(57)【特許請求の範囲】
【請求項１】
ディジタルトランスポートストリームにおいて複数のサービス内のアプリケーションデータを伝送する方法であって、前記複数のサービスの中の各サービスが少なくとも一つのアプリケーションを保持し、当該方法は、
前記トランスポートストリーム内に、前記複数のサービスが保持する前記複数のアプリケーションに関する情報を有するアプリケーションデータテーブルを提供するステップ；
前記アプリケーションデータテーブルをメモリに保存するステップ；および
前記アプリケーションデータテーブル内に含まれる情報に依存して前記アプリケーションのダウンロードまたは維持を制御するステップ、を含み、
前記アプリケーションの少なくとも一つが維持されなくなった場合であっても、前記アプリケーションデータテーブルを前記メモリに維持することを特徴とするアプリケーションデータの伝送方法。
【請求項２】
前記アプリケーションデータテーブルは、トランスポートパケット内に於けるアプリケーションデータテーブルの存在の有無に関連する予め決められたパケットＩＤを有する、前記トランスポートパケットとしてトランスポートされることを特徴とする請求項１に記載の方法。
【請求項３】
前記アプリケーションデータテーブルは、デコーダがアプリケーションデータテーブルを既知の運用業者から発せられたものとして検証することを可能にするように電子的に署名されることを特徴とする請求項１または２に記載の方法。
【請求項４】
各々のサービスは更に、そのサービスが保持するアプリケーションへのアクセスを与えるプログラムマップテーブルを含んでおり、また前記プログラムマップテーブル自身は、そのサービスが保持する前記少なくとも一つのアプリケーションに関する情報を含んでいることを特徴とする請求項１乃至３のいずれかに記載の方法。
【請求項５】
前記アプリケーションデータテーブルは更に、各サービスを介してどのアプリケーションがアクセス可能であるかに関する情報を含んでいることを特徴とする請求項１乃至４のいずれかに記載の方法。
【請求項６】
前記アプリケーションデータテーブル内に保持されたアプリケーション情報は更に、アプリケーションの実行に必要なメモリのサイズに関する情報を含んでいることを特徴とする請求項１乃至５のいずれかに記載の方法。
【請求項７】
前記アプリケーションデータテーブル内のアプリケーション情報は、アプリケーションの相対的優先順位を示す優先値を含むことを特徴とする請求項１乃至６のいずれかに記載の方法。
【請求項８】
前記アプリケーションデータテーブル内のアプリケーション情報は、あるアプリケーションが少なくとも一つのサービスに限定されていることを示すサービス限定値を含むことを特徴とする請求項１乃至７のいずれかに記載の方法。
【請求項９】
前記アプリケーションデータテーブル内のアプリケーション情報は、サービスの変更時にアプリケーションに関して取られるべき措置に関するフラグ値を含むことを特徴とする請求項１乃至８のいずれかに記載の方法。
【請求項１０】
前記方法は、複数の前記アプリケーションデータテーブルを備えるステップを含んでおり、且つ各々のアプリケーションデータテーブルは、一組（１ブーケ）のサービス内に含まれるアプリケーションに関する情報を含むものであることを特徴とする請求項１乃至９のいずれかに記載の方法。
【請求項１１】
各々のアプリケーションデータテーブルは、トランスポートパケット内のテーブルまたはセクションのいずれかにトランスポートされ、各アプリケーションデータテーブルは、特性テーブルＩＤ及び特性テーブルＩＤ拡張値のいずれかを有するテーブルまたはセクションのいずれかに関連していることを特徴とする請求項１０に記載の方法。
【請求項１２】
ディジタルテレビジョンシステムに適用されることを特徴とする請求項１乃至１１のいずれかに記載の方法。
【請求項１３】
前記ディジタルトランスポートストリームは、ＭＰＥＧ規格に従っていることを特徴とする請求項１乃至１２のいずれかに記載の方法。
【請求項１４】
伝送装置であって、トランスポートストリームにおいて複数のサービスが保持する複数のアプリケーションに関する情報を有するアプリケーションデータテーブルおよび複数の前記サービスを含むトランスポートストリームを伝送する手段；
前記アプリケーションデータテーブルをメモリに保存する手段；および
前記アプリケーションデータテーブル内に含まれる情報に依存して前記アプリケーションのダウンロードまたは維持を制御する手段、を含み
前記アプリケーションの少なくとも一つが維持されなくなった場合であっても、前記アプリケーションデータテーブルを前記メモリに維持することを特徴とする伝送装置。
【請求項１５】
前記伝送手段は、トランスポートパケット内のアプリケーションデータテーブルの有無に関する予め決められたパケットＩＤ値を有するトランスポートパケットとしてアプリケーションデータテーブルを伝送することに適応していることを特徴とする請求項１４に記載の伝送装置。
【請求項１６】
デコーダがアプリケーションデータテーブルを既知の運用業者から発したものとして検証することを可能にするように前記アプリケーションデータテーブルに電子的に署名する手段を含むことを特徴とする請求項１４または１５に記載の伝送装置。
【請求項１７】
前記伝送手段は、各サービスが保持するアプリケーションへのアクセスを与えるプログラムマップテーブルを各サービスごとに伝送することに適応しており、また前記プログラムマップテーブル自身は、そのサービスが保持する前記少なくとも一つのアプリケーションに関する情報を含んでいることを特徴とする請求項１４乃至１６のいずれかに記載の伝送装置。
【請求項１８】
前記アプリケーションデータテーブルは更に、各サービスを介してどのアプリケーションがアクセス可能であるかに関する情報を含んでいることを特徴とする請求項１４乃至１７のいずれかに記載の伝送装置。
【請求項１９】
前記アプリケーションデータテーブル内に保持されたアプリケーション情報は更に、アプリケーションの実行に必要なメモリのサイズに関する情報を含んでいることを特徴とする請求項１４乃至１８のいずれかに記載の伝送装置。
【請求項２０】
前記アプリケーションデータテーブル内のアプリケーション情報は、アプリケーションの相対的優先順位を示す優先値を含むことを特徴とする請求項１４乃至１９のいずれかに記載の伝送装置。
【請求項２１】
前記アプリケーションデータテーブル内のアプリケーション情報は、あるアプリケーションが少なくとも一つのサービスに限定されていることを示すサービス限定値を含むことを特徴とする請求項１４乃至２０のいずれかに記載の伝送装置。
【請求項２２】
前記アプリケーションデータテーブル内のアプリケーション情報は、サービスの変更時にアプリケーションと共に取られるべき措置に関するフラグ値を含むことを特徴とする請求項１４乃至２１のいずれかに記載の伝送装置。
【請求項２３】
前記伝送手段は、各々のアプリケーションデータテーブルが一組（１ブーケ）のサービスに含まれるアプリケーションに関する情報を含んでいる複数の前記アプリケーションデータテーブルを伝送することに適応していることを特徴とする請求項１４乃至２２のいずれかに記載の伝送装置。
【請求項２４】
前記伝送手段は、トランスポートパケット内のテーブルまたはセクションのいずれかで各アプリケーションデータテーブルを伝送することに適応しており、各アプリケーションデータテーブルは特性テーブルＩＤまたは特性テーブルＩＤ拡張値のいずれかを有するテーブルまたはセクションのいずれかに関連していることを特徴とする請求項２３に記載の伝送装置。
【請求項２５】
前記ディジタルトランスポートストリームは、ＭＰＥＧ規格に従っていることを特徴とする請求項１４乃至２４のいずれかに記載の伝送装置。
【請求項２６】
請求項１４乃至２５のいずれかに記載の伝送装置を含むことを特徴とするディジタルテレビジョンシステム。
【請求項２７】
デコーダであって、前記デコーダは、トランスポートストリームにおいて複数のサービスが保持する複数のアプリケーションに関する情報を有するアプリケーションデータテーブルを記憶するためのメモリと、前記アプリケーションデータテーブル内に含まれる情報に依存してこのようなアプリケーションのダウンロードまたは維持を制御する手段とを含み、前記アプリケーションの少なくとも一つが維持されなくなった場合であっても、前記アプリケーションデータテーブルを前記メモリに維持することを特徴とする前記デコーダ。
【請求項２８】
前記デコーダでは、前記アプリケーションデータテーブルは電子的に署名される様に構成されており、それによって前記デコーダが、前記アプリケーションデータが既知の運用業者から発せられたものとして検証することを可能にすることを特徴とする請求項２７に記載のデコーダ。
【請求項２９】
前記アプリケーションデータテーブルは更に、各サービスを介してどのアプリケーションがアクセス可能であるかに関する情報を含んでいることを特徴とする請求項２７又は２８に記載のデコーダ。
【請求項３０】
前記アプリケーションデータテーブル内に保持されたアプリケーション情報は更に、アプリケーションの実行に必要なメモリのサイズに関する情報を含んでいることを特徴とする請求項２７乃至２９のいずれかに記載のデコーダ。
【請求項３１】
前記アプリケーションデータテーブル内のアプリケーション情報は、アプリケーションの相対的優先順位を示す優先値を含むことを特徴とする請求項２７乃至３０のいずれかに記載のデコーダ。
【請求項３２】
前記アプリケーションデータテーブル内のアプリケーション情報は、あるアプリケーションが少なくとも一つのサービスに限定されていることを示すサービス限定値を含むことを特徴とする請求項２７乃至３１のいずれかに記載のデコーダ。
【請求項３３】
前記アプリケーションデータテーブル内のアプリケーション情報は、サービスの変更時に、アプリケーションと共に取られるべき措置に関するフラグ値を含むことを特徴とする請求項２７乃至３２のいずれかに記載のデコーダ。
【請求項３４】
ディジタルトランスポートストリームにおいて複数のサービス内のアプリケーションデータを受信する方法であって、前記複数のサービスの中の各サービスが少なくとも一つのアプリケーションを保持し、当該方法は、
前記トランスポートストリーム内に、前記複数のサービスが保持する前記複数のアプリケーションに関する情報を有するアプリケーションデータテーブルを受信するステップ；
前記アプリケーションデータテーブルをメモリに保存するステップ；および
前記アプリケーションデータテーブル内に含まれる情報に依存して前記アプリケーションのダウンロードまたは維持を制御するステップ、を含み、
前記アプリケーションの少なくとも一つが維持されなくなった場合であっても、前記アプリケーションデータテーブルを前記メモリに維持することを特徴とするアプリケーションデータの受信方法。
【請求項３５】
受信装置であって、トランスポートストリームにおいて複数のサービスが保持する複数のアプリケーションに関する情報を有するアプリケーションデータテーブルおよび複数の前記サービスを含むトランスポートストリームを受信する手段；
前記アプリケーションデータテーブルをメモリに保存する手段；および
前記アプリケーションデータテーブル内に含まれる情報に依存して前記アプリケーションのダウンロードまたは維持を制御する手段、を含み
前記アプリケーションの少なくとも一つが維持されなくなった場合であっても、前記アプリケーションデータテーブルを前記メモリに維持することを特徴とする受信装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ディジタル伝送システム、特にディジタルテレビジョンシステムに関する。
【０００２】
【従来の技術】
既存のディジタルテレビジョンシステムは、各々のパケットが予め決められた長さであってヘッダとペイロードとを含んでいる個別トランスポートストリームパケットあるいはトランスポートパケットの形でデータを伝送する。ＭＰＥＧ−２規格は、この分野で現在好まれている規格であって、このようなパケットに関して予め決められたフォーマットを規定している。
このパケットヘッダは、パケットに関する一般的な記述データを含むが、ペイロードは、レシーバ側で処理すべきデータを含んでいる。パケットヘッダは、少なくともパケットを識別するパケットＩＤあるいはＰＩＤを含んでいる。パケットのペイロードは、条件付きアクセスシステムデータ、または特に対話型その他のアプリケーションをセットアップするためにデコーダが使用するアプリケーションデータといったオーディオ、ビデオ、その他のデータを含むことができる。ＰＩＤパケット内のデータは更に、テーブルＩＤあるいはＴＩＤによって、更に正確にはＴＩＤ拡張値によって識別される多数のテーブルまたはセクションに分割されることもある。
【０００３】
従来のトランスポートストリーム内のデータは、以下のように構成されている。最も高いレベルでは、プログラムアクセステーブルまたはＰＭＴテーブルは、各ＰＭＴテーブルがトランスポートストリーム内のサービスに関連する一つ以上のプログラムマップテーブルまたはＰＭＴテーブルのＰＩＤ値をリストアップしている。ここでＰＭＴテーブルとは、そのサービスに関するオーディオデータ、ビデオデータ、アプリケーションデータ等を含むパケットのＰＩＤ値を指している。理解されるように、サービスは漠然とテレビジョンチャンネルに対応すると考えられるかも知れないが、サービスは多数のオーディオおよび／またはビジュアルのデータストリーム、単なるアプリケーションデータ等を含む可能性があるので、サービスの概念は更にいくらか広くなっている。
【０００４】
従来、各サービスは、多少とも独立して動作し、そのサービスが必要とするすべてのアプリケーションを持っている。これは、そのサービスで放送される番組（例えばそのチャンネルで見られる試合に関連したサッカーアプリケーション）に特にリンクされたアプリケーション、ならびに起動アプリケーションといった、より一般的なアプリケーションを含むことができる。前者のタイプのアプリケーションは、ただ一つのまたは少数のサービスを介してアクセス可能であるが、後者はすべてのサービスに含まれている。
アプリケーションのバージョン番号、アプリケーションに必要なメモリ空間等を含む、あるサービスが保持するアプリケーションに関する情報は通常、そのサービスの入口点のＰＭＴテーブルに含まれている。
【０００５】
この従来のデータ構成では、サービス間の変更時に特定の問題が発生する。前述のように各サービスは、そのサービスが必要とするすべてのアプリケーションを、これらのアプリケーションに関する情報のテーブルと一緒に持っている。サービスの選択に際して従来のように構成されたデコーダは、現在実行中のアプリケーションに関する如何なる決定をするよりも前にＰＭＴテーブルをダウンロードしてこのテーブルの内容を評価しなくてはならない。ＰＭＴテーブルのダウンロードと分析とに通常必要とされる時間を考えると、これは面倒な操作であることが分かる。更にデコーダの動作の柔軟性は、アプリケーションの優先度などの評価に関してかなり限定される。
【０００６】
【発明の開示】
本発明の目的は、その最も広い、および／または特定の実施形態において、この問題に対する解を提供することである。
本発明によれば、複数のサービスの中の各サービスが少なくとも一つのアプリケーションを保持する、ディジタルトランスポートストリーム内の複数のサービス内のアプリケーションデータの伝送方法であって、前記トランスポートストリーム内の複数のサービスの中の各サービスが保持する前記少なくとも一つのアプリケーションに関する情報を有するアプリケーションデータテーブルを備えるステップを含むことを特徴とする前記方法が提供される。
言い換えれば、本発明は、ディジタルトランスポートストリーム内の複数のサービス内のアプリケーションデータの伝送方法であって、前記トランスポートストリーム内の複数のサービスの中の各サービスが保持する一つまたは複数のアプリケーションに関する情報を有するアプリケーションデータテーブルを備えることを特徴とする前記方法を提供する。
【０００７】
複数のサービスに亘るアプリケーションデータに関する情報を有する単一のテーブル、アプリケーションデータテーブルあるいは「ＡＤＴ」の使用は、デコーダが多数の異なる因子にしたがうこのようなアプリケーションに関してその動作を定義することを可能にする。
例えば一つのサービスが一意に保持するアプリケーションの場合、デコーダは、アプリケーションデータテーブル内に在るこのアプリケーションに関する情報に基づいて、このアプリケーションを含まないサービスに切り換えるときでも、このアプリケーションを維持すると決定できる。このような評価に使用できる情報の種類については、以下に更に詳細に説明する。
【０００８】
前記アプリケーションデータテーブルは、トランスポートパケット内のアプリケーションデータテーブルの有無に関連する予め決められたパケットＩＤあるいはＰＩＤを有する前記トランスポートパケットにトランスポートされることが有利である。
データを保持する一定値のＰＩＤテーブルの使用は、デコーダがいかなるサービスにアクセスするよりも前にこのテーブルを迅速に探し出してダウンロードするように予めプログラムされることを可能にする。理解されるように、それでもアプリケーションデータテーブルは、他の手段、例えばモデムリンク、スマートカード等を介して、デコーダに伝達または導入される。同様にＡＤＴテーブルは、当のサービスのＰＭＴテーブルといった他のテーブルにおけるＰＩＤ参照によってもアクセス可能である。
【０００９】
一般的に、一つの商業的運用業者は通常、複数のサービスチャンネルの内容に責任を持っており、これらのチャンネルは１ブーケのサービスとして一まとめにされる。所定のトランスポートストリームは、各々が異なる運用業者によって管理される多数ブーケのサービスを含んでいることが多い。各運用業者は、自分のブーケ内のサービスに備えられたアプリケーションについては十分に知らされているが、この情報は当然の理由から通常、他の運用業者には入手できない。
したがって本方法は更に、各々のアプリケーションデータテーブルが１ブーケのサービスに含まれるアプリケーションに関する情報を含んでいる複数の前記アプリケーションデータテーブルを備えることを含むことが好ましい。
代替の実施形態では、多数のブーケに亘るアプリケーションについての情報を備える「スーパー」ＡＤＴテーブルの作成が考えられる。しかしながら、運用業者間の情報伝達時の問題を考慮すると、この解は実施困難であるかも知れない。
【００１０】
多数のアプリケーションデータテーブルを使用する実施形態では、各々のアプリケーションデータテーブルは、好都合にもトランスポートパケット内のテーブルまたはセクションにトランスポートでき、また各アプリケーションデータテーブルは、特性テーブルＩＤ、または好ましくは特性テーブルＩＤ拡張値を有するテーブルまたはセクションに関連している。
多数のＡＤＴテーブルがトランスポートストリーム内に保持されている場合には、これは、ユーザが加入するブーケのサービスに関連するＡＤＴテーブルをデコーダが識別するための特に好都合な方法を提供する。ＴＩＤ拡張値は、例えば当のブーケに関連する加入カードによってデコーダに通知される情報に含まれることもある。代替としてデコーダは、デコーダが受信する種々のブーケのサービスに関連するＴＩＤ拡張値のテーブルを維持することができる。
【００１１】
好適な任意選択の実施形態では、この、あるいは各々のアプリケーションデータテーブルは、デコーダがアプリケーションデータテーブルを既知の運用業者から発したものとして検証することを可能にするように電子的に署名される。この仕方のデータの認証または署名は、電子署名を提供するいかなる既知の方法によってでも、例えばハッシュとパブリックキー／プライベートキーとの組合せアルゴリズムによっても実行可能である。
更に好適な実施形態では、各サービスは更に、このサービスが保持するアプリケーションへのアクセスを与えるプログラムマップテーブルあるいはＰＭＴテーブルを含んでおり、このプログラムマップテーブル自身は、このサービスが保持するその、または各々のアプリケーションに関する情報を含んでいる。
【００１２】
例えば、あるアプリケーション用のデータがサービスを介してアクセスされるデータカルーセル内に保持されている実施形態では、ＰＭＴは、そのアプリケーションのモジュールのカルーセルアドレスに関する情報を含んでいる。
特に好適な実施形態では、アプリケーションデータテーブルは更に、例えば各サービスを介して何時でもアクセスできるアプリケーションを有するサービスのリストの形で、各サービス内にどのアプリケーションが保持されているかに関する情報を含んでいる。このリストは、通常はダイナミックであって、サービスが現在参照しているアプリケーションにしたがって変化するであろう。
一実施形態では、アプリケーションデータテーブル内に保持されているアプリケーション情報は更に、アプリケーションの実行に必要なメモリのサイズに関する情報を含んでいる。
【００１３】
追加情報は、アプリケーションの相対的優先順位を示す優先値と、あるアプリケーションが一つ以上のサービスに限定されていることを示すサービス限定値と、サービスの変更時にアプリケーションが取るべき措置に関するフラグ値と、そのアプリケーションに関連するデータカルーセルＩＤ値その他とを含むことがある。ＡＤＴテーブルに保持され得るデータに関する更に詳細な情報については、読者は好適な実施形態の説明を参照できる。
理解されるように、このリストは、決して網羅的のものではなく、ここに列挙された因子と同様に、あるいはそれらの代わりに、多数の他の因子を使うこともできる。
ディジタル伝送システムは、特にＭＰＥＧ規格にしたがって機能することに適応したディジタルテレビジョンシステムからなることが好ましい。
【００１４】
本発明は、ディジタルデータの伝送方法に関してこれまで説明してきた。本発明は更に、上述のような方法に使用するための伝送装置であって、トランスポートストリーム内の複数のサービスが保持するアプリケーションに関する情報を有するアプリケーションデータテーブルと共に前記複数のサービスを含むトランスポートストリームを伝送するための、送信器といった手段を含む前記装置に拡張される。
この伝送手段は、パケット内のアプリケーションデータテーブルの有無に関する予め決められたパケットＩＤ値を有するトランスポートパケットでアプリケーションデータテーブルを伝送することに適応している。
【００１５】
この装置は、デコーダがアプリケーションデータテーブルを既知の運用業者から発したものとして検証することを可能にするように前記アプリケーションデータテーブルに電子的に署名するための、暗号化ユニットといった手段を含むこともできる。
前記伝送手段は、各サービスが保持するアプリケーションへのアクセスを与えるプログラムマップテーブルを各サービスごとに伝送することに適応しており、また前記プログラムマップテーブル自身は、そのサービスが保持する前記少なくとも一つのアプリケーションに関する情報を含んでいる。
【００１６】
本発明は更に、前述のような方法に使用されるデコーダであって、トランスポートストリーム内の複数のサービスが保有するアプリケーションに関する情報を含むアプリケーションデータテーブルを記憶するためのメモリと、このアプリケーションデータテーブル内に収められた情報にしたがってこのようなアプリケーションのダウンロードと維持のうちの少なくとも一つを制御するための、コントローラといった手段とを含んでいることを特徴とする前記デコーダに拡張される。
【００１７】
本発明はまた、トランスポートストリーム内の複数のサービスが保持するアプリケーションに関する情報を含むアプリケーションデータテーブルを記憶するためのメモリと、このアプリケーションデータテーブル内に収められた情報にしたがってこのようなアプリケーションのダウンロードと維持のうちの少なくとも一つを制御するための手段とを含むデコーダに拡張される。こうしてアプリケーションデータテーブルは、送信器によってデコーダにトランスポートストリームの形で放送されずに、デコーダのメモリ内に常駐することができる。
本発明はまた、トランスポートストリーム内の複数のサービスの中の各サービスが保持する少なくとも一つのアプリケーションに関する情報を含むアプリケーションデータテーブルを提供する。
本発明の方法態様に関する前述の特徴は、装置態様にも適用可能であり、その逆も可能である。
【００１８】
ここで使用されるような、「ディジタル伝送システム」という用語は、主として例えばオーディオビジュアルまたはマルチメディアのディジタルデータを伝送または放送するためのいかなる伝送システムをも含んでいる。本発明は特に、放送ディジタルテレビジョンシステムに適用可能であるが、本発明はまた、マルチメディアインターネットアプリケーション用に固定された通信ネットワークや閉回路テレビジョンシステム等にも適用可能である。
ここで使用されるような、「ディジタルテレビジョンシステム」という用語は、例えば衛星、地上、ケーブルその他いかなるシステムをも含んでいる。
【００１９】
ここで使用される「レシーバ／デコーダ」あるいは「デコーダ」とう用語は、他の手段によって放送または伝送され得る符号化または非符号化信号、例えばテレビジョンおよび／またはラジオ信号のいずれかを受信するためのレシーバを意味している。この用語はまた、受信した信号を復号するデコーダも含んでいる。このようなレシーバ／デコーダの実施形態は、例えば受信信号を「セットトップボックス」内で復号するための、レシーバと統合されたデコーダ、物理的に分離したレシーバと組み合わせて機能するデコーダ、ウェブブラウザといった追加機能を含むデコーダ、ビデオレコーダやテレビジョンといった他の装置と統合されたデコーダ等を含んでいる。
レシーバ／デコーダの種々の機能は、ハードウエア、例えば専用の集積回路に実現でき、これは動作速度を改善できる。しかしながらこれらの機能の少なくとも一部はソフトウエアで実現されることが好ましく、これらのアプリケーションを実行する処理手段によって実行されることが好ましく、このことは、更に大きな柔軟性をもたらし、部品点数を少なくし、レシーバ／デコーダの更新を更に容易にすることができる。
【００２０】
ＭＰＥＧという用語は、国際標準化機構（ＩＳＯ）のワーキンググループ「Ｍｏｔｉｏｎ  Ｐｉｃｔｕｒｅｓ  Ｅｘｐｅｒｔ  Ｇｒｏｕｐ（動画専門家グループ）」によって開発されたデータ伝送規格を指しているが、特に排他的にではなくディジタルテレビジョン用に開発されたＭＰＥＧ−２規格を指しており、文書ＩＳＯ１３８１８−１とＩＳＯ１３８１８−２とＩＳＯ１３８１８−３とＩＳＯ１３８１８−４とに記述されている。本特許出願に関しては、この用語は、ディジタルデータ伝送の分野に適用可能なＭＰＥＧフォーマットのすべての変形、修正あるいは発展形を含んでいる。
【００２１】
【発明の実施の形態】
さて本発明の好適な実施形態は、単に例として、下記の図面を参照しながら説明されるであろう。
図１は、ディジタルテレビジョン放送受信システム１の概要を示す。本発明は、ＭＰＥＧ−２圧縮システムを使って圧縮されたディジタル信号を伝送する大部分は従来のディジタルテレビジョンシステム２を含んでいる。更に詳細には、放送センターのＭＰＥＧ−２圧縮器３は、ディジタル信号ストリーム（例えばオーディオまたはビデオ信号のストリーム）を受信する。圧縮器３は、リンケージ５によってマルチプレクサスクランブラ４に接続されている。マルチプレクサ４は、複数の更なる入力信号を受信し、一つ以上のトランスポートストリームを組み立て、圧縮された信号をリンケージ７を介して放送センターの送信器６に伝送する。このリンケージ７は遠距離通信リンクを含む幅広い種々の形式を取り得ることは無論である。
【００２２】
送信器６は、衛星トランスポンダ９に向かうアップリンク８を介して電磁信号を送信する。この場合これらの信号は、電子的に処理されて、エンドユーザが所有またはレンタルしている通常皿型の地上レシーバ１１に概念的なダウンリンク１０を介して放送される。レシーバ１１によって受信された信号は、エンドユーザが所有またはレンタルしている統合化レシーバ／デコーダ１２に伝送され、エンドユーザのテレビジョン受像機１３に接続される。このレシーバ／デコーダ１２は、圧縮されたＭＰＥＧ−２信号をテレビジョン受像機１３用のテレビジョン信号に復号する。
【００２３】
条件付きアクセスシステム２０は、マルチプレクサ４とレシーバ／デコーダ１２とに接続されており、一部は放送センターに、一部はデコーダに配置されている。これは、エンドユーザが一つ以上の放送提供業者からのディジタルテレビジョン放送にアクセスすることを可能にする。商業的提供物（すなわち放送提供業者が販売する一つまたは数種のテレビジョン番組）に関するメッセージを解読できるスマートカードは、レシーバ／デコーダ１２に挿入できる。デコーダ１２とスマートカードを使ってエンドユーザは、加入方式またはペイパービュー（番組有料視聴）方式のいずれかでイベントを購入することができる。
マルチプレクサ４とレシーバ／デコーダ１２とにも接続されていて、再び一部は放送センターに、一部はデコーダに配置されている対話型システム１７が備えられていて、エンドユーザは、モデム通信チャネル１６を介して種々のアプリケーションと対話するができる。
【００２４】
今度は、条件付きアクセスシステム２０について更に詳細に説明する。
図２を参照すれば概略的に、条件付きアクセスシステム２０は、加入者認証システム（Ｓｕｂｓｃｒｉｂｅｒ  Ａｕｔｈｏｒｉｚａｔｉｏｎ  Ｓｙｓｔｅｍ：ＳＡＳ）２１を含んでいる。ＳＡＳ２１は、各放送提供業者ごとに一つの加入者管理システム（Ｓｕｂｓｃｒｉｂｅｒ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ：ＳＭＳ）２２として一つ以上のＳＭＳにそれぞれのＴＣＰ−ＩＰリンケージ２３（代替として他のタイプのリンケージを使用することもできるが）によって接続されている。代替として一つのＳＭＳは、二つの放送提供業者間で共用することもでき、あるいは一つの提供業者が二つのＳＭＳを使用できるなどがある。
【００２５】
「マザー」スマートカード２５を利用する暗号化ユニット２４の形をした第１の暗号化ユニットは、リンケージ２６によってＳＡＳに接続されている。再びマザースマートカード２８を利用する暗号化ユニット２７の形をした第２の暗号化ユニットは、リンケージ２９によってマルチプレクサ４に接続されている。レシーバ／デコーダ１２は、「ドーター」スマートカード３０を収容している。これは、モデム通信チャネル１６を介して通信サーバ３１によって直接ＳＡＳ２１に接続される。ＳＡＳは、請求に応じて特に加入権をドータースマートカードに送る。
スマートカードは、一つ以上の商業的運用業者の機密事項を含んでいる。「マザー」スマートカードは、異なる種類のメッセージを暗号化し、「ドーター」スマートカードは、解読する権利を持っていれば、これらのメッセージを解読する。
【００２６】
第１、第２の暗号化ユニット２４、２７は、ラックと、ＥＥＰＲＯＭに記憶されたソフトウエアを有する電子ＶＭＥカードと、最大２０枚までの電子カードと、各電子カードごとにそれぞれ１枚がＥＣＭ暗号化用のカード２８で１枚がＥＭＭ暗号化用のカード２５の、スマートカード２５、２８とを含んでいる。
さてディジタルテレビジョンシステム２と条件付きアクセスシステム２０との種々のコンポーネントを参照しながら、ディジタルテレビジョンシステムの条件付きアクセスシステム２０の動作について更に詳細に説明する。
【００２７】
マルチプレクサスクランブラ
図１、２を参照すれば、放送センターにおいて、ディジタルオーディオまたはビデオ信号は先ず、ＭＰＥＧ−２圧縮器３を使って圧縮（またはビットレート削減）される。この圧縮された信号はその後、他の圧縮されたデータなどといった他のデータと多重化するためにリンケージ５を介してマルチプレクサスクランブラ４に伝送される。
スクランブラは、スクランブリング処理で使われ、マルチプレクサ内のＭＰＥＧ−２ストリームに含まれる制御語を発生させる。この制御語は、内部的に生成されて、エンドユーザの統合化レシーバ／デコーダ１２が番組（プログラム）をデスクランブルすることを可能にする。
番組がどのように商品化されているかを示すアクセス基準もまた、ＭＰＥＧ−２ストリームに加えられる。その番組は、多数の「加入」方式の一つおよび／または多数の「ペイパービュー（番組有料視聴制）」（ＰＰＶ）方式の一つのいずれかで、またはイベントの形で商品化することができる。加入方式では、エンドユーザは、一つ以上の商業的提供物あるいは「ブーケ」に加入し、それによってそれらのブーケ内のすべてのチャンネルを見る権利を取得する。好適な実施形態では１ブーケのチャンネルから最大９６０までの商業的提供物を選択することができる。
ペイパービュー方式では、エンドユーザは、所望のイベントを購入する権利を与えられる。これは、前もってそのイベントを予約する（「予約方式」）か、放送されると直ぐにそのイベントを購入する（「衝動方式」）のいずれかによって達成できる。好適な実施形態では、すべてのユーザは、加入方式またはＰＰＶ方式で見るかどうかにかかわらず加入者であるが、ＰＰＶ視聴者は、必ずしも加入者でないことは無論である。
【００２８】
資格制御メッセージ（ＥＣＭ）
資格制御メッセージ（Ｅｎｔｉｔｌｅｍｅｎｔ  Ｃｏｎｔｒｏｌ  Ｍｅｓｓａｇｅ：ＥＣＭ）を構築するためには、制御語とアクセス基準の両者が使われる。これは、スクランブルされた番組に関して送られるメッセージであり、このメッセージは、制御語（その番組をデスクランブルすることを認める）と、その放送番組のアクセス基準とを含んでいる。アクセス基準と制御語は、リンケージ２９を介して第２の暗号化ユニット２７に伝送される。このユニットでは、ＥＣＭが生成され、暗号化されてマルチプレクサスクランブラ４に伝送される。放送の送信中、一般的に制御語は数秒ごとに変化し、したがって変化する制御語をデスクランブルできるようにＥＣＭも周期的に送信される。冗長性のために、一般に各ＥＣＭは、現在の制御語と次の制御語という二つの制御語を含んでいる。
【００２９】
データストリームの形の放送提供業者による各サービス放送は、多数の個別コンポーネントを含んでおり、例えばテレビジョン番組は、ビデオコンポーネント、オーディオコンポーネント、サブタイトルコンポーネント等を含んでいる。あるサービスのこれらのコンポーネントの各々は、トランスポンダ９へのその後の放送のために個々にスクランブルされて暗号化される。サービスのスクランブルされた各コンポーネントに関しては、別個のＥＣＭが必要である。代替としてあるサービスのスクランブルされたコンポーネントのすべてに関して単一のＥＣＭが必要とされることもある。多数の条件付きアクセスシステムが送信される同一番組へのアクセスを制御する場合には多数のＥＣＭが生成される。
【００３０】
番組送信
マルチプレクサ４は、ＳＡＳ２１からの暗号化されたＥＭＭと、第２の暗号化ユニット２７からの暗号化されたＥＣＭと、圧縮器３からの圧縮された番組とを含む電気信号を受信する。マルチプレクサ４は、番組をスクランブルして、これらのスクランブルされた番組と暗号化されたＥＭＭと暗号化されたＥＣＭとをリンケージ７を介して放送センターの送信器６に送る。送信器６は、アップリンク８を介して電磁信号を衛星トランスポンダ９に送信する。
【００３１】
番組受信
衛星トランスポンダ９は、送信器６が送信した電磁信号を受信して処理し、それらの信号をエンドユーザが所有またはレンタルしている通常皿型の地上レシーバ１１に、ダウンリンク１０を介して送信する。レシーバ１１が受信した信号は、エンドユーザが所有またはレンタルしている統合化レシーバ／デコーダ１２に伝送され、エンドユーザのテレビジョン受像機１３に接続される。レシーバ／デコーダ１２は、暗号化されたＥＭＭと暗号化されたＥＣＭとを有するスクランブルされた番組を得るためにこれらの信号を多重分離する。
もし番組がスクランブルされていなければ、すなわちＥＣＭがＭＰＥＧ−２で送信されていなければ、レシーバ／デコーダ１２は、これらのデータをデコンプレス（非圧縮化）し、信号をテレビジョン受像機１３に伝送するためのビデオ信号に変換する。
【００３２】
もし番組がスクランブルされていれば、レシーバ／デコーダ１２は、ＭＰＥＧ−２ストリームから対応するＥＣＭを抽出し、このＥＣＭをエンドユーザの「ドーター」スマートカード３０に渡す。これは、レシーバ／デコーダ１２のハウジングに挿入される。このドータースマートカードは、エンドユーザがこのＥＣＭを解読してその番組にアクセスする権利を持っているかどうかを管理する。もし持っていなければ、その番組がデスクランブル出来ないことを示すために、否定的状態がレシーバ／デコーダ１２に渡される。もしエンドユーザが権利を持っていれば，このＥＣＭは解読されて制御語が抽出される。それからデコーダ１２は、この制御語を使って番組をデスクランブルすることができる。ＭＰＥＧ−２ストリームは、デコンプレス（非圧縮化）されて、更にテレビジョン受像機１３に伝送するためのビデオ信号に変換される。
【００３３】
資格管理メッセージ（Ｅｎｔｉｔｌｅｍｅｎｔ  Ｍａｎａｇｅｍｅｎｔ  Ｍｅｓｓａｇｅ：ＥＭＭ）
ＥＭＭは、個々のエンドユーザ（加入者）専用またはエンドユーザの１グループ専用のメッセージである。各グループは、所定数のエンドユーザを含むことができる。１グループとしてのこの構成は、帯域幅を最適化することを目的としている。すなわち１グループへのアクセスは、多数のエンドユーザへの到達を可能にする。
ＥＭＭの種々の固有のタイプを使うことができる。個々のＥＭＭは、個々の加入者に専用にされ、一般にペイパービューサービス（番組有料視聴制サービス）の規定で使われ、これらは、グループ識別子とそのグループ内の加入者の位置とを含んでいる。
グループ加入ＥＭＭは、２５６程度の個別ユーザのグループに専用とされ、一般には幾つかの加入サービスの管理に使われる。このＥＭＭは、グループ識別子と加入者のグループビットマップとを持っている。
視聴者ＥＭＭは、全視聴者に与えられ、例えばある一定の無料サービスを提供する特定の運用業者によって使用される。「視聴者」は、同一の条件付きアクセスシステム識別子（ＣＡ  ＩＤ）を有するスマートカードを持つ加入者全体である。最後に、「一意の」ＥＭＭは、スマートカードの一意識別子に宛てられている。
【００３４】
加入者管理システム（Ｓｕｂｓｃｒｉｂｅｒ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ：ＳＭＳ）
加入者管理システム（ＳＭＳ）２２は、特にエンドユーザファイルのすべてと、商業的提供物と、加入事項と、ＰＰＶ詳細事項と、エンドユーザの使用量および資格とに関するデータとを管理するデータベース３２を含んでいる。ＳＭＳは、ＳＡＳとは物理的に離れている可能性がある。
各ＳＭＳ２２は、エンドユーザに送信すべき資格管理メッセージ（ＥＭＭ）の修正または作成を意味するメッセージをそれぞれのリンケージ２３経由でＳＡＳ２１に送信する。
ＳＭＳ２２はまた、ＥＭＭの修正や作成を意味しないで単にエンドユーザの状態（製品の注文時にエンドユーザに与えられる資格に関する、あるいはエンドユーザが課金される金額に関する）の変更を意味するメッセージをＳＡＳ２１に送信する。
ＳＡＳ２１は、メッセージ（一般には回収情報あるいは請求書情報といった請求情報）をＳＭＳ２２に送るので、両者間の通信が双方向であることは明らかであろう。
【００３５】
加入者認可システム（Ｓｕｂｓｃｒｉｂｅｒ  Ａｕｔｈｏｒｉｚａｔｉｏｎ  Ｓｙｓｔｅｍ：ＳＡＳ）
ＳＭＳ２２によって生成されたメッセージは、リンケージ２３を介して加入者認可システム（ＳＡＳ）２１に渡され、今度はこのＳＡＳ２１は、ＳＭＳ２１によって作成されたメッセージの受領を通知するメッセージを作成して、これらの受領通知をＳＭＳ２２に渡す。
概略的に、ＳＡＳは、加入方式の権利を与え、毎月その権利を自動的に更新する加入連鎖領域と、ＰＰＶイベントの権利を与えるペイパービュー連鎖領域と、これら加入およびＰＰＶ連鎖領域によって作成されたＥＭＭをマルチプレクサスクランブラ４に渡し、従ってＭＰＥＧストリームにＥＭＭを供給するＥＭＭインジェクタを含んでいる。もしコンピュータソフトウエアをユーザのパーソナルコンピュータにダウンロードする場合のペイパーファイル（ＰＰＦ）といった他の権利が与えられることになっていれば、他の同様な領域も設けられる。
【００３６】
ＳＡＳ２１の一つの機能は、加入方式で商業的提供物として入手可能なテレビジョン番組、あるいは異なる商品化方式（予約方式、衝動方式）にしたがってＰＰＶイベントとして販売されるテレビジョン番組へのアクセス権を管理することである。ＳＡＳ２１は、これらの権利とＳＭＳ２２から受け取った情報とにしたがって、加入者用のＥＭＭを生成する。
ＥＭＭは、管理キーと利用キーとに関する暗号化のための暗号化ユニット（ＣＵ）２４に渡される。ＣＵは、ＥＭＭ上で署名を完了させてそのＥＭＭをＳＡＳ２１内のメッセージジェネレータ（ＭＧ）に返送し、ここでヘッダが付加される。ＥＭＭは、完全なＥＭＭとしてメッセージエミッタ（ＭＥ）に渡される。メッセージジェネレータは、放送の開始停止時間とＥＭＭの放射速度とを決定し、これらをＥＭＭと一緒に適当な指示としてメッセージエミッタに渡す。ＭＧは、所定のＥＭＭを一度作成するだけであって、ＥＭＭの周期的な送信をするのはＭＥである。
【００３７】
ＥＭＭの生成に際してＭＧは、一意の識別子をそのＥＭＭに割り当てる。ＭＧがＥＭＭをＭＥに渡すときＥＭＭ  ＩＤも渡す。これは、ＭＧとＭＥの両者での、ある特定のＥＭＭの識別を可能にする。
例えば多数の運用業者に関連する多数の条件付きアクセスシステムを取り扱うことに適応した同時暗号化（ｓｉｍｕｌｃｒｙｐｔ）といったシステムでは、各条件付きアクセスシステムに関連するＥＭＭストリームが別々に生成され、これらは、送信に先立ってマルチプレクサ４によって互いに多重化される。
【００３８】
レシーバ／デコーダ
さて図３を参照しながら、ディジタル放送システムで使用され、本発明での使用に適応したレシーバ／デコーダ１２あるいはセットトップボックスの要素について説明する。理解されるように、このデコーダの基本要素は、大部分は従来どおりのものであり、それらの実現は、この技術に精通した人の能力の範囲内にあるであろう。
図示のように本デコーダ１２は、データの送受信用の数種類のインタフェースと、特に放送ＭＰＥＧ伝送の受信用チューナー４０と、シリアルインタフェース４１と、パラレルインタフェース４２と、電話網を介してデータを送受信するためのモデム４３とを備えている。このデコーダはまた、第１、第２のスマートカード読取り器４４、４５を含んでおり、この第１の読取り器４４は加入スマートカードを受け入れるものであり、第２の読取り器４５はバンクカードおよび／または他のスマートカードを受け入れるものである。
【００３９】
デコーダはまた、送受器遠隔制御４７からの赤外線制御信号を受信するレシーバ４６と、このデコーダに接続されたテレビジョン１３にオーディオビジュアル信号を送るためのペリテル（Ｐｅｒｉｔｅｌ）出力とを含んでいる。
これらのインタフェースを介して受信したディジタル信号の処理と出力信号の生成は、中央制御ユニット４８としてここに纏められたハードウエア要素とソフトウエア要素とのアンサンブルによって処理される。
デコーダ内の制御ユニットのソフトウエアアーキテクチャについては、図４、５を参照しながら以下に説明する。明確に言えばこのシステムは、デコーダのハードウエアコンポーネントに実現された、より低レベルのオペレーティングシステムとインタフェースレイヤを介して対話する仮想マシンを使用する。ハードウエアアーキテクチャの点からは、制御ユニット４８は、既知のデコーダと同様にプロセッサと、ＲＯＭ、ＲＡＭ、ＦＬＡＳＨメモリ等といったメモリ素子とを備えている。
【００４０】
制御ユニット４８によって処理されるアプリケーションは、デコーダのＲＯＭまたはＦＬＡＳＨに記憶された常駐のアプリケーションであるか、またはデコーダのＭＰＥＧインタフェース２を介して放送され、ダウンロードされるアプリケーションである。アプリケーションは、デコーダが起動時に直ちに動作状態になることを可能にする起動アプリケーションとデコーダの態様を構成するアプリケーションと同じく、番組案内アプリケーション、ゲーム、対話型サービス、テレショッピングアプリケーション等も含むことができる。アプリケーションは、デコーダ内の記憶場所に記憶され、グラフィックオブジェクト記述ファイル、ユニットファイル、変数ブロックファイル、命令列ファイル、アプリケーションファイル、データファイル等からなる資源ファイルとして表現される。
【００４１】
デコーダシステムアーキテクチャ
さて図４に示すように、レシーバ／デコーダ内のシステムのソフトウエアアーキテクチャを考えてみると、階層化されたアーキテクチャが使われていることが分かるであろう。第１のレイヤ５１は、レシーバ／デコーダのハードウエアのオペレーティングシステムを表している。これは、レシーバ／デコーダのハードウエア要素を制御するために製造業者によって選択されたリアルタイムオペレーティングシステムである。このリアルタイムオペレーティングシステムは、ハードウエアの動作を正しく同期させることを可能にするために比較的高速の応答時間を持っている。データ処理システムは、このハードウエアオペレーティングシステムの上に位置しており、ミドルウエアレイヤ５２とアプリケーションインタフェースレイヤ５３とを含んでいる。
【００４２】
イベントメッセージは、オペレーティングシステムレイヤ５１と、その直ぐ上のミドルウエアレイヤ５２との間で渡される。ミドルウエアレイヤは、Ｃ  ＡＮＳＩといった言語で書かれており、仮想マシン５４の要素と、グラフィカルインタフェース５６、ＦＬＡＳＨ／ＰＲＯＭメモリインタフェース５７、プロトコルインタフェース５８およびデバイスインタフェース５９を含む多数のインタフェース５５とからなる。
仮想マシンの使用は特に、下記に更に詳細に説明される、通常システム管理者または一つ以上の運用業者によって提供される、より高レベルのアプリケーション６６、６７と、通常はデコーダのハードウエア製造業者によって実現される、より低レベルのオペレーティングシステムとの間の独立性を与えることができる。
インタフェース６０は、仮想マシンの動作と低レベルオペレーティングシステム５１の動作との間にリンクを与え、また中間レベルで更に容易に実行される多数の中間レベルのアプリケーションモジュールを含んでいる。
【００４３】
アプリケーションインタフェース（ＡＰＩ）レイヤ５３は、Ｊａｖａといったオブジェクト指向の解釈的言語で書かれた多数の高レベルパッケージ６０〜６５を含んでいる。これらのパッケージは、一般にサービス提供業者によって作成された高レベルアプリケーション（対話型番組案内、テレショッピング、インターネットブラウザ等）と、このシステムの仮想マシンとの間のインタフェースを提供する。このようなアプリケーションの例について、下記で説明する。
低レベルＯＳは通常、デコーダのハードウエアコンポーネントに埋め込まれており、一部の実施形態ではあるが、低レベルＯＳをダウンロードすることができる。ミドルウエアおよびアプリケーションインタフェースレイヤのパッケージは、放送送信からデコーダのＲＡＭまたはＦＬＡＳＨメモリにダウンロードできる。代替としてミドルウエアまたはアプリケーションインタフェースレイヤの要素の一部または全部は、デコーダのＲＯＭまたは（もしあれば）ＦＬＡＳＨメモリに記憶しておくことができる。理解されるようにデコーダのメモリ素子の物理構成は、メモリの論理構成とは異なっている。
【００４４】
アプリケーションおよびアプリケーションマネージャ
図４に示すように、多数の高レベルアプリケーション６６は、システム内の低レベルの上に位置しており、アプリケーションインタフェースレイヤ５３を介してこれらの低レベルと通信する。以下に説明するように、アプリケーションは、種々の供給源および／または運用業者から発生し得る。このようなアプリケーションの全体的制御は、それ自身がアプリケーションとしてインストールされて、放送されるアプリケーションのダウンロードとシステムの低レベルレイヤ等をアドレス指定して制御するためのある一定のアプリケーションの権利とを管理する責任を有するアプリケーションマネージャ６７によって実行されるであろう。
【００４５】
アプリケーションインタフェースレイヤ
図３に示すアプリケーションインタフェースレイヤ５３を参照すれば、前述のように、このレイヤのパッケージは、Ｊａｖａといったオブジェクト指向の言語で書かれている。各パッケージは、システムの動作中に要求される１組のクラスライブラリを定義する。本システムには下記のパッケージがインストールされている。
Ｌａｎｇ／Ｕｔｉｌパッケージ６０。これらのパッケージは、仮想マシンによるオブジェクトの操作に必要なクラスを定義する。これらのクラスライブラリは通常、選択されたオブジェクト指向言語に関連する標準ライブラリの一部を形成する。
ＭＨＥＧ−５パッケージ６１。このパッケージは、テレビジョン表示上のグラフィカルオブジェクトの操作に関連するクラスを定義する。このようなオブジェクトは、オーディオビジュアルデータとは異なっており、例えば表示された画像上に置かれたチャンネル識別子やテキストを組み上げることができる。このパッケージ内のクラスの定義は、ＥＴＳ３００７７７−３規格とＩＳＯ／ＩＳＥ１３５２２−５規格（およびＪａｖａで実現されたシステムの場合にはＩＳＯ／ＩＳＥ１３５２２−６規格）によって定義されるＭＨＥＧ−５基準を尊重すべきである。
【００４６】
Ｔｏｏｌｂｏｘパッケージ６２。このパッケージは、情報のダウンロードとデコンプレッション（非圧縮化）のために使用されるクラスと、レシーバ／デコーダ内のファイルシステムとメモリの管理に関連するクラスと、インターネット接続等に関連するクラスとを含んでいる。
Ｄｅｖｉｃｅパッケージ６３。このパッケージは、前述のような、またモデム、スマートカード読取り器、ＭＰＥＧフローチューナー等を含む、レシーバ／デコーダに取り付けられた周辺装置の管理に必要なクラスを定義する。
Ｓｅｒｖｉｃｅパッケージ６４。このパッケージは、クレジットカードデータ等の管理といった高レベル対話型アプリケーション開発の実施に必要なクラスを定義する。
ＤＳＭＣＣ−ＵＵパッケージ６５。このパッケージは、データファイルの探索と読取りのための、クライアントとサーバとの間の通信に必要なプロトコルを実現する。このパッケージの実現は、ＩＳＯ／ＩＥＣ１３８１８−６基準とＤＡＶＩＣパート９に定義された指示とを尊重すべきである。
【００４７】
サービス提供業者によって書かれ、従来のシステムのように放送中にダウンロードされる対話型アプリケーションの更なるレイヤは、上記に定義したインタフェースパッケージ上に置かれるであろう。導入されるアプリケーションによって、上記のパッケージの一部が省略されることもある。例えばもしサービス提供業者がデータ読取りのための一般的な方法を提供する意図を持たなければ、ＤＳＭＣＣ−ＵＵパッケージは最終システムから省略してもよい。
パッケージ５３は、オブジェクト指向プログラミング環境のためにクラスライブラリを提供する。これらのクラスの行動は、選択された言語に依存する。例えばＪａｖａアプリケーションの場合には、単一の継承クラス構造が厳守されるであろう。
【００４８】
インタフェースレイヤ
図示のように、インタフェースレイヤは、４個のモジュール、すなわちグラフィックスモジュール５６とメモリファイル管理モジュール５７とプロトコルモジュール５８とデバイスマネージャ５９とから構成される。このレベルのモジュールはインタフェースモジュールとして記述されるが、それらの機能は、アプリケーションインタフェースパッケージの実現と一般に仮想マシンの動作とのための「接着剤」レイヤを提供することである。
グラフィックスモジュール５６は例えば、グラフィカルオブジェクトの作成と管理とを提供する。これは、低レベルＯＳに個々の画素、線、矩形などといった基本的な図形を表示するように依頼する。このモジュールの実現は、製造業者の低レベルＯＳの図形処理機能に依存する。ＭＨＥＧ−５パッケージ４３１１への補足的な幾つかの方法では、これらの機能は、上記のアプリケーションレイヤ用に選択された高レベルのコードよりもこのコードレベルでの方がより効率的に実行できる。
【００４９】
同様な仕方でメモリファイル管理モジュール５７は、システムのメモリコンポーネントに関連する低レベルのファイル読取り／書込みコマンドを含んでいる。代表的にはハードウエアオペレーティングシステムは、メモリコンポーネント内のセクタまたはページを読み／書きするために必要なコマンドを含むだけである。グラフィックスモジュール５６と同様にこのモジュールは、１組のより単純な低レベルアプリケーションがシステムに効率的に導入されることを可能にする。
プロトコル管理モジュール５８は、例えばデコーダのＴＣＰ／ＩＰレイヤを介しての通信時に要求される可能性のある通信プロトコルのライブラリを定義する。
デバイスマネージャ５９は、ハードウエアオペレーティングシステムと、インタフェースレイヤ内の他のモジュールと仮想マシンとを含む上記のレイヤとの間のリンクまたはインタフェースを提供するということにおいて、このレイヤ内のその他のモジュールとは僅かに異なっている。例えば仮想マシンからハードウエアオペレーティングシステムに受信／送信されるコマンドまたはイベントメッセージは、これら二つのレベル間のインタフェース仕様にしたがう変換のために、必ずデバイスマネージャによって渡される。
【００５０】
仮想マシンの説明
今度は図５を参照して、本発明のシステムで使われる仮想マシン５４の構造を説明する。本発明で使われる仮想マシンは、プリエンプティブ（割込み優先）マルチスレッド型のマシンである。このようなマシンの一般的特性は、オーディオビジュアル分野とディジタルテレビジョン分野以外の関連で知られており、また下記の説明は、本出願に最も特有のそれらの分野に焦点を合わせている。
仮想マシンは、図５に示すように幅広く相互作用する多数の要素から構成される。
スレッドマネージャサービス７１とモニタマネージャサービス７２とからなるスケジューラ７０は、マルチスレッドマシンの心臓部を形成する。スケジューラ７０は、仮想マシンの外部からアプリケーションによって作成されるスレッドと仮想マシン自身によって作成されるスレッド（例えばガーベッジコレクションスレッド（不要情報整理スレッド））との実行を順序づける。
【００５１】
イベントマネージャ７３は、イベント経路指定テーブルとスレッドによって予約されたイベントのリストとを処理して、イベント処理の迅速処理を集中化する。
メモリマネージャ７４は、システムメモリ内のメモリゾーンの割当てと割当て解除とを処理し、また非参照オブジェクトの、メモリからの削除（ガーベッジコレクション）を処理する。
クラスマネージャ７５は、ダウンロードされたコードの完全性を検査するセキュリティマネージャ８０と対話し、またファイルマネージャ７６と対話しながら、ダウンロードされたアプリケーションコードのクラスを放送信号に入れて、アプリケーションを実現する。
ファイルマネージャ７６は、ファイルシステムの実現を実行し、対話型アプリケーションとデータとをダウンロードする機構を操作する。
セキュリティマネージャ８０は、ダウンロードされたアプリケーションに許されたアクセスのレベルを処理するが、幾つかのアプリケーションは、ファイルシステムに関する他の演算より多くの演算を実行する能力を持っている。
【００５２】
バイトコード翻訳サービス７８と「ｍコード」翻訳サービス７９とを含むインタプリタ７７は、これら二つのコード、すなわちＪａｖａアプリケーションに関連するバイトコードと応募者によって開発された専用のコードに与えられる名前であるｍコードとで書かれたアプリケーションの翻訳を処理する。
前述のようにデコーダは、トランスポートパケットの形でダウンロードされたアプリケーションと、衛星、ケーブル、または地上システムによって放送されたトランスポートストリームからのデータテーブルとを実現して実行することに適応している。さて図６を参照しながら、従来のＭＰＥＧ−２データストリーム内のこれらおよび他のこのようなデータテーブルの構成について説明する。
【００５３】
トランスポートストリーム内のデータテーブルの構成
図６に示すように、放送されるデータトランスポートストリームは、番組アクセステーブル９０（「ＰＡＴ」）を含む標準フォーマットの多数のパケットを含んでおり、このパケットのヘッダ内のＰＩＤは、このパケットに関してＭＰＥＧ−２規格によって０ｘ００という値に固定されている。番組アクセステーブル９０は、番組データへのアクセスのための入口点を備えており、このストリーム内の所定のサービスまたはチャンネルに関連する番組マップテーブル（「ＰＭＴ」）９１、９２のＰＩＤ値を参照するテーブルを含んでいる。各番組マップテーブル９１、９２は今度は、そのサービスに関連するオーディオテーブル９３とビデオテーブル９４とのパケットストリームのＰＩＤ値への参照を含んでいる。
図示のように、番組マップテーブル９２はまた、当のサービスに関する追加データ、特にこのサービスが保持するアプリケーションデータと同じく多数の条件付きアクセスシステムによって生成され、当のサービスに関連するＥＣＭデータを含む他のパケット９５、９６、９７のＰＩＤ値への参照も含んでいる。
【００５４】
番組アクセステーブルＰＡＴ９０に加えて、ＭＰＥＧトランスポートストリームは更に、条件付きアクセステーブル１０１（「ＣＡＴ」）を含んでおり、そのＰＩＤ値は０ｘ０１に固定されている。したがってこのＰＩＤ値を有するいかなるパケットヘッダも、アクセス制御情報を持っていると、自動的に識別される。ＣＡＴテーブル９７は、一つ以上の条件付きアクセスシステムと関連するＥＭＭデータを参照するＭＰＥＧパケット９８、９９、１００のＰＩＤ値を参照する。ＰＭＴパケットについてと同様に、ＣＡＴテーブル１０１内の参照されたＥＭＭパケットのＰＩＤ値は、固定的ではなく、システム運用者の選択で決定することもできる。
ＭＰＥＧ−２規格は、上記参照されたＰＡＴテーブル値とＣＡＴテーブル値とを除いてごく僅かの固定されたＰＩＤ値を指定する。したがって、ある一定の範囲内のＰＩＤ値の大多数は、運用業者によって決定可能である。以下さらに詳細に説明するように、本発明の本実施形態は、多数のサービスとブーケに保持されているアプリケーションに関するデータを含むテーブルに割り当てられる固定されたＰＩＤ値を提案する。
【００５５】
トランスポートパケットのフォーマットとプライベートセクションのデータ
知られているようにＭＰＥＧトランスポートパケットは、ヘッダを含めて１８８バイトという一定の長さを持っている。標準パケットでは、同期データに続くヘッダの３バイトは、次のものから構成される。
表Ｉ
トランスポートエラーインジケータ          １ビット
ペイロードユニットインジケータ            １ビット
トランスポート優先度                      １ビット
ＰＩＤ                                    １３ビット
トランスポートスクランブル制御            ２ビット
適応フィールド制御                        ２ビット
連続性カウンタ                            ４ビット
【００５６】
これらのフィールドの特性は大部分、ＭＰＥＧ規格によって決定される。
上記は、トランスポートパケットのヘッダのフォーマットを説明したものである。ＭＰＥＧ−２規格にしたがって、パケットペイロードと共に含まれる情報は、トランスポートされるデータのタイプにしたがって更に上のレベルの構造に従属する。オーディオ、ビデオ、テレテキスト、サブタイトル、その他このような迅速に展開し、同期化されたデータの場合には、情報は、パケット化された基本ストリームあるいはＰＥＳとして知られる形に組み立てられる。送信されるパケットのペイロードを組み立てることによって形成されるこのデータストリームはそれ自身で、各々のパケットがパケットヘッダとペイロードとを持っている一連のパケットを含んでいる。トランスポートストリームの形で送信されるパケットとは異なり、ＰＥＳパケットの長さは可変である。
【００５７】
アプリケーションデータまたはＥＣＭおよびＥＭＭデータといった他の幾つかのタイプのデータの場合には、ＰＥＳパケット化とは異なるフォーマットが規定されている。特にトランスポートパケットペイロードに含まれるデータは、一連のセクションまたはテーブルに分割されるが、このテーブルまたはセクションヘッダは、当のテーブルを識別するテーブルＩＤあるいはＴＩＤを含んでいる。データのサイズによってセクションは、一つのパケットペイロード内に完全に収まることもあり、多数のトランスポートパケットに跨がる一連のテーブルに拡張されることもある。ＭＰＥＧ−２関連で、用語「テーブル」は、データの単一のテーブルを指すために使われることが多いが、「セクション」は通常、同一のＴＩＤ値を有する複数のテーブルの内の一つを指す。
【００５８】
これらのテーブルまたはセクション内に保持された情報を指すために使われる実際のＴＩＤ値は、ＭＰＥＧ−２規格によって確定されておらず、１サービスあるいは１ブーケのサービスの運用業者の自由裁量で定義できる。
トランスポートパケットデータやＰＥＳパケットデータと同様に、テーブルまたはセクションのデータ構造または構文はやはり、ＭＰＥＧ−２規格によって更に定義される。プライベートテーブルデータまたはプライベートセクションデータ用の二つの可能な構文形式、長い形式と短い形式とが提案されている。
【００５９】
長短両形式においてプライベートテーブルのヘッダは、少なくとも下記からなるデータを含んでいる。
表ＩＩ
テーブルＩＤ                              ８ビット
セクション構文インジケータ                １ビット
プライベートインジケータ／予備            １ビット
ＩＳＯ予備                                ２ビット
セクション長                              １２ビット
プライベートインジケータ長とプライベートセクション長は、ＭＰＥＧ−２規格によって確定されないデータからなっており、システム運用者によって運用者自身のために使うことができる。テーブル構文に関する更に詳細な情報については、読者はＭＰＥＧ−２規格を参照できる。
【００６０】
一つ以上のＰＭＴテーブルを介してアクセスされるアプリケーション
上記から理解されるように、各ＰＭＴテーブルは、特定のサービスまたはチャンネルとこのサービス上で利用可能な情報とを定義する。例えば所定のサービス内に複数のオーディオストリームとビデオストリームが保持されていて、例えば視聴者が多数の異なる角度からそのサービスで放送されるスポーツイベントを見ることが可能になる。
サービスはまた、例えば対話型ショッピングアプリケーションまたは対話型気象図といった、ダウンロードされてデコーダによって実行されるアプリケーションを含むこともある。サービスが保持し、そのＰＭＴテーブルを介してアクセスされるアプリケーションの数とタイプは、大きく変化し得る。例えば専用の天気予報チャンネルの場合、そのチャンネルの保有するデータの大部分は、例えばこのサービスがリアルタイムでないビデオデータを持っているような、デコーダによって実行されるアプリケーションに関係していることもある。
【００６１】
１ブーケのサービスにおいては、起動アプリケーションといった幾つかのアプリケーションはすべてのサービスが保持しているが、一部のアプリケーションは、一つのサービスに、例えばそのサービスだけで見られる番組に直接関連している情報を含むアプリケーションに限定されていることもある。
従来から所定のサービスが保持するアプリケーションに関するすべてのデータは、そのサービス用の関連ＰＭＴテーブルに収められている。各ＰＭＴテーブルは、そのサービスによって使用されるアプリケーションの完全なセットに関する情報を持っており、これらのアプリケーションへのアクセスポイントを備えている。
【００６２】
サービスの選択に際して従来システムのアプリケーションマネージャは、そのサービスの保持するアプリケーションと、もし既にあるサービスに同調していれば、デコーダ内で現在実行されているそれらのアプリケーションとに関して、予め決められた一連の決定を実行する。デコーダ内に既に存在しないが新しいサービスに入っているアプリケーションは、そのサービスからダウンロードされる。もしデコーダ内で実行されているものより新しいバージョンがそのサービスに保持されていれば、このバージョンがダウンロードされて古いバージョンは削除される。実行中であって同じ（または古いバージョン）で新しいサービスにリストアップされているアプリケーションは、維持される。新しいサービスにリストアップされていないで現在実行中のアプリケーションは、削除される。
【００６３】
従来のデコーダシステムに見られるアプリケーションマネージャの後者の動作は、特に多くの問題を引き起こす。例えばユーザが一つのチャンネルから他のチャンネルに変更してまた元に戻る場合、アプリケーションは削除されていて、再インストールされる可能性がある。理解されるようにアプリケーションのインストールは、アプリケーションのサイズとデコーダ内の利用可能なメモリとによっては、かなり時間を要することがある。
更にチャンネルを変更する度ごとに、デコーダは、ダウンロードすべき、あるいは現在実行中のアプリケーションに関して何らかの動作を実行するために十分な情報を得る前に、ＰＭＴテーブルデータをダウンロードして分析することが要求される。これには、かなり時間を要する可能性がある。上述のように各サービスは、完全に独立していてそのサービスの動作に必要なすべてのアプリケーションを含んでおり、またこのようなアプリケーションに関する情報はそのサービスのＰＭＴテーブルに保持されている。
【００６４】
このような関係において、デコーダ内で現在実行中であって新しいサービスのＰＭＴテーブルにリストアップされていないアプリケーションの場合は、現在実行中のアプリケーションの中のどれがこのサービスに切り替わる際に無事に維持できるか、またどれが削除する必要があるかに関する情報をアプリケーションマネージャが持たないので、問題を提起する。大抵の現在のシステムは、新しいアプリケーションのダウンロードを可能にするために、現在実行中のアプリケーションを単に削除するように働く。
今度は図７を参照しながら、既知のシステムの問題を克服できるＭＰＥＧトランスポートストリームのテーブルおよびセクション用のデータフォーマットを定義する。
【００６５】
アプリケーション記述テーブル
図７に示すようにトランスポートストリームは、第１、第２のサービスに収められたデータを定義するために使われるＰＭＴ１、ＰＭＴ２テーブル９１、９２に加えて、サービスの各利用可能なブーケごとにアプリケーション記述テーブル（一つ、または複数）１１０、１１１を含んでいる。ＡＤＴ  Ｂ１は第１のブーケのサービス用のテーブルを表し、ＡＤＴ  Ｂ２は第２のブーケ用のテーブルを表す等である。
ＰＡＴテーブルおよびＣＡＴテーブルと同様な仕方で、ＡＤＴテーブルのＰＩＤ値は、ＭＰＥＧ−２規格によって現在、留保あるいは禁止されていない値に固定される。すべてのサービスブーケ内のすべてのアプリケーション記述テーブル、あるいはＡＤＴテーブルは、このＰＩＤ値によって、好ましくは固定されたＴＩＤ値によって指示される。異なるサービスブーケのために異なるＡＤＴテーブルを受け入れるために１ブーケのサービスに関連する各ＡＤＴテーブルには、ある特定のＴＩＤ拡張値が割り当てられる。これらのＴＩＤ拡張値は、固定される必要はなく、各ブーケの運用業者間の共通の同意によって決定できる。
【００６６】
理解されるように、本発明の本実施形態は、１ブーケのサービスごとに一つのＡＤＴテーブルを使用するが、この考えは、すべてのブーケに亘るすべてのサービスをカバーする単一のグローバルＡＤＴテーブルの使用へと一般化することができる。サービスの各ブーケを運用している運用業者間の違いを考慮すると、これは、すべての運用者ブーケについての情報を編集してグローバルＡＤＴテーブルの作成することに責任を持った「スーパーオペレータ」の創設を意味するであろうから実現は困難であるかも知れない。
デコーダは通常、そのデコーダに挿入された加入スマートカードまたはＰＣＭＣＩＡカードによって送信される権利にしたがって１ブーケのサービスを受信するように構成されている。加入カードから受け取った情報に基づいて、デコーダ内のアプリケーションマネージャは、このブーケに関連する適当なＴＩＤ拡張値を有するＡＤＴテーブルをダウンロードできる。
【００６７】
関連する加入カードを変更することによって予約したブーケを変更することは、デコーダに新しいブーケのサービスに関連した、またそれ自身の一意のＴＩＤ拡張値によって参照されるＡＤＴテーブルをダウンロードさせるであろう。このＴＩＤ拡張値は、加入カードから受け取った情報に直接与えられることもあり、デコーダ内のテーブルから導出されることもある。同様にデコーダは、他の手段によって、例えばモデムリンクを介して正しいＴＩＤ拡張値を持つように構成できる。
代替としてデコーダは、固定されたＰＩＤ、ＴＩＤ値を使用してトランスポートストリーム内のすべてのＡＤＴテーブルを走査してフィルタリングするように構成できる。以下に説明するように各ＡＤＴテーブル内には、そのＡＤＴテーブルが該当するサービスのＰＭＴ値への参照が存在する。この情報からデコーダは、ある特定のブーケのサービスに関して動作するときにどのＡＤＴテーブルが該当するかを推論できる。
【００６８】
図示のようにサービスブーケＢ１に関連するＡＤＴテーブル１１０は、三つの部分に、すなわちサービス記述部１１２とアプリケーション記述部１１３と（任意選択の）署名部１１４とに分割されている。
サービス記述部１１２は、どのアプリケーションＡ１、Ａ２、Ａ３等がサービスブーケＢ１内の各サービスＰＭＴ１、ＰＭＴ２等に保持されているかに関する情報を持っている。各アプリケーションは、一意のアプリケーションＩＤ（Ａ１、Ａ２等）によって識別される。
図７においてサービス記述部１１２は、サービスＰＭＴ１をアプリケーションＡ１、Ａ３等に関連するものとして識別し、サービスＰＭＴ２をアプリケーションＡ１、Ａ２、Ａ４等に関連するものとして識別する。
【００６９】
ＡＤＴテーブルのアプリケーション記述部１１３は、このブーケのすべてのサービスを介してアクセス可能なアプリケーションの記述を持っており、このアプリケーションの特性を記述するデータにこのアプリケーションＩＤをリンクする。この記述は代表的には、下記のパラメータを含んでいる。
Ａｐｐｌｉｃａｔｉｏｎ＿ｉｄ。ａｐｐｌｉｃａｔｉｏｎ＿ｉｄは、このブーケの各サービス内に保持されているアプリケーションのアプリケーションマネージャによる識別を可能にする。この実施形態では、各ブーケには異なるＡＤＴテーブルが関連しているので、他のブーケのサービスは、同じＩＤ値によってそれ自身のアプリケーションを指すことができ、したがってアプリケーションは、一対の値（ａｐｐｌｉｃａｔｉｏｎ＿ｉｄ、ｂｏｕｑｕｅ＿ｉｄ）によって専ら一意に識別される。
Ａｐｐｌｉｃａｔｉｏｎ＿ｔｙｐｅ：  アプリケーションのタイプ、例えば純粋なＪａｖａ言語アプリケーションまたはＭＨＥＧ−５アプリケーション。アプリケーションの起動がそのタイプによって全く異なることがあり、また同じサービスブーケに異なるタイプのアプリケーションが保持されていることもあるので、このタイプの定義が必要となる。タイプはまた、ソフトウエアのバージョン番号も含んでいる。
【００７０】
Ａｐｐｌｉｃａｔｉｏｎ＿ｎａｍｅ：  ユーザによって知られる、あるいはユーザに表示されるアプリケーションの名前。これは代表的には、アプリケーションが起動されるときにユーザが見る名前である。例えば「ＰＩＬＯＴ」と名付けられたアプリケーションの起動時にウィンドウ内にメッセージ「ＰＩＬＯＴ起動」を書くことが想像できる。
Ａｐｐｌｉｃａｔｉｏｎ＿ｂｏｏｔｉｎｆｏ：  アプリケーションをダウンロードおよび起動するためにアプリケーションマネージャがアドレス指定しなくてはならないアプリケーションのアクセスポイント（ａｐｐｌｉｃａｔｉｏｎ＿ｔｙｐｅに依存する）。
Ａｐｐｌｉｃａｔｉｏｎ＿ｆｌａｇ：  このフィールドは、ダウンロード、起動等に関するアプリケーションの行動を与える。特にこのフィールドは、当のサービスのＰＭＴテーブル内のいかなる指示にも関係なく、そのブーケ内のサービス間の変更時にアプリケーションを維持すべきか、削除すべきかを確定するために使われる。
【００７１】
Ａｐｐｌｉｃａｔｉｏｎ＿ｋｅｙ：  アプリケーションの起動に関連する遠隔制御キーまたはその他の入力動作。例えばパイロット型あるいはナビゲータ型のアプリケーションの場合、このａｐｐｌｉｃａｔｉｏｎ＿ｋｅｙは、パイロットの起動に関連した遠隔制御のボタンであることもある。自動スタートのアプリケーションに関しては、このａｐｐｌｉｃａｔｉｏｎ＿ｋｅｙ値は、省略値にすることもできる。
Ａｐｐｌｉｃａｔｉｏｎ＿ｅｘｃｌｕｓｉｖｅ：  アプリケーションが、あるサービスに限定されていることを示すフラグ。これは、各サービスに限定された複数のａｐｐｌｉｃａｔｉｏｎ＿ｉｄのリストが別のサービスに変更する場合にアプリケーションを削除するように動作するアプリケーションマネージャによって組み立てられることを可能にする。
Ａｐｐｌｉｃａｔｉｏｎ＿ｐｒｉｏｒｉｔｙ：  例えば最小（１）と最大（７）との間のアプリケーションの優先度。これに関して、優先度は、デコーダ内の資源へのアクセスの優先度および／またはアプリケーションのダウンロードに関する優先度を指すことができる。所望であれば、この違いを反映するために二つの別個の優先度フィールドを使うこともできる。
【００７２】
Ａｐｐｌｉｃａｔｉｏｎ＿ｍｅｍｏｒｙ：  アプリケーションをダウンロードするために必要なメモリサイズ。これは、アプリケーションのサイズだけでなく、そのアプリケーション自身とそのデータとが使用するメモリの最大量の推定値にも対応している。
Ａｐｐｌｉｃａｔｉｏｎ＿ｖｅｒｓｉｏｎ：  アプリケーションの現在のバージョン。
ＤＶＢトリプレット。これは、あるサービスに固有のアプリケーションに関するサービスのリストを識別する。ＤＶＴトリプレットは、元のＮｅｔｗｏｒｋ＿ＩｄとＴｒａｎｓｐｏｒｔＳｔｒｅａｍ＿ＩｄとＳｅｒｖｉｃｅ＿Ｉｄとから構成される。
認められるように、多くのタイプの情報が含まれる可能性があり、上記のリスト内の因子は、網羅的および／または必須であることを意図していない。
【００７３】
アプリケーション記述部内の他の情報は、サービスのセクションのＴＩＤテーブルの更に上のレベルの構造内に含まれるアプリケーションのモジュールを捜し当てるために必要とされる情報を含むこともある。例えば送信のためにテーブルとセクションとにパッケト化されることに加えて、アプリケーション自身が、例えばＤＳＭＣＣデータフォーマットにしたがうデータカルーセルに構成されることもある。ＡＤＴ内に含まれる情報は、デコーダがアプリケーションをダウンロードするための特定の入口点に行くことを可能にする経路記述またはカルーセルアドレスを含むことができる。
【００７４】
最後にＡＤＴテーブル１１０は、ＡＤＴテーブル１１０内のデータの電子署名からなる署名１１４を含んでおり、またデコーダがそのテーブル内のデータの発生源と完全性とを検証することを可能にする。
これは、例えばテーブル内のデータに対応するハッシュ値を得るためのハッシュアルゴリズム（ＭＤ５のような）の組合せを使用してブーケに責任を有する運用業者が作成することもできるが、このハッシュ値はその後、パブリック／プライベートアルゴリズム（ＲＳＡのような）のプライベートキーによって暗号化される。ＡＤＴテーブルの検証は、同じハッシュアルゴリズムを有するデコーダによって実行されることもでき、対応するパブリックキーを供給されることも可能である。通信されたデータを検証するためにハッシュアルゴリズムとプライベート／パブリックキーアルゴリズムとの組合せを使うことは、既知であり、ここで更に詳細に説明することはしない。
【００７５】
代替として、あるいはそれに加えて、ＡＤＴテーブルは、対称アルゴリズムによっても暗号化できる。しかしながら理解されるように、このレベルで電子署名を使うことは、任意選択であり、実際には検証は、更に低いレベルで、例えばアプリケーションデータ自身について実行することもできる。
上述のように、所定のブーケ用のＡＤＴテーブルは、予め決められたＰＩＤおよびＴＩＤ拡張値を持っており、このテーブルは、デコーダがどのサービスチャンネル（もしあれば）に同調しているかに関係なく、デコーダを起動すると即座にロードされて検証されるであろう。このテーブル内の情報が一旦供給されると、アプリケーションマネージャは、ＰＭＴテーブルのダウンロードを待つ必要なしに、サービスに同調させるとき、あるいはサービスを変更するときにアプリケーションを維持するか、維持しないかに関する選択の推論を可能にする。
特にサービスの選択時またはサービスの変更時にアプリケーションマネージャは、どのアプリケーションをダウンロードするか、どのアプリケーションを維持するか、どのアプリケーションを削除すべきか等を評価する際に、ａｐｐｌｉｃａｔｉｏｎ＿ｆｌａｇ、ａｐｐｌｉｃａｔｉｏｎ＿ｅｘｃｌｕｓｉｖｅ、ａｐｐｌｉｃａｔｉｏｎ＿ｐｒｉｏｒｉｔｙ、ａｐｐｌｉｃａｔｉｏｎ＿ｍｅｍｏｒｙの各フィールドに含まれる情報を考慮に入れることができる。
【００７６】
図７に示すサービスチャンネルＰＭＴ１に最初に同調するデコーダの場合には、アプリケーションマネージャは、このサービスチャンネルに含まれたアプリケーションＡ１、Ａ３を存在していて妥当であると、すなわちそのブーケのＡＤＴテーブルのサービスセクション１１２内にリストアップされているアプリケーションに対応するアプリケーションであると識別するであろう。これらのアプリケーションに関するＡＤＴテーブルデータを使って、アプリケーションマネージャは、それらのアプリケーションをダウンロードすべきかどうかに関して決定を実行し、すべての条件が満たされた（十分のメモリがある等）と想定して、アプリケーションＡ１、Ａ３等をダウンロードするであろう。
もしユーザがいまサービスチャンネルＰＭＴ２に切り換えるならば、アプリケーションマネージャは、アプリケーションＡ１、Ａ２、Ａ４をこのチャンネル内に存在していて妥当であると識別するであろう。
【００７７】
アプリケーションＡ１の場合には、アプリケーションマネージャは、このアプリケーションが既にダウンロードされていて、最新バージョンでデコーダ内に存在していることを知っており、デコーダ内で「そのまま」Ａ１を実行させておき、通常はなにも措置を実行しないであろう。アプリケーションＡ２、Ａ４の場合には、アプリケーションマネージャは、例えばこれらのアプリケーションのａｐｐｌｉｃａｔｉｏｎ＿ｐｒｉｏｒｉｔｙ、ａｐｐｌｉｃａｔｉｏｎ＿ｍｅｍｏｒｙ等の値を評価して、これらの値を、以前にダウンロードされて、デコーダ内で現在実行中のアプリケーションＡ３の対応する値と比較することもできる。この評価はまた、現在実行中のアプリケーションのａｐｐｌｉｃａｔｉｏｎ＿ｆｌａｇの値を使って、実行してすることもできる（上記参照）。
【００７８】
アプリケーションＡ３が存在しておらず、またＰＭＴ２を介してアクセスされるサービスチャンネルによって与えられる実行可能な事項へのすべてのアクセスには必要とされなくても、アプリケーションマネージャはやはり、ａｐｐｌｉｃａｔｉｏｎ＿ｆｌａｇの値にしたがって、アプリケーションＡ２、Ａ４の一方または他方のダウンロードより優先して、あるいはそれと同じく、アプリケーションＡ３の実行の継続を決定することもできる。したがってもしユーザがその後、ＰＭＴ１に戻っても、アプリケーションＡ３は、即座に利用可能となる。
その他多くの代替手段が可能である。例えばアプリケーションマネージャは、アプリケーションＡ１を削除するように（例えばＡ１がＰＭＴ１と関連するａｐｐｌｉｃａｔｉｏｎ＿ｅｘｃｌｕｓｉｖｅフラグを含んでいる場合）、Ａ３を削除してＡ２、Ａ４をダウンロードするまでの限られた時間の間、Ａ３を維持するように、ユーザが遠隔制御キーを押すまでＡ３を維持し、その後Ａ３を削除してアプリケーションＡ２、Ａ４の一つをダウンロードするようになどと構成することもできる。
【００７９】
理解されるように、あるブーケ内のすべてのサービスに亘るデータを含むＡＤＴテーブルの使用は、デコーダのアプリケーションマネージャが複数のサービスストリームに保持されたアプリケーションを維持するかしないかに関する非常に巧妙な評価を実行することを可能にしている。
上記の例ではＡＤＴテーブルは、放送されるトランスポートストリームからダウンロードされるものとして説明されてきた。実際には、ＡＤＴテーブル、または少なくともＡＤＴテーブルの開始バージョンは、あるブーケ内の一部、または全部のサービスが保持するある一定のアプリケーションをデコーダが自動的にロードすることを可能にするように、デコーダの製造時にデコーダ内にロードされることも可能である。代替としてデコーダは、そのモデム接続経由、スマートカードインタフェース経由、シリアルポート経由等により、あるバージョンのＡＤＴテーブルをダウンロードすることもできる。
【図面の簡単な説明】
【図１】  本実施形態によるディジタルＴＶシステムの全体的アーキテクチャを示す図。
【図２】  図１の条件付きアクセスシステムのアーキテクチャを示す図。
【図３】  本実施形態で使用されるレシーバ／デコーダの諸要素を示す図。
【図４】  本実施形態で使用されるデコーダのソフトウエアアーキテクチャを示す図。
【図５】  図４のシステム内の仮想マシンのアーキテクチャを示す図。
【図６】  送信トランスポートストリームでの種々のサービスに関するパケットの階層を示す図。
【図７】  １ブーケのサービスで提供されるアプリケーションに関するアプリケーション記述テーブルの使用を示す図。
【図１】
0004531259.tif 000002
【図２】
0004531259.tif 000003
【図３】
0004531259.tif 000004
【図４】
0004531259.tif 000005
【図５】
0004531259.tif 000006
【図６】
0004531259.tif 000007
【図７】
0004531259.tif 000008