JP6514505B2 - 情報処理装置、情報処理方法、並びにプログラム - Google Patents

Description

本技術は、情報処理装置、情報処理方法、並びにプログラムに関する。詳しくは、複数のサービスを提供するそれぞれのサーバからのサービスを、汎用のクライアントで処理できるようにする情報処理装置、情報処理方法、並びにプログラムに関する。

パーソナルコンピュータやデジタル家電の普及のともない、ホームＩＰ（Internet Protocol）ネットワークを介して、それら機器を相互接続し、ビデオ、オーディオ、写真などのデジタルコンテンツを共有して楽しむことが現実のものとなってきている。例えば、ＤＬＮＡ（Digital Living Network Alliance）では、それらデジタル機器がデジタルコンテンツの共有を行ううえでの必要な技術仕様、実装ガイドラインを定め、異なるベンダーの機器同士でも相互に接続することができ、ホームＩＰネットワークの業界標準となっている。

一方、放送システムも変革が見られ、従来、地上波や衛星を使って放送していたビデオコンテンツをＩＰブロードバンドネットワーク経由で伝送するＩＰＴＶサービス、ＶＯＤ（Video On Demand）サービスなどが商用化され始めてきている。このようなサービスにおいては、家庭内にＳＴＢ（Set Top Box）が設置され、そのＳＴＢがテレビジョン受像器などの表示装置に接続されることで、サービスを受けることができる。

このようなＩＰＴＶサービスやＶＯＤサービスが今後普及してくると、従来、一般的なブロードキャスト放送としてのＴＶ放送コンテンツをＤＬＮＡ 機器で共有して視聴していたのと同様に、ＩＰＴＶサービスから提供されるビデオコンテンツについてもＤＬＮＡ機器で利用したいというユーザの要求が起きてくる。

このような要請を実現するための解決案として、ＩＰＴＶサービスのプロトコル、メディアフォーマットなどを、ＤＬＮＡ機器のプロトコル、メディアフォーマットに変換して、ホームネットワーク接続機器に提供するといった手法が考えられる。なお、フォーマット変換処理を実行するホームネットワーク組み込みモジュールについては特許文献１に記載がある。

特表２００５−５３１２３１号公報

上記したように、ＳＴＢをテレビジョン受像器に接続した視聴は、ＩＰＴＶサービス、ＶＯＤサービスに限らず、ケーブルテレビジョン放送などでも行われている。ＳＴＢを用いた視聴の場合、ＳＴＢからテレビジョン受像器には、オーディオデータとビデオデータが供給される。

例えば、テレビジョン受像器が放送局からの放送番組を、ＳＴＢを介さずに受信した場合、オーディオデータやビデオデータの他に、番組に関する情報や番組内で紹介された店の情報などの情報を受信し、ユーザに提供できる場合がある。しかしながら、ＳＴＢを介した受信であると、上記したように、ＳＴＢからはオーディオデータとビデオデータのみがテレビジョン受像器に供給され、そのような情報は、テレビジョン受像器に供給されない。よって、放送局からの情報をユーザに提示することができない。

また、ＳＴＢを用いた視聴の場合、ユーザは、ＳＴＢのリモートコントローラを使い視聴を行い、テレビジョン受像器のリモートコントローラを用いない傾向にある。テレビジョン受像器を提供する側としては、テレビジョン受像器のリモートコントローラを利用してもらいという要望がある。また、放送局側としては、番組情報などの情報も、ユーザに利用してもらいたいという要望がある。

本技術は、このような状況に鑑みてなされたものであり、ＳＴＢなどを用いた視聴においても、番組に付随する情報をテレビジョン受像器で提供することができるようにするものである。

本技術の一側面の情報処理装置は、ＡＣＲ（Automatic Content Recognition）クライアントとして機能するように構成され、コンテンツの同定を行うための第１のプロトコルを使用する第１のＡＣＲサーバと通信し、コンテンツの同定を行うための第２のプロトコルを使用する少なくとも第２のＡＣＲサーバと通信する処理部を備え、前記第１のプロトコルと前記第２のプロトコルは異なり、前記処理部は、コンテンツサーバからコンテンツを受信し、前記コンテンツをオーディオデータ、および／または、ビデオデータにデコードするように構成され、前記オーディオデータ、および／または、前記ビデオデータからサンプルデータを抽出し、前記サンプルデータに基づいて前記コンテンツを識別するために、前記サンプルデータを前記第１のＡＣＲサーバに送信し、前記サンプルデータに基づいて前記コンテンツを識別するために、前記サンプルデータを前記第２のＡＣＲサーバに送信し、前記第１のＡＣＲサーバからコンテンツの第１の同定を受信し、前記第２のＡＣＲサーバからコンテンツの第２の同定を受信する。

前記コンテンツの第１の同定と前記コンテンツの第２の同定は、ＡＣＲに基づくようにすることができる。

テレビジョンコンテンツ、ビデオコンテンツ、オーディオコンテンツ、またはデジタルコンテンツのうちの少なくとも１つを含むコンテンツを受信するようにすることができる。

前記コンテンツは、ＩＰブロードバンドネットワーク経由で受信されるようにすることができる。

前記第２のＡＣＲサーバからの結果を、ＤＬＮＡ（Digital Living Network Alliance）に基づくフォーマットに変換し、受信された前記コンテンツを、ＤＬＮＡに基づくフォーマットに変換するようにすることができる。

前記第２のＡＣＲサーバのそれぞれから同定されたコンテンツの情報を取得し、取得された前記情報を一括するようにすることができる。

前記ＡＣＲサーバと所定の装置との間に設けられるゲートウェイ内に設けられるようにすることができる。
テレビジョン受像機であるようにすることができる。

本技術の一側面の情報処理方法は、ＡＣＲ（Automatic Content Recognition）クライアントとして機能するように構成され、コンテンツの同定を行うための第１のプロトコルを使用する第１のＡＣＲサーバと通信し、コンテンツの同定を行うための第２のプロトコルを使用する少なくとも第２のＡＣＲサーバと通信する処理部を備える情報処理装置の情報処理方法において、前記第１のプロトコルと前記第２のプロトコルは異なり、前記処理部は、コンテンツサーバからコンテンツを受信し、前記コンテンツをオーディオデータ、および／または、ビデオデータにデコードし、前記オーディオデータ、および／または、前記ビデオデータからサンプルデータを抽出し、前記サンプルデータに基づいて前記コンテンツを識別するために、前記サンプルデータを前記第１のＡＣＲサーバに送信し、前記サンプルデータに基づいて前記コンテンツを識別するために、前記サンプルデータを前記第２のＡＣＲサーバに送信し、前記第１のＡＣＲサーバからコンテンツの第１の同定を受信し、前記第２のＡＣＲサーバからコンテンツの第２の同定を受信するステップを含む。

本技術の一側面のプログラムは、コンピュータを、ＡＣＲ（Automatic Content Recognition）クライアントとして機能するように構成され、コンテンツの同定を行うための第１のプロトコルを使用する第１のＡＣＲサーバと通信し、コンテンツの同定を行うための第２のプロトコルを使用する少なくとも第２のＡＣＲサーバと通信する処理部を備え、前記第１のプロトコルと前記第２のプロトコルは異なり、前記処理部は、コンテンツサーバからコンテンツを受信し、前記コンテンツをオーディオデータ、および／または、ビデオデータにデコードするように構成され、前記オーディオデータ、および／または、前記ビデオデータからサンプルデータを抽出し、前記サンプルデータに基づいて前記コンテンツを識別するために、前記サンプルデータを前記第１のＡＣＲサーバに送信し、前記サンプルデータに基づいて前記コンテンツを識別するために、前記サンプルデータを前記第２のＡＣＲサーバに送信し、前記第１のＡＣＲサーバからコンテンツの第１の同定を受信し、前記第２のＡＣＲサーバからコンテンツの第２の同定を受信する情報処理装置における処理部として機能させる。

本技術の一側面の情報処理装置、情報処理方法、並びにプログラムにおいては、ＡＣＲ（Automatic Content Recognition）クライアントとして機能するように構成され、コンテンツの同定を行うための第１のプロトコルを使用する第１のＡＣＲサーバと通信が行われ、コンテンツの同定を行うための第２のプロトコルを使用する少なくとも第２のＡＣＲサーバと通信が行われる。第１のプロトコルと第２のプロトコルは異なり、処理部は、コンテンツサーバからコンテンツを受信し、コンテンツをオーディオデータ、および／または、ビデオデータにデコードするように構成され、オーディオデータ、および／または、ビデオデータからサンプルデータを抽出し、サンプルデータに基づいてコンテンツを識別するために、サンプルデータを第１のＡＣＲサーバに送信し、サンプルデータに基づいてコンテンツを識別するために、サンプルデータを第２のＡＣＲサーバに送信し、第１のＡＣＲサーバからコンテンツの第１の同定を受信し、第２のＡＣＲサーバからコンテンツの第２の同定を受信する。

本技術の一側面によれば、ＳＴＢなどを用いた視聴においても、番組に付随する情報をテレビジョン受像器で提供することができる。

コンテンツ配信システムの構成を示す図である。 クライアントの構成を示す図である。 コンテンツサーバの構成を示す図である。 ＡＣＲサーバの構成を示す図である。 ＡＣＲサーバとＡＣＲクライアントとの関係について説明するための図である。 汎用ＡＣＲクライアントについて説明するための図である。 システムの構成例を示す図である。 システムの構成例を示す図である。 ＩＰＴＶサーバとＩＰＴＶクライアントとの関係について説明するための図である。 プロトコル変換ゲートウェイについて説明するための図である。 システムの構成例を示す図である。 プロトコル変換ゲートウェイの内部構成例を示す図である。 メタデータの蓄積に関わる処理について説明するための図である。 リファレンスデータについて説明するための図である。 メタデータの供給に関わる処理について説明するための図である。 ＡＣＲクエリーについて説明するための図である。 ＡＣＲレスポンスについて説明するための図である。 ＡＣＲレスポンスについて説明するための図である。 メタデータの供給について説明するための図である。 メタデータの供給について説明するための図である。 メタデータの供給について説明するための図である。 メタデータの供給に関わる処理について説明するための図である。 記録媒体について説明するための図である。

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

［コンテンツ配信システムの構成］
図１は、コンテンツ配信システムの構成を示す図である。コンテンツ配信システム１は、クライアント１１、コンテンツサーバ１２、ＡＣＲサーバ１３から構成される。クライアント１１乃至ＡＣＲサーバ１３は、インターネット等のネットワーク２１を介して相互に接続される。なお、この構成は、一例であり、後述するように、ＳＴＢ（Set Top Box）やモデムなどを含む構成の場合もある。

クライアント１１は、コンテンツサーバ１２に対して、ネットワーク２１を介してコンテンツの配信を要求する。コンテンツサーバ１２は、クライアント１１からコンテンツの配信が要求された場合、その要求に応じた所定のコンテンツのデータを、ネットワーク２１を介して配信する。

なお、コンテンツの配信方式としては、ストリーミング配信又はダウンロード配信のいずれでもよく、ユニキャスト（１対１）又はマルチキャスト（１対多）により配信される。

クライアント１１は、ＡＣＲサーバ１３に対して、ネットワーク２１を介してコンテンツの同定を要求する。ＡＣＲサーバ１３は、クライアント１１からコンテンツの同定が要求された場合、クライアント１１で再生されているコンテンツを同定する処理を実行する。ＡＣＲサーバ１３は、同定結果を、ネットワーク２１を介してクライアント１１に通知する。

コンテンツの同定処理としては、例えば、ＡＣＲ（Automatic Content Recognition）と称される、コンテンツを構成するビデオデータ又はオーディオデータに基づいて、対象コンテンツを同定（特定）する処理が用いられる。このＡＣＲを用いることで、動画の解像度、アスペクト比、ビットレート、又はフォーマットなどの情報に依存せずに、ビデオデータ又はオーディオデータに基づいて、クライアント１１において再生されているコンテンツと同一となる対象コンテンツを同定することが可能となる。

以上のようにして、図１のコンテンツ配信システム１は構成される。

［クライアントの構成］
図２は、クライアント１１の構成を示す図である。クライアント１１は、通信I/F３１、コンテンツ再生部３２、表示制御部３３、表示部３４、RAM３５、サンプル取得部３６、制御部３７、メモリ３８、操作部３９から構成される。

通信I/F３１は、制御部３７の制御に従い、ネットワーク２１を介してコンテンツサーバ１２またはＡＣＲサーバ１３に接続する。通信I/F３１は、制御部３７の制御に従い、各種の要求を、ネットワーク２１を介してコンテンツサーバ１２またはＡＣＲサーバ１３に送信する。

通信I/F３１は、コンテンツサーバ１２からコンテンツのデータを受信した場合、そのコンテンツのデータをコンテンツ再生部３２に供給し、ＡＣＲサーバ１３から同定結果を受信した場合、その同定結果を制御部３７に供給する。

コンテンツ再生部３２は、通信I/F３１から供給されるコンテンツのデータに対して、デコード等のビデオデータを得るための所定の処理を施し、それにより得られるビデオデータを、表示制御部３３に供給する。表示制御部３３は、コンテンツ再生部３２から供給されるビデオデータを、表示部３４に表示させる。なお、コンテンツ再生部３２によって、コンテンツのデータから得られるオーディオデータは、後段のスピーカ（不図示）に供給される。

RAM３５は、コンテンツ再生部３２により得られたコンテンツのビデオデータを一時的に記憶する。サンプル取得部３６は、RAM３５に記憶されたコンテンツのビデオデータから、サンプルデータを取得し、制御部３７に供給する。

なお、後述するように、ＡＣＲの処理を行うＡＣＲクライアントを、テレビジョン受像器などの表示装置と別に設けた場合、その別に設けられるＡＣＲクライアントには、RAM３５やサンプル取得部３６が含まれる。

制御部３７は、クライアント１１の各部の動作を制御する。メモリ３８には、制御部３７が所定の処理を実行する上で必要なプログラムやデータが一時的に記憶される。操作部３９は、ユーザからの各種の操作を受け付けて、それに対応する信号を制御部３７に供給する。

また、制御部３７は、通信I/F３１を制御して、サンプル取得部３６から供給されるサンプルデータをＡＣＲサーバ１３に送信し、ＡＣＲサーバ１３から同定結果を取得する。

以上のようにして、クライアント１１は構成される。

［コンテンツサーバの構成］
図３は、コンテンツサーバ１２の構成を示す図である。コンテンツサーバ１２は、通信I/F５１、コンテンツ取得部５２、コンテンツ記憶部５３、及びコンテンツ配信部５４から構成される。

通信I/F５１は、ネットワーク２１を介してクライアント１１に接続する。通信I/F５１は、ネットワーク２１を介して、クライアント１１からコンテンツの配信が要求された場合、コンテンツの配信要求を、コンテンツ取得部５２に供給する。

コンテンツ取得部５２は、通信I/F５１から供給されるコンテンツの配信要求に基づいて、配信要求に応じたコンテンツのデータを、コンテンツ記憶部５３から取得し、コンテンツ配信部５４に供給する。コンテンツ記憶部５３には、例えば、テレビ番組や映画等の各種のコンテンツのデータが記憶されているが、それらのコンテンツのデータは、コンテンツ記憶部５３に記憶されているものの他、外部の装置から取得されるようにしてもよい。

コンテンツ配信部５４は、通信I/F５１を制御して、コンテンツ取得部５２から供給されるコンテンツのデータを、ネットワーク２１を介してクライアント１１に配信する。

以上のようにして、コンテンツサーバ１２は構成される。なお、ここではコンテンツサーバ１２として説明しているが、後述するように、例えばＩＰＴＶなどのＩＰＴＶサーバとされる場合もある。

［ＡＣＲサーバの構成］
図４は、ＡＣＲサーバ１３の構成を示す図である。ＡＣＲサーバ１３は、通信I/F６１、コンテンツ同定部６２、コンテンツ属性データベース６３、及び同定結果通知部６４から構成される。通信I/F６１は、ネットワーク２１を介してクライアント１１に接続する。通信I/F６１は、ネットワーク２１を介して、クライアント１１からコンテンツの同定が要求された場合、同定要求を、コンテンツ同定部６２に供給する。

コンテンツ同定部６２は、通信I/F６１から供給される同定要求に含まれるサンプルデータ、及びコンテンツ属性データベース６３から取得される属性データに基づいて、コンテンツを同定する処理を実行する。コンテンツ同定部６２は、同定結果を、同定結果通知部６４に供給する。

コンテンツ属性データベース６３には、オリジナルのコンテンツを同定するためのサンプルデータが記憶されている。また、オリジナルのコンテンツには、識別子（コンテンツIDやコンテンツURL等）があらかじめ割り当てられている。なお、コンテンツ属性データベース６３は、ＡＣＲサーバ１３とは別に設置して、ＡＣＲサーバ１３からネットワーク２１を介して接続されるようにしてもよい。

同定結果通知部６４には、コンテンツ同定部６２からの同定結果が供給される。同定結果通知部６４は、通信I/F６１を制御して、相対再生時間を含む同定結果を、ネットワーク２１を介してクライアント１１に通知する。

以上のようにして、ＡＣＲサーバ１３は構成される。

［ＡＣＲサーバとクライアントとの関係について］
図１には、ＡＣＲサーバ１３は１台しか図示していないが、複数の異なるＡＣＲサーバ１３が存在している可能性がある。異なるＡＣＲサーバ１３とは、異なるプロトコルに基づき抽出されるサンプルによる同定を行うサーバであり、異なるプロバイダに管理されているサーバである。

プロバイダ独自のＡＣＲサーバ１３においては、プロバイダ独自のプロトコルによりコンテンツの同定を行う。プロトコルの違いは、例えば、サンプルの出し方の違いにある。例えば、サンプルとして、番組内の一場面の画像から輝度により特徴量を抽出する、動きが大きな画像のときに特徴量を抽出する、画面内の所定の領域から特徴量を抽出するといったように、サンプルデータの出し方が異なる。

以下、適宜、サンプルデータを特徴量と記述する。また、サンプルデータとして、ウォータマークやフィンガープリントなどのシグニチャを用いることもできるが、ここでは特徴量を例に挙げて説明を続ける。また、ＡＣＲサーバ１３側で、コンテンツの同定を行う際に参照されるデータを、適宜、リファレンスデータと記述し、そのリファレンスデータは、コンテンツ属性データベース６３に記憶されているとして説明を続ける。

図５に示すように、複数のＡＣＲサーバ１３がある場合には、それぞれのＡＣＲサーバ１３に対応するＡＣＲクライアントが必要となる。図５を参照するに、図５に示した例では、ＡＣＲサーバ１３−１乃至１３−３の３個の異なるＡＣＲサーバ１３がネットワークに接続されている。これらのＡＣＲサーバ１３−１乃至１３−３で提供されるサービスの提供を受けるためには、それぞれのＡＣＲサーバ１３−１乃至１３−３に対応するＡＣＲクライアント１０１−１乃至１０１−３をクライアント１１は備える必要がある。

すなわち、ＡＣＲサーバ１３−１のプロトコルに対応したＡＣＲクライアント１０１−１、ＡＣＲサーバ１３−２のプロトコルに対応したＡＣＲクライアント１０１−２、およびＡＣＲサーバ１３−３のプロトコルに対応したＡＣＲクライアント１０１−３を、クライアント１１は備える必要がある。

このように複数のＡＣＲクライアント１０１をクライアント１１が実装しなくてはらならず、また複数のＡＣＲクライアント１０１を実装するためにはメンテナンスコストがかかるという問題が生じる可能性があった。

［汎用のＡＣＲクライアントについて］
そこで、図６に示すように汎用のＡＣＲクライアントを設けるようにする。図６を参照するに、ＡＣＲ機能を集中的に受け持つプロトコル変換ゲートウェイにＡＣＲサービスに依存する汎用ＡＣＲクライアント１２１を実装する構成とする。このことにより、エンドデバイス１３１側でのＡＣＲクライアントを稼働する処理負担、また個別のＡＣＲシステムに依存するＡＣＲクライアントを実装する負荷やコストを低減させることが可能となる。

このように汎用ＡＣＲクライアント１２１を設けることで、エンドデバイス１３１においては、プロバイダ毎の独自ＡＣＲプロトコルを実装する必要がなくなり、その実装・メンテナンスコストを低減することができる。また、それぞれのＡＣＲサービス毎にそのサービスでは解決できない対象コンテンツ（そのＡＣＲサービスにとって不得意なコンテンツ）がある場合に、より信憑性の高い結果を返す可能性が高いＡＣＲサービスに並行してリクエストすることにより、コンテンツ特定の信頼性を向上させることも可能となる。

例えば、汎用ＡＣＲクライアント１２１が、ＡＣＲクライアント１０１−１にコンテンツを同定する指示を出し、ＡＣＲクライアント１０１−１が、ＡＣＲサーバ１３−１に問い合わせする。その結果、ＡＣＲサーバ１３−１からＡＣＲクライアント１０１−１に、コンテンツが同定できなかったとのレスポンスを受けたとする。このとき、汎用ＡＣＲクライアント１２１は、再度同じ指示を、ＡＣＲクライアント１０１-２に対して行う。ＡＣＲクライアント１０１−２がＡＣＲサーバ１３−２に問い合わせをした結果、コンテンツを同定したとのレスポンスを受けたとする。

この場合、ＡＣＲサーバ１３−１では同定できなかったコンテンツであっても、ＡＣＲサーバ１３−２では同定できたことになる。またここでは、ＡＣＲサーバ１３−１の次に、ＡＣＲサーバ１３−２に対して問い合わせをするとして説明したが、ＡＣＲサーバ１３−１とＡＣＲサーバ１３−２に対して、同時に問い合わせを実行することもできる。

このように、コンテンツを特定できるＡＣＲサーバ１３を探し出し、コンテンツを同定することが可能となるので、上記したように、コンテンツ特定の信頼性を向上させることも可能となる。

図６に示したように、ＡＣＲクライアント１０１−１乃至１０１−３は、それぞれ、異なるプロトコルでコンテンツの同定を行うＡＣＲサーバ１３−１乃至１３−３と通信を行い、授受されるデータの処理を行う。汎用ＡＣＲクライアント１２１は、ＡＣＲクライアント１０１−１乃至１０１−３のそれぞれと通信を行い、授受されるデータの処理を行うとともに、エンドデバイス１３１とのデータの処理も行う。

また、図６に示したように、ＡＣＲクライアント１０１と汎用ＡＣＲクライアント１２１は、ＡＣＲサーバ１３とエンドデバイス１３１との間に設けられる。ＡＣＲサーバ１３側との通信は、インターネットなどの広域ネットワークを用いて行われ、エンドデバイス１３１との通信は、家庭内などの限られた範囲内のネットワークを用いて行われる。そのようなネットワークが切り替えられるところに設けられるに、ＡＣＲクライアント１０１と汎用ＡＣＲクライアント１２１を設けることができる。

なお、図６に示したエンドデバイス１３１は、例えば、テレビジョン受像器などの機器である。また、汎用ＡＣＲクライアント１２１は、テレビジョン受像器に対して物理的に外部に備えられる機器として構成されても良いし、テレビジョン受像器に対して物理的に内部に備えられる機器として構成されていても良い。

［ＩＰＴＶについて］
次に、ＩＰＴＶについて説明する。ここでＩＰＴＶは、地上波や衛星を使って放送していたビデオコンテンツをＩＰブロードバンドネットワーク経由で伝送するサービスである。

図７は、ＩＰＴＶシステムの構成例を示す図である。プロバイダ独自のＩＰＴＶサーバ１５１は、アクセスネットワーク１５２を介してモデム／ルータ１５３に接続されている。モデム／ルータ１５３は、Ethernet（登録商標）やWiFiなどで構成されるホームネットワーク１５４を介して、ＳＴＢ１５５に接続されている。ＳＴＢ(Set Top Box)１５５は、ＨＤＭＩ（登録商標）などの所定のケーブルでテレビジョン受像器などのエンドデバイス１３１に接続されている。

このようなシステムにおいてサービスプロバイダ（ＩＰＴＶサーバ１５１）は、独自のＩＰＴＶプロトコルを利用してＩＰＴＶサービス（VoD(Video on Demand)、LinearTV(ライブ等の放送型一斉同報配信)）を提供している。独自のプロトコルを利用するためこのプロトコルを実装したＳＴＢ１５５がプロバイダから提供され、それにエンドデバイス１３１がHDMI（登録商標）等で接続される。

ＩＰＴＶサーバ１５１からの番組のオーディオデータやビデオデータは、アクセスネットワーク１５２を介して、モデム／ルータ１５３に供給され、さらにホームネットワーク１５４を介してＳＴＢ１５５に供給される。ＳＴＢ１５１からは、オーディオデータとビデオデータがＨＤＭＩ（登録商標）などのケーブルを介してエンドデバイス１３１に供給される。

ＳＴＢ１５５は、エンドデバイス１３１に所定のケーブルで接続され、１対１で接続される。よって、家庭内（ホームネットワーク１５４内）に複数のエンドデバイス１３１が存在する場合、それぞれのエンドデバイス１３１に対してＳＴＢ１５５が必要となるため、複数のＳＴＢ１５５が存在する。

ＳＴＢ１５５が接続されているエンドデバイス１３１においては、ＳＴＢ１５５のリモートコントローラが用いられて番組の検索や、視聴する番組の選択などの操作が行われるのが一般的である。エンドデバイス１３１が例えば、テレビジョン受像器である場合、そのテレビジョン受像器のリモートコントローラは使用されないことが多い。

ＳＴＢ１５５からエンドデバイス１３１には、オーディオデータとビデオデータが供給されるが、仮に他のデータがＳＴＢ１５５に供給されても、他のデータは、エンドデバイス１３１には供給されない。例えば、他のデータとして、番組の内容や番組内で紹介された店の情報などの番組に付随する情報がデータとして、オーディオデータやビデオデータなどと一緒にＳＴＢ１５５に供給されても、ＳＴＢ１５５ではオーディオデータとビデオデータを抽出し、エンドデバイス１３１に供給する。よってエンドデバイス１３１では、番組に付随する情報をユーザに提供することができない。

エンドデバイス１３１に、汎用ＡＣＲクライアント１２１を備えるようにすると、汎用ＡＣＲクライアント１２１により、ＳＴＢ１３１から供給されるオーディオデータによる音声、またはビデオデータによる映像から、特徴量をサンプルデータとして抽出することができるようになる。そして、そのサンプルデータを、ＡＣＲサーバ１３に供給し、ＡＣＲサーバ１３によりサンプルデータから番組が同定されるようにすることができる。

この同定された番組に関する情報を、ＡＣＲサーバ１３から汎用ＡＣＲクライアント１２１に供給することで、エンドデバイス１３１は、番組に関する情報を取得することができる。この番組に関する情報を、上記した番組に付随する情報とすることで、ＳＴＢ１５５により供給されなかったデータをエンドデバイス１３１に供給することができる。このような番組に付随する情報などを見るために、エンドデバイス１３１のリモートコントローラが用いられる。よって、エンドデバイス１３１のリモートコントローラの利用頻度を高めることができる。

また、以下に説明するＤＬＮＡ(Digital Living Network Alliance)を用いることで、ホームネットワーク１５４内に複数のエンドデバイス１３１が存在していても、複数のＳＴＢ１５５をそれぞれのエンドデバイス１３１に接続しなくても良い構成とすることができる。

［ＤＬＮＡを用いた構成について］
ホームネットワークにおけるコンテンツ共有を実現するプロトコルとしてＤＬＮＡが普及しつつある。ホームネットワークの外から提供されるプロバイダのＩＰＴＶプロトコルをＤＬＮＡプロトコルに変換するモジュールをプロトコルゲートウェイに実装することにより、ＤＬＮＡという標準化された統一インターフェイスを利用してテレビジョン受像機やモニターデバイスにＩＰＴＶサービスを提供できるようにすることができる(ＩＰＴＶ-ＤＬＮＡプロトコル変換と称する)。

例えば、ＤＬＮＡを用いると、図７に示したシステムは、図８に示したシステムとなる。図８に示したシステムにおいてプロバイダ独自のＩＰＴＶサーバ１５１は、アクセスネットワーク１５２を介してプロトコル変換ゲートウェイ２０１に接続されている。プロトコル変換ゲートウェイ２０１は、ホームネットワーク１５４を介して、テレビジョン受像器などのエンドデバイス１３１に接続されている。

図８に示したシステムにおいては、ＳＴＢ１５５が省略された構成とされている。また、プロトコル変換ゲートウェイ２０１には、ＩＰＴＶプロトコルをＤＬＮＡプロトコルに変換するモジュールが組み込まれている。また、図示はしていないが、エンドデバイス１３１とホームネットワーク１５４との間、プロトコル変換ゲートウェイ２０１とホームネットワーク１５４との間、またはプロトコル変換ゲートウェイ２０１内に、汎用ＡＣＲクライアント１２１が設けられる。以下の説明においては、プロトコル変換ゲートウェイ２０１内に汎用ＡＣＲクライアント１２１が設けられるとして説明を続ける。

図８に示したような構成によれば、ＩＰＴＶサーバ１５１からの番組のオーディオデータやビデオデータを含むストリームは、アクセスネットワーク１５２を介して、プロトコル変換ゲートウェイ２０１に供給される。プロトコル変換ゲートウェイ２０１は、供給されたＩＰＴＶプロトコルに基づくデータを、ＤＬＮＡプロトコルに基づくデータに変換し、ホームネットワーク１５４を介してエンドデバイス１３１に供給する。

図８では図示していないが、仮に複数のエンドデバイス１３１が、ホームネットワーク１５４内に存在していても、ＤＬＮＡプロトコルに基づくデータがホームネットワーク１５４内で授受されるため、サービスプロバイダに依存するＳＴＢ１５５を複数台設けなくとも、各エンドデバイス１３１でＩＰＴＶサーバ１５１からの番組を視聴できる。

ところで、ＩＰＴＶサーバ１５１も、サービスを提供するプロバイダ毎に、ＩＰＴＶプロトコルが異なる可能性があるため、エンドデバイス１３１側では、それぞれのＩＰＴＶプロトコルに依存するＩＰＴＶクライアントを備える必要がある。しかしながら、ＤＬＮＡを用いることで、プロトコルの違いを吸収した処理を行うことが可能となる。

［ＩＰＴＶにＤＮＬＡを適用した場合について］
図９は、異なるＩＰＴＶプロトコルでサービスを提供する複数のＩＰＴＶサーバがアクセスネットワーク１５２に接続されているときの構成例を示す図である。図９に示した構成例においては、ＩＰＴＶサーバ１５１―１乃至１５１−３の３台のＩＰＴＶサーバ１５１がネットワークに接続されている。また、これらのＩＰＴＶ１５１−１乃至１５１−３のそれぞれに対応するＩＰＴＶクライアント２２１−１乃至２２１−３が設けられている。

ＩＰＴＶサーバ１５１−１のＩＰＴＶプロトコルに対応したＩＰＴＶクライアント２２１−１、ＩＰＴＶサーバ１５１−２のＩＰＴＶプロトコルに対応したＩＰＴＶクライアント２２１−２、およびＩＰＴＶサーバ１５１−３のＩＰＴＶプロトコルに対応したＩＰＴＶクライアント２２１−３は、エンドデバイス１３１側に設けられている。具体的に、これらのＩＰＴＶクライアント２２１−１乃至２２１−３は、プロトコル変換ゲートウェイ２０１に設けられる。

プロトコル変換ゲートウェイ２０１には、さらにＤＬＮＡサーバ２３１も設けられる。すなわち、プロトコル変換ゲートウェイ２０１は、ＩＰＴＶクライアント２２１−１乃至２２１−３のいずれかのＩＰＴＶクライアント２２１でＩＰＴＶプロトコルに基づき処理されたデータを、ＤＬＮＡサーバ２３１によりＤＬＮＡプロトコルに基づく処理を施し、エンドデバイス１３１に出力する。エンドデバイス１３１は、ＤＬＮＡクライアントに相当する。

このように、図９に示した例では、ＩＰＴＶクライアント２２１−１乃至２２１−３は、それぞれ異なるプロトコルでコンテンツを送信するＩＰＴＶサーバ１５１−１乃至１５１−３との通信を行い、ＩＰＴＶサーバ１５１−１乃至１５１−３とのデータ（コンテンツ）の処理を行う。また、ＤＬＮＡサーバ２３１は、エンドデバイス１３１と通信を行い、エンドデバイス１３１とのデータを処理する。

ここで、図１０を参照し、プロトコル変換ゲートウェイ２０１における変換について説明を加える。図１０のＡを参照するに、ＩＰＴＶサーバ１５１からＨＴＴＰ（Hyper Text Transfer Protocol）アダプティブストリーミング型でストリーミングが行われた場合、ＩＰＴＶサーバ１５１からＨＴＴＰに基づくコンテンツストリームがアクセスネットワーク１５２（図１０のＡでは不図示）を介してプロトコル変換ゲートウェイ２０１に送信される。

プロトコル変換ゲートウェイ２０１では、ＩＰＴＶサーバ１５１からのコンテンツストリームを、ＩＰＴＶクライアント２２１が取得する。ＩＰＴＶクライアント２２１は、取得されたコンテンツストリームから、オーディオデータをデコードしたり、ビデオデータをデコードしたりする。デコードされたオーディオデータとビデオデータは、ＤＬＮＡサーバ２３１に供給される。

ＤＬＮＡサーバ２３１では、供給されたオーディオデータとビデオデータを、ＤＬＮＡのプロトコルに基づくフォーマットのＨＴＴＰストリーミングプロトコルのデータに変換し、ホームネットワーク１５４を介してＤＬＮＡクライアントであるエンドデバイス１３１に送信する。エンドデバイス１３１は、ＤＬＮＡクライアントであるため、ＤＬＮＡに基づくフォーマットのデータを取得し、再生することができる。

図１０のＢを参照するに、ＩＰＴＶサーバ１５１からＲＴＳＰ／ＲＴＰ（Real Time Streaming Protocol／Real-time Transport Protocol）ストリーミング型でストリーミングが行われた場合、ＩＰＴＶサーバ１５１からＲＴＳＰ／ＲＴＰに基づくコンテンツストリームがアクセスネットワーク１５２を介してプロトコル変換ゲートウェイ２０１に送信される。

プロトコル変換ゲートウェイ２０１では、ＩＰＴＶサーバ１５１からのコンテンツストリームを、ＩＰＴＶクライアント２２１が取得する。ＩＰＴＶクライアント２２１は、取得されたコンテンツストリームから、オーディオデータをデコードしたり、ビデオデータをデコードしたりする。デコードされたオーディオデータとビデオデータは、ＤＬＮＡサーバ２３１に供給される。

ＤＬＮＡサーバ２３１では、供給されたオーディオデータとビデオデータを、ＤＬＮＡのプロトコルに基づくフォーマットのＨＴＴＰストリーミングプロトコルのデータに変換し、ホームネットワーク１５４を介してＤＬＮＡクライアントであるエンドデバイス１３１に送信する。エンドデバイス１３１は、ＤＬＮＡクライアントであるため、ＤＬＮＡに基づくフォーマットのデータを取得し、再生することができる。

図１０のＣを参照するに、ＩＰＴＶサーバ１５１から、ＩＰｖ４のＩＧＭＰ（Internet Group Management Protocol）、ＩＰｖ６のＭＬＤ（Multicast Listener Discovery）、またはＲＴＰなどのマルチキャスト型でストリーミングが行われた場合、ＩＰＴＶサーバ１５１からＩＧＭＰ、ＭＬＤ、またはＲＴＰに基づくコンテンツストリームがアクセスネットワーク１５２を介してプロトコル変換ゲートウェイ２０１に送信される。

プロトコル変換ゲートウェイ２０１では、ＩＰＴＶサーバ１５１からのコンテンツストリームを、ＩＰＴＶクライアント２２１が取得する。ＩＰＴＶクライアント２２１は、取得されたコンテンツストリームから、オーディオデータをデコードしたり、ビデオデータをデコードしたりする。デコードされたオーディオデータとビデオデータは、ＤＬＮＡサーバ２３１に供給される。

ＤＬＮＡサーバ２３１では、供給されたオーディオデータとビデオデータを、ＤＬＮＡのプロトコルに基づくフォーマットのＨＴＴＰストリーミングプロトコルのデータに変換し、ホームネットワーク１５４を介してＤＬＮＡクライアントであるエンドデバイス１３１に送信する。エンドデバイス１３１は、ＤＬＮＡクライアントであるため、ＤＬＮＡに基づくフォーマットのデータを取得し、再生することができる。

このように、ＩＰＴＶサーバ１５１からストリーミングされるコンテンツは、ＩＰＴＶサービス固有のフォーマットとプロトコル、例えばＨＴＴＰ、RTSP/RTP、IGMPなどでストリーミングされる。またストリーミングされるコンテンツは、ＩＰＴＶサービスを提供するＩＰＴＶサーバ１５１から、アクセスネットワーク１５２を介して提供される。

そして、プロトコル変換ゲートウェイ２０１では、ＩＰＴＶサーバ１５１からＩＰＴＶサービス固有プロトコルによりストリーミング取得したＩＰＴＶサービス固有フォーマットのコンテンツを、ＤＬＮＡに基づくフォーマットのＨＴＴＰストリーミングプロトコルに変換して、ＤＬＮＡクライアントであるエンドデバイス１３１にストリーミングする。

ＤＬＮＡクライアントは、ＤＬＮＡにより規定されたストリーミングプロトコル(ＤＬＮＡのＨＴＴＰストリーミング)を利用して、ゲートウェイに実装されるＤＬＮＡサーバ２３１からコンテンツをストリーミング取得し、再生する機能を有する。よって、エンドデバイス１３１は、ＳＴＢ１５５が接続されていなくても、ＩＰＴＶサーバ１５１からの番組を再生することができる。

図９、図１０に示した形態のように、家庭内のコンテンツサーバとコンテンツクライアント間でのプロトコルであるＤＬＮＡを、様々なプロバイダ独自ＩＰＴＶプロトコルに対して共通のインターフェイスとして、本実施の形態では、プロトコル変換ゲートウェイ２０１に設けた。このことにより、テレビジョン受像機などのエンドデバイス１３１においては、プロバイダ毎の独自ＩＰＴＶプロトコルを実装する必要がなくなる。

また、エンドデバイス１３１の追加毎にＳＴＢ１５５を追加、提供する必要がなくなり、プロバイダにとっても、STB１５５のメンテナンスコストを低減することができるというメリットがある。さらに、後述するように、プロバイダ毎に異なるＩＰＴＶサービスのコンテンツ探索と、ホームネットワーク内のコンテンツ探索を、同じＤＬＮＡの枠組みの中で統一して行うことができ、ユーザのコンテンツ探索の利便性を向上させることが可能となる。

このように、ＤＬＮＡを用いて、ＩＰＴＶサービスを受ける場合、図１０を参照して説明したように、プロトコル変換ゲートウェイ２０１による変換が行われる。すなわち、ＩＰＴＶサービス固有フォーマットのコンテンツを、ＤＬＮＡの規格に基づくフォーマットにトランスコードする。このトランスコードの際に、ＩＰＴＶサービス固有のDRM（コンテンツ保護）等を解いて、コンテンツを一旦デコードし、ビデオデータやオーディオデータを、バッファ上に展開し、再度、ＤＬＮＡ規定のストリーミングフォーマットにエンコードされる。

このコンテンツのデコード時に、バッファ上に展開されたコンテンツを汎用ＡＣＲクライアント１２１（図６）に通して、ＡＣＲ用の特徴量（サンプルデータ、シグニチャ）を生成し、ＡＣＲサーバ１３でコンテンツの特定が行われるようにすることができる。また、特定されたコンテンツのメタデータを取得し、プロトコル変換先のエンドデバイス１３１にて利用可能な方式で提供することにより、異なる複数のＡＣＲサービスの違いを意識せずに、かつ、エンドデバイス１３１に異なる複数のＡＣＲクライアントを実装することなく、ＡＣＲサービスを利用した、メタデータ、関連アプリケーション配信を実現することができる。

そこで、以下に、ＩＰＴＶクライアント２２１で行われるデコードの結果を用いたＡＣＲについて説明を行う。

なお、以下に説明する処理の流れなどは一例であり、限定を示すものではない。よって例えば、ＡＣＲクライアント側でリファレンスとなるシグニチャのマッチングに必要なデータベースを、ＡＣＲサーバ側からダウンロードして、サンプルのコンテンツから抽出されたシグニチャとのマッチングそのものをクライアント側で行う場合等もありえる。

［システムの構成について］
ここで、ＤＬＮＡを用いて汎用ＡＣＲクライアント１２１を実現する際のシステムの構成例について、図１１を参照して説明する。

図１１に示したシステムは、アクセスネットワーク１５２に、ＡＣＲサーバ１３、ＩＰＴＶサーバ１５１、およびメタデータサーバ３０１が接続されている。また、アクセスネットワーク１５２には、プロトコル変換ゲートウェイ２０１が接続されている。このプロトコル変換ゲートウェイ２０１を境に、通常、家庭内と家庭外に分けられる。

家庭内においては、ホームネットワーク１５４を介して、プロトコル変換ゲートウェイ２０１とエンドデバイス１３１が相互にデータの授受を行えるように構成されている。なお、図１１においては、エンドデバイス１３１は、１台しか図示していないが、複数存在していても勿論良い。また、図１１においては、ＡＣＲサーバ１３、ＩＰＴＶサーバ１５１、およびメタデータサーバ３０１も、それぞれ１台しか図示していないが、複数存在していても勿論良い。

［プロトコル変換ゲートウェイの構成について］
図１２は、図１１に示したプロトコル変換ゲートウェイ２０１の内部構成を示す図である。プロトコル変換ゲートウェイ２０１は、ＩＰＴＶサーバ１５１とのデータの授受を行うＩＰＴＶクライアント２２１、ＡＣＲサーバ１３とデータの授受を行う汎用ＡＣＲクライアント１２１、およびエンドデバイス１３１とデータの授受を行うＤＬＮＡサーバ２３１を含む構成とされている。

なお、以下の説明においては、図１２に示したプロトコル変換ゲートウェイ２０１を例にあげて説明を続けるが、より詳細には、ＩＰＴＶクライアント２２１は、図９に示したように、複数のＩＰＴＶクライアント、例えば、ＩＰＴＶクライアント２２１―１乃至２２１―３から構成される。また、汎用ＡＣＲクライアント１２１も、図６に示したように、複数のＡＣＲクライアント、例えば、ＡＣＲクライアント１０１−１乃至１０１−３間を橋渡しする機能を有し、プロトコル変換ゲートウェイ２０１は、ＡＣＲクライアント１０１−１乃至１０１−３も含まれる構成とされる。

ここでは汎用ＡＣＲクライアント１２１が処理を行うとして説明を続けるが、適宜、ＡＣＲクライアント１０１と連動した処理を行うことで、以下に説明する処理が行われる。

例えば、ＩＰＴＶクライアント２２１から供給されるオーディオデータやビデオデータの供給を受け、コンテンツを同定するための特徴量などのデータを抽出し、ＡＣＲサーバ１３に問い合わせを行う処理は、以下の説明では、汎用ＡＣＲクライアント１２１が代表して行うとして説明を行い、そのように構成することが可能である。

しかしながら、ＡＣＲクライアント１０１−１乃至１０１−３が、それぞれ特徴量などのデータを抽出し、ＡＣＲサーバ１３−１乃至１３−３にそれぞれ問い合わせを行い、その問い合わせ結果を、汎用ＡＣＲクライアント１２１が受け取り、処理をするという構成にすることも可能である。

また、汎用ＡＣＲクライアント１２１の指示に基づき、ＡＣＲクライアント１０１−１乃至１０１−３のいずれかのＡＣＲクライアント１０１が、特徴量などのデータを抽出し、ＡＣＲサーバ１３に問い合わせを行い、その問い合わせ結果を、汎用ＡＣＲクライアント１２１が受け取り、処理をするという構成にすることも可能である。

このように、図１２においては図示していないが、汎用ＡＣＲクライアント１２１とＡＣＲクライアント１０１は、連動して処理を実行する。

図１２に示したプロトコル変換ゲートウェイ２０１が行う処理の詳細は、後述するが、基本的な処理としては、ＩＰＴＶクライアント２２１によりコンテンツストリームが受信され、デコードされる。ＩＰＴＶクライアント２２１によりデコードされたコンテンツは、汎用ＡＣＲクライアント１２１とＤＬＮＡサーバ２３１に供給される。

汎用ＡＣＲクライアント１２１は、デコードされたコンテンツから、ＡＣＲサーバ１３がコンテンツの同定を行うときに必要とするデータ（特徴量などのデータ）を抽出し、ＡＣＲサーバ１３に送信する。また、汎用ＡＣＲクライアント１２１は、ＡＣＲサーバ１３からの同定結果を受信した場合、ＤＬＮＡサーバ２３１を介してエンドデバイス１３１に対して受信された同定結果を供給する。

なお、図１２に示したプロトコル変換ゲートウェイ２０１においては、汎用ＡＣＲクライアント１２１からのデータは、ＤＬＮＡサーバ２３１に供給され、ＤＬＮＡサーバ２３１からエンドデバイス１３１に供給される構成としているが、汎用ＡＣＲクライアント１２１とエンドデバイス１３１が、ＤＬＮＡサーバ２３１を介さずに直接的にデータの授受を行えるように構成することも可能である。

図１２に示したプロトコル変換ゲートウェイ２０１においては、エンドデバイス１３１との通信は、ＤＬＮＡサーバ２３１により行われる。すなわち、ＤＬＮＡサーバ２３１は、エンドデバイス１３１と通信を行い、エンドデバイス１３１とのデータの処理を行う。また具体的には、汎用ＡＣＲクライアント１２１またはＩＰＴＶクライアント２２１からのデータを、ＤＬＮＡに基づくフォーマットのデータに変換し、エンドデバイス１３１に供給する処理を行う。

［メタデータの蓄積について］
次に、図１１に示したシステムにおける処理について説明する。まず、ＡＣＲサーバ１３のメタデータの蓄積に係わる処理について図１３のフローチャートを参照して説明する。ＡＣＲサーバ１３は、ＩＰＴＶサーバ１５１で放送されている番組を受信し、番組（コンテンツ）を特定するためのリファレンスデータを蓄積するとともに、メタデータサーバ３０１で蓄積されているメタデータを取得し、蓄積する。ＡＣＲサーバ１３は、蓄積しているメタデータを、汎用ＡＣＲクライアント１２１からの要求に応じて提供する。

ＡＣＲサーバ１３は、メタデータを供給できるように、リファレンスデータの蓄積とメタデータの蓄積を行っている。その蓄積に関する処理について説明する。

ステップＳ１１において、ＩＰＴＶサーバ１５１は、ストリームの送信を行う。このストリームの送信は、継続的に行われる。ＩＰＴＶサーバ１５１からのストリームは、アクセスネットワーク１５２を介して、ステップＳ２１において、ＡＣＲサーバ１３に受信される。ＡＣＲサーバ１３は、ステップＳ２２において、特徴量の抽出と蓄積を行う。ＡＣＲサーバ１３は、所定のプロトコルに基づき、ストリームから抽出されるオーディオデータやビデオデータから、コンテンツを特定するためのデータを生成する。

例えば、所定のタイミングでオーディオデータがサンプリングされ、そのときのオーディオデータが特徴量とされる。また例えば、所定のタイミングでサンプリングされるビデオデータに基づく画像から、輝度の特徴量が抽出され、特徴量とされる。どのような特徴量が抽出、生成されるかは、プロバイダがどのようなプロトコルに基づいて特徴量を抽出、生成するかに依存する。また、ウォータマークやフィンガープリントなどのシグニチャでも良い。

特徴量は、ＡＣＲサーバ１３のコンテンツ属性データベース６３（図４）に蓄積される。ＡＣＲサーバ２２は、特徴量を抽出したコンテンツ（例えば、放送番組）の放送時間や放送されているチャンネルは認識している。この放送時間とチャンネルにより一意に番組を特定することができる。そこで、ステップＳ２３において、チャンネルと放送時間の情報が、メタデータサーバ３０１に対して、アクセスネットワーク１５２を介して送信される。

メタデータサーバ３０１は、ステップＳ３１において、ＡＣＲサーバ１３からのチャンネルと放送時間の情報を受信すると、ステップＳ３２において、該当するコンテンツ（番組）を特定し、そのコンテンツに関するメタデータを検出し、ＡＣＲサーバ１３に対して送信する。メタデータサーバ３０１には、予め、コンテンツと関連付けられてメタデータが管理されている。なお、ここでは、“該当するコンテンツ（番組）を特定する”としたが、チャンネルと放送時間の情報から一意に特定できるメタデータが検出されるように構成されていても良く、コンテンツの特定は必須ではない。

ステップＳ２４において、ＡＣＲサーバ１３は、メタデータサーバ３０１からのメタデータを受信し、ステップＳ２５において、受信したメタデータを、他のデータと関連付けてコンテンツ属性データベース６３に蓄積する。

図１４は、このようなメタデータサーバ３０１とのやりとりが繰り返されることでデータが蓄積されるＡＣＲサーバ１３のコンテンツ属性データベース６３に蓄積されるリファレンスデータについて説明するための図である。図１４に示したＡＣＲサーバ１３のコンテンツ属性データベース６３内の１つのリファレンスデータ３２１は、特徴量、コンテンツ識別子、再生時刻、メタデータが関連付けられたデータとされている。

特徴量は、ステップＳ２２において抽出された特徴量であり、輝度などの特徴量や、ウォータマークやフィンガープリントなどのシグニチャなどである。コンテンツ識別子は、コンテンツを一意に識別するために割り振られた識別子であり、例えば、メタデータサーバ３０１からメタデータの１情報として供給される。

再生時刻は、コンテンツの開始からの相対時刻、または絶対時刻である。メタデータは、ステップＳ２４おいて受信されたメタデータサーバ３０１から供給されるメタデータである。このメタデータは、コンテンツ識別子が同じコンテンツであっても再生時刻が異なれば異なるメタデータとなる可能性がある。

このようなリファレンスデータ３２１が、ＡＣＲサーバ１３において生成され、蓄積されている。このようなリファレンスデータが蓄積されているという前提で、以下の説明を続ける。

［コンテンツ、メタデータの供給に関わる処理について］
次に、図１５のフローチャートを参照し、図１１に示したシステムと、図１２に示したプロトコル変換ゲートウェイ２０１において実行される処理について説明する。図１５に示したフローチャートは、ユーザが所定のコンテンツ（番組）を視聴しているときに、その番組に付随する情報（メタデータ）を視聴したいと所望したときに対応できる処理である。

ステップＳ１０１において、エンドデバイス１３１でコンテンツの選択が行われる。例えば、エンドデバイス１３１としてテレビジョン受像器である場合、ユーザが、テレビジョン受像器のリモートコントローラを操作して、視聴したい所望の番組（コンテンツ）を選択する。その選択されたチャンネルの情報は、プロトコル変換ゲートウェイ２０１のＤＬＮＡサーバ２３１に、ホームネットワーク１５４を介して供給される。エンドデバイス１３１とＤＬＮＡサーバ２３１の間のデータの授受は、ＤＬＮＡに基づくフォーマット形式で行われる。

ステップＳ１２１において、エンドデバイス１３１からのチャンネル情報を取得したＤＬＮＡサーバ２３１は、その情報をＩＰＴＶクライアント２２１に供給する。ＩＰＴＶクライアント２２１は、ステップＳ１６１において、供給されたチャンネル情報を、ＩＰＴＶプロトコルに基づくデータに変換し、アクセスネットワーク１５２を介して、ＩＰＴＶサーバ１５１に対して送信する。

ＩＰＴＶサーバ１５１は、ステップＳ２０１において、チャンネル情報を取得すると、そのチャンネルで放送されているコンテンツのストリームが送信される。この送信は、継続的に行われる。ＩＰＴＶサーバ１５１から送信されるコンテンツのストリームは、アクセスネットワーク１５２を介してプロトコル変換ゲートウェイ２０１のＩＰＴＶクライアント２２１に供給される。ＩＰＴＶサーバ１５１とＩＰＴＶクライアント２２１との間は、ＩＰＴＶプロトコルに基づくデータが授受される。

ステップＳ１６２において、ＩＰＴＶ１５１からのストリームを受信したＩＰＴＶクライアント２２１は、ステップＳ１６３においてデコードを開始し、汎用ＡＣＲクライアント１２１とＤＬＮＡサーバ２３１に供給する。ＩＰＴＶクライアント２２１によるデコード処理により、ビデオデータとオーディオデータがデコードされる。デコードされたビデオデータとオーディオデータは、ステップＳ１４１において、汎用ＡＣＲクライアント１２１に取得され、ステップＳ１２２において、ＤＬＮＡサーバ２３１に取得される。

ステップＳ１２３において、ＤＬＮＡサーバ２３１は、供給されたビデオデータとオーディオデータを、ＤＬＮＡに基づくフォーマットのＨＴＴＰストリーミングプロトコルに変換（エンコード）し、エンドデバイス１３１に、ホームネットワーク１５４を介して送信する。この変換は、図１０などを参照して説明したように行われる。

エンドデバイス１３１は、ステップＳ１０２において、ＤＬＮＡサーバ２３１からエンコードされたオーディオデータやビデオデータを受信する。この受信されたオーディオデータに基づく音声と、ビデオデータに基づく映像のユーザへの提供が、ステップＳ１０３において、エンドデバイス１３１により行われる。このようにして、コンテンツがユーザに提供される。このようなＩＰＴＶクライアント２２１によりデコード、ＤＬＮＡサーバ２３１によるエンコード、エンドデバイス１３１により再生が継続的に繰り返されることで、ユーザにコンテンツが提供される。

このようなＩＰＴＶサーバ１５１からのコンテンツスが、エンドデバイス１３１によりユーザに提供される一連の処理が実行されている一方で、汎用ＡＣＲクライアント１２１では、ユーザが視聴しているコンテンツに付随する情報（メタデータ）の取得に係わる処理が実行されている。すなわち、ステップＳ１４２において、特徴量の抽出が行われる。

ステップＳ１４１において、汎用ＡＣＲクライアント１２１は、ＩＰＴＶクライアント２２１によりデコードされたオーディオデータやビデオデータを取得している。汎用ＡＣＲクライアント１２１は、デコードされたオーディオデータやビデオデータから、所定のプロトコルに基づいて特徴量を抽出する。特徴量は、ＡＣＲサーバ１３がコンテンツを同定する際に用いる特徴量と同じである必要があり、ＡＣＲサーバ１３が、例えば、画面から輝度の特徴量を抽出する場合には、汎用ＡＣＲクライアント１２１も、画面から輝度の特徴量を抽出する。また、特徴量として、ウォータマークやフィンガープリントといたシグニチャが用いられても良い。

ステップＳ１４３において、汎用ＡＣＲクライアント１２１は、ＡＣＲクエリーを生成し、ＡＣＲサーバ１３に対して送信する。図１６は、生成されるＡＣＲクエリーの一例を示す図である。ＡＣＲクエリー３５１には、ＡＣＲクエリー識別子、方式識別子、サービス識別子、特徴量、ローカルタイムスタンプ、発信元(返信先)アドレス、署名が含まれる。

ＡＣＲクエリー識別子は、必要がある場合に記載され、このＡＣＲクエリーを一意に識別する識別子である。方式識別子は、このＡＣＲクエリーに格納される特徴量、シグニチャ(ウォータマークもしくはフィンガープリント)の方式を表す識別子である。サービス識別子は、必要がある場合に記載され、ＡＣＲサービス(ＡＣＲによってコンテンツ同定を行うサービス)の識別子である。

特徴量は、特徴量やシグニチャ（抽出されたウォータマークもしくはフィンガープリント）である。ローカルタイムスタンプは、特徴量を抽出した時点のローカルシステムクロックの値である。発信元(返信先)アドレスは、必要がある場合に記載され、このＡＣＲクエリーに対する返答を戻すＡＣＲクライアントのアドレスである。署名は、必要がある場合に記載され、改ざん防止等のための署名である。必要であればＡＣＲクエリー全体が暗号化されるようにしても良い。

このようなデータを含むＡＣＲクエリーが、ステップＳ１４３において、汎用ＡＣＲクライアント１２１により生成され、ＡＣＲサーバ１３に対して送信される。

ＡＣＲサーバ１３は、ステップＳ１８１において、ＡＣＲクエリーを受信すると、そのＡＣＲクエリーに含まれるデータに基づき、コンテンツの同定を行う。ＡＣＲサーバ１３は、ステップＳ１８２において、ＡＣＲクエリーを受信すると、まずＡＣＲの方式識別子を見て、データベース内のＡＣＲリファレンスデータのＡＣＲ方式識別子とマッチング処理を行う。対応するＡＣＲ方式である場合、ＡＣＲクエリーに格納されている特徴量（シグニチャ (ウォータマーク/フィンガープリント)）により、データベースを検索してマッチングを行う。

マッチングのアルゴリズムは方式に依存し、この方式に依存するマッチングのアルゴリズムがＡＣＲサーバ１３には実装されている。ヒットした場合、解決されたコンテンツ識別子、再生時刻、関連するメタデータをＡＣＲレスポンスとして、ＡＣＲクエリーに格納されているＡＣＲクエリーの発行元ＡＣＲクライアントのアドレスに返答する。このとき、ＡＣＲクエリーに格納されているローカルタイムスタンプの値をもとにＡＣＲレスポンスに格納する関連するメタデータを選択するものとする。ヒットしなければ、ＡＣＲクエリーの発信元に対してヒットしなかった旨の返答をＡＣＲレスポンスとして返す。

ＡＣＲサーバ１３は、ステップＳ１８２、ステップＳ１８３において、コンテンツの同定、ＡＣＲレスポンスの生成、ＡＣＲレスポンスの送信を行う。ここで、生成され、送信されるＡＣＲレスポンスの一例を、図１７と図１８に示す。図１７は、該当するメタデータがヒットしたときのＡＣＲレスポンスであり、図１８は、該当するメタデータがヒットしなかったときのＡＣＲレスポンスである。

図１７を参照するに、該当するメタデータがヒットしたときのＡＣＲレスポンスには、ＡＣＲクエリー識別子、方式識別子、サービス識別子、コンテンツ識別子、再生時刻、ローカルタイムスタンプ、関連メタデータ、発信元アドレス、署名が含まれる。

ＡＣＲクエリー識別子は、必要がある場合に記載され、この返答のもとになるＡＣＲクエリーに格納されていた識別子である。方式識別子は、必要がある場合に記載され、対応するＡＣＲクエリーに格納されていた特徴量（シグニチャ(ウォータマークもしくはフィンガープリント)）の方式を識別するための識別子である。

サービス識別子は、必要がある場合に記載され、ＡＣＲサービス(ＡＣＲによってコンテンツ同定を行うサービス)の識別子である。コンテンツ識別子は、必要がある場合に記載され、認識されたコンテンツの識別子である。再生時刻は、このコンテンツの開始からの相対時刻、もしくは絶対時刻である。ローカルタイムスタンプは、必要がある場合に記載れ、特徴量を抽出（シグニチャを生成）した時点のローカルシステムクロックの値である。

関連メタデータは、その他の、このコンテンツやチャネルに関する関連メタデータである。この関連メタデータは、再生時刻毎に異なる場合がある。発信元アドレスは、必要がある場合に記載され、このＡＣＲレスポンスのＡＣＲサーバ１３のアドレスである。署名は、必要がある場合に記載され、改ざん防止等のための署名である。必要であればＡＣＲレスポンス全体が暗号化される場合もある。

図１８を参照するに、該当するメタデータがヒットしなかったときのＡＣＲレスポンスには、ＡＣＲクエリー識別子、サービス識別子、認証失敗フラグ、発信元アドレス、署名が含まれる。

ＡＣＲクエリー識別子は、この返答のもとになるＡＣＲクエリーに格納されていた識別子である。サービス識別子は、必要がある場合、ＡＣＲサービス(ＡＣＲによってコンテンツ同定を行うサービス)を識別するための識別子である。認識失敗フラグは、認識に失敗したことを示すフラグである。発信元アドレスは、このＡＣＲレスポンスのＡＣＲサーバのアドレスである。署名は、改ざん防止等のための署名である。必要であればＡＣＲレスポンス全体が暗号化される場合もある。

ステップＳ１８３（図１５）において、ＡＣＲサーバ１３によりＡＣＲレスポンスが生成され、送信されると、ステップＳ１４４において、汎用ＡＣＲクライアント１２１（図１２）に受信される。ここでは、図１７に示したＡＣＲレスポンスが取得されるとし、メタデータが取得されるとして説明を続ける。図１８に示したＡＣＲレスポンスが取得された場合、他のＡＣＲサーバ１３に再度問い合わせを行うといった処理が行われ、メタデータが取得されるように構成することも本実施の形態においては可能である。

汎用ＡＣＲクライアント１２１は、ステップＳ１４５において、受信されたＡＣＲレスポンスに含まれるメタデータを抽出し、ＤＬＮＡサーバ２３１に供給する。ＤＬＮＡサーバ２３１は、ステップＳ１２４において、供給されたメタデータを取得すると、ステップＳ１２５において、エンドデバイス１３１に対してメタデータを転送する。

転送されたメタデータは、ステップＳ１０４において、エンドデバイス１３１に取得され、ステップＳ１０５において、ユーザに提示される。このようにして、コンテンツに付随する情報が、ユーザに対して提示される。

ここで、ＤＬＮＡサーバ２３１がステップＳ１２５において実行するメタデータの転送に係わる処理について、図１９を参照して説明する。メタデータをＤＬＮＡに対応しているＤＬＮＡクライアント（エンドデバイス１３１）に供給する場合、ＤＬＮＡプロトコルにて規定されているＣＤＳ(Content Directory Service)を利用することができる。また、メタデータの内容そのものを、ＣＤＳフォーマットに変換することで、エンドデバイス１３１にメタデータを供給することができる。

すなわち、図１９に示したように、ＤＬＮＡサーバ２３１は、汎用ＡＣＲクライアント１２１から供給されるメタデータを、ＣＤＳで規定されたフォーマットに変換し、ＣＤＳプロトコルによりエンドデバイス１３１（ＤＬＮＡクライアント）に提供する。

エンドデバイス１３１側は、ＣＤＳで規定されたフォーマットで変換されたメタデータを取得し、再生することで、ユーザにメタデータを提供する。メタデータがコンテンツの内容に関する情報であった場合、ストーリーや登場人物などの情報がユーザに提供される。またメタデータが、関連するアプリケーションの実行を指示するような内容であった場合、その指示されているアプリケーションが実行され、そのアプリケーションによる処理が行われる。

図２０に示すように、Ｗｅｂサーバを用いる形態でも良い。図２０に示した場合、まずＤＬＮＡサーバ２３１は、汎用ＡＣＲクライアント１２１からのメタデータそのものを、ＨＴＭＬドキュメントに変換する。ＨＴＭＬドキュメントとしては、例えば、Javascript（登録商標）等のクライアントサイドスクリプトが適用できる。ＨＴＭＬドキュメントは、Ｗｅｂサーバ４０１に供給される。

ＤＬＮＡサーバ２３１は、ＨＴＭＬドキュメントへの変換処理を行うともに、ＣＤＳフォーマットで、Ｗｅｂサーバ４０１のＷｅｂドキュメントのURLを格納し、ＤＬＮＡクライアント（エンドデバイス１３１）に提供する。エンドデバイス１３１は、そのURLをもとにWebAPIを介してＷｅｂサーバ４０１からメタデータを取得する。このＨＴＭＬドキュメントを提供するWebサーバ４０１は、プロトコル変換ゲートウェイ２０１上に置くことが可能である。または、プロトコル変換ゲートウェイ２０１とは別のＤＬＮＡクライアントであるエンドデバイス１３１がアクセスできるネットワーク上に設置されていても良い。

図２１は、プロトコル変換ゲートウェイ２０１内にＷｅｂサーバが設けられている場合である。図２１に示したプロトコル変換ゲートウェイ２０１には、Ｗｅｂサーバ４２１が含まれている。このような構成の場合、ＤＬＮＡサーバ２３１は、汎用ＡＣＲクライアント１２１から取得したメタデータをＨＴＭＬドキュメント（Javascript（登録商標）等のクライアントサイドスクリプト）に変換し、Ｗｅｂサーバ４２１に供給し、Ｗｅｂサーバ４２１からWebAPIによりＤＬＮＡクライアント（エンドデバイス１３１）にメタデータが提供される。

このように、エンドデバイス１３１にメタデータが供給される。このようなことが可能となることで、例えば、ユーザがエンドデバイス１３１で、動画投稿サイトに投稿された動画を見ていたときに、その動画に対してもメタデータを提示することが可能となる。その動画が、例えば、放送されていた番組の動画であった場合、汎用ＡＣＲクライアント１２１とＡＣＲサーバ１３との処理により、番組が特定され、その特定された番組のメタデータが取得される。よって、ユーザにそのような動画投稿サイトに投稿された動画に対しても何らかの情報を提示することが可能となる。

［コンテンツ、メタデータの供給に関わる他の処理について］
図１５を参照して説明した処理は、プロトコル変換ゲートウェイ２０１からＤＬＮＡクライアントであるエンドデバイス１３１に対してコンテンツがストリーミングされると同時に、そのコンテンツに関連するメタデータや関連するアプリケーションが提示される際の処理例であった。

次に、ＤＬＮＡサーバ２３１から提供されるメタデータを基にしてクライアント側（エンドデバイス１３１側）でコンテンツ選択のメニューを提示し、そのメニューからコンテンツが選択され、ストリーミングが始まるケースについて説明する。なお、図１５に示したフローチャートの処理と基本的に同様の処理を含むので、図１５に示したフローチャートと同様の処理に関しては適宜説明を省略する。

ステップＳ３０１において、ＩＰＴＶサーバ１５１からストリームの送信が継続的に行われる。そのストリームを、ステップＳ３４１の処理として受信したＩＰＴＶクライアント２２１は、ステップＳ３４１において、受信したストリームをデコードし、オーディオデータやビデオデータを生成し、汎用ＡＣＲクライアント１２１に供給する。

ステップＳ３６１において、汎用ＡＣＲクライアント１２１は、ＩＰＴＶクライアント２２１からのオーディオデータやビデオデータを取得し、ステップＳ３６２において、特徴量（シグネチャ）を抽出する。また、ステップＳ３６３において、ＡＣＲクエリーを生成し、ＡＣＲサーバ１３に送信する。

ステップＳ３２１において、ＡＣＲサーバ１３は、汎用ＡＣＲクライアント１２１からのＡＣＲクエリーを受信すると、ステップＳ３２２において、コンテンツの同定を行い、その同定結果をＡＣＲレスポンスで返信する。ここでは、同定されたコンテンツがあり、メタデータが送信されるとして説明を続ける。

ステップＳ３６４において、汎用ＡＣＲクライアント１２１は、ＡＣＲレスポンスを受信すると、ステップＳ３６５において、ＤＬＮＡサーバ２３１にメタデータを供給する。例えば、このような処理を繰り返し、複数のＩＰＴＶサーバ１３から、複数のコンテンツに関するメタデータを取得すると、その時点で、放送されている番組に関するメタデータを複数取得できる。そのような複数取得されたメタデータを用いて番組表を作成し、ユーザに提供することが可能となる。

ここでは例えば、そのような番組表が、汎用ＡＣＲクライアント１２１により作成され、ユーザに提供されるとして説明を続ける。ステップＳ３８２においては、ＤＬＮＡサーバ２３１から、番組表がエンドデバイス１３１に対して転送される。そのような番組表を、ステップＳ４０１において受信したエンドデバイス１３１は、ステップＳ４０２において、メタデータの提示、この場合、番組表の提示を行う。

ユーザは、番組表を見て、コンテンツの選択を行うことができる。この番組表は、上記したように、複数の異なるＩＰＴＶサーバ１３から取得されるコンテンツから作成されている。よって、ユーザからは、あたかも１つの番組表であっても、本来、それぞれ異なる番組表として提供される番組表である。

換言すれば、従来、ＩＰＴＶサーバ１３毎にしか番組表を提供することができなかったため、複数のＩＰＴＶサーバ１３から提供されるコンテンツを検索する場合など、それぞれのＩＰＴＶサーバ１３毎に検索を行わなくてはならず、使い勝手が悪かった。しかしながら、本技術を適用することで、複数のＩＰＴＶサーバ１３から提供されるコンテンツの１つの番組表を提供することが可能となり、使い勝手を向上させることが可能となる。

ユーザが、番組表からコンテンツを選択すると、その情報は、ＤＬＮＡサーバ２３１に供給される。この後の処理は、図１５のフローチャートを参照して説明した場合と同様であるので、その説明は省略する。

このように、ユーザは、複数のＩＰＴＶサーバ１３から供給されているコンテンツであることを意識すること無く、複数のＩＰＴＶサーバ１３から供給されるコンテンツから所望のコンテンツを選択し、視聴することが可能となる。

なお、ここでは番組表を例にあげて説明したが、番組表に限定されるわけではない。汎用ＡＣＲクライアント１２１は、ＡＣＲクライアント１０１がそれぞれＡＣＲサーバ１３から取得した同定されたコンテンツに関する情報を取得する。この時点では、汎用ＡＣＲクライアント１２１は、複数の情報を取得したことになる。

汎用ＡＣＲクライアント１２１は、取得した複数の情報を、番組表などと同じく、１つの情報にまとめ、他の情報を生成する。換言すれば、汎用ＡＣＲクライアント１２１は、複数の情報を一括した情報を生成する。その生成された情報が、エンドデバイス１３１に供給されるようにすることができる。このような情報がユーザに提供されることで、本来なら、複数の情報として提示される情報を１つの情報としてまとめて見ることができるようになるため、使い勝手の向上につながる。

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

図２３は、上述した一連の処理をプログラムにより実行するコンピュータのハードウエアの構成例を示すブロック図である。コンピュータにおいて、ＣＰＵ（Central Processing Unit）１００１、ＲＯＭ（Read Only Memory）１００２、ＲＡＭ（Random Access Memory）１００３は、バス１００４により相互に接続されている。バス１００４には、さらに、入出力インターフェイス１００５が接続されている。入出力インターフェイス１００５には、入力部１００６、出力部１００７、記憶部１００８、通信部１００９、及びドライブ１０１０が接続されている。

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

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

コンピュータ（ＣＰＵ１００１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア１０１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の伝送媒体を介して提供することができる。

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

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

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

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

なお、本技術は以下のような構成も取ることができる。

（１）
コンテンツの同定を行う第１の装置とのデータを処理する第１の処理部と、
前記コンテンツの再生を行う第２の装置とのデータを処理し、前記第１の処理部とのデータの処理を行う第２の処理部と
を備える情報処理装置。
（２）
前記コンテンツの前記同定は、ＡＣＲ（Automatic Content Recognition）に基づき行われ、
前記第１の装置は、ＡＣＲサーバであり、
前記第１の処理部は、異なるプロトコルで前記ＡＣＲを行う複数のＡＣＲサーバとそれぞれ通信を行うＡＣＲクライアントとして機能する
前記（１）に記載の情報処理装置。
（３）
前記第１の装置と前記第２の装置との間に設けられるゲートウェイ内に設けられる
前記（１）または前記（２）に記載の情報処理装置。
（４）
前記コンテンツは、第３の装置から、ＩＰブロードバンドネットワーク経由で伝送され、
前記第３の装置とのデータの処理を行う第３の処理部をさらに備える
前記（１）乃至（３）のいずれかに記載の情報処理装置。
（５）
前記第３の処理部は、受信された前記コンテンツをデコードし、
前記第１の処理部は、デコードされた前記コンテンツから前記第１の装置が同定を行うときに必要とするデータを抽出し、前記第１の装置に送信し、
前記第１の装置から、前記同定の結果を受信した場合、前記第１の処理部は、前記第２の処理部に前記結果を供給し、前記第２の処理部は、前記第２の装置に、前記結果を供給する
前記（４）に記載の情報処理装置。
（６）
前記第２の装置と、ＤＬＮＡ（Digital Living Network Alliance）に基づくデータの処理を行う第４の処理部をさらに備え、
前記第４の処理部は、
前記第２の処理部からの前記結果を、ＤＬＮＡに基づくフォーマットに変換し、
前記第３の処理部からの前記コンテンツを、ＤＬＮＡに基づくフォーマットに変換する
前記（５）に記載の情報処理装置。
（７）
前記第２の処理部は、前記複数のＡＣＲサーバのそれぞれから、同定されたコンテンツの情報を取得し、取得された複数の情報を一括した情報を生成し、その情報を前記第２の装置に供給する
前記（２）に記載の情報処理装置。
（８）
第１の装置とのデータを処理する第１の処理部と、
第２の装置または前記第１の処理部とのデータの処理を行う第２の処理部と
を備える情報処理装置の情報処理方法において、
前記第１の処理部は、
コンテンツの同定を行う前記第１の装置と通信を行い、通信により授受されるデータを処理するステップを含み、
前記第２の処理部は、
前記コンテンツの再生を行う第２の装置との通信を行い、通信により授受されるデータを処理し、
前記第１の処理部とのデータの処理を行う
ステップを含む
情報処理方法。
（９）
第１の装置とのデータを処理する第１の処理部と、
第２の装置または前記第１の処理部とのデータの処理を行う第２の処理部と
を備える情報処理装置を制御するコンピュータに、
前記第１の処理部は、
コンテンツの同定を行う前記第１の装置と通信を行い、通信により授受されるデータを処理するステップを含み、
前記第２の処理部は、
前記コンテンツの再生を行う第２の装置との通信を行い、通信により授受されるデータを処理し、
前記第１の処理部とのデータの処理を行う
ステップを含む
処理を実行させるコンピュータ読み取り可能なプログラム。

１３ ＡＣＲサーバ， １２１ 汎用ＡＣＲクライアント， １３１ エンドデバイス， １５１ ＩＰＴＶサーバ， １５２ アクセスネットワーク， １５４ ホームネットワーク， ２２１ ＩＰＴＶクライアント， ２３１ ＤＬＮＡサーバ

Claims (17)

1. ＡＣＲ（Automatic Content Recognition）クライアントとして機能するように構成され、コンテンツの同定を行うための第１のプロトコルを使用する第１のＡＣＲサーバと通信し、コンテンツの同定を行うための第２のプロトコルを使用する少なくとも第２のＡＣＲサーバと通信する処理部を備え、
   前記第１のプロトコルと前記第２のプロトコルは異なり、
   前記処理部は、コンテンツサーバからコンテンツを受信し、前記コンテンツをオーディオデータ、および／または、ビデオデータにデコードするように構成され、
   前記オーディオデータ、および／または、前記ビデオデータからサンプルデータを抽出し、
   前記サンプルデータに基づいて前記コンテンツを識別するために、前記サンプルデータを前記第１のＡＣＲサーバに送信し、
   前記サンプルデータに基づいて前記コンテンツを識別するために、前記サンプルデータを前記第２のＡＣＲサーバに送信し、
   前記第１のＡＣＲサーバからコンテンツの第１の同定を受信し、前記第２のＡＣＲサーバからコンテンツの第２の同定を受信する
   情報処理装置。
2. 前記コンテンツの第１の同定と前記コンテンツの第２の同定は、ＡＣＲに基づく
   請求項１に記載の情報処理装置。
3. テレビジョンコンテンツ、ビデオコンテンツ、オーディオコンテンツ、またはデジタルコンテンツのうちの少なくとも１つを含むコンテンツを受信する
   請求項１または２に記載の情報処理装置。
4. 前記コンテンツは、ＩＰブロードバンドネットワーク経由で受信される
   請求項１乃至３のいずれかに記載の情報処理装置。
5. 前記第２のＡＣＲサーバからの結果を、ＤＬＮＡ（Digital Living Network Alliance）に基づくフォーマットに変換し、
   受信された前記コンテンツを、ＤＬＮＡに基づくフォーマットに変換する
   請求項１乃至４のいずれかに記載の情報処理装置。
6. 前記第２のＡＣＲサーバのそれぞれから同定されたコンテンツの情報を取得し、取得された前記情報を一括する
   請求項１乃至５のいずれかに記載の情報処理装置。
7. 前記第１のＡＣＲサーバと装置との間に設けられるゲートウェイ内に設けられる
   請求項１乃至６のいずれかに記載の情報処理装置。
8. テレビジョン受像機である
   請求項１乃至６のいずれかに記載の情報処理装置。
9. ＡＣＲ（Automatic Content Recognition）クライアントとして機能するように構成され、コンテンツの同定を行うための第１のプロトコルを使用する第１のＡＣＲサーバと通信し、コンテンツの同定を行うための第２のプロトコルを使用する少なくとも第２のＡＣＲサーバと通信する処理部を備える情報処理装置の情報処理方法において、
   前記第１のプロトコルと前記第２のプロトコルは異なり、
   前記処理部は、
   コンテンツサーバからコンテンツを受信し、前記コンテンツをオーディオデータ、および／または、ビデオデータにデコードし、
   前記オーディオデータ、および／または、前記ビデオデータからサンプルデータを抽出し、
   前記サンプルデータに基づいて前記コンテンツを識別するために、前記サンプルデータを前記第１のＡＣＲサーバに送信し、
   前記サンプルデータに基づいて前記コンテンツを識別するために、前記サンプルデータを前記第２のＡＣＲサーバに送信し、
   前記第１のＡＣＲサーバからコンテンツの第１の同定を受信し、前記第２のＡＣＲサーバからコンテンツの第２の同定を受信する
   ステップを含む情報処理方法。
10. 前記コンテンツの第１の同定と前記コンテンツの第２の同定は、ＡＣＲに基づく
    請求項９に記載の情報処理方法。
11. テレビジョンコンテンツ、ビデオコンテンツ、オーディオコンテンツ、またはデジタルコンテンツのうちの少なくとも１つを含むコンテンツを受信する
    請求項９または１０に記載の情報処理方法。
12. 前記コンテンツは、ＩＰブロードバンドネットワーク経由で受信される
    請求項９乃至１１のいずれかに記載の情報処理方法。
13. 前記第２のＡＣＲサーバからの結果を、ＤＬＮＡ（Digital Living Network Alliance）に基づくフォーマットに変換し、
    受信された前記コンテンツを、ＤＬＮＡに基づくフォーマットに変換する
    請求項９乃至１２のいずれかに記載の情報処理方法。
14. 前記第２のＡＣＲサーバのそれぞれから同定されたコンテンツの情報を取得し、取得された前記情報を一括する
    請求項９乃至１３のいずれかに記載の情報処理方法。
15. 前記第１のＡＣＲサーバと装置との間に設けられるゲートウェイ内に設けられる
    請求項９乃至１４のいずれかに記載の情報処理方法。
16. 前記情報処理装置は、テレビジョン受像器である
    請求項９乃至１５のいずれかに記載の情報処理方法。
17. コンピュータを、
    ＡＣＲ（Automatic Content Recognition）クライアントとして機能するように構成され、コンテンツの同定を行うための第１のプロトコルを使用する第１のＡＣＲサーバと通信し、コンテンツの同定を行うための第２のプロトコルを使用する少なくとも第２のＡＣＲサーバと通信する処理部を備え、
    前記第１のプロトコルと前記第２のプロトコルは異なり、
    前記処理部は、コンテンツサーバからコンテンツを受信し、前記コンテンツをオーディオデータ、および／または、ビデオデータにデコードするように構成され、
    前記オーディオデータ、および／または、前記ビデオデータからサンプルデータを抽出し、
    前記サンプルデータに基づいて前記コンテンツを識別するために、前記サンプルデータを前記第１のＡＣＲサーバに送信し、
    前記サンプルデータに基づいて前記コンテンツを識別するために、前記サンプルデータを前記第２のＡＣＲサーバに送信し、
    前記第１のＡＣＲサーバからコンテンツの第１の同定を受信し、前記第２のＡＣＲサーバからコンテンツの第２の同定を受信する
    情報処理装置における処理部として機能させるためのプログラム。

Images