(57)【要約】【課題】ＭＭＴにおけるイベント・メッセージ伝送方式を提供する。【解決手段】ＭＨ−ＡＩＴ内に、アプリケーションに対応した値となるイベント・メッセージ・グループ識別情報（ＥＭＧｉｄ）を指定するイベント・メッセージ・グループ記述子を新規に配置する。そして、ＥＭＴにはＥＭＧｉｄを指定して、アプリケーションに限定したイベント・メッセージの記述を行なって伝送する。する。また、複数のＥＭＴを同時に伝送する場合には、ＭＰテーブルに配置するアプリケーション・サービス記述子の複数のＥＭＴのロケーション情報を指定するループで、ＥＭＴ＿ｔａｇを指定する。【選択図】  図２２
2016174239.tif 000002
【特許請求の範囲】
【請求項１】
放送番組向けのアプリケーションを送信するアプリケーション送信部と、
アプリケーションに関わる制御情報を送信する制御情報送信部と、
を具備し、
前記制御情報送信部は、アプリケーションに対するイベント・メッセージを送信するとともに、アプリケーションに対応したイベント・メッセージ・グループ識別情報を指定するイベント・メッセージ・グループ記述子を配置したシグナリング・テーブルを送信する、
送信装置。
【請求項２】
前記制御情報送信部は、前記アプリケーション送信部から送出される各アプリケーションの処理方法並びにロケーション情報を指定するアプリケーション情報テーブルに前記イベント・メッセージ・グループ記述子を配置して送信する、
請求項１に記載の送信装置。
【請求項３】
前記制御情報送信部は、前記アプリケーション情報テーブルのコモン・ループに前記イベント・メッセージ・グループ記述子を配置して前記放送番組向けのすべてのアプリケーションに共通のイベント・メッセージ・グループ識別情報を指定し、又は、前記アプリケーション情報テーブルのアプリケーション・ループに前記イベント・メッセージ・グループ記述子を配置してアプリケーション毎又は所定のアプリケーション・グループ毎のイベント・メッセージ・グループ識別情報を指定する、
請求項２に記載の送信装置。
【請求項４】
前記制御情報送信部は、対応するアプリケーションを限定するイベント・メッセージ・グループ識別情報を記述したイベント・メッセージを送信する、
請求項１に記載の送信装置。
【請求項５】
前記アプリケーション送信部は、複数のアプリケーション伝送路でアプリケーションを送信し、
前記制御情報送信部は、アプリケーション伝送路毎に対応したイベント・メッセージ伝送路で各アプリケーションに向けたイベント・メッセージを送信する、
請求項１乃至４のいずれかに記載の送信装置。
【請求項６】
前記制御情報送信部は、伝送路毎のイベント・メッセージを識別するイベント・メッセージ識別タグとイベント・メッセージのロケーション情報の指定を含むアプリケーション・サービス記述子をさらに送信する、
請求項５に記載の送信装置。
【請求項７】
前記制御情報送信部は、前記アプリケーション・サービス記述子を配置したＭＰテーブルを放送サービスのエントリー・ポイントとなるＰＡ（Ｐａｃｋａｇｅ  Ａｃｃｅｓｓ）メッセージに格納して送信する、
請求項６に記載の送信装置。
【請求項８】
前記アプリケーション送信部は、対応するイベント・メッセージのイベント・メッセージ識別タグを指定してイベント・メッセージの監視を指示するアプリケーションを送信する、
請求項６又は７のいずれかに記載の送信装置。
【請求項９】
前記アプリケーション送信部及び前記制御情報送信部は、所定のトランスポート方式により前記アプリケーション及び前記制御情報をそれぞれ送信する、
請求項１乃至８のいずれかに記載の送信装置。
【請求項１０】
放送番組向けのアプリケーションを送信するアプリケーション送信ステップと、
アプリケーションに関わる制御情報を送信する制御情報送信ステップと、
を有し、
前記制御情報送信ステップでは、アプリケーションに対するイベント・メッセージを送信するとともに、アプリケーションに対応したイベント・メッセージ・グループ識別情報を指定するイベント・メッセージ・グループ記述子を配置したシグナリング・テーブルを送信する、
送信方法。
【請求項１１】
放送番組向けのアプリケーションを受信するアプリケーション受信部と、
アプリケーションに関わる制御情報を受信する制御情報受信部と、
受信した制御情報に基づいてアプリケーションの実行を制御するアプリケーション制御部と、
を具備し、
前記制御情報受信部は、アプリケーションに対するイベント・メッセージを送信するとともに、アプリケーションに対応したイベント・メッセージ・グループ識別情報を指定するイベント・メッセージ・グループ記述子を配置したシグナリング・テーブルを受信する、
受信装置。
【請求項１２】
前記制御情報受信部は、各アプリケーションの処理方法並びにロケーション情報を指定するるすとともに、前記イベント・メッセージ・グループ記述子を配置したアプリケーション情報テーブルを受信する、
請求項１１に記載の受信装置。
【請求項１３】
前記制御情報受信部は、対応するアプリケーションを限定するイベント・メッセージ・グループ識別情報を記述したイベント・メッセージを受信し、
前記アプリケーション制御部は、イベント・メッセージ・グループ記述子でイベント・メッセージ・グループ識別情報が指定されたアプリケーションに限定して、受信したイベント・メッセージの処理を行なう、
請求項１１に記載の受信装置。
【請求項１４】
前記アプリケーション受信部は、複数のアプリケーション伝送路でアプリケーションを受信し、
前記制御情報受信部は、アプリケーション伝送路毎に対応したイベント・メッセージ伝送路で各アプリケーションに向けたイベント・メッセージを受信する、
請求項１１乃至１３のいずれかに記載の送信装置。
【請求項１５】
前記制御情報受信部は、伝送路毎のイベント・メッセージを識別するイベント・メッセージ識別タグとイベント・メッセージのロケーション情報の指定を含むアプリケーション・サービス記述子をさらに受信する、
請求項１４に記載の送信装置。
【請求項１６】
前記アプリケーション制御部は、前記アプリケーション受信部が受信したアプリケーションが指定するイベント・メッセージ識別タグに対して前記アプリケーション・サービス記述子が指定するロケーション情報に基づいてイベント・メッセージを監視する、
請求項１５に記載の受信装置。
【請求項１７】
前記アプリケーション制御部は、受信したイベント・メッセージが指定するイベント・メッセージ・グループ識別情報が前記イベント・メッセージ・グループ記述子で現在実行中のアプリケーションに指定されているか否かに応じて、イベントの発火を制御する、
請求項１６に記載の受信装置。
【請求項１８】
前記アプリケーション受信部及び前記制御情報受信部は、所定のトランスポート方式により前記アプリケーション及び前記制御情報をそれぞれ受信する、
請求項１１乃至１７のいずれかに記載の送信装置。
【請求項１９】
放送番組向けのアプリケーションを受信するアプリケーション受信ステップと、
アプリケーションに関わる制御情報を受信する制御情報受信ステップと、
受信した制御情報に基づいてアプリケーションの実行を制御するアプリケーション制御ステップと、
を有し、
前記制御情報受信ステップでは、アプリケーションに対するイベント・メッセージを送信するとともに、アプリケーションに対応したイベント・メッセージ・グループ識別情報を指定するイベント・メッセージ・グループ記述子を配置したシグナリング・テーブルを受信する、
受信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本明細書で開示する技術は、所定のトランスポート方式によりデータ放送アプリケーション及びその制御情報を送信する送信装置及び送信方法、並びに、所定のトランスポート方式により伝送されるデータ放送アプリケーション及びその制御情報を受信し、制御情報に基づいてデータ放送アプリケーションを実行する受信装置及び受信方法に関する。
【背景技術】
【０００２】
次世代のディジタル放送方式として、ＭＰＥＧで新たなメディア・トランスポート方式として規格化されたＭＭＴ（ＭＰＥＧ  Ｍｅｄｉａ  Ｔｒａｎｓｐｏｒｔ）方式による超高解像度ＴＶ放送規格が検討されている（例えば、特許文献１を参照のこと）。ＭＭＴ方式では、異なる伝送路の組み合わせで利用することが容易であり、放送や通信の複数の伝送路に共通に用いることができる。
【０００３】
ＭＭＴ方式のＴＶ放送規格では、映像や音声、字幕などの放送番組本体のストリーム・メディアをタイムド（Ｔｉｍｅｄ）ＭＰＵ（Ｍｅｄｉａ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）フォーマットで伝送する一方、データ放送アプリケーションをノンタイムド（Ｎｏｎ  ｔｉｍｅｄ）ＭＰＵフォーマットで伝送する方式も規定されている。
【０００４】
データ放送アプリケーションには、放送番組に連動した番組連動型データ放送アプリケーションと、ニュースや天気予報のように放送番組とは特に連動しない番組非連動型データ放送アプリケーションに大別することができる。例えば番組連動型のアプリケーションは、放送番組の切り替わりや放送番組内でのシーンの切り替わりに同期して処理（アクション）を実行するサービスがある。このため、放送局から受信機で動作しているアプリケーションに対して、即座にあるいは指定した時刻に、メッセージ情報を送る手段として、イベント・メッセージ伝送方式について検討が行なわれている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１４−２０００５４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
本明細書で開示する技術の目的は、所定のトランスポート方式によりデータ放送アプリケーション及びその制御情報を好適に送信することができる、優れた送信装置及び送信方法を提供することにある。
【０００７】
また、本明細書で開示する技術の目的は、所定のトランスポート方式により伝送されるデータ放送アプリケーション及びその制御情報を好適に受信し、制御情報に基づいてデータ放送アプリケーションを実行することができる、優れた受信装置及び受信方法を提供することにある。
【課題を解決するための手段】
【０００８】
本願は、上記課題を参酌してなされたものであり、請求項１に記載の技術は、
放送番組向けのアプリケーションを送信するアプリケーション送信部と、
アプリケーションに関わる制御情報を送信する制御情報送信部と、
を具備し、
前記制御情報送信部は、アプリケーションに対するイベント・メッセージを送信するとともに、アプリケーションに対応したイベント・メッセージ・グループ識別情報を指定するイベント・メッセージ・グループ記述子を配置したシグナリング・テーブルを送信する、
送信装置である。
【０００９】
本願の請求項２に記載の技術によれば、請求項１に記載の送信装置の前記制御情報送信部は、前記アプリケーション送信部から送出される各アプリケーションの処理方法並びにロケーション情報を指定するアプリケーション情報テーブルに前記イベント・メッセージ・グループ記述子を配置して送信するように構成されている。
【００１０】
本願の請求項３に記載の技術によれば、請求項２に記載の送信装置の前記制御情報送信部は、前記アプリケーション情報テーブルのコモン・ループに前記イベント・メッセージ・グループ記述子を配置して前記放送番組向けのすべてのアプリケーションに共通のイベント・メッセージ・グループ識別情報を指定し、又は、前記アプリケーション情報テーブルのアプリケーション・ループに前記イベント・メッセージ・グループ記述子を配置してアプリケーション毎又は所定のアプリケーション・グループ毎のイベント・メッセージ・グループ識別情報を指定するように構成されている。
【００１１】
本願の請求項４に記載の技術によれば、請求項１に記載の送信装置の前記制御情報送信部は、対応するアプリケーションを限定するイベント・メッセージ・グループ識別情報を記述したイベント・メッセージを送信するように構成されている。
【００１２】
本願の請求項５に記載の技術によれば、請求項１乃至４のいずれかに記載の送信装置の前記アプリケーション送信部は、複数のアプリケーション伝送路でアプリケーションを送信し、前記制御情報送信部は、アプリケーション伝送路毎に対応したイベント・メッセージ伝送路で各アプリケーションに向けたイベント・メッセージを送信するように構成されている。
【００１３】
本願の請求項６に記載の技術によれば、請求項５に記載の送信装置の前記制御情報送信部は、伝送路毎のイベント・メッセージを識別するイベント・メッセージ識別タグとイベント・メッセージのロケーション情報の指定を含むアプリケーション・サービス記述子をさらに送信するように構成されている。
【００１４】
本願の請求項７に記載の技術によれば、請求項６に記載の送信装置の前記制御情報送信部は、前記アプリケーション・サービス記述子を配置したＭＰテーブルを放送サービスのエントリー・ポイントとなるＰＡメッセージに格納して送信するように構成されている。
【００１５】
本願の請求項８に記載の技術によれば、請求項６又は７のいずれかに記載の送信装置の前記アプリケーション送信部は、対応するイベント・メッセージのイベント・メッセージ識別タグを指定してイベント・メッセージの監視を指示するアプリケーションを送信するように構成されている。
【００１６】
本願の請求項９に記載の技術によれば、請求項１乃至８のいずれかに記載の送信装置の前記アプリケーション送信部及び前記制御情報送信部は、所定のトランスポート方式により前記アプリケーション及び前記制御情報をそれぞれ送信するように構成されている。
【００１７】
また、本願の請求項１０に記載の技術は、
放送番組向けのアプリケーションを送信するアプリケーション送信ステップと、
アプリケーションに関わる制御情報を送信する制御情報送信ステップと、
を有し、
前記制御情報送信ステップでは、アプリケーションに対するイベント・メッセージを送信するとともに、アプリケーションに対応したイベント・メッセージ・グループ識別情報を指定するイベント・メッセージ・グループ記述子を配置したシグナリング・テーブルを送信する、
送信方法である。
【００１８】
また、本願の請求項１１に記載の技術は、
放送番組向けのアプリケーションを受信するアプリケーション受信部と、
アプリケーションに関わる制御情報を受信する制御情報受信部と、
受信した制御情報に基づいてアプリケーションの実行を制御するアプリケーション制御部と、
を具備し、
前記制御情報受信部は、アプリケーションに対するイベント・メッセージを送信するとともに、アプリケーションに対応したイベント・メッセージ・グループ識別情報を指定するイベント・メッセージ・グループ記述子を配置したシグナリング・テーブルを受信する、
受信装置である。
【００１９】
本願の請求項１２に記載の技術によれば、請求項１１に記載の受信装置の前記制御情報受信部は、各アプリケーションの処理方法並びにロケーション情報を指定するるすとともに、前記イベント・メッセージ・グループ記述子を配置したアプリケーション情報テーブルを受信するように構成されている。
【００２０】
本願の請求項１３に記載の技術によれば、請求項１１に記載の受信装置の前記制御情報受信部は、対応するアプリケーションを限定するイベント・メッセージ・グループ識別情報を記述したイベント・メッセージを受信し、前記アプリケーション制御部は、イベント・メッセージ・グループ記述子でイベント・メッセージ・グループ識別情報が指定されたアプリケーションに限定して、受信したイベント・メッセージの処理を行なうように構成されている。
【００２１】
本願の請求項１４に記載の技術によれば、請求項１１乃至１３のいずれかに記載の受信装置の前記アプリケーション受信部は、複数のアプリケーション伝送路でアプリケーションを受信し、前記制御情報受信部は、アプリケーション伝送路毎に対応したイベント・メッセージ伝送路で各アプリケーションに向けたイベント・メッセージを受信するように構成されている。
【００２２】
本願の請求項１５に記載の技術によれば、請求項１４に記載の受信装置の前記制御情報受信部は、伝送路毎のイベント・メッセージを識別するイベント・メッセージ識別タグとイベント・メッセージのロケーション情報の指定を含むアプリケーション・サービス記述子をさらに受信するように構成されている。
【００２３】
本願の請求項１６に記載の技術によれば、請求項１５に記載の受信装置の前記アプリケーション制御部は、前記アプリケーション受信部が受信したアプリケーションが指定するイベント・メッセージ識別タグに対して前記アプリケーション・サービス記述子が指定するロケーション情報に基づいてイベント・メッセージを監視するように構成されている。
【００２４】
本願の請求項１７に記載の技術によれば、請求項１６に記載の受信装置の前記アプリケーション制御部は、受信したイベント・メッセージが指定するイベント・メッセージ・グループ識別情報が前記イベント・メッセージ・グループ記述子で現在実行中のアプリケーションに指定されているか否かに応じて、イベントの発火を制御するように構成されている。
【００２５】
本願の請求項１８に記載の技術によれば、請求項１１乃至１７のいずれかに記載の受信装置の前記アプリケーション受信部及び前記制御情報受信部は、所定のトランスポート方式により前記アプリケーション及び前記制御情報をそれぞれ受信するように構成されている。
【００２６】
また、本願の請求項１９に記載の技術は、
放送番組向けのアプリケーションを受信するアプリケーション受信ステップと、
アプリケーションに関わる制御情報を受信する制御情報受信ステップと、
受信した制御情報に基づいてアプリケーションの実行を制御するアプリケーション制御ステップと、
を有し、
前記制御情報受信ステップでは、アプリケーションに対するイベント・メッセージを送信するとともに、アプリケーションに対応したイベント・メッセージ・グループ識別情報を指定するイベント・メッセージ・グループ記述子を配置したシグナリング・テーブルを受信する、
受信装置である。
【発明の効果】
【００２７】
本明細書で開示する技術によれば、所定のトランスポート方式によりデータ放送アプリケーション及びその制御情報を好適に送信することができる、優れた送信装置及び送信方法を提供することができる。
【００２８】
また、本明細書で開示する技術によれば、所定のトランスポート方式により伝送されるデータ放送アプリケーション及びその制御情報を好適に受信し、制御情報に基づいてデータ放送アプリケーションを実行することができる、優れた受信装置及び受信方法を提供することができる。
【００２９】
なお、本明細書に記載された効果は、あくまでも例示であり、本発明の効果はこれに限定されるものではない。また、本発明が、上記の効果以外に、さらに付加的な効果を奏する場合もある。
【００３０】
本明細書で開示する技術のさらに他の目的、特徴や利点は、後述する実施形態や添付する図面に基づくより詳細な説明によって明らかになるであろう。
【図面の簡単な説明】
【００３１】
【図１】図１は、本明細書で開示する技術を適用したディジタル放送システム１０の構成例を模式的に示した図である。
【図２】図２は、ＭＭＴ方式を用いるディジタル放送システム１０におけるプロトコル・スタック２００を示した図である。
【図３】図３は、図２に示した放送信号を送出する放送送出システム１１の構成例を示した図である。
【図４】図４は、図２に示した放送信号を受信する受信機１２の構成例を示した図である。
【図５】図５は、ＭＭＴ／ＴＬＶ方式に従って放送送出システム１１から放送伝送路に送出される放送信号５００のイメージを示した図である。
【図６】図６は、ＰＡメッセージ内のＭＰテーブルからパッケージの各アセットを指定する仕組みを示した図である。
【図７】図７は、ＭＭＴ伝送されるデータ放送アプリケーションを構成するファイルを取得する仕組みを説明するための図である。
【図８】図８は、ＥＭＴのシンタックス８００を示した図である。
【図９】図９は、イベント・メッセージ記述子のシンタックス９００を示した図である。
【図１０】図１０は、ｅｖｅｎｔ＿ｍｓｇ＿ｇｒｏｕｏｐ＿ｉｄとして０ｘ０００と０ｘ００１をイベント・メッセージのフィルター条件とする場合の問題点を説明するための図である。
【図１１】図１１は、ｅｖｅｎｔ＿ｍｓｇ＿ｇｒｏｕｏｐ＿ｉｄとして０ｘ０００と０ｘ００１をイベント・メッセージのフィルター条件とする場合の問題点を説明するための図である。
【図１２】図１２は、ＰＡメッセージ１２０１とＰＡメッセージに含まれるＭＰテーブル１２０２のシンタックス例を示した図である。
【図１３】図１３は、ＰＡメッセージのシンタックス例１３００を示した図である。
【図１４】図１４は、ＭＰテーブルのシンタックス例１４００を示した図である。
【図１５】図１５は、アプリケーション・サービス記述子のシンタックス例１５００を示した図である。
【図１６】図１６は、ＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏ（一般ロケーション情報）のシンタックス例１６００を示した図である。
【図１７】図１７は、ＭＨ−ＡＩＴのシンタックス例１７００を示した図である。
【図１８】図１８は、イベント・メッセージ・グループ記述子のシンタックス例１８００を示した図である。
【図１９】図１９は、アプリケーションにおけるイベント・メッセージの監視を指定するＡＰＩを示した図である。
【図２０】図２０は、アプリケーションにおけるイベント・メッセージの監視を指定するＡＰＩを示した図である。
【図２１】図２１は、アプリケーションにおけるイベント・メッセージの監視を指定するＡＰＩを示した図である。
【図２２】図２２は、アプリケーションとイベント・メッセージの関係を示した図である。
【図２３】図２３は、受信機が図２２に示したような放送信号を受信したときの動作手順を示したフローチャートである。
【発明を実施するための形態】
【００３２】
以下、図面を参照しながら本明細書で開示する技術の実施形態について詳細に説明する。
【００３３】
Ａ．システム構成
図１には、本明細書で開示する技術を適用したディジタル放送システム１０の構成例を模式的に示している。図示のディジタル放送システム１０は、放送送出システム１１と、受信機１２で構成される。
【００３４】
放送送出システム１１は、放送信号の伝送にＭＭＴ方式を適用しており、放送サービスを構成する各コンポーネントをＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）パケットにして伝送する。具体的には、放送番組の映像信号や音声信号の符号、並びに、放送番組に関連するコンテンツ（データ放送アプリケーションなど）や字幕の信号は、ＭＭＴＰペイロードに乗せてＭＭＴＰパケット化され、ＩＰパケットで伝送される。また、これらのＩＰパケットは、放送伝送路ではＴＬＶ（Ｔｙｐｅ  Ｌｅｎｇｔｈ  Ｖａｌｕｅ）パケットの形式で伝送される。ここで、映像や音声、字幕などの放送番組本体に関わるコンポーネントは、タイムド・メディアである。また、コンテンツ、すなわちＨＴＭＬ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）形式などで符号化されるデータ放送アプリケーションは、ノンタイムド・メディアである。
【００３５】
一方、受信機１２は、放送送出システム１１から放送伝送路で送られてくるＴＬＶパケットを受信する。受信機１２は、そして、受信機１２は、受信パケットから映像や音声、字幕などの伝送メディアを復号して、画像や音声を提示する。また、受信機１２は、受信パケットからデータ放送用の各データ・ファイルを取得すると、ＨＴＭＬブラウザーなどのアプリケーション・エンジンを起動して、放送番組に連動したデータ放送の提示を行なう。
【００３６】
図２には、ＭＭＴ方式を用いるディジタル放送システム１０におけるプロトコル・スタック２００を示している。
【００３７】
１つの放送サービスは、映像２０１、音声２０２、字幕２０３、アプリケーション２０４、コンテンツ・ダウンロード２０５の各コンポーネントで構成される。映像２０１はＨＥＶＣ（Ｈｉｇｈ  Ｅｆｆｉｃｉｅｎｃｙ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ）形式で符号化２１１され、音声２０２はＡＡＣ（Ａｄｖａｎｃｅｄ  Ａｕｄｉｏ  Ｃｏｄｉｎｇ）形式で符号化２１２され、字幕２０３は字幕符号化２１３される。また、アプリケーション２０４は、ＥＰＧ（Ｅｌｅｃｔｒｉｃ  Ｐｒｏｇｒａｍ  Ｇｕｉｄｅ）を含むが、例えばＨＴＭＬ５形式で符号化２１４される。
【００３８】
ＭＭＴレイヤー２２０上では、これらタイムド・メディア及びノンタイムド・メディアの符号化コンポーネント２１１〜２１４は、ＭＰＵフォーマットにして、ＭＭＴＰペイロードに乗せてＭＭＴＰパケット化される。また、メディア・トランスポート方式であるＭＭＴに関わる（放送番組の構成などを示す）制御情報であるＭＭＴ−ＳＩ（Ｓｉｇｎａｌｉｎｇ  Ｉｎｆｏｒｍａｔｉｏｎ）２２１も、ＭＭＴＰペイロードに乗せてＭＭＴＰパケット化される。ＭＭＴに関わる制御情報ＭＭＴ−ＳＩの詳細については、後述に譲る。なお、コンテンツ・ダウンロード２０５のデータ伝送方式２１５として、字幕・文字スーパー伝送方式、アプリケーション伝送方式、イベント・メッセージ伝送方式、汎用データ伝送方式の４種類が挙げられるが、詳細な説明は省略する。
【００３９】
ＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）／ＩＰレイヤー２３０では、ＭＭＴＰパケットはＩＰパケット化される。また、タイムド・メディアのための現在時刻の情報を含むＮＴＰ（Ｎｅｔｗｏｒｋ  Ｔｉｍｅ  Ｐｒｏｔｏｃｏｌ）パケット２０６も、ＩＰパケット化される。さらに、これらのＩＰパケットは、ＴＬＶレイヤー２４０でＴＬＶパケット化され、最下層の物理レイヤーである放送伝送路２５０で伝送される。また、ＩＰパケットの多重のためのＴＬＶ多重化形式に関わるＴＬＶ−ＳＩ２４１も、ＴＬＶパケット化され、放送伝送路２５０で伝送される。ＴＬＶパケットを多重した伝送スロットは、伝送路のＴＭＣＣ（Ｔｒａｎｓｍｉｓｓｉｏｎ  ａｎｄ  Ｍｕｌｔｉｐｌｅｘｉｎｇ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｃｏｎｔｒｏｌ）信号２５１から、ＴＬＶストリーム識別情報（ＴＬＶ＿ｓｔｒｅａｍ＿ｉｄ）を用いて特定される。
【００４０】
図３には、図２に示した放送信号を送出する放送送出システム１１の構成例を示している。放送送出システム１１は、例えば放送番組本体の制作元であるキー局（番組制作局）に相当する。図示の放送送出システム１１は、時計部３０１と、信号送出部３０２と、ビデオ・エンコーダー３０３と、オーディオ・エンコーダー３０４と、キャプション・エンコーダー３０５と、シグナリング・エンコーダー３０６と、ファイル・エンコーダー３０７と、電子データ処理システム（Ｅｌｅｃｔｒｏｎｉｃ  Ｄａｔａ  Ｐｒｏｃｅｓｓｉｎｇ  Ｓｙｓｔｅｍ：ＥＤＰＳ）３０８と、ＴＬＶシグナリング・エンコーダー３０９と、ＩＰサービス・マルチプレクサー（ＭＵＸ）３１０と、ＴＬＶマルチプレクサー（ＭＵＸ）３１１と、変調・送信部３１２を備えている。
【００４１】
時計部３０１は、ＮＴＰサーバー（図示しない）から取得した時刻情報に同期した時刻情報を生成し、この時刻情報を含むＩＰパケットをＩＰサービス・マルチプレクサー３１０に送る。
【００４２】
信号送出部３０２は、例えばＴＶ放送局のスタジオやＶＴＲなどの記録再生機であり、タイムド・メディアである映像、音声、字幕などのストリーム・データや、ノンタイムド・メディアであるデータ放送アプリケーション用のデータ・ファイル（ＨＴＭＬ文書データなど）をそれぞれ、ビデオ・エンコーダー３０３、オーディオ・エンコーダー３０４、キャプション・エンコーダー３０５、ファイル・エンコーダー３０７に送る。
【００４３】
電子データ処理システム３０８は、ＴＶ放送局のスケジューラー並びにファイルの供給源であり、ノンタイムド・メディアであるデータ放送アプリケーションと、放送番組の構成などを示す制御情報と、ＩＰパケットの多重に関する制御情報をそれぞれ、ファイル・エンコーダー３０７、シグナリング・エンコーダー３０６、ＴＬＶシグナリング・エンコーダー３０９に送る。
【００４４】
ビデオ・エンコーダー３０３は、信号送出部３０２から送出される映像信号をＨＥＶＣ符号化し、さらにパケット化して、映像信号のＭＭＴパケットを含むＩＰパケットをＩＰサービス・マルチプレクサー３１０に送る。また、オーディオ・エンコーダー３０４は、信号送出部３０２から送出される音声信号をＡＡＣ符号化し、さらにパケット化して、音声信号のＭＭＴパケットを含むＩＰパケットをＩＰサービス・マルチプレクサー３１０に送る。また、キャプション・エンコーダー３０５は、信号送出部３０２から送出される字幕信号を字幕符号化し、さらにパケット化して、字幕のＭＭＴパケットを含むＩＰパケットをＩＰサービス・マルチプレクサー３１０に送る。
【００４５】
シグナリング・エンコーダー３０６は、電子データ処理システム３０８から送出される情報に基づいて、放送番組の構成などを示す制御情報を記述したシグナリング情報（ＭＭＴ−ＳＩ）を生成し、ペイロード部にこのシグナリング情報が配置されたＭＭＴパケットを含むＩＰパケットをＩＰサービス・マルチプレクサー３１０に送る。本実施形態では、シグナリング情報を乗せたシグナリング・メッセージは、ＰＡ（Ｐａｃｋａｇｅ  Ａｃｃｅｓｓ）メッセージ、Ｍ２セクション・メッセージ、データ伝送メッセージの３種類に大別される。シグナリング・メッセージの詳細については、後述に譲る。
【００４６】
ファイル・エンコーダー３０７は、信号送出部３０２又は電子データ処理システム３０８から送出されるデータ放送アプリケーションをＨＴＭＬ５形式のデータ・ファイルに符号化し、さらにパケット化して、このＭＭＴパケットを含むＩＰパケットをＩＰサービス・マルチプレクサー３１０に送る。
【００４７】
放送送出システム１１は、送出するチャンネル（放送番組）毎に、複数のＩＰサービス・マルチプレクサー３１０―１、…、３１０−Ｎを装備する。１つのチャンネルのＩＰサービス・マルチプレクサー３１０は、各エンコーダー３０３〜３０７から送られてくる映像、音声、字幕、シグナリング情報（ＭＭＴ−ＳＩ）、及びデータ放送アプリケーションの各々を含むＩＰパケットをマルチプレクスして、１つの放送サービス（番組）を構成するＴＬＶパケットを生成する。
【００４８】
ＴＬＶシグナリング・エンコーダー３０９は、電子データ処理システムＳ３０８から送出される情報に基づいて、上記のＩＰパケットの多重に関する制御情報（ＴＬＶ−ＳＩ）をペイロード部に配置するＴＬＶパケットを生成する。
【００４９】
ＴＬＶマルチプレクサー３１１は、各ＩＰサービス・マルチプレクサー３１０−１〜３１０−Ｎ及びＴＬＶシグナリング・エンコーダー３０９で生成されるＴＬＶパケットをマルチプレクスして、ＴＬＶストリーム識別情報で識別されるＴＬＶストリームを生成する。
【００５０】
変調・送信部３１２は、ＴＬＶマルチプレクサー３１１で生成されたＴＬＶストリームに対してＲＦ変調処理を行なって、放送伝送路に送出する。
【００５１】
図３に示した放送送出システム１１の動作について説明しておく。
【００５２】
時計部３０１では、ＮＴＰサーバー（図示しない）から取得した時刻情報に同期した時刻情報が生成され、この時刻情報を含むＩＰパケットが生成される。
【００５３】
信号送出部３０２から送出される映像信号は、ビデオ・エンコーダー３０３に供給される。ビデオ・エンコーダー３０３では、映像信号がＨＥＶＣ符号化され、さらにパケット化されて、ＨＥＶＣ符号化映像信号のＭＭＴパケットを含むＩＰパケットが生成される。このＩＰパケットは、ＩＰサービス・マルチプレクサー３１０に送られる。
【００５４】
また、信号送出部３０２から送出される音声信号並びに字幕信号に対しても、同様の処理が行なわれる。すなわち、オーディオ・エンコーダー３０４で生成されるＡＡＣ符号化音声信号のＭＭＴパケットを含むＩＰパケットがＩＰサービス・マルチプレクサー３１０に送られるとともに、キャプション・エンコーダー３０５で生成される字幕符号化信号のＭＭＴパケットを含むＩＰパケットがＩＰサービス・マルチプレクサー３１０に送られる。
【００５５】
また、シグナリング・エンコーダー３０６では、電子データ処理システム３０８から送出される情報に基づいて放送番組の構成などを示す制御情報を記述したシグナリング・メッセージ（ＭＭＴ−ＳＩ）が生成され、ペイロード部にこのシグナリング・メッセージが配置されたＭＭＴパケットを含むＩＰパケットが生成される。このＩＰパケットは、ＩＰサービス・マルチプレクサー３１０に送られる。
【００５６】
また、信号送出部３０２又は電子データ処理システム３０８から送出されるデータ放送アプリケーションは、ファイル・エンコーダー３０７に供給される。ファイル・エンコーダー３０７では、データ放送アプリケーションが例えばＨＴＭＬ５形式に符号化され、さらにパケット化され、このＭＭＴパケットを含むＩＰパケットが生成される。このＩＰパケットは、ＩＰサービス・マルチプレクサー３１０に送られる。
【００５７】
各ＩＰサービス・マルチプレクサー３１０では、各エンコーダー３０３〜３０７から送られてくる映像、音声、字幕、シグナリング情報（ＭＭＴ−ＳＩ）、及びデータ放送アプリケーション（ＨＴＭＬ５文書）の各々を含むＩＰパケットがマルチプレクスされて、１つのチャンネルを構成するＴＬＶパケットが生成される。
【００５８】
ＴＬＶシグナリング・エンコーダー３０９では、電子データ処理システム３０８から送出される情報に基づいて、上記のＩＰパケットの多重に関する制御情報（ＴＬＶ−ＳＩ）をペイロード部に配置するＴＬＶパケットが生成される。
【００５９】
ＴＬＶマルチプレクサー３１１では、各ＩＰサービス・マルチプレクサー３１０−１〜３１０−Ｎ及びＴＬＶシグナリング・エンコーダー３０９で生成されるＴＬＶパケットがマルチプレクスされて、ＴＬＶストリームが生成される。変調・送信部３１２では、ＴＬＶマルチプレクサー３１１で生成されたＴＬＶストリームに対してＲＦ変調処理が行なわれ、そのＲＦ変調信号が放送伝送路に送出される。
【００６０】
図４には、図２に示した放送信号を受信する受信機１２の構成例を示している。図示の受信機１２は、チューナー・復調部４０１と、デマルチプレクサー（ＤＥＭＵＸ）４０２と、時計回復部４０３と、ビデオ・デコーダー４０４と、オーディオ・デコーダー４０５と、キャプション・デコーダー４０６と、システム制御部４０７と、アプリケーション（Ａｐｐ）制御部４０８と、アプリケーション・エンジン４０９と、ＩＰインターフェース（Ｉ／Ｆ］）４１０と、合成部４１１を備えている。図示の受信機１２は、例えば家庭内に設置されるテレビ受信機やセット・トップ・ボックスの他、ＩＰＴＶやＣＡＴＶの再送信機を含むものとする。
【００６１】
チューナー・復調部４０１は、放送信号を選局受信し、復調処理を行なって、ＴＬＶストリームを得る。デマルチプレクサー４０２は、このＴＬＶストリームに対して、デマルチプレクス処理及びデパケット化処理を行なう。本実施形態では、デマルチプレクサー４０２は、ＴＬＶフィルター４０２−１と、ＩＰフィルター４０２−２と、ＵＤＰフィルター４０２−３と、ＭＭＴフィルター４０２−４と、ＳＩフィルター４０２−５を備えている。
【００６２】
ＴＬＶフィルター４０２−１は、ＴＬＶストリーム識別情報に基づいて、放送伝送されるＴＬＶパケットをフィルタリングする。ＩＰフィルター４０２−２は、ＩＰアドレスに基づいて、ＴＬＶパケットからＩＰパケットをフィルタリングするとともに、ＩＰインターフェース４１０経由で受信したＩＰパケットのフィルタリングも行なう。また、ＵＤＰフィルター４０２−３は、ＵＤＰパケットをフィルタリングする。ＭＭＴフィルター４０２−４は、ＭＭＴＰヘッダー内の情報に基づいて、ＩＰパケットからＭＭＴＰパケットをフィルタリングして、映像、音声、字幕、並びにデー放送アプリケーションの各符号化コンポーネントを乗せたＭＭＴＰパケットを、それぞれビデオ・デコーダー４０４、オーディオ・デコーダー４０５、キャプション・デコーダー４０６、アプリケーション（Ａｐｐ）・エンジン４０９に振り分ける。ＳＩフィルター４０２−５は、シグナリング情報ＳＩをフィルタリングして、システム制御部４０７及びアプリケーション制御部４０８にそれぞれ振り分ける。ＳＩフィルター４０２−５は、ＭＭＴストリームからＭＭＴ−ＳＩをフィルタリングするＭＭＴ−ＳＩフィルターと、ＴＬＶストリームからＴＬＶ−ＳＩをフィルタリングするＴＬＶ−ＳＩフィルターを含むものとする。
【００６３】
時計回復部４０３は、デマルチプレクサー４０２内のＩＰフィルター４０２−２並びにＵＤＰフィルター４０２−３でフィルタリングされたＮＴＰパケットに含まれる現在時刻の情報に基づいて、この時刻情報に同期した時刻情報を生成して、各タイムド・メディアをデコードするにビデオ・デコーダー４０４、オーディオ・デコーダー４０５、キャプション・デコーダー４０６にそれぞれ出力する。
【００６４】
ビデオ・デコーダー４０４は、デマルチプレクサー４０２で得られる符号化映像信号をデコードして、ベースバンドの映像信号を得る。また、オーディオ・デコーダー４０５は、デマルチプレクサー４０２で得られる符号化音声信号をデコードして、ベースバンドの音声信号を得る。また、キャプション・デコーダー４０６は、デマルチプレクサー４０２で得られる字幕符号化信号をデコードして、字幕の表示信号を得る。
【００６５】
アプリケーション制御部４０８は、ＳＩフィルター４０２−５を介して受け取るシグナリング情報に基づいて、データ放送アプリケーションの処理を制御する。例えば、アプリケーション制御部４０７は、ＭＭＴ−ＳＩを解析して、デフォルト・エントリーに設定されているデータ放送アプリケーションを見つけると、アプリケーション・エンジン４０９に対してデータ放送の提示処理を指示する。
【００６６】
本実施形態に係る放送システム１０では、放送信号並びにＩＰネットワークという２種類のデリバリー・パスを通じてデータ放送アプリケーションが伝送されることを想定している。前者の系統ではチューナー・復調部４０１で受信し、後者の系統ではＩＰインターフェース４１０で受信し、いずれもデマルチプレクサー４０２内でパケット化されたＭＭＴパケットがＭＭＴフィルター４０２−４によってアプリケーション・エンジン４０９に振り分けられる。
【００６７】
アプリケーション・エンジン４０９は、例えばＨＴＭＬブラウザーなどであり、データ放送アプリケーションのエンティティーであるデータ・ファイル（ＨＴＭＬ５文書など）の処理を行なって、データ放送の表示信号を生成する。また、アプリケーション・エンジン４０９は、データ放送の表示に必要なデータ・ファイル（データ放送の表示に使用するモノメディアや、リンク先のアプリケーションなど）をＩＰインターフェース４１０経由でＩＰネットワークから取得することもできる。
【００６８】
システム制御部４０７は、ＳＩフィルター４０２−５を介して受け取るシグナリング情報や、ユーザー操作部（図示しない）を介したユーザーからの操作情報などに基づいて、当該受信機１２の各部の動作を制御する。また、システム制御部４０７は、各デコーダー４０４〜４０６におけるデコード・タイミングをシグナリング情報に基づいて制御し、映像、音声、及び字幕の提示タイミングを調整する。
【００６９】
合成部４１１は、ベースバンドの映像信号に、字幕の表示信号及びデータ放送の表示信号を合成して、映像表示用の映像信号を得る。また、オーディオ・デコーダー４０５で得られるベースバンドの音声信号は、音声出力用の音声信号となる。映像信号及び音声信号からなる放送番組本編は、図示しないモニター・ディスプレイから映像及び音声出力される。また、データ放送アプリケーション・エンジン４０９が処理したデータ放送も、モニター・ディスプレイ上で放送番組本編の画面に重畳して表示される。
【００７０】
ＩＰインターフェース４１０は、例えばネットワーク・インターフェース・カードで構成され、インターネットやホーム・ネットワークなどのＩＰネットワークに接続して、ＩＰパケットの送受信処理を行なう。なお、ＩＰフィルター４０２−２でＩＰアドレスに基づいてフィルタリングしたＩＰパケットを、ＩＰインターフェース４１０からＩＰネットワークへ送信若しくは再送信することも想定される。
【００７１】
図４に示した受信機１２の動作について説明しておく。
【００７２】
チューナー・復調部４０１では、放送信号が受信され、復調処理が行なわれて、ＴＬＶストリームが得られる。デマルチプレクサー４０２では、このＴＬＶストリームに対して、デマルチプレクス処理及びでパケット化処理を行なわれ、ＮＴＰ時刻情報、映像、音声、字幕、データ放送の各符号化信号、並びに、シグナリング情報が抽出され、ビデオ・デコーダー４０４、オーディオ・デコーダー４０５、キャプション・デコーダー４０６、アプリケーション・エンジン４０９、システム制御部４０７、アプリケーション制御部４０８にそれぞれ振り分けられる。また、ＩＰインターフェース４１０で受信したＩＰパケットについても同様に、デマルチプレクス処理及びでパケット化処理が行なわれ、各部に振り分けられる。
【００７３】
また、デマルチプレクサー４０２で抽出されたＮＴＰパケットは、時計回復部４０３に振り分けられる。時計回復部４０３では、ＮＴＰパケットに載せられた時刻情報に基づいて、この時刻情報に同期した時刻情報が生成される。つまり、時計回復部４０３では、放送送出システム１１側の時計部３０１で生成された時刻情報に合った時刻情報が生成される。
【００７４】
デマルチプレクサー４０２で抽出された符号化映像信号は、ビデオ・デコーダー４０４に送られてデコードされ、ベースバンドの映像信号が得られる。また、デマルチプレクサー４０２で抽出された字幕符号化信号はキャプション・デコーダー４０６に送られてデコードされ、字幕の表示信号が得られる。
【００７５】
アプリケーション制御部４０８では、ＳＩフィルター４０２−５を介して受け取るシグナリング情報に基づいて、データ放送アプリケーションの処理が制御される。ＨＴＭＬブラウザーなどからなるアプリケーション・エンジン４０９では、アプリケーション制御部４０８からの指示に従って、デマルチプレクサー４０２で抽出されたデータ放送アプリケーションの符号化信号（ＨＴＭＬ５文書）の処理が行なわれ、データ放送の表示信号が得られる。
【００７６】
合成部４１１では、ベースバンドの映像信号に、字幕の表示信号及びデータ放送の表示信号が合成され、画面表示用の映像信号が得られる。また、デマルチプレクサー４０２で抽出された符号化音声信号はオーディオ・デコーダー４０５に送られてデコードされ、音声出力用のベースバンドの音声信号が得られる。そして、映像信号及び音声信号は、図示しないモニター・ディスプレイから映像及び音声出力される。
【００７７】
Ｂ．ＭＭＴを用いる放送信号
図１に示したディジタル放送システム１０では、放送送出システム１１から受信機１２へ、ＭＭＴ方式により放送信号を伝送することを想定している。図５には、ＭＭＴ方式に従って放送送出システム１１から放送伝送路に送出される放送信号５００のイメージを示している。
【００７８】
１つのサービス（チャンネル：放送番組）の放送信号は、映像、音声、字幕などの放送番組本編に関わるタイムド・メディアと、放送番組に連動するデータ放送アプリケーションのようなノンタイムド・メディアで構成される。これらを符号化したメディア・データは、ＭＰＵフォーマットにしてＭＭＴＰパケット化され、ＩＰパケットで伝送される。また、メディア・トランスポート方式であるＭＭＴに関わる（放送番組の構成などを示す）シグナリング情報（ＭＭＴ−ＳＩ）も、ＩＰパケットで伝送される。これらのＩＰパケットは、放送伝送路ではＴＬＶパケットの形式でＴＬＶストリームとして伝送される。ＩＰパケットの多重のためのＴＬＶ多重化形式に関わるシグナリング情報（ＴＬＶ−ＳＩ）も、ＴＬＶパケットの形式で伝送される。
【００７９】
ＭＭＴ方式では、１つのチャンネル（放送番組）を構成するタイムド・メディア及びノンタイムド・メディアのデータを異なる伝送路の組み合わせで利用することが容易である。図５に示す例では、放送信号５００として、映像、音声、字幕、ファイル・データ、シグナリング情報など、データのタイプ毎のＭＭＴ伝送路５０１〜５０４が利用されている。なお、図中、字幕データ用の伝送路は便宜上、図示を省略している。各ＭＭＴ伝送路は、それぞれ１つのＩＰデータ・フローに相当する。ここで言うＩＰデータ・フローとは、ＩＰヘッダー及びＵＤＰヘッダーの送信元ＩＰアドレス、宛先ＩＰアドレス、ＩＰヘッダーのプロトコル種別、送信元ポート番号、宛先ポート番号の５種類のフィールドの値がすべて同じとなるＩＰパケットの集合である。
【００８０】
１つの放送サービス（若しくは放送番組）は、映像、音声、字幕、データ放送アプリケーションなどタイプの異なる複数のアセットで構成される「パッケージ」と言うことができる。ここで言う「パッケージ」は、ＭＭＴ伝送路を使って伝送されるメディア・データの論理集合である。また、ここで言う「アセット」は、固有のアセット識別情報（ａｓｓｅｔ＿ｉｄ）に関連付けられる、マルチメディアのプレゼンテーションを構成するために使用されるデータのエンティティーである。なお、アセットはコンポーネントと対応関係がある（映像のアセットは映像コンポーネントに対応し、音声のアセットは音声コンポーネントに対応し、データ放送アプリケーション用のデータ・ファイルのアセットはデータ・ファイルのコンポーネントに対応する）。
【００８１】
各アセットは、同じアセット識別情報を共有する１又はそれ以上のＭＰＵの集合（論理グループ）で構成される。ＭＰＵは、ＭＭＴ方式における伝送単位となるフォーマットである。各ＭＰＵは、それぞれのアセットに専用のＥＳ（Ｅｌｅｍｅｎｔａｒｙ  Ｓｔｒｅａｍ）すなわちＭＭＴ伝送路５０１〜５０３上で伝送される。すなわち、伝送路５０１では、映像信号用として共通のアセット識別情報を持つＭＰＵ論理グループからなる符号化映像信号のＭＭＴＰパケットが伝送される。同様に、伝送路５０２では音声信号用として共通のアセット識別情報を持つＭＰＵ論理グループからなる符号化音声信号のＭＭＴパケットが伝送され、伝送路５０３ではデータ放送アプリケーション用として共通のアセット識別情報を持つＭＰＵ論理グループからなる符号化アプリケーションのＭＭＴパケットが伝送される。各ＭＰＵは、アセット識別情報と、該当する伝送路上でのＭＰＵのシーケンス番号で特定される。また、各メディアを伝送するＭＭＴ伝送路は、アセット識別情報で識別することができる。
【００８２】
１つのパッケージ（放送番組）内で、タイプが同じ（すなわち、アセット識別情報が異なる）アセットが複数伝送されることもある。例えば、同じ放送番組に対して、２以上のデリバリー・セグメントからそれぞれ独立してデータ放送アプリケーションが提供される場合であり、デリバリー・セグメント毎に異なるアセット識別情報が割り振られて伝送される。より具体的に言えば、番組を制作したキー局から提供される放送番組に連動する番組連動型データ放送アプリケーションと、番組を配信する地方局から提供される放送番組に連動しない番組非連動型データ放送アプリケーション（例えば、天気予報やニュースなど）は、通常、別のアセットとして別々のアセット識別情報が割り振られ、別々のＭＰＵ論理グループとして異なるＭＭＴ伝送路で伝送される。図５に示す例では、異なるアセット識別情報が割り振れられた２つのデータ放送アプリケーション用の伝送路５０３−１、５０３−２が描かれている。
【００８３】
また、ＭＭＴ方式は、放送や通信の複数の伝送路に共通に用いることができる。例えば、データ放送用アプリケーション（ＨＴＭＬ５文書など）のようなノンタイムド・メディアは、図５に示したように放送信号の伝送路５０３を用いてタイムド・メディアとともに伝送される以外に、ＩＰネットワークなど通信伝送路（図示しない）を介して提供することもできる。
【００８４】
伝送路５０４では、ＭＭＴのパッケージの構成や放送サービスに関連する情報を示す伝送制御信号であるＭＭＴ−ＳＩを含んだＭＭＴＰパケットが、カルーセル方式により繰り返し伝送される。なお、図５では、ＴＬＶ−ＳＩ用の伝送路の図示を省略している。
【００８５】
伝送路５０４で伝送されるＭＭＴ−ＳＩのシグナリング・メッセージとして、ＰＡメッセージ５１０、Ｍ２セクション・メッセージ５２０、データ伝送メッセージ５３０を挙げることができる。
【００８６】
例えば、ＰＡメッセージ５１０は、放送番組の構成などを示す制御情報であり、アセットのリストやその位置などパッケージを構成する情報を記述するＭＰ（ＭＭＴ  Ｐａｃｋａｇｅ）テーブル５１１が含まれている。
【００８７】
ＭＰテーブル５１１は、アセットのリストや、アセットのロケーション情報など、パッケージを構成する情報を与える。また、本実施形態では、ＭＰテーブル５１１は、ＭＰＴ記述子としてアプリケーション・サービス記述子を含むものとする。アプリケーション・サービス記述子は、データ放送アプリケーションの運用に必要又は重要な制御情報のロケーション情報（例えば、データ伝送メッセージ、ＭＨ−ＡＩＴ及びＥＭＴをそれぞれ伝送する各Ｍ２セクション・メッセージのロケーション情報）を示すものとする。
【００８８】
ＰＡメッセージ５１０は、放送サービスのエントリー・ポイントであり、ＰＡメッセージ５１０を伝送するＭＭＴＰパケットには、固定のパケット識別情報（例えば、０ｘ００００）が割り当てられている。したがって、受信機側では、ＭＭＴ伝送路５０４上で、上記固定のパケット識別情報を指定してＰＡメッセージ５１０を取得することができる。そして、ＰＡメッセージ５１０で伝送されるＭＰテーブル５１１を参照して、パッケージ（放送番組）を構成する各アセット（映像、音声、字幕、ファイル・データ（データ放送アプリケーション）など）のロケーション情報を指定することができる。
【００８９】
また、Ｍ２セクション・メッセージ５２０は、ＭＰＥＧ−２  Ｓｙｓｔｅｍｓのセクション拡張形式を伝送するメッセージである。ＭＨ−ＡＩＴ（Ａｐｐｌｉｃａｔｉｏｎ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｔａｂｌｅ）５２１や、ＥＭＴ（Ｅｖｅｎｔ  Ｍｅｓｓａｇｅ  Ｔａｂｌｅ）５２２といったシグナリング・テーブルが、それぞれ単体でＭ２セクション・メッセージ５２０に格納される。
【００９０】
ＭＨ−ＡＩＴ５２１は、アプリケーションに関する動的制御情報及び実行に必要な付加情報を伝送するテーブルであり、具体的には、ＭＭＴ伝送路で送られてくる各データ放送アプリケーション（ファイル・データ）の処理方法（アプリケーションに適用される起動状態など）、並びに、各データ放送アプリケーションのロケーション情報（ＵＲＬ：Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）を指定する。アプリケーションの処理方法として、アプリケーションの自動起動を示すＡＵＴＯＳＴＡＲＴ（ＡＳ）、アプリケーションが実行可能の状態であることを示すＰＲＥＳＥＮＴ（ＰＲ）、アプリケーションの終了を示すＫＩＬＬ、アプリケーションの取得及び保持（事前キャッシュ）を示すＰＲＥＦＥＴＣＨ（ＰＦ）を挙げることができる。
【００９１】
ＥＭＴ５２２は、イベント・メッセージ伝送方式に用いるシグナリング・テーブルであり、イベント・メッセージ（放送局から受信機上のアプリケーションに対する同期・非同期のメッセージ）に関する情報（イベント・メッセージ記述子）を格納する。イベント・メッセージ伝送方式は、放送局から受信機で動作しているデータ放送アプリケーションに対して、即座にあるいは指定した時刻に、メッセージ情報を送る手段を提供する。
【００９２】
また、データ伝送メッセージ５３０は、データ放送アプリケーションの伝送に関する制御情報を伝送するためのメッセージである。１つのデータ伝送メッセージ５３０内には、データ・ディレクトリー管理テーブル（Ｄａｔａ  Ｄｉｒｅｃｔｏｒｙ  ｍａｎａｇｅｍｅｎｔ  Ｔａｂｌｅ：ＤＤＭＴ）５３１、データ・アセット管理テーブル（Ｄａｔａ  Ａｓｓｅｔ  Ｍａｎａｇｅｍｅｎｔ  Ｔａｂｌｅ：ＤＡＭＴ）５３２、データ・コンテンツ管理テーブル（Ｄａｔａ  Ｃｏｎｔｅｎｔ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｔａｂｌｅ：ＤＣＣＴ）５３３の各シグナリング・テーブルが格納される。
【００９３】
データ・ディレクトリー管理テーブル５３１は、ディレクトリー単位（言い換えれば、データ放送アプリケーションの制作単位）でデータ放送アプリケーションを管理するためのテーブルである。同テーブル内は、１つのパッケージに含まれるディレクトリー並びにディレクトリーに含まれるサブディレクトリーやファイル（アイテム）に関するディレクトリー構造を記述しているので、アプリケーションのファイル構成とファイル伝送のための構成を分離することができる。同テーブルは、ディレクトリーやファイルなどの各ノードのパス名と、データ伝送メッセージ内で各ノードを識別するノード・タグとの対応関係を示している。
【００９４】
データ・アセット管理テーブル５３２は、アセット単位でデータ放送アプリケーションを管理するためのテーブルであり、アセット内のＭＰＵの構成とのＭＰＵ毎のバージョン情報を記述している。具体的には、同テーブルは、各コンポーネントのダウンロード識別情報や、コンポーネントを伝送する各ＭＰＵに含まれるノード（ファイル又はディレクトリー）をデータ伝送メッセージ内で識別するノード・タグとＭＭＴ伝送路上でノードを識別するアイテム識別情報との対応関係を示している。
【００９５】
データ・コンテンツ管理テーブル５３３は、提示単位（Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔ：ＰＵ）毎にデータ放送アプリケーションを管理するためのテーブルである。同テーブルは、データ放送アプリケーションを提示単位毎に識別する提示単位識別情報と、各提示単位に含まれるノード（ファイル又はディレクトリー）をデータ伝送メッセージ内で識別するノード・タグを示している。また、同テーブルは、提示単位にリンクする提示単位を識別するリンク先提示単位識別情報や、各提示単位のキャッシュ制御に関する情報を含めることができ、受信機側ではデータ放送アプリケーション用のファイル・データの柔軟で有効なキャッシュ制御に利用することができる。
【００９６】
ＭＭＴによるデータ放送アプリケーションの伝送方式において、データ伝送メッセージで伝送する上記３種類のシグナリング・テーブル５３１〜５３３を活用することにより、ファイル単位の伝送データ構造やコンテンツ（データ放送アプリケーション）制作におけるディレクトリー構造とは独立して、アプリケーション単位、提示単位といった利用単位のデータ構造を表現することができる。各シグナリング・テーブル５３１〜５３３の構成は、ＡＲＩＢ  ＳＴＤ  Ｂ−６０で規定されている。
【００９７】
ＭＭＴ−ＳＩとして伝送されるメッセージやテーブルのパケット識別情報は、固定されているものや、他のテーブルから間接指定されるものがある。このうち、ＰＡメッセージは、放送サービスのエントリー・ポイントであり、固定のパケット識別情報（例えば、０ｘ００００）が割り当てられている。ＰＡメッセージで伝送されるＭＰテーブルでは、パッケージ（放送番組）を構成する各アセット（映像、音声、字幕、データ放送アプリケーションなど）を指定している。したがって、受信機側では、ＭＭＴ伝送路上で、上記固定のパケット識別情報を指定してＰＡメッセージを取得することができる。そして、図６に示すように、ＰＡメッセージで伝送されるＭＰテーブルを参照して、パッケージ（放送番組）を構成する各アセット（映像、音声、字幕、ファイル・データ（データ放送アプリケーション）など）を指定することができる。
【００９８】
ＭＨ−ＡＩＴでは、データ放送アプリケーションのロケーション情報は、ＵＲＬ形式、言い換えれば、ディレクトリー・ノード名とファイル名の組み合わせからなるパス名で記述される。データ伝送メッセージで伝送されるデータ・ディレクトリー管理テーブル及びデータ・アセット管理テーブルを用いて、アセットのパス名をＭＭＴ伝送路上の識別情報（パケット識別情報）に変換することができる。ＭＭＴ伝送路からデータ放送アプリケーションを取得する仕組みについては、例えば本出願人に既に譲渡されている特願２０１４−２５０２７９号明細書に詳細に記載されている。本明細書では、図７を参照しながら、同一のＩＰデータ・フローに多重されたデータ放送アプリケーションのアイテムを取得する仕組みについて、簡単に説明しておく。
【００９９】
受信機は、Ｍ２セクション・メッセージで伝送されるＭＨ−ＡＩＴから、“ａｕｔｏｓｔａｒｔ（自動起動）”が指示されているアプリケーションのロケーション情報すなわちパス名を取得することができる。
【０１００】
参照番号７０１で示すように、データ伝送メッセージ内のデータ・ディレクトリー管理テーブルから、指定されたパス名のファイルのノード・タグを得ることができる。
【０１０１】
次いで、参照番号７０２で示すように、同じくデータ伝送メッセージ内のデータ・アセット管理テーブルから、データ・ディレクトリー管理テーブルで得られたノード・タグを持つアイテムが伝送されるアセットのコンポーネント・タグ、ダウンロード識別情報、ＭＰＵシーケンス番号、及びアイテム識別情報を得ることができる。
【０１０２】
さらに、参照番号７０３で示すように、ＭＰテーブルから、データ・アセット管理テーブルで得られたコンポーネント・タグを持つアセットのロケーション情報を取得すると、参照番号７０４で示すように、該当するファイルが実際に伝送されるデータ・アセットを特定することができる。
【０１０３】
そして、特定されたデータ・アセット内で、データ・アセット管理テーブルから得られたダウンロード識別情報とアイテムを伝送するＭＭＴＰパケットのヘッダー領域に記載されたダウンロード識別情報とにより、カルーセルに対応するファイルの繰り返し伝送の単位を一意に識別することができる。参照番号７０５で示すように、繰り返し伝送されるアイテムのうち、データ・アセット管理テーブルから得られたＭＰＵシーケンス番号及びアイテム識別情報を持つアイテムを所望のファイルとして指定することができる。
【０１０４】
Ｃ．ＭＭＴにおけるイベント・メッセージの伝送方式
データ放送アプリケーションの中には、例えば、放送番組の切り替わりや放送番組内でのシーンの切り替わりに同期して処理（アクション）を実行するサービスを提供するものがある。このため、放送局から受信機で動作しているアプリケーションに対して、即座にあるいは指定した時刻に、メッセージ情報を送る手段として、イベント・メッセージ伝送方式が重要である。以下では、ＭＭＴ放送システムにおけるイベント・メッセージ伝送方式について検討する。
【０１０５】
図５を参照しながら既に説明したように、ＭＭＴ方式のディジタル放送システムでは、イベント・メッセージ伝送方式に用いるシグナリング・テーブルであるＥＭＴは、Ｍ２セクション・メッセージに格納して伝送される。ＥＭＴには、イベント・メッセージ（放送局から受信機上のアプリケーションに対する同期・非同期のメッセージ）に関する情報（イベント・メッセージ記述子）を格納することができる。
【０１０６】
図８には、ＡＲＩＢ  ＳＴＤ  Ｂ−６０で規定されているＥＭＴのシンタックス８００を示している。ＥＭＴはセクション形式のテーブルである。以下、同テーブル内の各パラメーターについて説明する。
【０１０７】
ｔａｂｌｅ＿ｉｄは、当該テーブルがＥＭＴであることを識別する８ビットの固定値を示す。
【０１０８】
ｓｅｃｔｉｏｎ＿ｓｙｎｔａｘ＿ｉｎｄｉｃａｔｏｒは、セクションの末尾にＣＲＣ（Ｃｙｃｌｉｃ  Ｒｅｄｕｎｄａｎｃｙ  Ｃｈｅｃｋ）３２が存在するか否かを１ビットで示す。イベント・メッセージの伝送においては、このインジケータを常に１とし、セクションの末尾にＣＲＣ３２が存在する。
【０１０９】
ｓｅｃｔｉｏｎ＿ｌｅｎｇｔｈは、このフィールドの直後からセクションの末尾までのバイト長を示す１２ビットのフィールドである。
【０１１０】
参照番号８０１で示す、ｄａｔａ＿ｅｖｅｎｔ＿ｉｄは、イベント・メッセージを利用する時間的に相隣り合うデータ・イベントを区別し、それらのデータ・イベントで配信されるローカル・コンテンツ間でイベント・メッセージが誤配信されることを避けることを目的とした４ビット長の識別子である。送出時に相隣り合うローカル・コンテンツ間では異なる識別子が割り当てられる。
【０１１１】
参照番号８０２で示す、ｅｖｅｎｔ＿ｍｓｇ＿ｇｒｏｕｐ＿ｉｄは、アプリケーションが受信すべきメッセージ群を識別する１２ビット長の識別子である。本明細書で開示する技術では、アプリケーション（又は放送番組）に対応した値となるｅｖｅｎｔ＿ｍｓｇ＿ｇｒｏｕｐ＿ｉｄを指定することを想定しているが、詳細については後述に譲る。
【０１１２】
ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒは、サブテーブルのバージョン番号である。
【０１１３】
ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒは、‘１’の場合はサブテーブルが現在のサブテーブルであることを示し、‘０’の場合は送られるサブテーブルはまだ適用されず、次のサブテーブルとして使用されることを示す。
【０１１４】
ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒは、セクションの番号を表す８ビットのフィールドである。
【０１１５】
ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒは、このセクションが属するサブテーブルの最後のセクション（すなわち、最大のセクション番号を持つセクション）の番号を示す８ビットのフィールドである。
【０１１６】
ＥＭＴは、所定数Ｎの、イベント・メッセージ伝送方式に用いる記述子（ｄｅｓｃｒｉｐｔｏｒ）を格納する。この記述子領域には、最大８個のイベント・メッセージ記述子と、１つのＵＴＣ−ＮＰＴ参照記述子を配置することが可能である。このうち、イベント・メッセージ記述子は、イベント・メッセージ一般に関する情報を伝達するために用いる記述子である。複数の即時発火のイベント・メッセージ記述子を配置する場合は、出現順に発火することとする。
【０１１７】
図９には、ＡＲＩＢ  ＳＴＤ  Ｂ−６０で規定されているイベント・メッセージ記述子のシンタックス９００を示している。以下、同記述内の各パラメーターについて説明する。
【０１１８】
ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇは、当該記述子がイベント・メッセージ記述子であることを識別する１６ビットの固定値を示す。ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈは、このフィールドの直後から記述子の末尾までのバイト長を示す１６ビットのフィールドである。
【０１１９】
ｅｖｅｎｔ＿ｍｓｇ＿ｇｒｏｕｐ＿ｉｄは、アプリケーションが受信すべきメッセージ群を識別する１２ビット長の識別子である。
【０１２０】
ｔｉｍｅ＿ｍｏｄｅ（時間モード）は、イベント・メッセージの発生する時刻の指定方法を示す８ビットのフィールドである。時間モードの構成を以下の表１にまとめておく。なお、以下では、説明の簡素化のため、ｔｉｍｅ＿ｍｏｄｅ＝０ｘ００、すなわち、受信後すぐにイベント・メッセージを発生すること（即時発火）を前提とする。
【０１２１】
【表１】
2016174239.tif 000003
【０１２２】
ｅｖｅｎｔ＿ｍｓｇ＿ＵＴＣは、時間モードが０ｘ０１又は０ｘ０５の場合に符号化され、イベント・メッセージが発生する時刻をＣｏｒｄｉｎａｔｅｄ  Ｕｎｉｖｅｒｓａｌ  Ｔｉｍｅ（ＵＴＣ）の絶対時刻をＮＴＰタイムスタンプ形式で示す６４ビットのフィールドである。
【０１２３】
ｅｖｅｎｔ＿ｍｓｇ＿ＮＰＴは、時間モードが０ｘ０２の場合に符号化され、ＵＴＣ−ＮＰＴ参照記述子で示すＮｏｒｍａｌ  Ｐｌａｙ  Ｔｉｍｅによって、イベント・メッセージが発生する時刻を示す６４ビットのフィールドである。
【０１２４】
ｅｖｅｎｔ＿ｍｓｇ＿ｒｅｌａｔｉｖｅＴｉｍｅは、時間モードが０ｘ０３の場合に符号化され、番組開始時点からの相対時刻でイベント・メッセージが発生する時刻を示す６４ビットのフィールドである。
【０１２５】
ｅｖｅｎｔ＿ｍｓｇ＿ｔｙｐｅは、イベント・メッセージの種類を示す識別子である。また、ｅｖｅｎｔ＿ｍｓｇ＿ｉｄは、個々のイベント・メッセージを識別するための１６ビット長の識別子である。データ放送アプリケーションを符号化したＨＴＭＬ文書内で、ｅｖｅｎｔ＿ｍｓｇ＿ｉｄに対応する処理（アクション）を、例えばＪａｖａ（登録商標）スクリプトの形式で記述しておく。アプリケーションを動作している受信機にイベント・メッセージ記述子が届くと、その記述子で指定されているｅｖｅｎｔ＿ｍｓｇ＿ｉｄに対応するアクションを即時発火する（あるいは、時間モードに応じて指定されるイベント・メッセージの発生時刻で、該当するアクションを発火する）。
【０１２６】
ｐｒｉｖａｔｅ＿ｄａｔａ＿ｂｙｔｅは、ｅｖｅｎｔ＿ｍｓｇ＿ｔｙｐｅの値に応じて定義される、イベント・メッセージの関連情報を格納するフィールドである。
【０１２７】
本出願前に運用が想定されるイベント・メッセージの伝送方式では、ＥＭＴに格納される１２ビットのｅｖｅｎｔ＿ｍｓｇ＿ｇｒｏｕｏｐ＿ｉｄと４ビットのｄａｔａ＿ｅｖｅｎｔ＿ｉｄの２つのパラメーターをＥＭＴのフィルター条件とするものである。
【０１２８】
具体的には、ｅｖｅｎｔ＿ｍｓｇ＿ｇｒｏｕｏｐ＿ｉｄとして０ｘ０００と０ｘ００１の２値のみを使用し、この値に応じたフィルター条件を適用する。
【０１２９】
ｅｖｅｎｔ＿ｍｓｇ＿ｇｒｏｕｏｐ＿ｉｄ＝０ｘ０００とする場合では、受信機で動作しているアプリケーションに、ｄａｔａ＿ｅｖｅｎｔ＿ｉｄが合致するイベント・メッセージ・テーブルを適用する。
【０１３０】
ＭＭＴ方式の放送システムでは、データ放送アプリケーションを伝送するＭＭＴＰパケットには、必要に応じてマルチ拡張ヘッダー・タイプ０ｘ０００２を指定し、マルチ拡張ヘッダー領域にダウンロード識別情報を記載する（ＡＲＩＢＥ  ＳＴＤ  Ｂ−６０、並びに、例えば本出願人に既に譲渡されている特願２０１４−２５０２７９号明細書を参照のこと）。また、上記でも述べたように、データ伝送メッセージで伝送されるデータ・アセット管理テーブルは、各データ・コンポーネントのダウンロード識別情報を示す。そして、データ・イベントの運用を行なう場合には、３２ビット長のダウンロード識別情報のビット２８〜３１にｄａｔａ＿ｅｖｅｎｔ＿ｉｄを符号化するようになっている。したがって、動作中のデータ放送アプリケーションに適用すべきイベント・メッセージを、ｄａｔａ＿ｅｖｅｎｔ＿ｉｄでフィルタリングすることができる。
【０１３１】
しかしながら、ＭＭＴ方式の放送システムでは、その時点での伝送対象となるアプリケーション集合であるローカル・コンテンツの伝送を示すデータ・イベントの期間と上記アプリケーション集合の実行期間は必ずしも一致しないので、不適切である。データ・イベントの期間とアプリケーション集合の実行期間が一致しないことに起因する問題点について、図１０を参照しながら説明する。
【０１３２】
図１０では、映像信号のアセット１００１や音声信号のアセット１００２、データ放送アプリケーションのアセット１００３、１００４、並びに、ＭＭＴに関わる制御情報（ＭＭＴ−ＳＩ）である各シグナリング・テーブルの伝送期間を模式的に示している。但し、横方向は時間軸に相当するものとし、時刻ｔ１で放送番組Ｐ１のオンエアが開始し、時刻ｔ３でその放送番組Ｐ１内でコーナーが変更し、時刻ｔ４で放送番組Ｐ１が終了して次の放送番組Ｐ２が開始する。同図では、参照番号１０１１〜１０１６で、イベント情報テーブル（ＥＩＴｐｆ）、アプリケーション情報テーブル（ＡＩＴ）、データ・ディレクトリー管理テーブル（ＤＤＭＴ）、データ・アセット管理テーブル（ＤＡＭＴ）、データ・コンテンツ管理テーブル（ＤＣＣＴ）、イベント・メッセージ・テーブル（ＥＭＴ）の伝送期間をそれぞれ示している。
【０１３３】
ここで、イベント情報テーブル（ＥＩＴ）は、チャンネルに含まれる各コンテンツの放送時間帯を示す番組時間情報などの番組情報を含む番組配列情報である。ＥＩＴｐｆは、番組の変更や終了によって更新されるＥＩＴｐ（現在放送中の番組に対するＥＩＴ）、ＥＩＴｆ（現在放送中の次の番組に対するＥＩＴ）のことである。また、アプリケーション情報テーブル（ＡＩＴ）は、各アプリケーションの処理方法を示し、例えば自動起動（ＡＳ）すべきアプリケーション、実行可能な状態（ＰＲ）にあるアプリケーションを記述している。イベント・メッセージ・テーブル（ＥＭＴ）は、ｅｖｅｎｔ＿ｍｓｇ＿ｇｒｏｕｏｐ＿ｉｄとｄａｔａ＿ｅｖｅｎｔ＿ｉｄを含む、イベント・メッセージに関する情報を伝送する。
【０１３４】
アプリケーション・アセット１００３は番組連動型アプリケーションであり、アプリケーション・アセット１００４は番組非連動型アプリケーションである。番組の切り替わり並びに番組コーナーの切り替わりに連動して、アプリケーション・アセット１００３として伝送されるアプリケーションが変更される。すなわち、時刻ｔ１〜ｔ２の期間に番組連動型アプリケーション集合ａｐｐ１、ａｐｐ２が伝送され、時刻ｔ２〜ｔ４の期間に番組連動型アプリケーション集合ａｐｐ６、ａｐｐ７が伝送される。また、時刻ｔ３以降では、番組連動型アプリケーションの伝送が停止される。一方、アプリケーション・アセット１００４は、番組の切り替わりや番組コーナーの切り替わりには連動せずに、期間ｔ１〜ｔ４を通して番組非連動型アプリケーション集合ａｐｐ３、ａｐｐ４、ａｐｐ５が伝送され続ける。
【０１３５】
アプリケーション情報テーブル（ＡＩＴ）１０１２は、時刻ｔ１〜ｔ２の期間では、自動起動すべきアプリケーション（ＡＳ）にａｐｐ１を示すとともに、実行可能な状態にあるアプリケーション（ＰＲ）としてアプリケーションａｐｐ２、ａｐｐ３、ａｐｐ４、ａｐｐ５を示している。時刻ｔ２〜ｔ３の期間では、自動起動すべきアプリケーション（ＡＳ）はａｐｐ１を保持し、実行可能な状態にあるアプリケーション（ＰＲ）としてａｐｐ２、ａｐｐ３、ａｐｐ４、ａｐｐ５も保持するが、新たに事前蓄積（ＰｒｅＦｅｔｃｈ）すべきアプリケーション（ＰＦ）としてａｐｐ６を示している。また、時刻ｔ３〜ｔ４の期間では、自動起動すべきアプリケーション（ＡＳ）にａｐｐ６を示すとともに、実行可能な状態にあるアプリケーション（ＰＲ）としてアプリケーションａｐｐ７、ａｐｐ３、ａｐｐ４を示している。また、時刻ｔ３以降では、自動起動すべきアプリケーション（ＡＳ）に番組非連動アプリケーションａｐｐ３を示すとともに、実行可能な状態にあるアプリケーション（ＰＲ）としてアプリケーションａｐｐ４、ａｐｐ５を示している。これは、ｔ１〜ｔ２のデータ・イベント期間に、アプリケーション・アセット１００３でローカル・コンテンツとして伝送されているアプリケーション集合ａｐｐ１、ａｐｐ２の実行期間はｔ１〜ｔ３であり、同様にｔ２〜ｔ４のデータ・イベント期間で、アプリケーション・アセット１００３でローカル・コンテンツとして伝送されているアプリケーション集合ａｐｐ６、ａｐｐ７の実行期間はｔ３〜ｔ４であることを示していることになる。
【０１３６】
また、図１０の最下段では、各期間におけるアプリケーションの遷移関係を示している。時刻ｔ１〜ｔ２の期間では、ａｐｐ１がエントリー・アプリケーションに指定されており、ａｐｐ１は番組連動型アプリケーションａｐｐ２と番組非連動型アプリケーションａｐｐ３へ遷移している。ａｐｐ３は、同じく番組非連動型であるアプリケーションａｐｐ４へ遷移し、ａｐｐ４はさらにａｐｐ５へ遷移している。また、時刻ｔ２〜ｔ３の期間では、ａｐｐ６がエントリー・アプリケーションに指定されており、ａｐｐ６は番組連動型アプリケーションａｐｐ７と番組非連動型アプリケーションａｐｐ３へ遷移している。時刻ｔ２以前と同様に、ａｐｐ３は、番組非連動型であるアプリケーションａｐｐ４へ遷移し、ａｐｐ４はさらにａｐｐ５へ遷移している。
【０１３７】
受信機は、アプリケーション情報テーブル（ＡＩＴ）１０１２を参照
し、時刻ｔ１で放送番組Ｐ１のオンエアが開始されたことに連動して、エントリー・アプリケーションａｐｐ１を自動起動する。ＡＩＴはアプリケーションのロケーション情報をＵＲＬ形式（パス名）で示すが、データ・ディレクトリー管理テーブル１０１３及びデータ・アセット管理テーブル１０１４を用いて、アセットのパス名をＭＭＴ伝送路上の識別情報（パケット識別情報）に変換して、アプリケーション・アセット１００３の中からａｐｐ１のエンティティーであるファイル（ＨＴＭＬ文書）を取得することができる。
【０１３８】
また、データ・アセット管理テーブル１０１４は、各データ・コンポーネントのダウンロード識別情報を示し、そのビット２８〜３１にｄａｔａ＿ｅｖｅｎｔ＿ｉｄを符号化する。また、アプリケーション・アセット１００３のＭＭＴＰパケットには、マルチ拡張ヘッダー・タイプ０ｘ０００２を指定し、マルチ拡張ヘッダー領域にダウンロード識別情報を記載し、同様にそのビット２８〜３１にｄａｔａ＿ｅｖｅｎｔ＿ｉｄを符号化する。したがって、参照番号１０２０で示すように、伝送対象のアプリケーション集合であるローカル・コンテンツの伝送期間を示すｄａｔａ＿ｅｖｅｎｔ＿ｉｄが、アプリケーション・アセット１００３とその伝送制御情報であるＤＡＭＴ１０１４を結び付けた上でＥＭＴにおけるフィルター条件とすることができる。
【０１３９】
ところが、ＭＭＴ方式の放送システムでは、ローカル・コンテンツ伝送を示すデータ・イベントの期間と伝送されたアプリケーション集合の実行期間は必ずしも一致しない。図１０に示す例では、データ・イベントの期間毎に、参照番号１０１６、１０１２でそれぞれ示されるＥＭＴとＡＩＴが更新される。時刻ｔ１〜ｔ２のデータ・イベント期間で伝送されるアプリケーション集合の実行期間ｅ１はｔ１〜ｔ３である。よって、ｄａｔａ＿ｅｖｅｎｔ＿ｉｄをフィルター条件としてＥＭＴ１０１６を受信して、その時点で動作しているアプリケーションにメッセージを伝達すると、本来異なるアプリケーションに対応するメッセージを伝達することになり、ｅｖｅｎｔ＿ｍｓｇ＿ｉｄが偶然一致した場合にアプリケーションが誤った処理を行なうことになりかねない。
【０１４０】
一方、ｅｖｅｎｔ＿ｍｓｇ＿ｇｒｏｕｏｐ＿ｉｄ＝０ｘ０１とする場合、受信機で動作しているアプリケーションにすべてのイベント・メッセージ・テーブルを適用する。
【０１４１】
例えば、ＨＴＭＬ形式に符号化したアプリケーションは、ｅｖｅｎｔ＿ｍｓｇ＿ｉｄに対応する処理（アクション）を、例えばＪａｖａ（登録商標）スクリプトの形式で記述している。受信機で動作しているアプリケーションは、ＥＭＴに配置された各イベント・メッセージ記述子が示すｅｖｅｎｔ＿ｍｓｇ＿ｉｄに対応するアクションをＥＭＴでの出現順で発火する。
【０１４２】
ところが隣り合った番組で同じｅｖｅｎｔ＿ｍｓｇ＿ｉｄを使用している場合には、番組境界付近で、隣り合った番組向けに送信されたイベント・メッセージによって誤ったアクションを発火して、受信機が想定外の誤った動作をし得る危険がある。ｅｖｅｎｔ＿ｍｓｇ＿ｇｒｏｕｐ＿ｉｄ＝０ｘ００１の場合の誤動作問題について、図１１を参照しながら説明する。
【０１４３】
図１１では、映像信号のアセット１１０１や音声信号のアセット１１０２、データ放送アプリケーションのアセット１１０３、並びに、ＭＭＴに関わる制御情報（ＭＭＴ−ＳＩ）である各シグナリング・テーブルの伝送期間を模式的に示している。参照番号１１１１はアプリケーション情報テーブル（ＡＩＴ）の伝送期間を示し、参照番号１１１２はイベント・メッセージ・テーブル（ＥＭＴ）の伝送期間を示している。図１１の横方向は時間軸に相当するものとし、時刻ｔ１で放送番組Ｐ１から放送番組Ｐ２に切り替わるものとする。
【０１４４】
放送番組Ｐ１に連動するアプリケーションＡｐｐ１は、Ｅ１、Ｅ２、Ｅ３の各ｅｖｅｎｔ＿ｍｓｇ＿ｉｄにそれぞれ対応するアクションＡｃｔｉｏｎ１、Ａｃｔｉｏｎ２、Ａｃｔｉｏｎ３を記述している。また、放送番組Ｐ１と隣り合う放送番組Ｐ２でも、放送番組Ｐ１と同じｅｖｅｎｔ＿ｍｓｇ＿ｉｄであるＥ１を重複して使用しており、放送番組Ｐ２に連動するアプリケーションＡｐｐ２は、Ｅ１、Ｅ４、Ｅ５の各ｅｖｅｎｔ＿ｍｓｇ＿ｉｄにそれぞれ対応するアクションＡｃｔｉｏｎ１１、Ａｃｔｉｏｎ１２、Ａｃｔｉｏｎ１３を記述している。
【０１４５】
放送番組Ｐ１に連動するアプリケーションＡｐｐ１向けに送信されているＥＭＴでは、ｅｖｅｎｔ＿ｍｓｇ＿ｉｄがＥ２、…、Ｅ２、…、Ｅ１、…、Ｅ１のイベント・メッセージ記述子が順に配置されている。また、これと隣り合う放送番組Ｐ２に連動するアプリケーションＡｐｐ２向けに送信されているＥＭＴでは、ｅｖｅｎｔ＿ｍｓｇ＿ｉｄがＥ１、…、Ｅ４、…、Ｅ４、…のイベント・メッセージ記述子が順に配置されている。
【０１４６】
図１１に示す例では、アプリケーションＡｐｐ１向けに送信されているＥＭＴの放送番組Ｐ１の終了付近で出現するイベント・メッセージ記述子（Ｅ１）が、隣り合う放送番組Ｐ２に連動するアプリケーションＡｐｐ２の動作期間に、受信機に到来している。参照番号１１２０で示すように、放送番組Ｐ１向けのＥＭＴでは、Ａｃｔｉｏｎ１を動作することを想定して、イベント・メッセージ記述子（Ｅ１）を配置した。しかしながら、アプリケーションＡｐｐ６で同じＥ１のｅｖｅｎｔ＿ｍｓｇ＿ｉｄに対するアクションＡｃｔｉｏｎ１１が規定されているので、受信機では想定外の誤った動作が発生し得る。
【０１４７】
隣り合う放送番組では同じｅｖｅｎｔ＿ｍｓｇ＿ｉｄを重複して使用しないようにアプリケーションを制作すれば、図１１に示したような問題を回避することができる。しかしながら、再放送される番組についても隣り合う放送番組との間でｅｖｅｎｔ＿ｍｓｇ＿ｉｄの整合をとることは困難である。
【０１４８】
そこで、本明細書で開示する技術として、ＭＨ−ＡＩＴ内に、アプリケーション（又は放送番組）に対応した値となるイベント・メッセージ・グループ識別情報（ｅｖｅｎｔ＿ｍｓｇ＿ｇｒｏｕｐ＿ｉｄ：ＥＭＧｉｄ）を指定するイベント・メッセージ・グループ記述子を新規に配置するというイベント・メッセージの伝送方式（以下、単に「本イベント・メッセージ伝送方式」とする）を提案する。
【０１４９】
図５を参照しながら既に説明したように、ＭＨ−ＡＩＴは、アプリケーションに関する動的制御情報及び実行に必要な付加情報を伝送するテーブルであり、Ｍ２セクション・メッセージで伝送される。後述するように、ＭＨ−ＡＩＴは、ＡＩＴサブテーブル内のすべてのアプリケーション（放送番組毎のアプリケーション・グループ）に共通するコモン・ループと、アプリケーション毎のアプリケーション・ループを持つ。コモン・ループにイベント・メッセージ・グループ記述子を配置すると、同記述子で指定されるＥＭＧｉｄはＡＩＴサブテーブル内のすべてのアプリケーションに適用される。また、アプリケーション・ループにイベント・メッセージ・グループ記述子を配置すると、同記述子で指定されるＥＭＧｉｄは該当するアプリケーション又はアプリケーション・グループにのみ適用される。
【０１５０】
図１０や図１１で示したイベント・メッセージ伝送の運用では、ＥＭＧｉｄとして０ｘ０００又は０ｘ００１を使用して、ＥＭＴのフィルター条件を指定するのに利用されている。これに対し、本イベント・メッセージ伝送方式では、上述したような、アプリケーション（又は放送番組）に対応した値となるＥＭＧｉｄをＥＭＴに指定して、アプリケーションに限定したイベント・メッセージの記述を行なって伝送する。したがって、本イベント・メッセージ伝送方式では、ＥＭＧｉｄとして、上記の０ｘ０００、０ｘ００１、０ｘＦＦＦは使用しない。
【０１５１】
また、１つのパッケージ（放送番組）内で、複数のアプリケーションのアセットが伝送されることがある。例えば、同じ放送番組に対して、２以上のデリバリー・セグメントからそれぞれデータ放送アプリケーションが提供される場合である。このような場合、アプリケーションのアセット毎に、イベント・メッセージ（ＥＭＴ）を伝送する必要がある。複数のＥＭＴを同時に伝送する場合、各伝送路のＥＭＴを識別するために、タグ情報ＥＭＴ＿ｔａｇを割り当てるようにする。そして、本イベント・メッセージ伝送方式では、放送サービスのエントリー・ポイントであるＰＡメッセージで伝送されるＭＰテーブルに配置するアプリケーション・サービス記述子の複数のＥＭＴのロケーション情報を指定するループにおいて、ＥＭＴ＿ｔａｇを指定する。
【０１５２】
ここで、アプリケーション・サービス記述子は、アプリケーションの運用に必要又は重要な制御データを格納するシグナリング・メッセージやシグナリング・テーブル（具体的には、ＭＨ−ＡＩＴ、データ伝送メッセージ、ＥＭＴ）のロケーション情報を示すように構成されている。アプリケーション・サービス記述子の詳細については、例えば本出願人に既に譲渡されている特願２０１５−３８１３号明細書を参照されたい。
【０１５３】
また、アプリケーションは、対応するＥＭＴのＥＭＴ＿ｔａｇを指定し、イベント・メッセージのリスナー設定のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）により、当該アプリケーションを動作する受信機に対して、ＥＭＴ＿ｔａｇに該当するＥＭＴ（伝送路）の監視を指示する。受信機は、０ｘ０００／０ｘ００１／０ｘＦＦＦ以外の（有効な）値のＥＭＧｉｄを有するＥＭＴを受信した場合には、ＭＨ−ＡＩＴを参照して、上述したイベント・メッセージ・グループ記述子により現在実行中のアプリケーションに対応付けられたＥＭＧｉｄであれば、そのＥＭＴを取得する。
【０１５４】
そして、受信機は、取得したＥＭＴで指定される個々のｅｖｅｎｔ＿ｍｓｇ＿ｉｄに相当する時刻が到来することにより、イベントを発火する（取得したＥＭＴに配置されるイベント・メッセージ記述子が指定するｅｖｅｎｔ＿ｍｓｇ＿ｉｄに対応するアクションを、そのイベント・メッセージ記述子で指定されている時刻が到来することにより発火する）。
【０１５５】
本イベント・メッセージ伝送方式によれば、アプリケーション毎、あるいは番組単位のアプリケーション・グループ毎に特定のＥＭＧｉｄを持つＥＭＴに、他のアプリケーション（又は番組）とは独立してｅｖｅｎｔ＿ｍｓｇ＿ｉｄを指定しても（例えば、隣り合う放送番組で同じｅｖｅｎｔ＿ｍｓｇ＿ｉｄを重複して使用しても）、図１１に示したような問題が生じることはない。
【０１５６】
本イベント・メッセージ伝送方式について、さらに詳細に説明する。
【０１５７】
図１２には、ＰＡメッセージ１２０１とＰＡメッセージに含まれるＭＰテーブル１２０２のシンタックス例を示している。また、図１３には、ＰＡメッセージのシンタックス例１３００を示している。
【０１５８】
ｍｅｓｓａｇｅ＿ｉｄは、各種シグナリング情報において、ＰＡメッセージを識別する１６ビットの固定値である。ｖｅｒｓｉｏｎは、ＰＡメッセージのバージョンを示す、８ビットの整数値のパラメーターである。例えばＰＡメッセージを構成する一部のパラメーターでも更新した場合には、ｖｅｒｓｉｏｎは＋１だけインクリメントされる。ｌｅｎｇｔｈは、このフィールドの直後からカウントされる、当該ＰＡメッセージのサイズをバイト単位で示す、３２ビット長のパラメーターである。
【０１５９】
ｅｘｔｅｎｓｉｏｎフィールドには、ペイロード（ｍｅｓｓａｇｅ＿ｐａｙｌｏａｄ）のフィールドに配置されるテーブルの属性情報が配置される。具体的には、ｎｕｍｂｅｒ＿ｏｆ＿ｔａｂｌｅフィールドには当該ＰＡメッセージに格納するテーブルの数を示し、続くテーブルのインデックス情報のループでは、格納する各テーブルの属性情報として、８ビットのテーブル識別情報（ｔａｂｌｅ＿ｉｄ）と、８ビットのテーブル・バージョン（ｔａｂｌｅ＿ｖｅｒｓｉｏｎ）と、１６ビットのテーブル長（ｔａｂｌｅ＿ｌｅｎｇｔｈ）が配置される。ｔａｂｌｅ＿ｉｄは、テーブルを識別する固定値である。ｔａｂｌｅ＿ｖｅｒｓｉｏｎは、テーブルのバージョンを示す。ｔａｂｌｅ＿ｌｅｎｇｔｈは、テーブルのサイズをバイト単位で示す。
【０１６０】
ＰＡメッセージのｍｅｓｓａｇｅ＿ｐａｙｌｏａｄフィールドには、参照番号１３０１で示すように、ｎｕｍｂｅｒ＿ｏｆ＿ｔａｂｌｅｓで示される数分だけテーブル格納領域が配置される。このフィールドに格納されるＭＰテーブルは、すべてのアセットのリストを含むパッケージに関連する情報を示す。なお、ＭＰテーブルの他にも、ＬＣ（Ｌａｙｏｐｕｔ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ）テーブルやＰＬ（Ｐａｃｋａｇｅ  Ｌｉｓｔ）テーブルもＰＡメッセージのテーブル格納領域に格納されるが、これらは本明細書で開示する技術に直接関連しないので、詳細な説明は省略する。
【０１６１】
図１４には、ＰＡメッセージに格納されるＭＰテーブルのシンタックス例１４００を示している。以下、ＭＰテーブルの各パラメーターについて説明する。
【０１６２】
ｔａｂｌｅ＿ｉｄは、当該テーブルがＭＰテーブルであることを識別する８ビットの固定値（０ｘ２０）である。ｖｅｒｓｉｏｎは、ＭＰテーブルのバージョンを示す８ビットの整数値である。例えば、ＭＰテーブルを構成する一部のパラメーターでも更新した場合には、ｖｅｒｓｉｏｎは＋１だけインクリメントされる。ｌｅｎｇｔｈは、このフィールドの直後からカウントされる、ＭＰテーブルのサイズをバイト単位で示す、３２ビット長のパラメーターである。また、ＭＰＴ＿ｍｏｄｅは、このＭＰテーブルがサブセットに分割されているときの動作を示すが、詳細な説明は省略する。
【０１６３】
ＭＭＴ＿ｐａｃｋａｇｅ＿ｉｄ＿ｌｅｎｇｔｈは、パッケージ識別情報（ＭＭＴ＿ｐａｃｋａｇｅ＿ｉｄ）のテキスト情報のサイズをバイト単位で示す。続くパッケージ識別情報のループでは、ＭＭＴ＿ｐａｃｋａｇｅ＿ｉｄをバイト単位（ＭＭＴ＿ｐａｃｋａｇｅ＿ｉｄ＿ｂｙｔｅ）でパッケージ識別情報を示す。パッケージ識別情報は、放送信号（ＩＰデータ・フロー）で伝送されるすべての信号（映像、音声、字幕）、並びにファイル・データなどのアセットをコンポーネントとする全体のパッケージとしての識別情報である。この識別情報は、テキスト情報であり、上位１６ビットはサービスを識別するためのサービス識別情報と同じ値とする。
【０１６４】
ＭＰＴ＿ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈは、ＭＰテーブル記述子領域のサイズをバイト単位で示す。続く、参照番号１４０１で示すＭＰテーブル記述子のループでは、ＭＰテーブル記述子の内容をバイト単位（ＭＰＴ＿ｄｅｓｃｒｉｐｔｏｒｓ＿ｂｙｔｅ）で記述する。アプリケーション・サービス記述子は、ＭＰテーブル記述子の１つとして、例えばアプリケーションのデリバリー・セグメント毎に配置される。各アプリケーション・サービス記述子内には、対応するデリバリー・セグメントが提供するデータ放送アプリケーションの運用に必要又は重要な制御情報であるＭＨ−ＡＩＴ、データ伝送メッセージ、及び各ＥＭＴのロケーション情報を示す。また、複数のＥＭＴ伝送路がある場合には、各伝送路のＥＭＴを識別するＥＭＴ＿ｔａｇとそのロケーション情報を示す。アプリケーション・サービス記述子のシンタックスの詳細については、後述に譲る。
【０１６５】
ｎｕｍｂｅｒ＿ｏｆ＿ａｓｓｅｔｓは、パッケージを構成する要素としてのアセット（信号、ファイル）の数を示す、８ビットのパラメーターである。ｎｕｍｂｅｒ＿ｏｆ＿ａｓｓｅｔの数分だけ、アセット情報のループが配置される。１つのアセット情報のループ内には、個々のアセットの情報としてのアセット識別情報（ａｓｓｅｔ＿ｉｄ）と、一般ロケーション情報（ＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏ）と、アセット記述子（ａｓｓｅｔ＿ｄｅｓｃｒｉｐｔｏｒ）の各パラメーターが配置される。アセット情報のループ内に配置される情報について、以下に説明する。
【０１６６】
ｉｄｅｎｔｉｆｉｅｒ＿ｔｙｐｅは、ＭＭＴＰパケット・フローのＩＤ体系を示す。アセット識別情報（ａｓｓｅｔ＿ｉｄ）を示すＩＤ体系であれば０ｘ００とする。ａｓｓｅｔ＿ｉｄ＿ｓｃｈｅｍｅは、アセット識別情報の形式を示す。ａｓｓｅｔ＿＿ｉｄ＿ｌｅｎｇｔｈは、アセット識別情報のテキスト情報のサイズをバイト単位で示す。続くアセット識別情報のループでは、アセット識別情報をバイト単位（ａｓｓｅｔ＿ｉｄ＿ｂｙｔｅ）で示す。
【０１６７】
ａｓｓｅｔ＿ｔｙｐｅは、アセットの種類を３２ビット長の文字列で示す。ａｓｓｅｔ＿ｃｌｏｃｋ＿ｒｅｌａｔｉｏｎ＿ｆｌａｇは、アセットのクロック情報フィールドの有無を示すフラグである。当該フラグが１のときは、クロック情報識別フィールド（ａｓｓｅｔ＿ｃｌｏｃｋ＿ｒｅｌａｔｉｏｎ＿ｉｄ）とタイムスケール・フラグ・フィールド（ａｓｓｅｔ＿ｔｉｍｅｓｃａｌｅ＿ｆｌａｇ）が存在し、０のときはこれらのフィールドは存在しない。ｌｏｃａｔｉｏｎ＿ｃｏｕｎｔは、アセットのロケーション情報の数を示し、続くｌｏｃａｔｉｏｎ＿ｃｏｕｎｔの数だけ繰り返されるロケーション情報のループでは、該当するアセットのロケーション情報であるＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏが示される。アセットのロケーション情報は、アセットの取得先となるＭＭＴ伝送路上のパケット識別情報（ｐａｃｋｅｔ＿ｉｄ：ＰＩＤ）の形式で記述される。したがって、ＭＰテーブル上でアセット識別情報を引いて、ＭＭＴ伝送路（ＩＰデータ・フロー）上の該当するパケット識別情報を取り出すことができる（図６を参照のこと）。ＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏのデータ構造については、後述に譲る。
【０１６８】
ａｓｓｅｔ＿ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈは、アセット記述子（ａｓｓｅｔ＿ｄｅｓｃｒｉｐｔｏｒ）のテキスト情報のサイズをバイト単位で示す。続くアセット記述子のループでは、アセット毎の記述子の内容をバイト単位（ａｓｓｅｔ＿ｄｅｓｃｒｉｐｔｏｒｓ＿ｂｙｔｅ）で示す。
【０１６９】
図１５には、ＭＰテーブル内に配置されるアプリケーション・サービス記述子のシンタックス例１５００を示している。以下、アプリケーション・サービス記述子の各パラメーターについて説明する。
【０１７０】
ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇ（記述子タグ）は、８ビットのフィールドで、当該記述子の種類を識別する。ｄｅｓｃｒｉｐｔｏｒｓ＿ｌｅｎｇｔｈは、このフィールドより後に続くデータ・バイト数を書き込む領域である。
【０１７１】
ａｐｐｌｉｃａｔｉｏｎ＿ｆｏｒｍａｔ＿ｍａｐは、アプリケーション・サービスで適用されている方式をビットマップで示す。具体的には、ビット０をＨＴＭＬ５として、０ｘ００の固定運用とする。ＨＴＭＬ５のみ対応の受信機はｂｉｔ０＝１であることのみをチェックし、他のビット位置の値は無視する。
【０１７２】
ｄｅｆａｕｌｔ＿ＡＩＴ＿ｆｌａｇは、対応するデリバリー・セグメントから伝送されるＭＨ−ＡＩＴがデフォルトの監視対象ＡＩＴであるか否かを示すフラグである。
【０１７３】
ＤＴ＿ｍｅｓｓａｇｅ＿ｆｌａｇは、対応するデリバリー・セグメントから、データ放送アプリケーションの制御情報としてデータ伝送メッセージが伝送されるか否かを示すフラグである。
【０１７４】
ＥＭＴ＿ｎｕｍは、ＥＭＴの伝送数を示す。例えば、放送番組向けに複数のデリバリー・セグメントからデータ放送アプリケーションが伝送される場合、ＥＭＴもデリバリー・セグメント毎の伝送路で伝送される。ＥＭＴの伝送数が複数となる場合、各伝送路のＥＭＴはＥＭＴ＿ｔａｇで識別される。なお、ＩＰネットワークでのみデータ放送アプリケーションを配信する場合（放送信号ではデータ放送アプリケーションを配信しない場合）には、データ伝送メッセージやＥＭＴは配信されない。
【０１７５】
ＡＩＴ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏは、Ｍ２セクション・メッセージで伝送されるシグナリング・テーブルの１つであるＭＩＴ−ＡＩＴのロケーション情報を、ＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏ（一般ロケーション情報）のシンタックスに従って示す。ＭＨ−ＡＩＴが放送信号で伝送される場合のＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏのｌｏｃａｔｉｏｎ＿ｔｙｐｅは「０ｘ００」であり、通信で伝送される場合のｌｏｃａｔｉｏｎ＿ｔｙｐｅは「０ｘ０５」である。ＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏの詳細については、後述に譲る。
【０１７６】
また、ＤＴ＿ｍｅｓｓａｇｅ＿ｆｌａｇが１のときには、データ伝送メッセージのロケーション情報ＤＴ＿ｍｅｓｓａｇｅ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏが、ＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏのシンタックスに従って示される。データ伝送メッセージは放送信号でのみ伝送されるので、ＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏのｌｏｃａｔｉｏｎ＿ｔｙｐｅは基本的に「０ｘ００」である。
【０１７７】
参照番号１５０１で示す、ＥＭＴ＿ｎｕｍの数（ＥＭＴの伝送数）分のループで、各ＥＭＴの識別子であるＥＭＴ＿ｔａｇとロケーション情報ＥＭＴ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏが指定される。ＥＭＴ＿ｔａｇは、アプリケーションからのリスナー設定時に参照される情報である。また、ＥＭＴ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏは、ＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏのシンタックスに従って示される。ＥＭＴは放送信号でのみ伝送されるので、ＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏのｌｏｃａｔｉｏｎ＿ｔｙｐｅは基本的に「０ｘ００」である。
【０１７８】
図１６には、ロケーション情報を示すＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏ（一般ロケーション情報）のシンタックス例１６００を示している。以下、ＭＭＴ＿ｇｅｎｅｒａｌ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏの各パラメーターについて説明する。
【０１７９】
ｌｏｃａｔｉｏｎ＿ｔｙｐｅは、ロケーション情報の種類を８ビットで示し、以下の表２の割り当てに従う。
【０１８０】
【表２】
2016174239.tif 000004
【０１８１】
ｌｏｃａｔｉｏｎ＿ｔｙｐｅが０ｘ００のときは、当該ロケーション情報を含むテーブルが伝送されるＩＰデータ・フローと同一のＩＰデータ・フローのＭＭＴＰパケットのパケット識別情報（ｐａｃｋｅｔ＿ｉｄ）を示す。
【０１８２】
ｌｏｃａｔｉｏｎ＿ｔｙｐｅが０ｘ０１のときは、ロケーション情報として、ＩＰｖ４データ・フローのＭＭＴＰパケットを示す。具体的には、ＩＰｖ４データ・フローの送信元アドレス（ｉｐｖ４＿ｓｒｃ＿ａｄｄｒ）と、ＩＰｖ４データ・フローの宛先アドレス（ｉｐｖ４＿ｄｓｔ＿ａｄｄｒ）と、ＩＰデータ・フローの宛先ポート番号（ｄｓｔ＿ｐｏｒｔ）と、パケット識別情報（ｐａｃｋｅｔ＿ｉｄ）を示す。
【０１８３】
ｌｏｃａｔｉｏｎ＿ｔｙｐｅが０ｘ０２のときは、ロケーション情報として、ＩＰｖ６データ・フローのＭＭＴＰパケットを示す。具体的には、ＩＰｖ６データ・フローの送信元アドレス（ｉｐｖ６＿ｓｒｃ＿ａｄｄｒ）と、ＩＰｖ６データ・フローの宛先アドレス（ｉｐｖ６＿ｄｓｔ＿ａｄｄｒ）と、ＩＰデータ・フローの宛先ポート番号（ｄｓｔ＿ｐｏｒｔ）と、パケット識別情報（ｐａｃｋｅｔ＿ｉｄ）を示す。
【０１８４】
ｌｏｃａｔｉｏｎ＿ｔｙｐｅが０ｘ０３のときは、ロケーション情報として、ＭＰＥＧ−２  ＴＳの放送ネットワークのＭＰＥＧ−２  ＴＳパケットを示す。具体的には、放送ネットワークを識別するためのネットワーク識別情報（ｎｅｔｗｏｒｋ＿ｉｄ）と、ＭＰＥＧ−２  ＴＳを識別するためのトランスポート・ストリーム識別情報（ＭＰＥＧ＿２＿ｔｒａｎｓｐｏｒｔ＿ｓｔｒｅａｍ＿ｉｄ）と、ＭＰＥＧ−２  ＴＳパケットのパケット識別情報（ＭＰＥＧ＿２＿ＰＩＤ）を示す。
【０１８５】
ｌｏｃａｔｉｏｎ＿ｔｙｐｅが０ｘ０４のときは、ロケーション情報として、ＩＰｖ６データ・フローのＭＰＥＧ−２  ＴＳパケットを示す。具体的には、ＩＰｖ６データ・フローの送信元アドレス（ｉｐｖ６＿ｓｒｃ＿ａｄｄｒ）と、ＩＰｖ６データ・フローの宛先アドレス（ｉｐｖ６＿ｄｓｔ＿ａｄｄｒ）と、ＩＰデータ・フローの宛先ポート番号（ｄｓｔ＿ｐｏｒｔ）と、ＭＰＥＧ−２  ＴＳパケットのパケット識別情報（ＭＰＥＧ＿２＿ＰＩＤ）を示す。
【０１８６】
ｌｏｃａｔｉｏｎ＿ｔｙｐｅが０ｘ０５のときは、ＵＲＬでロケーション情報を示す。具体的には、ＵＲＬ＿ｌｅｎｇｔｈは、ＵＲＬバイト・フィールドの長さをバイト単位で示し、続くＵＲＬバイトのループでは、ＵＲＬ文字列をバイト単位（ＵＲＬ＿ｂｙｔｅ）で示す。
【０１８７】
図１７には、Ｍ２セクション・メッセージで伝送されるシグナリング・テーブルの１つであるＭＨ−ＡＩＴのシンタックス例１７００を示している。上述したように、ＭＰテーブルに配置されるアプリケーション・サービス記述子内のＡＩＴ＿ｌｏｃａｔｉｏｎ＿ｉｎｆｏが、対ＭＩＴ−ＡＩＴのロケーション情報を、一般ロケーション情報（図１６を参照のこと）のシンタックスに従って示す。以下、ＭＨ−ＡＩＴの各パラメーターの意味について説明する。
【０１８８】
ｔａｂｌｅ＿ｉｄ（テーブル識別）は、各種シグナリング情報においてアプリケーション情報（ＡＩ）テーブルであることを識別する８ビットの固定値であり、本実施形態では０ｘ８９とする。ｓｅｃｔｉｏｎ＿ｓｙｎｔａｘ＿ｉｎｄｉｃａｔｏｒ（セクション・シンタクス指示）は、１ビットのフィールドで、常に「１」とする。ｓｅｃｔｏｉｎ＿ｌｅｎｇｔｈ（セクション長）は、１２ビットのフィールドで、セクション長フィールドからＣＲＣ３２を含むセクションの最後までのセクションのバイト長を規定する。この値は４０９３（１６進数で０ｘＥＦＤ）を超えないものとする。
【０１８９】
ａｐｐｌｉｃａｔｉｏｎ＿ｔｙｐｅ（アプリケーション・タイプ）は、１６ビットのフィールドで、当該ＭＨ−ＡＩＴの制御対象となるアプリケーションのタイプを示す。アプリケーション・タイプの割り当ては、以下の表３に従うものとする。
【０１９０】
【表３】
2016174239.tif 000005
【０１９１】
ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒ（バージョン番号）は、５ビットのフィールドで、サブテーブルのパーション番号である。ｖｅｒｓｉｏｎ＿ｎｕｍｂｅｒは、当該ＭＨ−ＡＩＴのバージョン番号であり、サブテーブル内の情報に変化があった場合に＋１だけインクリメントされる。また、バージョン番号の値が「３１」になったとき、その次は「０」に戻る。ｃｕｒｒｅｎｔ＿ｎｅｘｔ＿ｉｎｄｉｃａｔｏｒ（カレント・ネクスト指示）は、常に「１」とする。ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒ（セクション番号）は、８ビットのフィールドで、セクションの番号を表す。サブテーブル内で最初のセクションのセクション番号は０ｘ００である。セクション番号は、同一のテーブル識別及びアプリケーション・タイプを持つセクションが追加される度に＋１だけインクリメントされる。ｌａｓｔ＿ｓｅｃｔｉｏｎ＿ｎｕｍｂｅｒ（最終セクション番号）は、８ビットのフィールドであり、そのセクションが属するサブテーブルにおける最後のセクション番号を規定する。
【０１９２】
ｃｏｍｍｏｎ＿ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈ（共通記述子ループ長）は、８ビットのフィールドで、後続のｄｅｓｃｒｉｐｔｏｒのバイト長を示し、このバイト数分のコモン・ループからなる一連の領域１７０１に、ｄｅｓｃｒｉｐｔｏｒ（共通記述子）が書き込まれる。共通記述子領域１７０１は、ＡＩＴサブテーブル内のすべてのアプリケーションに適用される。
【０１９３】
本実施形態では、この共通記述子領域１７０１に、イベント・メッセージ・グループ識別情報ＥＭＧｉｄを指定するイベント・メッセージ・グループ記述子を新規に配置することを想定している。共通記述子領域１７０１に配置されたイベント・メッセージ・グループ記述子で指定されるＥＭＧｉｄは、ＡＩＴサブテーブル内（サービス若しくは放送番組）のすべてのアプリケーションに適用される。
【０１９４】
ａｐｐｌｉｃａｔｉｏｎ＿ｌｏｏｐ＿ｌｅｎｇｔｈは、このＭＨ  ＡＩテーブルに含まれるアプリケーション情報の数を書き込む領域である。そして、ａｐｐｌｉｃａｔｉｏｎ＿ｌｏｏｐ＿ｌｅｎｇｔｈが示す数分だけ、アプリケーション・ループが配置される。
【０１９５】
１つのアプリケーション・ループ内には、ａｐｐｌｉｃａｔｉｏｎ＿ｉｄｅｎｔｉｆｉｅｒ（アプリケーション識別子）と、ａｐｐｌｉｃａｔｉｏｎ＿ｃｏｎｔｒｏｌ＿ｃｏｄｅ（アプリケーション制御コード）と、アプリケーション情報が配置される。
【０１９６】
ここで、ａｐｐｌｉｃａｔｉｏｎ＿ｉｄｅｎｔｉｆｉｅｒ（アプリケーション識別子）は、アプリケーションを識別するパラメーターである。ａｐｐｌｉｃａｔｉｏｎ＿ｃｏｎｔｒｏｌ＿ｃｏｄｅ（アプリケーション制御コード）は、８ビットのフィールドで、アプリケーションの状態を制御する制御コードを規定する。このフィールドのセマンティックスは、アプリケーション・タイプの値に依存する。アプリケーション・タイプに依存しない場合のアプリケーション制御コードのセマンティックスを表４に示しておく。
【０１９７】
【表４】
2016174239.tif 000006
【０１９８】
ａｐｐｌｉｃａｔｉｏｎ＿ｄｅｓｃｒｉｐｔｏｒ＿ｌｏｏｐ＿ｌｅｎｇｔｈ（アプリケーション情報記述子ループ長）はアプリケーション情報記述子のバイト長を示し、このバイト数分のループからなるアプリケーション情報記述子領域１７０２には、ｄｅｓｃｒｉｐｔｏｒ（アプリケーション情報記述子）が書き込まれる。この記述子領域１７０２内のアプリケーション情報記述子は、上記の共通記述子とは相違し、ａｐｐｌｉｃａｔｉｏｎ＿ｉｄｅｎｔｉｆｉｅｒで指定したアプリケーションのみに適用される。
【０１９９】
本実施形態では、このアプリケーション情報記述子領域１７０２に、イベント・メッセージ・グループ識別情報ＥＭＧｉｄを指定するイベント・メッセージ・グループ記述子を新規に配置することを想定している。アプリケーション情報記述子領域１７０２に配置されたイベント・メッセージ・グループ記述子で指定されるＥＭＧｉｄは、ａｐｐｌｉｃａｔｉｏｎ＿ｉｄｅｎｔｉｆｉｅｒで指定されるアプリケーション（又は、特定のアプリケーション・グループ）にのみ適用される。
【０２００】
そして、当該テーブルの最後に、ＩＴＵ−Ｔ勧告Ｈ．２２２．０に従う巡回冗長符号ＣＲＣ３２（ＣＲＣ）が付加される。
【０２０１】
アプリケーション単位でイベント・メッセージ（ＥＭＴ）を伝送する場合には、アプリケーション・ループ内のアプリケーション情報記述子１７０２として、イベント・メッセージ・グループ記述子を配置する。また、コンポーネント単位など、アプリケーション・グループ毎にイベント・メッセージを伝送する場合には、該当する各々のアプリケーション・ループに同じＥＭＧｉｄの値を持つイベント・メッセージ・グループ記述子を配置すればよい。
【０２０２】
一方、サービス（放送番組）単位のイベント・メッセージを伝送する場合には、コモン・ループ内の共通記述子１７０１として、イベント・メッセージ・グループ記述子を配置すればよい。
【０２０３】
図１８には、ＭＨ−ＡＩＴ内の共通記述子又はアプリケーション情報記述子として配置されるイベント・メッセージ・グループ記述子のシンタックス例１８００を示している。
【０２０４】
ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇは、当該記述子がイベント・メッセージ記述子であることを識別する１６ビットの固定値を示す。ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈは、このフィールドの直後から記述子の末尾までのバイト長を示す１６ビットのフィールドである。
【０２０５】
ｅｖｅｎｔ＿ｍｓｇ＿ｇｒｏｕｐ＿ｉｄは、アプリケーションが受信すべきメッセージ群（イベント・メッセージ・グループ）を識別する１２ビット長の識別子である。上述したように、アプリケーション（又は放送番組）に対応した値となるｅｖｅｎｔ＿ｍｓｇ＿ｇｒｏｕｐ＿ｉｄをイベント・メッセージ・グループ記述子で指定することを想定している。
【０２０６】
図１９〜図２０には、アプリケーションにおけるイベント・メッセージの監視を指定するＡＰＩをそれぞれ例示している。
【０２０７】
図１９に示す「ａｄｄＧｅｎｅｒａｌＥｖｅｎｔＭｅｓｓａｇｅＬｉｓｔｅｎｅｒ（ａｄｄＧＥＭＬｉｓｔｎｅｒ）」は、引数ｐａｒａｍで指定する条件に適合するイベント・メッセージを受信するようにイベント・リスナーを設定する関数である。
【０２０８】
ａｄｄＧＥＭＬｉｓｔｎｅｒは、イベント・メッセージのフィルター条件を指定する引数ｐａｒａｍとして、ＥＭＴ＿ｔａｇと、ｍｅｓｓａｇｅ＿ｇｒｏｕｐ＿ｉｄと、ｍｅｓｓａｇｅ＿ｉｄと、ｍｅｓｓａｇｅ＿ｖｅｒｓｉｏｎを持つ。ＥＭＴは、監視すべきＥＭＴを示す。ｍｅｓｓａｇｅ＿ｇｒｏｕｐ＿ｉｄは、対象とするイベント・メッセージのメッセージ・グループ識別子を示す。ｍｅｓｓａｇｅ＿ｉｄは、対象とするイベント・メッセージのメッセージ識別子を示す。ｍｅｓｓａｇｅ＿ｖｅｒｓｉｏｎは、対象とするイベント・メッセージのメッセージ・バージョンを示す。
【０２０９】
図２０に示す「ｒｅｍｏｖｅＧｅｎｅｒａｌＥｖｅｎｔＭｅｓｓａｇｅＬｉｓｔｅｎｅｒ」は、削除すべきイベント・リスナーの関数である。当該関数を省略すると、イベント・リスナーの関数によらず引数ｐａｒａｍで指定するイベント・メッセージを対象としているすべてのイベント・リスナーを削除対象とすることを指示したものとみなされる。
【０２１０】
ｒｅｍｏｖｅＧｅｎｅｒａｌＥｖｅｎｔＭｅｓｓａｇｅＬｉｓｔｅｎｅｒは、引数ｐａｒａｍとして、ＥＭＴ＿ｔａｇと、ｍｅｓｓａｇｅ＿ｇｒｏｕｐ＿ｉｄと、ｍｅｓｓａｇｅ＿ｉｄと、ｍｅｓｓａｇｅ＿ｖｅｒｓｉｏｎを持つ。ＥＭＴは、削除すべきイベント・リスナーが監視対象としているＥＭＴを示す。ｍｅｓｓａｇｅ＿ｇｒｏｕｐ＿ｉｄは、対象とするイベント・メッセージのメッセージ・グループ識別子を示す。ｍｅｓｓａｇｅ＿ｉｄは、対象とするイベント・メッセージのメッセージ識別子を示す。ｍｅｓｓａｇｅ＿ｖｅｒｓｉｏｎは、対象とするイベント・メッセージのメッセージ・バージョンを示す。
【０２１１】
図２１に示す「ｃａｌｌｂａｃｋＧｅｎｅｒａｌＥｖｅｎｔＭｅｓｓａｇｅＬｉｓｔｅｎｅｒ」は上記イベント・リスナーによりＥＭＴの監視を行っている間に対象となるイベント・メッセージを受信し発火時刻となったときに呼び出されるべき関数であり、発火したイベント・メッセージに関する情報、ＥＭＴ＿ｔａｇ、ｍｅｓｓａｇｅ＿ｇｒｏｕｐ＿ｉｄ、ｍｅｓｓａｇｅ＿ｉｄ、ｍｅｓｓａｇｅ＿ｖｅｒｓｉｏｎ、ｐｒｉｖａｔｅ＿ｄａｔａ＿ｂｙｔｅをメッセージに持つ。ＥＭＴ＿ｔａｇは、当該イベント・メッセージが送信されたＥＭＴを示す。ｍｅｓｓａｇｅ＿ｇｒｏｕｐ＿ｉｄは、当該イベント・メッセージのメッセージ・グループ識別子を示す。ｍｅｓｓａｇｅ＿ｉｄは、当該イベント・メッセージのメッセージ識別子を示す。ｍｅｓｓａｇｅ＿ｖｅｒｓｉｏｎは、当該イベント・メッセージのメッセージ・バージョンを示す。ｐｒｉｖａｔｅ＿ｄａｔａ＿ｂｙｔｅは、当該イベント・メッセージのプライベート・データ・バイトを示す。
【０２１２】
図２２には、アプリケーションとイベント・メッセージの関係を示している。図２２は、横軸を時間軸として、ディジタル放送における各アセット（映像、音声、及びアプリケーション）、並びに各制御情報（ＭＰテーブルＭＨ−ＡＩＴ、データ伝送メッセージ、ＥＭＴ）の伝送期間を模式的に示している。具体的には、時刻ｔ１〜ｔ３が放送番組Ｐのオンエア時間に相当し、放送番組Ｐ本編の映像アセット及び音声アセットが伝送される。また、放送番組Ｐのオンエア時間に合わせて、２種類のデータ放送アプリケーション（Ａｐｐ）のアセット１、２が伝送されている。
【０２１３】
放送番組Ｐは、時刻ｔ１とｔ３の間の時刻ｔ２でシーンがＰ１からＰ２に切り替わる。例えば、一方のＡｐｐアセット１は番組連動型アプリケーションであり、放送番組のシーンの切り替わりに応じて、伝送するアプリケーションが変化する。実際には、受信機でアプリケーション（ファイル）をプリキャッシュする時間を考慮して時刻ｔ２よりも前以て、伝送するアプリケーションが変化する。また、他方のＡｐｐアセット２は番組非連動アプリケーションであり、放送番組内のシーンの切り替わりや放送番組の切り替わりというタイミングでは変化しない。
【０２１４】
ＭＰテーブルは、放送サービスのエントリー・ポイントであるＰＡメッセージで伝送される。図１４を参照しながら説明したように、ＭＰテーブルはＭＰＴ記述子の１つとしてアプリケーション・サービス記述子を配置している。そして、図１５を参照しながら説明したように、アプリケーション・サービス記述子は、データ放送アプリケーションの運用に必要又は重要な制御情報であるＭＨ−ＡＩＴ、データ伝送メッセージ、ＥＭＴの各ロケーション情報を示す。
【０２１５】
ＭＨ−ＡＩＴは、Ａｐｐアセット１及びＡｐｐアセット２として伝送される各アプリケーションに関する動的制御情報及び実行に必要な付加情報を格納している。具体的には、ＭＨ−ＡＩＴは伝送される各アプリケーションの処理方法（ＡＳ（ＡＵＴＯＳＴＡＲＴ（自動起動）、ＰＲ（ＰＲＥＳＥＮＴ：実行可能な状態）など）を示すとともに、アプリケーションのロケーション情報をＵＲＬ（パス名）で示す。なお、時刻ｔ２における放送番組Ｐのシーンの切り替わり、Ａｐｐアセット１で伝送されるアプリケーションが変化することに連動して、ＭＨ−ＡＩＴも時刻ｔ２で更新される。
【０２１６】
データ伝送メッセージは、データ・ディレクトリー管理テーブル、データ・アセット管理テーブル、データ・コンテント管理テーブルを含んでいる。上述したように、データ・ディレクトリー管理テーブル及びデータ・アセット管理テーブルを用いて、パス名で示されるアセットのロケーション情報を、ＭＭＴ伝送路上の識別情報（パケット識別情報）に変換することができる。
【０２１７】
ＥＭＴは、受信機で動作しているアプリケーションに対して、即座にあるいは指定した時刻に、メッセージ情報を送る手段である。図２２に示す例では、１つの放送番組Ｐ向けに２つのアプリケーションのアセットが伝送されており、Ａｐｐアセット１にイベント・メッセージを送るＥＭＴ１と、Ａｐｐアセット２にイベント・メッセージを送るＥＭＴ２という２つのＥＭＴが伝送される。ＥＭＴ１とＥＭＴ２はＥＭＴ＿ｔａｇで識別される。なお、時刻ｔ２における放送番組Ｐのシーンの切り替わりに連動してＡｐｐアセット１で伝送されるアプリケーションが変化することに連動して、イベント・メッセージＥＭＴ１も時刻ｔ２で更新される。
【０２１８】
図１０や図１１に示した運用例とは相違して、図２２に示す実施形態では、ＥＭＴ１及びＥＭＴ２は、アプリケーション（又は放送番組）に対応した値となるｅｖｅｎｔ＿ｍｓｇ＿ｇｒｏｕｏｐ＿ｉｄ（ＥＭＧｉｄ）をそれぞれ指定する。また、図２２に示す実施形態では、ＭＨ−ＡＩＴのアプリケーション・ループ（又はコモン・ループ）に、アプリケーション（又は放送番組）に対応した値となるｅｖｅｎｔ＿ｍｓｇ＿ｇｒｏｕｏｐ＿ｉｄ（ＥＭＧｉｄ）を指定するイベント・メッセージ・グループ記述子を配置する（図１７及び図１８を参照のこと）。
【０２１９】
伝送されるアプリケーションのアセット数などに応じて、複数のＥＭＴが伝送される場合には、伝送路毎のＥＭＴを識別するＥＭＴ＿ｔａｇが割り当てられる。ＥＭＴ１のＥＭＴ＿ｔａｇ＝１とし、ＥＭＴ２のＥＭＴ＿ｔａｇ＝２とする。また、このような場合、ＭＰテーブルに配置されるアプリケーション・サービス記述子は、ＥＭＴ毎に（ＥＭＴ＿ｔａｇと対応付けて）ＥＭＴのロケーション情報を示す（図１５を参照のこと）。
【０２２０】
続いて、図２２を参照しながら、受信機におけるイベント・メッセージの処理動作について説明する。
【０２２１】
受信機で選局操作が行なわれ、放送番組Ｐのチャンネルに切り替えられると、参照番号２２０１で示すように、ＰＡメッセージで伝送されるＭＰテーブルから、アプリケーション・サービス記述子を取得する。アプリケーション・サービス記述子は、ＭＨ−ＡＩＴ、データ伝送メッセージ、及び各ＥＭＴのロケーション情報を示すので、受信機は、これらのテーブルやメッセージを取得することが可能になる。
【０２２２】
そして、受信機は、アプリケーション・サービス記述子で指定されているＭＨ−ＡＩＴのロケーション情報に基づいてＭＨ−ＡＩＴを取得する。時刻ｔ１〜ｔ２、ｔ２〜ｔ３の期間で、それぞれ参照番号２２１１、２２１２で示すＭＨ−ＡＩＴを取得できるものとする。
【０２２３】
参照番号２２１１で示す、時刻ｔ１〜ｔ２の期間で伝送されるＭＨ−ＡＩＴは、アプリケーションａｐｐ１が自動起動（ＡＳ）に指定されている。そこで、受信機（アプリケーション制御部４０８）は、アプリケーション・エンジン４０９に対して、ａｐｐ１の起動を指示する。ＭＨ−ＡＩＴにはａｐｐ１のパス名が指定されているので、データ伝送メッセージ内のデータ・ディレクトリー管理テーブル及びデータ・アセット管理テーブルに基づいてパス名をＭＭＴ伝送路上のパケット識別情報に変換すると、参照番号２２４１で示すように、Ａｐｐアセット１からａｐｐ１用のデータ・ファイル（ＨＴＭＬ文書）を取得して、アプリケーション・エンジン４０９で実行することができる。
【０２２４】
参照番号２２４１で示すように、ａｐｐ１は、対応するＥＭＴのＥＭＴ＿ｔａｇ＝１を指定して、イベント・メッセージのリスナー設定のＡＰＩにより、当該アプリケーションａｐｐ１を動作する受信機に対して、ＥＭＴ＿ｔａｇ＝１に該当するＥＭＴ（伝送路）の監視を指示する。
【０２２５】
受信機は、ＭＰテーブルに配置されたアプリケーション・サービス記述子２２０１から、指定されたＥＭＴ＿ｔａｇ＝１に対応するＥＭＴ伝送路のロケーション情報を取得して、参照番号２２２１、２２２２で示すようにＥＭＴ＿ｔａｇ＝１に対応するイベント・メッセージＥＭＴ１を監視する。
【０２２６】
ここで、受信機は、ＥＭＴ１から０ｘ０００／０ｘ００１／０ｘＦＦＦ以外の（有効な）値のＥＭＧｉｄ（＝１０）を有するＥＭＴ１を受信した場合には、この期間で伝送されているＭＨ−ＡＩＴ２２１１に配置されたイベント・メッセージ・グループ記述子を参照して、現在実行中のアプリケーションａｐｐ１に対応付けられたＥＭＧｉｄかどうかをチェックする。このように、受信したＥＭＴが持つＥＭＧｉｄのチェックを行なうことにより、受信機は、アプリケーション間でＥＭｉｄを独立して使用することに伴う誤動作を回避することができる。
【０２２７】
そして、監視中のＥＭＴ伝送路から受信したＥＭＴ１が現在実行中のアプリケーションａｐｐ１に対応付けられたＥＭＧｉｄ＝１０を示す場合には、受信機は、そのＥＭＴ１を取得する。その上で、受信機は、取得したＥＭＴ１で指定される個々のｅｖｅｎｔ＿ｍｓｇ＿ｉｄ（ＥＭｉｄ）に相当する時刻が到来することにより、イベントを発火する。
【０２２８】
図２２に示す例では、放送番組Ｐのオンエア時間内の期間ｔ１〜ｔ２で自動起動（ＡＳ）に指定されているアプリケーションａｐｐ１は、参照番号２２４１で示すように、ＥＭｉｄ＝１に対応するアクションＡｃｔｉｏｎ１、ＥＭｉｄ＝２に対応するアクションＡｃｔｉｏｎ２をそれぞれ指定している。したがって、受信機は、ＥＭＧｉｄ＝１０を示すＥＭＴ１を受信し、そこに配置されているイベント・メッセージ記述子がＥＭｉｄ＝１を示すとアクションＡｃｔｉｏｎ１を発火し、また、イベント・メッセージ記述子がＥＭｉｄ＝２を示すとイベントを発火してアクションＡｃｔｉｏｎ２を実行する（但し、即時発火のイベントとする）。
【０２２９】
また、受信機が、参照番号２２５１に示すように、Ａｐｐアセット２で伝送されるアプリケーションａｐｐ２を実行しているときには、受信機は、ａｐｐ２のイベント・メッセージのリスナー設定のＡＰＩにより、指定されているＥＭＴ＿ｔａｇ＝２に該当するＥＭＴを監視する。
【０２３０】
受信機は、ＭＰテーブルに配置されているアプリケーション・サービス記述子２２０１から、指定されたＥＭＴ＿ｔａｇ＝２に対応するロケーション情報を取得して、参照番号２２３１で示すように、ＥＭＴ＿ｔａｇ＝２に対応するイベント・メッセージＥＭＴ２を監視する。
【０２３１】
受信機は、ＥＭＴ２から０ｘ０００／０ｘ００１／０ｘＦＦＦ以外の（有効な）値のＥＭＧｉｄ（＝１１）を有するＥＭＴ２を受信した場合には、ＭＨ−ＡＩＴ２２１１に配置されたイベント・メッセージ・グループ記述子を参照して、現在実行中のアプリケーションａｐｐ１に対応付けられたＥＭＧｉｄかどうかをチェックする。このように、受信したＥＭＴが持つＥＭＧｉｄのチェックを行なうことにより、受信機は、アプリケーション間でＥＭｉｄを独立して使用することに伴う誤動作を回避することができる。
【０２３２】
そして、受信したＥＭＴ２が現在実行中のアプリケーションａｐｐ２に対応付けられたＥＭＧｉｄ＝１１を示す場合には、受信機は、そのＥＭＴ２を取得する。その上で、受信機は、取得したＥＭＴ２で指定される個々のｅｖｅｎｔ＿ｍｓｇ＿ｉｄ（ＥＭｉｄ）に相当する時刻が到来することにより、イベントを発火する。
【０２３３】
アプリケーションａｐｐ２は、参照番号２２５１で示すように、ＥＭｉｄ＝１に対応するアクションＡｃｔｉｏｎ５を指定している。したがって、受信機は、ＥＭＧｉｄ＝１１を示すＥＭＴ２を受信し、そこに配置されているイベント・メッセージ記述子がＥＭｉｄ＝１を示すとイベントを発火し、アクションＡｃｔｉｏｎ５を実行する。
【０２３４】
アプリケーションａｐｐ１とａｐｐ２は同じイベント・メッセージ識別子ＥＭｉｄ＝１を使用しているが、各アプリケーションが対応する（監視すべき）ＥＭＴ＿ｔａｇを指定し、且つ、イベント・メッセージ・グループ記述子で各アプリケーションに対応した値となるＥＭＧｉｇを指定するので、アプリケーションａｐｐ１とａｐｐ２の動作期間の境界で想定外の誤った動作が発生することはない。
【０２３５】
その後、放送番組Ｐのシーンが切り替わる時刻ｔ２が到来すると、参照番号２２１２で示すようにＭＨ−ＡＩＴが更新されるので、受信機はこれを再取得する。行使されたＭＨ−ＡＩＴでは、アプリケーションａｐｐ４が自動起動（ＡＳ）に指定されている。そこで、受信機（アプリケーション制御部４０８）は、アプリケーション・エンジン４０９に対して、ａｐｐ４の起動を指示する。ＭＨ−ＡＩＴにはａｐｐ４のパス名が指定されているので、データ伝送メッセージ内のデータ・ディレクトリー管理テーブル及びデータ・アセット管理テーブルに基づいてＭＭＴ伝送路上のパケット識別情報に変換すると、参照番号２２４２で示すように、Ａｐｐアセット１からａｐｐ４用のデータ・ファイル（ＨＴＭＬ文書）を取得して、アプリケーション・エンジン４０９で実行することができる。
【０２３６】
参照番号２２４２で示すように、ａｐｐ４は、対応するＥＭＴのＥＭＴ＿ｔａｇ＝１を指定して、イベント・メッセージのリスナー設定のＡＰＩにより、当該アプリケーションａｐｐ４を動作する受信機に対して、ＥＭＴ＿ｔａｇ＝１に該当するＥＭＴ（伝送路）の監視を指示する。
【０２３７】
受信機は、ＭＰテーブルに配置されたアプリケーション・サービス記述子２２０１から、指定されたＥＭＴ＿ｔａｇ＝１に対応するロケーション情報を取得して、参照番号２２３３、２２３４で示すようにＥＭＴ＿ｔａｇ＝１に対応するイベント・メッセージＥＭＴ１を監視する。
【０２３８】
ここで、受信機は、ＥＭＴ１から０ｘ０００／０ｘ００１／０ｘＦＦＦ以外の（有効な）値のＥＭＧｉｄ（＝１２）を有するＥＭＴ１を受信した場合には、この期間で伝送されているＭＨ−ＡＩＴ２２１２に配置されたイベント・メッセージ・グループ記述子を参照して、現在実行中のアプリケーションａｐｐ４に対応付けられたＥＭＧｉｄかどうかをチェックする。このように、受信したＥＭＴが持つＥＭＧｉｄのチェックを行なうことにより、受信機は、アプリケーション間でＥＭｉｄを独立して使用することに伴う誤動作を回避することができる。
【０２３９】
そして、受信したＥＭＴ１が現在実行中のアプリケーションａｐｐ４に対応付けられたＥＭＧｉｄ＝１２を示す場合には、受信機は、そのＥＭＴ１を取得する。その上で、受信機は、取得したＥＭＴ１で指定される個々のｅｖｅｎｔ＿ｍｓｇ＿ｉｄ（ＥＭｉｄ）に相当する時刻が到来することにより、イベントを発火する。
【０２４０】
図２２に示す例では、放送番組Ｐのシーンの切り替わり以降の期間ｔ２〜ｔ３で自動起動（ＡＳ）に指定されているアプリケーションａｐｐ４は、参照番号２２４２で示すように、ＥＭｉｄ＝１に対応するアクションＡｃｔｉｏｎ３、ＥＭｉｄ＝２に対応するアクションＡｃｔｉｏｎ４をそれぞれ指定している。したがって、受信機は、ＥＭＧｉｄ＝１２を示すＥＭＴ１を受信し、そこに配置されているイベント・メッセージ記述子がＥＭｉｄ＝１を示すとイベントを発火してアクションＡｃｔｉｏｎ３を実行し、また、イベント・メッセージ記述子がＥＭｉｄ＝２を示すとイベントを発火してアクションＡｃｔｉｏｎ４を実行する（但し、即時発火のイベントとする）。
【０２４１】
アプリケーションａｐｐ２とａｐｐ４は同じイベント・メッセージ識別子ＥＭｉｄ＝１を使用しているが、各アプリケーションが対応する（監視すべき）ＥＭＴ＿ｔａｇを指定し、且つ、イベント・メッセージ・グループ記述子で各アプリケーションに対応した値となるＥＭＧｉｇを指定するので、アプリケーションａｐｐ２とａｐｐ４の動作期間の境界で想定外の誤った動作が発生することはない。
【０２４２】
すなわち、本イベント・メッセージ伝送方式によれば、アプリケーション毎、あるいは番組単位のアプリケーション・グループ毎に特定のＥＭＧｉｄを持つＥＭＴに、他のアプリケーション（又は番組）とは独立してｅｖｅｎｔ＿ｍｓｇ＿ｉｄを指定しても（例えば、隣り合う放送番組で同じｅｖｅｎｔ＿ｍｓｇ＿ｉｄを重複して使用しても）、図１１に示したような問題が生じることはない。
【０２４３】
図２３には、受信機が図２２に示したような放送信号を受信したときの動作手順をフローチャートの形式で示している。図示の動作は、例えば受信機で選局操作が行なわれたことに応答して起動する。
【０２４４】
受信機は、放送サービスのエントリー・ポイントであるＰＡメッセージで伝送されるＭＰテーブルから、アプリケーション・サービス記述子を取得する（ステップＳ２３０１）。
【０２４５】
次いで、受信機は、アプリケーション・サービス記述子で指定されているＭＨ−ＡＩＴのロケーション情報に基づいてＭＨ−ＡＩＴを取得する（ステップＳ２３０２）。
【０２４６】
次いで、受信機は、ＭＨ−ＡＩＴで自動起動に指定されているアプリケーションを起動する（ステップＳ２３０３）。
【０２４７】
ここで、実行中のアプリケーションが、対応するＥＭＴのＥＭＴ＿ｔａｇを指定して、ＥＭＴの監視を指示している場合には（ステップＳ２３０４のＹｅｓ）、受信機は、ＭＰテーブルに配置されたアプリケーション・サービス記述子から、そのＥＭＴ＿ｔａｇに対応するＥＭＴ伝送路のロケーション情報を取得して、ＥＭＴを監視する（ステップＳ２３０５）。
【０２４８】
そして、受信機は、監視中のＥＭＴ伝送路から、０ｘ０００／０ｘ００１／０ｘＦＦＦ以外の（有効な）値のＥＭＧｉｄを有するＥＭＴを受信できたかどうかをチェックする（ステップＳ２３０６）。
【０２４９】
受信機は、監視中のＥＭＴ伝送路から、０ｘ０００／０ｘ００１／０ｘＦＦＦ以外の（有効な）値のＥＭＧｉｄを有するＥＭＴを受信できたときには（ステップＳ２３０６のＹｅｓ）、ステップＳ２３０２で取得したＭＨ−ＡＩＴに配置されているイベント・メッセージ・グループ記述子を参照して、現在実行中の（すなわち、ステップＳ２３０３で起動した）アプリケーションに対応付けられたＥＭＧｉｄかどうかをチェックする（ステップＳ２３０７）。このように、受信したＥＭＴが持つＥＭＧｉｄのチェックを行なうことにより、受信機は、アプリケーション間でＥＭｉｄを独立して使用することに伴う誤動作を回避するようにする。
【０２５０】
監視中のＥＭＴ伝送路から受信したＥＭＴが現在実行中のアプリケーションに対応付けられたＥＭＧｉｄを示す場合には、受信機は、そのＥＭＴを取得する（ステップＳ２３０８）。そして、取得したＥＭＴで指定される個々のｅｖｅｎｔ＿ｍｓｇ＿ｉｄ（ＥＭｉｄ）に相当する時刻が到来することにより（ステップＳ２３０９のＹｅｓ）、イベントを発火する（ステップＳ２３１０）。
【０２５１】
また、受信機に他のアプリケーションの起動が指示されたときには（ステップＳ２３１１のＹｅｓ）、ステップＳ２３０３に戻り、指定されたアプリケーションを起動して、ステップＳ２３０４以降の処理を繰り返し実行する。
【０２５２】
また、受信機は、放送番組の切り替わりや放送番組内のシーンの切り替わりなどに伴ってＭＨ−ＡＩＴが更新されたことを検出すると（ステップＳ２３１２のＹｅｓ）、ステップＳ２３０２に戻り、アプリケーション・サービス記述子で指定されているＭＨ−ＡＩＴのロケーション情報に基づいてＭＨ−ＡＩＴを再度取得して、ステップＳ２３０３以降の処理を繰り返し実行する。これらの処理が、アプリケーションの実行が終了するまで継続される（ステップＳ２３１３のＹｅｓ）。
【産業上の利用可能性】
【０２５３】
以上、特定の実施形態を参照しながら、本明細書で開示する技術について詳細に説明してきた。しかしながら、本明細書で開示する技術の要旨を逸脱しない範囲で当業者が該実施形態の修正や代用を成し得ることは自明である。
【０２５４】
本明細書で開示する技術は、トランスポート方式としてＭＭＴを採用するさまざまな放送システムにおけるイベント・メッセージの伝送方式として適用することができる。
【０２５５】
要するに、例示という形態により本明細書で開示する技術について説明してきたのであり、本明細書の記載内容を限定的に解釈するべきではない。本明細書で開示する技術の要旨を判断するためには、特許請求の範囲を参酌すべきである。
【０２５６】
なお、本明細書の開示の技術は、以下のような構成をとることも可能である。
（１）放送番組向けのアプリケーションを送信するアプリケーション送信部と、
アプリケーションに関わる制御情報を送信する制御情報送信部と、
を具備し、
前記制御情報送信部は、アプリケーションに対するイベント・メッセージを送信するとともに、アプリケーションに対応したイベント・メッセージ・グループ識別情報を指定するイベント・メッセージ・グループ記述子を配置したシグナリング・テーブルを送信する、
送信装置。
（２）前記制御情報送信部は、前記アプリケーション送信部から送出される各アプリケーションの処理方法並びにロケーション情報を指定するアプリケーション情報テーブルに前記イベント・メッセージ・グループ記述子を配置して送信する、
上記（１）に記載の送信装置。
（３）前記制御情報送信部は、前記アプリケーション情報テーブルのコモン・ループに前記イベント・メッセージ・グループ記述子を配置して前記放送番組向けのすべてのアプリケーションに共通のイベント・メッセージ・グループ識別情報を指定し、又は、前記アプリケーション情報テーブルのアプリケーション・ループに前記イベント・メッセージ・グループ記述子を配置してアプリケーション毎又は所定のアプリケーション・グループ毎のイベント・メッセージ・グループ識別情報を指定する、
上記（２）に記載の送信装置。
（４）前記制御情報送信部は、対応するアプリケーションを限定するイベント・メッセージ・グループ識別情報を記述したイベント・メッセージを送信する、
上記（１）に記載の送信装置。
（５）前記アプリケーション送信部は、複数のアプリケーション伝送路でアプリケーションを送信し、
前記制御情報送信部は、アプリケーション伝送路毎に対応したイベント・メッセージ伝送路で各アプリケーションに向けたイベント・メッセージを送信する、
上記（１）乃至（４）のいずれかに記載の送信装置。
（６）前記制御情報送信部は、伝送路毎のイベント・メッセージを識別するイベント・メッセージ識別タグとイベント・メッセージのロケーション情報の指定を含むアプリケーション・サービス記述子をさらに送信する、
上記（５）に記載の送信装置。
（７）前記制御情報送信部は、前記アプリケーション・サービス記述子を配置したＭＰテーブルを放送サービスのエントリー・ポイントとなるＰＡメッセージに格納して送信する、
上記（６）に記載の送信装置。
（８）前記アプリケーション送信部は、対応するイベント・メッセージのイベント・メッセージ識別タグを指定してイベント・メッセージの監視を指示するアプリケーションを送信する、
上記（６）又は（７）のいずれかに記載の送信装置。
（９）前記アプリケーション送信部及び前記制御情報送信部は、所定のトランスポート方式により前記アプリケーション及び前記制御情報をそれぞれ送信する、
上記（１）乃至（８）のいずれかに記載の送信装置。
（１０）放送番組向けのアプリケーションを送信するアプリケーション送信ステップと、
アプリケーションに関わる制御情報を送信する制御情報送信ステップと、
を有し、
前記制御情報送信ステップでは、アプリケーションに対するイベント・メッセージを送信するとともに、アプリケーションに対応したイベント・メッセージ・グループ識別情報を指定するイベント・メッセージ・グループ記述子を配置したシグナリング・テーブルを送信する、
送信方法。
（１１）放送番組向けのアプリケーションを受信するアプリケーション受信部と、
アプリケーションに関わる制御情報を受信する制御情報受信部と、
受信した制御情報に基づいてアプリケーションの実行を制御するアプリケーション制御部と、
を具備し、
前記制御情報受信部は、アプリケーションに対するイベント・メッセージを送信するとともに、アプリケーションに対応したイベント・メッセージ・グループ識別情報を指定するイベント・メッセージ・グループ記述子を配置したシグナリング・テーブルを受信する、
受信装置。
（１２）前記制御情報受信部は、各アプリケーションの処理方法並びにロケーション情報を指定するるすとともに、前記イベント・メッセージ・グループ記述子を配置したアプリケーション情報テーブルを受信する、
上記（１１）に記載の受信装置。
（１３）前記制御情報受信部は、対応するアプリケーションを限定するイベント・メッセージ・グループ識別情報を記述したイベント・メッセージを受信し、
前記アプリケーション制御部は、イベント・メッセージ・グループ記述子でイベント・メッセージ・グループ識別情報が指定されたアプリケーションに限定して、受信したイベント・メッセージの処理を行なう、
上記（１１）に記載の受信装置。
（１４）前記アプリケーション受信部は、複数のアプリケーション伝送路でアプリケーションを受信し、
前記制御情報受信部は、アプリケーション伝送路毎に対応したイベント・メッセージ伝送路で各アプリケーションに向けたイベント・メッセージを受信する、
上記（１１）乃至（１３）のいずれかに記載の送信装置。
（１５）前記制御情報受信部は、伝送路毎のイベント・メッセージを識別するイベント・メッセージ識別タグとイベント・メッセージのロケーション情報の指定を含むアプリケーション・サービス記述子をさらに受信する、
上記（１４）に記載の送信装置。
（１６）前記アプリケーション制御部は、前記アプリケーション受信部が受信したアプリケーションが指定するイベント・メッセージ識別タグに対して前記アプリケーション・サービス記述子が指定するロケーション情報に基づいてイベント・メッセージを監視する、
上記（１５）に記載の受信装置。
（１７）前記アプリケーション制御部は、受信したイベント・メッセージが指定するイベント・メッセージ・グループ識別情報が前記イベント・メッセージ・グループ記述子で現在実行中のアプリケーションに指定されているか否かに応じて、イベントの発火を制御する、
上記（１６）に記載の受信装置。
（１８）前記アプリケーション受信部及び前記制御情報受信部は、所定のトランスポート方式により前記アプリケーション及び前記制御情報をそれぞれ受信する、
上記（１１）乃至（１７）のいずれかに記載の送信装置。
（１９）放送番組向けのアプリケーションを受信するアプリケーション受信ステップと、
アプリケーションに関わる制御情報を受信する制御情報受信ステップと、
受信した制御情報に基づいてアプリケーションの実行を制御するアプリケーション制御ステップと、
を有し、
前記制御情報受信ステップでは、アプリケーションに対するイベント・メッセージを送信するとともに、アプリケーションに対応したイベント・メッセージ・グループ識別情報を指定するイベント・メッセージ・グループ記述子を配置したシグナリング・テーブルを受信する、
受信装置。
【符号の説明】
【０２５７】
１０…ディジタル放送システム
１１…放送送出システム、１２…受信機
３０１…時計部、３０２…信号送出部
３０３…ビデオ・エンコーダー、３０４…オーディオ・エンコーダー
３０５…キャプション・エンコーダー
３０６…シグナリング・エンコーダー
３０７…ファイル・エンコーダー
３０８…電子データ処理システム（ＥＤＰＳ）
３０９…ＴＬＶシグナリング・エンコーダー
３１０…ＩＰサービス・マルチプレクサー
３１１…ＴＬＶマルチプレクサー、３１２…変調・送信部
４０１…チューナー・復調部、４０２…デマルチプレクサー
４０２−１…ＴＬＶフィルター、４０２−２…ＩＰフィルター
４０２−３…ＵＤＰフィルター、４０２−４…ＭＭＴフィルター
４０２−５…ＳＩフィルター、４０３…時計回復部
４０４…ビデオ・デコーダー、４０５…オーディオ・デコーダー
４０６…キャプション・デコーダー、４０７…システム制御部
４０８…アプリケーション制御部
４０９…データ放送アプリケーション・エンジン
４１０…ＩＰインターフェース、４１１…合成部
【図１】
2016174239.tif 000007
【図２】
2016174239.tif 000008
【図３】
2016174239.tif 000009
【図４】
2016174239.tif 000010
【図６】
2016174239.tif 000011
【図１９】
2016174239.tif 000012
【図２０】
2016174239.tif 000013
【図２１】
2016174239.tif 000014
【図２３】
2016174239.tif 000015
【図５】
2016174239.tif 000016
【図７】
2016174239.tif 000017
【図８】
2016174239.tif 000018
【図９】
2016174239.tif 000019
【図１０】
2016174239.tif 000020
【図１１】
2016174239.tif 000021
【図１２】
2016174239.tif 000022
【図１３】
2016174239.tif 000023
【図１４】
2016174239.tif 000024
【図１５】
2016174239.tif 000025
【図１６】
2016174239.tif 000026
【図１７】
2016174239.tif 000027
【図１８】
2016174239.tif 000028
【図２２】
2016174239.tif 000029