情報処理装置および方法、並びにプログラム
【課題】一機器から得られた所定の種類のコンテンツに関するユーザの情報を、別の種類のコンテンツの推薦や、別の機器での推薦に活用できるようにする。
【解決手段】クライアント機器１０１は、映画再生等に関するユーザの振る舞いの履歴から、映画についてのユーザの性質を表す性質情報を１以上生成し、性質プロファイル蓄積部１３８に蓄積させる。一方、クライアント機器１は、楽曲再生等に関するユーザの振る舞いの履歴から、楽曲についてのユーザの性質を表す性質情報を１以上生成し、性質プロファイル蓄積部３８に蓄積させる。この楽曲についての１以上の性質情報は、通信部３９，１３９を介して性質プロファイル蓄積部１３８に蓄積される。映画推薦サーバ１０２は、映画についてのみならず、音楽についての性質情報も活用して映画推薦ができる。本発明は、コンテンツ推薦システムに適用可能である。
【解決手段】クライアント機器１０１は、映画再生等に関するユーザの振る舞いの履歴から、映画についてのユーザの性質を表す性質情報を１以上生成し、性質プロファイル蓄積部１３８に蓄積させる。一方、クライアント機器１は、楽曲再生等に関するユーザの振る舞いの履歴から、楽曲についてのユーザの性質を表す性質情報を１以上生成し、性質プロファイル蓄積部３８に蓄積させる。この楽曲についての１以上の性質情報は、通信部３９，１３９を介して性質プロファイル蓄積部１３８に蓄積される。映画推薦サーバ１０２は、映画についてのみならず、音楽についての性質情報も活用して映画推薦ができる。本発明は、コンテンツ推薦システムに適用可能である。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置および方法並びにプログラムに関し、特に、一機器から得られた所定の種類のコンテンツについてのユーザの情報を、別の種類のコンテンツの推薦や、別の機器での推薦に活用できるようになった、情報処理装置および方法並びにプログラムに関する。
【背景技術】
【０００２】
従来、ユーザの嗜好に基づいて、テレビジョン番組、楽曲などのコンテンツを検索し、ユーザに推薦するための発明、いわゆるコンテンツパーソナライゼーションのための発明が提案されている（例えば、特許文献１参照）。
【０００３】
コンテンツパーソナライゼーションには、協調フィルタリングと称される手法（以下、CF手法とも称する）や、コンテントベーストフィルタリングと称される手法(以下、CBF手法とも称する)が広く使われている。
【０００４】
CF手法とは、各ユーザのコンテンツの購入履歴をユーザ嗜好情報として管理し、コンテンツを推薦しようとする第１のユーザに対し、購入履歴が似ている別の第２のユーザを検出して、その第２のユーザが購入しており、かつ、第１のユーザが購入していないコンテンツを推薦する、といった手法であり、例えば、インターネット上の通信販売サイトにおいて採用されている。
【０００５】
また、CBF手法とは、コンテンツに対して配信側や販売側によって予め付与されているメタデータを直接的に嗜好の抽出やコンテンツの推薦に利用する、といった手法である。即ち、ユーザ嗜好情報として、各種メタデータをベクトル化した特徴ベクトルを利用し、ユーザ嗜好情報を示す特徴ベクトル（ユーザ嗜好ベクトルとも称する）と、候補となる各コンテンツの特徴ベクトルとの距離（余弦相関など）を算出し、算出された距離の短いコンテンツを、ユーザの嗜好に合致したコンテンツであるとして推薦する、といった手法である。
【特許文献１】特開２００４−１９４１０７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、CF手法においてもCBF手法においても、ユーザの購入履歴やユーザ嗜好ベクトルといったユーザ嗜好情報は、ユーザが使用する一機器から抽出されている。換言すると、従来の機器は、それぞれ独自にユーザ嗜好情報を抽出している。従って、ある機器でせっかく得たユーザ嗜好情報が、別の機器では全く利用ができないという事態が問題となっている。
【０００７】
この問題に対して、嗜好表現のスキーマを統一するというアプローチが考えられるが、例えばテレビジョン番組、楽曲、映画などのコンテンツの種類毎に、メタデータの形式がそれぞれ異なっており、さらに、同じ種類のコンテンツを取り扱う場合にも、今度は機器側の形式がそれぞれ異なっているため、現実的とはいえない。
【０００８】
本発明は、このような状況に鑑みてなされたものであり、一機器から得られた所定の種類のコンテンツについてのユーザの情報を、別の種類のコンテンツの推薦や、別の機器での推薦に活用できるようにするものである。
【課題を解決するための手段】
【０００９】
本発明の一側面の情報処理装置は、所定の種類のコンテンツに対して処理を実行する情報処理装置であって、前記所定の種類のコンテンツに対する前記処理に関するユーザの振る舞いの履歴を示す履歴情報に基づいて、その所定の種類のコンテンツについての前記ユーザの性質を表す性質情報を１以上生成する性質生成手段と、前記性質生成手段により生成された１以上の前記性質情報を送信する通信手段とを備える。
【００１０】
前記性質生成手段は、前記性質情報として、志向、広さ、深さ、および成熟度のうちの少なくとも１つを生成する。
【００１１】
前記性質生成手段は、前記履歴情報から把握される１以上のコンテンツの性質に基づいて、前記志向を生成する。
【００１２】
前記性質生成手段は、前記履歴情報から把握されるコンテンツのそれぞれを複数のコンテンツ属性に分類した場合における前記複数のコンテンツ属性毎の値の個数とエントロピーとに基づいて、前記広さと前記深さとのうちの少なくとも一方を生成する。
【００１３】
前記性質生成手段は、前記複数のコンテンツ属性として、多視点クラスタを利用する。
【００１４】
前記性質生成手段は、前記履歴情報から把握される１以上のコンテンツのそれぞれを複数のコンテンツ属性に分類した場合における前記複数のコンテンツ属性毎の値の個数とエントロピーとに基づいて、前記成熟度を生成する。
【００１５】
前記性質生成手段は、さらに、前記履歴情報から把握される１以上のコンテンツの性質に基づいて前記成熟度を生成する。
【００１６】
前記性質生成手段は、前記履歴情報を期間で区切り、区切られた前記期間のうちの所定期間についての履歴情報に基づいて前記成熟度を生成する。
【００１７】
前記性質生成手段は、１以上の前記性質情報の全てを正規化する。
【００１８】
前記通信手段は、１以上の前記性質情報とともに、コンテンツの前記所定の種類を示す情報を関連付けて送信する。
【００１９】
前記性質生成手段により生成された１以上に前記性質情報を保持する保持手段をさらに備え、前記通信手段は、さらに、別の情報処理装置から送信された１以上の前記性質情報を受信し、前記保持手段は、さらに、前記通信手段に受信された１以上の前記性質情報を、前記情報処理装置自身についての性質情報として保持する。
【００２０】
前記通信手段に受信された１以上の前記性質情報は、前記情報処理装置の処理対象の前記所定の種類とは別の種類のコンテンツについての性質情報である。
【００２１】
前記通信手段は、１以上の前記性質情報に対して、フリーキーワードを関連付けて送信する。
【００２２】
本発明の一側面の情報処理方法は、所定の種類のコンテンツに対して処理を実行する情報処理装置の情報処理方法であって、前記所定の種類のコンテンツに対する前記処理に関するユーザの振る舞いの履歴を示す履歴情報に基づいて、その所定の種類のコンテンツについての前記ユーザの性質を表す性質情報を１以上生成し、生成された１以上の前記性質情報を、前記情報処理装置から別の情報処理装置に送信する制御を行うステップを含む。
【００２３】
本発明の一側面のプログラムは、上述した本発明の一側面の情報処理方法に対応するプログラムである。
【００２４】
本発明の一側面の情報処理装置および方法、並びにプログラムにおいては、所定の種類のコンテンツに対して処理を実行する情報処理装置が対象となり、次のような処理が実行される。即ち、前記所定の種類のコンテンツに対する前記処理に関するユーザの振る舞いの履歴を示す履歴情報に基づいて、その所定の種類のコンテンツについての前記ユーザの性質を表す性質情報が１以上生成されて、前記情報処理装置から別の情報処理装置に送信される。
【発明の効果】
【００２５】
以上のごとく、本発明によれば、ユーザ嗜好情報そのものではなく、ユーザ嗜好情報の元となる履歴情報から、ユーザの性質を表す性質情報を得ることが可能になる。これにより、一機器から得られたこの性質情報を活用して、別の種類のコンテンツの推薦や、別の機器での推薦ができるようになる。
【発明を実施するための最良の形態】
【００２６】
以下に本発明の実施の形態を説明するが、本発明の構成要件と、発明の詳細な説明に記載の実施の形態との対応関係を例示すると、次のようになる。この記載は、本発明をサポートする実施の形態が、発明の詳細な説明に記載されていることを確認するためのものである。従って、発明の詳細な説明中には記載されているが、本発明の構成要件に対応する実施の形態として、ここには記載されていない実施の形態があったとしても、そのことは、その実施の形態が、その構成要件に対応するものではないことを意味するものではない。逆に、実施の形態が構成要件に対応するものとしてここに記載されていたとしても、そのことは、その実施の形態が、その構成要件以外の構成要件には対応しないものであることを意味するものでもない。
【００２７】
さらに、この記載は、発明の実施の形態に記載されている具体例に対応する発明が、請求項に全て記載されていることを意味するものではない。換言すれば、この記載は、発明の実施の形態に記載されている具体例に対応する発明であって、この出願の請求項には記載されていない発明の存在、すなわち、将来、分割出願されたり、補正により追加される発明の存在を否定するものではない。
【００２８】
本発明の一側面の情報処理装置（例えば図１のクライアント機器１や図１３のクライアント機器１０１）は、
所定の種類のコンテンツに対する処理（例えば図１のクライアント機器１については楽曲の再生等の処理であり、図１３のクライアント機器１０１については映画の再生等の処理）を実行する情報処理装置において、
前記所定の種類のコンテンツに対する前記処理に関するユーザの振る舞いの履歴を示す履歴情報（例えば図１の履歴蓄積部３４や図１３の履歴蓄積部１３４に蓄積された履歴情報）に基づいて、その所定の種類のコンテンツについての前記ユーザの性質を表す性質情報を１以上生成する性質生成手段（例えば図１の性質抽出部３７や図１３の性質抽出部１３７）と、
前記性質生成手段により生成された１以上の前記性質情報を送信する通信手段（例えば図１の通信部３９や図１３の通信部１３９）と
を備える。
【００２９】
前記性質生成手段は、前記性質情報として、志向、広さ、深さ、および成熟度のうちの少なくとも１つを生成する（例えば、図１２の例では、志向o，広さw，深さdを要素とする性質ベクトルD=(o , w , d)を生成する）。
【００３０】
前記性質生成手段は、前記履歴情報から把握される１以上のコンテンツの性質（例えば図１０の例では、楽曲m1乃至m4が、ユーザの振る舞い（視聴や購入）により履歴の対象となったコンテンツ、即ち、履歴情報から把握されるコンテンツであり、それらの楽曲m1乃至m4の被ダウンロード数）に基づいて、前記志向を生成する。
【００３１】
前記性質生成手段は、前記履歴情報から把握されるコンテンツのそれぞれを複数のコンテンツ属性に分類した場合における前記複数のコンテンツ属性毎の値（例えば図１０の例では、楽曲m1乃至m4が、ユーザの振る舞い（視聴や購入）により履歴の対象となったコンテンツ、即ち、履歴情報から把握されるコンテンツであり、これらの楽曲m1乃至m4が、各コンテンツ属性を示す各クラスタのうちの1以上に分類された結果を示す小さな丸印、即ち、View1乃至View3の各クラスタに存在する小さな丸印）の個数とエントロピーとに基づいて、前記広さと前記深さとのうちの少なくとも一方を生成する。
【００３２】
前記性質生成手段は、前記複数のコンテンツ属性として、多視点クラスタ（例えば図１０の３つのView1乃至View3のそれぞれに楕円として示されている各クラスタ）を利用する。
【００３３】
前記性質生成手段は、前記履歴情報から把握される１以上のコンテンツのそれぞれを複数のコンテンツ属性に分類した場合における前記複数のコンテンツ属性毎の値（例えば図１１の例では、楽曲mnが、ユーザの振る舞い（視聴や購入）により履歴の対象となったコンテンツ、即ち、履歴情報から把握されるコンテンツであり、この楽曲mnが、各コンテンツ属性を示す各クラスタのうちの1以上に分類された結果を示す小さな丸印、即ち、View1，View2の各クラスタに存在する小さな丸印）の個数とエントロピーとに基づいて、前記成熟度を生成する。
【００３４】
前記性質生成手段により生成された１以上の前記性質情報を保持する保持手段（例えば図１の性質プロファイル蓄積部３８や図１３の性質プロファイル蓄積部１３８）をさらに備え、
前記通信手段は、さらに、別の情報処理装置から送信された１以上の前記性質情報を受信し（図１３の通信部１３９参照）、
前記保持手段は、さらに、前記通信手段に受信された１以上の前記性質情報を、前記情報処理装置自身についての性質情報として保持する。
【００３５】
本発明の一側面の情報処理方法は、
所定の種類のコンテンツに対する処理を実行する情報処理装置（例えば図１のクライアント機器１や図１３のクライアント機器１０１）の情報処理方法であって、
前記所定の種類のコンテンツに対する前記処理に関するユーザの振る舞いの履歴を示す履歴情報に基づいて、その所定の種類のコンテンツについての前記ユーザの性質を表す性質情報を１以上生成し（例えば図１の性質抽出部３７や図１３の性質抽出部１３７の処理）、
生成された１以上の前記性質情報を、前記情報処理装置から別の情報処理装置に送信する（例えば図１の通信部３９や図１３の通信部１３９の処理）
ステップを含む情報処理方法。
【００３６】
本発明の一側面のプログラムは、上述した本発明の一側面の情報処理方法に対応するプログラムであって、例えば図１６のコンピュータにより実行される。
【００３７】
このように、本発明ではコンテンツを取り扱うことができる。ここに、コンテンツとは、広く、人間の創造的活動により生み出されるものである。例えば、映画、音楽、演劇、文芸、写真、漫画、アニメーション、コンピュータゲームその他の文字、図形、色彩、音声、動作若しくは映像若しくはこれらを組み合わせたものまたはこれらに係る情報を電子計算機を介して提供するためのプログラムが、コンテンツの一例である。ただし、本明細書では、いわゆるコンテンツデータ、即ち、人間の創造的活動により生み出されたものが装置によって処理可能な形態とされたもの、例えば電気信号とされたものや、メモリに固定されたもの等も、特に区別せずにまとめて、コンテンツと称する。
【００３８】
以下、図面を参照して、本発明の実施の形態について説明する。
【００３９】
図１は、本発明が適用される情報処理システムの構成例を示している。
【００４０】
図１の例では、情報処理システムは、クライアント機器１、楽曲推薦サーバ２、および、楽曲配信管理サーバ３から構成されている。
【００４１】
なお、情報処理システムを構成するクライアント機器の台数は、図１の例ではクライアント機器１の1台のみであるが、図１の例に限定されず、１台以上であれば任意の台数でよい。実際には、多数のユーザが存在し、また、取り扱うコンテンツの種類も様々であることから、多数のクライアント機器が存在することになろう。
【００４２】
また、情報処理システムを構成するサーバも、図１の例では、楽曲推薦サーバ２と楽曲配信管理サーバ３とのみであるが、図１の例に限定されず、情報処理システムの用途や性質に応じたサーバを採用すればよい。
【００４３】
即ち、図１の例の情報処理システムの取り扱うコンテンツの種類は、音楽（楽曲）とされている。換言すると、図１の例の情報処理システムは、特に楽曲ダウンロードサービスにおける嗜好抽出を行うことが可能な情報処理システムとされている。それ故、図１の例では、楽曲推薦サーバ２と楽曲配信管理サーバ３とが設けられているのである。
【００４４】
なお、以下、説明の簡略上、クライアント機器１にダウンロードされて再生された楽曲を、そのクライアント機器１を使用するユーザにとっての好みの楽曲（以下、嗜好楽曲と称する）として取り扱うとする。
【００４５】
楽曲推薦サーバ２は、楽曲アイテムデータベース１１と楽曲推薦エンジン１２とを含むように構成されている。
【００４６】
楽曲アイテムデータベース１１には、ダウンロード可能な複数の楽曲がそのメタデータと関連付けられて蓄積されている。
【００４７】
なお、本実施の形態では、楽曲推薦サーバ２は、楽曲のダウンロードサービス自体も行うとしているため、楽曲アイテムデータベース１１には、ダウンロード対象の楽曲の実データ自体も蓄積されている。換言すると、楽曲のダウンロードサービスは別のサーバが行い、楽曲推薦サーバ２は、楽曲推薦のみを行うとした場合には、楽曲のメタデータのみを楽曲アイテムデータベース１１に蓄積させることができる。
【００４８】
また、以下、説明の簡略上、特に断りのない限り、楽曲が伝達されると表現した場合には、楽曲の実データとともに、そのメタデータも伝達されることを意味するとする。
【００４９】
楽曲推薦エンジン１２は、楽曲アイテムデータベース１１に蓄積されている複数の楽曲の中から、クライアント機器１を利用するユーザに推薦すべき楽曲（以下、推薦楽曲と称する）を選択し、クライアント機器１に提供する。このため、楽曲推薦エンジン１２は、類似度演算部２１と性質適合フィルタ部２２とを有している。
【００５０】
類似度演算部２１は、クライアント機器１の後述する嗜好プロファイル蓄積部３６に蓄積された嗜好プロファイルと類似する楽曲、即ち、クライアント機器１のユーザの嗜好楽曲と類似する楽曲を、推薦楽曲の候補（以下、推薦候補と称する）として選択する。なお、類似度演算部２１の類似度演算手法は特に限定されず、例えば、各楽曲のメタデータをベクトル化して、それらの各ベクトル間のCosine距離等で類似度を演算する、といった手法を採用できる。
【００５１】
性質適合フィルタ部２２については、後述する。
【００５２】
楽曲配信管理サーバ３は、楽曲推薦サーバ２から配信される各楽曲に関する各種情報を管理する。具体的には例えば、楽曲配信管理サーバ３は、楽曲毎の被ダウンロード総数を管理することができる。即ち、上述したように、実際にはクライアント機器１のみならず、多数のクライアント機器が存在し、１つの楽曲は、それらの多数のクライアント機器のそれぞれに対して楽曲推薦サーバ２から個別配信される。そこで、楽曲配信管理サーバ３は、例えば、各楽曲毎に、楽曲推薦サーバ２から個別配信された回数をカウントし、そのカウント数を、その楽曲の被ダウンロード総数として管理することができる。かかる楽曲毎の被ダウンロード総数は、適宜、楽曲配信管理サーバ３からクライアント機器１に提供される。
【００５３】
クライアント機器１は、方略決定部３１乃至通信部３９を含むように構成されている。
【００５４】
方略決定部３１は、楽曲推薦サーバ２から配信された推薦楽曲の推薦方略を、後述する性質プロファイル蓄積部３８に蓄積された性質プロファイルに応じて決定し、推薦提示部３２に通知する。なお、推薦方略の具体例については、後述する。
【００５５】
推薦提示部３２は、楽曲推薦サーバ２から配信された推薦楽曲を、方略決定部３１により決定された推薦方略に基づいてユーザに提示する。より正確には、推薦楽曲の提示とは、推薦楽曲全体の再生による提示を意味する訳ではなく、例えば、推薦楽曲の一部分の再生による提示や、推薦楽曲のメタデータから生成される情報の提示、具体的には画像情報の表示による提示や、音声情報の音声出力による提示等を意味する。
【００５６】
ユーザが、この推薦を受け入れて、その推薦楽曲を視聴する指示をクライアント機器１に与えると（指示を受けるブロックは図示せず）、再生部３３は、指示された楽曲の再生を行う。
【００５７】
上述したように、再生部３３により再生された楽曲、即ち、ユーザが推薦を受け入れて視聴した楽曲が、本実施の形態では、ユーザの嗜好楽曲とみなされる。そこで、その嗜好楽曲に関する情報、例えば本実施の形態ではメタデータが、履歴情報として履歴蓄積部３４に蓄積される。
【００５８】
嗜好抽出部３５は、履歴蓄積部３４に蓄積された履歴情報から、ユーザ嗜好情報を抽出し、嗜好プロファイル蓄積部３６に蓄積させる。なお、ユーザ嗜好情報の抽出手法は、特に限定されず、例えば、CBF(Content Based Filtering)手法等を採用することができる。
【００５９】
一方、性質抽出部３７は、履歴蓄積部３４に蓄積された履歴情報から、楽曲についてのユーザの性質を表す1以上の情報（以下、性質情報と称する）を抽出し、性質プロファイル蓄積部３８に蓄積させる。
【００６０】
より一般的に性質情報について説明すると、所定の種類のコンテンツに対する一機器の処理に関するユーザの振る舞いの履歴から、その所定の種類のコンテンツについてのユーザの性質を表す性質情報が１以上生成されることになる。
【００６１】
ユーザの性質情報としては、例えば志向、広さ、深さ、および成熟度が採用可能であり、これらの性質情報のうちの少なくともひとつにより、所定の種類のコンテンツについてのユーザの性質が表現される。
【００６２】
志向とは、ユーザが好むコンテンツ自体がもっている大衆性を示す情報、具体的には例えば、大衆性の高いものであるのか、それともニッチなものであるのかといったことを示す情報をいう。
【００６３】
広さや深さは、コンテンツを分類するクラスタとして事前に決められたクラスタ単位、例えばジャンル単位等でみたときにおけるユーザのコンテンツ経験（コンテンツの購買や視聴等の経験）の広さや深さを示すものである。広さとは、コンテンツ経験の範囲はどのくらい局所に集中しているのかといったことを示す情報をいう。広さの把握により、どのくらいの範囲までのコンテンツ推薦をユーザは許容するのかについての可能性等がわかる。深さとは、とあるクラスタ単位でみたとき、そのクラスタに属するコンテンツをユーザはどのくらい経験しつくしているのか、といったことを示す情報をいう。ここで、クラスタとは、一般的なジャンルに留まらず、個人の嗜好をよりよく表現できるように作成されたものも含む広義な概念である。なお、クラスタの具体例については後述する。
【００６４】
成熟度とは、広さと深さの両面を兼ね備えた指標をいう。例えば広さと深さを適切に掛け合わせたものを成熟度として採用することができる。さらに、志向であるニッチ性を加味したもの成熟度として採用することができる。例えば、ニッチ度を広さと深さのいずれかあるいは両方と適切に掛け合わせたものを成熟度として採用することもできる。さらに、時期で区切って、その時期に絞った範囲内で上述したように求めたものを成熟度として採用することができる。具体的には例えば、最近１年間のコンテンツ経験に絞って上述したように求めたものを成熟度として採用することができる。
【００６５】
以上の定義は、ユーザのコンテンツ経験の分布を捉えるものが性質であるとした場合の定義の一例であって、その分布を、志向、広さ、深さ、あるいは成熟度として把握する場合の定義である。
【００６６】
従って、性質の捉え方によっては、別の定義による性質情報を採用することもできる。具体的には例えば、性質はコンテンツ単位の他にアーティスト単位でも捉えることができ、このアーティストに着目して定義された性質情報を採用することもできる。
【００６７】
ここで、各性質情報の具体的な生成手法を説明する前に、その生成手法で必要となる履歴情報のクラスタリング手法について、図２乃至図９を参照して説明する。
【００６８】
性質抽出部３７は、履歴蓄積部３４に蓄積された全ての楽曲のメタデータの各項目（タイトル、アーティスト名、ジャンル、レビューテキスト、テンポ、ビート、リズム等）を、図２に示すようなクラスタ層（第１乃至ｎ層）のいずれかに分類し、各項目の実情報を分類したクラスタ層に設けられる複数のクラスタのいずれかに、楽曲を分類（クラスタリング）する。
【００６９】
なお、１つの楽曲を複数のクラスタに分類してもよい。同一クラスタ層に存在するクラスタ間の距離（類似の程度を示す）は既知であるものとする。このクラスタリングの手法については後述する。そして、性質抽出部３７は、メタデータの代わりに楽曲の特徴を示す情報として、メタデータの各項目の実情報を分類したクラスタのクラスタＩＤ（図２におけるＣＬ１１など）からなるクラスタ情報を生成して保持するか、履歴蓄積部３４等に蓄積させる。
【００７０】
なお、分類に適したクラスタが存在しない場合、新たにクラスタを新設してもよい。各クラスタのサイズは任意であって複数の楽曲を包含できるものである。なお、単一の楽曲だけしか分類することができないクラスタを設けてもよい。この場合、当該クラスタのクラスタＩＤに唯一分類可能な楽曲の実情報のＩＤ（アーティストＩＤ、アルバムＩＤ、タイトルＩＤ）を用いてもよい。
【００７１】
図３はクラスタ情報の一例を示している。同図においては、例えば、楽曲ＩＤ＝ABC123の楽曲のクラスタ情報は、クラスタＩＤ（ＣＬ１２、ＣＬ２１、ＣＬ３５，ＣＬ４７，ＣＬ５２，…，ＣＬｎ２）であることを示している。また例えば、楽曲ＩＤ＝CTH863の楽曲のクラスタ情報は、クラスタＩＤ（ＣＬ１１、ＣＬ２５、ＣＬ３１，ＣＬ４２，ＣＬ５３，…，ＣＬｎ１）であることを示している。
【００７２】
図４は、図３に示されたクラスタ情報に対応するクラスタ−楽曲ＩＤ情報の一例を示している。なお、同図のｉは、クラスタ層の第ｉ層を示している。同図においては、例えば、クラスタＩＤ＝ＣＬ１１には、楽曲ＩＤ＝CTH863が対応することを示している。また例えば、クラスタＩＤ＝ＣＬ２１には、楽曲ＩＤ＝ABC123が対応することを示している。
【００７３】
さらに以下、性質抽出部３７による楽曲（メタデータ）のクラスタリングについて説明
する。
【００７４】
クラスタリング手法はいかなる手法でもかまわないが、クラスタ層毎に最適なクラスタリング手法、距離尺度を選ぶようにする。例えば、メタデータの実情報が数値であるならばそのまま、タイトルなどの場合は主成分分析等の数量化手法を用いて数値にして、ユークリッド距離などの距離尺度を定義してクラスタリングすることになる。代表的なクラスタリング手法としては、K-means法、階層クラスタリング法などを挙げることができる。
【００７５】
この際、嗜好距離を反映したクラスタリング（例えば、制約付きクラスタリング）によって実施することが望ましい。そのためには、事前調査により部分的な正解集（嗜好的に近い実情報の集合、遠い実情報の集合など）を作り、それに適合する数値表現、距離、クラスタリング手法を用いるものとする。またさらに、形成される各クラスタ層の独立性が高くなるクラスタリング手法（すなわち、特性の異なるクラスタリング手法）を選ぶことが望ましい。
【００７６】
例えば４種類のクラスタリング手法（以下、第１乃至４手法と称する）の中から特性の
異なる２種類のクラスタリング手法を選択する方法について、図５乃至図９を参照して
説明する。
【００７７】
まず、性質抽出部３７は、第１乃至４手法によってメタデータの実情報であるアーティストＡ乃至Ｊをクラスタリングする。そして図５に示すような結果が得られたとする。
【００７８】
すなわち、第１手法により、アーティストＡ乃至ＣがクラスタＣＬ１に、アーティストＤ乃至ＧがクラスタＣＬ２に、アーティストＨ乃至ＪがクラスタＣＬ３にクラスタリングされ、第２手法により、アーティストＡ，ＢがクラスタＣＬ１に、アーティストＣ乃至ＦがクラスタＣＬ２に、アーティストＧ乃至ＪがクラスタＣＬ３にクラスタリングされ、第３手法により、アーティストＡ，Ｄ，Ｇ，ＪがクラスタＣＬ１に、アーティストＢ，Ｅ，ＨがクラスタＣＬ２に、アーティストＣ，Ｆ，ＩがクラスタＣＬ３にクラスタリングされ、第４手法により、アーティストＤ，Ｉ，ＪがクラスタＣＬ１に、アーティストＥ乃至ＧがクラスタＣＬ２に、アーティストＡ乃至ＣおよびＨがクラスタＣＬ３にクラスタリングされたとする。
【００７９】
この場合、第１乃至４手法による結果の重複率（％）は図６に示すとおりである。すなわち、第１手法と第２手法の重複率は０．８、第１手法と第３手法の重複率は０．３、第１手法と第４手法の重複率は０．４、第２手法と第３手法の重複率は０．３、第２手法と第４手法の重複率は０．３、第３手法と第４手法の重複率は０．４である。
【００８０】
図６に示された重複率が小さいほど２つの手法の特性が異なると考えられるので、重複率が最小値の０．３である組み合わせ、即ち、第１手法と第３手法の組み合わせ、第２手法と第３手法の組み合わせ、または第２手法と第４手法の組み合わせを採用することが望ましい。
【００８１】
一方、ユーザ自身によってアーティストＡ乃至Ｊのうちの二人が同じクラスタに分類されるべきであるか否かを判定させた場合、図７に示すような結果が得られたとする。ただし、同図において、１は同じクラスタに分類されるべきであることを、０は異なるクラスタに分類されるべきであることを意味する。すなわち、同図においては、例えば、アーティストＡがアーティストＢ，Ｃ，Ｆ，Ｈ，Ｉと同じクラスタに分類されるべきであると判断されたことが示されており、アーティストＢがアーティストＣ，Ｄ，Ｅ，Ｊと同じクラスタに分類されるべきであることが示されている。
【００８２】
図７に示された結果を、正解とする理想的なクラスタリング結果であるとするならば、上述した第１乃至４手法の正解率は図８に示すとおりである。すなわち、第１手法の正解率は６２．２％、第２手法の正解率は５５．６％、第３手法の正解率は４０．０％、第４手法の正解率は６６．７％である。
【００８３】
従って、正解率を重視するならば、正解率が高い第１手法と第４手法の組み合わせを採用することが望ましい。
【００８４】
さらに、重複率と正解率を加味したクラスタリング手法の組み合わせを求めるため、第１乃至４手法の正解の重複率を算出すれば、図９に示すとおりとなる。図８に示された各手法単体の正解率の結果から正解率が極端に低い手法を特定し、特定した当該手法を含まない組み合わせのうちの正解率の重複率が最も低い組み合わせを図９に示される結果から特定し、特定した当該組み合わせを採用すればよい。すなわち、正解率が極端に低い手法として、図８の正解率が４０．０％の第３手法が特定され、第３手法を含まない組み合わせのうちの正解の重複率が最も低いものとして、図９の２４．４％の第２手法と第３手法の組み合わせが選択される。
【００８５】
なお、上述した重複率や正解率については絶対的な閾値を指定して、それ閾値を満たすことができない手法を除外してもよいし、バランスがとれた手法を採用するために、２つの指標（重複率と正解率）に基づいて例えば、以下に示す２例のような総合的な指標を作成し、総合的な指標に基づいてクラスタリングの手法の組み合わせを選択するようにしてもよい。
総合的な指標＝正解率×（１−重複率）
総合的な指標＝α×正解率×β（１−重複率） （α，βは所定の係数）
【００８６】
このように、性質抽出部３７による楽曲（メタデータ）のクラスタリングの結果を用いることで、各クラスタ層のそれぞれに視点を移して、コンテンツ属性の把握を行うことができる。即ち、各クラスタ層に属する各クラスタのそれぞれは、そのクラスタ層に応じた複数のコンテンツ属性をそれぞれ示していると把握することもできる。
【００８７】
換言すると、以上説明した性質抽出部３７による楽曲（メタデータ）のクラスタリングは、多視点の複数のクラスタへの分類であるともいえる。そこで、以下、各クラスタ層をViewと適宜称する。ただし、各Viewのクラスタは、以下、必要に応じて多視点クラスタと称する場合もあるし、そのままクラスタと称する場合もある。
【００８８】
性質抽出部３７は、このようにして楽曲（メタデータ）のクラスタリングを行うと、その結果（以下、多視点クラスタリング結果と称する）を用いて、各性質情報を生成する。
【００８９】
そこで、以下、各性質情報の生成手法の具体例についてそれぞれ説明する。
【００９０】
ただし、以下、説明の簡略上、図１０に示される多視点クラスタリング結果を用いて説明を行っていく。即ち、図１０に示されるように、８個のクラスタ（図中楕円）をそれぞれ有するView1乃至View3のそれぞれに対して、小さな丸印で示される４つの楽曲m1乃至m4がクラスタリングされたとして、以下の説明を行っていく。ただし、図１０に示されるように、View1とView3では１つの楽曲m1乃至m4のそれぞれが２クラスタで表現されている一方、View2では１つの楽曲m1乃至m4のそれぞれが１クラスタ（ハードクラスタリング）で表現されている。このように、１つの楽曲が複数クラスタで表現され得るため、以下の説明では、楽曲数（図１０の例では４）ではなく、各クラスタに含まれる値（図１０の例では丸印）の数（以下、曲エントリ数と称する）を用いるとする。
【００９１】
はじめに、志向(以下oとも記述する)の生成手法について説明する。
【００９２】
ここで、とある時点での楽曲の被ダウンロード数のLogを正規化（0乃至1.0）したものを、楽曲のメジャー志向度として定義する。なお、楽曲の被ダウンロード数は、本実施の形態では上述したように、図１の楽曲配信管理サーバ３から通信部３９を介して性質抽出部３７に提供される。
【００９３】
この場合、性質抽出部３７は、ユーザのメジャー志向度を、そのユーザのダウンロード再生楽曲（図１の例では、履歴蓄積部３４にメタデータが蓄積された楽曲）のもつメジャー志向度の平均として求め、そのユーザのメジャー志向度を志向ｏとする。
【００９４】
この場合の正規化項は、全ユーザのメジャー志向度が正規分布になるように調整されるとする。ここに、全ユーザとは、図１のクライアント機器１を利用するユーザと、図１には図示されていない多数のクライアント機器をそれぞれ使用する多数のユーザとを加えた全ユーザをいう。ただし、実際は、正規化項は、実際はサンプリングにより求められるとする。なお、正規化する理由は、他の性質情報、即ち後述する広さ、深さ、成熟度等との尺度をあわせるためである。即ち、後述するように、他の性質情報もまた正規化されることになる。
【００９５】
具体的には例えば、図１０の例において、楽曲m1の被ダウンロード数が1024とされ、楽曲m2の被ダウンロード数が8とされ、楽曲m3の被ダウンロード数が64とされ、楽曲m4の被ダウンロード数が512とされ、また、正規化項が16だった(全楽曲のうちの最も多くダウンロードされた楽曲について、そのダウンロード数が65536だった)とする。
【００９６】
この場合、志向ｏは、次の式（１）のように演算されることになる。なお、以下の各式で記述するlogの底は２であるが、この底については省略されている。
【００９７】
【数１】
【００９８】
なお、上述した志向oの生成手法は例示に過ぎず、志向oの生成手法としては、その他例えば、楽曲のメジャー志向度として、正規化した各楽曲の有名度を採用してもよいし、各楽曲の売り上げ等のランキングを正規化したものを採用してもよい。
【００９９】
より一般的にいえば、楽曲のメジャー志向度とは、その楽曲の性質を表している。即ち、志向oの生成手法は、各コンテンツの性質に基づいて生成する手法であれば、特に限定されない。
【０１００】
次に、広さ(以下wとも記述する)の生成手法について説明する。
【０１０１】
性質抽出部３７は、多視点クラスタリング結果の各View毎にエントロピーを求める。View v（vは、層番号を示し、図１０の例では、１乃至３のうちの何れかの値である）のクラスタv-i（ｉは、クラスタの番号を示す）に属する曲エントリ数Sv-iを、全曲エントリ数S=ΣSv-iで割った値を Pv-i とするとき、View vのエントロピーEvは、次の式（２）に示される通りとなる。なお、図１０の例では、View vにおいて、左上端のクラスタの番号を１として、右方向に順次並ぶクラスタのそれぞれに対して番号２乃至４をそれぞれ付していき、その後、左下端のクラスタの番号を５として、右方向に順次並ぶクラスタのそれぞれに対して６乃至８をそれぞれ付していったとする。
【０１０２】
【数２】
【０１０３】
ただし、曲エントリ数が0（Pv-i=0）の場合は、クラスタ種類数nに応じた一定の微小値（例えば nの二乗）を入れて、Pv-iやEvは、次の式（３）乃至式（５）の通りに修正されるとする。
【０１０４】
【数３】
【０１０５】
そして、性質抽出部３７は、エントロピーEv の中で最小エントロピーEv-minを正規化した値を、広さwとして求める。正規化項は、クラスタ数で決まる最大エントロピーEmaxが1.0になるように調整されるとする。
【０１０６】
具体的には例えば、図１０のView1乃至View3のエントロピーE1乃至E3のそれぞれは、式（６）乃至式（８）のそれぞれのように求められる。従って、最小エントロピーEv-minは、式（９）に示される通りとなり、最大エントロピーEmaxは、式（１０）に示される通りとなる。その結果、広さwは、式（１１）に示される通りとなる。
【０１０７】
【数４】
【０１０８】
次に、深さ(以下ｄとも記述する)の生成手法について説明する。
【０１０９】
この場合、性質抽出部３７は、広さwの算出に利用した最小エントロピーEv-minを有するViewを特定し、そのViewにおける各クラスタのうちの、Pv-iが最大値をとるクラスタの曲エントリ数Sv-i-maxを正規化した値を、深さｄとして算出する。
【０１１０】
具体的には例えば、全ユーザの最大曲エントリ数Sv-i-max が100とすると、図１０の例ではView3が最小エントロピーEv-minを有するので、曲エントリ数Sv-i-maxは次の式（１２）に示される通りとなり、その結果、深さdは次の式（１３）に示される通りとなる。
【０１１１】
【数５】
【０１１２】
なお、上述した広さwや深さｄの生成手法は例示に過ぎず、その他、例えば、次のような広さwや深さｄの生成手法を採用することができる。
【０１１３】
即ち、上述した例では、多視点クラスタにマッピングされる対象は、履歴蓄積部３４に蓄積されている楽曲（以下、ユーザ所持楽曲とも称する）とされたが、図１の楽曲推薦サーバ２の楽曲アイテムデータベース１１の全楽曲を多視点クラスタにマッピングした結果を利用して、上述した広さwや深さｄを算出してもよい。
【０１１４】
ただし、全楽曲が多視点クラスタにマッピングされたときには、各多視点クラスタへの所属数は偏りを持ち、その偏り度合いはViewにより異なることになる。そこで、性質抽出部３７は、全楽曲がマッピングされたときのクラスタ所属比率でView間の正規化を行い、この正規化値を用いてエントロピーEvを求めるとよい。具体的には例えば、とあるView vでのクラスタv-iの所属数がni 、全所属数合計がNだったとき、Pv-i× (N/ni)が正規化されるとP'v-iとなるので、性質抽出部３７は、この値P'v-iを用いてエントロピーEvを求めるとよい。即ち、性質抽出部３７は、ユーザ所持楽曲による曲エントリ数Sv-iを用いてPv-iを求めて、そのPv-iを用いてP'v-i を求めるとよい。
【０１１５】
即ち、性質抽出部３７は、View vのエントロピーEvを求めるための値として、上述した値Pv-iの代わりに、次の式（１４）により算出される値P'v-iを利用して、エントロピーEvを求めることもできる。
【０１１６】
【数６】
【０１１７】
具体的には例えば、全楽曲が多視点クラスタにマッピングされた結果が図１１に示される通りであるとする。即ち、図１１に示されるように、２個のクラスタ（図中楕円）をそれぞれ有する２つのView１，２に対して、ユーザ所持楽曲mnを含む２以上の楽曲がクラスタリングされたとする。ただし、以下の説明でも、曲エントリ数、即ち、図１１中小さい丸印の数が用いられるとする。
【０１１８】
この場合、View1のエントロピーE1は、次の式（１５）乃至（１７）に示される通りに演算されることになる。
【０１１９】
【数７】
【０１２０】
一方、View2のエントロピーE2は、次の式（１８）乃至（２０）に示される通りに演算されることになる。
【０１２１】
【数８】
【０１２２】
従って、図１１の例では、E1 ＜ E2となる。
【０１２３】
上述した広さwや深さｄの生成手法もまた例示に過ぎない。即ち、広さwや深さｄの生成手法をより一般的にいうと、ユーザの履歴から把握されるコンテンツのそれぞれを複数のコンテンツ属性（上述した例では多視点クラスタ）に分類した場合における複数のコンテンツ属性毎の値の個数とエントロピーとに基づいて、広さwと深さdとのうちの少なくとも一方を生成する、といった手法が適用可能であり、かかる手法の具体例の幾つかについて上述したことになる。
【０１２４】
次に、成熟度(以下ｍとも記述する)の生成手法について説明する。
【０１２５】
即ち、上述した全楽曲についての多視点クラスタリング結果（例えば図１１に示される結果等）を用いてView間の正規化計算でエントロピーEvがそれぞれ演算され、その結果、最小エントロピーEv-minを持つViewが、View voとなったとする。
【０１２６】
この場合、このView voにおいて、クラスタvo-iのうちの全所属数をnaiとして、ユーザ所持楽曲の所属数をnuiとし、全クラスタ数をncとしたとき、性質抽出部３７は、次の式（２１）に従って、成熟度mを算出することができる。
【０１２７】
【数９】
【０１２８】
具体的には例えば、図１１の例では、成熟度mは、次の式（２２）に示されるように算出される。
【０１２９】
m=｛(1/3)+(1/1)｝/2 ＝ 2/3 ・・・（２２）
【０１３０】
なお、全ての楽曲がユーザ所持楽曲となっていた場合には、m=1.0となる。
【０１３１】
上述した成熟度ｍの生成手法もまた例示に過ぎない。即ち、上述したように、成熟度mとは、広さwと深さdの両面を兼ね備えた指標をいう。従って、上述したように、広さwや深さｄの生成手法としては、ユーザの履歴から把握されるコンテンツのそれぞれを複数のコンテンツ属性（上述した例では多視点クラスタ）に分類した場合における複数のコンテンツ属性毎の値の個数とエントロピーとに基づいて、広さwと深さdとのうちの少なくとも一方を生成する、といった手法が適用可能である。従って例えば、成熟度ｍもまた、ユーザの履歴から把握されるコンテンツのそれぞれを複数のコンテンツ属性に分類した場合における複数のコンテンツ属性毎の値の個数とエントロピーとに基づいて成熟度ｍを生成する、といった手法を採用することもできる。
【０１３２】
さらに、上述したように、成熟度mとして、広さwと深さdの両面を兼ね備えたものに対して、志向oであるニッチ性を加味したものを採用することもできる。この場合には例えば、志向oの生成手法として、上述したように、各コンテンツの性質に基づいて志向ｏを生成する手法を採用できることを考慮すると、成熟度ｍの生成手法としては、上述した手法に加えて、さらに、履歴情報から把握される１以上のコンテンツの性質に基づいて成熟度ｍを生成するという手法を加えたものを採用することもできる。
【０１３３】
或いはまた例えば、上述したように、所定の時期に絞った範囲内で成熟度ｍを求めることもできる。即ち例えば、ユーザの履歴を期間で区切り、区切られた期間のうちの所定期間についてのユーザの履歴から把握されるコンテンツのそれぞれを複数のコンテンツ属性に分類した場合における複数のコンテンツ属性毎の値の個数とエントロピーとに基づいて成熟度ｍを生成する、いった手法を採用することもできる。
【０１３４】
このようにして、性質抽出部３７は、各性質情報を算出することができる。そこで、性質抽出部３７は、さらに、このようにして算出した各性質情報のうちの１以上を要素とするベクトル（以下、性質ベクトルと称する）、例えば、志向o、広さw、深さdを各要素とする性質ベクトルD=（o, w, d）を生成し、その性質ベクトルDを、ユーザの性質プロファイルとして性質プロファイル蓄積部３８に蓄積させることができる。例えば上述した図１０の例では、性質ベクトルD= （o, w, d）=(0.4375, 0.37, 0.04)が算出され、性質プロファイル蓄積部３８に蓄積されることになる。
【０１３５】
なお、性質ベクトルの次元および各要素のそれぞれは、性質ベクトルDに特に限定されない。例えば、広さwや深さdの代わりに、成熟度mを一要素とする性質ベクトルを採用してもよい。
【０１３６】
また、上述した例では、全楽曲を均等に扱うことで、性質ベクトルDが生成されているが、全楽曲を均等に扱う必要は特にない。例えば、性質抽出部３７は、楽曲のジャンル単位で、上述した一連の処理を行うことで、ジャンル毎の性質ベクトルを生成して、それらをユーザの性質プロファイルとして性質プロファイル蓄積部３８に蓄積させることもできる。
【０１３７】
なお、以下の説明では、説明の簡略上、性質抽出部３７は、志向o、広さw、深さdそのものの値を使用するのではなく、それらの値を適当な閾値で２値化し、２値化後の各値を各要素とする性質ベクトルDを生成し、性質プロファイル蓄積部３８に蓄積させるとする。
【０１３８】
この場合、志向oについては、１は、「メジャー志向」を示す値であり、０は「ニッチ志向」を示す値である。広さwについては、１は、「広い」を示す値であり、０は、「狭い」を示す値である。深さｄについては、１は、「深い」を示す値であり、０は、「浅い」を示す値である。
【０１３９】
例えば上述した図１０の例では、各性質情報としては、o=0.4375, w=0.37, d=0.04が算出されるので、閾値を0.5 としたときには、性質ベクトルD=（0,0,0）= (ニッチ志向、狭い、浅い)が得られて、性質プロファイル蓄積部３８に蓄積される。
【０１４０】
ここで、図１の楽曲推薦エンジン１２の性質適合フィルタ部２２は、性質ベクトルDの意味を解釈するための情報として、例えば図１２に示される情報を有しているとする。この場合、性質適合フィルタ部２２は、この図１２の情報を用いて、性質プロファイル蓄積部３８に蓄積されている性質ベクトルDの意味を簡単に解釈することができるようになる。
【０１４１】
その結果、性質適合フィルタ部２２は、類似度演算部２１の類似度演算により決定された1以上の推薦候補の中から、性質ベクトルDの意味に適合した楽曲を推薦楽曲として選抜し（フィルタリングし）、選抜した推薦楽曲を、クライアント機器１に対して提供することができる。
【０１４２】
或いは、性質適合フィルタ部２２は、性質ベクトルDの意味によっては、推薦候補となっていない楽曲を、別途推薦楽曲として決定することもできる。例えば、o＝メジャー志向であれば、ユーザ嗜好情報と類似しない楽曲（推薦候補に選ばれなかった楽曲）であったとしても、性質適合フィルタ部２２は、メジャー志向度の高い楽曲、例えば現在ヒット中の楽曲等を、推薦楽曲として決定することができる。
【０１４３】
具体的には例えば、図１０の例では、性質ベクトルD= (ニッチ志向、狭い、浅い)が得られて、性質プロファイル蓄積部３８に蓄積されている。従って、性質適合フィルタ部２２は、この性質ベクトルDの意味するところの「楽曲についてのユーザの性質」は、図１２の情報から、基本的に「ニッチ」であると判断できるが、視聴楽曲（経験）が少ないことによる「偶然？」の結果かもしれない、という解釈を行う。この場合、例えば、性質適合フィルタ部２２は、この解釈に基づいて、類似度演算部２１の類似度演算により決定された1以上の推薦候補のうちの、即ち、ユーザ嗜好情報に類似する１以上の楽曲のうちの、メジャー志向度の低い楽曲を、推薦楽曲としてクライアント機器１に提供することができる。ただし、性質適合フィルタ部２２は、d=浅いということも考慮して、例えば、基本として、最小エントロピーEv-minをもつViewのクラスタをはずさない範囲での選抜（フィルタリング）を行うとする。
【０１４４】
また例えば、性質ベクトルD= (ニッチ志向、広い、深い)が性質プロファイル蓄積部３８に蓄積されている場合には、性質適合フィルタ部２２は、次のような処理を実行することができる。即ち、性質適合フィルタ部２２は、この性質ベクトルDの意味するところの「楽曲についてのユーザの性質」は、図１２の情報から、基本的に「ニッチ好き」であるが、楽曲の視聴範囲は「守備範囲広い」であり、楽曲を視聴することに対して「貪欲」である、という解釈を行う。この場合、例えば、性質適合フィルタ部２２は、この解釈に基づいて、類似度演算部２１の類似度演算により決定された1以上の推薦候補のうちの、即ち、ユーザ嗜好情報に類似する１以上の楽曲のうちの、メジャー志向度の低い楽曲を、推薦楽曲としてクライアント機器１に提供することができる。ただし、この場合、性質適合フィルタ部２２は、w=広い，d=深いということも考慮して、例えば、基本として、適当に履歴のあるクラスタ間を飛ばすような選抜（フィルタリング）を行うとする。
【０１４５】
このようにして、性質ベクトルD= (ニッチ志向、広い、深い)の解釈に基づく推薦楽曲がクライアント機器１に提供されてきた場合、後述する方略決定部３１は、例えば、その推薦楽曲に適切な薀蓄情報をつけて提示する、という推薦方略を決定することができる。さらに、ユーザが、その推薦を受け入れた場合、即ち、その推薦楽曲が再生されて、履歴蓄積部３４に蓄積された場合、性質適合フィルタ部２２は、さらにクラスタ内でメジャー志向度の低い楽曲を推薦楽曲として選抜することで、「深くなり得る」というユーザの性向を満足させることができる。
【０１４６】
また例えば、性質ベクトルD= (メジャー志向、広い、浅い)が性質プロファイル蓄積部３８に蓄積されている場合には、性質適合フィルタ部２２は、次のような処理を実行することができる。即ち、性質適合フィルタ部２２は、この性質ベクトルDの意味するところの「楽曲についてのユーザの性質」は、図１２の情報から、基本的にメジャー志向、即ち「ミーハー」であるが、推薦範囲は「売れ筋でOK」である、という解釈を行う。この場合、例えば、性質適合フィルタ部２２は、この解釈に基づいて、類似度演算部２１の類似度演算により決定された推薦候補に拘らず、即ち、ユーザ嗜好情報に類似する楽曲に拘らず、ヒット曲などのメジャー志向度の高い楽曲を推薦楽曲に加えてクライアント機器１に提供することができる。また、性質適合フィルタ部２２は、w=広い，d=浅いということも考慮して、例えば、推薦候補からの推薦楽曲の選抜数は、推薦楽曲全体のうちの２割程度にとどめることとする。即ち、残りの８割の推薦楽曲は、ヒット曲などのメジャー志向度の高い楽曲となる。
【０１４７】
このようにして、ユーザの性質ベクトルDに応じた推薦楽曲が、楽曲推薦サーバ２からクライアント機器１の方略決定部３１に提供されると、方略決定部３１は、このユーザの性質ベクトルD、即ち、性質プロファイル蓄積部３８に蓄積されている性質ベクトルDを用いて、推薦楽曲の提示の方略を決定することができる。
【０１４８】
この提示の方略手法も、特に限定されず、例えば、性質適合フィルタ部２２と同様に図１２の情報を用いることができるとすれば、方略決定部３１は、その図１２の情報から性質ベクトルDの意味を解釈し、その解釈に応じた方略を決定する、という手法を採用できる。具体的には例えば、性質ベクトルD=（o , 狭い，深い）の場合には、方略決定部３１は、集中的に狭く深く同種の楽曲を連続的に提示する、という方略に決定することができる。一方、例えば、性質ベクトルD=（o , 広い，浅い）の場合には、方略決定部３１は、なるべく広く浅く様々な楽曲を連続的に提示する、という方略に決定することができる。
【０１４９】
以上説明した性質情報、即ち、志向o,広さw，深さd,成熟度mは、クライアント機器１から他の機器に転送することも可能である。この場合の転送プロトコルは特に限定されない。例えば、一般にはSOAP（Simple Object Access Protocol）通信や、Memory Stick（商標）での受け渡しなどが考えられるが、機器同士で定めた規格でもかまわない。さらに、他の機器に転送する場合には、単なる性質ベクトルを転送するのではなく、性質情報に加えて、音楽、映画など、コンテンツの種類をコード化した情報を要素とするベクトル（以下、転送用性質ベクトルSDと称する）を転送すると好適である。
【０１５０】
そこで、以下、コンテンツの種類をコード化した情報をkindと記述し、転送用性質ベクトルSD=(o,w,d,kind)として、音楽再生機器であるクライアント機器１から、別の機器、例えば映画再生機器に転送する例について説明する。
【０１５１】
この場合、映画再生機器は、例えば図１３のクライアント機器１０１として構成されているとする。このクライアント機器１０１は、方略決定部１３１乃至通信部１３９を含むように構成されている。方略決定部１３１乃至通信部１３９のそれぞれは、クライアント機器１の方略決定部３１乃至通信部３９（図１）のそれぞれと基本的に同様の機能と構成を有している。
【０１５２】
ただし、処理対象のコンテンツの種類、即ち推薦や再生の対象となるコンテンツの種類が、クライアント機器１では楽曲（音楽）であるのに対して、クライアント機器１０１では映画である点が異なる。
【０１５３】
従って、クライアント機器１０１は、映画推薦サーバ１０２から推薦映画の提供を受ける。この映画推薦サーバ１０２は、映画アイテムデータベース１１１、並びに、類似度演算部１２１および性質適合フィルタ部１２２からなる映画推薦エンジン１１２から構成されている。映画アイテムデータベース１１１、並びに、類似度演算部１２１および性質適合フィルタ部１２２からなる映画推薦エンジン１１２のそれぞれは、楽曲推薦サーバ２の楽曲アイテムデータベース１１、並びに類似度演算部２１および性質適合フィルタ部２２からなる楽曲推薦エンジン１２（図１）のそれぞれと基本的に同様の機能と構成を有している。ただし、処理対象コンテンツの種類、即ち、推薦等の対象となるコンテンツの種類が、楽曲推薦サーバ２では楽曲（音楽）であるのに対して、映画推薦サーバ１０２では映画である点が異なる。
【０１５４】
この場合、クライアント機器１は、性質プロファイル蓄積部３８に蓄積されている性質情報、即ち、志向o,広さw，深さdと、kind=musicとを各要素とする転送用性質ベクトルSD=(o,w,d,kind)を生成して、通信部３９を介してクライアント機器１０１に転送することができる。
【０１５５】
クライアント機器１０１側の通信部１３９は、この転送用性質ベクトルSDを受信して、性質プロファイル蓄積部１３８に蓄積させる。これにより、映画再生機器であるクライアント機器１０１は、音楽再生機器であるクライアント機器１側で得られた性質情報、即ち、楽曲についてのユーザの性質を表す性質情報を、映画の推薦等にも利用できるようになる。
【０１５６】
以下、具体例として、クライアント機器１からクライアント機器１０１に転送された転送用性質ベクトルSD=(o,w,d,kind=music)のうちの、性質情報の３要素（以下、性質tmpと称する）が、o=ニッチ志向、w＝狭い、d＝深いであった場合の例について説明する。また、映画には、楽曲（音楽）と同様にメジャー志向度が付けられているとする。
【０１５７】
この場合、映画推薦サーバ１０２は、クライアント機器１０１の履歴情報の蓄積量の多少、即ち、ユーザがクライアント機器１０１を利用して視聴した映画の数の大小に応じて、例えば次のような推薦を行うことができる。
【０１５８】
先ず、クライアント機器１０１の履歴情報の蓄積量、即ち、履歴蓄積部１３４に蓄積されている履歴情報が少ない状態での映画の推薦例について説明する。
【０１５９】
クライアント機器１０１の性質抽出部１３７も、履歴蓄積部１３４から映画についての履歴情報を抽出して、その履歴情報を利用して、映画についての各種性質情報を生成（算出）することができる。なお、以下、このようにして、クライアント機器１０１側で生成された性質情報、即ち、映画についての志向o、広さd、深さd等により表される性質を、性質Bと称する。この性質Bもまた、性質プロファイル蓄積部１３８に蓄積される。
【０１６０】
このように、性質Bは、クライアント機器１０１の履歴情報に基づいて生成されるので、その履歴情報の蓄積量が少ない場合に生成される性質Bは、ユーザの映画視聴の性向を十分に反映できていないと判断できる。
【０１６１】
そこで、このような場合、映画推薦サーバ１０２の映画推薦エンジン１１２は、クライアント機器１０１の性質プロファイル蓄積部１３８に蓄積されている性質tmpを用いて、即ち、ユーザの映画視聴の性向を示す性質Bの代わりに音楽視聴の性向を示す性質tmpを用いて、推薦候補の中からまたはそれ以外から、推薦映画を決定することができる。
【０１６２】
ここでいう推薦候補とは、クライアント機器１０１の嗜好プロファイル蓄積部１３６に蓄積されている嗜好プロファイル、即ち映画についてのユーザ嗜好情報（以下、嗜好Bと称する）を用いて、映画推薦エンジン１１２の類似度演算部１２１により決定される映画をいう。即ち、ここでいう推薦候補とは、嗜好Bに類似する映画をいう。
【０１６３】
より具体的には例えば、クライアント機器１０１で１つの好みの映画が選択された場合、即ち、ユーザの好みの１つの映画の再生指示がなされ、その結果、その映画が再生部１３３により再生され、その映画のメタ情報が履歴蓄積部１３４に蓄積された場合、嗜好抽出部１３５は、その選択された映画に基づいて嗜好Bを生成し、嗜好プロファイル蓄積部１３６に蓄積させる。
【０１６４】
すると、映画推薦エンジン１１２の類似度演算部１２１は、映画アイテムデータベース１１１に蓄積されている映画の中から、その嗜好Bに類似する映画、即ち、クライアント機器１０１で最初に選択された１つの好みの映画に類似する映画を、推薦候補として決定する。
【０１６５】
そして、映画推薦エンジン１１２の性質適合フィルタ部１２２が、クライアント機器１０１の性質プロファイル蓄積部１３８に蓄積されている性質tmpを用いて、即ち、ユーザの映画視聴の性向を示す性質Bの代わりに音楽視聴の性向を示す性質tmpを用いて、推薦候補の中からまたはそれ以外から、推薦映画を決定することができる。
【０１６６】
ここでは、性質tmpは、o=ニッチ志向、w＝狭い、d＝深い（以下、このような表現を、性質tmp＝ニッチ志向＆狭い＆深いという表現で記述する）であるので、性質適合フィルタ部１２２は、音楽視聴と同様に映画視聴でもユーザはニッチ志向で狭く深いという性向があるであろうと解釈し、この解釈に基づいて、例えば、推薦候補の中から、クライアント機器１０１で最初に選択された１つの好みの映画と同一ジャンルの映画を推薦映画として決定したり、同一出演者が出ているメジャー志向度の低い映画を推薦映画として決定することができる。
【０１６７】
なお、このように、映画推薦エンジン１１２による推薦が嗜好Bと性質tmpとを用いて行われる場合、そのような推薦を、以下、嗜好Bと性質tmpに基づく推薦と称する。
【０１６８】
かかる推薦をユーザが受け入れた場合、即ち、かかる推薦により決定された推薦映画が、クライアント機器１０１に提供されて、方略決定部１３１により決定された推薦方略で推薦提示部１３２によりユーザに提示され、その提示を受けたユーザにより再生指示がなされて、再生部１３３により再生された場合、ユーザの音楽視聴の性向と映画視聴の性向とは類似していると判断できる。
【０１６９】
従って、ユーザに推薦が受け入れられる毎に、即ち、クライアント機器１０１で別の好みの映画が選択される毎に、映画推薦エンジン１１２は、嗜好Bと性質tmpに基づく推薦、即ち、性質tmpの属性と類似した映画の推薦を行っていくことを繰り返していけばよい。このような推薦の繰り返しにより、性質tmp＝ニッチ志向＆狭い＆深いにあった推薦、即ち、狭い範囲での深い推薦が実現されていく。
【０１７０】
これに対して、かかる推薦をユーザが受け入れなかった場合、即ち、かかる推薦により決定された推薦映画が、クライアント機器１０１に提供されて、方略決定部１３１により決定された推薦方略で推薦提示部１３２によりユーザに提示されたが、その再生指示がユーザによりなされず、その結果、再生部１３３による再生がなされなかった場合、ユーザの音楽視聴の性向と映画視聴の性向とは非類似の可能性があると判断できる。
【０１７１】
即ち、ユーザが推薦を受け入れないことが何回かあった場合には、例えば、推薦を受け付けない回数をmissと記述したとしてmissが所定回数（５回等）以上となった場合には、ユーザの音楽視聴の性向と映画視聴の性向とは非類似であると判断できる。
【０１７２】
そこで、このような場合、映画推薦エンジン１１２は、性質tmpを用いずに、嗜好Bのみを利用した推薦（以下、嗜好Bに基づく推薦と称する）を行う。
【０１７３】
嗜好Bと性質tmpに基づく推薦と、嗜好Bに基づく推薦とのうちの何れの推薦がなされても、推薦がユーザに受け入れられる毎に、即ち、クライアント機器１０１で別の好みの映画が選択される毎に、クライアント機器１０１の履歴情報の蓄積量は増えていき、それに伴い、性質Bも更新されていく。即ち、性質Bは、ユーザの映画視聴の性向をだんだんと反映していく情報となっていく。
【０１７４】
従って、クライアント機器１０１の履歴情報の蓄積量が一定以上になった場合、例えば、その履歴情報の数（以下、履歴数と称する）が一定数（例えば２０）を超えた場合、映画推薦サーバ１０２の映画推薦エンジン１１２は、クライアント機器１０１の性質プロファイル蓄積部１３８に蓄積されている性質B、即ち、ユーザの映画視聴の性向を示す性質Bを用いて、推薦候補の中からまたはそれ以外から、推薦映画を決定することができる。
【０１７５】
この場合の推薦候補自体も、クライアント機器１０１の嗜好プロファイル蓄積部１３６に蓄積されている嗜好Bを用いて、映画推薦エンジン１１２の類似度演算部１２１により決定される。
【０１７６】
より具体的には例えば、映画推薦エンジン１１２の類似度演算部１２１は、映画アイテムデータベース１１１に蓄積されている映画の中から、その嗜好Bに類似する映画を、推薦候補として決定する。
【０１７７】
そして、映画推薦エンジン１１２の性質適合フィルタ部１２２は、クライアント機器１０１の性質プロファイル蓄積部１３８に蓄積されている性質Bを用いて、即ち、ユーザの映画視聴の性向を示す性質Bを用いて、推薦候補の中からまたはそれ以外から、推薦映画を決定する。
【０１７８】
この場合、例えば、性質Bと性質tmpとが同一である場合、即ち、ユーザの音楽視聴の性向と映画視聴の性向とがほぼ同様である場合、この例では、性質B＝ニッチ志向＆狭い＆深いの場合、性質適合フィルタ部１２２は、次のようにして推薦映画を決定できる。即ち、性質適合フィルタ部１２２は、音楽視聴と同様に映画視聴でもユーザはニッチ志向で狭く深いという性向があると解釈して、その解釈に基づいて、例えば、推薦候補の中からメジャー志向度の低い映画を推薦映画として決定することができる。
【０１７９】
これに対して、性質Bが性質tmpとは異なる場合、即ち、ユーザの音楽視聴の性向と映画視聴の性向とが非類似の場合、具体的には例えば、性質B＝メジャー志向＆広い＆浅いである場合、ユーザは、音楽視聴にはこだわりがあるが、映画視聴にはこだわりがない性向に有ると解釈できる。従って、性質適合フィルタ部１２２は、この解釈に基づいて、例えば、推薦候補とは別に、一般的なヒット作も推薦映画に含め、嗜好候補（嗜好Bに類似する映画）の推薦は全体推薦数の例えば２割程度に止める、といった推薦を行うことができる。
【０１８０】
なお、このように、映画推薦エンジン１１２による推薦が嗜好Bと性質Bとを用いて行われる場合、そのような推薦を、以下、嗜好Bと性質Bに基づく推薦と称する。
【０１８１】
以上の映画推薦サーバ１０２とクライアント機器１０１とによる一連の処理（以下、映画推薦処理と称する）の詳細例が、図１４のフローチャートに示されている。
【０１８２】
ステップＳ１において、クライアント機器１０１は、好みの映画が選択されたか否かを判定する。
【０１８３】
好みの映画が選択されていないと判定された場合、再びステップＳ１の判定処理が実行される。即ち、クライアント機器１０１側で好みの映画が選択されるまでの間、ステップＳ１の判定処理が繰り返され、その後、クライアント機器１０１側で好みの映画が選択されると、ステップＳ１の処理でＹＥＳであると判定されて、処理はステップＳ２に進む。
【０１８４】
この場合、好みの映画が再生部１３３により再生されて、そのメタ情報が履歴情報として履歴蓄積部１３４に蓄積される。そこで、ステップＳ２において、クライアント機器１０１の嗜好抽出部１３５は、その履歴情報を用いて嗜好Bを計算し、嗜好プロファイル蓄積部１３６に蓄積させる。
【０１８５】
ステップＳ３において、映画推薦サーバ１０２の映画推薦エンジン１１２は、性質tmpをセットする。性質tmpとは、上述したように、音楽再生機器であるクライアント機器１により生成された性質、即ち、楽曲についてのユーザの性質であって、クライアント機器１から転送されて、クライアント機器１０１側の性質プロファイル蓄積部１３８に蓄積されているものである。ここで、性質tmpをセットするとは、映画推薦エンジン１１２が、性質プロファイル蓄積部１３８から性質tmpを読み出して、自身に転送させて保持することをいう。
【０１８６】
ステップＳ４において、映画推薦エンジン１１２は、クライアント機器１０１の履歴数が２０未満であるか否かを判定する。この履歴数の管理は、クライアント機器１０１側で行ってもよいし、映画推薦サーバ１０２側で行ってもよい。ここでは、履歴数は、クライアント機器１０１の再生部１３３等により管理され、図１３には図示はしないが、映画推薦エンジン１１２に対して通信等により通知されるとする。
【０１８７】
なお、ステップＳ４の判定基準となる閾値２０は例示であり、別の閾値が採用されてもよい。
【０１８８】
履歴数が２０を超えていない場合、ステップＳ４において、ＹＥＳであると判定されて、処理はステップＳ６に進む。
【０１８９】
ステップＳ６において、映画推薦エンジン１１２は、miss（ユーザが推薦を受け付けなかった回数を示す値）が５個未満であるか否かを判定する。このmissの管理は、クライアント機器１０１側で行ってもよいし、映画推薦サーバ１０２側で行ってもよい。ここでは、missは、上述した履歴数とともに、クライアント機器１０１の再生部１３３等により管理され、図１３には図示はしないが、映画推薦エンジン１１２に対して通信等により通知されるとする。
【０１９０】
なお、ステップＳ６の判定基準となる閾値５は例示であり、別の閾値が採用されてもよい。
【０１９１】
missが５個未満である場合、ステップＳ６において、ＹＥＳであると判定され、処理はステップＳ８に進む。ステップＳ８において、映画推薦エンジン１１２は、上述した嗜好Bと性質tmpに基づく推薦を行う。
【０１９２】
これに対して、missが５個以上である場合、ステップＳ６において、ＮＯであると判定され、処理はステップＳ７に進む。ステップＳ７において、映画推薦エンジン１１２は、上述した嗜好Bに基づく推薦を行う。
【０１９３】
また、履歴数が２０以上の場合、ステップＳ４において、ＮＯであると判定され、処理はステップＳ５に進む。ステップＳ５において、映画推薦エンジン１１２は、上述した嗜好Bと性質Bに基づく推薦を行う。
【０１９４】
ステップＳ５，Ｓ７，Ｓ８のうちの何れかの推薦処理により決定された推薦映画が、クライアント機器１０１に提供され、方略決定部１３１により決定された推薦方略で推薦提示部１３２により提示されると、処理はステップＳ９に進む。
【０１９５】
ステップＳ９において、クライアント機器１０１の再生部１３３は、推薦が受け入れられたか否かを判定する。
【０１９６】
ユーザから推薦映画の再生指示がなされなかった場合、再生部１３３は、ステップＳ９において、推薦が受け入れられなかったと判定し、ステップＳ１０において、missを１だけインクリメントする。その後、処理はステップＳ４に戻され、それ以降の処理が繰り返される。
【０１９７】
これに対して、ユーザから推薦映画の再生指示がなされた場合、再生部１３３は、ステップＳ９において、推薦が受け入れられたと判定し、推薦映画を再生するとともに、その推薦映画のメタ情報を履歴蓄積部１３４に蓄積させる。すると、処理はステップＳ１１に進む。
【０１９８】
ステップＳ１１において、嗜好抽出部１３５は、直前のステップＳ９の処理で推薦が受け入れられた推薦映画のメタ情報も含めた履歴蓄積部１３４の履歴情報に基づいて、嗜好Bを計算し、嗜好プロファイル蓄積部１３６に蓄積させる。即ち、嗜好Bの内容が更新される。
【０１９９】
また、ステップＳ１２において、性質抽出部１３７は、直前のステップＳ９の処理で推薦が受け入れられた推薦映画のメタ情報も含めた履歴蓄積部１３４の履歴情報に基づいて、性質Bを計算し、性質プロファイル蓄積部１３８に蓄積させる。即ち、性質Bの内容が更新される。
【０２００】
ステップＳ１３において、再生部１３３は、履歴数を１だけインクリメントする。その後、処理はステップＳ４に戻され、それ以降の処理が繰り返される。
【０２０１】
図１５は、ステップＳ５の嗜好Bと性質Bに基づく推薦処理の具体例として、性質tmp＝ニッチ志向＆狭い＆深いの場合の処理例を説明するフローチャートである。
【０２０２】
ステップＳ２１において、映画推薦エンジン１１２は、クライアント機器１０１の性質プロファイル蓄積部１３８に蓄積されている性質Bと性質tmpとを比較して、性質B=性質tmpであるか否かを判定する。
【０２０３】
性質B＝ニッチ志向＆狭い＆深いの場合、ステップＳ２１において性質B＝性質tmpであると判定されて、処理はステップＳ２２に進む。ステップＳ２２において、映画推薦エンジン１１２は、嗜好Bでニッチな推薦を行う。これにより、図１４のステップＳ５の処理が終了し、処理はステップＳ９に進むことになる。
【０２０４】
なお、ステップＳ２２でいう「嗜好Bでニッチな推薦」とは、例えば、嗜好Bにより決定された推薦候補の中からメジャー志向度の低いものを、推薦映画として選抜することを意味する。
【０２０５】
性質Bが（ニッチ志向＆狭い＆深い）以外の場合、ステップＳ２１において性質B＝性質tmpではないと判定されて、処理はステップＳ２３に進む。ステップＳ２３において、映画推薦エンジン１１２は、性質B＝メジャー志向＆広い＆浅いであるか否かを判定する。
【０２０６】
性質B＝メジャー志向＆広い＆浅いの場合、ステップＳ２３においてＹＥＳであると判定されて、処理はステップＳ２４に進む。ステップＳ２４において、映画推薦エンジン１１２は、ヒット作８０％で嗜好B推薦２０％となる推薦を行う。これにより、図１４のステップＳ５の処理が終了し、処理はステップＳ９に進むことになる。
【０２０７】
なお、ステップＳ２４でいう「ヒット作８０％で嗜好B推薦２０％となる推薦」とは、例えば、メジャー志向度の高い映画が「ヒット作」を意味し、嗜好Bにより決定された推薦候補が「嗜好B推薦」を意味するとして、推薦映画全体のうちのヒット作が８０％を占めて嗜好B推薦が２０％を占めるように、推薦映画を決定することを意味する。
【０２０８】
性質Bが（ニッチ志向＆狭い＆深い）と（メジャー志向＆広い＆浅い）以外の場合、ステップＳ２３においてＮＯであると判定されて、処理はステップＳ２５に進む。ステップＳ２５において、映画推薦エンジン１１２は、嗜好Bと性質Bとに応じた推薦を行う。これにより、図１４のステップＳ５の処理が終了し、処理はステップＳ９に進むことになる。
【０２０９】
以上の図１４や図１５の例の映画推薦処理は、コンテンツの種類が映画の場合を想定した処理例であったが、実際には、コンテンツの種類は特に限定されない。即ち、コンテンツの第１の種類についての性質を性質tmpとして、コンテンツの第２の種類についての性質を性質Bとして、また、コンテンツの第２の種類についての嗜好情報を嗜好Bとすることで、第２の種類のコンテンツの推薦を行う処理として、図１４や図１５の例の映画推薦処理をそのまま適用することができる。
【０２１０】
また、図１４や図１５の映画推薦処理を実行可能なシステムは、図１３の情報処理システムに特に限定されない。ここに、システムとは、複数の装置や処理部により構成される装置全体を表すものである。
【０２１１】
即ち、映画推薦サーバ１０２とクライアント機器１０１とを１つの装置と捉えることもできる。
【０２１２】
換言すると、映画推薦サーバ１０２の構成要素である映画アイテムデータベース１１１と映画推薦エンジン１１２とは、映画推薦サーバ１０２に搭載させる必要は特になく、クライアント機器１０１側に搭載させてもよいし、図１３には図示せぬ別の装置に搭載させてもよい。何れの場合であっても、図１４や図１５の映画推薦処理を実行可能であることは明らかである。以上の映画推薦サーバ１０２とクライアント機器１０１との関係は、楽曲推薦サーバ２とクライアント機器１との関係にも全く同様に当てはまるし、図１３には図示しない所定の種類のコンテンツについての推薦サーバと再生用クライアント機器との関係にも全く同様に当てはまる。
【０２１３】
また、図示はしないが、楽曲推薦サーバ２や映画推薦サーバ１０２等の推薦サーバは、性質の生成機能を有しない第１のクライアント機器に対しても、性質の生成機能を有する別の第２のクライアント機器で得られた性質を利用することで、推薦を行うことができる。即ち、推薦サーバは、第１のクライアント機器で得られた嗜好と、第２のクライアント機器で得られた性質とを用いた推薦を行うこともできる。
【０２１４】
さらに、性質情報の用途は、上述した用途に限定されず、ユーザのコンテンツに対する振る舞いの性向を利用可能な様々な用途となり得る。
【０２１５】
具体的には例えば、性質情報は、次のようなフリーキーワードの用途として利用することもできる。
【０２１６】
即ち、第１のクライアント機器は、各種性質情報とともに、コンテンツの種類、嗜好に関するフリーキーワードを要素とするベクトル（以下、フリーキーワード性質ベクトルFDと称する）を生成し、例えば、フリーキーワードをkwγ（γは１以上の値）として、フリーキーワード性質ベクトルFD = (o, w, d, kind, kw1, kw2,…)を生成して、第２のクライアント機器に伝送することもできる。
【０２１７】
この場合、第２のクライアント機器は、フリーキーワード性質ベクトルFDの各要素を各属性に検索をかけて、マッチした場合にはその属性の値として登録することができるので、フリーキーワード性質ベクトルFDを、初期のユーザ嗜好情報の作成を手助けするために利用できる。例えば、フリーキーワード性質ベクトルFDのうちのキーワードの部分が（kw1 , kw2 , kw3 , kw4 ） = (音楽、サンバ、カエ○×△ ヴ△××ゾ、ロマンチック)であり、第２のクライアント機器に対応する推薦サーバが楽曲推薦サーバだった場合は、容易に、ジャンル-{サンバ},人名-{カエ○×△ ヴ△××ゾ}が結びつき、さらにムード-{ロマンチック}もムード属性を有するサーバによっては結びつくことになる。
【０２１８】
以上説明したように、本発明においては、詳細なユーザ嗜好情報自体を複数の機器間で共有するのでなく、ユーザ嗜好情報の生成元となる履歴情報から統計処理により得られたユーザの性質（1以上の性質情報群）を複数の機器間で共有することができる。これにより、一機器で得たユーザの性質を活用して、その一機器のみならず別の機器でもコンテンツ推薦を独自に行うこともできるし、別の種類のコンテンツ推薦も独自に行うことができるようになる。
【０２１９】
換言すると、例えば、一機器で得たコンテンツに対するユーザの振る舞いの性向を、他の機器でも活用できるようになる。また、コンテンツの種類の領域を横断した推薦（例えば音楽から映画など）が可能となる。また、これらの何れもが、厳密な規格なしに、またそれ故機器独自の解釈と利用方法を許す形で実現できる。即ち、例えば、性質情報自体は同一情報であっても、第１の機器では第１の解釈をして、第１の解釈を用いた処理を実行できる一方、第１の機器から性質情報を得た第２の機器では第２の解釈をして、第２の解釈を用いた処理を独自に実行できるようになる。
【０２２０】
ところで、上述した一連の処理は、ハードウエアにより実行させることもできるが、ソフトウエアにより実行させることができる。
【０２２１】
この場合、上述したクライアント機器やサーバ等の少なくとも一部として、例えば、図１６に示されるパーソナルコンピュータを採用してもよい。
【０２２２】
図１６において、CPU（Central Processing Unit）２０１は、ROM（Read Only Memory）２０２に記録されているプログラム、または記憶部２０８からRAM（Random Access Memory）２０３にロードされたプログラムに従って各種の処理を実行する。RAM２０３にはまた、CPU２０１が各種の処理を実行する上において必要なデータなども適宜記憶される。
【０２２３】
CPU２０１、ROM２０２、およびRAM２０３は、バス２０４を介して相互に接続されている。このバス２０４にはまた、入出力インタフェース２０５も接続されている。
【０２２４】
入出力インタフェース２０５には、キーボード、マウスなどよりなる入力部２０６、ディスプレイなどよりなる出力部２０７、ハードディスクなどより構成される記憶部２０８、および、モデム、ターミナルアダプタなどより構成される通信部２０９が接続されている。通信部２０９は、インターネットを含むネットワークを介して他の装置（図示せず）との間で行う通信を制御する。
【０２２５】
入出力インタフェース２０５にはまた、必要に応じてドライブ２１０が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどよりなるリムーバブルメディア２１１が適宜装着され、それらから読み出されたコンピュータプログラムが、必要に応じて記憶部２０８にインストールされる。
【０２２６】
一連の処理をソフトウエアにより実行させる場合には、そのソフトウエアを構成するプログラムが、専用のハードウエアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどに、ネットワークや記録媒体からインストールされる。
【０２２７】
このようなプログラムを含む記録媒体は、図１６に示されるように、装置本体とは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されている磁気ディスク（フロッピディスクを含む）、光ディスク（CD-ROM(Compact Disk-Read Only Memory),DVD(Digital Versatile Disk)を含む）、光磁気ディスク（ＭＤ（Mini-Disk）を含む）、もしくは半導体メモリなどよりなるリムーバブルメディア（パッケージメディア）２１１により構成されるだけでなく、装置本体に予め組み込まれた状態でユーザに提供される、プログラムが記録されているROM２０２や、記憶部２０８に含まれるハードディスクなどで構成される。
【０２２８】
なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、その順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
【０２２９】
また、本明細書において、システムとは、複数の装置や処理部により構成される装置全体を表すものである。
【図面の簡単な説明】
【０２３０】
【図１】本発明が適用される情報処理システムの構成例を示す図である。
【図２】メタデータを分類するクラスタとクラスタ層の概念、即ち多視点クラスタの概念を示す図である。
【図３】クラスタ情報の一例を示す図である。
【図４】クラスタ−楽曲ＩＤ情報の一例を示す図である。
【図５】クラスタリング第１乃至第４手法から２種類の手法を選択する方法を説明するための図である。
【図６】クラスタリング第１乃至第４手法から２種類の手法を選択する方法を説明するための図である。
【図７】クラスタリング第１乃至第４手法から２種類の手法を選択する方法を説明するための図である。
【図８】クラスタリング第１乃至第４手法から２種類の手法を選択する方法を説明するための図である。
【図９】クラスタリング第１乃至第４手法から２種類の手法を選択する方法を説明するための図である。
【図１０】性質情報の生成手法を説明するために利用する図であって、多視点クラスタの結果の具体例を示す図である。
【図１１】性質情報の生成手法を説明するために利用する図であって、多視点クラスタの結果の具体例を示す図である。
【図１２】性質情報を利用したコンテンツ選択の具体例を示す図である。
【図１３】本発明が適用される情報処理システムの別の構成例を示す図である。
【図１４】図１３の情報処理システムが実行する映画推薦処理例を説明するフローチャートである。
【図１５】図１４のステップＳ５に対応する嗜好Bと性質Bに基づく推薦処理の具体例を説明するフローチャートである。
【図１６】本発明が適用される情報処理装置としてのパーソナルコンピュータの構成例を示すブロック図である。
【符号の説明】
【０２３１】
１ クライアント機器， ２ 楽曲推薦サーバ， ３ 楽曲配信管理サーバ， １１ 楽曲アイテムデータベース， １２ 楽曲推薦エンジン， ２１ 類似度演算部， ２２ 性質適合フィルタ部， ３１ 方略決定部， ３２ 推薦提示部， ３３ 再生部， ３４ 履歴蓄積部， ３５ 嗜好抽出部， ３６ 嗜好プロファイル蓄積部， ３７ 性質抽出部， ３８ 性質プロファイル蓄積部， ３９ 通信部， １０１ クライアント機器， １０２ 映画推薦サーバ， １１１ 楽曲アイテムデータベース， １１２ 楽曲推薦エンジン， １２１ 類似度演算部， １２２ 性質適合フィルタ部， １３１ 方略決定部， １３２ 推薦提示部， １３３ 再生部， １３４ 履歴蓄積部， １３５ 嗜好抽出部， １３６ 嗜好プロファイル蓄積部， １３７ 性質抽出部， １３８ 性質プロファイル蓄積部， １３９ 通信部， ２０１ CPU， ２０２ ROM， ２０３ RAM， ２０８ 記憶部， ２１１ リムーバブルメディア
【技術分野】
【０００１】
本発明は、情報処理装置および方法並びにプログラムに関し、特に、一機器から得られた所定の種類のコンテンツについてのユーザの情報を、別の種類のコンテンツの推薦や、別の機器での推薦に活用できるようになった、情報処理装置および方法並びにプログラムに関する。
【背景技術】
【０００２】
従来、ユーザの嗜好に基づいて、テレビジョン番組、楽曲などのコンテンツを検索し、ユーザに推薦するための発明、いわゆるコンテンツパーソナライゼーションのための発明が提案されている（例えば、特許文献１参照）。
【０００３】
コンテンツパーソナライゼーションには、協調フィルタリングと称される手法（以下、CF手法とも称する）や、コンテントベーストフィルタリングと称される手法(以下、CBF手法とも称する)が広く使われている。
【０００４】
CF手法とは、各ユーザのコンテンツの購入履歴をユーザ嗜好情報として管理し、コンテンツを推薦しようとする第１のユーザに対し、購入履歴が似ている別の第２のユーザを検出して、その第２のユーザが購入しており、かつ、第１のユーザが購入していないコンテンツを推薦する、といった手法であり、例えば、インターネット上の通信販売サイトにおいて採用されている。
【０００５】
また、CBF手法とは、コンテンツに対して配信側や販売側によって予め付与されているメタデータを直接的に嗜好の抽出やコンテンツの推薦に利用する、といった手法である。即ち、ユーザ嗜好情報として、各種メタデータをベクトル化した特徴ベクトルを利用し、ユーザ嗜好情報を示す特徴ベクトル（ユーザ嗜好ベクトルとも称する）と、候補となる各コンテンツの特徴ベクトルとの距離（余弦相関など）を算出し、算出された距離の短いコンテンツを、ユーザの嗜好に合致したコンテンツであるとして推薦する、といった手法である。
【特許文献１】特開２００４−１９４１０７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、CF手法においてもCBF手法においても、ユーザの購入履歴やユーザ嗜好ベクトルといったユーザ嗜好情報は、ユーザが使用する一機器から抽出されている。換言すると、従来の機器は、それぞれ独自にユーザ嗜好情報を抽出している。従って、ある機器でせっかく得たユーザ嗜好情報が、別の機器では全く利用ができないという事態が問題となっている。
【０００７】
この問題に対して、嗜好表現のスキーマを統一するというアプローチが考えられるが、例えばテレビジョン番組、楽曲、映画などのコンテンツの種類毎に、メタデータの形式がそれぞれ異なっており、さらに、同じ種類のコンテンツを取り扱う場合にも、今度は機器側の形式がそれぞれ異なっているため、現実的とはいえない。
【０００８】
本発明は、このような状況に鑑みてなされたものであり、一機器から得られた所定の種類のコンテンツについてのユーザの情報を、別の種類のコンテンツの推薦や、別の機器での推薦に活用できるようにするものである。
【課題を解決するための手段】
【０００９】
本発明の一側面の情報処理装置は、所定の種類のコンテンツに対して処理を実行する情報処理装置であって、前記所定の種類のコンテンツに対する前記処理に関するユーザの振る舞いの履歴を示す履歴情報に基づいて、その所定の種類のコンテンツについての前記ユーザの性質を表す性質情報を１以上生成する性質生成手段と、前記性質生成手段により生成された１以上の前記性質情報を送信する通信手段とを備える。
【００１０】
前記性質生成手段は、前記性質情報として、志向、広さ、深さ、および成熟度のうちの少なくとも１つを生成する。
【００１１】
前記性質生成手段は、前記履歴情報から把握される１以上のコンテンツの性質に基づいて、前記志向を生成する。
【００１２】
前記性質生成手段は、前記履歴情報から把握されるコンテンツのそれぞれを複数のコンテンツ属性に分類した場合における前記複数のコンテンツ属性毎の値の個数とエントロピーとに基づいて、前記広さと前記深さとのうちの少なくとも一方を生成する。
【００１３】
前記性質生成手段は、前記複数のコンテンツ属性として、多視点クラスタを利用する。
【００１４】
前記性質生成手段は、前記履歴情報から把握される１以上のコンテンツのそれぞれを複数のコンテンツ属性に分類した場合における前記複数のコンテンツ属性毎の値の個数とエントロピーとに基づいて、前記成熟度を生成する。
【００１５】
前記性質生成手段は、さらに、前記履歴情報から把握される１以上のコンテンツの性質に基づいて前記成熟度を生成する。
【００１６】
前記性質生成手段は、前記履歴情報を期間で区切り、区切られた前記期間のうちの所定期間についての履歴情報に基づいて前記成熟度を生成する。
【００１７】
前記性質生成手段は、１以上の前記性質情報の全てを正規化する。
【００１８】
前記通信手段は、１以上の前記性質情報とともに、コンテンツの前記所定の種類を示す情報を関連付けて送信する。
【００１９】
前記性質生成手段により生成された１以上に前記性質情報を保持する保持手段をさらに備え、前記通信手段は、さらに、別の情報処理装置から送信された１以上の前記性質情報を受信し、前記保持手段は、さらに、前記通信手段に受信された１以上の前記性質情報を、前記情報処理装置自身についての性質情報として保持する。
【００２０】
前記通信手段に受信された１以上の前記性質情報は、前記情報処理装置の処理対象の前記所定の種類とは別の種類のコンテンツについての性質情報である。
【００２１】
前記通信手段は、１以上の前記性質情報に対して、フリーキーワードを関連付けて送信する。
【００２２】
本発明の一側面の情報処理方法は、所定の種類のコンテンツに対して処理を実行する情報処理装置の情報処理方法であって、前記所定の種類のコンテンツに対する前記処理に関するユーザの振る舞いの履歴を示す履歴情報に基づいて、その所定の種類のコンテンツについての前記ユーザの性質を表す性質情報を１以上生成し、生成された１以上の前記性質情報を、前記情報処理装置から別の情報処理装置に送信する制御を行うステップを含む。
【００２３】
本発明の一側面のプログラムは、上述した本発明の一側面の情報処理方法に対応するプログラムである。
【００２４】
本発明の一側面の情報処理装置および方法、並びにプログラムにおいては、所定の種類のコンテンツに対して処理を実行する情報処理装置が対象となり、次のような処理が実行される。即ち、前記所定の種類のコンテンツに対する前記処理に関するユーザの振る舞いの履歴を示す履歴情報に基づいて、その所定の種類のコンテンツについての前記ユーザの性質を表す性質情報が１以上生成されて、前記情報処理装置から別の情報処理装置に送信される。
【発明の効果】
【００２５】
以上のごとく、本発明によれば、ユーザ嗜好情報そのものではなく、ユーザ嗜好情報の元となる履歴情報から、ユーザの性質を表す性質情報を得ることが可能になる。これにより、一機器から得られたこの性質情報を活用して、別の種類のコンテンツの推薦や、別の機器での推薦ができるようになる。
【発明を実施するための最良の形態】
【００２６】
以下に本発明の実施の形態を説明するが、本発明の構成要件と、発明の詳細な説明に記載の実施の形態との対応関係を例示すると、次のようになる。この記載は、本発明をサポートする実施の形態が、発明の詳細な説明に記載されていることを確認するためのものである。従って、発明の詳細な説明中には記載されているが、本発明の構成要件に対応する実施の形態として、ここには記載されていない実施の形態があったとしても、そのことは、その実施の形態が、その構成要件に対応するものではないことを意味するものではない。逆に、実施の形態が構成要件に対応するものとしてここに記載されていたとしても、そのことは、その実施の形態が、その構成要件以外の構成要件には対応しないものであることを意味するものでもない。
【００２７】
さらに、この記載は、発明の実施の形態に記載されている具体例に対応する発明が、請求項に全て記載されていることを意味するものではない。換言すれば、この記載は、発明の実施の形態に記載されている具体例に対応する発明であって、この出願の請求項には記載されていない発明の存在、すなわち、将来、分割出願されたり、補正により追加される発明の存在を否定するものではない。
【００２８】
本発明の一側面の情報処理装置（例えば図１のクライアント機器１や図１３のクライアント機器１０１）は、
所定の種類のコンテンツに対する処理（例えば図１のクライアント機器１については楽曲の再生等の処理であり、図１３のクライアント機器１０１については映画の再生等の処理）を実行する情報処理装置において、
前記所定の種類のコンテンツに対する前記処理に関するユーザの振る舞いの履歴を示す履歴情報（例えば図１の履歴蓄積部３４や図１３の履歴蓄積部１３４に蓄積された履歴情報）に基づいて、その所定の種類のコンテンツについての前記ユーザの性質を表す性質情報を１以上生成する性質生成手段（例えば図１の性質抽出部３７や図１３の性質抽出部１３７）と、
前記性質生成手段により生成された１以上の前記性質情報を送信する通信手段（例えば図１の通信部３９や図１３の通信部１３９）と
を備える。
【００２９】
前記性質生成手段は、前記性質情報として、志向、広さ、深さ、および成熟度のうちの少なくとも１つを生成する（例えば、図１２の例では、志向o，広さw，深さdを要素とする性質ベクトルD=(o , w , d)を生成する）。
【００３０】
前記性質生成手段は、前記履歴情報から把握される１以上のコンテンツの性質（例えば図１０の例では、楽曲m1乃至m4が、ユーザの振る舞い（視聴や購入）により履歴の対象となったコンテンツ、即ち、履歴情報から把握されるコンテンツであり、それらの楽曲m1乃至m4の被ダウンロード数）に基づいて、前記志向を生成する。
【００３１】
前記性質生成手段は、前記履歴情報から把握されるコンテンツのそれぞれを複数のコンテンツ属性に分類した場合における前記複数のコンテンツ属性毎の値（例えば図１０の例では、楽曲m1乃至m4が、ユーザの振る舞い（視聴や購入）により履歴の対象となったコンテンツ、即ち、履歴情報から把握されるコンテンツであり、これらの楽曲m1乃至m4が、各コンテンツ属性を示す各クラスタのうちの1以上に分類された結果を示す小さな丸印、即ち、View1乃至View3の各クラスタに存在する小さな丸印）の個数とエントロピーとに基づいて、前記広さと前記深さとのうちの少なくとも一方を生成する。
【００３２】
前記性質生成手段は、前記複数のコンテンツ属性として、多視点クラスタ（例えば図１０の３つのView1乃至View3のそれぞれに楕円として示されている各クラスタ）を利用する。
【００３３】
前記性質生成手段は、前記履歴情報から把握される１以上のコンテンツのそれぞれを複数のコンテンツ属性に分類した場合における前記複数のコンテンツ属性毎の値（例えば図１１の例では、楽曲mnが、ユーザの振る舞い（視聴や購入）により履歴の対象となったコンテンツ、即ち、履歴情報から把握されるコンテンツであり、この楽曲mnが、各コンテンツ属性を示す各クラスタのうちの1以上に分類された結果を示す小さな丸印、即ち、View1，View2の各クラスタに存在する小さな丸印）の個数とエントロピーとに基づいて、前記成熟度を生成する。
【００３４】
前記性質生成手段により生成された１以上の前記性質情報を保持する保持手段（例えば図１の性質プロファイル蓄積部３８や図１３の性質プロファイル蓄積部１３８）をさらに備え、
前記通信手段は、さらに、別の情報処理装置から送信された１以上の前記性質情報を受信し（図１３の通信部１３９参照）、
前記保持手段は、さらに、前記通信手段に受信された１以上の前記性質情報を、前記情報処理装置自身についての性質情報として保持する。
【００３５】
本発明の一側面の情報処理方法は、
所定の種類のコンテンツに対する処理を実行する情報処理装置（例えば図１のクライアント機器１や図１３のクライアント機器１０１）の情報処理方法であって、
前記所定の種類のコンテンツに対する前記処理に関するユーザの振る舞いの履歴を示す履歴情報に基づいて、その所定の種類のコンテンツについての前記ユーザの性質を表す性質情報を１以上生成し（例えば図１の性質抽出部３７や図１３の性質抽出部１３７の処理）、
生成された１以上の前記性質情報を、前記情報処理装置から別の情報処理装置に送信する（例えば図１の通信部３９や図１３の通信部１３９の処理）
ステップを含む情報処理方法。
【００３６】
本発明の一側面のプログラムは、上述した本発明の一側面の情報処理方法に対応するプログラムであって、例えば図１６のコンピュータにより実行される。
【００３７】
このように、本発明ではコンテンツを取り扱うことができる。ここに、コンテンツとは、広く、人間の創造的活動により生み出されるものである。例えば、映画、音楽、演劇、文芸、写真、漫画、アニメーション、コンピュータゲームその他の文字、図形、色彩、音声、動作若しくは映像若しくはこれらを組み合わせたものまたはこれらに係る情報を電子計算機を介して提供するためのプログラムが、コンテンツの一例である。ただし、本明細書では、いわゆるコンテンツデータ、即ち、人間の創造的活動により生み出されたものが装置によって処理可能な形態とされたもの、例えば電気信号とされたものや、メモリに固定されたもの等も、特に区別せずにまとめて、コンテンツと称する。
【００３８】
以下、図面を参照して、本発明の実施の形態について説明する。
【００３９】
図１は、本発明が適用される情報処理システムの構成例を示している。
【００４０】
図１の例では、情報処理システムは、クライアント機器１、楽曲推薦サーバ２、および、楽曲配信管理サーバ３から構成されている。
【００４１】
なお、情報処理システムを構成するクライアント機器の台数は、図１の例ではクライアント機器１の1台のみであるが、図１の例に限定されず、１台以上であれば任意の台数でよい。実際には、多数のユーザが存在し、また、取り扱うコンテンツの種類も様々であることから、多数のクライアント機器が存在することになろう。
【００４２】
また、情報処理システムを構成するサーバも、図１の例では、楽曲推薦サーバ２と楽曲配信管理サーバ３とのみであるが、図１の例に限定されず、情報処理システムの用途や性質に応じたサーバを採用すればよい。
【００４３】
即ち、図１の例の情報処理システムの取り扱うコンテンツの種類は、音楽（楽曲）とされている。換言すると、図１の例の情報処理システムは、特に楽曲ダウンロードサービスにおける嗜好抽出を行うことが可能な情報処理システムとされている。それ故、図１の例では、楽曲推薦サーバ２と楽曲配信管理サーバ３とが設けられているのである。
【００４４】
なお、以下、説明の簡略上、クライアント機器１にダウンロードされて再生された楽曲を、そのクライアント機器１を使用するユーザにとっての好みの楽曲（以下、嗜好楽曲と称する）として取り扱うとする。
【００４５】
楽曲推薦サーバ２は、楽曲アイテムデータベース１１と楽曲推薦エンジン１２とを含むように構成されている。
【００４６】
楽曲アイテムデータベース１１には、ダウンロード可能な複数の楽曲がそのメタデータと関連付けられて蓄積されている。
【００４７】
なお、本実施の形態では、楽曲推薦サーバ２は、楽曲のダウンロードサービス自体も行うとしているため、楽曲アイテムデータベース１１には、ダウンロード対象の楽曲の実データ自体も蓄積されている。換言すると、楽曲のダウンロードサービスは別のサーバが行い、楽曲推薦サーバ２は、楽曲推薦のみを行うとした場合には、楽曲のメタデータのみを楽曲アイテムデータベース１１に蓄積させることができる。
【００４８】
また、以下、説明の簡略上、特に断りのない限り、楽曲が伝達されると表現した場合には、楽曲の実データとともに、そのメタデータも伝達されることを意味するとする。
【００４９】
楽曲推薦エンジン１２は、楽曲アイテムデータベース１１に蓄積されている複数の楽曲の中から、クライアント機器１を利用するユーザに推薦すべき楽曲（以下、推薦楽曲と称する）を選択し、クライアント機器１に提供する。このため、楽曲推薦エンジン１２は、類似度演算部２１と性質適合フィルタ部２２とを有している。
【００５０】
類似度演算部２１は、クライアント機器１の後述する嗜好プロファイル蓄積部３６に蓄積された嗜好プロファイルと類似する楽曲、即ち、クライアント機器１のユーザの嗜好楽曲と類似する楽曲を、推薦楽曲の候補（以下、推薦候補と称する）として選択する。なお、類似度演算部２１の類似度演算手法は特に限定されず、例えば、各楽曲のメタデータをベクトル化して、それらの各ベクトル間のCosine距離等で類似度を演算する、といった手法を採用できる。
【００５１】
性質適合フィルタ部２２については、後述する。
【００５２】
楽曲配信管理サーバ３は、楽曲推薦サーバ２から配信される各楽曲に関する各種情報を管理する。具体的には例えば、楽曲配信管理サーバ３は、楽曲毎の被ダウンロード総数を管理することができる。即ち、上述したように、実際にはクライアント機器１のみならず、多数のクライアント機器が存在し、１つの楽曲は、それらの多数のクライアント機器のそれぞれに対して楽曲推薦サーバ２から個別配信される。そこで、楽曲配信管理サーバ３は、例えば、各楽曲毎に、楽曲推薦サーバ２から個別配信された回数をカウントし、そのカウント数を、その楽曲の被ダウンロード総数として管理することができる。かかる楽曲毎の被ダウンロード総数は、適宜、楽曲配信管理サーバ３からクライアント機器１に提供される。
【００５３】
クライアント機器１は、方略決定部３１乃至通信部３９を含むように構成されている。
【００５４】
方略決定部３１は、楽曲推薦サーバ２から配信された推薦楽曲の推薦方略を、後述する性質プロファイル蓄積部３８に蓄積された性質プロファイルに応じて決定し、推薦提示部３２に通知する。なお、推薦方略の具体例については、後述する。
【００５５】
推薦提示部３２は、楽曲推薦サーバ２から配信された推薦楽曲を、方略決定部３１により決定された推薦方略に基づいてユーザに提示する。より正確には、推薦楽曲の提示とは、推薦楽曲全体の再生による提示を意味する訳ではなく、例えば、推薦楽曲の一部分の再生による提示や、推薦楽曲のメタデータから生成される情報の提示、具体的には画像情報の表示による提示や、音声情報の音声出力による提示等を意味する。
【００５６】
ユーザが、この推薦を受け入れて、その推薦楽曲を視聴する指示をクライアント機器１に与えると（指示を受けるブロックは図示せず）、再生部３３は、指示された楽曲の再生を行う。
【００５７】
上述したように、再生部３３により再生された楽曲、即ち、ユーザが推薦を受け入れて視聴した楽曲が、本実施の形態では、ユーザの嗜好楽曲とみなされる。そこで、その嗜好楽曲に関する情報、例えば本実施の形態ではメタデータが、履歴情報として履歴蓄積部３４に蓄積される。
【００５８】
嗜好抽出部３５は、履歴蓄積部３４に蓄積された履歴情報から、ユーザ嗜好情報を抽出し、嗜好プロファイル蓄積部３６に蓄積させる。なお、ユーザ嗜好情報の抽出手法は、特に限定されず、例えば、CBF(Content Based Filtering)手法等を採用することができる。
【００５９】
一方、性質抽出部３７は、履歴蓄積部３４に蓄積された履歴情報から、楽曲についてのユーザの性質を表す1以上の情報（以下、性質情報と称する）を抽出し、性質プロファイル蓄積部３８に蓄積させる。
【００６０】
より一般的に性質情報について説明すると、所定の種類のコンテンツに対する一機器の処理に関するユーザの振る舞いの履歴から、その所定の種類のコンテンツについてのユーザの性質を表す性質情報が１以上生成されることになる。
【００６１】
ユーザの性質情報としては、例えば志向、広さ、深さ、および成熟度が採用可能であり、これらの性質情報のうちの少なくともひとつにより、所定の種類のコンテンツについてのユーザの性質が表現される。
【００６２】
志向とは、ユーザが好むコンテンツ自体がもっている大衆性を示す情報、具体的には例えば、大衆性の高いものであるのか、それともニッチなものであるのかといったことを示す情報をいう。
【００６３】
広さや深さは、コンテンツを分類するクラスタとして事前に決められたクラスタ単位、例えばジャンル単位等でみたときにおけるユーザのコンテンツ経験（コンテンツの購買や視聴等の経験）の広さや深さを示すものである。広さとは、コンテンツ経験の範囲はどのくらい局所に集中しているのかといったことを示す情報をいう。広さの把握により、どのくらいの範囲までのコンテンツ推薦をユーザは許容するのかについての可能性等がわかる。深さとは、とあるクラスタ単位でみたとき、そのクラスタに属するコンテンツをユーザはどのくらい経験しつくしているのか、といったことを示す情報をいう。ここで、クラスタとは、一般的なジャンルに留まらず、個人の嗜好をよりよく表現できるように作成されたものも含む広義な概念である。なお、クラスタの具体例については後述する。
【００６４】
成熟度とは、広さと深さの両面を兼ね備えた指標をいう。例えば広さと深さを適切に掛け合わせたものを成熟度として採用することができる。さらに、志向であるニッチ性を加味したもの成熟度として採用することができる。例えば、ニッチ度を広さと深さのいずれかあるいは両方と適切に掛け合わせたものを成熟度として採用することもできる。さらに、時期で区切って、その時期に絞った範囲内で上述したように求めたものを成熟度として採用することができる。具体的には例えば、最近１年間のコンテンツ経験に絞って上述したように求めたものを成熟度として採用することができる。
【００６５】
以上の定義は、ユーザのコンテンツ経験の分布を捉えるものが性質であるとした場合の定義の一例であって、その分布を、志向、広さ、深さ、あるいは成熟度として把握する場合の定義である。
【００６６】
従って、性質の捉え方によっては、別の定義による性質情報を採用することもできる。具体的には例えば、性質はコンテンツ単位の他にアーティスト単位でも捉えることができ、このアーティストに着目して定義された性質情報を採用することもできる。
【００６７】
ここで、各性質情報の具体的な生成手法を説明する前に、その生成手法で必要となる履歴情報のクラスタリング手法について、図２乃至図９を参照して説明する。
【００６８】
性質抽出部３７は、履歴蓄積部３４に蓄積された全ての楽曲のメタデータの各項目（タイトル、アーティスト名、ジャンル、レビューテキスト、テンポ、ビート、リズム等）を、図２に示すようなクラスタ層（第１乃至ｎ層）のいずれかに分類し、各項目の実情報を分類したクラスタ層に設けられる複数のクラスタのいずれかに、楽曲を分類（クラスタリング）する。
【００６９】
なお、１つの楽曲を複数のクラスタに分類してもよい。同一クラスタ層に存在するクラスタ間の距離（類似の程度を示す）は既知であるものとする。このクラスタリングの手法については後述する。そして、性質抽出部３７は、メタデータの代わりに楽曲の特徴を示す情報として、メタデータの各項目の実情報を分類したクラスタのクラスタＩＤ（図２におけるＣＬ１１など）からなるクラスタ情報を生成して保持するか、履歴蓄積部３４等に蓄積させる。
【００７０】
なお、分類に適したクラスタが存在しない場合、新たにクラスタを新設してもよい。各クラスタのサイズは任意であって複数の楽曲を包含できるものである。なお、単一の楽曲だけしか分類することができないクラスタを設けてもよい。この場合、当該クラスタのクラスタＩＤに唯一分類可能な楽曲の実情報のＩＤ（アーティストＩＤ、アルバムＩＤ、タイトルＩＤ）を用いてもよい。
【００７１】
図３はクラスタ情報の一例を示している。同図においては、例えば、楽曲ＩＤ＝ABC123の楽曲のクラスタ情報は、クラスタＩＤ（ＣＬ１２、ＣＬ２１、ＣＬ３５，ＣＬ４７，ＣＬ５２，…，ＣＬｎ２）であることを示している。また例えば、楽曲ＩＤ＝CTH863の楽曲のクラスタ情報は、クラスタＩＤ（ＣＬ１１、ＣＬ２５、ＣＬ３１，ＣＬ４２，ＣＬ５３，…，ＣＬｎ１）であることを示している。
【００７２】
図４は、図３に示されたクラスタ情報に対応するクラスタ−楽曲ＩＤ情報の一例を示している。なお、同図のｉは、クラスタ層の第ｉ層を示している。同図においては、例えば、クラスタＩＤ＝ＣＬ１１には、楽曲ＩＤ＝CTH863が対応することを示している。また例えば、クラスタＩＤ＝ＣＬ２１には、楽曲ＩＤ＝ABC123が対応することを示している。
【００７３】
さらに以下、性質抽出部３７による楽曲（メタデータ）のクラスタリングについて説明
する。
【００７４】
クラスタリング手法はいかなる手法でもかまわないが、クラスタ層毎に最適なクラスタリング手法、距離尺度を選ぶようにする。例えば、メタデータの実情報が数値であるならばそのまま、タイトルなどの場合は主成分分析等の数量化手法を用いて数値にして、ユークリッド距離などの距離尺度を定義してクラスタリングすることになる。代表的なクラスタリング手法としては、K-means法、階層クラスタリング法などを挙げることができる。
【００７５】
この際、嗜好距離を反映したクラスタリング（例えば、制約付きクラスタリング）によって実施することが望ましい。そのためには、事前調査により部分的な正解集（嗜好的に近い実情報の集合、遠い実情報の集合など）を作り、それに適合する数値表現、距離、クラスタリング手法を用いるものとする。またさらに、形成される各クラスタ層の独立性が高くなるクラスタリング手法（すなわち、特性の異なるクラスタリング手法）を選ぶことが望ましい。
【００７６】
例えば４種類のクラスタリング手法（以下、第１乃至４手法と称する）の中から特性の
異なる２種類のクラスタリング手法を選択する方法について、図５乃至図９を参照して
説明する。
【００７７】
まず、性質抽出部３７は、第１乃至４手法によってメタデータの実情報であるアーティストＡ乃至Ｊをクラスタリングする。そして図５に示すような結果が得られたとする。
【００７８】
すなわち、第１手法により、アーティストＡ乃至ＣがクラスタＣＬ１に、アーティストＤ乃至ＧがクラスタＣＬ２に、アーティストＨ乃至ＪがクラスタＣＬ３にクラスタリングされ、第２手法により、アーティストＡ，ＢがクラスタＣＬ１に、アーティストＣ乃至ＦがクラスタＣＬ２に、アーティストＧ乃至ＪがクラスタＣＬ３にクラスタリングされ、第３手法により、アーティストＡ，Ｄ，Ｇ，ＪがクラスタＣＬ１に、アーティストＢ，Ｅ，ＨがクラスタＣＬ２に、アーティストＣ，Ｆ，ＩがクラスタＣＬ３にクラスタリングされ、第４手法により、アーティストＤ，Ｉ，ＪがクラスタＣＬ１に、アーティストＥ乃至ＧがクラスタＣＬ２に、アーティストＡ乃至ＣおよびＨがクラスタＣＬ３にクラスタリングされたとする。
【００７９】
この場合、第１乃至４手法による結果の重複率（％）は図６に示すとおりである。すなわち、第１手法と第２手法の重複率は０．８、第１手法と第３手法の重複率は０．３、第１手法と第４手法の重複率は０．４、第２手法と第３手法の重複率は０．３、第２手法と第４手法の重複率は０．３、第３手法と第４手法の重複率は０．４である。
【００８０】
図６に示された重複率が小さいほど２つの手法の特性が異なると考えられるので、重複率が最小値の０．３である組み合わせ、即ち、第１手法と第３手法の組み合わせ、第２手法と第３手法の組み合わせ、または第２手法と第４手法の組み合わせを採用することが望ましい。
【００８１】
一方、ユーザ自身によってアーティストＡ乃至Ｊのうちの二人が同じクラスタに分類されるべきであるか否かを判定させた場合、図７に示すような結果が得られたとする。ただし、同図において、１は同じクラスタに分類されるべきであることを、０は異なるクラスタに分類されるべきであることを意味する。すなわち、同図においては、例えば、アーティストＡがアーティストＢ，Ｃ，Ｆ，Ｈ，Ｉと同じクラスタに分類されるべきであると判断されたことが示されており、アーティストＢがアーティストＣ，Ｄ，Ｅ，Ｊと同じクラスタに分類されるべきであることが示されている。
【００８２】
図７に示された結果を、正解とする理想的なクラスタリング結果であるとするならば、上述した第１乃至４手法の正解率は図８に示すとおりである。すなわち、第１手法の正解率は６２．２％、第２手法の正解率は５５．６％、第３手法の正解率は４０．０％、第４手法の正解率は６６．７％である。
【００８３】
従って、正解率を重視するならば、正解率が高い第１手法と第４手法の組み合わせを採用することが望ましい。
【００８４】
さらに、重複率と正解率を加味したクラスタリング手法の組み合わせを求めるため、第１乃至４手法の正解の重複率を算出すれば、図９に示すとおりとなる。図８に示された各手法単体の正解率の結果から正解率が極端に低い手法を特定し、特定した当該手法を含まない組み合わせのうちの正解率の重複率が最も低い組み合わせを図９に示される結果から特定し、特定した当該組み合わせを採用すればよい。すなわち、正解率が極端に低い手法として、図８の正解率が４０．０％の第３手法が特定され、第３手法を含まない組み合わせのうちの正解の重複率が最も低いものとして、図９の２４．４％の第２手法と第３手法の組み合わせが選択される。
【００８５】
なお、上述した重複率や正解率については絶対的な閾値を指定して、それ閾値を満たすことができない手法を除外してもよいし、バランスがとれた手法を採用するために、２つの指標（重複率と正解率）に基づいて例えば、以下に示す２例のような総合的な指標を作成し、総合的な指標に基づいてクラスタリングの手法の組み合わせを選択するようにしてもよい。
総合的な指標＝正解率×（１−重複率）
総合的な指標＝α×正解率×β（１−重複率） （α，βは所定の係数）
【００８６】
このように、性質抽出部３７による楽曲（メタデータ）のクラスタリングの結果を用いることで、各クラスタ層のそれぞれに視点を移して、コンテンツ属性の把握を行うことができる。即ち、各クラスタ層に属する各クラスタのそれぞれは、そのクラスタ層に応じた複数のコンテンツ属性をそれぞれ示していると把握することもできる。
【００８７】
換言すると、以上説明した性質抽出部３７による楽曲（メタデータ）のクラスタリングは、多視点の複数のクラスタへの分類であるともいえる。そこで、以下、各クラスタ層をViewと適宜称する。ただし、各Viewのクラスタは、以下、必要に応じて多視点クラスタと称する場合もあるし、そのままクラスタと称する場合もある。
【００８８】
性質抽出部３７は、このようにして楽曲（メタデータ）のクラスタリングを行うと、その結果（以下、多視点クラスタリング結果と称する）を用いて、各性質情報を生成する。
【００８９】
そこで、以下、各性質情報の生成手法の具体例についてそれぞれ説明する。
【００９０】
ただし、以下、説明の簡略上、図１０に示される多視点クラスタリング結果を用いて説明を行っていく。即ち、図１０に示されるように、８個のクラスタ（図中楕円）をそれぞれ有するView1乃至View3のそれぞれに対して、小さな丸印で示される４つの楽曲m1乃至m4がクラスタリングされたとして、以下の説明を行っていく。ただし、図１０に示されるように、View1とView3では１つの楽曲m1乃至m4のそれぞれが２クラスタで表現されている一方、View2では１つの楽曲m1乃至m4のそれぞれが１クラスタ（ハードクラスタリング）で表現されている。このように、１つの楽曲が複数クラスタで表現され得るため、以下の説明では、楽曲数（図１０の例では４）ではなく、各クラスタに含まれる値（図１０の例では丸印）の数（以下、曲エントリ数と称する）を用いるとする。
【００９１】
はじめに、志向(以下oとも記述する)の生成手法について説明する。
【００９２】
ここで、とある時点での楽曲の被ダウンロード数のLogを正規化（0乃至1.0）したものを、楽曲のメジャー志向度として定義する。なお、楽曲の被ダウンロード数は、本実施の形態では上述したように、図１の楽曲配信管理サーバ３から通信部３９を介して性質抽出部３７に提供される。
【００９３】
この場合、性質抽出部３７は、ユーザのメジャー志向度を、そのユーザのダウンロード再生楽曲（図１の例では、履歴蓄積部３４にメタデータが蓄積された楽曲）のもつメジャー志向度の平均として求め、そのユーザのメジャー志向度を志向ｏとする。
【００９４】
この場合の正規化項は、全ユーザのメジャー志向度が正規分布になるように調整されるとする。ここに、全ユーザとは、図１のクライアント機器１を利用するユーザと、図１には図示されていない多数のクライアント機器をそれぞれ使用する多数のユーザとを加えた全ユーザをいう。ただし、実際は、正規化項は、実際はサンプリングにより求められるとする。なお、正規化する理由は、他の性質情報、即ち後述する広さ、深さ、成熟度等との尺度をあわせるためである。即ち、後述するように、他の性質情報もまた正規化されることになる。
【００９５】
具体的には例えば、図１０の例において、楽曲m1の被ダウンロード数が1024とされ、楽曲m2の被ダウンロード数が8とされ、楽曲m3の被ダウンロード数が64とされ、楽曲m4の被ダウンロード数が512とされ、また、正規化項が16だった(全楽曲のうちの最も多くダウンロードされた楽曲について、そのダウンロード数が65536だった)とする。
【００９６】
この場合、志向ｏは、次の式（１）のように演算されることになる。なお、以下の各式で記述するlogの底は２であるが、この底については省略されている。
【００９７】
【数１】
【００９８】
なお、上述した志向oの生成手法は例示に過ぎず、志向oの生成手法としては、その他例えば、楽曲のメジャー志向度として、正規化した各楽曲の有名度を採用してもよいし、各楽曲の売り上げ等のランキングを正規化したものを採用してもよい。
【００９９】
より一般的にいえば、楽曲のメジャー志向度とは、その楽曲の性質を表している。即ち、志向oの生成手法は、各コンテンツの性質に基づいて生成する手法であれば、特に限定されない。
【０１００】
次に、広さ(以下wとも記述する)の生成手法について説明する。
【０１０１】
性質抽出部３７は、多視点クラスタリング結果の各View毎にエントロピーを求める。View v（vは、層番号を示し、図１０の例では、１乃至３のうちの何れかの値である）のクラスタv-i（ｉは、クラスタの番号を示す）に属する曲エントリ数Sv-iを、全曲エントリ数S=ΣSv-iで割った値を Pv-i とするとき、View vのエントロピーEvは、次の式（２）に示される通りとなる。なお、図１０の例では、View vにおいて、左上端のクラスタの番号を１として、右方向に順次並ぶクラスタのそれぞれに対して番号２乃至４をそれぞれ付していき、その後、左下端のクラスタの番号を５として、右方向に順次並ぶクラスタのそれぞれに対して６乃至８をそれぞれ付していったとする。
【０１０２】
【数２】
【０１０３】
ただし、曲エントリ数が0（Pv-i=0）の場合は、クラスタ種類数nに応じた一定の微小値（例えば nの二乗）を入れて、Pv-iやEvは、次の式（３）乃至式（５）の通りに修正されるとする。
【０１０４】
【数３】
【０１０５】
そして、性質抽出部３７は、エントロピーEv の中で最小エントロピーEv-minを正規化した値を、広さwとして求める。正規化項は、クラスタ数で決まる最大エントロピーEmaxが1.0になるように調整されるとする。
【０１０６】
具体的には例えば、図１０のView1乃至View3のエントロピーE1乃至E3のそれぞれは、式（６）乃至式（８）のそれぞれのように求められる。従って、最小エントロピーEv-minは、式（９）に示される通りとなり、最大エントロピーEmaxは、式（１０）に示される通りとなる。その結果、広さwは、式（１１）に示される通りとなる。
【０１０７】
【数４】
【０１０８】
次に、深さ(以下ｄとも記述する)の生成手法について説明する。
【０１０９】
この場合、性質抽出部３７は、広さwの算出に利用した最小エントロピーEv-minを有するViewを特定し、そのViewにおける各クラスタのうちの、Pv-iが最大値をとるクラスタの曲エントリ数Sv-i-maxを正規化した値を、深さｄとして算出する。
【０１１０】
具体的には例えば、全ユーザの最大曲エントリ数Sv-i-max が100とすると、図１０の例ではView3が最小エントロピーEv-minを有するので、曲エントリ数Sv-i-maxは次の式（１２）に示される通りとなり、その結果、深さdは次の式（１３）に示される通りとなる。
【０１１１】
【数５】
【０１１２】
なお、上述した広さwや深さｄの生成手法は例示に過ぎず、その他、例えば、次のような広さwや深さｄの生成手法を採用することができる。
【０１１３】
即ち、上述した例では、多視点クラスタにマッピングされる対象は、履歴蓄積部３４に蓄積されている楽曲（以下、ユーザ所持楽曲とも称する）とされたが、図１の楽曲推薦サーバ２の楽曲アイテムデータベース１１の全楽曲を多視点クラスタにマッピングした結果を利用して、上述した広さwや深さｄを算出してもよい。
【０１１４】
ただし、全楽曲が多視点クラスタにマッピングされたときには、各多視点クラスタへの所属数は偏りを持ち、その偏り度合いはViewにより異なることになる。そこで、性質抽出部３７は、全楽曲がマッピングされたときのクラスタ所属比率でView間の正規化を行い、この正規化値を用いてエントロピーEvを求めるとよい。具体的には例えば、とあるView vでのクラスタv-iの所属数がni 、全所属数合計がNだったとき、Pv-i× (N/ni)が正規化されるとP'v-iとなるので、性質抽出部３７は、この値P'v-iを用いてエントロピーEvを求めるとよい。即ち、性質抽出部３７は、ユーザ所持楽曲による曲エントリ数Sv-iを用いてPv-iを求めて、そのPv-iを用いてP'v-i を求めるとよい。
【０１１５】
即ち、性質抽出部３７は、View vのエントロピーEvを求めるための値として、上述した値Pv-iの代わりに、次の式（１４）により算出される値P'v-iを利用して、エントロピーEvを求めることもできる。
【０１１６】
【数６】
【０１１７】
具体的には例えば、全楽曲が多視点クラスタにマッピングされた結果が図１１に示される通りであるとする。即ち、図１１に示されるように、２個のクラスタ（図中楕円）をそれぞれ有する２つのView１，２に対して、ユーザ所持楽曲mnを含む２以上の楽曲がクラスタリングされたとする。ただし、以下の説明でも、曲エントリ数、即ち、図１１中小さい丸印の数が用いられるとする。
【０１１８】
この場合、View1のエントロピーE1は、次の式（１５）乃至（１７）に示される通りに演算されることになる。
【０１１９】
【数７】
【０１２０】
一方、View2のエントロピーE2は、次の式（１８）乃至（２０）に示される通りに演算されることになる。
【０１２１】
【数８】
【０１２２】
従って、図１１の例では、E1 ＜ E2となる。
【０１２３】
上述した広さwや深さｄの生成手法もまた例示に過ぎない。即ち、広さwや深さｄの生成手法をより一般的にいうと、ユーザの履歴から把握されるコンテンツのそれぞれを複数のコンテンツ属性（上述した例では多視点クラスタ）に分類した場合における複数のコンテンツ属性毎の値の個数とエントロピーとに基づいて、広さwと深さdとのうちの少なくとも一方を生成する、といった手法が適用可能であり、かかる手法の具体例の幾つかについて上述したことになる。
【０１２４】
次に、成熟度(以下ｍとも記述する)の生成手法について説明する。
【０１２５】
即ち、上述した全楽曲についての多視点クラスタリング結果（例えば図１１に示される結果等）を用いてView間の正規化計算でエントロピーEvがそれぞれ演算され、その結果、最小エントロピーEv-minを持つViewが、View voとなったとする。
【０１２６】
この場合、このView voにおいて、クラスタvo-iのうちの全所属数をnaiとして、ユーザ所持楽曲の所属数をnuiとし、全クラスタ数をncとしたとき、性質抽出部３７は、次の式（２１）に従って、成熟度mを算出することができる。
【０１２７】
【数９】
【０１２８】
具体的には例えば、図１１の例では、成熟度mは、次の式（２２）に示されるように算出される。
【０１２９】
m=｛(1/3)+(1/1)｝/2 ＝ 2/3 ・・・（２２）
【０１３０】
なお、全ての楽曲がユーザ所持楽曲となっていた場合には、m=1.0となる。
【０１３１】
上述した成熟度ｍの生成手法もまた例示に過ぎない。即ち、上述したように、成熟度mとは、広さwと深さdの両面を兼ね備えた指標をいう。従って、上述したように、広さwや深さｄの生成手法としては、ユーザの履歴から把握されるコンテンツのそれぞれを複数のコンテンツ属性（上述した例では多視点クラスタ）に分類した場合における複数のコンテンツ属性毎の値の個数とエントロピーとに基づいて、広さwと深さdとのうちの少なくとも一方を生成する、といった手法が適用可能である。従って例えば、成熟度ｍもまた、ユーザの履歴から把握されるコンテンツのそれぞれを複数のコンテンツ属性に分類した場合における複数のコンテンツ属性毎の値の個数とエントロピーとに基づいて成熟度ｍを生成する、といった手法を採用することもできる。
【０１３２】
さらに、上述したように、成熟度mとして、広さwと深さdの両面を兼ね備えたものに対して、志向oであるニッチ性を加味したものを採用することもできる。この場合には例えば、志向oの生成手法として、上述したように、各コンテンツの性質に基づいて志向ｏを生成する手法を採用できることを考慮すると、成熟度ｍの生成手法としては、上述した手法に加えて、さらに、履歴情報から把握される１以上のコンテンツの性質に基づいて成熟度ｍを生成するという手法を加えたものを採用することもできる。
【０１３３】
或いはまた例えば、上述したように、所定の時期に絞った範囲内で成熟度ｍを求めることもできる。即ち例えば、ユーザの履歴を期間で区切り、区切られた期間のうちの所定期間についてのユーザの履歴から把握されるコンテンツのそれぞれを複数のコンテンツ属性に分類した場合における複数のコンテンツ属性毎の値の個数とエントロピーとに基づいて成熟度ｍを生成する、いった手法を採用することもできる。
【０１３４】
このようにして、性質抽出部３７は、各性質情報を算出することができる。そこで、性質抽出部３７は、さらに、このようにして算出した各性質情報のうちの１以上を要素とするベクトル（以下、性質ベクトルと称する）、例えば、志向o、広さw、深さdを各要素とする性質ベクトルD=（o, w, d）を生成し、その性質ベクトルDを、ユーザの性質プロファイルとして性質プロファイル蓄積部３８に蓄積させることができる。例えば上述した図１０の例では、性質ベクトルD= （o, w, d）=(0.4375, 0.37, 0.04)が算出され、性質プロファイル蓄積部３８に蓄積されることになる。
【０１３５】
なお、性質ベクトルの次元および各要素のそれぞれは、性質ベクトルDに特に限定されない。例えば、広さwや深さdの代わりに、成熟度mを一要素とする性質ベクトルを採用してもよい。
【０１３６】
また、上述した例では、全楽曲を均等に扱うことで、性質ベクトルDが生成されているが、全楽曲を均等に扱う必要は特にない。例えば、性質抽出部３７は、楽曲のジャンル単位で、上述した一連の処理を行うことで、ジャンル毎の性質ベクトルを生成して、それらをユーザの性質プロファイルとして性質プロファイル蓄積部３８に蓄積させることもできる。
【０１３７】
なお、以下の説明では、説明の簡略上、性質抽出部３７は、志向o、広さw、深さdそのものの値を使用するのではなく、それらの値を適当な閾値で２値化し、２値化後の各値を各要素とする性質ベクトルDを生成し、性質プロファイル蓄積部３８に蓄積させるとする。
【０１３８】
この場合、志向oについては、１は、「メジャー志向」を示す値であり、０は「ニッチ志向」を示す値である。広さwについては、１は、「広い」を示す値であり、０は、「狭い」を示す値である。深さｄについては、１は、「深い」を示す値であり、０は、「浅い」を示す値である。
【０１３９】
例えば上述した図１０の例では、各性質情報としては、o=0.4375, w=0.37, d=0.04が算出されるので、閾値を0.5 としたときには、性質ベクトルD=（0,0,0）= (ニッチ志向、狭い、浅い)が得られて、性質プロファイル蓄積部３８に蓄積される。
【０１４０】
ここで、図１の楽曲推薦エンジン１２の性質適合フィルタ部２２は、性質ベクトルDの意味を解釈するための情報として、例えば図１２に示される情報を有しているとする。この場合、性質適合フィルタ部２２は、この図１２の情報を用いて、性質プロファイル蓄積部３８に蓄積されている性質ベクトルDの意味を簡単に解釈することができるようになる。
【０１４１】
その結果、性質適合フィルタ部２２は、類似度演算部２１の類似度演算により決定された1以上の推薦候補の中から、性質ベクトルDの意味に適合した楽曲を推薦楽曲として選抜し（フィルタリングし）、選抜した推薦楽曲を、クライアント機器１に対して提供することができる。
【０１４２】
或いは、性質適合フィルタ部２２は、性質ベクトルDの意味によっては、推薦候補となっていない楽曲を、別途推薦楽曲として決定することもできる。例えば、o＝メジャー志向であれば、ユーザ嗜好情報と類似しない楽曲（推薦候補に選ばれなかった楽曲）であったとしても、性質適合フィルタ部２２は、メジャー志向度の高い楽曲、例えば現在ヒット中の楽曲等を、推薦楽曲として決定することができる。
【０１４３】
具体的には例えば、図１０の例では、性質ベクトルD= (ニッチ志向、狭い、浅い)が得られて、性質プロファイル蓄積部３８に蓄積されている。従って、性質適合フィルタ部２２は、この性質ベクトルDの意味するところの「楽曲についてのユーザの性質」は、図１２の情報から、基本的に「ニッチ」であると判断できるが、視聴楽曲（経験）が少ないことによる「偶然？」の結果かもしれない、という解釈を行う。この場合、例えば、性質適合フィルタ部２２は、この解釈に基づいて、類似度演算部２１の類似度演算により決定された1以上の推薦候補のうちの、即ち、ユーザ嗜好情報に類似する１以上の楽曲のうちの、メジャー志向度の低い楽曲を、推薦楽曲としてクライアント機器１に提供することができる。ただし、性質適合フィルタ部２２は、d=浅いということも考慮して、例えば、基本として、最小エントロピーEv-minをもつViewのクラスタをはずさない範囲での選抜（フィルタリング）を行うとする。
【０１４４】
また例えば、性質ベクトルD= (ニッチ志向、広い、深い)が性質プロファイル蓄積部３８に蓄積されている場合には、性質適合フィルタ部２２は、次のような処理を実行することができる。即ち、性質適合フィルタ部２２は、この性質ベクトルDの意味するところの「楽曲についてのユーザの性質」は、図１２の情報から、基本的に「ニッチ好き」であるが、楽曲の視聴範囲は「守備範囲広い」であり、楽曲を視聴することに対して「貪欲」である、という解釈を行う。この場合、例えば、性質適合フィルタ部２２は、この解釈に基づいて、類似度演算部２１の類似度演算により決定された1以上の推薦候補のうちの、即ち、ユーザ嗜好情報に類似する１以上の楽曲のうちの、メジャー志向度の低い楽曲を、推薦楽曲としてクライアント機器１に提供することができる。ただし、この場合、性質適合フィルタ部２２は、w=広い，d=深いということも考慮して、例えば、基本として、適当に履歴のあるクラスタ間を飛ばすような選抜（フィルタリング）を行うとする。
【０１４５】
このようにして、性質ベクトルD= (ニッチ志向、広い、深い)の解釈に基づく推薦楽曲がクライアント機器１に提供されてきた場合、後述する方略決定部３１は、例えば、その推薦楽曲に適切な薀蓄情報をつけて提示する、という推薦方略を決定することができる。さらに、ユーザが、その推薦を受け入れた場合、即ち、その推薦楽曲が再生されて、履歴蓄積部３４に蓄積された場合、性質適合フィルタ部２２は、さらにクラスタ内でメジャー志向度の低い楽曲を推薦楽曲として選抜することで、「深くなり得る」というユーザの性向を満足させることができる。
【０１４６】
また例えば、性質ベクトルD= (メジャー志向、広い、浅い)が性質プロファイル蓄積部３８に蓄積されている場合には、性質適合フィルタ部２２は、次のような処理を実行することができる。即ち、性質適合フィルタ部２２は、この性質ベクトルDの意味するところの「楽曲についてのユーザの性質」は、図１２の情報から、基本的にメジャー志向、即ち「ミーハー」であるが、推薦範囲は「売れ筋でOK」である、という解釈を行う。この場合、例えば、性質適合フィルタ部２２は、この解釈に基づいて、類似度演算部２１の類似度演算により決定された推薦候補に拘らず、即ち、ユーザ嗜好情報に類似する楽曲に拘らず、ヒット曲などのメジャー志向度の高い楽曲を推薦楽曲に加えてクライアント機器１に提供することができる。また、性質適合フィルタ部２２は、w=広い，d=浅いということも考慮して、例えば、推薦候補からの推薦楽曲の選抜数は、推薦楽曲全体のうちの２割程度にとどめることとする。即ち、残りの８割の推薦楽曲は、ヒット曲などのメジャー志向度の高い楽曲となる。
【０１４７】
このようにして、ユーザの性質ベクトルDに応じた推薦楽曲が、楽曲推薦サーバ２からクライアント機器１の方略決定部３１に提供されると、方略決定部３１は、このユーザの性質ベクトルD、即ち、性質プロファイル蓄積部３８に蓄積されている性質ベクトルDを用いて、推薦楽曲の提示の方略を決定することができる。
【０１４８】
この提示の方略手法も、特に限定されず、例えば、性質適合フィルタ部２２と同様に図１２の情報を用いることができるとすれば、方略決定部３１は、その図１２の情報から性質ベクトルDの意味を解釈し、その解釈に応じた方略を決定する、という手法を採用できる。具体的には例えば、性質ベクトルD=（o , 狭い，深い）の場合には、方略決定部３１は、集中的に狭く深く同種の楽曲を連続的に提示する、という方略に決定することができる。一方、例えば、性質ベクトルD=（o , 広い，浅い）の場合には、方略決定部３１は、なるべく広く浅く様々な楽曲を連続的に提示する、という方略に決定することができる。
【０１４９】
以上説明した性質情報、即ち、志向o,広さw，深さd,成熟度mは、クライアント機器１から他の機器に転送することも可能である。この場合の転送プロトコルは特に限定されない。例えば、一般にはSOAP（Simple Object Access Protocol）通信や、Memory Stick（商標）での受け渡しなどが考えられるが、機器同士で定めた規格でもかまわない。さらに、他の機器に転送する場合には、単なる性質ベクトルを転送するのではなく、性質情報に加えて、音楽、映画など、コンテンツの種類をコード化した情報を要素とするベクトル（以下、転送用性質ベクトルSDと称する）を転送すると好適である。
【０１５０】
そこで、以下、コンテンツの種類をコード化した情報をkindと記述し、転送用性質ベクトルSD=(o,w,d,kind)として、音楽再生機器であるクライアント機器１から、別の機器、例えば映画再生機器に転送する例について説明する。
【０１５１】
この場合、映画再生機器は、例えば図１３のクライアント機器１０１として構成されているとする。このクライアント機器１０１は、方略決定部１３１乃至通信部１３９を含むように構成されている。方略決定部１３１乃至通信部１３９のそれぞれは、クライアント機器１の方略決定部３１乃至通信部３９（図１）のそれぞれと基本的に同様の機能と構成を有している。
【０１５２】
ただし、処理対象のコンテンツの種類、即ち推薦や再生の対象となるコンテンツの種類が、クライアント機器１では楽曲（音楽）であるのに対して、クライアント機器１０１では映画である点が異なる。
【０１５３】
従って、クライアント機器１０１は、映画推薦サーバ１０２から推薦映画の提供を受ける。この映画推薦サーバ１０２は、映画アイテムデータベース１１１、並びに、類似度演算部１２１および性質適合フィルタ部１２２からなる映画推薦エンジン１１２から構成されている。映画アイテムデータベース１１１、並びに、類似度演算部１２１および性質適合フィルタ部１２２からなる映画推薦エンジン１１２のそれぞれは、楽曲推薦サーバ２の楽曲アイテムデータベース１１、並びに類似度演算部２１および性質適合フィルタ部２２からなる楽曲推薦エンジン１２（図１）のそれぞれと基本的に同様の機能と構成を有している。ただし、処理対象コンテンツの種類、即ち、推薦等の対象となるコンテンツの種類が、楽曲推薦サーバ２では楽曲（音楽）であるのに対して、映画推薦サーバ１０２では映画である点が異なる。
【０１５４】
この場合、クライアント機器１は、性質プロファイル蓄積部３８に蓄積されている性質情報、即ち、志向o,広さw，深さdと、kind=musicとを各要素とする転送用性質ベクトルSD=(o,w,d,kind)を生成して、通信部３９を介してクライアント機器１０１に転送することができる。
【０１５５】
クライアント機器１０１側の通信部１３９は、この転送用性質ベクトルSDを受信して、性質プロファイル蓄積部１３８に蓄積させる。これにより、映画再生機器であるクライアント機器１０１は、音楽再生機器であるクライアント機器１側で得られた性質情報、即ち、楽曲についてのユーザの性質を表す性質情報を、映画の推薦等にも利用できるようになる。
【０１５６】
以下、具体例として、クライアント機器１からクライアント機器１０１に転送された転送用性質ベクトルSD=(o,w,d,kind=music)のうちの、性質情報の３要素（以下、性質tmpと称する）が、o=ニッチ志向、w＝狭い、d＝深いであった場合の例について説明する。また、映画には、楽曲（音楽）と同様にメジャー志向度が付けられているとする。
【０１５７】
この場合、映画推薦サーバ１０２は、クライアント機器１０１の履歴情報の蓄積量の多少、即ち、ユーザがクライアント機器１０１を利用して視聴した映画の数の大小に応じて、例えば次のような推薦を行うことができる。
【０１５８】
先ず、クライアント機器１０１の履歴情報の蓄積量、即ち、履歴蓄積部１３４に蓄積されている履歴情報が少ない状態での映画の推薦例について説明する。
【０１５９】
クライアント機器１０１の性質抽出部１３７も、履歴蓄積部１３４から映画についての履歴情報を抽出して、その履歴情報を利用して、映画についての各種性質情報を生成（算出）することができる。なお、以下、このようにして、クライアント機器１０１側で生成された性質情報、即ち、映画についての志向o、広さd、深さd等により表される性質を、性質Bと称する。この性質Bもまた、性質プロファイル蓄積部１３８に蓄積される。
【０１６０】
このように、性質Bは、クライアント機器１０１の履歴情報に基づいて生成されるので、その履歴情報の蓄積量が少ない場合に生成される性質Bは、ユーザの映画視聴の性向を十分に反映できていないと判断できる。
【０１６１】
そこで、このような場合、映画推薦サーバ１０２の映画推薦エンジン１１２は、クライアント機器１０１の性質プロファイル蓄積部１３８に蓄積されている性質tmpを用いて、即ち、ユーザの映画視聴の性向を示す性質Bの代わりに音楽視聴の性向を示す性質tmpを用いて、推薦候補の中からまたはそれ以外から、推薦映画を決定することができる。
【０１６２】
ここでいう推薦候補とは、クライアント機器１０１の嗜好プロファイル蓄積部１３６に蓄積されている嗜好プロファイル、即ち映画についてのユーザ嗜好情報（以下、嗜好Bと称する）を用いて、映画推薦エンジン１１２の類似度演算部１２１により決定される映画をいう。即ち、ここでいう推薦候補とは、嗜好Bに類似する映画をいう。
【０１６３】
より具体的には例えば、クライアント機器１０１で１つの好みの映画が選択された場合、即ち、ユーザの好みの１つの映画の再生指示がなされ、その結果、その映画が再生部１３３により再生され、その映画のメタ情報が履歴蓄積部１３４に蓄積された場合、嗜好抽出部１３５は、その選択された映画に基づいて嗜好Bを生成し、嗜好プロファイル蓄積部１３６に蓄積させる。
【０１６４】
すると、映画推薦エンジン１１２の類似度演算部１２１は、映画アイテムデータベース１１１に蓄積されている映画の中から、その嗜好Bに類似する映画、即ち、クライアント機器１０１で最初に選択された１つの好みの映画に類似する映画を、推薦候補として決定する。
【０１６５】
そして、映画推薦エンジン１１２の性質適合フィルタ部１２２が、クライアント機器１０１の性質プロファイル蓄積部１３８に蓄積されている性質tmpを用いて、即ち、ユーザの映画視聴の性向を示す性質Bの代わりに音楽視聴の性向を示す性質tmpを用いて、推薦候補の中からまたはそれ以外から、推薦映画を決定することができる。
【０１６６】
ここでは、性質tmpは、o=ニッチ志向、w＝狭い、d＝深い（以下、このような表現を、性質tmp＝ニッチ志向＆狭い＆深いという表現で記述する）であるので、性質適合フィルタ部１２２は、音楽視聴と同様に映画視聴でもユーザはニッチ志向で狭く深いという性向があるであろうと解釈し、この解釈に基づいて、例えば、推薦候補の中から、クライアント機器１０１で最初に選択された１つの好みの映画と同一ジャンルの映画を推薦映画として決定したり、同一出演者が出ているメジャー志向度の低い映画を推薦映画として決定することができる。
【０１６７】
なお、このように、映画推薦エンジン１１２による推薦が嗜好Bと性質tmpとを用いて行われる場合、そのような推薦を、以下、嗜好Bと性質tmpに基づく推薦と称する。
【０１６８】
かかる推薦をユーザが受け入れた場合、即ち、かかる推薦により決定された推薦映画が、クライアント機器１０１に提供されて、方略決定部１３１により決定された推薦方略で推薦提示部１３２によりユーザに提示され、その提示を受けたユーザにより再生指示がなされて、再生部１３３により再生された場合、ユーザの音楽視聴の性向と映画視聴の性向とは類似していると判断できる。
【０１６９】
従って、ユーザに推薦が受け入れられる毎に、即ち、クライアント機器１０１で別の好みの映画が選択される毎に、映画推薦エンジン１１２は、嗜好Bと性質tmpに基づく推薦、即ち、性質tmpの属性と類似した映画の推薦を行っていくことを繰り返していけばよい。このような推薦の繰り返しにより、性質tmp＝ニッチ志向＆狭い＆深いにあった推薦、即ち、狭い範囲での深い推薦が実現されていく。
【０１７０】
これに対して、かかる推薦をユーザが受け入れなかった場合、即ち、かかる推薦により決定された推薦映画が、クライアント機器１０１に提供されて、方略決定部１３１により決定された推薦方略で推薦提示部１３２によりユーザに提示されたが、その再生指示がユーザによりなされず、その結果、再生部１３３による再生がなされなかった場合、ユーザの音楽視聴の性向と映画視聴の性向とは非類似の可能性があると判断できる。
【０１７１】
即ち、ユーザが推薦を受け入れないことが何回かあった場合には、例えば、推薦を受け付けない回数をmissと記述したとしてmissが所定回数（５回等）以上となった場合には、ユーザの音楽視聴の性向と映画視聴の性向とは非類似であると判断できる。
【０１７２】
そこで、このような場合、映画推薦エンジン１１２は、性質tmpを用いずに、嗜好Bのみを利用した推薦（以下、嗜好Bに基づく推薦と称する）を行う。
【０１７３】
嗜好Bと性質tmpに基づく推薦と、嗜好Bに基づく推薦とのうちの何れの推薦がなされても、推薦がユーザに受け入れられる毎に、即ち、クライアント機器１０１で別の好みの映画が選択される毎に、クライアント機器１０１の履歴情報の蓄積量は増えていき、それに伴い、性質Bも更新されていく。即ち、性質Bは、ユーザの映画視聴の性向をだんだんと反映していく情報となっていく。
【０１７４】
従って、クライアント機器１０１の履歴情報の蓄積量が一定以上になった場合、例えば、その履歴情報の数（以下、履歴数と称する）が一定数（例えば２０）を超えた場合、映画推薦サーバ１０２の映画推薦エンジン１１２は、クライアント機器１０１の性質プロファイル蓄積部１３８に蓄積されている性質B、即ち、ユーザの映画視聴の性向を示す性質Bを用いて、推薦候補の中からまたはそれ以外から、推薦映画を決定することができる。
【０１７５】
この場合の推薦候補自体も、クライアント機器１０１の嗜好プロファイル蓄積部１３６に蓄積されている嗜好Bを用いて、映画推薦エンジン１１２の類似度演算部１２１により決定される。
【０１７６】
より具体的には例えば、映画推薦エンジン１１２の類似度演算部１２１は、映画アイテムデータベース１１１に蓄積されている映画の中から、その嗜好Bに類似する映画を、推薦候補として決定する。
【０１７７】
そして、映画推薦エンジン１１２の性質適合フィルタ部１２２は、クライアント機器１０１の性質プロファイル蓄積部１３８に蓄積されている性質Bを用いて、即ち、ユーザの映画視聴の性向を示す性質Bを用いて、推薦候補の中からまたはそれ以外から、推薦映画を決定する。
【０１７８】
この場合、例えば、性質Bと性質tmpとが同一である場合、即ち、ユーザの音楽視聴の性向と映画視聴の性向とがほぼ同様である場合、この例では、性質B＝ニッチ志向＆狭い＆深いの場合、性質適合フィルタ部１２２は、次のようにして推薦映画を決定できる。即ち、性質適合フィルタ部１２２は、音楽視聴と同様に映画視聴でもユーザはニッチ志向で狭く深いという性向があると解釈して、その解釈に基づいて、例えば、推薦候補の中からメジャー志向度の低い映画を推薦映画として決定することができる。
【０１７９】
これに対して、性質Bが性質tmpとは異なる場合、即ち、ユーザの音楽視聴の性向と映画視聴の性向とが非類似の場合、具体的には例えば、性質B＝メジャー志向＆広い＆浅いである場合、ユーザは、音楽視聴にはこだわりがあるが、映画視聴にはこだわりがない性向に有ると解釈できる。従って、性質適合フィルタ部１２２は、この解釈に基づいて、例えば、推薦候補とは別に、一般的なヒット作も推薦映画に含め、嗜好候補（嗜好Bに類似する映画）の推薦は全体推薦数の例えば２割程度に止める、といった推薦を行うことができる。
【０１８０】
なお、このように、映画推薦エンジン１１２による推薦が嗜好Bと性質Bとを用いて行われる場合、そのような推薦を、以下、嗜好Bと性質Bに基づく推薦と称する。
【０１８１】
以上の映画推薦サーバ１０２とクライアント機器１０１とによる一連の処理（以下、映画推薦処理と称する）の詳細例が、図１４のフローチャートに示されている。
【０１８２】
ステップＳ１において、クライアント機器１０１は、好みの映画が選択されたか否かを判定する。
【０１８３】
好みの映画が選択されていないと判定された場合、再びステップＳ１の判定処理が実行される。即ち、クライアント機器１０１側で好みの映画が選択されるまでの間、ステップＳ１の判定処理が繰り返され、その後、クライアント機器１０１側で好みの映画が選択されると、ステップＳ１の処理でＹＥＳであると判定されて、処理はステップＳ２に進む。
【０１８４】
この場合、好みの映画が再生部１３３により再生されて、そのメタ情報が履歴情報として履歴蓄積部１３４に蓄積される。そこで、ステップＳ２において、クライアント機器１０１の嗜好抽出部１３５は、その履歴情報を用いて嗜好Bを計算し、嗜好プロファイル蓄積部１３６に蓄積させる。
【０１８５】
ステップＳ３において、映画推薦サーバ１０２の映画推薦エンジン１１２は、性質tmpをセットする。性質tmpとは、上述したように、音楽再生機器であるクライアント機器１により生成された性質、即ち、楽曲についてのユーザの性質であって、クライアント機器１から転送されて、クライアント機器１０１側の性質プロファイル蓄積部１３８に蓄積されているものである。ここで、性質tmpをセットするとは、映画推薦エンジン１１２が、性質プロファイル蓄積部１３８から性質tmpを読み出して、自身に転送させて保持することをいう。
【０１８６】
ステップＳ４において、映画推薦エンジン１１２は、クライアント機器１０１の履歴数が２０未満であるか否かを判定する。この履歴数の管理は、クライアント機器１０１側で行ってもよいし、映画推薦サーバ１０２側で行ってもよい。ここでは、履歴数は、クライアント機器１０１の再生部１３３等により管理され、図１３には図示はしないが、映画推薦エンジン１１２に対して通信等により通知されるとする。
【０１８７】
なお、ステップＳ４の判定基準となる閾値２０は例示であり、別の閾値が採用されてもよい。
【０１８８】
履歴数が２０を超えていない場合、ステップＳ４において、ＹＥＳであると判定されて、処理はステップＳ６に進む。
【０１８９】
ステップＳ６において、映画推薦エンジン１１２は、miss（ユーザが推薦を受け付けなかった回数を示す値）が５個未満であるか否かを判定する。このmissの管理は、クライアント機器１０１側で行ってもよいし、映画推薦サーバ１０２側で行ってもよい。ここでは、missは、上述した履歴数とともに、クライアント機器１０１の再生部１３３等により管理され、図１３には図示はしないが、映画推薦エンジン１１２に対して通信等により通知されるとする。
【０１９０】
なお、ステップＳ６の判定基準となる閾値５は例示であり、別の閾値が採用されてもよい。
【０１９１】
missが５個未満である場合、ステップＳ６において、ＹＥＳであると判定され、処理はステップＳ８に進む。ステップＳ８において、映画推薦エンジン１１２は、上述した嗜好Bと性質tmpに基づく推薦を行う。
【０１９２】
これに対して、missが５個以上である場合、ステップＳ６において、ＮＯであると判定され、処理はステップＳ７に進む。ステップＳ７において、映画推薦エンジン１１２は、上述した嗜好Bに基づく推薦を行う。
【０１９３】
また、履歴数が２０以上の場合、ステップＳ４において、ＮＯであると判定され、処理はステップＳ５に進む。ステップＳ５において、映画推薦エンジン１１２は、上述した嗜好Bと性質Bに基づく推薦を行う。
【０１９４】
ステップＳ５，Ｓ７，Ｓ８のうちの何れかの推薦処理により決定された推薦映画が、クライアント機器１０１に提供され、方略決定部１３１により決定された推薦方略で推薦提示部１３２により提示されると、処理はステップＳ９に進む。
【０１９５】
ステップＳ９において、クライアント機器１０１の再生部１３３は、推薦が受け入れられたか否かを判定する。
【０１９６】
ユーザから推薦映画の再生指示がなされなかった場合、再生部１３３は、ステップＳ９において、推薦が受け入れられなかったと判定し、ステップＳ１０において、missを１だけインクリメントする。その後、処理はステップＳ４に戻され、それ以降の処理が繰り返される。
【０１９７】
これに対して、ユーザから推薦映画の再生指示がなされた場合、再生部１３３は、ステップＳ９において、推薦が受け入れられたと判定し、推薦映画を再生するとともに、その推薦映画のメタ情報を履歴蓄積部１３４に蓄積させる。すると、処理はステップＳ１１に進む。
【０１９８】
ステップＳ１１において、嗜好抽出部１３５は、直前のステップＳ９の処理で推薦が受け入れられた推薦映画のメタ情報も含めた履歴蓄積部１３４の履歴情報に基づいて、嗜好Bを計算し、嗜好プロファイル蓄積部１３６に蓄積させる。即ち、嗜好Bの内容が更新される。
【０１９９】
また、ステップＳ１２において、性質抽出部１３７は、直前のステップＳ９の処理で推薦が受け入れられた推薦映画のメタ情報も含めた履歴蓄積部１３４の履歴情報に基づいて、性質Bを計算し、性質プロファイル蓄積部１３８に蓄積させる。即ち、性質Bの内容が更新される。
【０２００】
ステップＳ１３において、再生部１３３は、履歴数を１だけインクリメントする。その後、処理はステップＳ４に戻され、それ以降の処理が繰り返される。
【０２０１】
図１５は、ステップＳ５の嗜好Bと性質Bに基づく推薦処理の具体例として、性質tmp＝ニッチ志向＆狭い＆深いの場合の処理例を説明するフローチャートである。
【０２０２】
ステップＳ２１において、映画推薦エンジン１１２は、クライアント機器１０１の性質プロファイル蓄積部１３８に蓄積されている性質Bと性質tmpとを比較して、性質B=性質tmpであるか否かを判定する。
【０２０３】
性質B＝ニッチ志向＆狭い＆深いの場合、ステップＳ２１において性質B＝性質tmpであると判定されて、処理はステップＳ２２に進む。ステップＳ２２において、映画推薦エンジン１１２は、嗜好Bでニッチな推薦を行う。これにより、図１４のステップＳ５の処理が終了し、処理はステップＳ９に進むことになる。
【０２０４】
なお、ステップＳ２２でいう「嗜好Bでニッチな推薦」とは、例えば、嗜好Bにより決定された推薦候補の中からメジャー志向度の低いものを、推薦映画として選抜することを意味する。
【０２０５】
性質Bが（ニッチ志向＆狭い＆深い）以外の場合、ステップＳ２１において性質B＝性質tmpではないと判定されて、処理はステップＳ２３に進む。ステップＳ２３において、映画推薦エンジン１１２は、性質B＝メジャー志向＆広い＆浅いであるか否かを判定する。
【０２０６】
性質B＝メジャー志向＆広い＆浅いの場合、ステップＳ２３においてＹＥＳであると判定されて、処理はステップＳ２４に進む。ステップＳ２４において、映画推薦エンジン１１２は、ヒット作８０％で嗜好B推薦２０％となる推薦を行う。これにより、図１４のステップＳ５の処理が終了し、処理はステップＳ９に進むことになる。
【０２０７】
なお、ステップＳ２４でいう「ヒット作８０％で嗜好B推薦２０％となる推薦」とは、例えば、メジャー志向度の高い映画が「ヒット作」を意味し、嗜好Bにより決定された推薦候補が「嗜好B推薦」を意味するとして、推薦映画全体のうちのヒット作が８０％を占めて嗜好B推薦が２０％を占めるように、推薦映画を決定することを意味する。
【０２０８】
性質Bが（ニッチ志向＆狭い＆深い）と（メジャー志向＆広い＆浅い）以外の場合、ステップＳ２３においてＮＯであると判定されて、処理はステップＳ２５に進む。ステップＳ２５において、映画推薦エンジン１１２は、嗜好Bと性質Bとに応じた推薦を行う。これにより、図１４のステップＳ５の処理が終了し、処理はステップＳ９に進むことになる。
【０２０９】
以上の図１４や図１５の例の映画推薦処理は、コンテンツの種類が映画の場合を想定した処理例であったが、実際には、コンテンツの種類は特に限定されない。即ち、コンテンツの第１の種類についての性質を性質tmpとして、コンテンツの第２の種類についての性質を性質Bとして、また、コンテンツの第２の種類についての嗜好情報を嗜好Bとすることで、第２の種類のコンテンツの推薦を行う処理として、図１４や図１５の例の映画推薦処理をそのまま適用することができる。
【０２１０】
また、図１４や図１５の映画推薦処理を実行可能なシステムは、図１３の情報処理システムに特に限定されない。ここに、システムとは、複数の装置や処理部により構成される装置全体を表すものである。
【０２１１】
即ち、映画推薦サーバ１０２とクライアント機器１０１とを１つの装置と捉えることもできる。
【０２１２】
換言すると、映画推薦サーバ１０２の構成要素である映画アイテムデータベース１１１と映画推薦エンジン１１２とは、映画推薦サーバ１０２に搭載させる必要は特になく、クライアント機器１０１側に搭載させてもよいし、図１３には図示せぬ別の装置に搭載させてもよい。何れの場合であっても、図１４や図１５の映画推薦処理を実行可能であることは明らかである。以上の映画推薦サーバ１０２とクライアント機器１０１との関係は、楽曲推薦サーバ２とクライアント機器１との関係にも全く同様に当てはまるし、図１３には図示しない所定の種類のコンテンツについての推薦サーバと再生用クライアント機器との関係にも全く同様に当てはまる。
【０２１３】
また、図示はしないが、楽曲推薦サーバ２や映画推薦サーバ１０２等の推薦サーバは、性質の生成機能を有しない第１のクライアント機器に対しても、性質の生成機能を有する別の第２のクライアント機器で得られた性質を利用することで、推薦を行うことができる。即ち、推薦サーバは、第１のクライアント機器で得られた嗜好と、第２のクライアント機器で得られた性質とを用いた推薦を行うこともできる。
【０２１４】
さらに、性質情報の用途は、上述した用途に限定されず、ユーザのコンテンツに対する振る舞いの性向を利用可能な様々な用途となり得る。
【０２１５】
具体的には例えば、性質情報は、次のようなフリーキーワードの用途として利用することもできる。
【０２１６】
即ち、第１のクライアント機器は、各種性質情報とともに、コンテンツの種類、嗜好に関するフリーキーワードを要素とするベクトル（以下、フリーキーワード性質ベクトルFDと称する）を生成し、例えば、フリーキーワードをkwγ（γは１以上の値）として、フリーキーワード性質ベクトルFD = (o, w, d, kind, kw1, kw2,…)を生成して、第２のクライアント機器に伝送することもできる。
【０２１７】
この場合、第２のクライアント機器は、フリーキーワード性質ベクトルFDの各要素を各属性に検索をかけて、マッチした場合にはその属性の値として登録することができるので、フリーキーワード性質ベクトルFDを、初期のユーザ嗜好情報の作成を手助けするために利用できる。例えば、フリーキーワード性質ベクトルFDのうちのキーワードの部分が（kw1 , kw2 , kw3 , kw4 ） = (音楽、サンバ、カエ○×△ ヴ△××ゾ、ロマンチック)であり、第２のクライアント機器に対応する推薦サーバが楽曲推薦サーバだった場合は、容易に、ジャンル-{サンバ},人名-{カエ○×△ ヴ△××ゾ}が結びつき、さらにムード-{ロマンチック}もムード属性を有するサーバによっては結びつくことになる。
【０２１８】
以上説明したように、本発明においては、詳細なユーザ嗜好情報自体を複数の機器間で共有するのでなく、ユーザ嗜好情報の生成元となる履歴情報から統計処理により得られたユーザの性質（1以上の性質情報群）を複数の機器間で共有することができる。これにより、一機器で得たユーザの性質を活用して、その一機器のみならず別の機器でもコンテンツ推薦を独自に行うこともできるし、別の種類のコンテンツ推薦も独自に行うことができるようになる。
【０２１９】
換言すると、例えば、一機器で得たコンテンツに対するユーザの振る舞いの性向を、他の機器でも活用できるようになる。また、コンテンツの種類の領域を横断した推薦（例えば音楽から映画など）が可能となる。また、これらの何れもが、厳密な規格なしに、またそれ故機器独自の解釈と利用方法を許す形で実現できる。即ち、例えば、性質情報自体は同一情報であっても、第１の機器では第１の解釈をして、第１の解釈を用いた処理を実行できる一方、第１の機器から性質情報を得た第２の機器では第２の解釈をして、第２の解釈を用いた処理を独自に実行できるようになる。
【０２２０】
ところで、上述した一連の処理は、ハードウエアにより実行させることもできるが、ソフトウエアにより実行させることができる。
【０２２１】
この場合、上述したクライアント機器やサーバ等の少なくとも一部として、例えば、図１６に示されるパーソナルコンピュータを採用してもよい。
【０２２２】
図１６において、CPU（Central Processing Unit）２０１は、ROM（Read Only Memory）２０２に記録されているプログラム、または記憶部２０８からRAM（Random Access Memory）２０３にロードされたプログラムに従って各種の処理を実行する。RAM２０３にはまた、CPU２０１が各種の処理を実行する上において必要なデータなども適宜記憶される。
【０２２３】
CPU２０１、ROM２０２、およびRAM２０３は、バス２０４を介して相互に接続されている。このバス２０４にはまた、入出力インタフェース２０５も接続されている。
【０２２４】
入出力インタフェース２０５には、キーボード、マウスなどよりなる入力部２０６、ディスプレイなどよりなる出力部２０７、ハードディスクなどより構成される記憶部２０８、および、モデム、ターミナルアダプタなどより構成される通信部２０９が接続されている。通信部２０９は、インターネットを含むネットワークを介して他の装置（図示せず）との間で行う通信を制御する。
【０２２５】
入出力インタフェース２０５にはまた、必要に応じてドライブ２１０が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどよりなるリムーバブルメディア２１１が適宜装着され、それらから読み出されたコンピュータプログラムが、必要に応じて記憶部２０８にインストールされる。
【０２２６】
一連の処理をソフトウエアにより実行させる場合には、そのソフトウエアを構成するプログラムが、専用のハードウエアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどに、ネットワークや記録媒体からインストールされる。
【０２２７】
このようなプログラムを含む記録媒体は、図１６に示されるように、装置本体とは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されている磁気ディスク（フロッピディスクを含む）、光ディスク（CD-ROM(Compact Disk-Read Only Memory),DVD(Digital Versatile Disk)を含む）、光磁気ディスク（ＭＤ（Mini-Disk）を含む）、もしくは半導体メモリなどよりなるリムーバブルメディア（パッケージメディア）２１１により構成されるだけでなく、装置本体に予め組み込まれた状態でユーザに提供される、プログラムが記録されているROM２０２や、記憶部２０８に含まれるハードディスクなどで構成される。
【０２２８】
なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、その順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
【０２２９】
また、本明細書において、システムとは、複数の装置や処理部により構成される装置全体を表すものである。
【図面の簡単な説明】
【０２３０】
【図１】本発明が適用される情報処理システムの構成例を示す図である。
【図２】メタデータを分類するクラスタとクラスタ層の概念、即ち多視点クラスタの概念を示す図である。
【図３】クラスタ情報の一例を示す図である。
【図４】クラスタ−楽曲ＩＤ情報の一例を示す図である。
【図５】クラスタリング第１乃至第４手法から２種類の手法を選択する方法を説明するための図である。
【図６】クラスタリング第１乃至第４手法から２種類の手法を選択する方法を説明するための図である。
【図７】クラスタリング第１乃至第４手法から２種類の手法を選択する方法を説明するための図である。
【図８】クラスタリング第１乃至第４手法から２種類の手法を選択する方法を説明するための図である。
【図９】クラスタリング第１乃至第４手法から２種類の手法を選択する方法を説明するための図である。
【図１０】性質情報の生成手法を説明するために利用する図であって、多視点クラスタの結果の具体例を示す図である。
【図１１】性質情報の生成手法を説明するために利用する図であって、多視点クラスタの結果の具体例を示す図である。
【図１２】性質情報を利用したコンテンツ選択の具体例を示す図である。
【図１３】本発明が適用される情報処理システムの別の構成例を示す図である。
【図１４】図１３の情報処理システムが実行する映画推薦処理例を説明するフローチャートである。
【図１５】図１４のステップＳ５に対応する嗜好Bと性質Bに基づく推薦処理の具体例を説明するフローチャートである。
【図１６】本発明が適用される情報処理装置としてのパーソナルコンピュータの構成例を示すブロック図である。
【符号の説明】
【０２３１】
１ クライアント機器， ２ 楽曲推薦サーバ， ３ 楽曲配信管理サーバ， １１ 楽曲アイテムデータベース， １２ 楽曲推薦エンジン， ２１ 類似度演算部， ２２ 性質適合フィルタ部， ３１ 方略決定部， ３２ 推薦提示部， ３３ 再生部， ３４ 履歴蓄積部， ３５ 嗜好抽出部， ３６ 嗜好プロファイル蓄積部， ３７ 性質抽出部， ３８ 性質プロファイル蓄積部， ３９ 通信部， １０１ クライアント機器， １０２ 映画推薦サーバ， １１１ 楽曲アイテムデータベース， １１２ 楽曲推薦エンジン， １２１ 類似度演算部， １２２ 性質適合フィルタ部， １３１ 方略決定部， １３２ 推薦提示部， １３３ 再生部， １３４ 履歴蓄積部， １３５ 嗜好抽出部， １３６ 嗜好プロファイル蓄積部， １３７ 性質抽出部， １３８ 性質プロファイル蓄積部， １３９ 通信部， ２０１ CPU， ２０２ ROM， ２０３ RAM， ２０８ 記憶部， ２１１ リムーバブルメディア
【特許請求の範囲】
【請求項１】
所定の種類のコンテンツに対する処理を実行する情報処理装置において、
前記所定の種類のコンテンツに対する前記処理に関するユーザの振る舞いの履歴を示す履歴情報に基づいて、その所定の種類のコンテンツについての前記ユーザの性質を表す性質情報を１以上生成する性質生成手段と、
前記性質生成手段により生成された１以上の前記性質情報を送信する通信手段と
を備える情報処理装置。
【請求項２】
前記性質生成手段は、前記性質情報として、志向、広さ、深さ、および成熟度のうちの少なくとも１つを生成する
請求項１に記載の情報処理装置。
【請求項３】
前記性質生成手段は、前記履歴情報から把握される１以上のコンテンツの性質に基づいて、前記志向を生成する
請求項２に記載の情報処理装置。
【請求項４】
前記性質生成手段は、前記履歴情報から把握される１以上のコンテンツのそれぞれを複数のコンテンツ属性に分類した場合における前記複数のコンテンツ属性毎の値の個数とエントロピーとに基づいて、前記広さと前記深さとのうちの少なくとも一方を生成する
請求項２に記載の情報処理装置。
【請求項５】
前記性質生成手段は、前記複数のコンテンツ属性として、多視点クラスタを利用する
請求項４に記載の情報処理装置。
【請求項６】
前記性質生成手段は、前記履歴情報から把握される１以上のコンテンツのそれぞれを複数のコンテンツ属性に分類した場合における前記複数のコンテンツ属性毎の値の個数とエントロピーとに基づいて、前記成熟度を生成する
請求項２に記載の情報処理装置。
【請求項７】
前記性質生成手段は、前記複数のコンテンツ属性として、多視点クラスタを利用する
請求項６に記載の情報処理装置。
【請求項８】
前記性質生成手段は、さらに、前記履歴情報から把握される１以上のコンテンツの性質に基づいて前記成熟度を生成する
請求項６に記載の情報処理装置。
【請求項９】
前記性質生成手段は、前記履歴情報を期間で区切り、区切られた前記期間のうちの所定期間についての履歴情報に基づいて前記成熟度を生成する
請求項６に記載の情報処理装置。
【請求項１０】
前記性質生成手段は、１以上の前記性質情報の全てを正規化する
請求項１に記載の情報処理装置。
【請求項１１】
前記通信手段は、１以上の前記性質情報とともに、コンテンツの前記所定の種類を示す情報を関連付けて送信する
請求項１に記載の情報処理装置。
【請求項１２】
前記性質生成手段により生成された１以上の前記性質情報を保持する保持手段をさらに備え、
前記通信手段は、さらに、別の情報処理装置から送信された１以上の前記性質情報を受信し、
前記保持手段は、さらに、前記通信手段に受信された１以上の前記性質情報を、前記情報処理装置自身についての性質情報として保持する
請求項１に記載の情報処理装置。
【請求項１３】
前記通信手段に受信された１以上の前記性質情報は、前記情報処理装置の処理対象の前記所定の種類とは別の種類のコンテンツについての性質情報である
請求項１２に記載の情報処理装置。
【請求項１４】
前記通信手段は、１以上の前記性質情報に対して、フリーキーワードを関連付けて送信する
請求項１に記載の情報処理装置。
【請求項１５】
所定の種類のコンテンツに対する処理を実行する情報処理装置の情報処理方法において、
前記所定の種類のコンテンツに対する前記処理に関するユーザの振る舞いの履歴を示す履歴情報に基づいて、その所定の種類のコンテンツについての前記ユーザの性質を表す性質情報を１以上生成し、
生成された１以上の前記性質情報を、前記情報処理装置から別の情報処理装置に送信する
ステップを含む情報処理方法。
【請求項１６】
所定の種類のコンテンツに対する処理を実行する機器を制御するコンピュータに実行させるプログラムであって、
前記所定の種類のコンテンツに対する前記処理に関するユーザの振る舞いの履歴を示す履歴情報に基づいて、その所定の種類のコンテンツについての前記ユーザの性質を表す性質情報を１以上生成し、
生成された１以上の前記性質情報を、前記機器から別の機器に送信させる制御を行う
ステップを含むプログラム。
【請求項１】
所定の種類のコンテンツに対する処理を実行する情報処理装置において、
前記所定の種類のコンテンツに対する前記処理に関するユーザの振る舞いの履歴を示す履歴情報に基づいて、その所定の種類のコンテンツについての前記ユーザの性質を表す性質情報を１以上生成する性質生成手段と、
前記性質生成手段により生成された１以上の前記性質情報を送信する通信手段と
を備える情報処理装置。
【請求項２】
前記性質生成手段は、前記性質情報として、志向、広さ、深さ、および成熟度のうちの少なくとも１つを生成する
請求項１に記載の情報処理装置。
【請求項３】
前記性質生成手段は、前記履歴情報から把握される１以上のコンテンツの性質に基づいて、前記志向を生成する
請求項２に記載の情報処理装置。
【請求項４】
前記性質生成手段は、前記履歴情報から把握される１以上のコンテンツのそれぞれを複数のコンテンツ属性に分類した場合における前記複数のコンテンツ属性毎の値の個数とエントロピーとに基づいて、前記広さと前記深さとのうちの少なくとも一方を生成する
請求項２に記載の情報処理装置。
【請求項５】
前記性質生成手段は、前記複数のコンテンツ属性として、多視点クラスタを利用する
請求項４に記載の情報処理装置。
【請求項６】
前記性質生成手段は、前記履歴情報から把握される１以上のコンテンツのそれぞれを複数のコンテンツ属性に分類した場合における前記複数のコンテンツ属性毎の値の個数とエントロピーとに基づいて、前記成熟度を生成する
請求項２に記載の情報処理装置。
【請求項７】
前記性質生成手段は、前記複数のコンテンツ属性として、多視点クラスタを利用する
請求項６に記載の情報処理装置。
【請求項８】
前記性質生成手段は、さらに、前記履歴情報から把握される１以上のコンテンツの性質に基づいて前記成熟度を生成する
請求項６に記載の情報処理装置。
【請求項９】
前記性質生成手段は、前記履歴情報を期間で区切り、区切られた前記期間のうちの所定期間についての履歴情報に基づいて前記成熟度を生成する
請求項６に記載の情報処理装置。
【請求項１０】
前記性質生成手段は、１以上の前記性質情報の全てを正規化する
請求項１に記載の情報処理装置。
【請求項１１】
前記通信手段は、１以上の前記性質情報とともに、コンテンツの前記所定の種類を示す情報を関連付けて送信する
請求項１に記載の情報処理装置。
【請求項１２】
前記性質生成手段により生成された１以上の前記性質情報を保持する保持手段をさらに備え、
前記通信手段は、さらに、別の情報処理装置から送信された１以上の前記性質情報を受信し、
前記保持手段は、さらに、前記通信手段に受信された１以上の前記性質情報を、前記情報処理装置自身についての性質情報として保持する
請求項１に記載の情報処理装置。
【請求項１３】
前記通信手段に受信された１以上の前記性質情報は、前記情報処理装置の処理対象の前記所定の種類とは別の種類のコンテンツについての性質情報である
請求項１２に記載の情報処理装置。
【請求項１４】
前記通信手段は、１以上の前記性質情報に対して、フリーキーワードを関連付けて送信する
請求項１に記載の情報処理装置。
【請求項１５】
所定の種類のコンテンツに対する処理を実行する情報処理装置の情報処理方法において、
前記所定の種類のコンテンツに対する前記処理に関するユーザの振る舞いの履歴を示す履歴情報に基づいて、その所定の種類のコンテンツについての前記ユーザの性質を表す性質情報を１以上生成し、
生成された１以上の前記性質情報を、前記情報処理装置から別の情報処理装置に送信する
ステップを含む情報処理方法。
【請求項１６】
所定の種類のコンテンツに対する処理を実行する機器を制御するコンピュータに実行させるプログラムであって、
前記所定の種類のコンテンツに対する前記処理に関するユーザの振る舞いの履歴を示す履歴情報に基づいて、その所定の種類のコンテンツについての前記ユーザの性質を表す性質情報を１以上生成し、
生成された１以上の前記性質情報を、前記機器から別の機器に送信させる制御を行う
ステップを含むプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【公開番号】特開２００８−１１７２２２（Ｐ２００８−１１７２２２Ａ）
【公開日】平成２０年５月２２日（２００８．５．２２）
【国際特許分類】
【出願番号】特願２００６−３００６３２（Ｐ２００６−３００６３２）
【出願日】平成１８年１１月６日（２００６．１１．６）
【出願人】（０００００２１８５）ソニー株式会社 (34,172)
【Ｆターム（参考）】
【公開日】平成２０年５月２２日（２００８．５．２２）
【国際特許分類】
【出願日】平成１８年１１月６日（２００６．１１．６）
【出願人】（０００００２１８５）ソニー株式会社 (34,172)
【Ｆターム（参考）】
[ Back to top ]