(57)【要約】  本技術は、緊急時に通知される緊急情報の詳細情報を提供することができるようにする受信装置、送信装置、及び、データ処理方法に関する。受信装置は、デジタル放送信号を受信し、デジタル放送信号に含まれる制御情報であって、緊急に告知する必要がある緊急情報の詳細情報に関する情報を含む制御情報に基づいて、緊急情報の詳細情報を提示する緊急情報アプリケーションに関する処理を行う。本技術は、例えば、テレビ受像機に適用することができる。
2017047397.tif 000002
【特許請求の範囲】
【請求項１】
デジタル放送信号を受信する受信部と、
前記デジタル放送信号に含まれる制御情報であって、緊急に告知する必要がある緊急情報の詳細情報に関する情報を含む前記制御情報に基づいて、前記緊急情報の詳細情報を提示する緊急情報アプリケーションに関する処理を行う処理部と
を備える受信装置。
【請求項２】
前記制御情報は、前記緊急情報の緊急性、重大性、対象地域、カテゴリ、及び、優先度を示す情報のうちの少なくとも１つの情報を含み、
前記処理部は、前記制御情報に基づいて、前記緊急情報アプリケーションを起動するかどうかを判定する
請求項１に記載の受信装置。
【請求項３】
前記処理部は、
前記制御情報に基づいて、前記緊急情報の詳細情報を提示するかどうかの選択情報を表示し、
ユーザによって、前記緊急情報の詳細情報の提示が選択された場合、前記緊急情報アプリケーションを起動する
請求項２に記載の受信装置。
【請求項４】
前記処理部は、あらかじめユーザにより設定される設定情報に基づいて、前記緊急情報アプリケーションを起動する
請求項２に記載の受信装置。
【請求項５】
前記制御情報は、前記緊急情報アプリケーションのライフサイクルを制御するためのコマンドをさらに含み、
前記処理部は、前記制御情報に基づいて、前記緊急情報アプリケーションの動作を制御する
請求項２に記載の受信装置。
【請求項６】
前記処理部は、
前記制御情報に含まれるコマンドが、前記緊急情報アプリケーションの起動を示している場合であって、前記緊急情報アプリケーションを起動する場合に、通常時に実行される放送アプリケーションが起動されているとき、前記緊急情報アプリケーションを起動させるとともに、前記放送アプリケーションを一時停止又は終了させる制御を行い、
前記制御情報に含まれるコマンドが、前記緊急情報アプリケーションの終了を示している場合に、前記緊急情報アプリケーションが起動しているとき、前記緊急情報アプリケーションを終了させる制御を行う
請求項５に記載の受信装置。
【請求項７】
前記処理部は、前記制御情報に含まれるコマンドが、前記緊急情報アプリケーションの終了を示している場合に、前記放送アプリケーションが一時停止となっているとき、一時停止中の前記放送アプリケーションの動作を再開させる制御を行う
請求項６に記載の受信装置。
【請求項８】
前記処理部は、前記デジタル放送信号に含まれるイベントメッセージに基づいて、所定のタイミングで、前記緊急情報アプリケーションに関する処理を実行する
請求項２に記載の受信装置。
【請求項９】
前記イベントメッセージは、MPEG-DASH(Dynamic Adaptive Streaming over HTTP)で規定されるMPD(Media Presentation Description)のイベントストリーム要素、又は、DASHセグメントのイベントメッセージボックスに配置される
請求項８に記載の受信装置。
【請求項１０】
前記デジタル放送信号は、IP(Internet Protocol)伝送方式のデジタル放送信号であり、
前記制御情報は、IPパケットに含まれるUDP(User Datagram Protocol)パケットのペイロードに配置されて伝送される
請求項１に記載の受信装置。
【請求項１１】
受信装置のデータ処理方法において、
前記受信装置が、
デジタル放送信号を受信し、
前記デジタル放送信号に含まれる制御情報であって、緊急に告知する必要がある緊急情報の詳細情報に関する情報を含む前記制御情報に基づいて、前記緊急情報の詳細情報を提示する緊急情報アプリケーションに関する処理を行う
ステップを含むデータ処理方法。
【請求項１２】
緊急に告知する必要がある緊急情報の詳細情報に関する情報を含む制御情報であって、前記緊急情報の詳細情報を提示する緊急情報アプリケーションに関する処理に用いられる前記制御情報を生成する生成部と、
生成された前記制御情報を、デジタル放送信号に含めて送信する送信部と
を備える送信装置。
【請求項１３】
前記制御情報は、前記緊急情報の緊急性、重大性、対象地域、カテゴリ、及び、優先度を示す情報のうちの少なくとも１つの情報を含む
請求項１２に記載の送信装置。
【請求項１４】
前記制御情報は、前記緊急情報アプリケーションのライフサイクルを制御するためのコマンドをさらに含む
請求項１３に記載の送信装置。
【請求項１５】
前記生成部は、所定のタイミングで、前記緊急情報アプリケーションに関する処理を実行させるためのイベントメッセージを生成し、
前記送信部は、生成された前記イベントメッセージを、前記デジタル放送信号に含めて送信する
請求項１３に記載の送信装置。
【請求項１６】
前記イベントメッセージは、MPEG-DASHで規定されるMPDのイベントストリーム要素、又は、DASHセグメントのイベントメッセージボックスに配置される
請求項１５に記載の送信装置。
【請求項１７】
前記デジタル放送信号は、IP伝送方式のデジタル放送信号であり、
前記制御情報は、IPパケットに含まれるUDPパケットのペイロードに配置されて伝送される
請求項１２に記載の送信装置。
【請求項１８】
送信装置のデータ処理方法において、
前記送信装置が、
緊急に告知する必要がある緊急情報の詳細情報に関する情報を含む制御情報であって、前記緊急情報の詳細情報を提示する緊急情報アプリケーションに関する処理に用いられる前記制御情報を生成し、
生成された前記制御情報を、デジタル放送信号に含めて送信する
ステップを含むデータ処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本技術は、受信装置、送信装置、及び、データ処理方法に関し、特に、緊急時に通知される緊急情報の詳細情報を提供することができるようにした受信装置、送信装置、及び、データ処理方法に関する。
【背景技術】
【０００２】
デジタル放送の分野では、緊急時において、緊急に告知する必要がある情報である緊急情報を通知するための各種の提案が行われている（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１５−１０４０５５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ところで、緊急時に通知される緊急情報として、テキストなどの簡易的な情報とは別に、静止画や動画などのより詳細な情報も提供できるようにするための提案が要請されていた。【０００５】
本技術はこのような状況に鑑みてなされたものであり、緊急時に通知される緊急情報の詳細情報を提供することができるようにするものである。
【課題を解決するための手段】
【０００６】
本技術の第１の側面の受信装置は、デジタル放送信号を受信する受信部と、前記デジタル放送信号に含まれる制御情報であって、緊急に告知する必要がある緊急情報の詳細情報に関する情報を含む前記制御情報に基づいて、前記緊急情報の詳細情報を提示する緊急情報アプリケーションに関する処理を行う処理部とを備える受信装置である。【０００７】
本技術の第１の側面の受信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第１の側面のデータ処理方法は、上述した本技術の第１の側面の受信装置に対応するデータ処理方法である。【０００８】
本技術の第１の側面の受信装置、及び、データ処理方法においては、デジタル放送信号が受信され、前記デジタル放送信号に含まれる制御情報であって、緊急に告知する必要がある緊急情報の詳細情報に関する情報を含む前記制御情報に基づいて、前記緊急情報の詳細情報を提示する緊急情報アプリケーションに関する処理が行われる。【０００９】
本技術の第２の側面の送信装置は、緊急に告知する必要がある緊急情報の詳細情報に関する情報を含む制御情報であって、前記緊急情報の詳細情報を提示する緊急情報アプリケーションに関する処理に用いられる前記制御情報を生成する生成部と、生成された前記制御情報を、デジタル放送信号に含めて送信する送信部とを備える送信装置である。【００１０】
本技術の第２の側面の送信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第２の側面のデータ処理方法は、上述した本技術の第２の側面の送信装置に対応するデータ処理方法である。【００１１】
本技術の第２の側面の送信装置、及び、データ処理方法においては、緊急に告知する必要がある緊急情報の詳細情報に関する情報を含む制御情報であって、前記緊急情報の詳細情報を提示する緊急情報アプリケーションに関する処理に用いられる前記制御情報が生成され、生成された前記制御情報が、デジタル放送信号に含めて送信される。
【発明の効果】
【００１２】
本技術の第１の側面、及び、第２の側面によれば、緊急時に通知される緊急情報の詳細情報を提供することができる。【００１３】
なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。
【図面の簡単な説明】
【００１４】
【図１】本技術を適用した伝送システムの一実施の形態の構成を示す図である。
【図２】図１の伝送システムの各装置の概要を示す図である。
【図３】IP伝送方式のデジタル放送を採用した場合の緊急警報の伝送方式の概要を示す図である。
【図４】LLSテーブルのシンタックスの例を示す図である。
【図５】緊急警報アプリケーション（EAA）の起動方式の例を示す図である。
【図６】第１の方式における緊急警報の受信時の画面遷移を模式的に表した図である。
【図７】第２の方式における緊急警報の受信時の画面遷移を模式的に表した図である。
【図８】第３の方式Ａにおける緊急警報の受信時の画面遷移を模式的に表した図である。
【図９】第３の方式Ｂにおける緊急警報の受信時の画面遷移を模式的に表した図である。
【図１０】E-AITのシンタックスの例を示す図である。
【図１１】MPDの記述例を示す図である。
【図１２】MPDのEventStream要素の構造の例を示す図である。
【図１３】EventStream要素の第１の具体例を示す図である。
【図１４】EventStream要素の第２の具体例を示す図である。
【図１５】EventStream要素の第３の具体例を示す図である。
【図１６】DASHセグメントのイベントメッセージボックスの構造の例を示す図である。
【図１７】イベントメッセージボックスの第１の具体例を示す図である。
【図１８】イベントメッセージボックスの第２の具体例を示す図である。
【図１９】伝送システムの各装置の構成例を示す図である。
【図２０】HTML5アプリケーション（BCA，EAA）の起動シーケンスの例を示す図である。
【図２１】送信処理の流れを説明するフローチャートである。
【図２２】電源オフ・待機状態時の受信処理の流れを説明するフローチャートである。
【図２３】電源オフ状態時の受信処理の流れを説明するフローチャートである。
【図２４】放送ストリーム受信処理の流れを説明するフローチャートである。
【図２５】第１の方式のE-AIT受信処理の流れを説明するフローチャートである。
【図２６】第２の方式と第３の方式のE-AIT受信処理の流れを説明するフローチャートである。
【図２７】E-AIT受信処理の流れを説明するフローチャートである。
【図２８】イベント処理の流れを説明するフローチャートである。
【図２９】コンピュータの構成例を示す図である。
【発明を実施するための形態】
【００１５】
以下、図面を参照しながら本技術の実施の形態について説明する。なお、説明は以下の順序で行うものとする。
【００１６】
１．本技術を適用した伝送システムの運用
２．各装置の構成
３．各装置で実行される処理の流れ
４．変形例
５．コンピュータの構成
【００１７】
＜１．本技術を適用した伝送システムの運用＞
【００１８】
（伝送システムの構成例）
図１は、本技術を適用した伝送システムの一実施の形態の構成を示す図である。なお、システムとは、複数の装置が論理的に集合したものをいう。
【００１９】
伝送システム１において、各放送局（Broadcaster）は、送信装置１０（例えば、送信装置１０−１や送信装置１０−２）を設置している。送信装置１０は、放送番組等のコンテンツを含む放送ストリームを、デジタル放送信号として送信する。
【００２０】
送信装置１０からのデジタル放送信号は、電波塔３０等を経由して、伝送路８０を介して受信装置２０により受信される。受信装置２０は、固定受信機（例えば、受信装置２０−１）やモバイル受信機（例えば、受信装置２０−２や受信装置２０−３）である。受信装置２０は、デジタル放送信号から得られる放送ストリームを処理し、放送番組等のコンテンツの映像や音声を再生する。
【００２１】
また、図１において、伝送システム１は、米国で構築されているEAS(Emergency Alerting System)と称される緊急告知のシステムに対応する構成を含んでおり、緊急時には、各放送局などが、受信装置２０に対して、緊急に告知する必要がある情報である緊急情報（緊急警報）を提供（通知）することになる。
【００２２】
具体的には、伝送システム１では、緊急時に、米国連邦緊急事態管理庁（FEMA：Federal Emergency Management Agency）や大統領官邸（政府）等の緊急情報源から通知される緊急情報源情報（例えば災害時に発行される緊急警報など）が、CAP情報に変換され、各放送局（の送信装置１０）に提供される。
【００２３】
なお、CAP情報は、構造化情報標準促進協会（OASIS：Organization for the Advancement of Structured Information Standards）で規定されているCAP(Common Alerting Protocol)に準拠したものとなる。すなわち、米国では、EASと称される緊急告知のシステムが整備されているので、このEASを利用して、大統領からの最優先事項からローカルな告知事項まで、様々なレベルの緊急情報（CAP情報）が、様々なメディア（例えば放送経由や通信経由など）により告知（通知）されることになる。
【００２４】
放送局（の送信装置１０）は、例えば、緊急情報源からの緊急情報源情報に応じたCAP情報の解析結果に基づいて、例えば、放送番組の映像（非圧縮のビデオデータ）に、緊急警報メッセージ（緊急警報）を埋め込んでエンコードしたりすることで、緊急警報メッセージを含むコンテンツを生成する。そして、放送局（の送信装置１０）は、緊急警報メッセージを含むコンテンツを、放送エリア内の多数の受信装置２０（例えば、受信装置２０−１乃至２０−３）に対して送信する。
【００２５】
これにより、受信装置２０では、放送番組の映像に、緊急警報メッセージ（緊急警報）が重畳して表示されることになる。その結果、ユーザは、受信装置２０の画面に表示された緊急警報メッセージ（緊急警報）を確認することができる。
【００２６】
また、放送局（の送信装置１０）は、緊急警報の詳細な情報（以下、緊急詳細情報ともいう）を提示する緊急警報アプリケーション（EAA）を生成し、放送エリア内の多数の受信装置２０（例えば、受信装置２０−１乃至２０−３）に対して送信する。
【００２７】
すなわち、緊急情報としての緊急警報（緊急警報情報）は、緊急警報メッセージ（Universal Alert）と、アドバンスコンテンツ（Advanced Content）の２種類に分類され、先行して表示される緊急警報メッセージ（のテキスト情報）に関心があるユーザが、アドバンスコンテンツ（の緊急詳細情報）を表示させて確認することになる。
【００２８】
以下の説明では、緊急警報メッセージ（Universal Alert）の一例として、放送局（の送信装置１０）が、緊急情報源情報に応じたCAP情報を、放送番組等のコンテンツの映像（非圧縮のビデオデータ）に埋め込んでエンコードすることで、コンテンツの映像に重畳表示される緊急警報メッセージを、焼き込みテキストと称して説明する。また、この焼き込みテキストは、「burn-in text」とも記述される。
【００２９】
また、アドバンスコンテンツ（Advanced Content）は、静止画や動画等のリッチメディア（Rich Media）により、緊急詳細情報を提示する。以下の説明では、このアドバンスコンテンツの一例として、HTML5(HyperText Markup Language 5)で開発された、緊急詳細情報を提示可能なアプリケーションを、緊急警報アプリケーション（EAA：Emergency Alert Application）と称して説明する。なお、緊急警報アプリケーション（EAA）は、米国連邦緊急事態管理庁（FEMA）や政府などの緊急情報源情報を発する機関（EA Authority）が生成し、放送局（の送信装置１０）などの緊急警報情報の配信者に提供されるようにしてもよい。
【００３０】
なお、以下の説明では、通常の放送サービス向けのHTML5で開発されたアプリケーションを、放送アプリケーション（BCA：Broadcast Application）と称して、緊急警報アプリケーション（EAA）と区別する。ただし、緊急警報アプリケーション（EAA）と、放送アプリケーション（BCA）を特に区別する必要がない場合には、それらを、HTML5アプリケーション（HTML5 APP）とも称する。
【００３１】
また、HTML5アプリケーションを制御するための情報としては、AIT(Application Information Table)を用いることができるが、緊急警報アプリケーション（EAA）の制御に用いられるAITを、E-AIT(Emergency - AIT)と称して、放送アプリケーション（BCA）の制御に用いられるAITと区別する。なお、E-AITは、AITを拡張したものである。
【００３２】
なお、詳細は後述するが、このE-AITによって、緊急警報アプリケーション（EAA）の起動から終了までのライフサイクル（Lifecycle）が制御される。また、E-AITには、緊急警報（の詳細情報）に関する情報も含まれる。さらに、イベントメッセージを利用することで、緊急警報アプリケーション（EAA）に関する各種の処理を実行させることも可能であるが、その詳細については後述する。
【００３３】
図１の説明に戻り、放送局（の送信装置１０）は、緊急警報アプリケーション（EAA）を、EAサーバ４０に提供することができる。EAサーバ４０は、放送局（の送信装置１０）から提供される緊急警報アプリケーション（EAA）の配信を行う。
【００３４】
受信装置２０は、通信機能を有している場合、インターネットや携帯電話網等の通信回線９０を介してEAサーバ４０にアクセスし、緊急警報アプリケーション（EAA）を要求することができる。そして、受信装置２０は、通信回線９０を介してEAサーバ４０から配信される緊急警報アプリケーション（EAA）を受信して実行（起動）することができる。これにより、受信装置２０の画面には、緊急詳細情報が表示されることになる。
【００３５】
なお、図１において、固定受信機としての受信装置２０−１と、モバイル受信機としての受信装置２０−２や受信装置２０−３が、同一のホームネットワーク（家庭内LAN(Local Area Network)）に接続されている場合には、例えば、受信装置２０−１が、放送局（の送信装置１０）から受信した緊急警報情報（例えば緊急警報アプリケーション（EAA）等）を、受信装置２０−２又は受信装置２０−３に送信（転送）するようにしてもよい。これにより、例えば、モバイル受信機としての受信装置２０−２や受信装置２０−３は、放送機能を有していない場合でも、固定受信機としての受信装置２０−１から送信されてくる緊急警報情報を受信して、表示することが可能となる。
【００３６】
（各装置の概要）
図２は、図１の伝送システム１の各装置の概要を示す図である。
【００３７】
図２において、送信装置１０は、例えば、中継場所から伝送路や通信回線を介して送られてくるライブコンテンツ（例えば、スポーツ中継等の生放送番組）や、ストレージに蓄積された収録済みのコンテンツ（例えば、ドラマ等の事前収録番組）などの放送番組を、デジタル放送信号として送信する。
【００３８】
ここで、緊急時において、送信装置１０は、緊急情報源（EA Authority）から通知される緊急情報源情報としてのCAP情報を取得し、そのCAP情報の解析結果に応じた緊急警報メッセージ（Universal Alert）を、放送番組等のコンテンツの映像（非圧縮のビデオデータ）に埋め込んでエンコードする。ただし、緊急時においては、視覚障がい者向けのトーン信号や副音声などで、視覚障がい者向けの音声（Universal Alert）も配信することになる。
【００３９】
また、送信装置１０は、CAP情報の解析結果に応じたE-AITを生成する。このE-AITには、緊急警報（の詳細情報）に関する情報や、緊急警報アプリケーション（EAA）の制御情報などが含まれる。さらに、送信装置１０は、CAP情報の解析結果に基づいて、LCCコンテンツとして、アドバンスコンテンツ（Advanced Content）である緊急警報アプリケーション（EAA）を生成する。
【００４０】
そして、緊急時においては、緊急警報メッセージを含む放送番組等のコンテンツ、E-AITを含むシグナリング、及び、緊急警報アプリケーション（EAA）を含むLCCコンテンツのストリームが多重化され、デジタル放送信号として送信される。
【００４１】
なお、図２においては、説明の都合上、放送局（Broadcaster）に設置される装置が、送信装置１０、すなわち、１つの装置で構成される場合を例示しているが、複数の装置からなる送信システムとして構成されるようにしてもよい。
【００４２】
また、図２において、受信装置２０は、送信装置１０から伝送路８０を介して送信されてくるデジタル放送信号を受信する。受信装置２０は、デジタル放送信号から得られる放送ストリームを処理し、放送番組等のコンテンツの映像や音声を再生する。
【００４３】
ここで、緊急時においては、放送番組等のコンテンツの映像（非圧縮のビデオデータ）に、緊急警報メッセージ（Universal Alert）としての焼き込みテキスト（burned - in text）が埋め込まれているので、受信装置２０の画面には、放送番組の映像に重畳して、焼き込みテキスト（burned - in text）が表示される（図中の「1.burned-in text & audio」）。ただし、緊急時には、視覚障がい者向けのトーン信号や副音声などで、視覚障がい者向けの音声（Universal Alert）も配信されるので、この音声を出力することができる。
【００４４】
また、緊急時には、シグナリングとして、E-AITが伝送されてくるので、受信装置２０では、当該E-AITが解析され、その解析結果に従い、緊急詳細情報の表示の要否、すなわち、アドバンスコンテンツ（Advanced Content）である緊急警報アプリケーション（EAA）を起動するかどうかが判定される。そして、受信装置２０は、緊急警報アプリケーション（EAA）を起動すると判定した場合、LCCコンテンツとして伝送される緊急警報アプリケーション（EAA）を取得して起動する。これにより、受信装置２０の画面には、放送番組の映像に重畳して、緊急警報アプリケーション（EAA）による緊急詳細情報と、焼き込みテキスト（burned - in text）が表示される（図中の「2.burned-in text & audio & APP」）。ただし、緊急警報アプリケーション（EAA）による緊急詳細情報が、全画面に表示されるようにしてもよい（図中の「3.HTML5 Application」）。
【００４５】
なお、送信装置１０は、緊急警報アプリケーション（EAA）を、EAサーバ４０に提供するようにしてもよい。この場合、受信装置２０は、インターネット等の通信回線９０を介して、EAサーバ４０から配信される緊急警報アプリケーション（EAA）を受信して、起動することができる。また、詳細は後述するが、MPD(Media Presentation Description)のイベントストリーム要素（図中の「MPD」）やDASH(Dynamic Adaptive Streaming over HTTP)セグメントのイベントメッセージボックス（図中の「'emsg'box」）等に配置されるイベントメッセージ（Event Message）を利用して、緊急警報アプリケーション（EAA）に関する処理を行うこともできる（図中の「Event」）。ただし、後述するように、トランスポート・プロトコルとして、MMT(MPEG Media Transport)を用いる場合には、MPDのイベントストリーム要素の代わりに、MMTシグナリングに、MPDのイベントストリーム要素と同様の情報を埋め込んだり、あるいは、独立したシグナリングのデータとして同様の情報を通知したりすることができる。
【００４６】
以上、図１の伝送システム１の各装置の概要について説明した。
【００４７】
（IP伝送方式の緊急警報の伝送方法）
図３は、IP伝送方式のデジタル放送を採用した場合の緊急警報の伝送方式の概要を示す図である。
【００４８】
ところで、各国のデジタル放送の規格では、伝送方式としてMPEG2-TS(Moving Picture Experts Group phase 2-Transport Stream)方式が採用されているが、今後は、通信の分野で用いられているIP(Internet Protocol)パケットをデジタル放送に用いたIP伝送方式を導入することで、より高度なサービスを提供することが想定されている。
【００４９】
特に、現在策定が進められている米国の次世代放送規格であるATSC(Advanced Television Systems Committee)3.0では、IP伝送方式を用いたデジタル放送の採用が決定している。例えば、図１の伝送システム１において、送信装置１０と受信装置２０とでは、伝送路８０を介してATSC3.0に準拠したデータ伝送が行われるようにすることができる。
【００５０】
図３において、左側に示したパイプ図は、IP伝送方式のデジタル放送のシステムパイプモデルを表している。このシステムパイプモデルにおいて、所定の周波数帯域（例えば6MHz）の放送ストリーム（Broadcast Stream）には、１又は複数のPLPストリーム（PLP Stream）が含まれる。また、各PLPストリームには、シグナリングやサービスごとのストリームが含まれる。
【００５１】
なお、所定の周波数帯域の放送ストリームは、ブロードキャストストリームID（Broadcast Stream ID）により識別される。また、各PLPストリームは、PLP IDにより識別される。さらに、各サービスは、サービスID（Service ID）により識別される。
【００５２】
ここで、LLS(Link Layer Signaling)シグナリングは、IP/UDPパケットに格納されて伝送される。LLSシグナリングは、SLS(Service Layer Signaling)シグナリングに先行して取得されるシグナリングであって、LLSシグナリングの情報に従い、SLSシグナリングが取得される。
【００５３】
このLLSシグナリングとしては、例えば、SLT(Service List Table)やRRT(Region Rating Table)，E-AIT等のメタデータが含まれる。SLTメタデータは、サービスの選局に必要な情報(選局情報)など、放送ネットワークにおけるストリームやサービスの構成を示す情報を含む。RRTメタデータは、レーティングに関する情報を含む。E-AITメタデータ（以下、E-AITと記述する）は、緊急警報アプリケーション（EAA）の制御情報や、緊急警報（の詳細情報）に関する情報を含む。
【００５４】
なお、SLT，RRT，E-AIT等のメタデータは、XML(Extensible Markup Language)等のマークアップ言語により記述される。
【００５５】
また、サービスごとのストリームは、ROUTE(Real-Time Object Delivery over Unidirectional Transport)セッションで伝送される。ここで、ROUTEとは、ファイルを一方向でマルチキャスト転送するのに適したプロトコルであるFLUTE(File Delivery over Unidirectional Transport)を拡張したプロトコルである。サービスごとのストリームでは、ROUTEセッションによって、SLSシグナリングやコンポーネント（Component）、LCC(Locally Cached Content)コンテンツのストリームが伝送される。
【００５６】
このSLSシグナリングとしては、例えば、USD(User Service Description)，S-TSID(Service-based Transport Session Instance Description)，MPD(Media Presentation Description)等のメタデータが含まれる。USDメタデータは、他のメタデータの取得先などの情報を含む。S-TSIDメタデータは、LSID(LCT Session Instance Description)をATSC3.0向けに拡張したものであって、ROUTEプロトコルの制御情報である。MPDメタデータ（以下、MPDと記述する）は、コンポーネントのストリームの再生を管理するための制御情報である。
【００５７】
なお、USD，S-TSID，MPD等のメタデータは、XML等のマークアップ言語により記述される。また、MPDは、MPEG-DASH(Dynamic Adaptive Streaming over HTTP)の規格に準じている。
【００５８】
コンポーネントは、ビデオやオーディオ、字幕などのコンテンツを構成するデータである。また、LCCコンテンツは、受信装置２０のストレージに蓄積（ダウンロード）されてから処理されるコンテンツである。ただし、図３の例では、LCCコンテンツとして、緊急警報アプリケーション（EAA）が伝送されている。なお、LCCは、NRT(Non Real Time)と称される場合がある。
【００５９】
なお、説明の簡略化のために省略しているが、PLPストリームにおいては、時刻情報としてのNTP(Network Time Protocol)や、電子サービスガイドとしてのESG(Electronic Service Guide)サービスなどのストリームも伝送されることになる。
【００６０】
図３のパイプ図において、放送ストリームには、異なるPLP IDとなる２つのPLPストリームが含まれているが、一方（図中の上方）のPLPストリームは、通常のPLPストリームとされ、他方（図中の下方）のPLPストリームは、高ロバストネスなPLPストリームとされる。
【００６１】
この例では、通常のPLPストリームで、サービスのコンポーネントとSLSシグナリングが伝送され、高ロバストネスなPLPストリームで、LLSシグナリングとLCCコンテンツのストリームが伝送される。したがって、LLSシグナリングやLCCコンテンツを、確実に伝送することができる。また、この例では、LLSシグナリングは、複数のサービスで共通に用いられる。
【００６２】
ここで、図中の点線Ｌで囲った部分、すなわち、LLSシグナリングを伝送するストリームに注目すれば、緊急時において、LLSシグナリングとしてのE-AITは、次のように伝送されることになる。
【００６３】
IP伝送方式のプロトコルスタックにおいて、最も下位の階層は、物理層（L1：Layer1）とされ、この物理層に隣接する上位の階層は、レイヤ２の階層（L2：Layer2）とされ、さらに、レイヤ２の階層に隣接する上位の階層は、IP層とされ、IP層に隣接する上位の階層は、UDP(User Datagram Protocol)層とされる。
【００６４】
すなわち、図３の右側のフレーム（パケット）の構造図に示すように、物理層のL1フレーム（L1 Frame）は、L1ヘッダとL1ペイロードから構成される。このL1ヘッダには、緊急時に電源オフで、かつ、待機状態の受信装置２０を起動させるためのウェイクアップフラグ（wake-up flag）が含まれる。また、L1ペイロードには、１又は複数のALP(ATSC Link-layer Protocol)パケットが配置される。
【００６５】
このALPパケットは、レイヤ２の階層の伝送パケットであって、そのALPペイロードに、LLSテーブルが配置される。すなわち、LLSテーブルは、IP/UDPパケットに含まれて伝送されるため、そのヘッダとして、LLSヘッダ（LLS_H）のほかに、IPヘッダ（IP_H）とUDPヘッダ（UDP_H）が付加されている。また、LLSテーブルには、LLSシグナリングのデータ、すなわち、この例では、E-AITが配置される。
【００６６】
ここで、図４には、LLSテーブルのシンタックスの例を示している。図４のLLSテーブルにおいて、8ビットのLLS_table_idには、LLSテーブルを識別するためのLLSテーブルIDが指定される。また、8ビットのLLS_table_versionには、LLSテーブルのバージョンが指定される。なお、LLS_table_idとLLS_table_versionは、LLSヘッダに含まれる。
【００６７】
また、switch文によって、LLSテーブルIDとして、"0x01"が指定された場合、LLSシグナリングのデータとして、SLTメタデータが配置されることを示している。また、LLSテーブルIDとして、"0x02"が指定された場合には、LLSシグナリングのデータとして、RRTメタデータが配置され、"0x03"が指定された場合には、LLSシグナリングのデータとして、E-AITが配置されることを示している。
【００６８】
図３の説明に戻り、LLSテーブルに含まれるE-AITには、緊急警報アプリケーション（EAA）の制御情報や、緊急警報（の詳細情報）に関する情報が含まれる。受信装置２０は、E-AITが受信された場合、当該E-AITを解析し、その解析結果に応じて、緊急詳細情報を表示するかどうか（緊急警報アプリケーション（EAA）を起動するかどうか）を判定する。ここでは、例えば、ユーザ操作に応じて緊急詳細情報を表示するかどうかを判定したり、あるいは、ユーザによりあらかじめ設定された設定情報に応じて緊急詳細情報を表示するかどうかを判定したりすることができる。
【００６９】
そして、受信装置２０は、緊急詳細情報を表示すると判定された場合、すなわち、緊急警報アプリケーション（EAA）を起動すると判定された場合、LCCコンテンツとしてROUTEセッションで伝送される、緊急警報アプリケーション（EAA）を取得して起動する（Ｓ１）。その結果、受信装置２０の画面には、緊急警報アプリケーション（EAA）による緊急詳細情報が表示されることになる。
【００７０】
また、E-AITには、緊急警報アプリケーション（EAA）が、EAサーバ４０により提供される場合、そのEAサーバ４０のURL(Uniform Resource Locator)を示す情報が含まれている。この場合、受信装置２０は、当該E-AITに基づいて、通信回線９０（Internet）を介してEAサーバ４０にアクセスし、緊急警報アプリケーション（EAA）を要求する（Ｓ２，Ｓ３）。そして、受信装置２０は、EAサーバ４０から通信回線９０を介して配信される緊急警報アプリケーション（EAA）を受信して起動する（Ｓ３，Ｓ２）。その結果、受信装置２０の画面には、緊急警報アプリケーション（EAA）による緊急詳細情報が表示されることになる。
【００７１】
これにより、緊急時において、焼き込みテキスト等の文字列による緊急警報メッセージ（Universal Alert）によって、簡易的な情報を提示するだけでなく、その情報に関心のあるユーザに対しては、アドバンスコンテンツ（Advanced Content）としての緊急警報アプリケーション（EAA）によって、例えば、静止画や動画等を含む緊急詳細情報を提示することが可能となる。
【００７２】
なお、図３の例では、トランスポート層の伝送プロトコル（トランスポート・プロトコル）として、ROUTEを用いる場合を説明したが、他のトランスポート・プロトコルを用いるようにしてもよい。例えば、現在策定中のATSC3.0では、トランスポート・プロトコルとして、ROUTEとMMT(MPEG Media Transport)が併存することが想定されているが、ROUTEセッションほかに、MMTセッションを用いてコンポーネントやシグナリングのストリームが伝送されるようにしてもよい。
【００７３】
以上のように、ATSC3.0等のIP伝送方式のデジタル放送において、トランスポート・プロトコルとして、ROUTE又はMMTを用いた場合に、緊急時に、緊急情報源（例えば米国連邦緊急事態管理庁（FEMA））からの緊急情報源情報（例えば災害時に発行される緊急警報など）に応じた緊急情報（緊急警報）を、受信装置２０に対して提供（通知）することができる。
【００７４】
（緊急警報アプリケーション（EAA）の起動方式）
ところで、放送アプリケーション（BCA）と、緊急警報アプリケーション（EAA）とを比較した場合、緊急時に起動される緊急警報アプリケーション（EAA）は、通常時に起動される放送アプリケーション（BCA）よりも起動の優先度が高くなる。したがって、緊急警報アプリケーション（EAA）を起動する場合に、放送アプリケーション（BCA）が起動されているときには、緊急警報アプリケーション（EAA）による緊急詳細情報が、優先して表示されるようにする必要がある。
【００７５】
このような優先起動の解決策としては、例えば、受信装置２０において、緊急警報アプリケーション（EAA）を起動し、当該緊急警報アプリケーション（EAA）によって、緊急詳細情報の表示の要否を判定することは可能ではあるが、放送アプリケーション（BCA）が起動された状態であると、起動中の放送アプリケーション（BCA）を一時停止又は終了してから、緊急警報アプリケーション（EAA）を起動して、緊急詳細情報の表示の要否を判定することになる。
【００７６】
そして、緊急詳細情報の表示が必要な場合には、起動中の緊急警報アプリケーション（EAA）により緊急詳細情報を表示すればよいが、一方で、緊急詳細情報の表示が不要となる場合には、起動中の緊急警報アプリケーション（EAA）を終了させてから、再度、放送アプリケーション（BCA）の実行を再開又は起動することになる。すなわち、受信装置２０において、緊急警報アプリケーション（EAA）を起動可能な場合でも、例えば、ユーザによっては、緊急警報メッセージ（焼き込みテキスト）で十分であり、対象の緊急詳細情報を必要としていない場合もあり、そのような場合には、緊急警報アプリケーション（EAA）を起動させる必要はない。
【００７７】
そこで、本技術では、AITを拡張したE-AITに、緊急警報アプリケーション（EAA）の制御情報のほかに、緊急警報（の詳細情報）に関する情報を含めることで、受信装置２０が、当該E-AITの解析結果に応じて、緊急詳細情報の表示の要否を判定し、緊急詳細情報を表示させる場合にのみ、緊急警報アプリケーション（EAA）が起動されるようにしている。あるいは、本技術では、E-AITに、CAP情報を含めることで、緊急警報アプリケーション（EAA）が直接CAP情報を受け取って処理できるようにしている。また、受信装置２０では、緊急警報アプリケーション（EAA）の起動時に、放送アプリケーション（BCA）が起動されている場合には、放送アプリケーション（BCA）を一時停止又は終了して、緊急警報アプリケーション（EAA）が優先して起動されるようにする。
【００７８】
ここで、緊急警報アプリケーション（EAA）を起動して緊急詳細情報を表示するかどうかの判定処理としては、上述したように、ユーザの操作に応じて、緊急詳細情報の表示の要否を判定してもよいし、受信装置２０が、E-AITの解析結果に応じて、緊急詳細情報の表示の要否を判定してもよい。
【００７９】
後者の場合、例えば、受信装置２０は、その視聴地域が、緊急警報の対象地域であるかどうかを判定し、視聴地域が、緊急警報の対象地域外である場合には、緊急警報アプリケーション（EAA）を起動せずに、緊急詳細情報の表示が行われないようにする。また、例えば、受信装置２０は、ユーザがあらかじめ登録した設定情報（例えば、気象に関する情報は表示するが、学校の臨時休校などの情報は表示しないなど）に基づいて、緊急警報アプリケーション（EAA）の要否を判定してもよい。
【００８０】
図５は、緊急警報アプリケーション（EAA）の起動方式の例を示す図である。
【００８１】
図５に示すように、緊急警報の詳細情報（緊急詳細情報）を提示するための緊急警報アプリケーション（EAA）は、第１の方式乃至第３の方式のいずれかの方式によって起動され、緊急詳細情報が表示されるようにすることができる。ただし、これらの第１の方式乃至第３の方式は、緊急警報アプリケーション（EAA）の起動シーケンスの一例であって、他の方式によって、緊急警報アプリケーション（EAA）が起動されるようにしてもよい。
【００８２】
第１の方式では、レジデントアプリケーション（RA）によって、緊急警報アプリケーション（EAA）が起動される。
【００８３】
具体的には、受信装置２０において、ユーザにより放送番組が視聴されているときに、E-AIT（autostart）が受信された場合、レジデントアプリケーション（RA）が、当該E-AIT（autostart）に従い、緊急警報の詳細情報（緊急詳細情報）を受信したことを示すアイコン（EAアイコン）などを表示させる。そして、この表示情報（選択情報）を確認したユーザは、緊急詳細情報を表示させるかどうかを判断し、その表示を指示した場合には、緊急警報アプリケーション（EAA）が起動（実行）され、緊急詳細情報が、受信装置２０の画面に表示される。
【００８４】
その後、受信装置２０において、E-AIT（terminate）が受信された場合、レジデントアプリケーション（RA）が、当該E-AIT（terminate）に従い、起動中の緊急警報アプリケーション（EAA）を終了させる。これにより、受信装置２０の画面では、緊急詳細情報の表示が消えて、放送番組のみが表示されることになる。
【００８５】
第２の方式では、放送アプリケーション（BCA）が未実行の状態から、緊急警報アプリケーション（EAA）が起動される。
【００８６】
具体的には、受信装置２０において、ユーザにより放送番組が視聴されているときに、E-AIT（autostart）が受信された場合、ミドルウェア（MW）やブラウザ（BR）等が、当該E-AIT（autostart）に従い、緊急警報アプリケーション（EAA）を起動（実行）することで、緊急警報の詳細情報（緊急詳細情報）が表示される。
【００８７】
その後、受信装置２０において、E-AIT（terminate）が受信された場合、ミドルウェア（MW）やブラウザ（BR）等が、当該E-AIT（terminate）に従い、起動中の緊急警報アプリケーション（EAA）を終了させる。これにより、受信装置２０では、緊急詳細情報の表示が消えて、放送番組のみが表示されることになる。
【００８８】
第３の方式では、放送アプリケーション（BCA）が実行されている状態から、緊急警報アプリケーション（EAA）が起動される。
【００８９】
具体的には、受信装置２０において、ユーザにより放送番組が視聴されているときであって、放送アプリケーション（BCA）が起動されているときに、E-AIT（autostart）が受信された場合、ミドルウェア（MW）やブラウザ（BR）等が、当該E-AIT（autostart）に従い、緊急警報アプリケーション（EAA）を起動（実行）することで、緊急警報の詳細情報（緊急詳細情報）が表示される。その際、起動中の放送アプリケーション（BCA）は、一時停止（終了）され、その映像が、受信装置２０の画面上から消えることになる。
【００９０】
その後、受信装置２０において、E-AIT（terminate）が受信された場合、ミドルウェア（MW）やブラウザ（BR）等が、当該E-AIT（terminate）に従い、起動中の緊急警報アプリケーション（EAA）を終了させる。これにより、受信装置２０では、緊急詳細情報の表示が消えて、放送番組が表示されることになる。なお、一時停止中の放送アプリケーション（BCA）がある場合には、当該放送アプリケーション（BCA）の実行が再開され、その映像が、放送番組に重畳表示される。
【００９１】
また、イベントメッセージを利用することで、起動中の緊急警報アプリケーション（EAA）の更新を行うなど、緊急警報アプリケーション（EAA）に関する各種の処理を実行することが可能となる。なお、以下の説明では、第３の方式のうち、イベントメッセージを利用した場合を、第３の方式Ｂと称して、イベントメッセージを利用していない場合の第３の方式Ａと区別するようにする。
【００９２】
以下、第１の方式乃至第３の方式の詳細な内容について説明する。
【００９３】
（１）第１の方式
【００９４】
図６は、第１の方式における、緊急警報の受信時の画面遷移を模式的に表した図である。図６の例では、画面Ｄ１１乃至Ｄ１５により、受信装置２０の画面の遷移を表し、ステップＳ１１乃至Ｓ１５により、受信装置２０の動作を表している。なお、図６において、時間の方向は、図中の左側から右側に向かう方向とされる。また、図６の例では、時刻t1から時刻t2の間に、緊急警報（Emergency Alert）が通知されるものとする。なお、レジデントアプリケーション（RA）は、受信装置２０にあらかじめ組み込まれたアプリケーションである。
【００９５】
緊急警報が通知される時刻t1よりも前の時間帯において、受信装置２０では、その画面に、放送番組の映像のみが表示され、ユーザにより視聴されている（Ｄ１１）。なお、この時点において、放送アプリケーション（BCA）等のHTML5アプリケーションは実行されていない。
【００９６】
ここで、時刻t1となったとき、受信装置２０は、送信装置１０から伝送路８０を介して通知される緊急警報を受信する。そして、受信装置２０においては、放送番組の映像に、焼き込みテキスト（burned - in text）の文字列が重畳表示される（Ｄ１２）。これにより、緊急警報メッセージ（Universal Alert）としての焼き込みテキストの内容が、ユーザにより確認されることになる。
【００９７】
また、受信装置２０は、送信装置１０から伝送路８０を介して通知されるE-AIT（autostart）を受信する（Ｓ１１）。受信装置２０において、レジデントアプリケーション（RA）は、当該E-AIT（autostart）を解析し、その解析結果に応じたEAアイコンを、画面に表示させる（Ｓ１２，Ｄ１３）。このEAアイコンによって、例えば、「緊急警報の詳細情報があります。表示しますか？」などのメッセージとともに、緊急詳細情報の表示を選択するための「はい」ボタンと、「いいえ」ボタンが表示される。
【００９８】
なお、ここでは、緊急警報に関する緊急性や対象地域、カテゴリなどのE-AITに含まれる情報に基づいた各種の情報を表示させることも可能である。また、レジデントアプリケーション（RA）が、設定情報（例えば表示対象地域や表示対象項目などの設定）に応じて、緊急詳細情報の表示の要否を判定してもよい。
【００９９】
そして、受信装置２０では、画面（Ｄ１３）に、EAアイコンとして表示された「はい」ボタンが、ユーザにより選択された場合、緊急警報アプリケーション（EAA）のEAA起動イベントが発行され、緊急警報アプリケーション（EAA）が起動される（Ｓ１３）。その結果、受信装置２０の画面には、緊急警報アプリケーション（EAA）による緊急詳細情報が、焼き込みテキスト（burned - in text）とともに、放送番組の映像に重畳表示される（Ｄ１４）。
【０１００】
これにより、緊急時において、焼き込みテキスト等の文字列による緊急警報メッセージ（Universal Alert）によって、簡易的な情報を提示するだけでなく、その情報に関心のあるユーザに対しては、アドバンスコンテンツ（Advanced Content）としての緊急警報アプリケーション（EAA）によって、例えば、静止画や動画等を含む緊急詳細情報を提示して、より詳細な情報を提供することができる。
【０１０１】
その後、時刻t2を経過すると、送信装置１０からの緊急警報の通知が終了される。また、受信装置２０は、送信装置１０から伝送路８０を介して通知されるE-AIT（terminate）を受信する（Ｓ１４）。受信装置２０は、当該E-AIT（terminate）を解析し、その解析結果に応じて、起動中の緊急警報アプリケーション（EAA）を終了させる（Ｓ１５）。その結果、受信装置２０の画面では、焼き込みテキスト（burned - in text）と緊急詳細情報（図中の「EAA」）の表示が消えて、放送番組の映像のみが表示される（Ｄ１５）。
【０１０２】
以上のように、第１の方式では、レジデントアプリケーション（RA）が、E-AIT（autostart）に基づいて、EAアイコンを表示するとともに、ユーザが緊急詳細情報の表示を指示した場合には、緊急警報アプリケーション（EAA）を起動して、緊急詳細情報を表示することになる。これにより、例えば、緊急詳細情報を表示する必要がない場合には、緊急警報アプリケーション（EAA）を起動せず、緊急詳細情報を表示させる必要がある場合にのみ、緊急警報アプリケーション（EAA）が起動されるので、緊急警報アプリケーション（EAA）が無駄に起動されることが防止されるなど、受信装置２０における処理の負荷を軽減することができる。また、レジデントアプリケーション（RA）が、E-AITに基づいて、緊急警報アプリケーション（EAA）のライフサイクル（起動から終了までの動作）を制御することができる。
【０１０３】
（２）第２の方式
【０１０４】
図７は、第２の方式における、緊急警報の受信時の画面遷移を模式的に表した図である。図７の例では、画面Ｄ２１乃至Ｄ２５により、受信装置２０の画面の遷移を表し、ステップＳ２１乃至Ｓ２６により、受信装置２０の動作を表している。なお、図７においても、時間の方向は、図中の左側から右側に向かう方向とされる。また、図７の例では、時刻t1から時刻t2の間に、緊急警報（Emergency Alert）が通知されるものとする。なお、ミドルウェア（MW）は、後述するMW部２１３（図１９）に対応している。また、ブラウザ（BR）は、後述するブラウザ２１４（図１９）に対応している。この例では、ミドルウェア（MW）又はブラウザ（BR）が、処理の主体となる場合を説明するが、他のソフトウェアやハードウェアが処理を行うようにしてもよい。これらの関係は、後述する図８及び図９でも同様である。
【０１０５】
緊急警報が通知される時刻t1よりも前の時間帯において、受信装置２０では、その画面に、放送番組の映像が表示され、ユーザにより視聴されている（Ｄ２１）。なお、この時点において、放送アプリケーション（BCA）等のHTML5アプリケーションは実行されていない。
【０１０６】
ここで、時刻t1となったとき、受信装置２０は、送信装置１０から伝送路８０を介して通知される緊急警報を受信する。そして、受信装置２０においては、放送番組の映像に、焼き込みテキスト（burned - in text）の文字列が重畳表示される（Ｄ２２）。これにより、緊急警報メッセージ（Universal Alert）としての焼き込みテキストの内容が、ユーザにより確認されることになる。
【０１０７】
また、受信装置２０は、送信装置１０から伝送路８０を介して通知されるE-AIT（autostart）を受信する（Ｓ２１）。受信装置２０において、ミドルウェア（MW）又はブラウザ（BR）は、当該E-AIT（autostart）を解析し、その解析結果に応じて、緊急警報アプリケーション（EAA）の取得と起動を指示する（Ｓ２２）。
【０１０８】
なお、ここでは、ミドルウェア（MW）又はブラウザ（BR）が、ユーザからの指示又は設定情報（例えば表示対象地域や表示対象項目などの設定）に応じて、緊急詳細情報の表示の要否を判定することができる。例えば、緊急警報アプリケーション（EAA）の起動画面として、緊急詳細情報を受信したことを示すアイコン等を表示し、ユーザが緊急詳細情報を表示すると判断し、その表示が指示された場合にのみ、緊急詳細情報を表示させることができる。
【０１０９】
そして、受信装置２０では、ミドルウェア（MW）又はブラウザ（BR）からの指示（EAA起動イベント）に応じて、緊急警報アプリケーション（EAA）が取得され、起動される（Ｓ２３）。その結果、受信装置２０の画面には、緊急警報アプリケーション（EAA）による緊急詳細情報が、焼き込みテキスト（burned - in text）とともに、放送番組の映像に重畳表示される（Ｄ２４）。
【０１１０】
これにより、緊急時において、焼き込みテキスト等の文字列による緊急警報メッセージ（Universal Alert）によって、簡易的な情報を提示するだけでなく、その情報に関心のあるユーザに対しては、アドバンスコンテンツ（Advanced Content）としての緊急警報アプリケーション（EAA）によって、例えば、静止画や動画等を含む緊急詳細情報を提示して、より詳細な情報を提供することができる。
【０１１１】
その後、時刻t2を経過すると、送信装置１０からの緊急警報の通知が終了される。また、受信装置２０は、送信装置１０から伝送路８０を介して通知されるE-AIT（terminate）を受信する（Ｓ２４）。受信装置２０において、ミドルウェア（MW）又はブラウザ（BR）は、当該E-AIT（terminate）を解析し、その解析結果に応じて、起動中の緊急警報アプリケーション（EAA）の終了を指示する（Ｓ２５）。
【０１１２】
そして、受信装置２０では、ミドルウェア（MW）又はブラウザ（BR）からの指示（EAA終了イベント）に応じて、起動中の緊急警報アプリケーション（EAA）が終了される（Ｓ２６）。その結果、受信装置２０の画面には、焼き込みテキスト（burned - in text）と緊急詳細情報（図中の「EAA」）の表示が消えて、放送番組の映像のみが表示される（Ｄ２５）。
【０１１３】
以上のように、第２の方式では、ミドルウェア（MW）又はブラウザ（BR）が、E-AITに基づいて、緊急警報アプリケーション（EAA）を表示すると判定した場合にのみ、緊急警報アプリケーション（EAA）が起動されるので、例えば、緊急警報アプリケーション（EAA）が無駄に起動されることが防止されるなど、受信装置２０における処理の負荷を軽減することができる。また、ミドルウェア（MW）又はブラウザ（BR）が、E-AITに基づいて、緊急警報アプリケーション（EAA）のライフサイクル（起動から終了までの動作）を制御することができる。
【０１１４】
（３）第３の方式Ａ
【０１１５】
図８は、第３の方式Ａにおける、緊急警報の受信時の画面遷移を模式的に表した図である。図８の例では、画面Ｄ３１乃至Ｄ３５により、受信装置２０の画面の遷移を表し、ステップＳ３１乃至Ｓ３９により、受信装置２０の動作を表している。なお、図８においても、時間の方向は、図中の左側から右側に向かう方向とされる。また、図８の例では、時刻t1から時刻t2の間に、緊急警報（Emergency Alert）が通知されている。
【０１１６】
緊急警報が通知される時刻t1よりも前の時間帯において、受信装置２０では、その画面に、放送番組の映像が表示され、ユーザにより視聴されている（Ｄ３１）。また、受信装置２０は、送信装置１０から伝送路８０を介して通知されるAITを受信している（Ｓ３１）。受信装置２０において、ミドルウェア（MW）又はブラウザ（BR）は、当該AITを解析し、その解析結果に応じて、放送アプリケーション（BCA）の取得と起動を指示する（Ｓ３２）。
【０１１７】
そして、受信装置２０では、ミドルウェア（MW）又はブラウザ（BR）からの指示（BCA起動イベント）に応じて、放送アプリケーション（BCA）が取得され、起動される（Ｓ３３）。その結果、受信装置２０の画面には、放送アプリケーション（BCA）による情報（例えば画像や映像、文字等）が、放送番組の映像に重畳表示される（Ｄ３２）。
【０１１８】
その後、時刻t1になったとき、受信装置２０は、送信装置１０から伝送路８０を介して通知される緊急警報を受信する。そして、受信装置２０においては、放送アプリケーション（BCA）の情報とともに、焼き込みテキスト（burned - in text）の文字列が、放送番組の映像に重畳表示される（Ｄ３３）。これにより、緊急警報メッセージ（Universal Alert）としての焼き込みテキストの内容が、ユーザにより確認されることになる。
【０１１９】
また、受信装置２０は、送信装置１０から伝送路８０を介して通知されるE-AIT（autostart）を受信する（Ｓ３４）。受信装置２０において、ミドルウェア（MW）又はブラウザ（BR）は、当該E-AIT（autostart）を解析し、その解析結果に応じて、緊急警報アプリケーション（EAA）の取得と起動を指示する（Ｓ３５）。
【０１２０】
なお、ここでは、ミドルウェア（MW）又はブラウザ（BR）が、ユーザからの指示又は設定情報（例えば表示対象地域や表示対象項目などの設定）に応じて、緊急詳細情報の表示の要否を判定することができる。例えば、緊急警報アプリケーション（EAA）の起動画面として、緊急詳細情報を受信したことを示すアイコン等を表示し、ユーザが緊急詳細情報を表示すると判断し、その表示が指示された場合にのみ、緊急詳細情報を表示させることができる。
【０１２１】
そして、受信装置２０では、ミドルウェア（MW）又はブラウザ（BR）からの指示（EAA起動イベント）に応じて、緊急警報アプリケーション（EAA）が取得され、起動される（Ｓ３６）。その際、起動中の放送アプリケーション（BCA）は、一時停止（suspend）又は終了（terminate）される。その結果、受信装置２０の画面には、放送アプリケーション（BCA）の情報の代わりに、緊急警報アプリケーション（EAA）の緊急詳細情報が表示される（Ｄ３４）。なお、受信装置２０の画面では、焼き込みテキスト（burned - in text）も継続して、放送番組の映像に重畳表示されている（Ｄ３４）。
【０１２２】
これにより、緊急時において、焼き込みテキスト等の文字列による緊急警報メッセージ（Universal Alert）によって、簡易的な情報を提示するだけでなく、その情報に関心のあるユーザに対しては、アドバンスコンテンツ（Advanced Content）としての緊急警報アプリケーション（EAA）によって、例えば、静止画や動画等を含む緊急詳細情報を提示して、より詳細な情報を提供することができる。
【０１２３】
その後、時刻t2を経過すると、送信装置１０からの緊急警報の通知が終了される。また、受信装置２０は、送信装置１０から伝送路８０を介して通知されるE-AIT（terminate）を受信する（Ｓ３７）。受信装置２０において、ミドルウェア（MW）又はブラウザ（BR）は、当該E-AIT（terminate）を解析し、その解析結果に応じて、起動中の緊急警報アプリケーション（EAA）の終了を指示する（Ｓ３８）。
【０１２４】
そして、受信装置２０では、ミドルウェア（MW）又はブラウザ（BR）からの指示（EAA終了イベント）に応じて、起動中の緊急警報アプリケーション（EAA）が終了される（Ｓ３９）。また、緊急警報アプリケーション（EAA）を起動する際に、放送アプリケーション（BCA）が一時停止（suspend）されていた場合には、当該放送アプリケーション（BCA）の実行が再開される（起動される）。その結果、受信装置２０の画面には、焼き込みテキスト（burned - in text）と緊急詳細情報（図中の「EAA」）の表示が消えて、放送アプリケーション（BCA）の情報が、放送番組の映像に重畳表示される（Ｄ３５）。つまり、受信装置２０の画面の表示は、緊急警報が通知される前の状態（Ｄ３２）に戻ったことになる。
【０１２５】
なお、緊急警報アプリケーション（EAA）を起動する際に、放送アプリケーション（BCA）が終了（terminate）された場合には、放送アプリケーション（BCA）の実行は再開されず、受信装置２０の画面には、放送番組の映像のみが表示されることになる。
【０１２６】
以上のように、第３の方式Ａでは、ミドルウェア（MW）又はブラウザ（BR）が、E-AITに基づいて、緊急警報アプリケーション（EAA）を表示すると判定した場合にのみ、緊急警報アプリケーション（EAA）が起動されるので、例えば、緊急警報アプリケーション（EAA）が無駄に起動されることが防止されるなど、受信装置２０における処理の負荷を軽減することができる。また、第３の方式Ａでは、緊急警報アプリケーション（EAA）を起動する場合に、放送アプリケーション（BCA）が起動されているときには、当該放送アプリケーション（BCA）を一時停止又は終了させてから、緊急警報アプリケーション（EAA）を起動するため、緊急警報アプリケーション（EAA）を優先的に起動することができる。そのため、ユーザに対して、確実に、緊急詳細情報を提示することができる。
【０１２７】
（４）第３の方式Ｂ：イベント対応
【０１２８】
図９は、第３の方式Ｂにおける、緊急警報の受信時にイベント対応を行う場合の画面遷移を模式的に表した図である。図９の例では、画面Ｄ４１乃至Ｄ４５により、受信装置２０の画面の遷移を表し、ステップＳ４１乃至Ｓ４９により、受信装置２０の動作を表している。なお、図９においても、時間の方向は、図中の左側から右側に向かう方向とされる。また、図９の例では、時刻t1から時刻t2の間に、緊急警報（Emergency Alert）が通知されている。
【０１２９】
緊急警報が通知される時刻t1よりも前の時間帯において、受信装置２０の画面には、放送アプリケーション（BCA）による情報が、放送番組の映像に重畳表示されている（Ｄ４１）。なお、この放送アプリケーションの起動方法は、上述した第３の方式Ａ（図８のＳ３１乃至Ｓ３３）と同様であるため、ここではその説明は省略する。
【０１３０】
その後、時刻t1になったとき、受信装置２０は、送信装置１０から伝送路８０を介して通知される緊急警報を受信する。その結果、受信装置２０の画面には、放送アプリケーション（BCA）の情報とともに、焼き込みテキスト（burned - in text）の文字列が、放送番組の映像に重畳表示される（Ｄ４２）。これにより、緊急警報メッセージ（Universal Alert）としての焼き込みテキストの内容が、ユーザにより確認されることになる。
【０１３１】
また、受信装置２０は、送信装置１０から伝送路８０を介して通知されるE-AIT（autostart）を受信する（Ｓ４１）。受信装置２０において、ミドルウェア（MW）又はブラウザ（BR）は、当該E-AIT（autostart）を解析し、その解析結果に応じて、緊急警報アプリケーション（EAA1）の取得と起動を指示する（Ｓ４２）。
【０１３２】
なお、ここでは、上述した第３の方式Ａと同様に、ユーザからの指示又は設定情報（例えば表示対象地域や表示対象項目などの設定）に応じて、緊急詳細情報の表示の要否を判定することができる。例えば、緊急警報アプリケーション（EAA）の起動画面として、緊急詳細情報を受信したことを示すアイコン等を表示し、ユーザが緊急詳細情報を表示すると判断し、その表示が指示された場合にのみ、緊急詳細情報を表示させることができる。
【０１３３】
そして、受信装置２０では、ミドルウェア（MW）又はブラウザ（BR）からの指示（EAA1起動イベント）に応じて、緊急警報アプリケーション（EAA1）が取得され、起動される（Ｓ４３）。その際、起動中の放送アプリケーション（BCA）は、一時停止（suspend）又は終了（terminate）される。その結果、受信装置２０の画面には、放送アプリケーション（BCA）の情報の代わりに、緊急警報アプリケーション（EAA1）の緊急詳細情報が表示される（Ｄ４３）。なお、受信装置２０の画面では、焼き込みテキスト（burned - in text）も継続して、放送番組の映像に重畳表示されている（Ｄ４３）。
【０１３４】
これにより、緊急時において、焼き込みテキスト等の文字列による緊急警報メッセージ（Universal Alert）によって、簡易的な情報を提示するだけでなく、その情報に関心のあるユーザに対しては、アドバンスコンテンツ（Advanced Content）としての緊急警報アプリケーション（EAA）によって、例えば、静止画や動画等を含む緊急詳細情報を提示して、より詳細な情報を提供することができる。
【０１３５】
その後、受信装置２０は、送信装置１０から伝送路８０を介して通知されるイベントメッセージを受信する（Ｓ４４）。受信装置２０において、ミドルウェア（MW）又はブラウザ（BR）は、当該イベントメッセージを解析し、その解析結果に応じて、緊急警報アプリケーション（EAA1）から、緊急警報アプリケーション（EAA2）への遷移を指示する（Ｓ４５）。すなわち、ミドルウェア（MW）又はブラウザ（BR）は、当該イベントメッセージを、緊急警報アプリケーション（EAA1）に通知する。緊急警報アプリケーション（EAA1）は、イベントメッセージに記述された情報（イベント情報）に基づいて、そのイベント情報が、緊急警報アプリケーション（EAA2）への遷移指示である場合には、緊急警報アプリケーション（EAA2）に遷移する処理を実行する。
【０１３６】
そして、受信装置２０では、ミドルウェア（MW）又はブラウザ（BR）からの指示（EAA2遷移イベント）に応じて、緊急警報アプリケーション（EAA2）が取得され、起動される（Ｓ４６）。その結果、受信装置２０の画面では、緊急警報アプリケーション（EAA1）による緊急詳細情報（のページ）が更新され、緊急警報アプリケーション（EAA2）による緊急詳細情報（のページ）が表示される。ここで、緊急警報アプリケーション（EAA2）は、緊急警報アプリケーション（EAA1）により表示されるページの全部が更新されること（ページ遷移）のほか、例えば、緊急警報アプリケーション（EAA1）により表示されるページの一部が更新されることなどを意味するものである。
【０１３７】
これにより、緊急警報メッセージに関心のあるユーザに対して、最初に提示された緊急詳細情報（図中の「EAA1」）とは異なる緊急詳細情報（図中の「EAA2」）を提示して、さらに詳細な情報を提供することができる。
【０１３８】
その後、時刻t2を経過すると、送信装置１０からの緊急警報の通知が終了される。また、受信装置２０は、送信装置１０から伝送路８０を介して通知されるE-AIT（terminate）を受信する（Ｓ４７）。受信装置２０において、ミドルウェア（MW）又はブラウザ（BR）は、当該E-AIT（terminate）を解析し、その解析結果に応じて、起動中の緊急警報アプリケーション（EAA(EAA2)）の終了を指示する（Ｓ４８）。
【０１３９】
そして、受信装置２０では、ミドルウェア（MW）又はブラウザ（BR）からの指示（EAA(EAA2)終了イベント）に応じて、起動中の緊急警報アプリケーション（EAA(EAA2)）が終了される（Ｓ４９）。また、緊急警報アプリケーション（EAA1）を起動する際に、放送アプリケーション（BCA）が一時停止（suspend）されていた場合には、当該放送アプリケーション（BCA）の実行が再開される（起動される）。その結果、受信装置２０の画面には、焼き込みテキスト（burned - in text）と緊急詳細情報（図中の「EAA2」）の表示が消えて、放送アプリケーション（BCA）の情報が、放送番組の映像に重畳表示される（Ｄ４５）。つまり、受信装置２０の画面の表示は、緊急警報が通知される前の状態（Ｄ４１）に戻ったことになる。
【０１４０】
以上のように、第３の方式Ｂでは、ミドルウェア（MW）又はブラウザ（BR）が、E-AITに基づいて、緊急警報アプリケーション（EAA）を表示すると判定した場合にのみ、緊急警報アプリケーション（EAA）が起動されるので、例えば、緊急警報アプリケーション（EAA）が無駄に起動されることが防止されるなど、受信装置２０における処理の負荷を軽減することができる。また、第３の方式Ｂでは、ミドルウェア（MW）又はブラウザ（BR）が、イベントメッセージに基づいて、緊急警報アプリケーション（EAA）に関する処理（例えばライフサイクルの制御や、時間の経過による緊急警報の更新に伴う緊急警報アプリケーション（EAA）の遷移など）を制御することができる。
【０１４１】
なお、ここでは、緊急警報アプリケーション（EAA）の起動方式として、第１の方式乃至第３の方式について説明したが、これらの方式は説明の便宜上使用しているだけであり、第１の方式乃至第３の方式以外の他の起動方式が採用されるようにしてもよい。
【０１４２】
（E-AITのシンタックス）
図１０は、XML形式のE-AITのシンタックスの例を示す図である。なお、図１０において、要素と属性のうち、属性には「@」が付されている。また、インデントされた要素と属性は、その上位の要素に対して指定されたものとなる。
【０１４３】
E-AITは、ServiceDiscovery要素、及び、ApplicationDiscovery要素を含む。ApplicationDiscovery要素は、ルート要素（属性）として、DomainName属性、Version属性、EmergencyApplicationList要素、EmergencyApplication要素、及び、CAPMessage要素を含む。
【０１４４】
DomainName属性には、ドメイン名が指定される。Version属性には、バージョンが指定される。EmergencyApplicationList要素には、現行のプログラムで実行可能な緊急警報アプリケーション（EAA）のリストが指定される。
【０１４５】
EmergencyApplication要素には、緊急警報アプリケーション（EAA）に関する情報が指定される。EmergencyApplication要素は、appName要素、applicationIdentifier要素、CAPMessage要素、emergencyAlert要素、applicationDescriptor要素、applicationTransport要素、applicationLocation要素、及び、applicationBoundary要素の上位要素となる。
【０１４６】
appName要素には、緊急警報アプリケーション（EAA）の名称が指定される。appName要素は、language属性の上位要素となる。このlanguage属性には、ISO 639-2で規定される言語コードが指定される。
【０１４７】
applicationIdentifier要素は、orgId要素、及び、appId要素の上位要素となる。orgId要素には、組織IDが指定される。appId要素には、アプリケーションIDが指定される。すなわち、組織IDとアプリケーションIDの組み合わせにより、グローバルでユニークなアプリケーションIDが指定されることになる。
【０１４８】
CAPMessage要素には、CAP情報を配置することができる。すなわち、緊急警報アプリケーション（EAA）単位で、CAP情報を関連付ける場合には、このEmergencyApplication要素のCAPMessage要素に、CAP情報を配置することになる。
【０１４９】
emergencyAlert要素は、緊急警報（の詳細情報）に関する情報（基本情報）が指定される。emergencyAlert要素は、senderName属性、sentTime属性、category属性、priority属性、alertStatusCode属性、urgency属性、severity属性、及び、area要素の上位要素となる。
【０１５０】
senderName属性には、例えば米国連邦緊急事態管理庁（FEMA）や放送局等の緊急警報の発行元を示す情報が指定される。sentTime属性には、緊急警報の発行された時刻を示す情報が指定される。
【０１５１】
category属性には、緊急警報のカテゴリが指定される。このカテゴリとしては、例えば、"Geo(Geophysical)"，"Met(Meteorological)"，"Safety"などの緊急警報を分類するための情報が、運用に応じて指定される。
【０１５２】
priority属性には、緊急警報の優先度を示す情報が指定される。この優先度を示す情報としては、例えば、0，1，2，3，・・・などの数値が指定される。ここでは、例えば、0が最も優先度が低く、数値が大きくなるほど、優先度が高くなるなど、優先度の割り当ては運用により決定される。
【０１５３】
alertStatusCode属性には、例えば、テスト用であるのか、あるいは本番用であるのかなどの緊急警報の状態を示すコードが指定される。このコードとしては、例えば、"exercise"，"actual"，"system"，"test"，"draft"などが指定される。
【０１５４】
urgency属性には、緊急警報の緊急性を示す情報が指定される。この緊急性を示す情報としては、例えば、"immediate"，"expected"，"future"，"past"などが指定される。ここで、"immediate"は、すぐに避難することなどが求められることを意味する。"expected"は、まもなく（例えば１時間以内に）、避難などを開始することが求められることを意味する。"future"は、まもなく（"expected"より時間はある）避難などを開始することが求められることを意味する。"past"は、もう避難の必要はないことを意味する。
【０１５５】
severity属性には、緊急警報の重大性を示す情報が指定される。この重大性を示す情報としては、例えば、"extreme"，"severe"，"moderate"，"minor"など、緊急警報の重大性を分類するための情報が、運用に応じて指定される。
【０１５６】
area要素には、緊急警報の対象地域を示す情報（コード）が指定される。area要素は、type属性の上位要素となる。type属性には、対象地域を示す情報（コード）のタイプが指定される。このタイプとしては、例えば、"zip"や、"latitude/longitude"が指定される。
【０１５７】
ここで、"zip"は、例えば米国郵政公社（USPS）が使用する5桁又は9桁の郵便番号（ZIP code）により対象地域が指定されることを表している。また、"latitude/longitude"は、緯度と経度により対象地域が指定されることを表している。
【０１５８】
なお、emergencyAlert要素で指定される緊急警報に関する情報（基本情報）は、主に、緊急警報アプリケーション（EAA）の起動時の判定処理（緊急詳細情報の表示の要否判定）で用いられるものであって、その判定条件は運用ごとに異なるので、基本情報には、上述した情報に限らず、当該判定処理の内容に応じた情報を指定することができる。また、emergencyAlert要素の配下の要素又は属性のうち、alertStatusCode属性は、必須の属性となるが、それ以外の要素や属性を指定するかどうかは、任意である。
【０１５９】
applicationDescriptor要素には、緊急警報アプリケーション（EAA）に関する情報が指定される。applicationDescriptor要素は、type要素、controlCode要素、serviceBound要素、priority要素、icon要素の上位要素となる。
【０１６０】
type要素は、AtscApp要素の上位要素となる。AtscApp要素には、緊急警報アプリケーション（EAA）のタイプが指定される。このタイプとしては、例えば、HTML5で開発されたアプリケーションであることを示す"ATSC-HTML"が指定される。
【０１６１】
controlCode要素には、緊急警報アプリケーション（EAA）に対する制御コード（コマンド）が指定される。この制御コードとしては、例えば、"AUTOSTART"，"PRESENT"，"KILL"，"TERMINATE"，"PREFETCH"，"SUSPEND"のうちのいずれかが指定される。
【０１６２】
ここで、"AUTOSTART"は、緊急警報アプリケーション（EAA）を自動的に即時に実行させるためのコマンドである。"PRESENT"は、緊急警報アプリケーション（EAA）を自動実行させないためのコマンドである。"KILL"と"TERMINATE"は、緊急警報アプリケーション（EAA）を終了させるためのコマンドである。なお、本実施の形態では、緊急警報アプリケーション（EAA）を終了させるためのコマンドとして、"TERMINATE"が用いられる場合を例示しているが、"TERMINATE"の代わりに、"KILL"が指定されるようにしてもよい。
【０１６３】
"PREFETCH"は、緊急警報アプリケーション（EAA）を放送経由又は通信経由で取得させるためのコマンドである。"SUSPEND"は、緊急警報アプリケーション（EAA）を一時停止させるためのコマンドである。なお、"DESTROY"，"REMOTE"，"DISABLED"，及び、"PLAYBACK_AUTOSTART"は、制御コードとして使用されるべきものではない。
【０１６４】
serviceBound要素には、緊急警報アプリケーション（EAA）が連動して動作するサービス等の範囲が指定される。priority要素には、同一のアプリケーションのタイプ内での優先度が指定される。
【０１６５】
icon要素には、緊急警報アプリケーション（EAA）のアイコンに関する情報が指定される。icon要素は、filename属性、及び、size属性の上位要素となる。filename属性には、アイコンのファイル名に関する情報が指定される。size属性には、アイコンのサイズに関する情報が指定される。
【０１６６】
applicationTransport要素には、緊急警報アプリケーション（EAA）の転送方法とロケーション情報が指定される。applicationTransport要素は、URLBase要素、及び、URLExtension要素の上位要素となる。URLBase要素には、ベース部分のURLが指定される。また、URLExtension要素には、拡張部分のURLが指定される。applicationLocation要素には、緊急警報アプリケーション（EAA）のファイルのURLが指定される。すなわち、ベース部分（first part）のURLと、拡張部分（second part）のURLと、ファイル部分（third part）のURLとの結合により、緊急警報アプリケーション（EAA）のロケーション情報（URL）が指定される。
【０１６７】
applicationBoundary要素には、緊急警報アプリケーション（EAA）の動作範囲を示す情報（バウンダリ情報）が指定される。このバウンダリ情報には、特定のドメインが指定され、当該ドメインの範囲内であれば、緊急警報アプリケーション（EAA）の動作が許容されることになる。なお、このドメインの代わりに、上述の緊急警報アプリケーション（EAA）のロケーション情報（URL）を用いるようにしてもよい。
【０１６８】
（ルート要素の）CAPMessage要素には、CAP情報を配置することができる。すなわち、E-AITに記述される（複数の）緊急警報アプリケーション（EAA）のすべてに対して、同一のCAP情報を関連付ける場合（E-AIT全体でCAP情報を伝送する場合）には、このルート要素のCAPMessage要素に、CAP情報を配置することになる。
【０１６９】
なお、図１０において、出現数（Cardinality）であるが、"1"が指定された場合にはその要素又は属性は必ず１つだけ指定され、"0..1"が指定された場合には、その要素又は属性を指定するかどうかは任意である。また、"1..N"が指定された場合には、その要素又は属性は１以上指定され、"0..N"が指定された場合には、その要素又は属性を１以上指定するかどうかは任意である。
【０１７０】
また、Data Typeとして、"string"が指定された場合には、その要素又は属性の値が、文字列型であることを示している。Data Typeとして、"unsignedShort"又は"unsignedInt"が指定された場合、その要素又は属性の値が、整数型であることを示している。Data Typeとして、"Boolean"が指定された場合には、その要素又は属性がブール型であることを示し、"Hexadecimal"が指定された場合、その要素又は属性が16進数であることを示している。Data Typeとして、"anyURI"が指定された場合、その要素又は属性の値が、anyURIデータ型であることを示している。
【０１７１】
なお、図１０に示したE-AITのシンタックスは、一例であって、例えば、他の要素や属性を追加するなど、他のシンタックスを採用してもよい。また、E-AITは、XML形式に限らず、他のマークアップ言語により記述してもよいし、あるいはセクション形式であってもよい。
【０１７２】
（イベントメッセージの伝送方式）
ところで、上述したように、受信装置２０では、イベントメッセージに基づいて、緊急警報アプリケーション（EAA）に関する処理を行うことができるが、このイベントメッセージは、例えば、MPDのイベントストリーム要素、又は、ROUTEセッションで伝送されるDASHセグメントのイベントメッセージボックスに配置することができる。そこで、以下、イベントメッセージが、MPDのイベントストリーム要素に配置された場合と、イベントメッセージが、DASHセグメントのイベントメッセージボックスに配置された場合を、その順番で説明する。なお、トランスポート・プロトコルとして、ROUTEの代わりに、MMTを用いる場合には、MPDのイベントストリーム要素と同様の要素が、MMTシグナリングの一部として伝送されたり、あるいは、独立したシグナリングのデータとして伝送されたりするようにすればよい。また、イベントメッセージは、DASHセグメントではなく、MMTのメディアセグメントに埋め込まれて伝送されるようにしてもよい。
【０１７３】
（１）イベントメッセージをMPDのイベントストリーム要素に配置する場合
【０１７４】
（MPDの記述例）
図１１は、XML形式のMPDの記述例を示す図である。
【０１７５】
図１１に示すように、MPDは、Period要素、AdaptationSet要素、及び、Representation要素が、階層構造で記述されている。Period要素は、放送番組等のコンテンツの構成を記述する単位となる。また、AdaptationSet要素、及び、Representation要素は、ビデオやオーディオ、字幕等のコンポーネントのストリームごとに利用され、それぞれのストリームの属性を記述できるようになっている。
【０１７６】
具体的には、AdaptationSet要素は、各種のソースからエンコードされたストリームを表している。そして、当該ストリームを、例えばビットレート等のパラメトリックに応じて、受信装置２０側で選択させるために、AdaptationSet要素内に、Representation要素を配置して、例えばビットレート等のパラメータが異なる複数の選択肢となるストリームを列挙している。通常、AdaptationSet要素やRepresentation要素は、ビデオやオーディオ、字幕のストリームなど、単一のストリームに対応させている。
【０１７７】
また、AdaptationSet要素が、ビデオストリームやオーディオストリーム、字幕ストリームなどの複数のストリームが多重化されたストリームを表現する場合、AdaptationSet要素内に、Representation要素を配置して、例えばビットレート等のパラメータが異なる複数の選択肢となる多重化されたストリームを列挙する。すなわち、時間間隔を表すPeriod要素ごとに、多重化されたストリームを表す複数のAdaptationSet要素が配置され、それらのAdaptationSet要素内に配置された複数のRepresentation要素により、例えばビットレートが異なる多重化されたストリームを複数列挙することができる。
【０１７８】
また、MPDでは、Period要素内に、EventStream要素を記述することができる。このEventStream要素に、イベントメッセージを配置することができる。
【０１７９】
EventStream要素には、その属性として、schemeIdUri属性と、timescale属性を記述することができる。schemeIdUri属性には、イベントメッセージのスキームを識別するためのURIが指定される。この記述例では、schemeIdUri属性の属性値として、"urn:atsc:appControlMessage"が指定されており、この属性値によって、緊急警報（緊急警報アプリケーション（EAA））に関するイベントメッセージであることが識別される。また、timescale属性には、その属性値として、'1000'であるタイムスケールが指定されている。
【０１８０】
EventStream要素は、Event要素の上位要素となる。Event要素には、その開始タグと終了タグとの間に、イベントメッセージを記述することができる。また、Event要素には、その属性として、プレゼンテーションタイム（開始時刻）が指定されるpresentationTime属性と、その開始時刻からの期間が指定されるduration属性を指定することができる。
【０１８１】
例えば、この記述例では、EventStream要素の開始タグと終了タグの間に、２つのEvent要素が記述されているが、上側のEvent要素では、'0'である開始時刻から、'1000'である期間の間に、「緊急警報アプリ情報１」に記述された内容が、イベントメッセージとして発行されることを表している。また、下側のEvent要素では、'1000'である開始時刻から、'4000'である期間の間に、「緊急警報アプリ情報２」に記述された内容が、イベントメッセージとして発行されることを表している。
【０１８２】
ここで、「緊急警報アプリ情報１」や「緊急警報アプリ情報２」には、例えば、E-AIT（図１０）のemergencyAlert要素で指定される緊急警報に関する情報（基本情報）や、緊急警報アプリケーション（EAA）の制御情報などが含まれる。したがって、受信装置２０では、このイベントメッセージに基づいて、例えば、緊急警報アプリケーション（EAA）を更新するなど、緊急警報アプリケーション（EAA）に関する処理を行うことができる。
【０１８３】
なお、MPDのEventStream要素は、図１２に示すような構造を有しており、上述した図１１のMPDの記述例に限らず、他の要素や属性の組み合わせなどにより、イベントメッセージを伝送することが可能である。
【０１８４】
（MPDのEventStream要素の構造）
図１２は、MPDのEventStream要素の構造の例を示す図である。
【０１８５】
図１２に示すように、EventStream要素は、xlink:href属性、xlink:actuate属性、schemeIdUri属性、value属性、timescale属性、及び、Event要素の上位要素となる。
【０１８６】
xlink:href属性には、外部のイベントストリーム要素のURIが指定される。xlink:actuate属性には、トラバーサル（traversal）のタイミングが指定される。なお、XLink(XML Linking Language)は、XML文書同士のリンクを定義するための仕様である。
【０１８７】
schemeIdUri属性には、イベントメッセージのスキームを識別するためのURIが指定される。value属性には、EventStream要素の値が、属性値として指定される。timescale属性には、タイムスケールを示す情報が指定される。Event要素には、イベントに関する情報が指定される。
【０１８８】
（EventStream要素の具体例）
ここで、図１２に示した構造を有するEventStream要素によって、緊急警報（の詳細情報）に関するイベントメッセージを通知する場合の構造の具体例を、図１３乃至図１５に例示する。
【０１８９】
（第１の具体例）
図１３は、EventStream要素の構造の第１の具体例を示す図である。
【０１９０】
図１３においては、EventStream要素のschemeIdUri属性として、"urn:atsc3:us:emergency_info"が指定されている。すなわち、このschemeIdUri属性の属性値により、緊急警報（緊急警報アプリケーション（EAA））に関するイベントメッセージであることが識別される。
【０１９１】
EventStream要素のvalue属性には、その属性値として、例えば、E-AIT（図１０）のemergencyAlert要素のcategory属性の属性値、priority属性の属性値、urgency属性の属性値、severity属性の属性値、及び、area要素とそのtype属性の値のうち、少なくとも１つの情報が、カンマ区切りで指定される。
【０１９２】
このようなイベントメッセージが、SLSシグナリングとして、サービスごとに伝送されるMPDに含まれるので、受信装置２０は、MPDに含まれるイベントメッセージに基づいて、所定のタイミングで、緊急警報アプリケーション（EAA）に関する処理を行うことができる。
【０１９３】
なお、EventStream要素のvalue属性に指定される要素や属性は、E-AIT（図１０）のemergencyAlert要素で指定される緊急警報に関する情報（基本情報）に対応しており、図１３に示したvalue属性で指定される情報に限らず、各種の運用に応じた情報を指定することができる。また、基本情報に限らず、例えば、緊急警報アプリケーション（EAA）の制御情報などが指定されるようにしてもよい。
【０１９４】
（第２の具体例）
図１４は、EventStream要素の構造の第２の具体例を示す図である。
【０１９５】
図１４においては、EventStream要素のschemeIdUri属性として、"urn:atsc3:us:emergency_info"が指定されている。すなわち、このschemeIdUri属性の属性値により、緊急警報（緊急警報アプリケーション（EAA））に関するイベントメッセージであることが識別される。
【０１９６】
EventStream要素のEvent要素は、category要素、priority要素、urgency要素、severity要素、及び、area要素の上位要素となる。また、area要素は、type属性の上位要素となる。なお、これらの要素や属性は、E-AIT（図１０）のemergencyAlert要素の要素や属性に対応している。
【０１９７】
このようなイベントメッセージが、SLSシグナリングとして、サービスごとに伝送されるMPDに含まれているので、受信装置２０は、MPDに含まれるイベントメッセージに基づいて、所定のタイミングで、緊急警報アプリケーション（EAA）に関する処理を行うことができる。
【０１９８】
なお、EventStream要素のEvent要素の配下に指定される要素や属性は、E-AIT（図１０）のemergencyAlert要素で指定される緊急警報に関する情報（基本情報）に対応しており、図１４に示したEvent要素の配下に指定される要素や属性で指定される情報に限らず、各種の運用に応じた情報を指定することができる。また、基本情報に限らず、例えば、緊急警報アプリケーション（EAA）の制御情報などが指定されるようにしてもよい。
【０１９９】
（第３の具体例）
図１５は、EventStream要素の構造の第３の具体例を示す図である。
【０２００】
図１５においては、EventStream要素のschemeIdUri属性として、"urn:atsc3:us:emergency_info"が指定されている。すなわち、このschemeIdUri属性の属性値により、緊急警報（緊急警報アプリケーション（EAA））に関するイベントメッセージであることが識別される。
【０２０１】
EventStream要素のEvent要素には、XMLで規定されているCDATAセクション内に、CAP情報が配置されている。このCAP情報は、緊急情報源からの緊急情報源情報に応じた情報である。
【０２０２】
このようなイベントメッセージ（CPA情報）が、SLSシグナリングとして、サービスごとに伝送されるMPDに含まれているので、受信装置２０は、MPDに含まれるイベントメッセージ（CPA情報）に基づいて、所定のタイミングで、緊急警報アプリケーション（EAA）に関する処理を行うことができる。
【０２０３】
なお、EventStream要素のEvent要素において、CDATAセクション内に配置される情報は、CAP情報に限らず、各種の運用に応じた情報を配置することができる。
【０２０４】
（２）DASHセグメントのイベントメッセージボックスに配置する場合
【０２０５】
（イベントメッセージボックスの構造）
図１６は、ROUTEセッションで伝送されるDASHセグメントのイベントメッセージボックス（'emsg'ボックス）の構造の例を示す図である。
【０２０６】
DASHセグメントのイベントメッセージボックスには、scheme_id_uri，value，timescale，presentation_time_delta，event_duration，id，及び、message_data[]が格納される。
【０２０７】
文字列型のscheme_id_uriには、イベントメッセージのスキームを識別するためのURIが指定される。文字列型のvalueには、各種の値が指定される。
【０２０８】
32ビットの符号なし整数型のtimescaleは、タイムスケールを示す情報が指定される。32ビットの符号なし整数型のpresentation_time_deltaには、プレゼンテーションタイム（開始時刻）を示す情報が指定される。32ビットの符号なし整数型のevent_durationには、イベントメッセージの期間を示す情報が指定される。
【０２０９】
32ビットの符号なし整数型のidには、イベントメッセージを識別するための情報が指定される。8ビットの符号なし整数型のmessage_data[]には、イベントメッセージのデータが配置される。
【０２１０】
（DASHメッセージボックスの具体例）
ここで、図１６に示した構造を有するイベントメッセージボックスで、緊急警報（の詳細情報）に関するイベントメッセージを通知する場合の具体例を、図１７乃至図１８に例示する。
【０２１１】
（第１の具体例）
図１７は、DASHセグメントのイベントメッセージボックスの構造の第１の具体例を示す図である。
【０２１２】
図１７においては、box_typeとして、イベントメッセージボックスを意味する'emsg'が指定されている。また、scheme_id_uriには、"urn:atsc3:us:emergency_info"が指定されている。すなわち、このscheme_id_uriにより、緊急警報（緊急警報アプリケーション（EAA））に関するイベントメッセージであることが識別される。なお、valueには、0が指定されている。
【０２１３】
timescaleには、タイムスケールとして、1000が指定されている。また、presentation_time_deltaには、プレゼンテーションタイム（開始時刻）として、0が指定されている。さらに、event_durationには、イベントメッセージの期間として、0xFFFFが指定されている。
【０２１４】
idには、イベントメッセージIDとして、1が指定されている。message_data[]には、イベントメッセージのデータとして、緊急警報関連データ１が配置されている。この緊急警報関連データ１としては、E-AIT（図１０）のemergencyAlert要素で指定される緊急警報に関する情報（基本情報）を配置することができる。また、基本情報に限らず、例えば、緊急警報アプリケーション（EAA）の制御情報などが指定されるようにしてもよい。さらに、ここには、CAP情報などが配置されるようにしてもよい。
【０２１５】
なお、図１７の例では、message_data[]に、イベントメッセージのデータ（E-AITの基本情報）を配置しているが、valueに、イベントメッセージのデータ（E-AITの基本情報）が、カンマ区切りで配置されるようにしてもよい。
【０２１６】
（第２の具体例）
図１８は、DASHセグメントのイベントメッセージボックスの構造の第２の具体例を示す図である。
【０２１７】
図１８においては、box_typeとして、イベントメッセージボックスを意味する'emsg'が指定されている。また、scheme_id_uriには、"urn:atsc3:us:emergency_info"が指定されている。すなわち、このscheme_id_uriにより、緊急警報（緊急警報アプリケーション（EAA））に関するイベントメッセージであることが識別される。なお、valueには、0が指定されている。
【０２１８】
timescaleには、タイムスケールとして、1000が指定されている。また、presentation_time_deltaには、プレゼンテーションタイム（開始時刻）として、0が指定されている。さらに、event_durationには、イベントメッセージの期間として、0xFFFFが指定されている。
【０２１９】
idには、イベントメッセージIDとして、2が指定されている。message_data[]には、イベントメッセージのデータとして、緊急警報関連データ２が配置されている。この緊急警報関連データ２としては、E-AIT（図１０）のemergencyAlert要素で指定される緊急警報に関する情報（基本情報）を配置することができる。また、基本情報に限らず、例えば、緊急警報アプリケーション（EAA）の制御情報などが指定されるようにしてもよい。さらに、ここには、CAP情報などが配置されるようにしてもよい。
【０２２０】
なお、図１８の例では、message_data[]に、イベントメッセージのデータ（E-AITの基本情報）を配置しているが、valueに、イベントメッセージのデータ（E-AITの基本情報）が、カンマ区切りで配置されるようにしてもよい。
【０２２１】
＜２．各装置の構成＞
【０２２２】
次に、図１の伝送システム１を構成する各装置の詳細な構成について説明する。ここでは、放送局により設置される送信装置１０の構成と、ユーザにより設置される受信装置２０の構成を中心に説明する。
【０２２３】
図１９は、伝送システム１の各装置の構成例を示す図である。
【０２２４】
図１９において、送信装置１０は、EAパーサ１０１、ライブコンテンツ取得部１０２、ストレージ１０３、コンポーネント処理部１０４、シグナリング処理部１０５、LCC処理部１０６、エンコーダ１０７、マルチプレクサ１０８、変調部１０９、及び、RF部１１０から構成される。
【０２２５】
EAパーサ１０１は、緊急時に、緊急情報源（EA Authority）から通知される緊急情報源情報としてのCAP情報を取得し、解析する。EAパーサ１０１は、CAP情報の解析結果を、コンポーネント処理部１０４、シグナリング処理部１０５、又はLCC処理部１０６に供給する。
【０２２６】
ライブコンテンツ取得部１０２は、コンポーネント処理部１０４からの要求に応じて、例えば、中継場所から伝送路や通信回線を介して送られてくるライブコンテンツ（例えば、スポーツ中継等の生放送番組）のデータを取得し、コンポーネント処理部１０４に供給する。このライブコンテンツは、ビデオやオーディオ、字幕などのコンポーネントから構成される。
【０２２７】
ストレージ１０３は、例えば、収録済みのコンテンツ（例えば、ドラマ等の事前収録番組）を蓄積している。ストレージ１０３は、コンポーネント処理部１０４からの要求に応じて、蓄積している収録済みのコンテンツを、コンポーネント処理部１０４に供給する。この収録済みコンテンツは、ビデオやオーディオ、字幕などのコンポーネントから構成される。
【０２２８】
コンポーネント処理部１０４は、ライブコンテンツ取得部１０２からのライブコンテンツ、又はストレージ１０３からの収録済みコンテンツを取得し、取得されたコンテンツを構成するビデオやオーディオのコンポーネントを処理し、エンコーダ１０７に供給する。
【０２２９】
エンコーダ１０７は、コンポーネント処理部１０４から供給される、ビデオやオーディオのコンポーネントのデータを、所定の符号化方式に従ってエンコードし、マルチプレクサ１０８に供給する。
【０２３０】
また、緊急時には、受信装置２０の画面に、焼き込みテキスト（EA Text）を表示させるので、EAパーサ１０１からのCAP情報の解析結果が、コンポーネント処理部１０４に供給される。コンポーネント処理部１０４は、EAパーサ１０１からCAP情報の解析結果が供給された場合、コンテンツ（例えば生放送番組や事前収録番組）の映像（非圧縮のビデオデータ）に、EAパーサ１０１からのCAP情報の解析結果に応じた緊急警報（テキスト情報）を埋め込む。そして、エンコーダ１０７は、所定の符号化方式に従い、緊急警報（テキスト情報）が埋め込まれたビデオデータをエンコードすることになる。
【０２３１】
シグナリング処理部１０５は、LLSシグナリングやSLSシグナリングなどのシグナリングを生成し、マルチプレクサ１０８に供給する。例えば、LLSシグナリングとしては、SLTメタデータなどが生成される。また、SLSシグナリングとしては、USD，S-TSID，MPD等のメタデータが生成される。
【０２３２】
また、シグナリング処理部１０５は、緊急時に、EAパーサ１０１からCAP情報の解析結果が供給された場合、CAP情報の解析結果に応じたE-AITを生成し、マルチプレクサ１０８に供給する。このE-AITには、緊急警報（の詳細情報）に関する情報や、緊急警報アプリケーション（EAA）の制御情報などが含まれる。
【０２３３】
LCC処理部１０６は、LCCコンテンツが提供される場合に、例えば放送アプリケーション（BCA）等のLCCコンテンツを生成し、マルチプレクサ１０８に供給する。また、LCC処理部１０６は、緊急時に、EAパーサ１０１からCAP情報の解析結果が供給された場合、当該CAP情報の解析結果に基づいて、緊急警報アプリケーション（EAA）を生成し、マルチプレクサ１０８に供給する。
【０２３４】
マルチプレクサ１０８は、エンコーダ１０７から供給されるコンポーネントのストリームと、シグナリング処理部１０５から供給されるシグナリングのストリームを多重化して、多重化ストリームを生成し、変調部１０９に供給する。また、マルチプレクサ１０８は、LCCコンテンツ（例えば放送アプリケーション（BCA）や緊急警報アプリケーション（EAA））が提供される場合には、コンポーネントとシグナリングのストリームに加えて、LCC処理部１０６から供給されるLCCコンテンツ（例えば放送アプリケーション（BCA）や緊急警報アプリケーション（EAA））のストリームを多重化して、多重化ストリームを生成する。
【０２３５】
変調部１０９は、マルチプレクサ１０８から供給される多重化ストリームのデータに対する誤り訂正符号化処理（例えば、BCH符号化やLDPC符号化等）や変調処理（例えば、OFDM(Orthogonal Frequency Division Multiplexing)変調等）を行い、その処理の結果得られる信号を、RF部１１０に供給する。
【０２３６】
RF部１１０は、変調部１０９から供給される信号を、RF(Radio Frequency)信号に変換し、アンテナ（不図示）を介して、IP伝送方式のデジタル放送信号として、送信する。
【０２３７】
送信装置１０は、以上のように構成される。なお、図１９においては、説明の都合上、送信側の装置が、送信装置１０、すなわち、１つの装置で構成される場合を示しているが、図１９のブロックの各機能を有する複数の装置からなる送信システムとして構成されるようにしてもよい。また、送信装置１０が通信機能を有するようにすることで、緊急警報アプリケーション（EAA）が、送信装置１０からEAサーバ４０に提供されるようにしてもよい。
【０２３８】
また、図１９において、受信装置２０は、RF部２０１、復調部２０２、処理部２０３、出力部２０４、及び、通信I/F２０５から構成される。
【０２３９】
RF部２０１は、アンテナ（不図示）を介して、IP伝送方式のデジタル放送信号を受信して、RF信号を、IF(Intermediate Frequency)信号に周波数変換し、復調部２０２に供給する。なお、RF部２０１は、RF IC(Integrated Circuit)として構成される。
【０２４０】
復調部２０２は、RF部２０１から供給される信号に対する復調処理（例えばOFDM復調等）を行う。また、復調部２０２は、復調処理で得られる復調信号に対して、誤り訂正復号処理（例えばLDPC復号やBCH復号等）を施し、その処理の結果得られる信号を、処理部２０３に供給する。なお、復調部２０２は、例えば、復調LSI(Large Scale Integration)として構成される。
【０２４１】
処理部２０３は、復調部２０２から供給される信号に対する処理（例えばデコード処理など）を行い、その処理の結果得られるビデオやオーディオのデータを、出力部２０４に供給する。
【０２４２】
なお、処理部２０３は、例えば、メインSoC(System on Chip)として構成される。すなわち、復調LSIとしての復調部２０２と、メインSoCとしての処理部２０３とは、異なるチップ（Chip）として構成され、所定のインターフェースを介して接続されている。
【０２４３】
処理部２０３は、FW/HW部２１１、コンポーネント処理部２１２、MW部２１３、及び、ブラウザ２１４から構成される。
【０２４４】
FW/HW部２１１は、ファームウェア（FW：Firmware）又はハードウェア（HW：Hardware）により構成され、復調部２０２からの信号に対する処理を行う。FW/HW部２１１は、デマルチプレクサ２２１及びデコーダ２２２を含んで構成される。
【０２４５】
デマルチプレクサ２２１には、復調部２０２から供給される信号として、多重化ストリームが入力される。デマルチプレクサ２２１は、多重化ストリームを、ビデオやオーディオ等のコンポーネントのストリームと、シグナリングのストリームに分離して、デコーダ２２２と、MW部２１３に供給する。また、デマルチプレクサ２２１は、多重化ストリームに、LCCコンテンツ（例えば放送アプリケーション（BCA）や緊急警報アプリケーション（EAA））のストリームが含まれる場合、LCCコンテンツ（例えば放送アプリケーション（BCA）や緊急警報アプリケーション（EAA））のストリームを分離して、ブラウザ２１４に供給する。
【０２４６】
デコーダ２２２は、デマルチプレクサ２２１から供給されるコンポーネントのストリームに基づいて、ビデオやオーディオのコンポーネントのデータをデコードし、コンポーネント処理部２１２に供給する。また、デマルチプレクサ２２１及びデコーダ２２２は、DASHセグメントにイベントメッセージが含まれている場合には、当該イベントメッセージを解析して、その解析結果に応じて、ブラウザ２１４を制御することになる。
【０２４７】
コンポーネント処理部２１２は、デコーダ２２２から供給されるビデオやオーディオのデータを処理し、出力部２０４に供給する。
【０２４８】
ただし、緊急時において、コンテンツ（例えば生放送番組や事前収録番組）の映像（非圧縮のビデオデータ）には、緊急警報（テキスト情報）が埋め込まれており、これが、焼き込みテキスト（burned - in text）として表示されることになる。
【０２４９】
MW部２１３は、ミドルウェア（MW：Middleware）により構成され、デマルチプレクサ２２１から供給されるシグナリングのストリームに対する処理を行う。MW部２１３は、パーサ２３１、及び、フィルタ２３２から構成される。パーサ２３１は、対象のシグナリングの解析処理を行う。フィルタ２３２は、対象のシグナリングの抽出処理を行う。
【０２５０】
そして、処理部２０３では、MW部２１３で処理されたシグナリングに基づいて、コンポーネントやアプリケーション等に対する処理が行われる。ただし、緊急時においては、送信装置１０からE-AITが通知されるので、MW部２１３は、当該E-AITを解析して、その解析結果に応じて、ブラウザ２１４を制御することになる。また、MW部２１３は、MPDにイベントメッセージが含まれる場合には、当該イベントメッセージを解析して、その解析結果に応じて、ブラウザ２１４を制御することになる。
【０２５１】
ブラウザ２１４は、例えば、HTML5に対応したブラウザであり、デマルチプレクサ２２１から供給される、放送アプリケーション（BCA）や緊急警報アプリケーション（EAA）を実行する。この緊急警報アプリケーション（EAA）によって、緊急詳細情報が表示されることになる（図中の「EAA」）。
【０２５２】
出力部２０４は、コンポーネント処理部２１２から供給されるビデオデータを処理し、表示部（不図示）に出力する。また、出力部２０４は、コンポーネント処理部２１２から供給されるオーディオデータを処理し、スピーカ（不図示）に出力する。これにより、表示部では、生放送番組や事前収録番組等のコンテンツの映像が表示され、その映像に同期した音声が、スピーカから出力される。
【０２５３】
ただし、緊急時において、表示部には、緊急警報に応じた焼き込みテキスト（burned - in text）が埋め込まれた、生放送番組等のコンテンツの映像が表示されることになる。また、緊急時において、E-AITに応じて、緊急警報アプリケーション（EAA）が起動された場合には、生放送番組等のコンテンツの映像に、緊急詳細情報が重畳表示されることになる。
【０２５４】
通信I/F２０５は、インターネット等の通信回線９０を介して、EAサーバ４０と各種のデータをやりとりする。
【０２５５】
例えば、通信I/F２０５は、E-AITの解析結果に応じて、通信回線９０を介してEAサーバ４０に対して、緊急警報アプリケーション（EAA）を要求することで、EAサーバ４０から配信される緊急警報アプリケーション（EAA）を受信し、処理部２０３のブラウザ２１４に供給することができる。これにより、ブラウザ２１４は、EAサーバ４０から配信される緊急警報アプリケーション（EAA）を実行（起動）することができる。
【０２５６】
受信装置２０は、以上のように構成される。なお、受信装置２０は、テレビ受像機、セットトップボックス（STB：Set Top Box）、又は、録画機などの固定受信機のほか、携帯電話機、スマートフォン、又はタブレット端末などのモバイル受信機であってもよい。また、受信装置２０は、車両に搭載される車載機器でもよい。さらに、図１９の受信装置２０の構成では、表示部とスピーカが、外部に設けられる構成を示したが、表示部とスピーカは、受信装置２０の内部に設けられるようにしてもよい。また、図１９には、図示していないが、受信装置２０には、レジデントアプリケーション（RA）が内蔵されており、このレジデントアプリケーション（RA）により各種の処理が実行される。
【０２５７】
（BCAとEAAの起動シーケンス）
図２０は、図１９の受信装置２０における、HTML5アプリケーション（BCA，EAA）の起動シーケンスの例を示す図である。
【０２５８】
図２０において、放送・通信I/F２５１は、図１９の受信装置２０において、放送I/Fとして機能するRF部２０１や復調部２０２と、通信I/Fとして機能する通信1/F２０５に相当している。また、アプリケーション実行環境／ミドルウェア２５２は、図１９の受信装置２０において、処理部２０３のMW部２１３やブラウザ２１４に相当している。
【０２５９】
図１９の受信装置２０においては、放送・通信I/F２５１によって、AITが受信されると、アプリケーション実行環境／ミドルウェア２５２によって、当該AITが解析され、その解析結果に応じて、放送アプリケーション（BCA）が受信される（Ｓ７１）。そして、アプリケーション実行環境／ミドルウェア２５２は、放送・通信I/F２５１により受信された放送アプリケーション（BCA）を起動する（Ｓ７２）。
【０２６０】
ここで、起動された放送アプリケーション（BCA）は、addEventListenerメソッドにより、アプリケーション実行環境／ミドルウェア２５２に対して、特定のイベント（例えばE-AIT受信イベント）の登録を行う（Ｓ７３）。これにより、アプリケーション実行環境／ミドルウェア２５２では、特定のイベント（例えばE-AIT受信イベント）が発行されたときに、それを、放送アプリケーション（BCA）に通知する準備が整ったことになる。
【０２６１】
そして、放送・通信I/F２５１によって、E-AITが受信されると（Ｓ７４）、アプリケーション実行環境／ミドルウェア２５２では、コールバックイベントが発行され、当該E-AIT受信イベントが、放送アプリケーション（BCA）に通知される（Ｓ７５）。ここでは、E-AITが、アプリケーション実行環境／ミドルウェア２５２から、放送アプリケーション（BCA）に供給される。
【０２６２】
放送アプリケーション（BCA）は、E-AITを解析して、緊急警報アプリケーション（EAA）を起動するかどうかの判定処理を行う（Ｓ７６）。この判定処理では、例えば、緊急警報アプリケーション（EAA）を起動すると判定され、そのEAA起動判定結果が、アプリケーション実行環境／ミドルウェア２５２に通知される（Ｓ７７）。
【０２６３】
アプリケーション実行環境／ミドルウェア２５２は、放送アプリケーション（BCA）からのEAA起動判定結果に基づいて、緊急警報アプリケーション（EAA）を起動する場合には、起動中の放送アプリケーション（BCA）を一時停止又は終了させる（Ｓ７８）。そして、放送・通信I/F２５１によって、緊急警報アプリケーション（EAA）が受信されると（Ｓ７９）、アプリケーション実行環境／ミドルウェア２５２は、当該緊急警報アプリケーション（EAA）を起動させることになる（Ｓ８０）。
【０２６４】
以上のようにして、図１９の受信装置２０においては、放送アプリケーション（BCA）と、緊急警報アプリケーション（EAA）が起動される。ただし、図２０の起動シーケンスは一例であって、例えば、この例では、放送アプリケーション（BCA）側で、緊急警報アプリケーション（EAA）の起動判定処理を行っているが、上述した例のように、アプリケーション実行環境／ミドルウェア２５２側で、緊急警報アプリケーション（EAA）の起動判定処理を行うようにしてもよい。
【０２６５】
また、図２０の起動シーケンスでは、放送アプリケーション（BCA）が、addEventListenerメソッドによって、特定のイベントとして、E-AIT受信イベントを登録した場合を例に説明したが、他のイベントも同様に登録して処理することができる。例えば、イベントメッセージについても、addEventListenerメソッドで登録しておくことで、コールバックイベントが発行されたタイミングで、イベントメッセージの通知を受けることができる。
【０２６６】
＜３．各装置で実行される処理の流れ＞
【０２６７】
次に、図２１乃至図２８のフローチャートを参照して、図１の伝送システム１を構成する各装置で実行される処理の流れについて説明する。
【０２６８】
（送信処理の流れ）
まず、図２１のフローチャートを参照して、図１９の送信装置１０により実行される送信処理の流れについて説明する。
【０２６９】
ステップＳ１０１において、コンポーネント処理部１０４及びエンコーダ１０７は、コンポーネント処理を行う。
【０２７０】
このコンポーネント処理では、ライブコンテンツ取得部１０２により取得されるライブコンテンツ（例えば生放送番組）、又はストレージ１０３に蓄積されている収録済みのコンテンツ（例えば事前収録番組）が取得され、取得されたコンテンツを構成するビデオやオーディオのコンポーネントに対して、所定の符号化方式に応じたエンコードなどの処理が行われる。
【０２７１】
また、緊急時において、受信装置２０の画面に、焼き込みテキストを表示させる場合、コンポーネント処理では、コンテンツ（例えば生放送番組や事前収録番組）の映像（非圧縮のビデオデータ）に、EAパーサ１０１からのCAP情報の解析結果に応じた緊急警報（テキスト情報）を埋め込んでから、エンコードが行われる。
【０２７２】
ステップＳ１０２において、シグナリング処理部１０５は、シグナリング処理を行う。
【０２７３】
このシグナリング処理では、LLSシグナリングやSLSシグナリングなどのシグナリングが生成され、処理される。例えば、シグナリングとしては、放送アプリケーション（BCA）の動作を制御するためのAITが生成される。
【０２７４】
また、緊急時において、シグナリング処理では、LLSシグナリングとして、EAパーサ１０１からのCAP情報の解析結果に応じたE-AITが生成される。このE-AITには、緊急警報（の詳細情報）に関する情報や、緊急警報アプリケーション（EAA）の制御情報などが含まれる。
【０２７５】
ステップＳ１０３において、LCC処理部１０６は、アプリケーション処理を行う。
【０２７６】
このアプリケーション処理では、LCCコンテンツとして、放送アプリケーション（BCA）が生成される。また、緊急時において、アプリケーション処理では、LCCコンテンツとして、EAパーサ１０１からの緊急警報に応じた緊急警報アプリケーション（EAA）が生成される。放送アプリケーション（BCA）と緊急警報アプリケーション（EAA）は、HTML5で開発されたアプリケーションである。
【０２７７】
ステップＳ１０４において、マルチプレクサ１０８は、多重化ストリーム生成処理を行う。
【０２７８】
この多重化ストリーム生成処理では、ステップＳ１０１の処理で得られるコンポーネントのストリームと、ステップＳ１０２の処理で得られるシグナリングのストリームとが多重化され、多重化ストリームが生成される。ただし、緊急時においては、シグナリングに、E-AITが含まれる。また、緊急時においては、緊急警報アプリケーション（EAA）のストリームも多重化される。
【０２７９】
ステップＳ１０５において、変調部１０９及びRF部１１０は、放送ストリーム送信処理を行う。
【０２８０】
この放送ストリーム送信処理では、ステップＳ１０４の処理で生成された多重化ストリームが、IP伝送方式のデジタル放送信号として送信される。
【０２８１】
ステップＳ１０５の処理が終了すると、図２１の送信処理は終了される。
【０２８２】
以上、送信処理の流れについて説明した。
【０２８３】
（電源オフ・待機状態時の受信処理の流れ）
次に、図２２のフローチャートを参照して、図１９の受信装置２０により実行される、電源オフ・待機状態時における受信処理の流れについて説明する。ただし、図２２のフローチャートの処理が実行される前提として、受信装置２０が、電源オフで、かつ、待機状態、すなわち、受信装置２０において、RF部２０１及び復調部２０２のみが動作可能な状態であるものとする。
【０２８４】
ステップＳ２０１において、RF部２０１及び復調部２０２は、L1パケット受信処理を行う。
【０２８５】
このL1パケット受信処理では、送信装置１０からのデジタル放送信号が受信され、デジタル放送信号として伝送されるL1フレームが取得される。
【０２８６】
ステップＳ２０２において、復調部２０２は、ステップＳ２０１の処理で取得されるL1フレームのL1ヘッダに含まれるウェイクアップフラグ（wake-up flag）を監視する。
【０２８７】
ステップＳ２０３においては、ステップＳ２０２の監視結果に基づいて、ウェイクアップフラグが、"TRUE"であるかどうかが判定される。ステップＳ２０３において、ウェイクアップフラグが、"FALSE"であると判定された場合、処理は、ステップＳ２０１に戻り、ステップＳ２０１乃至Ｓ２０３の処理が繰り返される。
【０２８８】
そして、ステップＳ２０３において、ウェイクアップフラグが、"TRUE"であると判定された場合、処理は、ステップＳ２０４に進められる。ステップＳ２０４においては、受信装置２０の電源がオンされる。これにより、受信装置２０においては、処理部２０３や出力部２０４など、RF部２０１及び復調部２０２以外の他のブロックについても動作可能な状態となる。
【０２８９】
ステップＳ２０４の処理によって、受信装置２０の全ての機能が実行可能になると、処理は、ステップＳ２０５に進められる。ステップＳ２０５においては、放送ストリーム受信処理が行われる。
【０２９０】
この放送ストリーム受信処理では、シグナリングに基づいて、ビデオやオーディオのコンポーネントが処理され、コンテンツの映像と音声が再生される。また、緊急時においては、焼き込みテキストなどの緊急警報のほか、緊急警報アプリケーション（EAA）による緊急詳細情報が表示される。なお、この放送ストリーム受信処理の詳細な内容については、図２４のフローチャートを参照して後述する。
【０２９１】
ステップＳ２０６においては、ステップＳ２０５の放送ストリーム受信処理を終了するかどうかが判定される。ステップＳ２０６において、放送ストリーム受信処理を継続すると判定された場合、処理は、ステップＳ２０５に戻り、ステップＳ２０５乃至Ｓ２０６の処理が繰り返される。一方で、ステップＳ２０６において、放送ストリーム受信処理を終了すると判定された場合、図２２の電源オフ・待機状態時における受信処理は、終了される。
【０２９２】
以上、電源オフ・待機状態時における受信処理の流れについて説明した。
【０２９３】
（電源オフ状態時の受信処理の流れ）
次に、図２３のフローチャートを参照して、図１９の受信装置２０により実行される、電源オフ状態時における受信処理の流れについて説明する。ただし、図２３のフローチャートの処理が実行される前提として、受信装置２０が、電源オフ状態、すなわち、受信装置２０において、全ての機能が実行不可能な状態であるものとする。
【０２９４】
ステップＳ２１１においては、例えば、ユーザの操作に応じて、受信装置２０の電源がオンされる。
【０２９５】
ステップＳ２１１の処理によって、受信装置２０の全ての機能が実行可能になると、処理は、ステップＳ２１２に進められる。ステップＳ２１２においては、放送ストリーム受信処理が行われる。
【０２９６】
この放送ストリーム受信処理では、シグナリングに基づいて、ビデオやオーディオのコンポーネントが処理され、コンテンツの映像と音声が再生される。また、緊急時においては、焼き込みテキストなどの緊急警報のほか、緊急警報アプリケーション（EAA）による緊急詳細情報が表示される。なお、この放送ストリーム受信処理の詳細な内容については、図２４のフローチャートを参照して後述する。
【０２９７】
ステップＳ２１３においては、ステップＳ２１２の放送ストリーム受信処理を終了するかどうかが判定される。ステップＳ２１３において、放送ストリーム受信処理を継続すると判定された場合、処理は、ステップＳ２１２に戻り、ステップＳ２１２乃至Ｓ２１３の処理が繰り返される。一方で、ステップＳ２１３において、放送ストリーム受信処理を終了すると判定された場合、図２３の電源オフ状態時における受信処理は、終了される。
【０２９８】
以上、電源オフ状態時における受信処理の流れについて説明した。
【０２９９】
（放送ストリーム受信処理の流れ）
次に、図２４のフローチャートを参照して、図２２のステップＳ２０５の処理又は図２３のステップＳ２１２の処理に対応する、放送ストリーム受信処理の流れについて説明する。
【０３００】
ステップＳ２２１において、デマルチプレクサ２２１は、パケット受信処理を行う。このパケット受信処理では、復調部２０２により処理されたL1フレームから、ALPパケットやIP/UDPパケットが処理される。
【０３０１】
ステップＳ２２２においては、ステップＳ２２１の処理で得られるパケットに基づいて、LLSシグナリング（LLSテーブル）が取得されたかどうかが判定される。ステップＳ２２２において、LLSシグナリングが取得されたと判定された場合、処理は、ステップＳ２２３に進められる。
【０３０２】
ステップＳ２２３において、MW部２１３は、LLSシグナリングの種別とバージョンを判別する。ここでは、上述した図４を参照して説明したように、LLSテーブル（のLLヘッダ）に含まれるLLSテーブルIDとLLSテーブルのバージョンを解析することで、LLSシグナリングの種別とバージョンが判別される。
【０３０３】
ステップＳ２２４において、MW部２１３は、ステップＳ２２３の判別結果に基づいて、LLSシグナリングが更新されているかどうかを判定する。ステップＳ２２４において、LLSシグナリングが更新されていると判定された場合、処理は、ステップＳ２２５に進められる。
【０３０４】
ステップＳ２２５において、MW部２１３は、ステップＳ２２３の判別結果に基づいて、LLSシグナリングが、E-AITであるかどうかを判定する。ステップＳ２２５において、LLSシグナリングがE-AITであると判定された場合、処理は、ステップＳ２２６に進められる。
【０３０５】
ステップＳ２２６においては、E-AIT受信処理が行われる。このE-AIT受信処理では、E-AITに応じた緊急詳細情報を提示する緊急警報アプリケーション（EAA）に関する処理が行われる。なお、このE-AIT受信処理の詳細な内容については、図２５乃至図２７のフローチャートを参照して後述する。
【０３０６】
一方で、ステップＳ２２５において、LLSシグナリングがE-AITではないと判定された場合、処理は、ステップＳ２２７に進められる。ステップＳ２２７においては、他のLLSシグナリング受信処理が行われる。このLLSシグナリング受信処理では、SLTメタデータなどのE-AIT以外のLLSシグナリングに対する処理が行われる。
【０３０７】
なお、ステップＳ２２４において、LLSシグナリングが更新されていないと判定された場合、LLSシグナリングに対する処理を行う必要はないので、ステップＳ２２５乃至Ｓ２２７の処理はスキップされる。また、ステップＳ２２６又はステップＳ２２７の処理が終了すると、図２４の放送ストリーム受信処理は終了され、処理は、図２２のステップＳ２０５又は図２３のステップＳ２１２に戻り、それ以降の処理が実行される。
【０３０８】
また、ステップＳ２２２において、LLSシグナリングが取得されていないと判定された場合、処理は、ステップＳ２２８に進められる。ステップＳ２２８においては、対象のROUTEセッションの種別が判定される。なお、上述したように、ATSC3.0の場合、コンポーネントやシグナリングがMMTセッションで伝送される場合もあるが、ここでは、説明の簡略化のため、ROUTEセッションが用いられる場合についてのみ説明する。
【０３０９】
ステップＳ２２８において、ROUTEセッションの種別が、ビデオやオーディオ等のコンポーネントであると判定された場合、処理は、ステップＳ２２９に進められる。ステップＳ２２９乃至Ｓ２３２においては、ROUTEセッションで伝送されるコンポーネントに関する処理が行われる。
【０３１０】
具体的には、ステップＳ２２９において、デコーダ２２２及びコンポーネント処理部２１２は、コンポーネント受信処理を行う。このコンポーネント受信処理では、放送番組等のコンテンツを構成するビデオやオーディオのコンポーネントに対して、所定の復号方式に応じたデコードなどの処理が行われる。
【０３１１】
ステップＳ２３０において、出力部２０４は、レンダリング処理を行う。このレンダリング処理では、ステップＳ２２９の処理結果に基づいて、放送番組等のコンテンツの映像と音声が再生され、出力される。
【０３１２】
ステップＳ２３１において、FW/HW部２１１は、ROUTEセッションで伝送されるDASHセグメントのイベントメッセージボックスに、イベントメッセージが含まれるかどうかを判定する。ステップＳ２３１において、イベントメッセージが含まれると判定された場合、処理は、ステップＳ２３２に進められる。
【０３１３】
ステップＳ２３２において、FW/HW部２１１（又はMW部２１３）は、イベント処理を行う。このイベント処理では、DASHセグメントのイベントメッセージボックスに配置されたイベントメッセージに応じて、所定のタイミングで、緊急警報アプリケーション（EAA）に関する処理が行われる。なお、このイベント処理の詳細な内容については、図２８のフローチャートを参照して後述する。また、ステップＳ２３１において、イベントメッセージが含まれていないと判定された場合、ステップＳ２３２の処理はスキップされる。
【０３１４】
また、ステップＳ２２８において、ROUTEセッションの種別が、SLSシグナリングであると判定された場合、処理は、ステップＳ２３３に進められる。ステップＳ２３３乃至Ｓ２３７においては、ROUTEセッションで伝送されるSLSシグナリングに関する処理が行われる。
【０３１５】
具体的には、ステップＳ２３３において、MW部２１３は、SLSシグナリング受信解析処理を行う。このSLSシグナリング受信解析処理では、ROUTEセッションで伝送される、USDやMPD等のメタデータであるSLSシグナリングが取得され、解析される。
【０３１６】
ステップＳ２３４においては、ステップＳ２３３の解析結果に基づいて、SLSシグナリングが更新されたかどうかが判定される。ステップＳ２３４において、SLSシグナリングが更新されていると判定された場合、処理は、ステップＳ２３５に進められる。
【０３１７】
ステップＳ２３５においては、ステップＳ２３３の解析結果に基づいて、SLSシグナリングの更新内容が反映される。なお、ステップＳ２３４において、SLSシグナリングが更新されていないと判定された場合、ステップＳ２３５の処理はスキップされる。
【０３１８】
ステップＳ２３６において、MW部２１３は、ステップＳ２３３の解析結果に基づいて、MPDのEventStream要素に、イベントメッセージが含まれるかどうかを判定する。ステップＳ２３６において、イベントメッセージを含むと判定された場合、処理は、ステップＳ２３７に進められる。
【０３１９】
ステップＳ２３７において、MW部２１３は、イベント処理を行う。このイベント処理では、MPDのEventStream要素に配置されたイベントメッセージに応じて、所定のタイミングで、緊急警報アプリケーション（EAA）に関する処理が行われる。なお、このイベント処理の詳細な内容については、図２８のフローチャートを参照して後述する。また、ステップＳ２３６において、イベントメッセージが含まれていないと判定された場合、ステップＳ２３７の処理はスキップされる。
【０３２０】
また、ステップＳ２２８において、ROUTEセッションの種別が、LCCコンテンツであると判定された場合、処理は、ステップＳ２３８に進められる。ステップＳ２３８乃至Ｓ２３９においては、ROUTEセッションで伝送されるLCCコンテンツに関する処理が行われる。
【０３２１】
具体的には、ステップＳ２３８においては、LCCコンテンツ受信処理が行われ、例えばアプリケーション（例えば、放送アプリケーション（BCA））や蓄積用のコンテンツなどのLCCコンテンツが取得される。ステップＳ２３９においては、ローカルキャッシュ処理が行われ、ステップＳ２３８の処理で取得されたLCCコンテンツが、ストレージ（不図示）に蓄積（ダウンロード）される。
【０３２２】
ステップＳ２３２，Ｓ２３７，又はＳ２３９の処理が終了すると、図２４の放送ストリーム受信処理は終了され、処理は、図２２のステップＳ２０５又は図２３のステップＳ２１２に戻り、それ以降の処理が実行される。
【０３２３】
以上、放送ストリーム受信処理の流れについて説明した。
【０３２４】
（E-AIT受信処理の流れ）
次に、図２５乃至図２７のフローチャートを参照して、図２４のステップＳ２２６の処理に対応する、E-AIT受信処理の詳細な内容について説明する。
【０３２５】
ここでは、まず、図２５のフローチャートを参照して、第１の方式により緊急警報アプリケーション（EAA）が起動される場合のE-AIT受信処理について説明する。なお、E-AITが受信されるのは、送信装置１０から緊急警報が通知される期間でもあるため、図２５のフローチャートの処理を開始する際に、受信装置２０の画面には、緊急警報メッセージ（Universal Alert）としての焼き込みテキスト（burned - in text）が表示されている。
【０３２６】
ステップＳ２４１において、レジデントアプリケーション(RA)は、LLSシグナリングとして受信されるE-AITの解析処理を行う。ここで、E-AITには、例えば、緊急警報の緊急性、重大性、対象地域、カテゴリ、及び、優先度を示す情報（基本情報）のほか、制御コードとして、緊急警報アプリケーション（EAA）の自動起動（autostart）が設定されている。
【０３２７】
ステップＳ２４２において、レジデントアプリケーション(RA)は、ステップＳ２４１の解析結果に基づいて、緊急警報の概要を提示する。ここでは、例えば、E-AITに含まれる基本情報（例えば、緊急性や対象地域等）に応じた緊急詳細情報を提示するかどうかの選択情報が、EAアイコンとして、受信装置２０の画面に表示される（例えば、図６のＤ１３）。
【０３２８】
ステップＳ２４３においては、ステップＳ２４２の処理で提示された緊急警報の概要（例えばEAアイコン等の選択情報）を確認したユーザによって、緊急詳細情報の提示が指示されたかどうかが判定される。
【０３２９】
ステップＳ２４３において、例えば、EAアイコンとして表示される「はい」ボタンが操作された場合、緊急詳細情報の提示が指示されたことになるので、処理は、ステップＳ２４４に進められる。なお、この場合、レジデントアプリケーション(RA)は、緊急警報アプリケーション（EAA）の起動イベント（EAA起動イベント）を発行することになる。
【０３３０】
ステップＳ２４４において、ブラウザ２１４は、レジデントアプリケーション(RA)により発行されたEAA起動イベントに応じて、LCCコンテンツとして伝送される緊急警報アプリケーション（EAA）を取得して、起動する。これにより、受信装置２０の画面には、緊急警報アプリケーション（EAA）による緊急詳細情報が、焼き込みテキスト（burned - in text）の文字列とともに、放送番組の映像に重畳表示される（例えば、図６のＤ１４）。
【０３３１】
一方で、ステップＳ２４３において、例えば、EAアイコンとして表示される「いいえ」ボタンが操作された場合、緊急詳細情報の提示が拒否されたことになるので、ステップＳ２４４の処理はスキップされることになる。そして、ステップＳ２４４の処理が終了すると、処理は、図２４のステップＳ２２６に戻り、それ以降の処理が実行される。
【０３３２】
なお、上述したステップＳ２４２乃至Ｓ２４３の処理では、E-AITに含まれる基本情報に応じた選択情報（例えばEAアイコン）を表示することで、ユーザ操作に応じて緊急詳細情報を提示するかどうかを判定したが、判定方法はこれに限らず、例えば、ユーザによりあらかじめ設定された設定情報（例えば、気象に関する情報は表示するが、学校の臨時休校などの情報は表示しないなど）に基づいて、緊急詳細情報を提示するかどうかを判定するようにしてもよい。
【０３３３】
また、ステップＳ２４４の処理で、緊急警報アプリケーション（EAA）を起動する際に、放送アプリケーション（BCA）が起動されている場合には、起動中の放送アプリケーション（BCA）を一時停止又は終了させてから、緊急警報アプリケーション（EAA）を起動することになる。
【０３３４】
以上、第１の方式により緊急警報アプリケーション（EAA）が起動される場合のE-AIT受信処理の流れを説明した。
【０３３５】
次に、図２６のフローチャートを参照して、第２の方式又は第３の方式により緊急警報アプリケーション（EAA）が起動される場合のE-AIT受信処理の流れについて説明する。なお、E-AITが受信されるのは、送信装置１０から緊急警報が通知される期間でもあるため、図２６のフローチャートの処理を開始する際に、受信装置２０の画面には、緊急警報メッセージ（Universal Alert）としての焼き込みテキスト（burned - in text）が表示されている。
【０３３６】
ステップＳ２５１において、MW部２１３は、LLSシグナリングとして受信されるE-AITの解析処理を行う。ここで、E-AITには、例えば、緊急警報の緊急性、重大性、対象地域、カテゴリ、及び、優先度を示す情報（基本情報）のほか、制御コードとして、緊急警報アプリケーション（EAA）の自動起動（autostart）が設定されている。
【０３３７】
ステップＳ２５２において、MW部２１３は、放送アプリケーション（BCA）が起動中であるかどうかを判定する。
【０３３８】
ステップＳ２５２において、放送アプリケーション（BCA）が起動中であると判定された場合、処理は、ステップＳ２５３に進められる。この場合、上述した第３の方式に相当するため、ステップＳ２５３乃至Ｓ２５６においては、第３の方式に関する処理が行われる。
【０３３９】
ステップＳ２５３において、MW部２１３は、イベント通知処理を行う。このイベント通知処理では、図２０を参照して説明したように、例えば、起動中の放送アプリケーション（BCA）がaddEventListenerメソッドによって、E-AIT受信イベントを登録していた場合、コールバックイベントが発行され、E-AIT受信イベントが、放送アプリケーション（BCA）に通知されることになる。
【０３４０】
ステップＳ２５４において、MW部２１３（又は放送アプリケーション（BCA））は、ステップＳ２５１の解析結果に基づいて、緊急警報アプリケーション（EAA）を起動するかどうかを判定する。ここでは、例えば、ユーザからの指示又は設定情報（例えば表示対象地域や表示対象項目などの設定）に応じて、緊急警報アプリケーション（EAA）を起動するかどうかを判定することができる。
【０３４１】
ステップＳ２５４において、緊急警報アプリケーション（EAA）を起動すると判定された場合、処理は、ステップＳ２５５に進められる。この場合、MW部２１３は、緊急警報アプリケーション（EAA）の起動イベント（EAA起動イベント）を発行することになる。
【０３４２】
ステップＳ２５５において、ブラウザ２１４は、MW部２１３から発行されたEAA起動イベントに応じて、起動中の放送アプリケーション（BCA）を一時停止又は終了させる。
【０３４３】
ステップＳ２５６において、ブラウザ２１４は、MW部２１３から発行されたEAA起動イベントに応じて、LCCコンテンツとして伝送される緊急警報アプリケーション（EAA）を取得して、起動する。これにより、受信装置２０の画面には、緊急警報アプリケーション（EAA）による緊急詳細情報が、焼き込みテキスト（burned - in text）の文字列とともに、放送番組の映像に重畳表示される（例えば、図８のＤ３４）。
【０３４４】
なお、ステップＳ２５４において、緊急警報アプリケーション（EAA）を起動しないと判定された場合、ステップＳ２５５乃至Ｓ２５６の処理は、スキップされる。
【０３４５】
一方で、ステップＳ２５２において、放送アプリケーション（BCA）が起動中ではないと判定された場合、処理は、ステップＳ２５７に進められる。この場合、上述した第２の方式に相当するため、ステップＳ２５７乃至Ｓ２５８においては、第２の方式に関する処理が行われる。
【０３４６】
ステップＳ２５７において、MW部２１３は、ステップＳ２５１の解析結果に基づいて、緊急警報アプリケーション（EAA）を起動するかどうかを判定する。ここでは、例えば、ユーザからの指示又は設定情報（例えば表示対象地域や表示対象項目などの設定）に応じて、緊急警報アプリケーション（EAA）を起動するかどうかを判定することができる。
【０３４７】
ステップＳ２５７において、緊急警報アプリケーション（EAA）を起動すると判定された場合、処理は、ステップＳ２５８に進められる。この場合、MW部２１３は、緊急警報アプリケーション（EAA）の起動イベント（EAA起動イベント）を発行することになる。
【０３４８】
ステップＳ２５８において、ブラウザ２１４は、MW部２１３から発行されたEAA起動イベントに応じて、LCCコンテンツとして伝送される緊急警報アプリケーション（EAA）を取得して、起動する。これにより、受信装置２０の画面には、緊急警報アプリケーション（EAA）による緊急詳細情報が、焼き込みテキスト（burned - in text）の文字列とともに、放送番組の映像に重畳表示される（例えば、図７のＤ２４）。
【０３４９】
なお、ステップＳ２５７において、緊急警報アプリケーション（EAA）を起動しないと判定された場合、ステップＳ２５８の処理は、スキップされる。
【０３５０】
ステップＳ２５６又はＳ２５８の処理が終了すると、処理は、図２４のステップＳ２２６に戻り、それ以降の処理が実行される。
【０３５１】
以上、第２の方式又は第３の方式により緊急警報アプリケーション（EAA）が起動される場合のE-AIT受信処理の流れについて説明した。
【０３５２】
次に、図２７のフローチャートを参照して、第１の方式乃至第３の方式により緊急警報アプリケーション（EAA）が終了される場合のE-AIT受信処理の流れについて説明する。
【０３５３】
ただし、図２７のフローチャートの処理が実行される前提として、上述した図２５又は図２６のフローチャートの処理が実行され、緊急警報アプリケーション（EAA）が起動済みであるものとする。したがって、受信装置２０の画面には、緊急警報メッセージ（Universal Alert）としての焼き込みテキスト（burned - in text）とともに、アドバンスコンテンツ（Advanced Content）に応じた緊急詳細情報が表示されている（例えば、図６のＤ１４，図７のＤ２４，図８のＤ３４）。
【０３５４】
ステップＳ２６１において、MW部２１３は、LLSシグナリングとして受信されるE-AITの解析処理を行う。ここで、E-AITには、制御コードとして、緊急警報アプリケーション（EAA）の終了（terminate）が設定されている。ここでは、MW部２１３は、緊急警報アプリケーション（EAA）の終了イベント（EAA終了イベント）を発行することになる。
【０３５５】
ステップＳ２６２において、ブラウザ２１４は、MW部２１３から発行されたEAA終了イベントに応じて、起動中の緊急警報アプリケーション（EAA）を終了させる。
【０３５６】
ステップＳ２６３において、MW部２１３（又はブラウザ２１４）は、放送アプリケーション（BCA）が一時停止しているかどうかを判定する。ここでは、例えば、図２６のステップＳ２５５の処理で、起動中の放送アプリケーション（BCA）を一時停止させたかどうかが判定される。
【０３５７】
ステップＳ２６３において、放送アプリケーション（BCA）が一時停止していると判定された場合、処理は、ステップＳ２６４に進められる。この場合、MW部２１３は、放送アプリケーション（BCA）の実行の再開イベント（BCA再開イベント）を発行することになる。
【０３５８】
ステップＳ２６４において、ブラウザ２１４は、MW部２１３から発行されたBCA再開イベントに応じて、一時停止中の放送アプリケーション（BCA）の実行を再開させる。これにより、受信装置２０の画面では、放送アプリケーション（BCA）の情報が、放送番組の映像に重畳表示される。
【０３５９】
また、ステップＳ２６３において、放送アプリケーション（BCA）が一時停止していないと判定された場合、ステップＳ２６４の処理はスキップされる。ステップＳ２６４の処理が終了すると、処理は、処理は、図２４のステップＳ２２６に戻り、それ以降の処理が実行される。
【０３６０】
以上、第１の方式乃至第３の方式により緊急警報アプリケーション（EAA）が終了される場合のE-AIT受信処理の流れについて説明した。
【０３６１】
（イベント処理）
最後に、図２８のフローチャートを参照して、図２４のステップＳ２３２又はＳ２３７の処理に対応するイベント処理の詳細な内容について説明する。
【０３６２】
ステップＳ２７１において、FW/HW部２１１又はMW部２１３は、イベント解析処理を行う。このイベント解析処理では、DASHセグメントのイベントメッセージボックスに配置されるイベントメッセージ、又は、MPDのEventStream要素に配置されるイベントメッセージの解析が行われる。
【０３６３】
ステップＳ２７２において、FW/HW部２１１又はMW部２１３は、ステップＳ２７１の解析結果に基づいて、イベントメッセージが、緊急警報アプリケーション（EAA）に関するイベントメッセージ（EAAイベント）であるかどうかを判定する。
【０３６４】
ステップＳ２７２において、イベントメッセージが、EAAイベントであると判定された場合、処理は、ステップＳ２７３に進められる。ステップＳ２７３において、MW部２１３又はブラウザ２１４は、アプリケーション起動判定処理を行う。この起動判定処理では、放送アプリケーション（BCA）、又は、緊急警報アプリケーション（EAA）が起動されているかどうかが判定される。
【０３６５】
ステップＳ２７３において、放送アプリケーション（BCA）が起動されていると判定された場合、処理は、ステップＳ２７４に進められる。ステップＳ２７４において、MW部２１３又はブラウザ２１４は、イベント通知処理を行う。このイベント通知処理では、図２０を参照して説明したように、例えば、放送アプリケーション（BCA）がaddEventListenerメソッドによって、イベントメッセージ（のイベント）を登録していた場合、コールバックイベントが発行され、イベントメッセージ（のイベント）が、放送アプリケーション（BCA）に通知されることになる。
【０３６６】
ステップＳ２７５において、MW部２１３又はブラウザ２１４は、ステップＳ２７１の解析結果に基づいて、緊急警報アプリケーション（EAA）を起動するかどうかを判定する。なお、この起動判定処理は、放送アプリケーション（BCA）が行ってもよい。また、ここでは、例えば、ユーザからの指示又は設定情報（例えば表示対象地域や表示対象項目などの設定）に応じて、緊急警報アプリケーション（EAA）を起動するかどうかを判定することができる。
【０３６７】
ステップＳ２７５において、緊急警報アプリケーション（EAA）を起動すると判定された場合、処理は、ステップＳ２７６に進められる。この場合、MW部２１３は、緊急警報アプリケーション（EAA）の起動イベント（EAA起動イベント）を発行することになる。
【０３６８】
ステップＳ２７６において、ブラウザ２１４は、MW部２１３から発行されたEAA起動イベントに応じて、起動中の放送アプリケーション（BCA）を一時停止又は終了させる。
【０３６９】
ステップＳ２７７において、ブラウザ２１４は、MW部２１３から発行されたEAA起動イベントに応じて、LCCコンテンツとして伝送される緊急警報アプリケーション（EAA）を取得して、起動する。これにより、受信装置２０の画面には、緊急警報アプリケーション（EAA）による緊急詳細情報が、焼き込みテキスト（burned - in text）の文字列とともに、放送番組の映像に重畳表示される。
【０３７０】
なお、ステップＳ２７５において、緊急警報アプリケーション（EAA）を起動しないと判定された場合、ステップＳ２７６乃至Ｓ２７７の処理は、スキップされる。
【０３７１】
また、ステップＳ２７３において、緊急警報アプリケーション（EAA）が起動されていると判定された場合、処理は、ステップＳ２７８に進められる。ステップＳ２７８において、MW部２１３又はブラウザ２１４は、イベント通知処理を行う。このイベント通知処理では、図２０を参照して説明したように、例えば、緊急警報アプリケーション（EAA）がaddEventListenerメソッドによって、イベントメッセージ（のイベント）を登録していた場合、コールバックイベントが発行され、イベントメッセージ（のイベント）が、緊急警報アプリケーション（EAA）に通知されることになる。
【０３７２】
ステップＳ２７９において、MW部２１３又はブラウザ２１４は、ステップＳ２７１の解析結果に基づいて、緊急警報アプリケーション（EAA）を更新するかどうかを判定する。なお、この更新判定処理は、緊急警報アプリケーション（EAA）が行ってもよい。
【０３７３】
ステップＳ２７９において、緊急警報アプリケーション（EAA）を更新すると判定された場合、処理は、ステップＳ２８０に進められる。この場合、MW部２１３は、緊急警報アプリケーション（EAA）の遷移イベント（EAA遷移イベント）を発行することになる。
【０３７４】
ステップＳ２８０において、ブラウザ２１４は、MW部２１３から発行されたEAA遷移イベントに応じて、緊急警報アプリケーション（EAA）を更新する。ここでは、例えば、緊急警報アプリケーション（EAA1）が起動している場合に、緊急警報アプリケーション（EAA2）が起動されることで、緊急警報アプリケーション（EAA）による情報が遷移することになる。これにより、受信装置２０の画面には、緊急警報アプリケーション（EAA1）の情報が更新され、緊急警報アプリケーション（EAA2）の情報が表示される（例えば、図９のＤ４４）。
【０３７５】
なお、ステップＳ２７９において、緊急警報アプリケーション（EAA）を更新しないと判定された場合、ステップＳ２８０の処理は、スキップされる。
【０３７６】
また、ステップＳ２７３において、放送アプリケーション（BCA）と緊急警報アプリケーション（EAA）が共に起動されていないと判定された場合、処理は、ステップＳ２８１に進められる。
【０３７７】
ステップＳ２８１において、MW部２１３又はブラウザ２１４は、ステップＳ２７１の解析結果に基づいて、緊急警報アプリケーション（EAA）の起動処理を行う。これにより、受信装置２０の画面には、緊急警報アプリケーション（EAA）による緊急詳細情報が、焼き込みテキスト（burned - in text）の文字列とともに、放送番組の映像に重畳表示される。
【０３７８】
なお、ステップＳ２７２において、イベントメッセージが、EAAイベントではないと判定された場合、処理は、ステップＳ２８２に進められる。ステップＳ２８２において、MW部２１３又はブラウザ２１４等は、EAAイベント以外の他のイベントメッセージに対応したイベント処理を行う。
【０３７９】
ステップＳ２７７，Ｓ２８０，Ｓ２８１，又はＳ２８２の処理が終了すると、処理は、図２４のステップＳ２３２又はＳ２３７の処理に戻り、それ以降の処理が実行される。
【０３８０】
以上、イベント処理の流れについて説明した。
【０３８１】
＜４．変形例＞
【０３８２】
上述した説明としては、デジタル放送の規格として、米国等で採用されている方式であるATSC（特に、ATSC3.0）を説明したが、本技術は、日本等が採用する方式であるISDB(Integrated Services Digital Broadcasting)や、欧州の各国等が採用する方式であるDVB(Digital Video Broadcasting)などに適用するようにしてもよい。また、伝送システム１において、伝送路８０は、地上波放送に限らず、例えば、放送衛星（BS：Broadcasting Satellite）や通信衛星（CS：Communications Satellite）を利用した衛星放送、あるいは、ケーブルを用いた有線放送（CATV）などであってもよい。さらに、上述した説明では、米国の緊急告知のシステム（EAS）を一例に説明したが、各国で構築されている同様のシステムに適用するようにしてもよい。
【０３８３】
また、上述したLLSやSLS等のシグナリングの名称は、一例であって、他の名称が用いられる場合がある。ただし、これらの名称の違いは、形式的な違いであって、各シグナリングの実質的な内容が異なるものではない。さらに、シグナリングがXML等のマークアップ言語により記述される場合において、それらの要素や属性の名称は一例であって、他の名称が採用されるようにしてもよい。ただし、これらの名称の違いは、形式的な違いであって、それらの要素や属性の実質的な内容が異なるものではない。また、LCC（Locally Cached Content）は、NRT(Non Real Time)と称される場合があるが、実質的な内容が異なるものではない。
【０３８４】
＜５．コンピュータの構成＞
【０３８５】
上述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、コンピュータにインストールされる。図２９は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示す図である。
【０３８６】
コンピュータ９００において、CPU(Central Processing Unit)９０１，ROM(Read Only Memory)９０２，RAM(Random Access Memory)９０３は、バス９０４により相互に接続されている。バス９０４には、さらに、入出力インターフェース９０５が接続されている。入出力インターフェース９０５には、入力部９０６、出力部９０７、記録部９０８、通信部９０９、及び、ドライブ９１０が接続されている。
【０３８７】
入力部９０６は、キーボード、マウス、マイクロフォンなどよりなる。出力部９０７は、ディスプレイ、スピーカなどよりなる。記録部９０８は、ハードディスクや不揮発性のメモリなどよりなる。通信部９０９は、ネットワークインターフェースなどよりなる。ドライブ９１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブルメディア９１１を駆動する。
【０３８８】
以上のように構成されるコンピュータ９００では、CPU９０１が、ROM９０２や記録部９０８に記録されているプログラムを、入出力インターフェース９０５及びバス９０４を介して、RAM９０３にロードして実行することにより、上述した一連の処理が行われる。
【０３８９】
コンピュータ９００（CPU９０１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア９１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線又は無線の伝送媒体を介して提供することができる。
【０３９０】
コンピュータ９００では、プログラムは、リムーバブルメディア９１１をドライブ９１０に装着することにより、入出力インターフェース９０５を介して、記録部９０８にインストールすることができる。また、プログラムは、有線又は無線の伝送媒体を介して、通信部９０９で受信し、記録部９０８にインストールすることができる。その他、プログラムは、ROM９０２や記録部９０８に、あらかじめインストールしておくことができる。
【０３９１】
ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含む。また、プログラムは、１のコンピュータ（プロセッサ）により処理されるものであってもよいし、複数のコンピュータによって分散処理されるものであってもよい。
【０３９２】
なお、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
【０３９３】
また、本技術は、以下のような構成をとることができる。
【０３９４】
（１）
デジタル放送信号を受信する受信部と、
前記デジタル放送信号に含まれる制御情報であって、緊急に告知する必要がある緊急情報の詳細情報に関する情報を含む前記制御情報に基づいて、前記緊急情報の詳細情報を提示する緊急情報アプリケーションに関する処理を行う処理部と
を備える受信装置。
（２）
前記制御情報は、前記緊急情報の緊急性、重大性、対象地域、カテゴリ、及び、優先度を示す情報のうちの少なくとも１つの情報を含み、
前記処理部は、前記制御情報に基づいて、前記緊急情報アプリケーションを起動するかどうかを判定する
（１）に記載の受信装置。
（３）
前記処理部は、
前記制御情報に基づいて、前記緊急情報の詳細情報を提示するかどうかの選択情報を表示し、
ユーザによって、前記緊急情報の詳細情報の提示が選択された場合、前記緊急情報アプリケーションを起動する
（２）に記載の受信装置。
（４）
前記処理部は、あらかじめユーザにより設定される設定情報に基づいて、前記緊急情報アプリケーションを起動する
（２）に記載の受信装置。
（５）
前記制御情報は、前記緊急情報アプリケーションのライフサイクルを制御するためのコマンドをさらに含み、
前記処理部は、前記制御情報に基づいて、前記緊急情報アプリケーションの動作を制御する
（２）乃至（４）のいずれか一項に記載の受信装置。
（６）
前記処理部は、
前記制御情報に含まれるコマンドが、前記緊急情報アプリケーションの起動を示している場合であって、前記緊急情報アプリケーションを起動する場合に、通常時に実行される放送アプリケーションが起動されているとき、前記緊急情報アプリケーションを起動させるとともに、前記放送アプリケーションを一時停止又は終了させる制御を行い、
前記制御情報に含まれるコマンドが、前記緊急情報アプリケーションの終了を示している場合に、前記緊急情報アプリケーションが起動しているとき、前記緊急情報アプリケーションを終了させる制御を行う
（５）に記載の受信装置。
（７）
前記処理部は、前記制御情報に含まれるコマンドが、前記緊急情報アプリケーションの終了を示している場合に、前記放送アプリケーションが一時停止となっているとき、一時停止中の前記放送アプリケーションの動作を再開させる制御を行う
（６）に記載の受信装置。
（８）
前記処理部は、前記デジタル放送信号に含まれるイベントメッセージに基づいて、所定のタイミングで、前記緊急情報アプリケーションに関する処理を実行する
（２）乃至（７）のいずれか一項に記載の受信装置。
（９）
前記イベントメッセージは、MPEG-DASH(Dynamic Adaptive Streaming over HTTP)で規定されるMPD(Media Presentation Description)のイベントストリーム要素、又は、DASHセグメントのイベントメッセージボックスに配置される
（８）に記載の受信装置。
（１０）
前記デジタル放送信号は、IP(Internet Protocol)伝送方式のデジタル放送信号であり、
前記制御情報は、IPパケットに含まれるUDP(User Datagram Protocol)パケットのペイロードに配置されて伝送される
（１）乃至（９）のいずれか一項に記載の受信装置。
（１１）
受信装置のデータ処理方法において、
前記受信装置が、
デジタル放送信号を受信し、
前記デジタル放送信号に含まれる制御情報であって、緊急に告知する必要がある緊急情報の詳細情報に関する情報を含む前記制御情報に基づいて、前記緊急情報の詳細情報を提示する緊急情報アプリケーションに関する処理を行う
ステップを含むデータ処理方法。
（１２）
緊急に告知する必要がある緊急情報の詳細情報に関する情報を含む制御情報であって、前記緊急情報の詳細情報を提示する緊急情報アプリケーションに関する処理に用いられる前記制御情報を生成する生成部と、
生成された前記制御情報を、デジタル放送信号に含めて送信する送信部と
を備える送信装置。
（１３）
前記制御情報は、前記緊急情報の緊急性、重大性、対象地域、カテゴリ、及び、優先度を示す情報のうちの少なくとも１つの情報を含む
（１２）に記載の送信装置。
（１４）
前記制御情報は、前記緊急情報アプリケーションのライフサイクルを制御するためのコマンドをさらに含む
（１３）に記載の送信装置。
（１５）
前記生成部は、所定のタイミングで、前記緊急情報アプリケーションに関する処理を実行させるためのイベントメッセージを生成し、
前記送信部は、生成された前記イベントメッセージを、前記デジタル放送信号に含めて送信する
（１３）又は（１４）に記載の送信装置。
（１６）
前記イベントメッセージは、MPEG-DASHで規定されるMPDのイベントストリーム要素、又は、DASHセグメントのイベントメッセージボックスに配置される
（１５）に記載の送信装置。
（１７）
前記デジタル放送信号は、IP伝送方式のデジタル放送信号であり、
前記制御情報は、IPパケットに含まれるUDPパケットのペイロードに配置されて伝送される
（１２）乃至（１６）のいずれか一項に記載の送信装置。
（１８）
送信装置のデータ処理方法において、
前記送信装置が、
緊急に告知する必要がある緊急情報の詳細情報に関する情報を含む制御情報であって、前記緊急情報の詳細情報を提示する緊急情報アプリケーションに関する処理に用いられる前記制御情報を生成し、
生成された前記制御情報を、デジタル放送信号に含めて送信する
ステップを含むデータ処理方法。
【符号の説明】
【０３９５】
１  伝送システム，  １０−１，１０−２，１０  送信装置，  ２０，２０−１，２０−２，２０−３  受信装置，  ３０  電波塔，  ４０  EAサーバ，  ８０  伝送路，  ９０  通信回線，  １０１  EAパーサ，  １０２  ライブコンテンツ取得部，  １０３  ストレージ，  １０４  コンポーネント処理部，  １０５  シグナリング処理部，  １０６  LCC処理部，  １０７  エンコーダ，  １０８  マルチプレクサ，  １０９  変調部，  １１０  RF部，  ２０１  RF部，  ２０２  復調部，  ２０３  処理部，  ２０４  出力部，  ２０５  通信I/F，  ２１１  FW/HW部，  ２１２  コンポーネント処理部，  ２１３  MW部，  ２１４  ブラウザ，  ２２１  デマルチプレクサ，  ２２２  デコーダ，  ２３１  パーサ，  ２３２  フィルタ，  ２５１  放送・通信I/F，  ２５２  アプリケーション実行環境／ミドルウェア，  ９００  コンピュータ，  ９０１  CPU
【図１】
2017047397.tif 000003
【図２】
2017047397.tif 000004
【図３】
2017047397.tif 000005
【図４】
2017047397.tif 000006
【図５】
2017047397.tif 000007
【図６】
2017047397.tif 000008
【図７】
2017047397.tif 000009
【図８】
2017047397.tif 000010
【図９】
2017047397.tif 000011
【図１０】
2017047397.tif 000012
【図１１】
2017047397.tif 000013
【図１２】
2017047397.tif 000014
【図１３】
2017047397.tif 000015
【図１４】
2017047397.tif 000016
【図１５】
2017047397.tif 000017
【図１６】
2017047397.tif 000018
【図１７】
2017047397.tif 000019
【図１８】
2017047397.tif 000020
【図１９】
2017047397.tif 000021
【図２０】
2017047397.tif 000022
【図２１】
2017047397.tif 000023
【図２２】
2017047397.tif 000024
【図２３】
2017047397.tif 000025
【図２４】
2017047397.tif 000026
【図２５】
2017047397.tif 000027
【図２６】
2017047397.tif 000028
【図２７】
2017047397.tif 000029
【図２８】
2017047397.tif 000030
【図２９】
2017047397.tif 000031
【国際調査報告】
2017047397.tif 000032
2017047397.tif 000033
2017047397.tif 000034
2017047397.tif 000035