(57)【要約】【課題】分散コンピューティング・システム内のデータを管理するための効率的な方法およびメカニズムを提供する。【解決手段】テレビジョン・システムが、受信デバイスに対してオーディオ／ビデオ／インタラクティブ・データを伝達するように構成される。受信デバイスに伝達されるデータは、モジュールとして構造化され、主ディレクトリ・モジュールが、特定のアプリケーションを構成するか、それによって使用されるモジュールを示す。受信デバイスに伝達されているデータに対する変更は、最初に、デルタ・ディレクトリ・モジュールを受信デバイスに伝達することによって示され、それが対応する主ディレクトリ・モジュールに対する変更を識別する。デルタ・ディレクトリ・モジュールによって示される変更は、対応する主ディレクトリ・モジュールに適用され、続いてそれがアプリケーションによって使用されるデータ内に変更をもたらすことができる。デルタ・ディレクトリは、概して、変更の識別に充分な情報を含むだけとすることができ、対応する主ディレクトリより小さくすることができる。【選択図】図５
2008500606.tif 000002
【特許請求の範囲】
【請求項１】
分散コンピューティング・システム内のデータを管理する方法であって、
アプリケーションによる使用のための複数のモジュールを識別する第１のモジュールを受け取ること、
前記アプリケーションに対応する追加のデータであって、前記複数のモジュールのうちの全部より少ないモジュールを識別し、かつ前記第１のモジュールと前記複数のモジュールのうちの１ないしは複数に対して行われる更新を識別する追加のデータを受け取ること、および、
前記更新を行うこと、
を含む方法。
【請求項２】
前記第１のモジュールは、プッシュされる主ディレクトリ・モジュールを含み、前記追加のデータは、前記主ディレクトリ・モジュールに対応するデルタ・ディレクトリ・モジュールを含む請求項１に記載の方法。
【請求項３】
前記受け取られた主ディレクトリ・モジュールは、受信デバイスのメモリ内にストアされ、前記更新は、メモリ内にストアされた前記主ディレクトリ・モジュールの修正を直接行うことを含む請求項２に記載の方法。
【請求項４】
前記デルタ・ディレクトリは、前記デルタ・ディレクトリによって識別される前記更新の実行に応答して前記主ディレクトリが更新されるバージョンを示す識別子を含む請求項３に記載の方法。
【請求項５】
前記更新の実行に応答して、対応する変更が前記複数のモジュールのうちの１ないしは複数にもたらされ、前記対応する変更は、新しいモジュールの追加、既存のモジュールの削除、既存のモジュールに対する改訂からなるグループから選択される請求項４に記載の方法。
【請求項６】
前記複数のモジュールは、実行可能アプリケーション・コードまたは実行間の前記アプリケーションによるアクセスのためのデータのうちの一方または両方を含む請求項５に記載の方法。
【請求項７】
前記第１のモジュールはプッシュされ、前記方法がさらに、前記追加のデータを使用して変更を前記第１のモジュールに登録する前記アプリケーションを含む請求項１に記載の方法。
【請求項８】
前記追加のデータが前記アプリケーションによってプルされる請求項７に記載の方法。
【請求項９】
受信回路であって、
アプリケーションによる使用のための複数のモジュールを識別する第１のモジュールを受け取り、
前記複数のモジュールを受け取り、かつ、
前記アプリケーションに対応する追加のデータであって、前記複数のモジュールのうちの全部より少ないモジュールを識別し、かつ前記第１のモジュールおよび前記複数のモジュールのうちの１ないしは複数に対して行われる更新を識別する追加のデータを受け取るべく構成された受信回路と、
前記更新を行うべく構成された処理ユニットと、
を含む受信デバイス。
【請求項１０】
前記第１のモジュールは、プッシュされる主ディレクトリ・モジュールを含み、前記追加のデータは、前記主ディレクトリ・モジュールに対応するデルタ・ディレクトリ・モジュールを含む請求項９に記載の受信デバイス。
【請求項１１】
前記処理ユニットは、前記主ディレクトリ・モジュールの修正を直接行うことによって前記ディレクトリ・モジュールの更新を行うべく構成される請求項１０に記載の受信デバイス。
【請求項１２】
前記デルタ・ディレクトリは、前記デルタ・ディレクトリによって識別される前記更新の実行に応答して前記主ディレクトリが更新されるバージョンを示す識別子を含む請求項１１に記載の受信デバイス。
【請求項１３】
前記処理ユニットは、前記ディレクトリ・モジュールに対する前記更新の実行に応答して対応する変更を前記複数のモジュールにもたらすべく構成され、前記変更は、新しいモジュールの追加、既存のモジュールの削除、および、既存のモジュールに対する改訂からなるグループから選択される請求項１２に記載の受信デバイス。
【請求項１４】
前記複数のモジュールは、実行可能アプリケーション・コードまたは実行間の前記アプリケーションによるアクセスのためのデータのうちの一方または両方を含む請求項１２に記載の受信デバイス。
【請求項１５】
前記第１のモジュールと前記複数のモジュールは、放送者によって前記受信デバイスにプッシュされ、前記追加のデータは、前記アプリケーションによって代替ソースからプルされる請求項９に記載の受信デバイス。
【請求項１６】
前記第１のモジュールは、前記受信デバイスにプッシュされ、それにおいて前記アプリケーションは、前記第１のモジュールへの直接アクセスが許可されてなく、かつ前記追加のデータを使用して変更を前記第１のモジュールに登録するように構成される請求項９に記載の受信デバイス。
【請求項１７】
アプリケーションによる使用のためのデータを伝達するように構成されたサーバと、
放送のためのデータを伝達するように構成された送信機と、
処理メカニズムであって、
前記データに対応する複数のモジュールを生成し、
前記複数のモジュールを識別する第１のモジュールを生成し、
前記第１のモジュールおよび前記複数のモジュールを伝達し、
前記複数のモジュールに対する変更が必要であることを決定し、
前記複数のモジュールのうちの全部より少ないモジュールを識別し、かつ前記変更を識別する第２のモジュールを生成し、
前記第２のモジュールを伝達するように構成された処理メカニズムと、
を含む放送局。
【請求項１８】
前記第１のモジュールが主ディレクトリ・モジュールを含み、前記追加のデータが前記主ディレクトリ・モジュールに対応するデルタ・ディレクトリ・モジュールを含む請求項１７に記載の放送局。
【請求項１９】
前記処理メカニズムは、さらに、
前記変更を反映する更新済みディレクトリ・モジュールを生成し、
前記更新済み主ディレクトリを、前記デルタ・ディレクトリ・モジュールの伝達の後に続いて伝達するように構成される請求項１８に記載の放送局。
【請求項２０】
前記処理メカニズムは、プロセッサによって実行される実行可能プログラム・インストラクションを含む請求項１７に記載の放送局。
【請求項２１】
プログラム・インストラクションを含むコンピュータによるアクセスが可能なメディアであって、前記インストラクションが、
アプリケーションによる使用のための複数のモジュールを識別する第１のモジュールを受け取り、
前記アプリケーションに対応する追加のデータであって、前記複数のモジュールのうちの全部より少ないモジュールを識別し、かつ前記第１のモジュールと前記複数のモジュールのうちの１ないしは複数に対して行われる更新を識別する追加のデータを受け取り、かつ、
前記更新を実行するために実行可能である、コンピュータによるアクセスが可能なメディア。
【請求項２２】
前記第１のモジュールは、プッシュされる主ディレクトリ・モジュールを含み、前記追加のデータは、前記主ディレクトリ・モジュールに対応するデルタ・ディレクトリ・モジュールを含み、前記受け取られた主ディレクトリ・モジュールは、受信デバイスのメモリ内にストアされ、前記更新は、メモリ内にストアされた前記主ディレクトリ・モジュールの修正を直接行うことを含む請求項２１に記載のコンピュータによるアクセスが可能なメディア。
【請求項２３】
前記更新の実行に応答して、対応する変更が前記複数のモジュールのうちの１ないしは複数にもたらされ、前記対応する変更は、新しいモジュールの追加、既存のモジュールの削除、既存のモジュールに対する改訂からなるグループから選択される請求項２２に記載のコンピュータによるアクセスが可能なメディア。
【請求項２４】
前記第１のモジュールはプッシュされ、前記アプリケーションは、前記追加のデータを使用して変更を前記第１のモジュールに登録する請求項２１に記載のコンピュータによるアクセスが可能なメディア。
【請求項２５】
前記追加のデータは、前記アプリケーションによってプルされる請求項２４に記載のコンピュータによるアクセスが可能なメディア。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、分散コンピューティング・システムに関し、より詳細に述べれば、インタラクティブ・テレビジョン受像機に配信される、かつ／またはそれによって受信されるデータの管理に関する。
【背景技術】
【０００２】
インタラクティブ・テレビジョン・システムは、インタラクティブなコンテンツをはじめ通常のテレビジョンのオーディオやビデオを多数の加入者に配信する手段を提供する。これらのシステムによって放送される番組は、テレビジョンのオーディオとビデオ、静止イメージ、テキスト、インタラクティブ・グラフィクスとアプリケーション、そのほかの多くのコンポーネントを組み込むことができる。またこれらのシステムは、テレビジョンを介した商取引、電子番組ガイド（ＥＰＧ）、ビデオ‐オン‐デマンド等、そのほかのインタラクティブ・アプリケーションといった多くのサービスを視聴者に提供することもできる。インタラクティブ・テレビジョン信号のインタラクティブ・コンテンツは、したがってアプリケーション・コード、オーディオとビデオに関連付けされたデータ、コントロール信号、生データ、多くのそのほかのタイプの情報を含む。この情報は、加入者受信者に対する送信のための１ないしは複数の信号の中に組み込むことができる。
【０００３】
テレビジョンのインタラクティブ機能は、概して、統合化された受信機／デコーダ（ＩＲＤ）または類似のメカニズムによってコントロールされ、しばしばそれは、セット‐トップ・ボックス内に組み込まれる。ＩＲＤは、放送サービス・プロバイダまたはシステム・オペレータによって提供された信号を受信し、インタラクティブ部分をオーディオ‐ビデオ部分から分離する。ＩＲＤは、このインタラクティブ情報をたとえばアプリケーションの実行に使用するが、オーディオ‐ビデオ情報はテレビジョンに渡される。またＩＲＤは、インタラクティブ・アプリケーションによって生成されたインタラクティブ・グラフィクスまたはオーディオを、受信したオーディオ‐ビデオ情報と結合することもできる。
【０００４】
テレビジョン番組と関連のあるアプリケーション・コードまたは情報等のインタラクティブ・コンテンツは、周期的または反復的フォーマットで放送されることがある。このようにして放送される情報の部分が形成するものを「カルーセル」と呼ぶことができる。カルーセルは、所定のアプリケーションに対応する特定のモジュールを識別するディレクトリ・モジュールを含めて複数のデータのモジュールを含むことができる。単一カルーセルを、連続するデータ・ストリームとして運ぶこともできるが、２またはそれを超える数のカルーセルを単一データ・ストリームに多重化することも可能である。カルーセル・フォーマットの代替または補助として、いくつかのシステムは、戻りパスを使用してインタラクティブ・コンテンツの要求および／または受信を行うことがある。
【０００５】
カルーセル内の情報の部分、またはデータ・オブジェクトは、番組を形成するために単一オブジェクト・データ・ストリームに結合されることも意図されていることがある。この番組は、オーディオまたはビデオ等のストリーミング・データを含むか、あるいはそれに関連付けされていることがある。たとえば、インタラクティブ・テレビジョンのゲームショーは、テレビジョンのオーディオとビデオを、ユーザによる質問への回答を可能にするアプリケーション・コード等のインタラクティブ・コンテンツに結合させることができる。別の例は、オーディオとビデオを、スクリーンのボトムに現在の株価をバナーで挿入するアプリケーション・コードと結合するニュース番組である。さらにまた、インタラクティブ・アプリケーションが、ショッピングまたはウェブ・ブラウジング等のサービスを提供することもできる。
【０００６】
上に述べたとおり、インタラクティブ・テレビジョン・アプリケーションは、そのアプリケーションの部品であるモジュールを識別するディレクトリ・モジュールを含むプログラム・モジュールのセットから構成できる。実行可能アプリケーションに関するセキュリティには、署名済み証明書をディレクトリ・モジュールに取り付け、そのディレクトリ・コンテンツを署名することを含めることができる。それに加えて、モジュールの完全性は、ディレクトリ・モジュール内にそれぞれのハッシュ値を含めることによって監視することができる。その後この証明書とハッシュ値を、受信機において、種々の検証プロシージャを使用してチェックすることができる。検証済みのアプリケーションは、その後、実行することが許される。
【０００７】
アプリケーションが、本質的に動的なデータを含むことがあるため、その種のデータの管理が多様な難題を呈する。データ・モジュールに対する変更を効果的に管理するために、多くのアプローチを使用することができる。１つのアプローチは、バージョン番号を用いたモジュールのタグ付けを含む。モジュールのバージョン番号を監視することによって、受信機は、新しいバージョンのモジュールが受信されたことを検出できる。しかしながら、監視されなければならない多くのモジュールが存在する場合には、その種のアプローチが特に効率的であることにはならない。さらに、特定のモジュールがすでに放送されなくなっている場合には（すなわち、この場合の変更はカルーセルからのそのモジュールの削除になる）、受信済みモジュールのバージョン番号の単純な監視が、その種の変更を検出する効果的な手段にならないことがある。
【０００８】
モジュールに対する変更を管理する別のアプローチはディレクトリの監視を伴う。たとえば、上に述べたとおり、ディレクトリ・モジュールは、特定のカルーセルを構成するモジュールを識別することができる。その種のディレクトリは、それらのモジュールのそれぞれの現在のバージョンを示すこともできる。モジュールが変更された場合には、新しいディレクトリが放送され、受信機による処理ができる。ディレクトリの検査が、対応するカルーセル内におけるモジュールに対する変更を明らかにする。しかしながら、ディレクトリ・モジュール自体が比較的大きく、その種のモジュールの処理、検証、分析は軽微ではない。それに加えて、過度の遅れを伴うことなく受信機に変更が通知されることを保証するためには、それらのディレクトリ・モジュールが比較的頻繁に放送されなければならない。その結果、その種のアプローチが、法外な量の帯域幅を使用することがある。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
上記に照らせば、データを管理するための効率的な方法とメカニズムが望まれている。
【課題を解決するための手段】
【００１０】
分散コンピューティング・システムにおいて効率的にデータを管理するための方法およびメカニズムが企図されている。一実施態様においては、テレビジョン・システムが、オーディオ／ビデオ／インタラクティブ・データを受信デバイスに伝達するように構成される。伝達されるデータは、モジュールのカルーセルとして送信できる。主ディレクトリ・モジュールが伝達され、それが対応するアプリケーションによる使用のためのモジュールを識別する。このディレクトリ・モジュールは、対応するアプリケーションの実行を通じて常駐し、実行の間は、アプリケーション・モジュールによるデータの要求を満たすことができる。一実施態様においては、最初に、改訂を受けるデータの部分を示すだけのデルタ・ディレクトリを使用してモジュール・データに対する更新または改訂の識別を受信デバイスに伝達することができる。この種のデルタ・ディレクトリは、対応する主ディレクトリを識別する表示を含む。デルタ・ディレクトリの受信に応答して、そのデルタ・ディレクトリによって示される更新／変更を反映するべく対応する主ディレクトリが更新される。主ディレクトリに対する変更に応答して、新しいモジュールを獲得すること、モジュールを削除すること、あるいは既存のモジュールを改訂することができるようになる。
【００１１】
一実施態様においては、主ディレクトリとデータに関するコントロールが、放送者またはシステム・オペレータにより、受信デバイスの基礎をなすシステムと協働して管理される。その種の実施態様においては、受信デバイス内におけるディレクトリの取り扱いがデバイスのオペレーティング・システムによってコントロールされる。別の実施態様においては、アプリケーション自体を、ディレクトリ・タイプのサービスを提供するように構成することができる。基礎をなすシステムとは別にデータを管理するように構成されたアプリケーションは、放送者とは別のソースを、データに対する更新のための使用することができる。このようにすれば、放送者またはシステム・オペレータが、ディレクトリとそれらのコンテンツに関して完全なコントロールを有する必要がなくなる。本発明のこのほかの目的ならびに利点については、添付図面を参照した以下の詳細な説明を読むことによって明らかになるであろう。
【発明を実施するための最良の形態】
【００１２】
本発明には種々の修正や代替形式が可能であるが、その特定の実施形態を例示の手段として図面の中に示し、以下において詳細に説明する。しかしながらこれらの図面やそれに対する詳細な説明には、開示された特定の形式に本発明を限定する意図はなく、むしろその逆に本発明は、付随する特許請求の範囲によって定義される本発明の精神と範囲内に含まれるすべての修正、等価、変形を保護するものであることを理解する必要がある。
【００１３】
図１を参照すると、テレビジョン・システム１００の一実施形態が示されている。例示の実施形態においては、受信デバイス３０Ａ〜３０Ｚが、番組および／またはインタラクティブ・コンテンツのいくつかのソースと結合されている。受信デバイス３０のそれぞれは、セット‐トップ・ボックス（ＳＴＢ）、テレビジョン（ＴＶ）、ビデオ・カセット録画装置（ＶＣＲ）、ディジタル・ビデオ録画装置（ＤＶＲ）、携帯情報端末（ＰＤＡ）、パーソナル・コンピュータ（ＰＣ）、ビデオ・ゲーム・コンソール、モバイル／携帯電話、あるいはそのほかの任意の適切なデバイスを含む。ここで、文字が追加された特定の参照番号によって参照されている要素は、それらの参照番号のみによって集合的に参照されることがある。たとえば、受信機３０Ａ〜３０Ｚは、集合的に受信機３０として参照される。
【００１４】
図１の実施形態には、送信メディア１７やバック・チャンネル２６を介して受信機（１ないしは複数）３０と結合される放送局１６が含まれる。それに加えて受信機３０は、ネットワーク、すなわちそれ自体がインターネットを表すか、あるいはそれと接続することができるネットワーク２０を介してソース１８、ソース１９の両方と結合される。さらに放送局１６は、リモート・ソース１３やインターネット６０と結合される。図示の実施形態においては、放送局１６がソース１４、１５や送信機２２を含む。送信メディア１７は、衛星ベースのシステム２３、ケーブル・ベースのシステム２４、地上または複数のマルチ‐ポイント分配サービス（ＭＭＤＳ）ベースのシステム２５、これらのシステムの組み合わせ、あるいはそのほかの適切な送信システムを含むことができる。
【００１５】
図１の実施形態においては、放送局１６が、送信機２２によって利用され、伝達されることになる多様なコンテンツのソース１４、１５、６０を含むことができる。コンテンツ・ソース１４、１５は、データベース、アプリケーション・サーバ、そのほかのオーディオ／ビデオ・ソース、あるいはそのほかのデータ・ソースを含む。一実施形態においては、コンテンツが、その種のコンテンツを作るべく構成されたオーサリング・ステーションを含むことができるソース１４において作られる。オーサリング・ステーションは、インタラクティブ・コンテンツの開発の補助となるソフトウエアを伴って構成されたコンピュータ・ワークステーションを含むことができる。オーサリング・ステーションは、放送局１６の一部とすることができ、その場合には、作成されたコンテンツの伝達を、ローカル・コンピューティング・ネットワークまたは類似の構成を介して行うことができる。それに代えて、オーサリング・ステーションが放送局１６から離れたリモート・ロケーション１３に配置されることもある。オーサリング・ステーションが放送局１６と直接結合されない実施形態においては、ソース１３によって作成されたコンテンツを、インターネット、放送、ケーブル等を介して放送局１６に伝達することができる。いくつかの場合には、リモート・ロケーション１３において作成されたコンテンツが、最初にＣＤ‐ＲＷ、ＤＶＤ、あるいはフラッシュ・メモリ・デバイス等のストレージ・メディアに移され、より従来的な手段を介して放送局１６に運ばれ、そこでそれがデータベースまたはそのほかのストレージ・デバイス内にストアされることがある。
【００１６】
この作成に続いて、ソース１３、１４、１５、６０からのコンテンツを、送信ネットワークを介して受信機３０に配信することができる。このネットワークは、基本的に、ソース１３、１４、１５、６０からコンテンツを集め、適宜それらのコンテンツを処理し（たとえば、ディジタル化、圧縮、パケット化）する放送局１６と、コンテンツ４０を放送局１６から受信し、それを１ないしは複数の受信デバイス３０に伝達する送信ネットワーク１７からなる。一実施形態においては放送局１６が、前述したとおりにソース１３、１４、１５、６０によって伝達されるコンテンツを処理するように構成されたソフトウエアおよび／またはハードウエアを含む。第２の配信メカニズムは、受信機３０とソース１８の間の直接的なポイント‐ツー‐ポイント接続１３８を含むことができる。ソース１８は、たとえば、何らかのタイプのサーバを含むことができる。接続１３８は、従来の電話回線、ケーブル、ワイヤレス、またはそのほかとすることができる。第３の配信メカニズムもまたポイント‐ツー‐ポイントの接続１３６とすることができるが、ソース１９から受信機３０へのコンテンツの送信は、１ないしは複数の共有ネットワークを介して（たとえばインターネット経由）行われる。
【００１７】
図１は、放送局１６がオプションとしてソース１８および／またはソース１９と結合され得ることも示している。その種の結合は、受信機３０へのコンテンツの伝達において放送局１６がソース１８またはソース１９と協働することを可能にできる。たとえば、受信デバイス３０を、放送局１６やほかのソース（１８、１９）の両方から受信したコンテンツを結合するように構成することができる。その種の例として、ウェブ・ベースのコンテンツとテレビジョン番組の合体が挙げられる。また図１には、バック・チャンネル（または戻りパス）２６も例示されており、それによって受信デバイス３０が放送局１６と通信することができる。バック・チャンネル２６は、電話回線、ケーブル、ワイヤレス、またはそのほかの接続を含むことができる。
【００１８】
１つの配信メカニズムであるコンテンツのソースに対する直接的なポイント‐ツー‐ポイント接続は、従来の電話回線を介した通信を含むことができる。このタイプの接続は、通常、受信機３０によって開始されてデータ・サーバに対して情報を伝達し、あるいはそこから情報を検索する。別の配信メカニズムである１ないしは複数のネットワークを介したポイント‐ツー‐ポイント接続は、インターネット上のノード間の一般的な接続を含むことができる。インターネットを介してルーティングされるデータが多くの異なる共有ネットワークを伴い得ることから、データがソース１９から受信機３０に送信されるとき、多数回にわたって読み取り、ストアし、書き込むことができる。すでに述べたとおり、第３の配信メカニズムは、衛星、ケーブル、または地上波放送ネットワーク１７を含むことができる。受信機３０とは、リアルタイム形態で、あるいはストア・アンド・フォワード形態で、またはその両方において情報を送受できる。
【００１９】
一実施形態においては、さらに放送局１６が、受信したコンテンツを１ないしは複数のクライアント・デバイス３０と互換性のあるフォーマットにコード変換するプロキシ・サーバ２１を含む。たとえばプロキシ２１は、ＳＧＭＬ、ＸＭＬ、ＨＴＭＬ、ジャバスクリプト（Ｊａｖａ（登録商標）ＳｃｒｉｐｔTM（ＪａｖａＳｃｒｉｐｔはサンマイクロシステムズ（Ｓｕｎ  Ｍｉｃｒｏｓｙｓｔｅｍｓ，  Ｉｎｃ．）の商標）、ＣＳＳ、あるいはそのほかの言語で記述されたコンテンツを含むウェブ・ベースのコンテンツを受信することがあり、受信したコンテンツをクライアント３０と互換性のあるフォーマットにコード変換することができる。代替実施形態においては、クライアントがその種のコンテンツを直接処理するように構成できる。その種の場合においては、プロキシ２１を、クライアントに対する伝達に先行して特定タイプのコンテンツの前処理を実行するように構成することができる。
【００２０】
一実施形態においては、放送局１６から受信機３０に伝達される情報が、帯域幅の節約のために圧縮される。モーション・ピクチャ・エキスパート・グループ（Ｍｏｔｉｏｎ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔ  Ｇｒｏｕｐ）（ＭＰＥＧ）圧縮標準の１つのように、多数ある圧縮アルゴリズムのいずれかを特定の番組またはアプリケーションのために適宜使用することができる。タイムスタンプもまた、たとえば関連付けされたオーディオ信号とビデオ信号の同期のために追加することができる。圧縮に続いて、送信に先行してデータをパケット化してもよい。パケット化は、概して、パケット内に圧縮（または圧縮解除）情報を伴う。その後これらのパケットが多重化されて、放送チャンネルにわたる送信のためのオーディオ‐ビデオ‐インタラクティブ信号が構成される。
【００２１】
受信機３０は、受信したパケット化された信号を処理し、その信号内に埋め込まれていたテレビジョン番組とインタラクティブ・アプリケーションを復元する。復元されたアプリケーションは、続いて受信機内において実行されるが、復元されたテレビジョン番組は、表示のためにテレビジョンに渡される。インタラクティブ・アプリケーションは、表示に先行してテレビジョン番組と結合されるグラフィクスおよび／またはオーディオを生成する。
【００２２】
図２は、アプリケーション（および事実上、任意のカルーセル）が、一連のモジュールからなり、その１つをディレクトリ・モジュールとすることのできる実施形態を例示している。このディレクトリ・モジュールは、通常一意的な識別子を有し、その結果、追加の情報を伴うことなく送信の間に識別できる。このディレクトリ・モジュールは、アプリケーション内のモジュールのそれぞれのためのエントリを含み、一実施形態においては、対応するエントリをディレクトリ・モジュール内に有していないモジュールがアプリケーションによって認識されない。ディレクトリ・モジュールは、充分な情報を有しており、受信機が、プログラムの動作のために必要となることのあるアプリケーションのすべての部品（すなわちモジュール）にアクセスすることを可能にする。ディレクトリ・モジュールは、残りのモジュールが適切に解釈できるように、概してアプリケーションのほかのモジュールの前にアクセスされる。それに加えてディレクトリ・モジュールは、ほかのモジュールに対する基本的にランダムなアクセスが得られることを保証するために、アプリケーションのモジュールが送信されるサイクルの間に数回にわたって送信されることが許される。
【００２３】
一実施形態においては、新しいタイプのモジュールが使用されて、カルーセル内のデータに対する変更がもたらされるか、あるいは示される。このタイプのモジュール、すなわち「デルタ・ディレクトリ」モジュールは、概して、前述したディレクトリ・モジュール（「主」ディレクトリ）の１つに対応し、対応する主ディレクトリ・モジュールに対する変更を示す。しかしながらカルーセルのすべてのモジュールを識別するのではなく、デルタ・ディレクトリ・モジュール（または「デルタ・ディレクトリ」）は、対応するカルーセルに対する改訂または変更の識別に充分な情報だけを含む。このようにすればデータの変更を管理する努力において消費される帯域幅を減らすことができ、受信デバイスに必要とされる処理オーバーヘッドもまた減らすことができる。
【００２４】
ここで図３、４を参照すると、デルタ・ディレクトリの使用を伴わない実施形態およびデルタ・ディレクトリの使用を伴う実施形態が図示されている。図３に、カルーセルの変更についてディレクトリを監視することができるが、デルタ・ディレクトリが使用されない実施形態を例示する。図３には、概して、左から右へ時間の進捗を示す時間線３００が示されている。またディレクトリ（３０２Ａ〜３０２Ｂ、３０４Ａ〜３０４Ｃ）とモジュール３７０も示されている。一般的にいえば、特定のアプリケーションまたはカルーセルに対応するモジュールを識別するディレクトリが（たとえば、テレビジョン・システムにおける放送を介して）送信される。たとえばディレクトリ１（３０２Ａ）は、モジュールＡ、Ｂ、Ｃ、Ｄの識別（３２０Ａ）を含むことが示されている。モジュールＡ、Ｂ、Ｃ、Ｄ（３４０）が、所定の時間フレーム３１０Ａの間に送信されることも示されている。ここで注意する必要があるが、図３が、これらのディレクトリを特定の間隔において示し、またほかのモジュール（３７０）を所定の周波数や特定の順序で示しているが、図３の例示は、いずれかの特定の順序または送信の周波数を表すことが意図されていない。たとえば、種々のモジュールまたはデータの部分が、より小さいユニットに区切られ、ほかのデータとともにより大きな送信ストリームに多重化されることもある。当業者であれば、示されたデータを伝達することのできる広範多様な方法を認識することになろう。なお、ここで文字が追加された特定の参照番号によって参照されている要素は、それらの参照番号のみによって集合的に参照されることがある。たとえばディレクトリ３０２Ａ〜３０２Ｂは、集合的にディレクトリ３０２として参照されることがある。
【００２５】
一般的にいえば、受信デバイスが所定のディレクトリに対応するデータのカルーセルを適切に利用するためには、受信機が、最初にディレクトリを受信して処理しなければならず、その後、そのディレクトリによって識別されるモジュールを受信し、処理する。図３の例においては、第１のディレクトリ・モジュール、すなわちディレクトリ１（３０２）が、時間フレーム３１０Ａの間に２度にわたって送信されることが示されている。また、時間フレーム３１０Ａの間には、ディレクトリ３０２によって識別されるモジュールが送信されることも示されている。モジュールＡ〜Ｄは、時間フレーム３１０Ａ全体にわたって送信されることが示されているが、概して受信機は、モジュールＡ〜Ｄ、およびそれらが表すアプリケーション、オブジェクト、あるいはエンティティの処理と利用に先行してディレクトリ３０２の１つを処理しなければならない。したがって受信機（またはアプリケーション）が第１のディレクトリ３０２Ａの送信後であるが第２のディレクトリ３０２Ｂの送信の前にアクティブ化されることになっている場合には、対応するモジュール３７０によって表されるエンティティ（たとえば、実行可能アプリケーション、ウェブ・ページ等）を利用する前に第２のディレクトリ３０２Ｂを待機しなければならない。
【００２６】
また図３にはカルーセル・データに対する変更３３０が送信されることも示されている。更新および／または改訂は、その変更を反映する完全に新しいディレクトリ・モジュールの送信を伴う。前述したとおり、新しいディレクトリやそれが対応するアプリケーション・モジュールの処理は、時間とリソースをともに消費する。ディレクトリ・モジュールまたはアプリケーションに対して軽微な変更が行われるだけの場合には、完全に新しいディレクトリと対応するモジュールの処理が非効率的なものとなる。それに加えて、ほとんどのディレクトリに変更がないときに完全に新しいディレクトリ・モジュールを送信することは、法外な量の帯域幅を消費することとなる。ここに示した例においては、モジュールＡがモジュールＡ’によって置き換えられている。この変更に続いて、モジュール・グループ３５０Ａ、３５０Ｂに示されているとおり、新しいモジュールＡ’を反映するべくモジュール３７０の送信が変更されている。それに加えて新しいディレクトリ（ディレクトリ２）３０４Ａが、新しいモジュールＡ’を示す改訂後のリスト３２０Ｂを伴って送信される。受信機は、改訂後のディレクトリ・モジュールＡ’を伴うカルーセルを利用するために、最初に新しいディレクトリ３０４の１つを受信し、処理しなければならない。結局、変更３３０が発生した時点と、その変更を受信機が利用できる時点の間に比較的有意の遅延が存在することがある。この方法およびメカニズムの効率を改善するために、「デルタ」ディレクトリを使用することができる。
【００２７】
次に図４を参照すると、デルタ・ディレクトリを利用する実施形態が例示されている。図４の例は図３のそれに類似であり、類似のコンポーネントには類似の番号が用いられている。しかしながら図４の実施形態においては、デルタ・ディレクトリ４００が、モジュールＡ→Ａ’の変更３３０の時点またはそれに続いて送信されることが示されている。この例においては、時間フレーム４６０Ａの間に４つのデルタ・ディレクトリ４００が送信される。別の実施形態においては、特定の変更に対してデルタ・ディレクトリの送信をより早くあるいはより遅く開始することができる。それに加えて、送信されるデルタ・ディレクトリの数、それらの送信の頻度、それらの送信の持続時間もまた異なることがある。
【００２８】
一般的にいえば、各デルタ・ディレクトリは、対応する主ディレクトリに対する改訂を識別し、あるいは示すために必要な最小（または縮小された）量の情報を含む。それに加えて各デルタ・ディレクトリは、それが対応する主ディレクトリを識別する識別子も含むことができる。デルタ・ディレクトリと主ディレクトリの間の関係の識別に適した任意の方法を使用することができる。たとえば、一実施形態においては、連続的な識別子（たとえば、バージョン番号）を送信されるそれぞれの一意的な主ディレクトリに含め、デルタ・ディレクトリが、修正する主ディレクトリを識別する識別子を含むことができる。それに代えてデルタ・ディレクトリが、そのデルタ・ディレクトリの適用後の主ディレクトリのバージョンを識別する識別子を含むこともできる。多くのこの種の代替が可能である。
【００２９】
たとえば図４においては、それぞれのデルタ・ディレクトリが、そのデルタ・ディレクトリの適用後に結果としてもたらされる主ディレクトリのバージョンを示す識別子「２」を含む。一実施形態においては、主および／またはデルタ・ディレクトリに連続番号が与えられる。その結果として、これらのデルタ・ディレクトリの１つを受信する受信デバイスは、そのデルタ・ディレクトリが「１」（直前の連続識別子）として識別される主ディレクトリに続くものであり、それを修正するものであると決定することができる。受信デバイスがすでにディレクトリ・モジュール「１」（たとえば、図４における３０２Ａまたは３０２Ｂ）を獲得していた場合には、受信されたデルタ・ディレクトリ４００によって示される改訂を主ディレクトリに適用することができる。これに対して、受信デバイスがまだ対応する主ディレクトリを受信していなかった場合には、概してその受信デバイスは、データ内の変更を反映する主ディレクトリの受信を待機しなければならない。図４においては、ディレクトリ２（３０４Ａ〜３０４Ｃ）が、データ内における変更３３０を反映する新しい主ディレクトリを表す。
【００３０】
一実施形態においては、主ディレクトリに対する更新を単一（バージョン）のデルタ・ディレクトリによって表すことができる。図４に図示されているとおり、その種のデルタ・ディレクトリを、望ましければ１ないしは複数回にわたって伝達することができる。デルタ・ディレクトリの伝達に続いて、新しい（更新後の）主ディレクトリが伝達される。その種の実施形態においては、受信デバイスがデルタ・ディレクトリを受信し、かつ、それによって更新される主ディレクトリを有している場合に、受信デバイスは、示された更新を単純に適用すればよい。それに代わり、受信デバイスが対応する主ディレクトリを有していない場合には、そのデルタ・ディレクトリによって表される更新を適用することができない。ここで述べている援護のいずれかにおいては、デルタ・ディレクトリが、それが生成するバージョン、それが更新する主ディレクトリのバージョンのうちのいずれか、あるいはその両方を含む。デルタ・ディレクトリの単一バージョンだけを使用して主ディレクトリを更新するシステムにおいては、デルタ・ディレクトリが、それが更新する主ディレクトリのバージョンを明示的に識別する必要がないこともある。たとえば、連続番号またはバージョンのスキームが使用される場合には、デルタ・ディレクトリが更新する主ディレクトリのバージョンが、デルタ・ディレクトリによって生成されるバージョンの直前に先行する番号／バージョンであると仮定することができる。多くのその種の代替が可能であり、かつ企図されている。
【００３１】
代替実施形態においては、特定の主ディレクトリに対応する複数のデルタ・ディレクトリのバージョンが伝達され、受信されることがある。その種の複数のデルタ・ディレクトリは、増分更新、累積更新、あるいはそれら両方の何らかの組み合わせを提供することができる。複数のデルタ・ディレクトリのバージョンを使用するように構成された実施形態においては、各デルタ・ディレクトリが、それが更新する主ディレクトリのバージョンやそれが生成するバージョンの両方を識別することができる。したがって、たとえば特定の主ディレクトリを更新するように構成された３つのデルタ・ディレクトリのバージョンが伝達され、２番目のデルタ・ディレクトリが受信されなかった場合には、第３のデルタ・ディレクトリが累積更新を表す場合に限ってそれを主ディレクトリに適用することが許される。それ以外においては、受信デバイスが、新しい主ディレクトリの送信を待機するか、２番目のデルタ・ディレクトリの再送を実施形態がサポートしている場合にはその再送を待機するか、あるいは累積更新を表すデルタ・ディレクトリの送信を待機しなければならない。またその種の実施形態においては、デルタ・ディレクトリが、それらが累積更新を表すか否かについての表示を含むこともできる。
【００３２】
図４の例からわかるとおり、各デルタ・ディレクトリ・モジュール４００は、発生した変更３３０（Ａ’）を識別する情報を含む。一般に、単一のデルタ・ディレクトリは、任意数の変更を示すことができる。デルタ・ディレクトリがこの変更を識別する情報を含むだけとすることができることから、デルタ・ディレクトリは、それが対応する主ディレクトリよりかなり小さくすることができる。その結果、その種のデルタ・ディレクトリの送信によって消費される帯域幅が、主ディレクトリの送信と比較して有意に縮小されることになる。それに加えて、デルタ・ディレクトリがより小さいことから、受信デバイスによるデルタ・ディレクトリの処理に必要となるオーバーヘッドもまた縮小される。図４の例においては、表示されたデータ内の変更３３０の直後にデルタ・ディレクトリの送信が始まっている。したがってすでにディレクトリ「１」（３０２）を有している受信デバイスは、このデルタ・ディレクトリを受信して処理すればよく、主ディレクトリ「２」（３０４）を待機しなければならない場合よりはるかに早くなる。デルタ・ディレクトリが主ディレクトリより小さいことから、またデルタ・ディレクトリが主ディレクトリより早く受信されることから、それ以外の場合に可能になるよりはるかに早く、受信デバイスが、表示された変更３３０を実装することができる。それに加えて主ディレクトリに対するデルタ・ディレクトリの適用が、更新後の主ディレクトリの識別子（バージョン番号）を更新することもできる。したがって、新しい主ディレクトリ（３０４）が送信されたとき、受信デバイスは、それが最新のディレクトリ情報をすでに有していることや、新しく送信された主ディレクトリを処理する必要がないことを検出する。このように全体的なシステムのパフォーマンスと効率を向上させることができる。
【００３３】
データの管理においてデルタ・ディレクトリを使用する方法の実施形態の高レベルの概要を図５に例示する。一般的にいえば、図５に表されているフローは、受信デバイス内において生じることのある動作を図示しており、説明を目的としてそれを前提とする。しかしながらここで述べる方法は、所定のシステム内において適切と考えられる任意の場所で使用することができる。判断ブロック５８０は、受信済みデータが受信デバイスによって監視されていることを示す。たとえば一実施形態においては、データ・パケットがヘッダ・パケットを有し、受信済みデータの性質を突きとめるために受信デバイスによってそれを分析できる。前述したとおりのディレクトリを含む実施形態においては、受信デバイスが、受信済みデータがディレクトリ・モジュールに対応するか否かを決定することができる（判断ブロック５８０）。ディレクトリ・モジュールが検出された場合には（たとえば、データ・パケット・ヘッダによって示されるとおり）、受信デバイスが、そのディレクトリが主ディレクトリであるか（判断ブロック５８２）、あるいはデルタ・ディレクトリであるか（判断ブロック５８８）について追加の決定を行うことができる。主ディレクトリまたはデルタ・ディレクトリのいずれでもないと示された場合には、種々の実施形態においてそのデータを誤りとして単純に破棄し、エラー・メッセージを記録し、あるいはそのほかを行うことができる。
【００３４】
受信済みディレクトリ・データが主ディレクトリに対応するデータを示している場合には（判断ブロック５８２）、対応する主ディレクトリがすでに受信デバイス内に存在（たとえば、メモリ内にストアされているか、あるいはそれに代わり不揮発性ストレージ内にストアされている）するか否かをこの方法が決定する。表示された主ディレクトリがすでに受信デバイス内に存在している場合には、以前の主ディレクトリとデルタ・ディレクトリの組み合わせからそれが構築されたか、あるいは主ディレクトリの完全に更新されたバージョンが受信されたと考えられる。前述したとおり、一実施形態においては、識別子またはバージョン番号を使用して１つの主ディレクトリと別の主ディレクトリを区別することができる。その主ディレクトリが存在する場合には（判断ブロック５８４）、そのデータを単純に破棄し、受信されるデータの監視を継続することができる（判断ブロック５８０）。これに対して、その受信済みデータが存在しない主ディレクトリに対応する場合には（判断ブロック５８４）、その主ディレクトリを受信し、適宜処理することができる。ここで注意する必要があるが、別の実施形態においては、そのディレクトリを保持し、処理するべきか否かについての決定に先行して完全なディレクトリ、または完全に満たないディレクトリのいずれかを受信することができる。たとえば一実施形態においては、パケット・ヘッダが、伝達されているデータのタイプとバージョンの両方を識別する識別情報を含むことができる。その種の実施形態においては、そのパケットを保持するべきか否かを決定するために、受信デバイスは、受信されたパケットの最初の数バイトを単純に調べるだけでよい。このようにすれば、受信されるパケットの処理をより効率的に行うことができる。
【００３５】
受信済みディレクトリ・データがデルタ・ディレクトリに対応するデータを示しており（判断ブロック５８８）、それがそれまでに受信されていない場合には（判断ブロック５９０）、そのデルタ・ディレクトリの対応する主ディレクトリが受信済みであるか否かについての決定が行われる（判断ブロック５９２）。一実施形態においては、デルタ・ディレクトリが、それが修正する主ディレクトリを直接識別する。しかしながらすでに考察したとおり、デルタ・ディレクトリと主ディレクトリを関連付けする任意の適切な方法を使用することができる。対応する主ディレクトリがまだ受信されていない場合には（判断ブロック５９２）、そのデルタ・ディレクトリを破棄し、処理を判断ブロック５８０に戻す。これに対して、対応する主ディレクトリがすでに受信されている場合には（判断ブロック５９２）、そのデルタ・ディレクトリが受信されるか、あるいはすでに完全に受信されていればその後の処理のために保持され（ブロック５９４）、その後そのデルタ・ディレクトリによって示される変更を対応する主ディレクトリに適用する（ブロック５９６）。そのデルタ・ディレクトリによって示され、主ディレクトリに適用される変更は、モジュールの更新済みバージョンの可用性、新しいモジュールの追加、特定のモジュールの削除、あるいは適切と考えられるそのほかの任意の変更を含むことができる。それに加えて、主ディレクトリのバージョン番号またはそのほかの識別子を更新して、それが更新後のバージョンである旨を反映させることができる。ここで注意を要するが、図５は、ディレクトリの取り扱いの概要を例示することだけが意図されている。これには示されていないが、ほかのデータの受信や処理もまた管理される。
【００３６】
残りの考察に移り、追加の詳細、例、実施形態を例示する。一実施形態においては、すべてのディレクトリ・モジュールが、３つの部分、すなわち、固定長コンポーネントを有する部分、可変長コンポーネントを有する部分、証明情報を有する部分からなる共通フォーマットを有する。固定長部分は、アプリケーションとそのアプリケーション内のモジュールのそれぞれに関するデータを含む。可変長部分は、モジュールの名前とそのモジュールのハッシュに関するストリング・データを含む。最後の証明部分は、作成者の証明書とディレクトリの署名を含む。当業者であれば認識することになろうが、データの真正または完全性を検証するために利用できる多くのテクニックが存在する。一般的なテクニックには、ハッシュ、公開鍵アルゴリズム、ＭＡＣ、パディング等々が含まれる。この数年を経て進化したアルゴリズムの例としてＭＤ‐２、ＭＤ‐４、ＭＤ‐５、ＳＨＡ‐１、ＲＩＰＥＭＤ、ＨＭＡＣ‐ＭＤ５、ＨＭＡＣ‐ＳＨＡが挙げられる。したがって、ここで論じている実施形態がハッシュ値、署名、または完全性のデータを参照することもあるが、任意の適切な検証または認証の方法を、ここで説明している実施形態とともに使用することができる。
【００３７】
一実施形態においては、アプリケーションが、自動的にダウンロードされて実行される少なくとも１つのモジュールを含む。このほかのデータまたは追加のコードを含むモジュールは、直ちに必要とされないこともあり、そのためそれらについてはアプリケーションの実行が開始された後にダウンロードすることができる。しかしながらそれらのモジュールのダウンロードが時間制約を受けることもあり、したがってインタラクティブ・テレビジョン・システムは、それらの制約を考慮に入れて構成され、適時的形態でそれらのモジュールを配信する。必要であれば、それらのモジュールの１つをほかのモジュールまたはデータとともに多重化して、必要時にそれが確実に受信されるようにしてもよい。
【００３８】
図６を参照すると、モジュール５１のそれぞれは、データ・セグメント５２とＣＲＣセグメント５３を含む。ディレクトリ・モジュールのデータ・セグメント５２は、前述のとおりとすることができる。残りのモジュールのデータ・セグメント５２は、アプリケーション・コードまたは生データといった任意タイプのデータを含むことができる。モジュールのそれぞれのＣＲＣセグメント５３は、誤り制御に使用され、モジュール５１の全データ５２について計算される。モジュール５１のそれぞれは、さらに、一意的な識別子を含むことができる。モジュール５１は、それらが送信される前に送信ユニット５４にフォーマットされる。送信ユニット５４のそれぞれは、送信ユニットのストリーム内においてその送信ユニット５４を一意的に識別するヘッダ情報５５、および送信されるモジュールの一部を含むデータ５６を含む。ヘッダ５５は、モジュールＩＤ、モジュールのオフセット、サイズ等の情報を含み、それによって送信ユニット５４を完全なモジュール５１に復元することが可能になる。さらにヘッダ５５は、送信ユニット５４内に含まれているデータ５２のタイプを示す。たとえば一実施形態においては、ヘッダ５５が、そのモジュールをディレクトリとして識別する特殊なＩＤ（たとえば、ゼロ値ＩＤ）を含むことができる。特定のモジュール５１を含む送信ユニット５４は、送信ストリーム内においてほかの送信ユニット５４とインターリーブされてもよい。これに示されている実施形態においては、モジュール５１に関する最後の送信ユニット５４がＣＲＣセグメント５３を運ぶ。
【００３９】
送信ユニット５４のフォーマットは、概して送信メディアに依存するが、通常は一連のパケットを採用する。一実施形態においては、パケットが固定長のものとなる（最終パケットは、適正な長さを得るべくパディングを行うことができる）。パケット列内の最初のパケット５８は、送信ユニット５４のためのヘッダ情報を運ぶ。このヘッダ・パケット５８は、受信デバイスの中央処理ユニット（ＣＰＵ）内に割り込みを発生させることができ、かつＣＰＵが、モジュール５１をデコードするべきか否かについて、およびそれをメモリ内にロードするべきか否かについて決定できる情報を含む特殊なパケットである。
【００４０】
図７は、ディレクトリ・モジュール５００の多くの可能な実施形態の１つを例示している。これに示した実施形態においては、ディレクトリ・モジュール５００が、ヘッダ５１０、アプリケーション・モジュール・データ５２０Ａ〜５２０Ｚ、証明書と署名データ５３０を含む。ディレクトリ・モジュールのヘッダ５１０は、アプリケーションＩＤ、アプリケーション・タイプ（たとえば、広告主のポップアップ、インタラクティブ・ゲーム、スポーツ関連、株式相場表示、気象関連、あるいはそのほかの任意の適切なカテゴリ）を示すフィールド、そのアプリケーションのストアと実行に必要となるメモリの量、そのアプリケーション内に含まれるモジュールの数、認証データ等のセキュリティ・データを含むことのできるフィールドを含む。一実施形態においては、アプリケーションＩＤが、モジュールがディレクトリ・モジュールであることの表示５０１を含むことができ、またそのディレクトリのバージョンを示す表示５０２を含むこともできる。前述したとおり一実施形態においては、ヘッダ５１０が、アプリケーションＩＤとは別にそのモジュールをディレクトリとして識別する特殊なＩＤを含むことができる。ここで認識することになろうが、上にリストしたフィールドとそれに従ったフィールドは例示に過ぎない。異なる情報を適宜含めることができる。たとえばディレクトリ・モジュール５００が、実行間にアプリケーションによってアクセスされるデータを含むこともできる。
【００４１】
ヘッダ５１０に加えてディレクトリ・モジュール５００は、対応するアプリケーション内のモジュールのそれぞれのためのデータを含むことができる。たとえば、各モジュールのためのデータに、送信ＩＤ、モジュールＩＤ、モジュール名、バージョン番号、モジュールの長さ、必要メモリ等々を含めることができる。一実施形態においては、送信ＩＤおよび／またはモジュールＩＤを使用して、放送ストリーム内の対応するモジュールのデータを識別することができる。各モジュールのためのデータ・セクションはまた、それぞれのモジュールに関連するセキュリティ・データのためのフィールドも含むことができる。それに代えてこのデータを、より一般的なディレクトリ情報とともに最初のセキュリティ情報フィールド内に含めてもよい。上記に加えて、種々の実施形態が、対応するディレクトリ・モジュールによって識別されるすべてのモジュールの受信に先行してアプリケーションの実行を許容することがある。その種の実施形態においては、ディレクトリ・モジュールが、対応するアプリケーションの実行が開始できるようになる前に必要となるモジュール（「プレロード・モジュール」）のサブセットを識別する表示を含むこともある。たとえばディレクトリ・モジュールによって識別される各モジュールが、そのモジュールがプレロード・モジュールであるか否かについての表示を含むこともできる。
【００４２】
一実施形態においては、モジュール名が、アプリケーション・コード内において対応するモジュールの参照に使用されることのあるアスキー（ＡＳＣＩＩ）文字列を含むことができる。その種の実施形態は、それによってアプリケーション開発者がアプリケーション・コード内において記述的な名前を使用できることから望ましいことがある。モジュール名を使用する参照は、その後、マッピング・テーブルまたはそのほかの手段を介して対応するオブジェクトにマップされる。たとえばモジュール名を、放送ストリーム内、ネットワーク上、あるいはそのほかにおける対応するオブジェクトのモジュールＩＤに対してマップすることができる。その種のマッピングについてはさらに後述する。
【００４３】
さらにここで注意する必要があるが、種々の実施形態が、所定のアプリケーションに対応するコンテンツの識別に複数のディレクトリを使用できる階層的ディレクトリ・スキームの使用を含むことができる。たとえば、ディレクトリ・モジュール自体が、特定のアプリケーションによって要求されるモジュールのサブセットをそれぞれが記述する追加のディレクトリ・モジュール（「サブ‐ディレクトリ」モジュール）を識別することができる。したがってモジュール・データ５２０は、プログラム・モジュール、ディレクトリ・モジュール、またはディレクトリとプログラム・モジュールの任意の適切な組み合わせを識別することができる。この形態においては、ディレクトリ・モジュールがアプリケーションに対応するアプリケーション・モジュールを識別できる一方、いくつかは、サブ‐ディレクトリ・モジュールを介して間接的に識別されることがある。
【００４４】
図８は、デルタ・ディレクトリの一実施形態を示している。すでに述べたとおり、ディレクトリに対する更新と改訂は、「デルタ」ディレクトリによって表示できる。一実施形態においては、デルタ・ディレクトリが、そのコンテンツが別のディレクトリ・モジュール（たとえば、主ディレクトリ・モジュール、サブ‐ディレクトリ・モジュール、あるいはほかのデルタ・ディレクトリ・モジュール）に対する変更を示すタイプのディレクトリ・モジュールになる。たとえばデルタ・ディレクトリは、特定のアプリケーションに対応する追加のアプリケーション・モジュールが利用可能である旨を示すことができる。それに代えてデルタ・ディレクトリは、対応するモジュール送信ＩＤがすでに有効でなくなった旨を示すことによってアプリケーションからの１ないしは複数のモジュールの削除を示すことができる。またそれに代えてデルタ・ディレクトリは、データが追加、更新、または削除されることを示すコマンド・コードを含むこともできる。広範なその種の変更と、その種の変更を示す方法が可能であり、かつ企図されている。
【００４５】
図８は、ヘッダ７１０、モジュール・データ７２０Ａ〜７２０Ｎ、モジュールの完全性データ７３０を含むデルタ・ディレクトリ７００を示している。ヘッダ７１０は、図７に示されているディレクトリ・ヘッダ５１０に類似の情報を含むことができる。一実施形態においてはヘッダ７１０が、主ディレクトリに対応するか、あるいはそれを識別するアプリケーションＩＤ  ７５０を含む。それに加えてヘッダ７１０は、そのモジュールがデルタ・ディレクトリ・モジュールであることの表示７４０を含む。デルタ表示７４０は、単一ビットによって表されるフラグ程度の単純なもの、あるいはそのほかの任意の適切な表示とすることができる。さらにデルタ表示７４０が、それが更新する主ディレクトリ、それが適用されるバージョン（１ないしは複数）、そのデルタの適用の結果としてもたらさせるバージョン等々を識別することもできる。それに加えて、対応するアプリケーション内の各モジュールのためにモジュール・データを含むのではなく、デルタ・ディレクトリ７００は、何らかの形態で変更されることになるモジュール（またはそのほかのデータ）に対応するデータだけを含むことができる。たとえば、例示の実施形態においては、モジュール用のデータ７２０Ａ〜７２０Ｎがデルタ・ディレクトリ７００に含められることが示されている。このモジュール・データ７２０を、対応する主ディレクトリ・モジュールの更新に使用することができる。更新後の主ディレクトリ・モジュールを基礎として、対応する動作（たとえば、改訂後または新しいアプリケーション・モジュールの獲得、既存のアプリケーション・モジュールの無効化等）を行うことができる。デルタ・ディレクトリ７００がアプリケーションとそのモジュールに対する変更の識別に必要なデータを含むだけであることから（アプリケーション内のすべてのモジュールに対応するデータを包括的に含むことがある従来の主ディレクトリ・モジュールとは対照的に）、そのデルタ・ディレクトリ７００と表示されたモジュール７２０の処理（たとえば、獲得、認証、あるいはそのほかの検証）に必要なリソースを大きく削減することができる。前述したとおり、図８に図示されているエントリは例示に過ぎない。別の実施形態が、特定のシステムの要求を満たすために異なるエントリを有することもある。
【００４６】
図９を参照すると、メモリ６００内にストアされるアプリケーションの一実施形態が示されている。図９の実施形態には、ディレクトリ・モジュール・データ６２０の部分と対応するアプリケーション・コード／データ６１０の両方が図示されている。前述したとおり、ディレクトリ・モジュール６２０は、対応するアプリケーションによって必要とされるすべてのモジュールのリスト６１５を含むことができる。たとえばアプリケーション・コード／データ６１０は、対応するディレクトリ・モジュール６２０によって識別される３つのモジュール６５０Ａ〜６５０Ｃを含むことができる。ここで注意を要するが、図９の例示は、いかなる形においても限定またはそれが包括的であることを意図していない。むしろ図９は、考察のみの目的で種々の特徴を記述している。当業者であれば、図９が単に、考察における補助が意図された抽象的な表現に過ぎず、多くの代替実施形態が可能であり、かつ企図されていることを理解できよう。
【００４７】
図９の実施形態においては、ディレクトリ・モジュール６２０が、アプリケーションのためのマッピング機能を提供することもできる。一実施形態では、マップ６３０が、アプリケーション・コード／データ６１０内において参照される識別子を特定のロケーションにマップするように構成されている。たとえばモジュール６５０Ｂが、多数のプログラム・インストラクションを含む。１つのインストラクション６４０は、「背景」として識別されるオブジェクトに対する参照を含む。この例において「背景」は、そのコンテンツが動的であるオブジェクトを参照することができる。そのコンテンツが動的であることから、「背景」オブジェクトの獲得がランタイム間に必要となることがある。さらに「背景」オブジェクトのロケーションが、そのアプリケーションの記述の時点で既知でないこともある。結局、アプリケーション・コード内において特定のロケーション識別子が使用されるのではなく、抽象的な識別子（「背景」）がアプリケーション・コード内において参照される。この識別子は、その後ランタイム時に、対応するオブジェクトの実際のロケーションにマップすることができる。たとえば「背景」を特定のパケットＩＤ、テーブルＩＤ、拡張ＩＤ等にマップすることができる。
【００４８】
一実施形態においては、コンテンツとデータ（たとえばモジュール）処理が、放送者によって排他的に、あるいは主としてコントロールされる。この形態においては、放送者が、視聴者によって受信されるコンテンツに関するコントロールを維持することができる。たとえば、受信機によって受信されるアプリケーションを、広告を表示するように構成することができる。コンテンツに関するコントロールを維持することによって、放送者は、表示のための特定の広告を、与えられた視聴者のプロファイルに基づいて選択することが可能になる。それに加えてその種のコントロールを維持することは、放送者が、特定レベルの運用の完全性を確保することを可能にできる。たとえば特定のアプリケーションを視聴者に配信する放送者と同じ放送者が、そのアプリケーションによって必要とされる任意のリソースが利用可能となることも保証できる。アプリケーションが表示目的で特定の背景イメージを必要とする場合に、放送者は、その要求されたイメージが放送ストリーム内において、あるいは代替通信チャンネルを介して、必要時に利用可能となることを保証できる。放送者によるディレクトリ６２０および／またはそのマップ６３０のコンテンツのコントロールを可能にすることによって、その放送者は、「背景」参照によって返されるコンテンツだけでなく、そのコンテンツのロケーションもコントロールすることが可能になる。たとえば、コンテンツのロケーションを放送ストリーム内の特定のロケーション、ユニフォーム・リソース・ロケータ（ＵＲＬ）によって示されるロケーション、あるいはそのほかのロケーションとすることができる。
【００４９】
放送者が排他的または主要なコントロールをデータの管理に関して有する実施形態とは対照的に、代替実施形態は、アプリケーション自体でディレクトリ、更新、改訂、および／またはデータ・マッピングを管理するように構成されるアプリケーションを含むことができる。たとえばアプリケーション自体を、そのコードおよび／またはデータに対する更新を獲得するように構成することができる。一実施形態においては、アプリケーションを、サイトまたはロケーションにアクセスし、続いてそれがアプリケーションの改訂または更新が利用できることを示すように構成できる。それに応答してアプリケーションは、改訂または更新の伝達の要求を開始することによって、その改訂または更新をプルすることができる。その後アプリケーションは、それ独自の認証／検証メカニズムを使用してコードおよび／またはデータを更新することができる。それに代えて、基礎をなすシステムの認証／検証メカニズムを使用するべくアプリケーションを構成してもよい。さらにアプリケーションが、それ独自のモジュールとバージョン番号のリスティングを使用してもよく、更新と修正に関する独自バージョンのデルタ・ディレクトリを使用するように構成することもできる。上記の任意の組み合わせを適宜使用することができる。ここで理解する必要があるが、上記の考察は、放送者によるデータの管理と、アプリケーションによるデータの管理の両方を述べているが、システムは、それら２つの任意の組み合わせを組み込むことができる。
【００５０】
ここで使用される場合に基礎をなす「システム」という表現は、放送者またはテレビジョン・システムのオペレータからの許可を伴わずに通常のアプリケーションによる直接的なアクセスが可能でない受信デバイス内のハードウエアおよび／またはソフトウエアの部分を言う。たとえば基礎をなすシステムに、受信デバイスのオペレーティング・システムおよび／またはミドルウェア、メモリまたはそのほかのストレージの選択された領域、条件付きアクセス・サブシステム等々を含めることができる。一例を述べれば、アプリケーションは、あらかじめ決定済みのシステム呼び出しを介してシステム・メモリ空間内の特定のロケーションを読み出すことはできるが、そのロケーションへの書き込みができない許可を有してもよい。当業者であれば、ユーザ・レベルのアプリケーションからシステム・リソースを保護する種々の方法を認識するであろう。
【００５１】
すでに考察したとおり、ディレクトリは、１ないしは複数の対応するアプリケーションのためにマッピング機能を提供することもできる。前述したとおりその種のマッピングは、放送者によってコントロールされる。その種のコントロールは、放送者によるデータのコンテンツとロケーション両方の管理を可能にする。しかしながら代替実施形態においては、マッピングの管理に関する責任をアプリケーションがコントロール（または共有）することができる。その種の実施形態においては、アプリケーションがシステムにマッピングを登録し、その後、図９に記述されている実施形態と同じ、または類似のシステム呼び出しを使用することができる。その種の場合においては、マップ自体をディレクトリの一部として残し、そのコンテンツがアプリケーションによってコントロールされるか、あるいは影響を受けるようにできる。それに代えて、マップの一部または全部をアプリケーションの一部として含めることもできる。さらに種々の実施形態において、放送者によって提供されるマッピングとアプリケーションによって提供されるマッピングを組み合わせることができる。アプリケーションによるシステムへのマッピングの登録を可能にすることによって、アプリケーションは、放送者とアプリケーションによって提供されるマッピングの両方のために単一セットのシステム呼び出しを使用することができる。さらにまた、任意タイプのデータをシステムに登録し、その後そのデータへのアクセスにシステム呼び出しを使用するようにアプリケーションを構成してもよい。
【００５２】
アプリケーションがディレクトリまたはそのほかのデータを前述したとおりに管理するように構成される実施形態においては、アプリケーション・プロバイダが、必要なデータが配置されるロケーションを決定できる。前述の実施形態の場合には、参照されるオブジェクトのロケーションを決定するために、放送者によってマッピング・データが提供された。しかしながら図１０によって例示されるとおりの実施形態においては、アプリケーション自体がオブジェクトのロケーションを直接決定することができる。図１０は、図９の場合と同様に、考察の目的のために意図された抽象的な表現である。図１０は、図９に類似のメモリ６００内のアプリケーションを例示している。図９における場合と同様に、図１０は、アプリケーション・コード／データ６１０、モジュール６５０、ディレクトリ・モジュール６２０を示している。しかしながら図１０の実施形態においては、アプリケーション・コード／データ６１０自体が、参照されるオブジェクトのロケーションを識別するマッピング・データ６３２を含む。図示の実施形態においては、インストラクション６４０が「背景」オブジェクトを参照し、続いてそれを、マップ６３２を介して所定のロケーションにマップすることができる。アプリケーション・プロバイダによってマッピング・データ６３２の提供ができることから、データのロケーションとコンテンツの両方がアプリケーション・プロバイダによってコントロールされるようにできる。当然のことながら代替実施形態においては、マッピング・テーブルを使用する代わりに、インストラクションがオブジェクト・ロケーションに対する直接参照を含むこともできる。
【００５３】
ここで注意を要するが、多くの受信デバイスは、２方向通信の能力を含むことができる。たとえば受信デバイスは、放送信号を受信するための受信機、広帯域モデム等々を含むことができる。その結果としてデータに対する改訂および／または更新の「プッシュ」または「プル」を行うことができる。プッシュされるデータは、受信デバイスに、そのデバイスがそのデータを要求したか否か、あるいは必要としているか否かとは無関係に伝達される。プルされるデータは、受信デバイスに、そのデバイスからの要求に応答して伝達される。図９に示した実施形態のように、アプリケーションがデータのロケーションおよび／またはコンテンツに関してコントロールを有する実施形態においては、アプリケーションによってなされた要求に応答してデバイスにデータがプルされる傾向がよりもっともらしいものとなる。たとえば、アプリケーション・プロバイダがウェブ・サイトを有し、そこからデータをプルすることができる。これに対して放送者がデータのコンテンツとロケーションに関してのコントロールを維持する場合には、その放送者に受信デバイスに必要となると考えられるデータがすでにわかっていることから、放送者がそのデータをそのデバイスにプッシュすることができる。ここで注意を要するが、アプリケーションがデータの要求を行い、続いてそれがプッシュされるデータのソースまたはプルされるデータのソースのいずれか一方から、あるいは両方から検索されることはある。
【００５４】
図１１を参照すると、データを受信し、処理するための方法の一実施形態が示されている。当業者であれば認識することになろうが、このほかにも多くのデータを受信し、処理するための方法が存在し、その種の代替方法はすべて企図されている。ここに示した例においてはパケットが検出されると（判断ブロック５５０）、受信したパケットが未決の要求またはディレクトリ・モジュールに対応するか否かについての決定が行われる（判断ブロック５５１）。未決の要求は、たとえば、未決要求バッファ内にストアすることができ、ディレクトリ・モジュール内において識別されるモジュールに対応することもあり、あるいは実行中のアプリケーションによって作られることもある。そのパケットが未決の要求に対応せず、新しいディレクトリ・モジュールにも対応しない場合には、そのパケットが破棄されるか、あるいは無視される。そのパケットが未決の要求または新しいディレクトリ・モジュールに対応する場合には（判断ブロック５５１）、そのペイロードがメモリ内にストアされる（ブロック５５２）。受信したパケットに対応するモジュールが完全でない場合には（判断ブロック５５４）、処理が判断ブロック５５０に戻り、さらにパケットを待機する。そのモジュールが完全であれば（判断ブロック５５４）、この特定のモジュールが受信され、このモジュールに対応するパケットの検索を一時的に延期できる旨を示す表示をストアすることができる（ブロック５５６）。
【００５５】
完全なモジュールが受信された旨の表示のストア（ブロック５５６）に続いて、受信されたモジュールがデルタ・ディレクトリ・モジュールであるか否かについての決定が行われる（判断ブロック５５９）。デルタ・ディレクトリ・モジュールが受信された場合には（判断ブロック５５９）、そのモジュールに対してセキュリティ・プロシージャを実行し（判断ブロック５７１）、その真正と完全性を検証することができる。モジュールに対して実行されるこのプロシージャは、モジュール自体の中のデータ（たとえば１ないしは複数のフラグ）によって示される所望のセキュリティのレベルを基礎とすることができる。それに代えて、適用されるセキュリティのレベルを、受信されたモジュールのタイプを基礎とするレベル、すべてのモジュールについてデフォルトのレベル、あるいはそれ以外のレベルとすることができる。モジュールが安全であると見なされないと（判断ブロック５７１）、そのモジュールを破棄することができる（ブロック５７４）。それ以外であれば、そのデルタ・ディレクトリによって示される任意の修正を対応する主ディレクトリ・モジュールに対して実行することができる（ブロック５７３）。それに加えて、要求された新しいデータまたはモジュールがあれば、それについての要求をモジュール要求バッファ内に追加することができる。要求されたモジュールが受信され、それが要求に整合する場合には、セキュリティ・プロシージャを実行して、そのモジュールによって示される変更を対応するアプリケーションに適用することができる。
【００５６】
受信されたモジュールがデルタ・ディレクトリ・モジュールでない場合には（判断ブロック５５９）、そのモジュールが主ディレクトリ・モジュールであるか否かについての決定が行われる（判断ブロック５５８）。そのモジュールが主ディレクトリ・モジュールである場合には、システムがアプリケーション・プロバイダの認証を試みることができる（判断ブロック５７０）。一実施形態においては、認証が、ディレクトリ・モジュールに取り付けられている証明書の暗号解除とそのコンテンツのチェックを含むことができる。証明書のコンテンツが真正でない場合には、そのモジュールを破棄し（ブロック５７４）、処理を判断ブロック５５０に戻す。そのモジュールの破棄（ブロック５７４）に加えて、システムは、そのモジュールがまだ受信されていない旨を示す表示をストアし、そのモジュールに対応するパケットの検索を再開することができる。一般的にいえば、モジュールの要求は、対応するモジュールが検索され、かつ検証／認証が済むまで満たされたと見なされることがない。
【００５７】
証明書が真正であると決定されると（判断ブロック５７０）、そのディレクトリ・モジュールに取り付けられていた署名を検証する追加の処理が実行される（判断ブロック５７２）。署名が検証されなかった場合には、そのモジュールを破棄し（ブロック５７４）、システムは、そのモジュールがまだ受信されていない旨の表示をストアして処理を判断ブロック５５０に戻し、その後のパケットを待機することができる。署名が検証された場合には（判断ブロック５７２）、そのモジュールに対応する要求が満たされたものと見なされる。
【００５８】
一実施形態においては、ディレクトリ・モジュールによって識別されるモジュールのそれぞれについて未決要求バッファ内に要求をストアすることができる。受信されたモジュールがディレクトリ・モジュールでない場合には（判断ブロック５５８）、そのモジュールが、対応するディレクトリ・モジュールによって識別されるアプリケーション・コードおよび／またはデータを表すことがある。一実施形態においては、アプリケーション・モジュールのそれぞれが処理されて対応するハッシュ値が計算される（ブロック５６２）。与えられたモジュールについて計算されたハッシュ値が、対応するディレクトリ・モジュールから検索されたか、試験中のモジュールに取り付けられていたか、あるいはそれ以外に受信された、そのモジュールのための対応するハッシュ値と整合しない場合には（判断ブロック５６４）、そのモジュールを破棄することができる（ブロック５７４）。与えられたモジュールについて計算されたハッシュ値がそのモジュールのための対応するハッシュ値と整合する場合には（判断ブロック５６４）、そのモジュールに対応する要求が満たされたものと見なすことができる。その後、すべてのモジュールがチェックされたか否かについての決定が行われる（判断ブロック５６６）。
【００５９】
要求されたすべてのモジュールの処理がまだ完了していない場合には（判断ブロック５６６）、処理がブロック５５０に戻る。すべてのモジュール（または、実行の開始に必要なすべてのモジュール）の処理が完了した場合には（判断ブロック５６６）、対応するアプリケーションを実行することができる（５６８）。それに代えて、前述したとおり、対応するアプリケーションがすでに実行中であれば、アプリケーション・コードおよび／またはデータを、受信したデータに応じて更新することができる。アプリケーションの実行の間は、システムが、送信信号からプログラム・パケットの受信を継続することができる。一実施形態においては、バージョン番号についてパケット・ヘッダが調べられる。特定のモジュールのためのバージョン番号が変化しているときには、新しいモジュールを処理し、以前の対応するモジュールと置き換えることができる。
【００６０】
前述したとおり、アプリケーション・モジュールのサブセットだけをそのアプリケーションの実行の開始前に要求することができる。たとえばディレクトリ・モジュールが、アプリケーションのいずれのモジュールがそのアプリケーションの実行に先行して必要になるか否かを示すことができる。その種の実施形態においては、アプリケーションの実行を、それらの必要なモジュールの受信と検証（判断ブロック５６６）に続いて開始することができる。すべてのモジュールが実行のために要求される場合には、すべてのモジュールが必要である旨の明示的な表示を提供することができる。それに代えて、特定のモジュールのサブセットに関係する表示が提供されていない場合には、実行のためにすべてのモジュールが要求されているものと見なしてもよい。
【００６１】
前述したとおり、図１１に図示したイベントのシーケンスは例示のみを意図している。種々のアクティビティが異なる順序で実行されることもあり、いくつかのアクティビティが同時に実行され、あるいは生じることもある。たとえば図１１は、受信時における各アプリケーション・モジュールのハッシュを例示している（ブロック５６２）。しかしながら代替実施形態は、すべての必要なモジュールが受信された後にその種のハッシュを実行することができる。すべてが受信されるまで待機するのではなく、受信ごとにモジュールの検証を行うことは、アプリケーションの開始の遅れの短縮に役立つことがある。それに加えて図１１は、アプリケーション・モジュールが検証されなかった場合に（ブロック５６４）それが破棄できることを示している（ブロック５７４）。その種の場合においては、破棄されたモジュールの検索が一般に再開されることになる。破棄されたモジュールが再検索される間、すでに検索済みのほかのモジュールの検証（ブロック５６４）を、以前に破棄されたモジュールの検索と並行して継続することができる。多くのこの種の代替が可能であり、かつ企図されている。
【００６２】
さらにここで注意を要するが、受信されたモジュールがすでに実行中のアプリケーションに対応することがある。たとえば実行のために要求されたモジュールのサブセットの受信に続いて、実行中のアプリケーションは、対応するディレクトリ・モジュールによって識別される追加のモジュールを受信することができる。それに代えて実行中のアプリケーション自体がモジュールのための要求を生成することもできる。いずれの場合においても受信されたモジュールがすでに実行中のアプリケーションに対応することがあり、既存のアプリケーション・コードまたはデータを更新する目的のためにそれを使用することができる。ここで使用する場合、アプリケーション・コードまたはデータの「更新」という表現は、追加のデータを用いた既存のアプリケーション・コードまたはデータの補足、既存のコードまたはデータの削除、または既存のコードまたはデータの改訂を意味することができる。
【００６３】
一般的にいえば、ここで述べている実施形態においては、デルタ・ディレクトリが、対応するディレクトリ・モジュールの更新に使用されるデータを含むものとして述べられている。たとえば、アプリケーション・モジュールの改訂バージョンが利用可能な場合には、改訂後のアプリケーション・モジュールを識別するデータを用いてそのアプリケーションに対応するディレクトリ・モジュールを更新するためにデルタ・ディレクトリを使用することができる。ディレクトリ・モジュールの更新に続いて、改訂後のアプリケーション・モジュールを獲得することができる。その種の実施形態においては、デルタ・ディレクトリ自体が改訂後のアプリケーション・モジュールを含むこと、あるいは改訂後のアプリケーション・モジュール内にいずれの改訂が存在するか否かを示すことはない。むしろデルタ・ディレクトリは、対応するディレクトリ・モジュールに対する変更を識別することによってそのアプリケーションに対する変更を間接的に識別するだけである。しかしながらここで注意を要するが、別の実施形態においてはデルタ・ディレクトリ自体が、変更のコンテンツの一部または全部の伝達に使用されることがある。たとえば改訂後のアプリケーション・モジュールが利用可能になった場合に、デルタ・ディレクトリ・モジュールが、対応するディレクトリ・モジュールに対する変更を識別することをはじめ、改訂のコンテンツを含むことができる。その後、完全に新しいアプリケーション・モジュールを獲得するのではなく、その種の改訂を既存のアプリケーション・モジュールに直接適用することができる。さらに別の代替実施形態は、アプリケーション・コードおよび／またはデータに対する改訂を含むが、対応するディレクトリ・モジュールを更新しないデルタ・ディレクトリを含むことができる。ここで述べている方法およびメカニズムの任意の組み合わせが可能であり、かつ企図されている。
【００６４】
一実施形態においては、デルタ・ディレクトリ・モジュールの処理に続いてそのデルタ・ディレクトリ・モジュールを、表示されているデータが更新された後に破棄することができる。たとえば図９を参照するが、放送者によって「背景」オブジェクトのロケーションが変更された場合に、ディレクトリ・モジュール６２０内に含まれているマッピング・データ６３０を単に更新するだけのデルタ・ディレクトリを伝達することができる。そのディレクトリ・モジュールに対する変更だけが行われる場合に、デルタ・ディレクトリは、特にいずれかのアプリケーション・モジュールを識別することなく、対応するアプリケーションまたはディレクトリ・モジュールを単に識別するだけでよい。このデルタ・ディレクトリは、対応するディレクトリ・モジュールの更新に続いて破棄することができる。
【００６５】
デルタ・ディレクトリ・モジュールの破棄の代替として、ほかの実施形態は、デルタ・ディレクトリを保持し、ほかの方法でディレクトリ・モジュールに対する更新を示すことができる。たとえば代替実施形態は、受信済みのデルタ・ディレクトリ・モジュールを保存することができ、その後それが、改訂されるデータについて適宜参照される。実施形態には、その種のデルタ・ディレクトリ・モジュールをすべて伝達し、保存すること、累積的な変更を反映するデルタ・ディレクトリ・モジュールを伝達し、保存すること、あるいはそれ以外を含めることもできる。多くの代替が可能であり、かつ企図されている。
【００６６】
上記に加えて注意が必要になるが、放送者によって伝達される種々のタイプのデータは、異なるレベルのセキュリティを必要とすることがある。たとえば、実行可能アプリケーション・コードは、視聴者の受信デバイスに予期しない、あるいは誤った動作を生じさせる可能性を有することから、放送者が、その種のデータの慎重な認証と検証を望むことがある。これに対して、受信デバイスの動作への有害な影響という点で可能性の低いデータは、あまり厳格でないセキュリティを要求することができる。したがって、すべてのデータについてもっとも高いレベルのセキュリティを要求することは効率的でないと言える。一実施形態においては、デルタ・ディレクトリがさらに、必要なセキュリティ・レベルを示すセキュリティ情報を含むことができる。たとえば、実行可能コードの修正が伝達される場合には、デルタ・ディレクトリが、比較的高いレベルのセキュリティが必要となる旨を示すことができる。高いレベルのセキュリティを必要とするデータは、完全な認証と検証を要求することができる。それに代えてデルタ・ディレクトリは、更新／改訂が行われるデータが高いレベルのセキュリティを必要としない旨を示すことができる。その種の場合において受信デバイスは、利用可能なセキュリティ手段の１ないしは複数を迂回することができる。
【００６７】
最後に図１２、図１３を参照すると、放送局と受信デバイスの一実施形態が示されている。図１２の放送局１６は、アプリケーション・サーバ２５０と、以前に作成されたインタラクティブ・コンテンツを含むことのできるデータベース２３０とを含んでいる。図１２には、放送局１６の外部にあるが放送局１６に結合されているコンテンツのソース１３（たとえばインターネット）も示されている。データベース２３０、サーバ２５０、インターネット６０、ソース１３は、受け取ったコンテンツを処理し、処理済みのコンテンツをマルチプレクサ２２０に伝達するように構成されたコンテンツ処理メカニズム２００に結合されている。
【００６８】
一実施形態においては、コンテンツ処理メカニズム２００が、ソース１３、データベース２３０、またはサーバ２５０からコンテンツを受け取って伝達するべく結合されたコンピュータを含む。処理メカニズム２００は、処理済みのコンテンツをマルチプレクサ２２０に伝達するように構成されている。またマルチプレクサ２２０は、オーディオ／ビデオ信号２４０も受け取るべく結合される。マルチプレクサ２２０は、受け取った信号を多重化し、多重化後の信号をネットワーク通信オペレータ１７に伝達し、続いてそれが、受信デバイスに向けて伝達される。前述したとおりメカニズム２００は、クライアント・デバイスに対してコンテンツを伝達する前に、受信したコンテンツを処理するように構成することができる。たとえばメカニズム２００を、クライアントからウェブ・ベースのコンテンツのための要求を受信し、要求されたコンテンツを獲得し、受信したコンテンツを、要求デバイスに向けて伝達する前に別のフォーマットにコード変換するように構成することができる。最後に、上記に加えて放送局１６は、バック・チャンネル２６に結合される戻りデータ・プロセッサ２１０を含む。一実施形態においては、戻りデータ・プロセッサ２１０は、放送局１６内の追加の処理のためのデータを受信するモデムを含む。
【００６９】
上記に加えて、さらにコンテンツ処理メカニズム２００が、モジュールのカルーセルを送信するように構成されてもよい。その種のモジュールは、前述したとおり、ディレクトリ・モジュール、アプリケーション・モジュール、デルタ・ディレクトリ・モジュールを含むことができる。一実施形態においては、放送局が短い時間期間にわたってデルタ・ディレクトリを送信し、これまでの説明の中で述べたとおりに変更を示す。一般的にいえば、更新後の主ディレクトリが放送局によって送信される時点またはその近傍において、対応するデルタ・ディレクトリの送信が終了する。さらにメカニズム２００を、受信デバイスに対してプッシュおよびプルされるデータの両方を伝達するように構成できる。プルされるデータの要求は、バック・チャンネル２６、インターネット６０、またはそれ以外を介して受信することができる。種々の実施形態においては、放送局１６によるデータの処理と送信を、ハードウエア・コンポーネント、ソフトウエア・コンポーネント、またはハードウエアとソフトウエアの任意の適切な組み合わせにおいて実行することができる。たとえば、一実施形態においては処理メカニズム２００が、ここで述べている実施形態の１ないしは複数の実行のために設計されたプログラム・インストラクションを実行するように構成された汎用プロセッサを含むことができる。
【００７０】
前述したとおり、デルタ・ディレクトリの使用は、受信デバイス内における処理オーバーヘッドの縮小に役立てることができる。しかしながら、デルタ・ディレクトリは、放送側における更新の作成のタスクを単純化できることにも注意する必要がある。たとえば放送者（あるいはそのほかの「送信者」）が、ディレクトリに対する変更が必要とされていることを検出したとき、通常の方法ではその放送者に、送信のための完全に新しい主ディレクトリの生成が必要になることがある。各主ディレクトリが比較的大きくなることから、また容易に入手できない１ないしは複数の鍵を用いて「署名」されることがあるため、リアルタイム（または準リアルタイム）でのディレクトリ・コンテンツの更新が、実質的に不可能になることがある。これに対して、デルタ・ディレクトリの生成と伝達は、概して、新しい主ディレクトリの生成と伝達に要するよりはるかに少ない時間で達成することができる。
【００７１】
上記の説明においては、インタラクティブ・コンテンツのソースが放送局１６にあるとして説明されているが、代替実施形態のデータベース２３０とコンテンツ処理メカニズム２００は、ネットワーク通信オペレータ１７のロケーションに常駐することができる。その種の代替実施形態の一例を、送信に先行して放送信号にインタラクティブ・コンテンツを挿入するケーブル局とすることができる。多くのその種の代替が可能であり、かつ企図されている。
【００７２】
ここで図１３を参照すると、受信デバイス１０１２の一実施形態が示されている。図１３は、セット‐トップ・ボックス１０１２の形式でクライアント１０１２を例示しているが、デバイス１０１２は、同様にほかのデバイスを構成することもできる。一般的にいえば、クライアント１０１２は、放送信号等の第１の信号１０７０を受信し、ディスプレイまたは記録デバイス等へ第２の信号１０８０を伝達するように構成されている。クライアント１０１２は、外部大容量ストレージ・デバイス１０１８に結合されることが示されているが、その種のストレージをクライアント１０１２自体に内蔵してもよい。クライアント１０１２は、コントロール・ユニット１０３０、フロント・エンド１０２６、戻りチャンネル１０３８、トランスポート段１０２８、ＡＶ段１０３４を含む。また図１３には、ＯＳおよび／またはミドルウェア１０４４、モジュール・マネージャ１０３６、アプリケーション１０４２（１ないしは複数）を含むメモリ１０９０が表されている。さらにＩ／Ｏインターフェース１０４０、１０４１と、条件付きアクセス（ＣＡ）モジュール１０３２（１ないしは複数）も示されている。Ｉ／Ｏインターフェース１０４０は、リモート・コントロール、キーボード、あるいはそのほかのデバイスを介したユーザ・インタラクションを検出するように構成できる。Ｉ／Ｏインターフェース１０４１は、イーサネット（登録商標）（Ｅｔｈｅｒｎｅｔ）等の回路、またはそのほかの、インターネット、ホーム・ネットワーク、あるいはそのほかに対する双方向通信を提供するように構成されたネットワーク・インターフェースを含むことができる。コントロール・ユニット１０３０は、マイクロプロセッサ、メモリ（たとえばＲＡＭ）、そのほかの一般的な汎用コンピューティングの実行に必要となるコンポーネントを含むことができる。一実施形態においては、アプリケーション１０４２、ＯＳ／ミドルウェア１０４４、モジュール・マネージャ１０３６、ＣＡモジュール１０３２（１ないしは複数）が、セット‐トップ・ボックス１０１２のメモリ・デバイス内にストアできるコードを含む。それに加えてＣＡモジュール１０３２（１ないしは複数）は、セット‐トップ・ボックス１０１２によるアクセスが可能な特定の番組またはサービスへのアクセスをコントロールするように構成されたシステム・ソフトウエアを含むことができる。
【００７３】
一般的にいえば、クライアント１０１２は、ディジタル・データを含むことのできる信号を受信し、圧縮解除するべく動作できる。圧縮解除後の信号は、テレビジョン表示用にＰＡＬ、ＳＥＣＡＭ、またはＮＴＳＣフォーマット信号等のアナログ信号に変換されることもあり、あるいはディジタル表示用にディジタル・フォーマットで使用されることもある。図１３に示されているとおり、デバイス１０１２は、受信済みの信号１０７０からオーディオ、ビデオ、そのほかのデータを受け取るべく動作できるフロント・エンド回路１０２６を含む。受信済みの信号１０７０は、フロント・エンド１０２６においてクライアント１０１２に供給されるが、これは、アナログ・ディジタル（Ａ／Ｄ）コンバータと同調器／復調器（図示せず）を含むことができる。フロント・エンド１０２６は特定の周波数を選択して通過させ、それを復調し、アナログ信号からディジタル・フォーマットに変換する。アナログ・データがディジタル・データに変換されることがある一方、上で述べたとおり、受信済みの信号がディジタル・データを構成することもあり、その場合にはこの種の変換を必要としないと見られる。ディジタル出力は、続いてトランスポート段１０２８に伝達され、そこでさらにデータの処理が行われ、データの一部が表示のためにオーディオ‐ビジュアル（ＡＶ）段１０３４に伝達され、別の部分がコントロール・プロセッサ１０３０に伝達される。それに加えて、ＣＡモジュール１０３２がトランスポート段１０２８からデータを受け取ることがあり、デスクランブル後またはそのほかの信号をＡＶ段１０３４に条件付きで伝達することができる。シグナリングとコントロール情報もまた、オーディオ‐ビデオ・データとともに放送の中に含まれていることがあり、クライアント１０１２内のソフトウエアによって操作することができる。
【００７４】
モジュール・マネージャ１０３６は、図５または図１１に記述されているとおりに受信済みデータを処理するように構成される。ここではモジュール・マネージャ１０３６がメモリ１０９０内にストアされたソフトウエアとして図示されているが、モジュール・マネージャ１０３６に関連付けされるソフトウエアの一部または全部をＯＳ／ミドルウェア１０４４またはアプリケーション１０４２内に組み込めることを理解する必要がある。それに加えて、図５、図１１に記述されている機能は、モジュール・マネージャ１０３６によって実行できるが、ハードウエアにおいても同様に部分的に実行される機能を含んでもよい。当業者であれば認識することになろうが、その種の機能は、適切であると考えられるときにはハードウエアおよび／またはソフトウエアで実装することができる。
【００７５】
一般的にいえば、モジュール・マネージャ１０３６は、セット‐トップ・ボックスに結合される種々のモジュール・ソース（１０３８、１０４１、１０７０）を監視する。前述したとおり、これらのモジュール・ソースは、放送信号、ＨＴＴＰ信号、モデム通信またはそのほかの、セット‐トップ・ボックスに入力信号を供給するための手段を含むことができる（ここで用いている「モジュール・ソース」という表現は、広く、衛星またはモデム送信等の送信ソース、および処理後の信号、たとえば復元および圧縮解除後の信号を運ぶモジュール管理ユニットへの入力の両方を含むものと解釈される）。
【００７６】
スタート‐アップ時は、モジュール・マネージャ１０３６がアイドル状態でモジュール・ソースの１つにおいてパケットを待機する。放送局は、モジュール・ソースの１つでモジュール・マネージャ１０３６が待機しているモジュールを送信することができる。所定のモジュールを送信するチャンネルまたはモジュール・ソースの選択は、選択されるチャンネルの効率に依存させることができる。たとえば、加入者受信機の多くによって必要とされるモジュールは、放送チャンネルを介して送信することができるが、より需要が低いモジュールは、モデム回線を介して送信してもよい。モジュール管理ユニットがこれらすべてのモジュール・ソースを監視していることから、要求されたモジュールは、これらのソースのいずれを介しても受信されることになる。
【００７７】
一実施形態においては、受信デバイスが当初、ディレクトリ・モジュールを探すべく構成される。パケット・ヘッダが、そのパケットがディレクトリ・モジュールに対応することを示していれば、そのパケットを保持すればよく、ディレクトリ・モジュールの残りが獲得される。これに対して現在のところ受信デバイスがディレクトリ・モジュールを探しており、受信されたパケットがディレクトリ・モジュールに対応していない場合には、そのパケットを破棄することができる。モジュールが完全にロードされた後は、モジュール管理ユニットがそのモジュールの製造者証明書の認証を行う。モジュール管理ユニットは、その証明書が真正でなかった場合に単純にそのモジュールを破棄する、ユーザに警告する、あるいはセット‐トップ・ボックスをシャットダウンするといったいくつかのアクションのいずれかを採用するべくプログラムすることができる。その証明書が真正であれば、モジュールがチェックされ、システム内に実装されたセキュリティ・メカニズムに従ってその完全性の検証を行うことができる。そのモジュールが誤りを含んでいると決定されると、それが破棄される。そのモジュールに誤りがなければ、ほかのモジュールのダウンロードや、実行目的でのそのモジュールについての情報の提供に使用するために、システムがそれを利用できるようにする。受信されたモジュールがデルタ・ディレクトリ・モジュールであれば、対応するディレクトリ・モジュールを更新してそのデルタ・ディレクトリ・モジュールによって示される変更を反映させることができる。それに代えて、デルタ・ディレクトリ・モジュールを、上記の考察において述べたとおりにストアすることもできる。
【００７８】
スタート‐アップ後は、要求に応答して、あるいはディレクトリ・モジュール内にリストされた結果として、モジュール管理ユニットがモジュール（集合的に「必要な」モジュールという）をダウンロードすることができる。特定のモジュールの要求がモジュール管理ユニットによって維持されている未決要求のリスト内に置かれることがある。モジュール管理ユニットは、必要なモジュールに対応するパケットのためのモジュール・ソースを監視しながら待機する。パケットが検出されると、ディレクトリ・モジュールについて前述した形態でパケットの到来ストリームから分離される。モジュール管理ユニットは、１を超える数のモジュールのパケットを、それらが散在している場合には一度に検索することができる。モジュール用のすべてのパケットの受信が完了すると、そのモジュールが復元される。適切な誤りチェックとセキュリティ・メカニズムが実装されているときには、そのモジュールの誤りを試験し、その真正の検証を行うことができる。完全なモジュールが未決の要求に対応しているときには、そのモジュールがその要求を満たす（すなわち、その要求が相殺され、その要求を開始したアプリケーションまたはモジュールに対してそのモジュールを利用可能にする）。モジュール管理ユニットが、モジュール・ソースにおいて利用可能であった必要なモジュールのダウンロードを完了すると、次の必要なモジュールのための待機に復帰する。
【００７９】
クライアント１０１２によって受信されるオーディオ‐ビデオ信号とプログラム・コントロール信号は、テレビジョン番組、メタデータ、ユーザ・インターフェースを介した視聴者をはじめ、実行が考えられるアプリケーションによってアクセス可能なメニュー選択肢を含むことができる。視聴者は、赤外線リモート・コントロール・ユニット、クライアント上のコントロール・パネル、あるいはテレビジョン・スクリーン上に表示されるメニューからの選択に使用されるデバイスを介した方法を含む多様な方法でクライアント１０１２をコントロールすることができる。視聴者によって行われた選択とエントリは、クライアント上で実行中のいくつかのアプリケーションの１ないしは複数に対して意図されることがある。前述したとおり、放送信号１０７０は、フロント・エンド１０２６を介して受信され、トランスポート段１０２８によってフィルタリングされる。ユニキャストまたはマルチキャスト信号は、概して戻りチャンネル１０３８を介して受信される。クライアント１０１２上で実行するアプリケーション１０４２は、種々の方法でそこに到達できる。たとえば、放送信号１０７０経由、戻りチャンネルのリソース・インターフェース１０３８経由、あるいはストレージ・デバイス１０１８経由でアプリケーションを受信することができる。ストレージ・デバイス１０１８経由で受信されるアプリケーションは、最初からクライアント１０１２とともに出荷されることもあり、あるいは別のソースから前もってダウンロードされ、ストレージ１０１８上にストアされることもある。
【００８０】
一実施形態においては、クライアント１０１２を、ＭＰＥＧビデオ、オーディオ、データをデコードする能力を有する衛星受信機または衛星組み込みデコーダ／受信機を伴う使用のためのディジタル・セット‐トップ・ボックスとして構成することができる。たとえばクライアント１０１２を、直交振幅変調（ＱＡＭ）、直交位相シフト・キーイング（ＱＰＳＫ）、符号化直交周波数分割多重（ＣＯＦＤＭ）、または８値部分除去側波帯（ＶＳＢ）を使用する広帯域通信をサポートするディジタル・ビデオ・チャンネルを受信し、かつ２方向シグナリングと、メッセージングのためのチャンネルをコントロールするように構成することができる。これらのディジタル・チャンネルは、圧縮とエンコードが行われたマルチプログラムＭＰＥＧ（モーション・ピクチャ・エキスパート・グループ）トランスポート・ストリームを運ぶことができる。トランスポート段１０２８は、所望の番組をトランスポート・ストリームから抽出し、オーディオ、ビデオ、データ成分を分離し、それらが、ストリームを処理する、１ないしは複数のオーディオ・デコーダ、１ないしは複数のビデオ・デコーダ、オプションとしてＲＡＭ（またはそのほかの形式のメモリ）あるいはハードディスク等のデバイスにルーティングされる。ここで理解する必要があるが、クライアント１０１２とストレージ・デバイス１０１８（をはじめ、放送サービス・プロバイダからの任意のデータおよび信号）を、アナログ、ディジタル、またはアナログとディジタルの両方に適応するように構成することができる。受信したアナログ・データのストアのために、ディジタル・フォーマットへの変換を行うことができる。
【００８１】
ストレージ・デバイス１０１８は、オプションでクライアント１０１２に結合され、ビデオ、オーディオ、実行可能コード、メタデータ、そのほかのデータをストアするように構成できる。ストレージ・デバイス１０１８は、クライアント１０１２に内蔵してもよく、また恒久的な接続または取り外し可能な接続のいずれかを伴って外部的に（たとえば、ＩＥＥＥ１３９４‐１９９５接続を介して）接続してもよい。さらにストレージ・デバイス１０１８は、ハードディスク・ドライブ、記録可能ＤＶＤドライブ、磁気テープ、光ディスク、光磁気ディスク、フラッシュ・メモリ、あるいはソリッド・ステート・メモリといった任意の適切なタイプのストレージを含むことができる。それに加えて、１を超える数のデバイス１０１８等のストレージ・デバイスをクライアント１０１２に取り付けることができる。クライアント１０１２および／またはストレージ・デバイス１０１８は、さらに、テレビジョン・セット内に組み込まれることもある。ストレージ・デバイス１０１８内にストアされたプログラム・インストラクション等の実行可能データは、検索され、実行されることが許される。一実施形態においては、検索されたデータの実行またはそのほかの使用を、ほかの、たとえばクイズ番組、コマーシャル、またはインターネット・ベースのオンライン・ゲームに対応するアプリケーションまたは受信された信号と同期して行うことができる。それに代わり、ビデオ‐オン‐デマンド、バンキング、電子メール、ウェブ・ブラウザ、または電子番組ガイド（ＥＰＧ）等のように、検索したデータが独立して実行され、あるいは使用されることもある。
【００８２】
ここで理解する必要があるが、ここで述べたクライアント１０１２とシステム１００は、例示のみを意図している。放送ネットワーク・システム１００とクライアント１０１２は、本発明の範囲から逸脱することなしに、ここでの説明と異なるものとすることができる。さらに、図１３のクライアント１０１２内に図示されている種々のコンポーネントは、クライアント１０１２内にストレージ・デバイス１０１８の組み込みを配置するというように結合されることもある。種々の代替が可能であり、かつ企図されている。
【００８３】
すでに述べたとおり、上記の方法およびメカニズムの１ないしは複数のコンポーネントは、ハードウエアおよび／またはソフトウエアを含むことができる。コンポーネントがソフトウエアを含む実施形態においては、それらのコンポーネントを構成するプログラム・インストラクションをコンピュータによるアクセスが可能なメディア上で運ぶこと、またはそこにストアすることができる。プログラム・インストラクションをストアするように構成される多くのタイプのメディアがあり、ハードディスク、フロッピー（登録商標）ディスク、ＣＤ‐ＲＯＭ、ＤＶＤ、フラッシュ・メモリ、プログラマブルＲＯＭ（ＰＲＯＭ）、ランダム・アクセス・メモリ（ＲＡＭ）、そのほか各種の形式の揮発性または不揮発性ストレージが含まれる。コンピューティング・デバイスによるアクセスのためにプログラム・インストラクションを運ぶべく構成されるさらに別の形式のメディアとして、電気、電磁気、光、またはディジタル信号を運ぶことのできるネットワーク、ワイヤレス、および衛星リンク等の地上波と非地上波通信リンクもある。このように種々の実施形態は、コンピュータによるアクセスが可能なメディア上において以上の説明に従って実装されるインストラクションおよび／またはデータの受信、送信、またはストアをさらに含むことができる。
【００８４】
ここで理解する必要があるが、以上の実施形態は例示のみを意図している。たとえばここで述べた種々の特徴は、明示的に考察されている方法と異なる方法で結合されることがある。それに加えて、ここで考察した方法とメカニズムをインタラクティブ・テレビジョン・システム以外に適用することもできる。たとえば、別の分散処理、コンピューティング、電話、情報、およびネットワーク・システムが、ここで述べている方法とメカニズムを使用することもできる。すべてのその種のシステムは、包括的に分散コンピューティング・システムと呼ぶことができる。多数の代替構成が可能であり、かつ企図されている。
【図面の簡単な説明】
【００８５】
【図１】インタラクティブ・テレビジョン・システムの一実施形態を例示したブロック図である。
【図２】カルーセルおよびモジュールの一実施形態を図示した説明図である。
【図３】送信ストリームの一実施形態を例示した説明図である。
【図４】送信ストリームの一実施形態を例示した説明図である。
【図５】データを管理するための方法の一実施形態を例示したフローチャートである。
【図６】送信データの一実施形態を例示した説明図である。
【図７】ディレクトリ・モジュールの一実施形態を示した説明図である。
【図８】デルタ・ディレクトリ・モジュールの一実施形態を示した説明図である。
【図９】メモリ内にストアされたアプリケーションおよびディレクトリを図示した説明図である。
【図１０】メモリ内にストアされたアプリケーションおよびディレクトリを図示した説明図である。
【図１１】データを管理するための方法の一実施形態を例示したフローチャートである。
【図１２】ヘッドエンドの一実施形態を例示したブロック図である。
【図１３】受信デバイスの一実施形態を例示したブロック図である。
【符号の説明】
【００８６】
１３  リモート・ソース；リモート・ロケーション；ソース、１４  ソース、１５  ソース、１６  放送局、１７  送信メディア；送信ネットワーク；放送ネットワーク；ネットワーク通信オペレータ、１８  ソース、１９  ソース、２０  ネットワーク、２１  プロキシ・サーバ；プロキシ、２２  送信機、２３  衛星ベースのシステム、２４  ケーブル・ベースのシステム、２５  ＭＭＤＳベースのシステム、２６  バック・チャンネル
【図１】
2008500606.tif 000003
【図２】
2008500606.tif 000004
【図３】
2008500606.tif 000005
【図４】
2008500606.tif 000006
【図５】
2008500606.tif 000007
【図６】
2008500606.tif 000008
【図７】
2008500606.tif 000009
【図８】
2008500606.tif 000010
【図９】
2008500606.tif 000011
【図１０】
2008500606.tif 000012
【図１１】
2008500606.tif 000013
【図１２】
2008500606.tif 000014
【図１３】
2008500606.tif 000015