(57)【要約】アプリケーション制御メッセージを適用したアプリケーション制御を確実に実行可能とした構成を実現する。送信装置が受信装置にアプリケーション制御メッセージ（ＡＣＭ）をイベントデータとして格納したイベント通知データを送信する。受信装置のアプリケーション制御部は、イベント通知メッセージにイベントデータとして格納されたＡＣＭに基づくアプリケーション制御を実行する。イベント通知データは、シグナリングデータであるＭＰＤ、または、ＡＶコンテンツの送信用データであるセグメント内に格納され、受信装置はＭＰＤ、またはセグメントからＡＣＭを取得して迅速なアプリケーション制御を行うことができる。
2016174959.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーション制御メッセージをイベントデータとして格納したイベント通知データを受信する通信部と、
イベント通知メッセージにイベントデータとして格納されたアプリケーション制御メッセージに基づくアプリケーション制御を実行するアプリケーション制御部を有する受信装置。
【請求項２】
前記イベント通知データは、
制御情報の通知データとして送信されるシグナリングデータであるＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）を利用したイベント通知方式であるＭＰＤ適用イベント通知方式（ＭＰＤ  Ｅｖｅｎｔ）に従ったデータフォーマットを持つイベント通知データである請求項１に記載の受信装置。
【請求項３】
前記イベント通知データは、
ＡＶコンテンツの送信用データであるセグメントを利用したイベント通知方式であるセグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）に従ったデータフォーマットを持つイベント通知データである請求項１に記載の受信装置。
【請求項４】
前記イベント通知データは、
イベントデータがアプリケーション制御メッセージであることを示すイベント識別子を記録したデータである請求項１に記載の受信装置。
【請求項５】
前記イベント通知データは、
イベントデータとして格納されたアプリケーション制御メッセージに従って処理を実行するための制御時間情報を記録したデータである請求項１に記載の受信装置。
【請求項６】
前記アプリケーション制御メッセージは、
制御対象となるアプリケーション本体、またはアプリケーション識別子を記録したデータである請求項１に記載の受信装置。
【請求項７】
前記アプリケーション制御メッセージは、
制御対象となるアプリケーションに関するメタデータを記録したデータである請求項１に記載の受信装置。
【請求項８】
前記メタデータは、
（ａ）制御対象となるアプリケーションのバージョン、
（ｂ）制御対象となるアプリケーションの実行に必要となるリソース情報、
（ｃ）制御対象となるアプリケーションのレーティング情報、
上記（ａ）〜（ｃ）の少なくともいずれかの情報を含む請求項７に記載の受信装置。
【請求項９】
前記アプリケーション制御メッセージは、
制御対象となるアプリケーションに対するコマンド記録したデータである請求項１に記載の受信装置。
【請求項１０】
前記受信装置は、さらに、
前記通信部の受信したイベント通知データから、アプリケーション制御メッセージを取得して前記アプリケーション制御部に出力するデータ処理部を有する請求項１に記載の受信装置。
【請求項１１】
アプリケーション制御メッセージを受信する通信部と、
前記アプリケーション制御メッセージをイベントデータとして格納したイベント通知データを生成するミドルウェアと、
前記イベント通知データからアプリケーション制御メッセージを取得して、アプリケーション制御部に出力するデータ処理部と、
前記アプリケーション制御メッセージに基づくアプリケーション制御を実行するアプリケーション制御部を有する受信装置。
【請求項１２】
前記ミドルウェアは、
制御情報の通知データとして送信されるシグナリングデータであるＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）を利用したイベント通知方式であるＭＰＤ適用イベント通知方式（ＭＰＤ  Ｅｖｅｎｔ）に従ったデータフォーマットを持つイベント通知データを生成する請求項１１に記載の受信装置。
【請求項１３】
前記ミドルウェアは、
ＡＶコンテンツの送信用データであるセグメントを利用したイベント通知方式であるセグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）に従ったデータフォーマットを持つイベント通知データを生成する請求項１１に記載の受信装置。
【請求項１４】
アプリケーション制御メッセージをイベントデータとして格納したイベント通知データを送信する通信部を有する送信装置。
【請求項１５】
前記イベント通知データは、
制御情報の通知データとして送信されるシグナリングデータであるＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）を利用したイベント通知方式であるＭＰＤ適用イベント通知方式（ＭＰＤ  Ｅｖｅｎｔ）に従ったデータフォーマットを持つイベント通知データである請求項１４に記載の送信装置。
【請求項１６】
前記イベント通知データは、
ＡＶコンテンツの送信用データであるセグメントを利用したイベント通知方式であるセグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）に従ったデータフォーマットを持つイベント通知データである請求項１４に記載の送信装置。
【請求項１７】
受信装置において実行するデータ処理方法であり、
通信部が、アプリケーション制御メッセージをイベントデータとして格納したイベント通知データを受信し、
アプリケーション制御部が、イベント通知メッセージにイベントデータとして格納されたアプリケーション制御メッセージに基づくアプリケーション制御を実行するデータ処理方法。
【請求項１８】
受信装置において実行するデータ処理方法であり、
通信部が、アプリケーション制御メッセージを受信し、
ミドルウェアが、アプリケーション制御メッセージをイベントデータとして格納したイベント通知データを生成し、
データ処理部が、前記イベント通知データからアプリケーション制御メッセージを取得して、アプリケーション制御部に出力し、
アプリケーション制御部が、前記アプリケーション制御メッセージに基づくアプリケーション制御を実行するデータ処理方法。
【請求項１９】
送信装置において実行するデータ処理方法であり、
通信部が、アプリケーション制御メッセージをイベントデータとして格納したイベント通知データを送信するデータ処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、受信装置、送信装置、およびデータ処理方法に関する。さらに詳細には例えば放送波やネットワークを介したデータの受信または送信を実行する受信装置、送信装置、および通信データ対応のデータ処理方法に関する。
【背景技術】
【０００２】
画像データや音声データ等のコンテンツを各通信事業者のサービス形態に関わらず配信可能としたデータ配信方式としてＯＴＴ（Ｏｖｅｒ  Ｔｈｅ  Ｔｏｐ）がある。ＯＴＴによる配信コンテンツはＯＴＴコンテンツと呼ばれ、また、ＯＴＴを利用した画像（ビデオ）データの配信サービスはＯＴＴビデオやＯＴＴ−Ｖ（Ｏｖｅｒ  Ｔｈｅ  Ｔｏｐ  Ｖｉｄｅｏ）と呼ばれる。【０００３】
ＯＴＴ−Ｖに従ったデータストリーミング配信規格としてＤＡＳＨ（Ｄｙｎａｍｉｃ  Ａｄａｐｔｉｖｅ  Ｓｔｒｅａｍｉｎｇ  ｏｖｅｒＨＴＴＰ）規格がある。ＤＡＳＨは、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）をベースとしたストリーミングプロトコルを用いたアダプティブ（適応型）ストリーミング配信に関する規格である。【０００４】
アダプティブ（適応型）ストリーミングでは、放送局等のコンテンツ配信サーバは、データ配信先となる様々なクライアントにおいてコンテンツ再生を可能とするため、複数のビットレートの動画コンテンツの細分化ファイルとこれらの属性情報やＵＲＬを記述したマニフェスト・ファイルを作成し、クライアントに提供する。【０００５】
クライアントは、マニフェスト・ファイルをサーバから取得して、自装置の表示部のサイズや利用可能な通信帯域に応じた最適なビットレートコンテンツを選択し、選択コンテンツを受信して再生する。ネットワーク帯域の変動に応じてビットレートの動的な変更も可能であり、クライアント側では、状況に応じた最適なコンテンツを随時切り替えて受信することが可能となり、映像途切れの発生を低減した動画コンテンツ再生が実現される。なお、アダプティブ（適応型）ストリーミングについては、例えば特許文献１（特開２０１１−８７１０３号公報）に記載がある。【０００６】
放送局やその他のコンテンツサーバ等の送信装置から、テレビ、ＰＣ、携帯端末等の受信装置に対して、放送波等による一方向通信、あるいは、インターネット等のネットワークを介した双方向通信、一方向通信を用いて放送番組等のコンテンツを送受信するシステムについての開発や規格化が、現在、盛んに進められている。
なお、放送波およびネットワークを介したデータ配信を実現するための技術を開示した従来技術として、例えば特許文献２（特開２０１４−０５７２２７号公報）がある。【０００７】
放送波およびネットワークを介したデータ配信システムに関する規格として、現在、ＡＴＳＣ（Ａｄｖａｎｃｅｄ  Ｔｅｌｅｖｉｓｉｏｎ  Ｓｙｓｔｅｍ  Ｃｏｍｍｉｔｔｅｅ）３．０の規格化が進行中である。
ＡＴＳＣ３．０では、ＡＴＳＣ３．０準拠物理層（ＡＴＳＣ−ＰＨＹ）を実装した放送配信用デバイス（チューナ実装デバイス）上に、ＡＴＳＣ３．０放送の受信処理等を実行するミドルウェアを実装させることで、ＡＴＳＣ放送用の制御情報等を含むシグナリングデータを受信して、シグナリングデータによる様々な制御を可能とする構成を検討している。【０００８】
具体的には、シグナリングデータによる制御によって、インターネット等で利用されているアプリケーションプログラム、いわゆるクライアントアプリケーションをそのまま利用して、放送コンテンツの出力処理や、放送波等によって提供される様々なアプリケーションを利用したデータ処理を実現可能とする構成を検討している。【０００９】
例えば、家庭内やホットスポットに設置された放送サービスを受信するサーバ（専用サーバの他、ＰＣ、ＴＶ、タブレット、スマホ等）にＡＴＳＣ３．０準拠物理層（ＡＴＳＣ−ＰＨＹ）、ならびに、ＡＴＳＣ３．０放送受信ミドルウェアを実装する。
これらのサーバが、いったんＡＴＳＣ３．０放送サービスを受信した後、ネットワーク（ホームネットワークやホットスポット等のＬＡＮ／ＷｉＦｉ等）を介して、ユーザ装置（ＰＣ、ＴＶ、タブレット、スマホ等）に放送受信データを転送する。【００１０】
サーバを介して転送された放送受信データを入力したユーザ装置は、ユーザ装置の再生制御部やアプリケーション制御部上で稼働するアプリケーション（例えばＡＴＳＣ３．０  ＤＡＳＨクライアントアプリケーション）を利用して、放送コンテンツの再生や、放送で配信される様々なアプリケーションを実行することが可能となる。【００１１】
この形態では、ＡＴＳＣ３．０放送サービスの制御情報を含むシグナリングデータの解析等を実行するミドルウェアが、シグナリングデータの受信タイミングにおける即時解析処理が可能な終端デバイスとなる。この結果、後段のユーザ装置の再生制御部やアプリケーション制御部は、放送波等によって送信されるシグナリングデータの解析結果に応じた処理を、シグナリングデータの受信タイミングからの遅延を発生させない即時処理として行うことができなくなる場合が発生する。【００１２】
しかし、ミドルウェアが処理を行なったシグナリングデータにアプリケーション制御メッセージが含まれている場合がある。
このメッセージは、後段のアプリケーション制御部において実行されるアプリケーションの制御に利用されるメッセージであり、アプリケーション制御部は、アプリケーション制御メッセージを参照しなければ、正しいアプリケーション制御を行なえなくなるという問題がある。
【先行技術文献】
【特許文献】
【００１３】
【特許文献１】特開２０１１−８７１０３号公報
【特許文献２】特開２０１４−０５７２２７号公報
【発明の概要】
【発明が解決しようとする課題】
【００１４】
本開示は、例えば上記問題点に鑑みてなされたものであり、ＡＴＳＣ３．０放送受信ミドルウェアが受信したシグナリングデータにアプリケーション制御メッセージ等が含まれている場合、これを確実にアプリケーション制御部に出力する構成を実現する受信装置、送信装置、およびデータ処理方法を提供することを目的とする。
【課題を解決するための手段】
【００１５】
本開示の第１の側面は、
アプリケーション制御メッセージをイベントデータとして格納したイベント通知データを受信する通信部と、
イベント通知メッセージにイベントデータとして格納されたアプリケーション制御メッセージに基づくアプリケーション制御を実行するアプリケーション制御部を有する受信装置にある。【００１６】
さらに、本開示の第２の側面は、
アプリケーション制御メッセージを受信する通信部と、
前記アプリケーション制御メッセージをイベントデータとして格納したイベント通知データを生成するミドルウェアと、
前記イベント通知データからアプリケーション制御メッセージを取得して、アプリケーション制御部に出力するデータ処理部と、
前記アプリケーション制御メッセージに基づくアプリケーション制御を実行するアプリケーション制御部を有する受信装置にある。【００１７】
さらに、本開示の第３の側面は、
アプリケーション制御メッセージをイベントデータとして格納したイベント通知データを送信する通信部を有する送信装置にある。【００１８】
さらに、本開示の第４の側面は、
受信装置において実行するデータ処理方法であり、
通信部が、アプリケーション制御メッセージをイベントデータとして格納したイベント通知データを受信し、
アプリケーション制御部が、イベント通知メッセージにイベントデータとして格納されたアプリケーション制御メッセージに基づくアプリケーション制御を実行するデータ処理方法にある。【００１９】
さらに、本開示の第５の側面は、
受信装置において実行するデータ処理方法であり、
通信部が、アプリケーション制御メッセージを受信し、
ミドルウェアが、アプリケーション制御メッセージをイベントデータとして格納したイベント通知データを生成し、
データ処理部が、前記イベント通知データからアプリケーション制御メッセージを取得して、アプリケーション制御部に出力し、
アプリケーション制御部が、前記アプリケーション制御メッセージに基づくアプリケーション制御を実行するデータ処理方法にある。【００２０】
さらに、本開示の第６の側面は、
送信装置において実行するデータ処理方法であり、
通信部が、アプリケーション制御メッセージをイベントデータとして格納したイベント通知データを送信するデータ処理方法にある。【００２１】
本開示のさらに他の目的、特徴や利点は、後述する本開示の実施例や添付する図面に基づくより詳細な説明によって明らかになるであろう。なお、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。
【発明の効果】
【００２２】
本開示の一実施例の構成によれば、アプリケーション制御メッセージを適用したアプリケーション制御を確実に実行可能とした構成が実現される。
具体的には、送信装置が受信装置にアプリケーション制御メッセージ（ＡＣＭ）をイベントデータとして格納したイベント通知データを送信する。受信装置のアプリケーション制御部は、イベント通知メッセージにイベントデータとして格納されたＡＣＭに基づくアプリケーション制御を実行する。イベント通知データは、シグナリングデータであるＭＰＤ、または、ＡＶコンテンツの送信用データであるセグメント内に格納され、受信装置はＭＰＤ、またはセグメントからＡＣＭを取得して迅速なアプリケーション制御を行うことができる。
本構成により、アプリケーション制御メッセージを適用したアプリケーション制御を確実に実行可能とした構成が実現される。
なお、本明細書に記載された効果はあくまで例示であって限定されるものではなく、また付加的な効果があってもよい。
【図面の簡単な説明】
【００２３】
【図１】本開示の処理を実行する通信システムの一構成例について説明する図である。
【図２】送信装置の送信データについて説明する図である。
【図３】送信装置および受信装置のプロトコルスタックの例を示す図である。
【図４】ＲＯＵＴＥ／ＦＬＵＴＥプロトコルスタックについて説明する図である。
【図５】受信装置の構成例について説明する図である。
【図６】受信装置の構成例について説明する図である。
【図７】ＭＰＤの構成例について説明する図である。
【図８】ＭＰＤの構成例について説明する図である。
【図９】イベント通知ＭＰＤの構成例について説明する図である。
【図１０】ＭＰＤの利用シーケンス例について説明する図である。
【図１１】イベント情報の生成、送信、利用シーケンスについて説明する図である。
【図１２】イベント情報を格納するセグメントの構成について説明する図である。
【図１３】イベント情報を格納したセグメント内のデータ構成例について説明する図である。
【図１４】イベント情報の生成、送信、利用シーケンスについて説明する図である。
【図１５】アプリケーション制御メッセージ（ＡＣＭ）の構成例について説明する図である。
【図１６】アプリケーション制御メッセージ（ＡＣＭ）を格納したＭＰＤの例について説明する図である。
【図１７】ＭＰＤに格納されるアプリケーション制御メッセージ（ＡＣＭ）の例について説明する図である。
【図１８】アプリケーション制御メッセージ（ＡＣＭ）を格納したセグメント（ＭＰ４規定のｅｍｓｇボックス）の例について説明する図である。
【図１９】アプリケーション制御メッセージ（ＡＣＭ）の生成、送信、利用シーケンスについて説明する図である。
【図２０】アプリケーション制御メッセージ（ＡＣＭ）の生成、送信、利用シーケンスについて説明する図である。
【図２１】アプリケーション制御メッセージ（ＡＣＭ）の生成、送信、利用シーケンスについて説明する図である。
【図２２】アプリケーション制御メッセージ（ＡＣＭ）の生成、送信、利用シーケンスについて説明する図である。
【図２３】通信装置である送信装置と受信装置の構成例について説明する図である。
【図２４】通信装置である送信装置と受信装置のハードウェア構成例について説明する図である。
【発明を実施するための形態】
【００２４】
以下、図面を参照しながら本開示の受信装置、送信装置、およびデータ処理方法の詳細について説明する。なお、説明は以下の項目に従って行なう。
１．通信システムの構成例について
２．データ通信プロトコルＦＬＵＴＥ、およびＲＯＵＴＥについて
３．送信装置と受信装置の実行する通信処理例について
４．受信装置の構成例と処理例について
５．アプリケーション制御メッセージの転送処理について
６．イベント通知構成について
６−１．ＭＰＤ適用イベント通知方式（＝ＭＰＤ  Ｅｖｅｎｔ）について
６−２．セグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）について
７．アプリケーション制御メッセージの通知処理について
７−１．イベント通知機構を利用したアプリケーション制御メッセージ通知構成の概要
７−２．ＭＰＤ適用イベント通知方式（＝ＭＰＤ  Ｅｖｅｎｔ）を適用したアプリケーション制御メッセージの通知構成
７−３．セグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）を適用したアプリケーション制御メッセージの通知構成
８．アプリケーション制御メッセージ（ＡＣＭ）の通知、利用シーケンスについて
８−１．ＭＰＤ適用イベント通知方式（＝ＭＰＤ  Ｅｖｅｎｔ）を適用したアプリケーション制御メッセージの送信および利用シーケンスについて
８−２．セグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）を適用したアプリケーション制御メッセージの送信および利用シーケンスについて
９．チューナ非実装受信装置を利用した場合の処理例について
９−１．ＭＰＤ適用イベント通知方式（＝ＭＰＤ  Ｅｖｅｎｔ）を適用したアプリケーション制御メッセージの送信および利用シーケンスについて
９−２．セグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）を適用したアプリケーション制御メッセージの送信および利用シーケンスについて
１０．送信装置と受信装置の構成例について
１１．本開示の構成のまとめ
【００２５】
［１．通信システムの構成例について］
まず、図１を参照して本開示の処理を実行する通信システムの一構成例について説明する。
図１に示すように、通信システム１０は、画像データや音声データ等のコンテンツを送信する通信装置である送信装置２０と、送信装置２０の送信するコンテンツを放送波やネットワークを介して受信する通信装置であるチューナ実装受信装置３０と、送信装置２０の送信するコンテンツをチューナ実装受信装置３０、ネットワークを介して受信するチューナ非実装受信装置４０を有する。
【００２６】
送信装置２０は、具体的には、例えば放送局２１やコンテンツサーバ２２等、コンテンツを提供する装置である。
チューナ実装受信装置３０は、放送波を受信するためのチューナを備えた受信装置である。例えば一般ユーザのクライアント装置やホームサーバ、公共施設に設置された中継サーバ等である。具体的には、例えば、中継サーバ（ホームサーバ等を含む）３１、テレビ３２、ＰＣ３３、携帯端末３４等である。
また、チューナ非実装受信装置４０は、放送波を受信するためのチューナを備えていない受信装置である。具体的には、例えば、ＰＣ４１、携帯端末４２等である。
【００２７】
送信装置２０とチューナ実装受信装置３０間のデータ通信は、インターネット等のネットワークを介した双方向通信、一方向通信、あるいは、放送波等による一方向通信の少なくともいずれか、あるいは両者を利用した通信として行われる。
【００２８】
送信装置２０からチューナ実装受信装置３０に対するコンテンツ送信は、例えばアダプティブ（適応型）ストリーミング技術の規格であるＤＡＳＨ（ＭＰＥＧ−ＤＡＳＨ）規格に従って実行する。
なお、ＤＡＳＨ（Ｄｙｎａｍｉｃ  Ａｄａｐｔｉｖｅ  Ｓｔｒｅａｍｉｎｇ  ｏｖｅｒＨＴＴＰ）規格は、前述したようにＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）をベースとしたストリーミングプロトコルを用いたアダプティブ（適応型）ストリーミング配信に関する規格である。
【００２９】
ＭＰＥＧ−ＤＡＳＨ規格には、以下の２つの規格が含まれる。
（ａ）動画や音声ファイルの管理情報であるメタデータを記述するためのマニフェスト・ファイル（ＭＰＤ：Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）に関する規格、
（ｂ）動画コンテンツ伝送用のファイル・フォーマット（セグメント・フォーマット）に関する規格、
送信装置２０から、チューナ実装受信装置３０に対するコンテンツ配信は、上記のＭＰＥＧ−ＤＡＳＨ規格に従って実行される。
【００３０】
チューナ実装受信装置３０が受信したコンテンツは、ネットワーク（家庭内ならホームネットワーク（ＬＡＮ／ＷｉＦｉ等）、ホットスポットならＷｉＦｉ等）を介して、チューナ非実装受信装置４０に転送される。
チューナ実装受信装置３０や、チューナ非実装受信装置４０は、送信装置２０の送信したコンテンツの再生を行なうことができる。
【００３１】
送信装置２０は、コンテンツデータを符号化し、符号化データおよび符号化データのメタデータを含むデータファイルを生成する。符号化処理は、例えばＭＰＥＧにおいて規定されるＭＰ４ファイルフォーマットに従って行われる。なお、送信装置２０がＭＰ４形式のデータファイルを生成する場合の符号化データのファイルは「ｍｄａｔ」、メタデータは「ｍｏｏｖ」や「ｍｏｏｆ」等と呼ばれる。
【００３２】
送信装置２０がチューナ実装受信装置３０に提供するコンテンツは、例えば音楽データや、映画、テレビ番組、ビデオ、写真、文書、絵画および図表などの映像データや、ゲームおよびソフトウェアなど、様々なデータである。
【００３３】
送信装置２０の送信データについて図２を参照して説明する。
ＭＰＥＧ−ＤＡＳＨ規格に従ってデータ送信を実行する送信装置２０は、図２に示すように、大きく分けて以下の複数種類のデータの送信を行う。
（ａ）シグナリングデータ５０
（ｂ）ＡＶセグメント６０
（ｃ）その他のデータ（ＥＳＧ，ＮＲＴコンテンツ等）７０
【００３４】
ＡＶセグメント６０は、受信装置において再生する画像（Ｖｉｄｅｏ）や、音声（Ａｕｄｉｏ）データ、すなわち例えば放送局の提供する番組コンテンツ等によって構成される。例えば、上述したＭＰ４符号化データ（ｍｄａｔ）や、メタデータ（ｍｏｏｖ，ｍｏｏｆ）によって構成される。なお、ＡＶセグメントは、ＤＡＳＨセグメントとも呼ばれる。
【００３５】
一方、シグナリングデータ５０は、番組表等の番組予定情報や、番組取得に必要となるアドレス情報（ＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）等）、さらにコンテンツの再生処理に必要な情報、例えばコーデック情報（符号化方式など）などからなる案内情報、アプリケーション制御情報等の様々な制御情報によって構成される。
チューナ実装受信装置３０は、このシグナリングデータ５０を、再生対象となる番組コンテンツを格納したＡＶセグメント６０の受信に先行して受信することが必要となる。
このシグナリングデータ５０は、例えばＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）形式のデータとして送信装置２０から送信される。
【００３６】
シグナリングデータは、随時、繰り返し送信される。例えば１００ｍｓｅｃ毎など、頻繁に繰り返し送信される。
これは、受信装置（クライアント）が、いつでも、即座にシグナリングデータを取得することを可能とするためである。
クライアント（受信装置）は、随時、受信可能なシグナリングデータに基づいて、必要な番組コンテンツのアクセス用アドレスの取得や、コーデック設定処理など、番組コンテンツの受信および再生に必要な処理を遅滞なく実行することが可能となる。
【００３７】
その他のデータ７０は、例えばＥＳＧ（Ｅｌｅｃｔｒｏｎｉｃ  Ｓｅｒｖｉｃｅ  Ｇｕｉｄｅ）、ＮＲＴコンテンツ等が含まれる。
ＥＳＧは、電子サービスガイド（Ｅｌｅｃｔｒｏｎｉｃ  Ｓｅｒｖｉｃｅ  Ｇｕｉｄｅ）であり、例えば番組表等の案内情報である。
ＮＲＴコンテンツはノンリアルタイム型のコンテンツである。
【００３８】
ＮＲＴコンテンツには、例えば、クライアントである受信装置３０のブラウザ上で実行される様々なアプリケーションファイル、動画、静止画等のデータファイル等が含まれる。
【００３９】
図２に示す以下のデータ、すなわち、
（ａ）シグナリングデータ５０
（ｂ）ＡＶセグメント６０
（ｃ）その他のデータ（ＥＳＧ，ＮＲＴコンテンツ等）７０
これらのデータは、例えば、データ通信プロトコル：ＦＬＵＴＥ（Ｆｉｌｅ  Ｄｅｌｉｖｅｒｙ  ｏｖｅｒ  Ｕｎｉ−ｄｉｒｅｃｔｉｏｎａｌ  Ｔｒａｎｓｐｏｒｔ）に従って送信される。
【００４０】
［２．データ通信プロトコルＦＬＵＴＥ、およびＲＯＵＴＥについて］
データ通信プロトコル：ＦＬＵＴＥ（Ｆｉｌｅ  Ｄｅｌｉｖｅｒｙ  ｏｖｅｒ  Ｕｎｉ−ｄｉｒｅｃｔｉｏｎａｌ  Ｔｒａｎｓｐｏｒｔ）はマルチキャストにより伝送するコンテンツのセッション管理を行うプロトコルである。
例えば送信装置であるサーバ側で生成されるファイル（ＵＲＬとバージョンで識別される）は、ＦＬＵＴＥプロトコルに従って、受信装置であるクライアントに送信される。
【００４１】
チューナ実装受信装置（クライアント）３０は、例えば記憶部（クライアントキャッシュ）に、受信ファイルのＵＲＬおよびバージョンとファイルを対応付けて蓄積する。
同じＵＲＬでバージョンが異なるものはファイルの中身が更新されているものとみなす。ＦＬＵＴＥプロトコルは一方向ファイル転送制御のみを行うもので、クライアントにおけるファイルの選択的なフィルタリング機能はないが、ＦＬＵＴＥで転送制御するファイルをそのファイルに紐づけられるメタデータを利用して、クライアント側で取捨選択することにより、選択的なフィルタリングを実現し、ユーザの嗜好を反映したローカルキャッシュを構成・更新管理することが可能となる。
なお、メタデータは、ＦＬＵＴＥプロトコルに拡張して組み込むこともできるし、別途ＥＳＧ（Ｅｌｅｃｔｒｏｎｉｃ  Ｓｅｒｖｉｃｅ  Ｇｕｉｄｅ）等のプロトコルで記述することもできる。
【００４２】
なお、ＦＬＵＴＥは、当初マルチキャストにおけるファイル転送プロトコルとして仕様化された。ＦＬＵＴＥは、ＦＤＴと、ＡＬＣと呼ばれるスケーラブルなファイルオブジェクトのマルチキャストプロトコル、具体的にはそのビルディングブロックであるＬＣＴやＦＥＣコンポーネント、の組み合わせにより構成される。
【００４３】
従来のＦＬＵＴＥは、主に非同期型のファイル転送に利用するために開発されたが、現在、放送波およびネットワークを介したデータ配信システムに関する規格化団体であるＡＴＳＣ（Ａｄｖａｎｃｅｄ  Ｔｅｌｅｖｉｓｉｏｎ  Ｓｙｓｔｅｍ  Ｃｏｍｍｉｔｔｅｅ）において、ブロードキャストライブストリーミングにも適用しやすくするための拡張を行っている。このＦＬＵＴＥの拡張仕様がＲＯＵＴＥ（Ｒｅａｌ−Ｔｉｍｅ  Ｏｂｊｅｃｔ  Ｄｅｌｉｖｅｒｙ  ｏｖｅｒ  Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ  Ｔｒａｎｓｐｏｒｔ）と呼ばれる。
【００４４】
放送波およびネットワークを介したデータ配信システムに関する規格の１つとして現在、標準化が進められている規格としてＡＴＳＣ（Ａｄｖａｎｃｅｄ  Ｔｅｌｅｖｉｓｉｏｎ  Ｓｙｓｔｅｍ  Ｃｏｍｍｉｔｔｅｅ）３．０がある。このＡＴＳＣ３．０は、ＲＯＵＴＥを従来のＦＬＵＴＥプロトコルに置き換えて、シグナリングデータや、ＥＳＧ、あるいは非同期ファイル、同期型ストリーム等の送信に採用したスタック構成を規定している。
【００４５】
［３．送信装置と受信装置の実行する通信処理例について］
次に、送信装置と受信装置の実行する通信処理例について説明する。
図３は、送信装置および受信装置のプロトコルスタックの例を示す図である。
図３に示す例は、以下の２つの通信データの処理を行なうための２つのプロトコルスタックを有する。
（ａ）ブロードキャスト（マルチキャストも含む）通信（例えば放送型データ配信）
（ｂ）ユニキャスト（ブロードバンド）通信（例えばＨＴＴＰ型のＰ２Ｐ通信）
【００４６】
図３の左側が（ａ）ブロードキャスト通信（例えば放送型データ配信）に対応するプロトコルスタックである。
図３の右側が、（ｂ）ユニキャスト（ブロードバンド）通信（例えばＨＴＴＰ型のＰ２Ｐ通信）に対応するプロトコルスタックである。
【００４７】
図３左側に示す（ａ）ブロードキャスト通信（例えば放送型データ配信）に対応するプロトコルスタックは、下位レイヤから順に、以下のレイヤを持つ。
（１）ブロードキャスト物理レイヤ（Ｂｒｏａｄｃａｓｔ  ＰＨＹ）
（２）ＩＰマルチキャストレイヤ（ＩＰ  Ｍｕｌｔｉｃａｓｔ）
（３）ＵＤＰレイヤ
（４）ＲＯＵＴＥ（＝拡張型ＦＬＵＴＥ）レイヤ
（５）ＥＳＧ，ＮＲＴｃｏｎｔｅｎｔ，ＤＡＳＨ（ＩＳＯ  ＢＭＦＦ）およびＶｉｄｅｏ／Ａｕｄｉｏ／ＣＣ
（６）アプリケーションレイヤ（Ａｐｐｌｉｃａｔｉｏｎｓ（ＨＴＭＬ５））
【００４８】
なお、（２）ＩＰマルチキャストレイヤ（ＩＰ  Ｍｕｌｔｉｃａｓｔ）の上位レイヤとしてシグナリング（Ｓｉｇｎａｌｉｎｇ）レイヤが設定される。
シグナリングレイヤは、先に図２を参照して説明したシグナリングデータ５０の送受信に適用されるレイヤである。シグナリングデータには、番組表等の番組予定情報や、番組取得に必要となるアドレス情報（ＵＲＬ等）、さらにコンテンツの再生処理に必要な情報、例えばコーデック情報（符号化方式など）などからなる案内情報、制御情報などが含まれる。
【００４９】
シグナリングデータは、受信装置（クライアント）が受信、再生するＡＶセグメントのアクセス情報や、復号処理等の受信後の処理に必要となる案内情報や制御情報を含むデータであり、送信装置から随時繰り返し送信されるデータである。
【００５０】
シグナリングデータには、情報に応じた様々な種類がある。具体的には、例えば、サービス単位のシグナリングデータであるＵＳＤ（ユーザサービスディスクリプション（Ｕｓｅｒ  Ｓｅｒｖｉｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ））がある。
ＵＳＤには、様々な種類の制御情報が含まれる。代表的な制御情報として、コンテンツ（ＡＶセグメント）に対応する様々な案内情報、制御情報を格納したマニフェスト・ファイルを持つシグナリングデータであるＭＰＤ（メディアプレゼンテーションディスクリプション（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ））がある。
【００５１】
各種のシグナリングデータは、それぞれ受信装置（クライアント）において、送信装置から送信されるＡＶセグメントやアプリケーション（アプリケーションプログラム）の受信、再生処理、制御処理に必要となるデータであり、例えばカテゴリ別に個別のファイル（メタファィル）として設定され、送信装置から送信される。
【００５２】
なお、（１）ブロードキャスト物理レイヤ（Ｂｒｏａｄｃａｓｔ  ＰＨＹ）の上位レイヤとして将来の新たなプロトコルの利用許容レイヤ（Ｆｕｔｕｒｅ  Ｅｘｔｅｎｓｉｂｉｌｉｔｙ）が設定されている。
【００５３】
（１）ブロードキャスト物理レイヤ（Ｂｒｏａｄｃａｓｔ  ＰＨＹ）は、ブロードキャスト通信を実行するための例えば放送系の通信部を制御する通信制御部によって構成される物理レイヤである。
（２）ＩＰマルチキャストレイヤ（ＩＰ  Ｍｕｌｔｉｃａｓｔ）は、ＩＰマルチキャストに従ったデータ送受信処理を実行するレイヤである。
（３）ＵＤＰレイヤは、ＵＤＰパケットの生成、解析処理レイヤである。
【００５４】
（４）ＲＯＵＴＥレイヤは、拡張型ＦＬＵＴＥプロトコルであるＲＯＵＴＥプロトコルにしたがって転送データの格納や取り出しを行うレイヤである。
ＲＯＵＴＥは、ＦＬＵＴＥと同様、ＡＬＣと呼ばれるスケーラブルなファイルオブジェクトのマルチキャストプロトコルであり、具体的にはそのビルディングブロックであるＬＣＴやＦＥＣコンポーネントの組み合わせにより構成される。
図４に、ＲＯＵＴＥ、およびＦＬＵＴＥに関するプロトコルスタックを示す。
【００５５】
（５）ＥＳＧ，ＮＲＴｃｏｎｔｅｎｔ，ＤＡＳＨ（ＩＳＯ  ＢＭＦＦ）およびＶｉｄｅｏ／Ａｕｄｉｏ／ＣＣは、ＲＯＵＴＥプロトコルに従って転送されるデータである。
【００５６】
ＤＡＳＨ規格に従った同報型配信サービスは、ＭＢＭＳ（Ｍｕｌｔｉｍｅｄｉａ  Ｂｒｏａｄｃａｓｔ  Ｍｕｌｔｉｃａｓｔ  Ｓｅｒｖｉｃｅ）と呼ばれる。このＭＢＭＳをＬＴＥで効率的に実現させる方式としてｅＭＢＭＳ（ｅｖｏｌｖｅｄ  Ｍｕｌｔｉｍｅｄｉａ  Ｂｒｏａｄｃａｓｔ  Ｍｕｌｔｉｃａｓｔ  Ｓｅｒｖｉｃｅ）がある。
ＭＢＭＳやｅＭＢＭＳは、同報型配信サービスであり、特定のエリア内に位置する受信装置である複数のユーザ端末（ＵＥ）に対して共通のベアラで一斉に同一データ、例えば映画コンテンツなどを配信するサービスである。ＭＢＭＳやｅＭＢＭＳに従った同報配信により、配信サービス提供エリアに位置する多数のスマホやＰＣ、あるいはテレビ等の受信装置に、同じコンテンツを同時に提供することができる。
【００５７】
ＭＢＭＳ、およびｅＭＢＭＳは、３ＧＰＰファイルフォーマット（ＩＳＯ−ＢＭＦＦファイル、ＭＰ４ファイル）に従ったファイルを、転送プロトコルＲＯＵＴＥ、またはＦＬＵＴＥに従ってダウンロードする処理について規定している。
【００５８】
先に図２を参照して説明した以下のデータ、すなわち、
（ａ）シグナリングデータ５０
（ｂ）ＡＶセグメント６０
（ｃ）その他のデータ（ＥＳＧ、ＮＲＴコンテンツ等）７０
これらのデータの多くはＲＯＵＴＥプロトコル、またはＦＬＵＴＥプロトコルに従って送信される。
【００５９】
（５）ＥＳＧ，ＮＲＴｃｏｎｔｅｎｔ，ＤＡＳＨ（ＩＳＯ  ＢＭＦＦ）およびＶｉｄｅｏ／Ａｕｄｉｏ／ＣＣは、ＲＯＵＴＥプロトコルに従って転送されるデータである。
【００６０】
ＥＳＧは、電子サービスガイド（Ｅｌｅｃｔｒｏｎｉｃ  Ｓｅｒｖｉｃｅ  Ｇｕｉｄｅ）であり、例えば番組表等の案内情報である。
【００６１】
ＮＲＴｃｏｎｔｅｎｔはノンリアルタイム型のコンテンツである。
前述したように、ＮＲＴコンテンツには、例えば、クライアントである受信装置のブラウザ上で実行される様々なアプリケーションファイル、動画、静止画等のデータファイル等が含まれる。
Ｖｉｄｅｏ／Ａｕｄｉｏ／ＣＣは、ＤＡＳＨ規格に従って配信されるビデオやオーディオ等、再生対象となる実データである。
【００６２】
（６）アプリケーションレイヤ（Ａｐｐｌｉｃａｔｉｏｎｓ（ＨＴＭＬ５））は、ＲＯＵＴＥプロトコルに従って転送するデータの生成、あるいは解析、その他、様々なデータの出力制御等を実行するアプリケーションレイヤであり、例えばＨＴＭＬ５を適用したデータ生成、解析、出力処理等を行う。
【００６３】
一方、図３の右側に示す、（ｂ）ユニキャスト（ブロードバンド）通信（例えばＨＴＴＰ型のＰ２Ｐ通信）に対応するプロトコルスタックは、下位レイヤから順に、以下のレイヤを持つ。
（１）ブロードバンド物理レイヤ（Ｂｒｏａｄｂａｎｄ  ＰＨＹ）
（２）ＩＰユニキャストレイヤ（ＩＰ  Ｕｎｉｃａｓｔ）
（３）ＴＣＰレイヤ
（４）ＨＴＴＰレイヤ
（５）ＥＳＧ，Ｓｉｇｎａｌｉｎｇ，ＮＲＴｃｏｎｔｅｎｔ，ＤＡＳＨ（ＩＳＯ  ＢＭＦＦ）およびＶｉｄｅｏ／Ａｕｄｉｏ／ＣＣ
（６）アプリケーションレイヤ（Ａｐｐｌｉｃａｔｉｏｎｓ（ＨＴＭＬ５））
【００６４】
（１）ブロードバンド物理レイヤ（Ｂｒｏａｄｂａｎｄ  ＰＨＹ）は、ブロードバンド通信を実行する例えばネットワークカード等の通信部を制御するデバイスドライバ等の通信制御部によって構成される物理レイヤである。
（２）ＩＰユニキャストレイヤ（ＩＰ  Ｕｎｉｃａｓｔ）は、ＩＰユニキャスト送受信処理を実行するレイヤである。
（３）ＨＴＴＰレイヤは、ＨＴＴＰパケットの生成、解析処理レイヤである。
この上位レイヤは、図３左側の（ａ）ブロードキャスト通信（例えば放送型データ配信）のスタック構成と同様である。
【００６５】
なお、送信装置（サーバ）２０、チューナ実装受信装置（クライアント）３０は、図３の２つの処理系、すなわち、
（ａ）ブロードキャスト通信（例えば放送型データ配信）
（ｂ）ユニキャスト（ブロードバンド）通信（例えばＨＴＴＰ型のＰ２Ｐ通信）
これら２つの通信プロトコルスタックの少なくともいずれかに従った処理を行なう。
【００６６】
また、チューナ非実装受信装置（クライアント）４０は、チューナ実装受信装置（クライアント）３０との通信処理として、図３の右側の処理系、すなわち、
（ｂ）ユニキャスト（ブロードバンド）通信（例えばＨＴＴＰ型のＰ２Ｐ通信）
この通信プロトコルスタックに従った通信処理を実行する。
【００６７】
図３に示すプロトコルスタックにおいて、ＲＯＵＴＥ（ＦＬＵＴＥ）に従ってマルチキャスト転送されるファイル群の属性（ファイルの識別子であるＵＲＬを含む）は、ＲＯＵＴＥ（ＦＬＵＴＥ）の制御ファイル内に記述することもできれば、ファイル転送セッションを記述するシグナリング（Ｓｉｇｎａｌｉｎｇ）データ中に記述することもできる。また、ファイル転送セッションのさらなる詳細属性を（エンドユーザへの提示用途にも適用可能な）ＥＳＧにより記述することもできる。
【００６８】
前述したように、放送波およびネットワークを介したデータ配信システムに関する規格の１つとしてＡＴＳＣ（Ａｄｖａｎｃｅｄ  Ｔｅｌｅｖｉｓｉｏｎ  Ｓｙｓｔｅｍ  Ｃｏｍｍｉｔｔｅｅ）３．０の規格化が進められている。
ＡＴＳＣ３．０におけるＩＰベースのトランスポートスタックの標準化において、ＭＰＥＧ−ＤＡＳＨのファイルフォーマット（ＩＳＯ−ＢＭＦＦファイル、ＭＰ４ファイル）に基づくファイルをＦＬＵＴＥ（Ｆｉｌｅ  Ｄｅｌｉｖｅｒｙ  ｏｖｅｒ  Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ  Ｔｒａｎｓｐｏｒｔ）を拡張したＲＯＵＴＥ（Ｒｅａｌ−Ｔｉｍｅ  Ｏｂｊｅｃｔ  Ｄｅｌｉｖｅｒｙ  ｏｖｅｒ  Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ  Ｔｒａｎｓｐｏｒｔ）プロトコルにより転送する方法が提案され、標準候補方式として設定された。
【００６９】
ＲＯＵＴＥプロトコルを適用することで、ＤＡＳＨ規格のフラグメント化されたＭＰ４（ｆｒａｇｍｅｎｔｅｄ  ＭＰ４）ファイルシーケンスと、ＤＡＳＨ規格の制御情報（シグナリングデータ）格納メタファイルであるＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ））、ならびに、放送配信のためのシグナリングデータであるＵＳＢＤ／ＵＳＤ、Ｓ−ＴＳＩＤ（Ｓｅｒｖｉｃｅ  ｂａｓｅｄ  Ｔｒａｎｓｐｏｒｔ  Ｓｅｓｓｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）等を転送することができる。
【００７０】
前述したように、ＲＯＵＴＥプロトコルはＦＬＵＴＥをベースとするプロトコルである。ＦＬＵＴＥにおける転送制御パラメータを記述したメタデータファイルをＦＤＴ（Ｆｉｌｅ  Ｄｅｌｉｖｅｒｙ  Ｔａｂｌｅ）と呼び、ＲＯＵＴＥにおける転送制御パラメータを記述したメタデータファイルをＳ−ＴＳＩＤ（Ｓｅｒｖｉｃｅ  ｂａｓｅｄ  Ｔｒａｎｓｐｏｒｔ  Ｓｅｓｓｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）と呼ぶ。Ｓ−ＴＳＩＤはＦＤＴのスーパーセットでありＦＤＴを含む。
【００７１】
ＡＴＳＣ３．０サービスレイヤのシグナリングデータ（ＳＬＳ：Ｓｅｒｖｉｃｅ  Ｌａｙｅｒ  Ｓｉｇｎａｌｉｎｇ）として提案されているＵＳＢＤ／ＵＳＤ、Ｓ−ＴＳＩＤ、ＭＰＤ等はすべてＲＯＵＴＥセッションにより転送される。
【００７２】
［４．受信装置の構成例と処理例について］
次に、図５以下を参照してチューナ実装受信装置（クライアントＡ）３０と、チューナ非実装受信装置（クライアントＢ）４０の構成例と処理例について説明する。
放送サーバ２１は、放送波や、ネットワークを介したブロードキャスト送信により、放送コンテンツ等からなるＡＶセグメント、シグナリングデータ、その他のデータを送信する。
図には示していないが、放送サーバ２１以外の送信装置であるデータ配信サーバ２２もネットワークを介したブロードキャスト送信により、放送コンテンツ等からなるＡＶセグメント、シグナリングデータ、その他のデータを送信する。
【００７３】
図５に示すように、チューナ実装受信装置３０はミドルウェア１１０、ＨＴＴＰプロキシサーバ１２０、再生制御部（ＤＡＳＨクライアント）１３１、出力制御部１３２、アプリケーション制御部１４０を有する。
【００７４】
ミドルウェア１１０は、放送サーバ２１の提供データを受信し、解析する。
ミドルウェア１１０は、通信部（ＰＨＹ／ＭＡＣ）１１１、シグナリングデータを取得するシグナリング取得部１１２、シグナリングデータを解析するシグナリング解析部１１３、シグナリングデータ、および、映像、音声等の番組コンテンツデータや、アプリケーション等のＮＲＴコンテンツ等のデータファイルを取得するセグメント取得部１１４を有する。
【００７５】
さらに、放送番組や送信データの変更や詳細等の通知情報、受信装置において実行するアプリケーションに関する情報、受信装置において必要となる処理の情報などを含むイベント情報をシグナリングデータ、あるいはＡＶデータを格納したセグメント内に挿入する処理を実行するイベント挿入部１１５を有する。
【００７６】
イベント情報とは、例えば、番組表の変更や、放送コンテンツのデータ態様の変更、受信装置における放送コンテンツの再生時に実行すベき処理など、受信装置に対して通知すべき情報、何らかの処理の実行を要求するための情報などである。
【００７７】
ミドルウェア１１０は、さらに、受信装置において実行するための様々なアプリケーション（アプリケーションプログラム）を格納したアプリケーションファイルを取得するアプリケーションファイル取得部１１６を有する。
【００７８】
アプリケーションは、例えば、放送番組に重畳表示する天気情報やニュース情報、あるいは野球中継の場合の選手情報など、様々な情報表示を行うためのアプリケーションである。
アプリケーションの具体例としては、例えば、以下のようなものがある。
放送コンテンツが観光地の案内映像からなるコンテンツである場合に、その放送コンテンツに重畳表示するための地図情報、ホテル情報等を表示するためのアプリケーション。
放送コンテンツが野球中継である場合、各選手の打率、ホームラン数等の成績情報を表示するアプリケーション。
視聴者に対するクイズやアンケートを表示して、双方向通信を利用して視聴者からの回答を回収するためのアプリケーション。
この他にも、ユーザに応じて提供される広告表示など様々なアプリケーションがある。
【００７９】
ミドルウェア１１０が受信したデータは、プロキシサーバ１２０のキャッシュ部（プロキシキャッシュ）１２１に格納される。プロキシサーバ１２０は、さらにネットワーク経由でデータ配信サーバ２２から取得したデータをキャッシュ部（プロキシキャッシュ）１２２に格納する。
プロキシサーバ１２０は、出力制御部１３０からのデータ要求をアドレス解決部１２３に入力し、要求されたデータをキャッシュ部（プロキシキャッシュ）１２１，１２２、または外部から取得して提供する。
【００８０】
再生制御部（ＤＡＳＨ  Ｃｌｉｅｎｔ）１３１は、ＤＡＳＨ（ＭＰＥＧ−ＤＡＳＨ）規格に従って送信されたコンテンツの再生制御を実行する。
前述したように、ＭＰＥＧ−ＤＡＳＨ規格には、以下の２つの規格が含まれる。
（ａ）動画や音声ファイルの管理情報であるメタデータを記述するためのマニフェスト・ファイル（ＭＰＤ：Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）に関する規格、
（ｂ）動画コンテンツ伝送用のファイル・フォーマット（セグメント・フォーマット）に関する規格、
送信装置２０から、チューナ実装受信装置３０に対するコンテンツ配信は、上記のＭＰＥＧ−ＤＡＳＨ規格に従って実行される。
【００８１】
コンテンツは、例えばＭＰＥＧにおいて規定されるＭＰ４ファイルフォーマットに従って所定単位の分割データであるセグメントとして送信され、再生制御部（ＤＡＳＨ  Ｃｌｉｅｎｔ）１３１は、マニフェスト・ファイル（ＭＰＤ）を参照して、再生対象コンテンツを格納したセグメントを取得する処理等を実行する。
【００８２】
出力制御部１３２は、再生制御部の取得したセグメントから符号化コンテンツを取り出して復号し、表示部等の出力部に出力する。
【００８３】
アプリケーション制御部１４０は、前述した天気予報、ニュース、野球中継時の選手情報、旅番組における地図情報、ホテル情報、クイズ、アンケート処理等を実行する様々なアプリケーションの取得や、アプリケーションの開始、終了等のアプリケーション制御を実行する。
【００８４】
さらに、図５に示すチューナ非実装受信装置（クライアントＢ）４０は、例えばイーサネット（登録商標）やＷｉ−Ｆｉ等のネットワークによって、チューナ実装受信装置（クライアントＡ）３０と接続され、チューナ実装受信装置（クライアントＡ）３０との通信を実行する。
チューナ非実装受信装置（クライアントＢ）４０は、チューナ実装受信装置（クライアントＡ）３０が、放送サーバ２１や、データ配信サーバ２２から受信したコンテンツ等のデータを、チューナ実装受信装置（クライアントＡ）３０を介して受信し、コンテンツ再生を実行する。
【００８５】
図５に示すチューナ非実装受信装置（クライアントＢ）４０は、
再生制御部（ＤＡＳＨ  Ｃｌｉｅｎｔ）１５１、
出力制御部１５２、
アプリケーション制御部１６０、
これらの構成を有する。
これらの構成、機能は、チューナ実装受信装置（クライアントＡ）３０において説明した再生制御部（ＤＡＳＨ  Ｃｌｉｅｎｔ）１３１、出力制御部１３２、アプリケーション制御部１４０と同様である。
【００８６】
図６は、チューナ実装受信装置（クライアントＡ）３０の有する、
再生制御部（ＤＡＳＨ  Ｃｌｉｅｎｔ）１３１、
出力制御部１３２と、
チューナ非実装受信装置（クライアントＢ）４０の有する、
再生制御部（ＤＡＳＨ  Ｃｌｉｅｎｔ）１５１、
出力制御部１５２、
これらの詳細構成を示す図である。
【００８７】
チューナ実装受信装置（クライアントＡ）３０の再生制御部（ＤＡＳＨ  Ｃｌｉｅｎｔ）１３１は、ＭＰＤ取得部２０１、ＭＰＤ解析部２０２、セグメント取得部２０３、セグメント（ＭＰ４）解析部２０４、さらにイベント抽出部２０５を有する。
【００８８】
再生制御部（ＤＡＳＨ  Ｃｌｉｅｎｔ）１３１は、前述したように、ＤＡＳＨ（ＭＰＥＧ−ＤＡＳＨ）規格に従って送信されたコンテンツの再生制御を実行する。
ＭＰＤ取得部２０１は、動画や音声ファイルの管理情報記述ファイルであるマニフェスト・ファイル（ＭＰＤ：Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）を取得する。
ＭＰＤは、放送サーバ２１、データ配信サーバ２２から提供され、プロキシサーバ１２０に格納された後、再生制御部１３１が取得する。
【００８９】
ＭＰＤ解析部２０２は、ＭＰＤ取得部２０１の取得したＭＰＤの記述内容を解析し、再生対象データに対応するセグメントの取得に必要となる情報等をセグメント取得部に提供する。
【００９０】
さらに、ＭＰＤ解析部２０２は、ＭＰＤに、アプリケーション制御メッセージ（ＡＣＭ：Ａｐｐｌｉｃａｔｉｏｎ  Ｃｏｎｔｒｏｌ  Ｍｅｓｓａｇｅ）が含まれている場合、ＭＰＤをイベント抽出部２０５に出力する。
イベント抽出部２０５は、ＭＰＤに記録されたアプリケーション制御メッセージ（ＡＣＭ）をアプリケーション制御部１４０に出力する。
【００９１】
上述したように、アプリケーションには、旅番組におけるホテル案内情報の表示アプリケーションや、クイズやアンケート用のアプリケーション等、様々であるが、これらのアプリケーションは、特定の放送コンテンツにおいて、決められたタイミングで実行しなければ意味がない。従って、アプリケーション制御部１４０は、予め規定されたタイミングに従って、アプリケーションの取得、アプリケーションの実行、終了等の制御を行う必要がある。
これらの情報は、アプリケーション制御メッセージ（ＡＣＭ：Ａｐｐｌｉｃａｔｉｏｎ  Ｃｏｎｔｒｏｌ  Ｍｅｓｓａｇｅ）に記録されており、アプリケーション制御部１４０は、このアプリケーション制御メッセージ（ＡＣＭ）を再生制御部１３１のイベント抽出部２０５を介して受領する。
【００９２】
アプリケーション制御メッセージ（ＡＣＭ）は、シグナリングデータとしてのＭＰＤや、セグメント内に記録されており、再生制御部１３１はＭＰＤや、セグメントにアプリケーション制御メッセージ（ＡＣＭ）が含まれている場合、これをアプリケーション制御部１４０に出力する処理を実行する。
この処理については、後段で詳細に説明する。
【００９３】
セグメント取得部２０３は、ＭＰＤ解析部２０２のＭＰＤ解析結果に従って、再生対象データに対応するセグメントの取得を行う。
セグメントは、ＡＶデータからなるコンテンツ伝送用のファイル・フォーマット（セグメント・フォーマット）に従って設定される所定の単位データである。
【００９４】
セグメント解析部２０４は、セグメント取得部２０３の取得したセグメントから、符号化画像データ、符号化音声データ等を取得して、出力制御部１３２の復号部（デコーダ）２１１に出力する。
【００９５】
さらに、セグメント解析部２０４は、セグメントに、アプリケーション制御メッセージ（ＡＣＭ：Ａｐｐｌｉｃａｔｉｏｎ  Ｃｏｎｔｒｏｌ  Ｍｅｓｓａｇｅ）が含まれている場合、セグメントをイベント抽出部２０５に出力する。
イベント抽出部２０５は、セグメントに記録されたアプリケーション制御メッセージ（ＡＣＭ）をアプリケーション制御部１４０に出力する。
この処理の詳細については、後段で説明する。
【００９６】
イベント抽出部２０５は、ＭＰＤ、またはセグメントに格納されたイベント情報の抽出を実行し、抽出したイベント情報に含まれるアプリケーション制御メッセージをアプリケーション制御部１４０に出力する。
【００９７】
アプリケーション制御メッセージは、アプリケーション制御部１４０が制御対象とするアプリケーションに関する制御情報である。
このアプリケーション制御メッセージは、ＭＰＤ、またはセグメントにイベント情報として格納される。
なお、この具体的構成については後述する。
【００９８】
チューナ実装受信装置（クライアントＡ）３０の出力制御部１３２は、復号部（デコーダ）２１１と、出力部（レンダラ）２１２を有する。
復号部（デコーダ）２１１は、セグメント解析部２０４から提供された符号化画像データ、符号化音声データの復号処理（デコード）を実行する。
出力部２１２は、復号された画像データ、音声データを出力部（ディスプレイ、スピーカ）に出力する。
【００９９】
なお、チューナ非実装受信装置（クライアントＢ）４０の再生制御部（ＤＡＳＨ  Ｃｌｉｅｎｔ）１５１は、ＭＰＤ取得部２５１、ＭＰＤ解析部２５２、セグメント取得部２５３、セグメント（ＭＰ４）解析部２５４、さらにイベント抽出部２５５を有する。
また、出力制御部１５２は、復号部（デコーダ）２６１と、出力部（レンダラ）２６２を有する。
これらの構成、および実行する処理は、チューナ実装受信装置（クライアントＡ）３０の構成、処理と同様である。
【０１００】
なお、チューナ非実装受信装置（クライアントＢ）４０の再生制御部（ＤＡＳＨ  Ｃｌｉｅｎｔ）１５１には、チューナ実装受信装置（クライアントＡ）３０のプロキシサーバ１２０、ネットワークを介してＭＰＤ、セグメントが入力される。
また、チューナ非実装受信装置（クライアントＢ）４０のアプリケーション制御部１６０には、チューナ実装受信装置（クライアントＡ）３０のプロキシサーバ１２０、ネットワークを介してアプリケーションファイルが入力される。
【０１０１】
チューナ実装受信装置（クライアントＡ）３０、およびチューナ非実装受信装置（クライアントＢ）４０の再生制御部（ＤＡＳＨ  Ｃｌｉｅｎｔ）１３１，１５１は、ＡＴＳＣ３．０クライアントアプリケーション（３．０  ＤＡＳＨ  Ｃｌｉｅｎｔ）の実行部である。
ＡＴＳＣ３．０クライアントアプリケーションは、ＡＴＳＣ３．０放送受信クライアントデバイス上に実装されたブラウザ上で実行される。あるいは、ブラウザアプリケーションとしてだけではなくネィティブアプリケーションとして実行される場合もある。
【０１０２】
再生制御部（ＤＡＳＨ  Ｃｌｉｅｎｔ）１３１，１５１の実行するＡＴＳＣ３．０クライアントアプリケーションは、ＡＴＳＣ３．０  ＤＡＳＨクライアントアプリケーション（３．０  ＤＡＳＨ  Ｃｌｉｅｎｔ）や、ＡＴＳＣ３．０ストリーム付随アプリケーション（３．０  Ａｐｐｌｉｃａｔｉｏｎ）等からなる。
【０１０３】
再生制御部（ＤＡＳＨ  Ｃｌｉｅｎｔ）１３１，１５１のＡＴＳＣ３．０クライアントアプリケーション、および出力制御部１３２，１５２は、ミドルウェア（Ｃｌｉｅｎｔ  Ｌｏｃａｌ  ＡＴＳＣ  Ｍｉｄｄｌｅｗａｒｅ）１１０が受信したデータ、プロキシサーバ（Ｃｌｉｅｎｔ  Ｌｏｃａｌ  ＨＴＴＰ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ）１２０がネットワークを介して受信したデータの処理を実行する。
【０１０４】
ミドルウェア１１０、またはプロキシサーバ１２０の取得した、ＤＡＳＨ−ＭＰＤファイルやＤＡＳＨセグメント（ｓｅｇｍｅｎｔ）ファイル、その他一般のアプリケーションファイル、ならびに、シグナリングデータを格納したＳＬＳ（Ｓｅｒｖｉｃｅ  ｌｅｖｅｌ  Ｓｉｇｎａｌｉｎｇ）ファイルを入力して、ストリームのレンダリングや、アプリケーションの制御を行う。
【０１０５】
このモデルは、再生制御部（ＤＡＳＨ  Ｃｌｉｅｎｔ）１３１，１５１の実行するＡＴＳＣ３．０クライアントアプリケーションや、アプリケーション制御部１６０の実行するアブリケーションからすると、必ずプロキシサーバ１２０を介して外の世界にアクセスするため、それらファイル群を放送経由で取得しているのか、ネット経由で取得しているのかの区別を意識することがない（ネットワーク透過性が提供される）ため、アプリケーションの可搬性を高めることが可能となる。
従って放送向けのみに特化してアプリケーションを実装する必要がなく、放送もインターネットのどちらを使うかによらない実装とすることができる。
【０１０６】
再生制御部（ＤＡＳＨ  Ｃｌｉｅｎｔ）１３１，１５１の実行するＡＴＳＣ３．０クライアントアプリケーションがＤＡＳＨ−ＭＰＤファイルやＤＡＳＨセグメント（ｓｅｇｍｅｎｔ）ファイル、その他一般のアプリケーションファイル、ならびに、シグナリングデータファイルの取得を要求（ＨＴＴＰリクエスト）すると、それを受けたプロキシサーバ１２０が、アドレス解決部（Ｂｒｏａｄｃａｓｔ／Ｂｒｏａｄｂａｎｄ  Ａｄｄｒｅｓｓ  Ｒｅｓｏｌｖｅｒ）１２３において放送受信スタックを介して取得するか、ネット経由で取得するかの判断を行う。
【０１０７】
判断材料となる情報は、シグナリング解析部（ＳＬＳ  Ｓｉｇｎａｌｉｎｇ  Ｐａｒｓｅｒ）１１３から提供される。シグナリング解析部（ＳＬＳ  Ｓｉｇｎａｌｉｎｇ  Ｐａｒｓｅｒ）１１３は、シグナリング取得部（ＳＬＳ  Ｓｉｇｎａｌｉｎｇ  Ｒｅｔｒｉｅｖｅｒ）１１２に、ＡＴＳＣ３．０のシグナリングメタであるＵＳＢＤ／ＵＳＤやＳ−ＴＳＩＤ等の取得要求を行う。
【０１０８】
シグナリング取得部（ＳＬＳ  Ｓｉｇｎａｌｉｎｇ  Ｒｅｔｒｉｅｖｅｒ）１１２は、通信部（ＡＴＳＣチューナ：ＡＴＳＣ３．０  ＰＨＹ／ＭＡＣ）１１１を介して放送受信するＳＬＳ  ＬＣＴパケットにより運ばれるシグナリングメタを抽出する。
【０１０９】
シグナリング解析部（ＳＬＳ  Ｓｉｇｎａｌｉｎｇ  Ｐａｒｓｅｒ）１１３は、また、アプリケーションパーツの取得要求に含まれるｕｒｌから、シグナリングメタを抽出して、対象となるファイルを取得するための放送配信アドレス情報を解決する。放送配信される（た）ことがわかれば、その放送配信アドレス情報をもとにして、所望のファイルが格納されたＬＣＴパケットを放送ストリームから取得し、キャッシュ（Ｐｒｏｘｙ  Ｃａｃｈｅ）部１２１，１２２内に展開する。プロキシサーバ１２０は、当該ファイルを再生制御部１３１やアプリケーション制御部１４０に（ＨＴＴＰのレスポンスとして）返す。アプリケーションパーツの取得要求に含まれるｕｒｌがシグナリングメタになければ、プロキシサーバ１２０は、通常のネットスタックを介して当該ファイルを取得する。
【０１１０】
［５．アプリケーション制御メッセージの転送処理について］
前述したように、現在開発途上にあるＡＴＳＣ３．０においては、ＡＴＳＣ３．０準拠物理層（ＡＴＳＣ−ＰＨＹ）を実装したチューナ実装受信装置３０上に、ミドルウェア（ＡＴＳＣ３．０放送受信ミドルウェア）１１０を実装して、シグナリングデータ（ＡＴＳＣ放送シグナリング）を解析するモデルを検討している。
すなわち、ミドルウェア１１０をシグナリングデータの受信タイミングにおける即時解析処理が可能な終端デバイスとし、再生制御部（ＤＡＤＨクライアント）にシグナリングデータに対する即時解析負荷を発生させない設定としたモデルを検討している。この設定により、インターネットで利用されているＤＡＳＨクライアントアプリケーションをそのまま利用して、ＡＴＳＣ放送の受信、再生を実現することが可能となる。
【０１１１】
このモデルは、チューナ実装受信装置３０によって受信した放送コンテンツや、ネットワーク受信コンテンツを、チューナ非実装受信装置４０に転送し、チューナ非実装受信装置４０の再生制御部１５１の実行するＡＴＳＣ３．０  ＤＡＳＨクライアントアプリケーションの処理によってコンテンツ再生を行なうことも可能とする。
【０１１２】
チューナ実装受信装置３０は、例えば共用スペース（ホットスポット）に設置した中継サーバや、家庭に設置したホームサーバ、ＰＣ等であり、放送波を受信可能なチューナを実装した受信装置である。
チューナ実装受信装置３０の受信データは、ネットワーク（家庭内ならホームネットワーク（ＬＡＮ／ＷｉＦｉ等）、ホットスポットならＷｉＦｉ等）を介して、チューナ非実装受信装置４０に転送される。
チューナ非実装受信装置４０は、再生制御部１５１においてＡＴＳＣ３．０  ＤＡＳＨクライアントアプリケーションを実行して、コンテンツ再生を行なう。
【０１１３】
本開示の構成では、ＡＴＳＣ３．０放送サービスによって提供されるシグナリングデータの解析等の処理を、チューナ実装受信装置（クライアントＡ）３０のミドルウェア１１０が実行する。
チューナ実装受信装置（クライアントＡ）３０は、シグナリング情報にアプリケーション制御メッセージ（ＡＣＭ）が含まれている場合には、それを受信したタイミングでできるだけ早く、アプリケーション制御メッセージ（ＡＣＭ）を利用する受信装置に提供する。
【０１１４】
通知が必要となるアプリケーション制御メッセージ（ＡＣＭ）は、具体的には、放送ＡＶストリームと同期して制御されるＡＶストリーム付随アプリケーションに対するアプリケーション制御メッセージ（ＡＴＳＣ−ＴｒｉｇｇｅｒやＨｂｂＴＶ−ＡＩＴ他）等である。
特に、ストリームにできるだけ同期したメッセージ通知が必要な場合は、各受信装置３０，４０のアプリケーション制御部１４０，１６０に迅速にアプリケーション制御メッセージ（ＡＣＭ）を出力することが要求される。
【０１１５】
通常、再生制御部（ＤＡＳＨ  Ｃｌｉｅｎｔ）１３１，１５１は、画像や音声等のＡＶデータからなるコンテンツを含むセグメント（ＤＡＳＨセグメント）のＨＴＴＰによる取得を連続して実行する実装となる。一旦ストリーミング再生が開始されると常に再生制御部（ＤＡＳＨ  Ｃｌｉｅｎｔ）１３１，１５１がＨＴＴＰ取得／再生処理を継続して行う。
セグメント（ＡＶセグメント等のＤＡＳＨセグメント）を提供するサーバはＤＡＳＨサーバと呼ばれる。
ＤＡＳＨサーバは、具体的には、
放送サーバ２１、データ配信サーバ２２、
さらに、チューナ実装受信装置（クライアントＡ）３０のプロキシサーバ１２０もＤＡＳＨサーバとなる。
【０１１６】
チューナ実装受信装置３０や、チューナ非実装受信装置４０の再生制御部１３１，１５１は、ＤＡＳＨサーバと常時接続されるＰｕｌｌ型のコミュニケーションセッションを利用してセグメント取得を継続的に行い、放送番組等のコンテンツ再生を実行する。
【０１１７】
このセグメント取得セッション中で、アプリケーション制御部１４０において制御すべきアプリケーション（例えば、天気情報やニュース情報の表示、クイズ、アンケート処理等を実行するアプリケーションなど）に関するアプリケーション制御メッセージが到着した場合、このイベント通知や、アプリケーション制御メッセージそのものを、即座にアプリケーション制御部１４０に通知することが必要となる。
【０１１８】
本開示の構成は、ＤＡＳＨで規定されているイベント（Ｅｖｅｎｔ）通知機構を拡張してこのアプリケーション制御メッセージを抽出してアプリケーション制御部に出力する構成を提案するものである。
【０１１９】
本開示の処理では、ミドルウェア（ＡＴＳＣ３．０放送受信ミドルウェア）１１０が取得したアプリケーション制御メッセージを、例えばストリームセッション中に差し込むことができる。
従って、例えば、通信部１１１やミドルウェア１１０を実装しないチューナ非実装受信装置（クライアントＢ）４０に対しても、ストリームに同期してアプリケーション制御メッセージを転送することができる。
【０１２０】
通信部１１１やミドルウェア１１０を実装するチューナ実装受信装置（クライアントＡ）３０と、ネットワーク（家庭内ならホームネットワーク（ＬＡＮ／ＷｉＦｉ等）、ホットスポットならＷｉＦｉ等）を介して接続されるチューナ非実装受信装置（クライアントＢ）４０は、ＡＶセグメント転送セッションの他の新たなアプリケーションメッセージングセッションを開設することなく、ストリームに同期してアプリケーション制御メッセージを受信して、タイムリなアプリケーション制御を実行することができる。
【０１２１】
［６．イベント通知構成について］
次に、ＤＡＳＨ規格において規定されているイベント通知構成について説明する。
ＤＡＳＨ規格では、ＤＡＳＨイベント（ＤＡＳＨ  Ｅｖｅｎｔ）と呼ばれるイベント通知機構が定義されている。
イベント通知機構は、例えば、放送番組や送信データの変更や詳細等の通知情報、受信装置において実行するアプリケーションに関する情報、受信装置に通知すべき情報、受信装置において必要となる処理の情報など、様々なイベント情報の通知を行うための機構である。
【０１２２】
ＤＡＳＨ規格においてはイベント通知機構として、以下の２種類のイベント通知方式が規定されている。
（ａ）ＭＰＤ適用イベント通知方式（＝ＭＰＤ  Ｅｖｅｎｔ）、
（ｂ）セグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）
これらの２種類のイベント通知方式が規定されている。
以下、これらの２つのイベント通知方式の詳細について、順次、説明する。
【０１２３】
［６−１．ＭＰＤ適用イベント通知方式（＝ＭＰＤ  Ｅｖｅｎｔ）について］
ＭＰＤ適用イベント通知方式（＝ＭＰＤ  Ｅｖｅｎｔ）は、ＤＡＳＨ規格に規定されたシグナリングデータの１つであるＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）を利用してイベントを通知する方式である。
【０１２４】
ＭＰＤ適用イベント通知方式（＝ＭＰＤ  Ｅｖｅｎｔ）は、ＭＰＤに規定可能なピリオド（Ｐｅｒｉｏｄ）単位で、イベント要素、具体的には、イベント種類や、イベント内容を示すイベントストリーム（ＥｖｅｎｔＳｔｒｅａｍ）等の要素を追加することができる。
【０１２５】
ＭＰＤ適用イベント通知方式（＝ＭＰＤ  Ｅｖｅｎｔ）では、ＭＰＤを利用して、ピリオド（Ｐｅｒｉｏｄ）単位でイベント処理に必要な情報をクライアントに提供できる。
具体的には、ＭＰＤ適用イベント通知方式（＝ＭＰＤ  Ｅｖｅｎｔ）では、
（ａ）様々なイベントのアクティベート（開始／実行／活性化）タイミング等のイベントスケジュール、
（ｂ）各タイミングにおいてクライアント（受信装置）が処理すべきイベント処理、さらに、
（ｃ）イベント実行時にクライアント上で稼働するアプリケーションに渡すべきデータ等、
これらをＭＰＤに記述することができる。
【０１２６】
図７は、ＭＰＤのフォーマットを示す図である。
ＭＰＤは、画像や、音声それぞれのストリームごとに、以下の規定範囲単位で属性等の情報や制御情報を記述することが可能な構成を持つ。
（１）時間軸上の区間を規定したピリオド（Ｐｅｒｉｏｄ）
（２）画像、音声等のデータ種類等を規定したアダプテーション（Ａｄａｐｔａｔｉｏｎ）
（３）画像の種類、音声の種類等を規定したリプレゼンテーション（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）
（４）画像、音声のセグメント（ＡＶセグメント）単位の情報記録領域となるセグメントインフォ（ＳｅｇｍｅｎｔＩｎｆｏ）
【０１２７】
図８は、ＭＰＤに記録されるＡＶセグメント対応の情報（制御情報や管理情報、属性情報など）を時系列に展開して示した図である。
左から右に時間が経過するものとする。この時間軸は、例えば受信装置におけるＡＶコンテンツの再生時間に対応する。
【０１２８】
ＡＶセグメントに対応する様々な情報がＭＰＤに記録される。なお、ＭＰＤはシグナリングデータの一部であり、例えばＡＶセグメントに先行して送信される。
ＭＰＤは、図７を参照して説明したように、以下の各データ単位で情報が記録できる。
（１）時間軸上の区間を規定したピリオド（Ｐｅｒｉｏｄ）
（２）画像、音声等のデータ種類等を規定したアダプテーション（Ａｄａｐｔａｔｉｏｎ）
（３）画像の種類、音声の種類等を規定したリプレゼンテーション（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）
（４）画像、音声のセグメント（ＡＶセグメント）単位の情報記録領域となるセグメントインフォ（ＳｅｇｍｅｎｔＩｎｆｏ）
図８は、これらのデータ領域を時間軸、およびデータ種類別に展開して示した図である。
【０１２９】
図８には、以下の２つのアダプテーション（Ａｄａｐｔａｔｉｏｎ）を示している。
（Ｖ）画像対応情報記録領域であるアダプテーションＶ（Ａｄａｐｔａｔｉｏｎ（Ｖ））
（Ａ）音声対応情報記録領域であるアダプテーションＡ（Ａｄａｐｔａｔｉｏｎ（Ａ））
【０１３０】
（Ｖ）画像対応情報記録領域であるアダプテーションＶ（Ａｄａｐｔａｔｉｏｎ（Ｖ））は、異なる属性を持つストリーム単位の情報記録領域として、以下の２つのリプレゼンテーション（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）を有する。
（Ｖ１）低ビットレート画像対応の情報記録領域であるリプレゼンテーション（Ｖ１）（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ（Ｖ１））
（Ｖ２）高ビットレート画像対応の情報記録領域であるリプレゼンテーション（Ｖ２）（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ（Ｖ２））
【０１３１】
同様に、（Ａ）音声像対応情報記録領域であるアダプテーションＡ（Ａｄａｐｔａｔｉｏｎ（Ａ））は、異なる属性を持つストリーム単位の情報記録領域としての以下の２つのリプレゼンテーション（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）を有する。
（Ａ１）日本語音声対応の情報記録領域であるリプレゼンテーション（Ａ１）（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ（Ａ１））
（Ａ２）英語音声対応の情報記録領域であるリプレゼンテーション（Ａ２）（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ（Ａ２））
【０１３２】
さらに、各リプレゼンテーション（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）は、再生時間軸対応のピリオド、さらに、セグメント単位で情報が記録可能な構成となっている。
【０１３３】
例えば、高ビットレート画像と日本語音声を選択して再生する受信装置（クライアント）は、ピリオド１のセグメント（１１）の再生に際して、再生対象とする高ビットレート画像と日本語音声に関する情報をＭＰＤから選択して取得することになる。
この選択対象とするＭＰＤの記録情報が、図に示すセグメント領域３０１，３０２の情報となる。
【０１３４】
このように、受信装置は、シグナリングデータとして送信装置から送信されるＭＰＤから、自装置で再生対象とするデータ（セグメント）に対応する情報のみを選択して参照する。
【０１３５】
このように、ＭＰＤには、データ種別、時間単位のセグメント対応情報を記録することができる。
例えば、受信装置（クライアント）における様々な処理要求を通知するためのイベント通知も、このＭＰＤに記録することができる。
図９は、ＭＰＤを用いたイベント通知、すなわち、ＭＰＤ適用イベント通知方式（＝ＭＰＤ  Ｅｖｅｎｔ）を適用した場合のＭＰＤの記述例を示す図である。
イベント情報を含むＭＰＤは、例えば以下の記述を有する。
【０１３６】
＜ＭＰＤ  ａｖａｉｌａｂｉｌｉｔｙＳｔａｒｔＴｉｍｅ＝"２０１１−１２−２５Ｔ１２：３０：００
＜Ｐｅｒｉｏｄ  ｓｔａｒｔＴｉｍｅ＝'０'＞
・・・
＜ＥｖｅｎｔＳｔｒｅａｍ  ｓｃｈｅｍｅＩｄＵｒｉ＝'ｕｒｎ：ｘｘｘ'  ｔｉｍｅｓｃａｌｅ＝'１０００'＞
＜Ｅｖｅｎｔ  ｐｒｅｓｅｎｔａｔｉｏｎＴｉｍｅ＝'０'  ｄｕｒａｔｉｏｎ＝'１０００'＞イベントデータ１＜／Ｅｖｅｎｔ＞
＜Ｅｖｅｎｔ  ｐｒｅｓｅｎｔａｔｉｏｎＴｉｍｅ＝'１０００'  ｄｕｒａｔｉｏｎ＝'４０００'＞イベントデータ２＜／Ｅｖｅｎｔ＞
…．
＜／ＥｖｅｎｔＳｔｒｅａｍ＞
・・・
＜ＡｄａｐｔａｔｉｏｎＳｅｔ＞
＜Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ／＞
＜Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ／＞
＜／ＡｄａｐｔａｔｉｏｎＳｅｔ＞
・・・
＜／Ｐｅｒｉｏｄ＞
＜／ＭＰＤ＞
【０１３７】
上記のＭＰＤのデータ内容について説明する。
＜ＭＰＤ  ａｖａｉｌａｂｉｌｉｔｙＳｔａｒｔＴｉｍｅ＝"２０１１−１２−２５Ｔ１２：３０：００
このデータ記録記録領域は、このＭＰＤに記録されたデータに対応する最初のピリオドの開始時刻情報の記録領域である。時刻情報としては例えばＵＴＣ時刻が用いられる。
【０１３８】
＜Ｐｅｒｉｏｄ  ｓｔａｒｔＴｉｍｅ＝'０'＞
このデータ記録記録領域は、ピリオド開始時間情報記録領域である。ＭＰＤにおいて規定されるスタート時間（ＭＰＤ／＠ａｖａｉｌａｂｉｌｉｔｙＳｔａｒｔＴｉｍｅ）からのオフセット時間が記録される。
【０１３９】
＜ＥｖｅｎｔＳｔｒｅａｍ  ｓｃｈｅｍｅＩｄＵｒｉ＝'ｕｒｎ：ｘｘｘ'  ｔｉｍｅｓｃａｌｅ＝'１０００'＞
このデータ記録記録領域は、イベント種類等を示すイベントストリーム指定情報とタイムスケール情報の記録領域である。
「ＥｖｅｎｔＳｔｒｅａｍ  ｓｃｈｅｍｅＩｄＵｒｉ＝'ｕｒｎ：ｘｘｘ'」と、オプショナルな「ＥｖｅｎｔＳｔｒｅａｍ／＠ｖａｌｕｅ」によりイベントの種類等が定義される。
さらに、「ｔｉｍｅｓｃａｌｅ＝'１０００'」は、以下に記録されるプレゼンテーションタイム（ｐｒｅｓｅｎｔａｔｉｏｎＴｉｍｅ）の単位時間は１／１０００秒であることを示す。
【０１４０】
＜Ｅｖｅｎｔ  ｐｒｅｓｅｎｔａｔｉｏｎＴｉｍｅ＝'０'  ｄｕｒａｔｉｏｎ＝'１０００'＞イベントデータ１＜／Ｅｖｅｎｔ＞
このデータ記録記録領域は、イベントデータの記録領域と、イベントのアクティベート（実行開始等）時間や継続時間等のイベントスケジューリングデータの記録領域である。
イベントデータは、イベントを実行するために必要となる実体データ、メタデータ、コマンド等のデータや、そのアクセス情報等によって構成される。
さらに、イベントのアクティベート（実行開始等）時間や継続時間が記録される。
この例は、イベントデータ１によって特定されるイベントを、アクティベート（活性化／実行）時刻＝０で１０００単位時間継続することを指定している。
【０１４１】
＜Ｅｖｅｎｔ  ｐｒｅｓｅｎｔａｔｉｏｎＴｉｍｅ＝'１０００'  ｄｕｒａｔｉｏｎ＝'４０００'＞イベントデータ１＜／Ｅｖｅｎｔ＞
このデータ記録記録領域も、イベントデータの記録領域と、イベントのアクティベート（実行開始等）時間や継続時間等のイベントスケジューリングデータの記録領域である。
イベントデータは、イベントを実行するために必要となる実体データ、メタデータ、コマンド等のデータや、そのアクセス情報等によって構成される。
さらに、イベントのアクティベート（実行開始等）時間や継続時間が記録される。
この例は、イベントデータ２によって特定されるイベントを、アクティベート（活性化／実行）時刻＝１０００で４０００単位時間継続することを指定している。
【０１４２】
以下の、
＜ＡｄａｐｔａｔｉｏｎＳｅｔ＞
＜Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ／＞
＜Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ／＞
これらは、各データ種類別の情報を記録するデータ記録領域である。
【０１４３】
このように、ＭＰＤを用いたイベント通知、すなわち、ＭＰＤ適用イベント通知方式（ＭＰＤ  Ｅｖｅｎｔ）では、
ＥｖｅｎｔＳｔｒｅａｍ／＠ｓｃｈｅｍｅＩｄＵｒｉ（とオプショナルなＥｖｅｎｔＳｔｒｅａｍ／＠ｖａｌｕｅ）属性によりイベントの種類を定義し、
ＥｖｅｎｔＳｔｒｅａｍ／Ｅｖｅｎｔ要素のコンテンツパートにイベントデータ、すなわち、イベントを実行するために必要となる実体データ、メタデータ、コマンド等のデータや、そのアクセス情報等を付加することができる。
【０１４４】
なお、ＭＰＤ／Ｐｅｒｉｏｄ／ＥｖｅｎｔＳｔｒｅａｍ／Ｅｖｅｎｔ以下のデータ要素として格納される「イベントデータ」のフォーマット（何を格納すべきか）については、「ＥｖｅｎｔＳｔｒｅａｍ／＠ｓｃｈｅｍｅＩｄＵｒｉ」属性の値（図９の例では（ｕｒｎ：ｘｘｘ）によって特定（定義）される。
なお、この、ＭＰＤ適用イベント通知方式（ＭＰＤ  Ｅｖｅｎｔ）は、ＭＰＤの送出前に、ＭＰＤ内に記述されるピリオドの内容が確定できる場合にのみ適用可能である。
【０１４５】
図１０は、受信装置において実行するＭＰＤの解析処理（パース）の手順を説明する図である。
図１０には、以下の各図を示している。
（１）ＭＰＤ
（２）ピリオド単位情報
（３）リプレゼンテーション単位情報
（４）セグメント単位情報
【０１４６】
ＡＶセグメントを受信してＡＶコンテンツの再生処理を実行する受信装置（クライアント）は、ＡＶセグメント受信
前に予め受信するシグナリングデータに含まれるＭＰＤを取得し、自装置において再生するデータに対応する情報をＭＰＤから取得する。
【０１４７】
まず、図１０に示す（１）ＭＰＤから、ＡＶセグメント再生時間に相当する特定のピリオドの（情報を記録した（２）ピリオド単位情報を選択する。
さらに、自装置（クライアント）において再生するデータの種類に対応したリプレゼンテーション単位情報を選択し、さらに、再生対象セグメントに対応する（４）セグメント単位情報を選択する。
この（４）セグメント単位情報に記録されたデータを参照して、再生対象となるＡＶセグメントの取得や、ＡＶセグメント再生に必要となる様々な情報を取得することができる。
【０１４８】
受信装置（クライアント）は、受信したＭＰＤのセグメント単位情報にイベント情報が記録されている場合、その記録されたイベント情報に従って指定イベントのアクティベート（実行、開始等のイベント活性化処理）等を行うことになる。
【０１４９】
図１１を参照して、イベント情報を記録したＭＰＤの生成（または取得）と出力を実行するイベント挿入実行装置３１０と、イベント記録ＭＰＤを受領してＭＰＤ記録イベント情報に応じた処理を実行するイベント実行装置３２０の構成と処理例について説明する。
【０１５０】
図１１には、左側に、イベント情報を記録したＭＰＤの生成（または取得）と出力を実行するイベント挿入実行装置３１０を示している。
また、図１１の右側には、イベント情報を記録したＭＰＤを入力してＭＰＤに記録されたイベント情報に応じた処理（イベントアクティベート）を実行するイベント実行装置３２０を示している。
【０１５１】
イベント挿入実行装置３１０は、具体的には、ＭＰＤ等のシグナリングデータや、ＡＶセグメントを送信する放送サーバ２１、データ配信サーバ２２、あるいは、受信装置においてＭＰＤ等のシグナリングデータや、ＡＶセグメントを受信して、受信装置の再生制御部１３１に出力する受信装置のミドルウェア１１０（図５、図６に示すミドルウェア１１０）である。
【０１５２】
また、図１１の右側に示すイベント実行装置３２０は、具体的には、ＭＰＤ等のシグナリングデータや、ＡＶセグメントを入力してコンテンツ再生処理を実行する受信装置の再生制御部（図５、図６に示す再生制御部１３１，１５１）である。
【０１５３】
イベント挿入実行装置３１０の実行する処理について説明する。
イベント挿入実行装置３１０は、データ出力部（ＤＡＳＨサーバ）３１１、イベント処理部（イベントサーバ）３１２を有する。
なお、これらのサーバ機能は、ＭＰＤ等のシグナリングデータや、ＡＶセグメントを送信する放送サーバ２１、データ配信サーバ２２、さらに、受信装置のミドルウェア１１０（図５、図６に示すミドルウェア１１０）が有する機能である。
以下、イベント挿入実行装置３１０の実行する処理について、処理ステップごとに説明する。
【０１５４】
（ステップＳ１１）
まず、イベント挿入実行装置３１０のデータ出力部（ＤＡＳＨサーバ）３１１は、ステップＳ１１において、シグナリングデータとしてのＭＰＤ、および再生コンテンツを構成するＡＶデータを含むセグメントを生成、または取得する。
【０１５５】
イベント挿入実行装置３１０が放送サーバ２１、データ配信サーバ２２である場合は、ＭＰＤ、セグメントを生成または取得する処理を行なう。
イベント挿入実行装置３１０が受信装置のミドルウェア１１０（図５、図６に示すミドルウェア１１０）である場合は、ＭＰＤ、セグメントを受信データから取得する処理を行なう。
【０１５６】
（ステップＳ１２）
次に、イベント挿入実行装置３１０のイベント処理部（イベントサーバ）３１２は、ステップＳ１２において、イベント情報を生成または、取得する。
イベント情報とは、例えば、番組表の変更や、放送コンテンツのデータ態様の変更、受信装置における放送コンテンツの再生時に実行すベき処理など、受信装置に対して何らかの処理の実行を通知あるいは要求するための情報である。
【０１５７】
イベント挿入実行装置３１０が放送サーバ２１、データ配信サーバ２２である場合は、イベント情報を生成または取得する処理を行なう。
イベント挿入実行装置３１０が受信装置のミドルウェア１１０（図５、図６に示すミドルウェア１１０）である場合は、イベント情報を受信データから取得する処理を行なう。
【０１５８】
（ステップＳ１３）
次に、イベント挿入実行装置３１０のデータ出力部（ＤＡＳＨサーバ）３１１は、ステップＳ１３において、シグナリングデータとしてのＭＰＤに対して、イベント情報の挿入を行う。
この処理によって、先に図９を参照して説明したイベント情報記録ＭＰＤが生成される。
【０１５９】
図９に示すイベント情報記録ＭＰＤには、先に説明したように、
イベントの種類、内容や、イベントのアクティベート（活性化）時刻、継続時間情報等が記録されている。
受信装置は、このＭＰＤに記録されたイベント情報に従って、指定されたイベントを指定時間にアクティベート（例えば実行）し、指定継続時間、継続させる処理などを行うことが可能となる。
【０１６０】
（ステップＳ１４）
次に、イベント挿入実行装置３１０のデータ出力部（ＤＡＳＨサーバ）３１１は、ステップＳ１４において、シグナリングデータとしてのＭＰＤにイベント情報を記録したイベント情報記録ＭＰＤを送信（出力）する。
【０１６１】
イベント挿入実行装置３１０が放送サーバ２１、データ配信サーバ２２である場合は、イベント情報記録ＭＰＤを、放送波またはネットワークを介して送信する。
イベント挿入実行装置３１０が受信装置のミドルウェア１１０（図５、図６に示すミドルウェア１１０）である場合は、イベント情報記録ＭＰＤを、プロキシサーバ、あるいは再生制御部に出力する。
【０１６２】
（ステップＳ１５〜Ｓ１６）
次に、イベント挿入実行装置３１０のデータ出力部（ＤＡＳＨサーバ）３１１は、ステップＳ１５〜Ｓ１６において、ＡＶコンテンツ等を格納したセグメントを送信（出力）する。
セグメント送信は、ステップＳ１６以降、継続的に実行される。
【０１６３】
イベント挿入実行装置３１０が放送サーバ２１、データ配信サーバ２２である場合は、セグメントを、放送波またはネットワークを介して送信する。
イベント挿入実行装置３１０が受信装置のミドルウェア１１０（図５、図６に示すミドルウェア１１０）である場合は、セグメントを、プロキシサーバ、あるいは再生制御部に出力する。
【０１６４】
次に、図１１の右側に示すイベント実行装置３２０の実行する処理について説明する。
イベント実行装置３２０は、具体的には、ＭＰＤ等のシグナリングデータや、ＡＶセグメントを入力してコンテンツ再生処理を実行する受信装置の再生制御部（図５、図６に示す再生制御部１３１，１５１）である。
【０１６５】
図１１に示すイベント実行装置３２０の実行する処理は、受信装置の再生制御部１３１，１５１において実行する処理である。
なお、図１１においては、再生制御部を、実行する処理の種類に応じた処理種類単位で分離した構成として示している。
具体的には、イベント対応処理実行部としての再生制御部（イベントクライアント）３２１と、ＭＰＤやＡＶセグメントを適用したコンテンツ再生処理を実行する再生制御部（ＤＡＳＨクライアント）３２２、これら２つの処理部を示している。
【０１６６】
（ステップＳ２１）
まず、イベント実行装置３２０の再生制御部（ＤＡＳＨクライアント）３２２は、ステップＳ２１において、イベント挿入実行装置３１０に対してシグナリングデータとしてのＭＰＤの取得要求を行う。
【０１６７】
（ステップＳ２２）
次に、イベント実行装置３２０の再生制御部（ＤＡＳＨクライアント）３２２は、ステップＳ２２において、イベント挿入実行装置３１０から取得したＭＰＤからイベント情報を取得する。
【０１６８】
なお、ここで取得したＭＰＤは、イベント情報記録ＭＰＤ、すなわち、図９に示すイベント情報ＭＰＤであるものとする。
イベント情報記録ＭＰＤには、イベントの種類、内容や、イベントのアクティベート（例えば実行、停止等の活性化）時刻、継続時間情報等が記録されている。
受信装置は、このＭＰＤに記録されたイベント情報に従って、指定されたイベントを指定時間にアクティベート（例えば実行）し、指定継続時間、継続させる処理などを行うことが可能となる。
【０１６９】
（ステップＳ２３）
次に、イベント実行装置３２０の再生制御部（イベントクライアント）３２１は、ステップＳ２３において、ＭＰＤから取得したイベント情報に従って、イベント適用のスケジューリング処理を行なう。
前述したように、イベント情報記録ＭＰＤには、イベントの種類、内容や、イベントのアクティベート（活性化）時刻、継続時間情報等が記録されており、イベント実行装置３２０の再生制御部（イベントクライアント）３２１は、これらの情報を参照して、イベント実行のスケジューリング処理を行なう。
【０１７０】
（ステップＳ２４）
次に、イベント実行装置３２０の再生制御部（ＤＡＳＨクライアント）３２２は、ステップＳ２４において、イベント挿入実行装置３１０に対してセグメントの取得要求を行う。
【０１７１】
（ステップＳ２５）
次に、イベント実行装置３２０の再生制御部（ＤＡＳＨクライアント）３２２は、ステップＳ２５において、ステップＳ２４で取得したセグメントからＡＶコンテンツ等を取得し再生処理を実行する。
【０１７２】
（ステップＳ２６）
次に、イベント実行装置３２０の再生制御部（イベントクライアント）３２１は、ステップＳ２６において、ＭＰＤから取得したイベント情報に従ってスケジューリングされたイベントの適用処理、すなわちイベントアクティベート（イベント実行、開始等）処理を行なう。
【０１７３】
（ステップＳ２７〜Ｓ２９）
ステップＳ２７〜Ｓ２９の処理は、ステップＳ２４〜Ｓ２６の処理と同様の処理である。
この一連の処理は、継続的に実行されることになる。
【０１７４】
このように、受信装置（クライアント）は、ＡＶセグメントを受信し再生する処理に併せて、ＭＰＤに記録されたイベント情報に従って、様々なイベントを実行することが可能となる。
【０１７５】
［６−２．セグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）について］
次に、ＤＡＳＨ規格において規定されたもう１つのイベント通知方式であるセグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）について説明する。
【０１７６】
セグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）は、ＡＶコンテンツ等を格納したセグメント（ＤＡＳＨセグメント）内にイベント情報を記録して受信装置に提供する方式である。
【０１７７】
図１に示す送信装置２０は、前述したように、コンテンツデータを符号化し、符号化データおよび符号化データのメタデータを含むデータファイルを生成し送信する。符号化処理は、例えばＭＰＥＧにおいて規定されるＭＰ４ファイルフォーマットに従って行われる。なお、送信装置２０がＭＰ４形式のデータファイルを生成する場合の符号化データのファイルは「ｍｄａｔ」、メタデータは「ｍｏｏｖ」や「ｍｏｏｆ」等と呼ばれる。
【０１７８】
送信装置２０が提供するコンテンツは、例えば音楽データや、映画、テレビ番組、ビデオ、写真、文書、絵画および図表などの映像データや、ゲームおよびソフトウェアなど、様々なデータである。
【０１７９】
図１２を参照して、ＤＡＳＨ規格に従ってコンテンツストリーム配信を行う場合に利用可能なＤＡＳＨセグメントの構成例について説明する。ＤＡＳＨセグメントは、
（ａ）初期化セグメント（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ  Ｓｅｇｍｅｎｔ）、
（ｂ）メディアセグメント（Ｍｅｄｉａ  Ｓｅｇｍｅｎｔ）（＝ＡＶセグメント）、
これらの２種類に分けられる。
【０１８０】
（ａ）初期化セグメント（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ  Ｓｅｇｍｅｎｔ）は、受信装置３０におけるデコーダの設定等、コンテンツ再生を実行するために必要となる設定情報等の初期化データを格納したセグメントである。
（ｂ）メディアセグメント（Ｍｅｄｉａ  Ｓｅｇｍｅｎｔ）（＝ＡＶセグメント）は、再生対象となる符号化コンテンツ（ＡＶコンテンツ）を格納したセグメントである。
【０１８１】
図１２に示すように（ａ）初期化セグメントは、以下の各情報を含む。
（ａ１）セグメントのファイルタイプ情報等からなるヘッダ情報（ｄａｓｈ）、
（ａ２）メディアセグメントによって送信する符号化コンテンツであるメディアデータ（ｍｄａｔ）のコーデック（符号化態様）情報等の初期化情報を含むメタデータ（ｍｏｏｖ）、
【０１８２】
一方、（ｂ）メディアセグメントは、図１２に示すように以下の各情報を含む。
（ｂ１）セグメントのファイルタイプ情報等からなるヘッダ情報（ｍｓｄｈ）、
（ｂ２）メディアセグメントに格納された複数のサブセグメント（Ｓｕｂ−Ｓｅｇｍｅｎｔ）の境界情報や、メディアセグメントに格納された符号化コンテンツであるメディアデータ（ｍｄａｔ）のランダムアクセスポイント等を示すアクセス情報（ｓｉｄｘ）、
（ｂ３）複数のサブセグメント（Ｓｕｂ−Ｓｅｇｍｅｎｔ）、
【０１８３】
また、複数のサブセグメント（Ｓｕｂ−Ｓｅｇｍｅｎｔ）は１つまたは複数のフラグメント（Ｆｒａｇｍｅｎｔ）で構成される。
フラグメント（Ｆｒａｇｍｅｎｔ）は、以下の各データを含む。
再生対象となる符号化コンテンツであるメディアデータ（ｍｄａｔ）、
メディアデータ（ｍｄａｔ）に対応するメタデータ（ｍｏｏｆ）、
メディアデータ（ｍｄａｔ）に対応する各種情報（制御情報、管理情報、属性情報など）。
【０１８４】
なお、メディアデータ（ｍｄａｔ）、メタデータ（ｍｏｏｆ）、その他の各種情報（制御情報、管理情報、属性情報など）は、ＭＰ４フォーマットにおいて定義されるボックスに個別に格納される。
ｍｄａｔボックスにはＡＶデータが格納される。
ｍｏｏｆボックスにはメタデータが格納される。
その他の各種情報も、それぞれの情報に応じて定義されるボックスに格納される。
【０１８５】
イベント情報は、各種情報の一部としてイベント情報を格納するためのボックスとしてＭＰ４フォーマットで定義されたイベント情報格納ボックス［ｅｍｓｇボックス］に格納される。
【０１８６】
セグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）において利用されるＭＰ４フォーマットデータ内のイベント情報格納ボックス（ｅｍｓｇ）のデータ構成例について、図１３を参照して説明する。
図１３には、イベント識別子１，２の２つのイベント情報を個別に格納した２つのイベント情報格納ボックス（ｅｍｓｇ）のデータを示している。
【０１８７】
イベント情報格納ボックス（ｅｍｓｇ）は、例えば以下の記述を有する。
ｂｏｘ＿ｔｙｐｅ＝'ｅｍｓｇ'
ｓｃｈｅｍｅ＿ｉｄ＿ｕｒｉ＝"ｕｒｎ：ｘｘｘ"
ｖａｌｕｅ＝０
ｔｉｍｅｓｃａｌｅ＝１０００
ｐｒｅｓｅｎｔａｔｉｏｎ＿ｔｉｍｅ＿ｄｅｌｔａ＝０
ｅｖｅｎｔ＿ｄｕｒａｔｉｏｎ  ＝  ０ｘＦＦＦＦ
ｉｄ＝１
ｍｅｓｓａｇｅ＿ｄａｔａ［］＝イベントデータ−１
【０１８８】
上記のイベント情報格納ボックス（ｅｍｓｇ）のデータ内容について説明する。
ｂｏｘ＿ｔｙｐｅ＝'ｅｍｓｇ'
このデータ記録記録領域はボックスタイプ記録領域である。このボックス（ＭＰ４において規定されるデータ格納ボックス）が、イベント情報格納ボックス（ｅｍｓｇ）であることを記述している。
【０１８９】
ｓｃｈｅｍｅ＿ｉｄ＿ｕｒｉ＝"ｕｒｎ：ｘｘｘ"
ｖａｌｕｅ＝０
このデータ記録記録領域は、イベント種類等を示すイベント指定情報の記録領域である。
「ｓｃｈｅｍｅ＿ｉｄ＿ｕｒｉ＝"ｕｒｎ：ｘｘｘ"」と、オプショナルな「ｖａｌｕｅ」によりイベントの種類等を定義する。
【０１９０】
ｔｉｍｅｓｃａｌｅ＝１０００
このデータ記録記録領域は、タイムスケール情報の記録領域である。
「ｔｉｍｅｓｃａｌｅ＝'１０００'」は、以下に記録されるプレゼンテーションタイム（ｐｒｅｓｅｎｔａｔｉｏｎＴｉｍｅ）の単位時間は１／１０００秒であることを示す。
【０１９１】
ｐｒｅｓｅｎｔａｔｉｏｎ＿ｔｉｍｅ＿ｄｅｌｔａ＝０
ｅｖｅｎｔ＿ｄｕｒａｔｉｏｎ＝０ｘＦＦＦＦ
これらのデータ記録記録領域は、イベントのアクティベート（実行開始等）時間や継続時間等のイベントスケジューリングデータの記録領域である。イベント指定情報によって特定されるイベントのアクティベート（活性化／実行）時刻＝０で、時刻＝０ｘＦＦＦＦまで継続することを指定している。なお、０ｘＦＦＦＦは終了時間を定義していないことを示し、このイベント情報格納ボックスの設定されたセグメントに対応するＡＶコンテンツの再生終了まで、イベントを継続してもしなくてもよいという指定であることを意味する。
【０１９２】
ｉｄ＝１
このデータ記録領域は、イベント識別情報記録領域である。
【０１９３】
ｍｅｓｓａｇｅ＿ｄａｔａ［］＝イベントデータ−１
このデータ記録領域は、イベントデータの記録領域である。
イベントデータは、イベントを実行するために必要となる実体データ、メタデータ、コマンド等のデータや、そのアクセス情報等によって構成される。
【０１９４】
このように、セグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）では、セグメントストリームの中（ｉｎ−ｓｔｒｅａｍ）にイベント情報を記録して転送することができる。
【０１９５】
セグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）では、「ｓｃｈｅｍｅ＿ｉｄ＿ｕｒｉ」フィールドと、オプショナルな「ｖａｌｕｅ」フィールドにイベントの種類を定義可能である。
また、「ｍｅｓｓａｇｅ＿ｄａｔａ」フィールドにイベントデータ、すなわち、イベントを実行するために必要となる実体データ、メタデータ、コマンド等のデータや、そのアクセス情報等を付加することができる。
【０１９６】
次に、図１４を参照して、イベント情報を記録したセグメントの生成（または取得）と出力を実行するイベント挿入実行装置３１０と、イベント記録情報セグメントを受領してセグメントに記録されたイベント情報に応じた処理を実行するイベント実行装置３２０の構成と処理例について説明する。
【０１９７】
図１４には、左側に、イベント情報を記録したセグメントの生成（または取得）と出力を実行するイベント挿入実行装置３１０を示している。
また、図１４の右側には、イベント情報を記録したセグメントを入力してセグメントに記録されたイベント情報に応じた処理（イベントアクティベート）を実行するイベント実行装置３２０を示している。
【０１９８】
イベント挿入実行装置３１０は、具体的には、ＭＰＤ等のシグナリングデータや、ＡＶセグメントを送信する放送サーバ２１、データ配信サーバ２２、あるいは、受信装置においてＭＰＤ等のシグナリングデータや、ＡＶセグメントを受信して、受信装置の再生制御部１３１に出力する受信装置のミドルウェア１１０（図５、図６に示すミドルウェア１１０）である。
【０１９９】
また、図１４の右側に示すイベント実行装置３２０は、具体的には、ＭＰＤ等のシグナリングデータや、ＡＶセグメントを入力してコンテンツ再生処理を実行する受信装置の再生制御部（図５、図６に示す再生制御部１３１，１５１）である。
【０２００】
イベント挿入実行装置３１０の実行する処理について説明する。
イベント挿入実行装置３１０は、データ出力部（ＤＡＳＨサーバ）３１１、イベント処理部（イベントサーバ）３１２を有する。
なお、これらのサーバ機能は、ＭＰＤ等のシグナリングデータや、ＡＶセグメントを送信する放送サーバ２１、データ配信サーバ２２、さらに、受信装置のミドルウェア１１０（図５、図６に示すミドルウェア１１０）が有する機能である。
以下、イベント挿入実行装置３１０の実行する処理について、処理ステップごとに説明する。
【０２０１】
（ステップＳ３１）
まず、イベント挿入実行装置３１０のデータ出力部（ＤＡＳＨサーバ）３１１は、ステップＳ３１において、シグナリングデータとしてのＭＰＤ、および再生コンテンツを構成するＡＶデータを含むセグメントを生成、または取得する。
【０２０２】
イベント挿入実行装置３１０が放送サーバ２１、データ配信サーバ２２である場合は、ＭＰＤ、セグメントを生成または取得する処理を行なう。
イベント挿入実行装置３１０が受信装置のミドルウェア１１０（図５、図６に示すミドルウェア１１０）である場合は、ＭＰＤ、セグメントを受信データから取得する処理を行なう。
【０２０３】
（ステップＳ３２）
次に、イベント挿入実行装置３１０のイベント処理部（イベントサーバ）３１２は、ステップＳ３２において、イベント情報を生成または、取得する。
イベント情報とは、例えば、番組表の変更や、放送コンテンツのデータ態様の変更、受信装置における放送コンテンツの再生時に実行すベき処理など、受信装置に対して何らかの処理の実行を通知あるいは要求するための情報である。
【０２０４】
イベント挿入実行装置３１０が放送サーバ２１、データ配信サーバ２２である場合は、イベント情報を生成または取得する処理を行なう。
イベント挿入実行装置３１０が受信装置のミドルウェア１１０（図５、図６に示すミドルウェア１１０）である場合は、イベント情報を受信データから取得する処理を行なう。
【０２０５】
（ステップＳ３３）
次に、イベント挿入実行装置３１０のデータ出力部（ＤＡＳＨサーバ）３１１は、ステップＳ３３において、セグメントに対して、イベント情報の挿入を行う。
この処理によって、先に図１３を参照して説明したＭＰ４フォーマットにおいて規定されるイベント情報記録ボックスであるｅｍｓｇボックスを含むセグメントが生成される。
【０２０６】
図１３に示すイベント情報記録ボックス（ｅｍｓｇ）ｉは、先に説明したように、
イベントの種類、内容や、イベントのアクティベート（活性化）時刻、継続時間情報等が記録されている。
受信装置は、このセグメント内のｅｍｓｇボックスに記録されたイベント情報に従って、指定されたイベントを指定時間にアクティベート（例えば実行）し、指定継続時間、継続させる処理などを行うことが可能となる。
【０２０７】
（ステップＳ３４）
次に、イベント挿入実行装置３１０のデータ出力部（ＤＡＳＨサーバ）３１１は、ステップＳ３４において、シグナリングデータとしてのＭＰＤを送信（出力）する。
【０２０８】
イベント挿入実行装置３１０が放送サーバ２１、データ配信サーバ２２である場合は、ＭＰＤを、放送波またはネットワークを介して送信する。
イベント挿入実行装置３１０が受信装置のミドルウェア１１０（図５、図６に示すミドルウェア１１０）である場合は、ＭＰＤをプロキシサーバ、あるいは再生制御部に出力する。
【０２０９】
（ステップＳ３５〜Ｓ３６）
次に、イベント挿入実行装置３１０のデータ出力部（ＤＡＳＨサーバ）３１１は、ステップＳ３５〜Ｓ３６において、ＡＶコンテンツ等を格納したセグメントを送信（出力）する。
送信するセグメントは、ＭＰ４フォーマットにおいて規定されるイベント情報記録ボックス（ｅｍｓｇ）を含むセグメントである。
セグメント送信は、ステップＳ３６以降、継続的に実行される。
【０２１０】
イベント挿入実行装置３１０が放送サーバ２１、データ配信サーバ２２である場合は、セグメントを、放送波またはネットワークを介して送信する。
イベント挿入実行装置３１０が受信装置のミドルウェア１１０（図５、図６に示すミドルウェア１１０）である場合は、セグメントを、プロキシサーバ、あるいは再生制御部に出力する。
【０２１１】
次に、図１４の右側に示すイベント実行装置３２０の実行する処理について説明する。
イベント実行装置３２０は、具体的には、ＭＰＤ等のシグナリングデータや、ＡＶセグメントを入力してコンテンツ再生処理を実行する受信装置の再生制御部（図５、図６に示す再生制御部１３１，１５１）である。
【０２１２】
図１４に示すイベント実行装置３２０の実行する処理は、受信装置の再生制御部１３１，１５１において実行する処理である。
なお、図１４においては、再生制御部を、実行する処理の種類に応じて分離して示している。すなわち、イベント対応処理実行部としての再生制御部（イベントクライアント）３２１と、ＭＰＤやＡＶセグメントを適用したコンテンツ再生処理を実行する再生制御部（ＤＡＳＨクライアント）３２２の２つの処理部に区分して示している。
【０２１３】
（ステップＳ４１）
まず、イベント実行装置３２０の再生制御部（ＤＡＳＨクライアント）３２２は、ステップＳ４１において、イベント挿入実行装置３１０に対してシグナリングデータとしてのＭＰＤの取得要求を行う。
【０２１４】
（ステップＳ４２）
次に、イベント実行装置３２０の再生制御部（ＤＡＳＨクライアント）３２２は、ステップＳ４４において、イベント挿入実行装置３１０に対してセグメントの取得要求を行う。
【０２１５】
（ステップＳ４３）
次に、イベント実行装置３２０の再生制御部（ＤＡＳＨクライアント）３２２は、ステップＳ４２において、イベント挿入実行装置３１０から取得したセグメントからイベント情報を取得する。
【０２１６】
なお、ここで取得したセグメントは、イベント情報記録ボックス（ｅｍｓｇ）を有する。すなわち、図１３に示すイベント情報を記録したイベント情報記録ボックス（ｅｍｓｇ）を含むセグメント（イベント情報記録セグメント）であるものとする。
【０２１７】
イベント情報記録セグメントには、イベントの種類、内容や、イベントのアクティベート（活性化）時刻、継続時間情報等が記録されている。
受信装置は、このセグメントに記録されたイベント情報に従って、指定されたイベントを指定時間にアクティベート（例えば実行）し、指定継続時間、継続させる処理などを行うことが可能となる。
【０２１８】
（ステップＳ４４）
次に、イベント実行装置３２０の再生制御部（イベントクライアント）３２１は、ステップＳ４４において、セグメントから取得したイベント情報に従ってスケジューリングされたイベントの適用処理、すなわちイベントアクティベート（イベント実行、開始等）処理を行なう。
【０２１９】
（ステップＳ４５）
次に、イベント実行装置３２０の再生制御部（ＤＡＳＨクライアント）３２２は、ステップＳ４５において、ステップＳ４２で取得したセグメントからＡＶコンテンツ等を取得し再生処理を実行する。
【０２２０】
（ステップＳ４６〜Ｓ４９）
ステップＳ４６〜Ｓ４９の処理は、ステップＳ４２〜Ｓ４５の処理と同様の処理である。
この一連の処理は、セグメント単位の処理として継続的に実行されることになる。
【０２２１】
このように、受信装置（クライアント）は、ＡＶセグメントを受信し再生する処理に併せて、セグメント内のイベント情報記録ボックス（ｅｍｓｇ）に記録されたイベント情報に従って、様々なイベントを実行することが可能となる。
【０２２２】
［７．アプリケーション制御メッセージの通知処理について］
次に、上述したイベント通知機構を利用してアプリケーション制御メッセージを通知する構成について説明する。
【０２２３】
［７−１．イベント通知機構を利用したアプリケーション制御メッセージ通知構成の概要］
先に図５、図６を参照して説明したチューナ実装受信装置（クライアントＡ）３０と、チューナ非実装受信装置（クライアントＢ）４０は、いずれも、アプリケーション制御部１４０，１６０を有する。
アプリケーション制御部１４０，１６０は、例えば放送コンテンツの再生処理に併せて実行する様々なアプリケーションの制御を実行する。
【０２２４】
アプリケーションとは、例えば、前述したように旅番組におけるホテル案内情報の表示アプリケーションや、クイズやアンケート用のアプリケーション等、様々であるが、これらのアプリケーションは、特定の放送コンテンツにおいて、決められたタイミングで実行しなければ意味がない。従って、アプリケーション制御部１４０，１６０は、予め規定されたタイミングに従って、アプリケーションの取得、アプリケーションの実行、終了等の制御を行う必要がある。
【０２２５】
アプリケーション制御部１４０，１６０は、アプリケーションファイルの取得（ダウンロード）、起動、終了、停止、一時停止、可視化、不可視化、削除等アプリケーションを対象とした様々な制御を行う。
【０２２６】
アプリケーション制御部１４０，１６０に対して、上記の様々なアプリケーション制御を実行させるためには、アプリケーション制御部１４０，１６０に対して、制御内容や、制御タイミングを通知することが必要である。
この通知情報が、図６に示すアプリケーション制御メッセージ（ＡＣＭ：Ａｐｐｌｉｃａｔｉｏｎ  Ｃｏｎｔｒｏｌ  Ｍｅｓｓａｇｅ）である。
【０２２７】
アプリケーション制御メッセージ（ＡＣＭ）は、シグナリングデータとしてのＭＰＤや、セグメント内に記録されており、再生制御部１３１，１５１はＭＰＤや、セグメントにアプリケーション制御メッセージ（ＡＣＭ）が含まれている場合、これをアプリケーション制御部１４０，１６０に出力する処理を実行する。
【０２２８】
アプリケーション制御メッセージは、上述したイベント通知機構を利用して送信、出力される。以下、このイベント通知機構を利用したアプリケーション制御メッセージの通知構成の詳細について説明する。
【０２２９】
上述したように、ＤＡＳＨ規格では、イベント通知機構として以下の２種類のタイプのイベント通知方式が規定されている。
（ａ）ＭＰＤ適用イベント通知方式（＝ＭＰＤ  Ｅｖｅｎｔ）、
（ｂ）セグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）
これらの２種類のイベント通知方式が規定されている。
【０２３０】
（ａ）ＭＰＤ適用イベント通知方式（＝ＭＰＤ  Ｅｖｅｎｔ）を用いてイベント通知を行う場合の具体的なデータ構成例は図９を参照して説明した通りである。
（ｂ）セグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）を用いてイベント通知を行う場合の具体的なデータ構成例は図１３を参照して説明した通りである。
【０２３１】
これらのいずれの方式においてもイベント通知メッセージ内には、イベントの種類を特定するための情報としてイベント種類情報が記録される。
図９に示すイベント情報格納ＭＰＤでは、
「ＥｖｅｎｔＳｔｒｅａｍ  ｓｃｈｅｍｅＩｄＵｒｉ＝'ｕｒｎ：ｘｘｘ'」と、オプショナルな「ＥｖｅｎｔＳｔｒｅａｍ／＠ｖａｌｕｅ」によりイベントの種類が定義される。
また、図１３に示すセグメント内のイベント情報格納ボックス（ｅｍｓｇ）の記述では、
ｓｃｈｅｍｅ＿ｉｄ＿ｕｒｉ＝"ｕｒｎ：ｘｘｘ"
このデータ記録記録領域が、イベント種類等を示すイベント指定情報の記録領域である。
【０２３２】
このイベント種類の１つとして、アプリケーション制御メッセージ（ＡＣＭ：Ａｐｐｌｉｃａｔｉｏｎ  Ｃｏｎｔｒｏｌ  Ｍｅｓｓａｇｅ）を定義する。
すなわち、ＭＰＤやセグメントを用いて実行するイベント通知において通知するイベントの種類が、アプリケーション制御メッセージ（ＡＣＭ：Ａｐｐｌｉｃａｔｉｏｎ  Ｃｏｎｔｒｏｌ  Ｍｅｓｓａｇｅ）であることを示すイベント種類を定義する。
具体的には、例えば、
ｓｃｈｅｍｅＩｄＵｒｉ＝ｕｒｎ：ａｔｓｃ：ａｐｐＣｏｎｔｒｏｌＭｅｓｓａｇｅ
上記のｓｃｈｅｍｅＩｄＵｒｉを、アプリケーション制御メッセージ（ＡＣＭ）を示すイベント種類識別子とする。
【０２３３】
なお、上記の識別子は一例であり、受信装置が、ＭＰＤまたはセグメントから抽出したイベント情報が、アプリケーション制御メッセージ（ＡＣＭ）に関するイベント情報であることが判別できるデータ（文字列やコード）であれば、様々な識別子が利用可能である。
【０２３４】
さらに、図９、図１３を参照して説明した以下の２つのイベント通知方式、すなわち、
（ａ）ＭＰＤ適用イベント通知方式（＝ＭＰＤ  Ｅｖｅｎｔ）、
（ｂ）セグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）
これらの２種類のイベント通知方式のいずれにおいてもイベントデータが格納される。
イベントデータは、イベントを実行するために必要となる実体データ、メタデータ、コマンド等のデータや、そのアクセス情報等によって構成される。
【０２３５】
図９に示すイベント情報格納ＭＰＤでは、例えば、
「＜Ｅｖｅｎｔ  ｐｒｅｓｅｎｔａｔｉｏｎＴｉｍｅ＝'０'  ｄｕｒａｔｉｏｎ＝'１０００'＞イベントデータ１＜／Ｅｖｅｎｔ＞」に、イベントデータが記録される。
また、図１３に示すセグメント内のイベント情報格納ボックス（ｅｍｓｇ）の記述では、例えば、
「ｍｅｓｓａｇｅ＿ｄａｔａ［］＝イベントデータ−１」に、イベントデータが記録される。
【０２３６】
図９や図１３に示すイベント通知メッセージを利用してアプリケーション制御メッセージ（ＡＣＭ（Ａｐｐｌｉｃａｔｉｏｎ  Ｃｏｎｔｒｏｌ  Ｍｅｓｓａｇｅ）を通知する場合に、これらのイベント通知メッセージに記録するイベントデータの例について、図１５を参照して説明する。
【０２３７】
図１５には、イベント通知メッセージ内にイベントデータとして格納するアプリケーション制御メッセージ（ＡＣＭ）の以下の２つの構成例を示している。
（１）アプリケーション本体非格納型ＡＣＭ
（２）アプリケーション本体格納型ＡＣＭ
【０２３８】
（１）アプリケーション本体非格納型ＡＣＭは、アプリケーション本体は格納しないタイプであり、アプリケーション本体を取得するためのアクセス情報を格納している。
（２）アプリケーション本体格納型ＡＣＭは、アプリケーション本体を格納したタイプである。
【０２３９】
（１）アプリケーション本体非格納型ＡＣＭの構成要素は以下の通りである。
（１ａ）アプリケーション識別子
（１ｂ）アプリケーションメタデータ（オプショナル）
（１ｃ）アプリケーション制御コマンド
【０２４０】
（２）アプリケーション本体格納型ＡＣＭの構成要素は以下の通りである。
（２ａ）アプリケーション識別子＋アプリケーション本体
（２ｂ）アプリケーションメタデータ（オプショナル）
（２ｃ）アプリケーション制御コマンド
【０２４１】
以下、これらの格納データについて説明する。
【０２４２】
（１ａ）（２ａ）に含まれるアプリケーション識別子は、アプリケーション制御メッセージ（ＡＣＭ）の制御対象となるアプリケーションのＵＲＬ等、アプリケーションの識別や取得処理に必要な情報である。アプリケーション制御メッセージ（ＡＣＭ）の制御対象となるアプリケーションが複数のアプリケーションである場合は、複数のアプリケーションを取得可能な識別子が設定される。
例えばパッケージ化されたアプリケーションの識別子、あるいはアプリケーション個別の識別子の集合等である。
【０２４３】
なお、アプリケーション本体が識別子のｕｒｌで指定される場合、放送で取得する場合と、ネット経由で取得する場合がある。ネット経由の場合は、通常のネット系スタックによりＨＴＴＰにより取得される。放送で取得する場合は、シグナリングデータを格納したシグナリナングファイルや、ＤＡＳＨセグメントファイルと同様に、ＲＯＵＴＥプロトコルに従って転送される。なお、ファイルとして非同期に放送蓄積される場合はＮＲＴ（Ｎｏｎ  Ｒｅａｌ  Ｔｉｍｅ）ファイルと呼ぶ。
【０２４４】
（２ａ）に含まれるアプリケーション本体は、アプリケーション制御メッセージ（ＡＣＭ）の制御対象となるアプリケーションそのものである。なお、複数のアプリケーションがパッケージングされた構成である場合もある。
【０２４５】
（１ｂ），（２ｂ）に示すアプリケーションのメタデータはアプリケーションの属性情報である。
なお、アプリケーションメタデータは、ＡＣＭに格納する必須要素ではなく、すべてオプショナルである。
【０２４６】
以下、ＡＣＭに格納する優先度の高いメタデータ、優先度が中程度のメタデータ、優先度の低いメタデータに分類して示す。
【０２４７】
（Ａ）ＡＣＭに格納する優先度の高いメタデータ
（ａ１）バージョン（Ｖｅｒｓｉｏｎ）情報：アプリケーションのバージョン（識別子（Ｉｄｅｎｔｉｆｉｅｒ）とバージョン（Ｖｅｒｓｉｏｎ）によってアプリケーションのインスタンスが一意に識別される）
（ａ２）関連ファイル（Ｒｅｌａｔｅｄ  ｆｉｌｅｓ）情報：アプリケーションを実行するために必要な他の関連するファイル・リソース
（ａ３）アプリケーションレーティング（Ｃｏｎｔｅｎｔ  ａｄｖｉｓｏｒｙ  ｒａｔｉｎｇ）情報：アプリケーションのレーティング情報
【０２４８】
（Ｂ）ＡＣＭに格納する優先度が中程度のメタデータ
（ｂ１）アプリケーション名（Ｎａｍｅ）情報：アプリケーションのユーザ提示用の名前
（ｂ２）優先度（Ｐｒｉｏｒｉｔｙ）情報：アプリケーションの他アプリケーションに対する相対的な優先度
（ｂ３）セキュリティプロパティ（Ｓｅｃｕｒｉｔｙ  ｐｒｏｐｅｒｔｉｅｓ）情報：アプリケーションのセキュリティプロパティ情報、例えばＣＡＳ／ＤＲＭ情報
【０２４９】
（Ｃ）ＡＣＭに格納する優先度の低いメタデータ
（ｃ１）タイプ（Ｔｙｐｅ）情報：アプリケーションのタイプ（種類）
（ｃ２）プロファイル（Ｐｒｏｆｉｌｅ）情報：アプリケーションを実行するにあたり要求されるデバイスの能力属性（コーデックの種類やメモリ容量等）
（ｃ３）アイコン（Ｉｃｏｎｓ）情報：アプリケーションを識別するアイコン（アプリケーションランチャー等に表示される）
（ｃ４）ストレージ（Ｓｔｏｒａｇｅ  ｈｉｎｔｓ）情報：ローカルストレージや経路上のデバイスのキャッシュに格納可能かのヒント情報
（ｃ５）ターゲットプロパティ（Ｔａｒｇｅｔｉｎｇ  ｐｒｏｐｅｒｔｉｅｓ）情報：アプリケーションが消費されるべき対象を識別する属性（対象地域やユーザのクラス等）
【０２５０】
図１５に示す（１ｃ），（２ｃ）アプリケーション制御コマンドの記録領域には、制御対象となるアプリケーションに対する制御コマンドと、実行タイミング等の情報を記録する。
制御コマンドの種類としては、例えば、アプリケーションの起動（実行）、停止（一時停止（状態保持）を含む）、可視化／不可視化、削除（ローカルストレージにキャシュされる場合にその削除）等がある。
これらのコマンドのそれぞれについて、実行するタイミング、例えばあるストリーム（ＡＶストリーム）に付随する時間軸上の時刻（ＮＰＴ：Ｎｏｒｍａｌ  Ｐｌａｙ  Ｔｉｍｅの概念）や、絶対時刻（ｗａｌｌ  ｃｌｏｃｋ  ｔｉｍｅ）を記録する。
【０２５１】
図１５に示す（１ｃ），（２ｃ）アプリケーション制御コマンドの記録領域に記録する制御コマンドと具体的処理（コード）の例としては、以下のものがある。
＊ダウンロード（Ｄｏｗｎｌｏａｄ）：アプリケーションをダウンロードする
＊アクティベート（Ａｃｔｉｖａｔｉｏｎ（ｓｔａｒｔ））：アプリケーションを起動する
＊ターミネーション（Ｔｅｒｍｉｎａｔｉｏｎ（ｓｔｏｐ））：アプリケーションを停止する
＊サスペンション（Ｓｕｓｐｅｎｓｉｏｎ（ｐａｕｓｅ））：アプリケーションを一時停止する
＊データイベント（ＤａｔａＥｖｅｎｔ）：アプリケーションにデータを渡す（消費させる）
例えばこれらの制御コマンドがある。
【０２５２】
なお、図１５に示す（１ｃ），（２ｃ）アプリケーション制御コマンドの記録領域には、これらのコマンドの実行に際して適用するパラメータについても記録可能である。
パラメータとしては、例えば以下のパラメータ（ｐ１），（ｐ２）がある。
（ｐ１）Ｔｉｍｅ  ｏｆ  ｔｈｅ  ａｃｔｉｏｎ：  ｍｅｄｉａ  ｔｉｍｅ  ｌｉｎｅ
これは、アプリケーションが同期して実行制御される対象のストリームの時間軸を示すパラメータである。
（ｐ２）Ｒｅｑｕｉｒｅｄ  ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ  ｌｅｖｅｌ
これは、同期の精度のレベル（例えば、ｐｒｏｇｒａｍ  ｌｅｖｅｌ，〜２ｓｅｃ，ｌｉｐ  ｓｙｎｃ，  ｆｒａｍｅ  ｓｙｎｃ）を示すパラメータである。
これらのパラメータは、上記の制御コマンドの全てに付随して設定されるパラメータである。
【０２５３】
また、「ダウンロード（Ｄｏｗｎｌｏａｄ）」、「アクティベート（Ａｃｔｉｖａｔｉｏｎ（ｓｔａｒｔ））」、これらの制御コマンドに特有のパラメータとして、以下のパラメータ（ｐ３）がある。
（ｐ３）Ｔａｒｇｅｔ  ｄｅｖｉｃｅ
これは、対象アプリケーションをダウンロード、アクティベートする対象デバイス（ｐｒｉｍａｒｙ（プライマリ−ＴＶ等）／ｃｏｍｐａｎｉｏｎ（コンパニオン−タブレットや携帯等））を示すパラメータである。
【０２５４】
また、「データイベント（ＤａｔａＥｖｅｎｔ）」対応のパラメータとして以下のパラメータ（ｐ４）がある。
（ｐ４）Ｄａｔａ
これは、対象アプリケーションに渡すデータを示すパラメータである。
【０２５５】
先に説明したように、ＤＡＳＨ規格では、イベント通知機構として以下の２種類のタイプのイベント通知方式が規定されている。
（ａ）ＭＰＤ適用イベント通知方式（＝ＭＰＤ  Ｅｖｅｎｔ）、
（ｂ）セグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）
これらの２種類のイベント通知方式が規定されている。
以下、これらの２つのイベント通知方式を適用して、アプリケーション制御メッセージを通知する処理例について説明する。
【０２５６】
［７−２．ＭＰＤ適用イベント通知方式（＝ＭＰＤ  Ｅｖｅｎｔ）を適用したアプリケーション制御メッセージの通知構成］
次に、ＭＰＤ適用イベント通知方式（＝ＭＰＤ  Ｅｖｅｎｔ）を適用したアプリケーション制御メッセージの通知構成について説明する。
【０２５７】
図１６は、ＭＰＤを用いたイベント通知、すなわち、ＭＰＤ適用イベント通知方式（＝ＭＰＤ  Ｅｖｅｎｔ）を適用してアプリケーション制御メッセージを通知する場合のＭＰＤの記述例を示す図である。
図１６に示すようにアプリケーション制御メッセージを含むＭＰＤは、例えば以下の記述を有する。
【０２５８】
＜ＭＰＤ  ａｖａｉｌａｂｉｌｉｔｙＳｔａｒｔＴｉｍｅ＝"２０１１−１２−２５Ｔ１２：３０：００
＜Ｐｅｒｉｏｄ  ｓｔａｒｔＴｉｍｅ＝'０'＞
・・・
＜ＥｖｅｎｔＳｔｒｅａｍ  ｓｃｈｅｍｅＩｄＵｒｉ＝'ｕｒｎ：ａｔｓｃ：ａｐｐＣｏｎｔｒｏｌＭｅｓｓａｇｅ'  ｔｉｍｅｓｃａｌｅ＝'１０００'＞
＜Ｅｖｅｎｔ  ｐｒｅｓｅｎｔａｔｉｏｎＴｉｍｅ＝'０'  ｄｕｒａｔｉｏｎ＝'１０００'＞ＡＣＭ1格納＜／Ｅｖｅｎｔ＞
＜Ｅｖｅｎｔ  ｐｒｅｓｅｎｔａｔｉｏｎＴｉｍｅ＝'１０００'  ｄｕｒａｔｉｏｎ＝'４０００'＞ＡＣＭ2格納＜／Ｅｖｅｎｔ＞
…．
＜／ＥｖｅｎｔＳｔｒｅａｍ＞
・・・
＜ＡｄａｐｔａｔｉｏｎＳｅｔ＞
＜Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ／＞
＜Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ／＞
＜／ＡｄａｐｔａｔｉｏｎＳｅｔ＞
・・・
＜／Ｐｅｒｉｏｄ＞
＜／ＭＰＤ＞
【０２５９】
上記のＭＰＤのデータ内容について説明する。
＜ＭＰＤ  ａｖａｉｌａｂｉｌｉｔｙＳｔａｒｔＴｉｍｅ＝"２０１１−１２−２５Ｔ１２：３０：００
このデータ記録記録領域は、このＭＰＤに記録されたデータに対応する最初のピリオドの開始時刻情報の記録領域である。時刻情報としては例えばＵＴＣ時刻が用いられる。
【０２６０】
＜Ｐｅｒｉｏｄ  ｓｔａｒｔＴｉｍｅ＝'０'＞
このデータ記録記録領域は、ピリオド開始時間情報記録領域である。ＭＰＤにおいて規定されるスタート時間（ＭＰＤ／＠ａｖａｉｌａｂｉｌｉｔｙＳｔａｒｔＴｉｍｅ）からのオフセット時間が記録される。
【０２６１】
＜ＥｖｅｎｔＳｔｒｅａｍ  ｓｃｈｅｍｅＩｄＵｒｉ＝'ｕｒｎ：ａｔｓｃ：ａｐｐＣｏｎｔｒｏｌＭｅｓｓａｇｅ'  ｔｉｍｅｓｃａｌｅ＝'１０００'＞
このデータ記録記録領域は、イベント種類等を示すイベントストリーム指定情報とタイムスケール情報の記録領域である。
【０２６２】
「ＥｖｅｎｔＳｔｒｅａｍ  ｓｃｈｅｍｅＩｄＵｒｉ＝'ｕｒｎ：ａｔｓｃ：ａｐｐＣｏｎｔｒｏｌＭｅｓｓａｇｅ'」は、
このイベント通知がアプリケーション制御メッセージ（ＡＣＭ）を通知するイベント通知であることを示している。
さらに、「ｔｉｍｅｓｃａｌｅ＝'１０００'」は、以下に記録されるプレゼンテーションタイム（ｐｒｅｓｅｎｔａｔｉｏｎＴｉｍｅ）の単位時間は１／１０００秒であることを示す。
【０２６３】
＜Ｅｖｅｎｔ  ｐｒｅｓｅｎｔａｔｉｏｎＴｉｍｅ＝'０'  ｄｕｒａｔｉｏｎ＝'１０００'＞ＡＣＭ1格納＜／Ｅｖｅｎｔ＞
このデータ記録記録領域は、イベントデータの記録領域と、イベントのアクティベート（実行開始等）時間や継続時間等のイベントスケジューリングデータの記録領域である。
この例では、イベントデータとして、アプリケーション制御メッセージ１（ＡＣＭ1）が格納されている。
さらに、イベントのアクティベート（実行開始等）時間や継続時間が記録される。
この例は、イベントデータ１によって特定されるイベントを、アクティベート（活性化／実行）時刻＝０で１０００単位時間継続することを指定している。
【０２６４】
イベントデータとして格納するアプリケーション制御メッセージ１（ＡＣＭ1）は。例えば、アプリケーション本体または識別子、メタデータ、コマンド等のデータである。
アプリケーション制御メッセージ１（ＡＣＭ1）の具体例を図１７（１）に示す。
図１７（１）に示すアプリケーション制御メッセージ１（ＡＣＭ1）は、先に図１５（１）を参照して説明したアプリケーション本体非格納型（ＡＣＭ）と同様のデータ構成であり、以下のデータ構成要素を持つ。
（１ａ）アプリケーション識別子
（１ｂ）アプリケーションメタデータ（オプショナル）
（１ｃ）アプリケーション制御コマンド
これらの各データ要素の詳細は、先に図１５を参照して説明した通りである。
【０２６５】
図１７（１）に示す例では、
（１ａ）アプリケーション識別子＝ｕｒｉ−１
（１ｃ）アプリケーション制御コマンド＝［アクティベート（Ａｃｔｉｖａｔｉｏｎ）］
これらを記録している。
コマンド［アクティベート（Ａｃｔｉｖａｔｉｏｎ）］は、アプリケーションを起動するコマンドである。
【０２６６】
すなわち、
＜Ｅｖｅｎｔ  ｐｒｅｓｅｎｔａｔｉｏｎＴｉｍｅ＝'０'  ｄｕｒａｔｉｏｎ＝'１０００'＞ＡＣＭ1格納＜／Ｅｖｅｎｔ＞
この記述は、
（１ａ）アプリケーション識別子＝ｕｒｉ−１
によって識別され、取得されるアプリケーションを
時間＝０において、
（１ｃ）アプリケーション制御コマンド＝［アクティベート（Ａｃｔｉｖａｔｉｏｎ）］
に従って、起動処理を実行し、
１０００単位時間継続する処理の実行を指定した記述である。
【０２６７】
＜Ｅｖｅｎｔ  ｐｒｅｓｅｎｔａｔｉｏｎＴｉｍｅ＝'１０００'  ｄｕｒａｔｉｏｎ＝'４０００'＞ＡＣＭ2格納＜／Ｅｖｅｎｔ＞
このデータ記録記録領域も、イベントデータの記録領域と、イベントのアクティベート（実行開始等）時間や継続時間等のイベントスケジューリングデータの記録領域である。
この例では、イベントデータとして、アプリケーション制御メッセージ２（ＡＣＭ2）が格納されている。
さらに、イベントのアクティベート（実行開始等）時間や継続時間が記録される。
この例は、イベントデータ１によって特定されるイベントを、アクティベート（活性化／実行）時刻＝１０００で４０００単位時間継続することを指定している。
【０２６８】
イベントデータとして格納するアプリケーション制御メッセージ２（ＡＣＭ2）は。例えば、アプリケーション本体または識別子、メタデータ、コマンド等のデータである。
アプリケーション制御メッセージ２（ＡＣＭ2）の具体例を図１７（２）に示す。
図１７（２）に示すアプリケーション制御メッセージ２（ＡＣＭ2）は、先に図１５（１）を参照して説明したアプリケーション本体非格納型（ＡＣＭ）をさらに簡略化したデータ構成であり、以下のデータ構成要素を持つ。
（１ａ）アプリケーション識別子
（１ｃ）アプリケーション制御コマンド
【０２６９】
このＡＣＭの例は、アプリケーションメタデータを有していない。
このＡＣＭ2は、ＡＣＭ1と同じアプリケーションに対する処理を実行させるためのＡＣＭであり、ＡＣＭ1に格納されたメタデータと同一のメタデータが適用可能なため、メタデータ格納領域が省略されている。
【０２７０】
図１７（２）に示す例では、
（１ａ）アプリケーション識別子＝ｕｒｉ−１
（１ｃ）アプリケーション制御コマンド＝［ターミネート（Ｔｅｒｍｉｎａｔｅ）］
これらを記録している。
コマンド［ターミネート（Ｔｅｒｍｉｎａｔｅ）］は、アプリケーションを停止するコマンドである。
【０２７１】
すなわち、
＜Ｅｖｅｎｔ  ｐｒｅｓｅｎｔａｔｉｏｎＴｉｍｅ＝'１０００'  ｄｕｒａｔｉｏｎ＝'４０００'＞ＡＣＭ2格納＜／Ｅｖｅｎｔ＞
この記述は、
（１ａ）アプリケーション識別子＝ｕｒｉ−１
によって識別され、取得されるアプリケーションを
時間＝１０００において、
（１ｃ）アプリケーション制御コマンド＝［ターミネート（Ｔｅｒｍｉｎａｔｅ）］
に従って、停止処理を実行し、
４０００単位時間継続する処理の実行を指定した記述である。
【０２７２】
以下の、
＜ＡｄａｐｔａｔｉｏｎＳｅｔ＞
＜Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ／＞
＜Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ／＞
これらは、各データ種類別の情報を記録するデータ記録領域である。
【０２７３】
このように、ＭＰＤを用いたイベントとしてのアプリケーション制御メッセージ（ＡＣＭ）通知、すなわち、ＭＰＤ適用イベント通知方式（ＭＰＤ  Ｅｖｅｎｔ）を適用して、アプリケーション制御メッセージ（ＡＣＭ）を通知することができる。
【０２７４】
先に図７、図８等を参照して説明したように、ＭＰＤには、データ種別、時間単位のセグメント対応情報を記録することができる。
このＭＰＤを利用してアプリケーション制御メッセージ（ＡＣＭ）を通知することで、受信装置において再生対象とするデータ種別、時間単位のセグメントに対応付けたアプリケーション制御メッセージ（ＡＣＭ）を提供することが可能となる。
【０２７５】
なお、シグナリングデータであるＭＰＤは、ＡＶコンテンツに先行して受信装置に提供されるため、このＭＰＤを用いたＡＣＭイベントの通知処理は、ＭＰＤ内において処理時間範囲として規定されたピリオド（Ｐｅｒｉｏｄ）の時間区間に渡って予めイベントの実行タイミング等が予測できる場合に利用可能である。
具体例としては、ライブ放送というよりは、オフラインコンテンツ（事前収録番組や映画番組等）において利用可能である。
【０２７６】
［７−３．セグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）を適用したアプリケーション制御メッセージの通知構成］
次に、セグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）を適用したアプリケーション制御メッセージの通知構成について説明する。
【０２７７】
図１８は、セグメントを用いたイベント通知、すなわち、セグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）において利用されるＭＰ４フォーマットデータ内のイベント情報格納ボックス（ｅｍｓｇ）を適用してアプリケーション制御メッセージを通知する場合のセグメント中の［イベント情報格納ボックス（ｅｍｓｇ）］の記述例を示す図である。
なお、フォーマットはバイナリのビットストリーム表現でエンコードされる場合も、ＸＭＬ等によるテキストでエンコードされる場合もある。
【０２７８】
図１８には、イベント識別子１，２によって識別されるアプリケーション制御メッセージ１，２（ＡＣＭ1，2）の２つのＡＣＭを個別に格納した２つのイベント情報格納ボックス（ｅｍｓｇ）のデータを示している。
図１８に示すようにアプリケーション制御メッセージ（ＡＣＭ）を含むセグメントは、例えば以下の記述を有する。
【０２７９】
ｂｏｘ＿ｔｙｐｅ＝'ｅｍｓｇ'
ｓｃｈｅｍｅ＿ｉｄ＿ｕｒｉ＝"ｕｒｎ：ａｔｓｃ：ａｐｐＣｏｎｔｒｏｌＭｅｓｓａｇｅ"
ｖａｌｕｅ＝０
ｔｉｍｅｓｃａｌｅ＝１０００
ｐｒｅｓｅｎｔａｔｉｏｎ＿ｔｉｍｅ＿ｄｅｌｔａ＝０
ｅｖｅｎｔ＿ｄｕｒａｔｉｏｎ  ＝  ０ｘＦＦＦＦ
ｉｄ＝１
ｍｅｓｓａｇｅ＿ｄａｔａ［］＝ＡＣＭ1
【０２８０】
上記のイベント情報格納ボックス（ｅｍｓｇ）のデータ内容について説明する。
ｂｏｘ＿ｔｙｐｅ＝'ｅｍｓｇ'
このデータ記録記録領域はボックスタイプ記録領域である。このボックス（ＭＰ４において規定されるデータ格納ボックス）が、イベント情報格納ボックス（ｅｍｓｇ）であることを記述している。
【０２８１】
ｓｃｈｅｍｅ＿ｉｄ＿ｕｒｉ＝"ｕｒｎ：ａｔｓｃ：ａｐｐＣｏｎｔｒｏｌＭｅｓｓａｇｅ"
ｖａｌｕｅ＝０
このデータ記録記録領域は、イベント種類等を示すイベント指定情報の記録領域である。
「ｓｃｈｅｍｅ＿ｉｄ＿ｕｒｉ＝"ｕｒｎ：ａｔｓｃ：ａｐｐＣｏｎｔｒｏｌＭｅｓｓａｇｅ"」は、
このイベント通知がアプリケーション制御メッセージ（ＡＣＭ）を通知するイベント通知であることを示している。
【０２８２】
ｔｉｍｅｓｃａｌｅ＝１０００
このデータ記録記録領域は、タイムスケール情報の記録領域である。
「ｔｉｍｅｓｃａｌｅ＝'１０００'」は、以下に記録されるプレゼンテーションタイム（ｐｒｅｓｅｎｔａｔｉｏｎＴｉｍｅ）の単位時間は１／１０００秒であることを示す。
【０２８３】
ｐｒｅｓｅｎｔａｔｉｏｎ＿ｔｉｍｅ＿ｄｅｌｔａ＝０
ｅｖｅｎｔ＿ｄｕｒａｔｉｏｎ＝０ｘＦＦＦＦ
これらのデータ記録記録領域は、イベントのアクティベート（実行開始等）時間や継続時間等のイベントスケジューリングデータの記録領域である。イベント指定情報によって特定されるイベントのアクティベート（活性化／実行）時刻＝０で、時刻＝０ｘＦＦＦＦまで継続することを指定している。なお、０ｘＦＦＦＦは終了時間を定義していないことを示し、このイベント情報格納ボックスの設定されたセグメントに対応するＡＶコンテンツの再生終了まで、イベントを継続してもしなくてもよいという指定であることを意味する。
【０２８４】
ｉｄ＝１
このデータ記録領域は、イベント識別情報記録領域である。
【０２８５】
ｍｅｓｓａｇｅ＿ｄａｔａ［］＝ＡＣＭ1
このデータ記録領域は、イベントデータの記録領域である。
この例では、イベントデータとして、アプリケーション制御メッセージ１（ＡＣＭ1）が格納されている。
【０２８６】
アプリケーション制御メッセージ１（ＡＣＭ1）の具体例は、先に図１７（１）を参照して説明した通りである。
図１７（１）に示すアプリケーション制御メッセージ１（ＡＣＭ1）は、先に図１５（１）を参照して説明したアプリケーション本体非格納型（ＡＣＭ）と同様のデータ構成であり、以下のデータ構成要素を持つ。
（１ａ）アプリケーション識別子
（１ｂ）アプリケーションメタデータ（オプショナル）
（１ｃ）アプリケーション制御コマンド
これらの各データ要素の詳細は、先に図１５を参照して説明した通りである。
【０２８７】
図１７（１）に示す例では、
（１ａ）アプリケーション識別子＝ｕｒｉ−１
（１ｃ）アプリケーション制御コマンド＝［アクティベート（Ａｃｔｉｖａｔｉｏｎ）］
これらを記録している。
コマンド［アクティベート（Ａｃｔｉｖａｔｉｏｎ）］は、アプリケーションを起動するコマンドである。
【０２８８】
すなわち、図１８のイベント識別子＝１（ＡＣＭ1）対応のセグメント適用イベント（ＡＣＭ1）通知メッセージは、
（１ａ）アプリケーション識別子＝ｕｒｉ−１
によって識別され、取得されるアプリケーションを
時間＝０において、
（１ｃ）アプリケーション制御コマンド＝［アクティベート（Ａｃｔｉｖａｔｉｏｎ）］
に従って、起動処理を実行する処理の実行を指定した記述である。
【０２８９】
また、図１８の下段に示すイベント識別子＝２（ＡＣＭ2）対応のセグメント適用イベント（ＡＣＭ2）に格納されたアプリケーション制御メッセージ２（ＡＣＭ2）は図１７（２）に示すデータ構成を持つ。
図１７（２）に示すアプリケーション制御メッセージ２（ＡＣＭ2）は、先に図１５（１）を参照して説明したアプリケーション本体非格納型（ＡＣＭ）をさらに簡略化したデータ構成であり、以下のデータ構成要素を持つ。
（１ａ）アプリケーション識別子
（１ｃ）アプリケーション制御コマンド
【０２９０】
このＡＣＭの例は、アプリケーションメタデータを有していない。
このＡＣＭ2は、ＡＣＭ1と同じアプリケーションに対する処理を実行させるためのＡＣＭであり、ＡＣＭ1に格納されたメタデータと同一のメタデータが適用可能なため、メタデータ格納領域が省略されている。
【０２９１】
図１７（２）に示す例では、
（１ａ）アプリケーション識別子＝ｕｒｉ−１
（１ｃ）アプリケーション制御コマンド＝［ターミネート（Ｔｅｒｍｉｎａｔｅ）］
これらを記録している。
コマンド［ターミネート（Ｔｅｒｍｉｎａｔｅ）］は、アプリケーションを停止するコマンドである。
【０２９２】
すなわち、図１８のイベント識別子＝２（ＡＣＭ2）対応のセグメント適用イベント（ＡＣＭ2）通知メッセージは、
（１ａ）アプリケーション識別子＝ｕｒｉ−１
によって識別され、取得されるアプリケーションを
時間＝１０００において、
（１ｃ）アプリケーション制御コマンド＝［ターミネート（Ｔｅｒｍｉｎａｔｅ）］
に従って、停止処理を実行する処理の実行を指定した記述である。
【０２９３】
このように、セグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）を適用したアプリケーション制御メッセージ（ＡＣＭ）通知構成では、セグメントストリームの中（ｉｎ−ｓｔｒｅａｍ）にアプリケーション制御メッセージ（ＡＣＭ）を記録して転送することができる。
【０２９４】
セグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）では、「ｓｃｈｅｍｅ＿ｉｄ＿ｕｒｉ」フィールドと、オプショナルな「ｖａｌｕｅ」フィールドにイベント種類としてアプリケーション制御メッセージ（ＡＣＭ）であることを定義可能である。
また、「ｍｅｓｓａｇｅ＿ｄａｔａ」フィールドにイベントデータ、すなわち、アプリケーション制御メッセージ（ＡＣＭ）を構成するアプリケーショ実体データ、メタデータ、コマンド等のデータや、そのアクセス情報等を付加することができる。
【０２９５】
［８．アプリケーション制御メッセージ（ＡＣＭ）の通知、利用シーケンスについて］
次に、アプリケーション制御メッセージ（ＡＣＭ）の送信、利用シーケンスについて説明する。
上述したように、イベント通知機構を適用してアプリケーション制御メッセージ（ＡＣＭ）を送信する場合、以下の２種類のタイプのイベント通知方式を利用することができる。
（ａ）ＭＰＤ適用イベント通知方式（＝ＭＰＤ  Ｅｖｅｎｔ）、
（ｂ）セグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）
以下、これらの２種類のイベント通知方式を利用してアプリケーション制御メッセージ（ＡＣＭ）を送信する場合のシーケンスについて、順次、説明する。
【０２９６】
［８−１．ＭＰＤ適用イベント通知方式（＝ＭＰＤ  Ｅｖｅｎｔ）を適用したアプリケーション制御メッセージの送信および利用シーケンスについて］
まず、ＭＰＤ適用イベント通知方式（＝ＭＰＤ  Ｅｖｅｎｔ）を適用したアプリケーション制御メッセージの送信および利用シーケンスについて、図１９を参照して説明する。
【０２９７】
図１９を参照して、ＡＶセグメントや、イベント情報としてアプリケーション制御メッセージ（ＡＣＭ）を記録したＭＰＤの生成と出力を実行する送信装置５１０と、アプリケーション制御メッセージ（ＡＣＭ）記録ＭＰＤを受領してＭＰＤ記録アプリケーション制御メッセージ（ＡＣＭ）に応じた処理を実行する受信装置５２０の構成と処理例について説明する。
【０２９８】
図１９には、左側に、アプリケーション制御メッセージ（ＡＣＭ）を記録したＭＰＤの生成と出力を実行する送信装置５１０を示している。
また、図１９の右側には、アプリケーション制御メッセージ（ＡＣＭ）を記録したＭＰＤを入力してＭＰＤに記録されたアプリケーション制御メッセージ（ＡＣＭ）に応じたアプリケーション制御処理を実行する受信装置５２０を示している。
【０２９９】
送信装置５１０は、具体的には、ＭＰＤ等のシグナリングデータや、ＡＶセグメントを送信する放送サーバ２１、データ配信サーバ２２である。
【０３００】
また、図１９の右側に示す受信装置５２０は、具体的には、ＭＰＤ等のシグナリングデータや、ＡＶセグメントを入力してコンテンツ再生処理を実行する受信装置である。
【０３０１】
送信装置５１０の実行する処理について説明する。
送信装置５１０は、データ出力部（ＤＡＳＨサーバ）５１１、アプリケーション制御メッセージ（ＡＣＭ）処理部（ＡＣＭサーバ）５１２、放送信号生成部（放送サーバ）５１３を有する。
なお、これらのサーバ機能は、ＭＰＤ等のシグナリングデータや、ＡＶセグメントを送信する図１に示す放送サーバ２１、データ配信サーバ２２が有する機能である。
以下、送信装置５１０の実行する処理について、処理ステップごとに説明する。
【０３０２】
（ステップＳ１０１）
まず、送信装置５１０のデータ出力部（ＤＡＳＨサーバ）５１１は、ステップＳ１０１において、シグナリングデータとしてのＭＰＤ、および再生コンテンツを構成するＡＶデータを含むセグメントを生成する。
【０３０３】
（ステップＳ１０２）
次に、送信装置５１０のアプリケーション制御メッセージ（ＡＣＭ）処理部（ＡＣＭサーバ）５１２は、ステップＳ１０２において、アプリケーション制御メッセージ（ＡＣＭ）を生成する。
アプリケーション制御メッセージ（ＡＣＭ）は、例えば、先に図１５を参照して説明したデータを格納したメッセージである。
図１５を参照して説明したように、アプリケーション制御メッセージ（ＡＣＭ）は、例えば、以下の２つのデータタイプがある。
（１）アプリケーション本体非格納型ＡＣＭ
（２）アプリケーション本体格納型ＡＣＭ
ステップＳ１０２では、これらのいずれかのタイプのアプリケーション制御メッセージ（ＡＣＭ）を生成する。
【０３０４】
（ステップＳ１０３）
次に、送信装置５１０のアプリケーション制御メッセージ（ＡＣＭ）処理部（ＡＣＭサーバ）５１２は、ステップＳ１０３において、アプリケーション制御メッセージ（ＡＣＭ）をイベントとして設定する。
すなわち、アプリケーション制御メッセージ（ＡＣＭ）のアクティベート時間、継続時間等、イベント通知において必要となる各パラメータを決定する。すなわち、ＤＡＳＨ規格に従ったイベント通知機構を利用したＡＣＭ送信を可能とするためのパラメータその他のフォーマットデータの設定処理などを行う。
【０３０５】
（ステップＳ１０４）
次に、送信装置５１０のデータ出力部（ＤＡＳＨサーバ）５１１は、ステップＳ１０４において、シグナリングデータとしてのＭＰＤに対して、イベント情報としてアプリケーション制御メッセージ（ＡＣＭ）の挿入を行う。
この処理によって、先に図１６を参照して説明したアプリケーション制御メッセージを含むＭＰＤが生成される。
【０３０６】
図１６に示すアプリケーション制御メッセージ格納ＭＰＤには、先に説明したように、
イベントの種類として、アプリケーション制御メッセージであることが示されている。
また、イベントデータとして、図１５を参照して説明したアプリケーション制御メッセージ（ＡＣＭ）が格納されている。
さらに、アプリケーション制御メッセージのアクティベート（活性化）時刻、継続時間情報等が記録されている。
受信装置は、このＭＰＤに記録されたアプリケーション制御メッセージに従って、指定されたアプリケーション制御メッセージを参照した処理を行なうことが可能となる。
【０３０７】
すなわち、アプリケーション制御メッセージの記録データに従って取得されるアプリケーションに対して、
アプリケーション制御メッセージに記録された制御コマンドを適用した処理を実行する。
実行時間や、継続時間は、ＭＰＤの記述に従うことになる。
【０３０８】
（ステップＳ１０５）
次に、送信装置５１０のデータ出力部（ＤＡＳＨサーバ）５１１は、ステップＳ１０５において、シグナリングデータとしてのＭＰＤにアプリケーション制御メッセージを記録したイベント情報記録ＭＰＤやセグメントを送信（出力）する。
【０３０９】
送信装置５１０が放送サーバ２１である場合、放送信号生成部（放送サーバ）５１３において、ＭＰＤやセグメントを放送波に載せて送信する処理が行われる。
データ配信サーバ２２である場合は、ＭＰＤやセグメントを、ネットワークを介して送信する。
【０３１０】
次に、図１９の右側に示す受信装置５２０の実行する処理について説明する。
図１９には、受信装置５２０のミドルウェア５２１、アプリケーション制御部５２２、再生制御部５２３を示している。これらの構成は、図５、図６に示すチューナ実装受信装置３０の各構成に対応する。
【０３１１】
（ステップＳ１２１）
まず、受信装置５２０の再生制御部（ＤＡＳＨクライアント）５２３は、送信装置５１０からミドルウェア５２１を介してシグナリングデータとしてＭＰＤを取得すると、ステップＳ１２１において、取得ＭＰＤからイベント情報を取得する。
【０３１２】
なお、ここで取得したＭＰＤは、アプリケーション制御メッセージ（ＡＣＭ）が記録されたＭＰＤであるものとする。
アプリケーション制御メッセージ格納ＭＰＤには、先に説明したように、
イベントの種類として、アプリケーション制御メッセージであることが示されている。
また、イベントデータとして、図１５を参照して説明したアプリケーション制御メッセージ（ＡＣＭ）が格納されている。
さらに、アプリケーション制御メッセージのアクティベート（活性化）時刻、継続時間情報等が記録されている。
受信装置は、このＭＰＤに記録されたアプリケーション制御メッセージに従って、指定されたアプリケーションに対して指定されたコマンドを適用した処理を行なうことが可能となる。
【０３１３】
（ステップＳ１２２）
次に、受信装置５２０のアプリケーション制御部５２２は、ステップＳ１２２において、ＭＰＤから取得したアプリケーション制御メッセージ（ＡＣＭ）の適用処理を行なう。
【０３１４】
アプリケーション制御メッセージ格納ＭＰＤには、イベントデータとして、図１５を参照して説明したアプリケーション制御メッセージ（ＡＣＭ）が格納されている。
アプリケーション制御メッセージ（ＡＣＭ）には、制御対象のアプリケーション本体、または識別情報が記録され、さらにメタデータ、制御コマンド等が記録されている。
【０３１５】
アプリケーション制御部５２２は、このＡＣＭ記録データに従って特定されるアプリケーションに対して、ＡＣＭに規定されたコマンドの適用処理を実行する
なお、コマンド適用時刻や、継続時間情報は、先に図１６を参照して説明したようにＭＰＤに記録されている。
【０３１６】
（ステップＳ１２３）
次に、受信装置５２０の再生制御部（ＤＡＳＨクライアント）５２３は、送信装置５１０から受信したセグメントからＡＶコンテンツ等を取得し再生処理を実行する。
なお、ステップＳ１２１〜Ｓ１２３の処理は、継続的に繰り返し実行されることになる。
【０３１７】
このように、受信装置（クライアント）は、ＡＶセグメントを受信し再生する処理に併せて、ＭＰＤに記録されたイベント情報としてのアプリケーション制御メッセージ（ＡＣＭ）に従って、様々なアプリケーション制御を実行することが可能となる。
【０３１８】
［８−２．セグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）を適用したアプリケーション制御メッセージの送信および利用シーケンスについて］
次に、セグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）を適用したアプリケーション制御メッセージの送信および利用シーケンスについて、図２０を参照して説明する。
【０３１９】
図２０を参照して、イベント情報としてアプリケーション制御メッセージ（ＡＣＭ）を記録したセグメントの生成（または取得）と出力を実行する送信装置５１０と、アプリケーション制御メッセージ（ＡＣＭ）記録セグメントを受領してセグメントに記録されたアプリケーション制御メッセージ（ＡＣＭ）に応じた処理を実行する受信装置５２０の構成と処理例について説明する。
【０３２０】
図２０には、左側に、アプリケーション制御メッセージ（ＡＣＭ）を記録したセグメントの生成（または取得）と出力を実行する送信装置５１０を示している。
また、図２０の右側には、アプリケーション制御メッセージ（ＡＣＭ）を記録したセグメントを入力してセグメントに記録されたアプリケーション制御メッセージ（ＡＣＭ）に応じたアプリケーション制御処理を実行する受信装置５２０を示している。
【０３２１】
送信装置５１０は、具体的には、ＭＰＤ等のシグナリングデータや、ＡＶセグメントを送信する放送サーバ２１、データ配信サーバ２２である。
【０３２２】
また、図２０の右側に示す受信装置５２０は、具体的には、ＭＰＤ等のシグナリングデータや、ＡＶセグメントを入力してコンテンツ再生処理を実行する受信装置である。
【０３２３】
送信装置５１０の実行する処理について説明する。
送信装置５１０は、データ出力部（ＤＡＳＨサーバ）５１１、アプリケーション制御メッセージ（ＡＣＭ）処理部（ＡＣＭサーバ）５１２、放送信号生成部（放送サーバ）５１３を有する。
なお、これらのサーバ機能は、ＭＰＤ等のシグナリングデータや、ＡＶセグメントを送信する図１に示す放送サーバ２１、データ配信サーバ２２が有する機能である。
以下、送信装置５１０の実行する処理について、処理ステップごとに説明する。
【０３２４】
（ステップＳ１３１）
まず、送信装置５１０のデータ出力部（ＤＡＳＨサーバ）５１１は、ステップＳ１３１において、シグナリングデータとしてのＭＰＤ、および再生コンテンツを構成するＡＶデータを含むセグメントを生成、または取得する。
【０３２５】
（ステップＳ１３２）
次に、送信装置５１０のアプリケーション制御メッセージ（ＡＣＭ）処理部（ＡＣＭサーバ）５１２は、ステップＳ１３２において、アプリケーション制御メッセージ（ＡＣＭ）を生成する。
アプリケーション制御メッセージ（ＡＣＭ）は、例えば、先に図１５を参照して説明したデータを格納したメッセージである。
図１５を参照して説明したように、アプリケーション制御メッセージ（ＡＣＭ）は、例えば、以下の２つのデータタイプがある。
（１）アプリケーション本体非格納型ＡＣＭ
（２）アプリケーション本体格納型ＡＣＭ
ステップＳ１３２では、これらのいずれかのタイプのアプリケーション制御メッセージ（ＡＣＭ）を生成する。
【０３２６】
（ステップＳ１３３）
次に、送信装置５１０のアプリケーション制御メッセージ（ＡＣＭ）処理部（ＡＣＭサーバ）５１２は、ステップＳ１３３において、アプリケーション制御メッセージ（ＡＣＭ）をイベントとして設定する。
すなわち、アプリケーション制御メッセージ（ＡＣＭ）のアクティベート時間、継続時間等、イベント通知において必要となる各パラメータを決定する。すなわち、ＤＡＳＨ規格に従ったイベント通知機構を利用したＡＣＭ送信を可能とするためのパラメータその他のフォーマットデータの設定処理などを行う。
【０３２７】
（ステップＳ１３４）
次に、送信装置５１０のデータ出力部（ＤＡＳＨサーバ）３１１は、ステップＳ１３４において、セグメントの構成データであるＭＰ４において規定されるｅｍｓｇボックスに対して、イベント情報としてアプリケーション制御メッセージ（ＡＣＭ）の挿入を行う。
この処理によって、先に図１８を参照して説明したアプリケーション制御メッセージを含むセグメントが生成される。具体的にはＭＰ４において規定されるｅｍｓｇボックス記録データを生成する。
【０３２８】
図１８に示すアプリケーション制御メッセージ格納セグメントには、先に説明したように、
イベントの種類として、アプリケーション制御メッセージであることが示されている。
また、イベントデータとして、図１５を参照して説明したアプリケーション制御メッセージ（ＡＣＭ）が格納されている。
さらに、アプリケーション制御メッセージのアクティベート（活性化）時刻、継続時間情報等が記録されている。
受信装置は、このセグメントに記録されたアプリケーション制御メッセージに従って、指定されたアプリケーション制御メッセージを参照した処理を行なうことが可能となる。
【０３２９】
すなわち、アプリケーション制御メッセージの記録データに従って取得されるアプリケーションに対して、
アプリケーション制御メッセージに記録された制御コマンドを適用した処理を実行する。
実行時間や、継続時間は、セグメント（ｅｍｓｇボックス）記録データに従うことになる。
【０３３０】
（ステップＳ１３５）
次に、送信装置５１０のデータ出力部（ＤＡＳＨサーバ）５１１は、ステップＳ１３５において、ＭＰＤ、およびアプリケーション制御メッセージを記録したセグメントを送信（出力）する。
【０３３１】
送信装置５１０が放送サーバ２１である場合、放送信号生成部（放送サーバ）５１３において、ＭＰＤやセグメントを放送波に載せて送信する処理が行われる。
データ配信サーバ２２である場合は、ＭＰＤやセグメントを、ネットワークを介して送信する。
【０３３２】
次に、図２０の右側に示す受信装置５２０の実行する処理について説明する。
図２０には、受信装置５２０のミドルウェア５２１、アプリケーション制御部５２２、再生制御部５２３を示している。これらの構成は、図５、図６に示すチューナ実装受信装置３０の各構成に対応する。
【０３３３】
（ステップＳ１４１）
まず、受信装置５２０の再生制御部（ＤＡＳＨクライアント）５２３は、送信装置５１０からミドルウェア５２１を介してセグメントを取得すると、ステップＳ１４１において、取得したセグメントからイベント情報を取得する。
【０３３４】
なお、ここで取得したセグメントは、アプリケーション制御メッセージ（ＡＣＭ）が記録されたｅｍｓｇボックスを含むセグメントであるものとする。
図１８を参照して説明したＭＰ４規定のｅｍｓｇボックスにアプリケーション制御メッセージ（ＡＣＭ）が記録されたセグメントである。
【０３３５】
アプリケーション制御メッセージ格納セグメントには、先に説明したように、
イベントの種類として、アプリケーション制御メッセージであることが示されている。
また、イベントデータとして、図１５を参照して説明したアプリケーション制御メッセージ（ＡＣＭ）が格納されている。
さらに、アプリケーション制御メッセージのアクティベート（活性化）時刻、継続時間情報等が記録されている。
受信装置は、このセグメントに記録されたアプリケーション制御メッセージに従って、指定されたアプリケーションに対して指定されたコマンドを適用した処理を行なうことが可能となる。
【０３３６】
（ステップＳ１４２）
次に、受信装置５２０のアプリケーション制御部５２２は、ステップＳ１４２において、セグメントから取得したアプリケーション制御メッセージ（ＡＣＭ）の適用処理を行なう。
【０３３７】
アプリケーション制御メッセージ格納セグメントには、イベントデータとして、図１５を参照して説明したアプリケーション制御メッセージ（ＡＣＭ）が格納されている。
アプリケーション制御メッセージ（ＡＣＭ）には、制御対象のアプリケーション本体、または識別情報が記録され、さらにメタデータ、制御コマンド等が記録されている。
【０３３８】
アプリケーション制御部５２２は、このＡＣＭ記録データに従って特定されるアプリケーションに対して、ＡＣＭに規定されたコマンドの適用処理を実行する
なお、コマンド適用時刻や、継続時間情報は、先に図１８を参照して説明したようにセグメント（ＭＰ４規定のｅｍｓｇボックス）に記録されている。
【０３３９】
（ステップＳ１４３）
次に、受信装置５２０の再生制御部（ＤＡＳＨクライアント）５２３は、送信装置５１０から受信したセグメントからＡＶコンテンツ等を取得し再生処理を実行する。
なお、ステップＳ１４１〜Ｓ１４３の処理は、継続的に繰り返し実行されることになる。
【０３４０】
このように、受信装置（クライアント）は、ＡＶセグメントを受信し再生する処理に併せて、セグメントに記録されたイベント情報としてのアプリケーション制御メッセージ（ＡＣＭ）に従って、様々なアプリケーション制御を実行することが可能となる。
【０３４１】
［９．チューナ非実装受信装置を利用した場合の処理例について］
先に、図５、図６を参照して説明したように、放送コンテンツ等の再生を実行する受信装置（クライアント）には、チューナ実装受信装置（クライアントＡ）３０や、チューナ非実装受信装置（クライアントＢ）４０がある。
【０３４２】
チューナ非実装受信装置（クライアントＢ）４０は、直接、放送波を受信できないため、チューナ実装受信装置（クライアントＡ）３０を介して様々なデータを入力することが必要となる。
アプリケーション制御メッセージ（ＡＣＭ）についても同様であり、チューナ非実装受信装置（クライアントＢ）４０は、直接、アプリケーション制御メッセージ（ＡＣＭ）を受信できないため、チューナ実装受信装置（クライアントＡ）３０を介して入力することが必要となる。
以下、チューナ非実装受信装置（クライアントＢ）４０が、チューナ実装受信装置（クライアントＡ）３０を介してアプリケーション制御メッセージ（ＡＣＭ）を入力して処理を行なう場合の処理シーケンスについて説明する。
【０３４３】
上述したように、イベント通知機構を適用してアプリケーション制御メッセージ（ＡＣＭ）を送信する場合、以下の２種類のタイプのイベント通知方式を利用することができる。
（ａ）ＭＰＤ適用イベント通知方式（＝ＭＰＤ  Ｅｖｅｎｔ）、
（ｂ）セグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）
以下、これらの２種類のイベント通知方式を利用してアプリケーション制御メッセージ（ＡＣＭ）を送信する場合のシーケンスについて、順次、説明する。
【０３４４】
［９−１．ＭＰＤ適用イベント通知方式（＝ＭＰＤ  Ｅｖｅｎｔ）を適用したアプリケーション制御メッセージの送信および利用シーケンスについて］
まず、ＭＰＤ適用イベント通知方式（＝ＭＰＤ  Ｅｖｅｎｔ）を適用したアプリケーション制御メッセージの送信および利用シーケンスについて、図２１を参照して説明する。
【０３４５】
図２１を参照して、以下の３つの装置間の処理シーケンスについて説明する。
（１）ＡＶセグメントや、アプリケーション制御メッセージ（ＡＣＭ）の生成と出力を実行する送信装置６１０、
（２）ＡＶセグメントや、アプリケーション制御メッセージ（ＡＣＭ）を受信し、アプリケーション制御メッセージ（ＡＣＭ）をイベント情報としてＭＰＤに記録したＡＣＭ記録ＭＰＤを生成するチューナ実装受信装置６２０、
（３）チューナ実装受信装置６２０から、アプリケーション制御メッセージ（ＡＣＭ）記録ＭＰＤを受領してＭＰＤ記録アプリケーション制御メッセージ（ＡＣＭ）に応じた処理を実行するチューナ非実装受信装置６３０、
【０３４６】
図２１には、左から、送信装置６１０、チューナ実装受信装置６２０、さらに、チューナ非実装受信装置６３０を示している。
送信装置６１０は、具体的には、ＭＰＤ等のシグナリングデータや、ＡＶセグメントを送信する放送サーバ２１、データ配信サーバ２２である。
【０３４７】
送信装置６１０の実行する処理について説明する。
送信装置６１０は、データ出力部（ＤＡＳＨサーバ）６１１、アプリケーション制御メッセージ（ＡＣＭ）処理部（ＡＣＭサーバ）６１２、放送信号生成部（放送サーバ）６１３を有する。
なお、これらのサーバ機能は、ＭＰＤ等のシグナリングデータや、ＡＶセグメントを送信する図１に示す放送サーバ２１、データ配信サーバ２２が有する機能である。
以下、送信装置６１０の実行する処理について、処理ステップごとに説明する。
【０３４８】
（ステップＳ２０１）
まず、送信装置６１０のデータ出力部（ＤＡＳＨサーバ）６１１は、ステップＳ２０１において、シグナリングデータとしてのＭＰＤ、および再生コンテンツを構成するＡＶデータを含むセグメントを生成する。
【０３４９】
（ステップＳ２０２〜Ｓ２０３）
次に、送信装置６１０のアプリケーション制御メッセージ（ＡＣＭ）処理部（ＡＣＭサーバ）６１２は、ステップＳ２０２において、アプリケーション制御メッセージ（ＡＣＭ）を生成し、ステップＳ２０３において生成したアプリケーション制御メッセージ（ＡＣＭ）を送信する。
【０３５０】
アプリケーション制御メッセージ（ＡＣＭ）は、例えば、先に図１５を参照して説明したデータを格納したメッセージである。
図１５を参照して説明したように、アプリケーション制御メッセージ（ＡＣＭ）は、例えば、以下の２つのデータタイプがある。
（１）アプリケーション本体非格納型ＡＣＭ
（２）アプリケーション本体格納型ＡＣＭ
ステップＳ２０２〜Ｓ２０３では、これらのいずれかのタイプのアプリケーション制御メッセージ（ＡＣＭ）を生成して送信する。
【０３５１】
（ステップＳ２０４）
次に、送信装置６１０のデータ出力部（ＤＡＳＨサーバ）６１１は、ステップＳ２０４において、シグナリングデータとしてのＭＰＤやセグメントを送信（出力）する。
【０３５２】
送信装置６１０が放送サーバ２１である場合、放送信号生成部（放送サーバ）６１３において、ＭＰＤやセグメントを放送波に載せて送信する処理が行われる。
データ配信サーバ２２である場合は、ＭＰＤやセグメントを、ネットワークを介して送信する。
【０３５３】
次に、チューナ実装受信装置６２０の処理について説明する。
チューナ実装受信装置６２０は、図５、図６に示すチューナ実装受信装置３０と同様の構成を持つ。
チューナ実装受信装置６２０は、送信装置６１０の送信するＡＶセグメントや、アプリケーション制御メッセージ（ＡＣＭ）を受信し、アプリケーション制御メッセージ（ＡＣＭ）をイベント情報としてＭＰＤに記録したＡＣＭ記録ＭＰＤを生成する。
さらに、生成したＡＣＭ記録ＭＰＤや、セグメントをチューナ非実装受信装置６３０に転送する。
チューナ実装受信装置６２０の実行する各ステップの処理について説明する。
【０３５４】
（ステップＳ２１１）
チューナ実装受信装置６２０のミドルウェア６２１は、送信装置６１０からアプリケーション制御メッセージ（ＡＣＭ）を受信すると、ステップＳ２１１において、受信したアプリケーション制御メッセージ（ＡＣＭ）をイベントとして設定する。
すなわち、アプリケーション制御メッセージ（ＡＣＭ）のアクティベート時間、継続時間等、イベント通知において必要となる各パラメータを設定し、ＤＡＳＨ規格に従ったイベント情報としてのフォーマットを整える。
なお、この処理に適用する各パラメータは、送信装置６１０から受信するアプリケーション制御メッセージ（ＡＣＭ）に付随する属性データとして記録されている。
【０３５５】
（ステップＳ２１２）
次に、チューナ実装受信装置６２０のミドルウェア６２１は、ステップＳ２１２において、シグナリングデータとしてのＭＰＤに対して、イベント情報としてアプリケーション制御メッセージ（ＡＣＭ）の挿入を行う。
この処理によって、先に図１６を参照して説明したアプリケーション制御メッセージを含むＭＰＤが生成される。
【０３５６】
図１６に示すアプリケーション制御メッセージ格納ＭＰＤには、先に説明したように、
イベントの種類として、アプリケーション制御メッセージであることが示されている。
また、イベントデータとして、図１５を参照して説明したアプリケーション制御メッセージ（ＡＣＭ）が格納されている。
さらに、アプリケーション制御メッセージのアクティベート（活性化）時刻、継続時間情報等が記録されている。
チューナ非実装受信装置６３０は、このＭＰＤに記録されたアプリケーション制御メッセージに従って、指定されたアプリケーション制御メッセージを参照した処理を行なうことが可能となる。
【０３５７】
すなわち、アプリケーション制御メッセージの記録データに従って取得されるアプリケーションに対して、
アプリケーション制御メッセージに記録された制御コマンドを適用した処理を実行する。
実行時間や、継続時間は、ＭＰＤの記述に従うことになる。
【０３５８】
（ステップＳ２１３）
次に、チューナ実装受信装置６２０のミドルウェア６２１は、ステップＳ２１３において、シグナリングデータとしてのＭＰＤにアプリケーション制御メッセージを記録したイベント情報記録ＭＰＤやセグメントを送信（出力）する。
【０３５９】
なお、チューナ実装受信装置６２０から、チューナ非実装受信装置６３０に対するＭＰＤやセグメント出力は、例えば、チューナ実装受信装置６２０のミドルウェアからプロキシサーバを介して実行される。
【０３６０】
次に、図２１の右側に示すチューナ非実装受信装置６３０の実行する処理について説明する。
図２１には、チューナ非実装受信装置６３０のアプリケーション制御部６３１、再生制御部６３２を示している。これらの構成は、図５、図６に示すチューナ非実装受信装置４０の各構成に対応する。
【０３６１】
（ステップＳ２２１）
まず、チューナ非実装受信装置６３０の再生制御部（ＤＡＳＨクライアント）６３２は、チューナ実装受信装置６２０のミドルウェア６２１を介してシグナリングデータとしてのＭＰＤを取得すると、ステップＳ２２１において、取得ＭＰＤからイベント情報を取得する。
【０３６２】
なお、ここで取得したＭＰＤは、アプリケーション制御メッセージ（ＡＣＭ）が記録されたＭＰＤであるものとする。
アプリケーション制御メッセージ格納ＭＰＤには、先に説明したように、
イベントの種類として、アプリケーション制御メッセージであることが示されている。
また、イベントデータとして、図１５を参照して説明したアプリケーション制御メッセージ（ＡＣＭ）が格納されている。
さらに、アプリケーション制御メッセージのアクティベート（活性化）時刻、継続時間情報等が記録されている。
受信装置は、このＭＰＤに記録されたアプリケーション制御メッセージに従って、指定されたアプリケーションに対して指定されたコマンドを適用した処理を行なうことが可能となる。
【０３６３】
（ステップＳ２２２）
次に、チューナ非実装受信装置６３０のアプリケーション制御部６３１は、ステップＳ２２２において、ＭＰＤから取得したアプリケーション制御メッセージ（ＡＣＭ）の適用処理を行なう。
【０３６４】
アプリケーション制御メッセージ格納ＭＰＤには、イベントデータとして、図１５を参照して説明したアプリケーション制御メッセージ（ＡＣＭ）が格納されている。
アプリケーション制御メッセージ（ＡＣＭ）には、制御対象のアプリケーション本体、または識別情報が記録され、さらにメタデータ、制御コマンド等が記録されている。
【０３６５】
アプリケーション制御部６３１は、このＡＣＭ記録データに従って特定されるアプリケーションに対して、ＡＣＭに規定されたコマンドの適用処理を実行する
なお、コマンド適用時刻や、継続時間情報は、先に図１６を参照して説明したようにＭＰＤに記録されている。
【０３６６】
（ステップＳ２２３）
次に、チューナ非実装受信装置６３０の再生制御部（ＤＡＳＨクライアント）６３２は、チューナ実装受信装置６２０を介して受信したセグメントからＡＶコンテンツ等を取得し再生処理を実行する。
なお、ステップＳ２２１〜Ｓ２２３の処理は、継続的に繰り返し実行されることになる。
【０３６７】
このように、チューナ非実装受信装置６３０は、ＡＶセグメントを受信し再生する処理に併せて、チューナ実装受信装置６２０のミドルウェアが生成したアプリケーション制御メッセージ（ＡＣＭ）記録ＭＰＤから、イベント情報としてのアプリケーション制御メッセージ（ＡＣＭ）を取得し、取得したＡＣＭに従って、様々なアプリケーション制御を実行することが可能となる。
【０３６８】
なお、図２１を参照して説明したような放送送出後にアプリケーション制御メッセージ（ＡＣＭ）をＭＰＤに挿入する処理を行なう構成は、アプリケーションの実行までの時間的な余裕がある場合に限られる。
例えば、あるＡＶセグメントが放送サーバ等から送出されてから十分な時間が経ってからそのセグメントの再生開始時刻がスケジュールされている場合などに限られる。
【０３６９】
これは、アプリケーション制御メッセージ（ＡＣＭ）はピリオド単位の設定でＭＰＤに記録する必要があり、例えばチューナ実装受信装置６２０のミドルウェア６２１は、１つのピリオド（Ｐｅｒｉｏｄ）分の時間にわたって、放送サーバから放送されるＡＣＭを集めて、そのピリオド対応のＭＰＤを生成することが必要になり、ＭＰＤ送出までに最低でも１ピリオド分のタイムラグが生じるためである。
【０３７０】
［９−２．セグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）を適用したアプリケーション制御メッセージの送信および利用シーケンスについて］
次に、セグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）を適用したアプリケーション制御メッセージの送信および利用シーケンスについて、図２２を参照して説明する。
【０３７１】
図２２を参照して、以下の３つの装置間の処理シーケンスについて説明する。
（１）ＡＶセグメントや、アプリケーション制御メッセージ（ＡＣＭ）の生成と出力を実行する送信装置６１０、
（２）ＡＶセグメントや、アプリケーション制御メッセージ（ＡＣＭ）を受信し、アプリケーション制御メッセージ（ＡＣＭ）をイベント情報としてセグメントに記録したＡＣＭ記録セグメントを生成するチューナ実装受信装置６２０、
（３）チューナ実装受信装置６２０から、アプリケーション制御メッセージ（ＡＣＭ）記録セグメントを受領してセグメント記録アプリケーション制御メッセージ（ＡＣＭ）に応じた処理を実行するチューナ非実装受信装置６３０、
【０３７２】
図２２には、左から、送信装置６１０、チューナ実装受信装置６２０、さらに、チューナ非実装受信装置６３０を示している。
送信装置６１０は、具体的には、ＭＰＤ等のシグナリングデータや、ＡＶセグメントを送信する放送サーバ２１、データ配信サーバ２２である。
【０３７３】
送信装置６１０の実行する処理について説明する。
送信装置６１０は、データ出力部（ＤＡＳＨサーバ）６１１、アプリケーション制御メッセージ（ＡＣＭ）処理部（ＡＣＭサーバ）６１２、放送信号生成部（放送サーバ）６１３を有する。
なお、これらのサーバ機能は、ＭＰＤ等のシグナリングデータや、ＡＶセグメントを送信する図１に示す放送サーバ２１、データ配信サーバ２２が有する機能である。
以下、送信装置６１０の実行する処理について、処理ステップごとに説明する。
【０３７４】
（ステップＳ２５１）
まず、送信装置６１０のデータ出力部（ＤＡＳＨサーバ）６１１は、ステップＳ２５１において、シグナリングデータとしてのＭＰＤ、および再生コンテンツを構成するＡＶデータを含むセグメントを生成取得する。
【０３７５】
（ステップＳ２５２〜Ｓ２５３）
次に、送信装置６１０のアプリケーション制御メッセージ（ＡＣＭ）処理部（ＡＣＭサーバ）６１２は、ステップＳ２５２において、アプリケーション制御メッセージ（ＡＣＭ）を生成し、ステップＳ２５３において生成したアプリケーション制御メッセージ（ＡＣＭ）を送信する。
【０３７６】
アプリケーション制御メッセージ（ＡＣＭ）は、例えば、先に図１５を参照して説明したデータを格納したメッセージである。
図１５を参照して説明したように、アプリケーション制御メッセージ（ＡＣＭ）は、例えば、以下の２つのデータタイプがある。
（１）アプリケーション本体非格納型ＡＣＭ
（２）アプリケーション本体格納型ＡＣＭ
ステップＳ２５２では、これらのいずれかのタイプのアプリケーション制御メッセージ（ＡＣＭ）を生成する。
【０３７７】
（ステップＳ２５４）
次に、送信装置６１０のデータ出力部（ＤＡＳＨサーバ）６１１は、ステップＳ２５４において、シグナリングデータとしてのＭＰＤやセグメントを送信（出力）する。
【０３７８】
送信装置６１０が放送サーバ２１である場合、放送信号生成部（放送サーバ）６１３において、ＭＰＤやセグメントを放送波に載せて送信する処理が行われる。
データ配信サーバ２２である場合は、ＭＰＤやセグメントを、ネットワークを介して送信する。
【０３７９】
次に、チューナ実装受信装置６２０の処理について説明する。
チューナ実装受信装置６２０は、図５、図６に示すチューナ実装受信装置３０と同様の構成を持つ。
チューナ実装受信装置６２０は、送信装置６１０の送信するＡＶセグメントや、アプリケーション制御メッセージ（ＡＣＭ）を受信し、アプリケーション制御メッセージ（ＡＣＭ）をイベント情報としてセグメントに記録したＡＣＭ記録セグメントを生成する。
さらに、生成したＡＣＭ記録セグメントや、ＭＰＤをチューナ非実装受信装置６３０に転送する。
チューナ実装受信装置６２０の実行する各ステップの処理について説明する。
【０３８０】
（ステップＳ２６１）
チューナ実装受信装置６２０のミドルウェア６２１は、送信装置６１０からアプリケーション制御メッセージ（ＡＣＭ）を受信すると、ステップＳ２６１において、受信したアプリケーション制御メッセージ（ＡＣＭ）をイベントとして設定する。
すなわち、アプリケーション制御メッセージ（ＡＣＭ）のアクティベート時間、継続時間等、イベント通知において必要となる各パラメータを設定し、ＤＡＳＨ規格に従ったイベント情報としてのフォーマットを整える。
なお、この処理に適用する各パラメータは、送信装置６１０から受信するアプリケーション制御メッセージ（ＡＣＭ）に付随する属性データとして記録されている。
【０３８１】
（ステップＳ２６２）
次に、チューナ実装受信装置６２０のミドルウェア６２１は、ステップＳ２６２において、セグメントの構成データであるＭＰ４において規定されるｅｍｓｇボックスに対して、イベント情報としてアプリケーション制御メッセージ（ＡＣＭ）の挿入を行う。
この処理によって、先に図１８を参照して説明したアプリケーション制御メッセージを含むセグメントが生成される。具体的にはＭＰ４において規定されるｅｍｓｇボックス記録データを生成する。
【０３８２】
図１８に示すアプリケーション制御メッセージ格納セグメントには、先に説明したように、
イベントの種類として、アプリケーション制御メッセージであることが示されている。
また、イベントデータとして、図１５を参照して説明したアプリケーション制御メッセージ（ＡＣＭ）が格納されている。
さらに、アプリケーション制御メッセージのアクティベート（活性化）時刻、継続時間情報等が記録されている。
受信装置は、このセグメントに記録されたアプリケーション制御メッセージに従って、指定されたアプリケーション制御メッセージを参照した処理を行なうことが可能となる。
【０３８３】
すなわち、アプリケーション制御メッセージの記録データに従って取得されるアプリケーションに対して、
アプリケーション制御メッセージに記録された制御コマンドを適用した処理を実行する。
実行時間や、継続時間は、セグメント（ｅｍｓｇボックス）記録データに従うことになる。
【０３８４】
（ステップＳ２６３）
次に、チューナ実装受信装置６２０のミドルウェア６２１は、ステップＳ２６３において、ＭＰＤ、およびアプリケーション制御メッセージを記録したセグメントを送信（出力）する。
【０３８５】
なお、チューナ実装受信装置６２０から、チューナ非実装受信装置６３０に対するＭＰＤやセグメント出力は、例えば、チューナ実装受信装置６２０のミドルウェアからプロキシサーバを介して実行される。
【０３８６】
次に、図２２の右側に示すチューナ非実装受信装置６３０の実行する処理について説明する。
図２２には、チューナ非実装受信装置６３０のアプリケーション制御部６３１、再生制御部６３２を示している。これらの構成は、図５、図６に示すチューナ非実装受信装置４０の各構成に対応する。
【０３８７】
（ステップＳ２７１）
まず、チューナ非実装受信装置６３０の再生制御部（ＤＡＳＨクライアント）６３２は、チューナ実装受信装置６２０のミドルウェア６２１を介してセグメントを取得すると、ステップＳ２７１において、取得したセグメントからイベント情報を取得する。
【０３８８】
なお、ここで取得したセグメントは、アプリケーション制御メッセージ（ＡＣＭ）が記録されたｅｍｓｇボックスを含むセグメントであるものとする。
図１８を参照して説明したＭＰ４規定のｅｍｓｇボックスにアプリケーション制御メッセージ（ＡＣＭ）が記録されたセグメントである。
【０３８９】
アプリケーション制御メッセージ格納セグメントには、先に説明したように、
イベントの種類として、アプリケーション制御メッセージであることが示されている。
また、イベントデータとして、図１５を参照して説明したアプリケーション制御メッセージ（ＡＣＭ）が格納されている。
さらに、アプリケーション制御メッセージのアクティベート（活性化）時刻、継続時間情報等が記録されている。
受信装置は、このセグメントに記録されたアプリケーション制御メッセージに従って、指定されたアプリケーションに対して指定されたコマンドを適用した処理を行なうことが可能となる。
【０３９０】
（ステップＳ２７２）
次に、チューナ非実装受信装置６３０のアプリケーション制御部６３１は、ステップＳ２７２において、セグメントから取得したアプリケーション制御メッセージ（ＡＣＭ）の適用処理を行なう。
【０３９１】
アプリケーション制御メッセージ格納セグメントには、イベントデータとして、図１５を参照して説明したアプリケーション制御メッセージ（ＡＣＭ）が格納されている。
アプリケーション制御メッセージ（ＡＣＭ）には、制御対象のアプリケーション本体、または識別情報が記録され、さらにメタデータ、制御コマンド等が記録されている。
【０３９２】
アプリケーション制御部６３１は、このＡＣＭ記録データに従って特定されるアプリケーションに対して、ＡＣＭに規定されたコマンドの適用処理を実行する
なお、コマンド適用時刻や、継続時間情報は、先に図１８を参照して説明したようにセグメント（ＭＰ４規定のｅｍｓｇボックス）に記録されている。
【０３９３】
（ステップＳ２７３）
次に、チューナ非実装受信装置６３０の再生制御部（ＤＡＳＨクライアント）６３２は、チューナ実装受信装置６２０を介して受信したセグメントからＡＶコンテンツ等を取得し再生処理を実行する。
なお、ステップＳ２７１〜Ｓ２７３の処理は、継続的に繰り返し実行されることになる。
【０３９４】
このように、チューナ非実装受信装置６３０は、ＡＶセグメントを受信し再生する処理に併せて、セグメントに記録されたイベント情報としてのアプリケーション制御メッセージ（ＡＣＭ）に従って、様々なアプリケーション制御を実行することが可能となる。
【０３９５】
［１０．送信装置と受信装置の構成例について］
次に、通信装置である送信装置（サーバ）２０と、受信装置（クライアント）３０，４０の装置構成例について、図２３、図２４を参照して説明する。
【０３９６】
図２３には、送信装置（サーバ）２０と、受信装置（クライアント）３０の構成例を示している。
送信装置（サーバ）２０は、データ処理部７５１、通信部７５２、記憶部７５３を有する。
受信装置（クライアント）３０，４０は、データ処理部７７１、通信部７７２、記憶部７７３、入力部７７４、出力部７７５を有する。
データ処理部には再生制御部７７１ａ、出力制御部７７１ｂ、アプリケーション制御部７７１ｃが含まれる。
【０３９７】
送信装置（サーバ）２０のデータ処理部７５１は、データ配信サービスを実行するための各種のデータ処理を実行する。例えばデータ配信サービスの構成データの生成や送信制御を行う。さらに、データ処理部７５１は、受信装置（クライアント）３０に提供するアプリケーション、アプリケーション制御メッセージ（ＡＣＭ）、ＡＣＭ格納ＭＰＤ、ＡＣＭ格納セグメント、その他の様々なデータや、シグナリングデータの生成、送信処理を行う。
【０３９８】
通信部７５２は、ＡＶセグメントの他、アプリケーション、アプリケーション制御メッセージ（ＡＣＭ）、ＡＣＭ格納ＭＰＤ、ＡＣＭ格納セグメント、その他の様々なデータ、シグナリングデータ等の配信等の通信処理を行う。
記憶部７５３は配信対象とするＡＶセグメント、アプリケーション、アプリケーション制御メッセージ（ＡＣＭ）、ＡＣＭ格納ＭＰＤ、ＡＣＭ格納セグメント、アプリケーションによって利用されるデータ、シグナリングデータなどが格納される。
さらに、記憶部７５３は、データ処理部７５１の実行するデータ処理のワークエリアとして利用され、また各種パラメータの記憶領域としても利用される。
【０３９９】
一方、受信装置（クライアント）３０，４０は、データ処理部７７１、通信部７７２、記憶部７７３、入力部７７４、出力部７７５を有する。
【０４００】
通信部７７２は、チューナ実装受信装置３０の通信部と、チューナ非実装受信装置４０の場合とで異なる設定となる。
チューナ実装受信装置３０の通信部は、送信装置（サーバ）２０から配信されるデータ、例えばＡＶセグメントやアプリケーション、アプリケーション制御メッセージ（ＡＣＭ）、ＡＣＭ格納ＭＰＤ、ＡＣＭ格納セグメント、アプリケーションによって利用されるデータ、シグナリングデータ等を受信する。
さらに、ＬＡＮ、Ｗｉ−Ｆｉ等のネットワークを介したデータ送受信が可能な通信部として構成される。
一方、チューナ非実装受信装置４０の通信部は、放送波を受信可能なチューナ部は持たず、ＬＡＮ，Ｗｉ−Ｆｉ等のネットワークを介したデータ送受信を実行可能な通信部として構成される。
【０４０１】
データ処理部７７１は、再生制御部７７１ａ、出力制御部７７１ｂ、アプリケーション制御部７７１ｃを有し、例えば先に説明した実施例に従った処理等を実行する。
具体的には、アプリケーションや、ＡＰＩ、さらに、アプリケーション制御メッセージ（ＡＣＭ）、ＡＣＭ格納ＭＰＤ、ＡＣＭ格納セグメントを利用したデータ処理等を実行する。
【０４０２】
ユーザの指示コマンド、例えばチャンネル選択、アプリケーション起動、インストール等の様々なコマンドは入力部７７４を介して入力される。
再生データは表示部やスピーカ等の出力部７７５に出力される。
記憶部７７３はＡＶセグメント、アプリケーション制御メッセージ（ＡＣＭ）、ＡＣＭ格納ＭＰＤ、ＡＣＭ格納セグメント、アプリケーション、アプリケーションによって利用されるデータ、シグナリングデータなどが格納される。
さらに、記憶部７７３は、データ処理部７７１の実行するデータ処理のワークエリアとして利用され、また各種パラメータの記憶領域としても利用される。
【０４０３】
図２４は、送信装置２０、受信装置３０として適用可能な通信装置のハードウェア構成例を示している。
【０４０４】
ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）８０１は、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）８０２、または記憶部８０８に記憶されているプログラムに従って各種の処理を実行するデータ処理部として機能する。例えば、上述した実施例において説明したシーケンスに従った処理を実行する。ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）８０３には、ＣＰＵ８０１が実行するプログラムやデータなどが記憶される。これらのＣＰＵ８０１、ＲＯＭ８０２、およびＲＡＭ８０３は、バス８０４により相互に接続されている。
【０４０５】
ＣＰＵ８０１はバス８０４を介して入出力インタフェース８０５に接続され、入出力インタフェース８０５には、各種スイッチ、キーボード、マウス、マイクロホンなどよりなる入力部８０６、ディスプレイ、スピーカなどよりなる出力部８０７が接続されている。ＣＰＵ８０１は、入力部８０６から入力される指令に対応して各種の処理を実行し、処理結果を例えば出力部８０７に出力する。
【０４０６】
入出力インタフェース８０５に接続されている記憶部８０８は、例えばハードディスク等からなり、ＣＰＵ８０１が実行するプログラムや各種のデータを記憶する。通信部８０９は、インターネットやローカルエリアネットワークなどのネットワークを介したデータ通信の送受信部、さらに放送波の送受信部として機能し、外部の装置と通信する。
【０４０７】
入出力インタフェース８０５に接続されているドライブ８１０は、磁気ディスク、光ディスク、光磁気ディスク、あるいはメモリカード等の半導体メモリなどのリムーバブルメディア８１１を駆動し、データの記録あるいは読み取りを実行する。
【０４０８】
なお、データの符号化あるいは復号は、データ処理部としてのＣＰＵ８０１の処理として実行可能であるが、符号化処理あるいは復号処理を実行するための専用ハードウェアとしてのコーデックを備えた構成としてもよい。
【０４０９】
［１１．本開示の構成のまとめ］
以上、特定の実施例を参照しながら、本開示の実施例について詳解してきた。しかしながら、本開示の要旨を逸脱しない範囲で当業者が実施例の修正や代用を成し得ることは自明である。すなわち、例示という形態で本発明を開示してきたのであり、限定的に解釈されるべきではない。本開示の要旨を判断するためには、特許請求の範囲の欄を参酌すべきである。
【０４１０】
なお、本明細書において開示した技術は、以下のような構成をとることができる。
（１）  アプリケーション制御メッセージをイベントデータとして格納したイベント通知データを受信する通信部と、
イベント通知メッセージにイベントデータとして格納されたアプリケーション制御メッセージに基づくアプリケーション制御を実行するアプリケーション制御部を有する受信装置。
【０４１１】
（２）前記イベント通知データは、
制御情報の通知データとして送信されるシグナリングデータであるＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）を利用したイベント通知方式であるＭＰＤ適用イベント通知方式（ＭＰＤ  Ｅｖｅｎｔ）に従ったデータフォーマットを持つイベント通知データである（１）に記載の受信装置。
【０４１２】
（３）前記イベント通知データは、
ＡＶコンテンツの送信用データであるセグメントを利用したイベント通知方式であるセグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）に従ったデータフォーマットを持つイベント通知データである（１）に記載の受信装置。
【０４１３】
（４）前記イベント通知データは、
イベントデータがアプリケーション制御メッセージであることを示すイベント識別子を記録したデータである（１）〜（３）いずれかに記載の受信装置。
【０４１４】
（５）前記イベント通知データは、
イベントデータとして格納されたアプリケーション制御メッセージに従って処理を実行するための制御時間情報を記録したデータである（１）〜（４）いずれかに記載の受信装置。
【０４１５】
（６）  前記アプリケーション制御メッセージは、
制御対象となるアプリケーション本体、またはアプリケーション識別子を記録したデータである（１）〜（５）いずれかに記載の受信装置。
【０４１６】
（７）  前記アプリケーション制御メッセージは、
制御対象となるアプリケーションに関するメタデータを記録したデータである（１）〜（６）いずれかに記載の受信装置。
【０４１７】
（８）  前記メタデータは、
（ａ）制御対象となるアプリケーションのバージョン、
（ｂ）制御対象となるアプリケーションの実行に必要となるリソース情報、
（ｃ）制御対象となるアプリケーションのレーティング情報、
上記（ａ）〜（ｃ）の少なくともいずれかの情報を含む（７）に記載の受信装置。
【０４１８】
（９）  前記アプリケーション制御メッセージは、
制御対象となるアプリケーションに対するコマンド記録したデータである（１）〜（８）いずれかに記載の受信装置。
【０４１９】
（１０）  前記受信装置は、さらに、
前記通信部の受信したイベント通知データから、アプリケーション制御メッセージを取得して前記アプリケーション制御部に出力するデータ処理部を有する（１）〜（９）いずれかに記載の受信装置。
【０４２０】
（１１）  アプリケーション制御メッセージを受信する通信部と、
前記アプリケーション制御メッセージをイベントデータとして格納したイベント通知データを生成するミドルウェアと、
前記イベント通知データからアプリケーション制御メッセージを取得して、アプリケーション制御部に出力するデータ処理部と、
前記アプリケーション制御メッセージに基づくアプリケーション制御を実行するアプリケーション制御部を有する受信装置。
【０４２１】
（１２）  前記ミドルウェアは、
制御情報の通知データとして送信されるシグナリングデータであるＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）を利用したイベント通知方式であるＭＰＤ適用イベント通知方式（ＭＰＤ  Ｅｖｅｎｔ）に従ったデータフォーマットを持つイベント通知データを生成する（１１）に記載の受信装置。
【０４２２】
（１３）  前記ミドルウェアは、
ＡＶコンテンツの送信用データであるセグメントを利用したイベント通知方式であるセグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）に従ったデータフォーマットを持つイベント通知データを生成する（１１）に記載の受信装置。
【０４２３】
（１４）  アプリケーション制御メッセージをイベントデータとして格納したイベント通知データを送信する通信部を有する送信装置。
【０４２４】
（１５）  前記イベント通知データは、
制御情報の通知データとして送信されるシグナリングデータであるＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）を利用したイベント通知方式であるＭＰＤ適用イベント通知方式（ＭＰＤ  Ｅｖｅｎｔ）に従ったデータフォーマットを持つイベント通知データである（１４）に記載の送信装置。
【０４２５】
（１６）  前記イベント通知データは、
ＡＶコンテンツの送信用データであるセグメントを利用したイベント通知方式であるセグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）に従ったデータフォーマットを持つイベント通知データである（１４）に記載の送信装置。
【０４２６】
（１７）  受信装置において実行するデータ処理方法であり、
通信部が、アプリケーション制御メッセージをイベントデータとして格納したイベント通知データを受信し、
アプリケーション制御部が、イベント通知メッセージにイベントデータとして格納されたアプリケーション制御メッセージに基づくアプリケーション制御を実行するデータ処理方法。
【０４２７】
（１８）  受信装置において実行するデータ処理方法であり、
通信部が、アプリケーション制御メッセージを受信し、
ミドルウェアが、アプリケーション制御メッセージをイベントデータとして格納したイベント通知データを生成し、
データ処理部が、前記イベント通知データからアプリケーション制御メッセージを取得して、アプリケーション制御部に出力し、
アプリケーション制御部が、前記アプリケーション制御メッセージに基づくアプリケーション制御を実行するデータ処理方法。
【０４２８】
（１９）  送信装置において実行するデータ処理方法であり、
通信部が、アプリケーション制御メッセージをイベントデータとして格納したイベント通知データを送信するデータ処理方法。
【０４２９】
また、明細書中において説明した一連の処理はハードウェア、またはソフトウェア、あるいは両者の複合構成によって実行することが可能である。ソフトウェアによる処理を実行する場合は、処理シーケンスを記録したプログラムを、専用のハードウェアに組み込まれたコンピュータ内のメモリにインストールして実行させるか、あるいは、各種処理が実行可能な汎用コンピュータにプログラムをインストールして実行させることが可能である。例えば、プログラムは記録媒体に予め記録しておくことができる。記録媒体からコンピュータにインストールする他、ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、インターネットといったネットワークを介してプログラムを受信し、内蔵するハードディスク等の記録媒体にインストールすることができる。
【０４３０】
なお、明細書に記載された各種の処理は、記載に従って時系列に実行されるのみならず、処理を実行する装置の処理能力あるいは必要に応じて並列的にあるいは個別に実行されてもよい。また、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。
【産業上の利用可能性】
【０４３１】
以上、説明したように、本開示の一実施例の構成によれば、アプリケーション制御メッセージを適用したアプリケーション制御を確実に実行可能とした構成が実現される。
具体的には、送信装置が受信装置にアプリケーション制御メッセージ（ＡＣＭ）をイベントデータとして格納したイベント通知データを送信する。受信装置のアプリケーション制御部は、イベント通知メッセージにイベントデータとして格納されたＡＣＭに基づくアプリケーション制御を実行する。イベント通知データは、シグナリングデータであるＭＰＤ、または、ＡＶコンテンツの送信用データであるセグメント内に格納され、受信装置はＭＰＤ、またはセグメントからＡＣＭを取得して迅速なアプリケーション制御を行うことができる。
本構成により、アプリケーション制御メッセージを適用したアプリケーション制御を確実に実行可能とした構成が実現される。
【符号の説明】
【０４３２】
１０  通信システム
２０  送信装置
２１  放送サーバ
２２  データ配信サーバ
３０  チューナ実装受信装置
３１  中継サーバ
３２  ＴＶ
３３  ＰＣ
３４  携帯端末
４０  チューナ非実装受信装置
４１  ＰＣ
４２  携帯端末
５０  シグナリングデータ
６０  ＡＶセグメント
７０  その他のデータ
１１０  ミドルウェア
１１１  通信部（ＰＨＹ／ＭＡＣ）
１１２  シグナリング取得部
１１３  シグナリング解析部
１１４  セグメント取得部
１１５  イベント挿入部
１１６  アプリケーションファイル取得部
１２０  ＨＴＴＰプロキシサーバ
１２１，１２２  キャッシュ部
１２３  アドレス解決部
１３１，１５１  再生制御部
１３２，１５２  出力制御部
１４０，１６０  アプリケーション制御部
３１０  イベント挿入実行装置
３１１  データ出力部（ＤＡＳＨサーバ）
３１２  イベント処理部（イベントサーバ）
３２０  イベント実行装置
３２１  再生制御部（イベントクライアント）
３２２  再生制御部（ＤＡＳＨクライアント）
５１０  送信装置
５１１  データ出力部（ＤＡＳＨサーバ）
５１２  ＡＣＭ処理部（ＡＣＭサーバ）
５１３  放送信号処理部（放送サーバ）
５２０  受信装置
５２１  ミドルウェア
５２２  アプリケーション制御部
５２３  再生制御部
６１０  送信装置
６１１  データ出力部（ＤＡＳＨサーバ）
６１２  ＡＣＭ処理部（ＡＣＭサーバ）
６１３  放送信号処理部（放送サーバ）
６２０  チューナ実装受信装置
６２１  ミドルウェア
６３０  チューナ非実装受信装置
６３１  アプリケーション制御部
６３２  再生制御部
７５１  データ処理部
７５２  通信部
７５３  記憶部
７７１  データ処理部
７７１ａ  再生制御部
７７１ｂ  出力制御部
７７１ｃ  アプリケーション制御部
７７２  通信部
７７３  記憶部
７７４  入力部
７７５  出力部
８０１  ＣＰＵ
８０２  ＲＯＭ
８０３  ＲＡＭ
８０４  バス
８０５  入出力インタフェース
８０６  入力部
８０７  出力部
８０８  記憶部
８０９  通信部
８１０  ドライブ
８１１  リムーバブルメディア
【図１】
2016174959.tif 000003
【図２】
2016174959.tif 000004
【図３】
2016174959.tif 000005
【図４】
2016174959.tif 000006
【図５】
2016174959.tif 000007
【図６】
2016174959.tif 000008
【図７】
2016174959.tif 000009
【図８】
2016174959.tif 000010
【図９】
2016174959.tif 000011
【図１０】
2016174959.tif 000012
【図１１】
2016174959.tif 000013
【図１２】
2016174959.tif 000014
【図１３】
2016174959.tif 000015
【図１４】
2016174959.tif 000016
【図１５】
2016174959.tif 000017
【図１６】
2016174959.tif 000018
【図１７】
2016174959.tif 000019
【図１８】
2016174959.tif 000020
【図１９】
2016174959.tif 000021
【図２０】
2016174959.tif 000022
【図２１】
2016174959.tif 000023
【図２２】
2016174959.tif 000024
【図２３】
2016174959.tif 000025
【図２４】
2016174959.tif 000026
【手続補正書】
【提出日】平成28年6月21日(2016.6.21)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
アプリケーション制御メッセージをイベントデータとして格納したイベント通知データを受信する通信部と、
ＡＶコンテンツを格納したセグメント、および制御情報を通知するシグナリングデータであるＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）を取得して、コンテンツ再生制御を実行する再生制御部と、
前記イベント通知データにイベントデータとして格納されたアプリケーション制御メッセージに基づくアプリケーション制御を実行するアプリケーション制御部を有し、
前記再生制御部は、
取得したＭＰＤ、またはセグメントが、アプリケーション制御メッセージをイベントデータとして格納したイベント通知データである場合、ＭＰＤ、またはセグメントからイベントデータを抽出して前記アプリケーション制御部に出力し、
前記アプリケーション制御部は、前記再生制御部から入力したイベントデータであるアプリケーション制御メッセージに基づくアプリケーション制御を実行する受信装置。
【請求項２】
前記イベント通知データは、
制御情報の通知データとして送信されるシグナリングデータであるＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）を利用したイベント通知方式であるＭＰＤ適用イベント通知方式（ＭＰＤ  Ｅｖｅｎｔ）に従ったデータフォーマットを持つイベント通知データである請求項１に記載の受信装置。
【請求項３】
前記イベント通知データは、
ＡＶコンテンツの送信用データであるセグメントを利用したイベント通知方式であるセグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）に従ったデータフォーマットを持つイベント通知データである請求項１に記載の受信装置。
【請求項４】
前記イベント通知データは、
イベントデータがアプリケーション制御メッセージであることを示すイベント識別子を記録したデータである請求項１に記載の受信装置。
【請求項５】
前記イベント通知データは、
イベントデータとして格納されたアプリケーション制御メッセージに従って処理を実行するための制御時間情報を記録したデータである請求項１に記載の受信装置。
【請求項６】
前記アプリケーション制御メッセージは、
制御対象となるアプリケーション本体、またはアプリケーション識別子を記録したデータである請求項１に記載の受信装置。
【請求項７】
前記アプリケーション制御メッセージは、
制御対象となるアプリケーションに関するメタデータを記録したデータである請求項１に記載の受信装置。
【請求項８】
前記メタデータは、
（ａ）制御対象となるアプリケーションのバージョン、
（ｂ）制御対象となるアプリケーションの実行に必要となるリソース情報、
（ｃ）制御対象となるアプリケーションのレーティング情報、
上記（ａ）〜（ｃ）の少なくともいずれかの情報を含む請求項７に記載の受信装置。
【請求項９】
前記アプリケーション制御メッセージは、
制御対象となるアプリケーションに対するコマンド記録したデータである請求項１に記載の受信装置。
【請求項１０】
前記受信装置は、さらに、
前記通信部の受信したイベント通知データから、アプリケーション制御メッセージを取得して前記アプリケーション制御部に出力するデータ処理部を有する請求項１に記載の受信装置。
【請求項１１】
アプリケーション制御メッセージを受信する通信部と、
前記アプリケーション制御メッセージをイベントデータとして格納したイベント通知データを生成するミドルウェアと、
前記イベント通知データからアプリケーション制御メッセージを取得して、アプリケーション制御部に出力するデータ処理部と、
前記アプリケーション制御メッセージに基づくアプリケーション制御を実行するアプリケーション制御部を有する受信装置。
【請求項１２】
前記ミドルウェアは、
制御情報の通知データとして送信されるシグナリングデータであるＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）を利用したイベント通知方式であるＭＰＤ適用イベント通知方式（ＭＰＤ  Ｅｖｅｎｔ）に従ったデータフォーマットを持つイベント通知データを生成する請求項１１に記載の受信装置。
【請求項１３】
前記ミドルウェアは、
ＡＶコンテンツの送信用データであるセグメントを利用したイベント通知方式であるセグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）に従ったデータフォーマットを持つイベント通知データを生成する請求項１１に記載の受信装置。
【請求項１４】
ＡＶコンテンツを格納したセグメント、および制御情報を通知するシグナリングデータであるＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）を送信するデータ出力部と、
アプリケーション制御メッセージをイベントデータとして格納したイベント通知データを生成するイベント処理部を有し、
前記データ出力部は、
前記イベント処理部が生成したアプリケーション制御メッセージをイベントデータとして格納したイベント通知データを、セグメント、またはＭＰＤに挿入して送信する送信装置。
【請求項１５】
前記イベント通知データは、
制御情報の通知データとして送信されるシグナリングデータであるＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）を利用したイベント通知方式であるＭＰＤ適用イベント通知方式（ＭＰＤ  Ｅｖｅｎｔ）に従ったデータフォーマットを持つイベント通知データである請求項１４に記載の送信装置。
【請求項１６】
前記イベント通知データは、
ＡＶコンテンツの送信用データであるセグメントを利用したイベント通知方式であるセグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）に従ったデータフォーマットを持つイベント通知データである請求項１４に記載の送信装置。
【請求項１７】
受信装置において実行するデータ処理方法であり、
通信部が、ＡＶコンテンツを格納したセグメント、および制御情報を通知するシグナリングデータであるＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）、および、アプリケーション制御メッセージをイベントデータとして格納したイベント通知データを受信し、
再生制御部が、前記セグメント、およびＭＰＤを取得して、コンテンツ再生制御を実行し、
アプリケーション制御部が、イベント通知データにイベントデータとして格納されたアプリケーション制御メッセージに基づくアプリケーション制御を実行し、
前記再生制御部は、
取得したＭＰＤ、またはセグメントが、アプリケーション制御メッセージをイベントデータとして格納したイベント通知データである場合、ＭＰＤ、またはセグメントからイベントデータを抽出して前記アプリケーション制御部に出力し、
前記アプリケーション制御部は、前記再生制御部から入力したイベントデータであるアプリケーション制御メッセージに基づくアプリケーション制御を実行するデータ処理方法。
【請求項１８】
受信装置において実行するデータ処理方法であり、
通信部が、アプリケーション制御メッセージを受信し、
ミドルウェアが、アプリケーション制御メッセージをイベントデータとして格納したイベント通知データを生成し、
データ処理部が、前記イベント通知データからアプリケーション制御メッセージを取得して、アプリケーション制御部に出力し、
アプリケーション制御部が、前記アプリケーション制御メッセージに基づくアプリケーション制御を実行するデータ処理方法。
【請求項１９】
送信装置において実行するデータ処理方法であり、
データ出力部が、ＡＶコンテンツを格納したセグメント、および制御情報を通知するシグナリングデータであるＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）を送信するデータ出力処理と、
イベント処理部が、アプリケーション制御メッセージをイベントデータとして格納したイベント通知データを生成するイベント処理を実行し、
前記データ出力部は、
前記イベント処理部が生成したアプリケーション制御メッセージをイベントデータとして格納したイベント通知データを、セグメント、またはＭＰＤに挿入して送信するデータ処理方法。
【国際調査報告】
2016174959.tif 000027
2016174959.tif 000028
2016174959.tif 000029
2016174959.tif 000030