(57)【要約】緊急情報の迅速、かつ確実な視聴者への提示処理を可能とした構成を実現する。放送コンテンツ出力処理を行なう受信装置のミドルウェアが、送信装置の送信する緊急情報配信通知を受信し、受信した緊急情報配信通知の構成データを含む緊急情報イベント通知データを生成する。出力データ制御部は、イベント通知データを取得し、取得したイベント通知データに基づいて、緊急情報の取得、または表示処理を実行する。例えば、画像上に重畳された緊急情報が配信される場合は、イベント通知により、アプリ提示コンテンツの除去を実行させ、シグナリング緊急情報配信の場合は、迅速な緊急情報の取得、出力処理を実行させる。
2018016295.tif 000002
【特許請求の範囲】
【請求項１】
送信装置からの受信データの解析処理を実行するミドルウェアと、
前記送信装置からの受信データの出力制御処理を実行する出力データ制御部を有し、
前記ミドルウェアは、
送信装置の送信する緊急情報配信通知を受信し、受信した緊急情報配信通知の構成データを含む緊急情報イベント通知データを生成し、
前記出力データ制御部は、
前記イベント通知データを取得し、取得したイベント通知データに基づいて、緊急情報の取得、または表示処理を実行する受信装置。
【請求項２】
送信装置の送信する緊急情報配信通知は、
前記送信装置の送信画像上に重畳された緊急情報の配信を通知するオンスクリーンメッセージ型緊急情報配信通知であり、
前記ミドルウェアは、
オンスクリーンメッセージ型緊急情報配信通知がなされたことを示す緊急情報イベント通知データを生成し、
前記出力データ制御部を構成するアプリケーション制御部は、
取得した緊急情報イベント通知データに基づいて、表示部に対するアプリケーション提示コンテンツの出力を停止して、前記送信装置の送信画像上に重畳された緊急情報を視認可能とする制御を実行する請求項１に記載の受信装置。
【請求項３】
送信装置の送信する緊急情報配信通知は、
前記送信装置から送信されるシグナリングデータによる緊急情報の配信を通知するシグナリングデータ適用型緊急情報配信通知であり、
前記ミドルウェアは、
シグナリングデータ適用型緊急情報配信通知がなされたことを示す緊急情報イベント通知データを生成し、
前記出力データ制御部は、
取得した緊急情報イベント通知データに含まれる緊急情報を表示部出力する処理、
または、取得した緊急情報イベント通知データに含まれる緊急情報アクセス情報を利用して取得した緊急情報を表示部に出力する処理のいずれかを実行する請求項１に記載の受信装置。
【請求項４】
前記シグナリングデータ適用型緊急情報配信通知は、
緊急情報の規格として規定されたＡＥＡＴ（Ａｄｖａｎｃｅｄ  Ｅｍｅｒｇｅｎｃｙ  Ａｌｅｒｔｉｎｇ  Ｔａｂｌｅ）を含む通知である請求項３に記載の受信装置。
【請求項５】
前記ミドルウェアは、
前記前記緊急情報イベント通知データとして、
前記緊急情報配信通知の構成データを、ＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）に挿入した緊急情報イベント挿入ＭＰＤを生成し、
前記出力データ制御部は、
前記緊急情報イベント挿入ＭＰＤからの取得情報に基づいて、緊急情報の取得、または表示処理を実行する請求項１に記載の受信装置。
【請求項６】
前記ミドルウェアは、
前記出力データ制御部に、前記緊急情報イベント挿入ＭＰＤを遅滞なく取得させるための事前処理として、
前記出力データ制御部に対してＭＰＤ更新通知を出力する請求項５に記載の受信装置。
【請求項７】
前記ミドルウェアは、
前記緊急情報イベント通知データとして、
前記緊急情報配信通知の構成データを、セグメントに挿入した緊急情報イベント挿入セグメントを生成し、
前記出力データ制御部は、
前記緊急情報イベント挿入セグメントからの取得情報に基づいて、緊急情報の取得、または表示処理を実行する請求項１に記載の受信装置。
【請求項８】
前記ミドルウェアは、
生成した緊急情報イベント通知データをキャッシュ部に格納し、
前記出力データ制御部は、
前記キャッシュ部をアクセスして、前記イベント通知データを取得する請求項１に記載の受信装置。
【請求項９】
前記ミドルウェアは、
前記緊急情報イベント通知データを生成し、送信するイベント処理サーバを有し、
前記出力データ制御部は、
前記緊急情報イベント通知データを、前記イベント処理サーバから受信するイベント処理クライアントを有し、
前記イベント処理クライアントは、前記イベント処理サーバと間でイベント転送専用のセッションを確立して、確立した専用セッションを介して前記緊急情報イベント通知データを前記イベント処理サーバから受信する請求項１に記載の受信装置。
【請求項１０】
送信装置からの受信データの解析処理を実行するミドルウェアを有し、
前記ミドルウェアは、
送信装置の送信する緊急情報配信通知を受信し、受信した緊急情報配信通知の構成データを含む緊急情報イベント通知データを生成し、
生成した緊急情報イベント通知データを、前記送信装置からの受信データの出力制御処理を実行するクライアントに提供する受信装置。
【請求項１１】
送信装置の送信する緊急情報配信通知は、
前記送信装置の送信画像上に重畳された緊急情報の配信を通知するオンスクリーンメッセージ型緊急情報配信通知であり、
前記ミドルウェアは、
オンスクリーンメッセージ型緊急情報配信通知がなされたことを示す緊急情報イベント通知データを生成する請求項１０に記載の受信装置。
【請求項１２】
送信装置の送信する緊急情報配信通知は、
前記送信装置から送信されるシグナリングデータによる緊急情報の配信を通知するシグナリングデータ適用型緊急情報配信通知であり、
前記ミドルウェアは、
シグナリングデータ適用型緊急情報配信通知がなされたことを示す緊急情報イベント通知データを生成する請求項１０に記載の受信装置。
【請求項１３】
前記ミドルウェアは、
前記前記緊急情報イベント通知データとして、
前記緊急情報配信通知の構成データを、ＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）に挿入した緊急情報イベント挿入ＭＰＤを生成する請求項１０に記載の受信装置。
【請求項１４】
前記ミドルウェアは、
前記緊急情報イベント通知データとして、
前記緊急情報配信通知の構成データを、セグメントに挿入した緊急情報イベント挿入セグメントを生成する請求項１０に記載の受信装置。
【請求項１５】
送信装置からの受信データの出力制御処理を実行する出力データ制御部を有し、
前記出力データ制御部は、
前記送信装置の送信する緊急情報配信通知の構成データを含む緊急情報イベント通知データを取得し、
取得したイベント通知データに基づいて、緊急情報の取得、または表示処理を実行する受信装置。
【請求項１６】
送信装置の送信する緊急情報配信通知は、
前記送信装置の送信画像上に重畳された緊急情報の配信を通知するオンスクリーンメッセージ型緊急情報配信通知であり、
前記出力データ制御部は、
オンスクリーンメッセージ型緊急情報配信通知がなされたことを示す緊急情報イベント通知データを取得し、
前記出力データ制御部を構成するアプリケーション制御部は、
取得した緊急情報イベント通知データに基づいて、表示部に対するアプリケーション提示コンテンツの出力を停止して、前記送信装置の送信画像上に重畳された緊急情報を視認可能とする制御を実行する請求項１５に記載の受信装置。
【請求項１７】
送信装置の送信する緊急情報配信通知は、
前記送信装置から送信されるシグナリングデータによる緊急情報の配信を通知するシグナリングデータ適用型緊急情報配信通知であり、
前記出力データ制御部は、
シグナリングデータ適用型緊急情報配信通知がなされたことを示す緊急情報イベント通知データを取得し、
取得した緊急情報イベント通知データに含まれる緊急情報を表示部出力する処理、
または、取得した緊急情報イベント通知データに含まれる緊急情報アクセス情報を利用して取得した緊急情報を表示部に出力する処理のいずれかを実行する請求項１５に記載の受信装置。
【請求項１８】
受信装置において実行するデータ処理方法であり、
前記受信装置は、
送信装置からの受信データの解析処理を実行するミドルウェアと、
前記送信装置からの受信データの出力制御処理を実行する出力データ制御部を有し、
前記ミドルウェアが、
送信装置の送信する緊急情報配信通知を受信し、受信した緊急情報配信通知の構成データを含む緊急情報イベント通知データを生成し、
前記出力データ制御部が、
前記イベント通知データを取得し、取得したイベント通知データに基づいて、緊急情報の取得、または表示処理を実行するデータ処理方法。
【請求項１９】
受信装置において実行するデータ処理方法であり、
前記受信装置は、
送信装置からの受信データの解析処理を実行するミドルウェアを有し、
前記ミドルウェアが、
送信装置の送信する緊急情報配信通知を受信し、受信した緊急情報配信通知の構成データを含む緊急情報イベント通知データを生成し、
生成した緊急情報イベント通知データを、前記送信装置からの受信データの出力制御処理を実行するクライアントに提供するデータ処理方法。
【請求項２０】
受信装置において実行するデータ処理方法であり、
前記受信装置は、
送信装置からの受信データの出力制御処理を実行する出力データ制御部を有し、
前記出力データ制御部が、
前記送信装置の送信する緊急情報配信通知の構成データを含む緊急情報イベント通知データを取得し、
取得したイベント通知データに基づいて、緊急情報の取得、または表示処理を実行するデータ処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、受信装置、およびデータ処理方法に関する。さらに詳細には例えば放送波やネットワークを介したデータを受信し、受信データを表示部等に出力する処理を実行する受信装置、および通信データ対応のデータ処理方法に関する。
【背景技術】
【０００２】
画像データや音声データ等のコンテンツを各通信事業者のサービス形態に関わらず配信可能としたデータ配信方式としてＯＴＴ（Ｏｖｅｒ  Ｔｈｅ  Ｔｏｐ）がある。ＯＴＴによる配信コンテンツはＯＴＴコンテンツと呼ばれ、また、ＯＴＴを利用した画像（ビデオ）データの配信サービスはＯＴＴビデオやＯＴＴ−Ｖ（Ｏｖｅｒ  Ｔｈｅ  Ｔｏｐ  Ｖｉｄｅｏ）と呼ばれる。【０００３】
ＯＴＴ−Ｖに従ったデータストリーミング配信規格としてＤＡＳＨ（Ｄｙｎａｍｉｃ  Ａｄａｐｔｉｖｅ  Ｓｔｒｅａｍｉｎｇ  ｏｖｅｒＨＴＴＰ）規格がある。ＤＡＳＨは、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）をベースとしたストリーミングプロトコルを用いたアダプティブ（適応型）ストリーミング配信に関する規格である。【０００４】
アダプティブ（適応型）ストリーミングでは、放送局等のコンテンツ配信サーバは、データ配信先となる様々なクライアントにおいてコンテンツ再生を可能とするため、複数のビットレートの動画コンテンツの細分化ファイルとこれらの属性情報やＵＲＬを記述したマニフェスト・ファイルを作成し、クライアントに提供する。【０００５】
クライアントは、マニフェスト・ファイルをサーバから取得して、自装置の表示部のサイズや利用可能な通信帯域に応じた最適なビットレートコンテンツを選択し、選択コンテンツを受信して再生する。ネットワーク帯域の変動に応じてビットレートの動的な変更も可能であり、クライアント側では、状況に応じた最適なコンテンツを随時切り替えて受信することが可能となり、映像途切れの発生を低減した動画コンテンツ再生が実現される。なお、アダプティブ（適応型）ストリーミングについては、例えば特許文献１（特開２０１１−８７１０３号公報）に記載がある。【０００６】
放送局やその他のコンテンツサーバ等の送信装置から、テレビ、ＰＣ、携帯端末等の受信装置に対して、放送波等による一方向通信、あるいは、インターネット等のネットワークを介した双方向通信、一方向通信を用いて放送番組等のコンテンツを送受信するシステムについての開発や規格化が、現在、盛んに進められている。
なお、放送波およびネットワークを介したデータ配信を実現するための技術を開示した従来技術として、例えば特許文献２（特開２０１４−０５７２２７号公報）がある。【０００７】
放送波およびネットワークを介したデータ配信システムに関する規格として、現在、ＡＴＳＣ（Ａｄｖａｎｃｅｄ  Ｔｅｌｅｖｉｓｉｏｎ  Ｓｙｓｔｅｍ  Ｃｏｍｍｉｔｔｅ）３．０の規格化が進行中である。
ＡＴＳＣ３．０では、ＡＴＳＣ３．０準拠物理層（ＡＴＳＣ−ＰＨＹ）を実装した放送配信用デバイス（チューナ実装デバイス）上に、ＡＴＳＣ３．０放送の受信処理等を実行するミドルウェア（ＡＴＳＣ３．０放送受信ミドルウェア）を実装させることで、ＡＴＳＣ放送用の制御情報等を含むシグナリングデータを受信して、シグナリングデータによる様々な制御を可能とする構成を検討している。【０００８】
具体的には、シグナリングデータによる制御によって、インターネット等で利用されているアプリケーションプログラム、いわゆるクライアントアプリケーションをそのまま利用して、放送コンテンツの出力処理や、放送波等によって提供される様々なアプリケーションを利用したデータ処理を実現可能とする構成を検討している。【０００９】
例えば、家庭内やホットスポットに設置された放送サービスを受信するサーバ（専用サーバの他、ＰＣ、ＴＶ、タブレット、スマホ等）にＡＴＳＣ３．０準拠物理層（ＡＴＳＣ−ＰＨＹ）、ならびに、ＡＴＳＣ３．０放送受信ミドルウェアを実装する。
これらのサーバが、いったんＡＴＳＣ３．０放送サービスを受信した後、ネットワーク（ホームネットワークやホットスポット等のＬＡＮ／ＷｉＦｉ等）を介して、ユーザ装置（ＰＣ、ＴＶ、タブレット、スマホ等）に放送受信データを転送する。【００１０】
サーバを介して転送された放送受信データを入力したユーザ装置は、ユーザ装置の再生制御部やアプリケーション制御部上で稼働するアプリケーション（例えばＡＴＳＣ３．０  ＤＡＳＨクライアントアプリケーション）を利用して、放送コンテンツの再生や、放送で配信される様々なアプリケーションを実行することが可能となる。【００１１】
この形態では、ＡＴＳＣ３．０放送サービスの制御情報を含むシグナリングデータの解析等を実行するミドルウェア（ＡＴＳＣ３．０放送受信ミドルウェア）が、シグナリングデータの受信タイミングにおける即時解析処理が可能な終端デバイスとなる。【００１２】
ミドルウェア（ＡＴＳＣ３．０放送受信ミドルウェア）は、例えば、送信装置２０から緊急情報を受信する場合がある。具体的には、例えば、地震発生やテロ発生等の緊急情報である。
ミドルウェアは、このような緊急情報の受信を検知したタイミングでできるだけ早く、放送サービスの出力（表示）制御を実行している再生制御部（クライアント）に通知し、緊急情報を表示データとして出力させることが必要となる。【００１３】
ミドルウェアが、例えばホームサーバによって構成される場合、ミドルウェアには、ネットワークを介して様々なリモートのクライアント（ＰＣ、ＴＶ、タブレット、スマホ等）が接続される可能性がある。
これらのリモートのクライアントでは、各クライアントの再生制御部やアプリケーション制御部が、様々なデータを表示部に表示している。
ミドルウェアは、このようなリモートクライアントの再生制御部やアプリケーション制御部に対しても、できるだけ早く緊急情報が受信されたことを通知し、緊急情報を表示データとして出力させることが必要となる。【００１４】
例えば、放送番組の番組画像上に緊急メッセージが重畳された放送コンテンツを、ミドルウェアからスマホに転送してスマホの画面に表示していても、その画面上にスマホが実行する何らかのアプリケーションによる提示物が表示されると、緊急情報がアプリ提示物によって隠れてしまい、スマホのユーザ（視聴者）が緊急情報を確認できない状況が発生する。
このような場合、スマホのアプリケーション制御部にアプリ提示物を削除させる処理を要求することが必要となる。【００１５】
なお、例えば、米国では、ＥＡＳ（Ｅｍｅｒｇｅｎｃｙ  Ａｌｅｒｔ  Ｓｙｓｔｅｍ）と呼ばれる緊急情報通知システムが整備されており、このＥＡＳを利用して、様々な緊急情報、例えば気象災害情報や、テロ情報、その他の緊急避難情報などをいち早く通知することを可能としている。ＥＡＳを利用して通知される緊急情報には、例えば大統領からのメッセージ等、国家レベルの通知事項や、州、あるいは地方政府レベルのローカルな通知事項など、様々な異なるレベルの緊急情報がある。
【先行技術文献】
【特許文献】
【００１６】
【特許文献１】特開２０１１−８７１０３号公報
【特許文献２】特開２０１４−０５７２２７号公報
【発明の概要】
【発明が解決しようとする課題】
【００１７】
本開示は、例えば上記問題点に鑑みてなされたものであり、受信データの解析等を実行するミドルウェアが緊急情報を受信した場合、ミドルウェアを介して受信データの再生を実行する様々なクライアントに通知し、クライアントによる緊急情報の確実な提示を実現する受信装置、およびデータ処理方法を提供することを目的とする。
【課題を解決するための手段】
【００１８】
本開示の第１の側面は、
送信装置からの受信データの解析処理を実行するミドルウェアと、
前記送信装置からの受信データの出力制御処理を実行する出力データ制御部を有し、
前記ミドルウェアは、
送信装置の送信する緊急情報配信通知を受信し、受信した緊急情報配信通知の構成データを含む緊急情報イベント通知データを生成し、
前記出力データ制御部は、
前記イベント通知データを取得し、取得したイベント通知データに基づいて、緊急情報の取得、または表示処理を実行する受信装置にある。【００１９】
さらに、本開示の第２の側面は、
送信装置からの受信データの解析処理を実行するミドルウェアを有し、
前記ミドルウェアは、
送信装置の送信する緊急情報配信通知を受信し、受信した緊急情報配信通知の構成データを含む緊急情報イベント通知データを生成し、
生成した緊急情報イベント通知データを、前記送信装置からの受信データの出力制御処理を実行するクライアントに提供する受信装置にある。【００２０】
さらに、本開示の第３の側面は、
送信装置からの受信データの出力制御処理を実行する出力データ制御部を有し、
前記出力データ制御部は、
前記送信装置の送信する緊急情報配信通知の構成データを含む緊急情報イベント通知データを取得し、
取得したイベント通知データに基づいて、緊急情報の取得、または表示処理を実行する受信装置にある。【００２１】
さらに、本開示の第４の側面は、
受信装置において実行するデータ処理方法であり、
前記受信装置は、
送信装置からの受信データの解析処理を実行するミドルウェアと、
前記送信装置からの受信データの出力制御処理を実行する出力データ制御部を有し、
前記ミドルウェアが、
送信装置の送信する緊急情報配信通知を受信し、受信した緊急情報配信通知の構成データを含む緊急情報イベント通知データを生成し、
前記出力データ制御部が、
前記イベント通知データを取得し、取得したイベント通知データに基づいて、緊急情報の取得、または表示処理を実行するデータ処理方法にある。【００２２】
さらに、本開示の第５の側面は、
受信装置において実行するデータ処理方法であり、
前記受信装置は、
送信装置からの受信データの解析処理を実行するミドルウェアを有し、
前記ミドルウェアが、
送信装置の送信する緊急情報配信通知を受信し、受信した緊急情報配信通知の構成データを含む緊急情報イベント通知データを生成し、
生成した緊急情報イベント通知データを、前記送信装置からの受信データの出力制御処理を実行するクライアントに提供するデータ処理方法にある。【００２３】
さらに、本開示の第６の側面は、
受信装置において実行するデータ処理方法であり、
前記受信装置は、
送信装置からの受信データの出力制御処理を実行する出力データ制御部を有し、
前記出力データ制御部が、
前記送信装置の送信する緊急情報配信通知の構成データを含む緊急情報イベント通知データを取得し、
取得したイベント通知データに基づいて、緊急情報の取得、または表示処理を実行するデータ処理方法にある。【００２４】
本開示のさらに他の目的、特徴や利点は、後述する本開示の実施例や添付する図面に基づくより詳細な説明によって明らかになるであろう。なお、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。
【発明の効果】
【００２５】
本開示の一実施例の構成によれば、緊急情報の迅速、かつ確実な視聴者への提示処理を可能とした構成が実現される。
具体的には、例えば、放送コンテンツ出力処理を行なう受信装置のミドルウェアが、送信装置の送信する緊急情報配信通知を受信し、受信した緊急情報配信通知の構成データを含む緊急情報イベント通知データを生成する。出力データ制御部は、イベント通知データを取得し、取得したイベント通知データに基づいて、緊急情報の取得、または表示処理を実行する。例えば、画像上に重畳された緊急情報が配信される場合は、イベント通知により、アプリ提示コンテンツの除去を実行させ、シグナリング緊急情報配信の場合は、迅速な緊急情報の取得、出力処理を実行させる。
本構成により、緊急情報の迅速、かつ確実な視聴者への提示処理を可能とした構成が実現される。
なお、本明細書に記載された効果はあくまで例示であって限定されるものではなく、また付加的な効果があってもよい。
【図面の簡単な説明】
【００２６】
【図１】本開示の処理を実行する通信システムの一構成例について説明する図である。
【図２】送信装置の送信データについて説明する図である。
【図３】送信装置および受信装置のプロトコルスタックの例を示す図である。
【図４】ＲＯＵＴＥ／ＦＬＵＴＥプロトコルスタックについて説明する図である。
【図５】緊急情報の送受信と表示処理例について説明する図である。
【図６】緊急情報の送受信と表示処理例について説明する図である。
【図７】緊急情報の送受信と表示処理例について説明する図である。
【図８】緊急情報の送受信と表示処理例について説明する図である。
【図９】緊急情報の送受信と表示処理例について説明する図である。
【図１０】受信装置の構成例について説明する図である。
【図１１】受信装置の構成例について説明する図である。
【図１２】緊急情報送信通知データの構成例について説明する図である。
【図１３】緊急情報送信通知データの構成例について説明する図である。
【図１４】ＭＰＤの構成例について説明する図である。
【図１５】ＭＰＤの構成例について説明する図である。
【図１６】イベント通知ＭＰＤの構成例について説明する図である。
【図１７】ＭＰＤの利用シーケンス例について説明する図である。
【図１８】イベント情報の生成、送信、利用シーケンスについて説明する図である。
【図１９】イベント情報を格納するセグメントの構成について説明する図である。
【図２０】イベント情報を格納したセグメント内のデータ構成例について説明する図である。
【図２１】イベント情報の生成、送信、利用シーケンスについて説明する図である。
【図２２】オンスクリーンメッセージイベント（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ  Ｅｖｅｎｔ）情報を記録したＭＰＤのデータ構成例について説明する図である。
【図２３】オンスクリーンメッセージイベント（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ  Ｅｖｅｎｔ）をセグメント内に設定したイベント情報格納ボックス（ｅｍｓｇ）のデータ構成例について説明する図である。
【図２４】緊急情報、オンスクリーンメッセージイベントの生成、送信、利用シーケンスについて説明する図である。
【図２５】シグナリングデータ適用型緊急情報（ＡＥＡＴ）配信イベント（ＡＥＡＴＤｅｌｉｖｅｒｅｄ  Ｅｖｅｎｔ）情報を記録したＭＰＤのデータ構成例について説明する図である。
【図２６】シグナリングデータ適用型緊急情報（ＡＥＡＴ）配信イベント（ＡＥＡＴＤｅｌｉｖｅｒｅｄ  Ｅｖｅｎｔ）をセグメント内に設定したイベント情報格納ボックス（ｅｍｓｇ）のデータ構成例について説明する図である。
【図２７】緊急情報、シグナリングデータ適用型緊急情報配信イベントの生成、送信、利用シーケンスについて説明する図である。
【図２８】イベント処理サーバとイベント処理クライアントを有する受信装置の構成例について説明する図である。
【図２９】イベント処理サーバとイベント処理クライアントを利用した緊急情報、オンスクリーンメッセージイベントの生成、送信、利用シーケンスについて説明する図である。
【図３０】イベント処理サーバとイベント処理クライアントを利用した緊急情報、シグナリングデータ適用型緊急情報配信イベントの生成、送信、利用シーケンスについて説明する図である。
【図３１】通信装置である送信装置と受信装置の構成例について説明する図である。
【図３２】通信装置である送信装置と受信装置のハードウェア構成例について説明する図である。
【発明を実施するための形態】
【００２７】
以下、図面を参照しながら本開示の受信装置、およびデータ処理方法の詳細について説明する。なお、説明は以下の項目に従って行なう。
１．通信システムの構成例について
２．データ通信プロトコルＦＬＵＴＥ、およびＲＯＵＴＥについて
３．送信装置と受信装置の実行する通信処理例について
４．緊急情報の送信と出力処理の概要について
５．受信装置の構成例と処理例について
６．シグナリングデータを適用した緊急情報配信通知処理について
７．イベント通知構成について
７−１．ＭＰＤ適用イベント通知方式（＝ＭＰＤ  Ｅｖｅｎｔ）について
７−２．セグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）について
８．緊急情報配信通知処理のためのイベント通知構成について
８−１．オンスクリーンメッセージ型緊急情報配信通知をイベント情報として通知する構成について
８−１−１．ＭＰＤ適用イベント通知方式を適用したオンスクリーンメッセージ型緊急情報配信通知の通知構成について
８−１−２．セグメント適用（Ｉｎ−ｂａｎｄ）イベント通知方式を適用したオンスクリーンメッセージ型緊急情報配信通知の通知構成について
８−１−３．オンスクリーンメッセージ型緊急情報配信通知に基づくイベント生成、転送、およびイベントに基づく処理の実行シーケンスについて
８−２．シグナリングデータ適用型緊急情報配信通知をイベント情報として通知する構成について
８−２−１．ＭＰＤ適用イベント通知方式を適用したシグナリングデータ適用型緊急情報配信通知の通知構成について
８−２−２．セグメント適用（Ｉｎ−ｂａｎｄ）イベント通知方式を適用したシグナリングデータ適用型緊急情報配信通知の通知構成について
８−２−３．シグナリングデータ適用型緊急情報配信通知に基づくイベント生成、転送、およびイベントに基づく処理の実行シーケンスについて
９．イベント情報の転送専用のサーバとクライアントを有する構成例について］
９−１．オンスクリーンメッセージ型緊急情報配信通知に基づくイベント生成、転送、およびイベントに基づく処理の実行シーケンスについて
９−２．シグナリングデータ適用型緊急情報配信通知に基づくイベント生成、転送、およびイベントに基づく処理の実行シーケンスについて
１０．送信装置と受信装置の構成例について
１１．本開示の構成のまとめ
【００２８】
［１．通信システムの構成例について］
まず、図１を参照して本開示の処理を実行する通信システムの一構成例について説明する。
図１に示すように、通信システム１０は、画像データや音声データ等のコンテンツを送信する通信装置である送信装置２０と、送信装置２０の送信するコンテンツを放送波やネットワークを介して受信する通信装置であるチューナ実装受信装置３０と、送信装置２０の送信するコンテンツをチューナ実装受信装置３０、ネットワークを介して受信するチューナ非実装受信装置４０を有する。
【００２９】
送信装置２０は、具体的には、例えば放送局２１やコンテンツサーバ２２等、コンテンツを提供する装置である。
チューナ実装受信装置３０は、放送波を受信するためのチューナを備えた受信装置である。例えば一般ユーザのクライアント装置やホームサーバ、公共施設に設置された中継サーバ等である。具体的には、例えば、中継サーバ（ホームサーバ等を含む）３１、テレビ３２、ＰＣ３３、携帯端末３４等である。
また、チューナ非実装受信装置４０は、放送波を受信するためのチューナを備えていない受信装置である。具体的には、例えば、ＰＣ４１、携帯端末４２等である。
【００３０】
送信装置２０とチューナ実装受信装置３０間のデータ通信は、インターネット等のネットワークを介した双方向通信、一方向通信、あるいは、放送波等による一方向通信の少なくともいずれか、あるいは両者を利用した通信として行われる。
【００３１】
送信装置２０からチューナ実装受信装置３０に対するコンテンツ送信は、例えばアダプティブ（適応型）ストリーミング技術の規格であるＤＡＳＨ（ＭＰＥＧ−ＤＡＳＨ）規格に従って実行する。
なお、ＤＡＳＨ（Ｄｙｎａｍｉｃ  Ａｄａｐｔｉｖｅ  Ｓｔｒｅａｍｉｎｇ  ｏｖｅｒＨＴＴＰ）規格は、前述したようにＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）をベースとしたストリーミングプロトコルを用いたアダプティブ（適応型）ストリーミング配信に関する規格である。
【００３２】
ＭＰＥＧ−ＤＡＳＨ規格には、以下の２つの規格が含まれる。
（ａ）動画や音声ファイルの管理情報であるメタデータを記述するためのマニフェスト・ファイル（ＭＰＤ：Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）に関する規格、
（ｂ）動画コンテンツ伝送用のファイル・フォーマット（セグメント・フォーマット）に関する規格、
送信装置２０から、チューナ実装受信装置３０に対するコンテンツ配信は、上記のＭＰＥＧ−ＤＡＳＨ規格に従って実行される。
【００３３】
チューナ実装受信装置３０が受信したコンテンツは、ネットワーク（家庭内ならホームネットワーク（ＬＡＮ／ＷｉＦｉ等）、ホットスポットならＷｉＦｉ等）を介して、チューナ非実装受信装置４０に転送される。
チューナ実装受信装置３０や、チューナ非実装受信装置４０は、送信装置２０の送信したコンテンツの再生を行なうことができる。
【００３４】
送信装置２０は、コンテンツデータを符号化し、符号化データおよび符号化データのメタデータを含むデータファイルを生成する。符号化処理は、例えばＭＰＥＧにおいて規定されるＭＰ４ファイルフォーマットに従って行われる。なお、送信装置２０がＭＰ４形式のデータファイルを生成する場合の符号化データのファイルは「ｍｄａｔ」、メタデータは「ｍｏｏｖ」や「ｍｏｏｆ」等と呼ばれる。
【００３５】
送信装置２０がチューナ実装受信装置３０に提供するコンテンツは、例えば音楽データや、映画、テレビ番組、ビデオ、写真、文書、絵画および図表などの映像データや、ゲームおよびソフトウェアなど、様々なデータである。
【００３６】
送信装置２０の送信データについて図２を参照して説明する。
ＭＰＥＧ−ＤＡＳＨ規格に従ってデータ送信を実行する送信装置２０は、図２に示すように、大きく分けて以下の複数種類のデータの送信を行う。
（ａ）シグナリングデータ５０
（ｂ）ＡＶセグメント６０
（ｃ）その他のデータ（ＥＳＧ，ＮＲＴコンテンツ等）７０
【００３７】
ＡＶセグメント６０は、受信装置において再生する画像（Ｖｉｄｅｏ）や、音声（Ａｕｄｉｏ）データ、すなわち例えば放送局の提供する番組コンテンツ等によって構成される。例えば、上述したＭＰ４符号化データ（ｍｄａｔ）や、メタデータ（ｍｏｏｖ，ｍｏｏｆ）によって構成される。なお、ＡＶセグメントは、ＤＡＳＨセグメントとも呼ばれる。
【００３８】
一方、シグナリングデータ５０は、番組表等の番組予定情報や、番組取得に必要となるアドレス情報（ＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）等）、さらにコンテンツの再生処理に必要な情報、例えばコーデック情報（符号化方式など）などの制御情報、案内情報、通知情報、アプリケーション制御情報、さらに、地震情報、テロ情報等の緊急情報等、様々な情報によって構成される。
このシグナリングデータ５０は、例えばＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）形式のデータとして送信装置２０から送信される。
【００３９】
シグナリングデータは、随時、繰り返し送信される。例えば１００ｍｓｅｃ毎など、頻繁に繰り返し送信される。
これは、受信装置（クライアント）が、いつでも、即座にシグナリングデータを取得することを可能とするためである。
クライアント（受信装置）は、随時、受信可能なシグナリングデータに基づいて、必要な番組コンテンツのアクセス用アドレスの取得や、コーデック設定処理など、番組コンテンツの受信および再生に必要な処理を遅滞なく実行することが可能となる。
また、地震情報、テロ情報等の緊急情報についても、大きな遅れを発生させることなく多くの受信装置に一生に提供することが可能となる。
【００４０】
その他のデータ７０は、例えばＥＳＧ（Ｅｌｅｃｔｒｏｎｉｃ  Ｓｅｒｖｉｃｅ  Ｇｕｉｄｅ）、ＮＲＴコンテンツ等が含まれる。
ＥＳＧは、電子サービスガイド（Ｅｌｅｃｔｒｏｎｉｃ  Ｓｅｒｖｉｃｅ  Ｇｕｉｄｅ）であり、例えば番組表等の案内情報である。
ＮＲＴコンテンツはノンリアルタイム型のコンテンツである。
【００４１】
ＮＲＴコンテンツには、例えば、クライアントである受信装置３０のブラウザ上で実行される様々なアプリケーションファイル、動画、静止画等のデータファイル等が含まれる。
【００４２】
図２に示す以下のデータ、すなわち、
（ａ）シグナリングデータ５０
（ｂ）ＡＶセグメント６０
（ｃ）その他のデータ（ＥＳＧ，ＮＲＴコンテンツ等）７０
これらのデータは、例えば、データ通信プロトコル：ＦＬＵＴＥ（Ｆｉｌｅ  Ｄｅｌｉｖｅｒｙ  ｏｖｅｒ  Ｕｎｉ−ｄｉｒｅｃｔｉｏｎａｌ  Ｔｒａｎｓｐｏｒｔ）に従って送信される。
【００４３】
［２．データ通信プロトコルＦＬＵＴＥ、およびＲＯＵＴＥについて］
データ通信プロトコル：ＦＬＵＴＥ（Ｆｉｌｅ  Ｄｅｌｉｖｅｒｙ  ｏｖｅｒ  Ｕｎｉ−ｄｉｒｅｃｔｉｏｎａｌ  Ｔｒａｎｓｐｏｒｔ）はマルチキャストにより伝送するコンテンツのセッション管理を行うプロトコルである。
例えば送信装置であるサーバ側で生成されるファイル（ＵＲＬとバージョンで識別される）は、ＦＬＵＴＥプロトコルに従って、受信装置であるクライアントに送信される。
【００４４】
チューナ実装受信装置（クライアント）３０は、例えば記憶部（クライアントキャッシュ）に、受信ファイルのＵＲＬおよびバージョンとファイルを対応付けて蓄積する。
同じＵＲＬでバージョンが異なるものはファイルの中身が更新されているものとみなす。ＦＬＵＴＥプロトコルは一方向ファイル転送制御のみを行うもので、クライアントにおけるファイルの選択的なフィルタリング機能はないが、ＦＬＵＴＥで転送制御するファイルをそのファイルに紐づけられるメタデータを利用して、クライアント側で取捨選択することにより、選択的なフィルタリングを実現し、ユーザの嗜好を反映したローカルキャッシュを構成・更新管理することが可能となる。
なお、メタデータは、ＦＬＵＴＥプロトコルに拡張して組み込むこともできるし、別途ＥＳＧ（Ｅｌｅｃｔｒｏｎｉｃ  Ｓｅｒｖｉｃｅ  Ｇｕｉｄｅ）等のプロトコルで記述することもできる。
【００４５】
なお、ＦＬＵＴＥは、当初マルチキャストにおけるファイル転送プロトコルとして仕様化された。ＦＬＵＴＥは、ＦＤＴと、ＡＬＣと呼ばれるスケーラブルなファイルオブジェクトのマルチキャストプロトコル、具体的にはそのビルディングブロックであるＬＣＴやＦＥＣコンポーネント、の組み合わせにより構成される。
【００４６】
従来のＦＬＵＴＥは、主に非同期型のファイル転送に利用するために開発されたが、現在、放送波およびネットワークを介したデータ配信システムに関する規格化団体であるＡＴＳＣ（Ａｄｖａｎｃｅｄ  Ｔｅｌｅｖｉｓｉｏｎ  Ｓｙｓｔｅｍ  Ｃｏｍｍｉｔｔｅ）において、ブロードキャストライブストリーミングにも適用しやすくするための拡張を行っている。このＦＬＵＴＥの拡張仕様がＲＯＵＴＥ（Ｒｅａｌ−Ｔｉｍｅ  Ｏｂｊｅｃｔ  Ｄｅｌｉｖｅｒｙ  ｏｖｅｒ  Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ  Ｔｒａｎｓｐｏｒｔ）と呼ばれる。
【００４７】
放送波およびネットワークを介したデータ配信システムに関する規格の１つとして現在、標準化が進められている規格としてＡＴＳＣ（Ａｄｖａｎｃｅｄ  Ｔｅｌｅｖｉｓｉｏｎ  Ｓｙｓｔｅｍ  Ｃｏｍｍｉｔｔｅ）３．０がある。このＡＴＳＣ３．０は、ＲＯＵＴＥを従来のＦＬＵＴＥプロトコルに置き換えて、シグナリングデータや、ＥＳＧ、あるいは非同期ファイル、同期型ストリーム等の送信に採用したスタック構成を規定している。
【００４８】
［３．送信装置と受信装置の実行する通信処理例について］
次に、送信装置と受信装置の実行する通信処理例について説明する。
図３は、送信装置および受信装置のプロトコルスタックの例を示す図である。
図３に示す例は、以下の２つの通信データの処理を行なうための２つのプロトコルスタックを有する。
（ａ）ブロードキャスト（マルチキャストも含む）通信（例えば放送型データ配信）
（ｂ）ユニキャスト（ブロードバンド）通信（例えばＨＴＴＰ型のＰ２Ｐ通信）
【００４９】
図３の左側が（ａ）ブロードキャスト通信（例えば放送型データ配信）に対応するプロトコルスタックである。
図３の右側が、（ｂ）ユニキャスト（ブロードバンド）通信（例えばＨＴＴＰ型のＰ２Ｐ通信）に対応するプロトコルスタックである。
【００５０】
図３左側に示す（ａ）ブロードキャスト通信（例えば放送型データ配信）に対応するプロトコルスタックは、下位レイヤから順に、以下のレイヤを持つ。
（１）ブロードキャスト物理レイヤ（Ｂｒｏａｄｃａｓｔ  ＰＨＹ）
（２）ＩＰマルチキャストレイヤ（ＩＰ  Ｍｕｌｔｉｃａｓｔ）
（３）ＵＤＰレイヤ
（４）ＲＯＵＴＥ（＝拡張型ＦＬＵＴＥ）レイヤ
（５）ＥＳＧ，ＮＲＴｃｏｎｔｅｎｔ，ＤＡＳＨ（ＩＳＯ  ＢＭＦＦ）およびＶｉｄｅｏ／Ａｕｄｉｏ／ＣＣ、シグナリング（ＳＬＳ：Ｓｅｒｖｉｃｅ  Ｌｅｖｅｌ  Ｓｉｇｎａｌｉｎｇ）
（６）アプリケーションレイヤ（Ａｐｐｌｉｃａｔｉｏｎｓ（ＨＴＭＬ５））
【００５１】
なお、（２）ＩＰマルチキャストレイヤ（ＩＰ  Ｍｕｌｔｉｃａｓｔ）、ＵＤＰレイヤの上位レイヤとしてもシグナリングデータのレイヤが設定される。
【００５２】
シグナリングレイヤは、先に図２を参照して説明したシグナリングデータ５０の送受信に適用されるレイヤである。シグナリングデータには、番組表等の番組予定情報や、番組取得に必要となるアドレス情報（ＵＲＬ等）、さらにコンテンツの再生処理に必要な情報、例えばコーデック情報（符号化方式など）などからなる案内情報、制御情報、さらに、地震情報、テロ情報等の緊急情報等、様々な情報が含まれる。
【００５３】
シグナリングデータには、例えば以下の２つの異なるタイプのシグナリングデータがある。
ＬＬＳ（ローワレイヤシグナリング）
ＳＬＳ（サービスレベルシグナリング）
ＳＬＳ（サービスレベルシグナリング）は、各サービス単位、例えば各番組単位の制御情報、案内情報、メタデータ等を格納したシグナリングデータである。
ＬＬＳ（ローワレイヤシグナリング）は、ＳＬＳより上位の制御情報、案内情報、メタデータ等を格納したシグナリングデータであり、例えば、ＳＬＳを取得するための情報等が含まれる。
【００５４】
シグナリングデータは、受信装置（クライアント）が受信、再生するＡＶセグメントのアクセス情報や、復号処理等の受信後の処理に必要となる案内情報や制御情報も含み、送信装置から随時繰り返し送信されるデータである。
【００５５】
なお、シグナリングデータには、例えば提供情報に応じた様々な種類がある。具体的には、例えば、サービス単位のシグナリングデータであるＵＳＤ（ユーザサービスディスクリプション（Ｕｓｅｒ  Ｓｅｒｖｉｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ））がある。
ＵＳＤには、様々な種類の制御情報が含まれる。代表的な制御情報として、コンテンツ（ＡＶセグメント）に対応する様々な案内情報、制御情報を格納したマニフェスト・ファイルを持つシグナリングデータであるＭＰＤ（メディアプレゼンテーションディスクリプション（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ））がある。
【００５６】
各種のシグナリングデータは、それぞれ受信装置（クライアント）において、送信装置から送信されるＡＶセグメントやアプリケーション（アプリケーションプログラム）の受信、再生処理、制御処理に必要となるデータであり、例えばカテゴリ別に個別のファイル（メタファィル）として設定され、送信装置から送信される。
【００５７】
なお、（１）ブロードキャスト物理レイヤ（Ｂｒｏａｄｃａｓｔ  ＰＨＹ）の上位レイヤとして将来の新たなプロトコルの利用許容レイヤ（Ｆｕｔｕｒｅ  Ｅｘｔｅｎｓｉｂｉｌｉｔｙ）が設定されている。
【００５８】
（１）ブロードキャスト物理レイヤ（Ｂｒｏａｄｃａｓｔ  ＰＨＹ）は、ブロードキャスト通信を実行するための例えば放送系の通信部を制御する通信制御部によって構成される物理レイヤである。
（２）ＩＰマルチキャストレイヤ（ＩＰ  Ｍｕｌｔｉｃａｓｔ）は、ＩＰマルチキャストに従ったデータ送受信処理を実行するレイヤである。
（３）ＵＤＰレイヤは、ＵＤＰパケットの生成、解析処理レイヤである。
【００５９】
（４）ＲＯＵＴＥレイヤは、拡張型ＦＬＵＴＥプロトコルであるＲＯＵＴＥプロトコルにしたがって転送データの格納や取り出しを行うレイヤである。
ＲＯＵＴＥは、ＦＬＵＴＥと同様、ＡＬＣと呼ばれるスケーラブルなファイルオブジェクトのマルチキャストプロトコルであり、具体的にはそのビルディングブロックであるＬＣＴやＦＥＣコンポーネントの組み合わせにより構成される。
図４に、ＲＯＵＴＥ、およびＦＬＵＴＥに関するプロトコルスタックを示す。
【００６０】
（５）ＥＳＧ，ＮＲＴｃｏｎｔｅｎｔ，ＤＡＳＨ（ＩＳＯ  ＢＭＦＦ）およびＶｉｄｅｏ／Ａｕｄｉｏ／ＣＣは、ＲＯＵＴＥプロトコルに従って転送されるデータである。
【００６１】
ＤＡＳＨ規格に従った同報型配信サービスは、ＭＢＭＳ（Ｍｕｌｔｉｍｅｄｉａ  Ｂｒｏａｄｃａｓｔ  Ｍｕｌｔｉｃａｓｔ  Ｓｅｒｖｉｃｅ）と呼ばれる。このＭＢＭＳをＬＴＥで効率的に実現させる方式としてｅＭＢＭＳ（ｅｖｏｌｖｅｄ  Ｍｕｌｔｉｍｅｄｉａ  Ｂｒｏａｄｃａｓｔ  Ｍｕｌｔｉｃａｓｔ  Ｓｅｒｖｉｃｅ）がある。
ＭＢＭＳやｅＭＢＭＳは、同報型配信サービスであり、特定のエリア内に位置する受信装置である複数のユーザ端末（ＵＥ）に対して共通のベアラで一斉に同一データ、例えば映画コンテンツなどを配信するサービスである。ＭＢＭＳやｅＭＢＭＳに従った同報配信により、配信サービス提供エリアに位置する多数のスマホやＰＣ、あるいはテレビ等の受信装置に、同じコンテンツを同時に提供することができる。
【００６２】
ＭＢＭＳ、およびｅＭＢＭＳは、３ＧＰＰファイルフォーマット（ＩＳＯ−ＢＭＦＦファイル、ＭＰ４ファイル）に従ったファイルを、転送プロトコルＲＯＵＴＥ、またはＦＬＵＴＥに従ってダウンロードする処理について規定している。
【００６３】
先に図２を参照して説明した以下のデータ、すなわち、
（ａ）シグナリングデータ５０
（ｂ）ＡＶセグメント６０
（ｃ）その他のデータ（ＥＳＧ、ＮＲＴコンテンツ等）７０
これらのデータの多くはＲＯＵＴＥプロトコル、またはＦＬＵＴＥプロトコルに従って送信される。
【００６４】
（５）ＥＳＧ，ＮＲＴｃｏｎｔｅｎｔ，ＤＡＳＨ（ＩＳＯ  ＢＭＦＦ）およびＶｉｄｅｏ／Ａｕｄｉｏ／ＣＣは、ＲＯＵＴＥプロトコルに従って転送されるデータである。
【００６５】
ＥＳＧは、電子サービスガイド（Ｅｌｅｃｔｒｏｎｉｃ  Ｓｅｒｖｉｃｅ  Ｇｕｉｄｅ）であり、例えば番組表等の案内情報である。
【００６６】
ＮＲＴｃｏｎｔｅｎｔはノンリアルタイム型のコンテンツである。
前述したように、ＮＲＴコンテンツには、例えば、クライアントである受信装置のブラウザ上で実行される様々なアプリケーションファイル、動画、静止画等のデータファイル等が含まれる。
Ｖｉｄｅｏ／Ａｕｄｉｏ／ＣＣは、ＤＡＳＨ規格に従って配信されるビデオやオーディオ等、再生対象となる実データである。
【００６７】
（６）アプリケーションレイヤ（Ａｐｐｌｉｃａｔｉｏｎｓ（ＨＴＭＬ５））は、ＲＯＵＴＥプロトコルに従って転送するデータの生成、あるいは解析、その他、様々なデータの出力制御等を実行するアプリケーションレイヤであり、例えばＨＴＭＬ５を適用したデータ生成、解析、出力処理等を行う。
【００６８】
一方、図３の右側に示す、（ｂ）ユニキャスト（ブロードバンド）通信（例えばＨＴＴＰ型のＰ２Ｐ通信）に対応するプロトコルスタックは、下位レイヤから順に、以下のレイヤを持つ。
（１）ブロードバンド物理レイヤ（Ｂｒｏａｂａｎｄ  ＰＨＹ）
（２）ＩＰユニキャストレイヤ（ＩＰ  Ｕｎｉｃａｓｔ）
（３）ＴＣＰレイヤ
（４）ＨＴＴＰレイヤ
（５）ＥＳＧ，Ｓｉｇｎａｌｉｎｇ，ＮＲＴｃｏｎｔｅｎｔ，ＤＡＳＨ（ＩＳＯ  ＢＭＦＦ）およびＶｉｄｅｏ／Ａｕｄｉｏ／ＣＣ
（６）アプリケーションレイヤ（Ａｐｐｌｉｃａｔｉｏｎｓ（ＨＴＭＬ５））
【００６９】
（１）ブロードバンド物理レイヤ（Ｂｒｏａｂａｎｄ  ＰＨＹ）は、ブロードバンド通信を実行する例えばネットワークカード等の通信部を制御するデバイスドライバ等の通信制御部によって構成される物理レイヤである。
（２）ＩＰユニキャストレイヤ（ＩＰ  Ｕｎｉｃａｓｔ）は、ＩＰユニキャスト送受信処理を実行するレイヤである。
（３）ＨＴＴＰレイヤは、ＨＴＴＰパケットの生成、解析処理レイヤである。
この上位レイヤは、図３左側の（ａ）ブロードキャスト通信（例えば放送型データ配信）のスタック構成と同様である。
【００７０】
なお、送信装置（サーバ）２０、チューナ実装受信装置（クライアント）３０は、図３の２つの処理系、すなわち、
（ａ）ブロードキャスト通信（例えば放送型データ配信）
（ｂ）ユニキャスト（ブロードバンド）通信（例えばＨＴＴＰ型のＰ２Ｐ通信）
これら２つの通信プロトコルスタックの少なくともいずれかに従った処理を行なう。
【００７１】
また、チューナ非実装受信装置（クライアント）４０は、チューナ実装受信装置（クライアント）３０との通信処理として、図３の右側の処理系、すなわち、
（ｂ）ユニキャスト（ブロードバンド）通信（例えばＨＴＴＰ型のＰ２Ｐ通信）
この通信プロトコルスタックに従った通信処理を実行する。
【００７２】
図３に示すプロトコルスタックにおいて、ＲＯＵＴＥ（ＦＬＵＴＥ）に従ってマルチキャスト転送されるファイル群の属性（ファイルの識別子であるＵＲＬを含む）は、ＲＯＵＴＥ（ＦＬＵＴＥ）の制御ファイル内に記述することもできれば、ファイル転送セッションを記述するシグナリング（Ｓｉｇｎａｌｉｎｇ）データ中に記述することもできる。また、ファイル転送セッションのさらなる詳細属性を（エンドユーザへの提示用途にも適用可能な）ＥＳＧにより記述することもできる。
【００７３】
前述したように、放送波およびネットワークを介したデータ配信システムに関する規格の１つとしてＡＴＳＣ（Ａｄｖａｎｃｅｄ  Ｔｅｌｅｖｉｓｉｏｎ  Ｓｙｓｔｅｍ  Ｃｏｍｍｉｔｔｅ）３．０の規格化が進められている。
ＡＴＳＣ３．０におけるＩＰベースのトランスポートスタックの標準化において、ＭＰＥＧ−ＤＡＳＨのファイルフォーマット（ＩＳＯ−ＢＭＦＦファイル、ＭＰ４ファイル）に基づくファイルをＦＬＵＴＥ（Ｆｉｌｅ  Ｄｅｌｉｖｅｒｙ  ｏｖｅｒ  Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ  Ｔｒａｎｓｐｏｒｔ）を拡張したＲＯＵＴＥ（Ｒｅａｌ−Ｔｉｍｅ  Ｏｂｊｅｃｔ  Ｄｅｌｉｖｅｒｙ  ｏｖｅｒ  Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ  Ｔｒａｎｓｐｏｒｔ）プロトコルにより転送する方法が提案され、標準候補方式として設定された。
【００７４】
ＲＯＵＴＥプロトコルを適用することで、ＤＡＳＨ規格のフラグメント化されたＭＰ４（ｆｒａｇｍｅｎｔｅｄ  ＭＰ４）ファイルシーケンスと、ＤＡＳＨ規格の制御情報（シグナリングデータ）格納メタファイルであるＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ））、ならびに、放送配信のためのシグナリングデータであるＵＳＢＤ／ＵＳＤ、Ｓ−ＴＳＩＤ（Ｓｅｒｖｉｃｅ  ｂａｓｅｄ  Ｔｒａｎｓｐｏｒｔ  Ｓｅｓｓｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）等を転送することができる。
【００７５】
［４．緊急情報の送信と出力処理の概要について］
図１を参照して説明した通信システムにおいて、送信装置２０から緊急情報が送信され、チューナ実装受信装置３０が受信した場合、この緊急情報は、チューナ実装受信装置３０やチューナ非実装受信装置４０の表示部に、いち早く出力し、遅滞なくユーザが確認可能な状態にすることが必要となる。
【００７６】
なお、前述したように、例えば、米国では、ＥＡＳ（Ｅｍｅｒｇｅｎｃｙ  Ａｌｅｒｔ  Ｓｙｓｔｅｍ）と呼ばれる緊急情報通知システムが整備されており、このＥＡＳを利用して、様々な緊急情報、例えば気象災害情報や、テロ情報、その他の緊急避難情報などをいち早く通知することを可能としている。ＥＡＳを利用して通知される緊急情報には、例えば大統領からのメッセージ等、国家レベルの通知事項や、州、あるいは地方政府レベルのローカルな通知事項など、様々な異なるレベルの緊急情報がある。
【００７７】
米国における放送波およびネットワークを介したデータ配信システムに関する規格であるＡＴＳＣ（Ａｄｖａｎｃｅｄ  Ｔｅｌｅｖｉｓｉｏｎ  Ｓｙｓｔｅｍｓ  Ｃｏｍｍｉｔｔｅｅ）３．０では、次世代の緊急情報通知システムである統合公衆警報システム（ＩＰＡＷＳ：Ｉｎｔｅｇｒａｔｅｄ  Ｐｕｂｌｉｃ  Ａｌｅｒｔ  ａｎｄ  Ｗａｒｎｉｎｇ  Ｓｙｓｔｅｍ）の使用を前提としている。
【００７８】
放送局等の送信装置は、統合公衆警報システム（ＩＰＡＷＳ）に従って、緊急情報伝送のための規格として規定されているＡＥＡＴ（Ａｄｖａｎｃｅｄ  Ｅｍｅｒｇｅｎｃｙ  Ａｌｅｒｔｉｎｇ  Ｔａｂｌｅ）や、ＣＡＰ（Ｃｏｍｍｏｎ  Ａｌｅｒｔｉｎｇ  Ｐｒｏｔｏｃｏｌ）フォーマットに従って、緊急情報を構成するメッセージや避難経路情報等のデータを受信装置に送信する。
【００７９】
例えば、ＡＥＡＴやＣＡＰメッセージには緊急情報の様々な属性情報、例えば、緊急情報のカテゴリ、緊急情報の緊急度や発信元情報、緊急情報の通知が必要な地域情報等、様々な緊急情報名に関する詳細な情報が付与されている。
このＡＥＡＴやＣＡＰメッセージを受信した受信装置は、受信メッセージを解析して、例えば緊急情報のカテゴリや緊急度、あるいは、受信装置の現在位置等に応じて必要な情報を選択して出力（表示）する。
【００８０】
図１に示す通信システム構成において、例えば、チューナ実装受信装置３０は、受信データの解析を行うミドルウェアを有し、ミドルウェアが、地震発生やテロ発生等の緊急情報を受信した場合、緊急情報の受信を検知したタイミングでできるだけ早く、ミドルウェアを介して放送サービスを再生しているクライアント（ユーザ装置）に通知することが必要となる。
チューナ実装受信装置３０は、ＡＴＳＣ３．０放送サービスの制御情報を含むシグナリングデータの解析等を実行するミドルウェア（ＡＴＳＣ３．０放送受信ミドルウェア）を有するが、チューナ非実装受信装置４０は、このようなミドルウェアを有していない。
【００８１】
従って、チューナ実装受信装置３０は、ミドルウェアが検出した地震発生やテロ発生等の緊急情報をできるだけ早く、ミドルウェアを介して放送サービスを再生している様々なクライアント（ユーザ装置）に通知することが必要となる。
ミドルウェアは、例えば、ネットワーク接続されたリモートのクライアント（ＰＣ、ＴＶ、タブレット、スマホ等）の再生制御部やアプリケーション制御部上で稼働するアプリケーション（例えばＡＴＳＣ３．０  ＤＡＳＨクライアントアプリケーション）に緊急メッセージが受信されたことを通知しなければない。
【００８２】
なぜなら、例えばスマホ等のクライアントに表示中の放送番組の番組画像上に緊急メッセージが重畳表示（オーバレイ）されているにもかかわらず、クライアントで実行中の他の放送アプリケーションや、クライアント自身が実行するアプリケーションによって番組画像上にアプリケーション提示物が重畳（オーバレイ）表示されている場合には、アプリ提示物を排除しないと、ユーザは、緊急メッセージを見ることができず、ユーザを危険な状況に導いてしまう恐れがあるためである。
【００８３】
送信装置２０から受信装置３０に対する緊急情報の送信処理と受信装置３０における緊急情報の表示処理例について、図５以下を参照して説明する。
図５は、放送局等の送信装置が配信する番組コンテンツの画像上に緊急情報を重畳した画像データを配信する構成である。
（ａ）通常番組表示として例えば野球中継の番組コンテンツが配信されている際に、緊急情報が発生すると、放送局側で緊急情報を野球中継画像上に重畳した番組コンテンツを生成して受信装置に配信する。
このように、再生コンテンツに緊急情報を直接重畳して配信する緊急情報配信方式は、オンスクリーンメッセージ（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ）型緊急情報配信方式と呼ばれる。
【００８４】
図６は、オンスクリーンメッセージ（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ）型緊急情報配信方式の送信処理例を説明する図である。
放送局等の送信装置２０は、例えば番組配信路を介した複数のチャンネル（ＣＨ１．１，ＣＨ１．２）対応の番組コンテンツの配信と、シグナリング伝送路を介したシグナリングデータの配信を行う
【００８５】
図５を参照して説明した番組は、チャンネル（ＣＨ１．１）の番組であり、時間ｔ０〜ｔ１ではニュースを放映し、時間ｔ１から野球中継が開始される。
その後、放送局である送信装置２０は、時間ｔ２おいて緊急情報を野球中継画像上に重畳した番組コンテンツを生成して受信装置３０に配信する。
受信装置３０側で野球中継を見ているユーザ（視聴者）は、野球中継画面に重畳された緊急情報を確認することができる。
【００８６】
しかし、例えば、前述したように、受信装置３０において実行中の他の放送アプリケーションや、クライアント自身が実行するアプリケーションによって番組画像上にアプリケーション提示物が重畳（オーバレイ）表示されている場合、アプリ提示物の表示を停止する等の処理を実行しないと、ユーザは、緊急メッセージを見ることができない。
具体例を図７に示す。
図７（２ｂ）に示す例は、ユーザ（視聴者）が野球中継を見ている間に、天気予報表示アプリケーションを実行し、天気予報情報の表示を実行している例である。
この天気予報表示アプリケーションは、例えば、放送局が野球中継放送コンテンツに併せて、別途、配信したアプリケーション、あるいは、クライアント（テレビ）側が事前にＮＲＴコンテンツとして取得したアプリケーション等である。
【００８７】
この図７（２ｂ）に示すように、受信装置３０でアプリケーションを実行し、番組コンテンツの表示画面上にアプリケーション提示コンテンツが表示されると、アプリケーション提示コンテンツによって隠された部分の番組コンテンツは確認することができなくなる。
図７（２ｃ）に示すように、番組コンテンツ上に緊急情報が重畳表示されている場合には、緊急情報がアプリケーション提示コンテンツによって隠れてしまい、ユーザ（視聴者）が確認できないという事態が発生する。
【００８８】
なお、緊急情報の配信方式には、このようなオンスクリーンメッセージ（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ）型緊急情報配信方式以外に、シグナリングデータ利用した緊急情報配信方式がある。
図８は、シグナリングデータ適用型緊急情報配信方式を示している。
例えば放送局等の送信装置２０は、通常の番組配信経路とは異なる通信経路であるシグナリングデータ（ＬＬＳ：：Ｌｏｗｅｒ  Ｌａｙｅｒ  Ｓｉｇｎａｌｉｎｇ）専用の通信経路を利用して緊急情報を送信することが可能である。
先に説明したＡＥＡＴ（Ａｄｖａｎｃｅｄ  Ｅｍｅｒｇｅｎｃｙ  Ａｌｅｒｔｉｎｇ  Ｔａｂｌｅ）や、ＣＡＰ（Ｃｏｍｍｏｎ  Ａｌｅｒｔｉｎｇ  Ｐｒｏｔｏｃｏｌ）フォーマットに従った緊急情報は、このシグナリングデータ適用型緊急情報配信方式に従って送信される。
【００８９】
番組は、チャンネル（ＣＨ１．１）の番組であり、時間ｔ０〜ｔ１ではニュースを放映し、時間ｔ１から野球中継が開始される。
その後、放送局である送信装置２０は、時間ｔ２おいて緊急情報を格納したシグナリングデータ（ＬＬＳ）を生成して受信装置３０に配信する。
受信装置３０は、このシグナリングデータを受信し、野球中継の表示画面上にシグナリングデータから取得した緊急情報を表示する。
【００９０】
例えばＡＥＡＴやＣＡＰには、受信装置の位置情報に対応したデータ、例えば避難経路情報を提供するための制御情報が含まれており、これらを利用することで、各受信装置の位置に応じた避難経路の地図を表示する処理などが可能となる。
【００９１】
図９に地図情報の表示例を示す。
図９（３ｃ）に示す地図データも、シグナリングデータによる送信データである。
例えば、前述したＡＥＡＴや、ＣＡＰ等のシグナリングデータには、緊急情報の様々な属性情報、例えば、緊急情報のカテゴリ、緊急情報の緊急度や発信元情報、緊急情報の通知が必要な地域情報等、様々な緊急情報名に関する詳細な情報が記録可能であり、受信装置は、受信したシグナリングデータを解析して、例えば緊急情報のカテゴリや緊急度、あるいは、受信装置の現在位置等に応じて必要な情報を選択して出力（表示）することができる。
これらの情報帆を適用して、図９（３ｃ）に示すように、受信装置の位置に応じた地図を表示することができる。
【００９２】
図５〜図９を参照して説明したように、緊急情報配信方式には、以下の２つの種類がある。
（ａ）オンスクリーンメッセージ（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ）型緊急情報配信方式、
（ｂ）シグナリングデータ適用型緊急情報配信方式、
【００９３】
しかし、オンスクリーンメッセージ（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ）型緊急情報配信方式の場合、例えば受信装置側で、アプリケーションを実行してアプリケーション提示コンテンツが表示されていると、ユーザ（視聴者）は緊急情報を確認することができない。
また、図８、図９を参照して説明したシグナリングデータ適用方式の場合、受信装置３０は、このシグナリングデータの送信装置２０による送信処理後、即座に受信して表示処理を行なわなければ、ユーザ（視聴者）による緊急情報の確認処理が遅れ、ユーザの安全が確保できなくなる恐れがある。
本開示は、このような問題の発生を防止し、緊急情報を確実にかつ即座（タイムリ）にユーザ（視聴者）に確認させることを可能とした構成を実現するものである。
【００９４】
［５．受信装置の構成例と処理例について］
次に、図１０以下を参照して、図１を参照して説明したチューナ実装受信装置（クライアントＡ）３０と、チューナ非実装受信装置（クライアントＢ）４０の構成例と処理例について説明する。
放送サーバ２１は、放送波や、ネットワークを介したブロードキャスト送信により、放送コンテンツ等からなるＡＶセグメント、シグナリングデータ、その他のデータを送信する。
図には示していないが、放送サーバ２１以外の送信装置であるデータ配信サーバ２２もネットワークを介したブロードキャスト送信により、放送コンテンツ等からなるＡＶセグメント、シグナリングデータ、その他のデータを送信する。
【００９５】
図１０に示すように、チューナ実装受信装置３０はミドルウェア１１０、ＨＴＴＰプロキシサーバ１２０、再生制御部（ＤＡＳＨクライアント）１３１、出力制御部１３２、アプリケーション制御部１４０を有する。
【００９６】
ミドルウェア１１０は、放送サーバ２１の提供データを受信し、解析する。
ミドルウェア１１０は、以下の構成要素を有する。
通信部（ＰＨＹ／ＭＡＣ）１１１、
ＬＬＳシグナリング取得部１１２、
ＬＬＳシグナリング解析部１１３、
ＳＬＳシグナリング取得部１１４、
ＳＬＳシグナリング解析部（ＭＰＤイベント挿入部）１１５、
セグメント取得部１１７、
インバンドイベント挿入部１１８。
【００９７】
通信部（ＰＨＹ／ＭＡＣ）１１１は、放送波を介した放送サーバ２１の提供データを受信する。
ＬＬＳシグナリング取得部１１２と、ＬＬＳシグナリング解析部１１３は、通信部１１１を介して受信するローワレイヤ・シグナリングデータ（ＬＬＳ：Ｌｏｗｅｒ  Ｌａｙｅｒ  Ｓｉｇｎａｌｉｎｇ）を受信し、解析する。
ＳＬＳシグナリング取得部１１４と、ＳＬＳシグナリング解析部１１５は、通信部１１１を介して受信するサービスレベル・シグナリングデータ（ＳＬＳ：Ｓｅｒｖｉｃｅ  Ｌｅｖｅｌ  Ｓｉｇｎａｌｉｎｇ）を受信し、解析する。
セグメント取得部１１７は、映像、音声等の番組コンテンツデータや、アプリケーション等のＮＲＴコンテンツ、さらにシグナリングデータ等のデータを格納したセグメントを取得する。
【００９８】
さらに、ＳＬＳシグナリング解析部１１５は、ＭＰＤイベント挿入部としても機能する。
ＳＬＳシグナリング解析部１１５は、放送番組や送信データの変更や詳細等の通知情報、受信装置において実行するアプリケーションに関する情報、さらに緊急情報関連の情報等、受信装置において必要となる処理の情報などを含むイベント情報をシグナリングデータであるＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）内に挿入する処理を実行するＭＰＤイベント挿入部として機能する。
インバンド（Ｉｎ−ｂａｎｄ）イベント挿入部１１８は、緊急情報等のイベント情報をセグメント内に挿入する処理を実行する。
【００９９】
イベント情報は、例えば、番組表の変更や、放送コンテンツのデータ態様の変更、受信装置における放送コンテンツの再生時に実行すベき処理など、受信装置に対して通知すべき情報、何らかの処理の実行を要求するための情報などである。
【０１００】
本実施例では、このイベント情報として、新たに緊急情報や、緊急情報関連情報に関するイベント情報を設定し、このイベント情報を適用したイベント通知を行い、受信装置における緊急情報の迅速かつ確実な表示を実現するためのデータ処理を行わせる構成としたものである。
具体的には、例えば、先に図７を参照して説明したようなアプリケーション提示コンテンツが表示されている場合、この提示コンテンツの排除処理要求を格納したイベント情報を送信してイベント通知を行う。
また、シグナリングデータとして送信される緊急メッセージの発行状況やアクセス情報を通知する緊急情報関連情報を格納したイベント情報をクライアントに提供して、迅速な緊急情報の取得、表示を可能とする。
これらの具体的な処理については後段で詳細に説明する。
【０１０１】
ミドルウェア１１０が受信したデータは、プロキシサーバ１２０のキャッシュ部（プロキシキャッシュ）１２１に格納される。プロキシサーバ１２０は、さらにネットワーク経由でデータ配信サーバ２２から取得したデータをキャッシュ部（プロキシキャッシュ）１２２に格納する。
【０１０２】
プロキシサーバ１２０は、例えば再生制御部（ＤＡＳＨクライアント）１３１，１５１、アプリケーション制御部１３３，１５３、緊急情報制御部１４０，１６０等からのデータ要求をアドレス解決部１２３に入力し、要求されたデータをキャッシュ部（プロキシキャッシュ）１２１，１２２、または外部から取得して提供する。
【０１０３】
再生制御部（ＤＡＳＨクライアント）１３１は、ＤＡＳＨ（ＭＰＥＧ−ＤＡＳＨ）規格に従って送信されたコンテンツの再生制御を実行する。
前述したように、ＭＰＥＧ−ＤＡＳＨ規格には、以下の２つの規格が含まれる。
（ａ）動画や音声ファイルの管理情報であるメタデータを記述するためのマニフェスト・ファイル（ＭＰＤ：Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）に関する規格、
（ｂ）動画コンテンツ伝送用のファイル・フォーマット（セグメント・フォーマット）に関する規格、
送信装置２０から、チューナ実装受信装置３０に対するコンテンツ配信は、上記のＭＰＥＧ−ＤＡＳＨ規格に従って実行される。
【０１０４】
コンテンツは、例えばＭＰＥＧにおいて規定されるＭＰ４ファイルフォーマットに従って所定単位の分割データであるセグメントとして送信され、再生制御部（ＤＡＳＨクライアント）１３１は、マニフェスト・ファイル（ＭＰＤ）を参照して、再生対象コンテンツを格納したセグメントを取得する処理等を実行する。
【０１０５】
再生制御部（ＤＡＳＨクライアント）１３１は、さらに、イベント抽出部を有し、例えばＭＰＤやセグメントに格納されたイベントを抽出して、アプリケーション制御部１３３や、緊急情報制御部１４０に通知する。
通知するイベント情報には、例えば送信装置からの緊急情報の送信に伴って、受信装置側において実行すべき処理の要求や処理を可能とするための情報を含むイベント情報が含まれる。
これらのイベント情報を適用した処理の具体例については後段で詳細に説明する。
【０１０６】
出力制御部１３２は、再生制御部の取得したセグメントから符号化コンテンツを取り出して復号し、表示部等の出力部に出力する。
【０１０７】
アプリケーション制御部１３３は、例えば前述した天気予報等のアプリケーションの他、ニュース、野球中継時の選手情報、旅番組における地図情報、ホテル情報、クイズ、アンケート処理等を実行する様々なアプリケーションの取得や、アプリケーションの開始、終了等のアプリケーション制御を実行する。
さらに、アプリケーション制御部１３３は、再生制御部１３１のイベント抽出部の抽出したイベント情報に従って、例えば、図７を参照して説明したアプリケーション提示コンテンツの表示処理や除去処理等を実行する。
緊急情報制御部１４０も、再生制御部１３１のイベント抽出部の抽出したイベント情報に従って、例えば、図８を参照して説明したシグナリングデータ適用型の緊急情報の取得処理等を実行する。
これら、イベント情報を適用した処理の詳細については後段で説明する。
【０１０８】
さらに、図１０に示すチューナ非実装受信装置（クライアントＢ）４０は、例えばイーサネット（登録商標）やＷｉ−Ｆｉ等のネットワークによって、チューナ実装受信装置（クライアントＡ）３０と接続され、チューナ実装受信装置（クライアントＡ）３０との通信を実行する。
チューナ非実装受信装置（クライアントＢ）４０は、チューナ実装受信装置（クライアントＡ）３０が、放送サーバ２１や、データ配信サーバ２２から受信したコンテンツ等のデータを、チューナ実装受信装置（クライアントＡ）３０を介して受信し、コンテンツ再生を実行する。
【０１０９】
図１０に示すチューナ非実装受信装置（クライアントＢ）４０は、
再生制御部（ＤＡＳＨクライアント）１５１、
出力制御部１５２、
アプリケーション制御部１５３、
緊急情報制御部１６０、
これらの構成を有する。
これらの構成、機能は、チューナ実装受信装置（クライアントＡ）３０において説明した再生制御部（ＤＡＳＨクライアント）１３１、出力制御部１３２、アプリケーション制御部１３３、緊急情報制御部１４０と同様である。
【０１１０】
図１１は、チューナ実装受信装置（クライアントＡ）３０の有する、
再生制御部（ＤＡＳＨクライアント）１３１、
出力制御部１３２と、
アプリケーション制御部１３３、
緊急情報制御部１４０、
チューナ非実装受信装置（クライアントＢ）４０の有する、
再生制御部（ＤＡＳＨクライアント）１５１、
出力制御部１５２、
アプリケーション制御部１５３、
緊急情報制御部１６０、
これらの詳細構成を示す図である。
【０１１１】
チューナ実装受信装置（クライアントＡ）３０の再生制御部（ＤＡＳＨクライアント）１３１は、ＭＰＤ取得部２０１、ＭＰＤ解析部２０２、セグメント取得部２０３、セグメント（ＭＰ４）解析部２０４、さらにイベント抽出部２０５を有する。
【０１１２】
再生制御部（ＤＡＳＨクライアント）１３１は、前述したように、ＤＡＳＨ（ＭＰＥＧ−ＤＡＳＨ）規格に従って送信されたコンテンツの再生制御を実行する。
ＭＰＤ取得部２０１は、動画や音声ファイルの管理情報記述ファイルであるマニフェスト・ファイル（ＭＰＤ：Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）を取得する。
ＭＰＤは、放送サーバ２１、データ配信サーバ２２から提供され、プロキシサーバ１２０に格納された後、再生制御部１３１が取得する。
【０１１３】
ＭＰＤ解析部２０２は、ＭＰＤ取得部２０１の取得したＭＰＤの記述内容を解析し、再生対象データに対応するセグメントの取得に必要となる情報等をセグメント取得部に提供する。
さらに、ＭＰＤ解析部２０２は、ＭＰＤにイベント情報が含まれている場合、ＭＰＤをイベント抽出部２０５に出力する。
【０１１４】
イベント抽出部２０５は、ＭＰＤに記録されたイベント情報を解析し、イベント情報が、
（ａ）オンスクリーンメッセージ（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ）型の緊急情報が配信されたこと、
（ｂ）シグナリングデータ適用型の緊急情報が配信されたこと、
上記（ａ），（ｂ）のいずれの通知データを含むイベント情報かを判定する。
【０１１５】
イベント抽出部２０５は、イベント情報が、「（ａ）オンスクリーンメッセージ（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ）型の緊急情報が配信されたこと」を示すイベント情報であると判定した場合、このイベント情報をアプリケーション制御部１３３に出力する。
一方、イベント抽出部２０５は、イベント情報が、「（ｂ）シグナリングデータ適用型の緊急情報が配信されたこと」を示すイベント情報であると判定した場合、このイベント情報を緊急情報制御部１４０、またはアプリケーション制御部１３３に出力する。
【０１１６】
アプリケーション制御部１３３は、イベント抽出部２０５から、「（ａ）オンスクリーンメッセージ（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ）型の緊急情報が配信されたこと」を示すイベント情報を入力すると、アプリケーション実行状態を確認し、例えば、図７を参照して説明したアプリケーション提示コンテンツが番組コンテンツ上に提示されている場合、このアプリ提示コンテンツを除去する処理を実行する。
この処理により、オンスクリーンメッセージ（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ）型の緊急情報が配信された場合、緊急情報を確実にユーザに見せることが可能となる。
【０１１７】
一方、緊急情報制御部１４０は、イベント抽出部２０５から、「（ｂ）シグナリングデータ適用型の緊急情報が配信されたこと」を示すイベント情報を入力すると、入力イベント情報に格納された緊急情報、あるいは緊急情報のアクセス情報を用いてシグナリングデータ（ＡＥＡＴ、ＣＡＰ等のシグナリングデータ）を確実に取得し、表示部に対する出力制御を行う。、
この処理により、シグナリングデータ適用型の緊急情報が配信された場合、緊急情報を即座に取得し、確実にユーザに見せることが可能となる。
【０１１８】
なお、アプリケーション制御部１３３が緊急情報制御部１４０としての処理を実行する構成も可能であり、この場合は、イベント抽出部２０５は、「（ｂ）シグナリングデータ適用型の緊急情報が配信されたこと」を示すイベント情報をアプリケーション制御部１３３に出力する。
【０１１９】
セグメント取得部２０３は、ＭＰＤ解析部２０２のＭＰＤ解析結果に従って、再生対象データに対応するセグメントの取得を行う。
セグメントは、ＡＶデータからなるコンテンツ伝送用のファイル・フォーマット（セグメント・フォーマット）に従って設定される所定の単位データである。
【０１２０】
セグメント解析部２０４は、セグメント取得部２０３の取得したセグメントから、符号化画像データ、符号化音声データ等を取得して、出力制御部１３２の復号部（デコーダ）２１１に出力する。
【０１２１】
さらに、セグメント解析部２０４は、セグメントにイベント情報が含まれている場合、セグメントをイベント抽出部２０５に出力する。
【０１２２】
イベント抽出部２０５は、セグメントに格納されたイベント情報を解析し、イベント情報が、
（ａ）オンスクリーンメッセージ（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ）型の緊急情報が配信されたこと、
（ｂ）シグナリングデータ適用型の緊急情報が配信されたこと、
上記（ａ），（ｂ）のいずれの通知データを含むイベント情報かを判定する。
【０１２３】
イベント抽出部２０５は、イベント情報が、「（ａ）オンスクリーンメッセージ（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ）型の緊急情報が配信されたこと」を示すイベント情報であると判定した場合、このイベント情報をアプリケーション制御部１３３に出力する。
一方、イベント抽出部２０５は、イベント情報が、「（ｂ）シグナリングデータ適用型の緊急情報が配信されたこと」を示すイベント情報であると判定した場合、このイベント情報を緊急情報制御部１４０、またはアプリケーション制御部１３３に出力する。
【０１２４】
これらのイベント情報を受領したアプリケーション制御部１３３と、緊急情報制御部１４０の処理は、前述したＭＰＤ格納イベント情報を受領した場合の処理と同様である。
【０１２５】
チューナ実装受信装置（クライアントＡ）３０の出力制御部１３２は、復号部（デコーダ）２１１と、出力部（レンダラ）２１２を有する。
復号部（デコーダ）２１１は、セグメント解析部２０４から提供された符号化画像データ、符号化音声データの復号処理（テーコード）を実行する。
出力部２１２は、復号された画像データ、音声データを出力部（ディスプレイ、スピーカ）に出力する。
【０１２６】
なお、チューナ非実装受信装置（クライアントＢ）４０の再生制御部（ＤＡＳＨクライアント）１５１も、ＭＰＤ取得部２５１、ＭＰＤ解析部２５２、セグメント取得部２５３、セグメント（ＭＰ４）解析部２５４、さらにイベント抽出部２５５を有する。
また、出力制御部１５２は、復号部（デコーダ）２６１と、出力部（レンダラ）２６２を有する。
これらの構成、および実行する処理は、チューナ実装受信装置（クライアントＡ）３０の構成、処理と同様である。
【０１２７】
なお、チューナ非実装受信装置（クライアントＢ）４０の再生制御部（ＤＡＳＨクライアント）１５１には、チューナ実装受信装置（クライアントＡ）３０のプロキシサーバ１２０、ネットワークを介してＭＰＤ、セグメントが入力される。
また、チューナ非実装受信装置（クライアントＢ）４０のアプリケーション制御部１５３には、チューナ実装受信装置（クライアントＡ）３０のプロキシサーバ１２０、ネットワークを介してアプリケーションファイルが入力される。
【０１２８】
チューナ実装受信装置（クライアントＡ）３０、およびチューナ非実装受信装置（クライアントＢ）４０の再生制御部（ＤＡＳＨクライアント）１３１，１５１は、ＡＴＳＣ３．０クライアントアプリケーション（３．０  ＤＡＳＨクライアント）の実行部である。
ＡＴＳＣ３．０クライアントアプリケーションは、ＡＴＳＣ３．０放送受信クライアントデバイス上に実装されたブラウザ上で実行される。あるいは、ブラウザアプリケーションとしてだけではなくネィティブアプリケーションとして実行される場合もある。
【０１２９】
再生制御部（ＤＡＳＨクライアント）１３１，１５１の実行するＡＴＳＣ３．０クライアントアプリケーションは、ＡＴＳＣ３．０  ＤＡＳＨクライアントアプリケーション（３．０  ＤＡＳＨクライアント）や、ＡＴＳＣ３．０ストリーム付随アプリケーション（３．０  Ａｐｐｌｉｃａｔｉｏｎ）等からなる。
さらに、ネィティブアプリケーションとして実装されるものとして、これらのＷｅｂアプリケーションのライフサイクル制御を行うアプリケーションマネジャ（"３．０  Ａｐｐｌｉｃａｔｉｏｎ  Ｍａｎａｇｅｒ"）、ＡＥＡＴメッセージレンダラーアプリケーション（"ＣＡＰ  Ｍｅｓｓａｇｅ  Ｒｅｎｄｅｒｅｒ"）等が含まれる。
【０１３０】
再生制御部（ＤＡＳＨクライアント）１３１，１５１のＡＴＳＣ３．０クライアントアプリケーション、および出力制御部１３２，１５２は、ミドルウェア（Ｃｌｉｅｎｔ  Ｌｏｃａｌ  ＡＴＳＣ  Ｍｉｄｄｌｅｗａｒｅ）１１０が受信したデータ、プロキシサーバ（Ｃｌｉｅｎｔ  Ｌｏｃａｌ  ＨＴＴＰ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ）１２０がネットワークを介して受信したデータの処理を実行する。
【０１３１】
ミドルウェア１１０、またはプロキシサーバ１２０の取得した、ＤＡＳＨ−ＭＰＤファイルやＤＡＳＨセグメント（ｓｅｇｍｅｎｔ）ファイル、その他一般のアプリケーションファイル、ならびに、シグナリングデータを格納したＳＬＳ（Ｓｅｒｖｉｃｅ  ｌｅｖｅｌ  Ｓｉｇｎａｌｉｎｇ）ファイルを入力して、ストリームのレンダリングや、アプリケーションの制御を行う。
【０１３２】
このモデルは、再生制御部（ＤＡＳＨクライアント）１３１，１５１の実行するＡＴＳＣ３．０クライアントアプリケーションや、アプリケーション制御部１６０の実行するアプリケーションからすると、必ずプロキシサーバ１２０を介して外の世界にアクセスするため、それらファイル群を放送経由で取得しているのか、ネット経由で取得しているのかの区別を意識することがない（ネットワーク透過性が提供される）ため、アプリケーションの可搬性を高めることが可能となる。
従って放送向けのみに特化してアプリケーションを実装する必要がなく、放送もインターネットのどちらを使うかによらない実装とすることができる。
【０１３３】
再生制御部（ＤＡＳＨクライアント）１３１，１５１の実行するＡＴＳＣ３．０クライアントアプリケーションがＤＡＳＨ−ＭＰＤファイルやＤＡＳＨセグメント（ｓｅｇｍｅｎｔ）ファイル、その他一般のアプリケーションファイル、ならびに、シグナリングデータファイルの取得を要求（ＨＴＴＰリクエスト）すると、それを受けたプロキシサーバ１２０が、アドレス解決部（Ｂｒｏａｄｃａｓｔ／Ｂｒｏａｄｂａｎｄ  Ａｄｄｒｅｓｓ  Ｒｅｓｏｌｏｖｅｒ）１２３において放送受信スタックを介して取得するか、ネット経由で取得するかの判断を行う。
【０１３４】
判断材料となる情報は、ＳＬＳシグナリング解析部（ＳＬＳ  Ｓｉｇｎａｌｉｎｇ  Ｐａｒｓｅｒ）１１５から提供される。ＳＬＳシグナリング解析部（ＳＬＳ  Ｓｉｇｎａｌｉｎｇ  Ｐａｒｓｅｒ）１１５は、ＳＬＳシグナリング取得部（ＳＬＳ  Ｓｉｇｎａｌｉｎｇ  Ｒｅｔｒｉｅｖｅｒ）１１４に、ＡＴＳＣ３．０のシグナリングメタであるＵＳＢＤ／ＵＳＤやＳ−ＴＳＩＤ等の取得要求を行う。
【０１３５】
ＳＬＳシグナリング取得部（ＳＬＳ  Ｓｉｇｎａｌｉｎｇ  Ｒｅｔｒｉｅｖｅｒ）１１４は、通信部（ＡＴＳＣチューナ：ＡＴＳＣ３．０  ＰＨＹ／ＭＡＣ）１１１を介して放送受信するＳＬＳ  ＬＣＴパケットにより運ばれるシグナリングメタを抽出する。
【０１３６】
ＳＬＳシグナリング解析部（ＳＬＳ  Ｓｉｇｎａｌｉｎｇ  Ｐａｒｓｅｒ）１１４は、また、セグメントやアプリケーションパーツの取得要求に含まれるｕｒｌから、シグナリングメタを抽出して、対象となるファイルを取得するための放送配信アドレス情報を解決する。放送配信される（た）ことがわかれば、その放送配信アドレス情報をもとにして、所望のファイルが格納されたＬＣＴパケットを放送ストリームから取得し、キャッシュ（Ｐｒｏｘｙ  Ｃａｃｈｅ）部１２１，１２２内に展開する。プロキシサーバ１２０は、当該ファイルを再生制御部１３１やアプリケーション制御部１４０に（ＨＴＴＰのレスポンスとして）返す。アプリケーションパーツの取得要求に含まれるｕｒｌがシグナリングメタになければ、プロキシサーバ１２０は、通常のネットスタックを介して当該ファイルを取得する。
【０１３７】
本開示の構成では、ＳＬＳシグナリング解析部（ＳＬＳ  Ｓｉｇｎａｌｉｎｇ  Ｐａｒｓｅｒ）１１４は、ＭＰＤイベント挿入部（ＭＰＤ  Ｅｖｅｎｔ  Ｉｎｓｅｒｔｅｒ）としての機能も有する。
ＭＰＤイベントとは、ＤＡＳＨイベントのうちの１つである。
ＤＡＳＨイベントは、ＤＡＳＨのＭＰＤ、もしくは、ＤＡＳＨセグメントにより、ストリーミングのプロトコルの中で、あらかじめスケジュールされた、もしくは、スケジュールの決まっていない（イベントのアクティベート（活性化）時刻が未定な）イベントを転送・制御する機構である。
【０１３８】
なお、ＤＡＳＨイベントの転送方式には、以下の２つの種類がある。
（ａ）イベント情報をシグナリングデータであるＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）内に挿入して転送するＭＰＤ適用イベント通知方式、
（ｂ）イベント情報をセグメント内に挿入して転送するセグメント適用（Ｉｎ−ｂａｎｄ）イベント通知方式、
これらの２種類がある。
【０１３９】
イベント情報をシグナリングデータであるＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）内に挿入して転送するのが、ＳＬＳシグナリング解析部１１５内のＭＰＤイベント挿入部であり、イベント情報をセグメント内に挿入して転送するのが、インバンド（Ｉｎ−ｂａｎｄ）イベント挿入部１１８である。
【０１４０】
例えば、放送サーバ２１の送信するシグナリングデータ（ＬＬＳ：Ｌｏｗｅｒ  Ｌａｙｅｒ  Ｓｉｇｎａｌｉｎｇ）を利用して以下の通知情報が受信装置に送信される、
（ａ）オンスクリーンメッセージ（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ）型緊急情報が配信されたこと（オンスクリーンメッセージ通知：Ｏｎ  Ｓｃｒｅｅｎ  Ｍｅｓｓａｇｅ  Ｎｏｔｉｆｉｃａｔｉｏｎ）、
（ｂ）シグナリングデータ適用型緊急情報（ＡＥＡＴ、ＣＡＰ等）が配信されたことの通知：（ＡＥＡＴ  Ｍｅｓｓａｇｅ  Ｎｏｔｉｆｉｃａｔｉｏｎ）、
【０１４１】
なお、以下に説明する実施例において、シグナリングデータ適用型緊急情報として、ＡＥＡＴを代表例として説明する。
ただし、本開示の処理は、ＡＥＡＴに限らず、ＡＥＡＴ以外のデータフォーマットを持つ様々なシグナリングデータ適用型緊急情報に対しても、同様の処理が可能である。
なお、ＡＥＡＴのデータフォーマットについては後段で説明する。
【０１４２】
チューナ実装受信装置３０のミドルウェア１１０のＬＬＳシグナリング取得部１１２、ＬＬＳシグナリング解析部１１３は、放送サーバ２１等の送信装置から送信されるシグナリングデータ（ＬＬＳ）から、これらの緊急情報に関する通知を抽出し、
抽出された通知データを、ＳＬＳシグナリング解析部１１５内のＭＰＤイベント挿入部に入力する。
ＳＬＳシグナリング解析部１１５内のＭＰＤイベント挿入部は、これらの通知データを、ＭＰＤに挿入し、インバンドイベント挿入部１１８は、これらの通知をセグメント内に挿入する。
これらのイベント情報が挿入されたＭＰＤやセグメントは、キャッシュ部１２１を介して、例えば再生制御部（ＤＡＳＨクライアント）１３１，１５１に入力される。
【０１４３】
［６．シグナリングデータを適用した緊急情報配信通知処理について］
上述したように、放送サーバ２１等の送信装置２０は、シグナリングデータ（ＬＬＳ：Ｌｏｗｅｒ  Ｌａｙｅｒ  Ｓｉｇｎａｌｉｎｇ）を利用して以下の通知情報を受信装置に送信する。
（ａ）オンスクリーンメッセージ型緊急情報配信通知（Ｏｎ  Ｓｃｒｅｅｎ  Ｍｅｓｓａｇｅ  Ｎｏｔｉｆｉｃａｔｉｏｎ）、
（ｂ）シグナリングデータ適用型緊急情報配信通知（ＡＥＡＴ  Ｍｅｓｓａｇｅ  Ｎｏｔｉｆｉｃａｔｉｏｎ）、
以下、このシグナリング（ＬＬＳ）を利用した緊急情報配信通知処理構成について説明する。
【０１４４】
先に図３を参照して説明したように、シグナリングデータには、以下の２つの異なるレイヤを利用した異なるタイプのシグナリングデータがある。
ＬＬＳ（ローワレイヤシグナリング）
ＳＬＳ（サービスレベルシグナリング）
ＳＬＳ（サービスレベルシグナリング）は、各サービス単位、例えば各番組単位の制御情報、案内情報、メタデータ等を格納したシグナリングデータである。
ＬＬＳ（ローワレイヤシグナリング）は、ＳＬＳより上位の制御情報、案内情報、メタデータ等を格納したシグナリングデータであり、例えば、ＳＬＳを取得するための情報等が含まれる。
【０１４５】
ＬＬＳ（ローワレイヤシグナリング）や、ＳＬＳ（サービスレベルシグナリング）等のシグナリングデータの取得、解析処理を実行するのは、図１０に示すチューナ実装受信装置３０のミドルウェア１１０である。
図１０に示すミドルウェア１１０のＬＬＳシグナリング取得部１１２と、ＬＬＳシグナリング解析部１１３が、ＬＬＳ（ローワレイヤシグナリング）の取得、解析処理を実行する。
【０１４６】
また、図１０に示すミドルウェア１１０のＳＬＳシグナリング取得部１１４と、ＳＬＳシグナリング解析部（ＭＰＤイベント挿入部）１１５が、ＳＬＳ（サービスレベルシグナリング）の取得、解析処理を実行する。
【０１４７】
図１０に示すミドルウェア１１０のＬＬＳシグナリング取得部１１２、ＬＬＳシグナリング解析部１１３、ＳＬＳシグナリング取得部１１４、およびＳＬＳシグナリング解析部（ＭＰＤイベント挿入部）１１５は、送信装置２０から送信されるシグナリングデータを常時、監視し、未処理のシグナリングデータを検出した場合は、即座に取得、解析を実行する。
なお、前述したように送信装置２０は、シグナリングデータを繰り返し、送信しており、ミドルウェア１１０は、新規のシグナリングデータを大きな遅延を発生させることなく取得し、解析することが可能である。
【０１４８】
前述したように、送信装置２０が送信するシグナリングデータであるＬＬＳ（ローワレイヤシグナリング）には、以下の緊急情報配信通知データが含まれる場合がある。
（ａ）オンスクリーンメッセージ型緊急情報配信通知データ（Ｏｎ  Ｓｃｒｅｅｎ  Ｍｅｓｓａｇｅ  Ｎｏｔｉｆｉｃａｔｉｏｎ）、
（ｂ）シグナリングデータ適用型緊急情報配信通知データ（ＡＥＡＴ  Ｍｅｓｓａｇｅ  Ｎｏｔｉｆｉｃａｔｉｏｎ）、
【０１４９】
以下、このシグナリングデータ（ＬＬＳ）を利用した緊急情報配信通知処理構成について説明する。
上記（ａ），（ｂ）の緊急情報配信通知データを含むシグナリングデータ（ＬＬＳ）の詳細構成例について、図１２、図１３を参照して説明する。
図１２は、「（ａ）オンスクリーンメッセージ型緊急情報配信通知データ（Ｏｎ  Ｓｃｒｅｅｎ  Ｍｅｓｓａｇｅ  Ｎｏｔｉｆｉｃａｔｉｏｎ）」を含むシグナリングデータ（ＬＬＳ）の詳細構成例である。
オンスクリーンメッセージ型緊急情報配信通知データはＸＭＬデータとして記述される。
図１２に示すデータはＸＭＬデータを階層構成として示したＸＭＬデータの階層構成図である。
【０１５０】
図１２に示すように、オンスクリーンメッセージ型緊急情報配信通知データには、例えば、以下のデータが含まれる。
（１）緊急情報適用放送ストリーム識別子
（２）緊急情報適用対象サービス識別子
（３）画面クリア実行対象サービス識別子範囲
（４）画面クリア実行期間
（５）画面クリア処理要否フラグ
【０１５１】
画面クリア処理とは、先に図７を参照して説明したようなアプリ提示コンテンツ等の画面上のオーバレイコンテンツの表示を中止して、放送コンテンツを視聴可能な設定とする処理である。
【０１５２】
一方、図１３は、「（ｂ）シグナリングデータ適用型緊急情報配信通知データ（ＡＥＡＴ  Ｍｅｓｓａｇｅ  Ｎｏｔｉｆｉｃａｔｉｏｎ）」の詳細構成例である。
シグナリングデータ適用型緊急情報配信通知データもＸＭＬデータとして記述される。
図１３に示すデータはＸＭＬデータを階層構成として示したＸＭＬデータの階層構成図である。
【０１５３】
図１３に示すように、シグナリングデータ適用型緊急情報配信通知データには、例えば、以下のデータが含まれる。
（１）緊急情報の識別子、発行者、優先度情報等
（２）緊急情報の有効期間、タイプ、適用地域情報等
（３）緊急情報メッセージ等
（４）メディア（Ｍｅｄｉａ）情報：各言語対応緊急情報メッセージ、地図等のデータ、またはデータのアクセス情報等
【０１５４】
例えば、図１０、図１１に示すチューナ実装受信装置３０のミドルウェア１１０は、図１２、図１３に示す緊急情報関連データを含むシグナリングデータ（ＬＬＳ）を取得、解析することで、以下の通知がなされたことを遅延なく知ることが可能となる。
（ａ）オンスクリーンメッセージ型緊急情報配信通知（Ｏｎ  Ｓｃｒｅｅｎ  Ｍｅｓｓａｇｅ  Ｎｏｔｉｆｉｃａｔｉｏｎ）、
（ｂ）シグナリングデータ適用型緊急情報配信通知（ＡＥＡＴ  Ｍｅｓｓａｇｅ  Ｎｏｔｉｆｉｃａｔｉｏｎ）、
【０１５５】
しかし、放送サーバ２１等の送信装置２０の送信する番組コンテンツの再生処理を実行しているのは、図１０、図１１に示すチューナ実装受信装置３０や、チューナ非実装受信装置４０の再生制御部（ＤＡＳＨクライアント）１３１，１５１である。また、図７を参照して説明したようなアプリケーション提示コンテンツの提示処理を実行しているのは図１０、図１１に示すチューナ実装受信装置３０や、チューナ非実装受信装置４０のアプリケーション制御部１３３，１５３である。
【０１５６】
従って、これら再生制御部（ＤＡＳＨクライアント）１３１，１５１や、アプリケーション制御部１３３，１５３が、上記（ａ），（ｂ）の緊急情報配信通知がなされたことを把握しない限り、アプリケーション提示コンテンツの削除処理や、緊急情報の表示処理を実行することができない。
本開示の処理では、シグナリングデータ（ＬＬＳ）によって通知される、以下の通知情報、すなわち、
（ａ）オンスクリーンメッセージ型緊急情報配信通知（Ｏｎ  Ｓｃｒｅｅｎ  Ｍｅｓｓａｇｅ  Ｎｏｔｉｆｉｃａｔｉｏｎ）、
（ｂ）シグナリングデータ適用型緊急情報配信通知（ＡＥＡＴ  Ｍｅｓｓａｇｅ  Ｎｏｔｉｆｉｃａｔｉｏｎ）、
これらの緊急情報配信通知をミドルウェアから、再生制御部（ＤＡＳＨクライアント）１３１，１５１や、アプリケーション制御部１３３，１５３にいち早く転送し、これらの通知に対応した処理を遅延なく実行させることを可能とするものである。
このために、例えばイベント通知機構を利用した処理を実行する。
【０１５７】
通常、再生制御部（ＤＡＳＨクライアント）１３１，１５１は、番組コンテンツの構成データである画像や音声等の再生データを格納したＤＡＳＨセグメントのＨＴＴＰによる取得を連続して実行する。
従って、一旦、ストリーミング再生が開始されると、ＤＡＳＨクライアントはＨＴＴＰ取得／再生処理を継続して行う。
【０１５８】
すなわち、再生制御部（ＤＡＳＨクライアント）１３１，１５１は、ＤＡＳＨセグメントを提供するＤＡＳＨサーバとしての機能を実行するミドルウェア１１０やプロキシサーバ１２０と常時接続したＰｕｌｌ型コミュニケーションセッションを実行して、必要なデータを取得して再生処理、たとえば放送コンテンツの出力を行なう。
このセグメント取得セッション中で、なんらかのシグナリングの更新イベント通知、もしくはシグナリングそのものの伝送を行えるようにすることが課題となる。
【０１５９】
本開示の処理では、ＤＡＳＨで規定されているイベント（Ｅｖｅｎｔ）の機構を利用して、上述したシグナリングデータ（ＬＬＳ）による緊急情報配信通知、すなわち、
（ａ）オンスクリーンメッセージ型緊急情報配信通知（Ｏｎ  Ｓｃｒｅｅｎ  Ｍｅｓｓａｇｅ  Ｎｏｔｉｆｉｃａｔｉｏｎ）、
（ｂ）シグナリングデータ適用型緊急情報配信通知（ＡＥＡＴ  Ｍｅｓｓａｇｅ  Ｎｏｔｉｆｉｃａｔｉｏｎ）、
これらの通知情報を図１０、図１１に示すチューナ実装受信装置３０や、チューナ非実装受信装置４０の再生制御部（ＤＡＳＨクライアント）１３１，１５１、アプリケーション制御部１３３，１５３に遅延なく提供する構成を実現する。
【０１６０】
本開示の処理により、ＡＴＳＣ３．０放送受信ミドルウェアを実装するデバイスとネットワーク（家庭内ならホームネットワーク（ＬＡＮ／ＷｉＦｉ等）、ホットスポットならＷｉＦｉ等）を介して接続される別デバイス上で稼働するＤＡＳＨプレイヤや、ＡＥＡＴパーサ＆ビューワ等のクライアントアプリケーションに対しても、ストリームに同期させながら、動画画面上に表示される緊急メッセージ上に、重畳されてしまったアプリ提示データの排除処理や、例えばＡＥＡＴ等、動画ストリームとは別に送付される緊急情報や地図情報等の付加情報を遅延なく提供し出力させることが可能となる。
【０１６１】
［７．イベント通知構成について］
次に、ＤＡＳＨ規格において規定されているイベント通知構成について説明する。
ＤＡＳＨ規格では、ＤＡＳＨイベント（ＤＡＳＨ  Ｅｖｅｎｔ）と呼ばれるイベント通知機構が定義されている。
イベント通知機構は、例えば、放送番組や送信データの変更や詳細等の通知情報、受信装置において実行するアプリケーションに関する情報、受信装置に通知すべき情報、受信装置において必要となる処理の情報など、様々なイベント情報の通知を行うための機構である。
【０１６２】
ＤＡＳＨ規格においてはイベント通知機構として、以下の２種類のイベント通知方式が規定されている。
（ａ）ＭＰＤ適用イベント通知方式（＝ＭＰＤ  Ｅｖｅｎｔ）、
（ｂ）セグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）
これらの２種類のイベント通知方式が規定されている。
以下、これらの２つのイベント通知方式の詳細について、順次、説明する。
【０１６３】
［７−１．ＭＰＤ適用イベント通知方式（＝ＭＰＤ  Ｅｖｅｎｔ）について］
ＭＰＤ適用イベント通知方式（＝ＭＰＤ  Ｅｖｅｎｔ）は、ＤＡＳＨ規格に規定されたシグナリングデータの１つであるＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）を利用してイベントを通知する方式である。
【０１６４】
ＭＰＤ適用イベント通知方式（＝ＭＰＤ  Ｅｖｅｎｔ）は、ＭＰＤに規定可能なピリオド（Ｐｅｒｉｏｄ）単位で、イベント要素、具体的には、イベント種類や、イベント内容を示すイベントストリーム（ＥｖｅｎｔＳｔｒｅａｍ）等の要素を追加することができる。
【０１６５】
ＭＰＤ適用イベント通知方式（＝ＭＰＤ  Ｅｖｅｎｔ）では、ＭＰＤを利用して、ピリオド（Ｐｅｒｉｏｄ）単位でイベント処理に必要な情報をクライアントに提供できる。
具体的には、ＭＰＤ適用イベント通知方式（＝ＭＰＤ  Ｅｖｅｎｔ）では、
（ａ）様々なイベントのアクティベート（開始／実行／活性化）タイミング等のイベントスケジュール、
（ｂ）各タイミングにおいてクライアント（受信装置）が処理すべきイベント処理、さらに、
（ｃ）イベント実行時にクライアント上で稼働するアプリケーションに渡すべきデータ等、
これらをＭＰＤに記述することができる。
【０１６６】
図１４は、ＭＰＤのフォーマットを示す図である。
ＭＰＤは、画像や、音声それぞれのストリームごとに、以下の規定範囲単位で属性等の情報や制御情報を記述することが可能な構成を持つ。
（１）時間軸上の区間を規定したピリオド（Ｐｅｒｉｏｄ）
（２）画像、音声等のデータ種類等を規定したアダプテーション（Ａｄａｐｔａｔｉｏｎ）
（３）画像の種類、音声の種類等を規定したリプレゼンテーション（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）
（４）画像、音声のセグメント（ＡＶセグメント）単位の情報記録領域となるセグメントインフォ（ＳｅｇｍｅｎｔＩｎｆｏ）
【０１６７】
図１５は、ＭＰＤに記録されるＡＶセグメント対応の情報（制御情報や管理情報、属性情報など）を時系列に展開して示した図である。
左から右に時間が経過するものとする。この時間軸は、例えば受信装置におけるＡＶコンテンツの再生時間に対応する。
【０１６８】
ＡＶセグメントに対応する様々な情報がＭＰＤに記録される。なお、ＭＰＤはシグナリングデータの一部であり、例えばＡＶセグメントに先行して送信される。
ＭＰＤは、図１４を参照して説明したように、以下の各データ単位で情報が記録できる。
（１）時間軸上の区間を規定したピリオド（Ｐｅｒｉｏｄ）
（２）画像、音声等のデータ種類等を規定したアダプテーション（Ａｄａｐｔａｔｉｏｎ）
（３）画像の種類、音声の種類等を規定したリプレゼンテーション（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）
（４）画像、音声のセグメント（ＡＶセグメント）単位の情報記録領域となるセグメントインフォ（ＳｅｇｍｅｎｔＩｎｆｏ）
図１５は、これらのデータ領域を時間軸、およびデータ種類別に展開して示した図である。
【０１６９】
図１５には、以下の２つのアダプテーション（Ａｄａｐｔａｔｉｏｎ）を示している。
（Ｖ）画像対応情報記録領域であるアダプテーションＶ（Ａｄａｐｔａｔｉｏｎ（Ｖ））
（Ａ）音声対応情報記録領域であるアダプテーションＡ（Ａｄａｐｔａｔｉｏｎ（Ａ））
【０１７０】
（Ｖ）画像対応情報記録領域であるアダプテーションＶ（Ａｄａｐｔａｔｉｏｎ（Ｖ））は、異なる属性を持つストリーム単位の情報記録領域として、以下の２つのリプレゼンテーション（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）を有する。
（Ｖ１）低ビットレート画像対応の情報記録領域であるリプレゼンテーション（Ｖ１）（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ（Ｖ１））
（Ｖ２）高ビットレート画像対応の情報記録領域であるリプレゼンテーション（Ｖ２）（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ（Ｖ２））
【０１７１】
同様に、（Ａ）音声像対応情報記録領域であるアダプテーションＡ（Ａｄａｐｔａｔｉｏｎ（Ａ））は、異なる属性を持つストリーム単位の情報記録領域としての以下の２つのリプレゼンテーション（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）を有する。
（Ａ１）日本語音声対応の情報記録領域であるリプレゼンテーション（Ａ１）（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ（Ａ１））
（Ａ２）英語音声対応の情報記録領域であるリプレゼンテーション（Ａ２）（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ（Ａ２））
【０１７２】
さらに、各リプレゼンテーション（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）は、再生時間軸対応のピリオド、さらに、セグメント単位で情報が記録可能な構成となっている。
【０１７３】
例えば、高ビットレート画像と日本語音声を選択して再生する受信装置（クライアント）は、ピリオド１のセグメント（１１）の再生に際して、再生対象とする高ビットレート画像と日本語音声に関する情報をＭＰＤから選択して取得することになる。
この選択対象とするＭＰＤの記録情報が、図に示すセグメント領域３０１，３０２の情報となる。
【０１７４】
このように、受信装置は、シグナリングデータとして送信装置から送信されるＭＰＤから、自装置で再生対象とするデータ（セグメント）に対応する情報のみを選択して参照する。
【０１７５】
このように、ＭＰＤには、データ種別、時間単位のセグメント対応情報を記録することができる。
例えば、受信装置（クライアント）における様々な処理要求を通知するためのイベント通知も、このＭＰＤに記録することができる。
図１６は、ＭＰＤを用いたイベント通知、すなわち、ＭＰＤ適用イベント通知方式（＝ＭＰＤ  Ｅｖｅｎｔ）を適用した場合のＭＰＤの記述例を示す図である。
イベント情報を含むＭＰＤは、例えば以下の記述を有する。
【０１７６】
＜ＭＰＤ  ａｖａｉｌａｂｉｌｉｔｙＳｔａｒｔＴｉｍｅ＝"２０１１−１２−２５Ｔ１２：３０：００
＜Ｐｅｒｉｏｄ  ｓｔａｒｔＴｉｍｅ＝'０'＞
・・・
＜ＥｖｅｎｔＳｔｒｅａｍ  ｓｃｈｅｍｅＩｄＵｒｉ＝'ｕｒｎ：ｘｘｘ'  ｔｉｍｅｓｃａｌｅ＝'１０００'＞
＜Ｅｖｅｎｔ  ｐｒｅｓｅｎｔａｔｉｏｎＴｉｍｅ＝'０'  ｄｕｒａｔｉｏｎ＝'１０００'＞イベントデータ１＜／Ｅｖｅｎｔ＞
＜Ｅｖｅｎｔ  ｐｒｅｓｅｎｔａｔｉｏｎＴｉｍｅ＝'１０００'  ｄｕｒａｔｉｏｎ＝'４０００'＞イベントデータ２＜／Ｅｖｅｎｔ＞
…．
＜／ＥｖｅｎｔＳｔｒｅａｍ＞
・・・
＜ＡｄａｐｔａｔｉｏｎＳｅｔ＞
＜Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ／＞
＜Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ／＞
＜／ＡｄａｐｔａｔｉｏｎＳｅｔ＞
・・・
＜／Ｐｅｒｉｏｄ＞
＜／ＭＰＤ＞
【０１７７】
上記のＭＰＤのデータ内容について説明する。
＜ＭＰＤ  ａｖａｉｌａｂｉｌｉｔｙＳｔａｒｔＴｉｍｅ＝"２０１１−１２−２５Ｔ１２：３０：００
このデータ記録記録領域は、このＭＰＤに記録されたデータに対応する最初のピリオドの開始時刻情報の記録領域である。時刻情報としては例えばＵＴＣ時刻が用いられる。
【０１７８】
＜Ｐｅｒｉｏｄ  ｓｔａｒｔＴｉｍｅ＝'０'＞
このデータ記録記録領域は、ピリオド開始時間情報記録領域である。ＭＰＤにおいて規定されるスタート時間（ＭＰＤ／＠ａｖａｉｌａｂｉｌｉｔｙＳｔａｒｔＴｉｍｅ）からのオフセット時間が記録される。
【０１７９】
＜ＥｖｅｎｔＳｔｒｅａｍ  ｓｃｈｅｍｅＩｄＵｒｉ＝'ｕｒｎ：ｘｘｘ'  ｔｉｍｅｓｃａｌｅ＝'１０００'＞
このデータ記録記録領域は、イベント種類等を示すイベントストリーム指定情報とタイムスケール情報の記録領域である。
「ＥｖｅｎｔＳｔｒｅａｍ  ｓｃｈｅｍｅＩｄＵｒｉ'ｕｒｎ：ｘｘｘ'」と、オプショナルな「ＥｖｅｎｔＳｔｒｅａｍ／＠ｖａｌｕｅ」によりイベントの種類等が定義される。
さらに、「ｔｉｍｅｓｃａｌｅ＝'１０００'」は、以下に記録されるプレゼンテーションタイム（ｐｒｅｓｅｎｔａｔｉｏｎＴｉｍｅ）の単位時間は１／１０００秒であることを示す。
【０１８０】
＜Ｅｖｅｎｔ  ｐｒｅｓｅｎｔａｔｉｏｎＴｉｍｅ＝'０'  ｄｕｒａｔｉｏｎ＝'１０００'＞イベントデータ１＜／Ｅｖｅｎｔ＞
このデータ記録記録領域は、イベントデータの記録領域と、イベントのアクティベート（実行開始等）時間や継続時間等のイベントスケジューリングデータの記録領域である。
イベントデータは、イベントを実行するために必要となる実体データ、メタデータ、コマンド等のデータや、そのアクセス情報等によって構成される。
さらに、イベントのアクティベート（実行開始等）時間や継続時間が記録される。
この例は、イベントデータ１によって特定されるイベントを、アクティベート（活性化／実行）時刻＝０で１０００単位時間継続することを指定している。
【０１８１】
＜Ｅｖｅｎｔ  ｐｒｅｓｅｎｔａｔｉｏｎＴｉｍｅ＝'１０００'  ｄｕｒａｔｉｏｎ＝'４０００'＞イベントデータ１＜／Ｅｖｅｎｔ＞
このデータ記録記録領域も、イベントデータの記録領域と、イベントのアクティベート（実行開始等）時間や継続時間等のイベントスケジューリングデータの記録領域である。
イベントデータは、イベントを実行するために必要となる実体データ、メタデータ、コマンド等のデータや、そのアクセス情報等によって構成される。
さらに、イベントのアクティベート（実行開始等）時間や継続時間が記録される。
この例は、イベントデータ２によって特定されるイベントを、アクティベート（活性化／実行）時刻＝１０００で４０００単位時間継続することを指定している。
【０１８２】
以下の、
＜ＡｄａｐｔａｔｉｏｎＳｅｔ＞
＜Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ／＞
＜Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ／＞
これらは、各データ種類別の情報を記録するデータ記録領域である。
【０１８３】
このように、ＭＰＤを用いたイベント通知、すなわち、ＭＰＤ適用イベント通知方式（ＭＰＤ  Ｅｖｅｎｔ）では、
ＥｖｅｎｔＳｔｒｅａｍ／＠ｓｃｈｅｍｅＩｄＵｒｉ（とオプショナルなＥｖｅｎｔＳｔｒｅａｍ／＠ｖａｌｕｅ）属性によりイベントの種類を定義し、
ＥｖｅｎｔＳｔｒｅａｍ／Ｅｖｅｎｔ要素のコンテンツパートにイベントデータ、すなわち、イベントを実行するために必要となる実体データ、メタデータ、コマンド等のデータや、そのアクセス情報等を付加することができる。
【０１８４】
なお、ＭＰＤ／Ｐｅｒｉｏｄ／ＥｖｅｎｔＳｔｒｅａｍ／Ｅｖｅｎｔ以下のデータ要素として格納される「イベントデータ」のフォーマット（何を格納すべきか）については、「ＥｖｅｎｔＳｔｒｅａｍ／＠ｓｃｈｅｍｅＩｄＵｒｉ」属性の値（図１６の例では（ｕｒｎ：ｘｘｘ）によって特定（定義）される。
なお、この、ＭＰＤ適用イベント通知方式（ＭＰＤ  Ｅｖｅｎｔ）は、ＭＰＤの送出前に、ＭＰＤ内に記述されるピリオドの内容が確定できる場合にのみ適用可能である。
【０１８５】
図１７は、受信装置において実行するＭＰＤの解析処理（パース）の手順を説明する図である。
図１７には、以下の各図を示している。
（１）ＭＰＤ
（２）ピリオド単位情報
（３）リプレゼンテーション単位情報
（４）セグメント単位情報
【０１８６】
ＡＶセグメントを受信してＡＶコンテンツの再生処理を実行する受信装置（クライアント）は、ＡＶセグメント受信
前に予め受信するシグナリンクデータに含まれるＭＰＤを取得し、自走土地において再生するデータに対応する情報をＭＰＤから取得する。
【０１８７】
まず、図１７に示す（１）ＭＰＤから、ＡＶセグメント再生時間に相当する特定のピリオドの（情報を記録した（２）ピリオド単位情報を選択する。
さらに、自装置（クライアント）において再生するデータの種類に対応したリプレゼンテーション単位情報を選択し、さらに、再生対象セグメントに対応する（４）セグメント単位情報を選択する。
この（４）セグメント単位情報に記録されたデータを参照して、再生対象となるＡＶセグメントの取得や、ＡＶセグメント再生に必要となる様々な情報を取得することができる。
【０１８８】
受信装置（クライアント）は、受信したＭＰＤのセグメント単位情報にイベント情報が記録されている場合、その記録されたイベント情報に従って指定イベントのアクティベート（実行、開始等のイベント活性化処理）等を行うことになる。
【０１８９】
図１８を参照して、イベント情報を記録したＭＰＤの生成（または取得）と出力を実行するイベント挿入実行装置３１０と、イベント記録ＭＰＤを受領してＭＰＤ記録イベント情報に応じた処理を実行するイベント実行装置３２０の構成と処理例について説明する。
【０１９０】
図１８には、左側に、イベント情報を記録したＭＰＤの生成（または取得）と出力を実行するイベント挿入実行装置３１０を示している。
また、図１８の右側には、イベント情報を記録したＭＰＤを入力してＭＰＤに記録されたイベント情報に応じた処理（イベントアクティベート）を実行するイベント実行装置３２０を示している。
【０１９１】
イベント挿入実行装置３１０は、具体的には、ＭＰＤ等のシグナリングデータや、ＡＶセグメントを送信する放送サーバ２１、データ配信サーバ２２、あるいは、受信装置においてＭＰＤ等のシグナリングデータや、ＡＶセグメントを受信して、受信装置の再生制御部１３１に出力する受信装置のミドルウェア１１０（図１０、図１１に示すミドルウェア１１０）である。
【０１９２】
また、図１８の右側に示すイベント実行装置３２０は、具体的には、ＭＰＤ等のシグナリングデータや、ＡＶセグメントを入力してコンテンツ再生処理を実行する受信装置の再生制御部（図１０、図１１に示す再生制御部１３１，１５１）である。
【０１９３】
イベント挿入実行装置３１０の実行する処理について説明する。
イベント挿入実行装置３１０は、データ出力部（ＤＡＳＨサーバ）３１１、イベント処理部（イベントサーバ）３１２を有する。
なお、これらのサーバ機能は、ＭＰＤ等のシグナリングデータや、ＡＶセグメントを送信する放送サーバ２１、データ配信サーバ２２、さらに、受信装置のミドルウェア１１０（図１０、図１１に示すミドルウェア１１０）が有する機能である。
以下、イベント挿入実行装置３１０の実行する処理について、処理ステップごとに説明する。
【０１９４】
（ステップＳ１１）
まず、イベント挿入実行装置３１０のデータ出力部（ＤＡＳＨサーバ）３１１は、ステップＳ１１において、シグナリンクデータとしてのＭＰＤ、および再生コンテンツを構成するＡＶデータを含むセグメントを生成、または取得する。
【０１９５】
イベント挿入実行装置３１０が放送サーバ２１、データ配信サーバ２２である場合は、ＭＰＤ、セグメントを生成または取得する処理を行なう。
イベント挿入実行装置３１０が受信装置のミドルウェア１１０（図１０、図１１に示すミドルウェア１１０）である場合は、ＭＰＤ、セグメントを受信データから取得する処理を行なう。
【０１９６】
（ステップＳ１２）
次に、イベント挿入実行装置３１０のイベント処理部（イベントサーバ）３１２は、ステップＳ１２において、イベント情報を生成または、取得する。
イベント情報とは、例えば、番組表の変更や、放送コンテンツのデータ態様の変更、受信装置における放送コンテンツの再生時に実行すベき処理など、受信装置に対して何らかの処理の実行を通知あるいは要求するための情報である。
【０１９７】
イベント挿入実行装置３１０が放送サーバ２１、データ配信サーバ２２である場合は、イベント情報を生成または取得する処理を行なう。
イベント挿入実行装置３１０が受信装置のミドルウェア１１０（図１０、図１１に示すミドルウェア１１０）である場合は、イベント情報を受信データから取得する処理を行なう。
【０１９８】
（ステップＳ１３）
次に、イベント挿入実行装置３１０のデータ出力部（ＤＡＳＨサーバ）３１１は、ステップＳ１３において、シグナリンクデータとしてのＭＰＤに対して、イベント情報の挿入を行う。
この処理によって、先に図１６を参照して説明したイベント情報記録ＭＰＤが生成される。
【０１９９】
図１６に示すイベント情報記録ＭＰＤには、先に説明したように、
イベントの種類、内容や、イベントのアクティベート（活性化）時刻、継続時間情報等が記録されている。
受信装置は、このＭＰＤに記録されたイベント情報に従って、指定されたイベントを指定時間にアクティベート（例えば実行）し、指定継続時間、継続させる処理などを行うことが可能となる。
【０２００】
（ステップＳ１４）
次に、イベント挿入実行装置３１０のデータ出力部（ＤＡＳＨサーバ）３１１は、ステップＳ１４において、シグナリンクデータとしてのＭＰＤにイベント情報を記録したイベント情報記録ＭＰＤを送信（出力）する。
【０２０１】
イベント挿入実行装置３１０が放送サーバ２１、データ配信サーバ２２である場合は、イベント情報記録ＭＰＤを、放送波またはネットワークを介して送信する。
イベント挿入実行装置３１０が受信装置のミドルウェア１１０（図１０、図１１に示すミドルウェア１１０）である場合は、イベント情報記録ＭＰＤを、プロキシサーバ、あるいは再生制御部に出力する。
【０２０２】
（ステップＳ１５〜Ｓ１６）
次に、イベント挿入実行装置３１０のデータ出力部（ＤＡＳＨサーバ）３１１は、ステップＳ１５〜Ｓ１６において、ＡＶコンテンツ等を格納したセグメントを送信（出力）する。
セグメント送信は、ステップＳ１６以降、継続的に実行される。
【０２０３】
イベント挿入実行装置３１０が放送サーバ２１、データ配信サーバ２２である場合は、セグメントを、放送波またはネットワークを介して送信する。
イベント挿入実行装置３１０が受信装置のミドルウェア１１０（図１０、図１１に示すミドルウェア１１０）である場合は、セグメントを、プロキシサーバ、あるいは再生制御部に出力する。
【０２０４】
次に、図１８の右側に示すイベント実行装置３２０の実行する処理について説明する。
イベント実行装置３２０は、具体的には、ＭＰＤ等のシグナリングデータや、ＡＶセグメントを入力してコンテンツ再生処理を実行する受信装置の再生制御部（図１０、図１１に示す再生制御部１３１，１５１）である。
【０２０５】
図１８に示すイベント実行装置３２０の実行する処理は、受信装置の再生制御部１３１，１５１において実行する処理である。
なお、図１８においては、再生制御部を、実行する処理の種類に応じた処理種類単位で分離した構成として示している。
具体的には、イベント対応処理実行部としての再生制御部（イベントクライアント）３２１と、ＭＰＤやＡＶセグメントを適用したコンテンツ再生処理を実行する再生制御部（ＤＡＳＨクライアント）３２２、これら２つの処理部を示している。
【０２０６】
（ステップＳ２１）
まず、イベント実行装置３２０の再生制御部（ＤＡＳＨクライアント）３２２は、ステップＳ２１において、イベント挿入実行装置３１０に対してシグナリンクデータとしてのＭＰＤの取得要求を行う。
【０２０７】
（ステップＳ２２）
次に、イベント実行装置３２０の再生制御部（ＤＡＳＨクライアント）３２２は、ステップＳ２２において、イベント挿入実行装置３１０から取得したＭＰＤからイベント情報を取得する。
【０２０８】
なお、ここで取得したＭＰＤは、イベント情報記録ＭＰＤ、すなわち、図１６に示すイベント情報ＭＰＤであるものとする。
イベント情報記録ＭＰＤには、イベントの種類、内容や、イベントのアクティベート（例えば実行、停止等の活性化）時刻、継続時間情報等が記録されている。
受信装置は、このＭＰＤに記録されたイベント情報に従って、指定されたイベントを指定時間にアクティベート（例えば実行）し、指定継続時間、継続させる処理などを行うことが可能となる。
【０２０９】
（ステップＳ２３）
次に、イベント実行装置３２０の再生制御部（イベントクライアント）３２１は、ステップＳ２３において、ＭＰＤから取得したイベント情報に従って、イベント適用のスケジューリング処理を行なう。
前述したように、イベント情報記録ＭＰＤには、イベントの種類、内容や、イベントのアクティベート（活性化）時刻、継続時間情報等が記録されており、イベント実行装置３２０の再生制御部（イベントクライアント）３２１は、これらの情報を参照して、イベント実行のスケジューリング処理を行なう。
【０２１０】
（ステップＳ２４）
次に、イベント実行装置３２０の再生制御部（ＤＡＳＨクライアント）３２２は、ステップＳ２４において、イベント挿入実行装置３１０に対してセグメントの取得要求を行う。
【０２１１】
（ステップＳ２５）
次に、イベント実行装置３２０の再生制御部（ＤＡＳＨクライアント）３２２は、ステップＳ２５において、ステップＳ２４で取得したセグメントからＡＶコンテンツ等を取得し再生処理を実行する。
【０２１２】
（ステップＳ２６）
次に、イベント実行装置３２０の再生制御部（イベントクライアント）３２１は、ステップＳ２６において、ＭＰＤから取得したイベント情報に従ってスケジューリングされたイベントの適用処理、すなわちイベントアクティベート（イベント実行、開始等）処理を行なう。
【０２１３】
（ステップＳ２７〜Ｓ２９）
ステップＳ２７〜Ｓ２９の処理は、ステップＳ２４〜Ｓ２６の処理と同様の処理である。
この一連の処理は、継続的に実行されることになる。
【０２１４】
このように、受信装置（クライアント）は、ＡＶセグメントを受信し再生する処理に併せて、ＭＰＤに記録されたイベント情報に従って、様々なイベントを実行することが可能となる。
【０２１５】
［７−２．セグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）について］
次に、ＤＡＳＨ規格において規定されたもう１つのイベント通知方式であるセグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）について説明する。
【０２１６】
セグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）は、ＡＶコンテンツ等を格納したセグメント（ＤＡＳＨセグメント）内にイベント情報を記録して受信装置に提供する方式である。
【０２１７】
図１に示す送信装置２０は、前述したように、コンテンツデータを符号化し、符号化データおよび符号化データのメタデータを含むデータファイルを生成し送信する。符号化処理は、例えばＭＰＥＧにおいて規定されるＭＰ４ファイルフォーマットに従って行われる。なお、送信装置２０がＭＰ４形式のデータファイルを生成する場合の符号化データのファイルは「ｍｄａｔ」、メタデータは「ｍｏｏｖ」や「ｍｏｏｆ」等と呼ばれる。
【０２１８】
送信装置２０が提供するコンテンツは、例えば音楽データや、映画、テレビ番組、ビデオ、写真、文書、絵画および図表などの映像データや、ゲームおよびソフトウェアなど、様々なデータである。
【０２１９】
図１９を参照して、ＤＡＳＨ規格に従ってコンテンツストリーム配信を行う場合に利用可能なＤＡＳＨセグメントの構成例について説明する。ＤＡＳＨセグメントは、
（ａ）初期化セグメント（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ  Ｓｅｇｍｅｎｔ）、
（ｂ）メディアセグメント（Ｍｅｄｉａ  Ｓｅｇｍｅｎｔ）（＝ＡＶセグメント）、
これらの２種類に分けられる。
【０２２０】
（ａ）初期化セグメント（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ  Ｓｅｇｍｅｎｔ）は、受信装置３０におけるデコーダの設定等、コンテンツ再生を実行するために必要となる設定情報等の初期化データを格納したセグメントである。
（ｂ）メディアセグメント（Ｍｅｄｉａ  Ｓｅｇｍｅｎｔ）（＝ＡＶセグメント）は、再生対象となる符号化コンテンツ（ＡＶコンテンツ）を格納したセグメントである。
【０２２１】
図１９に示すように（ａ）初期化セグメントは、以下の各情報を含む。
（ａ１）セグメントのファイルタイプ情報等からなるヘッダ情報（ｄａｓｈ）、
（ａ２）メディアセグメントによって送信する符号化コンテンツであるメディアデータ（ｍｄａｔ）のコーデック（符号化態様）情報等の初期化情報を含むメタデータ（ｍｏｏｖ）、
【０２２２】
一方、（ｂ）メディアセグメントは、図１９に示すように以下の各情報を含む。
（ｂ１）セグメントのファイルタイプ情報等からなるヘッダ情報（ｍｓｄｈ）、
（ｂ２）メディアセグメントに格納された複数のサブセグメント（Ｓｕｂ−Ｓｅｇｍｅｎｔ）の境界情報や、メディアセグメントに格納された符号化コンテンツであるメディアデータ（ｍｄａｔ）のランダムアクセスポイント等を示すアクセス情報（ｓｉｄｘ）、
（ｂ３）複数のサブセグメント（Ｓｕｂ−Ｓｅｇｍｅｎｔ）、
【０２２３】
また、複数のサブセグメント（Ｓｕｂ−Ｓｅｇｍｅｎｔ）は１つまたは複数のフラグメント（Ｆｒａｇｍｅｎｔ）で構成される。
フラグメント（Ｆｒａｇｍｅｎｔ）は、以下の各データを含む。
再生対象となる符号化コンテンツであるメディアデータ（ｍｄａｔ）、
メディアデータ（ｍｄａｔ）に対応するメタデータ（ｍｏｏｆ）、
メディアデータ（ｍｄａｔ）に対応する各種情報（制御情報、管理情報、属性情報など）。
【０２２４】
なお、メディアデータ（ｍｄａｔ）、メタデータ（ｍｏｏｆ）、その他の各種情報（制御情報、管理情報、属性情報など）は、ＭＰ４フォーマットにおいて定義されるボックスに個別に格納される。
ｍｄａｔボックスにはＡＶデータが格納される。
ｍｏｏｆボックスにはメタデータが格納される。
その他の各種情報も、それぞれの情報に応じて定義されるボックスに格納される。
【０２２５】
イベント情報は、各種情報の一部としてイベント情報を格納するためのボックスとしてＭＰ４フォーマットで定義されたイベント情報格納ボックス［ｅｍｓｇボックス］に格納される。
【０２２６】
セグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）において利用されるＭＰ４フォーマットデータ内のイベント情報格納ボックス（ｅｍｓｇ）のデータ構成例について、図２０を参照して説明する。
図２０には、イベント識別子１，２の２つのイベント情報を個別に格納した２つのイベント情報格納ボックス（ｅｍｓｇ）のデータを示している。
【０２２７】
イベント情報格納ボックス（ｅｍｓｇ）は、例えば以下の記述を有する。
ｂｏｘ＿ｔｙｐｅ＝'ｅｍｓｇ'
ｓｃｈｅｍｅ＿ｉｄ＿ｕｒｉ＝"ｕｒｎ：ｘｘｘ"
ｖａｌｕｅ＝０
ｔｉｍｅｓｃａｌｅ＝１０００
ｐｒｅｓｅｎｔａｔｉｏｎ＿ｔｉｍｅ＿ｄｅｌｔａ＝０
ｅｖｅｎｔ＿ｄｕｒａｔｉｏｎ  ＝  ０ｘＦＦＦＦ
ｉｄ＝１
ｍｅｓｓａｇｅ＿ｄａｔａ［］＝イベントデータ−１
【０２２８】
上記のイベント情報格納ボックス（ｅｍｓｇ）のデータ内容について説明する。
ｂｏｘ＿ｔｙｐｅ＝'ｅｍｓｇ'
このデータ記録記録領域はボックスタイプ記録領域である。このボックス（ＭＰ４におい規定されるデータ格納ボックス）が、イベント情報格納ボックス（ｅｍｓｇ）であることを記述している。
【０２２９】
ｓｃｈｅｍｅ＿ｉｄ＿ｕｒｉ＝"ｕｒｎ：ｘｘｘ"
ｖａｌｕｅ＝０
このデータ記録記録領域は、イベント種類等を示すイベント指定情報の記録領域である。
「ｓｃｈｅｍｅ＿ｉｄ＿ｕｒｉ＝"ｕｒｎ：ｘｘｘ"」と、オプショナルな「ｖａｌｕｅ」によりイベントの種類等を定義する。
【０２３０】
ｔｉｍｅｓｃａｌｅ＝１０００
このデータ記録記録領域は、タイムスケール情報の記録領域である。
「ｔｉｍｅｓｃａｌｅ＝'１０００'」は、以下に記録されるプレゼンテーションタイム（ｐｒｅｓｅｎｔａｔｉｏｎＴｉｍｅ）の単位時間は１／１０００秒であることを示す。
【０２３１】
ｐｒｅｓｅｎｔａｔｉｏｎ＿ｔｉｍｅ＿ｄｅｌｔａ＝０
ｅｖｅｎｔ＿ｄｕｒａｔｉｏｎ＝０ｘＦＦＦＦ
これらのデータ記録記録領域は、イベントのアクティベート（実行開始等）時間や継続時間等のイベントスケジューリングデータの記録領域である。イベント指定情報によって特定されるイベントのアクティベート（活性化／実行）時刻＝０で、時刻＝０ｘＦＦＦＦまで継続することを指定している。なお、０ｘＦＦＦＦは終了時間を定義していないことを示し、このイベント情報格納ボックスの設定されたセグメントに対応するＡＶコンテンツの再生終了まで、イベントを継続してもしなくてもよいという指定であることを意味する。
【０２３２】
ｉｄ＝１
このデータ記録領域は、イベント識別情報記録領域である。
【０２３３】
ｍｅｓｓａｇｅ＿ｄａｔａ［］＝イベントデータ−１
このデータ記録領域は、イベントデータの記録領域である。
イベントデータは、イベントを実行するために必要となる実体データ、メタデータ、コマンド等のデータや、そのアクセス情報等によって構成される。
【０２３４】
このように、セグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）では、セグメントストリームの中（ｉｎ−ｓｔｒｅａｍ）にイベント情報を記録して転送することができる。
【０２３５】
セグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）では、「ｓｃｈｅｍｅ＿ｉｄ＿ｕｒｉ」フィールドと、オプショナルな「ｖａｌｕｅ」フィールドにイベントの種類を定義可能である。
また、「ｍｅｓｓａｇｅ＿ｄａｔａ」フィールドにイベントデータ、すなわち、イベントを実行するために必要となる実体データ、メタデータ、コマンド等のデータや、そのアクセス情報等を付加することができる。
【０２３６】
次に、図２１を参照して、イベント情報を記録したセグメントの生成（または取得）と出力を実行するイベント挿入実行装置３１０と、イベント記録情報セグメントを受領してセグメントに記録されたイベント情報に応じた処理を実行するイベント実行装置３２０の構成と処理例について説明する。
【０２３７】
図２１には、左側に、イベント情報を記録したセグメントの生成（または取得）と出力を実行するイベント挿入実行装置３１０を示している。
また、図２１の右側には、イベント情報を記録したセグメントを入力してセグメントに記録されたイベント情報に応じた処理（イベントアクティベート）を実行するイベント実行装置３２０を示している。
【０２３８】
イベント挿入実行装置３１０は、具体的には、ＭＰＤ等のシグナリングデータや、ＡＶセグメントを送信する放送サーバ２１、データ配信サーバ２２、あるいは、受信装置においてＭＰＤ等のシグナリングデータや、ＡＶセグメントを受信して、受信装置の再生制御部１３１に出力する受信装置のミドルウェア１１０（図１０、図１１に示すミドルウェア１１０）である。
【０２３９】
また、図２１の右側に示すイベント実行装置３２０は、具体的には、ＭＰＤ等のシグナリングデータや、ＡＶセグメントを入力してコンテンツ再生処理を実行する受信装置の再生制御部（図１０、図１１に示す再生制御部１３１，１５１）である。
【０２４０】
イベント挿入実行装置３１０の実行する処理について説明する。
イベント挿入実行装置３１０は、データ出力部（ＤＡＳＨサーバ）３１１、イベント処理部（イベントサーバ）３１２を有する。
なお、これらのサーバ機能は、ＭＰＤ等のシグナリングデータや、ＡＶセグメントを送信する放送サーバ２１、データ配信サーバ２２、さらに、受信装置のミドルウェア１１０（図１０、図１１に示すミドルウェア１１０）が有する機能である。
以下、イベント挿入実行装置３１０の実行する処理について、処理ステップごとに説明する。
【０２４１】
（ステップＳ３１）
まず、イベント挿入実行装置３１０のデータ出力部（ＤＡＳＨサーバ）３１１は、ステップＳ３１において、シグナリンクデータとしてのＭＰＤ、および再生コンテンツを構成するＡＶデータを含むセグメントを生成、または取得する。
【０２４２】
イベント挿入実行装置３１０が放送サーバ２１、データ配信サーバ２２である場合は、ＭＰＤ、セグメントを生成または取得する処理を行なう。
イベント挿入実行装置３１０が受信装置のミドルウェア１１０（図１０、図１１に示すミドルウェア１１０）である場合は、ＭＰＤ、セグメントを受信データから取得する処理を行なう。
【０２４３】
（ステップＳ３２）
次に、イベント挿入実行装置３１０のイベント処理部（イベントサーバ）３１２は、ステップＳ３２において、イベント情報を生成または、取得する。
イベント情報とは、例えば、番組表の変更や、放送コンテンツのデータ態様の変更、受信装置における放送コンテンツの再生時に実行すベき処理など、受信装置に対して何らかの処理の実行を通知あるいは要求するための情報である。
【０２４４】
イベント挿入実行装置３１０が放送サーバ２１、データ配信サーバ２２である場合は、イベント情報を生成または取得する処理を行なう。
イベント挿入実行装置３１０が受信装置のミドルウェア１１０（図１０、図１１に示すミドルウェア１１０）である場合は、イベント情報を受信データから取得する処理を行なう。
【０２４５】
（ステップＳ３３）
次に、イベント挿入実行装置３１０のデータ出力部（ＤＡＳＨサーバ）３１１は、ステップＳ３３において、セグメントに対して、イベント情報の挿入を行う。
この処理によって、先に図２０を参照して説明したＭＰ４フォーマットにおいて規定されるイベント情報記録ボックスであるｅｍｓｇボックスを含むセグメントが生成される。
【０２４６】
図２０に示すイベント情報記録ボックス（ｅｍｓｇ）ｉは、先に説明したように、
イベントの種類、内容や、イベントのアクティベート（活性化）時刻、継続時間情報等が記録されている。
受信装置は、このセグメント内のｅｍｓｇボックスに記録されたイベント情報に従って、指定されたイベントを指定時間にアクティベート（例えば実行）し、指定継続時間、継続させる処理などを行うことが可能となる。
【０２４７】
（ステップＳ３４）
次に、イベント挿入実行装置３１０のデータ出力部（ＤＡＳＨサーバ）３１１は、ステップＳ３４において、シグナリンクデータとしてのＭＰＤを送信（出力）する。
【０２４８】
イベント挿入実行装置３１０が放送サーバ２１、データ配信サーバ２２である場合は、ＭＰＤを、放送波またはネットワークを介して送信する。
イベント挿入実行装置３１０が受信装置のミドルウェア１１０（図１０、図１１に示すミドルウェア１１０）である場合は、ＭＰＤをプロキシサーバ、あるいは再生制御部に出力する。
【０２４９】
（ステップＳ３５〜Ｓ３６）
次に、イベント挿入実行装置３１０のデータ出力部（ＤＡＳＨサーバ）３１１は、ステップＳ３５〜Ｓ３６において、ＡＶコンテンツ等を格納したセグメントを送信（出力）する。
送信するセグメントは、ＭＰ４フォーマットにおいて規定されるイベント情報記録ボックス（ｅｍｓｇ）を含むセグメントである。
セグメント送信は、ステップＳ３６以降、継続的に実行される。
【０２５０】
イベント挿入実行装置３１０が放送サーバ２１、データ配信サーバ２２である場合は、セグメントを、放送波またはネットワークを介して送信する。
イベント挿入実行装置３１０が受信装置のミドルウェア１１０（図１０、図１１に示すミドルウェア１１０）である場合は、セグメントを、プロキシサーバ、あるいは再生制御部に出力する。
【０２５１】
次に、図２１の右側に示すイベント実行装置３２０の実行する処理について説明する。
イベント実行装置３２０は、具体的には、ＭＰＤ等のシグナリングデータや、ＡＶセグメントを入力してコンテンツ再生処理を実行する受信装置の再生制御部（図１０、図１１に示す再生制御部１３１，１５１）である。
【０２５２】
図２１に示すイベント実行装置３２０の実行する処理は、受信装置の再生制御部１３１，１５１において実行する処理である。
なお、図２１においては、再生制御部を、実行する処理の種類に応じて分離して示している。すなわち、イベント対応処理実行部としての再生制御部（イベントクライアント）３２１と、ＭＰＤやＡＶセグメントを適用したコンテンツ再生処理を実行する再生制御部（ＤＡＳＨクライアント）３２２の２つの処理部に区分して示している。
【０２５３】
（ステップＳ４１）
まず、イベント実行装置３２０の再生制御部（ＤＡＳＨクライアント）３２２は、ステップＳ４１において、イベント挿入実行装置３１０に対してシグナリンクデータとしてのＭＰＤの取得要求を行う。
【０２５４】
（ステップＳ４２）
次に、イベント実行装置３２０の再生制御部（ＤＡＳＨクライアント）３２２は、ステップＳ４４において、イベント挿入実行装置３１０に対してセグメントの取得要求を行う。
【０２５５】
（ステップＳ４３）
次に、イベント実行装置３２０の再生制御部（ＤＡＳＨクライアント）３２２は、ステップＳ４２において、イベント挿入実行装置３１０から取得したセグメントからイベント情報を取得する。
【０２５６】
なお、ここで取得したセグメントは、イベント情報記録ボックス（ｅｍｓｇ）を有する。すなわち、図２０に示すイベント情報を記録したイベント情報記録ボックス（ｅｍｓｇ）を含むセグメント（イベント情報記録セグメント）であるものとする。
【０２５７】
イベント情報記録セグメントには、イベントの種類、内容や、イベントのアクティベート（活性化）時刻、継続時間情報等が記録されている。
受信装置は、このセグメントに記録されたイベント情報に従って、指定されたイベントを指定時間にアクティベート（例えば実行）し、指定継続時間、継続させる処理などを行うことが可能となる。
【０２５８】
（ステップＳ４４）
次に、イベント実行装置３２０の再生制御部（イベントクライアント）３２１は、ステップＳ４４において、セグメントから取得したイベント情報に従ってスケジューリングされたイベントの適用処理、すなわちイベントアクティベート（イベント実行、開始等）処理を行なう。
【０２５９】
（ステップＳ４５）
次に、イベント実行装置３２０の再生制御部（ＤＡＳＨクライアント）３２２は、ステップＳ４５において、ステップＳ４２で取得したセグメントからＡＶコンテンツ等を取得し再生処理を実行する。
【０２６０】
（ステップＳ４６〜Ｓ４９）
ステップＳ４６〜Ｓ４９の処理は、ステップＳ４２〜Ｓ４５の処理と同様の処理である。
この一連の処理は、セグメント単位の処理として継続的に実行されることになる。
【０２６１】
このように、受信装置（クライアント）は、ＡＶセグメントを受信し再生する処理に併せて、セグメント内のイベント情報記録ボックス（ｅｍｓｇ）に記録されたイベント情報に従って、様々なイベントを実行することが可能となる。
【０２６２】
［８．緊急情報配信通知処理のためのイベント通知構成について］
次に、上述したイベント通知機構を利用して緊急情報自体、または緊急情報が配信されたことを通知する構成について説明する。
【０２６３】
先に説明したように、例えば、図１０、図１１に示すチューナ実装受信装置３０のミドルウェア１１０は、図１２、図１３に示すシグナリングデータ（ＬＬＳ）を取得、解析し、以下の緊急情報配信通知を遅延なく取得できる。
（ａ）オンスクリーンメッセージ型緊急情報配信通知（Ｏｎ  Ｓｃｒｅｅｎ  Ｍｅｓｓａｇｅ  Ｎｏｔｉｆｉｃａｔｉｏｎ）、
（ｂ）シグナリングデータ適用型緊急情報配信通知（ＡＥＡＴ  Ｍｅｓｓａｇｅ  Ｎｏｔｉｆｉｃａｔｉｏｎ）、
【０２６４】
しかし、放送サーバ２１等の送信装置２０の送信する番組コンテンツの再生処理を実行するのは、図１０、図１１に示すチューナ実装受信装置３０や、チューナ非実装受信装置４０の再生制御部（ＤＡＳＨクライアント）１３１，１５１である。また、図７を参照して説明したようなアプリケーション提示コンテンツの提示処理を実行しているのは図１０、図１１に示すチューナ実装受信装置３０や、チューナ非実装受信装置４０のアプリケーション制御部１３３，１５３である。
従って、これら再生制御部（ＤＡＳＨクライアント）１３１，１５１や、アプリケーション制御部１３３，１５３が、上記（ａ），（ｂ）の緊急情報配信通知がなされたことを把握しない限り、アプリケーション提示コンテンツの削除処理や、緊急情報の表示処理を実行することができない。
【０２６５】
本開示の処理では、シグナリングデータ（ＬＬＳ）によって通知される、以下の通知情報、すなわち、
（ａ）オンスクリーンメッセージ型緊急情報配信通知（Ｏｎ  Ｓｃｒｅｅｎ  Ｍｅｓｓａｇｅ  Ｎｏｔｉｆｉｃａｔｉｏｎ）、
（ｂ）シグナリングデータ適用型緊急情報配信通知（ＡＥＡＴ  Ｍｅｓｓａｇｅ  Ｎｏｔｉｆｉｃａｔｉｏｎ）、
これらの緊急情報配信通知をミドルウェアから、再生制御部（ＤＡＳＨクライアント）１３１，１５１や、アプリケーション制御部１３３，１５３にいち早く転送し、これらの通知に対応した処理を遅延なく実行させることを可能とするものであり、このための処理として、イベント通知機構を利用する。
【０２６６】
本開示の処理では、イベント通知機構を利用してイベント通知を行うイベントとして、以下の新たな２つのイベントを定義する。
（ａ）オンスクリーンメッセージイベント（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ  Ｅｖｅｎｔ）
（ｂ）シグナリングデータ適用型緊急情報配信イベント（ＡＥＡＴＤｅｌｉｖｅｒｅｄ  Ｅｖｅｎｔ）
【０２６７】
なお、イベント通知処理は、チューナ実装受信装置３０のミドルウェア１１０から、チューナ実装受信装置３０や、チューナ非実装受信装置４０の再生制御部（ＤＡＳＨクライアント）１３１，１５１に対して実行され、さらに、再生制御部（ＤＡＳＨクライアント）１３１，１５１を介して、チューナ実装受信装置３０や、チューナ非実装受信装置４０のアプリケーション制御部１３３，１５３、緊急情報制御部１４０，１６０に対して実行される。
【０２６８】
（ａ）オンスクリーンメッセージイベント（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ  Ｅｖｅｎｔ）は、シグナリングデータ（ＬＬＳ）によって、「オンスクリーンメッセージ型緊急情報配信通知（Ｏｎ  Ｓｃｒｅｅｎ  Ｍｅｓｓａｇｅ  Ｎｏｔｉｆｉｃａｔｉｏｎ）」が配信されたことを通知するためのイベント情報である。
【０２６９】
（ｂ）シグナリングデータ適用型緊急情報配信イベント（ＡＥＡＴＤｅｌｉｖｅｒｅｄ  Ｅｖｅｎｔ）は、シグナリングデータ（ＬＬＳ）によって、「（ｂ）シグナリングデータ適用型緊急情報配信通知（ＡＥＡＴ  Ｍｅｓｓａｇｅ  Ｎｏｔｉｆｉｃａｔｉｏｎ）」が配信されたことを通知するためのイベント情報である。
【０２７０】
上記２つのイベントを新たに定義する。
これら２つのイベントのイベント識別子（ｓｃｈｅｍｅＩｄＵｒｉ＝ｕｒｎ：ｕｎｉｆｏｒｍ  ｒｅｓｏｕｒｃｅ  ｎａｍｅ）は、以下の識別子とする。
（ａ）オンスクリーンメッセージイベント（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ  Ｅｖｅｎｔ）の識別子は、以下の識別子とする。
ｓｃｈｅｍｅＩｄＵｒｉ＝"ｕｒｎ：ａｔｓｃ：ｏｎＳｃｒｅｅｎＭｅｓｓａｇｅ"
【０２７１】
この識別子が設定されたイベント情報は、緊急情報メッセージがビデオストリーム上に（ビデオとして）重畳されたことを通知するためのイベント情報である。
例えばアプリケーション制御部１３３，１５３に、このイベント情報を通知して、緊急情報メッセージ上のアプリ提示コンテンツの排除を実行させる。
【０２７２】
一方、（ｂ）シグナリングデータ適用型緊急情報配信イベント（ＡＥＡＴＤｅｌｉｖｅｒｅｄ  Ｅｖｅｎｔ）の識別子は、以下の識別子とする。
ｓｃｈｅｍｅＩｄＵｒｉ＝"ｕｒｎ：ａｔｓｃ：ＡＥＡＴＤｅｌｉｖｅｒｅｄ"
【０２７３】
この識別子が設定されたイベント情報は、ＡＥＡＴやＣＡＰ等の緊急情報メッセージがシグナリングデータとして配信されたことを通知するためのイベント情報である。
再生制御部１３１，１５１、あるいはアプリケーション制御部１３３，１５３、緊急情報制御部１４０，２６０等に、このイベント情報を通知し、配信されたシグナリングデータから緊急情報（ＡＥＡＴ）を取得、または、シグナリングデータに記録されたアクセス情報を用いて緊急情報を取得し、取得した緊急情報を表示する処理を実行させる。
【０２７４】
なお、シグナリングデータ適用型緊急情報配信イベント（ＡＥＡＴＤｅｌｉｖｅｒｅｄ  Ｅｖｅｎｔ）は、イベント情報の記録データとして、
シグナリングデータ（ＬＬＳ）によって配信された緊急情報（ＡＥＡＴ）メッセージそのものを格納、または
緊急情報（ＡＥＡＴ）メッセージファイルのアクセス情報（ｕｒｌ）を記録、
これらいずれかの構成とする。
いずれの場合も、イベント情報に基づいて、緊急情報（ＡＥＡＴ）メッセージが取得可能である。
なお、緊急情報（ＡＥＡＴ）メッセージファイルには、先に図９を参照して説明した地図情報等も含まれる。
【０２７５】
［８−１．オンスクリーンメッセージ型緊急情報配信通知をイベント情報として通知する構成について］
まず、オンスクリーンメッセージ型緊急情報配信通知をイベント情報として通知する構成について説明する。
【０２７６】
なお、前述したように、ＤＡＳＨイベントの転送方式には、以下の２つの種類がある。
（ａ）イベント情報をシグナリングデータであるＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）内に挿入して転送するＭＰＤ適用イベント通知方式、
（ｂ）イベント情報をセグメント内に挿入して転送するセグメント適用（Ｉｎ−ｂａｎｄ）イベント通知方式、
これらの２種類がある。
【０２７７】
以下、オンスクリーンメッセージ型緊急情報配信通知を、上記２種類のイベント転送方式を適用した各処理方式について、順次、説明する。
なお、上記（ａ），（ｂ）いずれの場合も、イベント情報は、例えば、図１０、図１１に示すチューナ実装受信装置３０のミドルウェア１１０から、チューナ実装受信装置３０と、チューナ非実装受信装置４０の再生制御部（ＤＡＳＨクライアント）１３１，１５１に転送されることになる。
【０２７８】
［８−１−１．ＭＰＤ適用イベント通知方式を適用したオンスクリーンメッセージ型緊急情報配信通知の通知構成について］
まず、ＭＰＤ適用イベント通知方式を適用したオンスクリーンメッセージ型緊急情報配信通知の通知構成について説明する。
【０２７９】
ＭＰＤ適用イベント通知方式を用いて、オンスクリーンメッセージ型緊急情報配信通知を受信したことを知らせる「オンスクリーンメッセージイベント（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ  Ｅｖｅｎｔ）」の生成処理は、図１０、図１１に示すチューナ実装受信装置３０のＳＬＳシグナリング解析部（ＭＰＤイベント挿入部）１１５において実行される。
【０２８０】
オンスクリーンメッセージイベント（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ  Ｅｖｅｎｔ）は、緊急情報メッセージが番組コンテンツ等のビデオストリーム上に（ビデオとして）重畳されたことを通知し、この緊急情報メッセージ上に何も表示されないようにさせるための処理を要求するイベント情報である。
【０２８１】
しかし、緊急情報メッセージをビデオストリーム上に重畳する処理は、放送サーバ２１等の送信装置２０が、緊急事態発生時に実行するものであり、その実行タイミングは、予測不可能である。
すなわち、このイベントのアクティベート（活性化）時刻を記述することはできない。
【０２８２】
先に、図１４〜図１８を参照して説明したように、ＭＰＤ適用イベント通知方式（＝ＭＰＤ  Ｅｖｅｎｔ）では、ＭＰＤを利用して、ピリオド（Ｐｅｒｉｏｄ）単位でイベント処理に必要な情報をクライアントに提供できる。
具体的には、ＭＰＤ適用イベント通知方式（＝ＭＰＤ  Ｅｖｅｎｔ）では、
（ａ）様々なイベントのアクティベート（開始／実行／活性化）タイミング等のイベントスケジュール、
（ｂ）各タイミングにおいてクライアント（受信装置）が処理すべきイベント処理、さらに、
（ｃ）イベント実行時にクライアント上で稼働するアプリケーションに渡すべきデータ等、
これらをＭＰＤに記述することができる。
【０２８３】
しかし、上述したように、緊急情報メッセージのビデオストリーム上への重畳処理は、放送サーバ２１等の送信装置２０が、緊急事態発生時に実行するものであり、その実行タイミングは、予測不可能であり、ピリオド（Ｐｅｒｉｏｄ）単位のアクティベート（開始／実行／活性化）タイミング等のイベントスケジュールを規定することができない。
従って、オンスクリーンメッセージイベント（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ  Ｅｖｅｎｔ）のイベント情報を挿入した「緊急情報イベント挿入ＭＰＤ」を遅滞なく再生制御部（ＤＡＳＨクライアント）１３１,１５１等に取得させるためには、「緊急情報イベント挿入ＭＰＤ」の取得が必要であることを、再生制御部（ＤＡＳＨクライアント）１３１,１５１等に、事前に知らせることが必要となる。
【０２８４】
そのため、以下の処理手順（Ｓ０１）〜（Ｓ０３）を実行する。
（Ｓ０１）ミドルウェア１１０のＬＬＳシグナリング解析部１１３が、シグナリングデータ（ＬＬＳ）から、オンスクリーンメッセージ型緊急情報配信通知（Ｏｎ  Ｓｃｒｅｅｎ  Ｍｅｓｓａｇｅ  Ｎｏｔｉｆｉｃａｔｉｏｎ）を検出し、検出情報をＳＬＳシグナリング解析部（ＭＰＤイベント挿入部）１１５に通知、
【０２８５】
（Ｓ０２）ＳＬＳシグナリング解析部（ＭＰＤイベント挿入部）１１５は、オンスクリーンメッセージイベント（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ  Ｅｖｅｎｔ）を生成し、オンスクリーンメッセージイベント（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ  Ｅｖｅｎｔ）を記録したＭＰＤをキャッシュ部（プロキシキャッシュ）１２１に格納する。
さらに、再生制御部（ＤＡＳＨクライアント）１３１，１５１が利用中のＭＰＤが変更、または更新されたことを、既存のＤＡＳＨイベント通知機構を利用して再生制御部（ＤＡＳＨクライアント）１３１，１５１に通知する。
【０２８６】
（Ｓ０３）再生制御部（ＤＡＳＨクライアント）１３１，１５１は、ＭＰＤ更新イベント通知を受領し、このイベント通知に記録されたメッセージデータを適用して、ＭＰＤの更新処理を実行する。すなわち、上記のステップ（Ｓ０２）で、ＳＬＳシグナリング解析部（ＭＰＤイベント挿入部）１１５が生成し、キャッシュ部（プロキシキャッシュ）１２１に格納したオンスクリーンメッセージイベント（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ  Ｅｖｅｎｔ）を記録したＭＰＤを、再生制御部（ＤＡＳＨクライアント）１３１，１５１に、更新ＭＰＤとして取得させる。
【０２８７】
このステップ（Ｓ０１）〜（Ｓ０３）のＭＰＤ更新処理により、再生制御部（ＤＡＳＨクライアント）１３１，１５１は、「オンスクリーンメッセージイベント（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ  Ｅｖｅｎｔ）」を記録したＭＰＤを取得することができる。
再生制御部（ＤＡＳＨクライアント）１３１，１５１は、更新されたＭＰＤを参照することで、緊急情報メッセージが番組コンテンツ等のビデオストリーム上に（ビデオとして）重畳されたことを知ることが可能となる。
【０２８８】
なお、上記ステップ（Ｓ０２）で説明したＭＰＤが更新されたことを通知するイベント通知処理については、ＤＡＳＨスペックにおいて規定された既存の方法が適用可能である。
ＤＡＳＨスペックでは以下の２種類のイベントがＤＡＳＨ既定のイベントとして定義されている。
１つは、ＭＰＤ有効期限経過（ＭＰＤ  Ｖａｌｉｄｉｔｙ  Ｅｘｐｉｒａｔｉｏｎ）通知イベントであり、
もう１つは、ＭＰＤパッチ（ＭＰＤ  Ｐａｔｃｈ）通知イベントである。
これらのイベント（ＤＡＳＨイベント）は、いずれもＭＰＤの更新通知に利用するイベントである。どちらもそのイベントのタイプ（識別子）は、
ｓｃｈｅｍｅＩｄＵｒｉ＝"ｕｒｎ：ｍｐｅｇ：ｄａｓｈ：ｅｖｅｎｔ：２０１２"である。
ただし、これら２つのイベントには異なる属性（ｖａｌｕｅ属性）が設定され、この属性によって２つイベントを区別することが可能となる。
【０２８９】
ＭＰＤ有効期限経過（ＭＰＤ  Ｖａｌｉｄｉｔｙ  Ｅｘｐｉｒａｔｉｏｎ）通知イベントのタイプ（識別子）と属性（ｖａｌｕｅ属性）は以下の通りである。
ｓｃｈｅｍｅＩｄＵｒｉ＝"ｕｒｎ：ｍｐｅｇ：ｄａｓｈ：ｅｖｅｎｔ：２０１２"
ｖａｌｕｅ＝"１"  
一方、ＭＰＤパッチ（ＭＰＤ  Ｐａｔｃｈ）通知イベントのタイプ（識別子）と属性（ｖａｌｕｅ属性）は以下の通りである。
ｓｃｈｅｍｅＩｄＵｒｉ＝"ｕｒｎ：ｍｐｅｇ：ｄａｓｈ：ｅｖｅｎｔ：２０１２"
ｖａｌｕｅ＝"２"
【０２９０】
ＭＰＤ有効期限経過（ＭＰＤ  Ｖａｌｉｄｉｔｙ  Ｅｘｐｉｒａｔｉｏｎ）通知イベントは、再生制御部（ＤＡＳＨクライアント）が利用中のＭＰＤが変更、更新されたことを通知するイベントである。
通常ＭＰＤ更新時間はＭＰＤの属性であるＭＰＤ＠ｍｉｎｉｍｕｍＵｐｄａｔｅＰｅｒｉｏｄによりＭＰＤ内に記載して通知される。
クライアントとしての再生制御部（ＤＡＳＨクライアント）は、このｍｉｎｉｍｕｍＵｐｄａｔｅＰｅｒｉｏｄに記載さる時刻までは取得したＭＰＤが有効であると判断する。
【０２９１】
ただし、なんらかの事情で、再生制御部（ＤＡＳＨクライアント）に提供済みのＭＰＤを更新しなければならなくなった場合には、このＭＰＤ有効期限経過（ＭＰＤ  Ｖａｌｉｄｉｔｙ  Ｅｘｐｉｒａｔｉｏｎ）通知イベントを、セグメント適用（ｉｎ−ｂａｎｄ）イベント通知方式により、再生制御部（ＤＡＳＨクライアント）に転送する。
セグメント適用（ｉｎ−ｂａｎｄ）イベント通知方式は、セグメントのストリーム中にイベント通知情報を格納して通知する方式である。
すなわち、セグメント中にＭＰＤの更新が必要となったことを示すイベント通知を挿入して、再生制御部（ＤＡＳＨクライアント）に転送する。
再生制御部（ＤＡＳＨクライアント）は、入力セグメントについては、全て確認しており、このセグメント確認過程で、ＭＰＤ更新が必要となったことを知ることができる。
【０２９２】
なお、セグメント内に記録するイベントデータには、更新が必要となる時刻情報をメッセージデータとして記録する。具体的には、
ｉｎ−ｂａｎｄ  Ｅｖｅｎｔのｅｍｓｇ  ｂｏｘの、
ｍｅｓｓａｇｅ＿ｄａｔａ［］
に更新が必要となる時刻情報を格納する。
【０２９３】
再生制御部（ＤＡＳＨクライアント）は、セグメントから、このイベントを検出すると、現在利用中のＭＰＤファイルのアクセス情報（ｕｒｌ）と同様のアクセス情報を適用して、メッセージデータとして記録された時刻にＭＰＤの再取得を行う。この処理により、更新されたＭＰＤを取得することができる。
なお、緊急のＭＰＤ更新が必要となる場合は、"更新が必要となる時刻"を"今すぐ"に設定する。
【０２９４】
もう１つの、ＭＰＤパッチ（ＭＰＤ  Ｐａｔｃｈ）通知イベントは、ＭＰＤ有効期限経過（ＭＰＤ  Ｖａｌｉｄｉｔｙ  Ｅｘｐｉｒａｔｉｏｎ）通知イベントのように、ＭＰＤ更新が必要となる時刻を告げるのではなく、ＭＰＤそのものを更新する（改変する）コマンド（パッチスクリプト）を送る形態をとる。
【０２９５】
ＭＰＤそのものを更新するコマンドをメッセージデータとして、
ｉｎ−ｂａｎｄ  Ｅｖｅｎｔのｅｍｓｇ  ｂｏｘの
ｍｅｓｓａｇｅ＿ｄａｔａ［］
に格納する。
再生制御部（ＤＡＳＨクライアント）は、セグメントから、このイベントを検出すると、取得済みのＭＰＤに、このコマンドを適用して内容そのものを更新する。
【０２９６】
上記ステップ（Ｓ０２）で説明したＭＰＤの更新通知を行うイベント通知処理は、これらの既存のＤＡＳＨイベント通知機構を利用して実行することができる。
このように、上述したステップ（Ｓ０１）〜（Ｓ０３）の処理によって、再生制御部（ＤＡＳＨクライアント）１３１，１５１は、オンスクリーンメッセージイベント（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ  Ｅｖｅｎｔ）を記録した更新されたＭＰＤを取得することができる。
【０２９７】
オンスクリーンメッセージイベント（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ  Ｅｖｅｎｔ）情報を記録したＭＰＤのデータ例を図２２に示す。
ＭＰＤは、例えば以下の記述を有する。
【０２９８】
＜ＭＰＤ  ａｖａｉｌａｂｉｌｉｔｙＳｔａｒｔＴｉｍｅ＝"２０１１−１２−２５Ｔ１２：３０：００
＜Ｐｅｒｉｏｄ  ｓｔａｒｔＴｉｍｅ＝'０'＞
・・・
＜ＥｖｅｎｔＳｔｒｅａｍ  ｓｃｈｅｍｅＩｄＵｒｉ＝'ｕｒｎ：ａｔｓｃ：ｏｎＳｃｒｅｅｎＭｅｓｓａｇｅ'  ｔｉｍｅｓｃａｌｅ＝'１０００'＞
＜Ｅｖｅｎｔ  ｐｒｅｓｅｎｔａｔｉｏｎＴｉｍｅ＝'（イベントの開始（アクティベート）される対象期間（Ｐｅｒｉｏｄ）のピリオド開始時刻からの差分（経過時間)）
（緊急情報（オンスクリーンメッセージ（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ））データ、または緊急情報データアクセス用ＵＲＬ）
＜／Ｅｖｅｎｔ＞
・・・．
＜／ＥｖｅｎｔＳｔｒｅａｍ＞
・・・
＜ＡｄａｐｔａｔｉｏｎＳｅｔ＞
・・・
＜／Ｐｅｒｉｏｄ＞
＜／ＭＰＤ＞
【０２９９】
上記のＭＰＤのデータ内容について説明する。
＜ＭＰＤ  ａｖａｉｌａｂｉｌｉｔｙＳｔａｒｔＴｉｍｅ＝"２０１１−１２−２５Ｔ１２：３０：００
このデータ記録記録領域は、このＭＰＤに記録されたデータに対応する最初のピリオドの開始時刻情報の記録領域である。時刻情報としては例えばＵＴＣ時刻が用いられる。
【０３００】
＜Ｐｅｒｉｏｄ  ｓｔａｒｔＴｉｍｅ＝'０'＞
このデータ記録記録領域は、ピリオド開始時間情報記録領域である。ＭＰＤにおいて規定されるスタート時間（ＭＰＤ／＠ａｖａｉｌａｂｉｌｉｔｙＳｔａｒｔＴｉｍｅ）からのオフセット時間が記録される。
【０３０１】
＜ＥｖｅｎｔＳｔｒｅａｍ  ｓｃｈｅｍｅＩｄＵｒｉ＝'ｕｒｎ：ａｔｓｃ：ｏｎＳｃｒｅｅｎＭｅｓｓａｇｅ'  ｔｉｍｅｓｃａｌｅ＝'１０００'＞
このデータ記録記録領域は、イベント種類等を示すイベントストリーム指定情報とタイムスケール情報の記録領域である。
「ＥｖｅｎｔＳｔｒｅａｍ  ｓｃｈｅｍｅＩｄＵｒｉ＝'ｕｒｎ：ａｔｓｃ：ｏｎＳｃｒｅｅｎＭｅｓｓａｇｅ'」により、このイベントが、オンスクリーンメッセージイベント（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ  Ｅｖｅｎｔ）であることが確認できる。
さらに、「ｔｉｍｅｓｃａｌｅ＝'１０００'」は、以下に記録されるプレゼンテーションタイム（ｐｒｅｓｅｎｔａｔｉｏｎＴｉｍｅ）の単位時間は１／１０００秒であることを示す。
【０３０２】
＜Ｅｖｅｎｔ  ｐｒｅｓｅｎｔａｔｉｏｎＴｉｍｅ＝'（イベントの開始（アクティベート）される対象期間（Ｐｅｒｉｏｄ）のピリオド開始時刻からの差分（経過時間)）
（緊急情報（オンスクリーンメッセージ（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ））データ、または緊急情報データアクセス用ＵＲＬ）
このデータ記録記録領域は、イベントデータの記録領域と、イベントのアクティベート（実行開始等）時間や継続時間等のイベントスケジューリングデータの記録領域である。
オンスクリーンメッセージイベントの場合、放送コンテンツの画像に緊急情報が重畳表示される開始時間、重畳表示の継続時間が記録可能である。
イベントデータとしては、例えば、緊急情報メッセージの実体データ、またはそのアクセス情報等が記録される。
【０３０３】
以下の、
＜ＡｄａｐｔａｔｉｏｎＳｅｔ＞
＜Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ／＞
＜Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ／＞
これらは、各データ種類別の情報を記録するデータ記録領域であり、オンスクリーンメッセージイベントの場合、緊急情報が重畳表示される放送ストリームの識別情報等が記録される。
【０３０４】
例えば、図１０、図１１に示す再生制御部（ＤＡＳＨクライアント）１３１，１５１は、ＭＰＤを参照しながら、セグメントからデータを取得して、放送ストリームの出力制御を継続的に実行しており、この処理期間に、前述したセグメント適用（Ｉｎ−ｂａｎｄ）イベント通知方式により、セグメントのストリーム中から、イベント通知情報を取得する。
再生制御部（ＤＡＳＨクライアント）１３１，１５１は、このイベント情報に従って、オンスクリーンメッセージイベント（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ  Ｅｖｅｎｔ）を格納した更新ＭＰＤ、すなわち図２２を参照して説明した構成を持つオンスクリーンメッセージイベント（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ  Ｅｖｅｎｔ）を記録したＭＰＤを取得する。
【０３０５】
再生制御部（ＤＡＳＨクライアント）１３１，１５１は、更新ＭＰＤに記録された、オンスクリーンメッセージイベント（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ  Ｅｖｅｎｔ）を参照して、緊急情報が放送コンテンツの画像上に重畳されて配信されるタイミングを知ることが可能となる。
【０３０６】
再生制御部（ＤＡＳＨクライアント）１３１，１５１のイベント抽出部２０５，２５５は、さらに、このＭＰＤに記録されたオンスクリーンメッセージイベント（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ  Ｅｖｅｎｔ）を、アプリケーション制御部１３３，１５３に転送する。
アプリケーション制御部１３３，１５３は、アプリケーション提示コンテンツを表示部に表示している場合、そのアプリケーション提示コンテンツの表示を停止させる処理を行なう。
具体的には、例えば、先に図７を参照して説明した天気予報情報提示コンテンツ等の表示を停止させる。
この処理により、放送コンテンツの画像上に重畳されて配信される緊急情報をユーザ（視聴者）に確実に確認させることが可能となる。
【０３０７】
［８−１−２．セグメント適用（Ｉｎ−ｂａｎｄ）イベント通知方式を適用したオンスクリーンメッセージ型緊急情報配信通知の通知構成について］
次に、セグメント適用（Ｉｎ−ｂａｎｄ）イベント通知方式を適用したオンスクリーンメッセージ型緊急情報配信通知の通知構成について説明する。
【０３０８】
セグメント適用（Ｉｎ−ｂａｎｄ）イベント通知方式用いて、オンスクリーンメッセージ型緊急情報配信通知を受信したことを知らせる「オンスクリーンメッセージイベント（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ  Ｅｖｅｎｔ）」の生成処理は、図１０、図１１に示すチューナ実装受信装置３０のインバンドイベント挿入部１１８において実行される。
【０３０９】
オンスクリーンメッセージイベント（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ  Ｅｖｅｎｔ）は、緊急情報メッセージが番組コンテンツ等のビデオストリーム上に（ビデオとして）重畳されたことを通知し、この緊急情報メッセージ上に何も表示されないようにさせるための処理を要求するイベント情報である。
【０３１０】
図１１に示すチューナ実装受信装置３０のインバンドイベント挿入部１１８は、ゼグメント内に、このオンスクリーンメッセージイベント（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ  Ｅｖｅｎｔ）を挿入する。
セグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）において利用されるＭＰ４フォーマットデータ内のイベント情報格納ボックス（ｅｍｓｇ）の一般的なデータ構成例については、先に図２０を参照して説明した通りである。
【０３１１】
オンスクリーンメッセージイベント（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ  Ｅｖｅｎｔ）をセグメント内に設定したイベント情報格納ボックス（ｅｍｓｇ）のデータ構成例を図２３に示す。
【０３１２】
イベント情報格納ボックス（ｅｍｓｇ）は、例えば以下の記述を有する。
ｂｏｘ＿ｔｙｐｅ＝'ｅｍｓｇ'
ｓｃｈｅｍｅ＿ｉｄ＿ｕｒｉ＝"ｕｒｎ：ａｔｓｃ：ｏｎＳｃｒｅｅｎＭｅｓｓａｇｅ"
ｖａｌｕｅ＝０
ｔｉｍｅｓｃａｌｅ＝１０００
ｐｒｅｓｅｎｔａｔｉｏｎ＿ｔｉｍｅ＿ｄｅｌｔａ＝０
ｅｖｅｎｔ＿ｄｕｒａｔｉｏｎ  ＝  ０ｘＦＦＦＦ
ｉｄ＝１
ｍｅｓｓａｇｅ＿ｄａｔａ［］＝（緊急情報（オンスクリーンメッセージ（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ））データ、または緊急情報データアクセス用ＵＲＬ）
【０３１３】
上記のイベント情報格納ボックス（ｅｍｓｇ）のデータ内容について説明する。
ｂｏｘ＿ｔｙｐｅ＝'ｅｍｓｇ'
このデータ記録記録領域はボックスタイプ記録領域である。このボックス（ＭＰ４におい規定されるデータ格納ボックス）が、イベント情報格納ボックス（ｅｍｓｇ）であることを記述している。
【０３１４】
ｓｃｈｅｍｅ＿ｉｄ＿ｕｒｉ＝"ｕｒｎ：ａｔｓｃ：ｏｎＳｃｒｅｅｎＭｅｓｓａｇｅ"
ｖａｌｕｅ＝０
このデータ記録記録領域は、イベント種類等を示すイベント指定情報の記録領域である。
「ｓｃｈｅｍｅ＿ｉｄ＿ｕｒｉ＝"ｕｒｎ：ａｔｓｃ：ｏｎＳｃｒｅｅｎＭｅｓｓａｇｅ'」により、このイベントが、オンスクリーンメッセージイベント（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ  Ｅｖｅｎｔ）であることが確認できる。
さらに、オプショナルな「ｖａｌｕｅ」によりイベントの種類等を定義可能となる。
【０３１５】
ｔｉｍｅｓｃａｌｅ＝１０００
このデータ記録記録領域は、タイムスケール情報の記録領域である。
「ｔｉｍｅｓｃａｌｅ＝'１０００'」は、以下に記録されるプレゼンテーションタイム（ｐｒｅｓｅｎｔａｔｉｏｎＴｉｍｅ）の単位時間は１／１０００秒であることを示す。
【０３１６】
ｐｒｅｓｅｎｔａｔｉｏｎ＿ｔｉｍｅ＿ｄｅｌｔａ＝０
ｅｖｅｎｔ＿ｄｕｒａｔｉｏｎ＝０ｘＦＦＦＦ
これらのデータ記録記録領域は、イベントのアクティベート（実行開始等）時間や継続時間等のイベントスケジューリングデータの記録領域である。
オンスクリーンメッセージイベントの場合、放送コンテンツの画像に緊急情報が重畳表示される開始時間、重畳表示の継続時間が記録される。
イベントデータとしては、例えば、緊急情報メッセージの実体データ、またはそのアクセス情報等が記録可能である。
【０３１７】
ｉｄ＝１
このデータ記録領域は、イベント識別情報記録領域である。
【０３１８】
ｍｅｓｓａｇｅ＿ｄａｔａ［］＝（緊急情報（オンスクリーンメッセージ（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ））データ、または緊急情報データアクセス用ＵＲＬ）
このデータ記録領域は、イベントデータの記録領域である。
イベントデータは、イベントを実行するために必要となる実体データ、メタデータ、コマンド等のデータや、そのアクセス情報等によって構成される。
例えば、緊急情報メッセージの実体データ、またはそのアクセス情報等が記録される。
【０３１９】
このように、セグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）では、セグメントストリームの中（ｉｎ−ｓｔｒｅａｍ）にイベント情報を記録して転送することができる。
【０３２０】
セグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）では、「ｓｃｈｅｍｅ＿ｉｄ＿ｕｒｉ」フィールドと、オプショナルな「ｖａｌｕｅ」フィールドにイベントの種類を定義可能である。
また、「ｍｅｓｓａｇｅ＿ｄａｔａ」フィールドにイベントデータ、すなわち、イベントを実行するために必要となる実体データ、メタデータ、コマンド等のデータや、そのアクセス情報等を付加することができる。
【０３２１】
例えば、図１０、図１１に示す再生制御部（ＤＡＳＨクライアント）１３１，１５１は、ＭＰＤを参照しながら、セグメントからデータを取得して、放送ストリームの出力制御を継続的に実行しており、この処理期間に、セグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）により、セグメントのストリーム中から、イベント通知情報として、オンスクリーンメッセージイベント（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ  Ｅｖｅｎｔ）を取得する。
【０３２２】
再生制御部（ＤＡＳＨクライアント）１３１，１５１は、セグメント中に記録された、オンスクリーンメッセージイベント（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ  Ｅｖｅｎｔ）を参照して、緊急情報が放送コンテンツの画像上に重畳されて配信されるタイミングを知ることが可能となる。
【０３２３】
再生制御部（ＤＡＳＨクライアント）１３１，１５１のイベント抽出部２０５，２５５は、さらに、このセグメント内のオンスクリーンメッセージイベント（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ  Ｅｖｅｎｔ）を、アプリケーション制御部１３３，１５３に転送する。
アプリケーション制御部１３３，１５３は、アプリケーション提示コンテンツを表示部に表示している場合、そのアプリケーション提示コンテンツの表示を停止させる処理を行なう。
具体的には、例えば、先に図７を参照して説明した天気予報情報提示コンテンツ等の表示を停止させる。
この処理により、放送コンテンツの画像上に重畳されて配信される緊急情報をユーザ（視聴者）に確実に確認させることが可能となる。
【０３２４】
［８−１−３．オンスクリーンメッセージ型緊急情報配信通知に基づくイベント生成、転送、およびイベントに基づく処理の実行シーケンスについて］
上述したように、新たに定義したイベントである、
オンスクリーンメッセージイベント（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ  Ｅｖｅｎｔ）
は、シグナリングデータ（ＬＬＳ）によって、「オンスクリーンメッセージ型緊急情報配信通知（Ｏｎ  Ｓｃｒｅｅｎ  Ｍｅｓｓａｇｅ  Ｎｏｔｉｆｉｃａｔｉｏｎ）」が配信されたことを、ミドルウェアから、再生制御部（ＤＡＳＨクライアント）に通知することを可能とした。
【０３２５】
このイベント通知には、以下の２種類のタイプのイベント通知方式を利用することができる。
（ａ）ＭＰＤ適用イベント通知方式（＝ＭＰＤ  Ｅｖｅｎｔ）、
（ｂ）セグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）
以下、これらの２種類のイベント通知方式を利用したオンスクリーンメッセージイベント（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ  Ｅｖｅｎｔ）の生成、転送、およびイベントに基づく処理の実行シーケンスについて、順次、説明する。
【０３２６】
図２４を参照して、以下の３つの装置間の処理シーケンスについて説明する。
（１）ＡＶセグメントや、緊急情報、ＭＰＤ、シグナリングデータ等の生成と出力を実行する送信装置４１０、
（２）ＡＶセグメントや、緊急情報、ＭＰＤ、シグナリングデータ等を受信し、緊急情報の通知状況等を記録したイベント情報をＭＰＤ、またはセグメント内に記録したイベント挿入ＭＰＤ、またはイベント挿入セグメントを生成するチューナ実装受信装置ミドルウェア４２０、
（３）チューナ実装受信装置ミドルウェア４２０から、ＡＶセグメントや、イベント挿入ＭＰＤ、またはイベント挿入セグメント等を受領してＡＶセグメントの再生処理や、イベント情報に応じた処理を実行するチューナ実装／非実装受信装置出力データ制御部４３０、
【０３２７】
なお、チューナ実装受信装置ミドルウェア４２０は、図１０、図１１に示すチューナ実装受信装置３０のミドルウェア１１０に相当する。
また、チューナ実装／非実装受信装置出力データ制御部４３０は、図１０、図１１に示すチューナ実装受信装置３０と、チューナ非実装受信装置４０の再生制御部（ＤＡＳＨクライアント）１３１，１５１、出力制御部１３２，１５２、アプリケーション制御部１３３，１５３、緊急情報制御部１４０，１６０に相当する。
【０３２８】
また、図２４に示す送信装置４１０には、
再生コンテンツのストリーム等の生成を行うストリームサーバ４１１、
ＭＰＤやセグメントの生成を行うＤＡＳＨサーバ４１２、
緊急情報の生成を行う緊急情報サーバ４１３、
ＭＰＤ、セグメント、緊急情報の送信を実行する放送信号生成部（放送サーバ）４１４、
これらの４つの構成を分割してしている。
これらは、送信装置の実行する様々な処理を理解しやすくするために処理単位で区別して記載しているが、例えば、図１に示す放送サーバ２１、データ配信サーバ２２が有する機能であり、１つの送信装置（送信サーバ）において実行する構成としてもよい。
【０３２９】
まず、送信装置４１０の実行する処理について説明する。
（ステップＳ２０１）
まず、送信装置４１０の緊急情報サーバ４１３は、放送コンテンツを構成する画像に重畳して表示するための緊急情報を生成し、ストリームサーバ４１１の生成する画像に重畳する。
例えば、先に図５等を参照して説明したように、放送コンテンツの画像上に重畳して配信する緊急情報、すなわちオンスクリーンメッセージ型緊急情報を生成して、ストリームサーバ４１１の生成する画像に重畳する。
【０３３０】
（ステップＳ２０２）
次に、送信装置４１０の緊急情報サーバ４１３は、放送信号生成部（放送サーバ）４１４を介して、オンスクリーンメッセージ型緊急情報を放送コンテンツの画像上に重畳したことを示す通知を受信装置に出力する。
【０３３１】
これは、オンスクリーンメッセージ（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ）型の緊急情報の配信がなされること（オンスクリーンメッセージ通知：Ｏｎ  Ｓｃｒｅｅｎ  Ｍｅｓｓａｇｅ  Ｎｏｔｉｆｉｃａｔｉｏｎ）を示すシグナリングデータ（ＬＬＳ：Ｌｏｗｅｒ  Ｌａｙｅｒ  Ｓｉｇｎａｌｉｎｇ）の送信処理である。
このシグナリングデータ送信は、放送ストリーム等の通信セッションとは異なるセッションを利用して実行される。
【０３３２】
（ステップＳ２０３）
次に、送信装置４１０のストリームサーバ４１１は、ステップＳ２０３において、緊急情報サーバ４１３の生成した緊急情報を画像上に重畳したストリームを生成してＤＡＳＨサーバに出力する。
【０３３３】
（ステップＳ２０４〜Ｓ２０５）
次に、送信装置４１０のＤＡＳＨサーバ４１２は、ステップＳ２０４において、シグナリンクデータとしてのＭＰＤやセグメントを生成し、ステップＳ２０５において、放送信号生成部（放送サーバ）４１４を介して送信する。
【０３３４】
セグメントには放送コンテンツ構成データとしての画像や、音声が含まれる。
ＭＰＤには、放送コンテンツの再生処理に適用するための様々な制御情報、案内情報等が含まれる。
先に図１４他を参照して説明したように、ＭＰＤは、画像や、音声それぞれのストリームごとに、所定のデータ範囲単位の属性情報や制御情報を記述することが可能な構成を持つ。
【０３３５】
なお、送信装置４１０が放送局等である場合は、放送信号生成部（放送サーバ）４１４において、ＭＰＤやセグメントを放送波に載せて送信する処理が行われる。
一方、送信装置４１０が、インターネット等のネットワークを介したデータ送信を実行するデータ配信サーバである場合は、ＭＰＤやセグメントを、ネットワークを介して送信する。
【０３３６】
次に、チューナ実装受信装置ミドルウェア４２０の処理について説明する。
チューナ実装受信装置ミドルウェア４２０は、図１０、図１１に示すチューナ実装受信装置３０のミドルウェア１１０と同様の構成を持つ。
チューナ実装受信装置ミドルウェア４２０は、送信装置４１０の送信するＡＶセグメントや、緊急情報、ＭＰＤ、シグナリングデータ等を受信し、緊急情報の通知状況等を記録したイベント情報をＭＰＤ、またはセグメント内に記録したイベント挿入ＭＰＤ、またはイベント挿入セグメントを生成する、
さらに、生成したイベント挿入ＭＰＤ、またはイベント挿入セグメントをチューナ実装／非実装受信装置出力データ制御部４３０に転送する。
チューナ実装受信装置ミドルウェア４２０の実行する各ステップの処理について説明する。
【０３３７】
（ステップＳ２１１）
チューナ実装受信装置ミドルウェア４２０は、送信装置４１０から、オンスクリーンメッセージ型緊急情報が放送コンテンツの画像上に重畳されたことを示す通知を受信すると、ステップＳ２１１において、オンスクリーンメッセージイベントの生成処理を実行する。
【０３３８】
すなわち、チューナ実装受信装置ミドルウェア４２０は、送信装置４１０の緊急情報サーバのステップＳ２０２の処理において送信装置４１０から送信されたシグナリングデータ（ＬＬＳ：Ｌｏｗｅｒ  Ｌａｙｅｒ  Ｓｉｇｎａｌｉｎｇ）を受信する。
シグナリングデータ（ＬＬＳ）には、オンスクリーンメッセージ（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ）型の緊急情報の配信がなされること（オンスクリーンメッセージ通知：Ｏｎ  Ｓｃｒｅｅｎ  Ｍｅｓｓａｇｅ  Ｎｏｔｉｆｉｃａｔｉｏｎ）が記録されている。
【０３３９】
チューナ実装受信装置ミドルウェア４２０は、この通知に応じて、ＭＰＤ、またはセグメントに格納するイベント情報を生成する。
本例において、送信装置４１０の送信する緊急情報は、放送コンテンツの構成画像に直接重畳されたオンスクリーン型の緊急情報であり、チューナ実装受信装置ミドルウェア４２０は、オンスクリーンメッセージイベント（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ  Ｅｖｅｎｔ）を生成する。
【０３４０】
先に説明したように、オンスクリーンメッセージイベント（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ  Ｅｖｅｎｔ）は、シグナリングデータ（ＬＬＳ）によって、「オンスクリーンメッセージ型緊急情報配信通知（Ｏｎ  Ｓｃｒｅｅｎ  Ｍｅｓｓａｇｅ  Ｎｏｔｉｆｉｃａｔｉｏｎ）」が配信されたことを通知するためのイベント情報である。
【０３４１】
（ステップＳ２１２）
次に、チューナ実装受信装置ミドルウェア４２０は、ステップＳ２１２において、ＭＰＤ、またはセグメントの少なくともいずれかに、ステップＳ２１１で生成したイベント情報、すなわち、オンスクリーンメッセージイベント（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ  Ｅｖｅｎｔ）情報を記録する。
【０３４２】
前述したように、ＤＡＳＨイベントの転送方式には、以下の２つの種類がある。
（ａ）イベント情報をシグナリングデータであるＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）内に挿入して転送するＭＰＤ適用イベント通知方式、
（ｂ）イベント情報をセグメント内に挿入して転送するセグメント適用（Ｉｎ−ｂａｎｄ）イベント通知方式、
これらの２種類がある。
【０３４３】
ＭＰＤ適用イベント通知方式を適用する場合は、オンスクリーンメッセージイベント（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ  Ｅｖｅｎｔ）をＭＰＤに挿入する。
この処理によって、先に図２２を参照して説明したオンスクリーンメッセージイベント（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ  Ｅｖｅｎｔ）情報を記録したＭＰＤが生成される。
なお、この処理は、図１０に示すミドルウェア１１０のＳＬＳシグナリング生成部（ＭＰＤイベント挿入部）１１５において実行される。
【０３４４】
一方、セグメント適用（Ｉｎ−ｂａｎｄ）イベント通知方式を適用する場合は、オンスクリーンメッセージイベント（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ  Ｅｖｅｎｔ）をセグメントに挿入する。
この処理によって、先に図２３を参照して説明したオンスクリーンメッセージイベント（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ  Ｅｖｅｎｔ）情報を記録したセグメントが生成される。
なお、この処理は、図１０に示すミドルウェア１１０のインバンドイベント挿入部１１８において実行される。
【０３４５】
オンスクリーンメッセージイベント（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ  Ｅｖｅｎｔ）を挿入したＭＰＤ、あるいはセグメントには、例えば以下のデータが含まれる。
（１）緊急情報（オンスクリーンメッセージ（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ））データ、または緊急情報データアクセス用ＵＲＬ、
（２）放送コンテンツの画像に緊急情報が重畳表示される開始時間、重畳表示の継続時間、
これらのデータが記録される。
【０３４６】
（ステップＳ２１３）
次に、チューナ実装受信装置ミドルウェア４２０は、ステップＳ２１３において、ＭＰＤやセグメントをチューナ実装／非実装受信装置出力データ制御部４３０に転送する。
なお、この処理は、具体的には、プロキシサーバ１２１を介して実行される。
チューナ実装／非実装受信装置出力データ制御部４３０の再生制御部（ＤＡＳＨクライアント）、すなわち、図１０、図１１に示す再生制御部（ＤＡＳＨクライアント）１３１，１５１が、プロキシサーバ１２０のキャッシュ部（プロキシキャッシュ）１２１をアクセスしてＭＰＤやセグメントを取得する。
【０３４７】
再生制御部（ＤＡＳＨクライアント）１３１，１５１が取得するＭＰＤやセグメントには、再生制御部（ＤＡＳＨクライアント）１３１，１５１が、ステップＳ２１２で生成した、オンスクリーンメッセージイベント（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ  Ｅｖｅｎｔ）を挿入したＭＰＤ、またはセグメントが含まれる。
【０３４８】
なお、オンスクリーンメッセージイベント（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ  Ｅｖｅｎｔ）を挿入したＭＰＤを、チューナ実装／非実装受信装置出力データ制御部４３０、すなわち、図１０、図１１に示す再生制御部（ＤＡＳＨクライアント）１３１，１５１に遅延なく取得させるためには、前述したように、事前にＭＰＤ更新通知を行うことが必要である。
【０３４９】
すなわち、先に説明したように、チューナ実装受信装置ミドルウェア４２０は、まず、セグメント適用（ｉｎ−ｂａｎｄ）イベント通知方式を適用した既存のＭＰＤ更新イベント通知処理を実行する。
すなわち、再生制御部（ＤＡＳＨクライアント）１３１，１５１にＭＰＤ更新がなされたことを通知する。
再生制御部（ＤＡＳＨクライアント）１３１，１５１は、この通知に応じて、オンスクリーンメッセージイベント（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ  Ｅｖｅｎｔ）を挿入したＭＰＤを遅延なく取得することができる。
【０３５０】
次に、図２４の右側に示すチューナ実装／非実装受信装置出力データ制御部４３０の実行する処理について説明する。
図２４には、チューナ実装／非実装受信装置出力データ制御部４３０のアプリケーション制御部４３１、再生制御部４３２を示している。これらの構成は、図１０、図１１に示すチューナ実装受信装置３０とチューナ非実装受信装置４０のアプリケーション制御部１３３，１５３、再生制御部１３１，１５１の各構成に対応する。
【０３５１】
（ステップＳ２２１）
まず、チューナ実装／非実装受信装置出力データ制御部４３０の再生制御部（ＤＡＳＨクライアント）４３２は、チューナ実装受信装置ミドルウェア４２０を介して受信したＭＰＤ、またはセグメントから、オンスクリーンメッセージイベント（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ  Ｅｖｅｎｔ）を抽出し、アプリケーション制御部４３１に転送する。
【０３５２】
すなわち、再生制御部（ＤＡＳＨクライアント）４３２は、先に図２２を参照して説明したオンスクリーンメッセージイベント（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ  Ｅｖｅｎｔ）情報を記録したＭＰＤ、または、
先に図２３を参照して説明したオンスクリーンメッセージイベント（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ  Ｅｖｅｎｔ）情報を記録したセグメントから、
オンスクリーンメッセージイベント（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ  Ｅｖｅｎｔ）を抽出する。
【０３５３】
オンスクリーンメッセージイベント（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ  Ｅｖｅｎｔ）を挿入したＭＰＤ、あるいはセグメントには、例えば以下のデータが含まれる。
（１）緊急情報（オンスクリーンメッセージ（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ））データ、または緊急情報データアクセス用ＵＲＬ、
（２）放送コンテンツの画像に緊急情報が重畳表示される開始時間、重畳表示の継続時間、
これらのデータが記録されている。
【０３５４】
（ステップＳ２２２）
次に、チューナ実装／非実装受信装置出力データ制御部４３０のアプリケーション制御部４３１は、ステップＳ２２２において、再生制御部（ＤＡＳＨクライアント）４３２から受領したイベント情報に応じた処理を実行する。
【０３５５】
具体的には、アプリケーション制御部４３１は、アプリケーション提示コンテンツを表示部に表示している場合、そのアプリケーション提示コンテンツの表示を停止させる処理を行なう。
具体的には、例えば、先に図７を参照して説明した天気予報情報提示コンテンツ等の表示を停止させる。
この処理により、放送コンテンツの画像上に重畳されて配信される緊急情報をユーザ（視聴者）に確実に確認させることが可能となる。
【０３５６】
（ステップＳ２２３）
次に、チューナ実装／非実装受信装置出力データ制御部４３０の再生制御部（ＤＡＳＨクライアント）４３２は、チューナ実装受信装置ミドルウェア４２０を介して受信したセグメントからＡＶコンテンツ等を取得し再生処理を実行する。
【０３５７】
このように、チューナ実装／非実装受信装置出力データ制御部４３０の再生制御部（ＤＡＳＨクライアント）４３２は、ＡＶセグメントを受信し再生する処理に併せて、チューナ実装受信装置ミドルウェア４２０が生成したイベント情報挿入ＭＰＤ、またはイベント情報セグメントを取得し、放送コンテンツの画像に緊急情報が重畳表示されることを検知することが可能となる。
【０３５８】
さらに、このイベント情報をアプリケーション制御部４３１に転送することで、アプリケーション制御部が実行しているアプリケーション提示コンテンツの表示を停止させ、放送コンテンツの画像上に重畳された緊急情報が、アプリ提示コンテンツによって隠された状態になることを防止し、ユーザ（視聴者）に確実に確認させることができる。
【０３５９】
［８−２．シグナリングデータ適用型緊急情報配信通知をイベント情報として通知する構成について］
次に、シグナリングデータ適用型緊急情報配信通知をイベント情報として通知する構成について説明する。
【０３６０】
シグナリングデータ適用型緊急情報配信通知（ＡＥＡＴ  Ｍｅｓｓａｇｅ  Ｎｏｔｉｆｉｃａｔｉｏｎ）は、例えば先に図８を参照して説明したように、通常の番組配信経路とは異なる通信経路、例えば先に説明したシグナリングデータ（ＬＬＳ：：Ｌｏｗｅｒ  Ｌａｙｅｒ  Ｓｉｇｎａｌｉｎｇ）の通信経路を利用して緊急情報としてのメッセージや避難経路情報を送信する緊急情報通知方式である。
【０３６１】
先に図１３を参照して説明したＡＥＡＴ（Ａｄｖａｎｃｅｄ  Ｅｍｅｒｇｅｎｃｙ  Ａｌｅｒｔｉｎｇ  Ｔａｂｌｅ）や、ＣＡＰ（Ｃｏｍｍｏｎ  Ａｌｅｒｔｉｎｇ  Ｐｒｏｔｏｃｏｌ）フォーマットに従った緊急情報の送信処理は、このシグナリングデータ適用型の緊急情報配信方式に従って実行される。
【０３６２】
なお、前述したように、ＤＡＳＨイベントの転送方式には、以下の２つの種類がある。
（ａ）イベント情報をシグナリングデータであるＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）内に挿入して転送するＭＰＤ適用イベント通知方式、
（ｂ）イベント情報をセグメント内に挿入して転送するセグメント適用（Ｉｎ−ｂａｎｄ）イベント通知方式、
これらの２種類がある。
【０３６３】
以下、シグナリングデータ適用型緊急情報配信通知を、上記２種類のイベント転送方式を適用した各処理方式について、順次、説明する。
なお、上記（ａ），（ｂ）いずれの場合も、イベント情報は、例えば、図１０、図１１に示すチューナ実装受信装置３０のミドルウェア１１０から、チューナ実装受信装置３０と、チューナ非実装受信装置４０の再生制御部（ＤＡＳＨクライアント）１３１，１５１に転送されることになる。
【０３６４】
［８−２−１．ＭＰＤ適用イベント通知方式を適用したシグナリングデータ適用型緊急情報配信通知の通知構成について］
まず、ＭＰＤ適用イベント通知方式を適用したシグナリングデータ適用型緊急情報配信通知の通知構成について説明する。
【０３６５】
ＭＰＤ適用イベント通知方式を用いて、シグナリングデータ適用型緊急情報配信通知を受信したことを知らせる「シグナリングデータ適用型緊急情報（ＡＥＡＴ）配信イベント（ＡＥＡＴＤｅｌｉｖｅｒｅｄ  Ｅｖｅｎｔ）」の生成処理は、図１０、図１１に示すチューナ実装受信装置３０のＳＬＳシグナリング解析部（ＭＰＤイベント挿入部）１１５において実行される。
【０３６６】
シグナリングデータ適用型緊急情報（ＡＥＡＴ）配信イベント（ＡＥＡＴＤｅｌｉｖｅｒｅｄ  Ｅｖｅｎｔ）は、緊急情報としてのメッセージや避難経路情報等を、通常の番組配信経路とは異なる通信経路、例えば先に説明したシグナリングデータ（ＬＬＳ：：Ｌｏｗｅｒ  Ｌａｙｅｒ  Ｓｉｇｎａｌｉｎｇ）の通信経路を利用して受信装置に送信する方式である。
【０３６７】
しかし、この方式においても、先に説明したオンスクリーンメッセージ型緊急情報配信通知処理構成と同様、緊急情報の送信は、放送サーバ２１等の送信装置２０が、緊急事態発生時に実行するものであり、その実行タイミングは、予測不可能である。
従って、このイベントのアクティベート（活性化）時刻を記述することはできない。
【０３６８】
そのため、先にオンスクリーンメッセージ型のＭＰＤ適用イベント通知方式において説明したと同様、以下の処理手順（Ｓ０１）〜（Ｓ０３）を実行する。
（Ｓ０１）ミドルウェア１１０のＬＬＳシグナリング解析部１１３が、シグナリングデータ（ＬＬＳ）から、シグナリングデータ適用型緊急情報配信通知（Ｏｎ  Ｓｃｒｅｅｎ  Ｍｅｓｓａｇｅ  Ｎｏｔｉｆｉｃａｔｉｏｎ）を検出し、検出情報をＳＬＳシグナリング解析部（ＭＰＤイベント挿入部）１１５に通知、
【０３６９】
（Ｓ０２）ＳＬＳシグナリング解析部（ＭＰＤイベント挿入部）１１５は、シグナリングデータ適用型緊急情報（ＡＥＡＴ）配信イベント（ＡＥＡＴＤｅｌｉｖｅｒｅｄ  Ｅｖｅｎｔ）を生成し、シグナリングデータ適用型緊急情報（ＡＥＡＴ）配信イベント（ＡＥＡＴＤｅｌｉｖｅｒｅｄ  Ｅｖｅｎｔ）を記録したＭＰＤをキャッシュ部（プロキシキャッシュ）１２１に格納する。
さらに、再生制御部（ＤＡＳＨクライアント）１３１，１５１が利用中のＭＰＤが変更、または更新されたことを、既存のＤＡＳＨイベント通知機構を利用して再生制御部（ＤＡＳＨクライアント）１３１，１５１に通知する。
【０３７０】
（Ｓ０３）再生制御部（ＤＡＳＨクライアント）１３１，１５１は、ＭＰＤ更新イベント通知を受領し、このイベント通知に記録されたメッセージデータを適用して、ＭＰＤの更新処理を実行する。すなわち、上記のステップ（Ｓ０２）で、ＳＬＳシグナリング解析部（ＭＰＤイベント挿入部）１１５が生成し、キャッシュ部（プロキシキャッシュ）１２１に格納したシグナリングデータ適用型緊急情報（ＡＥＡＴ）配信イベント（ＡＥＡＴＤｅｌｉｖｅｒｅｄ  Ｅｖｅｎｔ）を記録したＭＰＤを、再生制御部（ＤＡＳＨクライアント）１３１，１５１に、更新ＭＰＤとして取得させる。
【０３７１】
このステップ（Ｓ０１）〜（Ｓ０３）のＭＰＤ更新処理により、再生制御部（ＤＡＳＨクライアント）１３１，１５１は、「シグナリングデータ適用型緊急情報（ＡＥＡＴ）配信イベント（ＡＥＡＴＤｅｌｉｖｅｒｅｄ  Ｅｖｅｎｔ）」を記録したＭＰＤを取得することができる。
再生制御部（ＤＡＳＨクライアント）１３１，１５１は、更新されたＭＰＤを参照することで、緊急情報メッセージがシグナリングデータ（例えばＬＬＳ）として配信された、または配信されることを知ることが可能となる。
【０３７２】
なお、上記ステップ（Ｓ０２）で説明したＭＰＤが更新されたことを通知するイベント通知処理は、先に説明したように、ＤＡＳＨスペックにおいて規定された以下の既存の方法が適用可能である。
１つは、ＭＰＤ有効期限経過（ＭＰＤ  Ｖａｌｉｄｉｔｙ  Ｅｘｐｉｒａｔｉｏｎ）通知イベントであり、
もう１つは、ＭＰＤパッチ（ＭＰＤ  Ｐａｔｃｈ）通知イベントである。
【０３７３】
このように、上述したステップ（Ｓ０１）〜（Ｓ０３）の処理によって、再生制御部（ＤＡＳＨクライアント）１３１，１５１は、シグナリングデータ適用型緊急情報（ＡＥＡＴ）配信イベント（ＡＥＡＴＤｅｌｉｖｅｒｅｄ  Ｅｖｅｎｔ）を記録した更新されたＭＰＤを取得することができる。
【０３７４】
シグナリングデータ適用型緊急情報（ＡＥＡＴ）配信イベント（ＡＥＡＴＤｅｌｉｖｅｒｅｄ  Ｅｖｅｎｔ）情報を記録したＭＰＤのデータ例を図２５に示す。
ＭＰＤは、例えば以下の記述を有する。
【０３７５】
＜ＭＰＤ  ａｖａｉｌａｂｉｌｉｔｙＳｔａｒｔＴｉｍｅ＝"２０１１−１２−２５Ｔ１２：３０：００
＜Ｐｅｒｉｏｄ  ｓｔａｒｔＴｉｍｅ＝'０'＞
・・・
＜ＥｖｅｎｔＳｔｒｅａｍ  ｓｃｈｅｍｅＩｄＵｒｉ＝'ｕｒｎ：ａｔｓｃ：ＡＥＡＴＤｅｌｉｖｅｒｅｄ'  ｔｉｍｅｓｃａｌｅ＝'１０００'＞
＜Ｅｖｅｎｔ  ｐｒｅｓｅｎｔａｔｉｏｎＴｉｍｅ＝'（イベントの開始（アクティベート）される対象期間（Ｐｅｒｉｏｄ）のピリオド開始時刻からの差分（経過時間)）
（シグナリングデータ適用型緊急情報（ＡＥＡＴ）データ、または緊急情報（ＡＥＡＴ）データアクセス用ＵＲＬ）
＜／Ｅｖｅｎｔ＞
・・・．
＜／ＥｖｅｎｔＳｔｒｅａｍ＞
・・・
＜ＡｄａｐｔａｔｉｏｎＳｅｔ＞
・・・
＜／Ｐｅｒｉｏｄ＞
＜／ＭＰＤ＞
【０３７６】
上記のＭＰＤのデータ内容について説明する。
＜ＭＰＤ  ａｖａｉｌａｂｉｌｉｔｙＳｔａｒｔＴｉｍｅ＝"２０１１−１２−２５Ｔ１２：３０：００
このデータ記録記録領域は、このＭＰＤに記録されたデータに対応する最初のピリオドの開始時刻情報の記録領域である。時刻情報としては例えばＵＴＣ時刻が用いられる。
【０３７７】
＜Ｐｅｒｉｏｄ  ｓｔａｒｔＴｉｍｅ＝'０'＞
このデータ記録記録領域は、ピリオド開始時間情報記録領域である。ＭＰＤにおいて規定されるスタート時間（ＭＰＤ／＠ａｖａｉｌａｂｉｌｉｔｙＳｔａｒｔＴｉｍｅ）からのオフセット時間が記録される。
【０３７８】
＜ＥｖｅｎｔＳｔｒｅａｍ  ｓｃｈｅｍｅＩｄＵｒｉ＝'ｕｒｎ：ａｔｓｃ：ＡＥＡＴＤｅｌｉｖｅｒｅｄ'  ｔｉｍｅｓｃａｌｅ＝'１０００'＞
このデータ記録記録領域は、イベント種類等を示すイベントストリーム指定情報とタイムスケール情報の記録領域である。
「ＥｖｅｎｔＳｔｒｅａｍ  ｓｃｈｅｍｅＩｄＵｒｉ＝'ｕｒｎ：ａｔｓｃ：ＡＥＡＴＤｅｌｉｖｅｒｅｄ'」により、このイベントが、シグナリングデータ適用型緊急情報（ＡＥＡＴ）配信イベント（ＡＥＡＴＤｅｌｉｖｅｒｅｄ  Ｅｖｅｎｔ）であることが確認できる。
さらに、「ｔｉｍｅｓｃａｌｅ＝'１０００'」は、以下に記録されるプレゼンテーションタイム（ｐｒｅｓｅｎｔａｔｉｏｎＴｉｍｅ）の単位時間は１／１０００秒であることを示す。
【０３７９】
＜Ｅｖｅｎｔ  ｐｒｅｓｅｎｔａｔｉｏｎＴｉｍｅ＝'（イベントの開始（アクティベート）される対象期間（Ｐｅｒｉｏｄ）のピリオド開始時刻からの差分（経過時間)）
（シグナリングデータ適用型緊急情報（ＡＥＡＴ）データ、または緊急情報（ＡＥＡＴ）データアクセス用ＵＲＬ）
このデータ記録記録領域は、イベントデータの記録領域と、イベントのアクティベート（実行開始等）時間や継続時間等のイベントスケジューリングデータの記録領域である。
シグナリングデータ適用型緊急情報（ＡＥＡＴ）配信イベントの場合、緊急情報（ＡＥＡＴ）が配信される開始時間、継続時間が記録可能である。
イベントデータとしては、例えば、緊急情報メッセージの実体データ、またはそのアクセス情報等が記録される。
【０３８０】
以下の、
＜ＡｄａｐｔａｔｉｏｎＳｅｔ＞
＜Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ／＞
＜Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ／＞
これらは、各データ種類別の情報を記録するデータ記録領域であり、シグナリングデータ適用型緊急情報（ＡＥＡＴ）配信イベントの場合、緊急情報が重畳表示される放送ストリームの識別情報等が記録される。
【０３８１】
例えば、図１０、図１１に示す再生制御部（ＤＡＳＨクライアント）１３１，１５１は、ＭＰＤを参照しながら、セグメントからデータを取得して、放送ストリームの出力制御を継続的に実行しており、この処理期間に、前述したセグメント適用（Ｉｎ−ｂａｎｄ）イベント通知方式により、セグメントのストリーム中から、イベント通知情報を取得する。
再生制御部（ＤＡＳＨクライアント）１３１，１５１は、このイベント情報に従って、シグナリングデータ適用型緊急情報（ＡＥＡＴ）配信イベント（ＡＥＡＴＤｅｌｉｖｅｒｅｄ  Ｅｖｅｎｔ）を格納した更新ＭＰＤ、すなわち図２５を参照して説明した構成を持つシグナリングデータ適用型緊急情報（ＡＥＡＴ）配信イベント（ＡＥＡＴＤｅｌｉｖｅｒｅｄ  Ｅｖｅｎｔ）を記録したＭＰＤを取得する。
【０３８２】
再生制御部（ＤＡＳＨクライアント）１３１，１５１は、更新ＭＰＤに記録された、シグナリングデータ適用型緊急情報（ＡＥＡＴ）配信イベント（ＡＥＡＴＤｅｌｉｖｅｒｅｄ  Ｅｖｅｎｔ）から、直接、緊急情報（ＡＥＡＴ）構成データを取得するか、または、更新ＭＰＤに記録された緊急情報（ＡＥＡＴ）のアクセス情報に従って、緊急情報（ＡＥＡＴ）をプロキシサーバ１２０のキャッシュ部１２１から取得する。
【０３８３】
なお、ミドルウェア１１０は、送信装置２０から送信される緊急情報（ＡＥＡＴ）を格納したシグナリングデータ（ＬＬＳ）を受信した場合、受信した緊急情報（ＡＥＡＴ）をプロキシサーバ１２０のキャッシュ部１２１に格納する処理を実行する。
【０３８４】
再生制御部（ＤＡＳＨクライアント）１３１，１５１のイベント抽出部２０５，２５５は、さらに、このＭＰＤに記録されたシグナリングデータ適用型緊急情報（ＡＥＡＴ）配信イベント（ＡＥＡＴＤｅｌｉｖｅｒｅｄ  Ｅｖｅｎｔ）を、アプリケーション制御部１３３，１５３、または、緊急情報制御部１４０，１６０に転送する。
イベントに緊急情報（ＡＥＡＴ）データが含まれていない場合は、更新ＭＰＤに記録された緊急情報（ＡＥＡＴ）のアクセス情報に従って、緊急情報（ＡＥＡＴ）をプロキシサーバ１２０のキャッシュ部１２１から取得し、アプリケーション制御部１３３，１５３、または、緊急情報制御部１４０，１６０に転送する。
【０３８５】
アプリケーション制御部１３３，１５３、または、緊急情報制御部１４０，１６０は、再生制御部（ＤＡＳＨクライアント）１３１，１５１を介して取得した緊急情報（ＡＥＡＴ）を解析し、緊急情報（ＡＥＡＴ）中に格納された緊急メッセージや避難経路の地図情報等を表示する処理を実行する。
具体的には、例えば、先に図８、図９を参照して説明した緊急情報の表示処理を実行する。
この処理により、シグナリングデータとして配信される緊急情報をユーザ（視聴者）に確実に確認させることが可能となる。
【０３８６】
［８−２−２．セグメント適用（Ｉｎ−ｂａｎｄ）イベント通知方式を適用したシグナリングデータ適用型緊急情報配信通知の通知構成について］
次に、セグメント適用（Ｉｎ−ｂａｎｄ）イベント通知方式を適用したシグナリングデータ適用型緊急情報配信通知の通知構成について説明する。
【０３８７】
セグメント適用（Ｉｎ−ｂａｎｄ）イベント通知方式用いて、シグナリングデータ適用型緊急情報配信通知を受信したことを知らせる「シグナリングデータ適用型緊急情報（ＡＥＡＴ）配信イベント（ＡＥＡＴＤｅｌｉｖｅｒｅｄ  Ｅｖｅｎｔ）」の生成処理は、図１０、図１１に示すチューナ実装受信装置３０のインバンドイベント挿入部１１８において実行される。
【０３８８】
シグナリングデータ適用型緊急情報（ＡＥＡＴ）配信イベント（ＡＥＡＴＤｅｌｉｖｅｒｅｄ  Ｅｖｅｎｔ）は、緊急情報としてのメッセージや避難経路情報等を、通常の番組配信経路とは異なる通信経路、例えば先に説明したシグナリングデータ（ＬＬＳ：：Ｌｏｗｅｒ  Ｌａｙｅｒ  Ｓｉｇｎａｌｉｎｇ）の通信経路を利用して受信装置に送信する方式である。
【０３８９】
図１１に示すチューナ実装受信装置３０のインバンドイベント挿入部１１８は、ゼグメント内に、このシグナリングデータ適用型緊急情報（ＡＥＡＴ）配信イベント（ＡＥＡＴＤｅｌｉｖｅｒｅｄ  Ｅｖｅｎｔ）を挿入する。
セグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）において利用されるＭＰ４フォーマットデータ内のイベント情報格納ボックス（ｅｍｓｇ）の一般的なデータ構成例については、先に図２０を参照して説明した通りである。
【０３９０】
シグナリングデータ適用型緊急情報（ＡＥＡＴ）配信イベント（ＡＥＡＴＤｅｌｉｖｅｒｅｄ  Ｅｖｅｎｔ）をセグメント内に設定したイベント情報格納ボックス（ｅｍｓｇ）のデータ構成例を図２６に示す。
【０３９１】
イベント情報格納ボックス（ｅｍｓｇ）は、例えば以下の記述を有する。
ｂｏｘ＿ｔｙｐｅ＝'ｅｍｓｇ'
ｓｃｈｅｍｅ＿ｉｄ＿ｕｒｉ＝"ｕｒｎ：ａｔｓｃ：ＡＥＡＴＤｅｌｉｖｅｒｅｄ"
ｖａｌｕｅ＝０
ｔｉｍｅｓｃａｌｅ＝１０００
ｐｒｅｓｅｎｔａｔｉｏｎ＿ｔｉｍｅ＿ｄｅｌｔａ＝０
ｅｖｅｎｔ＿ｄｕｒａｔｉｏｎ  ＝  ０ｘＦＦＦＦ
ｉｄ＝１
ｍｅｓｓａｇｅ＿ｄａｔａ［］＝（緊急情報（ＡＥＡＴ）データ、または緊急情報（ＡＥＡＴ）データアクセス用ＵＲＬ）
【０３９２】
上記のイベント情報格納ボックス（ｅｍｓｇ）のデータ内容について説明する。
ｂｏｘ＿ｔｙｐｅ＝'ｅｍｓｇ'
このデータ記録記録領域はボックスタイプ記録領域である。このボックス（ＭＰ４におい規定されるデータ格納ボックス）が、イベント情報格納ボックス（ｅｍｓｇ）であることを記述している。
【０３９３】
ｓｃｈｅｍｅ＿ｉｄ＿ｕｒｉ＝"ｕｒｎ：ａｔｓｃ：ＡＥＡＴＤｅｌｉｖｅｒｅｄ"
ｖａｌｕｅ＝０
このデータ記録記録領域は、イベント種類等を示すイベント指定情報の記録領域である。
「ｓｃｈｅｍｅ＿ｉｄ＿ｕｒｉ＝"ｕｒｎ：ａｔｓｃ：ＡＥＡＴＤｅｌｉｖｅｒｅｄ'」により、このイベントが、シグナリングデータ適用型緊急情報（ＡＥＡＴ）配信イベント（ＡＥＡＴＤｅｌｉｖｅｒｅｄ  Ｅｖｅｎｔ）であることが確認できる。
さらに、オプショナルな「ｖａｌｕｅ」によりイベントの種類等を定義可能となる。
【０３９４】
ｔｉｍｅｓｃａｌｅ＝１０００
このデータ記録記録領域は、タイムスケール情報の記録領域である。
「ｔｉｍｅｓｃａｌｅ＝'１０００'」は、以下に記録されるプレゼンテーションタイム（ｐｒｅｓｅｎｔａｔｉｏｎＴｉｍｅ）の単位時間は１／１０００秒であることを示す。
【０３９５】
ｐｒｅｓｅｎｔａｔｉｏｎ＿ｔｉｍｅ＿ｄｅｌｔａ＝０
ｅｖｅｎｔ＿ｄｕｒａｔｉｏｎ＝０ｘＦＦＦＦ
これらのデータ記録記録領域は、イベントのアクティベート（実行開始等）時間や継続時間等のイベントスケジューリングデータの記録領域である。
シグナリングデータ適用型緊急情報（ＡＥＡＴ）配信イベントの場合、緊急情報（ＡＥＡＴ）が配信される開始時間、継続時間が記録可能である。
イベントデータとしては、例えば、緊急情報メッセージの実体データ、またはそのアクセス情報等が記録可能である。
【０３９６】
ｉｄ＝１
このデータ記録領域は、イベント識別情報記録領域である。
【０３９７】
ｍｅｓｓａｇｅ＿ｄａｔａ［］＝（緊急情報（ＡＥＡＴ）データ、または緊急情報データアクセス用ＵＲＬ）
このデータ記録領域は、イベントデータの記録領域である。
イベントデータは、イベントを実行するために必要となる実体データ、メタデータ、コマンド等のデータや、そのアクセス情報等によって構成される。
例えば、緊急情報メッセージの実体データ、またはそのアクセス情報等が記録される。
【０３９８】
このように、セグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）では、セグメントストリームの中（ｉｎ−ｓｔｒｅａｍ）にイベント情報を記録して転送することができる。
【０３９９】
セグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）では、「ｓｃｈｅｍｅ＿ｉｄ＿ｕｒｉ」フィールドと、オプショナルな「ｖａｌｕｅ」フィールドにイベントの種類を定義可能である。
また、「ｍｅｓｓａｇｅ＿ｄａｔａ」フィールドにイベントデータ、すなわち、イベントを実行するために必要となる実体データ、メタデータ、コマンド等のデータや、そのアクセス情報等を付加することができる。
【０４００】
例えば、図１０、図１１に示す再生制御部（ＤＡＳＨクライアント）１３１，１５１は、ＭＰＤを参照しながら、セグメントからデータを取得して、放送ストリームの出力制御を継続的に実行しており、この処理期間に、セグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）により、セグメントのストリーム中から、イベント通知情報として、シグナリングデータ適用型緊急情報（ＡＥＡＴ）配信イベント（ＡＥＡＴＤｅｌｉｖｅｒｅｄ  Ｅｖｅｎｔ）を取得する。
【０４０１】
再生制御部（ＤＡＳＨクライアント）１３１，１５１は、セグメント中に記録された、シグナリングデータ適用型緊急情報（ＡＥＡＴ）配信イベント（ＡＥＡＴＤｅｌｉｖｅｒｅｄ  Ｅｖｅｎｔ）から、直接、緊急情報（ＡＥＡＴ）構成データを取得するか、または、更新ＭＰＤに記録された緊急情報（ＡＥＡＴ）のアクセス情報に従って、緊急情報（ＡＥＡＴ）をプロキシサーバ１２０のキャッシュ部１２１から取得する。
【０４０２】
再生制御部（ＤＡＳＨクライアント）１３１，１５１のイベント抽出部２０５，２５５は、さらに、このセグメント内のシグナリングデータ適用型緊急情報（ＡＥＡＴ）配信イベント（ＡＥＡＴＤｅｌｉｖｅｒｅｄ  Ｅｖｅｎｔ）を、アプリケーション制御部１３３，１５３、または、緊急情報制御部１４０，１６０に転送する。
イベントに緊急情報（ＡＥＡＴ）データが含まれていない場合は、セグメントに記録された緊急情報（ＡＥＡＴ）のアクセス情報に従って、緊急情報（ＡＥＡＴ）をプロキシサーバ１２０のキャッシュ部１２１から取得し、アプリケーション制御部１３３，１５３、または、緊急情報制御部１４０，１６０に転送する。
【０４０３】
アプリケーション制御部１３３，１５３、または、緊急情報制御部１４０，１６０は、再生制御部（ＤＡＳＨクライアント）１３１，１５１を介して取得した緊急情報（ＡＥＡＴ）を解析し、緊急情報（ＡＥＡＴ）中に格納された緊急メッセージや避難経路の地図情報等を表示する処理を実行する。
具体的には、例えば、先に図８、図９を参照して説明した緊急情報の表示処理を実行する。
この処理により、シグナリングデータとして配信される緊急情報をユーザ（視聴者）に確実に確認させることが可能となる。
【０４０４】
［８−２−３．シグナリングデータ適用型緊急情報配信通知に基づくイベント生成、転送、およびイベントに基づく処理の実行シーケンスについて］
上述したように、新たに定義したイベントである、
シグナリングデータ適用型緊急情報（ＡＥＡＴ）配信イベント（ＡＥＡＴＤｅｌｉｖｅｒｅｄ  Ｅｖｅｎｔ）
は、シグナリングデータ（ＬＬＳ）によって、「シグナリングデータ適用型緊急情報配信通知（ＡＥＡＴメッセージ通知：ＡＥＡＴ  Ｍｅｓｓａｇｅ  Ｎｏｔｉｆｉｃａｔｉｏｎ）」が配信されたことを、ミドルウェアから、再生制御部（ＤＡＳＨクライアント）に通知することを可能とした。
【０４０５】
このイベント通知には、以下の２種類のタイプのイベント通知方式を利用することができる。
（ａ）ＭＰＤ適用イベント通知方式（＝ＭＰＤ  Ｅｖｅｎｔ）、
（ｂ）セグメント適用イベント通知方式（＝Ｉｎ−ｂａｎｄ  Ｅｖｅｎｔ  Ｓｉｇｎａｌｉｎｇ）
以下、これらの２種類のイベント通知方式を利用したシグナリングデータ適用型緊急情報（ＡＥＡＴ）配信イベント（ＡＥＡＴＤｅｌｉｖｅｒｅｄ  Ｅｖｅｎｔ）の生成、転送、およびイベントに基づく処理の実行シーケンスについて、順次、説明する。
【０４０６】
図２７を参照して、以下の３つの装置間の処理シーケンスについて説明する。
（１）ＡＶセグメントや、緊急情報、ＭＰＤ、シグナリングデータ等の生成と出力を実行する送信装置４１０、
（２）ＡＶセグメントや、緊急情報、ＭＰＤ、シグナリングデータ等を受信し、緊急情報の通知状況等を記録したイベント情報をＭＰＤ、またはセグメント内に記録したイベント挿入ＭＰＤ、またはイベント挿入セグメントを生成するチューナ実装受信装置ミドルウェア４２０、
（３）チューナ実装受信装置ミドルウェア４２０から、ＡＶセグメントや、イベント挿入ＭＰＤ、またはイベント挿入セグメント等を受領してＡＶセグメントの再生処理や、イベント情報に応じた処理を実行するチューナ実装／非実装受信装置出力データ制御部４３０、
【０４０７】
なお、チューナ実装受信装置ミドルウェア４２０は、図１０、図１１に示すチューナ実装受信装置３０のミドルウェア１１０に相当する。
また、チューナ実装／非実装受信装置出力データ制御部４３０は、図１０、図１１に示すチューナ実装受信装置３０と、チューナ非実装受信装置４０の再生制御部（ＤＡＳＨクライアント）１３１，１５１、出力制御部１３２，１５２、アプリケーション制御部１３３，１５３、緊急情報制御部１４０，１６０に相当する。
【０４０８】
また、図２７に示す送信装置４１０には、
再生コンテンツのストリーム等の生成を行うストリームサーバ４１１、
ＭＰＤやセグメントの生成を行うＤＡＳＨサーバ４１２、
緊急情報の生成を行う緊急情報サーバ４１３、
ＭＰＤ、セグメント、緊急情報の送信を実行する放送信号生成部（放送サーバ）４１４、
これらの４つの構成を分割してしている。
これらは、送信装置の実行する様々な処理を理解しやすくするために処理単位で区別して記載しているが、例えば、図１に示す放送サーバ２１、データ配信サーバ２２が有する機能であり、１つの送信装置（送信サーバ）において実行する構成としてもよい。
【０４０９】
まず、送信装置４１０の実行する処理について説明する。
（ステップＳ４０１）
次に、送信装置４１０のストリームサーバ４１１は、ステップＳ４０１において、放送コンテンツ構成データとしての画像や音声等からなるストリームを生成してＤＡＳＨサーバに出力する。
【０４１０】
（ステップＳ４０２〜Ｓ４０３）
次に、送信装置４１０のＤＡＳＨサーバ４１２は、ステップＳ４０２において、シグナリンクデータとしてのＭＰＤやセグメントを生成し、ステップＳ４０３において、放送信号生成部（放送サーバ）４１４を介して送信する。
【０４１１】
セグメントには放送コンテンツ構成データとしての画像や、音声が含まれる。
ＭＰＤには、放送コンテンツの再生処理に適用するための様々な制御情報、案内情報等が含まれる。
先に図１４他を参照して説明したように、ＭＰＤは、画像や、音声それぞれのストリームごとに、所定のデータ範囲単位の属性情報や制御情報を記述することが可能な構成を持つ。
【０４１２】
なお、送信装置４１０が放送局等である場合は、放送信号生成部（放送サーバ）４１４において、ＭＰＤやセグメントを放送波に載せて送信する処理が行われる。
一方、送信装置４１０が、インターネット等のネットワークを介したデータ送信を実行するデータ配信サーバである場合は、ＭＰＤやセグメントを、ネットワークを介して送信する。
【０４１３】
（ステップＳ４０４〜Ｓ４０５）
まず、送信装置４１０の緊急情報サーバ４１３は、ステップＳ４０４において、シグナリングデータとして送信する緊急情報（ＡＥＡＴ）を生成し、ステップＳ４０５において、放送信号生成部（放送サーバ）４１４を介して送信する。
【０４１４】
緊急情報サーバ４１３の生成する緊急情報は、例えば先に図１３を参照して説明したデータフォーマットを有する緊急情報（ＡＥＡＴ：Ａｄｖａｎｃｅｄ  Ｅｍｅｒｇｅｎｃｙ  Ａｌｅｒｔｉｎｇ  Ｔａｂｌｅ）である。
ＡＥＡＴには、例えば緊急情報としての緊急情報メッセージや、避難経路を示す地図情報などの表示用データ、あるいは表示用データのアクセス情報等が含まれる。
なお、このシグナリングデータ送信は、放送ストリーム等の通信セッションとは異なるセッションを利用して実行される。
【０４１５】
次に、チューナ実装受信装置ミドルウェア４２０の処理について説明する。
チューナ実装受信装置ミドルウェア４２０は、図１０、図１１に示すチューナ実装受信装置３０のミドルウェア１１０と同様の構成を持つ。
チューナ実装受信装置ミドルウェア４２０は、送信装置４１０の送信するＡＶセグメントや、緊急情報、ＭＰＤ、シグナリングデータ等を受信し、緊急情報（ＡＥＡＴ）自体、あるいは緊急情報（ＡＥＡＴ）のアクセス情報を格納したイベント情報をＭＰＤ、またはセグメント内に記録したイベント挿入ＭＰＤ、またはイベント挿入セグメントを生成する、
さらに、生成したイベント挿入ＭＰＤ、またはイベント挿入セグメントをチューナ実装／非実装受信装置出力データ制御部４３０に転送する。
チューナ実装受信装置ミドルウェア４２０の実行する各ステップの処理について説明する。
【０４１６】
（ステップＳ４１１）
チューナ実装受信装置ミドルウェア４２０は、送信装置４１０から、シグナリングデータ適用型緊急情報（ＡＥＡＴ）を受信すると、ステップＳ４１１において、シグナリングデータ適用型緊急情報（ＡＥＡＴ）配信イベントの生成処理を実行する。
【０４１７】
すなわち、チューナ実装受信装置ミドルウェア４２０は、送信装置４１０の緊急情報サーバのステップＳ４０５の処理において送信装置４１０から送信された緊急情報（ＡＥＡＴ）を格納したシグナリングデータ（ＬＬＳ：Ｌｏｗｅｒ  Ｌａｙｅｒ  Ｓｉｇｎａｌｉｎｇ）を受信する。
【０４１８】
チューナ実装受信装置ミドルウェア４２０は、このシグナリングデータ（ＬＬＳ）の受信に応じて、ＭＰＤ、またはセグメントに格納するイベント情報を生成する。
本例において、送信装置４１０の送信する緊急情報は、シグナリングデータ適用型緊急情報（ＡＥＡＴ）であり、チューナ実装受信装置ミドルウェア４２０は、シグナリングデータ適用型緊急情報（ＡＥＡＴ）配信イベント（ＡＥＡＴＤｅｌｉｖｅｒｅｄ  Ｅｖｅｎｔ）を生成する。
【０４１９】
先に説明したように、シグナリングデータ適用型緊急情報（ＡＥＡＴ）配信イベント（ＡＥＡＴＤｅｌｉｖｅｒｅｄ  Ｅｖｅｎｔ）は、シグナリングデータ（ＬＬＳ）によって、「シグナリングデータ適用型緊急情報（ＡＥＡＴ）」が配信されたことを通知するためのイベント情報であり、緊急情報（ＡＥＡＴ）構成データ、または、緊急情報（ＡＥＡＴ）のアクセス情報を含むデータである。
【０４２０】
（ステップＳ４１２）
次に、チューナ実装受信装置ミドルウェア４２０は、ステップＳ４１２において、ＭＰＤ、またはセグメントの少なくともいずれかに、ステップＳ４１１で生成したイベント情報、すなわち、シグナリングデータ適用型緊急情報（ＡＥＡＴ）配信イベント（ＡＥＡＴＤｅｌｉｖｅｒｅｄ  Ｅｖｅｎｔ）情報を記録する。
【０４２１】
前述したように、ＤＡＳＨイベントの転送方式には、以下の２つの種類がある。
（ａ）イベント情報をシグナリングデータであるＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）内に挿入して転送するＭＰＤ適用イベント通知方式、
（ｂ）イベント情報をセグメント内に挿入して転送するセグメント適用（Ｉｎ−ｂａｎｄ）イベント通知方式、
これらの２種類がある。
【０４２２】
ＭＰＤ適用イベント通知方式を適用する場合は、シグナリングデータ適用型緊急情報（ＡＥＡＴ）配信イベント（ＡＥＡＴＤｅｌｉｖｅｒｅｄ  Ｅｖｅｎｔ）をＭＰＤに挿入する。
この処理によって、先に図２５を参照して説明したシグナリングデータ適用型緊急情報（ＡＥＡＴ）配信イベント（ＡＥＡＴＤｅｌｉｖｅｒｅｄ  Ｅｖｅｎｔ）情報を記録したＭＰＤが生成される。
なお、この処理は、図１０に示すミドルウェア１１０のＳＬＳシグナリング生成部（ＭＰＤイベント挿入部）１１５において実行される。
【０４２３】
一方、セグメント適用（Ｉｎ−ｂａｎｄ）イベント通知方式を適用する場合は、シグナリングデータ適用型緊急情報（ＡＥＡＴ）配信イベント（ＡＥＡＴＤｅｌｉｖｅｒｅｄ  Ｅｖｅｎｔ）をセグメントに挿入する。
この処理によって、先に図２６を参照して説明したシグナリングデータ適用型緊急情報（ＡＥＡＴ）配信イベント（ＡＥＡＴＤｅｌｉｖｅｒｅｄ  Ｅｖｅｎｔ）情報を記録したセグメントが生成される。
なお、この処理は、図１０に示すミドルウェア１１０のインバンドイベント挿入部１１８において実行される。
【０４２４】
シグナリングデータ適用型緊急情報（ＡＥＡＴ）配信イベント（ＡＥＡＴＤｅｌｉｖｅｒｅｄ  Ｅｖｅｎｔ）を挿入したＭＰＤ、あるいはセグメントには、例えば以下のデータが含まれる。
（１）緊急情報（ＡＥＡＴ）データ、または緊急情報（ＡＥＡＴ）データアクセス用ＵＲＬ、
（２）緊急情報の配信開始時間、配信継続時間、
これらのデータが記録される。
【０４２５】
（ステップＳ４１３）
次に、チューナ実装受信装置ミドルウェア４２０は、ステップＳ４１３において、ＭＰＤやセグメントをチューナ実装／非実装受信装置出力データ制御部４３０に転送する。
なお、この処理は、具体的には、プロキシサーバ１２１を介して実行される。
チューナ実装／非実装受信装置出力データ制御部４３０の再生制御部（ＤＡＳＨクライアント）、すなわち、図１０、図１１に示す再生制御部（ＤＡＳＨクライアント）１３１，１５１が、プロキシサーバ１２０のキャッシュ部（プロキシキャッシュ）１２１をアクセスしてＭＰＤやセグメントを取得する。
【０４２６】
再生制御部（ＤＡＳＨクライアント）１３１，１５１が取得するＭＰＤやセグメントには、再生制御部（ＤＡＳＨクライアント）１３１，１５１が、ステップＳ４１２で生成した、シグナリングデータ適用型緊急情報（ＡＥＡＴ）配信イベント（ＡＥＡＴＤｅｌｉｖｅｒｅｄ  Ｅｖｅｎｔ）を挿入したＭＰＤ、またはセグメントが含まれる。
【０４２７】
なお、シグナリングデータ適用型緊急情報（ＡＥＡＴ）配信イベント（ＡＥＡＴＤｅｌｉｖｅｒｅｄ  Ｅｖｅｎｔ）を挿入したＭＰＤを、チューナ実装／非実装受信装置出力データ制御部４３０、すなわち、図１０、図１１に示す再生制御部（ＤＡＳＨクライアント）１３１，１５１に取得させるためには、前述したように、事前にＭＰＤ更新通知を行うことが必要である。
【０４２８】
すなわち、先に説明したように、チューナ実装受信装置ミドルウェア４２０は、まず、セグメント適用（ｉｎ−ｂａｎｄ）イベント通知方式を適用した既存のＭＰＤ更新イベント通知処理を実行する。
すなわち、再生制御部（ＤＡＳＨクライアント）１３１，１５１にＭＰＤ更新がなされたことを通知する。
再生制御部（ＤＡＳＨクライアント）１３１，１５１は、この通知に応じて、シグナリングデータ適用型緊急情報（ＡＥＡＴ）配信イベント（ＡＥＡＴＤｅｌｉｖｅｒｅｄ  Ｅｖｅｎｔ）を挿入したＭＰＤを遅延なく取得することができる。
【０４２９】
（ステップＳ４１４）
ステップＳ４１４の処理は、チューナ実装受信装置ミドルウェア４２０が、ステップＳ４１３で、チューナ実装／非実装受信装置出力データ制御部４３０に転送したＭＰＤやセグメントに、緊急情報（ＡＥＡＴ）のアクセス情報が記録され、緊急情報（ＡＥＡＴ）データが含まれていない場合や、新たな出力（表示）用データが必要となるに実行される処理である。
【０４３０】
この場合、チューナ実装受信装置ミドルウェア４２０は、チューナ実装／非実装受信装置出力データ制御部４３０からの緊急情報（ＡＥＡＴ）取得要求に応じて、出力用データを含む緊急情報（ＡＥＡＴ）をチューナ実装／非実装受信装置出力データ制御部４３０に転送する。
【０４３１】
次に、図２７の右側に示すチューナ実装／非実装受信装置出力データ制御部４３０の実行する処理について説明する。
図２７には、チューナ実装／非実装受信装置出力データ制御部４３０の緊急情報制御部４３３、再生制御部４３２を示している。これらの構成は、図１０、図１１に示すチューナ実装受信装置３０とチューナ非実装受信装置４０の緊急情報制御部１４０，１６０と、再生制御部１３１，１５１の各構成に対応する。
【０４３２】
なお、この図２７に示す例では、緊急情報制御部４３３が緊急情報（ＡＥＡＴ）に含まれる緊急メッセージや地図等のデータレンダリングを実行する設定としているが、例えば、図１０、図１１に示すアプリケーション制御部１３３，１５３が、緊急情報（ＡＥＡＴ）に含まれる緊急メッセージや地図等のデータレンダリングを実行することも可能である。
すなわち、図２７に示す緊急情報制御部４３３をアプリケーション制御部に置き換えることも可能である。
【０４３３】
（ステップＳ４２１）
まず、チューナ実装／非実装受信装置出力データ制御部４３０の再生制御部（ＤＡＳＨクライアント）４３２は、チューナ実装受信装置ミドルウェア４２０を介して受信したＭＰＤ、またはセグメントから、シグナリングデータ適用型緊急情報（ＡＥＡＴ）配信イベント（ＡＥＡＴＤｅｌｉｖｅｒｅｄ  Ｅｖｅｎｔ）を抽出し、緊急情報制御部４３３に転送する。
【０４３４】
すなわち、再生制御部（ＤＡＳＨクライアント）４３２は、先に図２２を参照して説明したシグナリングデータ適用型緊急情報（ＡＥＡＴ）配信イベント（ＡＥＡＴＤｅｌｉｖｅｒｅｄ  Ｅｖｅｎｔ）情報を記録したＭＰＤ、または、
先に図２３を参照して説明したシグナリングデータ適用型緊急情報（ＡＥＡＴ）配信イベント（ＡＥＡＴＤｅｌｉｖｅｒｅｄ  Ｅｖｅｎｔ）情報を記録したセグメントから、
シグナリングデータ適用型緊急情報（ＡＥＡＴ）配信イベント（ＡＥＡＴＤｅｌｉｖｅｒｅｄ  Ｅｖｅｎｔ）を抽出する。
【０４３５】
シグナリングデータ適用型緊急情報（ＡＥＡＴ）配信イベント（ＡＥＡＴＤｅｌｉｖｅｒｅｄ  Ｅｖｅｎｔ）を挿入したＭＰＤ、あるいはセグメントには、例えば以下のデータが含まれる。
（１）緊急情報（ＡＥＡＴ）データ、または緊急情報（ＡＥＡＴ）データアクセス用ＵＲＬ、
（２）緊急情報（ＡＥＡＴ）の配信開始時間、継続時間、
これらのデータが記録されている。
【０４３６】
（ステップＳ４２２〜Ｓ４２３）
次に、チューナ実装／非実装受信装置出力データ制御部４３０の緊急情報制御部４３３は、ステップＳ４２２において、再生制御部（ＤＡＳＨクライアント）４３２から受領したイベント情報を取得し、ステップＳ４２３において、緊急情報（ＡＥＡＴ）データを表示部に出力する処理を実行する。
【０４３７】
なお、再生制御部（ＤＡＳＨクライアント）４３２から受領したイベント情報に、出力（表示）用の緊急情報（ＡＥＡＴ）データが含まれている場合は、受領したイベント情報から緊急情報（ＡＥＡＴ）を取得して、ステップＳ４２３において緊急情報（ＡＥＡＴ）に含まれる緊急メッセージや地図情報等を表示する。
【０４３８】
一方、再生制御部（ＤＡＳＨクライアント）４３２から受領したイベント情報に緊急情報（ＡＥＡＴ）のアクセス情報が記録され、出力（表示）用の緊急情報（ＡＥＡＴ）データが含まれていない場合には、アクセス情報を利用して、チューナ実装受信装置ミドルウェア４２０から緊急情報（ＡＥＡＴ）を取得する処理を実行した後、ステップＳ４２３において、取得した緊急情報（ＡＥＡＴ）に含まれる緊急メッセージや地図情報等を表示する。
【０４３９】
なお、チューナ実装受信装置ミドルウェア４２０が取得した緊急情報（ＡＥＡＴ）は、図１０に示すプロキシサーバ１２０のキッャシュ部１２１に格納されており、緊急情報制御部４３３は、プロキシサーバ１２０のキッャシュ部１２１に格納された緊急情報（ＡＥＡＴ）データを取得する。この取得処理は、再生制御部（ＤＡＳＨクライアント）４３２が実行し、再生制御部（ＤＡＳＨクライアント）４３２から緊急情報制御部４３３に提供する構成としてもよい。、
【０４４０】
（ステップＳ４２４）
次に、チューナ実装／非実装受信装置出力データ制御部４３０の再生制御部（ＤＡＳＨクライアント）４３２は、チューナ実装受信装置ミドルウェア４２０を介して受信したセグメントからＡＶコンテンツ等を取得し再生処理を実行する。
【０４４１】
このように、チューナ実装／非実装受信装置出力データ制御部４３０の再生制御部（ＤＡＳＨクライアント）４３２は、ＡＶセグメントを受信し再生する処理に併せて、チューナ実装受信装置ミドルウェア４２０が生成したイベント情報挿入ＭＰＤ、またはイベント情報セグメントを取得し、シグナリングデータとして緊急情報（ＡＥＡＴ）が送信されたことを検知し、シグナリングデータから緊急情報（ＡＥＡＴ）を取得して表示することが可能となる。
【０４４２】
なお、シグナリングデータ適用型緊急情報としてＡＥＡＴを例として説明したが、ＡＥＡＴ以外のフォーマットを持つ緊急情報であり、シグナリングデータを適用して送信される緊急情報については、どのようなフォーマットを持つ緊急情報であっても、本開示の処理を適用することができる。
【０４４３】
［９．イベント情報の転送専用のサーバとクライアントを有する構成例について］
次に、図１０、図１１を参照して説明したチューナ実装受信装置３０とチューナ非実装受信装置４０の構成を変更し、緊急情報関連イベント情報の送受信を実行する緊急情報関連イベント情報専用のサーバとクライアントを利用した構成例について説明する。
【０４４４】
図２８に示すように、チューナ実装受信装置３０のミドルウェア１１０に緊急情報関連イベントの転送処理を実行するイベント処理サーバ５０１を設け、チューナ実装受信装置３０とチューナ非実装受信装置４０の再生制御部（ＤＡＳＨクライアント）１３１，１５１と並列にイベント処理クライアント５１１，５２１を設ける。
【０４４５】
図２８に示す構成と、先に説明した図１０、図１１に示す構成との差異は以下の通りである。
（ａ）チューナ実装受信装置３０のミドルウェア１１０
（ａ１）緊急情報関連イベントの転送処理を実行するイベント処理サーバ５０１を追加、
（ａ２）図１０に示すインバンドイベント挿入部１１８の削除、
（ａ３）図１０に示すＳＬＳシグナリング解析部１１５のＭＰＤイベント挿入機能の削除
（ｂ）チューナ実装受信装置３０とチューナ非実装受信装置４０の再生制御部（ＤＡＳＨクライアント）１３１，１５１
（ｂ１）再生制御部（ＤＡＳＨクライアント）１３１，１５１と並列にイベント処理クライアント５１１，５２１を追加、
（ｂ２）図１１に示す再生制御部（ＤＡＳＨクライアント）１３１，１５１内のイベント抽出部２０５，２５５の削除、
図２８に示す構成のその他の構成は、先に説明した図１０、図１１と同一である。
【０４４６】
図２８に示す構成において、ＬＬＳシグナリング解析部１１３が、緊急情報に関する通知を含むシグナリングデータ（ＬＬＳ）を受信すると、そのシグナリングデータを、イベント処理サーバ５０１に転送する。
具体的には、例えば、先に図１２、図１３を参照して説明した通知データを含むシグナリングデータ（ＬＬＳ）である。
先に説明したように、図１２に示すデータは、
（ａ）オンスクリーンメッセージ型緊急情報配信通知データ（Ｏｎ  Ｓｃｒｅｅｎ  Ｍｅｓｓａｇｅ  Ｎｏｔｉｆｉｃａｔｉｏｎ）」を構成要素とするシグナリングデータ（ＬＬＳ）である。
また、図１３に示すデータは、
（ｂ）シグナリングデータ適用型緊急情報配信通知データ（ＡＥＡＴ  Ｍｅｓｓａｇｅ  Ｎｏｔｉｆｉｃａｔｉｏｎ）を構成要素とするシグナリングデータ（ＬＬＳ）である。
【０４４７】
図２８に示すミドルウェア１１０のＬＬＳシグナリング解析部１１３が、上記（ａ），（ｂ）いずれかの緊急情報に関する通知を含むシグナリングデータ（ＬＬＳ）を受信すると、そのシグナリングデータを、イベント処理サーバ５０１に転送する。
【０４４８】
イベント処理サーバ５０１は、ＬＬＳシグナリング解析部１１３から受領した、上記（ａ），（ｂ）いずれかの緊急情報に関する通知を含むシグナリングデータ（ＬＬＳ）に基づくイベント情報を生成して、生成したイベント情報をイベント処理クライアント５１１，５２１に転送する。
【０４４９】
なお、イベント処理サーバ５０１の生成するイベント情報は、
（ａ）オンスクリーンメッセージ型緊急情報配信通知データ（Ｏｎ  Ｓｃｒｅｅｎ  Ｍｅｓｓａｇｅ  Ｎｏｔｉｆｉｃａｔｉｏｎ）」を構成要素とするシグナリングデータ（ＬＬＳ）
（ｂ）シグナリングデータ適用型緊急情報配信通知データ（ＡＥＡＴ  Ｍｅｓｓａｇｅ  Ｎｏｔｉｆｉｃａｔｉｏｎ）を構成要素とするシグナリングデータ（ＬＬＳ）
これら（ａ），（ｂ）いずれかのデータを含むイベント情報である。
【０４５０】
なお、イベント処理サーバ５０１と、イベント処理クライアント５１１，５２１との間では、予め、緊急情報転送専用のセキュアセッションであるイベント情報中継セッションを確立し、常時接続状態が維持される。
イベント処理サーバ５０１は、は、このイベント情報中継セッションを介して、緊急情報に関する通知を含むシグナリングデータ（ＬＬＳ）に基づくイベント情報をイベント処理クライアント５１１，５２１に転送する。
【０４５１】
イベント処理クライアント５１１，５２１は、イベント処理サーバ５０１から受信したイベント情報を解析し、解析結果に従って必要な処理を実行する。
具体的には、受信したイベント情報が、
（ａ）オンスクリーンメッセージ型緊急情報配信通知（Ｏｎ  Ｓｃｒｅｅｎ  Ｍｅｓｓａｇｅ  Ｎｏｔｉｆｉｃａｔｉｏｎ）、
を含むイベント情報である場合には、アプリケーション制御部１３３，１５３に、このイベント情報を通知して、アプリケーション制御部１３３，１５３において実行中のアプリにより、アプリコンテンツの提示がなされている場合、その提示コンテンツの提示処理を中止させる処理を行なう。
【０４５２】
一方、受信したイベント情報が、
（ｂ）シグナリングデータ適用型緊急情報配信通知（ＡＥＡＴ  Ｍｅｓｓａｇｅ  Ｎｏｔｉｆｉｃａｔｉｏｎ）、
を含むイベント情報である場合には、緊急情報制御部１４０，１６０、あるいは、アプリケーション制御部１３３，１５３に、このイベント情報を通知して、緊急情報制御部１４０，１６０、あるいは、アプリケーション制御部１３３，１５３において、緊急情報（ＡＥＡＴ）の取得と緊急情報（ＡＥＡＴ）に含まれるメッセージ等の表示処理を実行させる処理を行なう。
【０４５３】
［９−１．オンスクリーンメッセージ型緊急情報配信通知に基づくイベント生成、転送、およびイベントに基づく処理の実行シーケンスについて］
次に、図２８に示すイベント処理サーバ５０１と、イベント処理クライアント５１１，５２１を有する構成を用いた具体的な処理シーケンスについて、説明する。
まず、図２９に示すシーケンス図を参照して、オンスクリーンメッセージ型緊急情報配信通知に基づくイベント生成、転送、およびイベントに基づく処理の実行シーケンスについて説明する。
【０４５４】
図２９には、以下の３つの装置を示している。
（１）送信装置４１０、
（２）チューナ実装受信装置ミドルウェア４２０、
（３）チューナ実装／非実装受信装置出力データ制御部４３０、
【０４５５】
なお、先に図２４、図２７を参照して説明した例では、ＡＶセグメントや、ＭＰＤ等の生成と出力を実行する様々な構成をめて説明したが、図２９に示すシーケンス図では、ＡＶセグメントやＭＰＤの生成、送信処理構成は省略し、緊急情報についての処理のみ示している。
図２８を参照して説明する緊急情報に対する処理に並行して、ＡＶセグメント、ＭＰＤの生成、送信、利用（再生）処理が実行される。
【０４５６】
まず、送信装置４１０の実行する処理について説明する。
（ステップＳ５０１）
まず、送信装置４１０の緊急情報サーバ４１３は、放送コンテンツを構成する画像に重畳して表示するための緊急情報を生成し、ストリームサーバ４１１の生成する画像に重畳する。
例えば、先に図５等を参照して説明したように、放送コンテンツの画像上に重畳して配信する緊急情報、すなわちオンスクリーンメッセージ型緊急情報を生成して、ストリームサーバ４１１の生成する画像に重畳する。
【０４５７】
（ステップＳ５０２）
次に、送信装置４１０の緊急情報サーバ４１３は、放送信号生成部（放送サーバ）４１４を介して、オンスクリーンメッセージ型緊急情報を放送コンテンツの画像上に重畳したことを示す通知を受信装置に出力する。
【０４５８】
これは、オンスクリーンメッセージ（ＯｎＳｃｒｅｅｎＭｅｓｓａｇｅ）型の緊急情報の配信がなされること（オンスクリーンメッセージ通知：Ｏｎ  Ｓｃｒｅｅｎ  Ｍｅｓｓａｇｅ  Ｎｏｔｉｆｉｃａｔｉｏｎ）を示すシグナリングデータ（ＬＬＳ：Ｌｏｗｅｒ  Ｌａｙｅｒ  Ｓｉｇｎａｌｉｎｇ）の送信処理である。
このシグナリングデータ送信は、放送ストリーム等の通信セッションとは異なるセッションを利用して実行される。
【０４５９】
次に、チューナ実装受信装置ミドルウェア４２０の処理について説明する。
チューナ実装受信装置ミドルウェア４２０は、イベント処理サーバ４２１を持つ。
イベント処理サーバ４２１は、図２８に示すチューナ実装受信装置３０のミドルウェア１１０内のイベント処理サーバ５０１に相当する。
【０４６０】
（ステップＳ５１１）
チューナ実装受信装置ミドルウェア４２０のイベント処理サーバ４２１は、ステップＳ５１１において、チューナ実装／非実装受信装置出力データ制御部４３０のイベント処理クライアント４３５（＝図２８に示すイベント処理クライアント５１１，５２１）との間で、緊急情報転送専用のセキュアセッションであるイベント情報中継セッションを確立する。
このセッションは、、常時接続状態が維持される。
【０４６１】
（ステップＳ５１２）
次に、イベント処理サーバ４２１は、送信装置４１０の送信した
「オンスクリーンメッセージ型緊急情報配信通知データ（Ｏｎ  Ｓｃｒｅｅｎ  Ｍｅｓｓａｇｅ  Ｎｏｔｉｆｉｃａｔｉｏｎ）」を構成要素とするシグナリングデータ（ＬＬＳ）」を入力する。
このシグナリンクデータ（ＬＬＳ）は、図２８に示すミドルウェア１１０のＬＬＳシグナリング解析部１１３を介して入力する。
【０４６２】
イベント処理サーバ４２１は、ＬＬＳシグナリング解析部１１３から受領した、上記の緊急情報に関する通知を含むシグナリングデータ（ＬＬＳ）に基づくイベント情報を生成して、生成したイベント情報をイベント処理クライアント４３５（＝図２８に示すイベント処理クライアント５１１，５２１）に転送する。
【０４６３】
次に、図２９の右側に示すチューナ実装／非実装受信装置出力データ制御部４３０の実行する処理について説明する。
図２９には、チューナ実装／非実装受信装置出力データ制御部４３０のアプリケーション制御部４３１、イベント処理クライアント４３５を示している。これらの構成は、図２８に示すチューナ実装受信装置３０とチューナ非実装受信装置４０のアプリケーション制御部１３３，１５３、イベント処理クライアント５１１，５２１の各構成に対応する。
【０４６４】
（ステップＳ５２１）
まず、チューナ実装／非実装受信装置出力データ制御部４３０のイベント処理クライアント４３５は、チューナ実装受信装置ミドルウェア４２０のイベント処理サーバ４２１との間で、緊急情報転送専用のセキュアセッションであるイベント情報中継セッションを確立する。
このセッションは、、常時接続状態が維持される。
【０４６５】
（ステップＳ５２２）
まず、チューナ実装／非実装受信装置出力データ制御部４３０のイベント処理クライアント４３５は、チューナ実装受信装置ミドルウェア４２０のイベント処理サーバ４２１から、
「オンスクリーンメッセージ型緊急情報配信通知データ（Ｏｎ  Ｓｃｒｅｅｎ  Ｍｅｓｓａｇｅ  Ｎｏｔｉｆｉｃａｔｉｏｎ）」を構成要素とするシグナリングデータ（ＬＬＳ）」に基づいて生成されたイベント情報入力する。
このイベント情報には、先に図１２を参照して説明した「オンスクリーンメッセージ型緊急情報配信通知データ（Ｏｎ  Ｓｃｒｅｅｎ  Ｍｅｓｓａｇｅ  Ｎｏｔｉｆｉｃａｔｉｏｎ）」の記録情報が含まれている。
【０４６６】
チューナ実装／非実装受信装置出力データ制御部４３０のイベント処理クライアント４３５は、チューナ実装受信装置ミドルウェア４２０のイベント処理サーバ４２１から入力したイベント情報をアプリケーション制御部４３１（＝図２８のアプリケーション制御部１３３，１５３）に転送する。
【０４６７】
（ステップＳ５２３）
次に、チューナ実装／非実装受信装置出力データ制御部４３０のアプリケーション制御部４３１は、ステップＳ５２３において、イベント処理クライアント４３５から受領したイベント情報に応じた処理を実行する。
【０４６８】
具体的には、アプリケーション制御部４３１は、アプリケーション提示コンテンツを表示部に表示している場合、そのアプリケーション提示コンテンツの表示を停止させる処理を行なう。
具体的には、例えば、先に図７を参照して説明した天気予報情報提示コンテンツ等の表示を停止させる。
この処理により、放送コンテンツの画像上に重畳されて配信される緊急情報をユーザ（視聴者）に確実に確認させることが可能となる。
【０４６９】
［９−２．シグナリングデータ適用型緊急情報配信通知に基づくイベント生成、転送、およびイベントに基づく処理の実行シーケンスについて］
次に、図３０に示すシーケンス図を参照して、シグナリングデータ適用型緊急情報配信通知（ＡＥＡＴ  Ｍｅｓｓａｇｅ  Ｎｏｔｉｆｉｃａｔｉｏｎ）に基づくイベント生成、転送、およびイベントに基づく処理の実行シーケンスについて説明する。
【０４７０】
図３０には、以下の３つの装置を示している。
（１）送信装置４１０、
（２）チューナ実装受信装置ミドルウェア４２０、
（３）チューナ実装／非実装受信装置出力データ制御部４３０、
【０４７１】
なお、図３０も、図２９と同様、ＡＶセグメントやＭＰＤの生成、送信処理構成は省略し、緊急情報についての処理のみ示している。
図３０を参照して説明する緊急情報に対する処理に並行して、ＡＶセグメント、ＭＰＤの生成、送信、利用（再生）処理が実行される。
【０４７２】
まず、送信装置４１０の実行する処理について説明する。
（ステップＳ６０１〜Ｓ６０２）
まず、送信装置４１０の緊急情報サーバ４１３は、ステップＳ６０１において、シグナリングデータとして送信する緊急情報（ＡＥＡＴ）を生成し、ステップＳ６０２において、放送信号生成部（放送サーバ）４１４を介して送信する。
【０４７３】
緊急情報サーバ４１３の生成する緊急情報は、例えば先に図１３を参照して説明したデータフォーマットを有する緊急情報（ＡＥＡＴ：Ａｄｖａｎｃｅｄ  Ｅｍｅｒｇｅｎｃｙ  Ａｌｅｒｔｉｎｇ  Ｔａｂｌｅ）である。
ＡＥＡＴには、例えば緊急情報としての緊急情報メッセージや、避難経路を示す地図情報などの表示用データ、あるいは表示用データのアクセス情報等が含まれる。
なお、このシグナリングデータ送信は、放送ストリーム等の通信セッションとは異なるセッションを利用して実行される。
【０４７４】
次に、チューナ実装受信装置ミドルウェア４２０の処理について説明する。
チューナ実装受信装置ミドルウェア４２０は、イベント処理サーバ４２１を持つ。
イベント処理サーバ４２１は、図２８に示すチューナ実装受信装置３０のミドルウェア１１０内のイベント処理サーバ５０１に相当する。
【０４７５】
（ステップＳ６１１）
チューナ実装受信装置ミドルウェア４２０のイベント処理サーバ４２１は、ステップＳ６１１において、チューナ実装／非実装受信装置出力データ制御部４３０のイベント処理クライアント４３５（＝図２８に示すイベント処理クライアント５１１，５２１）との間で、緊急情報転送専用のセキュアセッションであるイベント情報中継セッションを確立する。
このセッションは、、常時接続状態が維持される。
【０４７６】
（ステップＳ６１２）
次に、イベント処理サーバ４２１は、送信装置４１０の送信した
「シグナリングデータ適用型緊急情報配信通知（ＡＥＡＴ  Ｍｅｓｓａｇｅ  Ｎｏｔｉｆｉｃａｔｉｏｎ）」を構成要素とするシグナリングデータ（ＬＬＳ）」を入力する。
このシグナリンクデータ（ＬＬＳ）は、図２８に示すミドルウェア１１０のＬＬＳシグナリング解析部１１３を介して入力する。
【０４７７】
イベント処理サーバ４２１は、ＬＬＳシグナリング解析部１１３から受領した、上記の緊急情報に関する通知を含むシグナリングデータ（ＬＬＳ）に基づくイベント情報を生成して、生成したイベント情報をイベント処理クライアント４３５（＝図２８に示すイベント処理クライアント５１１，５２１）に転送する。
【０４７８】
（ステップＳ６１３）
ステップＳ６１３の処理は、チューナ実装受信装置ミドルウェア４２０のイベント処理サーバ４２１が、ステップＳ６１２で、チューナ実装／非実装受信装置出力データ制御部４３０のイベント書クライアント４３５に転送した、イベント情報に、緊急情報として出力するメッセージや地図等の出力用データが含まれていない場合に実行される処理である。
【０４７９】
この場合、チューナ実装受信装置ミドルウェア４２０のイベント処理サーバ４２１は、イベント処理クライアント４３５からの緊急情報（ＡＥＡＴ）取得要求に応じて、出力用データを含む緊急情報（ＡＥＡＴ）をイベント処理クライアント４３５に転送する。
【０４８０】
次に、図３０の右側に示すチューナ実装／非実装受信装置出力データ制御部４３０の実行する処理について説明する。
図３０には、チューナ実装／非実装受信装置出力データ制御部４３０の緊急情報制御部４３３、イベント処理クライアント４３５を示している。これらの構成は、図２８に示すチューナ実装受信装置３０とチューナ非実装受信装置４０の緊急情報制御部１４０，１６０と、イベント処理クライアント５１１，５２１の各構成に対応する。
【０４８１】
なお、この図３０に示す例では、緊急情報制御部４３３が緊急情報（ＡＥＡＴ）に含まれる緊急メッセージや地図等のデータレンダリングを実行する設定としているが、例えば、図２８に示すアプリケーション制御部１３３，１５３が、緊急情報（ＡＥＡＴ）に含まれる緊急メッセージや地図等のデータレンダリングを実行することも可能である。
すなわち、図３０に示す緊急情報制御部４３３をアプリケーション制御部に置き換えることも可能である。
【０４８２】
（ステップＳ６２１）
まず、チューナ実装／非実装受信装置出力データ制御部４３０のイベント処理クライアント４３５は、チューナ実装受信装置ミドルウェア４２０のイベント処理サーバ４２１との間で、緊急情報転送専用のセキュアセッションであるイベント情報中継セッションを確立する。
このセッションは、、常時接続状態が維持される。
【０４８３】
（ステップＳ６２２）
まず、チューナ実装／非実装受信装置出力データ制御部４３０のイベント処理クライアント４３５は、チューナ実装受信装置ミドルウェア４２０のイベント処理サーバ４２１から、
「シグナリングデータ適用型緊急情報配信通知（ＡＥＡＴ  Ｍｅｓｓａｇｅ  Ｎｏｔｉｆｉｃａｔｉｏｎ）」を構成要素とするシグナリングデータ（ＬＬＳ）」に基づいて生成されたイベント情報入力する。
このイベント情報には、先に図１３を参照して説明した「シグナリングデータ適用型緊急情報配信通知（ＡＥＡＴ  Ｍｅｓｓａｇｅ  Ｎｏｔｉｆｉｃａｔｉｏｎ）」の記録情報が含まれている。
【０４８４】
チューナ実装／非実装受信装置出力データ制御部４３０のイベント処理クライアント４３５は、チューナ実装受信装置ミドルウェア４２０のイベント処理サーバ４２１から入力したイベント情報を緊急情報制御部４３３（＝図２８の緊急情報制御部１４０，１６０）に転送する。
【０４８５】
このイベント情報には、例えば以下のデータが含まれる。
（１）緊急情報（ＡＥＡＴ）データ、または緊急情報（ＡＥＡＴ）データアクセス用ＵＲＬ、
（２）緊急情報（ＡＥＡＴ）の配信開始時間、継続時間、
これらのデータが記録されている。
【０４８６】
（ステップＳ６２３〜Ｓ６２４）
次に、チューナ実装／非実装受信装置出力データ制御部４３０の緊急情報制御部４３３は、ステップＳ６２３において、イベント処理クライアント４３５から受領したイベント情報を取得し、ステップＳ６２４において、緊急情報（ＡＥＡＴ）データを表示部に出力する処理を実行する。
【０４８７】
なお、イベント処理クライアント４３５から受領したイベント情報に、出力（表示）用の緊急情報（ＡＥＡＴ）データが含まれている場合は、受領したイベント情報から緊急情報（ＡＥＡＴ）を取得して、ステップＳ４２３において緊急情報（ＡＥＡＴ）に含まれる緊急メッセージや地図情報等を表示する。
【０４８８】
一方、イベント処理クライアント４３５から受領したイベント情報に緊急情報（ＡＥＡＴ）のアクセス情報が記録され、出力（表示）用の緊急情報（ＡＥＡＴ）データが含まれていない場合には、アクセス情報を利用して、チューナ実装受信装置ミドルウェア４２０のイベント処理サーバ４２１から緊急情報（ＡＥＡＴ）を取得する処理を実行した後、ステップＳ６２４において、取得した緊急情報（ＡＥＡＴ）に含まれる緊急メッセージや地図情報等を表示する。
【０４８９】
このように、チューナ実装／非実装受信装置出力データ制御部４３０のイベント処理クライアント４３５は、チューナ実装受信装置ミドルウェア４２０のイベント処理サーバ４２１が生成したイベント情報を取得し、緊急情報（ＡＥＡＴ）を取得して表示することが可能となる。
【０４９０】
なお、シグナリングデータ適用型緊急情報としてＡＥＡＴを例として説明したが、ＡＥＡＴ以外のフォーマットを持つ緊急情報であり、シグナリングデータを適用して送信される緊急情報については、どのようなフォーマットを持つ緊急情報であっても、本開示の処理を適用することができる。
【０４９１】
［１０．送信装置と受信装置の構成例について］
次に、通信装置である送信装置（サーバ）２０と、受信装置（クライアント）３０，４０の装置構成例について、図３１、図３２を参照して説明する。
【０４９２】
図３１には、送信装置（サーバ）２０と、受信装置（クライアント）３０の構成例を示している。
送信装置（サーバ）２０は、データ処理部７５１、通信部７５２、記憶部７５３を有する。
受信装置（クライアント）３０，４０は、通信部７７１、通信データ処理部７７２、出力データ処理部７７３、記憶部７７４、入力部７７５、出力部７７６を有する。
【０４９３】
送信装置（サーバ）２０のデータ処理部７５１は、データ配信サービスを実行するための各種のデータ処理を実行する。例えばデータ配信サービスの構成データの生成や送信制御を行う。さらに、データ処理部７５１は、受信装置（クライアント）３０に提供する放送コンテンツ等のＡＶストリームデータの他、アプリケーション、緊急情報、シグナリングデータ、その他の様々なデータの生成、送信処理を行う。
【０４９４】
通信部７５２は、放送コンテンツ等のＡＶストリームデータの他、アプリケーション、緊急情報、シグナリングデータ、その他の様々なデータの配信等の通信処理を行う。
記憶部７５３は配信対象とする放送コンテンツ等のＡＶストリームデータの他、アプリケーション、緊急情報、シグナリングデータ、その他の様々なデータなどが格納される。
さらに、記憶部７５３は、データ処理部７５１の実行するデータ処理のワークエリアとして利用され、また各種パラメータの記憶領域としても利用される。
【０４９５】
一方、受信装置（クライアント）３０，４０は、通信部７７１、通信データ処理部７７２、出力データ処理部７７３、記憶部７７４、入力部７７５、出力部７７６を有する。
【０４９６】
通信部７７１は、チューナ実装受信装置３０の通信部と、チューナ非実装受信装置４０の場合とで異なる設定となる。
チューナ実装受信装置３０の通信部は、送信装置（サーバ）２０から配信されるデータ、例えば放送コンテンツ等のＡＶストリームデータの他、アプリケーション、緊急情報、シグナリングデータ、その他の様々なデータ等を受信する。
さらに、ＬＡＮ、Ｗｉ−Ｆｉ等のネットワークを介したデータ送受信が可能な通信部として構成される。
一方、チューナ非実装受信装置４０の通信部は、放送波を受信可能なチューナ部は持たず、ＬＡＮ，Ｗｉ−Ｆｉ等のネットワークを介したデータ送受信を実行絵可能な通信部として構成される。
【０４９７】
通信データ処理部７７２は、図１０他に示す通信データ処理部７７２のミドルウェア１１０に相当する。
シグナリングデータの取得、解析、イベント情報の生成、イベント挿入ＭＰＤ、イベント挿入セグメント等の生成等の処理を実行する。
図２８を参照して説明したイベント処理サーバ５０１が含まれる場合もある。
【０４９８】
出力データ処理部７７３は、再生制御部（ＤＡＳＨクライアント）、出力制御部、アプリケーション制御部、緊急情報制御部、イベント処理クライアント等によって構成され、例えば先に説明した実施例に従った処理等を実行する。
具体的には、放送コンテンツの出力制御の他、緊急情報の出力制御、アプリケーション提示コンテンツの表示制御処理等を実行する。
【０４９９】
ユーザの指示コマンド、例えばチャンネル選択、アプリケーション起動、インストール等の様々なコマンドは入力部７７５を介して入力される。
再生データは表示部やスピーカ等の出力部７７６に出力される。
記憶部７７４はＡＶセグメント、ＭＰＤ、近況情報、シグナリングデータなどが格納される。
さらに、記憶部７７４は、データ処理部７７１の実行するデータ処理のワークエリアとして利用され、また各種パラメータの記憶領域としても利用される。
【０５００】
図３２は、送信装置２０、受信装置３０として適用可能な通信装置のハードウェア構成例を示している。
【０５０１】
ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）８０１は、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）８０２、または記憶部８０８に記憶されているプログラムに従って各種の処理を実行するデータ処理部として機能する。例えば、上述した実施例において説明したシーケンスに従った処理を実行する。ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）８０３には、ＣＰＵ８０１が実行するプログラムやデータなどが記憶される。これらのＣＰＵ８０１、ＲＯＭ８０２、およびＲＡＭ８０３は、バス８０４により相互に接続されている。
【０５０２】
ＣＰＵ８０１はバス８０４を介して入出力インタフェース８０５に接続され、入出力インタフェース８０５には、各種スイッチ、キーボード、マウス、マイクロホンなどよりなる入力部８０６、ディスプレイ、スピーカなどよりなる出力部８０７が接続されている。ＣＰＵ８０１は、入力部８０６から入力される指令に対応して各種の処理を実行し、処理結果を例えば出力部８０７に出力する。
【０５０３】
入出力インタフェース８０５に接続されている記憶部８０８は、例えばハードディスク等からなり、ＣＰＵ８０１が実行するプログラムや各種のデータを記憶する。通信部８０９は、インターネットやローカルエリアネットワークなどのネットワークを介したデータ通信の送受信部、さらに放送波の送受信部として機能し、外部の装置と通信する。
【０５０４】
入出力インタフェース８０５に接続されているドライブ８１０は、磁気ディスク、光ディスク、光磁気ディスク、あるいはメモリカード等の半導体メモリなどのリムーバブルメディア８１１を駆動し、データの記録あるいは読み取りを実行する。
【０５０５】
なお、データの符号化あるいは復号は、データ処理部としてのＣＰＵ８０１の処理として実行可能であるが、符号化処理あるいは復号処理を実行するための専用ハードウェアとしてのコーデックを備えた構成としてもよい。
【０５０６】
［１１．本開示の構成のまとめ］
以上、特定の実施例を参照しながら、本開示の実施例について詳解してきた。しかしながら、本開示の要旨を逸脱しない範囲で当業者が実施例の修正や代用を成し得ることは自明である。すなわち、例示という形態で本発明を開示してきたのであり、限定的に解釈されるべきではない。本開示の要旨を判断するためには、特許請求の範囲の欄を参酌すべきである。
【０５０７】
なお、本明細書において開示した技術は、以下のような構成をとることができる。
（１）  送信装置からの受信データの解析処理を実行するミドルウェアと、
前記送信装置からの受信データの出力制御処理を実行する出力データ制御部を有し、
前記ミドルウェアは、
送信装置の送信する緊急情報配信通知を受信し、受信した緊急情報配信通知の構成データを含む緊急情報イベント通知データを生成し、
前記出力データ制御部は、
前記イベント通知データを取得し、取得したイベント通知データに基づいて、緊急情報の取得、または表示処理を実行する受信装置。
【０５０８】
（２）  送信装置の送信する緊急情報配信通知は、
前記送信装置の送信画像上に重畳された緊急情報の配信を通知するオンスクリーンメッセージ型緊急情報配信通知であり、
前記ミドルウェアは、
オンスクリーンメッセージ型緊急情報配信通知がなされたことを示す緊急情報イベント通知データを生成し、
前記出力データ制御部を構成するアプリケーション制御部は、
取得した緊急情報イベント通知データに基づいて、表示部に対するアプリケーション提示コンテンツの出力を停止して、前記送信装置の送信画像上に重畳された緊急情報を視認可能とする制御を実行する（１）に記載の受信装置。
【０５０９】
（３）  送信装置の送信する緊急情報配信通知は、
前記送信装置から送信されるシグナリングデータによる緊急情報の配信を通知するシグナリングデータ適用型緊急情報配信通知であり、
前記ミドルウェアは、
シグナリングデータ適用型緊急情報配信通知がなされたことを示す緊急情報イベント通知データを生成し、
前記出力データ制御部は、
取得した緊急情報イベント通知データに含まれる緊急情報を表示部出力する処理、
または、取得した緊急情報イベント通知データに含まれる緊急情報アクセス情報を利用して取得した緊急情報を表示部に出力する処理のいずれかを実行する（１）または（２）に記載の受信装置。
【０５１０】
（４）  前記シグナリングデータ適用型緊急情報配信通知は、
緊急情報の規格として規定されたＡＥＡＴ（Ａｄｖａｎｃｅｄ  Ｅｍｅｒｇｅｎｃｙ  Ａｌｅｒｔｉｎｇ  Ｔａｂｌｅ）を含む通知である（３）に記載の受信装置。
【０５１１】
（５）  前記ミドルウェアは、
前記前記緊急情報イベント通知データとして、
前記緊急情報配信通知の構成データを、ＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）に挿入した緊急情報イベント挿入ＭＰＤを生成し、
前記出力データ制御部は、
前記緊急情報イベント挿入ＭＰＤからの取得情報に基づいて、緊急情報の取得、または表示処理を実行する（１）〜（４）いずれかに記載の受信装置。
【０５１２】
（６）  前記ミドルウェアは、
前記出力データ制御部に、前記緊急情報イベント挿入ＭＰＤを遅滞なく取得させるための事前処理として、
前記出力データ制御部に対してＭＰＤ更新通知を出力する（５）に記載の受信装置。
【０５１３】
（７）  前記ミドルウェアは、
前記緊急情報イベント通知データとして、
前記緊急情報配信通知の構成データを、セグメントに挿入した緊急情報イベント挿入セグメントを生成し、
前記出力データ制御部は、
前記緊急情報イベント挿入セグメントからの取得情報に基づいて、緊急情報の取得、または表示処理を実行する（１）〜（６）いずれかに記載の受信装置。
【０５１４】
（８）  前記ミドルウェアは、
生成した緊急情報イベント通知データをキャッシュ部に格納し、
前記出力データ制御部は、
前記キャッシュ部をアクセスして、前記イベント通知データを取得する（１）〜（７）いずれかに記載の受信装置。
【０５１５】
（９）  前記ミドルウェアは、
前記緊急情報イベント通知データを生成し、送信するイベント処理サーバを有し、
前記出力データ制御部は、
前記緊急情報イベント通知データを、前記イベント処理サーバから受信するイベント処理クライアントを有し、
前記イベント処理クライアントは、前記イベント処理サーバと間でイベント転送専用のセッションを確立して、確立した専用セッションを介して前記緊急情報イベント通知データを前記イベント処理サーバから受信する（１）〜（４）いずれかに記載の受信装置。
【０５１６】
（１０）  送信装置からの受信データの解析処理を実行するミドルウェアを有し、
前記ミドルウェアは、
送信装置の送信する緊急情報配信通知を受信し、受信した緊急情報配信通知の構成データを含む緊急情報イベント通知データを生成し、
生成した緊急情報イベント通知データを、前記送信装置からの受信データの出力制御処理を実行するクライアントに提供する受信装置。
【０５１７】
（１１）  送信装置の送信する緊急情報配信通知は、
前記送信装置の送信画像上に重畳された緊急情報の配信を通知するオンスクリーンメッセージ型緊急情報配信通知であり、
前記ミドルウェアは、
オンスクリーンメッセージ型緊急情報配信通知がなされたことを示す緊急情報イベント通知データを生成する（１０）に記載の受信装置。
【０５１８】
（１２）  送信装置の送信する緊急情報配信通知は、
前記送信装置から送信されるシグナリングデータによる緊急情報の配信を通知するシグナリングデータ適用型緊急情報配信通知であり、
前記ミドルウェアは、
シグナリングデータ適用型緊急情報配信通知がなされたことを示す緊急情報イベント通知データを生成する（１０）または（１１）に記載の受信装置。
【０５１９】
（１３）  前記ミドルウェアは、
前記前記緊急情報イベント通知データとして、
前記緊急情報配信通知の構成データを、ＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）に挿入した緊急情報イベント挿入ＭＰＤを生成する（１０）〜（１２）いずれかに記載の受信装置。
【０５２０】
（１４）  前記ミドルウェアは、
前記緊急情報イベント通知データとして、
前記緊急情報配信通知の構成データを、セグメントに挿入した緊急情報イベント挿入セグメントを生成する（１０〜（１３）いずれかに記載の受信装置。
【０５２１】
（１５）  送信装置からの受信データの出力制御処理を実行する出力データ制御部を有し、
前記出力データ制御部は、
前記送信装置の送信する緊急情報配信通知の構成データを含む緊急情報イベント通知データを取得し、
取得したイベント通知データに基づいて、緊急情報の取得、または表示処理を実行する受信装置。
【０５２２】
（１６）  送信装置の送信する緊急情報配信通知は、
前記送信装置の送信画像上に重畳された緊急情報の配信を通知するオンスクリーンメッセージ型緊急情報配信通知であり、
前記出力データ制御部は、
オンスクリーンメッセージ型緊急情報配信通知がなされたことを示す緊急情報イベント通知データを取得し、
前記出力データ制御部を構成するアプリケーション制御部は、
取得した緊急情報イベント通知データに基づいて、表示部に対するアプリケーション提示コンテンツの出力を停止して、前記送信装置の送信画像上に重畳された緊急情報を視認可能とする制御を実行する（１５）に記載の受信装置。
【０５２３】
（１７）  送信装置の送信する緊急情報配信通知は、
前記送信装置から送信されるシグナリングデータによる緊急情報の配信を通知するシグナリングデータ適用型緊急情報配信通知であり、
前記出力データ制御部は、
シグナリングデータ適用型緊急情報配信通知がなされたことを示す緊急情報イベント通知データを取得し、
取得した緊急情報イベント通知データに含まれる緊急情報を表示部出力する処理、
または、取得した緊急情報イベント通知データに含まれる緊急情報アクセス情報を利用して取得した緊急情報を表示部に出力する処理のいずれかを実行する（１５）または（１６）に記載の受信装置。
【０５２４】
（１８）  受信装置において実行するデータ処理方法であり、
前記受信装置は、
送信装置からの受信データの解析処理を実行するミドルウェアと、
前記送信装置からの受信データの出力制御処理を実行する出力データ制御部を有し、
前記ミドルウェアが、
送信装置の送信する緊急情報配信通知を受信し、受信した緊急情報配信通知の構成データを含む緊急情報イベント通知データを生成し、
前記出力データ制御部が、
前記イベント通知データを取得し、取得したイベント通知データに基づいて、緊急情報の取得、または表示処理を実行するデータ処理方法。
【０５２５】
（１９）  受信装置において実行するデータ処理方法であり、
前記受信装置は、
送信装置からの受信データの解析処理を実行するミドルウェアを有し、
前記ミドルウェアが、
送信装置の送信する緊急情報配信通知を受信し、受信した緊急情報配信通知の構成データを含む緊急情報イベント通知データを生成し、
生成した緊急情報イベント通知データを、前記送信装置からの受信データの出力制御処理を実行するクライアントに提供するデータ処理方法。
【０５２６】
（２０）  受信装置において実行するデータ処理方法であり、
前記受信装置は、
送信装置からの受信データの出力制御処理を実行する出力データ制御部を有し、
前記出力データ制御部が、
前記送信装置の送信する緊急情報配信通知の構成データを含む緊急情報イベント通知データを取得し、
取得したイベント通知データに基づいて、緊急情報の取得、または表示処理を実行するデータ処理方法。
【０５２７】
また、明細書中において説明した一連の処理はハードウェア、またはソフトウェア、あるいは両者の複合構成によって実行することが可能である。ソフトウェアによる処理を実行する場合は、処理シーケンスを記録したプログラムを、専用のハードウェアに組み込まれたコンピュータ内のメモリにインストールして実行させるか、あるいは、各種処理が実行可能な汎用コンピュータにプログラムをインストールして実行させることが可能である。例えば、プログラムは記録媒体に予め記録しておくことができる。記録媒体からコンピュータにインストールする他、ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、インターネットといったネットワークを介してプログラムを受信し、内蔵するハードディスク等の記録媒体にインストールすることができる。
【０５２８】
なお、明細書に記載された各種の処理は、記載に従って時系列に実行されるのみならず、処理を実行する装置の処理能力あるいは必要に応じて並列的にあるいは個別に実行されてもよい。また、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。
【産業上の利用可能性】
【０５２９】
以上、説明したように、本開示の一実施例の構成によれば、緊急情報の迅速、かつ確実な視聴者への提示処理を可能とした構成が実現される。
具体的には、例えば、放送コンテンツ出力処理を行なう受信装置のミドルウェアが、送信装置の送信する緊急情報配信通知を受信し、受信した緊急情報配信通知の構成データを含む緊急情報イベント通知データを生成する。出力データ制御部は、イベント通知データを取得し、取得したイベント通知データに基づいて、緊急情報の取得、または表示処理を実行する。例えば、画像上に重畳された緊急情報が配信される場合は、イベント通知により、アプリ提示コンテンツの除去を実行させ、シグナリング緊急情報配信の場合は、迅速な緊急情報の取得、出力処理を実行させる。
本構成により、緊急情報の迅速、かつ確実な視聴者への提示処理を可能とした構成が実現される。
【符号の説明】
【０５３０】
１０  通信システム
２０  送信装置
２１  放送サーバ
２２  データ配信サーバ
３０  チューナ実装受信装置
３１  中継サーバ
３２  ＴＶ
３３  ＰＣ
３４  携帯端末
４０  チューナ非実装受信装置
４１  ＰＣ
４２  携帯端末
５０  シグナリングデータ
６０  ＡＶセグメント
７０  その他のデータ
１１０  ミドルウェア
１１１  通信部（ＰＨＹ／ＭＡＣ）
１１２  ＬＬＳシグナリング取得部
１１３  ＬＬＳシグナリング解析部
１１４  ＳＬＳシグナリング取得部
１１５  ＳＬＳシグナリング解析部（ＭＰＤイベント挿入部）
１１７  セグメント取得部
１１８  インバンドイベント挿入部
１２０  ＨＴＴＰプロキシサーバ
１２１，１２２  キャッシュ部
１２３  アドレス解決部
１３１，１５１  再生制御部
１３２，１５２  出力制御部
１３３，１５３  アプリケーション制御部
１４０，１６０  緊急情報制御部
２０１，２５１  ＭＰＤ取得部
２０２，２５２  ＭＰＤ解析部
２０３，２５３  セグメント取得部
２０４，２５４  セグメント解析部
２０５，２５５  イベント抽出部
２１１，２６１  復号部
２１２，２６２  出力部
３１０  イベント挿入実行装置
３１１  データ出力部（ＤＡＳＨサーバ）
３１２  イベント処理部（イベントサーバ）
３２０  イベント実行装置
３２１  再生制御部（イベントクライアント）
３２２  再生制御部（ＤＡＳＨクライアント）
４１０  送信装置
４１１  ストリームサーバ
４１２  ＤＡＳＨサーバ
４１３  緊急情報サーバ
４１４  放送信号処理部（放送サーバ）
４２０  チューナ受信装置ミドルウェア
４２１  イベント処理サーバ
４３０  チューナ実装／非実装受信装置出力データ制御部
４３１  アプリケーション制御部
４３２  再生制御部
４３３  緊急情報制御部
４３５  イベント処理クライアント
５０１  イベント処理サーバ
５１１，５２１  イベント処理クライアント
７５１  データ処理部
７５２  通信部
７５３  記憶部
７７１  通信部
７７２  通信データ処理部
７７３  出力データ処理部
７７４  記憶部
７７５  入力部
７７６  出力部
８０１  ＣＰＵ
８０２  ＲＯＭ
８０３  ＲＡＭ
８０４  バス
８０５  入出力インタフェース
８０６  入力部
８０７  出力部
８０８  記憶部
８０９  通信部
８１０  ドライブ
８１１  リムーバブルメディア
【図１】
2018016295.tif 000003
【図２】
2018016295.tif 000004
【図３】
2018016295.tif 000005
【図４】
2018016295.tif 000006
【図５】
2018016295.tif 000007
【図６】
2018016295.tif 000008
【図７】
2018016295.tif 000009
【図８】
2018016295.tif 000010
【図９】
2018016295.tif 000011
【図１０】
2018016295.tif 000012
【図１１】
2018016295.tif 000013
【図１２】
2018016295.tif 000014
【図１３】
2018016295.tif 000015
【図１４】
2018016295.tif 000016
【図１５】
2018016295.tif 000017
【図１６】
2018016295.tif 000018
【図１７】
2018016295.tif 000019
【図１８】
2018016295.tif 000020
【図１９】
2018016295.tif 000021
【図２０】
2018016295.tif 000022
【図２１】
2018016295.tif 000023
【図２２】
2018016295.tif 000024
【図２３】
2018016295.tif 000025
【図２４】
2018016295.tif 000026
【図２５】
2018016295.tif 000027
【図２６】
2018016295.tif 000028
【図２７】
2018016295.tif 000029
【図２８】
2018016295.tif 000030
【図２９】
2018016295.tif 000031
【図３０】
2018016295.tif 000032
【図３１】
2018016295.tif 000033
【図３２】
2018016295.tif 000034
【国際調査報告】
2018016295.tif 000035
2018016295.tif 000036
2018016295.tif 000037
2018016295.tif 000038