JP4645676B2 - 情報処理装置、関連アイテムの提供方法、及びプログラム - Google Patents

Description

本発明は、情報処理装置、関連アイテムの提供方法、及びプログラムに関する。

近年、情報処理技術、および通信技術の急速な発展に伴い、大量の情報がネットワークを通じて提供されるようになってきた。また、ユーザが保有する情報機器の形態が多様化する中で、多種多様な情報が提供されるようになってきている。例えば、インターネット等の広域ネットワークを介してパーソナルコンピュータ（以下、ＰＣ）等に配信される情報もあれば、テレビジョン受像機等に配信される放送番組や放送情報等もある。こうした状況に鑑み、膨大な情報の中からユーザが好む情報（以下、嗜好情報）を効率良く提供するための技術に注目が集まっている。例えば、ユーザの嗜好により良く適合する情報を漏れなく選択するための技術には高い関心が寄せられている。

こうした技術に関連し、例えば、下記の特許文献１には、個々のユーザの嗜好等を考慮し、より適切な情報をユーザに提供できるようにするための情報処理装置が記載されている。この情報処理装置は、複数ユーザの嗜好に関するデータを用いてユーザ同士の相関度を算出する機能を有する。さらに、この情報処理装置は、例えば、１つの相関度に関連する２人のユーザに関し、一方のユーザが有する要素を他方のユーザが保持していない場合に他方のユーザに当該要素に関連する要素を提供する機能を有する。つまり、あるユーザの操作履歴等を用いても当該ユーザに提供されない情報が、そのユーザに関連する他のユーザとの間の相関度に基づいて提供されるようになる。

特開２００５−５７７１３号公報

上記文献１の他にも、例えば、協調フィルタリング（ＣＦ；Ｃｏｌｌａｂｏｒａｔｉｖｅ−Ｆｉｌｔｅｒｉｎｇ）や、コンテンツベースフィルタリング（ＣＢＦ；Ｃｏｎｔｅｎｔ−Ｂａｓｅｄ−Ｆｉｌｔｅｒｉｎｇ）と呼ばれる技術が知られている。協調フィルタリング法は、多くのユーザに関する嗜好情報を蓄積しておき、あるユーザに関して嗜好が類似する他のユーザの情報を用いて自動的に提供すべき情報を推定する方法である。一方、コンテンツベースフィルタリングは、あるコンテンツに関連するコンテンツをコンテンツ間の類似度に基づいて抽出するという方法である。これらの方法を用いて情報を提供するシステムのことを推薦システムと呼ぶことがある。

上記の通り、協調フィルタリングは、ユーザの行動履歴間の関連度に基づいて情報を提供する手法である。つまり、あるコンテンツに対し、ユーザの行動履歴などから抽出される間接的に関連する情報を提供するものであり、あるコンテンツと直接に関連する情報を提供するものではない。また、協調フィルタリングは、所定数以上の嗜好情報が集まらないとユーザの嗜好に適合した情報が抽出されない。さらに、ユーザの操作履歴等により抽出される情報の数が十分でない場合に、その数を拡充することが難しい。一方、コンテンツベースフィルタリングは、コンテンツと直接関連する情報を提供するものであるため、ユーザの行動履歴などから抽出される間接的にコンテンツに関連した情報を提供するものではない。

そこで、本発明は、上記問題に鑑みてなされたものであり、本発明の目的とするところは、コンテンツと直接関連する情報と間接的に関連する情報を考慮した関連コンテンツの算出が可能な、新規かつ改良された情報処理装置、関連アイテムの提供方法、及びプログラムを提供することにある。

上記課題を解決するために、本発明のある観点によれば、所定のアイテムと計算対象アイテムとの間の類似度を計算する第１類似度計算部と、前記類似度が高い順に所定数の計算対象アイテムを前記所定のアイテムの関連アイテムに決定する関連アイテム決定部と、を備え、前記所定のアイテムに対し、ユーザの行動履歴に基づいて前記計算対象アイテムに関連付けられたメタ情報を追加した上で、前記所定のアイテムと前記計算対象アイテムとの間の類似度を算出する、情報処理装置が提供される。

このように、上記の情報処理装置は、第１類似度計算部により、所定のアイテムと計算対象アイテムとの間の類似度を計算する。また、この情報処理装置は、関連アイテム決定部により、前記類似度が高い順に所定数の計算対象アイテムを前記所定のアイテムの関連アイテムに決定する。そして、この情報処理装置は、前記所定のアイテムに対し、ユーザの行動履歴に基づいて前記計算対象アイテムに関連付けられたメタ情報を追加した上で、前記所定のアイテムと前記計算対象アイテムとの間の類似度を算出する。

また、上記の情報処理装置は、前記所定のアイテムに関連付けられた関連アイテムの中に前記計算対象アイテムが含まれる場合、当該計算対象アイテムの関連度を前記第１類似度計算部により算出された当該計算対象アイテムの類似度に加算する関連度加算部をさらに備えていてもよい。

また、上記の情報処理装置は、所定のアイテムのメタ情報と同じメタ情報を保持する候補アイテムに対し、ユーザの行動履歴に基づいて関連付けられた関連アイテムの関連度を取得する関連度取得部と、前記所定のアイテムと前記関連アイテムまたは前記候補アイテムとの間の類似度を取得する類似度取得部と、前記関連度および前記類似度に基づき、前記関連アイテムまたは候補アイテムと前記所定のアイテムとの間の類似度を計算する第２類似度計算部と、前記関連アイテム決定部により決定された関連アイテム数が前記所定数未満の場合、前記第２類似度計算部により計算された類似度が大きい順にアイテムを選択して前記関連アイテムに追加する関連アイテム追加部と、をさらに備えていてもよい。

また、前記第２類似度計算部は、前記類似度取得部により前記所定のアイテムと前記関連アイテムとの間の類似度が取得された場合、当該類似度と前記関連度とを乗算し、その乗算値を前記所定のアイテムと前記候補アイテムとの間の類似度としてもよい。この場合、前記関連アイテム追加部は、前記第２類似度計算部により算出された類似度が大きい順に前記候補アイテムを選択して前記関連アイテムに追加する。

また、前記第２類似度計算部は、前記類似度取得部により前記所定のアイテムと前記候補アイテムとの間の類似度が取得された場合、当該類似度と前記関連度とを乗算し、その乗算値を前記所定のアイテムと前記関連アイテムとの間の類似度としてもよい。この場合、前記関連アイテム追加部は、前記第２類似度計算部により算出された類似度が大きい順に前記関連アイテムを選択して前記関連アイテムに追加する。

また、前記関連度取得部は、前記所定のアイテムが保持するメタ情報の中で、予めメタ情報毎に設定された優先度が高いメタ情報を保持する前記候補アイテムについて前記関連アイテムの関連度を取得するように構成されていてもよい。

また、上記の情報処理装置は、前記所定のアイテムにアクセスするユーザの嗜好または前記所定のアイテムが保持するメタ情報の統計データに応じてメタ情報毎の優先度を設定する優先度設定部をさらに備えていてもよい。この場合、前記関連度取得部は、前記所定のアイテムが保持するメタ情報の中で、前記優先度設定部により設定された優先度が高いメタ情報を保持する前記候補アイテムについて前記関連アイテムの関連度を取得する。

また、前記関連度取得部は、前記所定のアイテムが保持する全てのメタ情報を保持する前記候補アイテムについて前記関連アイテムの関連度を取得し、前記候補アイテム毎に全ての関連度を積算して当該候補アイテムの関連度としてもよい。

また、前記所定のアイテムに関連付けられたアイテムを第１の関連アイテムとし、第Ｎ−１の関連アイテム（Ｎ≧２）の関連付けられたアイテムを第Ｎの関連アイテムとすると、前記関連度取得部は、前記第Ｋ−１の関連アイテムと第Ｋの関連アイテムとの間の関連度（２≦Ｋ≦Ｎ）を全て乗算し、前記第１の関連アイテムと前記第Ｎの関連アイテムとの間の関連度を取得することもできる。

また、上記の情報処理装置は、前記ユーザの嗜好が近い順に前記関連アイテムをソートして当該ユーザに提示する関連アイテム提示部をさらに備えていてもよい。

また、上記課題を解決するために、本発明の別の観点によれば、情報処理装置により、所定のアイテムに対し、ユーザの行動履歴に基づいて計算対象アイテムに関連付けられたメタ情報が追加されるステップと、前記所定のアイテムと前記計算対象アイテムとの間の類似度が算出されるステップと、前記類似度が高い順に所定数の計算対象アイテムが前記所定のアイテムの関連アイテムに決定されるステップと、前記関連アイテムがユーザに提示されるステップと、を含む、関連アイテムの提供方法が提供される。

以上説明したように本発明によれば、コンテンツと直接関連する情報と間接的に関連する情報を考慮した関連コンテンツの算出が可能になる。特に、コンテンツベースフィルタリングの枠組みの中で、協調フィルタリングによる結果も一緒に計算できるようになる。

以下に添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。なお、本明細書および図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。

［課題の整理］
ユーザに対して情報を提供する際に、そのユーザ（以下、提供先ユーザ）の嗜好に適合した情報を選択する技術として、協調フィルタリングと呼ばれる技術が知られている。この技術は、例えば、提供先ユーザの操作履歴等に基づいて提供先ユーザの類似ユーザを探索し、その類似ユーザに関連付けられた関連アイテムの中から提供すべき推薦アイテムを算出するというものである。特に、類似ユーザの関連アイテムの中で、提供先ユーザに関連付けられていないアイテムが提供先ユーザに提供される。つまり、ユーザ間の類似性を介して間接的に推薦アイテムが抽出されるのである。

具体例を挙げると、協調フィルタリングに係る処理は次のようになる。まず、提供先ユーザの操作履歴に基づいて提供先ユーザの類似ユーザが発見される。次に、類似ユーザが好むアイテムが抽出され、類似ユーザの好むアイテムを提供先ユーザが知らないならば、その知らないアイテムを提供先ユーザに推薦するという処理が実行される。ここで、類似ユーザの好むアイテムというのが、上記の関連アイテムである。この例から分かる通り、提供先ユーザと推薦アイテムとの間の直接的な関連性は考慮されていない。さらに言えば、提供先ユーザに推薦されるアイテムと、提供先ユーザが元々好んでいるアイテムとの間の直接的な関連性は考慮されていない。

このように、提供先ユーザと推薦アイテムとの間の関連性は、提供先ユーザと類似ユーザとの間の類似性を介して間接的に算出されるものである。そのため、提供先ユーザに元々関連付けられている関連アイテムと推薦アイテムとの間の直接的な関連性は、協調フィルタリングにおいて考慮されないのである。なお、ここで言うアイテムには、放送番組等のコンテンツやコンテンツに関する情報（例えば、番組情報等）の他に、ユーザ自身も含まれる。従って、上記の例を参照すれば、提供先ユーザと類似ユーザとの間の関係は直接的なアイテム間の関係に相当する。また、類似ユーザと推薦アイテムとの間の関係も直接的な関係に相当する。しかしながら、提供先ユーザと推薦アイテムとの間の関係は、あくまでも類似ユーザを介した間接的なアイテム間の関係であると言える。

ところで、関連アイテムの提供サービスが開始された当初は、アイテムの提供サーバ等に対するアクセス数が少ないことが多く、そもそも、ユーザ数が少ない場合も多い。この場合、上記の協調フィルタリングを用いる推薦システムでは、ユーザの嗜好情報が十分に取得できないため、ユーザの嗜好に良く適合した関連アイテムを提供することが難しい（所謂、コールドスタート問題）。もちろん、時間の経過と共に提供される関連アイテムの数が増加するものの、サービスの開始初期においては、十分な数の関連アイテムが提供されないことがある。そのため、ユーザの嗜好情報を拡充するための技術が研究されている。

例えば、ユーザが好みそうなメタ情報を予測し、その予測結果を利用してユーザの嗜好情報を拡充する技術が提案されている。この技術を用いることにより、協調フィルタリングを実行する際に利用される嗜好情報の数が拡充され、サービスの開始初期であっても、十分な数の関連アイテムを提供することができるようになる。つまり、この技術は、ユーザの嗜好情報を予測に基づいて拡充する技術である。

一方で、アイテム間の類似度を計算し、その類似度が高いアイテムを関連アイテムとして推薦する技術が知られている。この技術は、アイテム間の直接的な関連性のみを考慮して関連アイテムを算出する技術であり、コンテンツベースフィルタリングと呼ばれる。例えば、この技術を用いた推薦システムは、提供先ユーザの好むアイテムに関連するアイテムを検索し、発見されたアイテムを提供先ユーザに推薦する。

ここで、より具体的な推薦処理について述べる。コンテンツベースフィルタリングを用いる推薦システムでは、複数アイテムの各々についてアイテムベクトルと呼ばれるベクトル量を算出し、そのアイテムベクトルに基づいてアイテム同士の類似度を算出する。このとき、推薦システムは、各アイテムに付与されたメタ情報に基づいてアイテムベクトルを生成する。上記の処理内容からも分かる通り、コンテンツベースフィルタリングでは、上記の協調フィルタリングとは異なり、アイテム間の直接的な類似度に基づいて推薦アイテムが算出される。また、付与されたメタ情報が少ないアイテムについては、そのアイテムに関連する関連アイテムの算出が難しい場合もある。

以下で説明する実施形態は、上記の協調フィルタリングのように間接的なアイテム間の関連性を考慮しつつ、コンテンツベースフィルタリングのようにアイテム間の直接的な類似度に基づいて関連アイテムを抽出する技術を提供するものである。これまで、アイテム間の直接的な類似性とユーザ間の関連性を媒介とする間接的な関連性とを共に考慮して関連アイテムを提供しようとすると、協調フィルタリングの計算とコンテンツベースフィルタリングの計算とを別々に実行する必要があった。

しかし、下記の実施形態に係る技術を用いると冗長な計算をせずに済むため、演算処理が簡素化され、関連アイテムの算出処理に掛かる演算負荷や演算時間の低減が期待される。さらに、下記の実施形態に係る技術は、コンテンツベースフィルタリングの要素を含むため、上記のコールドスタート問題に対する解決手段を提供するものでもある。

＜第１実施形態＞
まず、本発明に係る第１実施形態について説明する。本実施形態は、ＣＢＦ（Ｃｏｎｔｅｎｔ−Ｂａｓｅｄ−Ｆｉｌｔｅｒｉｎｇ）の枠組みの中で、ＣＦ（Ｃｏｌｌａｂｏｒａｔｉｖｅ−Ｆｉｌｔｅｒｉｎｇ）による結果も一緒に計算できるようにした関連アイテムの算出方法に関する。以下、関連アイテムメタの付与方法、関連アイテムメタに基づく関連アイテムの算出方法、関連アイテムの提示方法の順で説明する。まず、これらの方法を実現することが可能な関連アイテム提供システム１００の構成例について説明する。

［関連アイテム提供システム１００の構成例］
図１を参照しながら、本実施形態に係る関連アイテム提供システム１００のシステム構成について説明する。図１は、本実施形態に係る関連アイテム提供システム１００の構成例を示す説明図である。

図１に示すように、関連アイテム提供システム１００は、主に、操作ログＤＢ１０２と、嗜好抽出エンジン１０４と、アクセスウェイトＤＢ１０６と、関連性抽出エンジン１０８と、関連アイテムメタＤＢ１１０と、推薦エンジン１１２と、アイテム情報ＤＢ１１４と、救済措置エンジン１１６とを含む。

また、関連アイテム提供システム１００は、ユーザが操作する情報機器１０に直接またはネットワークを介して接続されており、情報機器１０の操作ログを取得したり、情報機器１０に関連アイテムを提供したりすることができる。図１には、便宜上、情報機器１０が１台しか描画されていないが、２台以上であってもよい。

なお、操作ログＤＢ１０２、アクセスウェイトＤＢ１０６、関連アイテムメタＤＢ１１０、およびアイテム情報ＤＢ１１４は、所定の記憶装置に格納されている。この記憶装置としては、例えば、後述するハードウェア構成例の中で、ＲＡＭ９０６、記憶部９２０、またはリムーバブル記憶媒体９２８等が対応する。

（操作ログＤＢ１０２）
操作ログＤＢ１０２は、情報機器１０の操作ログが格納されるデータベース（ＤＢ；Ｄａｔａ Ｂａｓｅ）である。つまり、情報機器１０の操作ログ等の情報は、関連アイテム提供システム１００により取得され、操作ログＤＢ１０２に格納される。操作ログＤＢ１０２に格納された情報は、後述する嗜好抽出エンジン１０４により読み出される。

ここで、図２を参照しながら、操作ログＤＢ１０２の構成例について説明する。図２は、本実施形態に係る操作ログＤＢ１０２の構成例を示す説明図（図表１）である。図表１の例では、操作ログＤＢ１０２には、アイテムＩＤ（ＩｔｅｍＩＤ）、ユーザＩＤ（ＭｅｍｂｅｒＩＤ）、ログタイプ（ＬｏｇＴｙｐｅ）、ログ記録日時（ＬｏｇＴｉｍｅ）の欄が設けられている。

アイテムＩＤの欄に記録される情報は、各アイテムを示す識別情報（ＩＤ）である。ユーザＩＤの欄に記録される情報は、各ユーザを示す識別情報（ＩＤ）である。ログタイプの欄に記録される情報は、各操作ログの種類を示す情報である。ログ記録日時の欄に記録される情報は、そのレコードの操作ログが記録された日時を示す情報である。

例えば、アイテムＩＤ＝１０１１の行を参照すると、ユーザＩＤに２が記録され、ログタイプに“ｄｅｔａｉｌ”が記録され、ログ記録日時に“２００７−１２−０５ ０８：３９：５４”が記録されている。つまり、アイテムＩＤ＝１０１１に対し、ユーザＩＤ＝２のユーザが２００７年１２月５日８時３９分５４秒にアクセスしたことを示している。さらに、ログタイプが“ｄｅｔａｉｌ”であることから、そのアイテムの詳細情報まで視聴されたことが分かる。図表１に示した構成は一例であるが、この例のように、ユーザの操作ログが時間情報と共に記録される。

（嗜好抽出エンジン１０４）
再び図１を参照する。嗜好抽出エンジン１０４は、操作ログＤＢ１０２からユーザの操作ログを取得し、ユーザ毎に各アイテムに対するアクセスウェイトを計算する。嗜好抽出エンジン１０４により算出されたアクセスウェイトは、後述するアクセスウェイトＤＢ１０６に格納される。なお、ここで言うアクセスウェイトとは、あるユーザが特定のアイテムをどれだけ好んでいるかを示す指標であり、嗜好の度合いを示す情報である。例えば、アイテムＩＤ＝１０１１のアイテムに対するユーザＩＤ＝２のユーザの嗜好が強い場合、ユーザＩＤ＝２、アイテムＩＤ＝１０１１に対するアクセスウェイトは大きな値となる。つまり、アクセスウェイトは、嗜好情報の一例である。このアクセスウェイトの計算方法については後述する。

（アクセスウェイトＤＢ１０６）
アクセスウェイトＤＢ１０６は、嗜好抽出エンジン１０４により算出されたアクセスウェイトが格納されるデータベースである。言い換えると、アクセスウェイトＤＢ１０６は、ユーザの操作ログを解析して得られた結果（嗜好情報）が格納されるデータベースである。アクセスウェイトＤＢ１０６に格納された情報は、後述する関連性抽出エンジン１０８により読み出される。

ここで、図３を参照しながら、アクセスウェイトＤＢ１０６の構成例について説明する。図３は、本実施形態に係るアクセスウェイトＤＢ１０６の構成例を示す説明図（図表２）である。図表２の例では、アクセスウェイトＤＢ１０６には、アイテムＩＤ（ＩｔｅｍＩＤ）、ユーザＩＤ（ＭｅｍｂｅｒＩＤ）、嗜好度（ＡｃｃｅｓｓＷｅｉｇｈｔ）、初期登録日時（ＥｎｔｒｙＴｉｍｅ）、更新日時（ＵｐｄａｔｅＴｉｍｅ）の欄が設けられている。

アイテムＩＤの欄に記録される情報は、各アイテムを示す識別情報（ＩＤ）である。ユーザＩＤの欄に記録される情報は、各ユーザを示す識別情報（ＩＤ）である。嗜好度の欄に記録される情報は、各アイテムに対する各ユーザの嗜好度を示す情報である。つまり、この欄には、嗜好抽出エンジン１０４により算出されたアクセスウェイトが記録される。初期登録日時の欄に記録される情報は、アクセスウェイトＤＢ１０６の各レコードに初期登録された日時を示す時間情報である。更新日時の欄に記録される情報は、アクセスウェイトＤＢ１０６の各レコードが更新された日時を示す時間情報である。

例えば、アイテムＩＤ＝１０１０のレコードを参照すると、ユーザＩＤ＝２のユーザがアイテムＩＤ＝１０１０のアイテムに示す嗜好度が２．４であることが分かる。また、このユーザの嗜好度は、２００７年１２月５日８時４０分５２秒に初期登録された後、更新されていないことが分かる。さらに、図表２のアクセスウェイトＤＢ１０６には、ユーザＩＤ＝２のユーザについて、アイテムＩＤ＝１００１のアイテムに対する嗜好度と、アイテムＩＤ＝１００５のアイテムに対する嗜好度とが記録されている。アイテムＩＤ＝１００１のアイテムに対する嗜好度は１．０である。一方、アイテムＩＤ＝１００５のアイテムに対する嗜好度は６．０である。

従って、図表２の例において、ユーザＩＤ＝２のユーザは、アイテムＩＤ＝１００５のアイテムを最も好んでいることが分かる。そして、ユーザＩＤ＝２のユーザは、アイテムＩＤ＝１０１０のアイテム、アイテムＩＤ＝１００１のアイテムの順に高い嗜好を有していることが分かる。図表２に示した構成は一例であるが、この例のように、アクセスウェイトＤＢ１０６には、嗜好情報がユーザＩＤ、アイテムＩＤ、および時間情報が共に記録され、各ユーザの嗜好度が管理されている。

このように、アクセスウェイトＤＢ１０６には、ユーザＩＤ、アイテムＩＤ、および嗜好度が関連付けられて記録されている。そのため、比較的高い嗜好度が付与されたアイテムＩＤを抽出し、抽出されたアイテムＩＤを共通して持つユーザのユーザＩＤを抽出することで、ユーザ間の類似性を算出することができる。つまり、同じアイテムＩＤのアイテムに対して高い嗜好度を有するユーザ間には、高い類似性が認められると考えるのである。また、同じユーザが高い嗜好度を有する複数のアイテム間には、一定の関連性があると考えることもできる。

（関連性抽出エンジン１０８）
再び図１を参照する。関連性抽出エンジン１０８は、アクセスウェイトＤＢ１０６から各アイテムに関連のあるアイテム（関連アイテム）を算出するための情報を取得する。この情報には、アイテムＩＤ、ユーザＩＤ、嗜好度が含まれる。そして、関連性抽出エンジン１０８は、取得した情報を用いて各アイテムの関連アイテムを算出する。例えば、関連性抽出エンジン１０８は、同じユーザの嗜好度が付与された複数のアイテムを抽出し、これらアイテムを相互に関連付ける。このとき、一方のアイテムは、他方のアイテムの関連アイテムとなる。なお、関連アイテムは、複数個抽出されることもある。

このとき、関連性抽出エンジン１０８は、あるアイテム（該当アイテム）と関連アイテムとの間の関連性の強さを表す関連度を算出する。例えば、関連性抽出エンジン１０８は、該当アイテムの嗜好度と関連アイテムの嗜好度とに基づいて関連度を算出する。このとき、関連性抽出エンジン１０８は、例えば、該当アイテムの嗜好度と関連アイテムの嗜好度とを積算し、その積算値を正規化して関連度を算出する。関連性抽出エンジン１０８により算出された関連アイテムの情報は、関連アイテムメタＤＢ１１０に記録される。この関連度とは、ユーザの操作履歴や作業履歴、またはコミュニティの活動状況等に基づくソーシャルな関係を用いて算出される値である。

（関連アイテムメタＤＢ１１０）
関連アイテムメタＤＢ１１０は、関連性抽出エンジン１０８により算出された各アイテムの関連アイテムの情報と、各アイテム間の関連度とが格納されるデータベースである。関連アイテムメタＤＢ１１０に格納された情報は、後述する推薦エンジン１１２により読み出される。

ここで、図４を参照しながら、関連アイテムメタＤＢ１１０の構成例について説明する。図４は、本実施形態に係る関連アイテムメタＤＢ１１０の構成例を示す説明図（図表３）である。図表３の例では、関連アイテムメタＤＢ１１０には、アイテムＩＤ（ＩｔｅｍＩＤ）、関連アイテムＩＤ（ＳｉｍＩｔｅｍＩＤ）、関連度（Ｓｃｏｒｅ）、初期登録日時（ＥｎｔｒｙＴｉｍｅ）、更新日時（ＵｐｄａｔｅＴｉｍｅ）の欄が設けられている。

アイテムＩＤの欄に記録される情報は、各アイテムを示す識別情報（ＩＤ）である。関連アイテムＩＤの欄に記録される情報は、アイテムＩＤで指定されたアイテムの関連アイテム（関連アイテム）を示す識別情報（ＩＤ）である。関連度の欄に記録される情報は、アイテムＩＤで指定されたアイテムと、関連アイテムＩＤで指定されたアイテムとの間の関連性の強さを示す関連度である。初期登録日時の欄に記録される情報は、関連アイテムメタＤＢ１１０の各レコードに初期登録された日時を示す時間情報である。更新日時の欄に記録される情報は、関連アイテムメタＤＢ１１０の各レコードが更新された日時を示す時間情報である。

例えば、図表３に示す関連アイテムメタＤＢ１１０の中で、アイテムＩＤ＝１００１のアイテムに対応するレコードを検索すると、関連アイテムＩＤ＝１００２のレコードと、関連アイテムＩＤ＝１００３のレコードとが検出される。関連アイテムＩＤ＝１００２のレコードには、関連度＝１．５が記録されている。一方、関連アイテムＩＤ＝１００３のレコードには、関連度＝３．４が記録されている。これらの情報から、アイテムＩＤ＝１００１のアイテムは、少なくとも、アイテムＩＤ＝１００２、１００３に対応する２つのアイテムと関連していることが分かる。さらに、アイテムＩＤ＝１００１のアイテムは、アイテムＩＤ＝１００２のアイテムに比べ、アイテムＩＤ＝１００３のアイテムとの間に大きな関連性を有することが分かる。

このように、関連アイテムメタＤＢ１１０には、アイテムＩＤ、関連アイテムＩＤ、および関連度が関連付けて記録されている。そのため、比較的高い関連度が付与された関連アイテムＩＤを抽出し、抽出された関連アイテムＩＤを共通して持つアイテムのアイテムＩＤを抽出することで、アイテム間の関連性を算出することができる。つまり、同じ関連アイテムＩＤのアイテムに対して高い関連度を有するアイテム間には、高い関連性が認められると考えられるのである。

関連アイテムメタＤＢ１１０に記録されている関連度は、アイテムＩＤのアイテムと、関連アイテムＩＤのアイテムとの間の直接的な関連性を示すものである。一方、関連アイテムメタＤＢ１１０に基づいて算出される上記のアイテム間の関連性は、関連アイテムを介して得られる間接的な関連性を示すものである。

（推薦エンジン１１２）
再び図１を参照する。推薦エンジン１１２は、関連アイテムメタＤＢ１１０に記録されている情報に基づいて各アイテムの関連アイテムを情報機器１０に提供する。例えば、情報機器１０からアイテムＡの関連アイテムが要求された場合、推薦エンジン１１２は、関連アイテムメタＤＢ１１０に記録されたアイテムＡの関連アイテムＩＤを参照し、この関連アイテムＩＤに対応する関連アイテムを情報機器１０に提示する。このとき、推薦エンジン１１２は、後述するアイテム情報ＤＢ１１４から関連アイテムを取得する。また、推薦エンジン１１２は、情報機器１０に提示する関連アイテムの個数が所定数に満たない場合、後述する救済措置エンジン１１６から関連アイテムを取得する。

（アイテム情報ＤＢ１１４）
アイテム情報ＤＢ１１４は、個々のアイテムに付与された属性情報が格納されるデータベースである。アイテム情報ＤＢ１１４に格納された属性情報は、推薦エンジン１１２、および後述する救済措置エンジン１１６により読み出される。

ここで、図５を参照しながら、アイテム情報ＤＢ１１４の構成例について説明する。図５は、本実施形態に係るアイテム情報ＤＢ１１４の構成例を示す説明図（図表４）である。図表４の例では、アイテム情報ＤＢ１１４には、アイテムＩＤ（ＩｔｅｍＩＤ）、メタタイプ（ＡｔｔｒｉｂｕｔｅＩＤ；属性ＩＤ）、メタ（ＶａｌｕｅＩＤ；属性値）、更新回数（ＮｏｆＴｉｍｅｓ）、重要度（Ｓｃｏｒｅ）の欄が設けられている。

アイテムＩＤの欄に記録される情報は、各アイテムを示す識別情報（ＩＤ）である。メタタイプの欄に記録される情報は、各アイテムに付与された属性情報の種類を表す情報である。この欄には、例えば、ジャンル（Ｇｅｎｒｅ）、パーソン（Ｐｅｒｓｏｎ）、キーワード（Ｋｅｙｗｏｒｄ）、放送時間、放送局、タイトル（Ｔｉｔｌｅ）等を示す識別情報（ＩＤ）が記録される。メタの欄には、各アイテムの属性値が記録される。例えば、この欄には、「アクション」「山田太郎」「正月」等を示す識別情報（ＩＤ）が記録される。更新回数の欄に記録される情報は、そのレコードが更新された回数である。重要度の欄に記録される情報は、そのレコードに記録されたメタの重要度を示す情報である。この重要度は、全てのアイテムのメタを参照した際に、そのメタの出現頻度等に基づいて算出されるものである（例：ＴＦ−ＩＤＦ）。

（救済措置エンジン１１６）
再び図１を参照する。救済措置エンジン１１６は、推薦エンジン１１２から関連アイテムの要求を受けた場合に推薦エンジン１１２とは異なる方法で関連アイテムを算出する。上記の通り、推薦エンジン１１２は、関連アイテムメタＤＢ１１０等に基づいて算出される関連アイテムの個数が所定数に満たない場合、救済措置エンジン１１６に関連アイテムの要求を行う。この要求を受けて、救済措置エンジン１１６は、関連アイテムの個数が所定数になるように所要数の関連アイテムを推薦エンジン１１２に提供する。救済措置エンジン１１６による関連アイテムの算出方法については後段において詳述する。

以上、本実施形態に係る関連アイテム提供システム１００の機能構成について説明した。上記の通り、関連アイテム提供システム１００は、ユーザの操作履歴、およびアイテム間の関連性に基づいてアイテム毎に関連アイテムを算出する。そのため、ユーザの嗜好を考慮しつつ、アイテム間の関連性に基づいて関連アイテムを算出することができる。アクセスウェイトＤＢ１０６、および関連アイテムメタＤＢ１１０の説明でも述べたように、この計算には、アイテム間の直接的な関連性と、間接的な関連性とが考慮されている。

また、推薦エンジン１１２により算出される関連アイテムの個数が所定数に満たない場合でも、救済措置エンジン１１６により関連アイテムが補充されることで、所定数の関連アイテムを情報機器１０に提供することが可能になる。なお、上記の説明においては、関連性の算出方法や各アイテムに付与されるメタの重要度の算出方法等について、その詳細な説明を割愛していた。そこで、これらの算出方法を含めた関連アイテムの提供方法について、以下で詳細に説明する。

［関連アイテムの提供方法］
以下、本実施形態に係る関連アイテム提供方法について詳細に説明する。まず、図６を参照しながら、本実施形態に係る関連アイテム提供方法の全体的な流れについて説明する。図６は、本実施形態に係る関連アイテム提供方法の全体的な流れを示す説明図である。

図６に示すように、まず、嗜好抽出エンジン１０４により、操作ログＤＢ１０２に格納された操作ログの解析範囲が指定される（Ｓ１０２）。操作ログの解析範囲としては、例えば、操作ログのログ記録日時について開始日時および終了日時が指定される。そして、嗜好抽出エンジン１０４により、解析範囲に含まれるレコードが特定される。

次いで、嗜好抽出エンジン１０４は、解析範囲のレコードに記録された操作ログに基づき、アイテムＩＤおよびユーザＩＤの各組み合わせに対してアクセスウェイトを算出する（Ｓ１０４）。アイテムＩＤおよびユーザＩＤの組み合わせが同じであるレコードが複数存在する場合、嗜好抽出エンジン１０４は、各レコードに記録された操作ログから算出されるアクセスウェイトを積算し、その積算値をアクセスウェイトＤＢ１０６に格納する。

ただし、積算ではなく、複数のアクセスウェイトの中で最大の値がアクセスウェイトＤＢ１０６に格納されるように構成されていてもよい。また、嗜好抽出エンジン１０４によりアクセスウェイトが算出されたアイテムＩＤおよびユーザＩＤの組み合わせに対するアクセスウェイトがアクセスウェイトＤＢ１０６に既に格納されていることがある。この場合、嗜好抽出エンジン１０４は、例えば、新たに算出したアクセスウェイトと、アクセスウェイトＤＢ１０６に既に格納されているアクセスウェイトとを積算し、その積算値で古い格納値を上書きする。ただし、より大きなアクセスウェイトで古い格納値を上書きするように構成されていてもよい。

次いで、関連性抽出エンジン１０８により、操作ログの解析範囲に含まれる全てのアイテムの中から１つのアイテムが選択され、このアイテム（以下、該当アイテム）について、ステップＳ１０６〜Ｓ１２２（またはＳ１２４）の処理が実行される（反復処理（Ａ）の開始）。まず、関連性抽出エンジン１０８により、該当アイテムに対して過去にアクセスした全てのユーザが検出される（Ｓ１０６）。

次いで、関連性抽出エンジン１０８により、該当アイテムに対して過去にアクセスした全てのユーザの中から１人のユーザが選択され、このユーザ（以下、該当ユーザ）について次の処理が実行される（反復処理（Ｂ）の開始）。まず、関連性抽出エンジン１０８により、該当ユーザにより過去にアクセスされた全てのアイテムのアクセスウェイトが取得され、アイテム毎にアクセスウェイトが積算される（Ｓ１０８）。次いで、該当アイテムにアクセスした全てのユーザの中から、他のユーザが１人だけ選択され、再びステップＳ１０８の処理が実行される（反復処理（Ｂ）の継続）。このとき、該当アイテムに対して過去にアクセスした全てのユーザについてステップＳ１０８の処理が実行された場合に反復処理が終了される（反復処理（Ｂ）の終了）。

反復処理（Ｂ）が終了した後、関連性抽出エンジン１０８により、アイテム毎に積算された積算値が正規化され、正規化された積算値が該当アイテムの関連度に設定される（Ｓ１１０）。次いで、関連性抽出エンジン１０８は、関連度が設定されたアイテムを該当アイテムの関連アイテムに設定する（Ｓ１１２）。

関連アイテムが設定されると、関連性抽出エンジン１０８により、該当アイテムとの間に関連度を有するアイテムの中から、１つのアイテムが選択され、このアイテム（以下、該当関連アイテム）について次の処理が実行される（反復処理（Ｃ）の開始）。まず、関連性抽出エンジン１０８により、該当関連アイテムが有効期間中のアイテムか否かが確認される（Ｓ１１４）。そして、関連性抽出エンジン１０８により、該当関連アイテムが有効であるか否かが判定される（Ｓ１１６）。該当関連アイテムが有効な場合、異なる該当関連アイテムが１つ選択され、再びステップＳ１１４〜Ｓ１１６の処理が実行される（反復処理（Ｃ）の継続）。ただし、全ての関連アイテムについて有効期間が判定された場合、ステップＳ１２０の処理に進行する（反復処理（Ｃ）の終了）。

一方、該当関連アイテムが無効な場合、ステップＳ１１８の処理に進行する。ステップＳ１１８では、関連性抽出エンジン１０８により、無効な関連アイテムが該当アイテムの関連アイテム群から取り除かれる（Ｓ１１８）。そして、異なる該当関連アイテムが１つ選択され、再びステップＳ１１４〜Ｓ１１６の処理が実行される（反復処理（Ｃ）の継続）。ただし、全ての関連アイテムについて有効期間が判定された場合、ステップＳ１２０の処理に進行する（反復処理（Ｃ）の終了）。

ステップＳ１２０では、関連性抽出エンジン１０８により、関連度が大きい順（または小さい順）に関連アイテムがソートされ、該当アイテムの関連アイテムとして付与される（Ｓ１２０）。ここで、関連アイテムの付与とは、関連アイテムメタＤＢ１１０に対するレコードの登録を意味する。なお、関連アイテムメタＤＢ１１０に登録される関連アイテムの個数が所定個未満である場合、関連性抽出エンジン１０８により、全ての関連アイテムが関連アイテムメタＤＢ１１０に登録されることになる。

推薦エンジン１１２は、関連アイテムメタＤＢ１１０に登録された関連アイテムの数が所定数（指定個）に達しているか否かを判断する（Ｓ１２２）。関連アイテム数≦指定個の場合、後述するステップＳ１２４の処理（救済措置）に進行する。一方、関連アイテム数＞指定個の場合、異なる該当アイテムを１つ選択し、再びステップＳ１０６から始まる処理を実行する（反復処理（Ａ）の継続）。ただし、操作ログの解析範囲に含まれる全てのアイテムについてステップＳ１０６〜Ｓ１２２（またはＳ１２４）の処理が実行された場合、一連の処理を終了する（反復処理（Ａ）の終了）。

（救済措置について）
ここで、図８を参照しながら、ステップＳ１２４の救済処置について詳細に説明する。ただし、救済措置について詳細に説明するのに先立ち、図７を参照しながら、各アイテムのアイテム情報を簡潔に表現するアイテム情報ベクトルの表現形式について説明する。なお、アイテム情報ベクトルの表現形式は、後述するユーザの嗜好情報を表現する際にも利用可能であるため、ここで併せて説明する。図７は、本実施形態に係るアイテム情報ベクトル、およびユーザ嗜好ベクトルの表現形式を示す説明図である。

図７を参照する。図７に示すように、各アイテムの情報は、ベクトル形式で表現される。第１要素（最左の欄）にアイテムＩＤが含まれる場合、そのベクトルは、アイテム情報ベクトルを表す。一方、第１要素にユーザＩＤが含まれる場合、そのベクトルは、ユーザ嗜好ベクトルを表す。ここでは、アイテム情報ベクトルを例に挙げて説明する。

アイテム情報ベクトルは、例えば、メタタイプ毎に複数のメタが対応付けられており、各メタに対して重要度の値が付与されている。なお、以下の説明中では、メタタイプ単位で見た各メタの重要度を表すベクトルをメタタイプベクトルと呼ぶ場合がある。ここで、アイテム情報ＤＢ１１４の例（図５）を参照すると、アイテム情報ベクトルを構成するアイテムＩＤ、メタタイプ、メタ、重要度の関係がアイテム情報ＤＢ１１４に記載されていることが分かる。つまり、救済措置エンジン１１６は、アイテム情報ＤＢ１１４の情報に基づいてアイテム情報ベクトルを構築することができる。

さて、次に救済措置について説明する。この救済措置（ステップＳ１２４）の処理は、主に、救済措置エンジン１１６により実行される。また、図８は、本実施形態に係る救済措置の流れを示す説明図である。

まず、図８を参照する。図８に示すように、救済措置が開始されると、救済措置エンジン１１６により、アイテム情報ＤＢ１１４から、該当アイテムに付与されたメタタイプ１のメタが取得される（Ｓ１３０）。例えば、該当アイテムがアイテムＩＤ＝１００５のアイテムである場合を考える。図５に示したアイテム情報ＤＢ１１４を想定すると、該当アイテムに付与されたメタタイプ１のメタは１５３１４４である。

次いで、救済措置エンジン１１６は、メタタイプ１のメタが付与されたアイテムが関連アイテムとして持つアイテム群を取得する（Ｓ１３２）。図５のアイテム情報ＤＢ１１４を参照すると、メタタイプ１のメタ（１５３１４４）が付与されたアイテムは、アイテムＩＤ＝１００１、１００２、…、１０１４のアイテムである。

この場合、救済措置エンジン１１６は、アイテムＩＤ＝１００１、１００２、…、１０１４を関連アイテムに持つアイテムを取得する。例えば、アイテムＩＤ＝１００３のアイテムを関連アイテムに持つアイテムを関連アイテムメタＤＢ１１０（図４）から検索すると、アイテムＩＤ＝１００１、１０１１のアイテムが抽出される。そこで、救済措置エンジン１１６は、アイテムＩＤ＝１００１、１０１１のアイテムをアイテム群に加える。同様に、他のアイテムＩＤのアイテムを関連アイテムに持つアイテムも抽出され、アイテム群に追加される。

次いで、救済措置エンジン１１６は、関連アイテムメタＤＢ１１０を参照し、ステップＳ１３２で取得したアイテム群を関連度順にソートする（Ｓ１３４）。例えば、アイテム群に含まれるアイテムとして、アイテムＩＤ＝１００３を関連アイテムに持つアイテム（アイテムＩＤ＝１００１、１０１１）について考える。この場合、救済措置エンジン１１６は、より大きな関連度を持つアイテムＩＤ＝１０１１のアイテム（関連度：５．４）を上位に、アイテムＩＤ＝１００１のアイテム（関連度：３．４）を下位に位置付ける。アイテム群に含まれる他のアイテムについても同様に、関連度順でソートされる。

次いで、救済措置エンジン１１６は、ステップＳ１３４でソートしたアイテム群の中から、関連度の高い順にアイテムを抽出して該当アイテムの関連アイテムに設定する（Ｓ１３６）。図４に例示した関連アイテムメタＤＢ１１０の場合、アイテムＩＤ＝１００５のアイテムに設定された関連アイテムは、アイテムＩＤ＝１００１、１００４、１０１０の３つである。仮に、関連アイテムの指定数が５である場合、救済措置エンジン１１６は、あと２つの関連アイテムを設定することになる。その際、救済措置エンジン１１６は、アイテム群（アイテムＩＤ＝１００１、１００２、…、１０１１）の中から、関連度の高いアイテムＩＤ＝１００３、１０１１を抽出し、アイテムＩＤ＝１００５の関連アイテムに設定することになる。

次いで、救済措置エンジン１１６は、該当アイテムの関連アイテム数が指定個を越えているか否かを判断する（Ｓ１３８）。該当アイテムの関連アイテム数≧指定個の場合、救済措置エンジン１１６は、救済措置に係る一連の処理を終了する。一方、該当アイテムの関連アイテム数＜指定個の場合、救済措置エンジン１１６は、ステップＳ１４０の処理に進行する。

ステップＳ１４０では、救済措置エンジン１１６により、該当アイテムに付与されたメタタイプ２のメタが取得される（Ｓ１４０）。次いで、救済措置エンジン１１６は、メタタイプ２が付与されたアイテムを関連アイテムに持つアイテム群を取得する（Ｓ１４２）。次いで、救済措置エンジン１１６は、ステップＳ１４２で取得したアイテム群を関連度順にソートする（Ｓ１４４）。次いで、救済措置エンジン１１６は、アイテム群に含まれるアイテムの中から、関連度の高い順にアイテムを抽出して該当アイテムの関連アイテムに設定する（Ｓ１４６）。

次いで、救済措置エンジン１１６は、該当アイテムの関連アイテム数が指定個を越えているか否かを判断する（Ｓ１４８）。該当アイテムの関連アイテム数≧指定個の場合、救済措置エンジン１１６は、救済措置に係る一連の処理を終了する。一方、該当アイテムの関連アイテム数＜指定個の場合、救済措置エンジン１１６は、ステップＳ１５０の処理に進行する。

ステップＳ１５０では、救済措置エンジン１１６により、該当アイテムに付与されたメタタイプ３のメタが取得される（Ｓ１５０）。次いで、救済措置エンジン１１６は、メタタイプ３が付与されたアイテムを関連アイテムに持つアイテム群を取得する（Ｓ１５２）。次いで、救済措置エンジン１１６は、ステップＳ１５２で取得したアイテム群を関連度順にソートする（Ｓ１５４）。次いで、救済措置エンジン１１６は、アイテム群に含まれるアイテムの中から、関連度の高い順にアイテムを抽出して該当アイテムの関連アイテムに設定する（Ｓ１５６）。

次いで、救済措置エンジン１１６は、該当アイテムの関連アイテム数が指定個を越えているか否かを判断する（Ｓ１５８）。該当アイテムの関連アイテム数≧指定個の場合、救済措置エンジン１１６は、救済措置に係る一連の処理を終了する。一方、該当アイテムの関連アイテム数＜指定個の場合、救済措置エンジン１１６は、ステップＳ１６０の処理に進行する。ただし、ステップＳ１６０の処理に進行する間、メタタイプ４〜Ｍ−１（Ｍは自然数）について、ステップＳ１５０〜Ｓ１５６と同様の処理が実行される。

ステップＳ１６０では、救済措置エンジン１１６により、該当アイテムに付与されたメタタイプＭのメタが取得される（Ｓ１６０）。次いで、救済措置エンジン１１６は、メタタイプＭが付与されたアイテムを関連アイテムに持つアイテム群を取得する（Ｓ１６２）。次いで、救済措置エンジン１１６は、ステップＳ１６２で取得したアイテム群を関連度順にソートする（Ｓ１６４）。次いで、救済措置エンジン１１６は、アイテム群に含まれるアイテムの中から、関連度の高い順にアイテムを抽出して該当アイテムの関連アイテムに設定する（Ｓ１６６）。

次いで、救済措置エンジン１１６は、該当アイテムの関連アイテム数が指定個を越えているか否かを判断する（Ｓ１６８）。該当アイテムの関連アイテム数≧指定個の場合、救済措置エンジン１１６は、救済措置に係る一連の処理を終了する。一方、該当アイテムの関連アイテム数＜指定個の場合、救済措置エンジン１１６は、ステップＳ１７０の処理に進行する。ステップＳ１７０では、救済措置エンジン１１６により、アクセスウェイトＤＢ１０６が参照され、全ユーザのアクセスウェイトランキングで上位のアイテムが該当アイテムの関連アイテムに設定される（Ｓ１７０）。このとき、救済措置エンジン１１６は、該当アイテムの関連アイテム数が指定個になるように関連アイテムを設定した後、救済措置に係る一連の処理を終了する。

（概念的な説明）
ここで、図９の概念図を参照しながら、上記の救済措置に関する概念的な説明を加える。図９は、本実施形態に係る救済措置の概念を簡単に示した説明図である。この救済措置（ソーシャルな関連使用バージョン）は、メタの関連性を利用してアイテムの類似度を計算するのではなく、コミュニティ内における社会知識に基づいてアイテムの類似度が計算される。そのため、メタに表現されていない類似度を考慮することが可能になる。この類似度とは、メタの関連性に基づいて算出された値である。

図９に示すように、該当アイテムに関連アイテムが無い場合について考える。また、該当アイテムには、メタタイプとして「ニュース」「サッカー」が付与されているものとする。ただし、実際には、「ニュース」「サッカー」に対応するメタタイプのＩＤ（属性ＩＤ）が該当アイテムに付与されている。

まず、救済措置エンジン１１６により、該当アイテムが持つメタタイプのメタが任意に抽出される。仮に、「ニュース」「サッカー」に対応するメタ（属性値）が抽出されたものとする。次いで、救済措置エンジン１１６は、抽出したメタを持つアイテムを関連アイテムの候補（以下、関連アイテム候補）として取得する。仮に、関連アイテム候補として、アイテム（１）、アイテム（２）、アイテム（３）が取得されたものとする。

これらのアイテムには関連度が付与されている。例えば、アイテム（１）には、アイテムＡに対する関連度１．５、アイテムＢに対する関連度０．５が付与されているものとする。また、アイテム（２）には、アイテムＢに対する関連度０．９、アイテムＣに対する関連度０．３、アイテムＤに対する関連度０．１が付与されているものとする。さらに、アイテム（３）には、アイテムＡに対する関連度１．０、アイテムＣに対する関連度０．４が付与されているものとする。また、アイテムＢが、該当アイテムのメタから抽出されたメタと同じメタ（例えば、「サッカー」）を持つものと仮定する。

この場合、救済措置エンジン１１６は、アイテムＢに対する各関連アイテム候補の関連度（値Ｂ）、および、該当アイテムとアイテムＢとの間の類似度（値Ａ）に基づき、該当アイテムと各関連アイテム候補との間の関連度を算出する。この関連度は、例えば、下記の式（１）および式（２）に基づいて算出することができる。

上記の式（１）および式（２）で算出された関連度は、各関連アイテム候補が関連アイテムとして該当アイテムに付与される際の関連度に設定される。例えば、該当アイテムには、関連度０．１５を持つアイテム（１）、および関連度０．２７を持つアイテム（２）が付与されるのである。このように、該当アイテムに付与される関連アイテムと、各関連アイテムに設定される関連度とが算出される。なお、上記の例では、（値Ａ）と（値Ｂ）との積算値を用いる方法を示したが、例えば、（値Ａ）と（値Ｂ）との加算値、または（値Ｂ）をそのまま用いる方法でもよい。

ところで、上記の説明においては、関連アイテム候補の選択方法として、該当アイテムのメタ群から抽出したメタと同じメタを持つアイテムを選択する方法について述べた。この方法について、より詳細に説明する。

本実施形態に係る救済措置においては、種々の関連アイテム候補の選択方法が適用できる。例えば、個々のメタに優先度を予め設定しておき、その優先度の高いメタを持つアイテムを関連アイテム候補として選択する方法が適用できる（方法１）。さらに、該当アイテムのメタ群をメタタイプベクトル（図７を参照）で表現し、メタタイプベクトルの類似度が大きいアイテムを関連アイテム候補として選択する方法が適用できる（方法２）。

以下、上記の方法２について簡単に説明する。方法２は、メタタイプベクトルを用いて算出される類似度をアイテム間で比較するというものである。この類似度は、下記の式（３）により算出される。ただし、ここで算出する類似度の計算方法は、下記の内積計算でなくても良く、例えば、コサイン尺度やユークリッド距離等を計算する方法でもよい。

上記の方法２によると、各計算対象アイテムについて、上記の式（３）により算出された類似度が比較され、類似度が大きい順に上位Ｎ個（Ｎは所定数）のアイテムが関連アイテム候補として選択されるのである。

（変形例１−１）
ここで、本実施形態に係る救済措置の変形例（変形例１−１）について述べる。上記の救済措置は、該当アイテムのメタに基づいて関連アイテム候補を抽出し、その関連アイテム候補が持つ関連アイテムの関連度等を基準に該当アイテムの関連アイテムを設定していた。この考え方を応用し、例えば、該当アイテムのメタに類似するメタを持つアイテムを抽出し、そのアイテムの関連アイテムを該当アイテムの関連アイテムに設定する方法が考えられる。そこで、図１０を参照しながら、この方法について以下で説明する。図１０は、本実施形態の変形例１−１に係る救済措置の流れを示す説明図である。

図１０に示すように、まず、救済措置エンジン１１６は、メタタイプ１が付与されたアイテムを検索する（Ｓ１７２）。次いで、救済措置エンジン１１６は、メタタイプ１のメタが付与されたアイテムについて、各アイテムが持つ関連アイテムの中から関連度が高い順に上位Ｎ個（Ｎは所定数）のアイテムを抽出する。そして、救済措置エンジン１１６は、抽出したアイテムを該当アイテムの関連アイテムに設定する（Ｓ１７４）。

次いで、救済措置エンジン１１６は、該当アイテムの関連アイテム数が指定個を越えたか否かを判断する（Ｓ１７６）。該当アイテムの関連アイテム数≧指定個の場合、救済措置エンジン１１６は、救済措置に係る一連の処理を終了する。一方、該当アイテムの関連アイテム数＜指定個の場合、救済措置エンジン１１６は、ステップＳ１７８の処理に進行する。

ステップＳ１７８では、救済措置エンジン１１６により、メタタイプ２が付与されたアイテムが検索される（Ｓ１７８）。次いで、救済措置エンジン１１６は、メタタイプ２のメタが付与されたアイテムについて、各アイテムが持つ関連アイテムの中から関連度が高い順に上位Ｎ個（Ｎは所定数）のアイテムを抽出する。そして、救済措置エンジン１１６は、抽出したアイテムを該当アイテムの関連アイテムに設定する（Ｓ１８０）。

次いで、救済措置エンジン１１６は、該当アイテムの関連アイテム数が指定個を越えたか否かを判断する（Ｓ１８２）。該当アイテムの関連アイテム数≧指定個の場合、救済措置エンジン１１６は、救済措置に係る一連の処理を終了する。一方、該当アイテムの関連アイテム数＜指定個の場合、救済措置エンジン１１６は、ステップＳ１８４の処理に進行する。

ステップＳ１８４では、救済措置エンジン１１６により、メタタイプ３が付与されたアイテムが検索される（Ｓ１８４）。次いで、救済措置エンジン１１６は、メタタイプ３のメタが付与されたアイテムについて、各アイテムが持つ関連アイテムの中から関連度が高い順に上位Ｎ個（Ｎは所定数）のアイテムを抽出する。そして、救済措置エンジン１１６は、抽出したアイテムを該当アイテムの関連アイテムに設定する（Ｓ１８６）。

次いで、救済措置エンジン１１６は、該当アイテムの関連アイテム数が指定個を越えたか否かを判断する（Ｓ１８８）。該当アイテムの関連アイテム数≧指定個の場合、救済措置エンジン１１６は、救済措置に係る一連の処理を終了する。一方、該当アイテムの関連アイテム数＜指定個の場合、救済措置エンジン１１６は、ステップＳ１９０の処理に進行する。ただし、ステップＳ１９０の処理に進行する間、メタタイプ４〜Ｍ−１（Ｍは自然数）について、ステップＳ１８４〜Ｓ１８８と同様の処理が実行される。

ステップＳ１９０では、救済措置エンジン１１６により、メタタイプＭが付与されたアイテムが検索される（Ｓ１９０）。次いで、救済措置エンジン１１６は、メタタイプＭのメタが付与されたアイテムについて、各アイテムが持つ関連アイテムの中から関連度が高い順に上位Ｎ個（Ｎは所定数）のアイテムを抽出する。そして、救済措置エンジン１１６は、抽出したアイテムを該当アイテムの関連アイテムに設定する（Ｓ１９２）。

次いで、救済措置エンジン１１６は、該当アイテムの関連アイテム数が指定個を越えたか否かを判断する（Ｓ１９４）。該当アイテムの関連アイテム数≧指定個の場合、救済措置エンジン１１６は、救済措置に係る一連の処理を終了する。一方、該当アイテムの関連アイテム数＜指定個の場合、救済措置エンジン１１６は、ステップＳ１９６の処理に進行する。ステップＳ１９６では、救済措置エンジン１１６により、アクセスウェイトＤＢ１０６が参照され、全ユーザのアクセスウェイトランキングで上位のアイテムが該当アイテムの関連アイテムに設定される（Ｓ１９６）。このとき、救済措置エンジン１１６は、該当アイテムの関連アイテム数が指定個になるように関連アイテムを設定した後、救済措置に係る一連の処理を終了する。

（概念的な説明）
ここで、図１１の概念図を参照しながら、変形例１−１の救済措置に関する概念的な説明を加える。図１１は、変形例１−１に係る救済措置の概念を示した説明図である。

図１１に示すように、該当アイテムに関連アイテムが無い場合について考える。また、該当アイテムには、メタタイプとして「ニュース」「サッカー」が付与されているものとする。ただし、実際には、「ニュース」「サッカー」に対応するメタタイプのＩＤ（属性ＩＤ）が該当アイテムに付与されている。

まず、救済措置エンジン１１６により、該当アイテムが持つメタタイプのメタが任意に抽出される。仮に、「ニュース」「サッカー」に対応するメタ（属性値）が抽出されたものとする。次いで、救済措置エンジン１１６は、抽出したメタを持つアイテムを関連アイテムの候補（以下、関連アイテム候補）として取得する。仮に、関連アイテム候補として、アイテム（１）、アイテム（２）、アイテム（３）が取得されたものとする。

これらのアイテムには関連度が付与されている。例えば、アイテム（１）には、アイテムＡに対する関連度１．５、アイテムＢに対する関連度０．５が付与されているものとする。また、アイテム（２）には、アイテムＢに対する関連度０．９、アイテムＣに対する関連度０．３、アイテムＤに対する関連度０．１が付与されているものとする。さらに、アイテム（３）には、アイテムＡに対する関連度１．０、アイテムＣに対する関連度０．４が付与されているものとする。

さらに、救済措置エンジン１１６により、該当アイテムに対する関連アイテム候補の類似度（値Ａ）が算出されているものとする。図１１の例では、アイテム（１）と該当アイテムとの間の類似度が０．３、アイテム（２）と該当アイテムとの間の類似度が０．０、アイテム（３）と該当アイテムとの間の類似度が０．０である。この例は、アイテム（１）のメタに該当アイテムと同じメタ（例えば、「サッカー」）が含まれている場合に相当する。

この場合、救済措置エンジン１１６は、該当アイテムと各関連アイテム候補との間の類似度（値Ａ）、および、各関連アイテム候補の各関連アイテムに対する関連度（値Ｂ）に基づき、該当アイテムと各関連アイテム候補の関連アイテムとの間の類似度を算出する。この類似度は、例えば、下記の式（４）および式（５）に基づいて算出することができる。そして、算出された類似度が大きい順に上位から所定個の関連アイテムが該当アイテムに付与される。なお、アイテム（２）およびアイテム（３）と、該当アイテムとの間の類似度が０．０であることから、これらのアイテムに関する類似度の記載は省略した。

上記の式（４）および式（５）で算出された類似度は、各関連アイテム候補の関連アイテムが該当アイテムに付与される際の関連度に設定される。例えば、該当アイテムには、関連度０．４５を持つアイテムＡ、および関連度０．１５を持つアイテムＢが付与されるのである。このようにして、該当アイテムに付与される関連アイテムと、各関連アイテムに設定される関連度とが算出される。なお、上記の例では、（値Ａ）と（値Ｂ）とを積算値を用いる方法を示したが、例えば、（値Ａ）と（値Ｂ）との加算値、または（値Ｂ）をそのまま用いる方法でもよい。

ところで、上記の説明においては、関連アイテム候補の選択方法として、該当アイテムのメタ群から抽出したメタと同じメタを持つアイテムを選択する方法について述べた。この方法について、より詳細に説明する。

本実施形態に係る救済措置においては、種々の関連アイテム候補の選択方法が適用できる。例えば、個々のメタに優先度を予め設定しておき、その優先度の高いメタを持つアイテムを関連アイテム候補として選択する方法が適用できる（方法１）。さらに、該当アイテムのメタ群をメタタイプベクトル（図７を参照）で表現し、メタタイプベクトルの類似度が大きいアイテムを関連アイテム候補として選択する方法が適用できる（方法２）。

以下、上記の方法２について簡単に説明する。方法２は、メタタイプベクトルを用いて算出される類似度をアイテム間で比較するというものである。この類似度は、下記の式（６）により算出される。ただし、ここで算出する類似度の計算方法は、下記の内積計算でなくても良く、例えば、コサイン尺度やユークリッド距離等を計算する方法でもよい。

上記の方法２によると、各計算対象アイテムについて、上記の式（６）により算出された類似度が比較され、類似度が大きい順に上位Ｎ個（Ｎは所定数）のアイテムが関連アイテム候補として選択されるのである。

＜第２実施形態＞
次に、本発明の第２実施形態について説明する。本実施形態は、ＣＢＦ（Ｃｏｎｔｅｎｔ−Ｂａｓｅｄ−Ｆｉｌｔｅｒｉｎｇ）の枠組みの中で、ＣＦ（Ｃｏｌｌａｂｏｒａｔｉｖｅ−Ｆｉｌｔｅｒｉｎｇ）による結果も一緒に計算できるようにする関連アイテムの算出方法に関する。特に、ユーザの嗜好情報を利用して関連アイテムを算出する技術に関する。

［関連アイテム提供システム２００の構成例］
まず、図１２を参照しながら、本実施形態に係る関連アイテム提供システム２００のシステム構成について説明する。図１２は、本実施形態に係る関連アイテム提供システム２００の構成例を示す説明図である。なお、上記の第１実施形態に係る関連アイテム提供システム１００と実質的に同一の機能構成については同一の符号を付することにより詳細な説明を省略する。

図１２に示すように、関連アイテム提供システム２００は、主に、操作ログＤＢ１０２と、嗜好抽出エンジン２０２と、アクセスウェイトＤＢ１０６と、関連性抽出エンジン１０８と、関連アイテムメタＤＢ１１０と、推薦エンジン１１２と、アイテム情報ＤＢ１１４と、救済措置エンジン２０６と、ユーザ嗜好情報ＤＢ２０４とを含む。上記の第１実施形態に係る関連アイテム提供システム１００との間の主な相違点は、嗜好抽出エンジン２０２、救済措置エンジン２０６の機能、およびユーザ嗜好情報ＤＢ２０４の存在である。そこで、これらの相違点を中心に説明する。

また、関連アイテム提供システム２００は、ユーザが操作する情報機器１０に直接またはネットワークを介して接続されており、情報機器１０の操作ログを取得したり、情報機器１０に関連アイテムを提供したりすることができる。図１２には、便宜上、情報機器１０が１台しか描画されていないが、２台以上であってもよい。

なお、操作ログＤＢ１０２、アクセスウェイトＤＢ１０６、関連アイテムメタＤＢ１１０、アイテム情報ＤＢ１１４、およびユーザ嗜好情報ＤＢ２０４は、所定の記憶装置に格納されている。この記憶装置としては、例えば、後述するハードウェア構成例の中で、ＲＡＭ９０６、記憶部９２０、またはリムーバブル記憶媒体９２８等に相当する。

（嗜好抽出エンジン２０２）
嗜好抽出エンジン２０２は、操作ログＤＢ１０２からユーザの操作ログを取得し、ユーザ毎に各アイテムに対するアクセスウェイトを計算する。嗜好抽出エンジン２０２により算出されたアクセスウェイトは、アクセスウェイトＤＢ１０６、およびユーザ嗜好情報ＤＢ２０４に格納される。なお、ここで言うアクセスウェイトとは、あるユーザが特定のアイテムをどれだけ好んでいるかを示す指標であり、嗜好の度合いを示す情報である。つまり、アクセスウェイトは、嗜好情報の一例である。

例えば、各操作ログに予め重み値が設定されており、その値に基づいて各アイテムに対する各ユーザのアクセスウェイトが算出される。ここで、アクセスウェイトの算出方法の一例について簡単に説明する。まず、嗜好抽出エンジン２０２は、操作ログＤＢ１０２から取得した各操作ログに基づき、アクセスのあったアイテムを特定する。次いで、嗜好抽出エンジン２０２は、アクセス情報ＤＢ１１４を参照し、特定したアイテムのメタと、そのメタに対応する重要度（重み値）を取得する。次いで、嗜好抽出エンジン２０２は、メタ毎に重要度を積算し、その積算値をアクセスウェイトとして蓄積する。なお、メタタイプ毎にアクセスウェイトを算出してもよい。

（ユーザ嗜好情報ＤＢ２０４）
ユーザ嗜好情報ＤＢ２０４は、個々のユーザ毎に嗜好情報として算出された属性情報が格納されるデータベースである。ユーザ嗜好情報ＤＢ２０４に格納された属性情報は、救済措置エンジン２０６により読み出される。

ここで、図１３を参照しながら、ユーザ嗜好情報ＤＢ２０４の構成例について説明する。図１３は、本実施形態に係るユーザ嗜好情報ＤＢ２０４の構成例を示す説明図（図表５）である。図表５の例で、ユーザ嗜好情報ＤＢ２０４には、ユーザＩＤ（ＭｅｍｂｅｒＩＤ）、メタタイプ（ＡｔｔｒｉｂｕｔｅＩＤ；属性ＩＤ）、メタ（ＶａｌｕｅＩＤ；属性値）、重要度（Ｓｃｏｒｅ）の欄が設けられている。なお、各アイテムに関連アイテムが付与されている場合、各関連アイテムに対するメタが格納されていてもよい。

ユーザＩＤの欄に記録される情報は、各ユーザを識別するための識別情報（ＩＤ）である。メタタイプの欄に記録される情報は、各アイテムに付与された属性情報の種類を表す情報である。この欄には、例えば、ジャンル（Ｇｅｎｒｅ）、パーソン（Ｐｅｒｓｏｎ）、キーワード（Ｋｅｙｗｏｒｄ）、放送時間、放送局、タイトル（Ｔｉｔｌｅ）等を示す識別情報（ＩＤ）が記録される。

メタの欄に記録される情報は、各アイテムの属性値が記録される。この欄には、例えば、「アクション」「山田太郎」「正月」等を示す識別情報（ＩＤ）が記録される。重要度の欄に記録される情報は、そのレコードに記録されたメタの重要度を示す情報である。この重要度は、全てのアイテムのメタを参照した際に、そのメタの出現頻度等に基づいて算出されるものである（例：ＴＦ−ＩＤＦ）。

（救済措置エンジン２０６）
再び図１２を参照する。救済措置エンジン２０６は、推薦エンジン１１２から関連アイテムの要求を受けた場合に推薦エンジン１１２とは異なる方法で関連アイテムを算出する。上記の通り、推薦エンジン１１２は、関連アイテムメタＤＢ１１０等に基づいて算出される関連アイテムの個数が所定数に満たない場合、救済措置エンジン１１６に関連アイテムの要求を行う。この要求を受けて、救済措置エンジン２０６は、関連アイテムの個数が所定数になるように所要数の関連アイテムを推薦エンジン１１２に提供するのである。ただし、救済措置エンジン２０６は、上記の第１実施形態に係る救済措置エンジン１１６とは異なり、ユーザの嗜好情報を利用して関連アイテムを抽出する。以下、この抽出方法について詳細に説明する。

（救済措置の詳細）
ここで、図１４を参照しながら、本実施形態に係る救済措置について説明する。図１４は、本実施形態に係る救済措置の流れを示す説明図である。

上記の第１実施形態に係る救済措置は、予め設定されたメタタイプの優先度（例えば、メタタイプ１、メタタイプ２、…、メタタイプＭの順番）に基づいて処理が実行され、該当アイテムの関連アイテムが設定された。本実施形態に係る救済措置は、全てのメタタイプに関して処理を実行した上で、その結果をマージする方法に関する。この方法によると、特定のメタタイプの関連度に影響されず、より関連性の高いアイテムを該当アイテムの関連アイテムに設定することが可能になる。以下、この方法について述べる。

まず、救済措置エンジン２０６は、該当アイテムが持つ全てのメタタイプを取得した上で、その中から１つのメタタイプ（以下、該当メタタイプ；メタタイプＭ）を選択し、ステップＳ２０２〜Ｓ２０６の処理を実行する（反復処理（Ａ）の開始）。

ステップＳ２０２では、救済措置エンジン２０６により、該当アイテムに付与されたメタタイプＭのメタが取得される（Ｓ２０２）。次いで、救済措置エンジン２０６は、メタタイプＭのメタを持つアイテムが関連アイテムとして付与されたアイテム（アイテム群）を取得する（Ｓ２０４）。次いで、救済措置エンジン２０６は、アイテム群に含まれる各アイテムに対する関連度を参照し、関連度が高い順にソートして関連アイテム候補のリストに記録する（Ｓ２０６）。

次いで、救済措置エンジン２０６は、該当アイテムが持つメタタイプの中から、他の該当メタタイプを１つ選択し、再びステップＳ２０２〜Ｓ２０６の処理を実行する。ただし、救済措置エンジン２０６は、該当アイテムが持つ全てのメタタイプについてステップＳ２０２〜Ｓ２０６の処理を実行した場合、ステップＳ２０８の処理に進行する。

ステップＳ２０８では、救済措置エンジン２０６により、関連アイテム候補リストに含まれる各アイテムの関連度に対し、各メタタイプの優先度に応じた重みを掛ける（Ｓ２０８）。ただし、各メタタイプの優先度は、予め設定しておく方法もあるが、動的に算出する方法もある。この動的に算出する方法について簡単に説明する。

優先度の算出方法としては、例えば、該当アイテムが持つメタの偏りに応じて優先度が決定される方法（方法１）や、アクセスしたユーザの嗜好の偏りに応じて優先度が決定される方法（方法２）が考えられる。

（方法１について）
方法１を採用する場合、救済措置エンジン２０６は、メタタイプ毎に該当アイテムが持つ各メタの偏りを算出し、その偏りに応じて重みを算出する。例えば、救済措置エンジン２０６は、偏りの大きいメタタイプに対して大きな重み値を設定する。この設定により、重み値が大きなメタタイプと、そのメタタイプが付与されたアイテムとの間の関連性が特に重要視されることになる。偏りの算出方法としては、例えば、次のような方法がある。（１）各メタタイプに含まれるメタに関して重み値の平均が算出され、その平均値が高い程、大きな偏り値が設定されるという方法。（２）各メタタイプに含まれるメタの中で、有限の値を持つメタの割合に応じて偏り値が設定されるという方法。

（方法２について）
方法２を採用する場合、救済措置エンジン２０６は、上記の方法１と同様に、アクセスしたユーザの嗜好の偏り値を算出し、その偏り値に応じて重み値を算出する。例えば、ユーザの嗜好が大きく偏っているメタタイプの重み値を大きく設定する。この設定により、該当ユーザが重要視しているメタタイプとの関連が重視されることになる。

上記のようにして重み付けされた後、救済措置エンジン２０６により、関連アイテム候補リスト内に重複して含まれるアイテムの重み値が足し合わされ、新たな関連度としてマージされる（Ｓ２１０）。つまり、関連アイテム候補リスト内に同じアイテムのレコードが複数存在する場合、それらのレコードは、１つのレコードに纏められる。その際、そのレコードに記録される関連度は、同一アイテムに関して複数のレコードに記録されていた重み値の合計値に設定される。

次いで、救済措置エンジン２０６は、関連アイテム候補リストに含まれるアイテムの中から、関連度が高い順に上位Ｎ個（Ｎは所定数）のアイテムを抽出し、該当アイテムの関連アイテムに設定する（Ｓ２１２）。次いで、救済措置エンジン２０６は、関連アイテム数が指定個に達しているか否かを判断する（Ｓ２１４）。関連アイテム数≧指定個の場合、救済措置エンジン２０６は、救済措置に係る一連の処理を終了する。一方、関連アイテム数＜指定個の場合、救済措置エンジン２０６は、ステップＳ２１６の処理に進行する。

ステップＳ２１６では、救済措置エンジン２０６により、全てのユーザに対するアクセスウェイトが大きい順に上位のアイテムが抽出され、該当アイテムの関連アイテムに付与される（Ｓ２１６）。このとき、救済措置エンジン２０６により、該当アイテムの関連アイテム数が指定数になるまで、アクセスウェイトが上位のアイテムが付与される。このようにして、該当アイテムに指定数だけ関連アイテムが付与され、救済措置に係る一連の処理が終了する。

以上の方法を用いると、特定のメタタイプを用いた関連度に影響されることなく、より関連性の高いアイテムを関連アイテムとして算出することができる。

（変形例２−１）
ここで、図１５を参照しながら、本実施形態に係る救済措置の変形例（変形例２−１）について説明する。図１５は、変形例２−１に係る救済措置の流れを示す説明図である。この変形例２−１は、処理が優先的に実行されるメタタイプの順番を決定するための優先度の算出方法に関する。この変形例２−１の場合、救済措置エンジン２０６は、救済措置を実行する前段で優先度の算出処理を実行する。

図１５に示すように、まず、救済措置エンジン２０６は、メタタイプ毎に優先度を算出する（Ｓ２２２）。このとき、救済措置エンジン２０６は、該当アイテムが持つメタについて各メタタイプの偏りを算出し、その偏りが大きいメタタイプから順に優先度を設定する。次いで、救済措置エンジン２０６は、優先度の高いメタタイプから順に救済措置を実行する（Ｓ２２４）。

上記のように、メタの偏りが大きいメタタイプに高い優先度が設定される。そこで、救済措置エンジン２０６は、この優先度を利用して、優先度が大きい順に上位のアイテムを該当アイテムの関連アイテムに設定することができる。さらに、救済措置エンジン２０６は、メタタイプ毎に算出された偏りの大きさに応じて関連アイテムとして付与する数を変えることもできる。つまり、この方法は、偏りの大きいメタタイプを利用して該当アイテムに関連が深いアイテムをより重要視するというものである。

また、救済措置エンジン２０６は、メタタイプに関する偏りと同様に、アクセスしたユーザの嗜好に関する偏りを算出し、その算出したユーザの嗜好の偏りに応じて優先度を設定してもよい。この場合、救済措置エンジン２０６は、ユーザの嗜好の偏りが大きいアイテムから順に選択し、該当アイテムの関連アイテムに設定する。さらに、救済措置エンジン２０６は、ユーザの嗜好の偏りに応じて関連アイテムとして付与する数を変えることもできる。つまり、この方法は、ユーザの嗜好の偏りが大きいアイテムを該当アイテムに関連が深いアイテムとして、より重要視するというものである。

（変形例２−２）
次に、図１６〜図１８を参照しながら、本実施形態に係る救済措置の変形例（変形例２−２）について説明する。図１６〜図１８は、変形例２−２に係る救済措置の流れを示す説明図である。この変形例２−２に係る救済措置は、該当アイテムの各関連アイテムについて、各関連アイテムが持つ関連アイテムを関連度が高い順に取得し、該当アイテムに付与する方法に関する。

図１６に示すように、まず、救済措置エンジン２０６により、該当アイテムがシードアイテムに指定される（Ｓ２３２）。次いで、救済措置エンジン２０６は、シードアイテムの関連アイテム群を取得する（Ｓ２３４）。次いで、救済措置エンジン２０６は、シードアイテムの関連アイテム群に含まれる全てのアイテムについて、ステップＳ２３６〜Ｓ２４０の処理を実行する（反復処理（Ａ）の開始）。

次いで、救済措置エンジン２０６は、シードアイテムの関連アイテム群の中から１つのアイテム（以下、選択アイテム）を取得する（Ｓ２３６）。次いで、救済措置エンジン２０６は、選択アイテムの関連アイテムを取得し、関連度が高い順に上位の関連アイテムを抽出して該当アイテムの関連アイテムに設定する（Ｓ２３８）。次いで、救済措置エンジン２０６は、該当アイテムの関連アイテム数が指定個に達したか否かを判断する（Ｓ２４０）。該当アイテムの関連アイテム数≧指定個である場合、救済措置エンジン２０６は、救済措置に係る一連の処理を終了する。

一方、該当アイテムの関連アイテム数＜指定個である場合、救済措置エンジン２０６は、シードアイテムの関連アイテムの中から、関連度が次に高い選択アイテムを選択し、ステップＳ２３６〜Ｓ２４０の処理を実行する（反復処理（Ａ）の継続）。ただし、シードアイテムの関連アイテム群に含まれる全ての関連アイテムについて、ステップＳ２３６〜Ｓ２４０の処理が実行された場合、反復処理（Ｂ）に進行する（反復処理（Ａ）の終了）。

反復処理（Ｂ）は、シードアイテムの関連アイテム群に含まれる関連アイテムについて反復実行される。まず、救済措置エンジン２０６により、シードアイテムの関連アイテム群の中から、１つのアイテムが取得される（Ｓ２４２）。次いで、救済措置エンジン２０６は、取得したアイテムの関連アイテム群（アイテム群１）を取得する（Ｓ２４４）。次いで、反復処理（Ｃ）に進行する。

反復処理（Ｃ）は、アイテム群１に含まれるアイテムについて反復実行される。救済措置エンジン２０６は、アイテム群１の中から１つのアイテムを取得する（Ｓ２４６）。次いで、救済措置エンジン２０６は、取得したアイテムの関連アイテム群の中で、関連度が高い順に上位の関連アイテムを該当アイテムの関連アイテムに設定する（Ｓ２４８）。次いで、救済措置エンジン２０６は、該当アイテムの関連アイテム数が指定数に達したか否かを判断する（Ｓ２５０）。該当アイテムの関連アイテム数≧指定個である場合、救済措置エンジン２０６は、救済措置に係る一連の処理を終了する。

一方、該当アイテムの関連アイテム数＜指定個の場合、救済措置エンジン２０６は、アイテム群１に含まれる他のアイテムを選択し、そのアイテムについてステップＳ２４６〜Ｓ２５０の処理を実行する（反復処理（Ｃ）の継続：図１７）。ただし、救済措置エンジン２０６は、アイテム群１に含まれる全てのアイテムについてステップＳ２４６〜Ｓ２５０の処理を実行した場合（反復処理（Ｃ）の終了：図１７）、ステップＳ２４２に戻り、シードアイテムの関連アイテム群の中から他の１つのアイテムを取得して、ステップＳ２４４以降の処理を実行する（反復処理（Ｂ）の継続）。ただし、シードアイテムの関連アイテム群に含まれる全てのアイテムについて、反復処理（Ｂ）に関する一連の処理が実行された場合、反復処理（Ｄ）（図１７）に進行する（反復処理（Ｂ）の終了）。

図１７を参照する。反復処理（Ｄ）は、アイテム群１に含まれる全てのアイテムについて反復実行される。救済措置エンジン２０６は、アイテム群１の中から１つのアイテムを取得する（Ｓ２５２）。次いで、救済措置エンジン２０６は、ステップＳ２５２で取得したアイテムの関連アイテム（アイテム群２）を取得する（Ｓ２５４）。次いで、救済措置エンジン２０６は、反復処理（Ｅ）に進行する。

反復処理（Ｅ）は、アイテム群２に含まれるアイテムについて反復実行される。救済措置エンジン２０６は、アイテム群２の中から１つのアイテムを取得する（Ｓ２５６）。次いで、救済措置エンジン２０６は、取得したアイテムの関連アイテム群の中で、関連度が高い順に上位の関連アイテムを該当アイテムの関連アイテムに設定する（Ｓ２５８）。次いで、救済措置エンジン２０６は、該当アイテムの関連アイテム数が指定数に達したか否かを判断する（Ｓ２６０）。該当アイテムの関連アイテム数≧指定個である場合、救済措置エンジン２０６は、救済措置に係る一連の処理を終了する。

一方、該当アイテムの関連アイテム数＜指定個の場合、救済措置エンジン２０６は、アイテム群１に含まれる他のアイテムを選択し、そのアイテムについてステップＳ２５６〜Ｓ２６０の処理を実行する（反復処理（Ｅ）の継続：図１８）。ただし、救済措置エンジン２０６は、アイテム群２に含まれる全てのアイテムについてステップＳ２５６〜Ｓ２６０の処理を実行した場合（反復処理（Ｄ）の終了：図１８）、ステップＳ２５２に戻り、アイテム群１の中から他の１つのアイテムを取得して、ステップＳ２５４以降の処理を実行する（反復処理（Ｄ）の継続）。ただし、アイテム群１に含まれる全てのアイテムについて、反復処理（Ｄ）に関する一連の処理が実行された場合、反復処理（Ｆ）（図１８）に進行する（反復処理（Ｄ）の終了）。

ただし、救済措置エンジン２０６は、反復処理（Ｄ）が終了して反復処理（Ｆ）に進行する間に、反復処理（Ｄ）と同じ一連の処理をアイテム群２〜アイテム群Ｍ−１について実行する。その後、救済措置エンジン２０６は、反復処理（Ｆ）に進行する。

図１８を参照する。反復処理（Ｆ）は、アイテム群Ｍに含まれる全てのアイテムについて反復実行される。救済措置エンジン２０６は、アイテム群Ｍの中から１つのアイテムを取得する（Ｓ２６２）。次いで、救済措置エンジン２０６は、ステップＳ２６２で取得したアイテムの関連アイテム（アイテム群Ｍ＋１）を取得する（Ｓ２６４）。次いで、救済措置エンジン２０６は、反復処理（Ｇ）に進行する。

反復処理（Ｇ）は、アイテム群Ｍ＋１に含まれるアイテムについて反復実行される。救済措置エンジン２０６は、アイテム群Ｍ＋１の中から１つのアイテムを取得する（Ｓ２６６）。次いで、救済措置エンジン２０６は、取得したアイテムの関連アイテム群の中で、関連度が高い順に上位の関連アイテムを該当アイテムの関連アイテムに設定する（Ｓ２６８）。次いで、救済措置エンジン２０６は、該当アイテムの関連アイテム数が指定数に達したか否かを判断する（Ｓ２７０）。該当アイテムの関連アイテム数≧指定個である場合、救済措置エンジン２０６は、救済措置に係る一連の処理を終了する。

一方、該当アイテムの関連アイテム数＜指定個の場合、救済措置エンジン２０６は、アイテム群Ｍ＋１に含まれる他のアイテムを選択し、そのアイテムについてステップＳ２６６〜Ｓ２７０の処理を実行する（反復処理（Ｇ）の継続）。ただし、救済措置エンジン２０６は、アイテム群Ｍ＋１に含まれる全てのアイテムについてステップＳ２６６〜Ｓ２７０の処理を実行した場合（反復処理（Ｇ）の終了）、ステップＳ２６２に戻り、アイテム群Ｍの中から他の１つのアイテムを取得して、ステップＳ２６４以降の処理を実行する（反復処理（Ｆ）の継続）。ただし、アイテム群Ｍに含まれる全てのアイテムについて、反復処理（Ｆ）に関する一連の処理が実行された場合、ステップＳ２７２の処理に進行する（反復処理（Ｄ）の終了）。

ステップＳ２７２では、救済措置エンジン２０６により、全てのユーザに関するアクセスウェイトランキングの中で上位に位置するアイテムが該当アイテムの関連アイテムに追加される（Ｓ２７２）。このとき、救済措置エンジン２０６は、該当アイテムの関連アイテム数が所定個になるまで追加処理を実行する。その後、救済措置エンジン２０６は、救済措置に係る一連の処理を終了する。

（概念的な説明）
ここで、図１９を参照しながら、変形例２−２に係る救済措置の概念について簡単に纏める。図１９は、変形例２−２に係る救済措置を概念的に示した説明図である。

図１９に例示したように、変形例２−２に係る救済措置は、５つのステップで概念的に表現することができる。Ｓｔｅｐ．１では、該当アイテムに２つの関連アイテム（アイテム１、アイテム２）が付与されているものと仮定する。また、該当アイテムとアイテム１との間の類似度が０．８であると仮定する。さらに、該当アイテムとアイテム２との間の類似度が０．５であると仮定する。

ここで、救済措置エンジン２０６は、該当アイテムの関連アイテムを１つ取得する。例えば、アイテム１が取得されるものと仮定する。また、Ｓｔｅｐ．２に示すように、アイテム１には、２つの関連アイテム（アイテム３、アイテム４）が付与されているものと仮定する。そして、アイテム１とアイテム３との間の類似度が０．９であり、アイテム１とアイテム４との間の類似度が０．３であると仮定する。

次いで、救済措置エンジン２０６は、アイテム１の関連アイテム（アイテム３、アイテム４）を関連アイテム候補に設定する（Ｓｔｅｐ．３）。次いで、救済措置エンジン２０６は、該当アイテムと各関連アイテム候補（アイテム３、アイテム４）との間の類似度を算出する（Ｓｔｅｐ．４）。この類似度の計算方法としては、例えば、下記の式（７）および式（８）のように、該当アイテムとアイテム１との間の類似度（値Ａ）に、アイテム１と各関連アイテム候補との間の類似度（値Ｂ）を乗算する方法がある。

上記のようにして各関連アイテム候補と該当アイテムとの間の類似度が算出され、関連アイテム候補が該当アイテムの関連アイテムに追加される（Ｓｔｅｐ．５）。このとき、救済措置エンジン２０６は、該当アイテムに元から付与されていた関連アイテムも含めて、関連アイテムの類似度が高い順に上位Ｎ個（Ｎは指定個数）のアイテムを付与する。

なお、上記の実施形態において、該当アイテムと各関連アイテム候補との間の関連度を算出する方法として、次のような変形が可能である。例えば、該当アイテムをアイテム１、関連アイテム候補をアイテムＮとし、関連アイテム候補を得るのに用いたアイテム群のアイテムをアイテム２〜Ｎ−１とする。これらのアイテム（アイテム１〜Ｎ）を用いることで、アイテム１とアイテムＮとの間の関連度は、下記の式（９）のように表現することができる。ただし、各アイテム間の関連度は０〜１の間の値に正規化されているものとする。

上記の方法を用いると、実際に関連のあるアイテムから処理が開始されるため、ある程度以上の関連性があるアイテムの取得が見込める。

［関連アイテムの算出方法］
ここで、図２０を参照しながら、関連アイテムメタＤＢ１１０に格納された情報に基づいて関連アイテムを算出する方法について説明する。図２０は、本実施形態に係る関連アイテムの算出方法の流れを示す説明図である。以下で説明する関連アイテムの算出処理は、主に、推薦エンジン１１２により実行される。なお、この方法を用いると、比較的高速な動作が期待できる。

図２０に示すように、まず、推薦エンジン１１２により、指定されたアイテムの関連アイテムに付与されたメタが関連アイテムメタＤＢ１１０から取得される（Ｓ２９２）。次いで、推薦エンジン１１２により、取得したメタの中で、関連度が高い順に上位Ｎ個のメタが関連アイテムに設定される（Ｓ２９４）。

ところで、推薦エンジン１１２は、単純に関連アイテムのメタを関連度順にソートして関連アイテムに設定することができる。ただし、推薦エンジン１１２は、各アイテムが持つ関連アイテムのメタ以外のメタ情報を利用し、類似度等の情報と組み合わせて関連アイテムを算出することもできる。例えば、推薦エンジン１１２は、協調フィルタリングによる結果と、コンテンツベースフィルタリングによる結果とを組み合わせて関連アイテムを算出することもできる。そこで、これらの方法について以下で簡単に説明する。

（類似度計算による関連アイテムの算出方法）
アイテム情報ベクトル間の類似度を計算する方法としては、例えば、アイテム情報ベクトルの内積、コサイン尺度、ユークリッド距離等を計算する方法がある。ここでは、アイテム情報ベクトルの内積を利用する方法について述べる。

アイテムが持つメタタイプの集合Ａに含まれるメタをａとする。また、メタａの重みをＷａとする。さらに、該当アイテムＸのメタａが属するメタタイプベクトルをＸａとし、計算対象となるアイテム（以下、対象アイテム）Ｙのメタａが属するメタタイプベクトルをＹａとする。このような表現を利用すると、該当アイテムと対象アイテムとの間の類似度は、下記の式（１０）により計算される。

なお、上記の式（１０）では、２つのメタタイプベクトル（Ｘａ、Ｙａ）の内積に重みＷａを乗算しているが、各メタタイプベクトルに各メタの重みを乗算するように設定されていてもよい。

（変形例：類似度計算方法）
ここで、図２１を参照しながら、類似度計算に関する変形例について説明する。図２１は、本変形例に係る類似度計算方法を利用した関連アイテムの算出方法の流れを示す説明図である。この変形例では、該当アイテムと対象アイテム群との間で、各アイテムのベクトルにより類似度が算出され、該当アイテムが持つ関連アイテムメタに含まれるアイテムの関連度が積算される。されに、その積算値から最終的な類似度が計算され、その類似度の高い順に上位Ｎ個のアイテムが関連アイテムとして算出されるというものである。

図２１に示すように、まず、推薦エンジン１１２により、アイテム情報ＤＢ１１４から該当アイテムのアイテム情報が読み出される（Ｓ３０２）。次いで、推薦エンジン１１２により、計算対象のアイテム群（以下、対象アイテム群）が選択される（Ｓ３０４）。次いで、反復処理（Ａ）が実行される。この反復処理（Ａ）は、対象アイテム群について反復実行される。まず、推薦エンジン１１２は、対象アイテム群の中から、１つの対象アイテムを選択し（反復処理（Ａ）の開始）、その対象アイテムのアイテム情報をアイテム情報ＤＢ１１４から取得する（Ｓ３０６）。

次いで、推薦エンジン１１２は、取得したアイテム情報のアイテム情報ベクトルに基づいて該当アイテムと対象アイテムとの間の類似度を計算する（Ｓ３０８）。このとき、計算された類似度は、結果リストに記録される。その後、推薦エンジン１１２により、他の対象アイテムが１つ選択され、ステップＳ３０６、Ｓ３０８の処理が実行される（反復処理（Ａ）の継続）。ただし、対象アイテム群に含まれる全ての対象アイテムについてステップＳ３０６、Ｓ３０８の処理が実行された場合、推薦エンジン１１２は、ステップＳ３１０の処理に進行する（反復処理（Ａ）の終了）。

ステップＳ３１０では、推薦エンジン１１２により、該当アイテムに付与された関連アイテムメタに含まれるアイテム群が取得される（Ｓ３１０）。次いで、推薦エンジン１１２は、反復処理（Ｂ）に進行する。この反復処理（Ｂ）は、関連アイテムメタのアイテム群に含まれる全てのアイテムについて反復実行される。まず、推薦エンジン１１２は、取得したアイテム群の中から１つのアイテムを選択し（反復処理（Ｂ）の開始）、そのアイテムと同一のアイテムが結果リスト中に存在するかを検索する（Ｓ３１２）。

次いで、推薦エンジン１１２は、結果リスト中に同一アイテムが存在するか否かを判断する（Ｓ３１４）。結果リスト中に同一アイテムが存在する場合、推薦エンジン１１２は、ステップＳ３１６の処理に進行する。一方、結果リスト中に同一アイテムが存在しない場合、推薦エンジン１１２は、ステップＳ３１８の処理に進行する。

ステップＳ３１６では、推薦エンジン１１２により、関連アイテムメタ毎に設定された関連度に対して重みが掛けられ、結果リストに含まれる類似度に積算される（Ｓ３１６）。一方、ステップＳ３１８では、推薦エンジン１１２により、関連アイテムメタ毎に設定された関連度に重み付けされた値が類似度として結果リストに格納される（Ｓ３１８）。ただし、関連アイテムメタの重みとは、関連アイテムメタの関連度をどの程度重要視するのかを示す値であり、予め与えられている。

その後、推薦エンジン１１２は、アイテム群に含まれる他のアイテムを選択し、ステップＳ３１２〜Ｓ３１６（またはＳ３１８）の処理を反復実行する（反復処理（Ｂ）の継続）。ただし、アイテム群に含まれる全てのアイテムに対してステップＳ３１２〜Ｓ３１６（またはＳ３１８）の処理を実行した場合、推薦エンジン１１２は、ステップＳ３２０の処理に進行する。

ステップＳ３２０では、推薦エンジン１１２により、類似度が高い順に結果リストのレコードがソートされる（Ｓ３２０）。次いで、推薦エンジン１１２は、類似度が高い順に上位Ｎ個のアイテムを該当アイテムの関連アイテムに設定し（Ｓ３２２）、関連アイテムの算出に係る一連の処理を終了する。

（類似度計算による関連アイテム算出方法のまとめ）
ここで、図２２を参照しながら、類似度計算による関連アイテムの算出方法について概念的な説明を加える。図２２は、上記の類似度計算による関連アイテムの算出方法を概念的に示した説明図である。

図２２に示すように、まず、推薦エンジン１１２により、該当アイテムのアイテム情報ベクトルと、対象ベクトルのアイテム情報ベクトルとに基づいて類似度が計算される（Ｓｔｅｐ．１）。ここで算出された類似度は対象アイテム毎に結果リストに記録される。さらに、結果リストに記録された類似度には、該当アイテムの関連アイテムメタに関する類似度が加算される（Ｓｔｅｐ．２）。このとき、該当アイテムの関連アイテムに対する各対象アイテムの類似度には、それぞれ所定の重みが乗算される。そして、その乗算値が結果リストに記録された対象アイテム毎の類似度に加算される。その後、結果リストのレコードは、類似度が大きい順にソートされる（Ｓｔｅｐ．３）。推薦エンジン１１２は、ソート後の結果リストから類似度が高い順に関連アイテムを抽出し、該当アイテムの関連アイテムとして提供する。

上記の方法は、該当アイテムのアイテム情報ベクトルと対象アイテムのアイテム情報ベクトルとの間で類似度計算が完了した後に、関連アイテムメタの重みを足しあわせるというものであった。これの応用として、例えば、該当アイテムのアイテム情報ベクトルと対象アイテムのアイテム情報ベクトルとの間で類似度計算が実行される際に、アイテム情報ベクトルの一要素として関連アイテムメタを付加する方法も考えられる。この方法を利用しても、上記の方法と同様の計算が実現できる。

（応用例１）
そこで、図２３、図２４を参照しながら、アイテム情報ベクトルの一要素に関連アイテムメタを付加する方法について簡単に説明する。図２３は、この方法で利用されるアイテム情報ベクトル（またはユーザ嗜好ベクトル）の構成例を示す説明図である。図２４は、アイテム情報ベクトルの一要素に関連アイテムメタを付加する方法による関連アイテムの決定処理の流れを示す説明図である。

図２４に示すように、まず、推薦エンジン１１２は、アイテム情報ＤＢ１１４から該当アイテムのアイテム情報を取得する（Ｓ３３２）。次いで、推薦エンジン１１２は、該当アイテムで用いるメタタイプの情報に基づいてアイテム情報ベクトルを構築する（Ｓ３３４）。次いで、推薦エンジン１１２は、計算対象となる対象ベクトル群を全アイテムの中から選択する（Ｓ３３６）。次いで、推薦エンジン１１２は、反復処理（Ａ）を実行する。この反復処理（Ａ）は、対象アイテム群に含まれる全ての対象アイテムについて反復実行される。

推薦エンジン１１２は、対象アイテム群から１つの対象アイテムを選択し（反復処理（Ａ）の開始）、その対象アイテムのアイテム情報をアイテム情報ＤＢ１１４から取得する（Ｓ３３８）。次いで、推薦エンジン１１２は、対象アイテムで用いるメタタイプの情報に基づいてアイテム情報ベクトルを構築する（Ｓ３４０）。次いで、推薦エンジン１１２は、該当アイテムのアイテム情報ベクトルと、対象アイテムのアイテム情報ベクトルとの間の類似度を計算し、その計算結果を結果リストに記録する（Ｓ３４２）。次いで、推薦エンジン１１２は、対象ベクトル群に含まれる他の対象ベクトルを選択し、その対象ベクトルについて再びステップＳ３３８〜Ｓ３４２の処理を実行する（反復処理（Ａ）の継続）。ただし、推薦エンジン１１２は、対象ベクトル群に含まれる全ての対象ベクトルについてステップＳ３３８〜Ｓ３４２の処理を実行した場合（反復処理（Ａ）の終了）、ステップＳ３４４の処理に進行する。

ステップＳ３４４では、推薦エンジン１１２により、類似度が大きい順に結果リストのレコードをソートする（Ｓ３４４）。次いで、推薦エンジン１１２は、類似度が大きい順に上位Ｎ個のアイテムを結果リストから抽出して該当アイテムの関連アイテムに決定する（Ｓ３４６）。その後、推薦エンジン１１２は、類似度計算に基づく関連アイテムの算出に係る一連の処理を終了する。

この方法を用いることで、協調フィルタリングとコンテンツベースフィルタリングの要素を織り交ぜた結果が算出可能である上、コンテンツベースフィルタリングの計算と協調フィルタリングの計算とが同時に行われるため、高速な計算が実現される。

（応用例２）
ところで、上記の方法とは異なり、コンテンツベースフィルタリングの結果に関連アイテムメタ間の類似度を付加することで、協調フィルタリングの要素を加味した結果を得る方法も１つの応用例として考えられる。この場合、アイテム情報ベクトル（またはユーザ嗜好ベクトル）の構成が、図２５に示すように変形される。ただし、基本的な処理の流れは、図２４と実質的に同一であるため、詳細な説明を省略する。

［関連アイテムの提示方法］
次に、図２６、および図２７を参照しながら、上記の推薦エンジン１１２による関連アイテムの提示方法について説明する。図２６は、関連アイテムの提示方法に係る一連の処理の流れを示す説明図である。図２７は、図２６に示す処理の変形例を示す説明図である。

図２６に示すように、まず、推薦エンジン１１２は、情報機器１０を介してユーザから指定されたアイテムの関連アイテムを取得する（Ｓ３５２）。次いで、推薦エンジン１１２は、関連アイテムメタの中で、関連度が高い順に上位Ｎ個の関連アイテムを算出し、その関連アイテム群を情報機器１０に提示する（Ｓ３５４）。

図２６に示した方法の場合、推薦エンジン１１２は、ユーザの嗜好を用いずに関連アイテムを算出している。そのため、アクセスしてきたユーザがどのような嗜好を持っているかが考慮されずに、嗜好が異なっても同じアイテムが関連アイテムとして提示されてしまう。そこで、この方法の中で、ユーザの嗜好を考慮した関連アイテムの提示ができるように変形したものが図２７の処理である。図２７の処理によると、アイテム間の関係を利用しつつ、アクセスしてきたユーザの嗜好に合った関連アイテムを提示できるものと考えられる。そこで、図２７の処理について説明する。

図２７に示すように、まず、推薦エンジン１１２は、情報機器１０を介してユーザから指定されたアイテムの関連アイテムを取得する（Ｓ３６２）。次いで、推薦エンジン１１２は、該当アイテムにアクセスしたユーザ（以下、該当ユーザ）の嗜好をユーザ嗜好情報ＤＢ２０４より取得する（Ｓ３６４）。次いで、推薦エンジン１１２は、該当ユーザの嗜好情報と、ステップＳ３６２で取得した関連アイテム群との間の関連度を計算し、関連アイテム群に含まれるアイテムを関連度が高い順にソートする（Ｓ３６６）。次いで、推薦エンジン１１２は、関連アイテム群の中で、関連度が高い順に上位Ｎ個の関連アイテムを算出し、その関連アイテム群を情報機器１０に提示する（Ｓ３６８）。

以上、本発明の第１および第２実施形態について説明した。また、各実施形態について、種々の変形例、および応用例を示した。これらの実施形態に係る技術を適用することで、コンテンツベースフィルタリングの枠組みの中で、協調フィルタリングのようなユーザの嗜好を考慮した関連アイテムの提示が可能になる。さらに、ユーザ数が少ない場合にも、アイテム間の類似度を利用して関連アイテムが提示されるため、コールドスタート問題に対する解決手段を提供することにも繋がる。さらに言えば、１度も参照されていないアイテムに対しても、関連アイテムの提示が可能になる。逆に、メタが少ないアイテムに関しても、関連アイテムを提示できるようになる。

このように、上記の実施形態に係る技術を用いることで様々な効果が得られる。そして、この効果は、ユーザが自身の持つ嗜好の幅を広げることにも役立つし、逆に、ユーザの潜在的な嗜好により適合した関連アイテムの推薦が実現される。

［ハードウェア構成（情報処理装置）］
上記の各システムが有する構成要素の機能は、例えば、図２８に示すハードウェア構成を有する情報処理装置により、上記の機能を実現するためのコンピュータプログラムを用いて実現することが可能である。図２８は、上記の各システムが有する構成要素の機能を実現することが可能な情報処理装置のハードウェア構成を示す説明図である。この情報処理装置の形態は任意であり、例えば、パーソナルコンピュータ、携帯電話、ＰＨＳ（Ｐｅｒｓｏｎａｌ Ｈａｎｄｙ−ｐｈｏｎｅ Ｓｙｓｔｅｍ）、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）等の携帯情報端末、ゲーム機、または各種の情報家電等がこれに含まれる。

図２８に示すように、この情報処理装置は、主に、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）９０２と、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）９０４と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）９０６と、ホストバス９０８と、ブリッジ９１０と、外部バス９１２と、インターフェース９１４と、入力部９１６と、出力部９１８と、記憶部９２０と、ドライブ９２２と、接続ポート９２４と、通信部９２６とにより構成される。

ＣＰＵ９０２は、例えば、演算処理装置、または制御装置として機能し、ＲＯＭ９０４、ＲＡＭ９０６、記憶部９２０、またはリムーバブル記録媒体９２８に記録された各種プログラムに基づいて各構成要素の動作全般またはその一部を制御する。ＲＯＭ９０４は、例えば、ＣＰＵ９０２に読み込まれるプログラムや演算に用いるデータ等を格納する。ＲＡＭ９０６は、例えば、ＣＰＵ９０２に読み込まれるプログラムや、そのプログラムを実行する際に適宜変化する各種パラメータ等を一時的または永続的に格納する。これらの構成要素は、例えば、高速なデータ伝送が可能なホストバス９０８によって相互に接続されている。また、ホストバス９０８は、例えば、ブリッジ９１０を介して比較的データ伝送速度が低速な外部バス９１２に接続されている。

入力部９１６は、例えば、マウス、キーボード、タッチパネル、ボタン、スイッチ、およびレバー等の操作手段である。また、入力部９１６は、赤外線やその他の電波を利用して制御信号を送信することが可能なリモートコントロール手段（所謂、リモコン）であってもよい。なお、入力部９１６は、上記の操作手段を用いて入力された情報を入力信号としてＣＰＵ９０２に伝送するための入力制御回路等により構成されている。

出力部９１８は、例えば、ＣＲＴ（Ｃａｔｈｏｄｅ Ｒａｙ Ｔｕｂｅ）、ＬＣＤ（Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ）、ＰＤＰ（Ｐｌａｓｍａ ＤｉｓｐｌａｙＰａｎｅｌ）、またはＥＬＤ（Ｅｌｅｃｔｒｏ−Ｌｕｍｉｎｅｓｃｅｎｃｅ Ｄｉｓｐｌａｙ）等のディスプレイ装置、スピーカ、ヘッドホン等のオーディオ出力装置、プリンタ、携帯電話、またはファクシミリ等、取得した情報を利用者に対して視覚的または聴覚的に通知することが可能な装置である。

記憶部９２０は、各種のデータを格納するための装置であり、例えば、ハードディスクドライブ（ＨＤＤ；Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）等の磁気記憶デバイス、半導体記憶デバイス、光記憶デバイス、または光磁気記憶デバイス等により構成される。

ドライブ９２２は、例えば、磁気ディスク、光ディスク、光磁気ディスク、または半導体メモリ等のリムーバブル記録媒体９２８に記録された情報を読み出し、またはリムーバブル記録媒体９２８に情報を書き込む装置である。リムーバブル記録媒体９２８は、例えば、ＤＶＤメディア、Ｂｌｕ−ｒａｙメディア、ＨＤ−ＤＶＤメディア、コンパクトフラッシュ（登録商標）（ＣＦ；ＣｏｍｐａｃｔＦｌａｓｈ）、メモリースティック、またはＳＤメモリカード（Ｓｅｃｕｒｅ Ｄｉｇｉｔａｌ ｍｅｍｏｒｙ ｃａｒｄ）等である。リムーバブル記録媒体９２８は、例えば、非接触型ＩＣチップを搭載したＩＣカード（Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ Ｃａｒｄ）や電子機器等であってもよい。

接続ポート９２４は、例えば、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）ポート、ＩＥＥＥ１３９４ポート、ＳＣＳＩ（Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ Ｉｎｔｅｒｆａｃｅ）、ＲＳ−２３２Ｃポート、または光オーディオ端子等のような外部接続機器９３０を接続するためのポートである。外部接続機器９３０は、例えば、プリンタ、携帯音楽プレーヤ、デジタルカメラ、デジタルビデオカメラ、またはＩＣレコーダ等である。

通信部９２６は、ネットワーク９３２に接続するための通信デバイスであり、例えば、有線または無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、またはＷＵＳＢ（Ｗｉｒｅｌｅｓｓ ＵＳＢ）用の通信カード、光通信用のルータ、ＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ）用のルータ、または各種通信用のモデム等である。また、通信部９２６に接続されるネットワーク９３２は、有線または無線により接続されたネットワークであり、例えば、インターネット、家庭内ＬＡＮ、赤外線通信、可視光通信、放送、または衛星通信等である。

以上、添付図面を参照しながら本発明の好適な実施形態について説明したが、本発明は係る例に限定されないことは言うまでもない。当業者であれば、特許請求の範囲に記載された範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、それらについても当然に本発明の技術的範囲に属するものと了解される。

本発明の第１実施形態に係る関連アイテム提供システムのシステム構成を示す説明図である。 同実施形態に操作ログＤＢの構成例を示す説明図である。 同実施形態にアクセスウェイトＤＢの構成例を示す説明図である。 同実施形態に関連アイテムメタＤＢの構成例を示す説明図である。 同実施形態にアイテム情報ＤＢの構成例を示す説明図である。 同実施形態に係る関連アイテム付与方法の流れを示す説明図である。 同実施形態に係るアイテムベクトル、およびユーザ嗜好ベクトルの構成例を示す説明図である。 同実施形態に係る関連アイテム付与方法の流れを示す説明図である。 同実施形態に係る関連アイテムの類似度計算方法を示す説明図である。 同実施形態に係る関連アイテム付与方法の流れを示す説明図である。 同実施形態に係る関連アイテムの類似度計算方法を示す説明図である。 本発明の第２実施形態に係る関連アイテム提供システムのシステム構成を示す説明図である。 同実施形態に係るユーザ嗜好情報ＤＢの構成例を示す説明図である。 同実施形態に係る関連アイテム付与方法の流れを示す説明図である。 同実施形態に係る関連アイテム付与方法の流れを示す説明図である。 同実施形態に係る関連アイテム付与方法の流れを示す説明図である。 同実施形態に係る関連アイテム付与方法の流れを示す説明図である。 同実施形態に係る関連アイテム付与方法の流れを示す説明図である。 同実施形態に係る関連アイテムの類似度計算方法を示す説明図である。 同実施形態に係る関連アイテム付与方法の流れを示す説明図である。 同実施形態に係る関連アイテム付与方法の流れを示す説明図である。 同実施形態に係る関連アイテムの類似度計算方法を示す説明図である。 同実施形態に係る関連アイテムの類似度計算方法を示す説明図である。 同実施形態に係る関連アイテム付与方法の流れを示す説明図である。 同実施形態に係る関連アイテムの類似度計算方法を示す説明図である。 同実施形態に係る関連アイテム付与方法の流れを示す説明図である。 同実施形態に係る関連アイテム付与方法の流れを示す説明図である。 本発明の各実施形態に係る関連アイテム提供システムが有する機能を実現することが可能な情報処理装置のハードウェア構成例を示す説明図である。

符号の説明

１０ 情報機器
１００、２００ 関連アイテム提供システム
１０２ 操作ログＤＢ
１０４、２０２ 嗜好抽出エンジン
１０６ アクセスウェイトＤＢ
１０８ 関連性抽出エンジン
１１０ 関連アイテムメタＤＢ
１１２ 推薦エンジン
１１４ アイテム情報ＤＢ
１１６、２０６ 救済措置エンジン
２０４ ユーザ嗜好情報ＤＢ

Claims (5)

1. 情報機器を用いてユーザがアイテムにアクセスした履歴を示す操作ログをユーザとアイテムの組み合わせ毎に格納した第１のデータベースから、前記操作ログを取得して各アイテムに対する各ユーザの嗜好度合いを表す嗜好度を算出する嗜好抽出部と、
   前記嗜好抽出部によって算出された嗜好度のうち、同じユーザに対応する第１及び第２のアイテムにそれぞれ対応付けられた第１及び第２の嗜好度の積算値に基づいて当該第１及び第２のアイテムの間の関連度を算出する関連性抽出部と、
   前記第１のアイテムが要求された場合に、前記関連性抽出部によって算出された関連度が高い順に所定数の前記第２のアイテムを関連アイテムとして提供するアイテム推薦部と、
   を備え、
   前記アイテムには、所定のメタデータが付与されており、
   前記所定のメタデータには、種類毎に前記アイテムが持つ前記メタデータの偏りを算出した所定の重み値が設定されており、
   前記嗜好抽出部は、前記操作ログから各ユーザに対応するアイテムを検出し、検出したアイテムのそれぞれに付与されたメタデータの重み値を積算して嗜好度を算出する、
   情報処理装置。
2. 前記アイテムには、有効期間が設定されており、
   前記関連性抽出部は、前記嗜好抽出部によって嗜好度が算出されたアイテムのうち、有効期間中のアイテムを対象に、前記第１及び第２のアイテムの間の関連度を算出する、
   請求項１に記載の情報処理装置。
3. 要求された前記第１のアイテムに対して前記関連性抽出部によって関連度が算出された第２のアイテムの数Ｍが所定数Ｎより少ない場合（Ｍ＜Ｎ）に、前記要求された第１のアイテムに付与されたメタデータと同じ種類のメタデータが付与された第３のアイテムに関連する第４のアイテムを関連度が高い順に抽出する救済措置部をさらに備える、
   請求項１に記載の情報処理装置。
4. 情報処理装置により、
   情報機器を用いてユーザがアイテムにアクセスした履歴を示す操作ログをユーザとアイテムの組み合わせ毎に格納した第１のデータベースから、前記操作ログを取得して各アイテムに対する各ユーザの嗜好度合いを表す嗜好度が算出される嗜好抽出ステップと、
   前記嗜好抽出ステップにて算出された嗜好度のうち、同じユーザに対応する第１及び第２のアイテムにそれぞれ対応付けられた第１及び第２の嗜好度の積算値に基づいて当該第１及び第２のアイテムの間の関連度が算出される関連性抽出ステップと、
   前記第１のアイテムが要求された場合に、前記関連性抽出ステップにて算出された関連度が高い順に所定数の前記第２のアイテムが関連アイテムとして提供されるアイテム推薦ステップと、
   を含み、
   前記アイテムには、所定のメタデータが付与されており、
   前記所定のメタデータには、種類毎に前記アイテムが持つ前記メタデータの偏りを算出した所定の重み値が設定されており、
   前記嗜好抽出ステップは、前記操作ログから各ユーザに対応するアイテムを検出し、検出したアイテムのそれぞれに付与されたメタデータの重み値を積算して嗜好度を算出する工程である、
   関連アイテムの提供方法。
5. 情報機器を用いてユーザがアイテムにアクセスした履歴を示す操作ログをユーザとアイテムの組み合わせ毎に格納した第１のデータベースから、前記操作ログを取得して各アイテムに対する各ユーザの嗜好度合いを表す嗜好度を算出する嗜好抽出機能と、
   前記嗜好抽出機能によって算出された嗜好度のうち、同じユーザに対応する第１及び第２のアイテムにそれぞれ対応付けられた第１及び第２の嗜好度の積算値に基づいて当該第１及び第２のアイテムの間の関連度を算出する関連性抽出機能と、
   前記第１のアイテムが要求された場合に、前記関連性抽出機能によって算出された関連度が高い順に所定数の前記第２のアイテムを関連アイテムとして提供するアイテム推薦機能と、
   をコンピュータに実現させるためのプログラムであり、
   前記アイテムには、所定のメタデータが付与されており、
   前記所定のメタデータには、種類毎に前記アイテムが持つ前記メタデータの偏りを算出した所定の重み値が設定されており、
   前記嗜好抽出機能は、前記操作ログから各ユーザに対応するアイテムを検出し、検出したアイテムのそれぞれに付与されたメタデータの重み値を積算して嗜好度を算出する、
   プログラム。

Images