JP7207457B2 - 受信装置及び受信装置の制御方法 - Google Patents

Description

本明細書で開示する技術は、所定の伝送方式によりデータ放送用のデータを送信する送信方法に関する。

現在の放送システムでは、メディアのトランスポート方式として、ＭＰＥＧ－２ ＴＳ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ－２ Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ）方式やＲＴＰ（Ｒｅａｌ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）方式が広く使用されている（例えば、特許文献１を参照のこと）。

また、本出願時に運用されているデータ放送サービスでは、ＢＭＬ（Ｂｒｏａｄｃａｓｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）形式で記述されたアプリケーションなどのデータ放送用データが、ＩＳＯ／ＩＥＣ １３８１８－６で定義されたデータ・カルーセル伝送方式に従って繰り返し配信され、受信機側では放送時間中の任意の時間で必要なデータを取得することができる（例えば、特許文献２を参照のこと）。このデータ・カルーセル伝送方式では、データはブロックに分割されたモジュール単位で伝送される。モジュールという伝送単位がアプリケーションのディレクトリー構造に組み込まれ、また、モジュールに複数のファイルをマルチパート化してキャッシュ単位とすることが想定されている。このような伝送方式に由来して、アプリケーションを制作する上での制約が大きいと思料される。

一方、最近では、放送と通信の連携などを目的として、より汎用性の高いＨＴＭＬ５（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ ５）をデータ放送アプリケーションの記述形式に適用することが検討されている（例えば、特許文献３を参照のこと）。

本明細書で開示する技術の目的は、データ・カルーセル伝送方式によりデータ放送用のデータを好適に送信することができる優れた送信方法を提供することにある。

本願は、上記課題を参酌してなされたものであり、請求項１に記載の技術は、
伝送路依存指定方式又はＵＲＩ指定方式のいずれかでファイル・ロケーションを指定して、データ放送アプリケーションのデータをデータ・カルーセル伝送方式によりエンコードする第１のエンコーダーと、
前記データ放送アプリケーションに関するアプリケーション情報テーブル（ＡＩＴ）の伝送配置情報を指定するデータ符号化方式記述子を配置したプログラム管理テーブル（ＰＭＴ）を含んだプログラム固有情報（ＰＳＩ）をエンコードする第２のエンコーダーと、
前記第１及び第２のエンコーダーでそれぞれエンコードされた放送データを含む複数の放送データを多重化して送信処理する送信処理部と、
を具備する送信装置である。

本願の請求項２に記載の技術によれば、請求項１に記載の送信装置は、前記アプリケーション情報テーブル（ＡＩＴ）において、データ・カルーセルの伝送路依存指定方式とＵＲＩ指定方式を指定するように構成されている。

本願の請求項３に記載の技術によれば、請求項１に記載の送信装置は、ＵＲＩ指定方式を選択した場合に適用されるシグナリング情報（ＤＤＭＴ、ＤＣＣＴ）の伝送配置情報を、前記プログラム管理テーブル（ＰＭＴ）に配置された前記データ符号化方式記述子でさらに指定するように構成されている。

本願の請求項４に記載の技術によれば、請求項３に記載の送信装置は、前記シグナリング情報（ＤＤＭＴ、ＤＣＣＴ）を、前記第１のエンコーダーでエンコードするデータ・カルーセルの特定のモジュールに含めるように構成されている。

本願の請求項５に記載の技術によれば、請求項３又は４のいずれかに記載の送信装置は、前記シグナリング情報として、データ放送で伝送するファイルのディレクトリー構造を管理するデータ・ディレクトリー管理テーブル（ＤＤＭＴ）を含めるように構成されている。

本願の請求項６に記載の技術によれば、請求項３乃至５のいずれかに記載の送信装置は、前記シグナリング情報として、データ放送で伝送するコンテンツ（アプリケーション）毎のファイル構成、コンテンツ（アプリケーション）内のデータ放送提示単位（ＰＵ）毎のファイル構成、コンテンツ構成とキャッシュ制御を示すデータ・コンテント管理テーブル（ＤＣＣＴ）を含めるように構成されている。

本願の請求項７に記載の技術によれば、請求項３乃至６のいずれかに記載の送信装置は、前記シグナリング情報を、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）表記形式並びにバイナリー表記形式で表記するように構成されている。

本願の請求項８に記載の技術によれば、請求項３乃至７のいずれかに記載の送信装置は、前記シグナリング情報に含まれる各テーブルにおいて、各ディレクトリー並びに各ファイルに対して共通のノード・タグを指定するとともに、データ・カルーセルの各モジュールの情報を示すコントロール・メッセージ（ＤＩＩ）のモジュール情報にノード・タグ記述子を配置して、モジュールと関連付けるように構成されている。

また、本願の請求項９に記載の技術は、
伝送路依存指定方式又はＵＲＩ指定方式のいずれかでファイル・ロケーションを指定して、データ放送アプリケーションのデータをデータ・カルーセル伝送方式によりエンコードする第１のエンコーディング・ステップと、
前記データ放送アプリケーションに関するアプリケーション情報テーブル（ＡＩＴ）の伝送配置情報を指定するデータ符号化方式記述子を配置したプログラム管理テーブル（ＰＭＴ）を含んだプログラム固有情報（ＰＳＩ）をエンコードする第２のエンコーディング・ステップと、
前記第１及び第２のエンコーディング・ステップでそれぞれエンコードされた放送データを含む複数の放送データを多重化して送信処理する送信処理ステップと、
を有する送信方法である。

また、本願の請求項１０に記載の技術は、
伝送路依存指定方式又はＵＲＩ指定方式のいずれかでファイル・ロケーションが指定されたデータ放送アプリケーションのデータ・カルーセルと、前記データ放送アプリケーションに関するアプリケーション情報テーブル（ＡＩＴ）の伝送配置情報を指定するデータ符号化方式記述子を配置したプログラム管理テーブル（ＰＭＴ）を含んだプログラム固有情報（ＰＳＩ）を含んだ放送信号を受信処理する受信処理部と、
データ放送アプリケーションの処理を制御するアプリケーション・データ制御部と、
を具備する受信装置である。

本願の請求項１１に記載の技術によれば、請求項１０に記載の受信装置の前記アプリケーション・データ制御部は、前記プログラム管理テーブル（ＰＭＴ）に配置されたデータ符号化方式記述子に記載された前記アプリケーション情報テーブル（ＡＩＴ）の伝送配置情報に基づいて前記アプリケーション情報テーブル（ＡＩＴ）を取得し、前記アプリケーション情報テーブル（ＡＩＴ）に基づいて、前記データ・カルーセルのファイル・ロケーション指定方式が伝送路依存指定方式又はＵＲＩ指定方式のいずれかであるかを判定するように構成されている。

本願の請求項１２に記載の技術によれば、請求項１０又は１１のいずれかに記載の受信装置は、前記データ・カルーセルのファイル・ロケーション指定方式としてＵＲＩ指定方式が選択されている場合に、前記アプリケーション・データ制御部が、前記プログラム管理テーブル（ＰＭＴ）でエレメンタリー・ストリームのパケット識別子（ＰＩＤ）が指定されたデータ・カルーセルから、データ・カルーセルの各モジュールの情報を示すコントロール・メッセージ（ＤＩＩ）と、ＵＲＩ指定方式を選択した場合に適用されるシグナリング情報（ＤＤＭＴ、ＤＣＣＴ）のモジュール（ＤＤＢメッセージ）に基づいて、前記データ・カルーセルに含まれるモジュールのロケーションを解決するように構成されている。

本願の請求項１３に記載の技術によれば、請求項１２に記載の受信装置の前記アプリケーション・データ制御部は、前記プログラム管理テーブル（ＰＭＴ）に配置された前記データ符号化方式記述子に記述されたシグナリング情報（ＤＤＭＴ、ＤＣＣＴ）の伝送配置情報に基づいて、シグナリング情報（ＤＤＭＴ、ＤＣＣＴ）を取得するように構成されている。

本願の請求項１４に記載の技術によれば、請求項１２に記載の受信装置の前記アプリケーション・データ制御部は、前記アプリケーション情報テーブル（ＡＩＴ）で所望のアプリケーションのロケーションを指定するＵＲＩと一致するノード・タグを、前記シグナリング情報（データ放送で伝送するファイルのディレクトリー構造を管理するデータ・ディレクトリー管理テーブル：ＤＤＭＴ）で検索し、そのノード・タグに関連付けられたモジュールのモジュール識別子を前記コントロール・メッセージ（ＤＩＩ）から取得して、得られたモジュール識別子とダウンロード識別子の組み合わせに基づいて、データ・カルーセルの中から該当するモジュール（ＤＤＢメッセージ）を指定するように構成されている。

本願の請求項１５に記載の技術によれば、請求項１２に記載の受信装置の前記アプリケーション・データ制御部は、前記シグナリング情報（データ放送で伝送するコンテンツ（アプリケーション）毎のファイル構成、コンテンツ（アプリケーション）内のデータ放送提示単位（ＰＵ）毎のファイル構成、コンテンツ構成とキャッシュ制御を示すデータ・コンテント管理テーブル：ＤＣＣＴ）を用いて、データ・カルーセル伝送されるファイル・データのキャッシュを制御するように構成されている。

本願の請求項１６に記載の技術によれば、請求項１３に記載の受信装置の前記アプリケーション・データ制御部は、前記シグナリング情報（ＤＣＣＴ）においてロック対象と指定されたモジュールを前記受信処理部が受信すると、キャッシュ・メモリーに強制キャッシュするように構成されている。

本願の請求項１７に記載の技術によれば、請求項１６に記載の受信装置の前記アプリケーション・データ制御部は、前記シグナリング情報（ＤＣＣＴ）においてアンロック対象と指定されたモジュールの強制キャッシュ指定を解除して前記キャッシュ・メモリーから削除するように構成されている。

本願の請求項１８に記載の技術によれば、請求項１５に記載の受信装置の前記アプリケーション・データ制御部は、前記シグナリング情報（ＤＣＣＴ）においてアンロック対象と指定されたモジュールの強制キャッシュ指定を解除して前記キャッシュ・メモリーから削除するように構成されている。

また、本願の請求項１９に記載の技術は、
伝送路依存指定方式又はＵＲＩ指定方式のいずれかでファイル・ロケーションが指定されたデータ放送アプリケーションのデータ・カルーセルと、前記データ放送アプリケーションに関するアプリケーション情報テーブル（ＡＩＴ）の伝送配置情報を指定するデータ符号化方式記述子を配置したプログラム管理テーブル（ＰＭＴ）を含んだプログラム固有情報（ＰＳＩ）を含んだ放送信号を受信処理する受信処理ステップと、
データ放送アプリケーションの処理を制御するアプリケーション・データ制御ステップと、
を有する受信方法である。

本明細書で開示する技術によれば、データ・カルーセル伝送方式によりデータ放送用のデータを好適に送信することができる優れた送信方法を提供することができる。

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

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

図１は、本明細書で開示する技術を適用したディジタル放送システム１０の構成例を模式的に示した図である。 図２は、本実施形態に係るディジタル放送システム１０において想定される放送信号２００の構成を模式的に示した図である。 図３は、図２に示した放送信号２００を送信する放送送出システム１１の構成を模式的に示した図である。 図４は、図２に示した放送信号２００を受信する受信機１２の構成を模式的に示した図である。 図５は、ＰＭＴのデータ構造５００を示した図である。 図６は、データ符号化方式記述子のデータ構造６００を示した図である。 図７は、Ａｄｄｉｔｉｏｎａｌ＿ｈｔｍｌ５＿ｉｎｆｏ（）のデータ構造７００を示した図である 図８は、データ・カルーセルのデータ構造８００を示した図である。 図９は、ＤＳＭ－ＣＣセクション（データ・カルーセル）で伝送されるＤＩＩメッセージのデータ構造９００を示した図である。を示した図である。 図１０は、ＤＤＢメッセージのデータ構造１０００を示した図である。 図１１は、アプリケーション情報テーブル（ＡＩＴ）のデータ構造１１００を示した図である。 図１２は、ａｐｐｌｉｃａｔｏｎ＿ｔｙｐｅの各値が示す意味を示した図である。 図１３は、ａｐｐｌｉｃａｔｉｏｎ＿ｃｏｎｔｒｏｌ＿ｃｏｄｅのセマンティクスを示した図である。 図１４は、アプリケーション記述子のデータ構造１４００を示した図である。 図１５は、アプリケーション記述子の各パラメーターのセマンティクスを示した図である。 図１６は、伝送プロトコル記述子のデータ構造１６００を示した図である。 図１７は、伝送路依存指定方式のデータ・カルーセル伝送の場合の、伝送プロトコル記述子内のセレクター・バイトのデータ構造１７００を示した図である。 図１８は、伝送路依存指定方式のデータ・カルーセル伝送の場合におけるファイル指定方法を示した図である。 図１９は、伝送路依存指定方式のデータ・カルーセル伝送の場合におけるディレクトリー構造を示した図である。 図２０は、伝送路依存指定方式のデータ・カルーセル伝送の場合におけるアプリケーション取得のシグナリング関係を示した図である。 図２１は、ＨＴＴＰ／ＨＴＴＰＳ伝送並びにＵＲＩ指定方式のデータ・カルーセル伝送の場合の、伝送プロトコル記述子内のセレクター・バイトのデータ構造２１００を示した図である。 図２２は、ＵＲＩ指定方式のデータ・カルーセル伝送の場合におけるファイル指定方法を示した図である。 図２３は、ＤＩＩメッセージの各ｍｏｄｕｌｅ＿ｉｎｆｏに配置するノード・タグ記述子のデータ構造２３００を示した図である。 図２４は、バイナリー表記形式のＤＤＭＴのデータ構造２４００を示した図である。 図２５は、ＸＭＬ表記形式のＤＤＭＴのデータ構造２５００を示した図である。 図２６は、ＸＭＬ表記形式のＤＤＭＴの記述例を示した図である。 図２７は、バイナリー表記形式のＤＣＣＴのデータ構造２７００を示した図である。 図２８は、ＸＭＬ表記形式のＤＣＣＴのデータ構造２８００を示した図である。 図２９は、ＸＭＬ表記形式のＤＣＣＴの記述例２９００を示した図である。 図３０は、データ・カルーセル伝送されるデータ放送アプリケーション（コンテント）の伝送とロケーションと提示を行なう仕組みを説明するための図である。 図３１は、ＵＲＩ指定方式のデータ・カルーセル伝送の場合におけるアプリケーション取得のシグナリング関係を示した図である。 図３２は、受信機１２で実行されるディジタル放送の選局ときの処理手順を示したフローチャートである。 図３３は、受信機１２におけるロック及びアンロックによるキャッシュ制御手順を示したフローチャートである。 図３４は、受信機１２におけるファイル・データのキャッシュのロック及びアンロック動作例を示した図である。

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

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

放送送出システム１１は、ＭＰＥＧ－２ ＴＳ方式の放送信号を送信する。放送信号には、ビデオやオーディオなどの放送番組本編を構成するエレメンタリー・ストリーム（ＥＳ）や、放送番組本編に関連又は連携するデータ放送アプリケーションなどが含まれる。以下の説明では、ＨＴＭＬ５によるデータ放送サービスを想定している。

一方、受信機１２は、放送送出システム１１から送られてくる放送信号を受信する。そして、受信機１２は、受信した放送信号からビデオやオーディオなどのエレメンタリー・ストリームを取得して、放送番組の画像や音声を提示する。また、受信機１２は、受信した放送信号からデータ放送用の各ファイル・データを取得すると、ＨＴＭＬブラウザーなどのアプリケーション・エンジンを起動して、放送番組に連動したデータ放送の提示を行なう。

本実施形態に係るディジタル放送システム１０では、ＭＰＥＧ－２ ＴＳ方式を適用したディジタル放送サービスが提供されるが、詳細な仕様は例えば標準規格ＡＲＩＢ ＳＴＤ－Ｂ２４ ５．９版に従う。

図２には、本実施形態に係るディジタル放送システム１０において想定される放送信号２００の構成を模式的に示している。図示の放送信号２００は、複数のトランスポート・ストリームのコンポーネント２１０～２５０を含んでいる。

参照番号２１０、２２０で示される各コンポーネントはそれぞれ、放送番組本編を構成するビデオ並びにオーディオを伝送するエレメンタリー・ストリームである。

参照番号２３０で示されるコンポーネントは、受信機１２に対するデータのダウンロードやマルチメディア・サービスにおけるコンテンツの伝送を行なう。本実施形態では、ＩＳＯ／ＩＥＣ １３８１８－６で定義されたＤＳＭ－ＣＣ（Ｄｉｇｉｔａｌ Ｓｔｏｒａｇｅ Ｍｅｄｉａ Ｃｏｍｍａｎｄ ａｎｄ Ｃｏｎｔｒｏｌ）データ・カルーセル仕様に基づいて、各データがブロックに分割されたモジュール単位でデータ・カルーセル伝送される。放送送出システム１１からはデータが繰り返し送信されるので、受信機１２側では放送時間中の任意の時間で必要なデータを取得することができる。

各データ・カルーセル２３１、２３２、…は、データ本体をブロックに分割されたモジュールとしてのＤＤＢ（ＤｏｗｎｌｏａｄＤａｔａＢｌｏｃｋ）メッセージと、ＤＳＭ－ＣＣコントロール・メッセージに属するＤＩＩ（ＤｏｗｎｌｏａｄＩｎｆｏＩｎｄｉｃａｔｉｏｎ）メッセージを含む。ＤＩＩメッセージは、データ・カルーセルに含まれる各モジュール（ＤＤＢメッセージ）の情報を記載する。データ・カルーセル内の各モジュールは、モジュール識別子（ｍｏｄｕｌｅ＿ｉｄ）で識別することができる。

ＤＤＢメッセージとして、例えばＨＴＭＬ５形式で記述されたデータ放送アプリケーションや、ＪＰＥＧやＰＮＧなどのデータ放送アプリケーションで使用するモノメディアなどのコンテンツ（ファイル）が伝送される。図２では、これらのアプリケーションに関連するデータのモジュールは「ＡｐｐＤ」で示されている。

また、ＤＤＢメッセージとして、点線で示されるアプリケーション情報テーブル（ＡＩＴ：Ａｐｐｌｉｃａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ）や、データ・ディレクトリー管理テーブル（ＤＤＭＴ：Ｄａｔａ Ｄｉｒｅｃｔｏｒｙ Ｍａｎａｇｅｍｅｎｔ Ｔａｂｌｅ）、データ・コンテント管理テーブル（ＤＣＣＴ：Ｄａｔａ Ｃｏｎｔｅｎｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｔａｂｌｅ）を、任意で伝送することができる。

ＡＩＴは、データ・カルーセル伝送方式で送られてくるアプリケーションの処理方法や、伝送方法、ロケーションの指定などアプリケーション制御情報を記述したテーブルである。ＤＤＭＴとＤＣＣＴは、データ放送アプリケーションのファイル・ロケーション指定方式としてＵＲＩ指定方式を選択した場合（後述）に適用するシグナリング情報である。このうち、ＤＤＭＴは、ＵＲＩ指定方式のデータ・カルーセルで送られるアプリケーションを構成するファイルのディレクトリー構造を管理するテーブルである。また、ＤＣＣＴは、ＵＲＩ指定方式のデータ・カルーセルで送られるアプリケーションを構成するコンテント（ファイル・データ）をデータ放送提示単位（Ｐｒｅｓｅｎｔａｔｉｏｎ Ｕｎｉｔ：ＰＵ）で管理するテーブルであり、ファイル・データのキャッシュ制御に利用することができる。ＡＩＴ、ＤＤＭＴ、ＤＣＣＴの各テーブルの詳細については後述に譲る。

ＤＩＩメッセージは、ＤＳＭ－ＣＣコントロール・メッセージに属し、データ・カルーセルに含まれる各ＤＤＢメッセージの情報を記述する。ＤＩＩメッセージの詳細については後述に譲る。

各データ・カルーセル２３１、２３２、…には、１以上のＤＤＢメッセージと、ＤＩＩメッセージが含まれる。但し、１つのデータ・カルーセル内で、同じＤＩＩメッセージが複数回にわたり伝送されることもある。

参照番号２４０で示されるコンポーネントは、コンポーネント２３０でデータ・カルーセル伝送方式により送られてくるアプリケーションのＡＩＴをパケット伝送する専用のトランスポート・ストリームである。但し、コンポーネント２３０でＤＤＢメッセージとしてＡＩＴを伝送する場合は、コンポーネント２４０は不要である。すなわち、コンポーネント２４０は任意であり、点線で描いている。データ・カルーセル伝送方式で伝送されるＡＩＴはモジュール識別子で識別され、コンポーネント２４０でパケット伝送されるＡＩＴはパケット識別子（ＰＩＤ：Ｐａｃｋｅｔ Ｉｄｅｎｔｉｆｉｅｒ）で識別される。

参照番号２５０で示されるコンポーネントは、ＰＳＩ（Ｐｒｏｇｒａｍ Ｓｐｅｃｉｆｉｃ Ｉｎｆｏｒｍａｔｉｏｎ）と、ＳＩ（Ｓｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ）を伝送する。ＰＳＩは、ＭＰＥＧ－２ ＴＳストリームに含まれる各エレメンタリー・ストリームがどの番組に属しているかを記した番組特定情報である。また、ＳＩは、番組配列情報であり、ＥＰＧ（Ｅｌｅｃｔｒｉｃ Ｐｒｏｇｒａｍ Ｇｕｉｄｅ：電子番組案内）に使用することができる。ＰＳＩは、１つの番組に含まれる動画や音声、その他の放送番組を構成する各エンコード信号を伝送するＴＳパケットのパケット識別子（ＰＩＤ）を記述したＰＭＴ（Ｐｒｏｇｒａｍ Ｍａｐ Ｔａｂｌｅ）や、各放送番組のＰＭＴのパケット識別子（ＰＩＤ）を列挙したＰＡＴ（Ｐｒｏｇｒａｍ Ａｓｓｏｃｉａｔｉｏｎ Ｔａｂｌｅ）などの、ＭＰＥＧ－２ ＴＳストリームの番組構成情報を含んでいる（ＰＡＴのＰＩＤは０と定められている）。ＰＭＴの詳細については後述に譲る。

図３には、図２に示した放送信号２００を送信する放送送出システム１１の構成を模式的に示している。クロック生成部３０１と、信号送出部３０２と、ビデオ・エンコーダー３０３と、オーディオ・エンコーダー３０４と、データ・カルーセル・エンコーダー３０５と、ＡＩＴエンコーダー３０６と、ＰＳＩ／ＳＩエンコーダー３０７と、放送情報システム３０８と、ＴＳマルチプレクサー（ＭＵＸ）３０９と、変調・送信部３１０を備えている。

クロック生成部３０１は、各エンコーダー３０３～３０７を同期させるためのクロック信号ＳＴＣ（Ｓｙｓｔｅｍ Ｔｉｍｅ Ｃｌｏｃｋ）を生成するとともに、受信機１２側でデコードに時刻同期を行なうための基準となるタイムスタンプＰＣＲ（Ｐｒｏｇｒａｍ Ｃｌｏｃｋ Ｒｅｆｅｒｅｎｃｅ）を含むＴＳパケットを出力する。

信号送出部３０２は、例えばＴＶ放送局のスタジオやＶＴＲなどの記録再生機であり、ビデオやオーディオなどの放送番組本編を構成するエレメンタリー・ストリームをそれぞれ、ビデオ・エンコーダー３０３、オーディオ・エンコーダー３０４に送る。

ビデオ・エンコーダー３０３は、信号送出部３０２から送出されるビデオ信号を符号化し、さらにパケット化して、ビデオのＴＳパケットを含むビデオ・エレメンタリー・ストリームをＴＳマルチプレクサー３０９に送る。また、オーディオ・エンコーダー３０４は、信号送出部３０２から送出されるオーディオ信号を符号化し、さらにパケット化して、オーディオのＴＳパケットを含むオーディオ・エレメンタリー・ストリームをＴＳマルチプレクサー３０９に送る。

放送情報システム３０８は、ＴＶ放送局のスケジューラー並びにファイルの供給源であり、ＨＴＭＬ５形式で記述されたデータ放送アプリケーションやモノメディアなどのデータ、アプリケーション制御情報、データ放送アプリケーションなどのデータに関するシグナリング情報、番組構成情報や番組配列情報を、データ・カルーセル・エンコーダー３０５、ＡＩＴエンコーダー３０６、ＰＳＩ／ＳＩエンコーダー３０７にそれぞれ送る。

データ・カルーセル・エンコーダー３０５は、放送情報システム３０８から送出されるデータ放送アプリケーションやモノメディアなどのデータ、アプリケーション制御情報、データ放送アプリケーションなどのデータに関するシグナリング情報を符号化し、さらにブロックに分割されたモジュールとしてのＤＤＢメッセージを生成して、１以上のＤＤＢメッセージと各ＤＤＢメッセージの情報を記載したＤＩＩメッセージからなるデータ・カルーセルを組み立てて、ＴＳマルチプレクサー３０９に送る。

ＡＩＴエンコーダー３０６は、放送情報システム３０８から送出されるアプリケーション制御情報を符号化し、さらにパケット化して、ＡＩＴのＴＳパケットを含むエレメンタリー・ストリームをＴＳマルチプレクサー３０９に送る。但し、ＡＩＴをＤＤＢメッセージとしてデータ・カルーセル伝送方式により伝送する場合には、ＡＩＴエンコーダー３０６は不要である。すなわち、ＡＩＴエンコーダー３０６の装備は任意であり、点線で描いている。

ＰＳＩ／ＳＩエンコーダー３０７は、放送情報システム３０８から送出される番組構成情報や番組配列情報を符号化し、さらにパケット化して、ＰＳＩ並びにＩＳのＴＳパケットを含むエレメンタリー・ストリームをＴＳマルチプレクサー３０９に送る。

ＴＳマルチプレクサー３０９は、各エンコーダー３０３～３０７から送られてくるＴＳパケットをマルチプレクスして、図２に示したような放送信号２００を構成する。

変調・送信部３１０は、ＴＳマルチプレクサー３０９で生成された放送ストリームに対してＯＦＤＭ変調などのディジタル変調を施し、さらにアップコンバートなどのＲＦ（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ）変調処理を行なって、ＲＦ伝送路に送出する。

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

クロック生成部３０１では、各エンコーダー３０３～３０７を同期させるためのクロック信号ＳＴＣが生成されるとともに、受信機１２側でデコードに時刻同期を行なうための基準となるＰＣＲを含むＴＳパケットが生成される。

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

また、信号送出部３０２から送出されるオーディオ信号は、オーディオ・エンコーダー３０４に供給される。オーディオ・エンコーダー３０４では、オーディオ信号が符号化され、さらにパケット化されて、オーディオのＴＳパケットを含むエレメンタリー・ストリームが生成される。このオーディオ・エレメンタリー・ストリームは、ＴＳマルチプレクサー３０９に送られる。

また、データ・カルーセル・エンコーダー３０５では、放送情報システム３０８から送出される情報に基づいて、ＤＤＢメッセージとＤＩＩメッセージからなるデータ・カルーセルが構成されて、ＴＳマルチプレクサー３０９に送られる。

また、ＡＩＴがデータ・カルーセルのＤＤＢメッセージとして伝送されない場合には、ＡＩＴエンコーダー３０６では、放送情報システム３０８から送出される情報に基づいて、ＡＩＴのＴＳパケットを含むエレメンタリー・ストリームが生成されて、ＴＳマルチプレクサー３０９に送られる。

また、ＰＳＩ／ＳＩエンコーダー３０７では、放送情報システム３０８から送出される番組構成情報や番組配列情報に基づいてＰＳＩ並びにＩＳのＴＳパケットを含むエレメンタリー・ストリームが生成されて、ＴＳマルチプレクサー３０９に送られる。

ＴＳマルチプレクサー３０９では、各エンコーダー３０３～３０７から送られてくるＴＳストリームがマルチプレクスされて、放送ストリームが生成される。そして、変調・送信部３１０では、放送ストリームに対してＯＦＤＭなどのディジタル変調が施され、さらにアップコンバートなどのＲＦ変調処理が行なわれて、ＲＦ伝送路に送出される。

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

チューナー・復調部４０１は、ＩＦ（Ｉｎｔｅｒｍｅｄｉａｔｅ Ｆｒｅｑｕｅｎｃｙ）又はＲＦ変調信号を受信して、ダウンコンバートなどの復調処理、さらにはＯＦＤＭ復調などのディジタル復調処理を行なって、放送ストリームを得る。デマルチプレクサー４０２は、この放送ストリームに対して、デマルチプレクス処理及びデパケット化処理を行なって、ＰＣＲパケット、ビデオ・エレメンタリー・ストリーム、オーディオ・エレメンタリー・ストリーム、データ・カルーセル、ＡＩＴ（但し、ＡＩＴがデータ・カルーセルのＤＤＢメッセージとして伝送されない場合）、ＰＳＩ／ＳＩを出力する。なお、データ放送に利用されるファイル・データは、例えばＨＴＭＬ５形式で記述されたデータ放送アプリケーションである。

クロック再生部４０３は、ＰＣＲパケットから元の時計情報ＳＴＣを再生して、ビデオ・デコーダー４０４並びにオーディオ・デコーダー４０５の再生タイミングを制御する。

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

システム制御部４０９は、デマルチプレクサー４０２で得られるＰＳＩ並びにＳＩに基づいて、当該受信機１２の各部の動作を制御する。本実施形態では、システム制御部４０９は、ＰＳＩに含まれるＰＭＴの一部の情報を使って、アプリケーション・データ制御部４０６の動作を制御する。

アプリケーション・データ制御部４０６は、データ放送で利用される各ファイル・データの処理を行なう。本実施形態では、データ放送で利用される各ファイル・データは放送信号並びにＩＰネットワークの２系統から伝送されることを想定し、前者はチューナー・復調部４０１及びデマルチプレクサー４０２経由で、後者はＩＰインターフェース４１１経由で、それぞれアプリケーション・データ制御部４０６が取得する。

アプリケーション・データ制御部４０６は、デマルチプレクサー４０２から出力されるデータ・カルーセルのＤＩＩメッセージと、ＤＤＢメッセージに含まれるＤＤＭＴ、ＤＣＭＴに基づいて、データ放送サービス用のファイル・データのキャッシュ・メモリー４０７へのキャッシュ処理を制御する。また、アプリケーション・データ制御部４０６は、ＤＩＩメッセージと、ＤＤＢメッセージに含まれるＤＤＭＴ、ＤＣＭＴ、並びにＡＩＴに基づいて、データ放送アプリケーション・エンジン４０８によるアプリケーションの起動を制御する。データ放送アプリケーション・エンジン４０８は、ＨＴＭＬブラウザーなどであり、適宜キャッシュ・メモリー４０７にキャッシュされたファイル・データを用いて、データ放送アプリケーションを処理する。

本実施形態では、データ放送で利用される各ファイルの強制キャッシュを指定する情報がシグナリング情報（ＤＣＣＴ）に含まれている。アプリケーション・データ制御部４０６は、ＤＣＣＴに含まれている強制キャッシュ情報に基づいて、データ放送をタイムリーに提示するために必要なファイル・データをキャッシュ・メモリー４０７にプリキャッシュする。ファイル・データのプリキャッシュの詳細については後述に譲る。

合成部４１０は、ベースバンドのビデオ信号に、データ放送アプリケーション・エンジン４０８から出力されるデータ放送の表示信号を合成し、映像表示用のビデオ信号を得る。また、オーディオ・デコーダー４０５で得られるベースバンドのオーディオ信号は、音声出力用のオーディオ信号となる。ビデオ信号及びオーディオ信号からなる放送番組本編は、図示しないモニター・ディスプレイから映像及び音声出力される。また、データ放送アプリケーション・エンジン４０８が処理したデータ放送も、モニター・ディスプレイ上で放送番組本編の画面に重畳して表示される。

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

チューナー・復調部４０１では、ＩＦ又はＲＦ変調信号が受信され、ダウンコンバートなどの復調処理、さらにはＯＦＤＭ復調などのディジタル復調処理が行なわれて、放送ストリームが得られる。デマルチプレクサー４０２では、この放送ストリームに対して、デマルチプレクス処理及びデパケット化処理を行なわれ、ＰＣＲパケット、ビデオ・エレメンタリー・ストリーム、オーディオ・エレメンタリー・ストリーム、データ・カルーセル、ＡＩＴ（但し、ＡＩＴがデータ・カルーセルのＤＤＢメッセージとして伝送されない場合）、ＰＳＩ／ＳＩが抽出される。

デマルチプレクサー４０２で抽出されたＰＣＲパケットは、クロック再生部４０３に送られる。クロック再生部４０３では、ＰＣＲパケットから元の時計情報ＳＴＣが再生される。つまり、クロック再生部４０３では、放送送出システム１１側のクロック生成部３０１で生成された時刻情報に合った時刻情報が生成される。

デマルチプレクサー４０２で抽出された符号化ビデオ信号は、ビデオ・デコーダー４０４に送られてデコードされ、ベースバンドのビデオ信号が得られる。また、デマルチプレクサー４０２で抽出されたデータ・カルーセルはアプリケーション・データ制御部４０６に送られる。アプリケーション・データ制御部４０６では、ＤＩＩメッセージと、ＤＤＢメッセージに含まれるＤＤＭＴ、ＤＣＭＴ、並びにＡＩＴに基づいて、データ放送アプリケーション・エンジン４０８によるアプリケーションの起動が制御される。データ放送アプリケーション・エンジン４０８では、ＤＤＢメッセージとして伝送されるデータ放送アプリケーションのファイル・データが処理され、データ放送の表示信号が生成される。そして、合成部４１０では、ベースバンドのビデオ信号にデータ放送の表示信号が合成され、映像表示用のビデオ信号が得られる。

また、デマルチプレクサー４０２で抽出された符号化オーディオ信号はオーディオ・デコーダー４０５に送られてデコードされ、音声出力用のベースバンドのオーディ信号が得られる。ビデオ信号及びオーディオ信号からなる放送番組本編は、図示しないモニター・ディスプレイから映像及び音声出力される。

また、アプリケーション・データ制御部４０６では、デマルチプレクサー４０２から出力されるデータ・カルーセルのＤＩＩメッセージと、ＤＤＢメッセージに含まれるＤＤＭＴ、ＤＣＭＴに基づいて、データ放送サービス用のファイル・データのキャッシュ・メモリー４０７へのキャッシュ処理が制御される。

従来の日本のデータ放送サービスでは、アプリケーションの記述形式としてＢＭＬを採用し、データ・カルーセル伝送方式に基づき、モジュールという伝送単位がアプリケーションのディレクトリー構造に組み込まれ、また、モジュールに複数のファイルをマルチパート化してキャッシュ単位とすることが想定されている。このような伝送方式に由来して、アプリケーションを制作する上での制約が大きいという問題がある。

今後、ＨＴＭＬ５をデータ放送アプリケーションの記述形式に適用する場合、その汎用性の高さを保持するためにも、上記のような伝送方式に由来する制約を取り除くことが好ましい。

そこで、本明細書で開示する技術では、データ・カルーセル伝送方式でＨＴＭＬ５のデータ放送アプリケーションのデータを伝送する場合に、ファイル・ロケーション指定方式として、従来から適用されていた伝送路依存指定方式とＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｎｄｉｃａｔｏｒ）指定方式を選択的に利用できるようにする。

そして、ＰＭＴに配置するデータ符号化方式記述子（ｄａｔａ ｃｏｍｐｏｎｅｎｔ ｄｅｓｃｒｉｐｔｏｒ）において、ＨＴＭＬ５におけるデータ放送アプリケーションのデータ伝送を示すとともに、ＡＩＴの伝送配置、並びにＵＲＩ指定方式を選択した場合に適用するシグナリング情報（ＤＤＭＴ並びにＤＣＣＴ）の伝送配置情報を指定する。

また、ＡＩＴにおいて、データ・カルーセルのファイル・ロケーション指定方式が伝送路依存指定方式又はＵＲＩ指定方式のいずれであるかを指定する。

また、ＵＲＩ指定方式を実現するために、上述したＤＤＭＴ並びにＤＣＣＴというシグナリング情報を伝送する。シグナリング情報に関しては、以下の（１）～（４）のように規定する。

（１）ＤＤＭＴは、データ放送で伝送するファイルのディレクトリー構造を管理するテーブルである。図２に示したように、ＤＤＭＴを、データ・カルーセルの特定のモジュール（ＤＤＢメッセージ）として伝送する。

（２）ＤＣＣＴは、データ放送で伝送するコンテンツ（アプリケーション）毎のファイル構成、さらにはコンテンツ（アプリケーション）内のデータ放送提示単位（ＰＵ）毎のファイル構成、事前キャッシュ対象ファイルなどのコンテンツ構成とキャッシュ制御を示すテーブルである。図２に示したように、ＤＣＣＴを、データ・カルーセルの特定のモジュール（ＤＤＢメッセージ）として伝送する。

（３）これらのシグナリング情報としてのＤＤＭＴ並びにＤＣＣＴは、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）表記形式並びにバイナリー表記形式で表記される。

（４）ＤＤＭＴで示されるディレクトリー構造において、各ディレクトリーと各ファイルに対して共通のノード・タグを指定する。また、ＤＣＣＴにおいても、ノード・タグで指定する。さらに、ＤＩＩメッセージの各モジュール情報（ｍｏｄｕｌｅＩｎｆｏＢｙｔｅ）にノード・タグ記述子を配置して、ディレクトリーとモジュールの関連付けを行なう。これによって、ＤＩＩメッセージと、ＤＤＭＴ並びにＤＣＣＴの各テーブルとを関連付けることができる。

そして、受信機１２側では、上記２つのファイル・ロケーション指定方式の選択を含めたデータ放送アプリケーションの動作を行なう。

以下では、データ・カルーセル伝送方式において、ＨＴＭＬ５のデータ放送アプリケーションのデータを伝送する場合に、上記２つのファイル・ロケーション指定方式を実現する実施形態について、詳細に説明する。

図５には、ＰＭＴのデータ構造５００を示している。ＰＭＴのデータ構造は、基本的にはＩＳＯ／ＩＥＣ １３８１８－１の規定に従う。

ｔａｂｌｅ＿ｉｄには、当該テーブルがＰＭＴであることを識別する値"０ｘ０２"が記述される。また、ｓｅｃｔｉｏｎ＿ｓｙｎｔａｘ＿ｉｎｄｉｃａｔｏｒには、"１"が記述される。ｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈには、当該ＰＭＴのセクション長が記述される。また、ｐｒｏｇｒａｍ＿ｎｕｍｂｅｒには、当該サービス（放送チャンネル）を識別するｓｅｒｖｉｃｅ＿ｉｄが記述される。ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒには、当該ＰＭＴのバージョン情報が記述される。ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒには、"１"が記述される。ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒには、"０ｘ００"が記述される。ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒには、"０ｘ００"が記述される。 ＰＣＲ ＰＩＤには、ｐｒｏｇｒａｍ＿ｎｕｍｂｅｒで指定されるサービスのＰＣＲのパケット識別子（ＰＩＤ）が記述される。

ＰＭＴは、参照番号５０１で示す第１のループと、参照番号５０２で示す第２のループを含んでいる。

第１のループ５０１は、プログラム・ループである。当該ループ５０１の直前のｐｒｏｇｒａｍ＿ｉｎｆｏ＿ｌｅｎｇｔｈフィールドには、第１のループ５０１のループ長が記述される。そして、ｐｒｏｇｒａｍ＿ｉｎｆｏ＿ｌｅｎｇｔｈの数分だけ繰り返される第１のループ５０１で構成される記述子領域ｄｅｓｃｒｉｐｔｏｒ（）には、限定受信方式記述子、ディジタル・コピー制御記述子、緊急情報記述子といったプログラム情報記述子などが記述される。

第２のループ５０２は、各エレメンタリー・ストリームの情報を格納するＥＳループであり、各ループ内には属性情報としてｓｔｒｅａｍ＿ｔｙｐｅ、ｅｌｅｍｅｎｔａｒｙ＿ＰＩＤ、ＥＳ＿ｉｎｆｏ＿ｌｅｎｇｔｈが記述される。ｓｔｒｅａｍ＿ｔｙｐｅには、ループが対象とするエレメンタリー・ストリームの形式識別が記述される。ｅｌｅｍｅｎｔａｒｙ＿ＰＩＤには、関連するエレメンタリー・ストリーム又はペイロードを伝送するＴＳパケットの識別子（ＰＩＤ）が記述される。ＥＳ＿ｉｎｆｏ＿ｌｅｎｇｔｈには、後に続く記述子領域の長さが記述される。そして、ＥＳ＿ｉｎｆｏ＿ｌｅｎｇｔｈの長さの数分だけ繰り返されるループで構成される記述子領域ｄｅｓｃｒｉｐｔｏｒ（）には、ＥＳ記述子が格納される。ＥＳ記述子として、例えば、ストリーム識別記述子や限定受信方式記述子、ディジタル・コピー制御記述子、データ符号化方式記述子などが記述される。

データ符号化方式記述子は、データ放送用エレメンタリー・ストリームの場合のデータの符号化方式を示す記述子である。上述したように、本実施形態では、ＰＭＴに配置するデータ符号化方式記述子において、ＨＴＭＬ５におけるデータ放送アプリケーションのデータ伝送を示すとともに、ＡＩＴの伝送配置、並びにＵＲＩ指定方式を選択した場合に適用するシグナリング情報（ＤＤＭＴ並びにＤＣＣＴ）の伝送配置情報を指定する。

図６には、ＥＳ記述子の１つであるデータ符号化方式記述子（ｄａｔａ ｃｏｍｐｏｎｅｎｔ ｄｅｓｃｒｉｐｔｏｒ）のデータ構造６００を示している。

データ符号化方式記述子は、属性情報として、ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇと、ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈと、ｄａｔａ＿ｃｏｍｐｏｎｅｎｔ＿ｉｄを含んでいる。ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈには、後続のループ６０１のループ長が記述される。ｄａｔａ＿ｃｏｍｐｏｎｅｎｔ＿ｉｄは、該当するエレメンタリー・ストリームのデータの符号化方式を識別するのに使用される。この１６ビットのフィールド値の割り当ては、標準化機関の規定に従う。該当するエレメンタリー・ストリームが（例えばＨＴＭＬ５記述形式の）アプリケーションである場合には、アプリケーション伝送であることを識別する値がｄａｔａ＿ｃｏｍｐｏｎｅｎｔ＿ｉｄに記述される。ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇには、該当するエレメンタリー・ストリームのデータの符号化方式を識別する８ビットのタグ値が記述される。

ループ６０１で構成される領域には、付加識別情報（ａｄｄｉｔｉｏｎａｌ＿ｄａｔａ＿ｃｏｍｐｏｎｅｎｔ＿ｉｎｆｏ）が記述される。ａｄｄｉｔｉｏｎａｌ＿ｄａｔａ＿ｃｏｍｐｏｎｅｎｔ＿ｉｎｆｏには、識別子番号の拡張、又は符号化方式毎に規定される捕捉情報の格納に使用される。この領域に記述される情報のデータ構造は、データ符号化方式毎に別途規定される。本実施形態では、ＨＴＭＬ５におけるデータ放送アプリケーションのデータ伝送を示すとともに、ＡＩＴの伝送配置、並びにＵＲＩ指定方式を選択した場合に適用するシグナリング情報（ＤＤＭＴ並びにＤＣＣＴ）の伝送配置情報を指定する付加識別情報（Ａｄｄｉｔｉｏｎａｌ＿ｈｔｍｌ５＿ｉｎｆｏ（））をこの領域６０１に挿入する。

図７には、データ符号化方式記述子に付加識別情報として挿入されるＡｄｄｉｔｉｏｎａｌ＿ｈｔｍｌ５＿ｉｎｆｏ（）のデータ構造７００を示している。

ｓｉｇｎａｌｉｎｇ＿ｆｌａｇは、該当する（データ・カルーセルの）エントリー・ストリームがシグナリング情報のモジュール（ＤＤＢメッセージ）を含む場合には、１が設定される。上述したように、データ放送アプリケーションのファイル・ロケーション指定方式としてＵＲＩ指定方式を選択した場合には、各テーブルＤＤＭＴ並びにＤＣＣＴを伝送するモジュールがデータ・カルーセルに含まれる。

ａｉｔ＿ｆｌａｇは、該当する（データ・カルーセルの）エントリー・ストリームがアプリケーション情報テーブルＡＩＴのモジュール（ＤＤＢメッセージ）を含む場合には、１が設定される。上述したように、ＡＩＴは、データ・カルーセル又は独立したパケットのいずれかの方法で伝送される（図２を参照のこと）。

ａｐｐｌｉｃａｔｉｏｎ＿ｄａｔａ＿ｆｌａｇは、該当する（データ・カルーセルの）エントリー・ストリームがアプリケーション・データのモジュール（ＤＤＢメッセージ）を含む場合には、１が設定される。

ｓｉｇｎａｌｉｎｇ＿ｆｌａｇが１である場合、１６ビット長のｓｉｇｎａｌｉｎｇ＿ｍｏｄｕｌｅ＿ｉｄには、ＤＤＢメッセージとして伝送されるシグナリング・ファイルＤＤＭＴのデータ・カルーセル内でのモジュールＩＤが記述される。ＤＤＭＴが伝送される場合にはＤＣＭＴも伝送される。本実施形態では、ＤＤＭＴとＤＣＣＴのモジュールＩＤを連番とし（すなわち、ＤＣＣＴは＋１のモジュールＩＤ）、Ａｄｄｉｔｉｏｎａｌ＿ｈｔｍｌ５＿ｉｎｆｏ内での記述を省略する。各テーブルＤＤＭＴ並びにＤＣＣＴのデータ構造の詳細については、後述に譲る。

また、ａｉｔ＿ｆｌａｇが１である場合、ＡＩＴの属性情報ａｉｔ＿ｍｏｄｕｌｅ＿ｉｄ、ａｐｐｌｉｃａｔｉｏｎ＿ｔｙｐｅ、ａｐｐｌｉｃａｔｉｏｎ＿ｐｒｉｏｒｉｔｙ、及びＡＩＴ＿ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒが記述される。ａｉｔ＿ｍｏｄｕｌｅ＿ｉｄには、ＤＤＢメッセージとして伝送されるＡＩＴファイルのデータ・カルーセル内でのモジュールＩＤが記述される。ａｐｐｌｉｃａｔｉｏｎ＿ｔｙｐｅには、ＡＩＴで伝送するアプリケーション形式の値が記述される。アプリケーション形式がＨＴＭＬ５の場合、ａｐｐｌｉｃａｔｉｏｎ＿ｔｙｐｅは０ｘ００１０である。ａｐｐｌｉｃａｔｉｏｎ＿ｐｒｉｏｒｉｔｙには、ＡＩＴの制御対象となるアプリケーション・タイプの起動優先順位が記述される。ＡＩＴ＿ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒには、ＡＩＴに記述されバージョン番号が記述される。

また、ａｐｐｌｉｃａｔｉｏｎ＿ｄａｔａ＿ｆｌａｇが１である場合には、データ放送アプリケーションに対し、マルチパート化したモジュール伝送を適用しているか否かを示すｍｕｌｔｉｐａｒｔ＿ｕｓｅ＿ｆｌａｇ、複数のアプリケーションを伝送しているか否かを示すｍｕｌｔｉｐｌｅ＿ａｐｐ＿ｆｌａｇの各フラグが含まれる。

ＰＭＴの第２のループ内のＥＳ記述子の１つであるデータ符号化方式記述子に挿入されるＡｄｄｉｔｉｏｎａｌ＿ｈｔｍｌ５＿ｉｎｆｏ（）で、ＡＩＴの伝送配置、並びにシグナリング情報（ＤＤＭＴ並びにＤＣＣＴ）の伝送配置情報を指定される、という点を十分留意されたい。

図８には、データ・カルーセルのデータ構造８００を示している。図示のデータ・カルーセルは、ＤＩＩメッセージとＤＤＢメッセージを伝送するＤＳＭ－ＣＣセクションである。

ｔａｂｌｅ＿ｉｄ（テーブル識別子）には、ＤＳＭ－ＣＣセクションのペイロード中のデータの肩を識別する番号が格納される。このフィールドの値によって、ＤＳＭ－ＣＣセクション中の後続のフィールドに特定の符号化説明が適用される。ＤＳＭ－ＣＣセクションの型がＤＩＩメッセージの場合のｔａｂｌｅ＿ｉｄの値は０ｘ３Ｂ、ＤＤＢメッセージの場合のｔａｂｌｅ＿ｉｄの値はｏｘ３Ｃ、プライベート・データの場合のｔａｂｌｅ＿ｉｄは０ｘ３Ｅとなっている。

１ビットのフィールドｓｅｃｔｉｏｎ＿ｉｎｄｅｘ＿ｉｎｄｉｃａｔｏｒ（セクション・シンタクス指示）は、１の場合は当該セクションの末尾にＣＲＣ３２が存在することを示し、０の場合はチェックサムが存在することを示す。

１ビットのフィールドｐｒｉｖａｔｅ＿ｉｎｄｉｃａｔｏｒ（プライベート指示）には、セクション・シンタクス指示の値の反転値を格納する。

ｄｓｍｃｃ＿ｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈ（ＤＳＭ－ＣＣセクション長）には、当該フィールドの直後からセクションの末尾までのバイト長を示す。このフィールドの値が４０９５を超えることはない。

ｔａｂｌｅ＿ｉｄ＿ｅｘｔｅｎｔｉｏｎ（テーブル識別子拡張）は、ｔａｂｌｅ＿ｉｄに応じて、以下の（１）、（２）の通り設定する。

（１）ｔａｂｌｅ＿ｉｄが０ｘ３Ｂ（ＤＳＭ－ＣＣセクションの方がＤＩＩメッセージの場合）、トランザクション識別子の下位２バイトを設定する。
（２）ｔａｂｌｅ＿ｉｄが０ｘ３Ｃ（ＤＳＭ－ＣＣセクションの方がＤＤＢメッセージの場合）、モジュールＩＤを設定する。

ｔｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒ（バージョン番号）は、ｔａｂｌｅ＿ｉｄに応じて、以下の（１）、（２）の通り設定する。

（１）ｔａｂｌｅ＿ｉｄが０ｘ３Ｂ（ＤＳＭ－ＣＣセクションの方がＤＩＩメッセージの場合）、０に設定する。
（２）ｔａｂｌｅ＿ｉｄが０ｘ３Ｃ（ＤＳＭ－ＣＣセクションの方がＤＤＢメッセージの場合）、モジュール・バージョンの下位５ビットを設定する。

１ビットのｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒ（カレント・ネクスト指示）は、１の場合はサブテーブルが現在のサブテーブルであることを表す。また、０の場合は送られるサブテーブルはまだ適用されず、次のサブテーブルとして使用されることを示す。ｔａｂｌｅ＿ｉｄが０ｘ３Ａ～０ｘ３Ｃの場合は、常に１が指定される。

ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒ（セクション番号）は、セクションの番号を表す。当該セクションがＤＩＩメッセージを伝送する場合は、ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒを常に０に設定する。また、ＤＤＢメッセージを伝送する場合は、ＤＤＢのブロック番号の下位８ビットをｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒに格納する。

ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒ（最終セクション番号）は、当該セクションが属するサブテーブルの最後のセクション（すなわち、最大のセクション番号を持つセクション）の番号を示す。

ｔａｂｌｅ＿ｉｄが０ｘ３Ｂの場合は、ＤＳＭ－ＣＣセクションのｕｓｅｒＮｅｔｗｏｒｋＭｅｓｓａｇｅ（）にＤＩＩメッセージが格納される。また、ｔａｂｌｅ＿ｉｄが０ｘ３Ｃの場合は、ＤＳＭ－ＣＣセクションのｄｏｗｎｌｏａｄＤａｔａＭｅｓｓａｇｅ（）にＤＩＩメッセージが格納される。

図９には、ＤＳＭ－ＣＣセクション（データ・カルーセル）で伝送されるＤＩＩメッセージのデータ構造９００を示している。

ｄｓｍｃｃＭｅｓｓａｇｅＨｅａｄｅｒ（）には、データ・カルーセル伝送におけるＤＩＩメッセージであることを識別するヘッダー情報が記述される。

ｄｏｗｎｌｏａｄＩｄ（ダウンロード識別子）には、データ・カルーセルを識別するラベルが記述される。

ｂｌｏｃｋＳｉｚｅ（ブロック長）には、ＤＤＢメッセージで伝送されるデータの、モジュールの末尾以外の各ブロックのバイト長が記述される。

ｗｉｎｄｏｗＳｉｚｅ並びにａｃｋＰｅｒｉｏｄは、データ・カルーセル伝送においては使用せず、これらの値は０に設定される。

ｔＣＤｏｗｎｌｏａｄＷｉｎｄｏｗは、データ・カルーセル伝送においては使用せず、その値は０に設定される。また、ｔＣＤｏｗｎｌｏａｄＳＣｅｎａｒｉｏには、ダウンロードを開始してから終了するまでのタイムアウト時間がマイクロ秒単位で記述される。

ｃｏｍｐａｔｉｂｉｌｉｔｙＤｅｓｃｒｉｐｔｏｒ（）には、ＩＳＯ／ＩＥＣ１３８１８－６に規定されるｃｏｍｐａｔｉｂｉｌｉｔｙＤｅｓｃｒｉｐｔｏｒ（）構造が格納される。

ｎｕｍｂｅｒＯｆＭｏｄｕｌｅｓ（モジュール数）には、当該ＤＩＩメッセージの中の後続のループ中に記述されるモジュールの個数が記述される。そして、ｎｕｍｂｅｒＯｆＭｏｄｕｌｅｓ（モジュール数）だけ繰り返されるモジュール情報のループ９０１内では、データ・カルーセル伝送されるモジュール毎の情報が格納される。各モジュールの属性情報として、ｍｏｄｕｌｅＩｄ（モジュール識別子）、ｍｏｄｕｌｅＶｅｒｓｉｏｎ（モジュール・バージョン）、ｍｏｄｕｌｅＩｎｆｏＬｅｎｇｔｈ（モジュール情報長）が格納され、これらに続いて、ｍｏｄｕｌｅＩｎｆｏＬｅｎｇｔｈの数分だけ繰り返されるループで構成される記述子領域に、ｍｏｄｕｌｅＩｎｆｏＢｙｔｅ（モジュール情報）が格納される。ｍｏｄｕｌｅＩｎｆｏＢｙｔｅ（モジュール情報）は、該当するモジュールに関する記述子が可能される。ｍｏｄｕｌｅＩｄには、ｍｏｄｕｌｅＩｎｆｏＢｙｔｅ領域にて記述されるモジュールのモジュール識別子が格納される。本実施形態では、ＵＲＩ指定方式の場合には、ｍｏｄｕｌｅＩｎｆｏＢｙｔｅ（モジュール情報）として、該当するモジュールを指定するポインター情報であるノード・タグ記述子が記述される。ここで言うモジュールは、アプリケーションのデータ・モジュールや、ＤＤＭＴ並びにＤＣＣＴのシグナリング・モジュールである。ＤＤＭＴで示されるディレクトリー構造では、各ディレクトリーと各ファイルに対して共通のノード・タグを指定しており、ＤＣＣＴでも、ノード・タグで指定している（後述）。したがって、ＤＩＩメッセージのノード・タグ記述子を通じてディレクトリーとモジュールの関連付けを行なう。これによって、ＤＩＩメッセージと、ＤＤＭＴ並びにＤＣＣＴの各テーブルとを関連付けることができる。ノード・タグ記述子のデータ構造の詳細については、後述に譲る。

ｐｒｉｖａｔｅＤａｔａＬｅｎｇｔｈ（プライベート・データ長）にはプライベート・データ領域のバイト長が記述され、ｐｒｉｖａｔｅＤａｔａＬｅｎｇｔｈの数分だけ繰り返されるループで構成される記述子領域には、ｐｒｉｖａｔｅＤａｔａＢｙｔｅ（プライベート・データ）が格納される。プライベート・データとして、データ符号化方式にて定義されるデータ構造や、事業者毎に定義されるデータ構造が挙げられる。

図１０には、ＤＳＭ－ＣＣセクション（データ・カルーセル）で伝送されるＤＤＢメッセージのデータ構造１０００を示している。ＤＤＢメッセージは、データ・ブロックを伝送するデータ構造である。データ・ブロックは、モジュールを固定長のブロック単位に分割したものである。ＤＤＢメッセージにはブロック番号が割り当てられており、受信機１２側では、ブロック番号順にデータ・ブロックを並べることでモジュールを再構成する。また、ＤＤＢメッセージをＭＰＥＧ－２ ＴＳで伝送する際には、同じＰＩＤのパケットの中に、同じｄｏｗｎｌｏａｄＩＤを持つＤＤＢメッセージのみが含まれなければならない。すなわち、１本のエレメンタリー・ストリームの中に、異なる２つのデータ・カルーセルのＤＤＢメッセージが混在することは許されない。

ｄｓｍｃｃｄｏｗｎｌｏａｄＤａｔａＨｅａｄｅｒ（）には、データ・カルーセル伝送におけるＤＤＢメッセージであることを識別するヘッダー情報が記述される。ヘッダー情報の詳細については説明を省略するが、データ・カルーセルを一意に識別するｄｏｗｎｌｏａｄＩＤを含んでいる。

ｍｏｄｕｌｅＩｄには、該当するデータ・ブロックが属するモジュールの識別子が記述される。また、ｍｏｄｕｌｅＶｅｒｓｉｏｎには、該当するデータ・ブロックが属するモジュールのバージョン情報が記述される。

ｂｌｏｃｋＮｕｍｂｅｒ（ブロック番号）には、該当するデータ・ブロックのモジュール中での位置が記述される。モジュールの先頭のデータ・ブロックのブロック番号は０でなければならない。続く、Ｎ回だけ繰り返されるループで構成されるブロック・データ領域ｂｌｏｃｋＤａｔａＢｙｔｅには、データ・ブロック本体が格納される。

ｂｌｏｃｋＤａｔａＢｙｔｅに格納されるデータ・ブロックとして、データ放送のアプリケーション・データの他、ＤＤＭＴやＤＣＣＴなどのシグナリング・データのブロックが含まれる（但し、ファイル・ロケーション指定方式にＵＲＩ指定方式を選択した場合）。ＤＩＩメッセージのモジュール情報として格納されるノード・タグ記述子（後述）を用いて、データ・カルーセルの中から所望するデータ・ブロックをフィルタリングすることができる。但し、ＤＤＭＴ並びにＤＣＣＴのシグナリング・データのブロックに関しては、ＰＭＴの第２のループ内のデータ符号化方式記述子に挿入されるＡｄｄｉｔｉｏｎａｌ＿ｈｔｍｌ５＿ｉｎｆｏ（）の伝送配置情報（ｓｉｇｎａｌｉｎｇ＿ｍｏｄｕｌｅ＿ｉｄ）を用いてフィルタリングすることができる。すなわち、受信機１２側では、ＤＩＩメッセージを読み取る前に、ＰＭＴを受信した段階でＤＤＭＴ並びにＤＣＣＴのシグナリング・データのブロックをフィルタリングすることができる。なお、データ・カルーセルの中からデータ・ブロックをフィルタリングする手順の詳細については、後述に譲る。

図１１には、アプリケーション情報テーブル（ＡＩＴ）のデータ構造１１００を示している。ＡＩＴは、アプリケーションの起動、終了や、放送リソースへのアクセスを制御する信号である。ＡＩＴは、放送や通信路を経由して伝送される。本実施形態では、図２に示したように、ＡＩＴは、データ・ブロック（ＤＤＢメッセージ）の１つとしてデータ・カルーセル伝送され、又は、独立したパケットとして伝送されることを想定している。図１１に示すＡＩＴは、ＭＰＥＧ－２ Ｓｙｓｔｅｍｓ（ＩＴＵ－Ｔ Ｒｅｃ． Ｈ２２２．０、ＩＳＯ／ＩＥＣ １３８１８－１）において規定されるセクション形式によってアプリケーション制御情報を符号化する場合に使用する。なお、アプリケーション情報テーブル（ＡＩＴ）にはＸＭＬ記述方式も規定されており、データ・カルーセル伝送の場合にはそれを利用してもよい。

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

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

ａｐｐｌｉｃａｔｉｏｎ＿ｌｏｏｐ＿ｌｅｎｇｔｈは、このＭＨ ＡＩテーブルに含まれるアプリケーション情報の数を書き込む領域である。そして、ａｐｐｌｉｃａｔｉｏｎ＿ｌｏｏｐ＿ｌｅｎｇｔｈが示す数分だけ、アプリケーション情報記述子ループ１１０１が配置される。また、ＡＩＴの末尾には、ＩＴＵ－Ｔ勧告Ｈ．２２２．０に従う巡回冗長符号ＣＲＣ＿３２が付加される。

１つのアプリケーション情報記述子ループ１１０１内には、アプリケーションの属性情報として、ａｐｐｌｉｃａｔｉｏｎ＿ｉｄｅｎｔｉｆｉｅｒ（アプリケーション識別子）、ａｐｐｌｉｃａｔｉｏｎ＿ｃｏｎｔｒｏｌ＿ｃｏｄｅ（アプリケーション制御コード）、ａｐｐｌｉｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒ＿ｌｏｏｐ＿ｌｅｎｇｔｈ（アプリケーション情報記述子ループ長）が格納される。ａｐｐｌｉｃａｔｉｏｎ＿ｉｄｅｎｔｉｆｉｅｒは、アプリケーションを一意に識別する値である。ａｐｐｌｉｃａｔｉｏｎ＿ｃｏｎｔｒｏｌ＿ｃｏｄｅは、アプリケーションの状態を制御する制御コードである。ａｐｐｌｉｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒ＿ｌｏｏｐ＿ｌｅｎｇｔｈは、後続のアプリケーション情報記述子領域のバイト長を示す。そして、これらアプリケーションの属性情報に続いて、ａｐｐｌｉｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒ＿ｌｏｏｐ＿ｌｅｎｇｔｈが示す個数分のループからなる記述子領域にアプリケーション情報記述子ｄｅｓｃｒｉｐｔｏｒ（）が格納される。この記述子領域内の記述子は、対応するアプリケーションのみに適用される。

ａｐｐｌｉｃａｔｉｏｎ＿ｃｏｎｔｒｏｌ＿ｃｏｄｅのセマンティクスはアプリケーション形式毎に規定するが、アプリケーション形式毎に規定されない場合は、図１３に示すセマンティクスとする。ａｐｐｌｉｃａｔｉｏｎ＿ｃｏｎｔｒｏｌ＿ｃｏｄｅとして "ＡＵＴＯＳＴＡＲＴ（自動開始）"が指示されていたら、このＡＩＴテーブルを参照した受信機１２は、ａｐｐｌｉｃａｔｉｏｎ＿ｉｄｅｎｔｉｆｉｅｒで指定されたアプリケーションを起動開始する。また、ａｐｐｌｉｃａｔｉｏｎ＿ｃｏｎｔｒｏｌ＿ｃｏｄｅとして"ＰＲＥＦＥＴＣＨ"が指示されていたら、このＭＨ ＡＩＴテーブルを参照した受信機１２は、ａｐｐｌｉｃａｔｉｏｎ＿ｉｄｅｎｔｉｆｉｅｒで指定されたアプリケーションを先読みする。また、ａｐｐｌｉｃａｔｉｏｎ＿ｃｏｎｔｒｏｌ＿ｃｏｄｅとして"ＫＩＬＬ"が指示されていたら、このＡＩＴテーブルを参照した受信機１２は、ａｐｐｌｉｃａｔｉｏｎ＿ｉｄｅｎｔｉｆｉｅｒで指定されたアプリケーションの実行を終了する。

ＡＩＴのアプリケーション情報記述子ループ１１０１内の記述子領域には、アプリケーション情報記述子ｄｅｓｃｒｉｐｔｏｒとして、例えばアプリケーション記述子（ａｐｐｌｉｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒ）や伝送プロトコル記述子（ｔｒａｎｓｐｏｒｔ＿ｐｒｏｔｏｃｏｌ＿ｄｅｓｃｒｉｐｔｏｒ）などが格納されている。アプリケーション記述子により、アプリケーションを伝送するプロトコル（ＨＴＴＰ／ＨＴＴＰＳ伝送又はデータ・カルーセル伝送のいずれであるか）を指定する。また、伝送プロトコル記述子により、アプリケーションを伝送するプロトコルに加え、データ・カルーセル伝送の場合におけるファイル・ロケーション指定方式（伝送路依存指定方式又はＵＲＩ指定方式のいずれであるか）を指定する。簡易アプリケーション・ロケーション記述子（ｓｉｍｐｌｅ＿ａｐｐｌｉｃａｔｉｏｎ＿ｌｏｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒ）やアプリケーション境界権限設定記述子（ａｐｐｌｉｃａｔｉｏｎ＿ｂｏｕｎｄａｒｙ＿ａｎｄ＿ｐｅｒｍｉｓｓｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒ）など他のアプリケーション情報記述子もループ１１０１内に配置されるが、詳細な説明は説明を省略する。

図１４には、ＡＩＴのアプリケーション情報記述子ループ１１０１内の記述子領域ｄｅｓｃｒｉｐｔｏｒ（）に格納される、アプリケーション記述子のデータ構造１４００を示している。また、図１５には、アプリケーション記述子の各パラメーターのセマンティクスを示している。アプリケーション記述子は、ＡＩＴのアプリケーション情報記述子ループ１１０１において、アプリケーション毎に必ず１つ配置される。

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

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

ｓｅｒｖｉｃｅ＿ｂｏｕｎｄ＿ｆｌａｇは、本アプリケーションが現在のサービスのみで有効かどうかを示すフラグである。ｖｉｓｉｂｉｌｉｔｙは、本アプリケーション実行中にユーザーや他のアプリケーションに対して可視か否かを示す。ａｐｐｌｉｃａｔｉｏｎ＿ｐｒｉｏｒｉｔｙは、複数のアプリケーションが動作する場合のアプリケーション間の相対優先度である。

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

図１６には、ＡＩＴのアプリケーション情報記述子ループ１１０１内の記述子領域ｄｅｓｃｒｉｐｔｏｒ（）に格納される、伝送プロトコル記述子のデータ構造１６００を示している。伝送プロトコル記述子は、アプリケーションの伝送手段として、放送や通信などの伝送プロトコルの指定と伝送プロトコルに依存したアプリケーション・データのファイル・ロケーション指定方式を示すことを目的とした記述子である。伝送プロトコル記述子は、ＡＩＴの共通記述子ループ又はアプリケーション情報記述子ループ１１０１において、アプリケーション記述子の伝送プロトコル・ラベルの数分だけ配置される。

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

ｐｒｏｔｏｃｏｌ＿ｉｄ（プロトコル識別子）は、アプリケーションを伝送するプロトコルを示す。本実施形態では、ｐｒｏｔｏｃｏｌ＿ｉｄの値として、０ｘ０００３はＨＴＴＰ／ＨＴＴＰＳ伝送、０ｘ０００４は伝送路依存指定方式のデータ・カルーセル伝送、０ｘ０００６はＵＲＩ指定のデータ・カルーセル伝送を規定する。ｔｒａｎｓｐｏｒｔ＿ｐｒｏｔｏｃｏｌ＿ｌａｂｅｌ（伝送プロトコル・ラベル）は、１つのアプリケーションを複数の経路で伝送する場合にその伝送手段を一意に識別する値であり、アプリケーション記述子（図１４を参照のこと）の同名のフィールドに対応する。

ｓｅｌｅｃｔｏｒ＿ｂｙｔｅ（セレクター・バイト）は、プロトコル識別子毎に規定される補足情報を格納する領域であり、プロトコル識別子毎にシンタックスが規定される。本実施形態では、ｓｅｌｅｃｔｏｒ＿ｂｙｔｅには、アプリケーション・データの取得場所が書き込まれる。プロトコル識別子が３（すなわち、ＨＴＴＰ／ＨＴＴＰＳ伝送）及びプロトコル識別子が６（ＵＲＩ指定方式のデータ・カルーセル伝送）の場合と、プロトコル識別子が４（伝送路依存指定方式のデータ・カルーセル伝送）の場合とで、ｓｅｌｅｃｔｏｒ＿ｂｙｔｅのシンタックスが異なる。各々の場合のセレクター・バイトのシンタックスの詳細については、後述に譲る。

上述したように、本実施形態では、データ・カルーセル伝送方式でＨＴＭＬ５のデータ放送アプリケーションのデータを伝送する場合に、ファイル・ロケーション指定方式として、従来から適用されていた伝送路依存指定方式とＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｎｄｉｃａｔｏｒ）指定方式を選択的に利用することができる。

まず、伝送路依存指定方式について説明する。伝送路依存のファイル・ロケーション指定方式は、ネットワーク識別子、トランスポート・ストリーム識別子、サービス識別子、コンポーネント・タグ、モジュール識別子という放送伝送路の階層で、データ放送アプリケーションのファイル・データを指定する方法である。

ＡＩＴのアプリケーション情報記述子ループ１１０１に配置される伝送プロトコル記述子では、プロトコル識別子を４として、（従来通りの）伝送路依存指定方式のデータ・カルーセル伝送であることを示すとともに、セレクター・バイト領域で上記の放送伝送路の階層を指定する。

また、伝送路依存指定方式では、アプリケーション内において、ファイル・データを、上記のような伝送路の階層（ネットワーク識別子、トランスポート・ストリーム識別子、サービス識別子、コンポーネント・タグ、モジュール識別子）に基づいて、以下のような名前空間で指定する。

ａｒｉｂ－ｄｃ：／／＜ｎｅｔｗｏｒｋ＿ｉｄ＞．＜ｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄ＞．＜ｓｅｒｖｉｃｅ＿ｉｄ＞／＜ｃｏｍｐｏｎｅｎｔ＿ｔａｇ＞／＜ｍｏｄｕｌｅ＿ｉｄ＞／＜ｒｅｓｏｕｒｃｅ＿ｎａｍｅ＞

従来の伝送路依存指定方式では、ＤＤＭＴやＤＣＣＴというシグナリング情報は適用しない。したがって、ＤＤＭＴ並びにＤＣＣＴを（データ・カルーセルで）伝送しないので、データ放送アプリケーションの伝送効率と処理効率はよい。但し、データ・カルーセル伝送方式に由来して、アプリケーションを制作する上での制約が大きいと思料される（前述）。

次に、ＵＲＩ指定方式について説明する。この方式では、データ放送アプリケーションのファイル・データを任意のＵＲＩで指定することが可能である。

ＡＩＴのアプリケーション情報記述子ループ１１０１に配置される伝送プロトコル記述子では、プロトコル識別子を６として、ＵＲＩ指定方式のデータ・カルーセル伝送であることを示すとともに、セレクター・バイト領域でＵＲＩを指定する。また、アプリケーション内でも、ファイル・データをＵＲＩで指定する。

また、ＵＲＩ指定方式では、ＤＤＭＴやＤＣＣＴというシグナリング情報を適用する。ＤＤＭＴは、データ放送で伝送するファイルのディレクトリー構造を管理するテーブルである。また、ＤＣＣＴは、コンテンツ毎のファイル構成、さらにはコンテンツ内のデータ放送提示単位（ＰＵ）毎のファイル構成、事前キャッシュ対象ファイルなどのコンテンツ構成とキャッシュ制御を示すテーブルである。ＤＤＭＴ並びにＤＣＣＴを適用することにより、アプリケーション制作上の十分な自由度を確保することができる。また、放送と通信も統合的な扱いが可能になる。但し、ＤＤＭＴ並びにＤＣＣＴをデータ・カルーセルで伝送することに伴い、データ放送アプリケーションの伝送効率と処理効率は若干犠牲になる。

図１７には、（従来通りの）伝送路依存指定方式のデータ・カルーセル伝送の場合の、伝送プロトコル記述子内のセレクター・バイトのデータ構造１７００を示している。

ｒｅｍｏｔｅ＿ｃｏｎｎｅｃｔｉｏｎ（リモート接続）は、ＡＩＴとアプリケーションを伝送するデータ・カルーセルが同一サービスで伝送されていない場合は１（ＡＩＴが通信取得の場合も含む）、同一サービスで伝送されている場合は０である。

ｒｅｍｏｔｅ＿ｃｏｎｎｅｃｔｉｏｎが１、すなわち、ＡＩＴとアプリケーションを伝送するデータ・カルーセルが同一サービスで伝送されていない場合、ｏｒｉｇｉｎａｌ＿ｎｅｔｗｏｒｋ＿ｉｄ、ｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄ、ｓｅｒｖｉｃｅ＿ｉｄの各パラメーターが記述される。ｏｒｉｇｉｎａｌ＿ｎｅｔｗｏｒｋ＿ｉｄは、アプリケーションが伝送されているオリジナル・ネットワーク識別子である。ｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄは、アプリケーションが伝送されているトランスポート・ストリーム識別子である。ｓｅｒｖｉｃｅ＿ｉｄは、アプリケーションが伝送されているサービス識別子である。ｒｅｍｏｔｅ＿ｃｏｎｎｅｃｔｉｏｎが０、すなわち、ＡＩＴとアプリケーションを伝送するデータ・カルーセルが同一サービスで伝送される場合は、これらのパラメーターの記述は省略される。

ｃｏｍｐｏｎｅｎｔ＿ｔａｇには、アプリケーションが伝送されているサービス・コンポーネントを示すコンポーネント・タグ値が記述される。ＰＭＴの第２のループ内に配置されるＥＳ記述子の１つであるストリーム識別記述子で与えられるコンポーネント・タグによって、データ・カルーセルが伝送されるコンポーネント・ストリームを指定する。

図１８には、（従来通りの）伝送路依存指定方式のデータ・カルーセル伝送の場合における、ファイル指定方法を図解している。

受信機１２側では、ＰＭＴ（図５を参照のこと）のデータ・カルーセルのエレメンタリー・ストリームに相当する第２のループ内に記述されているデータ符号化方式記述子（ｄａｔａ＿ｃｏｍｐｏｎｅｎｔ＿ｄｅｓｃｒｉｐｔｏｒ）（図６を参照のこと）に挿入されたＡｄｄｉｔｉｏｎａｌ＿ｈｔｍｌ５＿ｉｎｆｏ（図７を参照のこと）に含まれているＡＩＴのモジュール識別子に基づいて、ＡＩＴを取得する（但し、ＡＩＴがデータ・カルーセル伝送方式で伝送される場合）。あるいは、ＡＩＴが独立したパケットとして伝送される場合には、ＡＩＴのエレメンタリー・ストリームに相当する第２のループ内に記述されているＡＩＴのパケット識別子（ＡＩＴ ＰＩＤ）に基づいて、ＡＩＴを取得する。

ＡＩＴのアプリケーション情報記述子ループ（図１１を参照のこと）内の記述子領域には、アプリケーション記述子（ａｐｐｌｉｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒ）や伝送プロトコル記述子（ｔｒａｎｓｐｏｒｔ＿ｐｒｏｔｏｃｏｌ＿ｄｅｓｃｒｉｐｔｏｒ）、簡易アプリケーション・ロケーション記述子（ｓｉｍｐｌｅ＿ａｐｐｌｉｃａｔｉｏｎ＿ｌｏｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒ）などが格納されている（前述）。

参照番号１８０１で示すように、所望するアプリケーションのアプリケーション記述子のトランスポート・プロトコル・ラベル（＝１）と一致する伝送プロトコル記述子をフィルタリングし、さらに参照番号１８０２で示すように、その伝送プロトコル記述子に格納されているセレクター・バイト（コンポーネント・タグ）に基づいて、データ・カルーセルが伝送されるコンポーネント・ストリームを指定する。また、データ・カルーセルの中からＤＩＩメッセージをフィルタリングすることができる。

また、簡易アプリケーション・ロケーション記述子には、対応するアプリケーションのエントリー・ポイントのＵＲＬを示す文字列（アプリケーション文字列）を含んでいる。このアプリケーション文字列は、伝送プロトコル記述子のセレクター・バイトで示されるアプリケーションの取得可能なロケーションをルートとした相対パスであり、図示の例では、アプリケーション文字列は、アプリケーションのモジュール識別子（図示の例では、００１０）とリソース名（図示の例では、ｉｎｄｅｘ．ｈｔｍｌ）の組み合わせからなる。

また、データ・カルーセル内の各モジュールは、モジュール識別子とリソース名を使って識別される。データ・カルーセルの中から、テーブル識別子（ｔａｂｌｅ＿ｉｄ）として０ｘ３Ｂが格納されているセクションをＤＩＩメッセージとして取得することができる。また、リソース名を使って、ＤＤＢメッセージをフィルタリングすることができる。

図１９には、（従来通りの）伝送路依存指定方式のデータ・カルーセル伝送の場合における、ディレクトリー構造を図解している。

ＤＩＩメッセージの各モジュールのループには、モジュールｍ₁、ｍ₂、…ｍ_k毎のポインター情報として、モジュール識別子（ｍｏｄｕｌｅ＿ｉｄ）及びモジュール名（ｍｏｄｕｌｅ＿ｎａｍｅ）が格納されている。また、モジュールがマルチパート化されている場合、そのＤＤＢメッセージは、マルチパート化したリソース（ファイル名）のリスト（Ｒｅｓｏｕｒｃｅ Ｌｉｓｔ：ＲＬ）と、マルチパート化した各リソース（ファイル・データ）で構成される。

伝送路依存指定方式のデータ・カルーセル伝送におけるディレクトリー構造は、伝送プロトコル記述子のセレクター・バイト（コンポーネント・タグ）で指定されるコンポーネントがルート・ディレクトリーに相当する。また、ＤＩＩメッセージのモジュールのループでモジュール識別子が列挙された各モジュールがサブディレクトリーに相当し、各サブディレクトリーの直下にマルチパート化されたファイル・データが配置される、というディレクトリー構造となる。

通信取得のＨＴＭＬ文書からＡ．ｈｔｍｌというモジュール（ファイル・データ）を参照する場合、リンクタグは下記の通りとなる。

ｈｒｅｆ＝ａｒｉｂ－ｄｃ：／／７ＥＥ９．７ＦＥ９．０４４８／４０／００００／Ａ．ｈｔｍｌ

また、Ａ．ｈｔｍｌからＢ．ｈｔｍｌを参照する場合、リンクタグは下記の通りとなる。

ｈｒｅｆ＝．．／０００１／Ｂ．ｈｔｍｌ

図２０には、伝送路依存指定方式のデータ・カルーセル伝送の場合におけるアプリケーション取得のシグナリング関係を図解している。

参照２００１で示すように、ＰＭＴ（図５を参照のこと）のデータ・カルーセルのエレメンタリー・ストリームに相当する第２のループ内に記述されているＰＩＤに基づいて、データ・カルーセルのパケットを指定することができる。

また、参照番号２００２で示すように、同第２のループ内に記述されているデータ符号化方式記述子（ｄａｔａ＿ｃｏｍｐｏｎｅｎｔ＿ｄｅｓｃｒｉｐｔｏｒ）（図６を参照のこと）に挿入されたＡｄｄｉｔｉｏｎａｌ＿ｈｔｍｌ５＿ｉｎｆｏ（図７を参照のこと）に含まれているＡＩＴのモジュール識別子（ａｉｔ＿ｍｏｄｕｌｅ＿ｉｄ）に基づいて、ＡＩＴを取得することができる（但し、ＡＩＴがデータ・カルーセル伝送方式で伝送される場合）。あるいは、参照番号２００３で示すように、ＡＩＴが独立したパケットとして伝送される場合には、ＡＩＴのエレメンタリー・ストリームに相当する第２のループ内に記述されているＡＩＴのパケット識別子（ＡＩＴ ＰＩＤ）に基づいて、ＡＩＴを取得することができる。

ＡＩＴのアプリケーション情報記述子ループ（図１１を参照のこと）内で、ａｐｐｌｉｃａｔｉｏｎ＿ｃｏｎｔｒｉｌ＿ｃｏｄｅが"ＡＵＴＯＳＴＡＲＴ（自動開始）"に指定されているアプリケーションの伝送プロトコル記述子のプロトコル識別子が４であることから、伝送路依存指定方式のデータ・カルーセル伝送であることを認識できる。そして、その伝送プロトコル記述子に記述されているセレクター・バイト（ｃｏｍｐｏｎｅｎｔ＿ｔａｇ）に基づいて、参照番号２００４で示すように、データ・カルーセル内のＤＩＩメッセージを取得する。

このようにして、参照番号２００５で示すように、同じアプリケーション情報記述子内の簡易アプリケーション・ロケーション記述子に含まれているモジュール識別子及びリソース名（図示の例では、"００１０／ｉｎｄｅｘ．ｈｔｍｌ"）と、ＤＩＩメッセージに記載されているｄｏｗｎｌｏａｄＩＤとの組み合わせに基づいて、該当するアプリケーション（ファイル・データ）を伝送するＤＤＢメッセージを指定することができる。

図２１には、ＨＴＴＰ／ＨＴＴＰＳ伝送並びにＵＲＩ指定方式のデータ・カルーセル伝送の場合の、伝送プロトコル記述子内のセレクター・バイトのデータ構造２１００を示している。

ＵＲＬ＿ｂａｓｅ＿ｌｅｎｇｔｈは、アプリケーションを取得するためのＵＲＬのベース部のバイト数を示す。ＵＲＬ＿ｂａｓｅ＿ｂｙｔｅは、ＵＲＬ＿ｂａｓｅ＿ｌｅｎｇｔｈの数分のループからなる一連の領域に、アプリケーションを取得するためのＵＲＬのベース部の文字列を格納する。

ＵＲＬ＿ｅｘｔｅｎｓｉｏｎ＿ｃｏｕｎｔは、アプリケーションを取得するためのＵＲＬの拡張部の数を示す。ＵＲＬ＿ｅｘｔｅｎｓｉｏｎ＿ｃｏｕｎｔの数分だけＵＲＬ＿ｅｘｔｅｎｓｉｏｎのループが配置される。そして、１つのＵＲＬ＿ｅｘｔｅｎｓｉｏｎのループ内では、アプリケーションを取得するためのＵＲＬの拡張部のバイト数を示すＵＲＬ＿ｅｘｔｅｎｔｉｏｎ＿ｂｙｔｅと、ＵＲＬ＿ｅｘｔｅｎｓｉｏｎ＿ｌｅｎｇｔｈの数分のループからなるＵＲＬ＿ｅｘｔｅｎｔｉｏｎ領域が配置され、ＵＲＬ＿ｅｘｔｅｎｔｉｏｎにはアプリケーションを取得するためのＵＲＬの拡張部の文字列を格納する。

要するに、図２１に示すセレクター・バイトは、アプリケーションを取得するためのＵＲＬの文字列を折り畳み方式で記述しており、文字列を連結すればＵＲＬを完成することができる。

なお、図２１に示すセレクター・バイトは、全体がループとなっていることにより、アプリケーションを取得できるＵＲＬのベース部を複数設定することができる。

図２２には、ＵＲＩ指定方式のデータ・カルーセル伝送の場合におけるファイル指定方法を示している。

受信機１２側では、ＰＭＴ（図５を参照のこと）のデータ・カルーセルのエレメンタリー・ストリームに相当する第２のループ内に記述されているデータ符号化方式記述子（ｄａｔａ＿ｃｏｍｐｏｎｅｎｔ＿ｄｅｓｃｒｉｐｔｏｒ）（図６を参照のこと）に挿入されたＡｄｄｉｔｉｏｎａｌ＿ｈｔｍｌ５＿ｉｎｆｏ（図７を参照のこと）に含まれているＡＩＴのモジュール識別子に基づいて、ＡＩＴを取得する（但し、ＡＩＴがデータ・カルーセル伝送方式で伝送される場合）。あるいは、ＡＩＴが独立したパケットとして伝送される場合には、ＡＩＴのエレメンタリー・ストリームに相当する第２のループ内に記述されているＡＩＴのパケット識別子（ＡＩＴ ＰＩＤ）に基づいて、ＡＩＴを取得する。

ＡＩＴのアプリケーション情報記述子ループ（図１１を参照のこと）内の記述子領域には、アプリケーション記述子（ａｐｐｌｉｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒ）や伝送プロトコル記述子（ｔｒａｎｓｐｏｒｔ＿ｐｒｏｔｏｃｏｌ＿ｄｅｓｃｒｉｐｔｏｒ）、簡易アプリケーション・ロケーション記述子（ｓｉｍｐｌｅ＿ａｐｐｌｉｃａｔｉｏｎ＿ｌｏｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒ）などが格納されている（前述）。

参照番号２２０１で示すように、所望するアプリケーションのアプリケーション記述子のトランスポート・プロトコル・ラベル（＝１）と一致する伝送プロトコル記述子をフィルタリングする。さらに、その伝送プロトコル記述子のセレクター・バイトに折り畳み方式で記述されているＵＲＬを完成させて、アプリケーションを取得するためのＵＲＬを得ると、参照番号２２０２で示すように、データ・カルーセルの中から、シグナリング情報ＤＤＭＴを伝送するＤＤＢメッセージをフィルタリングすることができる。

本実施形態では、ＤＤＭＴで示されるディレクトリー構造において、各ディレクトリーと各ファイルに対して共通のノード・タグを指定している。付言すれば、ＤＣＣＴにおいてもノード・タグで指定する。さらに、ＵＲＩ指定方式の場合には、ＤＩＩメッセージのモジュール情報（ｍｏｄｕｌｅＩｎｆｏＢｙｔｅ）にノード・タグ記述子を配置して、ディレクトリーとモジュールの関連付けを行なう。これによって、ＤＩＩメッセージと、ＤＤＭＴ並びにＤＣＣＴの各テーブルとを関連付けることができる。

ノード・タグ記述子のデータ構造の詳細については後述に譲る。参照番号２２０３で示すように、ＤＤＭＴに記述されているノード・タグ値に基づいて、データ・カルーセルからＤＩＩメッセージをフィルタリングする。さらに、参照番号２２０４で示すように、ＤＩＩメッセージに記載されているモジュール識別子に基づいて、所望するアプリケーション・データを伝送するＤＤＢメッセージをフィルタリングする。

図２３には、ＵＲＩ指定方式の場合に、ＤＩＩメッセージのモジュール情報（ｍｏｄｕｌｅＩｎｆｏＢｙｔｅ）に配置される、ノード・タグ記述子のデータ構造２３００を示している。

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

ｎｏｄｅ＿ｌｅｖｅｌは、当該ノード・タグが指定するノードのレベルを示す１ビットの値であり、ノードがモジュールであれば０が記入され、ノードがリソースであれば１が記入される。

ノード・レベルの値が０、すなわち、ノードがモジュールの場合には、１６ビット長のモジュールのノード・タグｎｏｄｅ＿ｔａｇが記述される。

一方、ノード・レベルの値が１、すなわち、ノードがリソースの場合には、モジュール内のリソース数ｒｅｓｏｕｒｃｅ＿ｎｕｍｂｅｒと、これに続くリソース数分のループ内で、各リソースのノード・タグｎｏｄｅ＿ｔａｇが記述される。

上述したように、データ・カルーセル伝送におけるファイル・ロケーション指定方式としてＵＲＩ指定方式を選択した場合、データ・ディレクトリー管理テーブル（ＤＤＭＴ）、データ・コンテント管理テーブル（ＤＣＣＴ）というシグナリング情報がＤＤＢメッセージとして伝送される（図２を参照のこと）。ＤＤＭＴ並びにＤＣＣＴは、ＸＭＬ表記形式並びにバイナリー表記形式で表記される。これらのシグナリング情報について説明しておく。

ＤＤＭＴは、データ放送で伝送するファイルのディレクトリー構造を管理するテーブルである。図２４には、バイナリー表記形式のＤＤＭＴのデータ構造２４００を示している。

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

ｂａｓｅ＿ｄｉｒｅｃｔｏｒｙ＿ｐａｔｈ＿ｌｅｎｇｔｈは、ｂａｓｅ＿ｄｉｒｅｃｔｏｒｙ＿ｐａｔｈ＿ｂｙｔｅの情報領域のサイズをバイト単位で表す。ｂａｓｅ＿ｄｉｒｅｃｔｏｒｙ＿ｐａｔｈ＿ｂｙｔｅは、ｂａｓｅ＿ｄｉｒｅｃｔｏｒｙ＿ｐａｔｈ＿ｌｅｎｇｔｈの数分のループからなる一連の情報領域に、ｂａｓｅ＿ｄｉｒｅｃｔｏｒｙ（上位のディレクトリー）へのパス名を格納する。ｂａｓｅ＿ｄｉｒｅｃｔｏｒｙ＿ｐａｔｈ＿ｂｙｔｅは、例えば、対応するディレクトリーへアクセスするための絶対的なＵＲＬ形式で表記される。

ｎｕｍ＿ｏｆ＿ｄｉｒｅｃｔｏｒｙ＿ｎｏｄｅｓは、当該ＤＤＭＴに記載されるディレクトリーのノードの数を示す。そして、ｎｕｍ＿ｏｆ＿ｄｉｒｅｃｔｏｒｙ＿ｎｏｄｅｓの数分だけディレクトリー・ノードのループ２４０１が配置される。

１つのディレクトリー・ノードのループ内には、当該ＤＤＭＴに格納される各ディレクトリー・ノードの情報と、ベース・ディレクトリーに含まれる各ファイル・データの情報が格納される。

ｄｉｒｅｃｔｏｒｙ＿ｎｏｄｅ＿ｐａｔｈ＿ｌｅｎｇｔｈは、ｄｉｒｅｃｔｏｒｙ＿ｎｏｄｅ＿ｐａｔｈ＿ｂｙｔｅの情報領域のサイズをバイト単位で表す。ｄｉｒｅｃｔｏｒｙ＿ｎｏｄｅ＿ｐａｔｈ＿ｂｙｔｅは、ｄｉｒｅｃｔｏｒｙ＿ｎｏｄｅ＿ｐａｔｈ＿ｌｅｎｇｔｈの数分のループからなる一連の情報領域で構成され、ｄｉｒｅｃｔｏｒｙ＿ｎｏｄｅへのパス名を格納する。ｄｉｒｅｃｔｏｒｙ＿ｎｏｄｅ＿ｐａｔｈ＿ｂｙｔｅは、例えば、対応するディレクトリーへアクセスするための、ｂａｓｅ＿ｄｉｒｅｃｔｏｒｙ＿ｐａｔｈからの相対的なＵＲＬ形式で表記される。例えば、ｂａｓｅ＿ｄｉｒｅｃｔｏｒｙのパス名（ＵＲＬ）が"ｈｔｔｐ：／／ｗｗｗ．ｘｂｃ．ｃｏｍ"で、あるｆｏｌｄｅｒ＿ｄｉｒｅｃｔｏｒｙのバス名（ＵＲＬ）が"ｉｎｄｅｘ．ｈｔｍｌ"であれば、これらの文字列を連結して、完全なＵＲＬ"ｈｔｔｐ：／／ｘｂｃ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌ"を得ることができる。

ｎｕｍ＿ｏｆ＿ｆｉｌｅｓは、当該ＤＤＭＴに記載されるファイルの数を示す。そして、ｎｕｍ＿ｏｆ＿ｆｉｌｅｓの数分だけファイル・ノードのループ２４０２が配置される。

１つのファイル・ノードのループ内には、ベース・ディレクトリーに含まれる各ファイル・データの情報として、ｎｏｄｅ＿ｔａｇと、ｆｉｌｅ＿ｎａｍｅ＿ｂｙｔｅ（ファイル名）が格納される。ｎｏｄｅ＿ｔａｇは、ＤＤＭＴで示されるディレクトリー構造において、各ディレクトリーと各ファイルを共通して指定する値である。ＤＣＣＴにおいても、ノード・タグで指定する。また、上述したようにＤＩＩメッセージのモジュール情報（ｍｏｄｕｌｅＩｎｆｏＢｙｔｅ）にノード・タグ記述子を配置して、ディレクトリーとモジュールの関連付けを行なう。ｆｉｌｅ＿ｎａｍｅ＿ｂｙｔｅ（ファイル名）は、ｆｉｌｅ＿ｎａｍｅ＿ｌｅｎｇｔｈの数分のループからなる一連のファイル名領域に格納される。

また、図２５には、ＸＭＬ表記形式のＤＤＭＴのデータ構造２５００を示している。ＤＤＭＴは、属性として、ルートとなるディレクトリーのＵＲＬ（＠ｂａｓｅＵＲＩ）と、要素としてディレクトリー・ノード（ｄｉｒｅｃｔｏｒｙ）を持つ。

各ディレクトリーは、属性として、ディレクトリーのノード・タグ（＠ｎｏｄｅＴａｇ）と、ディレクトリー・ノードのＵＲＬ（＠ｕｒｉ）とを持ち、要素として、ディレクトリーに含まれるファイル・ノード（ｆｉｌｅ）を持つ。

各ファイル・ノードは、属性として、ファイル・ノードのノード・タグ（＠ｎｏｄｅＴａｇ）と、ファイル・ノードの名称（＠ｎａｍｅ）を持つ。

ＸＭＬ表記形式のＤＤＭＴの記述例２６００を図２６に示しておく。

ＤＣＣＴは、データ放送で伝送するコンテンツ（アプリケーション）毎のファイル構成、さらにはコンテンツ（アプリケーション）内のデータ放送提示単位（ＰＵ）毎のファイル構成、事前キャッシュ対象ファイルなどのコンテンツ構成とキャッシュ制御を示すテーブルである。図２７には、バイナリー表記形式のＤＣＣＴのデータ構造２７００を示している。

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

ｎｕｍｂｅｒ＿ｏｆ＿ｃｏｎｔｅｎｔは、データ・カルーセル伝送されるコンテントの数を示す、８ビットのパラメーターである。コンテントは、例えば、ＨＴＭＬ５形式で記述されたデータ放送アプリケーションや、アプリケーションにおいて利用されるモノメディアなどのファイル・データである。ｎｕｍｂｅｒ＿ｏｆ＿ｃｏｎｔｅｎｔの数分だけ、以下のコンテントのループ２７０１が配置され、コンテント毎の情報が格納される。

１つのコンテントのループ内には、コンテントに関する情報として、ｃｏｎｔｅｎｔ＿ＩＤと、ｃｏｎｔｅｎｔ＿ｖｅｒｓｉｏｎと、ｃｏｎｔｅｎｔ＿ｃａｃｈｅ＿ｓｉｚｅと、当該コンテントに含まれるデータ放送提示単位（Ｐｒｅｓｅｎｔａｔｉｏｎ Ｕｎｉｔ：ＰＵ）に関する情報が書き込まれる。ｃｏｎｔｅｎｔ＿ＩＤは、コンテントの識別子である。ｃｏｎｔｅｎｔ＿ｖｅｒｓｉｏｎは、コンテントのバージョンを示す。ｃｏｎｔｅｎｔ＿ｃａｃｈｅ＿ｓｉｚｅは、コンテントをキャッシュするサイズを示す。また、ｎｕｍｂｅｒ＿ｏｆ＿ＰＵは、コンテントに含まれるデータ放送提示単位ＰＵの数であり、ｎｕｍｂｅｒ＿ｏｆ＿ＰＵの数分だけＰＵのループ２７０２が配置される。

１つのＰＵのループ内には、ＰＵの識別情報であるＰＵ＿ｔａｇと、ＰＵをキャッシュするサイズを示すＰＵ＿ｃａｃｈｅ＿ｓｉｚｅと、当該データ放送提示単位（ＰＵ）の中心となるファイル（ｐｒｉｍａｒｙ ｍｏｄｕｌｅ）を識別するＰＵ＿ｐｒｉｍａｒｙ＿ｍｏｄｕｌｅ＿ｎｏｄｅ＿ｔａｇが書き込まれる。

また、ＰＵのループ内には、当該データ放送提示単位（ＰＵ）を構成する放送伝送ファイルのリストが書き込まれる。具体的には、ｎｕｍｂｅｒ＿ｏｆ＿ＰＵ＿ｍｅｍｂｅｒ＿ｎｏｄｅｓは、当該データ放送提示単位（ＰＵ）に含まれる（すなわち、ＰＵのメンバーとなる）ノードの数を示す。その後に、このｎｕｍｂｅｒ＿ｏｆ＿ＰＵ＿ｍｅｍｂｅｒ＿ｎｏｄｅｓの数分だけのＰＵメンバー・ノードのループが配置され、各ＰＵメンバー・ノードのループ内には、ＰＵメンバー・ノードのｎｏｄｅ＿ｔａｇが書き込まれる。ＰＵメンバー・ノードは、ディレクトリーのノードとアイテムのノードを含む。

また、ＰＵのループ内には、該当するＰＵにおいてロック対象ファイルが存在する場合はその対象ファイル・リストの情報を記述する。具体的には、ｎｕｍｂｅｒ＿ｏｆ＿ｌｏｃｋ＿ｃａｃｈｅ＿ｎｏｄｅｓはロック対象となるノードの数であり、ｎｕｍｂｅｒ＿ｏｆ＿ｌｏｃｋ＿ｃａｃｈｅ＿ｎｏｄｅｓの数分だけのロック・キャッシュ・ノードのループが配置される。１つのロック・キャッシュ・ノードのループ内には、ロック・キャッシュ・ノードを識別するｌｏｃｋ＿ｃａｃｈｅ＿ｎｏｄｅ＿ｔａｇが書き込まれる。

また、ＰＵのループ内には、該当するＰＵにおいてアンロック対象ファイルが存在する場合はその対象ファイル・リストの情報を記述する。具体的には、ｎｕｍｂｅｒ＿ｏｆ＿ｕｎｌｏｃｋ＿ｃａｃｈｅ＿ｎｏｄｅｓはアンロック対象となるノードの数であり、ｎｕｍｂｅｒ＿ｏｆ＿ｕｎｌｏｃｋ＿ｃａｃｈｅ＿ｎｏｄｅｓの数分だけのロック・キャッシュ・ノードのループが配置される。１つのアンロック・キャッシュ・ノードのループ内には、アンロック・キャッシュ・ノードを識別するｕｎｌｏｃｋ＿ｃａｃｈｅ＿ｎｏｄｅ＿ｔａｇが書き込まれる。

ここで言うロック対象ファイルは、例えば、現在のデータ放送提示単位（ＰＵ）から次に参照するデータ放送提示単位（ＰＵ）で使用する放送ファイル・リストで構成される。放送番組の制作側では、このようにデータ放送のシグナリング情報でロック並びにアンロックの対象ファイル・リストを提示することで、受信機側ではロック並びにアンロックによるキャッシュ制御動作を行なうことができる。例えば、受信機側では、次に遷移するデータ放送提示単位に必要なファイル・データをキャッシュにロック（すなわち強制キャッシュ）しておくことができる。その結果、放送番組に連動したタイムリーなデータ放送サービスを実現することができる。また、アンロック対象ファイルは、例えば、現在のデータ放送提示単位（ＰＵ）では不要となる放送ファイル・リストで構成される。アンロック対象ファイルを指定（すなわち、強制キャッシュの指定を解除）することで、不要なファイルをキャッシュ・メモリー４０７から削除することができ、メモリー・サイズを節約することができる。

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

また、図２８には、ＸＭＬ表記形式のＤＣＣＴのデータ構造２８００を示している。ＤＤＭＴは、要素としてデータ・コンテント（ｃｏｎｔｅｎｔ）を持つ。

各データ・コンテントは、属性としてコンテント識別子（＠ｉｄ）と、コンテント・バージョン（＠ｖｅｒｓｉｏｎ）と、コンテント全体キャッシュ時のキャッシュ・サイズ（＠ｃａｃｈｅＳｉｚｅ）を持ち、要素としてプレゼンテーション・ユニット（ＰＵ）を持つ。

各プレゼンテーション・ユニットは、属性として、提示単位の識別タグ（＠ｔａｇ）と、提示単位キャッシュ時のキャッシュ・サイズ（＠ｃａｃｈｅＳｉｚｅ）と、提示単位内のプライマリー・ノードのノード・タグ（＠ｐｒｉｍａｒｙ）を持ち、要素として、提示単位を構成するノード（Ｍｅｍｂｅｒ）と、強制キャッシュ指定ノード（ｌｏｃｌＣａｃｈｅＮｏｄｅ）と、強制キャッシュ解除指定ノード（ｕｎｌｏｃｋＣａｃｈｅＮｏｄｅ）と、リンク先提示単位（ｌｉｎｋｅｄＰＵ）を持つ。

提示単位を構成するノード（Ｍｅｍｂｅｒ）は、属性としてノード・タグ（＠ｎｏｄｅＴａｇ）を持つ。強制キャッシュ指定ノード（ｌｏｃｌＣａｃｈｅＮｏｄｅ）は、属性としてノード・タグ（＠ｎｏｄｅＴａｇ）を持つ。強制キャッシュ解除指定ノード（ｕｎｌｏｃｋＣａｃｈｅＮｏｄｅ）は、属性としてノード・タグ（＠ｎｏｄｅＴａｇ）を持つ。リンク先提示単位（ｌｉｎｋｅｄＰＵ）は、属性として提示単位識別タグ（＠ｐｕＴａｇ）を持つ。

ＸＭＬ表記形式のＤＣＣＴの記述例２９００を図２９に示しておく。

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

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

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

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

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

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

図３０（Ｃ）には、コンテントを構成するファイル・データをデータ・カルーセル伝送する様子を模式的に示している。コンテントの構成要素であるアプリケーションやマテリアルなどのファイル・データは、ブロックに分割されたモジュール単位で伝送される。各モジュールは、データ・カルーセル伝送路において、ＤＤＢメッセージに相当する。データ・カルーセル伝送では、各モジュールにはそれぞれモジュール識別子（ｍｏｄｕｌｅＩｄ）が割り当てられる。図示の例では、ｃｏｎｔｅｎｔ１は、ｃｏｍｐｏｎｅｎｔ１のＥＳストリームとして伝送され、ＨＴＭＬ文書データやマテリアルなどのファイル・データを分割した各モジュールには、それぞれモジュール識別子としてｉ１１、ｉ１２、ｉ１３、ｉ１４が割り当てられている。

図２４に示したように、シグナリング情報ＤＤＭＴでは、ディレクトリー構造において、各ディレクトリーと各ファイルに対して共通のノード・タグを指定している。また、ＤＩＩメッセージにおいても、各モジュール情報（ｍｏｄｕｌｅＩｎｆｏＢｙｔｅ）にノード・タグ記述子を配置して、各モジュールとノード・タグとの関連付けを行なっているので、ノード・タグを指定することで、ディレクトリーとモジュールの関連付けを行なうことができる。

図３１には、ＵＲＩ指定方式のデータ・カルーセル伝送の場合におけるアプリケーション取得のシグナリング関係を図解している。

参照３１０１で示すように、ＰＭＴ（図５を参照のこと）のデータ・カルーセルのエレメンタリー・ストリームに相当する第２のループ内に記述されているＰＩＤに基づいて、データ・カルーセルのパケットを指定することができる。

また、参照番号３１０２で示すように、同第２のループ内に配置されているデータ符号化方式記述子（ｄａｔａ＿ｃｏｍｐｏｎｅｎｔ＿ｄｅｓｃｒｉｐｔｏｒ）（図６を参照のこと）に挿入されたＡｄｄｉｔｉｏｎａｌ＿ｈｔｍｌ５＿ｉｎｆｏ（図７を参照のこと）に含まれているＡＩＴのモジュール識別子（ａｉｔ＿ｍｏｄｕｌｅ＿ｉｄ）に基づいて、ＡＩＴを取得することができる（但し、ＡＩＴがデータ・カルーセル伝送方式で伝送される場合）。あるいは、参照番号３１０３で示すように、ＡＩＴが独立したパケットとして伝送される場合には、ＡＩＴのエレメンタリー・ストリームに相当する第２のループ内に記述されているＡＩＴのパケット識別子（ＡＩＴ ＰＩＤ）に基づいて、ＡＩＴを取得することができる。

ＡＩＴのアプリケーション情報記述子ループ（図１１を参照のこと）内で、ａｐｐｌｉｃａｔｉｏｎ＿ｃｏｎｔｒｉｌ＿ｃｏｄｅが"ＡＵＴＯＳＴＡＲＴ（自動開始）"に指定されているアプリケーションの伝送プロトコル記述子のプロトコル識別子が６であることから、ＵＲＬ指定方式のデータ・カルーセル伝送であることを認識できる。

また、参照番号３１０４、３１０５で示すように、同第２のループ内に記述されているデータ符号化方式記述子（ｄａｔａ＿ｃｏｍｐｏｎｅｎｔ＿ｄｅｓｃｒｉｐｔｏｒ）（図６を参照のこと）に挿入されたＡｄｄｉｔｉｏｎａｌ＿ｈｔｍｌ５＿ｉｎｆｏ（図７を参照のこと）に含まれている、ＤＤＭＴ及びＤＣＣＴの各シグナリング情報のモジュール識別子（ｓｉｇｎａｌｉｎｇ＿ｍｏｄｕｌｅ＿ｉｄ）に基づいて、ＤＤＭＴ及びＤＣＣＴを取得することができる（但し、ＡＩＴがデータ・カルーセル伝送方式で伝送される場合）。

そして、参照番号３１０６で示すように、ＤＤＭＴのディレクトリー・ノードのループ及びファイル・ノードのループ（前述）内で、ＡＩＴの伝送プロトコル記述子のセレクター・バイトに記述されているＵＲＬ文字列に一致するファイルを検索して、そのノード・タグを取得する。なお、アプリケーションで参照される他のＨＴＭＬ５文書への繊維が指定された場合も、参照番号３１１１で示すように、同様の処理となる。

なお、ＤＤＭＴ内でＵＲＬ文字列が一致するノードが見つからなかった場合には、そのＵＲＬに基づいて、通信（インターネット）経由で該当するアプリケーションのファイル・データを取得することができる。すなわち、放送と通信を区別することなくデータ放送アプリケーションを取得できることが、ＵＲＩ指定方式の利点の１つである。

次いで、参照番号３１０７で示すように、ＤＩＩメッセージのモジュール情報のループ（前述）内で、上記のノード・タグに一致するノード・タグ記述子を検索して、そのノード・タグに対応するモジュール識別子を取得する。

このようにして、参照番号３１０８で示すように、得られたモジュール識別子と、ＤＩＩメッセージに記載されているダウンロード識別子（ｄｏｗｎｌｏａｄＩＤ）との組み合わせに基づいて、データ・カルーセルの中から、該当するアプリケーション（ファイル・データ）を伝送するＤＤＢメッセージを指定することができる。

なお、"ＡＵＴＯＳＴＡＲＴ（自動開始）"に指定されているアプリケーションにリンクするノード（ディレクトリー並びにファイル）をキャッシュしたい場合には、参照番号３１０９で示すように、ＤＣＣＴのＰＵのループ（前述）内で該当するノード・タグを検索し、さらに、参照番号３１１０で示すように、ＰＵのループを探索して、リンク先のＰＵタグに基づいて事前キャッシュを行なったり、ロック対象ファイルの強制キャッシュやアンロック対象ファイルの強制キャッシュ指定の解除を行なったりすることができる。

図３２には、受信機１２においてディジタル放送の選局処理が行なわれたときに実行される、アプリケーション・データの取得及び起動処理の手順をフローチャートの形式で示している。

チューナー・復調部４０１は放送信号を選局受信し、デマルチプレクサー４０２は、この放送ストリームに対して、デマルチプレクス処理して元の各エレメンタリー・ストリームに分離するとともに、各エレメンタリー・ストリームのデパケット化処理を行なう。

まず、システム制御部４０９は、ＰＳＩ／ＳＩのエレメンタリー・ストリームから、ＰＩＤ＝０のＰＡＴを参照して該当する放送チャンネルのＰＡＴのＰＩＤを読み取って、ＰＭＴを取得する（ステップＳ３２０１）。

また、選局された放送チャンネルの映像及び音声の再生を開始する（ステップＳ３２０２）。具体的には、ビデオ・デコーダー４０４とオーディオ・デコーダー４０５は、クロック再生部４０３が再生した時計情報ＳＴＣに基づいて再生タイミングを同期させながら、それぞれ符号化ビデオ信号、符号化オーディオ信号をデコードして、ベースバンドのビデオ信号を得る。

ＡＩＴがモジュール（ＤＤＢメッセージ）としてデータ・カルーセル伝送される場合には（ステップＳ３２０３のＹｅｓ）、アプリケーション・データ制御部４０６は、ＰＭＴの第２のループ内に配置されたデータ符号化方式記述子に挿入されたＡｄｄｉｔｉｏｎａｌ＿ｈｔｍｌ５＿ｉｎｆｏ（図７を参照のこと）に含まれているＡＩＴのモジュール識別子（ａｉｔ＿ｍｏｄｕｌｅ＿ｉｄ）に基づいて、ＡＩＴを取得する（ステップＳ３２０４）。あるいは、ＡＩＴが独立したパケットとして伝送される場合には（ステップＳ３２０３のＮｏ）、アプリケーション・データ制御部４０６は、ＰＭＴの第２のループ内に記述されているＡＩＴのパケット識別子（ＡＩＴ ＰＩＤ）に基づいて、独立したコンポーネントからＡＩＴを取得する（ステップＳ３２０５）。

次いで、アプリケーション・データ制御部４０６は、取得したＡＩＴのアプリケーション情報記述子ループに配置された伝送プロトコル記述子のプロトコル識別子を参照して、データ・カルーセル伝送のファイル・ロケーション指定方式を判定する（ステップＳ３２０６）。

ここで、プロトコル識別子が４、すなわち伝送路依存指定方式の場合には、アプリケーション・データ制御部４０６は、ＡＩＴの伝送プロトコル記述子に記述されたセレクター・バイト（図１７を参照のこと）で指定されているコンポーネント・タグから、ＤＩＩメッセージを取得する（ステップＳ３２０７）。具体的には、データ・カルーセルの中から、テーブル識別子（ｔａｂｌｅ＿ｉｄ）として０ｘ３Ｂが格納されているセクションをＤＩＩメッセージとして取得する。次いで、アプリケーション・データ制御部４０６は、ＤＩＩメッセージの記載内容に基づいてアプリケーションのエントリー・モジュールを取得し（図１８、図２０を参照のこと）、また必要に応じてモジュールのキャッシュ処理を制御する（ステップＳ３２０８）。

一方、プロトコル識別子が６、すなわちＵＲＩ指定方式の場合には、アプリケーション・データ制御部４０６は、ＰＭＴでＰＩＤが指定されたデータ・カルーセルから、ＤＩＩメッセージと、各シグナリング情報ＤＤＭＴ及びＤＣＣＴを取得する（ステップＳ３２０９）。具体的には、データ・カルーセルの中から、テーブル識別子（ｔａｂｌｅ＿ｉｄ）として０ｘ３Ｂが格納されているセクションをＤＩＩメッセージとして取得する。また、図３１に示したように、ＰＭＴ（図５を参照のこと）の第２のループに配置されているデータ符号化方式記述子に挿入されたＡｄｄｉｔｉｏｎａｌ＿ｈｔｍｌ５＿ｉｎｆｏ（図７を参照のこと）に含まれているＤＤＭＴ及びＤＣＣＴの各シグナリング情報のモジュール識別子（ｓｉｇｎａｌｉｎｇ＿ｍｏｄｕｌｅ＿ｉｄ）に基づいて、ＤＤＭＴ及びＤＣＣＴを取得する。

アプリケーション・データ制御部４０６は、取得したＤＤＩメッセージと、各シグナリング情報ＤＤＭＴ及びＤＣＣＴを使って、起動するデータ放送アプリケーションに関連するファイル・データのロケーションを解決する（ステップＳ３２１０）。具体的には、図３１に示したように、ＡＩＴのアプリケーション情報記述子のループ内で、所望するアプリケーションのロケーションとして伝送プロトコル記述子のセレクター・バイトに記載されているＵＲＬ文字列と一致するファイル・データのノード・タグをＤＤＭＴから検索すると、続いて、そのノード・タグに関連付けられたモジュールのモジュール識別子をＤＩＩメッセージのモジュール情報のループ内で検索する。そして、得られたモジュール識別子とダウンロード識別子の組み合わせに基づいて、データ・カルーセルの中から、該当するアプリケーション（ファイル・データ）を伝送するモジュール（ＤＤＢメッセージ）を指定する。

そして、アプリケーション・データ制御部４０６は、上記のロケーション解決手段を用いて、アプリケーションのエントリー・モジュールを取得し（図２２、図３１を参照のこと）、また必要に応じてモジュールのキャッシュ処理を制御する（ステップＳ３２１１）。

本実施形態では、シグナリング情報としてのＤＣＣＴは、キャッシュ制御を示す情報として、ロック対象ファイルのノード・タグ、アンロック対象ファイルのノード・タグ、並びに、現在のデータ放送提示単位（ＰＵ）のリンク先提示単位のノード・タグを記述している。したがって、アプリケーション・データ制御部４０６は、ロック対象ファイル（例えば、次に遷移するデータ放送提示単位に必要なファイル・データ）を強制キャッシュしたり、アンロック対象ファイル（例えば、現在のデータ放送提示単位で不要となるファイル・データ）の強制キャッシュの指定を解除してキャッシュ４０７から削除したり、リンク先提示単位のファイル・データを事前にキャッシュしておいたりすることができる。

そして、アプリケーション・データ制御部４０６は、伝送路依存指定方式又はＵＲＩ指定方式の各々のファイル・ロケーション指定方式に従って取得したアプリケーションのエントリー・モジュールと、キャッシュ４０７にキャッシュされたファイル・データを用いて、データ放送アプリケーション・エンジン４０８によるアプリケーションの起動を制御する（ステップＳ３２１１）。

上述したように、本実施形態では、ＵＲＩ指定方式で適用されるシグナリング情報ＤＣＣＴは、キャッシュ制御を示す情報として、ロック対象ファイルのノード・タグ、アンロック対象ファイルのノード・タグ、並びに、現在のデータ放送提示単位（ＰＵ）のリンク先提示単位のノード・タグを記述している。したがって、アプリケーション・データ制御部４０６は、ロック対象ファイル（例えば、次に遷移するデータ放送提示単位に必要なファイル・データ）を強制キャッシュしたり、アンロック対象ファイル（例えば、現在のデータ放送提示単位で不要となるファイル・データ）の強制キャッシュの指定を解除してキャッシュ４０７から削除したりすることができる。また、リンク先提示単位のファイル・データを事前にキャッシュしておくこともできる。

受信機１２において、シグナリング情報ＤＣＣＴに基づいて、データ・カルーセル伝送されるモジュールをロック及びアンロックによるキャッシュ動作を制御する大まかな手順を以下に示す。

（動作１）アプリケーション・データ制御部４０６は、データ・カルーセル伝送されるシグナリング情報ＤＤＭＴ及びＤＣＣＴを適宜検出して更新を行ないつつ、最新の情報を取得する。
（動作２）アプリケーション・データ制御部４０６が、データ放送アプリケーション制御エンジン４０８などからの指示によりｐｒｉｍａｒｙ ｍｏｄｕｌｅに指定された（データ放送提示単位の中心となる）アプリケーション・ファイルにアクセスすることにより、対応するデータ放送提示単位（ＰＵ）の提示状態に入ったことを認識する。
（動作３）アプリケーション・データ制御部４０６は、ＤＣＣＴにおいて、該当するデータ放送提示単位（ＰＵ）に含まれる各メンバー・ファイル（ＰＵ＿ｍｅｍｂｅｒ＿ｎｏｄｅ）も同時に取得して、キャッシュ・メモリー４０７に保持する。
（動作４）さらに、ＤＣＣＴ内で、該当するデータ放送提示単位（ＰＵ）に対してロックキャッシュの対象が指定されている場合には、アプリケーション・データ制御部４０６は、ロックキャッシュ対象のうち未取得の各ファイル（モジュール）も取得して、キャッシュ・メモリー４０７にキャッシュし、且つ、ロックキャッシュ対象ファイルとして別途管理する。
（動作５）逆に、ＤＣＣＴ内で、該当するデータ放送提示単位（ＰＵ）に対してアンロックキャッシュの対象に指定されている場合には、アプリケーション・データ制御部４０６は、アンロック対象ファイルがキャッシュ・メモリー４０７にキャッシュされていれば、これを削除するとともに、別途管理していたロックキャッシュ対象ファイルからも削除する。
（動作６）データ放送アプリケーション・エンジン４０８は、ｐｒｉｍａｒｙ ｍｏｄｕｌｅに指定されたアプリケーション・ファイルを、キャッシュ・メモリー４０７から実行する。
（動作７）その後、ＤＣＣＴの更新により、現在提示状態にあるデータ放送提示単位（ＰＵ）に含まれるメンバー・ファイル（ＰＵ＿ｍｅｍｂｅｒ＿ｎｏｄｅ）やロックキャッシュ対象又はアンロック対象のファイルの構成が変化した場合には、上記の（動作３）～（動作６）の処理を行なう。
（動作８）データ放送アプリケーション・エンジン４０８におけるアプリケーション動作により他のデータ放送提示単位（ＰＵ）の提示状態に遷移した場合には、ロックキャッシュ対象のファイルは一旦キャッシュ・メモリー４０７に保持した上で、上記の（動作３）～（動作６）の処理を行なう。ロックキャッシュ対象以外のファイルは、キャッシュ・メモリー４０７から削除してもよい。

図３３には、受信機１２におけるロック及びアンロックによるキャッシュ制御手順をフローチャートの形式で示している。

データ放送アプリケーション制御エンジン４０８がアプリケーション動作すなわちデータ放送の提示を行なっているときに（ステップＳ３３０１のＹｅｓ）、アプリケーション・データ制御部４０６は、データ・コンテント・マネジメント・テーブル内でｐｒｉｍａｒｙ＿ｍｏｄｕｌｅ（データ放送提示単位の中心）に指定されたアプリケーション・ファイルにアクセスすることにより（ステップＳ３３０２のＹｅｓ）、対応するデータ放送提示単位（ＰＵ）の提示状態に入ったことを認識する。

アプリケーション・データ制御部４０６は、キャッシュ・メモリー４０７をリセットして、ＤＣＣＴにおいて、現在提示しているデータ放送提示単位（ＰＵ）のｐｒｉｍａｒｙ＿ｍｏｄｕｌｅ並びに各メンバーのノード・タグ（ＰＵ＿ｍｅｍｂｅｒ＿ｎｏｄｅ＿ｔａｇ）を取得して、キャッシュ・メモリー４０７に保持する（ステップＳ３３０３）。データ放送アプリケーション・エンジン４０８は、ｐｒｉｍａｒｙ＿ｍｏｄｕｌｅに指定されたアプリケーション・ファイルを、キャッシュ・メモリー４０７から実行する。

また、アプリケーション・データ制御部４０６は、データ・コンテント・マネジメント・テーブル内で、該当するデータ放送提示単位（ＰＵ）に対してロックキャッシュの対象が指定されているかどうかをチェックする（ステップＳ３３０４）。そして、ロックキャッシュの対象が指定されている場合には（ステップＳ３３０４のＹｅｓ）、アプリケーション・データ制御部４０６は、ロックキャッシュ対象のうち未取得の各ファイル（モジュール）も取得して、キャッシュ・メモリー４０７にキャッシュし、且つ、ロックキャッシュ対象ファイルとして別途管理する（ステップＳ３３０５）。

また、アプリケーション・データ制御部４０６は、ＤＣＣＴ内で、該当するデータ放送提示単位（ＰＵ）に対してアンロックキャッシュの対象が指定されているかどうかをチェックする（ステップＳ３３０６）。そして、アンロックキャッシュの対象が指定されている場合には（ステップＳ３３０６のＹｅｓ）、アプリケーション・データ制御部４０６は、アンロック対象ファイルがキャッシュ・メモリー４０７にキャッシュされていれば、これを削除するとともに、別途管理していたロックキャッシュ対象ファイルからも削除する（ステップＳ３３０７）。

その後、ＤＣＣＴの更新により、現在提示状態にあるデータ放送提示単位（ＰＵ）に含まれるメンバー・ノード（ＰＵ＿ｍｅｍｂｅｒ＿ｎｏｄｅ）やプリキャッシュ対象のファイルの構成が変化した場合には（ステップＳ３３０８のＹｅｓ）、ステップＳ３３０３に戻り、現在提示状態にあるデータ放送提示単位（ＰＵ）において、上記の処理を繰り返し実行する。

また、データ放送アプリケーション・エンジン４０８におけるアプリケーション動作により他のデータ放送提示単位（ＰＵ）の提示状態に遷移し、そのデータ放送提示単位のｐｒｉｍａｒｙ＿ｍｏｄｕｌｅに指定されたアプリケーション・ファイルにアクセスした場合には（ステップＳ３３０９のＹｅｓ）、ステップＳ３３０３に戻り、遷移した先のデータ放送提示単位（ＰＵ）において、上記の処理を繰り返し実行する。

以上の処理を、データ放送アプリケーション・エンジン４０８がアプリケーション動作を終了するまで（ステップＳ３３１０のＮｏ）、繰り返し実行する。

図３４には、受信機１２におけるファイル・データのキャッシュのロック及びアンロック動作例を示している。

アプリケーション・データ制御部４０６は、データ・カルーセルから受信する各種シグナリング・メッセージを解析している。シグナリング情報の１つであるデータ・コンテント・マネジメント・テーブル（ＤＣＣＴ）が含まれている。

データ放送アプリケーション制御エンジン４０８がＰＵ＿ｔａｇ＝１で識別されるデータ放送提示単位（ＰＵ）のアプリケーション動作を行なっているとき、アプリケーション・データ制御部４０６は、ＤＣＣＴを参照して、現在提示状態にあるデータ放送提示単位（ＰＵ＿ｔａｇ＝１）のＰｒｉｍａｒｙ＿ｍｏｄｕｌｅ（データ放送提示単位の中心）に指定されたアプリケーション・ファイル「Ａ０１．ｈｔｍｌ」、並びに、各メンバー（ＰＵ＿ｍｅｍｂｅｒ＿ｎｏｄｅ）「Ｂ０１」、「Ｂ０２」それぞれのｎｏｄｅ＿ｔａｇをデータ・コンテント・マネジメント・テーブルから取得して、データ・カルーセルからこれらのｎｏｄｅ＿ｔａｇに対応するモジュールを取得すると、参照番号３４０１で示すように、キャッシュ・メモリー４０７にキャッシュする。但し、このデータ放送提示単位（ＰＵ）に対してロックキャッシュの対象が指定されていないので、キャッシュ動作は行なわない。なお、ｎｏｄｅ＿ｔａｇからデータ・カルーセル伝送されるモジュールにアクセスする方法については、図３１を参照しながら説明した通りである（ＤＩＩメッセージでｎｏｄｅ＿ｔａｇに対応するモジュール識別子（ｍｏｄｕｌｅＩｄ）とｄｏｗｎｌｏａｄＩＤの組み合わせに基づいて、データ・カルーセルの中から該当するモジュールをフィルタリングすることができる）。

次いで、データ放送アプリケーション・エンジン４０８におけるアプリケーション動作により、ＰＵ＿ｔａｇ＝３で識別される他のデータ放送提示単位（ＰＵ）の提示状態に遷移したとする。アプリケーション・データ制御部４０６は、上記と同様に、遷移した先のデータ放送提示単位（ＰＵ＿ｔａｇ＝３）のＰｒｉｍａｒｙ＿ｍｏｄｕｌｅ（データ放送提示単位の中心）に指定されたアプリケーション・ファイル「Ａ１１．ｈｔｍｌ」、並びに、各メンバー（ＰＵ＿ｍｅｍｂｅｒ＿ｎｏｄｅ）「Ｂ１１」、「Ｂ１２」、「Ｂ１３」それぞれのｎｏｄｅ＿ｔａｇをＤＣＣＴから取得すると、データ・カルーセルからこれらのｎｏｄｅ＿ｔａｇに対応するモジュールを取得して、参照番号３４０２で示すように、キャッシュ・メモリー４０７にキャッシュする。但し、このデータ放送提示単位（ＰＵ）に対してロックキャッシュの対象が指定されていないので、ロックキャッシュ動作は行なわない。

アプリケーション・データ制御部４０６は、データ・カルーセルから受信するシグナリング情報ＤＤＭＴ及びＤＣＣＴを常に解析している。そして、参照番号３４０３で示すように、ＤＣＣＴのバージョンが１から２に更新されたことを検出すると、アプリケーション・データ制御部４０６は、現在提示状態にあるデータ放送提示単位（ＰＵ＿ｔａｇ＝３）のＰｒｉｍａｒｙ＿ｍｏｄｕｌｅ並びに各メンバー・ファイル、ロックキャッシュ対象のファイルに変更がないかどうかをチェックする。今回はメンバー・ファイルに変更がないので、以前キャッシュしておいた各メンバー・ファイルはキャッシュ・メモリー４０７に保持したままとする。また、データ放送提示単位（ＰＵ＿ｔａｇ＝３）のロックキャッシュ対象のファイルとして「Ａ１２」、「Ｂ１４」、「Ｂ１２」、「Ｂ１５」が追加されているので、アプリケーション・データ制御部４０６は、データ・カルーセルからこれらのｎｏｄｅ＿ｔａｇに対応するモジュールを取得して、参照番号３４０４で示すように、キャッシュ・メモリー４０７にキャッシュするとともに、ロックキャッシュ対象ファイルとして別途管理する。図中、ロックキャッシュ対象として管理されているファイルを下線で示している（以下、同様）。

次いで、参照番号３４０５で示すように、データ放送の提示の更新を指示するイベント・メッセージを受信すると、データ放送アプリケーション・エンジン４０８は、実行中のＡ１１ファイルからＡ１２ファイルへのＨＴＭＬ５文書の遷移を行なう。一方でほぼ同時に、アプリケーション・データ制御部４０６は、バージョンが２から３に更新されたＤＣＣＴを参照して、現在提示状態にあるデータ放送提示単位（ＰＵ＿ｔａｇ＝３）のＰｒｉｍａｒｙ＿ｍｏｄｕｌｅが「Ａ１２．ｈｔｍｌ」に変更するとともに、メンバー・ファイルが「Ｂ１４」、「Ｂ１５」、「Ｂ１６」に変更したことを検出する。上述したように、Ｐｒｉｍａｒｙ＿ｍｏｄｕｌｅ「Ａ１２．ｈｔｍｌ」並びにメンバー・ファイルが「Ｂ１４」、「Ｂ１５」は既にキャッシュ・メモリー４０７にロックキャッシュされているので、データ放送アプリケーション・エンジン４０８は、キャッシュ・メモリー４０７に保持されているファイルを利用してデータ放送を迅速に表示することができる。すなわち、放送番組に連動したタイムリーなデータ放送の提示を行なうことができる。また、このデータ放送提示単位（ＰＵ）に対してロックキャッシュの対象が指定されていないので、ロックキャッシュ動作は行なわない。参照番号３４０６で示すように、ロックキャッシュされたファイル「Ａ１２」、「Ｂ１４」、「Ｂ１２」、「Ｂ１５」がそのままキャッシュ・メモリー４０７に保持される一方、不要になったファイル「Ａ１１」が削除されている。

さらに、データ放送の提示の更新を指示するイベント・メッセージを受信すると、アプリケーション・データ制御部４０６は、ＤＣＣＴを参照して、現在提示状態にあるデータ放送提示単位（ＰＵ＿ｔａｇ＝３）に対して、ロックキャッシュ対象のファイルとして「Ｂ１７」が追加されているとともに、アンロック対象ファイルとして「Ｂ１４」が追加されている。そこで、参照番号３４０７で示すように、アプリケーション・データ制御部４０６は、データ・カルーセルからファイル「Ｂ１７」のｎｏｄｅ＿ｔａｇに対応するモジュールを取得してキャッシュ・メモリー４０７にロックキャッシュするとともに、ロックキャッシュしていたファイル「Ｂ１２」をキャッシュ・メモリー４０７から削除し、ロック対象から外す。

現在運用されているＢＭＬ（Ｂｒｏａｄｃａｓｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）によるデータ放送サービスでは、スクリプトから「ＬｏｃｋＭｏｄｕｌｅＯｎＭｅｍｏｒｙ（）」というＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を呼び出すことにより、特定のファイルをあらかじめキャッシュ・メモリーにプリキャッシュして留めておくことが可能である（例えば、特許文献４を参照のこと）。この方法は、スクリプトなどのアプリケーションの仕様に、放送運用を前提とする特殊な仕様を盛り込む必要がある。

これに対し、本明細書で開示する技術によれば、放送局などの送信側からは、データ放送に関わるシグナリングに、強制キャッシュを指定する情報を含めて伝送し、受信機側では、受信したデータ放送に関わるシグナリングに含まれている強制キャッシュ情報に基づいてデータ放送用の各ファイルのキャッシュ制御を行なうようになっている。したがって、本明細書で開示する技術によれば、新しいＨＴＭＬ５によるデータ放送において、スクリプトなどのアプリケーションの仕様に、放送運用を前提とする特殊な仕様を盛り込むことなく、汎用性の高いフォーマットを維持することができる。

特開２０１３－１５３２９１号公報 特開２０１３－９３３７号公報 特開２０１３－６６１６０号公報 特開２００７－２７４１９３号公報

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

本明細書で開示する技術は、データ放送に用いるファイル・データをデータ・カルーセル伝送方式で伝送するさまざまな放送システムに適用することができる。本明細書では、トランスポート方式としてＭＰＥＧ－２ ＴＳ方式を採用する放送システムに適用した実施形態について説明してきたが、本明細書で開示する技術はこれに限定される訳ではない。

また、本明細書では、データ放送アプリケーションの記述形式にＨＴＭＬ５を使用した実施形態について説明してきたが、本明細書で開示する技術はこれに限定されるものではなく、さまざまなデータ放送サービスに適用することができる。

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

なお、本明細書の開示の技術は、以下のような構成をとることも可能である。
（１）伝送路依存指定方式又はＵＲＩ指定方式のいずれかでファイル・ロケーションを指定して、データ放送アプリケーションのデータをデータ・カルーセル伝送方式によりエンコードする第１のエンコーダーと、
前記データ放送アプリケーションに関するアプリケーション情報テーブル（ＡＩＴ）の伝送配置情報を指定するデータ符号化方式記述子を配置したプログラム管理テーブル（ＰＭＴ）を含んだプログラム固有情報（ＰＳＩ）をエンコードする第２のエンコーダーと、
前記第１及び第２のエンコーダーでそれぞれエンコードされた放送データを含む複数の放送データを多重化して送信処理する送信処理部と、
を具備する送信装置。
（２）前記アプリケーション情報テーブル（ＡＩＴ）において、データ・カルーセルの伝送路依存指定方式とＵＲＩ指定方式を指定する、
上記（１）に記載の送信装置。
（３）ＵＲＩ指定方式を選択した場合に適用されるシグナリング情報（ＤＤＭＴ、ＤＣＣＴ）の伝送配置情報を、前記プログラム管理テーブル（ＰＭＴ）に配置された前記データ符号化方式記述子でさらに指定する、
上記（１）に記載の送信装置。
（４）前記シグナリング情報（ＤＤＭＴ、ＤＣＣＴ）を、前記第１のエンコーダーでエンコードするデータ・カルーセルの特定のモジュールに含める、
上記（３）に記載の送信装置。
（５）前記シグナリング情報として、データ放送で伝送するファイルのディレクトリー構造を管理するデータ・ディレクトリー管理テーブル（ＤＤＭＴ）を含める、
上記（３）又は（４）のいずれかに記載の送信装置。
（６）前記シグナリング情報として、データ放送で伝送するコンテンツ（アプリケーション）毎のファイル構成、コンテンツ（アプリケーション）内のデータ放送提示単位（ＰＵ）毎のファイル構成、コンテンツ構成とキャッシュ制御を示すデータ・コンテント管理テーブル（ＤＣＣＴ）を含める、
上記（３）乃至（５）のいずれかに記載の送信装置。
（７）前記シグナリング情報を、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）表記形式並びにバイナリー表記形式で表記する、
上記（３）乃至（６）のいずれかに記載の送信装置。
（８）前記シグナリング情報に含まれる各テーブルにおいて、各ディレクトリー並びに各ファイルに対して共通のノード・タグを指定するとともに、データ・カルーセルの各モジュールの情報を示すコントロール・メッセージ（ＤＩＩ）のモジュール情報にノード・タグ記述子を配置して、モジュールと関連付ける、
上記（３）乃至（７）のいずれかに記載の送信装置。
（９）伝送路依存指定方式又はＵＲＩ指定方式のいずれかでファイル・ロケーションを指定して、データ放送アプリケーションのデータをデータ・カルーセル伝送方式によりエンコードする第１のエンコーディング・ステップと、
前記データ放送アプリケーションに関するアプリケーション情報テーブル（ＡＩＴ）の伝送配置情報を指定するデータ符号化方式記述子を配置したプログラム管理テーブル（ＰＭＴ）を含んだプログラム固有情報（ＰＳＩ）をエンコードする第２のエンコーディング・ステップと、
前記第１及び第２のエンコーディング・ステップでそれぞれエンコードされた放送データを含む複数の放送データを多重化して送信処理する送信処理ステップと、
を有する送信方法。
（１０）伝送路依存指定方式又はＵＲＩ指定方式のいずれかでファイル・ロケーションが指定されたデータ放送アプリケーションのデータ・カルーセルと、前記データ放送アプリケーションに関するアプリケーション情報テーブル（ＡＩＴ）の伝送配置情報を指定するデータ符号化方式記述子を配置したプログラム管理テーブル（ＰＭＴ）を含んだプログラム固有情報（ＰＳＩ）を含んだ放送信号を受信処理する受信処理部と、
データ放送アプリケーションの処理を制御するアプリケーション・データ制御部と、
を具備する受信装置。
（１１）前記アプリケーション・データ制御部は、前記プログラム管理テーブル（ＰＭＴ）に配置されたデータ符号化方式記述子に記載された前記アプリケーション情報テーブル（ＡＩＴ）の伝送配置情報に基づいて前記アプリケーション情報テーブル（ＡＩＴ）を取得し、前記アプリケーション情報テーブル（ＡＩＴ）に基づいて、前記データ・カルーセルのファイル・ロケーション指定方式が伝送路依存指定方式又はＵＲＩ指定方式のいずれかであるかを判定する、
上記（１０）に記載の受信装置。
（１２）前記データ・カルーセルのファイル・ロケーション指定方式としてＵＲＩ指定方式が選択されている場合に、
前記アプリケーション・データ制御部は、前記プログラム管理テーブル（ＰＭＴ）でエレメンタリー・ストリームのパケット識別子（ＰＩＤ）が指定されたデータ・カルーセルから、データ・カルーセルの各モジュールの情報を示すコントロール・メッセージ（ＤＩＩ）と、ＵＲＩ指定方式を選択した場合に適用されるシグナリング情報（ＤＤＭＴ、ＤＣＣＴ）に基づいて、前記データ・カルーセルに含まれるモジュールのロケーションを解決する、
上記（１０）又は（１１）のいずれかに記載の受信装置。
（１３）前記アプリケーション・データ制御部は、前記プログラム管理テーブル（ＰＭＴ）に配置された前記データ符号化方式記述子に記述されたシグナリング情報（ＤＤＭＴ、ＤＣＣＴ）の伝送配置情報に基づいて、シグナリング情報（ＤＤＭＴ、ＤＣＣＴ）を取得する、
上記（１２）に記載の受信装置。
（１４）前記アプリケーション・データ制御部は、前記アプリケーション情報テーブル（ＡＩＴ）で所望のアプリケーションのロケーションを指定するＵＲＩと一致するノード・タグを、前記シグナリング情報（データ放送で伝送するファイルのディレクトリー構造を管理するデータ・ディレクトリー管理テーブル：ＤＤＭＴ）で検索し、そのノード・タグに関連付けられたモジュールのモジュール識別子を前記コントロール・メッセージ（ＤＩＩ）から取得して、得られたモジュール識別子とダウンロード識別子の組み合わせに基づいて、データ・カルーセルの中から該当するモジュール（ＤＤＢメッセージ）を指定する、
上記（１２）に記載の受信装置。
（１５）前記アプリケーション・データ制御部は、前記シグナリング情報（データ放送で伝送するコンテンツ（アプリケーション）毎のファイル構成、コンテンツ（アプリケーション）内のデータ放送提示単位（ＰＵ）毎のファイル構成、コンテンツ構成とキャッシュ制御を示すデータ・コンテント管理テーブル：ＤＣＣＴ）を用いて、データ・カルーセル伝送されるファイル・データのキャッシュを制御する、
上記（１２）に記載の受信装置。
（１６）前記アプリケーション・データ制御部は、前記シグナリング情報（ＤＣＣＴ）においてロック対象と指定されたモジュールを前記受信処理部が受信すると、キャッシュ・メモリーに強制キャッシュする、
上記（１５）に記載の受信装置。
（１７）前記アプリケーション・データ制御部は、前記シグナリング情報（ＤＣＣＴ）においてアンロック対象と指定されたモジュールの強制キャッシュ指定を解除して前記キャッシュ・メモリーから削除する、
上記（１６）に記載の受信装置。
（１８）前記アプリケーション・データ制御部は、前記シグナリング情報（ＤＣＣＴ）においてリンク先提示単位と指定されたモジュールをキャッシュ・メモリーに事前キャッシュする、
上記（１５）に記載の受信装置。
（１９）伝送路依存指定方式又はＵＲＩ指定方式のいずれかでファイル・ロケーションが指定されたデータ放送アプリケーションのデータ・カルーセルと、前記データ放送アプリケーションに関するアプリケーション情報テーブル（ＡＩＴ）の伝送配置情報を指定するデータ符号化方式記述子を配置したプログラム管理テーブル（ＰＭＴ）を含んだプログラム固有情報（ＰＳＩ）を含んだ放送信号を受信処理する受信処理ステップと、
データ放送アプリケーションの処理を制御するアプリケーション・データ制御ステップと、
を有する受信方法。

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

Claims (3)

1. 放送番組の符号化ビデオ信号及び符号化オーディオ信号を含む放送ストリームと、アプリケーションと、前記アプリケーションを伝送するプロトコルと前記アプリケーションを取得するためのロケーションとを指定した伝送プロトコル記述子を配置したアプリケーション情報テーブルと、伝送データのディレクトリー構造を管理し前記伝送データとディレクトリー又はファイルを対応付けるためのノード・タグが配置されるデータディレクトリー管理テーブル（ＤＤＭＴ）を含む前記アプリケーションの伝送に関するシグナリング情報と、前記アプリケーション情報テーブルの伝送情報と前記シグナリング情報の伝送情報とを指定した記述子を配置したテーブルを受信する１又は複数の受信部と、
   前記放送番組の符号化ビデオ信号をデコードするビデオデコーダーと、
   前記放送番組の符号化オーディオ信号をデコードするオーディオデコーダーと、
   デコードされた前記放送番組のビデオ信号と前記アプリケーションの表示信号に基づくビデオ信号を映像表示し、デコードされた前記放送番組のオーディオ信号を音声出力するディスプレイと、
   を具備する受信装置。
2. 前記受信部は、放送信号を受信するチューナーと、インターネットを通じて信号を受信するＩＰインターフェースを含む、
   請求項１に記載の受信装置。
3. １又は複数の受信部が、放送番組の符号化ビデオ信号及び符号化オーディオ信号を含む放送ストリームと、アプリケーションと、前記アプリケーションを伝送するプロトコルと前記アプリケーションを取得するためのロケーションとを指定した伝送プロトコル記述子を配置したアプリケーション情報テーブルと、伝送データのディレクトリー構造を管理し前記伝送データとディレクトリー又はファイルを対応付けるためのノード・タグが配置されるデータディレクトリー管理テーブル（ＤＤＭＴ）を含む前記アプリケーションの伝送に関するシグナリング情報と、前記アプリケーション情報テーブルの伝送情報と前記シグナリング情報の伝送情報とを指定した記述子を配置したテーブルを受信し、
   ビデオデコーダーが、前記放送番組の符号化ビデオ信号をデコードし、
   オーディオデコーダーが、前記放送番組の符号化オーディオ信号をデコードし、
   ディスプレイが、デコードされた前記放送番組のビデオ信号と前記アプリケーションの表示信号に基づくビデオ信号を映像表示し、デコードされた前記放送番組のオーディオ信号を音声出力する、
   ように受信装置を制御する、受信装置の制御方法。

Images