JP4724420B2 - 動的対話型アプリケーションの同期式更新 - Google Patents

Description

本発明は、一般的には双方向テレビジョンの分野に関し、より詳細には、テレビジョン放送番組と同期した対話性の自動制御に関する。

ほとんどの双方向テレビジョンシステムによって、視聴者が選択可能な対話性によって既存の放送番組を改良することが試みられる。例えば、対話性を、視聴者がセットトップボックスまたは他の装置を同調して対話性を受信し、提示できる、特殊な対話チャネルで放送することができる。この対話性は、典型的には、テレビジョン画面全体を占めるユーザインタフェースと共に提供される。この形で、視聴者が、通常のチャネルで普通の放送番組を見るか、または対話チャネルで対話性を使用するか、いずれかを選択する。他の実施形態では、対話性を、どのチャネルでもアクティブにすることができるが、対話性によってテレビジョン画面全体が塞がれる。しかし、双方向テレビジョンのこれらの実施形態は、通常は、放送されつつある放送番組と対話性が同期することを必要としない。何故ならば、対話性により、画面全体をオーバーライドし、従って、放送番組の提示が阻止されるからである。放送番組は、テレビジョン番組、コマーシャル、番組ガイドなどを含む。

双方向テレビジョンの他のバージョンは、テレビジョン画面の一部だけに表示され、放送番組に付随する対話性を提供することを意図されたものである。例えば、放送ゲーム番組に、対話性を付随させることができ、対話性によって、視聴者が、番組の間に一緒にプレイでき、提示される質問に対する回答を入力できるようにする。この対話性は、テレビジョン画面の一部だけに表示されて、視聴者が、放送番組を見続けることができるようになる。

放送番組に付随する対話性について、対話性を、放送番組と同期している状態に維持することが望ましい。これは、対話性が付随する放送番組が放送されている時に、必ず対話性が視聴者から使用可能であることと、例えば、ゲームでの累積ポイント合計など、視聴者が作成するすべての状態情報が、例えばコマーシャルの時間中など、放送番組が一時的に中断され、再開される場合であっても、維持されなければならないことを意味する。

これは、さらに、付随する放送番組が放送されていない時、または別の形で中断される時に、対話性を表示してはならないことを意味する。具体的に言うと、正しい同期は、テレビジョン番組の対話性が、番組の間にコマーシャルが放送される時に表示されないことを必要とする。これには、２つの理由がある。第１に、コマーシャルは、それに付随するそれ自体の対話性、例えば、コマーシャル中に宣伝される製品に関する製品情報をユーザが要求するフォームなどを有する場合がある。従って、コマーシャルの対話性を表示しなければならず、それでも、コマーシャル（または一連のコマーシャル）が終り、テレビジョン番組が再開された時に、番組の対話性を再表示しなければならない。番組の対話性の再表示は、迅速でなければならず、注記したように、コマーシャルが開始された時に使用可能であった状態情報を保存しなければならない。例えば、視聴者が、対話型ゲームでポイントを累積した場合に、累積されたポイントが、番組の対話性が再開される時に使用可能にならなければならない。

第２に、コマーシャルが、それ自体の対話性を有しない場合であっても、コマーシャル中に番組の対話性を表示することは不適切である。これは、対話性によってテレビジョン画面の一部がオーバーライドされ、これによって、コマーシャルの一部が隠されるが、これが、コマーシャルの放送について支払った広告主にとって許容できないものであるからである。また、番組の対話性は、コマーシャルに関連せず、その外見によって、視聴者が混乱する可能性がある。

従って、さまざまな放送番組の対話性を正しく同期化し、他の放送番組による放送番組の中断に対処する、双方向テレビジョンシステム、方法、およびソフトウェア製品を提供することが望ましい。

双方向テレビジョンシステムとは別に、通常のテレビジョン放送システムによって、放送番組を選択し、放送送信のために出力する形に対するさまざまな度合の自動化された制御および手動制御が提供される。普通の放送システムには、通常、放送スケジューリングシステム、さまざまな放送ソース、データ挿入ユニット、および送信器が含まれる。放送ソースによって、送信器を介して放送されるビデオ、オーディオ、または他のコンテンツが提供される。これらの放送ソースは、さまざまな種類のビデオおよびオーディオのテープデッキ、ビデオテープライブラリ、ディジタルオーディオ／ビデオソース、生ビデオソース、サーバコンピュータ、および類似物とすることができる。

スケジューリングシステムによって、一般に、ネイティブ制御信号のシーケンスを用いて、放送システムの放送ソースが制御される。これらの制御信号によって、さまざまな放送ソースの１つの開始、停止、ロード、または他の形の放送番組の管理が指示される。制御信号のシーケンスは、主に、どの放送ソースをどの時刻にアクティブ化または非アクティブ化するかと、アクティブ放送ソースがルーティングされるチャネル割当てを識別するプレイリストによって決定される。手動制御システムでは、制御信号が、人間のオペレータの手動操作に応答して生成されて、放送ソースが選択的にアクティブ化または非アクティブ化され、出力が適当なチャネルに割り当てられる。

放送ソースからの放送データは、送信器に渡される。送信器によって、任意の数の放送受信器へ、選択されたチャネルで放送信号が送信される。セットトップボックスまたは互換テレビジョンなどの、選択されたチャネルに同調された放送受信器によって、放送信号が受信され、放送番組が表示される。

米国特許第５６８９７９９号明細書 米国仮特許出願第０９／４３１００１号明細書

普通のスケジューリングシステムおよび手動制御によって、一般に、放送ソースまたは類似する装置だけに出力制御信号が供給される。これは、これらの制御信号が、放送ソースに固有のフォーマットであり、他の種類の放送機器を制御するように設計されていないからである。例えば、ビデオソースを制御するスケジューリングシステムでは、ビデオソース装置にとって意味がある制御信号が使用される。従って、スケジューリングシステムからの既存の制御信号を使用して、放送番組と同期した対話性の自動制御をさらに容易にするシステムおよび方法を提供することが望ましい。これは、新しい自動化対応機器を操作するためにスケジューリングシステムの修正が必要としない点で望ましい。

一部の放送で、放送番組またはその種類を、例えばテレビジョン番組またはコマーシャルとして識別するコードが、放送信号に挿入される。一般的に使用されるコードの組が、アメリカ広告業協会（American Association of Advertising Agencies Inc.）のＩＳＣＩコード（Industry Standard Coding Identification system）である。ＩＳＣＩコードは、通常は、コマーシャル放送のスポンサーであることまたは提携を示すのに使用される。しかし、これらのコードは、現在、テレビジョン番組、コマーシャル、または他の放送番組に関連する可能性がある対話性の実行を制御するのに使用されない。従って、これらおよび類似する、放送信号に組み込まれたコードを使用して、さまざまな放送番組の対話性の同期化を制御するシステムおよび方法を提供することが望ましい。

双方向テレビジョンのシステムの１つでは、上で説明したものなどの普通の放送システムと協力して、有用な対話性を提供する。そのようなシステムは、対話型アプリケーションのデータベースが保管される放送サーバを含む。対話型アプリケーションは、さまざまな放送番組が放送される時に、そのような番組に付随させるために、放送番組に選択的に関連付けられる。放送サーバは、典型的には、所与の放送期間に関するそれ自体のプレイリストを受け取り、それに含まれるスケジューリング情報を使用して、現在放送されている特定の放送番組を識別する。放送サーバは、現在放送されている番組に関連する対話型アプリケーションを検索し、これらの対話型アプリケーションを、データ挿入ユニットに提供する。データ挿入ユニットは、対話型アプリケーションからのデータを、放送ソースからの放送データと組み合わせて、放送信号が作成し、この放送信号は、放送番組に対話型アプリケーションが付随する。組み合わされた放送信号は、送信器によって、選択されたチャネルで送信される。そのチャネルに同調された放送受信器のどれもが、放送番組と付随する対話型アプリケーションの両方を含む放送信号を受信する。放送受信器は、放送番組を表示し、対話型アプリケーションをデコードし、実行して、テレビジョン画面に適当に表示する。放送サーバは、さらに、プレイリスト内の事前定義の命令に従って、ある対話型アプリケーションの実行を選択的に開始し、停止し、中断し、または再開するように放送受信器にコマンドを送ることができる。

しかし、放送会社サーバは、以前に、スケジューリングシステムからの制御信号に基づいて対話型アプリケーションの制御を自動化するために既存のスケジューリングシステムと統合されたことがない。これに関する問題の１つは、さまざまな種類のスケジューリングシステムが放送ソースの制御に使用する制御信号の均一性のなさおよび多様性である。スケジューリングシステムは、上で説明したように、放送ソースとインタフェースするように設計される。このシステムは、以前に、対話性を制御するために、ＩＳＣＩコードまたは類似物に応答するようにもなっていない。従って、スケジューリングシステムと放送サーバの間の効率的なインタフェースを介する同期式対話型アプリケーションを提供することが望ましい。

既存のスケジューリングシステムおよび放送サーバに関する他の問題が、対話型アプリケーションのコンテンツの部分的変更を扱う際の柔軟性のなさである。いくつかの場合に、アプリケーション自体の全体を置換するのではなく、アプリケーションのコンテンツに対する選択された変更だけを行うことが望ましい。例えば、株式相場表示器アプリケーションは、更新株式相場レコードの進行中のフィードを必要とし、他の例として、毎晩のニュース対話型アプリケーションは、現在のニュース見出しに関連する部分だけに対する変更を必要とする可能性があり、あるいは、バラエティ番組の対話型アプリケーションは、ゲストの現在のスケジュールを記述する部分だけに対する更新を必要とする可能性がある。既存のシステムは、放送信号を生成する前に、変更された情報を対話型コンテンツに一体化することによって、放送ソースで対話型アプリケーションの変更を行うことに制限されてきた。しかし、この手法では、ケーブルヘッドエンドなどのローカル放送システムが、下流位置でローカルに関連する情報または更新を挿入することができない。さらに、ローカル放送サーバによって、受信された放送信号内で識別された対話型アプリケーションを、対話型アプリケーションのカスタマイズされたバージョン（例えば、より高品位のグラフィックスを有するバージョン）に置換できるシステムでは、更新をアプリケーションと一体化するために、放送信号からの更新をカスタマイズされたアプリケーションに転送することが望ましい。

本発明は、他の放送番組および／または対話性による放送番組およびその対話性の中断に無関係に、各々の放送番組との対話性の同期表示を維持する、対話性の自動制御を提供する。

本発明の一実施形態によれば、通常は放送ソース（またはサブタイトラ（subtitlers）などの類似する装置）を制御することだけ使用される制御信号が、受け取られ、処理されて、放送サーバにコマンドが出力される。これらコマンドは、放送サーバを選択的に指示して放送受信器の対話性の実行を制御する。放送サーバは、放送受信器にコマンドを送信と、放送受信器は、コマンドを実行して対話性を制御される。

本発明によって使用される制御信号は、自動モードまたは手動モードで動作する普通の放送スケジューリングシステムから、またはビデオテープなどの放送番組と共に信号をエンコードする事前に記録されたソースからなど、様々なソースから来る可能性がある。

上記したように、制御信号は、典型的には、ビデオ、オーディオ、または他の出力装置の特定の種類など、放送ソースを制御するために特にフォーマットされる。さらに、制御信号は、これらのソースの放送を単に制御と、制御信号は、対話性の実行に対する直接のまたは固有の関係を有しない。従って、本発明では、制御信号が、対話性の実行を選択的に制御するために放送サーバが受入可能であるコマンドに変換される。

本発明では、さまざまな放送受信器の対話性の実行の現在の状態を判定するのに、放送サーバからの状態情報も使用することができ、この状態情報により、スケジューリングシステムからの他の不透明な制御信号に応答して異なるコマンドが生成できるようにする。

本発明によって、さまざまな異なる種類の放送スケジューリングシステムの対話性の自動化された同期式制御が提供される。一般に、さまざまな種類のスケジューリングシステムによって、その制御信号で異なる量および種類の情報が提供される。

ある基本的なスケジューリングシステムでは、単に、放送番組の開始、停止、または準備を示す制御信号が提供され、この信号は、時々、番組の放送番組ＩＤを含む場合がある。この種類のスケジューリングシステムについて、放送番組の識別（例えば、テレビジョン番組またはコマーシャル）を使用して、放送番組に関して付随する対話型アプリケーションがあるかどうかを判定し、タイミング情報を使用して、対話型アプリケーションの開始、停止、中断、または再開を行わなければならないかどうかを判定する。適当なコマンドおよびデータが、放送サーバに供給されて、対話型アプリケーションの放送が選択的に制御される。

他の種類のスケジューリングシステムでは、テレビジョン番組中に放送されるコマーシャル番組を識別するのに使用できるが、それ以外ではテレビジョン番組自体を識別しない制御信号が供給される。本発明では、この情報を使用して、コマーシャルに関連する対話性を識別し、従って、コマーシャルが放送されるテレビジョン番組に付随する可能性がある対話性を選択的に中断し、再開するコマンドと共に、識別された対話性の放送をもたらすために放送サーバにコマンドを提供する。

さらに他の種類のスケジューリングシステムでは、放送番組をその持続時間と共に識別する制御信号が提供される。この場合に、本発明では、放送番組および間に入るコマーシャルの適当な対話性を中断し、再開することができる。

一実施形態では、本発明は、既存の普通の放送スケジューリングシステムと、対話型アプリケーション（および他の形態の対話性）のサーバとの間をインタフェースして、スケジューリングシステムによって出力される制御信号に応答して、放送番組に付随する可能性がある対話性の実行を選択的に制御する、自動化サーバを提供する。

本発明によれば、自動化サーバは、さらに、放送サーバとインタフェースして、対話型アプリケーションの実行の選択的な開始、取消、中断、および再開のために放送サーバにコマンドを供給する。スケジューリングシステムからの制御信号を使用して、自動化サーバによって、どの放送番組が放送されているかが判定され、各放送番組の状態に関する状態情報が作成され、維持される。放送番組およびそれに関連する対話性（ある場合に）を識別する情報を使用して、自動化サーバは、各対話型アプリケーションの状態に関する状態情報を維持する。この状態情報およびスケジューリングシステムからの制御信号を使用して、自動化サーバは、放送サーバに送られる適当なコマンドが判定し、放送番組と対話型アプリケーションの間の同期を維持する。

この同期式の挙動によって、関連する放送番組が表示される時に表示され、他の時に表示されない対話性がもたらされる。例えば、本発明では、１つまたは複数のコマーシャルの時間（それぞれが複数のコマーシャルを有する場合があり、コマーシャルがそれ自体の対話性を有する場合がある）によってセグメントに分割されるテレビジョン番組の対話型アプリケーションの正しい同期式表示が提供される。本発明では、スケジューリングシステムの制御信号から、放送またはテレビジョン番組中のいつ、コマーシャルの時間が発生したかが検出される。本発明では、コマーシャルの時間が終わった後に、同一のテレビジョン番組のさらなるセグメントがないと安全に判定できる時まで、対話性を取り消さずに、テレビジョン番組の対話性の実行を中断（停止）することができる。コマーシャルの時間中に、コマーシャルに適当な対話性が実行される。テレビジョン番組が再開される、すなわち、テレビジョン番組の他のセグメントが放送される場合に、本発明では、前のセグメントと現在のセグメントが関連することが検出され、中断された対話性が再開始され、コマーシャルの時間の前に作成された可能性があるすべての状態情報（例えば、現在のゲームポイント、フォームデータなど）が復元される。テレビジョン番組が、コマーシャルの時間の後に再開されず、新しいテレビジョン番組が放送される場合に、やはり、本発明では、この放送番組の変化が検出され、前のテレビジョン番組の対話性が打ち切られ、次のテレビジョン番組の対話性が開始される。

本発明の一実施形態では、自動化サーバは、複数のチャネルインタフェースを含み、このチャネルインタフェースの各々は、特定のチャネルの制御情報を受け取り、管理する。各チャネルインタフェースは、トランスレータモジュールおよびイベントマネージャを含む。トランスレータモジュールは、チャネルの放送番組に関係するスケジューリングシステムからのネイティブ制御信号を、固定された組のアトミックコマンドに変換する。トランスレータは、各放送番組のライフサイクルに関する状態情報を維持する。イベントマネージャは、アトミックコマンドを受け取り、放送サーバへのコマンドに処理して、放送番組の対話性が制御する。イベントマネージャは、チャネルの対話型アプリケーションのライフサイクルに関する状態情報を維持と、この状態情報から、放送サーバへの適当なコマンドを生成する。別々のトランスレータおよびイベントマネージャを使用することによって、本発明では、異なるトランスレータの使用によって異なるスケジューリングシステムとの簡単なインタフェースが可能になると同時に、同一のイベントマネージャが残される。さらに、トランスレータモジュールとイベントマネージャの分離によって、新しい種類のイベントマネージャを作成することによって、トランスレータモジュールの変更を必要とせずに、自動化サーバが、異なる種類の放送サーバと潜在的にインタフェースできるようになる。この特徴によって、自動化サーバが、将来に開発される可能性があるさまざまな標準規格で定義される対話性と協力できるようになる。

本発明に関して、対話性は、放送番組と同一の信号で送信され、放送信号を受信する放送受信器または他のエンドユーザ装置によって実行される対話型アプリケーション、ケーブルヘッドエンドまたは他の放送ソースで実行される対話型アプリケーション、普通のコンピュータで実行され、放送番組と同期してインターネットまたは他のネットワークを介してブロードキャストされる対話型アプリケーション、または放送番組と非同期に供給され、必要に応じて実行されるものなど、すべての形式の対話型アプリケーションによって提供することができる。

他の実施形態で、本発明では、放送信号内の対話型アプリケーションの更新されたレコードを検出し、これらの更新を放送サーバに選択的に供給する。これによって、放送サーバによって、これらの更新を、そのアプリケーションを受信する放送受信器に放送できるようになり、そのような更新をアプリケーションに一体化できるようになる。このシステムの一実施形態は、コードリーダおよびコード検出器を有する更新マネージャを含む。コード検出器は、放送信号内のアプリケーション識別コードの存在、不在、または変更を検出し、自動化サーバ内のトランスレータモジュール（またはイベントマネージャ）に、それに応じてシグナルが送られる。コードリーダは、放送信号から更新されたレコードを抽出する。イベントマネージャは、コードリーダに、放送サーバへの更新されたレコードの供給を開始または停止するシグナルを送る。これによって、放送サーバを有するローカルシステムが、放送信号から更新を抽出し、アプリケーションのローカルバージョンにこれらの更新を一体化できるようになる。これによって、リモート放送会社（例えば、ネットワーク放送会社）からの更新と、ローカルに関連するか、またはカスタマイズされたアプリケーション（例えば、高帯域幅ディジタルアプリケーション）の両方を組み合わせる。

本発明の自動化サーバは、ソフトウェア製品として、または専用ハードウェアおよびソフトウェアを含むより大規模なシステムまたは装置の一部として、実施することができる。本発明は、放送番組に関連する対話性の実行を制御するさまざまな方法として実践することもできる。

図１を参照すると、本発明にかかるシステムの図が示されている。図１に示されたシステムを、本発明の特徴および長所を提供しながら、より大きくより複雑なシステムに組み込むことができることを諒解されたい。

（Ａ．システムの概要）
一般に、システム１００は、スケジューリングシステム１０６、自動化サーバ１０８、放送サーバ１１０、トラフィックシステム１０４、放送番組ソース１０２、データ挿入ユニット１１６、および送信器１１８を含む。これらの要素を、典型的には、ケーブルオペレータによってケーブルヘッドエンドで使用される実施形態で使用する。他の設備での本発明の実施は、確かに実現可能である。放送受信器（ＢＲ）１２０が、視聴者の自宅、仕事場などにリモートに分散される。番組を受信する人を、「加入者」または「視聴者」と称する。

システム１００は、複数の放送会社１１４と協力する。放送会社１１４は、放送される番組材料をＢＲ１２０に供給する。本明細書で使用される「放送会社」１１４は、放送信号で搬送される番組を提供する実体である。「番組」は、放送の別個のセグメントである。従って、本明細書で定義される番組は、テレビジョン番組、コマーシャル、公共サービス情報、ペイパービューイベント、および類似物を含む。放送会社は、テレビジョン網、ならびにコマーシャルを準備する広告主、ペイーパービュープロバイダ、ケーブル網、および類似物を含む。

放送会社１１４は、必要なオーディオデータおよび他のデータを含む放送ビデオデータを、ビデオカセットプレイヤ、ビデオレーザディスクプレイヤ、サブタイトラ、ビデオサーバ、キャラクタジェネレータ、オーディオカートマシン（audio cart machine）、スチールストア（still store）、ディジタル効果システム、生スタジオフィード、生リモートフィールドフィード（例えば、生のスポーツイベント会場のカメラから）、および番組材料を含むか生成する類似物など、さまざまな放送番組ソース１０２に供給する。放送ビデオデータは、放送に必要になるまで、放送番組ソース１０２に保管される。適当な放送番組ソースは、米国カリフォルニア州アナハイムのOdetics,Inc.社のＴＣＳ４５、米国カリフォルニア州パロアルトのHewlett-Packard社のMediaStream Server、および類似する装置またはシステムを含む。

トラフィックシステム１０４は、放送会社１１４から番組スケジュールを受け取る。番組スケジュールは、放送会社１１４によって供給される番組のどれが、どの時間にどのチャネルで放送されるかを定義する。放送会社１１４に応じて、コマーシャル番組を、番組スケジュールに含めることができ、あるいは、スケジュールにスロットを設けて、他の放送会社１１４によって提供されるコマーシャルを挿入することができる。トラフィックシステム１０４は、多数の異なる放送会社からの番組スケジュールを、例えばケーブルオペレータによって、ローカルに生成される放送スケジュール情報と一体化されて、プレイリスト１１３を作る。適切なトラフィックシステム１０４が、Columbine JDS Systems,Inc.社のColumbine JDSである。

一実施形態では、このプレイリスト１１３が、放送に先立って準備され、特定の時刻に放送される番組が識別される。プレイリスト１１３は、各番組を識別するのに十分な情報、開始時刻および終了時刻、チャネル割当て、および網割当てを含むことが好ましい。さらに、特定の時刻の番組ごとに、その番組を出力する特定の放送番組ソース１０２を識別する情報が存在する場合がある。

スケジューリングシステム１０６は、手動制御コンポーネント、自動制御コンポーネント、またはその両方と、適当なスイッチング装置を含むことができる。スケジューリングシステム１０６は、さらに、どの放送番組がどの時刻にどの放送番組ソース１０２を使用して放送されるかを記述したプレイリスト１１３を受け取る。この手動および／または自動のコンポーネントを介して、スケジューリングシステム１０６は、放送番組ソースを各々の放送媒体に結合して、所与の時刻にどの番組ソースをどの放送媒体に出力するかを制御する。具体的に言うと、スケジューリングシステム１０６は、さまざまな放送番組ソース１０２の１つのためにフォーマットされ、典型的にはそのソースだけに意味がある、ネイティブ制御信号が出力される。自動化コンポーネントおよび手動コンポーネントの種類および複雑さは、多様であり、従って、それらが供給する制御信号の種類も多様である。スケジューリングシステム１０６の手動コンポーネントは、オペレータによって、必要に応じて放送番組ソース１０２を手動で選択し、アクティブ化し、同様に自動化サーバ１０８によって受け取られる対応する制御信号を生成するのに使用される。

自動化サーバ１０８への制御信号のも他のソースは、放送番組ソース１０２の放送データに含められる、事前に記録された制御信号を含む。従って、特定の放送番組に適する制御信号を、適当な時に、事前生成し、放送番組のビデオテープに保管することができる。この形での制御信号の保管は、放送番組が保管されるどの媒体に対しても行うことができる。代替案では、制御信号を、事前に記録し、放送番組とは別の媒体に保管するが、これらを一緒に再生することができる。代替案では、制御信号を、例えばＶＩＴＣタイムコードジェネレータまたはＮＯＲＰＡＫデータ挿入ユニットを使用して、リアルタイムで放送データに埋め込むことができる。

さらに、制御信号を得る方法は、スケジューリングシステム１０６からのプッシュまたはスケジューリングシステム１０６のポーリングのいずれかによって行うことができる。

放送サーバ１１０は、本明細書に記載の機能性を提供する１つまたは複数のソフトウェアプログラムを実行するコンピュータシステムであることが好ましい。適当な放送サーバが、米国カリフォルニア州アラメダの本願特許出願人のWink Broadcast Serverである。放送サーバ１１０は、対話型アプリケーションデータベース１１２を含む。対話型アプリケーションデータベース１１２は、さまざまなリモートに分散されたＢＲ１２０に放送される、対話型アプリケーションまたは他の形の対話性を保管する。対話型アプリケーションまたは他の形の対話型コンテンツを、放送会社１１４または他の番組供給業者が対話型アプリケーションデータベース１１２に追加することができ、セキュアネットワークリンクまたは他の伝送媒体によって対話型アプリケーションデータベース１１２に送信することができる。データベース１１２内のフィールドは、対話型アプリケーションを、例えば、特定の放送会社、ネットワーク、チャネル、番組、および／または放送時間に関連付ける。さらに、データベース１１２内の各対話型アプリケーションは、一意の対話型アプリケーション識別コードを有し、これによって識別できることが好ましい。対話型アプリケーション識別コードと番組識別コード（放送ソースによって使用されるものなど）の関連付けは、放送サーバ１１０が、番組識別コードの受取に応答して、対話型アプリケーションを選択的に検索できるようにする。参照を簡単にするために、用語「対話型アプリケーション」に、本明細書に記載のまたは開示されるものと同等の放送番組に関する対話性のすべての形態を含める。

本発明の一実施形態では、データベース１１２に保管される対話型アプリケーションを、コンパクトな通信プロトコルによって記述する。このコンパクトなプロトコルは、システムコンポーネントの間で効率的な方法で情報およびコマンドのコンパクトなセットをブロードキャストするように設計され、これによって、垂直帰線消去期間（「ＶＢＩ」）などの低帯域幅トランスポートの使用が可能になる。本発明の好ましい実施形態では、本明細書に記載のコンパクトなプロトコルが使用されるが、対話型アプリケーションを、例えばＨＴＭＬ（Hyper Text Markup Language）、ＸＭＬ（Extended Markup Language）、SUN MICROSYSTEMS INC.社のJAVA（登録商標）言語、またはＨＴＭＬベースの双方向テレビジョンプロトコルＡＴＶＥＦを含む他のプロトコルによって記述することができる。対話型アプリケーションに適する１つのコンパクトなプロトコルの、サポートされる定義、スクリプト、およびコマンドを含む詳細な説明が、特許文献１に開示されている。対話型アプリケーション自体は、実行可能コードおよびデータを含むソフトウェア製品であり、この実行可能コードおよびデータによって、下でさらに説明するように、放送受信器１２０の動作が構成され、制御される。

複数の放送サーバ１１０を設けることができ、各放送サーバ１１０は、特定の地理的地域、放送会社のセット、または加入者のセットを提供する。一実施形態では、各放送サーバ１１０が、一意のサーバ識別コードによって識別される。

一般に、放送サーバ１１０は、特定の時に特定のチャネルでどの対話型アプリケーションを放送しなければならないかを判定し、特定のチャネルおよび時刻または番組識別コードに対応する対話型アプリケーションをデータベース１１２から検索と、放送のために対話型アプリケーションを準備する。

さまざまな時刻、チャネルなどにどの対話型アプリケーションを放送するかを判定するために、放送サーバ１１０は、放送される番組のプレイリスト１１３を、トラフィックシステム１０４から受け取る。放送サーバ１１０は、この情報を使用して、各放送番組に付随する対応する対話型アプリケーション（があれば）を識別し、データベース１１２から検索する。放送サーバ１１０は、さらに、受信されるか既に受信され、ＢＲ１２０のメモリに常駐する可能性がある対話型アプリケーションの開始、停止、取消、中断、または再開を指示するＢＲ１２０に、ブロードキャストされるコマンドを出力する。

放送サーバ１１０は、必要な場合に検索された対話型アプリケーションをフォーマットし、他の形で、放送信号に挿入する準備をする。放送会社１１４から受け取ったプレイリスト１１３を使用して、放送サーバ１１０は、対話型アプリケーション１１５および／またはさまざまなコマンドを、データ挿入ユニット１１６（「ＤＩＵ」）に渡して、対話型アプリケーション１１５を、番組の放送と同時に放送データ１１７に組み込む。

ＤＩＵ１１６は、放送サーバ１１０からの対話型アプリケーション１１５またはコマンドと、対話型アプリケーション１１５に対応する番組を担持する放送信号またはフィードを受け取る。放送フィードは、放送番組ソースから、放送会社１１４から直接に、または、放送会社がフィードを供給しない場合に、ネットワーク、ケーブルオペレータ、またはローカルテレビジョン局などのサードパーティから、受け取ることができる。ＤＩＵ１１６は、対話型アプリケーション１１５およびコマンドを、放送会社フィードへの挿入および放送データ１１７としての送信に適するフォーマットに変換する。ＤＩＵ１１６は、複数の放送会社からフィードを受け取ることができ、別々の対話型アプリケーションを各フィードに挿入することができる。同様に、ＤＩＵ１１６は、別々の対話型アプリケーションを、同一のまたは異なる放送会社１１４からの複数のチャネルに同時に挿入することができる。

ＤＩＵ１１６は、対話型アプリケーション、コマンド、および放送番組を含む放送データ１１７を、放送媒体に挿入する。放送媒体は、対話型アプリケーション１１５を搬送するのに使用される周波数スペクトルである。一実施形態では、放送媒体が、ＮＴＳＣ（National Television Standards Committee）標準規格に従う標準アナログテレビジョン信号であり、ＶＢＩが、対話型アプリケーションの放送のトランスポートとして使用される。トランスポートは、放送媒体のうちで、対話型アプリケーション１１５を搬送する特定の部分である。他の実施形態では、放送媒体が、１つまたは複数のMPEG2 Video Servicesを含む標準MPEG2 Digital Video Multiplexであり、この多重分離器のMPEG2 elementary stream（またはストリーム）が、トランスポートとして使用される。ＤＩＵ１１６は、アナログまたはディジタルのビデオソースと共に動作することができ、代替案では、放送会社１１４または放送番組ソース１０２をさまざまな送信器１１８に直接に接続する広域ネットワークへのインタフェースとして動作することができる。

一実施形態では、ＤＩＵ１１６は、対話型アプリケーションを定義するデータを放送フィードのＶＢＩに挿入する普通の方法を使用する。North American Broadcast Teletext Standard（ＥＩＡ−５０６）は、ＶＢＩの１つまたは複数の走査線でデータを送信する方法およびプロトコルを定義する。しかし、対話型アプリケーション１１５をテレビジョン番組と別々に放送するものを含む、さまざまな他のトランスポート機構が使用可能である。そのようなトランスポート機構は、テレビジョン周波数スペクトルの未使用部分で対話型アプリケーション１１５を送信するアウトオブバンド送信器と、テレビジョン周波数スペクトルの外で対話型アプリケーション１１５を送信する普通の周波数変調（「ＦＭ」）無線送信器とを含む。他の実施形態では、ＤＩＵは、MPEG2 multiplexのelementary streamにデータを挿入する普通の方法が使用される。

一実施形態では、ハミングコードなどのエラー検出コードまたはエラー訂正コードが、データと共に挿入される。一実施形態では、ＤＩＵ１１６は、データをハミングコードに変換と、他の実施形態では、ＤＩＵ１１６が放送サーバ１１０から受け取るデータは、既にエンコードされている。

ＤＩＵ１１６は、放送サーバ１１０からの挿入された対話型アプリケーションまたはコマンドのすべてを含む放送フィードを送信するために送信器１１８に結合される。一実施形態では、送信器１１８が、フィードをローカルアップリンク受信器に送信する衛星アップリンクであり、ローカルアップリンク受信器は、ケーブルを介してＢＲ１２０にフィードを配布する。他の実施形態では、送信器１１８は、普通のケーブルシステムヘッドエンド増幅器である。他の実施形態では、送信器１１８は、普通のテレビジョン放送送信器または高品位テレビジョンディジタル送信器である。他の実施形態では、送信器１１８は、ＷＡＮ接続、インターネット、または他の公衆／私有ネットワークを介して放送データを送信することができる。

他の実施形態では、ＤＩＵ１１６は、番組放送の前に、番組に対話型アプリケーション１１５を挿入する。例えば、ＤＩＵ１１６は、テレビジョンコマーシャルのソースコピーに対話型アプリケーションを挿入することができる。従って、この対話型アプリケーションは、コマーシャルが放送される時に必ず放送される。この実施形態では、放送サーバ１１０は、対話型アプリケーションの検索を、プレイリストにリストされたスケジュールと同期化させる必要がない。しかし、自動化サーバ１０８は、それでもコマーシャルの放送中に放送される対話型アプリケーションの動作と、コマーシャルが放送されるテレビジョン番組中に放送される対話型アプリケーションの動作との同期化を制御するのに使用される。

送信方法および挿入の時に無関係に、対話型アプリケーションを含む放送データ１１７は、加入者のＢＲ１２０によって受信される。単一のＢＲ１２０だけが図１に示されているが、通常の実施形態で、放送データ１１７を受信し、本明細書に記載のように応答する数百または数千のＢＲ１２０があることを理解されたい。通常の実施形態では、ＢＲ１２０は、同軸ケーブルを介してデータ１１７を受信するテレビジョンセットトップボックスである。さらに、ＢＲ１２０を、テレビジョンに一体化することができる。さらに、ＮＴＳＣ放送受信器、高品位テレビジョンディジタル受信器、ビデオカセットレコーダ、またはＦＭラジオ受信器を含む他の放送受信器を使用することもできる。

上記のアーキテクチャでは、複数の有用な実施形態がサポートされ、これらの実施形態では、自動化サーバ１０８は、放送サーバ１１０を制御して、さまざまな種類およびフォーマットのデータを送信して、放送番組との同期式の挙動を達成する。最初に、放送サーバ１１０は、対話型アプリケーションとは別にまたはそれに加えて、他の種類のデータもサービスできることに留意されたい。例えば、放送サーバは、コンピュータプログラムまたはオーディオ／ビデオデータなどのデータをサービスすることができる。放送サーバは、前に放送受信器に送信された対話型アプリケーションに、データ、フォーム、コード、またはトリガを供給することもできる。

これらのさまざまな種類のデータを、本発明に従って、自動化サーバ１０８からのコマンドに応答して送信することができる。例えば、放送サーバによって、対話型アプリケーションおよびそれに関連する放送番組が表示される時より十分に前に、対話型アプリケーションを放送受信器に送出することができる。その後、自動化サーバ１０８からのコマンドに応答して、放送サーバ１１０は、トリガコードを送出することができ、このトリガコードは、前にロードされた対話型アプリケーションの実行をトリガし、その結果、対話型アプリケーションが、放送番組と同期して実行されるようになる。同様に、自動化サーバ１０８に応答して、放送サーバ１１０は、フォームまたは他のデータを送信して、既に放送受信器に常駐している対話型アプリケーションの特徴、ユーザインタフェース、または機能性を更新または修正することができる。これによって、自動化サーバ１０８によって、スケジューリングシステム１０６からの制御信号に応答して、対話型アプリケーションを操作または変更できるようになる。

放送サーバ１１０は、テキスト、グラフィックス、イメージ、ＵＲＬ（uniform resource locator）、ＵＲＩ（uniform resource identifier）、ＨＴＭＬ、ＸＭＬ、ＡＴＶＥＦ、ＪＡＶＡ（登録商標）アプレット、あるいは他の種類またはフォーマットのデータなどのハイパーメディアデータを、やはり自動化サーバ１０８からのコマンドに応答してサービスすることもできる。例えば、テレビジョン番組の開始を示す制御信号を供給するスケジューリングシステム１０６に応答して、自動化サーバ１０８は、放送サーバ１１０に指示して、ウェブサイトまたはウェブページへのＵＲＬを放送受信器に送信することができ、この放送受信器は、ユーザへの表示のためにウェブサイトをロードして、ウェブサイトがテレビジョン番組と同時に表示される。

自動化サーバ１０８からのコマンドに応答して、放送サーバ１１０は、サービスすることができる、これらおよび他の種類のデータのすべてについて、対話型アプリケーションデータベースまたは類似物は、放送番組の番組識別子に関連してデータを保管する。これによって、自動化サーバ１０８が、スケジューリングシステム１０６の制御信号からの番組識別子を与えられて、サービスすべき適当なデータを判定できるようになる。

（Ｂ．放送受信器）
図２に、本発明にかかる実施形態によるＢＲ１２０の実施形態を示す。一実施形態では、ＢＲ１２０は、General Instrument CFT-2200 ＣＡＴＶセットトップデコーダである。ＢＲ１２０は、送信器１１８から放送データ１１７を受信するチューナ２０２を含む。一実施形態では、チューナ２０２は、普通のケーブルテレビジョンチューナである。他の実施形態では、チューナは、テレビジョン放送チューナ、ＦＭラジオチューナ、ディジタルチューナ、または他の形のチューナである。他の実施形態では、適当なハードウェアおよびソフトウェアを有するパーソナルコンピュータは、ケーブル、インターネット、および衛星を含むさまざまな種類の送信チャネルを介して受信される放送番組を表示するように機能することができる。図２に示された実施形態には、通常はテレビジョンであるディスプレイ２１８が、ＢＲ１２０内に示されている。上で言及したように、ディスプレイ２１８を、ＢＲ１２０の外部に配置することもできる。

ＢＲ１２０は、放送データ１１７から対話型アプリケーションを抽出する、チューナ２０２に結合されたデータ抽出器２０６を含む。一実施形態では、データ抽出器２０６は、普通のＶＢＩインバンドデータ抽出回路である。他の実施形態では、データ抽出器２０６は、普通のモデムである。データ抽出器２０６は、抽出された対話型アプリケーションを含むシリアルビットストリームを、バス２０８上に供給する。バス２０８は、マイクロプロセッサ２１０に結合され、マイクロプロセッサ２１０は、バス２０８を介して、抽出された対話型アプリケーションを、第２記憶装置２１４に保管されたプログラムによる指示に従って、第１記憶装置２１２に保管する。一実施形態では、マイクロプロセッサ２１０は、抽出されたデータからのエラー訂正情報を使用して、デコードされた対話型アプリケーションのエラーを検査または訂正する。一実施形態では、第１記憶装置２１２は、普通のランダムアクセスメモリ（「ＲＡＭ」）であり、第２記憶装置２１４は、普通の読取専用メモリ（「ＲＯＭ」）である。ＲＡＭまたはフラッシュメモリとすることができる第３記憶装置２１３は、マイクロプロセッサ２１０に結合されて、残りのデータを保管する。フラッシュメモリの長所は、ＢＲ１２０に常駐するソフトウェアまたはデータを、受信された対話型アプリケーションによって修正できることである。

一実施形態で、ＢＲ１２０は、データ抽出器２０６を使用して、放送データ１１７から時間信号を抽出する。時間信号は、協定世界時（「ＵＴＣ」）または加入者の地方時などの標準タイムベースを使用する現在時刻を示す。他の実施形態では、ＢＲ１２０は、加入者または受信された時間信号のいずれかによってセットされるリアルタイムクロックを有する。いずれにせよ、ＢＲ１２０は、現在時刻へのアクセスを有し、従って、日付スタンプ機能およびタイミング機能を実行することができることが好ましい。

以下で説明するように、マイクロプロセッサ２１０は、第２記憶装置２１４に保管されたプログラムおよび第１記憶装置２１２に保管された対話型アプリケーションを使用して、対話型アプリケーションを実行し、出力を提供する。第２記憶装置２１４に保管されたプログラムは、さまざまなスクリプト、フォーム、定義、コードリソース、およびグラフィックリソースによって定義される対話型アプリケーションを実行する実行エンジン２１７であることが好ましい。好ましい実行エンジンは、米国カリフォルニア州アラメダの本願特許出願人が提供するWink Engineである。放送受信器１２０は、実行エンジン２１７、または第２記憶装置２１４に保管されるネイティブオペレーティングシステム２１９のいずれかの一部として、入力値からカウントダウンするバックグラウンド処理または同等のタイミング仕様として実行できるタイマ機能を含む。

対話型アプリケーションの実行からの出力は、例えば、テレビジョン視聴者に情報またはメニューを提示するか視聴者入力を受け取るフォームとするか、ＢＲ１２０またはテレビジョンの使用データを含むか視聴者の好みを示す、無音または他の形式の応答とすることができる。本発明の目的において、フォームは、さまざまな情報のどれでも表すことができ、さまざまなユーザ応答を受け取ることができる。このために、ＢＲ１２０は、バス２０８に結合され、第１記憶装置２１２に保管された対話型アプリケーション１１５および第２記憶装置２１４に保管されたプログラムによって駆動されるグラフィックスオーバーレイジェネレータ２１６を含むことが好ましい。グラフィックスオーバーレイジェネレータ２１６は、対話型アプリケーション１１５に応答してグラフィカルディスプレイを生成する。このグラフィカルディスプレイは、ＢＲ１２０に結合された、典型的なテレビジョンであるディスプレイ２１８に表示される。もちろん、グラフィックスオーバーレイジェネレータ２１６は、典型的には、対話型アプリケーションがひっそりと実行される時には使用されない。

一実施形態では、グラフィックスオーバーレイジェネレータ２１６は、チューナ２０２からの放送番組に対応する放送信号を受け取り、例えば表示されたフォームへのデータの入力のために、放送番組と、対話型アプリケーション１１５のグラフィカル態様（ある場合に）の同時表示が可能になる。一実施形態では、マイクロプロセッサ２１０は、ユーザ入力レシーバ２２４に結合されたユーザ入力デコーダ２２２にも結合されて、ユーザが、対話型アプリケーション１１５に応答するために、マイクロプロセッサ２１０と通信できるようになる。一実施形態では、ユーザ入力デコーダ２２２は、普通の赤外線リモートコントロールデコーダである。ユーザ入力レシーバ２２４は、ユーザが普通のハンドヘルドリモートコントロール装置を使用できる普通の赤外線レシーバ２２４であることが好ましい。ユーザが押したリモートコントロールキーが、コード化赤外線信号に変換され、この信号がユーザ入力レシーバ２２４によって受け取られ、ユーザ入力デコーダ２２２によってデコードされ、マイクロプロセッサ２１０に送られて、ユーザが対話型アプリケーション１１５と通信できるようになる。

一実施形態では、ＢＲ１２０は、ブロードバンド同軸ケーブルを介してケーブルシステムに接続されたケーブルＴＶセットトップデコーダである。この実施形態では、ラインドライバ２３０は、通常はＲＦスペクトルのアウトオブバンド部分を使用する、同軸ケーブルを介してケーブルシステムヘッドエンドに応答を送ることができるＲＦモデムであり、通信ポート２３２は、標準的なＲＦタップである。他の実施形態では、ＢＲ１２０は、テレビジョン、ＶＣＲ、またはセットトップであり、ラインドライバ２３０は、標準電話モデムであり、通信ポート２３２は、標準的なＲＪ−１１ジャックである。

マイクロプロセッサ２１０を、普通の赤外線コマンドエンコーダ２２６に結合することもでき、この赤外線コマンドエンコーダ２２６は、赤外線コマンド入力を受け入れ、普通の赤外線エミッタ２２８用の信号をエンコードして、対話型アプリケーション１１５が外部装置を制御できるようにする。

（Ｃ．対話型アプリケーションの実行）
図３は、本発明の好ましい実施形態によるコンパクトな情報プロトコルを使用する対話型アプリケーションの受信および実行のステップを示す流れ図である。ＢＲ１２０は、放送サーバ１１０によって準備され、ＤＩＵ１１６によって挿入され、送信器１１８によって送信されたアプリケーションヘッダレコードを受信して、デコードする（３１０）。アプリケーションヘッダレコードは、それに続く情報を記述し、アプリケーションヘッダレコードは、対話型アプリケーション識別コードを含む。

対話型アプリケーションの残りの機能性は、任意の順序でエンコードし、放送することができる定義、スクリプト、およびコマンドによって記述される。定義、スクリプト、およびコマンドは、ＢＲ１２０によって受信され、デコードされ（３１２）、これらによって、残りの対話型アプリケーションを実行する時（３１４）に使用される残りのパラメータおよび応答パラメータを定義する。

受信された残りの対話型アプリケーションの一部またはすべては、ＢＲ１２０内で保管される（３１２）。一実施形態では、対話型アプリケーションは、繰り返して放送され、ＢＲ１２０は、いつでも番組に同調でき、対話型アプリケーション全体を受信できるようになる。保管された対話型アプリケーションに対する所望の更新を、受信し、デコードすることができる（３１６）。追加のまたは更新された定義、スクリプト、またはコマンドがある場合に、これらを、アプリケーションが完了する（３１８）まで送信することができる。一実施形態では、終了コマンドを放送して、対話型アプリケーションを停止することができる（３２０）。

元のアプリケーションが実行されつつあるか応答を送信しつつある間を含めて、いつでも、新しい対話型アプリケーションを送信することができる。例えば、コマーシャルに対応する新しい対話型アプリケーションは、ニュース番組に対応する元のアプリケーションに割り込むことができ、本発明によって、後者のアプリケーションを、前者の終了の後に再開することができる。

ＵＲＬなどの対話性の異なる形を使用する他の実施形態では、放送受信器１２０によって、対話性の種類に関連する適当なデコード機能性、解析機能性、および実行機能性がもたらされる。従って、ＵＲＬ種類データについて、放送受信器１２０に、ウェブページ、ＪＡＶＡ（登録商標）アプレット、および類似物を検索し、ロードし、表示する、ブラウザおよび適当な機構を含めることができる。

（Ｄ．自動化サーバ）
（１．自動化サーバの挙動の概要）
自動化サーバ１０８は、スケジューリングシステム１０６とインタフェースして、スケジューリングシステムが放送番組ソース１０２に供給する制御信号を受け取る。自動化サーバ１０８は、さらに、通信的に放送サーバ１１０に結合されて、どの対話型アプリケーションが放送のために準備されるか、またはどの対話型アプリケーションがどのチャネルで現在放送されているかに関する情報を受け取る。自動化サーバ１０８は、そのプレイリストを含む状況情報および制御信号を使用して、放送サーバ１１０への特定のコマンドを生成する。これらのコマンドは、放送サーバ１１０が、放送される対話型アプリケーションの準備または現在放送されている対話型アプリケーションの実行を選択的に制御するように指示する。

具体的に言うと、自動化サーバ１０８は、制御信号に応答して、放送サーバ１１０へのコマンドを生成して、対話型アプリケーションの実行のスケジューリング、開始、停止、または取消が行われる。自動化サーバ１０８は、これらのコマンドのシーケンスが生成して、コマーシャルおよびテレビジョン番組の両方および他の放送番組に関する適当な対話性の、表示および／または終了を含む同期式実行をもたらす。

スケジューリングシステム１０６からの制御信号は、明示的または暗黙のうちのいずれかで、特定のチャネルに関連する。制御信号、そのチャネル割り当て、およびプレイリスト情報の性質から、自動化サーバ１０８は、放送される現在の放送番組の状態および種類、または次に放送される放送番組を、適宜決定する。具体的に言うと、自動化サーバ１０８は、制御信号から、現在放送されている番組が、テレビジョン番組またはコマーシャルであることが示されるかどうかを判定する。

特定のチャネルでコマーシャルの放送が開始されたことを示す制御信号（すなわち、放送ソースの１つへの、コマーシャルに関する放送データを再生するための制御信号）の受取に応答して、自動化サーバ１０８は、対話型アプリケーションが、そのチャネルで現在実行されつつあるかどうかを判定し、そうである場合には、放送サーバ１１０へのコマンドを生成して、その対話型アプリケーションの実行を中断（停止）する。放送サーバ１１０は、このコマンドが放送受信器１２０に送信する。適当なチャネルに同調されている放送受信器は、対話型アプリケーションの実行を中断する。しかし、自動化サーバ１０８は、対話型アプリケーションを取り消さない。何故ならば、放送受信器１２０は、コマーシャルが終わったならば対話型アプリケーションを実行する必要があり、従って、対話型アプリケーションが、即座に実行するのに使用可能である必要があり、コマーシャルが開始される時に有した状態情報を保存しなければならないからである。

自動化サーバ１０８は、コマーシャルに関連する対話型アプリケーションがあるかどうかを判定する。そうである場合には、自動化サーバ１０８は、放送サーバに指示して、対話型アプリケーションを送信し、その実行を引き起こす。コマーシャルに特に関連する対話型アプリケーションがない場合には、自動化サーバ１０８は、放送サーバにシグナルを送り、デフォルト対話型アプリケーションの実行を開始する。

ある時点で、自動化サーバ１０８は、コマーシャルが終わったことを示す制御信号を受け取る。この制御信号に応答して、自動化サーバ１０８は、放送サーバ１１０へのコマンドを生成し、対話型アプリケーションの実行を再開する。放送サーバ１１０は、このコマンドを放送受信器１２０に送信する。適当なチャネルに同調された放送受信器は、このコマンドを受信し、テレビジョン番組の対話型アプリケーションの実行を再開する。

視聴者が知覚する効果は、元のテレビジョン番組に付随する対話型アプリケーションが、コマーシャル中にテレビジョン画面から除去されることである。コマーシャルに固有の対話型アプリケーション、またはデフォルトアプリケーションは、コマーシャル中に実行され、表示される。コマーシャルが終り、テレビジョン番組が再開される時に、そのテレビジョン番組の対話型アプリケーションが、再び表示される。対話型アプリケーションを、再び表示する時に、コマーシャルの前に有した状態情報（例えば現在のスコア）を有し、これによって、視聴者による対話型アプリケーションの使用が保存される。

テレビジョン番組などの放送番組は、コマーシャル期間によって分離された複数のセグメントのフォーマットを有することが典型である。テレビジョン番組に関連する対話性は、セグメントのそれぞれを通じて、その状態情報と共に一貫した形で使用可能でなければならない。自動化サーバ１０８は、この結果を、複数のセグメントが実際に単一のテレビジョン番組または他の放送番組のどちらの一部であるかを判定し、これによって、同一の対話型アプリケーションに関連するかどうかを判定するために、制御信号から抽出される情報を相関させ、放送される各セグメントを識別することによって達成する。そうでなければ関係のないセグメントをそのように相関させることによって、自動化サーバ１０８は、複数のコマーシャル期間にまたがってテレビジョン番組の単一の対話型アプリケーションを適切に中断し、再開することができる。この処理を、以下で図１２に関して詳細に説明する。

自動化サーバ１０８は、Intel社のチップセッとおよびMicrosoft Corp.社のオペレーティングシステムなどの通常のワークステーションまたはパーソナルコンピュータで実行されるソフトウェア製品として実施することができ、あるいは、専用目的のＡＳＩＣまたは他のハードウェア実施形態でエンコードすることができる。

（２．自動化サーバの機能的概要）
図４を参照すると、本発明の一実施形態にかかる自動化サーバ１０８の機能的アーキテクチャの図が示されている。この実施形態では、自動化サーバ１０８は、インタフェースマネージャ４００を含む。インタフェースマネージャ４００は、複数のチャネルインタフェース４０２を管理し、各チャネルインタフェースは、１または複数のチャネルに関連する。各チャネルインタフェース４０２は、それに割り当てられたチャネルの制御信号をスケジューリングシステム１０６から受け取り、放送サーバ１１０にコマンドを出力する。

図５を参照すると、チャネルインタフェース４０２の機能的構造が示されている。各チャネルインタフェースモジュール４０２は、トランスレータモジュール５０２およびイベントマネージャ５０４を含む。トランスレータモジュール５０２は、制御信号をスケジューリングシステム１０６から受け取り、この信号をアトミックコマンドに変換する。イベントマネージャ５０４は、アトミックコマンドを受け取り、放送サーバ１１０によって理解されるコマンドに処理する。

（３．インタフェースマネージャ）
図６を参照すると、インタフェースマネージャ４００のライフサイクル対話の図が示されている。インタフェースマネージャ４００は、異なるスケジューリングシステム１０６のすべてのチャネルインタフェース４０２を作成し、維持する。インタフェースマネージャ４００は、３つのフェーズすなわち、初期化フェーズ、実行フェーズ、およびシャットダウンフェーズを有する。自動化サーバ１０８の起動時に、自動化サーバ１０８は、インタフェースマネージャ４００を作成し（６０２）、初期化する。この初期化フェーズ中に、インタフェースマネージャ４００は、初期化（ｉｎｉ）ファイルを読み取り（６０４）、スケジューリングシステム１０６と共に動作する必要がある異なるチャネルインタフェース４０２を作成し（６０６）、初期化する（６０８）。

インタフェースマネージャ４００は、すべての必要なオブジェクトが作成され、初期化されたならば、インタフェースマネージャ４００は、実行フェーズに遷移する。このフェーズの間に、インタフェースマネージャ４００は、各チャネルインタフェース４０２が動作するように要求する（６１０）。

通常は、自動化サーバ１０８およびそのインタフェースマネージャ４００は、長い期間にわたって実行フェーズに留まる。しかし、回復不能エラーがある時または自動化サーバ１０８が更新を必要とする場合に、自動化サーバ１０８がシャットダウンされる。このシャットダウンフェーズ中に、インタフェースマネージャは、各チャネルインタフェース４０２をシャットダウンすることを要求する（６１２）。

図７を参照すると、各チャネルインタフェース４０２のライフサイクル対話図が示されている。図４に示されているように、各チャネルインタフェース４０２は、トランスレータモジュール５０２およびイベントマネージャ５０４を含む。チャネルインタフェース４０２は、３つのメインフェーズすなわち、初期化フェーズ、実行フェーズ、およびシャットダウンフェーズを有する。

初期化フェーズ中に、トランスレータモジュール５０２およびイベントマネージャ５０４を作成し（７０２）、初期化する（７０４）。イベントマネージャ５０４の初期化パラメータは、下記の情報を含む。
・イベント種類ごとの、放送サーバイベントを構成する方法、
・対話型アプリケーションを探す場所、
・自動化サーバのタイミングを微調整するためのパラメータ、
・放送サーバに接続する方法、
・放送サーバからの突然の切断に応答する方法、
・イベントが事前にスケジューリングされるかどうか。

トランスレータモジュール５０２の初期化パラメータは、下記の情報を含む。
・スケジューリングシステムに接続する方法、
・スケジューリングシステムからの突然の切断に応答する方法、
・異なる放送会社によって異なる形で使用できる場合の特定のコマンドを解釈する方法など、スケジューリングシステム固有のパラメータ、
・スケジューリングシステムからコマンドを読み取り、解釈する方法の微調整、
・コマーシャルを番組から区別するのに使用される正規表現または他の情報。

実行フェーズ中に、チャネルインタフェース４０２は、無限ループ（イベントループ）（７０８）に入って、スケジューリングシステム１０６からの制御信号を処理する。また、チャネルインタフェース４０２は、別々の自動化サーバクライアントから直接に要求を受け取る（例えばシャットダウン要求）。チャネルインタフェース４０２は、トランスレータモジュール５０２にアトミックコマンドを要求し（７１０）、それらがイベント関連である場合には、イベントマネージャ５０４に渡される（７１２）。アトミックコマンドが、ＮｕｌｌコマンドまたはＥｒｒｏｒコマンドである場合には、チャネルインタフェース４０２は、そのコマンド自体を処理する（７１４）。回復不能エラーが発生する場合には、そのエラーがログ記録され、イベントループから抜ける（７１５）。

シャットダウンフェーズ中に、チャネルインタフェース４０２は、シャットダウン要求を受け取ると（７１６）、その要求をトランスレータモジュール５０２およびイベントマネージャ５０４に転送され（７１８）、これらをクリーンにシャットダウンすることができる。これらがシャットダウンされたならば、チャネルインタフェース４０２は、それ自体がクリーンアップし、イベントループからリターンして、それ自体をシャットダウンする。

（４．トランスレータモジュールの概要）
各放送番組は、特定の「ライフサイクル」を有するものとして理解することができる。このライフサイクルは、スケジューリングシステム１０６によって管理され、スケジューリングシステム１０６は、同様に、本質的に、各放送番組に関するステートマシンとして動作する。しかし、スケジューリングシステム１０６は、放送番組に関する限られた量の情報、典型的には放送ソースを制御するのに必要な量だけを提供する。

放送番組ごとに、トランスレータモジュール５０２は、スケジューリングシステム１０６から受け取る限られた情報に基づいて、ステートマシンの挙動を再構成して、放送番組のライフサイクルを再作成する。これによって、放送番組に関連する可能性がある対話型アプリケーションを管理するのに適当なアトミックコマンドを、イベントマネージャ５０４に提供できるようになる。従って、図５に示されているように、トランスレータモジュール５０２は、スケジューリングシステム１０６からの制御信号で識別される一意の放送番組ごとに、ステートマシン５１０を作成し、維持する。

各トランスレータモジュール５０２は、それと通信するスケジューリングシステム１０６の種類に固有であり、各トランスレータモジュール５０２は、スケジューリングシステム１０６からトランスレータモジュール５０２によって理解できるイベントの組への状態のマッピングを提供する。スケジューリングシステム１０６の各種類は、その制御信号で異なる種類の情報を提供するので、エラー、欠けている情報などを考慮に入れて、スケジューリングシステム１０６の暗黙のステートマシンを、トランスレータモジュール５０２によって定義されるステートマシンにマッピングする必要がある。

注記したように、さまざまな種類のスケジューリングシステム１０６があり、各々によって様々なレベルの情報を有する異なる種類の制御信号が出力され、従って、トランスレータモジュール５０２のそれぞれが、ある種類のスケジューリングシステム１０６に対応する。しかし、すべてのスケジューリングシステム１０６を、制御信号の最も完全な組を提供する「理想的な」スケジューリングシステム１０６に関して記述することができると思われる。表１に、理想的なスケジューリングシステム１０６によって提供される制御信号の種類と、これらの理想的な信号種類のそれぞれに含まれるデータを示す。

これらの信号は、指定されたデータのすべてが存在する場合に、トランスレータモジュール５０２が、放送番組の適当な状態を非常に簡単に判定し、イベントマネージャ５０４に通信される必要なデータを形成できるという意味で、理想的である。理想的でないスケジューリングシステム１０６では、トランスレータモジュール５０２は、データの追加の外部ソースを使用して、放送サーバ１１０のプレイリストなどのイベントマネージャ５０４に送信するのに適当なデータと、対話型アプリケーションデータベースに含まれる放送番組識別子に対する対話型アプリケーションの関係に関する情報とを判定する。

プリロード信号とは、典型的には、スケジューリングシステム１０６によって通常使用され、放送ソース１０２に後の時刻に放送されると予想される放送番組をロードさせる制御信号である。理想的には、この信号は、ロードされる放送番組を一意に識別する番組ＩＤを含む。チャネル識別は、放送に関するチャネルを指定し、このチャネルは、暗黙または明示的とすることができる。持続時間は、放送番組の長さを指定する。これは、自動化サーバ１０８によって使用され、スケジューリングシステム１０６からの明示的な停止信号がない場合に対話型アプリケーションを終了させる。

プリロード信号は、正確な時刻に受け取られる場合も、そうでない場合もある。すなわち、いくつかのスケジューリングシステムでは、プリロード信号が正確に（イベントの放送の前の数分の１秒の精度で）受け取られる。他のシステムでは、プリロード信号が、イベントの放送の数分から数時間前に受け取られる可能性がある。プリロール信号、イベント開始信号、およびイベント停止信号は、正確なタイミングで送られなければならない。ネイティブ制御信号が、プリロード信号および他の制御信号の両方に使用される場合には、これも正確なタイミングで送られなければならない。

対話型アプリケーション位置は、放送番組に付随するように指定された対話型アプリケーションの位置を指定する。この位置を、対話型アプリケーションデータベース１１２内で指定するか、対話型アプリケーションが保管されるファイルディレクトリへのパス名とすることができる。イベント種類によって、放送番組の種類が定義される。種類の数は、システム設計に依存し、単純にテレビジョン番組とコマーシャルの間の区別とするか、さらに、番組ガイド、クローズドキャプション、または他の種類の放送コンテンツを識別することができる。イベント種類は、以下で、イベントマネージャ５０４および表７に関してさらに説明する。

これらの信号およびそのデータ内容は、理想的なスケジューリングシステム１０６に関するものであり、実際のスケジューリングシステム１０６は、これらの信号の一部、指定されたデータの一部、またはその両方を使用することができる。しかし、トランスレータモジュール５０２およびイベントマネージャ５０４は、これらの制御信号からどのデータが欠けていてもそれを揃えるように動作し、これによって、放送サーバ１１０を管理する。

理想的な制御信号を与えられれば、「理想的な」トランスレータモジュール５０２を定義することができる。この理想的なトランスレータモジュール５０２は、スケジューリングシステム１０６からの制御信号が、イベントマネージャ５０４によって使用されるアトミックコマンドの組にマッピングされる。従って、この理想的なトランスレータは、放送番組のライフサイクルと、放送番組に関連する対話型アプリケーションの実行を制御するために放送サーバ１１０へのコマンドを生成するために放送番組のライフサイクルの異なる状態にイベントマネージャ５０４がどのように応答できるかが、表現される。

表２に、トランスレータモジュール５０２によって生成されるアトミックコマンドをリストする。

放送サーバ１１０が、対話型アプリケーションをスケジューリングするには時間がかかるので、いくつかの情況で、トランスレータモジュール５０２は、対話型アプリケーションを放送されつつあるビデオデータと同期化できるようにするのに十分に早期にスケジュールアトミックコマンドを送らない場合がある。この場合に、対話型アプリケーションを、他の手動プロセスまたは自動化プロセスによって放送サーバ１１０で事前スケジューリングすることができ、自動化サーバ１０８は、スケジューリングされる放送サーバ１１０に指示するのではなく、対話型アプリケーションの事前スケジューリングを探すことによって、時間を節約することができる。このモードでは、事前にスケジューリングされたイベントをもう一度放送することができるので、自動化サーバ１０８は、それらのイベントを取り消すことはない。その代わりに、それらのイベントをスケジューリングしたプロセスが、それらを取り消す責任を負う。

特定のスケジューリングシステム１０６の実際のトランスレータモジュール５０２は、理想的なトランスレータモジュール５０２から導出される。図８を参照すると、理想的なトランスレータのステートマシン５１０のステートマシンの説明が示されている。各放送番組は、制御信号によって定義される複数の状態の間で遷移すると理解することができる。

ステートマシンは、開始状態（８００）で開始される。

この状態から、トランスレータモジュール５０２は、ロード済み状態（８０２）に遷移する。ロード済み状態（８０２）は、３つの異なる理想的な信号（８０１）すなわちプリロード信号、プリロール信号、または開始信号のいずれかから達することができる。

通常、トランスレータモジュール５０２によって受け取られる最初の制御信号（８０１）は、プリロード信号である。スケジューリングシステム１０６は、この信号によって、放送番組が放送されようとしていることを示す。ロード済み状態（８０２）には、プリロード信号が以前に受け取られていない場合に、注記したように、プリロール信号によっても達する。プリロール信号も、放送信号が放送されようとしていることを示す。

ロード済み状態（８０２）において、トランスレータモジュール５０２は、放送番組に関連する適当な対話型アプリケーションを判定し、その実行をスケジューリングする。トランスレータモジュール５０２は、この状態の理想的なデータにできる限り近い形で、放送番組ＩＤ、イベント種類、放送番組の関連する対話型アプリケーションの位置などを判定する。イベント種類は、テレビジョン番組、コマーシャル、または未知など、放送番組の種類を記述する。イベント種類は、以下でさらに説明する。いくつかの場合に、トランスレータモジュール５０２が特定のチャネルに関連するので、チャネル割り当てが暗黙指定である。他の場合には、チャネルを制御信号で明示的にエンコードすることができる。

具体的に言うと、トランスレータモジュール５０２は、現在時刻および受け取った信号をログに記録する。トランスレータモジュール５０２は、関連する対話型アプリケーションの番組ＩＤに、制御信号に含まれる番組ＩＤをセットする。必要な場合に、トランスレータモジュール５０２は、正規表現を使用してイベント種類を計算する（以下を参照）。そうでない場合に、トランスレータモジュール５０２は、イベント種類にＵｎｋｎｏｗｎをセットして、それを対話型アプリケーション自体に含まれるデータから判定することが、イベントマネージャ５０４に委ねられる。必要な場合に、トランスレータモジュール５０２は、対話型アプリケーションの位置に番組ＩＤをセットと、イベントマネージャ５０４は、適宜、放送番組の番組ＩＤおよびセグメント番号に基づいて、実際の位置を判定する。

次に、トランスレータモジュール５０２は、作成された理想的なデータを使用して、スケジュールコマンドを作成し、イベントマネージャ５０４に出力する。このスケジュールコマンドは、イベントマネージャ５０４に指示して、放送番組の番組ＩＤに関連する対話型アプリケーションがあるか否かを判定し、そうである場合には、識別された対話型アプリケーションの放送の準備をするように放送サーバに要求する。

次の状態は、準備済み状態（８０４）である。この状態には、ロード済み状態（８０２）から、プリロール信号または開始信号のいずれかの際に達する。プリロール信号または開始信号が最初に受け取られる信号（８０１）である場合の、準備済み状態（８０４）への自動遷移もある。すなわち、これらの信号のいずれかが、最初の信号（８０１）として受け取られる場合に、トランスレータモジュール５０２は、ロード済み状態（８０２）、準備済み状態（８０４）、およびオンエア状態（８０６）を介して自動的に遷移する。準備済み状態（８０４）は、イベントマネージャ５０４に送られるアトミックコマンドのタイミングを制御する。開始の前に、自動化サーバ１０８は、スケジューリングシステムイベントの放送の開始のどれほど前にプリロール信号を受け取ることができるかに関して構成される。これは、通常は、１秒から１０秒の間であり、通常は、ミリ秒単位で測定される。プリロール信号または開始信号を受け取る際に、理想的なトランスレータモジュールは、準備済み状態（８０４）に入る。準備済み状態（８０４）は、Ｘ−Ｙミリ秒だけ一時停止することが好ましく、ここでＸは、プリロール信号がどれほど早く来るかであり、Ｙは、イベントマネージャ５０４および放送サーバ１１０が放送番組の対話型アプリケーション（イベント）を開始するのに要する時間の長さである。その時間が経過した後に、トランスレータモジュール５０２が、オンエア状態（８０６）に自動的に遷移し、この状態でイベントが開始される。この状態では、他のイベントステートマシンによって使用することができる開始信号（８０５）が生成される（以下のオフエア状態の節を参照）。Ｘ−Ｙが０未満であるか、制御信号が開始信号である場合には、準備済み状態（８０４）で全く待たないことに留意されたい。そうではなく、単にオンエア状態（８０６）に推移して、放送サーバイベントをできる限り早く開始できるようにする。

「オンエア」状態（８０６）は、準備済み状態（８０４）の後に自動的に発生する。この状態では、トランスレータモジュール５０２は、開始アトミックコマンドを作成と、イベントマネージャ５０４に送る。準備済み状態（８０４）で導入される一時停止と組み合わされる時に、これは、対話型アプリケーションの開始が、放送番組と共に実行を開始されるという効果を有する。

オンエア状態（８０６）中に、副トリガ（８０９）を形成する追加の信号を受け取り、処理することができる（８１０）。この副トリガによって、放送されている対話型アプリケーションに関連する追加の機能性の実行をもたらすことができる。

イベント停止信号（８０７）によって、放送が終了し、「オフエア」状態（８０８）がもたらされる。この状態では、イベントが取り消される。すなわち、トランスレータモジュール５０２は、現在の番組ＩＤに基づいて取消コマンドを作成と、このコマンドが、イベントマネージャ５０４に送られて、現在の対話型アプリケーションが取り消される。この状態は、他のイベントに関連する制御信号によってトリガすることができる。例えば、スケジューリングシステムのネイティブ制御信号に、イベント停止信号が含まれない場合に、次のイベントのイベント開始信号によって、前のイベントの停止が引き起こされる。

エラー信号の際に、トランスレータモジュール５０２は、現在の番組ＩＤに基づいて取消コマンドを作成し、このコマンドがイベントマネージャ５０４に送られて、現在の対話型アプリケーションが取り消される。

従って、これらの状態によって、スケジューリングシステム１０６の観点からの、各放送番組のライフサイクルが表現される。この情報から、自動化サーバ１０８は、放送番組に関連する対話型アプリケーションの状態を判定と、その状態に関する放送サーバ１１０への適当なコマンドを生成する。

従って、トランスレータモジュール５０２は、これらの状態に対応して、特定のチャネルの放送番組を管理するように設計されている。具体的に言うと、トランスレータモジュール５０２は、それが受け取る放送番組ＩＤごとにステートマシン５１０を維持する。このステートマシンは、新しい放送番組ＩＤが受け取られるたびに作成され、放送番組が終了したことがスケジューリングシステム１０６によって示されるまで、維持される。

図９を参照すると、トランスレータモジュール５０２の動作全体、具体的にはそのマッピングロジック５０６の流れ図が示されている。トランスレータモジュール５０２は、スケジューリングシステム１０６から制御信号を受け取る（９００）たびに、制御信号が、トランスレータモジュール５０２によって管理されるイベントに関連するか否かを判定する（９０２）。イベントは、起動、シャットダウン、エラー、またはシステムメッセージなどのエラー信号および他のデータと反対の、番組ＩＤまたは放送番組を示す他のデータによって示される。

制御信号が、イベントに関するものでない場合には、トランスレータモジュール５０２によって、それがエラー信号であるか否かが判定される（９０４）。エラー信号は、処理のためにイベントマネージャモジュール５０４に渡される（９０６）。

制御信号がエラー信号でない場合には、無視する（９１０）。

信号がイベント信号である場合には、トランスレータモジュール５０２は、マッピングロジック５０６を適用して、ステートマシンへのキーとしてイベントの番組ＩＤを使用して、識別されたイベントが、新規イベントまたはステートマシン５１０が既に存在するイベントのどちらであるかを判定する。イベントが新規イベントである場合には、トランスレータモジュール５０２は、番組ＩＤおよびイベントに関する新しいステートマシン５１０をインスタンス化し（９１２）、ステートマシン５１０を起動する（９１４）。

既存のステートマシンがある場合には、イベント制御信号が、番組ＩＤに関連するステートマシン５１０に渡される（９１６）。次に、理想的なステートマシンに関して説明したように、さらに特定のトランスレータ種類に関して以下で詳細に示すように、ステートマシン５１０は、その状態論理に従って、イベントを処理する。

（５．トランスレータの種類）
各スケジューリングシステム１０６は、トランスレータモジュール５０２によって解釈される、それ自体の特定の組の制御信号を生成する。以下の節では、理想的なトランスレータモジュールの状態図に関して、特定のトランスレータモジュールをどのように実施するかを説明する。すなわち、スケジューリングシステム固有の制御信号を、理想的なトランスレータの包括的な制御信号にマッピングすることができる。各特定のトランスレータモジュール５０２は、理想的なトランスレータモジュールで説明したものと同一の状態を推移する。しかし、各特定のトランスレータの状態アクションは、受け取る制御信号の相違を考慮に入れるために、わずかに異なる。

理想的なトランスレータのステートマシンから各種類のトランスレータの特定のステートマシンへのマッピングを、以下の表４から６に要約する。これらの表の列の見出しは、表３で定義されたものである。

ａ）トランスレータ種別１：基本的なスケジューリングシステム
基本的なスケジューリングシステム１０６は、制御信号に非常にわずかなデータ、典型的には番組ＩＤだけがエンコードされるスケジューリングシステムである。トランスレータのステートマシンを介するこの制御信号の解釈には、理想的な制御信号の理想的なデータであったはずのものを再作成するのに適当なデータの作成および推論が含まれる。基本的なスケジューリングシステム１０６の例が、Louth ADC-100である。

一実施形態では、自動化サーバ１０８は、サブタイトラをエミュレートすることによって、基本的なスケジューリングシステムとインタフェースする。Louthスケジューリングシステムなどの一実施形態では、エミュレートされるサブタイトラは、Cavena Subtitlerである。通常、基本的なスケジューリングシステム１０６は、放送番組のビデオ番組データの上に表示されるサブタイトルを準備し、サブタイトルを開始し、サブタイトルを停止する信号が、サブタイトラに送られる。本発明では、自動化サーバ１０８は、これらの信号を使用して、対話型アプリケーションをビデオと同期化させる。

いくつかの基本的なスケジューリングシステム１０６は、プリロール情報を提供する能力を有することが好ましい。この場合に、基本的なスケジューリングシステム１０６は、放送番組の実際の開始に先立つ構成可能な秒数の時に、準備信号を送る。自動化サーバ１０８は、この情報を使用して、対話型アプリケーションをより早期にプリロードし、開始して、放送番組が開始されるまさにその時にユーザに達することができるようにする。従って、種別１のトランスレータは、準備信号を受け取る時に、ロード済み状態（８０２）、準備済み状態（８０４）、およびオンエア状態（８０６）を介して推移する。これは、表４で、自動推移として記載されている。

自動化サーバ１０８が、基本的なスケジューリングシステム１０６から開始信号（８０５）を受け取る時に、自動化サーバ１０８は、対話型アプリケーションが、準備信号を使用して既に開始されていることを知り、従って、開始信号を無視する。基本的なスケジューリングシステムの制御信号にエラーがある場合には、自動化サーバ１０８は、現在の対話型アプリケーションを停止し、自動化サーバ１０８は、エラー状態（８１２）に移動する。

表４に、基本的なスケジューリングシステム１０６のネイティブ制御信号、理想的な制御信号、および理想的なトランスレータモジュール５０２のステートマシンの状態遷移の間の関係を要約する。

ｂ）トランスレータ種別２：コードベースのスケジューリングシステム
スケジューリングシステム１０６の第２の種別は、識別コードを使用して、テレビジョン番組とコマーシャルを選択的に区別するスケジューリングシステムである。この種類のスケジューリングシステム１０６の例が、ESPN Inc.社によって同社の放送システムで使用されているものなどのＩＳＣＩコードベースのシステムである。この種類のシステムでは、ＩＳＣＩコードが、コマーシャルなどの放送番組内に存在し、テレビジョン番組には存在しない。この種類のコードを、スケジューリングシステム１０６によって直接に、または放送番組と共に媒体（例えばビデオテープ）に事前に記録することによって間接的に、提供することができる。

他の種類のコードベースのシステムは、対話型アプリケーションを個別に識別するコード、ＵＲＬ、ＵＲＩ、および類似物を使用するシステムを含む。

自動化サーバ１０８は、ＶＩＴＣタイムコードリーダまたは類似するタイムコードリーダを介してスケジューリングシステム１０６とインタフェースする。コードベースのスケジューリングシステムは、コマーシャル中にＶＩＴＣタイムコードを介してＩＳＣＩ情報を送り、番組中にはＩＳＣＩ情報を送らない。自動化サーバ１０８は、この情報を使用して、コマーシャルおよび番組中に対話型アプリケーションを選択的に追加する。スケジューリングシステムの制御信号は、番組ＩＤによって番組を指定しないので、デフォルト対話型アプリケーションだけがサポートされる。

一般に、制御信号に、ＩＳＣＩコードまたは類似するコードの存在が含まれる時に、トランスレータ５０２は、コマーシャルが開始されたことを知る。従って、ステートマシン５１０は、ロード済み状態、準備済み状態、およびオンエア状態を遷移し、対話型アプリケーションが開始される。これらの遷移は、表５で自動遷移として示されているように、自動的に行われる。ロード済み状態で、ＩＳＣＩコード（または、ＵＲＬ、アプリケーション識別子、および類似物などの他のコード）が、理想的なデータの番組ＩＤとして使用される（例えば番組ＩＤとしてコードを保存することによって）。これによって、イベントマネージャ５０４によって、適当な対話型アプリケーションを判定できるようになる。

ＩＳＣＩコードの変化の際に、トランスレータ５０２は、新しいコマーシャルが開始されたことを知る。従って、ステートマシン５１０は、オフエア状態に推移し、対話型コンテンツを停止し、取消アトミックコマンドを作成して、コマーシャルに関する現在の対話型アプリケーションを取り消す。トランスレータ５０２は、新しいＩＳＣＩコードに関する新しいステートマシン５１０を作成し、そのステートマシン５１０は、ロード済み状態、準備済み状態、およびオンエア状態を推移し、開始アトミックコマンドが生成されて、新しいコマーシャルの対話型アプリケーションが開始される。

制御信号にＩＳＣＩコードが含まれない時には、トランスレータ５０２は、テレビジョン番組が開始された（または進行中である）ことを知る。従って、ステートマシン５１０は、オフエア状態に遷移し、対話型コンテンツを停止し、取消アトミックコマンドを作成して、コマーシャルの現在の対話型アプリケーションを取り消す。同一の信号（すなわち、ＩＳＣＩコードの不在）に基づいて、未知の番組ＩＤの、番組イベント種類を有する新しいステートマシン５１０が作成される。以下で説明するように、イベントマネージャは、この番組ＩＤをデフォルト番組に関連付けなければならないことを判定する。ステートマシン５１０は、ロード済み状態、準備済み状態、およびオンエア状態を通り、開始アトミックコマンドを生成して、テレビジョン番組のデフォルトアプリケーションを開始する。ＩＳＣＩコードがもう一度検出された時には、ステートマシン５１０が、オフエア状態に進み、取消アトミックコマンドが生成される。

しばしば、コードベースのシステムにデータなしの小さいギャップがある（特に、コードの間の遷移中に）ので、トランスレータ５０２は、ＩＳＣＩコードの不在を検出する前に、構成可能なミリ秒だけ待つ。これによって、誤検出を回避する。

制御信号にエラーがある場合には、ステートマシン５１０は、現在の対話型コンテンツを取り消し、エラー状態に移る。

表５に、コードベースのスケジューリングシステム１０６のネイティブ制御信号、理想的な制御信号、および、コマーシャルイベントおよびデフォルト番組イベントの両方の理想的なトランスレータモジュール５０２のステートマシンの状態遷移の間の関係を示す。

ｃ）トランスレータ種別３：プレイリストベースのスケジューリングシステム
本発明によってサポートされる第３の種別のスケジューリングシステム１０６は、プレイリストベースのスケジューリングシステムである。この種類のシステムでは、制御信号は、放送される番組およびその持続時間を識別して、プレイリストの要素を提供し、含まれるいくつかのインスタンスは、放送番組の番組タイトルである。この種類のスケジューリングシステムの例は、Sony Corporation社が提供する、BZCA-1102 Spot Reel Optionソフトウェアが動作するLibrary Management System（ＬＭＳ）BZCA-1100マルチカセットシステムである。

自動化サーバ１０８は、制御端末として機能することによって、この種類のスケジューリングシステム１０６とインタフェースする。制御端末は、送信プレイリストを表示し、この送信プレイリストは、スケジューリングされたイベントのテーブルである。LMS BAC-1200制御端末は、１つの例である。プレイリストは、各放送番組の番組ＩＤ、番組タイトル、持続時間などのイベント情報を含む。

プレイリストベースのトランスレータモジュール５０２は、スケジューリングシステム１０６から受け取られるすべてのイベント情報を取り込み、解析する。イベントは、放送時刻の前に、送信プレイリストに現れる。イベント（例えば放送番組）が、送信プレイリストに現れる時に、トランスレータ５０２は、そのイベントの対話型アプリケーションをプリロードし、ロード済み状態（８０２）に遷移する。スケジューリングシステム１０６は、オンエアされるイベントから構成可能な秒数だけ前に、再生制御信号のイベント状況を送ることによって、各イベントのプリロール情報を供給する。

トランスレータ５０２は、準備済み状態（８０４）およびオンエア状態（８０６）に推移して、イベントの再生制御信号が受け取られる時に、対話型アプリケーションが開始される。トランスレータ５０２が、ネットワークまたは他の問題に起因してイベントの再生制御信号をとり逃し、イベントのオンエア制御信号またはオンライン制御信号を受け取る場合に、トランスレータ５０２は、オンエア状態（８０６）に推移し、対話型アプリケーションを開始する。この場合には、自動化サーバ１０８が、プリロール情報の利益をとり逃すが、対話型アプリケーションは、それでも開始される。

トランスレータモジュール５０２が、オンエア信号またはオンライン信号を受け取り、準備済み状態（８０４）でない場合には、オンエア／オンライン信号が、再生信号として扱われ、まず準備済み状態（８０４）に推移し、その後、自動的にオンエア状態（８０６）に推移する。

イベントデータが、送信プレイリストから消滅する時に、トランスレータモジュール５０２は、オフエア状態（８０８）に推移し、イベントマネージャ５０４に、現在の対話型アプリケーションを取り消すように指示する。

スケジューリングシステムへの接続を失うなどのなんらかの種類のエラーが発生する場合には、自動化サーバ１０８は、現在の対話型アプリケーションを停止し、エラー状態に移る。

表６に、プレイリストベースのスケジューリングシステム１０６のネイティブ制御信号と、理想的な制御信号と、理想的なトランスレータモジュール５０２のステートマシンの状態遷移の間の関係を要約する。

（６．正規表現に基づくトランスレータイベント種類計算）
番組ＩＤのイベント種類を追跡するスケジューリングシステム１０６は、その情報を自動化サーバ１０８に直接に送ることができる。多数のスケジューリングシステム１０６が、この特徴をサポートしないので、一部の放送会社１１４は、番組とコマーシャルなど、異なる種類の番組を区別する番組ＩＤを使用する。自動化サーバ１０８は、利益を得るためにこの情報を使用する。トランスレータ５０２は、どの種類のイベントをスケジューリングするかを判定するのにこの情報を使用する。例えば、コマーシャルの番組ＩＤは、「ＶＴ」というプレフィックスを有することができ、テレビジョン番組の番組ＩＤが、異なるプレフィックスを有するか、プレフィックスを全く有しないものとすることができる。自動化サーバ１０８は、番組ＩＤと共に正規表現を使用して、コマーシャルと番組を区別する。正規表現分析に基づいて、イベント種類は、番組ＩＤがコマーシャルの判断基準に一致する場合にコマーシャルがセットされ、番組ＩＤが番組の判断基準と一致する場合に、番組がセットされる。放送会社１１４が、番組とコマーシャルを区別するように番組ＩＤに名前を付けていない場合には、イベント種類にＵｎｋｎｏｗｎがセットされる。その場合に、イベントマネージャ５０４は、実際の対話型アプリケーションファイルをフラグについて調べて、内容がコマーシャル用と番組用のどちらであるかを知る。

（７．イベントマネージャの概要）
図５を参照すると、イベントマネージャ５０４は、さまざまなアトミックコマンド５１４をトランスレータモジュールのステートマシン５１０から受け取り、それに応答して、放送サーバ１１０に、対話型アプリケーションの制御に関して指示する。

一般に、自動化サーバ１０８がない普通のシステムでは、放送サーバ１１０は、放送サーバイベントのリストである事前定義のプレイリストに従って、データ挿入ユニット１１６に対話型アプリケーションを送る。

しかし、自動化サーバ１０８は、スケジューリングシステム１０６によって提供される制御信号を介して、放送サーバのプレイリストの作成を自動化し、スケジューリングシステムのプレイリストに対するほぼリアルタイムの変更に合わせて、放送サーバのプレイリストにイベントを動的に追加し、除去し、修正することができる。放送サーバのプレイリストは、すべてのチャネルのイベントを含むことができるが、イベントマネージャ５０４は、それがアトミックコマンドを受け取るチャネルのイベントだけを管理する。

図５に、トランスレータモジュール５０２が、イベントマネージャ５０４にアトミックコマンド５１４をどのように送るかを示す。イベントマネージャ５０４は、アトミックコマンド５１４を解釈して、放送サーバ１１０へのプリミティブコマンドのストリームを生成する。イベントマネージャ５０４が、アトミックコマンド５１４を受け取る時に、それに含まれる番組ＩＤを、マッピングロジック５０８を介して特定の放送サーバにマッピングする。適当な放送サーバイベントが、特定の番組ＩＤに関して存在しない場合には、イベントマネージャ５０４は、放送サーバイベントを作成する。一般に、イベントマネージャ５０２は、必要に応じて放送サーバイベントを作成し、修正し、破棄する。

イベントマネージャ５０４は、それが管理する放送サーバイベントごとに、別々のステートマシン５１２を維持する。各ステートマシンに、イベントの番組ＩＤによってイベントが割り当てられる。トランスレータモジュール５０２からのアトミックコマンドは、その番組ＩＤに基づいて、これらのステートマシンにルーティングされる。この処理を、以下のアトミックコマンドマッピングロジックの節で説明する。イベントステートマシン５１２は、正しい放送サーバプリミティブコマンドを生成する責任を負う。これは、以下のイベントステートマシンの節で詳細に説明する。

トランスレータモジュール５０２およびイベントマネージャ５０４の２つのステートマシンを使用することによって、さまざまな異なる種類のスケジューリングシステム１０６のどれでも、自動化サーバ１０８に簡単にインタフェースできるようになるのと同時に、比較的単純で効率的なイベントマネージャ５０４の実施形態が可能になる。これによって、イベントマネージャ５０４の変更を必要とせずに、新しいスケジューリングシステム１０６と共に動作するように新しいトランスレータモジュール５０２を作成できるようになる。

異なるイベント種類によって、アトミックコマンドマッピングロジック５０８とイベントステートマシン５１２が異なる形で振る舞うようになる可能性があるので、以下の節で、イベントマネージャ５０４がサポートする様々なイベント種別を定義する。

ａ）イベント種別
イベント種別は、放送サーバイベントがどのように振る舞わなければならないかを決定する。イベント挙動を定義する、３つの異なるカテゴリがある。
・番組種別
・セグメント化
・対話性

番組種別は、コマーシャル、番組、または未知とすることができる。コマーシャルは、通常は短い（３０秒から１２０秒）、テレビジョン番組の自己完結型の部分である。番組は、１または複数のセグメントを含むテレビジョン番組である。通常は、１または複数のコマーシャルが、テレビジョン番組セグメントの間に再生される。自動化サーバ１０８にが、スケジューリングシステム１０６によって送られた制御信号から番組種別を判定できない場合には、種別に未知がセットされる。通常、未知イベントは、コマーシャルなどの自己完結型の番組として扱うか、テレビジョン番組のように扱うことができる。

番組種別およびセグメント化は、密接に関連する。好ましい実施形態では、テレビジョン番組が、必ずセグメント化されたものとして扱われ、コマーシャルが、必ずセグメント化されないものとして扱われる。未知番組は、この一方または他方として扱うことができる。セグメント化されたテレビジョン番組の処理は、以下で図１２に関して詳細に説明する。

対話性（例えば、対話型アプリケーション）は、通常対話型イベントまたはデフォルト対話型イベントのいずれかとすることができる。通常イベントは、特定の対話型アプリケーションを関連付けられるイベントである。イベントマネージャ５０４が、対話型アプリケーションデータベース１１２内でイベントに関連する特定の対話型アプリケーションを見つけることができない場合には、そのイベントの持続時間の間、デフォルト対話型イベントに置換することができる。ヌルイベントを、デフォルトイベントとして指定することもでき、これは、イベントの持続時間の間に対話型アプリケーションが放送されないことを意味する。

下の表に、６つのイベント種別を列挙し、各イベント種別の挙動を要約する。

イベント種別は、放送サーバイベント設定を判定するのにも使用される。

ｂ）イベント種別の判定
イベント種別は、最初に、トランスレータモジュール５０２によって判定され、アトミックコマンド５１４でイベントマネージャ５０４に渡される。いくつかの場合に、トランスレータモジュール５０２が、実際のイベント種類を判定するのに十分な情報を有しない。トランスレータモジュール５０２は、イベント種別の初期判定を行うが、イベントマネージャ５０４は、よりよい情報を有する場合に、イベント種別を変更することができる。イベントマネージャ５０４は、トランスレータモジュール５０２が有しない２つの情報を有する。
１．イベントマネージャ５０４は、イベントの番組ＩＤについて対話型アプリケーションが存在するか否かを知っている。
２．イベントマネージャ５０４は、対話型アプリケーションからイベント種別情報を得ることができる。アプリケーションは、それが中断されたか否かを判定する情報を含む。自動化サーバ１０８は、すべてのテレビジョン番組が中断可能であり、すべてのコマーシャルが中断可能でないと仮定される。

イベントマネージャの情報とトランスレータモジュールの情報を組み合わせて、イベントマネージャ５０４は、下記の表に要約された正しいイベント種べつを判定することができる。

ｃ）アトミックコマンドマッピングロジック
イベントマネージャ５０４は、それが管理するイベントごとに別々のステートマシン５１２を維持する。イベントマネージャ５０４は、トランスレータモジュール５０２からアトミックコマンド５１４を受け取る時に、そのアトミックコマンドの番組ＩＤを、適当な放送サーバイベントに関連付けなければならず、そのアトミックコマンドを、適当なステートマシン５１２に渡さなければならない。この処理は、イベントマネージャのマッピングロジック５０８によって処理される。

マッピングロジック５０８は、イベント関連テーブルを作成し、維持し、このイベント関連テーブルによって、番組ＩＤが放送サーバイベントＩＤに関連付ける。スケジューリングされたアトミックコマンドだけが、新しい放送サーバイベントの作成を引き起こすことができる。その結果、これらのアトミックコマンドのみによって、新しい行を、番組ＩＤを新しい放送サーバのイベントＩＤに関連付けるイベント関連テーブルに追加することができる。関連は、イベントによってステートマシン５１２がトラバースされ、ステートマシンが破棄される時に、テーブルから除去される。

図１０に、マッピングロジック５０８の一実施形態の状態挙動を示す。表９で、この図を説明する。

新規のイベントステートマシンが作成される時に、マッピングロジック５０８は、上記の表８のルールに従って、イベント種別を判定する。

通常のセグメント化されない対話型イベントについて、スケジューリングシステムイベントと放送サーバイベントの間に、イベント関連テーブル内で１対１マッピングが存在する。２つの特筆すべき例外を、次に説明する。

ｄ）特別な事例のイベントマッピング
一般に、スケジューリングシステムイベントと、放送サーバイベントの間に、１対１マッピングがある。２つの特筆すべき例外を、ここで説明する。

（ｉ）デフォルトイベント
起動時に、イベントマネージャ５０４は、３つの放送サーバイベント（デフォルトイベント種類ごとに１つ）を作成する。これは、イベント関連テーブルの最初の３つのイベントである。イベント種別に関して上述したように、デフォルトイベントは、特定の番組ＩＤについて対話型アプリケーションを見つけることができない時に選択される。これをサポートするために、イベント関連テーブルを用いて、多数の番組ＩＤを、同一のデフォルトイベントＩＤにマッピングできるようにする。マッピングロジック５０８が、関連する対話型アプリケーションがないスケジュールアトミックコマンドを受け取る時に、マッピングロジック５０８は、その番組ＩＤをスケジュールアトミックコマンドで指定されるイベント種別に対応するデフォルトイベントに関連付ける。デフォルトイベントは、既にスケジューリングされているので、マッピングロジック５０８は、スケジュールアトミックコマンドを渡さない。

（ｉｉ）セグメント化されたイベント
注記したように、単一のテレビジョン番組を、複数の部分にセグメント化することができる。スケジューリングシステム１０６にとって、番組は、それぞれがそれ自体の番組ＩＤを有する、一連の複数のイベントである。放送サーバにとって、テレビジョン番組は、セグメントごとに中断され、再開される単一のイベントである。その結果、イベント関連テーブルを用いて、複数の番組ＩＤを単一の放送サーバイベントにマッチングすることによって、この間隙がふさがれる。

スケジューリングシステム１０６が、その番組ＩＤ内のセグメント化に関する情報を提供する場合に、マッピングロジック５０８は、テレビジョン番組の最初のセグメントの新しいイベントステートマシン５１２を作成し、他のすべてのセグメントを同一のイベントステートマシン５１２に自動的にマッピングする。

残念ながら、ほとんどのスケジューリングシステムは、この情報を提供しない。従って、自動化サーバ１０８は、２つの異なる番組ＩＤが対話型アプリケーションデータベース１１２内で同一の対話型アプリケーションにマッピングされるか否かを判定することにより、両方の番組ＩＤが同一のテレビジョン番組に関連するか否かを判定する。マッピングロジック５０８が、新しい番組ＩＤが既にイベント関連テーブルにリストされているテレビジョン番組の他のセグメントに関連すると判定する場合に、マッピングロジック５０８は、
１．新しい番組ＩＤが、イベント関連テーブル内で事前に存在する放送サーバイベントに関連付けられ、
２．番組が既にスケジューリングされているので、スケジュールアトミックコマンドは渡されない。

これを、以下のイベントステートマシンおよびセグメント化の節で詳細に説明する。

ｅ）放送サーバのプリミティブコマンド
イベントマネージャのステートマシンは、４つの放送サーバプリミティブコマンドすなわち、スケジュール、開始、停止、および取消を発して、放送サーバを制御する。これらのコマンドは、同一の名前のアトミックコマンドに類似する。スケジュールは、対話型アプリケーションを放送のために準備し、放送サーバのプレイリストに追加する。開始は、対話型アプリケーションの放送を開始し、停止によってその放送を終わる。取消は、対話型アプリケーションを（まだ停止していない場合に）停止し、対話型アプリケーションをメモリから除去し、関連するイベントを放送サーバのプレイリストから削除する。

代替実施形態では、これらの特定のコマンドを拡張して、無期限の中断、選択された時間間隔の間の中断、即座の再開、選択された時間間隔の後の再開など、他のより複雑な挙動を含めることができる。

さらに、コマンドの内容すなわち、コマンドによって管理できる対話性の種類は、やはりシステム設計者によって決定される対話性の種類に応じて、可変である。従って、コマンドによって、以前に放送された対話性、フォーム、または他のデータ、ＵＲＬ、ウェブページ、Ｊａｖａ（登録商標）アプレット、または他のハイパーメディア対話性および類似物をスケジューリングするか、トリガを開始することができる。

（８．イベントステートマシン）
アトミックコマンドの寿命は、特定のイベントステートマシン５１２で終わる。各イベントステートマシン５１２は、放送サーバイベントに関連し、そのイベントでのすべての動作を制御する。アトミックコマンドマッピングロジック５０８は、どのステートマシン５１２によって特定のアトミックコマンドを受け取るかを決定する（以下に少数の例外がある）。

図１１に、イベントステートマシン５１２の挙動を、コマーシャルイベント種別、テレビジョン番組イベント種別、およびデフォルトイベント種別の詳細と共に示す。イベントステートマシンは、イベントのライフサイクルを追跡する。図１１では、状態遷移にラベルを付けて、下記のように、どの種類のイベントにそれらが適用されるかを示す。
Ｃ：コマーシャルイベントに適用可能な遷移。
Ｓ：テレビジョン番組イベントに適用可能な遷移。
Ｄ：デフォルトイベントに適用可能な遷移。

一般に、イベントは、下記の状態を通る。
スケジューリング済み（１１０２）：トランスレータモジュール５０２からのスケジュールアトミックコマンドによって、イベントが放送サーバでスケジューリングされる。ステートマシン５１２は、放送スケジュールプリミティブを発行し、これによって、放送サーバ１１０が、放送のために対話型アプリケーションを準備し、放送サーバのプレイリストに追加するように指示する。スケジューリングの後に、イベントを、開始アトミックコマンドによって開始する必要がある。

開始済み（１１０４）、停止（１１０６）：トランスレータモジュール５０２からの開始コマンドによって、ステートマシンが開始済み状態（１１０４）に遷移する。ステートマシンは、放送開始プリミティブを発行する。開始の後に、イベントは、開始アトミックコマンドおよび停止アトミックコマンドによって、何回でも開始および停止を行うことができる。ステートマシンは、テレビジョン番組イベントおよびデフォルトイベントに限って停止（１１０６）に推移し、コマーシャルイベントでは停止（１１０６）状態に達することがない。

放送開始プリミティブに応答して、放送サーバ１１０は、前に送信されていない場合に対話型アプリケーションを送信すること、またはアプリケーションが前に送信されている場合に実行を開始するために対話型アプリケーションにトリガを送信することを含む、さまざまな形で対話型アプリケーションを開始することができる。同様に、放送サーバ１１０は、フォームまたはコンテンツなどの他の種類のデータを対話型アプリケーションに送信するか、上述したようにＵＲＬまたは類似物を送信することができる。

副トリガ処理（１１０８）：開始された後に、イベントによって、０個以上の副トリガを引き起こすことができる。副トリガとは、イベントがアクティブである（すなわち、放送サーバでスケジューリングされている）間に発生するアクションである。その例が、イベント終了５分前のエンドユーザへの警告である。これらのトリガは、スケジューリングシステム１０６によって作成され、制御信号としてトランスレータモジュールに渡される。

取消済み（１１１０）：最後に、イベントに関連する放送番組が終了したならば、取消アトミックコマンドが、トランスレータモジュール５０２から送られる。ステートマシンは、放送サーバ１１０に放送取消プリミティブを発行することによって応答し、これによって、イベントが取り消される。この状態には、異なるイベントについて異なる形で到達される。コマーシャルイベントの場合には、取消アトミックコマンドがトランスレータモジュール５０２から受け取られる時にこの状態に到達し、テレビジョン番組イベントの場合には、次テレビジョン状態コマンドが受け取られる時にこの状態に到達し、最後に、デフォルトイベントの場合には、シャットダウン時にこの状態に到達する。

放送サーバイベント（対話型アプリケーション）の開始を、それに関連するスケジューリングシステム放送番組と正確に同期化するために、一部のスケジューリングシステムは、プリロールをサポートする。プリロールは、スケジューリングシステム１０６が制御する（ＶＴＲなど）装置が動作（番組の再生の開始など）を完了するのに必要とする時間の長さである。スケジューリングシステム１０６は、同一の種類のプリロール警告を自動化サーバ１０８に与えて、対話型アプリケーションを開始する時間を与えることができる。一部のスケジューリングシステムでは、１つのプリロール値だけがサポートされる。自動化サーバ１０８の応答時間が、プリロール値より高速である場合に、自動化サーバ１０８は、放送サーバイベントを開始する際にある追加の遅延を導入する。この微調整されるタイミングは、システム設計者によって、イベントステートマシンで行われる。開始済み状態、停止状態、および取消済み状態のすべてで、放送サーバイベントを実際に開始し、停止し、あるいは取り消す前に、ある量の遅延を導入することができる。

すべての放送サーバイベントは、この同一の基本的なステートマシンを共有するが、イベントステートマシンは、イベント種別ごとに異なる。これらの相違の詳細を、以下で説明する。

副トリガは、すべてのイベント種別について同一の形で処理される。副トリガは、自動化サーバ１０８を拡張する形式である。一部のスケジューリングシステム１０６は、基本的な制御信号（プリロード、プリロール、オンエア、およびオフエア）以上の信号をサポートする。これらのスケジューリングシステムは、例えば、番組終了の５分前に制御信号を送って、番組が終わろうとしていることを装置に警告することができる。自動化サーバは、この信号を使用して、現在の対話型アプリケーションを更新して、それが終わろうとしていることを視聴者に警告することができる。これは、副トリガを使用できる形の１つの例にすぎない。

ａ）コマーシャルイベント種類
これは、最も単純なイベントステートマシンである。コマーシャルイベントは、絶対に停止も再開始もされず、従って、単に、スケジューリング済みから開始済み（潜在的にはいくつかの副トリガを有する）に進み、最後に取消済みに進む。次の表に、状態、その状態に入らせるアトミックコマンド、およびその状態によって実行されるアクションを要約する。

ｂ）番組イベント種別
番組イベント種類ステートマシン５１２は、コマーシャルイベント種別ステートマシンに非常に似ているが、セグメント化（イベント種類の節で説明した）も考慮に入れなければならない。

コマーシャルイベントと異なって、取消コマンドは、番組が停止するだけである。何故ならば、番組を将来に再開する必要がある場合があるからである。次の番組の開始アトミックコマンドが受け取られる時に限って、この番組が取り消される。次の表に、状態、その状態に入らせるアトミックコマンド、およびその状態によって実行されるアクションを要約する。

ｃ）デフォルトイベント種別
デフォルトイベントは、デフォルト番組イベント、デフォルトコマーシャルイベント、およびデフォルト未知イベントという３つの異なる種類がある。デフォルトイベントは、番組ＩＤに関連する対話型アプリケーションがない時に使用される。

コマーシャルイベントとは異なって、取消コマンドだけによって、デフォルトイベントが停止する。何故ならば、将来に再開始する必要がある場合があるからである。デフォルトイベントは、自動化サーバ１０８がシャットダウンされる時に限って取り消される。通常のイベントとデフォルトイベントの主要な相違は、２つの順次番組ＩＤによって同一のデフォルトイベントが参照される場合があることである。この場合には、デフォルトイベントを停止し、即座に再開始しないことが好ましい。そうではなく、デフォルトイベントは、再生の継続を許可される。これが機能するためには、次の開始アトミックコマンドがこのデフォルトイベントにも関するものでないことが確実になるまで、「停止」状態では実際に停止しない。デフォルトイベント種類に無関係に、次の表に、状態、その状態に入らせるアトミックコマンド、およびその状態によって実行されるアクションを要約する。

（９．セグメント化）
図１２に、視聴者に一貫性のある経験を与え、テレビジョン番組の異なるセグメント中に適当な対話型アプリケーションを維持すると同時に、コマーシャル中に同様に適当な対話型アプリケーションを提供するために、テレビジョン番組のセグメント化がどのように扱われるかを示す。

図１２では、スケジューリングシステム１０６、（理想的な）トランスレータモジュール５０２、およびイベントマネージャ５０４からの、セグメント化されたテレビジョン番組を処理する時の、制御信号、アトミックコマンド、および放送サーバコマンドの流れのイベントトレースが示されている。テレビジョン番組Ｓｈｏｗ Ａが、それぞれが一意の番組ＩＤを有する２つのセグメントＡ．１およびＡ．２で放送される。セグメントの間に、コマーシャルＡｄ Ｘがある。セグメントＡ．２の後に、コマーシャルＡｄ Ｙと、それに続く次の番組Ｓｈｏｗ Ｂがある。ここで本発明によって解決される問題は、セグメントＡ．１およびＡ．２の両方の間に同一の対話性を維持する（これらのセグメントが一意の番組ＩＤを有する場合であっても）と同時に、Ａｄ ＸおよびＡｄ Ｙに付随する固有のまたはデフォルトの対話性が何であっても、それを提供するという問題である。この結果を達成するために、セグメントＡ．１およびＡ．２の両方の番組ＩＤを、イベントマネージャ５０４によって、イベント関連テーブルで同一の放送イベント（Ｓｈｏｗ Ａ）にマッピングしなければならない。これは、上述したさまざまな手順を使用して行うことができる。制御信号およびアトミックコマンドのシーケンスは、次の通りである。

番組セグメントＡ．１
１２００：最初に、スケジューリングシステム１０６は、Ａ．１プリロード信号を発行する。
１２０２：トランスレータモジュール５０２は、セグメントＡ．１をスケジューリングする。
１２０４：イベントマネージャ５０４は、このイベント（Ｓｈｏｗ Ａ）の新しいステートマシン５１２を作成し、この番組ＩＤおよびステートマシンのマッピングをイベント関連テーブルに保管する。Ｓｈｏｗ Ａステートマシンは、放送サーバ１１０にＳｈｏｗ Ａと共に放送するために適当な対話型アプリケーションをスケジューリングするように指示する。
１２０６：スケジューリングシステム１０６は、Ａ．１に関するプリロール信号または開始信号のいずれかを発行する。
１２０８：トランスレータモジュール５０２は、潜在的に、プリロール量によって決定される量の遅延と、イベントマネージャ５０４および放送サーバ１１０が放送サーバイベントを開始するのに要する時間の長さの後に、セグメントＡ．１を開始する。
１２１０：イベントマネージャのＳｈｏｗ Ａステートマシンは、それに対応して、Ｓｈｏｗ Ａの対話型アプリケーションを開始するように放送サーバに指示する。
１２１２：Ｓｈｏｗ Ａの対話型アプリケーションが、放送受信器１２０によって実行され、放送受信器１２０に結合された、テレビジョンセッとなどの表示装置に表示される。
スケジューリングシステム１０６によってプリロールが最初に発行される場合には、番組Ａ．１が既に開始されているので、トランスレータモジュール５０２は、スケジューリングシステム１０６からのその後の開始信号を無視する。

Ａｄ Ｘ
１２１４：少し後に、スケジューリングシステム１０６は、Ａｄ Ｘのプリロード信号を発行する。
１２１６：トランスレータモジュール５０２は、Ａｄ Ｘスケジュールアトミックコマンドを発行する。
１２１８：イベントマネージャは、放送サーバ１１０にスケジュールコマンドを発行し、Ａｄ Ｘの対話型アプリケーション（デフォルトを含む）をスケジューリングする。
１２２０：スケジューリングシステム１０６は、プリロール信号またはＡｄ開始信号を発行する。
１２２２、１２２４：トランスレータモジュール５０２は、Ｓｈｏｗ Ａに別のセグメントがあることを知らないので、セグメントＡ．１に関する取消コマンドを送信し、Ａｄ Ｘ開始コマンドを送信する（スケジューリングシステム１０６によってＡ．１停止が送られる場合には、このコマンドは、Ａｄ Ｘのプリロードおよびプリロールの後に到着し、そのために無視される）。
１２２６、１２２８：通常は、イベントマネージャ５０４が、セグメントＡ．１を取り消すことによって応答する。しかし、イベントマネージャ５０４は、一時的に取消コマンドを無視し、その代わりに、Ａ．１停止コマンドを送って、Ｓｈｏｗ Ａの対話型アプリケーションを停止し、その後、Ａｄ Ｘ開始コマンドを送り、これによって、Ａｄ Ｘの対話型アプリケーションの実行が開始される。
１２３０、１２３２：これらのコマンドが、放送受信器によって受け取られる時に、受信器は、Ｓｈｏｗ Ａの対話型アプリケーションの実行を中断するが、終了はせず、Ａｄ Ｘの対話型アプリケーション（またはデフォルトアプリケーション）の実行を開始する。対話型アプリケーションを中断することによって、ゲームのポイントまたは視聴者が見ていた特定のフォームなどの、その対話型アプリケーションが有した状態情報が保存される。中断は、さらなる効果も有し、例えば、Ｓｈｏｗ Ａの対話型アプリケーションが視聴者のテレビジョンセットのディスプレイから除去され、その結果、Ａｄ Ｘが画面にある時に、Ｓｈｏｗ Ａの対話型アプリケーションが表示されず、Ａｄ Ｘの対話性が、適当に進行するようになる。
イベントマネージャ５０４によって、Ｓｈｏｗ Ａに他のセグメントがないと判定できるまで（この時点では未知）、トランスレータモジュールの取消コマンドが延期される。この判定は、その後、以下で示すようにＳｈｏｗ Ｂが開始される時に行われる。

番組セグメントＡ．２
１２３４：Ａｄ Ｘが終わろうとする時に、スケジューリングシステム１０６は、Ａ．２プリロード信号を発行する。
１２３６：トランスレータモジュール５０２は、Ａ．２スケジュールコマンドを発行する。
この時点で、イベントマネージャ５０４のマッピングロジック５０８は、このイベントの（セグメントＡ．２）番組ＩＤが、セグメントＡ．１の番組ＩＤと同一の対話型アプリケーションに相関すると判定する。従って、マッピングロジック５０８は、セグメントＡ．２に関するすべてのコマンドを（番組ＩＤに従って）Ｓｈｏｗ Ａのイベントステートマシンにルーティングする。Ｓｈｏｗ Ａのこのセグメントの対話型アプリケーションは、既に放送受信器にロードされているので、放送サーバがこれを今プリロードさせる必要はない。従って、イベントマネージャは、別のスケジュールコマンドを発行しない。
１２３８：スケジューリングシステム１０６は、Ａ．２プリロール信号またはＡ．２開始信号を発行する。
１２４０、１２４２：トランスレータモジュール５０２は、Ａｄ Ｘの取消コマンドと、セグメントＡ．２の開始コマンドを送る。
１２４４、１２４６：イベントマネージャ５０４は、最初に、Ａｄ Ｘの対話性を取り消し、Ｓｈｏｗ Ａステートマシンに開始コマンドをルーティングするように放送サーバに指示し、これによってＳｈｏｗ Ａに関連する対話型アプリケーションを開始するように放送サーバに指示する。Ｓｈｏｗ Ａの対話型アプリケーションは、以前に中断されただけなので、Ａｄ Ｘ開始の前に有した状態を有して、ここで再び動作を開始する（１２４８）。
従って、Ｓｈｏｗ Ａがゲーム番組であり、その対話型アプリケーションがゲームアプリケーションである場合に、Ａｄ Ｘについてアプリケーションを中断することによって、ゲームでの視聴者のポイント総計（および他の状態）が保存され、セグメントＡ．２が放送され、アプリケーションが再開始される時に復元される。

Ａｄ Ｙ
１２５０：少し後に、スケジューリングシステム１０６は、Ａｄ Ｙプリロード信号を発行する。
１２５２：トランスレータモジュール５０２は、Ｙスケジュールコマンドをイベントマネージャ５０４に送る。
１２５４：イベントマネージャ５０４は、Ａｄ Ｙの対話性を放送サーバ上でスケジューリングする。
１２５６：スケジューリングシステム１０６は、Ａｄ Ｙプリロール信号またはＡｄ Ｙ開始信号を発行する。
１２５８、１２６０：トランスレータモジュール５０２は、セグメントＡ．２の取消コマンドおよびＡｄ Ｙの開始コマンドを送る。
１２６２、１２６４：イベントマネージャ５０４は、取消コマンドを延期し、その代わりに、Ｓｈｏｗ Ａの対話性を停止し、Ａｄ Ｙの対話性がある（デフォルト含む）場合に、その対話性を開始するように放送サーバに指示する。Ｓｈｏｗ Ａの対話型アプリケーションが、中断され（１２６６）、Ａｄ Ｙの対話性が実行される（１２６８）。
Ｓｈｏｗ Ａのステートマシンは、セグメントＡ．２の対話型アプリケーションの取消を延期する。何故ならば、Ｓｈｏｗ Ａの別のセグメントがあるかどうかがわからないからである。

Ｓｈｏｗ Ｂ
１２７０：Ａｄ Ｙが終わろうとしている時に、スケジューリングシステム１０６は、Ｓｈｏｗ Ｂプリロード信号を発行する。
１２７２：トランスレータモジュール５０２は、Ｓｈｏｗ Ｂをスケジューリングする。
１２７４：イベントマネージャのマッピングロジック５０８は、Ｓｈｏｗ Ｂの番組ＩＤがＳｈｏｗ Ａと異なり、従って、Ｓｈｏｗ Ａのセグメントがこれ以上ないと判定する。Ｓｈｏｗ Ｂの新しいステートマシンがインスタンス化される。イベントマネージャ５０４は、Ｓｈｏｗ Ｂスケジュールを放送サーバに発行して、Ｓｈｏｗ Ｂの対話性をスケジューリングする。イベントマネージャは、Ｓｈｏｗ Ｂがまだ開始されていないので、まだＳｈｏｗ Ａの対話性を取り消さない。
１２７６：スケジューリングシステム１０６は、Ｓｈｏｗ Ｂのプリロールまたは開始のいずれかを発行する。
１２７８、１２８０：トランスレータモジュール５０２は、Ａｄ Ｙを取り消し、Ｓｈｏｗ Ｂを開始するアトミックコマンドを発行する。
１２８２、１２８４：イベントマネージャ５０４は、まずＡｄ Ｙを取り消し、その後、新しいＳｈｏｗ Ｂステートマシンに開始コマンドをルーティングする。
１２８８：Ｓｈｏｗ Ｂ開始コマンドが現れる時に、新しい番組が始まることが明白なので、イベントマネージャ５０４は、Ｓｈｏｗ Ａ、セグメントＡ．２の対話性を安全に取り消すことができる。この取消コマンドは、トランスレータモジュール５０２から直接に来るのではなく、Ｓｈｏｗ Ｂの開始コマンドに基づいて、イベントマネージャのＳｈｏｗ Ａステートマシンによって合成される。Ｓｈｏｗ Ｂを、その放送の１時間前にスケジューリングすることが可能なので、Ｓｈｏｗ Ｂが実際に開始されるまで、Ｓｈｏｗ Ａの対話性を取り消してはならない。連続した番組の可能性があり、Ｓｈｏｗ Ｂがその開始時間の１時間前にスケジューリングされる可能性があるので、イベントＢをスケジューリングする時に、取消を行えない場合があることにも留意されたい。

いくつかの場合に、２つのテレビジョン番組（例えば、Ｓｈｏｗ ＡおよびＳｈｏｗ Ｂ）の間に入るコマーシャル（例えば、Ａｄ Ｙ）がない。すなわち、２つの番組が連続する場合がある（すなわち、Ｓｈｏｗ ＢがＳｈｏｗ Ａの直後に開始される可能性がある）。この場合には、Ｓｈｏｗ Ａ取消１２８８が、Ｓｈｏｗ Ｂ開始１２８４の前に行われる。

代替実施形態では、イベントマネージャ５０４は、ある対話型アプリケーションを取り消す前に、別の対話型アプリケーションを開始することができる。例えば、これは、対話型アプリケーションの取消が、停止より長い時間を要する場合に望ましく、２つの番組が連続する場合に、Ｓｈｏｗ Ａの対話型アプリケーションを取り消す前にＳｈｏｗ Ｂの対話型アプリケーションを開始することが、最適となる。一般に、代替実施形態は、以前の対話型アプリケーションを停止し、次の対話型アプリケーションを開始し、以前のアプリケーションを取り消すことである。

（Ｅ．動的対話型アプリケーションの更新）
上述したように、放送サーバ１１０は、対話型アプリケーションの特徴、ユーザインタフェース、または機能性を更新または修正するデータを送信することができる。この更新は、対話型アプリケーションの情報に対する更新、テキスト更新（例えば、新しいスポーツスコア、分類された宣伝、ニュース情報、ゲームの質問、または回答、番組ゲストのリスト）、イメージ更新（例えば、新しい天気図）、サウンド更新、およびファイル更新を含むが、これらに制限はされない。

対話型アプリケーションの更新を検討する際に、対話型アプリケーションを下記の３つのクラスに分離することが有用である。
１．静的アプリケーション：この種類の対話型アプリケーションは、その実行中に更新を一切受け取らない。
２．動的アプリケーション：動的アプリケーションは、通常は実行中に、新しい情報によって更新されるアプリケーションである。その例は、フットボールの試合中に新しいスコアを受信するスポーツティッカアプリケーション、同様に、更新された株式相場を受信する株式相場表示器アプリケーションである。データ更新のソースは、変化し、生データフィード、ウェブ情報に再度目的を持たせること、特定の時刻に送信される静的に定義された更新（例えば、ゲーム番組に付随する対話型プリケーションでの質疑応答）を含む。データ更新のソースは、全国的更新を生成する全国規模の放送会社および／または地方の更新を生成する地方サイトに置くことができる。上記したように、各動的アプリケーションが、一意のアプリケーション識別コードを有する。
３．再作成される動的アプリケーション：これは、新しい情報を含めるために定期的に再作成されるが、同一のアプリケーション識別コードが再利用され、構造的に同一である対話型アプリケーションである。従って、更新は、アプリケーションが、付随する番組と共に放送されるたびの新しいデータを構成する。そのような対話型アプリケーションの例が、ＮＢＣ社の「Jay Leno Show」などのバラエティテレビジョン番組に付随する対話型アプリケーションである。このアプリケーションは、毎晩同一の外見を有するが、その日のゲストおよび他の現在の情報を含めるために毎晩更新される。このアプリケーション種別を静的アプリケーションと区別することの長所は、対話型アプリケーションを対話型アプリケーションデータベース１１２に永続的に保管することができ、選択されたレコードまたは対話型アプリケーションの部分が、アプリケーションが送信される時に更新されることを示すようにマークされることである。これによって、放送会社１１４が、対話型アプリケーション全体ではなく、更新だけを送信できるようになるので、これは有利である。

図１３を参照すると、動的な対話型アプリケーションに更新を提供するシステムの実施形態が示されている。図１に関して説明したさまざまな要素のほかに、この実施形態は、更新マネージャ１３００を含む。更新マネージャ１３００は、２つのモジュールすなわち、対話型コンテンツコード検出器１３０２、および対話型コンテンツコードリーダ１３０４を含む。一般に、コード検出器１３０２は、受信された信号内の対話型アプリケーション識別コードを識別し、自動化サーバ１０８に供給する。自動化サーバ１０８は、識別された対話型アプリケーションの状態を追跡し、コードリーダ１３０４に制御信号を供給する。コードリーダ１３０４は、放送信号を読み取り、放送サーバ１１０で使用可能な対話型アプリケーションの対応するレコードに対する更新である部分（例えばレコード）を識別する。自動化サーバ１０８は、コードリーダ１３０４にコマンドを供給し、このコマンドは、受信装置への送信のために放送サーバ１１０にそのような更新を送る、またはそのような更新の送出を停止する、のいずれかを指示する。放送サーバ１１０は、最終的な放送受信器１２０への送信のために、ＤＩＵ１１６に更新を供給する。これらの特徴を用いると、放送サーバ１１０は、放送会社によって形成される更新でアプリケーションを構成することに頼らずに、対話型アプリケーションを更新できるようになる。放送受信器１２０は、更新されたレコードを受信し、基礎となる対話型アプリケーションと共に実行する。

具体的に言うと、コード検出器１３０２は、放送会社１１４からの着信放送ビデオ信号を受信し、信号のＶＢＩ部分（または他のデータトランスポートの対応する部分）の対話型アプリケーション識別コードの存在、不在、または変更に関するさまざまな条件を検出する。更新マネージャ１３００は、チャネルごとに新しいコード検出器１３０２を開始し、上記したように、自動化サーバ１０８は、チャネルごとの対応するトランスレータ５０２および対話型アプリケーションごとのステートマシン５１０を維持する。

コード検出器１３０２は、対話型アプリケーションのレコードについてＶＢＩを監視し、各レコードのアプリケーション識別コードを読み取る。最初のアプリケーション識別コードの受信の際に、コード検出器１３０２は、自動化サーバ１０８内の対応するトランスレータ５０２に新識別子コード信号を供給する。同様に、コード検出器１３０２が、アプリケーション識別コードの変更を検出する場合にも、コード検出器１３０２は、新識別子コード信号を発行する。

コード検出器１３０２が、中断コマンドまたはキルコマンドを検出する場合に、コード検出器１３０２は、対応する中断信号またはキル信号を発行する。コード検出器１３０２が、対話型アプリケーションレコードなしなど、アプリケーション識別コードの不在を検出する場合には、コード検出器１３０２は、タイマを開始する。タイマは、ユーザが構成可能な満了時間を有し、対話型アプリケーションレコードが、その時間が満了する前に受信されない場合に、コード検出器１３０２は、データなし信号を発行する。

他の実施形態では、コード検出器１３０２は、特定のトリガ信号について放送信号を監視する。例えば、トリガ信号は、クローズドキャプションライン、ライン２１などの予約されたラインで送出することができる。ライン２１トリガ信号は、対話型アプリケーション識別コードなどのコンテンツ識別子と、カウントダウンタイマを制御するための持続時間カウント（例えば８秒）が含む。例えば、３０の持続時間カウントが、３０秒カウントダウンタイマを開始する。タイマが満了した時に、対話型アプリケーションまたは他のコンテンツが、停止する。トリガ信号が受け取られる場合には、対話型アプリケーションレコードは、無視される。その代わりに、コード検出器１３０２は、この例では予約されたラインで送信される、アプリケーション識別コードの変化を探す。識別コードが変化する場合に、新識別コード信号が、トランスレータ５０２に送られ、タイマが、リセットされて、持続時間カウントからカウントダウンする。タイマが満了する場合に、データなしコマンドがトランスレータに送られる。

各コード検出器１３０２に対応して、自動化サーバ１０８は、トランスレータ５０２およびイベントマネージャ５０４を維持する。トランスレータ５０２は、コード検出器１３０２からのさまざまな信号を受け取る。各準備および開始の際に、トランスレータ５０２は、新しいステートマシン５１０（新しい対応するアプリケーションがあるので）と、上述した、それを介する遷移を開始する。イベントマネージャ５０４は、同様に、イベントマネージャ５１２を開始して、対応するトランスレータステートマシン５１０によって発行されるアトミックコマンド５１４を受け取る。

表１３に、コード検出器１３０２によって供給される制御信号の種類と、トランスレータ５０２での理想的な信号の間の関係を要約する。

上述したように、イベントマネージャ５０４は、トランスレータ５０２からのアトミックコマンドに応答して、ステートマシンを使用して各イベントの状態を追跡して、放送サーバ１１０のイベント（対話型アプリケーション）を管理する。イベントマネージャ５０４が、トランスレータ５０２からスケジュールコマンドを受け取る時には、イベントマネージャ５０４は、放送サーバ１１０に、放送に関する新しいイベント（対話型アプリケーション）を開始し、維持するように指示し、放送サーバ１１０は、このイベントを参照するために、イベントマネージャ５０４にイベントＩＤを返す。イベントＩＤは、放送される対話型アプリケーションの特定のインスタンスの一意の識別子である。

他の実施形態では、コード検出器１３０２は、トランスレータの機能性が直接に組み込まれ、それが識別する対話型アプリケーションごとにそれ自体のステートマシンを維持する。従って、放送信号の変化がアトミックコマンドに直接にマッピングされ、これらのアトミックコマンドが、イベントマネージャ５０４に供給される。この実施形態では、トランスレータの機能性が、コード検出器１３０２に移動される。

どちらの実施形態でも、イベントマネージャ５０４は、コードリーダ１３０４と相互作用するための追加の機能性を含む。具体的に言うと、イベントマネージャ５０４は、コード検出器１３０２のリーダを制御する２つの追加コマンドを提供する。第１に、イベントマネージャ５０４が、開始アトミックコマンドを受け取る時に、上述したように開始済み状態１１０４に遷移する。ここで、他の挙動のほかに、イベントマネージャ５０４は、対話型アプリケーションコードと、放送サーバ１１０によって供給された対応するイベントＩＤを指定して、チャネルに関してコードリーダ１３０４にＳｔａｒｔ＿Ｕｐｄａｔｅｓコマンドを発行する。イベントマネージャが、停止アトミックコマンドを受け取る時に、停止状態１１０６に遷移し、更新が停止される対話型アプリケーションの対話型識別コードをあたえて、コードリーダ１３０４にＫｉｌｌコマンドを発行する。

コードリーダ１３０４は、対話型アプリケーションのどのレコードが更新されるかを判定し、これらのレコードを放送サーバ１１０に供給する責任を負う。他のモジュールと同様に、コードリーダ１３０４は、チャネル指向であり、各チャネルでの別々の状態と、各チャネルの各アプリケーションを維持する。アプリケーションごとに、コード検出器１３０２は、その対話型アプリケーションのどのレコードが更新されるかを判定し、これらの更新を放送サーバ１１０に転送する。Ｓｔａｒｔ＿Ｕｐｄａｔｅｓコマンドの受取の前に、コードリーダ１３０４は、更新されるレコードをキャッシングする。コードリーダ１３０４は、イベントマネージャ５０４からのＳｔａｒｔ＿Ｕｐｄａｔｅｓコマンドに応答して、これらの更新の供給を開始する。コードリーダ１３０４は、アプリケーション識別子、放送サーバによって認識されるイベントＩＤ、および放送される更新レコードと共に、放送サーバ１１０にＵｐｄａｔｅコマンドを供給する。放送サーバ１１０は、ＤＩＵ１１６による放送のために、更新されたレコードを準備する。イベントマネージャ５０４からのＫｉｌｌコマンドに応答して、コードリーダ１３０４は、放送サーバ１１０への更新されたレコードの送信を停止する。

いくつかの実施形態で、放送サーバ１１０は、放送受信器への送信のために、所与の放送番組の、放送信号でエンコードされて受信されるものと異なる対話型アプリケーションを提供する。放送サーバ１１０は、受信された対話型アプリケーションを修正するか、異なるアプリケーションと置換することができる。異なるアプリケーションを、例えばローカルに関連する情報（例えば全国規模の売手の支点）を提供するか、高帯域幅アプリケーションなど（例えば、ＭＰＥＧまたは他のディジタルフォーマットで）の強化されたコンテンツを供給するなど、最初に受け取られたアプリケーションのローカルにカスタマイズされたバージョンとすることができる。

ディジタルアプリケーションが放送ディジタルビデオストリームに挿入される一実施形態では、データ挿入ユニット１１６が、当業者に既知の、例えばＭＰＥＧ１ストリームまたはＭＰＥＧ２ストリームなどの、ＭＰＥＧまたは他のディジタルフォーマット挿入能力を有する。放送サーバ１１０は、対話型コンテンツをＭＰＥＧストリームを生成するローカルサブシステムマルチプレクサに送信する。ローカルサブシステムのマルチプレクサは、典型的には、対話型コンテンツビットストリームを受け取るシリアルポートまたはＴＣＰ／ＩＰポートを有する。対話型コンテンツビットストリームを受け取る時に、マルチプレクサは、その通常動作に従って、その対話型コンテンツを出力ディジタルビデオストリームに追加する。マルチプレクサは、適当な時に、対話型コンテンツを除去または置換することもできる。ディジタルストリームが、SMPTE 259M-C標準規格で指定されるSerial Component Digital Video（パケットベースのディジタルビデオストリーム）である場合には、既存のパケットをローカル放送サーバ１１０によって送信される新しいパケットと置換することによって対話型コンテンツを追加するのに、Norpakエンコーダが使用される。代替案では、対話型コンテンツのディジタルバージョンが、アナログサブシステム６２８に放送された場合に、ローカルの対話型放送サーバ６０６によって、ディジタルアプリケーションを低帯域幅アナログアプリケーションにスワップすることができる。対話型コンテンツのアナログ版がシステム１００に放送された場合に、アナログバージョンは、まずディジタル番組に変換されるか、ディジタル番組が、アナログ版の代わりにスワップされる。アナログ版をディジタル化する場合には、ソフトウェアアナログディジタルコンバータを使用して、アナログバージョンを、ローカルサブシステムのプロトコルに従うディジタル番組に変換する。一実施形態では、ローカル放送サーバ１１０は、複数のアプリケーション配布をサポートする。例えば、ケーブルヘッドエンドサブシステムは、アナログストリームとディジタルストリームの両方を配布して、ディジタル放送受信器を有する家庭が、より高品質の対話性を受信すると同時に、アナログ放送受信器を有する家庭が、それでもより単純な対話性を受信できるようにすることができる。この実施形態では、ローカル放送サーバ１１０は、対話型コンテンツのより豊富なバージョンおよびより単純なバージョンの両方が選択され、これらをめいめいの信号に挿入する。

これらの実施形態では、更新マネージャ１３００は、最初に受信された対話型アプリケーションに関連する更新されたレコードの、放送されている、カスタマイズされたローカルバージョンへの移動を可能にする。これには、例えばＶＢＩラインからＭＰＥＧへなどのトランスポート層の変更が必要である可能性があるが、これによって、そのようなレコードを、ローカルアプリケーションに一体化できるようになる。その結果、放送会社が元々更新およびカスタマイズされたアプリケーションの両方を組み合わせた放送信号を作成しなかった場合であっても、ローカル放送サーバ１１０が、アプリケーションのローカルにカスタマイズされたバージョンの更新を提供できる。

対話型アプリケーションのどのレコードを更新するか、およびどれが静的レコードであるかを判定するために、さまざまな方法を使用することができる。単純な実施形態では、各レコードを、そのレコードが静的レコードまたは更新のどちらであるかを示すフラグによってマークする（レコードは、放送会社によって、またはローカルシステム内で更新することができる）。コードリーダ１３０４は、受信時に対話型アプリケーションの各レコードを読み取っており、更新としてタグを付けられたレコードをローカル放送サーバ１１０に転送する。

より洗練された実施形態には、各レコード内はシーケンス番号を含む。未更新の対話型アプリケーションのレコードは、０に初期化される。レコードが更新されるたびに、シーケンス番号が増分される。コードリーダ１３０４は、対話型アプリケーションごとに、対話型アプリケーションの各レコードおよびそのシーケンス番号（各レコードにレコードＩＤが含まれる）をリストするテーブルを維持する。あるレコードが、対話型アプリケーションに関して受信される時に、コードリーダ１３０４は、テーブル内のシーケンス番号を、受信したレコードのシーケンス番号と比較する。受信されたレコードのシーケンスＩＤが、保管されたシーケンス番号より大きい場合には、コードリーダ１３０４は、このレコードが更新であることを知り、適宜、キャッシングするか、放送サーバ１１０に送る。コードリーダ１３０４は、テーブルに保管されたシーケンス番号も更新する。

このシーケンス番号付け実施形態は、上述した、同一の対話型識別コードが使用されるが、放送されるたびに異なる更新を必要とする、再作成される動的アプリケーションに特に有用である。この対話型アプリケーションのローカルに保管されるバージョンは、すべてが０の値のシーケンス番号を含む。対話型アプリケーションの更新された国内版のそれぞれに、すべての動的レコードすなわち更新されるレコードについて１のシーケンス番号が含まれる。例えば、アプリケーションが、夜に放送される場合に、毎晩の更新レコード（例えばゲストのリスト）に、「１」のシーケンス番号を付ける。ローカル放送サーバ１１０は、放送のたびにローカルアプリケーションを再ロードするので、毎回０の値のレコードになる。従って、コードリーダ１３０４は、新しい放送のそれぞれで、更新されたシーケンス番号を識別する。これによって、全国放送会社が、単に動的レコードを変更することによって、毎回同一の対話型アプリケーションを使用できるようになる。これによって、毎晩更新を提供するのに必要なオーバーヘッドが減り、全国放送会社（または対話型アプリケーションを提供するすべてのもの）が、別個のアプリケーション識別コードを有する異なるアプリケーションを毎晩展開し、追跡する必要がなくなる。

レコードのタグ付けおよびシーケンス番号付けを、一緒に使用することもできる。対話型アプリケーションを、動的レコードの一部だけに更新のタグを付けられるように、ローカルに構成することができる。これは、例えば、ローカルシステムオペレータが、全国放送会社によって供給される、ある更新を無視することを望む場合に望ましい。この実施形態では、コードリーダ１３０４は、更新についてマークし、増分されたシーケンス番号を有するレコードだけを渡す。

更新提供の他の改良として、全国に放送される対話型アプリケーションによって提供されるものなど、更新されたレコードが、ローカルアプリケーションで更新されるレコードとの互換性を有することを保証することが望ましい。これは、あるレコード種別（例えばテキスト）の、別のレコード種別（例えばビットマップ）の置換によって、対話型アプリケーションが放送受信器でクラッシュし、許容されない結果を引き起こす可能性があるからである。コードリーダ１３０４ですべてのレコードに対して種別検査を行うことは、理論的には可能であるが、実際には、超高速でレコードを処理する必要に起因して、実用的な実施形態ではない。

従って、ある解決策では、各対話型アプリケーションに対する二重チェックサム（シグニチャ）を利用する。

第１のチェックサムは、アップロードされたレコードの構造に基づくが、その可変コンテンツに基づかずに、すなわち、更新されるレコードの非コンテンツ部分に基づいて計算される。例えば、チェックサムを、更新されるレコードのすべてのレコードＩＤおよびレコード名について計算することができる（代替案では、レコード種類も使用することができ、あるいは、これらのフィールドの組合せ、例えばＩＤおよび種類を使用することができる）。例えば、Guest_Listという名前のレコードのコンテンツを変更することはできるが、名前は、その型と同様に、更新にまたがって一定である。この「動的」チェックサムが、対話型アプリケーションと共に送信され、コードリーダ１３０４によって受信され、ローカル対話型アプリケーションの対応するレコードからの対応する動的チェックサムと比較される。これらが一致する場合には、コードリーダ１３０４は、更新されたレコードが、それに対応するローカルに保管されたレコードとの互換性を有することを知る。

第２のチェックサムは、国内（より一般的にはリモート）バージョンとローカルに保管されたバージョンの両方の、対話型アプリケーションの静的（変化しない）部分のすべてから計算される。この静的チェックサムが、対話型アプリケーションと共に送信され、コードリーダ１３０４によって受信され、同一のアプリケーションのローカルに保管されたバージョンの対応するチェックサムと比較される。これらのチェックサムが一致する場合には、コードリーダ１３０４は、対話型アプリケーションの静的部分、例えばスクリプト、ボタン、画面レイアウトなどが同一であることを知る。

チェックサムのいずれかが一致しない場合には、コードリーダ１３０４は、更新レコードを放送サーバ１１０に供給しない。２つのチェックサム値だけが計算されるので、この方法は、非常に高速であり、コードリーダ１３０４による追加の帯域幅を必要としない。

動的データ更新のほかに、更新マネージャ１３００によって、全国に（または他の形でリモートに）放送される対話型アプリケーションからローカル対話型アプリケーションへ制御情報を渡すこともサポートされる。この制御情報は、下記を含むが、これらに制限はされない。
・「対話型アプリケーションを終了」および「対話型アプリケーションを中断」などのコマンド。これによって、対話型アプリケーションの動作を制御する他の機構が提供される。
・信号の出所に関する情報（例えば、信号がどの全国放送サーバから来たか）。
・アプリケーション実行時間情報。このような情報（「リース」と称する）は、その間にアプリケーションの開始、実行、または終了を行うことができる特定の時間ウィンドウを制御するのに使用される。この特徴のさらなる詳細は、例えば、特許文献２に記載されている。

これらの信号のいずれかまたはすべてを、双方向テレビジョンシステムの必要に応じて、ローカルにカスタマイズされた対話型アプリケーションに渡すことができる。

（Ｆ．要約）
要約すると、本発明は、テレビジョン番組、コマーシャル、および類似物を含む放送番組の放送および表示と同期して、対話型コンテンツの挙動を制御するさまざまな方法および手段を提供する。ネイティブ信号を使用して放送番組の識別および状態を判定し、放送番組に関連する対話性の状態を管理することを含む、本発明の原理は、さまざまな異なる形で、多数の変形形態を用いて実施することができる。本発明の範囲内のこれらの変形形態の一部を、以下に示す。

自動化サーバ１０８を、トランスレータモジュール５０２およびイベントマネージャ５０４という二重のステートマシンを使用するものとして説明した。有益ではあるが、本発明の他の実施形態を、例えば制御信号の種類ごとにプログラミングされたスクリプトまたは他の手続き機構を使用して、ステートマシンなしで自動化サーバ１０８またはその機能性を実施することが可能である。

トランスレータモジュール５０２の理想的な制御信号および状態の組、イベントマネージャ５０４に出力されるアトミックコマンド、または放送サーバに似た装置を制御するために作られるコマンドのすべてを、より多数または少数の信号またはコマンドを含めるために変更することができる。同様に、状態のそれぞれでの特定のアクションを変更することができる。例えば、停止または取消のコマンドのほかに、より複雑な制御のために、再開コマンドまたは遅延付き再開コマンドを使用することができる。保存コマンドによって、将来の検索のために対話性で生成されたデータを保存するように放送受信器１２０に指示することができる。このコマンドは、ユーザまたは対話性によって作成されたデータを保存するために、例えば、エラー状態、チャネル変更、または他のイベントに応答して生成することができる。送信コマンドまたはアップロードコマンドによって、例えば対話型購入アプリケーションを介する購入を完了するために、作成された／収集機構に保管されたデータを送信するように放送受信器に指示することができる。

自動化サーバ１０８および本発明によって制御することができる対話性の種類は、変更することができ、既存の対話型アプリケーションに制限されない。ウェブページなどの対話性またはウェブページと対話型アプリケーションの組合せを、本発明の原理を使用して制御できることが予想されている。

コマンドが放送サーバまたは類似する装置に送られる時のタイミングは、帯域幅、データ送信の接続速度、およびどれほどすばやくテレビジョン画像を表示できるかに関する放送受信器の実行応答時間に応じて、変更することができる。従って、基礎となる放送イベントが発生する前に、その正確な時刻に、その直後に、またはかなり前に、コマンドを送ることができる。コマンドのタイミングは、最も早い可能な時にどの情報が既知であるかを利用するように最適化することができる。

制御信号を自動化サーバまたはその同等物に供給する手段を、変更することができる。これには、スケジューリングシステムへのシリアルポート、ＬＡＮ、または遠隔通信インタフェースを介するバイナリデータ、あるいはアナログビデオ信号またはディジタルビデオ信号にエンコードされたバイナリデータが含まれる。

従って、本発明は、請求項の範囲によって制限され、開示した好ましい実施形態の詳細によって固有に制限されないことを理解されたい。

本発明にかかるシステムを示す図である。 放送受信器を示す図である。 対話型アプリケーションを受信し、実行する処理全体を示す流れ図である。 本発明の実施形態の自動化サーバを示す図である。 トランスレータモジュールおよびイベントマネージャを含むチャネルインタフェースを示す図である。 インタフェースマネージャのライフサイクル図である。 トランスレータモジュールおよびイベントマネージャを含むチャネルインタフェースのライフサイクル図である。 理想的なトランスレータのステートマシン図である。 トランスレータモジュールのマッピングロジックの流れ図である。 イベントマネージャのマッピングロジックの流れ図である。 イベントマネージャのステートマシン図である。 コマーシャルに関する放送番組の対話性のセグメント化を示すイベントトレースの図である。 動的な対話型アプリケーションに更新を提供するシステムを示す図である。

Claims (34)

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. 前記コードリーダは、前記更新されたレコードを、前記アナログトランスポートプロトコルと互換のフォーマットから前記ディジタルトランスポートプロトコルと互換のフォーマットに変換することを特徴とする請求項２３に記載のシステム。
29. 前記コードリーダは、
    前記対話型アプリケーションのレコードごとに現在シーケンス番号を保管し、
    前記対話型アプリケーションの受信されたレコードのシーケンス番号が、前記対話型アプリケーションのレコードに関する前記現在のシーケンス番号を超えるか否かを判定し、
    前記シーケンス番号が前記保管されたシーケンス番号を超えるとの判定に応答して、前記更新レコードを選択し、前記更新レコードに関する前記保管されたシーケンス番号を受信されたシーケンス番号に調整する
    ことを特徴とする請求項１８に記載のシステム。
30. 前記コードリーダは、
    前記対話型アプリケーションのレコードごとに現在シーケンス番号を保管し、
    前記対話型アプリケーションのレコードごとに、更新フラグを識別することにより、前記更新レコードが更新であるか否かを判定し、
    前記更新フラグを有する更新レコードごとに、前記更新レコードのシーケンス番号が、前記対話型アプリケーションのレコードに関する前記現在のシーケンス番号を超えるか否かを判定することにより、前記更新レコードを利用するか否かを判定し、
    前記シーケンス番号が前記保管されたシーケンス番号を超えるとの判定に応答して、前記更新レコードの前記保管されたシーケンス番号を、前記受信されたシーケンス番号に調整する
    ことを特徴とする請求項１８に記載のシステム。
31. 前記コンテンツリーダは、前記更新レコードが前記対話型アプリケーションの対応するレコードと互換である場合に限って、前記更新レコードを前記放送サーバに提供することを特徴とする請求項１８に記載のシステム。
32. 前記コンテンツリーダは、前記対話型アプリケーションの前記レコードの非コンテンツ部分の第１チェックサムを、可変コンテンツを含む対応する前記対話型アプリケーションのレコードの非コンテンツ部分の第１チェックサムと照合することにより、前記更新レコードが前記対話型アプリケーションの前記対応するレコードと互換であるか否かを判定することを特徴とする請求項３１に記載のシステム。
33. 前記レコードの非コンテンツ部分は、
    レコードＩＤと、
    レコード種別と
    レコード名と
    からなる群から選択される少なくとも１つを含むことを特徴とする請求項３２に記載のシステム。
34. 前記コンテンツリーダは、前記更新レコードの静的部分の第２チェックサムを、前記対話型アプリケーションンのレコードの静的部分の第２チェックサムと照合することにより、前記更新レコードが前記対話型アプリケーションの前記対応するレコードと互換であるか否かを判定することを特徴とする請求項３２に記載のシステム。

Images