JP2010067175A - ハイブリッド型コンテンツ推薦サーバ、推薦システムおよび推薦方法 - Google Patents

Abstract

【課題】コンテンツベース型および協調フィルタリング型の両方の長所を有し、かつ、ユーザ数およびコンテンツ数が増加してもコンテンツの推薦を高速に行う。
【解決手段】コンテンツサーバからコンテンツのメタデータを含むコンテンツ情報を収集してコンテンツＤＢ２２に格納する。同様に、ユーザ端末からユーザのコンテンツに対する嗜好情報をユーザプロファイルとして収集してユーザプロファイルＤＢ２４に格納する。次に、コンテンツ情報およびユーザプロファイルに係るインデックスをそれぞれ作成してインデックスＤＢ２６に格納する。そして、ユーザプロファイルＤＢ２４から取得される被推薦ユーザに係るユーザプロファイルに基づいてインデックスＤＢ２６を参照し、被推薦ユーザの嗜好に適合したコンテンツを推薦する。
【選択図】図２

Description

本発明は、ユーザの嗜好に適合したコンテンツを推薦するコンテンツ推薦サーバ、推薦システムおよび推薦方法に関する。

近年、デジタル化にともない多数のコンテンツへのアクセスが可能になってきている。例えば、書籍、ＷｅＢサイト、ニュース記事、ブログ、テレビ番組、写真、音楽、動画などインターネット上には膨大なデジタル化されたコンテンツデータが蓄積されている。これらの膨大なコンテンツの中から興味のあるコンテンツをユーザが手動で探し出すのは難しくなっている。このような状況を改善するためにユーザの好みをシステムが自動的に把握して、ユーザが好むと思われるコンテンツを提示するコンテンツ推薦システム（例えば、特許文献１を参照）の重要性が高まっている。コンテンツ推薦システムを用いることでユーザは膨大なコンテンツの中から好みのコンテンツを容易に見つけ出すことができる。

コンテンツ推薦システムは大きく分けるとコンテンツベース型と協調フィルタリング型に分類できる。コンテンツベース型推薦システムは、コンテンツの内容に基づく手法の総称である。コンテンツベース型推薦システムは、ユーザが好むコンテンツと内容が類似した別のコンテンツを推薦するというのが基本的な方針である。

コンテンツが類似しているかの判断にはコンテンツの内容情報が必要となる。例えば、ＷｅＢサイト、ニュース記事、ブログといったテキストで表現されたコンテンツの場合、その中に含まれる単語を用いてどれくらい共通の単語があるかをもとに類似度が求められる。書籍やテレビ番組も著者、ジャンル、出演者、概要などのテキストメタデータが付与されているため同様に単語を用いて類似度が求められる。写真、音楽、動画などのマルチメディアデータの場合は、テキストメタデータが付与されている場合は単語を用いることもできるが、それがない場合でも画像ではカラーヒストグラム、音楽では波形、スペクトルなどの特徴ベクトルを用いて類似度が求められる。

協調フィルタリング型推薦システムは、他人のユーザプロファイルを利用する手法の総称である。ここでいうユーザプロファイルとは好きなコンテンツＩＤの集合を指している。協調フィルタリング型推薦システムは、自分と好みの傾向が類似している別のユーザを探し、そのユーザが好んでいて自分が知らないコンテンツを推薦してもらうというのが基本的な方針である。協調フィルタリング型推薦システムの特徴は、好みの傾向が類似しているユーザを探すのにコンテンツの内容は必要なく、コンテンツを識別するコンテンツＩＤだけがあればよい点である。協調フィルタリング型推薦システムはコンテンツの内容を解析する必要がないという利点から現在商用システムで幅広く用いられている。

まとめるとコンテンツベース型推薦システムは類似しているコンテンツを探す、協調フィルタリング型推薦システムは類似しているユーザを探すというのが両者のアプローチの大きな違いである。コンテンツベース型推薦システム、協調フィルタリング型推薦システムともに類似したコンテンツやユーザを探すという処理が基本にある。

近年、類似したコンテンツを高速に探すための手法あるいはデータ構造としてＬＳＨ（Locality Sensitive Hashing）が注目を集めている（例えば、非特許文献１、２、３を参照）。ＬＳＨは、近傍探索のアルゴリズムであり、コンテンツを予めハッシュと呼ばれるデータ構造に格納する（インデキシング）ことでクエリとして与えたコンテンツと類似したコンテンツを大規模なコンテンツ集合から非常に高速に探すことができる。
特開２００８−６７３７０号公報 A. Z. Broder, On the Resemblance and Containment of Documents, Proceedings of the Compression and Complexity of Sequences,1997. M. S. Charikar, Similarity Estimation Techniques from Rounding Algorithms, Proceedings of the 34th Annual ACM Symposium onTheory of Computing, 2002. M. Datar, N. Immorlica, P. Indyk and V. S. Mirrokni, Locality-Sensitive Hashing Scheme Based on p-Stable Distributions, Proceedings of the 20th Annual Symposium on Computational Geometry, 2004.

発明が解決する１つめの課題は、コンテンツベース型推薦システムと協調フィルタリング型推薦システムのトレードオフである。コンテンツベース型推薦システムと協調フィルタリング型推薦システムはどのようなコンテンツが推薦されるかに違いがある。コンテンツベース型推薦システムは、ユーザの好みに過剰に適合したコンテンツばかり推薦されるため推薦の幅が狭いという欠点があるが、協調フィルタリング型推薦システムは他のユーザの好みが反映されるため推薦の幅が広いという利点がある。

また、協調フィルタリング型推薦システムはユーザのプロファイルを必要とするため好む人が少ないニッチなコンテンツや追加されたばかりの新しいコンテンツは推薦できないという欠点があるが、コンテンツベース型推薦システムはそのようなコンテンツでも推薦できるという利点がある。

このように、コンテンツベース型推薦システムと協調フィルタリング型推薦システムはトレードオフの関係にあり、どちらか単独での利用では不十分な推薦しかできないという課題があった。

発明が解決する２つめの課題は、推薦のスケーラビリティである。スケーラビリティのある（＝スケーラブルな）推薦システムとは、推薦システムの規模（ユーザ数、コンテンツ数）が大きくなっても高速に動作するシステムを指す。

先ほど述べたようにコンテンツベース型推薦システムは似ているコンテンツを探す、協調フィルタリング型推薦システムは似ているユーザを探すのが基本的なアプローチである。そのため、従来のコンテンツベース型推薦システムでは、コンテンツ数が増えるにしたがって、協調フィルタリング型推薦システムでは、ユーザ数が増えるにしたがってスケーラビリティが低下するという課題があった。

そこで、本発明は、上記従来技術の問題に鑑み、コンテンツベース型および協調フィルタリング型の両方の長所を有し、かつ、ユーザ数およびコンテンツ数が増加してもコンテンツの推薦を高速に行えるハイブリッド型コンテンツ推薦サーバ、推薦システム、および推薦方法を提供することを目的とする。

本発明に係るハイブリッド型コンテンツ推薦サーバは、ネットワークを介して接続されたコンテンツサーバからコンテンツのメタデータを含むコンテンツ情報を収集するコンテンツ情報収集部と、前記収集されたコンテンツ情報を格納するコンテンツＤＢと、前記ネットワークを介して接続されたユーザ端末からユーザの前記コンテンツに対する嗜好情報をユーザプロファイルとして収集するユーザプロファイル収集部と、前記収集されたユーザプロファイルを格納するユーザプロファイルＤＢと、前記コンテンツＤＢからコンテンツのメタデータを取得し、このメタデータから前記コンテンツに係るインデックスを作成するコンテンツインデクサと、前記ユーザプロファイルＤＢからユーザプロファイルを取得し、このユーザプロファイルに含まれるコンテンツをキーとして前記ユーザに係るインデックスを作成するユーザインデクサと、前記作成された前記コンテンツおよび前記ユーザに係るインデックスを格納するインデックスＤＢと、前記ユーザプロファイルＤＢから取得される被推薦ユーザに係る前記ユーザプロファイルに基づいて前記インデックスＤＢを参照し、前記被推薦ユーザの嗜好に適合したコンテンツを推薦するコンテンツ推薦部と、を有することを特徴とする。

本発明に係るハイブリッド型コンテンツ推薦システムは、コンテンツのメタデータを提供するコンテンツサーバと、このコンテンツサーバにネットワークを介して接続され、前記コンテンツのメタデータおよびユーザプロファイルを管理し、前記コンテンツの推薦リストを出力するコンテンツ推薦サーバと、このコンテンツ推薦サーバに前記ネットワークを介して接続され、前記コンテンツ推薦サーバから前記推薦リストを取得するユーザ端末と、からなり、前記コンテンツ推薦サーバは、前記コンテンツサーバからコンテンツのメタデータを含むコンテンツ情報を収集するコンテンツ情報収集部と、前記収集されたコンテンツ情報を格納するコンテンツＤＢと、前記ユーザ端末からユーザの前記コンテンツに対する嗜好情報をユーザプロファイルとして収集するユーザプロファイル収集部と、前記収集されたユーザプロファイルを格納するユーザプロファイルＤＢと、前記コンテンツＤＢからコンテンツのメタデータを取得し、このメタデータから前記コンテンツに係るインデックスを作成するコンテンツインデクサと、前記ユーザプロファイルＤＢからユーザプロファイルを取得し、このユーザプロファイルに含まれるコンテンツをキーとして前記ユーザに係るインデックスを作成するユーザインデクサと、前記作成された前記コンテンツおよび前記ユーザに係るインデックスを格納するインデックスＤＢと、前記ユーザプロファイルＤＢから取得される被推薦ユーザに係る前記ユーザプロファイルに基づいて前記インデックスＤＢを参照し、前記被推薦ユーザの嗜好に適合したコンテンツを推薦するコンテンツ推薦部と、を有することを特徴とする。

本発明に係るハイブリッド型コンテンツ推薦方法は、ネットワークを介して接続されたコンテンツサーバからコンテンツのメタデータを含むコンテンツ情報を収集するコンテンツ情報収集ステップと、前記ネットワークを介して接続されたユーザ端末からユーザの前記コンテンツに対する嗜好情報をユーザプロファイルとして収集するユーザプロファイル収集ステップと、前記収集されたコンテンツのメタデータから前記コンテンツに係るインデックスを作成するコンテンツインデックス作成ステップと、前記収集されたユーザプロファイルに含まれるコンテンツをキーとして前記ユーザに係るインデックスを作成するユーザインデックス作成ステップと、被推薦ユーザに係る前記ユーザプロファイルに基づいて前記コンテンツおよび前記ユーザに係るインデックスを参照し、前記被推薦ユーザの嗜好に適合したコンテンツを推薦するコンテンツ推薦ステップと、を有することを特徴とする。

本発明によれば、コンテンツベース型および協調フィルタリング型の両方の長所を有し、かつ、ユーザ数およびコンテンツ数が増加してもコンテンツの推薦を高速に行えるハイブリッド型コンテンツ推薦サーバ、推薦システム、および推薦方法が提供される。

以下、本発明の実施形態について図面を用いて説明する。まず、コンテンツの種類を限定せずにシステムの全体構成、モジュール構成、処理手順を説明し、その後、コンテンツをテキストメタデータで表現されたテレビ番組に限定したテレビ番組推薦システムに基づいて具体的に説明する。

＜システムの全体構成＞
図１は、本発明の一実施形態に係るコンテンツ推薦システムの全体構成を示すブロック図である。

コンテンツ推薦サーバ１１は、プログラムを実行するＣＰＵ１１１、インデキシングプログラム、コンテンツ推薦プログラムをロードするＲＡＭ１１２、コンテンツＤＢ、ユーザプロファイルＤＢ、およびインデックスＤＢを格納するハードディスクドライブ１１３、他のサーバと情報の送受信を行うネットワーク機器１１４、コンテンツ推薦サーバ１１と入力デバイス１３間で情報の入出力を行う入出力機器１１５から構成される。ディスプレイ１２と入力デバイス１３は、コンテンツ推薦サーバ１１の管理者がコンテンツの入力、更新などの管理を行うために必要な表示機器および入力機器である。

コンテンツサーバ１４は、コンテンツ情報を管理している別のサーバである。例えば、コンテンツがテレビ番組の場合、コンテンツサーバ１４は各放送局に当たり、そこからコンテンツ情報が送信されてくる。また、書籍、画像、楽曲、動画などのデータの場合、他社のコンテンツサーバが提供しているＷｅｂＡＰＩを用いて取得することができる。

Ｗｅｂサーバ１５は、コンテンツ推薦サーバ１１とユーザ間のインタフェースを提供するサーバである。例えば、コンテンツ推薦サーバ１１がコンテンツを表示し、ユーザは表示されたコンテンツの選択・視聴・購入・レイティングを行う。上述したユーザ行動に関する履歴情報は、Ｗｅｂサーバ１５を通してコンテンツ推薦サーバ１１に送られ、ユーザプロファイルとしてハードディスクドライブ１１３に保存される。

ネットワーク１６は、コンテンツ推薦サーバ１１とユーザ端末１７を繋ぐインターネットなどの広域ネットワークである。ユーザ端末１７は、ユーザがＷｅｂサーバ１５にアクセスするための機器であり、ネットワーク１６に接続可能であるとする。ユーザ端末１７としては、例えばパーソナルコンピュータ、ＰＤＡ、携帯電話、ＴＶ、ハードディスクレコーダなどが考えられる。ユーザ端末１７にはディスプレイ１８と入力デバイス１９が備えられているとする。ディスプレイ１８を通してコンテンツの閲覧やコンテンツ推薦サーバ１１から送信されるコンテンツ推薦リストを閲覧できる。ユーザは、入力デバイス１９を通してコンテンツの選択・視聴・購入・レイティングなどコンテンツに対する操作ができる。

＜コンテンツ推薦サーバ１１のモジュール構成＞
図２は、コンテンツ推薦サーバ１１のモジュール関係図である。

コンテンツ情報収集部２１は、コンテンツサーバ１４からコンテンツ本体やコンテンツのメタデータなどのコンテンツ情報を収集するモジュールである。コンテンツＤＢ２２は、コンテンツ情報収集部２１で収集されたコンテンツ情報を格納するデータベースである。尚、コンテンツＤＢ２２には、コンテンツ本体は格納せずに、コンテンツのメタデータのみを格納してもよい。ただし、コンテンツのメタデータのみを格納する場合は、ユーザ端末１７へはコンテンツへのリンクを提供し、ユーザ端末１７は、該当するコンテンツをコンテンツサーバ１４から取得する必要がある。

ユーザプロファイル収集部２３は、ユーザ端末１７からユーザのコンテンツに対する操作履歴情報をユーザプロファイルとして収集するモジュールである。ユーザプロファイルＤＢ２４は、ユーザプロファイル収集部２３で収集されたユーザプロファイルを格納するデータベースである。各ユーザがどのコンテンツを選択・視聴・購入・レイティングしたか否かをユーザプロファイル収集部２３が収集し、ユーザプロファイルＤＢ２４に格納する。ここでは、ユーザがどのコンテンツに興味があるか否かを表した情報（嗜好情報）をユーザプロファイルと呼ぶ。本実施形態では、ある一定期間にわたってユーザプロファイルを収集し、ユーザプロファイルＤＢ２４に格納されている状態を想定している。

インデキシング部２５は、コンテンツやユーザ情報を特徴ベクトルに変換し、ＬＳＨ（Locality Sensitive Hash）と呼ばれるデータ構造に格納する処理を行うモジュールであり、コンテンツをインデキシングするコンテンツインデクサ２５１とユーザをインデキシングするユーザインデクサ２５２から構成される。ここでは、コンテンツやユーザなどの元データをあるデータ構造に変換して格納する処理をインデキシングと呼び、作成されたデータ構造をインデックスと呼ぶ。インデキシングによってデータが圧縮されて保存領域が小さくなる、検索が高速になる等の利点がある。

インデックスＤＢ２６は、インデキシング部２５によって作成されたインデックスを格納するデータベースである。インデックスはＬＳＨというデータ構造で表現される。また、コンテンツのインデックスとユーザのインデックスは同じインデックスＤＢ２６の同じＬＳＨに格納されることが本発明のポイントである。

コンテンツ推薦部２７は、コンテンツ推薦を希望するユーザ（以下、「被推薦ユーザ」という。）に対してコンテンツを推薦するモジュール群であり、ユーザプロファイル入力部２７１、類似ユーザ検索部２７２、推薦コンテンツ決定部２７３、類似コンテンツ検索部２７４、推薦コンテンツ結合部２７５、および推薦リスト出力部２７６から構成される。

ユーザプロファイル入力部２７１に被推薦ユーザのユーザプロファイルが入力されると類似ユーザ検索部２７２において被推薦ユーザと嗜好の似ているユーザがインデックスＤＢ２６から検索される。また、同時に類似コンテンツ検索部２７４において被推薦ユーザの好むコンテンツと似ているコンテンツがインデックスＤＢ２６から検索される。このように、インデックスＤＢ２６を用いることで類似ユーザの検索と類似コンテンツの検索は同時にしかも高速に実行できる。

推薦コンテンツ決定部２７３は、類似ユーザ検索部２７２によって検索された類似ユーザから協調フィルタリングという手法を用いてコンテンツを選択するモジュールである。この際、類似ユーザのユーザプロファイル情報を用いるためユーザプロファイルＤＢ２４にアクセスする必要がある。

推薦コンテンツ結合部２７５は、類似コンテンツ検索部２７４の推薦コンテンツと推薦コンテンツ決定部２７３の推薦コンテンツを結合するモジュールである。推薦リスト出力部２７６は、被推薦ユーザの推薦コンテンツを推薦リストとして出力するモジュールである。推薦リストは、Ｗｅｂサーバ１５を通して、ユーザ端末１７へ送信される。

＜コンテンツ推薦サーバ１１の処理手順＞
図３は、インデキシング部２５の処理の具体例を示すフローチャートである。工程Ｓ３０１では、コンテンツＤＢ２２中の全てのコンテンツをコンテンツインデクサ２５１によってインデキシングし、インデックスＤＢ２６に格納する。工程Ｓ３０２では、ユーザプロファイルＤＢ２４中の全てのユーザをユーザインデクサ２５２によってインデキシングし、インデックスＤＢ２６に格納する。

尚、工程Ｓ３０１と工程Ｓ３０２は、互いに処理が独立しているため並列に動作させることも可能である。工程Ｓ３０１と工程Ｓ３０２は、対象となるコンテンツによって処理内容が異なる。後ほどコンテンツがテキストメタデータであるテレビ番組を例にして詳しく説明する。

図４は、コンテンツ推薦部２７の処理の具体例を示すフローチャートである。

工程Ｓ４０１では、被推薦ユーザのユーザプロファイルを入力する。工程Ｓ４０２では、被推薦ユーザのユーザプロファイル内の好きなコンテンツと類似するコンテンツを検索する。工程Ｓ４０３では、被推薦ユーザのユーザプロファイルと嗜好の類似するユーザを検索する。

工程Ｓ４０４では、工程Ｓ４０３で求めた嗜好の類似するユーザ集合から被推薦ユーザへの推薦コンテンツを協調フィルタリングと呼ばれる手法を用いて計算する。工程Ｓ４０５では、工程Ｓ４０２と工程Ｓ４０４で求めた推薦コンテンツを結合する。

工程Ｓ４０６では、推薦コンテンツのリストを出力する。ここで、工程Ｓ４０２は、コンテンツベースの推薦であり、工程Ｓ４０３とＳ４０４は、協調フィルタリングベースの推薦を行っている。工程Ｓ４０５において２つの推薦結果を結合することで両者の長所を取り入れたハイブリッド型推薦を実現している。

＜処理手順の例＞
図５は、図３のインデキシング処理の具体例を示す図である。インデックスＤＢ２６では、ＬＳＨというデータ構造が利用される。ＬＳＨは、ハッシュとよく似たデータ構造である。一般的なハッシュは同一のコンテンツが同一のビン（符号５１で示されるＬＳＨの各マスのこと。例では４つのビンから成る。）に格納されるのに対し、ＬＳＨは類似したコンテンツほど同一のビンに格納される確率が高くなるという特徴がある。

本発明では、コンテンツとユーザは予めインデキシングし、ＬＳＨに格納する。まず、コンテンツＤＢ２２内の全てのコンテンツをコンテンツインデクサ２５１によってＬＳＨにインデキシングする（工程Ｓ３０１）。この例では、コンテンツはＩ１、Ｉ２、Ｉ３、Ｉ４、Ｉ５、Ｉ６の６種類あるとし、コンテンツＩＤで識別される。各コンテンツは特徴ベクトルと呼ばれるベクトル表現に変換される。特徴ベクトルで表現されたコンテンツは後ほど説明する手法に基づいてＬＳＨに格納される。ＬＳＨへの格納方法はコンテンツの種類によって異なるため後ほど詳しく説明する。符号５１で示されるＬＳＨの上段はコンテンツをインデキシングした結果である。符号５３や符号５４で示されるデータのようにＬＳＨの同じビンに入ったコンテンツは類似したコンテンツであると見なせる。例えば、コンテンツＩ２とＩ３は類似し、コンテンツＩ４とＩ５は類似している。

次に、ユーザプロファイルＤＢ２４内の全てのユーザをユーザインデクサ２５２によってＬＳＨにインデキシングする（工程Ｓ３０２）。この例では、２人分のユーザプロファイルをインデキシングしている。各ユーザプロファイルの表現方法は、ユーザが好きなコンテンツの集合で表す方法と好きなコンテンツの集合をコンテンツと同じ特徴ベクトルで表現する方法があるが、本実施形態では前者を用いている。好きかどうかの判定は、そのコンテンツを選択・視聴・購入・高いレイティングをしたかで判断すればよい。ユーザのインデキシングは、ユーザプロファイル中の全てのコンテンツをコンテンツと同じ方法でＬＳＨに格納することで行われる。この際、ＬＳＨへはコンテンツＩＤ（例ではＩ１、Ｉ２など）ではなく、ユーザＩＤ（例ではＡ、Ｂなど）を格納するのがポイントである。符号５１で示されるＬＳＨの下段はユーザをインデキシングした結果を示している。符号５７で示される（Ａ，Ｂ）のように、ＬＳＨにおいて同じビンに入ったユーザは、あるコンテンツに対する嗜好が一致したユーザである。例えば、ユーザＡとユーザＢはどちらもコンテンツＩ５を好んでいる。

上記の手順で作成したＬＳＨはインデックスＤＢ２６に格納される。本発明のポイントは、コンテンツとユーザの両方を同じＬＳＨに格納している点である。ユーザプロファイルは、コンテンツの集合で表すためコンテンツと同じＬＳＨに格納可能である。

図６は、図４のコンテンツ推薦処理の具体例を示す図である。図５で作成したＬＳＨを用いて、被推薦ユーザＣに対してコンテンツを推薦することを考える。

まず、被推薦ユーザＣのユーザプロファイルが入力される（工程Ｓ４０１）。ここでは、被推薦ユーザＣのユーザプロファイル６２は、（Ｉ２、Ｉ５）である。つまり、ユーザＣはコンテンツＩ２とＩ５を好んでいる。

次に、ユーザプロファイル中の全てのコンテンツをハッシングし、ハッシュ先のコンテンツＩＤを取り出す（工程Ｓ４０２）。例では、Ｉ２のハッシュ先にある（Ｉ２、Ｉ３）、Ｉ５のハッシュ先にある（Ｉ４、Ｉ５）である。被推薦ユーザがすでに知っているＩ２とＩ５を除くと、（Ｉ３、Ｉ４）が得られる。先ほどＬＳＨの性質を述べたようにＬＳＨはコンテンツが類似しているほど同じビンに入りやすい。つまり、ユーザＣの好きなコンテンツＩ２とＩ５に類似したコンテンツＩ３とＩ４が得られたことになる。これらのコンテンツはユーザＣが好きである可能性が高いため推薦される。この処理は、コンテンツ間の類似度に基づいているためコンテンツベース型の推薦と見なせる。

同様に、ハッシュ先のユーザＩＤを取り出す（工程Ｓ４０３）。例では、Ｉ２のハッシュ先にあるＡ、Ｉ５のハッシュ先にある（Ａ、Ｂ）である。重複を省くと（Ａ、Ｂ）が得られる。このユーザＡとユーザＢは、被推薦ユーザＣと好きなコンテンツが一部共通しているユーザである。つまり、被推薦ユーザＣと嗜好が似ているユーザの候補だと考えられる。

次に、嗜好が似ているユーザの候補を用いて協調フィルタリングを実行する（工程Ｓ４０４）。協調フィルタリングは、嗜好が似ているユーザからコンテンツ推薦を受ける手法の総称であり、さまざまな方法が提案されている。この例では、もっとも簡単な方法であるが、嗜好が似ているユーザが好んでいるコンテンツの中で被推薦ユーザが知らないコンテンツを推薦することにする。ユーザプロファイルＤＢ２４からユーザＡの好きなコンテンツは（Ｉ１、Ｉ２、Ｉ５）であり、ユーザＢの好きなコンテンツは（Ｉ４、Ｉ５、Ｉ６）であることがわかる。ここからユーザＣが好きなコンテンツＩ２とＩ５を除くと（Ｉ１、Ｉ４、Ｉ６）となり、これらのコンテンツが推薦される。これらのコンテンツは、被推薦ユーザＣと嗜好が類似したユーザに基づいているため協調フィルタリング型の推薦と見なせる。

上記の説明で、ユーザプロファイル中の全てのコンテンツをハッシングし、ハッシュ先のコンテンツＩＤとユーザＩＤを同時に求められるのがポイントである。つまり、被推薦ユーザＣの好きなコンテンツと似ているコンテンツ、被推薦ユーザＣと嗜好が類似するユーザの両方を同時に求めることができ、コンテンツベース型と協調フィルタリング型の推薦が同時に実行できる。しかも、ＬＳＨを用いているため高速に類似コンテンツ、類似ユーザが発見でき、コンテンツ数、ユーザ数の増加に対してスケーラブルである。

最後に、コンテンツベース型推薦コンテンツ（Ｉ３、Ｉ４）と協調フィルタリング型推薦コンテンツ（Ｉ１、Ｉ４、Ｉ６）が結合される（工程Ｓ４０５）。結合にはいくつかの方法が考えられる。例えば、両方のＯＲ条件を取って（Ｉ１、Ｉ３、Ｉ４、Ｉ６）、ＡＮＤ条件を取って（Ｉ４）などの結合方法が挙げられる。またコンテンツベース型と協調フィルタリング型のどちらに重点を置くかも調整可能である。例えば、推薦システムの稼動初期は他のユーザの履歴が少ないためコンテンツベース型を重視する、他のユーザの履歴がたまってきたら協調フィルタリング型を重視することもできる。結合によって得られた推薦コンテンツは、推薦リストとして出力され（工程Ｓ４０６）、Ｗｅｂサーバ１５を通してユーザに提示される。

＜番組推薦システム＞
以下では、コンテンツがテレビ番組である場合を想定して具体的なシステムの手順を説明する。図７は、番組推薦システムの全体構成を示すブロック図である。図１のブロック図と大部分は同じであるが、テレビ番組の場合には、コンテンツ推薦サーバ１１が番組推薦サーバ７１、コンテンツサーバ１４が放送局７２になり、ユーザ端末１７がテレビ番組を視聴できる機器、例えばテレビ７４、ハードディスクレコーダ７６、パーソナルコンピュータ７７、携帯電話７９等になる。

番組推薦サーバ７１は、予め放送局７２から番組メタデータである電子番組表（ＥＰＧ：Electronic Programming Guide）を定期的にダウンロードしてハードディスクドライブ７１３の番組ＤＢに格納しておく。デジタル放送の場合、ＥＰＧは番組コンテンツとともに電波を通して配信されている。

番組推薦サーバ７１は、番組メタデータであるＥＰＧだけ持てばよく、テレビ番組本体のデータ（映像など）は放送局７２がユーザ端末１７へ配信する。番組推薦サーバ７１が推薦リストとして提供するのは番組メタデータである。

図８は、番組メタデータの具体例を示す図である。番組メタデータは、番組毎に放送日、放送開始時間、放送局、ジャンル、タイトル、出演者、番組内容などの情報が付与されたデータである。図８では、タイトル、ジャンル、番組内容が具体例として挙げられている（形態素は後で説明する）。各番組にはユニークな番組ＩＤが付与されており、他の番組と区別できるものとする。これまではコンテンツの種類を限定せず、コンテンツとして抽象化した状態で各モジュールの処理を述べてきた。しかし、インデキシング処理は、対象となるコンテンツの性質によって処理の手順が異なる。

以下、図８に示したようにコンテンツがテキストメタデータで表される場合を例にインデキシングの詳細な手順を説明する。図９は、コンテンツが番組メタデータのようなテキストである場合のコンテンツインデキシング（工程Ｓ３０１）の詳細なフローチャートである。

工程Ｓ９０１では、番組内容を単語の集合に分解する形態素解析を行う。図８の例では、番組内容を形態素解析して単語に分解し、名詞のみを抽出して形態素の列に追加している。これらの形態素は、番組内容を表す特徴ベクトルの要素とし、番組間の類似性判定に用いる。例えば、二つの番組間で共通する単語を含むほど類似していると判断される。ここでは、番組内容のみを形態素解析した例を示したが、タイトル、ジャンル、出演者など番組メタデータの他の情報も形態素解析の対象としてもよい。

工程Ｓ９０２では、番組内容から抽出した形態素から索引語を選択する。索引語とは番組内容をよく特徴付ける単語のことで形態素の中から選ばれる。形態素から索引語を選ぶ処理はＴＦ−ＩＤＦ法などが一般的に知られている。尚、番組内容のように比較的短い文書の場合、ＴＦ−ＩＤＦ法は適切に働かないことも多いので、本実施形態では全ての形態素を索引語として選択する。

工程Ｓ９０３では、索引語・文書行列を生成する。ここでは、番組が文書に当たる。図１０は、索引語・文書行列、乱数列、シグネチャ行列の具体例を示す図である。同図における行列１００１は、図８の番組メタデータから生成した索引語・文書行列の例である。索引語・文書行列は、各行に索引語、各列に番組を割り当てた行列で、行列の値は番組が索引語を含む場合は１、含まない場合は０を取る。例えば、行列１００１のＰ１の列は、番組Ｐ１が世界・遺産・背景・歴史・紹介という索引語を含むことを意味している。この索引語・文書行列は、各番組の特徴ベクトルを表現している。例えば、番組Ｐ１の特徴ベクトルは、Ｐ１の列を縦に見た（１，１，１，１，１，０，０，…，０）という１６次元ベクトルである。各番組の特徴ベクトルの次元（長さ）は、索引語の数と同じである。また今回は、索引語を含むか否かで０または１の値を用いたが、先ほど述べたＴＦ−ＩＤＦ法のスコアを用いる場合もある。

工程Ｓ９０４では、索引語・文書行列１００１からシグネチャ１００３を生成する。シグネチャとは、番組の特徴ベクトルの次元を縮約した要約表現である。シグネチャも特徴ベクトルと同じくベクトルで表現される。１００３がシグネチャ行列の例である。元の索引語・文書行列１００１では、各番組の特徴ベクトルは１６次元ベクトルだったが、シグネチャ行列１００３では、各番組のシグネチャは４次元ベクトルに圧縮されている。このような特徴ベクトルを次元縮約してシグネチャに変換する手法は、さまざまな方法が提案されているが、ここではMin-Hashingと呼ばれる手法を利用する（非特許文献１）。Min-Hashingは、索引語・文書行列のようなスパース（要素の大部分が０）な行列に適した次元縮約法である。Min-Hashingを使って次元縮約するためには、乱数列１００２が複数必要になる。乱数列は、１から索引語数までの数がランダムに並んだ数列である。この例では、ｈ１〜ｈ４の４つの乱数列を用意している。

Min-Hashingは、各番組の特徴ベクトルに各乱数列を適用してシグネチャを求める。例えば、番組Ｐ１に乱数列ｈ１を適用することを考える。まず、Ｐ１のベクトル中で値が１の場所に対応する乱数列をｈ１から抽出すると１３、２、７、１４、１０が得られる。

そして、この中から最小の数を選び、シグネチャ行列１００３のＰ１とｈ１の交わる場所に書き込む。この場合は２である。

別の例として、番組Ｐ２に乱数列ｈ２を適用することを考える。まず、Ｐ２のベクトル中で値が１の場所に対応する乱数列をｈ２から抽出すると、１４、３、６、１１、８が得られる。そして、この中から最小の数を選び、シグネチャ行列１００３のＰ２とｈ２の交わる場所に書き込む。この場合は３である。
上記の手順を番組と乱数列の全ての組合せについて求めるとシグネチャ行列１００３が得られる。

今回の例では、特徴ベクトルの次元数（索引語数）は１６、シグネチャの次元数は４と小さいが、実際は大量の番組を対象とすると特徴ベクトルの次元数は数万から数十万に及ぶ場合もある。この場合、シグネチャの次元数は１００程度で十分なことが知られている。つまり、乱数列はｈ１〜ｈ１００の１００個用意してMin-Hashingを適用すればよい。

また、実際には、特徴ベクトルの次元数が大きくなると非常に長い乱数列が必要になるが、その場合は、乱数列を使う代わりに最小完全ハッシュ関数を使うこともできる。また、特徴ベクトルの次元数が大きくなった場合でもシグネチャ行列をより高速に求めるアルゴリズムが知られている。

工程Ｓ９０５では、番組をＬＳＨへインデキシングする。図１１は、番組をＬＳＨへインデキシングする処理の具体例を示す図である。まず、シグネチャを、いくつかのバンドに分割する。例では、バンド１１０１とバンド１１０２という２つのバンドに分割した。次に。各バンドにハッシュを用意し、分割されたシグネチャをキーとして各番組ＩＤをハッシュに格納する。例では、バンド１１０１のハッシュは符号１１０３、バンド１１０２のハッシュは符号１１０４で示されている。バンド１１０１の番組Ｐ１とＰ２は同じシグネチャ（２，３）なのでハッシュ１１０３の同じビンに格納される。ハッシュは、キーが同じ場合、同じビンに格納される。バンド１１０２の番組Ｐ３とＰ４も同じシグネチャ（１，３）なのでハッシュ１１０４の同じビンに格納される。同じビンにハッシュされた番組同士は類似している確率が高い番組である。例えば、番組Ｐ１（世界遺産と歴史）、番組Ｐ２（世界遺産の旅）は、ともに世界遺産の番組で内容が似ている番組である。また、番組Ｐ３（温泉めぐり）と番組Ｐ４（世界の珍味）は、ともに旅グルメの番組で内容が似ている番組である。番組メタデータのようなテキストの場合は、番組内容に共通する索引語が多く含まれるほど似ていると判断される。Ｐ５やＰ６は、番組内容に共通するキーワードが含まれていないためどの番組とも似ていないと判断され、別のビンに格納されている。つまり、ＬＳＨにインデキシングすることで内容が似ている番組を同じビンに集めることができる。また、符号１１０５で示されるハッシュの集合がＬＳＨと呼ばれる。図５では、簡単のためコンテンツをインデキシングするＬＳＨはあたかも１つのハッシュであるように模式的に描いたが、実際は、図１１のハッシュ集合１１０５がＬＳＨである。

図１２は、ユーザプロファイルの具体例を示す図である。ユーザプロファイルは、各ユーザがどの番組を視聴・録画したかを表している。例えば、ユーザＡは番組Ｐ１、Ｐ２、Ｐ５を視聴、ユーザＢは番組Ｐ３、Ｐ４、Ｐ６を視聴している。ユーザＡは世界遺産などの歴史の番組が好きなユーザ、ユーザＢはグルメや旅の番組が好きなユーザを想定している。このような視聴・録画履歴は、図７のユーザ端末、例えば、テレビ７４、ハードディスクレコーダ７６、パーソナルコンピュータ７７、携帯電話７９などの操作履歴から収集できる。ユーザ端末から収集した操作履歴はＷｅｂサーバ７３を通って番組推薦サーバのハードディスクドライブ７１３に格納され、図１２のようなユーザプロファイルが蓄積される。操作履歴は、ユーザの視聴・録画操作以外にもコンテンツへのレイティングなど別の方法を用いて収集してもよい。

図１３は、コンテンツが番組メタデータのようなテキストである場合のユーザインデキシング（工程Ｓ３０２）の詳細なフローチャートである。

工程Ｓ１３０１では、インデキシングが未処理のユーザの有無を判定する。ここで、未処理のユーザが存在すると判定された場合には、工程Ｓ１３０２へ進む。これに対し、全てのユーザの処理が完了したと判定された場合は、処理を終了する。

工程Ｓ１３０２では、ユーザプロファイル中にインデキシングが未処理のコンテンツがあるか否かを判定する。ここで、未処理のコンテンツが有ると判定された場合には、工程Ｓ１３０３へ進む。これに対して、全てのコンテンツについて処理が完了したと判定された場合には、Ｓ１３０１へ戻る。全てのコンテンツに対する処理が完了するまで工程Ｓ１３０３と工程Ｓ１３０４は繰り返される。

工程Ｓ１３０３では、対象コンテンツのシグネチャを取得する。そして、工程Ｓ１３０４で取得したコンテンツを図１１で表されるＬＳＨに同じ方法で格納する。このとき、図１１とは異なり、ＬＳＨにはユーザＩＤを格納するのがポイントである。

図１４は、ユーザをＬＳＨへインデキシングする処理例を示す図である。同図において、例えば、ユーザＡをインデキシングする場合を考える。ユーザＡのプロファイル中の番組は、Ｐ１、Ｐ２、Ｐ５であるため、この３つの番組を各バンドごとにＬＳＨ１４０３へハッシュする。このとき、Ｐ１、Ｐ２、Ｐ５のハッシュ先のビンへは、ユーザＩＤであるＡを格納する。ここでは、ユーザＣをインデキシングしていないが、これはあとで説明用に使うためであり、実際は全てのユーザをインデキシングしておく。

ユーザインデキシングには、上記のようにユーザが視聴した各コンテンツをハッシュするほかにも様々な方法が考えられる。例えば、嗜好ベクトルを用いてインデキシングを行う方法がある。図１５は、ユーザの好きなコンテンツ集合を嗜好ベクトルで表し、嗜好ベクトルをＬＳＨへ格納する処理の具体例を示すフローチャートである。

工程Ｓ１５０１では、インデキシングが未処理のユーザの有無を判定する。ここで、未処理のユーザが存在すると判定された場合には、工程Ｓ１５０２へ進む。これに対し、全てのユーザの処理が完了したと判定された場合は、処理を終了する。

工程Ｓ１５０２では、対象ユーザの好きなコンテンツの特徴ベクトルの集合からただ１つの嗜好ベクトルを作成する。工程Ｓ１５０３では、嗜好ベクトルをコンテンツインデキシングと同じ方法を用いてシグネチャへ変換する。工程Ｓ１５０４では、シグネチャをコンテンツインデキシングと同じ方法を用いてＬＳＨへハッシングし、ユーザＩＤを格納する。工程Ｓ１５０１からＳ１５０４の処理は、上記の処理を全てのユーザについて終えるまで繰り返される。

嗜好ベクトルを用いる方法では、図１４のように１人のユーザが複数のビンへ格納されることはなく、１人のユーザはただ１つのビンへ格納される。その結果、ユーザインデキシング処理が高速化され、ハッシュ表もハッシュ値の衝突が起こりにくくなるため高速化されるという利点がある。ただし、嗜好ベクトルの作成方法はコンテンツの種類に大きく依存し、コンテンツがマルチメディアデータの場合は作成が難しいことがある。

図１６は、嗜好ベクトルを用いたユーザインデキシングの具体例を示す図である。ここでは、例としてユーザＡの嗜好ベクトルを作成することを考える。ユーザＡの嗜好ベクトルは、ユーザＡが視聴した番組の特徴ベクトルの集合１６０１から作成される。ここでは、特徴ベクトルから嗜好ベクトルを求める方法の具体例が３例挙げられている。嗜好ベクトル１６０２は、ユーザＡが視聴した番組に含まれる単語を１、含まれない単語を０にしたベクトルである。嗜好ベクトル１６０３は、ユーザＡが視聴した番組に含まれる単語をカウントしたベクトルである。嗜好ベクトル１６０４は、１６０３のカウントに対し、頻度が２以上の単語を１、２未満の単語を０としたベクトルである。

嗜好ベクトルの作成方法は、嗜好モデリングと呼ばれ、上記以外にもさまざまな手法が提案されている。本実施形態では、２値ベクトルでなければシグネチャに変換できないため１６０２や１６０４のような嗜好ベクトルしか使えない。各ユーザの嗜好ベクトルが生成できたらコンテンツと同じ方法で嗜好ベクトルをシグネチャに変換してＬＳＨへユーザＩＤを格納すればよい。

図１７は、大規模なコンテンツ集合、ユーザ集合をインデキシングする場合の模式図である。先に説明したように大規模なシステムでは、シグネチャ行列１７０１は１００次元のシグネチャを持つ。そのため、バンド幅を５次元とした場合、２０個のバンドが作られ、対応するハッシュの数も２０個と多くなる。バンド幅を調整することでコンテンツが類似と判断される確率を調整することができる。

以上、コンテンツが番組である場合のコンテンツとユーザのインデキシング処理について説明した。

以下、番組の推薦処理を上述した図４のフローチャートに従って説明する。こちらは、どのようなコンテンツでも手順は先に解説した方法と同じである。例えば、図１２のユーザＣに対して番組を推薦する場合を考える。この場合、ユーザＣは、番組Ｐ１（世界遺産と歴史）、番組Ｐ３（温泉巡り）という２つの番組を好んでいることがユーザプロファイル入力部２７１を通して番組推薦サーバ７１に入力される（工程Ｓ４０１）。

次に、コンテンツ推薦部２７では、類似コンテンツの検索（工程Ｓ４０２）と類似ユーザの検索（工程Ｓ４０３）を行う。類似コンテンツと類似ユーザは、図１４のＬＳＨから求める。ＬＳＨを構成する全てのハッシュに対してＰ１とＰ３をハッシングし、ハッシュ先のビンに格納されている番組とユーザを抽出する。

ここでは、類似コンテンツとして、Ｐ１、Ｐ２、Ｐ３、Ｐ４が得られる。そして、ユーザＣが既に知っているＰ１とＰ３が除外され、ユーザＣの好きなコンテンツに内容が似ているコンテンツとしてＰ２とＰ４が推薦される。これは、コンテンツベース型の推薦である。

また、ユーザＣと嗜好が似ているユーザとして、Ａ、Ｂが得られる。ユーザＡとユーザＢのユーザプロファイルをユーザプロファイルＤＢ２４から検索して、Ｐ１、Ｐ２、Ｐ５、Ｐ３、Ｐ４、Ｐ６が得られる。そして、ユーザＣが既に知っているＰ１とＰ３が除外され、Ｐ２、Ｐ５、Ｐ４、Ｐ６が推薦される（工程Ｓ４０４）。これは、ユーザＣと嗜好が似ているユーザのプロファイルを用いているので協調フィルタリング型の推薦である。協調フィルタリング型の推薦では、Ｐ５（歴史アニメ）やＰ６（今日のお料理）のように内容による判断では類似していない番組でも他のユーザが興味を持った関係のある番組として推薦できるのがポイントである。

最後に、コンテンツベース型と協調フィルタリング型の推薦番組を結合する（工程Ｓ４０５）。結合方法にはいくつか方法が考えられる。例えば、両方の推薦番組のＯＲ条件（論理和）を取って、Ｐ２、Ｐ４、Ｐ５、Ｐ６を推薦する。または、両方の推薦番組のＡＮＤ条件（論理積）を取って、Ｐ２、Ｐ４を推薦する。図１８は、ユーザへ提示される推薦リストの具体例を示す図である。同図に示されるように、“みんなからのおすすめ度合い”というスクロールバー１８０２を用意し、両者のコンテンツをどの程度リストに追加するかユーザ自ら選択できるようにしてもよい。一般に、協調フィルタリング型の番組の割合を多くすると被推薦ユーザにとって意外な番組が多く推薦される傾向にあることが知られている。また、先に説明したように推薦の開始時はコンテンツベース型を重視し、ユーザ数の増加にしたがって協調フィルタリング型を重視するという方法を用いてもよい。このようにして結合された推薦リストは、番組推薦サーバ７１からテレビ７４などのユーザ端末１７へ送信され、図１８のおすすめ番組リスト１８０１のような形でユーザに提示される。

尚、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。更に、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。

例えば、上記実施形態では、コンテンツがテレビ番組のようなテキストデータで表される場合の処理手順について説明したが、テレビ番組以外の書籍、Ｗｅｂサイト、ニュース記事、ブログなどテキストで表されるデータなら上記の処理手順で同様の推薦システムが構築できる。また特徴ベクトルで表現された音楽、画像、動画などのコンテンツの場合は、先に挙げた（非特許文献２）や（非特許文献３）の方法でコンテンツをＬＳＨにインデキシングすることも可能である。本発明のユーザインデキシングと推薦手法を適用すれば同様の推薦システムが構築できる。

本発明の一実施形態に係るコンテンツ推薦システムの全体構成を示すブロック図。 コンテンツ推薦サーバのモジュール関係図。 インデキシング部の処理の具体例を示すフローチャート。 コンテンツ推薦部の処理の具体例を示すフローチャート。 インデキシングの処理例を示す図。 コンテンツ推薦の処理例を示す図。 番組推薦システムの全体構成を示すブロック図。 番組メタデータの具体例を示す図。 コンテンツがテキストの場合のコンテンツインデクサの処理の具体例を示すフローチャート。 索引語・文書行列、乱数列、シグネチャ行列の例を示す図。 番組をＬＳＨへインデキシングする処理の具体例を示す図。 ユーザプロファイルの具体例を示す図。 ユーザインデクサの処理の具体例を示すフローチャート。 ユーザをＬＳＨへインデキシングする処理例を示す図。 嗜好ベクトルを作成するユーザインデクサの処理の具体例を示すフローチャート。 嗜好ベクトルを用いたユーザインデキシングの具体例を示す図。 大規模なコンテンツ集合、ユーザ集合をインデキシングする場合の模式図。 ユーザへ提示される推薦リストの具体例を示す図。

符号の説明

１１…コンテンツ推薦サーバ、
１２…ディスプレイ、
１３…入力デバイス、
１４…コンテンツサーバ、
１５…Ｗｅｂサーバ、
１６…ネットワーク、
１７…ユーザ端末、
１８…ディスプレイ、
１９…入力デバイス、
１１１…ＣＰＵ、
１１２…ＲＡＭ、
１１３…ハードディスクドライブ、
１１４…ネットワーク機器、
１１５…入出力機器、
２１…コンテンツ情報収集部、
２２…コンテンツＤＢ、
２３…ユーザプロファイル収集部、
２４…ユーザプロファイルＤＢ、
２５…インデキシング部、
２６…インデックスＤＢ、
２７…コンテンツ推薦部、
２５１…コンテンツインデクサ、
２５２…ユーザインデクサ、
２７１…ユーザプロファイル入力部、
２７２…類似ユーザ検索部、
２７３…推薦コンテンツ決定部、
２７４…類似コンテンツ検索部、
２７５…推薦コンテンツ結合部、
２７６…推薦リスト出力部。

Claims (10)

1. ネットワークを介して接続されたコンテンツサーバからコンテンツのメタデータを含むコンテンツ情報を収集するコンテンツ情報収集部と、
   前記収集されたコンテンツ情報を格納するコンテンツＤＢと、
   前記ネットワークを介して接続されたユーザ端末からユーザの前記コンテンツに対する嗜好情報をユーザプロファイルとして収集するユーザプロファイル収集部と、
   前記収集されたユーザプロファイルを格納するユーザプロファイルＤＢと、
   前記コンテンツＤＢからコンテンツのメタデータを取得し、このメタデータから前記コンテンツに係るインデックスを作成するコンテンツインデクサと、
   前記ユーザプロファイルＤＢからユーザプロファイルを取得し、このユーザプロファイルに含まれるコンテンツをキーとして前記ユーザに係るインデックスを作成するユーザインデクサと、
   前記作成された前記コンテンツおよび前記ユーザに係るインデックスを格納するインデックスＤＢと、
   前記ユーザプロファイルＤＢから取得される被推薦ユーザに係る前記ユーザプロファイルに基づいて前記インデックスＤＢを参照し、前記被推薦ユーザの嗜好に適合したコンテンツを推薦するコンテンツ推薦部と、
   を有することを特徴とするハイブリッド型コンテンツ推薦サーバ。
2. 前記コンテンツインデクサは、前記コンテンツＤＢからコンテンツのメタデータを取得し、このメタデータからＬＳＨに基づいて前記コンテンツに係るインデックスを作成し、かつ、
   前記ユーザインデクサは、前記ユーザプロファイルＤＢからユーザプロファイルを取得し、このユーザプロファイルに含まれるコンテンツをキーとし、前記ＬＳＨに基づいて前記ユーザに係るインデックスを作成することを特徴とする請求項１記載のハイブリッド型コンテンツ推薦サーバ。
3. 前記コンテンツ推薦部は、
   被推薦ユーザのユーザプロファイルを入力するユーザプロファイル入力部と、
   前記入力された被推薦ユーザのユーザプロファイルに基づいて前記インデックスＤＢに格納された前記ユーザに係るインデックスを参照し、前記被推薦ユーザと前記コンテンツの嗜好が類似する類似ユーザを検索する類似ユーザ検索部と、
   前記被推薦ユーザのユーザプロファイルに基づいて前記インデックスＤＢに格納された前記コンテンツに係るインデックスを参照し、前記被推薦ユーザの嗜好するコンテンツに類似する類似コンテンツを検索する類似コンテンツ検索部と、
   前記類似ユーザ検索部において検索された類似ユーザから協調フィルタリングによって推薦コンテンツを決定する推薦コンテンツ決定部と、
   前記類似コンテンツおよび前記類似コンテンツを所定の規則に基づいて結合して前記コンテンツの推薦リストを作成する推薦コンテンツ結合部と、
   を有することを特徴とする請求項１または請求項２記載のハイブリッド型コンテンツ推薦サーバ。
4. 前記コンテンツインデクサは、前記コンテンツ情報の形態素解析によって求められた形態素の中から前記コンテンツの索引語を選択して特徴ベクトルを作成し、この特徴ベクトルの次元縮約によって求められるシグネチャを所定のバンド幅で分割し、この分割により求められたバンド毎に前記コンテンツに係るインデックスを作成することを特徴とする請求項１または請求項２記載のハイブリッド型コンテンツ推薦サーバ。
5. 前記ユーザインデクサは、前記メタデータおよび前記ユーザプロファイルに基づいて前記ユーザが嗜好するコンテンツ集合を表す嗜好ベクトルを作成し、この嗜好ベクトルの次元縮約によって求められるシグネチャを所定のバンド幅で分割し、この分割により求められたバンド毎に前記ユーザに係るインデックスを作成することを特徴とする請求項１または請求項２記載のハイブリッド型コンテンツ推薦サーバ。
6. 推薦コンテンツ結合部は、前記ユーザ端末において指定された割合に応じて前記類似コンテンツおよび前記推薦コンテンツに対する推薦優先度を変更して結合を行い、前記コンテンツの推薦リストを作成することを特徴とする請求項３記載のハイブリッド型コンテンツ推薦サーバ。
7. コンテンツのメタデータを提供するコンテンツサーバと、
   このコンテンツサーバにネットワークを介して接続され、前記コンテンツのメタデータおよびユーザプロファイルを管理し、前記コンテンツの推薦リストを出力するコンテンツ推薦サーバと、
   このコンテンツ推薦サーバに前記ネットワークを介して接続され、前記コンテンツ推薦サーバから前記推薦リストを取得するユーザ端末と、
   からなり、
   前記コンテンツ推薦サーバは、
   前記コンテンツサーバからコンテンツのメタデータを含むコンテンツ情報を収集するコンテンツ情報収集部と、
   前記収集されたコンテンツ情報を格納するコンテンツＤＢと、
   前記ユーザ端末からユーザの前記コンテンツに対する嗜好情報をユーザプロファイルとして収集するユーザプロファイル収集部と、
   前記収集されたユーザプロファイルを格納するユーザプロファイルＤＢと、
   前記コンテンツＤＢからコンテンツのメタデータを取得し、このメタデータから前記コンテンツに係るインデックスを作成するコンテンツインデクサと、
   前記ユーザプロファイルＤＢからユーザプロファイルを取得し、このユーザプロファイルに含まれるコンテンツをキーとして前記ユーザに係るインデックスを作成するユーザインデクサと、
   前記作成された前記コンテンツおよび前記ユーザに係るインデックスを格納するインデックスＤＢと、
   前記ユーザプロファイルＤＢから取得される被推薦ユーザに係る前記ユーザプロファイルに基づいて前記インデックスＤＢを参照し、前記被推薦ユーザの嗜好に適合したコンテンツを推薦するコンテンツ推薦部と、
   を有することを特徴とするハイブリッド型コンテンツ推薦システム。
8. 前記コンテンツインデクサは、前記コンテンツＤＢからコンテンツのメタデータを取得し、このメタデータからＬＳＨに基づいて前記コンテンツに係るインデックスを作成し、かつ、
   前記ユーザインデクサは、前記ユーザプロファイルＤＢからユーザプロファイルを取得し、このユーザプロファイルに含まれるコンテンツをキーとし、前記ＬＳＨに基づいて前記ユーザに係るインデックスを作成することを特徴とする請求項７記載のハイブリッド型コンテンツ推薦システム。
9. ネットワークを介して接続されたコンテンツサーバからコンテンツのメタデータを含むコンテンツ情報を収集するコンテンツ情報収集ステップと、
   前記ネットワークを介して接続されたユーザ端末からユーザの前記コンテンツに対する嗜好情報をユーザプロファイルとして収集するユーザプロファイル収集ステップと、
   前記収集されたコンテンツのメタデータから前記コンテンツに係るインデックスを作成するコンテンツインデックス作成ステップと、
   前記収集されたユーザプロファイルに含まれるコンテンツをキーとして前記ユーザに係るインデックスを作成するユーザインデックス作成ステップと、
   被推薦ユーザに係る前記ユーザプロファイルに基づいて前記コンテンツおよび前記ユーザに係るインデックスを参照し、前記被推薦ユーザの嗜好に適合したコンテンツを推薦するコンテンツ推薦ステップと、
   を有することを特徴とするハイブリッド型コンテンツ推薦方法。
10. 前記コンテンツインデックス作成ステップにおいて、前記コンテンツのメタデータを取得し、このメタデータからＬＳＨに基づいて前記コンテンツに係るインデックスを作成し、かつ、
    前記ユーザインデックス作成ステップにおいて、前記ユーザプロファイルを取得し、このユーザプロファイルに含まれるコンテンツをキーとし、前記ＬＳＨに基づいて前記ユーザに係るインデックスを作成することを特徴とする請求項９記載のハイブリッド型コンテンツ推薦方法。

Images