(57)【要約】【課題】ユーザの嗜好を構成する個々の属性、要素などの重要性を、常に適切に反映させた推薦を行なうことができるようにする。【解決手段】属性重み調整エンジン１２９は、属性重み調整エンジン１２９は、属性重み調整DB１３２に記憶されているレコードであって、特定されたメンバーＩＤのレコードに基づいて当該ユーザの重みの調整を行う。ここで、重みの調整は、属性重み調整DB１３２のレコードから得られる目標類似度と属性重み調整DB１３２のレコードから得られる各アトリビュートの類似度を用いた重回帰分析によりなされ、得られた重みが、特定されたユーザの各アトリビュートの重みとして特定される。ユーザの各アトリビュートの重みを反映させるべく、属性重みＤＢ１３１が更新され、属性重み調整ＤＢ１３２の中の不要なレコードが削除される。【選択図】図８
2010061601.tif 000002
【特許請求の範囲】
【請求項１】
ユーザの嗜好を表す情報であって複数の要素を有するベクトルとして構成されるユーザ嗜好情報、および推薦の対象となるアイテムのそれぞれのメタ情報に基づいて生成され、それぞれ前記ユーザ嗜好情報の要素と同数の要素を有するベクトルとして構成されるアイテム嗜好情報の要素毎の類似度に重み係数をそれぞれ乗じた値、並びに前記アイテムに対する前記ユーザの操作の内容に応じて定まる評価値の目標値を対応付けた調整情報を生成して記憶する調整情報記憶手段と、
複数の前記調整情報を用いた重回帰分析により前記ユーザ嗜好情報の要素のそれぞれに乗じられる重み係数のそれぞれを、ユーザ毎に算出する重回帰分析手段と、
前記算出された重み係数を、前記評価値の算出において、前記ユーザ嗜好情報の要素のそれぞれに乗じられる重み係数として前記ユーザ毎に記憶する重み係数記憶手段と、
前記ユーザ嗜好情報および前記アイテム嗜好情報のそれぞれの要素、および前記要素に対応する前記重み係数に基づいて演算される前記評価値に基づいて、前記ユーザに推薦する前記アイテムを特定する推薦アイテム特定手段と
を備える推薦装置。
【請求項２】
予め設定された期間内に生成された前記調整情報が、前記重回帰分析の対象とされる
請求項１に記載の推薦装置。
【請求項３】
予め定められた周期で、
前記調整情報を生成して記憶し、
前記重み係数のそれぞれを、ユーザ毎に算出し、
前記算出された重み係数を、前記評価値の算出において、前記ユーザ嗜好情報の要素のそれぞれに乗じられる重み係数として前記ユーザ毎に記憶する
請求項２に記載の推薦装置。
【請求項４】
前記重回帰分析に用いられた前記調整情報を削除する調整情報削除手段をさらに備える
請求項１に記載の推薦装置。
【請求項５】
前記調整情報削除手段は、
前記調整情報のうち、生成日時の古い順に所定の割合の前記調整情報を削除する
請求項４に記載の推薦装置。
【請求項６】
前記調整情報には、前記ユーザの操作の内容に応じて定まる利用回数が含まれ、
前記調整情報削除手段は、
前記利用回数分だけ前記重回帰分析に用いられた前記調整情報を削除する
請求項４に記載の推薦装置。
【請求項７】
ユーザの嗜好を表す情報であって複数の要素を有するベクトルとして構成されるユーザ嗜好情報、および推薦の対象となるアイテムのそれぞれのメタ情報に基づいて生成され、それぞれ前記ユーザ嗜好情報の要素と同数の要素を有するベクトルとして構成されるアイテム嗜好情報の要素毎の類似度に重み係数をそれぞれ乗じた値、並びに前記アイテムに対する前記ユーザの操作の内容に応じて定まる評価値の目標値を対応付けた調整情報を生成して記憶し、
複数の前記調整情報を用いた重回帰分析により前記ユーザ嗜好情報の要素のそれぞれに乗じられる重み係数のそれぞれを、ユーザ毎に算出し、
前記算出された重み係数を、前記評価値の算出において、前記ユーザ嗜好情報の要素のそれぞれに乗じられる重み係数として前記ユーザ毎に記憶し、
前記ユーザ嗜好情報および前記アイテム嗜好情報のそれぞれの要素、および前記要素に対応する前記重み係数に基づいて演算される前記評価値に基づいて、前記ユーザに推薦する前記アイテムを特定する
推薦方法。
【請求項８】
コンピュータを、
ユーザの嗜好を表す情報であって複数の要素を有するベクトルとして構成されるユーザ嗜好情報、および推薦の対象となるアイテムのそれぞれのメタ情報に基づいて生成され、それぞれ前記ユーザ嗜好情報の要素と同数の要素を有するベクトルとして構成されるアイテム嗜好情報の要素毎の類似度に重み係数をそれぞれ乗じた値、並びに前記アイテムに対する前記ユーザの操作の内容に応じて定まる評価値の目標値を対応付けた調整情報を生成して記憶する調整情報記憶手段と、
複数の前記調整情報を用いた重回帰分析により前記ユーザ嗜好情報の要素のそれぞれに乗じられる重み係数のそれぞれを、ユーザ毎に算出する重回帰分析手段と、
前記算出された重み係数を、前記評価値の算出において、前記ユーザ嗜好情報の要素のそれぞれに乗じられる重み係数として前記ユーザ毎に記憶する重み係数記憶手段と、
前記ユーザ嗜好情報および前記アイテム嗜好情報のそれぞれの要素、および前記要素に対応する前記重み係数に基づいて演算される前記評価値に基づいて、前記ユーザに推薦する前記アイテムを特定する推薦アイテム特定手段とを備える推薦装置として機能させる
プログラム。
【請求項９】
請求項８に記載のプログラムが記録されている記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、推薦装置および方法、プログラム、並びに記録媒体に関し、特に、ユーザの嗜好を構成する個々の属性、要素などの重要性を、常に適切に反映させた推薦を行なうことができるようにする推薦装置および方法、プログラム、並びに記録媒体に関する。
【背景技術】
【０００２】
従来より、録画された番組などのコンテンツをユーザに推薦する技術が開発されている。コンテンツの推薦は、例えば、コンテンツのメタデータに含まれる属性のそれぞれを要素するベクトルと、そのベクトルと同じ要素数のベクトルとして構成されるユーザ嗜好情報とのマッチング処理などにより算出された類似度に基づいて行われる。
【０００３】
また、ＥＰＧデータの供給を受け、必要なメタデータが抽出され、メタデータに含まれている、タイトル、内容などが、形態素解析されて、単語に分解され、それぞれの項目がベクトル化されて番組ベクトルが生成されるようにすることもできる。この際、供給されたメタデータの番組のジャンルに基づいて、対応する効き目ベクトルが抽出され効き目ベクトルと生成されたベクトルとが関連付けされて、処理が終了されるようにする技術も提案されている（例えば、特許文献１参照）。
【０００４】
【特許文献１】特開平２００７−２００３３９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、従来、ユーザ嗜好情報と番組ベクトルとの類似度を算出する場合、効き目や重みなどは個人によらない共通の固定値が用いられている。しかし、実際にはユーザごとに重要視する属性は異なり、共通の固定値ではこの個人差を補えないため、共通の固定値である効き目や重みを用いて類似度を算出してアイテムを推薦しても、真にユーザの嗜好に合致したアイテムを推薦できないことがある。
【０００６】
また、例えば、予めユーザに自分が重要視する属性（アトリビュート）などを入力させ、その入力結果に応じて個人別に重みを調整する方式もが考えられる。この方式であれば、上述した個人差を補うことも可能である。
【０００７】
しかし、ユーザの嗜好は、極めて抽象的な概念であって本人であっても表現することは難しく、必ずしも自分が重要視する属性（アトリビュート）が簡単に見つかるとは限らない。
【０００８】
さらに、ユーザの嗜好は、時間とともに変化することもある。例えば、放送される番組やDVDのコンテンツなどを数多く視聴した結果、自分が最初に重要視すると考えていた属性よりも、さらに重要視すべき属性が見つかることもある。
【０００９】
本発明はこのような状況に鑑みてなされたものであり、ユーザの嗜好を構成する個々の属性、要素などの重要性を、常に適切に反映させた推薦を行なうことができるようにするものである。
【課題を解決するための手段】
【００１０】
本発明の一側面は、ユーザの嗜好を表す情報であって複数の要素を有するベクトルとして構成されるユーザ嗜好情報、および推薦の対象となるアイテムのそれぞれのメタ情報に基づいて生成され、それぞれ前記ユーザ嗜好情報の要素と同数の要素を有するベクトルとして構成されるアイテム嗜好情報の要素毎の類似度に重み係数をそれぞれ乗じた値、並びに前記アイテムに対する前記ユーザの操作の内容に応じて定まる評価値の目標値を対応付けた調整情報を生成して記憶する調整情報記憶手段と、複数の前記調整情報を用いた重回帰分析により前記ユーザ嗜好情報の要素のそれぞれに乗じられる重み係数のそれぞれを、ユーザ毎に算出する重回帰分析手段と、前記算出された重み係数を、前記評価値の算出において、前記ユーザ嗜好情報の要素のそれぞれに乗じられる重み係数として前記ユーザ毎に記憶する重み係数記憶手段と、前記ユーザ嗜好情報および前記アイテム嗜好情報のそれぞれの要素、および前記要素に対応する前記重み係数に基づいて演算される前記評価値に基づいて、前記ユーザに推薦する前記アイテムを特定する推薦アイテム特定手段とを備える推薦装置である。
【００１１】
予め設定された期間内に生成された前記調整情報が、前記重回帰分析の対象とされるようにすることができる。
【００１２】
予め定められた周期で、前記調整情報を生成して記憶し、前記重み係数のそれぞれを、ユーザ毎に算出し、前記算出された重み係数を、前記評価値の算出において、前記ユーザ嗜好情報の要素のそれぞれに乗じられる重み係数として前記ユーザ毎に記憶するようにすることができる。
【００１３】
前記重回帰分析に用いられた前記調整情報を削除する調整情報削除手段をさらに備えるようにすることができる。
【００１４】
前記調整情報削除手段は、前記調整情報のうち、生成日時の古い順に所定の割合の前記調整情報を削除するようにすることができる。
【００１５】
前記調整情報には、前記ユーザの操作の内容に応じて定まる利用回数が含まれ、前記調整情報削除手段は、前記利用回数分だけ前記重回帰分析に用いられた前記調整情報を削除するようにすることができる。
【００１６】
本発明の一側面は、ユーザの嗜好を表す情報であって複数の要素を有するベクトルとして構成されるユーザ嗜好情報、および推薦の対象となるアイテムのそれぞれのメタ情報に基づいて生成され、それぞれ前記ユーザ嗜好情報の要素と同数の要素を有するベクトルとして構成されるアイテム嗜好情報の要素毎の類似度に重み係数をそれぞれ乗じた値、並びに前記アイテムに対する前記ユーザの操作の内容に応じて定まる評価値の目標値を対応付けた調整情報を生成して記憶し、複数の前記調整情報を用いた重回帰分析により前記ユーザ嗜好情報の要素のそれぞれに乗じられる重み係数のそれぞれを、ユーザ毎に算出し、前記算出された重み係数を、前記評価値の算出において、前記ユーザ嗜好情報の要素のそれぞれに乗じられる重み係数として前記ユーザ毎に記憶し、前記ユーザ嗜好情報および前記アイテム嗜好情報のそれぞれの要素、および前記要素に対応する前記重み係数に基づいて演算される前記評価値に基づいて、前記ユーザに推薦する前記アイテムを特定する推薦方法である。
【００１７】
本発明の一側面は、コンピュータを、ユーザの嗜好を表す情報であって複数の要素を有するベクトルとして構成されるユーザ嗜好情報、および推薦の対象となるアイテムのそれぞれのメタ情報に基づいて生成され、それぞれ前記ユーザ嗜好情報の要素と同数の要素を有するベクトルとして構成されるアイテム嗜好情報の要素毎の類似度に重み係数をそれぞれ乗じた値、並びに前記アイテムに対する前記ユーザの操作の内容に応じて定まる評価値の目標値を対応付けた調整情報を生成して記憶する調整情報記憶手段と、複数の前記調整情報を用いた重回帰分析により前記ユーザ嗜好情報の要素のそれぞれに乗じられる重み係数のそれぞれを、ユーザ毎に算出する重回帰分析手段と、前記算出された重み係数を、前記評価値の算出において、前記ユーザ嗜好情報の要素のそれぞれに乗じられる重み係数として前記ユーザ毎に記憶する重み係数記憶手段と、前記ユーザ嗜好情報および前記アイテム嗜好情報のそれぞれの要素、および前記要素に対応する前記重み係数に基づいて演算される前記評価値に基づいて、前記ユーザに推薦する前記アイテムを特定する推薦アイテム特定手段とを備える推薦装置として機能させるプログラムである。
【００１８】
本発明の一側面においては、ユーザの嗜好を表す情報であって複数の要素を有するベクトルとして構成されるユーザ嗜好情報、および推薦の対象となるアイテムのそれぞれのメタ情報に基づいて生成され、それぞれ前記ユーザ嗜好情報の要素と同数の要素を有するベクトルとして構成されるアイテム嗜好情報の要素毎の類似度に重み係数をそれぞれ乗じた値、並びに前記アイテムに対する前記ユーザの操作の内容に応じて定まる評価値の目標値を対応付けた調整情報が生成されて記憶され、複数の前記調整情報を用いた重回帰分析により前記ユーザ嗜好情報の要素のそれぞれに乗じられる重み係数のそれぞれが、ユーザ毎に算出され、前記算出された重み係数が、前記評価値の算出において、前記ユーザ嗜好情報の要素のそれぞれに乗じられる重み係数として前記ユーザ毎に記憶され、前記ユーザ嗜好情報および前記アイテム嗜好情報のそれぞれの要素、および前記要素に対応する前記重み係数に基づいて演算される前記評価値に基づいて、前記ユーザに推薦する前記アイテムが特定される。
【発明の効果】
【００１９】
本発明によれば、ユーザの嗜好を構成する個々の属性、要素などの重要性を、常に適切に反映させた推薦を行なうことができる。
【発明を実施するための最良の形態】
【００２０】
以下、図面を参照して、本発明の実施の形態について説明する。
【００２１】
図１は、本発明の一実施の形態に係る推薦システム１０の構成例を示すブロック図である。この推薦システムは、例えば、映像、音声などのデータからなるアイテムをユーザに推薦するようになされている。アイテムには、例えば、放送される番組などのコンテンツ、DVDなどに記録された映画などをダビングすることで得られたコンテンツなどが含まれるものとする。
【００２２】
同図に示される推薦システム１０は、端末２１、操作ログDB２２、アイテムメタＤＢ２３、嗜好抽出エンジン２４、ユーザ嗜好ＤＢ２５、推薦エンジン２６、基軸・反転要素抽出部２７、および成熟度算出エンジン２８により構成されている。同図における操作ログDB２２乃至成熟度算出エンジン２８は、例えば、１台または複数台のコンピュータ（サーバ）などにより推薦装置として構成され、端末２１とネットワークなどを介して接続される。
【００２３】
あるいはまた、端末２１と操作ログDB２２乃至成熟度算出エンジン２８の機能ブロックを有する推薦装置とをそれぞれ独立した機器として設けるのではなく、推薦システム１０全体を１台または複数台のコンピュータなどの機器により実現することも可能である。
【００２４】
この推薦システム１０においては、例えば、端末２１からの要求に応じて、推薦装置が推薦すべきアイテムの一覧などを端末２１に送信するようになされている。推薦システム１０においては、例えば、各アイテムのメタ情報などに基づいて、ユーザの嗜好に合致するアイテムが推薦される。また、後述するように、推薦システム１０においては、端末２１からの要求に応じて、あえてユーザに意外性を感じさせるようなアイテムを推薦することができるようになされている。
【００２５】
同図において、ユーザは、端末２１を操作して、例えば、端末２１に記憶されているコンテンツのデータを再生するなどしてアイテムを視聴する。また、ユーザは、端末２１を操作して、例えば、放送される番組などを録画するなどしてアイテムを録画する。さらに、ユーザは、端末２１を操作して、例えば、端末２１に記憶されているコンテンツのデータを携帯端末に送信するなどしてアイテムを転送する。あるいはまた、ユーザは、端末２１を操作して、例えば、端末２１に記憶されているコンテンツのデータを削除するなどしてアイテムを削除する。その他、ユーザは、端末２１を操作して、アイテムに関する各種の処理を行うようになされている。
【００２６】
このような端末２１によるアイテムに関する各種の処理の操作に関する情報が、操作ログとして出力され、操作ログに基づいて生成されるレコードが操作ログDB（データベース）２２に蓄積されるようになされている。図２は、操作ログDB２２に記憶されるデータの例を示す図である。
【００２７】
図２の例において、各行に示されるデータが操作ログDB２２のレコードのそれぞれに対応する。この例では、操作ログDB２２のレコードのそれぞれは、「ItemId」、「MemberId」、「LogType」、および「LogTime」の４つのフィールドにより構成されている。
【００２８】
同図におけるフィールド「ItemId」は、操作されて処理された対象のアイテムを特定する情報であるアイテムIDの値が格納されるフィールドである。この例では、「１００１」、「１００３」、「１００９」、・・・の各値が各レコードのフィールド「ItemId」に格納されている。
【００２９】
同図におけるフィールド「MemberId」は、その操作を行ったユーザを特定する情報であるユーザ（メンバー）IDの値が格納されるフィールドである。この例では、「１」、「３」、「１」、・・・の各値が各レコードのフィールド「MemberId」に格納されている。
【００３０】
同図におけるフィールド「LogType」は、その操作の内容を特定する情報が格納されるフィールドである。この例では、「reserve」、「detail」、「good」、・・・などの情報が各レコードのフィールド「LogType」に格納されている。なお、フィールド「LogType」に格納されている情報は、例えば、アイテムの視聴、録画などの操作内容を予め設定された方式により変換した文字列などとされる。
【００３１】
同図におけるフィールド「LogTime」は、その操作が行われた日時を特定する情報が格納されるフィールドである。この例では、「２００７−１２−０５  ０８：３９：４４（西暦２００７年１２月５日の８時３９分４４秒を表す）」などの情報が各レコードのフィールド「LogTime」に格納されている。
【００３２】
アイテムメタDB２３には、各アイテムに付されたメタ情報に関する情報が格納されている。メタ情報は、例えば、放送される番組のEPGなどに基づいて得られる情報とされ、そのアイテム（コンテンツ）のジャンル、出演者、キーワードなどの情報により構成される。
【００３３】
図３は、あるアイテム（コンテンツなど）に付与されたアイテムメタ情報の例を示す図である。同図に示されるように、アイテムメタ情報は、アトリビュート、バリュー、およびスコアにより構成されている。アイテムメタ情報のアトリビュートは、「ジャンル」、「人物（例えば、コンテンツの出演者など）」、「キーワード」、・・・のような属性を表す項目により構成される。アイテムメタ情報のバリューは、アトリビュートを詳細に分類するものであり、この例では、アトリビュート「ジャンル」に含まれるバリューとして、「ドラマ」、「ニュース」、「ドキュメンタリー」、・・・が記述されている。アイテムメタ情報のスコアは、バリューのそれぞれに付与されたポイント（値）とされる。この例では、バリュー「ドラマ」のスコアは「５」、バリュー「ニュース」のスコアは「０」、バリュー「ドキュメンタリー」のスコアは「１」、・・・とされている。
【００３４】
図３の例におけるアイテムメタ情報に対応するアイテムは、例えば、そのジャンルがドラマに近いものであるが、ドキュメンタリーの要素も含むものであることが分かる。
【００３５】
また、図３の例では、アトリビュート「人物」に含まれるバリューとして、「ABC」、「DEF」、「GHI」、・・・が記述されている。この例では、バリュー「ABC」のスコアは「１」、バリュー「DEF」のスコアは「１」、バリュー「GHI」のスコアは「１」、・・・とされている。
【００３６】
図３の例におけるアイテムメタ情報に対応するアイテムは、例えば、そのコンテンツの出演者に「ABC」、「DEF」、「GHI」（いずれも架空の人物名）が含まれているものであることが分かる。
【００３７】
また、図３の例では、アトリビュート「キーワード」に含まれるバリューとして、「グルメ」、「旅行」、「音楽」、・・・が記述されている。この例では、バリュー「グルメ」のスコアは「３」、バリュー「旅行」のスコアは「５」、バリュー「音楽」のスコアは「１」、・・・とされている。アトリビュート「キーワード」のバリューは、例えば、そのアイテム（例えば、放送される番組など）を紹介するメッセージ（例えば、EPGの番組説明）に含まれる単語などであって、予め定められた単語とされる。例えば、EPGの番組説明の文章の中から「グルメ」、「旅行」、「音楽」、・・・など予め定められた単語が検出され、その単語の検出回数に対応してスコアが設定される。
【００３８】
図３の例におけるアイテムメタ情報に対応するアイテムは、例えば、「グルメ」、「旅行」、「音楽」に関連する内容のコンテンツであり、特に「旅行」について深い関連性のある内容であることが分かる。
【００３９】
アイテムメタDB２３には、各アイテムのアイテムメタ情報を、バリュー単位に分割して得られるレコードが記憶される。図４は、アイテムメタDB２３に記憶されるデータの例を示す図である。
【００４０】
図４の例において、各行に示されるデータがアイテムメタDB２３のレコードのそれぞれに対応する。この例では、アイテムメタDB２３のレコードのそれぞれは、「ItemId」、「AttributeId」、「ValueId」、「No/Times」および「Score」の４つのフィールドにより構成されている。
【００４１】
同図におけるフィールド「ItemId」は、当該レコードのアイテムを特定する情報であるアイテムIDの値が格納されるフィールドである。この例では、「２０００１１４７８９１４２」、「２０００１９５８０４８９」、「１０００２４３１６１６３」、・・・の各値が各レコードのフィールド「ItemId」に格納されている。
【００４２】
同図におけるフィールド「AttributeId」は、当該レコードのアトリビュートを特定する情報であるアトリビュートIDの値が格納されるフィールドである。この例では、値「１」が各レコードのフィールド「AttributeId」に格納されている。例えば、「AttributeId」が「１」である場合、アトリビュート「ジャンル」に対応し、「AttributeId」が「２」である場合、アトリビュート「人物」に対応し、・・・のようにフィールド「AttributeId」の値により当該レコードのアトリビュートが特定される。なお、この例では、「AttributeId」の値が、全てレコードにおいて「１」とされているが、実際のアイテムメタDB２３には、当然、「AttributeId」の値が「２」、「３」、・・・のレコードも存在する。
【００４３】
同図におけるフィールド「ValueId」は、当該レコードのバリューを特定する情報であるバリューIDの値が格納されるフィールドである。この例では、値「１５３１４４」が各レコードのフィールド「ValueId」に格納されている。例えば、「ValueId」が「１５３１４４」である場合、バリュー「ドラマ」に対応し、「ValueId」が「１５３１４５」である場合、バリュー「ニュース」に対応し、・・・のようにフィールド「ValueId」の値により当該レコードのバリューが特定される。なお、この例では、「ValueId」の値が、全てレコードにおいて「１５３１４４」とされているが、実際のアイテムメタDB２３には、当然、「ValueId」の値が「１５３１４５」、「１５３１４６」、・・・のレコードも存在する。
【００４４】
同図におけるフィールド「No/Times」は、当該レコードが更新された回数を特定する数値を格納するフィールドである。なお、フィールド「No/Times」は、設けられないようにしてもよい。
【００４５】
同図におけるフィールド「Score」は、当該レコードのバリューのスコアを特定する値が格納されるフィールドである。すなわち、フィールド「Score」には、図３のスコアに対応する値が格納される。例えば、同図の第１番目のレコードは、アイテムIDが「２０００１１４７８９１４２」のアイテムのアイテムメタ情報のバリュー「ドラマ」（「ValueId」が「１５３１４４」のバリュー）のスコアが記述されたレコードとなる。
【００４６】
このように、アイテムメタDB２３が構成されている。アイテムメタDB２３は、例えば、端末２１の操作の対象となり得る各アイテムに対応するコンテンツのメタデータを事前に取得するなどして予め生成されているものとする。
【００４７】
図１に戻って、嗜好抽出エンジン２４は、操作ログDB２２のレコードと、アイテムメタDB２３のレコードとに基づいてユーザ嗜好DB２５にデータを記憶させるようになされている。
【００４８】
嗜好抽出エンジン２４は、操作ログDB２２のレコードに基づいて、ユーザが端末２１を操作して処理を行ったアイテムのアイテムIDを特定し、また、その操作の内容を特定する。そして、嗜好抽出エンジン２４は、特定されたアイテムIDに基づいて、アイテムメタDB２３のレコードを検索し、特定されたアイテムIDのアイテムのアイテムメタ情報のアトリビュート、バリュー、スコアを特定する。
【００４９】
嗜好抽出エンジン２４は、さらに、特定されたアトリビュート、バリュー、スコアを当該ユーザのメンバーIDと対応付けたレコードを生成する。このとき、嗜好抽出エンジン２４は、スコアの値に操作の内容に応じて予め設定された係数を乗じるようになされている。例えば、操作ログDB２２のレコードに基づいて、特定された操作の内容がアイテムの録画であった場合、アイテムメタDB２３のレコードに基づいて、特定されたスコアの値に係数３が乗じられる。また、例えば、操作ログDB２２のレコードに基づいて、特定された操作の内容がアイテムの視聴であった場合、アイテムメタDB２３のレコードに基づいて、特定されたスコアの値に係数２が乗じられる。
【００５０】
そして、上述したように生成されたレコードがユーザ嗜好DB２５のレコードとなる。図５は、ユーザ嗜好DB２５の例を示す図である。
【００５１】
図５の例において、各行に示されるデータがユーザ嗜好DB２５のレコードのそれぞれに対応する。この例では、ユーザ嗜好DB２５のレコードのそれぞれは、「MemberId」、「AttributeId」、「ValueId」、および「Score」の４つのフィールドにより構成されている。
【００５２】
同図におけるフィールド「MemberId」は、図２の操作ログDB２２の説明において上述したユーザを特定する情報である。また、同図におけるフィールド「AttributeId」、フィールド「ValueId」、フィールド「Score」は、それぞれ図４のアイテムメタDB２３の説明において上述したアトリビュート、バリュー、スコアを特定する情報である。
【００５３】
図５の例では、ユーザ嗜好DB２５は、バリュー単位に生成されている。すなわち、１人のユーザが行なった１回の操作に対応して複数のレコードが生成される。それらのレコードは、操作の対象となったアイテムのアイテムメタ情報のバリューの数だけ生成されることになる。
【００５４】
また、ユーザ嗜好DB２５には、各ユーザが行なった操作に対応して、都度レコードが生成されて記憶される。すなわち、上述したような、操作の対象となったアイテムのアイテムメタ情報のバリューの数と同数のレコードが、１回の操作に対応して生成されることになる。
【００５５】
図１に戻って、推薦エンジン２６は、ユーザ嗜好DB２５のレコードに基づいてユーザ嗜好情報を生成する。また、推薦エンジン２６は、アイテムメタDB２３のレコードに基づいてアイテム嗜好情報を生成する。ここで、ユーザ嗜好情報およびアイテム嗜好情報は、それぞれアトリビュートの数と同数の要素を有するベクトルとされる。例えば、アイテムメタ情報のアトリビュートの数の合計が１００であった場合、ユーザ嗜好情報およびアイテム嗜好情報は、それぞれ１００次元（要素数が１００）のベクトルとされる。
【００５６】
ユーザ嗜好情報における各要素の値は、例えば、次のようにして求められる。推薦エンジン２６は、図５のユーザ嗜好DB２５のレコードをチェックして、当該ユーザのメンバーIDに対応付けられたレコードを全て取得する。推薦エンジン２６は、それらのレコードを、フィールド「AttributeId」の値によりソートし、フィールド「AttributeId」の値が同じレコードが複数あった場合、それらのレコードのフィールド「Score」の値を合計する。例えば、ユーザ嗜好情報のベクトルにおいて、アトリビュート「ジャンル」（「AttributeId」が「１」）に対応する要素の値は、バリュー「ドラマ」、「ニュース」、「ドキュメンタリー」、・・・のスコアの合計値とされる。このように、ユーザ嗜好情報は、各アトリビュートのスコアの合計値が各要素の値とされたベクトルとして生成される。
【００５７】
アイテム嗜好情報における各要素の値もユーザ嗜好情報の場合と同様にして求められる。アイテム嗜好情報を生成する場合、推薦エンジン２６は、図４のアイテムメタDB２３のレコードに基づいてベクトルの各要素の値を算出することになる。なお、１つのアイテムIDに対応して１つのアイテム嗜好情報のベクトルが生成されることになる。
【００５８】
基軸・反転要素抽出部２７は、ユーザ嗜好情報のベクトル、またはアイテム嗜好情報のベクトルから基軸要素と反転要素を抽出する。ここで、基軸要素は、ユーザの嗜好を強く反映させるための要素とされ、反転要素は、ユーザにとっての意外性を強く反映させるための要素とされる。基軸・反転要素抽出部２７は、例えば、次のようにして基軸要素と反転要素を抽出する。
【００５９】
基軸・反転要素抽出部２７は、ユーザ嗜好情報のベクトルの要素毎に、後述する式（１）の重みwaを乗じて得られる値について占有率を算出する。説明を簡単にするために、例えば、ユーザ嗜好情報が３次元のベクトルであるものと仮定し、あるユーザのユーザ嗜好情報がベクトル（１，２，３）であったとする。なお、このときのベクトル（１，２，３）は、ユーザ嗜好情報のそれぞれの要素の本来の値に、後述する式（１）の重みwaが乗じられた値とされる。後で説明するが、重みwaは、ベクトルの各要素に対応して予め設定された係数とされるので、いまの場合ｗ1乃至ｗ3の３種類の重みが予め設定されていることになる。すなわち、本来のユーザ嗜好情報がベクトル（ｘ，ｙ，ｚ）であったとすると、ｘ×w1＝１，ｙ×ｗ2＝２，ｚ×w3＝３の関係を満たすことになる。
【００６０】
この場合、第１番目の要素の占有率は、次式により演算される。
【００６１】
１／（１＋２＋３）＝０．１６６６≒１７％
【００６２】
第２番目の要素の占有率は、次式により演算される。
【００６３】
２／（１＋２＋３）＝０．３３３３≒３３％
【００６４】
第３番目の要素の占有率は、次式により演算される。
【００６５】
３／（１＋２＋３）＝０．５０００＝５０％
【００６６】
基軸・反転要素抽出部２７は、このようにして演算された占有率に基づいて基軸要素と反転要素を抽出する。例えば、ユーザ嗜好情報のベクトルの要素の中で占有率が最も高い要素は、基軸要素とされ、占有率が次に高い要素は、反転要素とされる。なお、ここからの説明では、ユーザ嗜好情報のベクトルは、Ｎ次元のベクトルとして説明する。
【００６７】
そして、基軸・反転要素抽出部２７は、最初に基軸要素として抽出された要素の占有率との合計値が予め設定された値（例えば、５０％）に達するまで、占有率が第３番目に高い要素、占有率が第４番目に高い要素、・・・を抽出し、それらの要素を基軸要素とする。
【００６８】
なお、ここで設定される値（例えば、５０％）は、後述する成熟度算出エンジン２８により算出される成熟度に対応して定まるものである。
【００６９】
例えば、占有率が第５番目に高い要素が抽出された時点で、基軸要素として抽出された要素の占有率の合計値が予め設定された値に達したものとする。その後、基軸・反転要素抽出部２７は、占有率が第６番目に高い要素、占有率が第７番目に高い要素、・・・占有率が第Ｎ番目に高い要素を抽出する。そしてそれらの要素が、最初に反転要素として抽出された要素とともに反転要素とされる。このようにして、ユーザ嗜好情報のベクトルから基軸要素と反転要素が抽出される。
【００７０】
なお、上記において説明した基軸要素と反転要素の抽出方式は、１つの例であり、他の方式により基軸要素と反転要素が抽出されるようにしても構わない。
【００７１】
基軸・反転要素抽出部２７は、基軸要素として抽出された要素のそれぞれに対応する「AttributeId」の値を基軸要素ＩＤとして推薦エンジン２６に通知する。また、基軸・反転要素抽出部２７は、反転要素として抽出された要素のそれぞれに対応する「AttributeId」の値を反転要素ＩＤとして推薦エンジン２６に通知する。
【００７２】
推薦エンジン２６は、基軸要素ＩＤに基づいてユーザ嗜好情報のベクトルの中の基軸要素を特定し、また、アイテム嗜好情報のベクトルの中の基軸要素を特定する。そして、推薦エンジン２６は、ユーザ嗜好情報のベクトルおよびアイテム嗜好情報のベクトルからそれぞれ基軸要素を抽出する。これにより、ユーザ嗜好情報の基軸ベクトルおよびアイテム嗜好情報の基軸ベクトルが生成される。
【００７３】
推薦エンジン２６は、反転要素ＩＤに基づいてユーザ嗜好情報のベクトルの中の反転要素を特定し、また、アイテム嗜好情報のベクトルの中の反転要素を特定する。そして、推薦エンジン２６は、ユーザ嗜好情報のベクトルおよびアイテム嗜好情報のベクトルからそれぞれ反転要素を抽出する。これにより、ユーザ嗜好情報の反転ベクトルおよびアイテム嗜好情報の反転ベクトルが生成される。
【００７４】
推薦エンジン２６は、例えば、アイテムの推薦を要求されたユーザのユーザ嗜好情報の基軸ベクトルと、アイテムメタＤＢ２３のレコードから生成された各アイテムのアイテム嗜好情報の基軸ベクトルとのマッチング処理を行う。マッチング処理は、例えば、ベクトルの内積を算出する方式、コサイン尺度を算出する方式、ユークリッド距離を算出する方式などにより行なわれる。
【００７５】
例えば、マッチング処理としてベクトルの内積を算出する方式が用いられる場合、マッチング処理の結果として得られるベクトルＸとベクトルＹの類似度sim（X,Ｙ）は、式（１）により演算される。
【００７６】
【数１】
2010061601.tif 000003
【００７７】
ここで、Ａは、例えば、基軸ベクトルの要素の集合とされ、ａは、集合Ａに含まれる１つの要素とされる。また、ＸaとＹaは、それぞれベクトルＸとベクトルＹにおける要素ａの値を表している。ｗａは、上述したように、要素ａに乗じられる係数であり、重みとも称される。なお、この重みｗaは、例えば、要素毎に予め決められた値が用いられるようにしてもよいし、各ユーザに対応して予め設定されるものとしてもよい。
【００７８】
重みｗaは、ベクトルの要素のそれぞれに対して個々に乗じられる係数であるから、実際には、ユーザ嗜好情報（またはアイテム嗜好情報）の各要素に対応した係数がそれぞれ存在する。従って、例えば、ユーザ嗜好情報がＮ個の要素を有するベクトルであった場合、重みwaはN次元ベクトルとして表現することもできる。
【００７９】
つまり、例えば、ユーザ嗜好情報（またはアイテム嗜好情報）の各要素が１００個あった場合、それらの要素は、それぞれ第１番目のアトリビュート乃至第１００番目のアトリビュートに対応する。この場合、重みwaは、第１番目のアトリビュート乃至第１００番目のアトリビュートに対応した係数の集合となる。例えば、第ｎ番目のアトリビュートに対応する係数をｗnで表すと、重みwaを１００個の要素からなるベクトルとして次のように表現することも可能である。
【００８０】
（ｗ1，ｗ2，ｗ3，・・・ｗ100）
【００８１】
上述した基軸ベクトル同士のマッチングにおいては、例えば、要素ａが第５番目の要素である場合、式（１）のwaに、（ｗ1，ｗ2，ｗ3，・・・ｗ100）のうちのｗ5が代入されて類似度が演算されるのである。
【００８２】
推薦エンジン２６は、例えば、式（１）の演算により、ユーザのユーザ嗜好情報の基軸ベクトルと、各アイテムのアイテム嗜好情報の基軸ベクトルとの類似度をそれぞれ算出する。そして、算出された類似度を基軸類似度として、それぞれ各アイテム（例えば、アイテムID）に対応付けて記憶するようになされている。
【００８３】
ここで、算出される基軸類似度は、その値が高いほど、ユーザの嗜好に合致したアイテムであることを表すものとなる。
【００８４】
推薦エンジン２６は、例えば、上述した基軸類似度の高いアイテムを予め定められた数だけ抽出し、それらのアイテムを候補アイテムとする。そして、推薦エンジン２６は、候補アイテムのそれぞれについて、次のように反転類似度を算出する。
【００８５】
推薦エンジン２６は、例えば、式（１）の演算により、ユーザのユーザ嗜好情報の反転ベクトルと、候補アイテムのアイテム嗜好情報の反転ベクトルとの類似度をそれぞれ算出する。そして、算出された類似度を反転類似度として、それぞれ各アイテムに対応付けて記憶するようになされている。
【００８６】
ここで、算出される反転類似度は、やはりその値が高いほど、ユーザの嗜好に合致する可能性が高いアイテムであることを表すものとなる。
【００８７】
そして、推薦エンジン２６は、上述した基軸類似度、および反転類似度に基づいて、各アイテムのそれぞれについて、意外性推薦評価値を算出する。ここで、意外性推薦評価値は、例えば、そのアイテムを推薦することにより、ユーザが肯定的な意外性を感じる可能性の高さを評価する値とされる。
【００８８】
例えば、アイテムＡの意外性推薦評価値igaiDegree（A）は、アイテムAの反転類似度Hanten（A）により、次式のように演算される。
【００８９】
igaiDegree（A）＝１−Hanten（A）
【００９０】
すなわち、アイテムAの反転類似度の値が小さいほど、アイテムＡの意外性推薦評価値の値が大きくなるのである。
【００９１】
あるいはまた、アイテムAの基軸類似度Base（A）を用いて、アイテムＡの意外性推薦評価値igaiDegree（A）は、次式により演算されるようにしてもよい。
【００９２】
igaiDegree（A）＝αBase（A）−βHanten（A）
【００９３】
なお、上記の式におけるαとβは、それぞれ予め定められた係数とする。
【００９４】
推薦エンジン２６は、例えば、このようにして算出された意外性推薦評価値の高い（大きい）ものから順に所定の数のアイテムを推薦するようになされている。例えば、推薦エンジン２６は、意外性推薦評価値の高いものから順に所定の数のアイテムを特定し、それらのアイテムの一覧などとして構成される推薦リストを生成する。そして、推薦エンジン２６は、推薦リストを端末２１に送信する。
【００９５】
このように、本発明においては、最初に基軸類似度に基づいて候補アイテムを絞り込み、その後、反転類似度を用いた意外性推薦評価値が演算されて推薦すべきアイテムが特定される。
【００９６】
図１の成熟度算出エンジン２８は、ユーザ嗜好情報の成熟度を算出するようになされている。例えば、成熟度は、次のようにして算出される。成熟度算出エンジン２８は、ユーザ嗜好DB２５に記憶されている当該ユーザのレコードを、最も新しいものから順に予め設定された数だけ抽出する。例えば、当該ユーザによる端末２１の直近の３回の操作に対応して生成されたレコードが抽出される。
【００９７】
そして、成熟度算出エンジン２８は、抽出されたレコードのフィールド「ValueId」の値をチェックし、フィールド「ValueId」の値が何種類あったかを表す値xvnを記憶する。例えば、当該ユーザのレコードが、最も新しいものから順に３個抽出されたものとする。例えば、それら３個のレコードのフィールド「ValueId」の値がそれぞれ、「１１」、「２２」、「３３」であった場合、xvn＝３となる。また、例えば、それら３個のレコードのフィールド「ValueId」の値がそれぞれ、「１１」、「２２」、「１１」であった場合、xvn＝２となる。
【００９８】
成熟度算出エンジン２８は、ユーザ嗜好DB２５に存在し得る「ValueId」の値の種類の合計を表す値yvnを求め、次式により成熟度Mを算出する。
【００９９】
M＝１−（xvn／yvn）
【０１００】
なお、xvnの値は、当該ユーザによる当該ユーザによる端末２１の操作１回あたりの、レコードのフィールド「ValueId」の値の種類の数の平均値とされるようにしてもよい。
【０１０１】
すなわち、成熟度算出エンジン２８は、ユーザ嗜好情報全体の中で直近の操作により更新される度合いに基づいて成熟度Mを算出するのである。
【０１０２】
ユーザ嗜好情報全体の中で直近の操作により更新される度合いが大きいほど、すなわち、上記の（xvn／yvn）が大きいほど、当該ユーザの嗜好が大きく変化していると考えることができる。このように、直近の操作によって、当該ユーザの嗜好が大きく変化している場合、当該ユーザのユーザ嗜好情報は、未だ成熟していないと推定される。このようなユーザ嗜好情報は、今後の操作により、再度大きく変化する可能性が高いからである。
【０１０３】
一方、直近の操作によって、当該ユーザの嗜好が大きく変化してない場合、当該ユーザのユーザ嗜好情報は、成熟していると推定される。このようなユーザ嗜好情報は、今後の操作により、大きく変化する可能性は低いからである。
【０１０４】
なお、例えば、ユーザ嗜好DB２５において当該ユーザのメンバーIDのレコードが最初に生成されてから、所定の期間が経過するまでは、当該ユーザのユーザ嗜好情報は未成熟であるとして成熟度Mの値が一律に０とされるようにしてもよい。また、例えば、当該ユーザによる操作の回数が予め設定された閾値未満であるなどの場合も、同様に当該ユーザのユーザ嗜好情報は未成熟であるとして成熟度Mの値が一律に０とされるようにしてもよい。
【０１０５】
なお、上述した成熟度Mの算出方式は、あくまで例であり、成熟度は、他の方式で算出されるようにしてもよい。
【０１０６】
上述したように、成熟度算出エンジン２８により算出された成熟度Mの値に基づいて、基軸・反転要素抽出部２７による基軸要素の抽出における、最初に基軸要素として抽出された要素の占有率との合計値の設定がなされることになる。なお、上述したように、占有率の算出にあたっては、本来のユーザ嗜好情報の要素の値に、それぞれ重みｗaが乗じられて算出される。
【０１０７】
例えば、成熟度が０％乃至４０％までの範囲である場合、ユーザ嗜好情報が未成熟であるとされ、それぞれの基軸要素の占有率の合計が８０％と設定される。未成熟なユーザ嗜好情報から抽出された反転要素は信頼性が低いと考えられるからである。
【０１０８】
また、例えば、成熟度が４１％乃至７０％までの範囲である場合、ユーザ嗜好情報がやや成熟しているとされ、それぞれの基軸要素の占有率の合計が６５％と設定される。
【０１０９】
さらに、例えば、成熟度が７１％乃至１００％までの範囲である場合、ユーザ嗜好情報が成熟しているとされ、それぞれの基軸要素の占有率の合計が５０％と設定される。成熟したユーザ嗜好情報から抽出された反転要素は信頼性が高いと考えられるからである。
【０１１０】
このように、上述した基軸ベクトルと反転ベクトルは、ユーザ嗜好情報の成熟度に基づいてその要素が確定される。
【０１１１】
このように、本発明においては、ユーザ嗜好情報の成熟度に基づいてその要素が確定される基軸ベクトルと反転ベクトルを用いた類似度の算出が行なわれる。そして、最初に基軸類似度に基づいて候補アイテムを絞り込み、その後、反転類似度を用いた意外性推薦評価値が演算されて推薦すべきアイテムが特定される。このようにすることで、ユーザに、肯定的な意外性を感じるアイテムを推薦することが可能となる。
【０１１２】
ユーザに意外性を感じさせるためには、ユーザに分かりやすいつながりを持ちつつ、普段見ているアイテムとはどこか異なるコンテンツを提示することが重要であると考えられる。すなわち、全くユーザの嗜好と合致しないコンテンツが推薦されたとすれば、やはりユーザは満足しないものと考えられる。
【０１１３】
例えば、従来の技術では、各属性の重みを変えることによって、マッチング結果へのその属性の寄与度を高くしようとするものもあるが、これでは、必ずしもユーザに分かりやすいつながりのあるコンテンツが推薦されるとは限らない。 
【０１１４】
単純に各属性の重みを変える方式では、例えば、ユーザ嗜好情報の中の特定の属性の重みを高く設定したとしても、コンテンツのメタデータに含まれる属性の値が小さいと、そのコンテンツが推薦される可能性は低くなってしまう。一方で、ユーザ嗜好情報の中の特定の属性の重みを低く設定したとしても、コンテンツのメタデータに含まれる属性の値が大きいと、そのコンテンツが推薦される可能性は高くなってしまう。
【０１１５】
このように従来の方式では、例えば、普段見ているコンテンツのジャンルと異なるジャンルのコンテンツを推薦することができ、ユーザに意外性を感じさせることはできるものの、その意外性が必ずしも肯定的な意外性と感じられるかどうかは分からない。
【０１１６】
本発明においては、最初に基軸類似度に基づいて候補アイテムを絞り込み、その後、反転類似度を用いた意外性推薦評価値が演算されて推薦すべきアイテムが特定されるようになされている。
【０１１７】
そもそも、基軸類似度、反転類似度ともにユーザ嗜好情報とアイテム嗜好情報との類似度合いを表すものであり、基軸類似度も、反転類似度も値が大きいほどユーザの嗜好に合致している可能性は高くなる。また、一方で基軸類似度も、反転類似度も値が小さいほどユーザの嗜好に合致していない可能性は高くなる。
【０１１８】
例えば、類似度の低いアイテムを推薦するようにすれば、確実にユーザに意外性を感じさせることはできる。しかしながら、このような推薦では、ユーザの嗜好に逆行するアイテムを選択して推薦することになってしまうので、ユーザに肯定的な意外性を感じさせることはできない。
【０１１９】
そこで、本発明は、ユーザ嗜好情報のベクトルを基軸ベクトルと反転ベクトルの２つに分割したのである。そして、基軸ベクトルに基づく類似度（基軸類似度）の高いアイテムを絞り込んで、さらに、反転ベクトルに基づく類似度（反転類似度）の低いアイテムが選択されるようにしたのである。これにより、本発明では、確実に肯定的な意外性を感じさせるアイテムを推薦することができるのである。
【０１２０】
次に、図６のフローチャートを参照して、図１の推薦システム１０による推薦リスト生成処理について説明する。この処理は、例えば、端末２１により、あえてユーザに意外性を感じさせるようなアイテムの推薦が要求されたとき実行される。
【０１２１】
ステップＳ１１において、成熟度算出エンジン２８は、成熟度を算出する。
【０１２２】
ステップＳ１２において、基軸・反転要素抽出部２７は、ステップＳ１１で算出された成熟度に基づいて、基軸要素と反転要素の割合を設定する。このとき上述したように、例えば、成熟度の値が所定の閾値と比較され、ユーザ嗜好情報の成熟の度合い（例えば、未成熟、やや成熟、成熟）が判定される。そして、その成熟の度合いに応じた基軸要素と反転要素の割合が設定される。例えば、それぞれの基軸要素の占有率の合計が８０％、６５％、５０％などのように設定される。
【０１２３】
ステップＳ１３において、基軸・反転要素抽出部２７と推薦エンジン２６は、図７を参照して後述するマッチング処理を実行する。これにより、ユーザ嗜好情報とアイテム嗜好情報の基軸ベクトル、反転ベクトルのマッチングがなされ、各アイテムのそれぞれについて基軸類似度と反転類似度が算出されて記憶される。また、ステップＳ１３の処理により、推薦すべきアイテムの候補となる候補アイテムの特定もなされることになる。
【０１２４】
ステップＳ１４において、推薦エンジン２６は、ステップＳ１３の処理の中で特定された候補アイテムのそれぞれについて意外性推薦評価値を算出する。このとき、例えば、上述したように、アイテムＡの意外性推薦評価値igaiDegree（A）は、アイテムAの反転類似度Hanten（A）により、次式のように演算される。
【０１２５】
igaiDegree（A）＝１−Hanten（A）
【０１２６】
あるいはまた、アイテムAの基軸類似度Base（A）を用いて、アイテムＡの意外性推薦評価値igaiDegree（A）は、次式により演算されるようにしてもよい。
【０１２７】
igaiDegree（A）＝αBase（A）−βHanten（A）
【０１２８】
ステップＳ１５において、推薦エンジン２６は、推薦すべきアイテムを特定する。このとき、例えば、候補アイテムのうち、意外性推薦評価値の高いアイテムが予め設定された数だけ特定される。
【０１２９】
ステップＳ１６において、推薦エンジン２６は、ステップＳ１５において推薦すべきアイテムとして特定されたアイテムの一覧などとして構成される推薦リストのデータを生成する。ここで生成された推薦リストのデータは端末２１に送信され、例えば、推薦リストが端末２１のディスプレイに表示されるなどして、ユーザにアイテムが推薦されることになる。
【０１３０】
このようにして、推薦リスト生成処理が実行される。このようにすることで、ユーザに、確実に肯定的な意外性を感じさせるアイテムを推薦することができる。
【０１３１】
次に、図７のフローチャートを参照して、図６のステップＳ１３のマッチング処理の詳細な例について説明する。
【０１３２】
ステップＳ３１において、基軸・反転要素抽出部２７は、ユーザ嗜好情報から基軸要素を抽出する。
【０１３３】
このとき、上述したように、基軸・反転要素抽出部２７は、ユーザ嗜好情報のベクトルの要素毎に、式（１）の重みwaを乗じて得られる値について占有率を算出する。例えば、ユーザ嗜好情報のベクトルの要素の中で占有率が最も高い要素は、基軸要素とされ、占有率が次に高い要素は、基軸要素とされない。そして、最初に基軸要素として抽出された要素の占有率との合計値がステップＳ１２の処理で設定された値に達するまで、占有率が第３番目に高い要素、占有率が第４番目に高い要素、・・・が抽出され、それらの要素を基軸要素とされる。そして、基軸要素として抽出された要素のそれぞれに対応する「AttributeId」の値に基づいてユーザ嗜好情報から基軸要素が抽出される。
【０１３４】
ステップＳ３２において、基軸・反転要素抽出部２７は、アイテム嗜好情報から基軸要素を抽出する。このとき、ステップＳ３１の処理で抽出された基軸要素に対応する要素がアイテム嗜好情報から抽出される。
【０１３５】
ステップＳ３３において、推薦エンジン２６は、ステップＳ３１の処理で抽出された基軸要素からなる、ユーザ嗜好情報の基軸ベクトルと、ステップＳ３２の処理で抽出された基軸要素からなる、アイテム嗜好情報の基軸ベクトルとの類似度を算出する。類似度は、例えば、上述した式（１）により算出される。このとき、例えば、推薦の対象となるアイテムの数だけ類似度が算出され、それらの類似度は各アイテムのそれぞれに対応する基軸類似度とされる。
【０１３６】
ステップＳ３４において、推薦エンジン２６は、ステップＳ３３の処理により算出された類似度の高い順に予め定められた数のアイテムを、候補アイテムとして特定する。
【０１３７】
ステップＳ３５において、推薦エンジン２６は、ステップＳ３４の処理で特定された候補アイテムのそれぞれに対応付けて、ステップＳ３３の処理で算出された基軸類似度を記憶する。
【０１３８】
ステップＳ３６において、基軸・反転要素抽出部２７は、ユーザ嗜好情報から反転要素を抽出する。このとき、例えば、ステップＳ３１の処理で基軸要素として抽出されなかった要素が反転要素として抽出される。
【０１３９】
ステップＳ３７において、基軸・反転要素抽出部２７は、アイテム嗜好情報から反転要素を抽出する。このとき、ステップＳ３６の処理で抽出された反転要素に対応する要素がアイテム嗜好情報から抽出される。
【０１４０】
ステップＳ３８において、推薦エンジン２６は、ステップＳ３６の処理で抽出された反転要素からなる、ユーザ嗜好情報の反転ベクトルと、ステップＳ３７の処理で抽出された反転要素からなる、アイテム嗜好情報の反転ベクトルとの類似度を算出する。類似度は、例えば、上述した式（１）により算出される。このとき、例えば、推薦の対象となるアイテムの数だけ類似度が算出され、それらの類似度は各アイテムのそれぞれに対応する反転類似度とされる。
【０１４１】
ステップＳ３９において、推薦エンジン２６は、ステップＳ３４の処理で特定された候補アイテムのそれぞれに対応付けて、ステップＳ３８の処理で算出された反転類似度を記憶する。
【０１４２】
このようにして、マッチング処理が行われる。
【０１４３】
なお、以上においては、推薦システム１０において、主に、あえてユーザに意外性を感じさせるようなアイテムの推薦を行なう場合の例について説明したが、勿論、意外性を感じさせないようなアイテムの推薦を行なうことも可能である。推薦システム１０において、意外性を感じさせないようなアイテムの推薦を行なう場合、例えば、推薦エンジン２６が、ユーザ嗜好情報とアイテム嗜好情報とをそのままマッチングして、類似度を算出する。そして、算出された類似度の高いアイテムが推薦される。
【０１４４】
ところで、以上においては、式（１）の重みｗaは、例えば、要素毎に予め決められた値が用いられるようにしてもよいし、各ユーザに対応して予め設定されるものとしてもよいとして説明した。
【０１４５】
従来、ユーザ嗜好情報とアイテム嗜好情報との類似度を算出する場合、重みは個人によらない共通の固定値が用いられている。しかし、実際にはユーザごとに重要視する属性は異なり、共通の固定値ではこの個人差を補えないため、共通の固定値である重みを用いて類似度を算出してアイテムを推薦しても、真にユーザの嗜好に合致したアイテムを推薦できないことがある。
【０１４６】
また、例えば、予めユーザに自分が重要視する属性（アトリビュート）などを入力させ、その入力結果に応じて個人別に重みを調整する方式もが考えられる。この方式であれば、上述した個人差を補うことも可能である。
【０１４７】
しかし、ユーザの嗜好は、極めて抽象的な概念であって本人であっても表現することは難しく、必ずしも自分が重要視する属性（アトリビュート）が簡単に見つかるとは限らない。
【０１４８】
さらに、ユーザの嗜好は、時間とともに変化することもある。例えば、放送される番組やDVDのコンテンツなどを数多く視聴した結果、自分が最初に重要視すると考えていた属性よりも、さらに重要視すべき属性が見つかることもある。
【０１４９】
そこで、本発明においては、個々のユーザにとって最適な重みを自動的に調整できるようにする。
【０１５０】
図８は、個々のユーザにとって最適な重みを自動的に調整できるようにした推薦システム１００の構成例を示すブロック図である。
【０１５１】
同図に示される推薦システム１００は、端末１２１、操作ログDB１２２、アイテムメタＤＢ１２３、ユーザ嗜好ＤＢ１２５、推薦エンジン１２６、属性重み調整エンジン１２９、属性重みＤＢ１３１、および属性重み調整ＤＢ１３２により構成されている。同図における操作ログDB１２２乃至属性重み調整ＤＢ１３２は、例えば、１台または複数台のサーバなどにより推薦装置として構成され、端末１２１とネットワークなどを介して接続される。
【０１５２】
あるいはまた、端末１２１と操作ログDB１２２乃至属性重み調整ＤＢ１３２の機能ブロックを有する推薦装置とをそれぞれ独立した機器として設けるのではなく、推薦システム１００全体を１台または複数台のコンピュータなどの機器により実現することも可能である。
【０１５３】
図８の端末１２１、操作ログDB１２２、アイテムメタＤＢ１２３、およびユーザ嗜好ＤＢ１２５は、図１の端末２１、操作ログDB２２、アイテムメタＤＢ２３、およびユーザ嗜好ＤＢ２５と同様のものであるので、詳細な説明は省略する。操作ログDB１２２は、図２を参照して上述した場合と同様のレコードにより構成されている。アイテムメタＤＢ１２３は、図４を参照して上述した場合と同様のレコードにより構成されている。ユーザ嗜好ＤＢ１２５は、図５を参照して上述した場合と同様のレコードにより構成されている。なお、同図には、図１の嗜好抽出エンジン２４に対応する機能ブロックが記載されていないが、図１を参照して上述した場合と同様に、ユーザ嗜好ＤＢ１２５のレコードが生成されるものとする。
【０１５４】
図９は、属性重みＤＢ１３１の例を示す図である。図９の例において、各行に示されるデータが属性重みＤＢ１３１のレコードのそれぞれに対応する。この例では、属性重みＤＢ１３１のレコードのそれぞれは、「MemberId」、「AttributeId」、「Weight」、および「DefaultWeight」の４つのフィールドにより構成されている。
【０１５５】
同図におけるフィールド「MemberId」は、図２の操作ログDB２２の説明において上述したユーザを特定する情報が格納されるフィールドである。また、同図におけるフィールド「AttributeId」は、図４のアイテムメタDB２３の説明において上述したアトリビュートを特定する情報が格納されるフィールドである。
【０１５６】
同図のフィールド「Weight」は、フィールド「MemberId」によって特定されるユーザの重みの値が格納されるフィールドである。なお、上述したように、重みはアトリビュート（属性）ごとに設定されるようになされており、フィールド「Weight」には、フィールド「AttributeId」の値に対応するアトリビュートの重みの値が格納される。
【０１５７】
フィールド「DefaultWeight」は、フィールド「MemberId」によって特定されるユーザの重みの値の初期値が格納されるフィールドである。重みの初期値は、予め決められた値が用いられるようにしてもよいし、各ユーザに対応して予め設定されるものとしてもよい。すなわち、当該ユーザの重みが自動的に調整される前は、フィールド「Weight」には、フィールド「DefaultWeight」の値が格納されることになる。
【０１５８】
図９の例では、フィールド「MemberId」の値が「１」または「２」であるレコードがそれぞれアトリビュート毎に記憶されている。同図の例では、各レコードのフィールド「Weight」には、フィールド「DefaultWeight」の値が格納されており、当該ユーザの重みは、まだ自動的に調整されていない。
【０１５９】
図８の属性重み調整エンジン１２９は、操作ログDB１２２に記憶されているレコードに基づいて属性重み調整DB１３２のレコードを生成するようになされている。属性重み調整DB１３２は、所定のユーザについて調整した重みを算出するために用いられる情報が記憶されるデータベースとされる。
【０１６０】
図１０は、属性重み調整DB１３２の例を示す図である。図１０の例において、各行に示されるデータが属性重み調整ＤＢ１３２のレコードのそれぞれに対応する。この例では、属性重み調整ＤＢ１３２のレコードのそれぞれは、「MemberId」、「TargetScore」、「AttributeScore」、および「UpdateTime」の４つのフィールドにより構成されている。
【０１６１】
同図におけるフィールド「MemberId」は、図２の操作ログDB２２の説明において上述したユーザを特定する情報が格納されるフィールドである。
【０１６２】
また、同図におけるフィールド「TargetScore」およびフィールド「AttributeScore」には、次のようにして得られた情報が格納される。
【０１６３】
属性重み調整エンジン１２９は、操作ログDB１２２のレコードについて、各レコードのフィールド「LogType」に格納される情報をチェックする。上述したように、操作ログDB１２２のレコードのフィールド「LogType」には、「reserve」、「detail」、「good」、・・・などの情報が格納されている。そして、フィールド「LogType」に格納されている情報は、アイテムの視聴、録画などの操作内容を予め設定された方式により変換した文字列などとされる。
【０１６４】
属性重み調整エンジン１２９は、フィールド「LogType」に格納される情報が予め設定された情報と同じであるレコードを、属性重み調整DB１３２のレコードの生成に用いるレコードとして取得する。ここで、属性重み調整DB１３２のレコードの生成に用いるレコードとは、対象となったアイテムに対してのユーザの評価を推測できる操作に対応して生成されたレコードとされる。
【０１６５】
例えば、ユーザがあるアイテムを視聴、録画などする操作を行った場合、ユーザは、そのアイテムを肯定的に評価していると推測することができる。一方、例えば、ユーザがあるアイテムに対応するコンテンツのデータを削除する操作を行った場合、ユーザは、そのアイテムを否定的に評価していると推測することができる。
【０１６６】
操作ログDB１２２のレコードについて、各レコードのフィールド「LogType」に格納される情報は、このように操作内容に対応するユーザの評価を推測できるように、予め設定された方式により変換した文字列などとされる。例えば、ユーザがあるアイテムを視聴、録画などする操作を行った場合、その操作に対応して生成されるレコードのフィールド「LogType」に格納される情報は、「good」となる。また、例えば、ユーザがあるアイテムに対応するコンテンツのデータを削除する操作などを行った場合、その操作に対応して生成されるレコードのフィールド「LogType」に格納される情報は、「bad」となる。
【０１６７】
属性重み調整エンジン１２９は、例えば、フィールド「LogType」に格納される情報が「good」または「bad」であるレコードを、属性重み調整DB１３２のレコードの生成に用いるレコードとして取得する。
【０１６８】
属性重み調整エンジン１２９は、上述のように取得したレコードのフィールド「ItemId」の値に基づいて、操作の対象となったアイテムを特定し、推薦エンジン１２６に、そのアイテムのアイテム嗜好情報を生成させる。ここで、アイテム嗜好情報は、上述したように、アトリビュートの数と同数の要素を有するベクトルとされ、アイテムメタDB１２３のレコードに基づいて生成される。また、属性重み調整エンジン１２９は、上述のように取得したレコードのフィールド「MemberId」の値に基づいて、操作を行ったユーザを特定し、推薦エンジン１２６に、ユーザ嗜好DB１２５のレコードに基づいてそのユーザのユーザ嗜好情報を生成させる。
【０１６９】
そして、属性重み調整エンジン１２９は、推薦エンジン１２６に、アイテム嗜好情報とユーザ嗜好情報とのマッチング処理を実行させる。このとき、例えば、上述した式（１）の演算が行われることになる。属性重み調整エンジン１２９は、式（１）の│Xa・Ya│の値を、アトリビュートａの類似度として推薦エンジン１２６から取得し、各アトリビュートの類似度をアトリビュートＩＤに対応づけた情報を生成する。この情報が、フィールド「AttributeScore」に格納される情報になる。
【０１７０】
例えば、図１０の第１番目のレコードのフィールド「AttributeScore」には、「&1=｛6265.430664｝&6=｛9245.234375｝&7=｛255.272858｝・・・」と記述されている。これは、アトリビュートＩＤが「１」であるアトリビュートの類似度が「6265.430664」であり、アトリビュートＩＤが「６」であるアトリビュートの類似度が「9245.234375」であり、アトリビュートＩＤが「７」であるアトリビュートの類似度が「255.272858」であり、・・・であることを表している。
【０１７１】
フィールド「TargetScore」には、フィールド「LogType」に格納される情報に対応して定まる類似度の目標値が格納される。ここでの類似度の目標値は、アイテム嗜好情報とユーザ嗜好情報との類似度の目標値であり、式（１）のsim（X,Y）に対応する値となる。例えば、属性重み調整DB１３２のレコードの生成に用いるレコードのフィールド「LogType」に格納される情報が「good」である場合、フィールド「TargetScore」には、「100.0」が格納される。例えば、属性重み調整DB１３２のレコードの生成に用いるレコードのフィールド「LogType」に格納される情報が「bad」である場合、フィールド「TargetScore」には、「-100.0」が格納される。なお、「good」に対応する類似度の目標値（いまの場合、「100.0」）と「bad」に対応する類似度の目標値（いまの場合、「-100.0」）は、予め定められているものとする。
【０１７２】
図１０のフィールド「UpdateTime」には、例えば、そのレコードが生成された日時を特定する情報が格納される。
【０１７３】
このようにして、属性重み調整DB１３２のレコードが生成されていく。すなわち、操作ログDB１２２のレコードのうち、属性重み調整DB１３２のレコードの生成に用いるレコードとして取得されたレコードの数に対応する数の属性重み調整DB１３２のレコードが生成されることになる。
【０１７４】
属性重み調整エンジン１２９は、属性重み調整DB１３２のレコードに基づいて各ユーザの重みの調整を行う。ここで、重みの調整は、属性重み調整DB１３２のレコードのフィールド「TargetScore」から得られる類似度の目標値（目標類似度と称することにする）と属性重み調整DB１３２のレコードのフィールド「AttributeScore」から得られる各アトリビュートの類似度を用いた重回帰分析によりなされる。
【０１７５】
すなわち、属性重み調整エンジン１２９は、目標類似度を従属変数とし、各アトリビュートの類似度を説明変数として重回帰分析を行なうことで、各アトリビュートに対応する重みの最適値の予測演算を実行するのである。
【０１７６】
上述したように、重みwaは、それぞれの要素（アトリビュート）に対応して定まるので、例えば、図１０の第１番目のレコードから、次のような線形一次式を得ることができる。
【０１７７】
100.0＝6265.430664×ｗ1＋9245.234375×ｗ6＋255.272858×ｗ7＋・・・
【０１７８】
また、図１０の第２番目のレコードから、次のような線形一次式を得ることができる。
【０１７９】
100.0＝336.787109×ｗ1＋334.451447×ｗ6＋720.280334×ｗ7＋・・・
【０１８０】
このように、属性重み調整DB１３２のレコードのうちメンバーIDが「１」であるレコードのそれぞれに基づいて上述した線形一次式を生成する。そして、それらの線形一次式の左辺と右辺の各項を足しこんだ行列式を生成する。この行列式に基づいて、例えば、最小自乗法により（ｗ1，ｗ6，ｗ7，・・・）の解を求めるのである。このようにして重回帰分析が行なわれる。
【０１８１】
なお、ここでは、重みが、（ｗ1，ｗ6，ｗ7，・・・）で表される例について説明したが、属性重み調整DB１３２のレコード数が充分に多ければ、例えば、ｗ2，ｗ3，ｗ4，・・・などの値も求めることは可能である。属性重み調整エンジン１２９が、充分多くのレコードを取得して、目標類似度を従属変数とし、各アトリビュートの類似度を説明変数として重回帰分析を行なうことで、上述した式（１）の重みｗaが求められる。例えば、ユーザ嗜好情報の要素数が１００個存在する場合、ｗ1，ｗ2，ｗ3，・・・ｗ100が上述した重回帰分析により求められるのである。
【０１８２】
このようにして、属性重み調整エンジン１２９は、各アトリビュートに対応する重みの最適値を求める。このようにして得られた重みを用いて式（１）の演算を行って類似度を求めれば、「LogType」に格納される情報が「good」であったアイテムのアイテム嗜好情報との類似度は、「100.0」に近い値となる。また、「LogType」に格納される情報が「bad」であったアイテムのアイテム嗜好情報との類似度は、「-100.0」に近い値となる。すなわち、ユーザの評価の高いアイテムの類似度が高くなり、ユーザの評価の高いアイテムの類似度が低くなるように、そのユーザの重みの調整を行うことができるのである。
【０１８３】
属性重み調整エンジン１２９は、上述のようして得られた調整済みの重みの値のそれぞれを、当該ユーザのメンバーIDに対応するレコードとしてアトリビュート単位に生成された属性重みＤＢ１３１のレコードのフィールド「Weight」に格納する。
【０１８４】
推薦エンジン１２６は、ユーザに推薦すべきアイテムを特定するために、そのユーザのユーザ嗜好情報と各アイテムのアイテム嗜好情報との類似度を、属性重みＤＢ１３１のレコードのフィールド「Weight」に格納された値を用いて演算する。このとき、例えば、属性重みＤＢ１３１のレコードに基づいて特定された、当該ユーザの各アトリビュートに対応する重みの値のそれぞれが、式（１）のwaとして用いられ、類似度（sim（X,Y））が演算される。
【０１８５】
推薦エンジン１２６は、例えば、このようにして演算された類似度の高い（大きい）ものから順に所定の数のアイテムを推薦するようになされている。例えば、推薦エンジン１２６は、類似度の高いものから順に所定の数のアイテムを特定し、それらのアイテムの一覧などとして構成される推薦リストを生成する。そして、推薦エンジン１２６は、推薦リストを端末１２１に送信する。
【０１８６】
このようにして、推薦システム１００におけるアイテムの推薦が行なわれる。ユーザごとに重要視する属性（アトリビュート）は異なるものなので、共通の固定値である重みを用いて類似度を算出してアイテムを推薦しても、真にユーザの嗜好に合致したアイテムを推薦できないことがある。
【０１８７】
また、ユーザの嗜好は、極めて抽象的な概念であって本人であっても表現することは難しく、必ずしも自分が重要視する属性（アトリビュート）が簡単に見つかるとは限らない。さらに、ユーザの嗜好は、時間とともに変化することもある。
【０１８８】
本発明においては、各ユーザの操作ログDBに基づいて、そのユーザのアイテムに対する評価を推定し、属性重み調整DB１３２のレコードの目標類似度が設定される。そして、目標類似度と、各アトリビュートの類似度とを用いて重回帰分析が行なわれることで、そのユーザの各アトリビュートに対応する重みが求められるようになされている。従って、個々のユーザにとって最適な重みを自動的に設定できるようにする。
【０１８９】
次に、図１１のフローチャートを参照して、図８の推薦システム１００における属性重み調整DＢ生成処理について説明する。この処理は、属性重み調整ＤＢ１３２のレコードを生成するとき実行される。
【０１９０】
ステップＳ１０１において、属性重み調整エンジン１２９は、操作ログDB１２２の解析範囲を設定する。解析範囲は、例えば、日時を表す情報として指定され、操作ログDB１２２のレコードのうち、指定された日時以降現在までのレコードが解析範囲とされる。
【０１９１】
ステップＳ１０２において、属性重み調整エンジン１２９は、ステップＳ１０１で設定された解析範囲のレコードを取得する。なお、当該レコードが解析範囲のものであるか否かは、例えば、操作ログDB１２２のレコードのフィールド「LogTime」に記述された情報に基づいて特定される。
【０１９２】
ステップＳ１０３において、属性重み調整エンジン１２９は、ステップＳ１０２の処理で取得されたレコードについて、予め定められたログタイプのレコードであるか否かを判定する。このとき、例えば、レコードのフィールド「LogType」に格納される情報が属性重み調整DB１３２のレコードの生成に用いるレコードとして予め定められたものであるか否かがチェックされる。例えば、フィールド「LogType」に格納される情報が「good」または「bad」である場合、処理は、ステップＳ１０４に進む。
【０１９３】
ステップＳ１０４において、属性重み調整エンジン１２９は、当該レコードのメンバーＩＤとアイテムＩＤを特定する。
【０１９４】
ステップＳ１０５において、属性重み調整エンジン１２９は、推薦エンジン１２６に、ステップＳ１０４の処理で特定されたメンバーＩＤに対応するユーザ嗜好情報と特定されたアイテムＩＤに対応するアイテム嗜好情報とをマッチングさせる。このとき、例えば、上述した式（１）の演算が行われることになる。ステップＳ１０５において、属性重み調整エンジン１２９は、式（１）の│Xa・Ya│の値を、アトリビュートａの類似度として推薦エンジン１２６から取得し、各アトリビュートの類似度をアトリビュートＩＤに対応づけた情報を生成する。これによりアトリビュート毎の類似度が算出されたことになる。なお、上述したように、各アトリビュートの類似度をアトリビュートＩＤに対応づけた情報は、属性重み調整DB１３２のレコードのフィールド「AttributeScore」に格納される情報になる。
【０１９５】
ステップＳ１０６において、属性重み調整エンジン１２９は、ステップＳ１０５の処理で得られた情報と類似度の目標値とを対応付けて、図１０を参照して上述したように、属性重み調整DB１３２のレコードを生成して属性重み調整DB１３２に記憶（登録）する。
【０１９６】
なお、上述したように、例えば、属性重み調整DB１３２のレコードの生成に用いるレコードのフィールド「LogType」に格納される情報が「good」である場合、類似度の目標値は、「100.0」とされる。また、例えば、属性重み調整DB１３２のレコードの生成に用いるレコードのフィールド「LogType」に格納される情報が「bad」である場合、類似度の目標値は、「-100.0」とされる。
【０１９７】
ステップＳ１０３において、ステップＳ１０２の処理で取得されたレコードについて、予め定められたログタイプのレコードではないと判定された場合、ステップＳ１０４乃至ステップＳ１０６の処理は、スキップされる。
【０１９８】
ステップＳ１０７において、解析範囲の全てのレコードをチェックしたか否かが判定される。まだ、解析範囲の全てのレコードをチェックしていないと判定された場合、処理は、ステップＳ１０２に戻る。
【０１９９】
そして、ステップＳ１０７において、解析範囲の全てのレコードをチェックしたと判定されるまで、ステップＳ１０２乃至ステップＳ１０７の処理が繰り返し実行される。
【０２００】
このようにして、属性重み調整DB生成処理が実行される。
【０２０１】
次に、図１２のフローチャートを参照して、図８の推薦システム１００における属性重み算出処理について説明する。この処理は、例えば、端末１２１のユーザ単位に所定の周期で実行される。すなわち、例えば、ユーザAについての属性重み算出処理を最初に行ってから、所定の日数が経過したタイミングで、再度ユーザAについての属性重み算出処理が実行される。そして、その後、所定の日数が経過したタイミングで、再度ユーザAについての属性重み算出処理が実行されるようになされている。
【０２０２】
あるいはまた、この処理は、例えば、ユーザにより指令される都度、実行されるようにしても構わない。
【０２０３】
ステップＳ１２１において、属性重み調整エンジン１２９は、メンバーＩＤを特定する。すなわち、これから実行される処理によって、ステップＳ１２１の処理で特定されたメンバーＩＤに対応するユーザの各アトリビュートの重みが算出されることになる。
【０２０４】
ステップＳ１２２において、属性重み調整エンジン１２９は、属性重み調整DB１３２に記憶されているレコードであって、ステップＳ１２１で特定されたメンバーＩＤのレコードをチェックする。
【０２０５】
ステップＳ１２３において、属性重み調整エンジン１２９は、ステップＳ１２２の処理でチェックしたレコードがＮ個以上あったか否かを判定する。ここで、Ｎは、予め設定された値とされ、上述したように重回帰分析を行なうのに充分なレコード数が存在するか否かを判定するための閾値とされる。
【０２０６】
ステップＳ１２３において、レコードがＮ個以上あったと判定された場合、処理は、ステップＳ１２４に進む。
【０２０７】
ステップＳ１２４において、属性重み調整エンジン１２９は、ステップＳ１２２の処理でチェックした、属性重み調整DB１３２のレコードに基づいて当該ユーザの重みの調整を行う。ここで、重みの調整は、属性重み調整DB１３２のレコードのフィールド「TargetScore」から得られる目標類似度と属性重み調整DB１３２のレコードのフィールド「AttributeScore」から得られる各アトリビュートの類似度を用いた重回帰分析によりなされる。
【０２０８】
ステップＳ１２５において、属性重み調整エンジン１２９は、ステップＳ１２４の処理の結果得られた重みを、ステップＳ１２１で特定されたユーザの各アトリビュートの重みとして特定する。
【０２０９】
ステップＳ１２６において、属性重み調整エンジン１２９は、ステップＳ１２５の処理で特定されたユーザの各アトリビュートの重みを反映させるべく、属性重みＤＢ１３１を更新する。具体的には、図９に示したような属性重みＤＢ１３１のレコードの中から、ステップＳ１２１で特定されたメンバーＩＤのレコードが取得され、それらのレコードのフィールド「AttributeId」の値がチェックされる。そして、ステップＳ１２５の処理で特定されたユーザの各アトリビュートの重みのそれぞれが、当該アトリビュートを表す「AttributeId」の値を有するレコードのフィールド「Weight」の値として書き換えられていくのである。アトリビュートの数は、ユーザ嗜好情報の要素数に対応するので、例えばユーザ嗜好情報の要素数が１００個存在する場合、ステップＳ１２６においては、属性重みＤＢ１３１の中の１００個のレコードのフィールド「Weight」の値が書き換えられることになる。
【０２１０】
ステップＳ１２６の処理の後、ステップＳ１２７において属性重み調整エンジン１２９は、属性重み調整ＤＢ管理処理を実行する。この処理によって、属性重み調整ＤＢ１３２の中の不要なレコードが削除されることになる。属性重み調整ＤＢ管理処理の詳細については、図１３乃至図１５を参照して後述する。
【０２１１】
このようにして、属性重み算出処理が実行される。
【０２１２】
本発明においては、図１１のフローチャートを参照して上述したように、各ユーザの操作ログDBに基づいて、そのユーザのアイテムに対する評価を推定し、属性重み調整DB１３２のレコードの目標類似度が設定される。そして、図１２のフローチャートを参照して上述したように、目標類似度と、各アトリビュートの類似度とを用いて重回帰分析が行なわれることで、そのユーザの各アトリビュートに対応する重みが求められるようになされている。このようにすることで、個々のユーザにとって最適な重みを自動的に設定できる。
【０２１３】
次に、図１３のフローチャートを参照して、図１２のステップＳ１２７の属性重み調整ＤＢ管理処理の詳細な例について説明する。
【０２１４】
ステップＳ１４１において、属性重み調整エンジン１２９は、属性重み調整DB１３２のレコードのうち、ステップＳ１２１で特定されたメンバーＩＤのレコードのそれぞれの生成日時をチェックする。このとき、例えば、図１０のフィールド「UpdateTime」の日時を特定する情報がチェックされる。
【０２１５】
ステップＳ１４２において、属性重み調整エンジン１２９は、ステップＳ１４１の処理でチェックした生成日時の古い順に、Ｘ％のレコードを特定する。このとき、ステップＳ１２１で特定されたメンバーＩＤのレコードの総数のＸ％（例えば、５０％）が特定される。なお、Ｘの値は予め定められているものとする。
【０２１６】
ステップＳ１４３において、属性重み調整エンジン１２９は、ステップＳ１４２で特定された属性重み調整DB１３２のレコードを削除する。
【０２１７】
このようにして、属性重み調整ＤＢ管理処理が実行される。このように、古いレコードが削除されるようにすることで、当該ユーザの各アトリビュートの重みを、例えば、当該ユーザの嗜好の変化に対応させるように適切に調整することが可能となる。
【０２１８】
ところで、属性重み調整DB１３２のレコードは、上述したように、操作ログDB１２２のレコードに基づいて生成される。従って、ユーザが行なった端末１２１の操作の中で、古い操作に対応して生成された属性重み調整DB１３２のレコードは、その生成日時が古いものとなり、新しい操作に対応して生成された属性重み調整DB１３２のレコードは、その生成日時は新しいものとなる。
【０２１９】
しかし、ユーザの操作の中でも、その操作の内容によってユーザの嗜好に対する重要性は異なるものと考えられる。例えば、ユーザがあるコンテンツのデータを削除不可となるようにプロテクトしたり、「お気に入り」のフォルダに登録するなどの操作を行った場合、そのコンテンツ（アイテム）に対する肯定的な評価がなされたと認識することができる。そして、このような操作には、そのコンテンツに対するユーザの強い嗜好性が感じられ、肯定的な評価を明示する操作ということができる。
【０２２０】
一方、例えば、ユーザがあるコンテンツのデータを再生してコンテンツを視聴した場合、そのコンテンツ（アイテム）に対する肯定的な評価がなされたことを示唆するものであるが、この場合、そのコンテンツに対するユーザの強い嗜好性が感じられるとは断言できない。このような操作は、ユーザが単に、記録されているデータの内容を確認するために行われた可能性があるからである。
【０２２１】
このように、ユーザの操作の中でも、その操作の内容によってユーザの嗜好に対する重要性は異なる。操作の内容によらず、一律に古いデータを削除するようにすると、ユーザの嗜好を適確に認識して重みを調整することができなくなる可能性がある。
【０２２２】
そこで、図１２のステップＳ１２７の属性重み調整ＤＢ管理処理において、操作の内容が考慮されるようにする。例えば、次のようにすることで、図１２のステップＳ１２７の属性重み調整ＤＢ管理処理において、操作の内容が考慮されるようにすることができる。
【０２２３】
図１４は、属性重み調整DB１３２の別の例を示す図である。同図においては、図１０を参照して上述した場合と同様に、各行に示されるデータが属性重み調整ＤＢ１３２のレコードのそれぞれに対応する。この例では、属性重み調整ＤＢ１３２のレコードのそれぞれは、「MemberId」、「TargetScore」、「AttributeScore」、「UpdateTime」、および「利用可能回数」の５つのフィールドにより構成されている。
【０２２４】
図１４の例におけるフィールド「MemberId」、フィールド「TargetScore」、フィールド「AttributeScore」、およびフィールド「UpdateTime」は、図１０を参照して上述した場合と同様であるので、詳細な説明は省略する。
【０２２５】
図１４のフィールド「利用可能回数」は、例えば、当該レコードを、属性重み算出処理に何回利用できるかを表す数値が格納されるフィールドとされる。フィールド「利用可能回数」には、当該レコードが生成されるとき、操作ログＤＢ１２２のレコードにより特定される操作の内容に対応して定まる値が格納される。
【０２２６】
いまの場合、操作ログDB１２２の各レコードのフィールド「LogType」に格納される情報は、例えば、ユーザがあるアイテムの肯定的な評価を明示する操作を行った場合、「good3」となるものとする。そして、例えば、ユーザがあるアイテムの肯定的な評価を示唆する操作を行った場合、その操作に応じて「good2」、または「good1」となるものとする。
【０２２７】
同様に、例えば、ユーザがあるアイテムに対応するコンテンツのデータを削除する操作などを行った場合、ユーザがあるアイテムの否定的な評価を明示する操作を行った場合、「bad3」となるものとする。そして、例えば、ユーザがあるアイテムの否定的な評価を示唆する操作を行った場合、その操作に応じて「bad2」、または「bad1」となるものとする。
【０２２８】
そして、属性重み調整ＤＢ１３２のレコードが生成されるとき、例えば、操作ログDB１２２のレコードのフィールド「LogType」に格納される情報が「good3」であった場合、フィールド「利用可能回数」には、「３」が格納される。同様に、属性重み調整ＤＢ１３２のレコードが生成されるとき、例えば、操作ログDB１２２のレコードのフィールド「LogType」に格納される情報が「good2」または「good1」であった場合、フィールド「利用可能回数」には、「２」または「１」が格納される。
【０２２９】
また、属性重み調整ＤＢ１３２のレコードが生成されるとき、例えば、操作ログDB１２２のレコードのフィールド「LogType」に格納される情報が「bad3」であった場合、フィールド「利用可能回数」には、「３」が格納される。同様に、属性重み調整ＤＢ１３２のレコードが生成されるとき、例えば、操作ログDB１２２のレコードのフィールド「LogType」に格納される情報が「bad2」または「bad1」であった場合、フィールド「利用可能回数」には、「２」または「１」が格納される。
【０２３０】
なお、上で説明した操作ログDB１２２のレコードのフィールド「LogType」に格納される情報「good3」、「good2」、「good1」、「bad3」、「bad2」、「bad1」などは、あくまで説明のための例であり、実際に格納される情報はこれらとは異なるものであってもよい。要は、操作の内容に応じてフィールド「利用可能回数」に格納する値を特定することができればよいのである。
【０２３１】
属性重み調整ＤＢ管理処理において、操作の内容が考慮されるようにする場合、属性重み調整DB１３２は、図１４のように構成されているものとし、図１４の属性重み調整DB１３２を用いて図１１と図１２の処理が実行されるものとする。
【０２３２】
ここで、図１５のフローチャートを参照して、図１２のステップＳ１２７の属性重み調整ＤＢ管理処理の別の詳細な例について説明する。この処理は、属性重み調整ＤＢ管理処理において、操作の内容が考慮されるようにする場合の例である。
【０２３３】
ステップＳ１６１において、属性重み調整エンジン１２９は、属性重み調整DB１３２のレコードのうち、ステップＳ１２１で特定されたメンバーＩＤのレコードのそれぞれの利用可能回数を更新する。このとき、例えば、ステップＳ１２１で特定されたメンバーＩＤの全レコードのそれぞれについて、図１４のフィールド「利用可能回数」に格納された値が１だけデクリメントされる。
【０２３４】
ステップＳ１６２において、属性重み調整エンジン１２９は、ステップＳ１６１の処理によって更新された利用可能回数が「０」となったレコードを特定する。例えば、図１４の第３行目に記載のレコードは、現在の利用可能回数の値が「２」であるから、ステップＳ１６１の処理で更新された結果、利用可能回数の値は「１」となる。例えば、図１４の第４行目に記載のレコードは、現在の利用可能回数の値が「３」であるから、ステップＳ１６１の処理で更新された結果、利用可能回数の値は「２」となる。
【０２３５】
また、図１４の第２行目、第５行目、第６行目、・・・に記載のレコードは、現在の利用可能回数の値が「１」であるから、ステップＳ１６１の処理で更新された結果、利用可能回数の値は「０」となる。ステップＳ１６２では、例えば、図１４の第２行目、第５行目、第６行目、・・・に記載のレコードが特定されることになる。
【０２３６】
ステップＳ１６３において、属性重み調整エンジン１２９は、ステップＳ１６２の処理で特定されたレコードを削除する。
【０２３７】
このようにして、属性重み調整ＤＢ管理処理が実行される。このように、操作の内容に対応して定まる利用可能回数の値に基づいて、当該レコードを削除するか否かが判定されるようにしたので、属性重み調整ＤＢ管理処理において、操作の内容が考慮されるようにすることができる。その結果、ユーザの嗜好が常に適切に反映された、属性重み調整DB１３２を構築することが可能となり、当該ユーザの各アトリビュートの重みを、より適切に調整することが可能となる。
【０２３８】
なお、上述した一連の処理は、ハードウェアにより実行させることもできるし、ソフトウェアにより実行させることもできる。上述した一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、専用のハードウェアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば図１６に示されるような汎用のパーソナルコンピュータ７００などに、ネットワークや記録媒体からインストールされる。
【０２３９】
図１６において、CPU（Central Processing Unit）７０１は、ROM（Read Only Memory）７０２に記憶されているプログラム、または記憶部７０８からRAM（Random Access Memory）７０３にロードされたプログラムに従って各種の処理を実行する。RAM７０３にはまた、CPU７０１が各種の処理を実行する上において必要なデータなども適宜記憶される。
【０２４０】
CPU７０１、ROM７０２、およびRAM７０３は、バス７０４を介して相互に接続されている。このバス７０４にはまた、入出力インタフェース７０５も接続されている。
【０２４１】
入出力インタフェース７０５には、キーボード、マウスなどよりなる入力部７０６、CRT(Cathode Ray Tube)、ＬＣＤ(Liquid Crystal display)などよりなるディスプレイ、並びにスピーカなどよりなる出力部７０７、ハードディスクなどより構成される記憶部７０８、モデム、LANカードなどのネットワークインタフェースカードなどより構成される通信部７０９が接続されている。通信部７０９は、インターネットを含むネットワークを介しての通信処理を行う。
【０２４２】
入出力インタフェース７０５にはまた、必要に応じてドライブ７１０が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア７１１が適宜装着され、それらから読み出されたコンピュータプログラムが、必要に応じて記憶部７０８にインストールされる。
【０２４３】
上述した一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、インターネットなどのネットワークや、リムーバブルメディア７１１などからなる記録媒体からインストールされる。
【０２４４】
なお、この記録媒体は、図１６に示される、装置本体とは別に、ユーザにプログラムを配信するために配布される、プログラムが記録されている磁気ディスク（フロッピディスク（登録商標）を含む）、光ディスク（CD-ROM(Compact Disk-Read Only Memory),DVD(Digital Versatile Disk)を含む）、光磁気ディスク（MD（Mini-Disk）（登録商標）を含む）、もしくは半導体メモリなどよりなるリムーバブルメディア７１１により構成されるものだけでなく、装置本体に予め組み込まれた状態でユーザに配信される、プログラムが記録されているROM７０２や、記憶部７０８に含まれるハードディスクなどで構成されるものも含む。
【０２４５】
なお、本明細書において上述した一連の処理は、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
【図面の簡単な説明】
【０２４６】
【図１】本発明の一実施の形態に係る推薦システムの構成例を示すブロック図である。
【図２】図１の操作ログＤＢの構成を示す図である。
【図３】アイテムメタ情報の例を示す図である。
【図４】図１のアイテムメタＤＢの例を示す図である。
【図５】図１のユーザ嗜好ＤＢの例を示す図である。
【図６】図１の推薦システムによる推薦リスト生成処理の例を説明するフローチャートである。
【図７】マッチング処理の例を説明するフローチャートである。
【図８】本発明の一実施の形態に係る推薦システムの別の構成例を示すブロック図である。
【図９】図８の属性重みＤＢの例を示す図である。
【図１０】図８の属性重み調整ＤＢの例を示す図である。
【図１１】属性重み調整ＤＢ生成処理を説明するフローチャートである。
【図１２】属性重み算出処理を説明するフローチャートである。
【図１３】属性重み調整ＤＢ管理処理の例を説明するフローチャートである。
【図１４】図８の属性重み調整ＤＢの別の例を示す図である。
【図１５】属性重み調整ＤＢ管理処理の別の例を説明するフローチャートである。
【図１６】パーソナルコンピュータの構成例を示すブロック図である。
【符号の説明】
【０２４７】
１０  推薦システム，  ２１  端末，  ２２  操作ログＤＢ，  ２３  アイテムメタＤＢ，  ２４  嗜好抽出エンジン，  ２５  ユーザ嗜好ＤＢ，  ２６  推薦エンジン，  ２７  基軸・反転要素抽出部，  ２８  成熟度算出エンジン，  １００  推薦システム，  １２１  端末，  １２２  操作ログＤＢ，  １２３  アイテムメタＤＢ，  １２５  ユーザ嗜好ＤＢ，  １２６  推薦エンジン，  １２９  属性重み調整エンジン，  １３１  属性重みＤＢ，  １３２  属性重み調整ＤＢ
【図１】
2010061601.tif 000004
【図２】
2010061601.tif 000005
【図３】
2010061601.tif 000006
【図４】
2010061601.tif 000007
【図５】
2010061601.tif 000008
【図６】
2010061601.tif 000009
【図７】
2010061601.tif 000010
【図８】
2010061601.tif 000011
【図９】
2010061601.tif 000012
【図１０】
2010061601.tif 000013
【図１１】
2010061601.tif 000014
【図１２】
2010061601.tif 000015
【図１３】
2010061601.tif 000016
【図１４】
2010061601.tif 000017
【図１５】
2010061601.tif 000018
【図１６】
2010061601.tif 000019