(57)【要約】ユーザに対話式テレビ放送を提供するためのテレビジョンシステム。このシステムは、１つまたは複数のデータパラメータを記憶する（１４３）ローカルメモリ（１４６、１５２）を備え、データソースからのデータの可用性を決定し、利用可能データの第１部分を捕捉し、ローカルメモリ（１４６，１５２）の第１区域（１５１）に記憶する。このシステムは、ローカルメモリに記憶したパラメータ（１４３）を使用して、第1データ部分が利用可能な第２部分に関連するかどうかを決定する。必要があればデータの第２部分を捕捉し、ローカルメモリの第１区域（１５１）に記憶する。データの第１および第２部分をそれぞれの識別性に合わせて処理する。処理したデータをローカルメモリ（１４６、１５２）の第２区域（１５０）へ書き込み、これを利用することでユーザに対話式テレビ放送を提供できる。
2006527556.tif 000002
【特許請求の範囲】
【請求項１】
ユーザに対話式テレビ放送を提供するテレビジョンプラットフォームシステムであって、
ローカルメモリと；
データソースからのデータの使用可能性を決定する手段と；
使用可能データを捕捉する手段と；
使用可能データの第１部分をローカルメモリの第1エリアに記憶する手段であって、該第1部分が特定の識別を備える記憶手段と；
ローカルメモリに記憶した１つまたは複数のパラメータ値に従って前記第１部分が使用可能データの第２データ部分と関連するかどうかを決定する手段であって、該第２部分も特定の識別を備える決定手段と；
第１部分と第２部分に関連性が認められる場合、第２部分をローカルメモリの第１エリアに記憶する手段であって、捕捉したデータがユーザに対話式サービスを提供するのに利用できる記憶手段と、
を備えるテレビジョンシステム。
【請求項２】
ローカルメモリが揮発性メモリと非揮発性メモリを含む請求項１に記載のテレビジョンシステム。
【請求項３】
第１および第２メモリエリアが揮発性メモリである請求項２に記載のシステム。
【請求項４】
揮発性メモリがDRAMである請求項１または２に記載のシステム。
【請求項５】
第１および／または第２メモリエリアをハードドライブで提供する請求項１に記載のシステム。
【請求項６】
ダウンロードしたデータオブジェクト内に含まれるコードに規定したステップに全面的または部分的に基づいて第１部分および第２データ部分を処理する手段であって、処理したデータをローカルメモリの第２エリアへ記憶し、前記対話式サービスを提供するのに利用する処理手段を更に含む前記請求項の何れかに記載のシステム。
【請求項７】
ユーザにサービスを提供していない間にデータの捕捉／ダウンロードを実行するようにした前記請求項の何れかに記載のシステム。
【請求項８】
データソースがテレビ放送ネットワーク及び／又はインターネットである前記請求項の何れかに記載のシステム。
【請求項９】
データソースから送信される予定のデータがローカルメモリにあるデータよりも新しく、最新のものであることを決定し、前記データソースからのデータがローカルメモリのものより古く、最新のものでないと判断した場合は予定されたダウンロードを阻止あるいは実行しないようにした前記請求項の何れかに記載のシステム。
【請求項１０】
データソースからデータを受け取る直前にシステムの１つまたは複数の部分をパワーアップし、データの受け取り直後にパワーダウンする前記請求項の何れかに記載のシステム。
【請求項１１】
データソースから捕捉するデータの一部が、プラットフォームに向けたサービスエンタイトルメントあるいはディスエンタイトルメントメッセージから成る前記請求項の何れかに記載のシステム。
【請求項１２】
提供する対話式サービスが電子プログラムガイドまたはスクリーン上のテレビマガジンから成る前記請求項の何れかに記載のシステム。
【請求項１３】
提供する対話式サービスが双方向対話式ゲームから成る前記請求項の何れかに記載のシステム。
【請求項１４】
提供する対話式サービスが記憶したビデオやオーディオクリップ、またはビデオやオーディオストリームの再生から成る前記請求項の何れかに記載のシステム。
【請求項１５】
セットトップボックス、テレビ、またはビデオレコーダ、コードレスまたは携帯式電話、メディアジュークボックス、個人用デジタルアシスタント、移動式電話、あるいは上記の組合せから成る前記請求項の何れかに記載のシステム。
【請求項１６】
前記請求項の何れかに記載のシステム。
【請求項１７】
テレビジョンシステムのユーザに対話式テレビ放送を提供するための方法であって、
データソースからのデータの使用可能性を決定し；
使用可能データの少なくともいくつかを捕捉し；
使用可能データの第１部分をローカルメモリの第１エリアに記憶し、該第１部分は特定の識別を備え；
ローカルメモリに記憶した１つまたは複数のパラメータ値に従って前記第１部分が使用可能データの第２データ部分と関連するかどうかを決定し、該第２部分も特定の識別を備え；
第１部分と第２部分に関連性が認められる場合、第２部分をローカルメモリの第１エリアに記憶し；
それぞれの識別に従ってデータの第１部分および第２部分を処理し；
処理したデータをローカルメモリの第２エリアへ書き込み；
対話式テレビ放送をユーザに提供するのに処理したデータを利用するステップから成る方法。
【請求項１８】
ローカルメモリが揮発性メモリと非揮発性メモリを含む請求項１７に記載の方法。
【請求項１９】
第１および第２メモリエリアが揮発性メモリである請求項１８に記載の方法。
【請求項２０】
揮発性メモリがDRAMである請求項１８または１９に記載の方法。
【請求項２１】
ダウンロードしたデータオブジェクト内に含まれるコードに規定したステップに全面的または部分的に基づいてデータ処理を行う請求項１７〜２０の何れかに記載の方法。
【請求項２２】
システムがユーザにサービスを提供していない間にデータの捕捉／ダウンロードを実行する請求項１７〜２１の何れかに記載の方法。
【請求項２３】
データソースがテレビ放送ネットワーク及び／又はインターネットである請求項１７〜２２の何れかに記載の方法。
【請求項２４】
テレビジョンプラットフォームがセットトップボックス、テレビ、またはビデオレコーダ、コードレスまたは携帯式電話、メディアジュークボックス、個人用デジタルアシスタント、移動式電話、あるいは上記の組合せから成る請求項１７〜２３の何れかに記載の方法。
【請求項２５】
テレビジョンシステムのユーザに対話式テレビ放送を提供するための好ましくは、データ媒体あるいはコンピュータ可読媒体上のコンピュータプログラムであって、
データソースのデータ使用可能性を決定するためのコードまたは命令を有し；
使用可能データを捕捉し；
使用可能データの第１部分をローカルメモリの第１エリアに記憶し、該第１部分は特定の識別を備え；
ローカルメモリに記憶した１つまたは複数のパラメータ値に従って前記第１部分が使用可能データの第２データ部分と関連するかどうかを決定し、該第２部分も特定の識別を備え；
第１部分と第２部分に関連性が認められる場合、第２部分をローカルメモリの第１エリアに記憶し；
それぞれの識別に従ってデータの第１部分および第２部分を処理し；
処理したデータをローカルメモリの第２エリアへ書き込み；
対話式テレビ放送をユーザに提供するのに処理したデータを利用するステップから成るコンピュータプログラム。
【請求項２６】
対話式テレビ放送コンテンツ及び／又はソフトウエアの更新を含むデータストリームを伝送する手段と；
データストリームを受信するための複数の異なるユーザプラットフォームとから成るテレビジョンシステムであって、
データストリームは、ストリームのどの部分がどのプラットフォームによって使用されるかを識別するための複数の異なるユーザプラットフォーム識別子を含み、データ及び／又はソフトウエアの少なくともいくつかは2個以上のプラットフォームによって共有可能で、各ユーザプラットフォームは自らが使用するデータストリームの部位を認識し、これらの部位を利用して対話式コンテンツや画像をテレビコンテンツと同時に、あるいは、テレビコンテンツの代わりにスクリーンに表示するようにしたテレビジョンシステム。
【請求項２７】
テレビジョンシステムのユーザに対話式コンテンツを配給するための方法であって、
双方向対話式サービスを実行するために複数の異なるユーザテレビプラットフォームにデータ及び／又はソフトウエアを含む放送データストリームを伝送し；
データストリームは、ストリームのどの部分がどのプラットフォームによって使用されるかを識別するための複数の異なるユーザプラットフォーム識別子を含み、データ及び／又はソフトウエアの少なくともいくつかは2個以上のプラットフォームによって共有可能で、各ユーザプラットフォームで自らが使用するデータストリームの部位を捕捉するステップから成り、
それにより、対話式コンテンツや画像をテレビコンテンツと同時に、あるいは、テレビコンテンツの代わりにスクリーンに表示するようにした方法。
【請求項２８】
テレビ放送を受信および表示するテレビ、セットトップボックス、またはその他の大衆消費電子製品などの双方向対話式テレビジョンシステムであって、
ローカルメモリを有し、データオブジェクトの条件付き階層の捕捉／ダウンロードが可能で；
ローカルメモリに記憶したパラメータを使用して記憶が必要な階層内のデータオブジェクトを識別し；
データオブジェクトを識別した場合、これらのオブジェクトをローカルメモリに記憶するようにした対話式テレビジョンシステム。
【請求項２９】
データオブジェクトの条件付き階層を複数の異なるユーザプラットフォームに伝送／放送する方法であって、ユーザプラットフォームが識別に使用可能なパラメータや識別子を含むデータオブジェクトを、後で利用するために記憶する方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、テレビ放送を受信・表示するテレビ、セットトップボックス、またはその他の大衆消費電子製品内部の電子メモリにデータオブジェクトの条件付き階層をダウンロードできるようにした双方向対話式テレビジョンシステムに関する。
【０００２】
デジタルテレビやセットトップボックスのプラットフォームへの対話式放送は長年にわたり実施されてきた。これは、通常、プラットフォーム内のダイナミックRAM（DRAM）である揮発性メモリ（すなわち、電力を供給しないとメモリコンテンツが失われる）を対話式ソフトウェアアプリケーションの一時記憶域に割付けする。ユーザがプラットフォームスクリーンに表示されたキューに応答することでアプリケーションを呼び出し、プラットフォームがデータの連続的放送"カルーセル"から記憶域へアプリケーションをダウンロードするようにしても構わない。ふつう、アプリケーションを多重オブジェクトに分け、あるものは実行可能プログラムから成り、また、あるものはグラフィック、ビデオ、テキスト、サウンドオブジェクトを含むデータオブジェクトから成る。各オブジェクトを他のオブジェクトとリンクさせることもできる。通常、アプリケーションはユーザが別のアプリケーションキューを選択するまで持続し、その上で、全体的または部分的に新しいアプリケーションで上書きし、ユーザが同じアプリケーションをもう一度選択した場合は、そのアプリケーションを再度ダウンロードしなければならない。アプリケーションオブジェクトはテレビ放送とともに放送されることが多いため、同一の多重チャンネルを共有する。この場合、アプリケーション特有のフォーマットまたはスタイルでキューをテレビビデオに表示することが多い。
【０００３】
この方式には多くの問題が付随する。第一に、アプリケーションオブジェクトをプラットフォームにダウンロードする間、キューを選択してからアプリケーションがスタートするまでユーザは望ましくない遅延に甘んじなければならない。第二に、放送業者は同一のアプリケーションを、ふつう一日に数百回から数千回、繰り返し放送しなければならない。これは帯域幅の浪費であり、有線や衛星放送と比較して利用可能な帯域幅が制限されることの多い地上波放送の業者にとっては特に不経済である。
【０００４】
代替的手法としては、製造段階で、アプリケーションを"ファームウエア"として不揮発性メモリ（しばしば"フラッシュメモリ"と称される）のプラットフォームに記憶させる。これは、アプリケーションがプラットフォーム内に初期設定されているため応答性に優れるという点で有利であるが、対話式アプリケーションの多くが即座にまたはプラットフォームの有効寿命の間に時代遅れになるという点で不都合がある。代替的手法としては、プラットフォームの有効寿命が切れるまでアプリケーションの新型バージョンあるいは異なるアプリケーションをプラットフォームのフラッシュメモリにダウンロードする。しかし、この手法にも欠点がある。第一に、不揮発性フラッシュメモリは同サイズの揮発性DRAMと比べた場合、高価格である。すなわち、DRAMベースのメモリと比較してフラッシュファームウエアのインプリメンテーションの作成は一般的にコストが嵩む。第二に、低価格の（"NAND"と称される）フラッシュメモリを使用して記憶装置に書き込んだり回復したりしたデータは破損や信頼性に欠ける心配があり、実行や処理を行う前に、誤り検出／修正のためにDRAMへ連続的に読み込む必要がある。従って、実行中のアプリケーションコードやデータをホストするために、いずれにしても大量のDRAMが必要になる。
【０００５】
対話式テレビ放送を提供する別の手法は、記憶容量、ブランドやモデル、または中央処理装置（CPU）の型やプラットフォームの位置などのその他のプラットフォームパラメータに関係なく、全タイプのプラットフォームにダウンロードした単一の対話式アプリケーションオブジェクトのみを放送する。プラットフォームのハードウエアやMHEG-5、Java（登録商標） TV、MHP（マルチメディア・ホーム・プラットフォーム）、メディアハイウェイ、オープンTVなどのCPUの型から独立し、局所的に実行される"ミドルウエア"と呼ばれるフォーマットでこうしたアプリケーションの大部分を実行する。一般に、これらのミドルウエア・フォーマット間の相互情報交換可能性には限界があり、そのため、例えば、オープンTVのアプリケーションを実行するように構成または"ポート"したプラットフォームで、例えば、同時にメディアハイウェイのアプリケーションを実行することはできない。互換性のないミドルウエア・フォーマットが市場でますます増加傾向にあることは、製造業者、有料テレビ配給者、および放送業者に危機感をもたらしている。特に、他の競合フォーマットによる有利な媒体への路線変更や時代遅れになる怖れのあるミドルウエア・フォーマットへの投資に危機感を抱いている。
【０００６】
対話式テレビ放送を提供する別の手法は、従来式のテレビ放送と同じ輸送経路の対話式アプリケーションを放送して、画質を高めるものである。例えば、レシピアプリケーションを料理番組中に放送して、番組の所定のポイントでユーザがアプリケーションと対話するようにキューを設定しても構わない。別の例によれば、スクリーンで同時に視認する従来式のテレビ広告に情報や背景を盛り込んだ対話式"情報コマーシャル"アプリケーションとすることもできる。こうした目下の手法には、後続のテレビ番組または広告の数秒前または放送中という実時間にアプリケーションをダウンロードするという基本的な限界がある。これにより、プラットフォームにダウンロードする間ソフトの使用に遅延を招く怖れがあり、番組中アプリケーションを繰り返し再放送することで帯域幅を浪費することにもなる。
【０００７】
対話式テレビ放送を提供する別の手法は、広帯域インターネッネットサービスの受信と両者を組み合わせたサービスをユーザに表示できるデジタル式テレビジョン受像プラットフォームの導入である。このような目下のプラットフォームの限界は、特に、付加的なドライバのファームウエアを必要とするローカルエリアネットワーク（LAN）のアダプタのような外付け装置に接続しているような場合、ファームウエアの更新をユーザが手動で要求しなければならないことである。
【０００８】
セットトップボックス市場とテレビジョン受信プラットフォームの分野では、一般に製造業者や小売業者の競争が激しくなる傾向にある。その結果、製造業者は競合業者と差がつくような広域帯サービスを自社製品の特徴に盛り込む工程を模索している。同様に、小売業者は顧客の関心を逸らさず、新製品購買を促すために他社との識別化を図れるような製品開発の工程を模索している。
【発明の開示】
【０００９】
本発明の実施態様を独立クレームに記載する。好ましい特徴を従属クレームに記載する。
【００１０】
本発明の一実施態様によれば、ユーザに双方向対話式テレビ放送を提供するテレビジョンプラットフォームであって、ローカルメモリと；リモートデータソースからのデータの使用可能性を決定する手段と；使用可能データの第1部分を捕捉し、これをローカルメモリの第1エリアに記憶する手段であって、該第1部分が特定の識別を備える記憶手段と；ローカルメモリに記憶した１つまたは複数のパラメータ値に従って第1部分が使用可能データの第２部分と関連するかどうかを決定する手段であって、該第2部分も特定の識別を備える決定手段と；第1部分と第2部分に関連性が認められる場合は第2部分を捕捉し、これをローカルメモリの第1エリアに記憶する手段と；第1部分および第2部分の識別に従って両者のデータを処理し、処理したデータをローカルメモリの第2エリアへ書き込む手段と；対話式テレビ放送をユーザに提供するためにこの処理データを使用する手段と、を備えるテレビジョンプラットフォームが提供される。
【００１１】
システムソフトなどのデータを同報通信から定期的にダウンロードし、または、インターネットを介してこれをアップロードし、これを処理して局所的に記憶することで、適応性の増強が可能となる。各プラットフォーム内に記憶したパラメータの数値によりミドルウエアとアプリケーションオブジェクトを条件付きでダウンロードできるため、さらなる便益を実現できる。これにより、ブランド、型式、あるいはプラットフォームの型によって各プラットフォームの外観と機能性をカスタマイズしたり、ユーザの好みや使用履歴に応じてパーソナライズしたりすることが可能となる。従って、製造業者や小売業者はプラットフォームで実行するサービスの在り様を競争業者のそれから差別化できる。さらに、販売後は、サービスオペレータは周辺機器（LANカードなど）用ドライバソフトを一定のSTBにダウンロードすることに的を絞ることができる。各々異なるプラットフォーム配列を標的にした放送サービスにおいて、多数のプラットフォームに共通のオブジェクトをセッション中に一度だけ放送するようにして単一のダウンロードセッション中に放送サービスを実行できるため、対話式テレビ放送を多重放送する場合、放送業者にとって節約となる。
【００１２】
一実施例において、第1および第2メモリエリアはDRAMなどの揮発性メモリである。対話式ソフトを記憶するための第2メモリエリアとして高価格のフラッシュメモリの代わりにDRAMを使用することでプラットフォームのメモリ全体に掛かるコストを削減できるため、プラットフォーム製造業者やユーザはコストを節約できる。さらに有利な点は、ミドルウエアの型の交換や修正がDRAMへの単一のダウンロード中に即座に実行できるため、テレビネットワーク演算子と放送業者にとって機能的適応性が実現できることにある。
【００１３】
本発明のシステムの更に別の特徴によれば、ドライバを検出し、自らの識別と接続する外付け装置の識別に従って自らを自動更新するようにできる。これにより、ユーザが新しいソフトを用いて手動でシステムの更新を実行したり構成したりする面倒を排除することができる。これは、後でインターネット接続が必要になるのに購買時には通信用アダプタが含まれていないデジタル放送テレビジョン受信プラットフォームの場合、特に有効である。本発明によれば、ユーザは後から通信用インターフェースをプラットフォームに追加することが可能で、その存在は任意の適当な手段を用いてプラットフォームにより認識される。ひとたびインターフェースを追加すると、プラットフォームが適正に機能するのに必要なソフト用ドライバとアプリケーションを放送でダウンロードする。
【００１４】
対話式エンハンスメントをテレビ番組や広告と同時に出現させ、放送業者にとっては帯域幅の節約、ユーザ、テレビ番組製作者、広告主には反応の向上を目指して、テレビ番組や広告の数日から数時間前に対話式アプリケーションをDRAMにダウンロードするようにしても構わない。
【００１５】
小売業者によるプラットフォームユーザへのプリペイド式サービスの販売は、小売業者の売上げを増やすという見地から有益である。番号付きクーポンの小売り販売により前払い決済を実現できる。ユーザはクーポンの表面を擦って、サービスオペレータに示す番号を知り、これを受けて演算子が同時通信エンタイトルメントメッセージをユーザのプラットフォームへ送る。この手法は、電話やその他の電子手段でクレジットカードによるサービス費用の決済を強制しないという点でユーザにも有益であると認められる。さらに、小売業者が販売したプラットフォームに販促リーチを維持する工程はユーザの関心を維持し、新製品情報を伝えるのに有効である。
【００１６】
人気のアプリケーションとミドルウエア構成要素を1日に1回または少時間放送することで放送業者の帯域幅が節約できる。これらを放送するたびごとに、好ましくは、ローカルメモリに保存されているデータが利用可能データと異なっているかどうかプラットフォームが識別を実行する。好ましくは、ユーザがプラットフォームをスタンバイモードに設定している間にこれを実行する。データが異なる場合は、プラットフォームがパワーアップを行い、これを捕捉する。データに相違がない場合は、プラットフォームはスタンバイモードを維持する。これにより、エネルギーが節約でき、結果として、ユーザと環境に経済的恩恵をもたらす。
【００１７】
本発明の別の実施態様によれば、テレビコンテンツに加えて、データ及び／又はソフトウエアの更新を含むデータストリームを放送する手段と；テレビコンテンツとデータストリームを受信するための複数の異なるユーザプラットフォームとを備えるテレビジョンシステムが提供され、データストリームは、ストリームのどの部分がどのプラットフォームによって使用されるかを識別するための複数の異なるユーザプラットフォーム識別子を含み、データ及び／又はソフトウエアの少なくともいくつかは2個以上のプラットフォームによって共有可能で、各ユーザプラットフォームは自らが使用するデータストリームの部位を認識し、これらの部位を利用してコンテンツや画像をテレビコンテンツと同時に、あるいは、テレビコンテンツの代わりにスクリーンに表示するようにしたテレビジョンシステム。
【００１８】
上記のように構成したデータストリームにより、異なるタイプのプラットフォームが少なくともいくつかのデータ及び／又はアプリケーションを共有することが可能で、相対的に低い帯域幅で多数の異なるユーザプラットフォームに最新のアップデートを送ることができる。
【実施例】
【００１９】
図１は、多数の対話式サービスとコンテンツプロバイダのデータベース１０１、１０２、１０３、１０４、１９０からの対話式サービスアプリケーションとデータを受信、総合し、前記データをデータストリームの集積として多数のテレビジョン受信プラットフォーム１０９に放送するデータセンタ１００を示したものである。データベースは、番組タイトル、開始・終了時間、説明文、ハイパーテキストやメタデータを含む図式説明やAV図解などのテレビ・ラジオ番組のリスティング情報を含むテレビジョンリスティングデータベース１０１を備えることができる。ユーザがテレビスクリーン上でブラウザしたり、前記リスティングコンテンツを照会したりするプラットフォーム１０９で実行・表示するための電子プログラムガイド（EPG）アプリケーションを含む対話式アプリケーションデータベース１０２がデータベース１０１をさらに補足するようにしても構わない。付加的にあるいは代替的に、図1のシステムに、プラットフォーム１０９で実行・表示するための対話式で、教育的、情報付与的、または娯楽的コンテンツ（テレビマガジン、ニュース、スポーツ、天気など）、ゲーム、クイズ、投票、競技、およびその他の双方向的ソフトを備えるデータベース１０４を含んでも構わない。付加的にあるいは代替的に、このデータベースに広告１９０を含む１つまたは複数の発行者データベースを含んでも構わず、この場合、発行者は広告の単一プロモータ（小売店または小売チェーン店）かプロモータのクラブを表す。付加的にあるいは代替的に、プラットフォーム１０９からのSMS（ショートメッセージサービス）テキスト、マルチメディア、そのほかの電子メッセージの集積にコンテンツ集計仲介１０３を備えても構わない。これらにチャットサービスからのメッセージを含んでも構わず、この場合、ユーザ１１８はプラットフォーム１０９や携帯電話などのその他の共同使用プラットフォームを通じてメッセージを作成し、データセンタ１００へ直接送信したり、メッセージ集計仲介１０３を介して送信したりできる。付加的にあるいは代替的に、例えば、論説、ニュース、天気やスポーツの結果などを伝える情報・娯楽サービスを備えるデータベース１０５を含んでも構わない。
【００２０】
図２は図1のデータセンタ１００を更に詳細に示したものである。これは、一つのサイトでの共同使用、または多数のサイトに地理的に分散され、ネットワークされたサブシステムを含む。これは、サービス集計センタ１３０、トランスアクションプロセッサ１３１、データベース監理システム１３２、対話式音声応答システム１３４及び／又はコールセンタ１３５を含む。サービス集計センタ１３０が外部から着信したサービスコンテンツとアプリケーションを受け取り、これらのコンテンツとアプリケーションをまとめて処理・編集し、データストリームを形成し、このデータストリームをデータカルーセル１３６に送る。コールセンタ１３５と対話式音声応答システム１３４を備えることで電話によるユーザ権利リクエストの受け取りと読み取りができる。データベース監理システム１３２を設けることで、データべース１３３上でのユーザ情報とプラットフォーム情報の監理および記憶と、財務基盤１３８を介してのクレジットカードやその他の支払い機関との決済通信が可能となる。トランスアクションプロセッサ１３１は、データベースマネージメントシステム１３２を介してユーザ１１８からの権利リクエストを受け取り、個々のユーザのプラットフォーム１０９向けに権利監理パケットを作成し、ストリームを単一のデータチャンネルにまとめるプレマルチミキサ１３７を介して所定の時間表とデータ転送速度に従ってデータストリームを実行するカルーセル１３６によりこれらをプラットフォーム１０９に放送するように構成してある。データストリームをプレマルチミキサ１３７から放送マルチミキサ演算子１０６に送り、公共衛星（DVB-S）のDVB（デジタルビデオ放送）ファミリ及び／又はケーブル（DVB-C）及び／又は陸上（DVB-T）放送フォーマットを使ってこれを適当な放送インフラストラクチャからユーザの家庭に送信する。
【００２１】
図３は典型的なユーザプラットフォーム１０９を示す。これは、データセンタ１００からのデータストリームを含む架空ディッシュ、衛星ディッシュまたはケーブルソケット１１６からのテレビ放送を受信し、テレビ１１２に接続して、一人または複数のユーザ１１８にスクリーン１１３を介して表示するセットトップボックス（STB）または個人用ビデオレコーダ（PVR）１１４から成る。データ及び／又は電話ネットワーク１０８を介してデータセンタ１００と通信するコードレス、有線、または携帯式電話１１１により口頭またはキー配列を押すことでユーザ１１８はデータセンタ１００と情報交換できる。テレビプラットフォーム１０９を操作するための手持ち型コントローラ１１７を設ける。このコントローラ１１７を図4に示す。手持ち型コントローラ１１７は好ましくは無線手段でコマンドをプラットフォーム１０９に送る。好ましい実施例では、手持ち型コントローラ１１７はキーに相当する赤外線送信機１２９を使用してプラットフォーム１０９にコマンドを送り、これはユーザが押すキーと対応し、プラットフォーム電源オン・オフトグル１２７、音量調節１２５、チャンネル選択１２６、赤／緑／黄／青ファーステクストキー１２４、上下左右カーソルキー１２０、OK／選択キー１２１、０から９の番号キー１２３、及び本発明に記載したプラットフォームの相互方向対話式サービスのいくつかを呼び出す"サービス"キー１２８を含むこれらのキーを押すことでユーザはコマンドを伝える。別の手持ち型コントローラ１１７の実施例では、テレビコントロールプラットフォームのそれと対応するようにキーを適宜ラベル付けした任意のプラットフォームを含むことが可能で、ディスプレイにテレビコントロールコマンドに対応するようにラベル付けした部位を含む携帯式またはコードレス電話、標準型"QWERTY"キーパッド、個人用デジタルアシスタント（PDA）、または指触感応手持ち型ディスプレイを使用して実現できる。
【００２２】
プラットフォーム１０９に関し、他の実施例も可能である。たとえば、STBまたはPVR１１４の機能範囲をテレビ１１２及び／又はディスプレイ１１３と部分的または全体的に統合しても構わない。別の実施例では、STBまたはPVR１１４の機能をパーソナルコンピュータ（PC）で実行し、テレビのディスプレイスクリーン１１３の機能をディスプレイモニタで実行する。更に別の実施例では、空中線１１６、STB１１４、テレビ１１２、キーコントローラ１１７、及びスクリーン１１３の機能をコードレスまたは携帯式電話、ノート型パソコン、メディアプレイヤまたはジュークボックス、パームトップコンピュータ、または個人用デジタルアシスタント（PDA）などの単一の手持ち型プラットフォームに統合する。更に別の実施例では、図５に示すようにプラットフォーム１０９にローカルエリアネットワーク（LAN）トランシーバ１１９を備え、データセンタ１００とデータ交換をDVB放送インフラストラクチャの代わりにインターネット１０８で行う。こうした実施例では、STBまたはPVR１１４は典型的にローカルの家屋内アクセスポイント１３９を介して無線（WiFiまたはワイヤレスIEEE８０２．１１a／ｂ／ｇ規格）またはエサーネットケーブルLANトランシーバ１１９によってインターネットと接続する。このような場合、プラットフォーム１０９は、インフラストラクチャ１１０や空中線１１６を介して放送手段によってテレビチャンネルやその他のサービスを受け取り続けるようにしても構わない。代替的または付加的に、プラットフォーム１０９は、インターネット１０８、アクセスポイント１３９、およびＬＡＮトランシーバ１１９を介してテレビチャンネルやその他のサービスを受け取るようにしても構わない。好ましくは、ＬＡＮトランシーバ１３９は着脱自在で、ＰＣＭＣＩＡ（Personal Computer Memory Card International Association）工業規格の"ＰＣカード"６８ピン１型、２型、３型インターフェース、あるいはＵＳＢ（Universal Serial Bus）インターフェースなどの接続インターフェース（図示省略）を介してＳＴＢ１１４と接続する。
【００２３】
プラットフォームメモリの割付け
図６はプラットフォーム内のメモリ割付けを示す。"キャニスタ"メモリエリア１４７と呼ばれるダイナミックＲＡＭ（ＤＲＡＭ）１４６の揮発部内のＳＴＢ１１４メモリエリアは、データセンタ１００からの対話式サービスを含むダウンロードしたオブジェクトイメージ１５０の記憶専用に使用される。目下のメモリコストに鑑みて、キャニスタメモリエリア１４７のサイズは典型的に１６または３２Ｍバイトである。将来的な実施例ではより大容量のメモリエリアをキャニスタ１４７に割付け可能で、プラットフォームの実施例には、例えば個人用ビデオレコーダ（ＰＶＲ）などが含まれ、ＤＲＡＭの代用またはＤＲＡＭに加えてハードディスクや磁気光学ディスク（記録可能ＣＤやＤＶＤプレーヤなどに広く採用されている）メモリがキャニスタ１４７の記憶に使用されよう。キャニスタの変形であるキャニスタサービス版とキャニスタシェル版１４９は、最後にダウンロードしたサービスバーストの全オブジェクトに固有のバージョン識別とロードシェルのバージョン識別にそれぞれ相当する。
【００２４】
"スクラッチパッド"エリア１４８と称される別のメモリエリアを、特別な事象中の中間結果を一時的に記憶するのに使用する。こうした事象は、例えば、プラットフォームがコンフィギュレーションストリームデータの検索、ダウンロード、処理を行うコンフィギュレーションストリーム１７０のダウンロードと；プラットフォームがスクラッチパッドエリア１４８内の緩衝領域１５１に新しいオブジェクトをダウンロードし、これらのオブジェクトを処理し、キャニスタエリア１４７に書き込みするバーストダウンロード事象１７１と；キャニスタアプリケーション２９３が前景でコンフィギュレーション１７０、デルタ１７２、またはトリガ１７３ストリームの背景ダウンロードを実行するトリガ事象や実時間ユーザセッションと、を含むことができる。これらの事象外では、例えば、標準型ＭＨＥＧ−５（マルチメディア・ハイパーメディア・エキスパート・グループ）エンジンなどのその他の非キャニスタ型常駐アプリケーションでスクラッチパッド１４８を自由に使用できる。好ましい実施例では、スクラッチパッドエリアをＤＲＡＭで構成しているが、ハードディスクベースの個人用ビデオレコーダ（ＰＶＲ）内など、その他のプラットフォーム実施例では、スクラッチパッドをハードディスク記憶装置に割付けしたり、ハードディスクとＤＲＡＭを組み合わせたりしても構わない。例えば、プラットフォームがＬＡＮトランシーバ１５４又はモデム１１５装置に接続しているか、又は接続している装置の詳細など、プラットフォームの外部機器との接続状態を示す一時的プラットフォームパラメータ１５４の記憶へＤＲＡＭの小さいエリアを付加的に割付けする。キャニスタローダプログラム１４０がプラットフォームのパワーアップを受けて定期的に、その後は、ＵＳＢやＰＣカードポートなどの外部接続インターフェースのポーリングが、一時的プラットフォーム１５４を更新する。
【００２５】
非揮発性部のフラッシュメモリ１５２も内部に記憶したアプリケーション２９３やキャニスタ１４７のメンテナンスに関連するファームウエアとデータの記憶に割付けされる。ファームウエアは、バーストストリーム１７１からのオブジェクトのダウンロード制御を実行可能なコードで、キャニスタ１４７内にデータ画像１５０を生成するキャニスタローダ１４０を含む。好ましくは、キャニスタローダの最小"ブートストラップ"構成要素１４０だけがファームウエアとしてフラッシュメモリ１５２に存在し、バースト事象１７１からのダウンロード開始時に残りの"一時的"部分１５３が揮発性メモリ１４６にロードされ、その後、部分的または全体的に消去される。この他、デコーダとトランスレータ１４１をフラッシュ１５２内に記憶させる。これらは、ダウンロードしたオブジェクトを処理するためにキャニスタブーストラップローダ１４０及び／又は一時的ローダ１５３によって呼び出し可能なソフトウエアモジュールである。例えば、テキストをクリアするためにオブジェクトに提供するデクリプション（decryption）デコーダを呼び出すにはキャニスタローダが最初に必要となろう。
【００２６】
クリアテキストオブジェクトを減圧するのに別のデコーダを引き続き呼び出すこともできる。好ましくは、プラットフォーム独自のフォームで全ての実行可能オブジェクトを伝送する。好ましくは、キャニスタローダがトランスレータを呼び出し、プラットフォーム独自の実行可能オブジェクトをプラットフォームの中央処理ユニット（ＣＰＵ）で直接実行可能なフォームに変換する。プラットフォーム調節層１４２もフラッシュ１５２に記憶させる。これはキャニスタアプリケーション２９３が直接独占的に呼び出し可能で、キャニスタ１４７にダウンロードするオペレーティングシステムまたはカーネル２８８やライブラリ２８９要素から成るオブジェクトを含む。プラットフォーム調節層１４２はキャニスタオペレーティングシステム画像２８８とライブラリ２８９をプラットフォーム固有ドライバ及びオペレーティングシステム２９０（好ましい実施例のＳＴＡＰＩとＯＳ２０）とハードウエア（実施例に記載のＳＴｉ５５１７）へ束縛するプラットフォーム特有のコードである。オペレーティングシステム層にＪＶＭ（ジャバ仮想コンピュータ）２９４を含んで、ジャババイトコードフォームでキャニスタにロードしたアプリケーション２９３の実行をサポートしても構わない。オペレーティングシステム２８８にＴＣＰ／ＩＰ（端末制御プロトコル／インターネットプロトコル）などの通信プロトコルソフトを含んで、アプリケーション２９３がインターネットを介してデータの送受信をするようにしても構わない。
【００２７】
フラッシュ１５２に記憶させるその他のファームウエアやデータはプラットフォームパラメータ１４３、プラットフォームクッキー１４４およびアプリケーションクッキー１４５を含む。プラットフォームパラメータ１４３は、ＣＰＵ速度、スクリーン解像度、キャニスタサイズ、スクラッチパッドメモリ割付け、あれば付属の接続インターフェース（例えば、ＰＣカード、ＵＳＢ、ＳＤカード）の型などのブランド、型式番号、及びハードウエア特性とすることができる。これらを製造段階で非揮発性メモリに焼付け、プラットフォーム有効寿命の間だけ読み込む。プラットフォームクッキー１４４はサービスＩＤまたはエンタイトルメント（後述）などのプラットフォームコンフィギュレーションから構成される小さなデータファイルで出力が低下しても残存できる。アプリケーションクッキー１４５は小さなデータファイルで、次に呼び出した時に復元すべきアプリケーション２９３の所定の状態を保持する。例えば、電子プログラムガイドアプリケーション２８４によって、前述のコンフィギュレーションをクッキー１４５として保存することによりユーザは選択設定した任意のチャンネルの消去または注文ができる。または、例えば、ゲームアプリケーション２８３においてユーザ名とハイスコアをクッキー１４５として記録することができる。あるいは、例えば、将来参照できるようにアプリケーション２９３でダウンロードした権利をクッキー１４５として保存し、その特徴またはコンテンツ２９２全体または所定の部分にアクセス権を付与するか否かを決定できる。
【００２８】
キャニスタ構造
図７はキャニスタ１４７に記憶したプログラムソフトウエア、データおよびサービスコンテンツの構造を示す。好ましくは、キャニスタにロードしたデータは、その他の型のプラットフォームハードウエアのキャニスタと機能的に同一の積層ソフトウエアスタックから構成され、特定のプラットフォームハードウエアコンフィギュレーションに対応するプラットフォーム調節ファームウエア１４２を介してプラットフォーム１０９のプログラム式ハードウエア（例えば表示制御装置、音響発生器、チューナ、デマルチプレクサなど）を制御するドライバソフトウエア２９０を含む。適当なハードウエアドライブをロードし、例えばプラットフォーム１１４がＬＡＮトランシーバ１１９またはモデム１１５に接続しているかどうかを示す一時的プラットフォームパラメータ１５４の値に基づく条件付きでドライバソフトウエア２９０にリンクさせても構わない。
【００２９】
好ましくは、各キャニスタにロードするデータは、単一のキャニスタアプリケーションプログラミングインターフェース（ＡＰＩ）２９１を通じてキャニスタ１４７内に常駐するアプリケーション２９３によって呼び出しできるオペレーティングシステム２８８と実行可能コード２８９のライブラリも含む。好ましくは、各アプリケーション２９３が処理を行うデータまたはコンテンツ２９２と協働するようにしても構わない。好ましくは、アプリケーション２９３は、１つまたは複数のゲームアプリケーション２８３と、電子プログラムガイド（ＥＰＧ）アプリケーション２８４と、チャットアプリケーション２８５と、図式およびハイパーテキストブラウザ２８７とを含む。オーディオビデオプレーヤなどのマルチプレーヤアプリケーションをロードし、例えばプラットフォーム１１４がＬＡＮトランシーバ１１９またはモデム１１５に接続しているかどうかを示す一時的プラットフォームパラメータ１５４の値に基づく条件付きでアプリケーションソフトウエア２９３にリンクさせても構わない。
【００３０】
バーストストリーム
キャニスタ１４７にバーストストリーム１７１の１つまたは複数のオブジェクトから構成したデータをロードする。低ビット速度の連続コンフィギュレーションストリーム１７０は時刻、持続時間、輸送ストリームロケーションなどのダウンロードパラメータを放送し、プラットフォームが本明細書に記載した処理に従ってバーストストリーム１７１からダウンロードできるようにしている。別のブロードキャストストリームであるデルタストリーム１７２により、プラットフォームは本明細書に記載した処理に従ってバーストストリーム１７１から最後にダウンロードしたものから、より最新のデータに自ら更新できる。さらに別のストリームとして、目下視聴中のテレビ番組と平行して同一の輸送ストリーム内を流れるトリガストリーム１７３は、本明細書に記載した工程に従ってプラットフォームがロードおよび実行する対話式アプリケーションを伝送する。さらに別のストリームとして、トランスアクションストリーム１７４は後述するように、提供するサービスの度合いと個々のプラットフォームが利用可能なアクセスを決定するアドレス権利保有情報を含む。
【００３１】
各バーストストリーム１７１は、典型的に１５分から１２０分の持続時間と通常６４〜２５６ｋｂｉｔ／ｓの高ビット速度を有し、その他のストリーム１７０，１７２、１７３、及び１７４と比較して、ダウンロード中のプラットフォームのパワーアップ時間を最小限とする。典型的に３つから４つのバースト１７１を毎日、ほぼ同間隔で放送する。図８は各バーストストリーム１７１が伝送するオブジェクトの全体的な順序を示す。最初に放送するオブジェクトは、識別２０１が常に空のルートオブジェクト１８０で、図９に示すように、その他のオブジェクト１８１，１８２，１８３が後に続き、関連するその他全てのオブジェクトが先に放送されるまで放送されないようになっている。最後にバーストストリーム１７１の終わりを限定するのに"オブジェクト終了"マーカー１８４を放送する。 
【００３２】
オブジェクトは、任意のフォーマットで実行可能なアプリケーション及び／又はオペレーティングシステム及び／又はドライバ（ジャババイトコードまたはスクリプト、パスカルｐコード、インテントＶＰコード、プラットフォームのＣＰＵに固有の機械コード、原始コードを含む）、圧縮フォーム及び／又は暗号フォームでの保存に関わらない任意の型のコンテンツ（テキスト、グラフィック、音声、オーディオ及び／又はビデオクリップ、映画、条件付きアクセス権を含む）を含む任意の二進データから構成して構わない。図９はバーストストリーム１７１が伝送するオブジェクトのリンク構造を示すものである。キャニスタローダ１４０は、１つまたは複数の"シェル"オブジェクト１８１が参照するオブジェクトペイロードの接続ネットワークに基づいてキャニスタ内にメモリ画像を構成する。一つのシェルオブジェクト１８１だけを任意のプラットフォームキャニスタにダウンロードするようにしても構わず、プラットフォームパラメータ１４３及び／又は一時的プラットフォームパラメータ１５４の係数であるルートオブジェクト１８０内の論理式を評価することにより任意のプラットフォームについてその識別を決定する。特有のシェルオブジェクト１８１のもとに直接または間接的に接続するオブジェクトのサブセットに対応するサービスを以下、"シェルサービス"と称する。
【００３３】
ユーザにとって同一のサービスのように見せるコンテンツオブジェクト１８３に間接的にリンクする一方で、異なるオペレーティングシステムを含むオブジェクトペイロードに直接または間接的にリンクできるという見地からシェルオブジェクト１８１は別のシェルオブジェクトと相違すると言える。一例として、１つのシェルがオブジェクトをマルチメディアホームプラットフォーム（ＭＨＰ）ミドルウエアから成るキャニスタ１４７にリンクさせる一方、２番目のシェルオブジェクトが、例えば、ＰＳＯＳやインテントなどの著作権の設定されたオペレーティングシステムにリンクし、３番目のシェルオブジェクトが著作権オペレーティングシステムの上にＭＨＰをレイヤーすることもできる。アプリケーションプログラムインターフェース（ＡＰＩｓ）が業界の支持を得るにつれ、製造業者と放送業者の両者が、業界のニーズの変化に適応できるようにミドルウエアを改変する動きを見せている。ミドルウエアまたはその他のファームウエアをフラッシュメモリに焼付けるという従来型の手法に比べて、定期的な放送を行い、ファームウエアの全キャニスタとメモリ内のアプリケーションを更新することでプラットフォーム１０９を素早く簡単に更新できるので、ユーザ、製造業者、及び放送業者に多大な利益がもたらされる。
【００３４】
さらに、異なるプラットフォームが実行する２つのシェルサービスには目に見える違いがあるが、それぞれのキャニスタのオブジェクトグループ間には構造的またはプログラミングの違いが皆無か、あっても限定的である。例えば、シェルサービスはその"スキン"（すなわち、スタイル、スクリーンの背景、またはユーザへのサービスの外観）という見地からのみ相違し、それが提示する機能範囲とコンテンツという見地からは同一であると言えよう。これは、他の製造業者の製品が提供する類似のサービスから少なくとも美観や外観という点から違いを見せなければならない製造業者にとって特に重要である。
【００３５】
単一のバースト１７１が多様で異なるタイプのプラットフォームをサポートするようにしても構わない。例えば、サービスオペレータは２つのシェルサービスをサポートする：１つはセットトップボックスプラットフォームで、もう１つは個人用ビデオレコーダとする。２つのサービスは本質的に同じコンテンツを伝送するものであるが、ある実行可能オブジェクトが一方のプラットフォームには必要で他方のプラットフォームには不要の場合、あるいはその逆もあり得る。同様に、あるコンテンツオブジェクトを一方のプラットフォームに保存するように指定しても、他方のプラットフォームでは例えばサイズのせいで使用できない場合もある。
【００３６】
プラットフォームコンフィギュレーション
図１０はデータセンタ１００がどのように１日中データストリームを放送し、キャニスタ１４７を最新に保ち、アプリケーションとその他のオブジェクトを装填しておくかを説明する。プラットフォーム１０９は、チューナとバーストストリーム１７１を開始するデータレシーバステージを定期的にパワーアップし、これらのキャニスタをリロードする。いつ、どの伝送ストリームで次のバースト事象が発生するかをプラットフォームが決定するのに必要なタイミングとロケーション情報はコンフィギュレーションストリーム１７０が伝える。コンフィギュレーションストリーム１７０は永続型で、典型的に２ｋｂｉｔ／ｓの低ビット速度の反復式（普通、数秒毎）ストリームで、全データセンタ１００のストリームの時間やロケーション、コンフィギュレーションテーブル１６２、伝送ストリーム内でやがて（典型的に２４時間以内）発生する全バースト事象１７１のスケジュールやロケーション、バースト事象テーブル１６３などのサービスコンフィギュレーションやシステムデータを伝える。図１１に示すようにバースト事象を異なるサービスのために放送して構わない。例えば、図１１に示すように、フランスとドイツの国境近くのＤＴＴネットワークのチャンネルを受信し、それぞれをサポートするために異なるサービス識別２０７を放送するようにできる。
【００３７】
図１２に示す永続ループにより、キャニスタローダ１４０が定期的にコンフィギュレーションストリームを読んで、いつ、どの伝送ストリームで次のバースト事象が発生するかを決定する。プラットフォームがスタンバイモード（１−１）の間、キャニスタローダは、２時間ごとに（１−９）クロック素子３０８によって駆動されるループに留まり、"電源オン"コマンドをプログラム可能チューナ３００とデマルチプレクサ３０１素子に送り（１−１０）、次に、ロードコンフィギュレーションプロセス（後述）に従ってコンフィギュレーションストリームからデータを獲得し（１−１１）、プログラム可能チューナとデマルチプレクサ素子のパワーダウンを実行する（１−１２）。プラットフォームが既にアクティブモード（１−１）の場合、プラットフォームは使用中の可能性がある。単一チューナのプラットフォームにおける視聴中断を防ぐためにキャニスタローダはコンフィギュレーションストリーム１７０へ向かう前にプラットフォームが使用中でないことを決定しなければならない。これは以下の手順で実行される。キャニスタローダは現在時刻がユーザに許可されたダウンロードウインド内であるかどうかを決定する（１−２）。設定メニューを介してユーザはこのウインドを変更可能で、典型的に、初期設定で早朝に設定してある。コンフィギュレーションを獲得するのにチャンネル変更が必要だと仮定した場合、キャニスタローダは、最小限のユーザ無活動状態が発生した後（１−３）と、最後のコンフィギュレーションロードから最小時間が経過した後（１−４）と、ユーザ承認を最後に要求した後（１−５）だけ獲得を試みることで視聴活動の中断を最小限のものとする。初期設定による無活動時間は４時間であるが、設定メニューからユーザが変更できる。ユーザが手持ち型コントローラのキーをたたいて承認しない場合は、キャニスタローダがスクリーンの警告部にコンフィギュレーション装荷が起こる旨のメッセージをオーバーレイする（１−６）。数秒以内にユーザ承認が得られない場合（１−７）、キャニスタローダは、目下同調しているプラットフォームのチャンネル設定をメモリに保存し（１−１５）、ロードコンフィギュレーションプロセスを開始し（１−１４）、ユーザが最後に視聴したチャンネルを回復する（１−１３）。ユーザ承認が得られた場合（１−７）、キャニスタローダはダウンロードの試みを強制終了し、無活動カウントダウンタイマーをリセットし（１−８）、ループに戻る。
【００３８】
図１３にロードコンフィギュレーションのフロー図を示す。キャニスタローダ１４０は次のバースト事象と協働するパラメータを決定する。キャニスタローダは有効コンフィギュレーションストリーム用の伝送ストリームをサーチする（２−２）。コンフィギュレーションストリームが見つからない場合（２−３）、キャニスタローダは診断メッセージをスクリーンに表示するか（２−９）、または、コンフィギュレーションストリームから現在時刻とデータをロードし、それに沿ってプラットフォーム実時間クロックを設定する（２−９）。次に、キャニスタローダ１４０は不揮発性メモリエリアのプラットフォームクッキー１４４、すなわち、受信してキャニスタ１４７へロードするようにユーザが過去に環境設定したプラットフォームのサービスを識別するサービスＩＤを調べる（２−５）。サービスＩＤクッキーが存在したら、キャニスタローダ１４０は次のバースト事象、すなわち、サービスＩＤに対応するバーストＩＤの識別を調べる（２−１０）。サービスＩＤクッキーが存在しない場合（プラットフォームが新品の場合）、またはその数値をバースト事象テーブルで見つけられない場合、ポップアップ式のオンスクリーンメニューでバースト事象テーブルからユーザにサービスを選択してもらう。
【００３９】
多数の連続バースト事象１７１が同一オブジェクトを運搬している（キャニスタに保存されているものと比べて新しいバージョンがまだ登録されていない）と仮定して、同じオブジェクトを複数回ダウンロードするためにプラットフォームがスタンバイ状態から起きて、パワーを浪費するのは好ましくない。キャニスタに既に存在するのと同じデータをキャニスタローダ１４０がダウンロードするのを回避する手段が必要で、これはバースト事象テーブルにサービス属性、すなわち、バースト事象内を伝送される任意のサービス識別２０７の各オブジェクト群に固有のサービスバージョンを付加することで達成できる。キャニスタローダ１４０がオブジェクトシェルをキャニスタにロードするたびに、ロードセルとサービスそれぞれの全オブジェクトに固有のバージョンに相当する２つの変数、すなわち、キャニスタサービスバージョン及びキャニスタシェルバージョンをキャニスタ１４９に書き込む（２−１４）。キャニスタローダは最初に、サービスバージョンとキャニスタサービスバージョンがマッチするかどうかを決定する（２−６、２−７）。両者がマッチしたら、バーストＩＤに対応するバースト事象１７１からのダウンロードを省略し、次のバースト事象を環境設定するプロセスを終了する（２−１５）。その次に、キャニスタローダは、シェルバージョンとキャニスタシェルバージョンがマッチするかどうかを決定する（２−８、２−１２）。最後に、サービスバージョンにもシェルバージョンにもマッチングが見つからない場合、キャニスタローダはバーストＩＤ，すなわち次のバースト時間と次のバースト伝送ＩＤをプラットフォームのクッキーエリア１４４に書き込む（２−１４）。その結果、プラットフォームには次のイベント時間とロケーションが適切に設定され、ロードコンフィギュレーションプロセスが終了する。（２−１５）。
【００４０】
デルタストリーム
バーストストリーム事象１７１は、１日のうち、定期的にのみ発生する。更新オブジェクトの反復放送であるカルーセルストリームは、バースト事象の間に放送され、デルタストリーム１７２と称される。図１４はデルタストリームの構造を示し、図９と１０で説明したバースト事象"Ｂ"１７１の開始後に所定のオブジェクト１８５の最新バージョンが放送可能になった事例を説明する。カルーセルマーカ１８６の開始がこれらの更新オブジェクト１８５放送の境界線となり、更新オブジェクト１８５がその後に続き、カルーセルマーカ１８７の終了で完了する。デルタストリーム１７２は、ふつう、少なくとも２４時間繰り返し放送されるか、または、オブジェクトの更新バージョン（図１０のイベント"Ｃ"）あるいは更に最新のバージョンを含むバースト事象１７１が終了するまで放送される。これは、例えば、新しい告示を反映させるために改修した新オブジェクトまたはスケジュール変更を反映させるための更新テレビリスティングオブジェクトなどである。バーストストリームと比較して、デルタストリーム１７２は、典型的に１３−３２ｋｂｉｔ／ｓの低ビット速度を有する。
【００４１】
第２チューナが使用可能なプラットフォームの場合、プラットフォームがデルタストリーム１７２を連続的に監視・処理し、ユーザセッションの間、キャニスタを常に最新の状態に保つようにすることもできる。単一チューナのプラットフォームでは、ユーザが手動でスクリーンメニューから更新を要求してキャニスタアプリケーション２９３を呼び出し、これにより、プラットフォーム１０９を同調し直して、実時間でデルタストリーム１７２を受信・処理するようにする。例えば、リスティングコンテンツオブジェクト２８１を更新するには、ユーザがＩＰＧアプリケーション２８４内の"リスティング更新"を選択して、キャニスタローダ１４０を呼び出すことができる。
【００４２】
キャニスタローダ１４０がデルタストリーム１７２に同調して分析し、そこで見つけた新しいオブジェクトと古いキャニスタオブジェクトとの置き換えを行うロードデルタの工程を図１５に示す。最初に、キャニスタローダはプログラム可能チューナの既存設定を保存し（３−２）、コンフィギュレーションテーブルを読み込んで、どの輸送ストリームとデータストリームＩＤ（パケットＩＤ）でデルタストリームを見つけられるかを決定し（３−３）、プログラム可能チューナとデマルチプレクサにコマンドを送って、デルタストリームをフィルタにかける（３−４）。次に、キャニスタはオブジェクトマーカ１８６の始まりを受け取るまで待ち、ロードデルタオブジェクトプロセスを呼び出し、各オブジェクトを処理する（３−６）。図１６に示すロードデルタオブジェクトは、好ましくは、"ダブルバッフア"法を利用して新しい画像を付加するにつれて古いオブジェクト画像をキャニスタから消去する（４−１５）以外、本質的にロードバーストオブジェクトを簡略化したものである。このダブルバッフア法においてはデータ損失を防ぐために、新しい画像をキャニスタに完全に書き込み、他のオブジェクトとリンクさせたときだけ古い画像バージョンをアンリンクさせ、消去する。
【００４３】
任意に、キャニスタ全体またはサブセットをデルタストリーム内で連続的に放送しても構わない。これは電源をオフにした状態でプラットフォームのパワーアップを行う、あるいは、新しいプラットフォームを初めて使う場合、次のバースト事象を待たずに即座にキャニスタのリロードを実行してプラットフォームを使用できるようするユーザにとって効果的である。このような場合、設定メニューを通じてユーザが手動で、バーストストリーム１７０の代わりにデルタストリーム１７２からロードデルタプロセスのダウンロードを開始し、キャニスタローダが実時間でオブジェクトの処理を実行する。
【００４４】
トリガストリーム
キャニスタ１４７は、従来型テレビチャンネル放送の視聴を補助または増強する双方向機能性を提供するようにできる。こうした放送では、テレビチャンネル事象と同じ輸送ストリームまたはマルチプレクサで小さいトリガデータオブジェクトを放送し、キャニスタ１４７に既に保存されているアプリケーションの特定の部分を起動させる。
【００４５】
図１７はスクリーン１１３に表示した従来型テレビ放送チャンネル２２０を示す。
図１８に示すように、キャニスタ常駐アプリケーション２９３は、テレビ放送と同じ輸送ストリーム内を伝わり、テレビチャンネルプレイアウト手段１０７で生成されるトリガ信号に応答してチャンネルディスプレイ２２０に第1オーバーレイ２７０を表示することができる。オーバーレイ２７０の外見と一緒にビデオ２２０をスクリーンに収まる程度の任意の大きさに小さくすることにより、ビデオ２２０とポップアップオーバーレイ２７０を互いに重複させずにスクリーン１１３に同時に表示することができる。オーバーレイ２７０を不透明にして、後ろのビデオ２２０部分を見えないようにすることもできる。あるいは、透明にして後ろのビデオ２２０がオーバーレイ２７０を通して部分的に見えるようにしても構わない。オーバーレイ２７０を任意の大きさ、または円形、長円形、長方形などの任意の形状にして、スクリーン１１３上の任意の場所に設置できる。オーバーレイに使用説明を含んで、図１９に示すような第２および後続オーバーレイ２７１を表示するには手持ち型コントローラ１１７のどのキーを押したらいいかユーザに告げるようにしても構わない。全てのオーバーレイはテキストラベル２７２、静止画または動画２７４、および表現効果２７３などの対話式表示素子を含み、オーバーレイ内で注目すべきエリアをユーザに示し、ユーザは手持ち型コントローラ１１７のキー（図示した実施例におけるオーバーレイ２７１では、"ＯＫ"キー１２１）を押して、表現効果２７３と関連している対話式アプリケーション２９３における実行プロセスを選択するようにできる。
【００４６】
従来型のテレビを視聴している間にアプリケーション２９３がスクリーンをオーバーレイするためのトリガストリームハンドラプロセスを図２０に示す。初めに、電源オフの状態またはスタンバイモードからプラットフォーム１０９をパワーアップさせ、プラットフォームがどのテレビチャンネルに同調しているかを連続的に背景モニタリングするとトリガストリームハンドラプロセスを開始する（５−１）。チャンネルが変更するたびに（５−２）、新しいチャンネル放送と輸送ＩＤを獲得し（５−３）、コンフィギュレーションテーブルを検索して（５−４）、トリガパケットストリームＰＩＤの識別子を見つけられるかどうかを決定する（５−５）。トリガＰＩＤが存在すると仮定して、トリガストリームハンドラが次のトリガオブジェクトをスクラッチパッド１４８に読み込み（５−７）、破損していないか、本物であるかを解読前にチェックする（５−８、５−９）。
【００４７】
トリガオブジェクトの構造を図２１に示す。トリガオブジェクトはバーストオブジェクトまたはデルタオブジェクト２００と同一の構造を有し、各々のオブジェクトが潜在的に多様なトリガペイロード２９９を運ぶ。ペイロードの形式２９５が現在視聴しているチャンネルとペイロードの添付物２９９が関連しているかどうかを決定する。関連している場合、ペイロードをダウンロードする（５−１１、５−１２）。不必要なペイロードは消去する。トリガペイロード２９９は一般に小さく、典型的に、単一のデコーダ／トランスレータ２８１を含むペイロードだけが"トリガハンドラ"として知られている。
トリガハンドラを実行するにあたり（５−１５）、特有の時間または特有のタイムスタンプ（チューンした輸送ストリーム内を伝わる）２９８発生時に"トークン"２９７メッセージを伝えるのに、特有のテレビ放送チャンネル２９５の識別を特有のキャニスタアプリケーション２９６とリンクさせる情報を含む２進画像２８２を伴うようにしても構わない。動作しない場合は、トリガハンドラ２８１が識別アプリケーション２９３を開始させ、トークン２９７を識別アプリケーション２９３と通信させ、このアプリケーションがオーバーレイ２７０と２７１をスクリーン１１３に出現させる。  
【００４８】
トランスアクションストリーム
個々のプラットフォームアドレス可能"トランスアクション"ストリーム１７４を１日中連続して放送する。トランスアクションストリームは個々のプラットフォームに向けた特徴的な権利保有情報を含み、そのプロセスを後述する。
【００４９】
オブジェクトとペイロード
シェルオブジェクト１８１は１つまたは複数のオペレーティングシステムオブジェクトと１つまたは複数のアプリケーションのオブジェクト１８２とリンクし、その各々が今度は別のオブジェクト１８３とリンクするようにできる。オブジェクトは多様なオブジェクトによってリンクするが、放送はバースト事象１７１の間に１度だけで帯域幅の節約になる。キャニスタローダはバーストストリームが伝送する全てのオブジェクトをスクラッチパッド内のバッフアエリア１５１に書き込む。ここで、以下に説明するように、それぞれに利用可能なオブジェクトのキャニスタ、リンクルート、ツリー、ブランチへ書き込む前にこれらを処理する。
【００５０】
各オブジェクトは、好ましくは、１つまたは複数のモジュールとしてＤＳＭ−ＣＣ（デジタルストレージメディアコマンドおよびコントロール）と呼ばれるカルーセル１３６を用いて伝送される。ＤＳＭ−ＣＣは、モジュールシーケンスを伝送するオーディオビデオデータと一緒に放送局が伝送するデータストリームであって、各モジュールは、ＳＴＢでダウンロード可能な１つまたは複数のデータセットの実行可能コード及び／又はデータ素子で構成される。全オブジェクトには所属サービスの識別であるサービスＩＤ２０７がタグ付けされる。例えば、２つのバースト事象１７１（例えば、フランス語の放送とドイツ語の放送）が同じストリームで共存しても構わない。全オブジェクトは図２２に示す構造から成る。各オブジェクトは他のオブジェクトによってリンクできるように識別２０１も備える。全オブジェクトは整数バージョン２０２を有する。前回の放送後に更新を行ったオブジェクト（例えば、テレビリスティングを含むオブジェクト派初期のバースト事象で放送されてから既に更新されている）は、それぞれの過去の数値と比較して増加した整数バージョンを運んでいる。オブジェクトはユーザ認証のために署名及び／又はチェックサム２０３を伝送しても構わない。オブジェクトは多様なペイロード２０５を運搬しても構わない。ペイロードをケースステートメントに組み込むことで、一般に、関連する論理式２０４が正しいかどうかによって、キャニスタローダは１つのペイロードのみを選択してキャニスタに装荷する。キャニスタローダはフライケース論理式を評価するインタプリタを備える。式は演算子と、プラットフォームパラメータ１４３と、一時的プラットフォームパラメータ１５４と、定数の論理関数である。演算子は算術演算子（足す、引く、掛ける、割る）、論理演算子（ＮＯＴ、ＡＮＤ、ＯＲ）、不等式（<＝、>＝、<、>、！＝、＝＝）、ストリング演算子（ＬＥＮ、ＦＩＮＤ）、ワイルドカード（＊、？）、メモリピーク、およびアレイポインタ演算子を含むことができる。プラットフォームパラメータと定数は文字タイプ、短長の整数、浮動小数点、ストリング、時刻／日付およびプール変数とすることができる。条件を満たさないプラットフォームパラメータ１４３または一時的プラットフォームパラメータ１５４の基準を含む式は誤りとして評価される。
【００５１】
バーストストリームからのオブジェクトのダウンロード
図２３は永続ループを示し、これによりキャニスタローダ１４０がバーストストリーム１７１を定期的に読んで、キャニスタ１４７を再生させる。プラットフォームのパワーがスタンバイモードの間（６−１）、ロードコンフィギュレーションプロセスが以前に決定したように、キャニスタローダはクロックを読んで時刻が次のバースト事象のガードタイム（１５秒）かどうかを決定する（６−８）。ガードタイムと決定した場合、キャニスタローダは、プログラム可能チューナとデマルチプレクサ素子にコマンドで電力を送り（６−９）、キャニスタへのロードバーストプロセスのダウンロードを開始し（６−１０）（後述）、次に、ロードコンフィギュレーションプロセスを実行して（６−１１）次のバースト事象の詳細を獲得し、プログラム可能チューナとデマルチプレクサ素子に"パワーダウン"コマンドを送って終了する（６−１２）。ループはこの工程を繰り返す。
【００５２】
プラットフォームがパワーアップすると（６−１）、キャニスタローダは現在時刻がユーザに許可されたダウンロードウインド内であるかどうかを決定する（６−２）。これは前述したコンフィギュレーションパラメータのローディング用ウインドと同じである。バースト事象オブジェクトを獲得するのにチャンネル変更が必要だと仮定した場合、キャニスタローダは、ユーザ無活動状態が持続した後だけ獲得を試みることで視聴活動の中断を最小限のものとする（６−３、６−４）。初期設定による無活動時間は４時間であるが、設定メニューからユーザが変更できる。ユーザが手持ち型コントローラの"ＯＫ"キーをたたいて承認しない場合は、キャニスタローダがスクリーンの警告部にコンフィギュレーションが発生する旨のメッセージをオーバーレイする（６−５）。ユーザ承認が得られない場合（６−６）、キャニスタローダは、目下同調しているプラットフォームのチャンネル設定をメモリに保存し（１−１５）、ロードバーストプロセス（６−１５）、引き続きロードコンフィギュレーションプロセスを実行し（６−１４）、ユーザが視聴していたチャンネルを回復する（６−１３）。ユーザ承認が得られた場合（６−６）、キャニスタローダはダウンロードの試みを強制終了し、無活動カウントダウンタイマーをリセットし（６−７）、ループに戻る。
【００５３】
サービスと残りのオブジェクトのローディング（該当がある場合）
図２４はバーストストリームで放送する全オブジェクトを構文解析するのにキャニスタローダが使用するロードバーストプロセスを示す。このプロセスは、ロード中に蓄積したアンサティスファイドリンクスと呼ばれるリンク参照をメモリの空テーブルに形成し（７−２）、次に、第１ルートオブジェクト１８０をスクラッチパッドエリア１４８に装荷することで始まる。好ましくは、キャニスタローダの機能範囲の大部分はダウンロードした"一時的"画像２１２内に含まれ、これはルートオブジェクト１８０のペイロード２０５内を伝送される。第１オブジェクトであるルートオブオブジェクト１８０は常に空（０）２０１を有し、キャニスタローダ１４０のブートストラップ部がこれをダウンロードする。ルートオブジェクトのペイロード式２０４を評価してどのペイロードを使用するか決定する。ルートペイロードは、好ましくは、プラットフォーム独自フォームのキャニスタローダの残りの"一時的"素子１５３を含む。ペイロード２進画像が圧縮またはプラットフォーム独自のフォームの場合、ペイロードは、順番に呼び出して、画像を実行可能フォームに変換するファームウエア１５２内の１つまたは複数のデコーダ及び／又はトランスレータ１４１への参照２１０を含む。ダウンロード後即座に実行可能画像を機械コードに翻訳する手法は、多くのミドルウエア環境で広く使用されている実時間コマンド解釈と比べてアプリケーションの実行速度という面から有益である。好ましい実施例において、仮想プロセッサオペレーティングシステム２８８、インテントをキャニスタに採用することで、仮想プロセッサ（ＶＰ）トランスレータ１４１を採用して一般の機械コード表示でダウンロードした実行可能オブジェクトをホストプラットフォームが採用した特有の機械固有コード指示セット及びハードウエア環境に変換できる。最後に、後述するように、画像を実行してキャニスタローダの全機能範囲を呼び出す。
【００５４】
キャニスタローダがルートオブジェクト１８０を含む各オブジェクトを解析するのに用いるロードバーストオブジェクトプロセス（７−４、８−１）を図２５に示し、これについてさらに説明する。次のオブジェクトの見出しを読み込み（８−２）、それがルートオブジェクト１８０の場合（８−３）を除いて、アンサティスファイドリンクス内のオブジェクト識別２０１を調べて、過去にローディングしたオブジェクトで参照されているかどうかを決定する。アンサティスファイドリンクスにオブジェクト識別が存在する場合（８−４）、同じ識別およびバージョンのオブジェクトが既にキャニスタに装荷されたかどうかをキャニスタローダが決定する（８−５、８−６）。存在しない場合は、生オブジェクトデータをスクラッチパッドメモリエリアに書き込み（８−８）、ここで、認証のために署名及び／又はチェックサムをチェックし、これは誤りがない（８−９）。オブジェクトが本物で誤りがないと仮定して（８−１０）、これをクリアテキストに解読し（８−１１）、オブジェクトが多様なペイロードを含んでいる場合（８−１２）、ペイロード式を評価してどのペイロードの処理・ローディングを行うべきかを決定する（８−１３）。キャニスタローダは、次に、ペイロードの見出しで参照したコーダとトランスレータを実行し（図２６参照）、ペイロードの２進画像２１２を順番に処理し（８−１４、８−１５、８−１６）、結果を宛先またはファイルパスネームアドレス２１１のメモリに書き込む（８−１７）。宛先アドレス２１１はキャニスタ１４７内のメモリロケーションを表す。また、宛先アドレス２１１はバッファメモリエリア１５１またはプラットフォーム内のその他のメモリエリアなどの付加的なロケーションを表示しても構わない。例えば、トリガストリームから実時間でアプリケーションペイロード２０５をダウンロードし、プラットフォーム内の一時的に使っていないどこか他のメモリ資源にローディングするようにもできる（例えば、デジタル地上波放送テレビ受信機のＭＨＥＧ−５エンジン用に設けられたスクラッチパッドやバッファメモリエリア）。
【００５５】
次に、キャニスタローダは該当がある場合、ペイロードやチェックが参照する各オブジェクトリンクを読み込んで、各参照オブジェクトが既にキャニスタにローディングされているかどうかを決定する（８−１８、８−２２）。参照オブジェクトがローディングされていない場合、その識別をアンサティスファイドリンクステーブルに追加する（８−２３、８−２４）。最後に、アンサティスファイドリンクスにローディングしたオブジェクトエントリを削除する（８−２０）。
【００５６】
放送終了マーカ１８４に到達するまで、全オブジェクトについて解析プロセスを続け（７−３）、一時的キャニスタローダ素子１５３またはその実質的部分があればこれをスクラッチパッドエリア１４８から消去する（７−６）。一時的ローダ部分をスクラッチパッドに残存させることもできるし、あるいは、キャニスタに配置して、デルタストリーム１７２やトリガストリーム１７３を処理するようにしても構わない。
【００５７】
サービスエンタイトルメント
ユーザが保有権利を実施したり閲覧したりするのにセッション中に実時間でダウンロードするのと違い、通常、オブジェクトのダウンロードは予定された時刻に実行されるため、ユーザの機能範囲へのアクセス権の有無、または、コンテンツを視聴するか否かに拘わらず、セッション前にシェルに所属する全オブジェクトをキャニスタにローディングする。その結果、ユーザがアプリケーション内の一定の機能範囲を起動させたり、実時間で"権利取得"したりできるため、望ましい手法といえる。これについて後述する。
【００５８】
ユーザ１１８が手持ち型コントローラ１１７の"サービス"キー１２８を使って目下アクセス権を持っているかまたは持っていないキャニスタの対話式サービスを選択し、局所記憶からプラットフォームに放映するテレビ放送チャンネルまたはビデオセグメントとしてビデオ２２０を視聴する視聴スクリーン１１３を図１７に示す。図２７に示すように"アクション呼出し"オーバーレイ２２１がスクリーン２２０に現れ、ユーザに権利の申し込み条件と権利入手に何をすべきかを知らせる。スクリーン１１３上のビデオ２２０のサイズを任意に縮小することで、互いに重複することなくビデオ２２０とポップアップオーバーレイ２２１をスクリーン１１３に同時に表示できる。ビデオを局所記憶から放映する場合、オーバーレイの間、一時停止するようにもできる。オーバーレイ２２０を不透明にして下にあるビデオ２２０部分を見えなくする、あるいは透明にして、円形、長円形、長方形など任意の形状およびサイズとし、スクリーン１１３上の任意の場所においたオーバーレイ２２１で覆ったビデオ２２０を部分的に見えるようにしても構わない。
【００５９】
または、ユーザがアクセスする権利があるかどうかを認証するのにシェルと関連する所定のオブジェクトだけを求めるようにしても構わない。例えば、対話式ゲームアプリケーションの第１レベルではアクセス権の有無に関係なく全てのユーザがオブジェクトにアクセスできるようにする。しかし、ゲームアプリケーションの次のレベルではユーザに例えば、全ゲームの年会費または個々のゲームをプレーするごとに支払うなどその他の形態の権利申し込みを求め、次のステージのゲームを続けられるようにする。別の例には、ゲームの特徴やコンテンツ２８１を使用または視聴するのに何らかの有料資格を求める電子プログラムガイドアプリケーション２８４がある。
【００６０】
好ましくは、プラットフォームはモデム１１５あるいはＬＡＮプラットフォーム１１９を含むか又はこれと接続する。その結果、ユーザは電話をかけなくても手持ち型コントローラ１１７のカーソルキー１７０を使って多様なテキストエリアまたはポップアップ内のテキストラベルと協働するエリア内の表現効果を移動させ、希望するエンタイトルメントオプションを選択できる。表現効果はユーザにスクリーン上の焦点を知らせ、テキストをマーキングするカーソルまたはその他のアイコンとしたり、エリアを囲む可変境界、可変エリア背景、パターン、可変フォントタイプ、点滅効果、または上記の任意の組合せにしたりできる。
【００６１】
図２８に示した好ましい実施例において、ユーザは手持ち型コントローラ１１７の"サービス"キー１２８を押すことで、フルスクリーンのテレビ放送チャンネルを見ながら、またはプラットフォーム２２０に保存したテレビ番組を放映しながら、キャニスタアプリケーションとサービスを介在メニュー２４０として表示することができる。スクリーンは多様な標識セルを表示し、各々のセルはメニューエリア２３１の異なるサービス（例えば、プログラムガイド２２７、ゲーム２２８、買い物２２９）に対応し、このエリアでは１つのセルを強調表示する２２８。メニューエリア２３１と重複しないスクリーン２２６の第２エリアは、強調表示サービスオプション２２８に関する注釈と情報をもたらし、同じ形状の広告パネルで定期的にオーバーレイさせるようにしても構わない（後述）。ユーザがカーソルキー１２０を押して、強調表示をメニューエリア２３１の別セルに移動させ、新しく強調表示したセルに反応して注釈エリア２２６のコンテンツを変化させても構わない。スクロール矢印２３０が出現して、ユーザは目下表示されていないセルまたはメニューエリア２３１以外のセルに向かって矢印２３０方向に強調表示をナビゲートできる。メニューエリアと注釈エリアと同時に、重複しない第３エリア２２４が既にフルスクリーンで放映したテレビ放送チャンネルまたはテレビプログラムに対応するスケールに縮小したビデオウインド２２０を表示することもできる。ユーザは"ＯＫ"キー１２１を押して、強調表示したセル２２８に対応するサービスを起動させることもできる。ユーザがセル２２８に対応するアプリケーション２９３にアクセスする権利を目下、保有していない場合、図２９に示す１つまたは複数の支払いオプションから選択するようにユーザを勧誘する告示２４１を注釈エリア２２６と置き換える。好ましくは、オプションは、ユーザが強調表示２４３をナビゲートし、"ＯＫ"キー１２１を押して選択したセル２４２に対応する。こうした場合、選択後にメニューバー２３１で強調表示されたアプリケーション２２８を別に強調表示して２４３、焦点が注釈エリア２４１の第２オプションシリーズ２４２の一つ２４３に切り替わったことを知らせる。あるいは、ユーザが強調表示したオプション２２８へアクセス可能な場合、図３０に示すように対応するアプリケーションを呼び出すか、またはサービスアプリケーションセルの第２レベルメニューを表示する。
【００６２】
実行プロセスの起動時またはその後の時点で、任意の実行済みオブジェクトがアクションポップアップ呼び出しをスクリーンに表示する。例えば、図３１に部分的にプレーしたゲームを表示し、このとき、ユーザはアプリケーション内のその他の機能範囲にアクセスする権利条件を満たしているとする。手持ち型コントローラ１１７の"?"（右矢印）キー１２０を押すことで新しい機能範囲を選ぶようにユーザを勧誘し、それにより図３２のオーバーレイ２６０が表示される。
【００６３】
ＬＡＮプラットフォーム１１９またはモデム１１５がプラットフォームにフィットし、図３１の例と同様にユーザはアプリケーションの条件を満たし、ユーザにインパルス応答を行って権利の購入を勧誘する事例を図３３に示す。この場合、右矢印キーを押すとアプリケーションがユーザ告示と、バックアウト又は権利を購入しないオプションを含む多様なエンタイトルメントオプションを備えるオーバーレイ２６０を表示する。ユーザは希望するオプションに対応するセル２４２まで強調表示セル２４３をナビゲーションし、"ＯＫ"キー１２１を押す。次にモデム１１５またはＬＡＮプラットフォーム１１９をサービスプロバイダと接続させ、エンタイトルメントメッセージをプラットフォーム１０９に放送するか、あるいは電話ネットワーク１０８とモデム１１５（あるいはインターネット１０８、アクセスポイント１３９およびＬＡＮプラットフォーム１１９）を通じてプラットフォームに戻すことで、プラットフォームはアプリケーションを実行するか、または図３４に示すようにアプリケーションの次のレベルを実行する。
【００６４】
肯定的や否定的なエンタイトルメントメッセージを放送するプロセスを使用してユーザのプラットフォームへの個々のアクセスを制御する。このプロセスを図３５に示し、以下に説明する。アプリケーション２９３がアクションポップアップ２４１、２６０、２７０呼び出しをスクリーン上に表示し（９−５）、ここで（ｉ）ユーザが目下権利を保有していないアプリケーション機能範囲の一部使用を試みた（例えば有料ゲームの選択またはプログラムガイドの有料機能の選択）、または（ｉｉ）ユーザのアプリケーションとの双方向履歴がアプリケーションの機能範囲に埋め込まれた条件を満たしている（例えば最小ゲームスコアを突破）場合、ユーザが有料機能範囲を選んでいると（９−２）決定する（９−３）。
【００６５】
アプリケーションは、フラッシュメモリのアプリケーションクッキー領域内部で正確なエンタイトルメントメッセージネームであるエンタイトルメントネームを検索する（９−３）。これを発見し、そのコンテンツが有効な場合（後述）、アプリケーションの有料部へのアクセスが認められる（９−４）。有効なエンタイトルメントメッセージコンテンツが見つからない場合、ユーザに対して、スクリーン上にアクションメッセージ呼び出しを表示する（９−５）。ユーザは権利要求するか、または要求を破棄してアプリケーション機能範囲の無料素子に戻るか（９−１１）を決定する（９−１０）。アプリケーションはモデム１１５またはＬＡＮプラットフォーム１１９がＳＴＢ１１４と接続しているかを決定し（９−９）、該当する場合は接続できるかを決定する（９−７）。必要に応じて、自動式アウトエンタイトルメントを使用する（９−６）。
【００６６】
モデムまたはＬＡＮプラットフォームが存在しない場合、あるいは接続が確立できない場合、図３６に示すようにアプリケーションはマニュアルエンタイトルメントという方法を使い（９−８、１０−１）、これを後述する。この手法を用いると、権利保有情報をユーザのプラットフォームに実時間で放送でき、ユーザにパスワードや数字配列の入力を要求しないため、速度と手間という点から有利である。アプリケーションは、最初に放映中の任意のテレビビデオをフリーズさせ、目下のチャンネルの調整設定を記憶する（１０−２）（これにより、後でリストアできる）。アプリケーションはプログラム可能チューナ３００とデマルチプレクサ３０１にコマンドを送って、トランスアクションストリーム１７４を伝えるマルチプレクサとデマルチプレクサにプラットフォームを同調させ、そのパケットＩＤ（ＰＩＤ）に従ってフィルタし、コンフィギュレーションテーブルから回復したストリーム識別を搬送する（１０−３）。
【００６７】
輸送ストリームが見つからない場合（１０−４）（例えば、信号有効範囲の問題により）、診断メッセージ（１０−１０）をスクリーンに表示してプロセスを終了する（１０−２０）。あるいは、アプリケーションはプラットフォームに既に割り当てられたブロードキャストアドレスがあるかどうかを調べて決定する（１０−５）。ブロードキャストアドレスが過去に割り当てられていない場合、ブロードキャストアドレス用のランダムな数字を生成し、これを非揮発性プラットフォームメモリ１４４に書き込む（１０−１１）。ユーザが引用間違いしたときのコールセンタ１３５による認識を補助するためにスクリーンにブロードキャストアドレスを表示する場合、典型的に３〜５デジットから成る付加的グループであるチェックサムを付加する。好ましくは、ベース３３にディスプレイ目的でブロードキャストアドレスを大文字のアルファベットと数字で表示し、ユーザの認識エラーを減らすために３つの文字（Ｏはゼロと、Ｉは１と、Ｑはゼロと見間違いやすい）を使用しない３〜５デジットのグループとする。アクション２６０の呼び出しをスクリーンに表示し（１０−６）、サービスの特徴、利益、値段、エンタイトルメントを起動させるための電話番号、引用するブロードキャストアドレスを記載した権利保有の申し込みをユーザに提示する。次に、アプリケーションがダウンロードに伴い、識別エンタイトルメントネームを有するエンタイトルメントメッセージをフィルタする（後述）。
【００６８】
ユーザは表示された電話番号を使ってコールセンタ１３５へダイヤルする（１０−７）。コールセンタの顧客サービス係り（ＣＳＲ）がユーザの電話に応える（１０−８）。ユーザはＣＳＲに連絡先や支払いの詳細を伝え（１０−９）て、取引決済を始める。支払いの詳細には、クレジットカードの詳細またはクーポンエンタイトルメントシーケンス（後述）を含むことができる。ユーザはＣＳＲにスクリーンのブロードキャストアドレスを読み上げる（１０−１２）。ＣＳＲは取引決済を認証し、ユーザのデータベースをチェックして同一のブロードキャストアドレス値を別のプラットフォームに既に割り当てていないかを決定する（１０−１３）。この場合、ＣＳＲは手持ち型コントローラにキーシーケンスを入力するようにユーザへ求め（１０−２２）、これによりプラットフォームアプリケーションが新しいブロードキャストアドレスを生成してアクション呼び出しオーバーレイ内のスクリーンにこれを表示し（１０−２１）、ＣＳＲはユーザにそれを再度読み上げるように求め、それが唯一無二であるかのチェックプロセスを繰り返すことができる。ブロードキャストアドレスが有効かつ固有であるとＣＳＲが認証すると（１０−１３）、ＣＳＲはエンタイトルメントメッセージをブロードキャストアドレスのプラットフォームアドレスに放送するようにする（１０−１４）。エンタイトルメントメッセージは以下の情報を含むデータパケットから成る：
ブロードキャストアドレス[...ブロードキャストアドレスＭ]：ここで、[...]は同一のメッセージを受信および処理するその他のプラットフォームに対する任意のブロードキャストアドレスを含む；
エンタイトルメントネーム：プラットフォームファイルシステムの保存や後のアプリケーションによる検索用のエンタイトルメントメッセージの名前；
機能範囲１[...機能範囲Ｎ]：ここで機能範囲１は、１つのアプリケーションまたはアプリケーショングループ内の特有の機能範囲に割り当てられた固有の識別子で、それに対するアクセス権が認められ、[...]は同じメッセージによってアクセス権が認められた任意のその他の参照を含む；
開始時刻日付：期限満了時刻日付：ここで開始時刻日付はアクセス権が発効する時刻と日付で、期限満了時刻日付はアクセス権が失効する時刻と日付；
ユーズカウント：１つのアプリケーションまたはアプリケーショングループ内の機能範囲の最大許容累積使用回数（ゼロは無制限を意味する）；
使用時間：１つのアプリケーションまたはアプリケーショングループ内の機能範囲の最大許容累積使用時間（ゼロは無制限を意味する）；
発行者識別：権利パケットを販売した発行者の任意の識別で、この詳細については後で説明する。
エンタイトルメントメッセージに含まれるこれらのパラメータによって、経過時間、セッション回数、セッションの有効期限、またはこれらの組合せに基づいてアクセスの制御が可能になる。前払いトークンなどエンタイトルメントメッセージに付加的なパラメータを加えることでユーザのエンタイトルメントプロセスにさらに柔軟性をもたらすことができるのは当業者であれば理解されよう。
【００６９】
プラットフォームはエンタイトルメントメッセージをダウンロードし、エンタイトルメントネームとして非揮発性記憶エリアのファイリングシステム内に保存する（１０−１５）。プラットフォームアプリケーションが新しいメッセージとしてのエンタイトルメントネームの存在をプラットフォームファイリングシステム内に認識したとたん、このメッセージを開いてエンタイトルメントパラメータに読み込む。これらが有効だと仮定して、エンタイトルメントの承認メッセージをスクリーンに表示し（１０−１６）、ＣＳＲは、スクリーン上にエンタイトルメントを受け取った旨の承認をユーザに求める。ユーザが承認した場合、ＣＳＲはお礼を述べて、両者は通話を終える。ユーザが承認しない場合、ＣＳＲはユーザと問題解決を図るが、うまく解決できないときは、ＣＳＲは次の１つまたは複数のデータストリームバーストで権利剥奪メッセージを送るようにしても構わない（１０−２３）。
【００７０】
クーポンエンタイトルメント
エンタイトルメントプロセスの間に決済の詳細を提供する別の手段によれば、プラットフォーム１０９の販売時あるいは後刻に、小売業者が前払いクーポンをユーザ１１８に発行し、このクーポンは、サービスを受けるためのエンタイトルメントとして使用したり、発行者に特有の広告として使用したりできる。
【００７１】
図３７に基本的なステップを示す。発行者はユーザに、番号または文字のエンタイトルメントシーケンスを表示し、不透明な表面で覆われた紙のクーポンを販売する（１１−１）。ユーザは不透明な表面を取り除いて、シーケンスを見えるようにし、エンタイトルメントステップの一部として（１０−９）、クレジットカードの詳細の代わりに、このシーケンスをＣＳＲに伝える（１１−２）。このステップの間、ＣＲＳはシーケンスが有効であることを認証し、これを記録して将来再使用されることを防ぐ。有効なエンタイトルメントシーケンスは全可能シーケンスの小さなサブセットで、未使用クーポンを所持せずに不正ユーザが有効な未使用のシーケンスを正確に予想することは不可能である。
【００７２】
発行者
エンタイトルメントシーケンスに付加的な情報として、クーポンの発行者を識別する発行者識別を含ませることができる。発行者は所定のコンテンツまたは広告のスポンサーになることを選び、これらを販売したプラットフォーム１０９に割り当てる。これは、購入者であるユーザと購入後に、より多くの接触を維持できるため、例えば、チェーン展開している小売店または小売チェーングループを代表する特約カード機関などの発行者にとって有益である。好ましいエンタイトルメントプロセスにおいて、ＣＳＲがエンタイトルメントシーケンスから発行者識別を回収し（１１−３）、発行者と決済を調整する将来の請求作業のために保存し、これをプラットフォームに放送するエンタイトルメントメッセージに含むようにする（１０−１４）。プラットフォームアプリケーション２９３がエンタイトルメントメッセージから発行者識別を回収し、非揮発性プラットフォームパラメータ１４３としてこれを保存する（１１−４）。最終的に、多数の発行者の各識別に従って、プラットフォーム１０９の全母集団を部分母集団で分割する。
【００７３】
広告
各発行者は自身の広告データベース１９０を維持し、データセンタ１００、マルチプレクサ演算子１０６、またはインターネット１０８を通じてプラットフォーム１０９に各広告を放送する（１１−５）。各広告は、オブジェクト２００内のペイロード２０５と対応する。ペイロード式２０４は各ペイロード２０５と関連し、エンタイトルメントステップの間にプラットフォームパラメータ１４３として既にプラットフォーム１０９にダウンロードしてある１つまたは複数の識別、すなわち発行者識別を参照する。前述したように、キャニスタローダはバースト事象１７１またはデルタ１７２事象の間に式２０４を評価し、式が正しい場合、対応するペイロード２０５をキャニスタにダウンロードする（１１−６、１１−７、１１−８）。好ましい実施例において、広告をＨＴＭＬ／ジャバで符号化したパネルとし、ファイル２８２として保存して、コンテンツブラウザ２８７が注釈エリア２２６上のネット広告メニュー２４０内にこれを表示する。しかし、類似のステップを用いて、スクリーン上の任意の位置に他の任意のアプリケーション２９３で広告を表示できることは理解されよう。
【００７４】
セットトップボックスのハードウエアコンフィギュレーション
図３８に、ＤＶＢテレビ伝送を受信しディコード化するのに使用する典型的なデジタルＳＴＢ１１４の内部機能要素を示す。これは典型的に、消費者テレビ市場においてキャニスタローダが相互情報交換に利用する機能性である。これは揮発性ＤＲＡＭ１４６と結合するＣＰＵ３０３と非揮発性（フラッシュ）メモリ１５２から成る。ＣＰＵとその他のブロックとの通信は１つまたは複数のシステムデータバス３１１を通じて行う。
ＣＰＵは、ＩＲ受信器３１２を通じて、赤外線（ＩＲ）式の手持ち型コントローラ送受器１１７からのユーザコマンドを受ける。ＳＴＢがスタンバイモードの場合、実時間クロック（ＲＴＣ）またはカウントダウンタイマー３０８がＳＴＢの一部をパワーアップさせる時期を制御する。好ましい実施例において、ＳＴＢがダウンロードの間のスタンバイモードにあるとき、低パワーモードのＣＰＵとメモリがＲＴＣ３０８、ＩＲ受信器３１２、及び完全に電源を切ったプログラム可能電源３１０を除く他の全ブロックを操作する。ＳＴＢが活動状態、スタンバイ、またはダウンロード状態に入る必要があるかに応じて、ＣＰＵが電源を制御して１つまたは複数のその他のブロックに対する電圧レールの印加と除去を行う。ＳＴＢがＰＶＲ機能を有する場合、何らかの形態の大容量記憶インターフェース３０４を備えることになる。これは、典型的にＡＴＡＰＩまたはＳＣＳＩハードディスクインターフェースであるが、任意の手近な大容量データ記憶インターフェース標準を実施して構わない。
【００７５】
ＳＴＢはプログラム可能チューナ３００を含み、これがアンテナ１１６を介してＤＶＢ−Ｔ放送受信に接続している。また、チューナを受信ケーブルと衛星通信としても構わない。内部データバスによってキャニスタローダ１４０のアプリケーションソフトがチューナ３００とデマルチプレクサ３０１をプログラムして、データセンタ１００通信を伝えるストリーム（チャンネル）を含む、アンテナ１１６に存在する任意のＭＰＥＧ２トランスポートストリーム（チャンネル）を受信するようにできる。調整したトランスポートストリームをデマルチプレクサ３０１に適用し、ここで基本のオーディオ、ビデオおよびデータストリームを抽出することができる。ビデオデータストリームをＭＰＥＧ２ビデオデコーダ３０２に適用する。このデコーダの出力をスクリーン表示ＯＳＤと組み合わせて、ビデオ信号をテレビ１１２に供与する。ＯＳＤはキャニスタアプリケーションの全図形要素を表示する役割を果たす。ビデオミックスとスケール機能はデコーダビデオの縮尺が可能で、サイズ縮小したライブビデオをテレビスクリーン１１３の任意の位置に表示できる。
【００７６】
図３８に記載した機能要素の多くを、ＳＴマイクロエレクトロニクスのＳＴｉ５５１７チップセットなどの単一大規模集積（ＬＳＩ）シリコン要素と組み合わせることができる。デジタルテレビ受信機の場合、図３８に記載した全機能がテレビシャシー内部に常駐している。さらに、ＳＴＢは、デジタル式テレビ信号からデータ回復するときの補足的または代替的手段として、アナログ式テレビ信号からデータを受信する手段を備える。データ回復は、例えば、ＰＡＬ、ＳＥＣＡＭ、ＮＴＳＣテレビ規格に従ってコード化したアナログ式テレビジョンチャンネル信号からプログラム可能チューナを通じて回復させたベースバンド信号の垂直帰線消去期間（ＶＢＩ）に含まれるラインから文字放送デコーダ３０９を使ってアナログ手段でデータをディコード化することにより達成される。
【００７７】
当業者であれば、本発明から逸脱することなく、記載した配置の応用が可能なことは理解されよう。従って、上述した実施例は単に例示手段に過ぎず、本発明を限定するものではない。記載した実施例に有意な変更を加えずに若干の改変が可能なことは当業者であれば理解されよう。
【図面の簡単な説明】
【００７８】
【図１】テレビ放送システムのブロック図。
【図２】図１に示すシステムのデータセンタのブロック図。
【図３】外部エンティティと対話できるように構成したテレビジョンシステムのブロック図。
【図４】図１のシステムで使用するリモートコントロールユニットを示す。
【図５】外部エンティティと対話できるように構成した別のテレビジョンシステムを示す。
【図６】図１のシステムにおいて、テレビなどのユーザプラットフォームでどのようにメモリを割付けするかを示す。
【図７】図６に示すメモリリソースに含まれるキャニスタの構造を示す。
【図８】バーストストリームシーケンスを示す。
【図９】バーストストリームデータ構造を示す。
【図１０】１日の典型的なデータストリームアクティビティを時間の流れで示す。
【図１１】バーストストリームに含まれる様々な表を示す。
【図１２】ロードループ構成を示す。
【図１３】受け取ったストリーム構成から次のバースト事象のパラメータを決定する工程を示す。
【図１４】デルタストリームデータ構成を示す。
【図１５】対象デルタストリームのロードプロセスを示す。
【図１６】対象デルタのロードプロセスを示す。
【図１７】従来型テレビ放送チャンネルのスクリーンの一場面を示す。
【図１８】トリガプロンプトが表示される図１７のスクリーンの一場面を示す。
【図１９】対話式シーンを駆動させてテレビ番組または広告を強調する図１７のスクリーンの一場面を示す。
【図２０】トリガストリームオブジェクトの操作工程を示す。
【図２１】トリガペイロード構造を示す。
【図２２】オブジェクトデータ構造を示す。
【図２３】バーストロードループを示す。
【図２４】オブジェクトバーストストリームのロードループを示す。
【図２５】オブジェクトバーストロードの工程を示す。
【図２６】オブジェクトペイロードの構造を示す。
【図２７】申し込み勧誘のオーバーレイを表示するテレビスクリーンの一場面。
【図２８】各種サービスを表す対話式のユーザ選択可能アイコンを表示するテレビスクリーンの一場面。
【図２９】一つのサービスが選択され、権利オプションリストを表示した以外は図２８と同じスクリーンの一場面。
【図３０】対話式のユーザ選択可能コンテンツの見出しとサービスの特徴を表示するテレビスクリーンの一場面。
【図３１】必要な基準を満たして初めて新規の機能範囲にアクセスできるゲームアプリケーションスクリーンの一場面。
【図３２】図３１のゲームのオーバーレイを表示するスクリーンの一場面。
【図３３】ユーザ選択可能エンタイトルメントオプションリストを表示した以外は図３２と同じスクリーンの一場面。
【図３４】特徴または可能なコンテンツオプションを表示するスクリーンの一場面。
【図３５】アプリケーションがアクションコールを勧誘する工程を示す。
【図３６】サービスを受けるために手動でプラットフォームへ権利付与するプロセスを示す。
【図３７】クーポン発行者の識別をプラットフォームに課すことに伴う、発行者の広告標的プロセスを示す。
【図３８】セットトップボックスを図示。
【図１】
2006527556.tif 000003
【図２】
2006527556.tif 000004
【図３】
2006527556.tif 000005
【図４】
2006527556.tif 000006
【図５】
2006527556.tif 000007
【図６】
2006527556.tif 000008
【図７】
2006527556.tif 000009
【図８】
2006527556.tif 000010
【図９】
2006527556.tif 000011
【図１０】
2006527556.tif 000012
【図１１】
2006527556.tif 000013
【図１２】
2006527556.tif 000014
【図１３】
2006527556.tif 000015
【図１４】
2006527556.tif 000016
【図１５】
2006527556.tif 000017
【図１６】
2006527556.tif 000018
【図１７】
2006527556.tif 000019
【図１８】
2006527556.tif 000020
【図１９】
2006527556.tif 000021
【図２０】
2006527556.tif 000022
【図２１】
2006527556.tif 000023
【図２２】
2006527556.tif 000024
【図２３】
2006527556.tif 000025
【図２４】
2006527556.tif 000026
【図２５】
2006527556.tif 000027
【図２６】
2006527556.tif 000028
【図２７】
2006527556.tif 000029
【図２８】
2006527556.tif 000030
【図２９】
2006527556.tif 000031
【図３０】
2006527556.tif 000032
【図３１】
2006527556.tif 000033
【図３２】
2006527556.tif 000034
【図３３】
2006527556.tif 000035
【図３４】
2006527556.tif 000036
【図３５】
2006527556.tif 000037
【図３６】
2006527556.tif 000038
【図３７】
2006527556.tif 000039
【図３８】
2006527556.tif 000040
【手続補正書】
【提出日】平成18年5月19日(2006.5.19)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ユーザに対話式テレビ放送を提供するテレビジョンシステムであって、
ローカルメモリと；
データソースからのデータの使用可能性を決定する手段と；
データの第１部分を捕捉する手段と；
前記第１部分をローカルメモリの第１エリアに記憶する手段であって、該第１部分が特定
の第１識別を備える記憶手段と；
ローカルメモリに記憶した１つまたは複数のパラメータ値に従って前記第１部分が使用可
能データの第２データ部分と関連するかどうかを決定する手段であって、該第２部分が特
定の第２識別を備える決定手段と；
第１部分と第２部分に関連性が認められる場合、第２部分を捕捉し、ローカルメモリの第
２エリアに記憶する手段であって、捕捉したデータがユーザに対話式サービスを提供する
のに利用可能な捕捉・記憶手段と、
から成るテレビジョンシステム。
【請求項２】
第２部分を特定の予定利用可能時刻に伝送し、該利用可能時刻に第２部分の捕捉手段を起
動させるようにした請求項１に記載のテレビジョンシステム。
【請求項３】
データの第２部分を複数の条件付きリンクデータオブジェクトとして伝送し、該リンクさ
せたオブジェクトを捕捉・記憶する間にこれらのオブジェクトの識別を分析する手段を含
む請求項１又は２に記載のテレビジョンシステム。
【請求項４】
データをプラットフォーム独自のフォームで伝送し、該データを局所的に実行可能なフォ
ームに変換する前記請求項の何れかに記載のテレビジョンシステム。
【請求項５】
ローカルメモリが揮発性メモリと非揮発性メモリを含む前記請求項の何れかに記載のテレ
ビジョンシステム。
【請求項６】
第１および第２メモリエリアが揮発性メモリである前記請求項の何れかに記載のテレビジ
ョンシステム。
【請求項７】
揮発性メモリがDRAMである請求項６に記載のテレビジョンシステム。
【請求項８】
メモリの第１及び／又は第２エリアをハードドライブで提供する請求項１に記載のテレビ
ジョンシステム。
【請求項９】
ダウンロードしたデータオブジェクト内に含まれるコードに規定したステップに全面的ま
たは部分的に基づいて第１部分および第２部分を処理する手段であって、処理したデータ
をローカルメモリの第２部分へ記憶し、対話式サービスを提供するのに利用する処理手段
を更に含む前記請求項の何れかに記載のテレビジョンシステム。
【請求項１０】
ユーザにサービスを提供していない間にデータの捕捉／ダウンロードを実行するようにし
た前記請求項の何れかに記載のテレビジョンシステム。
【請求項１１】
データソースがテレビ放送ネットワーク及び／又はインターネットである前記請求項の何
れかに記載のテレビジョンシステム。
【請求項１２】
データソースから送信される予定のデータがローカルメモリにあるデータよりも新しく、
最新のものであることを決定し、前記データソースからのデータがローカルメモリのもの
より古く、最新のものでないと判断した場合は予定されたダウンロードを阻止あるいは実
行しないようにした前記請求項の何れかに記載のテレビジョンシステム。
【請求項１３】
データソースからデータを受け取る直前にシステムの１つまたは複数の部分をパワーアッ
プし、データの受け取り直後にパワーダウンする前記請求項の何れかに記載のテレビジョ
ンシステム。
【請求項１４】
データソースから捕捉するデータの一部が、プラットフォームに向けたサービスエンタイ
トルメントあるいはディスエンタイトルメントメッセージから成る前記請求項の何れかに
記載のテレビジョンシステム。
【請求項１５】
提供する対話式サービスが電子プログラムガイドまたはスクリーン上のテレビマガジンか
ら成る前記請求項の何れかに記載のテレビジョンシステム。
【請求項１６】
提供する対話式サービスが双方向対話式ゲームから成る前記請求項の何れかに記載のテレ
ビジョンシステム。
【請求項１７】
提供する対話式サービスが記憶したビデオやオーディオクリップ、またはビデオやオーデ
ィオストリームの再生から成る前記請求項の何れかに記載のテレビジョンシステム。
【請求項１８】
セットトップボックス、テレビ、またはビデオレコーダ、コードレスまたは携帯式電話、
メディアジュークボックス、個人用デジタルアシスタント、移動式電話、あるいは上記の
組合せから成る前記請求項の何れかに記載のシステム。
【請求項１９】
テレビジョンシステムのユーザに対話式テレビ放送を提供するための方法であって、
データソースからのデータの使用可能性を決定し；
使用可能データの少なくともいくつかを捕捉し；
使用可能データの第１部分をローカルメモリの第１エリアに記憶し、該第１部分は特定の
識別を備え；
ローカルメモリに記憶した１つまたは複数のパラメータ値に従って前記第１データ部分が
使用可能データの第２部分と関連するかどうかを決定し、該第２部分も特定の識別を備え
；
第１部分と第２部分に関連性が認められる場合、第２部分をローカルメモリの第１エリア
に記憶し；
それぞれの識別に従ってデータの第１部分および第２部分を処理し；
処理したデータをローカルメモリの第２エリアへ書き込み；
対話式テレビ放送をユーザに提供するのに処理したデータを利用するステップから成る方
法。
【請求項２０】
利用可能な指定／予定時刻に第２部分を捕捉する請求項１９に記載の方法。
【請求項２１】
データの第２部分を１つまたは複数の条件付きリンクデータオブジェクトとして伝送し、
データの第２部分を記憶した後に該リンクオブジェクト内の関連データを決定するステッ
プを含む請求項１９又は２０に記載の方法。
【請求項２２】
データをプラットフォーム独自のフォームで伝送し、捕捉した該データを局所的に実行可
能なフォームに変換する請求項１９〜２１の何れかに記載の方法。
【請求項２３】
ローカルメモリが揮発性メモリと非揮発性メモリを含む請求項１９〜２２の何れかに記載
の方法。
【請求項２４】
第１および第２メモリエリアが揮発性メモリである請求項１９〜２２の何れかに記載の方
法。
【請求項２５】
揮発性メモリがDRAMである請求項２４に記載の方法。
【請求項２６】
ダウンロードしたデータオブジェクト内に含まれるコードに規定したステップに全面的ま
たは部分的に基づいてデータ処理を行う請求項１９〜２５の何れかに記載の方法。
【請求項２７】
システムがユーザにサービスを提供していない間にデータの捕捉／ダウンロードを実行す
る請求項１９〜２６の何れかに記載の方法。
【請求項２８】
データソースがテレビ放送ネットワーク及び／又はインターネットである請求項１９〜２
７の何れかに記載の方法。
【請求項２９】
テレビジョンプラットフォームがセットトップボックス、テレビ、またはビデオレコーダ
、コードレスまたは携帯式電話、メディアジュークボックス、個人用デジタルアシスタン
ト、移動式電話、あるいは上記の組合せから成る請求項１９〜２８の何れかに記載の方法
。
【請求項３０】
テレビジョンシステムのユーザに対話式テレビ放送を提供するための好ましくは、データ
媒体あるいはコンピュータ可読媒体上のコンピュータプログラムであって、
データソースのデータ使用可能性を決定するためのコードまたは命令を有し；
使用可能データを捕捉し；
使用可能データの第１部分をローカルメモリの第１エリアに記憶し、該第１部分は特定の
識別を備え；
ローカルメモリに記憶した１つまたは複数のパラメータ値に従って前記第１部分が使用可
能データの第２データ部分と関連するかどうかを決定し、該第２部分も特定の識別を備え
；
第１部分と第２部分に関連性が認められる場合、第２部分をローカルメモリの第１エリア
に記憶し；
それぞれの識別に従ってデータの第１部分および第２部分を処理し；
処理したデータをローカルメモリの第２エリアへ書き込み；
対話式テレビ放送をユーザに提供するのに処理したデータを利用するステップから成るコ
ンピュータプログラム。
【請求項３１】
対話式テレビ放送コンテンツ及び／又はソフトウエアの更新を含むデータストリームを伝
送する手段と；
データストリームを受信するための複数の異なるユーザプラットフォームとから成るテレ
ビジョンシステムであって、
データストリームは、ストリームのどの部分がどのプラットフォームによって使用される
かを識別するための複数の異なるユーザプラットフォーム識別子を含み、データ及び／又
はソフトウエアの少なくともいくつかは２個以上のプラットフォームによって共有可能で
、各ユーザプラットフォームは自らが使用するデータストリームの部位を認識し、これら
の部位を利用して対話式コンテンツや画像をテレビコンテンツと同時に、あるいは、テレ
ビコンテンツの代わりにスクリーンに表示するようにしたテレビジョンシステム。
【請求項３２】
テレビジョンシステムのユーザに対話式コンテンツを配給するための方法であって、
双方向対話式サービスを実行するために複数の異なるユーザテレビプラットフォームにデ
ータ及び／又はソフトウエアを含む放送データストリームを伝送し；
データストリームは、ストリームのどの部分がどのプラットフォームによって使用される
かを識別するための複数の異なるユーザプラットフォーム識別子を含み、データ及び／又
はソフトウエアの少なくともいくつかは２個以上のプラットフォームによって共有可能で
、各ユーザプラットフォームで自らが使用するデータストリームの部位を捕捉するステッ
プから成り、
それにより、対話式コンテンツや画像をテレビコンテンツと同時に、あるいは、テレビコ
ンテンツの代わりにスクリーンに表示するようにした方法。
【請求項３３】
テレビ放送を受信および表示するテレビ、セットトップボックス、またはその他の大衆消
費電子製品などの双方向対話式テレビジョンシステムであって、
ローカルメモリを有し、条件付きリンクデータオブジェクトの捕捉／ダウンロードが可能
で；
ローカルメモリに記憶したパラメータを使用して記憶が必要なデータオブジェクトを識別
し；
データオブジェクトを識別した場合、これらのオブジェクトをローカルメモリに記憶する
ようにした対話式テレビジョンシステム。
【請求項３４】
データオブジェクトの条件付き階層を複数の異なるユーザプラットフォームに伝送／放送
する方法であって、ユーザプラットフォームが識別に使用可能なパラメータや識別子を含
むデータオブジェクトを後で利用するために記憶する方法。
【国際調査報告】
2006527556.tif 000041
2006527556.tif 000042
2006527556.tif 000043
2006527556.tif 000044
2006527556.tif 000045