JP5725235B1 - 受信装置及び受信方法、並びに、送信装置及び送信方法 - Google Patents

Abstract

【課題】ＭＭＴ（ＭＰＥＧ Ｍｅｄｉａ Ｔｒａｎｓｐｏｒｔ）方式でファイルを受信する受信装置及び受信方法を提供する。【解決手段】送信側からは、アプリケーションを構成するリソースを、アプリケーションにおいてロケーションを示すＵＲＬを放送などのＭＭＴ伝送路上のロケーションにマッピングする情報、アプリケーションにおける表示単位とリンク関係を示す情報を伝送する。受信機側では、データ放送アプリケーションを実行する際の階層的なファイル・データへのアクセス範囲と、各アクセス範囲におけるファイル・データのロケーション情報及びサイズを取得して、アプリケーションの効果的な事前キャッシュを行なう。【選択図】図２８

Description

本明細書で開示する技術は、ファイルを受信する受信装置及び受信方法、並びに、ファイルを送信する送信装置及び送信方法に係り、例えば、所定のトランスポート方式で伝送されるファイルを受信する受信装置及び受信方法、並びに、送信装置及び送信方法に関する。

現在の放送システムでは、メディアのトランスポート方式として、ＭＰＥＧ−２ ＴＳ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ−２ Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ）方式やＲＴＰ（Ｒｅａｌ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）方式が広く使用されている（例えば、特許文献１を参照のこと）。次世代のディジタル放送方式として、ＭＰＥＧで新たなメディア・トランスポート方式として規格化されたＭＭＴ（ＭＰＥＧ Ｍｅｄｉａ Ｔｒａｎｓｐｏｒｔ）（例えば、非特許文献１を参照のこと）が検討されている。ＭＭＴでは異なる伝送路の組み合わせで利用することが容易であり、放送や通信の複数の伝送路に共通に用いることができる。

ＭＭＴ方式によれば、ＭＭＴパケット上で、ストリーム・メディアである映像や音声などのタイムド・メディア（Ｔｉｍｅｄ ｍｅｄｉａ）と、ファイルのようなノンタイムド・メディア（Ｎｏｎ ｔｉｍｅｄ ｍｅｄｉａ）の両方を伝送することが可能である。

特開２０１３−１５３２９１号公報

ＩＳＯ／ＩＥＣ ＦＤＩＳ ２３００８−１：２０１３（Ｅ） Ｉｎｆｏｒｍａｔｉｏｎ ｔｅｃｈｎｏｐｌｏｇｙ−Ｈｉｇｈ ｅｆｆｉｃｉｅｎｃｙ ｃｏｄｉｎｇ ａｎｄ ｍｅｄｉａ ｄｅｌｉｖｅｒｙ ｉｎ ｈｅｔｅｒｏｇｅｎｅｏｕｓ ｅｎｖｉｒｏｎｍｅｎｔｓ−Ｐａｒｔ１：ＭＰＥＧ ｍｅｄｉａ ｔｒａｎｓｐｏｒｔ（ＭＭＴ）

本明細書で開示する技術の目的は、所定のトランスポート方式で伝送されるファイルを好適に受信することができる、優れた受信装置及び受信方法、並びに、所定のトランスポート方式でファイルを好適に送信することができる、優れた送信装置及び送信方法を提供することにある。

本願は、上記課題を参酌してなされたものであり、請求項１に記載の技術は、
所定のトランスポート方式の伝送信号を受信する受信部と、
受信信号を各メディア・データとシグナリング情報にデマルチプレクスするデマルチプレクサーと、
デマルチプレクスされたシグナリング情報に基づいて、デマルチプレクスされた少なくともの１つのメディア・データのキャッシュを制御する制御部と、
を具備する受信装置である。

本願の請求項２に記載の技術によれば、請求項１に記載の受信装置において、前記所定のトランスポート方式はＭＭＴである。

本願の請求項３に記載の技術によれば、請求項１に記載の受信装置において、伝送信号はタイムド・メディア及びノンタイムド・メディアを含み、前記制御部は、ノンタイムド・メディアのキャッシュを制御するように構成されている。

本願の請求項４に記載の技術によれば、請求項１に記載の受信装置において、前記ノンタイムド・メディアは、データ放送アプリケーションのアセットを構成する複数のファイル・データからなり、前記制御部は、キャッシュの空き容量に応じて、ファイル・データのキャッシュを制御するように構成されている。

本願の請求項５に記載の技術によれば、請求項４に記載の受信装置の前記制御部は、受信したシグナリング情報に基づいて、データ放送アプリケーションを実行する際の階層的なファイル・データへのアクセス範囲と、各アクセス範囲におけるファイル・データのロケーション情報及びサイズを取得して、キャッシュを制御するように構成されている。

本願の請求項６に記載の技術によれば、請求項４又は５のいずれかに記載の受信装置の前記制御部は、以下の４通りの階層的なアクセス範囲（ａ）〜（ｄ）とそのサイズを把握して、キャッシュの空き容量に応じていずれのアクセス範囲でキャッシュするかを決定するように構成されている。
（ａ）アプリケーション実行時に直接参照するファイル・データ
（ｂ）同時に表示するアプリケーション提示単位を構成するファイル・データのリソース・グループ
（ｃ）同時に表示するアプリケーション提示単位を構成するリソース・グループと、これにリンクする他のアプリケーション提示単位を含む大きなリソース・グループ
（ｄ）アプリケーション全体のリソース・グループ

本願の請求項７に記載の技術によれば、請求項６に記載の受信装置の前記制御部は、シグナリング情報として、アプリケーションにおいてロケーションを示すＵＲＬを放送などのＭＭＴ伝送路上のロケーションにマッピングする第１の情報と、アプリケーションにおける表示単位とリンク関係を示す第２の情報を受信して、前記４通りの階層的なアクセス範囲（ａ）〜（ｄ）とそのサイズを把握するように構成されている。

本願の請求項８に記載の技術によれば、請求項７に記載の受信装置の前記受信部は、前記第１の情報として、アプリケーションの伝送方法とロケーションを示すＵＲＬ情報を管理するアプリケーション情報テーブルと、アプリケーションにおいてロケーションを示すＵＲＬとデータ・トランスミッション・メッセージ上のｉｔｅｍ識別情報との対応関係を管理するデータ・ロケーション・マネジメント・テーブルと、ｉｔｅｍ情報と、そのアイテムを含むアセットのａｓｓｅｔ識別情報、そのアセットのＭＭＴ伝送路上のＭＭＴＰパケットのｄｏｗｎｌｏａｄ＿ｉｄ及びｉｔｅｍ識別情報との対応関係を管理するデータ・アセット・マネジメント・テーブルと、ａｓｓｅｔ識別情報とＭＭＴ伝送路上でそのアセットを伝送するパケットのｐａｃｋｅｔ識別情報の対応関係を管理するＭＭＴパッケージ・テーブルを受信するように構成されている。

本願の請求項９に記載の技術によれば、請求項７又は８のいずれかに記載の前記受信部は、前記第２の情報として、コンテントに含まれるアプリケーション提示単位の識別情報、アプリケーション提示単位に含まれるすべてのアイテムのｉｔｅｍ識別情報と、これにリンクする他のアプリケーション提示単位の識別情報を管理するデータ・コンテント・マネジメント・テーブルを受信するように構成されている。

本願の請求項１０に記載の技術によれば、請求項１乃至９のいずれかに記載の受信装置の前記制御部は、ｐｒｅｆｅｔｃｈ（先読み）に状態が制御されたアプリケーションに関するシグナリング情報を受信したことに応答して、キャッシュ処理を実行するように構成されている。

また、本願の請求項１１に記載の技術は、
所定のトランスポート方式の伝送信号を受信する受信ステップと、
受信信号を各メディア・データとシグナリング情報にデマルチプレクスするデマルチプレクス・ステップと、
デマルチプレクスされたシグナリング情報に基づいて、デマルチプレクスされた少なくともの１つのメディア・データのキャッシュを制御する制御ステップと、
を有する受信方法である。

また、本願の請求項１２に記載の技術は、
タイムド・メディア及びノンタイムド・メディアと、受信側でノンタイムド・メディアのキャッシュ処理に利用可能な情報を含むシグナリング・メッセージをマルチプレクスするマルチプレクサーと、
マルチプレクスされたパケットを所定のトランスポート方式で送信する送信部と、
を具備する送信装置である。

本願の請求項１３に記載の技術によれば、請求項１２に記載の送信装置において、前記所定のトランスポート方式はＭＭＴである。

本願の請求項１４に記載の技術によれば、請求項１２又は１３のいずれかに記載の送信装置において、前記ノンタイムド・メディアは、データ放送アプリケーションのアセットを構成する複数のファイル・データからなり、前記シグナリング・メッセージは、アプリケーションにおいてロケーションを示すＵＲＬを放送などのＭＭＴ伝送路上のロケーションにマッピングする第１の情報と、アプリケーションにおける表示単位とリンク関係を示す第２の情報を含む。

本願の請求項１５に記載の技術によれば、請求項１４に記載の送信装置において、前記第１の情報は、アプリケーションの伝送方法とロケーションを示すＵＲＬ情報を管理するアプリケーション情報テーブルと、アプリケーションにおいてロケーションを示すＵＲＬとデータ・トランスミッション・メッセージ上のｉｔｅｍ識別情報との対応関係を管理するデータ・ロケーション・マネジメント・テーブルと、ｉｔｅｍ識別情報と、そのアイテムを含むアセットのａｓｓｅｔ識別情報、そのアセットのＭＭＴ伝送路上のＭＭＴＰパケットのｄｏｗｎｌｏａｄ＿ｉｄ及びｉｔｅｍ識別情報との対応関係を管理するデータ・アセット・マネジメント・テーブルと、ａｓｓｅｔ識別情報とＭＭＴ伝送路上でそのアセットを伝送するパケットのｐａｃｋｅｔ識別除法の対応関係を管理するＭＭＴパッケージ・テーブルを含む。

本願の請求項１６に記載の技術によれば、請求項１４又は１５のいずれかに記載の送信装置において、前記第２の情報は、コンテントに含まれるアプリケーション提示単位の識別情報、アプリケーション提示単位に含まれるすべてのアイテムのｉｔｅｍ識別情報と、これにリンクする他のアプリケーション提示単位の識別情報を管理するデータ・コンテント・マネジメント・テーブルを含む。

また、本願の請求項１７に記載の技術は、
タイムド・メディア及びノンタイムド・メディアと、受信側でノンタイムド・メディアのキャッシュ処理に利用可能な情報を含むシグナリング・メッセージをマルチプレクスするマルチプレクス・ステップと、
マルチプレクスされたパケットを所定のトランスポート方式で送信する送信ステップと、
を有する送信方法である。

本明細書で開示する技術によれば、所定のトランスポート方式で伝送されるファイルを好適に受信することができる、優れた受信装置及び受信方法、並びに、所定のトランスポート方式でファイルを好適に送信することができる、優れた送信装置及び送信方法を提供することができる。

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

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

図１は、本明細書で開示する技術を適用したディジタル放送システム１０の構成例を模式的に示した図である。 図２は、ＭＭＴを適用した放送信号のスタック・モデル２００を示した図である。 図３は、図２に示した放送信号を送出する放送送出システム１１の構成例を示した図である。 図４は、図２に示した放送信号を受信する受信機１２の構成例を示した図である。 図５は、ＭＭＴ方式に従って放送送出システム１１からＲＦ伝送路に送出される放送信号（パッケージ）５００のイメージを示した図である。 図６は、ＭＭＴパケットのヘッダーの構成例を示した図である。 図７は、ノンタイムド・メディアを伝送するＭＭＴＰパケットの場合の拡張ヘッダー７００の構成例を示した図である 図８は、ＭＰＵモードの場合のＭＭＴＰペイロード８００の構成例を示した図である。 図９は、ペイロードにタイムド・メディアを配置したＭＦＵのＤＵ＿Ｈｅａｄｅｒ９００の構成例を示した図である。 図１０は、ペイロードにノンタイムド・メディアを配置したＭＦＵのＤＵ＿Ｈｅａｄｅｒ１０００の構成例を示した図である。 図１１は、ノンタイムド・メディアのデータを伝送する際のパケット構成例を示した図である。 図１２は、ＰＡメッセージ１２０１と、ＰＡメッセージに含まれるＭＰテーブル１２０２の構成例を示した図である。 図１３は、ＰＡメッセージ１３００のシンタックス例を示した図である。 図１４は、ＰＡメッセージに含まれるパラメーターの説明を示した図である。 図１５は、ＭＰテーブル（ＭＰＴ）のシンタックス例（前半部分）を示した図である。 図１６は、ＭＰテーブルのシンタックス例を示した図である。 図１７は、ＭＰテーブルに含まれる各パラメーターを説明した図である。 図１８は、Ｍ２セクション・メッセージ１８００の構成例を示した図である。 図１９は、Ｍ２セクション・メッセージで伝送されるＭＨ ＡＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ）テーブル（ＭＨ ＡＩＴ）１９００の構成例を示した図である。 図２０は、アプリケーション情報記述子２０００の構成例を示した図である。 図２１は、アプリケーション情報記述子に含まれるパラメーターの説明を示した図である。 図２２は、伝送プロトコル記述子２２００の構成例を示した図である。 図２３は、ＨＴＴＰ／ＨＴＴＰＳ、ＭＭＴ、及びノンタイムド伝送に共通のセレクター・バイトの構成例を示した図である。 図２４は、シグナリング・メッセージの１つであるデータ・トランスミッション・メッセージの構成例を示した図である。 図２５は、データ・アセット・マネジメント・テーブル（ＤＡＭＴ）２５００の構成例を示した図である。 図２６は、データ・ロケーション・マネジメント・テーブル（ＤＬＭＴ）２６００の構成例を示した図である。 図２７は、データ・コンテント・マネジメント・テーブル（ＤＣＭＴ）２７００の構成例を示した図である。 図２８は、ＭＭＴ伝送されるデータ放送アプリケーション（コンテント）の伝送、ロケーションと提示を行なう仕組みを説明するための図である。 図２９は、ＭＭＴ伝送路からデータ放送アプリケーション（コンテント）を取得する際の、シグナリング情報として伝送される各テーブルの参照関係を説明するための図である。 図３０は、受信機内でアプリケーションを事前キャッシュする仕組みを模式的に示した図である。 図３１は、受信機において放送ストリームからアプリケーションを取得して起動する動作を説明するための図である。 図３２は、受信機においてアプリケーション提示画面が遷移する際の動作を説明するための図である。 図３３は、アプリケーションのファイル・データが更新された際の受信機における動作を説明するための図である。

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

図１には、本明細書で開示する技術を適用したディジタル放送システム１０の構成例を模式的に示している。図示のディジタル放送システム１０は、放送送出システム１１と、受信機１２で構成される。

放送送出システム１１は、伝送メディアを含むＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）方式の放送信号を送信する。放送信号の伝送ディアには、タイムド・メディアと、ファイルのようなノンタイムド・メディアの両方が含まれる。タイムド・メディアは、例えば、ビデオやオーディオ、字幕などのストリーム・データである。また、ノンタイムド・メディアは、例えばＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）文書のようなアプリケーション（コンテント）のファイル・データである。

一方、受信機１２は、放送送出システム１１から送られてくる放送信号を受信する。そして、受信機１２は、受信した放送信号からビデオやオーディオ、字幕などの伝送メディアを取得して、画像や音声を提示する。

図１に示したディジタル放送システム１０では、放送送出システム１１から受信機１２へ放送信号を伝送する際のトランスポート方式として、ＭＭＴを適用することを想定している。図２には、この場合の放送信号構成例をスタック・モデル２００で示している。

スタック・モデル２００の最下層には、物理レイヤー（ＰＨＹ）２０１がある。物理例２０１には、変調方式や誤り訂正方式などが含まれる。

物理レイヤー２０１の上に、ＴＬＶ（Ｔｙｐｅ Ｌｅｎｇｔｈ Ｖａｌｕｅ）の伝送パケットのレイヤー２０２がある。また、ＴＬＶ２０２の上にはＩＰパケット２０３が載り、さらにその上にＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）２０４が載る。また、ＴＬＶの伝送パケット２０２の上には、ＩＰ２０３とＵＤＰ２０４のヘッダーを圧縮したヘッダー圧縮ＩＰ２０５と、シグナリング（Ｓｉｇｎａｌｉｎｇ）情報としての伝送制御信号２０６も載る。

ＵＤＰ２０４の上には、ＭＭＴパケット２０７、現在時刻の情報を含むＮＴＰ（Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）パケット２０８などが載る。ＭＭＴプロトコル（ＭＭＴＰ）は、ＭＭＴＰペイロード２０９をＩＰネットワーク上で伝送するためのアプリケーション・レイヤーのトランスポート・プロトコルである。

ＭＭＴパケット２０７のＭＭＴペイロード２０９には、ＭＦＵ（ＭＭＴ Ｆｒａｇｍｅｎｔ Ｕｎｉｔ）２１０あるいはシグナリング・メッセージ（Ｓｉｇｎａｌｉｎｇ Ｍｅｓｓａｇｅ）２１１が含まれる。ＭＦＵ２１０は、符号化されたタイムド・メディア並びにノンタイムド・メディアのコンテナーであるＭＰＵ（Ｍｅｄｉａ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）のフラグメントである。ＭＦＵ２１０には、ビデオやオーディオ、字幕などのストリーム・データ（タイムド・メディア）２１２や、ＨＴＭＬ文書データなどのファイル・データ（ノンタイムド・メディア）２１３が挿入される。

図３には、図２に示した放送信号を送出する放送送出システム１１の構成例を示している。図示の放送送出システム１１は、時計部３０１と、信号送出部３０２と、ビデオ・エンコーダー３０３と、オーディオ・エンコーダー３０４と、キャプション・エンコーダー３０５と、シグナリング・エンコーダー３０６と、ファイル・エンコーダー３０７と、情報システム３０８と、ＴＬＶシグナリング・エンコーダー３０９と、ＩＰサービス・マルチプレクサー（ＭＵＸ）３１０と、ＴＬＶマルチプレクサー（ＭＵＸ）３１１と、変調・送信部３１２を備えている。

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

信号送出部３０２は、例えばＴＶ放送局のスタジオやＶＴＲなどの記録再生機であり、タイムド・メディアであるビデオ、オーディオ、字幕などのストリーム・データや、ノンタイムド・メディアであるＨＴＭＬ文書データなどのファイル・データをそれぞれ、ビデオ・エンコーダー３０３、オーディオ・エンコーダー３０４、キャプション・エンコーダー３０５、ファイル・エンコーダー３０７に送る。また、情報システム３０８は、ＴＶ放送局のスケジューラー並びにファイルの供給源であり、ノンタイムド・メディアであるＨＴＭＬ文書データ、シグナリング情報をそれぞれ、ファイル・エンコーダー３０７、シグナリング・エンコーダー３０６に送る。

ビデオ・エンコーダー３０３は、信号送出部３０２から送出されるビデオ信号を符号化し、さらにパケット化して、ビデオのＭＭＴパケットを含むＩＰパケットをＩＰサービス・マルチプレクサー３１０に送る。また、オーディオ・エンコーダー３０４は、信号送出部３０２から送出されるオーディオ信号を符号化し、さらにパケット化して、オーディオのＭＭＴパケットを含むＩＰパケットをＩＰサービス・マルチプレクサー３１０に送る。また、キャプション・エンコーダー３０５は、信号送出部３０２から送出される字幕信号を符号化し、さらにパケット化して、字幕のＭＭＴパケットを含むＩＰパケットをＩＰサービス・マルチプレクサー３１０に送る。

シグナリング・エンコーダー３０６は、情報システム３０８から送出される情報に基づいてシグナリング・メッセージを生成し、ペイロード部にこのシグナリング・メッセージが配置されたＭＭＴパケットを含むＩＰパケットをＩＰサービス・マルチプレクサー３１０に送る。本実施形態では、生成されるメッセージは、ＰＡメッセージ、Ｍ２セクション・メッセージ、データ・トランスミッション・メッセージの３種類に大別されるが、各シグナリング・メッセージの詳細については後述に譲る。

ファイル・エンコーダー３０７は、信号送出部３０２又は情報システム３０８から送出されるファイル・データを、必要に応じて分割して、ファイル・データを含むＭＭＴパケットを生成し、このＭＭＴパケットを含むＩＰパケットをＩＰサービス・マルチプレクサー３１０に送る。なお、ファイル・データは、データ放送コンテント（データ放送用アプリケーション）を構成するものである。

放送送出システム１１は、送出するチャンネル（放送番組）毎にＩＰサービス・マルチプレクサー３１０を装備する。１つのチャンネルのＩＰサービス・マルチプレクサー３１０は、各エンコーダー３０３〜３０７から送られてくるビデオ、オーディオ、字幕、シグナリング・メッセージ、及びファイル・データの各々を含むＩＰパケットをマルチプレクスして、１つのチャンネルを構成するＴＬＶパケットを生成する。

ＴＬＶシグナリング・エンコーダー３０９は、情報システム３０８から送出されるシグナリング情報をエンコードして、ペイロード部に配置するＴＬＶパケットを生成する。

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

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

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

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

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

また、信号送出部３０２から送出されるオーディオ信号、字幕信号に対しても、同様の処理が行なわれる。そして、また、オーディオ・エンコーダー３０４で生成されるオーディオのＭＭＴパケットを含むＩＰパケットがＩＰサービス・マルチプレクサー３１０に送られ、キャプション・エンコーダー３０５で生成される字幕のＭＭＴパケットを含むＩＰパケットがＩＰサービス・マルチプレクサー３１０に送られる。

また、シグナリング・エンコーダー３０６では、情報システム３０８から送出される情報に基づいてシグナリング・メッセージを生成され、ペイロード部にこのシグナリング・メッセージが配置されたＭＭＴパケットを含むＩＰパケットが生成される。このＩＰパケットは、ＩＰサービス・マルチプレクサー３１０に送られる。

また、信号送出部３０２又は情報システム３０８から送出されるファイル・データは、ファイル・エンコーダー３０７に供給される。ファイル・エンコーダー３０７では、ファイル・データが必要に応じて分割され、ファイル・データを含むＭＭＴパケットが生成され、このＭＭＴパケットを含むＩＰパケットが生成される。このＩＰパケットは、ＩＰサービス・マルチプレクサー３１０に送られる。

各ＩＰサービス・マルチプレクサー３１０では、各エンコーダー３０３〜３０７から送られてくるビデオ、オーディオ、字幕、シグナリング・メッセージ、及びファイル・データの各々を含むＩＰパケットがマルチプレクスされて、１つのチャンネルを構成するＴＬＶパケットが生成される。

ＴＬＶシグナリング・エンコーダー３０９では、情報システム３０８から送出されるシグナリング情報がエンコードされて、ペイロード部に配置するＴＬＶパケットを生成する。

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

また、図４には、図２に示した放送信号を受信する受信機１２の構成例を示している。図示の受信機１２は、チューナー・復調部４０１と、デマルチプレクサー（ＤＥＭＵＸ）４０２と、時計部４０３と、ビデオ・デコーダー４０４と、オーディオ・デコーダー４０５と、キャプション・デコーダー４０６と、データ放送アプリケーション・エンジン４０７と、システム制御部４０８と、合成部４０９を備えている。

チューナー・復調部４０１は、ＲＦ変調信号を受信して、復調処理を行なって、放送ストリームを得る。デマルチプレクサー４０２は、この放送ストリームに対して、デマルチプレクス処理及びでパケット化処理を行なって、ＮＴＰ時刻情報、ＰＴＳ（Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ Ｓｔａｍｐ：提示時刻情報）、シグナリング情報、ビデオ、オーディオ、キャプションの各符号化信号、ファイル・データ、並びにシグナリング情報を出力する。なお、ファイル・データは、データ放送コンテント（データ放送用アプリケーション）を構成するものである。

システム制御部４０８は、デマルチプレクサー４０２で得られるシグナリング情報や、ユーザー操作部（図示しない）を介したユーザーからの操作情報などに基づいて、当該受信機１２の各部の動作を制御する。時計部４０３は、デマルチプレクサー４０２で得られるＮＴＰ時刻情報に基づいて、この時刻情報に同期した時刻情報を生成する。

ビデオ・デコーダー４０４は、デマルチプレクサー４０２で得られる符号化ビデオ信号をデコードして、ベースバンドのビデオ信号を得る。また、オーディオ・デコーダー４０５は、デマルチプレクサー４０２で得られる符号化オーディオ信号をデコードして、ベースバンドのオーディ信号を得る。また、キャプション・デコーダー４０６は、デマルチプレクサー４０２で得られる符号化字幕信号をデコードして、字幕の表示信号を得る。

データ放送アプリケーション・エンジン４０７は、ファイル・データとして伝送されてくるデータ放送アプリケーションの処理部である。すなわち、データ放送アプリケーション・エンジン４０７は、デマルチプレクサー４０２で得られるファイル・データを処理して、データ放送の表示信号を得る。データ放送アプリケーションは、例えばＨＴＭＬ形式で記述されるファイル・データ（ＨＴＭＬ文書データ）である。本明細書では、データ放送アプリケーションを、「アプリケーション」又は「コンテント」とも呼ぶ。

なお、放送ストリームでは、同一コンテントのファイル・データが繰り返し送られてくる。システム制御部４０８は、デマルチプレクサー４０２におけるフィルタリング動作を制御して、繰り返し送られてくるファイル・データ群の中からデマルチプレクサー４０２において必要なもののみがデータ放送アプリケーション・エンジン４０７で取得されるようにする。

本実施形態では、システム制御部４０８は、ＰＡメッセージ、Ｍ２セクション・メッセージ、データ・トランスミッション・メッセージの各々に含まれるシグナリング・テーブルを参照して、データ放送を提示するために必要なアクセス範囲を特定し、データ放送アプリケーション・エンジン４０７でキャッシュ可能なファイル・データを事前に取得するためのフィルタリング動作を制御する。ファイル・データの事前キャッシュの詳細については後述に譲る。

また、システム制御部４０８は、各デコーダー４０４〜４０６におけるデコード・タイミングをＰＴＳに基づいて制御し、ビデオ、オーディオ、字幕の提示タイミングを調整する。合成部４０９は、ベースバンドのビデオ信号に、字幕の表示信号及びデータ放送の表示信号を合成し、映像表示用のビデオ信号を得る。また、オーディオ・デコーダー４０５で得られるベースバンドのオーディオ信号は、音声出力用のオーディオ信号となる。

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

チューナー・復調部４０１では、ＲＦ変調信号が受信され、復調処理が行なわれて、放送ストリームが得られる。デマルチプレクサー４０２では、この放送ストリームに対して、デマルチプレクス処理及びデパケット化処理を行なわれ、ＮＴＰ時刻情報、ＰＴＳ、シグナリング情報、ビデオ、オーディオ、キャプションの各符号化信号、並びに、ファイル・データが抽出される。

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

デマルチプレクサー４０２で抽出された符号化ビデオ信号は、ビデオ・デコーダー４０４に送られてデコードされ、ベースバンドのビデオ信号が得られる。また、デマルチプレクサー４０２で抽出された符号化字幕信号はキャプション・デコーダー４０６に送られてデコードされ、字幕の表示信号が得られる。また、デマルチプレクサー４０２で抽出されたファイル・データはデータ放送アプリケーション・エンジン４０７に送られて処理され、データ放送の表示信号が得られる。なお、システム制御部４０８によってデマルチプレクサー４０２におけるフィルタリング動作が制御されて、必要なファイル・データのみがデマルチプレクサー４０２で取得されるようにする。

そして、合成部４０９では、ベースバンドのビデオ信号に、字幕の表示信号及びデータ放送の表示信号が合成され、映像表示用のビデオ信号が得られる。

また、デマルチプレクサー４０２で抽出された符号化オーディオ信号はオーディオ・デコーダー４０５に送られてデコードされ、音声出力用のベースバンドのオーディ信号が得られる。

図１に示したディジタル放送システム１０では、放送送出システム１１から受信機１２へ放送信号を伝送する際のトランスポート方式として、ＭＭＴを適用することを想定している。図５には、ＭＭＴ方式に従って放送送出システム１１からＲＦ伝送路に送出される放送信号５００のイメージを示している。

１つのチャンネル（放送番組）の放送信号は、ビデオ、オーディオ、字幕などのタイムド・メディアと、ファイル・データのようなノンタイムド・メディアで構成され、これらをエンコードしたメディア・データをＭＰＵに格納して伝送する。また、これらの放送信号の伝送制御などに関する情報を、シグナリング情報として伝送する。ＭＭＴでは、１つのチャンネル（放送番組）を構成するタイムド・メディア及びノンタイムド・メディアのデータを異なる伝送路の組み合わせで利用することが容易である。図５に示す例では、放送信号５００として、ビデオ、オーディオ、字幕、ファイル・データ、シグナリング情報など、データのタイプ毎のＭＭＴ伝送路５０１〜５０４が利用されている。すなわち、図中、字幕データ用の伝送路は便宜上、図示を省略している。

１つのチャンネル（放送番組）は、ビデオ、オーディオ、字幕、ファイル・データ（アプリケーション）などタイプの異なる複数のアセットで構成される「パッケージ」と言うことができる（パッケージは、ＭＭＴ伝送路を使値って伝送されるメディア・データの論理集合である）。各アセットは、同じａｓｓｅｔ＿ｉｄを共有する１又はそれ以上のＭＰＵの集合（論理グループ）であり、それぞれ専用のＥＳ（Ｅｌｅｍｅｎｔａｒｙ Ｓｔｒｅａｍ）すなわちＭＭＴ伝送路上で伝送される（アセットは、固有の識別子に関連付けられ、マルチメディアのプレゼンテーションを構成するために使用されるデータのエンティティーである）。すなわち、伝送路５０１では、共通のａｓｓｅｔ＿ｉｄを持つＭＰＵ論理グループからなるビデオのＭＭＴパケット（ＭＭＴＰ）が伝送され、伝送路５０２では、共通のａｓｓｅｔ＿ｉｄを持つＭＰＵ論理グループからなるオーディオのＭＭＴパケットが伝送され、伝送路５０３では、共通のａｓｓｅｔ＿ｉｄを持つＭＰＵ論理グループからなるファイル・データのＭＭＴパケットが伝送される。ＭＰＵは、ａｓｓｅｔ＿ｉｄと、該当する伝送路上でのＭＰＵのシーケンス番号で特定される。また、各メディアを伝送するＭＭＴ伝送路は、ａｓｓｅｔ＿ｉｄで識別することができる。

付言すれば、１つのパッケージ（放送番組）で、タイプが同じ複数の（すなわち、ａｓｓｅｔ＿ｉｄが異なる）アセットが伝送されることもある。例えば、同じ放送番組に対して、２以上のファイル・コンテント（データ放送アプリケーション）が提供される場合である。このような場合、異なるファイル・コンテントには別々のａｓｓｅｔ＿ｉｄが割り振られ、別々のＭＰＵ論理グループとして異なるＭＭＴ伝送路上で伝送されることになる。図５では、簡素化のため、ファイル・データ用の伝送路５０３を１本しか描いていない。

また、ＭＭＴは、放送や通信の複数の伝送路に共通に用いることができる。ＨＴＭＬ文書データのようなノンタイムド・メディアは、図５に示したように放送の伝送路でタイムド・メディアとともに伝送される以外に、通信の伝送路を介して提供することもできる。

また、伝送路５０４では、同じシグナリング・メッセージを含んだＭＭＴパケットが、繰り返し伝送される。本明細書で開示する技術を実現する上で、伝送されるシグナリング・メッセージは、ＰＡメッセージ５１０、Ｍ２セクション・メッセージ５２０、データ・トランスミッション・メッセージ５３０の３種類のシグナリング・メッセージが関連する。各種シグナリング・メッセージで、シグナリング・テーブルが伝送される。例えば、ＰＡメッセージ５１０内には、ＭＰ（ＭＭＴ Ｐａｃｋａｇｅ）テーブル５１１が含まれている。また、Ｍ２セクション・メッセージ５２０内には、ＭＨ ＡＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ）テーブル５２１が含まれている。また、データ・トランスミッション・メッセージ５３０は、データの伝送方法やデータ管理の制御方法を通知するためのメッセージであり、データ・ロケーション・マネジメント・テーブル５３１、データ・アセット・マネジメント・テーブル５３２、データ・コンテント・マネジメント・テーブル５３３の各シグナリング・テーブルが含まれている。各テーブルの詳細については後述に譲る。

上述したように、ＭＭＴＰでは、ビデオ、オーディオ、字幕などのタイムド・メディアや、ファイル・データのようなノンタイムド・メディアが伝送される。図６には、ＭＭＴＰパケット６００の構成例を示している。ＭＭＴＰパケットは、ＭＭＴプロトコルを用いて伝送されるようにフォーマットされたメディア・データのユニットである。詳細については、例えば非特許文献１を参照されたい。

参照番号６０１で示すパケット・カウンター・フラグ「Ｃ」に１が代入されていると、参照番号６０２で示すパケット・カウンターのフィールドがこのＭＭＴＰパケット内に存在することが表される。パケット・カウンター６０２は、ＭＭＴＰパケットをカウントした整数値を書き込む３２ビット長のフィールドであり、ＭＭＴＰパケットを送信する度に１ずつインクリメントされる。

参照番号６０３で示す拡張フラグ「Ｘ」に１が代入されていると、参照番号６０４で示す拡張ヘッダー６０４が存在することが表される。図６の下には、拡張ヘッダー６０４の構成例を併せて示している。拡張ヘッダー６０４は、参照番号６０４−１で示す１６ビット長のｔｙｐｅフィールドと、参照番号６０４−２で示すｌｅｎｇｔｈフィールドと、参照番号６０４−３で示すｈｅａｄｅｒ＿ｅｘｔｅｎｓｉｎ＿ｖａｌｕｅフィールドで構成される。ｌｅｎｇｔｈフィールドには、ｈｅａｄｅｒ＿ｅｘｔｅｎｓｉｎ＿ｖａｌｕｅフィールドのバイト長が書き込まれる。ｈｅａｄｅｒ＿ｅｘｔｅｎｓｉｎ＿ｖａｌｕｅフィールドには、ＭＭＴの仕様から外れた拡張情報を書き込むことができる。

参照番号６０６で示すｔｙｐｅフィールドには、当該ＭＭＴＰパケットのペイロード・データのタイプを表すタイプ値が書き込まれる。タイプ値の定義を以下の表１に示しておく。

参照番号６０５で示すＲＡＰ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｐｏｉｎｔ）フラグに１が代入されていると、当該ＭＭＴＰパケットのペイロードが当該データ・タイプのデータ・ストリームへのＲａｎｄｏｍ Ａｃｃｅｓｓ Ｐｏｉｎｔを含んでいることを表す。

参照番号６０７で示す、１６ビット長のｐａｃｋｅｔ＿ｉｄフィールドには、アセットを区別するための整数値が書き込まれる。このフィールドの値は、当該ＭＭＴＰパケットが属するアセットのａｓｓｅｔ＿ｉｄに由来する。ｐａｃｋｅｔ＿ｉｄとａｓｓｅｔ＿ｉｄのマッピングは、シグナリング・メッセージの一部であるＭＭＴパッケージ（ＭＰ）テーブルで示されている。

参照番号６０８で示す、３２ビット長のｔｉｍｅｓｔａｍｐフィールドには、当該ＭＭＴＰパケットの送信時間が、ＮＴＰプロトコルで規定されているｓｈｏｒｔ−ｆｏｒｍａｔで記載される。

参照番号６０９で示す、３２ビット長のｐａｃｋｅｔ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒフィールドには、同一のｐａｃｋｅｔ＿ｉｄを持つパケットを識別するための整数値（ＭＭＴ伝送路上でのシーケンス番号）が記載される。

図７には、ノンタイムド・メディアを伝送するＭＭＴＰパケットの場合の拡張ヘッダー７００の構成例を示している。図示のように、この場合、ｌｅｎｇｔｈフィールド７０１には、ｈｅａｄｅｒ＿ｅｘｔｅｎｓｉｎ＿ｖａｌｕｅフィールドのバイト長として４が書き込まれる。ｈｅａｄｅｒ＿ｅｘｔｅｎｓｉｎ＿ｖａｌｕｅフィールドには、ｄｏｗｎｌｏａｄ＿ｉｄが４バイトで記載される。

ＭＭＴプロトコルを使ってＭＰＵを伝送する際、送信側及び受信側ではそれぞれパケット化、デパケット化が必要である。パケット化により、ＭＰＵはＭＭＴＰペイロードに挿入され、ＭＭＴＰパケットで伝送される。ＭＭＴＰペイロードのフォーマットは、大きなペイロードの伝送が可能なように、ＭＭＴＰペイロードのフラグメンテーションを許容する。また、ＭＴＰペイロードのフォーマットは、小さなデータ・ユニットに対応して、複数のＭＭＴＰペイロードを単一のＭＭＴＰペイロードに挿入するアグリゲーションも許容する。受信側では、デパケット化して、元のＭＰＵデータを復元する。

図８には、ＭＰＵモードの場合のＭＭＴＰペイロード８００の構成例を示している。詳細については、例えば非特許文献１を参照されたい。ＭＰＵモードは、ＭＭＴＰヘッダーのｔｙｐｅフィールド６０６に「０ｘ００」が書き込まれている場合である。ＭＰＵモードのＭＭＴＰパケットは、ビデオ、オーディオ、ファイル・データ（アプリケーション）の伝送に使用される。

参照番号８０１で示すＭＰＵ Ｆｒａｇｍｅｎｔ Ｔｙｐｅ（ＦＴ）フィールドには、フラグメントのタイプが４ビットの値で示される。ＦＴ値の定義を以下の表２に示しておく。

参照番号８０２で示すＴｉｍｅｄ（Ｔ）フラグに１が記入されているときには、タイムド・メディアを伝送するＭＰＵがフラグメントされていることを示し、０が記入されているときには、ノンタイムド・メディアを伝送するＭＰＵがフラグメントされていることを示す。

参照番号８０３で示すＦｒａｇｍｅｎｔａｔｉｏｎ Ｉｄｅｎｔｉｆｉｅｒ（ｆ＿ｉ）フィールドは、ペイロード内のデータ・ユニットのフラグメンテーションに関する情報を、２ビットで表す。ｆ＿ｉの４つの値の定義を以下の表３に示しておく。

当該ペイロードが複数のデータ・ユニットをアグリゲートしたものであるときには、参照番号８０４で示すａｇｇｒｅｇａｔｉｏｎ（Ａ）フラグに１が記入される。

参照番号８０５で示す、８ビット長のｆｒａｇｍｅｎｔ＿ｃｏｕｎｔｅｒフィールドには、当該ＭＭＴＰペイロードが続く同じデータ・ユニットのフラグメントを含んでいるペイロードの数が記載される。

参照番号８０６で示す、１６ビット長のＤＵ＿ｌｅｎｇｔｈフィールドには、当該フィールドに続くデータ（ＤＵ：Ｄａｔａ Ｕｎｉｔ）の長さが記載される。但し、Ａフラグ８０４が０のときは、ＤＵ＿ｌｅｎｇｔｈフィールド８０６はない。

参照番号８０７で示すＤＵ＿Ｈｅａｄｅｒは、データ・ユニットのヘッダーである。但し、ＦＴ値８０１が０又は１のとき（言い換えれば、ＭＦＵでないとき）には、ＤＵ＿Ｈｅａｄｅｒ８０７はない。ＭＦＵは、タイムド・メディアのサンプル若しくはサブサンプル、又は、ノンタイムド・メディアのアイテムを含んでいる。

図９には、ペイロードにタイムド・メディアを配置したＭＦＵのＤＵ＿Ｈｅａｄｅｒ９００の構成例を示している。また、図１０には、ペイロードにノンタイムド・メディアを配置したＭＦＵのＤＵ＿Ｈｅａｄｅｒ１０００の構成例を示している。図１０に示すように、ノンタイムド・メディアの場合のＤＵ＿Ｈｅａｄｅｒ１０００は、当該ＭＦＵの一部として伝送されるアイテムの識別子である３２ビット長のｉｔｅｍ＿ＩＤで構成される。アイテムは、ＨＴＭＬ文書データや、ＨＴＭＬ文書から参照されるモノメディア・データなどの、アプリケーションを構成するリソースである。ａｓｓｅｔ＿ｉｄで指定されたＭＭＴ伝送路上では、上述したＭＭＴＰパケットのヘッダー内のｐａｃｋｅｔ＿ｉｄ及び拡張ヘッダー内のｄｏｗｎｌｏａｄ＿ｉｄと、ＤＵヘッダー内のｉｔｅｍ＿ＩＤの組み合わせで、アイテムを一意に特定することができる。

図１１には、ノンタイムド・メディアのデータを伝送する際のパケット構成例を示している。

図１１（ａ）には、元のファイル・データの状態を示している。同図中、Ｆ１、Ｆ２はそれぞれ１つのファイル・データである。ファイル・データは、例えばＨＴＭＬ文書であり、１以上のアイテムを含んでいる。また、ＨＴＭＬ文書自体も１つのアイテムである。

図１１（ｂ）には、各ファイル・データＦ１、Ｆ２をＭＦＵに配置した様子を示している。ファイル・データＦ１は、ファイル・サイズが大きくないので、そのまま１つのＭＦＵのペイロードに配置される。一方、ファイル・データＦ２は、ファイル・サイズが大きいので、複数個に分割され、それぞれがＭＦＵのペイロードに配置される。図示の例では、ファイル・データＦ２は、Ｆ２−１とＦ２−２に２分割され、それぞれが別のＭＦＵのペイロードに配置されている。

ここで、ＨＴＭＬ文書データやモノメディアなどのノンタイムド・メディアがペイロードに配置されるＭＦＵには、そのアイテムを一意に示すｉｔｅｍ＿ＩＤが記載されたＤＵ＿Ｈｅａｄｅｒ（図１０を参照のこと）がそれぞれ付けられる。

次いで、図１１（ｃ）に示すように、各ＭＦＵには、ＭＭＴペイロードのヘッダー（図８を参照のこと）が付けられて、ＭＭＴペイロードとなる。ここで、ＭＭＴペイロードのヘッダーのＦｒａｇｍｅｎｔ Ｔｙｐｅ（ＦＴ）フィールドに値２を記載して、フラグメントのタイプがＭＦＵであることを示す。また、Ｔｉｍｅｄ（Ｔ）フラグに値０を記載して、ノンタイムド・メディアを伝送するＭＰＵであることを示す。また、フラグメントしていないノンタイムド・メディアを配置したＭＦＵには、Ｆｒａｇｍｅｎｔａｔｉｏｎ Ｉｄｅｎｔｉｆｉｅｒ（ｆ＿ｉ）フィールドに値０を記載する。一方、フラグメントしたノンタイムド・メディアを配置したＭＦＵには、Ｆｒａｇｍｅｎｔａｔｉｏｎ Ｉｄｅｎｔｉｆｉｅｒ（ｆ＿ｉ）フィールドに値１を記載するとともに、ｆｒａｇｍｅｎｔ＿ｃｏｕｎｔｅｒフィールドに該当するカウント値を記載する。

次いで、図１１（ｄ）に示すように、各ＭＭＴペイロードに、ＭＭＴＰパケットのヘッダー及び拡張ヘッダー（図６を参照のこと）が付けられて、ＭＭＴパケット・ストリームとなる。ここで、ＭＭＴＰヘッダーのｔｙｐｅフィールドには、０を記載して、ペイロード・データのタイプがＭＰＵであることを記載し、ｐａｃｋｅｔ＿ｉｄフィールドにはアセットを区別するための整数値が書き込まれる。また、拡張ヘッダーには、ｄｏｗｎｌｏａｄ＿ｉｄが記載される。したがって、ａｓｓｅｔ＿ｉｄで指定されたＭＭＴ伝送路上では、上述したＭＭＴＰパケットのヘッダー内のｐａｃｋｅｔ＿ｉｄ及び拡張ヘッダー内のｄｏｗｎｌｏａｄ＿ｉｄと、ＤＵヘッダー内のｉｔｅｍ＿ＩＤの組み合わせで、アイテムを一意に特定することができる。

さらに、図１１（ｅ）に示すように、各ＭＭＴパケットにＩＰヘッダー及びＵＤＰヘッダーが付けられて、ＩＰパケット・ストリームとなる。図示を省略したが、各ＩＰパケットにＴＬＶヘッダーを付けることで、放送ストリームを構成するＴＬＶパケットが生成される。

なお、図１１では図示を省略したが、ＭＭＴパケットには、シグナリング・メッセージをペイロードに含むＭＭＴパケットも存在する。シグナリング・メッセージは、ＰＡメッセージ、Ｍ２セクション・メッセージ、データ・トランスミッション・メッセージがある（前述並びに図５を参照のこと）。ＭＭＴＰペイロードにタイムド・メディアやノンタイムド・メディアなどの伝送メディアが含まれるか、あるいは、シグナリング・メッセージが含まれるかは、ＭＭＴＰヘッダー内のｔｙｐｅフィールドの値を参照して識別することができる。

続いて、本明細書で開示する技術を実現する上で関連する、ＭＭＴプロトコルで使用されるシグナリング・メッセージの構成について説明する。シグナリング・メッセージは、パッケージの伝送制御やパッケージの使用に必要なシグナリング情報であり、各種のシグナリング・テーブルを伝送する。

ＭＭＴのシグナリング・メッセージは、３つの共通するフィールドと、シグナリング・メッセージ・タイプ毎の特定の１つのフィールドと、メッセージ・ペイロードからなる一般的なフォーマットを使用する。メッセージ・ペイロードは、シグナリング情報を伝送する。以下、ＰＡメッセージ、Ｍ２セクション・メッセージ、データ・トランスミッション・メッセージの順に説明する。

ＰＡ（Ｐａｃｋｅｇｅ Ａｃｃｅｓｓ）メッセージは、Ｐａｃｋｅｇｅ Ａｃｃｅｓｓに必要なすべてのシグナリング・テーブル上の情報を持つＰＡテーブルを伝送する。ＰＡテーブルには、ＭＭＴ Ｐａｃｋａｇｅ（ＭＰ）テーブルが含まれる。図１２には、シグナリング・メッセージの１つであるＰＡメッセージ１２０１と、ＰＡメッセージに含まれるＭＰテーブル１２０２の構成例を示している。また、図１３には、ＰＡメッセージ１３００のシンタックス例を示し、図１４には、ＰＡメッセージに含まれるパラメーターの説明を示している。

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

ｅｘｔｅｎｓｉｏｎフィールドには、ｐａｙｌｏａｄのフィールドに配置されるＭＰテーブル（ＭＰＴ）のインデックス情報が配置される。このフィールドには、８ビットのｔａｂｌｅ＿ｉｄと、８ビットのｔａｂｌｅ＿ｖｅｒｓｉｏｎと、１６ビットのｔａｂｌｅ＿ｌｅｎｇｔｈが配置される。ｔａｂｌｅ＿ｉｄは、ＭＰテーブルを識別する固定値である。ｔａｂｌｅ＿ｖｅｒｓｉｏｎは、ＭＰテーブルのバージョンを示す。ｔａｂｌｅ＿ｌｅｎｇｔｈは、ＭＰテーブルのサイズをバイト単位で示す。

ＰＡメッセージのｐａｙｌｏａｄフィールドには、ＭＰテーブルが配置される。ＭＰテーブルは、すべてのアセットのリストを含むパッケージに関連する情報を格納する。

図１５及び図１６には、ＭＰテーブルのシンタックス例を示している（図１６は、図１５の続く後半部分である）。また、図１７には、ＭＰテーブルに含まれるパラメーターの説明を示している。以下、ＭＰテーブルの構成について説明する。

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

ＭＭＴ＿ｐａｃｋａｇｅ＿ｉｄは、放送信号で伝送されるすべての信号（ビデオ、オーディオ、字幕）、並びにファイルなどのアセットを構成要素とする全体のパッケージとしての識別情報である。この識別情報は、テキスト情報である。ＭＭＴ＿ｐａｃｋａｇｅ＿ｉｄ＿ｌｅｎｇｔｈは、そのテキスト情報のサイズをバイト単位で示す。

ＭＰ＿ｔａｂｌｅ＿ｄｅｓｃｒｉｐｔｏｒｓのフィールドは、パッケージ全体に関わる記述子の格納領域である。ＭＰＴ＿ｔａｂｌｅ＿ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈは、そのフィールドのサイズＮ２をバイト単位で示す、１６ビット長のパラメーターである。そして、ＭＰ＿ｔａｂｌｅ＿ｄｅｓｃｒｉｐｔｏｒは、さまざまな目的の記述子を規定した上で、Ｎ２バイト分（１つ又は複数配置）することを想定している。

ｎｕｍｂｅｒ＿ｏｆ＿ａｓｓｅｔｓは、パッケージを構成する要素としてのアセット（信号、ファイル）の数を示す、８ビットのパラメーターである。ｎｕｍｂｅｒ＿ｏｆ＿ａｓｓｅｔの数分（Ｎ３）だけ、以下のＡｓｓｅｔ ｌｏｏｐが配置される。

１つのＡｓｓｅｔ ｌｏｏｐ内には、個々のアセットの情報としてのａｓｓｅｔ＿ｉｄ＿ｌｅｎ、ａｓｓｅｔ＿ｉｄ、ｇｅｎ＿ｌｏｃ＿ｉｎｆｏ、ａｓｓｅｔ＿ｄｓｃ＿ｌｅｎ、ａｓｓｅｔ＿ｄｅｓｃｒｉｐｔｏｒの各パラメーターが配置される。

ａｓｓｅｔ＿ｉｄは、アセットをユニークに識別するテキスト情報である。ａｓｓｅｔ＿ｉｄ＿ｌｅｎは、ａｓｓｅｔ＿ｉｄのサイズをバイト単位で示す。ｇｅｎ＿ｌｏｃ＿ｉｎｆｏは、アセットの取得先のロケーションを示す情報である。本実施形態では、ｇｅｎ＿ｌｏｃ＿ｉｎｆｏは、アセットの取得先となる伝送路上のｐａｃｋｅｔ ｉｄの形式で記述される。したがって、ＭＰテーブル上でａｓｓｅｔ＿ｉｄを引いて、ＭＭＴ伝送路上の該当するｐａｃｋｅｔ ＩＤを取り出すことができる。

ａｓｓｅｔ＿ｄｅｓｃｒｉｐｔｏｒのフィールドは、アセットに関わる記述子の格納領域である。ａｓｓｅｔ＿ｄｅｓｃｒｉｐｔｏｒｓ＿ｌｅｎｇｔｈは、ａｓｓｅｔ＿ｄｅｓｃｒｉｐｔｏｒフィールドのサイズＮ５をバイト単位で示す。そして、ａｓｓｅｔ＿ｄｅｓｃｒｉｐｔｏｒは、さまざまな目的の記述子を規定した上で、Ｎ５個（１つ又は複数）配置することを想定している。

Ｍ２セクション・メッセージは、ＭＰＥＧ−２ Ｓｙｓｔｅｍのセクション拡張形式をそのまま伝送するために用いるシグナリング・メッセージである。図１８には、Ｍ２セクション・メッセージ１８００の構成例を示している。以下、Ｍ２セクション・メッセージの各パラメーターの意味について説明する。

ｍｅｓｓａｇｅ＿ｉｄ（メッセージ識別）は、各種シグナリング情報において、Ｍ２セクション・メッセージを識別する１６ビットの固定値であり、本実施形態では０ｘ８０００とする。ｖｅｒｓｉｏｎ（バージョン）は、Ｍ２セクション・メッセージのバージョンを示す、８ビットの整数値のパラメーターである。ｌｅｎｇｔｈ（メッセージ長）は、このフィールドの直後からカウントされる、当該Ｍ２セクション・メッセージのサイズをバイト単位で示す、１６ビット長のパラメーターである。ｔａｂｌｅ＿ｉｄ（テーブル識別）は、当該セクションが属するテーブルの識別のために使用する領域である。ｓｅｃｔｉｏｎ＿ｓｙｎｔａｘ＿ｉｎｄｉｃａｔｏｒ（セクション・シンタクス指示）は、拡張形式を示す‘１’とする。ｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈ（セクション長）は、セクション長領域より後に続くデータのバイト数を書き込む領域である。ｔａｂｌｅ＿ｉｄ＿ｅｘｔｅｎｔｉｏｎ（テーブル識別拡張）は、テーブル識別の拡張を行なう領域である。ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒ（バージョン番号）は、テーブルのバージョン番号を書き込む領域である。ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒ（カレント・ネクスト指示）は、テーブルが現在使用可能である場合は‘１’とし、テーブルが現在使用不可であり次に有効となることを示す場合は‘０’とする。ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒ（セクション番号）は、テーブルを構成するセクション番号を書き込む領域である。ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒ（最終セクション番号）は、テーブルを構成する最後のセクション番号を書き込む領域である。ＣＲＣ３２（ＣＲＣ）、ＩＴＵ−Ｔ勧告Ｈ．２２２．０に従う巡回冗長符号とする。

図１９には、Ｍ２セクション・メッセージで伝送されるＭＨ ＡＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ）テーブル（ＭＨ ＡＩＴ）１９００の構成例を示している。以下、ＭＨ ＡＩテーブルの各パラメーターの意味について説明する。

ｔａｂｌｅ＿ｉｄ（テーブル識別）は、各種シグナリング情報においてアプリケーション情報（ＡＩ）テーブルであることを識別する８ビットの固定値であり、本実施形態では０ｘ８９とする。ｓｅｃｔｉｏｎ＿ｓｙｎｔａｘ＿ｉｎｄｉｃａｔｏｒ（セクション・シンタクス指示）は、１ビットのフィールドで、常に「１」とする。ｓｅｃｔｏｉｎ＿ｌｅｎｇｔｈ（セクション長）は、１２ビットのフィールドで、先頭の２ビットは常に「００」とする。これは、セクション長フィールドからＣＲＣ３２を含むセクションの最後までのセクションのバイト数を規定する。この値は１０２１（１６進数で０ｘ３ＦＤ）を超えないものとする。ａｐｐｌｉｃａｔｏｎ＿ｔｙｐｅ（アプリケーション形式）は、１６ビットのフィールドで、ＡＩＴで伝送しているアプリケーションの値を示す。ＤＶＢでは、ＤＶＢ−Ｊアプリケーションに対して０ｘ０００１が割り当てられている。ＡＲＩＢ−Ｊアプリケーションにおいても０ｘ０００１とする。ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒ（バージョン番号）は、５ビットのフィールドで、サブテーブルのパーション番号である。ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒは、当該ＭＨ ＡＩテーブルのバージョン番号であり、サブテーブル内の情報に変化があった場合に＋１だけインクリメントされる。また、バージョン番号の値が「３１」になったとき、その次は「０」に戻る。ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒ（カレント・ネクスト指示）は、常に「１」とする。ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒ（セクション番号）は、８ビットのフィールドで、セクションの番号を表す。サブテーブル内で最初のセクションのセクション番号は０ｘ００である。セクション番号は、同一のテーブル識別及びアプリケーション形式を持つセクションが追加される度に＋１だけインクリメントされる。ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒ（最終セクション番号）は、８ビットのフィールドであり、そのセクションが属するサブテーブルにおける最後のセクション番号を規定する。

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

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

１つのアプリケーション情報のループ内には、ａｐｐｌｉｃａｔｉｏｎ＿ｉｄｅｎｔｉｆｉｅｒ（アプリケーション識別子）と、ａｐｐｌｉｃａｔｉｏｎ＿ｃｏｎｔｒｏｌ＿ｃｏｄｅ（アプリケーション制御コード）と、ａｐｐｌｉｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒ＿ｌｏｏｐ＿ｌｅｎｇｔｈ（アプリケーション情報記述子ループ長）の数分のループからなる一連の領域に記載されるｄｅｓｃｒｉｐｔｏｒ（アプリケーション情報記述子）が配置される。この記述子領域内の記述子は、指定したアプリケーションのみに適用される。

ａｐｐｌｉｃａｔｉｏｎ＿ｉｄｅｎｔｉｆｉｅｒ（アプリケーション識別子）は、アプリケーションを識別するパラメーターである。ａｐｐｌｉｃａｔｉｏｎ＿ｃｏｎｔｒｏｌ＿ｃｏｄｅ（アプリケーション制御コード）は、８ビットのフィールドで、アプリケーションの状態を制御する制御コードを規定する。このフィールドのセマンティックスは、アプリケーション形式の値に依存する。ａｐｐｌｉｃａｔｉｏｎ＿ｃｏｎｔｒｏｌ＿ｃｏｄｅとして“ａｕｔｏｓｔａｒｔ”が指示されていたら、このＭＨ ＡＴテーブルを参照した受信機は、ａｐｐｌｉｃａｔｉｏｎ＿ｉｄｅｎｔｉｆｉｅｒで指定されたアプリケーションを起動開始する。また、ａｐｐｌｉｃａｔｉｏｎ＿ｃｏｎｔｒｏｌ＿ｃｏｄｅとして“ｐｒｅｆｅｔｃｈ”が指示されていたら、このＭＨ ＡＴテーブルを参照した受信機は、ａｐｐｌｉｃａｔｉｏｎ＿ｉｄｅｎｔｉｆｉｅｒで指定されたアプリケーションを先読みする。また、ａｐｐｌｉｃａｔｉｏｎ＿ｃｏｎｔｒｏｌ＿ｃｏｄｅとして“ｋｉｌｌ”が指示されていたら、このＭＨ ＡＴテーブルを参照した受信機は、ａｐｐｌｉｃａｔｉｏｎ＿ｉｄｅｎｔｉｆｉｅｒで指定されたアプリケーションの実行を停止する。ＣＲＣ３２（ＣＲＣ）、ＩＴＵ−Ｔ勧告Ｈ．２２２．０に従う巡回冗長符号とする。

要するに、ＭＨ ＡＩテーブルは、ＭＭＴ伝送路で送られてくるアプリケーション（ファイル・データ）の処理方法や、伝送方法（ｔｒａｎｓｐｏｒｔ＿ｐｒｏｔｏｃｏｌ）、ロケーション（ＵＲＬ）を指定するテーブルである。受信機は、Ｍ２セクション・メッセージで送られてくるＭＨ ＡＩテーブルを受信すると、ａｐｐｌｉｃａｔｉｏｎ＿ｃｏｎｔｒｏｌ＿ｃｏｄｅで指定された処理を実行するために、指定されたロケーションから指定されたｔｒａｎｓｐｏｒｔ＿ｐｒｏｔｏｃｏｌでアプリケーションを取得する。

図２０には、ＭＨ ＡＩテーブルのアプリケーション情報のループ内に格納される、アプリケーション情報記述子２０００の構成例を示している。また、図２１には、アプリケーション情報記述子２０００に含まれるパラメーターの説明を示している。以下、アプリケーション情報記述子２０００の各パラメーターの意味について説明する。

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

ａｐｐｌｉｃａｔｉｏｎ＿ｐｒｏｆｉｌｅ＿ｌｅｎｇｔｈの数分のループからなる一連の領域には、ａｐｐｌｉｃａｔｉｏｎ＿ｐｒｏｆｉｌｅの情報が書き込まれる。ａｐｐｌｉｃａｔｉｏｎ＿ｐｒｏｆｉｌｅは、本アプリケーションが実行可能である受信機のプロファイルである。受信機に要求する機能毎のビットマップで要求機能を示す。但し上位３ビットは機能ビットマップ切り替えを示す。上記ビットマップはバージョン毎に規定する。また、ｖｅｒｓｉｏｎ＿ｍａｊｏｒ、ｖｅｒｓｉｏｎ＿ｍｉｎｏｒ、ｖｅｒｓｉｏｎ＿ｍｉｃｒｏはそれぞれ、アプリケーション・プロファイル規定のバージョンである。

ｓｅｒｖｉｃｅ＿ｂｏｕｎｄ＿ｆｌａｇは、本アプリケーションが現在のサービスのみで有効かどうかを示すフラグである。ｖｉｓｉｂｉｌｉｔｙは、アプリケーション可視か否かを示す。ａｐｐｌｉｃａｔｉｏｎ＿ｐｒｉｏｒｉｔｙは、このサービス内で告知されているアプリケーション間の相対優先度である。ｔｒａｎｓｐｏｒｔ＿ｐｒｏｔｏｃｏｌ＿ｌａｂｅｌは、アプリケーションを伝送するプロトコルを示す。ｔｒａｎｓｐｏｒｔ＿ｐｒｏｔｏｃｏｌ＿ｌａｂｅｌの値としては、０ｘ０００３はＨＴＴＰ／ＨＴＴＰＳ伝送、０ｘ０００５はＭＭＴ並びにノンタイムド伝送を規定する。

また、図２２には、伝送プロトコル記述子２２００の構成例を示している。以下、伝送プロトコル記述子２２００の各パラメーターの意味について説明する。

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

ｐｒｏｔｏｃｏｌ＿ｉｄ（プロトコルＩＤ）は、アプリケーションを伝送するプロトコルを示す。値としては、０ｘ０００３はＨＴＴＰ／ＨＴＴＰＳ伝送、０ｘ０００５はＭＭＴ並びにノンタイムド伝送を規定する。ｔｒａｎｓｐｏｒｔ＿ｐｒｏｔｏｃｏｌ＿ｌａｂｅｌ（伝送プロトコル・ラベル）は、１つのアプリケーションを複数の経路で伝送する場合にその伝送手段を一意に識別する値であり、アプリケーション情報記述子の同名のフィールドに対応する。ｓｅｌｅｃｔｏｒ＿ｂｙｔｅ（セレクター・バイト）は、プロトコルＩＤ毎にシンタックスが規定される領域であり、取得場所が書き込まれる。

図２３には、ＨＴＴＰ／ＨＴＴＰＳ、ＭＭＴノンタイムド伝送に共通のセレクター・バイト２３００の構成例を示している。

ＵＲＬ＿ｂａｓｅ＿ｂｙｔｅは、ＵＲＬ＿ｂａｓｅ＿ｌｅｎｇｔｈの数分のループからなる一連の領域に、ＵＲＬ文字列のうち、ＵＲＬ＿ｂａｓｅを示すテキスト情報を格納する。

ＵＲＬ＿ｅｘｔｅｎｓｉｏｎ＿ｃｏｕｎｔは、ＵＲＬ＿ｂａｓｅに続くＵＲＬ＿ｅｘｔｅｎｓｉｏｎの数を示し、ＵＲＬ＿ｅｘｔｅｎｓｉｏｎ＿ｃｏｕｎｔの数分だけＵＲＬ＿ｅｘｔｅｎｓｉｏｎのループが配置される。そして、１つのＵＲＬ＿ｅｘｔｅｎｓｉｏｎのループ内では、ＵＲＬ＿ｅｘｔｅｎｔｉｏｎ＿ｂｙｔｅは、ＵＲＬ＿ｅｘｔｅｎｓｉｏｎの長さを規定するＵＲＬ＿ｅｘｔｅｎｓｉｏｎ＿ｌｅｎｇｔｈの数分のループからなる一連の領域に、個々のＵＲＬ＿ｅｘｔｅｎｔｉｏｎを示すテキスト情報を格納する。各ＵＲＬ＿ｅｘｔｅｎｔｉｏｎは、ＵＲＬ＿ｂａｓｅに続くＵＲＬ文字列である。例えば、ＵＲＬ＿ｂａｓｅが“ｈｔｔｐ：／／ｗｗｗ．ｘｂｃ．ｃｏｍ”で、ＵＲＬ＿ｅｘｔｅｎｓｉｏｎが“ｉｎｄｅｘ．ｈｔｍｌ”であれば、これらの文字列を連結して、完全なＵＲＬ“ｈｔｔｐ：／／ｘｂｃ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌ”を得ることができる。

要するに、ＭＨ ＡＩテーブルのアプリケーション情報のループ内のアプリケーション情報記述子並びに伝送プロトコル記述子を参照することで、アプリケーションの伝送手段（ＭＭＴ伝送か、ＨＴＭＬ伝送か）、並びに、ロケーション情報（ＵＲＬ）を取得することができる。

図２４には、シグナリング・メッセージの１つであるデータ・トランスミッション・メッセージ２４００の構成例を示している。以下、データ・トランスミッション・メッセージの各パラメーターの意味について説明する。

ｍｅｓｓａｇｅ＿ｉｄ（メッセージ識別）は、各種シグナリング情報において、データ・トランスミッション・メッセージを識別する１６ビットの固定値であり、本実施形態では０ｘＦ０００とする。ｖｅｒｓｉｏｎ（バージョン）は、データ・トランスミッション・メッセージのバージョン番号を書き込む領域である。ｌｅｎｇｔｈ（メッセージ長）は、このフィールドより後に続く当該メッセージのデータのサイズをバイト単位で示す、３２ビットのパラメーターである。

ｎｕｍ＿ｏｆ＿ｔａｂｌｅｓ（テーブル数）は、このデータ・トランスミッション・メッセージに格納するテーブルの数を示す。データ・トランスミッション・メッセージに格納するテーブルとして、そして、ｎｕｍ＿ｏｆ＿ｔａｂｌｅｓが示す数分だけ、テーブル情報のループが配置される。

１つのテーブ情報のループ内には、テーブル情報として、ｔａｂｌｅ＿ｉｄ（テーブル識別）、ｔａｂｌｅ＿ｖｅｒｓｉｏｎ（テーブル・バージョン）、並びに、ｔａｂｌｅ＿ｌｅｎｇｔｈ（テーブル長）が格納される。ｔａｂｌｅ＿ｉｄ（テーブル識別）は、このデータ・トランスミッション・メッセージに格納するテーブルの識別のための使用する領域である。データ・トランスミッション・メッセージで、データ・ロケーション・マネジメント・テーブル、データ・アセット・マネジメント・テーブル、データ・コンテント・マネジメント・テーブルの３種類のシグナリング・テーブルが伝送されるが（前述）、ｔａｂｌｅ＿ｉｄはこれらのうちいずれのテーブルであるかを識別する。ｔａｂｌｅ＿ｖｅｒｓｉｏｎ（テーブル・バージョン）は、このデータ・トランスミッション・メッセージに格納するテーブルのバージョンを示す。ｔａｂｌｅ＿ｌｅｎｇｔｈ（テーブル長）は、このデータ・トランスミッション・メッセージに格納するテーブルの大きさをバイト単位で示す。ｔａｂｌｅ（テーブル）は、このデータ・トランスミッション・メッセージに格納するテーブルを示す。

また、ｎｕｍ＿ｏｆ＿ｔａｂｌｅｓが示す数分だけ、テーブルのループが配置される。１つのテーブルのループ内には、ｔａｂｌｅ＿ｉｄで識別されるテーブルの中身の情報が格納される。

図２５には、データ・トランスミッション・メッセージで伝送されるデータ・アセット・マネジメント・テーブル２５００の構成例を示している。データ・アセット・マネジメント・テーブルは、ＭＭＴＰパケットとして伝送されるファイル・データのアセットの情報と、ファイル・データの各アセットに含まれるアイテムの情報を管理するテーブルである。以下、このデータ・アセット・マネジメント・テーブルの各パラメーターの意味について説明する。

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

ｎｕｍｂｅｒ＿ｏｆ＿ａｓｓｅｔは、パッケージに含まれるファイル・データのアセットの数を示す、８ビットのパラメーターである。ｎｕｍｂｅｒ＿ｏｆ＿ａｓｓｅｔの数分だけ、以下のＡｓｓｅｔ ｌｏｏｐが配置され、アセット毎のファイル・データの情報が格納される。

１つのＡｓｓｅｔ ｌｏｏｐ内には、ｄｏｗｎｌｏａｄ＿ｉｄと、アセット（ファイル・データ）自体に関する情報と、そのアセットに含まれる各アイテムに関する情報が含まれる。ｄｏｗｎｌｏａｄ＿ｉｄは、ノンタイムド・メディア（ファイル・データ）を伝送するＭＭＴＰパケットの拡張ヘッダーに書き込まれる識別情報である（図７を参照のこと）。

Ａｓｓｅｔ ｌｏｏｐ内に格納されるアセット自体に関する情報として、ａｓｓｅｔ＿ＩＤ＿ｓｃｈｅｍｅ、ａｓｓｅｒ＿ＩＤ＿ｌｅｎｇｔｈ、ａｓｓｅｔ＿ＩＤ＿ｌｅｎｇｔｈと、ａｓｓｅｔ＿ＩＤ＿ｂｙｔｅを含む。ａｓｓｅｔ＿ＩＤ＿ｓｃｈｅｍｅは、アセットＩＤの形式を示す。アセットＩＤの形式として、例えばＵＵＩＤ（Ｕｎｉｖｅｒｓａｌ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｅｒ）、ＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）、ＧＵＲＬ（Ｇｅｎｅｒａｌ ＵＲＬ）を割り当てることができる。ａｓｓｅｒ＿ＩＤ＿ｌｅｎｇｔｈは、アセットＩＤバイトの長さをバイト単位で表す。ａｓｓｅｔ＿ＩＤ＿ｂｙｔｅは、ａｓｓｅｒ＿ＩＤ＿ｌｅｎｇｔｈの数分のループからなる一連の領域に、ａｓｓｅｔ＿ＩＤ＿ｓｃｈｅｍｅで指定された形式で、アセットＩＤを示す。ちなみに、この情報は、本実施形態では、ＭＰテーブル、データ・アセットマネジメント・テーブル共通にアセットを識別する情報として用いられるが、データ量が大きいので他の代用可能なアセット識別情報を用いてもよい。例えば、ＭＰテーブルにおいてａｓｓｅｔ＿ＩＤに対応する情報として１６ビットのｃｏｍｐｏｎｅｎｔ＿ｔａｇを定義し、データ・アセット・マネジメント・テーブルにおいてはａｓｓｅｔ＿ＩＤの代わりにｃｏｍｐｏｎｅｎｔ＿ｔａｇを利用することが想定される。

ｎｕｍｂｅｒ＿ｏｆ＿ｉｔｅｍｓは、該当するファイル・データのアセットを構成するアイテムの数を書き込む領域である。そして、ｎｕｍｂｅｒ＿ｏｆ＿ｉｔｅｍｓの数分だけアイテムのループが配置され、アセット（ファイル・データ）を構成する各アイテムに関する情報が書き込まれる。

１つのアイテムのループ内には、アイテムに関する情報として、ｉｔｅｍ＿ＩＤ、ｉｔｅｍ＿ｔａｇ、ｉｔｅｍ＿ｓｉｚｅ、ｉｔｅｍ＿ｖｅｒｓｉｏｎ、ｉｔｅｍ＿ｃｈｅｃｋｓｕｍ、ｉｔｅｍ＿ｉｎｆｏの各パラメーターが記述される。ｉｔｅｍ＿ＩＤは、ノンタイムドＭＦＵで伝送されるアイテムを識別するＩＤを示す３２ビットの値である。ｉｔｅｍ＿ｔａｇは、同様にアイテムを識別する情報であり、１６ビットの値である。シグナリング情報としては、３２ビットのｉｔｅｍ＿ＩＤに代えて１６ビットのｉｔｅｍ＿ｔａｇを使用することで、アイテムの識別に必要なビット・サイズを削減することができる。ｉｔｅｍ＿ｓｉｚｅは、アイテムのサイズをバイト単位で表す。ｉｔｅｍ＿ｖｅｒｓｉｏｎは、アイテムのバージョンを示し、アイテムの内容が更新される度にｖｅｒｓｉｏｎは＋１だけインクリメントされる。ｉｔｅｍ＿ｃｈｅｃｋｓｕｍは、アイテムのチェックサムを示す。なお、チェックサムは、すべてのファイルに対して必ず設定するのは情報量が多いと考えられる。よって、そのような考慮により、例えば１ビットのｃｈｅｃｋ＿ｓｕｍ＿ｆｌａｇを設定し、これに１が代入された場合にのみ３２ビットのｉｔｅｍ＿ｃｈｅｃｋ＿ｓｕｍが現れるようにしてもよい。あるいは、シグナリングではなく、図７に示したＭＭＴＰパケットの拡張ヘッダーとしてｔｙｐｅとしてチェックサムを示し、ｌｅｎｇｔｈの後に３２ビットのチェックサムを配置してもよい。ｉｔｅｍ＿ｉｎｆｏ＿ｌｅｎｇｔｈは、ｉｔｅｍ＿ｉｎｆｏ＿ｂｙｔｅの情報領域のサイズをバイト単位で表す。そして、ｉｔｅｍ＿ｉｎｆｏ＿ｂｙｔｅは、ｉｔｅｍ＿ｉｎｆｏ＿ｌｅｎｇｔｈの数分のループからなる一連の領域に、当該アイテムに関する情報を格納する。

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

要するに、データ・アセット・マネジメント・テーブル２５００は、１つのパッケージに含まれるファイル・データ（コンテント）のアセット並びにアセットに含まれるアイテムに関する情報を管理するテーブルである。アイテムに関する情報として、アイテムのバージョン情報も管理する。データ・アセット・マネジメント・テーブル２５００を参照して、ｉｔｅｍ＿ｔａｇ（若しくは、Ｉｔｅｍ＿ＩＤ）から該当するａｓｓｅｔ＿ｉｄやアセットを伝送するＭＭＴ拡張ヘッダーに記載されたｄｏｗｎｌｏａｄＩＤやｉｔｅｍ＿ｉｎｆｏを引いたり、シグナリング情報の伝送路上で扱うｉｔｅｍ＿ｔａｇからファイル・データの伝送路上のｉｔｅｍ＿ＩＤやｉｔｅｍ＿ｉｎｆｏを引いたりすることができる。

図２６には、データ・トランスミッション・メッセージで伝送されるデータ・ロケーション・マネジメント・テーブル（ＤＬＭＴ）２６００の構成例を示している。データ・ロケーション・マネジメント・テーブルは、ＭＭＴＰパケットとして伝送される各ファイル・データのロケーション情報と、ファイル・データに含まれる各アイテムのロケーション情報を管理するテーブルである。以下、このデータ・ロケーション・マネジメント・テーブルの各パラメーターの意味について説明する。

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

ｂａｓｅ＿ＵＲＬ＿ｌｅｎｇｔｈは、ｂａｓｅ＿ＵＲＬ＿ｂｙｔｅの情報領域のサイズをバイト単位で表す。ｂａｓｅ＿ＵＲＬ＿ｂｙｔｅは、ｂａｓｅ＿ＵＲＬ＿ｌｅｎｇｔｈの数分のループからなる一連の領域に、ファイル・データの絶対的なＵＲＬ形式で表記されたロケーション情報を格納する。

ｎｕｍｂｅｒ＿ｏｆ＿ｉｔｅｍｓは、ファイル・データに含まれるアイテムの数を書き込む領域である。そして、ｎｕｍｂｅｒ＿ｏｆ＿ｉｔｅｍｓの数分だけアイテムのループが配置される。

１つのアイテムのループ内には、ファイル・データに含まれる各アイテムについての、ｉｔｅｍ＿ｔａｇ、ｉｔｅｍ＿ＵＲＩ＿ｂｙｔｅが書き込まれる。ｉｔｅｍ＿ｔａｇは、ノンタイムドＭＦＵで伝送されるアイテムを識別する情報を、３２ビットのｉｔｅｍ＿ＩＤ（前述）よりも短い１６ビットで表す。ｉｔｅｍ＿ＵＲＩ＿ｂｙｔｅは、ｎｕｍｂｅｒ＿ｏｆ＿ｉｔｅｍ＿ＵＲＩ＿ｂｙｔｅの数分のループからなる一連の領域に、ファイル・データのベースとなるロケーション情報すなわちｂａｓｅ＿ＵＲＬ＿ｂｙｔｅに対する相対的なＵＲＬ形式で表記されたロケーション情報を格納する。例えば、コンテントのｂａｓｅ＿ＵＲＬが“ｈｔｔｐ：／／ｗｗｗ．ｘｂｃ．ｃｏｍ”で、あるアイテムのｉｔｅｍ＿ＵＲＬが“ｉｎｄｅｘ．ｈｔｍｌ”であれば、これらの文字列を連結して、完全なＵＲＬ“ｈｔｔｐ：／／ｘｂｃ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌ”を得ることができる。

要するに、データ・ロケーション・マネジメント・テーブル２６００は、１つのパッケージに含まれるファイル・データ（コンテント）並びにファイル・データに含まれるアイテムに関するロケーション情報を管理するテーブルである。データ・ロケーション・マネジメント・テーブル２６００を参照して、ｉｔｅｍ＿ｔａｇからそのアイテムのＵＲＬを引いたり、逆にＵＲＬから該当するｉｔｅｍ＿ｔａｇを引いたりすることができる。なお、ｂａｓｅ＿ＵＲＬで示されるロケーション（ディレクトリー）の下にさらに複雑なディレクトリー構造を設定したい場合には、本構成例ではｉｔｅｍ＿ＵＲＩ＿ｂｙｔｅの情報量が大きくなり過ぎる可能性がある。これを考慮すると、データ・ロケーション・マネジメント・テーブルにおいて、ファイルが存在するディレクトリーのロケーション情報をｎｏｄｅ＿ＵＲＬとして設定すると共に各ディレクトリーをｎｏｄｅ＿ｔａｇとして識別情報を与え、アイテム毎の情報としてはファイル名とｎｏｄｅ＿ｔａｇのみを指定するような構成としてもよい。

また、図２７には、データ・トランスミッション・メッセージで伝送されるデータ・コンテント・マネジメント・テーブル（ＤＣＭＴ）２７００の構成例を示している。データ・コンテント・マネジメント・テーブルは、ノンタイムド・メディアとして伝送されるファイル・データすなわちコンテント（データ放送アプリケーション）の情報を管理するテーブルである。以下、このデータ・コンテント・マネジメント・テーブルの各パラメーターの意味について説明する。

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

ｎｕｍｂｅｒ＿ｏｆ＿ｃｏｎｔｅｎｔは、パッケージに含まれるコンテントの数を示す、８ビットのパラメーターである（コンテントは、例えば、データ放送アプリケーションを記述したＨＴＭＬ文書などのファイル・データである）。ｎｕｍｂｅｒ＿ｏｆ＿ｃｏｎｔｅｎｔの数分だけ、以下のコンテントのループが配置され、コンテント毎の情報が格納される。

１つのコンテントのループ内には、コンテントに関する情報として、ｃｏｎｔｅｎｔ＿ＩＤと、ｃｏｎｔｅｎｔ＿ｖｅｒｓｉｏｎと、ｃｏｎｔｅｎｔ＿ｃａｃｈｅ＿ｓｉｚｅと、当該コンテントに含まれるアプリケーション提示単位（Ｐｒｅｓｅｎｔａｔｉｏｎ Ｕｎｉｔ：ＰＵ）に関する情報が書き込まれる。ｃｏｎｔｅｎｔ＿ＩＤは、コンテントの識別情報である。ｃｏｎｔｅｎｔ＿ｖｅｒｓｉｏｎは、コンテントのバージョンを示す。ｃｏｎｔｅｎｔ＿ｃａｃｈｅ＿ｓｉｚｅは、コンテントをキャッシュするサイズを示す。

ｎｕｍｂｅｒ＿ｏｆ＿ＰＵは、コンテントに含まれるアプリケーション提示単位ＰＵの数であり、ｎｕｍｂｅｒ＿ｏｆ＿ＰＵの数分だけＰＵのループが配置される。

１つのＰＵのループ内には、ＰＵの識別情報であるＰＵ＿ｔａｇと、ＰＵをキャッシュするサイズを示すＰＵ＿ｃａｃｈｅ＿ｓｉｚｅが書き込まれる。また、ＰＵのループ内には、該当するＰＵに含まれるアイテムの数を示すｎｕｍｂｅｒ＿ｏｆ＿ｉｔｅｍｓと、ｎｕｍｂｅｒ＿ｏｆ＿ｉｔｅｍｓの数分だけのアイテムのループが配置される。１つのアイテムのループ内には、アイテムのｉｔｅｍ＿ｔａｇが書き込まれる。

また、１つのＰＵのループ内には、このＰＵからリンクされる他のＰＵの数を示すｎｕｍｂｅｒ＿ｏｆ＿ｌｉｎｋｅｄ＿ＰＵと、ｎｕｍｂｅｒ＿ｏｆ＿ｌｉｎｋｅｄ＿ＰＵの数分だけのｌｉｎｋｅｄ＿ＰＵのループが配置される。１つのｌｉｎｋｅｄ＿ＰＵのループ内では、ｌｉｎｋｅｄ＿ＰＵの識別情報であるｌｉｎｋｅｄ＿ＰＵ＿ｔａｇが書き込まれる。

要するに、データ・コンテント・マネジメント・テーブル２７００は、１つのパッケージで各コンテント（データ放送アプリケーション）をアプリケーション提示単位（ＰＵ）で管理するテーブルである。データ・コンテント・マネジメント・テーブル２７００を参照して、ｉｔｅｍ＿ｔａｇから、そのアイテムを含むアプリケーション提示単位ＰＵ＿ｔａｇを取得することができる。なお、本構成例では、データ・コンテント、ＰＵ、アイテムという階層構造としたが、キャッシュを利用したアプリケーション以外の一般的なデータ・コンテントを想定した場合には、データ・コンテント、アイテムという２階層にした上で、アイテム毎の情報としてＰＵ＿ｔａｇを指定できるようにしてもよい。また、データ・コンテント・マネジメント・テーブルを利用しないで、同様の情報をデータ・アセット・マネジメント・テーブルに設定する方法も考えられる。その場合、図２５に示すデータ・アセット・マネジメント・テーブルのｉｔｅｍ＿ｉｎｆｏ（）に配置可能な記述子により同等の情報を表現する。具体的には、例えばデータ・マネジメント記述子としてアイテムが属するべき１つ又は複数のｃｏｎｔｅｎｔ＿ＩＤ及びＰＵ＿ｔａｇを指定できるようにする。

図２８には、ＭＭＴ伝送されるデータ放送アプリケーション（コンテント）の伝送、コンテントのロケーションと、アプリケーションの提示を行なう仕組みを図解している。

図２８（Ａ）には、コンテントのディレクトリー構造を示している。各コンテントｃｏｎｔｅｎｔ１、２、…は、アプリケーション（ａｐｐ）とマテリアルで構成される。アプリケーションやマテリアルは、それぞれファイル・データが実体であるリソースである。各リソースは、ＭＭＴ伝送路上ではアセットの構成要素であるアイテムに相当し、ｉｔｅｍ＿ＩＤで識別することができる。図２８（Ｃ）に示すように、各リソースは、該当するアセットのＭＭＴ伝送路上でアイテムとして伝送される（後述）。アプリケーションは、コンテントの実行時（アプリケーションの提示時）において参照される１以上のＨＴＭＬ文書からなる。また、マテリアルは、ＨＴＭＬ文書から参照されるｊｐｅｇ画像やその他のタイプのモノメディア・データなどである。１つのＨＴＭＬ文書と、そこから参照されるマテリアルで、１つのアプリケーション提示単位ＰＵを構成する。図２８（Ａ）に示す例では、ｃｏｎｔｅｎｔ１は、Ａ１１．ｈｔｍｌ、Ａ１２．ｈｔｍｌ、Ａ１３．ｈｔｍｌなどの１以上のＨＴＭＬ文書をアプリケーションのリソースとして持つ。このうち、Ａ１１．ｈｔｍｌは、コンテントの実行時に直接参照されるリソースとする。

図２８（Ｂ）には、コンテントの実行時（アプリケーションの提示時）におけるリソース間の参照関係を示している。図示の例では、コンテントの実行時に直接参照されるアプリケーションＡ１１とこれが参照するマテリアルＢ１１、Ｂ０２が１つのアプリケーション提示単位ＰＵを構成するリソース・グループ２８０１であり、ＰＵ＿ｔａｇとしてｐ１が割り当てられている（なお、Ｂ１４は、放送によりＭＭＴ伝送されるのではなく通信によるＨＴＴＰ伝送で随時取得することができるマテリアルであり、以下では、アプリケーション提示単位のリソース・グループには含まないものとして扱う）。

同様に、アプリケーションＡ１２とこれが参照するマテリアルＢ１２、Ｂ０２、Ｂ１３が１つのアプリケーション提示単位ＰＵを構成するリソース・グループ２８０２であり、ＰＵ＿ｔａｇとしてｐ２が割り当てられている（なお、Ｂ０７は、放送によりＭＭＴ伝送されるのではなく通信によるＨＴＴＰ伝送で随時取得することができるマテリアルであり、以下では、アプリケーション提示単位のリソース・グループには含まないものとして扱う）。同様に、アプリケーションＡ０１とこれが参照するマテリアルＢ０３、Ｂ０１、Ｂ０４が１つのアプリケーション提示単位ＰＵを構成するリソース・グループ２８０３であり、ＰＵ＿ｔａｇとしてｐ３が割り当てられている。

また、複数のＨＴＭＬ文書間でリンク参照関係を持つことができる（周知）。図２８（Ｂ）に示す例では、リソースＡ０１．ｈｔｍｌは、コンテントの実行時に直接参照され、最初に表示されるアプリケーション提示画面を記述するＨＴＭＬ文書である。これに対し、同じｃｏｎｔｅｎｔ１に含まれリソースＡ１２．ｈｔｍｌと、ｃｏｎｔｅｎｔ１外のｃｏｍｍｏｎに含まれるリソースＡ０１．ｈｔｍｌは、Ａ０１．ｈｔｍｌを実行して提示される画面から遷移するアプリケーション提示画面を記述するＨＴＭＬ文書であり、Ａ１１．ｈｔｍｌとリンク参照関係を持つ。各リソースＡ０１．ｈｔｍｌ、Ａ１２．ｈｔｍｌ、Ａ０１．ｈｔｍｌは、それぞれ１つのアプリケーション提示単位ＰＵを構成するリソース・グループ２８０１、２８０２、２８０３を形成する。そして、リンクし合うアプリケーション提示単位２８０１、２８０２、２８０３同士で、さらに上位の大きなリソース・グループ２８１０を構成する。

また、パッケージ（１つの放送番組）に含まれるアプリケーション全体となるさらにコンテント全体で大きなリソース・グループすなわちデータ・コンテント全体を構成する。データ・コンテント全体とは、共通のｃｏｎｔｅｎｔ＿ＩＤを持つアプリケーション提示単位ＰＵの範囲であり、データ・コンテント・マネジメントテーブルで、該当するｃｏｎｔｅｎｔ＿ＩＤのＰＵのループを回すことにより、コンテントに含まれるすべてのアプリケーション提示単位ＰＵを一括して特定することができる。図２８（Ｂ）に示す例では、ｃｏｎｔｅｎｔ１とｃｏｍｍｏｎに含まれるアプリケーションでコンテント全体のリソース・グループ２８２０を形成している。

図２８（Ｃ）には、コンテントをＭＭＴ伝送する様子を模式的に示している。コンテントの構成要素であるアプリケーションやマテリアルは、それぞれファイル・データが実体であり、「リソース」とも呼ぶ。各リソースは、ＭＭＴ伝送路上ではアセットの構成要素であるアイテムに相当する。ＭＭＴ伝送では、パッケージに含まれる各コンテントは１つのアセットとして扱われ、それぞれＡｓｓｅｔ＿ＩＤが割り当てられる。図示の例では、ｃｏｎｔｅｎｔ１にはａｓｓｅｔ＿ＩＤとしてａ１が割り当てられている。また、ＭＭＴ伝送では、ＨＴＭＬ文書データやマテリアルなどの個々のリソースは、１つのアイテムとして扱われ、それぞれＩｔｅｍ＿ＩＤが割り当てられる。図示の例では、ｃｏｎｔｅｎｔ１に含まれる各リソースには、それぞれＩｔｅｍ＿ＩＤとしてｉ１１、ｉ１２、ｉ１３、ｉ１４が割り当てられている。

また、同じコンテントに含まれるリソースは同じａｓｓｅｔ＿ＩＤを共有し、同じＭＭＴ伝送路上で伝送される。図２８（Ｃ）に示す例では、Ｉｔｅｍ＿ＩＤがｉ１１、ｉ１２、ｉ１３、ｉ１４の各アイテムは、同じＡｓｓｅｔ＿ＩＤとしてａ１を共有しており、同じＭＭＴ伝送路上で伝送される。前述したデータ・ロケーション・マネジメント・テーブルは図２８（Ａ）で表現され、データ・コンテント・マネジメント・テーブルは図２８（Ｂ）で表現され、データ・アセット・マネジメント・テーブルは図２８（Ｃ）で表現され、これらの間をｉｔｅｍ＿ＩＤにより関係付けられることになる。

ＭＭＴ伝送路からデータ放送アプリケーション（コンテント）を取得する際の、シグナリング情報として伝送される各テーブルの参照関係について、図２９を参照しながら説明する。

受信機は、Ｍ２セクション・メッセージで、ＭＨ−ＡＩテーブル（ＭＨ ＡＩＴ）２９０１を取得すると、ａｐｐｌｉｃａｔｉｏｎ＿ｃｏｎｔｒｏｌ＿ｃｏｄｅを参照して、アプリケーションの状態がどのように制御されているかを確認する。そして、“ａｕｔｏｓｔａｒｔ”が指示されている場合には、テーブル内のｔｒａｎｓｐｏｒｔ＿ｐｒｏｔｏｃｏｌ＿ｌａｂｅｌを参照して、ＭＭＴ伝送が指定されていることを確認すると、このアプリケーションの提示時に直接参照されるアイテム（ファイル・データ）のＵＲＬ情報を伝送プロトコル記述子から取り出す。そして、受信機は、データ・トランスミッション・メッセージで送られてくるデータ・ロケーション・マネジメント・テーブル（ＤＬＭＴ）２９０２を参照して、そのｂａｓｅ＿ＵＲＬ及びｉｔｅｍ＿ＵＲＬの組み合わせに対応するアイテムのＩｔｅｍ＿ｔａｇを取得することができる。

次いで、受信機は、データ・トランスミッション・メッセージで送られてくるデータ・アセット・マネジメント・テーブル（ＤＡＭＴ）２９０３を参照して、取得したｉｔｅｍ＿ｔａｇをＭＭＴ伝送路上のｉｔｅｍ＿ＩＤに戻すとともに、対応するアセットを特定して、そのａｓｓｅｔ＿ＩＤとｄｏｗｎｌｏａｄ＿ｉｄを取得する。

そして、受信機は、ＰＡメッセージで送られてくるＭＰテーブル（ＭＰＴ）２９０４を参照して、取得したａｓｓｅｔ＿ＩＤに対応するｐａｃｋｅｔ＿ｉｄを取得すると、ファイル・データのＭＭＴ伝送路上で、ＭＭＴＰパケットのヘッダー内のｐａｃｋｅｔ＿ｉｄと、拡張ヘッダー内のｄｏｗｎｌｏａｄ＿ｉｄと、ＤＵヘッダー内のｉｔｅｍ＿ＩＤに基づいてフィルタリングして、所望する（アプリケーションの提示時に直接参照する）アイテムを取得することができる。

また、受信機は、データ・トランスミッション・メッセージで送られてくるデータ・コンテント・マネジメント・テーブル（ＤＣＭＴ）２９０５内で、データ・ロケーション・マネジメント・テーブル２９０２から取得したｉｔｅｍ＿ｔａｇを引いて、該当するアプリケーション提示単位のＰＵ＿ｔａｇを取り出すことができる。また、このＰＵ＿ｔａｇのＰＵのループ内でｌｉｎｋｅｄ＿ＰＵのループを回すことにより、これにリンクする他のアプリケーション提示単位のＰＵ＿ｔａｇを一括して取り出すことができる。

トランスポート方式としてＭＭＴを採用するディジタル放送システムにおいて、ＨＭＴＬ文書データのようなアプリケーションをノンタイムド・メディアとして伝送する場合、受信機側で、アプリケーション本体並びに参照されているモノメディア・ファイルを放送（ＭＭＴ伝送）と通信（ＨＴＴＰ伝送）の両方の経路で取得することが想定される。

受信機において、アプリケーションを実行する場合に迅速な応答を可能とするためには（例えば、リモコンでｄボタンが押されてデータ放送を画面に表示する場合や画面を遷移する場合）、あらかじめ必要なリソース（アイテム、ファイル・データ）を受信し、キャッシュしておくことが好ましい。通信で取得可能なファイル・データはほぼ瞬時に取得することができる。一方、放送ストリームではファイル・データは繰り返し送られてくるが、使用可能な帯域が制限されている場合などでは、アプリケーションの実行が指示されてから次にファイル・データが届くまでの時間が長くなり迅速に応答できないおそれがある。このため、放送ストリームで取得するファイル・データに関しては、とりわけ事前にキャッシュしておく必要があると考えられる。

そこで、本明細書で開示する技術では、放送送出システム側からは、アプリケーションを構成するリソース（アイテム）を、放送並びに通信の任意のロケーションから取得可能となるように、アプリケーションにおいてロケーションを示すＵＲＬを放送などのＭＭＴ伝送路上のロケーションにマッピングする情報と、アプリケーションにおける表示単位とリンク関係を示す情報を伝送するようにしている。

図１９〜図２３を参照しながら説明したように、ＭＨ ＡＩテーブルには、アプリケーションの伝送方法（ｔｒａｎｓｐｏｒｔ＿ｐｒｏｔｏｃｏｌ＿ｌａｂｅｌ）とロケーションを示すＵＲＬ情報が記載される。一方、図２６などを参照しながら説明したように、データ・ロケーション・マネジメント・テーブルには、アプリケーションにおいてロケーションを示すＵＲＬとデータ・トランスミッション・メッセージ上のｉｔｅｍ＿ｔａｇとの対応関係が記述され、図２５などを参照しながら説明したように、データ・アセット・マネジメント・テーブルには、ｉｔｅｍ＿ｔａｇと、そのアイテムを含むアセットのａｓｓｅｔ＿ＩＤ、そのアセットのＭＭＴ伝送路上のＭＭＴＰパケットのｄｏｗｎｌｏａｄ＿ｉｄ及びｉｔｅｍ＿ＩＤとの対応関係が記載され、図１６などを参照しながら説明したように、ＭＰテーブルでａｓｓｅｔ＿ＩＤを引くことにより、ＭＭＴ伝送路上でそのアセットを伝送するパケットのｐａｃｋｅｔ＿ｉｄを取得することができる。したがって、本実施形態では、放送送出システムは、シグナリング・メッセージで伝送されるＭＨ ＡＩテーブル、データ・ロケーション・マネジメント・テーブル、データ・アセット・マネジメント・テーブル、及びＭＰテーブルを用いて、アプリケーションにおいてロケーションを示すＵＲＬを放送などのＭＭＴ伝送路上のロケーションにマッピングする情報を伝送することができる。

また、図２７などを参照しながら説明したように、データ・コンテント・マネジメント・テーブルには、パッケージに含まれる各コンテントについて、アプリケーション提示単位の情報を管理する。具体的には、データ・コンテント・マネジメント・テーブルは、コンテントに含まれるアプリケーション提示単位のＰＵ＿ｉｄ、アプリケーション提示単位に含まれるすべてのアイテムのｉｔｅｍ＿ｔａｇと、これにリンクする他のアプリケーション提示単位のＰＵ＿ｉｄ（ｌｉｎｋｅｄ＿ＰＵ＿ｉｄ）を記載する。また、図２５に示したように、データ・アセット・マネジメント・テーブルは、アセットに含まれるすべてのアイテムのサイズ（ｉｔｅｍ＿ｓｉｚｅ）をｉｔｅｍ＿ｔａｇと対応付けて管理する。したがって、本実施形態では、放送送出システムは、データ・アセット・マネジメント・テーブルとデータ・コンテント・マネジメント・テーブルを用いて、アプリケーションにおける表示単位とリンク関係を示す情報を伝送することができる。

また、本実施形態では、データ・アセット・マネジメント・テーブルでパッケージ内のアプリケーション（ファイル・データ）のアセット並びにアセットに含まれるアイテムに関する情報を管理し、データ・ロケーション・マネジメント・テーブルでパッケージ内のコンテント並びにコンテントに含まれるアイテムに関するロケーション情報を管理し、データ・コンテント・マネジメント・テーブルによりアプリケーション提示単位でコンテントに含まれるアイテム（リソース）を管理する仕組みを採り入れている。

したがって、本実施形態では、アプリケーションのオーサリング時におけるディレクトリー構成の自由度と、また、アプリケーションを構成する任意のファイルを放送（ＭＭＴ伝送）と通信（ＨＴＴＰ伝送）の伝送路に切り分ける自由度と、アプリケーション実行時におけるアプリケーション提示単位でリンク関係の自由度を確保するアプリケーション伝送方式を提供することができる。

また、本実施形態では、図２８（Ｂ）などを参照しながら説明したように、以下の４通りのアクセス範囲（ａ）〜（ｂ）で、コンテントへのアクセス範囲に関するロケーション情報とサイズを階層的な情報として与えることができる。

（ａ）アプリケーション実行時に直接参照するリソース（例えば、図２８（Ｂ）中のＡ１１．ｈｔｍｌ）
（ｂ）同時に表示するアプリケーション提示単位を構成するリソース・グループ（例えば、図２８（Ｂ）中の参照番号２８０１、２８０２、２８０３、２８０４で示す各リソース・グループ）
（ｃ）同時に表示するアプリケーション提示単位を構成するリソース・グループと、これにリンクする他のアプリケーション提示単位を含む大きなリソース・グループ（図２８（Ｂ）中の参照番号２８１０で示すリソース・グループ）
（ｄ）アプリケーション全体のリソース・グループ（図２８（Ｂ）中の参照番号２８２０で示すリソース・グループ）

したがって、受信機側では、シグナリング・メッセージで伝送される上記の各テーブルに基づいて、キャッシュの空き容量に応じたいずれかのアクセス範囲（ａ）〜（ｄ）と各々のサイズを把握することができ、アプリケーションの効果的な事前キャッシュを行なうことが可能になる。

図３０には、受信機内で、データ放送アプリケーション・エンジンが処理するアプリケーションを事前キャッシュする仕組みを模式的に示している。

図４では図示を省略したが、受信機は、放送信号でＭＭＴ伝送されるデータ放送アプリケーションのコンテントを事前キャッシュするコンテント・キャッシュ３００１を備えている。あるいは、コンテント・キャッシュ３００１は、データ放送アプリケーション・エンジン４０７の内部に配置されていてもよい。

システム制御部４０８は、デマルチプレクサー４０２で放送ストリームからデマルチプレクスされたシグナリング・メッセージを解析して、受信機内の動作を制御する。コンテントの事前キャッシュに関しては、システム制御部４０８は、コンテント・キャッシュ３００１の空き容量を把握して、可能な限りより大きなアクセス範囲でファイル・データをキャッシュする。

具体的には、システム制御部４０８は、Ｍ２セクション・メッセージで伝送されるＭＨ ＡＩテーブルで指定されたエントリーのアイテム（ファイル・データ、ＨＴＭＬ文書データ）のＵＲＬを、データ・トランスミッション・メッセージで伝送されるデータ・ロケーション・マネジメント・テーブルで引いて、参照されたアイテムのｉｔｅｍ＿ｔａｇを取得する。データ・アセット・マネジメント・テーブル及びＭＰテーブルを用いて、ｉｔｅｍ＿ｔａｇから該当するＭＭＴＰパケットを特定できることは既に述べた通りである。

次いで、システム制御部４０８は、データ・トランスミッション・メッセージで伝送されるデータ・コンテント・マネジメント・テーブルでｉｔｅｍ＿ｔａｇを引いて、参照されたアイテムが属するアプリケーション提示単位ＰＵとそのサイズ（ＰＵ＿ｃａｃｈｅ＿ｓｉｚｅ）を取得し、さらにそのアプリケーション提示単位とリンクする他のアプリケーション提示単位（ｌｉｎｋｅｄ＿ＰＵ）並びにそのサイズ、アイテムが属すコンテント（ｃｏｎｔｅｎｔ＿ＩＤ）とそのサイズ（ｃｏｎｔｅｎｔ＿ｃａｃｈｅ＿ｓｉｚｅ）を取得する。すなわち、システム制御部４０８は、以下の４通りのアクセス範囲（ａ）〜（ｄ）に関するサイズを階層的な情報として把握する。

（ａ）ＭＨ ＡＩテーブルで直接参照したアイテム（例えば、図２８（Ｂ）中のＡ１１．ｈｔｍｌ）
（ｂ）参照したアイテムが属するアプリケーション提示単位（例えば、図２８（Ｂ）中の参照番号２８０１）
（ｃ）参照したアイテムが属するアプリケーション提示単位と、これにリンクする他のアプリケーション提示単位（例えば、図２８（Ｂ）中の参照番号２８１０）
（ｄ）コンテント（ｃｏｎｔｅｎｔ＿ＩＤの範囲）全体（例えば、図２８（Ｂ）中の参照番号２８２０）

そして、システム制御部４０８は、コンテント・キャッシュ３００１の空き容量に基づいて、（ａ）〜（ｄ）のうちいずれのアクセス範囲でアイテムのキャッシュを行なうかを決定する。

システム制御部４０８は、キャッシュしたいアイテムのｉｔｅｍ＿ｔａｇを、データ・トランスミッション・メッセージで伝送されるデータ・アセット・マネジメント・テーブルで引いて、そのアイテムが属するアセットのａｓｓｅｔ＿ＩＤを取得し、次いで、ａｓｓｅｔ＿ＩＤをＰＡメッセージで伝送されるＭＰテーブルで引いて、アセットが伝送されるＭＭＴＰパケットのｐａｃｋｅｔ＿ｉｄを取得する。また、システム制御部４０８は、データ・アセット・マネジメント・テーブルから、所望するアイテムを伝送するＭＭＴＰパケットの拡張ヘッダーに記載されるｄｏｗｎｌｏａｄ＿ｉｄを取得すると、ファイル・データのＭＭＴ伝送路上で、ＭＭＴＰパケットのヘッダー内のｐａｃｋｅｔ＿ｉｄと、拡張ヘッダー内のｄｏｗｎｌｏａｄ＿ｉｄと、ＤＵヘッダー内のｉｔｅｍ＿ＩＤに基づいてフィルタリングして、所望するアイテムのエンティティーを取得して、コンテント・キャッシュ３００１にキャッシュする。

また、アクセス範囲（ｂ）、すなわち、参照したアイテムが属するアプリケーション提示単位でキャッシュしたいときには、システム制御部４０８は、データ・コンテント・マネジメント・テーブルでそのアイテムが属するアプリケーション提示単位ＰＵを特定すると、このＰＵ＿ｔａｇのＰＵのループ内でｉｔｅｍのループを回すことにより、同じアプリケーション提示単位ＰＵに含まれるすべてのアイテムのｉｔｅｍ＿ｔａｇを一括して取得する。そして、各アイテムのエンティティーを、ｉｔｅｍ＿ｔａｇを基に上述した手順に従って取得して、逐次コンテント・キャッシュ３００１にキャッシュする。

また、アクセス範囲（ｃ）、すなわち、参照したアイテムが属するアプリケーション提示単位と、これにリンクする他のアプリケーション提示単位でキャッシュしたいときには、システム制御部４０８は、データ・コンテント・マネジメント・テーブルでそのアイテムが属するアプリケーション提示単位ＰＵのループ内で、ｌｉｎｋｅｄ＿ＰＵのループを回すことにより、参照したアイテムが属するアプリケーション提示単位にリンクされたすべてのアプリケーション提示単位ＰＵのＰＵ＿ｔａｇを一括して取得する。そして、上述した手順に従って、各ｌｉｎｋｅｄ＿ＰＵに含まれるに含まれるすべてのアイテムのｉｔｅｍ＿ｔａｇを一括して取得する。そして、各アイテムのエンティティーを、ｉｔｅｍ＿ｔａｇを基に上述した手順に従って取得して、逐次コンテント・キャッシュ３００１にキャッシュする。

また、アクセス範囲（ｄ）、すなわち、コンテント（ｃｏｎｔｅｎｔ＿ＩＤの範囲）全体でキャッシュしたいときには、システム制御部４０８は、システム制御部４０８は、データ・コンテント・マネジメント・テーブルでそのアイテムが属するコンテントのｃｏｎｔｅｎｔ＿ＩＤを特定すると、このｃｏｎｔｅｎｔ＿ｉｄのループ内でＰＵのループを回すことにより、そのコンテントに含まれるすべてのアプリケーション提示単位ＰＵのＰＵ＿ｔａｇを一括して取得する。そして、各アイテムのエンティティーを、ｉｔｅｍ＿ｔａｇを基に上述した手順に従って取得して、逐次コンテント・キャッシュ３００１にキャッシュする。

データ放送アプリケーション・エンジン４０７は、アプリケーションを実行する際、必要なアイテム（ファイル・データ）が既にコンテント・キャッシュ３００１に事前にキャッシュされていれば、デマルチプレクサー４０２で放送ストリームからデマルチプレクスされたファイル・データが届くのを待つことなく、コンテント・キャッシュ３００１から取り出して、迅速に応答して、データ放送用表示信号を生成することができる。

一方、必要なアイテムがコンテント・キャッシュ３００１内に存在しないときには、データ放送アプリケーション・エンジン４０７は、放送ストリームからデマルチプレクスされたファイル・データが届くのを待って応答して、データ放送用表示信号を生成する。

図３１には、受信機において、放送ストリームからアプリケーションを取得して起動する動作を図解している。

システム制御部４０８は、ＭＭＴ伝送路３１０２上で受信する各種シグナリング・メッセージの内容を解析する。システム制御部４０８は、Ｍ２セクション・メッセージで伝送されるＭＨ ＡＩテーブル３１３１内のアプリケーション情報のループを回して、各アプリケーションの情報を参照する。

そして、ａｐｐｌｉｃａｔｉｏｎ＿ｃｏｎｔｒｏｌ＿ｃｏｄｅで“ｐｒｅｆｅｔｃｈ（先読み）”に状態が制御されているアプリケーションを検出すると、システム制御部４０８は、参照番号３１１１で示すように、指定されたエントリーのアイテム（ファイル・データ、ＨＴＭＬ文書データ）のＵＲＬを、データ・トランスミッション・メッセージで伝送されるデータ・ロケーション・マネジメント・テーブル３１３２で引いて、参照されたアイテムのｉｔｅｍ＿ｔａｇを取得する。

次いで、システム制御部４０８は、参照番号３１１２で示すように、データ・トランスミッション・メッセージで伝送されるデータ・コンテント・マネジメント・テーブル３１３３でｉｔｅｍ＿ｔａｇを引いて、参照されたアイテムが属するアプリケーション提示単位ＰＵを特定すると、そのＰＵのループ内のアイテムのループを回して、同じアプリケーション提示単位ＰＵに属する各アイテムのｉｔｅｍ＿ｔａｇを逐次取得する。

次いで、システム制御部４０８は、参照番号３１１３で示すように、各ｉｔｅｍ＿ｔａｇをデータ・アセット・マネジメント・テーブル３１３４で引いて、そのアイテムが属するアセットのａｓｓｅｔ＿ＩＤを取得する。

次いで、システム制御部４０８は、参照番号３１１４で示すように、ａｓｓｅｔ＿ＩＤをＰＡメッセージで伝送されるＭＰテーブル３１３５で引いて、アセットが伝送されるＭＭＴＰパケットのｐａｃｋｅｔ＿ｉｄを取得する。

そして、システム制御部４０８は、参照番号３１１５で示すように、データ・アセット・マネジメント・テーブル３１３４でｉｔｅｍ＿ｔａｇを引いて、ＭＭＴ伝送路上のｉｔｅｍ＿ＩＤと、所望するアイテムを伝送するＭＭＴＰパケットの拡張ヘッダーに記載されるｄｏｗｎｌｏａｄ＿ｉｄを取得すると、ファイル・データのＭＭＴ伝送路３１０１上で、ＭＭＴＰパケットのヘッダー内のｐａｃｋｅｔ＿ｉｄと、拡張ヘッダー内のｄｏｗｎｌｏａｄ＿ｉｄと、ＤＵヘッダー内のｉｔｅｍ＿ＩＤに基づいてフィルタリングして、参照番号３１１６で示すように、所望するアプリケーションのアイテムを取得する。取得したアプリケーションのアイテムは、参照番号３１１７で示すように、逐次コンテント・キャッシュ３００１に事前キャッシュされる。

システム制御部４０８は、事前キャッシュを行なう際、上述したように、データ放送アプリケーションを実行する際の階層的なファイル・データへのアクセス範囲と、各アクセス範囲におけるファイル・データのロケーション情報及びサイズを取得して、キャッシュの空き容量に応じてアプリケーションを効果的にキャッシュする。

その後、システム制御部４０８は、参照番号３１１８で示すように、受信したＭＨ ＡＩテーブル３１３６の内容を参照して、ａｐｐｌｉｃａｔｉｏｎ＿ｃｏｎｔｒｏｌ＿ｃｏｄｅで“ａｕｔｏｓｔａｒｔ（自動開始）”に状態が制御されているアプリケーションを検出すると、参照番号３１１９で示すように、データ放送アプリケーション・エンジン４０７は、そのアプリケーション識別子（ａｐｐｌｉｃａｔｉｏｎ＿ｉｄｅｎｔｉｆｉｅｒ）で指定されたアプリケーション「Ａ１」を起動する。その際、アプリケーションを構成するファイル・データが事前キャッシュされている場合には、そこからファイル・データをロードして、アプリケーションを迅速に起動することができる。

また、図３２には、受信機において、アプリケーション提示画面が遷移する際の動作を図解している。

システム制御部４０８は、ＭＭＴ伝送路３２０２上で受信する各種シグナリング・メッセージの内容を解析する。システム制御部４０８は、Ｍ２セクション・メッセージで伝送されるＭＨ ＡＩテーブル３２３１内のアプリケーション情報のループを回して、各アプリケーションの情報を参照する。

そして、ａｐｐｌｉｃａｔｉｏｎ＿ｃｏｎｔｒｏｌ＿ｃｏｄｅで“ａｕｔｏｓｔａｒｔ（自動開始）”が指示されているアプリケーションを検出すると、システム制御部４０８は、参照番号３２１１で示すように、データ放送アプリケーション・エンジン４０７に対して、そのアプリケーション識別子（ａｐｐｌｉｃａｔｉｏｎ＿ｉｄｅｎｔｉｆｉｅｒ）で指定されたアプリケーション「Ａ１」の起動を指示する。なお、ここでは、アプリケーション「Ａ１」のアイテムが全く事前にキャッシュされていないか、又は、エントリーのアイテムのみが事前にキャッシュされていることを想定する。

ここで、参照番号３２３２で示すように、起動したＨＴＭＬアプリケーションが、ＵＲＬ“ｈｔｔｐ：／／ｘｘｘ／Ａ２．ｈｔｍｌ”で指定される他のアイテム（リソース）、すなわちＨＴＭＬ文書データ「Ａ２．ｈｔｍｌ」を参照しているとする。

このような場合、システム制御部４０８は、参照番号３２１２で示すように、そのＵＲＬを、データ・トランスミッション・メッセージで伝送されるデータ・ロケーション・マネジメント・テーブル３２３３で引いて、参照されたアイテムのｉｔｅｍ＿ｔａｇを取得する。

次いで、システム制御部４０８は、参照番号３２１３で示すように、データ・トランスミッション・メッセージで伝送されるデータ・アセット・マネジメント・テーブル３２３４でそのｉｔｅｍ＿ｔａｇを引いて、そのアイテム「Ａ２．ｈｔｍｌ」が属するアセットのａｓｓｅｔ＿ＩＤを取得する。

次いで、システム制御部４０８は、参照番号３２１４で示すように、ａｓｓｅｔ＿ＩＤをＰＡメッセージで伝送されるＭＰテーブル３２３５で引いて、アセットが伝送されるＭＭＴＰパケットのｐａｃｋｅｔ＿ｉｄを取得する。

そして、システム制御部４０８は、参照番号３２１５で示すように、データ・アセット・マネジメント・テーブル３２３４でｉｔｅｍ＿ｔａｇを引いて、ＭＭＴ伝送路上のｉｔｅｍ＿ＩＤと、所望するアイテムを伝送するＭＭＴＰパケットの拡張ヘッダーに記載されるｄｏｗｎｌｏａｄ＿ｉｄを取得すると、ファイル・データのＭＭＴ伝送路３２０１上で、ＭＭＴＰパケットのヘッダー内のｐａｃｋｅｔ＿ｉｄと、拡張ヘッダー内のｄｏｗｎｌｏａｄ＿ｉｄと、ＤＵヘッダー内のｉｔｅｍ＿ＩＤに基づいてフィルタリングして、参照番号３２１６で示すように、所望するアイテム「Ａ２．ｈｔｍｌ」を取得する。但し、アイテム「Ａ２．ｈｔｍｌ」が事前にキャッシュされている場合には、ＭＭＴ伝送路３２０１から受信する必要はない。そして、データ放送アプリケーション・エンジン４０７は、アプリケーション「Ａ２．ｈｔｍｌ」を実行し、その結果、提示される文書の画面が遷移する。

その後、システム制御部４０８は、参照番号３２１７で示すように、受信したＭＨ ＡＩテーブル３２３６の内容を参照して、エントリーのアイテム「Ａ１」についてａｐｐｌｉｃａｔｉｏｎ＿ｃｏｎｔｒｏｌ＿ｃｏｄｅで“ｋｉｌｌ（終了）”が指示されていることを検出すると、参照番号３２１８で示すように、データ放送アプリケーション・エンジン４０７に対してアプリケーションの終了を指示する。

また、図３３には、受信機において、アプリケーションのファイル・データが更新された際の動作を図解している。

システム制御部４０８は、ＭＭＴ伝送路３３０２上で受信する各種シグナリング・メッセージの内容を解析する。システム制御部４０８は、Ｍ２セクション・メッセージで伝送されるＭＨ ＡＩテーブル３３３１内のアプリケーション情報のループを回して、各アプリケーションの情報を参照する。

そして、ａｐｐｌｉｃａｔｉｏｎ＿ｃｏｎｔｒｏｌ＿ｃｏｄｅで“ａｕｔｏｓｔａｒｔ（自動開始）”が指示されているアプリケーションを検出すると、システム制御部４０８は、参照番号３３１１で示すように、データ放送アプリケーション・エンジン４０７に対して、そのアプリケーション識別子（ａｐｐｌｉｃａｔｉｏｎ＿ｉｄｅｎｔｉｆｉｅｒ）で指定されたアプリケーション「Ａ１」の起動を指示する。

その後、システム制御部４０８は、参照番号３３１２で示すように、データ・トランスミッション・メッセージで伝送されるデータ・アセット・マネジメント・テーブル３３３２を参照して、上述と同様の手順に従って、参照番号３３１３で示すように、ファイル・データのＭＭＴ伝送路３３０１上で、ＭＭＴＰパケットのヘッダー内のｐａｃｋｅｔ＿ｉｄと、拡張ヘッダー内のｄｏｗｎｌｏａｄ＿ｉｄ（＝Ｎ）と、ＤＵヘッダー内のｉｔｅｍ＿ＩＤに基づいてフィルタリングして、参照番号３３１３で示すように、該当するＭＭＴＰパケット３３３３を取得する。このＭＭＴＰパケット３３３３で伝送されるアイテムを実行する処理については説明を省略する。

データ・アセット・マネジメント・テーブル３３３２では、アイテムのバージョン情報としてｉｔｅｍ＿ｖｅｒｓｉｏｎ＝Ｋを示しており、システム制御部４０８は、このアイテムのバージョン情報を管理する。

システム制御部４０８は、参照番号３３１４で示すように、さらにその後に受信したデータ・トランスミッション・メッセージのデータ・アセット・マネジメント・テーブル３３３４を参照して、同じｉｔｅｍ＿ｉｄのｉｔｅｍ＿ｖｅｒｓｉｏｎがＫからＫ＋１に更新されていることを検出すると、参照番号３３１５で示すように、データ放送アプリケーション・エンジン４０７に対してファイル更新イベントを通知する。

また、システム制御部４０８は、参照番号３３１６で示すように、ファイル・データのＭＭＴ伝送路３３０１上で、ＭＭＴＰパケットのヘッダー内のｐａｃｋｅｔ＿ｉｄと、更新されたｄｏｗｎｌｏａｄ＿ｉｄ（＝Ｎ＋１）と、ＤＵヘッダー内のｉｔｅｍ＿ＩＤに基づいてフィルタリングして、参照番号３３１７で示すように、バージョンがＫ＋１に更新されたアイテムを伝送するＭＭＴＰパケット３３３５を取得する。そして、参照番号３３１８で示すように、取得したアイテムは、アプリケーションのリソースとして、データ放送アプリケーション・エンジン４０７に渡され、文書の画面が遷移する。

上述したように、本明細書で開示する技術を適用した放送システムでは、アプリケーションを構成するリソース（アイテム）を放送・通信の任意のロケーションから取得可能とするために、アプリケーションにおいてロケーションを示すＵＲＬを放送などのＭＭＴ伝送路上のロケーションにマッピングする情報、アプリケーションにおける表示単位とリンク関係を示す情報を伝送することができる。

また、本明細書で開示する技術は、アプリケーションのオーサリング時のディレクトリー構成の自由度、アプリケーションを構成する任意のファイルを放送と通信の伝送路に切り分ける自由度、これらとアプリケーション実行時の表示単位、リンク関係の自由度を確保することが可能なアプリケーション伝送方式を提供するものである。

また、本明細書で開示する技術によれば、放送ストリームの送信側からは、アプリケーションにおいて、直接参照するリソース、同時に表示するアプリケーション提示単位を構成するリソース・グループ、さらにこれにリンクする他のアプリケーション提示単位を含むリソース・グループ、アプリケーション全体のリソース・グループという４通りのアクセス範囲で、アクセス範囲に関するロケーション情報とサイズを階層的に情報として与えることができる。これにより、受信側では、利用可能なキャッシュ・サイズに応じて効果的な事前キャッシュを行なうことが可能になる。

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

本明細書で開示する技術は、トランスポート方式としてＭＭＴを採用するさまざまな放送システムに適用することができる。また、本明細書で開示する技術は、タイムド・メディアとノンタイムド・メディアの両方を伝送するさまざまな伝送システムに適用することができる。

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

なお、本明細書の開示の技術は、以下のような構成をとることも可能である。
（１）所定のトランスポート方式の伝送信号を受信する受信部と、
受信信号を各メディア・データとシグナリング情報にデマルチプレクスするデマルチプレクサーと、
デマルチプレクスされたシグナリング情報に基づいて、デマルチプレクスされた少なくともの１つのメディア・データのキャッシュを制御する制御部と、
を具備する受信装置。
（２）前記所定のトランスポート方式はＭＭＴである、
上記（１）に記載の受信装置。
（３）伝送信号はタイムド・メディア及びノンタイムド・メディアを含み、
前記制御部は、ノンタイムド・メディアのキャッシュを制御する、
上記（１）に記載の受信装置。
（４）前記ノンタイムド・メディアは、データ放送アプリケーションのアセットを構成する複数のファイル・データからなり、
前記制御部は、キャッシュの空き容量に応じて、ファイル・データのキャッシュを制御する、
上記（１）に記載の受信装置。
（５）前記制御部は、受信したシグナリング情報に基づいて、データ放送アプリケーションを実行する際の階層的なファイル・データへのアクセス範囲と、各アクセス範囲におけるファイル・データのロケーション情報及びサイズを取得して、キャッシュを制御する、
上記（４）に記載の受信装置。
（６）前記制御部は、以下の４通りの階層的なアクセス範囲（ａ）〜（ｄ）とそのサイズを把握して、キャッシュの空き容量に応じていずれのアクセス範囲でキャッシュするかを決定する、
上記（４）又は（５）のいずれかに記載の受信装置。
（ａ）アプリケーション実行時に直接参照するファイル・データ
（ｂ）同時に表示するアプリケーション提示単位を構成するファイル・データのリソース・グループ
（ｃ）同時に表示するアプリケーション提示単位を構成するリソース・グループと、これにリンクする他のアプリケーション提示単位を含む大きなリソース・グループ
（ｄ）アプリケーション全体のリソース・グループ
（７）前記制御部は、シグナリング情報として、アプリケーションにおいてロケーションを示すＵＲＬを放送などのＭＭＴ伝送路上のロケーションにマッピングする第１の情報と、アプリケーションにおける表示単位とリンク関係を示す第２の情報を受信して、前記４通りの階層的なアクセス範囲（ａ）〜（ｄ）とそのサイズを把握する、
上記（６）に記載の受信装置。
（８）前記受信部は、前記第１の情報として、アプリケーションの伝送方法とロケーションを示すＵＲＬ情報を管理するアプリケーション情報テーブルと、アプリケーションにおいてロケーションを示すＵＲＬとデータ・トランスミッション・メッセージ上のｉｔｅｍ識別情報との対応関係を管理するデータ・ロケーション・マネジメント・テーブルと、ｉｔｅｍ情報と、そのアイテムを含むアセットのａｓｓｅｔ識別情報、そのアセットのＭＭＴ伝送路上のＭＭＴＰパケットのｄｏｗｎｌｏａｄ＿ｉｄ及びｉｔｅｍ識別情報との対応関係を管理するデータ・アセット・マネジメント・テーブルと、ａｓｓｅｔ識別情報とＭＭＴ伝送路上でそのアセットを伝送するパケットのｐａｃｋｅｔ識別情報の対応関係を管理するＭＭＴパッケージ・テーブルを受信する、
上記（７）に記載の受信装置。
（９）前記受信部は、前記第２の情報として、コンテントに含まれるアプリケーション提示単位の識別情報、アプリケーション提示単位に含まれるすべてのアイテムのｉｔｅｍ識別情報と、これにリンクする他のアプリケーション提示単位の識別情報を管理するデータ・コンテント・マネジメント・テーブルを受信する、
上記（７）又は（８）のいずれかに記載の受信装置。
（１０）前記制御部は、ｐｒｅｆｅｔｃｈ（先読み）に状態が制御されたアプリケーションに関するシグナリング情報を受信したことに応答して、キャッシュ処理を実行する、
上記（１）乃至（９）のいずれかに記載の受信装置。
（１１）所定のトランスポート方式の伝送信号を受信する受信ステップと、
受信信号を各メディア・データとシグナリング情報にデマルチプレクスするデマルチプレクス・ステップと、
デマルチプレクスされたシグナリング情報に基づいて、デマルチプレクスされた少なくともの１つのメディア・データのキャッシュを制御する制御ステップと、
を有する受信方法。
（１２）タイムド・メディア及びノンタイムド・メディアと、受信側でノンタイムド・メディアのキャッシュ処理に利用可能な情報を含むシグナリング・メッセージをマルチプレクスするマルチプレクサーと、
マルチプレクスされたパケットを所定のトランスポート方式で送信する送信部と、
を具備する送信装置。
（１３）前記所定のトランスポート方式はＭＭＴである、
上記（１２）に記載の送信装置。
（１４）前記ノンタイムド・メディアは、データ放送アプリケーションのアセットを構成する複数のファイル・データからなり、
前記シグナリング・メッセージは、アプリケーションにおいてロケーションを示すＵＲＬを放送などのＭＭＴ伝送路上のロケーションにマッピングする第１の情報と、アプリケーションにおける表示単位とリンク関係を示す第２の情報を含む、
上記（１２）又は（１３）のいずれかに記載の送信装置。
（１５）前記第１の情報は、アプリケーションの伝送方法とロケーションを示すＵＲＬ情報を管理するアプリケーション情報テーブルと、アプリケーションにおいてロケーションを示すＵＲＬとデータ・トランスミッション・メッセージ上のｉｔｅｍ識別情報との対応関係を管理するデータ・ロケーション・マネジメント・テーブルと、ｉｔｅｍ識別情報と、そのアイテムを含むアセットのａｓｓｅｔ識別情報、そのアセットのＭＭＴ伝送路上のＭＭＴＰパケットのｄｏｗｎｌｏａｄ＿ｉｄ及びｉｔｅｍ識別情報との対応関係を管理するデータ・アセット・マネジメント・テーブルと、ａｓｓｅｔ識別情報とＭＭＴ伝送路上でそのアセットを伝送するパケットのｐａｃｋｅｔ識別除法の対応関係を管理するＭＭＴパッケージ・テーブルを含む、
上記（１４）に記載の送信装置。
（１６）前記第２の情報は、コンテントに含まれるアプリケーション提示単位の識別情報、アプリケーション提示単位に含まれるすべてのアイテムのｉｔｅｍ識別情報と、これにリンクする他のアプリケーション提示単位の識別情報を管理するデータ・コンテント・マネジメント・テーブルを含む、
上記（１４）又は（１５）のいずれかに記載の送信装置。
（１７）タイムド・メディア及びノンタイムド・メディアと、受信側でノンタイムド・メディアのキャッシュ処理に利用可能な情報を含むシグナリング・メッセージをマルチプレクスするマルチプレクス・ステップと、
マルチプレクスされたパケットを所定のトランスポート方式で送信する送信ステップと、
を有する送信方法。

１０…ディジタル放送システム
１１…放送送出システム、１２…受信機
３０１…時計部、３０２…信号送出部、３０３…ビデオ・エンコーダー
３０４…オーディオ・エンコーダー、３０５…キャプション・エンコーダー
３０６…シグナリング・エンコーダー、３０７…ファイル・エンコーダー
３０８…情報システム、３０９…ＴＬＶシグナリング・エンコーダー
３１０…ＩＰサービス・マルチプレクサー
３１１…ＴＬＶマルチプレクサー、３１２…変調・送信部
４０１…チューナー・復調部、４０２…デマルチプレクサー
４０３…時計部、４０４…ビデオ・デコーダー
４０５…オーディオ・デコーダー、４０６…キャプション・デコーダー
４０７…データ放送アプリケーション・エンジン
４０８…システム制御部、４０９…合成部

Claims (8)

1. タイムド・メディア及びノンタイムド・メディアからなる各アセットに関するシグナリング・メッセージを生成するメッセージ生成部と、
   前記シグナリング・メッセージを格納するパケットを所定のトランスポート方式で送信する送信部と、
   を具備し、
   前記ノンタイムド・メディアは、データ放送アプリケーションのアセットを構成するファイル又はディレクトリーに相当する複数のアイテムからなり、
   前記メッセージ生成部は、ノンタイムド・メディア内のデータ放送アプリケーションの提示単位を識別する提示単位識別情報と、前記提示単位に含まれるアイテムを識別するアイテムタグ情報を示す第１のテーブルを含むシグナリング・メッセージを生成する、
   送信装置。
2. 前記所定のトランスポート方式はＭＭＴである、
   請求項１に記載の送信装置。
3. 前記シグナリング・メッセージは、シグナリング・メッセージ上でアイテムを識別するアイテムタグ情報に対応するトランスポート・ストリーム上でアイテム識別するアイテム識別情報を示す第２のテーブルをさらに含む、
   請求項２に記載の送信装置。
4. 前記第１のテーブルは、前記アプリケーション提示単位にリンクする他のアプリケーション提示単位を識別するリンク先提示単位識別情報をさらに示す、
   請求項３に記載の送信装置。
5. 前記第２のテーブルは、アイテムを含むアセットを識別するアセット識別情報をさらに示す、
   請求項４に記載の送信装置。
6. 送信装置が備えるメッセージ生成部が、タイムド・メディア及びノンタイムド・メディアからなる各アセットに関するシグナリング・メッセージを生成するメッセージ生成ステップと、
   前記送信装置が備える送信部が、前記シグナリング・メッセージを格納するパケットを所定のトランスポート方式で送信する送信ステップと、
   を有し、
   前記ノンタイムド・メディアは、データ放送アプリケーションのアセットを構成するファイル又はディレクトリーに相当する複数のアイテムからなり、
   前記メッセージ生成ステップでは、ノンタイムド・メディア内のデータ放送アプリケーションの提示単位を識別する提示単位識別情報と、前記提示単位に含まれるアイテムを識別するアイテムタグ情報を示す第１のテーブルを含むシグナリング・メッセージを生成する、
   送信方法。
7. タイムド・メディア及びノンタイムド・メディアからなる各アセットに関するシグナリング・メッセージが格納されている所定のトランスポート方式の伝送信号を受信する受信部と、
   受信したシグナリング・メッセージに基づいてノンタイムド・メディアのキャッシュを制御する制御部と、
   を具備し、
   前記ノンタイムド・メディアは、データ放送アプリケーションのアセットを構成するファイル又はディレクトリーに相当する複数のアイテムからなり、
   前記制御部は、受信したシグナリング・メッセージに含まれる、ノンタイムド・メディア内のデータ放送アプリケーションの提示単位を識別する提示単位識別情報と、前記提示単位に含まれるアイテムを識別するアイテムタグ情報を示す第１のテーブルに基づいて、提示単位でのアイテムのキャッシュを制御する、
   受信装置。
8. 受信装置が備える受信部が、タイムド・メディア及びノンタイムド・メディアからなる各アセットとノンタイムド・メディアに関するシグナリング・メッセージが格納されている所定のトランスポート方式の伝送信号を受信する受信ステップと、
   前記受信装置が備える制御部が、受信したシグナリング・メッセージに基づいてノンタイムド・メディアのキャッシュを制御する制御ステップと、
   を有し、
   前記ノンタイムド・メディアは、データ放送アプリケーションのアセットを構成するファイル又はディレクトリーに相当する複数のアイテムからなり、
   前記制御ステップでは、受信したシグナリング・メッセージに含まれる、ノンタイムド・メディア内のデータ放送アプリケーションの提示単位を識別する提示単位識別情報と、前記提示単位に含まれるアイテムを識別するアイテムタグ情報を示す第１のテーブルに基づいて、提示単位でのアイテムのキャッシュを制御する、
   受信方法。