WO2016194471A1

WO2016194471A1 - 送信装置及び送信方法、並びに受信装置及び受信方法

Info

Publication number: WO2016194471A1
Application number: PCT/JP2016/061392
Authority: WO
Inventors: 北里　直久
Original assignee: ソニー株式会社
Priority date: 2015-05-29
Filing date: 2016-04-07
Publication date: 2016-12-08

Abstract

所定のトランスポート方式によりデータ放送アプリケーション及びその制御情報を好適に送受信する。　送信側は、アプリケーション制御情報にアプリケーションを伝送するアセット及びデータ・イベントの各指定情報を付加して伝送する。受信機側では、放送で伝送されるアプリケーションなどのデータを取得する際、データ伝送制御情報において指定されるコンポーネント・タグとデータ・イベント・タグを、対象とするアプリケーションに対してアプリケーション制御情報で指定されている値とマッチングがとれた場合のみ、ファイルを取得する。

Description

送信装置及び送信方法、並びに受信装置及び受信方法

　本明細書で開示する技術は、所定のトランスポート方式によりデータ放送アプリケーションを送信する送信装置及び送信方法、並びに、所定のトランスポート方式により伝送されるデータ放送アプリケーションを受信し、その制御情報に基づいてデータ放送アプリケーションを実行する受信装置及び受信方法に関する。

　次世代のディジタル放送規格では、メディア・トランスポート方式として、従来のＭＰＥＧ２－ＴＳから、ＭＭＴ（ＭＰＥＧ　Ｍｅｄｉａ　Ｔｒａｎｓｐｏｒｔ）方式への変更が検討されている（例えば、特許文献１を参照のこと）。ＭＭＴ方式では、異なる伝送路の組み合わせで利用することが容易であり、放送や通信の複数の伝送路に共通に用いることができる。

　ＭＭＴ方式のＴＶ放送規格では、映像や音声、字幕などの放送番組本体のストリーム・メディアを同期型（Ｔｉｍｅｄ）ＭＰＵ（Ｍｅｄｉａ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）フォーマットで伝送する一方、データ放送アプリケーションを非同期型（Ｎｏｎ　ｔｉｍｅｄ）ＭＰＵフォーマットで伝送する方式も規定されている。

　従来のディジタル放送規格では、データ放送アプリケーションを構成する複数のリソース・ファイルをまとめたモジュールはＤＤＢ（Ｄｏｗｎｌｏａｄ　Ｄａｔａ　Ｂｌｏｃｋ）メッセージに分割される。そして、ＤＤＢメッセージを分割したＴＳパケットがデータ・イベントと呼ばれる期間にデータ・カルーセル方式により繰り返し伝送される。また、モジュールのＤＤＢメッセージへの分割に同期して、各モジュールの情報を指定するＤＩＩ（ＤｏｗｎｌｏａｄＩｎｆｏＩｎｄｉｃａｔｉｏｎ）メッセージが、ＤＳＭ－ＣＣセクションとされＴＳパケットに分割されて、同様にデータ・イベントの期間に送出される。データ・イベントは、ＤＩＩメッセージのデータ・イベント識別子（ｄａｔａ＿ｅｖｅｎｔ＿ｉｄ）の更新に従って切り替わる。すなわち、データ・イベント識別子の更新に同期して、データ・イベント内で伝送されるコンテンツであるローカル・コンテンツが切り替わる（例えば、特許文献２を参照のこと）。

　次世代のディジタル放送規格で採用されるＭＭＴ方式においても、データ放送アプリケーションの伝送方式には、データ・イベントという概念が、従来のＭＰＥＧ２－ＴＳ方式を継承する形で導入されている。

特開２０１４－２０００５４号公報特開２０１５－８０２２９号公報

　本明細書で開示する技術の目的は、所定のトランスポート方式によりデータ放送アプリケーションを好適に送信することができる、優れた送信装置及び送信方法を提供することにある。

　また、本明細書で開示する技術の目的は、所定のトランスポート方式により伝送されるデータ放送アプリケーションを受信し、その制御情報に基づいてデータ放送アプリケーションを好適に実行することができる、優れた受信装置及び受信方法を提供することにある。

　本明細書で開示する技術は、上記課題を参酌してなされたものであり、その第１の側面は、
　アプリケーション制御情報に、アプリケーションを伝送するデータ・イベントを指定するデータ・イベント指定情報を付与する処理部と、
　前記データ・イベント指定情報を付与した前記アプリケーション制御情報を送信する送信部と、
を具備する送信装置である。

　本明細書で開示する技術の第２の側面によれば、第１の側面に係る送信装置は、所定のトランスポート方式によりデータ・イベント毎に伝送されるアプリケーションの伝送制御情報を送信する第２の送信部をさらに備えている。

　本明細書で開示する技術の第３の側面によれば、第２の側面に係る送信装置は、アプリケーションのデータからなるアセットを前記所定のトランスポート方式を用いて伝送する第３の送信部をさらに備えている。そして、前記第２の送信部は、各アセットで伝送されるデータの伝送制御情報を送信するように構成されている。

　本明細書で開示する技術の第４の側面によれば、第１の側面に係る送信装置の前記処理部は、アプリケーションを伝送するアセット及びデータ・イベントの組み合わせを一意に指定する前記データ・イベント指定情報を前記アプリケーション制御情報に付与するように構成されている。

　本明細書で開示する技術の第５の側面によれば、第１の側面に係る送信装置の前記処理部は、前記アプリケーション制御情報に配置される、アプリケーションのロケーション情報を指定する第１の記述子に、前記データ・イベント指定情報を付与するように構成されている。

　本明細書で開示する技術の第６の側面によれば、第５の側面に係る送信装置の前記処理部は、前記第１の記述子がアプリケーションのロケーション情報を指定するＵＲＬに前記データ・イベント指定情報をクエリーとして付与するように構成されている。

　本明細書で開示する技術の第７の側面によれば、第１の側面に係る送信装置の前記処理部は、アプリケーションを伝送するアセットと一意に対応するコンポーネント識別情報と、アプリケーションのデータと一意に対応するダウンロード識別情報からなる前記データ・イベント指定情報とを記載する第２の記述子を前記アプリケーション制御情報に配置するように構成されている。

　本明細書で開示する技術の第８の側面によれば、第７の側面に係る送信装置の前記処理部は、アプリケーションを伝送するデータ・イベントのデータ・イベント識別情報を前記ダウンロード識別情報の所定領域に符号化するように構成されている。

　また、本明細書で開示する技術の第９の側面は、
　アプリケーション制御情報に、アプリケーションを伝送するデータ・イベントを指定するデータ・イベント指定情報を付与する付与ステップと、
　前記データ・イベント指定情報を付与した前記アプリケーション制御情報を送信する送信ステップと、
を有する送信方法である。

　また、本明細書で開示する技術の第１０の側面は、
　所定のトランスポート方式によりデータ・イベント毎に伝送されるアプリケーションのアセットを受信する第１の受信部と、
　アプリケーションの伝送制御情報を受信する第２の受信部と、
　アプリケーションが伝送されるデータ・イベントを指定するデータ・イベント指定情報報が付与されたアプリケーション制御情報を受信する第３の受信部と、
　前記アプリケーション制御情報に基づいてアプリケーションの処理を制御する制御部と、
を具備する受信装置である。

　本明細書で開示する技術の第１１の側面によれば、第１０の側面に係る受信装置の前記第３の受信部は、アプリケーションを伝送するアセット及びデータ・イベントの組み合わせを一意に指定する前記データ・イベント指定情報が付与された前記アプリケーション制御情報を受信するように構成されている。

　本明細書で開示する技術の第１２の側面によれば、第１０の側面に係る受信装置の前記第３の受信部は、アプリケーションのロケーション情報を指定するとともに前記データ・イベント指定情報が付与された第１の記述子が配置された前記アプリケーション制御情報を受信するように構成されている。

　本明細書で開示する技術の第１３の側面によれば、第１２の側面に係る受信装置の前記第３の受信部は、アプリケーションのロケーション情報を指定するＵＲＬに前記データ・イベント指定情報がクエリーとして付与された前記第１の記述子が配置された前記アプリケーション制御情報を受信するように構成されている。

　本明細書で開示する技術の第１４の側面によれば、第１０の側面に係る受信装置の前記第３の受信部は、アプリケーションが伝送されるアセットと一意に対応するコンポーネント識別情報と、アプリケーションのデータと一意に対応するダウンロード識別情報からなる前記データ・イベント指定情報とを記載する第２の記述子が配置された前記アプリケーション制御情報を受信するように構成されている。

　本明細書で開示する技術の第１５の側面によれば、第１４の側面に係る受信装置の前記第３の受信部は、アプリケーションを伝送するデータ・イベントのデータ・イベント識別情報が所定領域に符号化された前記ダウンロード識別情報を記載する前記第２の記述子を受信するように構成されている。

　本明細書で開示する技術の第１６の側面によれば、第１０の側面に係る受信装置の前記制御部は、前記アプリケーション制御情報に付与されるデータ・イベント指定情報に基づいて、前記所定のトランスポート方式で伝送されるアプリケーションへのアクセスを制御するように構成されている。

　本明細書で開示する技術の第１７の側面によれば、第１０の側面に係る受信装置の前記制御部は、前記所定のトランスポート方式で伝送されるアプリケーションにアクセスする際に、前記伝送制御情報によりアプリケーションに指定されるアセット及びデータ・イベント識別情報と前記アプリケーション制御情報でアプリケーションに付与された前記データ・イベント指定情報を比較した結果に基づいて、アプリケーションへのアクセスを制御するように構成されている。

　また、本明細書で開示する技術の第１８の側面は、
　所定のトランスポート方式によりデータ・イベント毎に伝送されるアプリケーションのアセットを受信する第１の受信ステップと、
　アプリケーションの伝送制御情報を受信する第２の受信ステップと、
　アプリケーションが伝送されるデータ・イベントを指定するデータ・イベント指定情報報が付与されたアプリケーション制御情報を受信する第３の受信ステップと、
　前記アプリケーション制御情報に基づいてアプリケーションの処理を制御する制御ステップと、
を有する受信方法である。

　本明細書で開示する技術によれば、所定のトランスポート方式によりデータ放送アプリケーション及びその制御情報を好適に送信することができる、優れた送信装置及び送信方法を提供することができる。

　また、本明細書で開示する技術によれば、所定のトランスポート方式により伝送されるデータ放送アプリケーション及びその制御情報を好適に受信し、制御情報に基づいてデータ放送アプリケーションを実行することができる、優れた受信装置及び受信方法を提供することができる。

　なお、本明細書に記載された効果は、あくまでも例示であり、本発明の効果はこれに限定されるものではない。また、本発明が、上記の効果以外に、さらに付加的な効果を奏する場合もある。

　本明細書で開示する技術のさらに他の目的、特徴や利点は、後述する実施形態や添付する図面に基づくより詳細な説明によって明らかになるであろう。

図１は、ディジタル放送システム１０の構成例を模式的に示した図である。図２は、ＭＭＴ方式を用いるディジタル放送システム１０におけるプロトコル・スタック２００を示した図である。図３は、放送送出システム１１の構成例を示した図である。図４は、放送送出システム１１からの放送信号を受信する受信機１２の構成例を示した図である。図５は、ＭＭＴ方式に従った放送信号５００のイメージを示した図である。図６は、ＰＡメッセージ内のＭＰテーブルから放送サービスに関連する各アセットを指定する仕組みを示した図である。図７は、ＭＨ－ＡＩＴのシンタックス例７００を示した図である。図８は、伝送プロトコル記述子のシンタックス例８００を示した図である。図９は、ＨＴＴＰ／ＨＴＴＰＳ、ＭＭＴ非同期型伝送に共通のセレクター・バイトのシンタックス例９００を示した図である。図１０は、データ・ディレクトリー管理テーブルのシンタックス例１０００を示した図である。図１１は、データ・アセット管理テーブルのシンタックス例１１００を示した図である。図１２は、ＭＭＴ伝送されるデータ放送に関連するファイルを取得する仕組みを説明するための図である。図１３は、ＭＭＴ方式におけるアプリケーションの伝送並びにアプリケーション実行のシナリオを例示した図である。図１４は、放送で伝送されるアプリケーションのロケーション情報を指定するＵＲＬにコンポーネント・タグ及びデータ・イベント識別情報を付与する例を示した図である。図１５は、ＭＨ－ＡＩＴのアプリケーション情報ループに配置される伝送参照記述子のシンタックス例１５００を示した図である。図１６は、データ・イベントをチェックしながらＭＭＴ伝送されるアプリケーション・データを取得する仕組みを説明するための図である。図１７は、アプリケーションを伝送するアセット及びデータ・イベントをＭＨ－ＡＩＴで指定する方法を適用した場合における、アプリケーション実行のシナリオを例示した図である。図１８は、データ・イベントのチェックを伴うアプリケーションの実行制御を行なうための処理手順を示したフローチャートである。図１９は、データ・イベントのチェックを伴うアプリケーションの実行制御を行なうための処理手順を示したフローチャートである。図２０は、データ・イベントのチェックを伴うアプリケーションの実行制御を行なうための処理手順を示したフローチャートである。図２１は、ＰＡメッセージに格納されるＭＰテーブルのシンタックス例２１００を示した図である。図２２は、ＭＰテーブル内に配置されるアプリケーション・サービス記述子のシンタックス例２２００を示した図である。

　以下、図面を参照しながら本明細書で開示する技術の実施形態について詳細に説明する。

Ａ．システム構成
　図１には、ディジタル放送システム１０の構成例を模式的に示している。図示のディジタル放送システム１０は、放送送出システム１１と、受信機１２で構成される。

　放送送出システム１１は、放送信号の伝送にＭＭＴ方式を適用しており、放送サービスを構成する各コンポーネントをＩＰ（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ）パケットにして伝送する。具体的には、放送送出システム１１は、放送番組の映像信号や音声信号の符号、並びに、放送番組に関連するコンテンツ（データ放送アプリケーションなど）や字幕の信号を、ＭＭＴＰ（ＭＭＴ　Ｐｒｏｔｏｃｏｌ）ペイロードに乗せてＭＭＴＰパケット化し、さらにＩＰパケット化し、放送伝送路ではＴＬＶ（Ｔｙｐｅ　Ｌｅｎｇｔｈ　Ｖａｌｕｅ）パケットの形式で伝送する。ここで、映像や音声、字幕などの放送番組本体に関わるコンポーネントは、同期型メディアである。また、コンテンツ、すなわちＨＴＭＬ（Ｈｙｐｅｒ　Ｔｅｘｔ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ）５形式などで符号化されるデータ放送アプリケーションは、非同期型メディアである。

　また、放送送出システム１１は、同期型及び非同期型のメディアを伝送する放送サービスに関する制御情報であるＭＭＴ－ＳＩのシグナリングも行なう。ＭＭＴ－ＳＩには、メッセージ、テーブル、記述子（ｄｅｓｃｒｉｐｔｏｒ）がある。テーブルは、メッセージをコンテナーとして伝送される。メッセージやテーブルで示すパラメーターの一部は記述子の形式で記述される。

　一方、受信機１２は、放送送出システム１１から放送伝送路で送られてくるＴＬＶパケットを受信する。受信機１２は、そして、受信機１２は、受信パケットから映像や音声、字幕などの伝送メディアを復号して、画像や音声を提示する。また、受信機１２は、受信パケットからデータ放送用の各データ・ファイルを取得すると、ＨＴＭＬブラウザーなどのアプリケーション・エンジンを起動して、放送番組に連動したデータ放送を、ＴＶ番組の映像を表示するスクリーンの一部又は全部の領域に表示する。

　また、受信機１２は、放送サービスに関する制御情報であるＭＭＴ－ＳＩも受信する。受信機１２は、ＭＭＴ－ＳＩに基づいて、映像や音声、字幕、データ放送などの伝送メディアの受信制御や受信機１２上での出力（表示、音声出力）制御を行なう。

　図２には、ＭＭＴ方式を用いるディジタル放送システム１０におけるプロトコル・スタック２００を示している。

　１つの放送サービスは、映像２０１、音声２０２、字幕２０３、アプリケーション２０４、コンテンツ・ダウンロード２０５の各コンポーネントで構成される。映像２０１はＨＥＶＣ（Ｈｉｇｈ　Ｅｆｆｉｃｉｅｎｃｙ　Ｖｉｄｅｏ　Ｃｏｄｉｎｇ）形式で符号化２１１され、音声２０２はＡＡＣ（Ａｄｖａｎｃｅｄ　Ａｕｄｉｏ　Ｃｏｄｉｎｇ）形式で符号化２１２され、字幕２０３は字幕符号化２１３される。また、アプリケーション２０４は、ＥＰＧ（Ｅｌｅｃｔｒｉｃ　Ｐｒｏｇｒａｍ　Ｇｕｉｄｅ）を含むが、例えばＨＴＭＬ５形式で符号化２１４される。

　ＭＭＴレイヤー２２０上では、これら同期型メディア及び非同期型メディアの符号化コンポーネント２１１～２１４は、ＭＰＵフォーマットにして、ＭＭＴＰペイロードに乗せてＭＭＴＰパケット化される。また、メディア・トランスポート方式であるＭＭＴに関わる（放送番組の構成などを示す）制御情報であるＭＭＴ－ＳＩ２２１も、ＭＭＴＰペイロードに乗せてＭＭＴＰパケット化される。ＭＭＴに関わる制御情報ＭＭＴ－ＳＩの詳細については、後述に譲る。なお、コンテンツ・ダウンロード２０５のデータ伝送方式２１５として、字幕・文字スーパー伝送方式、アプリケーション伝送方式、イベント・メッセージ伝送方式、汎用データ伝送方式の４種類が挙げられるが、詳細な説明は省略する。

　ＵＤＰ（Ｕｓｅｒ　Ｄａｔａｇｒａｍ　Ｐｒｏｔｏｃｏｌ）／ＩＰレイヤー５３０では、ＭＭＴＰパケットはＩＰパケット化される。また、同期型メディアのための現在時刻の情報を含むＮＴＰ（Ｎｅｔｗｏｒｋ　Ｔｉｍｅ　Ｐｒｏｔｏｃｏｌ）パケット２０６も、ＩＰパケット化される。さらに、これらのＩＰパケットは、ＴＬＶレイヤー２４０でＴＬＶパケット化され、最下層の物理レイヤーである放送伝送路２５０で伝送される。また、ＩＰパケットの多重のためのＴＬＶ多重化形式に関わるＴＬＶ－ＳＩ２４１も、ＴＬＶパケット化され、放送伝送路２５０で伝送される。ＴＬＶパケットを多重した伝送スロットは、伝送路のＴＭＣＣ（Ｔｒａｎｓｍｉｓｓｉｏｎ　ａｎｄ　Ｍｕｌｔｉｐｌｅｘｉｎｇ　Ｃｏｎｆｉｇｕｒａｔｉｏｎ　Ｃｏｎｔｒｏｌ）信号２５１から、ＴＬＶストリーム識別情報（ＴＬＶ＿ｓｔｒｅａｍ＿ｉｄ）を用いて特定される。

　図３には、図２に示すようなプロトコル・スタック構造の放送信号を送信する放送送出システム１１の構成例を示している。図示の放送送出システム１１は、時計部３０１と、信号送出部３０２と、ビデオ・エンコーダー３０３と、オーディオ・エンコーダー３０４と、字幕／文字スーパー・エンコーダー３０５と、シグナリング・エンコーダー３０６と、ファイル・エンコーダー３０７と、電子データ処理システム（Ｅｌｅｃｔｒｏｎｉｃ　Ｄａｔａ　Ｐｒｏｃｅｓｓｉｎｇ　Ｓｙｓｔｅｍ：ＥＤＰＳ）３０８と、ＴＬＶシグナリング・エンコーダー３０９と、ＩＰサービス・マルチプレクサー（ＭＵＸ）３１０と、ＴＬＶマルチプレクサー（ＭＵＸ）３１１と、変調・送信部３１２を備えている。

　時計部３０１は、ＮＴＰサーバー（図示しない）から取得した時刻情報に同期した時刻情報を生成し、この時刻情報を含むＩＰパケットをＩＰサービス・マルチプレクサー３１０に送る。

　信号送出部３０２は、例えばＴＶ放送局のスタジオやＶＴＲなどの記録再生機であり、同期型メディアである映像、音声、字幕及び文字スーパーなどのストリーム・データや、非同期型メディアであるデータ放送アプリケーションをそれぞれ、ビデオ・エンコーダー３０３、オーディオ・エンコーダー３０４、字幕／文字スーパー・エンコーダー３０５、ファイル・エンコーダー３０７に送る。

　電子データ処理システム３０８は、ＴＶ放送局のスケジューラー並びにファイルの供給源である。電子データ処理システム３０８は、非同期型メディアであるデータ放送アプリケーションをファイル・エンコーダー３０７に送る。また、電子データ処理システム３０８は、放送サービスの構成などを示す制御情報をシグナリング・エンコーダー３０６に送る。また、電子データ処理システム３０８は、ＩＰパケットの多重に関する制御情報をＴＬＶシグナリング・エンコーダー３０９に送る。

　ビデオ・エンコーダー３０３は、信号送出部３０２から送出される映像信号をＨＥＶＣ符号化し、さらにパケット化して、映像信号のＭＭＴパケットを含むＩＰパケットをＩＰサービス・マルチプレクサー３１０に送る。また、オーディオ・エンコーダー３０４は、信号送出部３０２から送出される音声信号をＡＡＣ符号化し、さらにパケット化して、音声信号のＭＭＴパケットを含むＩＰパケットをＩＰサービス・マルチプレクサー３１０に送る。また、字幕／文字スーパー・エンコーダー３０５は、信号送出部３０２から送出される字幕信号及び文字スーパー信号を符号化し、さらに提示処理の単位でＭＰＵを生成して、字幕のＭＭＴパケットを含むＩＰパケットをＩＰサービス・マルチプレクサー３１０に送る。

　放送送出システム１１が複数の放送サービスを送信する場合、放送サービス毎に映像信号のＨＥＶＣ符号化、音声信号のＡＡＣ符号化、及び字幕／文字スーパーの符号化処理が行なわれ、それぞれの放送サービス＃１～＃Ｎに対応するＩＰサービス・マルチプレクサー３１０－１、…、３１０－Ｎに送られる。

　シグナリング・エンコーダー３０６は、電子データ処理システム３０８から送出される情報に基づいて、放送番組の構成などを示す制御情報（ＭＭＴ－ＳＩ）を生成し、ペイロード部にＭＭＴ－ＳＩが配置されたＭＭＴパケットを含むＩＰパケットをＩＰサービス・マルチプレクサー３１０に送る。ＭＭＴ－ＳＩには、メッセージ、テーブル、記述子がある（前述）。シグナリング・エンコーダー３０６は、放送サービス単位のＭＭＴ－ＳＩを生成する他、放送サービス横断のＭＭＴ－ＳＩを生成する。

　ファイル・エンコーダー３０７は、信号送出部３０２又は電子データ処理システム３０８から送出されるデータ放送アプリケーションをＨＴＭＬ５形式のデータ・ファイルに符号化し、さらにパケット化して、このＭＭＴパケットを含むＩＰパケットをＩＰサービス・マルチプレクサー３１０に送る。

　放送送出システム１１は、送出する放送サービス（放送チャンネル）＃１～＃Ｎ毎に、複数のＩＰサービス・マルチプレクサー３１０―１、…、３１０－Ｎを装備する。放送サービス毎のチャンネルのＩＰサービス・マルチプレクサー３１０は、各エンコーダー３０３～３０７から送られてくる映像、音声、字幕、（放送サービス単位）ＭＭＴ－ＳＩ、及びデータ放送アプリケーションの各々を含むＩＰパケットをマルチプレクスして、放送サービス単位の放送信号、並びに、放送サービス横断のＭＭＴ－ＳＩを含んだＴＬＶパケットを生成する。

　ＴＬＶシグナリング・エンコーダー３０９は、電子データ処理システム３０８から送出される情報に基づいて、上記のＩＰパケットの多重に関する制御情報（ＴＬＶ－ＳＩ）をペイロード部に配置するＴＬＶパケットを生成する。

　ＴＬＶマルチプレクサー３１１は、各ＩＰサービス・マルチプレクサー３１０－１～３１０－Ｎ及びＴＬＶシグナリング・エンコーダー３０９で生成されるＴＬＶパケットをマルチプレクスして、ＴＬＶストリーム識別情報で識別されるＴＬＶストリームを生成する。

　変調・送信部３１２は、ＴＬＶマルチプレクサー３１１で生成されたＴＬＶストリームに対してＲＦ変調処理を行なって、放送伝送路に送出する。

　図３に示した放送送出システム１１の動作について説明しておく。

　時計部３０１では、ＮＴＰサーバー（図示しない）から取得した時刻情報に同期した時刻情報が生成され、この時刻情報を含むＩＰパケットが生成される。

　信号送出部３０２から送出される映像信号は、ビデオ・エンコーダー３０３に供給される。ビデオ・エンコーダー３０３では、映像信号がＨＥＶＣ符号化され、さらにパケット化されて、ＨＥＶＣ符号化映像信号のＭＭＴパケットを含むＩＰパケットが生成される。このＩＰパケットは、ＩＰサービス・マルチプレクサー３１０に送られる。

　また、信号送出部３０２から送出される音声信号並びに字幕及び文字スーパー信号に対しても、同様の処理が行なわれる。すなわち、オーディオ・エンコーダー３０４で生成されるＡＡＣ符号化音声信号のＭＭＴパケットを含むＩＰパケットがＩＰサービス・マルチプレクサー３１０に送られるとともに、字幕／文字スーパー・エンコーダー３０５で生成される字幕符号化信号のＭＭＴパケットを含むＩＰパケットがＩＰサービス・マルチプレクサー３１０に送られる。

　また、シグナリング・エンコーダー３０６では、電子データ処理システム３０８から送出される情報に基づいて放送番組の構成などを示す制御情報（ＭＭＴ－ＳＩ）が生成され、ペイロード部にこのＭＭＴ－ＳＩが配置されたＭＭＴパケットを含むＩＰパケットが生成される。これらのＩＰパケットは、ＩＰサービス・マルチプレクサー３１０に送られる。

　また、信号送出部３０２又は電子データ処理システム３０８から送出されるデータ放送アプリケーションは、ファイル・エンコーダー３０７に供給される。ファイル・エンコーダー３０７では、データ放送アプリケーションが例えばＨＴＭＬ５形式に符号化され、さらにパケット化され、このＭＭＴパケットを含むＩＰパケットが生成される。このＩＰパケットは、ＩＰサービス・マルチプレクサー３１０に送られる。

　各ＩＰサービス・マルチプレクサー３１０－１、…、３１０－Ｎでは、各エンコーダー３０３～３０７から送られてくる映像、音声、字幕、（放送サービス単位及びサービス横断の）ＭＭＴ－ＳＩ、及びデータ放送アプリケーション（ＨＴＭＬ５文書）の各々を含むＩＰパケットがマルチプレクスされて、１つのチャンネルを構成するＴＬＶパケットが生成される。

　ＴＬＶシグナリング・エンコーダー３０９では、電子データ処理システム３０８から送出される情報に基づいて、上記のＩＰパケットの多重に関する制御情報（ＴＬＶ－ＳＩ）をペイロード部に配置するＴＬＶパケットが生成される。

　ＴＬＶマルチプレクサー３１１では、各ＩＰサービス・マルチプレクサー３１０－１～３１０－Ｎ及びＴＬＶシグナリング・エンコーダー３０９で生成されるＴＬＶパケットがマルチプレクスされて、ＴＬＶストリームが生成される。変調・送信部３１２では、ＴＬＶマルチプレクサー３１１で生成されたＴＬＶストリームに対してＲＦ変調処理が行なわれ、そのＲＦ変調信号が放送伝送路に送出される。

　図４には、放送送出システム１１からの放送信号を受信する受信機１２の構成例を示している。図示の受信機１２は、チューナー・復調部４０１と、ＭＭＴデマルチプレクサー（ＤＥＭＵＸ）４０２と、時計回復部４０３と、ビデオ・デコーダー４０４と、オーディオ・デコーダー４０５と、文字スーパー・デコーダー４０６と、字幕デコーダー４０７と、マルチメディア（ＭＭ）キャッシュ４０８と、ＳＩキャッシュ４０９と、放送システム制御部４１０と、アプリケーション（Ａｐｐ）・エンジン４１１と、通信インターフェース（ＩＦ）４１２と、スケーラー４１４と、合成部４１５～４１８を備えている。

　チューナー・復調部４０１は、放送信号を選局受信し、復調処理を行なって、ＴＬＶストリームを得る。ＭＭＴデマルチプレクサー４０２は、このＴＬＶストリームに対して、デマルチプレクス処理及びデパケット化処理を行なう。デマルチプレクサー４０２は、パケット・フィルター４０２－１とＳＩフィルター４０２－２を備えている。

　パケット・フィルター４０２－１は、ＴＬＶストリーム識別情報及びＩＰアドレスに基づいてＩＰパケットのフィルタリングを行ない、さらにＭＭＴＰヘッダー内の情報に基づいて、ＩＰパケットからＭＭＴＰパケットをフィルタリングして、映像、音声、字幕、並びにマルチメディア（データ放送アプリケーション）の各符号化コンポーネント、及びシグナリング情報を乗せたＭＭＴＰパケットを、それぞれビデオ・デコーダー４０４、オーディオ・デコーダー４０５、文字スーパー・デコーダー４０６、字幕デコーダー４０７、マルチメディア（ＭＭ）キャッシュ４０８、並びにＳＩフィルター４０２－２に振り分ける。また、ＳＩフィルター４０２－２は、シグナリング情報ＳＩをフィルタリングして、ＳＩキャッシュ４０９にキャッシュする。

　時計回復部４０３は、ＭＭＴデマルチプレクサー４０２内のパケット・フィルター４０２－１でフィルタリングされたＮＴＰパケットに含まれる現在時刻の情報に基づいて、この時刻情報に同期した時刻情報を生成して、各同期型メディアをデコードするにビデオ・デコーダー４０４、オーディオ・デコーダー４０５、文字スーパー・デコーダー４０６、字幕デコーダー４０７にそれぞれ出力する。

　ビデオ・デコーダー４０４は、ＭＭＴデマルチプレクサー４０２で得られる符号化映像信号をデコードして、ベースバンドの映像信号を得る。また、オーディオ・デコーダー４０５は、ＭＭＴデマルチプレクサー４０２で得られる符号化音声信号をデコードして、ベースバンドの音声信号を得る。また、文字スーパー・デコーダー４０６並びに字幕デコーダー４０７は、ＭＭＴデマルチプレクサー４０２で得られる文字スーパー及び字幕符号化信号をそれぞれデコードして、文字スーパー及び字幕の表示信号をそれぞれ得る。

　放送システム制御部４１０は、ＳＩキャッシュ４０９にキャッシュされているＭＭＴ－ＳＩに基づいて、受信機１２全体の放送サービス受信動作を制御する。例えば、放送システム制御部４１０は、ＭＭＴ－ＳＩに含まれるアプリケーションの実行制御情報（ＭＨ－ＡＩＴ：後述）を解析して、起動が指示されているデータ放送アプリケーションを見つけると、アプリケーション・エンジン４１１に対してデータ放送の提示処理を指示する。

　アプリケーション・エンジン４１１は、例えばＨＴＭＬブラウザーなどであり、マルチメディア・キャッシュ４０８にキャッシュされているデータ放送アプリケーション（ＨＴＭＬ５文書など）の処理を行なって、データ放送の表示信号並びに音声信号を生成する。また、アプリケーション・エンジン４１１は、データ放送の表示に必要なデータ・ファイル（データ放送の表示に使用するメディア・データや、リンク先のアプリケーションなど）を、通信インターフェース４１２経由でＩＰネットワークから取得することもできる。

　スケーラー４１４は、ビデオ・デコーダー４０４でデコードされた映像信号（放送映像）を、受信機１２の画面サイズに応じてスケーリング処理する。

　合成部４１５は、オーディオ・デコーダー４０５でデコードされた音声信号と、アプリケーション・エンジン４１１が再生したデータ放送用の音声信号を合成して、出力用の音声信号を生成する。

　合成部４１６は、文字スーパー・デコーダー４２０６がデコードした文字スーパー表示と、字幕デコーダー４０７がデコードした字幕表示を合成する。また、合成部４１７は、スケーラー４１４でスケーリング処理された放送映像と、アプリケーション・エンジン４１１が生成したデータ放送の表示信号を合成する。さらに後段の合成部４１８は、データ放送の表示が重畳された放送映像と、合成部４１６から出力される文字スーパー表示及び字幕表示とを合成して、出力用の映像信号を生成する。

　図４に示した受信機１２の動作について説明しておく。

　チューナー・復調部４０１では、放送信号が受信され、復調処理が行なわれて、ＴＬＶストリームが得られる。ＭＭＴデマルチプレクサー４０２では、このＴＬＶストリームに対して、デマルチプレクス処理及びでパケット化処理を行なわれ、ＮＴＰ時刻情報、映像、音声、文字スーパー及び字幕、データ放送の各符号化信号、並びに、シグナリング情報が抽出され、ビデオ・デコーダー４０４、オーディオ・デコーダー４０５、文字スーパー・デコーダー４０６、字幕デコーダー４０７、マルチメディア（ＭＭ）キャッシュ４０８、ＳＩフィルター４０２－１にそれぞれ振り分けられる。

　また、デマルチプレクサー４０２で抽出されたＮＴＰパケットは、時計回復部４０３に振り分けられる。時計回復部４０３では、ＮＴＰパケットに載せられた時刻情報に基づいて、この時刻情報に同期した時刻情報が生成される。つまり、時計回復部４０３では、放送送出システム１１側の時計部４０１で生成された時刻情報に合った時刻情報が生成される。

　ＭＭＴデマルチプレクサー４０２で抽出された符号化映像信号は、ビデオ・デコーダー４０４に送られてデコードされ、ベースバンドの映像信号が得られる。デマルチプレクサー４０２で抽出された文字スーパー符号化信号は文字スーパー・デコーダー４０６に送られてデコードされ、文字スーパーの表示信号が得られる。また、デマルチプレクサー４０２で抽出された字幕符号化信号は字幕デコーダー４０７に送られてデコードされ、字幕の表示信号が得られる。

　放送システム制御部４１０では、ＳＩフィルター４０２－２並びにＳＩキャッシュ４０９を介して受け取るＭＭＴ－ＳＩに基づいて、データ放送アプリケーションの処理を始め受信機１２による受信処理動作全体が制御される。

　アプリケーション・エンジン４１１では、マルチメディア・キャッシュ４０８にキャッシュされているデータ放送アプリケーション（ＨＴＭＬ５文書など）の処理が行なわれ、データ放送の表示信号並びに音声信号が生成される。

　スケーラー４１４では、ビデオ・デコーダー４０４でデコードされた映像信号（放送映像）のスケーリング処理が行なわれる。また、合成部４１６は、文字スーパー・デコーダー４０６でデコードされた文字スーパー表示と、字幕デコーダー４０７でデコードされた字幕表示が合成される。続いて、合成部４１７では、スケーラー４１４でスケーリング処理された放送映像と、アプリケーション・エンジン４１１で生成されたデータ放送の表示信号が合成される。さらに後段の合成部４１８では、データ放送の表示が重畳された放送映像と、合成部４１６から出力される文字スーパー表示及び字幕表示が合成されて、出力用の映像信号が生成される。

　また、合成部４１５では、オーディオ・デコーダー４０５でデコードされた音声信号と、アプリケーション・エンジン４１１で再生されたデータ放送用の音声信号を合成して、出力用の音声信号が生成される。

Ｂ．放送信号の構成
　図５には、ＭＭＴ方式に従って放送送出システム１１から受信機１２に向けて放送伝送路に送出される放送信号５００のイメージを示している。

　１つのサービスの放送信号は、映像、音声、字幕などの放送番組本編に関わる同期型メディアと、データ放送のような非同期型メディアで構成される（但し、１つの放送サービスは、１つのチャンネルすなわち放送番組に対応するものとする）。これらのメディアを符号化したメディア・データは、ＭＰＵフォーマットにしてＭＭＴＰパケット化され、ＩＰパケットで伝送される。また、メディア・トランスポート方式であるＭＭＴに関わる（放送番組の構成などを示す）制御情報であるＭＭＴ－ＳＩも、ＩＰパケットで伝送される。これらのＩＰパケットは、放送伝送路ではＴＬＶパケットの形式でＴＬＶストリームとして伝送される。ＩＰパケットの多重のためのＴＬＶ多重化形式に関わるシグナリング情報（ＴＬＶ－ＳＩ）も、ＴＬＶパケットの形式で伝送される。

　ＭＭＴ方式では、１つの放送サービスを構成する各メディア・データを異なる伝送路の組み合わせで利用することが容易である。図５に示す例では、放送信号５００として、映像、音声、字幕、データ放送、放送サービスに関する制御情報（ＭＭＴ－ＳＩ）など、データのタイプ毎のＭＭＴ伝送路５０１～５０５が利用されている。各ＭＭＴ伝送路は、それぞれ１つのＩＰデータ・フローに相当する。ここで言うＩＰデータ・フローとは、ＩＰヘッダー及びＵＤＰヘッダーの送信元ＩＰアドレス、宛先ＩＰアドレス、ＩＰヘッダーのプロトコル種別、送信元ポート番号、宛先ポート番号の５種類のフィールドの値がすべて同じとなるＩＰパケットの集合である。

　１つの放送サービスは、映像、音声、字幕、データ放送アプリケーションなどタイプの異なる複数のアセットで構成される「パッケージ」と言うことができる。ここで言う「パッケージ」は、ＭＭＴ伝送路を使って伝送されるメディア・データの論理集合である。また、「アセット」は、コンポーネントと対応関係がある（映像のアセットは映像コンポーネントに対応し、音声のアセットは音声コンポーネントに対応し、字幕のアセットは字幕コンポーネントに対応し、データ放送アプリケーション用のデータ・ファイルのアセットはデータ・ファイルのコンポーネントに対応する）。各アセットは、固有のアセット識別情報（ａｓｓｅｔ＿ｉｄ）で識別される。

　各アセットは、それぞれ同じアセット識別情報を共有する１又はそれ以上のＭＰＵの集合（論理グループ）で構成される。ＭＰＵは、ＭＭＴ方式における伝送単位となるフォーマットである。各ＭＰＵは、アセット識別情報と、該当する伝送路上でのＭＰＵのシーケンス番号で特定される。また、映像、音声、字幕、データ放送アプリケーションなど各メディア（アセット）を伝送するＭＭＴ伝送路は、アセット識別情報で識別することができる。

　同じ放送サービスに関わる各ＭＰＵは、パッケージすなわち放送信号５００内のそれぞれのアセットに専用のＥＳ（Ｅｌｅｍｅｎｔａｒｙ　Ｓｔｒｅａｍ）すなわちＭＭＴ伝送路５０１～５０４上で伝送される。図５に示す例では、伝送路５０１では、映像信号用として共通のアセット識別情報を持つＭＰＵ論理グループからなる符号化映像信号のＭＭＴＰパケットが伝送される。同様に、伝送路５０２では音声信号用として共通のアセット識別情報を持つＭＰＵ論理グループからなる符号化音声信号のＭＭＴパケットが伝送され、伝送路５０３では字幕信号用としての共通のアセット識別情報を持つＭＰＵグループからなる符号化字幕信号のＭＭＴＰパケットが伝送され、伝送路５０４－１並びに５０４－２ではデータ放送アプリケーション用として共通のアセット識別情報を持つＭＰＵ論理グループからなる符号化アプリケーションのＭＭＴＰパケットが伝送される。

　１つのパッケージ（放送サービス）内で、タイプが同じアセットが複数伝送されることもある。タイプが同じでも、各アセットは異なるアセット識別情報を持ち、それぞれ専用のＥＳすなわちＭＭＴ伝送路で伝送される。例えば、同じ放送番組に対して、２以上のデリバリー・セグメントからそれぞれ独立してデータ放送アプリケーションが提供される場合であり、デリバリー・セグメント毎に異なるアセット識別情報が割り振られて、異なるＥＳで伝送される。より具体的に言えば、番組を制作したキー局から提供される放送番組に連動する番組連動型データ放送アプリケーションと、番組を配信する地方局から提供される放送番組に連動しない番組非連動型データ放送アプリケーション（例えば、天気予報やニュースなど）は、通常、別のアセットとして異なるアセット識別情報が割り振られ、別々のＭＰＵ論理グループとして異なるＭＭＴ伝送路で伝送される。図５に示す例では、異なるアセット識別情報が割り振れられた２つのデータ放送アプリケーション用として伝送路５０４－１、５０４－２が描かれている。

　また、ＭＭＴ方式は、放送や通信の複数の伝送路に共通に用いることができる。例えば、データ放送（ＨＴＭＬ５文書など）のような非同期型メディアは、図５に示したように放送信号５００の伝送路５０４－１や５０４－２を用いて同じ放送サービスの同期型メディアとともに伝送される以外に、ＩＰネットワークなど通信伝送路（図示しない）を介して提供することもできる。

　伝送路５０５は、ＭＭＴ方式におけるシグナリング、すなわち、ＭＭＴのパッケージの構成や放送サービスに関連する情報を示す制御情報であるＭＭＴ－ＳＩの伝送に使用される。伝送路５０５では、ＭＭＴ－ＳＩを含んだＭＭＴメッセージがＭＭＴＰパケット化され、カルーセル方式により繰り返し伝送される。なお、図５では、ＴＬＶ－ＳＩ用の伝送路の図示を省略している。

　ＭＭＴ－ＳＩには、メッセージ、テーブル、記述子がある。伝送路５０５で伝送されるメッセージとして、ＰＡメッセージ５１０、Ｍ２セクション・メッセージ５２０、データ伝送メッセージ５３０を挙げることができる。

　ＰＡメッセージ５１０は、放送番組の構成などを示す制御情報であり、アセットのリストやその位置などパッケージを構成する情報を記述するＭＰ（ＭＭＴ　Ｐａｃｋａｇｅ）テーブル５１１を格納するコンテナーである。

　ＭＰ（ＭＭＴ　Ｐａｃｋａｇｅ）テーブル５１１は、放送サービス単位の基本的な受信制御情報を示すテーブルであり、具体的には、アセットのリストや、アセットのロケーション情報など、パッケージを構成する情報を与える。また、ＭＰテーブル５１１は、アプリケーション・サービス記述子などのＭＰＴ記述子を含む。アプリケーション・サービス記述子は、データ放送アプリケーションの運用に必要又は重要な制御情報のロケーション情報（例えば、データ伝送メッセージ、ＭＨ－ＡＩＴ及びＥＭＴをそれぞれ伝送する各Ｍ２セクション・メッセージのロケーション情報）を示す。

　ＰＡメッセージ５１０は、放送サービスのエントリー・ポイントであり、ＰＡメッセージ５１０を伝送するＭＭＴＰパケットには、固定のパケット識別情報（例えば、０ｘ００００）が割り当てられている。また、ＰＡメッセージで伝送されるＭＰテーブルでは、パッケージ（放送番組）を構成する各アセット（映像、音声、字幕、データ放送アプリケーションなど）のアセット識別情報とロケーション情報を示している。したがって、受信機側では、ＭＭＴ伝送路５０４上で、上記固定のパケット識別情報を直接指定してＰＡメッセージ５１０を取得することができる。そして、ＰＡメッセージ５１０で伝送されるＭＰテーブル５１１を参照して、パッケージ（放送番組）を構成する各アセット（映像、音声、字幕、データ放送の各ロケーション情報を間接指定することができる。

　なお、図５では省略したが、ＰＡメッセージ５１０に格納されるテーブルとして、ＭＰテーブル以外に、ＰＬ（Ｐａｃｋａｇｅ　Ｌｉｓｔ）テーブル（ＰＬＴ）、ＬＣ（Ｌａｙｏｕｔ　Ｃｏｎｆｉｇｕｒａｔｉｏｎ）テーブル（ＬＣＴ）を挙げることができる。ＰＬＴは、放送サービスとして提供されるＭＭＴパッケージのＰＡメッセージを伝送するＩＰデータ・フロー及びパケットＩＤ並びにＩＰサービスを伝送するＩＰデータ・フローの一覧を示す。また、ＬＣＴは、提示のためのレイアウト情報をレイアウト番号に対応付けるために用いる。ＰＡメッセージは、ＭＰテーブル、ＰＬテーブル、ＬＣテーブルという最大３つのテーブルを格納することができるコンテナーである。

　Ｍ２セクション・メッセージ５２０は、ＭＰＥＧ－２　Ｓｙｓｔｅｍｓのセクション拡張形式を伝送するメッセージであり、セクション形式のシグナリング・テーブルを１つずつ格納するコンテナーである。各Ｍ２セクション・メッセージ５２０内には、ＭＨ－ＡＩＴ（Ａｐｐｌｉｃａｔｉｏｎ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｔａｂｌｅ）５２１や、ＥＭＴ（Ｅｖｅｎｔ　Ｍｅｓｓａｇｅ　Ｔａｂｌｅ）５２２といったテーブルがそれぞれ１つだけ格納される。

　ＭＨ－ＡＩＴ５２１は、アプリケーションに関する動的制御情報及び実行に必要な付加情報を指定するテーブルであり、具体的には、ＭＭＴ伝送路で送られてくる各データ放送アプリケーション（ファイル・データ）の処理方法（アプリケーションに適用される起動状態など）、並びに、各データ放送アプリケーションのロケーション情報（ＵＲＬ：Ｕｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｌｏｃａｔｏｒ）を指定する。アプリケーションの処理方法として、アプリケーションの自動起動を示すＡＵＴＯＳＴＡＲＴ（ＡＳ）、アプリケーションが実行可能の状態であることを示すＰＲＥＳＥＮＴ（ＰＲ）、アプリケーションの終了を示すＫＩＬＬ、アプリケーションの取得及び保持（事前キャッシュ）を示すＰＲＥＦＥＴＣＨ（ＰＦ）を挙げることができる。

　ＥＭＴ５２２は、イベント・メッセージ伝送方式に用いるシグナリング・テーブルであり、イベント・メッセージ（放送局から受信機上のアプリケーションに対する同期・非同期のメッセージ）に関する情報（イベント・メッセージ記述子）を格納する。イベント・メッセージ伝送方式は、放送局から受信機で動作しているデータ放送アプリケーションに対して、即座にあるいは指定した時刻に、メッセージ情報を送る手段を提供する。

　データ伝送メッセージ５３０は、データ放送アプリケーションの伝送に関する制御情報を伝送するためのメッセージである。データ伝送メッセージ５３０は、データ・ディレクトリー管理テーブル（Ｄａｔａ　Ｄｉｒｅｃｔｏｒｙ　ｍａｎａｇｅｍｅｎｔ　Ｔａｂｌｅ：ＤＤＭＴ）５３１、データ・アセット管理テーブル（Ｄａｔａ　Ａｓｓｅｔ　Ｍａｎａｇｅｍｅｎｔ　Ｔａｂｌｅ：ＤＡＭＴ）５３２、データ・コンテント管理テーブル（Ｄａｔａ　Ｃｏｎｔｅｎｔ　Ｃｏｎｆｉｇｕｒａｔｉｏｎ　Ｔａｂｌｅ：ＤＣＣＴ）５３３という、最大３つのテーブルを同時に格納することができるコンテナーである。データ・ディレクトリー管理テーブル及びデータ・アセット管理テーブルはデータ放送サービスに必須であるが、データ・コンテント管理テーブルは任意である。

　ここで、データ・ディレクトリー管理テーブル５３１は、ディレクトリー単位（言い換えれば、データ放送アプリケーションの制作単位）でデータ放送アプリケーションを管理するためのテーブルである。同テーブル内は、１つのパッケージに含まれるアイテム（ディレクトリー並びにディレクトリーに含まれるサブディレクトリーやファイル）に関するディレクトリー構造を記述しているので、アプリケーションのファイル構成とファイル伝送のための構成を分離することができる。同テーブルは、ディレクトリーやファイルなどの各ノードのパス名と、データ伝送メッセージ内で各ノードを識別するノード・タグとの対応関係を示している。

　また、データ・アセット管理テーブル５３２は、アセット単位でデータ放送アプリケーションを管理するためのテーブルであり、アセット内のＭＰＵの構成とのＭＰＵ毎のバージョン情報を記述している。具体的には、同テーブルは、各コンポーネントのダウンロード識別情報や、コンポーネントを伝送する各ＭＰＵに含まれるノード（ファイル又はディレクトリー）をデータ伝送メッセージ内で識別するノード・タグとＭＭＴ伝送路上でノードを識別するアイテム識別情報との対応関係を示している。

　また、データ・コンテント管理テーブル５３３は、提示単位（Ｐｒｅｓｅｎｔａｔｉｏｎ　Ｕｎｉｔ：ＰＵ）毎にデータ放送アプリケーションを管理するためのテーブルである。同テーブルは、データ放送アプリケーションを提示単位毎に識別する提示単位識別情報と、各提示単位に含まれるノード（ファイル又はディレクトリー）をデータ伝送メッセージ内で識別するノード・タグを示している。また、同テーブルは、提示単位にリンク先となる（遷移する可能性のある）他の提示単位を識別するリンク先提示単位識別情報や、各提示単位のキャッシュ制御に関する情報を含めることができ、受信機側ではデータ放送アプリケーション用のファイル・データの柔軟で有効なキャッシュ制御に利用することができる。

　ＭＭＴによるデータ放送アプリケーションの伝送方式において、データ伝送メッセージで伝送する上記３種類のシグナリング・テーブル５３１～５３３を活用することにより、ファイル単位の伝送データ構造やコンテンツ（データ放送アプリケーション）制作におけるディレクトリー構造とは独立して、アプリケーション単位、提示単位といった利用単位のデータ構造を表現することができる。

　ＭＭＴ－ＳＩとして伝送されるメッセージやテーブルのパケット識別情報は、固定されているものや、他のテーブルから間接指定されるものがある。このうち、ＰＡメッセージは、放送サービスのエントリー・ポイントであり、固定のパケット識別情報（例えば、０ｘ００００）が割り当てられている。ＰＡメッセージで伝送されるＭＰテーブルでは、パッケージ（放送番組）を構成する各アセット（映像、音声、字幕、データ放送アプリケーションなど）のアセット識別情報とロケーション情報を示している。したがって、受信機側では、ＭＭＴ伝送路上で、上記固定のパケット識別情報を直接指定してＰＡメッセージを取得することができる。そして、図６に示すように、ＰＡメッセージで格納されるＭＰテーブルを参照して、放送サービスに関連する各アセット（映像、音声、字幕、データ放送アプリケーションなど）や他のシグナリング・メッセージを間接的に指定することができる。

　また、本実施形態では、ＭＰテーブルは、ＭＰＴ記述子としてアプリケーション・サービス記述子を含むものとする。アプリケーション・サービス記述子は、データ放送アプリケーションの運用に必要又は重要な制御情報のロケーション情報（例えば、データ伝送メッセージ、ＭＨ－ＡＩＴ及びＥＭＴをそれぞれ伝送する各Ｍ２セクション・メッセージのロケーション情報）を示す。

　図２１には、ＰＡメッセージに格納されるＭＰテーブルのシンタックス例２１００を示している。以下、ＭＰテーブルの各パラメーターについて説明する。

　ｔａｂｌｅ＿ｉｄは、当該テーブルがＭＰテーブルであることを識別する８ビットの固定値（０ｘ２０）である。ｖｅｒｓｉｏｎは、ＭＰテーブルのバージョンを示す８ビットの整数値である。例えば、ＭＰテーブルを構成する一部のパラメーターでも更新した場合には、ｖｅｒｓｉｏｎは＋１だけインクリメントされる。ｌｅｎｇｔｈは、このフィールドの直後からカウントされる、ＭＰテーブルのサイズをバイト単位で示す、３２ビット長のパラメーターである。また、ＭＰＴ＿ｍｏｄｅは、このＭＰテーブルがサブセットに分割されているときの動作を示すが、詳細な説明は省略する。

　ＭＭＴ＿ｐａｃｋａｇｅ＿ｉｄ＿ｌｅｎｇｔｈは、パッケージ識別情報（ＭＭＴ＿ｐａｃｋａｇｅ＿ｉｄ）のテキスト情報のサイズをバイト単位で示す。続くパッケージ識別情報のループでは、ＭＭＴ＿ｐａｃｋａｇｅ＿ｉｄをバイト単位（ＭＭＴ＿ｐａｃｋａｇｅ＿ｉｄ＿ｂｙｔｅ）でパッケージ識別情報を示す。パッケージ識別情報は、放送信号（ＩＰデータ・フロー）で伝送されるすべての信号（映像、音声、字幕）、並びにファイル・データなどのアセットをコンポーネントとする全体のパッケージとしての識別情報である。この識別情報は、テキスト情報であり、上位１６ビットはサービスを識別するためのサービス識別情報と同じ値とする。

　ＭＰＴ＿ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈは、ＭＰテーブル記述子領域のサイズをバイト単位で示す。続く、ＭＰテーブル記述子のループでは、ＭＰテーブル記述子の内容をバイト単位（ＭＰＴ＿ｄｅｓｃｒｉｐｔｏｒｓ＿ｂｙｔｅ）で記述する。アプリケーション・サービス記述子は、ＭＰテーブル記述子の１つとして、例えばアプリケーションのデリバリー・セグメント毎に配置される。各アプリケーション・サービス記述子内には、対応するデリバリー・セグメントが提供するデータ放送アプリケーションの運用に必要又は重要な制御情報であるＭＨ－ＡＩＴ、データ伝送メッセージ、及び各ＥＭＴのロケーション情報を示す。また、複数のＥＭＴ伝送路がある場合には、各伝送路のＥＭＴを識別するＥＭＴ＿ｔａｇとそのロケーション情報を示す。アプリケーション・サービス記述子のシンタックスの詳細については、後述に譲る。

　ｎｕｍｂｅｒ＿ｏｆ＿ａｓｓｅｔｓは、パッケージを構成する要素としてのアセット（信号、ファイル）の数を示す、８ビットのパラメーターである。ｎｕｍｂｅｒ＿ｏｆ＿ａｓｓｅｔの数分だけ、アセット情報のループが配置される。１つのアセット情報のループ内には、個々のアセットの情報としてのアセット識別情報（ａｓｓｅｔ＿ｉｄ）と、一般ロケーション情報（ＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏ）と、アセット記述子（ａｓｓｅｔ＿ｄｅｓｃｒｉｐｔｏｒ）の各パラメーターが配置される。アセット情報のループ内に配置される情報について、以下に説明する。

　ｉｄｅｎｔｉｆｉｅｒ＿ｔｙｐｅは、ＭＭＴＰパケット・フローのＩＤ体系を示す。アセット識別情報（ａｓｓｅｔ＿ｉｄ）を示すＩＤ体系であれば０ｘ００とする。ａｓｓｅｔ＿ｉｄ＿ｓｃｈｅｍｅは、アセット識別情報の形式を示す。ａｓｓｅｔ＿＿ｉｄ＿ｌｅｎｇｔｈは、アセット識別情報のテキスト情報のサイズをバイト単位で示す。続くアセット識別情報のループでは、アセット識別情報をバイト単位（ａｓｓｅｔ＿ｉｄ＿ｂｙｔｅ）で示す。

　ａｓｓｅｔ＿ｔｙｐｅは、アセットの種類を３２ビット長の文字列で示す。ａｓｓｅｔ＿ｃｌｏｃｋ＿ｒｅｌａｔｉｏｎ＿ｆｌａｇは、アセットのクロック情報フィールドの有無を示すフラグである。当該フラグが１のときは、クロック情報識別フィールド（ａｓｓｅｔ＿ｃｌｏｃｋ＿ｒｅｌａｔｉｏｎ＿ｉｄ）とタイムスケール・フラグ・フィールド（ａｓｓｅｔ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇ）が存在し、０のときはこれらのフィールドは存在しない。ｌｏｃａｔｉｏｎ＿ｃｏｕｎｔは、アセットのロケーション情報の数を示し、続くｌｏｃａｔｉｏｎ＿ｃｏｕｎｔの数だけ繰り返されるロケーション情報のループでは、該当するアセットのロケーション情報であるＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏが示される。アセットのロケーション情報は、アセットの取得先となるＭＭＴ伝送路上のパケット識別情報（ｐａｃｋｅｔ＿ｉｄ：ＰＩＤ）の形式で記述される。したがって、ＭＰテーブル上でアセット識別情報を引いて、ＭＭＴ伝送路（ＩＰデータ・フロー）上の該当するパケット識別情報を取り出すことができる（図１２を参照のこと）。ＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏのデータ構造の詳細については説明を省略する。本実施形態では、ＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏは、放送で伝送される場合における、ＩＰデータ・フローのＭＭＴＰパケットを示すパケット識別情報であると理解されたい（以下、同様）。

　ａｓｓｅｔ＿ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈは、アセット記述子（ａｓｓｅｔ＿ｄｅｓｃｒｉｐｔｏｒ）のテキスト情報のサイズをバイト単位で示す。続くアセット記述子のループでは、アセット毎の記述子の内容をバイト単位（ａｓｓｅｔ＿ｄｅｓｃｒｉｐｔｏｒｓ＿ｂｙｔｅ）で示す。

　図２２には、ＭＰテーブル内に配置されるアプリケーション・サービス記述子のシンタックス例２２００を示している。以下、アプリケーション・サービス記述子の各パラメーターについて説明する。

　ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇ（記述子タグ）は、８ビットのフィールドで、当該記述子の種類を識別する。ｄｅｓｃｒｉｐｔｏｒｓ＿ｌｅｎｇｔｈは、このフィールドより後に続くデータ・バイト数を書き込む領域である。

　ａｐｐｌｉｃａｔｉｏｎ＿ｆｏｒｍａｔ＿ｍａｐは、アプリケーション・サービスで適用されている方式をビットマップで示す。具体的には、ビット０をＨＴＭＬ５として、０ｘ００の固定運用とする。ＨＴＭＬ５のみ対応の受信機はｂｉｔ０＝１であることのみをチェックし、他のビット位置の値は無視する。

　ｄｅｆａｕｌｔ＿ＡＩＴ＿ｆｌａｇは、対応するデリバリー・セグメントから伝送されるＭＨ－ＡＩＴがデフォルトの監視対象ＡＩＴであるか否かを示すフラグである。

　ＤＴ＿ｍｅｓｓａｇｅ＿ｆｌａｇは、対応するデリバリー・セグメントから、データ放送アプリケーションの制御情報としてデータ伝送メッセージが伝送されるか否かを示すフラグである。

　ＥＭＴ＿ｎｕｍは、ＥＭＴの伝送数を示す。例えば、放送番組向けに複数のデリバリー・セグメントからデータ放送アプリケーションが伝送される場合、ＥＭＴもデリバリー・セグメント毎の伝送路で伝送される。ＥＭＴの伝送数が複数となる場合、各伝送路のＥＭＴはＥＭＴ＿ｔａｇで識別される。なお、ＩＰネットワークでのみデータ放送アプリケーションを伝送する場合（放送信号ではデータ放送アプリケーションを伝送しない場合）には、データ伝送メッセージやＥＭＴは伝送されない。

　ＡＩＴ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏは、Ｍ２セクション・メッセージで伝送されるシグナリング・テーブルの１つであるＭＩＴ－ＡＩＴのロケーション情報を、ＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏのシンタックスに従って示す。

　また、ＤＴ＿ｍｅｓｓａｇｅ＿ｆｌａｇが１のときには、データ伝送メッセージのロケーション情報ＤＴ＿ｍｅｓｓａｇｅ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏが、ＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏのシンタックスに従って示される。

　ＥＭＴ＿ｎｕｍの数（ＥＭＴの伝送数）分のループで、各ＥＭＴの識別子であるＥＭＴ＿ｔａｇとロケーション情報ＥＭＴ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏが指定される。ＥＭＴ＿ｔａｇは、アプリケーションからのリスナー設定時に参照される情報である。また、ＥＭＴ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏは、ＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏのシンタックスに従って示される。ＥＭＴは放送信号でのみ伝送されるので、ＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏのｌｏｃａｔｉｏｎ＿ｔｙｐｅは基本的に「０ｘ００」である。

　ｐｒｉｖａｔｅ＿ｄａｔａは、必要に応じて運用にて利用可能な拡張領域である。

　図７には、Ｍ２セクション・メッセージをコンテナーとして伝送されるＭＨ－ＡＩＴのシンタックス例７００を示している。以下、ＭＨ－ＡＩＴの各パラメーターの意味について説明する。

　ｔａｂｌｅ＿ｉｄ（テーブル識別）は、各種シグナリング情報においてアプリケーション情報（ＡＩ）テーブルであることを識別する８ビットの固定値であり、本実施形態では０ｘ８９とする。ｓｅｃｔｉｏｎ＿ｓｙｎｔａｘ＿ｉｎｄｉｃａｔｏｒ（セクション・シンタクス指示）は、１ビットのフィールドで、常に「１」とする。ｓｅｃｔｏｉｎ＿ｌｅｎｇｔｈ（セクション長）は、１２ビットのフィールドで、セクション長フィールドからＣＲＣ３２を含むセクションの最後までのセクションのバイト長を規定する。この値は４０９３（１６進数で０ｘＥＦＤ）を超えないものとする。

　ａｐｐｌｉｃａｔｉｏｎ＿ｔｙｐｅ（アプリケーション・タイプ）は、１６ビットのフィールドで、当該ＭＨ－ＡＩＴの制御対象となるアプリケーションのタイプを示す。アプリケーション・タイプの割り当ては、以下の表１に従うものとする。

　ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒ（バージョン番号）は、５ビットのフィールドで、サブテーブルのパーション番号である。ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒは、当該ＭＨ－ＡＩＴのバージョン番号であり、サブテーブル内の情報に変化があった場合に＋１だけインクリメントされる。また、バージョン番号の値が「３１」になったとき、その次は「０」に戻る。ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒ（カレント・ネクスト指示）は、常に「１」とする。ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒ（セクション番号）は、８ビットのフィールドで、セクションの番号を表す。サブテーブル内で最初のセクションのセクション番号は０ｘ００である。セクション番号は、同一のテーブル識別及びアプリケーション・タイプを持つセクションが追加される度に＋１だけインクリメントされる。ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒ（最終セクション番号）は、８ビットのフィールドであり、そのセクションが属するサブテーブルにおける最後のセクション番号を規定する。

　ｃｏｍｍｏｎ＿ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈ（共通記述子ループ長）は、８ビットのフィールドで、後続のｄｅｓｃｒｉｐｔｏｒのバイト長を示し、このバイト数分のコモン・ループからなる一連の領域に、ｄｅｓｃｒｉｐｔｏｒ（共通記述子）が書き込まれる。共通記述子領域は、ＡＩＴサブテーブル内のすべてのアプリケーションに適用される。

　ａｐｐｌｉｃａｔｉｏｎ＿ｌｏｏｐ＿ｌｅｎｇｔｈは、このＭＨ　ＡＩテーブルに含まれるアプリケーション情報の数を書き込む領域である。そして、ａｐｐｌｉｃａｔｉｏｎ＿ｌｏｏｐ＿ｌｅｎｇｔｈが示す数分だけ、アプリケーション情報ループが配置される。

　１つのアプリケーション情報ループ内には、ａｐｐｌｉｃａｔｉｏｎ＿ｉｄｅｎｔｉｆｉｅｒ（アプリケーション識別子）と、ａｐｐｌｉｃａｔｉｏｎ＿ｃｏｎｔｒｏｌ＿ｃｏｄｅ（アプリケーション制御コード）と、アプリケーション情報が配置される。

　ここで、ａｐｐｌｉｃａｔｉｏｎ＿ｉｄｅｎｔｉｆｉｅｒ（アプリケーション識別子）は、アプリケーションを識別するパラメーターである。ａｐｐｌｉｃａｔｉｏｎ＿ｃｏｎｔｒｏｌ＿ｃｏｄｅ（アプリケーション制御コード）は、８ビットのフィールドで、アプリケーションの状態を制御する制御コードを規定する。このフィールドのセマンティックスは、アプリケーション・タイプの値に依存する。アプリケーション・タイプに依存しない場合のアプリケーション制御コードのセマンティックスを表２に示しておく。

　ａｐｐｌｉｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒ＿ｌｏｏｐ＿ｌｅｎｇｔｈ（アプリケーション情報記述子ループ長）はアプリケーション情報記述子のバイト長を示し、このバイト数分のループからなるアプリケーション情報記述子領域７０１には、ｄｅｓｃｒｉｐｔｏｒ（アプリケーション情報記述子）が書き込まれる。この記述子領域７０１内のアプリケーション情報記述子は、上記の共通記述子とは相違し、ａｐｐｌｉｃａｔｉｏｎ＿ｉｄｅｎｔｉｆｉｅｒで指定したアプリケーションのみに適用される。アプリケーション情報ループには、例えばＭＨ－アプリケーション記述子や、ＭＨ－伝送プロトコル記述子が配置される。

　そして、当該テーブルの最後に、ＩＴＵ－Ｔ勧告Ｈ．２２２．０に従う巡回冗長符号ＣＲＣ３２（ＣＲＣ）が付加される。

　図８には、ＭＨ－伝送プロトコル記述子（以下、単に「伝送プロトコル記述子」とする）のシンタックス例８００を示している。伝送プロトコル記述子は、アプリケーションの伝送手段として放送や通信などの伝送プロトコルの指定と伝送プロトコルに依存したアプリケーションのロケーション情報を示すことを目的として、ＭＨ－ＡＩＴの共通記述子ループ又はアプリケーション情報記述子のループに配置される。以下、伝送プロトコル記述子の各パラメーターの意味について説明する。

　ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇは、当該記述子８００を識別する、８ビットの固定値を示す。ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈは、このフィールドより後に続く当該記述子のデータのバイト長を書き込む、８ビットの領域である。

　ｐｒｏｔｏｃｏｌ＿ｉｄ（プロトコル識別情報）は、アプリケーションを伝送するプロトコルを示す。プロトコル識別情報の各値が示す意味を以下の表３に示しておく。プロトコル識別情報の値としては、０ｘ０００３はＨＴＴＰ並びにＨＴＴＰＳ伝送、０ｘ０００５はＭＭＴ並びに非同期型伝送を規定する。

　ｔｒａｎｓｐｏｒｔ＿ｐｒｏｔｏｃｏｌ＿ｌａｂｅｌ（伝送プロトコル・ラベル）は、１つのアプリケーションを複数の経路で伝送する場合にその伝送手段を一意に識別する値であり、アプリケーション情報記述子の同名のフィールドに対応する。

　ｓｅｌｅｃｔｏｒ＿ｂｙｔｅ（セレクター・バイト）は、補足情報を格納する領域であり、プロトコル識別情報毎にシンタックスが規定される。図９には、ＨＴＴＰ／ＨＴＴＰＳ、ＭＭＴ非同期型伝送に共通のセレクター・バイトのシンタックス例９００を示している。以下、セレクター・バイトの各パラメーターについて説明する。

　ＵＲＬ＿ｂａｓｅ＿ｌｅｎｇｔｈはアプリケーションを取得するためのＵＲＬのベース部のバイト長を示し、このバイト数分のループからなる一連の領域にプリケーションを取得するためのＵＲＬのベース部の文字列がバイト単位（ＵＲＬ＿ｂａｓｅ＿ｂｙｔｅ）で書き込まれる。

　ＵＲＬ＿ｅｘｔｅｎｓｉｏｎ＿ｃｏｕｎｔは、アプリケーションを取得するためのＵＲＬの拡張部分（ＵＲＬ＿ｂａｓｅに続くＵＲＬ＿ｅｘｔｅｎｓｉｏｎ）の数を示し、ＵＲＬ＿ｅｘｔｅｎｓｉｏｎ＿ｃｏｕｎｔの数分だけＵＲＬ＿ｅｘｔｅｎｓｉｏｎのループが配置される。そして、１つのＵＲＬ＿ｅｘｔｅｎｓｉｏｎのループ内では、ＵＲＬ＿ｅｘｔｅｎｓｉｏｎ＿ｌｅｎｇｔｈはＵＲＬの拡張部分のバイト長を示し、このバイト数分のループからなる一連の領域にＵＲＬの拡張部分の文字列がバイト単位（ＵＲＬ＿ｅｘｔｅｎｔｉｏｎ＿ｂｙｔｅ）で書き込まれる。

　例えば、ＵＲＬのベース部が“ｈｔｔｐ：／／ｗｗｗ．ｘｂｃ．ｃｏｍ”で、ＵＲＬの拡張部が“ｉｎｄｅｘ．ｈｔｍｌ”であれば、これらの文字列を連結して、完全なＵＲＬ“ｈｔｔｐ：／／ｘｂｃ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌ”を得ることができる。

　要するに、ＭＨ－ＡＩＴは、アプリケーション情報ループにおいて、各アプリケーションの状態とロケーション情報を示す。すなわち、ａｐｐｌｉｃａｔｉｏｎ＿ｃｏｎｔｒｏｌ＿ｃｏｄｅ（アプリケーション制御コード）でアプリケーションの状態を示すとともに、伝送プロトコル記述子でアプリケーションのロケーション情報をＵＲＬ形式で示している。

　ＭＭＴ方式によるアプリケーションの伝送では、アプリケーションの伝送期間で直接アプリケーションの制御を行なわず、ＭＨ－ＡＩＴだけでアプリケーションの実行制御を行なう仕組みとなっている。

　図１０には、データ伝送メッセージをコンテナーとして伝送されるデータ・ディレクトリー管理テーブル（ＤＤＭＴ）のシンタックス例１０００を示している。以下、データ・ディレクトリー管理テーブルの各パラメーターの意味について説明する。

　ｔａｂｌｅ＿ｉｄ（テーブル識別子）には、各種シグナリング情報においてデータ・ディレクトリー管理テーブルであることを示す８ビットの固定値が書き込まれる。ｖｅｒｓｉｏｎ＿（バージョン）は、当該データ・ディレクトリー管理テーブルのバージョンを示す８ビットの整数値のパラメーターである。例えば当該テーブルを構成する一部のパラメーターでも更新した場合には、ｖｅｒｓｉｏｎは＋１だけインクリメントされる。ｌｅｎｇｔｈは、このフィールドの直後からカウントされる、当該データ・ディレクトリー管理テーブルのサイズをバイト単位で示す、１６ビット長のパラメーターである。

　ｂａｓｅ＿ｄｉｒｅｃｔｏｒｙ＿ｐａｔｈ＿ｌｅｎｇｔｈは、ベース・ディレクトリー・ノード・パス領域のバイト長を示し、このバイト数分のループからなる一連の領域にベース・ノード・ディレクトリー・パスがバイト単位（ｂａｓｅ＿ｄｉｒｅｃｔｏｒｙ＿ｐａｔｈ＿ｂｙｔｅ）で書き込まれる。ベース・ディレクトリー・パスは、例えば、対応するディレクトリーへアクセスするための絶対的なＵＲＬ形式で表記される。

　ｎｕｍ＿ｏｆ＿ｄｉｒｅｃｔｏｒｙ＿ｎｏｄｅｓは、当該データ・ディレクトリー管理テーブルに記載されるディレクトリーのノードの数を示す。そして、ｎｕｍ＿ｏｆ＿ｄｉｒｅｃｔｏｒｙ＿ｎｏｄｅｓの数分だけディレクトリー・ノードのループが配置され、ディレクトリー毎の情報が格納される。

　１つのディレクトリー・ノードのループ内には、当該データ・ディレクトリー管理テーブルに格納される各ディレクトリー・ノードの属性情報と、ディレクトリーに含まれる各ファイル・データの情報が格納される。

　ｎｏｄｅ＿ｔａｇは、ディレクトリー・ノードのノード・タグとしてディレクトリーを識別するラベルを示す。ｄｅｒｅｃｔｏｒｙ＿ｎｏｄｅ＿ｖｅｒｓｉｏｎは、ディレクトリー・ノードのバージョンを示す。ｄｉｒｅｃｔｏｒｙ＿ｎｏｄｅ＿ｐａｔｈ＿ｌｅｎｇｔｈはディレクトリー・ノード・パス領域のバイト長を示し、このバイト数分のループからなる一連の領域にディレクトリー・ノード・パスがバイト単位（ｄｉｒｅｃｔｏｒｙ＿ｎｏｄｅ＿ｐａｔｈ＿ｂｙｔｅ）で書き込まれる。

　ｎｕｍ＿ｏｆ＿ｆｉｌｅｓは、当該ディレクトリーに含まれるファイルの数を示す。そして、ｎｕｍ＿ｏｆ＿ｆｉｌｅｓの数分だけファイル・ノードのループが配置される。各ファイル・ノードのループ内には、当該ディレクトリーに含まれる各ファイル・データの情報として、ｎｏｄｅ＿ｔａｇと、ファイル名が格納される。このループ内のｎｏｄｅ＿ｔａｇは、ファイルのノード・タグとしてファイルを識別するラベルを示す。ｆｉｌｅ＿ｎａｍｅ＿ｂｙｔｅはファイル名領域のバイト長を示し、このバイト数分のループからなる一連の領域にファイル名がバイト単位（ｆｉｌｅ＿ｎａｍｅ＿ｌｅｎｇｔｈ）で書き込まれる。

　ディレクトリー・ノード・パスは、対応するディレクトリーへアクセスするための、ベース・ディレクトリー・パスからの相対的なＵＲＬ形式で表記される。さらにファイル名を含めこれらの文字列を連結することによりファイルにアクセスする完全なＵＲＬを得ることができる。例えば、ベース・ディレクトリーパス（ＵＲＬ）が“ｈｔｔｐ：／／ｗｗｗ．ｘｂｃ．ｃｏｍ”で、ディレクトリー・ノード・パス（ＵＲＬ）が“ｐｒｏｇｒａｍＡ”であり、さらにファイル名が“ｉｎｄｅｘ．ｈｔｍｌ”であれば、データ・ディレクトリー管理テーブルによる指定に従ってこれらの文字列を連結して、完全なＵＲＬ“ｈｔｔｐ：／／ｗｗｗ．ｘｂｃ．ｃｏｍ／ｐｒｏｇｒａｍＡ／ｉｎｄｅｘ．ｈｔｍｌ”を得ることができる。

　また、図１１には、データ伝送メッセージをコンテナーとして伝送されるデータ・アセット管理テーブル（ＤＡＭＴ）のシンタックス例１１００を示している。以下、データ・アセット管理テーブルの各パラメーターについて説明する。

　ｔａｂｌｅ＿ｉｄ（テーブル識別）は、各種シグナリング情報においてデータ・アセット管理テーブルであることを示す８ビットの固定値である。ｖｅｒｓｉｏｎ＿（バージョン）は、このデータ・アセット管理テーブルのバージョンを示す８ビットの整数値のパラメーターである。例えばデータ・アセット管理テーブルを構成する一部のパラメーターでも更新した場合には、ｖｅｒｓｉｏｎは＋１だけインクリメントされる。ｌｅｎｇｔｈは、このフィールドの直後からカウントされる、このデータ・アセット管理テーブルのサイズをバイト単位で示す、１６ビット長のパラメーターである。

　ｎｕｍｂｅｒ＿ｏｆ＿ｄａｔａ＿ｃｏｍｐｏｎｅｎｔｓは、パッケージに含まれるデータ・コンポーネントの数（すなわち、データ放送アプリケーションのアセット数）を示す、８ビットのパラメーターである。例えば、１つのパッケージ（放送番組）で番組連動型データ放送アプリケーションと番組非連動型データ放送アプリケーションの２種類のデータ・コンポーネントが伝送されることが想定される。ｎｕｍｂｅｒ＿ｏｆ＿ｄａｔａ＿ｃｏｍｐｏｎｅｎｔｓの数分だけ、以下のデータ・コンポーネント（すなわち、アセット）のループが配置され、データ・コンポーネント毎の情報が格納される。各データ・コンポーネントのループ内には、データ・コンポーネントの属性情報と、データ・コンポーネントに含まれるＭＰＵの情報が書き込まれる。

　データ・コンポーネントの属性情報として、ｔｒａｎｓａｃｔｉｏｎ＿ｉｄ（トランザクション識別情報）と、ｃｏｍｐｏｎｅｎｔ＿ｔａｇ（コンポーネント・タグ）と、ｄｏｗｎｌｏａｄ＿ｉｄ（ダウンロード識別情報）が含まれる。ｔｒａｎｓａｃｔｉｏｎ＿ｉｄは、当該データ・コンポーネントのバージョン機能を持つ識別子である。ｃｏｍｐｏｎｅｎｔ＿ｔａｇは、当該データ・コンポーネントのストリームを識別するためのラベルである。ｃｏｍｐｏｎｅｎｔ＿ｔａｇは、ＭＰテーブル内にアセット記述子として配置されるＭＨストリーム識別記述子内のｃｏｍｐｏｎｅｎｔ＿ｔａｇと同一の値であるとする。

　ｄｏｗｎｌｏａｄ＿ｉｄは、データ・コンテンツを一意に識別するためのラベルの役割をする。アプリケーションを伝送するＭＭＴＰパケットには、必要に応じて、マルチ拡張ヘッダー領域にダウンロード識別情報を記載する。また、データ・イベントの運用を行なう場合には、３２ビット長のダウンロード識別情報のビット２８～３１にｄａｔａ＿ｅｖｅｎｔ＿ｉｄを符号化するようになっている。また、アプリケーション（非同期型メディア）を伝送するＭＭＴＰパケットには、必要に応じて拡張ヘッダーにダウンロード識別情報が書き込まれる。

　ｎｕｍ＿ｏｆ＿ｍｐｕｓは、当該データ・コンポーネントに含まれるＭＰＵの数を示す。そして、ｎｕｍ＿ｏｆ＿ｍｐｕｓの数分だけ配置されるＭＰＵのループ内には、各ＭＰＵの属性情報が格納される。ＭＰＵ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒは、ＭＰＵに割り振られるＭＰＵシーケンス番号である。ｎｕｍ＿ｏｆ＿ｉｔｅｍｓは、ＭＰＵに含まれるアイテム（ファイル・データ）の数を示す。そして、ｎｕｍ＿ｏｆ＿ｉｔｅｍｓの数分だけ配置されるアイテムのループ内には、各アイテムの情報が格納される。

　１つのアイテムのループ内には、アイテムの属性情報とアイテムに関する情報が格納される。アイテムの属性情報として、ｉｔｅｍ＿ｉｄ、ｎｏｄｅ＿ｔａｇ、ｉｔｅｍ＿ｓｉｚｅ、ｉｔｅｍ＿ｖｅｒｓｉｏｎ、ｉｔｅｍ＿ｃｈｅｃｋｓｕｍが格納される。ｉｔｅｍ＿ｉｄは、ＭＭＴ伝送路上でアイテムを一意に識別する３２ビットの値である。ｎｏｄｅ＿ｔａｇは、アイテムに対応するノード・タグとしてアイテムを識別する１６ビットの値である。シグナリング情報としては、３２ビットのｉｔｅｍ＿ｉｄに代えて１６ビットのｎｏｄｅ＿ｔａｇを使用することで、データ伝送メッセージ上のアイテムの識別に必要なビット・サイズを削減することができる。ｉｔｅｍ＿ｓｉｚｅは、アイテムのサイズをバイト単位で表す。ｉｔｅｍ＿ｖｅｒｓｉｏｎは、アイテムのバージョンを示し、アイテムの内容が更新される度にｖｅｒｓｉｏｎは＋１だけインクリメントされる。ｉｔｅｍ＿ｃｈｅｃｋｓｕｍは、アイテムのチェックサムを示す。なお、チェックサムは、すべてのファイルに対して必ず設定するのは情報量が多いと考えられるので、１ビットのｃｈｅｃｋ＿ｓｕｍ＿ｆｌａｇを設定し、これに１が代入された場合にのみ３２ビットのｉｔｅｍ＿ｃｈｅｃｋ＿ｓｕｍが現れる。ｃｈｅｃｋｓｕｍ＿ｆｌａｇはチェックサムの記載があるか否かを示すフラグであり、このフラグが１のときにはｉｔｅｍ＿ｃｈｅｃｋｓｕｍが記載される。ｉｔｅｍ＿ｉｎｆｏ＿ｌｅｎｇｔｈは後続のアイテム情報領域のバイト長を示し、このバイト数分のループからなる一連の領域にアイテムに関する情報がバイト単位（ｉｔｅｍ＿ｉｎｆｏ＿ｂｙｔｅ）で書き込まれる。

　また、ＭＰＵのループ内には、各ＭＰＵの情報が格納される。具体的には、ＭＰＵ＿ｉｎｆｏ＿ｌｅｎｇｔｈは後続のＭＰＵ情報領域のバイト長を示し、このバイト数分のループからなる一連の領域にＭＰＵに関する情報がバイト単位（ｉｔｅｍ＿ｉｎｆｏ＿ｂｙｔｅ）で書き込まれる。

　ｄｅｓｃｒｉｐｔｏｒ＿ｌｏｏｐ＿ｌｅｎｇｔｈは、ｄｅｓｃｒｉｐｔｏｒの全バイト長を示す。ｄｅｓｃｒｉｐｔｏｒは、ｄｅｓｃｒｉｐｔｏｒ＿ｌｏｏｐ＿ｌｅｎｇｔｈの数分のループからなる一連の領域に記述子（ｄｅｓｃｒｉｐｔｏｒ）の情報を格納する。格納される記述子は別途定義する。

　ＭＨ－ＡＩＴでは、各アプリケーションのロケーション情報は、ＵＲＬ形式、言い換えれば、ディレクトリー・ノード名とファイル名の組み合わせからなるパス名で記述される。一方、データ伝送メッセージで伝送されるデータ・ディレクトリー管理テーブル及びデータ・アセット管理テーブルを用いて、アセットのパス名をＭＭＴ伝送路上の識別情報（パケット識別情報）に変換することができる。図１２を参照しながら、ＭＭＴ伝送されるデータ放送に関連するファイルを取得する仕組みについて、簡単に説明しておく。

　受信機は、Ｍ２セクション・メッセージで伝送されるＭＨ－ＡＩＴ内のアプリケーション情報ループを参照して、起動すべきアプリケーション（例えば、アプリケーション制御コードで自動起動（ａｕｔｏｓｔａｒｔ）が指定されたアプリケーション）を検知することができる。また、受信機は、ＭＨ－ＡＩＴに配置されている伝送プロトコル記述子から、アプリケーションのロケーション情報すなわちパス名を取得することができる。放送で伝送されるアプリケーションの場合には、参照番号１２０１で示すように、データ伝送メッセージ内のデータ・ディレクトリー管理テーブルから、指定されたパス名に対応するファイルのノード・タグを得ることができる。

　次いで、参照番号１２０２で示すように、同じくデータ伝送メッセージ内のデータ・アセット管理テーブルから、データ・ディレクトリー管理テーブルで得られたノード・タグを持つアイテムが伝送されるデータ・アセットのコンポーネント・タグ、ダウンロード識別情報、ＭＰＵシーケンス番号、及びアイテム識別情報を得ることができる。

　さらに、参照番号１２０３で示すように、ＭＰテーブルから、データ・アセット管理テーブルで得られたコンポーネント・タグを持つアセットのロケーション情報を取得すると、参照番号１２０４で示すように、該当するファイルが実際に伝送されるデータ・アセットを特定することができる。

　そして、特定されたデータ・アセット内で、データ・アセット管理テーブルから得られたダウンロード識別情報とアイテムを伝送するＭＭＴＰパケットのヘッダー領域に記載されたダウンロード識別情報とにより、カルーセルに対応するファイルの繰り返し伝送の単位を一意に識別することができる。参照番号１２０５で示すように、繰り返し伝送されるアイテムのうち、データ・アセット管理テーブルから得られたＭＰＵシーケンス番号及びアイテム識別情報を持つアイテムを所望のファイルとして指定することができる。

Ｄ．アプリケーションの伝送方式
　従来のＭＰＥＧ２－ＴＳ方式によるデータ放送アプリケーションの伝送では、特定のアプリケーション・セットのデータの伝送期間はデータ・イベント識別子で指定され、データ・イベントはアプリケーション・セットの有効期間を示す情報に位置付けられる。これは、従来のＭＰＥＧ２－ＴＳ方式では、アプリケーションの伝送期間とアプリケーションの実行期間が等しいという前提があるからである。

　ＭＭＴ方式においても、データ放送アプリケーションの伝送には、データ・イベントという概念が、従来のＭＰＥＧ２－ＴＳ方式を継承する形で導入されている。

　ここで、データ・イベントは、一塊のデータ放送の内容を伝送する、開始時刻と終了時刻が定められたデータ放送ストリームの集合を指す。番組内か番組間かに関わらず、データ放送の内容の提示の切り替えを随時発生可能とする目的で、データ・イベントはイベントとは直接の時間関係を有しない。また、１つのデータ・イベントの中で伝送されるデータ放送をローカル・コンテンツという。一般に、ローカル・コンテンツは、内容の持つ意味や制作編成上の理由などにより決定する一塊のデータ群により構成される。

　ＭＭＴ方式では、従来のＭＰＥＧ２－ＴＳ方式とは相違して、データ・イベントは単にアプリケーションの伝送期間を示す。何故ならば、アプリケーションの伝送期間で直接アプリケーションの制御を行なわず、ＭＨ－ＡＩＴだけで実行制御を行なう仕組みとなっているからである。

　図１３には、ＭＭＴ方式におけるアプリケーションの伝送並びにアプリケーション実行のシナリオを例示している。同図では、ある放送事業者（放送局）から送信される放送信号（ＴＬＶストリーム）１３００を例示しており、横軸を時間軸とする。期間ｔ１～ｔ３は１つの放送番組Ｐのオンエア期間であり、この放送番組Ｐは時刻ｔ２（但し、ｔ１＜ｔ２＜ｔ３）で番組コーナーが切り替わるものとする。

　放送信号１３００は、放送番組を構成するコンポーネントとして、映像アセット１３０１、音声アセット１３０２、字幕／文字スーパー・アセット（図示しない）を含んでいる。

　また、放送信号１３００は、２つのアプリケーション・アセット（ＡｐｐＡｓｓｅｔ）１３０３、１３０４を含んでいる。但し、アプリケーション・アセット１３０３は番組連動型アプリケーションのアセットであり、アプリケーション・アセット１３０４は番組非連動型アプリケーションのアセットである。

　一方のアプリケーション・アセット１３０３にはデータ・イベントの概念が導入されている。すなわち、番組の境界や番組コーナーの境界に同期するようにしてデータ・イベントが切り替わり、データ・イベント毎にローカル・コンテンツが入れ替えられている。図１３に示す例では、放送番組Ｐの前半の期間ｔ１～ｔ２では、番組連動型アプリケーションの集合からなるローカル・コンテンツａｐｐ１、ａｐｐ２が伝送される。また、放送番組の後半の期間ｔ２～ｔ３では、番組連動型アプリケーションの集合からなるローカル・コンテンツａｐｐ６、ａｐｐ７が伝送される。また、アプリケーション・アセット１３０３上で相隣り合うデータ・イベントを区別するために、データ・イベント毎にデータ・イベント識別情報（ｄａｔａ＿ｅｖｅｎｔ＿ｉｄ）が割り当てられる。

　他方のアプリケーション・アセット１３０４は、番組の切り替わりや番組コーナーの切り替わりには連動せずに、全期間を通して番組非連動型アプリケーション集合ａｐｐ３、ａｐｐ４、ａｐｐ５が伝送され続ける。アプリケーション・アセット１３０４では、放送番組Ｐのオンエア時間内にデータ・イベントの切り替わりは発生しない。

　なお、図１３の最下段では、アプリケーション間の遷移関係を矢印で例示している。データ・コンテント管理テーブル（前述）では、遷移関係が提示単位で示されている。

　さらに、放送信号１３００は、制御情報（ＭＭＴ－ＳＩ）として、参照番号１３０５～１３１０で示すように、ＥＩＴｐｆ、ＡＩＴ（ＭＨ－ＡＩＴ）、ＤＤＭＴ（データ・ディレクトリー管理テーブル）、ＤＡＭＴ（データ・アセット管理テーブル）、ＤＣＣＴ（データ・コンテント管理テーブル）、ＥＭＴの各シグナリング・テーブルがそれぞれ伝送される。なお、放送信号１３００で伝送されるシグナリング・テーブルは上記以外にもあるが、以下の説明に直接関連しないので、図示を省略する。

　ここで、イベント情報テーブル（ＥＩＴ）は、チャンネルに含まれる各コンテンツの放送時間帯を示す番組時間情報などの番組情報を含む番組配列情報である。参照番号１３０５で示すＥＩＴｐｆは、番組の変更や終了によって更新されるＥＩＴｐ（現在放送中の番組に対するＥＩＴ）、ＥＩＴｆ（現在放送中の次の番組に対するＥＩＴ）のことである。

　参照番号１３０６で示すアプリケーション情報テーブル（ＡＩＴ）は、アプリケーションの実行制御に関する情報を示すシグナリング・テーブルであり、Ｍ２セクション・メッセージをコンテナーとして伝送される。アプリケーション情報テーブル１３０６は、各アプリケーション・アセット１３０３、１３０４で伝送されるすべてのアプリケーションの状態をアプリケーション制御コードで指定するとともに、各アプリケーションのロケーション情報を伝送プロトコル記述子でＵＲＬ形式により指定する。

　図１３に示す例では、時刻ｔ１～ｔ２のローカル・コンテンツに対応するアプリケーション実行期間では、アプリケーション情報テーブルは、参照番号１３２１で示すように、各アプリケーションａｐｐ１、ａｐｐ２、ａｐｐ３、ａｐｐ４、ａｐｐ５の状態が順にａｓ（ａｕｔｏｓｔａｒｔ：自動起動）、ｐｒ（ｐｒｅｓｅｎｔ：実行可能）、ｐｒ、ｐｒ、ｐｒであることを、各アプリケーションのロケーション情報とともに示している。また、時刻ｔ２～ｔ３のローカル・コンテンツに対応するアプリケーション実行期間では、アプリケーション情報テーブルは、参照番号１３２２で示すように、各アプリケーションａｐｐ３、ａｐｐ４、ａｐｐ５、ａｐｐ６、ａｐｐ７の状態が順にｐｒ、ｐｒ、ｐｒ、ａｓ、ｐｒであることを、各アプリケーションのロケーション情報とともに示している。また、時刻ｔ３以降のアプリケーション実行期間では、アプリケーション情報テーブルは、参照番号１３２３で示すように、各アプリケーションａｐｐ３、ａｐｐ４、ａｐｐ５の状態が順にａｓ、ｐｒ、ｐｒであることを、各アプリケーションのロケーション情報とともに示している。

　参照番号１３０７～１３０９で示すデータ・ディレクトリー管理テーブル（ＤＤＭＴ）、データ・アセット管理テーブル（ＤＡＭＴ）、データ・コンテント管理テーブル（ＤＣＣＴ）は、アプリケーション・アセット１３０３、１３０４に含まれる各アプリケーションを放送で伝送する場合の伝送制御情報を指定するシグナリング・テーブルであり、ともにデータ伝送メッセージをコンテナーとして伝送される。

　参照番号１３１０で示すイベント・メッセージ・テーブル（ＥＭＴ）は、ｄａｔａ＿ｅｖｅｎｔ＿ｉｄとｅｖｅｎｔ＿ｍｓｇ＿ｇｒｏｕｐ＿ｉｄを含む、イベント・メッセージに関する情報を伝送する。ここで、ｄａｔａ＿ｅｖｅｎｔ＿ｉｄは、イベント・メッセージを利用する時間的に相隣り合うデータ・イベントを区別し、それらのデータ・イベントで伝送されるローカル・コンテンツ間でイベント・メッセージが誤配信されることを避けることを目的とした識別子である。送出時に隣り合うローカル・コンテンツ間では異なるｄａｔａ＿ｅｖｅｎｔ＿ｉｄが割り当てられる。また、ｅｖｅｎｔ＿ｍｓｇ＿ｇｒｏｕｐ＿ｉｄは、アプリケーションが受信すべきメッセージ群を識別する識別子である。

　アプリケーション情報テーブル１３０６は、各アプリケーションを起動する場合のロケーション情報を、伝送プロコル記述子によりＵＲＬ形式（パス名）で示す。放送で伝送されるアプリケーションの場合には、データ・ディレクトリー管理テーブル１３０７及びデータ・アセット管理テーブル１３０８を用いて、伝送プロトコル記述子で示すロケーション情報をＭＭＴ伝送路上の識別情報（パケット識別情報）に変換して（図１２を参照のこと）、アプリケーション・アセット１３０３又は１３０４の中から該当するアプリケーションのエンティティーであるファイル（ＨＴＭＬ文書）を取得する。

　ＭＭＴ方式では、データ・イベントは単にアプリケーションの伝送期間を示すだけであり、アプリケーション情報テーブルが示すアプリケーション実行期間とは一致しない。このため、受信機がＭＨ－ＡＩＴの指定に基づいてアプリケーションを起動する際や、アプリケーションから参照されるファイルにアクセスする際に、不適切な動作となるおそれがある。

　例えば、アプリケーションを起動する時点でデータ・イベントが切り替わっていると、伝送プロトコル記述子で示すロケーション情報がＭＭＴ伝送路上で見つからず、受信機はタイムアウトするまで待つことになってしまう。あるいは、伝送プロトコル記述子で示すロケーション情報にヒットする別のアプリケーションをＭＭＴ伝送路上で取得すると、受信機は誤動作してしまうこともあり得る。

　また、アプリケーション動作中にデータ・イベントが切り替わってしまうと、アプリケーションから参照されるファイルを取得しようとしても、ＭＭＴ伝送路上で見つからず、受信機はタイムアウトするまで待つことになってしまう。あるいは、誤って異なるファイルをＭＭＴ伝送路から取得して、受信機は誤ったアプリケーションの表示を行なうこともあり得る。

　そこで、本明細書では、受信機がアプリケーションを起動する際やアプリケーションから参照されるファイルにアクセスする際に、誤ったファイルを取得して不適切な動作とならないようにするための技術について、以下に説明する。

　本明細書で開示する技術では、送信側（放送送出システム１１）は、アプリケーションの実行を制御するアプリケーション制御情報に、アプリケーションが伝送されるデータ・イベントを一意に指定するデータ・イベント指定情報を付加して伝送するようにする。データ・イベントはアセット毎に定められるので、データ・イベント識別情報（ｄａｔａ＿ｅｖｅｎｔ＿ｉｄ）だけではアセット内でしかデータ・イベントを指定できない。そこで、アセットと一対一で対応するコンポーネント・タグと、アセット内でデータ・イベントを区別するデータ・イベント識別情報の組み合わせを、データ・イベント指定情報として用いるようにする。

　ここで、データ・アセット管理テーブル内では、各アセットのコンポーネント・タグとダウンロード識別情報が示されている。また、ダウンロード識別情報のビット２８～３１には、データ・イベント識別情報が符号化されている。したがって、コンポーネント・タグとデータ・イベント識別情報の組み合わせからなるデータ・イベント指定情報は、アプリケーションを伝送するデータ・イベントを指定可能な情報であると言うことができる。

　受信機側では、放送で伝送されるアプリケーションなどのデータ（ファイル）を取得する際には、データ伝送制御情報で指定されているコンポーネント・タグとデータ・イベント識別情報を、アプリケーション制御情報で指定されている値と比較して、マッチングがとれた場合のみ、データ伝送制御情報を通じて該当するファイルを取得するようにする。これによって、受信機は、誤ったファイルを取得して不適切な動作となるのを防ぐことができる。

　アプリケーション制御情報において、アプリケーションを伝送するアセット及びデータ・イベントを指定する方法として、以下の（１）及び（２）で示す２通りの方法を挙げることができる。

（１）ＭＨ－ＡＩＴのアプリケーション情報ループに配置される伝送プロトコル記述子に、データ・イベント指定情報を付与する。伝送プロトコル記述子は、アプリケーションのロケーション情報をＵＲＬで指定する記述子である（前述、並びに図８、図９を参照のこと）。伝送プロトコル記述子で、ＭＭＴ伝送される場合（すなわち、プロトコル識別情報が０ｘ０００５の場合）のＵＲＬ指定として、アセットの指定情報としてのコンポーネント・タグ（ｃｏｍｐｏｎｅｎｔ＿ｔａｇ）と、データ・イベントの指定情報としてのデータ・イベント識別情報（ｄａｔａ＿ｅｖｅｎｔ＿ｉｄ）を、例えばクエリー形式により付与する。

（２）ＭＨ－ＡＩＴのアプリケーション情報ループに、データ・イベント指定情報を参照するための伝送参照記述子を配置する。伝送参照記述子には、データ・イベント指定情報として、アプリケーションのコンポーネント・タグ及びダウンロード識別情報を記述する。ダウンロード識別情報の代わりにデータ・イベント識別情報を記述してもよいが、ダウンロード識別情報を用いれば、データ・アセット管理テーブルで指定される値と直接マッチングをとることができる。

　伝送プロトコル記述子は、ＭＭＴ伝送されるアプリケーション・データのロケーション情報を、図９に示したシンタックス９００からなるセレクター・バイトで指定する。図１４には、上記（１）の方法に従って、ロケーション情報をＵＲＬ指定するセレクター・バイトに、放送で伝送されるアプリケーションのコンポーネント・タグ及びデータ・イベント識別情報をクエリーとして付与する例を示している。図示のように、ＵＲＬ＿ｂａｓｅ＿ｂｙｔｅのループからなるＵＲＬのベース部＜ＡＩＴ＿ＴＰｄｅｓｃ＿ＵＲＬＢａｓｅ＞として、データ・ディレクトリー管理テーブルで示すベース・ディレクトリー名＜ＤＤＭＴ＿ＢａｓｅＤｉｒｅｃｔｏｒｙ＞が指定される。また、ＵＲＬ＿ｅｘｔｅｎｓｉｏｎのループからなるＵＲＬの拡張部＜ＡＩＴ＿ＴＰｄｅｓｃ＿ＵＲＬＥｘｔｅｎｓｉｏｎ＞として、データ・ディレクトリー管理テーブルで示すディレクトリー名（ＤＤＭＴ＿ｄｉｒｅｃｔｏｒｙ＿ｎｏｄｅ＿ｐａｔｈ）とファイル名（ＤＤＭＴ＿ｆｉｌｅ＿ｎａｍｅ）からなる文字列情報の後方に、コンポーネント・タグ及びデータ・イベント識別情報のクエリー（？ｃｏｍｐｏｎｅｎｔ＿ｔａｇ＝＜ｃｏｍｐｏｎｅｎｔ＿ｔａｇ＞＆ｄａｔａ＿ｅｖｅｎｔ＿ｉｄ＝＜ｄａｔａ＿ｅｖｅｎｔ＿ｉｄ＞）が付与されている。

　また、図１５には、上記（２）の方法に従って、ＭＨ－ＡＩＴのアプリケーション情報ループに配置される伝送参照記述子のシンタックス例１５００を示している。伝送参照記述子の各パラメーターについて説明しておく。ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇは、当該記述子１５００を識別する、８ビットの固定値を示す。ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈは、このフィールドより後に続く当該記述子のデータのバイト長を書き込む、８ビットの領域である。ｃｏｍｐｏｎｅｎｔ＿ｔａｇフィールドには、対象とするアプリケーションを伝送するアセットを指定するコンポーネント・タグが記載される。また、ｄｏｗｎｌｏａｄ＿ｉｄフィールドには、データ・コンテンツを一意に識別するダウンロード情報が記載される。

　データ・ディレクトリー管理テーブル及びデータ・アセット管理テーブルは、ＭＭＴ方式の放送によりアプリケーションを伝送する際の伝送制御情報を示している。このうち、データ・ディレクトリー管理テーブルは、アプリケーション・データのパス名とノード・タグの対応関係を示す。パス名は、ベース・ディレクトリー名（ＤＤＭＴ＿ＢａｓｅＤｉｒｅｃｔｏｒｙ）と、ディレクトリー名（ＤＤＭＴ＿ｄｉｒｅｃｔｏｒｙ＿ｎｏｄｅ＿ｐａｔｈ）とファイル名（ＤＤＭＴ＿ｆｉｌｅ＿ｎａｍｅ）の文字列の連結からなる（図１０を参照のこと）。また、データ・アセット管理テーブルは、ノード・タグと、ノード（アプリケーションなどのデータ）が属するコンポーネント（すなわち、アセット）を識別するコンポーネント・タグ及びコンポーネントのダウンロード識別情報との対応関係を示している（図１１を参照のこと）。ここで、データ・イベントの運用を行なう場合には、３２ビット長のダウンロード識別情報のビット２８～３１にはデータ・イベント識別情報が符号化されている（前述）。したがって、データ・アセット管理テーブルは、ノード・タグとコンポーネント・タグ及びデータ・イベント識別情報の対応関係を示している。要するに、データ・ディレクトリー管理テーブル及びデータ・アセット管理テーブルからなるデータ伝送制御情報は、アプリケーション・データのパス名と、コンポーネント・タグ及びデータ・イベント識別情報の対応関係を示していることになる。

　したがって、上記の方法（１）並びに（２）により、ＭＨ－ＡＩＴに配置する伝送プロトコル記述子又は伝送参照記述子でアプリケーション・データのコンポーネント・タグとデータ・イベント識別情報を示すようにすれば、受信機側では、放送で伝送されるアプリケーション・データを取得する際に、データ伝送制御情報において、対象とするアプリケーション・データに対して指定されるコンポーネント・タグ及びデータ・イベント識別情報とのマッチングをとることで、誤ったファイルを取得しないようにして、不適切な動作を防ぐことができる。

　データ・イベントをチェックしながらＭＭＴ伝送されるアプリケーション・データを取得する仕組みについて、図１６を参照しながら説明する。

　Ｍ２セクション・メッセージで伝送されるＭＨ－ＡＩＴのアプリケーション情報ループに配置されている伝送プロトコル記述子（ＴＰＤ）は、各アプリケーションを取得するためのパス名をＵＲＬ形式で示す。また、ＭＨ－ＡＩＴのアプリケーション情報ループに配置されている伝送プロトコル記述子（又は、伝送参照記述子（ＴＲＤ））は、アプリケーションを伝送するアセットを指定する情報としてコンポーネント・タグを示すとともに、データ・イベントの指定情報としてデータ・イベント識別情報を示す。

　受信機は、起動が指示されたアプリケーションのパス名を伝送プロトコル記述子から取得することができる。そして、放送で伝送されるアプリケーションの場合には、参照番号１６０１で示すように、データ伝送メッセージ内のデータ・ディレクトリー管理テーブルから、指定されたパス名に対応するファイルのノード・タグを得ることができる。

　次いで、参照番号１６０２で示すように、同じくデータ伝送メッセージ内のデータ・アセット管理テーブルから、データ・ディレクトリー管理テーブルで得られたノード・タグを持つアイテムが伝送されるデータ・アセットのコンポーネント・タグ、ダウンロード識別情報、ＭＰＵシーケンス番号、及びアイテム識別情報を得ることができる。

　ここで、参照番号１６０３で示すように、受信機は、対象とするアプリケーションに対してデータ伝送メッセージで指定されるコンポーネント・タグをＭＨ－ＡＩＴ内の伝送プロトコル記述子又は伝送参照記述子で指定される値と比較する。

　また、データ・イベントの運用を行なう場合には、３２ビット長のダウンロード識別情報のビット２８～３１にデータ・イベント識別情報が符号化されている。そこで、参照番号１６０４で示すように、受信機は、対象とするアプリケーションに対してデータ伝送メッセージで指定されるダウンロード識別情報のビット２８～３１から復号されるデータ・イベント識別情報をＭＨ－ＡＩＴ内の伝送プロトコル記述子で指定される値と比較する。あるいは、受信機は、対象とするアプリケーションに対してデータ伝送メッセージで指定されるダウンロード識別情報そのものを、ＭＨ－ＡＩＴ内の伝送参照記述子で指定される値と比較する。

　コンポーネント・タグ及びデータ・イベント識別情報（若しくは、ダウンロード識別情報）のマッチングがとれない場合、データ・イベントが切り替わっていると判定することができる。したがって、受信機は、アプリケーション・データの取得を行なわず、アプリケーションの動作を回避するようにすればよい。

　一方、コンポーネント・タグ及びデータ・イベント識別情報のマッチングがとれた場合には、受信機は、参照番号１６０５で示すように、データ・アセット管理テーブルで得られたコンポーネント・タグを持つアセットのロケーション情報をＭＰテーブルから取得し、該当するデータ・アセットを特定する。そして、受信機は、参照番号１６０６で示すように、特定されたデータ・アセット内で、データ・アセット管理テーブルから得られたＭＰＵシーケンス番号及びアイテム識別情報を持つアイテムを所望のファイルとして取得して、アプリケーションを起動する。

　図１７には、アプリケーションを伝送するアセット及びデータ・イベントをＭＨ－ＡＩＴで指定する方法を適用した場合における、アプリケーション実行のシナリオを例示している。同図では、簡素化のため、ある放送事業者（放送局）から送信される放送信号のうち、参照番号１７０１～１７０３で示す、Ｍ２セクション・メッセージ、データ伝送メッセージ、及びデータ・アセットのみを描いている。

　また、図１７の横軸を時間軸とする。データ・アセット１７０３は、時刻ｔ１１でデータ・イベントが切り替わる。時刻ｔ１１以前のデータ・イベントでは、ローカル・コンテンツａｐｐ１、ａｐｐ２、ａｐｐ３が伝送され、時刻ｔ１１以降のデータ・イベントでは、ローカル・コンテンツａｐｐ４、ａｐｐ２、ａｐｐ３が伝送される。また、時刻ｔ１１以前のデータ・イベントで伝送されるローカル・コンテンツにはデータ・イベント識別情報として「Ａ」が割り当てられ、時刻ｔ１１以降のデータ・イベントで伝送されるローカル・コンテンツにはデータ・イベント識別情報として「Ｂ」が割り当てられ（但し、Ａ≠Ｂとする）、時間的に隣り合うデータ・イベントが区別されている。

　時刻ｔ１１以前のデータ・イベントに対しては、参照番号１７２１で示すように、ローカル・コンテンツａｐｐ１、ａｐｐ２、ａｐｐ３に関するデータ伝送制御情報（データ・ディレクトリー管理テーブル及びデータ・アセット管理テーブル）を格納するデータ伝送メッセージが伝送される。また、時刻ｔ１１以降のデータ・イベントに対しては、参照番号１７２２で示すように、ローカル・コンテンツａｐｐ４、ａｐｐ２、ａｐｐ３に関するデータ伝送制御情報を格納するデータ伝送メッセージが伝送される。

　データ伝送メッセージ１７０２は、データ・アセット１７０３とは別の設備で生成され伝送されることから、データ・ディレクトリー管理テーブル及びデータ・アセット管理テーブルが切り替わるタイミングがデータ・イベントの切り替わりから多少ずれることも想定されるが、ほぼ一致しているものとする。

　Ｍ２セクション・メッセージ１７０１は、アプリケーションの実行制御を行なうＭＨ－ＡＩＴを伝送する。図１７に示す例では、時刻ｔ１２以前の期間には、参照番号１７１１で示すように、ローカル・コンテンツａｐｐ１、ａｐｐ２、ａｐｐ３の実行制御を行なうＭＨ－ＡＩＴが伝送される。また、時刻ｔ１２以降の期間には、参照番号１７１２で示すように、ローカル・コンテンツａｐｐ４、ａｐｐ２、ａｐｐ３の実行制御を行なうＭＨ－ＡＩＴが伝送される。

　既に述べたように、ＭＭＴ方式では、アプリケーションの伝送期間で直接アプリケーションの制御を行なわず、ＭＨ－ＡＩＴだけで実行制御を行なう仕組みとなっており、データ・イベントは、単にアプリケーションの伝送期間を示すことになる。図１７に示す例では、データ・イベントが切り替わる時刻ｔ１１よりも遅れた時刻ｔ１２で、Ｍ２セクション・メッセージから伝送されるＭＨ－ＡＩＴが切り替わるものとする。このような場合、受信機側では、ＭＨ－ＡＩＴで自動起動（ａｕｔｏｓｔａｒｔ）に指定されたアプリケーションを起動しようとする際、既にデータ・イベントが切り替わっているため、アプリケーションを取得できない、あるいは別のアプリケーションを取得して誤動作してしまうおそれがある。

　本明細書で開示する技術では、アプリケーションの実行制御を行なうＭＨ－ＡＩＴにおいて、伝送プロトコル記述子又は伝送参照記述子を用いて、アプリケーションを伝送するアセット及びデータ・イベントの各々を指定する情報を示すようにしている。したがって、受信機側では、放送（すなわち、データ・アセット１７０３）で伝送するアプリケーションなどのファイルにアクセスする際には、データ伝送メッセージが伝送するデータ伝送制御情報１７２１、１７２２で指定されるアセット（コンポーネント・タグ）及びデータ・イベント識別情報を、ＭＨ－ＡＩＴで指定する値と突き合わせて、マッチングがとれた場合のみファイルを取得するようにして、誤動作を防止することができる。

　ここで、データ・イベントが切り替わる時刻ｔ１１よりも早い時刻ｔ２１に、自動起動が指定されたアプリケーションａｐｐ１を受信機側で起動する場合について考察してみる。

　まず、受信機は、参照番号１７３１で示すように、ＭＨ－ＡＩＴ内の伝送プロトコル記述子が指定するアプリケーションａｐｐ１のロケーション情報を、データ伝送制御情報１７２１を用いて、データ・アセット１７０３上でａｐｐ１を識別する情報に変換した後、参照番号１７３２で示すように、ａｐｐ１のファイルの取得を試みる。

　ここで、受信機は、ファイルへのアクセスを行なう際に、対象とするアプリケーションに対してデータ伝送制御情報１７２１で指定されるコンポーネント・タグをＭＨ－ＡＩＴ内の伝送プロトコル記述子又は伝送参照記述子で指定される値と比較する。

　また、受信機は、対象とするアプリケーションに対してデータ伝送制御情報１７２１で指定されるデータ・イベント識別情報を、伝送プロトコル記述子で指定される値と比較する。あるいは、受信機は、対象とするアプリケーションに対してデータ伝送メッセージで指定されるダウンロード識別情報を、伝送参照記述子で指定される値と比較する。

　時刻ｔ１１よりも早い時刻ｔ２１では、コンポーネント・タグとデータ・イベント識別情報（若しくはダウンロード識別情報）は、ともに一致する。したがって、受信機は、アプリケーションａｐｐ１のファイルを成功裏に取得し、起動することができる。

　続いて、データ・イベントが切り替わる時刻ｔ１１を経過した時刻ｔ２２に、受信機側で、自動起動が指定されたアプリケーションａｐｐ１を起動する場合について考察してみる。ＭＭＴ方式では、データ伝送期間がアプリケーションの実行時間と一致するとは限らないので、このような事態は想定し得る。

　まず、受信機は、参照番号１７３３で示すように、ＭＨ－ＡＩＴ内の伝送プロトコル記述子が指定するアプリケーションａｐｐ１のロケーション情報を、データ伝送制御情報１７２２を用いて、データ・アセット１７０３上でａｐｐ１を識別する情報への変換を試みる。伝送プロトコル記述子が指定するアプリケーションａｐｐ１のロケーション情報がデータ伝送制御情報１７２２内に存在しなければ、受信機は、ファイルを取得することができず、アプリケーションａｐｐ１を起動することはない。ここでは、別のアプリケーション（例えばａｐｐ４）が、直前のデータ・イベントにおけるａｐｐ１と同じロケーション情報（ｒｏｏｔ／ｒｅｎｄｏｕ／ｄｅｆａｕｌｔ．ｈｔｍｌ）で指定されていることを想定する。このような場合には、参照番号１７３４で示すように、データ・アセット１７０３上でａｐｐ４を識別する情報にすりかわるおそれがある。

　受信機は、ファイルへのアクセスを行なう際に、対象とするアプリケーションに対してデータ伝送メッセージで指定されるコンポーネント・タグをＭＨ－ＡＩＴ内の伝送プロトコル記述子又は伝送参照記述子で指定される値と比較する（同上）。図１７に示す例では、ａｐｐ１にすり替わったａｐｐ４も同じデータ・アセット１７０３上で伝送されるので、コンポーネント・タグのマッチングがとれる。

　さらに、受信機は、対象とするアプリケーションに対してデータ伝送メッセージで指定されるデータ・イベント識別情報を、伝送プロトコル記述子で指定される値と比較する。あるいは、受信機は、対象とするアプリケーションに対してデータ伝送メッセージで指定されるダウンロード識別情報を、伝送参照記述子で指定される値と比較する（同上）。

　時刻ｔ１１を経過した時刻ｔ２１では、データ・アセット１７０３のデータ・イベント識別情報は「Ａ」から「Ｂ」に切り替わっている。このため、伝送プロトコル記述子がａｐｐ１に対して指定するデータ・イベント識別情報「Ａ」は、時刻ｔ２１以降のデータ・イベント識別情報「Ｂ」と一致しない。したがって、受信機は、データ・イベント識別情報のマッチングがとれないことから、データ・イベントが既に切り替わっていることを検知することができる。このような場合、受信機は、アプリケーション・データの取得を行なわず、想定外のアプリケーションａｐｐ４の表示を回避することができる。

　他方、ＭＨ－ＡＩＴ内でアプリケーションを伝送するアセット及びデータ・イベントの各指定情報を示さない場合には、ＭＨ－ＡＩＴで起動を指示するアプリケーションのファイルにアクセスする際に、受信機は、上記のようなマッチングによりデータ・イベントの切り替わりを検知することができないので、放送伝送のファイルが想定外のファイルにすりかわって、誤動作を起こす可能性がある。

　図１８～図２０には、受信機において、データ・イベントのチェックを伴うアプリケーションの実行制御を行なうための処理手順をフローチャートの形式で示している。この処理手順は、図４に示した受信機１２において実行されるものと理解されたい。

　まず、受信機１２は、ＰＡメッセージを取得する（ステップＳ１８０１）。ＰＡメッセージは、放送サービスのエントリー・ポイントであり、固定のパケット識別情報（例えば、０ｘ００００）が割り当てられたＭＭＴＰパケットで伝送される。ＰＡパケットに格納されるＭＰテーブルは、放送サービスに関連する各アセット（映像、音声、字幕、データ放送アプリケーションなど）や他のシグナリング・メッセージを間接的に指定している（図６を参照のこと）。したがって、受信機１２では、ＭＰテーブルに基づいて、放送サービスを構成する映像及び音声のアセットを取得して、これらの再生を開始することができる。

　次いで、受信機１２内の放送システム制御部４１０は、上記のＭＰテーブルにアプリケーション・サービス記述子が存在する場合には、ＡＩＴ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏで指定されたパケット識別情報に基づいてＭＨ－ＡＩＴを受信並びに取得すると、自動起動（ａｕｔｏｓｔａｒｔ）に指定されているアプリケーションを割り出す（ステップＳ１８０２）。

　次いで、放送システム制御部４１０は、ＭＨ－ＡＩＴで指定されたアプリケーションに関わる伝送プロトコル記述子又は伝送参照記述子から、アプリケーションのロケーション情報を指定するＵＲＬと、当該アプリケーションを伝送するアセット及びデータ・イベントをそれぞれ指定するコンポーネント・タグ（ｃｏｍｐｏｎｅｎｔ＿ｔａｇ）及びデータ・イベント識別情報（ｄａｔａ＿ｅｖｅｎｔ＿ｉｄ）を抽出する（ステップＳ１８０３）。

　次いで、放送システム制御部４１０は、データ伝送メッセージで伝送されるデータ・ディレクトリー管理テーブル（ＤＤＭＴ）及びデータ・アセット管理テーブル（ＤＡＭＴ）を受信及び取得する。そして、受信機は、先行ステップＳ１８０３で抽出したアプリケーションのＵＲＬに対応するノード・タグをデータ・ディレクトリー管理テーブルにより抽出すると、さらにデータ・アセット管理テーブルによりこのノード・タグに対応するファイルを伝送するアセット識別情報とＭＰＵシーケンス番号を特定する（ステップＳ１８０４）。

　データ・アセット管理テーブルから割り出したアセット識別情報をＭＰテーブルで引くことで、コンポーネント・タグを割り出すことができる。また、データ・アセット管理テーブルで示されるダウンロード識別情報のビット２８～３１から、符号化されたデータ・イベント識別情報を抽出することができる。そして、放送システム制御部４１０は、取得すべきアプリケーションのファイルを伝送するコンポーネント・タグ及びデータ・イベント識別情報と、先行ステップＳ１８０３でＭＨ－ＡＩＴの伝送プロトコル記述子又は伝送参照記述子から抽出したコンポーネント・タグ及びデータ・イベントとが同値であるか否かをチェックする（ステップＳ１８０５）。

　データ・アセット管理テーブルで示されるコンポーネント・タグ及びデータ・イベントがＭＨ－ＡＩＴから抽出した各値と同値でない場合には（ステップＳ１８０５のＮｏ）、受信機１２では、本処理ルーチンを終了する。すなわち、データ・イベントが切り替わったことが検知されるので、受信機１２は、アプリケーションを起動しないことにより、誤動作を防止することができる。

　一方、データ・アセット管理テーブルで示されるコンポーネント・タグ及びデータ・イベントがＭＨ－ＡＩＴから抽出した各値と同値である場合には（ステップＳ１８０５のＹｅｓ）、データ・イベントがまだ切り替わっていないことが分かる。したがって、受信機１２は、先行ステップＳ１８０４で特定したアセット識別情報に対応するデータ・アセットを受信し、同じく特定したＭＰＵシーケンス番号に該当するＭＰＵを受信及び取得する。そして、放送システム制御部４１０は、先行ステップＳ１８０４で特定したノード・タグに対応するアプリケーション・ファイルを起動させる（ステップＳ１８０６）。

　アプリケーション実行中に、アプリケーション（ＨＴＭＬ５文書）の記述により参照したファイルにアクセスする場合には（ステップＳ１８０７のＹｅｓ）、ステップＳ１８０８に進んで、受信機１２は、データ伝送メッセージで伝送されるデータ・ディレクトリー管理テーブル（ＤＤＭＴ）及びデータ・アセット管理テーブル（ＤＡＭＴ）を受信及び取得する。そして、放送システム制御部４１０は、上記の参照ファイルのＵＲＬに対応するノード・タグをデータ・ディレクトリー管理テーブルにより抽出すると、さらにデータ・アセット管理テーブルによりこのノード・タグに対応するファイルを伝送するアセット識別情報とＭＰＵシーケンス番号を特定する。

　次いで、放送システム制御部４１０は、データ・アセット管理テーブルで示される、上記の参照ファイルを伝送するコンポーネント・タグ及びデータ・イベント識別情報と、先行ステップＳ１８０３でＭＨ－ＡＩＴから抽出したコンポーネント・タグ及びデータ・イベントが同値であるか否かをチェックする（ステップＳ１８０９）。

　上記の参照ファイルについて特定したコンポーネント・タグ及びデータ・イベント識別情報がＭＨ－ＡＩＴから抽出した各値と同値でない場合には（ステップＳ１８０９のＮｏ）、放送システム制御部４１０は、データ・イベントの切り替わりなどのために、適切なファイルを取得できなかったと認識して、エラー表示を行なわせる（ステップＳ１８１１）。そして、受信機１２は、ステップＳ１８０７に戻って、アプリケーション実行を継続する。

　また、上記の参照ファイルについて特定したコンポーネント・タグ及びデータ・イベント識別情報がＭＨ－ＡＩＴから抽出した各値と同値である場合には（ステップＳ１８０９のＹｅｓ）、受信機１２は、先行ステップＳ１８０８で特定したアセット識別情報に対応するデータ・アセットを受信し、同じく特定したＭＰＵシーケンス番号に該当するＭＰＵを受信及び取得する。そして、先行ステップＳ１８０８で特定したノード・タグに対応するファイルをブラウザー（アプリケーション・エンジン４１１）で処理する（ステップＳ１８１０）。例えば、画像ファイルの場合には、ブラウザーはこれを再生表示する。そして、受信機１２は、ステップＳ１８０７に戻って、アプリケーション実行を継続する。

　また、アプリケーション実行中に、アプリケーション遷移のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ　Ｐｒｏｇｒａｍｍｉｎｇ　Ｉｎｔｅｒｆａｃｅ）がコールされた場合には（ステップＳ１８１２のＹｅｓ）、次ステップＳ１８１３に進む。そうでない場合には（ステップＳ１８１２のＮｏ）、受信機１２は、ステップＳ１８０７に戻って、アプリケーション実行を継続する。

　ステップＳ１８１３では、受信機１２は、その時点でのＭＨ－ＡＩＴをＭ２セクション・メッセージから取得する。ここで、先行ステップＳ１８０２で取得したＭＨ－ＡＩＴと変化がない場合には、これを用いてもよい。

　そして、放送システム制御部４１０は、先行ステップＳ１８１２で指定されたアプリケーションが、その時点のＭＨ－ＡＩＴにおいて、ＡＵＴＯＳＴＡＲＴ又はＰＲＥＳＥＮＴを指定されたアプリケーションとして記述されているか否かをチェックする（ステップＳ１８１４）。

　当該アプリケーションがその時点のＭＨ－ＡＩＴで記述されていない場合には（ステップＳ１８１４のＮｏ）、放送システム制御部４１０は、遷移先のアプリケーションが有効でないとみなして、ステップＳ１８０７に戻って、アプリケーション実行を継続させる。

　また、当該アプリケーションがその時点のＭＨ－ＡＩＴで記述されている場合には（ステップＳ１８１４のＹｅｓ）、放送システム制御部４１０は、遷移先のアプリケーションが有効であるとみなして、その時点で動作するアプリケーションを終了させた後（ステップＳ１８１５）、ステップＳ１８０３に戻り、受信機１２は、遷移先のアプリケーションについて上記と同様の処理を実施する。

　以上、特定の実施形態を参照しながら、本明細書で開示する技術について詳細に説明してきた。しかしながら、本明細書で開示する技術の要旨を逸脱しない範囲で当業者が該実施形態の修正や代用を成し得ることは自明である。

　本明細書では、メディア伝送にＭＭＴ方式を採用した放送システムに本明細書で開示する技術を適用した実施形態を中心に説明してきたが、本明細書で開示する技術の要旨はこれに限定されるものではない。アプリケーションの伝送期間で直接アプリケーションの制御を行なわず、ＡＩＴのようなアプリケーション制御に関するシグナリング情報だけで実行制御を行なう仕組みを採用するさまざまなタイプのデータ放送システムに対して、同様に本明細書で開示する技術を適用することができる。

　要するに、例示という形態により本明細書で開示する技術について説明してきたのであり、本明細書の記載内容を限定的に解釈するべきではない。本明細書で開示する技術の要旨を判断するためには、特許請求の範囲を参酌すべきである。

　なお、本明細書の開示の技術は、以下のような構成をとることも可能である。
（１）アプリケーション制御情報に、アプリケーションを伝送するデータ・イベントを指定するデータ・イベント指定情報を付与する処理部と、
　前記データ・イベント指定情報を付与した前記アプリケーション制御情報を送信する送信部と、
を具備する送信装置。
（２）所定のトランスポート方式によりデータ・イベント毎に伝送されるアプリケーションの伝送制御情報を送信する第２の送信部をさらに備える、
上記（１）に記載の送信装置。
（３）アプリケーションのデータからなるアセットを前記所定のトランスポート方式を用いて伝送する第３の送信部をさらに備え、
　前記第２の送信部は、各アセットで伝送されるデータの伝送制御情報を送信する、
上記（２）に記載の送信装置。
（４）前記処理部は、アプリケーションを伝送するアセット及びデータ・イベントの組み合わせを一意に指定する前記データ・イベント指定情報を前記アプリケーション制御情報に付与する、
上記（１）乃至（３）のいずれかに記載の送信装置。
（５）前記処理部は、前記アプリケーション制御情報に配置される、アプリケーションのロケーション情報を指定する第１の記述子に、前記データ・イベント指定情報を付与する、
上記（１）乃至（４）のいずれかに記載の送信装置。
（６）前記処理部は、前記第１の記述子がアプリケーションのロケーション情報を指定するＵＲＬに前記データ・イベント指定情報をクエリーとして付与する、
上記（５）に記載の送信装置。
（７）前記処理部は、アプリケーションを伝送するアセットと一意に対応するコンポーネント識別情報と、アプリケーションのデータと一意に対応するダウンロード識別情報からなる前記データ・イベント指定情報とを記載する第２の記述子を前記アプリケーション制御情報に配置する、
上記（１）乃至（４）のいずれかに記載の送信装置。
（８）前記処理部は、アプリケーションを伝送するデータ・イベントのデータ・イベント識別情報を前記ダウンロード識別情報の所定領域に符号化する、
上記（７）に記載の送信装置。
（９）アプリケーション制御情報に、アプリケーションを伝送するデータ・イベントを指定するデータ・イベント指定情報を付与する付与ステップと、
　前記データ・イベント指定情報を付与した前記アプリケーション制御情報を送信する送信ステップと、
を有する送信方法。
（１０）所定のトランスポート方式によりデータ・イベント毎に伝送されるアプリケーションのアセットを受信する第１の受信部と、
　アプリケーションの伝送制御情報を受信する第２の受信部と、
　アプリケーションが伝送されるデータ・イベントを指定するデータ・イベント指定情報報が付与されたアプリケーション制御情報を受信する第３の受信部と、
　前記アプリケーション制御情報に基づいてアプリケーションの処理を制御する制御部と、
を具備する受信装置。
（１１）前記第３の受信部は、アプリケーションを伝送するアセット及びデータ・イベントの組み合わせを一意に指定する前記データ・イベント指定情報が付与された前記アプリケーション制御情報を受信する、
上記（１０）に記載の受信装置。
（１２）前記第３の受信部は、アプリケーションのロケーション情報を指定するとともに前記データ・イベント指定情報が付与された第１の記述子が配置された前記アプリケーション制御情報を受信する、
上記（１０）又は（１１）のいずれかに記載の受信装置。
（１３）前記第３の受信部は、アプリケーションのロケーション情報を指定するＵＲＬに前記データ・イベント指定情報がクエリーとして付与された前記第１の記述子が配置された前記アプリケーション制御情報を受信する、
上記（１２）に記載の受信装置。
（１４）前記第３の受信部は、アプリケーションが伝送されるアセットと一意に対応するコンポーネント識別情報と、アプリケーションのデータと一意に対応するダウンロード識別情報からなる前記データ・イベント指定情報とを記載する第２の記述子が配置された前記アプリケーション制御情報を受信する、
上記（１０）又は（１１）のいずれかに記載の受信装置。
（１５）前記第３の受信部は、アプリケーションを伝送するデータ・イベントのデータ・イベント識別情報が所定領域に符号化された前記ダウンロード識別情報を記載する前記第２の記述子を受信する、
上記（１４）に記載の受信装置。
（１６）前記制御部は、前記アプリケーション制御情報に付与されるデータ・イベント指定情報に基づいて、前記所定のトランスポート方式で伝送されるアプリケーションへのアクセスを制御する、
上記（１０）乃至（１５）のいずれかに記載の受信装置。
（１７）前記制御部は、前記所定のトランスポート方式で伝送されるアプリケーションにアクセスする際に、前記伝送制御情報によりアプリケーションに指定されるアセット及びデータ・イベント識別情報と前記アプリケーション制御情報でアプリケーションに付与された前記データ・イベント指定情報を比較した結果に基づいて、アプリケーションへのアクセスを制御する、
上記（１０）乃至（１６）のいずれかに記載の受信装置。
（１８）所定のトランスポート方式によりデータ・イベント毎に伝送されるアプリケーションのアセットを受信する第１の受信ステップと、
　アプリケーションの伝送制御情報を受信する第２の受信ステップと、
　アプリケーションが伝送されるデータ・イベントを指定するデータ・イベント指定情報報が付与されたアプリケーション制御情報を受信する第３の受信ステップと、
　前記アプリケーション制御情報に基づいてアプリケーションの処理を制御する制御ステップと、
を有する受信方法。

　１０…ディジタル放送システム
　１１…放送送出システム、１２…受信機
　３０１…時計部、３０２…信号送出部
　３０３…ビデオ・エンコーダー
　３０４…オーディオ・エンコーダー
　３０５…字幕／文字スーパー・エンコーダー
　３０６…シグナリング・エンコーダー
　３０７…ファイル・エンコーダー
　３０８…電子データ処理システム
　３０９…ＴＬＶシグナリング・エンコーダー
　３１０…ＩＰサービス・マルチプレクサー
　３１１…ＴＬＶマルチプレクサー、３１２…変調・送信部
　４０１…チューナー復調部、４０２…ＭＭＴデマルチプレクサー
　４０３…時計回復部、４０４…ビデオ・デコーダー
　４０５…オーディオ・デコーダー
　４０６…文字スーパー・デコーダー、４０７…字幕デコーダー
　４０８…マルチメディア・キャッシュ、４０９…ＳＩキャッシュ
　４１０…放送システム制御部
　４１１…アプリケーション・エンジン
　４１２…通信インターフェース、４１４…スケーラー
　４１５～４１８…合成部

Claims

　アプリケーション制御情報に、アプリケーションを伝送するデータ・イベントを指定するデータ・イベント指定情報を付与する処理部と、
　前記データ・イベント指定情報を付与した前記アプリケーション制御情報を送信する送信部と、
を具備する送信装置。
　所定のトランスポート方式によりデータ・イベント毎に伝送されるアプリケーションの伝送制御情報を送信する第２の送信部をさらに備える、
請求項１に記載の送信装置。
　アプリケーションのデータからなるアセットを前記所定のトランスポート方式を用いて伝送する第３の送信部をさらに備え、
　前記第２の送信部は、各アセットで伝送されるデータの伝送制御情報を送信する、
請求項２に記載の送信装置。
　前記処理部は、アプリケーションを伝送するアセット及びデータ・イベントの組み合わせを一意に指定する前記データ・イベント指定情報を前記アプリケーション制御情報に付与する、
請求項１に記載の送信装置。
　前記処理部は、前記アプリケーション制御情報に配置される、アプリケーションのロケーション情報を指定する第１の記述子に、前記データ・イベント指定情報を付与する、
請求項１に記載の送信装置。
　前記処理部は、前記第１の記述子がアプリケーションのロケーション情報を指定するＵＲＬに前記データ・イベント指定情報をクエリーとして付与する、
請求項５に記載の送信装置。
　前記処理部は、アプリケーションを伝送するアセットと一意に対応するコンポーネント識別情報と、アプリケーションのデータと一意に対応するダウンロード識別情報からなる前記データ・イベント指定情報とを記載する第２の記述子を前記アプリケーション制御情報に配置する、
請求項１に記載の送信装置。
　前記処理部は、アプリケーションを伝送するデータ・イベントのデータ・イベント識別情報を前記ダウンロード識別情報の所定領域に符号化する、
請求項７に記載の送信装置。
　アプリケーション制御情報に、アプリケーションを伝送するデータ・イベントを指定するデータ・イベント指定情報を付与する付与ステップと、
　前記データ・イベント指定情報を付与した前記アプリケーション制御情報を送信する送信ステップと、
を有する送信方法。
　所定のトランスポート方式によりデータ・イベント毎に伝送されるアプリケーションのアセットを受信する第１の受信部と、
　アプリケーションの伝送制御情報を受信する第２の受信部と、
　アプリケーションが伝送されるデータ・イベントを指定するデータ・イベント指定情報報が付与されたアプリケーション制御情報を受信する第３の受信部と、
　前記アプリケーション制御情報に基づいてアプリケーションの処理を制御する制御部と、
を具備する受信装置。
　前記第３の受信部は、アプリケーションを伝送するアセット及びデータ・イベントの組み合わせを一意に指定する前記データ・イベント指定情報が付与された前記アプリケーション制御情報を受信する、
請求項１０に記載の受信装置。
　前記第３の受信部は、アプリケーションのロケーション情報を指定するとともに前記データ・イベント指定情報が付与された第１の記述子が配置された前記アプリケーション制御情報を受信する、
請求項１０に記載の受信装置。
　前記第３の受信部は、アプリケーションのロケーション情報を指定するＵＲＬに前記データ・イベント指定情報がクエリーとして付与された前記第１の記述子が配置された前記アプリケーション制御情報を受信する、
請求項１２に記載の受信装置。
　前記第３の受信部は、アプリケーションが伝送されるアセットと一意に対応するコンポーネント識別情報と、アプリケーションのデータと一意に対応するダウンロード識別情報からなる前記データ・イベント指定情報とを記載する第２の記述子が配置された前記アプリケーション制御情報を受信する、
請求項１０に記載の受信装置。
　前記第３の受信部は、アプリケーションを伝送するデータ・イベントのデータ・イベント識別情報が所定領域に符号化された前記ダウンロード識別情報を記載する前記第２の記述子を受信する、
請求項１４に記載の受信装置。
　前記制御部は、前記アプリケーション制御情報に付与されるデータ・イベント指定情報に基づいて、前記所定のトランスポート方式で伝送されるアプリケーションへのアクセスを制御する、
請求項１０に記載の受信装置。
　前記制御部は、前記所定のトランスポート方式で伝送されるアプリケーションにアクセスする際に、前記伝送制御情報によりアプリケーションに指定されるアセット及びデータ・イベント識別情報と前記アプリケーション制御情報でアプリケーションに付与された前記データ・イベント指定情報を比較した結果に基づいて、アプリケーションへのアクセスを制御する、
請求項１０に記載の受信装置。
　所定のトランスポート方式によりデータ・イベント毎に伝送されるアプリケーションのアセットを受信する第１の受信ステップと、
　アプリケーションの伝送制御情報を受信する第２の受信ステップと、
　アプリケーションが伝送されるデータ・イベントを指定するデータ・イベント指定情報報が付与されたアプリケーション制御情報を受信する第３の受信ステップと、
　前記アプリケーション制御情報に基づいてアプリケーションの処理を制御する制御ステップと、
を有する受信方法。