JP2018067926A - 送信装置及び送信方法 - Google Patents

Abstract

【課題】デリバリー・セグメント毎のデータ放送アプリケーションの制御情報を配信する。【解決手段】放送局側では、ＰＡメッセージに格納されるＭＰテーブルに、デリバリー・セグメント毎のアプリケーション・サービス記述子を配置する。各アプリケーション・サービス記述子は１つのアプリケーション・タイプの情報とそのアプリケーション・タイプの優先度を示す。受信機は、アプリケーション・サービス記述子で示されるアプリケーション・タイプ毎の優先度とデフォルトＡＩＴフラグにより、さらに特定のＭＨ−ＡＩＴ及びデータ伝送メッセージを選択する。【選択図】 図９

Description

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

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

ＭＭＴ方式のＴＶ放送規格では、ビデオやオーディオ、字幕などの放送番組本体のストリーム・メディアを同期（Ｔｉｍｅｄ）ＭＰＵ（Ｍｅｄｉａ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）フォーマットで伝送する一方、ＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）文書のようなデータ放送アプリケーション並びにアプリケーションに関わる制御情報を非同期（Ｎｏｎ ｔｉｍｅｄ）ＭＰＵフォーマットで伝送する方式も規定されている

また、データ放送アプリケーションには、放送番組に連動した番組連動型データ放送アプリケーションと、ニュースや天気予報のように放送番組とは特に連動しない番組非連動型データ放送アプリケーションに大別することができる。また、データ放送アプリケーションのデリバリー・セグメントが複数存在することが想定される。例えば、放送番組本体の制作元であるキー局が主に放送番組に連動したアプリケーションを付与する一方、配信事業者である各地方局でも自前のアプリケーションを付与するという運用が想定される。各地方局は、必ずしも放送番組本体には連動しないが、天気予報やローカル・ニュースといったその地域に密着した情報を自前のアプリケーションで提供し、地域毎に粒度の細かいデータ放送サービスを実現できるというメリットがある。

本出願時のＢＭＬ（Ｂｒｏａｄｃａｓｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）を利用したデータ放送やハイブリッドキャストの放送局運用では、特に民間放送において、責任分界と地方局の配信設備の負担を増大させないという観点から、データ放送アプリケーション並びにアプリケーションに関連する制御情報の伝送を、デリバリー・セグメント（キー局分と地方局分）毎に独立して実施できるように考慮されている。

次世代のＭＭＴ方式の放送規格を検討する際にも、各地方局でも自前のアプリケーションを付与するという民間放送の要求を十分考慮すべきである。ところが、複数のデリバリー・セグメントからそれぞれ提供されるデータ放送アプリケーションをすべて一系統に統合して運用してしまうと、キー局で用意したデータ放送のデータ・フローに対して、各地方局において自前のアプリケーションの付け足しや付け替え作業を行なわなければならない。この結果、地方局に過大な配信コストを強いるとともに、作業がうまくいかないリスクもある。

特開２０１４−２０００５４号公報

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

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

本明細書で開示する技術は、上記課題を参酌してなされたものであり、その第１の側面は、
放送番組に対するアプリケーションを送信するアプリケーション送信部と、
前記アプリケーションに関わるシグナリング・メッセージを送信するシグナリング・メッセージ送信部と、
を具備し、
前記シグナリング・メッセージ送信部は、所定のシグナリング・メッセージで伝送するシグナリング・テーブル内に、アプリケーションを提供するデリバリー・セグメント毎のアプリケーション・サービス記述子を配置して送信する、
送信装置である。

本明細書で開示する技術の第２の側面によれば、第１の側面に係る送信装置の前記シグナリング・メッセージ送信部は、各アプリケーション・サービス記述子で、対応するデリバリー・セグメントが提供するアプリケーションの運用に必要又は重要な制御データを格納するシグナリング・メッセージ又はシグナリング・テーブルのロケーション情報を示すように構成されている。

本明細書で開示する技術の第３の側面によれば、第１の側面に係る送信装置の前記シグナリング・メッセージ送信部は、各アプリケーション・サービス記述子に、対応するデリバリー・セグメントが伝送するデータ伝送メッセージ、アプリケーション情報テーブル、又はイベント・メッセージ・テーブルのロケーション情報を示すように構成されている。

本明細書で開示する技術の第４の側面によれば、第１の側面に係る送信装置の前記シグナリング・メッセージ送信部は、放送サービスのエントリー・ポイントとなるシグナリング・メッセージで伝送するシグナリング・テーブル内に、デリバリー・セグメント毎のアプリケーション・サービス記述子を配置して送信するように構成されている。

本明細書で開示する技術の第５の側面によれば、第１の側面に係る送信装置の前記シグナリング・メッセージ送信部は、各アプリケーション・サービス記述子でデリバリー・セグメントが提供するアプリケーション・タイプの情報を示すように構成されている。

本明細書で開示する技術の第６の側面によれば、第５の側面に係る送信装置の前記シグナリング・メッセージ送信部は、各アプリケーション・サービス記述子でアプリケーション・タイプ毎の優先度の情報をさらに示すように構成されている。

本明細書で開示する技術の第７の側面によれば、第６の側面に係る送信装置の前記シグナリング・メッセージ送信部は、アプリケーション・タイプ毎の優先度の情報を示すパラメーター（ａｐｐｌｉｃａｔｉｏｎ＿ｐｒｉｏｒｉｔｙ）を各アプリケーション・サービス記述子に含めるように構成されている。

本明細書で開示する技術の第８の側面によれば、第６の側面に係る送信装置の前記シグナリング・メッセージ送信部は、各アプリケーション・サービス記述子に配置されるプライベート・データ領域で、アプリケーション・タイプ毎の優先度の情報を示すように構成されている。

本明細書で開示する技術の第９の側面によれば、第６の側面に係る送信装置の前記シグナリング・メッセージ送信部は、所定ビット長のビットマップ情報領域（ａｐｐｌｉｃａｔｉｏｎ＿ｂｉｔｍａｐ）でアプリケーション・タイプ及びその優先度を示すように構成されている。

本明細書で開示する技術の第１０の側面によれば、第９の側面に係る送信装置の前記シグナリング・メッセージ送信部は、所定ビット長のビットマップ情報領域（ａｐｐｌｉｃａｔｉｏｎ＿ｂｉｔｍａｐ）でアプリケーション・タイプ及びその優先度を示すように構成されている。

本明細書で開示する技術の第１１の側面によれば、第１の側面に係る送信装置の前記シグナリング・メッセージ送信部は、各アプリケーション・サービス記述子で、対応するデリバリー・セグメントについてのアプリケーション情報テーブルがデフォルトの監視対象に指定されているか否かを示すように構成されている。

本明細書で開示する技術の第１２の側面によれば、第１の側面に係る送信装置の前記シグナリング・メッセージ送信部は、各アプリケーション・サービス記述子で、対応するデリバリー・セグメントから伝送されるイベント・メッセージ・テーブルの数の情報を示すように構成されている。

本明細書で開示する技術の第１３の側面によれば、第１の側面に係る送信装置の前記アプリケーション送信部は、ペイロードにアプリケーションを含むことを示す第１のペイロード種別情報をパケット・ヘッダーに挿入した第１の伝送パケットでアプリケーションを送信し、前記シグナリング・メッセージ送信部は、ペイロードにシグナリング・メッセージを含むことを示す第２のペイロード識別情報をパケット・ヘッダーに挿入した第２の伝送パケットでシグナリング・メッセージを送信するように構成されている。

また、本明細書で開示する技術の第１４の側面は、
放送番組に対するアプリケーションを送信するアプリケーション送信ステップと、
前記アプリケーションに関わるシグナリング・メッセージを送信するシグナリング・メッセージ送信ステップと、
を有し
前記シグナリング・メッセージ送信ステップでは、所定のシグナリング・メッセージで伝送するシグナリング・テーブル内に、アプリケーションを提供するデリバリー・セグメント毎のアプリケーション・サービス記述子を配置して送信する、
送信方法である。

また、本明細書で開示する技術の第１５の側面は、
放送番組に対するアプリケーションを受信するアプリケーション受信部と、
前記アプリケーションに関わるシグナリング・メッセージを受信するシグナリング・メッセージ受信部と、
を具備し、
前記シグナリング・メッセージ受信部は、伝送するシグナリング・テーブル内に、アプリケーションを提供するデリバリー・セグメント毎のアプリケーション・サービス記述子を配置したシグナリング・テーブルが格納された所定のシグナリング・メッセージを受信する、
受信装置である。

本明細書で開示する技術の第１６の側面によれば、第１５の側面に係る受信装置は、前記アプリケーション受信部が受信したアプリケーションの起動を制御するアプリケーション制御部をさらに備えている。そして、前記アプリケーション制御部は、前記シグナリング・テーブルに配置される各アプリケーション・サービス記述子でアプリケーション・タイプ毎の優先度に基づいて、前記シグナリング・メッセージで受信するシグナリング・メッセージ又はシグナリング・テーブルを選択するように構成されている。

また、本明細書で開示する技術の第１７の側面は、
放送番組に対するアプリケーションを受信するアプリケーション受信ステップと、
前記アプリケーションに関わるシグナリング・メッセージを受信するシグナリング・メッセージ受信ステップと、
を有し、
前記シグナリング・メッセージ受信ステップでは、伝送するシグナリング・テーブル内に、アプリケーションを提供するデリバリー・セグメント毎のアプリケーション・サービス記述子を配置したシグナリング・テーブルが格納された所定のシグナリング・メッセージを受信する、
受信方法である。

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

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

本明細書で開示する技術によれば、同一の放送番組に関するデータ放送アプリケーションを提供するデリバリー・セグメントが複数存在する場合に（例えば、番組制作局としてのキー局、配信局としての各地方局、並びに第３者など）、データ放送アプリケーションに関連する制御情報をデリバリー・セグメント毎に独立した系統で配信することができる。したがって、キー局と地方局間の責任分界と、地方局の配信設備の負担を増大させずに済む。

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

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

図１は、本明細書で開示する技術を適用したディジタル放送システム１０の構成例を模式的に示した図である。 図２は、ＭＭＴ方式を用いる放送システムのプロトコル・スタック２００を示した図である。 図３は、図２に示した放送信号を送出する放送送出システム１１の構成例を示した図である。 図４は、図２に示した放送信号を受信する受信機１２の構成例を示した図である。 図５は、ＭＭＴ／ＴＬＶ方式に従って放送送出システム１１から放送伝送路に送出される放送信号５００のイメージを示した図である。 図６は、ＰＡメッセージ内のＭＰテーブルからパッケージの各アセットを指定する仕組みを示した図である。 図７は、ＭＭＴ伝送されるデータ放送アプリケーションを構成するファイルを取得する仕組みを説明するための図である。 図８は、複数のデリバリー・セグメントが提供するデータ放送アプリケーション間のリンク関係の一例を示した図である。 図９は、デリバリー・セグメント毎の放送信号をそれぞれ独立した系統で配信する放送信号の構成例を示した図である。 図１０は、同一の放送番組に対するデリバリー・セグメント毎のデータ放送アプリケーション及びアプリケーションに関連する制御情報をそれぞれ独立した系統で伝送する仕組みを模式的に示した図である。 図１１は、ＰＡメッセージ１１０１とＰＡメッセージに含まれるＭＰテーブル１１０２の構成例を示した図である。 図１２は、ＰＡメッセージのシンタックス例１２００を示した図である。 図１３は、ＰＡメッセージに格納されるＭＰテーブルのシンタックス例１３００を示した図である。 図１４は、ＭＰテーブル内にアプリケーション・サービス記述子のシンタックス例１４００を示した図である。 図１５は、ＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏ（一般ロケーション情報）のシンタックス例１５００を示した図である。 図１６は、Ｍ２セクション・メッセージで伝送されるＭＨ ＡＩＴのシンタックス例１６００を示した図である。 図１７は、アプリケーション・サービス記述子の他のシンタックス例１７００を示した図である。 図１８は、プライベート・データ領域のシンタックス例１８００を示した図である。 図１９は、プライベート・データ領域の利用例を示した図である。 図２０は、アプリケーション・サービス記述子のさらに他のシンタックス例２０００を示した図である。 図２１は、ａｐｐｌｉｃａｔｉｏｎ＿ｂｉｔｍａｐでアプリケーション・タイプの優先度を示す方法を説明するための図である。 図２２は、ａｐｐｌｉｃａｔｉｏｎ＿ｂｉｔｍａｐでアプリケーション・タイプの優先度を示す方法を説明するための図である。 図２３は、受信機においてデータ放送アプリケーションを起動するための処理手順を示したフローチャートである。 図２４は、アプリケーション・サービス記述子がアプリケーション・タイプ及び優先度を指定した例を示している。

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

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

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

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

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

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

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

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

図３には、図２に示した放送信号を送出する放送送出システム１１の構成例を示している。放送送出システム１１は、例えば放送番組本体の制作元であるキー局（番組制作局）に相当する。図示の放送送出システム１１は、時計部３０１と、信号送出部３０２と、ビデオ・エンコーダー３０３と、オーディオ・エンコーダー３０４と、キャプション・エンコーダー３０５と、シグナリング・エンコーダー３０６と、ファイル・エンコーダー３０７と、電子データ処理システム（Ｅｌｅｃｔｒｏｎｉｃ Ｄａｔａ Ｐｒｏｃｅｓｓｉｎｇ Ｓｙｓｔｅｍ：ＥＤＰＳ）３０８と、ＴＬＶシグナリング・エンコーダー３０９と、ＩＰサービス・マルチプレクサー（ＭＵＸ）３１０と、ＴＬＶマルチプレクサー（ＭＵＸ）３１１と、変調・送信部３１２を備えている。

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

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

ＥＤＰＳ３０８は、ＴＶ放送局のスケジューラー並びにファイルの供給源であり、非同期メディアであるデータ放送アプリケーションと、放送番組の構成などを示す制御情報と、ＩＰパケットの多重に関する制御情報をそれぞれ、ファイル・エンコーダー３０７、シグナリング・エンコーダー３０６、ＴＬＶシグナリング・エンコーダー３０９に送る。

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

シグナリング・エンコーダー３０６は、ＥＤＰＳ３０８から送出される情報に基づいて、放送番組の構成などを示す制御情報を記述したシグナリング・メッセージ（ＭＭＴ−ＳＩ）を生成し、ペイロード部にこのシグナリング・メッセージが配置されたＭＭＴパケットを含むＩＰパケットをＩＰサービス・マルチプレクサー３１０に送る。本実施形態では、シグナリング・メッセージは、ＰＡ（Ｐａｃｋａｇｅ Ａｃｃｅｓｓ）メッセージ、Ｍ２セクション・メッセージ、データ伝送メッセージの３種類に大別される。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図４には、図２に示した放送信号を受信する受信機１２の構成例を示している。図示の受信機１２は、チューナー・復調部４０１と、デマルチプレクサー（ＤＥＭＵＸ）４０２と、時計回復部４０３と、ビデオ・デコーダー４０４と、オーディオ・デコーダー４０５と、キャプション・デコーダー４０６と、システム制御部４０７と、アプリケーション制御部４０８と、アプリケーション・エンジン４０９と、ＩＰインターフェース（Ｉ／Ｆ）４１０と、合成部４１１を備えている。図示の受信機１２は、例えば家庭内に設置されるテレビ受信機やセット・トップ・ボックスの他、ＩＰＴＶやＣＡＴＶの再送信機を含むものとする。

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

ＴＬＶフィルター４０２−１は、ＴＬＶストリーム識別情報に基づいて、放送伝送されるＴＬＶパケットをフィルタリングする。ＩＰフィルター４０２−２は、ＩＰアドレスに基づいて、ＴＬＶパケットからＩＰパケットをフィルタリングするとともに、ＩＰインターフェース４１０経由で受信したＩＰパケットのフィルタリングも行なう。また、ＵＤＰフィルター４０２−３は、ＵＤＰパケットをフィルタリングする。ＭＭＴフィルター４０２−４は、ＭＭＴＰヘッダー（後述）内の情報に基づいて、ＩＰパケットからＭＭＴＰパケットをフィルタリングして、映像、音声、字幕、並びにアプリケーションの各符号化コンポーネントを乗せたＭＭＴＰパケットを、それぞれビデオ・デコーダー４０４、オーディオ・デコーダー４０５、キャプション・デコーダー４０６、アプリケーション・エンジン４０９に振り分ける。ＳＩフィルター４０２−５は、シグナリング情報ＳＩをフィルタリングして、システム制御部４０７及びアプリケーション制御部４０８にそれぞれ振り分ける。ＳＩフィルター４０２−５は、ＭＭＴストリームからＭＭＴ−ＳＩをフィルタリングするＭＭＴ−ＳＩフィルターと、ＴＬＶストリームからＴＬＶ−ＳＩをフィルタリングするＴＬＶ−ＳＩフィルターを含むものとする。

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

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

アプリケーション制御部４０８は、ＳＩフィルター４０２−５を介して受け取るシグナリング情報に基づいて、データ放送アプリケーションの処理を制御する。例えば、アプリケーション制御部４０７は、ＭＭＴ−ＳＩを解析して、デフォルト・エントリーに設定されているデータ放送アプリケーションを見つけると、アプリケーション・エンジン４０９に対してデータ放送の提示処理を指示する。

本実施形態に係る放送システム１０では、放送信号並びにＩＰネットワークという２種類のデリバリー・パスを通じてデータ放送アプリケーションが伝送されることを想定している。前者の系統ではチューナー・復調部４０１で受信し、後者の系統ではＩＰインターフェース４１０で受信し、いずれもデマルチプレクサー４０２内でパケット化されたＭＭＴパケットがＭＭＴフィルター４０２−４によってアプリケーション・エンジン４０９に振り分けられる。

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

システム制御部４０７は、ＳＩフィルター４０２−５を介して受け取るシグナリング情報や、ユーザー操作部（図示しない）を介したユーザーからの操作情報などに基づいて、当該受信機１２の各部の動作を制御する。また、システム制御部４０７は、各デコーダー４０４〜４０６におけるデコード・タイミングをシグナリング情報に基づいて制御し、映像、音声、及び字幕の提示タイミングを調整する。合成部４１１は、ベースバンドの映像信号に、字幕の表示信号及びデータ放送の表示信号を合成して、映像表示用の映像信号を得る。また、オーディオ・デコーダー４０５で得られるベースバンドの音声信号は、音声出力用の音声信号となる。映像信号及び音声信号からなる放送番組本編は、図示しないモニター・ディスプレイから映像及び音声出力される。また、データ放送アプリケーション・エンジン４０９が処理したデータ放送も、モニター・ディスプレイ上で放送番組本編の画面に重畳して表示される。

ＩＰインターフェース４１０は、例えばネットワーク・インターフェース・カードで構成され、インターネットやホーム・ネットワークなどのＩＰネットワークに接続して、ＩＰパケットの送受信処理を行なう。

また、本実施形態では、ＩＰフィルター４０２−２でＩＰアドレスに基づいてフィルタリングしたＩＰパケットを、ＩＰインターフェース４１０からＩＰネットワークへ送信若しくは再送信することも想定される。また、放送サービスをＩＰアドレスだけでフィルタリングできることが判明すると、デマルチプレクサー４０２内のＩＰフィルター４０２−２だけで特定サービスを抽出して、受信機１２から外部へ転送することができる。

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

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

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

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

アプリケーション制御部４０８では、ＳＩフィルター４０２−５を介して受け取るシグナリング情報に基づいて、データ放送アプリケーションの処理が制御される。ＨＴＭＬブラウザーなどからなるアプリケーション・エンジン４０９では、アプリケーション制御部４０８からの指示に従って、デマルチプレクサー４０２で抽出されたデータ放送アプリケーションの符号化信号（ＨＴＭＬ５文書）の処理が行なわれ、データ放送の表示信号が得られる。

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

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

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

ＭＭＴ方式では、１つのチャンネル（放送番組）を構成する同期メディア及び非同期メディアのデータを異なる伝送路の組み合わせで利用することが容易である。図５に示す例では、放送信号５００として、映像、音声、字幕、データ放送アプリケーションなど、タイプ毎のアセット５０１〜５０３が利用されている。なお、図中、字幕データ用のアセットは便宜上、図示を省略している。各アセットは、それぞれ１つのＩＰデータ・フローに相当する。ここで言うＩＰデータ・フローとは、ＩＰヘッダー及びＵＤＰヘッダーの送信元ＩＰアドレス、宛先ＩＰアドレス、ＩＰヘッダーのプロトコル種別、送信元ポート番号、宛先ポート番号の５種類のフィールドの値がすべて同じとなるＩＰパケットの集合である。

ＭＭＴ方式の放送システム１１は、放送伝送路でＩＰパケットを伝送する方式であるが、放送サービス毎（若しくは、放送局毎）に１つのＩＰアドレスをマッピングするという運用が可能である。このような場合、受信機側では、ＩＰアドレスに基づいて放送信号５００をフィルタリングすることで、所望する放送サービス（若しくは、所望する放送局）の各アセット５０１〜５０３にアクセスすることができる。同じＩＰアドレス内の各アセット５０１〜５０３で伝送されるＭＭＴＰ（ＭＭＴプロトコル）パケットは、パケット識別情報（ｐａｃｋｅｔ＿ｉｄ：ＰＩＤ）で一意に指定することができる。また、異なるＩＰアドレス上のＭＭＴＰパケットは、パケット識別情報と、ＩＰアドレスと、ポート番号の組み合わせにより指定することができる。

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

各アセットは、同じアセット識別情報を共有する１又はそれ以上のＭＰＵの集合（論理グループ）で構成される。ＭＰＵは、ＭＭＴ方式における伝送単位となるフォーマットということができる。各ＭＰＵは、それぞれのアセットに専用のＥＳ（Ｅｌｅｍｅｎｔａｒｙ Ｓｔｒｅａｍ）すなわちアセット５０１〜５０３上で伝送される。すなわち、映像アセット５０１では、同じアセット識別情報を持つ映像信号のＭＰＵ論理グループからなる符号化映像信号のＭＭＴＰパケットが伝送される。同様に、音声アセット５０２では同じアセット識別情報を持つ音声信号のＭＰＵ論理グループからなる符号化音声信号のＭＭＴパケットが伝送され、データ・アセット５０３では同じアセット識別情報を持つデータ放送アプリケーションのＭＰＵ論理グループからなる符号化アプリケーションのＭＭＴパケットが伝送される。各ＭＰＵは、アセット識別情報と、該当するアセット上でのＭＰＵのシーケンス番号で特定される。また、各メディアを伝送するアセットは、アセット識別情報で識別することができる。

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

また、ＭＭＴ方式は、放送や通信の複数の伝送路に共通に用いることができる。例えば、データ放送用アプリケーション（ＨＴＭＬ５文書など）のような非同期メディアは、図５に示したようにデータ・アセット５０３として同期メディアとともに伝送される以外に、ＩＰネットワークなど通信伝送路（図示しない）を介して提供することもできる。

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

シグナリング５０４で伝送されるＭＭＴ−ＳＩのシグナリング・メッセージとして、ＰＡメッセージ５１０、Ｍ２セクション・メッセージ５２０、データ伝送メッセージ５３０を挙げることができる。

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

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

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

ＭＨ−ＡＩＴ５２１は、アプリケーションに関する動的制御情報及び実行に必要な付加情報を伝送するテーブルであり、具体的には、放送伝送路でデータ・アセットとして送られてくるデータ放送アプリケーション（ファイル・データ）の処理方法（アプリケーションに適用される起動状態など）、並びにロケーション（ＵＲＬ）を指定する。

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

また、データ伝送メッセージ５３０は、データ放送アプリケーションの伝送に関する制御情報を伝送するためのメッセージである。１つのデータ伝送メッセージ５３０内には、データ・ディレクトリー管理テーブル（Ｄａｔａ Ｄｉｒｅｃｔｏｒｙ ｍａｎａｇｅｍｅｎｔ Ｔａｂｌｅ：ＤＤＭＴ）５３１、データ・アセット管理テーブル（Ｄａｔａ Ａｓｓｅｔ Ｍａｎａｇｅｍｅｎｔ Ｔａｂｌｅ： ＤＡＭＴ）５３２、データ・コンテンツ管理テーブル（Ｄａｔａ Ｃｏｎｔｅｎｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｔａｂｌｅ：ＤＣＣＴ）５３３の各シグナリング・テーブルが格納される。

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

データ・アセット管理テーブル５３２は、アセット単位でデータ放送アプリケーションを管理するためのテーブルであり、アセット内のＭＰＵの構成とのＭＰＵ毎のバージョン情報を記述している。

データ・コンテンツ管理テーブル５３３は、提示単位（Ｐｒｅｓｅｎｔａｔｉｏｎ Ｕｎｉｔ：ＰＵ）毎にデータ放送アプリケーションを管理するためのテーブルである。同テーブルは、データ放送アプリケーションのファイルの構成情報をデータ放送の提示単位（ＰＵ）で記述しており、受信機側ではデータ放送アプリケーション用のファイル・データの柔軟で有効なキャッシュ制御に利用することができる。

ＭＭＴによるデータ放送アプリケーションの伝送方式において、データ伝送メッセージで伝送する上記３種類のシグナリング・テーブル５３１〜５３３を活用することにより、ファイル単位の伝送データ構造やコンテンツ（データ放送アプリケーション）制作におけるディレクトリー構造とは独立して、受信機におけるキャッシュ・メモリーの有効活用のために、アプリケーション単位、提示単位といった利用単位のデータ構造を表現することができる（例えば、本出願人に既に譲渡されている特願２０１４−８８６３０号明細書を参照のこと）。

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

図７には、同一のＩＰデータ・フローに多重されたデータ放送アプリケーションのアイテムを取得する仕組みを図解している。

データ放送アプリケーションを構成するアイテム（データ・ファイル）は、ＨＴＭＬ５などのアプリケーション記述内でパス名を指定される。ここで言うパス名は、ディレクトリー・ノード名とファイル名の組み合わせで記述される。また、ディレクトリー・ノードとファイルを統合した記述子としてノード・タグを規定し、各シグナリング・テーブルをリンクする情報として使用する。

データ放送アプリケーションからパス名を指定すると、参照番号７０１で示すように、データ伝送メッセージ内のデータ・ディレクトリー管理テーブルから、指定されたパス名のファイルのノード・タグを得ることができる。

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

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

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

なお、データ伝送メッセージで伝送される、データ・ディレクトリー管理テーブル、データ・アセット管理テーブル、データ・コンテンツ管理テーブルの各シグナリング・テーブルの詳細な構成については、例えば本出願人に既に譲渡されている特願２０１４−２５０２７９号明細書を参照されたい。

ディジタル放送サービスでは、同一の放送番組に対してデータ放送アプリケーションを提供するデリバリー・セグメントが複数存在することが想定される。例えば、放送番組本体の制作元であるキー局が主に放送番組に連動したアプリケーションを付与する一方、配信事業者である各地方局でも自前のアプリケーションを付与するという運用が想定される。各地方局は、必ずしも放送番組本体には連動しないが、天気予報やローカル・ニュースといったその地域に密着した情報を自前のアプリケーションで提供し、地域毎に粒度の細かいデータ放送サービスを実現できるというメリットがある。図５に示した例では、デリバリー・セグメント毎に、番組制作局が提供するデータ放送アプリケーション用のアセット５０３−１と、番組を配信する地方局が提供するデータ放送アプリケーション用のアセット５０３−２を描いている。さらに、番組制作局でも配信局でもない第３者が、インターネットなどの広域ネットワーク経由でデータ放送アプリケーションを提供することも想定される。

図８には、同一の放送番組に対して、番組制作局、配信局、第３者の各デリバリー・セグメントがそれぞれ提供するデータ放送アプリケーション間のリンク関係の一例を示している。

図８中、Ａｐｐ１、Ａｐｐ２、Ａｐｐ４は、番組制作局であるキー局から提供されるデータ放送アプリケーションである。番組制作局は、Ａｐｐ１、Ａｐｐ２、Ａｐｐ４などの自局で制作したアプリケーションを、例えばビデオやオーディオ、字幕など放送番組本体を構成するアセットとともに、同じＩＰデータ・フロー（デリバリー・パス）で放送信号として伝送する。番組制作局が提供するデータ放送アプリケーションは、例えば、放送番組に関連し若しくは連動するアプリケーションである。

また、Ａｐｐ３、Ａｐｐ５は、配信局である地方局が提供するデータ放送アプリケーションである。Ａｐｐ３やＡｐｐ５は、例えば天気予報やローカル・ニュースといったその地域に密着した情報を提供する、放送番組に非連動のデータ放送アプリケーションである。配信局は、Ａｐｐ３、Ａｐｐ５などの自前のデータ放送アプリケーションを、番組制作局とは異なるＩＰデータ・フロー（すなわち、独立したデリバリー・パス）で放送信号として伝送する。

また、Ａｐｐ６は、番組制作局でも配信局でもない第３者が提供する、放送番組に連動又は非連動のデータ放送アプリケーションである。第３者は、Ａｐｐ６などの自前のアプリケーションを、インターネットなどの広域ネットワーク経由（すなわち、独立したデリバリー・パス）で配信する。なお、番組制作局や配信局も、それぞれが制作したデータ放送アプリケーションを、放送信号ではなく広域ネットワーク経由で配信することもある。

図８に示す例では、番組制作局から提供されるデータ放送アプリケーションＡｐｐ１が、当該放送番組のデフォルト・エントリーに設定されるとともに、番組制作局から提供される他のデータ放送アプリケーションＡｐｐ２、並びに、配信局から提供されるデータ放送アプリケーションＡｐｐ３にリンクしている。図示のようなアプリケーション間のリンク関係が形成されている場合に期待されるページ遷移動作について、以下に説明しておく。

当該放送番組を受信した受信機は、データ放送を起動時にはまずエントリーに指定されたデータ放送アプリケーションＡｐｐ１を実行し、その後、ユーザーの操作やイベント・メッセージに応じて、リンク関係が形成されている他のデータ放送アプリケーションＡｐｐ２又はＡｐｐ３に遷移する。

番組制作局から提供されるデータ放送アプリケーションＡｐｐ２は、さらに、番組制作局から提供される他のデータ放送アプリケーションＡｐｐ４、並びに、配信局から提供されるデータ放送アプリケーションＡｐｐ５にリンクしている。したがって、受信機は、データ放送アプリケーションＡｐｐ２を実行してページを遷移した後、ユーザーの操作やイベント・メッセージに応じて、データ放送アプリケーションＡｐｐ４又はＡｐｐ５に遷移する。

また、配信局から提供されるデータ放送アプリケーションＡｐｐ３は、さらに、第３者から提供されるデータ放送アプリケーションＡｐｐ６にリンクしている。したがって、受信機は、データ放送アプリケーションＡｐｐ３を実行してページを遷移した後、ユーザーの操作やイベント・メッセージに応じて、データ放送アプリケーションＡｐｐ６に遷移する。

現状のＢＭＬを利用したデータ放送やハイブリッドキャストの放送局運用では、特に民間放送において責任分界と地方局の配信設備の負担を増大させないという観点から、データ放送アプリケーション並びにアプリケーションに関連する制御情報の伝送を、デリバリー・セグメント（キー局分と地方局分）毎に独立して実施できるように考慮されている。

ＭＭＴによるメディア・トランスポート方式を適用する次世代の放送規格でも、各地方局や第３者など番組制作局以外でも自前のデータ放送アプリケーションを提供する（すなわち、１つの放送番組に対して、複数のデリバリー・セグメントがそれぞれ自前のデータ放送アプリケーションを提供する）、という民間放送の要求を十分考慮すべきである。

ところが、複数のデリバリー・セグメントからそれぞれ提供されるデータ放送アプリケーションをすべて一系統に統合して運用してしまうと、例えばキー局から配信される放送番組に対して地方局でデータ放送アプリケーションを付与する必要がある。このような場合、地方局は、キー局が放送番組並びにそれに付随するアプリケーション並びにアプリケーションの制御情報を伝送するＩＰデータ・フローに対して、自前のアプリケーションの付け足しや付け替え作業を行なわなければならない。その結果、地方局は、配信設備や配信コストの負担が増大するとともに、アプリケーションの付け足しや付け替え作業を行なう際のリスクが発生し、キー局と地方局間の責任分界が不明になる。

本明細書では、ＭＭＴによるメディア・トランスポート方式を適用する次世代の放送規格において、番組制作局としてのキー局、配信局としての各地方局、並びに第３者といった、複数のデリバリー・セグメントがそれぞれ独立したデータ放送アプリケーションの運用を実現するための技術について提案する。以下では、提案する内容について、さらに詳細に説明する。

シグナリング・メッセージの１つであるＰＡメッセージが放送番組のエントリー・ポイント（固定のパケット識別子（例えば、０ｘ００００）が割り当てられる）となり、ＰＡメッセージ内には、アセットのリストやその位置などパッケージを構成する情報を記述するＭＰテーブルが含まれていることは、既に述べた通りである。

また、ＭＨ−ＡＩＴテーブル、データ・ディレクトリー管理テーブルと、データ・アセット管理テーブル、データ・コンテンツ管理テーブルは、データ放送アプリケーションの伝送制御に関連する重要なシグナリング・テーブルである。これらに加えて、イベント・メッセージ伝送方式に用いるＥＭＴも、データ放送アプリケーションの運用に重要なシグナリング・テーブルである。

そこで、本明細書で開示する技術では、各デリバリー・セグメントによる独立したデータ放送アプリケーションの運用を実現するために、まず、デリバリー・セグメント毎に、シグナリング・メッセージやシグナリング・テーブルをグルーピングする。ここで、グルーピングの対象とするシグナリング・メッセージやシグナリング・テーブルは、データ伝送メッセージ、ＭＨ−ＡＩＴ、ＥＭＴといった、データ放送アプリケーションの運用に必要又は重要な制御データである。

そして、放送のサービス・レベルの制御情報を記述するＭＰテーブルに、アプリケーション・サービス記述子という新たな記述子をデリバリー・セグメント毎に配置する。より厳密には、同じデリバリー・セグメントが提供するデータ放送アプリケーションのアプリケーション・タイプ毎に、アプリケーション・サービス記述子を配置する。各アプリケーション・サービス記述子内には、対応するデリバリー・セグメントが提供するデータ放送アプリケーションの運用に必要又は重要な上記の各制御データのロケーション情報を示すようにする。また、アプリケーション・サービス記述子には、該当するアプリケーション情報テーブルがデフォルトの監視対象ＡＩＴ設定されていることを示すデフォルトＡＩＴフラグをさらに示す。

なお、アプリケーション・サービス記述子で示すデータ伝送メッセージのロケーション情報により、同メッセージに格納されるデータ・ディレクトリー管理テーブル、データ・アセット管理テーブル、及びデータ・コンテンツ管理テーブルの３つのシグナリング・テーブルのロケーション情報を示すことになる。他方、アプリケーション・サービス記述子で示すＭＨ−ＡＩＴ、ＥＭＴのロケーション情報は、各々のテーブルを単体で格納するＭ２セクション・メッセージのロケーション情報と等価である。

また、アプリケーション・サービス記述子は、対応するデリバリー・セグメントから提供されるデータ放送アプリケーションのフォーマットすなわちアプリケーション・タイプと、アプリケーション・タイプ毎の優先度をさらに示す。

図９には、デリバリー・セグメント毎のアプリケーション・サービス記述子に記述した情報に基づいて、同一の放送番組に対する各デリバリー・セグメントのデータ放送アプリケーション及びアプリケーションに関連する制御情報をそれぞれ独立した系統で配信する放送信号の構成例を示している。

参照番号９１０は、番組制作局からの放送信号を伝送するＩＰデータ・フローである。ＩＰデータ・フロー９１０は、同じＩＰアドレス内の複数のアセット及びシグナリング９１１〜９１６を含んでいる。ＩＰデータ・フロー９１０内は、同一のＩＰアドレスであり、伝送される各ＭＭＴＰパケットをパケット識別子だけで指定することができる。

参照番号９１１、９１２で示すアセットは、番組制作局により制作した放送番組本体のビデオ、オーディオの各データをＭＰＵフォーマットでそれぞれ伝送している。また、参照番号９１３で示すアセットは、番組制作局が上記の放送番組本体に関連して制作した、例えばＨＴＭＬ５形式のデータ放送アプリケーションＡｐｐ１、Ａｐｐ２、Ａｐｐ４を伝送している。

参照番号９１４で示すシグナリングは、上記のデータ・アセット９１３で伝送されるＨＴＭＬ５形式のデータ放送アプリケーションに関連する制御情報、すなわち各種シグナリング・メッセージ並びにシグナリング・テーブルを伝送している。図９では、図面の簡素化のため、ＰＡメッセージに格納して伝送されるＭＰテーブル９１４Ａと、データ放送アプリケーションを運用するために必要又は重要となるデータ伝送メッセージ（ＤＴＭ）９１４Ｂ、ＭＨ−ＡＩＴ９１４Ｃ、ＥＭＴ９１４Ｄのみを描いている。

また、参照番号９１５で示すアセットは、番組制作局が上記の放送番組本体に関連して制作した、ＨＴＭＬ５以外の記述形式（例えば、ｊａｖａ形式）のデータ放送アプリケーションＡｐｐ１１、Ａｐｐ１２、Ａｐｐ１３を伝送している。

参照番号９１６で示すシグナリングは、上記のデータ・アセット９１５で伝送されるｊａｖａ形式のデータ放送アプリケーションに関連する制御情報、すなわち各種シグナリング・メッセージ並びにシグナリング・テーブルを伝送している。図９では、図面の簡素化のため、データ放送アプリケーションを運用するために必要又は重要となるデータ伝送メッセージ（ＤＴＭ）９１６Ｂ、ＭＨ−ＡＩＴ９１６Ｃ、ＥＭＴ９１６Ｄのみを描いている。

参照番号９２０は、配信局から伝送されるデータ放送アプリケーション並びにこれに関連する制御情報を伝送するＩＰデータ・フローであり、データ・アセット９２１とシグナリング９２２を含んでいる。

参照番号９２１で示すデータ・アセットでは、配信局が、上記の放送番組本体に対応するデータ放送アプリケーションＡｐｐ３を伝送している。

参照番号９２２で示すシグナリングでは、上記のデータ・アセット９２１で伝送されるデータ放送アプリケーションＡｐｐ３に関連する制御情報、すなわち各種シグナリング・メッセージ並びにシグナリング・テーブルを伝送している。図９では、図面の簡素化のため、データ放送アプリケーションを運用するために必要又は重要となるデータ伝送メッセージ９２２Ａ、ＭＨ−ＡＩＴ９２２Ｂ、ＥＭＴ９２２Ｃのみを描いている。

参照番号９３０は、インターネットなどのＩＰネットワークである。配信局は、上記の放送番組本体に対応するデータ放送アプリケーションの１つＡｐｐ５を、ＩＰネットワーク９３０上で伝送している。また、第３者は、上記の放送番組本体に対応するデータ放送アプリケーションＡｐｐ６を、ＩＰネットワーク９３０上で伝送している。さらに第３者は、自分が提供するデータ放送アプリケーションＡｐｐ６の処理方法（アプリケーションに適用される起動状態など）並びにロケーション情報（ＵＲＬ）を記述したＭＨ−ＡＩＴ９３１を、ＩＰネットワーク９３０上で配信している。なお、ＩＰネットワーク９３０（通信伝送路）上で配信するデータ放送アプリケーションＡｐｐ５、Ａｐｐ６については、データ伝送メッセージ並びにＥＭＴの伝送は不要である。

シグナリング９１４で伝送されるＰＡメッセージに格納されるＭＰテーブル９１４Ａには、各デリバリー・セグメントについてアプリケーション記述形式毎にアプリケーション・サービス記述子が配置されている。各アプリケーション・サービス記述子内には、対応するデリバリー・セグメントが提供するデータ放送アプリケーションの運用に必要又は重要な上記の各制御データのロケーション情報を示している。

具体的には、ＭＰテーブル９１４Ａ内に配置されたアプリケーション・サービス記述子１は、番組制作局がデータ・アセット９１３で伝送するデータ放送アプリケーションに対応付けて配置され、シグナリング９１４で伝送されるデータ伝送メッセージ９１４Ｂ、ＭＨ−ＡＩＴ９１４Ｃ、ＥＭＴ９１４Ｄのロケーション情報（同じＩＰアドレス内のパケット識別子）を示している。

また、ＭＰテーブル９１４Ａ内に配置されたアプリケーション・サービス記述子２は、番組制作局がデータ・アセット９１５で伝送するデータ放送アプリケーションに対応付けて配置され、シグナリング９１６で伝送されるデータ伝送メッセージ９１６Ｂ、ＭＨ−ＡＩＴ９１６Ｃ、ＥＭＴ９１６Ｄのロケーション情報（同じＩＰアドレス内のパケット識別子）を示している。

また、ＭＰテーブル９１４Ａ内に配置されたアプリケーション・サービス記述子３は、配信局がデータ・アセット９２１並びにＩＰネットワーク９３０で伝送するデータ放送アプリケーションに対応付けて配置され、シグナリング９２２で伝送されるデータ伝送メッセージ９２２Ｂ、ＭＨ−ＡＩＴ９２２Ｃ、ＥＭＴ９２２Ｄのロケーション情報（同じＩＰアドレス内のパケット識別子）を示している。

また、ＭＰテーブル９１４Ａ内に配置されたアプリケーション・サービス記述子４は、第３者がＩＰネットワーク９３０で伝送するデータ放送アプリケーションに対応付けて配置され、第３者からＩＰネットワーク９３０で伝送されるＭＨ−ＡＩＴ９３１のロケーション情報（ＵＲＬ）を示している。なお、放送伝送路ではなくＩＰネットワーク９３０（通信伝送路）上で配信するデータ放送アプリケーションＡｐｐ６については、データ伝送メッセージ並びにＥＭＴの伝送は不要である。

各アプリケーション・サービス記述子１〜４は、アプリケーションがデフォルト・エントリーに設定されていることを示すデフォルト・フラグを含むとともに、対応するデリバリー・セグメントから提供されるデータ放送アプリケーションのフォーマット（記述形式）のタイプと、アプリケーションのタイプ（記述形式）毎の優先度をさらに示す（前述）。

受信機は、番組制作局からの放送信号（シグナリング）９１４を受信すると、ＭＭＴ−ＳＩのエントリー・ポイントとなるＰＡメッセージに格納されているＭＰテーブル９１４Ａを解析して、データ放送アプリケーションを提供するデリバリー・セグメント毎に配置されたアプリケーション・サービス記述子１〜４を取得することができる。

そして、受信機は、アプリケーション・サービス記述子１から、番組制作局がシグナリング９１４で伝送するデータ伝送メッセージ９１４Ｂ、ＭＨ−ＡＩＴ９１４Ｃ、ＥＭＴ９１４Ｄのロケーション情報を得るとともに、ＭＨ−ＡＩＴ９１４Ｃに基づいて番組制作局がデータ・アセット９１３上で伝送するＨＴＭＬ５形式のデータ放送アプリケーションＡｐｐ１、Ａｐｐ２、Ａｐｐ４のアプリケーションの処理方法（アプリケーションに適用される起動状態など）並びにロケーション情報（ＵＲＬ）を取得することができる。また、受信機は、アプリケーション・サービス記述子２から、番組制作局がシグナリング９１６で伝送するデータ伝送メッセージ９１６Ｂ、ＭＨ−ＡＩＴ９１６Ｃ、ＥＭＴ９１６Ｄのロケーション情報を得るとともに、ＭＨ−ＡＩＴ９１６Ｃに基づいて番組制作局がデータ・アセット９１５上で伝送するｊａｖａ形式のデータ放送アプリケーションＡｐｐ１１、Ａｐｐ１２、Ａｐｐ１３のアプリケーションの処理方法（アプリケーションに適用される起動状態など）並びにロケーション情報（ＵＲＬ）を取得することができる。

同様に、受信機は、アプリケーション・サービス記述子３から、配信局が別のＩＰデータ・フロー９２０（シグナリング９２２）で伝送するデータ伝送メッセージ９２２Ｂ、ＭＨ−ＡＩＴ９２２Ｃ、ＥＭＴ９２２Ｄのロケーション情報を得るとともに、ＭＨ−ＡＩＴ９２２Ｃに基づいて配信局がＩＰデータ・フロー９２０（データ・アセット９２１）やＩＰネットワーク９３０上で伝送するデータ放送アプリケーションＡｐｐ３のアプリケーションの処理方法（アプリケーションに適用される起動状態など）並びにロケーション情報（ＵＲＬ）を取得することができる。

同様に、受信機は、アプリケーション・サービス記述子４から、第３者がＩＰネットワーク９３０で伝送するＭＨ−ＡＩＴ９３１のロケーション情報を得るとともに、ＭＨ−ＡＩＴ９３１に基づいて第３者がＩＰネットワーク９３０上で伝送するデータ放送アプリケーションＡｐｐ６のアプリケーションの処理方法（アプリケーションに適用される起動状態など）並びにロケーション情報（ＵＲＬ）を取得することができる。

また、各アプリケーション・サービス記述子１〜４には、それぞれがロケーション情報を示すＭＨ−ＡＩＴ９１４Ｃ、９１６Ｃ、９２２Ｂ、又は９３１のうちいずれがデフォルトの監視対象ＡＩＴであるか否かを、デフォルト・フラグにより示している。さらに、ＭＨ−ＡＩＴは制御対象である複数のアプリケーションうち１つのアプリケーションのみａｐｐｌｉｃａｔｉｏｎ＿ｃｏｎｔｒｏｌ＿ｃｏｄｅとして“ａｕｔｏｓｔａｒｔ”（アプリケーションの起動）を指定して唯一自動起動することができ、結果的に特定のアプリケーションがデフォルト・エントリーと認識される。図９に当てはめて説明すると、例えば、番組制作局に対応付けられたアプリケーション・サービス記述子１でＭＨ−ＡＩＴ９１４Ｃがデフォルトの監視対象ＡＩＴであることを示すとともに、ＭＨ−ＡＩＴ９１４Ｃ内で番組制作局から伝送されるデータ放送アプリケーションのうちＡｐｐ１にのみ“ａｕｔｏｓｔａｒｔ”（アプリケーションの起動）を指定しているとする。この場合、受信機は、アプリケーション・サービス記述子１からデフォルト・フラグを見つけると、番組制作局から配信される当該ＭＨ−ＡＩＴ９１４Ｃにおいて制御対象であるＡｐｐ１、Ａｐｐ２、Ａｐｐ４のうち唯一自動起動を設定したアプリケーションＡｐｐ１をデフォルト・エントリーとして起動することができる。

要するに、図９を参照しながら説明したように、番組制作局としてのキー局、配信局としての各地方局、並びに第３者といったデリバリー・セグメント毎に対応付けられたアプリケーション・サービス記述子をＭＰテーブルに配置することで、同一の放送番組に対するデリバリー・セグメント毎のデータ放送アプリケーション及びアプリケーションに関連する制御情報をそれぞれ独立した系統（デリバリー・パス）で伝送することができる。したがって、データ放送アプリケーションを提供するデリバリー・セグメント毎に独立してアプリケーションの運用を実現することができる。アプリケーション・サービス記述子のシンタックスの詳細については、後述に譲る。

図１０には、同一の放送番組に対するデリバリー・セグメント毎のデータ放送アプリケーション及びアプリケーションに関連する制御情報をそれぞれ独立した系統（デリバリー・パス）で伝送する仕組みを模式的に示している。但し、図１０では、デリバリー・セグメントとして、番組制作局と、２つの配信局１０２０及び１０３０を想定している。

番組制作局１０１０では、ビデオ・エンコーダーやオーディオ・エンコーダーなどからなるＡＶエンコーダー１０１１が、ビデオやオーディオなどの放送番組本体を構成するデータをエンコードする。また、アプリケーション生成部１０１２は、例えば放送番組に連動したデータ放送アプリケーション、並びにそのアプリケーションに関連する制御情報を生成する。マルチプレクサー（ＭＵＸ）１０１３は、エンコードした放送番組のデータと、データ放送アプリケーション及びその制御情報のデータを多重化する。

番組制作局１０１０では、アプリケーションに関連する制御情報を生成し符号化する際、放送のサービス・レベルの制御情報を記述するＭＰテーブルに、アプリケーション・サービス記述子という新たな記述子を、自局１０１０を含む各デリバリー・セグメントに対応付けて配置する。そして、このアプリケーション・サービス記述子内に、デリバリー・セグメント毎のデータ放送アプリケーションの運用に必要又は重要な制御データのロケーション情報を示すようにする。ここで言う、アプリケーションの運用に必要又は重要な制御データは、データ伝送メッセージ、ＭＨ−ＡＩＴ、ＥＭＴである。

そして、番組制作局１０１０から、多重化された配信信号を、Ｂ２Ｂなどの通信伝送路１０４０を介して、各配信局１０２０、１０３０に分配する。

配信局１０２０では、アプリケーション生成部１０２１が、例えば放送番組に非連動のデータ放送アプリケーション、並びにそのアプリケーションに関連する制御情報を生成する。番組非連動のデータ放送アプリケーションは、天気予報やローカル・ニュースといったその地域に密着した情報を提供するアプリケーションである。マルチプレクサー１０２２は、番組制作局１０１０から分配された配信信号と、データ放送アプリケーション及びその制御情報のデータを多重化する。

配信局１０２０において自前のアプリケーションに関連する制御情報を生成し符号化する際、番組制作局１０１０で記述されたＭＰテーブル内の自分に対応付けて配置されたアプリケーション・サービス記述子で指定されているロケーション情報の通りに、自前のアプリケーションの運用に必要又は重要な制御データを格納する。そして、配信局１０２０から、多重化された配信信号が、放送波として送出される。

同様に、配信局１０３０では、アプリケーション生成部１０３１が、例えば放送番組に非連動のデータ放送アプリケーション、並びにそのアプリケーションに関連する制御情報を生成する。マルチプレクサー１０３２は、番組制作局１０１０から分配された配信信号と、データ放送アプリケーション及びその制御情報のデータを多重化する。

配信局１０３０において自前のアプリケーションに関連する制御情報を生成し符号化する際、番組制作局１０１０で記述されたＭＰテーブル内の自分に対応付けて配置されたアプリケーション・サービス記述子で指定されているロケーション情報の通りに、自前のアプリケーションの運用に必要又は重要な制御データを格納する。そして、配信局１０３０から、多重化された配信信号が、放送波として送出される。

本明細書で開示する技術では、図１０に示すような、複数のデリバリー・セグメント（番組制作局１０１０、配信局１０２０、配信局１０３０）がそれぞれ独立したデータ放送アプリケーションの運用を実現するために、ＭＭＴ−ＳＩのエントリー・ポイントとなるＰＡメッセージに格納されるＭＰテーブル内に、各デリバリー・セグメントに対応付けられたアプリケーション・サービス記述子を配置する。

図１１には、シグナリング・メッセージの１つであるＰＡメッセージ１１０１と、ＰＡメッセージに含まれるＭＰテーブル１１０２の構成例を示している。また、図１２には、ＰＡメッセージのシンタックス例１２００を示している。以下、ＰＡメッセージの各パラメーターについて説明する。

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

ｅｘｔｅｎｓｉｏｎフィールドには、ペイロード（ｍｅｓｓａｇｅ＿ｐａｙｌｏａｄ）のフィールドに配置されるテーブルの属性情報が配置される。具体的には、ｎｕｍｂｅｒ＿ｏｆ＿ｔａｂｌｅフィールドには当該ＰＡメッセージに格納するテーブルの数を示し、続くテーブルのインデックス情報のループでは、格納する各テーブルの属性情報として、８ビットのテーブル識別情報（ｔａｂｌｅ＿ｉｄ）と、８ビットのテーブル・バージョン（ｔａｂｌｅ＿ｖｅｒｓｉｏｎ）と、１６ビットのテーブル長（ｔａｂｌｅ＿ｌｅｎｇｔｈ）が配置される。ｔａｂｌｅ＿ｉｄは、テーブルを識別する固定値である。ｔａｂｌｅ＿ｖｅｒｓｉｏｎは、テーブルのバージョンを示す。ｔａｂｌｅ＿ｌｅｎｇｔｈは、テーブルのサイズをバイト単位で示す。

ＰＡメッセージのｍｅｓｓａｇｅ＿ｐａｙｌｏａｄフィールドには、ｎｕｍｂｅｒ＿ｏｆ＿ｔａｂｌｅｓで示される数分だけテーブルが配置される。このフィールドに格納されるＭＰテーブルは、すべてのアセットのリストを含むパッケージに関連する情報を示す。なお、ＭＰテーブルの他にも、ＬＣ（Ｌａｙｏｐｕｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ）テーブルやＰＬ（Ｐａｃｋａｇｅ Ｌｉｓｔ）テーブルもＰＡメッセージに格納されるが、これらは本明細書で開示する技術に直接関連しないので、詳細な説明は省略する。

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

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

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

ＭＰＴ＿ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈは、ＭＰテーブル記述子領域のサイズをバイト単位で示す。続く、参照番号１３０１で示すＭＰテーブル記述子のループでは、ＭＰテーブル記述子の内容をバイト単位（ＭＰＴ＿ｄｅｓｃｒｉｐｔｏｒｓ＿ｂｙｔｅ）で記述する。本実施形態では、アプリケーション・サービス記述子は、ＭＰテーブル記述子の１つとして、デリバリー・セグメント毎に配置される。各アプリケーション・サービス記述子内には、対応するデリバリー・セグメントが提供するデータ放送アプリケーションの運用に必要又は重要な上記の各制御データのロケーション情報を示す。アプリケーション・サービス記述子のシンタックスの詳細については、後述に譲る。

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

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

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

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

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

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

参照番号１４０１で示すａｐｐｌｉｃａｔｉｏｎ＿ｔｙｐｅは、当該アプリケーション・サービス記述子の制御対象となる（言い換えれば、対応するデリバリー・セグメントから伝送される）アプリケーションの形式を示す。アプリケーション・タイプの割り当て例を以下の表１に示しておく。また、参照番号１４０２で示すａｐｐｌｉｃａｔｉｏｎ＿ｐｒｉｏｒｉｔｙは、アプリケーション・タイプ毎の優先度（対応するデリバリー・セグメントから伝送される、上記のアプリケーション・タイプのアプリケーションを起動する優先度）を示す。

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

ＤＴ＿ｍｅｓｓａｇｅ＿ｆｌａｇは、対応するデリバリー・セグメントから、データ放送アプリケーションの制御情報としてデータ伝送メッセージが伝送されるか否かを示すフラグである。また、ＥＭＴ＿ｎｕｍは、対応するデリバリー・セグメントからのＥＭＴの配信数を示す。デリバリー・セグメントがＩＰネットワークでのみデータ放送アプリケーションを配信する場合（放送信号ではデータ放送アプリケーションを配信しない場合）には、データ伝送メッセージやＥＭＴは配信されない。

ＡＩＴ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏは、Ｍ２セクション・メッセージで伝送されるシグナリング・テーブルの１つであるＭＩＴ−ＡＩＴのロケーション情報を、ＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏ（一般ロケーション情報）のシンタックスに従って示す。ＭＨ−ＡＩＴが放送信号で伝送される場合のＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏのｌｏｃａｔｉｏｎ＿ｔｙｐｅは「０ｘ００」であり、通信で伝送される場合のｌｏｃａｔｉｏｎ＿ｔｙｐｅは「０ｘ０５」である。ＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏの詳細については、後述に譲る。

また、ＤＴ＿ｍｅｓｓａｇｅ＿ｆｌａｇが１のときには、データ伝送メッセージのロケーション情報ＤＴ＿ｍｅｓｓａｇｅ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏが、ＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏのシンタックスに従って示される。データ伝送メッセージは放送信号でのみ伝送されるので、ＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏのｌｏｃａｔｉｏｎ＿ｔｙｐｅは基本的に「０ｘ００」である。

また、ＥＭＴ＿ｎｕｍの数分のループで、各ＥＭＴのロケーション情報ＥＭＴ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏが、ＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏのシンタックスに従って示される。ＥＭＴは放送信号でのみ伝送されるので、ＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏのｌｏｃａｔｉｏｎ＿ｔｙｐｅは基本的に「０ｘ００」である。

図１５には、アセットのロケーション情報を示すＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏ（一般ロケーション情報）のシンタックス例１５００を示している。以下、ＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏの各パラメーターについて説明する。

ｌｏｃａｔｉｏｎ＿ｔｙｐｅは、ロケーション情報の種類を８ビットで示し、以下の表２の割り当てに従う。

ｌｏｃａｔｉｏｎ＿ｔｙｐｅが０ｘ００のときは、当該ロケーション情報を含むテーブルが伝送されるＩＰデータ・フローと同一のＩＰデータ・フローのＭＭＴＰパケットのパケット識別情報（ｐａｃｋｅｔ＿ｉｄ）を示す。

ｌｏｃａｔｉｏｎ＿ｔｙｐｅが０ｘ０１のときは、ロケーション情報として、ＩＰｖ４データ・フローのＭＭＴＰパケットを示す。具体的には、ＩＰｖ４データ・フローの送信元アドレス（ｉｐｖ４＿ｓｒｃ＿ａｄｄｒ）と、ＩＰｖ４データ・フローの宛先アドレス（ｉｐｖ４＿ｄｓｔ＿ａｄｄｒ）と、ＩＰデータ・フローの宛先ポート番号（ｄｓｔ＿ｐｏｒｔ）と、パケット識別情報（ｐａｃｋｅｔ＿ｉｄ）を示す。

ｌｏｃａｔｉｏｎ＿ｔｙｐｅが０ｘ０２のときは、ロケーション情報として、ＩＰｖ６データ・フローのＭＭＴＰパケットを示す。具体的には、ＩＰｖ６データ・フローの送信元アドレス（ｉｐｖ６＿ｓｒｃ＿ａｄｄｒ）と、ＩＰｖ６データ・フローの宛先アドレス（ｉｐｖ６＿ｄｓｔ＿ａｄｄｒ）と、ＩＰデータ・フローの宛先ポート番号（ｄｓｔ＿ｐｏｒｔ）と、パケット識別情報（ｐａｃｋｅｔ＿ｉｄ）を示す。

ｌｏｃａｔｉｏｎ＿ｔｙｐｅが０ｘ０３のときは、ロケーション情報として、ＭＰＥＧ−２ ＴＳの放送ネットワークのＭＰＥＧ−２ ＴＳパケットを示す。具体的には、放送ネットワークを識別するためのネットワーク識別情報（ｎｅｔｗｏｒｋ＿ｉｄ）と、ＭＰＥＧ−２ ＴＳを識別するためのトランスポート・ストリーム識別情報（ＭＰＥＧ＿２＿ｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄ）と、ＭＰＥＧ−２ ＴＳパケットのパケット識別情報（ＭＰＥＧ＿２＿ＰＩＤ）を示す。

ｌｏｃａｔｉｏｎ＿ｔｙｐｅが０ｘ０４のときは、ロケーション情報として、ＩＰｖ６データ・フローのＭＰＥＧ−２ ＴＳパケットを示す。具体的には、ＩＰｖ６データ・フローの送信元アドレス（ｉｐｖ６＿ｓｒｃ＿ａｄｄｒ）と、ＩＰｖ６データ・フローの宛先アドレス（ｉｐｖ６＿ｄｓｔ＿ａｄｄｒ）と、ＩＰデータ・フローの宛先ポート番号（ｄｓｔ＿ｐｏｒｔ）と、ＭＰＥＧ−２ ＴＳパケットのパケット識別情報（ＭＰＥＧ＿２＿ＰＩＤ）を示す。

ｌｏｃａｔｉｏｎ＿ｔｙｐｅが０ｘ０５のときは、 ＵＲＬでロケーション情報を示す。具体的には、ＵＲＬ＿ｌｅｎｇｔｈは、ＵＲＬバイト・フィールドの長さをバイト単位で示し、続くＵＲＬバイトのループでは、ＵＲＬ文字列をバイト単位（ＵＲＬ＿ｂｙｔｅ）で示す。

図１６には、Ｍ２セクション・メッセージで伝送されるシグナリング・テーブルの１つであるＭＨ ＡＩＴのシンタックス例１６００を示している。上述したように、ＭＰテーブル内にデリバリー・セグメント毎に配置されるアプリケーション・サービス記述子内のＡＩＴ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏが、対応するデリバリー・セグメントから伝送されるＭＩＴ−ＡＩＴのロケーション情報を一般ロケーション情報（図１５を参照のこと）のシンタックスに従って示す。以下、ＭＨ ＡＩテーブルの各パラメーターの意味について説明する。

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

ａｐｐｌｉｃａｔｉｏｎ＿ｔｙｐｅ（アプリケーション・タイプ）は、１６ビットのフィールドで、当該ＭＨ−ＡＩＴの制御対象となる（言い換えれば、対応するデリバリー・セグメントから伝送される）アプリケーションの形式を示す。アプリケーション・タイプの割り当ては、アプリケーション・サービス記述子と同様、上記の表１に従うものとする。

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

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

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

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

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

ａｐｐｌｉｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒ＿ｌｏｏｐ＿ｌｅｎｇｔｈ（アプリケーション情報記述子ループ長）はアプリケーション情報記述子のバイト長を示し、このバイト数分のループからなる一連の領域にｄｅｓｃｒｉｐｔｏｒ（アプリケーション情報記述子）が書き込まれる。この記述子領域内のアプリケーション情報記述子は、共通記述子とは相違し、ａｐｐｌｉｃａｔｉｏｎ＿ｉｄｅｎｔｉｆｉｅｒで指定したアプリケーションのみに適用される。

図１７には、ＭＰテーブル内にデリバリー・セグメント毎に配置されるアプリケーション・サービス記述子の他のシンタックス例１７００を示している。参照番号１７０１で示すようにアプリケーション・タイプを示すａｐｐｌｉｃａｔｉｏｎ＿ｔｙｐｅは配置するが、アプリケーション・タイプ毎の優先度を示すａｐｐｌｉｃａｔｉｏｎ＿ｐｒｉｏｒｉｔｙフィールドを配置しないことと、参照番号１７０２で示すように記述子の最後にプライベート・データ領域ｐｒｉｖａｔｅ＿ｄａｔａを配置したことの２点で、図１４に示したアプリケーション・サービス記述子のシンタックス例１４００とは相違する。参照番号１７０１で示すａｐｐｌｉｃａｔｉｏｎ＿ｔｙｐｅの意味は、図１４に示したシンタックス例１４００の場合と同様である。

プライベート・データ領域は、データ放送サービスの運用時に必要となる情報を柔軟に定義することができる。プライベート・データ領域に、アプリケーション・タイプ毎の優先度情報を格納するという利用方法も考えられる。

図１８には、プライベート・データ領域のシンタックス例１８００を示している。ｄａｔａ＿ｓｅｇｍｅｎｔ＿ｔａｇは、４ビットのフィールドで、プライベート・データ領域の種類（最大で１６種類）を識別する。ｄａｔａ＿ｌｅｎｇｔｈは、このフィールドより後に続く領域（ｄａｔａ＿ｓｅｇｍｅｎｔ）のデータ・バイト数（最大で１６バイト）を書き込む領域である。ｄａｔａ＿ｓｅｇｍｅｎｔには、プライベート・データの内容が格納される。

また、図１９には、プライベート・データ領域の利用例を示している。ここでは、アプリケーション・タイプ毎の優先度情報を格納するという利用方法を想定している。図示の例では、ｄａｔａ＿ｓｅｇｍｅｎｔ＿ｔａｇが「１」で、当該プライベート・データ領域をアプリケーション・タイプ毎の優先度情報に利用することを識別する。また、ｄａｔａ＿ｓｅｇｍｅｎｔのデータ長（ｄａｔａ＿ｌｅｎｇｔｈ）を１バイトとし、ｄａｔａ＿ｓｅｇｍｅｎｔには、当該アプリケーション・タイプの優先度を８ビットの値で示す。

図２０には、ＭＰテーブル内にデリバリー・セグメント毎に配置されるアプリケーション・サービス記述子のさらに他のシンタックス例２０００を示している。図１４に示したアプリケーション・サービス記述子のシンタックス例１４００では、アプリケーション・タイプとアプリケーション・タイプ毎の優先度をそれぞれ個別のパラメーター（ａｐｐｌｉｃａｔｉｏｎ＿ｔｙｐｅ、ａｐｐｌｉｃａｔｉｏｎ＿ｐｒｉｏｒｉｔｙ）で示した。これに対し、図２０に示すシンタックス例２０では、ａｐｐｌｉｃａｔｉｏｎ＿ｔｙｐｅ及びａｐｐｌｉｃａｔｉｏｎ＿ｐｒｉｏｒｉｔｙという２つのパラメーターを配置せず、代わりに参照番号２００１で示すように、ａｐｐｌｉｃａｔｉｏｎ＿ｂｉｔｍａｐという８ビットの単一のパラメーターでアプリケーション・タイプとアプリケーション・タイプ毎の優先度の両方を示すという点で相違する。また、図１７に示したシンタックス例１７００と同様に、参照番号２００２で示すように、記述子の最後にプライベート・データ領域ｐｒｉｖａｔｅ＿ｄａｔａを配置した。プライベート・データ領域は、データ放送サービスの運用時に必要となる情報を柔軟に定義することができる（同上）。

ａｐｐｌｉｃａｔｉｏｎ＿ｂｉｔｍａｐの運用方法に一例について説明する。ａｐｐｌｉｃａｔｉｏｎ＿ｂｉｔｍａｐでは、当該アプリケーション・サービス記述子の制御対象となる（言い換えれば、対応するデリバリー・セグメントから伝送される）アプリケーション・タイプを２ビットで表現するようにしている。２ビットで表現されるアプリケーション・タイプの種別を表４に例示する。

また、ａｐｐｌｉｃａｔｉｏｎ＿ｂｉｔｍａｐの８ビット中に上記のアプリケーション・タイプを示すに２ビットの値を格納する位置によってその優先度を示す。図２１には、８ビットのａｐｐｌｉｃａｔｉｏｎ＿ｂｉｔｍａｐでアプリケーション・タイプの優先度を示す方法の一例を図解している。図示の例では、８ビットを２ビット毎のブロックに区切り、各ブロックに対しＭＳＢ側から順に優先度１、２、３、４を割り当てている。そして、アプリケーション・タイプを識別する２ビットの値を、そのアプリケーション・タイプに与えられた優先度に対応するブロックに格納し、その他のビットをすべて「０」にする。例えば、図２２に示すように、「０１」で識別されるアプリケーション方式１がＭＳＢ側に格納されていると、そのアプリケーション・タイプ（ＨＴＭＬ５）は最も高い優先度といとうことになる。

なお、上記のようなａｐｐｌｉｃａｔｉｏｎ＿ｂｉｔｍａｐの運用方法では、２ビットを用いて３種類のアプリケーション・タイプしか識別することができない。何故なら、「００」にアプリケーション・タイプを割り当てると、ａｐｐｌｉｃａｔｉｏｎ＿ｂｉｔｍａｐの８ビットはすべて「０」になり、空の情報と相違しないからである。第４のアプリケーション・タイプが出現したときには、ａｐｐｌｉｃａｔｉｏｎ＿ｂｉｔｍａｐをすべて０にして、プライベート・データ領域を利用してアプリケーション・タイプとアプリケーション・タイプ毎の優先度を示すようにしてもよい。

上述したように、本明細書で開示する技術では、放送のサービス・レベルの制御情報を記述するＭＰテーブルに、アプリケーション・サービス記述子という新たな記述子を、データ放送アプリケーションを提供するデリバリー・セグメント毎に配置することとした。アプリケーション・サービス記述子のシンタックス例は、図１４、図１７、並びに図２０に示した通りである。アプリケーション・サービス記述子のシンタックスには、デリバリー・セグメントを直接識別する情報は含まない。

また、１つのアプリケーション・サービス記述子には１つのアプリケーション・タイプの情報のみを記述するように規定する。各シンタックス例におけるアプリケーション・タイプの表現方法は既に述べた通りである。

また、デリバリー・セグメントから複数のアプリケーション・タイプのデータ放送アプリケーションが提供されることを想定して、どちらを優先して起動するかを指定するために、アプリケーション・サービス記述子内でアプリケーション・タイプ毎の優先度（ａｐｐｌｉｃａｔｉｏｎ＿ｐｒｉｏｒｉｔｙ）を示すように規定する。各シンタックス例におけるアプリケーション・タイプの優先度の表現方法は、図１４、図１７、並びに図２０を参照しながら既に説明した通りである。

したがって、受信機側では、図９に示したような放送信号を受信すると、ＭＰテーブルに配置される複数のアプリケーション・サービス記述子でそれぞれ示されるアプリケーション・タイプ毎の優先度を判断した上で、デフォルトの監視対象ＡＩＴであることを示すフラグにより、さらに特定のアプリケーション情報テーブル（ＭＨ−ＡＩＴ）及びデータ伝送メッセージを選択することができる。

図２３には、受信機においてデータ放送アプリケーションを起動するための処理手順をフローチャートの形式で示している。但し、受信機は、図９に示したような放送信号を受信することを想定している。また、図２３に示す処理手順は、ＭＰテーブルに配置されるアプリケーション・サービス記述子のシンタックスとして、図１４、図１７、並びに図２０のいずれにも対応していることを理解されたい。また、この処理手順は、受信機において選局動作時に起動し、受信機内のアプリケーション制御部４０８が中心となって実行されるものとする。

受信機は、放送信号を受信すると、放送サービスのエントリー・ポイントであるＰＡメッセージで伝送されるＭＰテーブルを取得し、その内容を解析する（ステップＳ２３０１）。

ここで、受信機は、ＭＰテーブル内にアプリケーション・サービス記述子が配置されているかどうかをチェックする（ステップＳ２３０２）。

ここで、ＭＰテーブル内にアプリケーション・サービス記述子が１つも配置されていない場合には、データ放送アプリケーションの起動処理を行なうことなく、本処理ルーチンを終了する。

また、ＭＰテーブル内に複数のアプリケーション・サービス記述子が配置されている場合には、各アプリケーション・サービス記述子の内容をチェックして、当該受信機で動作可能なアプリケーション・タイプを示すアプリケーション・サービス記述子が複数あるかどうかをチェックする（ステップＳ２３０６）。

動作可能なアプリケーション・タイプが複数ある場合には（ステップＳ２３０６のＹｅｓ）、受信機は、その中で優先度が高いアプリケーション・タイプのアプリケーション・サービス記述子を選択する（ステップＳ２３０７）。そして、受信機は、選択したアプリケーション・サービス記述子の中で、デフォルトの監視対象ＡＩＴフラグが設定されているものを選択する（ステップＳ２３０８）。

また、動作可能なアプリケーション・タイプを示すアプリケーション・サービス記述子が１つしかない場合には（ステップＳ２３０６のＮｏ）、受信機は、動作可能なアプリケーション・タイプを示すアプリケーション・サービス記述子の中で、デフォルトの監視対象ＡＩＴフラグが設定されているものを選択する（ステップＳ２３０８）。

ステップＳ２３０３では、受信機は、アプリケーション・サービス記述子で指定されたＭＨ−ＡＩＴを取得する。具体的には、ＭＰテーブル内にただ１つのアプリケーション・サービス記述子が配置されている場合には、そのアプリケーション・サービス記述子でロケーション情報が指定されたＭＨ−ＡＩＴを取得する。また、ＭＰテーブル内に複数のアプリケーション・サービス記述子が配置されている場合には、ステップＳ２３０８で選択された、デフォルトの監視対象ＡＩＴフラグが設定されているアプリケーション・サービス記述子でロケーション情報が指定されたＭＨ−ＡＩＴを取得する。

次いで、受信機は、ＭＨ−ＡＩＴに指定されたデータ放送アプリケーションを取得する（ステップＳ２３０４）。ＭＨ−ＡＩＴに指定されたデータ放送アプリケーションのデータ・ファイルを取得する方法の詳細については、例えば本出願人に既に譲渡されている特願２０１４−２５０２７９号明細書を参照されたい。

そして、受信機は、アプリケーション・エンジン４０９で、取得したデータ放送アプリケーションを起動する（ステップＳ２３０５）。

図２４に示す４つのアプリケーション・サービス記述子２４０１〜２４０４がＭＰテーブルに配置されている場合を例にとって、受信機が図２３に示した処理手順に従ってアプリケーションの優先度とデフォルトの監視対象ＡＩＴを判定する処理動作について説明する。

参照番号２４０１並びに２４０２は、番組を制作したキー局に対応して配置されたアプリケーション・サービス記述子である。但し、各アプリケーション・サービス記述子２４０１、２４０２は、デリバリー・セグメントとしてのキー局を識別する情報を含まない。一方のアプリケーション・サービス記述子２４０１は、キー局が提供する、アプリケーション・タイプがＨＴＭＬ５形式のデータ放送アプリケーションの情報並びにそのアプリケーション・タイプの優先度を示す。アプリケーション・サービス記述子２４０１では、キー局が提供するＨＴＭＬ５形式の優先度が「１０」、デフォルトの監視対象ＡＩＴフラグが「１」に指定されているものとする。他方のアプリケーション・サービス記述子２４０２は、キー局が提供する、アプリケーション・タイプがｊａｖａ形式のデータ放送アプリケーションの情報並びにそのアプリケーション・タイプの優先度を示す。アプリケーション・サービス記述子２４０２では、キー局が提供するｊａｖａ形式の優先度が「５」、デフォルトの監視対象ＡＩＴフラグが「０」に指定されているものとする。

参照番号２４０３並びに２４０４は、ある地方局に対応して配置されたアプリケーション・サービス記述子である。但し、各アプリケーション・サービス記述子２４０３、２４０４は、デリバリー・セグメントとしての当該地方局を識別する情報を含まない。一方のアプリケーション・サービス記述子２４０３は、この地方局が提供する、アプリケーション・タイプがＨＴＭＬ５形式のデータ放送アプリケーションの情報並びにそのアプリケーション・タイプの優先度を示す。アプリケーション・サービス記述子２４０３では、この地方局が提供するＨＴＭＬ５形式の優先度が「１０」、デフォルトの監視対象ＡＩＴフラグが「０」に指定されているものとする。他方のアプリケーション・サービス記述子２４０４は、この地方局が提供する、アプリケーション・タイプがｊａｖａ形式のデータ放送アプリケーションの情報並びにそのアプリケーション・タイプの優先度を示す。アプリケーション・サービス記述子２４０４では、この地方局が提供するｊａｖａ形式の優先度が「５」、デフォルトの監視対象ＡＩＴフラグが「１」に指定されている。

受信機は、図２４に示す複数のアプリケーション・サービス記述子２４０１〜２４０４がＭＰテーブルに配置された放送信号を受信したとき、ステップＳ２３０２の分岐からステップＳ２３０６に進んで、動作可能なアプリケーション・タイプを示すアプリケーション・サービス記述子が複数あるかどうかをチェックする。

例えば、受信機がＨＴＭＬ５及びｊａｖａのいずれのアプリケーション・タイプも動作可能な場合には、ステップＳ２３０７に進んで、アプリケーション・サービス記述子２４０１〜２４０４の中で優先度が高い「１０」に指定されたアプリケーション・タイプＨＴＭＬ５を指定するアプリケーション・サービス記述子２４０１、２４０３を選択する。そして、ステップＳ２３０８では、受信機は、デフォルトの監視対象ＡＩＴフラグが設定されているアプリケーション・サービス記述子２４０１を選択する。

また、受信機がＨＴＭＬ５のアプリケーション・タイプのみ動作可能な場合には、ステップＳ２３０８に進んで、受信機は、アプリケーション・タイプがＨＴＭＬ５を指定するアプリケーション・サービス記述子２４０１、２４０３の中で、デフォルトの監視対象ＡＩＴフラグが設定されているアプリケーション・サービス記述子２４０１を選択する。

このように受信機は、図２３に示した処理手順に従って、ＭＰテーブルに配置されるアプリケーション・サービス記述子で示されるアプリケーション・タイプ毎の優先度を判断した上で、デフォルトの監視対象ＡＩＴであることを示すフラグにより、さらに特定のＭＨ−ＡＩＴ及びデータ伝送メッセージを選択することができる。

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

本明細書で開示する技術は、トランスポート方式としてＭＭＴを採用するさまざまな放送システムに適用することができる。また、本明細書で開示する技術は、データ放送アプリケーションのデリバリー・セグメントが複数存在することが想定される放送システムに適用することができる。

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

なお、本明細書の開示の技術は、以下のような構成をとることも可能である。
（１）放送番組に対するアプリケーションを送信するアプリケーション送信部と、
前記アプリケーションに関わるシグナリング・メッセージを送信するシグナリング・メッセージ送信部と、
を具備し、
前記シグナリング・メッセージ送信部は、所定のシグナリング・メッセージで伝送するシグナリング・テーブル内に、アプリケーションを提供するデリバリー・セグメント毎のアプリケーション・サービス記述子を配置して送信する、
送信装置。
（２）前記シグナリング・メッセージ送信部は、各アプリケーション・サービス記述子で、対応するデリバリー・セグメントが提供するアプリケーションの運用に必要又は重要な制御データを格納するシグナリング・メッセージ又はシグナリング・テーブルのロケーション情報を示す、
上記（１）に記載の送信装置。
（３）前記シグナリング・メッセージ送信部は、各アプリケーション・サービス記述子に、対応するデリバリー・セグメントが伝送するデータ伝送メッセージ、アプリケーション情報テーブル、又はイベント・メッセージ・テーブルのロケーション情報を示す、
上記（１）に記載の送信装置。
（４）前記シグナリング・メッセージ送信部は、放送サービスのエントリー・ポイントとなるシグナリング・メッセージで伝送するシグナリング・テーブル内に、デリバリー・セグメント毎のアプリケーション・サービス記述子を配置して送信する、
上記（１）に記載の送信装置。
（５）前記シグナリング・メッセージ送信部は、各アプリケーション・サービス記述子でデリバリー・セグメントが提供するアプリケーション・タイプの情報を示す、
上記（１）に記載の送信装置。
（６）前記シグナリング・メッセージ送信部は、各アプリケーション・サービス記述子でアプリケーション・タイプ毎の優先度の情報をさらに示す、
上記（５）に記載の送信装置。
（７）前記シグナリング・メッセージ送信部は、アプリケーション・タイプ毎の優先度の情報を示すパラメーター（ａｐｐｌｉｃａｔｉｏｎ＿ｐｒｉｏｒｉｔｙ）を各アプリケーション・サービス記述子に含める、
上記（６）に記載の送信装置。
（８）前記シグナリング・メッセージ送信部は、各アプリケーション・サービス記述子に配置されるプライベート・データ領域で、アプリケーション・タイプ毎の優先度の情報を示す、
上記（６）に記載の送信装置。
（９）前記シグナリング・メッセージ送信部は、所定ビット長のビットマップ情報領域（ａｐｐｌｉｃａｔｉｏｎ＿ｂｉｔｍａｐ）でアプリケーション・タイプ及びその優先度を示す、
上記（６）に記載の送信装置。
（１０）前記シグナリング・メッセージ送信部は、アプリケーション・タイプを示すｎビット情報をｍビット長のビットマップ情報領域に格納する位置により当該アプリケーション・タイプの優先度を示す（但し、ｎ＜ｍとする）、
上記（９）に記載の送信装置。
（１１）前記シグナリング・メッセージ送信部は、各アプリケーション・サービス記述子で、対応するデリバリー・セグメントについてのアプリケーション情報テーブルがデフォルトの監視対象に指定されているか否かを示す、
上記（１）に記載の送信装置。
（１２）前記シグナリング・メッセージ送信部は、各アプリケーション・サービス記述子で、対応するデリバリー・セグメントから伝送されるイベント・メッセージ・テーブルの数の情報を示す、
上記（１）に記載の送信装置。
（１３）前記アプリケーション送信部は、ペイロードにアプリケーションを含むことを示す第１のペイロード種別情報をパケット・ヘッダーに挿入した第１の伝送パケットでアプリケーションを送信し、
前記シグナリング・メッセージ送信部は、ペイロードにシグナリング・メッセージを含むことを示す第２のペイロード識別情報をパケット・ヘッダーに挿入した第２の伝送パケットでシグナリング・メッセージを送信する、
上記（１）に記載の送信装置。
（１４）放送番組に対するアプリケーションを送信するアプリケーション送信ステップと、
前記アプリケーションに関わるシグナリング・メッセージを送信するシグナリング・メッセージ送信ステップと、
を有し
前記シグナリング・メッセージ送信ステップでは、所定のシグナリング・メッセージで伝送するシグナリング・テーブル内に、アプリケーションを提供するデリバリー・セグメント毎のアプリケーション・サービス記述子を配置して送信する、
送信方法。
（１５）放送番組に対するアプリケーションを受信するアプリケーション受信部と、
前記アプリケーションに関わるシグナリング・メッセージを受信するシグナリング・メッセージ受信部と、
を具備し、
前記シグナリング・メッセージ受信部は、伝送するシグナリング・テーブル内に、アプリケーションを提供するデリバリー・セグメント毎のアプリケーション・サービス記述子を配置したシグナリング・テーブルが格納された所定のシグナリング・メッセージを受信する、
受信装置。
（１６）前記アプリケーション受信部が受信したアプリケーションの起動を制御するアプリケーション制御部をさらに備え、
前記アプリケーション制御部は、前記シグナリング・テーブルに配置される各アプリケーション・サービス記述子でアプリケーション・タイプ毎の優先度に基づいて、前記シグナリング・メッセージで受信するシグナリング・メッセージ又はシグナリング・テーブルを選択する、
上記（１５）に記載の受信装置。
（１７）放送番組に対するアプリケーションを受信するアプリケーション受信ステップと、
前記アプリケーションに関わるシグナリング・メッセージを受信するシグナリング・メッセージ受信ステップと、
を有し、
前記シグナリング・メッセージ受信ステップでは、伝送するシグナリング・テーブル内に、アプリケーションを提供するデリバリー・セグメント毎のアプリケーション・サービス記述子を配置したシグナリング・テーブルが格納された所定のシグナリング・メッセージを受信する、
受信方法。

１０…ディジタル放送システム
１１…放送送出システム、１２…受信機
３０１…時計部、３０２…信号送出部
３０３…ビデオ・エンコーダー
３０４…オーディオ・エンコーダー
３０５…キャプション・エンコーダー
３０６…シグナリング・エンコーダー
３０７…ファイル・エンコーダー、３０８…ＥＤＰＳ
３０９…ＴＬＶシグナリング・エンコーダー
３１０…ＩＰサービス・マルチプレクサー
３１１…ＴＬＶマルチプレクサー、３１２…変調・送信部
４０１…チューナー・復調部、４０２…デマルチプレクサー
４０２−１…ＴＬＶフィルター、４０２−２…ＩＰフィルター
４０２−３…ＵＤＰフィルター、４０２−４…ＭＭＴフィルター
４０２−５…ＳＩフィルター、４０３…時計回復部
４０４…ビデオ・デコーダー、４０５…オーディオ・デコーダー
４０６…キャプション・デコーダー、４０７…システム制御部
４０８…アプリケーション制御部
４０９…データ放送アプリケーション・エンジン
４１０…ＩＰインターフェース、４１１…合成部
１０１０…番組制作局、１０１１…ＡＶエンコーダー
１０１２…アプリケーション生成部、１０１３…マルチプレクサー
１０２０…配信局、１０２１…アプリケーション生成部
１０２２…マルチプレクサー、１０３０…配信局
１０３１…アプリケーション生成部
１０３２…マルチプレクサー、１０４０…通信伝送路

Claims (3)

1. 放送番組に対するアプリケーションを送信するアプリケーション送信部と、
   前記アプリケーションに関わる制御情報を送信する制御情報送信部と、
   を具備し、
   前記制御情報送信部は、パッケージを構成する情報を記述するテーブル内にアプリケーション・サービス記述子を配置して送信し、
   前記アプリケーション・サービス記述子は、アプリケーション情報テーブルのロケーション情報と、前記アプリケーション情報テーブルがデフォルトの監視対象であるか否かを示すフラグと、対象となるアプリケーションの形式を示す情報を含む、
   送信装置。
2. 前記アプリケーション送信部は、ペイロードにアプリケーションを含むことを示す第１のペイロード種別情報をパケット・ヘッダーに挿入した第１の伝送パケットでアプリケーションを送信し、
   前記制御情報送信部は、ペイロードに制御情報を含むことを示す第２のペイロード識別情報をパケット・ヘッダーに挿入した第２の伝送パケットで制御情報を送信する、
   請求項１に記載の送信装置。
3. 放送番組に対するアプリケーションを送信するアプリケーション送信ステップと、
   前記アプリケーションに関わる制御情報を送信する制御情報送信ステップと、
   を有し
   前記制御情報送信ステップでは、パッケージを構成する情報を記述するテーブル内にアプリケーション・サービス記述子を配置して送信し、
   前記アプリケーション・サービス記述子は、アプリケーション情報テーブルのロケーション情報と、前記アプリケーション情報テーブルがデフォルトの監視対象であるか否かを示すフラグと、対象となるアプリケーションの形式を示す情報を含む、
   送信方法。