視聴履歴記録方法および視聴履歴利用方法
デジタルＴＶ等の電化機器（１１）では、デバイスエージェント（２０）が視聴日時とメディア種別識別子およびコンテンツ識別子とを組にして視聴履歴データとして記録する。サーバ装置（１２）では、ユーザエージェント（３０）がデバイスエージェント（２０）から視聴履歴データを受信して視聴履歴データベースに登録する。外部のサービスコンシェルジェ（４０，５０）はサーバ装置（１２）にアクセスして、ユーザが有する電化機器（１１）におけるコンテンツ視聴履歴を一括利用する。
【発明の詳細な説明】
【技術分野】
本発明は、相互に接続された電化機器におけるコンテンツ視聴の履歴を、ユーザ単位、あるいは家族単位で、一元的に管理し利用するための技術に属する。
【背景技術】
従来から、ユーザのコンテンツ視聴履歴をマーケティングや情報推薦に利用する方法が提案されている。例えば、ＰＨＳ機能の付与されたリモコンでユーザのチャンネル操作の履歴を記録し、ＰＨＳ網を介して操作履歴をサーバにアップロードして視聴率調査に利用する方法（特許文献１、特に図１を参照）や、ＴＶやインターネットなど複数の情報源の視聴履歴を一括管理して、ユーザの好みに合致したコンテンツを推薦する装置（特許文献２、特に図２を参照）などがある。また、複数の電化製品をコントロールするリモートコントローラによって、ユーザの各電化製品の利用履歴をサーバーに通信ネットワークを通じて送信するシステムも、提案されている（特許文献３）。
（特許文献１） 特開２００２−７７４３６号公報
（特許文献２） 特開平１１−７４５３号公報
（特許文献３） 特開２００２−２０３１６８号公報
解決課題
ところが、従来の技術の多くは、ＴＶ番組の視聴履歴をセンターで収集するなど単一のメディアに対するもの、あるいは、インターネットの閲覧履歴を利用してＴＶ番組を推薦するテレビのように複数のメディアを扱う単一の機器に対するものであった。
今後は、機器のネットワーク化がますます進展することが予想され、ユーザが所有する複数の機器におけるコンテンツ視聴履歴を統合して、ネットワークを介したユーザの嗜好の分析などのマーケティング調査やコンテンツ推薦のサービスに利用できるようにする必要がある。
ところで、コンテンツ視聴履歴からユーザの好みを推測する一般的な方法では、電子プログラムガイド（ＥＰＧ：Ｅｌｅｃｔｒｉｃ Ｐｒｏｇｒａｍ Ｇｕｉｄｅ）に代表されるコンテンツの属性情報（メタ情報）を利用して、「どのジャンル」または「どんなキーワードを含む」コンテンツをよく見ているかというメタ情報レベルの統計データに変換することによって、ユーザの好みの判断が行われている。
しかしながら、ＥＰＧなどのメタ情報においてジャンルやキーワードとして用いられる語彙の集合や情報の詳細度は、メタ情報を提供するプロバイダごとに異なっている。このため、端末側でメタ情報を利用してコンテンツ視聴履歴をメタ情報レベルの統計データに変換してしまうと、複数の機器のコンテンツ視聴履歴を統合して利用しようとする際に、他の機器において他のメタ情報を利用して得られたメタ情報レベルの統計データと整合性がとれないという問題が起こる。
また、複数の機器のコンテンツ利用履歴を利用する方法としては、必要なときにネットワークを介してそれぞれの機器にコンテンツ利用履歴を問い合わせる方法も考えられるが、すべての機器が常時通電されていてネットワークからのアクセスに応答できる、と仮定することは、現実的ではない。
また、従来は、例えば特許文献３のように、装置毎に役割（履歴の記録、履歴の収集管理、履歴の分析）が固定化されており、１個の装置に複数の役割を持たせることができなかったり、電化機器に組み込まれたサービスとインターネットを介して提供されるサービスとで視聴履歴を利用する仕組みを共通化できない、など柔軟性にかけていた。
さらに、従来は、視聴履歴を蓄積したデータ形式そのままで提供するものがほとんどであり、視聴履歴への効率的なアクセスが、必ずしも実現されていなかった。
前記の問題に鑑み、本発明は、ユーザが有する機器におけるコンテンツ視聴履歴を統合的に管理し、コンテンツ視聴履歴を利用したサービスを、柔軟に、かつ、効率的に、提供可能にすることを課題とする。
【発明の開示】
具体的には、本発明は、コンテンツ視聴に利用される電化機器においてコンテンツ視聴履歴データを記録する方法として、当該電化機器に対するユーザの操作を解釈してコンテンツ視聴操作を抽出し、抽出されたコンテンツ視聴操作に係るコンテンツについてコンテンツ識別子を求め、前記コンテンツについて、抽出されたコンテンツ視聴操作から視聴日時を特定し、特定した視聴日時と前記コンテンツ識別子とを組にして視聴履歴記憶部に視聴履歴データとして記録するものである。
また、本発明は、複数の機器におけるコンテンツの視聴履歴を利用する方法として、コンテンツが前記複数の機器にわたって共通の識別子によって特定されているコンテンツ視聴履歴データから、同一の識別子を持つコンテンツに対し、前記複数の機器において行われた一連の操作パターンを抽出し、抽出した操作パターンの中から、共通の属性を有するコンテンツに対して共通に行われた操作パターンを特定し、特定した操作パターンを、当該属性を有する他のコンテンツに適用するための、操作パターン再現スクリプトを生成するものである。
また、他の態様では、ネットワークシステムとして、コンテンツ視聴に利用され、デバイスエージェントを有する少なくとも１つの電化機器と、前記電化機器とネットワークを介して接続され、ユーザエージェントを有するサーバ装置とを備え、前記デバイスエージェントは、コンテンツの視聴履歴データを格納するための視聴履歴記憶部を備え、かつ、各コンテンツについて、視聴日時を特定し、この特定した視聴日時と、当該コンテンツに係るメディアの種別を特定するメディア種別識別子、および特定されたメディアにおいて当該コンテンツを一意に特定するコンテンツ識別子とを組にして、視聴履歴データとして、前記視聴履歴記憶部に記録するものであり、前記ユーザエージェントは、コンテンツの視聴履歴データを格納するための視聴履歴データベースを備え、かつ、前記電化機器のデバイスエージェントから視聴履歴データを受信して、前記視聴履歴データベースに登録するものである。
この態様によると、電化機器では、デバイスエージェントが、各コンテンツについて、視聴日時と、メディア種別識別子およびコンテンツ識別子とを組にして、視聴履歴データとして記録する。メディア種別識別子は、当該コンテンツに係るメディアの種別を特定し、コンテンツ識別子は、特定されたメディアにおいて当該コンテンツを一意に特定する。そして、サーバ装置では、ユーザエージェントが、電化機器のデバイスエージェントから視聴履歴データを受信して、視聴履歴データベースに登録する。これにより、サーバ装置の視聴履歴データベースには、少なくとも１つの電化機器によって視聴された各コンテンツについて、視聴日時と、メディア種別識別子およびコンテンツ識別子とが、格納される。すなわち、コンテンツ視聴履歴がメディア識別子とコンテンツ識別子を用いて蓄積されるので、サービス側と視聴履歴蓄積側の相互運用性を高めることができる。
また、他の態様では、コンテンツ視聴に利用される少なくとも１つの電化機器と、前記電化機器とネットワークを介して接続されたサーバ装置とを備えたシステムにおいて、コンテンツ視聴履歴を管理する方法として、前記電化機器が、各コンテンツについて視聴日時を特定し、特定した視聴日時と、当該コンテンツに係るメディアの種別を特定するメディア種別識別子、および特定されたメディアにおいて当該コンテンツを一意に特定するコンテンツ識別子とを組にして、視聴履歴データとして視聴履歴記憶部に記録し、前記サーバ装置が、前記電化機器から視聴履歴データを受信し、受信した視聴履歴データを視聴履歴データベースに登録するものである。
この態様によると、電化機器が、各コンテンツについて、視聴日時と、メディア種別識別子およびコンテンツ識別子とを組にして、視聴履歴データとして記録する。メディア種別識別子は、当該コンテンツに係るメディアの種別を特定し、コンテンツ識別子は、特定されたメディアにおいて当該コンテンツを一意に特定する。そして、サーバ装置が、電化機器から視聴履歴データを受信して、視聴履歴データベースに登録する。これにより、サーバ装置の視聴履歴データベースには、少なくとも１つの電化機器によって視聴された各コンテンツについて、視聴日時と、メディア種別識別子およびコンテンツ識別子とが、格納される。すなわち、コンテンツ視聴履歴がメディア識別子とコンテンツ識別子を用いて蓄積されるので、サービス側と視聴履歴蓄積側の相互運用性を高めることができる。
そして、前記視聴履歴管理方法は、前記システムの外部にあるアプリケーションサーバが、前記サーバ装置にアクセスして、前記視聴履歴データベースから視聴履歴データを取得し、コンテンツ視聴に関する分析を行うのが好ましい。
また、他の態様では、コンテンツ視聴に利用される電化機器に設けられるデバイスエージェントとして、コンテンツの視聴履歴データを格納するための視聴履歴記憶部と、当該電化機器に対するユーザの操作を解釈してコンテンツ視聴操作を抽出する操作入力解釈部と、抽出されたコンテンツ視聴操作に係るコンテンツについてコンテンツ識別子を求めるコンテンツＩＤ生成部と、前記コンテンツについて、抽出されたコンテンツ視聴操作から視聴日時を特定し、特定した視聴日時と前記コンテンツ識別子とを組にして、前記視聴履歴記憶部に視聴履歴データとして記録する視聴履歴記録部とを備えたものである。
そして、前記デバイスエージェントにおけるコンテンツＩＤ生成部は、前記コンテンツ識別子を、当該コンテンツが格納されたメディア媒体から抽出する、または、当該コンテンツに係るメディアに関する属性情報から所定の方法によって生成するのが好ましい。
また、前記デバイスエージェントは、前記視聴履歴記憶部に格納された視聴履歴データを、所定のタイミングで、当該視聴履歴データが所定量になったとき、または、当該電化機器の外部から送信要求があったとき、当該電化機器の外部に送信する視聴履歴送信部を備えているのが好ましい。
また、他の態様では、ユーザが所有する、またはユーザが利用する権利を持つ少なくとも１つの電化機器とネットワークを介して接続されるサーバ装置に設けられるユーザエージェントとして、少なくとも１つのメディア種別におけるコンテンツの視聴履歴データをコンテンツのメディア種別を特定可能な形式で格納するための視聴履歴データベースと、前記電化機器から送信された視聴履歴データを受信する視聴履歴受信部と、受信した視聴履歴データを前記視聴履歴データベースに登録する視聴履歴登録部とを備えたものである。
そして、前記ユーザエージェントは、視聴履歴データに関する問合せを受信する問合せ受信部と、受信した問合せに応じて、視聴履歴の開示制限を加味しつつ、前記視聴履歴データベースを検索し、当該問合せに対する応答を作成する応答作成部と、作成した応答を当該問合せを送信した主体に返信する応答送信部とを備えているのが好ましい。
【図面の簡単な説明】
図１は本発明の一実施形態におけるシステムの全体構成を示す図である。
図２は図１の各構成要素に搭載される主要なモジュールを示す概念図である。
図３は本発明の一実施形態におけるデバイスエージェントの構成を示すブロック図である。
図４は図３のデバイスエージェントがコンテンツ視聴履歴を記録する動作を示すフローチャートである。
図５は図３のデバイスエージェントにおける操作解釈テーブルの一例である。
図６はメディア種別識別子の一例である。
図７はコンテンツ識別子の生成方法を示す図である。
図８は放送局識別子を得るためのテーブルの一例である。
図９はデバイスエージェントに蓄積された視聴履歴データの例である。
図１０は図３のデバイスエージェントが視聴履歴データを送信する動作を示すフローチャートである。
図１１はデバイスエージェントに蓄積された視聴履歴データの他の例である。
図１２は本発明の一実施形態におけるユーザエージェントの構成を示すブロック図である。
図１３は図１２のユーザエージェントが、送信された視聴履歴データを登録する動作を示すフローチャートである。
図１４はユーザエージェントに蓄積された視聴履歴データの一例である。
図１５は図１２のユーザエージェントが問合せに応答する動作を示すフローチャートである。
図１６（ａ）はユーザエージェントが受信した問合せメッセージ、図１６（ｂ）はその応答メッセージである。
図１７はマーケティング調査を行うサービスコンシェルジェの構成を示すブロック図である。
図１８は図１７のサービスコンシェルジェの動作を示すフローチャートである。
図１９は調査条件を受け付けるためのＧＵＩ画面である。
図２０は図１７のサービスコンシェルジェが送信する問合せメッセージと、その応答メッセージの例である。
図２１は集計結果の表示例である。
図２２はコンテンツ推薦を行うサービスコンシェルジェの構成を示すブロック図である。
図２３は図２２のサービスコンシェルジェの動作を示すフローチャートである。
図２４は図２２のサービスコンシェルジェが送信する問合せメッセージと、その応答メッセージの一例である。
図２５はコンテンツを推薦するメールメッセージの一例である。
図２６は番組時間と視聴時間との関係を説明するための図である。
図２７は番組視聴の判断方法を示すフローチャートである。
図２８は番組放送時間の変更への対応を説明するための図である。
図２９はコンテンツ自動管理のためのスクリプトを提供するサービスコンシェルジェの構成を示すブロック図である。
図３０は図２９のサービスコンシェルジェに対応したデバイスエージェントの構成を示すブロック図である。
図３１は図２９のサービスコンシェルジェの動作を示すフローチャートである。
図３２はコンテンツ視聴履歴データの一例である。
図３３はコンテンツのメタ情報の一例である。
図３４はユーザに追加機能を選択させる画面例である。
【発明を実施するための最良の形態】
以下、本発明の実施の形態について、図面を参照して説明する。
＜全体構成＞
図１は本発明の一実施形態におけるシステムの全体構成を示す図である。図１において、１１はデジタルＴＶやビデオなどのコンテンツ視聴に利用される電化機器としての端末家電機器、１２は常時通電されており、所定の条件に従ってＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）側からのアクセスが許されたホームサーバやホームゲートウェイなどのサーバ装置としてのサーバ家電機器、１３はサーバ家電機器１２へのアクセスを許可されたアプリケーションサーバ、１４ａ，１４ｂはイーサネット（Ｅｔｈｅｒｎｅｔ）などの有線ネットワークや８０２．１１ｂに代表される無線ネットワークから構成されるＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、１５はＷＡＮ（インターネット）、１６ａ，１６ｂはＬＡＮ１４ａ，１４ｂをＷＡＮ１５に接続するルータである。なお、ＷＡＮへのアクセスにＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ）やＦＴＴＨ（Ｆｉｂｅｒ Ｔｏ Ｔｈｅ Ｈｏｍｅ）を利用する場合など、必要に応じて、対応するモデム機能をルータ１６ａ，１６ｂに持たせてもよい。
図２は図１における端末家電機器１１、サーバ家電機器１２およびアプリケーションサーバ１３に搭載される主要なモジュールを示す概念図である。図２に示すように、端末家電機器１１には、ユーザの操作をトリガとしてコンテンツ視聴履歴を記録するデバイスエージェント２０がそれぞれ搭載されている。またサーバ家電機器１２には、デバイスエージェント２０から例えば所定のタイミングで送信されるコンテンツ視聴履歴を受け付けて一元管理するユーザエージェント３０が搭載され、アプリケーションサーバ１３には、ユーザエージェント２０が提供するコンテンツ視聴履歴を利用したサービスを提供するサービスコンシェルジェ４０，５０がそれぞれ搭載されている。
デバイスエージェント２０およびユーザエージェント３０は、ＣＰＵやメモリなどのハードウェアと、プログラムなどのソフトウェアとの組み合わせによって実現される。デバイスエージェント２０を有する端末家電機器１１と、ユーザエージェント３０を有するサーバ家電機器１２とによって、本発明に係るネットワークシステムが構成されている。
なお、例えば録画機能を有するホームサーバなど、コンテンツ視聴履歴を記録する必要があるサーバ家電装置１２については、ユーザエージェント３０に加えて、デバイスエージェント２０を搭載してもよい。また、サーバ家電装置１２となり得る家電機器が複数存在する場合は、所定の方法によって、１個の機器をサーバ家電装置１２として選択する。
また、サービスコンシェルジェは、必要に応じて端末家電機器１１に搭載してよい。これにより、他の端末家電機器１１の視聴履歴を利用した連携アプリケーションを容易に実現できる。例えば、ＭＤコンポにサービスコンシェルジェを搭載することによって、ユーザエージェントを介してデジタルＴＶの視聴履歴を取得し、ユーザが視聴した番組の主題歌を自動的にダウンロードするサービスを実現することができる。
また、携帯電話のＪａｖａアプリケーションと同様に、サービスコンシェルジェのデータ部分（メタ情報データベース）をアプリケーションサーバ１３に配置し、プログラム部分をサーバ家電装置１２にダウンロードするようにしてもよい。このように構成することによって、視聴履歴がネットワーク上を流れないようにできるため、プライバシー保護を強化することができる。
すなわち、デバイスエージェント、ユーザエージェントおよびサービスコンシェルジェは、ネットワークで接続された機器上に、自由に配置してよい。
次に、図２における各モジュールの構成と動作について説明する。
＜デバイスエージェント＞
図３はデバイスエージェント２０の構成を示すブロック図である。図３において、２１はリモコンなどを介して入力されるユーザからの操作を受け付ける操作入力部、２２は操作入力部２１からの操作入力を解釈して当該家電機器１１の動作状態を決定するとともに、コンテンツ視聴操作を抽出する操作入力解釈部、２３は操作入力解析部２２の解析結果に応じて当該家電機器１１を制御する機器制御部、２４はメディア種別毎に所定の方法を用いて、コンテンツを識別するためのコンテンツ識別子を生成するコンテンツＩＤ生成部、２５はコンテンツの視聴履歴データを格納するための視聴履歴記憶部、２６は操作入力解析部２２によって抽出されたコンテンツ視聴操作から視聴日時を特定し、特定した視聴日時とコンテンツＩＤ生成部２４によって生成されたコンテンツ識別子とを組にして視聴履歴記憶部に視聴履歴データとして記録する視聴履歴記録部、２７は視聴履歴記憶部２５に蓄積された視聴履歴データを、例えば所定のタイミングで、ネットワークＩＦ２８を介してデバイスエージェント３０宛に送信する視聴履歴送信部である。
ここでは、図３のデバイスエージェント２０は、デジタルＴＶに設けられているものとする。そして、コンテンツの視聴日時として、視聴開始日時および視聴終了日時を記録するものとする。なお、コンテンツの視聴終了日時の代わりに、コンテンツ視聴時間を記録してもよい。
図４のフローチャートを用いて、図３のデバイスエージェント２０がコンテンツ視聴履歴を記録する動作について説明する。
（ステップａ１）
ユーザからのリモコン操作を操作入力部２１によって受け付ける。ここでは、ユーザが地上波放送の８ｃｈをデジタルＴＶで見ており、リモコンのチャンネルアップボタンを２回押したものとする。リモコン以外からの入力操作についても同様に処理される。
（ステップａ２）
ステップａ１で受け付けた操作入力を、操作入力解釈部２２が操作解釈テーブル２２ａを参照して解釈し、コンテンツ視聴に関する操作すなわちコンテンツ視聴操作に該当するか否かを判断する。図５は操作解釈テーブル２２ａの一例である。受け付けた操作入力が操作解釈テーブル２２ａに定義されているとき（Ｙｅｓ）は、コンテンツ視聴操作に該当すると判断して、ステップａ３にすすむ。一方、受け付けた操作入力が操作解釈テーブル２２ａに定義されていないとき（ｎｏ）は、コンテンツ視聴操作ではないと判断して、デバイスエージェント２０は動作を終了する。
ここでは、８ｃｈの状態からチャンネルアップボタンが２回押されたため、コンテンツ視聴操作に該当しており、「チャンネルを１０ｃｈに変更する」と解釈される。なお、チャンネルアップ以外でも、リモコンのボタンでダイレクトに１０ｃｈを指定した場合やＥＰＧ番組表から現在放送中の１０ｃｈの番組を選択した場合も、同一の解釈がなされる。
（ステップａ３）
機器制御部２３によって、操作入力に対応する制御を実行する。ここでは、チャンネルを２個アップさせて１０ｃｈに変更する。なお、チャンネルアップボタン、ダイレクトボタン、ＥＰＧなど入力操作の方法に応じて、画面の切り替え動作を変更してもよい。
（ステップａ４）
操作入力が、操作解釈テーブル２２ａに記述された操作履歴記録条件を満たしているか否かを判断する。満たしているときは（ｙｅｓ）ステップａ５にすすむ一方、満たしていないときは（ｎｏ）、記録する必要がないと判断して、デバイスエージェント２０は動作を終了する。
図５では、操作履歴記録条件として「操作後一定時間チャンネルを保持」と規定されている。ここでは、チャンネルが１０ｃｈに変更された後、一定時間チャンネルが保持されたものとして、ステップａ５にすすむ。
（ステップａ５）
視聴履歴記録部２６は、視聴履歴データを視聴履歴記憶部２５に記録する。具体的にはここでは、８ｃｈの視聴が終了して１０ｃｈの視聴が開始されたと判断し、視聴開始日時記憶部（図示せず）に記憶しておいた８ｃｈの視聴開始日時を読み出すとともに、現在日時を８ｃｈの視聴終了日時として、これら視聴開始日時および視聴終了日時と、メディア種別識別子およびコンテンツＩＤ生成部２４によって生成されたコンテンツ識別子とを組にして、視聴履歴記憶部２５に記録する。このとき、現在日時を１０ｃｈの視聴開始日時として視聴開始日時記憶部に記憶しておく。
図６はメディア種別識別子の一例を示す図である。「メディア種別識別子」は、コンテンツの視聴履歴データを一元的に管理できるようにするために、当該コンテンツに係るメディアの種別を特定するものである。ここでは、地上波アナログ放送を視聴したので、メディア種別識別子として“Ｖｉｄｅｏ＿ＵＶ”が記録される。
またここでは、図７に示すようにしてコンテンツ識別子が生成される。「コンテンツ識別子」は、特定されたメディアにおいて当該コンテンツを一意に特定するものである。まず、地域を特定するコード（ここでは郵便番号）および受信チャンネルから、放送局識別子を得る。最近のＴＶ受像機やビデオなどのチューナを搭載する機器では、設置時のチャンネル設定を簡易にするために、７桁の郵便番号を入力するだけでチャンネル設定が完了できるようになっている。このような機器では、図８に示すような、７桁の郵便番号から地域を特定するためのテーブル（ａ）と、地域コードから各チャンネルに割り当てるべき放送局を決定するためのテーブル（ｂ）とが搭載されている。したがって、これらのテーブルを利用することによって、簡単に放送局識別子を得ることができる。なお、地域を特定するコードとして、固定電話の市外局番や市内局番などを組み合わせて利用してもよい。
そして、得られた放送局識別子とコンテンツの視聴日時とを用いて、所定の数式によって、コンテンツ識別子を生成する。ここでは可逆的な変換を行うものとし、所定の逆変換によって、コンテンツ識別子から放送局識別子と視聴日時を抽出できるものとする。
このようにして生成されたコンテンツ識別子は、視聴日時およびメディア種別識別子と併せて、視聴履歴記憶部２５に記録される。このような動作の結果、図９に示すような視聴履歴データが視聴履歴記憶部２５に蓄積される。
ところで、コンテンツ識別子の取得（付与）については、メディアの種別ごとに様々な方法が考えられる。代表的な方法としては、上述したような当該コンテンツに係る属性情報から所定の方法によって生成する方法や、当該コンテンツが格納されたメディア媒体から抽出する方法がある。
例えば、ＴＶのアナログ地上波放送の場合は、受信した地域、チャネル（ＶＨＦ２ｃｈなど）、受信した時間帯の３つの属性情報を組み合わせることによって、ユーザが視聴したコンテンツを特定可能であり、これをコンテンツ識別子として利用することができる。また、ＥＰＧのデータを用いて、視聴した時間帯から番組の名称等を取り出してコンテンツ識別子として利用する方法もあるが、野球の試合延長などによって放送時間枠が急遽変更されたとき、コンテンツと識別子との対応がとれないおそれがある。
デジタル放送では、番組データと同時に送信されるメタ情報から番組のコンテンツ識別子を得ることができる。また、ＣＤなどの従来メディアの場合では、収録時間やトラック数などの個々のメディアに固有の情報からＩＤを算出する方法が一般に用いられている。さらに、ＤＶＤなどの新しいメディアでは、ディスクに予め記録されたコンテンツ識別子を読み出す方法が利用可能である。
アプリケーションサーバ側でコンテンツ視聴履歴の分析を可能にするためには、複数のデバイスエージェントとサービスコンシェルジェとの間で、メディア種別毎に、共通の識別子を利用する必要がある。しかしながら、異なる識別子体系間の変換および相互運用は、変換テーブルを用いれば容易に実現できるため、さほど大きな問題にはならない。これに対して、仮にＥＰＧなどを用いてメタ情報レベルの統計データに変換している場合には、相互運用の実現のために、それぞれのメタ情報で用いられている語彙体系間のマッピングを行う変換テーブルが必要になる。語彙体系間のマッピングは、語彙空間が増大していく性質もあり、メンテナンスを含めて実現が極めて困難である。
次に図１０のフローチャートを用いて、図３のデバイスエージェント２０が視聴履歴データの送信を行う動作について説明する。この動作は、コンテンツ視聴履歴を記憶する図４の動作に対し、パラレルに行っても、またはシーケンシャルに行ってもかまわない。送信された視聴履歴データはサーバ家電機器１２のユーザエージェント３０によって受信される。
（ステップａ６）
ユーザエージェント３０への視聴履歴データのアップデートを行うタイマー割り込みが発生しているか否かを調べ、割り込みが発生しているときはステップａ９にすすむ。一方、そうでないときは、ステップａ７にすすむ。
（ステップａ７）
視聴履歴記憶部２５が視聴履歴データで一杯になっているか否かを調べ、データが一杯になっているときはステップａ９にすすむ。一方、そうでないときは、ステップａ８に進む。なお、一杯になっている否かの代わりに、視聴履歴データが所定量になったか否かによって判断してもよい。
（ステップａ８）
ユーザエージェント３０からの視聴履歴のアップデートの要求があるか否かを調べ、要求があるときはステップａ９にすすむ。一方、そうでないときは、動作を終了する。
（ステップａ９）
視聴履歴送信部２７からネットワークＩ／Ｆ２８を介して、ユーザエージェント３０に対して、視聴履歴記憶部２５に蓄積されたコンテンツ視聴履歴を送信する。すなわちここでは、タイマー割り込みによる所定のタイミングで、視聴履歴データが送信され、また、視聴履歴記憶部２５が視聴履歴データで一杯になったとき、若しくは当該電化機器の外部から送信要求があったとき、視聴履歴データが送信される。なお、ステップａ６〜ａ８の条件は必ずしも必須ではなく、省くことも可能である。
（ステップａ１０）
送信が完了したか否かを確認し、完了したときはステップａ１１にすすむ。一方、そうでないときは動作を終了する。
（ステップａ１１）
送信済みの視聴履歴データを視聴履歴記憶部２５から削除して、動作を終了する。
なお、コンテンツの視聴日時だけでなく、コンテンツに対して実行した操作の履歴も視聴履歴データとして記録するようにしてもよい。図１１はこの場合の視聴履歴記憶部２５の蓄積データの一例である。この場合には、相互運用性を確保するために、コンテンツに対して実行可能な操作（再生、録画、消去、停止コピーなど）の識別子を統一すればよい。操作履歴を記録することによって、サービスコンシェルジェ側で、どういうコンテンツ（ジャンル、アーティスト、キーワード）に対してどういう操作（蓄積、再生、削除）を行っているかを判断することができる。
例えば、
（１）ニュースはストリーム（リアルタイム放送）でしか見ない。
（２）バラエティはＨＤＤに蓄積するが、１回見たら消去する。
（３）ドラマはＨＤＤに一旦蓄積して、タイトルごとにＤＶＤに移動する
などである。これは、各コンテンツに対するユーザ毎の典型的な操作シーケンスを自動実行するサービスに応用できる。
また、デバイスエージェントが記録する操作履歴を逆向きに利用することによって、サービスコンシェルジェからデバイスの操作（コンテンツの蓄積、再生、削除）を容易に実現できる。さらに、サービスコンシェルジェからユーザエージェントにコンテンツの操作要求（操作履歴と同じフォーマット）を出すことによって、適したデバイスに対して、操作要求を実行させることができる。
＜ユーザエージェント＞
図１２はユーザエージェント３０の構成を示すブロック図である。図１２において、３１はデバイスエージェント２０から送信された視聴履歴データを受信する視聴履歴受信部、３２は視聴履歴データを格納するための視聴履歴データベース、３３は視聴履歴受信部３１によって受信した視聴履歴データを視聴履歴データベース３２に登録する視聴履歴登録部、３４はサービスコンシェルジェからの問合せ要求を受信する問合せ受信部、３５は問合せ受信部３４によって受信した問合せの内容に応じて視聴履歴データベース３２を検索し、当該問合せに対する応答を作成する応答作成部、３６は問合せを送信した主体となるサービスコンシェルジェに対して、応答作成部３５によって作成された応答を送信する応答送信部である。
まず、図１３のフローチャートを用いて、ユーザエージェント３０がデバイスエージェント２０から送信された視聴履歴データを視聴履歴データベース３２に登録する動作について説明する。
（ステップｂ１）
視聴履歴受信部３１はデバイスエージェント２０からの視聴履歴データを受信したか否かを調べ、視聴履歴データを受信したときはステップｂ２にすすむ。一方、そうでないときは、ステップｂ１の実行を所定の周期で継続する。
（ステップｂ２）
視聴履歴登録部３３は、視聴履歴受信部３１によって受信した視聴履歴データを取り出し、視聴履歴データベース３２に登録する。
（ステップｂ３）
視聴履歴データベース３２への視聴履歴データの登録が正常に完了したか否かを判断し、登録が正常に完了したときはステップｂ４にすすむ。一方、そうでないときは、動作を終了する。
（ステップｂ４）
視聴履歴データの送信元のデバイスエージェント２０に対して、登録完了通知を返信して、動作を終了する。
図１４は視聴履歴データベース３２に格納された視聴履歴データの一例である。図１４では、各デバイスエージェント２０から送信された視聴履歴データが視聴開始日時の順に格納されている。
次に、図１５のフローチャートを用いて、図１２のユーザエージェント３０がサービスコンシェルジェからの問合せに応答する動作について説明する。この動作は、図１３に示す視聴履歴データを登録する動作とパラレルに実行されるものとする。
（ステップｂ５）
問合せ受信部３４は、サービスコンシェルジェからの問合せを受信したか否かを調べ、問合せを受信したときはステップｂ６にすすみ、そうでないときはステップｂ５の実行を所定の周期で継続する。ここでの問合せには、所定の通信プロトコルおよびメッセージフォーマットが利用されるものとする。例えば、通信プロトコルとしてＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を、メッセージフォーマットとしてＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）を、それぞれ利用することができる。
（ステップｂ６）
応答作成部３５が問合せ受信部３４によって受信した問合せの解釈を行い、視聴履歴データベース３２を検索する。ここで、問合せの内容としては、
（１）指定された日時にどんなコンテンツを視聴しているか？
（２）指定された期間にどんなコンテンツを視聴しているか？
（３）指定された期間の指定された時間にどんなコンテンツを視聴しているか？
（４）指定された識別子のコンテンツを視聴したことがあるか？
（５）指定された識別子のコンテンツをいつ視聴したか？
などがあり、この問合せ内容に応じて検索を行う。
（ステップｂ７）
ステップｂ６における検索結果を、応答のフォーマットにエンコードする。例えば、ステップｂ６の（１）〜（５）の問合せの結果は、次のようになる。
（１）「メディア種別識別子＋コンテンツ識別子」
（２）「メディア種別識別子＋コンテンツ識別子」の集合
（３）「メディア種別識別子＋コンテンツ識別子」の集合
（４）「ＹＥＳ」または「ＮＯ」
（５）「日時」の集合
なお、応答メッセージのフォーマットは、問合せメッセージのフォーマットと同様、例えばＸＭＬで定義されたものを利用できる。
本実施形態のように、サービス提供側からの視聴履歴へのアクセスを、サービスコンシェルジェからユーザエージェントへの問合せという形で実現することによって、契約内容に応じた視聴履歴の開示制限が可能になる。すなわち、応答作成部３５は、視聴履歴の開示制限を加味しつつ、視聴履歴データベース３２を検索するのが好ましい。
従来は、視聴履歴を蓄積したデータ形式そのままの形で提供するものがほとんどであり、視聴履歴への効率的なアクセスを行うための問合せを準備しているシステムはなかった。視聴履歴へのアクセス方法として問合せを用いることによって、例えば、一度に読み出せるデータ量や期間を制限して全ての視聴履歴が不用意に読み出されることを防ぐことができる。あるいは、利用可能な問合せの種類をサービス毎に限定することによって、プライバシーを保護することができる。また、サービス提供者側にとっても、問合せの組み合わせのみによってユーザの視聴傾向を抽出できるため、視聴履歴を利用したサービスを構築しやすい、というメリットもある。
視聴履歴の開示制限の例としては、問合せ回数を制限したり、問合せ内容の種類を限定したりすることが考えられる。また例えば、上述の「指定された識別子のコンテンツをいつ視聴したか？」という問合せに対して、通常は視聴日時のリストを返信するところを、あるサービスについては、コンテンツの視聴回数のみを返信する、というように制限をかけることもできる。
（ステップｂ８）
応答作成部３５によって作成された応答メッセージを、応答送信部３６から、問合せメッセージの送信元のサービスコンシェルジェに対して送信し、動作を終了する。
図１６は問合せメッセージと応答メッセージの一例であり、ともにＸＭＬで記述されている。図１６（ａ）の問合せメッセージは、２００２年の８月１日から８月３１日までに視聴したコンテンツを問い合わせるものであり、図１６（ｂ）はそれに対応する応答メッセージである。
以上のような動作によって、サーバ家電機器１２の視聴履歴データベース３２には、少なくとも１つの端末家電機器１１によって視聴された各コンテンツについて、視聴日時と、メディア種別識別子およびコンテンツ識別子とが、格納される。すなわち、ユーザが有する端末家電機器１１におけるコンテンツ視聴履歴が、サーバ家電機器１２で一元管理されることになり、したがって、外部のサービスコンシェルジェ３０，４０は、サーバ家電機器１２にアクセスするだけで、ユーザが有する端末家電機器１１におけるコンテンツ視聴履歴を一括して利用することができる。
なお、本実施形態では、電化機器およびサーバ装置が家庭内に設置されているものとしたが、家庭以外の場所、例えばオフィスや学校などに設置されていても、本発明は有効である。
なお、デバイスエージェント２０の動作において、単一のメディアについてコンテンツ視聴履歴を管理する場合には、メディア種別識別子の付与は省いてもかまわない。
＜サービスコンシェルジェ＞
（その１：マーケティング調査）
図１７はマーケティング調査を行うサービスコンシェルジェ４０の構成を示すブロック図である。図１７において、４１は番組名やアーティスト名などのメタ情報レベルの語彙を含む調査条件を受け付ける条件入力部、４２はメディア種別毎にコンテンツの属性データなどのメタ情報をコンテンツ識別子と対応づけて格納したメタ情報データベース、４３はメタ情報データベース４２を参照して、条件入力部４１から入力された問合せに含まれるメタ情報レベルの語彙をコンテンツ識別子や視聴時間などに置換して、ユーザエージェント３０に対する問合せメッセージを生成する問合せ作成部、４４は当該サービスコンシェルジェが提供するサービスを契約しているユーザのプロファイル（属性情報）、ユーザエージェント３０のロケーション情報（ネットワークアドレス）、およびサービスを受信する端末家電機器のロケーション情報を格納したユーザデータベース、４５は問合せ作成部４３によって作成された問合せメッセージを契約ユーザのユーザエージェント３０に送信する問合せ送信部、４６はユーザエージェント３０からの応答メッセージを受信する応答受信部、４７は応答受信部４６によって受信した応答メッセージを集計する応答集計部、４８は応答集計部４７の集計結果を出力する集計結果出力部である。
図１８のフローチャートを用いて、図１７のサービスコンシェルジェ４０の動作を説明する。ここでは、マーケティング調査として、２００２年の８月５日から８月１１日までの１週間に放送された地上波放送のドラマを対象とした人気ランキングを得るものとする。
（ステップｃ１）
条件入力部４１が、図１９に示すようなＧＵＩを画面に表示して、調査条件を受け付ける。ここでは、調査期間として「２００２年８月５日から２００２年８月１１日まで」の１週間が指定され、調査対象として「地上波放送」が、ジャンルとして「ドラマ」が選択される。また、出力結果フォーマットとして「ランキング」を指定する（図示せず）。
（ステップｃ２）
ステップｃ１で入力された「２００２年８月５日から２００２年８月１１日まで」に放送された「地上波放送」の「ドラマ」という条件で、メタ情報データベース４２を検索し、条件に合致する番組のコンテンツ識別子をリストとして抽出する。
（ステップｃ３）
問合せ作成部４３は、ステップｃ２で抽出されたリストのコンテンツが視聴されたか否かをユーザエージェント３０に問い合わせるメッセージを作成する。
（ステップｃ４）
問合せ送信部４５は、ユーザデータベース４４に登録されているユーザエージェント３０のロケーション情報（宛先となるネットワークアドレス）のリストを抽出する。
（ステップｃ５）
問合せ送信部４５は、ステップｃ３で作成した問合せメッセージを、ステップｃ４で抽出したリストを参照して各ユーザエージェント３０に送信する。なお、特定のプロファイルのユーザを対象とした調査を行いたい場合は、条件入力部４１に調査対象となるユーザのプロファイル条件、例えば、性別、年代（年齢）、家族構成などを指定すればよい。ユーザのプロファイル条件が指定されると、問合せ送信部４５はユーザデータベース４４からプロファイル条件に合致するユーザのユーザエージェントのロケーション情報のみを抽出して、問合せメッセージを送信する。これにより、調査対象となるユーザのデータのみを収集することができる。
（ステップｃ６）
応答受信部４６が、問合せメッセージを送信した全てのユーザエージェント３０からの応答メッセージが受信されたか否かを調べる。全ての応答メッセージが受信されたときはステップｃ７にすすむ。一方、そうでないときは、所定の間隔をおいて再度ステップｃ６を実行する。
図２０において、（ａ）は送信する問合せメッセージの例、（ｂ）は応答メッセージの例である。図２０（ａ）の問い合わせメッセージでは、ユーザエージェント３０側でのマッチングコストを低減するため、冗長ではあるが、視聴期間を指定している。＜ｃｈｅｃｋＣｏｎｔｅｎｔｌｄ＞というメッセージは、＜ｐｅｒｉｏｄ＞で指定された期間に＜ｃｏｎｔｅｎｔｌｄＬｉｓｔ＞で指定されたコンテンツを視聴しているか否かをチェックし、視聴したコンテンツのリストを＜ｃｏｎｔｅｎｔｌｄＬｉｓｔ＞として返す。すなわち、問合せメッセージの＜ｃｏｎｔｅｎｔｌｄＬｉｓｔ＞から、視聴していないコンテンツの項目（メディア種別識別子およびコンテンツ識別子）を削除したものが、図２０（ｂ）の応答メッセージになる。
（ステップｃ７）
応答集計部４７が、受信したすべての応答メッセージを順番に解釈し、結果の集計を行う。ここでは、条件入力部４１で「ランキング」が指定されているため、コンテンツ識別子毎に、応答メッセージの＜ｃｏｎｔｅｎｔｌｄＬｉｓｔ＞に含まれている個数をカウントする。
（ステップｃ８）
ステップｃ７で集計された結果に基づき、例えば、応答メッセージに含まれた個数が多い順、すなわち視聴率の高い順にコンテンツを並べたリストを、アプリケーションサーバ１３のコンソール画面に出力する。集計結果の表示例を図２１に示す。なお、集計結果の出力先として、ファイル出力、印刷など他のメディアを指定できるようにしてもよい。
以上のように、オペレータが調査条件をアプリケーションサーバ１３のコンソールから入力するだけで、複数のユーザエージェント３０に視聴履歴を問い合わせて、調査結果を得ることができる。どのメタ情報データベース４２を用いるかは、サービスコンシェルジェ４０側で自由に選択すれば良く、また、ユーザエージェント３０とサービスコンシェルジェ４０との間で同じコンテンツ識別子を利用するだけで相互運用性が確保できる。
（その２：コンテンツ推薦）
図２２はコンテンツ推薦を行うサービスコンシェルジェ５０の構成を示すブロック図である。図２２では、図１７と共通の構成要素については図１７と同一符号を付しており、ここでは詳細な説明を省略する。図２２において、５１は応答受信部４６によって受信した応答メッセージをメタ情報データベース４２を参照して解析し、ユーザがどのようなジャンルのコンテンツに興味があるかを算出するユーザ嗜好計算部、５２はユーザ嗜好計算部５１の結果に基づいて推薦すべきコンテンツの抽出を行うおすすめ情報作成部、５３はおすすめ情報作成部５２によって作成したおすすめ情報を携帯電話等のメールアドレスに送信するメール送信部、５４はカウンタをリセットされてからの経過時間を計測するタイマー部、５５はユーザエージェント３０に対する問合せメッセージを生成する問合せ作成部である。メタ情報データベース４２は、メディア種別毎のコンテンツの属性情報を格納しており、メディア種別識別子とコンテンツ識別子を指定することで、対応する属性情報が取り出せるものとする。
図２３のフローチャートを用いて、図２２のサービスコンシェルジェ５０の動作を説明する。ここでは、１週間ごとにユーザエージェント３０が記憶するコンテンツ視聴履歴を取得してユーザの嗜好傾向を推定し、おすすめコンテンツを携帯電話のメールに送信するものとする。
（ステップｄ１）
問合せ作成部５５は、前回の起動から１週間が経過しているか否かをタイマー部５４を参照して調べ、１週間が経過しているときはステップｄ２に進む。そうでないときは、所定の時間待機してから再度ステップｄ１を実行する。ここでは、毎週月曜日の午前０：００に問合せ作成部５５が起動されるものとする。なお、問合せ作成部５５がタイマー部５４をポーリングする代わりに、タイマー部５４が定期的に発生するイベントによって問合せ作成部５５を駆動するようにしてもよい。
（ステップｄ２）
問合せ作成部５５は、前の月曜日から日曜日までの視聴履歴データを取り出すための問合せメッセージを作成する。
（ステップｄ３）
問合せ送信部４５は、ユーザデータベース４４から、おすすめコンテンツ情報配信のサービスを契約しているユーザのユーザエージェント３０のロケーション情報を１つ取り出し、ステップｄ２において作成された問合せメッセージを送信する。このとき、メール送信部５３は、このユーザの携帯電話のメールアドレスをユーザデータベース４４から取り出して記憶しておく。
（ステップｄ４）
応答受信部４６は、問合せメッセージを送信したユーザエージェント３０からの応答メッセージが受信されたか否かを調べる。応答メッセージが受信されたときはステップｄ５にすすむ一方、そうでないときは、所定の間隔をおいて、再度ステップｄ４を実行する。図２４は問合せメッセージと応答メッセージの一例である。図２４（ａ）の問合せメッセージは、２００２年８月１２日の午前０：００に作成されたものである。
（ステップｄ５）
ユーザ嗜好計算部５１が、ステップｄ４において受信した応答メッセージに含まれたコンテンツ識別子を用いてユーザの嗜好を計算する。具体的には、視聴されたコンテンツの属性情報をメタ情報データベース４２を参照して調べ、属性ごとの各属性値の出現頻度を計算することによって、ユーザが興味を持つコンテンツの属性条件を抽出する。これにより、「ジャンル」「アーティスト」「キーワード」などの観点から見たユーザの嗜好傾向を得ることができる。その他に、「前週におすすめしたコンテンツの中で実際に視聴されたものはあるか？」などを考慮することができる。サービスプロバイダ側でメタ情報データベース４２のメディア種別間の語彙の定義などについて整合をとることが可能なため、あるメディア種別の視聴履歴を、他のメディア種別のコンテンツ推薦に生かすことができる。
（ステップｄ６）
おすすめ情報作成部５２が、今週すなわち２００２年の８月１２日〜１８日の期間に視聴可能なコンテンツの中で、ステップｄ５において抽出された属性条件に合致するものを、メタ情報データベース４２を検索して抽出する。
（ステップｄ７）
おすすめ情報作成部５２が、ステップｄ６において抽出したコンテンツを推薦するためのメールメッセージを作成する。図２５はメッセージの一例である。なお、コンテンツの詳細情報を簡単に参照できるように、コンテンツのタイトル部分をアンカーにして、メタ情報データベース４２の情報とリンクさせておいてもよい。
（ステップｄ８）
メール送信部５３は、ステップｄ３で記憶しておいた携帯電話のメールアドレスに、ステップｄ７で作成したメッセージを送信する。
（ステップｄ９）
全ての登録ユーザに対して処理が終了したかを調べ、終了していないときはステップｄ３にもどり、処理を継続する。終了したときは、タイマー部５４のカウンタをリセットし、動作を終了する。
以上のように、サービスコンシェルジェ側のプログラムを変更するだけで、コンテンツ推薦などさまざまなサービスを提供することができる。例えば、サービスを契約しているユーザに限定して、サービスコンシェルジェ５０からデバイスエージェント２０へのアクセスを許可すれば、サービスコンシェルジェ５０からデバイスエージェント２０に制御メッセージを送信することによっておすすめＴＶ番組の録画予約を自動化することも可能である。
（その３：コンテンツ自動管理）
図２９はコンテンツ自動管理のためのスクリプトを提供するサービスコンシェルジェ５０Ａの構成を示すブロック図である。図２９では、図２２と共通の構成要素については図２２と同一符号を付しており、ここでは詳細な説明を省略する。図２９において、６１は応答受信部４６によって受信した応答メッセージに含まれるコンテンツ視聴履歴（例えば１ヶ月分）から、同一の識別子を持つコンテンツに対してＨＤＤレコーダやＤＶＤレコーダなど複数の機器において行われた一連の操作パターンを抽出するコンテンツ操作パターン抽出部、６２はコンテンツ操作パターン抽出部６１によって抽出された操作パターンのうち、共通する属性を持つコンテンツに対して繰り返し適用された操作パターンを特定し、この特定した操作パターンを同じ属性を持つ他のコンテンツに対して自動適用するスクリプト、すなわち操作パターン再現スクリプトを生成する操作パターン再現スクリプト生成部、６３は操作パターン再現スクリプト生成部６２によって生成された操作パターン再現スクリプトをユーザエージェント３０に送信する操作パターン再現スクリプト送信部である。
ユーザエージェント３０は送信された操作パターン再現スクリプトを解釈し、このスクリプトに含まれた機器制御コマンドを、それに対応するデバイスエージェント２０に送信する。これにより、コンテンツに対する一連の操作パターンが再現される。
図３０は本例におけるデバイスエージェント２０Ａの構成を示すブロック図である。図３０では、図３と共通の構成要素については図３と同一符号を付しており、ここでは詳細な説明を省略する。図３０において、７１はユーザエージェント３０から送信される機器制御コマンドを受信する機器制御コマンド受信部、７２は操作解釈テーブル２２ａを用いて、機器制御コマンド受信部７１によって受信した機器制御コマンドを解釈して、機器制御部２３により当該機器を制御する機器制御コマンド実行部である。
図３１のフローチャートを用いて、図２９のサービスコンシェルジェ５０Ａの動作を説明する。ここでは、ユーザエージェント３０が記憶するコンテンツ視聴履歴を１ヶ月ごとに取得して、ユーザが特定の属性を有するコンテンツに対して繰り返し行う操作パターンを抽出し、コンテンツを自動管理するためのスクリプトを生成してユーザエージェント３０に送信するものとする。
（ステップｆ１）
問合せ作成部５５は、前回の起動から１ヶ月が経過しているか否かについて、タイマー部５４を参照して調べ、１ヶ月が経過しているときはステップｆ２に進む。そうでないときは、所定の時間待機してから再度ステップｆ１を実行する。ここでは、毎月１日の午前０：００に問合せ作成部５５が起動されるものとする。なお、問合せ作成部５５がタイマー部５４をポーリングする代わりに、タイマー部５４が定期的に発生するイベントによって問合せ作成部５５を駆動するようにしてもよい。
（ステップｆ２）
問合せ作成部５５は、前月の視聴履歴データを取り出すための問合せメッセージを作成する。
（ステップｆ３）
問合せ送信部４５は、ユーザデータベース４４から、コンテンツ自動管理スクリプト配信のサービスを契約しているユーザのユーザエージェント３０のロケーション情報を１つ取り出し、ステップｆ２において作成された問合せメッセージを送信する。このとき、操作パターン再現スクリプト送信部６３は、問い合わせメッセージを送信したユーザエージェント３０のロケーション情報を記憶しておく。
（ステップｆ４）
応答受信部４６は、問合せメッセージを送信したユーザエージェント３０からの応答メッセージが受信されたか否かを調べる。応答メッセージが受信されたときはステップｆ５にすすむ一方、そうでないときは、所定の間隔をおいて、再度ステップｆ４を実行する。
（ステップｆ５）
コンテンツ操作パターン抽出部６１が、ステップｆ４において受信した応答メッセージに含まれる１ヶ月分のコンテンツ視聴履歴から、同一の識別子を持つコンテンツに対してＨＤＤレコーダやＤＶＤレコーダなど複数の機器にまたがって行われた一連の操作パターンを操作パターン候補群として抽出する。例えば、図３２に示す視聴履歴から、コンテンツ「ｘｘｘｘｘｘｘｘｘｘ１１」に対して行われた、ＨＤＤレコーダに一旦記録してからＤＶＤに移動する一連の操作を抽出する。
（ステップｆ６）
ステップｆ５で抽出された操作パターン候補群から操作パターンを１つ取り出す。
（ステップｆ７）
取り出した操作パターンと類似した操作パターンが操作パターン候補群に含まれるかどうか調べる。同一の操作パターンが見つかった場合はステップｆ８に進む。そうでない場合はステップｆ１０に進む。
（ステップｆ８）
操作パターン候補群から異なるコンテンツＩＤに対する類似した操作パターンをすべて取り出す。例えば、図３２に示す視聴履歴では、コンテンツ「ｘｘｘｘｘｘｘｘｘｘ２２」とコンテンツ「ｘｘｘｘｘｘｘｘｘｘ２３」に対する操作が、ある機器に録画してからポータブルＳＤビデオプレーヤに移動する点で類似していると見なすことができる。
（ステップｆ９）
ステップｆ８で取り出した類似した操作パターンのコンテンツに共通の属性を見つけ出して、操作パターン再現スクリプトを生成する。図３３に示すようなデータがメタ情報データベース４２に格納されているものとすると、上述の場合、コンテンツ「ｘｘｘｘｘｘｘｘｘｘ２２」とコンテンツ「ｘｘｘｘｘｘｘｘｘｘ２３」に共通する属性として、『ニュース』が特定できる。そこで、操作パターン再現スクリプトとして、「ＨＤＤかＤＶＤに蓄積されたコンテンツが『ニュース』であるか否か調べ、『ニュース』の場合は、朝までにポータブルＳＤプレーヤに移動する」が生成される。
（ステップｆ１０）
ステップｆ５で抽出された操作パターン候補群の操作パターンをすべて調べた場合には、ステップｆ１１に進む。そうでない場合にはステップｆ６に戻り、処理を繰り返す。
（ステップｆ１１）
操作パターン再現スクリプト送信部６３は、ステップｆ３で記憶しておいたユーザエージェント３０のロケーション情報に、ステップｆ９で生成した操作パターン再現スクリプトを送信する。
（ステップｆ１２）
全ての登録ユーザに対して処理が終了したかを調べ、終了していないときはステップｆ３にもどり、処理を継続する。終了したときは、タイマー部５４のカウンタをリセットし、動作を終了する。
以上のように、ユーザが特定の種類のコンテンツに対して繰り返し行う操作パターンを見つけ出して自動化することにより、コンテンツを管理するための手間を大幅に削減することができる。本例では、未視聴の録画ニュースをポータブルＳＤビデオプレーヤに自動的に移動する例について説明したが、録画したコンテンツをライブラリ化することの多いユーザには、操作パターン再現スクリプトを応用して、図３４の画面例のように、ユーザが選択可能な機能を後から追加提供することも可能である。
なお、サービスコンシェルジェはホームサーバ装置に組み込まれていても良い。ホームサーバ装置に組み込まれたサービスコンシェルジェの場合、インターネットまたは放送波から得られるＥＰＧデータベースを参照して、上述した処理を行うことができる。
また、サービスコンシェルジェ側では、多数のユーザに共通して利用される操作パターン再現スクリプトを抽出することができる。例えば、このように抽出したスクリプトを、新規に機器を購入したユーザに提供するサービスを行うことによって、当該ユーザは、機器を使いこなしているユーザと同等の利用価値を最小限の手間で享受することが可能になる。
＜番組視聴の判断方法＞
ストリーム系のコンテンツ（番組）については、視聴開始・終了時刻が番組開始・終了時刻とぴったり合うことはまれであり、ほとんどの場合には時間的なずれが存在する。例えば図２６に示すように、番組が視聴時間に含まれる場合（ａ）や、番組が視聴時間と一部重なる場合（ｂ）、あるいは、視聴時間が番組に含まれる場合（ｃ）などがある。
そこで、ユーザがコンテンツを実際に視聴したか否かの判断を、例えば次のように行う。すなわち、番組の放送時間をＤとし、視聴時間をＴとしたとき、
Ｔ／Ｄ ＞ Ｃ
すなわち放送時間Ｄに対する視聴時間Ｔの割合が、所定値Ｃを超えているとき、そのコンテンツは視聴されたと判断する。所定値Ｃは、例えば０．８（８０％）を設定する。
図２７は本例に係る番組視聴判断方法を示すフローチャートである。まず番組時間Ｄを算出する（ｅ１）。そして、視聴開始が番組開始よりも前であり（ｅ２でｙｅｓ）、視聴終了が番組終了よりも後である（ｅ３でｎｏ）ときは、番組を視聴したと判断する（ｅ４）。また、視聴開始が番組開始よりも前である（ｅ２でｙｅｓ）が、視聴終了が番組終了よりも前である（ｅ３でｙｅｓ）ときは、番組開始から視聴終了までの時間を視聴時間Ｔとして算出し（ｅ５）、時間Ｄに対する時間Ｔの割合が所定値（ここでは０．８）を超えているときは（ｅ６でｙｅｓ）、番組を視聴したと判断する（ｅ４）一方、越えていないときは（ｅ６でｎｏ）、番組を視聴していないと判断する（ｅ１１）。
また、視聴開始が、番組開始よりも後である（ｅ２でｎｏ）が、番組開始と終了の間である場合は（ｅ７でｙｅｓ）、視聴終了が番組終了よりも前である（ｅ８でｙｅｓ）ときは、視聴開始から視聴終了までの時間を視聴時間Ｔとして算出する（ｅ９）一方、視聴終了が番組終了よりも後である（ｅ８でｎｏ）ときは、視聴開始から番組終了までの時間を視聴時間Ｔとして算出する（ｅ１０）。そして、時間Ｄに対する時間Ｔの割合が所定値を超えているときは（ｅ６でｙｅｓ）、番組を視聴したと判断する（ｅ４）一方、越えていないときは（ｅ６でｎｏ）、番組を視聴していないと判断する（ｅ１１）。また、視聴開始が番組終了よりも後である（ｅ７でｎｏ）ときは、番組を視聴していないと判断する（ｅ１１）。
また、ストリーム系のコンテンツの場合には、例えば野球中継の放送延長や、特別報道番組などによって、番組の放送時間が変更されることがよくある。この場合には、放送後の番組表を利用することによって、実際の放送に即してコンテンツ視聴履歴データを解釈することができる。例えば図２８に示すように、放送予定では１９時から２１時までが「プロ野球」であり、２１時から２２時までが「ドラマ」であるとき（ａ）、視聴履歴データにおいて、視聴開始時刻が１９時、視聴終了時刻が２２時であると（ｂ）、コンテンツとして「プロ野球」および「ドラマ」が視聴されたと判断される。ところが、実際はプロ野球中継が２２時まで延長されていたとすると（ｃ）、ユーザは「プロ野球」を見ただけであって「ドラマ」は見ておらず、したがって、正確な視聴履歴が得られないことになる。この問題を回避するためには、サービスコンシェルジェにおいて、放送後の番組表を利用して、視聴履歴データを適宜変更するようにすればよい。
以上のように本発明によると、履歴の記録、履歴の収集管理、履歴の分析の役割をそれぞれデバイスエージェント、ユーザエージェント、サービスコンシェルジェの独立したモジュールとして構成することにより、１個の装置に複数の役割を持たせたり、電化機器に組み込むサービスとインターネットを介して接続されるサービスとで視聴履歴を共有するなど、柔軟な運用ができる。
また、サービス提供側から視聴履歴へのアクセスを、サービスコンシェルジェからユーザエージェントへの問合せ形式で提供することにより、回線容量やプライバシーポリシーに応じて視聴履歴へのアクセスを制御することができる。
また、ユーザが有する電化機器におけるコンテンツ視聴履歴が、メディア識別子とコンテンツ識別子を用いて蓄積されるので、サービス側と視聴履歴蓄積側の相互運用性を高めることができる。また、視聴履歴データベースに語彙の共通化が困難なメタ情報レベルの語彙が含まれないため、さまざまなベンダーが自由にサービスコンシェルジェを設計したり、詳細度の高い独自のメタ情報を利用するなどして、コンテンツ視聴履歴を活用したサービスを提供することができる。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【技術分野】
本発明は、相互に接続された電化機器におけるコンテンツ視聴の履歴を、ユーザ単位、あるいは家族単位で、一元的に管理し利用するための技術に属する。
【背景技術】
従来から、ユーザのコンテンツ視聴履歴をマーケティングや情報推薦に利用する方法が提案されている。例えば、ＰＨＳ機能の付与されたリモコンでユーザのチャンネル操作の履歴を記録し、ＰＨＳ網を介して操作履歴をサーバにアップロードして視聴率調査に利用する方法（特許文献１、特に図１を参照）や、ＴＶやインターネットなど複数の情報源の視聴履歴を一括管理して、ユーザの好みに合致したコンテンツを推薦する装置（特許文献２、特に図２を参照）などがある。また、複数の電化製品をコントロールするリモートコントローラによって、ユーザの各電化製品の利用履歴をサーバーに通信ネットワークを通じて送信するシステムも、提案されている（特許文献３）。
（特許文献１） 特開２００２−７７４３６号公報
（特許文献２） 特開平１１−７４５３号公報
（特許文献３） 特開２００２−２０３１６８号公報
解決課題
ところが、従来の技術の多くは、ＴＶ番組の視聴履歴をセンターで収集するなど単一のメディアに対するもの、あるいは、インターネットの閲覧履歴を利用してＴＶ番組を推薦するテレビのように複数のメディアを扱う単一の機器に対するものであった。
今後は、機器のネットワーク化がますます進展することが予想され、ユーザが所有する複数の機器におけるコンテンツ視聴履歴を統合して、ネットワークを介したユーザの嗜好の分析などのマーケティング調査やコンテンツ推薦のサービスに利用できるようにする必要がある。
ところで、コンテンツ視聴履歴からユーザの好みを推測する一般的な方法では、電子プログラムガイド（ＥＰＧ：Ｅｌｅｃｔｒｉｃ Ｐｒｏｇｒａｍ Ｇｕｉｄｅ）に代表されるコンテンツの属性情報（メタ情報）を利用して、「どのジャンル」または「どんなキーワードを含む」コンテンツをよく見ているかというメタ情報レベルの統計データに変換することによって、ユーザの好みの判断が行われている。
しかしながら、ＥＰＧなどのメタ情報においてジャンルやキーワードとして用いられる語彙の集合や情報の詳細度は、メタ情報を提供するプロバイダごとに異なっている。このため、端末側でメタ情報を利用してコンテンツ視聴履歴をメタ情報レベルの統計データに変換してしまうと、複数の機器のコンテンツ視聴履歴を統合して利用しようとする際に、他の機器において他のメタ情報を利用して得られたメタ情報レベルの統計データと整合性がとれないという問題が起こる。
また、複数の機器のコンテンツ利用履歴を利用する方法としては、必要なときにネットワークを介してそれぞれの機器にコンテンツ利用履歴を問い合わせる方法も考えられるが、すべての機器が常時通電されていてネットワークからのアクセスに応答できる、と仮定することは、現実的ではない。
また、従来は、例えば特許文献３のように、装置毎に役割（履歴の記録、履歴の収集管理、履歴の分析）が固定化されており、１個の装置に複数の役割を持たせることができなかったり、電化機器に組み込まれたサービスとインターネットを介して提供されるサービスとで視聴履歴を利用する仕組みを共通化できない、など柔軟性にかけていた。
さらに、従来は、視聴履歴を蓄積したデータ形式そのままで提供するものがほとんどであり、視聴履歴への効率的なアクセスが、必ずしも実現されていなかった。
前記の問題に鑑み、本発明は、ユーザが有する機器におけるコンテンツ視聴履歴を統合的に管理し、コンテンツ視聴履歴を利用したサービスを、柔軟に、かつ、効率的に、提供可能にすることを課題とする。
【発明の開示】
具体的には、本発明は、コンテンツ視聴に利用される電化機器においてコンテンツ視聴履歴データを記録する方法として、当該電化機器に対するユーザの操作を解釈してコンテンツ視聴操作を抽出し、抽出されたコンテンツ視聴操作に係るコンテンツについてコンテンツ識別子を求め、前記コンテンツについて、抽出されたコンテンツ視聴操作から視聴日時を特定し、特定した視聴日時と前記コンテンツ識別子とを組にして視聴履歴記憶部に視聴履歴データとして記録するものである。
また、本発明は、複数の機器におけるコンテンツの視聴履歴を利用する方法として、コンテンツが前記複数の機器にわたって共通の識別子によって特定されているコンテンツ視聴履歴データから、同一の識別子を持つコンテンツに対し、前記複数の機器において行われた一連の操作パターンを抽出し、抽出した操作パターンの中から、共通の属性を有するコンテンツに対して共通に行われた操作パターンを特定し、特定した操作パターンを、当該属性を有する他のコンテンツに適用するための、操作パターン再現スクリプトを生成するものである。
また、他の態様では、ネットワークシステムとして、コンテンツ視聴に利用され、デバイスエージェントを有する少なくとも１つの電化機器と、前記電化機器とネットワークを介して接続され、ユーザエージェントを有するサーバ装置とを備え、前記デバイスエージェントは、コンテンツの視聴履歴データを格納するための視聴履歴記憶部を備え、かつ、各コンテンツについて、視聴日時を特定し、この特定した視聴日時と、当該コンテンツに係るメディアの種別を特定するメディア種別識別子、および特定されたメディアにおいて当該コンテンツを一意に特定するコンテンツ識別子とを組にして、視聴履歴データとして、前記視聴履歴記憶部に記録するものであり、前記ユーザエージェントは、コンテンツの視聴履歴データを格納するための視聴履歴データベースを備え、かつ、前記電化機器のデバイスエージェントから視聴履歴データを受信して、前記視聴履歴データベースに登録するものである。
この態様によると、電化機器では、デバイスエージェントが、各コンテンツについて、視聴日時と、メディア種別識別子およびコンテンツ識別子とを組にして、視聴履歴データとして記録する。メディア種別識別子は、当該コンテンツに係るメディアの種別を特定し、コンテンツ識別子は、特定されたメディアにおいて当該コンテンツを一意に特定する。そして、サーバ装置では、ユーザエージェントが、電化機器のデバイスエージェントから視聴履歴データを受信して、視聴履歴データベースに登録する。これにより、サーバ装置の視聴履歴データベースには、少なくとも１つの電化機器によって視聴された各コンテンツについて、視聴日時と、メディア種別識別子およびコンテンツ識別子とが、格納される。すなわち、コンテンツ視聴履歴がメディア識別子とコンテンツ識別子を用いて蓄積されるので、サービス側と視聴履歴蓄積側の相互運用性を高めることができる。
また、他の態様では、コンテンツ視聴に利用される少なくとも１つの電化機器と、前記電化機器とネットワークを介して接続されたサーバ装置とを備えたシステムにおいて、コンテンツ視聴履歴を管理する方法として、前記電化機器が、各コンテンツについて視聴日時を特定し、特定した視聴日時と、当該コンテンツに係るメディアの種別を特定するメディア種別識別子、および特定されたメディアにおいて当該コンテンツを一意に特定するコンテンツ識別子とを組にして、視聴履歴データとして視聴履歴記憶部に記録し、前記サーバ装置が、前記電化機器から視聴履歴データを受信し、受信した視聴履歴データを視聴履歴データベースに登録するものである。
この態様によると、電化機器が、各コンテンツについて、視聴日時と、メディア種別識別子およびコンテンツ識別子とを組にして、視聴履歴データとして記録する。メディア種別識別子は、当該コンテンツに係るメディアの種別を特定し、コンテンツ識別子は、特定されたメディアにおいて当該コンテンツを一意に特定する。そして、サーバ装置が、電化機器から視聴履歴データを受信して、視聴履歴データベースに登録する。これにより、サーバ装置の視聴履歴データベースには、少なくとも１つの電化機器によって視聴された各コンテンツについて、視聴日時と、メディア種別識別子およびコンテンツ識別子とが、格納される。すなわち、コンテンツ視聴履歴がメディア識別子とコンテンツ識別子を用いて蓄積されるので、サービス側と視聴履歴蓄積側の相互運用性を高めることができる。
そして、前記視聴履歴管理方法は、前記システムの外部にあるアプリケーションサーバが、前記サーバ装置にアクセスして、前記視聴履歴データベースから視聴履歴データを取得し、コンテンツ視聴に関する分析を行うのが好ましい。
また、他の態様では、コンテンツ視聴に利用される電化機器に設けられるデバイスエージェントとして、コンテンツの視聴履歴データを格納するための視聴履歴記憶部と、当該電化機器に対するユーザの操作を解釈してコンテンツ視聴操作を抽出する操作入力解釈部と、抽出されたコンテンツ視聴操作に係るコンテンツについてコンテンツ識別子を求めるコンテンツＩＤ生成部と、前記コンテンツについて、抽出されたコンテンツ視聴操作から視聴日時を特定し、特定した視聴日時と前記コンテンツ識別子とを組にして、前記視聴履歴記憶部に視聴履歴データとして記録する視聴履歴記録部とを備えたものである。
そして、前記デバイスエージェントにおけるコンテンツＩＤ生成部は、前記コンテンツ識別子を、当該コンテンツが格納されたメディア媒体から抽出する、または、当該コンテンツに係るメディアに関する属性情報から所定の方法によって生成するのが好ましい。
また、前記デバイスエージェントは、前記視聴履歴記憶部に格納された視聴履歴データを、所定のタイミングで、当該視聴履歴データが所定量になったとき、または、当該電化機器の外部から送信要求があったとき、当該電化機器の外部に送信する視聴履歴送信部を備えているのが好ましい。
また、他の態様では、ユーザが所有する、またはユーザが利用する権利を持つ少なくとも１つの電化機器とネットワークを介して接続されるサーバ装置に設けられるユーザエージェントとして、少なくとも１つのメディア種別におけるコンテンツの視聴履歴データをコンテンツのメディア種別を特定可能な形式で格納するための視聴履歴データベースと、前記電化機器から送信された視聴履歴データを受信する視聴履歴受信部と、受信した視聴履歴データを前記視聴履歴データベースに登録する視聴履歴登録部とを備えたものである。
そして、前記ユーザエージェントは、視聴履歴データに関する問合せを受信する問合せ受信部と、受信した問合せに応じて、視聴履歴の開示制限を加味しつつ、前記視聴履歴データベースを検索し、当該問合せに対する応答を作成する応答作成部と、作成した応答を当該問合せを送信した主体に返信する応答送信部とを備えているのが好ましい。
【図面の簡単な説明】
図１は本発明の一実施形態におけるシステムの全体構成を示す図である。
図２は図１の各構成要素に搭載される主要なモジュールを示す概念図である。
図３は本発明の一実施形態におけるデバイスエージェントの構成を示すブロック図である。
図４は図３のデバイスエージェントがコンテンツ視聴履歴を記録する動作を示すフローチャートである。
図５は図３のデバイスエージェントにおける操作解釈テーブルの一例である。
図６はメディア種別識別子の一例である。
図７はコンテンツ識別子の生成方法を示す図である。
図８は放送局識別子を得るためのテーブルの一例である。
図９はデバイスエージェントに蓄積された視聴履歴データの例である。
図１０は図３のデバイスエージェントが視聴履歴データを送信する動作を示すフローチャートである。
図１１はデバイスエージェントに蓄積された視聴履歴データの他の例である。
図１２は本発明の一実施形態におけるユーザエージェントの構成を示すブロック図である。
図１３は図１２のユーザエージェントが、送信された視聴履歴データを登録する動作を示すフローチャートである。
図１４はユーザエージェントに蓄積された視聴履歴データの一例である。
図１５は図１２のユーザエージェントが問合せに応答する動作を示すフローチャートである。
図１６（ａ）はユーザエージェントが受信した問合せメッセージ、図１６（ｂ）はその応答メッセージである。
図１７はマーケティング調査を行うサービスコンシェルジェの構成を示すブロック図である。
図１８は図１７のサービスコンシェルジェの動作を示すフローチャートである。
図１９は調査条件を受け付けるためのＧＵＩ画面である。
図２０は図１７のサービスコンシェルジェが送信する問合せメッセージと、その応答メッセージの例である。
図２１は集計結果の表示例である。
図２２はコンテンツ推薦を行うサービスコンシェルジェの構成を示すブロック図である。
図２３は図２２のサービスコンシェルジェの動作を示すフローチャートである。
図２４は図２２のサービスコンシェルジェが送信する問合せメッセージと、その応答メッセージの一例である。
図２５はコンテンツを推薦するメールメッセージの一例である。
図２６は番組時間と視聴時間との関係を説明するための図である。
図２７は番組視聴の判断方法を示すフローチャートである。
図２８は番組放送時間の変更への対応を説明するための図である。
図２９はコンテンツ自動管理のためのスクリプトを提供するサービスコンシェルジェの構成を示すブロック図である。
図３０は図２９のサービスコンシェルジェに対応したデバイスエージェントの構成を示すブロック図である。
図３１は図２９のサービスコンシェルジェの動作を示すフローチャートである。
図３２はコンテンツ視聴履歴データの一例である。
図３３はコンテンツのメタ情報の一例である。
図３４はユーザに追加機能を選択させる画面例である。
【発明を実施するための最良の形態】
以下、本発明の実施の形態について、図面を参照して説明する。
＜全体構成＞
図１は本発明の一実施形態におけるシステムの全体構成を示す図である。図１において、１１はデジタルＴＶやビデオなどのコンテンツ視聴に利用される電化機器としての端末家電機器、１２は常時通電されており、所定の条件に従ってＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）側からのアクセスが許されたホームサーバやホームゲートウェイなどのサーバ装置としてのサーバ家電機器、１３はサーバ家電機器１２へのアクセスを許可されたアプリケーションサーバ、１４ａ，１４ｂはイーサネット（Ｅｔｈｅｒｎｅｔ）などの有線ネットワークや８０２．１１ｂに代表される無線ネットワークから構成されるＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、１５はＷＡＮ（インターネット）、１６ａ，１６ｂはＬＡＮ１４ａ，１４ｂをＷＡＮ１５に接続するルータである。なお、ＷＡＮへのアクセスにＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ）やＦＴＴＨ（Ｆｉｂｅｒ Ｔｏ Ｔｈｅ Ｈｏｍｅ）を利用する場合など、必要に応じて、対応するモデム機能をルータ１６ａ，１６ｂに持たせてもよい。
図２は図１における端末家電機器１１、サーバ家電機器１２およびアプリケーションサーバ１３に搭載される主要なモジュールを示す概念図である。図２に示すように、端末家電機器１１には、ユーザの操作をトリガとしてコンテンツ視聴履歴を記録するデバイスエージェント２０がそれぞれ搭載されている。またサーバ家電機器１２には、デバイスエージェント２０から例えば所定のタイミングで送信されるコンテンツ視聴履歴を受け付けて一元管理するユーザエージェント３０が搭載され、アプリケーションサーバ１３には、ユーザエージェント２０が提供するコンテンツ視聴履歴を利用したサービスを提供するサービスコンシェルジェ４０，５０がそれぞれ搭載されている。
デバイスエージェント２０およびユーザエージェント３０は、ＣＰＵやメモリなどのハードウェアと、プログラムなどのソフトウェアとの組み合わせによって実現される。デバイスエージェント２０を有する端末家電機器１１と、ユーザエージェント３０を有するサーバ家電機器１２とによって、本発明に係るネットワークシステムが構成されている。
なお、例えば録画機能を有するホームサーバなど、コンテンツ視聴履歴を記録する必要があるサーバ家電装置１２については、ユーザエージェント３０に加えて、デバイスエージェント２０を搭載してもよい。また、サーバ家電装置１２となり得る家電機器が複数存在する場合は、所定の方法によって、１個の機器をサーバ家電装置１２として選択する。
また、サービスコンシェルジェは、必要に応じて端末家電機器１１に搭載してよい。これにより、他の端末家電機器１１の視聴履歴を利用した連携アプリケーションを容易に実現できる。例えば、ＭＤコンポにサービスコンシェルジェを搭載することによって、ユーザエージェントを介してデジタルＴＶの視聴履歴を取得し、ユーザが視聴した番組の主題歌を自動的にダウンロードするサービスを実現することができる。
また、携帯電話のＪａｖａアプリケーションと同様に、サービスコンシェルジェのデータ部分（メタ情報データベース）をアプリケーションサーバ１３に配置し、プログラム部分をサーバ家電装置１２にダウンロードするようにしてもよい。このように構成することによって、視聴履歴がネットワーク上を流れないようにできるため、プライバシー保護を強化することができる。
すなわち、デバイスエージェント、ユーザエージェントおよびサービスコンシェルジェは、ネットワークで接続された機器上に、自由に配置してよい。
次に、図２における各モジュールの構成と動作について説明する。
＜デバイスエージェント＞
図３はデバイスエージェント２０の構成を示すブロック図である。図３において、２１はリモコンなどを介して入力されるユーザからの操作を受け付ける操作入力部、２２は操作入力部２１からの操作入力を解釈して当該家電機器１１の動作状態を決定するとともに、コンテンツ視聴操作を抽出する操作入力解釈部、２３は操作入力解析部２２の解析結果に応じて当該家電機器１１を制御する機器制御部、２４はメディア種別毎に所定の方法を用いて、コンテンツを識別するためのコンテンツ識別子を生成するコンテンツＩＤ生成部、２５はコンテンツの視聴履歴データを格納するための視聴履歴記憶部、２６は操作入力解析部２２によって抽出されたコンテンツ視聴操作から視聴日時を特定し、特定した視聴日時とコンテンツＩＤ生成部２４によって生成されたコンテンツ識別子とを組にして視聴履歴記憶部に視聴履歴データとして記録する視聴履歴記録部、２７は視聴履歴記憶部２５に蓄積された視聴履歴データを、例えば所定のタイミングで、ネットワークＩＦ２８を介してデバイスエージェント３０宛に送信する視聴履歴送信部である。
ここでは、図３のデバイスエージェント２０は、デジタルＴＶに設けられているものとする。そして、コンテンツの視聴日時として、視聴開始日時および視聴終了日時を記録するものとする。なお、コンテンツの視聴終了日時の代わりに、コンテンツ視聴時間を記録してもよい。
図４のフローチャートを用いて、図３のデバイスエージェント２０がコンテンツ視聴履歴を記録する動作について説明する。
（ステップａ１）
ユーザからのリモコン操作を操作入力部２１によって受け付ける。ここでは、ユーザが地上波放送の８ｃｈをデジタルＴＶで見ており、リモコンのチャンネルアップボタンを２回押したものとする。リモコン以外からの入力操作についても同様に処理される。
（ステップａ２）
ステップａ１で受け付けた操作入力を、操作入力解釈部２２が操作解釈テーブル２２ａを参照して解釈し、コンテンツ視聴に関する操作すなわちコンテンツ視聴操作に該当するか否かを判断する。図５は操作解釈テーブル２２ａの一例である。受け付けた操作入力が操作解釈テーブル２２ａに定義されているとき（Ｙｅｓ）は、コンテンツ視聴操作に該当すると判断して、ステップａ３にすすむ。一方、受け付けた操作入力が操作解釈テーブル２２ａに定義されていないとき（ｎｏ）は、コンテンツ視聴操作ではないと判断して、デバイスエージェント２０は動作を終了する。
ここでは、８ｃｈの状態からチャンネルアップボタンが２回押されたため、コンテンツ視聴操作に該当しており、「チャンネルを１０ｃｈに変更する」と解釈される。なお、チャンネルアップ以外でも、リモコンのボタンでダイレクトに１０ｃｈを指定した場合やＥＰＧ番組表から現在放送中の１０ｃｈの番組を選択した場合も、同一の解釈がなされる。
（ステップａ３）
機器制御部２３によって、操作入力に対応する制御を実行する。ここでは、チャンネルを２個アップさせて１０ｃｈに変更する。なお、チャンネルアップボタン、ダイレクトボタン、ＥＰＧなど入力操作の方法に応じて、画面の切り替え動作を変更してもよい。
（ステップａ４）
操作入力が、操作解釈テーブル２２ａに記述された操作履歴記録条件を満たしているか否かを判断する。満たしているときは（ｙｅｓ）ステップａ５にすすむ一方、満たしていないときは（ｎｏ）、記録する必要がないと判断して、デバイスエージェント２０は動作を終了する。
図５では、操作履歴記録条件として「操作後一定時間チャンネルを保持」と規定されている。ここでは、チャンネルが１０ｃｈに変更された後、一定時間チャンネルが保持されたものとして、ステップａ５にすすむ。
（ステップａ５）
視聴履歴記録部２６は、視聴履歴データを視聴履歴記憶部２５に記録する。具体的にはここでは、８ｃｈの視聴が終了して１０ｃｈの視聴が開始されたと判断し、視聴開始日時記憶部（図示せず）に記憶しておいた８ｃｈの視聴開始日時を読み出すとともに、現在日時を８ｃｈの視聴終了日時として、これら視聴開始日時および視聴終了日時と、メディア種別識別子およびコンテンツＩＤ生成部２４によって生成されたコンテンツ識別子とを組にして、視聴履歴記憶部２５に記録する。このとき、現在日時を１０ｃｈの視聴開始日時として視聴開始日時記憶部に記憶しておく。
図６はメディア種別識別子の一例を示す図である。「メディア種別識別子」は、コンテンツの視聴履歴データを一元的に管理できるようにするために、当該コンテンツに係るメディアの種別を特定するものである。ここでは、地上波アナログ放送を視聴したので、メディア種別識別子として“Ｖｉｄｅｏ＿ＵＶ”が記録される。
またここでは、図７に示すようにしてコンテンツ識別子が生成される。「コンテンツ識別子」は、特定されたメディアにおいて当該コンテンツを一意に特定するものである。まず、地域を特定するコード（ここでは郵便番号）および受信チャンネルから、放送局識別子を得る。最近のＴＶ受像機やビデオなどのチューナを搭載する機器では、設置時のチャンネル設定を簡易にするために、７桁の郵便番号を入力するだけでチャンネル設定が完了できるようになっている。このような機器では、図８に示すような、７桁の郵便番号から地域を特定するためのテーブル（ａ）と、地域コードから各チャンネルに割り当てるべき放送局を決定するためのテーブル（ｂ）とが搭載されている。したがって、これらのテーブルを利用することによって、簡単に放送局識別子を得ることができる。なお、地域を特定するコードとして、固定電話の市外局番や市内局番などを組み合わせて利用してもよい。
そして、得られた放送局識別子とコンテンツの視聴日時とを用いて、所定の数式によって、コンテンツ識別子を生成する。ここでは可逆的な変換を行うものとし、所定の逆変換によって、コンテンツ識別子から放送局識別子と視聴日時を抽出できるものとする。
このようにして生成されたコンテンツ識別子は、視聴日時およびメディア種別識別子と併せて、視聴履歴記憶部２５に記録される。このような動作の結果、図９に示すような視聴履歴データが視聴履歴記憶部２５に蓄積される。
ところで、コンテンツ識別子の取得（付与）については、メディアの種別ごとに様々な方法が考えられる。代表的な方法としては、上述したような当該コンテンツに係る属性情報から所定の方法によって生成する方法や、当該コンテンツが格納されたメディア媒体から抽出する方法がある。
例えば、ＴＶのアナログ地上波放送の場合は、受信した地域、チャネル（ＶＨＦ２ｃｈなど）、受信した時間帯の３つの属性情報を組み合わせることによって、ユーザが視聴したコンテンツを特定可能であり、これをコンテンツ識別子として利用することができる。また、ＥＰＧのデータを用いて、視聴した時間帯から番組の名称等を取り出してコンテンツ識別子として利用する方法もあるが、野球の試合延長などによって放送時間枠が急遽変更されたとき、コンテンツと識別子との対応がとれないおそれがある。
デジタル放送では、番組データと同時に送信されるメタ情報から番組のコンテンツ識別子を得ることができる。また、ＣＤなどの従来メディアの場合では、収録時間やトラック数などの個々のメディアに固有の情報からＩＤを算出する方法が一般に用いられている。さらに、ＤＶＤなどの新しいメディアでは、ディスクに予め記録されたコンテンツ識別子を読み出す方法が利用可能である。
アプリケーションサーバ側でコンテンツ視聴履歴の分析を可能にするためには、複数のデバイスエージェントとサービスコンシェルジェとの間で、メディア種別毎に、共通の識別子を利用する必要がある。しかしながら、異なる識別子体系間の変換および相互運用は、変換テーブルを用いれば容易に実現できるため、さほど大きな問題にはならない。これに対して、仮にＥＰＧなどを用いてメタ情報レベルの統計データに変換している場合には、相互運用の実現のために、それぞれのメタ情報で用いられている語彙体系間のマッピングを行う変換テーブルが必要になる。語彙体系間のマッピングは、語彙空間が増大していく性質もあり、メンテナンスを含めて実現が極めて困難である。
次に図１０のフローチャートを用いて、図３のデバイスエージェント２０が視聴履歴データの送信を行う動作について説明する。この動作は、コンテンツ視聴履歴を記憶する図４の動作に対し、パラレルに行っても、またはシーケンシャルに行ってもかまわない。送信された視聴履歴データはサーバ家電機器１２のユーザエージェント３０によって受信される。
（ステップａ６）
ユーザエージェント３０への視聴履歴データのアップデートを行うタイマー割り込みが発生しているか否かを調べ、割り込みが発生しているときはステップａ９にすすむ。一方、そうでないときは、ステップａ７にすすむ。
（ステップａ７）
視聴履歴記憶部２５が視聴履歴データで一杯になっているか否かを調べ、データが一杯になっているときはステップａ９にすすむ。一方、そうでないときは、ステップａ８に進む。なお、一杯になっている否かの代わりに、視聴履歴データが所定量になったか否かによって判断してもよい。
（ステップａ８）
ユーザエージェント３０からの視聴履歴のアップデートの要求があるか否かを調べ、要求があるときはステップａ９にすすむ。一方、そうでないときは、動作を終了する。
（ステップａ９）
視聴履歴送信部２７からネットワークＩ／Ｆ２８を介して、ユーザエージェント３０に対して、視聴履歴記憶部２５に蓄積されたコンテンツ視聴履歴を送信する。すなわちここでは、タイマー割り込みによる所定のタイミングで、視聴履歴データが送信され、また、視聴履歴記憶部２５が視聴履歴データで一杯になったとき、若しくは当該電化機器の外部から送信要求があったとき、視聴履歴データが送信される。なお、ステップａ６〜ａ８の条件は必ずしも必須ではなく、省くことも可能である。
（ステップａ１０）
送信が完了したか否かを確認し、完了したときはステップａ１１にすすむ。一方、そうでないときは動作を終了する。
（ステップａ１１）
送信済みの視聴履歴データを視聴履歴記憶部２５から削除して、動作を終了する。
なお、コンテンツの視聴日時だけでなく、コンテンツに対して実行した操作の履歴も視聴履歴データとして記録するようにしてもよい。図１１はこの場合の視聴履歴記憶部２５の蓄積データの一例である。この場合には、相互運用性を確保するために、コンテンツに対して実行可能な操作（再生、録画、消去、停止コピーなど）の識別子を統一すればよい。操作履歴を記録することによって、サービスコンシェルジェ側で、どういうコンテンツ（ジャンル、アーティスト、キーワード）に対してどういう操作（蓄積、再生、削除）を行っているかを判断することができる。
例えば、
（１）ニュースはストリーム（リアルタイム放送）でしか見ない。
（２）バラエティはＨＤＤに蓄積するが、１回見たら消去する。
（３）ドラマはＨＤＤに一旦蓄積して、タイトルごとにＤＶＤに移動する
などである。これは、各コンテンツに対するユーザ毎の典型的な操作シーケンスを自動実行するサービスに応用できる。
また、デバイスエージェントが記録する操作履歴を逆向きに利用することによって、サービスコンシェルジェからデバイスの操作（コンテンツの蓄積、再生、削除）を容易に実現できる。さらに、サービスコンシェルジェからユーザエージェントにコンテンツの操作要求（操作履歴と同じフォーマット）を出すことによって、適したデバイスに対して、操作要求を実行させることができる。
＜ユーザエージェント＞
図１２はユーザエージェント３０の構成を示すブロック図である。図１２において、３１はデバイスエージェント２０から送信された視聴履歴データを受信する視聴履歴受信部、３２は視聴履歴データを格納するための視聴履歴データベース、３３は視聴履歴受信部３１によって受信した視聴履歴データを視聴履歴データベース３２に登録する視聴履歴登録部、３４はサービスコンシェルジェからの問合せ要求を受信する問合せ受信部、３５は問合せ受信部３４によって受信した問合せの内容に応じて視聴履歴データベース３２を検索し、当該問合せに対する応答を作成する応答作成部、３６は問合せを送信した主体となるサービスコンシェルジェに対して、応答作成部３５によって作成された応答を送信する応答送信部である。
まず、図１３のフローチャートを用いて、ユーザエージェント３０がデバイスエージェント２０から送信された視聴履歴データを視聴履歴データベース３２に登録する動作について説明する。
（ステップｂ１）
視聴履歴受信部３１はデバイスエージェント２０からの視聴履歴データを受信したか否かを調べ、視聴履歴データを受信したときはステップｂ２にすすむ。一方、そうでないときは、ステップｂ１の実行を所定の周期で継続する。
（ステップｂ２）
視聴履歴登録部３３は、視聴履歴受信部３１によって受信した視聴履歴データを取り出し、視聴履歴データベース３２に登録する。
（ステップｂ３）
視聴履歴データベース３２への視聴履歴データの登録が正常に完了したか否かを判断し、登録が正常に完了したときはステップｂ４にすすむ。一方、そうでないときは、動作を終了する。
（ステップｂ４）
視聴履歴データの送信元のデバイスエージェント２０に対して、登録完了通知を返信して、動作を終了する。
図１４は視聴履歴データベース３２に格納された視聴履歴データの一例である。図１４では、各デバイスエージェント２０から送信された視聴履歴データが視聴開始日時の順に格納されている。
次に、図１５のフローチャートを用いて、図１２のユーザエージェント３０がサービスコンシェルジェからの問合せに応答する動作について説明する。この動作は、図１３に示す視聴履歴データを登録する動作とパラレルに実行されるものとする。
（ステップｂ５）
問合せ受信部３４は、サービスコンシェルジェからの問合せを受信したか否かを調べ、問合せを受信したときはステップｂ６にすすみ、そうでないときはステップｂ５の実行を所定の周期で継続する。ここでの問合せには、所定の通信プロトコルおよびメッセージフォーマットが利用されるものとする。例えば、通信プロトコルとしてＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を、メッセージフォーマットとしてＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）を、それぞれ利用することができる。
（ステップｂ６）
応答作成部３５が問合せ受信部３４によって受信した問合せの解釈を行い、視聴履歴データベース３２を検索する。ここで、問合せの内容としては、
（１）指定された日時にどんなコンテンツを視聴しているか？
（２）指定された期間にどんなコンテンツを視聴しているか？
（３）指定された期間の指定された時間にどんなコンテンツを視聴しているか？
（４）指定された識別子のコンテンツを視聴したことがあるか？
（５）指定された識別子のコンテンツをいつ視聴したか？
などがあり、この問合せ内容に応じて検索を行う。
（ステップｂ７）
ステップｂ６における検索結果を、応答のフォーマットにエンコードする。例えば、ステップｂ６の（１）〜（５）の問合せの結果は、次のようになる。
（１）「メディア種別識別子＋コンテンツ識別子」
（２）「メディア種別識別子＋コンテンツ識別子」の集合
（３）「メディア種別識別子＋コンテンツ識別子」の集合
（４）「ＹＥＳ」または「ＮＯ」
（５）「日時」の集合
なお、応答メッセージのフォーマットは、問合せメッセージのフォーマットと同様、例えばＸＭＬで定義されたものを利用できる。
本実施形態のように、サービス提供側からの視聴履歴へのアクセスを、サービスコンシェルジェからユーザエージェントへの問合せという形で実現することによって、契約内容に応じた視聴履歴の開示制限が可能になる。すなわち、応答作成部３５は、視聴履歴の開示制限を加味しつつ、視聴履歴データベース３２を検索するのが好ましい。
従来は、視聴履歴を蓄積したデータ形式そのままの形で提供するものがほとんどであり、視聴履歴への効率的なアクセスを行うための問合せを準備しているシステムはなかった。視聴履歴へのアクセス方法として問合せを用いることによって、例えば、一度に読み出せるデータ量や期間を制限して全ての視聴履歴が不用意に読み出されることを防ぐことができる。あるいは、利用可能な問合せの種類をサービス毎に限定することによって、プライバシーを保護することができる。また、サービス提供者側にとっても、問合せの組み合わせのみによってユーザの視聴傾向を抽出できるため、視聴履歴を利用したサービスを構築しやすい、というメリットもある。
視聴履歴の開示制限の例としては、問合せ回数を制限したり、問合せ内容の種類を限定したりすることが考えられる。また例えば、上述の「指定された識別子のコンテンツをいつ視聴したか？」という問合せに対して、通常は視聴日時のリストを返信するところを、あるサービスについては、コンテンツの視聴回数のみを返信する、というように制限をかけることもできる。
（ステップｂ８）
応答作成部３５によって作成された応答メッセージを、応答送信部３６から、問合せメッセージの送信元のサービスコンシェルジェに対して送信し、動作を終了する。
図１６は問合せメッセージと応答メッセージの一例であり、ともにＸＭＬで記述されている。図１６（ａ）の問合せメッセージは、２００２年の８月１日から８月３１日までに視聴したコンテンツを問い合わせるものであり、図１６（ｂ）はそれに対応する応答メッセージである。
以上のような動作によって、サーバ家電機器１２の視聴履歴データベース３２には、少なくとも１つの端末家電機器１１によって視聴された各コンテンツについて、視聴日時と、メディア種別識別子およびコンテンツ識別子とが、格納される。すなわち、ユーザが有する端末家電機器１１におけるコンテンツ視聴履歴が、サーバ家電機器１２で一元管理されることになり、したがって、外部のサービスコンシェルジェ３０，４０は、サーバ家電機器１２にアクセスするだけで、ユーザが有する端末家電機器１１におけるコンテンツ視聴履歴を一括して利用することができる。
なお、本実施形態では、電化機器およびサーバ装置が家庭内に設置されているものとしたが、家庭以外の場所、例えばオフィスや学校などに設置されていても、本発明は有効である。
なお、デバイスエージェント２０の動作において、単一のメディアについてコンテンツ視聴履歴を管理する場合には、メディア種別識別子の付与は省いてもかまわない。
＜サービスコンシェルジェ＞
（その１：マーケティング調査）
図１７はマーケティング調査を行うサービスコンシェルジェ４０の構成を示すブロック図である。図１７において、４１は番組名やアーティスト名などのメタ情報レベルの語彙を含む調査条件を受け付ける条件入力部、４２はメディア種別毎にコンテンツの属性データなどのメタ情報をコンテンツ識別子と対応づけて格納したメタ情報データベース、４３はメタ情報データベース４２を参照して、条件入力部４１から入力された問合せに含まれるメタ情報レベルの語彙をコンテンツ識別子や視聴時間などに置換して、ユーザエージェント３０に対する問合せメッセージを生成する問合せ作成部、４４は当該サービスコンシェルジェが提供するサービスを契約しているユーザのプロファイル（属性情報）、ユーザエージェント３０のロケーション情報（ネットワークアドレス）、およびサービスを受信する端末家電機器のロケーション情報を格納したユーザデータベース、４５は問合せ作成部４３によって作成された問合せメッセージを契約ユーザのユーザエージェント３０に送信する問合せ送信部、４６はユーザエージェント３０からの応答メッセージを受信する応答受信部、４７は応答受信部４６によって受信した応答メッセージを集計する応答集計部、４８は応答集計部４７の集計結果を出力する集計結果出力部である。
図１８のフローチャートを用いて、図１７のサービスコンシェルジェ４０の動作を説明する。ここでは、マーケティング調査として、２００２年の８月５日から８月１１日までの１週間に放送された地上波放送のドラマを対象とした人気ランキングを得るものとする。
（ステップｃ１）
条件入力部４１が、図１９に示すようなＧＵＩを画面に表示して、調査条件を受け付ける。ここでは、調査期間として「２００２年８月５日から２００２年８月１１日まで」の１週間が指定され、調査対象として「地上波放送」が、ジャンルとして「ドラマ」が選択される。また、出力結果フォーマットとして「ランキング」を指定する（図示せず）。
（ステップｃ２）
ステップｃ１で入力された「２００２年８月５日から２００２年８月１１日まで」に放送された「地上波放送」の「ドラマ」という条件で、メタ情報データベース４２を検索し、条件に合致する番組のコンテンツ識別子をリストとして抽出する。
（ステップｃ３）
問合せ作成部４３は、ステップｃ２で抽出されたリストのコンテンツが視聴されたか否かをユーザエージェント３０に問い合わせるメッセージを作成する。
（ステップｃ４）
問合せ送信部４５は、ユーザデータベース４４に登録されているユーザエージェント３０のロケーション情報（宛先となるネットワークアドレス）のリストを抽出する。
（ステップｃ５）
問合せ送信部４５は、ステップｃ３で作成した問合せメッセージを、ステップｃ４で抽出したリストを参照して各ユーザエージェント３０に送信する。なお、特定のプロファイルのユーザを対象とした調査を行いたい場合は、条件入力部４１に調査対象となるユーザのプロファイル条件、例えば、性別、年代（年齢）、家族構成などを指定すればよい。ユーザのプロファイル条件が指定されると、問合せ送信部４５はユーザデータベース４４からプロファイル条件に合致するユーザのユーザエージェントのロケーション情報のみを抽出して、問合せメッセージを送信する。これにより、調査対象となるユーザのデータのみを収集することができる。
（ステップｃ６）
応答受信部４６が、問合せメッセージを送信した全てのユーザエージェント３０からの応答メッセージが受信されたか否かを調べる。全ての応答メッセージが受信されたときはステップｃ７にすすむ。一方、そうでないときは、所定の間隔をおいて再度ステップｃ６を実行する。
図２０において、（ａ）は送信する問合せメッセージの例、（ｂ）は応答メッセージの例である。図２０（ａ）の問い合わせメッセージでは、ユーザエージェント３０側でのマッチングコストを低減するため、冗長ではあるが、視聴期間を指定している。＜ｃｈｅｃｋＣｏｎｔｅｎｔｌｄ＞というメッセージは、＜ｐｅｒｉｏｄ＞で指定された期間に＜ｃｏｎｔｅｎｔｌｄＬｉｓｔ＞で指定されたコンテンツを視聴しているか否かをチェックし、視聴したコンテンツのリストを＜ｃｏｎｔｅｎｔｌｄＬｉｓｔ＞として返す。すなわち、問合せメッセージの＜ｃｏｎｔｅｎｔｌｄＬｉｓｔ＞から、視聴していないコンテンツの項目（メディア種別識別子およびコンテンツ識別子）を削除したものが、図２０（ｂ）の応答メッセージになる。
（ステップｃ７）
応答集計部４７が、受信したすべての応答メッセージを順番に解釈し、結果の集計を行う。ここでは、条件入力部４１で「ランキング」が指定されているため、コンテンツ識別子毎に、応答メッセージの＜ｃｏｎｔｅｎｔｌｄＬｉｓｔ＞に含まれている個数をカウントする。
（ステップｃ８）
ステップｃ７で集計された結果に基づき、例えば、応答メッセージに含まれた個数が多い順、すなわち視聴率の高い順にコンテンツを並べたリストを、アプリケーションサーバ１３のコンソール画面に出力する。集計結果の表示例を図２１に示す。なお、集計結果の出力先として、ファイル出力、印刷など他のメディアを指定できるようにしてもよい。
以上のように、オペレータが調査条件をアプリケーションサーバ１３のコンソールから入力するだけで、複数のユーザエージェント３０に視聴履歴を問い合わせて、調査結果を得ることができる。どのメタ情報データベース４２を用いるかは、サービスコンシェルジェ４０側で自由に選択すれば良く、また、ユーザエージェント３０とサービスコンシェルジェ４０との間で同じコンテンツ識別子を利用するだけで相互運用性が確保できる。
（その２：コンテンツ推薦）
図２２はコンテンツ推薦を行うサービスコンシェルジェ５０の構成を示すブロック図である。図２２では、図１７と共通の構成要素については図１７と同一符号を付しており、ここでは詳細な説明を省略する。図２２において、５１は応答受信部４６によって受信した応答メッセージをメタ情報データベース４２を参照して解析し、ユーザがどのようなジャンルのコンテンツに興味があるかを算出するユーザ嗜好計算部、５２はユーザ嗜好計算部５１の結果に基づいて推薦すべきコンテンツの抽出を行うおすすめ情報作成部、５３はおすすめ情報作成部５２によって作成したおすすめ情報を携帯電話等のメールアドレスに送信するメール送信部、５４はカウンタをリセットされてからの経過時間を計測するタイマー部、５５はユーザエージェント３０に対する問合せメッセージを生成する問合せ作成部である。メタ情報データベース４２は、メディア種別毎のコンテンツの属性情報を格納しており、メディア種別識別子とコンテンツ識別子を指定することで、対応する属性情報が取り出せるものとする。
図２３のフローチャートを用いて、図２２のサービスコンシェルジェ５０の動作を説明する。ここでは、１週間ごとにユーザエージェント３０が記憶するコンテンツ視聴履歴を取得してユーザの嗜好傾向を推定し、おすすめコンテンツを携帯電話のメールに送信するものとする。
（ステップｄ１）
問合せ作成部５５は、前回の起動から１週間が経過しているか否かをタイマー部５４を参照して調べ、１週間が経過しているときはステップｄ２に進む。そうでないときは、所定の時間待機してから再度ステップｄ１を実行する。ここでは、毎週月曜日の午前０：００に問合せ作成部５５が起動されるものとする。なお、問合せ作成部５５がタイマー部５４をポーリングする代わりに、タイマー部５４が定期的に発生するイベントによって問合せ作成部５５を駆動するようにしてもよい。
（ステップｄ２）
問合せ作成部５５は、前の月曜日から日曜日までの視聴履歴データを取り出すための問合せメッセージを作成する。
（ステップｄ３）
問合せ送信部４５は、ユーザデータベース４４から、おすすめコンテンツ情報配信のサービスを契約しているユーザのユーザエージェント３０のロケーション情報を１つ取り出し、ステップｄ２において作成された問合せメッセージを送信する。このとき、メール送信部５３は、このユーザの携帯電話のメールアドレスをユーザデータベース４４から取り出して記憶しておく。
（ステップｄ４）
応答受信部４６は、問合せメッセージを送信したユーザエージェント３０からの応答メッセージが受信されたか否かを調べる。応答メッセージが受信されたときはステップｄ５にすすむ一方、そうでないときは、所定の間隔をおいて、再度ステップｄ４を実行する。図２４は問合せメッセージと応答メッセージの一例である。図２４（ａ）の問合せメッセージは、２００２年８月１２日の午前０：００に作成されたものである。
（ステップｄ５）
ユーザ嗜好計算部５１が、ステップｄ４において受信した応答メッセージに含まれたコンテンツ識別子を用いてユーザの嗜好を計算する。具体的には、視聴されたコンテンツの属性情報をメタ情報データベース４２を参照して調べ、属性ごとの各属性値の出現頻度を計算することによって、ユーザが興味を持つコンテンツの属性条件を抽出する。これにより、「ジャンル」「アーティスト」「キーワード」などの観点から見たユーザの嗜好傾向を得ることができる。その他に、「前週におすすめしたコンテンツの中で実際に視聴されたものはあるか？」などを考慮することができる。サービスプロバイダ側でメタ情報データベース４２のメディア種別間の語彙の定義などについて整合をとることが可能なため、あるメディア種別の視聴履歴を、他のメディア種別のコンテンツ推薦に生かすことができる。
（ステップｄ６）
おすすめ情報作成部５２が、今週すなわち２００２年の８月１２日〜１８日の期間に視聴可能なコンテンツの中で、ステップｄ５において抽出された属性条件に合致するものを、メタ情報データベース４２を検索して抽出する。
（ステップｄ７）
おすすめ情報作成部５２が、ステップｄ６において抽出したコンテンツを推薦するためのメールメッセージを作成する。図２５はメッセージの一例である。なお、コンテンツの詳細情報を簡単に参照できるように、コンテンツのタイトル部分をアンカーにして、メタ情報データベース４２の情報とリンクさせておいてもよい。
（ステップｄ８）
メール送信部５３は、ステップｄ３で記憶しておいた携帯電話のメールアドレスに、ステップｄ７で作成したメッセージを送信する。
（ステップｄ９）
全ての登録ユーザに対して処理が終了したかを調べ、終了していないときはステップｄ３にもどり、処理を継続する。終了したときは、タイマー部５４のカウンタをリセットし、動作を終了する。
以上のように、サービスコンシェルジェ側のプログラムを変更するだけで、コンテンツ推薦などさまざまなサービスを提供することができる。例えば、サービスを契約しているユーザに限定して、サービスコンシェルジェ５０からデバイスエージェント２０へのアクセスを許可すれば、サービスコンシェルジェ５０からデバイスエージェント２０に制御メッセージを送信することによっておすすめＴＶ番組の録画予約を自動化することも可能である。
（その３：コンテンツ自動管理）
図２９はコンテンツ自動管理のためのスクリプトを提供するサービスコンシェルジェ５０Ａの構成を示すブロック図である。図２９では、図２２と共通の構成要素については図２２と同一符号を付しており、ここでは詳細な説明を省略する。図２９において、６１は応答受信部４６によって受信した応答メッセージに含まれるコンテンツ視聴履歴（例えば１ヶ月分）から、同一の識別子を持つコンテンツに対してＨＤＤレコーダやＤＶＤレコーダなど複数の機器において行われた一連の操作パターンを抽出するコンテンツ操作パターン抽出部、６２はコンテンツ操作パターン抽出部６１によって抽出された操作パターンのうち、共通する属性を持つコンテンツに対して繰り返し適用された操作パターンを特定し、この特定した操作パターンを同じ属性を持つ他のコンテンツに対して自動適用するスクリプト、すなわち操作パターン再現スクリプトを生成する操作パターン再現スクリプト生成部、６３は操作パターン再現スクリプト生成部６２によって生成された操作パターン再現スクリプトをユーザエージェント３０に送信する操作パターン再現スクリプト送信部である。
ユーザエージェント３０は送信された操作パターン再現スクリプトを解釈し、このスクリプトに含まれた機器制御コマンドを、それに対応するデバイスエージェント２０に送信する。これにより、コンテンツに対する一連の操作パターンが再現される。
図３０は本例におけるデバイスエージェント２０Ａの構成を示すブロック図である。図３０では、図３と共通の構成要素については図３と同一符号を付しており、ここでは詳細な説明を省略する。図３０において、７１はユーザエージェント３０から送信される機器制御コマンドを受信する機器制御コマンド受信部、７２は操作解釈テーブル２２ａを用いて、機器制御コマンド受信部７１によって受信した機器制御コマンドを解釈して、機器制御部２３により当該機器を制御する機器制御コマンド実行部である。
図３１のフローチャートを用いて、図２９のサービスコンシェルジェ５０Ａの動作を説明する。ここでは、ユーザエージェント３０が記憶するコンテンツ視聴履歴を１ヶ月ごとに取得して、ユーザが特定の属性を有するコンテンツに対して繰り返し行う操作パターンを抽出し、コンテンツを自動管理するためのスクリプトを生成してユーザエージェント３０に送信するものとする。
（ステップｆ１）
問合せ作成部５５は、前回の起動から１ヶ月が経過しているか否かについて、タイマー部５４を参照して調べ、１ヶ月が経過しているときはステップｆ２に進む。そうでないときは、所定の時間待機してから再度ステップｆ１を実行する。ここでは、毎月１日の午前０：００に問合せ作成部５５が起動されるものとする。なお、問合せ作成部５５がタイマー部５４をポーリングする代わりに、タイマー部５４が定期的に発生するイベントによって問合せ作成部５５を駆動するようにしてもよい。
（ステップｆ２）
問合せ作成部５５は、前月の視聴履歴データを取り出すための問合せメッセージを作成する。
（ステップｆ３）
問合せ送信部４５は、ユーザデータベース４４から、コンテンツ自動管理スクリプト配信のサービスを契約しているユーザのユーザエージェント３０のロケーション情報を１つ取り出し、ステップｆ２において作成された問合せメッセージを送信する。このとき、操作パターン再現スクリプト送信部６３は、問い合わせメッセージを送信したユーザエージェント３０のロケーション情報を記憶しておく。
（ステップｆ４）
応答受信部４６は、問合せメッセージを送信したユーザエージェント３０からの応答メッセージが受信されたか否かを調べる。応答メッセージが受信されたときはステップｆ５にすすむ一方、そうでないときは、所定の間隔をおいて、再度ステップｆ４を実行する。
（ステップｆ５）
コンテンツ操作パターン抽出部６１が、ステップｆ４において受信した応答メッセージに含まれる１ヶ月分のコンテンツ視聴履歴から、同一の識別子を持つコンテンツに対してＨＤＤレコーダやＤＶＤレコーダなど複数の機器にまたがって行われた一連の操作パターンを操作パターン候補群として抽出する。例えば、図３２に示す視聴履歴から、コンテンツ「ｘｘｘｘｘｘｘｘｘｘ１１」に対して行われた、ＨＤＤレコーダに一旦記録してからＤＶＤに移動する一連の操作を抽出する。
（ステップｆ６）
ステップｆ５で抽出された操作パターン候補群から操作パターンを１つ取り出す。
（ステップｆ７）
取り出した操作パターンと類似した操作パターンが操作パターン候補群に含まれるかどうか調べる。同一の操作パターンが見つかった場合はステップｆ８に進む。そうでない場合はステップｆ１０に進む。
（ステップｆ８）
操作パターン候補群から異なるコンテンツＩＤに対する類似した操作パターンをすべて取り出す。例えば、図３２に示す視聴履歴では、コンテンツ「ｘｘｘｘｘｘｘｘｘｘ２２」とコンテンツ「ｘｘｘｘｘｘｘｘｘｘ２３」に対する操作が、ある機器に録画してからポータブルＳＤビデオプレーヤに移動する点で類似していると見なすことができる。
（ステップｆ９）
ステップｆ８で取り出した類似した操作パターンのコンテンツに共通の属性を見つけ出して、操作パターン再現スクリプトを生成する。図３３に示すようなデータがメタ情報データベース４２に格納されているものとすると、上述の場合、コンテンツ「ｘｘｘｘｘｘｘｘｘｘ２２」とコンテンツ「ｘｘｘｘｘｘｘｘｘｘ２３」に共通する属性として、『ニュース』が特定できる。そこで、操作パターン再現スクリプトとして、「ＨＤＤかＤＶＤに蓄積されたコンテンツが『ニュース』であるか否か調べ、『ニュース』の場合は、朝までにポータブルＳＤプレーヤに移動する」が生成される。
（ステップｆ１０）
ステップｆ５で抽出された操作パターン候補群の操作パターンをすべて調べた場合には、ステップｆ１１に進む。そうでない場合にはステップｆ６に戻り、処理を繰り返す。
（ステップｆ１１）
操作パターン再現スクリプト送信部６３は、ステップｆ３で記憶しておいたユーザエージェント３０のロケーション情報に、ステップｆ９で生成した操作パターン再現スクリプトを送信する。
（ステップｆ１２）
全ての登録ユーザに対して処理が終了したかを調べ、終了していないときはステップｆ３にもどり、処理を継続する。終了したときは、タイマー部５４のカウンタをリセットし、動作を終了する。
以上のように、ユーザが特定の種類のコンテンツに対して繰り返し行う操作パターンを見つけ出して自動化することにより、コンテンツを管理するための手間を大幅に削減することができる。本例では、未視聴の録画ニュースをポータブルＳＤビデオプレーヤに自動的に移動する例について説明したが、録画したコンテンツをライブラリ化することの多いユーザには、操作パターン再現スクリプトを応用して、図３４の画面例のように、ユーザが選択可能な機能を後から追加提供することも可能である。
なお、サービスコンシェルジェはホームサーバ装置に組み込まれていても良い。ホームサーバ装置に組み込まれたサービスコンシェルジェの場合、インターネットまたは放送波から得られるＥＰＧデータベースを参照して、上述した処理を行うことができる。
また、サービスコンシェルジェ側では、多数のユーザに共通して利用される操作パターン再現スクリプトを抽出することができる。例えば、このように抽出したスクリプトを、新規に機器を購入したユーザに提供するサービスを行うことによって、当該ユーザは、機器を使いこなしているユーザと同等の利用価値を最小限の手間で享受することが可能になる。
＜番組視聴の判断方法＞
ストリーム系のコンテンツ（番組）については、視聴開始・終了時刻が番組開始・終了時刻とぴったり合うことはまれであり、ほとんどの場合には時間的なずれが存在する。例えば図２６に示すように、番組が視聴時間に含まれる場合（ａ）や、番組が視聴時間と一部重なる場合（ｂ）、あるいは、視聴時間が番組に含まれる場合（ｃ）などがある。
そこで、ユーザがコンテンツを実際に視聴したか否かの判断を、例えば次のように行う。すなわち、番組の放送時間をＤとし、視聴時間をＴとしたとき、
Ｔ／Ｄ ＞ Ｃ
すなわち放送時間Ｄに対する視聴時間Ｔの割合が、所定値Ｃを超えているとき、そのコンテンツは視聴されたと判断する。所定値Ｃは、例えば０．８（８０％）を設定する。
図２７は本例に係る番組視聴判断方法を示すフローチャートである。まず番組時間Ｄを算出する（ｅ１）。そして、視聴開始が番組開始よりも前であり（ｅ２でｙｅｓ）、視聴終了が番組終了よりも後である（ｅ３でｎｏ）ときは、番組を視聴したと判断する（ｅ４）。また、視聴開始が番組開始よりも前である（ｅ２でｙｅｓ）が、視聴終了が番組終了よりも前である（ｅ３でｙｅｓ）ときは、番組開始から視聴終了までの時間を視聴時間Ｔとして算出し（ｅ５）、時間Ｄに対する時間Ｔの割合が所定値（ここでは０．８）を超えているときは（ｅ６でｙｅｓ）、番組を視聴したと判断する（ｅ４）一方、越えていないときは（ｅ６でｎｏ）、番組を視聴していないと判断する（ｅ１１）。
また、視聴開始が、番組開始よりも後である（ｅ２でｎｏ）が、番組開始と終了の間である場合は（ｅ７でｙｅｓ）、視聴終了が番組終了よりも前である（ｅ８でｙｅｓ）ときは、視聴開始から視聴終了までの時間を視聴時間Ｔとして算出する（ｅ９）一方、視聴終了が番組終了よりも後である（ｅ８でｎｏ）ときは、視聴開始から番組終了までの時間を視聴時間Ｔとして算出する（ｅ１０）。そして、時間Ｄに対する時間Ｔの割合が所定値を超えているときは（ｅ６でｙｅｓ）、番組を視聴したと判断する（ｅ４）一方、越えていないときは（ｅ６でｎｏ）、番組を視聴していないと判断する（ｅ１１）。また、視聴開始が番組終了よりも後である（ｅ７でｎｏ）ときは、番組を視聴していないと判断する（ｅ１１）。
また、ストリーム系のコンテンツの場合には、例えば野球中継の放送延長や、特別報道番組などによって、番組の放送時間が変更されることがよくある。この場合には、放送後の番組表を利用することによって、実際の放送に即してコンテンツ視聴履歴データを解釈することができる。例えば図２８に示すように、放送予定では１９時から２１時までが「プロ野球」であり、２１時から２２時までが「ドラマ」であるとき（ａ）、視聴履歴データにおいて、視聴開始時刻が１９時、視聴終了時刻が２２時であると（ｂ）、コンテンツとして「プロ野球」および「ドラマ」が視聴されたと判断される。ところが、実際はプロ野球中継が２２時まで延長されていたとすると（ｃ）、ユーザは「プロ野球」を見ただけであって「ドラマ」は見ておらず、したがって、正確な視聴履歴が得られないことになる。この問題を回避するためには、サービスコンシェルジェにおいて、放送後の番組表を利用して、視聴履歴データを適宜変更するようにすればよい。
以上のように本発明によると、履歴の記録、履歴の収集管理、履歴の分析の役割をそれぞれデバイスエージェント、ユーザエージェント、サービスコンシェルジェの独立したモジュールとして構成することにより、１個の装置に複数の役割を持たせたり、電化機器に組み込むサービスとインターネットを介して接続されるサービスとで視聴履歴を共有するなど、柔軟な運用ができる。
また、サービス提供側から視聴履歴へのアクセスを、サービスコンシェルジェからユーザエージェントへの問合せ形式で提供することにより、回線容量やプライバシーポリシーに応じて視聴履歴へのアクセスを制御することができる。
また、ユーザが有する電化機器におけるコンテンツ視聴履歴が、メディア識別子とコンテンツ識別子を用いて蓄積されるので、サービス側と視聴履歴蓄積側の相互運用性を高めることができる。また、視聴履歴データベースに語彙の共通化が困難なメタ情報レベルの語彙が含まれないため、さまざまなベンダーが自由にサービスコンシェルジェを設計したり、詳細度の高い独自のメタ情報を利用するなどして、コンテンツ視聴履歴を活用したサービスを提供することができる。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【特許請求の範囲】
【請求項１】
コンテンツ視聴に利用される電化機器において、コンテンツ視聴履歴データを記録する方法であって、
当該電化機器に対するユーザの操作を解釈して、コンテンツ視聴操作を抽出し、
抽出されたコンテンツ視聴操作に係るコンテンツについて、コンテンツ識別子を求め、
前記コンテンツについて、抽出されたコンテンツ視聴操作から視聴日時を特定し、特定した視聴日時と前記コンテンツ識別子とを組にして、視聴履歴記憶部に視聴履歴データとして記録する
ことを特徴とする視聴履歴記録方法。
【請求項２】
複数の機器におけるコンテンツの視聴履歴を利用する方法であって、
コンテンツが前記複数の機器にわたって共通の識別子によって特定されているコンテンツ視聴履歴データから、同一の識別子を持つコンテンツに対し、前記複数の機器において行われた一連の操作パターンを抽出し、
抽出した操作パターンの中から、共通の属性を有するコンテンツに対して共通に行われた操作パターンを特定し、
特定した操作パターンを、当該属性を有する他のコンテンツに適用するための、操作パターン再現スクリプトを生成する
ことを特徴とする視聴履歴利用方法。
【請求項１】
コンテンツ視聴に利用される電化機器において、コンテンツ視聴履歴データを記録する方法であって、
当該電化機器に対するユーザの操作を解釈して、コンテンツ視聴操作を抽出し、
抽出されたコンテンツ視聴操作に係るコンテンツについて、コンテンツ識別子を求め、
前記コンテンツについて、抽出されたコンテンツ視聴操作から視聴日時を特定し、特定した視聴日時と前記コンテンツ識別子とを組にして、視聴履歴記憶部に視聴履歴データとして記録する
ことを特徴とする視聴履歴記録方法。
【請求項２】
複数の機器におけるコンテンツの視聴履歴を利用する方法であって、
コンテンツが前記複数の機器にわたって共通の識別子によって特定されているコンテンツ視聴履歴データから、同一の識別子を持つコンテンツに対し、前記複数の機器において行われた一連の操作パターンを抽出し、
抽出した操作パターンの中から、共通の属性を有するコンテンツに対して共通に行われた操作パターンを特定し、
特定した操作パターンを、当該属性を有する他のコンテンツに適用するための、操作パターン再現スクリプトを生成する
ことを特徴とする視聴履歴利用方法。
【国際公開番号】ＷＯ２００４／０４５２２１
【国際公開日】平成１６年５月２７日（２００４．５．２７）
【発行日】平成１８年３月１６日（２００６．３．１６）
【国際特許分類】
【出願番号】特願２００４−５５１２３２（Ｐ２００４−５５１２３２）
【国際出願番号】ＰＣＴ／ＪＰ２００３／０１４４８４
【国際出願日】平成１５年１１月１３日（２００３．１１．１３）
【特許番号】特許第３７１３０４３号（Ｐ３７１３０４３）
【特許公報発行日】平成１７年１１月２日（２００５．１１．２）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
イーサネット
ＥＴＨＥＲＮＥＴ
ＪＡＶＡ
【出願人】（０００００５８２１）松下電器産業株式会社 (73,050)
【Ｆターム（参考）】
【国際公開日】平成１６年５月２７日（２００４．５．２７）
【発行日】平成１８年３月１６日（２００６．３．１６）
【国際特許分類】
【国際出願番号】ＰＣＴ／ＪＰ２００３／０１４４８４
【国際出願日】平成１５年１１月１３日（２００３．１１．１３）
【特許番号】特許第３７１３０４３号（Ｐ３７１３０４３）
【特許公報発行日】平成１７年１１月２日（２００５．１１．２）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
イーサネット
ＥＴＨＥＲＮＥＴ
ＪＡＶＡ
【出願人】（０００００５８２１）松下電器産業株式会社 (73,050)
【Ｆターム（参考）】
[ Back to top ]