JP2010061601A - 推薦装置および方法、プログラム、並びに記録媒体 - Google Patents

推薦装置および方法、プログラム、並びに記録媒体 Download PDF

Info

Publication number
JP2010061601A
JP2010061601A JP2008229313A JP2008229313A JP2010061601A JP 2010061601 A JP2010061601 A JP 2010061601A JP 2008229313 A JP2008229313 A JP 2008229313A JP 2008229313 A JP2008229313 A JP 2008229313A JP 2010061601 A JP2010061601 A JP 2010061601A
Authority
JP
Japan
Prior art keywords
user
item
information
preference information
record
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2008229313A
Other languages
English (en)
Other versions
JP4650541B2 (ja
Inventor
Hiroyuki Masuda
弘之 増田
Naoki Kamimaeda
直樹 上前田
Takehiro Hagiwara
丈博 萩原
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Original Assignee
Sony Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Corp filed Critical Sony Corp
Priority to JP2008229313A priority Critical patent/JP4650541B2/ja
Priority to US12/553,257 priority patent/US8214318B2/en
Priority to CN2009101717970A priority patent/CN101674458B/zh
Publication of JP2010061601A publication Critical patent/JP2010061601A/ja
Application granted granted Critical
Publication of JP4650541B2 publication Critical patent/JP4650541B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/173—Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
    • H04N7/17309—Transmission or handling of upstream communications
    • H04N7/17318—Direct or substantially direct transmission and handling of requests
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/258—Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
    • H04N21/25866—Management of end-user data
    • H04N21/25891—Management of end-user data being end-user preferences
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/466—Learning process for intelligent management, e.g. learning user preferences for recommending movies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/466—Learning process for intelligent management, e.g. learning user preferences for recommending movies
    • H04N21/4667—Processing of monitored end-user data, e.g. trend analysis based on the log file of viewer selections
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/466—Learning process for intelligent management, e.g. learning user preferences for recommending movies
    • H04N21/4668—Learning process for intelligent management, e.g. learning user preferences for recommending movies for recommending content, e.g. movies

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Graphics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

【課題】ユーザの嗜好を構成する個々の属性、要素などの重要性を、常に適切に反映させた推薦を行なうことができるようにする。
【解決手段】属性重み調整エンジン１２９は、属性重み調整エンジン１２９は、属性重み調整DB１３２に記憶されているレコードであって、特定されたメンバーＩＤのレコードに基づいて当該ユーザの重みの調整を行う。ここで、重みの調整は、属性重み調整DB１３２のレコードから得られる目標類似度と属性重み調整DB１３２のレコードから得られる各アトリビュートの類似度を用いた重回帰分析によりなされ、得られた重みが、特定されたユーザの各アトリビュートの重みとして特定される。ユーザの各アトリビュートの重みを反映させるべく、属性重みＤＢ１３１が更新され、属性重み調整ＤＢ１３２の中の不要なレコードが削除される。
【選択図】図８

Description

本発明は、推薦装置および方法、プログラム、並びに記録媒体に関し、特に、ユーザの嗜好を構成する個々の属性、要素などの重要性を、常に適切に反映させた推薦を行なうことができるようにする推薦装置および方法、プログラム、並びに記録媒体に関する。
従来より、録画された番組などのコンテンツをユーザに推薦する技術が開発されている。コンテンツの推薦は、例えば、コンテンツのメタデータに含まれる属性のそれぞれを要素するベクトルと、そのベクトルと同じ要素数のベクトルとして構成されるユーザ嗜好情報とのマッチング処理などにより算出された類似度に基づいて行われる。
また、ＥＰＧデータの供給を受け、必要なメタデータが抽出され、メタデータに含まれている、タイトル、内容などが、形態素解析されて、単語に分解され、それぞれの項目がベクトル化されて番組ベクトルが生成されるようにすることもできる。この際、供給されたメタデータの番組のジャンルに基づいて、対応する効き目ベクトルが抽出され効き目ベクトルと生成されたベクトルとが関連付けされて、処理が終了されるようにする技術も提案されている（例えば、特許文献１参照）。
特開平２００７−２００３３９号公報
しかしながら、従来、ユーザ嗜好情報と番組ベクトルとの類似度を算出する場合、効き目や重みなどは個人によらない共通の固定値が用いられている。しかし、実際にはユーザごとに重要視する属性は異なり、共通の固定値ではこの個人差を補えないため、共通の固定値である効き目や重みを用いて類似度を算出してアイテムを推薦しても、真にユーザの嗜好に合致したアイテムを推薦できないことがある。
また、例えば、予めユーザに自分が重要視する属性（アトリビュート）などを入力させ、その入力結果に応じて個人別に重みを調整する方式もが考えられる。この方式であれば、上述した個人差を補うことも可能である。
しかし、ユーザの嗜好は、極めて抽象的な概念であって本人であっても表現することは難しく、必ずしも自分が重要視する属性（アトリビュート）が簡単に見つかるとは限らない。
さらに、ユーザの嗜好は、時間とともに変化することもある。例えば、放送される番組や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,Ｙ）は、式（１）により演算される。
Figure 2010061601
ここで、Ａは、例えば、基軸ベクトルの要素の集合とされ、ａは、集合Ａに含まれる１つの要素とされる。また、Ｘ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７０２や、記憶部７０８に含まれるハードディスクなどで構成されるものも含む。
なお、本明細書において上述した一連の処理は、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
本発明の一実施の形態に係る推薦システムの構成例を示すブロック図である。 図１の操作ログＤＢの構成を示す図である。 アイテムメタ情報の例を示す図である。 図１のアイテムメタＤＢの例を示す図である。 図１のユーザ嗜好ＤＢの例を示す図である。 図１の推薦システムによる推薦リスト生成処理の例を説明するフローチャートである。 マッチング処理の例を説明するフローチャートである。 本発明の一実施の形態に係る推薦システムの別の構成例を示すブロック図である。 図８の属性重みＤＢの例を示す図である。 図８の属性重み調整ＤＢの例を示す図である。 属性重み調整ＤＢ生成処理を説明するフローチャートである。 属性重み算出処理を説明するフローチャートである。 属性重み調整ＤＢ管理処理の例を説明するフローチャートである。 図８の属性重み調整ＤＢの別の例を示す図である。 属性重み調整ＤＢ管理処理の別の例を説明するフローチャートである。 パーソナルコンピュータの構成例を示すブロック図である。
符号の説明
１０ 推薦システム， ２１ 端末， ２２ 操作ログＤＢ， ２３ アイテムメタＤＢ， ２４ 嗜好抽出エンジン， ２５ ユーザ嗜好ＤＢ， ２６ 推薦エンジン， ２７ 基軸・反転要素抽出部， ２８ 成熟度算出エンジン， １００ 推薦システム， １２１ 端末， １２２ 操作ログＤＢ， １２３ アイテムメタＤＢ， １２５ ユーザ嗜好ＤＢ， １２６ 推薦エンジン， １２９ 属性重み調整エンジン， １３１ 属性重みＤＢ， １３２ 属性重み調整ＤＢ

Claims (9)

  1. ユーザの嗜好を表す情報であって複数の要素を有するベクトルとして構成されるユーザ嗜好情報、および推薦の対象となるアイテムのそれぞれのメタ情報に基づいて生成され、それぞれ前記ユーザ嗜好情報の要素と同数の要素を有するベクトルとして構成されるアイテム嗜好情報の要素毎の類似度に重み係数をそれぞれ乗じた値、並びに前記アイテムに対する前記ユーザの操作の内容に応じて定まる評価値の目標値を対応付けた調整情報を生成して記憶する調整情報記憶手段と、
    複数の前記調整情報を用いた重回帰分析により前記ユーザ嗜好情報の要素のそれぞれに乗じられる重み係数のそれぞれを、ユーザ毎に算出する重回帰分析手段と、
    前記算出された重み係数を、前記評価値の算出において、前記ユーザ嗜好情報の要素のそれぞれに乗じられる重み係数として前記ユーザ毎に記憶する重み係数記憶手段と、
    前記ユーザ嗜好情報および前記アイテム嗜好情報のそれぞれの要素、および前記要素に対応する前記重み係数に基づいて演算される前記評価値に基づいて、前記ユーザに推薦する前記アイテムを特定する推薦アイテム特定手段と
    を備える推薦装置。
  2. 予め設定された期間内に生成された前記調整情報が、前記重回帰分析の対象とされる
    請求項１に記載の推薦装置。
  3. 予め定められた周期で、
    前記調整情報を生成して記憶し、
    前記重み係数のそれぞれを、ユーザ毎に算出し、
    前記算出された重み係数を、前記評価値の算出において、前記ユーザ嗜好情報の要素のそれぞれに乗じられる重み係数として前記ユーザ毎に記憶する
    請求項２に記載の推薦装置。
  4. 前記重回帰分析に用いられた前記調整情報を削除する調整情報削除手段をさらに備える
    請求項１に記載の推薦装置。
  5. 前記調整情報削除手段は、
    前記調整情報のうち、生成日時の古い順に所定の割合の前記調整情報を削除する
    請求項４に記載の推薦装置。
  6. 前記調整情報には、前記ユーザの操作の内容に応じて定まる利用回数が含まれ、
    前記調整情報削除手段は、
    前記利用回数分だけ前記重回帰分析に用いられた前記調整情報を削除する
    請求項４に記載の推薦装置。
  7. ユーザの嗜好を表す情報であって複数の要素を有するベクトルとして構成されるユーザ嗜好情報、および推薦の対象となるアイテムのそれぞれのメタ情報に基づいて生成され、それぞれ前記ユーザ嗜好情報の要素と同数の要素を有するベクトルとして構成されるアイテム嗜好情報の要素毎の類似度に重み係数をそれぞれ乗じた値、並びに前記アイテムに対する前記ユーザの操作の内容に応じて定まる評価値の目標値を対応付けた調整情報を生成して記憶し、
    複数の前記調整情報を用いた重回帰分析により前記ユーザ嗜好情報の要素のそれぞれに乗じられる重み係数のそれぞれを、ユーザ毎に算出し、
    前記算出された重み係数を、前記評価値の算出において、前記ユーザ嗜好情報の要素のそれぞれに乗じられる重み係数として前記ユーザ毎に記憶し、
    前記ユーザ嗜好情報および前記アイテム嗜好情報のそれぞれの要素、および前記要素に対応する前記重み係数に基づいて演算される前記評価値に基づいて、前記ユーザに推薦する前記アイテムを特定する
    推薦方法。
  8. コンピュータを、
    ユーザの嗜好を表す情報であって複数の要素を有するベクトルとして構成されるユーザ嗜好情報、および推薦の対象となるアイテムのそれぞれのメタ情報に基づいて生成され、それぞれ前記ユーザ嗜好情報の要素と同数の要素を有するベクトルとして構成されるアイテム嗜好情報の要素毎の類似度に重み係数をそれぞれ乗じた値、並びに前記アイテムに対する前記ユーザの操作の内容に応じて定まる評価値の目標値を対応付けた調整情報を生成して記憶する調整情報記憶手段と、
    複数の前記調整情報を用いた重回帰分析により前記ユーザ嗜好情報の要素のそれぞれに乗じられる重み係数のそれぞれを、ユーザ毎に算出する重回帰分析手段と、
    前記算出された重み係数を、前記評価値の算出において、前記ユーザ嗜好情報の要素のそれぞれに乗じられる重み係数として前記ユーザ毎に記憶する重み係数記憶手段と、
    前記ユーザ嗜好情報および前記アイテム嗜好情報のそれぞれの要素、および前記要素に対応する前記重み係数に基づいて演算される前記評価値に基づいて、前記ユーザに推薦する前記アイテムを特定する推薦アイテム特定手段とを備える推薦装置として機能させる
    プログラム。
  9. 請求項８に記載のプログラムが記録されている記録媒体。
JP2008229313A 2008-09-08 2008-09-08 推薦装置および方法、プログラム、並びに記録媒体 Expired - Fee Related JP4650541B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2008229313A JP4650541B2 (ja) 2008-09-08 2008-09-08 推薦装置および方法、プログラム、並びに記録媒体
US12/553,257 US8214318B2 (en) 2008-09-08 2009-09-03 Apparatus, method and computer program for content recommendation and recording medium
CN2009101717970A CN101674458B (zh) 2008-09-08 2009-09-08 用于内容推荐的设备和方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2008229313A JP4650541B2 (ja) 2008-09-08 2008-09-08 推薦装置および方法、プログラム、並びに記録媒体

Publications (2)

Publication Number Publication Date
JP2010061601A true JP2010061601A (ja) 2010-03-18
JP4650541B2 JP4650541B2 (ja) 2011-03-16

Family

ID=42008098

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008229313A Expired - Fee Related JP4650541B2 (ja) 2008-09-08 2008-09-08 推薦装置および方法、プログラム、並びに記録媒体

Country Status (3)

Country Link
US (1) US8214318B2 (ja)
JP (1) JP4650541B2 (ja)
CN (1) CN101674458B (ja)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011210090A (ja) * 2010-03-30 2011-10-20 Nec Corp 情報推薦装置、情報推薦方法およびプログラム
JP2012141724A (ja) * 2010-12-28 2012-07-26 Jvc Kenwood Corp 情報処理方法、情報処理装置、及び情報処理プログラム
JP2015095009A (ja) * 2013-11-11 2015-05-18 インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ 情報処理装置、情報処理方法、及びプログラム
WO2015102429A1 (ko) * 2014-01-03 2015-07-09 에스케이플래닛 주식회사 전자상거래 서비스 시스템, 그의 사용자 로그 기반 상품 추천 방법 및 연관 상품 판매를 위한 방법
WO2017199415A1 (ja) * 2016-05-20 2017-11-23 富士通株式会社 表示制御プログラム、表示制御装置及び表示制御方法
EP3249598A1 (en) 2016-05-23 2017-11-29 Fuji Xerox Co., Ltd. Program, product recommendation system, and product recommendation method
JP7417889B2 (ja) 2019-10-21 2024-01-19 パナソニックＩｐマネジメント株式会社 コンテンツ推薦システム

Families Citing this family (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8301624B2 (en) * 2009-03-31 2012-10-30 Yahoo! Inc. Determining user preference of items based on user ratings and user features
JP5962926B2 (ja) * 2011-03-03 2016-08-03 日本電気株式会社 レコメンダシステム、レコメンド方法、及びプログラム
WO2012173672A1 (en) * 2011-06-13 2012-12-20 United Video Properties, Inc. Systems and methods for transmitting content metadata from multiple data records
US20130159291A1 (en) * 2011-12-14 2013-06-20 Microsoft Corporation Ranking search results using weighted topologies
US9633118B2 (en) * 2012-03-13 2017-04-25 Microsoft Technology Licensing, Llc. Editorial service supporting contrasting content
CN103902607A (zh) * 2012-12-28 2014-07-02 佳能株式会社 信息处理方法、信息处理设备及信息系统
US9384242B1 (en) * 2013-03-14 2016-07-05 Google Inc. Discovery of news-related content
US20150213018A1 (en) * 2014-01-24 2015-07-30 Google Inc. Method for recommending videos to add to a playlist
US9525899B2 (en) * 2014-04-28 2016-12-20 Rovi Guides, Inc. Methods and systems for preventing a user from terminating services based on a consumption rate of the user
US9729933B2 (en) * 2014-06-30 2017-08-08 Rovi Guides, Inc. Systems and methods for loading interactive media guide data based on user history
CN104036045B (zh) * 2014-07-01 2018-04-03 彩带网络科技（北京）有限公司 一种信息分析方法及服务平台
CN104965889B (zh) * 2015-06-17 2017-06-13 腾讯科技（深圳）有限公司 内容推荐方法及装置
RU2632131C2 (ru) 2015-08-28 2017-10-02 Общество С Ограниченной Ответственностью "Яндекс" Способ и устройство для создания рекомендуемого списка содержимого
RU2632100C2 (ru) 2015-09-28 2017-10-02 Общество С Ограниченной Ответственностью "Яндекс" Способ и сервер создания рекомендованного набора элементов
RU2629638C2 (ru) 2015-09-28 2017-08-30 Общество С Ограниченной Ответственностью "Яндекс" Способ и сервер создания рекомендуемого набора элементов для пользователя
RU2632144C1 (ru) 2016-05-12 2017-10-02 Общество С Ограниченной Ответственностью "Яндекс" Компьютерный способ создания интерфейса рекомендации контента
RU2632132C1 (ru) 2016-07-07 2017-10-02 Общество С Ограниченной Ответственностью "Яндекс" Способ и устройство для создания рекомендаций содержимого в системе рекомендаций
RU2636702C1 (ru) 2016-07-07 2017-11-27 Общество С Ограниченной Ответственностью "Яндекс" Способ и устройство для выбора сетевого ресурса в качестве источника содержимого для системы рекомендаций
CN106507145A (zh) * 2016-11-08 2017-03-15 天脉聚源(北京)传媒科技有限公司 一种基于人物特征的直播切换方法及系统
USD882600S1 (en) 2017-01-13 2020-04-28 Yandex Europe Ag Display screen with graphical user interface
CN107562848B (zh) * 2017-08-28 2020-07-14 广州优视网络科技有限公司 一种视频推荐方法和装置
CN110046006A (zh) * 2018-01-15 2019-07-23 北京京东尚科信息技术有限公司 菜单排序的方法和装置
CN108197335B (zh) * 2018-03-09 2020-06-12 中国人民解放军国防科技大学 一种基于用户行为个性化查询推荐方法及装置
RU2720952C2 (ru) 2018-09-14 2020-05-15 Общество С Ограниченной Ответственностью "Яндекс" Способ и система для создания рекомендации цифрового содержимого
RU2714594C1 (ru) 2018-09-14 2020-02-18 Общество С Ограниченной Ответственностью "Яндекс" Способ и система определения параметра релевантность для элементов содержимого
RU2720899C2 (ru) 2018-09-14 2020-05-14 Общество С Ограниченной Ответственностью "Яндекс" Способ и система для определения зависящих от пользователя пропорций содержимого для рекомендации
RU2725659C2 (ru) 2018-10-08 2020-07-03 Общество С Ограниченной Ответственностью "Яндекс" Способ и система для оценивания данных о взаимодействиях пользователь-элемент
RU2731335C2 (ru) 2018-10-09 2020-09-01 Общество С Ограниченной Ответственностью "Яндекс" Способ и система для формирования рекомендаций цифрового контента
RU2757406C1 (ru) 2019-09-09 2021-10-15 Общество С Ограниченной Ответственностью «Яндекс» Способ и система для обеспечения уровня сервиса при рекламе элемента контента
CN111651678B (zh) * 2020-06-18 2023-12-22 达观数据有限公司 一种基于知识图谱的个性化推荐方法
CN113139769B (zh) * 2021-04-21 2023-02-14 平安壹钱包电子商务有限公司 采购方案智能推荐方法、装置、计算机设备及存储介质
WO2023197204A1 (en) * 2022-04-13 2023-10-19 Comcast Cable Communications, Llc Managing transmission resources

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001075889A (ja) * 1999-09-07 2001-03-23 Nippon Telegr & Teleph Corp <Ntt> 文書表示方法及び文書表示プログラムを格納した記憶媒体
JP2004192460A (ja) * 2002-12-12 2004-07-08 Sony Corp 情報処理装置および情報処理方法、記録媒体、並びにプログラム
JP2005190421A (ja) * 2003-12-26 2005-07-14 Toshiba Corp コンテンツ提供装置と方法、およびプログラム

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20050085287A (ko) * 2002-12-04 2005-08-29 코닌클리케 필립스 일렉트로닉스 엔.브이. 유사한 시청 습관을 갖고 있는 사용자의 사용자 프로파일에기초한 비디오 콘텐트의 추천 방법
WO2004082257A2 (en) * 2003-03-11 2004-09-23 Koninklijke Philips Electronics N.V. Generation of television recommendations via non-categorical information
JP4428036B2 (ja) * 2003-12-02 2010-03-10 ソニー株式会社 情報処理装置および方法、プログラム、並びに、情報処理システムおよび方法
CN1629884A (zh) * 2003-12-15 2005-06-22 皇家飞利浦电子股份有限公司 一种信息推荐系统及方法
JP2006048320A (ja) * 2004-08-04 2006-02-16 Sony Corp 情報処理装置および方法、記録媒体、並びにプログラム
WO2006064877A1 (ja) * 2004-12-17 2006-06-22 Matsushita Electric Industrial Co., Ltd. コンテンツ推薦装置
US7461061B2 (en) * 2006-04-20 2008-12-02 Veveo, Inc. User interface methods and systems for selecting and presenting content based on user navigation and selection actions associated with the content
US8078884B2 (en) * 2006-11-13 2011-12-13 Veveo, Inc. Method of and system for selecting and presenting content based on user identification
JP4501948B2 (ja) 2007-03-05 2010-07-14 ソニー株式会社 情報処理装置および情報処理方法、記録媒体、並びにプログラム
US7904530B2 (en) * 2008-01-29 2011-03-08 Palo Alto Research Center Incorporated Method and apparatus for automatically incorporating hypothetical context information into recommendation queries
US8037011B2 (en) * 2008-09-15 2011-10-11 Motorola Mobility, Inc. Method and apparatus for recommending content items

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001075889A (ja) * 1999-09-07 2001-03-23 Nippon Telegr & Teleph Corp <Ntt> 文書表示方法及び文書表示プログラムを格納した記憶媒体
JP2004192460A (ja) * 2002-12-12 2004-07-08 Sony Corp 情報処理装置および情報処理方法、記録媒体、並びにプログラム
JP2005190421A (ja) * 2003-12-26 2005-07-14 Toshiba Corp コンテンツ提供装置と方法、およびプログラム

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011210090A (ja) * 2010-03-30 2011-10-20 Nec Corp 情報推薦装置、情報推薦方法およびプログラム
JP2012141724A (ja) * 2010-12-28 2012-07-26 Jvc Kenwood Corp 情報処理方法、情報処理装置、及び情報処理プログラム
JP2015095009A (ja) * 2013-11-11 2015-05-18 インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ 情報処理装置、情報処理方法、及びプログラム
WO2015102429A1 (ko) * 2014-01-03 2015-07-09 에스케이플래닛 주식회사 전자상거래 서비스 시스템, 그의 사용자 로그 기반 상품 추천 방법 및 연관 상품 판매를 위한 방법
WO2017199415A1 (ja) * 2016-05-20 2017-11-23 富士通株式会社 表示制御プログラム、表示制御装置及び表示制御方法
EP3249598A1 (en) 2016-05-23 2017-11-29 Fuji Xerox Co., Ltd. Program, product recommendation system, and product recommendation method
JP7417889B2 (ja) 2019-10-21 2024-01-19 パナソニックＩｐマネジメント株式会社 コンテンツ推薦システム

Also Published As

Publication number Publication date
JP4650541B2 (ja) 2011-03-16
CN101674458A (zh) 2010-03-17
US8214318B2 (en) 2012-07-03
CN101674458B (zh) 2012-06-20
US20100070454A1 (en) 2010-03-18

Similar Documents

Publication Publication Date Title
JP4650541B2 (ja) 推薦装置および方法、プログラム、並びに記録媒体
JP4678546B2 (ja) 推薦装置および方法、プログラム、並びに記録媒体
US20220035827A1 (en) Tag selection and recommendation to a user of a content hosting service
JP5740814B2 (ja) 情報処理装置および方法
KR101061234B1 (ko) 정보처리 장치와 방법, 및 기록 매체
US8611676B2 (en) Information processing apparatus, feature extraction method, recording media, and program
US20090006368A1 (en) Automatic Video Recommendation
JP6261547B2 (ja) 判定装置、判定方法及び判定プログラム
US20090063568A1 (en) Method and apparatus for constructing user profile using content tag, and method for content recommendation using the constructed user profile
JP2006048286A (ja) 情報処理装置および方法、並びにプログラム
CN109165302A (zh) 多媒体文件推荐方法及装置
EP2973351A2 (en) Taste profile attributes
JP2011145742A (ja) 情報処理装置、情報処理方法、およびプログラム
WO2007013390A1 (ja) 情報処理装置、特徴抽出方法、記録媒体、および、プログラム
KR20120049551A (ko) 사용자 선호도와 컨텐츠 내용을 고려한 컨텐츠 추천 방법
JP2017201535A (ja) 判定装置、学習装置、判定方法及び判定プログラム
KR20090020005A (ko) 영상 정보 기반의 동영상 연관 검색 시스템 및 방법
JP2004362019A (ja) 情報推薦装置、情報推薦方法、情報推薦プログラム及び記録媒体
KR20120049550A (ko) 시간에 따라 변화하는 사용자 선호도를 고려한 컨텐츠 추천 방법
JP2007233515A (ja) 情報処理装置および情報処理方法、提供装置および提供方法、並びにプログラム
JP2005018205A (ja) 楽曲検索システム、楽曲検索方法、及び楽曲検索装置
JP5625792B2 (ja) 情報処理装置、潜在特徴量算出方法、及びプログラム
JP2006323732A (ja) 情報センタ、端末装置、情報送信プログラム、及び情報選択プログラム
JP2000348039A (ja) 情報提供方式及びその方式を用いた情報提供装置
JP2005275505A (ja) 情報処理装置および方法、プログラム

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100601

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100702

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100729

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100830

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20101116

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20101129

R151 Written notification of patent or utility model registration

Ref document number: 4650541

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20131224

Year of fee payment: 3

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees