JP2017514345A - 埋め込みコードを用いた対話型コンテンツ取得 - Google Patents

Abstract

マルチメディアコンテンツについて関連情報を取得するために方法及びデバイスが提供される。そのような方法の一つは、透かし検出器を備えた受信装置においてコンテンツを受信することと、埋め込まれた透かしのペイロードを抽出するために受信したコンテンツに透かし検出を行うことを含む。ペイロードは、サーバ識別子を含む第１のフィールドと、サーバ識別子と関連付けられたインターバル識別子を含む第２のフィールドを含む。第１のフィールドは、透かしペイロードによって識別されるコンテンツセグメントに関連付けられたメタデータを取得するためにアクセス可能なインターネットアドレスへのマッピングを提供する。この方法では、検出された透かしペイロードに基づいて、クエリが形成され、及びインターネットアドレスによって識別されるサーバに送信され、クエリに対する応答がサーバから受信され、それはコンテンツに関連するメタデータを含む。

Description

本出願は、２０１４年３月１３日に出願された米国特許仮出願番号第６１／９５２，８４０号、及び米国特許仮出願番号第６１／９５３，６６８号の優先権を主張する。上記仮出願の全ての内容が本文献の開示の一部として引用により援用される。

本特許文献の主題は、マルチメディアコンテンツの管理に関し、より具体的には、透かしを使用してマルチメディアコンテンツの認識及び利用を容易にすることに関する。

さまざまなモバイルプラットフォーム及び固定プラットフォーム上でのマルチメディアコンテンツの使用及び提示が急速に増殖している。このようなクラウドベースのストレージインフラストラクチャ、メディアプレーヤの低減された形状要因、および高速無線ネットワーク機能等のストレージパラダイムを利用することによって、ユーザは、ユーザ又はマルチメディアコンテンツの物理的位置に関係なく、マルチメディアコンテンツに容易にアクセスし、消費することができる。視聴覚（オーディオビジュアル）コンテンツ等のマルチメディアコンテンツは、連続して表示されるとき、多くの場合、一連の関連する画像で構成され、存在する場合は添付の音とともに、動きの印象を与えることができる。このようなコンテンツは、ハードドライブや光学ディスク等のローカルストレージ、インターネットサイトやケーブル／衛星配信サーバ等のリモートストレージ、ワイヤレス（ｏｖｅｒ−ｔｈｅ−ａｉｒ）放送チャンネルやその他のさまざまなソースからアクセスされ得る。

あるシナリオでは、そのようなマルチメディアコンテンツ、又はその一部は、これらに限定されないが、例えば、静止画像、ビデオシーケンス及びオーディオクリップのコンテンツの一種類のみを含み、他のシナリオでは、マルチメディアコンテンツ、又はその部分は、視聴覚コンテンツ及び幅広いメタデータ等のコンテンツの二種類以上を含み得る。メタデータは、例えば、チャネル識別、プログラム識別、コンテンツ及びコンテンツセグメント識別、コンテンツサイズ、コンテンツが作成又は編集された日付、コンテンツの所有者及び作成者の識別、タイムコード識別、著作権情報、字幕、及び、例えば、広告コンテンツのＵＲＬ等のロケーション、ソフトウェアアプリケーション、対話型（インタラクティブ）サービスコンテンツ、及びさまざまなサービスを可能にするシグナリング、及びその他のアクセス可能な関連データのうちの一つ以上含むことができる。一般に、メタデータは、コンテンツのエッセンス（例えば、音響及び/又は映像コンテンツ）と、関連するサービス（例えば、対話型サービス、ターゲティング広告の挿入）についての情報である。

メタデータは、コンテンツ作成及び配信バリューチェーン全体で、コンテンツの管理、注釈、パッケージング及び検索を有効にすることができる。デジタルテレビの導入以来、メタデータは、デジタル対話型機能及びサービスを可能にするために導入された。様々な標準化の取り組み（例えば、ＭＰＥＧ−７、ＭＰＥＧ−２１、ＴＶ−Ａｎｙｔｉｍｅ、ＤＶＢ−ＳＩ、ＡＴＳＣ等）が、相互運用性と統一サービスをサポートするエッセンスを記述するための事前定義されたデータ構造と移送方法を持つメタデータ規格を作成する努力を行っている。

そのようなメタデータは、ある用途、特に放送対話型サービスを可能にするために有用であり得るが、それらは、マルチメディアコンテンツにインターリーブ、プリペンド、又は付加されなければならず、このことは、追加の帯域幅を占有し、より重要なことに、コンテンツを異なるフォーマットに変換（例えば、アナログデジタル変換、別のファイルフォーマットへのトランスコード等）するとき、処理（トランスコーディング等）するとき、及び／又は通信プロトコル／インターフェース（ＨＤＭＩ（登録商標）、アダプティブストリーミング等）を介して送信するときに失われる可能性がある。

開示される技術は、コンテンツの自動認識を容易にし、コンテンツに関連するメタデータの取得を可能にする。

開示される技術の一態様は、マルチメディアコンテンツについて関連する情報を取得するための方法に関する。この方法は、透かし検出器を備えた受信機デバイスにおいてコンテンツを受信し、一つ以上の埋め込まれた透かしのペイロードを抽出するために受信されたコンテンツに対して透かし検出を実行することを含む。ペイロードは、サーバ識別子を含む第１のフィールドと、サーバ識別子と関連付けられたインターバル識別子を含む第２のフィールドを含む。第１のフィールドは、透かしペイロードによって識別されるコンテンツセグメントに関連付けられたメタデータを取得するためにアクセス可能なインターネットアドレスへのマッピングを提供する。方法はさらに、検出された透かしペイロードに基づいて、クエリを形成し、インターネットアドレスによって識別されるサーバにクエリを送信し、及び、サーバからのクエリに対する応答であって、コンテンツに関連付けられたメタデータを含む応答を受信することを含む。

例示的な一実施形態では、第１のフィールドの値は、中央局によってドメインレジストラントに割り当てられ、各ドメインレジストラントは、第２のフィールドの割り当て及び使用を制御する。もう一つの例示的な実施形態において、第１のフィールドとインターネットアドレスとの対応関係は、少なくとも部分的にレジストラサーバによって予め確立されている。さらに別の例示的な実施形態では、マッピングは、受信装置においてメモリ内に記憶される。別の例示的な実施形態では、受信装置は、ルックアップサーバへの第１のフィールドを含むルックアップ要求に応答して、マッピング又はインターネットアドレスを受信する。例示的な一実施形態では、クエリは、インターバル識別子の特定の値に対応するメタデータを取得するために使用される標準化されたクエリである。さらに別の例示的な実施形態では、ペイロードは、インターバル識別子によって識別されるコンテンツインターバルに関連付けられたメタデータの可用性を示す第３のフィールドを含む。さらに別の例示的な実施形態では、クエリが形成され、第３のフィールドの値の変化を検出したときにサーバに送信される。

例示的な一実施形態によれば、ペイロードはさらに、小ドメイン（a small domain）、中ドメイン（a medium domain）、又は大ドメイン（a large domain）のうちの一つにペイロードが対応することを識別するペイロードタイプフィールドを含むよう構成される。特定の一実施形態では、ペイロードは５０ビット長であり、ペイロードタイプフィールドは、２ビットフィールドである。別の特定の実施形態では、小ドメインに対応するペイロードが、３０ビットの第１のフィールド、１７ビットの第２のフィールド、及び１ビットの対話型ビットを含み、中ドメインに対応するペイロードが、２２ビットの第１のフィールド、２５ビットの第２のフィールド、及び１ビットの対話型ビットを含み、及び大ドメインに対応するペイロードが、１８ビットの第１のフィールド、２９ビットの第２のフィールド、及び１ビットの対話型ビットを含む。例示的な一実施形態では、対話型ビットは、対話型コンテンツが利用可能であるか否かの指標を提供する。

別の実施形態によれば、第１のフィールドはサーバコードを指定し、第２のフィールドは、コンテンツの特定のインターバルに関連付けられたインターバルコードを指定し、それぞれのサーバコードは、中央局によって、コンテンツプロデューサー、コンテンツディストリビューター、又はサービスプロバイダのうちの一つに割り当てられる。さらに別の実施形態において、メタデータは、受信装置が、インターバル識別子によって識別されるコンテンツインターバルに関連付けられている特定の対話型サービスを実行できるようにする命令を含む。特定の一実施形態では、メタデータは、対話型サービスサーバのインターネットアドレス、又はいつ、どのように対話型サービスが構成され得るかを示す１つ以上のパラメータのうちの１つ以上を識別する。

開示された実施形態の別の態様は、マルチメディアコンテンツを受信することができるデバイスに関する。デバイスは、少なくとも部分的に電子回路を用いて実装される透かし検出器を含み、受信されたマルチメディアコンテンツからの１つ又は複数の透かしを検出する。検出された透かしは、サーバ識別子を含む第１のフィールドと、サーバ識別子に関連付けられたインターバル識別子を含む第２のフィールドを含むペイロードを含む。第１のフィールドは、透かしペイロードによって識別されるコンテンツセグメントに関連付けられたメタデータを検索するためにアクセス可能なインターネットアドレスへのマッピングを提供する。さらに、デバイスは、プロセッサと、その上に具現化されるプロセッサ実行可能命令を含むメモリとを含む。命令は、実行時に、プロセッサにクエリを形成させる。デバイスはまた、少なくとも部分的に電子回路を用いて実装される通信コンポーネントを含み、インターネットアドレスによって識別されるサーバにクエリを送信し、サーバからクエリに対する応答を受信する。応答は、コンテンツに関連するメタデータを含む。

例示的な一実施形態では、第１のフィールドの値は、中央局によってドメインレジストラントに割り当てられ、各ドメインレジストラントは、第２のフィールドの割り当てと使用を制御する。別の例示的な実施形態において、第１のフィールドとインターネットアドレスとの対応は、少なくとも部分的にレジストラサーバによって予め確立される。さらに別の実施形態では、マッピングは受信装置に格納され、第１のフィールドに基づいて、インターネットアドレスを検索するための受信装置による使用のためにアクセス可能である。さらに別の実施形態において、通信コンポーネントは、第１のフィールドを含むルックアップ要求をルックアップサーバへ送信し、ルックアップ要求に応答して、マッピング又はインターネットアドレスを受信するように構成される。

別の例示的な実施形態によれば、プロセッサによって実行される命令は、第１のフィールドの値に基づいて、ルックアップクエリを形成し、通信コンポーネントは、ルックアップサーバにルックアップ要求を送信し、インターネットアドレスを受信するように構成される。この特定の実施形態では、プロセッサによって実行される命令はさらに、インターネットアドレスとインターバル識別子の特定の値に基づいて標準化されたクエリとしてクエリを形成し、通信コンポーネントはさらに、標準化されたクエリをサーバへ送信し、インターバル識別子の特定の値に対応するメタデータを受信するように構成される。例示的な一実施形態では、プロセッサによって実行される命令は、第３のフィールドの値の変化を検出すると、クエリを生成する。

上記デバイスに関連する別の例示的な実施形態では、ペイロードは、インターバル識別子によって識別されるコンテンツインターバルに関連付けられたメタデータの可用性を示す第３のフィールドを含む。さらに別の実施形態では、ペイロードはさらに、小ドメイン、中ドメイン、又は大ドメインの一つに対応するようにペイロードを識別するペイロードタイプフィールドを含むように構成される。特定の一つの実装では、ペイロードは５０ビット長であり、ペイロードタイプフィールドは、２ビットフィールドである。別の特定の実装では、小ドメインに対応するペイロードは、３０ビットの第１のフィールドと、１７ビットの第２、及び１ビットの対話型ビットを含み、中ドメインに対応するペイロードは、２２ビットの第１のフィールド、２５ビットの第２のフィールド、及び１ビットの対話型ビットを含み、大ドメインに対応するペイロードは、１８ビットの第１のフィールド、２９ビットの第２のフィールド、及び１ビットの対話型ビットを含む。さらに別の実施形態では、対話型（インタラクティブ）ビットは、対話型コンテンツが利用可能であるか否かの指標を提供する。

上記デバイスに関連付けられた例示的な一実施形態によれば、第１のフィールドはサーバコードを指定し、第２のフィールドは、コンテンツの特定のインターバルに関連付けられたインターバルコードを指定し、それぞれのサーバコードは、中央局によって、コンテンツプロデューサー、コンテンツディストリビューター、又はサービスプロバイダの一つに割り当てられる。さらに別の実施形態では、プロセッサによって実行される命令は、インターバル識別子によって識別されるコンテンツインターバルに関連付けられた特定の対話型サービスを実行するためのメタデータをプロセッサに使用させる。別の例示的な実施形態では、メタデータは、対話型サービスサーバのインターネットアドレス、又はいつ、どのように対話型サービスが構成され得るかを示す１つ以上のパラメータのうちの１つ以上を識別する。

開示された技術の別の態様は、１つ以上の非一過性のコンピュータ記録媒体上で実施されるコンピュータプログラム製品に関する。コンピュータプログラム製品は、透かし検出器を備えた受信装置においてコンテンツを受信するためのプログラムコード、及び一つ以上の埋め込み透かしのペイロードを抽出するために、受信したコンテンツにおいて透かし検出を行うためのプログラムコードを含む。ペイロードは、サーバ識別子を含む第１のフィールドと、サーバ識別子と関連付けられたインターバル識別子を含む第２のフィールドとを含む。第１のフィールドは、透かしペイロードによって識別されるコンテンツセグメントに関連付けられたメタデータを検索するためにアクセス可能なインターネットアドレスへのマッピングを提供する。コンピュータプログラム製品はさらに、検出した透かしペイロードに基づいて、クエリを形成し、インターネットアドレスによって識別されるサーバへクエリを送信するためのプログラムコード、及び、サーバからのクエリに対する応答（応答は、コンテンツに関連するメタデータを含む）を受信するためのプログラムコードを含む。

開示された技術の別の態様は、プロセッサと、プロセッサ実行可能なコードを含むメモリとを含むデバイスに関する。プロセッサ実行可能コードは、プロセッサによって実行されるとき、マルチメディアコンテンツに埋め込まれた一つ以上の透かしを抽出するようにデバイスを構成し、抽出された透かしは、サーバ識別子を含む第１のフィールドと、サーバ識別子に関連付けられたインターバル識別子を含む第２のフィールドを含むペイロードを含む。第１のフィールドは、透かしペイロードによって識別されるコンテンツセグメントに関連付けられたメタデータを検索するためにアクセス可能なインターネットアドレスへのマッピングを提供する。さらに、プロセッサによって実行されるとき、プロセッサ実行可能コードは、クエリを生成し、インターネットアドレスによって識別されるサーバにクエリを送信し、サーバからのクエリに対する応答（応答は、コンテンツに関連付けられたメタデータを含む）を受信するようにデバイスを構成する。

図１は、例示的な実施形態に従って、自動コンテンツ認識及び対話型コンテンツの取得を提供するためのシステムを示す。 図２は、例示的な実施形態に従って、レジストラ、ドメインマネージャ、ドメインメンバエンベッダマネージャ、及びエンベッダがどのように階層構造で接続され得るかを示す図である。 図３は、例示的な実施形態に従って、放送コンテンツのタイムラインと埋め込まれた透かしとの関係を示す。 図４は、透かしペイロードをメディアタイムと対話型コンテンツに関連付けることができる方法の実施例を提示する。 図５（Ａ）は、例示的な実施形態に従って、コンテンツの自動認識を提供し、及び関連するメタデータを取得するために実行され得る例示的な一連の操作を示す。 図５（Ｂ）は、例示的な実施形態に従って、コンテンツの自動認識を提供し、及び関連するメタデータを取得するために実行され得る例示的な一連の操作を示す。 図６は、例示的な実施形態に従って、コンテンツの自動認識及び対応するメタデータの取得を可能にするシステムおよび関連するコンポーネントを示す。 図７は、例示的な実施形態による透かしペイロード構造を示す。 図８（Ａ）は、例示的な実施形態による透かしペイロード構造を示す。 図８（Ｂ）は、例示的な実施形態によるペイロードタイプの値を記述するテーブルである。 図８（Ｃ）は、例示的な実施形態による大ドメイン、中ドメイン、及び小ドメインのフィールドを含む構造を示す。 図８（Ｄ）は、一つの実施形態によるサーバコード及びインターバルコードの値を示すテーブルである。 図８（Ｅ）は、例示的な実施形態によるドメイン当たりのドメイン数及び持続時間を示すテーブルである。 図９は、種々の開示された実施形態が実装されるデバイス９００のブロック図を示す。 図１０は、実施形態に従って、マルチメディアコンテンツに関連付けられたメタデータを取得するために実行される実施例の動作のセットを図示する。

以下の説明において、説明する目的であり限定ではなく、開示された実施形態の完全な理解を提供するために、詳細な記述及び説明が記載される。しかしながら、本発明がこれらの詳細な記述及び説明から離れた他の実施形態において実施され得ることは、当業者には明らかであろう。

さらに、この説明において、単語「例示的」は、例、事例、又は例示として役立つことを意味するために使用される。「例示的」として本明細書に記載のいずれの実施形態又は設計は、他の実施形態又は設計よりも好ましい又は有利であると必ずしも解釈されない。どちらかというと、例示的の単語の使用は、具体的な方法で概念を提示することを意図する。

先に述べたように、マルチメディアコンテンツにメタデータを組み込むための典型的な手法は、多くの場合、関連するマルチメディアコンテンツにメタデータフィールド又はパケットをインターリーブすること、プリペンドすること、又は付加することに依存する。これらの技術は、特定の状況下で信頼できないことが証明されており、例えば、マルチメディアコンテンツが別のフォーマットに変換される場合、メタデータが失われる可能性がある。特に、いくつかのシナリオにおいて、マルチチャネルビデオプログラムディストリビューター（ＭＶＰＤ）によって発行されたセットトップボックスのような介入デバイスは、コンテンツソースからマルチメディアコンテンツを受信し、非圧縮のマルチメディアコンテンツをテレビ又は他の提示デバイスへ提供し、その結果、さまざまなメタデータや、そうでなければマルチメディアコンテンツに伴ったであろう対話型アプリケーション等の機能が失われる。従って、コンテンツ識別のための代替技術が、メタデータの多重化技術を補完又は置換し得る。

開示された実施形態は、埋め込まれた透かしを使用して、自動コンテンツ認識（ＡＣＲ）を可能にする。透かしは、コンテンツの音響部分、及び／又は映像部分に埋め込まれ得、コンテンツの視聴者（又はリスナー）に実質的に知覚不可能である。透かしはまた、さまざまなコンテンツ処理操作やチャネル障害、例えば、圧縮と解凍、クロッピング、スケーリング、トランスコーディング、フォーマットの変換、ノイズの付加、音響伝搬、光（例えば、自由空間）伝送、デジタルアナログ（Ｄ／Ａ）及びアナログデジタル（Ａ／Ｄ）変換等に影響されない。透かし検出器（時には、透かしエクストラクタとも言われる）によって検出されると、透かしペイロードは、コンテンツ、並びに視聴中のコンテンツのカレントの時間的な位置（タイミング情報）を特定するため、及び、例えば、追加コンテンツの受信、動的な広告挿入の実行、又は対話機会への参加等さまざまな操作を可能にするように識別されたコンテンツ及び時間位置に関連付けられたメタデータを回復するために使用され得る。視聴デバイス（または関連するデバイス）は、追加コンテンツの検索のため、対話機会又はその他のサービスに参加するために、インターネット（又はより一般的に、リモートデータベース）に接続される。

開示された実施形態はさらに、Ａｄｖａｎｃｅｄ Ｔｅｌｅｖｉｓｉｏｎ Ｓｙｓｔｅｍｓ Ｃｏｍｍｉｔｔｅｅ （ＡＴＳＣ）, Ｉｎｃ., 自動コンテンツ認識電子透かしソリューションの提案募集（Call for Proposals For ATSC-3.0 AUTOMATIC CONTENT RECOGNITION WATERMARKING SOLUTIONS）−ＡＴＳＣ Ｔｅｃｈｎｏｌｏｇｙ Ｇｒｏｕｐ ３ （ＡＴＳＣ ３．０） （Ｓ３３ Ｄｏｃ. ０６７ｒ３）の要件に準拠する。特に、いくつかの実施形態は、コンテンツソースのコンテンツに透かし挿入器を使用して、透かし埋め込みをすることを規定し、それは次いで、消費者の家庭でのセットトップボックス（又は同様のデバイス）にコンテンツを提供するＭＶＰＤに送信される。セットトップボックスから（典型的にはＨＤＭＩ（登録商標）インターフェースを介して）のコンテンツは、ＡＴＳＣ３．０規格に準拠した視聴デバイス（「受信機」）上に提示される。視聴デバイスにおける非圧縮オーディオ／ビデオは埋め込まれた透かしを含み、それはコンテンツ及び視聴されるコンテンツの現在位置の識別を可能にする。識別されたコンテンツ及びコンテンツの現在の時間位置はメタデータの回復に使用され、それは視聴デバイスが、追加のコンテンツ、サービス、又は提示されたコンテンツに関連する機能を受信することを可能にする。いくつかの実施形態では、受信機（受信装置ということもある）は、セットトップボックスとは別のコンポーネントであるが、他の変形では、受信装置は、セットトップボックス、ディスプレイ、キーボード又は他のユーザインタフェースデバイス、または透かし検出器、並びにプロセッサ（例えば、マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）等）、及びそのようなデバイス（複数可）の実装に必要となり得る回路等の追加のコンポーネントのいずれか一つ又は組み合わせを含んでよく、あるいは、それらを含むより大きなデバイスの部分であってもよいことに留意すべきである。

本出願に係るいくつかの実施形態では、埋め込まれた透かしによって伝えられる情報は、視聴デバイスが、現在視聴中のチャネルを識別し短い時間周期（例えば、２秒）でチャネルの変更を認識できるようにする。また、埋め込まれた透かしによって伝えられる情報は、視聴デバイスが、コンテンツ（インタースティシャル等の短いコンテンツを含む）、及び視聴されるコンテンツの現在位置を認識できるようにする。埋め込まれた透かしによって搬送される情報はまた、視聴デバイスが、コンテンツおよび関連サービスに関するメタデータ情報にアクセスするための遠隔地（例えば、リモートサーバのＵＲＬ）を発見することを可能にする。それは、視聴デバイスに、レンダリングされているコンテンツ内の時間位置を、サンプル毎、又はアクセスユニット毎の精度レベルで識別することを可能にする。また、埋め込み透かしによって伝えられる情報は、視聴デバイスに、リアルタイムで時間限定イベントトリガを受信することを可能にし、そのことは、遠隔地からメタデータを要求する等の様々な操作を実行するように視聴デバイスをアクティブにし得る。

本文献に記載される方法、システム、デバイス及びコンピュータプログラム製品はさらに、透かしに関連付けられたハイレベルの名前空間の集中管理を有効にし、同時に、分散された名前空間のルックアップを有効にする。開示された実施形態は、さらに、相互運用性のキーポイントが標準化されるようにして、名前空間内の透かしの独立した管理を実現し、並びに、個々の放送コンテンツに関連付けられた関連データサービスの分散運用、自立運用、及び管理を実現する。

いくつかの例示的な実施形態における電子透かしの構造は、次のフィールド、すなわち、ドメインＩＤ及びシーケンスＩＤを含む。各ドメインＩＤは、中央局によって、そのドメイン下でシーケンスＩＤコードの割り当てと使用を制御するドメインレジストラントへ割り当てられる。各ドメインＩＤは、そのドメインのシーケンスＩＤに関連付けられたメタデータを検索するために使用されるインターネットドメイン名に、１対１でマップする。クライアントは、ドメイン名の関連を見つけるためにルックアップサービスを使用する。標準化されたクエリは、ドメイン内のサーバからシーケンスＩＤと一致するメタデータを取得するために使用される。ドメインルックアップサービスでの使用のためにドメインレジストラで登録されるドメインＩＤに関連付けられるドメイン名は、透かしに埋め込まれた関連するドメインＩＤをその中に持つ放送コンテンツについて対話型サービスを提供するために使用される同じドメイン名であってよく、または、対話型サービスを提供するために使用されるドメイン名とは別のドメイン名であってもよいことに留意されたい。シーケンスＩＤは、コンテンツ、及び、ドメインＩＤで指定されるドメイン内で視聴されているコンテンツの現在の時間位置を識別するために使用され得る。

実施例の透かしペイロード：例示的な実施形態によれば、５０ビットペイロードが、コンテンツの１．５秒ごとに埋め込まれる。この例示的な実施形態では、透かしペイロードは、以下の構造で標準化され得る：［ペイロードタイプ：２］［ペイロード：４８］。すなわち、一番右の４８ビットは、ペイロードを運ぶために指定され、左端の２ビットはペイロードタイプを運ぶために指定される。例えば、ペイロードタイプの値は、０乃至３の範囲にある場合があり、「０」は予備のペイロードタイプを指定し、「１」は大ドメインペイロードタイプを指定し、「２」は中ドメインペイロードタイプを指定し、及び、「３」は小ドメインペイロードタイプを指定する。従って、ペイロードタイプの値はそれぞれ、ペイロードの構造を記述し得る。

いくつかの例示的な実施形態において、各ペイロードタイプのペイロードの構造は次のように定義される。
・小ドメイン：［ドメインフィールド：３０ビット］［シーケンスフィールド：１７ビット］［トリガフィールド：１ビット]
・中ドメイン：［ドメインフィールド：２２ビット］［シーケンスフィールド：２５ビット］［トリガフィールド：１ビット]
・大ドメイン：［ドメインフィールド：１８ビット］［シーケンスフィールド：２９ビット］［トリガフィールド：１ビット]

いずれの構造からのドメインフィールドも、ペイロードタイプの値をドメインフィールドにプリペンドし、３２ビットまで（右へ）ゼロパディングすることによって、ユニークなドメインＩＤへマップされ得る。ＡＳＣＩＩ符号化の場合、ドメインＩＤは、８文字の１６進数の値として表現され得る。０のドメインフィールドの値は、すべてのドメインで用意することができる。いずれの構造のシーケンスフィールドも、シーケンスＩＤに直接マッピングされ得る。ＡＳＣＩＩ符号化において、シーケンスフィールド（先行するゼロのオプション）の１６進表現が利用され得る。１０２４以下の１０進値を持つシーケンスＩＤは、制御コードとして使用するために予定され得る。制御コードは、一時的に確保される。

トリガビットは、（例えば「１」の値に）設定されると、受信機に、ドメインサーバからのメタデータを要求する等の様々な操作を実行するように、受信機をアクティブにし得るイベントを通知する。それは、シーケンスＩＤに関連付けられた対話型コンテンツや広告挿入等のさらなるサービスや機能が、ペイロードのドメインＩＤに関連付けられたドメインサーバから受信機に利用可能であることを示す。いくつかの実装形態では、トリガフィールドは、マルチビットを含み得る。いくつかの実装形態では、トリガフィールドは、他の目的に使用され得る。例えば、フィールドは、以前にコンテンツディストリビューターやコンテンツプロデューサーによって埋め込まれた既存の透かしが別のディストリビューターによって置き換えられるか（これは、「置換」透かしと呼ぶことがある）否かを示す「上書き可能」ビットとして定義することができる。この場合に、透かしエンベッダは、透かしペイロードの存在を最初にチェックし、ペイロードが予め設定されている場合、そのような「上書き可能」ビットの値を検証し、ビットの値に応じて、新しい透かしペイロードが、既存のものを置換するために埋め込まれ得るか決定する。別の実施例では、別のフィールドが、「重ね透かし可能（over-watermarkable）」ビットとして定義することができ、それは、予め存在していたものと共存してコンテンツに新しい透かしペイロードを埋め込み、両方を抽出する（このことは、透かし「重ね（layering）」と呼ばれることがある）ことができるか否かを示す。いくつかの実装形態では、追加のフィールドが、これらの２つの例示的な使用事例をサポートするために、透かしペイロード構造に加えられてよい。「上書き可能」ビット、及び／又は「重ね透かし可能」ビットは、シーケンスＩＤによって識別されるコンテンツセグメントに関連付けられるので、コンテンツの各セグメントはこれらのビットを別々に設定されことができ、従って、あるセグメントを上書き可能、及び／又は重ね透かし可能にすることができる。

別の実施形態では、上書き透かしまたは重ね透かしの許可は、ドメインサーバを介して行われ得る。このような許可は、１つ以上のドメインＩＤ及び／又はシーケンスＩＤに関連付けられてよい。透かしエンベッダが、既存の透かしペイロードを検出した場合、それは、ペイロードのドメインＩＤに応じてドメインサーバにペイロードを送信し、そのようなペイロードが新しいペイロードに置換され得るか、または、新しいペイロードが既存のものの上に重畳され得るかどうかを示す応答を受信する。

いくつかのケースで、コンテンツディストリビューターは、一部又はすべてのコンテンツセグメントで、既存のペイロードを置換する、または新しいペイロードを重ねる決定をする前に、既存の透かしペイロードにより有効にされるサービスを確認したい場合がある。ディストリビューターは、サービスを識別する関連するすべてのメタデータについて、既存のペイロードによって識別されたドメインサーバを照会し、それを検査し、いくつかのコンテンツセグメントに関連付けられているメタデータを選択し、そのようなディストリビューターによって好ましいドメインサーバに選択したメタデータを投稿し得る。ディストリビューターは、既存のペイロードに関連付けられた新たなサービスを導入し得る。また、ディストリビューターは、いくつかのセグメントに新しいペイロードを埋め込み、ドメインサーバ上の新しいペイロードにより有効にされるこれらのセグメントに新しいサービスを関連付けることもできる。さらにディストリビューターは、既存のペイロードの上に、いくつかのセグメントで新たなペイロードを埋め込むこともできる。従って、新たなペイロードおよび既存のペイロードの両方が検出され、ドメインサーバに提供され得、受信機は、新たなペイロード又はセグメントに関連付けられた既存のペイロードによって識別される複数のトリガを受信し得る。受信機は、ユーザの嗜好や事前設定に従って、トリガのいずれかによって生ずるサービスを選択するか、複数のトリガによって生ずるすべてのサービスをユーザにもたらし得る。

トリガによって引き起こされるサービスの一つは、プリフェッチされる広告等、典型的にインターネットを介して配信される二次的な視聴覚コンテンツの提示であり得る。そのような視聴覚コンテンツは通常の視聴覚コンテンツとして扱われ、すなわち、それは透かし入れすることができ、透かしに基づくトリガをドメインサーバに登録することができる。従って、二次コンテンツ内の透かしペイロードも、対話型サービスをトリガすることができる。これは、「ネストされたトリガ（nested triggers）」と呼ばれることがある。

代替の実施形態では、透かしエンベッダは、常に、既存の透かしを上書きするが、既存の透かし、及び新たに埋め込まれた透かしとの関係を追跡し、それについてドメインサーバに通知する。これは特に生放送で有効であり、既存の透かしについてのコンテンツの調査が、上書き処理中にいかなる待ち時間を生ずることなく、透かしの埋め込み／上書きと並行して進行し得る。例えば、ドメインサーバは、ペイロードＸで透かしの埋め込みが始まったときに、ペイロードＹで既存の透かしが発見されたことを通知され得、既存の透かしは、新たな埋め込み透かしの前に、Ｔミリ秒開始する。この情報を使用して、ドメインサーバは、後に、ペイロードＸを使用して照会するとき、既存の透かしのタイムラインを計算することができ、及びペイロードＹのタイムラインに同期して、サービスに関するメタデータを提供する。

さらに別の実施形態では、複数の透かしは、異なる透かし埋め込みパラメータを使用して、同じコンテンツに埋め込まれ得る。例えば、コンテンツプロデューサーは、その透かしについて一組のパラメータを使用することができるが、コンテンツディストリビューターは、コンテンツプロデューサーの透かしの検出を実質的に妨害しない透かしを生成する異なるパラメータセットを持つことができる。代替的に、異なるパラメータを使用する透かしの埋め込みは、透かしのコード空間、又は全体の透かしデータのスループットを増大させるために使用され得る。このように、透かしの階層化（watermark layering）とも呼ばれて、複数の透かしが受信機によって検出され得、受信機は、それらのそれぞれに関連付けられているドメインサーバにアクセスし、複数のサービスを得ることができる。

上記の透かしペイロード構造を使用し、透かしのペイロードが１．５秒の持続時間を持っていると仮定した場合、２５０，０００を超える大ドメインが識別され得（例えば、長期の持続的な埋め込みのために）、ドメイン毎に、２５．５年間、コンテンツを一意に透かし入れすることを可能にするであろう。この構造はさらに、４百万を超える中ドメインが一意に識別されることを可能にし（例えば、オリンピック規模のイベントの持続的な透かし入れ、毎年恒例のチャネルの割り当て、または長期の選択的埋め込みのために）、そのことはドメイン毎に、コンテンツを一意に透かし入れすることを１．５年間可能にするであろう。小ドメインの構造は、１０億を超える小ドメイン（例えば、番組）の一意の識別を可能にするとともに、ドメイン毎に一意に透かし入れされたコンテンツを５４時間可能にする。ペイロードタイプによって、ドメインは、一つ又は複数の、１）放送装置又はコンテンツプロデューサー、２）ＭＶＰＤ、３）チャネル、４）スポーツイベント、５）番組、６）映画、又は７）エピソードに割り当てられてよい。

透かしペイロードは、コンテンツに埋め込まれる前に、様々な符号化、変調および書式設定の操作を受ける場合がある。例えば、ペイロードは、エラー訂正コード（ＥＣＣ）符号化、スクランブル、他のパケットのインターリーブ、同期または登録ヘッダの付加、暗号化、又は特定の特性を持つビットのシーケンスを形成するためのチャネルコード化がされ得る。多くの場合、透かしペイロードは、埋め込み透かしの検出の信頼性を向上させるために、ホストコンテンツの複数の部分に繰り返し埋め込まれる。埋め込まれると、埋め込まれたコンテンツは、埋め込まれた透かしビット（または、より一般的に、シンボル）を復元し、上記の符号化、変調またはフォーマティングスキームの逆を実行してペイロードを回復するために、透かしエクストラクタによって処理され得る。いくつかの例では、統計的な技術が、埋め込まれた透かしの複数のインスタンスを使用してコンテンツから埋め込まれたシンボルを回復するために使用される。

図１は、例示的な実施形態に従って、放送装置（ブロードキャスター）から消費者デバイスに提供されるコンテンツの自動コンテンツ認識、及び対話型コンテンツの取得を提供するためのシステムを示す。コンテンツは放送前に、ドメインメンバによって透かしを埋め込まれる。例えば、そのようなドメインメンバは、コンテンツプロデューサー又は放送装置であり得る。放送装置はコンテンツを、１つ又は複数のユーザ宅内に送信する。そのようなコンテンツは、多くの場合、セットトップボックス（ＳＴＢ）等の受信機で受信され、コンテンツが受信機に提供される前に、解凍やフォーマットの操作が行われ得る。解凍やフォーマットは、代わりに受信機内で行われてもよい。透かし検出器を含む受信機は、透かしの存在について、受信したコンテンツを調べる。透かしの検出は、検出された透かしペイロードに関連付けられたドメイン名を識別し、識別されたドメインサーバにクエリを送信する等のさらなるアクションをトリガすることができる。

図１のドメインレジストラは、ドメインＩＤを登録し、ドメインＩＤとドメイン名の間のマッピングをドメインルックアップサーバへ公開することに関与する、ユニークな集中型のエンティティである。ドメインの登録は、ドメインＩＤをドメインレジストラントエンティティに一意に割り当てる処理である。ドメインレジストラはドメインレジストラントに、処理（例えば、図１のＲＥＧＩＳＴＥＲとして指定された）を提供し、ドメインＩＤとドメイン名（例えば、インターネット形式）との関係を確立し、維持する。複数のドメインＩＤは、同じドメイン名にマッピングすることができる。ドメインレジストラは、さらに、ドメインＩＤからドメイン名へのすべてのマッピングのデータベースを管理する。ドメインレジストラは、標準化プロトコルを採用し（例えば、図１にＰＵＢＬＩＳＨとして指定される）、ドメインルックアップサーバ、並びにドメインルックアップサービスを実装するために必要とされ得る任意の他のデバイスを含み得るドメインルックアップサービスに、新規及び変更されたドメインのマッピングをパブリッシュ（公開）する。ドメインレジストラが使用するこのプロトコルは、中央ドメインレジストラとすべてのドメインルックアップサービス間の相互運用を可能にする。いくつかの実装では、ＰＵＢＬＩＳＨプロトコルのためのサポートがドメインルックアップサーバとドメインレジストラの両方に必須である。

再び図１を参照し、ドメインレジストラントは、一つ以上のドメインメンバによって、透かしにおけるシーケンスＩＤの使用を調整することに関与する。ドメインレジストラントがそのドメインのメンバであり得る。ドメインレジストラントはまた、ドメインレジストラで、ドメイン名（その割り当てドメインＩＤに関連付けられる）を登録することに関与する。

ドメインルックアップサーバ（複数可）ドメイン登録データベースのコピーを維持し、それはそれぞれの登録されたドメインＩＤをドメイン名にマッピングし、ドメインレジストラでＰＵＢＬＩＳＨプロトコルを使用して、それを最新の状態に保つ。ドメインルックアップサーバ（複数可）はまた、標準化されたプロトコル（例えば、図１にＬＯＯＫＵＰとして示される）を使用し、受信機によって発信されたドメインＩＤルックアップクエリに応答する、データベースからのドメイン名のマッピングを提供する。いくつかの実施形態では、標準化されたルックアッププロトコルの使用は、任意の受信機と任意のドメインルックアップサーバ間の相互運用性を得る必要があるが、受信機製造者は、彼らが製造するデバイスからのすべてのルックアップクエリをプライベートドメインルックアップサービスにつなぐことができ、そのようにする非標準プロトコルを採用することができるので、受信機又はドメインルックアップサーバ（複数可）のどちらの側でも必須とすることを要しない。いくつかの実施形態では、受信機はＡＴＳＣ対応又はＡＴＳＣ互換である。すなわち、これらの受信機は、このようなＡＴＳＣ３．０等のＡＴＳＣ要件に準拠する。

ドメインサーバは、登録されたドメインＩＤに関連付けられているドメイン名でアクセス可能なインターネットサーバであり、電子透かしの検出によってトリガされるクエリに応答して受信機にメタデータを提供することができる。いくつかの実装形態では、クエリは、（例えば、図１においてＱＵＥＲＹとして指定された）標準化されたメッセージプロトコルを使用する。クエリは、受信機によって開始され、ドメインＩＤとシーケンスＩＤをドメインサーバに提供する。ドメインサーバは、提供されたドメインＩＤとシーケンスＩＤに関連付けられた利用可能なメタデータ（例えば、放送チャネル識別子、放送セグメント識別子、タイムコード、シグナリング）で応答する。ドメインサーバは、すべてのクエリで使用可能なすべての必要なデータフィールドのためのデータを提供する必要はない。いくつかの実施形態では、ＱＵＥＲＹプロトコルのサポートは、すべての受信機とコンテンツの間の相互運用性を可能にするために、すべての受信機及びドメインサーバに必須である。このプロトコルは、すべての受信機と、すべてのドメインサーバ間の相互運用性を有効にし、サポートは受信機およびドメインサーバの両方で必須であり得る。

ドメイン管理：ドメインは、ドメインレジストラントとドメインメンバ（ドメイン内のエンティティ）との間の協調的な相互作用を介して管理される。ドメイン管理は、ドメイン内のシーケンスＩＤのドメインメンバへの割り当て、シーケンスＩＤのコンテンツセグメントへの割り当て、透かしエンベッダによるシーケンスＩＤの使用状況の管理、及び／又はシーケンスのＩＤに関連付けられるメタデータのドメインサーバへの配信を含む。これらの機能のためのプロトコル又はプロセスの標準化は、専門的なシステムの相互運用性を得るために価値があるが、デバイスの相互運用性のための要点ではない。ドメイン管理は、視聴覚放送コンテンツと多重化デジタルメタデータの両方を含むデジタル放送ストリームの解析を含み、透かしと埋め込みデジタルメタデータの両方を復号し、ドメインサーバのポピュレーションのために、放送コンテンツのオーディオ及びビデオエッセンスに存在する透かしペイロードと、放送ストリーム内の同じエッセンスに存在し関連付けられるデジタルメタデータとの間の関連性を自動的に確立する。ドメイン管理はまた、放送装置やコンテンツプロデューサーが放送コンテンツから抽出されたメタデータを編集し、または、ドメインサーバのポピュレーションのために新たなメタデータを追加することを可能にする機能やインターフェースを含む。

ドメイン識別子（ドメインＩＤ）、シーケンス識別子（シーケンスＩＤ）、及びトリガフィールドを含む、前述の透かし構造は、受信機へメタデータ（シグナリング）を提供するための代替方法として使用することができ、受信機が、多重デジタルデータストリームにおいて、メタデータ（シグナリング）を含む完全なデジタル放送ストリームではなく、放送コンテンツのエッセンス（すなわち、その音響及び映像）にアクセス権を持つというシナリオにおいて特に有用である。このことは、受信機が、例えば、アナログまたはＨＤＭＩ（登録商標）インターフェースを介して、トリガを含む多重放送ストリームの部分を含まないインターフェースから放送コンテンツを取得した場合に起こり得る。このようなシナリオでは、以下の例示的な操作のシーケンスが、完全な放送コンテンツに関連付けられた機能の完全なセット、並びに開示された技術を使用することによって有効になる追加の機能をユーザが取得することができるように実装され得る。操作の実施例のシーケンスは以下のとおりである。まず、メタデータにアクセスすることが可能なネットワークサーバの名前（「ドメイン名」）が特定される。次に、識別されたサーバは、関連するメタデータを取得するために照会される。例示的な一実施形態では、メタデータの検索処理は、特定の透かしペイロードにセットトリガビットを配置して受信機にトリガ検索プロセスを模倣させることにより達成され得る。

例示的な一実施形態によれば、ドメイン内のシーケンスＩＤが、ドメインマネージャ（ドメイン管理機能を実行する）によってドメインメンバに動的に割り当てられる。また、ドメインメンバのエンベッダが、さまざまな場所で複数の施設に配備され得る。それらは、インターネット、企業ネットワーク、または別の適切な通信リンクを介して、ドメインメンバエンベッダマネージャによって管理され接続される。シーケンスＩＤのブロック（一つ以上の連続したシーケンスＩＤを含むことができる）が、各エンベッダに最初に割り当てられる。エンベッダは、より多くのシーケンスＩＤを必要とする場合、そのドメインメンバエンベッダマネージャにシーケンスＩＤの新しいブロックの要求を送信する。そのような要求は、透かし埋め込みを実行する前、または、残りのシーケンスＩＤの数が所定数に達するときに送信され得る。同様に、ドメインマネージャは最初に、メンバエンベッダマネージャに、シーケンスＩＤの１つ以上のブロックを割り当てる。メンバエンベッダマネージャがより多くのシーケンスＩＤを必要とするとき、新しいシーケンスＩＤの要求をそのドメインマネージャに送信する。ドメインマネージャ及びドメインメンバエンベッダマネージャの両方は、各エンベッダが適切なシーケンスＩＤを持つことを保証する。シーケンスＩＤの割り当てに加えて、ドメインメンバエンベッダマネージャはまた、エンベッダによって埋め込まれる透かしペイロードのドメインＩＤ及びその他の埋め込みパラメータを含めて、それが管理する各エンベッダを設定することができる。それはまた、埋め込みログやエンベッダから透かし入りコンテンツのメタデータを収集し、それらをドメインマネージャに報告する。ドメインマネージャは、割り当てられたシーケンスＩＤを登録し、前述のように、ドメインサーバでコンテンツセグメント及び関連メタデータとシーケンスＩＤとを関連付けるために、このデータを使用することができる。

図２は、例示的な実施形態に従って、レジストラ、ドメインマネージャ、ドメインメンバエンベッダマネージャ、及びエンベッダを階層構造で接続し得る方法を図示する。図２に示すように、各ドメインメンバエンベッダマネージャ（例えば、ドメインメンバエンベッダマネージャ１）は、複数のエンベッダ（エンベッダ１Ａから１Ｎ）に関連付けられてよく、各ドメインマネージャ（例えば、ドメインマネージャ１）は、複数のドメインメンバエンベッダマネージャ（例えば、ドメインメンバエンベッダマネージャ１からｋ）と関連付けられてよく、及びレジストラは、複数のドメインマネージャ（例えば、ドメインマネージャ１からＰ）に関連付けられてよい。

一つの例示的な実施形態では、ドメインは複数のドメインサーバを持つことができ、そのそれぞれが特定の領域及び／又はドメインメンバとしてふるまう場合がある。この場合、ルックアップサービスは、階層構造のルックアップサーバのクラスタによって提供され得る。例えば、レジストラレベルのサーバは、まず、受信機によって提供されるドメインＩＤをドメインレベルのルックアップサーバへマッピングする。そしてその後、そのようなドメインレベルのルックアップサーバが、特定のドメインサーバへのドメインＩＤを決定する。

再び図１を参照して、受信機及びドメインルックアップサービスは、標準化されたメッセージプロトコル（例えば、図１においてＬＯＯＫＵＰとして指定される）を採用し、ドメインルックアップサービスへ問い合わせして、ドメインＩＤに関連付けられるドメイン名を提供する。ドメインＩＤとドメイン名のマッピングは受信機でローカルに、キャッシュに格納することができ、キャッシュは、定期的にタイムアウトしたり（例えば、有効生存期間（ＴＴＬ）値で）、必要に応じて（例えば、サーバが応答に失敗した場合）リフレッシュしたりすることができる。このプロトコルは、すべての受信機（例えば、ＡＴＳＣ受信機）と、すべてのドメインルックアップサービス間の相互運用を可能にする。先に述べたように、受信機製造者（例えば、ＡＴＳＣ受信機製造者）は、独自のドメインルックアップサービスを提供し得、それらの対話について独自のプロトコルを使用し得るので、受信機もドメインルックアップサービスも、標準化されたルックアッププロトコルのサポートは必ずしも必須ではない。受信機製造者は、彼らの受信機を彼らが選択したドメインルックアップサービスに関連付けることを許可されるであろうし、エンドユーザに、使用するドメインルックアップサービスを選択することを許可するだろう。一つ以上のドメインＩＤについて、受信機製造者はまた、名前がドメインレジストラに登録されている代替ドメインサーバを使用することができる。そのようなドメインＩＤについて、その製造者は、適時にポピュレートされるドメインサーバへクエリをつなぎ、ドメインＩＤ及び受信した透かしペイロードにおいて識別されたセグメントＩＤに関連付けられたメタデータを訂正することを保証することに関与する。そのような例では、完全なデジタル放送ストリームのリアルタイム分析から、すでに説明されているように、ドメインサーバがポピュレートされてよい。

再び図１を参照すると、受信機は、透かしペイロードのために受信コンテンツをスキャンする透かし検出器を採用する。受信機は、完全なデジタル放送ストリームから、及び／又は特定の放送チャネルから別々に受信されたコンテンツのみについて、透かし検出器をアクティブにし得る。透かしペイロードが検出されると、受信機は、関連するドメインサーバに問い合わせて、関連するメタデータを要求し得る。透かしペイロードに設定されたトリガビットは、シーケンスＩＤに関連付けられている対話型コンテンツが、ペイロードのドメインＩＤに関連付けられたドメインサーバから利用可能であろうデバイスへの「ヒント」である。従って、受信機は、ドメインサーバのクエリを開始するタイミングを決定するための基準として設定されたトリガビットの存在を使用してもよい。受信機は、さらに他の文脈、例えば、コンテンツの再生が始まった後に透かしペイロードが検出されたとき（例えば、受信機が最初にオンされた後）、チャネル変更後、割込み周期後にネットワーク接続が復元された後、又は、そのような「ヒント」が無視され得る以前のトリガでシグナリングが提供されるとき等において、ドメインサーバクエリを開始することを選択してよい。

トリガビットを使用する実装において、そのようなビットは、放送装置がそのコンテンツ全体に透かしを埋め込むことを選択する（おそらく、他の用途、例えば視聴者測定、広告の追跡等のために）使用例をサポートし得るが、コンテンツのある部分について特有のコンテンツ（例えば、ＡＴＳＣ対応の対話型コンテンツ）の利用可能性を知らせるのみである。そのようなトリガビットが存在しなければ、何百万のテレビセットが、利用可能な対話型コンテンツが存在しない場合、それらのサーバへ問い合わせを試みるであろう。いくつかの実装ではトリガビットが必要とされないことに留意されたい。例えば、受信機がドメインサーバからのトリガを問い合わせするとき、それは、コンテンツの特定の持続時間についてトリガのセットを要求し、クエリトラフィックを低減させ得る。

クエリを受けたドメインサーバは、提供された透かしペイロード情報に関連付けられた、格納されたメタデータを提供することにより、受信機のクエリに応答する。受信機は、その後、ドメインサーバから受信したメタデータを使用して、対話型サービスにアクセスし、設定し、及び実行し得る。そのようなメタデータは、これらに限定されないが、放送チャネル識別子、放送コンテンツ及び放送セグメントを一意に識別する識別子、タイムコード、トリガ、イベント又はアクション、補足コンテンツ、広告コンテンツ、又は上記が得られるサーバの位置（例えば、ＵＲＬ）を含む場合がある。受信機は、ドメインサーバからの応答がない、遅延する、又は不正な形式であることに対して復元性を有するであろう。

以下は、トリガフィールドが、コンテンツに関連する追加機能を有効にするメタデータを取得するために使用することができる例示的なシナリオを提供する。放送のタイムラインがコンテンツの連続した「セグメント」（例えば、番組、広告、広告、プロモーション、広告、番組）に分割されるいくつかの実装では、個々のセグメントについて、メタデータは、セグメントのタイムライン上の特定の瞬間に関連付けられ得る。トリガフィールドは、そのようなメタデータが利用可能であるか否かを示す。メタデータは、どのような方法で、いつ、又はどのような条件下で、特定のコンテンツや、セグメントに関連付けられた対話型サービス等のサービスをロードし実行すべきかについての命令を含み得る。メタデータは、対話型サービスがロードされ得るインターネットサーバを識別することができる。メタデータは、付加的に、例えば、対話型サービスが関連付けられた、表示されているセグメントを識別する。メタデータはさらに、いつ及びどのような方法で、例えば、対話型サービスが構成されるべきかについての一つ又は複数のパラメータを識別し得る。

図３は、例示的な実施形態に従って、放送コンテンツのタイムライン（スケジュール）と、埋め込まれた透かしとの関係を示す。図示された放送コンテンツのタイムラインは、メインプログラムの２つの放送セグメント（すなわち、番組セグメント４９及び５０）、広告セグメント６２及びプロモーションセグメント１２を含む。図３の下の部分は、ペイロードタイプ（ＰＴ）フィールド（１の値を有するものとして示される）を含むプロモーションセグメント１２に埋め込まれた透かしペイロード、ドメインＩＤ（ＤＩＤ）、セグメントＩＤ（ＳＩＤ）、及びトリガフィールド（ＩＳ）を図示する。図３は、プロモーションセグメント１２内の４０のセグメントのそれぞれに埋め込まれた連続したＳＩＤ値（６２８０１から６２８４０）を示す。すべての４０のセグメントのＤＩＤ値は４２０４であり、ペイロードタイプは１であり、トリガフィールドは１に設定される。

図４は、実施形態に従って、透かしペイロードをメディアタイムと対話型コンテンツとに関連付けることができる方法の実施例を提供する。特に、図４のテーブルは、ドメインＩＤ ５８３７ＦＥ００内のシーケンスＩＤ ６２８０１がメディアタイム 16:28:43.195に関連付けられ、ＵＲＬ xbc.tv/p12?e=7.5からアクセス可能な対話型機能に関連付けられたＸＢＣ−Ｅａｓｔチャネルへマップされることを示す。同様に、図４は、シーケンスＩＤ ６２８０１がメディアタイム 16:28:43.195に関連付けられ、ＸＢＣ−Ｅａｓｔチャネルへマップされ、ＵＲＬ xbc.tv/p12?e=7.5&m=77eeからアクセス可能な対話型機能に関連付けられることを示す。図４に示されているテーブルは、ドメインサーバで保存することができ、選択されたデータは、クエリに応答して受信機に提供することができる。

図５（Ａ）は、例示的な実施形態に従って、自動コンテンツ認識を提供し、関連するメタデータを取得するために実行され得る例示的な一連の操作を示す。図５（Ａ）中の操作は、受信機（例えば、図１に示される受信機等）によって実行され得る。５０２において、コンテンツは、透かし検出器を備えた受信装置で受信される。受信されたコンテンツは、例えば、非圧縮形式であり得る。いくつかの実施形態では、コンテンツは、圧縮された形式で受信機に到達し得、透かし検出の前に受信機内で復元され得る。５０４において、透かし検出が、一つ以上の埋め込まれた透かしペイロードを抽出するために受信したコンテンツに対して行われる。５０６では、抽出された透かしペイロードからのドメインＩＤが受信機のキャッシュにあるか否かが判定される。ドメインＩＤがキャッシュされている場合、操作は５１４で継続する。ドメインＩＤが、キャッシュ（または他のローカルストレージ）に存在しない場合、５０８において、受信機は、抽出されたペイロードからクエリを生成し、抽出されたペイロードのドメインＩＤに対応するドメインサーバを検索するためにルックアップサーバにクエリを送信する。いくつかの実装形態では、一つ以上のルックアップサーバのＵＲＬが受信機において事前に設定される。５１０で、ドメインサーバのアドレス（例えば、ＵＲＬ）を受信機が受信するか否かが判定され、ドメインサーバのアドレスを受信すると、受信機は、５１２で、ドメインＩＤとともに対応するドメインサーバのアドレスをキャッシュに記憶し、５１４において、受信機は、メタデータの抽出されたペイロードに基づいてクエリを生成し、それを識別されたドメインサーバに送信する。５１６において、クエリに対する応答がドメインサーバから受信され、応答はコンテンツに関連するメタデータを含む。ルックアップサーバが応答に失敗した場合、受信機は、別のルックアップサーバを試みることができる。少なくとも２度の試みの失敗の後、受信機は、エラーメッセージをユーザに通知してもよい。

図５（Ｂ）は、実施形態に従って、自動コンテンツ認識を提供し、関連するメタデータを取得するために実行され得る例示的な一連の操作を示す。図５（Ｂ）内の操作は図５（Ａ）のそれと同様であるが、サーバへのクエリを開始するために、レシーバへヒントを与える条件をさらに強調する。具体的に、コンテンツを受信し（５０１）、透かし検出を行った（５０３）後、５０５において、再生が開始されるかどうか決定され、チャネルの変化が検出され、あるいはトリガフィールドが設定される。例えば、トリガフィールド（例えば、トリガビット）が「１」に設定されている場合、又はトリガフィールドの値が以前に検出されたトリガフィールドの値から変更された場合、そのような決定は肯定（ＹＥＳ）を提供し得る。そのような決定はまた、例えば、検出された透かしが、コンテンツの再生開始後の最初のものであったり、チャネル変更が生じた後の最初のものであったりしたとき肯定的な答え（ＹＥＳ）を提供し得る。５０５での決定がＮＯの場合、操作は、受信したコンテンツから追加の透かしが検出される５０３に戻る。５０５での決定がＹＥＳの場合、操作は、検出された透かしに対応するドメインＩＤがキャッシュに格納されているか否かが決定される５０７に進む。図５（Ｂ）の操作５０７、５０９、５１１、５１３、５１５及び５１７はそれぞれ、先に説明した図５（Ａ）の操作５０６、５０８、５１０、５１２、５１４及び５１６と同様である。

ＶＰ１透かし：開示された技術の一つの具体的な実装例は、ＡＴＳＣ−３．０自動コンテンツ認識電子透かしソリューションの提案募集（「ＣｆＰ」）に定める要件と完全に互換性がある。そのような実装は、柔軟な、分散型の、スケーラブルな、ＶＰ１と呼ばれる特定の透かしを採用するインターネットベースシステムアーキテクチャを提供し、それとともに、標準化された通信プロトコルの収集と、完全な放送ストリームを伝えないインターフェースにより、失われたＡＴＳＣ−３．０放送ストリームメタデータを完全に回復するために、接続する任意のＡＴＳＣ受信機を有効にする軽量な管理プロセスを提供する。このようなアーキテクチャは、ＣｆＰで概説されるサーバベースの使用モデルをサポートし、それとともに、受信機製造者から、ＡＣＲサービスを提供しメタデータサービスを契約する必要を取り除く、よりオープンな、分散化された、および効率的なアーキテクチャを可能にし、及び、完全なＡＴＳＣ放送ストリームへの直接のアクセスを介して、ＡＴＳＣ受信機で有効となる対話型サービスをサポートする同じコンテンツ及びシグナリングサーバによって提供されるこの機能を有効にする。しかしながら、このアーキテクチャに集中されるべき１つの機能があり、それは、レジストラントに透かしコードのブロックを割り当てるための軽量な管理プロセスを実行し、及びサービスプロバイダへ登録のデータベースを公開するドメインレジストラ（例えば、サーバレジストラ）である。（この機能は、ＡＴＳＣ又はそれによって指定される管理エンティティによって操作されてもよい。）他のすべての機能は、オープンであり且つ分散され、放送局、受信機製造者、又はサードパーティのサービスプロバイダによって運用され得る。このようなアーキテクチャは、いずれかのサービスプロバイダに複数のブロードキャストストリームに関連付けられたメタデータを集約し公開する必要を避けることにより、大きな市場と運用上の利点を提供する。同様に、ＡＴＳＣ受信機製造者は、すべてのブロードキャストストリームに関連付けられたメタデータを集約し、公開するために、商用サービスプロバイダと協働することを必要とされない。

ＶＰ１透かし及び関連するシステムアーキテクチャは、透かし入れされたコンテンツの、１．５秒の持続時間を持つ５０ビットの透かしデータペイロードの使用に基づく。単一の検出された透かしは、フレーム（例えば、ミリ秒）精度で、埋め込みコンテンツのタイムコードとレシーバを同期させ、失われたいずれのメタデータと元の放送ストリームに関連した対話型サービスを回復するのに十分である。ＶＰ１透かしは、後続の検出のためにコンテンツに連続的に埋め込まれてもよい。例えば以下のようにすることができる。

（ａ）ＩＴＵ ＢＳ−１１１６−１「Ｓｕｂｊｅｃｔｉｖｅ Ａｓｓｅｓｓｍｅｎｔ ｏｆ Ｓｍａｌｌ Ａｕｄｉｏ Ｉｍｐａｉｒｍｅｎｔｓ」のテスト条件下で、音響品質は、「透明に近い」（すなわち、劣化度合が９５％の信頼度で、下限が−０．５より大きい）。

（ｂ）ペイロードの最初の検出の平均時間は、４８ ｋｂｐｓでＨＥ ＡＡＣ ｖ２を施した放送コンテンツについて、３秒未満である。

（ｃ）虚偽検出（すなわち、埋め込まれていないコンテンツから報告される検出）や誤検出（すなわち、コンテンツに埋め込まれているものとは異なるデータペイロードの検出）が、連続検出の５年に一回を超えない頻度で、検出器により報告される。虚偽の、又は誤った検出の場合に得られるデータペイロードは、定義されたコードの範囲全体に均一に分布する乱数値を有していると考えられることに留意されたい。あり得るコード値の多くは放送コンテンツに関連付けられないであろうから、虚偽又は誤検出に起因するユーザが触れるエラーの頻度は、上記よりも実質的に少ないであろう（すなわち、５年よりもよりさらに離れるであろう）。

（ｄ）ＶＰ１透かしの埋め込みは、４８ ｋＨｚオーディオチャンネル当たり毎秒２０メガの命令（ＭＩＰＳ）より多くの処理を要しない。

（ｅ）ＶＰ１透かしの検出は、マルチチャンネルオーディオプログラム当たり１０ ＭＩＰＳより多くの処理を要しない。

さらに、ＶＰ１の透かしは、透かしの上書きと透かしの消去をサポートし、コンテンツ作成又は流通チェーン内の任意のパーティを有効にして、すべてのダウンストリームの透かし機能を制御する。さらにＶＰ１は、他のアプリケーションのための他のデータペイロードを含む追加の直交透かしデータチャネル（多くの場合、「層」と呼ばれる）の運搬をサポートする。

ＶＰ１透かしに関連付けられた分散システムアーキテクチャは、電子透かし技術の標準化を可能にするだけでなく、標準化されたコード管理スキームと３つのネットワークプロトコルを含む。ＣｆＰの図２に記載された手法と互換性のあるアーキテクチャの例が、図６において提示される。図６を参照して、コード管理（またはドメイン管理）スキーム、システムコンポーネント機能、及び必要なプロトコルが以下のセクションで説明される。

先に説明した透かしペイロード構造と同様に、ＶＰ１の透かしは、３のフィールドを持つ透かしペイロードを含む。これらのフィールドは、サーバコード、インターバルコード、及びトリガを運ぶ。ＶＰ１透かしペイロード構造体のフィールドは、先に説明した透かし構造に適合し、サーバコードとインターバルコードは、ドメインＩＤとシーケンスＩＤに類似していることに留意すべきである。実施例のＶＰ１透かし構造が図７に示される。サーバコードは、独立したコード発行エンティティ（例えば、サーバレジストラント）の間で透かしコード空間を分割するためのメカニズムを提供するサーバーレジストラ（例えば、ＡＴＳＣ）により指定される、中央局で登録される値である。例えば、サーバコードは、作成するコンテンツ内のコードを管理し使用したいコンテンツ製作者、配信するコンテンツ内のコードを管理し使用したいネットワーク、またはそれらに代わって対話型サービスを管理したいサービスプロバイダによって登録され得る。サーバコードは、インターネットドメインに１対１のマッピングを提供することができるため、これらの独立したコード発行エンティティは、「ＡＴＳＣドメイン」と呼ばれる場合がある。ドメイン識別子は、サーバレジストラによって記録され、登録データベースのコピーを管理するサーバ検索サービスに発行され、そのサーバコードを埋め込まれたコンテンツに関連するメタデータをホストするサーバにアクセスすることができるインターネットドメイン名を発見するために、受信機によりアクセスされ得る。

サーバレジストラントは、割り当てられたサーバコードに関連付けられているすべてのインターバルコードの管理を調整することに関与する。各インターバルコード値は、放送コンテンツのインスタンスの特定の間隔に一意に関連付けられ得る。いくつかの実装形態では、インターバルは、透かしの持続時間（例えば、１．５秒）に等しいが、間隔内のタイミングを識別するように受信機を有効にする必要がない場合、より長くてもよい。割り当てられたサーバコードと、すべての関連するインターバルコードによって定義されるコードの範囲をコードドメインと呼ぶ。ＶＰ１透かしのトリガフィールドは、コンテンツソースからＡＴＳＣ受信機へのブーリアン信号であり、ＡＴＳＣ受信機が新しい対話型サービスコンテンツを問い合わせる必要があることを示す。

なお、図６に示されているいくつかのコンポーネントは、図１に類似する対照物を見ることができる。例えば、サーバレジストラとドメインレジストラ；コンテンツ、シグナリング及びメタデータサーバとドメインサーバ；及びサーバ検索サービス／サーバとドメインルックアップサーバは、類似の操作を実行し得る。図６における種々のコンポーネントは以下にさらに記載される。サーバレジストラは、ＡＴＳＣドメインを登録し、それぞれにユニークなサーバコードを割り当るためにＡＴＳＣによって確立される。レジストラントは、コードドメインに関連付けられたメタデータサービスが配置される、インターネットのドメイン名またはＵＲＬであるサーバ名をレジストラに通知する。サーバレジストラは、サーバルックアップサービスへ、サーバコードと関連するサーバ名を公開する。

１以上のサーバルックアップサービスが確立される。これらのサービスは、ＡＴＳＣ、サーバレジストラ、コンテンツオーナー、ＡＴＳＣ受信機製造者、又はサードパーティによって運用され得る。各サーバルックアップサービスは、サーバレジストラによって公開されるすべてのサーバコード/サーバ名の関連性のデータベースを維持し、ＡＴＳＣ受信機からのルックアップリクエストに応答する。サーバルックアップサービスは、放送メタデータのいずれもアクセスしたり格納したりする必要はない。それらは単に、放送透かしから検出されたサーバコードに関連付けられたサーバ名へのアクセスをＡＴＳＣ受信機へ提供する。

サーバレジストラントとして、又はサーバレジストラントと協調して機能するコンテンツソースは、有効に登録されたサーバコードと１つ以上のユニークなインターバルコードとを関連付け、それらを放送コンテンツエッセンスのインターバルにマップする。コンテンツソースは、ＭＶＰＤに放送コンテンツを配信する前に、透かし挿入器を使用して、放送コンテンツにこれらのコードを埋め込みする。放送エッセンス（例えば、任意の対話型コンテンツ、シグナリング、メタデータ、トリガ、チャネル識別子、メディアタイムラインのタイムコード等）のこれら同じ間隔のために、インターバルコードとメタデータは一緒に、コンテンツ、シグナリング、及びメタデータサーバ（「ＣＳＭサーバ」）に与えられるデータベースにおいて関連付けられる。コンテンツソースは、順次増大するインターバルコードを使用して、そのプログラム材料全体に継続的に透かしを関連付け、及び埋め込んでよく、対話型サービスが有効になっている場合に、コンテンツの間隔だけに透かしを埋め込んでよく、あるいは、対話型サービスが利用可能であるが、タイミング精度を必要としない場合、プログラムセグメントを通じて繰り返しインターバルコードを埋め込んでよい。コンテンツソースは、所与のサーバコードに関連付けられたインターバルコード空間が枯渇する前に、追加のコードドメインを登録してよく、インフラの継続性を維持するために、同じインターネットドメイン名で新たに割り当てられたサーバコードを関連付けてよい。

ＣＳＭサーバは、ＡＴＳＣ受信機からの様々なリクエストに応答し、それは、シグナリングと、完全な放送ストリームから受信した対話型サービスデータに基づく対話型コンテンツの配信とを含む。ＣＳＭサーバまた、コードメタデータクエリに応答し、透かしペイロードを含むクエリ（例えば、ＡＳＣＩＩ表現形式）が、放送コンテンツの間隔に関連付けられたメタデータを要求して、ＡＴＳＣ受信機のＷＭクライアントによって提出される。ＣＳＭサーバの応答に含まれるメタデータは、チャネル識別子、タイムコード、コンテンツ又はセグメント識別子、トリガ等（これらは、ＣｆＰにおいて、「伝えるべき情報」と呼ばれる）を含む場合がある。メタデータサービスは、コンテンツ及びシグナリングサービスと同じサーバでホストされる場合があるが、代わりに、コンテンツ及びシグナリングサービスに使用されるものとは異なるサーバでホストされてもよいことに留意すべきである。

ＡＴＳＣ受信機（レシーバ）は、ＳＴＢを介してＭＶＰＤから完全なＡＴＳＣ放送ストリームは欠いている放送コンテンツのエッセンスを得る場合がある。ＡＴＳＣ受信機は、いずれかの埋め込みコードを検出するために、透かしクライアントにコンテンツエッセンスを提供し得る。所与の製品における透かしクライアントの実装の一部として、サーバコードとサーバ名との間の関連付けがキャッシュ（例えば、メモリデバイス）内に保存され得、それはまた、新たに登録又は変更されたサーバ名をルックアップするように、サーバルックアップサービスのインターネットアドレスを含み得る。キャッシュは、サーバルックアップサービスへのトラフィックを減らすために、ＡＴＳＣ受信機の製造時にプレポピュレートされてよい。

透かしクライアントは、再生されているコンテンツに埋め込まれた透かしペイロードを検出すると、検出されたサーバコードがキャッシュに存在するかどうかを調べる。存在する場合、透かしのクライアントは、そのサーバ名がサーバコード関連付けられているＣＳＭサーバを照会し、検出した透かしペイロードに関連付けられているメタデータを取得する。検出された透かしからのサーバコードがキャッシュに存在しない場合、又は接続サーバが期待通りに応答しない場合、透かしクライアントはサーバルックアップサービスからサーバコードに関連付けられた現用サーバ名をルックアップし、結果をキャッシュしてよく、その後、新たに識別されたサーバ名に向けてクエリを開始する。

透かしクライアントは、ある透かしの検出のためのみにクエリを開始するように構成されてよい（例えば、再生開始後の最初のもの、チャネル変更後の最初のもの、過去、例えば、３０秒以内にクエリが行われていない場合に設定されるトリガフィールドを有するもののみ等）。ＣＳＭサーバによって透かしクライアントに提供されるタイムコードのメタデータは、透かし検出プロセスから回復されたデータとともに使用されてよく、フレーム精度又はミリ秒の精度で、放送コンテンツの元のメディアタイムコードを決定することができる。

図６に示されているアーキテクチャを有効にするために、次の３つのネットワークプロトコル（ＰＵＢＬＩＳＨ、ＬＯＯＫＵＰ、及びＱＵＥＲＹ）についてオープンスタンダードが提供され得る。

ＰＵＢＬＩＳＨは、サーバレジストラがサーバコードとインターネットドメイン名との間に新たに設立された、又は更新されたマッピングを、関与するエコシステム参加者へ通知し、関連をサーバルックアップサービスへパブリッシュするプロトコルである。

ＬＯＯＫＵＰは、ＡＴＳＣ受信機がサーバルックアップサービスへサーバコードを提出し、サーバレジストラによって直近にパブリッシュされた関連のサーバ名を含む応答を受信することができるプロトコルである。

ＱＵＥＲＹは、ＡＴＳＣ受信機が、ＣＳＭサーバにサーバコードやインターバルコードを送信し、放送コンテンツの特定の間隔に関連付けられているＡＴＳＣメタデータ（例えば、チャネル、タイムコード、対話型サービストリガ等）を受信することができるプロトコルである。

ＣｆＰは、さらに、関連アーキテクチャが、その透かし関連の要求のすべてで受信機製造者によって指定されたメタデータサーバにアクセスするようにプログラムされた受信機を持つことに依存する、図２のシナリオについて説明する。本出願の開示されたアーキテクチャは、このようなモデルを採用したい受信機製造者による当該アプローチの使用をサポートする。このような構成において、「コードＤＢ及びメタデータサーバ」は、領域内の全てのブロードキャスターのための完全な放送ストリームへのアクセス権を持ついずれかの「メタデータサーバ」オペレータによってポピュレートされ得る（「イタリック体」の用語は、ＣｆＰの図２から取られている）。同じサービスプロバイダが、放送ストリームからの透かし検出、及びメタデータのリカバリを実行することができ、メタデータサーバで使用するために、それらの「コードＤＢ」をポピュレートすることができる。透かしの仕様がオープンであるため、コンテンツソースは、特定の「メタデータサーバ」オペレータと提携する透かし挿入器を使用する必要はなく、「メタデータサーバ」オペレータは任意のブロードキャスターによって埋め込まれた透かしを回復することができる。

非常に具体的な例として、「コードＤＢ」と「コンテンツ及びシグナリングサーバ」は、領域内のすべてのブロードキャスターについて完全な放送ストリームへのアクセス権を持つ任意の自動コンテンツ認識（ＡＣＲ）サービスプロバイダによってポピュレートされ得る。ＡＣＲサービスプロバイダは、「コンテンツ及びシグナリングサーバ」による使用のためにそれらの「コードＤＢ」を配置するように、放送ストリームから透かし検出及びメタデータリカバリを実行し得る。透かしの仕様がオープンであるため、「コンテンツソース」は、特定のＡＣＲサービスプロバイダと提携する「透かし挿入器」を使用する必要はなく、いずれのＡＣＲサービスプロバイダも任意のブロードキャスターによって埋め込まれた透かしを回復することができる。

このような閉じたエコシステム内のＡＴＳＣ受信機は、ＬＯＯＫＵＰ又はＱＵＥＲＹのプロトコルを採用する必要はなく、代わりに、「メタデータサーバ」オペレータによって（例えば、ＡＣＲサービスプロバイダによって）生成されたプライベートエコシステム内のサービスにアクセスするために、プライベートなプロトコルに依存し得る。そのような受信機はシームレスに、本出願に記載される標準化されたプロトコル及びインフラストラクチャを利用する他のＡＴＳＣ受信機と一緒に共存することができる。

以下は、本出願のある実施形態に従って、コード構造及びペイロード符号化の詳細な実施例を提供する。前に、図７に関連して説明された具象構造は、５０ビットペイロードよりも大きな空間をサポートする。以下のセクションでは、我々は、より効率的な手法で、必要なシグナリングを提供するために適切に使用することができるコード空間のサブセットを定義する。我々はさらに、透かしのペイロードに符号化するために提案された手法を説明する。

図８（Ａ）は、一つの実施形態に従って、実施例の透かし構造を図示する。図８（Ａ）に示すように、５０ビットの透かしペイロードは、２つのトップレベルのフィールド、ペイロードタイプフィールド（２ビット）及びペイロードフィールド（４８ビット）に分割される。ペイロードタイプフィールドは、図８（Ｂ）に示すようにマッピングし、ペイロードフィールドのフォーマットを記述する。大ドメイン、中ドメイン、及び小ドメインフィールドの構造が図８（Ｃ）に示される。図８（Ｃ）中の４８ビットのペイロードフィールドのそれぞれは、サーバフィールド、インターバルフィールド、及びトリガフィールドを含む。

サーバコードは、（（ＰＴ＜＜３０）＋ＳＦ）により、３のドメインタイプのいずれかのサーバフィールドに関連し、ここで、＜＜３０は、３０ビットのビット単位の左シフトであり、ＰＴはペイロードタイプの値であり、ＳＦは、サーバフィールドの値である。図８（Ｄ）は、この手法でのサーバコードのサポート範囲と、コードドメインごとのインターバルコードのサポート範囲のリストを提供する。サポートの範囲外のコードは予備と考えられる。この構成は、さまざまなサイズのコードドメインの割り当てをサポートし、効率的なコード空間の使用を助ける。図８（Ｅ）のテーブルは、上記の手法で割り当てられる各タイプのドメイン数と、各ドメインタイプがサポートすることができる、連続して放送される、一意に埋め込まれたコンテンツの量（放送コンテンツの１．５秒当たり１のユニークコードを仮定）をまとめたものである。サーバレジストラントは、登録時に必要なドメインのサイズ（小、中、又は大）を選択し得る。

開示された実施形態のある態様は、プロセッサ、及びプロセッサ実行可能なコードを備えるメモリを含むデバイスとして実装することができる。プロセッサ実行可能コードは、プロセッサによって実行されるとき、本出願に記載されるいずれか一つ、及び／又はすべての操作のいずれかを実行するようにデバイスを構成する。

図９は、種々の開示された実施形態を実装することができるデバイス９００のブロック図を示す。図９のデバイスは、図１に示されている受信装置、セットトップボックス、ドメインメンバ、ドメインレジストラント又はドメインレジストラのいずれかの一部として実装することができる。デバイス９００は、少なくとも１つのプロセッサ９０４及び／又はコントローラ、プロセッサ９０４と通信する少なくとも１つのメモリ９０２ユニット、通信リンク９０８を介して、他のエンティティ、デバイス、データベースやネットワークと直接又は間接にデータ及び情報を交換することを可能にする、少なくとも１つの通信ユニット９０６を含む。通信ユニット９０６は、１つ以上の通信プロトコルに従って、有線及び／又は無線の通信機能を提供することができ、それゆえ、それは適切な送信機／受信機、アンテナ、回路及びポート、並びに、データ及び他の情報の適切な送信及び／又は受信のために必要な符号化／復号化機能を含み得る。図９の例示的なデバイス９００は、開示された方法のいずれかを実行するために、図１に示された任意のデバイス又はコンポーネントの一部として一体化されてよい。

図１０は、マルチメディアコンテンツに関連するメタデータを取得するための例示的な実施形態に従って実施され得る例示的な一連の操作を示す。１００２において、コンテンツは、透かし検出器を備えた受信装置で受信される。受信されたコンテンツは、例えば、マルチメディアコンテンツの部分又はコンポーネント（例えば、オーディオ又はビデオ成分）から成る場合がある。１００４において、一つ以上の埋め込み透かしのペイロードを抽出するために、受信したコンテンツに対して透かし検出が実行される。ペイロードは、サーバ識別子を含む第１のフィールドと、サーバ識別子と関連付けられたインターバル識別子を含む第２のフィールドを含む。第１のフィールドは、透かしペイロードによって識別されるコンテンツセグメントに関連付けられたメタデータを取得するためにアクセス可能なインターネットアドレスへのマッピングを提供する。１００６で、検出された透かしペイロードに基づいてクエリが形成され、クエリは、インターネットアドレスによって識別されるサーバに送信される。１００８で、クエリに対する応答がサーバから受信される。応答は、コンテンツに関連するメタデータを含む。

開示された実施形態の一つの態様は、ドメインルックアップサーバとレジストラントサーバを含むシステムに関する。ドメインルックアップサーバは、受信機からのルックアップリクエストを受信するように構成され、要求は、マルチメディアコンテンツから抽出された透かしから取得したサーバコードを含む。ドメイン検索サーバは、レジストラサーバからサーバコードに関連付けられたサーバ名を受信することができ、さらに受信機に送信するための応答を提供する。ドメインルックアップサーバの応答は、サーバ名を含む。システムのレジストラントサーバは、マルチメディアコンテンツに関連付けられた少なくともメタデータが配置されたメタデータサーバ、及び電子回路を用いて実装されるプロセッサを含み、又は通信し、レジストラントサーバに割り当てられたサーバコードをレジストラサーバから受信し、マルチメディアコンテンツの１つ以上のセグメントに対応する１つまたはそれ以上のインターバルコードを割り当て、及び、それぞれ割り当てられたインターバルコードと関連するメタデータを含む情報をメタデータサーバに通信する。

例示的な一実施形態では、上記システムは、さらに、レジストラントサーバに結合された透かし挿入器を含む。透かし挿入器は、サーバコード及びマルチメディアコンテンツの一つ以上のインターバルコードを受信し、サーバコード及び一つ以上のインターバルコードを透かしとしてマルチメディアコンテンツに埋め込むように構成される。もう一つの実施形態では、システムはまた、透かし挿入器に結合されているコンテンツブロードキャスターと通信する。コンテンツブロードキャスターは、埋め込まれたマルチメディアコンテンツを受信し、受信機に埋め込まれたマルチメディアコンテンツを送信し得る。いくつかの実装形態では、システムはまた、受信機、及び受信機に結合されたセットトップボックス（ＳＴＢ）を含む。ＳＴＢは、埋め込みマルチメディアコンテンツをコンテンツブロードキャスターから受信し、受信された埋め込みマルチメディアコンテンツの少なくとも一つのコンポーネントを受信機に提供するように構成される。いくつかの実装形態で、少なくとも一つのコンポーネントは、マルチメディアコンテンツのオーディオコンポーネントである。

一つの実施形態に従って、上記システムはさらに、一つ以上の追加のコンテンツレジストラントサーバを含み、一つ又は複数の追加のレジストラントサーバのそれぞれは、レジストラサーバ及びメタデータサーバに結合される。各レジストラントサーバは、レジストラサーバから、対応するレジストラントサーバに割り当てられるユニークなサーバコードを受信するために、電子回路を用いて実装される、対応プロセッサを含む。さらに、各レジストラントサーバは、レジストラントサーバのユニークなサーバコードと関連し、マルチメディアコンテンツの１つ以上のセグメントに対応する一つ又は複数のインターバルコードを割り当てることができる。各レジストラントサーバは、さらに、レジストラントサーバの割り当てインターバルコード（複数可）、及び関連するメタデータを含む情報を、メタデータサーバへ通信することができる。一つの例示的な実装形態では、透かし挿入器は、追加のレジストラントサーバのうちの少なくとも一つに結合され、追加のレジストラントサーバのうちの少なくとも一つに対応するサーバコード及びインターバルコードを受信し、及び、追加のレジストラントサーバのうちの少なくとも一つに対応するサーバコード及びインターバルコードを、透かしとして、マルチメディアコンテンツに埋め込むことができる。

別の実施形態では、透かし挿入器は、追加のレジストラントサーバの少なくとも一つに対応するサーバコード及びインターバルコードを、別のレジストラントサーバのサーバコード及びインターバルコードより異なる透かし層としてマルチメディアコンテンツに挿入するように構成される。さらに別の実施形態では、受信機は、少なくとも２つのユニークなサーバコードを取得するために少なくとも２つの透かしの層から埋め込み透かしを検出し、さらに、ユニークなサーバコードの一方又は両方をルックアップサーバに送信し、応答において、ユニークなサーバコードの一方又は両方に関連付けられているサーバ名を、ドメインルックアップサーバから受信するように構成される。

開示された実施形態に関連して記載されるコンポーネント又はモジュールは、ハードウェア、ソフトウェア、又はそれらの組合せとして実装され得る。例えば、ハードウェア実装は、例えば、プリント回路基板の一部として集積された個別のアナログ及び／又はデジタルコンポーネントを含み得る。代替的に、又は追加的に、開示されるコンポーネント又はモジュールは、特定用途向け集積回路（ＡＳＩＣ）、及び／又はフィールドプログラマブルゲートアレイ（ＦＰＧＡ）デバイスとして実装され得る。いくつかの実装では、追加的または代替的に、本出願の開示された機能に関連付けられているデジタル信号処理の動作の必要性のために最適化されたアーキテクチャを有す専門のマイクロプロセッサであるデジタルシグナルプロセッサ（ＤＳＰ）を含む。

本明細書に記載されるさまざまな実施形態は、方法又はプロセスの一般的な文脈で記載され、一つの実施形態では、コンピュータ記録媒体で具現化される、ネットワーク環境にあるコンピュータによって実行されるプログラムコード等のコンピュータ実行可能命令を含む、コンピュータプログラム製品によって実装され得る。コンピュータ記録媒体は、これらに限定されないが、リードオンリーメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、コンパクトディスク（ＣＤ）、デジタル多用途ディスク（ＤＶＤ）、ブルーレイディスク等を含む、リムーバブル及び非リムーバブルストレージデバイスを含んでよい。従って、本出願に記載されたコンピュータ記録媒体は、非一過性記憶媒体を含む。一般に、プログラムモジュールは、特定のタスクを実行する、または特定の抽象データ型を実装する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造等を含んでよい。コンピュータ実行可能命令、関連データ構造、及びプログラムモジュールは、本明細書に開示される方法のステップを実行するためのプログラムコードの実施例を示す。そのような実行可能命令の特定のシーケンス又は関連データ構造は、そのようなステップ又はプロセスにおいて説明される機能を実装するための対応する行動（act）の実施例を示す。

例えば、開示された実施形態の一態様は、非一過性コンピュータ記録媒体に具現化されるコンピュータプログラム製品に関する。コンピュータプログラム製品は、開示された実施形態の動作のいずれか一つ、及び/又は全てを実行するためのプログラムコードを含む。

実施形態の前述の説明は、例示および説明のために提示された。前述の説明は、網羅的であることや、本発明の実施形態を開示された厳密な形態に限定するものではなく、修正および変形は、上記の教示に照らして可能であり、あるいは、さまざまな実施形態の実践から取得され得る。本明細書で説明した実施形態は、さまざまな実施形態及び実際的な用途の原理及び本質を説明するために選択され記載され、当業者が、さまざまな実施形態において、あるいは、企図された特定の使用に適するようにさまざまな修正を伴って、本発明を利用することを可能する。本明細書に記載の実施形態の特徴は、方法、装置、モジュール、システム、およびコンピュータプログラム製品の全ての可能な組み合わせにおいて、並びに異なるシーケンシャル順序で組み合わせることができる。任意の実施形態がさらに、任意の他の実施形態と組み合わせられてよい。

Claims (28)

1. マルチメディアコンテンツについて関連する情報を取得するための方法であって、
   透かし検出器を備えた受信装置でコンテンツを受信することと、
   一つ以上の埋め込み透かしペイロードを抽出するために、前記受信されたコンテンツの透かし検出を実行することであって、前記ペイロードが、サーバ識別子を含む第１のフィールドと、前記サーバ識別子に関連付けられたインターバル識別子を含む第２のフィールドとを含み、前記第１のフィールドが、前記透かしペイロードによって識別されたコンテンツセグメントに関連付けられたメタデータを検索するためにアクセス可能なインターネットアドレスへのマッピングを提供する、実行することと、
   検出された透かしペイロードに基づいて、クエリを形成し、該クエリを前記インターネットアドレスによって識別されたサーバへ送信することと、及び
   前記クエリへの応答を前記サーバから受信することであって、前記応答が前記コンテンツに関連付けられたメタデータを含む、方法。
2. 前記第１のフィールドの値が中央局によってドメインレジストラントに割り当てられ、それぞれのドメインレジストラントが、前記第２のフィールドの割り当て及び使用を制御することを特徴とする請求項１に記載された方法。
3. 前記第１のフィールドと前記インターネットアドレスとの対応が、少なくとも部分的にレジストラサーバによって予め確立されていることを特徴とする請求項１に記載された方法。
4. 前記マッピングが、前記受信装置においてメモリ内に記憶されることを特徴とする請求項１に記載された方法。
5. 前記受信装置が、前記第１のフィールドを含む、ルックアップサーバへのルックアップ要求に応答して、前記マッピング及び前記インターネットアドレスを受信することを特徴とする請求項１に記載された方法。
6. 前記クエリが、前記インターバル識別子の特定の値に対応する前記メタデータを取得するために用いられる標準化されたクエリであることを特徴とする請求項１に記載された方法。
7. 前記ペイロードが、前記インターバル識別子によって識別されるコンテンツインターバルに関連付けられた前記メタデータの可用性を示す第３のフィールドを含むことを特徴とする請求項１に記載された方法。
8. 前記第３のフィールドの値の変化が検出されると前記クエリが形成され前記サーバへ送信されることを特徴とする請求項７に記載された方法。
9. 前記ペイロードがさらに、該ペイロードが小ドメイン、中ドメイン、又は大ドメインのうちの一つに対応することを識別するペイロードタイプフィールドを含むように構成されることを特徴とする請求項１に記載された方法。
10. 前記ペイロードが５０ビット長であり、前記ペイロードタイプフィールドが２ビットフィールドであることを特徴とする請求項９に記載された方法。
11. 前記第１のフィールドがサーバコードを特定し、前記第２のフィールドが前記コンテンツの特定のインターバルに関連付けられるインターバルコードを特定し、それぞれのサーバコードが、中央局によって、コンテンツプロデューサー、コンテンツディストリビューター、又はサービスプロバイダのうちの一つに割り当てられることを特徴とする請求項１に記載された方法。
12. 前記メタデータが、前記受信装置に、前記インターバル識別子によって識別されたコンテンツインターバルに関連付けられる特定の対話型サービスを実行することを許可する命令を含むことを特徴とする請求項１に記載された方法。
13. メタデータが、
    対話型サービスサーバのインターネットアドレス、又は、
    いつどのような方法で対話型サービスが構成可能かを示す一つ又は複数のパラメータのうちの一つ又は複数を識別することを特徴とする請求項１に記載された方法。
14. マルチメディアコンテンツを受信可能なデバイスであって、
    前記受信されたマルチメディアコンテンツから一つ又は複数の透かしを検出するための、少なくとも部分的に電子回路を用いた実装の透かし検出器であって、前記検出される透かしが、サーバ識別子を含む第１のフィールドと、前記サーバ識別子に関連付けられたインターバル識別子を含む第２のフィールドとを含み、前記第１のフィールドが、前記透かしペイロードにより識別されるコンテンツセグメントに関連付けられたメタデータを検索するためにアクセス可能なインターネットアドレスへのマッピングを提供する、透かし検出器と、
    プロセッサと、プロセッサ実行可能命令が具現化されるメモリであって、前記命令は実行により、前記プロセッサにクエリを形成させる、プロセッサ及びメモリと、
    前記インターネットアドレスによって識別されるサーバへ前記クエリを送信し、前記サーバから前記クエリに対する応答を受信するための、少なくとも部分的に電子回路を用いた実装の通信コンポーネントを含み、前記応答が前記コンテンツに関連付けられたメタデータを含む、通信コンポーネントと、を含むデバイス。
15. 前記第１のフィールドの値が中央局によってドメインレジストラントへ割り当てられ、それぞれのドメインレジストラントが、前記第２のフィールドの割当及び使用を制御することを特徴とする請求項１４に記載されたデバイス。
16. 前記第１のフィールドと前記インターネットアドレスとの対応が、少なくとも部分的にレジストラサーバによって予め確立されることを特徴とする請求項１４に記載されたデバイス。
17. 前記マッピングが前記受信デバイスに記憶され、前記第１のフィールドに基づいて、前記インターネットアドレスを検索するために、前記受信デバイスによる使用のためにアクセス可能であることを特徴とする請求項１４に記載されたデバイス。
18. 前記通信コンポーネントが、前記第１のフィールドを含むルックアップ要求をルックアップサーバへ送信し、前記ルックアップ要求に応答して、前記マッピング及び前記インターネットアドレスを受信するように構成されることを特徴とする請求項１４に記載されたデバイス。
19. 前記プロセッサによって実行される前記命令が、前記第１のフィールドの値に基づいてルックアップクエリを形成し、前記通信コンポーネントが、前記ルックアップ要求をルックアップサーバへ送信し、前記インターネットアドレスを受信するように構成され、前記プロセッサによって実行される前記命令がさらに、前記インターネットアドレス及び前記インターバル識別子の特定の値に基づいて標準化されたクエリとして前記クエリを形成し、前記通信コンポーネントがさらに、前記標準化されたクエリをサーバへ送信し、前記インターバル識別子の前記特定の値に対応するメタデータを受信するように構成されることを特徴とする請求項１４に記載されたデバイス。
20. 前記ペイロードが、前記インターバル識別子によって識別されるコンテンツインターバルに関連付けられたメタデータの可用性を示す第３のフィールドを含むことを特徴とする請求項１４に記載されたデバイス。
21. 前記プロセッサによって実行される命令が、前記第３のフィールドの値の変化を検知すると、前記クエリを形成することを特徴とする請求項２０に記載されたデバイス。
22. 前記ペイロードがさらに、該ペイロードが、小ドメイン、中ドメイン、又は大ドメインの一つに対応することを同定するペイロードタイプフィールドを含むように構成されることを特徴とする請求項１４に記載されたデバイス。
23. 前記ペイロードが５０ビット長であり、前記ペイロードタイプフィールドが２ビットフィールドであることを特徴とする請求項１４に記載されたデバイス。
24. 前記第１のフィールドがサーバコードを特定し、前記第２のフィールドが前記コンテンツの特定のインターバルに関連付けられたインターバルコードを特定し、それぞれのサーバコードが中央局によって、コンテンツプロデューサー、コンテンツディストリビューター、又はサービスプロバイダの一つに割り当てられることを特徴とする請求項１４に記載されたデバイス。
25. 前記プロセッサによって実行される命令が、前記プロセッサに、前記インターバル識別子によって識別されるコンテンツインターバルに関連付けられた特定の対話型サービス実行するために前記メタデータを使用させることを特徴とする請求項１４に記載されたデバイス。
26. 前記メタデータが、
    対話型サービスサーバのインターネットアドレス、又は、
    いつどのような方法で対話型サービスが構成可能かを示す一つ又は複数のパラメータのうちの一つ又は複数を識別することを特徴とする請求項１４に記載されたデバイス。
27. 一つ又は複数の非一過性コンピュータ記録媒体上で具現化されるコンピュータプログラム製品であって、
    透かし検出器を備える受信装置でコンテンツを受信するためのプログラムコードと、
    一つ又は複数の埋め込み透かしのペイロードを抽出するために前記受信されたコンテンツについて透かし検出を実行するプログラムコードであって、前記ペイロードが、サーバ識別子を含む第１のフィールドと、前記サーバ識別子に関連付けられたインターバル識別子を含む第２のフィールドとを含み、前記第１のフィールドが、前記透かしペイロードにより識別されるコンテンツセグメントに関連付けられたメタデータを検索するためにアクセス可能なインターネットアドレスへのマッピングを提供する、プログラムコードと、
    前記検出された透かしペイロードに基づいて、クエリを形成し、該クエリを、前記インターネットアドレスによって識別されたサーバへ送信するためのプログラムコードと、
    前記サーバから前記クエリに対する応答を受信するためのプログラムコードであって、前記応答が前記コンテンツに関連付けられたメタデータを含む、プログラムコードと、を含むコンピュータプログラム製品。
28. デバイスであって、
    プロセッサと、
    プロセッサ実行可能コードを含むメモリと、を含み、
    前記プロセッサにより実行されるとき前記プロセッサ実行可能コードが、
    マルチメディアコンテンツに埋め込まれた一つ又は複数の透かしを抽出することであって、該抽出された透かしが、サーバ識別子を含む第１のフィールドと、前記サーバ識別子に関連付けられたインターバル識別子を含む第２のフィールドとを含むペイロードを含み、前記第１のフィールドが、前記透かしペイロードにより識別されるコンテンツセグメントに関連付けられたメタデータを検索するためにアクセス可能なインターネットアドレスへのマッピングを提供する、抽出することと、
    クエリを形成することと、
    前記インターネットアドレスによって識別されるサーバへ前記クエリを送信することと、
    前記サーバから前記クエリに対する応答を受信することであって、前記応答が前記コンテンツに関連付けられたメタデータを含む、受信することと、を前記デバイスに行わせる、デバイス。