JP2010066837A - 情報処理装置および方法、プログラム、並びに記録媒体 - Google Patents

Abstract

【課題】推薦精度を向上させる。
【解決手段】操作ログデータベース３１には、ユーザが行った操作に関するログが書き込まれている。ログとして残されるのは、番組を録画した、視聴したといった操作である。そのような操作の内容や回数により、所定の番組に対するアクティブ度が算出される。このようなアクティブ度、所定の番組がシリーズに属するか否かといった情報、さらにユーザの嗜好に関する情報が用いられて、ユーザに推薦する番組が抽出される。本発明は、テレビジョン放送の番組を処理できるパーソナルコンピュータになどに適用できる。
【選択図】図１

Description

本発明は情報処理装置および方法、プログラム、並びに記録媒体に関し、特に、所定のアイテムの推薦に係わる処理を、より適切にできるようにした情報処理装置および方法、プログラム、並びに記録媒体に関する。

近年、所定のアイテム、例えば、テレビジョン放送の番組を推薦するといった、推薦システムが普及しつつある。推薦システムには大きく分けて、「ユーザの嗜好を用いて推薦を行うもの」と「ユーザの短期的な興味や習慣性をとらえ、推薦を行うもの」の二つが存在していた。（例えば、特許文献１乃至３参照）

従来の推薦システムにおける嗜好をベースとした推薦では、ユーザが視聴や購入等のアクションを起こしたアイテムに付与されているメタデータを元にユーザの嗜好が学習されていた。そして、学習された嗜好と推薦対象とされる各アイテムに付与されたメタデータを元に、例えば、マッチングなどの処理が行われることで、推薦アイテムが決定されていた。

また、従来の推薦システムにおけるユーザの短期的な興味や習慣性をとらえ、推薦を行う推薦では、ユーザの習慣に基づいて、連続ドラマの次回番組やシリーズの次回番組が推薦されていた。
特開２００７−０４３４７１号公報 特開２００７−３２３３９８号公報 特開２００４−１９２４６０号公報

嗜好をベースとした推薦では、ユーザの嗜好にマッチしたアイテムの推薦はある程度可能だが、ユーザが見ている連続ドラマの次回番組やシリーズものの次回番組を的確に推薦することができない場合があった。これは、例えば、アイテムに付与されているメタデータにより提供される情報が少なく、少ない情報に基づいてマッチングなどの処理が行われ、その結果として誤ったアイテムが選択されてしまうことが１つの要因である。本来、ユーザに推薦されても良いアイテムが、メタデータの情報が少ないために、メタデータの情報が多い他のアイテムが選択され、推薦されてしまうことがあった。

ユーザの短期的な興味や習慣性をとらえ、推薦を行う場合、ユーザの短期的な興味や習慣性として、例えば、月曜の夜８時からの番組を毎週録画しているといった情報が用いられる。この場合、月曜の夜８時からの番組を推薦することができ、その時間帯に放送されている番組が、連続ドラマの次回番組やシリーズものであれば、的確に推薦できることになる。

しかしながら、例えば、その時間帯に放送されていた連続ドラマが終了し、次の連続ドラマは、ユーザの嗜好にマッチしていないような番組であっても、ユーザに推薦されてしまう。また、ユーザがたまたま興味があった録画予約した番組の情報、換言すれば、短期的な興味で録画予約した番組の情報、例えば、時間帯や放送局といった情報が用いられた推薦が行われると、興味のない番組であっても、時間帯や放送局が一致することで誤った推薦が行われてしまう。このように、短期的な興味や習慣性をとらえ、推薦を行う場合、必ずしもユーザの嗜好にマッチするものを推薦することができなかった。

本発明は、このような状況に鑑みてなされたものであり、ユーザの嗜好だけでなく、短期的な興味や習慣性もとらえ、推薦を行うことができるようにするものである。

本発明の一側面の情報処理装置は、所定のアイテムに対して行った操作内容から算出される度数と、前記アイテムが属するシリーズを関連付けて管理する管理手段と、前記度数をソートしたときの上位Ｎ個のシリーズと同じシリーズに属するアイテムを、複数のアイテムのなかから抽出する第１の抽出手段と、ユーザの嗜好を管理する嗜好管理手段と、前記嗜好管理手段により管理されている前記嗜好と、アイテムとの類似度を計算し、類似度の高い複数のアイテムを抽出する第２の抽出手段と、第１の抽出手段により抽出されたアイテムと、第２の抽出手段により抽出されたアイテムのうちの所定数のアイテムを、ユーザに推薦する推薦手段とを備える。

前記度数は、前記アイテムを録画した、視聴した、他の装置に転送したという操作にそれぞれ設定されている値を加算することで算出されるようにすることができる。

前記度数は、所定の間隔毎に減衰されるようにすることができる。

シリーズで視聴した方が良い度合いを示す値を算出し、前記第２の抽出手段で抽出されたアイテムの類似度に乗算する乗算手段をさらに備えるようにすることができる。

本発明の一側面の情報処理方法は、記憶手段に記憶されている所定のアイテムに対して行った操作内容から算出される度数と、前記アイテムが属するシリーズを関連付けた情報を参照し、前記度数をソートしたときの上位Ｎ個のシリーズと同じシリーズに属するアイテムを、複数のアイテムのなかから抽出し、記憶手段に記憶されているユーザの嗜好を参照し、前記嗜好管理手段により管理されている前記嗜好と、アイテムとの類似度を計算し、類似度の高い複数のアイテムを抽出し、それらの抽出されたアイテムを、ユーザに推薦するステップを含む。

本発明の一側面のプログラムは、記憶手段に記憶されている所定のアイテムに対して行った操作内容から算出される度数と、前記アイテムが属するシリーズを関連付けた情報を参照し、前記度数をソートしたときの上位Ｎ個のシリーズと同じシリーズに属するアイテムを、複数のアイテムのなかから抽出し、記憶手段に記憶されているユーザの嗜好を参照し、前記嗜好管理手段により管理されている前記嗜好と、アイテムとの類似度を計算し、類似度の高い複数のアイテムを抽出し、それらの抽出されたアイテムを、ユーザに推薦するステップを含む処理を実行するコンピュータが読み取り可能なプログラム。

本発明の一側面の記録媒体は、前記プログラムを記録している。

本発明の一側面の情報処理装置および方法、並びにプログラムにおいては、所定のアイテムに対して行った操作内容から算出される度数と、アイテムが属するシリーズが関連付けて管理され、その管理されている情報が参照されて、度数をソートしたときの上位Ｎ個のシリーズと同じシリーズに属するアイテムが、複数のアイテムのなかから抽出され、ユーザの嗜好と、アイテムとの類似度が計算され、類似度の高い複数のアイテムが抽出され、それらの抽出されたアイテムが、ユーザに推薦される。

本発明の一側面によれば、アイテムを推薦するとき、ユーザの嗜好だけでなく、短期的な興味や習慣性も考慮した推薦を行うことができる。

以下、発明を実施するための最良の形態（以下、実施の形態とする）について説明する。

［システムの一実施の形態の構成］
図１は、本発明を適用したシステムの一実施の形態構成を示す図である。図１に示したシステムは、ユーザに所定のアイテムを推薦するシステムである。図１に示したシステムは、機器１１、エンジン部１２、およびデータベース部１３を含む構成とされている。

機器１１は、ユーザ側の端末であり、例えば、パーソナルコンピュータ、テレビジョン受像機、ハードディスクレコーダなどの機器である。ここでは、テレビジョン放送の番組を推薦する例を挙げて説明をするため、機器１１としては、テレビジョン放送の番組を受信したり、再生したり、記憶したりするといった番組を処理できる装置である。ここでは、機器１は、パーソナルコンピュータであるとし、このパーソナルコンピュータが、テレビジョン放送の番組を受信したり、録画したりするとして説明を続ける。

エンジン部１２は、複数のエンジンを備え、ユーザの嗜好に関する情報を取得したり、ユーザの嗜好に合致するアイテムを推薦するための処理をしたりする。データベース部１３は、エンジン部１２により取得されたユーザの嗜好に関する情報を記憶したり、エンジン部１２が推薦に関わる処理を実行するときに必要となるデータを記憶したりする。

機器１１とエンジン部１２は、互いにデータ（情報）の授受を行えるように構成され、エンジン部１２とデータベース部１３も、互いにデータ（情報）の授受を行えるように構成されている。例えば、機器１１、エンジン部１２、およびデータベース部１３は、それぞれ互いにデータの授受を行えるように、ネットワークを介して接続されている。

または、機器１１が、エンジン部１２とデータベース部１３を備える構成とすることも可能である。さらには、機器１１が、エンジン部１２を備え、機器１１とデータベース部１３がネットワークを介して接続される形態でも良いし、機器１１とエンジン部１２がネットワークを介して接続され、エンジン部１２とデータベース部１３は、１つの装置として構成される形態でも良い。

また、後述するようにエンジン部１２は複数のエンジンで構成され、データベース部１３は複数のデータベースで構成されるが、それらを構成するエンジンの一部やデータベースの一部を、機器１１が備えるような構成とすることも可能である。

特に、エンジン部１２を構成する機器内情報抽出エンジン２１は、後述するように、機器１１で記憶している情報から、ユーザの嗜好に関する情報を抽出するため、セキュリティの観点から、機器１１が備え、抽出された情報だけを、データベース部１３に供給する形態が好ましい。

［エンジンについて］
エンジン部１２は、機器内情報抽出エンジン２１、アイテム管理エンジン２２、嗜好抽出エンジン２３、マイニングエンジン２４、推薦エンジン２５から構成される。

機器内情報抽出エンジン２１は、機器１１に記憶されている（管理されている）曲、メールなどの情報から、ユーザの嗜好に関する情報を抽出する。機器１１が、上記したようにパーソナルコンピュータである場合、例えば、ネットワークを介してダウンロードした曲や、授受した電子メールのデータなどが記憶されている。曲は、ユーザの嗜好を反映するものであり、例えば、曲の情報を取得することで、ユーザの好きなアーティストやジャンルといったユーザの嗜好を得ることができる。また、電子メールの内容からも、ユーザの嗜好を抽出することができる。よって、このような機器１１に蓄積されている情報を、機器内情報抽出エンジン２１は抽出する。

アイテム管理エンジン２２は、データベース部１３を構成する操作ログデータベース３１を参照し、アクティブ度の計算を実行し、アクティブ度データベース３５を更新する（アクティブ度や各データベースの詳細は後述する）。また、アイテム管理エンジン２２は、アイテム状態管理データベース３４を更新する処理も担当する。

嗜好抽出エンジン２３は、操作ログデータベース３１を参照し、ユーザの嗜好を抽出し、ユーザ嗜好データベース３２や、アイテムメタデータベース３３を更新する。

マイニング（mining）エンジン２４は、アイテムのメタデータを基に、アイテムの特徴量を抽出し、アイテム状態管理データベース３４を更新する。

推薦エンジン２５は、ユーザ嗜好データベース３２とアイテムメタデータベース３３などを参照し、ユーザに推薦するアイテムを決定する。

［データベースについて］
データベース部１３は、操作ログデータベース３１、ユーザ嗜好データベース３２、アイテムメタデータベース３３、アイテム状態管理データベース３４、アクティブ度データベース３５、シリーズ視聴ジャンルマスタデータベース３６、およびＥＰＧ（Electronic Program Guide）管理データベース３７から構成される。

操作ログデータベース３１は、ユーザが機器１１を操作したときに関するログを管理する。図２に、操作ログデータベース３１のデータ構造の一例を示す。図２に示したように操作ログデータベース３１は、“アイテムＩＤ”、ユーザＩＤ“、ログの種類”、および“ログ記録日時”といった情報を関連付けて管理している。

“アイテムＩＤ”という項目の欄には、アイテムに割り振られているＩＤが書き込まれる。ここで、アイテムは、テレビジョン放送の番組なので、各番組に割り振られたＩＤである。なおここでは、アイテムは、テレビジョン放送の番組であるとして説明を続けるが、例えば、ネットワークを介して配信されたり、ＣＤとして販売されたりする音楽、ネットワークを介してい配信されたり、ＤＶＤなどの記録媒体に記録されて販売されたりする映像、ラジオ放送の番組など、アイテムはテレビジョン放送の番組だけに限定されるものではない。アイテムとしては、ユーザに対して推薦できる物や情報を対象とし、そのような対象とされたアイテムを一意に識別できるＩＤが、アイテムＩＤである。

“ユーザＩＤ”という項目の欄には、ユーザ毎に割り振られたＩＤが書き込まれる。ユーザとは、ここでは、機器１１の使用者である。なお、例えば、図１に示した推薦システムを利用するとき、ログインなどのユーザを識別するための処理が行われた後、利用可能とされ、そのログインなどの処理が行われることによりユーザが特定される。その特定されたユーザに割り振られているのがユーザＩＤである。このようなログインなどの処理を行う部分は、図１においては省略してある。

“ログの種類”という項目の欄には、ユーザＩＤで識別されるユーザが行った操作に関するログが書き込まれる。アイテムがテレビジョン放送の番組である場合、ログとして残されるのは、番組を視聴したというログ、番組を録画した（録画予約した）というログ、番組を視聴した後、その番組に対する評価をしたというログ（評価内容のログ）、番組の詳細情報を検索したというログ、録画した番組を機器１１以外の装置に転送したというログなどである。“ログの記録日時”という項目の欄には、操作が行われログが残された日時が書き込まれる。

例えば、図２に示した操作ログデータベース３１の一番上の欄に書き込まれている情報を参照するに、アイテムＩＤが“１００１”、ユーザＩＤが“１”、ログの種類が“録画”、ログの記録日時が“２００７−１２−０５ ０８：３９：４４”が関連付けられて管理されている。このような関連付けから、ユーザＩＤとして“１”が割り振られたユーザが、アイテムＩＤ“１００１”で識別されるアイテム（番組）を、ログの記録日時で表される“２００７−１２−０５ ０８：３９：４４”のときに、ログの種類で表される“録画”という操作を実行したことがわかる。

このように、操作ログデータベース３１は、所定の番組に対してユーザが行った操作を管理するためのデータベースである。このようなデータを管理することで、ユーザが最近どのようなアイテムに興味があるのかといった情報を取得することができる。

詳細は後述するが、例えば、所定のユーザ（ユーザＡとする）が、所定のアイテム（アイテムＡとする）を録画し、視聴し、さらに“良い”といった評価をしたといったログが残っていた場合、そのユーザＡは、アイテムＡが属するジャンル（ジャンルＡとする）の番組が好きであるといった判断を行うことができる。すなわち、この場合、ユーザＡには、ジャンルＡに属する番組を優先的に推薦すればよいことになる。

また、操作ログデータベース３１に書き込まれているログが参照され、後述するアクティブ度は、ユーザが行った操作、例えば、録画や視聴が行われると増加する値とされ、そのようなアクティブ度により推薦するアイテムが決定される。よって、ユーザが録画や視聴などをするほど興味がある番組に関係する番組を推薦することが可能となる。さらにそのアクティブ度は、時間経過と共に、減衰するように設定されるため、時間が経過している操作に対するアクティブ度は、低くなり、過去にユーザが興味を持っていたような番組に関する番組を推薦してしまうと行ったことを防ぐことができる。このような時間経過をみるために、操作ログデータベース３１は、ログ記録日時を管理するように構成されている。

なお、操作ログデータベース３１で管理されているデータの更新、例えば、新たな操作ログの追加といった処理は、機器内情報抽出エンジン２１が、機器１１から操作に関する情報を取得し行うようにしても良い。または、そのような処理を実行するエンジンを新たに設け（図１には不図示）、そのエンジンが行うようにしても良い。さらには、機器１１が、ログインといった処理を行ったときに、操作ログデータベース３１にアクセスし、操作ログを更新するといった処理を行うようにしても良い。

図１に関する説明に戻り、ユーザ嗜好データベース３２は、ユーザの嗜好に関する情報を管理する。図３に、ユーザ嗜好データベース３２のデータ構造の一例を示す。図３に示したようにユーザ嗜好データベース３２は、“ユーザＩＤ”、“属性ＩＤ”、“属性値”、および“重要度”といった情報を関連付けて管理している。

“ユーザＩＤ”という項目の欄には、操作ログデータベース３１の“ユーザＩＤ”という項目と同じく、ユーザ毎に割り振られたＩＤが書き込まれる。

“属性ＩＤ”という項目の欄には、次の項目の“属性値”という項目の欄に書き込まれる情報の属性を表すＩＤが書き込まれる。例えば、“属性値”のところに、“ドラマ”といった属性を示すＩＤが書き込まれるとき、その“ドラマ”は“ジャンル”という属性に属するため、“ジャンル”という属性に割り振られているＩＤが“属性ＩＤ”のところに書き込まれる。すなわち、各属性とは、例えば、ジャンル、人物、キーワードなどであり、それらの属性となりうる情報には予めＩＤが割り振られている。その割り振られているＩＤが書き込まれる。

“属性値”という項目の欄には、各属性値を表すＩＤが書き込まれる。上記したように、“ドラマ”とか、“俳優Ａ”といった具体的な情報に割り振られているＩＤが書き込まれる。“重要度”という項目の欄には、ユーザが、各属性値で表される情報を好んでいる度合いを表す数値が書き込まれる。

例えば、図３に示したユーザ嗜好データベース３２の上から１乃至５行目までの欄に書き込まれている情報を参照するに、ユーザＩＤが“１”には、属性ＩＤとして、“１”（１行目）と“２”（２乃至５行目）が関連付けられている。属性ＩＤが“１”の属性値には“３０”が関連付けられ、重要度には“０．５”が関連付けられている。このことから、例えば、属性ＩＤ“１”が、“ジャンル”という属性を示すＩＤであった場合、そのジャンルという属性に含まれる属性値が“３０”で割り当てられている、例えば、“アクション”といった属性が関連付けられていることがわかる。さらに、ユーザＩＤが“１”で表されるユーザは、“アクション”という“ジャンル”に対して、重要度で表される“０．５”程度、興味を有していると判断できることがわかる。

またユーザＩＤ“１”で表されるユーザは、属性ＩＤ“２”で表される属性に含まれる属性値“２”、“４”、“５２”、“２５６”という属性値が割り振られている情報に対して、それぞれ重要度で表される“０．３”、“１．３”、“４．４”、“１２．４”程度の興味を有していることがわかる。

すなわちこの場合、属性ＩＤ“２”には、属性値“２”、“４”、“５２”、“２５６”が、それぞれ関連付けられている。例えば、属性ＩＤ“２”が、“人物”という属性に割り当てられたＩＤである場合、属性値“２”、“４”、“５２”、“２５６”には、それぞれ、例えば、“俳優Ａ”、“俳優Ｂ”、“歌手Ｃ”、“歌手Ｄ”といった“人物”が割り当てられている。このように、１つの属性ＩＤには、複数の属性値が関連付けられており、ユーザの嗜好に関わる属性ＩＤと属性値が、ユーザ嗜好データベース３２には書き込まれる。

このように、ユーザ嗜好データベース３２には、ユーザ毎に、ユーザの嗜好に関わる情報が書き込まれ、管理される。ユーザ嗜好データベース３２は、嗜好抽出エンジン２３により更新される。

図１に関する説明に戻り、アイテムメタデータベース３３は、アイテムのメタデータに関する情報を管理する。図４に、アイテムメタデータベース３３のデータ構造の一例を示す。図４に示したようにアイテムメタデータベース３３は、“アイテムＩＤ”、“属性ＩＤ”、“属性値”、“更新回数”、および“重要度”といった情報を関連付けて管理している。

“アイテムＩＤ”という項目の欄には、操作ログデータベース３１の“アイテムＩＤ”という項目と同じく、アイテム毎に割り振られたＩＤが書き込まれる。

“属性ＩＤ”と“属性値”という項目の欄には、それぞれユーザ嗜好データベース３２の“属性ＩＤ”と“属性値”という項目と同じく、属性毎に割り振られたＩＤと、その属性に含まれる情報に割り振られた値が書き込まれる。

“更新回数”という項目の欄には、属性値が更新された回数が書き込まれる。また、“重要度”という項目の欄には、属性値に対する重要度が書き込まれる。この重要度は、ユーザ嗜好データベース３２の“重要度”とは異なる。ユーザ嗜好データベース３２の“重要度”は、所定のユーザの、所定の属性ＩＤと属性値で一意に特定される情報に対する重要度であり、このアイテムメタデータベース３３の“重要度”は、所定のアイテムの、所定の属性ＩＤと属性値で一意に特定される情報に対する重要度である。

図４に示したアイテムメタデータベース３３の一番上の欄に記載されている例を参照するに、アイテムＩＤが“１００１”、属性ＩＤが“１”、属性値が“153144”、更新回数が“１”、および重要度が“1.5845”という情報が関連付けられて管理されている。この場合、“１００１”であるアイテムＩＤで特定されるアイテムが“１”である属性ＩＤで特定される属性の属性値は、“153144”であり、その属性値は、“１”回更新され、その属性値の重要度は、“1.5845”であることが、図４のアイテムメタデータベース３３のうちの上側の横１列によって示されいる。

このように、アイテムメタデータベース３３には、アイテム毎に、そのアイテムが属する属性やその重要度といった情報が書き込まれ、管理される。アイテムメタデータベース３３は、嗜好抽出エンジン２３により更新される。嗜好抽出エンジン２３は、ユーザ嗜好データベース３２とアイテムメタデータベース３３を更新するが、ユーザ嗜好データベース３２とアイテムメタデータベース３３が管理している項目、例えばアイテムＩＤなどの項目は、一緒なので、まとめて嗜好抽出エンジン２３が更新するように構成されている。しかしながら、これは一例なので、他のエンジンが管理するようにしても良い。

図１に関する説明に戻り、アイテム状態管理データベース３４は、アイテムの状態を管理するための情報を管理する。図５に、アイテム状態管理データベース３４のデータ構造の一例を示す。図５に示したようにアイテム状態管理データベース３４は、“ユーザＩＤ”、“シリーズＩＤ”、“視聴日”、“視聴放送日”、“予約日”、“録画日”、“放送日”、“録画回数”、“放送回数”、“積算値”、“ユーザ更新日”、および“レコード更新日”といった情報を関連付けて管理している。

“ユーザＩＤ”という項目の欄には、操作ログデータベース３１の“ユーザＩＤ”や、ユーザ嗜好データベース３２の“ユーザＩＤ”という項目と同じく、ユーザ毎に割り振られたＩＤが書き込まれる。

“シリーズＩＤ”という項目の欄には、シリーズを識別するＩＤが書き込まれる。このシリーズを識別するＩＤとは、例えば、テレビジョン放送の番組において、シリーズとして放送される番組に対して、シリーズであることを示すＩＤである。シリーズとは、例えば、毎週、同じチャンネルで、同じ時間帯に放送される、いわゆる連続ドラマといった番組や、クイズ番組といったような番組の一連のまとまりを示す。

例えば、連続ドラマといった番組は、例えば、１５回などと決まった回数を１シリーズとして放送される。ここでは、各回の放送を番組と称し、この番組を複数含む場合をシリーズと称する。連続ドラマを構成する各番組は、同一のシリーズＩＤが付される。以下の説明においては、１５回で１シリーズである番組を、適宜例に挙げながら説明を続ける。

このシリーズＩＤであるが、季節的に放送される、いわゆる特番などと称される特別番組であり、同じような内容（主旨）で放送される番組なども、シリーズとして扱い、同じＩＤが付されるようにしても良い。

また、シリーズでない番組に対するシリーズＩＤは、シリーズでないことを示すＩＤか、または、ＩＤ自体が付与されない。

“視聴日”という項目の欄には、ユーザにより最後に同一のシリーズを構成する番組が視聴された日時が書き込まれる。例えば、１５回の放送予定のシリーズのうちの、３回目（３話）として放送された番組が、そのシリーズを構成する番組のうち、最後にユーザにより視聴された番組であった場合、その３話目の番組が視聴された日時が“視聴日”という項目の欄に書き込まれる。

“視聴放送日”という項目の欄には、ユーザにより最後に視聴された同一シリーズの番組の放送終了日時が書き込まれる。例えば、１５回の放送予定のシリーズのうちの、３回目（３話）として放送された番組が、そのシリーズを構成する番組のうち、最後に視聴された番組であった場合、その３話目の番組が放送された日時が“視聴放送日”という項目の欄に書き込まれる。

“予約日”という項目の欄には、ユーザにより最後に録画予約された同一シリーズの番組の放送終了日時が書き込まれる。例えば、１５回の放送予定のシリーズのうちの、８回目（８話）として放送される番組が、そのシリーズを構成する番組のうち、最後に録画予約された番組であった場合、その８話目の番組が放送された日時（放送される予定の日時）が“予約日”という項目の欄に書き込まれる。

“録画日”という項目の欄には、最後に録画された同一シリーズの番組の放送終了日時が書き込まれる。例えば、１５回の放送予定のシリーズのうちの、６回目（６話）として放送された番組が、そのシリーズを構成する番組のうち、最後に録画された番組であった場合、その６話目の番組が放送された日時が“録画日”という項目の欄に書き込まれる。

“放送日”という項目の欄には、最後に放送された同一シリーズの番組の放送終了日時が書き込まれる。例えば、１５回の放送予定のシリーズのうちの、７回目（７話）として放送された番組が、そのシリーズを構成する番組のうち、最後に放送された番組であった場合、その７話目の番組が放送された日時が“放送日”という項目の欄に書き込まれる。

“録画回数”という項目の欄には、同一シリーズの録画回数が書き込まれる。例えば、１５回の放送予定のシリーズのうちの、３回目（３話）まで放送され、その１乃至３話までの番組が録画された場合、“３”という値が“録画回数”という項目の欄に書き込まれる。

“放送回数”という項目の欄には、同一シリーズの放送回数が書き込まれる。例えば、１５回の放送予定のシリーズのうちの、３回目（３話）まで放送されていた場合、“３”という値が“放送回数”という項目の欄に書き込まれる。

“積算値”という項目の欄には、“放送日”の欄に書き込まれている日時と、番組の放送終了日時の差分を積算した値が書き込まれる。

“ユーザ更新日”という項目の欄には、ユーザが操作を行った最後の日時（直近の操作を行った日時）が書き込まれる。例えば、ユーザの直近の操作が録画予約であった場合、その録画予約の操作がされた日時が“ユーザ更新日”のところに書き込まれる。

“レコード更新日”という項目の欄には、このアイテム状態管理データベース３４で管理している上記情報が更新された日時が書き込まれる。

図５に示したアイテム状態管理データベース３４の一番上の欄に記載されている例を参照するに、ユーザＩＤが“１”、シリーズＩＤが“２”、視聴日が“2008-08-11 10:41:16”、視聴放送日が“0001-01-01 00:00:00”、予約日が“2008-08-12 13:00:00”、録画日が“2008-08-11 03:10:00”、放送日が“2008-08-16 02:55:00”、録画回数が“４”、放送回数が“３６”、積算値が“80229”、ユーザ更新日が”2008-08-11 11:50:13“、およびレコード更新日が”2008-08-11 06:17:21“という情報が関連付けられている。

またここでは、例えば、ユーザが視聴していないなど、日時が書き込めない場合、そのことを表す情報、例えば、“0001-01-01 00:00:00”といった情報が書き込まれる。

このように、アイテム状態管理データベース３４は、ユーザ毎に、各アイテムの状態を示す情報が関連付けられて管理されている。アイテム状態管理データベース３４は、アイテム管理エンジン２２により更新される。

図１に関する説明に戻り、アクティブ度データベース３５は、アクティブ度を管理する。図６に、アクティブ度データベース３５のデータ構造の一例を示す。図６に示したようにアクティブ度データベース３５は、“ユーザＩＤ”、“シリーズＩＤ”、“ファンクションＩＤ”、“アクティブ度”、および“レコード更新日”といった情報を関連付けて管理している。

ここで、アクティブ度とは、ユーザのその時点での興味、嗜好などを測るための指標である。所定の番組を視聴する、録画する、他の装置に転送する、録画されていた番組を削除する、といったユーザのアイテムに対する所定の操作は、その番組に対してユーザが何らかの興味があるから行うのである。

このようなことを考慮すると、ユーザがどのようなアイテムに対してどのような操作を行ったかということから、ユーザの嗜好を抽出することができる。例えば、所定のアイテムを録画し、視聴した場合には、そのアイテムにとても興味があり、そのようなアイテムが、その時点でのユーザの嗜好を反映しているアイテムであると考えられる。このようなことから、アクティブ度とは、所定のアイテムに対するユーザの所定の操作から導き出される、ユーザの嗜好に関する１つの指標であるといえる。

このアクティブ度は、アイテム管理エンジン２２により算出される。アイテム管理エンジン２２は、アクティブ度データベース３５のアクティブ度をアイテム管理状態データベース３４で管理されている情報を用いて計算する。予め所定の操作に対するアクティブ度は設定されており、その設定されている値が、操作毎にまたアイテム毎に加算されることでアクティブ度は算出される。例えば、録画という操作には、２点、視聴という操作には１点といった値が設定されていた場合、所定のアイテムが録画された後、視聴されたときには、そのアイテムに対するアクティブ度は、３点（＝２＋１）と算出され、アクティブ度データベース３５に書き込まれる。

またこのアクティブ度は、時間経過とともに、値が小さくなるように設定されている。アクティブ度は、後述するように、主に、ユーザの短期的な興味や習慣性を反映させたアイテムの推薦を行うときに用いられる。このように用いられるので、時間が経過しているアクティブ度がアイテムの推薦時に大きな影響を及ぼさないように、時間が経過しているアクティブ度は数値が小さくなるように設定されている。

例えば、アクティブ度データベース３５の“レコード更新日”（後述）の日時が、所定の間隔Ｔ１毎にチェックされ、間隔Ｔ１以上経過していると判断されるアクティブ度が検出される。そして、検出されたアクティブ度に対して減衰定数Ｖが乗算される。このような処理が所定の間隔Ｔ１毎に行われることで、アクティブ度が、時間経過と共に減衰される。

アクティブ度データベース３５について説明するに、アクティブ度データベース３５の“ユーザＩＤ”という項目の欄には、操作ログデータベース３１、ユーザ嗜好データベース３２、アイテム状態管理データベース３４の“ユーザＩＤ”という項目と同じく、ユーザ毎に割り振られたＩＤが書き込まれる。

“シリーズＩＤ”という項目の欄には、アイテム状態管理データベース３４の“シリーズＩＤ”という項目と同じく、シリーズのＩＤが書き込まれる。

“ファンクションＩＤ”という項目の欄には、ファンクションに割り当てられているＩＤが書き込まれる。ここで、ファンクションとは、推薦の種類を表すものである。例えば、ユーザの嗜好を判断して、自動的に録画する番組をお勧めする推薦、録画済の番組の視聴をお勧めする推薦、録画済の番組を削除するときの推薦などがある。各ファンクションのアクティブ度は、ユーザの操作がに基づいて更新される。すなわち、ユーザの操作は、操作ログデータベース３１のところで説明したように、番組の視聴、番組の録画（録画予約）、番組の評価、番組の詳細情報の検索、録画した番組の機器１１以外の装置への転送といった操作がある。

これらの操作をユーザが行うと、操作ログデータベース３１の“ログの種類”の欄に書き込まれるため、その“ログの種類”の欄に書き込まれる情報に基づき、アクティブ度が更新される。各ファンクションのアクティブ度の更新に用いられるユーザの操作は、予め定められており、その操作が行われたタイミング、例えば、操作ログが書き込まれたタイミングで、それに対応するファンクションのアクティブ度が更新される。

なお、ここでは図示していないが、操作とファンクションＩＤを関連付けるテーブルを、別途用意し、管理するようにしても良い。そのようにすることで、例えば、操作の追加、変更、削除といったことを行いたいときに、その処理に対応してファンクションＩＤを追加、変更、削除といった処理を行うことが可能となり、汎用性を高め、管理をしやすくすることが可能となる。

“アクティブ度”という項目の欄には、アクティブ度が書き込まれる。このアクティブ度は、ユーザの操作に対応して更新される値であるため、“レコード更新日”という項目が設けられ、レコードの更新日が書き込まれるように構成されている。

図６に示したアクティブ度データベース３５の一番上の欄に記載されている例を参照するに、ユーザＩＤが“１”、シリーズＩＤが“１０１”、ファンクションＩＤが“１”、アクティブ度が“９．８”、レコード更新日が“2008-08-11 11:50:13”という情報が関連付けられて管理されている。この情報から、ユーザＩＤが“１”のユーザは、“１０１”というシリーズの番組に対して、ファンクションＩＤとして“１”が割り振れた推薦の種類、例えば、自動録画といった推薦に対して、アクティブ度は、“９．８”であることがわかる。すなわち、この場合、シリーズＩＤが１０１で表されるシリーズに対して、自動録画といった操作をお勧めする度合いが９．８であることを示している。

このように、アクティブ度データベース３５は、各シリーズの各ファンクションにおけるアクティブ度を管理する。アクティブ度データベース３５は、アイテム管理エンジン２２により更新される。

図１に関する説明に戻り、シリーズ視聴ジャンルマスタデータベース３６は、シリーズの初めから（１話）から、連続して視聴することが好ましいジャンルの一覧を管理する。図７に示したようにシリーズ視聴ジャンルマスタデータベース３６は、“ジャンルＩＤ”と“ジャンル名”といった情報を関連付けて管理している。

“ジャンルＩＤ”という項目の欄には、ジャンルに割り振られているＩＤが書き込まれる。“ジャンル名”という項目の欄には、ジャンルＩＤに対応するジャンル名が書き込まれる。

図７に示したシリーズ視聴ジャンルマスタデータベース３６の一番上の欄に記載されている例を参照するに、ジャンルＩＤが“１０３０００”、ジャンル名が“ドラマ”という情報が関連付けられて管理されている。この場合、ジャンルＩＤとして“１０３０００”が割り振られた“ドラマ”というジャンル名に属する番組（シリーズ）は、第１話から視聴した方が良いとユーザに推薦されるジャンルであるとして管理されていることになる。

図１に関する説明に戻り、ＥＰＧ管理データベース３７は、ＥＰＧに関するデータを管理する。図８に、ＥＰＧ管理データベース３７のデータ構造の一例を示す。図８に示したようにＥＰＧ管理データベース３７は、“アイテムＩＤ”、“シリーズＩＤ”、“開始時刻”、“終了時刻”、および“放送曲”といった情報を関連付けて管理している。

“アイテムＩＤ”という項目の欄には、例えば、アイテムメタデータベース３３の“アイテムＩＤ”という項目と同じく、アイテムに割り振られたＩＤが書き込まれる。“シリーズＩＤ”という項目の欄には、例えば、アイテム状態管理データベース３４の“シリーズＩＤ”という項目と同じく、シリーズに割り振られたＩＤが書き込まれる。

“開始時刻”という項目の欄には、アイテム、すなわちこの場合、番組の放送の開始時刻が書き込まれる。同様に“終了時刻”という項目の欄には、番組の放送の終了時刻が書き込まれる。同様に“放送局”という項目の欄には、番組を放送する放送局（チャンネル）が書き込まれる。

図８に示したＥＰＧ管理データベース３７の一番上の欄に記載されている例を参照するに、アイテムＩＤが“１００１”、シリーズＩＤが“２”、開始時刻が“2008-08-12 08:00:00”、終了時刻が“2008-08-12 09:00:00”、放送局が“３”という情報が関連付けられて管理されている。

ＥＰＧ管理データベース３７に記載される情報は、アイテムのメタデータを取得し、そのメタデータに記載されている情報が書き込まれる。ここでは、シリーズＩＤは、ＥＰＧを構成する情報（メタデータに含まれる情報）として説明を続けるので、メタデータが取得され、ＥＰＧ管理データベース３７に書き込まれるとして説明を続ける。この場合、ＥＰＧを作成する側がシリーズＩＤを割り当てることになる。他の形態としては、ＥＰＧ管理データベース３７を管理する側で、シリーズＩＤを付与し、書き込むようにしても良い。

このように、ＥＰＧ管理データベース３７は、ＥＰＧから得られるデータを管理する。

このようなデータベースを、データベース部１３（図１）は備えている。このようなデータベース部１３に備えられているデータベースを用いて、エンジン部１２が行う処理、ここでは特に、推薦に関する処理について以下に説明する。

［推薦に係わる処理について］
推薦としては、ユーザに対して、放送されている番組の視聴を薦める、放送予定の番組の録画を薦める、録画済の番組の中から視聴する番組を薦める、録画済の番組で削除する番組を薦めるなどがある。また、この他の推薦として、例えば、機器１１に既に録画されている番組を、他の装置、例えば携帯可能な、映像を表示できる表示部を有する装置（携帯端末と記述する）に転送するときに、転送するのに適している番組を薦めるという推薦もある。また、このような転送のときに、複数の番組の転送がユーザにより指示されたが、転送先の携帯端末の記憶容量が少なく、指示された全ての番組を転送できないときに、転送しない番組をお勧めするという推薦もある。

このような推薦のうち、削除するときの推薦以外の推薦（視聴、録画といった推薦）は、基本的な処理の流れが同じであるので、図９と図１０に示したフローチャートを参照して、その基本的な処理の流れについて説明する。削除するときの推薦に関しては、図１１に示したフローチャートを参照して後述する。推薦に関する処理、すなわち、図９、図１０を参照して説明する処理は、推薦エンジン２５（図１）により行われる。

ステップＳ１１において、推薦エンジン２５は、アクティブ度の高いシリーズを抽出する。推薦エンジン１５は、処理対象（番組を推薦する対象とされたユーザ）とされたユーザのユーザＩＤに関連付けられているアクティブ度を、例えば、上位Ｎ個、アクティブ度データベース３５（図６）を参照し読み出す。上位Ｎ個とは、この場合、アクティブ度の値が高いＮ個のことである。仮に、アクティブ度が高いほど、低い値が付けられるとして設定されている場合、アクティブ度の低い方から順にＮ個が読み出される。

また、アクティブ度データベース３５から読み出される情報は、アクティブ度の高い上位Ｎ個のシリーズＩＤである。なお、このような処理が行われるため、アクティブ度データベース３５の更新が行われるとき、アクティブ度順にソートするといった更新も行われるようにし、常に、アクティブ度順に情報がソートされているようにしても良い。

ステップＳ１２において、アイテムがお勧めリスト１に格納される。この格納されるアイテムは、録画する番組や、その時点で放送されている番組のうち視聴する番組をお勧めする場合、放送予定や放送中の番組が対象となる。このような場合、ＥＰＧ管理データベース３７が参照され、ステップＳ１１において抽出されたＮ個のシリーズＩＤと同じＩＤを有する番組が、お勧めリスト１に格納される。

また、録画済の番組の中から視聴する番組をお勧めする場合、機器１１に記録されている番組が対象とされ、アイテム状態管理データベース３４が参照され、ステップＳ１１において抽出されたＮ個のシリーズＩＤと同じＩＤを有する番組が、お勧めリスト１に格納される。以下、録画する番組をお勧めする場合であるとして説明を続ける。

ステップＳ１３において、処理対象とされているユーザの嗜好情報が取得される。推薦エンジン２５は、ユーザ嗜好データベース３２を参照し、その時点で処理対象とされているユーザに割り振られているユーザＩＤと関連付けられている情報を読み出す。

ステップＳ１４において、推薦対象とされるアイテムとマッチングが行われる。推薦対象とされるアイテムは、処理時点よりも後の時点で放送予定の全ての番組である。マッチングとは、具体的には、ユーザの嗜好と推薦対象とされるアイテムとの類似度を計算することを、ここでは意味する。

類似度を計算する手法として、ベクトル間の内積やコサイン尺度、ユークリッド距離など様々な手法を適切に用いることで、適切な類似度を得ることができる。ここでは、内積を用いた手法を例にとって説明を行う。
アイテムが持つ属性の集合Ａに含まれる属性をａ、
属性aの重みをＷａ、
当該ユーザの嗜好の属性aをＸａ、
推薦対象アイテムの属性aをＹａ
とすると、当該アイテムと推薦対象アイテムとの間の類似度は次式（１）で計算できる。

このようにして類似度が、全てのアイテムに対して算出されると、ステップＳ１５において、マッチング結果が降順にソートされる。すなわち、類似度の数値が大きいほど、類似していると判定されるように構成されている場合、類似度が高い順にソートされる（並び替えられる）。

このようにソートされた後のアイテムは、ステップＳ１６において、お勧め候補リストに格納される。この、お勧め候補リストには、推薦対象とされた全てのアイテムが格納されるようにしても良いし、類似度の値が閾値以上のアイテムだけが格納されるようにしても良い。

ステップＳ１７において、お勧め候補リストに含まれるアイテムが、お勧めリスト１とお勧めリスト２に、同一のアイテムが格納されているか否かが判断される。このステップＳ１７以下の処理は、お勧め候補リストに格納されているアイテム毎に行われる。よって、ステップＳ１７においては、お勧め候補リストに格納されているアイテムのうちの１つが処理対象とされ、その処理対象とされたアイテムが、お勧めリスト１またはお勧めリスト２に格納されているか否かが判断される。

このステップＳ１７の処理は、お勧め候補リストに格納されているアイテムと、お勧めリスト１とお勧めリスト２に既に格納されている（だぶって格納されている）ことを防ぐための判断処理である。

ステップＳ１７において、処理対象とされたお勧め候補リストに格納されているアイテムは、お勧めリスト１またはお勧めリスト２に格納されていると判断された場合、ステップＳ２６（図１０）に処理が進められ、格納されいないと判断された場合、ステップＳ１８に処理が進められる。

ステップＳ１８において、処理対象とされているアイテムは、シリーズ視聴お勧めジャンルの番組であるか否かが判断される。この判断は、処理対象とされているアイテムのジャンルＩＤが、シリーズ視聴ジャンルマスタデータベース３６に登録されているか否かが判断されることにより行われる。例えば、ステップＳ１４でマッチングの処理が行われるとき、アイテムの情報の１つとして、ジャンルＩＤが取得され、そのジャンルＩＤを用いて、ステップＳ１８における処理が実行される。また、アイテムの情報は、例えば、番組のメタデータであり、そのメタデータは、マッチングの処理が行われる時点で他のサーバなどから取得されるようにしても良いし、事前にＥＰＧ管理データベース３７に記憶され、ＥＰＧ管理データベース３７から取得されるようにしても良い。

ステップＳ１８において、処理対象のアイテムは、シリーズ視聴お勧めジャンルの番組であると判断された場合、ステップＳ１９に処理が進められる。ステップＳ１９において、同一シリーズが既に録画済または視聴済であるか否かが判断される。ここでは、録画済または視聴済であるか否かが判断されるとして説明を続けるが、さらに、アイテムを購入する、いわゆる有料放送なども処理対象とする場合、購入済であるか否かも判断要素の１つとされる。

ステップＳ１９における処理は、アイテム状態管理データベース３４が参照されることにより行われる。すなわち、処理対象とされているアイテムに付けられたシリーズＩＤと一致するシリーズＩＤが、アイテム状態管理データベース３４で管理されているか否かが判断され、管理されていると判断された場合、さらに、そのシリーズＩＤに関連付けられている視聴日や録画日が参照されることで、ステップＳ１９における処理が実行される。

ステップＳ１９において、処理対象とされているアイテムが属するシリーズは、既に録画済、視聴済であると判断された場合、すなわち、ユーザが、そのシリーズを構成する番組のうち、少なくとも１番組を視聴または録画していると判断された場合、ステップＳ２０（図１０）に処理が進められる。

ステップＳ２０において、処理対処とされているアイテムは、お勧め候補リスト内で上位Ｊ以内に入っているアイテムであるか否かが判断される。ステップＳ２０において、上位Ｊ以内であると判断された場合、ステップＳ２１に処理が進められる。ステップＳ２１において、処理対象とされているお勧め候補リストに格納されていたアイテムが、お勧めリスト１に格納される。

ステップＳ２１に処理が来るのは、ステップＳ１７でＮＯと判断されたときなので、処理対象とされているアイテムは、お勧めリスト１には格納されていない。また、ステップＳ１８で、処理対象のアイテムはシリーズとして視聴した方が良いとお勧め出来る番組であると判断されたアイテムである。さらにステップＳ１９で、ユーザは、そのアイテム（番組）を既に視聴しているか録画しているといった状態であり、関心があるアイテムであると判断されたアイテムである。すなわち、ここまでの処理（ステップＳ１９までの処理）で、ユーザは、処理対象とされているアイテムが属するシリーズに少しは興味があり、仮にそのシリーズがユーザの嗜好に合っていなくても、その時点での、換言すれば短期的にみれば、関心があるアイテムであると判断できる。

ここまでの処理で、短期的なユーザの嗜好に合致するアイテムの検出を行ったことになる。そのようなアイテムに対して、ステップＳ２０における上位Ｊ以内であるか否かといった判断を行うわけだが、この処理は、ユーザの嗜好に合致したアイテムを検出する処理であると言える。換言すれば、長期的なユーザの嗜好に合致するアイテムの検出を行うための処理であると言える。

このような判断を経て、ステップＳ２１に処理が来た場合、その処理対象とされているアイテムは、短期的なユーザの嗜好にも、長期的なユーザの嗜好にも合致したアイテムであると判断されたことを意味する。このような短期的なユーザの嗜好も反映したアイテムの検出を本発明によれば行うことが可能となる。

一方、ステップＳ２０において、処理対象とされているアイテムは、お勧め候補リスト内で、上位Ｊ以内には含まれていないと判断された場合、ステップＳ２２に処理が進められる。ステップＳ２２において、シリーズ視聴お勧め度をＰ倍するフラグが立てられる。このシリーズ視聴お勧め度とは、ステップＳ２３で算出され、その値をステップＳ２４における処理でＰ倍するためのフラグが、ステップＳ２２の処理について立てられる。

ステップＳ２２に処理が来るのは、処理対象としているアイテムが、短期的なユーザの嗜好に合致していると判断されるが、長期的なユーザの嗜好には合致していないと判断されるときである。このようなときは、短期的な嗜好には合致しているということを反映させるために、後段の処理でお勧め度が大きくなるように、そのような処理を行うためのフラグが立てられる。

ステップＳ２３への処理には、ステップＳ１８において、処理対象とされているアイテムは、シリーズお勧めジャンルに属する番組ではないと判断されたとき、または、ステップＳ１９において、処理対象とされているアイテムは、まだ録画済、視聴済ではないと判断された場合も来る。

ステップＳ２３において、シリーズ視聴お勧め度が算出される。このシリーズ視聴お勧め度とは、シリーズで視聴した方が良い度合いを示す数値であり、以下の式（２）により算出される。

式（２）において、viewWeightは、シリーズ視聴お勧め度を表し、１項目のActiveDegreeは、アクティブ度データベース３５に書き込まれているアクティブ度を表す。２項目のRecordNumは、アイテム状態管理データベース３４の録画回数の欄に書き込まれている数値を表し、BroadcastNumは、アイテム状態管理データベース３４の放送回数の欄に書き込まれている数値を表す。３項目のLastRecordBroadcastDataは、アイテム状態管理データベース３４の積算値の欄に書き込まれている数値を表し、NowDateは、計算時の日時を表す。１項目のα、２項目のβ、および３項目のγは、それぞれ係数である。また４項目のwは、viewWeightのデフォルトの値である。

このような式（２）でシリーズ視聴お勧め度が算出される。なお、この式（２）に基づく演算の前に、そのアイテムを現在視聴中であるか否かの判断を行い、その判断の結果、視聴中であると判断された場合には、式（２）で算出された値に定数εを乗算した値とするようにしても良い。

ステップＳ２３において、シリーズ視聴お勧め度が算出されると、ステップＳ２４において、処理対象とされているアイテムの類似度（ステップＳ１４において算出された類似度）に、シリーズ視聴お勧め度が乗算される。さらにこのとき、ステップＳ２２においてフラグが立てられたアイテムである場合には、Ｐ倍にするための乗算が行われる。このようにして、最終的なお勧め度が算出される。このようにしてお勧め度が算出されたアイテムは、ステップＳ２５において、お勧めリスト２に格納される。

このようなステップＳ１７乃至Ｓ２５までの処理が、お勧め候補リストに格納されている全てのアイテムに対して繰り返し行われる。全てのアイテムに対して処理が行われると、お勧めリスト２に格納されている全てのアイテムに対して、お勧め度が格納された状態とされる。

このような状態になると、ステップＳ２６において、お勧めリスト２に格納されているアイテムが、お勧め度が高い順にソートされる。そして、ステップＳ２７において、お勧めリスト２に格納されているアイテムが、お勧めリスト１に格納される。このとき、お勧めリスト２内で、お勧め度が高いｋ個のアイテムだけが、お勧めリスト１に格納される。

このようにすると、お勧めリスト１に多くのアイテムが既に格納されていると、お勧めリスト２内のアイテムが追加されることで、さらに多くのアイテムが、お勧めリスト１に格納されることになる。また逆に、お勧めリスト１にあまりアイテムが格納されていない状態だと、お勧めリスト２内のアイテムが追加されても、その状態は変わらず、お勧めリスト１に格納されているアイテムが少ない場合もある。お勧めリスト１に格納されているアイテムは、ユーザ側にお勧めのアイテムとして推薦されるため、その推薦されるアイテムの数は、多くもなく、少なくもない適切な数であることが好ましい。

そこで、ステップＳ２７において、お勧めリスト２に格納されているアイテムを、お勧めリスト１に格納し直すとき、お勧めリスト１に既に格納されているアイテムの数を考慮して、お勧めリスト２からお勧めリスト１に移すアイテムの数が決定されるようにしても良い。すなわち、上記したｋ個は変数とし、例えば、お勧めリスト１に最終的に格納されるアイテムの数をＬ個とした場合、その時点で、お勧めリスト１に格納されているアイテムの数を、Ｌ個から減算した値をｋ個として、そのｋ個だけ、アイテムがお勧めリスト２からお勧めリスト１に移動されるようにしても良い。

このようにして、お勧めリスト１に、お勧めリスト２に格納されていたアイテムが追加されると、ステップＳ２８において、お勧めリスト１が正規化されて出力される。正規化の処理として、例えば、お勧め度の高い順にソートされるといった処理が行われる。そして、ソートされた順に、ユーザにアイテムが推薦される。推薦とは、具体的には、アイテムの情報を、テキスト、画像、音声で、ユーザに提示することを意味する。

この推薦されるアイテムは、お勧めリスト１に格納されているアイテムである。このお勧めリスト１に格納されているアイテムは、まず、ステップＳ１１，Ｓ１２の処理が行われることにより格納されたアイテムである。このステップＳ１１，Ｓ１２の処理で、お勧めリスト１に格納されたアイテムは、ユーザが録画や視聴などを繰り返したシリーズの番組である。このようなアイテムは、その時点で、ユーザが興味あるアイテムである。換言すれば、短期的な嗜好であっても、そのような短期的な嗜好から抽出されたアイテムである。

また、そのようなアイテムは、アクティブ度を用いて抽出されているため、例えば、月曜の８時に放送される番組を録画し、その後視聴するといったような、その時点での習慣性を反映している。すなわち、アクティブ度を用いて推薦するアイテムを決定することで、ユーザの習慣性をも考慮したアイテムを抽出することが可能となる。このように、本実施の形態を適用した推薦によれば、ユーザの短期的な嗜好、習慣性に合致したアイテムを、ユーザに推薦することが可能となる。

さらに、お勧め候補リストに格納されているアイテムは、ユーザの嗜好に基づくものであり、この嗜好は、蓄積された情報である。よって、継続的な嗜好であったり、長期的な嗜好であったりする。そのような長期的な嗜好を反映したアイテムを、短期的な嗜好を反映して選択し、お勧めリスト１に移動することで、長期的な嗜好と短期的な嗜好を共に反映したアイテムをユーザに推薦することが可能となる。

上記した図９、図１０のフローチャートを参照して説明した実施の形態においては、ユーザの短期的な嗜好や習慣性を、ステップＳ１１やステップＳ１２の処理を行うことで、優先的に推薦されるようにした。換言すれば、ユーザに推薦されるアイテムの上位Ｎ個は、ユーザの短期的な興味、習慣性などに基づいたアイテムとされるようにした。

ステップＳ１１，Ｓ１２よりも後段の処理、例えば、ステップＳ２３などの処理で、シリーズという概念を用い、シリーズを構成する番組（アイテム）は、お勧め度が大きくなるような処理を行っている。ユーザが興味を持っているシリーズを構成するアイテムを推薦するようにしているため、このような処理だけでも、ユーザの短期的な興味や習慣性などに基づいたアイテムを推薦することが可能である。

このようなことから、推薦に係わる処理として、図９のステップＳ１１とステップＳ１２の処理を削除し、ステップＳ１３からの処理が実行されるようにしても良い。このようなことを考慮した処理について、図１１のフローチャートを参照して説明する。図１１に示したフローチャートの各処理は、図９、図１０に示したフローチャートの各処理と同様に行われる処理が多いため、対応するステップを記述し、その詳細な説明は適宜省略する。

ステップＳ６１において、ユーザの嗜好が取得され、ステップＳ６２において、推薦対象とされるアイテムとのマッチングが行われる。その結果を用いて、ステップＳ６３において、類似度順にアイテムがソートされる。これらのアイテムは、ステップＳ６４において、お勧め候補リストに格納される。

このステップＳ６１乃至Ｓ６４の処理は、図９のステップＳ１３乃至Ｓ１６の処理と同様に行われる。なお、図１１に示した処理においては、お勧めリスト１は用いないが、図９、図１０のフローチャートを参照した説明に合わせるために、図９、図１０のフローチャートでお勧めリスト２と記述したリストを、図１１のフローチャートにおいてもお勧めリスト２と記述して説明する。

ステップＳ６５において、処理対象のアイテムは、シリーズ視聴お勧めジャンルであるか否かが判断され、シリーズ視聴お勧めジャンルであると判断された場合、ステップＳ６６に処理が進められ、そうではないと判断された場合、ステップＳ６６，Ｓ６７の処理をスキップして、ステップＳ６８に処理が進められる。

このステップＳ６５とステップＳ６６の処理は、図９のステップＳ１８とステップＳ１９の処理に対応する。

ステップＳ６６において、処理対象とされているアイテムが属するシリーズと同一のシリーズに属するアイテムは、既に録画済または視聴済であると判断された場合、ステップＳ６７に処理が進められる。ステップＳ６７において、シリーズ視聴お勧め度をＰ倍するフラグが立てられる。フラグが立てられた後、ステップＳ６８に処理が進められる。このステップＳ６７における処理は、図１０のフローチャートのステップＳ２２の処理に対応する。

ステップＳ６８において、シリーズお勧め度が算出され、その値が、ステップＳ６９の処理として、類似度に乗算される。ステップＳ６９の処理が行われるとき、ステップＳ６７の処理が実行され、フラグが立てられているアイテムに対しては、さらにＰ倍するという処理も実行される。ステップＳ７０において、算出されたお勧め度は、アイテムと関連付けられ、お勧めリスト２に格納される。このステップＳ６８乃至Ｓ７０の処理は、図１０のフローチャートのステップＳ２３乃至Ｓ２５に対応する。

ステップＳ７１において、お勧めリスト２に格納されているアイテムが、お勧め度順にソートされる。そして、ステップＳ７２において、お勧めリスト２が正規化されて、ユーザ側にお勧めするアイテムが提示される。このステップＳ７１，Ｓ７２の処理は、図１０のフローチャートのステップＳ２６，Ｓ２８に対応する。

このような処理に基づいても、ステップＳ６５乃至Ｓ６９の処理により、シリーズに属するアイテムであるか否か、またユーザが録画や視聴を行ったアイテムであるか否かといった判断が行われることで、ユーザの短期的な嗜好や習慣性を考慮したアイテムを抽出することが可能である。

よって、図１１に示したフローチャートに基づく処理においても、長期的な嗜好と短期的な嗜好を共に反映したアイテムをユーザに推薦することが可能となる。

［削除の推薦に係わる処理について］
次に、削除の推薦に係わる処理について説明する。削除の推薦とは、例えば、機器１１の記憶容量の残量が少なくなり、その記憶容量を増やすために、記憶されているアイテムを削除するとき、削除しても良いアイテムをユーザに推薦する。また、機器１１から他の装置に複数のアイテムを移動するとき、他の装置の記憶容量の残量が不足し、指示されたアイテムの全てを移動することができないときなどに、移動するアイテムのリストから削除する候補を推薦するといった推薦もある。

このような削除に係わる推薦の処理について図１２のフローチャートを参照して説明する。

ステップＳ１０１において、推薦エンジン２５は、ファンクションが“削除お勧め”に関するアクティブ度の高いシリーズを抽出する。推薦エンジン１５は、処理対象（番組を推薦する対象とされたユーザ）とされたユーザのユーザＩＤに関連付けられ、ファンクションとして“削除お勧め”を示すファンクションＩＤに関連付けられているアクティブ度を、高い順にソートしたとき、その順で、上位のＮ個を、アクティブ度データベース３５（図６）を参照し読み出す。この場合、削除お勧めのアクティブ度が高いシリーズは、ユーザの興味のないシリーズであると判断でき、この場合、削除対象とするアイテムを抽出するための処理なので、ユーザの興味のないシリーズを抽出するための処理が、ステップＳ１０１において実行される。

ステップＳ１０２において、アイテムが削除リスト１に格納される。この格納されるアイテムは、削除対象とされる番組である。録画済のアイテムを削除する場合、機器１１に記憶されているアイテムが削除対象とされる番組である。また、アイテムの移動が指示されたときに、その指示されたアイテムから削除する場合、移動が指示されたアイテムが削除対象とされる番組である。

いずれの場合であっても、削除対象とされるのは、機器１１に記憶されているアイテムであるので、機器１１に記憶されている番組が対象とされ、アイテム状態管理データベース３４が参照され、ステップＳ１０１において抽出されたＮ個のシリーズＩＤと同じＩＤを有する番組が、削除リスト１に格納される。

ステップＳ１０３において、処理対象とされているユーザの嗜好情報が取得される。推薦エンジン２５は、ユーザ嗜好データベース３２を参照し、その時点で処理対象とされているユーザに割り振られているユーザＩＤと関連付けられている情報を読み出す。

ステップＳ１０４において、削除対象とされるアイテムとユーザの嗜好とのマッチングが行われる。マッチングの対象となるアイテムは、機器１１に記憶されているアイテムである。このマッチングは、例えば、図９のフローチャートのステップＳ１４において実行される処理と同様に行うことが可能であり、ユーザの嗜好と削除対象とされるアイテムとの類似度が計算される処理である。

類似度が算出されると、ステップＳ１０５において、類似度と関連付けられて、その類似度が算出されたアイテムが、削除候補リストに格納される。なお、削除候補リストには、削除対象とされた全てのアイテムが格納されるようにしても良いし、類似度の値が閾値以下、すなわち、ユーザの嗜好に合わないと判断されるアイテムだけが格納されるようにしても良い。

ステップＳ１０６において、削除候補リスト内のアイテムが、削除リスト１と削除リスト２に、既に格納されているか否かが判断される。このステップＳ１０６以下の処理は、削除候補リストに格納されているアイテム毎に行われる。よって、ステップＳ１０６においては、削除候補リストに格納されているアイテムのうちの１つが処理対象とされ、その処理対象とされたアイテムが、削除リスト１または削除リスト２に格納されているか否かが判断される。

ステップＳ１０６において、処理対象とされた削除候補リストに格納されているアイテムは、削除リスト１または削除リスト２に格納されていると判断された場合、ステップＳ１０７乃至１０９の処理をスキップし、ステップＳ１１０に処理が進められ、格納されいないと判断された場合、ステップＳ１０７に処理が進められる。

ステップＳ１０７において、シリーズ視聴お勧め度が算出される。このシリーズ視聴お勧め度とは、シリーズで視聴した方が良い度合いを示す数値であり、上記した式（２）により算出される。この式（２）に関しては、図１０のフローチャートのステップＳ２３の処理の説明のときに説明したので、その詳細な説明は省略する。

ステップＳ１０７において、シリーズ視聴お勧め度が算出されると、ステップＳ１０８において、処理対象とされているアイテムの類似度（ステップＳ１０４において算出された類似度）に、シリーズ視聴お勧め度が乗算される。このようにして算出されたお勧め度は、削除リスト２に、処理対象とされたアイテムと関連付けられて格納される。

このようなステップＳ１０６乃至Ｓ１０９までの処理が、削除候補リストに格納されている全てのアイテムに対して繰り返し行われる。全てのアイテムに対して処理が行われると、削除候補リストに格納されていた全てのアイテムに対して、お勧め度が格納された状態とされる。

このような状態になると、ステップＳ１１０において、削除リスト２に格納されているアイテムが、削除するアイテムとしてお勧め度が高い順にソートされる。ここでの処理は、削除するアイテムとしてお勧めすべきアイテムの抽出なので、削除するアイテムとしてお勧め度が高いアイテムが対象となる。よって、ステップＳ１１０においては、削除するアイテムとしてお勧め度が高い順に、お勧めリスト２内のアイテムがソートされる。

ステップＳ１１１において、削除リスト２に格納されているアイテムが、削除リスト１に格納される。このとき、削除リスト２内で、お勧め度が低いｋ個のアイテムだけが、削除リスト１に格納される。このｋ個も、図１０のステップＳ２７の処理と同じく、削除リスト１に格納されているアイテム数に依存する変数として設定されていても良い。

削除リスト１に、削除リスト２に格納されていたアイテムが追加されると、ステップＳ１１２において、削除リスト１が正規化されて出力される。正規化の処理として、例えば、お勧め度の低い順にソートされるといった処理が行われる。そして、ソートされた順に、ユーザにアイテムが推薦される。

このような処理が行われることにより、ユーザの嗜好に合致していないアイテムを削除対象として推薦することが可能となる。

このように、本発明の推薦においては、短期的な興味や習慣性に基づいた推薦を行うとが可能となる。また、推薦を行うことにより、ユーザに新たなきっかけ、例えば、録画したり視聴したりするといったきっかけを与えることが可能となる。また、ユーザの嗜好を広げることができる。さらには、ユーザの嗜好に合わせた推薦を行うことも可能となる。

上述した一連の処理は、ハードウェアにより実行させることもできるし、ソフトウエアにより実行させることもできる。一連の処理をソフトウエアにより実行させる場合には、そのソフトウエアを構成するプログラムが、専用のハードウェアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどに、プログラム記録媒体からインストールされる。

図１３は、上述した一連の処理をプログラムにより実行するパーソナルコンピュータのハードウェアの構成の例を示すブロック図である。

コンピュータにおいて、ＣＰＵ（Central Processing Unit）２０１、ＲＯＭ（Read Only Memory）２０２、ＲＡＭ（Random Access Memory）２０３は、バス２０４により相互に接続されている。

バス２０４には、さらに、入出力インターフェース２０５が接続されている。入出力インターフェース２０５には、キーボード、マウス、マイクロホンなどよりなる入力部２０６、ディスプレイ、スピーカなどよりなる出力部２０７、ハードディスクや不揮発性のメモリなどよりなる記憶部２０８、ネットワークインタフェースなどよりなる通信部２０９、磁気ディスク、光ディスク、光磁気ディスク、あるいは半導体メモリなどのリムーバブルメディア２１１を駆動するドライブ２１０が接続されている。

以上のように構成されるコンピュータでは、ＣＰＵ２０１が、例えば、記憶部２０８に記憶されているプログラムを、入出力インターフェース２０５及びバス２０４を介して、ＲＡＭ２０３にロードして実行することにより、上述した一連の処理が行われる。

コンピュータ（ＣＰＵ２０１）が実行するプログラムは、例えば、磁気ディスク（フレキシブルディスクを含む）、光ディスク（CD-ROM(Compact Disc-Read Only Memory),DVD(Digital Versatile Disc)等）、光磁気ディスク、もしくは半導体メモリなどよりなるパッケージメディアであるリムーバブルメディア２１１に記録して、あるいは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の伝送媒体を介して提供される。

そして、プログラムは、リムーバブルメディア２１１をドライブ２１０に装着することにより、入出力インターフェース２０５を介して、記憶部２０８にインストールすることができる。また、プログラムは、有線または無線の伝送媒体を介して、通信部２０９で受信し、記憶部２０８にインストールすることができる。その他、プログラムは、ＲＯＭ２０２や記憶部２０８に、あらかじめインストールしておくことができる。

なお、コンピュータが実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであっても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであっても良い。

また、本明細書において、システムとは、複数の装置により構成される装置全体を表すものである。

なお、本発明の実施の形態は、上述した実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲において種々の変更が可能である。

本発明を適用したシステムの一実施の形態の構成を示す図である。 操作ログデータベースのデータ構造を示す図である。 ユーザ嗜好データベースのデータ構造を示す図である。 アイテムメタデータベースのデータ構造を示す図である。 アイテム状態管理データベースのデータ構造を示す図である。 アクティブ度データベースのデータ構造を示す図である。 シリーズ視聴ジャンルマスタデータベースのデータ構造を示す図である。 ＥＰＧ管理データベースのデータ構造を示す図である。 推薦に係わる処理について説明するためのフローチャートである。 推薦に係わる処理について説明するためのフローチャートである。 推薦に係わる処理について説明するためのフローチャートである。 推薦に係わる処理について説明するためのフローチャートである。 記録媒体について説明するための図である。

符号の説明

１１ 機器， １２ エンジン部， １３ データベース部， ２１ 機器内情報抽出エンジン， ２２ アイテム管理エンジン， ２３ 嗜好抽出エンジン， ２４ マイニングエンジン， ２５ 推薦エンジン， ３１ 操作ログデータベース， ３２ ユーザ嗜好データベース， ３３ アイテムメタデータベース， ３４ アイテム状態管理データベース， ３５ アクティブ度データベース， ３６ シリーズ視聴ジャンルマスタデータベース， ３７ ＥＰＧ管理データベース

Claims (7)

1. 所定のアイテムに対して行った操作内容から算出される度数と、前記アイテムが属するシリーズを関連付けて管理する管理手段と、
   前記度数をソートしたときの上位Ｎ個のシリーズと同じシリーズに属するアイテムを、複数のアイテムのなかから抽出する第１の抽出手段と、
   ユーザの嗜好を管理する嗜好管理手段と、
   前記嗜好管理手段により管理されている前記嗜好と、アイテムとの類似度を計算し、類似度の高い複数のアイテムを抽出する第２の抽出手段と、
   第１の抽出手段により抽出されたアイテムと、第２の抽出手段により抽出されたアイテムのうちの所定数のアイテムを、ユーザに推薦する推薦手段と
   を備える情報処理装置。
2. 前記度数は、前記アイテムを録画した、視聴した、他の装置に転送したという操作にそれぞれ設定されている値を加算することで算出される
   請求項１に記載の情報処理装置。
3. 前記度数は、所定の間隔毎に減衰される
   請求項１に記載の情報処理装置。
4. シリーズで視聴した方が良い度合いを示す値を算出し、前記第２の抽出手段で抽出されたアイテムの類似度に乗算する乗算手段をさらに備える
   請求項１に記載の情報処理装置。
5. 記憶手段に記憶されている所定のアイテムに対して行った操作内容から算出される度数と、前記アイテムが属するシリーズを関連付けた情報を参照し、前記度数をソートしたときの上位Ｎ個のシリーズと同じシリーズに属するアイテムを、複数のアイテムのなかから抽出し、
   記憶手段に記憶されているユーザの嗜好を参照し、前記嗜好管理手段により管理されている前記嗜好と、アイテムとの類似度を計算し、類似度の高い複数のアイテムを抽出し、
   それらの抽出されたアイテムを、ユーザに推薦する
   ステップを含む情報処理方法。
6. 記憶手段に記憶されている所定のアイテムに対して行った操作内容から算出される度数と、前記アイテムが属するシリーズを関連付けた情報を参照し、前記度数をソートしたときの上位Ｎ個のシリーズと同じシリーズに属するアイテムを、複数のアイテムのなかから抽出し、
   記憶手段に記憶されているユーザの嗜好を参照し、前記嗜好管理手段により管理されている前記嗜好と、アイテムとの類似度を計算し、類似度の高い複数のアイテムを抽出し、
   それらの抽出されたアイテムを、ユーザに推薦する
   ステップを含む処理を実行するコンピュータが読み取り可能なプログラム。
7. 請求項６に記載のプログラムを
   記録している記録媒体。

Images