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

Abstract

【課題】 ユーザの嗜好に合った情報を作成し、ユーザの嗜好に合った情報を提供できるようにする。
【解決手段】 ユーザＡとユーザＢが、それぞれ番組Ｘを録画予約する。ユーザＢは、番組Ｚも録画予約する。番組Ｘと番組Ｚは、ジャンルとして“お笑い系”に属する。番組Ｘには、人物Ａが出演し、番組Ｚには、人物Ｂが出演している。ユーザＡとユーザＢは、同じお笑い系の番組Ｘを録画予約しているため、お笑い好きであると考えられる。そこで、ユーザＡがまだ録画予約していない番組Ｚを、ユーザＡに対してオススメ番組として推薦する。本発明は、EPGを提供する側のサーバに適用することができる。
【選択図】図３８

Description

本発明は、情報処理装置および方法、プログラム、並びに記録媒体に関し、特に、ユーザの嗜好に基づく情報を提供する際に用いて好適な情報処理装置および方法、プログラム、並びに記録媒体に関する。

近年、インターネットなどのネットワークに接続できる機器が増加し、従来、ネットワークを介しては提供されていなかったようなサービスが提供され、それらのサービスを受けることが一般的になりつつある。例えば、テレビジョン受像機などは、テレビジョン番組のデータを受信するという従来からある機能に加え、ネットワークに接続し、所定のサーバからＥＰＧ（Electronic Program Guide）と称される電子的な番組表を取得する機能を有しているものもある。また、取得されたＥＰＧ上から録画予約などもできる機能も実現化されている。

ＥＰＧは、テレビジョン受像機以外の、例えば、パーソナルコンピュータなどでも取得でき、閲覧できるようになっている。

図１にＥＰＧの一例を示す。ＥＰＧは、上述したように、テレビジョン受像機やパーソナルコンピュータにより取得されるが、その取得されたＥＰＧは、表示部１１に表示される。ＥＰＧは、放送局、放送時間、放送される番組が対応付けられたマトリクス状の表で表示されることが多い。例えば、図１においては、“放送局Ａ”の“１２時”台に放送されている番組は“番組Ａ−１”であるといった情報が表示されている。このように、ＥＰＧには、番組を放送する放送局、放送される時間、および放送される番組が関連付けられ、その関連付けをユーザが認識しやすい表示が行われる。（例えば、非特許文献１参照）

このように、ＥＰＧには、基本的に、放送局、放送時間、放送される番組が関連付けれた状態で表示されるが、さらに、そのＥＰＧを提供する側が、ユーザの使い勝手等を考慮して、他の情報も合わせてユーザ側に提示することがある。例えば、図１に示した例では、番組名が表示されている領域内に、“予約”という予約ボタン２１が表示されている。この予約ボタン２１は、ユーザが、その番組を録画予約したいときに操作されるボタンとして設定されている。ＥＰＧを表示している端末が、パーソナルコンピュータのような記憶部（不図示）を有する端末である場合、この予約ボタン２１が操作されると、その内蔵する記憶部に、対応する番組が記憶（録画）されるような設定が行なわれる。

また、図１に示した例では、オススメボタン２２とランキングボタン２３も表示されている。オススメボタン２２は、ＥＰＧを提供する側がオススメする番組の情報を閲覧したときに操作されるボタンである。ランキングボタン２３は、録画予約された数や視聴率などに基づく情報を閲覧したいときに操作されるボタンである。

これらのボタンは、ユーザが操作部（不図示）を操作し、カーソル３１が所望のボタン上に位置した状態で、クリックなどの所定の操作が行われることにより操作されるように構成されている。
ソニー株式会社、テレビ王国、［online］、［平成１５年７月３０日検索］、インターネット＜URL：http://www.so-net.ne.jp/tv/index.html＞

図１に示したＥＰＧにおいて、例えば、オススメボタン２２が操作されると、図２に示したような画面に、表示部１１の表示が切り替えられる。図２に示した画面には、複数の番組名と、その番組名に対応する番組内容が表示されている。このオススメボタン２２が操作されたときに表示される画面は、ＥＰＧを提供する側が、予め作成したものである。すなわち、オススメの基準は、ＥＰＧを提供する側にあり、ＥＰＧの提供を受けるユーザ側にはない。

従って、ＥＰＧの１つのサービスとして提供されているオススメ番組の情報などは、複数のユーザを対象としたものであり、ユーザ個人を対象としたものではなかった。すなわち、個々のユーザの嗜好を考慮したオススメ番組の情報を提供することは困難であるという課題があった。このことは、オススメ番組の情報以外の情報を提供する際にも、同様の課題があった。

本発明はこのような状況に鑑みてなされたものであり、個々のユーザの嗜好などを考慮し、より適切な情報を、ユーザに提供できるようにすることを目的とする。

本発明の情報処理装置は、複数のユーザの嗜好に関する第１のデータを、ユーザ毎に管理する第１の管理手段と、第１のデータを用いて、ユーザ同士の相関度を算出する第１の算出手段と、第１の算出手段により算出された相関度のうち、一方のユーザは有しているが他方のユーザは有していない要素に対する相関度を用いて予測ベクトルを算出する第２の算出手段とを備えることを特徴とする。

前記情報処理装置は、情報に関する第２のデータを管理する第２の管理手段と、第２の算出手段により算出された予測ベクトルを用いて、処理対象とされているユーザの嗜好に一致するであろう情報を、第２のデータ内から検出する検出手段とをさらに備えるようにすることができる。

前記第１の算出手段により算出された相関度をソートし、隣接する相関度を有するユーザ同士を１つのグループとして設定する設定手段と、設定手段により設定されたグループの総数が、所定の数以下になるまで、設定手段による処理が繰り返し行われるように、所定の数以下になったか否かを判断する判断手段とをさらに備え、第２の算出手段は、グループをユーザとして扱い、グループ間の予測ベクトルを算出するようにすることができる。

ユーザが利用した情報に関するログを管理する第３の管理手段と、第３の管理手段により管理されているログを参照し、同じ情報を利用したユーザを抽出する抽出手段と、抽出手段により抽出されたユーザをグループとして設定する設定手段とをさらに備え、第２の算出手段は、グループ間の予測ベクトルを算出するようにすることができる。

本発明の情報処理方法は、データを管理するための記憶手段と、記憶手段に記憶されているデータを用いて所定の処理を実行する制御手段とを少なくとも備えた情報処理装置の情報処理方法であって、複数のユーザの嗜好に関する第１のデータを、ユーザ毎に管理する第１の管理ステップと、第１のデータを用いて、ユーザ同士の相関度を算出する第１の算出ステップと、第１の算出ステップの処理で算出された相関度のうち、一方のユーザは有しているが他方のユーザは有していない要素に対する相関度を用いて予測ベクトルを算出する第２の算出ステップとを含むことを特徴とする。

本発明のプログラムは、データを管理するための記憶手段と、記憶手段に記憶されているデータを用いて所定の処理を実行する制御手段とを少なくとも備えた情報処理装置のプログラムであって、複数のユーザの嗜好に関する第１のデータを、ユーザ毎に管理する第１の管理ステップと、第１のデータを用いて、ユーザ同士の相関度を算出する第１の算出ステップと、第１の算出ステップの処理で算出された相関度のうち、一方のユーザは有しているが他方のユーザは有していない要素に対する相関度を用いて予測ベクトルを算出する第２の算出ステップとを含むことを特徴とする。

本発明の記録媒体は、前記プログラムを記録していることを特徴とする。

本発明の情報処理装置および方法、並びにプログラムにおいては、ユーザ毎に、ユーザの嗜好に関するデータが管理され、その管理されているデータが用いられて、ユーザ同士の相関度が算出され、さらにその相関度が用いられて予測ベクトルが求められる。

本発明によれば、情報、特に、テレビジョン放送の番組に関する情報を提供することが可能となる。

本発明によれば、ユーザの嗜好を考慮した、例えば、テレビジョン放送の番組に関する情報を提供することができる。また、個々のユーザ毎にカスタマイズされた情報を提供することができるため、その情報を提供する側へのアクセスを増加させることが可能となる。

本発明によれば、ユーザに対して情報を提供する際、その情報を提供する根拠（キーワードなど）を合わせて提供することが可能となる。よって、ユーザ側は、提供された情報が、どのようなキーワードに基づき選択され、提供されたのかを認識することが可能となる。

さらに本発明によれば、ユーザ側に提供するキーワードなどは、提供する側で制御することができるため、例えば、ユーザに提供するにはふさわしくないキーワードだが、ユーザに提供する情報を検索する際にはふさわしいキーワードであるといったようなキーワードを管理することが可能となり、より適切な情報提供が可能となる。

以下に本発明の実施の形態を説明するが、請求項に記載の発明特定事項と、発明の実施の形態における具体例との対応関係を例示すると、次のようになる。この記載は、請求項に記載されている発明をサポートする具体例が、発明の実施の形態に記載されていることを確認するためのものである。従って、発明の実施の形態中に記載されているが、発明特定事項に対応するものとして、ここには記載されていない具体例があったとしても、そのことは、その具体例が、その発明特定事項に対応するものではないことを意味するものではない。逆に、具体例が発明特定事項に対応するものとしてここに記載されていたとしても、そのことは、その具体例が、その発明特定事項以外の発明特定事項には対応しないものであることを意味するものではない。

さらに、この記載は、発明の実施の形態に記載されている具体例に対応する発明が、請求項に全て記載されていることを意味するものではない。換言すれば、この記載は、発明の実施の形態に記載されている具体例に対応する発明であって、この出願の請求項には記載されていない発明の存在、すなわち、将来、分割出願、補正、国内優先などにより追加される発明の存在を否定するものではない。

本発明の情報処理装置（例えば、図９のサーバ５２）は、複数のユーザの嗜好に関する第１のデータ（例えば、図３０のT_UM_VALUEデータベース３１７）を、ユーザ毎に管理する第１の管理手段（例えば、図１１のターゲットデータベース２５２）と、第１のデータを用いて、ユーザ同士の相関度を算出する第１の算出手段（例えば、図４１のステップＳ９１の処理を実行する図９のＣＰＵ２０１）と、第１の算出手段により算出された相関度のうち、一方のユーザは有しているが他方のユーザは有していない要素に対する相関度を用いて予測ベクトルを算出する第２の算出手段（例えば、図４１のステップＳ９２の処理を実行する図９のＣＰＵ２０１）とを備えることを特徴とする。

以下に、本発明の実施の形態について図面を参照して説明する。

以下の説明においては、番組情報を提供するＥＰＧ（Electronic Program Guide）を扱うシステムを例に挙げて説明するが、他の情報を扱うシステムにおいても、本発明を適用することは可能である。

本発明の実施の形態について説明するが、その説明の順番について記載しておく。まず本発明をい適用するシステムの構成について説明を加える。、次に、そのようなシステムにおいて授受されるＥＰＧデータについて説明を加えるが、先に、ＥＰＧデータを取得したユーザ側のユーザ端末５３―１乃至５３−Ｎ（図３）に表示されるＥＰＧの特徴を説明した後、そのような特徴を実現するためのデータ構成などについて、ＥＰＧデータを提供する側のサーバ５２（図３）の構成を含めて説明を加える。

図３は、本発明を適用したシステムの一実施の形態の構成を示す図である。

ネットワーク５１は、インターネットやＬＡＮ（Local Area Network）で構成され、接続されている機器同士でデータの授受を行う際に用いられる。ネットワーク５１には、サーバ５２が接続されている。サーバ５２は、ＥＰＧを作成、提供する側の管理者が管理している端末である。サーバ５２からは、ユーザ端末５３−１乃至５３−Ｎからの要求に対応して、適宜、ＥＰＧのデータが、ネットワーク１を介して提供される。

ユーザ端末５３−１乃至５３−Ｎは、それぞれ、放送局５４から放送されるテレビジョン放送を受信する機能も有する。ユーザ端末５３−１乃至５３−Ｎは、それぞれ、ネットワーク５１を介してサーバ５２と接続する機能を有し、放送局５４からの番組を受信する機能を有するテレビジョン受像機やパーソナルコンピュータである。または、ネットワーク５１を介してサーバ５２と接続する機能を有するパーソナルコンピュータと、放送局５４からの番組を受信する機能を有するテレビジョン受像機という２つの端末から構成される。さらにユーザ端末５３−１乃至５３−Ｎは、それぞれ、番組を録画するための録画装置が含まれる構成とされていても良い。

すなわち、ユーザ端末５３−１乃至５３−Ｎは、それぞれ、サーバ５２とデータの授受を行う機能を有し、放送局５４からのテレビジョン放送用の番組を受信する機能を少なくとも有している、１の装置から構成される端末、または、複数の装置から構成され、それらの装置間でデータの授受を行える構成とされている端末である。

以下の説明において、ユーザ端末５３−１乃至５３−Ｎを個々に区別する必要がない場合、単に、ユーザ端末５３と記述する。また、他の装置においても同様に記述する。さらに、図３においては、サーバ５２や放送局５４を、それぞれ１台しか図示していないが、説明の都合上、そのように図示しただけであり、実際の構成を限定するものではなく、複数台存在していても、本発明を適用できる事にかわりはない。

図４は、ユーザ端末５３の内部構成例を示す図である。ここでは、ユーザ端末５３は、サーバ５２とデータの授受を行い、放送局５４からの番組を受信することができる１台の端末であるとして説明する。また、そのような端末は、パーソナルコンピュータにより構成できるため、ここでは、ユーザ端末５３は、パーソナルコンピュータであるとして説明する。なお、パーソナルコンピュータとは、デスクトップ型やノート型のものを含むことはもちろんであるが、ＰＤＡ（Personal Digital Assistance）や、携帯電話なども含む。

ユーザ端末５３のＣＰＵ（Central Processing Unit）７１は、ＲＯＭ（Read Only Memory）７２に記憶されているプログラムに従って各種の処理を実行する。ＲＡＭ（Random Access Memory）７３には、ＣＰＵ７１が各種の処理を実行する上において必要なデータやプログラムなどが適宜記憶される。入出力インタフェース７５は、キーボードやマウスから構成される入力部７６が接続され、入力部７６に入力された信号をＣＰＵ７１に出力する。また、入出力インタフェース７５には、ディスプレイやスピーカなどから構成される出力部７７も接続されている。

さらに、入出力インタフェース７５には、ハードディスクなどから構成される記憶部７８、および、ネットワーク５１を介して他の装置（例えば、サーバ５２）とデータの授受を行う通信部７９も接続されている。なお、詳細は図示しないが、通信部７９には、放送局５４からの番組を受信し、処理するためのアンテナ、チューナなども含まれる。ドライブ８０は、磁気ディスク９１、光ディスク９２、光磁気ディスク９３、半導体メモリ９４などの記録媒体からデータを読み出したり、データを書き込んだりするときに用いられる。

図５のフローチャートを参照して、ユーザ端末５３の基本的な動作について説明する。ここでは、サーバ５２により管理されているＥＰＧを取得し、処理する場合を例に挙げて説明する。以下の説明においては、ＥＰＧとは、ＥＰＧを表示させるためのデータ、および、ＥＰＧに付随するデータを含むとする。

ステップＳ１１において、ユーザ端末５３は、ネットワーク５１（図３）を介してサーバ５２にアクセスする。このアクセスの処理は、所定のブラウザが起動され、ダイアルアップ方式など所定の方式（ユーザがＩＳＰ（Internet Service Provider）と契約した内容に従った方式）により行われる。

アクセスが完了すると、ステップＳ１２において、ログインの処理が行われる。この処理は、ユーザが入力部７６を操作し、ユーザ名やパスワードを入力し、その入力された情報が、通信部７９を介してサーバ５２に対して送信されることにより行われる。

サーバ５２は、ユーザ端末５３からのアクセス（またはログイン）を受けると、管理しているＥＰＧの初期画面のデータを、ネットワーク５１を介して、アクセスしてきたユーザ端末５３に対して提供する。もちろん、ＥＰＧが提供されるのは、ログインの処理が正常に行われときであり、正常に行われなかったときには、所定のエラー処理が実行される。

サーバ５２側から提供されたデータを、ユーザ端末５３は、ステップＳ１３の処理として受信する。ＣＰＵ７１（図４）は、通信部７９により受信されたデータに基づき、出力部７７としてのディスプレイ１０１（図６）上に、ＥＰＧの初期画面（図６を参照して後述する）を表示させる。ユーザは、ディスプレイ１０１上に表示された初期画面を閲覧し、その画面内に設けられている複数のボタン（リンク先やコマンドが関連付けられているボタン）を操作する。

そのようなボタンの操作が行われると、ステップＳ１４において、その操作されたボタンに対応するデータ（指示）が、サーバ５２に送信される。そして、その指示を受信したサーバ５２からの応答としてのデータが、ステップＳ１５において受信される。そして、ステップＳ１３の処理と同様に、ＣＰＵ７１が、受信されたデータを処理することにより、ディスプレイ１０１上に、所定の画面が表示される。ステップＳ１４，Ｓ１５の処理は、必要に応じ繰り返し行われる。

図６は、ステップＳ１３においてディスプレイ１０１上に表示される初期画面の一例を示す図である。図６に示したディスプレイ１０１上には、ＥＰＧが表示されているが、そのＥＰＧの構成は、基本的に、放送局、放送時間、放送される番組が関連付けられた状態で表示されている。例えば、図６に示したＥＰＧにおいては、“放送局Ａ”で“１２時”台に放送されるのは、“番組Ａ―１”であることが示されている。このように、複数の放送局、それらの放送局で放送される番組、および、それらの番組が放送される時間が、それぞれ関連付けられ、ユーザが、一見して認識できるような表示形態で、表示される。

また、図６に示したように、例えば、“番組Ａ―１”という文字が表示されている領域内には、予約ボタン１１１が表示されている。この予約ボタン１１１が操作されると、対応する番組が、記憶部７８（図４）に記憶（録画）されるような設定が行われる。

さらに、図６に示したように、例えば、“番組Ａ―１”という文字が表示されている領域内には、オススメマーク１１２が表示されている。このオススメマーク１１２は、アクセスしてきたユーザに対してオススメする番組に付けられるマークである。ここで、“アクセスしてきたユーザに対してオススメする番組”とは、アクセスしてきたユーザ毎に、そのユーザに適した番組が提供され、ユーザ毎に異なる番組がオススメされる可能性があることを意味する。

換言すれば、オススメされる番組は、サーバ５２にアクセスしてきたユーザ全員に共通したものではなく、よって、サーバ５２側で、予めオススメ番組として設定されている番組ではなく、アクセスしてきたユーザの嗜好に合わせて、ユーザがアクセスしてきたときに、ユーザ毎に作成される情報である。このように、アクセスしてきたユーザの嗜好に合った番組がオススメとして、ユーザ側に提示されるのは、本発明の１つの特徴であり、このような特徴を実現するために、サーバ５２は、後述するようなデータベースを有し、そのデータベースを用いた処理を実行する。

このオススメマーク１１２は、図６に示した例では、星マークで示されているが、そのマークの形状などは、どのようなものでも良い。また、星マークなどで示される場合、そのマークの数により、オススメ度が異なるようにしても良い。例えば、図６においては、“番組Ａ−１”のオススメマーク１１２は、星マークが１つであるが、“番組Ｂ−１”のオススメマーク１１２は、星マークが３つであり、“番組Ｂ−１”の方が、“番組Ａ−１”よりオススメであることが示されている。

このオススメマーク１１２（星マークの数）に関するデータは、サーバ５２側で、ユーザの嗜好に関するデータを基に設定され、ＥＰＧの初期画面のデータに含まれて送信される。または、サーバ５２側から送信されてきたＥＰＧの初期画面のデータと、ユーザ端末５３側で管理しているユーザの嗜好に関するデータを基に設定されるようにしても良い。このような設定の仕方の差異は、ユーザの嗜好に関するデータ（以下、適宜、嗜好データと記述する）をサーバ５２側で管理するか、ユーザ端末５３側で管理するかにより生じるものである。ここでは、まず、サーバ５２側で、嗜好データを管理するとして説明をする。

このような、ＥＰＧの初期画面で、ユーザの嗜好に適した番組に対してオススメマーク１１２が表示されるようにするのは、サーバ５２にユーザ端末５３がアクセスした時点で、アクセスしてきたユーザを特定するための認証処理（ログイン）などが行われることを前提としている。しかしながら、例えば、初期画面として図１に示したような画面がユーザに提供され、その後、ログイン処理が実行された時点で、図６に示したような画面がユーザに提供されるようにしても良い。

オススメマーク１１２は、オススメの番組（サーバ５２側の処理として、所定の条件を満たすとして検出された番組）とされた番組名の領域に必ず表示されるようにしても良い。必ず表示されるようにした場合、同一の放送時間帯に放送される複数の番組にオススメマーク１１２が、それぞれ表示されといった状況が発生する可能性がある。しかしながら、通常、ユーザは、１つの時間帯には、１つの番組しか視聴できず、また、ユーザが所有する１つの装置では、１の時間帯には１つの番組しか録画できないので、１の時間帯に２以上のオススメマーク１１２を表示させても、結果としては、その内の２つの番組しか視聴できないと考えられる。

また、オススメマーク１１２が表示される番組が、多いと、オススメマーク１１２を表示させる意味が薄くなると考えられる。極端な例だが、全ての番組に対してオススメマーク１１２が表示されたような場合（このような状況が発生することも考えられる）、オススメマーク１１２が、実質上、意味のないものとなってしまう。

これらのことを考慮すると、オススメマーク１１２が表示される番組数に、何らかの制限を設けるようにした方が良い。例えば、同一の時間帯には、オススメマーク１１２は２番組内にする、１日分のＥＰＧ内には、オススメマーク１１２は２０番組内するなどの制御が行われるようにしても良い。

図６に示したＥＰＧの画面内には、オススメボタン１１３とランキングボタン１１４も表示されている。オススメボタン１１３は、オススメとされる番組を閲覧したときに操作されるボタンである。ランキングボタン１１４は、録画予約された数や視聴率などの基づく番組紹介を閲覧したいときに操作されるボタンである。

これらのボタンは、ユーザが入力部７７（図４）を操作し、カーソル１２１を所望のボタン上に位置した状態で、クリックなどの所定の操作が行われることにより操作されるように構成されている。

オススメボタン１１３が操作されると、図７に示したような画面に、ディスプレイ１０１上の画面が切り替えられる。図７に示した画面例では１番組分の画面しか図示しないが、オススメとされる１つの番組の詳細情報を提示する画面（以下、適宜、オススメ画面と記述する）は、ディスプレイ１０１上に複数、同様の形式で表示される。オススメ画面には、番組名表示部１５１、放送時間表示部１５２、内容表示部１５３、出演者表示部１５４、理由表示部１５５、および、オススメ度表示部１５６が設けられている。

番組名表示部１５１には、オススメとされる番組名が表示され、放送時間表示部１５２には、その番組が放送される日時が表示され、内容表示部１５３には、その番組の内容が簡潔な文章で示され、出演者表示部１５４には、その番組に出演する主な出演者の名前が表示される。そして、理由表示部１５５には、なぜその番組がオススメなのかを、ユーザに認識させるようなオススメ理由が表示され、オススメ度表示部１５６には、オススメ理由から総合的に算出されるオススメ度が、表示される。

図７に示した例では、オススメ度表示部１５６には点数が表示されているが、図６に示したオススメマーク１１２と同様に、星マークなどのマーク（および、そのマークの個数）で表示されるようにしても良い。

図７に示したオススメ画面のうち、理由表示部１５５を表示させるのは、本発明の１つの特徴である。このような特徴を有することにより、ユーザは、なぜその番組がオススメとして提供されているのか、自分のどのような嗜好に対してマッチングしているのかなどを認識することができる。そして、ユーザは、このような理由を閲覧することにより、視聴（録画）したい番組を選択しやすい（自分の嗜好に合った番組を見つけやすい）ようになる。

また本発明の１つの特徴としては、このようなオススメ画面は、既存のものが提供されるのではなく（サーバ５２側が、アクセスしてきたユーザ全てに対して同様のものを提供するのではなく）、アクセスしてきたユーザの嗜好のデータを基に、そのユーザの嗜好に合った番組が選択され、提供される点である。このような特徴のために、ユーザ側としては、提供される情報に信頼性を持つことができ、所望の番組を検索しやすくなり、使い勝手がよいＥＰＧが提供されていると感じることが可能となる。よって、サーバ５２へのアクセスが増加すると考えられ、会員数などを増加させることが可能になると考えられる。

図７に示したオススメ画面についてさらに説明を加えるに、理由表示部１５５には、複数の情報が表示される。表示される内容は、例えば、図７においては、“よく見る出演者”、“登録ジャンル”、“よく見るキーワード”、“同じ番組を録画した人の興味”などの項目があるが、後述するようにさまざまな項目（情報）が考えられる。これらの理由表示部１５５に表示される情報に関しては、サーバ５２側で管理されているデータベースの内容などに関わる。

図７に示した例では、例えば、“よく見る出演者”として「人物Ａ」が挙げられ、さらに、その「人物Ａ」に対する点数（図７では１７．０点）が表示されている。この点数は、オススメとしてサーバ５２側が提供する番組を検索する際、「出演者Ａ」に対してマッチングしたスコアであり、このスコアが高いほど、ユーザの嗜好に合っていると考えられる。

この点数について説明を加えるに、図７に示した例では、単に１７．０点と表示されているだけであるが、さらに、次のような詳細な表示の形態も考えられる。例えば、“１７．０点（８．９，３．８）”といったような括弧書きでさらに詳細な点数が表示される。括弧書きの点数のうち、前半の“８．９”は、番組に対する重み付けの値（後述するT_PRG_VALUEの値）であり、後半の“３．８”は、ユーザに対する重み付けの値（後述するT_UM_VALUEの値）である。括弧外の点（この場合、１７．０点）は、この２つの重み付けの値の責に所定のパラメータを乗算した値である。

ところで、図７に示したように、例えば、“よく見る出演者”という同一の項目に対して、「人物Ａ」、「人物Ｃ」、および「人物Ｄ」という３つの情報が表示され、それぞれの情報に対する点数がそれぞれ表示されているような場合、以下のような問題点がある。図７に示した例では、理由表示部１５５に表示される項目の内の一部だけを示した状態を示しているが、複数ある項目の全部が表示され、それぞれの項目に対して複数の情報が、複数行にわたって分散的に表示され、さらに、それらの情報毎に点数までも表示されるとなると理由表示部１５５の領域の大きさは大きいものとなってしまう。また、情報を羅列してもユーザにとっては、見やすい画面であるとは言えない。さらに、点数を表示しても、その点数からユーザが得る情報量は少なく（点数から得られる情報を判断することはユーザにとっては必ずしも容易なことであるとは考えられないため）、所望の番組の検索には、あまり意味を持たない情報であると考えられる。

そこで、オススメ画面を図８に示したようにしても良い。図８に示したオススメ画面の理由表示部１５５には、１つの項目に対して、複数の情報が行を改めることなく連続的に表示され、点数は表示されないようになっている。従って、同じ項目（例えば、“よく見る出演者”）が、図７に示した例のように、何度も表示されるようなことは、図８における表示形態ではない。このようにすれば、理由表示部１５５の領域が大きくなってしまうようなことを防ぐことができる。また、情報がコンパクトにまとまっているので、ユーザは、それらの情報を見やすく、各情報から得られる情報は多いいと考えられる。従って、ユーザが所望の番組をより検索しやすくなると考えられる。

図７または図８に示したオススメ画面のうち、ユーザに提示される画面はどちらでも良い。また、表示形態などは、図７または図８に示した画面に限定されるものではないため、どのような形態、例えば、各表示部の順序が入れ替わった状態で表示される、図示していない表示部が設けられる形態などで情報が提示されるようにしても良い。しかしながら、本発明を適用することにより、オススメ画面、および、そのオススメ画面が表示される前に表示される画面（上述した実施の形態では、初期画面と称した画面）においては、以下のような特徴が少なくともある。

オススメ画面のみ、または、初期画面とオススメ画面は、ユーザの嗜好を考慮した画面（情報）となっており、ユーザ毎に適した情報が提示される。その提示される情報は、見やすい形態で提示される。このような特徴を実現するための、サーバ５２の構成、管理されるデータベース、そのデータベースが用いられた処理などについて、以下に説明を加える。

以下の説明の概略を示しておくと、まず、サーバ５２の内部構成について説明を加え、その次に、データベースについての説明を加える。そして、そのデータベースにより管理されるデータの作成について説明を加え、作成されたデータを用いた処理、特に、オススメ画面に関わる処理について説明を加える。

図９は、サーバ５２の内部構成例を示す図である。サーバ５２は、パーソナルコンピュータなどから構成することが可能である。サーバ５２のＣＰＵ２０１は、ＲＯＭ２０２に記憶されているプログラムに従って各種の処理を実行する。ＲＡＭ２０３には、ＣＰＵ２０１が各種の処理を実行する上において必要なデータやプログラムなどが適宜記憶される。入出力インタフェース２０５は、キーボードやマウスから構成される入力部２０６が接続され、入力部２０６に入力された信号をＣＰＵ２０１に出力する。また、入出力インタフェース２０５には、ディスプレイやスピーカなどから構成される出力部２０７も接続されている。

さらに、入出力インタフェース２０５には、ハードディスクなどから構成される記憶部２０８、および、ネットワーク５１を介して他の装置、例えば、ユーザ端末５３とデータの授受を行う通信部２０９も接続されている。ドライブ２１０は、磁気ディスク、光ディスク、光磁気ディスク、半導体メモリなどの記録媒体からデータを読み出したり、データを書き込んだりするときに用いられる。

サーバ５２は、上述したようにＥＰＧやオススメ画面を作成し、ユーザ端末５３側に提供する機能を有する端末であるが、その機能を実行するためのプログラムは、記憶部２０８に記憶され、ＲＡＭ２０３に展開され、その展開されたプログラムに基づいてＣＰＵ２０１が処理を実行することにより行われる。図１０は、サーバ５２における機能を説明するための機能ブロック図である。

ログ生成機能２３１は、ユーザが（ユーザ端末５３が）アクセスしたときの日時など、また、そのユーザ受けたサービスの使用情報（所定の番組の録画予約）などに基づくログを生成し、記憶部２０８に記憶させ、その記憶されたログファイルを管理する機能である。ユーザ管理機能２３２は、ユーザの新規の登録、既に登録されているユーザの削除、ユーザがログインしてきたときの処理を行う機能であり、必要に応じ、ユーザからの操作（指示）を管理する機能である。

情報選別機能２３３は、後述する対象情報メタデータベースとユーザモデルデーターベースを参照して、アクセスしてきた（所定の要求を出してきた）ユーザに対して、そのユーザに適した情報を、対象となっている情報データベースから取捨選択し、ユーザ側に提供する機能である。サービス管理機能２３４は、サービス管理者（サーバ５２の管理者や、サーバ５２に対してＥＰＧに関わるデータを供給する者）が、各機能や、各データベース、関連情報などの追加、変更、削除などの編集を行うための機能である。

ユーザモデル管理機能２３５は、ユーザあるいはサービスの管理者から、直接的に入力されるか、または、ログデータベースのマイニング（Mining）結果に基づく処理により、ユーザモデルデータベースの登録、更新、削除などを行う機能である。詳細は後述するが、ユーザモデル管理機能２３５は、ユーザの嗜好に関するデータを取得し、管理するが、その取得には、ユーザ自身が登録したデータを取得する、学習により取得されたデータを取得する、フィルタリング処理により取得された情報を取得するといった方法がある。

情報通信機能２３６は、選別された情報などをユーザ側に提供する機能であり、ユーザ側からのデータを受信する機能である。対象情報メタデータ管理機能２３７は、ユーザあるいはサービスの管理者からの直接的な入力や、情報データベースやその他のマスターなどの関連情報をマイニングした結果に基づく処理により、情報メタデータベースへの情報の登録、更新、削除などを行う機能である。サービス一般機能２３８は、サーバ５２がサービスを提供するうえで必要となるが、上述した機能では行われない処理を実行するための機能である。

このような機能を、サーバ５２は備えている。このような機能は、ここでは、サーバ５２が備えているとして説明を続けるが、これらの機能のうち、一部の機能は、ユーザ端末５３側に持たせることも可能である。また、これらの機能の全て、または、一部をサーバ５２以外の端末に持たせ、その端末とデータの授受を行うことにより、結果として、サーバ５２が機能を実現できるように構成しても良い。

例えば、ユーザ端末５３側で、ログ生成機能２３１や、ユーザモデル管理機能２３５を有するようにし（ユーザのプライベートな情報や嗜好に関わるデータを管理する機能を、ユーザ側が管理できるようにし）、これらの機能が担当する後述するような処理を、サーバ５２側でなく、ユーザ端末５３側で行うようにしても良い。

このような機能が用いる（管理する）データベースについて説明する。データベースは、記憶部２０８に構築される。図１１は、記憶部２０８に構築されるデータベースを示す図である。図１１に示した例では、記憶部２０８には、データベースとして、マスターデータベース２５１、ターゲットデータベース２５２、ログデータベース２５３、および、ユーザデータベース２５４が構築されている。

マスターデータベース２５１は、ＥＰＧを作成する際に用いられるデータベースや、ユーザに関する情報（例えば、年齢など）を管理するためのデータベースなどの複数のデータベースにより構成される。ターゲットデータベース２５２は、オススメ画面などを作成する際に、数値計算などが行われるが、その計算に用いられるデータベースなどの複数のデータベースにより構成される。ログデータベース２５３は、ログ生成機能２３１により生成され、管理されるデータベースである。ユーザデータベース２５４は、会員登録しているユーザの情報などを管理するためのデータベースである。

マスターデータベース２５１は、図１２乃至図２１の各図に示すデータベースから構成されている。なお、図１２乃至図２１に示すデータベース内のデータは、説明の都合上、一部分のデータのみを図示してある。

図１２に示したデータベースは、M_CATEGORYデータベース２７１であり、放送される番組のカテゴリー（ジャンル）を管理するために設けられている。このM_CATEGORYデータベース２７１には、AttributeIDとして、“００１”という識別子が割り当てられている。M_CATEGORYデータベース２７１は、登録されているカテゴリーを識別するための識別子（CategoryID）とカテゴリー（Category）を関連付けて管理する。例えば、図１２に示したM_CATEGORYデータベース２７１において、CategoryID“1000”は、“スポーツ”というカテゴリに割り当てられている。

図１３に示したデータベースは、M_PERSONデータベース２７２であり、放送される番組に出演する人物（司会者、俳優、女優、文化人、政治家など）を管理するために設けられている。このM_PERSONデータベース２７２には、AttributeIDとして、“００２”という識別子が割り当てられている。M_PERSONデータベース２７２は、登録されている人物名を識別するための識別子（PersonID）、人物名（Name）、および、その人物名の読み方（KanaName）を、それぞれ関連付けて管理する。例えば、図１３に示したM_PERSONデータベース２７２において、PersonIDとして“0000000001”は、“人物Ａ”という人物に割り当てられており、その“人物Ａ”の読み方は、“ジンブツエー”であることが関連付けられている。

図１４に示したデータベースは、M_PERSON_CHARACTERデータベース２７３であり、放送される番組に出演する人物のキャラクター（特徴）を管理するために設けられている。M_PERSON_CHARACTERデータベース２７３には、AttributeIDとして、“００３”という識別子が割り当てられている。M_PERSON_CHARACTERデータベース２７３は、番組に出演する人物のキャラクターを識別するための識別子（CharacterID）とキャラクター（Character）が、関連付けて管理する。なお、キャラクターとは、一般的に使われている意味あいを本発明においても適用するが、ここでは特に、視聴者（ユーザ）が、その人物に対してどのような印象を持っているか、その人物を表すのにまたは特徴として適している言葉などを意味する。

例えば、図１４に示したM_PERSON_CHARACTERデータベース２７３において、CharacterID“００１”は、“司会者系”というキャラクターが関連付けられている。なお、図１４に示した例では、１つのCharacterIDには、１つの言葉が関連付けられている例を示したが、１つのCharacterIDに、複数の言葉（類似する言葉）が関連付けらているようにしても良い。例えば、CharacterIDとして“００４”が割り当てられているのは、“身近”であるが、“身近、親しみ”などと、類似する複数の言葉と関連付けられるようにしても良い。

図１５に示したデータベースは、M_VIEW_TYPEデータベース２７４であり、ユーザの視聴タイプ（どのような番組を好むか、どのような形態で視聴するかなど）を表す言葉を管理するために設けられている。このM_VIEW_TYPEデータベース２７４には、AttributeIDとして、“００４”が割り当てられている。M_VIEW_TYPEデータベース２７４は、視聴タイプを識別するための識別子（ViewID）と視聴タイプ（ViewType）を関連付けて管理する。例えば、図１５に示したM_VIEW_TYPEデータベース２７４において、ViewID“001”は、“笑い刺激型”という視聴タイプに割り当てられている。

図１６に示したデータベースは、M_KEYWORDデータベース２７５であり、番組の特徴を表すキーワード（単語）を管理するために設けられている。このM_KEYWORDデータベース２７５には、AttributeIDとして、“００５”が割り当てられている。M_KEYWORDデータベース２７３は、キーワードを識別するための識別子（KyewordID）とキーワード（Keyword）を関連付けて管理する。なお、キーワードとは、一般的に使われている意味あいを本発明においても適用するが、例えば、“番組Ａ”の内容を１または複数の単語で表すと、どのような単語が一番適しているか（言い表せているか）を示す言葉であるとする。

例えば、図１６に示したM_KEYWORDデータベース２７３において、KeywordID“0000000001”は、“情報”というキーワードに割り当てられている。

図１７に示したデータベースは、M_KEYWORD_1データベース２７６であり、上述したM_KEYWORDデータベース２７５と基本的に同様のデータを管理するために設けられている。このM_KEYWORD_1データベース２７６は、図１６に示したM_KEYWORDデータベース２７５と比較し、リーゾン（Reason）という項目も、KeywordIDやKeywordと、それぞれ関連付けて管理する。このReasonという項目に記載されている言葉は、例えば、図８において、理由表示部１５５に表示される言葉であり、ユーザ側に提示される言葉（単語）である。

すなわち、Keywordという項目に書かれているキーワードは、マッチングなどの処理を行うとき等に用いられる言葉であり、Reasonという項目に書かれている言葉は、マッチングが行われた結果、そのマッチングのときの得点が高く、ユーザ側にオススメ理由として提示する際に、実際に提示される言葉が書かれている。

例えば、KeywordIDが“0000000006”の“エロティック”というキーワードは、マッチングのときに適切な番組を検索するのには適していても、実際に、ユーザに番組をオススメとして提示する際には、あまり好ましくない言葉であると考えられる。そこで、“エロティック”という言葉を表示されないようにするために、Reasonの部分は空欄（Null）とされている。

また、例えば、KeywordIDが“000000000８”の“得”というキーワードは、マッチングのときに適切な番組を検索するのには適していても、実際に、ユーザに番組をオススメとして提示する際には、“得”とだけ表示しても具体的な意味がつかみづらく、不親切な表示となってしまうと考えられ、ユーザに提示するには適切ではない。そこで、Reasonの部分には“お得な情報”と記載しておき、“得”というキーワードがユーザに提示される際には、“お得な情報”という言葉が代わりに提示されるようにする。

このように、Reasonという項目を設けることにより、マッチングなどの処理に用いられる言葉と、ユーザ側に提示される言葉とを使いわけることが可能となる。

図１８に示したデータベースは、M_KEYWORD_2データベース２７７であり、上述したM_KEYWORDデータベース２７５と基本的に同様のデータを管理するために設けられている。このM_KEYWORD_2データベース２７７は、図１６に示したM_KEYWORDデータベース２７５と比較し、Displayという項目も、KeywordIDやKeywordと、それぞれ関連付けて管理する。このDisplayという項目に記載されているのはフラグであり、そのフラグは、Keywordの項目に記載されている言葉を、ユーザ側に提示するか否かを表すものとされている。

図１８に示した例で、“１”は、ユーザ側に提示し、“０”は、ユーザ側に提示しないとして設定されていることを示す。例えば、KeywordIDが“0000000001”と割り当てられている“情報”というキーワードは、オススメ理由として、ユーザ側に提示されるが、KeywordIDが“0000000006”と割り当てられている“エロティック”というキーワードは、オススメ理由として、ユーザ側には提示されない。

図１６乃至図１８に示したデータベースのうち、いずれか１つのデータベースがマスターデータベース２５１に管理されていれば良い。よって、図１６乃至図１８に示した各データベースのAttributeIDは、“００５”と共通のIDにしてある。以下の説明においては、特に断りのない限り、図１６に示したM_KEYWORDデータベース２７５が、マスターデータベース２５１に管理されているとして説明する。

図１９に示したデータベースは、M_AGEデータベース２７８であり、ユーザの年齢層を管理するために設けられている。このM_AGEデータベース２７８には、AttributeIDとして、“００６”が割り当てられている。M_AGEデータベース２７８は、年齢を識別するための識別子（AgeID）、年齢の幅を示し、その幅を識別するための名前（AgeName）、その年齢の幅の始めの年齢（StartAge）、および、その年齢の幅の終わりの年齢（EndAge）を、それぞれ関連付けて管理する。

例えば、図１９に示したM_AGEデータベース２７８において、AgeID“001”は、“０から４”というAgeNameに関連付けられ、“０”というStartAgeにも関連付けられ、さらに、“４”というEndAgeにも関連付けられている。

図２０に示したデータベースは、M_GENDERデータベース２７９であり、ユーザの性別を管理するために設けられている。このM_GENDERデータベース２７９には、AttributeIDとして、“００７”が割り当てられている。M_GENDERデータベース２７９は、性別を識別するための識別子（GenderID）と性別（GenderType）を関連付けて管理する。例えば、図２０に示したM_GENDERデータベース２７９において、GenderID“001”は、“男性”というGenderTypeに関連付けられている。

図２１に示したデータベースは、M_REASONデータベース２８０であり、理由表示部１５５（図７または図８）に表示される言葉を制御するためのデータを管理する。M_REASONデータベース２８０は、AttributeID、ValueID、およびReasonを、それぞれ関連付けて管理する。AttributeIDは、上述したように、各データベースを識別するために割り振られたIDであり、例えば、図１２に示したM_CATEGORYデータベース２７１には、AttributeIDとして“００１”が割り振られている。

ValueIDは、各データベースが管理するIDのことであり、CategoryID（図１２）、PersonID（図１３）、CharacterID（図１４）、ViewID（図１５）、KeywordID（図１６）、AgeID（図１９）、および、GenderID（図２０）のことである。Reasonは、図１７や図１８を参照して説明したように、理由表示部１５５（図７，８）に表示される言葉のことである。

例えば、図２１に示したM_REASONデータベース２８０のAttributeIDが“００１”である場合、M_CATEGORYデータベース２７１のことを示し、加えてValueIDが“1000”である場合、M_CATEGORYデータベース２７１のCategoryIDが“1000”のことを示す。そして、M_REASONデータベース２８０のAttributeIDが“００１”、ValueIDが“1000”で示される言葉が、ユーザに提示される場合、Reasonの項目の対応する欄に記載されている“スポーツ”という言葉が提示されることとなる。

このM_REASONデータベース２８０は、上述した図１２乃至図１９（図１７と図１８は除く）にそれぞれ示したデータベースを、理由表示部１５５（図８）に表示させる言葉を制御するために、１つにまとめたものである。制御するためにというのは、上述したように、ユーザ側に提示するには好ましくない言葉や、そのままではユーザ側に提示するには適していない言葉があり、そのような言葉を適切に処理するためという意味である。

例えば、ユーザ側に提示するには好ましくない言葉として、上述した例では“エロティック”という言葉を挙げたが、この“エロティック”という言葉は、図１６に示したM_KEYWORDデータベース２７５に管理されており、KeywordIDとして“0000000006”が割り当てられている。M_KEYWORDデータベース２７５のAttributeIDは“００５”であるので、図２１に示したM_REASONデータベース２８０のAttributeIDが“００５”で、ValueIDが“0000000006”を見ると、記載がない（削除されている）ことがわかる。M_REASONデータベース２８０に記載がないということは、ユーザ側には、提示されないということになる。

よって、M_REASONデータベース２８０に記載しなければ、ユーザ側に提示するには好ましくない言葉は、提示されないようにするといった制御を行えることになる。

また、例えば、そのままではユーザ側に提示するには適していない言葉として、上述した例では“得”という言葉を挙げたが、この“得”という言葉は、図１６に示したM_KEYWORDデータベース２７５に管理されており、KeywordIDとして“0000000008”が割り当てられている。M_KEYWORDデータベース２７５のAttributeIDは“００５”であるので、図２１に示したM_REASONデータベース２８０のAttributeIDが“００５”で、ValueIDが“0000000008”を見ると、“お得な情報”という記載がある。M_REASONデータベース２８０に“お得な情報”と記載があるということは、ユーザ側に“得”という言葉（キーワード）が提示されるときには、実際には“お得な情報”という言葉が提示されることになる。

よって、M_REASONデータベース２８０にユーザ側に提示したい言葉を記載しておけば、そのままではユーザ側に提示するには適していない言葉であっても、実際に提示されるときには、ユーザ側に提示するのに適した言葉で提示できるようにするといった制御を行えるようになる。

すなわち、番組を推薦する場合を考えると、番組のスコアリング（マッチング）には有効な番組を特徴付ける語であっても、その語自体が、例えば、成人向けの用語、一文字の語、メジャーでないキーワード、一般的過ぎて理由になりにくいキーワード、オススメ理由として成立していないキーワードなどであり、オススメ理由としてユーザに提示するには馴染まないような語である場合、そのような語を表示させない、または、他の語として表示させるといった、自由度の高い表示の制御を行うことが可能となる。

また、M_REASONデータベース２８０という、オススメ理由の表示を制御するためのデータベースを設けることにより、図１２乃至図２０に示したマスターデータベースに基づく表示とは異なる表示が行えるようになるため、例えば、形態素解析の結果、“恋い”、“恋”、“こい”などの全てのValueに対して、「恋愛好きに」といったオススメの理由の表示が可能となる。

このようなデータを管理するM_REASONデータベース２８０をマスターデータベース２５１で管理させることにより、上述したように、適切に、ユーザ側に提示する言葉を制御することができるといった効果の他に、以下のような効果もある。その効果について図２２と図２３を参照して説明する。

図２２と図２３においては、オススメ理由として、AttributeIDが“００１”でCategoryIDが“1000”の言葉（検索言葉Ａとする）、AttributeIDが“００２”でPersonIDが“0000000001”の言葉（検索言葉Ｂとする）、AttributeIDが“００２”でPersonIDが“0000000002”の言葉（検索言葉Ｃとする）、および、AttributeIDが“００５”でKeywordIDが“0000000001”の言葉（検索言葉Ｄとする）を、ユーザ側に提示すると決定された場合を例に挙げて説明する。

図２２を参照して、まず、M_REASONデータベース２８０が存在していないとき、従って、図１２乃至図２０（図１７、図１８を除く）のみが存在しているときの検索の仕方について説明する。検索言葉Ａが検索される際、AttributeIDとして“００１”が割り当てられているM_CATEGORYデータベース２７１（図１２）内が検索される。そして、CategoryIDが“1000”である“スポーツ”という言葉が検索結果とされる。同様に、検索言葉Ｂが検索される際、AttributeIDとして“００２”が割り当てられているM_PERSONデータベース２７２（図１３）内が検索され、PersonIDが“0000000001”である“人物Ａ”という言葉が検索結果とされる。

検索言葉Ｂと同様に、検索言葉Ｃも、M_PERSONデータベース２７２が参照され、“人物Ｂ”という言葉が検索結果とされる。そして、検索言葉Ｄは、M_KEYWORDデータベース２７５が参照され、“情報”という言葉が検索結果とされる。

この場合、４つの検索言葉を検索するのに、３つのデータベースを参照しなければならない。

これに対し、M_REASONデータベース２８０が存在する場合、図２３を参照して以下に説明するように検索が行われる。検索言葉Ａが検索される場合、M_REASONデータベース２８０が参照される。その参照される位置は、AttributeIDが“００１”であり、ValueIDが“１０００”のところである。その結果、“スポーツ”という言葉が検索結果とされる。同じように、検索言葉Ｂ乃至Ｄも、M_REASONデータベース２８０が参照されて、それぞれ検索結果が出される。

この場合、４つの検索言葉を検索するのに、１つのデータベースのみを参照すればよい。

このように、M_REASONデータベース２８０を設けることにより、検索を実行する際、複数のデータベースを参照する必要はなく、M_REASONデータベース２８０のみを参照すればよいので、検索に要する時間を短くすることができる。このことは、ユーザがオススメ画面を要求してから、そのユーザに対するオススメ画面を返すまでにかかる時間が短くなることを意味し、リアルタイムに返答を返さなくてはならないシステムにおいて、有効な手段である。

このように、マスターデータベース２５１には、ＥＰＧの作成、オススメ画面の作成に必要なデータが管理されている。

次に、ターゲットデータベース２５２（図１１）について説明する。

ターゲットデータベース２５２は、オススメ画面を作成する際、ユーザの嗜好と番組とのマッチングを取るためのデータ、ユーザの嗜好をより詳細なものとするための学習機能を実現するためのデータなどから構成される。

図２４に示したデータベースは、T_PERSON_TARGET_GENDERデータベース３１１であり、番組に出演する人物（Person）が、どのような性別（Gender）の人々に人気があるか等を数値化したデータを管理する。T_PERSON_TARGET_GENDERデータベース３１１は、PersonID、GenderID、および、Scoreを関連付けて管理する。PersonIDは、図１３に示したM_PERSONデータベース２７２が管理するPersonIDと同じIDとされている。すなわち、例えば、PersonID“0000000001”は、“人物Ａ”のことを意味する。

GenderIDは、図２０に示したM_GENDERデータベース２７９が管理するGenderIDと同じIDとされている。すなわち、例えば、GenderIDが“００１”は、“男性”のことを意味する。Scoreは、PersonIDに対応する人物は、GenderIDに対応する性別の人に対して、どの程度の数値（重み付け）を有するかを示す値である。例えば、人物Ａが、男性に人気があるなら、数値を高くするまたは低く設定される。

数値が高く設定される場合、人気があるので、マッチングが行われるときに検出される可能性を高くするという意図があるときである。逆に、数値が低く設定される場合、人気があるので、沢山の番組に出ている、汎用すぎる等の理由から、マッチングが行われるとき、あまり重要な要素とならないようにするという意図があるときである。どちらに設定するかは、ＥＰＧを管理する管理者の考え、利用するユーザの特徴（どの性別のユーザが多いか、どの年代のユーザが多いかなど）、システムへの負荷などを考慮して設定されればよい。

なお、他のターゲットデータベースも、それぞれ、ターゲットとする要素に関わる数値を管理するが、その数値が高い値として設定されるか、低い値として設定されるかは、上述したようなことが考慮されて設定される。

図２５に示したデータベースは、T_PERSON_TARGET_AGEデータベース３１２であり、番組に出演する人物（Person）が、どのような年齢（Age）の人々に人気があるか等を数値化したデータを管理する。T_PERSON_TARGET_AGEデータベース３１２は、PersonID、AgeID、および、Scoreを関連付けて管理する。このT_PERSON_TARGET_AGEデータベース３１２は、PersonIDは、図１３に示したM_PERSONデータベース２７２が管理するPersonIDと同じIDとされている。

AgeIDは、図１９に示したM_AGEデータベース２７８が管理するAgeIDと同じIDとされている。すなわち、例えば、AgeID“００１”は、“０から４”歳のことを意味する。Scoreは、PersonIDに対応する人物は、AgeIDに対応する年齢の人に対して、どの程度の数値（重み付け）を有するかを示す値である。例えば、人物Ａが、０から４歳（赤ちゃん）に人気があるなら、数値が高くまたは低く設定される。

図２６に示したデータベースは、T_PERSON_VIEW_TYPEデータベース３１３であり、番組に出演する人物が、どのような視聴タイプに適しているか等を数値化したデータを管理する。T_PERSON_VIEW_TYPEデータベース３１３は、PersonID、ViewID、および、Scoreを関連付けて管理する。このPersonIDも、図１３に示したM_PERSONデータベース２７２が管理するPersonIDと同じIDとされている。

ViewIDは、図１５に示したM_VIEW_TYPEデータベース２７４が管理するViewIDと同じIDとされてる。すなわち、例えば、ViewID“００１”は、“笑い刺激型”のことを意味する。Scoreは、PersonIDに対応する人物は、ViewIDに対応する視聴タイプに対して、どの程度の数値（重み付け）を有するかを示す値である。例えば、人物Ａが、笑い刺激型である（お笑い番組に良く出る芸人）なら、数値が高くまたは低く設定される。

図２７に示したデータベースは、T_PERSON_CHARACTERデータベース３１４であり、番組に出演する人物が、どのようなキャラクタ（特徴）を有しているか等を数値化したデータを管理する。T_PERSON_CHARACTERデータベース３１４は、PersonID、CharacterID、および、Scoreを関連付けて管理する。このPersonIDも、図１３に示したM_PERSONデータベース２７２が管理するPersonIDと同じIDとされている。

CharacterIDは、図１４に示したM_PERSON_CHARACTERデータベース２７３が管理するCharacterIDと同じIDとされてる。すなわち、例えば、CharacterID“００１”は、“司会者系”のことを意味する。Scoreは、PersonIDに対応する人物は、CharacterIDに対応するキャラクタに対して、どの程度の数値（重み付け）を有するかを示す値である。例えば、人物Ａが、バラエティ番組などで司会者をつとめることが多い司会者系であるなら、数値が高くまたは低く設定される。

図２８に示したデータベースは、T_PRG_VALUデータベース３１５であり、所定の番組と、その番組に関連する事項を関連付けて管理する。T_PRG_VALUデータベース３１５は、ProgramID、Attribute、および、ValueIDを関連付けて管理する。ProgramIDは、各番組を識別するために各番組に割り当てられている識別子である。

Attributは、どのデータベースに対する特性であるかを示すデータである、AttributeIDで記載することも可能である。ValueIDは、図２４に示したM_REASONデータベース２８０が管理するValueIDと同じIDとされてる。すなわち、例えば、AttributeIDが“００２”（すなわち、AttributeとしてはPerson）で、ValueIDが“１０００”は、“人物Ａ”のことを意味する。このように、T_PRG_VALUEデータベース３１５は、所定の番組と、その番組に出演している人物（Person）や、その番組を特徴付けるキーワード（Keyword）などを関連付けるためのデータベースとして用いられる。

図２９に示しデータベースは、T_PRG_VALUEデータベース３１６であり、番組自体の重み付けの数値を管理する。このT_PRG_VALUEデータベース３１６は、図２８に示したT_PRG_VALUEデータベース３１５に、Scoreをさらに関連付けて管理する構成とされている。ただし、図２９に示したT_PRG_VALUEデータベース３１６では、Attributeではなく、AttributeIDを管理する。

例えば、図２９に示したT_PRG_VALUEデータベース３１６において、ProgramIDとして“1000000030000029”というIDが割り当てられている番組は、AttributeIDが“００１”、ValueIDが“１０００”に対して“0.65193365995972070000”という数値が与えられている。

スコアリングの計算のときに、このScoreの値が用いられるが、そのスコアリングの計算時には、AttributeIDとValueIDの組から一意にScore値が求められるため、AttributeIDとValueIDの組が、どのような語に関連付けられているかを判別する必要はないが、説明のために判別すると、AttributeIDが“００１”、ValueIDが“１０００”は、図２１に示したM_REASONデータベース２８０を参照するに“スポーツ”である。よって、ここでは、ProgramIDとして“1000000030000029”というIDが割り当てられている番組は、“スポーツ”という要素に対しては、“0.65193365995972070000”という数値を有することになる。

このように、このT_PRG_VALUEデータベース３１６も、複数のAttributeIDを含むため、それぞれの要素を検出する必要がある場合、複数の対応するマスターデータベースを参照しなくてはならないが、M_REASONデータベース２８０を設けることにより、このM_REASONデータベース２８０のみを参照するだけで、必要な要素を検出することが可能となる。ただし、M_REASONデータベース２８０には、ユーザ側に提示するにはふさわしくないキーワードなどは削除されている（記載されていない）ため、必要に応じてM_REASONデータベース２８０を参照するようにしても、削除されている語は検出することはできないので、処理に必要ならば、M_REASONデータベース２８０以外のマスターデータベースを参照する必要がある。

図３０に示したデータベースは、T_UM_VALUEデータベース３１７であり、ユーザの嗜好に関するデータを管理するために設けられている。T_UM_VALUEデータベース３１７は、MemberID、UMTypeID、AttributeID、ValueID、および、Scoreを関連付けて管理する。MemberIDは、ユーザ登録しているユーザに対して割り当てられた識別子である。UMTypeIDは、この要素は、何に基づいて設定されたものであるかを示す。“何に基づいて”とは、ここでは、登録、学習、フィルタリングに基づく場合が考えられる。

例えば、図３０を参照するに、１行目のAttributeIDが“００１”でValueIDが“１０００”の要素は、図２１のM_REASONデータベース２８０を参照するに、“スポーツ”という要素であるが、その要素を、ユーザが、自分は“スポーツ”が好きであると登録してあった場合には、UMTypeIDは“１”と設定される。

図３０を参照するに、２行目のAttributeIDが“００１”でValueIDが“１００１”の要素は、図２１のM_REASONデータベース２８０を参照するに、“スポーツ：野球”という要素であるが、その要素は、ユーザが良く視聴している番組を解析した結果、スポーツの中でも“野球”が好きであると判断され、その結果設定された要素である場合には、UMTypeIDは“２”と設定される。

図３０を参照するに、３行目のAttributeIDが“００２”でValueIDが“0000000001”の要素は、図２１のM_REASONデータベース２８０を参照するに、“人物Ａ”という要素であるが、その要素を、後述するフィルタリングの処理の結果、“人物Ａ”が好きであろうと判断され、その結果設定された要素である場合には、UMTypeIDは“３”と設定される。

本実施の形態においては、このように、ユーザにオススメする番組を検出する際に用いられる要素は、ユーザ自身による登録により設定され、ユーザの嗜好を学習することにより設定され、さらに、フィルタリングの処理により設定される。このようにすることで、よりユーザの嗜好を的確に判断し、オススメの番組を提示できるようになる。例えば、ユーザ自身による登録だけに依存すると、あまり多くの要素を登録することができない。例えば、３万個の要素がある場合、その３万個の要素の中から、ユーザ自身が、自分に合う要素を登録するというのは、不可能なこと（可能であってもユーザに取っては煩雑な処理）となってしまう。

よって、例えば、“スポーツ”（AttributeIDが００１でValueIDが１０００）などという広い範囲のカテゴリーは設定できても、スポーツの中でも“野球”といった細かい設定はできない可能性がある。しかしながら、ユーザが“スポーツ”という要素しか設定していなくても、そのユーザが“野球”をよく視聴していれば、学習という機能により、“スポーツ：野球”（AttributeIDが００１でValueIDが１００１）の要素も設定されることになる。さらにフィルタという機能を設けることにより、後述するように、ユーザの嗜好に合っているはずと推測されるが、ユーザが登録もせず、学習の結果でも設定されないような要素も設定することが可能となる。

なお、このように登録、学習、フィルタという３つの処理で要素が設定されるわけだが、ユーザ自身が登録した要素の方が、他の処理で設定された要素よりも重要視され、学習により設定された要素の方が、フィルタという処理で設定された要素よりも重要視される方が好ましい。そのような重み付けに関することは、図３０に示したT_UM_VALUEデータベース３１７のScoreの数値を変えることにより、制御することができる。

図２２乃至図３０を参照して説明したようなデータベースが、ターゲットデータベース２５２に管理されている。

ここで、T_PRG_VALUEデータベース３１５の作成について、図３１のフローチャートを参照して説明する。図３１に示したフローチャートに基づく処理は、ＥＰＧのデータが作成された際に行われる（放送する番組やその番組に出演する出演者などが決定し、ＥＰＧを作成するためのデータがそろった時点で行われる）。また、図３１に示したフローチャートに基づく処理は、サーバ５２のＣＰＵ２０１（図９）が実現する対象情報メタデータ管理機能２３７（図１０）が実行する。または、管理者が手作業で行いデータを入力することも可能である。ここでは、ＣＰＵ２０１が実行するとして説明する。他のフローチャートの処理も、断りのないかぎり、ＣＰＵ２０１（CPU２０１が実現する機能）が実行するとして説明する。

ステップＳ３１において、ＣＰＵ３１は、T_PRG_VALUEデータベース３１５に追加するデータを取得する。ステップＳ３１において取得されるデータは、番組に出演する出演者、番組のキーワードなどの要素に対応するT_PRG_VALUEである。各要素は、主に、ＥＰＧ、例えば、図６に示したＥＰＧに表示される情報であり、そのために、ＥＰＧを作る時に必要とされるデータであり、そのＥＰＧを作成する側から供給されるものである。

例えば、図３２に示したようなＥＰＧがユーザ側に提供される場合を考える。図３２の左側に示したＥＰＧでは、“番組Ａ−１”という番組名と、その下に出演者として“人物Ａ”と“人物Ｂ”が表示されている。さらに下側に、“情報”と“買い物”という２つのキーワードが表示されている。このようなＥＰＧを表示させるのに必要な情報としては、図３２の右側に示したように、まず、“人物Ａ”というのを表示させるために、AttributeIDが“００２”でValueIDが“0000000001”という情報が必要である。同じように、“人物Ｂ”、“情報”、および“買い物”という表示をさせるにの必要な情報としては、AttributeIDとValueIDの組み合わせの情報が必要である。

図３２の図中右側に示したような情報が、ステップＳ３１において取得されるわけだが、そのデータは、図２８に示したT_PRG_VALUEデータベース３１５として提供されるため、対応するT_PRG_VALUEデータベース３１５内のデータを取得することにより行われる。ステップＳ３２において、マップデータから、ステップＳ３１において取得された各要素に対応する属性データと、その属性データに対応するスコアが取得される。マップデータとは、ターゲットデータベース２５２で管理されている各データベースのことである。

ステップＳ３３において、出演者や出現キーワードのT_PRG_VALUEのスコアに、ステップＳ３２において取得されたマップデータから取得されたスコアを乗算し、その値を属性データのスコアとして設定する。そして、ステップＳ３４において、設定されたスコアが、T_PRG_VALUEデータベース３１６の１つの要素として追加、記憶される。要素が追加される際、その追加される要素には、属性に対応するAttributeIDが割り当てられる。また、その要素には、ValueIDとして、当該属性のマスターデータで定められている属性を一意に識別するIDが割り当てられる。

このようにして、図２９に示したT_PRG_VALUEデータベース３１６が作成される。

次に、図３０に示したT_UM_VALUEデータベース３１７の作成に関わる処理について説明する。図３０に示したT_UM_VALUEデータベース３１７のところの説明で、T_UM_VALUEデータベース３１７の各要素は、登録、学習、またはフィルタといういずれかの処理により設定されたものであると説明した。ここではまず、図３３に示したフローチャートを参照して、ユーザ自身の登録による要素の追加処理について説明する。T_UM_VALUEデータベース３１７の作成に関わる処理は、ＣＰＵ２０１が実現する１つの機能であるユーザモデル管理機能２３５により実行される。

ステップS５１において、ＣＰＵ２０１は、T_UM_VALUEデータベース３１７に追加するデータを取得する。ステップＳ５１において取得されるデータは、編集対象となっているユーザ（視聴者）の嗜好に関わる出演者、キーワードなどの各要素に対するT_UM_VALUEである。ステップＳ５２において、マップデータから、ステップＳ５１において取得された各要素に対応する属性データと、その属性データに対応するスコアが取得される。

ステップＳ５３において、出演者や出現キーワードのT_UM_VALUEのスコアに、ステップＳ５２において取得されたマップデータからの取得されたスコアを乗算し、その値を属性データのスコアとして設定する。そして、ステップＳ５４において、設定されたスコアが、T_UM_VALUEデータベース３１７の１つの要素として追加、記憶される。要素が追加される際、その追加される要素には、属性に対応するAttributeIDが割り当てられる。また、その要素には、ValueIDとして、当該属性のマスターデータで定められている属性を一意に識別するIDが割り当てられる。

このようにして、ユーザ自身が登録した要素に対する処理が行われることにより図３０に示したT_UM_VALUEデータベース３１７の一部が作成される。

次に、T_UM_VALUEデータベース３１７に、学習により要素が追加される場合の処理について、図３４のフローチャートを参照して説明する。ステップＳ７１において、処理対象となっているユーザが視聴した番組（録画予約した番組）に関するデータが、ログデータベース２５３（図１１）から読み出される。ログデータベース２５３には、ユーザを識別するための識別子（MemberID）、そのユーザが視聴した番組を識別するための識別子（ProgramID）が、少なくとも関連付けられて管理されている。

ステップＳ７１においては、所定のユーザが視聴した番組に関わるデータが取得されるわけだが、まず、処理対象とさているユーザのMemberIDが取得される。そして、そのMemberIDを基に、ログデータベース２５３からユーザが利用した番組のProgramIDが取得される。ProgramIDが取得されると、T_PRG_VALUEデータベース３１６が参照され、取得されたProgramIDに対応する、それぞれの要素毎に、T_PRG_VALUEが取得される。

ステップＳ７２において、取得されたT_PRG_VALUEのスコアが、同一のAttributeID、ValueIDのT_UM_VALUEの要素に加算される。この処理について、図３５を参照して説明を加える。ログデータベース２５３に、MemberIDが“200241723056783”、ProgramIDが“1000000030000029”というデータが残されている状況で、このデータが読み出されると、まず、同一のProgramIDを有する要素が、T_PRG_VALUEデータベース３１６から読み出される。図３５に示した例では、AttributeIDが“００１”、ValueIDが“1000”、Scoreが“1.65193365995972070000”という要素が読み出される。

次に、この読み出されたAttributeIDとValueIDが一致する要素が、T_UM_VALUEデータベース３１７内に存在するか否かが判断される。図３５に示したように、一致する要素が存在する場合、その存在していると判断された要素のScore、図３５に示した例では、“.84296419427714530000”が読み出される。その読み出されたScoreに、先に、T_PRG_VALUEデータベース３１６から読み出されているScore（この場合、“1.65193365995972070000”）が加算される。なお、単に加算されるだけでなく、所定の値が乗算される（重み付けが行われる）などするようにしても良い。

このように、ユーザが番組を視聴する（録画予約する）たびに、T_UM_VALUEデータベース３１７の各要素のScoreが変更される。すなわち、よりユーザの嗜好に近いものになるように、学習が行われていることになる。

図３５に示した例では、T_UM_VALUEデータベース３１７に、T_PRG_VALUEデータベース３１６から読み出されたAttributeIDとValueIDが一致する要素が存在する場合を例に挙げたが、存在していない場合も考えられる。例えば、ユーザＡが視聴した番組に“人物Ａ”が出演していたが、その“人物Ａ”という要素は、ユーザＡに対応するT_UM_VALUEデータベース３１７には登録されていないこともある。

そのような場合、新たな要素がT_UM_VALUEデータベース３１７に追加される。図３６を参照して、このような状況について説明を加える。

ユーザＡが、番組Ｘを視聴し、その番組Ｘには、人物Ａと人物Ｂが出演していた。人物Ａは、ユーザＡが好みであり、人物Ａが出演していた番組は、よく視聴していたが、人物Ｂのことは知らなく、人物Ｂが出演している番組Ｘ以外の他の番組を視聴したことはなかった。このような状況の時には、ユーザＡのT_UM_VALUEデータベース３１７には、人物Ａに関するScoreＡは既に存在しているので、そのScoreＡに、新たな数値が加算され、ScoreＡ’とされる。

一方、人物Ｂに関する要素は、ユーザＡのT_UM_VALUEデータベース３１７には存在していないため、新たに人物Ｂに対する要素が追加される。

ここでは、人物Ａと同じ番組に出演していた人物Ｂに関する要素が追加されるとしたが、例えば、人物Ａのキャラクタや視聴タイプなどの要素も追加される場合がある。また、人物Ａのキャラクタや視聴タイプなどが、既に存在しているときには、そのScoreに、新たな値が加算されるなどして、その値が変化することはもちろんある。

例えば、ユーザＡが視聴し、人物Ａが出演していた番組Ｘは、バラエティ番組であっても、その人物Ａ自体は、時代劇に出演することが多い人物であるような場合、人物Ａのキャラクタとして、“時代劇”が関連付けられている（マッピングされている）。よって、ユーザＡが視聴していた番組Ｘが、バラエティ番組であっても、上述したような処理が実行されるため、番組Ｘを視聴することにより、人物Ａに関連付けられている“時代劇”という要素のスコア値があがり、次回から、“時代劇”もオススメ番組として推薦される可能性が高くなる。

また、人物Ａが“たくましい”といった属性を有する場合、その“たくましい”といった属性を有する人物Ｃ（不図示）の要素がユーザＡのT_UM_Valueデータベース３１７に追加される。もちろん、人物Ａが“たくましい”といった属性を有する場合、かつ、ユーザＡのT_UM_VALUEデータベース３１７に“たくましい”といった要素が存在している場合、その要素のScoreは、更新される。

さらに、ここでは、番組Ｘには、人物Ａと人物Ｂが出演しているとしたが、例えば、人物Ａのみが出演していた場合でも、同様なことが実行される。すなわち、人物Ａと人物Ｂは、“時代劇”というキーワード（属性）で関連付けられている（マッピングされている）ような場合、人物Ａしか出演していない番組Ｘが視聴された時点で、人物Ａにマッピングされている人物Ｂが読み出され、その人物Ｂの要素が追加されることになる。

すなわち、このような学習が行われることにより、この場合、番組Ｘの属性や人物Ａの属性に関連付けられている要素も、新たに、T_UM_VALUEデータベース３１７に追加される、または、その要素のScoreが更新される。

このように、ユーザが録画予約や視聴などを行うことにより、Score値は更新され、新たな要素が追加される。よって、徐々に、ユーザの嗜好に関するデータが、サンプル数が増えることにより詳細なものとなり、そのようなデータを用いて行われるオススメ番組の検索を、よりユーザに適した番組（ユーザが求める番組）を検索することができるものとすることができる。

図３７は、このような学習の処理を行わない場合と、行った場合とを比較するために作成したグラフである。グラフＡは、属性によるオススメを行った時を示し、グラフＢは、詳細メタデータのみによりオススメを行った時を示す。図３７に示したように、あまり時間が経過していない初期段階では、属性によるオススメを行う方（グラフＡ）が、学習度が高く、一定の時間が経過した段階では、詳細メタデータのみによりオススメを行う方（グラフＢ）の方が、学習度が高いといった結果が得られる。

この結果を考慮すると、ユーザ登録して間もないユーザに対しては、学習という処理を行う方が、より早い時期に、学習度を高めることができ、ユーザの嗜好のデータの信頼性を高めることができる。そして、所定の時間が経過した後（所定の学習度に達成した後）は、学習をやめる（または、学習の回数を少なくする）などした方が好ましい。

いずれにしても、学習を行うことにより、より早い時期に、ユーザの嗜好に関する、信頼性の高いデータを作成することができる。よって、より早い時期に、適切にユーザの嗜好に適した番組をオススメすることができるようになり、ユーザが満足するような結果を提供することが可能となる。よって、登録したユーザが、離れてしまう（脱会する）といったようなことを防ぐことが可能になる。

ユーザの嗜好に関するデータを、学習により収集するといった方法の他に、ユーザ自身で、登録するといった方法があることは既に上述した。これらの方法は、よりユーザの嗜好を正しいものとすることが１つの目的としてある。そこで、収集されるデータ（要素）についてだが、この場合、テレビジョン放送として放送される番組内から、ユーザの嗜好に合った番組をオススメするというのが１つの目的としているため、主に、番組の種類、番組に出演する出演者などに関する要素が収集される。

もちろん、このような要素だけでも良いが、さらに、ユーザのライフスタイルに関する情報を収集し、そのような情報に基づく要素も考慮して番組の推薦が行われるようにしても良い。ライフスタイルとは、例えば、日中はテレビジョン放送を視聴しない等である。しかしながら、このような、ある意味、ユーザのプライバシーに関わることは、また、ユーザに取っては、番組の推薦にどのような関連があるのか直接的に導き出せないプライバシーな情報を、簡単に提供することを快くは思わないユーザもいると考えられる。

そこで、このような情報は、アンケート形式や占い形式で、ユーザ側には、プライベートな情報を提供していると感じさせないような形式で収集する。このようにすることで、ユーザは、ゲーム感覚でプロファイルを登録することができ、そのようなプロファイルを管理する（収集する）側（この場合、サーバ５２、および管理者）は、プロファイルを収集しやすくなるといった効果を望むことができる。

このようなライフスタイルといった情報も、オススメ番組の検索が実行される際に用いられる要素とすることにより、よりユーザに適した番組を推薦することが可能となる。

次に、T_UM_VALUEデータベース３１７に対するフィルタリング処理（またはマイニング（mining）処理）について説明する。このフィルタリング処理は、主に図８に示したオススメ画面のうち、理由表示部１５５の“同じ番組を録画した人の興味”という項目を表示させるために行われる処理である。このような表示を行うのは、以下のような状況、理由からである。

図３８を参照して説明する。例えば、ユーザＡが、番組Ｘを録画予約し、ユーザＢも番組Ｘを録画予約したとする。ユーザＡもユーザＢも、番組Ｘに対して興味があると考えられる。例えば、その番組Ｘが、お笑い番組だとすると、ユーザＡとユーザＢは、お笑い系が好みであると考えられる。

ユーザＢは、お笑い系に属する番組Ｚも録画予約している。番組Ｘには、人物Ａが出演し、番組Ｚには、人物Ｂが出演している。このような場合、番組Ｚや人物Ｂは、ユーザＡが行った録画予約のログ内やユーザＡの嗜好データには含まれていないが（従って、オススメ番組として推薦されることはないが）、お笑い系の好きなユーザＡは、同じお笑い系に属する番組Ｚや人物Ｂのことも好みであると考えられる。換言すれば、ユーザＡは、好みであるはずの番組Ｚや人物Ｂのことを単に知らないだけとも考えられる。

そこで、番組Ｘを録画予約したユーザＢが録画予約した番組Ｚ、および、番組Ｚに出演する人物Ｂが、ユーザＡに推薦されるようにする。このようにすれば、ユーザＡ側としては、その時点まで認識していなかった番組Ｚや人物Ｂのことを、新たに認識することができる。認識していなかった新たな情報が提示されるということは、ユーザ側にとって、有意な情報であり、サーバ５２から提供される情報の信頼性を高めることができると考えられる。

このようなことは、従来でも、似たようなことは行われていた。例えば、書籍を販売しているサイトにおいて、購入者Ａが書籍Ａを購入した場合、同じくその書籍Ａを購入した購入者Ｂが購入した書籍Ｂを、購入者Ａに情報として提供するといったことは行われていた。このような場合、購入者Ａの嗜好に関しては考慮されておらず、単に、購入者Ａより前の時点で書籍Ａを購入した購入者Ｂが存在し、その購入者Ｂが購入したのが書籍Ｂであるので、その書籍Ｂがオススメされるという結果になっていた。

ここで、従来行われていたオススメ（フィルタリング処理）と、本実施の形態で行われるオススメ（フィルタリング処理）を比較し、その違いを説明する。図３９は、従来行われていたフィルタリング処理について説明するための図である。図３９に示したように、ユーザＡ乃至ユーザＺが、視聴した番組（コンテンツ）の履歴が管理されている状況を考える。例えば、ユーザＡにコンテンツをオススメする場合、ユーザＢ乃至ユーザＺから構成されるユーザグループの中から、ユーザＡと同じコンテンツを沢山視聴した人、すなわち、コンテンツの利用の相関度が高いユーザが検索される。

そして、相関度が高いとして検索されたユーザが利用したコンテンツの中で、ユーザＡがまだ利用したことがないコンテンツが、オススメとしてユーザＡに提示される。

このようにしてユーザ側に情報を提示する従来の方法の場合、過去に相関度の高い人が利用したコンテンツ（番組）しかオススメできないといった問題があった。

図４０は、本実施の形態において行われるフィルタリング処理について説明するための図である。図４０に示したように、ユーザＡ乃至ユーザＺが、利用したコンテンツの履歴が管理されている状況を考えるが、履歴の中には、各コンテンツのメタ情報も含まれている。さらに本実施の形態においては、コンテンツレポジトリも管理される。コンテンツレポジトリとは、ここでは、ターゲットデータベース２５２で管理されているデータのことである。

例えば、ユーザＡにコンテンツをオススメする場合、ユーザＢ乃至ユーザＺから構成されるユーザグループの中から、ユーザＡと同じメタ情報（例えば、出演者やキーワードなどを情報として含んでいる）を沢山利用した人、すなわち、メタ情報の利用の相関度が高いユーザ（すなわち、嗜好が似ていると判断されるユーザ）が検索される。そして、相関度が高いとして検索されたユーザが利用したメタ情報の中で、ユーザＡが、まだ利用したことがないメタ情報、または、利用頻度が低いメタ情報がさらに検索される（従って、ユーザＡ自体は、認識していない出演者やキーワード）。そして、その検索されたメタ情報を有するコンテンツ（番組）が、コンテンツレポジトリから読み出され、そのコンテンツが、オススメとしてユーザＡに提示される。

このようにしてユーザ側に情報を提示することにより、例えば、再利用されることのないコンテンツや、期間限定で供給されるコンテンツなどの推薦が行えるようになると共に、通常のコンテンツなどの推薦も、より適切に行えるようになる。さらに例えば、コンテンツの推薦などにより得られたキーワードの相関度を用いて、他のコンテンツの推薦等を行うことも可能となる。

図４１に示したフローチャートを参照して、本実施の形態におけるフィルタリング処理について説明する。ステップＳ９１において、ユーザ間の相関度の計算が行われる。このユーザ間の相関度の計算は、次式（１）に基づいて行われる。

式（１）において、Ｘνは、Valueνに対するユーザＸの評価（Score）を示し、Ｘ_Aは、ユーザＸの評価の平均値を示す。同様に、Ｙνは、Valueνに対するユーザＹの評価を示し、Ｙ_Aは、ユーザＹの評価の平均値を示す。式（１）に基づく計算を行うことにより、ユーザＸとユーザＹの相関度（T_UM_SIMILARITY）を求めることができる。式（１）における各値は、T_UM_VALUEデータベース３１７で管理されている値が代入される。

このような計算が、ステップＳ９１において行われると、ステップＳ９２において、予測ベクトルの算出が行われる。ユーザＸのValueνに対する予測ベクトルの算出は、次式（２）に基づいて行われる。

式（２）において、Ｘ_Aは、ユーザＸの評価の平均値を示し、Ｎは、Valueνに対するユーザＸとの相関度を持つユーザＮの評価を示し、Ｎ_Aは、ユーザＮの評価の平均値を示し、Ｓｉｍ_XNは、ステップＳ９１において算出された値であり、ユーザＸとユーザＮの相関度を示す。

このようにして算出された予測ベクトルは、T_UM_VALUEデータベース３１７に記憶される。図３０に示したT_UM_VALUEデータベース３１７のところで説明したように、UMTypeIDの“３”は、このようなフィルタリング処理により算出された予測ベクトルであることを示している。

ステップＳ９１において算出された相関度を管理するデータベースを、記憶部２０８（図１１）に設けるようにしても良い。また、ステップS９２において算出された予測ベクトルの値は、T_UM_VALUEデータベース３１７に記憶されるようにしたが、記憶されない構成とすることも可能である。相関度や予測ベクトルは、会員登録しているユーザの内の１人が、録画予約や視聴をした時点で新たなデータが追加された（新たに計算の対象となるデータが追加された）ことになり、その結果、基本的に算出し直さなくてはならなくなる。

このようなことを考慮すると、必要が生じた時点で算出し、常に、最新の予測ベクトルの値を用いることができるようにしておいた方が良いとも考えられため、記憶させないようにすることも可能である。よって、相関度を管理するためのデータベースを設けなかった場合や、予測ベクトルの値をT_UM_VALUEデータベース３１７に記憶させるようにしなかった場合、必要に応じて、例えば、ユーザにオススメ画面を提供する時点で、相関度や予測ベクトルを算出するようにすればよい。

また、相関度や予測ベクトルを事前に記憶させるようにした場合であっても、その記憶されているデータを、全て再度算出し直すといったようなことはせず、新たにログが生成されたユーザに対してのみ（そのユーザのデータに対してのみ）、相関度や予測ベクトルを算出するといった処理を行うようにしても良い。このようにすれば、相関度や予測ベクトルを算出するために要する時間を短縮することができる。また、サーバ５２への負担を軽くすることができる。

図４１に示したフローチャートの処理のように、予測ベクトルを算出するようにしても良いが、例えば、１万人の会員が存在すると、約１万×１万の計算が最低限必要となる。会員数が増せば、それだけ、計算回数が増加し、システムにかかる負担が増大する。そこで、システムにかかる負担を軽減するとともに、軽減しても適切なフィルタリング処理が行えるようにする（図４１に示したフローチャートの処理を実行したときとほぼ同様の効果が得られるようにする）ための、他のフィルタリング処理について、図４２のフローチャートを参照して説明する。

図４２に示したフローチャートの処理では、ステップＳ１０１においてユーザ間の相関度が計算され、ステップＳ１０２において、ユーザグループの生成の処理が行われ、ステップＳ１０３において、予測ベクトルの算出が行われる。図４１に示したフローチャートの処理と比較すると、図４２に示したフローチャートの処理では、ステップＳ１０２におけるユーザグループの生成処理という処理が追加された構成とされている。このユーザグループの生成処理について、図４３のフローチャートを参照して説明する。なお、ステップＳ１０１における相関度の計算に関わる処理は、ステップＳ９１（図４１）における相関度の計算に関わる処理と基本的に同様である。

ステップＳ１１１において、全ユーザが各グループに属しているとしてグループをユーザの人数分だけ生成する。すなわち、構成人数が１人のグループが、ユーザ数分だけ生成される。例えば、１万人のユーザが存在していると、構成人数が１人のグループが１万グループ作成される。

ステップＳ１１２において、相関度データベース（不図示）が参照され、相関度の高い順にソート処理が実行される。このステップＳ１１２における処理においては、ステップＳ１０１（図４２）において算出された相関度が用いられる。相関度データベースが、設けられる構成とされている場合、ステップＳ１０１において算出された相関度が、相関度データベースに記憶され、その記憶された相関度が用いられてステップＳ１１２の処理が実行される。一方、相関度データベースが設けられない構成とされた場合、ステップＳ１０１において相関度が算出される毎に、ソート処理が繰り返され、ステップＳ１０１における相関度の処理が終了した時点で、ステップＳ１１２におけるソートの処理も終了される。

ステップＳ１１１における処理と、ステップＳ１１２における処理は、時間的に前後関係を有しなくてはならない処理ではないため、ステップＳ１１２における処理が、ステップＳ１１１における処理より前の時点で行われても良いし、ステップＳ１１１の処理とステップＳ１１２の処理が、並列的に処理が行われても良い。

ステップＳ１１２までの処理が終了されると、ステップＳ１１３に処理が進められる。ステップＳ１１３において、相関度の高い順に、計算対象とされている２人のユーザが属するグループがまとめて１つのグループとして設定される。この処理により、相関度がほぼ同じユーザ同士が、１つのグループとして設定されることになる。例えば、１万のユーザ存在し、１万のグループが設定されているときには、このステップＳ１１３における処理で、半分の５千グループに設定し直されることになる。

ステップＳ１１４において、設定し直されたグループ数は、最終的に求めたいグループ数以下になったか否かが判断される。ステップＳ１１４において、最終的に求めたいグループ数以下になったと判断されるまで、ステップＳ１１３とステップＳ１１４の処理が繰り返される。

例えば、最終的に求めたいグループが２千グループ以下である場合、１万グループが存在しているときを考える。まず、１回目のステップＳ１１３における処理で５０００グループ（１グループは、２名で構成される）とされ、２回目のステップＳ１１３の処理で２５００グループ（１グループは、４名で構成される）とされ、３回目のステップＳ１１３の処理で１２５０グループ（１グループは、８名で構成される）とされる。この時点で、２０００グループ以下となるので、ステップＳ１１４の処理で、最終的に求めたいグループ数に達したと判断され、ユーザグループの生成処理は終了される。

ステップＳ１１３とステップＳ１１４における処理は、所定のグループ数以下にユーザグループを設定するために行われる処理であり、上述したような、存在するグループ数を半分のグループ数にするという処理を繰り返す方法に限定されるものではない。例えば、全ユーザ数（ステップＳ１１１において作成された全グループ数）を、目標としているグループ数で除算し、その結果得られた数値を、１グループの人数として設定し、相関度の高い順に、その設定された人数毎に、グループを設定し直すようにしても良い。

例えば、１万のグループが存在し、２千のグループ数以下にしたい場合、まず、１万を２千で除算し、５という結果を得る。よって、１グループを５人と設定し、５人で構成されるグループを、相関度の高い順に作成すれば、２千グループが生成されることになる。

ユーザグループをどのような方法を用いて生成しても良いが、相関度の近いユーザ同士が、１つのグループとされ、グループ数の総数が、所定の数以下になれば良い。このグループの最終的な数は、システムへの負荷などを考慮して設定されればよい。

このようにして生成されたグループ毎に、予測ベクトルが、ステップＳ１０３において算出される。このステップＳ１０３における処理は、基本的に、ステップＳ９２（図４１）の処理と同様であるが、ステップＳ９２においては、例えば、ユーザＸとユーザＹというように、所定のユーザと他のユーザとの間の予測ベクトルが求められる処理であった。

これに対し、ステップＳ１０３においては、例えば、グループＸとグループＹというように、所定のグループと他のグループとの間の予測ベクトルが求められる。このようにした場合、例えば、ユーザＸの予測ベクトルは、そのユーザＸが属するグループＸとグループＹの予測ベクトルとされる。

または、ステップＳ１０３においては、例えば、グループＸに属するユーザＸと、そのユーザＸが属していない他のグループＹというように、所定のユーザと所定のグループとの間の予測ベクトルが求められるようにしても良い。

いずれの方法によっても、グループという概念を用いて予測ベクトルを算出する方が、ユーザ同士で予測ベクトルを求める方法よりも、その算出にかかる処理を軽くすることができるため、算出にかかる時間を短縮し、システムにかかる負荷を低減させることができる。

図４４は、他のフィルタリング処理について説明するためのフローチャートである。図４４に示したフローチャートの処理も、グループ化を前提としているが、相関度を用いない点が、図４２に示したフィルタリング処理と異なる。ステップＳ１３１において、ユーザグループの生成が行われる。このステップＳ１３１におけるユーザグループの生成の処理は、例えば、ログデータベース２５３（図１１）が参照されて行われる。ログデータベースが参照され、近々に同じ情報を利用したユーザ同士がグループ化される。このようにすれば、このフィルタリング処理が実行されている時点で、同じような興味を持っているユーザ同士をグループ化できると考えられる。

この際、１グループに属する人数などは、予め設定されている、または、上述したような方法（例えば、全ユーザ数を、目標とするグループ数で除算する）により設定される。その設定されている人数で１グループが構成されるように、グループ化の処理が実行される。なお、このグループ化の処理は、管理者が手作業により行うことも当然可能である。

このようなグループ化（ユーザグループの生成）が終了されると、ステップＳ１３２において予測ベクトルが算出される。この予測ベクトルの算出は、ステップＳ１０３（図４２）における処理と、基本的に同様に行われるので、ここでは、その説明を省略する。この場合、グループに属するユーザの各Valueに対する平均値が、そのグループに属する全ユーザに対する予測ベクトルとして設定される。

グループ化や、予測ベクトルの算出を、必要がある時に、その時点で行うのではなく、事前に実行し、記憶させるようにした場合、その記憶されているデータを再度算出し直すといったようなことはせず、新たにログが生成されたユーザに対してのみ（そのユーザのデータに対してのみ）、処理を実行するようにしても良い。このようにすれば、予測ベクトルを算出するために要する時間を短縮することができる。また、サーバ５２への負担を軽くすることができる。

図４１乃至図４４に示した各フローチャートの処理のうち、いずれの処理に基づいて予測ベクトルが求められても良い。

なお、上述したフィルタリングの処理において、計算に利用する相関度（Ｓｉｍ_XN）に関して、所定の値以上の相関度を持つユーザのみ計算に用いる（閾値を設定し、その閾値以上の相関度を有するユーザのみを計算対象のユーザに設定する）ようにしても良い。このようにすれば、予測ベクトルの算出にかかる時間を短縮することができ、また、算出のためにかかる負荷を軽減させることができる。

また、予測ベクトルが所定のユーザに適用される際、そのユーザが有していない全てのValueに関する要素を、T_UM_VALUEデータベース３１７に登録するのではなく、上位の所定数のみを登録するようにしても良い。このように、登録される要素に制限を加えることにより、データベースのリソースの節約、計算速度の向上をはかることが可能となる。

仮に、予測ベクトルの情報のみを用いて、ユーザにオススメの番組を推薦するような場合、ユーザが既に有しているValueに関しても予測ベクトルを求め、オススメ番組の検索などに用いることができる。ユーザの現在のプロファイル（学習や登録により求められたプロファイル）が、“本来なら、このようになるのではないか”、“将来的には、こういう風になるはず”といったような観点からのオススメが可能となる。

このように、本実施の形態においては、ユーザ側に推薦する番組を検索する際の情報（T_UM_VALUEデータベース３１７のデータ（要素））は、登録、学習、フィルタリングといった、それぞれの処理が総合的に実行されることにより作成される。

次に、作成されたこれらのデータベースを用いて、推薦する番組の検索（オススメ画面の作成）について説明する。図４５のフローチャートを参照し、所定のユーザに対して推薦する番組を検索し、その検索された番組の情報を取得するまでの処理について説明する。

ステップＳ１６１において、ユーザがログインしてくるため、そのログインに対応するための処理が実行される。このログインに関わる処理は、ユーザ管理機能２３２（図１０）において行われる。ユーザは、ユーザ端末５３（図３）を用いて、自己のユーザIDとパスワードをサーバ５２に対して送信する。その送信されたユーザIDとパスワードは、サーバ５２の情報通信機能２３６（図１０）の制御により受信され、ユーザ管理機能２３２に供給される。ユーザ管理機能２３２は、供給されたユーザのユーザIDとパスワードの組が、ユーザデータベース２５４に記憶されているか否かを判断する。

供給されたユーザIDとパスワードの組が、ユーザデータベース２５４に記憶されていると判断された場合、ログインの処理は正常に行われることになり、ステップＳ１６２に処理が進められるが、ログインの処理が正常に行われなかった場合は、ステップＳ１６２に処理が進められることなく、エラー処理、例えば、ログインを要求してきたユーザに対して、ログインが正常に行われなかったことを示すメッセージを送付するなどの処理が実行され、図４５に示したフローチャートの処理は終了される。

ステップＳ１６２において、対象ユーザモデルが取得される。対象ユーザモデルの取得とは、T_UM_VALUEデータベース３１７から、ログインしてきたユーザに関わる情報が読み出されることを意味する。ステップＳ１６１におけるログインの処理で、ログインしてきたユーザが判別されているため、MemberIDを取得することができる状態とされている。そこで、ログインしてきたユーザのMemberIDを、ユーザデータベース２５４から読み出し、そのMemberIDに対応するデータが、T_UM_VALUEデータベース３１７から読み出される。

このステップＳ１６２以降の処理は、情報選別機能２３３により行われる。ログインの処理を実行するのは、上述したようにユーザ管理機能２３２であるが、ユーザ管理機能２３２は、ログインの処理を実行した結果、取得したMemberIDを、情報選別機能２３３に供給する。情報選別機能２３３は、供給されたMemberIDを用いて、ステップＳ１６２における処理を実行する。

情報選別機能２３３は、ステップS１６２の処理を実行すると共に、並列的に、ステップＳ１６３の処理も実行する。ステップS１６３において、ユーザ情報から、対象情報を絞る必要があるか否かが判断される。“ユーザ情報”とは、ここでは、ユーザが住んでいる地域、ユーザが有する視聴権限、ユーザの年齢や性別などである。また、“対象情報を絞る必要があるか否か”とは、例えば、一部地域では放送されないような番組が存在するような場合、ログインしてきた（処理対象とされているユーザ）が、その地域に住んでいるか否かが判断され、住んでいる地域に放送される番組のみが提供されるように、情報を選択することを意味する。

視聴権限により対象情報を絞る必要がある場合、例えば、有料放送を視聴する権限があるか否か、そのような権限があると判断されたときであっても、どのような範囲で権限を有しているのか等が判断され、対象情報の絞り込みが行われる。また、年齢により対象情報を絞る必要がある場合、例えば、成人向けの番組が、成人でないユーザに対してはオススメされるようなことがないように、成人でないユーザがログインしてきたときには、対象情報の絞り込みが行われる。

性別により対象情報を絞る必要がある場合、例えば、男性向けの番組を女性に対してオススメされることがないようにした方が好ましいときには、対象情報の絞り込みが行われる。しかしながら、性別により対象情報を絞る必要性は、他のユーザ情報により対象情報を絞る必要性より低く、必ずしも設けなくてはならない対象ではない。

ステップＳ１６３において、ユーザ情報から対象情報を絞る必要があると判断された場合、ステップＳ１６４に処理が進められ、対象情報を絞る必要がないと判断された場合、ステップＳ１６４の処理はスキップされ、ステップＳ１６５に処理は進められる。ステップＳ１６４において、情報データの選別が行われる。この情報データの選別は、ログインしてきたユーザにオススメ番組として推薦できないような番組を排除するために行われる。排除されて残った番組が、ステップＳ１６５における処理の対象とされる。

一方、ステップＳ１６４の処理がスキップされてステップＳ１６５に処理が進められた場合は、情報データを選別する必要がないので、全ての番組が処理対象とされる。ステップＳ１６５において、処理対象とされている番組の情報メタデータが取得される。この情報メタデータは、T_PRG_VALUEデータベース３１６（図２９）で管理されているデータのことである。

ステップＳ１６５において、処理対処とされた番組の情報メタデータが取得されると、ステップＳ１６６において、推薦対象情報の得点計算および選別の処理が実行される。この処理は、ステップＳ１６２で取得された対象ユーザモデル（T_UM_VALUEデータベース３１７）のScoreと、ステップＳ１６５において取得された情報メタデータ（T_PRG_VALUEデータベース３１６）のScoreが用いられて行われる。例えば、ベクトル演算などの得点計算方法により値が算出され、その値を元に、番組のランキングが付けられる。この処理により演算された得点は、例えば、図８に示したオススメ画面内のオススメ度表示部１５６に表示される得点とされる。

このようにして、各番組の得点が演算され、その得点の高い順にランキング付けが行われると、ステップＳ１６７に処理が進められる。ステップＳ１６７において、推薦対象とされた番組の情報の取得が行われる。推薦対象とされた番組とは、ランキングの上位に位置する、所定数の番組（例えば、１０番組）である。その所定数の番組の情報が取得されるわけだが、この取得は、情報選別機能２３３により行われる。情報選別機能２３３は、ランキングの上位に位置する番組の識別子（ProgramID）を取得する。

そのProgramIDを元に、出演者（PersonID）やキーワード（KeywordID）といった番組に関する情報を取得する。このようにして、複数の番組の情報が順次取得される。

ユーザにオススメとして推薦される複数の番組の情報が取得された後の処理について、図４６のフローチャートを参照して説明する。ステップＳ１８１において、推薦情報の取得が行われる。この処理は、ステップＳ１６７（図４５）のことである。ステップＳ１８２において、推薦情報の推薦度を算出する際に、算出対象とされたValue（ValueIDにより識別される要素）に関して、各Value毎のスコアでソート処理が実行される。

ステップＳ１８３において、ソートされた上位のValueに対して、そのValueに関連付けられているAttributeIDとValueIDの組を用いて、M_REASONデータベース２８０（図２１）から、オススメ理由が取得される。例えば、ソートされた結果、上位のValueとされたAttributeIDが“００１”、ValueIDが“１０００”であった場合、“スポーツ”というオススメ理由が取得される。

ステップＳ１８４において、ReasonTypeの表示上限個数と、ReasonType毎に指定された条件を満たしているか否かが判断される。ここで、ReasonTypeに関わる事項について説明する。ReasonTypeとは、図８に示したオススメ画面のうち、理由表示部１５５に表示される理由（Reason）の個数などを制限するために設定されているものである。図４７にReasonTypeを設定するためのデータを示し、図４８に各ReasonType毎の表示個数を設定するためのデータを示す。図４７や図４８に示した表示個数を制御するためのデータに基づく処理は、例えば、情報選別機能２３３の１機能として組み込まれ、実行される。

図４７に示したデータのうち、１行目は、ReasonTypeを指定するデータであることを宣言するため、そして、２行目以降のデータ形式を規定するためのデータである。２行目以降のデータにおいて、“Normal”は、UMTypeを示し、図３０に示したT_UM_VALUEデータベース３１７の説明においては、UMTypeID＝“２”と記載した事項と同じ意味合いを有する。すなわち、“Normal”は、学習により登録された要素であることを示す。

“Prior”は、図３０に示したT_UM_VALUEデータベース３１７の説明においては、UMTypeID＝“１”と記載した事項と同じ意味合いを有する。すなわち、“Prior”は、ユーザ自身が登録した要素であることを示す。さらに、“Expected”は、図３０に示したT_UM_VALUEデータベース３１７の説明においては、UMTypeID＝“３”と記載した事項と同じ意味合いを有する。すなわち、“Expected”は、フィルタリング処理により登録された要素を意味する。

２行目以降は、同一の形態でデータが記載されているので、２行目を例に挙げてそのデータについて説明する。２行目には、“ReasonType．Normal．Category＝４”との記載がある。まず、“ReasonType”は、その行のデータがReasonTypeを設定するものであることを宣言している。次の“Normal”は、UMTypeを示している。そして、“Category＝４”は、“Category”は、“４”というReasonTypeに属することを示している。まとめると、２行目の記載が意味するものは、この場合、学習により登録され、Attributeとして“Category”に属するものは、ReasonTypeが“４”と設定されることを示している。

図４８は、このようなReasonType毎のReasonType表示個数を設定するためのデータである。２行目の“＃［０］登録キーワード、人物（合計５件以内）”という記載を例に挙げて、図４８に示したデータについて説明する。“＃［０］”は、ReasonTypeが“０”の内容を示すデータが、２行目には記載されていることを示している。“＃［０］”に続く“登録キーワード、人物（合計５件以内）”という記載は、“登録キーワード、人物”という項目が、理由表示部１５５に表示される場合、この項目に対応するキーワードや人物は、合わせて５件以内しか表示してはいけないという規定である。換言すれば、この場合、Attributeが“Keyword”や“Person”であるReason（図２１）は、合計５件までしか、この項目の欄には表示させてはいけないという制限が規定されている。

図４７と図４８に示したデータにより、図８に示したオススメ画面内の理由表示部１５５の表示に制御が加えられることになる。ここで、オススメ画面の理由表示部１５５の表示とあわせて、図４７と図４８に示したデータについての説明をさらに加える。まず、ステップS１８３における処理において、AttributeIDとして“００１”、ValueIDとして“１０００”が取得されたとする。AttributeID“００１”、ValueID“１０００”の組をM_REASONデータベース２８０（図２１）を参照すると、“スポーツ”という言葉が関連付けられているため、オススメ理由（Reason）として、“スポーツ”という言葉がユーザ側に提示されるとして決定される。

さらに、AttributeID“００１”、ValueID“１０００”の組を、T_UM_VALUEデータベース３１７（図３０）を参照して検出すると、UMTypeIDが“１”であることが分かる。UMTypeID“１”は、UMTypeとしては“Prior”である。また、AttributeID“００１”は、M_CATEGORYデータベース２７１（図１２）に割り振られたIDであるため、Attributeとしては“Category”であることが分かる。ここまでの処理で、オススメ理由として表示させようとしている“スポーツ”という言葉は、“Prior”であり、“Category”であることが分かる。

図４７を参照するに、“Prior”、“Category”の組み合わせは、１２行目に存在する。１２行目の記載より、ReasonTypeが“１”であることが分かる。そこで、図４８のデータを参照するに、ReasonType＝１については、４，５行目に記載がある。４行目の記載より、“登録ジャンル”という項目の欄に表示されることがわかる。また、この項目には、１件しか表示してはいけないという規定になっていることが分かる。

結果として、この場合、理由表示部１５５には、
登録ジャンル：「スポーツ」
といった表示がされることになる。

なお、このような処理が行われた後に、“Prior”、“Category”、および、ReasonType“１”のValueがステップＳ１８３で取得された場合、既に、“スポーツ”という言葉が割り当てられているので、その取得されたValueは、処理対象とはならず破棄される。また、ステップＳ１８２において、ソートをかけているため、破棄されるValueは、常に、既に処理済みのValueよりも低い値を有するものであるため、結果として、ユーザに提示されるのは、常に、Valueが高いものだけになる。

この説明は、ステップＳ１８３とステップＳ１８４の処理についての説明であるが、実際に、上述したような順番で、データベースなどが参照されつつ行われる必要はない。すなわち、ステップＳ１８３の処理が実行される前の段階で、例えば、UMTypeIDなどは判断されているため、または、判断されるようにすれば、ステップＳ１８３，Ｓ１８４の処理においてT_UM_VALUEデータベース３１７を再度参照する必要性はない。よって、適宜、処理の重複がないように、各処理が実行されれば良く、どのタイミングで、どのようなデータベースが参照されるか等は上述した説明に限定されるものではない。

このように図４７と図４８にそれぞれ示したデータに基づく制御により、ステップＳ１８４（図４６）の判断が行われる。ステップＳ１８４において、ReasonTypeの表示上限個数（図４７に示したデータにより制限が加えられる）と、ReasonType毎に指定されている条件（図４８に示したデータにより制限が加えられる）を満たしていると判断されるまで、ステップＳ１８３とステップＳ１８４の処理が繰り返され、満たしていると判断されると、図４６に示したフローチャートの処理は終了される。

すなわち、図４６に示したフローチャートの処理が終了されると、ユーザ側にオススメ画面を提示するためのデータがそろったことになるので、そのそろえられたデータが、ユーザ側にユーザ端末５３に送信される。

ここで、さらに、ステップＳ１８３における処理について説明を加える。ステップＳ１８３においては、M_REASONデータベース２８０が参照される。例えば、AttributeIDとして、“００５”が、ValueIDとして“0000000006”が取得された場合を考える。このAttributeIDとValueIDの組み合わせと関連付けられているのは、図１６のM_KEYWORDデータベース２７５を参照すると、“エロティック”という言葉であることが分かる。しかしながら、既に説明したように、この“エロティック”という言葉は、ユーザ側に提示する言葉としてはふさわしくないと判断されているため、M_REASONデータベース２８０（図２１）には記載されていない。

よって、ステップＳ１８３における処理で、AttributeID“００５”、ValueID“0000000006”の組が取得されたとしても、オススメ理由としてM_REASONデータベース２８０から読み出されるデータはないことになる。このような場合、ステップＳ１８４の処理を行う必要がないので、行わないで、次の要素（Value）に対してステップＳ１８３の処理が実行されるようにしても良い。いずれにしても、M_REASONデータベース２８０に記載がないReasonは、ユーザ側には提示されないという制御が行われることになる。

図４６に示したフローチャートの処理では、図２１に示したようなM_REASONデータベース２８０が参照されるとして説明した。しかしながら、図２１に示したようなM_REASONデータベース２８０を有してなく、図１７に示したM_KEYWORD_1データベース２７６を有しているような場合でも、図４９のフローチャートの処理に従えば、基本的に、図４６に示した処理を実行したときと同様の処理を行うことができる。

図４９におけるステップＳ２０１、ステップＳ２０２、および、ステップＳ２０４の処理は、図４６のステップＳ１８１、ステップＳ１８２、および、ステップＳ１８４の処理と基本的に同様であるので、その説明は省略する。ステップＳ２０３において、ソートされた上位のValueに対して、当該マスターテーブルが参照され、当該ValueIDが用いられて、オススメ理由（Reason）が取得される。この処理も、基本的には、図４６に示したフローチャートのステップＳ１８３の処理と同様であるが、参照されるデータベースが異なる。

ステップＳ２０３においては、M_KEYWORD_1データベース２７６が参照される。例えば、ValueID（この場合、KeywordIDになる）が“0000000008”の場合、M_KEYWORD_1データベース２７６内のReasonの欄が参照され、“お得な情報”というのが読み出される。また、例えば、ValueIDが“0000000006”の場合、M_KEYWORD_1データベース２７６内のReasonの欄が参照されるが、空欄（NULL）とされているため、読み出されるデータなく、このValueID“0000000006”に対する処理は終了され、次のValueIDに対する処理に移行される。

このように、M_KEYWORD_1データベース２７６を用い、図４９に示したフローチャートの処理を実行した場合も、ユーザに提示される言葉として不適切な言葉は、提示されない、または、他の言葉に変換されて提示されるように制御することが可能である。

M_KEYWORD_1データベース２７６の代わりに、M_KEYWORD_２データベース２７７（図１８）が備えられている場合、図５０のフローチャートに基づく処理が実行される。この場合、ステップS２１１、ステップＳ２１２、および、ステップＳ２１４は、図４６のステップＳ１８１、ステップＳ１８２、および、ステップＳ１８４の処理と基本的に同様であるので、その説明は省略する。

ステップＳ２１３においては、M_KEYWORD_２データベース２７７が参照される。例えば、ValueID（この場合、KeywordIDになる）が“000000000１”の場合、M_KEYWORD_２データベース２７７内のKeywordの欄が参照され、“情報”というのが読み出され、Displayの欄の“１”という値が読み出される。このDisplayの欄の“１”という値（フラグ）は、ユーザ側に提示されるとして設定されていることを示す。

例えば、ValueID（この場合、KeywordIDになる）が“0000000008”の場合、M_KEYWORD_2データベース２７７内のKeywordの欄が参照され、“得”というのが読み出され、Displayの欄の“０”という値が読み出される。このDisplayの欄の“０”という値（フラグ）は、ユーザ側に提示されないとして設定されていることを示す。よって、結果としてユーザ側には提示されないので、このような処理を行う必要もなく、Displayの欄が“０”のときには、“０”と判断された時点で、処理は、次のValueIDの要素へと移行される。

このように、M_KEYWORD_1データベース２７６を用い、図５０に示したフローチャートの処理を実行した場合も、ユーザに提示される言葉として不適切な言葉は、提示されないように制御することが可能である。しかしながら、図１８に示したM_KEYWORD_２データベース２７７を用いた処理では、ユーザに提示するにはふさわしくない言葉を、他の言葉に変換して提示するといった処理はできない。よって、他の言葉に変換しなくても良いようなシステムにおいては、有効な処理の仕方である。

このように、本発明においては、ユーザ側に提示する言葉を制御することができる。本実施の形態においては、主に、番組を推薦する場合を例に挙げて説明したが、番組以外の情報を推薦するような場合も本発明を適用することはできる。所定の情報をユーザに推薦する際、なぜその情報が推薦されたのか、その根拠をユーザ側に提示することができ、また、その提示される内容は、ユーザが認識しやすい言葉で提示されるので、ユーザは、提示される内容を理解しやくすくなり、提示される内容に信頼性をもつことができるようになる。

また、本発明によれば、その提示される内容は、ユーザの嗜好を良く考慮したものとすることができる。その理由は、上述したように、ユーザの嗜好に関するデータを、登録、学習、フィルタリングといった複数の処理を総合的に行うようにしたので、より、詳細に、ユーザの嗜好を解析することができるようになる。

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

記録媒体は、図４に示すように、パーソナルコンピュータとは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されている磁気ディスク９１（フレキシブルディスクを含む）、光ディスク９２（CD-ROM（Compact Disc-Read Only Memory），DVD（Digital Versatile Disc）を含む）、光磁気ディスク９３（MD（Mini-Disc）（登録商標）を含む）、若しくは半導体メモリ９４などよりなるパッケージメディアにより構成されるだけでなく、コンピュータに予め組み込まれた状態でユーザに提供される、プログラムが記憶されているＲＯＭ７２や記憶部７８が含まれるハードディスクなどで構成される。

なお、本明細書において、媒体により提供されるプログラムを記述するステップは、記載された順序に従って、時系列的に行われる処理は勿論、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。

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

従来のＥＰＧ画面について説明するための図である。 従来の番組のオススメ画面について説明するための図である。 本発明を適用したシステムの一実施の形態の構成を示す図である。 ユーザ端末の内部構成例を示す図である。 ユーザ端末の基本的な処理を説明するためのフローチャートである。 ＥＰＧの画面例を示す図である。 オススメ画面の一例を示す図である。 オススメ画面の他の例を示す図である。 サーバの内部構成例を示す図である。 サーバの機能ついて説明する機能ブロック図である。 記憶部に記憶されているデータベースについて説明するための図である。 M_CATEGORYデータベースについて説明するための図である。 M_PERSONデータベースについて説明するための図である。 M_PERSON_CHARACTERデータベースについて説明するための図である。 M_VIEW_TYPEデータベースについて説明するための図である。 M_KEYWORDデータベースについて説明するための図である。 M_KEYWORD_1データベースについて説明するための図である。 M_KEYWORD_2データベースについて説明するための図である。 M_AGEデータベースについて説明するための図である。 M_GENDERデータベースについて説明するための図である。 M_REASONデータベースについて説明するための図である。 マスターデータベースから情報を検出する際の処理について説明するための図である。 マスターデータベースから情報を検出する際の処理について説明するための図である。 T_PERSON_TARGET_GENDERデータベースについて説明するための図である。 T_PERSON_TARGET_AGEデータベースについて説明するための図である。 T_PERSON_TARGET_GENDERデータベースについて説明するための図である。 T_PERSON_VIEW_TYPEデータベースについて説明するための図である。 T_PERSON_CHARACTERデータベースについて説明するための図である。 T_PRG_VALUEデータベースについて説明するための図である。 T_UM_VALUEデータベースについて説明するための図である。 T_PRG_VALUEデータベースを作成する際の処理について説明するためのフローチャートである。 表示される情報と、その情報に関するデータの関係について説明するための図である。 T_UM_VALUEデータベースを作成する際の処理について説明するためのフローチャートである。 T_UM_VALUEデータベースを作成する際の他の処理について説明するためのフローチャートである。 Scoreの変更に関わる処理について説明するための図である。 要素の追加に関する処理について説明するための図である。 学習処理をした場合と、学習処理をしない場合とを比較するためのグラフである。 フィルタリング処理を行う理由について説明するための図である。 他のユーザの履歴から所定のコンテンツを推薦する場合の処理について説明するための図である。 他のユーザの履歴から所定のコンテンツを推薦する場合の処理について説明するための図である。 フィルタリング処理について説明するためのフローチャートである。 フィルタリング処理について説明するためのフローチャートである。 ユーザグループの作成について説明するためのフローチャートである。 フィルタリング処理について説明するためのフローチャートである。 推薦する番組の検索に関わる処理について説明するためのフローチャートである。 推薦理由を取得する際の処理について説明するためのフローチャートである。 ReasonTypeに関わる処理を実行するデータについて説明するための図である。 ReasonTypeに関わる処理を実行するデータについて説明するための図である。 推薦理由を取得する際の処理について説明するためのフローチャートである。 推薦理由を取得する際の処理について説明するためのフローチャートである。

符号の説明

５１ ネットワーク， ５２ サーバ， ５３ ユーザ端末， ５４ 放送局， １０１ ディスプレイ， １１２ オススメマーク， １１３ オススメボタン， １１４ ランキングボタン， １５１ 番組表示部， １５２ 放送時間表示部， １５３ 内容表示部， １５４ 出演者表示部， １５５ 理由表示部， １５６ オススメ度表示部， ２３１ ログ生成機能， ２３２ ユーザ管理機能， ２３３ 情報選別機能， ２３４ サービス管理機能， ２３５ ユーザモデル管理機能， ２３６ 情報通信機能， ２３７ 対象情報メタデータ管理機能， ２３８ サービス一般機能， ２５１ マスターデータベース， ２５２ ターゲットデータベース， ２５３ ログデータベース， ２５４ ユーザデータベース

Claims (7)

1. 複数のユーザの嗜好に関する第１のデータを、ユーザ毎に管理する第１の管理手段と、
   前記第１のデータを用いて、ユーザ同士の相関度を算出する第１の算出手段と、
   前記第１の算出手段により算出された前記相関度のうち、一方のユーザは有しているが他方のユーザは有していない要素に対する相関度を用いて予測ベクトルを算出する第２の算出手段と
   を備えることを特徴とする情報処理装置。
2. 情報に関する第２のデータを管理する第２の管理手段と、
   前記第２の算出手段により算出された前記予測ベクトルを用いて、処理対象とされている前記ユーザの嗜好に一致するであろう情報を、前記第２のデータ内から検出する検出手段と
   をさらに備えることを特徴とする請求項１に記載の情報処理装置。
3. 前記第１の算出手段により算出された前記相関度をソートし、隣接する相関度を有するユーザ同士を１つのグループとして設定する設定手段と、
   前記設定手段により設定されたグループの総数が、所定の数以下になるまで、前記設定手段による処理が繰り返し行われるように、前記所定の数以下になったか否かを判断する判断手段と
   をさらに備え、
   前記第２の算出手段は、前記グループを前記ユーザとして扱い、グループ間の予測ベクトルを算出する
   ことを特徴とする請求項１に記載の情報処理装置。
4. 前記ユーザが利用した情報に関するログを管理する第３の管理手段と、
   前記第３の管理手段により管理されている前記ログを参照し、同じ情報を利用した前記ユーザを抽出する抽出手段と、
   前記抽出手段により抽出された前記ユーザをグループとして設定する設定手段と
   をさらに備え、
   前記第２の算出手段は、前記グループ間の予測ベクトルを算出する
   ことを特徴とする請求項１に記載の情報処理装置。
5. データを管理するための記憶手段と、記憶手段に記憶されている前記データを用いて所定の処理を実行する制御手段とを少なくとも備えた情報処理装置の情報処理方法であって、
   複数のユーザの嗜好に関する第１のデータを、ユーザ毎に管理する第１の管理ステップと、
   前記第１のデータを用いて、ユーザ同士の相関度を算出する第１の算出ステップと、
   前記第１の算出ステップの処理で算出された前記相関度のうち、一方のユーザは有しているが他方のユーザは有していない要素に対する相関度を用いて予測ベクトルを算出する第２の算出ステップと
   を含むことを特徴とする情報処理方法。
6. データを管理するための記憶手段と、記憶手段に記憶されている前記データを用いて所定の処理を実行する制御手段とを少なくとも備えた情報処理装置のプログラムであって、
   複数のユーザの嗜好に関する第１のデータを、ユーザ毎に管理する第１の管理ステップと、
   前記第１のデータを用いて、ユーザ同士の相関度を算出する第１の算出ステップと、
   前記第１の算出ステップの処理で算出された前記相関度のうち、一方のユーザは有しているが他方のユーザは有していない要素に対する相関度を用いて予測ベクトルを算出する第２の算出ステップと
   を含むことを特徴とするプログラム。
7. 請求項６に記載のプログラムを記録している
   ことを特徴とする記録媒体。
   

Images