JP2009089421A - Ｍｐｅｇテーブル構造 - Google Patents

Abstract

【課題】データ部分を含むＭＰＥＧプライベートテーブルセクションのためのデータ構造を提供する。
【解決手段】データ部分を含むＭＰＥＧプライベートテーブルセクションのためのデータ構造が開示されており、該データ構造は該セクションまたは該データ部分のサイズの基準を指定するサイズ指定子を備え、該データ部分は少なくとも１つのデータブロックを備え、該ブロックまたは各ブロックはそのブロックのサイズの基準を指定する追加サイズ指定子を含む。
【選択図】図８

Description

本発明の態様は、データ構造、ＭＰＥＧテーブル、ならびに該データ及び／またはＭＰＥＧテーブルに関する方法に、装置に、このような方法を実施する装置に、構文解析ツール、受信機／デコーダ、送信機、放送システム、コンピュータ読み取り可能媒体及び信号に関する。

本発明の態様は、トランスポートパケットストリームを処理する一般的なＭＰＥＧテーブルプロセッサに関する。本発明は、特にデジタルテレビシステムで使用するためのデジタル伝送システム用の受信機／デコーダに適している。

ここで使用されるように用語「デジタルテレビシステム」は、例えば任意の衛星システム、地上システム及びケーブルシステムまたは他のシステムを含む。

ここで使用される用語「受信機／デコーダ」は、なんらかの他の手段によって一斉送信または送信されてよい、例えばテレビ信号及び／無線信号などの符号化されている信号または符号化されていない信号のどちらかを受信する受信機を暗示してよい。用語は、受信された信号を復号するデコーダも暗示してよい。このような受信機／デコーダの実施形態は、物理的に別個の受信機と組み合わせて機能するデコーダのような、あるいはウェブブラウザ、ビデオレコーダ、またはテレビなどの追加機能を含むこのようなデコーダなどの、例えば「セットトップボックス」内で受信された信号を復号する受信機と一体化されたデコーダを含んでよい。

用語ＭＰＥＧは、国際標準化機構作業グループ「エムペグ（ＭＯＴＩＯＮ ＰＩＣＴＵＲＥＳ ＥＸＰＥＲＴ ＧＲＯＵＰ）」によって開発されたデータ伝送規格を指し、特にではあるがデジタルテレビ用途のために開発され、文書ＩＳＯ １３８１８−１、ＩＳＯ １３８１８−２、ＩＳＯ １３８１８−３、ＩＳＯ １３８１８−４に説かれるＭＰＥＧ−２規格に限られない。本特許願書の文脈においては、用語はデジタルデータ伝送に適用可能なＭＰＥＧフォーマットのすべての変形、変型及び開発物を含む。

本発明の第１の態様に従って、データ部分を含むＭＰＥＧプライベートテーブルセクションのためのデータ構造が提供され、該データ構造は該セクションまたは該データ部分のサイズの基準を指定するサイズ指定子を備え、該データ部分は少なくとも１つのブロックを備え、該ブロックまたは各ブロックはそのブロックのサイズの基準を指定する追加のサイズ指定子を含む。

テーブルセクションで従来提供される指定子に加えて追加のサイズ指定子を有することにより、その追加サイズ指定子は特定のデータブロックのサイズの基準を指定し、一般的なデータ構造を定義できるため、ＭＰＥＧプライベートテーブルセクションのそれぞれの使用に別の構造を提供するニーズを排除することができる。さらに、従来のサイズ指定子を保持できるため、テーブルセクションは下位互換性である場合がある。

前記に参照されるＭＰＥＧ規格サイズ指定子は、サイズ指定子の後のセクションの残りバイト数という点でセクションのサイズを指定する。ただし、該セクションまたは該データ部分のサイズの他の基準は本発明の範囲内に該当する。

特に、さらに複雑なデータ構造を達成するために、データ部分は、好ましくは、それぞれがこのような追加のサイズ指定子のそれぞれ１つを含む複数のデータブロックを備える。

本発明の追加の態様に従って、データ部分を含むＭＰＥＧプライベートテーブルセクションのためのデータ構造が提供され、該データ部分は、それぞれのブロックがそのそれぞれのブロックのサイズの基準を指定するサイズ指定子を含む複数のデータブロックを備える。

構造は好ましくはさらにブロックのリストを備える。

これによりなおさらに複雑なデータ構造が可能になる。リストはブロックを含まなくてよいか、１つのブロックまたは複数の（あるいは事実上非常に多数の）ブロックを含んでよい。

好ましくは、このようなリストはリスト中のブロックの全体的なサイズの基準を指定するリスト指定子を含む。これにより、データ構造は構文解析可能のままとなる。リスト指定子は、例えば、関連ブロック数またはその長さ全体を指定してよい。

まださらに複雑なデータ構造のために、構造は、好ましくは複数のこのようなリストを備える。

構造は、好ましくはさらに、このような複数のリストに共通なデータを有する少なくとも１つのブロックを備える。これによりデータ構造の汎用性を高めることができる。

同じ理由から、このようなリストの中の該ブロックまたは各ブロックは、その特定のリストに特定的なデータを有する。

言うまでもなく、これに関連して、リストに対する参照がそのリストが表現するコンテンツに対する参照を含むことが理解されるだろう。

構造は、好ましくはこのようなリストの中の複数のブロックを備える。

データ構造にさらに多くの機能性を与えるために、構造は、好ましくはさらにそれぞれのリストのコンテンツを表す識別子を備える。

データ構造の構文解析を容易にするために、サイズ指定子はブロックのヘッダ部分に位置している。

好ましくは、少なくとも１つのこのようなブロックはそのコンテンツを表すタグを含む。

したがって、必要とされるデータのあるブロックを検索またはフィルタリングできる。要件に応じて、タグはブロックのコンテンツに関連する情報を含んでよい。

ＭＰＥＧプライベートテーブルのデータ構造の好適実施形態は、前述されたようにただ１つの構造を備える。

ＭＰＥＧプライベートテーブルのデータ構造の好適実施形態は、前述されたように複数の構造を備える。

したがって、それぞれが単一の全体的な構造を有することがある２つの一般的なデータ構造を定義することができる。これらの２つの一般的な構造は状況に応じて使用できる。

構造は、好ましくはＭＰＥＧ標準ヘッダ及び追加ヘッダを含む。

好ましくは、追加ヘッダはデータの変換の状態を表すフラグを含む。例えば、フラグはデータの圧縮または暗号化の状態を表してよい。

代わりに、または加えて、追加ヘッダはデータ部分に適用された変換のタイプを表すフラグを含んでよい。

本発明の追加の態様は、データ部分を提供することと、データ部分の変換の状態またはタイプを表すフラグを追加することとを備えるＭＰＥＧポータブルテーブルをアセンブルする方法を提供する。

前述されたフラグは、そのとき、変換の状態またはタイプを決定するために（受信機／デコーダなどの）以後のプロセッサで使用できる。例えば、フラグは圧縮されたテーブルと圧縮され宛て以内テーブルを区別するために、あるいは暗号化されたテーブルと暗号化されていないテーブルを区別するために使用されてよい。フラグを使用することにより、複数の異なる変換アルゴリズムも使用できる。これにより、例えばさまざまな種類のデータでさまざまなアルゴリズムを使用できるようにするなどの、さらに大きな柔軟性が生まれる。

好ましくはデータ部分は、圧縮または暗号化などの変換を受けた。好ましくは、標準ヘッダ及び追加ヘッダは圧縮されておらず、暗号化されていない。これにより既存のシステムハードウェアとソフトウェアとの互換性が保証される。

好ましくは、追加ヘッダは、フィルタ指定子及び／または構文解析ツールタイプを指定するフィールド及び／またはプライベートテーブルセクションが処理される優先順位を指定するためのフィールドを含む。通常、構文解析タイプフィールドが追加ヘッダの最初のフィールドである。

本発明の追加の態様に従って、ＭＰＥＧ標準ヘッダ、追加ヘッダ、及びデータ部分を備えるＭＰＥＧプライベートテーブルセクションのためのデータ構造が提供される。

ＭＰＥＧ標準ヘッダの存在は、既存のプライベートテーブルセクションとの互換性を可能にするが、追加ヘッダの存在は追加の機能性をテーブルセクションに組み込むことを可能にする。

追加ヘッダは、好ましくはデータ部分に適用される変換の状態またはタイプを表すフラグを含む。

追加ヘッダは、好ましくはデータの圧縮の状態を表すフラグを含む。したがって、必要とされる帯域幅はさらに少なくなる。好ましくは、標準ヘッダ及び追加ヘッダは圧縮された形式ではない。

追加ヘッダは、データの暗号化の状態を表すフラグも含んでよい。したがって、プライベートテーブルセクションは暗号化コードのあるものによってだけ読み取られてよい。好ましくは標準ヘッダ及び追加ヘッダは暗号化された形式ではない。

追加ヘッダは、好ましくはフィルタ指定子も含む。したがって、強化された機能性をデータのフィルタリングに与えることができる。

追加ヘッダは好ましくは構文解析ツールタイプのフィールドを備える。これはさらに大きな汎用性を与えることができる。

構文解析を容易にするために、構文解析ツールタイプのフィールドは追加ヘッダの第１のヘッダである。

再び追加の機能性のために、追加ヘッダが、プライベートテーブルセクションが処理される優先順位を指定するフィールドを備える。例えば、同じ種類の複数のテーブルが同時に受信される場合、優先順位フィールドは、それらが処理される順序を決定するために使用されてよい。

本発明の追加の態様はＭＰＥＧプライベートテーブルで変換を実行する方法を提供し、該テーブルはデータ部分を備え、該方法は変換済みのデータ部分を形成できるように該データ部分を圧縮することを備える。

本発明の追加の態様はＭＰＥＧプライベートテーブルで変換を実行する方法を提供し、該テーブルはデータ部分を備え、該方法は変換済みのデータ部分を形成できるように該データ部分を解凍することを備える。

本発明の追加の態様はＭＰＥＧプライベートテーブルで変換を実行する方法を提供し、該テーブルはデータ部分を備え、該方法は変換済みのデータ部分を形成できるようにデータ部分を暗号化することを備える。

本発明の追加の態様はＭＰＥＧプライベートテーブルでの変換を実行する方法を提供し、該テーブルはデータ部分を備え、該方法は変換済みのデータ部分を形成できるように該データ部分を復号化することを備える。

該方法は、好ましくは変換済みのデータ部分で実行された変換の状態またはタイプを表すフラグを追加することをさらに備える。

発明の追加の態様は、中間ブロックを形成するためにデータブロックをアセンブルすることと、変換済みのブロックを形成するために該中間ブロックで変換を実行することとを備える、複数のデータブロックで変換を実行する方法を提供する。

個々に、且つ別個に各データブロックを変換する代わりに、本発明の本態様に従ってデータブロックは中間ブロックという形で大量に処理される。これにより処理のオーバヘッドは削減できる。典型的な変換プロセスの例は、圧縮、解凍、暗号化及び復号化を含む。

好ましくは、変換は１つのブロックを複数のサブブロックに分割し、要すればサブブロックごとに変換の状態及び／またはタイプを表すフラグを追加することを備える。

変換済みのブロックは受取人に送信される、及びまたは送信機から受信されてよい。

通常、方法は変換済みのブロックで追加変換、つまり通常は前記変換の逆を実行することをさらに備える。

追加変換を実行することは、通常、追加の中間部ロックを形成するためにサブブロックをアセンブルすることと、追加の中間部ロックで追加の変換を実行することを備える。

標準ヘッダは各サブブロックに追加されてよい。

通常、アセンブルするステップが、それぞれがそれぞれのデータブロックのサイズを指定するサイズ指定子を中間部ロックの中に含むことを備える。これにより、以後の処理ステップ中間ブロックからでデータブロックを抽出できる。各指定子はそのそれぞれのデータブロックに先行してよい、あるいはなんらかの他の方法でそのそれぞれのデータブロックと関連付けられてよい。

代わりに、変換済みのサイズ指定子は、ブロックがサブブロックにどのようにして分割されなければならないのかを決定するために検査されてよい。これによってデータブロック構造を作り直すことができる。

変換は圧縮、解凍、暗号化または復号化であってよい。

通常、前記複数のデータブロックはＭＰＥＧプライベートテーブルのデータ部分である。

変換済みのブロックは、通常、変換済みのＭＰＥＧプライベートテーブルの部分を形成するためにも使用される。

通常、ＭＰＥＧプライベートテーブルは、それぞれが標準ヘッダとデータ部分を含む複数のテーブルセクションを備え、変換済みのＭＰＥＧプライベートテーブルは、それぞれが標準ヘッダと変換済みのブロックによって提供される変換済みのデータ部分を含む複数のテーブルセクションを備える。

変換済みのＭＰＥＧプライベートテーブルの中のヘッダの少なくとも一部は、ＭＰＥＧプライベートテーブルの中の標準ヘッダの一部に実質的に同一であってよい。

方法は、変換のタイプ及び／または状態を指定する変換済みのＭＰＥＧプライベートテーブルの中に値を含むことをさらに備えてよい。

方法は、好ましくはデータの意図されている受取人である受信機／デコーダまたは受信機／デコーダのグループを識別するターゲット情報を追加するステップを備える。

ターゲット情報は、例えば識別された受信機／デコーダのスマートカード数（複数の場合がある）を一覧表示することによって、ある特定の受信機／デコーダまたはグループまたは複数の受信機／デコーダを直接的に識別してよい。代わりに、ターゲット情報は、例えばソフトウェアまたはハードウェアプラットホームを識別することによってなど、なんらかの間接的な方法で受信機／デコーダ（複数の場合がある）を識別してよい。

本発明の追加の態様は、複数の圧縮済みのデータブロックを備えるデータ構造を提供し、圧縮済みのデータは複数の解凍済みのデータブロックを提供するために解凍でき、それぞれの解凍済みのデータブロックはデータ部分と、該データ部分のサイズを指定するサイズ指定子を含む。

通常、解凍済みのデータブロックの数は、圧縮済みのデータブロックの数より多い。これにより処理のオーバヘッドが削減する。

通常、データ構造はそれぞれの圧縮済みのデータブロックと関連付けられるヘッダをさらに備える。

本発明の追加の態様は、複数の暗号化済みのデータブロックを備えるデータ構造を提供し、該暗号化済みのデータブロックは、複数の復号化済みのデータブロックを提供するために復号化することができ、それぞれの復号化済みのデータブロックは、データ部分と該データ部分のサイズを指定するサイズ指定子を含む。

通常、データ構造は、それぞれの復号化済みのデータブロックと関連付けられるヘッダをさらに備える。

通常、ヘッダは標準ＭＰＥＧヘッダである。

本発明の追加の態様は、圧縮済みのＭＰＥＧプライベートテーブルセクション及び／または圧縮済みのＭＰＥＧプライベートテーブルを提供する。標準ＭＰＥＧプライベートテーブルの圧縮は、記憶装置の空間及び帯域幅を節約する。

本発明の追加の態様は暗号化されたＭＰＥＧプライベートテーブルセクション及び／または暗号化されたＭＰＥＧプライベートテーブルを提供する。

本発明の追加の態様は、ＭＰＥＧプライベートテーブルセクションの意図された受取人である受信機／デコーダまたは受信機／デコーダのグループを識別するターゲット情報を備えるＭＰＥＧプライベートテーブルセクションまたはＭＰＥＧプライベートテーブルを提供する。

ターゲット情報は、例えば識別された受信機／デコーダのスマートカード数（複数の場合がある）を一覧表示することによってある特定の受信機／デコーダまたは受信機／デコーダのグループを直接的に識別してよい。代わりに、ターゲット情報は、例えばソフトウェアハードウェアプラットホームを識別することによってなんらかの間接的な方法で受信機／デコーダ（複数の場合がある）を識別してよい。

本発明の追加の態様は、ＭＰＥＧプライベートテーブルセクションをアセンブルする方法を提供し、該方法はＭＰＥＧプライベートテーブルセクションの意図された受取人である受信機／デコーダまたは受信機／デコーダのグループを識別するターゲット情報を挿入することを備える。

本発明の追加の態様は、変換を受けた変換済みのデータ部分を提供する手段と、変換のタイプを表すフラグを追加する手段とを備える、ＭＰＥＧプライベートテーブルをアセブルする装置を備える。

本発明の追加の態様は、ＭＰＥＧプライベートテーブルで変型を実行する装置を提供し、該テーブルはデータ部分を備え、該装置は変換済みのデータ部分を形成するために該データ部分を圧縮、解凍、暗号化及び／復号化する手段を備える。

本発明の追加の態様は、中間ブロックを形成するためにデータブロックをアセンブルする手段と、変換済みのブロックを形成するために該中間ブロックで変換を実行する手段とを備える、複数のデータブロックで変換を実行する装置を提供する。

本発明の追加の態様は、ＭＰＥＧプライベートテーブルセクションをアセンブルする装置を提供し、該装置は、ＭＰＥＧプライベートテーブルセクションの意図される受けと炉委任である受信機／デコーダまたは受信機／デコーダのグループを識別するターゲット情報を挿入する手段を備える。

本発明の追加の態様に従って、データ部分を含むＭＰＥＧプライベートテーブルセクションを構文解析する構文解析ツールが提供され、該データ部分のセクションのサイズの基準を指定するサイズ指定子を備えるフォーマットでデータを構文解析する（例えば関連付けられたメモリを備えるプロセッサの形の）手段を備え、該データ部分は少なくとも１つのデータブロックを備え、該ブロックまたは各ブロックはそのブロックのサイズの基準を指定する追加のサイズ指定子を含む。

好ましくは、構文解析ツールは、データ部分が複数のデータブロックを備え、それぞれがこのような追加サイズ指定子のそれぞれ１つを含むフォーマットでデータを構文解析するように適応される。

本発明の追加の態様においては、データ部分を含むＭＰＥＧプライベートテーブルセクションを構文解析する構文解析ツールが提供され、該データ部分は複数のデータブロックを備え、各ブロックはそのそれぞれのブロックのサイズの基準を指定するサイズ指定子を含む。

好ましくは、構文解析ツールはさらにブロックのリストを備えるフォーマットでデータを構文解析するように適応される。

好ましくは、構文解析ツールは、このようなリストがリストの中のブロックの全体的なサイズの基準を指定するリスト指定子を含むフォーマットでデータを構文解析するように適応される。

好ましくは、構文解析ツールは、複数のこのようなリストを備えるフォーマットでデータを構文解析するように適応される。

好ましくは、構文解析ツールは、このような複数のリストに共通なデータを有する少なくとも１つのブロックをさらに備えるフォーマットでデータを解析するように適応される。

好ましくは、構文解析ツールは、このような特定のデータがこのような共通のデータを無効にするようにデータを構文解析するように適応される。

好ましくは、構文解析ツールは、このようなリストの中の複数のブロックを備えるフォーマットでデータを構文解析するように適応される。

好ましくは、構文解析ツールは、それぞれのリストのコンテンツを表す識別子をさらに備えるフォーマットでデータを構文解析するように適応される。

好ましくは、構文解析ツールは、サイズ指定子がブロックのヘッダ部分に位置するフォーマットでデータを構文解析するように適応される。

好ましくは、構文解析ツールは、少なくとも１つのこのようなブロックがそのコンテンツを表すタグを含むフォーマットでデータを構文解析するように適応される。

好ましくは、構文解析ツールはただ１つのＭＰＥＧセクションを備えるフォーマットでデータを構文解析するように適応される。

代わりに、構文解析ツールは複数のＭＰＥＧセクションを備えるフォーマットでデータを構文解析するように適応される。

好ましくは、構文解析ツールはＭＰＥＧ標準ヘッダ及び追加ヘッダを含むフォーマットでデータを構文解析するように適応される。

本発明の追加の態様に従って、ＭＰＥＧ標準ヘッダ、追加ヘッダ、及びデータ部分を備えるフォーマットでデータを解析する（例えば、関連メモリを備えたプロセッサの形の）手段を備える、ＭＰＥＧプライベートテーブルセクションを構文解析する構文解析ツールが提供される。

好ましくは、構文解析ツールは、追加ヘッダが変換の状態またはタイプを表すフラグを含むフォーマットでデータを構文解析するように適応される。

好ましくは、構文解析ツールは、追加ヘッダがデータの圧縮の状態を表すフラグを含むフォーマットでデータを構文解析するように適応される。

好ましくは、構文解析ツールは、追加ヘッダがデータの暗号化の状態を表すフラグを含むフォーマットでデータを構文解析するように適応される。

好ましくは、構文解析ツールは、追加ヘッダがフィルタ指定子を含むフォーマットでデータを構文解析するように適応される。

好ましくは、構文解析ツールは、追加ヘッダが構文解析ツールタイプを指定するフィールドを備えるフォーマットでデータを構文解析するように適応される。

好ましくは、構文解析ツールは、構文解析ツールタイプフィールドが追加ヘッダの第１のフィールドであるフォーマットでデータを構文解析するように適応される。

好ましくは、構文解析ツールは、追加ヘッダがプライベートテーブルセクションが処理される優先順位を指定するためのフィールドを備えるフォーマットでデータを構文解析するように適応される。

本発明の追加の態様に従って、ＭＰＥＧ標準ヘッダとデータ部分を備えるＭＰＥＧプライベートテーブルセクションを構文解析するための構文解析ツールが提供され、ＴＩＤ拡張フィールドの値を出力する（例えば、関連付けられたメモリを備えるプロセッサの形を取る）手段を備え、該ＭＰＥＧ標準ヘッダがＴＩＤ拡張フィールドを含む。過去において、ＴＩＤ拡張フィールドは無視されていた。

本発明の追加の態様に従って、このようなデータを、指定フォーマットと、ここに説明するようなデータ構造のフォーマットのデータの間で変換する（例えば、関連付けられたメモリを備えるプロセッサの形を取る）手段を備えるデータを処理する装置が提供される。

本発明の追加の態様に従って、データ部分を提供する（例えば、関連付けられたメモリを備えるプロセッサの形の）手段と、データ部分の変換の状態またはタイプを表すフラグを追加する（例えば、関連付けられたメモリを備えたプロセッサの形の）手段とを備える、ＭＰＥＧプライベートテーブルをアセンブルする装置が提供される。

好ましくは、データ部分は、変換を受けた変換済みのデータ部分である。

本発明の追加態様に従って、ＭＰＥＧプライベートテーブルで変換を実行する装置が提供され、該テーブルはデータ部分を備え、該装置は変換済みのデータ部分を形成するために該データ部分を圧縮、解凍、暗号化または復号化する（例えば、関連付けられたメモリを備えたプロセッサの形の）手段を備える。

好ましくは、装置は、さらに変換済みのデータ部分の変換の状態を表すフラグを追加する（例えば、関連付けられたメモリを備えたプロセッサの形を取る）手段をさらに備える。

好ましくは、装置は、データ部分で実行された変換のタイプを表すフラグを追加する（例えば、関連付けられたメモリを備えたプロセッサの形を取る）手段をさらに備える。

本発明の追加の態様に従って、複数のデータブロックで変換を実行する装置が提供され、中間ブロックを形成するためにデータブロックをアセンブルする（例えば、関連付けられたメモリを備えるプロセッサの形を取る）手段と、変換済みのブロックを形成するために中間ブロックで変換を実行する（例えば、関連付けられたメモリを備えるプロセッサの形を取る）手段とを備える。

好ましくは、実行する手段は、１つのブロックを複数のサブブロックに分割するために（例えば、関連付けられたメモリを備えるプロセッサの形を取る）手段を備える。

好ましくは、装置は、データのサブブロックへの変換の状態を表すフラグを追加する（例えば、関連付けられたメモリを備えるプロセッサの形を取る）手段をさらに備える。

好ましくは、装置は、サブブロックへの変換のタイプを表すフラグを追加する（例えば、関連付けられたメモリを備えるプロセッサの形を取る）手段をさらに備える。

好ましくは、装置は、変換済みのブロックを受取人に送信する（例えば、関連付けられたメモリを備えるプロセッサの形を取る）手段をさらに備える。

好ましくは、装置は、変換済みのブロックを受信する（例えば、関連付けられたメモリを備えるプロセッサの形を取る）手段をさらに備える。

好ましくは、装置は、変換済みのブロックで追加のブロックを実行する（例えば、関連付けられたメモリを備えるプロセッサの形を取る）手段をさらに備える。

好ましくは、前記追加の変換は前記変換の逆である。

好ましくは、装置は、追加の中間ブロックを形成するためにサブブロックをアセンブルする（例えば、関連付けられたメモリを備えるプロセッサの形を取る）手段と、該追加の中間ブロックで追加の変換を実行する（例えば、関連付けられたメモリを備えるプロセッサの形を取る）手段とをさらに備える。

好ましくは、装置は、標準ヘッダを各サブアブロックに追加する（例えば、関連付けられたメモリを備えるプロセッサの形を取る）手段をさらに備える。

好ましくは、それぞれがそれぞれのデータブロックのサイズを指定するサイズ指定子を中間ブロックの中に含む（例えば、関連付けられたメモリを備えるプロセッサの形を取る）手段をさらに備える。

好ましくは、装置は、ブロックがどのようにサブブロックに分割されなければならないのかを決定するためにブロックの中のサイズ指定子を検査する（例えば、関連付けられたメモリを備えるプロセッサの形を取る）手段をさらに備える。

好ましくは、変換は圧縮、解凍、暗号化または復号化である。

好ましくは、装置は、変換されたブロックによって提供される少なくとも１つの変換済みのデータ部分を有する変換済みのＭＰＥＧプライベートテーブルを形成する（例えば、関連付けられたメモリを備えるプロセッサの形を取る）手段をさらに備える。

好ましくは、装置は変換のタイプを指定する変換済みのＭＰＥＧプライベートテーブルに値を含める（例えば、関連付けられたメモリを備えるプロセッサの形を取る）手段をさらに備える。

好ましくは、変換済みのデータ部分の変換の状態を指定する変換済みのＭＰＥＧプライベートテーブルに値を含める（例えば、関連付けられたメモリを備えるプロセッサの形を取る）手段をさらに備える。

好ましくは、前述されたような構文解析ツールを含む受信機／デコーダが提供される。しかしながら、本発明は受信機／デコーダに制限されず、例えばＰＣの中で実現できる。

データは放送ストリームで送信されてよい。データは、それから放送ストリームから受信機端部で抽出できる。

好適実施形態では、方法はデジタル放送センタ、及び複数の受信機／デコーダを含むシステムで利用される。

次に、データは、多様なタスクで利用できる。例えば、それは受信機／デコーダの機能を制御するアクション通知データを含んでよい。代わりに、データは、条件付きアクセスシステムへのアクセスを獲得するために受信機／デコーダによって使用するためのキーデータを含んでよい。

代わりに、データはビデオオンデマンドシステムで使用するための番組情報を含んでよい。

好ましくは、データ部分またはブロックは、指定されたカテゴリの少なくとも１つのアセットに対する番組情報を含み、データ部分またはブロックは前記カテゴリを識別するカテゴリ識別子を含むフィルタ指定子を伴なう。アセットは、好ましくはテレビ番組またはビデオオンデマンドシステムを通して使用可能な他の提供物であり、複数のアセットは好ましくはそれらのコンテンツに応じて分類される。例えば、スポーツカテゴリ、映画カテゴリ等がある場合がある。また、サブカテゴリがある場合もある。このようにして、フィルタリングはカテゴリ識別子に対して実行され、所望されるカテゴリの中のアセットに関する情報をさらに容易に検索できるようにしてよい。

代わりに、またはさらに、データ部分またはブロックはアセットに対する番組情報を含み、データ部分またはブロックは前記アセットを識別するアセット識別子を含むフィルタ指定子を伴なう。これにより、ある特定のアセットに関する情報をさらに容易に検索できる。

好ましくは、フィルタ指定子はＭＰＥＧテーブルセクションのＴＩＤ拡張フィールドである。多くの受信機／デコーダは、ＴＩＤ拡張フィールドを含む多くのヘッダフィールドに従ってＭＰＥＧテーブルセクションをフィルタリングする機能を提供し、このような機能は多くの場合ハードウェアで提供されるので、情報は、ＴＩＤ拡張フィールドがこのように使用されるときにこのようなデコーダによってさらに容易に且つ迅速に検索されてよい。

受信機／デコーダは、好ましくは、ＴＩＤ拡張フィールドの値を受信し、このような値を処理する（例えば、関連付けられたメモリを備えるプロセッサの形を取る）手段を含む。

受信及び処理手段は、好ましくは受信機／デコーダのユーザへの通知としてこのような値を処理するように適応される。

受信及び処理手段は、好ましくは受信機／デコーダによって受信されるコンテンツに関するデータとしてこのような値を処理するように適応される。

好ましくは、前述した、あるいは前述したようにアセンブルされ、処理され、あるいは変換されたデータ構造でデータを受信及び／または復号するように適応される受信機／デコーダが提供される。

送信機は、前述したような、あるいは前述したようにアセンブル、処理または変換されたデータ構造の中のデータを送信するように適応される。

受信機／デコーダ及び前述した送信機を組み込む放送システムがさらに提供される。

放送システムの中のデータは、好ましくは条件付きアクセスデータであり、システムは別個のチャネルデこのようなデータを送受するように適応されている。

指定されたフォーマットと、前述したようなデータ構造のフォーマットのデータの間でこのようなデータを変換することを備えるデータを処理する方法も提供される。指定されるフォーマットは、それに、及びそれから、それが前述されたようなデータ構造のフォーマットからデータが変換される任意のフォーマットであってよい。

本発明の追加の態様に従って、ここに前述された方法を使用してＭＰＥＧプライベートテーブルで変換を実行することと、変換済みのテーブルを送信することを備える、ＭＰＥＧプライベートテーブルを送信する方法が提供される。

追加の態様は、ＭＰＥＧプライベートテーブルを受信することと、ここに前述した方法を使用して受信したテーブルで変換を実行することとを備える、ＭＰＥＧプライベートテーブルを受信する方法を提供する。

好ましくは、データ部分またはブロックは、受信機／デコーダによる受信のため、及び受信機／デコーダの機能を制御するためのアクション通知データを含む。

好ましくは、データ部分またはブロックは、ビデオオンデマンドシステムで使用するための番組情報を含む。

好ましくは、データ部分またはブロックは指定されたカテゴリの少なくとも１つのアセットのための番組情報を含み、該データ部分またはブロックは前記カテゴリを識別するカテゴリ識別子を含むフィルタ指定子を伴なう。

好ましくは、データ部分またはブロックはアセットのための番組情報を含み、データ部分またはブロックは前記アセットを識別するアセット識別子を含むフィルタ指定子を伴なう。

好ましくは、フィルタ指定子はＭＰＥＧテーブルセクションのＴＩＤ拡張フィールドである。

好ましくは、データ部分またはブロックは、条件付きアクセスシステムに対するアクセスを獲得するために受信機／デコーダが使用するためのキーデータを含む。

本発明の追加の態様は、ここに説明されるようなＭＰＥＧプライベートテーブルまたはテーブルセクションを構文解析する、あるいはここに説明されるデータ構造を有するデータを構文解析する、あるいはここに説明される方法により処理、アセンブルまたは変換されるデータを構文解析する（例えば、関連付けられたメモリを備えるプロセッサの形を取る）手段を提供する。

本発明の追加の態様は、ここに説明されるような、あるいはここに説明されるような方法で処理、アセンブル、あるいは変換されたＭＰＥＧプライベートテーブルまたはテーブルセクションを送信するように適応される送信機を提供される。

本発明の追加の態様はここに説明されるような方法を実行するように適応される構文解析ツールを提供する。

本発明は、添付図面に関して実質的にここに説明される方法、及び実質的に添付図面に関してここに説明され、添付図面に図解されるような装置も提供する。

本発明は前述されたように方法を実行するように適応されたコンピュータプログラム製品に及ぶ。

本発明は、さらに、前述されたように構文解析ツールまたは装置を実現するコンピュータ読み取り可能媒体に及ぶ。

本発明は、前述されたように構文解析ツールまたは装置を有形で実現する信号になおさらに及ぶ。

本発明は、ここに説明される方法のどれかを実施するため、及び／またはここに説明される装置機能のどれかを実現するためのコンピュータプログラム及びコンピュータプログラム製品、ならびにここに説明される方法のどれかを実施するため、及び／またはここに説明される装置機能のどれかを実現するためのプログラムをその上に記憶するコンピュータ読み取り可能媒体も提供する。

本発明は、ここに説明される方法のどれかを実施するため、及び／またはここに説明される装置機能のどれかを実現するためのコンピュータプログラムを実現する信号、このような信号を送信する方法、ならびにここに説明される方法のどれかを実施するため、及び／またはここに説明される装置機能のどれかを実現するためのコンピュータプログラムをサポートするオペレーティングシステムを有するコンピュータ製品も提供する。

ハードウェアで実現される機能は、通常ソフトウェアで実現されてよく、逆もまた同様である。ここのソフトウェア機能とハードウェア機能に対するあらゆる参照は相応して解釈されるべきである。

本発明のある態様の任意の態様は、任意の適切な組み合わせで本発明の他の態様に適用されてよい。特に方法の態様は装置の態様に適用されてよく、逆もまた同様である。

本発明の好適機能はここで添付図面に関して純粋に例証として説明される。
システム概要
デジタルテレビシステム１の概要は図１に図示されている。本発明は、既知のＭＰＥＧ−２圧縮システムを使用し、圧縮済みのデジタル信号を送信するおもに従来のデジタルテレビシステム２を含む。さらに詳細には、放送センタ内のＭＰＥＧ−２圧縮器３がデジタル信号ストリーム（通常はビデオ信号のストリーム）を受信する。圧縮器３はリンケージ５によってマルチプレクサ及びスクランブラ４に接続される。

マルチプレクサ４は複数の追加入力信号を受信し、トランスポートストリームをアセンブルし、電気通信リンクを含む、言うまでもなく多岐に渡る形式を取ることがあるリンケージ７を介して圧縮済みのデジタル信号を放送センタの送信機６に送信する。送信機６は、信号が電子的に処理され、概念上のダウンリンク１０を介して従来はエンドユーザによって所有または借りられている地上受信機１２に一斉送信される衛星トランスポンダ９に向かってアップリンク８を介して電磁信号を送信する。言うまでもなく、地上放送、ケーブル伝送、衛星／ケーブル結合リンク、電話網等のデータの伝送用の他のトランスポートチャネルも考えられる。

受信機１２によって受信される信号は、エンドユーザによって所有される、または借りられ、エンドユーザのテレビ受像機１４に接続されている統合型受信機／デコーダ１３に伝送される。受信機／デコーダ１３は圧縮されたＭＰＥＧ−２信号をテレビ受像機１４用のテレビ信号に復号する。別個の受信機／デコーダが図１に図示されているが、該受信機／デコーダも統合型デジタルテレビの一部であってよい。ここに使用されるように、用語「受信機／デコーダ」は、セットトップボックスなどの別個の受信機／デコーダ、及びそれと統合される受信機／デコーダを有するテレビを含む。

マルチチャネルシステムにおいては、マルチプレクサ４が数多くの並列ソースから受信される音声情報とビデオ情報を処理し、送信機６と対話し、情報を対応する数のチャネルに沿って一斉送信する。視聴覚情報に加えて、メッセージまたはアプリケーションまたは他の種類のデジタルデータが、送信されたデジタル音声情報及びビデオ情報とインタレースされるこれらのチャネルのいくつかまたはすべてで導入されてよい。

条件付きシステム１５はマルチプレクサ４及び受信機／デコーダ１３に接続され、部分的に放送センタ内に、及び部分的に受信機／デコーダ内に位置する。それにより、エンドユーザは１つまたは複数の放送供給業者からのデジタルテレビ放送にアクセスできるようになる。商業的なオファー（すなわち放送供給業者によって販売される１つまたは複数のテレビ番組）に関するメッセージを解読できるスマートカードを受信機／デコーダ１３の中に差し込むことができる。受信機／デコーダ１３及びスマートカードを使用して、エンドユーザは加入モードまたはペイパービューモードのどちらかで商業的なオファーを購入してよい。

前述されたように、システムによって送信される番組はマルチプレクサ４でスクランブルされ、指定される伝送に適用される条件鍵及び暗号化鍵はアクセスコントロールシステム１５によって決定される。このようにしてスクランブルされたデータの伝送は、ペイテレビシステムの分野では周知である。通常、スクランブルされたデータは、データをデスクランブルするコントロールワードとともに送信され、該コントロールワード自体がいわゆるエクスプロイテーションキーによって暗号化され、暗号化された形式で送信される。

それからスクランブルされたデータ及び暗号化されたコントロールワードは、暗号化されたコントロールワードを復号化し、それ以後送信されたデータをデスクランブルするために受信機／デコーダに挿入されるスマートカード上に記憶されるエクスプロイテーションキーの同等物にアクセスしている受信機／デコーダ１３によって受信される。支払い済みの加入者は、例えば、放送月次ＥＭＭ（エンタイトルメント管理メッセージ）の中で伝送の視聴を可能とするように暗号化されたコントロールワードを復号化するために必要なエクスプロイテーションキーを受信するだろう。

やはりマルチプレクサ４及び受信機／デコーダ１３に接続され、再び部分的に放送センタ内にあり、部分的に受信機／デコーダ内にある対話型システム１６は、エンドユーザがバックチャネル１７を介して多様なアプリケーションと対話できるようにする。該バックチャネルは、例えば、公衆電話交換網（ＰＳＴＮ）チャネル（例えばモデム付きバックチャネル）またはアウトオブバンド（ＯＯＢ）チャネルであってよい。バックチャネルは条件付きアクセスシステム１５内で使用される通信にも使用されてよい。

条件付きアクセスシステム
図２を参照すると、概要において、条件付きアクセスシステム１５は、加入者許可システム（ＳＡＳ）３０を含んでいる。ＳＡＳ ３０は１つまたは複数の加入者管理システム（ＳＭＳ）３２、放送供給者ごとに１つのＳＭＳに、ＴＣＰ−ＩＰリンクまたは他の種類のリンクであってよいリンク３４によって接続される。代わりに、１つのＳＭＳは２つの商業的な事業者の間で共用されるか、あるいは１つの事業者が２つのＳＭＳを使用することがあるだろう。

「マザー」スマートカード３８を活用する暗号装置３６の形を取る第１の暗号化装置は、リンケージ４０によってＳＡＳに接続される。再びマザースマートカード４４を活用する暗号装置４２の形を取る第２の暗号化装置は、リンケージ４６によってマルチプレクサ４に接続される。受信機／デコーダ１３は「ドーター」スマートカード４８を受け入れる。受信機／デコーダは、通信サーバ５０及びモデム付きバックチャネル１７を介してＳＡＳ ３０に直接的に接続される。ＳＡＳは、要求がありしだい、とりわけ加入権をドータースマートカードに送信する。

スマートカードは、１つまたは複数の商業的な事業者からの秘密の情報を含んでいる。「マザー」スマートカードはさまざまな種類のメッセージを暗号化し、「ドーター」スマートカードは、それらがそうする権利を有している場合にはメッセージを復号化する。

図２に関して、放送センタでは、デジタルビデオ信号がＭＰＥＧ−２圧縮器３を使用して最初に圧縮される（つまりビットレート削減される）。それから、この圧縮された信号は、他の圧縮データなどの他のデータと多重化されるために、マルチプレクサ及びスクランブラ４に伝送される。

スクランブラは、スクランブルプロセスで使用され、マルチプレクサ４でＭＰＥＧ−２ストリームに含まれるコントロールワードを作成する。コントロールワードは内部で作成され、エンドユーザの統合型受信機／デコーダ１３が番組をデスクランブルできるようにする。

番組がどのようにして商品化されているのかを示すアクセス基準もＭＰＥＧ−２ストリームに追加される。番組は、数多くの「加入」モードの１つ及び／または数多くの「ペイパービュー」（ＰＰＶ）モードまたはイベント１つのどちらかで商品化されてよい。加入モードでは、エンドユーザは１つまたは複数の商業的なオファー、つまり「ブーケ」に加入し、このようにしてそれらのブーケの中のあらゆるチャネルを見る権利を獲得する。ペイパービューモードでは、エンドユーザは、自分が希望するようにイベントを購入する機能を与えられる。

コントロールワードとアクセス基準の両方ともエンタイトルメントコントロールメッセージ（ＥＣＭ）を構築するのに使用される。これは、１つのスクランブルされた番組に関して送信されるメッセージであり、該メッセージは（番組のデスクランブルを可能にする）コントロールワード及び放送番組のアクセス基準を含む。アクセス基準とコントロールワードはリンケージ４６を介して第２の暗号化装置４２に送信される。この装置では、ＥＣＭが生成され、暗号化され、マルチプレクサとスクランブラ４に送信される。

放送供給業者によってデータストリームの中で一斉送信される各サービスは、数多くの別個の成分を備える。例えば、テレビ番組は、ビデオ成分、音声成分、字幕成分等を含んでいる。サービスのこれらの成分のそれぞれが個別にスクランブルされ、以後の放送のために暗号化される。サービスのそれぞれのスクランブルされた成分に関して、別個のＥＣＭが必要とされる。

マルチプレクサ４は、ＳＡＳ ３０からの暗号化されたＥＭＭ、第２の暗号化装置４２からの暗号化されたＥＣＭ、及び圧縮器３からの圧縮済み番組を備える電気信号を受信する。マルチプレクサ４は番組をスクランブルし、スクランブルされた番組、暗号化されたＥＭＭ、及び暗号化されたＥＣＭを電気信号として、例えば図１に図示されるような衛星システム、または他の放送システムであってよい放送システム５４に送信する。受信機／デコーダ１３は信号を逆多重化し、暗号化されたＥＭＭと暗号化されたＥＣＭとともに、スクランブルされた番組を取得する。

受信機／デコーダは放送信号を受信し、ＭＰＥＧ−２データストリームを抽出する。番組がスクランブルされている場合、受信機／デコーダ１３は、ＭＰＥＧ−２ストリームから対応するＥＣＭを抽出し、エンドユーザの「ドーター」スマートカード４８に該ＥＣＭを渡す。これは受信機／デコーダ１３内のハウジングに組み込まれる。ドータースマートカード４８は、エンドユーザがＥＣＭを復号化し、番組にアクセスする権利を有するかどうかを制御する。ない場合には、否定的なステータスは受信機／デコーダ１３に渡され、番組をデスクランブルできないことを示す。エンドユーザが権利を有する場合には、ＥＣＭは復号化され、コントロールワードが抽出される。デコーダ１３は、それからこのコントロールワードを使用して番組をデスクランブルする。ＭＰＥＧ−２ストリームは解凍され、テレビ受像機１４に対する前進伝送のためにビデオ信号に変換される。

番組がスクランブルされていない場合、ＥＣＭはＭＰＥＧ−２ストリームとともに送信されず、受信機／デコーダ１３はデータを解凍し、テレビ受像機１４への伝送のために信号をビデオ信号に変換する。

加入者管理システム（ＳＭＳ）３０は、とりわけエンドユーザファイル、（料金表及び宣伝などの）商業的なオファー、加入、ＰＰＶ詳細、及びエンドユーザの消費と許可に関するデータを管理するデータベース５２を含んでいる。ＳＭＳはＳＡＳから物理的に遠くてよい。

ＳＭＳ ３２は、エンドユーザに送信されるエンタイトルメント管理メッセージ（ＥＭＭ）に対する修正またはその作成を暗示するＳＡＳ ３０にメッセージを送信する。ＳＭＳ ３２は、ＥＭＭの修正や作成を暗示しないが、（製品を注文するときにエンドユーザに付与される許可、またはエンドユーザが請求される金額に関する）エンドユーザの状態の変更だけを暗示するＳＡＳ ３０にもメッセージを送信する。ＳＡＳ ３０は（通常、コールバック情報または料金請求書作成発行情報などの情報を要求する）メッセージもＳＭＳ ３２に送信し、その結果２つの間の通信が双方向であることは明らかになるだろう。

エンタイトルメント管理メッセージ（ＥＭＭ）
１つのスクランブルされた番組だけ、あるいは同じ商業的なオファーの一部の場合スクランブルされた番組の集合専用であるＥＣＭとは対照的に、ＥＭＭは、個別エンドユーザ（加入者）専用、またはエンドユーザのグループだけに対するメッセージである。

多様な特定のタイプのＥＭＭが考えられる。ここのＥＭＭはここの加入者専用であり、通常はペイパービューサービスの提供で使用される。これらはグループ識別子及びそのグループ内での加入者の位置を含んでいる。いわゆる「グループ」加入ＥＭＭは、例えば２５６人の個人ユーザのグループ専用であり、通常、いくつかの加入サービスの管理に使用される。視聴者ＥＭＭは視聴者全体専用である。「視聴者」とは同じオペレータ識別子（ＯＰＩ）が付いたスマートカードを持つ加入者の全体のことである。最後に「固有の」ＥＭＭはスマートカードの固有の識別子にアドレス指定されている。

好適実施形態で使用されるＥＭＭの一般的な形式を、ここで図３に関して説明する。基本的には、一連のデジタルデータビットとして実現されるＥＭＭは、ヘッダ６０、ＥＭＭプロパー（ｐｒｏｐｅｒ）６２、及びシグネチャ６４を備える。ヘッダ６０は、代わりにＥＭＭの種類を識別するためのタイプ識別子６６、ＥＭＭの長さを示す長さ識別子６８、ＥＭＭのためのオプションのアドレス７０、オペレータ識別子７２、及びキー識別子７４を備える。最後に、やはりオプションであるシグネチャ６４がＥＭＭの中に残っているデータの破壊に対するチェックの数を提供する。ヘッダの中のタイプ識別子はメッセージをＥＭＭとして識別する。

加入者許可システム（ＳＡＳ）
ＳＭＳ ３２によって作成されるメッセージは、リンケージ３４を介して、代わりにＳＭＳ ３２によって作成されるメッセージの受信を肯定応答するメッセージを作成し、これらの肯定応答をＳＭＳ ３２に渡す加入者管理システム（ＳＡＳ）３０に渡される。ＳＡＳに渡されてよいメッセージには、例えば未払いのための加入者差し止め、例えば特定の商業的なオファーを追加または削除するための加入者修正があり、例えばＰＰＶモードでの特定のイベントなどの権利を提供する。

ＳＡＳ ３０はＳＭＳ ３２によって宣言される全加入者のステータスを記憶するデータベースを管理する。ステータス及びＳＭＳによって送信される多様なメッセージに従って、ＳＡＳは加入者のスマートカードのためのＥＭＭを作成する。該ＥＭＭはＳＡＳ暗号装置３６によって暗号にされ、マルチプレクサ４に送信される。ＥＭＭが加入者によって受信されることを確実にするために、ＳＡＳはこれらのメッセージを周期的に送信する。サイクルは、ＥＭＭのタイプによるが、通常３０秒と３０分の間である。

ＳＡＳ ３０の通常の構成が図４に図示されている。概要では、ＳＡＳ ３０は、加入モードに対する権利を与え、毎月自動的に該権利を更新するための加入チェーン領域１００、ＰＰＶイベントの権利を与えるためのペイパービュー（ＰＰＶ）チェーン領域１０２、及び加入チェーン領域及びＰＰＶチェーン領域によって作成されるＥＭＭをマルチプレクサとスクランブラ４に渡し、したがってＭＰＥＧストリームにＥＭＭを供給するためのＥＭＭインジェクタ１０４を備えている。コンピュータソフトウェアをユーザのパーソナルコンピュータにダウンロードするケースでのペイパーファイル（ＰＰＦ）権利などの他の権利が許可される場合には、他の類似する領域も提供される。

ＳＡＳ ３０の１つの機能とは、加入モードで商業的なオファーとして入手可能である、あるいはさまざまな商業化のモード（予約モード、インパルスモード）に従ってＰＰＶイベントとして販売されるテレビ番組に対するアクセス権を管理することである。ＳＡＳ ３０は、それらの権利とＳＭＳ ３２から受信される情報に従って、加入者にＥＭＭを作成する。

加入チェーン領域１００は、コマンドインタフェース（ＣＩ）１０６、加入者技術管理（ＳＡＴＭ）サーバ１０８、メッセージジェネレータ（ＭＧ）１１０、及び暗号装置３６を備える。ＰＰＶチェーン領域１０２は、許可サーバ（ＡＳ）１１２、エンドユーザの関連する詳細を記憶するためのリレーショナルデータベースを含むデータベースサーバ１１４、１１６、注文集中サーバ（ＯＣＳ）１１８、番組放送局用サーバ（ＳＰＢ）１２０、その機能が基本的に加入チェーン領域のものと同じであるメッセージジェネレータ（ＭＧ）１２２、及び暗号装置３６を備える。

ＥＭＭインジェクタ１０４は複数のメッセージエミッタ（ＭＥ）１２４、１２６、１２８及び１３０、及びソフトウェアマルチプレクサ（ＳＭＵＸ）１３２と１３４を備える。好適実施形態においては、メッセージジェネレータ１３２用に２つのＭＥ、１２４と１２６があり、メッセージジェネレータ１３４用には他の２つのＭＥ、１２８と１３０がある。ＭＥ １２４と１２６はＳＭＵＸ １３２と接続されるが、ＭＥ １２８と１３０はＳＭＵＸ １３４に接続される。

メッセージジェネレータ１１０と１２２は、それぞれＳＴＭ １０８及びＯＣＳ １１８によって発行されるコマンドをＥＭＭに変換する。ＭＧはＥＭＭの期間とエミッションの率を決定する。ＭＧは、専用の暗号装置を使用してＥＭＭも暗号にする。それらは、次に暗号にしたＥＭＭを、ＥＭＭを周期的に送信するそれぞれのＭＥに渡す。図４に図示されるように、単一のＭＧに複数のＭＥを接続することができ、適切なＭＥはＥＭＭの中で参照されるオペレータに従ってＭＧによって決定される。指定されたＥＭＭの有効期間中、ＭＧは独自のデータベースの中にそれを記憶する。ＥＭＭは、そのエミッション期間が期限切れになるとすぐにデータベースから消去される。このデータベースは、ＭＧとＭＥの一貫性を確実にする。

メッセージエミッタ１２４、１２６、１２８、１３０は、それぞれのＭＧから放送開始日、放送停止日、及び放送サイクルなどの複数のパラメータとともにＥＭＭを受信する。それから、ＭＧは指定されたパラメータに従ってＥＭＭの一斉送信を管理する。

受信機／デコーダ
図５を参照すると、受信機／デコーダ１３の多様な要素をここで機能ブロックという点で説明する。

例えばデジタルセットトップボックス（ＳＴＢ）であってよい受信機／デコーダは、関連付けられたメモリ素子を含み、シリアルインタフェース２２１、パラレルインタフェース２２２、（図１のモデムバックチャネル１７に接続される）モデム２２３から入力データを受信するように適応された中央処理装置２２０、及びデコーダのフロントパネル上のスイッチ接点２２４を備える。

受信機／デコーダは、さらに、赤外線リモコン２２５からコントロールユニット２２６を介して入力を受信するように適応され、それぞれ銀行スマートカードと加入スマートカード２４２、２４０を読み取るように適応される２台のスマートカード読取装置２２７、２２８も所有している。加入スマートカード読取装置２２８は挿入された加入カード２４０と、及び条件付きアクセス装置２２９と係合し、必要なコントロールワードをデマルチプレクサ／デスクランブラ／リマルチプレクサ装置２３０に供給し、暗号化された放送信号をデスクランブルできるようにする。デコーダは、装置２３０によってフィルタリングされ、逆多重化される前に衛星伝送を受信、復調するために従来のチューナ２３１と復調器２３２も含む。

本説明で使用されるように、好ましくはアプリケーションは、好ましくは受信機／デコーダ１３の高水準機能を制御する１個のコンピュータコードである。例えば、エンドユーザがリモコン２２５のフォーカスをテレビ受像機１４の画面に表示されるボタンオブジェクトの上に配置し、確証キーを押すと、該ボタンに関連付けられる命令シーケンスが実行される。

対話型アプリケーションはメニューを提案し、エンドユーザの要求によりコマンドを実行し、アプリケーションの目的に関するデータを提供する。アプリケーションは、常駐アプリケーション、つまり受信機／デコーダ２０００のＲＯＭ（またはＦＬＡＳＨまたは他の不揮発性メモリ）に記憶されているか、あるいは受信機／デコーダ２０００のＲＡＭ、またはＦＬＡＳＨメモリに一斉送信され、ダウンロードされてよい。

アプリケーションは受信機／デコーダ１３の中のメモリロケーションに記憶され、リソースファイルとして表現される。該リソースファイルは、前述された特許明細書に詳細に説明されるように、グラフィックオブジェクト記述単位ファイル、変数ブロック単位ファイル、命令シーケンスファイル、アプリケーションファイル、及びデータファイルを備える。

受信機／デコーダは、ＲＡＭボリューム、ＦＬＡＳＨボリューム及びＲＯＭボリュームに分割されるメモリを含むが、この物理的な編成は論理的な編成とは異なる。メモリは、多様なインタフェースと関連付けられるメモリボリュームにさらに分割されてよい。ある視点からは、メモリはハードウェアの一部と見なすことができる。別の視点からは、メモリは、ハードウェアの他に示されるシステムの全体をサポートする、または含むと見なすことができる。

受信機／デコーダのアーキテクチャ
受信機／デコーダは、ソフトウェアを受信機／デコーダの中で、及び任意のオペレーティングシステムとともに実現できるように編成される５つのソフトウェア層を含む。図６を参照すると、多様なソフトウェア層とはアプリケーション層２５０、アプリケーションプログラミングインタフェース（ＡＰＩ）層２５２、仮想機械層２５４、デバイス層２５６、及びシステムソフトウェア／ハードウェア層２５８である。

アプリケーション層２５０は受信機／デコーダに常駐しているか、あるいはダウンロードされるアプリケーションを包含する。それらはカスタマによって使用され、例えばＪａｖａ（登録商標）、ＨＴＭＬ、ＭＨＥＧ−５または他の言語によって作成される対話型アプリケーションであってよいか、あるいはそれらはこのような対話型アプリケーションを実行するために受信機／デコーダによって使用されるアプリケーションであってよい。この層は、仮想機械層によって提供されるオープンなアプリケーションプログラミングインタフェース（ＡＰＩ）の集合に基づいている。このシステムによって、進行中にあるいはオンデマンドで、アプリケーションを受信機／デコーダのフラッシュメモリ、またはＲＡＭメモリにダウンロードできる。アプリケーションコードは、データストレージメディアコマンドアンドコントロール（Ｄａｔａ Ｓｔｏｒａｇｅ Ｍｅｄｉａ Ｃｏｍｍａｎｄ Ａｎｄ Ｃｏｎｔｒｏｌ）（ＤＳＭＣＣ）、ネットワークファイルサーバ（Ｎｅｔｗｏｒｋ Ｆｉｌｅ Ｓｅｒｖｅｒ）（ＮＦＳ）または他のプロトコルなどのプロトコルを使用して圧縮フォーマットまたは未圧縮フォーマットで送信できる。

対話型アプリケーションは、ユーザが、例えば電子番組表、テレバンキングアプリケーション及びゲームなどの製品とサービスを獲得するために対話するアプリケーションである。次に示す常駐アプリケーションが、対話型アプリケーションを管理するために使用される。

・ブート。ブートアプリケーション２６０は受信機／デコーダの電源が投入されたときに起動される最初のアプリケーションである。ブートアプリケーションは仮想機械の中でさまざまな「マネージャ」を起動し、最初がアプリケーションマネージャ２６２である。

・アプリケーションマネージャ。アプリケーションマネージャ２６２は、受信機／デコーダ内で実行する対話型アプリケーションを管理する。すなわち、それはイベントを起動、停止、中断、再開、処理し、アプリケーション間の通信に対処する。それは複数のアプリケーションを一度に実行できるようにし、したがってそれらの間でのリソースの割り当てに関与している。このアプリケーションはユーザにとって完全にトランスペアレントである。

・セットアップ（ＳＥＴＵＰ）。セットアップアプリケーション２６４の目的は、受信機／デコーダを、おもに初めてそれが使用されるときに構成することである。それは、テレビチャネルの走査、日付と時刻の設定、ユーザ優先順位の確立等のアクションを実行する。しかし、セットアップアプリケーションは、受信機／デコーダの構成を変更するためにユーザがいつでも使用できる。

・ザッピング。ザッピングアプリケーション２６８はＰｒｏｇｒａｍ−ｕｐキー、Ｐｒｏｇｒａｍ−ｄｏｗｎキー、及び数値キーを使用してチャネルを変更するために使用される。例えばバナー（パイロット）アプリケーションを通してなど、別の形式のザッピングが使用されるとき、ザッピングアプリケーションは停止される。

・コールバック。コールバックアプリケーションは、受信機／デコーダのメモリに記憶されている多様なパラメータの値を抽出し、これらの値をモデム付きバックチャネル１７を介して、あるいは他の手段によって戻すために使用される。

ＡＰＩ層２５２は対話型アプリケーション開発に高水準のユーティリティを与える。それは、この高水準ＡＰＩを構成する複数のパッケージを含む。該パッケージは対話型アプリケーションを実行するために必要なすべての機能性を提供する。パッケージはアプリケーションによってアクセス可能である。

好適実施形態においては、ＡＰＩはＪａｖａ（登録商標）で作成されるアプリケーションに適応されている。さらに、それはＨＴＭＬ、及びＭＨＥＧ-５などの他のフォーマットを解釈できる。これらのインタプリタに加えて、それは、要件が決定つけるように分離可能且つ拡張可能である他のパッケージ及びサービスモジュールも含む。

仮想機械層２５４は、言語インタプリタ及び多様なモジュールとシステムから構成される。それは、対話型アプリケーションを受信機／デコーダで受信、実行するために必要なあらゆるものから構成される。

デバイスインタフェース層２５６は、デバイスマネージャとデバイスを含む。デバイスは外部イベントと物理インタフェースの管理に必要な論理リソースから構成されるソフトウェアモジュールである。デバイス層はドライバとアプリケーション間の通信チャネルを管理し、強化されたエラー例外チェックを提供する。管理されているデバイスのいくつかの例は、カード読取装置、モデム、ネットワーク、ＰＣＭＣＩＡ（ＰＣメモリカード国際協会）、ＬＥＤディスプレイ等である。ＡＰＩ層が上からデバイスを制御するため、プログラマがこの層に直接的に処理する必要はない。

システムソフトウェア／ハードウェア層２５８は、受信機／デコーダのメーカによって提供される。システムのモジュール方式のため、及び（イベントスケジューリング及びメモリ管理などの）ＯＳによって供給されるサービスが仮想機械の一部であるため、さらに高い層は特定のリアルタイムオペレーティングシステム（ＲＴＯＳ）または特定のプロセッサに結び付けられていない。

ＭＰＥＧシステム
従来のデジタルテレビ放送システムは、離散トランスポートストリームパケットまたはトランスポートパケットの形でデータを送信し、各パケットは所定の長さであり、ヘッダと本体を含む。ＭＰＥＧ規格はこのドメインで現在好まれている規格であり、とりわけこのようなパケットの所定のフォーマットである。

パケットヘッダはパケットに関する一般的な記述データを備えるが、本体は受信機／デコーダで処理されるデータを備える。パケットヘッダは、少なくともパケットを識別するパケットＩＤつまりＰＩＤを含む。パケットの本体は、アプリケーションデータ、または特に条件付きアクセスシステムデータなどの音声データ、ビデオデータ、または他のデータを含んでよい。

従来、入信データストリームは、各パケットのＰＩＤに従って受信機／デコーダによってフィルタリングされる。音声データまたは画像データなどの即時処理を必要とするデータは、従来パケット化された流線、つまりＰＥＳとして従来既知であるものの形で適切なプロセッサに通信される。トランスポートパケットの本体をアセンブルすることにより形成されるこの連続的なデータの流れは、それ自体パケットのシーケンスを備え、各パケットはパケットヘッダ及び本体を備える。

即時処理を必要としない他のデータもトランスポートパケットの本体の中でカプセル化されてよい。リアルタイム出力を作成するためにプロセッサによってただちに処理されるＰＥＳデータとは異なり、この種のデータは通常受信機／デコーダプロセッサによって非同期で処理される。このケースでは、データは単一のテーブルまたはそれぞれがヘッダと本体を含む、テーブルの一連のセクションでフォーマットされ、セクションまたはテーブルのヘッダはテーブルＩＤつまりＴＩＤを含む。

従来のＭＰＥＧデータストリームの多様な態様は、ここで本願に引用して援用するＷＯ第９８／４３４３１号にも記載される図７Ａ、図７Ｂ、及び図７Ｃに関して説明される。

図７Ａを参照すると、既知のように、ＭＰＥＧ−２ビットストリームは、ゼロのパケット識別（「ＰＩＤ」）を有する番組アクセステーブル（「ＰＡＴ」）３１０を含む。ＰＡＴは、多くの番組の番組マップテーブル（「ＰＭＴ」）３１２のＰＩＤに対する参照を含む。各ＰＭＴは、その番組の音声ＭＰＥＧテーブル３１４とビデオＭＰＥＧテーブル３１６のストリームのＰＩＤに対する参照を含む。番組アクセステーブル３１０であるゼロのＰＩＤを有するパケットは、すべてのＭＰＥＧアクセスにエントリポイントを提供する。

アプリケーション及びそれらのデータをダウンロードするために、２つの新しいストリームタイプが定義され、関連するＰＭＴは、アプリケーションテーブル３１８（またはそれらのセクション）とデータＭＰＥＧテーブル３２０（またはそれらのセクション）のストリームのＰＩＤに対する参照も含む。

図７Ｂを参照すると、アプリケーション３２２をダウンロードするために、アプリケーションは、そのいくつかが単一のセクション３１８によって構成され、その他が複数のセクション３１８によって構成されてよい、それぞれがＭＰＥＧテーブルによって形成されるモジュール３２４に分割される。典型的なセクション３１８は、１バイトのテーブル識別（「ＴＩＤ」）３２８を含むヘッダ３２６、テーブル内のそのセクションのセクション番号３３０、そのテーブル内のセクションの総数３３２、及び２バイトのＴＩＤ拡張３３４を有する。各セッションはデータ部３３６とＣＦＣ ３３８も含む。ある特定のモジュール／テーブル３２４の場合、そのテーブル３２４を構成するセクション３１８のすべてが同じＴＩＤ３２８と同じＴＩＤ拡張３３４を有する。ある特定のアプリケーション３２２の場合、そのアプリケーション３２２を構成するテーブル３２４のすべては同じＴＩＤ３２８であるが、異なるそれぞれのＴＩＤ拡張を有する。

アプリケーション３２２ごとに、ディレクトリとして使用され、図７Ｃにさらに詳細に図示される単一のこのようなＭＰＥＧテーブル３２４がある。ディレクトリテーブル３４０はヘッダ３２６、ディレクトリ部３４２、キー識別３４４、暗号化されたシグネチャ３４６、及びＣＲＣ ３３８を含む。前記から、ディレクトリテーブル３４０が、そのヘッダ３２６の中にアプリケーションを構成する他のモジュール／テーブル３２４と同じＴＩＤ３２８を有することが理解されるだろう。しかしながら、ディレクトリテーブルは、ゼロという所定のＴＩＤ拡張３３４を有し、他のモジュール３２４のすべては非ゼロＴＩＤ拡張を有する。ヘッダは、ディレクトリテーブル３４０のバージョン番号３４８も含む。ディレクトリ部３４２は、アプリケーション３３２を構成する他のモジュール／テーブル３２４のそれぞれに、そのモジュールの名称３５０、そのモジュールのＴＩＤ拡張３３４、及びそのモジュールのシグネチャ３５２を含む。ディレクトリ部３４２は、他のモジュール／テーブル３２４のそれぞれに、そのモジュールの長さとそのモジュールのバージョン番号も含んでよい。

図７Ａを参照し直すと、動作中、ＰＡＴ ３１０、ＰＭＰ ３１２及びアプリケーションとデータストリーム構成要素３１８,３２０が周期的に伝送され、必要に応じて更新される。送信される各アプリケーションは、それぞれの所定のＴＩＤ ３２８を有する。アプリケーションをダウンロードするために、適切なＴＩＤとゼロというＴＩＤ拡張を有するＭＰＥＧテーブルは受信機／デコーダ１３にダウンロードされる。したがって、これは必要とされるアプリケーションのディレクトリテーブル４０である。次に、ディレクトリ内のデータは、必要とされるアプリケーションを構成するモジュールテーブルのＴＩＤ拡張３３４を求めるために受信機／デコーダ１３によって処理され、それからディレクトリテーブルと同じＴＩＤ及びディレクトリから求められたＴＩＤ拡張を有する任意の必要とされるモジュールテーブルをダウンロードできる。

受信機／デコーダ１３は、その更新のためにディレクトリテーブルをチェックするように装置される。これは、例えば３０秒、または１分または５分ごとなど再び周期的にディレクトリテーブルをダウンロードし、新たにダウンロードされるディレクトリテーブルのバージョン番号を前にダウンロードされたディレクトリテーブルのバージョン番号と比較することによって達成されてよい。新たにダウンロードされたバージョン番号が未定である場合、過去のディレクトリテーブルに関連付けられたモジュール、または後のバージョン番号があるこのようなモデルはマウントされておらず、後のモジュールがダウンロードされ、マウントされる。代替の装置では、入信ビットストリームがＴＩＤ、ＴＩＤ拡張及びバージョン番号に対応するマスクを使用してフィルタリングされ、値がアプリケーションのＴＩＤ、ゼロというＴＩＤ拡張、及び現在ダウンロードされたディレクトリのバージョン番号より１大きなバージョン番号に設定される。したがって、バージョン番号の増分を検出することができ、前述されたように、いったん検出されたディレクトリがダウンロードされ、アプリケーションが更新される。このようなフィルタリングの追加の説明は特許出願ＷＯ第９８/４３４１５号に記載されている。アプリケーションを終了する場合には、次のバージョン番号が付いた空のディレクトリが送信されるが、ディレクトリにリストされているモジュールはない。このような空のディレクトリの受信に応えて、受信機／デコーダ１３はアプリケーションをアンマウントするようにプログラミングされる。

例えばペイテレビシステムにおいてなど、伝送に対するアクセスが制限されなければならないケースでは、条件付きアクセスデータが伝送とともにトランスポートストリームの中で一斉送信されるテーブルまたはセクションに含まれてよい。この条件付きアクセスデータはデコーダによってフィルタリングされ、デコーダに差し込まれているスマートカードなどの携帯セキュリティモジュールに渡される。それから、データは、例えば伝送をデスクランブルするためにデコーダによって後に使用されるコントロールワードを生成するために、スマートカードによって処理される。

１つの問題は、デコーダによって受信、処理されるデータのボリューム、特にセキュリティモジュールに最終的に転送される条件付きアクセスデータのボリュームにある。特に、セキュリティモジュールプロセッサの処理機能及びデコーダとセキュリティモジュール間の通信チャネルの容量は指定される量のメッセージを処理するには不十分である可能性がある。この問題は、番組が、さまざまなオペレータが同じ番組（例えば、サッカーの試合または主題テレビチャネル）にアクセスできるようにする複数の条件付きアクセスメッセージとともに送信される傾向が強まることによって悪化する。したがって、やがて、一斉送信される情報を減らす、あるいは少なくともさらによく管理する方法が調査されるだろう。

プライベートＭＰＥＧテーブルセクションは表１に示されている。このフォーマットは、未処理のデータをＭＰＥＧセクションに変換するために固有に使用される。セクションの最大数はＳｅｃｔｉｏｎ＿Ｓｙｎｔａｘ＿Ｉｎｄｉｃａｔｏｒに依存している。

表１は、ＩＦ／ＥＬＳＥ構文によって表現される変形データ構造として、長いテーブルデータ構造と短いテーブルセクション構造の両方を表している。言い換えると、Ｓｅｃｔｉｏｎ＿Ｓｙｎｔａｘ＿Ｉｎｄｉｃａｔｏｒが０に等しい場合には、表は短いテーブルデータ構造を有し、それ以外の場合、テーブルは長いテーブルデータ構造を有するだろう。短いテーブルは、単一のセクションだけで構成されているが、長いテーブルは複数のセクションから構成されてよい。

後述される本発明の２つの実施形態においては、構造化された情報が、長いテーブルセクションデータ構造と短いテーブルセクションデータ構造の両方の未処理データ部分を置換し、両方の新しいデータフォーマットを生じさせる。未処理データ部分は、Ｐｒｉｖａｔｅ＿Ｄａｔａ＿Ｔｙｐｅフィールドのループによって表１に表現されており、セクション本体とも呼ばれるだろう。これらの実施形態の構造は、図８に一般的なデータ構造として図示される。

データ構造は従来のＭＰＥＧプライベートテーブルセクションヘッダ４００を備える。従来のヘッダ４００のＴａｂｌｅ＿ｉｄ＿ｅｘｔｅｎｓｉｏｎフィールド４０２は、アプリケーションに特殊なフィルタリング機能を提供するためにいくつかの実施形態で使用される。例えば、それはハードウェアフィルタリングを使用してそのコンテンツの高速検索を可能にするためにテーブルコンテンツの識別子として使用されてよい。従来のＣＲＣ情報４２０が保持される。

標準ＭＰＥＧプライベートデータセクションの未処理データ部分（つまり本体）は、追加のヘッダフィールド、さらに構造化されたデータ部分を備える追加ヘッダ４０４によって置換される。追加ヘッダ４０４の中の追加のヘッダフィールドはテーブルの圧縮と暗号化、優先順位、構文解析フォーマット及びフィルタ拡張フィールドに関する情報を含む。それらは、共通属性リスト４０８のサイズを指定するフィールドも含む。共通属性リスト４０８はデータ項目リスト４１０の中の全データ項目４１２に共通である属性４０６を備える。構造化されたデータ部分は、さらにデータ項目４１２の可変長リスト４１０を備え、それぞれが汎用データ項目識別子と、そのデータ項目に特定の属性４１６の可変長リスト４１４を含む。特定的な属性リスト４１４の長さはデータ項目４１２で指定される。項目に特定的な属性リスト４１４の中の属性は共通属性リスト４０８の中の同じ共通属性４０６を無効にしてよい。

この構造により、全データ項目に共通の属性を一度だけ含むことができる。さらにいくつかのデータ項目に共通の属性は共通属性リストに表示されてよく、それらのデータ項目は特定の属性を無効にすることを含む、これらの共通属性にとって異なる値を備えている。これにより、フォーマットされたデータによって必要とされる空間を最小限に保つことができる。

属性は、以下においてＭＰＥＧ規格用語に基づいて記述子とも呼ばれるだろう。ループコンストラクトが後述される特定のテーブルフォーマット定義のリストを定義する上で形式論として使用されるため、リストは同様にループとも呼ばれるだろう。したがって、属性リスト４０８と４１４は、それぞれ記述子ループまたは共通及び特定記述子ループとも呼ばれるだろう。ループ４１０は識別子ループとも呼ばれるだろう。

特定的な例は、データ構造要素のどれかに特定的な名称を与えてもよい。

記述子は本来表現される属性に応じた任意のデータ構造であってよい。好ましくは、それは記述子の自動的な構文解析を可能にするために記述子タグ及び記述子サイズを含む簡略なヘッダを含むだろう。

構造化されたデータだけではなく追加ヘッダを表１の既存のテーブル構造の未処理データ部分または本体の中でカプセル化することによって、既存の構造との互換性が維持される。これは、既存のＭＰＥＧテーブル処理ハードウェア及びソフトウェアとの互換性も提供する。

プライベートテーブルセクションは、通常、情報が前述された構造に従ってフォーマットされる放送センタで生成される。データ構造は、放送センタのメモリでいったんアセンブルされると、それらはＭＰＥＧストリームの中に挿入され、受信機／デコーダに一斉送信される。それから、受信機／デコーダはＭＰＥＧストリームから情報を検索し、後述されるようにそれらを追加処理のために構文解析ツールに渡す前にそのメモリ内でデータ構造を作り直してよい。

長いプライベートテーブルセクションの特定の例は、以下の表２および表３（なお、表２および表３は一続きのものである。）によって示される。このようなテーブルは最高２５６のセクションから構成されてよい。表はフィールド名、ビット単位のフィールドサイズ、バイナリデータフォーマット及びデフォルト値を示す。バイナリデータフォーマットは、ＭＰＥＧ規格で定義されるニーモニックを使用して示される。

セクションの最大数：２５６
各セクションの最大サイズ：４０９８

ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒとＣＲＣ＿３２の間であるが、それらを除くフィールドが、表１の既存のテーブルフォーマットの未処理のフォーマットされていないデータ構造を置換する。新しいフィールドが、予約されているフィールドという例外とともにここで説明される。

Ｐｒｉｖａｔｅ＿Ｆｉｌｔｅｒ＿ｅｘｔｅｎｓｉｏｎ：ハードウェアフィルタの使用を最適化するために、この１６ビットのフィールドは、例えばＭＬＯＡＤ＿ｔａｂｌｅ呼び出し、ＭＬＯＡＤ＿ｇｒｏｕｐ呼び出し、及びＭＬＯＡＤ＿ｓｅｃｔｉｏｎ呼び出しを用いてハードウェアフィルタリングが実行されるヘッダの部分に追加基準を含むことによってプライベートフィルタリングを拡張するために使用されてよい。

Ｄａｔａ＿Ｐａｒｓｉｎｇ＿Ｆｏｒｍａｔ：この８ビットフィールドは、テーブルの中の以下のデータのデータ構文解析フォーマットを示す。これは、以下のデータが将来のバージョンで変更される場合に自動構文解析を補助する。このフィールドは、２５６を超える構文解析フォーマットが必要とされる場合に、２５６を法としてテーブルフォーマットバージョン番号に同等であるとして解釈できる。その場合、構文解析フォーマットを指定する目的で追加のヘッダフィールドが新しいテーブルフォーマットで導入されてよい。

Ｄａｔａ＿Ｃｙｐｈｅｒｅｄ＿ｆｌａｇ：このフラグは、データ部分または本文中のデータ、すなわち追加ヘッダとＣＲＣ＿３２フィールドの間であるがそれらを含まないデータが暗号化されているかどうかを示す。データが暗号化されている場合には、暗号アルゴリズムの選択がＤａｔａ＿Ｃｙｐｈｅｒｉｎｇ＿Ａｌｇｏｒｉｔｈｍフィールドを用いて行われる。

Ｄａｔａ＿Ｃｏｍｐｒｅｓｓｅｄ＿ｆｌａｇ：このフラグは、データ部分または本文中のデータ、すなわち追加ヘッダとＣＲＣ＿３２フィールドの間であるがそれらを含まないデータが圧縮されているかどうかを示す。データが圧縮されている場合には、圧縮アルゴリズムの選択がＤａｔａ＿Ｃｏｍｐｒｅｓｓｉｎｇ＿Ａｌｇｏｒｉｔｈｍフィールドを用いて行われる。

Ｄａｔａ＿Ｃｙｐｈｅｒｅｄ＿ＦｌａｇとＤａｔａ＿Ｃｏｍｐｒｅｓｓｅｄ＿Ｆｌａｇの両方ともセットされている場合には、暗号化はデータの圧縮後に実行される。受信側では、受信機／デコーダ１３が解凍の前に解読する。

Ｄａｔａ＿Ｃｙｐｈｅｒｉｎｇ＿Ａｌｇｏｒｉｔｈｍ：この２ビットフィールドは、４つの異なるアルゴリズムの１つをセクション本体のデータの暗号化／解読で使用するために指定できるようにする。

Ｄａｔａ＿Ｃｏｍｐｒｅｓｓｉｎｇ＿Ａｌｇｏｒｉｔｈｍ：この２ビットフィールドは、４つの異なるアルゴリズムの１つをセクション本体のデータの圧縮に指定できるようにする。

Ｐｒｉｏｒｉｔｙ：優先順位レベルをプライベートデータと関連付けることができるようにするこの２ビットフィールドで４つの優先順位レベルの１つが指定されてよい。値０は最高の優先順位レベルを表し、３が最低の優先順位レベルを表す。

Ｃｏｍｍｏｎ＿Ｄｅｓｃｒｉｐｔｏｒ＿ｉｎｆｏ＿ｌｅｎｇｈｔ：これは、（要素の数も長さを指定するために使用できるが）バイト単位のサイズとして以下の共通記述子リストの長さを指定する。

記述子リスト：これは記述子要素のリストである。記述子要素は変化する内部構造であってよく、データ要素属性を表す。リストはループ構成によって表２に表示されている。

付加的な識別子リスト：このリストはループ構成によって表２および表３に表されている。このリストはゼロまたは複数の付加的な識別子を含んでよく、それぞれが記述子リストを備える。付加的な識別子の各要素は以下のフィールドを備える。

Ｅｘｔｒａ＿Ｉｄｅｎｔｉｆｉｅｒ＿Ｌｅｎｇｔｈ：この８ビットフィールドは、可変長Ｅｘｔｒａ＿ｉｄｅｎｔｉｆｉｅｒフィールドに使用されるバイトの数（Ｎ）を指定する。

Ｅｘｔｒａ＿ｉｄｅｎｔｉｆｉｅｒ：この８^＊Ｎビットフィールドは、続く付加的な識別子記述子ループを記述する識別子または識別子のグループを指定する。

付加的な識別子記述子ループ：これは記述子要素のリストである。記述子要素は変化する内部構造であってよく、データ要素属性を表す。このリストはループ構成によって表２および表３に表されている。

前記表１では、フィールドｐｒｉｖａｔｅ＿ｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈが、次のフィールドからセクションの最後までのプライベートセクションの残りの部分のサイズを指定している。同じ機能は表２のＳｅｃｔｉｏｎ＿ｌｅｎｇｔｈフィールドによって実行される。表２および表３においては、(記述子の数も使用できるだろうが、バイト単位のサイズとしての)２つの記述子ループの長さが、さらにフィールドＣｏｍｍｏｎ＿Ｄｅｓｃｒｉｐｔｏｒ＿ｉｎｆｏ＿ｌｅｎｇｔｈ(デフォルト値Ｎ１)とＥｘｔｒａ＿Ｉｄｅｎｔｉｆｉｅｒ＿ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈ（デフォルト値Ｎ３）によって指定される。

短いプライベートテーブルの形を取る実施形態が以下の表４および表５（なお、表４および表５は一続きのものである。）に示されている。短いプライベートテーブルは、ただ１つのセクションだけから構成される。

最大セクション数： １
各セクションの最大サイズ： ４０９６

Ｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈとＣＲＣ＿３２の間であるがそれらを含まないフィールドは、既存のテーブルフォーマットの未処理のフォーマットされていないデータ部分―本体―を置換する。新しいフィールドが、予約フィールドの例外及び表２および表３に関して前述されたフィールドとともにここで説明される。

Ｐｒｉｖａｔｅ＿Ｆｉｌｔｅｒ＿Ｅｘｔｅｎｓｉｏｎ：ハードウェアフィルタの使用を最適化するために、この５６ビットのフィールドは、ハードウェアフィルタリングがＭＬＯＡＤ＿ｔａｂｌｅ呼び出し、ＭＬＯＡＤ＿ｇｒｏｕｐ呼び出しまたはＭＬＯＡＤ＿ｓｅｃｔｉｏｎ呼び出しを用いて実行されるヘッダの部分に追加の基準を含めることによってプライベートフィルタリングを拡張するために使用されてよい。このフィルタ拡張フィールドは、短長（ｓｈｏｒｔ ｌｏｎｇ）フォーマット（表２および表３を参照のこと）の同等なフィールドより長い。これは、両方のフォーマットのヘッダを等しいサイズにし、テーブルの構文解析をさらに容易にするためである。

Ｐｒｉｏｒｉｔｙ：４つの優先順位レベルの１つがこの２ビットフィールドに指定されてよく、優先順位レベルをプライベートデータに関連付けることができるようにする。値０は最高の優先順位レベルを表し、値３が最低の優先順位レベルを表す。

Ｃｏｍｍｏｎ＿Ｄｅｓｃｒｉｐｔｏｒ＿ｉｎｆｏ＿ｌｅｎｇｔｈ：（長さを指定するためには、要素数も使用できるだろうが）これはバイト単位でのサイズとして以下の共通記述子リストの長さを指定する。

記述子リスト：これは記述子要素のリストである。記述子要素は変化する内部構造であってよく、データ要素属性を表す。リストは、ループ構成によって表４および表５に表されている。

付加的な識別子リスト：このリストは、ループ構成によって表４および表５に表されている。このリストはゼロまたは複数の付加的な識別子を含んでよく、それぞれに記述子リストがある。付加的な識別子の各要素は以下のフィールドを備える。

Ｅｘｔｒａ＿Ｉｄｅｎｔｉｆｉｅｒ＿Ｌｅｎｇｔｈ：これは、可変長Ｅｘｔｒａ＿Ｉｄｅｎｔｉｆｉｅｒフィールドのために使用されるバイト数を指定する。

Ｅｘｔｒａ＿Ｉｄｅｎｔｉｆｉｅｒ：これは以下の記述子ループを記述する記述子または記述子のグループを指定する。

付加的な識別子記述子ループ：これは記述子要素のリストである。記述子要素は変化する内部構造であってよく、データ要素を表す。このリストは、ループ構成によって表４および表５に表現される。

長いセクションフォーマットと短いセクションフォーマット両方の前記例は、圧縮と暗号化に関する追加のヘッダフィールドを提供する。これらは、フォーマットされたデータ部分及び追加ヘッダ情報の部分を暗号化する能力と圧縮する能力の両方を提供する。セクション本体の圧縮と暗号化の記述は以下に示される。また、Ｐｉｒｏｒｉｔｙフィールドは、プライベートテーブルセクションに含まれる情報の優先順位付与を可能にするために提供される。

記述されたプライベートテーブルフォーマットは、例えばセットトップボックスに命令を渡すために、ビデオオンデマンドアプリケーションにおいて、あるいは条件付きアクセスシステムにおいてなど多くのさまざまなアプリケーションで使用されてよい。これらの例のいくつかがさらに詳しく後述される。

構文解析ツール
前述された一般的なテーブル構造を解釈するために、構文解析ツールはセットトップボックスのオペレーティングソフトウェアの一部として提供される。定義されたデータ構造が与えられたこのような構文解析ツールの構築は、当業者によって容易に実施できる。したがって、ここではいくつかの基本的な要件だけが概略される。

構文解析ツールの役割は図９に示されている。構文解析ツールを備える構文解析ツール層５０６は、アプリケーション層５０８とＭＰＥＧテーブル受信フィルタリング層５０４の間に、データストリーム５０２を介して放送システム５００によって送信される情報を抽出する抽象化の層を設ける。

この抽象化の効果とは、さまざまなアプリケーションが、それらが処理するさまざまな種類のデータの多数の異なったテーブルフォーマットに特に適応する必要がないという点である。構文解析ツールは受信されたテーブルセクションを処理し、関連する情報を抽出し、それをアプリケーション層のアプリケーションに渡す。

前述された一般的なテーブルフォーマットは、さまざまなタイプのデータを同じテーブル構造の中で編成できるようにする。共通の、及び特定の属性記述子の集合体としてテーブルセクションに記憶される個々のデータ項目は、アプリケーションによって必要とされる情報を含む。記述子フォーマットは変化してよい。例えば、情報のタイプ及びサイズ属性を指定するタグを備える前記の例の簡略なヘッダは、構文解析ツールが情報を正確に抽出し、それをアプリケーションに渡すことができるようにするために設けられている。

さらに、記述子リストのサイズは、構文解析ツールがそれらを正確に抽出できるようにするためにＣｏｍｍｏｎ＿Ｄｅｓｃｒｉｐｔｏｒ＿ｉｎｆｏ＿ｌｅｎｇｔｈフィールドとＥｘｔｒａ＿Ｉｄｅｎｔｉｆｉｅｒ＿ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈフィールドの形で提供される。構文解析ツールはそれ自体を個々のデータ項目の意味または機能と関係させる必要はない。つまり、それは単にデータをアプリケーションに渡すだけである。したがって、構文解析ツールはそれが受信する可能性のある情報のさまざまなタイプを認識する必要はない。情報の解釈はアプリケーションによって実行される。構文解析ツールはヘッダに含まれる伝送関連の情報を単に剥ぎ取り（ＳＴＲＩＰＳ）、テーブルの実際のデータコンテンツを適切で一般的な形式のアプリケーションに渡すにすぎない。

このようにして、構文解析ツールはさまざまなタイプの可変長のテーブルを処理できる。構文解析ツールの設計は、さまざまなアプリケーションによって使用されるさまざまのタイプの情報によってではなく、汎用テーブルの設計によってのみ決定される。

追加のテーブルセクションフォーマットを可能にするために、カレントフォーマットは構文解析フォーマットフィールド（Ｄａｔａ＿Ｐａｒｓｉｎｇ＿Ｆｏｒｍａｔ）を提供する。このフィールドの前のヘッダセクションは、それがプライベートテーブルセクションのフォーマットを決定し、このようにしてそれを構文解析するための適切な戦略を選ぶために使用するフィールドを、構文解析ツールが正しく識別できるようにすべてのテーブルフォーマットにおいて一定のサイズのままとなる。

プライベートテーブルの圧縮及び暗号化
前述されたテーブルフォーマットは、圧縮済みの、及びまたは暗号化済みのプライベートテーブルにも備える。プライベートテーブルの圧縮は、テーブルが、ビデオオンデマンドアプリケーションでの番組カタログなどの大量の情報をトランスポートするために使用されるときに有効である可能性がある。デジタル放送システムは多くの場合高価であるため、必要とされる帯域幅の削減は利益になる場合がある。テーブルに記憶されている情報が、条件付きアクセス情報など機密の性質である場合にはテーブルの暗号化が有効となる可能性がある。

プライベートテーブルの圧縮をここで説明する。

前記に（表２および表３を参照すること）定義された追加ヘッダは２つの圧縮関連フィールドを含む。Ｄａｔａ＿Ｃｏｍｐｒｅｓｓｅｄ＿Ｆｌａｇフラグは、プライベートテーブルセクションの中のデータが圧縮されているかどうかを示すために使用される。さらに、追加ヘッダの中のＤａｔａ＿Ｃｏｍｐｒｅｓｓｉｎｇ＿Ａｌｇｏｒｉｇｈｍフィールドは、圧縮のために使用されるアルゴリズムを指定できるようにする。したがって、システムは同時に多くのさまざまな圧縮アルゴリズムを使用できる。表２および表３に記述される実施形態では、これは２ビットのフィールドである。従って４つのアルゴリズムが指定されてよい。

後述される好適実施形態では、前記に指定されるフィールドを含む追加ヘッダだけではなく標準ヘッダ及びフッタも圧縮されておらず、その結果圧縮されたテーブルは標準ＭＰＥＧハードウェア及びソフトウェアを使用して処理、送信されてよく、その結果受信機はテーブルが圧縮されているかどうか、あるいはそれを圧縮するためにどのアルゴリズムが使用されたのかを判断できる。ＭＰＥＧプライベートテーブルの本体（つまりデータ部分）だけが圧縮される。他の例では、追加ヘッダ内のいくつかのフィールドを含む、追加ヘッダの圧縮関連フィールドとフッタの間（であるがそれらを除く）のすべてが圧縮される。

いくつかの実施形態では、セクション本体は単に個別に圧縮されるにすぎない。その場合、全体としてのテーブルは圧縮後のセクションと同じ数を保持する。

しかしながら、好適実施形態では、すべてのテーブルセクションのセクション本体は、テーブルセクションから抽出され、１つの大きなデータブロックを形成するためにアセンブルされる。元のテーブルセクションを解凍後に作り直すことができるようにするために、ブロックの中の各本体の前にはその長さを指定する指定子が先行する。

次に、それらのそれぞれの長さとともにすべてのセクションを備えるこの即時データブロックが、新しい圧縮されたデータブロックを与えるために圧縮される。したがって、新しいプライベートＭＰＥＧテーブルはこのブロックから、それを多くのセグメントに分けることによって作成され、そのそれぞれは新しいテーブルのセクションの本体に置かれる。これらのフラグとセッション番号とサイズに関するフィールドとは別に、ＭＰＥＧ標準ヘッダ及び追加ヘッダは、それ以外の場合もとのテーブルの中で同じままとなる。したがって、圧縮されたテーブルは元の未圧縮テーブルと同じように処理できる。

送信されるデータの量が圧縮により削減されたため、圧縮済みのテーブルは通常（達成された圧縮率に応じて）もトンテーブルより少ないセクションを含むだろう。

この圧縮済みのプライベートテーブルは次に通常のチャネルを介して送信される。受信時、Ｄａｔａ＿Ｃｏｍｐｒｅｓｓｅｄ＿Ｆｌａｇがテーブルが圧縮されていることを示すがＤａｔａ＿Ｃｏｍｐｒｅｓｓｉｎｇ＿Ａｌｇｏｒｉｇｈｍは圧縮に使用されたアルゴリズムを示し、このようにして受信機／デコーダに解凍にどのアルゴリズムを使用する必要があるのかを示す。

受信機／デコーダは圧縮済みのテーブルセクションのそれぞれから本体を抽出し、それをアセンブルし直し、元の圧縮済みのデータブロックを形成する。これは解凍されてから、長さ指定子を用いてその構成のセクション本体に逆アセンブルされる。これらの解凍された本体は、次に元のプライベートテーブルセクション、したがって元のプライベートテーブルを作り直すために使用される。

各セクション本体を個々に圧縮するのではなく、すべてのセクション本体から構築されるデータの大きなブロックを圧縮する優位点とは、さらに高い圧縮率を達成できるという点である。また、送信されるセクション数も削減できる。したがって、圧縮済みのプライベートテーブルの伝送に必要とされる帯域幅と計算オーバヘッドも削減される。

圧縮及び解凍は、ここで図１１Ａと図１１Ｂに関してさらに詳細に説明される。
まず図１１Ａを参照すると、プライベートＭＰＥＧテーブル７００はＮ個のプライベートテーブルセクション７０２から７０４を備えている。各テーブルセクションは標準ＭＰＥＧプライベートテーブルセクションヘッダＡ、追加ヘッダＢ、本体Ｃ１からＣＮ、及びフッタＤを備える。いくつかの実施形態では、他の特定的な構造が考えられるが、テーブルセクション構造は表２および表３または表４および表５に前記に定義されるとおりである。他の例では、追加のヘッダが、表２および表３と表４および表５に指定されるフィールドに加えて、または代わりに他のフィールドを含むか、あるいはこのようなフィールドを省略する。また、長いテーブルフォーマットの実施形態にでは、フッタはＣＲＣチェックサムを提供する。短いテーブルフォーマットの実施形態では、フッタは省略される。

テーブル７００を圧縮するために、セクション本体Ｃ１からＣＮがテーブルセクション１〜Ｎから抽出される。各本体の長さが求められ、データブロック７０６が本体をアセンブルし、各本体をその本体の長さを指定するサイズ指定子で選考することによって作成される。次にデータブロックは、セクションＣ１からＣＮを備え、それぞれがそれらのそれぞれのサイズ指定子Ｃ１ ＬｅｎｇｔｈからＣＮ Ｌｅｎｇｔｈによって先行される。サイズ指定子を包含することにより、解凍後にセクション本体を正しく抽出できる。（それぞれ表２および表３と表４および表５に前述されたような）長いテーブルフォーマットと短いテーブルフォーマットの両方におけるセクション長フィールドは１２ビットフィールドであるので、この例では２バイト長の指定子で十分である。各２バイト長指定子の４つの未使用ビットが１に設定される。

それからデータブロック７０６は、任意の適切な圧縮アルゴリズムを使用して圧縮される。この結果圧縮済みのブロック７０８が生じる。

次に解凍済みのＭＰＥＧプライベートテーブル７１０が、以下のようにして圧縮済みのデータブロック７０８から作成される。圧縮済みのブロック７０８は多くのセグメントＣ’１からＣ’Ｐに分けられる。それから、各セグメントはセクション本体としてテーブル７１０のセクションに置かれる。圧縮済みのテーブル７１０は次に圧縮済みのデータブロック７０８のセグメントＣ’１からＣ’ｐを含むＰ個のテーブルセクション７１２から７１４を備える。

圧縮済みのテーブル７１０は、それから送信または記憶されてよい。圧縮されたテーブルは、前述したように、ＭＰＥＧ標準プライベートテーブルとだけではなく、一般的なプライベートテーブルフォーマットと互換性があるため、同じように処理することができる。

圧縮済みのテーブルに記憶されるデータの量は圧縮を通して削減されているため、圧縮済みのテーブル７１０は、通常（ではあるが、必ずではない）元の圧縮されていないテーブル７００より少ないセクションを有するだろう。それから、圧縮済みのデータは好ましくは均等に再配分される。したがって、テーブルの伝送は、送信されるデータの総量を削減することによってだけではなく、送信されるテーブルセクションの数を削減することによってもさらに効率化される。また、個別にではなくすべてのセクション本体をともに圧縮することにより、さらに高い圧縮率を達成できる。

ここで図１１Ｂを参照すると、圧縮済みのＭＰＥＧプライベートテーブル７１０は次のように解凍される。セクション本体Ｃ’１からＣ’ｐは、次に適切な解凍アルゴリズムを使用して解凍される圧縮済みのデータブロック７１６を提供するために抽出され、アセンブルされる。この結果、そのそれぞれのサイズ指定子とともに、元のセクション本体Ｃ１からＣｎを備える元の圧縮されていないデータブロック７１８が生じる。サイズ指定子を使用して、データブロック７１８は、次にその元の構成要素、つまりセクション本体Ｃ１からＣｎに分けられ、テーブルセクション７２２から７２４を有する元の圧縮されていないプライベートＭＰＥＧテーブル７２０がこれらのセクション本体から再構築される。

テーブルの圧縮について前述されたのと同じ手順が、プライベートテーブルを暗号化するために使用される。この目的のため、追加のヘッダは２つのフィールドＤａｔａ＿Ｃｙｐｈｅｒｅｄ＿ＦｌａｇとＤａｔａ＿Ｃｙｐｈｅｒｉｎｇ＿Ａｌｇｏｒｉｇｈｍを提供する。これらは同様の名前の圧縮関連フィールドに類似している。最初は、テーブルが暗号化されているかどうかを示すフラグであるが、２つ目は使用されている暗号化アルゴリズム、及び復号化に必要とされる復号化アルゴリズムを指定するためにオプションで使用されてよい（他の例では、このフィールドは複数の暗号化鍵の内の１つを指定するためにも使用でき、それらの鍵は前に受信機に伝達されていた）例えば、ＤＥＳまたはＲＳＡなどの任意の適当な暗号化アルゴリズムが使用されてよい。圧縮の場合と同様に、いくつかの実施形態では、暗号化はテーブルセクションで個別に実行されるが、ここで説明した好適実施形態では、サイズ指定子とともにすべてのテーブルセクション本体を備えるデータブロック上で実行される。この後者の技法は、テーブル構造が保持されていないためにセキュリティの強化を実現できる。したがって、テーブルを暗号化するための手順は前述した圧縮方法に類似している。事実上、技法は任意の演算または変換で使用されてよい。圧縮及び暗号化の形を取る変換は、例としてここに説明された。

さらに、テーブルは暗号化され、圧縮された。このケースでは、図１１Ａに図示されるデータブロック７０６が最初に圧縮されてから、暗号化される。受信機では、圧縮済み、暗号化済みのテーブルが最初に復号化されてから、解凍される（別の例では、テーブルは最初に暗号化されてから圧縮され、受信機で暗号化済み、圧縮済みのテーブルは最初に解凍されてから復号化される）。

受信機／デコーダでは、解凍及び復号化は構文解析ツールモジュールによって第１段階として実行される。代替実施形態においては、それらは別々に、テーブルが構文解析ツールに渡される前に実行される。解凍と復号化の結果、送信された圧縮済みの、及び／または暗号化済みのプライベートテーブルから第２のプライベートテーブルが作成されるため、圧縮済みの／暗号化済みのテーブルが必要とされなくなるので、送信されたテーブルによって占有されるメモリは、いったん解凍／復号化されたテーブルが作成されるとリリースされる。受信機／デコーダは、テーブル構造及びテーブルセクションに対するポインタに関する情報を備えるテーブルが受信されるとテーブル記述子を作成する。テーブル記述子は、メモリから圧縮済みの／暗号化済みのテーブルを削除するために使用される。それから、新しいテーブル記述子が、例えば解凍済みの／復号化済みのテーブルにアクセスできるようにするために別のソフトウェアモジュールに渡されてよい解凍済みの／復号化済みのテーブルについて、該ソフトウェアモジュールが作成される。

解凍／復号化モジュールは、Ｄａｔａ＿Ｃｏｍｐｒｅｓｓｅｄ＿ＦｌａｇとＤａｔａ＿Ｃｙｐｈｅｒｅｄ＿Ｆｌａｇを検査することによって、テーブルが圧縮されている、及び／または暗号化されているかどうかを検出する。これらのどちらかがセットされている場合、適切な解凍及び／または復号化アルゴリズムがＤａｔａ＿Ｃｏｍｐｒｅｓｓｉｎｇ＿ＡｌｇｏｒｉｇｈｍフィールドとＤａｔａ＿Ｃｙｐｈｅｒｉｎｇ＿Ａｌｇｏｒｉｇｈｍフィールドの値に基づいて選択される。それから、圧縮及び／または復号化は、追加の構文解析が発生する前に実行される。

したがって、テーブルの圧縮と暗号化はアプリケーションにとって、及び完全にではない場合も大体において構文解析ツールにとってトランスペアレントである。ＭＰＥＧ標準ヘッダは圧縮済みの及び／または暗号化済みのテーブルで未変更のままであり、したがって標準ＭＰＥＧプライベートテーブルセクション構造が保持されているので、圧縮／暗号化は、ＭＰＥＧテーブルの送信、受信、及びフィルタリングに関わるさらに低いレベルのＭＰＥＧに準拠するモジュールにもトランスペアレントである。受信機／デコーダでは、例えばテーブルＩＤフィールドとテーブルＩＤ抽出フィールドでフィルタリングすることによってなど、圧縮済みの及び／または暗号化済みのテーブルは標準フィルタリング方法を使用して、入信ストリームから検索される。したがて、ＭＰＥＧストリームの中の圧縮済みの／暗号化済みの情報へのアクセスの容易さは維持される。

圧縮／暗号化技法はここでは、表２および表３と表４および表５に前述され、例証された一般的なＭＰＥＧプライベートテーブル構造に関連して説明されてきた。しかしながら、それは、同じ技法を使用して圧縮、暗号化されてよい標準ＭＰＥＧプライベートテーブルにも適用可能である。いくつかのこのような例では、説明された属性のようなフラグ属性は、プライベートテーブルセクション本体の開始時に追加されるだけである。他の例では、送信者と受信者の間にプライベートテーブルセクション本体の圧縮済みの状態または暗号化済みの状態に関して過去の合意が存在する場合にはこのようなフラグは必要とされない。技法はＭＰＥＧプライベートテーブルではない他の類似したデータにも適用可能である。

アプリケーションの例
前述された実施形態は、数多くのさまざまなアプリケーションで使用されてよい。このようなアプリケーションのいくつかの例をここに示す。

第１の例は、セットトップボックスによって実施されるアクションをセットトップボックスに知らせる手段を提供する。

アプリケーションの例：アクション通知テーブル
アクション通知テーブル（ＡＮＴ）は、前述した汎用テーブル構造に基づいている。それはセットトップボックスまたはセットトップボックスのグループにある特定のアクションを実施するように命令するために使用されてよい。

受信機／デコーダによって実施されるアクションの例は、ソフトウェアのダウンロード、自動チャネル走査、受信機／デコーダのリブート、（ビデオオンデマンドカタログなどの）番組のカタログのリフレッシュ、及びセットトップボックスのユーザに対するメッセージの表示（視聴者メッセージング）を含む。テーブルＩＤ拡張フィールドは必要とされるアクションを識別するためにＡＮＴで使用される。

ＡＮＴは（例えば、ある特定のメーカの）ある特定の種類のセットトップボックス、あるいはターゲット記述子によって個別のセットトップボックスも目標にしてよい。これらは、例えば、ＡＮＴテーブルの共通記述子ループに入れられてよい。共通記述子ループの中のターゲット記述子を処理することにより、セットトップボックスは、アクションがそのセットトップボックスによって実施される必要があるかどうかを決定してよい。このターゲット及びアクション情報の処理は、例えば、セットトップボックスで実行中のアプリケーションプログラミングによって実施されてよい。

ＡＮＴは、任意のタイプのアクションと選択基準をサポートするために記述子とループのリストを記載するテーブルである。新しい記述子を作成することに対する制限はない。したがって、このアプローチは任意の新しい進化にとって開かれている。下記のセクションでは、基本的なダウンロード目的に必要とされるいくつかの基本的な記述子だけではなくＡＮＴテーブルの基本的な構造も説明されている。

マルチセクションテーブルに対処する追加ヘッダフィールドのある長いテーブルと、単一セクションテーブルを可能にする短いバージョンの２つのテーブルフォーマットが使用できる。これらは前述されたように本発明の実施形態に従う。長いテーブルフォーマットは、以下に表６および表７（なお、表６および表７は一続きのものである。）に示されている。

Ａｃｔｉｏｎ＿Ｉｄｅｎｔｉｆｉｅｒ：テーブル識別子拡張フィールド（Ｔｉｄ＿ｅｘｔ）は、ここで別の目的に、つまりアクションを識別するために使用される。アクション及びその符号化の例は、以下の表８に示されている。

Ｆｉｌｔｅｒ＿Ｅｘｔｅｎｓｉｏｎ：このフィールドの意味はＡｃｔｉｏｎ＿Ｉｄｅｎｔｉｆｉｅｒフィールドの値に依存する。考えられる値と意味の例は、以下の表９に示される。

短いテーブルフォーマットアクション通知テーブルが、前述した短いテーブルフォーマットに基づいて同様に構築されてよい。

基本的な記述子のいくつかの例は、表１０から表１７に関して後述される。

Ｃｏｄｅ＿Ｄｏｗｎｌｏａｄ＿ｄｅｓｃｒｉｐｔｏｒ
使用可能なコードローダごとに１つの記述子が提供される。

記述子はＡＮＴテーブルの内側の項目ループに置かれ、コードダウンロードスケジューリングを定義する。

フィールドの説明
Ｄｏｗｎｌｏａｄ＿Ｆｌａｇ

Ｔｙｐｅ：このフィールドは、ダウンロードプロセス開始時のＳＴＢの動作を定義する。

予定されたアクションにより、ＳＴＢは、この演算が成功するまで自動ソフトウェアダウンロードを（例えば、１ヶ月の間午前３時に一日に一度など）周期的にプログラムすることができる。

Ｐｅｒｉｏｄｉｃｉｔｙ：このフィールドは、ダウンロードプロセスが予定されたアクションについて開始したときのＳＴＢ動作を定義します。この周期性は、予定されたアクションについてＵＴＣ＿ｄａｔｅ＿ｔｉｍｅ＿ｓｔａｒｔとＵＴＣ＿ｄａｔｅ＿ｔｉｍｅ＿ｅｓｔｉｍａｔｅｄ＿ｓｔｏｐの間で使用できるだけである。

ＵＴＣ＿ｄａｔｅ＿ｔｉｍｅ＿ｓｔａｒｔ：このフィールドは、ＳＴＢの強制リブートが発生する予定される日付と時刻を示す。それは、ＴＤＴテーブルとＴＯＴテーブルの中でＤＶＢによって指定されるのと同じフォーマットでＵＴＣで符号化される。

ＵＴＣ＿ｄａｔｅ＿ｔｉｍｅ＿ｅｓｔｉｍａｔｅｄ＿ｓｔｏｐ：このフィールドは、コードダウンロードの可用性の日付けを示す。

ＡＮＴ拡張
ＡＮＴは、他のタイプのイベント通知のために使用できる。制限はない。つまり以下の例は、この解決策を別の目的でどのように使用するのかを説明する。

Ｓｃａｎｎｉｎｇ＿Ｄｅｓｃｒｉｐｔｏｒ
この記述子を使用して、セットトップボックスは走査を実施するように命令されてよい。これは、例えば使用可能なチャネルに関する情報を含むサービスマップを獲得することを含む。走査はただちに、あるいは予定に基づいて必要とされる可能性がある。

フィールドの説明
Ｓｅｒｖｉｃｅ＿ｍａｐ＿ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒ：このフィールドは使用されるサービスマップのバージョン番号を識別する。

Ｏｒｉｇｉｎａｌ＿ｎｅｔｗｏｒｋ＿ｉｄ, Ｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄ：これらのＤＶＢ値は、走査情報が放送されるトランスポートストリームを識別する。

Ｓｃａｎｎｉｎｇ＿Ｆｌａｇ：

Ｔｙｐｅ：このフィールドは、走査プロセス開始時のＳＴＢの動作を定義する。

予定されたアクションにより、この動作が成功するまで自動走査を周期的に（例えば、１月の間一日に一度午前３時に）プログラムすることが可能になる。

Ｐｅｒｉｏｄｉｃｉｔｙ：このフィールドは、予定されたアクションについて走査プロセスが開始したときのＳＴＢの動作を定義する。この周期性は、予定されているアクションについてＵＴＣ＿ｄａｔｅ＿ｔｉｍｅ＿ｓｔａｒｔとＵＴＣ＿ｄａｔｅ＿ｔｉｍｅ＿ｅｓｔｉｍａｔｅｄ＿ｓｔｏｐの間だけで使用できる。

ＵＴＣ＿ｄａｔｅ＿ｔｉｍｅ＿ｓｔａｒｔ：このフィールドは、ＳＴＢの強制リブートが発生するときの予定された日付けと時刻を示す。それはＴＤＴテーブルとＴＯＴテーブルの中のＤＶＢによって指定されるのと同じフォーマットでＵＴＣで符号化される。

ＵＴＣ＿ｄａｔｅ＿ｔｉｍｅ＿ｅｓｔｉｍａｔｅｄ＿ｓｔｏｐ：このフィールドは、走査サービスマップ情報の可用性の日付を示す。

アクション通知テーブル（ＡＮＴ）は、例えば、情報をダウンロードするようにセットトップボックスに命令するために使用されてよい。

データのダウンロードには、シグナリング機構、ダウンロード機構、及びブートストラップ機構の３つの機構が必要となる。以下の説明では、シグナリング機構はＮＩＴ（ネットワーク情報テーブル）またはＢＡＴからＰＭＴ内のリンケージ記述子の使用に基づいている。（図７ａで前記に紹介された）ＰＭＴはデータダウンロードに必要なすべての情報を記載し、ダウンロードストリームの場所を識別するテーブルである。

ダウンロードプロセスは、どの事業者、ネットワーク及びセットトップボックス（ＳＴＢ）メーカが使用されるのかに応じて多岐に渡るさまざまなタイプの情報を必要とする可能性がある。したがって、非常にオープン且つ柔軟なテーブルの概念が必要とされる。

プラットホームは、ＯＵＩ識別子によって第１のレベルで識別される。ＯＵＩ識別子は、特定のＳＴＢメーカを示す。第２のレベルでは、シリアルナンバー、マックアドレス、ＣＡＳ＿ＩＤにリンクされるスマートカード番号等の「多様なパラメータを使用するために、正確な目標設定は未決のままとされる。追加のハードウェアまたはソフトウェアのバージョン及びサブバージョンが許される。後述される解決策により、フィルタリングに任意のタイプの弁別記述子を使用できる。

図１０に図示されるように、ダウンロードサービスのシグナリングはＮＩＴ内またはＢＡＴ ６０２からＰＭＴ ６０６へのリンケージ記述子に基づいている。ＮＩＴのｓｅｒｖｅｒ＿ｌｉｓｔ＿ｄｅｓｃｒｉｐｔｏｒだけではなくＳＤＴ（サービス記述テーブル）のｓｅｒｖｉｃｅ＿ｄｅｓｃｒｉｐｔｏｒでも、サービスタイプ「ＤＯＷＮＬＯＡＤ」がこの特定のサービスを宣言するために（ダウンロードサービスが画面上でプログラムとして表示されるのを回避する目的で）定義される。

ＰＭＴ ６０６はストリーム型「ＮＯＴＩＦＩＣＡＴＩＯＮ」を定義することによりＡＮＴ（アクション通知テーブル）６０８を参照する。複数のＡＮＴテーブルをサポートすることができるため、ＯＵＩセレクタは、ＡＮＴテーブル６０８の第１の選択を使用できるようにするためにＰＭＴ ６０６で使用される。受信機／デコーダ１３が正しいＯＵＩと対応するＡＮＴを発見すると、それはＡＮＴ ６０８の中で記述子が別の選択基準に適合するかをチェックし、データカルーセルのエントリポイントを獲得する。

ＰＭＴ ６０６は、ＡＮＴ ６０８がサービスまたは任意の他の通知記述子を記載しているかどうかを即時に表示できるためにＡＩＴテーブルに類似した選択記述子を記載する。

ＯＵＩに対するフィルタリングはこのレベルで実行される。ＯＵＩの予約される値は、任意のメーカＳＴＢを選択できるように定義される。

ＯＵＩデータ構造は、以下の表１６に示される。

Ａｃｔｉｏｎ＿Ｉｄｅｎｔｉｆｉｅｒフィールドは、ＡＮＴのアクションコード値、つまりＡＮＴのＴＩＤ＿Ｅｘｔに等しい。

すべてのテーブルはバージョン番号を含むため、ＰＭＴバージョン番号変更をフィルタリングすることにより、ＡＮＴバージョン番号が変化したかどうか、及び各ＡＮＴを別々にチェックしなくてもどのバージョン番号かが分かる。

ＮＩＴまたはＢＡＴリンケージ記述子は表１７に示される構造を有する。

このリンケージ記述子は、ＰＭＴが１つまたは複数のＡＮＴ構成要素を参照するダウンロードサービスを指す。

第１のステップでは、目標は、使用可能な通知のすべての記述を搬送するサービスに達することである。第２のステップでは、このサービスのＰＭＴの分析が実行される。各通知テーブルは必要とされるＳＴＢだけに影響を及ぼすために特定のセレクタを含む特定のアクションについて作成される。したがって、ＯＵＩフィルタリングを可能とするために、各ＡＮＴ ＰＩＤの元のＡｃｔｉｏｎ＿Ｎｏｔｉｆｉｃａｔｉｏｎ＿Ｌｉｓｔ＿Ｄｅｓｃｒｉｐｔｏｒの存在は必須である。ＡＮＴ ＰＩＤは同じＯＵＩプロバイダからさまざまなアクション通知に対応する複数のＡＮＴ ｓｕｂ＿ＴＡＢＬＥを搬送できる。各ＡＮＴはＳＯＮＯＴＩＤ＿Ｅｘｔｅｎｓｉｏｎフィールドとは異なる。「ダウンロード」が考えられるアクションとして記述され、ＯＵＩコードが受信機と一致する場合には、ＡＮＴはＳＴＢによってダウンロードされる。いったんロードされると、ＡＮＴの分析はさらに正確に時間内に使用できる一致するダウンロードを記述するのに役立つ。プログラミング時にストリーム内に存在するダウンロードコードを使用しない将来のダウンロードの参照及びプログラミングが実現可能となるように、スケジューリングが可能である。

異なる使用可能な記述されたコードの中でダウンロード記述とＳＴＢ特性の間に一致が発見されると、ＳＴＢは、ａｓｓｏｃｉａｔｉｏｎ＿ｔａｇ ６１０によって記述されるダウンロードコードｅｎｔｒｙ＿ｐｏｉｎｔにジャンプできるか、あるいは別のサービス場合にはｄｅｆｆｅｒｅｄ＿ａｓｓｏｃｉａｔｉｏｎ＿ｔａｇ ６１２によって、あるいはコードが使用できない場合には、開始時間とロケーションはＳＴＢによって記憶されなければならない。その後、記憶されているｅｎｔｒｙ＿ｐｏｉｎｔ（ＯＮ＿ＩＤ、ＴＳ＿ＩＤ、ＳＶ＿ＩＤ及びａｓｓｏｃｉａｔｉｏｎ＿ｔａｇ）によって指されるデータを分析、使用するのはＳＴＢプロバイダの責任である。ダウンロードされたデータのフォーマットは、プロバイダが望む任意のフォーマットである場合がある。

それにもかかわらず、データは以下のように命令されるものとする。
・第１のフィルタリングによっても、ＳＴＢ特性とダウンロードコードのチェックはダウンロードを実行するために行われなければ成らない→コードの明確なアイデンティティが定義されなければならない。

・複数のダウンロードコードを搬送するための同じデータＰＩＤ内の機能――例えばハードウェアバージョンごとに１つ――は現在のデータの全体的な集合の中のバージョンごとに区別する方法を意味する（ｄａｔａ＿ｃａｒｏｕｓｅｌでのモジュールの選択）。

ＡＮＴと関連する機構は、新しいローダバージョンが発見できる、つまり新しくダウンロード可能なバージョントランスポートストリームまたは別のトランスポートストリーム内の場所を１つまたは複数のセットトップボックスに示す従来のシグナリング方法の拡張を提供する。

前述されたテーブル構造は、特に予定されたダウンロードのケースで有効である。

アプリケーションの例：ターッゲットされたテーブル
ＡＮＴテーブルについて前述されたように、テーブルの目標設定は、ターゲット記述子を記述子ループの含むことによって可能である。第１のＴａｒｇｅｔ＿ＲＳＭ＿Ｄｅｓｃｒｉｐｔｏｒは、特定のスマートカードを目標とするために使用される。第２のＴａｒｇｅｔ＿Ｐｌａｔｆｏｒｍ＿Ｄｅｓｃｒｉｐｔｏｒは、特定的なハードウェア及び／またはソフトウェアプラットホームを目標にするために使用される。

Ｔａｒｇｅｔ＿ＲＳＭ＿Ｄｅｓｃｒｉｐｔｏｒ
以下の表１８に記述されるこの記述子は、スマートカード識別子のリストについて動作を実施できるようになり、ＡＮＴテーブルの共通記述子ループに置かれる。複数の連続記述子が表中に表示されてよい。

フィールドの記述
Ｎｕｍｂｅｒ＿ｏｆ＿ｔｅｓｔｅｒ：この数は、ダウンロードによって影響されるＲＳＭの数を識別する。

ＲＳＭ＿Ｓｅｒｉａｌ−Ｎｕｍｂｅｒ：Ｑｕｉ Ｅｔｅｓ Ｖｏｕｓ（メディアガードスマートカードに使用可能）

ＱＥＶ：Ｑｕｉ Ｅｔｅｓ Ｖｏｕｓ（メディアガードスマートカードに使用可能）

Ｔａｒｇｅｔ＿Ｐｌａｔｆｏｒｍ＿Ｄｅｓｃｒｉｐｔｏｒ
以下の表１９に記述される記述子は、プラットホーム識別子のリストについてアクションを実行できるようにする。それは、ＡＮＴテーブルの共通記述子ループに置かれる。複数の連続記述子は、プラットホームあたり１つ、表の中に表示されてよい。

フィールドの記述
Ｈａｒｄｗａｒｅ＿ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒ：この数は１つのメーカの中のハードウェアプラットホームを特定する。

Ｎｕｍｂｅｒ＿ｏｆ＿ｖｅｒｓｉｏｎｓ＿ｃｏｎｃｅｒｎｅｄ：この数はダウンロードによって影響を受けるソフトウェアプラットホームの数を識別する。

Ｇｌｏｂａｌ＿ｓｏｆｔ＿ｉｄ：このフィールドは、コードダウンロードによって影響を受けるＳＴＢのソフトウェアバージョンを、ハードウェアプラットホームごとに識別する。

Ｔａｒｇｅｔ＿ＲＳＭ＿Ｄｅｓｃｒｉｐｔｏｒ（表１８）とＴａｒｇｅｔ＿Ｐｌａｔｆｏｒｍ＿Ｄｅｓｃｒｉｐｔｏｒ（表１９）は、特定のスマートカード及び／またはプラットホームにテーブルとテーブルセクションを向けるために使用される。したがって、それらは前述されたアクション通知テーブル、及び後述されるビデオオンデマンドアプリケーション以外のアプリケーションで使用されてよい。この目標設定機能は、アプリケーション及び関連情報をテストデバイスの定義された集合に向けることによって新しいアプライケーションを試験するのに特に有効である場合がある。後述のビデオオンデマンドアプリケーションでは、目標設定は、例えば異なる言語または異なる価格を異なるカスタマに提供するために使用されてもよい。複数の言語を提供するために目標設定記述子を使用することによって、番組の音声成分だけが複製される必要があるため、伝送帯域幅は節約されてよい。ピクチャ構成要素は言語に関係なく同じままである。目標設定記述子は、本来、通常のテーブルフィルタリング方法への拡張を提供する。

目標設定記述子は共通の、及び特定の記述子のループの両方に置かれてよい。第１の共通記述子ループを使用すると、すべての考えられるフィルタに適用可能な共通フィルタリングパラメータを指定する第１レベルのフィルタが提供される。このテーブルについての他の共通情報は、この共通記述子ループに含まれてよい。

識別子ループは、ＯＲ条件として解釈できるが、内側の特定の記述子ループはＡＮＤ条件を提出する。例えば、それぞれが２つのリンクされた状態を有する３つのフィルタが宣言される場合、識別子ループはそれぞれ２つの記述子を含む３つの項目を含むだろう。

アプリケーションの例：ビデオオンデマンドアプリケーション
第２のアプリケーションの例では、長いテーブルセクションフォーマットと短いテーブルセクションフォーマットが、ビデオオンデマンド提供品に関する情報を受信機／デコーダに送信するために使用される。

ビデオオンデマンド（ＶｏＤ）アプリケーションの関連では、アセットカタログ（アセットとは、例えば映画などのある特定のＶＯＤ提供品である）はメタデータから構成されている。このメタデータはコンテンツプロバイダから（ＸＭＬフォーマットで）供給され、ＭＰＥＧプライベートセクションの中に入れられる。ＳＴＢに送信されるそれらのセクションがカルーセルモードで一斉送信される。

ＶＯＤシステムを通して提供される多数のアセットがある可能性がある。したがって、例えば数万または数十万などの多数のアセットに使用できるデータフォーマットが提供されなければならない。

各アセットのサイズを考慮すると、以下の２つのレベルの情報が提供される。
第１のレベル：アセットのタイトル、レーティング及びカテゴリを提供する。
第２のレベル：要約、俳優のリスト、言語及び字幕情報、ならびに他の番組に関連した情報を提供する。

第１のレベルでは、テーブルの集合に、例えばテレビ番組などのリスティングアセットが提供されてよい。テーブルに容易にアクセスするために、これらのテーブルには同じテーブルＩＤが付いているが、別のテーブルＩＤ拡張子が付いている。テーブルＩＤ拡張子はアセットを分類するために使用される。例えば、あるテーブルは映画を一覧表示する可能性があるが、別のテーブルはスポーツイベントと一覧表示する。これにより、ハードウェアのフィルタリングを通して、必要なカテゴリのアセットに関するテーブルをＭＰＥＧストリームから容易に抽出できるようになる。ユーザは、例えば、スポーツ番組のリストを見ることを要求してよい。アセットテーブルのテーブルＩＤをテーブルＩＤ拡張フィールドのスポーツ番組に対するカテゴリコードに結合することによって、正しいアセットテーブルが容易に検索できる。

このテーブルにはそのカテゴリ内のすべてのアセット、つまりこの例ではすべてのスポーツ番組のリストが含まれている。次にこのリストがユーザに表示されてよい。ユーザがこれらの番組の１つに関して追加情報を要求すると、番組のコスト及びコンテンツの説明などのこの特定のアセットに関する追加情報を含む第２レベルのテーブルが検索される。ここでは、アセット識別子がテーブル識別子拡張として使用され、アセット識別子に対するハードウェアフィルタリング、ひいては関連アセット情報の高速検索を可能にする。

考えられる使用可能なカテゴリは、別のＭＰＥＧプライベートデータテーブルでも送信される。

使用可能なアセットのリストは番組カタログを構成する。追加のテーブルは、後述されるようにカタログの更新に提供される。

以下のフォーマットは、構文解析モジュールの再利用を確実にするためにプライベートテーブルの前記一般的なフォーマット記述に基づいている。これらのフォーマットは、デコーダの中のセクションフィルタリングモジュールがハードウェア８バイトマスク（ｔｉｄ＿ｅｘｔを含む、ｔａｂｌｅ＿ｉｄ＋ｔｉｄ＿ｅｘｔフィールドからの７バイト）に基づいているという事実を利用している。

以下のテーブルのカテゴリとアセットの優先順位が、情報がｔｉｄ＿ｅｘｔフィールドで並べ替えられるときに、最高の優先順位のデータが最初に検索されるように、低い方の値により高い優先順位が設定されて並べられるものとすることに注意する。

Ｃａｔｅｇｏｒｉｅｓ＿Ｄｅｓｃｒｉｐｔｉｏｎ＿Ｔａｂｌｅ
（以下に表２０および表２１（なお、表２０および表２１は一続きのものである。）に示される）Ｃａｔｅｇｏｒｉｅｓ＿Ｄｅｓｃｒｉｐｔｉｏｎ＿Ｔａｂｌｅは、入信ストリームから検出される第１のテーブルであり、使用可能なカテゴリのリストを提供する。テーブルは、前述された一般的に長いテーブルセクションに基づいている。Ｃａｔｅｇｏｒｙ＿ｉｄは、追加情報が以下の記述子リストで提供されるカテゴリを識別する２バイトフィールドである。Ｃａｔｅｇｏｒｙ＿ｉｄの値の範囲が、以下にさらに詳しく説明されるように、カテゴリ定義とサブカテゴリ定義の使用を可能にする。

Ｃａｔｅｇｏｒｙ＿ｉｄの高い方のバイトはカテゴリを定義する。Ｃａｔｅｇｏｒｙ＿ｉｄの低い方のバイトはサブカテゴリを定義する。したがって、例えばＣａｔｅｇｏｒｙ＿ｉｄ ０ｘ１２００はカテゴリ０ｘ１２とサブカテゴリ０ｘ００を定義する。同様に、Ｃａｔｅｇｏｒｙ＿ｉｄ ０ｘ１２３４は同じカテゴリ０Ｘ１２であるが別のサブカテゴリ０ｘ３４を定義する。

例えば、Ｃａｔｅｇｏｒｙ＿ｉｄ ０ｘ１２００に続くＣａｔｅｇｏｒｙ＿ｎａｍｅ＿Ｄｅｓｃｒｉｐｔｏｒは、カテゴリの視覚的な名称を表している可能性があり、Ｃａｔｅｇｏｒｙ＿ｉｄ ０ｘ１２３４に続くＣａｔｅｇｏｒｙ＿ｎａｍｅ＿Ｄｅｓｃｒｉｐｔｏｒは同じカテゴリの別のサブカテゴリの名前を表している可能性がある。

カテゴリ０Ｘ００は、一般的なｓｕｂ＿ｃａｔｅｇｏｒｙ定義をしようできるようにする予約値である。例えば、すべての考えられるカテゴリの中で一般的なｓｕｂ＿ｃａｔｅｇｏｒｙ 「ｌｉｖｅ＿ｅｖｅｎｔ」をサブカテゴリＩＤ ０ｘ０１で定義することが必要である場合には、０ｘ０００１値をＣａｔｅｇｏｒｙ＿ｉｄとして、「ｌｉｖｅ＿ｅｖｅｎｔ」が設定された記述子をテキストコンテンツとして定義することが可能である。

ｃａｔｅｇｏｒｙ＿ｄｅｓｃｒｉｐｔｏｒ＿ｌｏｏｐに記憶される記述子は、表２２に示されている。

Ｃａｔｅｇｏｒｙ＿ｎａｍｅ＿ｄｅｓｃｒｉｐｔｏｒ

アセットテーブル
アセット情報の第１のレベルは、プライベートセクション（Ｓｅｃｔｉｏｎ＿ｓｙｎｔａｘ＿ｉｎｄｉｃａｔｏｒ＝１）の長いフォーマット構文に基づいている。

各テーブルはそれらのそれぞれの識別子によって識別される特定のｃａｔｅｇｏｒｙとｓｕｂ＿ｃａｔｅｇｏｒｙに対応する。テーブルは、それぞれ４バイトの２５６個のセクションから構成できるため、１００００より多いアセットを記述できる。

（ｔｉｄ＿ｅｘｔフィールドを置換する）ｃａｔｅｇｏｒｙとｓｕｂ＿ｃａｔｅｇｏｒｙレーティングは、レーティング基準に基づいたアセットのグループの高速フィルタリングを確実にするためにハードウェアフィルタ深度にある。レーティングは、例えば、通常のペイパービューアプリケーションで使用されるＤＶＢ ｐａｒｅｎｔａｌ＿ｒａｔｉｎｇ＿Ｄｅｓｃｒｉｐｔｏｒと一貫するために８ビットで符号化される。

各テーブルはａｓｓｅｔ＿ｉｄループから構成されている。第１の記述子ループは、すべてのａｓｓｅｔ＿ｉｄに適用する共通属性を持つ。

第２の記述子ループは、ある特定のアセットに適用する特定の属性を持つ。属性が第１のループと第２のループで定義されると、第２の定義が共通定義を無効にする。

アセット情報テーブルセクションの構造は表２３および表２４（なお、表２３および表２４は一続きのものである。）に示される。

Ａｓｓｅｔ＿ｉｄ＿ｌｅｎｇｔｈ：値フィールドを定義するために使用されるバイト数
Ａｓｓｅｔ＿ｉｄ：続く記述子ループを記述する識別子または識別子のグループ
アセット情報の第２レベルは、プライベートセクション（Ｓｅｃｔｉｏｎ＿ｓｙｎｔａｘ＿ｉｎｄｉｃａｔｏｒ＝０）の短いフォーマット構文に基づいている。

ハードウェアフィルタ深度のため、特定のａｓｓｅｔ＿ｉｄにアクセスするためにフィルタをセットアップすることができる。２４ビットの予約フィールドは短いセクション構文の一般的なフォーマットと一貫するように定義される。それは実際にはハードウェアフィルタマスクを補足する。

記述子ループは、アセットに関係する属性を符号化するために使用される。

テーブルセクション構造が表２５に記述される。

Ａｓｓｅｔ＿ｉｎｆｏｒｍａｔｉｏｎ＿ｓｅｃｔｉｏｎまたはＡｓｓｅｔ＿ｍｏｒｅ＿ｉｎｆｏｒｍａｔｉｏｎ＿ｓｅｃｔｉｏｎのどちらかの記述子ループに含むために考えられるいくつかの記述子がここで説明される。

ＡＳＳＥＴ＿ｎａｍｅ＿Ｄｅｓｃｒｉｐｔｏｒ
この記述子はアセット情報テーブルのアセットループに置かれる。その構造は表２６に示される。

以下の記述子は、通常、Ａｓｓｅｔ＿ｍｏｒｅ＿ｉｎｆｏｒｍａｔｉｏｎ＿ｔａｂｌｅに置かれる。しかしながら、これらのいくつかはＡｓｓｅｔ＿ｉｎｆｏｒｍａｔｉｏｎ＿ｔａｂｌｅの属性としても使用されてよい。

ｓｏｕｒｃｅ＿ｄｅｓｃｒｉｐｔｏｒ
下記の表２７に定義されているこの記述子は、アセットの提示フォーマットの態様について情報を提供する。

Ａｓｓｅｔ＿ｍｏｒｅ＿ｉｎｆｏ＿ｄｅｓｃｒｉｐｔｏｒ
以下の表２８に定義されるこの記述子は、アセットについてその他の情報を提供する。

Ａｓｓｅｔ＿Ｄｅｓｃｒｉｐｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒ
以下の表２９に定義されるこの記述子は、アセットのテキスト記述を提供する。

Ａｃｔｏｒｓ＿ｄｅｓｃｒｉｐｔｏｒ
以下の表３０に定義されるこの記述子は、映画などのアセットに出演する俳優についての情報を提供する。

Ｐａｃｋａｇｅ＿ｄｅｓｃｒｉｐｔｏｒ
以下の表３１に定義されるこの記述子は、アセットのパッケージに関する情報を提供する。

以下の記述子はすべてのアセットに適用するため、それらはアセット情報テーブルの共通記述子ループに位置する必要があるか、あるいは特定のアセットを無効にする必要がある場合には、それはａｓｓｅｔ＿ｌｏｏｐで反復できる。

Ｃｈｅｃｋｏｕｔ＿Ｌｅｎｇｔｈ＿ｄｅｓｃｒｉｐｔｏｒ
以下の表３２に定義されるこの記述子は、チェックアウト長についての情報を提供する。それは、ＶＯＤサーバへの接続をタイムアウトにする機構を提供する。

Ｓｔｒｅａｍ＿ｃｏｎｔｒｏｌ＿ｄｅｓｃｒｉｐｔｏｒ
以下の表３３に定義されるこの記述子は、ストリーム制御情報を提供する。それは、ＩＦ高分を使用する変形データ構造として以下に定義される。

ＣＯＮＴＲＯＬ＿ＦｌａｇＳ属性は以下の表３４に記述される。

カタログ更新
ＶＯＤアプリケーションが起動されると、使用可能なセットを表示するためにアセット情報テーブルがロードされる（カテゴリレーティングは、未許可映画でカテゴリを非表示にするために考慮に入れられる）。

加入者がある特定のアセットについて追加の情報を必要とする場合、それは対応するＡｓｓｅｔ＿ｍｏｒｅ＿ｉｎｆｏｒｍａｔｉｏｎ＿ｔａｂｌｅをロードする。

さらに、アセット情報を更新するためには、表３５に説明される以下の更新する必要のあるカテゴリとサブカテゴリを示すＣａｔａｌｏｇ＿Ｕｐｄａｔｅ＿ｔａｂｌｅが一斉送信されてよい。

ｕｐｄａｔｅ＿ｃｏｕｎｔｅｒ：このカウンタは、カタログが完全に更新されるたびに１増分される。いくつかの修正だけが発生した場合、このカウンタは１増分される。Ｕｐｄａｔｅ＿Ｃｏｕｎｔｅｒフィールドの第１の値は０である。データベースエクストラクタがリセットされると、このカウンタは値０にリセットされてよいが、Ｃｕｒｒｅｎｔ＿Ａｃｔｉｏｎ＿Ｆｌａｇｓフィールドは０００１にセットされ、完全なデータベースの完全な更新を示すものとする。フィールドのサイズは８ビットに制限されているため、値はＳＴＢによって２５６を方として表現されると理解される。更新カウンタは、ＳＴＢが新規情報をいつダウンロードする必要があるのかを決定できるようにする。

ｃａｔｅｇｏｒｙ＿ｃｏｕｎｔｅｒ＿ｄｅｓｃｒｉｐｔｏｒ：カウンタ記述子は、アセット情報テーブルのバージョンカウンタを識別する。それは、ＳＴＢが、それが最新の情報をダウンロードできるように、アセット情報がいつ更新されたのかを決定できるようにする。

Ｃｕｒｒｅｎｔ＿ａｃｔｉｏｎ＿ｆｌａｇｓ：多様なフラグは、内側ループの使用可能なｃａｔｅｇｏｒｙ＿ｄｅｓｃｒｉｐｔｏｒＳに対応して同時に立てられてよい。個々のフラグは表３６に一覧表示されている。

Ｃａｔａｌｏｇ＿ｕｐｄａｔｅ＿ｓｅｃｔｉｏｎの記述子ループに表示されることがあるいくつかの記述子がここで説明される。

Ｃａｔｅｇｏｒｙ＿Ｃｏｕｎｔｅｒ＿ｄｅｓｃｒｉｐｔｏｒ
以下に表３７に定義されるこの記述子は、カテゴリ／サブカテゴリ更新カウンタを提供する。

ｃｏｕｎｔｅｒ：この８ビットフィールドは、ある特定のカテゴリとサブカテゴリについて、Ａｓｓｅｔ＿ｉｎｆｏｒｍａｔｉｏｎ＿ｔａｂｌｅと関連するＡｓｓｅｔ＿ｍｏｒｅ＿ｉｎｆｏｒｍａｔｉｏｎ＿ｔａｂｌｅの更新をカウントする。

Ｃａｔｅｇｏｒｙ＿Ａｃｔｉｏｎ＿Ｄｅｓｃｒｉｐｔｏｒ
以下に表３８に定義されるこの記述子は、指定されたカテゴリとサブカテゴリの組み合わせに必要とされる更新の種類に関する情報を提供する。

Ａｃｔｉｏｎ：この８ビットフィールドは、ループに含まれるカテゴリとサブカテゴリのリストに対するカタログ更新の間に実行されるアクションを指定する。考えられるアクションは表３９に示されている。

Ｐｌａｎｔ＿ｉｄ機構
Ｐｌａｎｔ＿ｉｄ機構は、選択されたサーバとのＶＯＤセッション接続を確立するために使用される。最初に、受信機／デコーダ１３は表４０に以下に定義される初期化ファイルを検索し、走査された周波数の１つに同調できるまで、表４２に示されるｌｏｏｋｕｐ＿ｆｒｅｑｕｅｎｃｙ＿ｌｉｓｔ＿ｄｅｓｃｒｉｐｔｏｒループの中で使用可能なすべての周波数を走査する。１つの周波数が検出されると、正しいｓｅｒｖｅｒ＿Ｇｒｏｕｐ＿Ｉｄを検索するためにＴＩＤＥＸＴが（つねに同じ記述子の中にある）Ｐｌａｎｔ＿ｉｄ＿ｓｅｌｅｃｔｉｏｎフィールドに等しいＰｌａｎｔ＿ｉｄ定義テーブルを、この同じ記述子に記述されるＰＩＤでフィルタリングすることが必要になる。同時に、アプリケーションは、ＶＯＤサーバのＩＰアドレスを検索するためにＶＯＤ＿ｉｎｉｔｉａｌｉｚａｔｉｏｎ＿ｔａｂｌｅのｃｏｍｍｏｎ＿ｄｅｓｃｒｉｐｔｏｒ＿ｌｏｏｐで使用可能なＲＯＵＴＩＮＧ＿ＩＰ記述子を使用してＨＴＴＰサーバに接続する。

ＶＯＤ＿ｉｎｉｔｉａｌｉｚａｔｉｏｎ＿ｓｅｃｔｉｏｎの構文は、以下の表４０に示される。

Ｐｒｉｖａｔｅ＿Ｆｉｌｔｅｒｉｎｇ＿Ｅｘｔｅｎｓｉｏｎ：ハードウェアフィルタの使用を最適化するために、この５６＿ＢＩＴフィールドはＭＬＯＡＤ＿ｔａｂｌｅ呼び出し、ＭＬＯＡＤ＿ｇｒｏｕｐ呼び出しまたはＭＬＯＡＤ＿ｓｅｃｔｉｏｎ呼び出しでプライベートフィルタリングを拡張するために使用されてよい。

Ｐｌａｎｔ＿ｉｄ＿ｌｅｎｇｔｈ：Ｅｘｔｒａ＿Ｉｄｅｎｔｉｆｉｅｒフィールドを定義するために使用されるバイト数

Ｐｌａｎｔ＿ｉｄ：続く記述子ループによって記述される１つの識別子または識別子のグループ

表４０のＶＯＤ＿ｉｎｉｔｉａｌｉｚａｔｉｏｎ＿ｓｅｃｔｉｏｎで使用される記述子は以下に説明される。

Ｃａｂｌｅ＿ｄｅｌｉｖｅｒｙ＿ｓｙｓｔｅｍ＿ｄｅｓｃｒｉｐｔｏｒ
以下に表４１に定義されるＣａｂｌｅ＿ｄｅｌｉｖｅｒｙ＿ｓｙｓｔｅｍ＿ｄｅｓｃｒｉｐｔｏｒは、ｆｒｅｑｕｅｎｃｙ＿ｆｉｅｌｄが００００．００００ＭＨＺに設定されるｃｏｍｍｏｎ＿ｄｅｓｃｒｉｐｔｏｒ＿ｌｏｏｐに位置してよい。それは、すべての以下の周波数のデフォルト偏重パラメータを示すのに役立つ。

ｐｌａｎｔ＿ｉｄ＿ｄｅｓｃｒｉｐｔｏｒ＿ｌｏｏｐの考えられる記述子は以下のとおりである。

ｌｏｏｋｕｐ＿ｆｒｅｑｕｅｎｃｙ＿ｌｉｓｔ＿ｄｅｓｃｒｉｐｔｏｒ
この記述子は表４２に定義される。

Ｆｒｅｑｕｅｎｃｙ：これは、周波数値の８文字を指定する４ビットのＢＣＤ値を示す３２ビットのフィールドである。周波数は、４番目の文字の後に小数が発生するＭＨＺでコーディングされている。

Ｐｌａｎｔ＿Ｉｄ＿ＰＩＤ：受信機／デコーダ１３がｐｌａｎｔ＿ＩＤファイルを検出する場合のＰＩＤ値

Ｐｌａｎｔ＿ｉｄ＿Ｓｅｌｅｃｔｉｏｎ：この１６ビットのフィールドは、ＰＩＤでフィルタリングされるＴＩＤ＿ＥＸＴ値であってよいが、ＴＩＤ値は正しいｐｌａｎｔ＿ｉｄ＿ｄｅｆｉｎｉｔｉｏｎ＿ＴＡＢＬＥを検索するために静的である。このフィールドは将来の拡張だけにオプションである。オプションである場合、その値は０ＸＦＦＦＦに設定されるものとする。

追加の例では、予約されたフィールドとｐｌａｎｔ＿ｉｄ＿ＰＩＤフィールドは、実際のＰＩＤ値を検出するのに役立つ関連タグ値を示すためにマージされてよいが、静的なデータＰＩＤ参照でシステムを利用するのはつねに困難である。

これらの以下の３つの記述子はＨｔｔｐ ＯＤＡサーバとして共通記述子ループに設定されなければならない。

Ｃｏｎｎｅｃｔｉｏｎ＿ｄａｔａ＿ｄｅｓｃｒｉｐｔｏｒ
この記述子は表４３に定義される。

Ｒｏｕｔｉｎｇ＿ＩＰＶ４＿Ｄｅｓｃｒｉｐｔｏｒ
この記述子は表４４に定義される。

Ｃｏｍｐｏｎｅｎｔ＿ｔａｇフィールドはこの例では使用されていない。その値は０に設定される。

Ｒｏｕｔｉｎｇ＿ＩＰＶ６＿ｄｅｓｃｒｉｐｔｏｒ
この記述子は表４５に定義される。

Ｃｏｍｐｏｎｅｎｔ＿ｔａｇフィールドはこの例では使用されていない。その値は０に設定される。

表４６は、ｐｌａｎｔ＿ｉｄ＿ｄｅｆｉｎｉｔｉｏｎ＿ｓｅｃｔｉｏｎの構文を定義する。

ＶＯＤ＿Ｓｅｒｖｉｃｅ＿Ｇｒｏｕｐ＿Ｄｅｓｃｒｉｐｔｏｒ
以下の表４７に記述される記述子はｐｌａｎｔ＿ｉｄ＿ｄｅｆｉｎｉｔｉｏｎ＿ｓｅｃｔｉｏｎの中で使用される。

ＶＯＤ信号の送信
以下の項では、標準信号送信及びプライベートＣ+信号送信を使用し、専用ＶＯＤテーブルをストリームから検索する方法を説明する。

最初に、ＶＯＤポータルサービスを宣言することが必要である。これは、このサービスがＶＯＤサービスであることを示すプライベート値０ＸＤ０に等しいサービスタイプを用いて行われる。このサービスタイプはＣＮＩＴのＳｅｒｖｉｃｅ＿ｌｉｓｔ＿ｄｅｓｃｒｉｐｔｏｒで、及びＳＮＴ（サービスネットワークテーブル）のｓｅｒｖｉｃｅ＿ｄｅｓｃｒｉｐｔｏｒで報告されなければならない。

このサービスは、ＶＯＤアプリケーションを起動するために必要な宣言を発見する必要がある。ＶＯＤサービスタイプ宣言がこれを達成するのに十分である場合がある。

次に、このサービスに属するＰＭＴの構成要素ループでは、ｓｔｒｅａｍ＿ｔｙｐｅ ０ＸＣ１と添付ＰＩＤとともにプライベートデータ基本ストリームのループが発見される。このｓｔｒｅａｍ＿ｔｙｐｅの各ストリームはこれらのデータのどれがこのＰＩＤを使用して一斉送信されるのかを定義するためにａｐｐｌｉ＿ｌｉｓｔ＿ｄｅｓｃｒｉｐｔｏｒを含むものとする。

ａｐｐｌｉ＿ｌｉｓｔ＿ｄｅｓｃｒｉｐｔｏｒの構文は以下の表４８に示される。

Ａｐｐｌｉ＿ｎａｍｅは（８文字に制限される）以下の値をとってよい。
□ＶＯＤ＿Ｉｎｉｔｉａｌｉｚａｔｉｏｎ＿Ｔａｂｌｅに関してＶＯＤ＿ＩＮＩＴ
□Ａｓｓｅｔ＿Ｉｎｆｏｒｍａｔｉｏｎ＿Ｔａｂｌｅに関してＡＳＳＥＴ（名前は最高８文字の空間で充填されるものとする。）
□Ａｓｓｅｔ＿Ｍｏｒｅ＿Ｉｎｆｏｒｍａｔｉｏｎ＿Ｔａｂｌｅに関してＤＥＴＡＩＬＳ
□Ｃａｔｅｇｏｒｉｅｓ＿Ｄｅｆｉｎｉｔｉｏｎ＿Ｔａｂｌｅに関してｃａｔｅｇｏｒｙ
□Ｃａｔａｌｏｇ＿Ｕｐｄａｔｅ＿Ｔａｂｌｅに関してＵＰＤＡＴＥ（名前は最高８文字の空間で充填されるものとする。）

放送のために、将来の分割を容易にするために２つのａｐｐｌｉ＿ｌｉｓｔ＿ｄｅｓｃｒｉｐｔｏｒＳがこのＰＩＤの元に存在するように、ＡＳＳＥＴとＣＡＴＥＧＯＲＹが同じＰＩＤの中に入れられてよいことに注意する。

データの量及び循環期間のために、ＤＥＴＡＩＬＳはＡＳＳＥＴとＣＡＴＥＧＯＲＹに対して別のＰＩＤの中になければならない。

起動時、ＶＯＤアプリケーションは最初にカテゴリを表示し、ユーザが必要とする場合にはＡＳＳＥＴテーブルに存在する詳細を示す。いったんデータのＰＩＤが定義されると、情報へのアクセスを加速するために完全なＤＭＴ機構の代わりにフィルタリングを行うために直接割り当てられたＴＩＤ値を使用することが許される（ＤＭＴはいずれにせよ一斉送信され、ＴＩＤと――ａｐｐｌｉ＿ｌｉｓｔ＿ｄｅｓｃｒｉｐｔｏｒ内と同じ――ｔａｂｌｅ＿ｎａｍｅの間の解像度を示すものとする）。

カタログの構文解析中、ＵＰＤＡＴＥテーブルは、カテゴリまたはアセットに変更が発生すると監視されるものとする。

したがって、いったんユーザが選択を行うと、ＶＯＤアプリケーションはそのハブ周波数を走査するためにＶＯＤ＿ＩＮＴデータを使用する。詳細については、前記ＰＬＡＮＴ＿ＩＤ＿ＭＥＣＨＡＮＩＳＭを参照すること。

いったん正しい周波数が検索され、同調が可能になると、少なくとも１つのＰｌａｎｔ＿Ｉｄ＿Ｄｅｆｉｎｉｔｏｎ＿Ｔａｂｌｅがトランスポートストリームの最初のＰＭＴに定義されるＰＩＤで一斉送信されなければならない。第１ＰＭＴによって、これが、ａｐｐｌｉ＿Ｌｉｓｔ＿Ｄｅｓｃｒｉｐｔｏｒがその中にＰｌａｎｔ＿Ｉｄ名を含むｓｔｅａｍ＿ｔｙｐｅ ０ＸＣ１の１つの基本ストリームを含む必要があるＰＡＴ内で宣言される最初のサービスであることが意味される。このＰＩＤは、この周波数についてＶＯＤ＿ｉｎｉｔｉａｌｉｚａｔｉｏｎ＿ｔａｂｌｅのｌｏｏｋｕｐ＿ｆｒｅｑｕｅｎｃｙ＿ｌｉｓｔ＿ｄｅｓｃｒｉｐｔｏｒにも説明されるＰＩＤ値である。この機構は、ＤＶＢ準拠であるために、及びゴーストＰＩＤを有さないように確立される。

それから、このＰＩＤでＰｌａｎｔ＿Ｉｄ＿Ｄｅｆｉｎｉｔｏｎ＿Ｔａｂｌｅが一斉送信され、ＴＩＤＥＸＴ値は、現在同調している周波数についてＶＯＤ＿ｉｎｉｔｉａｌｉｚａｔｉｏｎ＿ｔａｂｌｅのｌｏｏｋｕｐ＿ｆｒｅｑｕｅｎｃｙ＿ｌｉｓｔ＿ｄｅｓｃｒｉｐｔｏｒに既に定義されているＰｌａｎｔ＿Ｉｄ＿Ｓｅｌｅｃｔｉｏｎ値に等しい。このフィルタリングが一致しない場合には、別の周波数に対する試行が行われる。さらに指定の周波数についてＰｌａｎｔ＿Ｉｄ＿Ｄｅｆｉｎｉｔｏｎ＿Ｔａｂｌｅを検索するためのタイムアウトは、ＶＯＤ＿ｉｎｉｔｉａｌｉｚａｔｉｏｎ＿ｔａｂｌｅの現在のｌｏｏｋｕｐ＿ｆｒｅｑｕｅｎｃｙ＿ｌｉｓｔ＿ｄｅｓｃｒｉｐｔｏｒの中で次に説明される周波数へのジャンプを暗示するものとする。

一致なしで完全なループが行われる場合には、明示的なエラーが表示されるか、あるいは使用可能な完全な周波数リストについて新しい試行が行われる。

明示的なエラーは、以下の可能性の１つを意味する。
・周波数が検出されない。
・同調している周波数についてＰＬＡＮＴ＿ＩＤテーブルが検出されない。
・検出された周波数についてＰＡＴ信号送信がない。
・検出された周波数についてＰＭＴ信号送信がない。

それ以外の場合は、ＶＯＤセッションコネクションを確立するために、ＶＯＤ＿ｉｎｉｔｉａｌｉｚａｔｉｏｎ＿ｔａｂｌｅのＩＰ＿Ｄｅｓｃｒｉｐｔｏｒｓを用いてサーバのアドレスが検出される。

前記説明は、以下のアプローチに基づいたプライベートテーブル構造を定義した。
・短いセクションのためのモデル
・長いセクションのためのモデル、及び
・アプリケーション−コンテキストに依存した記述子の例

前述されたこのシステムは以下の戦略的な優位点を提供する。
・それによりさらに効率的な開発を可能になる。
・それにより、受信機／デコーダ１３のメーカ、及び条件付きアクセスシステムのメーカとは無関係にアプリケーションインプリメンテーションの作成が可能になる。
・コストを増加させずに使用できるデータ量の増加――これはデータ圧縮を介して行われる、及び
・製品更新の容易な開発

システムは、アプリケーション一斉送信に以下の優位点も提供する。
・一般的なテーブル構文解析ツールの提供
・構文解析ツールに対する変更は既存のアプリケーションに対して大きな影響を及ぼさない。
・プライベートテーブルの定義の正規化
・開発者はデータフィルタリング及び必要とされる特定の記述子に集中できる。
・テーブルコンテンツのさらに容易な処理
・データの抽出は構文解析ツールによって実行される。
・データフォーマットとの下位互換性を維持する。
・既存のフォーマットとの統合――プライベートセクションは、ＤＶＢテーブルがプライベート記述子を使用できる一方で既存のＤＶＢ記述子を使用できる。
・後退しないこと（ＮＯＮ-ＲＥＧＲＥＳＳＩＯＮ）の保証
・オブジェクトメソッドの記述子との関連付け
・単一の試験と統合の助長
・（ライブ放送に悪影響を及ぼさない、サイトにおける）操作統合の助長、及び
・アプリケーションを開発するために必要とされる時間の縮小

本発明が、純粋に例証として説明されてきたこと、及び詳細の変型を本発明の範囲内で加えることができることが理解されるだろう。

説明、及び（適切な場合には）請求項と図面の中に開示されたそれぞれの特徴は、個別に、あるいは任意の適切な組み合わせで実現されてよい。

デジタルテレビシステムの全体的なアーキテクチャを示す。 条件付きアクセスシステムのアーキテクチャを示す。 ＥＭＭの一般的な形式を示す。 ＳＡＳの典型的な構成を示す。 受信機／デコーダを詳細に示す。 受信機／デコーダにより含まれる５つのソフトウェア層を示す。 ＭＰＥＧストリームの数多くの構成要素の相互関係を図解する。 アプリケーションがどのようにして、代わりにセクションから形成されてよいモジュール／テーブルから構成されてよいのかを示す。 ディレクトリモジュールのコンテンツを図解する。 本発明のある実施形態によるデータ構造を示す。 セットトップボックス内の構文解析ツールの役割を示す。 アクション通知テーブルの選択を図解する。 プライベートテーブルの圧縮を図解する。 圧縮されたプライベートテーブルの解凍を図解する。

Claims (1)

1. データ部分を含むＭＰＥＧプライベートテーブルセクションのためのデータ構造であって、該データ構造は該セクションまたは該データ部分のサイズの基準を指定するサイズ指定子を備え、該データ部分は少なくとも１つのブロックを備え、該ブロックまたは各ブロックはそのブロックのサイズの基準を指定する追加のサイズ指定子を含むことを特徴とするデータ構造。
   

Images