無線通信技術は、過去数年間で飛躍的な成長を経験してきた。この成長は、移動可能な公衆に移動の自由を提供し、有線通信システムへの束縛を断ち切る、ワイヤレスサービスによって促進されてきた。サービス拡大の結果として、無線サービスの普及は急速な成長を続けことが期待される。無線通信サービスに最近加えられたことは、受信デバイスにテレビやその他のコンテンツを放送する能力である。マルチメディア・順方向リンク専用(multimedia forward link only (FLO))放送サービスは、ユーザが、テレビジョンショーのようなマルチメディア番組を見ることを許容し、また、モバイル放送送信を受信するように構成されるモバイル受信デバイスを用いて、ニュースの携帯版、エンターテイメント、スポーツ、ビジネス、インターネットデータ、データファイル、およびその他のコンテンツを受信することも許容する。マルチメディア放送サービスは、モバイルデバイスへの様々なサービスを配信するために使用され得る、かなりの帯域幅を示す。
様々な実施形態は、マルチメディア放送ネットワークを介して受信デバイスに対話型アプリケーションなどのアプリケーションを効率的に配信するためのソフトウェアを格納するシステム、デバイス、方法および非一時的コンピュータ可読媒体を提供する。様々なシステムおよび方法は、アプリケーションサプライヤの所望のサービス品質、放送時刻、起動時刻、対象となるデバイスおよびユーザ、ならびにアプリケーションが放送システムを介した配信のためにパッケージングされ、受信デバイスにおいて適宜に受信され、実装されることを可能にする他の基準に関する情報とともにアプリケーションおよび対話型イベントアイテムを放送のために対話型イベントのプロバイダを含むアプリケーションサプライヤが提示するためのインターフェースを提供する。様々な実施形態は、受信デバイスが、前に受信され、メモリに格納されたテンプレートおよびデータからイベントコンテンツを組み立てることを含めて、対話型イベントを適切に実装することを可能にする対話型イベントシグナリングメッセージを放送することを可能にする。様々な実施形態は、サービスシステム情報(サービスSI)メッセージ中で、リアルタイムサービスに関連する、対話型リソースを搬送するファイルデータフローと、対話型シグナリングメッセージを搬送する補助フローとを特定するためのシグナリング機構を提供する。
様々な実施形態は、1つまたは複数のリアルタイムチャネルに関連する対話型シーケンスのための対話型リソースを放送することを可能にする。様々な実施形態は、対話型リソースがファイルデータフローを共用するようにそれらの対話型リソースを放送することを可能にする。様々な実施形態は、1つまたは複数のリアルタイムチャネルに関連する対話型シーケンスのための対話型リソースが別々のファイルデータフロー上で搬送され得るように、それらの対話型リソースを区分することを可能にする。様々な実施形態は、補助フロー上で1つまたは複数のリアルタイムチャネルに関連する対話型シーケンスのための対話型シグナリングメッセージを放送することを可能にする。様々な実施形態は、補助フローを共用するように、または別々の補助フロー上で搬送され得るように対話型シグナリングメッセージを編成することを可能にする。様々な実施形態は、対話型リソースを搬送するファイルデータフローを発見するように受信デバイスを構成することを可能にする。様々な実施形態は、対話型シグナリングメッセージを搬送する補助フローを発見するように受信デバイスを構成することを可能にする。様々な実施形態は、さらに、受信デバイスバッテリー電力を節約しながら、信号とコンテンツとを効率的に配信するための機構および方法を提供する。様々な実施形態のこれらおよび他の機能および利益について、以下で詳細な説明において説明する。
本明細書に組み込まれ、本明細書の一部をなす添付の図面は、本発明の例示的な実施形態を示し、上記の概略的な説明および下記の詳細な説明とともに、本発明の特徴を説明するのに役立つ。
図1Aは、一実施例での使用に係る、モバイルマルチメディア放送通信システムとセルラ"ユニキャスト"通信システムとを示す通信システムのブロック図である。
図1Bは、順方向リンクのみの放送システムの放送通信システムブロック図の代わりの代表例である。
図1Cは、実施の形態に係り、対話型イベントを生成し、放送することに携わる機能モジュールを示す、放送通信システムの要素のシステムブロック図である。
図1Dは、実施形態に係り、放送通信システムを介してモバイルデバイスにアプリケーションを配信することに携わるシステム要素を示す、放送通信システムのブロックの代わりの代表例である。
図2は、様々な実施形態での使用に適したモバイル受信デバイスの一例のソフトウェアアーキテクチャ図である。
図3Aは、実施形態に係り、アプリケーションの受信に応答して提示され得る、ユーザインターフェース表示の図である。
図3Bは、実施の形態に係り、対話型イベントの要素を示す、プレゼンテーション表示の流れの図である。
図3Cは、図3Bに示される対話型イベントにおけるプレゼンテーション表示の流れに対応する表示状態と遷移を示す表示状態図である。
図4は、実施形態に係り、対話型イベントアプリケーションを自動的に生成し、それを受信デバイスに放送するための、放送ネットワークサーバに実装され得る実施形態の方法の処理フロー図である。
図5Aは、放送のためにアプリケーションパッケージと対話型イベントをコンパイルし、準備するために、放送システムのアプリケーションサーバ内で実行され得る実施形態の方法の処理フローである。
図5Bは、放送のためにアプリケーションパッケージと対話型イベントをコンパイルし、準備するために、放送システムのアプリケーションサーバ内で実行され得る実施形態の方法の処理フローである。
図5Cは、放送のためにアプリケーションパッケージと対話型イベントをコンパイルし、準備するために、放送システムのアプリケーションサーバ内で実行され得る実施形態の方法の処理フローである。
図6は、実施形態に係り、各種ファイルが、放送に適したアプリケーションパッケージにどのように組み立てられ得るかを示すフロー図である。
図7は、放送のためにアプリケーションパッケージをコンパイルし、準備するために、放送システムのアプリケーションサーバ内で実行され得る実施形態の方法の処理フロー図である。
図8は、様々な実施形態にしたがい、放送アプリケーションを受信するのに適したモバイル受信デバイスの他の例のソフトウェアアーキテクチャ図である。
図9は、放送アプリケーションカタログからダウンロードのためにアプリケーションを選択するため、受信デバイスに実装され得る実施形態の方法の処理フロー図である。
図10は、アプリケーションが受信された後、アプリケーションを起動するために、受信デバイスに実装され得る実施形態の方法の処理フロー図である。
図11は、アプリケーションが受信された後、アプリケーションを起動するために、受信デバイスに実装され得る他の実施形態の方法の処理フロー図である。
図12は、モバイルデバイス内の対話型イベントシグナリングメッセージを受信し、処理するための実施形態の方法の処理フロー図である。
図13は、モバイルデバイス内の対話型イベントシグナリングメッセージを受信し、処理するための実施形態の方法の処理フロー図である。
図14Aは、実施形態での使用に適した、対話型イベントシグナリングメッセージデータの形式の例を示す。
図14Bは、実施形態での使用に適した、対話型イベントシグナリングメッセージデータの形式の例を示す。
図15は、実施形態での使用に適した、対話型イベントシグナリングメッセージデータの形式の例を示す。
図16Aは、実施形態での使用に適した、対話型イベントシグナリングメッセージデータの形式の例を示す。
図16Bは、実施形態での使用に適した、対話型イベントシグナリングメッセージデータの形式の例を示す。
図16Cは、実施形態での使用に適した、対話型イベントシグナリングメッセージデータの形式の例を示す。
図17は、実施形態での使用に適した対話型イベントテンプレートのデータ構造例である。
図18は、対話型イベントテンプレートを使用して対話型イベントを実装するための実施形態の方法の処理フロー図である。
図19は、放送ネットワークを介する受信と更新のために、電子サービスガイドカタログにおける対話型イベントテンプレートを特定するための実施形態の方法の処理フロー図である。
図20Aは、更新される対話型イベントテンプレートを受信し、格納する実施形態の方法の処理フロー図である。
図20Bは、放送ネットワークを介して送信するために、対話型イベントのテンプレートを使用して対話型イベントを生成するための実施形態の方法の処理フロー図である。
図21Aは、対話型イベントでのユーザーの参加に基づいて、受信デバイス上で対話型イベントに関連する追加データを受信するための実施形態の方法の処理フロー図である。
図21Bは、対話型イベントでのユーザーの参加に基づいて、受信デバイス上で対話型イベントに関連する追加データを受信するための実施形態の方法の処理フロー図である。
図22は、電子サービスガイドカタログの中への包含のために、対話型イベントのカタログリストを生成するための実施形態の方法の処理フロー図である。
図23A、電子サービスガイドカタログ内のカタログリストに基づいて対話型イベントを受信し、実行するための実施形態の方法の処理フロー図である。
図23B、電子サービスガイドカタログ内のカタログリストに基づいて対話型イベントを受信し、実行するための実施形態の方法の処理フロー図である。
図24Aは、実施形態での使用に適した、対話型イベントカタログデータの形式例を示す。
図24Bは、実施形態での使用に適した、対話型イベントカタログデータの形式例を示す。
図24Cは、実施形態での使用に適した、対話型イベントカタログデータの形式例を示す。
図24Dは、実施形態での使用に適した、対話型イベントカタログデータの形式例を示す。
図25Aは、受信デバイスが対話型イベントリソースを取得できるよう、リソースデータファイルフローを供給し、サービスSI情報を生成するための実施形態の方法の処理フロー図である。
図25Bは、受信デバイスが対話型イベントリソースを取得できるよう、リソースデータファイルフローを供給し、サービスSI情報を生成するための実施形態の方法の処理フロー図である。
図26Aは、サービスSI放送における情報に基づいて、リソースデータファイルフローから対話型イベントリソースを受信するための実施形態の方法の処理フロー図である。
図26Bは、サービスSI放送における情報に基づいて、リソースデータファイルフローから対話型イベントリソースを受信するための実施形態の方法の処理フロー図である。
図27は、実施例での使用に適したサービスSIデータの形式の例を示す。
図28は、受信デバイス内で対話型イベント要素を受信し、適切な対話型イベントを生成するための実施形態の方法の処理フロー図である。
図29は、様々な実施形態での使用に適した、対話型イベント生成データの形式の例を示す。
図30は、様々な実施形態での使用に適した、対話型イベント生成データの形式の例を示す。
図31は、様々な実施形態での使用に適した、対話型イベント生成データの形式の例を示す。
図32は、様々な実施形態での使用に適した、対話型イベント生成データの形式の例を示す。
図33は、様々な実施形態での使用に適した、対話型イベント生成データの形式の例を示す。
図34は、様々な実施形態での使用に適した、対話型イベント生成データの形式の例を示す。
図35は、様々な実施形態での使用に適した、対話型イベント生成データの形式の例を示す。
図36は、様々な実施形態での使用に適した、対話型イベント生成データの形式の例を示す。
図37は、対話型イベント信号メッセージ(interactivity event signal message (IESM))を実装するための例示的なデータ形式を示す。
図38は、視聴されるチャネに限定される、場合によっては、プログラムリストの中で、視聴対象のチャネルのいずれかの側のチャネルに限定される、対話型イベントアプリケーションデータとリソースとを受信するための実施形態の方法の処理フロー図である。
図39は、視聴されるチャネルが変更される場合、対話型イベントアプリケーションのータとリソースを受信するための実施形態の方法の処理フロー図である。
図40は、様々な実施形態での使用に適した例示の受信デバイスの構成要素ブロック図である。
図41は、様々な実施形態での使用に適した例示のサーバの構成要素ブロック図である。
詳細な説明
種々の実施形態は、添付の図面を参照しながら詳細に説明される。可能な限り、同じ参照番号は、同一又は類似の部分を参照するために、図面全体を通して使用さる。特定の例および実装への参照は、例示的な目的のためであり、本発明又は特許請求の範囲を限定することを意図されない。
“例、例示、事例(exemplary)”という用語は、この中で、「例、実例、例示としての働きをすること」を意味するために使用される。“例、例示、事例”としてこの中に記載される任意の実装は、必ずしも、他の実装よりも好ましいまたは有利であると解釈されるべきではない。
"モバイルデバイス(mobile device)"と "受信デバイス(receiver device )という用語は、 モバイルメディア放送受信(mobile media broadcast receivers)、セルラ電話(cellular telephones)、パーソナルテレビジョンデバイス(personal television devices)、パーソナルデータアシスタンツ(personal data assistants (PDA's))、パームトップコンピュータ(palm-top computers)、ワイヤレス電子メール受信(wireless electronic mail receivers (例えば、Blackberry(登録商標) やTreo(登録商標)のデバイス), マルチメディアインターネットイネーブル・セルラ電話(multimedia Internet enabled cellular telephones (e.g., the Blackberry Storm(登録商標))), グローバルポジショニングシステム(Global Positioning System (GPS))受信、ワイヤレスゲームコントローラ(wireless gaming controllers)、車(例えば、自動車)に搭載される受信、MediaFLO(登録商標)のようなFLO(順方向リンクのみ)の放送送信を受信し、処理するためにプログラム可能なプロセッサとメモリと順方向リンクのみ(FLO)モバイルTV放送受信回路を有する類似のパーソナル電子デバイスの任意のひとつまたは全てを言うために、この中で互換的に用いられる。
"放送(broadcast)"の用語は、データ(情報パケット)の送信を意味するためにこの中で使用され、それは同時に多数の受信デバイスにより受信することができる。放送メッセージの例としては、コンテンツ放送(コンテンツフロー)とメタデータメッセージなどのオーバーヘッド情報放送(オーバーヘッドフロー)を含む、モバイルテレビジョンサービス放送信号である。放送ネットワークは送信のみを行うことができ、直接の戻り通信リンクをもたない。このようなネットワークは、また、セルラ電話システムやワイヤレス広域ネットワーク(例えば、無線LAN、WIMAXなど)のような二方向ワイヤレス通信ネットワークから区別するために、順方向リンク専用(forward link only (FLO))放送ネットワークと呼ばれる。
この中で使われるような、"対話型イベント(interactivity event)"は、放送メディアを用いて配信され、モバイルデバイス上の対話型機能を開始するためにコンテンツと機能の起動(trigger)を提供するイベントをいう。対話型コンテンツは、"対話シーケンス"(時には "iSeq"と略記される)とこの中で呼ばれる、1つまたはそれより多くの場面(scene)の流れ(sequence)の中で、モバイルデバイスでユーザに表示され得る。対話型シーケンスは、視聴者への単一の経験として表現され、提供されることを意図されたコヒーレントエンティティにバンドルされるシーンの集合を含むことができる。対話型シーケンスアプリケーションデータは、対話型シーケンスを生成するために使用できる、シーンの情報、テキスト、画像、および、ユーザのアクションに関連するメタデータを含む。この中で使用する場合、対話型イベントアプリケーションデータは、イベントメタデータ、シーンテンプレートデータ、ユーザアクション、およびシーケンスロジックを含み、また、一般的にそれらをいう。この中で用いられる場合、 "対話型資産(interactivity assets)"の用語は、一般的に、対話型シーケンスにおいて、または、対話型ベントの一部として使用される画像やグラフィックをいう。"対話型リソース(interactivity resources)”は、"アプリケーションデータ、テンプレート、および対話型資産を含む対話型イベントで使用されるさまざまなリソースをいう、総称的な用語として用いられる。
多くの異なるモバイルテレビ放送サービスや放送規格が、利用可能、または、将来的に企画されるが、それらの全てが、種々の実施形態を実装することができ、また恩恵を受け得る。このようなサービスや規格は、オープン・モバイル・アライアンス・モバイル放送サービス・イネーブラスイート(Open Mobile Alliance Mobile Broadcast Services Enabler Suite (OMA BCAST))、メディアFLO(MediaFLO(登録商標))、 デジタル映像放送・IPデータ配信(Digital Video Broadcast IP Datacasting (DVB-IPDC))、デジタル映像放送−ハンドヘルド(Digital Video Broadcasting-Handheld (DVB-H))、デジタル映像放送−携帯衛星サービス(Digital Video Broadcasting-Satellite services to Handhelds (DVB-SH))、デジタル映像放送−ハンドヘルド2(Digital Video Broadcasting-Handheld 2 (DVB-H2))、次世代テレビジョンシステム委員会−モバイル/ハンドヘルド(Advanced Television Systems Committee-Mobile/Handheld (ATSC-M/H))、および、中国マルチメディアモバイル放送(China Multimedia Mobile Broadcasting (CMMB))を含む。放送フォーマットや用語は、異なるモバイルマルチメディア放送サービス規格の間で変わるが、それらの全てが、モバイルデバイスが選択されるコンテンツを受信し、視聴またはダウンロード用に利用可能なプログラムやコンテンツをユーザに知らせることを可能にするために、メタデータ送信を利用する。参照を容易にするために、様々な実施形態は、FLO TV(登録商標)放送システムに実装されるメディアFLO(登録商標)システムを参照して説明される。しかし、メディアFLO(登録商標)の用語の参照や技術的詳細は、例示の目的に限られ、特許請求の範囲において特に記載されない限り、特定のFLO通信システムまたは技術に特許請求の範囲を限定することは意図されない。
様々な実施形態は、モバイル受信デバイスを介してモバイル放送コンテンツとのユーザ対話性をサポートする方法でアプリケーションを配信するための機構およびシステムを提供する。対話型機能は、ユーザのモバイルデバイス上でTV番組またはコマーシャルなどの特定の放送コンテンツを視聴している間、ユーザが関与することを可能にする。対話型形態は、ユーザが、ユーザのモバイルデバイス上に提示されたコンテンツとユーザが能動的に対話し、参加することを可能にすることによって、(受動的視聴の反対に)能動的視聴を可能にする。リアルタイムコンテンツを視聴しているユーザは、提示されたコンテンツ、番組スポンサー、番組製作者および/または放送ネットワークに参加することに引き入れられ得る。対話型に誘うアイテムは、受信デバイスに送られ、受信デバイス上で実行するアプリケーションによって処理され、ユーザに表示される、信号、命令および/またはデータであり得る。これらの対話型に誘うアイテムは、より多くの情報を求めてディスプレイをクリックすること、コンテンツ中の何らかの態様に関して投票すること、製品詳細をユーザに送らせること、(たとえば、広告された商品のための)購入トランザクションを開始すること、および/または他の参加態様に関与すること、を行うようにユーザを勧誘するコンテンツを受信デバイスに表示させる。たとえば、対話型に誘うアイテムは、可能な対話型アクションのほんのいくつかの例を挙げれば、広告中の製品に関係する追加情報を要求するか、進行中の番組に関係する番組情報を受信するか、その番組に関してコメントするか、または調査に応答するための機会をユーザに提示するために使用され。そのような対話型の態様はユーザの体験を改善し得る。様々な実施形態は、対話型コンテンツをより十分にサポートするために使用され得る、効率的なモバイルマルチメディア放送機構を提供する。
様々な実施形態は、受信デバイス上に対話型コンテンツを提示することをサポートするためのシグナリング機構を提供する。これらのシグナリング機構は、放送事業者が受信デバイスに様々なリソースフローを知らせることを可能にする。受信デバイスは、これらのリソースフローを使用して、TV番組またはコマーシャルなどの視聴されるコンテンツに関係する対話型イベントのためのリソースとシグナリング情報とを取得する。受信デバイスはまた、これらのリソースフローを使用して、特定の視聴されるコンテンツ/チャネルに拘束されていない対話型イベントのためのリソースとシグナリング情報とを取得することを可能にする。放送チャネルを介して対話型イベントファイルを配信し、選択的に受信するために使用され得る好適なシステム、メッセージおよび方法に関する更なる詳細は、本明細書と同時に出願され、本出願の譲受人に譲渡され、その全体が参照により本明細書に組み込まれる、「File Delivery Over A Broadcast Network Using File System Abstraction, Broadcast Schedule Messages And Selective Reception」と題する米国特許出願第13/004,702号(代理人整理番号第101302U1)に記載されている。
様々な実施形態によって提供されるこれらのシグナリング機構は、対話型シグナリングフロー(ISF:interactivity signaling flow)と対話型リソースフロー(IRF:interactivity resource flow)とを含み得る。様々な実施形態では、対話型シグナリングフローは、対話型イベントシグナリングメッセージ(IESM:interactivity event signaling message)を搬送するために使用され、対話型リソースフローは、対話型イベントに関連する対話型リソースを搬送するために使用され得る。一実施形態では、対話型リソースと対話型イベントシグナリングメッセージの両方は、汎用対話型フロー上など、同じフロー上で放送され得る。様々な実施形態では、対話型シグナリングフローと対話型リソースフローは異なるフロー上で搬送されてもよい。他の実施形態では、対話型シグナリングフローと対話型リソースフローは同じフロー上で搬送され得る。
様々な実施形態によって提供されるシグナリング機構はまた、放送事業者が、対話型イベントシグナリングメッセージ(IESM)とリソースとを取得するように、受信デバイスを非放送ソースに向けることを可能にする。様々な実施形態によって開示されるシグナリング機構は、対話型イベント放送システムに、より大きいフレキシビリティと拡張性とを与える。様々な実施形態によって提供されるシグナリング機構はまた、複数のチャネルにわたって共用され得る、複数の対話型シグナリングフローおよび対話型リソースフローの柔軟な使用を可能にする。
対話型イベントを可能にするために、コンテンツプロバイダは、対話型生成システム(IPS:interactivity production system)を使用して、対話型要素を生成し得る。対話型要素は、それらの組合せがモバイルデバイス上に所望の対話型表示を生成するために使用され得る、画像、形状、テキスト、割り当てられたユーザ入力機能、グラフィックス効果、および実行可能命令を含み得る。様々な実施形態は、対話型イベントシグナリングメッセージ(IESM)および/またはファイル配信ストリームの中で、モバイルデバイスにこれらの対話型要素を放送するための機構を提供する。効率を改善するために、様々な実施形態はまた、イベントタイミングに先立って、ファイル配信ストリームを介して、IESMからモバイルデバイスに、これらの対話型要素(たとえば、アプリケーションデータ、リソース[たとえば、画像、グラフィックスなど]およびイベントテンプレート)をアウトオブバンド(out- of -band)で放送するための機構を提供する。これにより、対話型イベントシグナリングメッセージ中にリソース表示を単に含めることによって、放送されたデータが特定され、呼び出されることを可能にする。
対話型イベントが押し迫ってスケジュールされたときなど、いくつかの状況では、アプリケーションデータおよび/またはリソースは、対話型イベントの開始時刻に期間的に極めて近接して(すなわち、数秒前などに)放送される必要があり得る。そのような状況をサポートするために、様々な実施形態は、対話型イベントアプリケーションデータ(IEAD:interactivity event application data)とリソースとテンプレートとを、対話型イベントシグナリングメッセージ(IESM)の一部としてインバンドで放送するための機構を提供する。したがって、様々な実施形態は、コンテンツとリソースとを、インバンドとアウトオブバンドの両方で放送するための機構を提供する。
様々な実施形態では、特定の対話型イベントシグナリングメッセージ(IESM)中で必要とされるデータ量を低減するためにテンプレートが使用される。様々な実施形態では、特定の対話型イベントシグナリングメッセージ中で必要とされるデータは、特定されたテンプレート内の適切な位置にインポートされ得る、テンプレート表示・単純テキストフィールドに低減され得る。様々な実施形態では、あらかじめ定義されたリソースおよびテンプレートは、放送通信システムを介して無線でダウンロードされ、更新され得る。様々な実施形態では、モバイルデバイスは、受信のために、必要とされ、互換性のあるリソースおよびテンプレートのみを選択し得る。これらのテンプレートおよびリソースは複数のITVイベントにわたって共用され得る。
様々な実施形態では、対話型イベントは、特定の放送番組またはコマーシャルの内容の外で示され得る。様々な実施形態では、対話型イベントは、TV番組またはコマーシャルなどの特定の放送コンテンツと同期され得る。対話型イベントを特定の番組および/または広告コンテンツ(たとえば、対話型広告)と同期させるために、様々な実施形態は、シグナリング機構を使用して、対話型イベントが適切な時刻に実装されることを可能にし得る。様々な実施形態では、シグナリングメッセージは、イベントが時刻どおりに受信され、実装されることを保証しながら、帯域幅利用を改善するために、異なる間隔で放送され得る。
様々な実施形態では、対話型イベントは優先度を割り当てられ得る。対話型イベントに優先度を割り当てることは、受信デバイスが、放送事業者、イベントプロバイダまたはコンテンツプロバイダの要望に従って、重複する対話型イベントを実装または無視することを可能にする。様々な実施形態では、シグナリング機構は、対話型イベントがダウンロードされた後に、それらを放送上で更新するかまたは取り消すために使用され得る。様々な実施形態では、対話型イベントは、多種多様な選択およびフィルタ処理基準に基づいて、モバイル受信デバイスおよび/またはユーザの特定の集合に向けられ得る。
上記で説明したように、様々な実施形態では、モバイルデバイスは、受信のため、必要とされ、互換性のあるリソースおよびテンプレートのみを選択するように構成され得る。様々な実施形態では、受信デバイスは、現在視聴されているリアルタイムチャネルに関係する対話型イベントアセット(すなわち、リアルタイムチャネル上で表示されるべき対話型イベントのためのアプリケーションデータおよびリソース)だけを受信するように構成され得る。様々な実施形態では、受信デバイスは、現在視聴されているリアルタイムチャネルに関係する対話型イベントアセット、ならびに1つまたは複数の隣接チャネルに関係するITVイベントアセットを受信するように構成され得る。隣接チャネルは、番組リストまたは番組ガイド内の現在視聴されているチャネルに隣接するチャネルと定義され得る。したがって、様々な実施形態は、現在視聴されているチャネルに関する情報と同時に、隣接チャネルに関する情報を受信することによって、受信デバイスが、デバイス処理とバッテリー電力とを節約することを可能にする。
様々な実施形態によれば、モバイルマルチメディア放送システムは、複数のリアルタイムチャネルを同時に放送し得る。ある状況では、消費者、放送事業者および広告主がますます多くの対話型イベントを要求するので、対話型イベントに対する需要が利用可能な帯域幅を超える可能性がある。そのような増加に適応するために、様々な実施形態は、リアルタイムチャネルごとに専用対話型シグナリングフロー(dedicated interactivity signaling flow (ISF))および対話型リソースフロー(interactivity resource flow (IRF))を放送するための機構を与える。対話型シグナリングイベントおよびリソースを配信することに関連するレイテンシ(待ち時間)を低減するために、様々な実施形態は、複数のシグナリングフローおよびリソースフローを同時に使用するための機構を提供する。
増加に適応することに加えて、様々な実施形態は、使用および需要の突出を管理するための機構を提供する。すなわち、いくつかのネットワーク上で、対話型イベントシグナリングおよびリソース送信に関連する帯域幅の量は、時刻によっておよび日によって変動し得る。したがって、様々な実施形態は、拡張し、使用および需要の突出に適応することができる方法で、受信デバイスに対話型リソースを配信するためのフレキシブルな機構を提供する。
上記で説明したように、様々な実施形態は、受信デバイスに対話型リソースを配信するためのフレキシブルな機構を提供する。様々な実施形態は、スケジュールされる対話型イベントのためのリソースを獲得するために受信デバイスが同調することができる1つまたは複数のリソースファイルデータフロー(RFDF:resource file data flow)を供給することによって、そのようなフレキシビリティに適応するための機構を提供する。様々な実施形態では、これらのリソースファイルデータフローのうちの1つまたは複数は、対話型リソースと関連するフィルタ処理情報とをリストするカタログファイルを搬送し得る。様々な実施形態では、リソースは複数のデータフロー上で放送され得る。たとえば、カタログファイルは、第1のファイルデータフロー上で放送され得、他のリソースは第2のファイルデータフロー上で放送される。
上記で説明したように、様々な実施形態では、リソースおよびカタログファイルは、複数のデータフロー上で放送され得る。複数のフローは、カタログファイルがリソースよりも頻繁に送られる必要があるときに、特に有用である。そのような状況では、受信デバイスは、特定のリアルタイムチャネルに向けられる対話型シーケンスのための対話型リソースをどの放送ファイルデータフローが搬送しているかを決定する方法を必要とする。受信デバイスは、対話型イベントに結び付けられるサービスのためのリソースを獲得するために、この決定を行わなければならない。アンバウンド(unbound:非連結型)対話型イベント(すなわち、特定のリアルタイムチャネルに連結されていない対話型イベント)のためのリソースを獲得するために、受信デバイスはまた、どの放送ファイルデータフローがアンバウンド対話型シーケンスのための対話型リソースを搬送しているかを決定する必要がある。
様々な実施形態では、対話型イベントシグナリングメッセージ(IESM)は、複数のデータフロー上で送られ得る。すなわち、対話型イベントシグナリングメッセージは、スケジュールされる対話型イベントのための対話型シグナリングを獲得するために受信デバイスが同調することができる1つまたは複数の放送シグナリングフロー(BSF:broadcast signaling flow)上で送られ得る。これらの実施形態では、受信デバイスは、どの放送シグナリングフローが特定のリアルタイムチャネルのためにターゲットにされる対話型シーケンスのための対話型シグナリングを搬送しているかを決定する方法を必要とする。受信デバイスは、サービスバウンド(サービス連結型)対話型イベントのためのシグナリングを獲得するために、この決定を行わなければならない。アンバウンド(非連結型)対話型イベント(すなわち、特定のリアルタイムチャネルに連結されていない対話型イベント)のためのシグナリングを獲得するために、受信デバイスはまた、アンバウンド対話型シーケンスのための対話型シグナリングを搬送する放送シグナリングフローを決定する必要がある。
様々な実施形態は、対話型リソースとシグナリング情報とを搬送する放送フローがサービスシステム情報(Service System Information (Service SI))オーバーヘッド情報中で受信デバイスに対して表示され得るような機構を提供することによって、これらの必要に対処する。様々な実施形態はまた、受信デバイスによってフェッチされ得る対話型リソースをホスティングするユニキャスト(特定相手通信)サーバなどの対話型イベントリソースのための非放送ソースを、受信デバイスに知らせることを可能にする。
現在、ワイヤレスアプリケーション配信システムは、概して、モバイルデバイスが各アプリケーションのダウンロードを明確に要求することを必要とする。次いで、各ダウンロード要求は、セルラ電話ネットワークまたはワイドエリアワイヤレスネットワークなどのユニキャストネットワークを通してサーバに通信されなければならない。次いで、アプリケーションサーバは、要求を処理し、モバイルデバイスに対してアプリケーションを費やさなければならない。この処理は著しい処理および帯域幅を必要とするので、現在のワイヤレスアプリケーション配信システムは、多数のデバイスにアプリケーションを同時に配信するには非効率になる。
さらに、現在のワイヤレスアプリケーション配信システムは、概して、モバイルデバイスが、ダウンロードのために利用可能なすべてのアプリケーションの存在を知らされることと、特定のアプリケーションごとに必要性を決定するように(ソフトウェアによって)構成されることと、適切なファイルがダウンロードされることを明確に要求することとを必要とする。これも著しい帯域幅を必要とし、現在のワイヤレスアプリケーション配信システムの非効率にさらに寄与する。その結果、現在のワイヤレスアプリケーション配信システムは、高い需要があり、時間的に厳しいアプリケーションを、多数の受信側に同時に配信するには有効でない。時間的に厳しいアプリケーションは、保証されたおよび/または特定の時刻にモバイルデバイス上にあることが必要とされるアプリケーションである。時間的に厳しいアプリケーションを配信する能力は、ユーザ対話型をサポートするアプリケーション配信システムにおける重要な特徴である。
様々な実施形態は、将来放送されることになる番組およびコンテンツに関する情報を放送することによって、モバイル受信デバイスが自己収納式であることを可能にする。この情報は、メタデータとコンテンツフローに関するオーバーヘッド情報とを搬送することに専用の放送送信ストリームの一部分を通して放送される。この部分は、コンテンツ(本明細書では、「コンテンツフロー」または「放送ストリーム」と呼ぶ)を搬送する放送送信の部分とは別である。コンテンツに関する情報、すなわち「メタデータ」は、モバイルデバイスが選択されるコンテンツをどのように、いつ受信すべきかを発見することを可能にする。
本出願において開示される様々な実施形態はまた、時間的に厳しいアプリケーションのより効率的な配信を可能にする。特に、様々な実施形態は、MediaFLO(登録商標)ネットワークなどのモバイルマルチメディア放送ネットワークの高帯域を使用して、現在のワイヤレスアプリケーション配信システムよりもはるかに効率的にアプリケーションを配信する。実施形態は、ファイル配信サービスのために使用される帯域幅の部分など、利用可能な帯域幅の一部分のみを介して、モバイルマルチメディア放送ネットワークが、受信デバイスにアプリケーションを「押し出す(push)」ことを可能にする。
様々な実施形態は、コンテンツプロバイダが、放送システム内のアプリケーションサーバに(アプリケーションを構成する)ファイルとメタデータとを配信することを可能にする。放送システムは、放送のためにアプリケーションを組み立て(アセンブルし)、パッケージングし得る。放送の準備ができているアプリケーションは、電子カタログにリストされ得る。第1の放送ステップにおいて、カタログが、放送オーバーヘッドストリームの一部として受信デバイスに放送され得る。次いで、第2の放送ステップにおいて、ファイル配信システムに関係する電子サービスガイドまたはオーバーヘッドシグナリング中に示された時刻に、アプリケーション自体が、モバイルマルチメディア放送ネットワークによって放送され得る。この2ステップ処理により、受信デバイスは、モバイルマルチメディア放送ネットワークの高帯域を介して関係するアプリケーションを選択的に受信することが可能になる。また、これにより、アプリケーションが多数のデバイスにより効率的に同時に配信されることが可能になる。
受信デバイスでは、カタログ中のアプリケーションのリストは、受信デバイスに互換性(たとえば、モデル互換性)があり、該受信デバイスに向けられ(たとえば、ターゲット先選択基準に基づいて)、ユーザによる受信のために表示され(たとえば、電子サービスガイドから選択を行うユーザによって)、および/またはいくつかのユーザの好み、ユーザ人口統計、または他のユーザ特有のターゲッティング基準に一致するような、それらのアプリケーションを選択するために視聴またはフィルタ処理され得る。選択されるアプリケーションは、カタログまたはオーバーヘッドシグナリングによって指定される放送時刻に受信され、メモリに格納され得る。メモリに格納される、受信されたアプリケーションが起動のために選択されるまで、アプリケーションマネージャモジュールは、それらのアプリケーションを追跡し得る。アプリケーションは、いくつかの起動信号または基準に基づいて起動のために選択され得る。起動信号および/または起動基準の使用は、アプリケーションのタイムリーな配信および実行を可能にし、アプリケーションが起動および/または実行されるべき厳密な時刻を、放送事業者が制御することを可能にする。
様々な実施形態では、アプリケーションは、リアルタイム放送ストリームの中で信号を受信したことに応答して起動され得る。その信号を使用して、対話型イベントを与えるためになど、アプリケーションの起動をメディア番組(たとえば、TV番組またはコマーシャル)中のイベントと同期させ得る。受信した放送信号に基づいてアプリケーションを起動する機能は、放送番組と同期して、ダウンロードされたアプリケーションを起動することを可能にするので、アプリケーションは、放送番組中の特定の時刻に立ち上げられるように作成され得る。これは、モバイルデバイスユーザに、変わった表示効果を生じること、ユーザに番組と対話する能力を与えること、またはユーザが番組中で特集された商品を購入することを可能にすることなど、拡張された視聴の選択肢を提示するために使用され得る。これは、放送事業者が、何のアプリケーションがユーザに提示されるかを制御することを可能にし、ユーザが、特定の番組のコンテンツに関係するアプリケーションのみを視聴することを可能にする。また、これは、ユーザ対話型をサポートするようにアプリケーションが作成されることを可能にする。
一実施形態では、アプリケーションは、起動後に自己削除するように構成され、ワンタイム専用メディア同期アプリケーション(one-time only media synchronized application)を可能にする。一実施形態では、アプリケーションは、時刻、地理的位置(たとえば、GPS受信によって検出される)、動作状態、イベントのシーケンスなど、受信デバイス内の状態またはイベントに応答して起動され得る。一実施形態では、ユーザは、ディスプレイを介して1つまたは複数のアプリケーションの受信を知らされ、アプリケーションが起動されるべきかどうかを示すように促され得る。この場合、受信したアプリケーションは、ユーザ入力に応答して起動され得る。たとえば、ユーザがアプリケーションを起動することを選択した場合、アプリケーションマネージャはアプリケーションのインスタンシエーション(instantiation: オブジェクトの作成)を開始し得る。ユーザがアプリケーションを起動しないことを選択した場合、ファイルは起動されることなく、メモリから削除され得る。
様々な実施形態では、コンテンツプロバイダは、特定のアプリケーションロジック、アセット、リソース、およびメタデータファイルを作成することによって、対話型アプリケーションを作成することができる。アプリケーションロジックおよびリソースファイルは、特定のフォーマットのために組み合わされ、パッケージングされ得る。たとえば、Flash実行可能アプリケーションでは、コンテンツプロバイダは、関連するアプリケーションアセットをもつMXMLコードを、Shockwave Flashフォーマットのファイル(Shockwave Flash formatted file (SWF))にコンパイルし得る。メタデータファイルは、システムに関する情報ならびにユーザ要件を含み得る。ユーザ要件は、特定のモバイルデバイス上で実行中のアプリケーションのための好みおよび/または特権のリストを含み得る。たとえば、コンテンツプロバイダは、受信デバイスへのアプリケーションの配信をサポートする情報を含む、提示されたアプリケーションをもつXMLファイルを与え得る。XMLファイルはまた、システムに関する情報(たとえば、サポートされるモバイルデバイス)および/またはユーザ要件(たとえば、18歳超の加入者)を含み得る。
様々な実施形態では、モバイルデバイスへの放送のために、コンテンツプロバイダは、それらのアプリケーションを、ワイヤレス放送配信システム(たとえば、MediaFLO(登録商標)システム)に提供し得る。コンテンツプロバイダはまた、各アプリケーションがモバイルデバイス宛に押し出されるべき特定のスケジュールまたは時刻を特定し得る。コンテンツプロバイダはまた、各アプリケーション放送のためのサービス品質(Quality of Service (QoS))を要求し得る。QoSは、(たとえば、アプリケーションタイプに基づいて)コンテンツプロバイダと放送システムとの間で事前に取り決められ得る。アプリケーション配信のための課金態様は、放送チャネル上のアプリケーション配信によって与えられるQoSレベルに基づき得られる。
ワイヤレス放送システムは、ネゴシエートされたQoSに基づいてアプリケーションを空中線上(over-the-air (OTA))で配信し得る。アプリケーションを空中線で配信するために、コンテンツは、コンテンツタイプアグノスティックフォーマットでパッケージングされ、放送のために符号化され、ワイヤレス放送システムを通して送られ得る。OTAで放送されることになるアプリケーションは、オーバーヘッド放送ストリーム中でモバイルデバイスに放送されるカタログの中で事前に広告され得る。様々な実施形態では、1つまたは複数のアプリケーションカタログファイルが生成され、同時に放送され得る。たとえば、一実施形態では、放送システムは、放送ネットワーク中の各キャリアのために1つまたは複数のアプリケーションカタログファイルを生成し、放送し得る。
カタログは、モバイルデバイスが将来放送されることになるアプリケーションの集合を見つけることを可能にする。これは、どのアプリケーションが選択的受信によるダウンロードのために利用可能になるかを、モバイルデバイスが決定することを可能にする。様々な実施形態では、カタログは放送システムによって周期的に放送され得る。そのような場合、カタログは、将来放送されることになるアプリケーションおよび関連するリソースのリストを含み得る。各アプリケーションとリソースとが受信され得る放送時刻および放送フローは、ファイル配信オーバーヘッドフロー中に含まれ得る。放送されることになるアプリケーションは、サービスに関連付けられ得る(サービスバウンド(連結型)アプリケーション)か、またはサービスとは無関係であり得る(アンバウンド(非連結型)アプリケーション)。モバイルデバイスは、それらの加入サービスに関連するアプリケーションならびにアンバウンドアプリケーションの両方を選択的にダウンロードし得る(すなわち、選択的に受信し、格納し得る)。
カタログはまた、フィルタ処理基準を指定し得る。モバイルデバイスは、フィルタ処理基準を使用して、受信されるべきアプリケーションを選択し得る。そのようなフィルタ処理基準の例には、たとえば、特定のデバイスタイプまたはデバイスプロファイルに向けられるアプリケーション(たとえば、iPhoneデバイスに向けられたアプリケーション)、および特定のユーザ(たとえば、特定のサービスへの加入者)あるいはユーザのタイプまたはカテゴリー(たとえば、特定の人口統計学的カテゴリー)に向けられたアプリケーションがある。たとえば、アプリケーションは、18歳から25歳の間の英語を話す人に向けられ、その場合、ユーザがこの人口統計学的カテゴリーに一致するモバイルデバイスのみが、アプリケーション放送を受信することを選択し、そのアプリケーションをメモリに格納する。
様々な実施形態では、モバイルデバイスは、放送システムから、加入状況ごとにおよび/またはフィルタ処理基準に基づいてなど、モバイルデバイスに適用可能であるアプリケーションのみを選択的に受信し得る。パッケージがモバイルデバイスによって受信された後、デバイスプロセッサ中で動作するアプリケーションマネージャは、アプリケーションの完全性を検証し得る。アプリケーションマネージャは、すべての外部リソースおよびアセットがモバイルデバイスによって受信され、メモリ中で利用可能であることを確認し得る。アプリケーションマネージャは、すべての必要なリソースが存在することを検証した後、新しいアプリケーションが利用可能であることをユーザに通知し得る。この通知は、MediaFLOユーザインターフェースなどのユーザインターフェース(UI)を介して、またはユーザにとって利用可能な他の通知方法によって通信され得る。
将来の時点において、ユーザの要求時にまたはトリガリングシステムイベントによって(たとえば、OTAで放送される対話型シグナリングイベントに基づいて)、アプリケーションは呼び出され、立ち上げられ得る。このとき、UIは、アプリケーションマネージャから、実行可能ファイルとメタデータとアセットURLとを要求し得る。これらのファイルをUIに与えることに加えて、アプリケーションマネージャはまた、放送システムから受信され、アプリケーションのために標的とされた対話型イベントシグナリングデータを渡し得る。UIは、メタデータを使用して、アプリケーションのためにどのレンダリングコンテナを使用すべきかを決定し得る。たとえば、アプリケーションがHTML/JS/CSSアプリケーションである場合、アプリケーションを実行するために、WebKitエンジンコンテナが使用され得る。別の例として、アプリケーションがswf−x−application mimeタイプである場合、Flashプレーヤが使用され得る。一実施形態では、アプリケーションは、それが、ある時刻にまたは実行後に非起動され、および/またはモバイルデバイスから完全に削除され得ることを示してもよい(すなわち、ワンタイムアプリケーション)。
様々な実施形態は、MediaFLO(登録商標)ネットワークなどのモバイルマルチメディア放送ネットワークにおいて使用するための対話型イベントアプリケーションの自動生成と配信とを可能にする。実施形態は、放送ネットワークのサーバ上でまたは受信デバイス自体の中で対話型イベントアプリケーションの生成を達成させることによって、対話型イベントプロバイダが新しい対話型イベントを効率的に生成することを可能にする。対話型イベントプロバイダは、イベント構成要素(たとえば、対話型イベントアプリケーションデータ、イベント関係情報およびシーケンスロジック)を生成し、それらを、好適な放送フォーマットへの対話型イベント情報の適応を行う対話型生成システムまたは対話型ゲートウェイに与え得る。
対話型アプリケーションジェネレータは、対話型イベント情報を使用して、対話型アプリケーションを生成し得る。様々な実施形態では、対話型アプリケーションジェネレータは、放送ヘッドエンド内のサーバにおいて、または受信デバイス自体の中にホスティングされ得る。対話型アプリケーションジェネレータが放送システムのサーバ内にホスティングされる場合、多種多様なターゲット先受信デバイスをサポートするために、複数の対話型アプリケーションが適宜に生成され得る。そのようなアプリケーションは、受信デバイスが対話型アプリケーションの適合バージョンを選択的に受信することができるように、アプリケーションのメタデータ中で特定され得る。対話型アプリケーションメタデータは、対話型カタログファイル中で与えられ得る。対話型アプリケーションジェネレータが受信デバイス内にホスティングされるとき、その受信デバイスに好適なタイプの対話型アプリケーションのみが生成され得る。
対話型アプリケーションジェネレータが放送システムのサーバ内にホスティングされるとき、モバイルマルチメディア放送ネットワークは、ファイル配信サービスのために利用可能な帯域幅など、帯域幅の一部分を介して受信デバイスに対し、生成された対話型イベントアプリケーションを放送し得る。対話型アプリケーションジェネレータがモバイルデバイス内でホスティングされるとき、対話型イベント情報およびリソースは、モバイルマルチメディア放送ネットワークによって放送され得る。放送の準備ができている対話型イベントアプリケーションおよび対話型イベントメタデータは、放送バーヘッドストリームの一部として受信デバイスに放送される電子カタログの中にリストされ得る。上記で説明したように、受信デバイスでは、電子カタログ中の対話型イベントアプリケーションのリストは、受信デバイスに関係し(たとえば、視聴されたチャネルに関係し、デバイスモデルに適合し)、受信デバイスに向けられ(たとえば、ターゲット先選択基準に基づいて)、ユーザによる受信のために示され(たとえば、ユーザが電子サービスガイドから選択を行うことによって)、および/または、いくつかのユーザの好み、ユーザ人口統計、または他のユーザ特有のターゲッティング基準に一致する、というような対話型イベントアプリケーションを選択するために、視聴またはフィルタ処理され得る。
実施形態では、コンテンツプロバイダは、アプリケーションを構成する、特定のアプリケーションロジック、アセット、リソース、およびメタデータファイルとを作成することによって対話型イベントアプリケーションを作成することができる。上記で説明したように、アプリケーションロジックおよびリソースファイルは、特定のフォーマットのためにパッケージに組み合わされ、メタデータは、モバイルデバイス上でそのようなアプリケーションを実行するためのシステムに関する情報とユーザ要件とを含み得る。コンテンツプロバイダはまた、受信デバイスへのアプリケーションの配信をサポートするメタデータを含む、提供されるアプリケーションをもつXMLファイルを与え得る。コンテンツプロバイダは、対話型イベントの生成および受信デバイスへの関連する対話型アプリケーションの放送のため、対話型イベントアプリケーションを構成するコンテンツ要素を、ワイヤレス放送配信システム(たとえば、MediaFLO(登録商標)システム)に提供し得る。
様々な実施形態は、図1Aにその一例を示す、様々なモバイルマルチメディア放送システム内に実装され得る。MediaFLO(登録商標)放送ネットワークなどのモバイルマルチメディア放送ネットワーク1は、一般に、本明細書では放送ペレーションセンター4(または図では「BOC」)と呼ばれるモバイル放送ネットワーク制御センターによって制御される、複数の放送送信機2を含む。放送ネットワーク1は、放送送信機2から、モバイルテレビジョン受信、スマートフォン、セルラ電話、携帯情報端末(PDA)、対話型ゲームデバイス、ノートブック、スマートブック、ネットブック、データ処理装置、または他のそのような電子デバイスなどの受信デバイス10による受信のために、モバイル放送送信3としてコンテンツを放送する。モバイル放送ネットワーク制御センター4(放送ペレーションセンターまたは「BOC (broadcast operation center)」とも呼ばれる)内には、コンテンツ放送のスケジューリングと、コンテンツ放送に関する電子サービスガイド、カタログメッセージ、および放送スケジューリングメッセージの生成と、マルチメディア放送ネットワーク1のオーバーヘッドフローを介した放送のためのメタデータメッセージの生成とを管理するように構成され得る、1つまたは複数のサーバ6がある。
様々な実施形態では、1つまたは複数のコンテンツマネージャサーバ6はまた、コンテンツマネージャサーバ6がコンテンツプロバイダサーバ8からコンテンツ供給を受信し得るための、インターネット7などの外部ネットワークへの接続を含み得る。様々な実施形態では、1つまたは複数のサーバ6は、コンテンツプロバイダサーバ8からコンテンツを受信し、メタデータ中に含まれる受信されたコンテンツに関する情報を決定し、コンテンツバッチでのコンテンツの放送のためのスケジュールを決定し、受信デバイス10への放送のための電子サービスガイド(ESG:electronic service guide)と他のオーバーヘッドフローとを生成するように構成され得る。
通常のコンテンツ配信システムに加えて、モバイル放送ネットワーク1はまた、モバイル放送ネットワーク1を介した放送のために対話型イベントを管理するための対話型サーバ5を含み得る。典型的な実装形態では、対話型サーバ5は、直接ネットワーク接続、またはインターネット7などの間接的ネットワーク接続のいずれかを介して、対話型生成システムサーバ9から対話型イベントのための要素を受信し得る。対話型生成システムサーバ9における対話型イベントの生成は、コンテンツプロバイダサーバ8から受信されたコンテンツによってまたはそれに基づいて制御され得る。
モバイルマルチメディア放送ネットワーク1Aに加えて、受信デバイス10はまた、セルラ電話ネットワークなどのユニキャスト(特定相手通信)ネットワーク11を介して通信するように構成され得る。典型的なセルラ電話ネットワークは、固定電話線(たとえば、POTSネットワーク、図示せず)やインターネット7などを介して、モバイルデバイス10と他のネットワーク宛先との間の音声およびデータ呼を接続するように動作する、ネットワーク運用センター14につながった複数のセルラ基地局12を含む。モバイル受信デバイス10とユニキャストネットワーク11との間の通信は、3G、CDMA、WCDMA、GSM(登録商標)、TDMA、および他のセルラ電話通信技術などの対話型ワイヤレス通信リンク13を介して達成される。インターネットデータ通信を可能にするために、ユニキャストネットワーク11は、一般に、インターネット7への接続を与えるネットワーク運用センター14につながったまたはその内部にある1つまたは複数のサーバ16を単独で含む。さらなる実施形態では、ユニキャストネットワーク11は、WiFi、WiMAXなどのワイヤレス広域ネットワークであり得る。モバイル受信デバイス10は、ユーザ対話メッセージを放送事業者に送信する放送サービスに加入するために、インターネット7を経由した放送ネットワークサーバ6へのIPデータ呼を介してなど、ユニキャストネットワーク11を介して放送ネットワーク1と通信し得る。
様々な実施形態および実装形態では、対話型イベントをもちいたユーザ対話により、放送サービスプロバイダ、コンテンツプロバイダまたは対話型コンテンツプロバイダにメッセージが返信される結果になる。ユーザ投票、商品注文、サービス要求、調査応答などを伝達し得るそのような応答メッセージは、IPデータ呼、電子メール、シンプルメッセージサービス(simple message service (SMS))、マルチメディアメッセージサービス(multimedia message service))、ならびにワイヤレスインターネットアクセス・メッセージングなど、ユニキャストネットワーク11によってサポートされる任意のデータ伝送プロトコルを介して送信され得る。
図1Bに、一実施形態による放送ネットワーク1内の情報フローを示す。上述のように、放送ネットワーク1は、いくつかのコンテンツプロバイダサーバ8からコンテンツ(たとえば、テレビ番組、ウェブサイト、シリアルデータ供給など)を受信し得る。様々な実施形態では、コンテンツプロバイダサーバ8は、このコンテンツを、データネットワーク20(たとえば、インターネット7)を介してコンテンツマネージャサーバ6に送りる。コンテンツマネージャサーバ6は、将来の放送のために、受信されるコンテンツをスケジュールし、そのコンテンツをデータベースに格納し得る。コンテンツマネージャサーバ6はまた、コンテンツデータ22およびコンテンツ情報24を放送ペレーションセンター4に与え得る。放送ペレーションセンター4は、メディアロジックチャネル(media logical channel (MLC))26とオーバーヘッド情報サービス(overhead information service (OIS))チャネル28とを含む情報の多重(multiplex)として放送信号を生成し得る。受信デバイス10は、その多重を受信し、その中に含まれている情報を解析し得る。様々な実施形態では、受信デバイス10は、オーバーヘッド情報サービスチャネル28および他のオーバーヘッド情報ストリーム(たとえば、制御チャネル)を個別に受信し、その情報を使用して、特定のメディアロジックチャネル26を受信する。
様々な実施形態では、情報は、複数のスーパーフレームに編成されたワイヤレス信号中で送信され得る。各スーパーフレームは、周波数帯域内および設定時間境界内の周波数および時間において、符号化された信号を備える。各スーパーフレーム内の符号化信号は、選択されたコンテンツを受信するために受信デバイス10によって使用されるオーバーヘッド情報とともに、放送コンテンツを通信する複数のデータパケットを符号化する。たとえば、MediaFLO(登録商標)放送システムでは、放送送信は、6MHz周波数帯域(たとえば、716MHz〜722MHz)にわたる1秒スーパーフレームに編成され得る。MediaFLO(登録商標)放送信号は他の周波数帯域上で送られ得、複数の信号は、複数の別個の周波数帯域を使用することによって同時に送られ得る。各スーパーフレームは、オーバーヘッドフローに専用の部分と、コンテンツフローに関連する複数のチャネルを搬送する部分とを含む。オーバーヘッドフローおよび他のオーバーヘッドストリーム(たとえば、制御チャネル)内の情報は、その特定のコンテンツフローがスーパーフレーム内のどこで取得され得るか、ならびにどのくらいの数のパケットがそのコンテンツフローのMLCに関連するかを受信デバイスに知らせる。
図1Cは、対話型(ITV)イベントと、関連するシグナリングメッセージと、対話型リソースと、テンプレートとを生成し、配信するための様々な実施形態を実装するのに好適な放送通信システムの放送事業者側のシステム機能構成要素(コンポーネント)を示す。リアルタイム(実時間)コンテンツプロバイダサーバ8は、リアルタイムコンテンツ(たとえば、オーディオ、ビデオ、テキストなど)を放送ペレーションセンター(BOC)4に送る。様々な実施形態では、放送ペレーションセンター4は、広告挿入システム32を使用して、指定さる広告スロットの間に、コンテンツ中にリニア広告を挿入し得る。広告挿入システム32はBOC4内のサーバ上でホスティングされ得る。リアルタイムコンテンツおよび挿入されたリニア広告は、同じくBOC4内のサーバ上でホスティングされ得るリアルタイムエンコーダ34によって符号化され得る。次いで、符号化されたリアルタイムコンテンツおよび広告は、放送ネットワーク1を介して送信される。様々な実施形態では、広告挿入システム32はまた、以下でより詳細に説明するように、対話型生成システムサーバ9に、広告スロットと同期して再生される必要がある対話型イベントに関する同期タイミング情報(破線矢印によって示される)を与え得る。
様々な実施形態では、広告挿入システム32およびリアルタイムエンコーダ34は、それぞれ、放送ペレーションセンター4の中の異なるサーバ上にホスティングされてもよい。様々な実施形態では、広告挿入システム32およびリアルタイムエンコーダ34は、放送ペレーションセンター4の中の同じサーバ上にホスティングされてもよい。一実施形態では、広告挿入システム32およびリアルタイムエンコーダ34は、図1Cに示すように、放送ペレーションセンター4の外部にホスティングされてもよい。
対話型コンテンツプロバイダ30は、対話型生成システムサーバ9に対話型コンテンツを対話型シーケンスの形態で供給し得る。対話型コンテンツプロバイダ30は、リアルタイムコンテンツプロバイダサーバ8と同じでも、または異なってもよい。対話型生成システム9において生成された対話型イベント情報(IEI:interactivity event information)は、BOC4内の対話型サーバ5に与えられる。対話型イベント情報は、ユーザに表示される情報の集合、特定のユーザ入力/アクション(操作)に関連するアクション(動作)または機能、画像および表示フォーマット情報、ビデオシーケンスファイル、関連する対話型アセット、ユーザ応答の宛先となるURL、および所望の対話型表示を生成するために受信デバイスにとって有用な他のデータ、などの対話型イベントアプリケーションデータ(interactivity event application data (IEAD))を含み得る。対話型アプリケーションデータは、例えば、SMSを介して、ユニキャスト(IP)を介して、電話通話を介して、またはウェブを介してなど、複数の選択肢を使用して与えられる、ユーザ入力のための情報を含み得る。対話型イベント情報はまた、例えば、イベント開始時刻、および、有効性持続時間/終了時刻(すなわち、対話型イベントがユーザに表示されるために、開始時刻からどのくらい有効であるか、または、対話型イベントが満了し、ユーザにもはや表示されるべきでない時刻)、対話型イベントが現れる、対象とされるリアルタイムコンテンツフローまたはメディアサービス、対象とされる対話型アプリケーション、受信デバイスタイプの対象とされる集合、対象とされるサービスキャリア(たとえば、Verizon、AT&T、など)、ならびに関連するかまたは必要なリソースおよびテンプレートの表示、といった対話型イベントメタデータを含み得る。
対話型コンテンツに加えて、対話型コンテンツプロバイダ30はまた、対話型生成システムサーバ9に追加の情報ユニットを与えてもよい。リアルタイム番組(たとえば、TV番組、または、TV番組内の広告スロット内の)と同期して再生される必要がある対話型イベントでは、対話型コンテンツプロバイダ30は、対話型イベント表示開始時刻、または対象とされるリアルタイムコンテンツにイベントを同期させるために有用な他のデータを与え得る。
対話型生成システムは、対話型イベントシーケンスに関連する対話型イベントデータを、対話型ゲートウェイ42に送り得る。対話型ゲートウェイ42は、受信した対話型イベント情報を、放送に好適なフォーマットに適応させ得る。対話型イベントゲートウェイ42は、受信した対話型イベント情報を使用して、1つまたは複数の対話型アプリケーションを動的に生成するために、対話型アプリケーションジェネレータ44とインターフェースし得る。以下でより十分に説明するように、対話型アプリケーションジェネレータ44は、1つまたは複数の対話型イベントアプリケーションをアセンブルする(組み立てる)ために、対話型コンテンツプロバイダ30によって与えられたシーケンスおよびイベント情報を使用して、対話型イベントアプリケーションを動的に生成し得る。場合によっては、対象とされるデバイスが様々なタイプのアプリケーションをサポートする場合、単一の対話型イベントのために、複数の対話型イベントアプリケーションが生成され得る。たとえば、所与の対話型イベントのために、Flash実行可能アプリケーション(Shockwave Flashフォーマットのファイル(SWF))である第1の対話型アプリケーションが生成され、webアプリケーション(HTML5アプリケーション)である第2の対話型イベントアプリケーションが生成され得る。この例では、両方のタイプの対話型イベントアプリケーションが放送され、受信デバイスは互換性のある対話型アプリケーションを選択的に受信することになる。この動作の一部として、対話型サーバは、対話型イベントが表示されるべきリアルタイムサービスに係る、エンドツーエンド(端から端まで)の放送システムレイテンシ(待ち時間)に基づいて、対話型イベント開始時刻を調整し得る。生成された対話型アプリケーションは、対話型ゲートウェイ42に返信され得、対話型ゲートウェイ42はその対話型アプリケーションを対話型放送サーバ5に与える。別の実施形態では、対話型ゲートウェイ42は、対話型要素情報を含む対話型イベントアプリケーションデータを生成し得る(たとえば、対話型アプリケーションデータは、対話型ゲートウェイによってXMLフォーマットで生成され得る)。様々な実施形態では、対話型ゲートウェイ42は、モバイルデバイスへの放送のために、生成された対話型イベントアプリケーションデータを、対話型放送サーバ5に与える。
対話型放送サーバ5は、放送ネットワーク1を介したアウトオブバンドでの送信のために、必要な対話型イベントアプリケーションデータ(interactivity event application data (IEAD))、リソースとテンプレートと(すなわち、受信デバイスが対話型イベントを生成するために必要とする、データとリソースとテンプレート)を、ファイル配信システム38に与え得る。様々な実施形態では、ファイル配信システム38は、ファイル配信送信ストリームの中で、対話型イベントアプリケーションデータ、リソース、およびテンプレートを送信し得る。一実施形態では、対話型イベントアプリケーションデータ、リソースおよびテンプレートは、他のタイプのファイルを送信するために使用される従来のファイル配信送信システムと類似であるファイル配信送信ストリーム上で送信され得る。
様々な実施形態では、対話型サーバ5は、ファイル配信システム38が、リソースとテンプレートとを、イベント開始時刻より前に受信デバイス10上で獲得され得るように放送することを要求するために、イベントタイミング情報を使用し得る。一実施形態では、対話型イベントアプリケーションデータ(IEAD)およびリソースは、放送帯域幅を節約するために、イベント開始時刻よりわずか前に(たとえば、イベント開始時刻の数秒または数分前に)放送され得る。
様々な実施形態では、対話型サーバ5を使用して、対話型イベントシグナリングメッセージ(interactivity event signaling messages (IESM))を生成し得る。これらの生成された対話型イベントシグナリングメッセージは、放送ネットワーク1を介したオーバーヘッド情報フローによる送信のためにオーバーヘッドデータ配信システム36に与えられ得る。一実施形態では、対話型サーバ5は、放送帯域幅を節約するために、イベント開始時刻よりわずか前に(たとえば、イベント開始時刻の5〜10秒前に)IESMを放送するよう、オーバーヘッドデータ配信システム36に要求し得る。様々な実施形態では、対話型サーバ5は、対話型イベントアプリケーションデータ(IEAD)とリソースとを、対話型イベントシグナリングメッセージ(IESM)の一部として、インバンドで送信し得る。上記で説明したように、対話型イベントが押し迫ってスケジュールされているときなど、ファイル配信システム上でデータとリソースとをアウトオブバンドで放送するのに十分な時間がないとき、インバンドでデータを送信することが有用である。
様々な実施形態では、オペレータ33は、供給(provisioning)システム35を使用して、リアルタイムチャネルおよび/またはサービスと、対話型イベントシグナリングを搬送するシグナリングフローとの間の関連付けを特定し得る。オペレータ33は、複数のリアルタイムチャネルが所与のシグナリングフローを共用するかどうか、または、別々のシグナリングフローが各リアルタイムチャネルのための対話型シグナリングを配信するために使用されるべきかどうか、を特定指定し得る。一実施形態では、オペレータ33は、アンバウンド対話型イベントを搬送するためのシグナリングフローを特定指定し得る。供給システム35は、対話型シグナリングが、放送ネットワーク1によって放送される適切なシグナリングフロー上で配信され得るように、この関連付けを、オーバーヘッドデータ配信システム36に与える。
様々な実施形態では、オペレータ33は、供給システム35を使用して、リアルタイムチャネルおよび/またはサービスと、対話型リソースを搬送するリソースフローとの間の関連付けを特定し得る。オペレータ33は、複数のリアルタイムチャネルが所与のリソースフローを共用するかどうか、または、別々のリソースフローが各リアルタイムチャネルのための対話型リソースを配信するために使用されるべきかどうか、を指定し得る。一実施形態では、オペレータ33は、アンバウンド対話型イベントを搬送するためのリソースフローを指定し得る。供給システム35は、対話型リソースが、放送ネットワーク1によって放送される適切なリソースフロー上で配信され得るように、この関連付けをファイル配信システム38に与える。
上記で説明したように、供給システム35は、リアルタイムチャネルおよび/またはサービスと、対話型シグナリングおよびリソースを搬送するシグナリングフローおよびリソースフローとの間の関連付けを特定するために使用され得る。供給システム35はまた、放送ネットワーク1を介した配信のためにオーバーヘッドデータ配信システム36に与えられるサービスシステム情報(Service System Information (Service SI): サービスSI)メッセージを生成するために使用される。これらのサービスSIメッセージは、受信デバイスに、どのリソースファイルデータフロー(resource file data flows (RFDF))およびシグナリングフローが対話型イベントのためのリソースおよびシグナリングを含んでいるかを決定することが可能にする。たとえば、サービスSIメッセージは、各リアルタイムチャネルのための対話型情報を搬送するシグナリングフローおよびファイルデータフロー上の情報を含み得る。一実施形態では、対話型リソースは、対話型ユニキャストサーバ39などの非放送ソースから取得され得る。一実施形態では、対話型ユニキャストサーバ39は、3Gセルラネットワークなどのワイヤレスユニキャストネットワーク37を介してアクセスされ得る。
図1Dは、本発明の複数の実施形態による、受信デバイスにアプリケーションを放送するのに好適な通信システム100の別の例を示す。コンテンツプロバイダ102は、受信デバイスにダウンロードされ得るアプリケーションを放送システムに与え得る。図1Dは、複数のコンテンツプロバイダ112、114、116がそれぞれ、アプリケーションコンテンツを生成し、アプリケーションデータ、実行可能スクリプト、およびアセット(たとえば、画像、ビデオクリップ、グラフィカルスクリーン、XMLスクリプトなど)を作成し得ることを示す。コンテンツプロバイダ112、114、116は、これらのファイルを、一緒に、アプリケーションパッケージ118、120、122の中にバンドル(詰め込み)し得る。アプリケーションパッケージ118、120、122は、放送ネットワーク104内のアプリケーションサーバ130に送信され得る。アプリケーションサーバ130は、配信のために利用可能なアプリケーションのリストを維持し、各特定のアプリケーションに関係する追加のメタデータを格納し得る。アプリケーションサーバ130は、フォーマットに基づいてアプリケーションをパッケージングし得る。アプリケーションサーバ130はまた、アプリケーションを所望のフォーマットにパッケージングし得る。
一実施形態では、コンテンツプロバイダ112、114、116は、放送ネットワーク104にスケジューリング情報を与え得る。たとえば、図1Dは、コンテンツプロバイダ116が、スケジューラサーバ132にスケジューリングデータを与えて、アプリケーションが将来の特定の時刻に受信デバイス106、107、108に押し出されることを可能することを示す。したがって、コンテンツプロバイダ116は、特定のアプリケーションと放送コンテンツとの同期に寄与し、それに対する制御を有し得る。
放送ネットワーク104内の同期エージェントサーバ134は、スケジュールに基づいてアプリケーションパッケージの放送を制御し得る。たとえば、アプリケーションパッケージは、夜遅くになど、帯域利用率が低いときに放送されるようにスケジュールされ得る。アプリケーションパッケージはまた、コンテンツプロバイダ116によって与えられたスケジューリングデータによって指定された時刻など、特定の時刻に放送されるようにスケジュールされ得る。
周期的に、同期エージェントサーバ134は、放送のためのアプリケーションパッケージを、アプリケーションサーバ130に要求し得る(矢印136)。アプリケーションサーバ130は、要求されたアプリケーションパッケージを、同期エージェントサーバ134に返信する(矢印138)。同期エージェントサーバ134は、アプリケーションパッケージを符号化サーバ150に渡す(矢印154)。符号化サーバ150は、ワイヤレス放送ネットワーク152上での放送のために、パッケージを適切なフォーマットに符号化する。
同期エージェントサーバ134はまた、スケジューラサーバ132から受信されたトリガ140に基づいて、受信したアプリケーションを放送するための時刻を決定し得る。スケジューラサーバ132は、コンテンツプロバイダ116のうちの1つまたは複数によって指定された放送スケジュールに基づいてトリガ140を送り得る。同期エージェントサーバ134はまた、放送制御サーバ142によって与えられたリアルタイム放送ステータストリガ144に基づいて、アプリケーションを放送するための時刻を決定し得る。リアルタイム放送ステータストリガ144は、アプリケーションが起動されるべきビデオストリーム146内の時刻(またはタイムスロット)を示し得る。
様々な実施形態では、放送ネットワーク104は、同期メタデータ148を放送し得る。同期メタデータ148は、受信デバイス106、107、108上のアプリケーションパッケージを、ビデオストリーム146と同期する状態で、起動することを可能にする。この能力をサポートするために、放送制御サーバ142は、前に放送されたアプリケーションが起動されるべきビデオストリーム146内の時刻(またはタイムスロット)を示すリアルタイム放送ステータストリガ144を、同期エージェントサーバ134に与え得る。リアルタイム放送ステータストリガ144を受信したことに応答して、同期エージェントサーバ134は、符号化サーバ150においてアプリケーションパッケージを符号化し、そのアプリケーションパッケージをワイヤレス放送ネットワーク152上で放送するため、同期メタデータ148を生成し得る。そのような同期メタデータ148は、放送ネットワーク152のオーバーヘッド情報フロー内で送信される対話型イベントシグナリングメッセージ(IESM)の形態で送信され得る。対話型イベントシグナリングメッセージの説明ならびにそのようなメッセージを管理するためのシステムおよび方法については、以下でより詳細に開示する。
この同期メタデータ148を受信したことに応答して、受信デバイス106、107、108は、メモリに格納され、示されたアプリケーションを起動するように促され得る。同期メタデータ148は、アプリケーション起動が放送ストリームと同期されることを可能にし得る。これはまた、アプリケーションの機能が、放送番組内の特定のイベントまたはポイントに対応するようにスケジュールされることを可能にする。アプリケーションの機能を放送番組中の特定のイベントおよび/またはポイントと同期させることは、コンテンツプロバイダ102が時間的に厳しい対話型アプリケーションを書くことを許容することによって、放送ネットワーク104がユーザ対話型をサポートすることを可能にする。
様々な実施形態では、対話型イベントシグナリングメッセージはまた、アプリケーションデータと画像と実行可能スクリプトとアセット(総称してアプリケーションデータ)を送るために使用され得る。一実施形態では、対話型イベントシグナリングメッセージと対応するアプリケーションデータとを送るために、同じフローが使用され得る。一実施形態では、アプリケーションデータは、ファイル配信フレームワークを介して、バックグラウンドで受信デバイス106、107、108に放送され得る。この実施形態では、受信デバイス106、107、108は、ダウンロード処理を開始するためにオンにされる必要はなく、大きいファイルは、受信デバイス106、107、108に事前に送られ得る。別の実施形態では、アプリケーションデータは、受信デバイス106、107、108にデータキャスト(datacast: データ放送)され得る。様々な実施形態では、対話型イベントが発生するようにスケジュールされるか、またはデバイスが対話型イベントシグナリングメッセージを受信するとき、受信デバイス106、107、108は、アプリケーションデータについてそれらのメモリを確認し、メモリからアプリケーションデータを引き出し、起動および/または実行処理を開始し得る。
図2は、様々な実施形態を実装するのに好適な受信デバイス10内に実装され得る機能構成要素を示す。受信デバイス10のソフトウェアモジュールは、図2に示すものと同様のソフトウェアアーキテクチャ20に編成され得る。放送送信は、受信デバイス物理レイヤによって受信され、FLOネットワークモジュール21などの放送受信モジュールによって処理され得る。FLOネットワーク21によって受信されたビデオおよびオーディオストリームはメディア受信モジュール(図示せず)によって処理され得る。FLOネットワーク21上で受信されたファイル転送ストリームは、ファイルパケットを受信し、それらをデバイスソフトウェアアーキテクチャ20内の適切なモジュールおよびアプリケーションに向けるように機能するファイル配信システムモジュール26に与えられ、それによって処理され得る。オーバーヘッドデータストリームは、オーバーヘッドデータパケットを処理し、受信したメタデータとオーバーヘッドデータとをデバイスシステムアーキテクチャ20内の適切なモジュールに向けるように機能する、オーバーヘッドデータ獲得モジュール28に渡され得る。
サービスシステム情報獲得(service system information acquisition (SI Acquisition): SI獲得)モジュール27は、オーバーヘッドデータストリームからサービスシステム情報(サービスSI)メッセージデータを獲得し、この情報をファイル配信システムモジュール26およびオーバーヘッドデータ獲得モジュール28に転送し得る。ファイル配信システムモジュール26は、サービスSIメッセージデータを使用して、対話型リソースデータを搬送するファイルデータフローのフローIDを決定し得る。同様に、オーバーヘッドデータ獲得モジュール28は、サービスSIメッセージデータを使用して、どのシグナリングフローが、関係する対話型シグナリングデータを搬送しているかを決定し得る。
図2はまた、対話型イベントをサポートするため、デバイスソフトウェアアーキテクチャ20が、対話型イベントを受信し、管理し、格納するために、ユーザインターフェース(UI)アプリケーション24とFLOネットワーク21との間のコアモジュールとして働く対話型コアサービス22を含むことを示す。ユーザインターフェースアプリケーションモジュール24は、いくつかの対話型アプリケーション244、246、248とユーザエージェント242とを含む。ユーザエージェント242は、対話型イベントシグナリングメッセージを対話型アプリケーションの対象とされる集合にルーティングする機能をサポートする。
対話型コアサービスモジュール22は、リソースマネージャモジュール222、対話型イベントマネージャモジュール224、およびアプリケーションマネージャモジュール226、ならびに受信デバイスプロセッサ上で実行する他の機能モジュールを含み得る。対話型イベントにおいて使用することが意図されたリソースおよびテンプレートのための放送ファイルは、ファイル配信システムモジュール26によって受信され、対話型コアサービス22内のリソースマネージャ222に渡され得る。リソースマネージャ222は、受信したリソースおよびテンプレートをメモリに格納し、それらのリソースおよびテンプレートは、表示とユーザインターフェースとを生成する際に使用するために、そのようなファイルの呼び戻し(recall)および使用を可能にするように索引付けされ、編成され得る。これらの表示およびユーザインターフェースは、受信デバイスのユーザに受信した対話型イベントを示すためにユーザインターフェースアプリケーションモジュール24によって使用され得る。
様々な実施形態では、オーバーヘッドデータ獲得モジュール28は、オーバーヘッドフローから対話型イベントシグナリングメッセージ(IESM)を選択的に受信(たとえば、フィルタと対応するアプリケーションとに基づいて)し、それらを対話型イベントマネージャモジュール224に受け渡し得る。対話型イベントマネージャモジュール224は、デバイス上にロードされる対話型アプリケーションのための対話型イベントシグナリングメッセージを獲得するように、オーバーヘッドデータ獲得モジュール28に要求し得る。これを可能にするために、対話型アプリケーション244、246、248は、それらのアプリケーションが受信デバイス10、106、107、108上にダウンロードされるか、またはそれらの受信デバイス上で立ち上げられるとき、アプリケーションマネージャモジュール226に登録し得る。獲得された対話型イベントシグナリングメッセージは、シグナリングメッセージ中で受信されるアプリケーション識別子フィルタ処理情報に基づいて、適切な対象とされる対話型アプリケーション(244、246または248)に渡され得る。
受信デバイス10、106、107、108上で、受信したアプリケーションのユーザ通知が、図3Aにその一例が示される様々な形態で達成され得る。この例では、表示160上にリアルタイムコンテンツを示している受信デバイス106は、表示の一部分内にポップアップまたはバナー162を生成し得る。ポップアップまたはバナー162は、新しいアプリケーションの利用可能性をユーザに通知する単純なテキストボックスを含み得る。ポップアップまたはバナー162は、アプリケーションを起動するためにタッチスクリーン上のボタンまたはアイコンを押すようにユーザに促し得る。プロンプトの一部として、ユーザはまた、新しいアプリケーションがメモリから削除されるべきかどうかを示すことを求められ得る。別の実施形態では、デバイス上の受信した対話型アプリケーションは、ユーザによる明示的な起動なしに、放送ネットワークを介して受信されるIESMに基づいて引き出され、起動され得る。
上記で説明したように、対話型イベントおよび対話型イベントアプリケーションはまた、個々に定義され、次いで、対話型アプリケーションジェネレータ44によって対話型イベントアプリケーションの中に組み入れられるか、または対話型ゲートウェイ42によって(たとえばXMLフォーマットで)対話型イベントアプリケーションデータの中に組み入れられる、画像、ビデオ、表示画面およびユーザプロンプトのシーケンスの形態に組み立てられ得る。クリックツーSMS(click-to-SMS)対話型シーケンスを特徴づける例示的な対話型イベントおよび関連する表示が、図3Bに示される。この例では、デフォルトシーン(画像302に示される)は、特定のチャネル上で受信されているリアルタイム番組(たとえば、図示のドッグショー番組)であり得る。バックグラウンドで、受信デバイスは、対話型イベントアプリケーションまたはアプリケーションデータを受信し、適切なイベント開始時刻にそれを実装する準備ができる。そのイベント開始時刻は、後で対話型イベントシグナリングメッセージの中で受信され得る。イベント開始時刻に、受信デバイス上の対話型アプリケーションは、画像304に示されるように、対話型イベントへの出だしとしてプロンプトシーンを生成し得る。この例では、プロンプトシーンは、リアルタイム番組上に現れるとともに、ユーザが対話型イベントに参加したい(または参加したくない)という要望を示すことを可能にするための仮想ボタンを含む、テキストまたはバナー表示を有する。この例では、ユーザは、無料ドッグフードのためのコンテストに応募するための機会を提供されている。「はい」または「いいえ」のいずれかに関連するボタン(または仮想ボタン)を押すことによって、ユーザは、コンテストに参加することを選択するかまたは断ることができる。
ユーザが、プロンプトシーン304に応答して「はい」に関連するボタンを押し、参加するという意思を示した場合、受信デバイス上で動作する対話型イベントアプリケーションは、画像306に示すようにアクションシーンを表示し得る。この例では、コンテストに関連する画像またはビデオが情報テキストとともに提示され得る。この例では、ユーザは、コンテストに応募するためにSMSメッセージを送るように促される。対話型アプリケーションによって与えられるボタン機能は、ユーザが、単にボタン(たとえば、表示された「送信」ユーザの選択肢に関連するボタン)を押すことによって参加することができるように、応答を自動化し得る。この例では、対話型イベントアプリケーションは、ユーザが「送る」ユーザの選択肢に関連するボタンを押したことに応答して、ユーザがコンテストに応募していることを示すために、プログラムされたSMSアドレスに、SMSメッセージを送るように構成される。SMSアドレスは、対話型アプリケーションまたはアプリケーションデータの一部としてプログラムされ得る。この例はまた、「終了」ユーザの選択肢に関連するボタンを押すことによってなど、対話型イベントアプリケーションが、ユーザに、どのようにアプリケーションを終了させるための機会を与え得るかを示す。
ユーザが、アクションシーン306に応答して「送信」に関連するボタンを押した場合、対話型イベントアプリケーションは、確認シーン308を備える第3の表示画像を表示するように構成され得る。この例では、確認シーンは、ユーザのアクションが実装されていることをユーザに示すテキストとともに、コンテスト、またはユーザアクションの確認に関連する表示を含む。図示の例では、この確認テキストは、コンテスト応募メッセージが送信されたことと、当選者はテキストメッセージによって通知されることとを、ユーザに知らせる。対話型アプリケーションの確認シーン部分はまた、ユーザが確認シーンを閉じ、視聴されているリアルタイム番組などのデフォルトシーン310に戻ることを可能にするため、ユーザ入力機能を含み得る。
図3Bはまた、対話型イベントアプリケーションが、ユーザのアクションに応じて異なる結果を与えるためにどのように構成され得るかを示す。たとえば、ユーザが、プロンプトシーン304において「いいえ」に関連するボタンを押した場合、対話型イベントアプリケーションは、デフォルトシーン310に戻るように構成され得る。さらに、ユーザが(本明細書では「シーンタイムアウト」時間と呼ぶ)ある量の時間内にアクションをとることができなかった場合、対話型イベントアプリケーションは、デフォルトシーン310に自動的に戻るように構成され得る。同様に、ユーザが、アクションシーン306において「終了」に関連するボタンを押した場合、対話型イベントアプリケーションは、デフォルトシーン310に自動的に戻るように構成され得る。同様に、確認シーン308も、所定のシーンタイムアウト時間後に終了し得る。
対話型イベントアプリケーションを、シーン、ユーザの選択肢ボタンおよび関連する機能のシーケンスに編成することによって、そのようなアプリケーションは、対話型アプリケーションジェネレータによって動的に生成され得る。対話型イベントアプリケーションが対話型アプリケーションジェネレータによってどのように組み立てられるかの一例が、図3Bに示した対話型イベントアプリケーションに対応する4つの表示またはシーン状態を示す図3Cに示されている。対話型イベントアプリケーションは、受信デバイスによって視聴されているリアルタイム番組またはチャネルであり得るデフォルトシーン状態322から開始するように構成され得る。対話型イベントアプリケーションは、受信した対話型イベントシグナリングメッセージに応答してトリガされ、また、現在時刻がイベント開始時刻に等しいときを決定するために、デバイスシステムクロックを視聴し得る。代替的に、対話型イベントアプリケーションは、受信デバイス中のモジュール(たとえば、図2を参照しながら上記で説明した対話型イベントマネージャ242)によってイベント開始時刻に起動され得る。イベント開始時刻に、対話型イベントアプリケーションは、状態遷移330においてプロンプトシーン状態324に遷移し得る。上記で説明したように、プロンプトシーン状態324は、この例ではシーンID1として特定される、表示画像およびテキストの特定の集合と、「いいえ」350および「はい」352の選択のためのユーザ入力ボタンの選択肢などのユーザ入力機能とを含み得る。この例では、ユーザ入力が「いいえ」350の選択肢に対応する場合、またはタイムアウトタイマーが満了した場合、対話型イベントアプリケーションは、状態遷移332においてデフォルトシーン状態322に戻り、終了し得る。
ユーザ入力が「はい」352の選択肢に対応する場合、対話型イベントアプリケーションは、状態遷移334においてアクションシーン状態326に遷移するように構成され得る。上記で説明したように、アクションシーン状態324は、この例ではシーンID2として特定される、表示画像およびテキストの特定の集合と、この例に示すように「終了」354および「送信」356の選択のためのユーザ入力ボタン選択肢などのユーザ入力機能とを、含み得る。この例では、ユーザ入力が「終了」354の選択肢に対応する場合、またはタイムアウトタイマーが満了した場合、対話型イベントアプリケーションは、状態遷移336においてデフォルトシーン状態322に戻り、終了し得る。
ユーザ入力が「送信」356の選択肢に対応する場合、対話型イベントアプリケーションは、状態遷移338において確認シーン状態328に遷移するように構成され得る。上記で説明したように、確認シーン状態324は、この例では「シーンID=3」として特定される、表示画像およびテキストの特定の集合と、この例に示すように、対話型イベントアプリケーションを終了するための「閉じる」358の選択のためのユーザ入力ボタンの選択肢などのユーザ入力機能とを含み得る。この例では、ユーザ入力が「閉じる」358の選択肢に対応する場合、またはタイムアウトタイマーが満了した場合、対話型イベントアプリケーションは、状態遷移340においてデフォルトシーン状態322に戻り、終了する。
図3A〜図3Cに示した例は、対話型イベントが、構成要素データ(たとえば、シーンとテキストとを表示する)、および、単純なロジックスクリプト(たとえば、ユーザ入力ボタン機能、特定のユーザ選択を実行するためのアドレス、タイムアウトおよびデフォルト設定、ならびにシーンシーケンス選択)から、どのように組み立てられるかの一例にすぎない。そのような構成要素は、対話型コンテンツプロバイダによって個々に生成され、図3Cに示す方法で機能するアプリケーションの中に構成部分を組み入れるために、対話型アプリケーションジェネレータによって使用されるシーケンシング情報またはメタデータとともに、対話型生成システムに送られ得る。したがって、様々な実施形態は、単純なロジックでの選択に結び付けられシーケンスの中でリンクされたる個別の構成要素を与えることによって、対話型コンテンツプロバイダが望み得るだけの複雑さおよびコンテンツをもつ対話型イベントを生成することを可能にし、そのアプリケーションの組立は、対話型アプリケーションジェネレータ31によって動的に達成される。別の実施形態では、デバイス上の静的対話型アプリケーションが、複雑さを低減するために対話型シーンシーケンスロジックをすでに構築させていてもよい。その場合、対話型シーン情報は、デバイス上の対話型アプリケーションによって使用されることになる、対話型アプリケーションデータの一部として放送されることになる。
図4に、受信デバイスによって受信され、処理され得るように、対話型イベントシグナリングメッセージを準備し、放送するための実施形態の方法400を示す。方法400のステップ402において、対話型コンテンツプロバイダは、対話型イベントシグナリングメッセージの生成のために、対話型生成システム(IPS)に対話型コンテンツおよび/または対話型イベント情報(IEI)を供給する。対話型生成システムに供給される対話型イベント情報は、イベント開始時刻、有効期間/終了時刻、対象とされるリアルタイムサービス、対象とされる対話型アプリケーション、フィルタ処理基準、対象キャリア、対象デバイスタイプ、ならびに必要なまたは関連するリソースおよびテンプレートなどの、イベントメタデータを含み得る。様々な実施形態では、対話型生成システムにおける対話型コンテンツの取り込みは、オペレータによって手動で達成される(たとえば、対話型生成システム上の供給インターフェースを使用して)か、または、対話型コンテンツプロバイダまたはリアルタイムコンテンツプロバイダとのプログラミングインターフェースを介して、達成され得る。対話型コンテンツは、対話型生成システムへのプログラミングインターフェースを使用して、外部広告(ad)ネットワーク(たとえば、Google Adネットワーク)からも取り込まれる。
上述のように、対話型生成システムに供給される対話型イベント情報は、ビデオファイル、サウンドファイル、表示テキスト、メニュー選択テキストおよび機能、応答URL、シーンシーケンシングおよび分岐情報、ならびにイベントメタデータ(たとえば、イベント開始時刻、有効期間/終了時刻、対象とされるリアルタイムサービス、対象とされる対話型アプリケーション、ターゲットキャリア、ターゲットデバイスタイプ、ならびに必要なまたは関連するリソースおよびテンプレート)を含み得る。また、ステップ402において、ユーザに表示され得る情報、ユーザに示される画像およびグラフィックス、ならびに特定のユーザインターフェースボタンまたはタッチスクリーンインターフェースアイコンに割り当てられた機能などのユーザから期待される関連アクションなどの、対話型アプリケーションデータが与えられ得る。また、ステップ402の一部として、対話型イベントとリアルタイムコンテンツストリームまたは広告との同期を可能にするために、リアルタイムコンテンツに係るイベント表示開始時刻に関する情報が指定され得る。リニア広告のために作成される対話型イベントでは、ステップ402において、イベントがリニア広告スロット(枠)に関連付けられ得る。リニア広告スロットは広告スロットタイムウィンドウ(ad slot time window)を指定する。そのようなイベントに係るイベント開始時刻は、ステップ408に関して上記で説明したように、広告挿入システムから受信されるタイミングトリガに基づいて、対話型生成システムによって計算され得る。
ステップ404において、対話型生成システム(IPS)は、リアルタイムコンテンツに対するイベント表示開始時刻に関する情報を与える。リアルタイムコンテンツに対するイベント表示開始時刻に関する情報を与えることは、対話型イベントをリアルタイムコンテンツストリームまたは広告と同期させることを、システムに可能にする。様々な実施形態では、イベント表示開始時刻は、後述のステップ408に関して説明するように、広告挿入システムから受信されるタイミングトリガ(timing trigger)に基づいて対話型生成システムによって計算され得る。
また、ステップ404において、対話型生成システム(IPS)は、対話型イベントに関連する、組み立てられた対話型イベント情報(イベントメタデータおよびイベントアプリケーションデータなど)を、放送ペレーションセンター内の対話型サーバまたはゲートウェイに送る。ステップ406において、対話型サーバまたはゲートウェイは、対話型イベント情報(すなわち、対話型イベントに関連する対話型リソースおよび/またはテンプレートファイル)の適応を実行するか、または場合によっては、対話型イベント情報を、放送システムを介した放送のために適切なフォーマットにする。たとえば、対話型イベント情報は、JPEGファイルの形のビデオを含み得る。このコンテンツを、モバイル放送システム(たとえば、FLO TV(登録商標))による放送に好適にするために、対話型ゲートウェイは、コンテンツが放送エンコーダシステムと互換性があるように、画像サイズとフレームレートとデータフォーマットとを変更する必要がある。ステップ408において、対話型ゲートウェイは、1つまたは複数の対話型アプリケーションを動的に生成するために対話型アプリケーションジェネレータ(IAG:interactivity application generator)とインターフェースする。これは、ステップ410において、対話型アプリケーションジェネレータにとって必要な適切にフォーマットされたファイルを与える、ならびに、対話型イベントアプリケーションの対象とされるべきデバイスタイプのリストを与える、対話型ゲートウェイを含む。このステップ410はまた、対話型アプリケーションジェネレータにイベントメタデータと他のシステムデータとを与える対話型ゲートウェイを含む。
ステップ412において、対話型アプリケーションジェネレータは、受信したアプリケーションデータとデバイスタイプのリストとに基づいて、1つまたは複数の対話型アプリケーションを動的に生成する。図3Cに関して上記で説明したように、この処理は、対話型要素とシーケンスロジックとを実行可能アプリケーションに組み込むことを含む。ステップ414において、対話型アプリケーションジェネレータは、動的に生成された対話型アプリケーションを、対話型ゲートウェイに送る。ステップ415において、対話型ゲートウェイは、イベントメタデータ情報と動的に生成された対話型アプリケーションとを、対話型放送サーバに送る。
様々な実施形態では、ステップ410〜415は、IPSから受信された対話型要素情報に基づいて、適切な必要とされるフォーマットで対話型アプリケーションデータを生成する対話型ゲートウェイ自体によって置き換えられ得ることに留意されたい。これらの実施形態では、対話型ゲートウェイは、生成されたアプリケーションデータと、イベントメタデータ情報と、対話型リソース情報とを、対話型放送サーバに送り得る。
ステップ416において、対話型放送サーバは、受信デバイスへの放送配信のために、対話型関係ファイル(対話型アプリケーションとアプリケーションデータとリソースとを含む)を、ファイル配信システムに配信する。対話型関係ファイルは、ステップ416の一部として、対話型シグナリングカタログファイル中で広告され得る。ステップ418において、ファイル配信システムは、対話型シグナリングカタログファイルと対話型イベント関係ファイルとを、空中線上で配信する。ステップ420において、モバイルデバイスは、放送ネットワークから対話型イベントアプリケーションファイル/アプリケーションデータと、他の対話型リソースとテンプレートファイルとを、獲得する。ステップ422において、対話型放送サーバは、適切な対話型イベントシグナリングメッセージ(IESM)を生成し、そのメッセージを、オーバーヘッドデータストリームの一部として放送するために、オーバーヘッドデータ配信システムに与える。この対話型イベントシグナリングメッセージは、配信に必要な信頼性およびサービス品質(quality of service (QoS))を指定し得、また、対話型イベントの開始時刻近くに放送され得る。
ステップ424において、オーバーヘッドデータ配信システムは、対話型サーバによって指定された信頼性およびサービス品質をもったオーバーヘッドフロー上で、対話型放送サーバから受信された対話型イベントシグナリングメッセージを放送する。対話型イベントシグナリングメッセージが受信デバイスによってタイムリーに受信されることを保証するために、対話型イベントシグナリングメッセージは、高優先度オーバーヘッドデータとして放送され得る。様々な実施形態では、対話型イベントシグナリングメッセージは、対話型イベントが開始することになる前に、ステップ422においてオーバーヘッドデータ配信システムに与えられ、ステップ424において放送され、そして、対象とされるリアルタイムコンテンツに同調する受信デバイスが、すぐに、対話型イベントを実装し、表示し得るように、対話型イベントの持続期間にわたって放送され続ける。
ステップ426において、放送カバレージエリア内の受信デバイスは、リアルタイムサービスのためのオーバーヘッドフローから対話型イベントシグナリングメッセージを獲得し、そのメッセージ中に示されたイベント開始時刻に、対話型イベントシグナリングメッセージ中で参照される適切な対話型アプリケーション(特定の受信デバイスタイプに基づく)を実行する。ESMは、対話型イベントが向けられている各デバイスタイプに係るアプリケーションデータファイルおよびリソースファイルへの参照を与え得る。
サーバ生成(server-generated)対話型イベントアプリケーションおよび/またはデバイス生成(device generated)対話型イベントアプリケーションの実装形態をサポートするために、対話型イベントシグナリングメッセージデータの形式は、図14A〜図16Cに示すようにフォーマットされ得る。特に、メッセージデータの形式は、各関連するデバイスプロファイルに係り、動的に生成された対話型アプリケーションを含んでいるリソースの識別子などの情報をもつ、対話型イベントが実行されるべきデバイスプロファイルのリストを含む。対話型アプリケーションリソースIDは、受信したデバイス上に対話型を表示するように適切な対話型アプリケーションを実行するため、そのデバイスによって使用されることになる。
上記で説明したように、一実施形態では、対話型イベントアプリケーションは、BOC4内の対話型アプリケーションジェネレータ31内で動的に生成され得る。この実施形態について、図5Aを参照しながら以下で説明する。この実施形態では、生成された対話型イベントアプリケーションは、図8〜図24Dを参照しながら以下で説明するように、受信デバイスによって受信され、実装され得るアプリケーションとして(たとえばファイル配信システムを介して)放送される。以下で説明する別の実施形態では、対話型イベントアプリケーションは、放送された対話型アプリケーションデータおよびメタデータに基づいて、受信デバイス自体の内で生成/実装され得る。
図5Aに、放送システムを介して、受信デバイスに、対話型アプリケーションと関連するメタデータとを配信するための実施形態の方法500を示す。そのような配信機構はまた、対話型イベントを実装するため、ならびに対話型イベントアプリケーションを生成するために受信デバイスによって用いられる、対話型イベントデータとリソースとテンプレートとを配信するために使用され得る。方法500のステップ502において、コンテンツプロバイダおよび/または対話型アプリケーションジェネレータは、アプリケーションコンテンツを生成し、アプリケーションデータとアセットとファイルと他の実行可能要素とを作成し、それらを一緒にアプリケーションパッケージの中にバンドルする。そのようなアプリケーションパッケージは、アプリケーションパッケージを構成し得るコンテンツのタイプのほんのいくつかの例を挙げれば、HTMLファイル、XMLスクリプト、JPEG画像、テキストファイル、およびshockwaveファイルを含み得る。ステップ504において、アプリケーションパッケージは、放送ネットワーク内のアプリケーションサーバに渡される。ステップ506において、コンテンツプロバイダは、特定のアプリケーションの放送のための要求される将来の日付に関する情報を、スケジューラサーバに送る。ステップ508において、アプリケーションサーバは、受信デバイスによるダウンロードのために利用可能なアプリケーションを広告するカタログファイルを生成し、これを、符号化と、ワイヤレス放送ネットワークを介した放送とのために、符号化サーバに与える。アプリケーションサーバは、特定のアプリケーションパッケージが放送されることになる日付および時刻を特定するために、同期エージェントサーバまたは放送スケジューラと協調し得る。アプリケーション放送のデータおよび時刻は、ファイル配信スケジュールを搬送するオーバーヘッドフロー中に示され得る。アプリケーションカタログファイルはまた、アプリケーションパッケージが受信され得る放送ストリームを示し得る。
ステップ510において、サーバが、アプリケーションサーバからアプリケーションパッケージを取り出し、アプリケーションに関する追加のメタデータを追加し、符号化のためにアプリケーションとメタデータとをパッケージングする。たとえば、様々な実施形態では、同期エージェントは、ステップ510において、カタログ中のアプリケーションを検索(look up)し、それをリポジトリ(repository)から取り出し、アプリケーションに関する追加のメタデータを加え、それを符号化のためにパッケージングし得る。ステップ512において、符号化サーバは、放送ストリーム内に含めるために、アプリケーションパッケージを好適なフォーマットに符号化する。符号化処理の一部として、アプリケーションパッケージは、データパッケージに分割され得、該データパッケージは、データパケットおよびスーパーフレームに符号化される。ステップ514において、符号化されたアプリケーションパッケージは、次いで、ワイヤレス放送ネットワークを介して放送される。ステップ516において、符号化されたアプリケーションパッケージは、受信デバイスによって放送信号から取り出される。
図5Bは、受信デバイスが対話型イベントを実装するために使用することができる対話型イベントシグナリングメッセージ(IESM)を準備し、放送するための実施形態の方法550aを示す。方法550aのステップ552において、対話型コンテンツプロバイダは、対話型イベントシグナリングメッセージを生成するために、対話型生成システム(IPS)に対話型コンテンツおよび/または対話型イベント情報(IEI)を供給する。対話型生成システムに供給される対話型イベント情報は、イベント開始時刻、有効期間/終了時刻、対象とされるリアルタイムサービス、対象とされる対話型アプリケーション、対象キャリア、対象デバイスタイプ、ならびに必要なまたは関連するリソースおよびテンプレートなど、イベントメタデータを含み得る。様々な実施形態では、対話型生成システムにおける対話型コンテンツの取り込みは、オペレータによって手動で達成される(たとえば、対話型生成システム上の供給インターフェースを使用して)か、または対話型コンテンツプロバイダまたはリアルタイムコンテンツプロバイダとのプログラミングインターフェースを介して達成され得る。対話型コンテンツは、対話型生成システムの中へのプログラミングインターフェースを使用して、外部広告ネットワーク(たとえば、Google Adネットワーク)からも摂取され得る。
上記で説明したように、ステップ552において、対話型コンテンツプロバイダは、対話型生成システム(IPS)に、対話型コンテンツおよび/または対話型イベント情報(IEI)を供給する。様々な実施形態では、ステップ552において、対話型生成システムはまた、対話型イベントアプリケーションデータ(IEAD)を与えられ得る。この対話型イベントアプリケーションデータは、ユーザに表示される情報と、ユーザに示される画像およびグラフィックスと、ユーザから期待される関連するアクションとを含み得る。ユーザから期待される関連するアクションは、特定のユーザインターフェースボタンまたはタッチスクリーンインターフェースアイコンに割り当てられた機能を含み得る。ステップ552において、対話型生成システムはまた、リニア広告のために作成された対話型イベントを、リニア広告スロットに関連付け得る。これらのリニア広告スロットは、対話型広告が表示されるべき広告スロットタイムウィンドウを指定する。
また、ステップ552の一部として、対話型生成システム(IPS)は、リアルタイムコンテンツに係るイベント表示開始時刻に関する情報を与える。リアルタイムコンテンツに係るイベント表示開始時刻に関する情報を与えることは、対話型イベントを、リアルタイムコンテンツストリームまたは広告と同期させることを、システムに可能にする。様々な実施形態では、イベント表示開始時刻は、後述のステップ558に関して説明するように、広告挿入システムから受信されたタイミングトリガに基づいて、対話型生成システムによって計算され得る。
様々な実施形態では、ステップ553において、対話型生成システム(IPS)は、イベント情報を対話型ゲートウェイに送り、対話型ゲートウェイは、データを、対話型サーバに送るのに適したフォーマットでフォーマットする。ステップ554において、対話型生成システムおよび/または対話型ゲートウェイは、組み立てられる対話型イベント情報(イベントメタデータおよびイベントアプリケーションデータなどの)を、放送ペレーションセンター内の対話型サーバに送る。リニア広告上で表示される対話型イベントでは、対話型生成システムは、イベント情報を、対話型サーバに送り得る。イベント情報は、広告挿入システムから受信されるトリガに基づいて、複数のシグナリングメッセージを介して対話型サーバに送られ得る。
ステップ556において、対話型サーバは、イベントが開始する前に、対話型イベントに関連する対話型リソース(アセットとアプリケーションデータとを含む)および/またはテンプレートファイルが受信デバイスによって受信され得るよう、これらのファイルを放送するためにファイル配信システムに通知し得る。上述のように、様々な実施形態では、帯域幅を節約するために、対話型イベントアプリケーションデータおよびリソースは、イベント開始時刻より前に(たとえば、イベント開始時刻の数秒または数分前に)放送され得る。したがって、様々な実施形態では、対話型サーバは、イベント開始時刻より前に対話型リソースおよびテンプレートファイルの配信を要求するように構成される。このようにして、必要なリソースおよびテンプレートは、対話型イベントに先立って放送され、したがって、必要なリソースおよび/またはテンプレートを前にダウンロードしていない受信デバイスは、次に来る対話型イベントを実装する準備ができるように時刻内にダウンロードすることができる。様々な実施形態では、対話型サーバは、イベント表示開始時刻および/または広告スロットウィンドウ時間に基づいて、対話型リソースおよびテンプレートファイルの配信を要求し得る。様々な実施形態では、対話型イベントアプリケーションデータ(IEAD)、リソースおよびテンプレートは、対話型イベントリソースファイル配信ストリーム中でなど、放送ネットワークのファイル配信サービスを使用してアウトオブバンドで放送され得、これは、対話型イベントアプリケーションデータが対話型イベントシグナリングメッセージ(IESM)の一部としてインバンドで送信される場合よりも、放送帯域幅のより良い使用を可能にする。
ステップ558において、対話型コンテンツプロバイダからまたは広告挿入システムから受信され得るトリガ情報に基づいて、対話型生成システム(IPS)によって、対話型イベント開始時刻が計算され得る。たとえば、放送ペレーションセンターによって挿入されたリニア広告上で提示されることになる対話型イベントは、ステップ552の間の厳密な開始時刻を与えられなくてもよい。そのような場合、対話型生成システムは、広告挿入システムから受信されたトリガ情報に基づいて、適切な開始時刻を計算する。
ステップ560において、対話型生成システム(IPS)は、リニア広告のための対話型イベントに係る計算されたイベント開始時刻を、(対話型ゲートウェイを介して)対話型サーバに送る。ステップ562において、対話型サーバは、対象とされるリアルタイムサービス(すなわち、対話型イベントが現れることが意図されたリアルタイムコンテンツ)について、エンドツーエンド(端から端まで)の放送システム待ち時間に基づいて対話型イベント開始時刻を調整する。この調整は、対話型イベントがリアルタイムコンテンツとの所望の同期で再生されることを保証する。
ステップ564において、対話型サーバは、適切な対話型イベントシグナリングメッセージ(IESM)を生成し、そのメッセージを、オーバーヘッドデータストリームの一部として放送するために、オーバーヘッドデータ配信システムに与える。対話型イベントシグナリングメッセージとともに与えられる情報の一部として、対話型サーバは、放送システムを介した対話型イベントシグナリングメッセージの配信のために必要な信頼性およびサービス品質(QoS)を指定し得る。
ステップ566において、オーバーヘッドデータ配信システムは、対話型サーバによって指定された信頼性およびサービス品質を以って、オーバーヘッドフロー上で対話型イベントシグナリングメッセージ(IESM)を放送する。対話型イベントシグナリングメッセージが受信デバイスによってタイムリーに受信されることを保証するために、対話型イベントシグナリングメッセージは、高優先度オーバーヘッドデータとして放送され得る。様々な実施形態では、対話型イベントシグナリングメッセージは、対話型イベントが開始することになる前に、ステップ564においてオーバーヘッドデータ配信システムに与えられ、ステップ566において放送され得る。様々な実施形態では、対話型イベントシグナリングメッセージは、対話型イベントの継続期間にわたって放送され得る。これは、対象となるリアルタイムコンテンツに同調する受信デバイスが、対話型イベントをすぐに実装し、表示することを可能にする。
ステップ568において、放送カバレージエリア内の受信デバイスは、ファイル配信システムから、対話型イベントに関連する対話型リソースとテンプレートファイルとを受信する。ステップ570において、放送カバレージエリア内の受信デバイスは、オーバーヘッドフローから、対話型イベントシグナリングメッセージ(IESM)を受信する。ステップ572において、受信デバイスは、イベントシグナリングメッセージの中で受信されたイベント開始時刻に基づいてコンテンツを表示することによって、対話型イベントを実装する。
様々な実施形態では、特定のイベントのための対話型イベントシグナリングメッセージ(IESM)は、モバイル放送ネットワークを介して、一様でない方法で送られ得る。イベント開始時刻の前に残っている時間に応じてなど、対話型イベントシグナリングメッセージを異なるレートで送信することによって、対話型イベントシグナリングメッセージが大部分の受信デバイスによって時間内に受信されることになる所望レベルの確実さを与えながら、空中線帯域幅の利用が最適化され得る。たとえば、イベントを起動するために、受信デバイスの大部分がメッセージを時刻内に獲得することを保証するため、そのイベントのための対話型イベント開始時刻のわずか前により頻繁に(たとえば1秒ごとに1回)、対話型イベントシグナリングメッセージが放送され得る。対話型イベントシグナリングメッセージは、そのようなメッセージに割り振られる帯域幅の量を低減するために、対話型イベント開始時刻の十分前にはより少ない頻度(たとえば、3〜10秒ごとに1回)で配信され得る。対話型イベントシグナリングメッセージはまた、イベント開始時刻後に対話型イベントに関連するカバレージに入る受信デバイスが対話型イベントシグナリングメッセージを獲得し、対話型を表示することができるように、イベント有効期間全体の中で頻繁に放送されてもよい。対話型イベントシグナリングメッセージは、イベント有効期間中に周期的に(たとえば、5秒ごとに1回)放送されてもよい。イベントの間の対話型イベントシグナリングメッセージの放送は、その時刻中にコンテンツフローに同調したか、またはカバレージエリアに入ってきた受信デバイスが、対話型イベントの表示を開始することを可能にするためであるので、フローデータを獲得し、コンテンツを表示するための準備ができるようなデバイスに関連するレイテンシ(一般に約5秒の)が存在するとの理由から、放送頻度は低減され得る(たとえば、5秒ごとに1回)。
上記で説明したように、特定のイベントのための対話型イベントシグナリングメッセージ(IESM)は、一様でない方法で送られ得る。これは、図5Bを参照しながら上記で説明した方法550aと類似の実施形態の方法550bを示す図5Cに示されている。方法550bのステップ564において、対話型サーバは、対話型イベントシグナリングメッセージを生成し、そのメッセージを、オーバーヘッドデータストリームの一部として放送するために、オーバーヘッドデータ配信システムに与える。ステップ565において、対話型イベントが開始および/または終了する前に残っている時間に基づいて、対話型イベントシグナリングメッセージの放送がスケジュールされる。ステップ565において、対話型イベントシグナリングメッセージの放送時刻は、イベントが完了するまで間欠的に調整される。ステップ566において、オーバーヘッドデータ配信システムは、オーバーヘッドフロー上で対話型イベントシグナリングメッセージを放送する。対話型イベントシグナリングメッセージが放送されている間、放送時刻は、ステップ565によって示されるように、イベントが完了するまで間欠的に調整され得る。様々な実施形態では、対話型イベントシグナリングメッセージ配信へのこの一様でない対応、以下でさらにより詳細に説明されるように、空中線帯域幅の消費を節約するために実装される。
図6は、アプリケーション要素をパッケージに組み立て、そのパッケージを放送のために準備する処理期間中の、システムモジュール間のデータフローの例を示す。図7は、図1Dに示すアプリケーションサーバ130内に実装され得る、放送に係るアプリケーションパッケージを準備するための例示的な方法700を示す。図1Dを参照しながら上記で説明したように、コンテンツプロバイダ102は、アプリケーションサーバ130に、アプリケーションパッケージを構成する様々なアプリケーション要素を与え得る。アプリケーションサーバ130は、放送ネットワークを介して配信するのに好適なアプリケーションパッケージに、これらのアプリケーション要素をコンパイル(編集)し得る。図6は、これらのアプリケーション要素が、画像および同様のアセット602と、実行可能スクリプト604などのアプリケーションロジックと、テキストおよび数字などのデータリソース606とを含み得ることを示す。画像アセット602は、画像ファイル608の形態で与えられ得る。アプリケーションロジック604は、XML、HTML、およびJSFLファイル610の形態で与えられ得る。データリソース606は、テキストまたはXMLファイル612の形態で与えられ得る。
図7を参照すると、方法700のステップ702において、アプリケーションサーバは、コンテンツプロバイダ102から、画像アセット602と、データリソース606と、アプリケーションロジック604とを受信する。ステップ704において、アプリケーションサーバは、アプリケーションアセットを動作アプリケーション618にコンパイルする。アプリケーション要素をコンパイルすることの一部として、アプリケーションサーバ130は、ディスプレイレイアウトテンプレート、標準フラッシュモジュール、標準XMLスクリプトなどの共通のテンプレートおよびソフトウェアアセット614を呼び出し、これらの共通の要素を動作アプリケーションに組み込む。代替的に、共通のテンプレートおよびソフトウェアアセットは、受信デバイスがそれら自体のメモリからそのような共通のテンプレートおよびソフトウェアアセットを呼び出すことを可能にするために、動作アプリケーションに関連するメタデータ中で指定され得る。一例として、アプリケーションサーバ130は、shockwave flash(SWF)またはAdobe Integrated Runtime(AIR)実行可能ファイルにコンパイルされ得るアセットとMXMLデータとを使用して、Flashアプリケーションを構築し得る。これは、ZIPまたはAIRでフォーマットされたバンドル(bundle)を生成することによって行われ得る。第2の例として、アプリケーションサーバ130は、HTML/CSS/JSファイルを受け付けること、ブラウザにおいて立ち上げられたとき、すべてのリソースのための適切なURLを含んでいるHTMLファイルを生成すること、すべてのバイナリリソースをbase64文字列に変換することとによって、Webアプリケーション(HTML)をコンパイルし得る。この処理は、すべての関係するデータファイルを取り込むことと、WebArchiveでフォーマットされたバンドルファイルを作成することとを必要とする。この処理の結果は、データストアまたはリポジトリに格納され得るアプリケーション618である。
アプリケーションサーバ130が、同期エージェントサーバ134からなど、放送のためのアプリケーションに係る要求/トリガを受信する(ステップ706)とき、ステップ708において、アプリケーションサーバ130は、データストレージから要求されたアプリケーションを取り出す。ステップ710において、アプリケーションサーバは、受信デバイスによる受信のために必要なメタデータを含むアプリケーションパッケージ620を形成するために、アプリケーション618にメタデータ622を追加する。ステップ712において、アプリケーションサーバ130は、アプリケーションとメタデータとを、符号化および/またはワイヤレス放送ネットワーク152を介した配信に好適なアプリケーションmimeタイプアグノスティックフォーマットにパッケージングする。
図8は、受信デバイスが、方法600および700において組み立てられるアプリケーションパッケージをサポートするように構成され得る代替ソフトウェアアーキテクチャ800を示す。詳細には、図8は、アプリケーションマネージャモジュール806が、放送ネットワークを介したアプリケーションの受信を直接管理し得ることを示す。図8は、また、受信デバイスのソフトウェアアーキテクチャが、放送ネットワークストリームからデータと命令とを受信し、情報を他のモジュールによって理解され得るフォーマットに復号化するデコーダ802を含み得ることを示す。アプリケーションおよびメタデータ804は、デコーダ802によって、アプリケーションが実装される前にそれらを管理するアプリケーションマネージャ806に渡され得る。ユーザインターフェースモジュール812は、レンダラモジュール814、フラッシュプレーヤ816、ブラウザまたはウェブキット818およびネイティブ処理820(たとえば、DLLおよびMOD)など、アプリケーションを実行およびレンダリングするために必要なソフトウェア構成要素を含み得る。さらに、ソフトウェアアーキテクチャ800は、ダウンロードされたアプリケーションの起動のタイミングを協調させるために、ユーザインターフェース812と協調するイベントマネージャモジュール810を含み得る。
ユーザインターフェース812は、特定のアプリケーションおよびイベント情報を取得するために、アプリケーションマネージャ806およびイベントマネージャ810とインターフェースし得る。たとえば、ユーザインターフェース812の制御下にあるアプリケーションは、やり取りを示す矢印824によって示すように、アプリケーションマネージャに登録し得る。アプリケーションを登録することは、受信デバイスによって受信された、そのアプリケーションに関係する更新が、ユーザインターフェース812に渡されるべきであることを、アプリケーションマネージャに示し得る。たとえば、フェイスブック(Facebook)アプリケーションは、放送チャネルを介して受信された後続のフェイスブックメッセージおよび更新が、ユーザインターフェース812を介してフェイスブックアプリケーションに自動的に渡されるように、アプリケーションマネージャに登録し得る(矢印824)。
イベントマネージャ810は、対話型アプリケーション起動の開始および停止時刻を制御するために、矢印828によって示すように、ユーザインターフェース812と通信し得る。たとえば、アプリケーションが特定の広告の間に機能するように意図されている場合、イベントマネージャ810は、アプリケーションが始まるべきポイントにおいてユーザインターフェース812に開始メッセージ828を送り、アプリケーションが終了すべきポイントにおいて停止メッセージ828を送り得る。
様々な実施形態では、実行中のアプリケーションまたは対話型イベントの性質に応じて、ユーザは、選択を行うかまたはフィードバックを与えるように勧誘され得る。フィードバックは、調査質問に対する応答または特定の対話型アプリケーションに対する応答など、コンテンツプロバイダにとって有益であり得る情報を含み得る。そのようなユーザ対話は、メッセージ826中でイベントマネージャ810に通信され得、イベントマネージャ810は、放送事業者または別の当事者に後で報告するために応答をロギング(記載)し得る。さらに、モバイルメディア放送受信デバイスは、ユーザ閲覧傾向および選択を都度報告する機構を用いて構成され得るので、既存の機構も、実行中のアプリケーションに応答して統計および特定のユーザ選択を報告するために使用され得る。ユーザインターフェース812はまた、リアルタイムデータイベントとアプリケーションに対する更新とを受信するために、通信826を介してイベントマネージャ810に登録し得る。
上述のように、受信デバイスは、放送オーバーヘッドストリーム中に含まれるカタログまたは他の情報に基づいて、放送ストリームからの受信のためにアプリケーションを選択し得る。図9は、そのようなカタログメッセージ中に含まれている情報に基づいて、放送ストリームからの受信のためにアプリケーションパッケージを選択するため、受信デバイスにおいて実装され得る例示的な方法900を示す。方法900のステップ902において、デコーダ802は放送オーバーヘッドストリームからアプリケーションカタログを抽出し、ステップ904において、アプリケーションカタログをアプリケーションマネージャ806に渡す。ステップ906において、アプリケーションマネージャは、カタログに記載されているアプリケーションのためのメタデータを抽出し得る。ステップ908において、アプリケーションマネージャは、ダウンロードするために適切なアプリケーションを選択するために、抽出されたアプリケーションメタデータを、受信デバイスに知られているフィルタ処理および選択基準と比較する。そのようなフィルタ処理および選択基準は、受信デバイスに特に関係し、互換性のあるアプリケーションを特定するために有用な様々な情報(たとえば、モデル番号、キャリア識別子、地理的領域、サービスプラン、常駐アプリケーションなど)、ならびにデバイスユーザに向けられるアプリケーションと対話型イベントとを特定するために有用な様々な情報(たとえば、ユーザジェンダー、年齢層、所属、閲覧傾向、好み、要求サービスなど)の任意のものであり得る。
ステップ910において、アプリケーションマネージャは、受信のために選択されたアプリケーション、ならびにそれらの放送時刻、およびアプリケーションパッケージが受信され得る放送ストリームを特定し、受信のために、この情報を放送受信レイヤに与える。放送時刻および放送ストリーム情報は、ファイル配信オーバーヘッドメッセージから受信され得ることに留意されたい。受信レイヤは、物理レイヤとネットワークレイヤの両方を含み得る。ステップ912において、受信レイヤは、アプリケーションマネージャから受信された情報を使用して、放送ストリームから、選択されたアプリケーションを受信するために、受信回路をいつ起動すべきかを決定する。
受信したアプリケーションは、ユーザアクションに基づいて起動され得る。図10は、受信したアプリケーションを処理するために、モバイルデバイスにおいて実装され得る例示的な方法1000を示す。方法1000のステップ1002において、デコーダ802は、スケジュールされた時刻およびチャネルまたはストリームにおいて放送信号からアプリケーションパッケージを抽出する。ステップ1004において、受信したアプリケーションパッケージは、アプリケーションリソースを抽出し、すべてのアプリケーションリソースが取得されていることを検証するアプリケーションマネージャ806に渡される。ステップ1004の一部として、アプリケーションマネージャ806はまた、アプリケーションパッケージ内で指定されているが、含まれていない、共通のテンプレートまたはソフトウェアアセットをメモリから呼び戻し得る。ステップ1006において、アプリケーションマネージャ806は、実装のために利用可能である新しいアプリケーションを受信したことをユーザインターフェース812に通知する(矢印822によって図示)。ステップ1008において、ユーザインターフェース812は、新しいアプリケーションが受信されたことをユーザに通知するUI表示を生成する。ユーザインターフェース812はまた、アプリケーションが立ち上げられるべきかどうかを示すようにユーザに促し得る。ステップ1008の一部として、ユーザインターフェースは、アプリケーションが起動されるべきであることを示すユーザ入力を待ち得る。ユーザが、アプリケーションが起動されるべきであることを示す場合、ステップ1010において、ユーザインターフェース812は、アプリケーション実行ファイルとアセットとを与えるようにアプリケーションマネージャ806に要求する(矢印824によって図示)。ステップ1012において、レンダラ814はアプリケーションアセットとリソースとを受信し(矢印822によって図示)、メタデータに基づいて、提示のためにどのコンテンツコンテナ(たとえば、フラッシュプレーヤ816、ウェブキット818、またはネイティブスクリプト820)を使用すべきかを決定する。たとえば、アプリケーションがshockwaveファイルmime形式をもつツイッターアプリケーションである場合、レンダラは、フラッシュプレーヤコンテナ816を使用することを決定し得る。
アプリケーションを実装することの一部として、ステップ1014において、ユーザインターフェース812は、リアルタイムアプリケーションデータ更新に関係する対話型イベントの登録を行う(矢印826によって図示)。その後、ステップ1016において、ユーザインターフェースは、イベントマネージャ810を介してリアルタイムアプリケーション更新のためのイベントを受信する(矢印828によって図示)。
アプリケーションが受信され、検証されると、ユーザインターフェース812は、受信デバイスのユーザに、アプリケーションの利用可能性を知らせ得る。これは、新たに受信したアプリケーションをユーザに知らせるユーザ通知162をもつビデオ番組160を提示している受信デバイス106を示す、図3Aに示されている。
図3Aに示すユーザ通知は単一のアプリケーション通知であるが、より高度なユーザインターフェースが与えられ得る。一実施形態では、複数のアプリケーションがダウンロードされ得、起動のためにユーザが複数のアプリケーションを選択することを可能にするメニュー通知がユーザに提示され得る。このようにして、複数のアプリケーションは、受信デバイスが充電している間などに、受信デバイスによってダウンロードされ、次いで、カタログまたはオンラインアプリケーションストアと同様のメニューインターフェースにおいて提示され得る。ここで、違いは、アプリケーションがすでにメモリにキャッシュされていることである。この実施形態では、ユーザは、タッチスクリーンインターフェース上のアイコンにタッチするか、またはデバイスボタンを使用してアプリケーションを選択することによって、ユーザが実装することを望むアプリケーションを選択し得る。次いで、選択されたアプリケーションは、上記で説明したように実装され、一方、選択されなかったアプリケーションはある時点においてメモリから削除され得る。ダウンロードされたアプリケーションのこのユーザインターフェースカタログの一部として、ユーザは、メモリからアプリケーションを削除する選択肢を提示され得る。
さらなる実施形態では、ダウンロードされたアプリケーションのユーザ選択および拒否は、ユーザの好みについて知るために、受信デバイスによって使用され得る。このようにして、時間がたつにつれて、受信デバイスは、ユーザの好みに一致する可能性がより高いアプリケーションまたはアプリケーションのタイプをダウンロードするために選択または自動サブスクライブすることを可能にするフィルタ処理または選択基準を作成することができる。
様々な実施形態では、対話型イベントアプリケーションなどの受信したアプリケーションは、アプリケーション機能をリアルタイム放送コンテンツと同期させるように、放送ストリーム内で受信された信号に基づいて自動的に起動され得る。図11に、そのような同期されたアプリケーション起動を可能にするために受信デバイス上で実装され得る例示的な方法1100を示す。方法1100のステップ1102において、デコーダ802は、スケジュールされた時刻およびチャネルまたはストリームにおいて、放送信号からアプリケーションパッケージを抽出する。ステップ1104において、受信したアプリケーションパッケージは、アプリケーションリソースを抽出し、すべてのアプリケーションリソースが取得されていることを検証するアプリケーションマネージャ806に渡される。ステップ1104の一部として、アプリケーションマネージャはまた、アプリケーションパッケージ内で指定されているが、含まれていない、共通のテンプレートまたはソフトウェアアセットをメモリから呼び戻し得る。ステップ1106において、アプリケーションマネージャは、受信したアプリケーションが起動されるべきであることを示す信号を求めて、放送ストリームからの信号を視聴する。アプリケーションを起動するためのそのような信号は、放送バーヘッドストリーム内で、メタデータ804の形態で受信され得る。代替的に、イベントマネージャ810は、受信したアプリケーションが起動されるべきであることを示すイベントシグナリングメッセージ(ESM)を求めて、放送ストリームを視聴し得る。そのようなイベントシグナリングメッセージのためのフォーマットについては以下で開示する。
アプリケーションを起動するための信号を受信したことに応答して、アプリケーションマネージャ806は、ステップ1108において、アプリケーション実行ファイルとアセットとを、ユーザインターフェースに送る。ステップ1110において、レンダラ814はアプリケーションアセットとリソースとを受信し(矢印822)、メタデータに基づいて、提示のためにどのコンテンツコンテナ(たとえば、フラッシュプレーヤ816、ウェブキット818、またはネイティブスクリプト820)を使用すべきかを決定する。ステップ1112において、レンダラはアプリケーションを起動する。アプリケーションは、受信デバイス上に表示されているリアルタイムコンテンツと同期するように起動されるか、あるいは対話型イベントメタデータまたはシグナリングメッセージ中で特定された何らかの他の特定の時刻に起動され得る。
以下でより詳細に説明するように、対話型イベントの実際の開始時刻に先立って空中線上で放送されたイベントシグナリングメッセージは、変更、更新または終了され得る。これは、同じイベントIDと、更新されたイベントバージョン番号と、イベントステータスインジケータ(表示子)とを含む第2のイベントシグナリングメッセージを放送することによって達成され得る。同期されたアプリケーション起動イベントが放送された後に、アプリケーションプロバイダが、そのイベントを取り消すことを望み得るいくつかの理由があり得る。たとえば、アプリケーション起動イベントは、リアルタイムで発生するコンテンツ番組またはイベントにおける変化のために取り消され得る。たとえば、アプリケーションプロバイダは、スポーツイベントの結果に関連する2つの代替アプリケーションを放送し得る。次いで、アプリケーションプロバイダは、結果と関係しないアプリケーション起動を取り消し得る。
上記で説明したように、対話型放送サーバ5は、送信のためにファイル配信システム38に、必要な対話型イベントアプリケーションデータとリソースとテンプレートと(すなわち、受信デバイスが対話型イベントを生成するために必要とするデータとリソースとテンプレートと)を与え得る。対話型放送サーバ5はまた、放送ネットワーク1を介したオーバーヘッド情報フローによる送信のために、オーバーヘッドデータ配信システム36に与えられる対話型イベントシグナリングメッセージを生成し得る。図12は、図4を参照しながら上記で説明した実施形態に従って生成され、放送される対話型イベントシグナリングメッセージを受信し、処理するための、受信デバイスの中に実装され得る例示的な方法1200を示す。
図12は、受信デバイスにおいて、対話型イベントシグナリングメッセージ(IESM)を受信し、処理するための例示的な方法1200を示す。方法1200のステップ1202において、モバイルデバイス上で動作するアクティブな対話型アプリケーションは、対話型イベントを受信するために、アプリケーションマネージャに登録する。一実施形態では、対話型アプリケーションは、1つまたは複数のタイプの対話型イベントを受信するために登録し得る。アプリケーションマネージャへの対話型アプリケーションの登録は、図2に矢印2262によって示されている。
上記で説明したように、対話型アプリケーションは、1つまたは複数のタイプの対話型イベントを受信するために、アプリケーションマネージャに登録し得る。たとえば、アプリケーションマネージャが、アプリケーション識別子(ID)を指定する対話型イベントが受信され、処理されることを、保証することができるように、対話型アプリケーションは、それらのアプリケーションIDをアプリケーションマネージャに登録し得る。アプリケーションマネージャは、受信デバイスプロセッサにおいて機能するオーバーヘッドデータ獲得モジュールにアプリケーションIDを渡すことによって、これを達成する。オーバーヘッドデータ獲得モジュールは、FLOネットワークから受信されたオーバーヘッドフローから、登録されたアプリケーションIDに係る対話型イベントを選択的に受信し得る。オーバーヘッドデータ獲得モジュールはまた、対話型イベントを選択的に処理するためのフィルタ処理基準として、登録されたアプリケーションIDを使用し得る。様々な実施形態では、対話型アプリケーションはまた、対話型イベントアプリケーションデータのための追加のmimeタイプを登録し得る。これらの実施形態では、対話型アプリケーションは、登録されたmimeタイプをもつアプリケーションデータを有するイベントのみを受信することになる。様々な実施形態では、対話型アプリケーションは、一意のイベント名、一意のイベントタイプなどに基づく要求を発行することなど、特定の対話型イベントが放送チャネルオーバーヘッドフローから受信されることを要求するために、他の方法を使用し得る。一実施形態では、アウトオブバンドで送信された対話型イベントアプリケーションデータ(IEAD)は、ファイル配信フローから受信され、対話型イベントが開始するようにスケジュールされるまで、受信デバイスのメモリに格納され得る。
ステップ1204において、リソースマネージャモジュールは、図23Aを参照しながら以下で説明するロジックおよび方法に従って、ファイル配信システムから、対話型イベントに関係する対話型リソースとテンプレートファイルとを獲得する。ステップ1206において、オーバーヘッドデータ獲得モジュールは、放送バーヘッドフローから対話型イベントシグナリングメッセージ(IESM)を獲得する。オーバーヘッドデータ獲得モジュールは、受信デバイスが現在同調しているリアルタイムチャネル、受信のデバイスプロファイル、対象キャリアなどの様々な基準に基づいて、対話型イベントシグナリングメッセージをフィルタ処理し得る。すなわち、一実施形態では、オーバーヘッドデータ獲得モジュールは、視聴されている現在のリアルタイムサービスと他の一致するフィルタ処理基準と向けられている対話型イベントシグナリングメッセージのみを獲得するように構成され得る。他の実施形態では、リアルタイムサービスに結びつけられていない対話型イベントシグナリングメッセージ(たとえば、アンバウンド対話型イベントシグナリングメッセージ)は、それが、デバイスタイプ、対象とされるキャリア、ユーザ人口統計などの他のフィルタ処理基準を満たすことを条件とし、その対話型イベントシグナリングメッセージは、どのリアルタイムサービスが視聴されているかにかかわらず、任意の時刻に獲得され得る。
ステップ1208において、オーバーヘッドデータ獲得モジュールは、獲得された対話型イベントシグナリングメッセージ(IESM)を、対話型イベントマネージャに渡す。これは、図2に矢印2802によって示される。ステップ1210において、対話型イベントマネージャは、イベントフィルタ処理を実行し、受信デバイスにまたはデバイスの現在の状態に適用可能でない対話型イベントシグナリングメッセージをドロップする(すなわち、保存しない)かまたは受信しない。対話型イベントマネージャはまた、対話型イベントを再生するために必要な必須のリソースまたはテンプレートが、ステップ1204においてリソースマネージャからすでにダウンロードされているかどうかを決定し得る。一実施形態では、対話型イベントは、必須のリソースまたはテンプレートが対話型イベント時刻に利用可能でない場合、再生されないことになる。一実施形態では、対話型イベントマネージャは、対話型イベントシグナリングメッセージ中に含まれるターゲット基準に基づいてイベントフィルタ処理を実行し得る。
ステップ1212において、対話型イベントマネージャは、フィルタ処理された対話型イベントをアプリケーションマネージャに渡す。アプリケーションマネージャは、ステップ1214において、受信した対話型イベントを受けるために、すでに登録された対話型アプリケーションがあるかどうかを決定する。この決定は、アプリケーションID、イベントアプリケーションデータのmimeタイプ、イベント名、イベントタイプ、または対話型イベントシグナリングメッセージ(IESM)内に含まれる同様の情報に基づき得る。受信した対話型イベントがどの登録された対話型アプリケーションにも一致しない場合(すなわち、決定ステップ1214=「いいえ」)、ステップ1216において、受信されたイベントは無視される。
対話型イベントを受信するためにアプリケーションマネージャに登録された対話型アプリケーションのうちの1つまたは複数が、受信した対話型イベントシグナリングメッセージと一致する場合(すなわち、決定ステップ1214=「はい」)、ステップ1218において、アプリケーションマネージャは、ユーザインターフェース内のユーザエージェントを介して、適切な対話型アプリケーションに、対話型イベントを送る。一実施形態では、ユーザエージェントは、対話型イベントを正しい対話型アプリケーションにルーティングする機能を実行し得る。
ステップ1220において、対話型イベントを受信した対話型アプリケーションは、デバイスファイルシステムからの必要なリソースとテンプレートとにアクセスし、これらのリソースおよび/またはテンプレートを、必要な対話型表示および機能を組み立てまたは生成するために使用する。ステップ1222において、対話型アプリケーションは、対話型イベントシグナリングメッセージ中で受信されたイベントアプリケーションデータに基づいて、対話型コンテンツを表示する。
いくつかの対話型イベントは時刻的に重複し得るので、受信デバイスは、2つ以上の重複イベントのいずれが、いつ表示されるべきかを決定するように構成され得る。受信デバイスにおいてこの決定を実行することは、放送側でのスケジューリングおよびフォーマッティングを簡略化し、受信デバイスが、デバイス固有イベント(たとえば、受信エリア間の移動、チャネルの切替え、対象の基準に関係するデバイス情報)から生じる重複イベントを管理することを可能にし得る。たとえば、大部分の受信デバイスは、両方(またはそれ以上)の基準に一致しない一方で、一部の受信デバイスは、時刻的に重複する2つ(またはそれ以上)の対話型イベントのためのターゲッティング基準に一致し得る。受信デバイスにおいて2つ以上の対象とされる対話型イベントの中で選択することは、2つ以上の基準に一致する少数のデバイスに係るイベントの競合解消について心配する必要なしに、対話型イベントサプライヤおよび放送事業者が対象となるイベントを生成することを可能にする。受信デバイスが、対話型イベントサプライヤまたは放送事業者に好まれる方法で、競合する対話型イベントの中で選択を行うことを可能にするために、対話型イベントは、対話型イベントシグナリングメッセージ内に含まれ得る優先度値を割り当てられ得る。
図13に、設定された優先度値に基づいて重複する対話型イベントに応答するために受信デバイスが実装し得る例示的な方法1300を示す。方法1300は、ステップ1214とステップ1218との間に実装され得るステップを追加して、図12を参照しながら上記で説明した方法1200を補足する。
上記で説明したように、ステップ1214において、アプリケーションマネージャは、受信した対話型イベントを受けるために、すでに登録された対話型アプリケーションがあるかどうかを決定する。受信デバイスプロセッサが、受信した対話型イベントのためにアプリケーションが登録されていると決定した場合(すなわち、決定ステップ1214=「はい」)、図13の方法1300の決定ステップ1302において、プロセッサは、受信した対話型イベントが、別の前に受信した対話型イベントと重複するかどうかを決定する。前に受信した対話型イベントとの重複がない場合(すなわち、決定ステップ1302=「いいえ」)、プロセッサは、図12を参照しながら上記で説明したように、ステップ1218に進み得る。しかしながら、受信した対話型が別の対話型イベントと重複する場合(すなわち、決定ステップ1302=「はい」)、プロセッサは、ステップ1350において、対話型イベントシグナリングメッセージから重複イベントの各々のためのイベント優先度を取得する。
決定ステップ1352において、プロセッサは、イベント優先度を比較して、それらが等しいかどうかを決定する。イベント優先度が等しい場合(すなわち、決定ステップ1352=「はい」)、プロセッサは、ステップ1354において、より遅く開始する対話型イベントを実装または無視するためのデフォルトルールを適用する。一実施形態では、デフォルトルールは、より遅く開始する対話型イベントが、より早く開始する対話型イベントにとって代わることであってもよい。この場合、より遅く開始する対話型イベントは、それの開始時刻に実装されることになる。別の実施形態では、デフォルトルールは、より遅く開始する対話型イベントが、より早く開始する対話型イベントにとって代ることがないことでもよい。この場合、より遅く開始する対話型イベントは、無視される(方法1200のステップ1216)か、またはより早く開始する対話型イベントが終了したとき(すなわち、より早く開始する対話型イベント有効時間が満了したとき)に起動されるように、キューの中に維持され得る。
上記で説明したように、決定ステップ1352において、プロセッサは、イベント優先度を比較して、それらが等しいかどうかを決定する。対話型イベント優先度が等しくない場合(すなわち、決定ステップ1352=「いいえ」)、決定ステップ1356において、プロセッサは、より早く開始する対話型イベント(いくつかの状況では現在アクティブな対話型イベントであり得る)が、より高い優先度を有するかどうかを決定する。より早く開始する対話型イベントが、より遅く開始するイベントよりも低い優先度を有する場合(すなわち、決定ステップ1356=「いいえ」)、プロセッサは、図12を参照しながら上記で説明したように、ステップ1218に進むことによって、より遅く開始する受信した対話型イベントを、通常の機能のために処理する。より早く開始する対話型イベントが、より遅く開始するイベントよりも高い優先度を有する場合(すなわち、決定ステップ1356=「はい」)、プロセッサは、より遅く開始する対話型イベントを無視するか、またはより早く開始する対話型イベントが終了したときに起動されるようにキューの中に保持する(ステップ1358)。3つ以上の重複対話型イベントが受信された場合、プロセッサは、所与の時刻にどの対話型イベントを実装すべきかを決定するために、方法1300に示すものと同様のステップを実装し得る。
対話型イベントを選択するためにデバイスによって使用される、上記の優先度、およびプリエンプション(とって代るための)ロジックは、ユーザの体験に影響を及ぼし得る。このために、一実施形態では、デバイスによって使用されるプリエンプションロジックは、受信デバイス上のメモリに格納された構成/供給パラメータによって制御され得る。この構成パラメータは、受信デバイスのユーザが、デバイス、表示されたコンテンツ、システムの対話型機能に対してより大きい制御を有することを可能にし得る。たとえば、ユーザは、対話型イベントが途中から開始すること、または理解するには余りにも短すぎる期間の間しか実行されないことによるいらつきを避けるために、競合の場合に、2番目に到着するかまたは低優先度の対話型イベントを無視することを選択し得る。
図14A〜図16Cに、様々な実施形態による対話型イベントシグナリングメッセージ(IESM)において使用するのに好適な例示的なデータの形式を示す。図14Aを参照すると、対話型イベントシグナリングメッセージ70は、メッセージ識別子721と、イベント識別子722と、イベントバージョン番号723と、イベントステータス724と、イベント開始時刻725と、イベント持続時間または終了時刻726とを有する属性データ72を含み得る。メッセージ識別子721は、イベントシグナリング情報を搬送するメッセージを特定し得る。イベント識別子722は、特定の対話型イベントのための一意の識別子を与え得る。イベントバージョン番号723は、対話型イベントシグナリングメッセージのバージョンを示し、それによって、受信デバイスが特定のシグナリングメッセージをすでに受信したかどうかを決定することを可能にする。イベントステータス724フィールドは、イベントが現在アクティブであるかまたは停止しているのかを示すためになど、対話型イベントのステータスを示し得る。一実施形態では、イベントステータス724フィールドは、イベントがすでに停止し、したがって、受信デバイス上に表示されるべきでないことを示すために更新される。イベント開始時刻725フィールドは、絶対UNIX(登録商標)時間フォーマットでなど、受信デバイスが理解することができる形式でイベントの開始時刻を示し得る。イベント持続時間または終了時刻726は、イベント開始時刻(データフィールド725中に与えられる)からの秒数でイベントの持続時間を示し得る。代替的に、イベント持続時間または終了時刻726は、絶対UNIX時間形式でなど、受信デバイスが理解することができる形式で終了時刻を示してもよい。
図14Bは、図13を参照しながら上記で説明したように、イベント優先度によって複数の対話型イベントシグナリングメッセージを受信することをサポートする、対話型イベントシグナリングメッセージ(IESM)のための例示的なデータの形式を示す。具体的には、図14Bは、対話型イベントシグナリングメッセージ70が、イベントの持続時間を数で示すイベント持続時間726要素を有し得ることを示す。一実施形態では、イベント持続時間726は、イベント開始時刻725からの秒数を示す。対話型イベントシグナリングメッセージ70はまた、図13を参照しながら上記で説明したように、2つ以上の対話型イベントシグナリングメッセージが重複するような、重複イベントの状況のためにイベント優先度を指定するイベント優先度フィールド727を含み得る。
図15および図16Aは、対話型イベントアプリケーションデータ、リソースおよびテンプレートのインバンド配信を可能にする、対話型イベントシグナリングメッセージ(IESM)のための例示的なデータの形式を示す。対話型イベントアプリケーションデータ、リソースおよびテンプレートのアウトオブバンド配信を可能にするために、対話型イベントシグナリングデータの形式は、図16Bおよび図16Cに示すように、これらのリソース、アセットおよびテンプレートのための識別子を搬送する。様々な実施形態では、単一の汎用の形式が、イベントアプリケーションデータとリソースとテンプレートとのインバンド配信およびアウトオブバンド配信の両方をサポートするために使用され得ることに留意されたい。
図15を参照すると、対話型イベントシグナリングメッセージ70は、対象となるリアルタイムサービスなどの、対話型イベントが表示されるべき1つまたは複数のサービスの識別子を与える、サービス識別子80を含み得る。対話型イベントシグナリングメッセージ70は、イベントが向けられている1つまたは複数の対話型アプリケーションのための識別子を含み得る、アプリケーション識別子81を有する。アプリケーション識別子81は、上記で説明したように、アプリケーションマネージャに登録した対話型アプリケーションから受信されるアプリケーションIDと比較される。様々な実施形態では、対話型イベントシグナリングメッセージ70はまた、課金および顧客サービスプロバイダ(BCS:billing and customer service provider)を有し、それはBCS(たとえば、VZWまたはAT&T)と、対話型イベントが対象とする関連デバイスプロファイル(たとえば、イベントをVerizon BCS上のすべてのデバイスに向ける)とをリストし得る。
図15は、対話型イベントシグナリングメッセージ70がまた、対話型イベントが実行/表示されるべきエリアをリストし得る、適用可能なエリア(領域)のデータフィールド84を含み得ることを示す。受信デバイスが特定された適用可能なエリア内に現在位置する場合のみ、対話型イベントが実行されるように、これらのエリア(領域)は、地理的座標、アクセスされた送信機の識別子、放送ネットワークによって定義されたインフラストラクチャエリア識別子、または他のタイプの地理的情報に関して定義され得る。たとえば、MediaFLOネットワークでは、適用可能なエリアは、ワイドエリアオペレーションインフラストラクチャ識別子(wide-area operation infrastructure identifier (WOI ID))および/またはローカルエリアオペレーションインフラストラクチャ識別子(local-area operation infrastructure identifier (LOI ID))によって特定され得る。
様々な実施形態では、対話型イベントシグナリングメッセージ70はまた、対話型イベントのためのアプリケーションデータ関係情報を指定し得る、アプリケーションデータ情報86を含み得る。アプリケーションデータ情報86は、アプリケーションデータを搬送するファイルのためのリソース識別子を含み得るか、またはイベントシグナリングメッセージ中にアプリケーションデータをインバンドで含み得る。対話型イベントシグナリングメッセージ70はまた、対話型イベントのためのテンプレートデータ関係情報を指定し得る、テンプレート情報86Aを含む。テンプレート情報は、事前ダウンロードされたレイアウトテンプレートデータのためのテンプレート識別子を含み得るか、または対話型イベントシグナリングメッセージ中にテンプレートデータをインバンドで含む(たとえば、新しいテンプレートを使用する急なイベントのため)。対話型イベントシグナリングメッセージ70はまた、対話型イベントのためのリソース関係情報を指定し得る、リソース情報88を有する。そのようなリソース情報88は、受信デバイスが対話型イベントを実装/表示するためにメモリから呼び戻すべき必要なリソースを特定し得る。
図16Aは、適用可能なBCS82が、BCSのための識別子828、包まれるデバイスプロファイル824、および除外されるデバイスプロファイル826などの属性822を含み得ることを示す。包まれるデバイスのプロファイル824は、対話型イベントが実行されるべきデバイスプロファイルをリストし、一方、除外されるデバイスのプロファイル826は、イベントが実行されるべきでないデバイスプロファイルをリストする。一実施形態では、包まれるデバイスプロファイル824または除外されるデバイスプロファイル826のいずれか一方のみが、適用可能なBCS82中に存在してもよい。
上述のように、対話型イベントデータ、リソースおよびテンプレートは、対話型イベントシグナリングメッセージの一部としてインバンドで、または対話型イベント配信に先立ってファイル配信データフローにおいてアウトオブバンドで放送され得る。イベントアプリケーションデータ、リソースおよびテンプレートをアウトオブバンドで放送することは、対話型イベントを実装するために必要な帯域幅を節約することができる。上記で説明したように、対話型イベントアプリケーションデータ、リソースおよびテンプレートのアウトオブバンド配信を可能にするために、対話型イベントシグナリングデータの形式は、図16Bおよび図16Cに示すように、これらのリソース、アセットおよびテンプレートのための識別子を搬送する。
図16Bを参照すると、対話型のためのアプリケーション関係情報を指定するアプリケーション情報87は、アプリケーションデータがインバンドで含まれるかどうかを示すアプリケーションデータインバンド属性872、アプリケーションデータを含んでいるリソースを特定し得るアプリケーションデータリソース属性ID874、およびインバンドアプリケーションデータに係るmimeタイプを示すmimeタイプ属性876などの属性を含み得る。さらに、アプリケーション情報は、インバンドアプリケーションデータを与えるアプリケーションデータ878を含み得る。アプリケーションデータがアウトオブバンドで配信される場合、アプリケーションデータリソース属性ID874は、関連するアプリケーションデータを搬送するファイルリソースの識別子を特定する。
図16Cを参照すると、対話型イベントシグナリングメッセージ70内のリソース情報88は、いくつかの属性とリソースデータ886とを含み得る。それらの属性は、リソースに係る識別子を与えるリソースID属性881、リソースがインバンドで含まれるかどうかを示すリソースインバンド属性882、リソースが特定の対話型イベントにとって必須かどうかを指定するリソース必須属性883、リソースがこの特定の対話型イベントのためにのみ使用されることを指定するイベント固有属性884、およびインバンドリソースに係るmimeタイプを示すmimeタイプ属性885を含み得る。リソースがインバンドで与えられる(リソースインバンド属性882に示すように)場合、リソースデータ886は特定されたリソースデータを含むことになる。
一実施形態では、対話型イベントの実際の開始時刻に先立って空中線で放送される対話型イベントは、それらの初期放送後に、変更、更新または終了され得る。図14A〜図16Cに示すメッセージの形式は、メッセージID721、イベントID722、イベントバージョン723、およびイベントステータス(イベントの状態)724などのデータフィールドを用いて、そのような更新および終了を可能にする。対話型イベントが放送された後、対話型コンテンツプロバイダがそれを取り消すことを望むいくつかの理由があり得る。たとえば、対話型イベントは、リアルタイムで発生するコンテンツ番組またはイベントにおける変化のために取り消され得る。たとえば、対話型コンテンツプロバイダは、スポーツイベントの結果に関連する2つの択一的な対話型イベントを放送し、次いで、その結果に関係しない対話型イベントを取り消し得る。これらの機構を使用して、対話型コンテンツプロバイダは、視聴者が、スーパーボウルで勝ったチームに適した記念品を注文することを可能にし、次いで、敗れたチームに対応する対話型イベントを取り消すことができるような、対話型イベントを事前に放送することができる。このようにして、対話型イベントは、結果がわかった後に対話型イベントを作成し、放送するために必要になるであろう遅延なしで、視聴者が勝ったチームの記念品を購入することを可能にするため、対話型イベントは、受信デバイス上に直ちに表示され得る。
対話型イベントを停止するかまたは取り消すという決定が行われたとき、前に放送されたイベントシグナリングメッセージを更新するかまたは置き換え、イベントが取り消されるかまたは停止されることを示す、対応する対話型イベントシグナリングメッセージが放送され得る。たとえば、受信デバイスが、そのメッセージを、更新されたシグナリングメッセージとして認識するように、対話型イベントシグナリングメッセージは、イベントバージョン723中で新しいバージョン番号を示し、イベントステータス724中でイベントが取り消されたことを示す。対話型イベントを終了するために必要な唯一の情報は、イベントID722とイベントバージョン723とイベントステータス724とを特定する属性であるので、イベントを終了するために必要な対話型イベントシグナリングメッセージは、とても短く、そのような終了シグナリングに必要な帯域幅の量を低減し得ることに留意されたい。受信デバイス上の対話型イベントマネージャが、イベントが取り消されたことを示す更新された対話型イベントシグナリングメッセージを受信するとき、その対話型イベントがまだ開始していない場合、それをメモリから削除し得る。その対話型イベントがすでに開始している場合、対話型イベントマネージャは、アプリケーションマネージャに、イベントを停止するように通知し得る。アプリケーションマネージャは、表示されている対話型を終了し、および/または取り消すようにアプリケーションに通知する対話型イベント停止信号を、対話型アプリケーションに送り得る。同様にして、前に放送された対話型イベントシグナリングメッセージは、追加のリソースまたはテンプレートを特定するか、あるいはイベントに関連するメタデータまたはアプリケーションデータの一部を変更するためなどのように、更新され得る。
さらなる実施形態では、対話型イベントシグナリングメッセージは、重複する対話型イベントを調整するように構成され、受信デバイスによって処理され得る。図12を参照しながら上記で説明したように、様々な実装形態およびプログラミング状況では、単一のコンテンツフロー上で提示される2つ以上の対話型イベントは、時間的に重複し得る(すなわち、それらの有効時間は重なり得る)。そのような状況の別の例は、広告に関連する対話型イベントをも含む、投票対話型イベント(たとえば、好きな芸能人、音楽ビデオまたは曲についての投票)を含む、リアルタイム放送番組またはコンテンツフローである。この例では、投票対話型イベントは、ユーザ投票入力を促し、受信するためのユーザインターフェース表示を含み得、広告対話型イベントは、ユーザが広告されているアイテムを購入することを可能にするための、オンライン注文ユーザインターフェースであり得る。いくつかの重なり合う状況では、放送事業者または番組/コンテンツプロバイダが、広告対話型イベントを提示するためになど、第1の起動された対話型イベントが第2(および第3など)の起動された対話型イベントによって中断されることを希望する。他の重なり合う状況では、第1に現れる対話型イベントは、第1の対話型イベントが高優先度イベントであるときなど、後続の対話型イベントによって中断されるべきではない。2つ以上の対話型イベントが同時にまたはほぼ同時に開始するようにスケジュールされた状況では、図13を参照しながら上記で説明した方法1300など、受信デバイスが、どの対話型イベントを提示すべきかを決定することができる機構があり得る。
図13を参照しながら上記で説明したように、2つ以上の重なった対話型イベントのいずれがユーザに表示されるべきかを決定することを、受信デバイスに可能にするために、対話型イベントシグナリングメッセージは、優先度値を含み得る。図14Bは、メッセージ属性の一部としてeventPriority727の値を含む、対話型イベントシグナリングメッセージ70に係るシステム情報データの形式を示す。この実施形態では、対話型ヘッドエンドシステムは、各対話型イベントに優先度を割り当て得る。一実施形態では、対話型ヘッドエンドシステムが特定の優先度を割り当てない場合、すべての対話型イベントは、デフォルト優先度(たとえば、低優先度)を割り当てられ得る。さらに、受信デバイスは、2つ以上の重なり合う対話型イベントをどう扱うか決定するための対話型ロジック、例えば、同じ優先度のより遅く開始するイベントによって現在のイベントを常に中断するか、または同じ優先度のより遅く開始するイベントによって現在のイベントを決して中断しないなど、を用いて構成され得る。このようにして、放送事業者または番組/コンテンツプロバイダは、対話型イベントシグナリングメッセージ中で通信される第1または第2の優先度イベントのいずれかの優先度を設定することによって、第1に開始する対話型イベントがより遅く開始する重なった対話型イベントによってとって代られるかどうかを制御し得る。
図13を参照しながら上記で説明した例示的な方法1300は、受信デバイスが、イベントの特定の状況、イベントの優先度およびユーザ設定に従って、笠名あった対話型イベントをどのように扱うかを決定することを可能にする。たとえば、対話型イベントに係るデフォルト優先度設定が低優先度であり、2つのイベントが同じ優先度を有するときに、より遅く開始する対話型イベントを起動するロジックを用いて受信デバイスが構成された実装形態では、同じ優先度をもつ重なったイベントを受信した場合、受信デバイスは、対話型イベントをそれらの開始時刻順で示すことになる。複数の同じ優先度イベントが同時に開始するようにスケジュールされる場合、受信デバイスは、対話型イベントを、それらの獲得順(すなわち、第1の対話型イベントシグナリングメッセージが受信された順序)で表示し得る。対話型イベントが終了するとき、同じ優先度の第2の対話型イベントがまだ有効である(イベントの有効時間に基づいて)場合、第2の対話型イベントはユーザに表示され得る。
様々な実施形態では、ある対話型イベントを他のデフォルト優先度対話型イベントの上に表示する(すなわち、とって代る)ことを意図している場合、オペレータは、そのイベントに、より高い優先度を手動で割り当てることができる。代替的に、優先度はまた、ヘッドエンドシステムにおいてプログラムされた何らかのビジネスロジックに基づいて割り当てられ得る。0から9までの数値など、複数レベルの優先度が、ヘッドエンドシステムによって対話型イベントに割り当てられ得る。イベント優先度の値を含む対話型イベントシグナリングメッセージデータの形式については、図14Bを参照しながら上記で説明した。
上記で説明したように、対話型イベントシグナリングメッセージが放送されるときに送信されなければならないデータ量を低減するため、および所与の放送帯域幅内でよりロバスト(頑強)な表示を可能にするために、対話型イベントは、事前に放送され、受信デバイスに格納されたリソースおよびテンプレートを使用し得る。そのようなリソースおよびテンプレートはまた、複数のイベントおよび複数のイベントのタイプにおいて使用され得る、標準化された表示とレイアウトと画像と機能とを含み得る。このようにして、対話型イベントシグナリングメッセージは、受信デバイスによって実装されるべき1つまたは複数のリソースおよびテンプレートを指定し、特定のテンプレート実装に関連付けられることになるデータを与える。たとえば、単純な標準テンプレートは、対話型イベントシグナリングメッセージの中で与えられるテキストのために、表示部の下部に沿って配置される、フォーマット済みテキストをもったバナーを与え得る。バナーテンプレートIDを指定し、ASCIテキストデータを含めることによって、少量のデータを備える対話型イベントシグナリングメッセージが、様式化されたテキストバナー表示を生成できる。
様々な実施形態では、リソースおよびテンプレートを使用することにより、システムは、ほぼ無限の数の機能を実装することが可能になる。リソースの例は、ソフトウェアモジュール、API、フラッシュスクリプト、およびXMLスクリプトがある。テンプレートの例には、バナー、ボーダー、画像、ユーザインターフェース画像、およびユーザ入力定義がある。リソースおよびテンプレートは、OEM構成の一部としてなど、受信デバイス上にプリロードされ、空中線上で展開および更新され得る。リソースおよびテンプレートがどのように空中線上で送信および更新され得るかについてのより詳細な説明は、以下で図22〜図24Dを参照しながら行う。
テンプレートは、XMLスクリプト、Cコードデータ定義、htmlスクリプト、および図17にその例を示すデータテーブルを含む、任意の知られているデータ構造を使用して構築され得る。たとえば、テンプレートデータテーブル1700は、各々が複数のデータフィールドから構築される複数のテンプレート1720〜1728を格納し得る。たとえば、テンプレートは、ほんのいくつかの例を挙げれば、テンプレートIDデータフィールド1702、互換性または適用性データフィールド1704、表示座標データフィールド1706、形状・色または塗りつぶしデータフィールド1708、テキストフォントデータフィールド1710、シャドーイング効果データフィールド1712、およびグラフィックス機能またはフラッシュデータフィールド1714を含み得る。図17に示すデータフィールドは、テンプレート中に実装され得る情報のタイプの例として与えられており、テンプレートは、この図に示すよりもはるかに多い特徴および要素を含み得ることが想定される。
テンプレート表示1702は、受信デバイスメモリにテンプレートをダウンロードするかまたは更新するため、ならびに対話型イベントシグナリングメッセージ中のテンプレートの使用を特定するためになど、特定のテンプレートを参照するための、利便性のある索引を与える。互換性または適用性データフィールド1704は、テンプレートが適用可能である、受信デバイスまたは対話型アプリケーションの特定のタイプを特定するために有用であり得る。このようにして、その受信デバイスに互換性があるかまたは適用可能なテンプレートのみが受信され、メモリに格納されるように、受信デバイスは、モバイル放送システムを介して放送されたテンプレートをフィルタ除去し得る。
テンプレートは、対話型イベント表示においてデータがどのように提示され得るかを定義する、いくつかの特性データフィールド1706〜1714を含み得る。たとえば、テンプレートは、テキストまたは画像のための特定の位置と、形状に適用されるべき色または塗りつぶしのパターンと、受信したデータが提示されるべきフォント(たとえば、スタイルおよびサイズ)と、シェーディング、フラッシュ、シャドーなど、適用されるべき強調またはグラフィカル特性とを指定し得る。このようにして、メッセージ内で特定のテンプレートを指定し、テンプレート中で使用されるべきデータを含めることによって、情報の多種多様な異なるグラフィカル表現が、比較的小さい対話型イベントシグナリングメッセージから、対話型イベントに実装され得る。
表示レイアウトおよびレンダリング情報に加えて、テンプレートファイルはまた、対話型イベント内で実装されるべき機能、特に、様々なユーザ入力に応答して実行されるべき機能またはルーチンを、指定し得る。ユーザ対話型イベントは、一般に、放送ネットワーク、対話型コンテンツプロバイダ、コンテンツプロバイダ、または広告主などの別の当事者との情報の受送信を必要とする、投票、商品の注文、調査への応答によってなど、ユーザが好みを表すことに関与する。上述のように、ユーザ入力情報のそのような通信は、ユニキャストネットワーク11(図1A参照)を介して、IPデータ呼、電子メール、SMSメッセージ、MMSメッセージなど、様々なデータメッセージング技術およびプロトコルを使用し、インターネット上のウェブページにアクセスして、達成され得る。対話型イベントシグナリングメッセージ中に含まれなければならない情報量を最小限に抑えるために、通信方法またはプロトコル、アドレス、データフォーマット、および他のシグナリング仕様は、テンプレートファイル中で特定され得る。たとえば、投票イベントのために有用なテンプレートは、異なるユーザ投票選択に対応する様々なユーザ入力が、受信のために適切なフォーマットで特定のメッセージ宛先に送信されることを指定し得る。たとえば、IPデータ呼、電子メール、SMSメッセージ、MMSメッセージのうちの1つによって、および/またはインターネット上のウェブページにアクセスすることによって、ユーザ入力が、指定されたIPアドレスに送信されることを、テンプレートは指定し得る。
上記で説明したように、テンプレートは、対話型イベントに先立って放送され得、また、デバイスOEMにおいてまたはサービスキャリアによって与えられる構成中に含まれ得る。テンプレートは、利用可能な帯域幅を活用するために、午前2時と午前6時の間など、ユーザがコンテンツを視聴している可能性の低い時間帯の間に放送および更新され得る。また、ユーザが、いつテンプレートがダウンロードまたは更新されているのか気づかないように、テンプレートは、バックグラウンドで放送され得る。上述のように、テンプレートは、モバイル放送システムのファイル配信サービスを介して送信され得る。
図18は、テンプレートを使用して対話型イベントを実行するために受信デバイスプロセッサにおいて実装され得る、例示的な方法1800を示す。方法1800のステップ1802において、対話型イベントシグナリングメッセージを受信する受信デバイスプロセッサは、1つまたは複数のテンプレートのための識別子(たとえば、テンプレートID)を含む様々なデータ要素を取得するために、そのメッセージをアンパックする(パックを解く)。対話型イベントシグナリングメッセージのこのアンパッキングは、上記で説明したように、プロセッサ上で動作する対話型イベントマネージャモジュールによって達成され得る。ステップ1804において、対話型イベントマネージャは、リソースマネージャまたはリソースメモリから、イベントシグナリングメッセージ中で指定された任意のテンプレートを取り出す。ステップ1806において、対話型アプリケーションは、レンダリングのための表示要素を生成するために、対話型イベントシグナリングメッセージの中で受信されたデータ要素を、取り出されたテンプレート中に挿入する。ステップ1808において、対話型アプリケーションは、テンプレート中で指定された特定の入力機能またはアドレスにボタンまたはタッチスクリーン座標を割り当てる。このようにして、対話型イベントは、テンプレートにおいて定義されている特定のボタンまたはタッチスクリーンアイコンを用いて、特定の対話型イベントに合致するユーザ入力を受信し、処理するように構成され得る。
上記で説明したように、単一の対話型イベントに複数のテンプレートが実装され得る。したがって、決定ステップ1810において、対話型アプリケーションは、別のテンプレートがシグナリングメッセージ中で指定されているかどうかを決定する。別のテンプレートがシグナリングメッセージ中で指定されている場合(すなわち、決定ステップ1810=「はい」)、対話型アプリケーションは、ステップ1806に戻ることによって、レンダリングのための表示要素を生成するために、データを次のテンプレート中に挿入する。すべての指定されたテンプレートが実装されているとき(すなわち、決定ステップ1810=「いいえ」)、対話型アプリケーションは、ステップ1812において、受信デバイスディスプレイ上での提示のために、生成された表示要素をディスプレイドライバに転送する。対話型表示を提示しながら、受信デバイス上のプロセッサは、ステップ1814において、ユーザ対話型入力を受け付けるために待機し、ステップ1816において、プロセッサは、テンプレート中、および、対話型イベントシグナリングメッセージ中に含まれるアプリケーションデータまたは実行可能スクリプト中で指定されれば、受信されるユーザ入力に関連するどんな対話型機能でも実行し得る。
上述のように、テンプレートは、空中線上でダウンロードされ、更新され得、その例示的な方法1900を図19に示す。方法1900のステップ1902において、受信デバイスは、放送システムから電子カタログ更新を受信する。電子カタログは、オーバーヘッドフロー上で送信され得るか、またはファイル配信システム上でファイルとして送信され得る。決定ステップ1904において、受信デバイスのプロセッサは、受信した電子カタログが何らかのテンプレート更新をリストしているかどうかを決定する。何のテンプレート更新もリストされていない場合(すなわち、決定ステップ1904=「いいえ」)、プロセッサは、ステップ1906において、受信した電子カタログの通常の処理に戻る。1つまたは複数のテンプレート更新が、受信した電子カタログにリストされている場合(すなわち、決定ステップ1904=「はい」)、プロセッサは、ステップ1908において、電子カタログからテンプレート更新に関連するメタデータを取得する。ステップ1910において、プロセッサは、カタログ中のテンプレートリストから第1のテンプレートを選択し、決定ステップ1912において、そのテンプレートが受信デバイスに適用可能であるかまたは互換性があるかどうかを決定する。この決定は、受信デバイスが、その受信デバイスに非互換であるかまたは適用可能でないテンプレートをダウンロードすることを回避することを可能にする。テンプレートが互換であると決定された場合(すなわち、決定ステップ1912=「はい」)、プロセッサは、決定ステップ1914において、テンプレートがいずれかの登録された対話型アプリケーションに関係するかどうかを決定することなど、さらなるフィルタ処理を実行する。テンプレートが1つまたは複数の登録された対話型アプリケーションに関係すると決定された場合(すなわち、決定ステップ1914=「はい」)、プロセッサは、決定ステップ1916において、カタログにリストされているテンプレートバージョン番号が、メモリに格納されたテンプレートのバージョン番号よりも大きいかどうかを決定することによってなど、リストされたテンプレートがメモリにすでに格納されたテンプレートよりも新しいバージョンであるかどうかを決定する。リストされたテンプレートバージョン番号が、テンプレートがメモリに格納されたテンプレートよりも新しいバージョンであることを示す場合(すなわち、決定ステップ1916=「はい」)、プロセッサは、ステップ1918において、示された放送時刻での受信のために、リストされるテンプレートを指定する。ステップ1918において受信のためにテンプレートを指定した後、あるいはテンプレートが適合しない(すなわち、決定ステップ1912=「いいえ」)、無関係である(すなわち、決定ステップ1914=「いいえ」)、またはメモリに格納されたテンプレートよりも新しいバージョンでない(すなわち、決定ステップ1916=「いいえ」)との決定に基づいて、プロセッサは、決定ステップ1920において、別のテンプレートがカタログにリストされているかどうかを決定する。別のテンプレートがリストされている場合(すなわち、決定ステップ1920=「はい」)、プロセッサは、評価のために次のテンプレートを選択するために、ステップ1910に戻り得る。カタログにリストされているすべてのテンプレートが評価されると(すなわち、決定ステップ1920=「いいえ」)、プロセッサは、ステップ1922において、受信した電子カタログの通常の処理に戻る。
図20Aは、テンプレートとテンプレート更新とを空中線で受信するための、受信デバイス上に実装され得る例示的な方法2000を示す。カタログにリストされているテンプレートが受信のために指定されているとき、この情報は、指定されたテンプレートを受信する(ステップ2002)ために、電子サービスガイド、カタログまたは別のファイル配信オーバーヘッドフローの中で示された時刻にファイル配信フローを視聴し得るファイルシステムモジュールに、伝達され得る。ステップ2004において、受信したテンプレートは、メモリに格納される。ステップ2006において、リソースマネージャが、対話型イベントを実行する処理の一部としてテンプレートを取り出すことができるように、受信され、格納されたテンプレートは、リソースマネージャに登録される。代替的に、リソースマネージャは、ファイルシステムモジュールからテンプレートを受信し、それをリソースマネージャによって索引付けされた位置においてメモリに格納し得る。
図20Bに、対話型生成システムが対話型イベントシグナリングメッセージを生成する処理の一部としてテンプレートを使用し得る例示的な方法2050を示す。ステップ2052において、対話型生成システムを使用するオペレータは、受信デバイス上に表示されるべき対話型要素を定義する際に使用する1つまたは複数のレイアウトテンプレートを選択し得る。次いで、オペレータは、ステップ2054において、選択されたテンプレート中に挿入されるべきデータ要素を指定または定義する。一実施形態では、選択されたテンプレートに必要なデータの特定のタイプおよびフォーマットのために、対話型生成システムは、オペレータを促すユーザインターフェースを与え得る。ステップ2056において、対話型生成システムは、テンプレートIDおよびメタデータとともに、対話型イベント情報を対話型サーバに転送する。ステップ2058において、対話型サーバは、テンプレートIDおよび指定されたデータ要素を適切なフォーマットで含めることにり、対話型イベントシグナリングメッセージをフォーマットし、結果、上記で説明したように、それらが受信デバイスによって受信され、解釈され得る。
上述のように、一実施形態は、イベントシグナリングメッセージ中で指定され得る様々なフィルタ処理基準に基づいて、対話型イベントが受信デバイスの特定のグループ、さらには個々の受信デバイスに向けられることを可能にする。図14A〜図16Cに示す例示的なメッセージの形式に示すように、特定の対話型イベントが受信デバイス用に指定されているかどうかを決定するために受信デバイスが使用することができるいくつかのデータフィールド中に、対象選定(ターゲッティング)またはフィルタ処理基準が含まれ得る。たとえば、図14A〜図16Cに示すメッセージの形式は、サービス、キャリア(BCS)、デバイスタイプ、対話型アプリケーションおよび地理的エリアに基づく対話型イベントの対象選定を可能にする。追加の対象選定基準は、人口統計学的情報(たとえば、所有者のジェンダー、年齢層など)、サービスレベルまたはサブスクリプション(加入状況)、グループ所属などに基づく個人へのイベントの対象選定を可能にするために、対話型メッセージ要素中に含まれ得る。対象とされる対話型イベントは、対話型イベントシグナリングメッセージがオーバーヘッドフローから取得されるとき、それらが対話型イベントマネージャによって処理されるとき、およびそれらがアプリケーションマネージャによって処理されるときを含む、いくつかの段階において、フィルタ処理され得る。このようにして、ユーザ対話型コンテンツは、そのようなコンテンツが特に関係するかまたは有効であるユーザに狭く対象づけされ、それによって、コンテンツプロバイダにとってのそのようなサービスの経済的値を増加させ得る。
図21Aおよび図21Bに示すさらなる実施形態では、放送チャネルを介した動的対話型情報更新をサポートするために様々な対話型イベントシグナリング機構が使用され得る。そのような実施形態では、対話型イベントは、投票結果が放送ネットワークを介してリアルタイムで更新され得るように、リアルタイムで結果を集計し、放送ネットワークに投票集計を与えることができるサーバに、ユニキャストネットワークを介して送信されるユーザ入力を用いて、ユーザが、番組選択、好きな政治家、好きな芸能人、アドホック(特別目的の)視聴者調査など、様々なことについて投票することを可能にしする。さらなる実施形態では、動的対話型情報は、1つまたは複数のデータストリームを介して放送され得る。さらなる実施形態では、対話型イベントシグナリングメッセージは、そのイベントに関係する動的に更新された対話型データが放送されるデータストリームの識別子を含み得る。これは、受信デバイスが、それらのユーザが現在参加している対話型イベントに関連するデータストリームから、対話型データを受信することを選択することを可能にする。たとえば、投票のための対話型イベントシグナリングメッセージは、その投票イベントのための結果を搬送するデータストリームのための識別子を含み得る。一実施形態では、受信デバイスは、結果のデータストリームから、対話型データを選択的に獲得し得る。たとえば、受信デバイスは、ユーザが関連する投票イベントに参加した場合のみ、対話型データを受信することを選択し得る。このようにして、対話型イベントは、動的に更新された対話型情報を搬送するデータストリームにリンクされ得る。同様に、興味をひくイベントを見つけないユーザは、ユーザの受信デバイス上に気を散らす対話型データが表示されることを免れ得る。
さらなる実施形態では、複数の対話型イベントが互いにリンク(連関)されて、1次および2次イベント関係を作成し得る。一実施形態では、このイベントリンキングは、イベントシグナリングメッセージ中に含まれるイベント識別子または他の状態情報を介して達成され得る。したがって、受信デバイスは、ユーザが関係する1次イベントに参加した場合のみ、ユーザに2次イベントを表示すると決定し得る。たとえば、クイズ番組中に、前のクイズの答えに基づく関連質問(follow-up question)があり得る。受信デバイスは、ユーザが、第1のクイズに参加しなかった場合、関連質問を獲得および表示しないように構成され得る。このようにして、イベントが、興味をもつユーザに向けられるように、対話型イベントは、他の対話型イベントにリンクされ得る。そのような興味をひく対話型イベントを見いだせないユーザは、そのユーザの受信デバイス上に気を散らす対話型イベント表示が現れることを免れ得る。
図21Aに、ユーザの参加に基づいて、対話型イベントにおいて指定されたデータストリームから、動的対話型データ(たとえば、投票集計)を受信するための、受信デバイスにおいて実装され得る例示的な方法2100を示す。方法2100のステップ2102において、受信デバイスは、特定のイベントのための対話型イベントシグナリングメッセージを獲得し、ステップ2104において、イベントの対応する表示をレンダリングする。そのような対話型イベントの獲得およびレンダリングは、本明細書で説明する他の実施形態の方法のいずれかを使用し得る。決定ステップ2106において、受信デバイスは、ユーザがレンダリングされた対話型イベントに参加したかどうかを決定する。この決定は、イベントに応答してユーザ選択が入力されたかどうかに基づき得る。代替的に、この決定は、イベントへの参加に対応する代替ユーザ入力のうちの特定の1つまたは複数をユーザが選択したかどうかに基づき得る。したがって、受信デバイスは、イベントに参加することを取り消すかまたは断るユーザ入力を、実際の参加に関連するユーザ入力と区別し得る。対話型イベントデータまたはテンプレートは、どのユーザ入力が参加に対応するかを指定し得る。受信デバイスが、ユーザが対話型イベントに参加しなかったと決定した場合(すなわち、決定ステップ2106=「いいえ」)、処理は、ステップ2108において通常動作に戻る。受信デバイスが、ユーザが対話型イベントに参加したと決定した場合(すなわち、決定ステップ2106=「はい」)、受信デバイスは、決定ステップ2110において、それがデータストリーム識別子を指定しているかどうかを決定するために、対話型イベントデータを検査する。対話型イベントデータがデータストリーム識別子を指定していない場合(すなわち、決定ステップ2110=「いいえ」)、受信デバイスは、受信されるべき追加の動的対話型データがないので、通常動作に戻る(ステップ2112)。受信デバイスが、対話型イベントがデータストリームのための識別子を指定していると決定した場合(すなわち、決定ステップ2110=「はい」)、受信デバイスは、ステップ2114において、そのデータストリーム表示を使用して、放送信号からの指定されたデータストリームから、動的対話型データを獲得する。次いで、受信デバイスは、ステップ2116において、必要とされる動的対話型データを表示する。このようにして、対話型イベントに参加したユーザは、投票または調査結果など、イベントに関係する情報を受信し得、一方、参加しなかったユーザは、そのような追加のデータ提供で煩わされない。
図21Bは、ユーザの参加に基づいて2次動的対話型イベント(たとえば、関連質問)を受信するために、受信デバイスにおいて実装され得る例示的な方法2150を示す。方法2150のステップ2102において、受信デバイスは、特定のイベントのための対話型イベントシグナリングメッセージを獲得し、ステップ2104において、イベントの対応する表示をレンダリングする。そのような対話型イベントの獲得およびレンダリングは、本明細書で説明する他の実施形態の方法のいずれかを使用し得る。決定ステップ2106において、受信デバイスは、図21Aを参照しながら上記で説明したように、ユーザがレンダリングされた対話型イベントに参加したかどうかを決定する。受信デバイスが、ユーザが対話型イベントに参加しなかったと決定した場合(すなわち、決定ステップ2106=「いいえ」)、処理は、ステップ2108に示すように通常動作に戻る。受信デバイスが、ユーザが対話型イベントに参加したと決定した場合(すなわち、決定ステップ2106=「はい」)、受信デバイスは、決定ステップ2152において、それが他の対話型イベントを含むかまたは特定するかどうかを決定するために、対話型イベントデータを検査する。そのような追加の対話型イベントは、元の対話型イベント内の構成要素中に含まれ得る。代替的に、元の対話型イベントデータは、後で放送される対話型イベントシグナリングメッセージを選択的に受信し、実装するために受信デバイスが使用することができる、イベントIDまたは他の情報を指定し得る。対話型イベントデータが他の対話型イベントを含んでいないか、または特定しない場合、(すなわち、決定ステップ2152=「いいえ」)、受信デバイスは通常動作に戻る(ステップ2112)。受信デバイスが、対話型イベントが他の対話型イベントを含んでいるかまたは特定すると決定した場合(すなわち、決定ステップ2152=「はい」)、受信デバイスは、ステップ2154において関係する2次対話型イベントを獲得するために、その情報を使用する。同じく、2次対話型イベントは、元の対話型イベント内に含まれているデータから取得されるか、あるいは対話型イベント識別子、またはイベントシグナリングメッセージフィルタ処理基準、または受信デバイスが関係するイベントシグナリングメッセージを選択的に受信することを可能にする他の情報、を使用して、放送ストリームから取得され得る。次いで、受信デバイスは、ステップ2156において、受信デバイス上に獲得された2次対話型イベントを表示する。このようにして、第1の対話型イベントに参加したユーザは、2次または関係するイベントに参加し続けるように勧誘され得、一方、はじめに、参加することを選択しなかったユーザは、興味のない対話型イベントのストリームで煩わされない。
上述のように、対話型リソースおよびテンプレートが対話型イベントのために利用可能であることが必要となる前に、受信デバイスがそれらを受信することを可能にするために、受信デバイスが視聴することができる電子サービスガイドまたは電子カタログ中で特定されるファイル転送フローまたはデータチャネル上での放送のため、そのようなリソースおよびテンプレートがスケジュールされ得る。様々な実施形態では、利用可能な対話型リソースおよびテンプレートのリストを広告することと、どの対話型リソースおよびテンプレートを獲得すべきか、ならびにそのようなファイルをどのように、いつ獲得すべきかを決定するために、受信デバイスが必要とする情報を与えることと、のために、対話型カタログシグナリングファイルが使用され得る。別の実施形態では、対話型ファイルのためのスケジュールは、ファイル配信オーバーヘッドフローを介して搬送され得る。様々な実施形態では、対話型サーバは、対話型カタログシグナリングファイルを生成し得る。様々な実施形態では、対話型カタログシグナリングファイルは、放送ファイルシステムを介して配信されることになるか、または配信されている対話型リソースをリストし得る。
様々な実施形態では、対話型カタログシグナリングファイルは、すべての現在および将来の対話型シーケンスのための対話型リソースを含むように生成され得る。様々な実施形態では、対話型カタログシグナリングファイルは、カタログのタイムウィンドウ(時間枠)内に入る対話型シーケンスのための対話型リソースを含むように生成され得る。たとえば、対話型カタログシグナリングファイルは、次の24時間中に発生するすべての対話型イベントシーケンスのために必要になる対話型リソースを含むように生成され得る。様々な実施形態では、対話型カタログシグナリングファイルは、カタログタイムウィンドウの境界で、都度、再生成され得、新しい対話型シーケンスが生成された場合、関連するリソースおよびテンプレートが、現在のカタログタイムウィンドウに追加され得る。様々な実施形態では、対話型カタログファイルは、放送ファイルシステム中の対話型リソースおよびテンプレートへの索引(たとえば、ファイル名またはテンプレートID)を含み得る。対話型カタログファイルは、リソースおよび/またはテンプレートがダウンロードされるべきかどうかを決定するために、受信デバイスが使用することができる対話型ファイルに関連するフィルタ処理またはターゲッティング(対象選定)の基準をも含み得る。そのようなフィルタ処理またはターゲッティングの基準は、たとえば、対象BCS、対象リアルタイムサービス、対象デバイスタイプ、対象エリアなどを含み得る。
受信デバイスは、放送ファイルシステム中のよく知られる位置(たとえば、/itv/cat.xml)から対話型カタログファイルを獲得し得る。様々な実施形態では、受信デバイスは、よく知られているディレクトリを視聴し、そのディレクトリの下のカタログファイルを受信し得る。対話型カタログファイルから、受信デバイスは、その受信デバイスのためのターゲッティング基準を満たす対話型リソースおよびテンプレートのリストを決定し、次いで、放送ファイル配信システムからすべてのそのような関連リソースおよびテンプレートを獲得し得る。様々な実施形態では、対話型カタログファイルは、受信デバイスによってもはや必要とされない対話型リソースおよびテンプレートを削除するように更新され得る。たとえば、対話型カタログファイルは、関連する対話型シーケンスが満了しており、リソースまたはテンプレートが、予見できる将来に再利用されることが予想されないので、対話型リソースを削除するように更新され得る。様々な実施形態では、受信デバイスは、対話型カタログファイルに記載されていないものなど、メモリから削除され得る、それらの対話型リソースおよびテンプレートを特定するために、対話型カタログファイルを使用し得る。
様々な実施形態では、対話型カタログファイルは、対話型シーケンスが満了した直後には更新されない。これは、対話型シーケンスが満了し、対話型リソースがもはや必要とされなくなるたびに、受信デバイスが対話型カタログファイルを再獲得する必要がないので、受信デバイスバッテリー電力を節約する。一実施形態では、満了した対話型シーケンスのための対話型リソースは、対話型カタログファイルが他のトリガが原因で生成されるときに削除され得る。たとえば、満了した対話型シーケンスのための対話型リソースは、対話型カタログファイルがカタログウィンドウの境界で生成されるとき、および、新しい/既存の対話型シーケンスのための新しい対話型リソースが追加されるとき、に削除され得る。
様々な実施形態では、対話型カタログファイルは、カタログファイル配信期間に基づいて生成され得る。様々な実施形態では、対話型カタログファイルは、現在および次のカタログファイル配信期間に入る、対話型シーケンスのための対話型リソースを含み得る。これらの実施形態では、これは、現在のカタログファイル配信期間と次のカタログファイル配信期間との境界で発生する対話型シーケンスを説明するために使用され得る。
様々な実施形態では、受信デバイスは、ファイルが対話型カタログファイル中にもはや含まれないときに、対話型リソースおよびテンプレートを削除するように構成され得る。様々な実施形態では、対話型カタログファイル中の各リソースまたはテンプレートはまた、指定された満了時刻(すなわち、リソースまたはテンプレートがメモリから削除され得る日付および時刻)を有し得る。一実施形態では、リソース/テンプレート満了時刻は、リソースまたはテンプレートの将来の使用が企図されない場合、関連する対話型シーケンスのための満了時刻に基づいて設定され得る。次いで、受信デバイスは、リソース満了がリソースまたはテンプレートメタデータの一部として指定されているか、または含まれる場合、リソース満了に基づいて、対話型リソースまたはテンプレートを削除し得る。
図22は、一実施形態により、対話型カタログファイルを生成し、放送するために、放送ヘッドエンド設備において使用され得る例示的な方法2200を示す。方法2200のステップ2202において、対話型コンテンツプロバイダは、対話型生成システムに、対話型コンテンツ(すなわち、イベントアプリケーションデータ、リソースおよびテンプレート)を供給する。ステップ2204において、対話型生成システムは、放送ネットワークを介して対話型アプリケーションデータとリソースとテンプレートとシグナリングデータとを送信するために、対話型シーケンスに関連する対話型イベントデータを、対話型サーバに送る。ステップ2206において、対話型サーバは、現在および将来の対話型イベントのための対話型シーケンスに係る対話型アプリケーションデータ、リソースおよびテンプレートへの索引を含み得る、対話型カタログファイルを生成する。そのステップの一部として、対話型サーバは、対話型リソースおよびテンプレートが再利用のために指定されていない場合、関連する対話型シーケンスの満了に基づいてそのようなリソースおよびテンプレートのための満了時刻を設定し得る。ステップ2208において、対話型サーバは、生成された対話型カタログファイルと、イベントアプリケーションデータリソースを含む他の対話型リソースおよびテンプレートとを、モバイル放送ネットワークを介したこれらのファイルの送信のために、ファイル配信システムに送る。一実施形態では、対話型カタログファイルは、放送帯域幅をより良く利用するために、イベント開始時刻よりわずか前に、対話型リソースおよびアプリケーションデータを放送することを可能にするため、頻繁に更新され得る。対話型サーバは、カタログファイル中に含まれる対話型リソースの配信前のある時刻のために、対話型カタログファイルの配信をスケジュールし得る。これは、受信デバイスが放送リソースまたはテンプレートを受信することを可能にするために、対話型カタログファイルが受信デバイスによって時間内に獲得され、処理され得ること、を保証する。
ステップ2210において、ファイル配信システムは、対話型サーバによって指定された配信サービス品質(QoS)に従って、モバイル放送ネットワークを介して放送するために、対話型サーバから受信された対話型カタログファイルと対話型リソースとテンプレートとを、放送事業者に配信する。ステップ2212において、受信デバイスは、放送ファイルシステム中のよく知られている位置(たとえば、/itv/cat.xml)から、対話型カタログファイルを獲得する。ステップ2214において、受信デバイスは、受信した対話型カタログファイルを使用して、適用可能なフィルタ処理基準に基づいてなど、受信デバイスに適用可能な対話型リソースおよびテンプレートのリストを決定する。ステップ2214の一部として、受信デバイスは、リストされたリソースおよびテンプレートが、デバイスメモリに現在格納されているリソースおよびテンプレートのより新しいバージョンであるかどうかを決定し得る。ステップ2216において、受信デバイスは、放送ネットワーク内のファイル配信システムから、すべての適用可能な対話型リソースとテンプレートとを獲得する。ステップ2216の一部として、受信デバイスは、すでに受信され、メモリに格納されたファイルをダウンロードする必要をなくすことによってバッテリー電力を節約するために、メモリにすでに格納されたリソースおよびテンプレートの更新されているバージョンのみを選択し得る。
図23Aおよび図23Bに、対話型リソースとテンプレートとを受信するために、対話型カタログファイルを受信し、処理するため、受信デバイスにおいて実装され得る例示的な方法2300を示す。方法2300のステップ2302において、対話型アプリケーションは、対話型イベントを受信するため、アプリケーションマネージャに登録する。上記で説明したように、様々な実施形態では、対話型アプリケーションは、1つまたは複数のタイプの対話型イベントを受信するため、アプリケーションマネージャに登録し得る。ステップ2304において、対話型イベントマネージャは、少なくとも1つの対話型アプリケーションが対話型イベントを受信するために登録されているかどうかを決定し、登録されている場合、対話型カタログファイルに係る獲得を開始する。ステップ2306において、対話型イベントマネージャは、リソースマネージャに、ファイル配信システムからの対話型カタログファイルの獲得を開始するように要求する。ステップ2308において、リソースマネージャは、ファイル配信システムに、放送ファイルシステム中のよく知られている位置(たとえば、/itv/cat.xml)から対話型カタログを獲得するよう要求する。ステップ2310において、ファイル配信システムは、対話型カタログファイルを受信し、新しいまたは更新された対話型カタログファイルを、リソースマネージャに送る。ステップ2312において、リソースマネージャは、対話型カタログファイルを使用して、カタログファイル中で指定されたフィルタ処理基準に基づいて、受信デバイスによる使用のために適用可能な対話型リソースおよびテンプレートのリストを決定する。ステップ2314において、リソースマネージャは、受信デバイスへの適用性および登録された対話型アプリケーションへの適用性など、フィルタ処理基準を満たす、関係する対話型リソースおよびテンプレートのリストを作成する。ステップ2316において、リソースマネージャは、ファイル配信システムに、適用可能なリソースおよびテンプレートのそれのリスト中に含まれる対話型リソースとテンプレートとを獲得するよう要求する。ステップ2318において、ファイル配信システムは、放送ネットワークからリストされた対話型リソースとテンプレートとを獲得する。
決定ステップ2320において、対話型イベントマネージャは、受信デバイスが特定のリアルタイムチャネルに現在同調しているかどうかを決定する。受信デバイスがリアルタイムチャネルに同調していない場合(すなわち、決定ステップ2320=「いいえ」)、受信デバイスは、ステップ2322において、非リアルタイム対話型イベントまたはアンバウンド対話型イベントを、それらのいずれかが実行のためにスケジュールされていれば、実装する。受信デバイスがリアルタイムチャネルに同調している場合(すなわち、決定ステップ2320=「はい」)、対話型イベントマネージャは、図13に示す方法に従って、ステップ2324において、オーバーヘッドデータ獲得モジュールから、現在同調されているリアルタイムチャネルに係る対話型イベントシグナリングメッセージを獲得する。ステップ2326において、対話型イベントマネージャは、受信した対話型イベントシグナリングメッセージ中のターゲット基準に基づいてイベントフィルタ処理を実行し、受信デバイスに適用可能でないシグナリングメッセージをドロップする。ステップ2328において、対話型イベントマネージャが、アプリケーションデータが対話型イベントシグナリングメッセージ中にインバンドで含まれないと決定した場合、マネージャは、対話型イベントシグナリングメッセージ中で受信されたアプリケーションデータファイルリファレンス(索引)情報に基づいて、ファイル配信システムからアプリケーションデータファイルをアウトオブバンドで獲得する(リソースマネージャを介して)か、または、メモリからアプリケーションデータファイルを獲得する(すでにダウンロードされた場合)。ステップ2330において、対話型イベントマネージャは、関連するアプリケーションデータ、ならびにリソースおよびテンプレートに係るファイル位置ロケーションとともに、フィルタ処理されたイベントをアプリケーションマネージャに渡す。ステップ2332において、1つまたは複数の対話型アプリケーションが対話型イベントを受信するために登録されている場合、アプリケーションマネージャは、対話型イベントを正しいアプリケーションにルーティングする機能を実行するユーザエージェントを以って、対話型イベントを適切なアプリケーションに送る。ステップ2334において、対話型アプリケーションは、対話型イベントが対話型リソース(たとえば、画像またはグラフィック)またはテンプレートを必要とする場合、ファイルシステムから、必要なリソースとテンプレートとにアクセスする。ステップ2336において、対話型アプリケーションは、受信されたアプリケーションデータと対話型リソースとテンプレートとに基づいて、対話型シーケンスを表示する。
対話型カタログファイルで使用するのに好適な例示的なメッセージの形式が図24A〜図24Dに示される。詳細には、図24A〜図24Dは、対話型カタログファイル中に含まれ得る例示的なデータフィールドを示し、様々なデータ要素の目的および性質の記述説明をリストする。図24Aを参照すると、対話型カタログ2402は、課金および顧客サービスプロバイダ(BCS)信号要素2404と共用信号要素2406とを含み得る。BCS信号要素2404は、BCSに係る対話型カタログシグナリング情報を定義し得る。共用信号要素2406は、サービスおよびBCSを通じて共用される対話型アプリケーションおよびリソースのためのカタログシグナリング情報を定義し得る。共用信号要素2406はまた、共用RSCタイプ2448であり得る、共用RSC2414フィールドを有する共用信号要素タイプ2424フィールドを持ち得る。BCS信号要素2404は、BCSのための識別子であるBCS特定要素2408と、BCS信号要素2404中に含まれる情報のバージョンを指定するバージョン2410要素とを有する、属性フィールド2422を持ち得る。BCS信号要素2404はまた、サービスに係る対話型アプリケーションとリソースとのためのBCS固有シグナリング情報を定義するSVC信号2412要素を持ち得る。SVC信号2412要素は、属性フィールド2428とSVC RSC2420フィールドとを有する、SVC信号タイプ2426要素を持ち得る。SVC信号タイプ2426要素の属性フィールド2428は、対話型シグナリング情報が指定されるMediaFLO(登録商標)サービスのための識別子であり得るSVC識別子2416要素と、サービス信号要素中に含まれる情報のバージョンを指定するバージョン2418要素と、を含み得る。様々な実施形態では、SVC RSC2420要素は、SVC RSCタイプ要素2430であり得る。
図24Bを参照すると、SVC RSCタイプ要素2430は、属性要素2432と、対話型リソースが使用され得るデバイスプロファイルのリストを指定するターゲットデバイスプロファイル要素2444と、対話型リソースが使用され得るエリア(領域)のリストを指定するターゲットエリア要素2446と、持ち得る。SVC RSCタイプ2430要素の属性要素2432は、リソース識別子を与える識別子2434と、共用要素2436と、ファイル名2438と、満了要素2440と、mime要素2442と、を持ち得る。共用要素2436は、リソースが対話型イベントを通じて共用されるかどうかを示す、ブール(Boolean)フラグであり得る。共用リソースでは、リソース情報は、対話型カタログサイズの大きさを最適化するために、共用RSC要素の一部として指定される。ファイル名要素2438は、リソースに係る絶対ファイル名であり得る。満了要素2440は、リソースに係る満了時刻であり得る。mime要素2442は、リソースに係るmimeタイプ(たとえば、jpeg、png)を示し得る。様々な実施形態では、ターゲットデバイスプロファイル要素2444は、図24Dを参照しながら以下で説明するように、1つまたは複数のターゲットデバイスプロファイルタイプ2464を示す。
上記で説明したように、共用信号タイプ2424は、共用RSC2414要素を有し得る。詳細には、図24Aは、共用RSC2414要素が、共用RSCタイプ2448のものであり得ることを示す。図24Cは、共用RSCタイプ2448が、属性要素2450と、対話型リソースが使用され得るようなデバイスプロファイルのリストを指定するターゲットデバイスプロファイル要素2460と、対話型リソースが使用され得るエリアのリストを指定するターゲット(対象)エリア要素2462とを有し得ることを示す。共用RSCタイプ2448の属性要素2450は、リソース識別子2452と、ファイル名2454と、満了要素2456と、mime要素2458とを含み得る。ファイル名要素2454は、リソースに係る絶対ファイル名であり得る。満了要素2456は、リソースに係る満了時刻であり得る。mime要素2458は、リソースに係るmimeタイプを示し得る。様々な実施形態では、ターゲットデバイスプロファイル要素2460は、図24Dを参照しながら以下で説明するように、1つまたは複数のターゲットデバイスプロファイルタイプ2464を示し得る。
上記で説明したように、SVC RSCタイプ要素2430および共用RSC2414要素はそれぞれ、対話型リソースが使用され得るデバイスプロファイルのリストを指定するターゲットデバイスプロファイル要素2444、2460を持ち得る。様々な実施形態では、ターゲットデバイスプロファイル要素2444、2460は、ターゲットデバイスプロファイルタイプ2464要素を含み得る。図24Dは、ターゲットデバイスプロファイルタイプ2464要素が、BCS識別子2468要素を有する属性要素2466を含み得ることを示す。ターゲットデバイスプロファイルタイプ2464要素はまた、包含されるデバイスプロファイルのすべてをリストする包含2470要素と、除外されるデバイスプロファイルのすべてを記載する除外2472要素とを含み得る。いくつかの実施形態では、ターゲットデバイスプロファイルタイプ2464は、包含2470要素または除外要素2472のいずれかを含み得る。他の実施形態では、ターゲット(対象)デバイスプロファイルタイプ2464は、包含2470要素と除外要素2472の両方を含み得る。
いくつかの実装形態では、複数のリアルタイムリニアチャネルのために作成され、同時に放送される多数の対話型シーケンスがあり得る。しかしながら、所与の時刻に、ユーザは、所与の対話型イベントが表示される時刻にユーザが同調しているチャネル上の対話型シーケンスしか視聴することができない。複数の対話型シーケンスが放送され、イベントがリニア広告スロットのトップで再生されるように設定されたイベント開始時刻を以って、いくつかの異なるリアルタイムチャネルのための対話型イベントはたいてい同時発生することになる。これは、広告のためのブレーク(中断)が、異なるチャネル上で同時にまたは互いに近接して発生する傾向があるからである。したがって、対話型イベントアプリケーションデータおよびリソースが、1つまたは複数のファイル配信システムフロー中などで、対話型イベントの開始よりわずか前に放送される場合、ユーザは、対話型イベントのうちの1つ、すなわち、視聴されているチャネル上のイベントのみを視聴することになるにもかかわらず、受信デバイスは、大量の対話型イベントデータを獲得するように要求され得る。これは、受信デバイスの処理能力に負担を課しながら、バッテリー電力を不要に消耗させることになり得る。
この事象および他の潜在的な他の事象に対処するために、一実施形態では、受信デバイスは、モバイルデバイスによって視聴されているリアルタイムチャネル上でユーザに表示されることになる対話型シーケンスに関係する対話型イベントアセットのみを獲得するように構成され得る。この実施形態は、デバイス処理およびデバイスバッテリー電力に対する需要を低減する。
上記で説明したように、様々な実施形態は、モバイルマルチメディア放送事業者が、モバイル放送ネットワークを介して対話型シグナリングおよび対話型リソース情報を搬送する放送ファイルデータ配信フローおよびシグナリングフローを通信することを可能にする、機構を与える。様々な実施形態では、対話型リソースは、放送ファイル配信システムを介してデータファイルとして配信され得、対話型リソースファイルは、1つまたは複数のファイルデータフロー上で放送され得る。様々な実施形態では、対話型通信情報は、1つまたは複数のシグナリングオーバーヘッドフローを介して配信され得る。様々な実施形態では、対話型イベントが可能にされる各リアルタイムサービスに係るサービスシステム情報オーバーヘッド情報(the service system information overhead information)は、リアルタイムサービスに関連する対話型リソースを搬送するファイルデータフローへのリンクを指定するため、およびリアルタイムサービスに関連する対話型シグナリングメッセージを搬送するシグナリングフローへのリンクを指定するために増補され(augmented)得る。
様々な実施形態では、すべてのリアルタイムチャネルに関連する対話型シーケンスのための対話型リソースは、1つのファイルデータフロー(すなわち、グローバルファイルデータフロー)を共用することができる。これらの実施形態は、すべてのリアルタイムチャネルにわたって同時起こるか、または時間的に重複する対話型シーケンスがごく僅かしかない状況において、特に適切である。そのような状況では、対話型リソースデータファイルは、繰り返し放送され、したがって、すべてのリソースが共用ファイルデータフロー上で送信される場合、それらは、順繰りに、繰り返し放送されてよい。これは、すべてのリアルタイムチャネルにわたって対話型リソースを送信するために必要とされる放送帯域幅を、最適化することになり得る。
様々な実施形態では、対話型リソースは、複数のファイルデータフロー上で配信され得る。様々な実施形態では、対話型リソースは、リアルタイムチャネルごとに別々のファイルデータフロー上で(すなわち、リアルタイムサービスファイルデータフローごとに)配信され得る。これは、リアルタイムチャネルにわたって同時に起こるるか、または時間的に重複する多くの対話型シーケンスがあり、したがって、多数の対話型リソースが放送される状況において、特に適切である。複数のファイルデータフロー上で対話型リソースを配信することは、所与のファイルデータフロー上で放送されるリソースデータファイルの数がより少なくなり得るので、特定のリアルタイムサービスのためのリソースを受信する前に受信デバイスが待つ必要のある時間量を低減する。専用ファイルデータフロー上で対話型リソースを放送することは、そのフローが、対応するリアルタイムサービスのためのリソースのみを搬送するので、特定のリソースを受信するために受信デバイスが待つ必要のある時間量はさらに低減することができる。様々な実施形態では、リアルタイムチャネルのサブ集合からの対話型リソースが組み合わされ、1つのファイルデータフロー上で放送され得る。
対話型リソースの放送と同様に、様々な実施形態では、すべてのリアルタイムチャネルのための対話型イベントシグナリングメッセージ(IESM)は、1つの補助シグナリングフロー(すなわち、グローバル補助フロー)上で放送され得る。これらの実施形態は、すべてのリアルタイムチャネルにわたって時間的に重複する対話型イベントシグナリングメッセージがあまり多くない状況において、特に有用である。また、リソース送信と同様に、対話型イベントシグナリングメッセージは、複数のシグナリングメッセージのシーケンスの繰り返しにおいてなどで、繰り返し放送され得る。対話型イベントシグナリングメッセージはまた、順繰りに放送される対話型イベントシグナリングメッセージの数を低減するために、複数の補助オーバーヘッドフロー上で配信され、それによって、受信デバイスが特定の対話型イベントシグナリングメッセージを受信するために待たなければならない時間量を低減する。したがって、一実施形態では、リアルタイムチャネルのサブ集合のための対話型イベントシグナリングメッセージは組み合わされ、1つまたは複数の補助オーバーヘッドフロー上で放送されてもよい。一実施形態では、対話型イベントシグナリングメッセージは、各リアルタイムチャネルに対応する別々の補助オーバーヘッドフロー上で(すなわち、リアルタイムサービス補助フローごとに)配信され得る。これは、リアルタイムチャネルにわたって時間的に重複する多くの対話型シーケンスがある状況において、特に有用である。
アンバウンド対話型シーケンス(すなわち、特定のリアルタイムサービスに連関されていない対話型イベント)では、ファイルデータフローおよびシグナリングフローは、ファイルデータフローおよび補助オーバーヘッドフローを通信するためのサービスSI(System Information: システム情報)内の予約済みサービスIDにおいて特定され得る。
サービスSIの中で対話型イベントリソースおよびシグナリングメッセージのためのファイルデータフローIDおよびシグナリングフローを放送することは、受信デバイスが、特定のサービスのそれぞれに係る対話型リソースおよび対話型シグナリングメッセージを搬送するファイルデータフローおよび補助オーバーヘッドフローを見つけることを可能にする。次いで、受信デバイスは、適用可能な対話型リソースと対話型シグナリングメッセージとを獲得するために、特定されたフローを使用することができる。サービスSIはまた、受信デバイスが対話型リソースおよび/またはシグナリング情報を獲得し得る、ユニキャストリンク(たとえば、URL)を指定することができる。
様々な実施形態では、すべてのリアルタイムチャネルに関連する対話型シーケンスのための対話型リソースを配信するために、単一のファイルデータフローが使用され、それによって、全体的な帯域幅利用を改善する。しかしながら、多くの、またはすべてのリアルタイムチャネルにわたって時間的に重複する多くの対話型シーケンスに係る対話型リソースがある場合、これらのリソースの獲得は、デバイス上でより長くかかり、デバイスのバッテリー寿命に影響を及ぼし得る。様々な実施形態では、対話型イベントプロバイダまたは放送事業者は、少数のリアルタイムサービスにわたってファイルデータフローを共用すること、または各リアルタイムサービスに係る対話型リソースを配信するために別々のファイルデータフローを使用すること、を決定し得る。様々な実施形態では、これらの決定は、重複する対話型シーケンスの数に基づき得る。様々な実施形態では、これらの決定は動的に行われ得る。一実施形態では、これらの決定は、所与の時刻にスケジュールされた対話型イベントの数に応じて、放送日全体にわたって、動的に行われてもよい。この実施形態では、サービスSIは、1つまたは複数のファイルデータフローにまたがる対話型リソースの供給における変化を反映するために、必要に応じて更新され得る。
様々な実施形態では、1つの補助オーバーヘッドフローは、すべてのリアルタイムチャネルのための対話型イベントシグナリングメッセージを配信するために使用され、これらのメッセージを配信するために必要な空中線帯域幅上の全体を最適化し得る。しかしながら、多くのリアルタイムチャネルにわたって時間的に重複する多くの対話型シーケンスに係る対話型イベントシグナリングメッセージがある場合、この手法は、任意の1つのシグナリングメッセージのための、受信デバイス獲得時間を増加させる。したがって、様々な実施形態では、対話型プロバイダまたは放送事業者は、重複する対話型シーケンスの数に基づいて、各リアルタイムサービスに係る対話型シグナリングメッセージを配信するために、別々の補助オーバーヘッドフローを共用または使用することを決定し得る。様々な実施形態では、これらの決定は、動的に行われ得る。一実施形態では、これらの決定は、1つまたは複数のファイルデータフローにまたがる対話型リソースの供給における変化を反映するために、必要に応じて更新されるサービスSIを用いて、所与の時刻にスケジュールされた対話型イベントの数に応じて、放送日全体にわたって動的に行われ得る。
図25Aおよび図25Bは、一実施形態による、オーバーヘッドデータフロー中で送信されるサービスSI情報を生成する際に使用されるリソースファイルデータフローとシグナリング/補助フローとを供給するのに好適な例示的な方法2500を示す。方法2500のステップ2502において、オペレータは、対話型リソースを配信するために、グローバルファイルデータフロー、共用ファイルデータフロー、またはリアルタイムサービスごとのファイルデータフローが使用されるべきかどうかを指定するために、供給システムを使用する。様々な実施形態では、オペレータは、ステップ2503において、対話型イベントシグナリングメッセージを配信するために、グローバル補助フロー、共用補助フロー、またはリアルタイムサービスごとの補助フローが使用されるべきかどうかを指定する。ステップ2504において、オペレータは、供給システムを使用して、供給システム上で放送リアルタイムサービスを供給し、特定のリアルタイムサービスに対して対話型を可能にする。ステップ2506において、供給システムは、そのリアルタイムサービスのための対話型リソースおよびシグナリングメッセージを搬送するために、ファイルデータフローおよび(適用可能な場合)補助フローを作成する。グローバルファイルデータフローおよびグローバル補助フローの選択肢が使用される場合、ファイルデータフローおよび補助フローは、第1のリアルタイムサービスに対して対話型が可能にされるときに作成され得る。ステップ2508において、供給システムは、サービスSIを生成する。サービスSIは、各対話型対応リアルタイムサービスのための対話型シーケンスに関する対話型情報を搬送するファイルデータフローおよび補助フローのためのフローIDへのリンクを含み得る。様々な実施形態では、サービスSIはまた、予約済みサービスIDを使用するアンバウンドフローへのリンクを搬送し得る。
ステップ2510において、供給システムは、放送ネットワークを介してサービスSIを配信するために、サービスSIを、オーバーヘッドデータ配信システムに送る。ステップ2512において、オーバーヘッドデータ配信システムは、放送ネットワーク上でサービスSIを配信する。ステップ2514において、受信デバイスは、放送ネットワークからサービスSIを獲得し、サービスSI中で指定された対話型リンクに基づいて、視聴されるチャネルについての対話型シグナリングメッセージを獲得するために、データフローが、対話型リソースと補助フローとを獲得することを決定する。
ステップ2516において、供給システムは、対話型対応リアルタイムサービスのための補助フロー情報を、オーバーヘッドデータ配信システムに送る。図25Bをに進んで、ステップ2518において、供給システムは、対話型対応リアルタイムサービスのためのファイルデータフロー情報を、ファイル配信システムに送る。ステップ2520において、対話型コンテンツプロバイダによって与えられた対話型コンテンツに基づいて、1つまたは複数の対話型シーケンスは、対話型生成システム上で供給される。様々な実施形態では、対話型シーケンス情報は、イベント開始時刻および有効期間(または停止時刻)、イベントターゲッティング(対象選定)基準、関連する対話型アセット(たとえば、画像/グラフィックス、URLなど)などの対話型イベントメタデータと、ユーザに表示される情報の集合、関連するアクションなどの対話型イベントアプリケーションデータとを含み得る。
ステップ2522において、対話型生成システムは、モバイル放送ネットワークを介した対話型リソースとシグナリングデータとの送信のために、対話型シーケンスに関連する対話型イベントデータを、対話型放送サーバに送る。ステップ2524において、対話型放送サーバは、モバイル放送ネットワークを介した対話型リソース(イベントアプリケーションデータリソースを含む)の送信のために、これらのリソースを、ファイル配信システムに送る。ステップ2526において、ファイル配信システムは、関連するリアルタイムサービスのための対応するファイルデータフローを介して、対話型放送サーバから受信された対話型リソースを配信する。この処理では、ファイル配信システムは、ステップ2518に関して上記で説明したように、供給システムからファイルデータフローを受信し得る。ステップ2528において、対話型放送サーバは、モバイル放送ネットワークを介した対話型イベントシグナリングメッセージの送信のために、対話型シグナリングメッセージを、オーバーヘッドデータ配信システムに送る。ステップ2530において、オーバーヘッドデータ配信システムは、関連するリアルタイムサービスのための補助フローを介して、対話型放送サーバから受信された対話型イベントシグナリングメッセージを、配信する。このステップ2530において、オーバーヘッドデータ配信システムは、ステップ2516に関して上記で説明したように、供給システムから補助フローを受信し得る。ステップ2532において、受信デバイスは、リアルタイムサービスのためのファイルデータフローから、そのリアルタイムサービスのための対話型シーケンスに関連する対話型リソースを獲得する。様々な実施形態では、受信デバイスはまた、リアルタイムサービスのための補助フローから、そのリアルタイムサービスに関連する対話型イベントシグナリングメッセージを獲得し得る。
上記で説明したように、受信デバイスは、リアルタイムサービスのサービスSIから、ファイルデータフローと補助フローとを見つけ得る。図26Aおよび図26Bは、一実施形態による、オーバーヘッドデータフローの中で受信されたサービスSI情報から、特定のリアルタイムサービスに係る対話型イベントリソースおよびシグナリングメッセージを受信するためのファイルデータフローおよびオーバーヘッドデータフローを決定するため、受信デバイス上に実装され得る例示的な方法2600を示す。方法2600のステップ2602において、受信デバイス内のSI獲得モジュールは、モバイル放送ネットワークからサービスSIデータを獲得する。ステップ2604において、ファイル配信システムモジュールは、対話型対応リアルタイムサービスに係り、サービスSI中で受信されたファイルデータフロー(カタログファイルを搬送するファイルデータフローを含む)情報を獲得するために、SI獲得モジュールとインターフェースする。ステップ2606において、オーバーヘッドデータ獲得モジュールは、対話型対応リアルタイムサービスに係り、サービスSI中で受信された補助フロー情報を獲得するために、SI獲得モジュールとインターフェースする。ステップ2608において、対話型イベントマネージャは、受信した対話型カタログファイルに基づいて、対話型リソースを獲得する必要があると決定する。ステップ2610において、対話型イベントマネージャは、ファイル配信システムから、対話型リソースとアセットと任意のアプリケーションデータファイルとを獲得するために、リソースマネージャとインターフェースする。ステップ2612において、ファイル配信システムは、デバイスが加入される先である対話型対応リアルタイムサービスに係り、サービスSI獲得モジュールから受信されたファイルデータフローから、対話型リソースを獲得する。ステップ2614において、対話型アプリケーション(ITVアプリ)は、対話型イベントを受信するために、アプリケーションマネージャに登録する。様々な実施形態では、対話型アプリケーションは、ステップ2614において、1つまたは複数のタイプの対話型イベントを受信するために登録し得る。
ステップ2616において、対話型イベントマネージャは、受信デバイスがリアルタイムチャネルに現在同調していると決定する。図26Bにうつって、ステップ2618において、対話型イベントマネージャは、対話型イベントシグナリングメッセージを獲得するために、オーバーヘッドデータ獲得モジュールとインターフェースする。ステップ2620において、オーバーヘッドデータ獲得モジュールは、現在同調されているリアルタイムサービス、ならびに予約済みサービスIDからのアンバウンドリアルタイムサービスについて、システムSIの獲得から受信された補助フローから、対話型シグナリングメッセージを獲得する。ステップ2622において、オーバーヘッドデータ獲得モジュールは、獲得された対話型イベントシグナリングメッセージを、対話型イベントマネージャに送る。ステップ2624において、対話型イベントマネージャは、イベントフィルタ処理を実行し、受信デバイスに現在適用可能でない対話型イベントシグナリングメッセージをドロップする。上記で説明したように、様々な実施形態では、このフィルタ処理は、対話型イベントシグナリングメッセージ中に含まれるターゲット基準に基づいて実行され得る。対話型イベントマネージャが、アプリケーションデータはイベントシグナリングメッセージ中にインバンドで含まれないと決定した場合、イベントシグナリングメッセージ中で受信されたアプリケーションデータファイル索引(reference)に基づいて、ファイル配信システムからまたはデバイスメモリから、(リソースマネージャを介して)、必要なアプリケーションデータファイルを獲得し得る。
ステップ2626において、対話型イベントマネージャは、関連するアプリケーションデータとともに、フィルタ処理されたイベントを、アプリケーションマネージャに渡す。アプリケーションマネージャは、対話型イベントを受信するためにすでに登録されたアプリケーションがあるかどうかを決定し得る。様々な実施形態では、この決定は、たとえば、アプリケーションID、イベントアプリケーションデータに係るmimeタイプ、イベント名、および/またはイベントタイプに基づき得る。ステップ2628において、1つまたは複数の対話型アプリケーションが、フィルタ処理された対話型イベントを受信するために登録されている場合、アプリケーションマネージャは、対話型イベントを、それらのアプリケーションに送る。ステップ2630において、ユーザエージェントは、対話型イベントを正しい対話型イベントアプリケーションにルーティングする機能を実行する。ステップ2632において、対話型リソース(たとえば、画像/グラフィックス)が示されることを、対話型イベントが必要とする場合、対話型イベントは、ファイル配信システムからそのリソースにアクセスする。ステップ2634において、対話型アプリケーションは、受信したアプリケーションデータと対話型アセットとに基づいて対話型シーケンスを表示する。
図27は、サービスSIオーバーヘッド情報のサービス定義メッセージのための例示的なデータの形式を示す。図27はまた、リアルタイムサービスのためのファイルデータフローと補助フローとを示すために、サービスSIがどのように使用され得るかを示す。たとえば、図27は、サービスSIが、サービス詳細を定義するサービス定義2702を含み得ることを示し、サービス定義2702は、属性2704要素とサービス記録2706要素とを含み得る。対話型リアルタイムサービスサービス記録2706は、フローID上の情報を与えるリソース要素2722、または、関連するファイルデータフローおよび補助フローのリソースURL2726を含み得る。様々な実施形態では、リアルタイムサービスサービス記録2706はまた、サービスタイプ2708、サービス言語固有データ2710、能力要件(capability requirements)2712、レーティング2714、フロー記録2716、利用可能エリア情報2718、およびマルチプレゼンテーション閲覧記録2720を含み得る。
様々な実施形態では、リソース要素2722はまた、記述子要素2724とリソースURL要素2726とを含み得る。記述子要素2724は、たとえば、リソースURLがファイルデータフローまたはオーバーヘッドシグナリングフローに係るフローIDを指定するのを指定するのかを示す、リソースURLのための記述を与える。これらのデータフィールドは、受信デバイスが、正しいファイルデータフロー、シグナリングオーバーヘッドフローおよび/または外部ソース(たとえば、URLでアクセスされるソース)から対話型イベントリソースとシグナリングメッセージとを獲得する必要があるという情報を、受信デバイスに与える。様々な実施形態では、記述子要素2724は、リソース要素がファイルデータフローまたは補助フローを記述していることを示し得る。様々な実施形態では、記述子要素2724は、サイズ最適化のために使用され得るコントロールド・ターム(controlled term)への索引(reference)であり得る。一実施形態では、コントロールド・タームは、特定のファイルデータフローのためのリソース記述子分類形式における「itv−file−service」という用語を指すことがある。一実施形態では、記述子2724のコントロールド・タームは、補助フローのためのリソース記述子分類形式における「itv−aux−flow」という用語を指してもよい。
様々な実施形態では、「itv−file−service」および「itv−aux−flow」というコントロールド・タームを強調するリソース記述子の分類形式の断片は、以下のようになり得る。
上記で説明したように、様々な実施形態では、対話型イベントリソースおよびシグナリングメッセージは、システムSI中に含まれるURLにアクセスすることによって、ユニキャストネットワークを介してなど、非放送ソースから取得され得る。様々な実施形態では、ファイルデータフローを特定するresource_url要素2726は、「itv:fileService−<serviceID>」のフォーマットであり得る。補助フローを特定するresource_url要素2726は、「itv:auxFlow−<flowID>」のフォーマットであり得る。ファイルデータフローおよび補助フローのためのリソース要素を強調する、サービス定義SIメッセージの中のリアルタイムサービスのための例示的なサービスレコードの断片が以下に与えられる。記述子要素に係る、この例の値「resource−url:2.1」は、エイリアスresource−us1をもつ分類形式におけるTermID 2.1を用いて、「Term」を参照することに留意されたい。
別の実施形態では、対話型イベントアプリケーションデータ、構成要素、メタデータおよびシーケンスロジックは、受信デバイスが、デバイス互換性のある対話型イベントアプリケーションを生成することを可能にするフォーマットで、受信デバイスによる受信のために、ファイルデータフローを介して放送され得る。この実施形態では、放送システム内の対話型アプリケーションジェネレータ31において対話型アプリケーションを生成するのではなく、そのようなアプリケーションの構成部分が、ファイル配信システムを介してファイルとして放送される。受信デバイスは、上記で説明したように、受信した対話型カタログファイル内で適切なファイルを特定することによってなど、ファイル配信システムを介して、アプリケーションアセットと、アプリケーションデータと、メタデータと、関連するファイルとを獲得する。そのような受信したデータおよびアプリケーション構成要素は、図2を参照しながら上記で説明したソフトウェアおよびアプリケーションモジュールにおいて、受信デバイス内で組み立てられ得る。受信デバイスが、それら自身の機能に基づいて生成され得る対話型イベントアプリケーションのタイプを決定するので、放送システムは、様々な受信デバイスタイプに適応するために数種の各イベントアプリケーションを放送する必要がないため、この実施形態は、対話型アプリケーションを送信するのに必要な帯域幅を低減し得る。
対話型イベントアプリケーションを生成するための、受信デバイス内に実装され得る例示的な方法2800を図28に示す。方法2800のステップ2802において、ユーザインターフェースアプリケーションは、オーバーヘッドデータ獲得モジュールおよびファイル配信システムを介して対話型イベントと関係情報とを受信するために、アプリケーションマネージャ(または対話型イベントマネージャ)に登録する。ステップ2804において、受信デバイスリソースマネージャは、ファイル配信システムから対話型カタログシグナリングファイルを獲得する。ステップ2806において、リソースマネージャは、カタログシグナリングファイルを使用して、どの対話型アプリケーションデータ、対話型アセットおよび他の対話型リソースがダウンロードされるべきかを決定する。一実施形態では、リソースマネージャによるこの決定は、受信デバイスに関係するとともに互換性のあるリソースおよび対話型アプリケーションデータのみが獲得されるように、常駐アプリケーションと受信デバイスタイプおよび機能とを考慮に入れる。様々な実施形態では、カタログシグナリングファイルは、図24A〜図24Dに示す例と同様のデータの形式を用いたメタデータを含み、受信デバイスが、対話型イベントを表示するために必要なアプリケーションアセットとアプリケーションデータとリソースとを特定することを可能にする。様々な実施形態において、カタログファイルでは、アプリケーションデータは、別のリソースファイルとして参照され得ることに留意されたい。
ステップ2808において、リソースマネージャは、スケジュール放送時刻に、ファイル配信システムから、適用可能な対話型アプリケーションアセットと、アプリケーションデータと、他の対話型リソースとを獲得する。ステップ2810において、対話型イベントマネージャは、受信デバイスがリアルタイムチャネルに現在同調しているかどうかを決定する。受信デバイスがリアルタイムチャネルに同調している場合、対話型イベントマネージャは、ステップ2812において、視聴されたリアルタイムチャネルに関連する対話型イベントシグナリングメッセージを獲得するために、オーバーヘッドデータ獲得モジュールとインターフェースする。ステップ2814において、オーバーヘッドデータ獲得モジュールは、獲得された対話型イベントシグナリングメッセージを、対話型イベントマネージャに送る。ステップ2815において、対話型イベントマネージャは、イベントフィルタ処理を実行し、受信デバイスまたはそのデバイス上に常駐するアプリケーションと互換性のない対話型イベントシグナリングメッセージをドロップする。ステップ2816において、対話型イベントマネージャは、対話型イベントについて(デバイスタイプに基づいて)要求される対話型アプリケーションアセットファイルまたはアプリケーションデータファイルが、(ファイル配信システムを介して)すでにダウンロードされ、デバイス上のメモリに格納されたかどうかを決定する。
必要な情報、リソースおよび/またはファイルが獲得されている場合、対話型イベントマネージャは、ステップ2818において、イベント情報と対話型アプリケーションデータとアセットとを、ユーザインターフェースアプリケーションに送る。ステップ2820において、アプリケーションデータが対話型イベントシグナリングメッセージの一部として受信された場合、ユーザエージェントは、受信したアプリケーションデータ情報に基づいて、受信デバイス上で対話型イベントアプリケーションを動的に生成する。このステップ2820において、ユーザエージェントは、放送ヘッドエンド内の対話型アプリケーションジェネレータに関して上記で説明したものと同様の機能を実行する。すなわち、ユーザエージェントは、対話型シーケンスと、表示コンテンツと、ユーザインターフェース機能と、シーケンシングロジックとを、実行可能アプリケーションの中に組み立てる。ステップ2822において、生成された対話型アプリケーションは、ユーザに対話型イベントを表示することと、ユーザ入力を受け付けることと、各ユーザ入力に対して定義された機能を実行することとを含めて、受信デバイス上で実行される。
受信デバイスが、対話型イベントアプリケーションアセットとアプリケーションデータとリソースとイベントメタデータとを受信し、実行可能アプリケーションの中に組み立てることを可能にするために、対話型アプリケーションデータ、リソースおよびメタデータは、図29〜図36に示すようなデータの形式を使用して、アプリケーションデータファイルの中で特定され得る。このデータの形式は、図25A〜図27を参照しながら上記で説明したものと同様の方法で実装され得る。このデータの形式は、受信デバイスが、表示画像、表示シーケンス、表示されるべきユーザプロンプト、ユーザ入力機能、表示状態タイムアウト値、およびシーケンスロジックに関して知らされることを保証する。
たとえば、ユーザ入力機能は、受信デバイスがクリックツーアクション・シーンシーケンスを指定するために使用し得る、図29に示す、クリックツーアクション・シーンシーケンスデータの形式において定義され得る。クリックツーアクション・シーケンス2902データは、プロンプトシーン2906要素と、アクションシーン2908要素と、アクション定義2910要素と、確認シーン2912要素とを含み得る。
プロンプトシーンに関連するタイムアウトを定義するためのプロンプト要素の例示的なデータ要素と、様々なユーザ入力に関連するラベルとを図30に示す。たとえば、クリックツーアクション・データ形式のプロンプトシーン要素2906は、タイムアウト要素3004と、肯定応答ボタンラベル要素3006と、否定応答ボタンラベル要素3008とを含む表示メッセージ定義3002要素を含み得る。タイムアウト3004要素は、視聴者がアクションをとっていない場合に、システムがスクリーン表示を維持すべきである持続時間を(たとえば、秒数で)指定し得る。肯定応答ボタンラベル要素3006は、肯定応答ボタンのためのラベル(たとえば、はい、送信、OK、Go、Call)を指定し得る。同様に、否定応答ボタンラベル要素3008は、否定応答ボタンのためのラベル(たとえば、いいえ、閉じる、終了、取り消す)を指定し得る。
図31に示すように、クリックツーアクション・データ形式の中のプロンプトシーン要素2906は、さらに、プロンプト中に含めるべきテキスト3104を定義し、グラフィックス要素3106を特定し、プロンプトシーン内に表示され得る選択可能なテキスト3108を含み得る。テキスト3104は、受信デバイスが非タッチ要素3112においてボタンを有する(すなわち、タッチスクリーンデバイスでない)場合と、受信デバイスがタッチ要素3114においてタッチスクリーンを有する場合とをカバーするために、異なるテキストを含み得る、主要テキストデータ要素3110を含み得る。グラフィックス要素3106は、グラフィックスが取得され得るリソースのリソースID3118を含む、グラフィックタイプ要素3116を有し得る。選択可能なテキスト要素3108は、テキストデータフィールド3122を含む、選択可能なテキストデータのフィールド3120を有し得る。
同様に、アクションシーン要素は、図32および図33に示す要素を含み得る。たとえば、アクション要素2908は、タイムアウト要素3204と、肯定応答ボタンラベル要素3206と、否定応答ボタンラベル要素3208とを含む、表示メッセージ定義要素を有し得る。タイムアウト要素3204は、視聴者がアクションをとっていない場合、システムがスクリーンを表示すべきである期間を(たとえば、秒数で)指定し得る。肯定応答ボタンラベル要素3206は、肯定応答ボタンのためのラベル(たとえば、はい、送信、OK、Go、Call)を指定し得、否定応答ボタンラベル要素3208は、否定ボタンのためのラベル(たとえば、いいえ、閉じる、終了、取り消す)を指定し得る。アクション要素2908は、さらに、アクションシーン中に含めるべきテキスト3304を有し、グラフィックス要素3306を特定し、アクションシーン内に表示され得る選択可能なテキスト3308を含み得る。テキスト3304は、主要テキストデータ要素3310を含み、非タッチスクリーンデバイスとタッチスクリーンデバイスのためのテキストとを、非タッチ要素3312およびタッチ要素3314に分離し得る。グラフィックス要素3306は、グラフィックスがどこで取得され得るかを特定するリソースID3318を含むグラフィックタイプ3316を有する。選択可能テキスト要素3308は、テキストデータフィールド3322を含む、選択可能なテキストデータのフィールド3320を含み得る。
対話型イベントアプリケーションに関連するアクション定義は、図34に示すデータ形式を使用するメッセージの中で通信され得る。図示のように、アクション定義要素2910は、アクション定義に関する情報3402を含むとともに、SMSメッセージ3404、(ユニキャストベースの)UDSI返答3406を送ること、呼3408を発すること、および/または(URLを介して)デバイス上のアプリケーション3410を起動すること、に必要とされる情報など、アクションを完了するために使用され得るコードまたは情報も含み得る。
確認シーンは、図35および図36に示すデータの形式を使用して送られるメッセージによって定義され得る。図35は、確認要素2912が、タイムアウト要素3504と、肯定応答ボタンラベル要素3506と、否定応答ボタンラベル要素3508とを含む表示メッセージ定義要素を含み得ることを示す。図36は、確認要素2912が、さらに、確認シーン中に含められるべきテキスト3604を含み、グラフィックス要素3606を特定し、確認シーン内に表示され得る選択可能なテキスト3608を含み得ることを示す。
図37に、対話型イベント信号メッセージ(IESM)を実装するための例示的なデータ方式を示す。詳細には、対話型イベント信号メッセージ3702は、属性フィールド3704、ならびに、サービスID要素3706、アプリケーションID要素3708、適用可能BCS要素3710、適用可能エリア要素3712、アプリケーションデータ情報要素3714、テンプレート情報要素3716、およびリソース情報要素3718などの様々な要素を含み得る。適用可能BCS要素3710は、BCS IDフィールド3722を含む属性フィールド3720とともに、アプリケーションリソースIDフィールド3738を含む属性フィールド3736を有する、内包(included)デバイスプロファイル要素3724とを含み得る。アプリケーションリソースIDフィールド3738は、異なるデバイスタイプのために異なるアプリケーションデータが生成される場合、デバイスプロファイルに基づいて、イベントのための適切なアプリケーションデータリソースをフェッチするために使用される。アプリケーションデータ情報要素3714は、アプリケーションデータフィールド3734と、アプリケーションデータインバンド要素3728、アプリケーションデータリソースID要素3730、およびmimeタイプ要素3732を含む属性フィールド3726とを有し得る。
図38に、現在視聴されているチャネルに関係するイベントのみが受信され、処理されるように、受信デバイスにおいて、対話型イベントシグナリングメッセージを受信し、処理するための例示的な方法3800を示す。方法3800のステップ1202において、モバイルデバイス上の起動されている対話型アプリケーションは、図12を参照しながら上記で説明したものと同様の方法で、対話型イベントを受信するために、アプリケーションマネージャに登録する。ステップ3802において、対話型イベントマネージャは、視聴されている特定のチャネルを特定することを含めて、受信デバイスがリアルタイムチャネルに現在同調しているかどうかを決定する。ステップ3804において、対話型イベントマネージャは、受信した対話型カタログファイルにアクセスして、現在視聴されているリアルタイムチャネルのためにスケジュールされた対話型イベントを実行するのに必要とされる対話型アセット(すなわち、アプリケーションデータおよびリソースファイル)のリストを決定する。対話型カタログファイルの受信については上記で説明した。
場合によっては、ステップ3804において、対話型イベントマネージャはまた、対話型カタログファイルを使用して、プログラムガイドリスト(すなわち、ユーザが視聴するためのチャネルを選択することを可能にする、オンスクリーン・チャネルガイド・ユーザインターフェース)中の現在視聴されているリアルタイムチャネルに近い1つまたは2つのリアルタイムチャネル上の対話型イベントを実行するために必要になるであろう、対話型アセットを決定する。この実施形態は、放送チャネルにわたってスクロールをするユーザが、遅延なしに連続チャネルにおいて対話型イベントを見ることになるように、受信デバイスが近くのチャネルにおける対話型イベントを表示する準備をすることを可能にする。この実施形態はまた、受信デバイスが型どおりにダウンロードしなければならない対話型イベントデータおよびリソースの量を低減する。
ステップ3806において、対話型イベントマネージャは、特定された対話型アセット(すなわち、アプリケーションデータおよびリソース)の獲得を要求するために、リソースマネージャとインターフェースする。リソースマネージャは、アセット獲得要求を使用して、ファイル配信システムからそれらのファイルを獲得し得る。この実施形態では、アウトオブバンドで(たとえば、対話型イベントリソースファイル配信ストリーム中で)送信される対話型イベントアプリケーションデータは、受信され、対話型イベントが開始するようにスケジュールされるまで、メモリに格納され得る。対話型イベントマネージャは、リソースIDまたはイベントIDおよびアプリケーションIDを、オーバーヘッドデータ獲得モジュールに渡すことによって、または、対話型イベントを選択的に処理するためにイベントIDおよび登録されたアプリケーションIDをフィルタ処理基準として使用することによって、これを達成し得るが、オーバーヘッドデータ獲得モジュールは、FLOネットワークから受信されたオーバーヘッドフローから、特定されたイベントに係り登録されたアプリケーションIDのための対話型イベントアセットを選択的に受信する。前記フィルタ処理は、同じくまたは代替的に、リソースIDと、チャネルIDと、番組情報と、視聴されたチャネル(および場合によっては近くのチャネル)に関係する対話型イベントアセットをデバイスが選択的に受信することを可能にする他の情報とに基づいて達成され得る。様々な実施形態および実装形態では、対話型アプリケーションは、特定の対話型イベントが、一意のイベント名、一意のイベントタイプ、ファイル配信システムデータストリームなどに基づいてなど、異なるファクタおよびフィルタに基づいて放送チャネルまたはファイル配信データフローから受信されることを要求し得る。
ステップ3808において、リソースマネージャモジュールは、図23を参照しながら上記で説明したロジックおよび方法に従って、ファイル配信システムから、要求された対話型イベントアプリケーションデータとリソースとを獲得する。したがって、様々な実施形態では、ステップ3808は、ステップ3806において対話型イベントマネージャから受信された、特定された対話型アセット(すなわち、アプリケーションデータおよびリソース)についての要求に応答して実行されるアクションを表し得る。
ステップ1204において、オーバーヘッドデータ獲得モジュールは、放送バーヘッドフローから対話型イベントシグナリングメッセージを獲得する。オーバーヘッドデータ獲得モジュールは、様々な基準に基づいて対話型イベントシグナリングメッセージをフィルタ処理し得る。様々な実施形態では、この基準は、受信デバイスが現在同調しているリアルタイムチャネルを含み得る。たとえば、様々な実施形態では、オーバーヘッドデータ獲得モジュールは、視聴されている現在のリアルタイムサービスにターゲットされた対話型イベントシグナリングメッセージのみを獲得し得る。様々な実施形態では、リアルタイムサービスに連関されていない対話型イベントシグナリングメッセージ(たとえば、アンバウンド対話型イベントシグナリングメッセージ)が、デバイスタイプ、対象先キャリア、ユーザ人口統計など、他のフィルタ処理基準を満たすことを条件に、その対話型イベントシグナリングメッセージは、どのリアルタイムサービスが視聴されているのかにかかわらず、任意の時刻に獲得され得る。
ステップ1206において、オーバーヘッドデータ獲得モジュールは、獲得された対話型イベントシグナリングメッセージを、対話型イベントマネージャに渡す。これは、図4に矢印4802によって示されている。ステップ1208において、対話型イベントマネージャは、イベントフィルタ処理を実行し、受信デバイスに、またはデバイスの現在の状態に適用可能でない対話型イベントシグナリングメッセージをドロップする。様々な実施形態では、このフィルタ処理は、イベントシグナリングメッセージ中に含まれる対象選定基準に基づいて実行され得る。一実施形態では、対話型イベントマネージャはまた、対話型イベントを再生するために必要な必須のリソースまたはテンプレートが、ステップ1203においてリソースマネージャからすでにダウンロードされているかを決定し得る。様々な実施形態では、対話型イベントは、必須のリソースまたはテンプレートが対話型イベントの時刻に利用可能でない場合、再生されないことになる。
ステップ1210において、対話型イベントマネージャは、フィルタ処理された対話型イベントをアプリケーションマネージャに渡す。アプリケーションマネージャは、ステップ1212において、受信した対話型イベントを受けるために、すでに登録された対話型アプリケーションがあるかどうかを決定する。この決定は、アプリケーションID、イベントアプリケーションデータのmimeタイプ、イベント名、イベントタイプ、または対話型イベントシグナリングメッセージ内に含まれる同様の情報に基づき得る。受信した対話型イベントが、どの登録された対話型アプリケーションにも一致しない場合(すなわち、決定ステップ1212=「いいえ」)、ステップ1214において、受信したイベントを無視する。
対話型イベントを受信するためにアプリケーションマネージャに登録された対話型アプリケーションのうちの1つまたは複数が、受信した対話型イベントシグナリングメッセージに一致する場合(すなわち、決定ステップ1212=「はい」)、アプリケーションマネージャは、ステップ1216において、ユーザインターフェース内のユーザエージェントを介して、対話型イベントを適切な対話型アプリケーションに送る。一実施形態では、ユーザエージェントは、対話型イベントを正しい対話型アプリケーションにルーティングする機能を実行し得る。ステップ1218において、対話型イベントを受信した対話型アプリケーションは、デバイスファイルシステムからの必要なリソースとテンプレートとにアクセスし、そのようなリソースおよび/またはテンプレートを使用して、必要な対話型表示および機能を組み立て、または生成する。ステップ1220において、対話型アプリケーションは、対話型イベントシグナリングメッセージの中で受信されたイベントアプリケーションデータに基づいて、対話型コンテンツを表示する。
様々な実施形態では、方法3800は、対話型イベントマネージャが、リソースマネージャに対して、対話型イベントアセットの獲得についての更新された要求を継続的に行っているように、連続ループで実行され得る。これらの実施形態では、リソースマネージャおよびオーバーヘッドデータ獲得モジュールは、対話型イベントが視聴されたリアルタイムチャネルにおいて実行されるために要求されるアセットを、継続的に獲得し得る。
図39は、ユーザが任意の時刻にチャネルを変更することに受信デバイスが適応することを可能にする処理方法3900を示す。方法3800の実行中の任意の時刻に、受信デバイスプロセッサは、ステップ3902において、視聴されるチャネルまたはコンテンツフローの変化を検出し得る。このステップは、ユーザが受信デバイスに対してチャネル選択またはスクロール入力を行ったことに応答して実行される機能の一部であり得る。ステップ3902の一部として、対話型イベントマネージャは、新たに視聴されるチャネルを決定し得る。
ステップ3904において、対話型イベントマネージャは、対話型イベントアセットのダウンロードについてのリソースマネージャへの(1つまたは複数の)現在の要求を取り消し得る。対話型アセットが、視聴されたチャネルと、プログラム(番組)ガイド内のそれの近くの各チャネル(すなわち、プログラム(番組)リスト中で上および下にあるチャネル)とのためにダウンロードされる実施形態では、対話型イベントマネージャは、プログラムガイドリスト中で1チャネルを超して離れているチャネルについてのリソースマネージャへの(1つまたは複数の)現在の要求を取り消し得る。この方法では、ユーザがチャネルを変更すると、受信デバイスが、必要にならないアセットを獲得するために電力および処理時間を伸長しないように、プログラムリスト中で現在1または2チャネルを超えて離れているリアルタイムチャネルに関係する、まだサポートされていない(すなわち、要求されたアセットがまだ受信されていない)対話型イベントアセットについての要求は取り消される。たとえば、視聴されるチャネルとプログラムガイド内でそれの近くにある各チャネル(すなわち、プログラムリスト中で上および下にあるチャネル)とのために、対話型アセットがダウンロードされる実施形態では、ユーザがプログラムガイドにわたってスクロールダウンしたとき、対話型イベントマネージャは、現在視聴されているチャネルから現在2リスト離れているチャネルに関連する対話型イベントアセットのダウンロード要求を取り消し得る。別の例として、ユーザが、前に視聴されたチャネルから2リストを超えて離れているプログラムガイドリスト中のチャネルにジャンプする場合、対話型イベントマネージャは、対話型イベントアセットダウンロードについてのすべての要求を取り消してもよい。
ステップ3904の後に、方法3900は、方法3800のステップ3804に進み、対話型カタログファイルを使用して、別のチャネル変化がステップ3902において検出されるまで、図38を参照しながら上記で説明したように進む処理を以って、新たに視聴されるチャネル、ならびに、いくつかの実施形態では近くのチャネルに関係する対話型アセットのリストを決定する。
図40は、実施形態のいずれかで使用するのに好適な受信デバイスのシステムブロック図である。典型的な受信デバイス4000は、内部メモリ4002とディスプレイ4003とスピーカー4054とに結合されたプロセッサ4001を含み得る。さらに、受信デバイス4000は、プロセッサ4001に結合されたワイヤレスデータリンクおよび/またはセルラ電話トランシーバ4005に接続され得る、電磁放射を送信および受信するためのアンテナ4004と、プロセッサ4001に結合されるモバイルマルチメディア放送レシーバ4024とを有し得る。受信デバイス4000は、一般に、ユーザ入力を受信するためのメニュー選択ボタンまたはロッカースイッチ(rocker switches)4008を含む。
対話型イベントシグナリングメッセージを受信し、処理するための様々な実施形態の方法は、マルチメディア放送レシーバ4024と、プロセッサ4001およびメモリ4002の部分とによって実行され得る。代替的に、マルチメディア放送レシーバ4024内のまたはそれに結合された専用モジュールが実施形態の方法を実行し得る。
上記で説明した放送ネットワーク側の様々な実施形態は、図41に示すサーバ4100など、様々な市販のサーバデバイスのいずれにも実装され得る。そのようなサーバ4100は、一般に、揮発性メモリ4102と、ディスクドライブ4103などの大容量不揮発性メモリとに結合されたプロセッサ4101を含む。サーバ4100は、プロセッサ4101に結合されたフロッピー(登録商標)ディスクドライブ、コンパクトディスク(CD)またはDVDディスクドライブ4106をも含み得る。サーバ4100はまた、他の放送システムコンピュータとサーバとに結合されたローカルエリアネットワークなど、ネットワーク4105とのデータ接続を確立するために、プロセッサ4101に結合されたネットワークアクセスポート4104を含み得る。
プロセッサ4001、4101は、以下で説明する様々な実施形態の機能を含む、様々な機能を実行するようにソフトウェア命令(アプリケーション)によって構成され得る任意のプログラマブルマイクロプロセッサ、マイクロコンピュータあるいは1つまたは複数の多重プロセッサチップであり得る。モバイル受信デバイスによっては、1つのプロセッサをワイヤレス通信機能専用とし、1つのプロセッサを他のアプリケーションの実行専用とするなど、複数のプロセッサ4101を設け得る。一般に、ソフトウェアアプリケーションは、アクセスされ、プロセッサ4001、4101にロードされる前に内部メモリ4002、4102、4103に格納され得る。プロセッサ4001、4101は、アプリケーションソフトウェア命令を格納するのに十分な内部メモリを含み得る。
上記の方法の説明および処理フロー図は、単に説明のための例として提供したものであり、様々な実施形態のステップが提示された順序で実行されなければならないことを要求または暗示するものではない。当業者なら諒解するように、上記の実施形態におけるステップの順序は、どんな順序でも実行され得る。「その後」、「次いで」、「次に」などの単語は、ステップの順序を限定するものではなく、これらの単語は、単に、読者に方法の説明を案内するために使用される。さらに、たとえば、冠詞「a」、「an」または「the」を使用する単数形の請求項要素への言及は、その要素を単数形に限定するものと解釈すべきではない。
本明細書で開示した実施形態に関して説明した様々な例示的なロジックブロック、モジュール、回路、およびアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、または両方の組合せとして実装され得る。ハードウェアとソフトウェアのこの互換性を明確に示すために、様々な例示的な構成要素、ブロック、モジュール、回路、およびステップを、上記では概してそれらの機能に関して説明した。そのような機能をハードウェアとして実装するか、ソフトウェアとして実装するかは、特定の適用例および全体的なシステムに課せられた設計制約に依存する。当業者は、説明した機能を特定の適用例ごとに様々な方法で実装し得るが、そのような実装の決定は、本発明の範囲からの逸脱を生じるものと解釈すべきではない。
本明細書で開示した態様に関して説明した様々な例示的なロジック、ロジックブロック、モジュール、および回路を実装するために使用されるハードウェアは、汎用プロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)または他のプログラマブルロジックデバイス、個別ゲートまたはトランジスタロジック、個別ハードウェア構成要素、あるいは本明細書で説明した機能を実行するように設計されたそれらの任意の組合せを用いて実装または実行され得る。汎用プロセッサはマイクロプロセッサであり得るが、代替として、プロセッサは任意の従来のプロセッサ、コントローラ、マイクロコントローラ、または状態機械であり得る。プロセッサはまた、コンピューティングデバイスの組合せ、たとえば、DSPとマイクロプロセッサとの組合せ、複数のマイクロプロセッサ、DSPコアと連携する1つまたは複数のマイクロプロセッサ、あるいは任意の他のそのような構成として実装され得る。代替的に、いくつかのステップまたは方法は、所与の機能に固有の回路によって実行され得る。
1つまたは複数の例示的な態様では、説明する機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実装した場合、機能は、1つまたは複数の命令またはコードとしてコンピュータ可読媒体に格納されるか、あるいはコンピュータ可読媒体を介して送信され得る。本明細書で開示した方法またはアルゴリズムのステップは、有形の非一時的コンピュータ可読格納媒体上に常駐し得る、プロセッサ実行可能なソフトウェアモジュールで実施され得る。有形の非一時的コンピュータ可読格納媒体は、コンピュータによってアクセスされ得る任意の利用可能なメディアであり得る。限定ではなく、例として、そのような非一時的コンピュータ可読媒体は、RAM、ROM、EEPROM、CD−ROMまたは他の光ディスク格納装置、磁気ディスク格納デバイスまたは他の磁気格納デバイス、あるいは命令またはデータ構造の形態で所望のプログラムコードを格納するために使用され得、コンピュータによってアクセスされ得る、任意の他の媒体を備え得る。本明細書で使用するディスク(disk)およびディスク(disc)は、コンパクトディスク(disc)(CD)、レーザディスク(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フロッピーディスク(disk)、およびブルーレイ(登録商標)ディスク(disc)を含み、ディスク(disk)は、通常、データを磁気的に再生し、ディスク(disc)は、データをレーザで光学的に再生する。上記の組合せも非一時的コンピュータ可読媒体の範囲内に含めるべきである。さらに、方法またはアルゴリズムの動作は、コンピュータプログラム製品に組み込まれ得る、有形の非一時的機械可読媒体および/またはコンピュータ可読媒体上のコードおよび/または命令の1つまたは任意の組合せ、あるいはその集合として常駐し得る。
開示した実施形態の上記の説明は、当業者が本発明を製作または使用できるように提供したものである。これらの実施形態に対する様々な変更は当業者には容易に明らかであり、本明細書で定義した一般原理は、本発明の趣旨または範囲から逸脱することなく他の実施形態に適用され得る。したがって、本発明は、本明細書で示した実施形態に限定されるものではなく、以下の特許請求の範囲ならびに本明細書で開示した原理および新規の特徴に合致する最も広い範囲を与えられるべきである。