JP4945011B2 - マルチメディア・ストリームとともに使用するための制御情報の送信及び受信 - Google Patents

Description

本発明は、通信システムを構成することに関し、より詳細には、１つの実施形態では、構成情報をシグナリングするための再構成可能な方法に関する。

従来の通信システムでは、データ及び制御ストリームのフォーマットは事前に定められた方法でしか変更することができない。機能を追加するために数ビットが確保されており、わずかな列挙パラメータが複数のオプションをサポートするが、全体的に見ればサポートされる変更は非常に限られている。開発者は、この限られた柔軟性を、システムの変更しやすいと思われる場所に加える。必要となる計画できない変更には、システムに関する予期せぬ問題及び新しい技術革新に関する予期せぬ問題という２つの種類がある。不確定な変更のサポートには前方互換性が必要となる。

時間とともに進化し得るデータ及び制御プロトコルの必要性に対処するために、柔軟で拡張可能なデータ構築方法が発明されてきたが、これらには限界がある。このような言語として、ＸＭＬ、ＪＳＯＮ及びＹＡＭＬが挙げられる。これらの言語はツリー・ベースのフォーマットでデータを構築し、これは拡張性には有利であるが、ビット効率に関して注意深く設計しなければ大量のオーバーヘッドを要する場合がある。ＸＭＬ及び関連プロトコルのフォーマットは、人の読み易さを支援するためにテキスト・ベースになっている。これにより、データは人にとって読み易くなるが、言語には過度のオーバーヘッドがかかる。通信システムでは、帯域幅効率が非常に望ましい。さらに効率的な拡張可能な通信の方法が必要とされている。

ＡＴＳＣ（Ａｄｖａｎｃｅｄ Ｔｅｌｅｖｉｓｉｏｎ Ｓｙｓｔｅｍｓ Ｃｏｍｍｉｔｅｅ）規格は、アナログＮＴＳＣテレビジョン・システムに取って代わるデジタル・テレビジョン方式に関する規格である。ＡＴＳＣ規格は、以前のＮＴＳＣ規格の表示解像度の６倍を超える最大１９２０×１０８０画素のサイズの標準的な４：３の画像又はワイドスクリーンの１６：９の画像を生成する高繊細度テレビの規格である。ＡＴＳＣ規格は、単一の６ＭＨｚＴＶチャンネル上で複数の標準画質の「仮想チャンネル」放送を伝送することに備えている。ＡＴＳＣ規格はまた、ドルビーデジタルＡＣ−３方式を使用して５．１チャンネルサラウンドサウンドを提供する「シアター品質」音響も含む。ＡＴＳＣ規格はまた、数多くの補助的なデータ放送サービスも提供する。ＡＴＳＣ規格のシグナリング及びバージョニングの改善が必要とされている。

本発明の実施形態は、マルチメディア・ストリームを視聴覚装置へ送信する際に使用する制御情報を生成するためのシステム及び方法に関する。本発明の実施形態はまた、受信した制御情報に基づいてマルチメディア・コンテンツを受信して提示するためのシステム及び方法にも関する。本発明の実施形態は、デジタル移動体放送テレビジョン、並びに携帯電話、スマートフォンなどの様々な移動体／ハンドヘルド装置へのデジタルマルチメディア・コンテンツの提供とともに使用することができる。

送信の実施形態では、方法が１又はそれ以上の制御情報のグループ（例えば複数のグループ）を生成する。個々の制御情報のグループは、視聴覚装置をマルチメディア・ストリームを提示するように構成するためのものである。個々の制御情報のグループは、異なるプロトコルバージョンに基づいて生成することができる。さらに、個々の制御情報のグループを、視聴覚装置をマルチメディア・ストリームを異なる方法で提示するように構成するためのものとすることもできる。

この方法は、第１のデータ構造（サービス記述子と呼ぶこともできる）を生成することもできる。第１のデータ構造は、個々の制御情報のグループの位置情報を含む。第１のデータ構造はまた、個々の制御情報のグループのプロトコル・バージョンを指定することもできる。複数の制御情報のグループの各々の位置は、プロトコル・バージョン及び／又はサービスタイプに基づくことができる。第１のデータ構造は、例えば追加の制御情報に関する追加情報を加えるように拡張可能に構成することができる。例えば、追加の制御情報を加えて将来的な規格変更又は新しい規格に対応することができ、これに応じて第１のデータ構造を、この新たな制御情報に関する情報を含むように拡張することができる。また、後続の送信に追加のデータ構造（サービス記述子）を含めて追加の制御情報に対応することができる。

第１のデータ構造に含まれる情報を受信側視聴覚装置が使用して、どの制御情報が視聴覚装置と互換性があるか、及びどの制御情報を無視すべきかを判断することができる。

次に、この方法は、第１のデータ構造と、複数の制御情報のグループと、マルチメディア・ストリームとを含む第１の複数のパケットを生成して送信することができる。ここで言うパケットの「送信」には、無線放送テレビジョン・システムなどにおけるパケットの放送送信が含まれる。パケットの「送信」には、サーバ・コンピュータからインターネットなどのネットワークを介して（移動体装置などの）クライアントへパケットを提供することも含まれる。

視聴覚装置が、１又はそれ以上のそれぞれの制御情報のグループの（単複の）プロトコル・バージョンを理解するように構成されていない場合、視聴覚装置が第１のデータ構造を使用して１又はそれ以上のそれぞれの制御情報のグループを無視することができる。

受信の実施形態では、視聴覚装置が、第１のマルチメディア・ストリームと、第１の制御情報と、第２の制御情報と、第１のデータ構造とを含む第１の複数のパケットを受信することができる。このパケットは、有線又は無線方式で受信することができる。

（サービス記述子などの）第１のデータ構造は、第１の制御情報及び第２の制御情報の位置情報を含む。第１のデータ構造はまた、第１の制御情報の第１のプロトコル・バージョン及び第２の制御情報の第２のプロトコル・バージョンも指定する。

視聴覚装置は、第１のデータ構造を分析して、第１の制御情報及び第２の制御情報の位置情報と、第１の制御情報及び第２の制御情報の第１及び第２のプロトコル・バージョンとを判断する。視聴覚装置が第２のプロトコル・バージョンを理解するように構成されていない場合、視聴覚装置は、第２の制御情報の位置情報を使用して第２の制御情報を無視する。

次に、視聴覚装置は、この視聴覚装置自体を第１の制御情報に基づいて構成し、従って視聴覚装置が第１のマルチメディア・ストリームを提示できるようにする。この結果、視聴覚装置は、構成後に第１のマルチメディア・ストリームを提示することができる。

視聴覚装置をマルチメディア・ストリームを提示するように構成するために視聴覚装置に提供される制御情報は、複数のノードを有するツリー・データ構造に基づいて体系化することができ、これらのノードの少なくともいくつかはリーフ・ノードである。リーフ・ノードは、視聴覚装置を構成するためのデータ値を記憶する。制御情報は複数の命令を含むことができる。これらの命令の少なくともいくつかを視聴覚装置が実行して、リーフ・ノードに記憶されたデータ値を探し出すようにツリー構造のノードをナビゲートすることができる。命令のいくつかは、ツリー構造をツリー構造内の現在の位置に関してナビゲートするように実行可能である。これとは別に、或いはこれに加えて、命令のいくつかは、ツリー構造をツリー構造のルート・ノードに関してナビゲートするように実行可能である。命令の１又はそれ以上を修飾子命令とすることができる。修飾子命令は、ツリー・データ構造内の現在のノード位置よりも下にある全てのリーフ・ノードのパラメータ値を指定することができる。例えば、修飾子命令は、ツリー・データ構造内の現在のノード位置よりも下にある全てのデータ値が任意のデータ値であるか又は必須の値であるかを指定することができる。リーフ・ノードのいくつかは、視聴覚装置を構成するための複数のデータ値を各々が記憶することができる。

１つの実施形態では、制御情報が複数の命令を含み、命令の少なくともサブセットが、関連するデータ・フィールドを有する。命令の１又はそれ以上を、長さ値を含む修飾子命令とすることができ、この命令は、長さ値により指定される修飾子命令からの或る長さ距離内にある全てのデータ値に適用されるパラメータ値を指定する。例えば、修飾子命令は、長さ値により指定される修飾子命令からの長さ距離内にある全てのデータ値が任意のデータ値であるか又は必須の値であるかを指定することができる。

本発明の実施形態は、様々なビット効率を利用して制御情報をさらに効率的に生成することができる。例えば、制御情報は複数の命令を含むことができ、命令の少なくともサブセットが、関連するデータ・フィールドを有する。命令の各々は、均一長の複数のビット部分を含むことができる。また、データ・フィールドの各々も、均一長の複数のビット部分を含むことができる。１つの実施形態では、命令のビット部分の（ＭＳＢなどの）第１のビットが、ビット部分が命令であることを示す（「０」などの）第１の値を有することができる。データ・フィールドのビット部分の（ＭＳＢなどの）第１のビットは、ビット部分がデータ・フィールドであることを示す（「１」などの）第２の値を有することもでき、この第２の値は第１の値と異なる。これにより、専用の長さフィールドを必要とせずに命令及びデータの長さを示す効率的な方法を提供する。

以下の好ましい実施形態の詳細な説明を以下の図面と併せて検討すれば、本発明をより良く理解することができる。

１つの実施形態によるデジタル・テレビジョン放送システムを示す図である。 １つの実施形態による、マルチメディア・ストリームを視聴覚装置へ送信する際に使用するための制御情報を生成する方法を示すフロー図である。 １つの実施形態による、視聴覚装置がマルチメディア・ストリームのための制御情報を受信する方法を示すフロー図である。 １つの実施形態による、インライン・シグナリングを含むアーキテクチャを示す図である。 １つの実施形態によるツリー・ベースのデータ構造を示す図である。 １つの実施形態による、ＡＴＳＣ Ｍ／Ｈシステムの基本バージョンの機能ブロックを示す図である。 １つの実施形態による、ＡＴＳＣ Ｍ／Ｈ機能ブロックのバージョニングを含むツリー・ベースのデータ構造を示す図である。 １つの実施形態による、別のバージョニングブロックを含むアーキテクチャを示す図である。 １つの実施形態による、バージョニングブロックとシグナリングブロックを組み合わせたアーキテクチャを示す図である。 １つの実施形態によるパケットフォーマットを示す図である。 １つの実施形態による、制御パケットのフィールドを定義するテーブルである。 １つの実施形態による、サービス記述子フィールドのフォーマットを示す図である。 １つの実施形態による、サービス記述子フィールドのサブフィールドを定義するテーブルである。 １つの実施形態による、例示的なサービス記述子フィールドを示すテーブルである。 １つの実施形態による、一連の命令／データのフォーマットを示す図である。 １つの実施形態による、ＸＣＬ命令セットを定義するテーブルである。 １つの実施形態による、ＸＣＬ命令セット修飾子を定義するテーブルである。 １つの実施形態によるＡＴＳＣ Ｍ／Ｈツリーの一部を示す図である。 １つの実施形態によるＡＴＳＣ Ｍ／Ｈツリーを示す図である。 １つの実施形態による、図１９のＡＴＳＣ Ｍ／Ｈツリーとともに使用するためのＦＩＣデータツリーを示す図である。 １つの実施形態による、ＦＩＣツリーをナビゲートする例示的な命令シーケンスを示す図である。 １つの実施形態による、図１９のＡＴＳＣ Ｍ／Ｈツリーとともに使用するためのＳＭＴデータツリーを示す図である。 １つの実施形態による、ＳＭＴツリーをナビゲートする例示的な命令シーケンスを示す図である。 ＸＣＬ命令セットの別の実施形態を定義するテーブルである。 命令修飾子の別の実施形態を定義するテーブルである。 ＦＩＣ及びＳＭＴデータツリーの別の実施形態を示す図である。 ＦＩＣ及びＳＭＴデータツリーの別の実施形態を示す図である。 ＦＩＣ及びＳＭＴデータツリーの別の実施形態を示す図である。

本発明は、様々な修正及び代替の形態が可能であるが、図面には本発明の特定の実施形態を一例として示し、本明細書ではこれらについて詳細に説明する。しかしながら、図面及びこれらの詳細な説明は、開示する特定の形態に本発明を限定することを意図するものではなく、むしろ添付の特許請求の範囲により定められる本発明の思想及び範囲内にある全ての修正、同等物及び代替手段を含むことを意図するものであると理解されたい。

通常、放送システムなどの通信システムは、ある種のコンテンツ又は（単複の）サービスを通信するためのフレームワークを含むことができる。通信システムは、コンテンツ又は（単複の）サービスに関する情報を受信機に提供するためのシグナリング・フレームワークをさらに含むことができる。複雑さを最小限にまで抑えた、又は時間とともに変化することを予想できるいずれの通信システムも、このような情報を提供して受信機がコンテンツ又は（単複の）サービスを使用できるようにする必要があり、例えば、シグナリング・フレームワークは、受信機が提供されるサービスに同調し、転送からサービスを抽出してこれをユーザに提示できるようにすることができる。通信システムの１つの特定の例に、デジタル・テレビジョン放送システムなどの視聴覚放送システムがある。本明細書で説明する実施形態の多くは、このような例示的なシステムに照らして示すことができるが、これらの実施形態はその他の通信システムにも適用可能である。

シグナリングは、受信機がサービスを使用するのに有用な又は必要な特定の構成要素に関する情報を含むことができる。シグナリングはバージョニング情報を含むこともできる。（システムのあらゆるレベルにおける、システム全体に至るまでの、及びシステム全体を含む）システムの１又はそれ以上の構成要素は、プロトコル・バージョンを含むことができる。受信機は、サービスを正確に再構築するためにこのようなバージョニング情報を知る必要があり得る。例えば、受信機にインストールされている現在の機能よりも新しいバージョンの機能を含むサービスが送信機において構築された場合、受信機はこのサービスを処理してこれを正確に提示することができない。従って、サービスの処理及び提示に関与する機能のバージョン情報をシグナリング情報に含める必要があり得る。通信システムにおける帯域幅は制限されることがあるので、例えば、実際のコンテンツ及び／又は（単複の）サービスのためにできるだけ多くの帯域幅を取っておくために、シグナリング・フレームワークが効率的であることも重要となり得る。

ある通信システムで使用されるシグナリング・フレームワーク及び方法は、現在実現されている及び将来的に実現される通信システムの前方及び後方互換性に大きな影響を与えることになる。通信システムにとって特に望ましい機能は、古い（レガシーな）装置及びサービスを提供できると同時に、新たなサービス及びこの新たなサービスをサポートできる装置を提供できることである。この新たなサービスにおける後方互換性を効率的に提供する（例えば、レガシー装置及びサービスとともに動作できる新たなサービス及び装置を開発する）ための最も効果的な方法は、前方互換性の高い（例えば、シグナリング・フレームワーク自体の変更を含む不確定な変更を通信システムに効率的かつ効果的に提供するように設計された）シグナリング・フレームワークを構築することであると考えられる。従って、柔軟で拡張可能な効率のよいシグナリング・フレームワークを使用することは、通信システムの全体的な機能を向上させること、及び通信システムの（提供されるサービス及びこれらのサービスを受信するための消費者構成要素などの）構成要素の耐用寿命を延ばすことにとって不可欠となり得る。

本発明の様々な実施形態は、通信システムのための柔軟で拡張可能な効率のよいバージョニング及びシグナリング・システムを生成できるようなフレームワーク及び方法に関する。このようなフレームワークの１つの鍵は、レガシー受信機がシグナリング／バージョン・データの一部をサポートできないかどうか、及びシグナリング／バージョニング・データのこのような部分を無視又はスキップするかどうかをレガシー受信機が適切に認識する方法を提供することであると考えられる。これにより、新たなサービス及びこれらの新たなサービスをサポートできる受信機の開発を、レガシー受信機のコンテンツを受信するための能力を損なうことなく自由に行えるようになる。

このようなフレームワークのためのいくつかの構成要素が存在することができ、これらの各々を様々な方法で実現することができる。これらの構成要素の一部又は全ては、拡張可能で効率のよいシグナリング及びバージョニング・フレームワークを生成するようにともに機能することができる。いくつかの実施形態では、構成要素の１又はそれ以上を、例えば他の構成要素を伴わずに単独で実現することができるが、いくつかの実施形態では、構成要素の一部又は全てをともに使用することによってより大きな利益を得ることができる。構成要素は次のいずれかを含むことができ、以下、これらの各々について説明する。サポートしていないデータが構造に挿入されていることをレガシー受信機が検出して適切にスキップできるようにシグナリング／バージョニング・データを構築するための手段が存在することができる。シグナリング／バージョニング・データを互換性のあるグループに区分して、これらのグループの対象（受信機など）が、グループ分けした機能をサポートできるようにする手段が存在することができる。受信機が、サポートされているサービスを復号して正確に提示するために必要なデータのみにアクセスすることにおいてサポートを受けるようにこれらのシグナリング／バージョニング・グループにインデックスを付け、受信機が、コンテンツの提示が完全にサポートされていることをコンテンツを提示しようと試みる前に知ることができるようにする手段が存在することができる。一部がサポートされていない場合にどれほどのデータをスキップすべきかを判断するための手段が存在することができる。データの構造を修正及び／又は拡張できるように、シグナリング／バージョニング・データの構造をナビゲート又は別様に参照するための手段が存在することができる。シグナリング／バージョニング・データの構造をナビゲート又は別様に参照する手段を拡張するための手段が存在することができる。

サポートしていないデータが構造に挿入されていることをレガシー受信機が検出して適切にスキップできるようにシグナリング／バージョニング・データを構築するということは、他のあらゆる構造の部分とは無関係に変更される可能性のある構造の部分を受信機がサポートできるかどうかを受信機（すなわちレガシー受信機を含む）にシグナリングする要素がこれらの構造の部分ごとに含まれることを意味する。事実上、異なる構造の部分にバージョンごとにマーキングする方法が存在しなければならない。これはいくつかの方法で行うことができる。１つの実施構成では、シグナリング／バージョニング・データをツリー・フォーマットで構築し、（１又はそれ以上のリーフ及び／又はサブノードなどを含む）あらゆるリーフ又はノードを個別にバージョニングすることができる。別の実施構成は、シグナリング／バージョニング・データを１又はそれ以上のテーブルの形で構築し、この場合、テーブルの個々の部分が、シグナリング／バージョニング・データのその部分のバージョンに直接的又は間接的にマークキングするヘッダ又はポインタを有する。また、構造自体を拡張可能にすべきであり、すなわち追加のシグナリング／バージョニング・データを挿入する方法が存在しなければならない。構造の残りに影響を与えることなく追加のノード又はリーフを作成できる場合、ツリー構造はこの追加要件に容易に適応できる。テーブルもこの要件に対応できるが、

シグナリング／バージョニング・データを互換性のあるグループに区分して、前記グループの対象がグループ分けした機能をサポートできるようにすることで、シグナリング・フレームワークの効率を上げることができる。このようなグループ分けの例として、所与の規格のプロトコル・バージョン、サービスのクラス、音声／視覚情報タイプ、規格タイプなどを挙げることができる。例えば、シグナリング／バージョニング・データをプロトコル・バージョングループに区分した場合、特定のプロトコル・バージョンに至るまで互換性のある受信機は、そのプロトコル・バージョンのシグナリング／バージョニング・データを全て単一のグループから得ることができる。

シグナリング／バージョニング・グループにインデックスを付けることにより、受信機がサポートするグループをこの受信機が発見できるようになり、逆にサポートできないグループを認識し、従ってこれらを無視できるようになる。この方法は、データがサポートされているかどうかを見いだすためにシグナリング／バージョニング・データ自体を解析し始めるように受信機に強いることと比較した場合、受信機がシグナリング／バージョニング・データのいずれの（単複の）部分がこの特定の受信機に関連しこの受信機によりサポートされているかを見いだすためのはるかに効率的な方法となり得る。このようなインデックスの１つの例示的な実施構成に「サービス記述子」又は「サービス発見テーブル」があり、これらは、シグナリング／バージョニング・データとは別の、例えばこのようなインデックス付与情報を提供するデータ構造である。別の考えられる実施構成は、このようなインデックス付与情報をシグナリング・バージョニング・データに含めることであるが、これによって得られるシグナリング・フレームワーク自体への将来的な変更に対する柔軟性はそれほど大きくはないと思われる。

受信機が、サポートしていないデータをスキップ又は無視する場合、受信機は、どれほどのデータをスキップすべきかを判断するための方法を有していなければならない。換言すれば、受信機は、データの一部をサポートしていないことを認識できる必要があるだけでなく、スキップすべきデータがどこから始まってどこで終わるかを知っておく必要がある。１つの実施形態では、このことをインデックス付与機能に組み込むことができ、例えば、各グループの開始及び終了位置を示す情報をインデックスに含めることができる。いくつかの実施形態では、グループが同じ基本プロトコル・バージョンを有することができるが、グループ内に異なる（例えば高い）プロトコル・バージョンを有するいくつかの任意の構成要素を含むことが望ましい。この場合、任意にこれらの構成要素にマーキングする方法も望ましい。

通信システムの将来的なプロトコル・バージョンの変更を行い、及び新しいプロトコル・バージョンを作成するために、シグナリング／バージョニング・データの構造を修正及び／又は拡張できるようにこれらをナビゲートし又は別様に参照するための手段が有用になり得る。例えば、構造がツリー構造である場合、ツリーをナビゲートするための手段は、ツリー内の新たな又は修正されたノード又はリーフにナビゲートする能力を含んでいなければならず、そうでなければ、ツリーをナビゲートするための手段が、修正されたツリーをサポートすることができない。１つの実施構成では、これを、ツリーのあらゆるノード又はリーフへのナビゲートをサポートする、ツリー構造をナビゲートするための命令セットとすることができる。このような命令セットの例については、図１５〜図１７に関してより詳細に説明する。このような命令セットのことを、本明細書では「拡張可能制御言語」又は「ＸＣＬ」と呼ぶ。シグナリング／バージョニング・データにどのような構造（ツリー、テーブル、又はいずれかの構造など）を使用する場合でも、これをナビゲートし又は別様に参照するための手段は、この構造への修正及び／又は拡張を可能にすることができるべきである。

同様に、構造をナビゲートし又は別様に参照する手段を拡張するための手段を提供することが有用になり得る。換言すれば、シグナリング方法自体が柔軟かつ拡張可能であるべきである。これは、将来的なナビゲーション又は参照情報のために固定数のビット又は値を確保することと同じぐらい単純なものと考えられるが、無制限に拡張可能なシステムが好ましい。一例として、シグナリング／バージョニング・データのための上述したツリー・ベースの構造、及びツリーをナビゲートするための命令セットを再検討する。命令セット内のあらゆる所与の命令を固定長フィールド内の値として列挙することができる。未知の将来的な使用のためにわずかなフィールドの値を確保し、あらゆる新規命令をこれらのわずかな値に（そのシグナリングプロトコル・バージョン内で）制限するのではなく、フィールドを別の固定増分ずつ拡張するように命令を定義することができる。拡張されたフィールドは、拡張されたフィールドの全ての値が定義されるまで新規命令のために使用することができ、このフィールドを「フィールド拡張」命令によって再び拡張することもでき、これを後方互換性を破壊することなく無制限に継続することができる。

以下、このような拡張可能なシグナリング・フレームワークの実施形態及び例示的な実施構成について、デジタル・テレビジョン放送システムなどの放送システムに関して説明する。しかしながら、本明細書で説明する方法は、図１に示し様々な実施形態に基づいて以下で説明するような放送システムとともに使用できると同時に、これらをより一般的に、例えば必要に応じてあらゆる通信システムとともに使用することもできる。

図１−デジタル・テレビジョン放送システム
図１は、本発明の１つの実施形態による例示的な放送システム１００を示している。１つの実施形態では、この放送システムをデジタル・テレビジョン放送システムとすることができる。本明細書で説明する放送システム１００を、本明細書で説明する様々な方法を含めて使用して、視聴覚情報及びその他のデータを含む様々な種類のデータのいずれかを放送することができる。当業者であれば理解するであろうが、本明細書で使用する「放送」という用語は、そのあらゆる通常の意味を含むことが意図されている。

本明細書で使用する「視聴覚情報」及び「マルチメディア・ストリーム」という用語は、ビデオデータ及び／又は音声データを含む様々な種類の情報又はデータのいずれかを含む。「ビデオデータ」という用語は、（テレビ、映画、ストリーミングビデオ、その他、及びＪＰＥＧなどの画像データのような）動画ビデオを含む。「視聴覚情報」及び「マルチメディア・ストリーム」という用語は、実行時に装置に（ディスプレイ上に）ビデオデータを、及び／又は（スピーカ上に）音声データを提示させる様々な種類の情報又はプログラム命令のいずれかをさらに含む。例えば、「視聴覚情報」及び「マルチメディア・ストリーム」という用語は、提示装置上に（画像、ビデオ、及び／又は音声などの）ゲーム・コンテンツを提示するために利用及び／又は実行できる（プログラム命令及び／又はデータを含む）様々な種類のゲーム・コンテンツのいずれかを含む。

１つの実施形態の組では、放送システムが、８−ＶＳＢ変調などを使用してＡＴＳＣ（Ａｄｖａｎｃｅｄ Ｔｅｌｅｖｉｓｉｏｎ Ｓｔａｎｄａｒｄｓ Ｃｏｍｍｉｔｔｅｅ）規格に基づいて動作することができる。或いは、この放送システムは、ＡＴＳＣ規格の修正版に基づいて、或いは別の規格に基づいて動作することができる。例えば、移動中の受信機に視聴覚情報を送信するためには、ＡＴＳＣ規格のＭｏｂｉｌｅ／Ｈａｎｄｈｅｌｄ（Ｍ／Ｈ）修正版が使用される。本明細書に開示する実施形態の具体例は、ＡＴＳＣ規格のＭ／Ｈ修正版の一部に基づくこと、又はこれを含むことができ、Ｍ／Ｈ及びＡＴＳＣ規格のさらなる変形版及び修正版を含むこともできる。しかしながら、本明細書に開示する視聴覚情報の送信に関する実施形態は、必ずしもＡＴＳＣ又はＭ／Ｈシステムとの使用に限定されるものではなく、ＤＶＢ−Ｔ／Ｈ、ＩＳＤＢ−Ｔ、ＤＭＢ−Ｔ／Ｈなどの他の規格及び／又は修正スキームに基づく視聴覚情報の送信にも等しく適用することができる。

図示のように、システム１００は、送信システム（又は送信システム）１０２と、（１１２Ａなどの１又はそれ以上の固定装置、及び／又は１１２Ｂ〜１１２Ｅなどの１又はそれ以上の移動体装置などの）１又はそれ以上の視聴覚装置とを含む。上述したように図１は例示にすぎず、例えば例示的なシステムは、１又はそれ以上の送信システム１０２と、複数の移動体装置と、複数の固定装置とを含むことができる。本明細書で説明する様々な方法はいずれも、移動体装置又は固定装置のいずれか、或いはこれらの両方とともに望む通りに利用することができる。

送信システム１０２は、視聴覚情報を１又はそれ以上の視聴覚装置１１２へ有線又は無線方式で送信するように構成することができる。特定の実施形態では、送信システム１０２を、デジタル・テレビジョン信号／チャンネルを移動体装置１１２Ｂ〜１１２Ｅへ無線で送信するように構成することができる。移動体装置１１２Ｂ〜１１２Ｅは、視聴覚情報を受信して提示することができ、例えばデジタル・テレビジョン信号／チャンネルを受信して提示することができる。送信システム１０２はまた、視聴覚情報を（固定テレビなどの）固定装置１１２Ａへ有線方式又は無線方式のいずれかで送信するように構成することもできる。いくつかの実施形態では、視聴覚装置を送信システムとして動作できるようにすることができ、例えば視聴覚装置を、送信を受信してこれを他の視聴覚装置へローカルに再放送できるようにすることができる。従って、いくつかの実施形態では、送信システム１０２を視聴覚装置とすることもできる。

送信システム１０２は、送信機１０６と、この送信機１０６に結合された送信論理回路１０４とを含む。送信論理回路１０４は、（付属のソフトウェアを含む）１又はそれ以上のコンピュータ・システム、デジタル論理回路、アナログ論理回路、プログラマブル・ゲート・アレイなどの様々な種類の論理回路のいずれか、又はこれらの組み合わせを含むことができる。送信論理回路１０４は、（テレビデータなどの）視聴覚情報を受信及び／又は記憶して、この視聴覚情報を含むパケットを生成するようにされる。送信論理回路１０４は、８−ＶＳＢ変調などを使用して、ＡＴＳＣ（Ａｄｖａｎｃｅｄ Ｔｅｌｅｖｉｓｉｏｎ Ｓｔａｎｄａｒｄｓ Ｃｏｍｍｉｔｔｅｅ）規格などの様々な規格のいずれかに基づいてパケットを生成することができる。送信システム１０２は、ＤＶＢ−Ｔ／Ｈ、ＩＳＤＢ−Ｔ、ＤＭＢ−Ｔ／Ｈなどの他の変調方式を使用することもできる。本明細書で説明するように、送信論理１０４を、（シグナリング／バージョニング・データなどの）制御情報を含むパケットを生成するように構成することもできる。１つの実施形態では、デジタル・テレビジョン・チャンネルの１又はそれ以上を、テレビなどの固定受信機向けに企図することができる。デジタル・テレビジョン・チャンネルの１又はそれ以上を、移動体及び／又はハンドヘルド（Ｍ／Ｈ）（本明細書ではまとめて「移動体」と呼ぶ）装置１１２Ｂ〜１１２Ｅ向けに企図することもできる。１つの実施形態では、デジタル・テレビジョン・チャンネルの１又はそれ以上を、固定受信機又は移動体装置のいずれかに向けて企図することができる。

移動体装置１１２は、ポータブル・コンピュータ・システム（ラップトップ）１１２Ｂ、（Ｂｌａｃｋｂｅｒｒｙ、ｉＰｈｏｎｅなどの）無線電話機１１２Ｃ、携帯情報端末１１２Ｄ、車載型テレビ装置１１２Ｅ、及び受信した視聴覚情報を表示できるその他の種類の携帯機器などの様々な種類の装置のいずれであってもよい。

（単複の）固定装置１１２Ａは、液晶ディスプレイ（ＬＣＤディスプレイ）、プラズマ・ディプレイなどの従来のテレビのような、固定位置に設置されることを意図された（固定式又は「非モバイル」と呼ぶ）様々な種類の装置のいずれであってもよい。

視聴覚装置１１２は、送信機１０６により送信された視聴覚情報及び制御情報を含むパケットを受信するように構成される。それぞれの視聴覚装置１１２は、受信した視聴覚情報を処理するための受信機論理回路、及びビデオ情報を提示するためのディスプレイと音声情報を提示するための１又はそれ以上のスピーカとを含むこともできる。従って、視聴覚装置１１２の各々は、本明細書で説明するような受信したテレビジョン・チャンネルを提示するためのテレビのような能力を含むことができる。

図２−送信フロー図
図２は、マルチメディア・ストリームとともに使用する制御情報を視聴覚装置へ送信する方法を示すフロー図である。この方法は、上述したような及び図１に示すような、送信論理回路及び送信機を含むシステムなどの送信システムにより実施することができる。マルチメディア・ストリームは移動体装置が受信するためのものであってもよく、或いはマルチメディア・ストリームは、固定装置が、又は移動体装置及び固定装置の両方が受信するためのものであってもよい。なお、様々な実施形態によれば、ステップのうちの１又はそれ以上を省略し、反復し、或いは図２に示し以下で説明するものとは異なる順序で実施することができる。

２０２において、第１のプロトコル・バージョンに基づく第１の制御情報を生成することができる。この第１の制御情報は、マルチメディア・ストリームを第１の方法で（例えば第１のサービスタイプに基づいて）提示するように視聴覚装置を構成するためのものであってもよい。第１の制御情報は、視聴覚装置がツリー・ベースのデータ構造をナビゲートするための、及びツリーの１又はそれ以上のリーフ・ノードのパラメータ値を設定するための一連の命令及びデータであってもよい。例えば、第１の制御情報は、（図１９、２０、又は２２に示しこれに関して説明する）ＡＴＳＣ Ｍ／Ｈツリーをナビゲート及び定義するための（図１５〜図１７に示しこれに関して説明する）一連のＸＣＬ命令であってもよい。従って、第１の制御情報を図２２又は図２４に示すように、又はこれらと同様に符号化することができる。或いは、第１の制御情報は、視聴覚装置をマルチメディア・ストリームを提示するように構成するためのいずれの種類の制御情報であってもよい。第１の制御情報は、第１のプロトコル・バージョンに基づいて生成することができる。例えば、１つの実施形態では、第１の制御情報をバージョン１．０ＸＣＬに基づいて生成することができる。

２０４において、第１の制御情報に関する情報を含む第１のデータ構造を生成することができる。第１のデータ構造は、第１の制御情報が第１のプロトコル・バージョンであることを指定することができる。換言すれば、第１の制御情報がバージョン１．０ＸＣＬである場合、第１のデータ構造がこのことを示すことができる。第１のデータ構造はまた（或いは上記とは別に）、第１の制御情報の位置情報（オフセットなど）、及び／又は第１の制御情報により指定されるマルチメディア・ストリームのサービスのクラス又はタイプなどの、第１の制御情報に関する他の様々な種類の情報のいずれかを示すこともできる。例えば、第１の制御情報は、マルチメディア・ストリームを３−Ｄ又は２−Ｄで提示するように視聴覚装置を構成するためのものであってもよい。第１のデータ構造はまた、第１のデータ構造自体を定義する、例えばサイズ、プロトコル・バージョン、構造などを指定する情報を含むこともできる。

１つの実施形態では、第１のデータ構造を、図１２〜図１４に関して以下で説明するようなサービス記述子とすることができる。従ってこの場合、データ構造は、（プロトコル・バージョン、長さ、コラムの数、コラムの長さなどの）このデータ構造自体を定義する情報、及び第１の制御情報に関する情報（情報の（単複の）種類、及び情報の種類ごとのデータ）を含むことになる。或いは、第１のデータ構造は、いずれの種類のデータ構造であってもよい。

２０６において、第１の複数のパケットを生成することができる。第１の複数のパケットは、第１の制御情報により指定されるマルチメディア・ストリーム（視聴覚情報など）、第１の制御情報、及び第１のデータ構造を含むことができる。マルチメディア・ストリームを含むパケットを生成する前にマルチメディア・ストリームを受信及び／又は記憶することができる。第１の複数のパケットはパケットの別個のサブセットを含むことができ、この場合、１つのサブセットがマルチメディア・ストリームを含むのに対し、１つのサブセットが第１の制御情報及び第１のデータ構造を含む。サブセットは別個のものであってもよく、或いはともに混合（多重化など）することもできる。或いは、異なる方法で情報を分離することもでき、或いはマルチメディア・ストリーム、第１の制御情報、及び第１のデータ構造を含む同様のパケット内に情報を生成することもできる。パケットは、ＩＰｖ４、ＩＰｖ６、ＭＰＥＧ−２などの様々なフォーマットのいずれかに基づいて生成することができる。

２０８において、第１の複数のパケットを送信することができる。第１の複数のパケットは、様々な実施形態による、図１に関して説明したような送信システムにより送信することができる。いくつかの実施形態では、インターネットサーバなどのサーバにより第１の複数のパケットを提供することができる。従って、送信システムは、（放送システムのような）１方向通信システムであっても、或いは（インターネット、セルラーネットワーク、又はいずれかの２方向通信システムを介するような）２方向通信システムであってもよい。

２１０において、第２のプロトコル・バージョンに基づく第２の制御情報を生成することができる。第２の制御情報は、マルチメディア・ストリームを、例えば第２のサービスタイプに基づく第２の方法で提示するように視聴覚装置を構成するためのものであってもよい。第１の制御情報と同様に、第２の制御情報は、ツリー・ベースのデータ構造をナビゲートするための、及びツリーの１又はそれ以上のリーフ・ノードのパラメータ値を設定するための一連の命令及びデータであってもよい。例えば、第２の制御情報は、（図１９、２０、又は２２に示しこれに関して説明する）ＡＴＳＣ Ｍ／Ｈツリーをナビゲート及び定義するための（図１５〜図１７に示しこれに関して説明する）一連のＸＣＬ命令であってもよい。従って、第２の制御情報を図２２又は図２４に示すように、又はこれらと同様に符号化することができる。或いは、第２の制御情報は、視聴覚装置をマルチメディア・ストリームを提示するように構成するためのいずれの種類の制御情報であってもよい。第２の制御情報は、第１のプロトコル・バージョンとは異なる場合もある第２のプロトコル・バージョンに基づいて生成することができる。例えば、第１の制御情報がバージョン１．０のＸＣＬに基づいて生成される場合、第２の制御情報を、バージョン２．０のＸＣＬ、又は完全に異なる命令言語又は制御情報の形に基づいて生成することができる。

第２の制御情報は、第１の制御情報が視聴覚装置の構成情報を指定する同じマルチメディア・ストリームを提示するように視聴覚装置を構成するためのものであってもよい。或いは、第２の制御情報は、（例えば、第１のマルチメディア・ストリームとは異なるプロトコル・バージョンに基づくマルチメディア・ストリームのような、異なる種類のマルチメディア・ストリームなどの）第１の制御情報とは異なるマルチメディア・ストリームを提示するように視聴覚装置を構成するためのものであってもよい。

２１２において、第１のデータ構造を、第２の制御情報に関する追加情報を含むように修正することができる。例えば、第１のデータ構造が（図１２〜図１４に関して様々な実施形態により説明するような）サービス記述子である場合、個々のコラム内の追加項目を示すようにコラム長フィールドを修正することができる。次に、第２の制御情報に関する情報を第２の項目として各コラムに含めることができる。従って、修正した第１のデータ構造は、第２の制御情報のプロトコル・バージョン、サービスのタイプ又はクラス、メジャー／マイナーなチャンネル番号、（オフセットなどの）位置情報のような、第１の制御情報に関するものと同様の第２の制御情報に関する情報を含むことができる。なお、第１のデータ構造は、第２の制御情報に関する追加情報を含むように修正されることに加え、第１の制御情報に関する情報を保持することもできる。１つの実施形態では、データ構造のフォーマットを変更することができる。例えば、第１のデータ構造をバージョン１．０のサービス記述子とすることができ、修正した第１のデータ構造をバージョン２．０のサービス記述子とすることができる。修正した第１のデータ構造は、第１のデータ構造のフォーマットを指定する情報を含むことができ、例えば、修正した第１のデータ構造のバージョン情報、及び／又は修正した第１のデータ構造のサイズ情報を含むことができる。或いは、データ構造をサービス記述子とは異なる種類のデータ構造とすることもでき、あらゆる数の方法で第２の制御情報に関する追加情報を含むように修正することができる。

別の実施形態では、第１のデータ構造を修正することができず、むしろ第２のデータ構造を生成することができる。第２のデータ構造は、第１のデータ構造と同様のものではあるが第１の制御情報に関する情報ではなく第２の制御情報に関する情報を含むものとすることができ、或いは第２のデータ構造を異なる種類のデータ構造とすることができる。例えば、第２のデータ構造を、異なるプロトコル・バージョンのサービス記述子、或いは全く別の種類のデータ構造にすることができる。このような第２のデータ構造は、第２の制御情報のプロトコル・バージョン情報、位置情報（オフセットなど）などの、第１のデータ構造と同様のものではあるが第２の制御情報に関する情報を含むことができ、或いは第２のデータ構造は、第２の制御情報に関する様々な異なる種類の情報のいずれかを含むことができる。

１つの実施形態では、データ構造内の第１及び第２の制御情報に関する（単複の）情報を（受信側視聴覚装置などの）受信機が使用して、受信機がどの制御情報を使用でき又は使用すべきか、及びどの制御情報を無視でき又は無視すべきかを判断することができる。例えば、第１のデータ構造は、第１の制御情報を第１のプロトコル・バージョンによるものとして識別し、複数のパケット内の第１の制御情報の位置を提供することができ、従って視聴覚装置が第１の制御情報の第１のプロトコル・バージョンを解析するように構成されていない場合、視聴覚装置は、第１のデータ構造内の情報を使用して第１の制御情報を無視することができる。同様に、いくつかの制御情報の組又はグループが存在する場合、サービス記述子などのデータ構造を視聴覚装置が使用して、視聴覚装置が理解するように構成されていないプロトコル・バージョンを有する複数の制御情報のグループを判断することができ、従って視聴覚装置はこのデータ構造を使用して、視聴覚装置が理解するように構成されていないプロトコル・バージョンを有する制御情報のグループを無視することができる。

２１４において、修正した第１のデータ構造と、第１の制御情報と、第２の制御情報と、第１の制御情報により指定されるマルチメディア・ストリームと、第２の制御情報により指定されるマルチメディア・ストリームとを含む第２の複数のパケットを生成することができる。マルチメディア・ストリームを含むパケットを生成する前に個々のマルチメディア・ストリームを受信及び／又は記憶することができる。第２の制御情報により指定されるマルチメディア・ストリームは、第１の制御情報により指定されるマルチメディア・ストリームと同じマルチメディア・ストリームであってもよく、或いはこれらは２つの異なるストリームであってもよい。例えば、第１の制御情報により指定されるマルチメディア・ストリームを第１のプロトコル・バージョンに基づいて生成することができ、第２の制御情報により指定されるマルチメディア・ストリームを第２のプロトコル・バージョンに基づいて生成することができる。

第２の複数のパケットは、追加のマルチメディア・ストリーム、（追加のマルチメディア・ストリームなどの）追加の制御情報、及び／又は（追加の制御情報に関する位置及びプロトコル・バージョン情報などの情報を提供するような）追加のデータ構造などのその他の情報を含むこともできる。なお、第１のデータ構造（又は第２のデータ構造）は、追加の制御情報に関する追加情報を含むこともでき、例えば単一のデータ構造が複数の制御情報の組又はグループに関する情報を含むことができ、この場合、個々の制御情報の組又はグループは異なるプロトコル・バージョンであってもよく、及び／又はその制御情報のグループにインデックスを付けるために使用できる１又はそれ以上の他の明確な特徴を有することができる。１つの実施形態では、例えば２又はそれ以上のデータ構造が存在する場合、第２の複数のパケットが、この第２の複数のパケットに含まれる複数のデータ構造を指定する情報を含むことができる。

第２の複数のパケットはパケットの別個のサブセットを含むことができ、この場合、マルチメディア・ストリームごとに１つのサブセットが存在する一方で、１つのサブセットが第１の制御情報及び第１のデータ構造を含む。サブセットは別個のものであってもよく、或いはともに混合（多重化など）することもできる。或いは、異なる方法で情報を分離することもでき、或いは全ての生成されたパケットが、マルチメディア・ストリーム、第１の制御情報、及び第１のデータ構造の各々の部分を同様に含むことができる。パケットは、ＩＰｖ４、ＩＰｖ６、ＭＰＥＧ−２などの様々なフォーマットのいずれかに基づいて生成することができる。

２１６において、第２の複数のパケットを送信することができる。第２の複数のパケットは、様々な実施形態による、図１に関して説明したような送信システムにより送信することができる。いくつかの実施形態では、第１の複数のパケットを「送信する」ことが、インターネットサーバなどのサーバにより第１の複数のパケットを提供することを含むことができる。従って、送信システムは、（放送システムのような）１方向通信システムであっても、或いは（インターネット、セルラー・ネットワーク、又はいずれかの２方向通信システムを介するような）２方向通信システムであってもよい。

いくつかの実施形態では、新しいプロトコル・バージョン、サービスなどが開発及び／又は公開されたときに、追加の制御情報、追加の又は修正したデータ構造、追加のマルチメディア・ストリームなどを含む（第３、第４などの）追加の複数のパケットを生成して送信することができる。

マルチメディア・ストリームとともに使用する制御情報を視聴覚装置へ送信するための上述の方法は、様々な実施形態による、マルチメディア・ストリームのための制御情報を視聴覚装置へ送信するためのシステムにより実施することができる。例えば、このシステムは、１又はそれ以上のマルチメディア・ストリームを受信するための入力部、制御情報、データ構造及び／又はパケットを生成及び／又は修正するための送信論理回路、及び／又はパケットを送信するための送信機を含むことができる。

図３−受信フロー図
図３は、視聴覚装置がマルチメディア・ストリームのための制御情報を受信する方法を示すフロー図である。この方法は、あらゆる種類の視聴覚装置により実施することができる。例えば、この方法は、ポータブルコンピュータ・システム（ラップトップ）、（Ｂｌａｃｋｂｅｒｒｙ、ｉＰｈｏｎｅなどの）無線電話機、携帯情報端末、車載型テレビ装置、及び受信した視聴覚情報を表示できるその他の種類の携帯機器などの、上述した図１に示すような移動体装置により実施することができる。或いは、いくつかの実施形態では、この方法を、液晶ディスプレイ（ＬＣＤディスプレイ）テレビ、プラズマ・ディスプレイ・テレビなどの従来のテレビのような、図１に示し上述したような固定装置により実施することができる。なお、様々な実施形態によれば、ステップのうちの１又はそれ以上を省略し、反復し、或いは図３に示し以下で説明するものとは異なる順序で実施することができる。

３０２において、第１の複数のパケットを受信することができる。第１の複数のパケットは、第１のマルチメディア・ストリーム、第１の制御情報、第２の制御情報、及び第１のデータ構造を含むことができる。第１のデータ構造は、第１及び第２の制御情報の位置及びプロトコル・バージョン情報を含むことができる。第１及び第２の制御情報は、異なるプロトコル・バージョンに基づいて生成することができる。個々の制御情報の組は、第１のマルチメディア・ストリームのためのものであってもよく、或いは異なるマルチメディア・ストリームのためのものであってもよい。例えば、第１の複数のパケットは、１又はそれ以上の追加のマルチメディア・ストリームを含むことができる。様々な実施形態では、データ構造をサービス記述子とすることができる。第１及び／又は第２の制御情報は、ＸＣＬの異なるプロトコル・バージョンなどのＸＣＬの実施形態に基づいて生成されたものであってもよい。複数のマルチメディア・ストリームが存在する場合、いくつかのマルチメディア・ストリームは、その他のものとは異なるプロトコル・バージョンであってもよい。

３０４において、第１のデータ構造を分析して第１及び第２の制御情報の位置及びプロトコル・バージョン情報を判断することができる。視聴覚装置は、（位置及びプロトコル・バージョン情報などの）第１のデータ構造を使用して、視聴覚装置自体を構成するためにいずれの制御情報を使用でき又は使用すべきか、及び逆にいずれの制御情報を無視でき又は無視すべきかを判断することができる。従って、第２の制御情報の第２のプロトコル・バージョンを理解するように視聴覚装置を構成することはできず、従って視聴覚装置は、制御情報の位置情報を使用して第２の制御情報を無視することができる。

３０６において、視聴覚装置を第１の制御情報に基づいて構成することができる。第１のプロトコル・バージョンを理解するように視聴覚装置を構成することができる。従って、視聴覚装置は、データ構造内の情報を使用して第１の制御情報の位置を判断するとともに第１の制御情報を解析することができる。従って、視聴覚装置は、視聴覚装置自体を第１の制御情報に基づいて構成することができる。視聴覚装置を構成することにより、視聴覚装置が第１のマルチメディア・ストリームを提示できるようになる。

３０８において、第１のマルチメディア・ストリームを提示することができる。第１のマルチメディア・ストリームを提示するステップは、ディスプレイ上にビデオ情報を提示するステップ、及び／又は１又はそれ以上のスピーカ上に音声情報を提示するステップを含むことができる。

図４−インライン・シグナリングを含むアーキテクチャ
図４は、当業で一般的に使用されるインライン・シグナリングを含むシステム・アーキテクチャを示している。通信システムでは、サービスの処理に関与するシステムブロックの多くによってシグナリング情報を処理させることが通常であり、従ってこれらのブロックは、後方互換性を破壊することなく変更されるように能力が制限されている。例えば、ＦＬＵＴＥはファイル管理プロトコルである。これは、ＯＭＡ ＢＣＡＳＴ及びＤＶＢ−Ｈなどの多くの無線規格におけるシグナリングを含むファイル・ベースのコンテンツを管理するために使用される。シグナリング情報は、送信機からターゲット受信機へＦＬＵＴＥファイル・フォーマットで渡される。このことは、ＦＬＵＴＥ機能を非後方互換的な方法で変更できないこと、及び置き換えることができないことを意味する。ターゲット受信機がバージョン１．０のＦＬＵＴＥ機能を有しており、送信機が（後方互換性がないと仮定される）ＦＬＵＴＥ２．０バージョンのフォーマットでシグナリング情報を送信する場合、受信機はＦＬＵＴＥ機能においてパケットをドロップし、シグナリング機能が、これまでに情報が受信されたという表示を見ることはない。このため、図８及び図９に示しこれに関して説明するシステム・アーキテクチャのように、より低いレベルの信号処理を含むことの方が道理にかなう。

図５−ツリー・ベースのデータ構造
上述したように、拡張可能なシグナリング／バージョニング・フレームワークの１つの側面は、新たな又は修正したシグナリング／バージョニング・データの挿入を、この新たな／修正したシグナリング／バージョニング・データをサポートしていない受信機（視聴覚装置など）がこれをスキップ又は無視できるような方法で可能にするシグナリング／バージョニング情報の構造である。

一般に、現行のシグナリング・スキームは、静的テーブルに依拠してシステム・パラメータ及びその他のシステム構成情報を通信する。このようなテーブルは、生バイナリ値及び列挙タイプの混合を含むパラメータを通信するためのビット定義構造を有することができる。将来的な使用のために数ビットを確保することはできるが、通常は、後方互換性を破壊することなくこのようなテーブルを拡張又は変更することはできない。このようなテーブルの例示的な形式は以下の通りであると考えられる。

このようなテーブルは、ＡＴＳＣ Ｍ／Ｈシステムにおいて送信パラメータ・チャンネル（ＴＰＣ）、高速情報チャンネル（ＦＩＣ）、及びサービスマップ・テーブル（ＳＭＴ）を送信するために使用されてきた。ＴＰＣは、Ｍ／Ｈ通信プロトコルの構成及びＭ／Ｈ通信プロトコルにおける相対的位置を提供する。ＦＩＣは、（仮想チャンネルなどの）Ｍ／ＨサービスとＭ／Ｈアンサンブル（Ｍ／Ｈデータ構造）との間のバインディング情報を提供する。ＳＭＴは、（仮想チャンネルなどの）Ｍ／ＨサービスとＩＰデータグラムとの間のバインディング情報を提供する。

これらのテーブルは、シグナリング情報のための比較的ビット効率の高いフォーマットであり得るが、フォーマットを修正又は拡張するための余地をほとんど残していない。図示のように、このスキームはプロトコル・バージョニングをサポートしておらず、シグナリングするデータに、プロトコル自体に関するシグナリング又はその他の機能への変更ではない変更があった場合、テーブルに含まれるバージョニングビットを使用してシグナリングを行う。

所望の拡張性を提供する１つの選択肢は、テーブル内に単純にテーブル（又はテーブルの一部）のバージョニング情報を含めることである。

静的データテーブルの使用に代わる別の方法に、ツリー・ベースのデータ構造の使用がある。図５は、例示的なツリー・ベースのデータ構造を示している。データツリーは、ルート・ノード、１又はそれ以上の「サブノード」（又は「ブランチ」）、及びブランチごとに１又はそれ以上のリーフを含むことができる。ツリーはまた、「サブ‐サブノード」（又は「ツイッグ」）などの追加の層を望む通りに有することもできる。

ツリー・ベースのデータ構造は、個々のノード及び／又はリーフを、これらのバージョニング情報及び（パラメータ値などの）実際の１又は複数の値の両方の観点から個別に定義できるようにする。ツリー・ベースのデータ構造はまた、後方互換性を破壊することなくノードを追加できるようにもする。従って、ツリー・ベースのデータ構造は、静的データテーブルよりもかなり高い拡張性及び後方互換性を提供することができる。ツリー・ベースのデータ構造を使用する通信は、潜在的に大量の追加オーバーヘッドを招く可能性があり、例えば、ツリーとともに使用する命令セット次第では、ビット効率が静的テーブルよりも低くなる可能性がある。しかしながら、図１５〜図１７に関して以下で説明するようなビット効率の高い命令セットを使用すれば、この問題を大幅に軽減することができ、例えば、ビット効率の高い命令セットが与えられると、ツリー・ベースのデータ構造を使用する通信は、ビット効率においてデータテーブルを使用することに匹敵することができる。

図６及び図７−ＡＴＳＣ Ｍ／Ｈ機能ブロック
図６は、ＡＴＳＣ Ｍ／Ｈシステムをバージョニングのための機能ブロックの組に区分する例を示している。本明細書では、機能の更新に改訂番号を割り当てるための、及びレガシーバージョン及び現行バージョンの受信機とのロバストな通信を同時にサポートできるように改訂番号を通信するための方法論を定めるためにバージョニングという用語を使用する。この結果、この方法論を使用して、所定の送信機からレガシー受信機と現世代受信機に同時にサービスを拡張することができる。

図６に示すように、機能ブロックを複数のプロトコル・スタックの層に分割することができる。従って、１つの実施形態では、プレゼンテーション層、管理層、及び物理層が存在することができる。個々のプロトコル層はいくつかの要素を含むことができ、例えば図示のように、プレゼンテーション層は、サービスガイド、グラフィック要素、キャプショニング、音声コーデック、及びビデオコーデックを含むことができる。プロトコル層内に異なるプロトコル層及び／又は異なる要素を含む他の様々なプロトコル・スタックも考えられる。なお、例えば本発明のいくつかの実施形態では、受信機のプロトコル・スタックを修正し又は置き換える。従って、１つの実施形態では、新しいプロトコル・バージョンが、プロトコル・スタックの１又はそれ以上の要素の追加、置換、回収、又は再構成を指定することができる。１つの実施形態では、図７に示すようなツリー・ベースの構造を使用して、（例えば、新しいプロトコル・バージョンがサポートされている場合には）改訂されたプロトコルスタックに基づいて、或いは（例えば、新しいプロトコル・バージョンがサポートされていない場合には）以前のプロトコルスタックに基づいて装置をナビゲート及び構成することができる。

図７は、図６に示すＡＴＳＣ Ｍ／Ｈプロトコル・スタックの一部のツリーバージョンを示している。個々のプロトコル要素を、（プロトコル・スタックなどの）ツリーのそれぞれの（プロトコル層などの）ノードのリーフとして列挙することができる。このようにして、個々のノード及び要素を別々にバージョニングすることができる。

図８及び図９−例示的なアーキテクチャ
図８及び図９は、シグナリング及び／又はバージョニング処理機能をシステム内の下位に置き及び／又はサービスの処理から分離した例示的な受信機システムのアーキテクチャを示している。このアーキテクチャは、図４に関して説明した問題を軽減することができる。図８及び図９は例示的なものにすぎず、従って他の受信機アーキテクチャも考えられる。

図１０−パケットフォーマット
図１０は、１つの実施形態による、マルチメディア・ストリームのためのシグナリング／バージョニング・データ（又は単純に「制御情報」）を通信するために使用できるパケットフォーマットを示している。図示のように、パケットは、ヘッダ、長さ、フラグメント番号、サービス記述子、命令／修飾子、データ、及びＣＲＣ１６用のフィールドを含むことができる。ヘッダ、長さ、フラグメント番号、サービス記述子、及びＣＲＣ１６の位置は固定することができる。サービス記述子のコンテンツは構成可能であってもよい。制御ストリーム自体が、連結された一連の命令／修飾子／データのニブルを含むことができる。図１０は１つの例示的なパケット・フォーマットを示しているが、異なるサイズのフィールド、追加のフィールド、少ないフィールド、類似してはいるが修正されたフィールド、及び／又はあらゆる数のその他の相違を含むパケットを含むあらゆる数のその他のパケットフォーマットが考えられる。以下、この例示的なパケット・フォーマットのフィールドの定義及びさらなる説明を図１１に関して行う。

図１１−制御パケットフィールドのテーブル
図１１は、１つの実施形態による制御パケットのフィールドを定義するテーブルである。図１０に関して上述したように、１つの実施形態では、フィールドが、ヘッダ、長さ、フラグメント番号、サービス記述子、命令／修飾子、データ、及びＣＲＣ１６を含むことができる。

ヘッダは長さを４ビット（１ニブル）とすることができる。ヘッダは、制御パケットのバージョン番号を含むことができる。換言すれば、これにより、シグナリング方法自体のバージョニング情報をシグナリングする手段が提供される。従って、以下で説明するフィールドは、バージョン１．０の制御パケット内でフィールドを定義する可能性があるのに対し、将来的なバージョンは、フィールドを別様に定義し又は異なるフィールドを含む可能性があり、シグナリング方法のバージョンをシグナリングすることにより、受信機が（例えば、受信機のソフトウェアを新しいバージョンに対応するように更新し、或いは互換性がない場合には新しいバージョンを無視することによって）シグナリング方法に対する将来的な更新に対処できるようにすることができる。

長さフィールドは、長さを８ビット（２ニブル）とすることができる。長さフィールドは、（パケット長フィールドの後ろから始まりパケットの最後のバイトで終わるフィールドとして定義される）バケット本体の長さをバイトで与える。パケットをサポートできないことをパケットヘッダにより認識する受信機は、少なくともこのフィールドを解析して、パケットがどのくらい大きいか、ひいては制御ストリーム内の次のパケットを解析しようと試み始めるためにはどこまでスキップすべきかを判断することができる。

フラグメント番号フィールドは長さを４ビット（１ニブル）とすることができる。フラグメント番号フィールドは、（例えば、００００の値から開始するのではなく）０００１の値から開始して、パケット内のフラグメントの番号を与える。００００の値は、フラグメンテーションが使用されていないことを示す特別な値とすることができる。

サービス記述子は可変数のビットとすることができる。サービス記述子フィールドは、サービス識別子（ＩＰアドレス）、メジャー・チャンネル番号などによって参照されるサービスにバージョニングされたシグナリング・ストリームをマップする。サービス記述子又はサービス発見テーブルを使用して、例えば受信機が、制御情報内のいずれの（単複の）部分をサポートできていずれの（単複の）部分をサポートできないか、及び／又は受信機が提示しようと試みている特定のサービスに制御情報のどの部分を関連付けることができるかを判断できるように制御情報にインデックスを付けることができる。サービス記述子の実施形態のさらなる詳細については、図１２〜図１４に関して以下で示す。

命令、修飾子、及びデータ・フィールドは、制御パケットの制御情報を構成する。換言すれば、これらのフィールド内の命令、修飾子、及びデータは、シグナリング／バージョニング情報の（ツリー構造などの）構造をナビゲートして、付随するマルチメディア・ストリームを提示するように視聴覚装置を構成するための手段とすることができる。１つの実施形態によれば、個々の命令、修飾子、又はデータ・フィールドを４ビット（１ニブル）とすることができ、或いはニブルの増分の形で無制限に拡張することができる。このようにして、上記手段を拡張可能とすることができる。本明細書で「拡張可能制御言語」（「ＸＣＬ」）と呼ぶ命令セットの実施形態に関するさらなる詳細については、図１５〜図１７に関して以下で示す。

ＣＲＣ１６は、エラー検出／訂正の目的で使用できる、パケットの全長を通じて計算した１６ビットの巡回冗長検査である。

図１２−サービス記述子フォーマット
図１２は、１つの実施形態による、ＸＣＬパケット内のサービス記述子フィールドのフォーマットを示している。サービス記述子は、構成可能なコラムタイプを含むテーブルとしてフォーマットすることができる。サービス記述子フィールドは、サービス記述子タイプ、サービス記述子長、コラム数、及びコラム長ごとにサブフィールドを含むことができる。サービス記述子フィールドはまた、コラムタイプ、及びテーブル内のコラムごとのデータサブフィールドを含むこともできる。

図１３−サービス記述子フィールドのテーブル
図１３は、１つの実施形態による、ＸＣＬパケットのサービス記述子フィールドを構成するサブフィールドを定義するテーブルである。図１２に関して上述したように、サービス記述子タイプ、サービス記述子長、コラムの数、コラム長、コラムタイプ、及びデータのためのサブフィールドが存在することができる。個々のサブフィールドは長さを４ビット（１ニブル）とすることができ、或いはニブルの増分の形で無制限に拡張することができる。

サービス記述子タイプを使用して、サービス記述子をバージョニングすることができる。換言すれば、サービス記述子を、全体としての制御パケットのバージョニングとは別に（或いはこれに加えて）バージョニングすることができる。従って、以下で説明するフィールドは、サービス記述子の１つのバージョンに関してサブフィールドを定義する可能性があるのに対し、将来的なバージョンは、フィールドを下位に別様に定義し又は異なるフィールドを含む可能性があり、バージョンをヘッダとしてシグナリングすることにより、受信機が、実際にサービス記述子の本体を解析しようと試みる前にサービス記述子を解析できるかどうかを判断することができる。従って、受信機が特定のサービス記述子を解析するように構成されていない場合、受信機は、受信機のソフトウェアを新しいバージョンに対応するように更新し、或いは新しいバージョンに対応できない場合には新しいバージョンを無視することができる。

サービス記述子長サブフィールドは、サービス記述子フィールドの長さをニブルで指定する。サービス記述子をサポートできないことをサービス記述子タイプにより認識する受信機は、少なくともこのフィールドを解析して、サービス記述子がどのくらい大きいか、ひいては制御ストリーム内の（受信機が解析できる別のサービス記述子などの）次の１つの情報を解析しようと試み始めるためにはどこまでスキップすべきかを判断することができる。

コラム数（すなわち「ＮｕｍＣｏｌｕｍｎｓ」）サブフィールドは、テーブル内のコラム数を指定するとともに、次に来るコラムタイプ及びデータ・サブフィールドの数も効果的に指定する。コラム長サブフィールドは、個々のコラム内の項目数を指定する。全てのコラムは同じ長さとすることができる。コラム数及びコラム長を指定するフィールドを含むことにより、サービス記述子は、基本的にサービス記述子自体を定義することができる。従って、サービス記述子は、設計により非常に柔軟なデータ構造とすることができ、かなりの量のフォーマットの修正及び／又は変化を可能にすることができ、ひいては新しいプロトコル・バージョンを必要とせずに情報を提供することができる。

コラムタイプサブフィールドは、次に来るデータ・フィールド内の情報のタイプを指定する。所与のサービス記述子のバージョンに関して様々な考えられる情報のタイプを列挙することができ、タイプ例として、バージョン番号、ストリームＩＤ、ＩＰアドレス、メジャー・チャンネル番号、又はマイナー・チャンネル番号が考えられる。

データサブフィールドは、コラムの項目ごとに値を指定する。上述したように、項目の数は、コラム長サブフィールドにより指定される。個々の項目の長さは、コラムタイプの一部として指定（例えば定義）することができる。例えば、コラムタイプがＩＰｖ４である場合、項目を３２ビットとすることができる。

図１４−例示的なサービス記述子フィールド
図１４は、サブフィールドにより細分化された例示的なサービス記述子フィールドを示すテーブルである。この例では、サービス記述子タイプの値を、基本バージョンを示す「００００」とすることができる。サービス記述子長は、サービス記述子内に１１（バイナリでは１０１１）ニブルが存在することを示す「１０１１」とすることができる。コラム数は、３つ（バイナリでは００１１）のコラムが存在することを示す「００１１」とすることができる。コラム長は、個々のコラムが１つの項目を含むことを示す「０００１」とすることができる。次に３つのコラム・タイプ・サブフィールドが後続することができ、これらの各々に１項目のデータ・サブフィールドが後続するる。この例では、コラム・タイプは、（「００００」として列挙する）バージョン番号、（「０００１」として列挙する）メジャーチャンネル番号、及びオフセット・ベクトル（００１０）である。換言すれば、このサービス記述子は、基本バージョン「００００」であるメジャーチャンネル「０００１」の制御情報がオフセット・ベクトル００１０に位置することを指定する。

単一のサービス記述子を使用して、制御情報の複数の部分にインデックスを付けることができる。例えば、サービス記述子は、特定のサービス及び／又は特定のプロトコル・バージョンのためのものとすることができる第１の命令グループを示すことができ、また異なるサービス及び／又は異なるプロトコル・バージョンのためのものとすることができる第２の命令グループを示すこともできる。従って、いくつかの命令グループが存在するものの１つのグループのみが１．０の基本バージョンを有し、他の全てのグループがより高い基本バージョンを有する場合、基本バージョン１．０しかサポートできないレガシー受信機はサービス記述子を解析することができ、これによりこの受信機は、基本バージョン１．０を有するグループをサポートすることができるが、より高い基本バージョンを有するグループをサポートすることはできない（及び従って無視又はスキップすることができる）と判断することができる。

これと同様に、或いはこれとは別に、いくつかの実施形態では複数のサービス記述子を使用することもできる。例えば、新しいプロトコル・バージョンのサービス記述子をより古いプロトコル・バージョンのサービス記述子とともに使用して、レガシー装置が受信できるサービスを判断できるようにするとともに、現在の装置が新しいプロトコル・バージョンを有するサービス記述子を使用して、受信できるサービスを判断できるようにすることもできる。いくつかの実施形態では、現在の装置が複数（例えばこの例では、新しいサービス記述子及び古いサービス記述子の両方）のサービス記述子を使用して、受信できるサービスを判断することができる。

図１５−命令シリーズのフォーマット
図１５は、一連の命令／データの１つの考えられるフォーマットを示すテーブルである。図示のように、実行すべき命令、（例えば、レガシー受信機が未知の命令をスキップできるようにするための）バイト単位の命令ペイロード長、指定すべき（単複の）パラメータが位置するリーフ又はノードを指定する１又はそれ以上のナビゲーションフィールド、及び設定すべき実際の（単複の）パラメータ、のためのフィールドが存在することができる。

図１６−ＸＣＬ命令セット
上述したように、制御パケット内のサービス記述子フィールドに続いて、連結された一連の命令／修飾子／データのニブルが存在することができる。図１６は、ツリー・ベースのデータ構造を通信及びナビゲートするための１つの考えられる命令セットを定義するテーブルである。上述したように、この命令言語の実施形態を本明細書では「ＸＣＬ」と呼ぶ。

ＸＣＬ言語は、データを構成する柔軟で拡張可能な方法であり、より詳細には、ツリー・ベースの情報を非常にビット効率の良い方法で符号化する方法である。この方法は、可変数のデータ・フィールドが後続し、ツリー内のノード及び各々に位置する対応するパラメータ値を通信するために使用される命令セットを含むことができる。この方法は、データテーブルをパラメータのグループに区分して、個々のグループを、テーブル内のパラメータセットの位置を指定するヘッダにカプセル化することに類似する。実際にこの方法は、別の考えられる実施形態になる。この構造化されたフォーマットでパラメータを表現することにより、パラメータセットを前方互換性のある方法で追加又は削除することをサポートする。未認識のノードに遭遇したレガシー受信機はこれをスキップして、この受信機がサポートするデータの解析を継続することができる。

この言語は、ツリーのセクション全体にわたって適用でき、数多くのノードが同様の性質の値を有することを伝える簡単な方法を可能にし、従って各ノードへの経路と各修正パラメータの値とを別個に表現する必要を無くすパラメータである修飾子の組を含むこともできる。この能力は、複数のパラメータグループをヘッダとともにカプセル化するヘッダに匹敵する。この能力の使用例として、修飾子を使用して、ツリーのセクションの全てのパラメータがＡＴＳＣ Ｍ／Ｈバージョン１．０対応であること、或いはツリーの１つのセクションのパラメータがツリーの別のセクションのパラメータと最小限の相違で同じであることを指定することが挙げられる。修飾子を使用して後者の用途を指定する場合、匹敵するノードの位置及び相違のみを指定することができる。

１つの実施形態では、命令及びデータ・フィールドを、ニブル、バイト、又は他のいずれかの固定境界に基づいて体系化することができる。例示的な実施形態としてニブル境界をとり、個々のニブルの１ビットを使用してニブルに命令又はデータのいずれかとしてマーキングを行うことができる。例えば、１つの実施形態では、最上位ビット（ＭＳＢ）を使用することができる。従って、この実施形態では、ＭＳＢが「０」である場合には命令をマーキングされる一方で、ＭＳＢが「１」の場合にはデータをマーキングされる。受信機が命令及びデータ情報を解析できるようにする上で、この約束、又は命令及びデータニブルをこのようにマーキングするためのあらゆる同様の約束が有用になる可能性があり、例えば受信機は、各々が「０」で始まる一連のニブルは命令であり、これらの命令に続く各々が「１」で始まる１又はそれ以上のニブルはこれらの命令により指定されるデータであると判断することができる。従って、受信機は、データ（例えば、ノード又はリーフに対するパラメータ）が後続する（ツリー内のノード又はリーフにナビゲートするような）一連の命令を解析することができ、またデータがどこで終わり、次の一連の命令が「０」のＭＳＢを有する次のニブルとしてどこから始まるかを認識することができる。いくつかの実施形態では、これにより、専用の長さフィールドを使用するオーバーヘッドを節約して個々の命令シーケンスの長さを受信機に示すことができる。いくつかの実施形態では、依然として長さフィールドを命令の一部又は全てとともに使用することができる。命令又はデータ・フィールドの小さい方から３つのビット（ＬＳＢ）が、フィールドのための列挙命令又はデータ値が何であるかを示すことができる。

必要な場合、この３つのＬＳＢを「１１１」に設定し、又は他の実施形態では、フィールドの拡張を示すように指定された他のいずれかの値に設定することにより、命令又はデータ・フィールドを拡張することができる。このようにして、レガシー受信機の命令ストリームを解析する能力を妨げずに命令セットを無制限に拡張することができる。すなわち、たとえ受信機が拡張されたフィールド内の命令を認識しない場合でも、受信機は、フィールドが拡張されたことを認識して次のフィールドにスキップすることができる。

図１６は、１つの実施形態による個々の命令の簡単な説明を含む。これらの考えられる命令の各々のより詳細な説明を以下に示す。

ノード（又はグループ）ポインタは、階層ツリー構造内のパラメータ（又はパラメータのグループ）を示す。ノード命令は、ナビゲーションをパラメータ仕様と組み合わせる。ノード命令は可変数のデータ・フィールドを含み、いくつかはトラバースされるノードを指定するものであり、１つはリーフ位置を指定するものであり、最後の１つはパラメータ／機能セットを指定するものである。ノード命令を使用する場合、現在のノード位置が、パラメータを設定するために参照されるリーフの真上のノードに設定される。例えば、受信機がデフォルトノード０にあり、位置０．１．０．０にあるリーフをｖａｌｕｅ＿１に設定したいと望む場合、命令は、０００１（命令），１００１（データ），１０００（データ），１０００（データ），ｖａｌｕｅ＿１（データ）となる。最後のデータ・フィールドはパラメータ値である。最後から２番目のデータ・フィールドはリーフ位置であり、現在のノードは０．１．０の真上にある。

降下命令は、階層ツリー構造内の現在の位置よりも下にあるパラメータ位置までの（下向きの）相対パスを指定する。この命令は、ツリー内の新しいノードにナビゲートするために使用される。降下命令は可変数のデータ・フィールドを含み、これらの各々がトラバースすべきノードを指定する。次の命令ニブルの前に、降下命令の後にいくつのデータ・フィールドが続くかによって、トラバースすべきノードの総数を判断することができる。例えば、受信機が現在デフォルト・ノード０を示しており、ノード０．１．１を示すことが望まれる場合、降下命令は、０１００（命令），１００１（データ），１００１（データ）となる。命令及びデータ値は、（命令又はデータなどの）これらのタイプごとにこれらのＭＳＢセットとともに示している。受信機は、現在のノード位置を追跡することができ、従って現在のノードに関して全てのナビゲーション命令を構成することができる。或いは、個々のナビゲーション命令がルート・ノードから開始することができ、この場合、以下で説明する上昇命令が必要となり得る。

上昇命令は、階層ツリー構造内の（上向きに）トラバースすべきレベルの数を指定する。上昇命令は、降下命令を指定されたレベルの数だけ逆転させる。ツリー内の個々の子ノードは親を１つしか持たないので、さらなる仕様は不必要となり得る。

修飾子命令は、階層構造内の現在の位置よりも下にある全てのパラメータに適用すべき値を指定する。修飾子命令は、たった１つの位置ではなくツリーの複数のセクションにおけるパラメータを指定するための特別な命令である。修飾子命令を使用するための最初のステップは、降下命令を使用してツリー内の所望のノード位置にナビゲートすることである。次に、降下命令の後に修飾子命令及び関連フィールドを適用することにより修飾子が加えられる。修飾子は、ＸＣＬ命令内のいずれの場所に挿入してもよいが、（単複の）パラメータを指定するためのナビゲーションと修飾子を指定するためのナビゲーションとを組み合わせるように配置した場合に最も効果的にすることができる。修飾子はまた、共通の値で設定できるパラメータがともに同じノードの下でグループ分けされるようにツリー・データを構成した場合にも最も効果的にすることができる。

この命令セットはＸＣＬの１つの考えられる実施形態であり、図２４に示す命令セットのようなあらゆる数のその他の変形例も考えられる。

図１７−ＸＣＬ命令セット修飾子
上述したように、修飾子命令は、後続するデータが特定の修飾子及び１又はそれ以上の対応する修飾子値を含むことを指定し、このことは現在のノードよりも下にあるツリーの全てのノードに当てはまる。図１７は、１つの実施形態によるこれらの修飾子の各々を列挙して定義するテーブルである。以下、これらの考えられる修飾子の各々についてさらに説明する。

サブバージョン（又はプロトコル生成）修飾子は、現在のノードよりも下にあるノードにおいて指定されるパラメータのプロトコル副生成を指定する。これは、特定の基本サブシステムの生成である。全体としてのサービスのプロトコル生成は、ナビゲートされたツリーのルート位置により指定することができる。

例外修飾子は、現在のノードよりも下にあるノードにおけるデータ・パラメータが、指定された最新の修飾子の例外であることを指定する。

任意的修飾子は、現在のノードよりも下にあるノードにおけるあらゆるデータ・パラメータが任意の拡張であることを指定する。修飾子命令に「任意の」データ・フィールドを後続させ、これを（単複の）パラメータが存在するノードに適用して特に注記しない限り、指定された全てのパラメータを要求することができる。この修飾子は、例えば、全体としてサービスとは異なる基本プロトコル・バージョンの可能性がある任意の構成要素をサービスに含めるために有用である。これにより、レガシー装置が任意の構成要素を伴わずにサービスを使用できるようになると同時に、新しい受信機が（例えばサービス拡張させる）任意の構成要素を使用できるようになる。

複製修飾子は、複製を行うための位置にある階層ノードを指定する。すなわち、指定されたノードからの全てのパラメータを現在の位置にコピーすることができる。

将来的な使用のために１又はそれ以上の値を、修飾子フィールドを拡張するための値とともに確保して、例えば確保した値を全て使用した場合でも、基本的により多くの修飾子を定義できるようにすることができる。図示の実施形態では、修飾子に関する「拡張フィールド」値は「１１１１」である。

図１７は１つの考えられる命令修飾子の組を示しているが、あらゆる数の実施形態が可能であり、例えば代替の実施形態を図２５に示している。

図１８−ＡＴＳＣ Ｍ／Ｈツリー
図１８は、１つの実施形態による、ＡＴＳＣ Ｍ／Ｈプロトコルスタックのツリー・ベースのバージョンの一部を示している。上述した命令を使用して、このようなツリーをナビゲートできるとともに、バージョニング及びパラメータ情報をビット効率の高い方法で提供することができる。

図１９−ＡＴＳＣ Ｍ／Ｈツリー
図１９は、ＡＴＳＣ Ｍ／Ｈツリーの別の表示を示している。なお、このツリーは、ＦＩＣ、ＳＭＴ、ＣＩＴ、ＳＴＴ、ＳＬＴ、及びＧＡＴなどの、システム構成シグナリング「テーブル」の全てのリーフを含み、これによりこれらのテーブル（又はツリー）をバージョニングすることもできるようになる。いくつかの実施形態では、このようなツリーを、ツリーを符号化するために使用される（ＸＣＬなどの）命令言語を利用するような方法で具体的に構成することができる。例えば、必要なノード数を最小にして個々のノードにおけるリーフ数を最大にすることにより、ＸＣＬの能力を最大限に活用するようにテーブルデータを最適に構築することができる。これにより、ナビゲーションオーバーヘッドを最小化することができる。使用する命令言語に応じて、このようなツリーの構成にいくつかの規則を適用することもできる。例えば、上述したＸＣＬの実施形態では以下の規則を適用することができる。
１）ノードは、ナビゲーションのためだけのものであり、パラメータ（データ）を含まない。
２）新しいノードは、別の（リーフではなく）ノードにしか追加することができない。
３）ノードは、ツリーの将来的なパラメータを加える必要があると思われる位置に配置される。
４）パラメータはリーフに位置する。リーフは、ノードの終端ポイントにおける位置である。
これらの規則は例示的なものにすぎず、従って使用する命令セットに応じ、シグナリング・フレームワークの効率を改善する際には異なる規則の組が必須又は有用となり得る。

いくつかの実施形態では、通常、プロトコル生成ごとに（ＦＩＣツリーなどの）所与のツリーを１回定義することができる。その後、オリジナル・ツリーの修正としてテーブルに追加及び削除を行って順序を維持することにより、ツリー内の位置が情報を伝えるようになる（例えば、ノード０から降下するツリーは常に最初のプロトコル生成サービスである）。

データのためのシグナリング構造を構築する場合、データをツリー化する程度によりデータの柔軟性及び拡張性が制御される。柔軟性を最大にするために、個々のパラメータを別個のリーフに位置付ける（例えばツリーを完全に解明する）ことができる。或いは、パラメータを個々のリーフでグループ分けすることにより、より効率的なシグナリング構造を実現する（例えばツリーを部分的に解明する）ことができる。

図２０−ＦＩＣツリー
図２０は、個々のノードにおいてツリーを将来的に拡張するための仮説ノードを含む、ＦＩＣの部分的に解明されたツリー表示を示している。このツリーは、図１９のツリーと組み合わせて使用することができる（例えば、ＦＩＣルート・ノードは、図１９に示すシステム構成ツリー内のノード０．８．０である）。例えば、図示してはいるが「（単複の）将来的なフィールド」を有していないツリーは、バージョン１．０のＦＩＣツリーとすることができる。バージョン１．１のＦＩＣツリーは、「（単複の）将来的なフィールド」の１又はそれ以上を示す１又はそれ以上の追加のフィールドを含むことができる。この場合、追加のノード及び／又はリーフをバージョン１．１とする一方で、オリジナルノード及びリーフを１．０のままとすることができる。バージョン２．０のＦＩＣツリーは完全に異なる構造を有することができ、例えば再構成したり、又は異なるフィールドを含んだりすることができる。

図２１−ＦＩＣツリーの例示的符号化
図２１は、図１５〜図１７に関して上述したＸＣＬの実施形態による、図２０に示すＦＩＣテーブルの一部の例示的な符号化を示している。図２１は、制御パケットの命令／データ部分（例えば制御情報）のみを示しており、いくつかの実施形態では、これは、（図１０で説明したようなパケット・ヘッダ、長さなどの）その他のフィールドも含む制御パケットのほんの一部とすることができる。

図２２−ＳＭＴツリー
図２２は、個々のノードにおいてツリーを将来的に拡張するための仮説ノードを含む、ＳＭＴの部分的に解明されたツリー表示を示している。このツリーは、図１９のツリーと組み合わせて使用することができる（例えば、ＳＭＴルート・ノードは、図１９に示すシステム構成ツリー内のノード０．５．０である）。例えば、図示してはいるが「（単複の）将来的なフィールド」を有していないツリーは、バージョン１．０のＳＭＴツリーとすることができる。バージョン１．１のＳＭＴツリーは、「（単複の）将来的なフィールド」の１又はそれ以上を示す１又はそれ以上の追加のフィールドを含むことができる。この場合、追加のノード及び／又はリーフをバージョン１．１とする一方で、オリジナルノード及びリーフを１．０のままとすることができる。バージョン２．０のＳＭＴツリーは完全に異なる構造を有することができ、例えば再構成したり、又は異なるフィールドを含んだりすることができる。

図２３−ＳＭＴツリーの例示的符号化
図２３は、図１５〜図１７に関して上述したＸＣＬの実施形態による、図２２に示すＳＭＴテーブルの一部の例示的な符号化を示している。図２３に示すコードは、図２３の最上位に示す「ヘッダ」、「長さ」、「フラグメント番号」、及び「サービス記述子」フィールドによって示されるより大きな制御パケットの一部とすることができる。

図２４及び図２５−ＸＣＬ命令の代替の実施形態
図２４及び図２５は、ＸＣＬ命令及び命令修飾子の代替の実施形態をそれぞれ示している。従って、図１５〜図１７に関して図示し説明したＸＣＬは、ツリー・ベースの情報を符号化するための命令セットの１つの実施形態とすることができ、これとは別に、図２４及び図２５に示す組又はいずれかのこのような命令セットを、ツリー・ベースの情報を非常にビット効率の高い方法で符号化する柔軟で拡張可能な方法として望む通りに使用することができる。

図２６〜図２８−ＦＩＣ及びＳＭＴデータツリーの代替の実施形態
図２６〜図２８は、データツリーのいくつかの代替の実施形態を示している。図２６は、１つの実施形態によるＦＩＣの完全に解明されたツリー表示を示している。データツリーを完全に解明することにより、ツリーの柔軟性及び拡張性が最大化され、「複製」命令修飾子で冗長性をさらに効果的に活用して、ツリーを完全に解明することにより生じる追加のナビゲーションオーバーヘッドを最小化することができる。

或いは、ツリーを完全に解明する代わりに、図２７に示すようにツリーを部分的に解明することもできる。このようにして、類似の、或いは同時に又は同じ方法で修正される可能性のあるリーフのグループを使用して、ツリーをナビゲートする際に伴うオーバーヘッドを低減させることができる。しかしながら、この方法はツリーの柔軟性及び拡張性を制限し、同時に及び同じ方法で変更される可能性のあるリーフを予想するためにグループ分けを適切に設計しなければならない。

図２８は、部分的に解明されたＳＭＴデータツリーの代替の実施形態を示している。

上記の実施形態についてかなり詳細に説明したが、当業者には、上記の開示を十分に理解した時点で数多くの変形及び修正が明らかになるであろう。以下の特許請求の範囲は、全てのこのような変形及び修正を含むと解釈すべきであることが意図される。
なお、この明細書に開示した技術の態様を列挙すれば次のようである。
（アイテム１）
マルチメディア・ストリームを視聴覚装置へ送信する際に使用するための制御情報を生成する方法であって、
マルチメディア・ストリームを提示できるよう前記視聴覚装置を構成する第１の制御情報を、第１のプロトコル・バージョンに従って生成するステップと、
前記第１の制御情報に関する情報を含むとともに、前記第１の制御情報が前記第１のプロトコル・バージョンであることを指定する第１のデータ構造を生成するステップと、
前記第１の制御情報により指定される少なくとも１つのマルチメディア・ストリームと、前記第１の制御情報と、前記第１のデータ構造とを含んでいる第１の複数のパケットを生成して送信するステップと、
マルチメディア・ストリームを提示できるよう前記視聴覚装置を構成する第２の制御情報を、第２のプロトコル・バージョンに従って生成するステップと、
前記第１のデータ構造を、前記第２の制御情報に関する追加の情報を含むとともに、前記第１の制御情報に関する情報を保持するように修正するステップと、
前記修正した第１のデータ構造と、前記第１の制御情報と、前記第１の制御情報により指定されるマルチメディア・ストリームと、前記第２の制御情報と、前記第２の制御情報により指定されるマルチメディア・ストリームとを含んでいる第２の複数のパケットを生成して送信するステップと、
を含むことを特徴とする方法。
（アイテム２）
前記第１の制御情報は、前記マルチメディア・ストリームを第１の手法で提示するように前記視聴覚装置を構成するためのものであり、前記第２の制御情報は、前記マルチメディア・ストリームを第２の手法で提示するように前記視聴覚装置を構成するためのものである、
ことを特徴とするアイテム１に記載の方法。
（アイテム３）
前記第１のデータ構造が、前記第１の制御情報が存在する前記第１の複数のパケット内の１又はそれ以上の位置を指定し、前記修正した第１のデータ構造が、前記第２の制御情報が存在する前記第２の複数のパケット内の１又はそれ以上の位置を指定する、
ことを特徴とするアイテム１に記載の方法。
（アイテム４）
前記第１の制御情報に関する情報が、前記第１の制御情報内の第１の命令の１又はそれ以上のタイプ及び１又はそれ以上の位置を指定し、前記第２の制御情報に関する追加情報が、前記第２の制御情報内の命令の１又はそれ以上のタイプ及び１又はそれ以上の位置を指定する、
ことを特徴とするアイテム１に記載の方法。
（アイテム５）
前記第１のデータ構造を修正するステップが、前記第１のデータ構造のフォーマットを修正するステップを含み、
前記第１のデータ構造のフォーマットを指定する情報を、前記第１のデータ構造を修正するステップを反映するように修正するステップをさらに含む、
ことを特徴とするアイテム１に記載の方法。
（アイテム６）
前記第１のデータ構造のフォーマットを指定する情報を修正するステップが、前記修正した第１のデータ構造のバージョン情報を修正するステップを含む、
ことを特徴とするアイテム５に記載の方法。
（アイテム７）
前記第１のデータ構造のフォーマットを指定する情報を変更するステップが、前記修正した第１のデータ構造のサイズ情報を修正するステップを含む、
ことを特徴とするアイテム５に記載の方法。
（アイテム８）
前記第１のデータ構造を修正するステップが、前記第１のデータ構造のフォーマットを修正するステップを含み、前記第１のデータ構造が、前記第１のデータ構造のフォーマットを指定する情報を含み、
前記修正した第１のデータ構造内の前記第１のデータ構造のフォーマットを指定する情報を、前記第１のデータ構造を修正するステップを反映するように修正するステップをさらに含む、
ことを特徴とするアイテム１に記載の方法。
（アイテム９）
マルチメディア・ストリームを提示するように前記視聴覚装置を構成するための、第３のプロトコル・バージョンに基づいて生成される第３の制御情報を生成するステップと、
前記第３の制御情報に関する情報を含むように第２のデータ構造を生成するステップと、
前記修正した第１のデータ構造と、前記第１の制御情報と、前記第１の制御情報により指定されるマルチメディア・ストリームと、前記第２の制御情報と、前記第２の制御情報により指定されるマルチメディア・ストリームと、前記第３のデータ構造と、前記第３の制御情報と、前記第３の制御情報により指定されるマルチメディア・ストリームとを含む第３の複数のパケットを生成して送信するステップと、
をさらに含むことを特徴とするアイテム１に記載の方法。
（アイテム１０）
前記第１のデータ構造が、前記第１の制御情報の第１のプロトコル・バージョンと前記第１の制御情報の位置とを識別する情報を含み、前記視聴覚装置が前記第１の制御情報の第１のプロトコル・バージョンを解析するように構成されていない場合、前記第１の制御情報の第１のプロトコル・バージョンと前記第１の制御情報の位置とを識別する前記情報を視聴覚装置が使用して、前記第１の制御情報を無視することができる、
ことを特徴とするアイテム１に記載の方法。
（アイテム１１）
前記第１のデータ構造が、追加の制御情報に関する追加情報を追加するように拡張可能に構成される、
ことを特徴とするアイテム１に記載の方法。
（アイテム１２）
前記第１のデータ構造が複数のフィールドを含み、該フィールドの少なくとも１つが拡張可能である、
ことを特徴とするアイテム１に記載の方法。
（アイテム１３）
前記少なくとも１つの拡張可能なフィールドが、該フィールドの値を特定の値に設定することにより拡張され、前記特定の値が、前記拡張可能なフィールドが拡張されたことを視聴覚装置に示す、
ことを特徴とするアイテム１２に記載の方法。
（アイテム１４）
前記第１のデータ構造を、後から生成されたパケット内の追加の制御情報に関する追加情報を含むように構成することができる、
ことを特徴とするアイテム１に記載の方法。
（アイテム１５）
前記第２の複数のパケットが、該第２の複数のパケットに含まれる複数のデータ構造を指定する情報を含む、
ことを特徴とするアイテム１に記載の方法。
（アイテム１６）
視聴覚装置へマルチメディア・ストリームを送信する際に使用するための制御情報を生成する方法であって、
マルチメディア・ストリームを提示するように前記視聴覚装置を構成するための、第１のプロトコル・バージョンに基づいて生成される第１の制御情報を生成するステップと、
前記第１の制御情報に関する情報を含むとともに、前記第１の制御情報が前記第１のプロトコル・バージョンであることを指定する第１のデータ構造を生成するステップと、
前記第１の制御情報により指定されるマルチメディア・ストリームと、前記第１の制御情報と、前記第１のデータ構造とを含む第１の複数のパケットを生成して送信するステップと、
マルチメディア・ストリームを提示するように前記視聴覚装置を構成するための、第２のプロトコル・バージョンに基づいて生成される第２の制御情報を生成するステップと、
前記第２の制御情報に関する情報を含むとともに、前記第２の制御情報が前記第２のプロトコル・バージョンであることを指定する第２のデータ構造を生成するステップと、
前記第１のデータ構造と、前記第１の制御情報と、前記第１の制御情報により指定されるマルチメディア・ストリームと、前記第２のデータ構造と、前記第２の制御情報と、前記第２の制御情報により指定されるマルチメディア・ストリームとを含む第２の複数のパケットを生成して送信するステップと、
を含むことを特徴とする方法。
（アイテム１７）
マルチメディア・ストリームを視聴覚装置へ送信する際に使用するための制御情報を生成する方法であって、
マルチメディア・ストリームを提示するように前記視聴覚装置を構成するための、第１のプロトコル・バージョンに基づいて生成される第１の制御情報を生成するステップと、
前記第１の制御情報に関する情報を含むとともに、前記第１の制御情報が前記第１のプロトコル・バージョンであることを指定する第１のデータ構造を生成するステップと、
前記第１の制御情報により指定されるマルチメディア・ストリームと、前記第１の制御情報と、前記第１のデータ構造とを含む第１の複数のパケットを生成して送信するステップと、
第１のプロトコル・バージョンに基づいて第２の制御情報を生成するステップと、
前記第１のデータ構造を、前記第２の制御情報に関する追加の情報を含むとともに前記第１の制御情報に関する情報を保持するように修正するステップと、
前記修正した第１のデータ構造と、前記第１の制御情報と、前記第２の制御情報と、前記第１の制御情報により指定されるマルチメディア・ストリームとを含む第２の複数のパケットを生成して送信するステップと、
を含むことを特徴とする方法。
（アイテム１８）
マルチメディア・ストリームを視聴覚装置へ送信する際に使用するための制御情報を生成する方法であって、
第１のサービスタイプに基づいてマルチメディア・ストリームを提示するように前記視聴覚装置を構成するための第１の制御情報を生成するステップと、
前記第１の制御情報に関する情報を含むとともに、前記第１の制御情報が前記第１のサービスタイプに関連することを指定する第１のデータ構造を生成するステップと、
前記第１のサービスタイプに基づくマルチメディア・ストリームと、前記第１の制御情報と、前記第１のデータ構造とを含む第１の複数のパケットを生成して送信するステップと、
第２のサービスタイプに基づいてマルチメディア・ストリームを提示するように前記視聴覚装置を構成するための第２の制御情報を生成するステップと、
前記第１のデータ構造を、前記第２の制御情報に関する追加の情報を含むとともに前記第１の制御情報に関する情報を保持するように修正するステップと、
前記修正した第１のデータ構造と、前記第１の制御情報と、前記第１のサービスタイプに基づくマルチメディア・ストリームと、前記第２の制御情報と、前記第２のサービスタイプに基づくマルチメディア・ストリームとを含む第２の複数のパケットを生成して送信するステップと、
を含むことを特徴とする方法。
（アイテム１９）
マルチメディア・ストリームを視聴覚装置へ送信する際に使用するための制御情報を生成する方法であって、
第１のサービスタイプに基づいてマルチメディア・ストリームを提示するように前記視聴覚装置を構成するための第１の制御情報を生成するステップと、
前記第１の制御情報に関する情報を含むとともに、前記第１の制御情報が前記第１のサービスタイプに関連することを指定する第１のデータ構造を生成するステップと、
前記第１のサービスタイプに基づくマルチメディア・ストリームと、前記第１の制御情報と、前記第１のデータ構造とを含む第１の複数のパケットを生成して送信するステップと、
第２のサービスタイプに基づいてマルチメディア・ストリームを提示するように前記視聴覚装置を構成するための第２の制御情報を生成するステップと、
前記第２の制御情報に関する情報を含むとともに、前記第２の制御情報が前記第２のサービスタイプに関連することを指定する第２のデータ構造を生成するステップと、
前記第１のデータ構造と、前記第１の制御情報と、前記第１のサービスタイプに基づくマルチメディア・ストリームと、前記第２のデータ構造と、前記第２の制御情報と、前記第２のサービスタイプに基づくマルチメディア・ストリームとを含む第２の複数のパケットを生成して送信するステップと、
を含むことを特徴とする方法。
（アイテム２０）
装置を構成するための命令ストリームを通信する方法であって、前記命令ストリームが、第１のプロトコル・バージョンに基づいて動作する第１の装置及び第２のプロトコル・バージョンに基づいて動作する第２の装置により使用可能であり、前記第１の装置には前記第２のプロトコル・バージョンとの互換性がなく、
前記命令ストリームを生成するステップと、
前記命令ストリームを１又はそれ以上の装置へ送信するステップと、
を含み、前記命令ストリームが、前記第１のプロトコル・バージョンに基づいて装置を構成するために使用可能な第１の部分と、前記第２のプロトコル・バージョンに基づいて装置を構成するために使用可能な第２の部分と、前記第１の部分が前記第１のプロトコル・バージョンに基づいて装置を構成するためのものであることを示す第１の情報と、前記第２の部分が前記第２のプロトコル・バージョンに基づいて装置を構成するためのものであることを示す第２の情報とを含み、前記第２の情報が、前記第１の装置が前記第２の部分を使用できないことを前記第１の装置に示す、
ことを特徴とする方法。
（アイテム２１）
前記第２の情報が前記第２の部分の位置を示し、前記第２の情報を前記第１の装置が使用して前記第２の部分の位置を判断することにより、前記第１の装置が前記第２の部分を無視できるようになる、
ことを特徴とするアイテム２０に記載の方法。
（アイテム２２）
前記第２の装置には前記第１のプロトコル・バージョンとの互換性がなく、前記第１の情報が、前記第２の装置が前記第１の部分を使用できないことを前記第２の装置に示す、
ことを特徴とするアイテム２０に記載の方法。
（アイテム２３）
前記第２の装置が、前記第２の部分が前記第２の情報を基に前記第２のプロトコル・バージョンに基づいて装置を構成するためのものであると判断するように構成されることにより、前記第２の装置が前記第２の部分を使用して前記第２の装置自体を構成できるようになる、
ことを特徴とするアイテム２０に記載の方法。
（アイテム２４）
前記第１の情報が、前記第１の部分と同じデータ構造内に存在する、
ことを特徴とするアイテム２０に記載の方法。
（アイテム２５）
前記第１の装置が、前記第１の部分が前記第１の情報を基に前記第１のプロトコル・バージョンに基づいて装置を構成するためのものであると判断するように構成されることにより、前記第１の装置が前記第１の部分を使用して前記第１の装置自体を構成できるようになる、
ことを特徴とするアイテム２０に記載の方法。
（アイテム２６）
マルチメディア・ストリームを視聴覚装置へ無線で送信する方法であって、
第１のマルチメディア・ストリームを受信するステップと、
第１のサービスに基づいて前記第１のマルチメディア・ストリームを提示するように前記視聴覚装置を構成するための第１の制御情報を生成するステップと、
前記第１の複数のパケット内の前記第１の制御情報が存在する位置を指定する第１のデータ構造を生成するステップと、
前記第１のマルチメディア・ストリームと、前記第１の制御情報と、前記第１のデータ構造とを含む第１の複数のパケットを生成するステップと、
前記第１の複数のパケットを前記視聴覚装置へ送信するステップと、
第２のマルチメディア・ストリームを受信するステップと、
第２のサービスに基づいて前記第２のマルチメディア・ストリームを提示するように前記視聴覚装置を構成するための、前記視聴覚装置内で前記第１の制御情報に取って代わるように構成された第２の制御情報を生成するステップと、
前記第２の複数のパケット内の前記第２の制御情報が存在する位置を指定する第２のデータ構造を生成するステップと、
前記第２のマルチメディア・ストリームと、前記第２の制御情報と、前記第２のデータ構造とを含む第２の複数のパケットを生成するステップと、
前記第２の複数のパケットを前記視聴覚装置へ送信するステップと、
を含むことを特徴とする方法。
（アイテム２７）
マルチメディア・ストリームを視聴覚装置へ送信する際に使用するための制御情報を生成する方法であって、
マルチメディア・ストリームを提示するように前記視聴覚装置を構成するための、第１のプロトコル・バージョンに基づいて生成される第１の制御情報を生成するステップと、
マルチメディア・ストリームを提示するように前記視聴覚装置を構成するための、第２のプロトコル・バージョンに基づいて生成される第２の制御情報を生成するステップと、
前記第１の制御情報の位置情報を含むとともに前記第１の制御情報が前記第１のプロトコル・バージョンであることを指定し、さらに前記第２の制御情報の位置情報を含むとともに前記第２の制御情報が前記第２のプロトコル・バージョンであることを指定する第１のデータ構造を生成するステップと、
前記第１のデータ構造と、前記第１の制御情報と、前記第２の制御情報と、マルチメディア・ストリームとを含む第１の複数のパケットを生成して送信するステップと、
を含み、前記視聴覚装置が前記第１のプロトコル・バージョンを理解するように構成されていない場合、前記第１の制御情報の位置情報により、視聴覚装置が前記第１の制御情報を無視できるようになる、
ことを特徴とする方法。
（アイテム２８）
マルチメディア・ストリームを視聴覚装置へ送信する際に使用するための制御情報を生成する方法であって、
各々がマルチメディア・ストリームを提示するように前記視聴覚装置を構成するためのものであり、各々が異なるプロトコル・バージョンに基づいて生成される複数の制御情報のグループを生成するステップと、
個々の制御情報のグループの位置情報を含むとともに、個々の制御情報のグループのプロトコル・バージョンを指定する第１のデータ構造を生成するステップと、
前記第１のデータ構造と、前記複数の制御情報のグループと、マルチメディア・ストリームとを含む第１の複数のパケットを生成して送信するステップと、
を含み、前記視聴覚装置が制御情報の１又はそれ以上のそれぞれのグループの（単複の）プロトコル・バージョンを理解するように構成されていない場合、前記第１のデータ構造を前記視聴覚装置が使用して、１又はそれ以上のそれぞれの制御情報のグループを無視することができる、
ことを特徴とする方法。
（アイテム２９）
前記複数の制御情報のグループの各々の位置が、プロトコル・バージョン及びサービスタイプの１又はそれ以上に基づく、
ことを特徴とするアイテム２８に記載の方法。
（アイテム３０）
前記複数の制御情報のグループの各々が、異なるサービスタイプに対応する、
ことを特徴とするアイテム２８に記載の方法。
（アイテム３１）
個々の制御情報のグループが、前記マルチメディア・ストリームを異なる方式で提示するように前記視聴覚装置を構成するためのものである、
ことを特徴とするアイテム２８に記載の方法。
（アイテム３２）
前記第１のデータ構造が、追加の制御情報に関する追加情報を追加するように拡張可能に構成される、
ことを特徴とするアイテム２８に記載の方法。
（アイテム３３）
前記第１のデータ構造が複数のフィールドを含み、前記フィールドの少なくとも１つが拡張可能である、
ことを特徴とするアイテム２８に記載の方法。
（アイテム３４）
マルチメディア・ストリームのための制御情報を視聴覚装置へ送信するためのシステムであって、
送信論理回路を備え、該送信論理回路が、
マルチメディア・ストリームを提示するように前記視聴覚装置を構成するための、第１のプロトコル・バージョンに基づいて生成される第１の制御情報を生成し、
前記第１の制御情報に関する情報を含むとともに、前記第１の制御情報が前記第１のプロトコル・バージョンであることを指定する第１のデータ構造を生成し、
前記第１のプロトコル・バージョンに基づくマルチメディア・ストリームと、前記第１の制御情報と、前記第１のデータ構造とを含む第１の複数のパケットを生成して送信し、
マルチメディア・ストリームを提示するように前記視聴覚装置を構成するための、第２のプロトコル・バージョンに基づいて生成される第２の制御情報を生成し、
前記第１のデータ構造を、前記第２の制御情報に関する追加の情報を含むとともに前記第１の制御情報に関する情報を保持するように修正し、
前記修正した第１のデータ構造と、前記第１の制御情報と、前記第１のプロトコル・バージョンに基づくマルチメディア・ストリームと、前記第２の制御情報と、前記第２のプロトコル・バージョンに基づくマルチメディア・ストリームとを含む第２の複数のパケットを生成して送信する、
ように構成される、
ことを特徴とするシステム。
（アイテム３５）
マルチメディア・ストリームのための制御情報を視聴覚装置へ送信するためのシステムであって、
送信論理回路を備え、該送信論理回路が、
マルチメディア・ストリームを提示するように前記視聴覚装置を構成するための、第１のプロトコル・バージョンに基づいて生成される第１の制御情報を生成し、
マルチメディア・ストリームを提示するように前記視聴覚装置を構成するための、第２のプロトコル・バージョンに基づいて生成される第２の制御情報を生成し、
前記第１の制御情報の位置情報を含むとともに前記第１の制御情報が前記第１のプロトコル・バージョンであることを指定し、さらに前記第２の制御情報の位置情報を含むとともに前記第２の制御情報が前記第２のプロトコル・バージョンであることを指定する第１のデータ構造を生成し、
前記第１のデータ構造と、前記第１の制御情報と、前記第２の制御情報と、マルチメディア・ストリームとを含む第１の複数のパケットを生成して送信する、
ように構成され、前記視聴覚装置が前記第１のプロトコル・バージョンを理解するように構成されていない場合、前記第１の制御情報の位置情報により、視聴覚装置が前記第１の制御情報を無視できるようになる、
ことを特徴とするシステム。
（アイテム３６）
マルチメディア・ストリームのための制御情報を視聴覚装置へ送信するためのシステムであって、
送信論理回路を備え、該送信論理回路が、
各々がマルチメディア・ストリームを提示するように前記視聴覚装置を構成するためのものであり、各々が異なるプロトコル・バージョンに基づいて生成される複数の制御情報のグループを生成し、
個々の制御情報のグループの位置情報を含むとともに、個々の制御情報のグループのプロトコル・バージョンを指定する第１のデータ構造を生成し、
前記第１のデータ構造と、前記複数の制御情報のグループと、マルチメディア・ストリームとを含む第１の複数のパケットを生成して送信する、
ように構成され、前記視聴覚装置が制御情報の１又はそれ以上のそれぞれのグループの（単複の）プロトコル・バージョンを理解するように構成されていない場合、前記第１のデータ構造を前記視聴覚装置が使用して、１又はそれ以上のそれぞれの制御情報のグループを無視することができる、
ことを特徴とするシステム。
（アイテム３７）
視聴覚装置がマルチメディア・ストリームのための制御情報を受信する方法であって、
第１のマルチメディア・ストリームと、第１の制御情報と、第２の制御情報と、前記第１の制御情報及び前記第２の制御情報の位置情報を含むとともに前記第１の制御情報の第１のプロトコル・バージョン及び前記第２の制御情報の第２のプロトコル・バージョンを指定する第１のデータ構造とを含む第１の複数のパケットを受信するステップと、
前記第１のデータ構造を分析して、前記第１の制御情報及び前記第２の制御情報の位置情報と、前記第１の制御情報及び前記第２の制御情報の前記第１及び第２のプロトコル・バージョンとを判断するステップと、
を含み、前記視聴覚装置が、前記第２のプロトコル・バージョンを理解するように構成されずに、前記第２の制御情報の位置情報を使用して前記第２の制御情報を無視し、
前記視聴覚装置を前記第１の制御情報に基づいて構成して、前記視聴覚装置が前記第１のマルチメディア・ストリームを提示できるようにするステップと、
前記構成ステップ後に前記第１のマルチメディア・ストリームを提示するステップと、
をさらに含むことを特徴とする方法。
（アイテム３８）
前記第１の複数のパケットが無線方式で受信される、
ことを特徴とするアイテム３７に記載の方法。
（アイテム３９）
マルチメディア・コンテンツを受信して提示するための、視聴覚装置により実施される方法であって、
第１の制御情報に関する情報を含むとともに前記第１の制御情報が前記第１のプロトコル・バージョンであることを指定する第１のデータ構造と、前記第１の制御情報により指定される少なくとも１つのマルチメディア・ストリームとを含む第１の複数のパケットを受信するステップと、
第１のプロトコル・バージョンに基づいてフォーマットされた前記第１の制御情報を使用して、前記少なくとも１つのマルチメディア・ストリームを提示するように前記視聴覚装置を構成するステップと、
前記第１の制御情報と、前記第１の制御情報により指定されるマルチメディア・ストリームと、第２の制御情報と、前記第２の制御情報により指定されるマルチメディア・ストリームと、前記第２の制御情報に関する追加情報を含むとともに、前記第１の制御情報に関する情報を保持する修正した第１のデータ構造とを含んでいる第２の複数のパケットを受信するステップと、
第２のプロトコル・バージョンに基づいてフォーマットされた前記第２の制御情報を使用して、マルチメディア・ストリームを提示するように前記視聴覚装置を構成するステップと、
を含むことを特徴とする方法。
（アイテム４０）
マルチメディア・コンテンツを受信して提示するための、視聴覚装置により実施される方法であって、
第１の制御情報と、第２の制御情報と、マルチメディア・ストリームと、前記第１の制御情報の位置情報を含むとともに前記第１の制御情報が前記第１のプロトコル・バージョンであることを指定し、さらに前記第２の制御情報の位置情報を含むとともに前記第２の制御情報が前記第２のプロトコル・バージョンであることを指定する第１のデータ構造とを含む第１の複数のパケットを受信するステップを含み、前記視聴覚装置は、前記第１のプロトコル・バージョンを理解するように構成されておらず、
前記第１の制御情報の位置情報を分析して前記視聴覚装置が前記第１の制御情報を無視できるようにするステップと、
前記第２の制御情報を使用して、マルチメディア・ストリームを提示するように前記視聴覚装置を構成するステップと、
をさらに含むことを特徴とする方法。
（アイテム４１）
マルチメディア・ストリームのための制御情報を受信するためのシステムであって、
第１のマルチメディア・ストリームと、第１の制御情報と、第２の制御情報と、前記第１の制御情報及び前記第２の制御情報の位置情報を含むとともに前記第１の制御情報の第１のプロトコル・バージョン及び前記第２の制御情報の第２のプロトコル・バージョンを指定する第１のデータ構造とを含む、無線方式で送信された第１の複数のパケットを受信するための入力部と、
前記入力部に結合された受信機論理回路と、
を備え、前記受信機論理回路が、
前記第１のデータ構造を分析して、前記第１の制御情報及び前記第２の制御情報の位置情報と、前記第１の制御情報及び前記第２の制御情報の前記第１及び第２のプロトコル・バージョンを判断し、
前記視聴覚装置を前記第１の制御情報に基づいて構成して、前記視聴覚装置が前記第１のマルチメディア・ストリームを提示できるようにし、
前記構成ステップ後に前記第１のマルチメディア・ストリームを提示する、
ように構成され、前記視聴覚装置が、前記第２のプロトコル・バージョンを理解するように構成されずに、前記第２の制御情報の位置情報を使用して前記第２の制御情報を無視する、
ことを特徴とするシステム。
（アイテム４２）
マルチメディア・ストリームを視聴覚装置へ送信する際に使用するための制御情報を生成する方法であって、
マルチメディア・ストリームを提示するように前記視聴覚装置を構成するための第１の制御情報を生成するステップを含み、前記制御情報が、複数のノードを有するツリー・データ構造に基づいて体系化され、前記ノードの少なくともいくつかが、前記視聴覚装置を構成するためのデータ値を記憶するリーフ・ノードであり、前記制御情報が複数の命令を含み、前記命令の少なくともサブセットを前記視聴覚装置が実行して、前記リーフ・ノードに記憶された前記データ値を探し出すように前記ツリー構造のノードをナビゲートすることができ、
前記視聴覚装置へ送信するために前記第１の制御情報を記憶するステップをさらに含む、
ことを特徴とする方法。
（アイテム４３）
前記命令の少なくともサブセットが、前記ツリー構造を該ツリー構造内の現在の位置に関してナビゲートするように実行可能である、
ことを特徴とするアイテム４２に記載の方法。
（アイテム４４）
前記命令の少なくともサブセットが、前記ツリー構造を該ツリー構造のルート・ノードに関してナビゲートするように実行可能である、
ことを特徴とするアイテム４２に記載の方法。
（アイテム４５）
前記命令の少なくとも１つが、前記ツリー・データ構造内の現在のノード位置よりも下にある全てのリーフ・ノードのパラメータ値を指定する修飾子命令である、
ことを特徴とするアイテム４２に記載の方法。
（アイテム４６）
前記修飾子命令が、前記ツリー・データ構造内の前記現在のノード位置よりも下にある全てのデータ値が任意のデータ値であることを指定する、
ことを特徴とするアイテム４５に記載の方法。
（アイテム４７）
前記修飾子命令が、前記ツリー・データ構造内の前記現在のノード位置よりも下にある全てのデータ値が必須のデータ値であることを指定する、
ことを特徴とするアイテム４５に記載の方法。
（アイテム４８）
前記リーフ・ノードの少なくともサブセットが、前記視聴覚装置を構成するための複数のデータ値を各々が記憶する、
ことを特徴とするアイテム４２に記載の方法。
（アイテム４９）
前記第１の制御情報及びマルチメディア・ストリームを前記視聴覚装置へ送信するステップをさらに含む、
ことを特徴とするアイテム４２に記載の方法。
（アイテム５０）
マルチメディア・ストリームを視聴覚装置へ送信する際に使用するための制御情報を生成する方法であって、マルチメディア・ストリームを提示するように前記視聴覚装置を構成するための、複数の命令を含む第１の制御情報を生成するステップを含み、前記命令の少なくともサブセットが関連するデータ・フィールドを有し、前記命令の少なくとも１つが長さ値を含む修飾子命令であるとともに、前記長さ値により指定される前記修飾子命令からの或る長さ距離内の全てのデータ値に適用されるパラメータ値を指定する、
ことを特徴とする方法。
（アイテム５１）
前記修飾子命令が、前記長さ値により指定される前記修飾子命令からの前記長さ距離内の全てのデータ値が任意のデータ値であることを指定する、
ことを特徴とするアイテム５０に記載の方法。
（アイテム５２）
前記修飾子命令が、前記長さ値により指定される前記修飾子命令からの前記長さ距離内の全てのデータ値が必須のデータ値であることを指定する、
ことを特徴とするアイテム５０に記載の方法。
（アイテム５３）
マルチメディア・ストリームを視聴覚装置へ送信する際に使用するための制御情報を生成する方法であって、マルチメディア・ストリームを提示するように前記視聴覚装置を構成するための、複数の命令を含む第１の制御情報を生成するステップを含み、前記命令の少なくともサブセットが関連するデータ・フィールドを有し、前記複数の命令の各々が均一長の複数のビット部分を含み、前記データ・フィールドの各々が均一長の複数のビット部分を含み、前記命令の前記ビット部分の第１のビットが、前記ビット部分が命令であることを示す第１の値を有し、前記データ・フィールドの前記ビット部分の第１のビットが、前記ビット部分がデータ・フィールドであることを示す第２の値を有し、前記第２の値が前記第１の値とは異なる、
ことを特徴とする方法。

１００ 放送システム； １０２ 送信システム； １０４送信論理回路；
１０６ 送信機； １１２ 移動体装置。

Claims (22)

1. マルチメディア・ストリームを視聴覚装置へ送信する際に使用するための制御情報を生成する方法であって、
   マルチメディア・ストリームを提示できるよう前記視聴覚装置を構成する第１の制御情報を、第１のプロトコル・バージョンに従って生成するステップと、
   前記第１の制御情報に関する情報を含むとともに、前記第１の制御情報が前記第１のプロトコル・バージョンであることを指定する第１のデータ構造を生成するステップと、
   前記第１の制御情報により指定される少なくとも１つのマルチメディア・ストリームと、前記第１の制御情報と、前記第１のデータ構造とを含んでいる第１の複数のパケットを生成して送信するステップと、
   マルチメディア・ストリームを提示できるよう前記視聴覚装置を構成する第２の制御情報を、第２のプロトコル・バージョンに従って生成するステップと、
   前記第１のデータ構造を、前記第２の制御情報に関する追加の情報を含むとともに、前記第２の制御情報が前記第２のプロトコル・バージョンであることを指定し、前記第１の制御情報に関する情報を保持するように修正するステップと、
   前記修正した第１のデータ構造と、前記第１の制御情報と、前記第１の制御情報により指定されるマルチメディア・ストリームと、前記第２の制御情報と、前記第２の制御情報により指定されるマルチメディア・ストリームとを含んでいる第２の複数のパケットを生成して送信するステップと、
   を含むことを特徴とする方法。
2. 前記第１の制御情報は、前記マルチメディア・ストリームを第１の手法で提示するように前記視聴覚装置を構成するためのものであり、前記第２の制御情報は、前記マルチメディア・ストリームを第２の手法で提示するように前記視聴覚装置を構成するためのものである、
   ことを特徴とする請求項１に記載の方法。
3. 前記第１のデータ構造が、前記第１の制御情報が存在する前記第１の複数のパケット内の１又はそれ以上の位置を指定し、前記修正した第１のデータ構造が、前記第２の制御情報が存在する前記第２の複数のパケット内の１又はそれ以上の位置を指定する、
   ことを特徴とする請求項１に記載の方法。
4. 前記第１の制御情報に関する情報が、前記第１の制御情報内の第１の命令の１又はそれ以上のタイプ及び１又はそれ以上の位置を指定し、前記第２の制御情報に関する追加情報が、前記第２の制御情報内の命令の１又はそれ以上のタイプ及び１又はそれ以上の位置を指定する、
   ことを特徴とする請求項１に記載の方法。
5. 前記第１のデータ構造を修正するステップが、前記第１のデータ構造のフォーマットを修正するステップを含み、
   前記第１のデータ構造のフォーマットを指定する情報を、前記第１のデータ構造を修正するステップを反映するように修正するステップをさらに含む、
   ことを特徴とする請求項１に記載の方法。
6. 前記第１のデータ構造のフォーマットを指定する情報を修正するステップが、前記修正した第１のデータ構造のバージョン情報を修正するステップを含む、
   ことを特徴とする請求項５に記載の方法。
7. 前記第１のデータ構造のフォーマットを指定する情報を変更するステップが、前記修正した第１のデータ構造のサイズ情報を修正するステップを含む、
   ことを特徴とする請求項５に記載の方法。
8. 前記第１のデータ構造を修正するステップが、前記第１のデータ構造のフォーマットを修正するステップを含み、前記第１のデータ構造が、前記第１のデータ構造のフォーマットを指定する情報を含み、
   前記修正した第１のデータ構造内の前記第１のデータ構造のフォーマットを指定する情報を、前記第１のデータ構造を修正するステップを反映するように修正するステップをさらに含む、
   ことを特徴とする請求項１に記載の方法。
9. マルチメディア・ストリームを提示するように前記視聴覚装置を構成するための、第３のプロトコル・バージョンに基づいて生成される第３の制御情報を生成するステップと、
   前記第３の制御情報に関する情報を含むように第２のデータ構造を生成するステップと、
   前記修正した第１のデータ構造と、前記第１の制御情報と、前記第１の制御情報により指定されるマルチメディア・ストリームと、前記第２の制御情報と、前記第２の制御情報により指定されるマルチメディア・ストリームと、前記第３のデータ構造と、前記第３の制御情報と、前記第３の制御情報により指定されるマルチメディア・ストリームとを含む第３の複数のパケットを生成して送信するステップと、
   をさらに含むことを特徴とする請求項１に記載の方法。
10. 前記第１のデータ構造が、前記第１の制御情報の第１のプロトコル・バージョンと前記第１の制御情報の位置とを識別する情報を含み、前記視聴覚装置が前記第１の制御情報の第１のプロトコル・バージョンを解析するように構成されていない場合、前記第１の制御情報の第１のプロトコル・バージョンと前記第１の制御情報の位置とを識別する前記情報を視聴覚装置が使用して、前記第１の制御情報を無視することができる、
    ことを特徴とする請求項１に記載の方法。
11. 前記第１のデータ構造が、追加の制御情報に関する追加情報を追加するように拡張可能に構成される、
    ことを特徴とする請求項１に記載の方法。
12. 前記第１のデータ構造が複数のフィールドを含み、該フィールドの少なくとも１つが拡張可能である、
    ことを特徴とする請求項１に記載の方法。
13. 前記少なくとも１つの拡張可能なフィールドが、該フィールドの値を特定の値に設定することにより拡張され、前記特定の値が、前記拡張可能なフィールドが拡張されたことを視聴覚装置に示す、
    ことを特徴とする請求項１２に記載の方法。
14. 前記第１のデータ構造を、後から生成されたパケット内の追加の制御情報に関する追加情報を含むように構成することができる、
    ことを特徴とする請求項１に記載の方法。
15. 前記第２の複数のパケットが、該第２の複数のパケットに含まれる複数のデータ構造を指定する情報を含む、
    ことを特徴とする請求項１に記載の方法。
16. 前記第１のデータ構造が前記第１の制御情報から分離している、ことを特徴とする請求項１に記載の方法。
17. マルチメディア・ストリームのための制御情報を視聴覚装置へ送信するためのシステムであって、
    送信論理回路を備え、該送信論理回路が、
    マルチメディア・ストリームを提示するように前記視聴覚装置を構成するための、第１のプロトコル・バージョンに基づいて生成される第１の制御情報を生成し、
    前記第１の制御情報に関する情報を含むとともに、前記第１の制御情報が前記第１のプロトコル・バージョンであることを指定する第１のデータ構造を生成し、
    前記第１のプロトコル・バージョンに基づくマルチメディア・ストリームと、前記第１の制御情報と、前記第１のデータ構造とを含む第１の複数のパケットを生成して送信し、
    マルチメディア・ストリームを提示するように前記視聴覚装置を構成するための、第２のプロトコル・バージョンに基づいて生成される第２の制御情報を生成し、
    前記第１のデータ構造を、前記第２の制御情報に関する追加の情報を含むとともに、前記第２の制御情報が前記第２のプロトコル・バージョンであることを指定し、前記第１の制御情報に関する情報を保持するように修正し、
    前記修正した第１のデータ構造と、前記第１の制御情報と、前記第１のプロトコル・バージョンに基づくマルチメディア・ストリームと、前記第２の制御情報と、前記第２のプロトコル・バージョンに基づくマルチメディア・ストリームとを含む第２の複数のパケットを生成して送信する、
    ように構成される、
    ことを特徴とするシステム。
18. 前記第１のデータ構造が前記第１の制御情報から分離している、ことを特徴とする請求項１７に記載の方法。
19. マルチメディア・コンテンツを受信して提示するための、視聴覚装置により実施される方法であって、
    第１の制御情報に関する情報を含むとともに前記第１の制御情報が前記第１のプロトコル・バージョンであることを指定する第１のデータ構造と、前記第１の制御情報により指定される少なくとも１つのマルチメディア・ストリームとを含む第１の複数のパケットを受信するステップと、
    第１のプロトコル・バージョンに基づいてフォーマットされた前記第１の制御情報を使用して、前記少なくとも１つのマルチメディア・ストリームを提示するように前記視聴覚装置を構成するステップと、
    前記第１の制御情報と、前記第１の制御情報により指定されるマルチメディア・ストリームと、第２の制御情報と、前記第２の制御情報により指定されるマルチメディア・ストリームと、前記第２の制御情報に関する追加情報を含み且つ前記第２の制御情報が前記第２のプロトコル・バージョンであることを含むとともに、前記第１の制御情報に関する情報を保持する修正した第１のデータ構造とを含んでいる第２の複数のパケットを受信するステップと、
    第２のプロトコル・バージョンに基づいてフォーマットされた前記第２の制御情報を使用して、マルチメディア・ストリームを提示するように前記視聴覚装置を構成するステップと、
    を含むことを特徴とする方法。
20. 前記第１のデータ構造が前記第１の制御情報から分離している、ことを特徴とする請求項１９に記載の方法。
21. マルチメディア・ストリームのための制御情報を受信するためのシステムであって、
    第１のマルチメディア・ストリームと、第１の制御情報と、第２の制御情報と、前記第１の制御情報及び前記第２の制御情報の位置情報を含むとともに前記第１の制御情報の第１のプロトコル・バージョン及び前記第２の制御情報の第２のプロトコル・バージョンを指定する第１のデータ構造とを含む、無線方式で送信された第１の複数のパケットを受信するための入力部と、
    前記入力部に結合された受信機論理回路と、
    を備え、前記受信機論理回路が、
    前記第１のデータ構造を分析して、前記第１の制御情報及び前記第２の制御情報の位置情報と、前記第１の制御情報及び前記第２の制御情報の前記第１及び第２のプロトコル・バージョンを判断し、
    前記視聴覚装置を前記第１の制御情報に基づいて構成して、前記視聴覚装置が前記第１のマルチメディア・ストリームを提示できるようにし、
    前記構成ステップ後に前記第１のマルチメディア・ストリームを提示する、
    ように構成され、前記視聴覚装置が、前記第２のプロトコル・バージョンを理解するように構成されずに、前記第２の制御情報の位置情報を使用して前記第２の制御情報を無視する、
    ことを特徴とするシステム。
22. 前記第１のデータ構造が前記第１の制御情報から分離している、ことを特徴とする請求項２１に記載の方法。

Images