説明

情報処理装置、および関連アイテムの提供方法

【課題】ユーザの嗜好とアイテム間の関連性を考慮して推薦すべき関連アイテムを提示することが可能なシステムを提供すること。
【解決手段】情報処理装置により、所定のアイテムに対し、ユーザの行動履歴に基づいて計算対象アイテムに関連付けられたメタ情報が追加されるステップと、前記所定のアイテムと前記計算対象アイテムとの間の類似度が算出されるステップと、前記類似度が高い順に所定数の計算対象アイテムが前記所定のアイテムの関連アイテムに決定されるステップと、前記関連アイテムがユーザに提示されるステップとを含む、関連アイテムの提供方法およびこれを実現するためのシステムが提供される。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、情報処理装置、および関連アイテムの提供方法に関する。
【背景技術】
【0002】
近年、情報処理技術、および通信技術の急速な発展に伴い、大量の情報がネットワークを通じて提供されるようになってきた。また、ユーザが保有する情報機器の形態が多様化する中で、多種多様な情報が提供されるようになってきている。例えば、インターネット等の広域ネットワークを介してパーソナルコンピュータ(以下、PC)等に配信される情報もあれば、テレビジョン受像機等に配信される放送番組や放送情報等もある。こうした状況に鑑み、膨大な情報の中からユーザが好む情報(以下、嗜好情報)を効率良く提供するための技術に注目が集まっている。例えば、ユーザの嗜好により良く適合する情報を漏れなく選択するための技術には高い関心が寄せられている。
【0003】
こうした技術に関連し、例えば、下記の特許文献1には、個々のユーザの嗜好等を考慮し、より適切な情報をユーザに提供できるようにするための情報処理装置が記載されている。この情報処理装置は、複数ユーザの嗜好に関するデータを用いてユーザ同士の相関度を算出する機能を有する。さらに、この情報処理装置は、例えば、1つの相関度に関連する2人のユーザに関し、一方のユーザが有する要素を他方のユーザが保持していない場合に他方のユーザに当該要素に関連する要素を提供する機能を有する。つまり、あるユーザの操作履歴等を用いても当該ユーザに提供されない情報が、そのユーザに関連する他のユーザとの間の相関度に基づいて提供されるようになる。
【0004】
【特許文献1】特開2005−57713号公報
【発明の開示】
【発明が解決しようとする課題】
【0005】
上記文献1の他にも、例えば、協調フィルタリング(CF;Collaborative−Filtering)や、コンテンツベースフィルタリング(CBF;Content−Based−Filtering)と呼ばれる技術が知られている。協調フィルタリング法は、多くのユーザに関する嗜好情報を蓄積しておき、あるユーザに関して嗜好が類似する他のユーザの情報を用いて自動的に提供すべき情報を推定する方法である。一方、コンテンツベースフィルタリングは、あるコンテンツに関連するコンテンツをコンテンツ間の類似度に基づいて抽出するという方法である。これらの方法を用いて情報を提供するシステムのことを推薦システムと呼ぶことがある。
【0006】
上記の通り、協調フィルタリングは、ユーザの行動履歴間の関連度に基づいて情報を提供する手法である。つまり、あるコンテンツに対し、ユーザの行動履歴などから抽出される間接的に関連する情報を提供するものであり、あるコンテンツと直接に関連する情報を提供するものではない。また、協調フィルタリングは、所定数以上の嗜好情報が集まらないとユーザの嗜好に適合した情報が抽出されない。さらに、ユーザの操作履歴等により抽出される情報の数が十分でない場合に、その数を拡充することが難しい。一方、コンテンツベースフィルタリングは、コンテンツと直接関連する情報を提供するものであるため、ユーザの行動履歴などから抽出される間接的にコンテンツに関連した情報を提供するものではない。
【0007】
そこで、本発明は、上記問題に鑑みてなされたものであり、本発明の目的とするところは、コンテンツと直接関連する情報と間接的に関連する情報を考慮した関連コンテンツの算出が可能な、新規かつ改良された情報処理装置、および関連アイテムの提供方法を提供することにある。
【課題を解決するための手段】
【0008】
上記課題を解決するために、本発明のある観点によれば、所定のアイテムと計算対象アイテムとの間の類似度を計算する第1類似度計算部と、前記類似度が高い順に所定数の計算対象アイテムを前記所定のアイテムの関連アイテムに決定する関連アイテム決定部と、を備え、前記所定のアイテムに対し、ユーザの行動履歴に基づいて前記計算対象アイテムに関連付けられたメタ情報を追加した上で、前記所定のアイテムと前記計算対象アイテムとの間の類似度を算出する、情報処理装置が提供される。
【0009】
このように、上記の情報処理装置は、第1類似度計算部により、所定のアイテムと計算対象アイテムとの間の類似度を計算する。また、この情報処理装置は、関連アイテム決定部により、前記類似度が高い順に所定数の計算対象アイテムを前記所定のアイテムの関連アイテムに決定する。そして、この情報処理装置は、前記所定のアイテムに対し、ユーザの行動履歴に基づいて前記計算対象アイテムに関連付けられたメタ情報を追加した上で、前記所定のアイテムと前記計算対象アイテムとの間の類似度を算出する。
【0010】
また、上記の情報処理装置は、前記所定のアイテムに関連付けられた関連アイテムの中に前記計算対象アイテムが含まれる場合、当該計算対象アイテムの関連度を前記第1類似度計算部により算出された当該計算対象アイテムの類似度に加算する関連度加算部をさらに備えていてもよい。
【0011】
また、上記の情報処理装置は、所定のアイテムのメタ情報と同じメタ情報を保持する候補アイテムに対し、ユーザの行動履歴に基づいて関連付けられた関連アイテムの関連度を取得する関連度取得部と、前記所定のアイテムと前記関連アイテムまたは前記候補アイテムとの間の類似度を取得する類似度取得部と、前記関連度および前記類似度に基づき、前記関連アイテムまたは候補アイテムと前記所定のアイテムとの間の類似度を計算する第2類似度計算部と、前記関連アイテム決定部により決定された関連アイテム数が前記所定数未満の場合、前記第2類似度計算部により計算された類似度が大きい順にアイテムを選択して前記関連アイテムに追加する関連アイテム追加部と、をさらに備えていてもよい。
【0012】
また、前記第2類似度計算部は、前記類似度取得部により前記所定のアイテムと前記関連アイテムとの間の類似度が取得された場合、当該類似度と前記関連度とを乗算し、その乗算値を前記所定のアイテムと前記候補アイテムとの間の類似度としてもよい。この場合、前記関連アイテム追加部は、前記第2類似度計算部により算出された類似度が大きい順に前記候補アイテムを選択して前記関連アイテムに追加する。
【0013】
また、前記第2類似度計算部は、前記類似度取得部により前記所定のアイテムと前記候補アイテムとの間の類似度が取得された場合、当該類似度と前記関連度とを乗算し、その乗算値を前記所定のアイテムと前記関連アイテムとの間の類似度としてもよい。この場合、前記関連アイテム追加部は、前記第2類似度計算部により算出された類似度が大きい順に前記関連アイテムを選択して前記関連アイテムに追加する。
【0014】
また、前記関連度取得部は、前記所定のアイテムが保持するメタ情報の中で、予めメタ情報毎に設定された優先度が高いメタ情報を保持する前記候補アイテムについて前記関連アイテムの関連度を取得するように構成されていてもよい。
【0015】
また、上記の情報処理装置は、前記所定のアイテムにアクセスするユーザの嗜好または前記所定のアイテムが保持するメタ情報の統計データに応じてメタ情報毎の優先度を設定する優先度設定部をさらに備えていてもよい。この場合、前記関連度取得部は、前記所定のアイテムが保持するメタ情報の中で、前記優先度設定部により設定された優先度が高いメタ情報を保持する前記候補アイテムについて前記関連アイテムの関連度を取得する。
【0016】
また、前記関連度取得部は、前記所定のアイテムが保持する全てのメタ情報を保持する前記候補アイテムについて前記関連アイテムの関連度を取得し、前記候補アイテム毎に全ての関連度を積算して当該候補アイテムの関連度としてもよい。
【0017】
また、前記所定のアイテムに関連付けられたアイテムを第1の関連アイテムとし、第N−1の関連アイテム(N≧2)の関連付けられたアイテムを第Nの関連アイテムとすると、前記関連度取得部は、前記第K−1の関連アイテムと第Kの関連アイテムとの間の関連度(2≦K≦N)を全て乗算し、前記第1の関連アイテムと前記第Nの関連アイテムとの間の関連度を取得することもできる。
【0018】
また、上記の情報処理装置は、前記ユーザの嗜好が近い順に前記関連アイテムをソートして当該ユーザに提示する関連アイテム提示部をさらに備えていてもよい。
【0019】
また、上記課題を解決するために、本発明の別の観点によれば、情報処理装置により、所定のアイテムに対し、ユーザの行動履歴に基づいて計算対象アイテムに関連付けられたメタ情報が追加されるステップと、前記所定のアイテムと前記計算対象アイテムとの間の類似度が算出されるステップと、前記類似度が高い順に所定数の計算対象アイテムが前記所定のアイテムの関連アイテムに決定されるステップと、前記関連アイテムがユーザに提示されるステップと、を含む、関連アイテムの提供方法が提供される。
【発明の効果】
【0020】
以上説明したように本発明によれば、コンテンツと直接関連する情報と間接的に関連する情報を考慮した関連コンテンツの算出が可能になる。特に、コンテンツベースフィルタリングの枠組みの中で、協調フィルタリングによる結果も一緒に計算できるようになる。
【発明を実施するための最良の形態】
【0021】
以下に添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。なお、本明細書および図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
【0022】
[課題の整理]
ユーザに対して情報を提供する際に、そのユーザ(以下、提供先ユーザ)の嗜好に適合した情報を選択する技術として、協調フィルタリングと呼ばれる技術が知られている。この技術は、例えば、提供先ユーザの操作履歴等に基づいて提供先ユーザの類似ユーザを探索し、その類似ユーザに関連付けられた関連アイテムの中から提供すべき推薦アイテムを算出するというものである。特に、類似ユーザの関連アイテムの中で、提供先ユーザに関連付けられていないアイテムが提供先ユーザに提供される。つまり、ユーザ間の類似性を介して間接的に推薦アイテムが抽出されるのである。
【0023】
具体例を挙げると、協調フィルタリングに係る処理は次のようになる。まず、提供先ユーザの操作履歴に基づいて提供先ユーザの類似ユーザが発見される。次に、類似ユーザが好むアイテムが抽出され、類似ユーザの好むアイテムを提供先ユーザが知らないならば、その知らないアイテムを提供先ユーザに推薦するという処理が実行される。ここで、類似ユーザの好むアイテムというのが、上記の関連アイテムである。この例から分かる通り、提供先ユーザと推薦アイテムとの間の直接的な関連性は考慮されていない。さらに言えば、提供先ユーザに推薦されるアイテムと、提供先ユーザが元々好んでいるアイテムとの間の直接的な関連性は考慮されていない。
【0024】
このように、提供先ユーザと推薦アイテムとの間の関連性は、提供先ユーザと類似ユーザとの間の類似性を介して間接的に算出されるものである。そのため、提供先ユーザに元々関連付けられている関連アイテムと推薦アイテムとの間の直接的な関連性は、協調フィルタリングにおいて考慮されないのである。なお、ここで言うアイテムには、放送番組等のコンテンツやコンテンツに関する情報(例えば、番組情報等)の他に、ユーザ自身も含まれる。従って、上記の例を参照すれば、提供先ユーザと類似ユーザとの間の関係は直接的なアイテム間の関係に相当する。また、類似ユーザと推薦アイテムとの間の関係も直接的な関係に相当する。しかしながら、提供先ユーザと推薦アイテムとの間の関係は、あくまでも類似ユーザを介した間接的なアイテム間の関係であると言える。
【0025】
ところで、関連アイテムの提供サービスが開始された当初は、アイテムの提供サーバ等に対するアクセス数が少ないことが多く、そもそも、ユーザ数が少ない場合も多い。この場合、上記の協調フィルタリングを用いる推薦システムでは、ユーザの嗜好情報が十分に取得できないため、ユーザの嗜好に良く適合した関連アイテムを提供することが難しい(所謂、コールドスタート問題)。もちろん、時間の経過と共に提供される関連アイテムの数が増加するものの、サービスの開始初期においては、十分な数の関連アイテムが提供されないことがある。そのため、ユーザの嗜好情報を拡充するための技術が研究されている。
【0026】
例えば、ユーザが好みそうなメタ情報を予測し、その予測結果を利用してユーザの嗜好情報を拡充する技術が提案されている。この技術を用いることにより、協調フィルタリングを実行する際に利用される嗜好情報の数が拡充され、サービスの開始初期であっても、十分な数の関連アイテムを提供することができるようになる。つまり、この技術は、ユーザの嗜好情報を予測に基づいて拡充する技術である。
【0027】
一方で、アイテム間の類似度を計算し、その類似度が高いアイテムを関連アイテムとして推薦する技術が知られている。この技術は、アイテム間の直接的な関連性のみを考慮して関連アイテムを算出する技術であり、コンテンツベースフィルタリングと呼ばれる。例えば、この技術を用いた推薦システムは、提供先ユーザの好むアイテムに関連するアイテムを検索し、発見されたアイテムを提供先ユーザに推薦する。
【0028】
ここで、より具体的な推薦処理について述べる。コンテンツベースフィルタリングを用いる推薦システムでは、複数アイテムの各々についてアイテムベクトルと呼ばれるベクトル量を算出し、そのアイテムベクトルに基づいてアイテム同士の類似度を算出する。このとき、推薦システムは、各アイテムに付与されたメタ情報に基づいてアイテムベクトルを生成する。上記の処理内容からも分かる通り、コンテンツベースフィルタリングでは、上記の協調フィルタリングとは異なり、アイテム間の直接的な類似度に基づいて推薦アイテムが算出される。また、付与されたメタ情報が少ないアイテムについては、そのアイテムに関連する関連アイテムの算出が難しい場合もある。
【0029】
以下で説明する実施形態は、上記の協調フィルタリングのように間接的なアイテム間の関連性を考慮しつつ、コンテンツベースフィルタリングのようにアイテム間の直接的な類似度に基づいて関連アイテムを抽出する技術を提供するものである。これまで、アイテム間の直接的な類似性とユーザ間の関連性を媒介とする間接的な関連性とを共に考慮して関連アイテムを提供しようとすると、協調フィルタリングの計算とコンテンツベースフィルタリングの計算とを別々に実行する必要があった。
【0030】
しかし、下記の実施形態に係る技術を用いると冗長な計算をせずに済むため、演算処理が簡素化され、関連アイテムの算出処理に掛かる演算負荷や演算時間の低減が期待される。さらに、下記の実施形態に係る技術は、コンテンツベースフィルタリングの要素を含むため、上記のコールドスタート問題に対する解決手段を提供するものでもある。
【0031】
<第1実施形態>
まず、本発明に係る第1実施形態について説明する。本実施形態は、CBF(Content−Based−Filtering)の枠組みの中で、CF(Collaborative−Filtering)による結果も一緒に計算できるようにした関連アイテムの算出方法に関する。以下、関連アイテムメタの付与方法、関連アイテムメタに基づく関連アイテムの算出方法、関連アイテムの提示方法の順で説明する。まず、これらの方法を実現することが可能な関連アイテム提供システム100の構成例について説明する。
【0032】
[関連アイテム提供システム100の構成例]
図1を参照しながら、本実施形態に係る関連アイテム提供システム100のシステム構成について説明する。図1は、本実施形態に係る関連アイテム提供システム100の構成例を示す説明図である。
【0033】
図1に示すように、関連アイテム提供システム100は、主に、操作ログDB102と、嗜好抽出エンジン104と、アクセスウェイトDB106と、関連性抽出エンジン108と、関連アイテムメタDB110と、推薦エンジン112と、アイテム情報DB114と、救済措置エンジン116とを含む。
【0034】
また、関連アイテム提供システム100は、ユーザが操作する情報機器10に直接またはネットワークを介して接続されており、情報機器10の操作ログを取得したり、情報機器10に関連アイテムを提供したりすることができる。図1には、便宜上、情報機器10が1台しか描画されていないが、2台以上であってもよい。
【0035】
なお、操作ログDB102、アクセスウェイトDB106、関連アイテムメタDB110、およびアイテム情報DB114は、所定の記憶装置に格納されている。この記憶装置としては、例えば、後述するハードウェア構成例の中で、RAM906、記憶部920、またはリムーバブル記憶媒体928等が対応する。
【0036】
(操作ログDB102)
操作ログDB102は、情報機器10の操作ログが格納されるデータベース(DB;Data Base)である。つまり、情報機器10の操作ログ等の情報は、関連アイテム提供システム100により取得され、操作ログDB102に格納される。操作ログDB102に格納された情報は、後述する嗜好抽出エンジン104により読み出される。
【0037】
ここで、図2を参照しながら、操作ログDB102の構成例について説明する。図2は、本実施形態に係る操作ログDB102の構成例を示す説明図(図表1)である。図表1の例では、操作ログDB102には、アイテムID(ItemID)、ユーザID(MemberID)、ログタイプ(LogType)、ログ記録日時(LogTime)の欄が設けられている。
【0038】
アイテムIDの欄に記録される情報は、各アイテムを示す識別情報(ID)である。ユーザIDの欄に記録される情報は、各ユーザを示す識別情報(ID)である。ログタイプの欄に記録される情報は、各操作ログの種類を示す情報である。ログ記録日時の欄に記録される情報は、そのレコードの操作ログが記録された日時を示す情報である。
【0039】
例えば、アイテムID=1011の行を参照すると、ユーザIDに2が記録され、ログタイプに“detail”が記録され、ログ記録日時に“2007−12−05 08:39:54”が記録されている。つまり、アイテムID=1011に対し、ユーザID=2のユーザが2007年12月5日8時39分54秒にアクセスしたことを示している。さらに、ログタイプが“detail”であることから、そのアイテムの詳細情報まで視聴されたことが分かる。図表1に示した構成は一例であるが、この例のように、ユーザの操作ログが時間情報と共に記録される。
【0040】
(嗜好抽出エンジン104)
再び図1を参照する。嗜好抽出エンジン104は、操作ログDB102からユーザの操作ログを取得し、ユーザ毎に各アイテムに対するアクセスウェイトを計算する。嗜好抽出エンジン104により算出されたアクセスウェイトは、後述するアクセスウェイトDB106に格納される。なお、ここで言うアクセスウェイトとは、あるユーザが特定のアイテムをどれだけ好んでいるかを示す指標であり、嗜好の度合いを示す情報である。例えば、アイテムID=1011のアイテムに対するユーザID=2のユーザの嗜好が強い場合、ユーザID=2、アイテムID=1011に対するアクセスウェイトは大きな値となる。つまり、アクセスウェイトは、嗜好情報の一例である。このアクセスウェイトの計算方法については後述する。
【0041】
(アクセスウェイトDB106)
アクセスウェイトDB106は、嗜好抽出エンジン104により算出されたアクセスウェイトが格納されるデータベースである。言い換えると、アクセスウェイトDB106は、ユーザの操作ログを解析して得られた結果(嗜好情報)が格納されるデータベースである。アクセスウェイトDB106に格納された情報は、後述する関連性抽出エンジン108により読み出される。
【0042】
ここで、図3を参照しながら、アクセスウェイトDB106の構成例について説明する。図3は、本実施形態に係るアクセスウェイトDB106の構成例を示す説明図(図表2)である。図表2の例では、アクセスウェイトDB106には、アイテムID(ItemID)、ユーザID(MemberID)、嗜好度(AccessWeight)、初期登録日時(EntryTime)、更新日時(UpdateTime)の欄が設けられている。
【0043】
アイテムIDの欄に記録される情報は、各アイテムを示す識別情報(ID)である。ユーザIDの欄に記録される情報は、各ユーザを示す識別情報(ID)である。嗜好度の欄に記録される情報は、各アイテムに対する各ユーザの嗜好度を示す情報である。つまり、この欄には、嗜好抽出エンジン104により算出されたアクセスウェイトが記録される。初期登録日時の欄に記録される情報は、アクセスウェイトDB106の各レコードに初期登録された日時を示す時間情報である。更新日時の欄に記録される情報は、アクセスウェイトDB106の各レコードが更新された日時を示す時間情報である。
【0044】
例えば、アイテムID=1010のレコードを参照すると、ユーザID=2のユーザがアイテムID=1010のアイテムに示す嗜好度が2.4であることが分かる。また、このユーザの嗜好度は、2007年12月5日8時40分52秒に初期登録された後、更新されていないことが分かる。さらに、図表2のアクセスウェイトDB106には、ユーザID=2のユーザについて、アイテムID=1001のアイテムに対する嗜好度と、アイテムID=1005のアイテムに対する嗜好度とが記録されている。アイテムID=1001のアイテムに対する嗜好度は1.0である。一方、アイテムID=1005のアイテムに対する嗜好度は6.0である。
【0045】
従って、図表2の例において、ユーザID=2のユーザは、アイテムID=1005のアイテムを最も好んでいることが分かる。そして、ユーザID=2のユーザは、アイテムID=1010のアイテム、アイテムID=1001のアイテムの順に高い嗜好を有していることが分かる。図表2に示した構成は一例であるが、この例のように、アクセスウェイトDB106には、嗜好情報がユーザID、アイテムID、および時間情報が共に記録され、各ユーザの嗜好度が管理されている。
【0046】
このように、アクセスウェイトDB106には、ユーザID、アイテムID、および嗜好度が関連付けられて記録されている。そのため、比較的高い嗜好度が付与されたアイテムIDを抽出し、抽出されたアイテムIDを共通して持つユーザのユーザIDを抽出することで、ユーザ間の類似性を算出することができる。つまり、同じアイテムIDのアイテムに対して高い嗜好度を有するユーザ間には、高い類似性が認められると考えるのである。また、同じユーザが高い嗜好度を有する複数のアイテム間には、一定の関連性があると考えることもできる。
【0047】
(関連性抽出エンジン108)
再び図1を参照する。関連性抽出エンジン108は、アクセスウェイトDB106から各アイテムに関連のあるアイテム(関連アイテム)を算出するための情報を取得する。この情報には、アイテムID、ユーザID、嗜好度が含まれる。そして、関連性抽出エンジン108は、取得した情報を用いて各アイテムの関連アイテムを算出する。例えば、関連性抽出エンジン108は、同じユーザの嗜好度が付与された複数のアイテムを抽出し、これらアイテムを相互に関連付ける。このとき、一方のアイテムは、他方のアイテムの関連アイテムとなる。なお、関連アイテムは、複数個抽出されることもある。
【0048】
このとき、関連性抽出エンジン108は、あるアイテム(該当アイテム)と関連アイテムとの間の関連性の強さを表す関連度を算出する。例えば、関連性抽出エンジン108は、該当アイテムの嗜好度と関連アイテムの嗜好度とに基づいて関連度を算出する。このとき、関連性抽出エンジン108は、例えば、該当アイテムの嗜好度と関連アイテムの嗜好度とを積算し、その積算値を正規化して関連度を算出する。関連性抽出エンジン108により算出された関連アイテムの情報は、関連アイテムメタDB110に記録される。この関連度とは、ユーザの操作履歴や作業履歴、またはコミュニティの活動状況等に基づくソーシャルな関係を用いて算出される値である。
【0049】
(関連アイテムメタDB110)
関連アイテムメタDB110は、関連性抽出エンジン108により算出された各アイテムの関連アイテムの情報と、各アイテム間の関連度とが格納されるデータベースである。関連アイテムメタDB110に格納された情報は、後述する推薦エンジン112により読み出される。
【0050】
ここで、図4を参照しながら、関連アイテムメタDB110の構成例について説明する。図4は、本実施形態に係る関連アイテムメタDB110の構成例を示す説明図(図表3)である。図表3の例では、関連アイテムメタDB110には、アイテムID(ItemID)、関連アイテムID(SimItemID)、関連度(Score)、初期登録日時(EntryTime)、更新日時(UpdateTime)の欄が設けられている。
【0051】
アイテムIDの欄に記録される情報は、各アイテムを示す識別情報(ID)である。関連アイテムIDの欄に記録される情報は、アイテムIDで指定されたアイテムの関連アイテム(関連アイテム)を示す識別情報(ID)である。関連度の欄に記録される情報は、アイテムIDで指定されたアイテムと、関連アイテムIDで指定されたアイテムとの間の関連性の強さを示す関連度である。初期登録日時の欄に記録される情報は、関連アイテムメタDB110の各レコードに初期登録された日時を示す時間情報である。更新日時の欄に記録される情報は、関連アイテムメタDB110の各レコードが更新された日時を示す時間情報である。
【0052】
例えば、図表3に示す関連アイテムメタDB110の中で、アイテムID=1001のアイテムに対応するレコードを検索すると、関連アイテムID=1002のレコードと、関連アイテムID=1003のレコードとが検出される。関連アイテムID=1002のレコードには、関連度=1.5が記録されている。一方、関連アイテムID=1003のレコードには、関連度=3.4が記録されている。これらの情報から、アイテムID=1001のアイテムは、少なくとも、アイテムID=1002、1003に対応する2つのアイテムと関連していることが分かる。さらに、アイテムID=1001のアイテムは、アイテムID=1002のアイテムに比べ、アイテムID=1003のアイテムとの間に大きな関連性を有することが分かる。
【0053】
このように、関連アイテムメタDB110には、アイテムID、関連アイテムID、および関連度が関連付けて記録されている。そのため、比較的高い関連度が付与された関連アイテムIDを抽出し、抽出された関連アイテムIDを共通して持つアイテムのアイテムIDを抽出することで、アイテム間の関連性を算出することができる。つまり、同じ関連アイテムIDのアイテムに対して高い関連度を有するアイテム間には、高い関連性が認められると考えられるのである。
【0054】
関連アイテムメタDB110に記録されている関連度は、アイテムIDのアイテムと、関連アイテムIDのアイテムとの間の直接的な関連性を示すものである。一方、関連アイテムメタDB110に基づいて算出される上記のアイテム間の関連性は、関連アイテムを介して得られる間接的な関連性を示すものである。
【0055】
(推薦エンジン112)
再び図1を参照する。推薦エンジン112は、関連アイテムメタDB110に記録されている情報に基づいて各アイテムの関連アイテムを情報機器10に提供する。例えば、情報機器10からアイテムAの関連アイテムが要求された場合、推薦エンジン112は、関連アイテムメタDB110に記録されたアイテムAの関連アイテムIDを参照し、この関連アイテムIDに対応する関連アイテムを情報機器10に提示する。このとき、推薦エンジン112は、後述するアイテム情報DB114から関連アイテムを取得する。また、推薦エンジン112は、情報機器10に提示する関連アイテムの個数が所定数に満たない場合、後述する救済措置エンジン116から関連アイテムを取得する。
【0056】
(アイテム情報DB114)
アイテム情報DB114は、個々のアイテムに付与された属性情報が格納されるデータベースである。アイテム情報DB114に格納された属性情報は、推薦エンジン112、および後述する救済措置エンジン116により読み出される。
【0057】
ここで、図5を参照しながら、アイテム情報DB114の構成例について説明する。図5は、本実施形態に係るアイテム情報DB114の構成例を示す説明図(図表4)である。図表4の例では、アイテム情報DB114には、アイテムID(ItemID)、メタタイプ(AttributeID;属性ID)、メタ(ValueID;属性値)、更新回数(NofTimes)、重要度(Score)の欄が設けられている。
【0058】
アイテムIDの欄に記録される情報は、各アイテムを示す識別情報(ID)である。メタタイプの欄に記録される情報は、各アイテムに付与された属性情報の種類を表す情報である。この欄には、例えば、ジャンル(Genre)、パーソン(Person)、キーワード(Keyword)、放送時間、放送局、タイトル(Title)等を示す識別情報(ID)が記録される。メタの欄には、各アイテムの属性値が記録される。例えば、この欄には、「アクション」「山田太郎」「正月」等を示す識別情報(ID)が記録される。更新回数の欄に記録される情報は、そのレコードが更新された回数である。重要度の欄に記録される情報は、そのレコードに記録されたメタの重要度を示す情報である。この重要度は、全てのアイテムのメタを参照した際に、そのメタの出現頻度等に基づいて算出されるものである(例:TF−IDF)。
【0059】
(救済措置エンジン116)
再び図1を参照する。救済措置エンジン116は、推薦エンジン112から関連アイテムの要求を受けた場合に推薦エンジン112とは異なる方法で関連アイテムを算出する。上記の通り、推薦エンジン112は、関連アイテムメタDB110等に基づいて算出される関連アイテムの個数が所定数に満たない場合、救済措置エンジン116に関連アイテムの要求を行う。この要求を受けて、救済措置エンジン116は、関連アイテムの個数が所定数になるように所要数の関連アイテムを推薦エンジン112に提供する。救済措置エンジン116による関連アイテムの算出方法については後段において詳述する。
【0060】
以上、本実施形態に係る関連アイテム提供システム100の機能構成について説明した。上記の通り、関連アイテム提供システム100は、ユーザの操作履歴、およびアイテム間の関連性に基づいてアイテム毎に関連アイテムを算出する。そのため、ユーザの嗜好を考慮しつつ、アイテム間の関連性に基づいて関連アイテムを算出することができる。アクセスウェイトDB106、および関連アイテムメタDB110の説明でも述べたように、この計算には、アイテム間の直接的な関連性と、間接的な関連性とが考慮されている。
【0061】
また、推薦エンジン112により算出される関連アイテムの個数が所定数に満たない場合でも、救済措置エンジン116により関連アイテムが補充されることで、所定数の関連アイテムを情報機器10に提供することが可能になる。なお、上記の説明においては、関連性の算出方法や各アイテムに付与されるメタの重要度の算出方法等について、その詳細な説明を割愛していた。そこで、これらの算出方法を含めた関連アイテムの提供方法について、以下で詳細に説明する。
【0062】
[関連アイテムの提供方法]
以下、本実施形態に係る関連アイテム提供方法について詳細に説明する。まず、図6を参照しながら、本実施形態に係る関連アイテム提供方法の全体的な流れについて説明する。図6は、本実施形態に係る関連アイテム提供方法の全体的な流れを示す説明図である。
【0063】
図6に示すように、まず、嗜好抽出エンジン104により、操作ログDB102に格納された操作ログの解析範囲が指定される(S102)。操作ログの解析範囲としては、例えば、操作ログのログ記録日時について開始日時および終了日時が指定される。そして、嗜好抽出エンジン104により、解析範囲に含まれるレコードが特定される。
【0064】
次いで、嗜好抽出エンジン104は、解析範囲のレコードに記録された操作ログに基づき、アイテムIDおよびユーザIDの各組み合わせに対してアクセスウェイトを算出する(S104)。アイテムIDおよびユーザIDの組み合わせが同じであるレコードが複数存在する場合、嗜好抽出エンジン104は、各レコードに記録された操作ログから算出されるアクセスウェイトを積算し、その積算値をアクセスウェイトDB106に格納する。
【0065】
ただし、積算ではなく、複数のアクセスウェイトの中で最大の値がアクセスウェイトDB106に格納されるように構成されていてもよい。また、嗜好抽出エンジン104によりアクセスウェイトが算出されたアイテムIDおよびユーザIDの組み合わせに対するアクセスウェイトがアクセスウェイトDB106に既に格納されていることがある。この場合、嗜好抽出エンジン104は、例えば、新たに算出したアクセスウェイトと、アクセスウェイトDB106に既に格納されているアクセスウェイトとを積算し、その積算値で古い格納値を上書きする。ただし、より大きなアクセスウェイトで古い格納値を上書きするように構成されていてもよい。
【0066】
次いで、関連性抽出エンジン108により、操作ログの解析範囲に含まれる全てのアイテムの中から1つのアイテムが選択され、このアイテム(以下、該当アイテム)について、ステップS106〜S122(またはS124)の処理が実行される(反復処理(A)の開始)。まず、関連性抽出エンジン108により、該当アイテムに対して過去にアクセスした全てのユーザが検出される(S106)。
【0067】
次いで、関連性抽出エンジン108により、該当アイテムに対して過去にアクセスした全てのユーザの中から1人のユーザが選択され、このユーザ(以下、該当ユーザ)について次の処理が実行される(反復処理(B)の開始)。まず、関連性抽出エンジン108により、該当ユーザにより過去にアクセスされた全てのアイテムのアクセスウェイトが取得され、アイテム毎にアクセスウェイトが積算される(S108)。次いで、該当アイテムにアクセスした全てのユーザの中から、他のユーザが1人だけ選択され、再びステップS108の処理が実行される(反復処理(B)の継続)。このとき、該当アイテムに対して過去にアクセスした全てのユーザについてステップS108の処理が実行された場合に反復処理が終了される(反復処理(B)の終了)。
【0068】
反復処理(B)が終了した後、関連性抽出エンジン108により、アイテム毎に積算された積算値が正規化され、正規化された積算値が該当アイテムの関連度に設定される(S110)。次いで、関連性抽出エンジン108は、関連度が設定されたアイテムを該当アイテムの関連アイテムに設定する(S112)。
【0069】
関連アイテムが設定されると、関連性抽出エンジン108により、該当アイテムとの間に関連度を有するアイテムの中から、1つのアイテムが選択され、このアイテム(以下、該当関連アイテム)について次の処理が実行される(反復処理(C)の開始)。まず、関連性抽出エンジン108により、該当関連アイテムが有効期間中のアイテムか否かが確認される(S114)。そして、関連性抽出エンジン108により、該当関連アイテムが有効であるか否かが判定される(S116)。該当関連アイテムが有効な場合、異なる該当関連アイテムが1つ選択され、再びステップS114〜S116の処理が実行される(反復処理(C)の継続)。ただし、全ての関連アイテムについて有効期間が判定された場合、ステップS120の処理に進行する(反復処理(C)の終了)。
【0070】
一方、該当関連アイテムが無効な場合、ステップS118の処理に進行する。ステップS118では、関連性抽出エンジン108により、無効な関連アイテムが該当アイテムの関連アイテム群から取り除かれる(S118)。そして、異なる該当関連アイテムが1つ選択され、再びステップS114〜S116の処理が実行される(反復処理(C)の継続)。ただし、全ての関連アイテムについて有効期間が判定された場合、ステップS120の処理に進行する(反復処理(C)の終了)。
【0071】
ステップS120では、関連性抽出エンジン108により、関連度が大きい順(または小さい順)に関連アイテムがソートされ、該当アイテムの関連アイテムとして付与される(S120)。ここで、関連アイテムの付与とは、関連アイテムメタDB110に対するレコードの登録を意味する。なお、関連アイテムメタDB110に登録される関連アイテムの個数が所定個未満である場合、関連性抽出エンジン108により、全ての関連アイテムが関連アイテムメタDB110に登録されることになる。
【0072】
推薦エンジン112は、関連アイテムメタDB110に登録された関連アイテムの数が所定数(指定個)に達しているか否かを判断する(S122)。関連アイテム数≦指定個の場合、後述するステップS124の処理(救済措置)に進行する。一方、関連アイテム数>指定個の場合、異なる該当アイテムを1つ選択し、再びステップS106から始まる処理を実行する(反復処理(A)の継続)。ただし、操作ログの解析範囲に含まれる全てのアイテムについてステップS106〜S122(またはS124)の処理が実行された場合、一連の処理を終了する(反復処理(A)の終了)。
【0073】
(救済措置について)
ここで、図8を参照しながら、ステップS124の救済処置について詳細に説明する。ただし、救済措置について詳細に説明するのに先立ち、図7を参照しながら、各アイテムのアイテム情報を簡潔に表現するアイテム情報ベクトルの表現形式について説明する。なお、アイテム情報ベクトルの表現形式は、後述するユーザの嗜好情報を表現する際にも利用可能であるため、ここで併せて説明する。図7は、本実施形態に係るアイテム情報ベクトル、およびユーザ嗜好ベクトルの表現形式を示す説明図である。
【0074】
図7を参照する。図7に示すように、各アイテムの情報は、ベクトル形式で表現される。第1要素(最左の欄)にアイテムIDが含まれる場合、そのベクトルは、アイテム情報ベクトルを表す。一方、第1要素にユーザIDが含まれる場合、そのベクトルは、ユーザ嗜好ベクトルを表す。ここでは、アイテム情報ベクトルを例に挙げて説明する。
【0075】
アイテム情報ベクトルは、例えば、メタタイプ毎に複数のメタが対応付けられており、各メタに対して重要度の値が付与されている。なお、以下の説明中では、メタタイプ単位で見た各メタの重要度を表すベクトルをメタタイプベクトルと呼ぶ場合がある。ここで、アイテム情報DB114の例(図5)を参照すると、アイテム情報ベクトルを構成するアイテムID、メタタイプ、メタ、重要度の関係がアイテム情報DB114に記載されていることが分かる。つまり、救済措置エンジン116は、アイテム情報DB114の情報に基づいてアイテム情報ベクトルを構築することができる。
【0076】
さて、次に救済措置について説明する。この救済措置(ステップS124)の処理は、主に、救済措置エンジン116により実行される。また、図8は、本実施形態に係る救済措置の流れを示す説明図である。
【0077】
まず、図8を参照する。図8に示すように、救済措置が開始されると、救済措置エンジン116により、アイテム情報DB114から、該当アイテムに付与されたメタタイプ1のメタが取得される(S132)。例えば、例えば、該当アイテムがアイテムID=1005のアイテムである場合を考える。図5に示したアイテム情報DB114を想定すると、該当アイテムに付与されたメタタイプ1のメタは153144である。
【0078】
次いで、救済措置エンジン116は、メタタイプ1のメタが付与されたアイテムが関連アイテムとして持つアイテム群を取得する(S134)。図5のアイテム情報DB114を参照すると、メタタイプ1のメタ(153144)が付与されたアイテムは、アイテムID=1001、1002、…、1014のアイテムである。
【0079】
この場合、救済措置エンジン116は、アイテムID=1001、1002、…、1014を関連アイテムに持つアイテムを取得する。例えば、アイテムID=1003のアイテムを関連アイテムに持つアイテムを関連アイテムメタDB110(図4)から検索すると、アイテムID=1001、1011のアイテムが抽出される。そこで、救済措置エンジン116は、アイテムID=1001、1011のアイテムをアイテム群に加える。同様に、他のアイテムIDのアイテムを関連アイテムに持つアイテムも抽出され、アイテム群に追加される。
【0080】
次いで、救済措置エンジン116は、関連アイテムメタDB110を参照し、ステップS134で取得したアイテム群を関連度順にソートする(S136)。例えば、アイテム群に含まれるアイテムとして、アイテムID=1003を関連アイテムに持つアイテム(アイテムID=1001、1011)について考える。この場合、救済措置エンジン116は、より大きな関連度を持つアイテムID=1011のアイテム(関連度:5.4)を上位に、アイテムID=1001のアイテム(関連度:3.4)を下位に位置付ける。アイテム群に含まれる他のアイテムについても同様に、関連度順でソートされる。
【0081】
次いで、救済措置エンジン116は、ステップS136でソートしたアイテム群の中から、関連度の高い順にアイテムを抽出して該当アイテムの関連アイテムに設定する(S138)。図4に例示した関連アイテムメタDB110の場合、アイテムID=1005のアイテムに設定された関連アイテムは、アイテムID=1001、1004、1010の3つである。仮に、関連アイテムの指定数が5である場合、救済措置エンジン116は、あと2つの関連アイテムを設定することになる。その際、救済措置エンジン116は、アイテム群(アイテムID=1001、1002、…、1011)の中から、関連度の高いアイテムID=1003、1011を抽出し、アイテムID=1005の関連アイテムに設定することになる。
【0082】
次いで、救済措置エンジン116は、該当アイテムの関連アイテム数が指定個を越えているか否かを判断する(S138)。該当アイテムの関連アイテム数≧指定個の場合、救済措置エンジン116は、救済措置に係る一連の処理を終了する。一方、該当アイテムの関連アイテム数<指定個の場合、救済措置エンジン116は、ステップS140の処理に進行する。
【0083】
ステップS140では、救済措置エンジン116により、該当アイテムに付与されたメタタイプ2のメタが取得される(S140)。次いで、救済措置エンジン116は、メタタイプ2が付与されたアイテムを関連アイテムに持つアイテム群を取得する(S142)。次いで、救済措置エンジン116は、ステップS142で取得したアイテム群を関連度順にソートする(S144)。次いで、救済措置エンジン116は、アイテム群に含まれるアイテムの中から、関連度の高い順にアイテムを抽出して該当アイテムの関連アイテムに設定する(S146)。
【0084】
次いで、救済措置エンジン116は、該当アイテムの関連アイテム数が指定個を越えているか否かを判断する(S148)。該当アイテムの関連アイテム数≧指定個の場合、救済措置エンジン116は、救済措置に係る一連の処理を終了する。一方、該当アイテムの関連アイテム数<指定個の場合、救済措置エンジン116は、ステップS150の処理に進行する。
【0085】
ステップS150では、救済措置エンジン116により、該当アイテムに付与されたメタタイプ3のメタが取得される(S150)。次いで、救済措置エンジン116は、メタタイプ3が付与されたアイテムを関連アイテムに持つアイテム群を取得する(S152)。次いで、救済措置エンジン116は、ステップS152で取得したアイテム群を関連度順にソートする(S154)。次いで、救済措置エンジン116は、アイテム群に含まれるアイテムの中から、関連度の高い順にアイテムを抽出して該当アイテムの関連アイテムに設定する(S156)。
【0086】
次いで、救済措置エンジン116は、該当アイテムの関連アイテム数が指定個を越えているか否かを判断する(S158)。該当アイテムの関連アイテム数≧指定個の場合、救済措置エンジン116は、救済措置に係る一連の処理を終了する。一方、該当アイテムの関連アイテム数<指定個の場合、救済措置エンジン116は、ステップS160の処理に進行する。ただし、ステップS160の処理に進行する間、メタタイプ4〜M−1(Mは自然数)について、ステップS150〜S156と同様の処理が実行される。
【0087】
ステップS160では、救済措置エンジン116により、該当アイテムに付与されたメタタイプMのメタが取得される(S160)。次いで、救済措置エンジン116は、メタタイプMが付与されたアイテムを関連アイテムに持つアイテム群を取得する(S162)。次いで、救済措置エンジン116は、ステップS162で取得したアイテム群を関連度順にソートする(S164)。次いで、救済措置エンジン116は、アイテム群に含まれるアイテムの中から、関連度の高い順にアイテムを抽出して該当アイテムの関連アイテムに設定する(S166)。
【0088】
次いで、救済措置エンジン116は、該当アイテムの関連アイテム数が指定個を越えているか否かを判断する(S168)。該当アイテムの関連アイテム数≧指定個の場合、救済措置エンジン116は、救済措置に係る一連の処理を終了する。一方、該当アイテムの関連アイテム数<指定個の場合、救済措置エンジン116は、ステップS170の処理に進行する。ステップS170では、救済措置エンジン116により、アクセスウェイトDB106が参照され、全ユーザのアクセスウェイトランキングで上位のアイテムが該当アイテムの関連アイテムに設定される(S170)。このとき、救済措置エンジン116は、該当アイテムの関連アイテム数が指定個になるように関連アイテムを設定した後、救済措置に係る一連の処理を終了する。
【0089】
(概念的な説明)
ここで、図9の概念図を参照しながら、上記の救済措置に関する概念的な説明を加える。図9は、本実施形態に係る救済措置の概念を簡単に示した説明図である。この救済措置(ソーシャルな関連使用バージョン)は、メタの関連性を利用してアイテムの類似度を計算するのではなく、コミュニティ内における社会知識に基づいてアイテムの類似度が計算される。そのため、メタに表現されていない類似度を考慮することが可能になる。この類似度とは、メタの関連性に基づいて算出された値である。
【0090】
図9に示すように、該当アイテムに関連アイテムが無い場合について考える。また、該当アイテムには、メタタイプとして「ニュース」「サッカー」が付与されているものとする。ただし、実際には、「ニュース」「サッカー」に対応するメタタイプのID(属性ID)が該当アイテムに付与されている。
【0091】
まず、救済措置エンジン116により、該当アイテムが持つメタタイプのメタが任意に抽出される。仮に、「ニュース」「サッカー」に対応するメタ(属性値)が抽出されたものとする。次いで、救済措置エンジン116は、抽出したメタを持つアイテムを関連アイテムの候補(以下、関連アイテム候補)として取得する。仮に、関連アイテム候補として、アイテム(1)、アイテム(2)、アイテム(3)が取得されたものとする。
【0092】
これらのアイテムには関連度が付与されている。例えば、アイテム(1)には、アイテムAに対する関連度1.5、アイテムBに対する関連度0.5が付与されているものとする。また、アイテム(2)には、アイテムBに対する関連度0.9、アイテムCに対する関連度0.3、アイテムDに対する関連度0.1が付与されているものとする。さらに、アイテム(3)には、アイテムAに対する関連度1.0、アイテムCに対する関連度0.4が付与されているものとする。また、アイテムBが、該当アイテムのメタから抽出されたメタと同じメタ(例えば、「サッカー」)を持つものと仮定する。
【0093】
この場合、救済措置エンジン116は、アイテムBに対する各関連アイテム候補の関連度(値B)、および、該当アイテムとアイテムBとの間の類似度(値A)に基づき、該当アイテムと各関連アイテム候補との間の関連度を算出する。この関連度は、例えば、下記の式(1)および式(2)に基づいて算出することができる。
【0094】
【数1】

【0095】
上記の式(1)および式(2)で算出された関連度は、各関連アイテム候補が関連アイテムとして該当アイテムに付与される際の関連度に設定される。例えば、該当アイテムには、関連度0.15を持つアイテム(1)、および関連度0.27を持つアイテム(2)が付与されるのである。このように、該当アイテムに付与される関連アイテムと、各関連アイテムに設定される関連度とが算出される。なお、上記の例では、(値A)と(値B)とを積算値を用いる方法を示したが、例えば、(値A)と(値B)との加算値、または(値B)をそのまま用いる方法でもよい。
【0096】
ところで、上記の説明においては、関連アイテム候補の選択方法として、該当アイテムのメタ群から抽出したメタと同じメタを持つアイテムを選択する方法について述べた。この方法について、より詳細に説明する。
【0097】
本実施形態に係る救済措置においては、種々の関連アイテム候補の選択方法が適用できる。例えば、個々のメタに優先度を予め設定しておき、その優先度の高いメタを持つアイテムを関連アイテム候補として選択する方法が適用できる(方法1)。さらに、該当アイテムのメタ群をメタタイプベクトル(図7を参照)で表現し、メタタイプベクトルの類似度が大きいアイテムを関連アイテム候補として選択する方法が適用できる(方法2)。
【0098】
以下、上記の方法2について簡単に説明する。方法2は、メタタイプベクトルを用いて算出される類似度をアイテム間で比較するというものである。この類似度は、下記の式(3)により算出される。ただし、ここで算出する類似度の計算方法は、下記の内積計算でなくても良く、例えば、コサイン尺度やユークリッド距離等を計算する方法でもよい。
【0099】
【数2】

【0100】
上記の方法2によると、各計算対象アイテムについて、上記の式(3)により算出された類似度が比較され、類似度が大きい順に上位N個(Nは所定数)のアイテムが関連アイテム候補として選択されるのである。
【0101】
(変形例1−1)
ここで、本実施形態に係る救済措置の変形例(変形例1−1)について述べる。上記の救済措置は、該当アイテムのメタに基づいて関連アイテム候補を抽出し、その関連アイテム候補が持つ関連アイテムの関連度等を基準に該当アイテムの関連アイテムを設定していた。この考え方を応用し、例えば、該当アイテムのメタに類似するメタを持つアイテムを抽出し、そのアイテムの関連アイテムを該当アイテムの関連アイテムに設定する方法が考えられる。そこで、図10を参照しながら、この方法について以下で説明する。図10は、本実施形態の変形例1−1に係る救済措置の流れを示す説明図である。
【0102】
図10に示すように、まず、救済措置エンジン116は、メタタイプ1が付与されたアイテムを検索する(S172)。次いで、救済措置エンジン116は、メタタイプ1のメタが付与されたアイテムについて、各アイテムが持つ関連アイテムの中から関連度が高い順に上位N個(Nは所定数)のアイテムを抽出する。そして、救済措置エンジン116は、抽出したアイテムを該当アイテムの関連アイテムに設定する(S174)。
【0103】
次いで、救済措置エンジン116は、該当アイテムの関連アイテム数が指定個を越えたか否かを判断する(S176)。該当アイテムの関連アイテム数≧指定個の場合、救済措置エンジン116は、救済措置に係る一連の処理を終了する。一方、該当アイテムの関連アイテム数<指定個の場合、救済措置エンジン116は、ステップS178の処理に進行する。
【0104】
ステップS178では、救済措置エンジン116により、メタタイプ2が付与されたアイテムが検索される(S178)。次いで、救済措置エンジン116は、メタタイプ2のメタが付与されたアイテムについて、各アイテムが持つ関連アイテムの中から関連度が高い順に上位N個(Nは所定数)のアイテムを抽出する。そして、救済措置エンジン116は、抽出したアイテムを該当アイテムの関連アイテムに設定する(S180)。
【0105】
次いで、救済措置エンジン116は、該当アイテムの関連アイテム数が指定個を越えたか否かを判断する(S182)。該当アイテムの関連アイテム数≧指定個の場合、救済措置エンジン116は、救済措置に係る一連の処理を終了する。一方、該当アイテムの関連アイテム数<指定個の場合、救済措置エンジン116は、ステップS184の処理に進行する。
【0106】
ステップS184では、救済措置エンジン116により、メタタイプ3が付与されたアイテムが検索される(S184)。次いで、救済措置エンジン116は、メタタイプ3のメタが付与されたアイテムについて、各アイテムが持つ関連アイテムの中から関連度が高い順に上位N個(Nは所定数)のアイテムを抽出する。そして、救済措置エンジン116は、抽出したアイテムを該当アイテムの関連アイテムに設定する(S186)。
【0107】
次いで、救済措置エンジン116は、該当アイテムの関連アイテム数が指定個を越えたか否かを判断する(S188)。該当アイテムの関連アイテム数≧指定個の場合、救済措置エンジン116は、救済措置に係る一連の処理を終了する。一方、該当アイテムの関連アイテム数<指定個の場合、救済措置エンジン116は、ステップS190の処理に進行する。ただし、ステップS190の処理に進行する間、メタタイプ4〜M−1(Mは自然数)について、ステップS184〜S188と同様の処理が実行される。
【0108】
ステップS190では、救済措置エンジン116により、メタタイプMが付与されたアイテムが検索される(S190)。次いで、救済措置エンジン116は、メタタイプMのメタが付与されたアイテムについて、各アイテムが持つ関連アイテムの中から関連度が高い順に上位N個(Nは所定数)のアイテムを抽出する。そして、救済措置エンジン116は、抽出したアイテムを該当アイテムの関連アイテムに設定する(S192)。
【0109】
次いで、救済措置エンジン116は、該当アイテムの関連アイテム数が指定個を越えたか否かを判断する(S194)。該当アイテムの関連アイテム数≧指定個の場合、救済措置エンジン116は、救済措置に係る一連の処理を終了する。一方、該当アイテムの関連アイテム数<指定個の場合、救済措置エンジン116は、ステップS196の処理に進行する。ステップS196では、救済措置エンジン116により、アクセスウェイトDB106が参照され、全ユーザのアクセスウェイトランキングで上位のアイテムが該当アイテムの関連アイテムに設定される(S196)。このとき、救済措置エンジン116は、該当アイテムの関連アイテム数が指定個になるように関連アイテムを設定した後、救済措置に係る一連の処理を終了する。
【0110】
(概念的な説明)
ここで、図11の概念図を参照しながら、変形例1−1の救済措置に関する概念的な説明を加える。図11は、変形例1−1に係る救済措置の概念を示した説明図である。
【0111】
図11に示すように、該当アイテムに関連アイテムが無い場合について考える。また、該当アイテムには、メタタイプとして「ニュース」「サッカー」が付与されているものとする。ただし、実際には、「ニュース」「サッカー」に対応するメタタイプのID(属性ID)が該当アイテムに付与されている。
【0112】
まず、救済措置エンジン116により、該当アイテムが持つメタタイプのメタが任意に抽出される。仮に、「ニュース」「サッカー」に対応するメタ(属性値)が抽出されたものとする。次いで、救済措置エンジン116は、抽出したメタを持つアイテムを関連アイテムの候補(以下、関連アイテム候補)として取得する。仮に、関連アイテム候補として、アイテム(1)、アイテム(2)、アイテム(3)が取得されたものとする。
【0113】
これらのアイテムには関連度が付与されている。例えば、アイテム(1)には、アイテムAに対する関連度1.5、アイテムBに対する関連度0.5が付与されているものとする。また、アイテム(2)には、アイテムBに対する関連度0.9、アイテムCに対する関連度0.3、アイテムDに対する関連度0.1が付与されているものとする。さらに、アイテム(3)には、アイテムAに対する関連度1.0、アイテムCに対する関連度0.4が付与されているものとする。
【0114】
さらに、救済措置エンジン116により、該当アイテムに対する関連アイテム候補の類似度(値A)が算出されているものとする。図11の例では、アイテム(1)と該当アイテムとの間の類似度が0.3、アイテム(2)と該当アイテムとの間の類似度が0.0、アイテム(3)と該当アイテムとの間の類似度が0.0である。この例は、アイテム(1)のメタに該当アイテムと同じメタ(例えば、「サッカー」)が含まれている場合に相当する。
【0115】
この場合、救済措置エンジン116は、該当アイテムと各関連アイテム候補との間の類似度(値A)、および、各関連アイテム候補の各関連アイテムに対する関連度(値B)に基づき、該当アイテムと各関連アイテム候補の関連アイテムとの間の類似度を算出する。この類似度は、例えば、下記の式(4)および式(5)に基づいて算出することができる。そして、算出された類似度が大きい順に上位から所定個の関連アイテムが該当アイテムに付与される。なお、アイテム(2)およびアイテム(3)と、該当アイテムとの間の類似度が0.0であることから、これらのアイテムに関する類似度の記載は省略した。
【0116】
【数3】

【0117】
上記の式(4)および式(5)で算出された類似度は、各関連アイテム候補の関連アイテムが該当アイテムに付与される際の関連度に設定される。例えば、該当アイテムには、関連度0.45を持つアイテムA、および関連度0.15を持つアイテムBが付与されるのである。このようにして、該当アイテムに付与される関連アイテムと、各関連アイテムに設定される関連度とが算出される。なお、上記の例では、(値A)と(値B)とを積算値を用いる方法を示したが、例えば、(値A)と(値B)との加算値、または(値B)をそのまま用いる方法でもよい。
【0118】
ところで、上記の説明においては、関連アイテム候補の選択方法として、該当アイテムのメタ群から抽出したメタと同じメタを持つアイテムを選択する方法について述べた。この方法について、より詳細に説明する。
【0119】
本実施形態に係る救済措置においては、種々の関連アイテム候補の選択方法が適用できる。例えば、個々のメタに優先度を予め設定しておき、その優先度の高いメタを持つアイテムを関連アイテム候補として選択する方法が適用できる(方法1)。さらに、該当アイテムのメタ群をメタタイプベクトル(図7を参照)で表現し、メタタイプベクトルの類似度が大きいアイテムを関連アイテム候補として選択する方法が適用できる(方法2)。
【0120】
以下、上記の方法2について簡単に説明する。方法2は、メタタイプベクトルを用いて算出される類似度をアイテム間で比較するというものである。この類似度は、下記の式(6)により算出される。ただし、ここで算出する類似度の計算方法は、下記の内積計算でなくても良く、例えば、コサイン尺度やユークリッド距離等を計算する方法でもよい。
【0121】
【数4】

【0122】
上記の方法2によると、各計算対象アイテムについて、上記の式(6)により算出された類似度が比較され、類似度が大きい順に上位N個(Nは所定数)のアイテムが関連アイテム候補として選択されるのである。
【0123】
<第2実施形態>
次に、本発明の第2実施形態について説明する。本実施形態は、CBF(Content−Based−Filtering)の枠組みの中で、CF(Collaborative−Filtering)による結果も一緒に計算できるようにする関連アイテムの算出方法に関する。特に、ユーザの嗜好情報を利用して関連アイテムを算出する技術に関する。
【0124】
[関連アイテム提供システム200の構成例]
まず、図12を参照しながら、本実施形態に係る関連アイテム提供システム200のシステム構成について説明する。図12は、本実施形態に係る関連アイテム提供システム200の構成例を示す説明図である。なお、上記の第1実施形態に係る関連アイテム提供システム100と実質的に同一の機能構成については同一の符号を付することにより詳細な説明を省略する。
【0125】
図12に示すように、関連アイテム提供システム200は、主に、操作ログDB102と、嗜好抽出エンジン202と、アクセスウェイトDB106と、関連性抽出エンジン108と、関連アイテムメタDB110と、推薦エンジン112と、アイテム情報DB114と、救済措置エンジン206と、ユーザ嗜好情報DB204とを含む。上記の第1実施形態に係る関連アイテム提供システム100との間の主な相違点は、嗜好抽出エンジン202、救済措置エンジン206の機能、およびユーザ嗜好情報DB204の存在である。そこで、これらの相違点を中心に説明する。
【0126】
また、関連アイテム提供システム200は、ユーザが操作する情報機器10に直接またはネットワークを介して接続されており、情報機器10の操作ログを取得したり、情報機器10に関連アイテムを提供したりすることができる。図12には、便宜上、情報機器10が1台しか描画されていないが、2台以上であってもよい。
【0127】
なお、操作ログDB102、アクセスウェイトDB106、関連アイテムメタDB110、アイテム情報DB114、およびユーザ嗜好情報DB204は、所定の記憶装置に格納されている。この記憶装置としては、例えば、後述するハードウェア構成例の中で、RAM906、記憶部920、またはリムーバブル記憶媒体928等に相当する。
【0128】
(嗜好抽出エンジン202)
嗜好抽出エンジン202は、操作ログDB102からユーザの操作ログを取得し、ユーザ毎に各アイテムに対するアクセスウェイトを計算する。嗜好抽出エンジン202により算出されたアクセスウェイトは、アクセスウェイトDB106、およびユーザ嗜好情報DB204に格納される。なお、ここで言うアクセスウェイトとは、あるユーザが特定のアイテムをどれだけ好んでいるかを示す指標であり、嗜好の度合いを示す情報である。つまり、アクセスウェイトは、嗜好情報の一例である。
【0129】
例えば、各操作ログに予め重み値が設定されており、その値に基づいて各アイテムに対する各ユーザのアクセスウェイトが算出される。ここで、アクセスウェイトの算出方法の一例について簡単に説明する。まず、嗜好抽出エンジン202は、操作ログDB102から取得した各操作ログに基づき、アクセスのあったアイテムを特定する。次いで、嗜好抽出エンジン202は、アクセス情報DB114を参照し、特定したアイテムのメタと、そのメタに対応する重要度(重み値)を取得する。次いで、嗜好抽出エンジン202は、メタ毎に重要度を積算し、その積算値をアクセスウェイトとして蓄積する。なお、メタタイプ毎にアクセスウェイトを算出してもよい。
【0130】
(ユーザ嗜好情報DB204)
ユーザ嗜好情報DB204は、個々のユーザ毎に嗜好情報として算出された属性情報が格納されるデータベースである。ユーザ嗜好情報DB204に格納された属性情報は、救済措置エンジン206により読み出される。
【0131】
ここで、図13を参照しながら、ユーザ嗜好情報DB204の構成例について説明する。図13は、本実施形態に係るユーザ嗜好情報DB204の構成例を示す説明図(図表5)である。図表5の例で、ユーザ嗜好情報DB204には、ユーザID(MemberID)、メタタイプ(AttributeID;属性ID)、メタ(ValueID;属性値)、重要度(Score)の欄が設けられている。なお、各アイテムに関連アイテムが付与されている場合、各関連アイテムに対するメタが格納されていてもよい。
【0132】
ユーザIDの欄に記録される情報は、各ユーザを識別するための識別情報(ID)である。メタタイプの欄に記録される情報は、各アイテムに付与された属性情報の種類を表す情報である。この欄には、例えば、ジャンル(Genre)、パーソン(Person)、キーワード(Keyword)、放送時間、放送局、タイトル(Title)等を示す識別情報(ID)が記録される。
【0133】
メタの欄に記録される情報は、各アイテムの属性値が記録される。この欄には、例えば、「アクション」「山田太郎」「正月」等を示す識別情報(ID)が記録される。重要度の欄に記録される情報は、そのレコードに記録されたメタの重要度を示す情報である。この重要度は、全てのアイテムのメタを参照した際に、そのメタの出現頻度等に基づいて算出されるものである(例:TF−IDF)。
【0134】
(救済措置エンジン206)
再び図12を参照する。救済措置エンジン206は、推薦エンジン112から関連アイテムの要求を受けた場合に推薦エンジン112とは異なる方法で関連アイテムを算出する。上記の通り、推薦エンジン112は、関連アイテムメタDB110等に基づいて算出される関連アイテムの個数が所定数に満たない場合、救済措置エンジン116に関連アイテムの要求を行う。この要求を受けて、救済措置エンジン206は、関連アイテムの個数が所定数になるように所要数の関連アイテムを推薦エンジン112に提供するのである。ただし、救済措置エンジン206は、上記の第1実施形態に係る救済措置エンジン116とは異なり、ユーザの嗜好情報を利用して関連アイテムを抽出する。以下、この抽出方法について詳細に説明する。
【0135】
(救済措置の詳細)
ここで、図14を参照しながら、本実施形態に係る救済措置について説明する。図14は、本実施形態に係る救済措置の流れを示す説明図である。
【0136】
上記の第1実施形態に係る救済措置は、予め設定されたメタタイプの優先度(例えば、メタタイプ1、メタタイプ2、…、メタタイプMの順番)に基づいて処理が実行され、該当アイテムの関連アイテムが設定された。本実施形態に係る救済措置は、全てのメタタイプに関して処理を実行した上で、その結果をマージする方法に関する。この方法によると、特定のメタタイプの関連度に影響されず、より関連性の高いアイテムを該当アイテムの関連アイテムに設定することが可能になる。以下、この方法について述べる。
【0137】
まず、救済措置エンジン206は、該当アイテムが持つ全てのメタタイプを取得した上で、その中から1つのメタタイプ(以下、該当メタタイプ;メタタイプM)を選択し、ステップS202〜S206の処理を実行する(反復処理(A)の開始)。
【0138】
ステップS202では、救済措置エンジン206により、該当アイテムに付与されたメタタイプMのメタが取得される(S202)。次いで、救済措置エンジン206は、メタタイプMのメタを持つアイテムが関連アイテムとして付与されたアイテム(アイテム群)を取得する(S204)。次いで、救済措置エンジン206は、アイテム群に含まれる各アイテムに対する関連度を参照し、関連度が高い順にソートして関連アイテム候補のリストに記録する(S206)。
【0139】
次いで、救済措置エンジン206は、該当アイテムが持つメタタイプの中から、他の該当メタタイプを1つ選択し、再びステップS202〜S206の処理を実行する。ただし、救済措置エンジン206は、該当アイテムが持つ全てのメタタイプについてステップS202〜S206の処理を実行した場合、ステップS208の処理に進行する。
【0140】
ステップS208では、救済措置エンジン206により、関連アイテム候補リストに含まれる各アイテムの関連度に対し、各メタタイプの優先度に応じた重みを掛ける(S208)。ただし、各メタタイプの優先度は、予め設定しておく方法もあるが、動的に算出する方法もある。この動的に算出する方法について簡単に説明する。
【0141】
優先度の算出方法としては、例えば、該当アイテムが持つメタの偏りに応じて優先度が決定される方法(方法1)や、アクセスしたユーザの嗜好の偏りに応じて優先度が決定される方法(方法2)が考えられる。
【0142】
(方法1について)
方法1を採用する場合、救済措置エンジン206は、メタタイプ毎に該当アイテムが持つ各メタの偏りを算出し、その偏りに応じて重みを算出する。例えば、救済措置エンジン206は、偏りの大きいメタタイプに対して大きな重み値を設定する。この設定により、重み値が大きなメタタイプと、そのメタタイプが付与されたアイテムとの間の関連性が特に重要視されることになる。偏りの算出方法としては、例えば、次のような方法がある。(1)各メタタイプに含まれるメタに関して重み値の平均が算出され、その平均値が高い程、大きな偏り値が設定されるという方法。(2)各メタタイプに含まれるメタの中で、有限の値を持つメタの割合に応じて偏り値が設定されるという方法。
【0143】
(方法2について)
方法2を採用する場合、救済措置エンジン206は、上記の方法1と同様に、アクセスしたユーザの嗜好の偏り値を算出し、その偏り値に応じて重み値を算出する。例えば、ユーザの嗜好が大きく偏っているメタタイプの重み値を大きく設定する。この設定により、該当ユーザが重要視しているメタタイプとの関連が重視されることになる。
【0144】
上記のようにして重み付けされた後、救済措置エンジン206により、関連アイテム候補リスト内に重複して含まれるアイテムの重み値が足し合わされ、新たな関連度としてマージされる(S210)。つまり、関連アイテム候補リスト内に同じアイテムのレコードが複数存在する場合、それらのレコードは、1つのレコードに纏められる。その際、そのレコードに記録される関連度は、同一アイテムに関して複数のレコードに記録されていた重み値の合計値に設定される。
【0145】
次いで、救済措置エンジン206は、関連アイテム候補リストに含まれるアイテムの中から、関連度が高い順に上位N個(Nは所定数)のアイテムを抽出し、該当アイテムの関連アイテムに設定する(S212)。次いで、救済措置エンジン206は、関連アイテム数が指定個に達しているか否かを判断する(S214)。関連アイテム数≧指定個の場合、救済措置エンジン206は、救済措置に係る一連の処理を終了する。一方、関連アイテム数<指定個の場合、救済措置エンジン206は、ステップS216の処理に進行する。
【0146】
ステップS216では、救済措置エンジン206により、全てのユーザに対するアクセスウェイトが大きい順に上位のアイテムが抽出され、該当アイテムの関連アイテムに付与される(S216)。このとき、救済措置エンジン206により、該当アイテムの関連アイテム数が指定数になるまで、アクセスウェイトが上位のアイテムが付与される。このようにして、該当アイテムに指定数だけ関連アイテムが付与され、救済措置に係る一連の処理が終了する。
【0147】
以上の方法を用いると、特定のメタタイプを用いた関連度に影響されることなく、より関連性の高いアイテムを関連アイテムとして算出することができる。
【0148】
(変形例2−1)
ここで、図15を参照しながら、本実施形態に係る救済措置の変形例(変形例2−1)について説明する。図15は、変形例2−1に係る救済措置の流れを示す説明図である。この変形例2−1は、処理が優先的に実行されるメタタイプの順番を決定するための優先度の算出方法に関する。この変形例2−1の場合、救済措置エンジン206は、救済措置を実行する前段で優先度の算出処理を実行する。
【0149】
図15に示すように、まず、救済措置エンジン206は、メタタイプ毎に優先度を算出する(S222)。このとき、救済措置エンジン206は、該当アイテムが持つメタについて各メタタイプの偏りを算出し、その偏りが大きいメタタイプから順に優先度を設定する。次いで、救済措置エンジン206は、優先度の高いメタタイプから順に救済措置を実行する(S224)。
【0150】
上記のように、メタの偏りが大きいメタタイプに高い優先度が設定される。そこで、救済措置エンジン206は、この優先度を利用して、優先度が大きい順に上位のアイテムを該当アイテムの関連アイテムに設定することができる。さらに、救済措置エンジン206は、メタタイプ毎に算出された偏りの大きさに応じて関連アイテムとして付与する数を変えることもできる。つまり、この方法は、偏りの大きいメタタイプを利用して該当アイテムに関連が深いアイテムをより重要視するというものである。
【0151】
また、救済措置エンジン206は、メタタイプに関する偏りと同様に、アクセスしたユーザの嗜好に関する偏りを算出し、その算出したユーザの嗜好の偏りに応じて優先度を設定してもよい。この場合、救済措置エンジン206は、ユーザの嗜好の偏りが大きいアイテムから順に選択し、該当アイテムの関連アイテムに設定する。さらに、救済措置エンジン206は、ユーザの嗜好の偏りに応じて関連アイテムとして付与する数を変えることもできる。つまり、この方法は、ユーザの嗜好の偏りが大きいアイテムを該当アイテムに関連が深いアイテムとして、より重要視するというものである。
【0152】
(変形例2−2)
次に、図16〜図18を参照しながら、本実施形態に係る救済措置の変形例(変形例2−2)について説明する。図16〜図18は、変形例2−2に係る救済措置の流れを示す説明図である。この変形例2−2に係る救済措置は、該当アイテムの各関連アイテムについて、各関連アイテムが持つ関連アイテムを関連度が高い順に取得し、該当アイテムに付与する方法に関する。
【0153】
図16に示すように、まず、救済措置エンジン206により、該当アイテムがシードアイテムに指定される(S232)。次いで、救済措置エンジン206は、シードアイテムの関連アイテム群を取得する(S234)。次いで、救済措置エンジン206は、シードアイテムの関連アイテム群に含まれる全てのアイテムについて、ステップS236〜S240の処理を実行する(反復処理(A)の開始)。
【0154】
次いで、救済措置エンジン206は、シードアイテムの関連アイテム群の中から1つのアイテム(以下、選択アイテム)を取得する(S236)。次いで、救済措置エンジン206は、選択アイテムの関連アイテムを取得し、関連度が高い順に上位の関連アイテムを抽出して該当アイテムの関連アイテムに設定する(S238)。次いで、救済措置エンジン206は、該当アイテムの関連アイテム数が指定個に達したか否かを判断する(S240)。該当アイテムの関連アイテム数≧指定個である場合、救済措置エンジン206は、救済措置に係る一連の処理を終了する。
【0155】
一方、該当アイテムの関連アイテム数<指定個である場合、救済措置エンジン206は、シードアイテムの関連アイテムの中から、関連度が次に高い選択アイテムを選択し、ステップS236〜S240の処理を実行する(反復処理(A)の継続)。ただし、シードアイテムの関連アイテム群に含まれる全ての関連アイテムについて、ステップS236〜S240の処理が実行された場合、反復処理(B)に進行する(反復処理(A)の終了)。
【0156】
反復処理(B)は、シードアイテムの関連アイテム群に含まれる関連アイテムについて反復実行される。まず、救済措置エンジン206により、シードアイテムの関連アイテム群の中から、1つのアイテムが取得される(S242)。次いで、救済措置エンジン206は、取得したアイテムの関連アイテム群(アイテム群1)を取得する(S244)。次いで、反復処理(C)に進行する。
【0157】
反復処理(C)は、アイテム群1に含まれるアイテムについて反復実行される。救済措置エンジン206は、アイテム群1の中から1つのアイテムを取得する(S246)。次いで、救済措置エンジン206は、取得したアイテムの関連アイテム群の中で、関連度が高い順に上位の関連アイテムを該当アイテムの関連アイテムに設定する(S248)。次いで、救済措置エンジン206は、該当アイテムの関連アイテム数が指定数に達したか否かを判断する(S250)。該当アイテムの関連アイテム数≧指定個である場合、救済措置エンジン206は、救済措置に係る一連の処理を終了する。
【0158】
一方、該当アイテムの関連アイテム数<指定個の場合、救済措置エンジン206は、アイテム群1に含まれる他のアイテムを選択し、そのアイテムについてステップS246〜S250の処理を実行する(反復処理(C)の継続:図17)。ただし、救済措置エンジン206は、アイテム群1に含まれる全てのアイテムについてステップS246〜S250の処理を実行した場合(反復処理(C)の終了:図17)、ステップS242に戻り、シードアイテムの関連アイテム群の中から他の1つのアイテムを取得して、ステップS244以降の処理を実行する(反復処理(B)の継続)。ただし、シードアイテムの関連アイテム群に含まれる全てのアイテムについて、反復処理(B)に関する一連の処理が実行された場合、反復処理(D)(図17)に進行する(反復処理(B)の終了)。
【0159】
図17を参照する。反復処理(D)は、アイテム群1に含まれる全てのアイテムについて反復実行される。救済措置エンジン206は、アイテム群1の中から1つのアイテムを取得する(S252)。次いで、救済措置エンジン206は、ステップS252で取得したアイテムの関連アイテム(アイテム群2)を取得する(S254)。次いで、救済措置エンジン206は、反復処理(E)に進行する。
【0160】
反復処理(E)は、アイテム群2に含まれるアイテムについて反復実行される。救済措置エンジン206は、アイテム群2の中から1つのアイテムを取得する(S256)。次いで、救済措置エンジン206は、取得したアイテムの関連アイテム群の中で、関連度が高い順に上位の関連アイテムを該当アイテムの関連アイテムに設定する(S258)。次いで、救済措置エンジン206は、該当アイテムの関連アイテム数が指定数に達したか否かを判断する(S260)。該当アイテムの関連アイテム数≧指定個である場合、救済措置エンジン206は、救済措置に係る一連の処理を終了する。
【0161】
一方、該当アイテムの関連アイテム数<指定個の場合、救済措置エンジン206は、アイテム群1に含まれる他のアイテムを選択し、そのアイテムについてステップS256〜S260の処理を実行する(反復処理(E)の継続:図18)。ただし、救済措置エンジン206は、アイテム群2に含まれる全てのアイテムについてステップS256〜S260の処理を実行した場合(反復処理(D)の終了:図18)、ステップS252に戻り、アイテム群1の中から他の1つのアイテムを取得して、ステップS254以降の処理を実行する(反復処理(D)の継続)。ただし、アイテム群1に含まれる全てのアイテムについて、反復処理(D)に関する一連の処理が実行された場合、反復処理(F)(図18)に進行する(反復処理(D)の終了)。
【0162】
ただし、救済措置エンジン206は、反復処理(D)が終了して反復処理(F)に進行する間に、反復処理(D)と同じ一連の処理をアイテム群2〜アイテム群M−1について実行する。その後、救済措置エンジン206は、反復処理(F)に進行する。
【0163】
図18を参照する。反復処理(F)は、アイテム群Mに含まれる全てのアイテムについて反復実行される。救済措置エンジン206は、アイテム群Mの中から1つのアイテムを取得する(S262)。次いで、救済措置エンジン206は、ステップS262で取得したアイテムの関連アイテム(アイテム群M+1)を取得する(S264)。次いで、救済措置エンジン206は、反復処理(G)に進行する。
【0164】
反復処理(G)は、アイテム群M+1に含まれるアイテムについて反復実行される。救済措置エンジン206は、アイテム群M+1の中から1つのアイテムを取得する(S266)。次いで、救済措置エンジン206は、取得したアイテムの関連アイテム群の中で、関連度が高い順に上位の関連アイテムを該当アイテムの関連アイテムに設定する(S268)。次いで、救済措置エンジン206は、該当アイテムの関連アイテム数が指定数に達したか否かを判断する(S270)。該当アイテムの関連アイテム数≧指定個である場合、救済措置エンジン206は、救済措置に係る一連の処理を終了する。
【0165】
一方、該当アイテムの関連アイテム数<指定個の場合、救済措置エンジン206は、アイテム群M+1に含まれる他のアイテムを選択し、そのアイテムについてステップS266〜S270の処理を実行する(反復処理(G)の継続)。ただし、救済措置エンジン206は、アイテム群M+1に含まれる全てのアイテムについてステップS266〜S270の処理を実行した場合(反復処理(G)の終了)、ステップS262に戻り、アイテム群Mの中から他の1つのアイテムを取得して、ステップS264以降の処理を実行する(反復処理(F)の継続)。ただし、アイテム群Mに含まれる全てのアイテムについて、反復処理(F)に関する一連の処理が実行された場合、ステップS272の処理に進行する(反復処理(D)の終了)。
【0166】
ステップS272では、救済措置エンジン206により、全てのユーザに関するアクセスウェイトランキングの中で上位に位置するアイテムが該当アイテムの関連アイテムに追加される(S272)。このとき、救済措置エンジン206は、該当アイテムの関連アイテム数が所定個になるまで追加処理を実行する。その後、救済措置エンジン206は、救済措置に係る一連の処理を終了する。
【0167】
(概念的な説明)
ここで、図19を参照しながら、変形例2−2に係る救済措置の概念について簡単に纏める。図19は、変形例2−2に係る救済措置を概念的に示した説明図である。
【0168】
図19に例示したように、変形例2−2に係る救済措置は、5つのステップで概念的に表現することができる。Step.1では、該当アイテムに2つの関連アイテム(アイテム1、アイテム2)が付与されているものと仮定する。また、該当アイテムとアイテム1との間の類似度が0.8であると仮定する。さらに、該当アイテムとアイテム2との間の類似度が0.5であると仮定する。
【0169】
ここで、救済措置エンジン206は、該当アイテムの関連アイテムを1つ取得する。例えば、アイテム1が取得されるものと仮定する。また、Step.2に示すように、アイテム1には、2つの関連アイテム(アイテム3、アイテム4)が付与されているものと仮定する。そして、アイテム1とアイテム3との間の類似度が0.9であり、アイテム1とアイテム4との間の類似度が0.3であると仮定する。
【0170】
次いで、救済措置エンジン206は、アイテム1の関連アイテム(アイテム3、アイテム4)を関連アイテム候補に設定する(Step.3)。次いで、救済措置エンジン206は、該当アイテムと各関連アイテム候補(アイテム3、アイテム4)との間の類似度を算出する(Step.4)。この類似度の計算方法としては、例えば、下記の式(7)および式(8)のように、該当アイテムとアイテム1との間の類似度(値A)に、アイテム1と各関連アイテム候補との間の類似度(値B)を乗算する方法がある。
【0171】
【数5】

【0172】
上記のようにして各関連アイテム候補と該当アイテムとの間の類似度が算出され、関連アイテム候補が該当アイテムの関連アイテムに追加される(Step.5)。このとき、救済措置エンジン206は、該当アイテムに元から付与されていた関連アイテムも含めて、関連アイテムの類似度が高い順に上位N個(Nは指定個数)のアイテムを付与する。
【0173】
なお、上記の実施形態において、該当アイテムと各関連アイテム候補との間の関連度を算出する方法として、次のような変形が可能である。例えば、該当アイテムをアイテム1、関連アイテム候補をアイテムNとし、関連アイテム候補を得るのに用いたアイテム群のアイテムをアイテム2〜N−1とする。これらのアイテム(アイテム1〜N)を用いることで、アイテム1とアイテムNとの間の関連度は、下記の式(9)のように表現することができる。ただし、各アイテム間の関連度は0〜1の間の値に正規化されているものとする。
【0174】
【数6】

【0175】
上記の方法を用いると、実際に関連のあるアイテムから処理が開始されるため、ある程度以上の関連性があるアイテムの取得が見込める。
【0176】
[関連アイテムの算出方法]
ここで、図20を参照しながら、関連アイテムメタDB110に格納された情報に基づいて関連アイテムを算出する方法について説明する。図20は、本実施形態に係る関連アイテムの算出方法の流れを示す説明図である。以下で説明する関連アイテムの算出処理は、主に、推薦エンジン112により実行される。なお、この方法を用いると、比較的高速な動作が期待できる。
【0177】
図20に示すように、まず、推薦エンジン112により、指定されたアイテムの関連アイテムに付与されたメタが関連アイテムメタDB110から取得される(S292)。次いで、推薦エンジン112により、取得したメタの中で、関連度が高い順に上位N個のメタが関連アイテムに設定される(S294)。
【0178】
ところで、推薦エンジン112は、単純に関連アイテムのメタを関連度順にソートして関連アイテムに設定することができる。ただし、推薦エンジン112は、各アイテムが持つ関連アイテムのメタ以外のメタ情報を利用し、類似度等の情報と組み合わせて関連アイテムを算出することもできる。例えば、推薦エンジン112は、協調フィルタリングによる結果と、コンテンツベースフィルタリングによる結果とを組み合わせて関連アイテムを算出することもできる。そこで、これらの方法について以下で簡単に説明する。
【0179】
(類似度計算による関連アイテムの算出方法)
アイテム情報ベクトル間の類似度を計算する方法としては、例えば、アイテム情報ベクトルの内積、コサイン尺度、ユークリッド距離等を計算する方法がある。ここでは、アイテム情報ベクトルの内積を利用する方法について述べる。
【0180】
アイテムが持つメタタイプの集合Aに含まれるメタをaとする。また、メタaの重みをWaとする。さらに、該当アイテムXのメタaが属するメタタイプベクトルをXaとし、計算対象となるアイテム(以下、対象アイテム)Yのメタaが属するメタタイプベクトルをYaとする。このような表現を利用すると、該当アイテムと対象アイテムとの間の類似度は、下記の式(10)により計算される。
【0181】
【数7】

【0182】
なお、上記の式(10)では、2つのメタタイプベクトル(Xa、Ya)の内積に重みWaを乗算しているが、各メタタイプベクトルに各メタの重みを乗算するように設定されていてもよい。
【0183】
(変形例:類似度計算方法)
ここで、図21を参照しながら、類似度計算に関する変形例について説明する。図21は、本変形例に係る類似度計算方法を利用した関連アイテムの算出方法の流れを示す説明図である。この変形例では、該当アイテムと対象アイテム群との間で、各アイテムのベクトルにより類似度が算出され、該当アイテムが持つ関連アイテムメタに含まれるアイテムの関連度が積算される。されに、その積算値から最終的な類似度が計算され、その類似度の高い順に上位N個のアイテムが関連アイテムとして算出されるというものである。
【0184】
図21に示すように、まず、推薦エンジン112により、アイテム情報DB114から該当アイテムのアイテム情報が読み出される(S302)。次いで、推薦エンジン112により、計算対象のアイテム群(以下、対象アイテム群)が選択される(S304)。次いで、反復処理(A)が実行される。この反復処理(A)は、対象アイテム群について反復実行される。まず、推薦エンジン112は、対象アイテム群の中から、1つの対象アイテムを選択し(反復処理(A)の開始)、その対象アイテムのアイテム情報をアイテム情報DB114から取得する(S306)。
【0185】
次いで、推薦エンジン112は、取得したアイテム情報のアイテム情報ベクトルに基づいて該当アイテムと対象アイテムとの間の類似度を計算する(S308)。このとき、計算された類似度は、結果リストに記録される。その後、推薦エンジン112により、他の対象アイテムが1つ選択され、ステップS306、S308の処理が実行される(反復処理(A)の継続)。ただし、対象アイテム群に含まれる全ての対象アイテムについてステップS306、S308の処理が実行された場合、推薦エンジン112は、ステップS310の処理に進行する(反復処理(A)の終了)。
【0186】
ステップS310では、推薦エンジン112により、該当アイテムに付与された関連アイテムメタに含まれるアイテム群が取得される(S310)。次いで、推薦エンジン112は、反復処理(B)に進行する。この反復処理(B)は、関連アイテムメタのアイテム群に含まれる全てのアイテムについて反復実行される。まず、推薦エンジン112は、取得したアイテム群の中から1つのアイテムを選択し(反復処理(B)の開始)、そのアイテムと同一のアイテムが結果リスト中に存在するかを検索する(S312)。
【0187】
次いで、推薦エンジン112は、結果リスト中に同一アイテムが存在するか否かを判断する(S314)。結果リスト中に同一アイテムが存在する場合、推薦エンジン112は、ステップS316の処理に進行する。一方、結果リスト中に同一アイテムが存在しない場合、推薦エンジン112は、ステップS318の処理に進行する。
【0188】
ステップS316では、推薦エンジン112により、関連アイテムメタ毎に設定された関連度に対して重みが掛けられ、結果リストに含まれる類似度に積算される(S316)。一方、ステップS318では、推薦エンジン112により、関連アイテムメタ毎に設定された関連度に重み付けされた値が類似度として結果リストに格納される(S318)。ただし、関連アイテムメタの重みとは、関連アイテムメタの関連度をどの程度重要視するのかを示す値であり、予め与えられている。
【0189】
その後、推薦エンジン112は、アイテム群に含まれる他のアイテムを選択し、ステップS312〜S316(またはS318)の処理を反復実行する(反復処理(B)の継続)。ただし、アイテム群に含まれる全てのアイテムに対してステップS312〜S316(またはS318)の処理を実行した場合、推薦エンジン112は、ステップS320の処理に進行する。
【0190】
ステップS320では、推薦エンジン112により、類似度が高い順に結果リストのレコードがソートされる(S320)。次いで、推薦エンジン112は、類似度が高い順に上位N個のアイテムを該当アイテムの関連アイテムに設定し(S322)、関連アイテムの算出に係る一連の処理を終了する。
【0191】
(類似度計算による関連アイテム算出方法のまとめ)
ここで、図22を参照しながら、類似度計算による関連アイテムの算出方法について概念的な説明を加える。図22は、上記の類似度計算による関連アイテムの算出方法を概念的に示した説明図である。
【0192】
図22に示すように、まず、推薦エンジン112により、該当アイテムのアイテム情報ベクトルと、対象ベクトルのアイテム情報ベクトルとに基づいて類似度が計算される(Step.1)。ここで算出された類似度は対象アイテム毎に結果リストに記録される。さらに、結果リストに記録された類似度には、該当アイテムの関連アイテムメタに関する類似度が加算される(Step.2)。このとき、該当アイテムの関連アイテムに対する各対象アイテムの類似度には、それぞれ所定の重みが乗算される。そして、その乗算値が結果リストに記録された対象アイテム毎の類似度に加算される。その後、結果リストのレコードは、類似度が大きい順にソートされる(Step.3)。推薦エンジン112は、ソート後の結果リストから類似度が高い順に関連アイテムを抽出し、該当アイテムの関連アイテムとして提供する。
【0193】
上記の方法は、該当アイテムのアイテム情報ベクトルと対象アイテムのアイテム情報ベクトルとの間で類似度計算が完了した後に、関連アイテムメタの重みを足しあわせるというものであった。これの応用として、例えば、該当アイテムのアイテム情報ベクトルと対象アイテムのアイテム情報ベクトルとの間で類似度計算が実行される際に、アイテム情報ベクトルの一要素として関連アイテムメタを付加する方法も考えられる。この方法を利用しても、上記の方法と同様の計算が実現できる。
【0194】
(応用例1)
そこで、図23、図24を参照しながら、アイテム情報ベクトルの一要素に関連アイテムメタを付加する方法について簡単に説明する。図23は、この方法で利用されるアイテム情報ベクトル(またはユーザ嗜好ベクトル)の構成例を示す説明図である。図24は、アイテム情報ベクトルの一要素に関連アイテムメタを付加する方法による関連アイテムの決定処理の流れを示す説明図である。
【0195】
図24に示すように、まず、推薦エンジン112は、アイテム情報DB114から該当アイテムのアイテム情報を取得する(S332)。次いで、推薦エンジン112は、該当アイテムで用いるメタタイプの情報に基づいてアイテム情報ベクトルを構築する(S334)。次いで、推薦エンジン112は、計算対象となる対象ベクトル群を全アイテムの中から選択する(S336)。次いで、推薦エンジン112は、反復処理(A)を実行する。この反復処理(A)は、対象アイテム群に含まれる全ての対象アイテムについて反復実行される。
【0196】
推薦エンジン112は、対象アイテム群から1つの対象アイテムを選択し(反復処理(A)の開始)、その対象アイテムのアイテム情報をアイテム情報DB114から取得する(S338)。次いで、推薦エンジン112は、対象アイテムで用いるメタタイプの情報に基づいてアイテム情報ベクトルを構築する(S340)。次いで、推薦エンジン112は、該当アイテムのアイテム情報ベクトルと、対象アイテムのアイテム情報ベクトルとの間の類似度を計算し、その計算結果を結果リストに記録する(S342)。次いで、推薦エンジン112は、対象ベクトル群に含まれる他の対象ベクトルを選択し、その対象ベクトルについて再びステップS338〜S342の処理を実行する(反復処理(A)の継続)。ただし、推薦エンジン112は、対象ベクトル群に含まれる全ての対象ベクトルについてステップS338〜S342の処理を実行した場合(反復処理(A)の終了)、ステップS344の処理に進行する。
【0197】
ステップS344では、推薦エンジン112により、類似度が大きい順に結果リストのレコードをソートする(S344)。次いで、推薦エンジン112は、類似度が大きい順に上位N個のアイテムを結果リストから抽出して該当アイテムの関連アイテムに決定する(S346)。その後、推薦エンジン112は、類似度計算に基づく関連アイテムの算出に係る一連の処理を終了する。
【0198】
この方法を用いることで、協調フィルタリングとコンテンツベースフィルタリングの要素を織り交ぜた結果が算出可能である上、コンテンツベースフィルタリングの計算と協調フィルタリングの計算とが同時に行われるため、高速な計算が実現される。
【0199】
(応用例2)
ところで、上記の方法とは異なり、コンテンツベースフィルタリングの結果に関連アイテムメタ間の類似度を付加することで、協調フィルタリングの要素を加味した結果を得る方法も1つの応用例として考えられる。この場合、アイテム情報ベクトル(またはユーザ嗜好ベクトル)の構成が、図25に示すように変形される。ただし、基本的な処理の流れは、図24と実質的に同一であるため、詳細な説明を省略する。
【0200】
[関連アイテムの提示方法]
次に、図26、および図27を参照しながら、上記の推薦エンジン112による関連アイテムの提示方法について説明する。図26は、関連アイテムの提示方法に係る一連の処理の流れを示す説明図である。図27は、図26に示す処理の変形例を示す説明図である。
【0201】
図26に示すように、まず、推薦エンジン112は、情報機器10を介してユーザから指定されたアイテムの関連アイテムを取得する(S352)。次いで、推薦エンジン112は、関連アイテムメタの中で、関連度が高い順に上位N個の関連アイテムを算出し、その関連アイテム群を情報機器10に提示する(S354)。
【0202】
図26に示した方法の場合、推薦エンジン112は、ユーザの嗜好を用いずに関連アイテムを算出している。そのため、アクセスしてきたユーザがどのような嗜好を持っているかが考慮されずに、嗜好が異なっても同じアイテムが関連アイテムとして提示されてしまう。そこで、この方法の中で、ユーザの嗜好を考慮した関連アイテムの提示ができるように変形したものが図27の処理である。図27の処理によると、アイテム間の関係を利用しつつ、アクセスしてきたユーザの嗜好に合った関連アイテムを提示できるものと考えられる。そこで、図27の処理について説明する。
【0203】
図27に示すように、まず、推薦エンジン112は、情報機器10を介してユーザから指定されたアイテムの関連アイテムを取得する(S362)。次いで、推薦エンジン112は、該当アイテムにアクセスしたユーザ(以下、該当ユーザ)の嗜好をユーザ嗜好情報DB204より取得する(S364)。次いで、推薦エンジン112は、該当ユーザの嗜好情報と、ステップS362で取得した関連アイテム群との間の関連度を計算し、関連アイテム群に含まれるアイテムを関連度が高い順にソートする(S366)。次いで、推薦エンジン112は、関連アイテム群の中で、関連度が高い順に上位N個の関連アイテムを算出し、その関連アイテム群を情報機器10に提示する(S368)。
【0204】
以上、本発明の第1および第2実施形態について説明した。また、各実施形態について、種々の変形例、および応用例を示した。これらの実施形態に係る技術を適用することで、コンテンツベースフィルタリングの枠組みの中で、協調フィルタリングのようなユーザの嗜好を考慮した関連アイテムの提示が可能になる。さらに、ユーザ数が少ない場合にも、アイテム間の類似度を利用して関連アイテムが提示されるため、コールドスタート問題に対する解決手段を提供することにも繋がる。さらに言えば、1度も参照されていないアイテムに対しても、関連アイテムの提示が可能になる。逆に、メタが少ないアイテムに関しても、関連アイテムを提示できるようになる。
【0205】
このように、上記の実施形態に係る技術を用いることで様々な効果が得られる。そして、この効果は、ユーザが自身の持つ嗜好の幅を広げることにも役立つし、逆に、ユーザの潜在的な嗜好により適合した関連アイテムの推薦が実現される。
【0206】
[ハードウェア構成(情報処理装置)]
上記の各システムが有する構成要素の機能は、例えば、図28に示すハードウェア構成を有する情報処理装置により、上記の機能を実現するためのコンピュータプログラムを用いて実現することが可能である。図28は、上記の各システムが有する構成要素の機能を実現することが可能な情報処理装置のハードウェア構成を示す説明図である。この情報処理装置の形態は任意であり、例えば、パーソナルコンピュータ、携帯電話、PHS(Personal Handy−phone System)、PDA(Personal Digital Assistant)等の携帯情報端末、ゲーム機、または各種の情報家電等がこれに含まれる。
【0207】
図28に示すように、この情報処理装置は、主に、CPU(Central Processing Unit)902と、ROM(Read Only Memory)904と、RAM(Random Access Memory)906と、ホストバス908と、ブリッジ910と、外部バス912と、インターフェース914と、入力部916と、出力部918と、記憶部920と、ドライブ922と、接続ポート924と、通信部926とにより構成される。
【0208】
CPU902は、例えば、演算処理装置、または制御装置として機能し、ROM904、RAM906、記憶部920、またはリムーバブル記録媒体928に記録された各種プログラムに基づいて各構成要素の動作全般またはその一部を制御する。ROM904は、例えば、CPU902に読み込まれるプログラムや演算に用いるデータ等を格納する。RAM906は、例えば、CPU902に読み込まれるプログラムや、そのプログラムを実行する際に適宜変化する各種パラメータ等を一時的または永続的に格納する。これらの構成要素は、例えば、高速なデータ伝送が可能なホストバス908によって相互に接続されている。また、ホストバス908は、例えば、ブリッジ910を介して比較的データ伝送速度が低速な外部バス912に接続されている。
【0209】
入力部916は、例えば、マウス、キーボード、タッチパネル、ボタン、スイッチ、およびレバー等の操作手段である。また、入力部916は、赤外線やその他の電波を利用して制御信号を送信することが可能なリモートコントロール手段(所謂、リモコン)であってもよい。なお、入力部916は、上記の操作手段を用いて入力された情報を入力信号としてCPU902に伝送するための入力制御回路等により構成されている。
【0210】
出力部918は、例えば、CRT(Cathode Ray Tube)、LCD(Liquid Crystal Display)、PDP(Plasma DisplayPanel)、またはELD(Electro−Luminescence Display)等のディスプレイ装置、スピーカ、ヘッドホン等のオーディオ出力装置、プリンタ、携帯電話、またはファクシミリ等、取得した情報を利用者に対して視覚的または聴覚的に通知することが可能な装置である。
【0211】
記憶部920は、各種のデータを格納するための装置であり、例えば、ハードディスクドライブ(HDD;Hard Disk Drive)等の磁気記憶デバイス、半導体記憶デバイス、光記憶デバイス、または光磁気記憶デバイス等により構成される。
【0212】
ドライブ922は、例えば、磁気ディスク、光ディスク、光磁気ディスク、または半導体メモリ等のリムーバブル記録媒体928に記録された情報を読み出し、またはリムーバブル記録媒体928に情報を書き込む装置である。リムーバブル記録媒体928は、例えば、DVDメディア、Blu−rayメディア、HD−DVDメディア、コンパクトフラッシュ(登録商標)(CF;CompactFlash)、メモリースティック、またはSDメモリカード(Secure Digital memory card)等である。リムーバブル記録媒体928は、例えば、非接触型ICチップを搭載したICカード(Integrated Circuit Card)や電子機器等であってもよい。
【0213】
接続ポート924は、例えば、USB(Universal Serial Bus)ポート、IEEE1394ポート、SCSI(Small Computer System Interface)、RS−232Cポート、または光オーディオ端子等のような外部接続機器930を接続するためのポートである。外部接続機器930は、例えば、プリンタ、携帯音楽プレーヤ、デジタルカメラ、デジタルビデオカメラ、またはICレコーダ等である。
【0214】
通信部926は、ネットワーク932に接続するための通信デバイスであり、例えば、有線または無線LAN(Local Area Network)、Bluetooth(登録商標)、またはWUSB(Wireless USB)用の通信カード、光通信用のルータ、ADSL(Asymmetric Digital Subscriber Line)用のルータ、または各種通信用のモデム等である。また、通信部926に接続されるネットワーク932は、有線または無線により接続されたネットワークであり、例えば、インターネット、家庭内LAN、赤外線通信、可視光通信、放送、または衛星通信等である。
【0215】
以上、添付図面を参照しながら本発明の好適な実施形態について説明したが、本発明は係る例に限定されないことは言うまでもない。当業者であれば、特許請求の範囲に記載された範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、それらについても当然に本発明の技術的範囲に属するものと了解される。
【図面の簡単な説明】
【0216】
【図1】本発明の第1実施形態に係る関連アイテム提供システムのシステム構成を示す説明図である。
【図2】同実施形態に操作ログDBの構成例を示す説明図である。
【図3】同実施形態にアクセスウェイトDBの構成例を示す説明図である。
【図4】同実施形態に関連アイテムメタDBの構成例を示す説明図である。
【図5】同実施形態にアイテム情報DBの構成例を示す説明図である。
【図6】同実施形態に係る関連アイテム付与方法の流れを示す説明図である。
【図7】同実施形態に係るアイテムベクトル、およびユーザ嗜好ベクトルの構成例を示す説明図である。
【図8】同実施形態に係る関連アイテム付与方法の流れを示す説明図である。
【図9】同実施形態に係る関連アイテムの類似度計算方法を示す説明図である。
【図10】同実施形態に係る関連アイテム付与方法の流れを示す説明図である。
【図11】同実施形態に係る関連アイテムの類似度計算方法を示す説明図である。
【図12】本発明の第2実施形態に係る関連アイテム提供システムのシステム構成を示す説明図である。
【図13】同実施形態に係るユーザ嗜好情報DBの構成例を示す説明図である。
【図14】同実施形態に係る関連アイテム付与方法の流れを示す説明図である。
【図15】同実施形態に係る関連アイテム付与方法の流れを示す説明図である。
【図16】同実施形態に係る関連アイテム付与方法の流れを示す説明図である。
【図17】同実施形態に係る関連アイテム付与方法の流れを示す説明図である。
【図18】同実施形態に係る関連アイテム付与方法の流れを示す説明図である。
【図19】同実施形態に係る関連アイテムの類似度計算方法を示す説明図である。
【図20】同実施形態に係る関連アイテム付与方法の流れを示す説明図である。
【図21】同実施形態に係る関連アイテム付与方法の流れを示す説明図である。
【図22】同実施形態に係る関連アイテムの類似度計算方法を示す説明図である。
【図23】同実施形態に係る関連アイテムの類似度計算方法を示す説明図である。
【図24】同実施形態に係る関連アイテム付与方法の流れを示す説明図である。
【図25】同実施形態に係る関連アイテムの類似度計算方法を示す説明図である。
【図26】同実施形態に係る関連アイテム付与方法の流れを示す説明図である。
【図27】同実施形態に係る関連アイテム付与方法の流れを示す説明図である。
【図28】本発明の各実施形態に係る関連アイテム提供システムが有する機能を実現することが可能な情報処理装置のハードウェア構成例を示す説明図である。
【符号の説明】
【0217】
10 情報機器
100、200 関連アイテム提供システム
102 操作ログDB
104、202 嗜好抽出エンジン
106 アクセスウェイトDB
108 関連性抽出エンジン
110 関連アイテムメタDB
112 推薦エンジン
114 アイテム情報DB
116、206 救済措置エンジン
204 ユーザ嗜好情報DB

【特許請求の範囲】
【請求項1】
所定のアイテムと計算対象アイテムとの間の類似度を計算する第1類似度計算部と、
前記類似度が高い順に所定数の計算対象アイテムを前記所定のアイテムの関連アイテムに決定する関連アイテム決定部と、
を備え、
前記所定のアイテムに対し、ユーザの行動履歴に基づいて前記計算対象アイテムに関連付けられたメタ情報を追加した上で、前記所定のアイテムと前記計算対象アイテムとの間の類似度を算出する、情報処理装置。
【請求項2】
前記所定のアイテムに関連付けられた関連アイテムの中に前記計算対象アイテムが含まれる場合、当該計算対象アイテムの関連度を前記第1類似度計算部により算出された当該計算対象アイテムの類似度に加算する関連度加算部をさらに備える、請求項1に記載の情報処理装置。
【請求項3】
所定のアイテムのメタ情報と同じメタ情報を保持する候補アイテムに対し、ユーザの行動履歴に基づいて関連付けられた関連アイテムの関連度を取得する関連度取得部と、
前記所定のアイテムと前記関連アイテムまたは前記候補アイテムとの間の類似度を取得する類似度取得部と、
前記関連度および前記類似度に基づき、前記関連アイテムまたは候補アイテムと前記所定のアイテムとの間の類似度を計算する第2類似度計算部と、
前記関連アイテム決定部により決定された関連アイテム数が前記所定数未満の場合、前記第2類似度計算部により計算された類似度が大きい順にアイテムを選択して前記関連アイテムに追加する関連アイテム追加部と、
をさらに備える、請求項1に記載の情報処理装置。
【請求項4】
前記第2類似度計算部は、前記類似度取得部により前記所定のアイテムと前記関連アイテムとの間の類似度が取得された場合、当該類似度と前記関連度とを乗算し、その乗算値を前記所定のアイテムと前記候補アイテムとの間の類似度とし、
前記関連アイテム追加部は、前記第2類似度計算部により算出された類似度が大きい順に前記候補アイテムを選択して前記関連アイテムに追加する、請求項3に記載の情報処理装置。
【請求項5】
前記第2類似度計算部は、前記類似度取得部により前記所定のアイテムと前記候補アイテムとの間の類似度が取得された場合、当該類似度と前記関連度とを乗算し、その乗算値を前記所定のアイテムと前記関連アイテムとの間の類似度とし、
前記関連アイテム追加部は、前記第2類似度計算部により算出された類似度が大きい順に前記関連アイテムを選択して前記関連アイテムに追加する、請求項3に記載の情報処理装置。
【請求項6】
前記関連度取得部は、前記所定のアイテムが保持するメタ情報の中で、予めメタ情報毎に設定された優先度が高いメタ情報を保持する前記候補アイテムについて前記関連アイテムの関連度を取得する、請求項3に記載の情報処理装置。
【請求項7】
前記所定のアイテムにアクセスするユーザの嗜好または前記所定のアイテムが保持するメタ情報の統計データに応じてメタ情報毎の優先度を設定する優先度設定部をさらに備え、
前記関連度取得部は、前記所定のアイテムが保持するメタ情報の中で、前記優先度設定部により設定された優先度が高いメタ情報を保持する前記候補アイテムについて前記関連アイテムの関連度を取得する、請求項3に記載の情報処理装置。
【請求項8】
前記関連度取得部は、前記所定のアイテムが保持する全てのメタ情報を保持する前記候補アイテムについて前記関連アイテムの関連度を取得し、前記候補アイテム毎に全ての関連度を積算して当該候補アイテムの関連度とする、請求項3に記載の情報処理装置。
【請求項9】
前記所定のアイテムに関連付けられたアイテムを第1の関連アイテムとし、第N−1の関連アイテム(N≧2)の関連付けられたアイテムを第Nの関連アイテムとすると、前記関連度取得部は、前記第K−1の関連アイテムと第Kの関連アイテムとの間の関連度(2≦K≦N)を全て乗算し、前記第1の関連アイテムと前記第Nの関連アイテムとの間の関連度を取得する、請求項3に記載の情報処理装置。
【請求項10】
前記ユーザの嗜好が近い順に前記関連アイテムをソートして当該ユーザに提示する関連アイテム提示部をさらに備える、請求項1に記載の情報処理装置。
【請求項11】
情報処理装置により、
所定のアイテムに対し、ユーザの行動履歴に基づいて計算対象アイテムに関連付けられたメタ情報が追加されるステップと、
前記所定のアイテムと前記計算対象アイテムとの間の類似度が算出されるステップと、
前記類似度が高い順に所定数の計算対象アイテムが前記所定のアイテムの関連アイテムに決定されるステップと、
前記関連アイテムがユーザに提示されるステップと、
を含む、関連アイテムの提供方法。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate

【図9】
image rotate

【図10】
image rotate

【図11】
image rotate

【図12】
image rotate

【図13】
image rotate

【図14】
image rotate

【図15】
image rotate

【図16】
image rotate

【図17】
image rotate

【図18】
image rotate

【図19】
image rotate

【図20】
image rotate

【図21】
image rotate

【図22】
image rotate

【図23】
image rotate

【図24】
image rotate

【図25】
image rotate

【図26】
image rotate

【図27】
image rotate

【図28】
image rotate


【公開番号】特開2009−266096(P2009−266096A)
【公開日】平成21年11月12日(2009.11.12)
【国際特許分類】
【出願番号】特願2008−117304(P2008−117304)
【出願日】平成20年4月28日(2008.4.28)
【出願人】(000002185)ソニー株式会社 (34,172)
【Fターム(参考)】