(57)【要約】  デジタル映画フィーチャ・プレゼンテーションを伴う補助コンテンツ（例えば、広告）のプレイアウトを追跡するための方法とシステムは、先ず、補助コンテンツがプレイアウトされている間に当該補助コンテンツに関連付けられた補助コンテンツ・ファイル内の識別情報を検出する。検出された識別情報がアクティブである時間が求められる。その後、補助コンテンツ・ファイル（複数可）と、識別情報が検出された識別情報アクティビティの長さの両方を記録して、プレイアウトされた補助コンテンツ・ファイルを追跡する。
2015507286.tif 000002
【特許請求の範囲】
【請求項１】
第１のデジタル映画構成のプレイアウトを追跡するための方法であって、
ａ）前記第１のデジタル映画構成がプレイアウトされている間に第１の補助コンテンツに対応する第１の識別情報を検出するステップであって、前記識別情報は、前記第１のデジタル映画構成、前記第１のデジタル映画構成のリール、前記第１の補助コンテンツを含む補助コンテンツ・ファイル、および前記第１の補助コンテンツの少なくとも一部のうち１つに固有であるステップと、
ｂ）再生された前記構成を代表する第１のデータを前記識別情報に基づいてログに取るステップと、
を含む、前記方法。
【請求項２】
ｃ）前記第１のデジタル映画構成の特定の部分が再生されたことを少なくとも前記識別情報から立証するステップと、
をさらに含み、前記データはさらに前記特定の部分を代表する、請求項１に記載の方法。
【請求項３】
ｃ）前記第１のデジタル映画構成の特定の部分が再生されたことを少なくとも前記識別情報から立証するステップと、
をさらに含み、前記ログに取るステップが、前記特定の部分が少なくとも前記第１のデジタル映画構成の所定の部分であることに応答して行われる、請求項１に記載の方法。
【請求項４】
前記識別情報はキャプションに存在する、請求項１に記載の方法。
【請求項５】
前記識別情報はサブタイトルに存在する、請求項１に記載の方法。
【請求項６】
前記識別情報はリソース表示リストに存在する、請求項１に記載の方法。
【請求項７】
前記識別情報はリール識別データに存在する、請求項１に記載の方法。
【請求項８】
ｃ）ステップａ）およびｂ）を複数の構成に対して繰り返し実施するステップと、  ｄ）どの構成が再生されたかを示すレポートを前記データに基づいて生成するステップと、
をさらに含む、請求項１に記載の方法。
【請求項９】
ｄ）ステップａ）、ｂ）、およびｃ）を複数の構成に対して繰り返し実施するステップと、
ｅ）どの構成がどの特定の部分に対して再生されたかを示すレポートを前記データに基づいて生成するステップと、
をさらに含む、請求項３に記載の方法。
【請求項１０】
ｃ）第２のデジタル映画構成に対応する第２の識別情報を検出するステップであって、前記第２のデジタル映画構成はフィーチャである、ステップと、
ｄ）再生された前記第２のデジタル映画構成を代表する第２のデータを前記第２の識別情報に基づいてログに取るステップであって、前記第２のデータはさらに前記第２のデジタル映画構成の第１の開始時刻を含む、ステップと、
をさらに含み、
前記第１のデータはさらに前記第１のデジタル映画構成の第２の開始時刻を含み、
前記第１の構成が前記第２の構成の前の所定期間内に再生されたかどうかを前記第１の開始時刻と前記第２の開始時刻を比較することによって判定することができる、請求項１に記載の方法。
【請求項１１】
ｅ）ステップａ）およびｂ）を複数の第１の構成の各々に対して繰り返し実施するステップと、
ｆ）前記複数の第１の構成が再生されたことを前記第１のデータに基づいて示すレポートを生成するステップであって、前記レポートはさらに、前記第２の構成の前の前記所定期間内に再生された第１の構成を示すステップと、
を含む、請求項１０に記載の方法。
【請求項１２】
第１のデジタル映画構成のプレイアウトを追跡するためのシステムであって、
ａ）前記第１のデジタル映画構成がプレイアウトされている間に、第１の補助コンテンツに対応する第１の識別情報を検出し、前記識別情報は、前記第１のデジタル映画構成、前記第１のデジタル映画構成のリール、前記第１の補助コンテンツを含む補助コンテンツ・ファイル、および前記第１の補助コンテンツの少なくとも一部のうち１つに固有であり、ｂ）再生された前記構成を代表する第１のデータを前記識別情報に基づいてログに取るためのプレイアウト監視モジュールを備えた、前記システム。
【請求項１３】
前記プレイアウト監視モジュールはさらに、（ｃ）前記構成の特定の部分が再生されたことを少なくとも前記第１の識別情報から立証し、前記データはさらに前記特定の部分を代表する、請求項１２に記載のシステム。
【請求項１４】
前記プレイアウト監視モジュールさらに、（ｃ）前記構成の特定の部分が再生されたことを少なくとも前記第１の識別情報から立証し、前記ログに取ることは、前記特定の部分が少なくとも前記構成の所定の部分であることに応答して行われる、請求項１２に記載のシステム。
【請求項１５】
前記識別情報はキャプションに存在する、請求項１２に記載のシステム。
【請求項１６】
前記識別情報はサブタイトルに存在する、請求項１２に記載のシステム。
【請求項１７】
前記識別情報はリソース表示リストに存在する、請求項１２に記載のシステム。
【請求項１８】
前記識別情報はリール識別データに存在する、請求項１２に記載のシステム。
【請求項１９】
前記補助コンテンツ・ファイルと識別情報を格納するためのデータベースをさらに備える、請求項１２に記載のシステム。
【請求項２０】
前記プレイアウト監視モジュールは、どの補助コンテンツ・ファイルがどれだけ長く再生されるかを、ログに取った前記補助コンテンツ・ファイルと識別情報のアクティビティに従って示すレポートを生成する、請求項１２に記載のシステム。
【請求項２１】
前記プレイアウト監視モジュールはさらに、（ｃ）第２のデジタル映画構成に対応する第２の識別情報を検出し、前記第２のデジタル映画構成はフィーチャであり、（ｄ）再生された前記第２のデジタル映画構成を代表する第２のデータを前記第２の識別情報に基づいてログに取り、前記第２のデータはさらに前記第２のデジタル映画構成の第１の開始時刻を含み、前記第１のデータはさらに前記第１のデジタル映画構成の第２の開始時刻を含み、前記第１の構成が前記第２の構成の前の所定期間内に再生されたかどうかを前記第１の開始時刻と前記第２の開始時刻を比較することによって判定することができる、請求項１２に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の記載
本願は、２０１２年１月３１日に出願した米国仮特許出願第６１／５９２、６７４号に対する優先権を米国特許法第１１９条（ｅ）に基づいて主張し、その教示事項を本明細書に取り込む。
【０００２】
本発明は、デジタル映画構成のプレイアウトを追跡するための技術に関する。
【背景技術】
【０００３】
デジタル映画を視聴者に提供することに関して、１つまたは複数の広告には一般にフィーチャ・プレゼンテーションと何らかのトレーラを伴う。ＳＭＰＴＥ（Ｓｏｃｉｅｔｙ  ｏｆ  Ｍｏｔｉｏｎ  Ｐｉｃｔｕｒｅ  ａｎｄ  Ｔｅｌｅｖｉｓｉｏｎ  Ｅｎｇｉｎｅｅｒｓ）およびＤＣＩ（Ｄｉｇｉｔａｌ  Ｃｉｎｅｍａ  Ｉｎｉｔｉａｔｉｖｅ）は、デジタル映画に関する標準を開発する２つの標準組織であり、双方とも「デジタル映画構成」という用語を用いて、フィーチャ・プレゼンテーション、広告およびトレーラを含むデジタル映画コンテンツを参照する。実際には、広告は、フィーチャ・プレゼンテーションに先立ってプレイアウトするトレーラに先立ってプレイアウトする。大抵の事例では、映画館主（例えば、映画館の所有者）は、トレーラとフィーチャ・プレゼンテーションを含む広告を拒否することができる。例えば、特定のブランドのソフト・ドリンクを提供する映画館の運営者は、競合するソフト・ドリンクの広告を拒否することができる。さらに、映画館の所有者は、Ｇ評価のフィーチャ・プレゼンテーションに先立って表示するのに不適切な特定の広告を拒否することができる。幾つかの事例では、映画館の所有者は現在のフィーチャ・プレゼンテーションが遅れている場合には一定の割合の広告を落とすことができる。
【０００４】
契約上、広告主は実際に表示される広告に対して料金を支払い、プレイアウトするようにスケジュールされているがプレイアウトされない広告には料金を支払わない。したがって、各広告のプレイアウトの確認は広告主と映画館の運営者の両方にとって重要となる。
【０００５】
歴史的には、幾つかの映画館は専用の広告プレイヤに依存している。当該プレイヤは、フィーチャ・プレゼンテーションに対するものと同じプロジェクタか、または、広告プレイアウト専用の別個のプロジェクタの何れかを使用する。専用広告プレイヤの例には、カリホールニア州バーバンクのＥｌｅｃｔｒｏｓｏｎｉｃ社により製造され、ニューヨーク州ニューヨークのＳｃｒｅｅｎｖｉｓｉｏｎ  Ｃｉｎｅｍａ  Ｎｅｔｗｏｒｋ社により開発されたＥＳＣＡＮスケジューリング・システムと関連して使用されるＭＳ９４００  ＨＤ  ＦｒＥＮＤ  マルチメディアプレイヤモジュールがある。かかるシステムには、広告ブローカに対して後でレポートするための専用広告プレイヤによりプレイアウトされた各広告を記録するための機能を有する。
【０００６】
デジタル映画が急増するにつれ、一部の映画館主は、別個の専用プレイヤよりも、主要なデジタル映画プロジェクタおよびデジタル映画サーバから直接広告をプレイアウトすることを好む。このアプローチでは、複数のシステムの相互接続における複雑度が一部軽減され、プロジェクタまたはオーディオ・サブシステムが間違った信号源に着目する（例えば、フィーチャ・プレゼンテーションが表示されている間に当該フィーチャ・プレゼンテーションに関連付けられたオーディオを再生するのではなく、広告に関連付けられたオーディオを再生する）可能性を排除する。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】米国特許第５，５７０，９４４号明細書
【発明の概要】
【発明が解決しようとする課題】
【０００８】
一部のデジタル映画サーバは、デジタル映画構成のプレイアウトの自動記録を備える。実際、暗号化されたデジタル映画構成をプレイアウトする全てのデジタル映画サーバはログを取らなければならない。しかし、かかるログには以下の難点がある。
（ａ）抽出における難点
（ｂ）サーバの製造者、コンテンツの所有者、および映画館主の間の、複雑で交渉が困難なビジネス上の同意
（ｃ）各デジタル映画サーバにおける暗号化構成ごとに一意な暗号化キーを生成し配布する必要性
【０００９】
したがって、既存の標準化されたデジタル映画ログは広告プレイアウトの検証に関して望ましくないままである。標準化されたデジタル映画ログシステムを利用するのではなく、多数の映画館の運営者は、手動で生成した宣誓供述書（これには手動記録プロセスのように、その精度と正確性は疑問がある）によりデジタル映画広告のプレイアウトを実現している。
【００１０】
したがって、個々の広告のプレイアウトを監視するための低コストで自動化された方法が必要である。幾つかのケースでは、不完全なプレイアウトが発生したとき、広告のどの部分がプレイアウトされたかを考慮すべきである。
【課題を解決するための手段】
【００１１】
デジタル映画フィーチャ・プレゼンテーションに付随するデジタル映画構成のプレイアウトを追跡するための方法は、構成がプレイアウトされている間、その構成と関連している補助コンテンツ・ファイルにおける識別情報を先ず検出することによって開始される。識別情報は、個別の補助コンテンツ・ファイルに固有とすることができる。検出された識別情報が有効な期間が規定される。その後、識別情報と識別情報が検出された有効期間を表すデータは、ログを取られてプレイアウトされた構成を追跡する。
【図面の簡単な説明】
【００１２】
【図１】本発明の好適な実施形態に従う広告プレイアウト監視の略ブロック図である。
【図２】図１の広告プレイアウト監視とともに使用されるクローズド・キャプション・レファレンスを有する、ＳＭＰＴＥフォーマットのデジタル映画構成プレイリスト（ＣＰＬ）の一部を示す図である。
【図３】図１の広告プレイアウト監視とともに使用されるクローズド・キャプションを提供するためのＣＰＬで参照される、ＳＭＰＴＥフォーマットの時限テキスト追跡ファイルの一部を示す図である。
【図４】デジタル映画サーバ（ＤＣＳ）により補助コンテンツサーバ（ＡＣＳ）に配信されるリソース表示リスト（ＲＰＬ）の一部を示す図である。
【図５】本発明に従う、記録されたキャプションに基づく広告プレイアウトをレポートするためのプロセスのステップの流れ図である。
【図６】記録されているリールを表すデータに基づく、広告プレイアウトをレポートするための代替的なプロセスの流れ図である。
【図７】記録されたキャプション・インタフェース・データに基づく広告プレイアウトをレポートするためのさらに別のプロセスの流れ図である。
【図８】本発明に従う記録されたキャプション・インタフェース・データに基づく広告プレイアウトを記録しレポートするためのデータベース・スキーマの図である。
【発明を実施するための形態】
【００１３】
図１は、本発明の好適な実施形態に従う、デジタル映画構成のプレイアウトを提供するためのデジタル映画システム１００を示す。当該構成には、２つの相違なるデジタル映画ホール１１０および１２０におけるオンスクリーン広告が含まれるがこれには限られない。ホール１１０および１２０においては、デジタル映画サーバ１１２および１２２は、それぞれ、コンテンツ記憶装置１１３および１２３と通信し、それぞれ、デジタル・プロジェクタ１１４および１２４と通信する。当業界で公知なように、一部の実施形態では、デジタル映画サーバ（例えば、１１２）を対応するプロジェクタ（例えば、１１４）と統合してもよい。コンテンツ記憶装置１１３および１２３は、広告コンテンツおよび映画コンテンツ、例えば、フィーチャ・プレゼンテーションおよびトレーラを格納し、その全てはデジタル映画構成であり、一般にデジタル映画構成プレイリスト（ＣＰＬ）としてまたは他の適切なフォーマットで提供される。以下では、適切なＳＭＰＴＥ標準に対応するフォーマットのＣＰＬで提供されるコンテンツ（デジタル映画構成）を有する例示的なシステムに主に着目して説明する。しかし、本発明に従う広告のロギング（logging）では、ＳＭＰＴＥ標準に従ってフォーマットされたＣＰＬを要求する必要はない。
【００１４】
広告サーバ１４０は、広告コンテンツ１３０をリモート・ソース、例えば、ハード・ドライブまたは広告サーバと通信する他の物理記憶媒体から受信する。あるいは、または、１つまたは複数の物理記憶装置から受信したコンテンツに加えて、広告サーバ１４０は、通信リンク（図示せず）を介して、例えば、衛星、ブロードバンド接続、無線接続等を介して、かかるコンテンツに対するソース（図示せず）から、広告コンテンツ１３０を受信することができる。当該実施形態では、広告サーバ１４０は、それぞれチャネル１４１および１４２を介してデジタル映画サーバ１１２および１２２と通信して、広告コンテンツ１３０の少なくとも一部を各デジタル映画サーバに配信して、それぞれコンテンツ記憶装置１１３および１２３に取り込むかまたは格納する。
【００１５】
実際には、広告サーバ１４０は、それぞれチャネル１５１および１５２を通じてデジタル映画サーバ１１２および１２２と通信して、各サーバによるデジタル映画構成のプレイアウト、特に、広告のプレイアウトを監視するプレイアウト監視モジュール１５０を有する。以降で詳細に説明するように、プレイアウト監視モジュール１５０は、リソース表示リスト（ＲＰＬ）、キャプション、リール利用、および／または現在のフィーチャ・プレゼンテーションタイムラインを監視して、１つまたは複数のデジタル映画構成、特に広告のロギングを容易にする。
【００１６】
図１のデジタル映画システム１００のようなデジタル映画システムでは、デジタル映画サーバ１１２および１２２の１つのようなデジタル映画サーバ（ＤＣＳ）が、図１の対応するデジタル映画プロジェクタ１１４および１２４のうち１つとは異なるサブシステム（図示せず）により表示するためのキャプションまたはサブタイトルを生成することができる。かかるキャプションまたはサブタイトルの表示サブシステムは、以下の議論において「補助コンテンツサーバ（ＡＣＳ）」と表す。
【００１７】
技術的には、「キャプション」という用語は、口語対話と同じ言語での対話に対応するテキストをいい、「サブタイトル」とは口語対話以外の言語での対話に対応するテキストをいう。「オープン・サブタイトル」は一般に、視聴者全体が視聴するためのメイン表示画面に現れる。対照的に、「クローズド・サブタイトル」または「クローズド・キャプション」は、例えば装置を用いてクローズド・キャプション／サブタイトルを可視にすることによってそれらを視聴することを選択した人にのみ出現する。以降、「サブタイトル」および「キャプション」という用語は区別せずに現れ、その「クローズド」バージョンを指す。
【００１８】
ＳＭＰＴＥ（Ｓｏｃｉｅｔｙ  ｆｏｒ  Ｍｏｔｉｏｎ  Ｐｉｃｔｕｒｅ  ａｎｄ  Ｔｅｌｅｖｉｓｉｏｎ  Ｅｎｇｉｎｅｅｒｓ）は、１つまたは複数のＳＭＰＴＥ標準で具体化したＤＣＳ／ＡＣＳ対話のための例示的な標準化機構を開発して相互互換性を促進している。デジタル映画におけるクローズド・サブタイトルおよび／またはクローズド・キャプションに関するＳＭＰＴＥ標準は、フィーチャ・プレゼンテーションのプレイアウト中の（例えば、難聴者のための）代替的な言語のサブタイトルまたは同一言語のキャプションを可能とする。さらに、当該標準ではかかるキャプション／サブタイトルを暗号化するための手段を提供し、補助コンテンツサーバ（ＡＣＳ）が図１のデジタル映画サーバ１１２および１２２のうち１つのようなデジタル映画サーバ（ＤＣＳ）と、Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ（ＩＰプロトコル）、例えばイーサネット（登録商標）を介して通信できるようにするためのプロトコルを提供する。ＳＭＰＴＥの「補助コンテンツ同期プロトコル」は、外部ＡＣＳに対し、利用可能なキャプション／サブタイトル言語のリスト（「補助リソース表示リスト」またはＲＰＬ）をどこで取得するかを通知する。当該リストは、個々のキャプションとタイムライン内のその関連位置とを含むファイルを識別する。補助コンテンツ同期プロトコルはまた、ＤＳＣがプレゼンテーションをプレイアウトする間にタイムラインの現在の位置を提供する。
【００１９】
したがって、ＡＣＳはＲＰＬを取得し、次いでＡＣＳは、関連するキャプション／サブタイトルを含む関心のある１つまたは複数の言語固有のファイルを取得する。ＡＣＳはさらに、タイムラインの進行をプレゼンテーションの再生として追跡し、関心のあるキャプションをフィーチャ・プレイアウトと同期して適切に表示する。ＤＣＳを停止するかまたは早送りまたは巻戻しする場合には、同期プロトコルが、タイムラインが停止またはスキップされたことを報告する。巻戻しに関連するキャプションは再びプレイアウトすることができ、早送り区間に関連するキャプションは再生されない。
【００２０】
デジタル映画の上映で使用されるクローズド・キャプションとクローズド・サブタイトルの暗号化、および、補助コンテンツ同期プロトコルと補助リソース表示リストに関する完全な詳細は以下のＳＭＰＴＥ標準に掲載されている。
【００２１】
ＳＭＰＴＥ  ＳＴ  ４２８−１０：２００８  Ｄ−Ｃｉｎｅｍａ  Ｄｉｓｔｒｉｂｕｔｉｏｎ  Ｍａｓｔｅｒ  −  クローズド・キャプションおよびクローズド・サブタイトル；
ＳＭＰＴＥ  ＳＴ  ４２９−７：２００６  Ｄ−Ｃｉｎｅｍａ  Ｐａｃｋａｇｉｎｇ  −  構成  プレイリスト；
ＳＭＰＴＥ  ＳＴ  ４２９−１２：２００８  Ｄ−Ｃｉｎｅｍａ  Ｐａｃｋａｇｉｎｇ  −  キャプションおよびクローズド・サブタイトル；
ＳＭＰＴＥ  ＳＴ  ４３０−１０：２０１０  Ｄ−Ｃｉｎｅｍａ  Ｏｐｅｒａｔｉｏｎｓ  −  補助コンテンツ同期プロトコル；  
ＳＭＰＴＥ  ＳＴ  ４３０−１１  ：２０１０  Ｄ−Ｃｉｎｅｍａ  Ｏｐｅｒａｔｉｏｎｓ  −  補助リソース・プレゼンテーション・リスト
他のクローズド・キャプション／サブタイトル機構が存在し、例えば、マサチューセッツ州ボストンのＭｅｄｉａ  Ａｃｃｅｓｓ  Ｇｒｏｕｐ  ａｔ  ＷＧＢＨで開発され、特許文献１に開示されているＲｅａｒ  Ｗｉｎｄｏｗ（登録商標）キャプション・システムのようなデジタル映画システムに応用される。
【００２２】
以下で説明するように、プレイアウト監視モジュール１５０は、プレイアウトされる広告に関連付けられたキャプションを追跡することによって広告プレイアウト・ログ１６０を生成する。プレイアウト監視モジュール１５０は、通信チャネル１７１によりかかるログを広告運用サーバ１７０に送信することができる。通信チャネル１７１には、インターネット１７２、および／またはイントラネットを含めてもよい。広告運用サーバ１７０は、データベース１７３を使用して、どの広告を再生すべきかを追跡し、プレイアウト監視モジュール１５０によって報告された検証情報を収集し、編成することができる。データベース１７３のより詳細な説明は、図８と関連して後述する。
【００２３】
代替的な実施形態では、プレイアウト監視モジュール１５０が広告サーバ１４０の外部に存在することができる。あるいは、デジタル映画サーバ１１２および１２２の各々がその独自の関連するプレイアウト監視モジュール（図示せず）を有してもよい。さらに、プレイアウト監視モジュール１５０が展示施設の外部にあってもよく、チャネル１５１がインターネット１７２および／または仮想プライベート・ネットワーク（ＶＰＮ）接続（図示せず）を介した接続を備えてもよい。したがって、幾つかの実施形態では（図示せず）、プレイアウト監視モジュール１５０は広告運用サーバ１７０のコンポーネントを備えてもよく、または、広告運用サーバ１７０とともに配置されていてもよい。ログ１６０は数日間または数週間格納され、かつ／または、バッチで１つの場所もしくは遠隔位置に送信される。あるいは、プレイアウト監視モジュール１５０が、通信チャネル（例えば、チャネル１７１）を用いた電子送信を介して当該記録を送信するのではなく、記録１６０を物理媒体に書き込んで発送してもよい。
【００２４】
図２は、構成プレイリスト（ＣＰＬ）ファイルの部分２００をＳＭＰＴＥフォーマットで示し、デジタル映画構成の全部または一部の上映で使用するためのメディア資産を特定する。多数のデジタル映画構成、特に広告やトレーラは単一の「リール」（一般には２０分を超えない編成単位であり、その起点はフィルム・ベースのコンテンツにある）として編成され、大抵のフィーチャ・プレゼンテーションは、一般には５つ以上の複数のリールから成る。
【００２５】
ＣＰＬの構成プレイリストは一種のＸＭＬ（ｅｘｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）文書から構成され、図２に示すように角括弧で呼び出されるタグで画される階層的に入れ子の要素を含む。部分２００で表したリール要素は、先頭のリール・タグ２０１で開始し、終了リール・タグ２０２まで続く。各リールはグローバルに一意な識別子２１０を有する。ＣＰＬの各リールは資産のリストを有する。リール２１０に対して、資産リスト２２０は以下の４つの要素を含む。
【００２６】
主要画像部分２２１、
主要音声部分２２２、
グローバルに一意な識別子２３１と米語を示す言語タグ２３２とを有する第１のクローズド・キャプション２３０、
グローバルに一意な識別子２４１と、この例では、広告検証キャプションを識別するために使用される未登録の「実験」タグである、「ｘ−ａｄ」を示す言語タグ２４２とを有する第２のクローズド・キャプション２４０。
【００２７】
図における省略（「．．．」）は、これらの例において簡単のため省略された詳細を示すが、当業者には周知である。
【００２８】
リスト２２０内の各資産タグは、対応するグローバル識別子を有する対応する資産追跡ファイルとの関連付けを有することができる。主要画像部分２２１と主要音声部分２２２は、フィーチャ・プレゼンテーションを表す一連の映像と、フィーチャ・プレゼンテーションとの同時プレイアウトのための対応するマルチチャネル音声を含むファイルをそれぞれ特定する。クローズド・キャプション２３０は、キャプション（英語）と各キャプションを表示できる時間間隔を含む時限テキスト・ファイルを特定する。
【００２９】
図３を参照すると、クローズド・キャプション要素２４０は、時限テキスト・ファイル３００を識別（ＩＤ）タグ２４１で特定する。時限テキスト・ファイル３００はＸＭＬヘッダ３０１で開始し、次にフレームが来て、グローバルに一意な識別子３０を有する「デジタル映画サブタイトル」（ＤＣＳＴ）要素３０２を含む残りのコンテンツを有する。ＣＰＬリール２００内のクローズド・キャプション要素２４０は識別タグ２４１を有する。「Ｃｏｎｔｅｎｔ  Ｔｉｔｌｅ  Ｔｅｘｔ」タグと「Ａｎｎｏｔａｔｉｏｎ  Ｔｅｘｔ」タグ、および、それに続く他のタグにより人間が読める情報を提供する。言語タグ３０４は「ｘ−ａｄ」を示し、上述のように、以前に使用した言語タグを構成せず、実際の言語を表さないが、本例では、広告プレイアウトの検証で使用するために与えたクローズド・キャプションを示す役割を担う。
【００３０】
時限テキスト・ファイル３００内の個々のキャプションは「サブタイトル・リスト」要素３０９内の逐次的リストに現れる。サブタイトル要素３１０、３２０、３３０、３４０、および３５０の各々は、（サブタイトルが最初に適用される）タイムイン、（サブタイトルが最後に適用される）タイムアウト、および個々のサブタイトル３１１、３２１、３３１、３４１、および３５１のテキストをそれぞれ提供する。時限テキスト・ファイル３００は「ｘ−ａｄ」と指定されるので、個々のキャプションのテキストは一般に視聴者に表示されないが、広告の識別（「ＳＩＰＰＹ  ０１１９１２  ００１」）と、対応するタイムインの時点でリール２１０のどの部分が再生されたかを通知する割合識別子（例えば、サブタイトル・テキスト３１１における「０００」が０％を表す）を提供する。タイムインとタイムアウトを表すタイムコードは、タイムコード速度タグ３０６で示される秒ごとのフレーム数とともに時間：分：秒：フレームのフォーマットを有する。これは、開始時刻タグ３０７によりオフセットされうる。
【００３１】
ＣＰＬ２００内のリール２０１で表示される広告の最初の２４フレームにおいて表示されうるサブタイトル要素３１０によれば、クローズド・キャプションは、（「ＳＩＰＰＹ  ０１１９１２  ００１」で識別される）広告の０％がプレイアウトされ、その時刻までに、サブタイトル要素３３０が（１５秒で開始して）適用され、広告の５０％がプレイアウトされたことを示す。当該キャプションの各々は、本例では、１秒間適用される。
【００３２】
ＳＭＰＴＥサブタイトル追跡ファイルに対するスキーマ定義は、「Ｌｏａｄ  Ｆｏｎｔ」タグ３０８を必要とするが、リール２０１により表示される広告に対するプレイアウトの検証においてそのフォントのグローバルに一意な識別子を参照する必要はない。当該例示的な実施形態では、ＳＭＰＴＥ標準によれば、サブタイトル・リスト３０９内のクローズド・キャプションのようなクローズド・キャプションへのアクセスは、（上のＳＭＰＴＥの引用で定義した）補助コンテンツ同期プロトコルを用いてデジタル映画サーバ（例えば、サーバ１１２）に登録する補助コンテンツサーバまたはＡＣＳ（ここでは、プレイアウト監視モジュール１５０）によって生じる。一度登録されると、プレイアウト監視モジュール１５０は、デジタル映画サーバ１１２によるプレイアウト開始時に図４に示す、リソース表示リストファイル４００が発見されるアドレスを受信する。プレイアウト監視モジュール１５０は、表示リストファイル４００を取り出し、当該ファイルを解析することによって、当該プレイアウト監視は、対応するリール・リソース要素４１０および４２０の各々における広告プレイアウト検証ファイル４１２および４２３をそれぞれ学習する（この２つのリール・リソース・タグには言語「ｘ−ａｄ」の属性がある）。
【００３３】
リール・リソース要素４１０はまた、英語クローズド・キャプション資産４１１を列挙する。リール・リソース要素４２０は、英語のクローズド・キャプション資産４２１とフランス語のクローズド・キャプション資産４２２を列挙する。各リール・リソース要素は識別を有する。例えば、リール・リソース４１２は、時限テキスト・ファイル３００内の識別子３０３に対応するグローバルな一意な識別子「ｕｒｎ：ｕｕｉｄ：５５５５５５５５−５５５５−５５５５−５５５５−５５５５５５５５５５５５」を含む。各リール・リソースは、（必ずではないが）一般にはハイパーテキスト転送プロトコルを用いて、かつ、（必ずではないが）一般にはデジタル映画サーバによって提供されるサーバからファイル３００を取り出すための位置を識別するリソース・ファイル位置４１３も表示す。当該サーバは、本例ではローカルのインターネット・プロトコル（ＩＰ）アドレス「１９２．１６８．１．１」で到達可能である。
【００３４】
図１の例示的な実施形態では、デジタル映画サーバ１１２は補助コンテンツ同期プロトコルを用いてイーサネット接続１５１を介してプレイアウト監視モジュール１５０と通信する。このように、デジタル映画サーバ１１２は、接続１５１を介して、リソース表示リスト４００を取り出すようにプレイアウト監視モジュール１５０に指示し、引き続いて時限テキスト・ファイル３００を取り出すことができる。当該アドレスは要素４１３内のＵＲＬ（ｕｎｉｖｅｒｓａｌ  Ｒｅｓｏｕｒｃｅ  ｌｏｃａｔｏｒ）で提供され、接続１５１を介してアクセス可能なデジタル映画サーバ１１２を特定する。デジタル映画サーバ１１２は、適合すると判断すれば、リソース・ファイルのサブディレクトリとファイル名を提供する。換言すれば、デジタル映画サーバ１１２は任意に、時限テキスト・ファイル３００を参照してホールダとファイル名を決定する。
【００３５】
補助コンテンツ同期プロトコルによれば、デジタル映画サーバ１１２は続いて、リソース表示リスト４００に対応するプレゼンテーションの（編集単位での）現在位置と状態（例えば、再生や一時停止）をプレイアウト監視モジュール１５０に対して示す。編集単位は、デジタル映画構成を測定するための最小の時間単位を構成する。ＲＰＬ４００に対応するプレゼンテーションのケースでは、リール４１０と４２０は「２４１」または毎秒２４編集単位の編集速度を有する。個々のリールは異なる編集速度を有する可能性があり、ＲＰＬ４００内の要素は常にフィーチャ・プレゼンテーション内の全てのリールを表すというわけではない（クローズド・キャプションまたはクローズド・サブタイトルのトラックを有するもののみ）。したがって、リール・リソース要素４１０が「１４４０」のタイムライン・オフセットを引用する場合には、これは（リール４１０のアイデンティティに対応するアイデンティティ２１０を有する）リール２０１のコンテンツが、現在のプレゼンテーションに「１４４０」の編集単位で開始することを意味する。「２４１」の編集速度では、これは、１４４０／２４＝６０の関係に従って６０秒を構成するはずである。この場合、任意の所与の時刻で、現在の補助コンテンツ同期プロトコルが、リール２０１の前にプレイアウトされるリールに使用されるプレイアウト監視モジュール１５０に当該編集速度を供給する。
【００３６】
デジタル映画サーバ１１２が報告したプレゼンテーションの現在の位置が「１４４０」に達すると、これはリール・リソース要素４１１および４１２が最新になる時刻であり、時限テキスト・ファイル３００において（リール・リソース４１２のＩＤ要素により特定されるので）、第１のサブタイトル要素３１０がアクティブになる。開始時刻３０７は００：００：００：００であり、タイムインに対するサブタイトル要素３１０は００：００：００：００であり、サブタイトル要素は２４個の編集単位に関してアクティブのままであり、これが１秒を構成する。
【００３７】
サブタイトル要素３１０がアクティブなままである間、プレイアウト監視モジュール１５０は、クローズド・キャプション・テキスト３１１から、「ＳＩＰＰＹ  ０１１９１２  ００１」として特定される広告が０％プレイアウトしたという指標を取得することができる。１５秒（３６０編集単位）後に、プレイアウトが継続し、キャプション３３１が５０％のプレイアウトを示し、プレイアウトの２９秒で、キャプション・テキスト３５１が、広告のプレイアウトが１００％に到達したと示すと仮定する。幾つかの実施形態では、サブタイトル要素３１０、３２０、３３０、３４０、および３５０とともに、プレイアウト割合を省略することができる。例えば、ビジネス・ポリシに応じて、プレイアウト監視モジュール１５０は０％または２５％のプレイアウト・マーク、または、１００％のプレイアウトに満たないものを無視してもよい。特定のプレゼンテーションにおいて、ファイル３００内の各キャプションがアクティブになる時刻でログを取ることができ、あるいは、最も完全なプレイアウトを示すキャプションのみログを取る必要がある。例えば、広告３００が８０％までプレイアウトされ停止された場合には、そのプレイアウトに対して、キャプション３４１のログが取られるが、キャプション３５１のログは取られない。さらに他の実施形態では、プレイアウトのログが関心のあるキャプションごとに増加するカウントを含むことができる。
【００３８】
代替的な実施形態では、特別な「ｘ−ａｄ」キャプション・ファイルを要求するのではなく、図１のシステム１００は「ｅｎ−ｕｓ」または他の通常の言語キャプションを信頼する（例えば、クローズド・キャプション資産要素２３０によりＣＰＬ２００で参照したものやリール・リソース要素４１１によりＲＰＬ４００で参照したもの。その他のものについては図示していない）。かかるケースでは、アクティブな最後のキャプション・エントリのログを取ることができる。代替的な実施形態では、リール全体における夫々の連続的なキャプションを単一の値にハッシュ化することができ、それにより、曖昧さの可能性が殆ど無く広告が完全に再生したかどうかを示す値を表示する。このアプローチには、テキスト資産を複製する必要性をクローズド・キャプション追跡ファイルから取り除く利点があり、それにより、それがなければ生じうる著作権の問題が回避される。
【００３９】
幾つかの実施形態では、プレイアウト監視モジュール１５０は、サブタイトル・リスト要素３０９内のキャプション、または、要素２３０および４１１が参照する通常言語キャプション・ファイル内の対応するサブタイトル・リスト要素を無視することができる。その代りに、プレイアウト監視モジュール１５０は、プレイアウトの部分をＲＰＬおよびレポートされたプレイアウト部分から直接決定することができる。例えば、プレイアウト監視モジュール１５０が、タイムライン・オフセット「１４４０」で開始するとしてＲＰＬファイル４００内のリール４１０でリール２０１を特定し、リール・リソース要素４１１、４１２が各々、「７２０」編集単位の固有期間を有すると特定される（「固有期間」属性はＳＭＰＴＥ標準では必須であるが、存在する場合には、任意の「Ｄｕｒａｔｉｏｎ」属性（図示せず）を代わりに使用すべきである）とき、リール２０１によって表示される広告に対するプレイアウトの現在部分を、タイムライン・オフセット（「１４４０」）を固有期間（「７２０」）で除算したものより少ない現在位置として決定することができる。例えば、タイムライン位置「１８００」では、これは広告リール２０１がプレイアウトされている間に生じるが、プレイアウトされた広告の部分は（１８００−１４４０）／７２０＝３６０／７２０＝５０％となるはずである。当該実施形態では、（４１０においてＲＰＬ内で呼び出される）リール識別子２１０は、どの広告がロギング・プロセス中にプレイアウトされたかを示すことができる。
【００４０】
プレイアウトが停止した時（これは広告の割込みを表しうる）およびプレイアウトが進行する各リールの終了時にログを更新することができる。このように、終了まで再生される広告がリール境界でログを取られ、割り込まれた広告には（後で再開されたとしても）注釈を付けてもよい。レポート時にかかるログにどのように割り込むか（例えば、部分的なプレイアウトが報告されたかどうかまたは広告のどのプレイアウト部分が再生されたと考えられるか）はビジネス・ポリシに留まる。
【００４１】
図５は、広告プレイアウトを報告するプロセス５００の一実施形態を流れ図の形で示す。当該プロセスは、プレイアウト監視モジュール１５０がデジタル映画サーバ１１２と通信するステップ５０１で開始する。その通信は、当該補助コンテンツ同期プロトコルを介した再生準備が完了したかまたは既に再生されている番組の貸出しの要求または許可により、プレイアウト監視モジュール１５０とデジタル映画サーバが接続を開始することを可能にする。ステップ５０２で、デジタル映画サーバ１１２はリソース表示リスト（ＲＰＬ）、例えば、リスト４００をプレイアウト監視モジュール１５０に提供する。ＲＰＬ４００は１つまたは複数のリール（例えば、リール４１０、４２０）を列挙する。当該１つまたは複数のリールは、そのプレイアウト監視モジュール１５０が当該リールに対応するクローズド・キャプション・ファイル（例えば、ファイル４１２、４２３）を特定するために監視するプレイアウトのコンテンツ（例えば、広告）に対応する補助コンテンツ（本例では、クローズド・キャプション）を有する。ステップ５０３で、プレイアウト監視モジュール１５０は、監視されているコンテンツに対応するＲＰＬ４００において特定されたクローズド・キャプション・ファイル（例えば、３００）を取り出す。プレイアウト監視モジュール１５０は、当該ファイルを解析して、（編集単位での）どのタイムライン位置で各サブタイトルがアクティブになるかを判定することができる。
【００４２】
一般に、ステップ５０３で取り出した当該第１のクローズド・キャプション・ファイル（例えば、ファイル３００）はＲＰＬ（例えば、ＲＰＬ４００）内で特定された第１のリール（例えば、リール４１０）において列挙されたファイル（例えば、ファイル４１２）に対応する。当該プレイアウト監視モジュールは、追加のクローズド・キャプション・ファイル（例えば、４２３）を順次または並列に取り出すことができる。しかし、プレゼンテーションが開始以外の位置で開始する一部の場合、または、プレイアウトが開始後すぐに先の位置に早送りされる一部の場合には、取り出した第１のクローズド・キャプション・ファイルは最初のもの（３００）以外であってもよい。
【００４３】
ステップ５０４で、プレイアウト監視モジュール１５０はプレイアウト位置のその推定を更新する。プレイアウト監視モジュール１５０は、当該プレイアウト位置の推定を編集単位ごとに１回更新して、連続的な一連の編集単位のカウントがステップ５０４の繰返しにより提供されるようにしてもよい。再生中は、定期的に、デジタル映画サーバ１１２が、現在のプレイアウト位置を含む更新を送信し、プレイアウト監視モジュール１５０が当該更新を使用してそのカウントを再調整して同期を保証する。プレイアウトが開始し、一時停止し、または再開したとき、当該デジタル映画サーバは、補助コンテンツ同期プロトコルにより規定されるように、事実上すぐに更新を送信する。
【００４４】
ステップ５０５で、現在のタイムライン位置（例えば、「１８００」）がＲＰＬ（例えば、ＲＰＬ４００）内のリール（例えば、「１４００」から「２１５９」まで続くリール４１０）に対応するかどうかを判定するための比較を行って、現在のタイムライン（プレイアウト）位置がＲＰＬ内の何れかのキャプションに一致するかどうかを判定する。一致する場合には、ステップ５０３からの対応するキャプション・ファイル（例えば、ファイル３００）を検査して、もしあれば、「００：００：１５：００」のタイムインを有する時限テキスト・ファイル３００内のキャプション３３０がそうであるように、そのキャプション（例えば、キャプション３１０、３２０、３３０、３４０、および３５０）のうちどれが現在のタイムライン位置（例えば、（１８００−１４４０）／２４＝３６０／２４＝「００：００：１５：００」）に対応するかを判定する。
【００４５】
ステップ５０５で、過去にアクティブなキャプションがないか、または、過去にアクティブであったキャプションがこの現在位置でちょうどアクティブにならなくなり、（本例のキャプション３３０のような）新たなキャプションがちょうどアクティブになった場合には、処理はステップ５０６で継続する。ステップ５０６の間に、データベース５０７がキャプションのテキスト（例えば、テキスト３３１）を表示するデータを後のレポートのためにログに取り、その後、プロセスはステップ５０８に進んで次のタイムラインの増分を待機する。そうでない場合には、（過去にアクティブであったキャプションの有無に関わらず）ちょうどアクティブになったキャプションがないときには、処理はステップ５０８で継続する。
【００４６】
様々な実施形態では、ステップ５０６で記録されるキャプションの様々な表現をログに取ることができる。幾つかの実施形態では、（例えば、テキスト・タグ３３１内部で見つかるように）キャプションのテキストをそのまま記録することができる。他の実施形態では、当該キャプションを解析して、例えば、ＡｄＩＤフィールドと完了率を別々のレコード・フィールドに分離してもよい。現在日時を表すタイムスタンプを、かかるレコード内のフィールドとして導入してもよい。さらに他の実施形態では、広告識別（ＡｄＩＤ）の単一のインスタンスおよび直近の完了率のみで、単一のレコードを広告のプレイアウトごとに生成してもよい。さらに、プレイアウト部分が実質的に１００％に達したときに増加されるカウント・フィールドがあってもよい。かかるサマリ・データは非常にコンパクトであることができ、例えば、以前のカウントが報告され受領が確認されたときに定期的にリセットしてもよい。さらに他の実施形態では、プレイアウト監視モジュール１５０がレコードを暗号化またはハッシュ化して不正に対してより抵抗してもよい。
【００４７】
ステップ５０８で、ＲＰＬ（例えば、ＲＰＬ４００）で呼び出された現在のキャプション・ファイル（例えば、キャプション３００）の一部が尽きたかどうかを判定するテストを行う。尽きていない場合には、処理はステップ５０４に戻って次のタイムラインの更新を待つ。キャプション・ファイルが尽きた場合には、処理はステップ５０９で継続する。ＲＰＬはキャプション・ファイル全体を使用する必要はないことに留意されたい。なぜならば、幾つかの事例（図示していないが、ＲＰＬ向けＳＭＰＴＥ仕様には記載されている）では、リール・リソース（例えば、４１２）は、個々のキャプションの一部のみの規定を含めて、使用されるサブタイトルファイル（例えば、ファイル３００）内で定義されるタイムラインの一部のみを規定するエントリ・ポイントおよび／または期間を有してもよいからである。
【００４８】
ステップ５０９で、タイムライン内の現在位置とＲＰＬ全体の比較を行い、ＲＰＬが尽きたかどうかを判定する。尽きていない場合には、処理はステップ５０３で継続して、（例えば、ファイル４２３で参照する）次のキャプション・ファイルを取り出す。幾つかの実施形態では、当該ファイルをバックグラウンド・プロセスとして事前フェッチし事前解析しておき、当該時点ですぐに準備できるようにしてもよいことに留意されたい。しかし、ステップ５０９でＲＰＬが尽きた場合には、プレイアウトは完了し、処理はステップ５１０に進み、ログに格納された情報を例えば広告運用サーバ１７０に報告するために処理する。幾つかの実施形態では、ログに関する報告をリアルタイムに行うか、または、多数の上演にわたって（例えば、数時間、数日、数週間）にわたって格納し、全体として、またはサマリで、直接接続により、または間接的に（例えば、電子メールにより）送信し、または、ウェブ・サーバを介してダウンロードまたは呼び出して検査できるようにしてもよい等である。幾つかの実施形態では、データベース５０７内のログエントリを大規模データベース内の記録として送信することができ、レポートがアドホックに提供される。レポートが完了すると、プロセス５００はステップ５１１で完了する。
【００４９】
幾つかの実施形態では、広告の間または広告の後に再生されるトレーラとフィーチャの監視とロギングを同様に行うこともできる。かかる実施形態では、ステップ５０３で、トレーラとフィーチャコンテンツに対応するキャプション・ファイルの取得が同様に行われるが、これらのキャプション・ファイルに特別なマーカ（例えば、「ｘ−ａｄ」のような特別な言語コード）がなくともよい。例えば、一部のトレーラのプロデューサが特別なマーカを取り込んで（上述のように）プレイアウト監視を単純かつ信頼性の高いものにすることができるが、フィーチャ・プレゼンテーションは、一般にそれらは暗号化されているので、デジタル映画セキュリティ・コンポーネントによりログが取られる。しかし、かかるログは一般に、フィーチャの配信者および／または所有者以外の第三者によってはアクセス不可能である。これらの事例では、フィーチャのアイデンティティを（ステップ５０６の間に記録される）一意なサブタイトル・データの繰返し発生と他所で発行される番組スケジュールの相関関係から推論することができる。これを以下で図８に関連してさらに詳細に論ずる。
【００５０】
図６は、プレイアウト監視モジュール（例えば、プレイアウト監視モジュール１５０）により実行される別の例示的な広告プレイアウト検証プロセス６００を示す。ステップ６０１、６０２、および６０４はそれぞれ図５のステップ５０１、５０２、および５０４と同じ機能を順次実行する。しかし、ステップ６０５で、もしあればＲＰＬ４００のどのリールが現在のタイムライン位置に対応するかを判定するテストを行う。対応するものがある場合には、ステップ６０６で、リールアイデンティティ（例えば、タグ４１０からの「１１１１１１１１−１１１１−１１１１−１１１１−１１１１１１１１１１１１」）が、関連するリール・リソースのタイムライン・オフセットと固有期間（または与えられれば実際の期間）に基づいて、プレイアウト部分（例えば、現在のタイムライン位置が「１８００」である場合には、１８００−１４４０）／７２０＝５０％と共に、データベース６０７において記録される。幾つかの実施形態では、ステップ６０６中のリール・プレイアウトのロギングが、プレイアウト部分が何らかの所定値（例えば、９５％）を超えるのを待ってもよい。
【００５１】
ステップ６０９で、ＲＰＬで表示したタイムラインが完了したかどうかを判定するテストを行う。完了していない場合には、プロセス６００はステップ６０４に戻る。そうでなければ、ステップ６１０で、データベース６０７にアクセスして広告プレイアウトを検証するためのレポートを提供する。プレイアウトをステップ６１０で検証すると、プロセス６００はステップ６１１で完了する。
【００５２】
図５および図６の両方のケースにおいて、ＣＰＬが補助コンテンツ（例えば、クローズド・キャプション）資産を有さない場合には、ＲＰＬ４００は当該ＣＰＬの表示を有さず、補助コンテンツ同期プロトコルを用いてアクセス可能な対応する時限テキスト・ファイルも存在しないことに留意されたい。確かに、広告に対して、当該システムに配信するための広告をパッケージ化するエンティティがＣＰＬを制御し、拡張により、それらがプレイアウトに選択されスケジュールされるときには、それらはＲＰＬ４００に含まれる。他のコンテンツ、例えばフィーチャに関して、例えば聴覚障害者に対しかかる補助コンテンツ（例えば、キャプション）を提供して十分なアクセス可能性を保証するための法的要件、または、かかる法律に対する要件を満たす、できるだけ押し付けがましくないアクセス方法である法的要件が存在する可能性が十分にある。
【００５３】
図７は、プレイアウト監視（例えば、プレイアウト監視モジュール１５０）により実行するための広告プレイアウト監視プロセス７００を示す。当該プロセスでは、ステップ７０１はステップ５０１と６０１と実質的に同様な機能を実施する。ステップ７０２で、プレイアウト監視モジュール１５０はキャプション・インタフェース（例えば、対応するデジタル映画サーバ１１２への接続１５１）をチェックして、図５および図６に関して上述した広告プレイアウトを検出する。ステップ７０３で、プレイアウト監視モジュール１５０は、ステップ７０２で検出した各広告プレイアウトをデータベース７０４に記録する。ステップ７０５で、プレゼンテーションが完了したかどうかを判定するテストを行う。完了していない場合には、処理はステップ７０２で再開する。そうでなければ、ステップ７０６で、データベース７０４にアクセスしてレポートを提供し、プロセスはステップ７０７で完了する。
【００５４】
監視プロセス５００、６００、７００の何れかが完了すると、プレイアウト監視（例えば、モジュール１５０）は、デジタル映画サーバ１１２が提供する次のＲＰＬにより表示される次のプレゼンテーションを監視するために、監視プロセスの次のインスタンスを開始してもよい（または既に開始していてもよい）
図８は、広告運用サーバ１７０が使用するデータベース１７３を実装するのに適した例示的なスキーマ８００を示す。各テーブル内の各レコードは、当該レコードを一意に特定する（太字のイタリック体の）アイデンティティ・フィールドを有する。一部の外部キー・フィールド（フィールド名を非太字イタリック体で示す）が、特定のクエリを解決し、包括的なレポート（例えば、どの広告がどの映画館でどのパフォーマンス階層で再生されるか、契約情報に従ってどれを使用してどれだけ多くの金額を広告主に課金するかを決定できる）を生成するために有用な他のテーブル内のレコードとの関係を生成する。
【００５５】
スキーマ８００において、広告テーブル８１０は個々の広告（例えば、ソーダに関する特定の広告）を記録する。広告テーブル８１０内の各レコードに関連付けられた広告識別子キー・フィールドは当該レコードに対する一意な識別子の役割を果たす。各広告は、当該広告を説明する対応する説明フィールドを有する。当該説明は、実際の広告コンテンツに対する参照を含むことができる（それ以外は図示せず）。当該説明フィールドは、広告所有者や広告配信者のような、かかる広告に対する予約または課金に必要な他の情報を含むことができる。
【００５６】
デジタル映画システムによるプレイアウトのための広告をパッケージする代理店が広告リール・テーブル８２０を埋めることができる。そうする場合には、リールＩＤ（例えば、リールＩＤ２１０）または代替的にはクローズド・キャプション識別子（例えば、クローズ・キャプション識別子２４１および３０３）に、対応する広告識別子と関連して関係８２１を生成する注釈を付け、それによりリール識別子が特定の広告レコードを束ねる。広告ごとに複数の広告リール・レコードがテーブル８２０に存在しうることに留意されたい。例えば、テーブル８１０内の単一の広告レコードが２つのコンテンツに対応しうる。例えば、同一の広告が２つのアスペクト比（スコープとフラット）で存在することができ、夫々は、対応するアスペクト比を有するフィーチャを伴うプレイアウトに良く適している。各広告リール・レコードは、他の情報、例えば、言語コード、バージョン情報、および期間を含むことができる。
【００５７】
映画館テーブル８３０では、各レコードは、１つまたは複数の広告をプレイアウトする契約の下にありうる映画館に対応する。映画館識別キー・フィールドは、各映画館レコードを一意に識別する。幾つかの実施形態では、各映画館内の個々のホールをさらに特定することができるが、これはデータベース内で許容し難いほど激しい変動をもたらすおそれがあり、それらが表示すべき現実と同期しないレコードが非常に多数生じうる。映画館テーブル８３０内の他の情報は、位置情報や映画館主情報を含むことができる。位置情報は、例えば、発送コンテンツのアドレスを決定するために必要であり、または、特定の人口領域に映画館が存在するかどうかを判定するのに必要である。映画館主情報は、例えば、契約責任者として必要であり、または、複数の映画館の共通管理を決定するために必要である。
【００５８】
サーバ・テーブル８４０は、システム１００に既知なデジタル映画サーバごとのレコードを含む。８４０内の各サーバ・レコードは、関係８４３により与えられる単一の映画館と一意な関連を有する。当該サーバ情報は、一意な装置識別子、または、特定のプレイアウト監視モジュール１５０または通信チャネル１５１との関連付けを含むことができて、ログ５０７、６０７、および７０７、および特定の映画館の間の関係を記録または構築するのを容易にする。ログ５０７、６０７、および７０７内の各レコードは、キャプション・ログ・テーブル８５０内の対応するレコードを有することができる。キャプション・ログ・テーブル８５０は、複数の映画館の広告プレイアウト・ログ１６０に存在することができ、後でデータベース１７３に統合される。あるいは、データベース１７３を十分にリアルタイムで（即ち、高々、秒または時間等で）更新することができる。幾つかの実施形態では、ログ５０７、６０７、および７０７を定期的に広告運用サーバ１７０に転送して取り込み（必要に応じて処理し）、テーブル８５０を埋める。
【００５９】
テーブル８５０内の各ログ・レコードは一意な記録識別子を有する。当該サーバ識別子とその対応するレコードは関係８５４を形成する。キャプション・ベースのプロセス５００の場合、広告識別子が各キャプション（例えば、キャプション３３１）のテキストに存在し、関係８５１を形成することができる。リール・ベースのプロセス６００の場合、（例えば、リール４１０からの）リール識別子または幾つかの実施形態では時限−テキスト識別子（例えば、時限−テキスト識別子４１１、４１２、または３０３）を捕捉して、関係８５２を形成し、後で関係８２１と組み合わせて広告識別子を埋め、関係８５１を形成する。
【００６０】
プレイアウト部分とタイムスタンプ・フィールドは、広告のどの部分がいつ再生されたかを示す。当該プレイアウト部分は、プレイアウトが契約要件またはビジネス要件を満たすのを検証する役割を果たすことができる（例えば、広告プレイアウトは、ログが９５％以上のプレイアウトを示す場合にのみ行われる）。当該タイムスタンプは、フィーチャ・プレゼンテーションに対する広告の近接性を、契約要件またはビジネス要件に従って決定する役割を果たすことができる（例えば、広告がフィーチャの前に再生された最後の５つのうち１つであり、または、フィーチャ前５分以内に再生された広告である、等）。
【００６１】
広告委任テーブル８６０は、広告プレイアウトを管理する契約上の同意またはビジネス上の同意に個々の広告を関連付けるレコードを含む。この例示的な実施形態では、テーブル８６０に広告委任レコードを埋めるのは、契約情報フィールドに従う開始日と終了日の間に１回または複数回、対応する広告をプレイアウトすることによって行われる。広告の適正なプレイアウトが、任意のフィーチャ、または、特定のフィーチャ、または、特定のフィーチャを除くフィーチャに対する所定の近接性において行われなければならない場合には、かかる要件はフィーチャ規則フィールドに存在する。かかる広告委任が適用される特定の広告と映画館はそれぞれ関係８６１と８６３をもたらす。代替的な実施形態では、広告の集合または映画館の集合を、例えば８６１もしくは８６３の何れかまたは８６１と８６３の両方の代わりに多対多の関係を形成する中間接続レコード（図示せず）を介して、単一の委任レコードと関連付けてもよい。委任識別子は広告委任レコードを一意に特定する。
【００６２】
検証プレイアウト・テーブル８７０は、（関係８７５で決定された）テーブル８５０内のログ・レコードを示すレコード、（関係８７１で決定された）対応する広告、および（関係８７６で決定された）検証レコードが適用される広告委任レコードを示すレコードを含む。当該検証レコードは、広告プレイアウト時間に関するタイムスタンプ、パフォーマンス階層（即ち、プレイアウト広告がフィーチャの開始時刻に対してどれだけ近くに発生したかの定量的な指標）、（関係８８７で決定された）関連フィーチャ、および適用可能なフィーチャ規則との準拠に関する評価結果を含むことができる。テーブル８７０からの検証プレイアウト・レコードは、課金システム（図示せず）を動作させて対応する広告の所有者または配信者に課金する役割を担うことができる。１つの例示的な実施形態では、パフォーマンス階層フィールドを構成する「定量的な指標」が、広告がフィーチャ開始の５分以内、フィーチャ開始の１０分以内、またはそれより前に、再生されたかを示す所定の３階層スケールを構成することができる。様々な所定の階層が、テーブル８６０内の広告委任レコードごとに存在してもよく、契約情報フィールドにより選択するかまたは示してもよい。
【００６３】
幾つかの実施形態では、フィーチャテーブル８８０が、図１のシステム１００に既知なフィーチャごとに識別子を含むことができる。説明フィールドが、フィーチャのタイトルおよび／または他の識別情報を含むことができる。広告委任テーブル８６０内のフィーチャ規則フィールドが、（関係が存在しない）テーブル８８０のレコード内のフィーチャに対する参照を含むことができる。テーブル８８０内のフィーチャの開始時刻を特定するための２つの例示的な機構が、別々にフィーチャ・リール・テーブル８９０とスケジュール・テーブル８０１に現れる。フィーチャ・リール・テーブル８９０は、未認識のリール、即ち、対応する広告リール・レコードがテーブル８２０に存在しないものに対してテーブル８５０内のログ・レコードの生成を仮定する。対応するリール識別子のないかかるログ・レコードが広告リール・テーブル８２０に生成されると、対応するリール識別子をテーブル８９０内で検索することができる。対応するリール識別子が見つからない場合には、当該リール識別子を有するレコードを生成し、関係８９５を形成し、カウント・フィールドを「１」に設定するが、フィーチャ・リール・テーブル８９０にレコードが既に存在する場合には、参照カウント・フィールドを増加させる。関係８９８は、リール識別子をテーブル８８０内のフィーチャ・レコードと関連付け、予め存在することができる。例えば、システムが、特定のフィーチャＩＤに対応するリールＩＤを予め提供するか、または、（例えば、後でデータを受信するかまたはスケジュール・テーブル８０１内のレコードとの十分な対応からデータを生成するため）後で当該フィールドを埋めることができる。
【００６４】
どのようにかかる「十分な対応」を確立できるかの例は、スケジュール・テーブル８０１にエンコードされた映画スケジュールで開始する。スケジュール・テーブル８０１は、映画館の公開ごとにレコードを含む。各レコードは、各映画館の公開を一意に特定するＳｈｏｗＩＤフィールドを有する。さらに、各レコードは、（関係８０８で決まる）特定のフィーチャを特定の時刻（開始時刻）に提供するようにスケジュールされた（関係８０３で決まる）特定の映画館を記述するためのフィールドを有する。かかるスケジュールされた上演レコードの各々は、どの広告リールにも関連付けられない（関係８５２が空）テーブル８５０内のログ・レコードに対応することができる。かかるスケジュール・上演レコードの各々は、２つの関係８５４と８４３を介して同一の映画館と関連付けられる。換言すれば、８５０内のログ・レコードは、関係８５４により決定され、特定のサーバに由来する。当該サーバは、関係８４３で決まる特定の映画館に存在する。８５０内のレコードに対するタイムスタンプは、８０１内のスケジュールされた上演レコードの開始時間から２０分くらいの間に存在する。
【００６５】
スケジュールされた上演は、直前の変更（例えば、スケジュールされた上演のキャンセル、移動、または遅延）を受けうる。さらに、スケジュールされたレコードが適用される映画館内のホールに関する不確実性が存在しうる。少なくともこれらの理由のため、システム１００は、（関係８０８によるテーブル８８０内の）単一のフィーチャに関連付けられた（テーブル８０１内の）開始時刻と（関係８９５によるテーブル８９０内の）単一のリールＩＤに関連付けられたテーブル８５０内のタイムスタンプの間のピーク相関に対して関係８９８を構築することができる。（複数の映画館およびおそらく複数の日にわたる）最大の相関は、テーブル８５０内の非広告リールＩＤが、テーブル８８０からのフィーチャＩＤの第１のリールを構成するために生ずる。フィーチャとリールの関連を決定する方式に関わらず、検証プレイアウト・テーブル８７０に格納されたパフォーマンス階層とフィーチャ規則への準拠とを後で評価するために、関係８９８をテーブル８９０に記録する。
【００６６】
他の機構が、例えば、フィーチャに対応するＣＰＬにアクセスし解析することにより、または、安全なフィーチャのプレイアウトのログをデジタル映画サーバ（例えば、サーバ１１２）から取得し、解析することにより、フィーチャ・リールまたはスケジュールされた上演を特定のフィーチャと関連付ける役割を果たししてもよい。かかる機構の何れかにより、最終的にテーブル８７０の検証プレイアウト・レコード内のフィーチャ・アイデンティティ・フィールドを埋め、関係８８７を確立する際に使用するために、どのフィーチャがそれに応じてテーブル８５０の広告キャプション・ログの各々に（例えば３０分を上回らない時間において）従うかを決定してもよい。
【００６７】
明らかに、他のデータベース構造が本発明を実施する際に使用される例示的なスキーマ８００と同じ機能を提供することができる。上記の例示的な実施形態では関係データベースを説明したが、他のパラダイムが同じ結果を上手く提供できることを当業者は本発明の教示事項から認識するであろう。したがって、デジタル映画サーバの補助コンテンツ（例えば、クローズド・キャプション）インタフェースが、報告と課金に関して広告のプレイアウトを検証する役割を果たすことができる。かかるシステムを、トレーラのプレイアウトの検証に、それが望まれる場合に使用することができる。
【図１】
2015507286.tif 000003
【図２】
2015507286.tif 000004
【図３】
2015507286.tif 000005
【図４】
2015507286.tif 000006
【図５】
2015507286.tif 000007
【図６】
2015507286.tif 000008
【図７】
2015507286.tif 000009
【図８】
2015507286.tif 000010
【国際調査報告】
2015507286.tif 000011
2015507286.tif 000012
2015507286.tif 000013