(57)【要約】  本技術は、緊急時に通知される緊急情報を適切な位置に表示することができるようにする受信装置、送信装置、及び、データ処理方法に関する。受信装置は、デジタル放送信号で伝送されるメタデータであって、緊急に告知する必要がある情報である第１の緊急情報と、非圧縮のビデオデータに第２の緊急情報が埋め込まれているかどうかを示すとともに、第２の緊急情報が非圧縮のビデオデータに埋め込まれている場合にその画面上の表示位置を示す表示位置情報とを含むメタデータを取得し、メタデータを処理して、第２の緊急情報が非圧縮のビデオデータに埋め込まれている場合、第２の緊急情報の画面上の表示位置と異なる位置に、第１の緊急情報を表示させる。本技術は、例えば、テレビ受像機に適用することができる。
2017038482.tif 000002
【特許請求の範囲】
【請求項１】
デジタル放送信号を受信する受信部と、
前記デジタル放送信号で伝送されるメタデータであって、緊急に告知する必要がある情報である第１の緊急情報と、非圧縮のビデオデータに第２の緊急情報が埋め込まれているかどうかを示すとともに、前記第２の緊急情報が前記非圧縮のビデオデータに埋め込まれている場合にその画面上の表示位置を示す表示位置情報とを含む前記メタデータを取得する取得部と、
前記メタデータを処理して、前記第２の緊急情報が前記非圧縮のビデオデータに埋め込まれている場合、前記第２の緊急情報の画面上の表示位置と異なる位置に、前記第１の緊急情報を表示させる処理部と
を備える受信装置。
【請求項２】
前記第１の緊急情報は、前記メタデータに含めて伝送されるテキスト情報であり、
前記第２の緊急情報は、前記ビデオデータに埋め込まれて伝送されるテキスト情報である
請求項１に記載の受信装置。
【請求項３】
前記第１の緊急情報は、緊急に告知する必要がある情報の見出しであるメッセージと、その詳細な内容である説明文とから構成される
請求項２に記載の受信装置。
【請求項４】
前記メッセージと、前記説明文とは、異なるレイアウトで表示される
請求項３に記載の受信装置。
【請求項５】
前記メタデータは、前記第１の緊急情報の表示レイアウトに関する表示レイアウト情報をさらに含み、
前記処理部は、前記表示レイアウト情報に基づいて、前記第１の緊急情報が、前記ビデオデータに対応する映像に重畳表示される場合にのみ、前記第１の緊急情報を、前記第２の緊急情報の画面上の表示位置と異なる位置に表示させる
請求項１に記載の受信装置。
【請求項６】
前記表示位置情報は、前記第２の緊急情報が表示される画面上の座標、又は画面上の所定の領域を示す情報である
請求項１に記載の受信装置。
【請求項７】
前記受信部は、IP(Internet Protocol)伝送方式のデジタル放送信号を受信する
請求項１に記載の受信装置。
【請求項８】
受信装置のデータ処理方法において、
前記受信装置が、
デジタル放送信号を受信し、
前記デジタル放送信号で伝送されるメタデータであって、緊急に告知する必要がある情報である第１の緊急情報と、非圧縮のビデオデータに第２の緊急情報が埋め込まれているかどうかを示すとともに、前記第２の緊急情報が前記非圧縮のビデオデータに埋め込まれている場合にその画面上の表示位置を示す表示位置情報とを含む前記メタデータを取得し、
前記メタデータを処理して、前記第２の緊急情報が前記非圧縮のビデオデータに埋め込まれている場合、前記第２の緊急情報の画面上の表示位置と異なる位置に、前記第１の緊急情報を表示させる
ステップを含むデータ処理方法。
【請求項９】
緊急に告知する必要がある情報である第１の緊急情報と、非圧縮のビデオデータに第２の緊急情報が埋め込まれているかどうかを示すとともに、前記第２の緊急情報が前記非圧縮のビデオデータに埋め込まれている場合に受信装置の画面上の表示位置を示す表示位置情報とを含むメタデータを生成する生成部と、
前記メタデータを、デジタル放送信号として送信する送信部と
を備える送信装置。
【請求項１０】
前記第１の緊急情報は、前記メタデータに含めて伝送されるテキスト情報であり、
前記第２の緊急情報は、前記ビデオデータに埋め込まれて伝送されるテキスト情報である
請求項９に記載の送信装置。
【請求項１１】
前記第１の緊急情報は、緊急に告知する必要がある情報の見出しであるメッセージと、その詳細な内容である説明文とから構成される
請求項１０に記載の送信装置。
【請求項１２】
前記メッセージと、前記説明文とは、異なるレイアウトで表示される
請求項１１に記載の送信装置。
【請求項１３】
前記メタデータは、前記第１の緊急情報の表示レイアウトに関する表示レイアウト情報をさらに含む
請求項９に記載の送信装置。
【請求項１４】
前記表示位置情報は、前記第２の緊急情報が表示される画面上の座標、又は画面上の所定の領域を示す情報である
請求項９に記載の送信装置。
【請求項１５】
前記送信部は、前記メタデータを、IP伝送方式のデジタル放送信号として送信する
請求項９に記載の送信装置。
【請求項１６】
送信装置のデータ処理方法において、
前記送信装置が、
緊急に告知する必要がある情報である第１の緊急情報と、非圧縮のビデオデータに第２の緊急情報が埋め込まれているかどうかを示すとともに、前記第２の緊急情報が前記非圧縮のビデオデータに埋め込まれている場合に受信装置の画面上の表示位置を示す表示位置情報とを含むメタデータを生成し、
前記メタデータを、デジタル放送信号として送信する
ステップを含むデータ処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本技術は、受信装置、送信装置、及び、データ処理方法に関し、特に、緊急時に通知される緊急情報を適切な位置に表示することができるようにした受信装置、送信装置、及び、データ処理方法に関する。
【背景技術】
【０００２】
デジタル放送の分野では、緊急時において、緊急に告知する必要がある情報である緊急情報を通知するための各種の提案が行われている（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１５−１０４０５５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ところで、緊急時において、複数の方式で緊急情報を通知する場合に、緊急情報を適切な位置に表示できない可能性があるため、緊急情報を適切な位置に表示するための提案が要請されていた。【０００５】
本技術はこのような状況に鑑みてなされたものであり、緊急時に通知される緊急情報を適切な位置に表示することができるようにするものである。
【課題を解決するための手段】
【０００６】
本技術の第１の側面の受信装置は、デジタル放送信号を受信する受信部と、前記デジタル放送信号で伝送されるメタデータであって、緊急に告知する必要がある情報である第１の緊急情報と、非圧縮のビデオデータに第２の緊急情報が埋め込まれているかどうかを示すとともに、前記第２の緊急情報が前記非圧縮のビデオデータに埋め込まれている場合にその画面上の表示位置を示す表示位置情報とを含む前記メタデータを取得する取得部と、前記メタデータを処理して、前記第２の緊急情報が前記非圧縮のビデオデータに埋め込まれている場合、前記第２の緊急情報の画面上の表示位置と異なる位置に、前記第１の緊急情報を表示させる処理部とを備える受信装置である。【０００７】
本技術の第１の側面の受信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第１の側面のデータ処理方法は、上述した本技術の第１の側面の受信装置に対応するデータ処理方法である。【０００８】
本技術の第１の側面の受信装置、及び、データ処理方法においては、デジタル放送信号が受信され、前記デジタル放送信号で伝送されるメタデータであって、緊急に告知する必要がある情報である第１の緊急情報と、非圧縮のビデオデータに第２の緊急情報が埋め込まれているかどうかを示すとともに、前記第２の緊急情報が前記非圧縮のビデオデータに埋め込まれている場合にその画面上の表示位置を示す表示位置情報とを含む前記メタデータが取得され、前記メタデータが処理されて、前記第２の緊急情報が前記非圧縮のビデオデータに埋め込まれている場合、前記第２の緊急情報の画面上の表示位置と異なる位置に、前記第１の緊急情報が表示される。【０００９】
本技術の第２の側面の送信装置は、緊急に告知する必要がある情報である第１の緊急情報と、非圧縮のビデオデータに第２の緊急情報が埋め込まれているかどうかを示すとともに、前記第２の緊急情報が前記非圧縮のビデオデータに埋め込まれている場合に受信装置の画面上の表示位置を示す表示位置情報とを含むメタデータを生成する生成部と、前記メタデータを、デジタル放送信号として送信する送信部とを備える送信装置である。【００１０】
本技術の第２の側面の送信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第２の側面のデータ処理方法は、上述した本技術の第２の側面の送信装置に対応するデータ処理方法である。【００１１】
本技術の第２の側面の送信装置、及び、データ処理方法においては、緊急に告知する必要がある情報である第１の緊急情報と、非圧縮のビデオデータに第２の緊急情報が埋め込まれているかどうかを示すとともに、前記第２の緊急情報が前記非圧縮のビデオデータに埋め込まれている場合に受信装置の画面上の表示位置を示す表示位置情報とを含むメタデータが生成され、前記メタデータが、デジタル放送信号として送信される。
【発明の効果】
【００１２】
本技術の第１の側面、及び、第２の側面によれば、緊急時に通知される緊急情報を適切な位置に表示することができる。【００１３】
なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。
【図面の簡単な説明】
【００１４】
【図１】本技術を適用した伝送システムの一実施の形態の構成を示す図である。
【図２】IP伝送方式のデジタル放送を採用した場合の緊急情報の伝送方式の概要を示す図である。
【図３】LLSテーブルのシンタックスの例を示す図である。
【図４】緊急情報の表示例を示す図である。
【図５】バナーテキストの表示例を示す図である。
【図６】EATメタデータのシンタックスの例を示す図である。
【図７】伝送システムの各装置の構成例を示す図である。
【図８】送信処理の流れを説明するフローチャートである。
【図９】電源オフ・待機状態時の受信処理の流れを説明するフローチャートである。
【図１０】電源オフ状態時の受信処理の流れを説明するフローチャートである。
【図１１】放送ストリーム受信処理の流れを説明するフローチャートである。
【図１２】EAT受信処理の流れを説明するフローチャートである。
【図１３】バナーテキスト表示処理の流れを説明するフローチャートである。
【図１４】コンピュータの構成例を示す図である。
【発明を実施するための形態】
【００１５】
以下、図面を参照しながら本技術の実施の形態について説明する。なお、説明は以下の順序で行うものとする。
【００１６】
１．本技術を適用した伝送システムの運用
２．シンタックスの例
３．各装置の構成
４．各装置で実行される処理の流れ
５．変形例
６．コンピュータの構成
【００１７】
＜１．本技術を適用した伝送システムの運用＞
【００１８】
（伝送システムの構成例）
図１は、本技術を適用した伝送システムの一実施の形態の構成を示す図である。なお、システムとは、複数の装置が論理的に集合したものをいう。
【００１９】
伝送システム１において、各放送局（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情報を、テレビ番組の映像（非圧縮のビデオデータ）に埋め込んでエンコードしたり、あるいは、所定のフォーマット（例えば、後述するEATメタデータ）に変換したりすることで、緊急情報を生成する。そして、放送局（の送信装置１０）は、生成された緊急情報を、放送エリア内の多数の受信装置２０（例えば、受信装置２０−１乃至２０−３）に対して送信する。
【００２５】
これにより、受信装置２０では、テレビ番組の映像に、緊急情報が重畳して表示されることになる。その結果、ユーザは、受信装置２０の画面に表示された緊急情報（例えばテキスト情報）を確認することができる。
【００２６】
なお、以下の説明では、受信装置２０の画面に表示される緊急情報（テキスト情報）のうち、テレビ番組等のコンテンツの映像（非圧縮のビデオデータ）に埋め込んでエンコードされた緊急情報を、焼き込みテキストと称する。この焼き込みテキストは、「Burned EA Message」又は「EA text」とも記述される。
【００２７】
一方で、受信装置２０の画面に表示される緊急情報（テキスト情報）のうち、CAP情報を所定のフォーマット（例えば、後述するEATメタデータ）に変換して得られた緊急情報を、バナーテキストと称する。このバナーテキストは、「banner text」とも記述される。
【００２８】
また、放送局（の送信装置１０）は、緊急情報源からの緊急情報源情報に応じたCAP情報に基づいて、緊急情報アプリケーション（例えば、緊急情報に関するより詳細な情報）を生成し、EAサーバ４０に提供することができる。なお、この緊急情報アプリケーションは、「EA APP」とも記述される。
【００２９】
受信装置２０は、通信機能を有している場合、インターネットや携帯電話網等の通信回線９０を介してEAサーバ４０にアクセスし、緊急情報アプリケーションを要求することができる。そして、受信装置２０は、通信回線９０を介してEAサーバ４０から配信される緊急情報アプリケーションを受信して実行することができる。これにより、受信装置２０の画面には、例えば、緊急情報に関するより詳細な情報が表示されることになる。
【００３０】
なお、放送局（の送信装置１０）において、緊急情報の生成方法としては、上述した方法に限らず、例えば、CAP情報をそのままの形式で用いるなど、他の生成方法を用いるようにしてもよい。また、緊急情報を生成するための情報としてのCAP情報は一例であって、緊急情報源情報を他の方式に準拠した形式に変換して得られる情報などを用いて、緊急情報が生成されるようにしてもよい。
【００３１】
ところで、各国のデジタル放送の規格では、伝送方式として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伝送方式の緊急情報の伝送方法）
図２は、IP伝送方式のデジタル放送を採用した場合の緊急情報の伝送方式の概要を示す図である。
【００３４】
図２において、左側に示したパイプ図は、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)，EAT(Emergency Alerting Table)等のメタデータが含まれる。SLTメタデータは、サービスの選局に必要な情報(選局情報)など、放送ネットワークにおけるストリームやサービスの構成を示す情報を含む。RRTメタデータは、レーティングに関する情報を含む。EATメタデータは、緊急に告知する必要がある情報である緊急情報（緊急警報情報）に関する情報を含む。
【００３８】
なお、SLTやEAT等のメタデータは、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メタデータは、コンポーネントのストリームの再生を管理するための制御情報である。
【００４１】
なお、USD，S-TSID，MPD等のメタデータは、XML等のマークアップ言語により記述される。また、MPDメタデータは、MPEG-DASH(Dynamic Adaptive Streaming over HTTP)の規格に準じている。
【００４２】
コンポーネントは、ビデオやオーディオ、字幕などのコンテンツを構成するデータである。また、LCCコンテンツは、受信装置２０のストレージに蓄積（ダウンロード）されてから処理されるコンテンツである。ただし、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シグナリングとしてのEATメタデータは、次のように伝送されることになる。
【００４７】
ここで、IP伝送方式のプロトコルスタックにおいて、最も下位の階層は、物理層（L1：Layer1）とされ、この物理層に隣接する上位の階層は、レイヤ２の階層（L2：Layer2）とされ、さらに、レイヤ２の階層に隣接する上位の階層は、IP層とされ、IP層に隣接する上位の階層は、UDP層とされる。
【００４８】
すなわち、図２の右側のフレーム（パケット）の構造図に示すように、物理層の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シグナリングのデータ、すなわち、この例では、EATメタデータが配置される。
【００５０】
ここで、図３には、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シグナリングのデータとして、EATメタデータが配置されることを示している。
【００５２】
図２の説明に戻り、LLSテーブルに含まれるEATメタデータには、緊急情報に関する情報が含まれる。受信装置２０は、EATメタデータにバナーテキストが含まれる場合、EATメタデータに基づいて、そのバナーテキストを表示する。
【００５３】
ただし、EATメタデータには、焼き込みテキストの有無を示す要素があり、その要素は、焼き込みテキストが存在する場合、その焼き込みテキストの表示位置を示す情報（表示位置情報）が含まれている。この場合、受信装置２０は、当該EATメタデータに基づいて、焼き込みテキスト（EA text）の画面上の表示位置と異なる位置に、バナーテキスト（banner text）を表示させる（Ｓ１１）。
【００５４】
また、EATメタデータには、LCCコンテンツとして、緊急情報の詳細情報（緊急詳細情報）を含む緊急情報アプリケーションが提供される場合、緊急情報アプリケーションに関する情報が含まれている。この場合、受信装置２０は、当該EATメタデータに基づいて、ROUTEセッションで伝送される緊急情報アプリケーション（EA APP）を取得して実行し、緊急詳細情報を表示することができる（Ｓ１２）。
【００５５】
さらに、EATメタデータには、EAサーバ４０により緊急詳細情報が提供される場合、そのEAサーバ４０のURL(Uniform Resource Locator)を示す情報が含まれている。この場合、受信装置２０は、当該EATメタデータに基づいて、通信回線９０（Internet）を介してEAサーバ４０にアクセスし、緊急詳細情報を要求する（Ｓ１３，Ｓ１４）。そして、受信装置２０は、EAサーバ４０から配信される緊急詳細情報を表示することができる（Ｓ１４，Ｓ１３）。ただし、EAサーバ４０から配信される緊急詳細情報は、緊急情報アプリケーション（EA APP）として提供することができる。
【００５６】
なお、図２の例では、トランスポート層の伝送プロトコル（トランスポート・プロトコル）として、ROUTEを用いる場合を説明したが、他のトランスポート・プロトコルを用いるようにしてもよい。例えば、現在策定中のATSC3.0では、トランスポート・プロトコルとして、ROUTEとMMT(MPEG Media Transport)が併存することが想定されているが、ROUTEセッションほかに、MMTセッションを用いてコンポーネントやシグナリングのストリームが伝送されるようにしてもよい。
【００５７】
以上のように、ATSC3.0等のIP伝送方式のデジタル放送において、トランスポート・プロトコルとして、ROUTE又はMMTを用いた場合に、緊急時に、緊急情報源（例えば米国連邦緊急事態管理庁（FEMA））からの緊急情報源情報（例えば災害時に発行される緊急警報など）に応じた緊急情報を、受信装置２０に対して提供（通知）することができる。
【００５８】
ここで、緊急情報は、多くの受信装置２０が迅速に表示するための情報と、その詳細情報の２種類に分類することができるが、前者は、主に、「竜巻注意」や「地震注意」などの短いテキスト情報や、視覚障がい者向けの音声の読み上げなどにより提供される。一方で、後者は、主に、HTML5(HyperText Markup Language 5)に対応したアプリケーションや静止画などの複数のモノメディアファイル、マルチメディアファイルにより提供される。
【００５９】
前者については、上述したように、放送局（の送信装置１０）が、テレビ番組の映像に、緊急情報（テキスト情報）を埋め込んだ焼き込みテキストを伝送する方法と、放送局（の送信装置１０）が、テレビ番組の映像や音声とは別に緊急情報（テキスト情報）を伝送して、受信装置２０が、テレビ番組の映像にバナーテキストを重畳表示させる方法とがある。そして、受信装置２０では、焼き込みテキストとバナーテキストのどちらか一方を表示するだけでなく、送信装置１０から、焼き込みテキストとバナーテキストの両方を受信したときには、焼き込みテキストとバナーテキストの両者を同時に表示させる場合がある。
【００６０】
この場合に、受信装置２０の画面上において、バナーテキストが、焼き込みテキストの表示を邪魔せずに表示されるようにすることが求められる。そこで、本技術では、EATメタデータに、焼き込みテキストの有無を示し、焼き込みテキストがある場合に、その焼き込みテキストの表示位置情報（バナーテキストの表示禁止領域情報）を含めることで、受信装置２０が、当該EATメタデータに含まれる表示位置情報に基づいて、焼き込みテキストの表示位置と異なる位置に、バナーテキストを表示させることができるようにしている。
【００６１】
これにより、受信装置２０では、焼き込みテキストとバナーテキストを同時に表示する際に、これらの緊急情報を適切な位置に表示するための制御を行うことが可能となる。また、例えば、番組制作者によっては、緊急情報をビデオスケーリング表示ではなく、オーバーレイ表示してほしい場合などが想定されるが、このような場合でも、番組制作者の意図を反映して緊急情報を表示することができる。また、視聴者が見やすいレイアウトで、緊急情報を提示することが可能である。さらに、放送局側としては、緊急情報として、異なる方式で伝送される焼き込みテキストとバナーテキストの両者を同時に表示させることができるので、緊急情報の伝送手段の選択肢が増えることになる。これは、例えば現在策定中のATSC3.0の放送サービスを開始するに際して、導入設備や導入方法の選択肢が増えることに繋がるため、結果として、導入コストを下げることができるなどのメリットが得られることになる。
【００６２】
なお、後者については、ROUTEセッションによりLCCコンテンツとして伝送される緊急情報アプリケーションや、EAサーバ４０から配信される緊急情報アプリケーションなどによって、緊急詳細情報が提供されるので、例えば、受信装置２０は、緊急情報アプリケーションを取得することで、緊急詳細情報を表示させることができる。
【００６３】
（緊急情報の表示例）
図４は、緊急情報の表示例を示す図である。
【００６４】
緊急情報を画面上に表示するための方式としては、焼き込みテキストのみが表示される第１の方式と、バナーテキストのみが表示される第２の方式と、焼き込みテキストとバナーテキストの両者を同時に表示する第３の方式の３つの方式がある。
【００６５】
図４においては、野球中継番組の視聴中に緊急情報が通知され、第１の方式乃至第３の方式のいずれかの方式に応じて、緊急情報が表示される様子が模式的に表されている。
【００６６】
第１の方式（1.Burned EA Message in uncompressed video）では、図中の上段に示すように、緊急情報（竜巻警報：「Tornado Warning」）が、野球中継番組の映像（非圧縮のビデオデータ）に埋め込まれ、焼き込みテキストとして表示されている。
【００６７】
第２の方式（2.banner text）では、図中の中段に示すように、緊急情報（竜巻警報：「Tornado Warning」、警報の場所と時刻情報：「Fairfield CT. 06/30/15 13:43:00 EDT.」）が、バナーテキストとして表示されている。ここで、第２の方式の表示レイアウトとしては、オーバーレイ表示（overlay）と、ビデオスケーリング表示（video scaling）の２種類がある。
【００６８】
第２の方式でオーバーレイ表示が採用される場合、緊急情報は、バナーテキストとして、野球中継番組の映像の一部に重畳して表示される。以下、第２の方式で、かつ、バナーテキストがオーバーレイ表示される場合を、「第２の方式Ａ」とも称して説明する。
【００６９】
一方で、第２の方式でビデオスケーリング表示が採用される場合、野球中継番組の映像の縦横のサイズが縮小され、それによりできた逆Ｌ字型の領域に、緊急情報が、バナーテキストとして表示される。以下、第２の方式で、かつ、バナーテキストがビデオスケーリング表示される場合を、「第２の方式Ｂ」とも称して説明する。
【００７０】
第３の方式（3.Mixing burned EA Message and banner text）では、図中の下段に示すように、緊急情報（竜巻警報：「Tornado Warning」）が、野球中継番組の映像（非圧縮のビデオデータ）に埋め込まれ、焼き込みテキストとして表示されている。また、第３の方式では、緊急情報（警報の場所と時刻情報：「Fairfield CT. 06/30/15 13:43:00 EDT.」）が、バナーテキストとして表示されている。
【００７１】
ここで、第３の方式の表示レイアウトとしては、第２の方式の表示レイアウトと同様に、オーバーレイ表示（overlay）と、ビデオスケーリング表示（video scaling）の２種類がある。
【００７２】
第３の方式でオーバーレイ表示が採用される場合、緊急情報（警報の場所と時刻情報：「Fairfield CT. 06/30/15 13:43:00 EDT.」）は、バナーテキストとして、野球中継番組の映像の一部に重畳して表示される。以下、第３の方式で、かつ、バナーテキストがオーバーレイ表示される場合を、「第３の方式Ａ」とも称して説明する。
【００７３】
一方で、第３の方式でビデオスケーリング表示が採用される場合、野球中継番組の映像の縦横のサイズが縮小され、それによりできた逆Ｌ字型の領域に、緊急情報が、バナーテキストとして表示される。以下、第３の方式で、かつ、バナーテキストがビデオスケーリング表示される場合を、「第３の方式Ｂ」とも称して説明する。
【００７４】
本技術では、受信装置２０において、焼き込みテキストとバナーテキストの両者を同時に表示させる場合に、EATメタデータに含まれる焼き込みテキストの表示位置情報（バナーテキストの表示禁止領域情報）に基づいて、焼き込みテキストの表示位置と異なる位置に、バナーテキストを表示させるようにしているが、このような場面が想定されるのは、第３の方式Ａのケースである。
【００７５】
なお、バナーテキストが、オーバーレイ表示されるか、ビデオスケーリング表示されるかを示す情報（表示レイアウト情報）は、EATメタデータに含めることができる。また、バナーテキストの表示レイアウトは、オーバーレイ表示とビデオスケーリング表示に限らず、他の表示形態であってもよい。さらに、上述した第２の方式Ｂと第３の方式Ｂのビデオスケーリング表示の表示形態は一例であって、逆Ｌ字型に限らず、例えば、Ｌ字型など、バナーテキストを表示するための領域が確保できるのであれば、他の表示形態を採用してもよい。
【００７６】
（バナーテキストの表示例）
図５は、バナーテキストの表示例を示す図である。
【００７７】
バナーテキストとしては、バナーメッセージと、バナー説明文の２段階で緊急情報を提供することができる。ここで、バナーメッセージは、緊急情報の見出しであって、例えば、短文で緊急情報の種類などを通知するためのものである。また、バナー説明文は、緊急情報の詳細文（詳細情報）を通知するためのものである。
【００７８】
また、バナーメッセージと、バナー説明文とでは、表示形態が異なるようにすることができる。例えば、バナーメッセージを強調して表示する一方で、バナー説明文を、バナーメッセージよりも小さい文字で表示するなどの表示形態を採用することが可能である。
【００７９】
例えば、図５のＡでは、テレビ番組に、バナーテキストが重畳表示されている。このバナーテキストでは、バナーメッセージとして、緊急情報が、気象情報であることを示す見出し（「Severe Thunderstorm Warning」）が強調して表示され、バナー説明文として、その気象情報の詳細な内容（「The National Weather ・・・」）が、見出しよりも小さい文字で表示されている。
【００８０】
同様に、図５のＢでは、例えば、バナーメッセージとして、緊急情報が、アンバーアラート（AMBER Alert）であることを示す見出し（「Child Abduction Emergency」）が強調表示され、バナー説明文として、そのアンバーアラートの詳細な内容（「Civil Authorities have ・・・」）が、見出しよりも小さい文字で表示されている。
【００８１】
＜２．シンタックスの例＞
【００８２】
図６は、XML形式のEATメタデータのシンタックスの例を示す図である。なお、図６において、要素と属性のうち、属性には「@」が付されている。また、インデントされた要素と属性は、その上位の要素に対して指定されたものとなる。
【００８３】
図６に示すように、ルート要素としてのEAT要素は、AutomaticTuningService要素、BurnedInMessageRegion要素、MessageLayoutPolicy要素、及び、EaMessage要素の上位要素となる。
【００８４】
AutomaticTuningService要素には、受信装置２０を強制的に起動させる場合において、起動時に選局されるサービス(自動選局サービス（ATS：Automatic Tuning Service）)に関する情報が指定される。
【００８５】
AutomaticTuningService要素は、broadcastStreamID属性、及び、serviceId属性の上位要素となる。broadcastStreamID属性には、自動選局サービスのブロードキャストストリームIDが指定される。serviceId属性には、自動選局サービスのサービスIDが指定される。
【００８６】
BurnedInMessageRegion要素には、焼き込みテキストが存在する場合に、その焼き込みテキストの表示位置を示す情報（表示位置情報）が指定される。ここで、BurnedInMessageRegion要素は、その出現数（Cardinality）が"0..n"となるので、１又は複数のBurnedInMessageRegion要素を記述できるだけでなく、BurnedInMessageRegion要素を記述しなくてもよい。
【００８７】
１又は複数のBurnedInMessageRegion要素が記述される場合には、焼き込みテキストが存在することを示し、さらに、その要素の値として、対象の焼き込みテキストの表示位置情報が指定されることになる。すなわち、第１の方式又は第３の方式が採用される場合には、１又は複数のBurnedInMessageRegion要素が記述される。
【００８８】
一方で、BurnedInMessageRegion要素が記述されていない場合には、焼き込みテキストが存在しないことを示している。すなわち、第２の方式が採用される場合には、BurnedInMessageRegion要素が記述されることはない。
【００８９】
BurnedInMessageRegion要素は、type属性の上位要素となる。type属性には、焼き込みテキストの表示位置の形式を示すタイプ情報が指定される。このtype属性としては、例えば、"coordinates"や"upper/middle/bottom"が指定される。
【００９０】
"coordinates"は、焼き込みテキストの表示位置が、例えば、受信装置２０の画面の左上を原点として、ＸＹ座標で表されることを示している。また、"upper/middle/bottom"は、受信装置２０の画面を水平方向に３つの領域に分割したときの上側の領域（upper）、真ん中の領域（middle）、及び、下側の領域（bottom）を表しており、そのいずれかの領域を指定することで、その指定領域に、焼き込みテキストが表示されることを示している。
【００９１】
なお、複数のBurnedInMessageRegion要素が記述される場合、受信装置２０の画面上の複数の領域に、焼き込みテキストが表示されることになる。なお、焼き込みテキストの表示位置を示す情報の形式としては、上述した座標等に限らず、焼き込みテキストの表示位置を特定できる情報であれば、他の形式を採用するようにしてもよい（例えば、絶対的な位置や相対的な位置、パーセント表示など）。
【００９２】
MessageLayoutPolicy要素には、バナーテキストの表示レイアウトに関する情報（表示レイアウト情報）が指定される。このMessageLayoutPolicy要素としては、例えば、"overlay"や"scaling"が指定される。
【００９３】
"overlay"は、バナーテキストが、オーバーレイ表示されることを示している。すなわち、第２の方式Ａ又は第３の方式Ａが採用される場合、MessageLayoutPolicy要素として、"overlay"が指定される。また、"scaling"は、バナーテキストがビデオスケーリング表示されることを示している。すなわち、第２の方式Ｂ又は第３の方式Ｂが採用される場合、MessageLayoutPolicy要素として、"scaling"が指定される。
【００９４】
EaMessage要素には、緊急情報に関する情報が指定される。EaMessage要素は、eaMessageId属性、eaCategory属性、EaGeolocation要素、EaBannerMessage要素、EaBannerDescription要素、SpeechInfo要素、SpeechInfoURI要素、EaApplication要素、EaService要素、EaAudio要素、及び、EaWww要素の上位要素となる。
【００９５】
eaMessageId属性には、緊急情報の識別子として、メッセージIDが指定される。eaCategory属性には、緊急情報のカテゴリが指定される。
【００９６】
EaGeolocation要素には、緊急情報の対象地域に関する情報が指定される。EaGeolocation要素は、type属性の上位要素となる。type属性には、緊急情報の対象地域を示す情報が指定される。このtype属性としては、例えば、"zip"や、"latitude/longitude"が指定される。
【００９７】
"zip"は、例えば米国郵政公社（USPS）が使用する5桁又は9桁の郵便番号（ZIP code）により対象地域が指定されることを表している。また、"latitude/longitude"は、緯度と経度により対象地域が指定されることを表している。
【００９８】
EaBannerMessage要素には、緊急情報がバナーテキストとして提供される場合に、そのバナーテキストのバナーメッセージが指定される。なお、このバナーメッセージは、図５のバナーメッセージに対応している。
【００９９】
EaBannerMessage要素は、type属性の上位要素となる。type属性には、バナーテキストのバナーメッセージの種別を示すタイプ情報が指定される。このtype属性としては、例えば、"CAP"や"text"、"EEE code"、"TTML"が指定される。
【０１００】
"CAP"は、バナーメッセージとして、緊急情報源（EA Authority）が発行する緊急情報源情報（緊急警報メッセージ）としてのCAP情報の全部又は一部が提供されることを表している。"text"は、バナーメッセージが、テキスト情報であることを表している。"EEE code"は、バナーメッセージが、連邦通信委員会（FCC：Federal Communications Commission）で規定されるEEEコードに準拠していることを表している。"TTML"は、バナーメッセージが、TTML(Timed Text Markup Language)形式で記述されていることを表している。
【０１０１】
EaBannerDescription要素には、緊急情報がバナーテキストとして提供される場合に、そのバナーテキストのバナー説明文が指定される。なお、このバナー説明文は、図５のバナー説明文に対応している。
【０１０２】
すなわち、第２の方式と第３の方式が採用される場合に、EaBannerMessage要素として、バナーメッセージが記述され、さらに、EaBannerDescription要素として、バナー説明文が記述されることになる。
【０１０３】
SpeechInfo要素は、音声発話メタデータが提供される場合に、音声発話メタデータの内容そのものが記述される。ここで、音声発話メタデータとは、緊急情報に対する制作者が意図した通りの音声の発話が行われるようにするために、制作者が意図する音声の発話に関する情報である。例えば、この音声発話メタデータの内容は、音声合成マークアップ言語であるSSML(Speech Synthesis Markup Language)形式で記述される。この音声発話メタデータを用いて、視覚障がい者向けの音声の読み上げが行われる。
【０１０４】
SpeechInfo要素は、content-type属性及びcontent-enc属性の上位要素となる。content-type属性には、SpeechInfo要素に記述される音声発話メタデータの種別を示すタイプ情報が指定される。このcontent-type属性としては、例えば、"SSML"が指定される。また、content-enc属性には、SpeechInfo要素に記述される音声発話メタデータの符号化方式を示す情報が指定される。このcontent-enc属性としては、例えば、"zip"が指定される。
【０１０５】
SpeechInfoURI要素は、音声発話メタデータが提供される場合に、音声発話メタデータを取得するためのアドレス情報（例えば、URI(Uniform Resource Identifier)）が指定される。例えば、音声発話メタデータファイルが、インターネット等の通信回線９０に接続されたEAサーバ４０から提供される場合、このEAサーバ４０にアクセスするためのURLが、アドレス情報として指定される。
【０１０６】
SpeechInfoURI要素は、content-type属性及びcontent-enc属性の上位要素となる。content-type属性には、URI等のアドレス情報を参照することで取得される音声発話メタデータの種別を示すタイプ情報が指定される。このcontent-type属性としては、例えば、"SSML"が指定される。また、content-enc属性には、URI等のアドレス情報を参照することで取得される音声発話メタデータの符号化方式を示す情報が指定される。このcontent-enc属性としては、例えば、"zip"が指定される。
【０１０７】
EaApplication要素には、緊急詳細情報を含む緊急情報アプリケーションが提供される場合に、その緊急情報アプリケーションに関する情報が指定される。EaApplication要素は、applicationId属性の上位要素となる。applicationId属性には、緊急情報アプリケーションのアプリケーションIDが指定される。なお、このアプリケーションIDは、AIT(Application Information Table)等のアプリケーション制御情報で管理されるアプリケーションの識別子に関連付けられる。
【０１０８】
EaService要素には、緊急詳細情報が、緊急情報サービスとして提供される場合に、その緊急情報サービスに関する情報が指定される。EaService要素は、serviceId属性の上位要素となる。serviceId属性には、緊急情報サービスのサービスIDが指定される。
【０１０９】
EaAudio要素には、緊急情報（緊急詳細情報）が、音声情報として、他のサービスと共有されるシェアドオーディオのコンポーネントにより提供される場合に、そのシェアドオーディオに関する情報が指定される。EaAudio要素は、id属性の上位要素となる。id属性には、オーディオのコンポーネントを識別するためのコンポーネントIDが指定される。
【０１１０】
EaWww要素には、緊急詳細情報が、インターネット等の通信回線９０に接続されたEAサーバ４０により提供される場合に、このEAサーバ４０に関する情報が指定される。EaWww要素は、uri属性の上位要素となる。uri属性には、緊急詳細情報を提供するEAサーバ４０のURLが指定される。なお、EAサーバ４０は、緊急詳細情報として、緊急情報アプリケーションを提供することができる。
【０１１１】
なお、図６において、出現数（Cardinality）であるが、"1"が指定された場合にはその要素又は属性は必ず１つだけ指定され、"0..1"が指定された場合には、その要素又は属性を指定するかどうかは任意である。また、"1..n"が指定された場合には、その要素又は属性は１以上指定され、"0..n"が指定された場合には、その要素又は属性を１以上指定するかどうかは任意である。
【０１１２】
また、Data Typeとして、"integer"が指定された場合には、その要素又は属性の値が、整数型であることを示し、"string"が指定された場合には、その要素又は属性の値が、文字列型であることを示している。また、Data Typeとして、"anyURI"が指定された場合、その要素又は属性の値が、anyURIデータ型であることを示している。
【０１１３】
なお、図６に示したEATメタデータのシンタックスは、一例であって、例えば、他の要素や属性を追加するなど、他のシンタックスを採用してもよい。また、EATメタデータは、XML形式に限らず、他のマークアップ言語により記述してもよいし、あるいはセクション形式であってもよい。
【０１１４】
＜３．各装置の構成＞
【０１１５】
次に、図１の伝送システム１を構成する各装置の詳細な構成について説明する。ここでは、放送局により設置される送信装置１０の構成と、ユーザにより設置される受信装置２０の構成を中心に説明する。
【０１１６】
図７は、伝送システム１の各装置の構成例を示す図である。
【０１１７】
図７において、送信装置１０は、EAパーサ１０１、ライブコンテンツ取得部１０２、ストレージ１０３、コンポーネント処理部１０４、シグナリング処理部１０５、LCC処理部１０６、エンコーダ１０７、マルチプレクサ１０８、変調部１０９、及び、RF部１１０から構成される。
【０１１８】
EAパーサ１０１は、緊急時に、緊急情報源（EA Authority）から通知される緊急情報源情報としてのCAP情報を取得し、解析する。EAパーサ１０１は、CAP情報の解析結果（緊急情報）を、コンポーネント処理部１０４、シグナリング処理部１０５、又はLCC処理部１０６に供給する。
【０１１９】
ライブコンテンツ取得部１０２は、コンポーネント処理部１０４からの要求に応じて、例えば、中継場所から伝送路や通信回線を介して送られてくるライブコンテンツ（例えば、スポーツ中継等の生放送番組）のデータを取得し、コンポーネント処理部１０４に供給する。このライブコンテンツは、ビデオやオーディオ、字幕などのコンポーネントから構成される。
【０１２０】
ストレージ１０３は、例えば、収録済みのコンテンツ（例えば、ドラマ等の事前収録番組）を蓄積している。ストレージ１０３は、コンポーネント処理部１０４からの要求に応じて、蓄積している収録済みのコンテンツを、コンポーネント処理部１０４に供給する。この収録済みコンテンツは、ビデオやオーディオ、字幕などのコンポーネントから構成される。
【０１２１】
コンポーネント処理部１０４は、ライブコンテンツ取得部１０２からのライブコンテンツ、又はストレージ１０３からの収録済みコンテンツを取得し、取得されたコンテンツを構成するビデオやオーディオのコンポーネントを処理し、エンコーダ１０７に供給する。
【０１２２】
エンコーダ１０７は、コンポーネント処理部１０４から供給される、ビデオやオーディオのコンポーネントのデータを、所定の符号化方式に従ってエンコードし、マルチプレクサ１０８に供給する。
【０１２３】
また、緊急時において、第１の方式又は第３の方式が採用されている場合、受信装置２０の画面に、焼き込みテキスト（EA Text）を表示させるので、EAパーサ１０１からの緊急情報が、コンポーネント処理部１０４に供給される。コンポーネント処理部１０４は、EAパーサ１０１から緊急情報が供給された場合、コンテンツ（例えば生放送番組や事前収録番組）の映像（非圧縮のビデオデータ）に、EAパーサ１０１からの緊急情報（テキスト情報）を埋め込む。そして、エンコーダ１０７は、所定の符号化方式に従い、緊急情報（テキスト情報）が埋め込まれたビデオデータをエンコードすることになる。
【０１２４】
シグナリング処理部１０５は、LLSシグナリングやSLSシグナリングなどのシグナリングを生成し、マルチプレクサ１０８に供給する。例えば、LLSシグナリングとしては、SLTメタデータなどが生成される。また、SLSシグナリングとしては、USD，S-TSID，MPD等のメタデータが生成される。
【０１２５】
また、シグナリング処理部１０５は、緊急時に、EAパーサ１０１から緊急情報が供給された場合、緊急情報に応じたEATメタデータを生成し、マルチプレクサ１０８に供給する。ただし、第２の方式又は第３の方式が採用されている場合、受信装置２０の画面に、バナーテキスト（banner text）を表示させるので、EAパーサ１０１からの緊急情報に対応するバナーメッセージやバナー説明文が、EATメタデータに含められる。
【０１２６】
LCC処理部１０６は、LCCコンテンツが提供される場合に、LCCコンテンツを生成し、マルチプレクサ１０８に供給する。また、LCC処理部１０６は、緊急時に、EAパーサ１０１から緊急情報が供給された場合、当該緊急情報に基づいて、緊急情報アプリケーションを生成し、マルチプレクサ１０８に供給する。
【０１２７】
マルチプレクサ１０８は、エンコーダ１０７から供給されるコンポーネントのストリームと、シグナリング処理部１０５から供給されるシグナリングのストリームを多重化して、多重化ストリームを生成し、変調部１０９に供給する。また、マルチプレクサ１０８は、LCCコンテンツ（緊急情報アプリケーション）が提供される場合には、コンポーネントとシグナリングのストリームに加えて、LCC処理部１０６から供給されるLCCコンテンツ（緊急情報アプリケーション）のストリームを多重化して、多重化ストリームを生成する。
【０１２８】
変調部１０９は、マルチプレクサ１０８から供給される多重化ストリームのデータに対する誤り訂正符号化処理（例えば、BCH符号化やLDPC符号化等）や変調処理（例えば、OFDM(Orthogonal Frequency Division Multiplexing)変調等）を行い、その処理の結果得られる信号を、RF部１１０に供給する。
【０１２９】
RF部１１０は、変調部１０９から供給される信号を、RF(Radio Frequency)信号に変換し、アンテナ（不図示）を介して、IP伝送方式のデジタル放送信号として、送信する。
【０１３０】
送信装置１０は、以上のように構成される。なお、図７においては、説明の都合上、送信側の装置が、送信装置１０、すなわち、１つの装置で構成される場合を示しているが、図７のブロックの各機能を有する複数の装置からなる送信システムとして構成されるようにしてもよい。また、送信装置１０が通信機能を有するようにすることで、緊急情報アプリケーション（EA APP）や音声発話メタデータ（SpeechInfo）が、送信装置１０から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コンテンツ（緊急情報アプリケーション）のストリームが含まれる場合、LCCコンテンツ（緊急情報アプリケーション）のストリームを分離して、ブラウザ２１４に供給する。
【０１３９】
デコーダ２２２は、デマルチプレクサ２２１から供給されるコンポーネントのストリームに基づいて、ビデオやオーディオのコンポーネントのデータをデコードし、コンポーネント処理部２１２に供給する。
【０１４０】
コンポーネント処理部２１２は、デコーダ２２２から供給されるビデオやオーディオのデータを処理し、出力部２０４に供給する。
【０１４１】
ただし、緊急時において、第１の方式又は第３の方式が採用されている場合、コンテンツ（例えば生放送番組や事前収録番組）の映像（非圧縮のビデオデータ）には、緊急情報（テキスト情報）が埋め込まれており、これが、焼き込みテキスト（EA Text）として表示されることになる。
【０１４２】
MW部２１３は、ミドルウェア（MW：Middleware）により構成され、デマルチプレクサ２２１から供給されるシグナリングのストリームに対する処理を行う。MW部２１３は、パーサ２３１、及び、フィルタ２３２から構成される。パーサ２３１は、対象のシグナリングの解析処理を行う。フィルタ２３２は、対象のシグナリングの抽出処理を行う。そして、処理部２０３では、MW部２１３で処理されたシグナリングに基づいて、コンポーネントやアプリケーション等に対する処理が行われる。
【０１４３】
ただし、緊急時においては、送信装置１０からEATメタデータが通知されるので、MW部２１３は、当該EATメタデータを取得して、処理することになる。さらに、第２の方式又は第３の方式が採用されている場合、EATメタデータにバナーメッセージやバナー説明文が含まれており、これが、バナーテキスト（banner text）として表示されることになる。
【０１４４】
ブラウザ２１４は、例えば、HTML5に対応したブラウザであり、デマルチプレクサ２２１から供給される、緊急情報アプリケーションを実行する。この緊急情報アプリケーション（EA APP）によって、例えば、緊急詳細情報が表示されることになる。
【０１４５】
出力部２０４は、コンポーネント処理部２１２から供給されるビデオデータを処理し、表示部（不図示）に出力する。また、出力部２０４は、コンポーネント処理部２１２から供給されるオーディオデータを処理し、スピーカ（不図示）に出力する。これにより、表示部では、生放送番組や事前収録番組等のコンテンツの映像が表示され、その映像に同期した音声が、スピーカから出力される。
【０１４６】
ただし、緊急時において、第１の方式又は第３の方式が採用されている場合、表示部には、緊急情報に応じた焼き込みテキスト（EA Text）が埋め込まれた、生放送番組等のコンテンツの映像が表示されることになる。また、緊急時において、第２の方式又は第３の方式が採用されている場合、表示部には、生放送番組等のコンテンツの映像に、バナーメッセージやバナー説明文を含むバナーテキスト（banner text）が重畳表示されることになる。さらに、ブラウザ２１４により緊急情報アプリケーション（EA APP）が実行された場合、その緊急詳細情報が表示されることになる。
【０１４７】
通信I/F２０５は、インターネット等の通信回線９０を介して、EAサーバ４０と各種のデータをやりとりする。
【０１４８】
例えば、通信I/F２０５は、EATメタデータの解析結果に応じて、通信回線９０を介してEAサーバ４０に対して、緊急情報アプリケーション（EA APP）を要求することで、EAサーバ４０から配信される緊急情報アプリケーション（EA APP）を受信し、処理部２０３のブラウザ２１４に供給することができる。これにより、ブラウザ２１４は、EAサーバ４０から配信される緊急情報アプリケーション（EA APP）を実行することができる。
【０１４９】
また、例えば、通信I/F２０５は、EATメタデータの解析結果に応じて、通信回線９０を介してEAサーバ４０に対して、音声発話メタデータ（SpeechInfo）を要求することで、EAサーバ４０から配信される音声発話メタデータ（SpeechInfo）を受信し、処理部２０３のFW/HW部２１１のデコーダ２２２に供給することができる。これにより、デコーダ２２２（のTTSエンジン）は、音声発話メタデータ（SpeechInfo）に基づいて、緊急情報（テキスト情報）を読み上げることができる。なお、TTSエンジンは、テキスト情報から、人間の音声を人工的に作り出すことができる音声合成機（Text To Speech Synthesizer）である。
【０１５０】
受信装置２０は、以上のように構成される。なお、受信装置２０は、テレビ受像機、セットトップボックス（STB：Set Top Box）、又は、録画機などの固定受信機のほか、携帯電話機、スマートフォン、又はタブレット端末などのモバイル受信機であってもよい。また、受信装置２０は、車両に搭載される車載機器でもよい。さらに、図７の受信装置２０の構成では、表示部とスピーカが、外部に設けられる構成を示したが、表示部とスピーカは、受信装置２０の内部に設けられるようにしてもよい。
【０１５１】
＜４．各装置で実行される処理の流れ＞
【０１５２】
次に、図８乃至図１３のフローチャートを参照して、図１の伝送システム１を構成する各装置で実行される処理の流れについて説明する。
【０１５３】
（送信処理の流れ）
まず、図８のフローチャートを参照して、図７の送信装置１０により実行される送信処理の流れについて説明する。
【０１５４】
ステップＳ１０１において、コンポーネント処理部１０４及びエンコーダ１０７は、コンポーネント処理を行う。
【０１５５】
このコンポーネント処理では、ライブコンテンツ取得部１０２により取得されるライブコンテンツ（例えば生放送番組）、又はストレージ１０３に蓄積されている収録済みのコンテンツ（例えば事前収録番組）が取得され、取得されたコンテンツを構成するビデオやオーディオのコンポーネントに対して、所定の符号化方式に応じたエンコードなどの処理が行われる。
【０１５６】
また、緊急時において、第１の方式又は第３の方式が採用されている場合、受信装置２０の画面に、焼き込みテキストを表示させるので、コンポーネント処理では、コンテンツ（例えば生放送番組や事前収録番組）の映像（非圧縮のビデオデータ）に、EAパーサ１０１からの緊急情報（テキスト情報）を埋め込んでから、エンコードが行われる。なお、第２の方式が採用されている場合には、バナーテキストのみを表示させるため、コンテンツの映像に緊急情報を埋め込む必要はない。
【０１５７】
ステップＳ１０２において、シグナリング処理部１０５は、シグナリング処理を行う。
【０１５８】
このシグナリング処理では、LLSシグナリングやSLSシグナリングなどのシグナリングが生成され、処理される。
【０１５９】
また、緊急時において、シグナリング処理では、LLSシグナリングとして、EAパーサ１０１からの緊急情報に応じたEATメタデータが生成される。
【０１６０】
ここで、第１の方式が採用されている場合、焼き込みテキストのみを表示させるので、EATメタデータには、バナーテキストに関する情報を記述する必要はない。また、第２の方式が採用されている場合、バナーテキストのみを表示させるので、EATメタデータには、焼き込みテキストに関する情報（例えば焼き込みテキストの表示位置情報）を記述する必要はない。さらに、第３の方式が採用されている場合、EATメタデータには、焼き込みテキストの表示位置情報と、バナーテキストの表示レイアウト情報が記述される。
【０１６１】
ステップＳ１０３において、LCC処理部１０６は、アプリケーション処理を行う。
【０１６２】
このアプリケーション処理は、例えば、緊急時であって、緊急情報アプリケーションを伝送する場合に実行され、EAパーサ１０１からの緊急情報に応じた緊急情報アプリケーションが生成される。
【０１６３】
ステップＳ１０４において、マルチプレクサ１０８は、多重化ストリーム生成処理を行う。
【０１６４】
この多重化ストリーム生成処理では、ステップＳ１０１の処理で得られるコンポーネントのストリームと、ステップＳ１０２の処理で得られるシグナリングのストリームとが多重化され、多重化ストリームが生成される。ただし、緊急時においては、シグナリングに、EATメタデータが含まれる。また、緊急情報アプリケーションが生成された場合には、そのストリームも多重化される。
【０１６５】
ステップＳ１０５において、変調部１０９及びRF部１１０は、放送ストリーム送信処理を行う。
【０１６６】
この放送ストリーム送信処理では、ステップＳ１０４の処理で生成された多重化ストリームが、IP伝送方式のデジタル放送信号として送信される。
【０１６７】
ステップＳ１０５の処理が終了すると、図８の送信処理は終了される。
【０１６８】
以上、送信処理の流れについて説明した。
【０１６９】
（電源オフ・待機状態時の受信処理の流れ）
次に、図９のフローチャートを参照して、図７の受信装置２０により実行される、電源オフ・待機状態時における受信処理の流れについて説明する。ただし、図９のフローチャートの処理が実行される前提として、受信装置２０が、電源オフで、かつ、待機状態、すなわち、受信装置２０において、RF部２０１及び復調部２０２のみが動作可能な状態であるものとする。
【０１７０】
ステップＳ２０１において、RF部２０１及び復調部２０２は、L1パケット受信処理を行う。
【０１７１】
このL1パケット受信処理では、送信装置１０からのデジタル放送信号が受信され、デジタル放送信号として伝送されるL1フレームが取得される。
【０１７２】
ステップＳ２０２において、復調部２０２は、ステップＳ２０１の処理で取得されるL1フレームのL1ヘッダに含まれるウェイクアップフラグ（wake-up flag）を監視する。
【０１７３】
ステップＳ２０３においては、ステップＳ２０２の監視結果に基づいて、ウェイクアップフラグが、"TRUE"であるかどうかが判定される。ステップＳ２０３において、ウェイクアップフラグが、"FALSE"であると判定された場合、処理は、ステップＳ２０１に戻り、ステップＳ２０１乃至Ｓ２０３の処理が繰り返される。
【０１７４】
そして、ステップＳ２０３において、ウェイクアップフラグが、"TRUE"であると判定された場合、処理は、ステップＳ２０４に進められる。ステップＳ２０４においては、受信装置２０の電源がオンされる。これにより、受信装置２０においては、処理部２０３や出力部２０４など、RF部２０１及び復調部２０２以外の他のブロックについても動作可能な状態となる。
【０１７５】
ステップＳ２０４の処理によって、受信装置２０の全ての機能が実行可能になると、処理は、ステップＳ２０５に進められる。ステップＳ２０５においては、放送ストリーム受信処理が行われる。
【０１７６】
この放送ストリーム受信処理では、シグナリングに基づいて、ビデオやオーディオのコンポーネントが処理され、コンテンツの映像と音声が再生される。また、緊急時においては、焼き込みテキストやバナーテキストなどの緊急情報が表示される。なお、この放送ストリーム受信処理の詳細な内容については、図１１のフローチャートを参照して後述する。
【０１７７】
ステップＳ２０６においては、ステップＳ２０５の放送ストリーム受信処理を終了するかどうかが判定される。ステップＳ２０６において、放送ストリーム受信処理を継続すると判定された場合、処理は、ステップＳ２０５に戻り、ステップＳ２０５乃至Ｓ２０６の処理が繰り返される。一方で、ステップＳ２０６において、放送ストリーム受信処理を終了すると判定された場合、図９の電源オフ・待機状態時における受信処理は、終了される。
【０１７８】
以上、電源オフ・待機状態時における受信処理の流れについて説明した。
【０１７９】
（電源オフ状態時の受信処理の流れ）
次に、図１０のフローチャートを参照して、図７の受信装置２０により実行される、電源オフ状態時における受信処理の流れについて説明する。ただし、図１０のフローチャートの処理が実行される前提として、受信装置２０が、電源オフ状態、すなわち、受信装置２０において、全ての機能が実行不可能な状態であるものとする。
【０１８０】
ステップＳ２１１においては、例えば、ユーザの操作に応じて、受信装置２０の電源がオンされる。
【０１８１】
ステップＳ２１１の処理によって、受信装置２０の全ての機能が実行可能になると、処理は、ステップＳ２１２に進められる。ステップＳ２１２においては、放送ストリーム受信処理が行われる。
【０１８２】
この放送ストリーム受信処理では、シグナリングに基づいて、ビデオやオーディオのコンポーネントが処理され、コンテンツの映像と音声が再生される。また、緊急時においては、焼き込みテキストやバナーテキストなどの緊急情報が表示される。なお、この放送ストリーム受信処理の詳細な内容については、図１１のフローチャートを参照して後述する。
【０１８３】
ステップＳ２１３においては、ステップＳ２１２の放送ストリーム受信処理を終了するかどうかが判定される。ステップＳ２１３において、放送ストリーム受信処理を継続すると判定された場合、処理は、ステップＳ２１２に戻り、ステップＳ２１２乃至Ｓ２１３の処理が繰り返される。一方で、ステップＳ２１３において、放送ストリーム受信処理を終了すると判定された場合、図１０の電源オフ状態時における受信処理は、終了される。
【０１８４】
以上、電源オフ状態時における受信処理の流れについて説明した。
【０１８５】
（放送ストリーム受信処理の流れ）
次に、図１１のフローチャートを参照して、図９のステップＳ２０５の処理又は図１０のステップＳ２１２の処理に対応する、放送ストリーム受信処理の流れについて説明する。
【０１８６】
ステップＳ２２１において、デマルチプレクサ２２１は、パケット受信処理を行う。このパケット受信処理では、復調部２０２により処理されたL1フレームから、ALPパケットやIP/UDPパケットが処理される。
【０１８７】
ステップＳ２２２においては、ステップＳ２２１の処理で得られるパケットに基づいて、LLSシグナリング（LLSテーブル）が取得されたかどうかが判定される。ステップＳ２２２において、LLSシグナリングが取得されたと判定された場合、処理は、ステップＳ２２３に進められる。
【０１８８】
ステップＳ２２３において、MW部２１３は、LLSシグナリングの種別とバージョンを判別する。ここでは、上述した図３を参照して説明したように、LLSテーブル（のLLヘッダ）に含まれるLLSテーブルIDとLLSテーブルのバージョンを解析することで、LLSシグナリングの種別とバージョンが判別される。
【０１８９】
ステップＳ２２４において、MW部２１３は、ステップＳ２２３の判別結果に基づいて、LLSシグナリングが更新されているかどうかを判定する。ステップＳ２２４において、LLSシグナリングが更新されていると判定された場合、処理は、ステップＳ２２５に進められる。
【０１９０】
ステップＳ２２５において、MW部２１３は、ステップＳ２２３の判別結果に基づいて、LLSシグナリングが、EATメタデータであるかどうかを判定する。ステップＳ２２５において、LLSシグナリングがEATメタデータであると判定された場合、処理は、ステップＳ２２６に進められる。
【０１９１】
ステップＳ２２６においては、EAT受信処理が行われる。このEAT受信処理では、EATメタデータに応じた緊急情報に関する処理が行われる。なお、このEAT受信処理の詳細な内容については、図１２のフローチャートを参照して後述する。
【０１９２】
一方で、ステップＳ２２５において、LLSシグナリングがEATメタデータではないと判定された場合、処理は、ステップＳ２２７に進められる。ステップＳ２２７においては、他のLLSシグナリング受信処理が行われる。このLLSシグナリング受信処理では、SLTメタデータなどのEATメタデータ以外のLLSシグナリングに対する処理が行われる。
【０１９３】
なお、ステップＳ２２４において、LLSシグナリングが更新されていないと判定された場合、LLSシグナリングに対する処理を行う必要はないので、ステップＳ２２５乃至Ｓ２２７の処理はスキップされる。また、ステップＳ２２６又はステップＳ２２７の処理が終了すると、図１１の放送ストリーム受信処理は終了され、処理は、図９のステップＳ２０５又は図１０のステップＳ２１２に戻り、それ以降の処理が実行される。
【０１９４】
また、ステップＳ２２２において、LLSシグナリングが取得されていないと判定された場合、処理は、ステップＳ２２８に進められる。ステップＳ２２８においては、対象のROUTEセッションの種別が判定される。なお、上述したように、ATSC3.0の場合、コンポーネントやシグナリングがMMTセッションで伝送される場合もあるが、ここでは、説明の簡略化のため、ROUTEセッションが用いられる場合についてのみ説明する。
【０１９５】
ステップＳ２２８において、ROUTEセッションの種別が、ビデオやオーディオ等のコンポーネントであると判定された場合、処理は、ステップＳ２２９に進められる。ステップＳ２２９乃至Ｓ２３０においては、ROUTEセッションで伝送されるコンポーネントに関する処理が行われる。
【０１９６】
具体的には、ステップＳ２２９において、デコーダ２２２及びコンポーネント処理部２１２は、コンポーネント受信処理を行う。このコンポーネント受信処理では、テレビ番組等のコンテンツを構成するビデオやオーディオのコンポーネントに対して、所定の復号方式に応じたデコードなどの処理が行われる。
【０１９７】
ステップＳ２３０において、出力部２０４は、レンダリング処理を行う。このレンダリング処理では、ステップＳ２２９の処理結果に基づいて、テレビ番組等のコンテンツの映像と音声が再生され、出力される。
【０１９８】
また、ステップＳ２２８において、ROUTEセッションの種別が、SLSシグナリングであると判定された場合、処理は、ステップＳ２３１に進められる。ステップＳ２３１乃至Ｓ２３３においては、ROUTEセッションで伝送されるSLSシグナリングに関する処理が行われる。
【０１９９】
具体的には、ステップＳ２３１において、MW部２１３は、SLSシグナリング受信解析処理を行う。このSLSシグナリング受信解析処理では、ROUTEセッションで伝送される、USDメタデータやS-TSIDメタデータ等のSLSシグナリングが取得され、解析される。
【０２００】
ステップＳ２３２においては、ステップＳ２３１の解析結果に基づいて、SLSシグナリングが更新されたかどうかが判定される。ステップＳ２３２において、SLSシグナリングが更新されていると判定された場合、処理は、ステップＳ２３３に進められる。
【０２０１】
ステップＳ２３３においては、ステップＳ２３１の解析結果に基づいて、SLSシグナリングの更新内容が反映される。なお、ステップＳ２３２において、SLSシグナリングが更新されていないと判定された場合、ステップＳ２３３の処理はスキップされる。
【０２０２】
また、ステップＳ２２８において、ROUTEセッションの種別が、LCCコンテンツであると判定された場合、処理は、ステップＳ２３４に進められる。ステップＳ２３４乃至Ｓ２３５においては、ROUTEセッションで伝送されるLCCコンテンツに関する処理が行われる。
【０２０３】
具体的には、ステップＳ２３４においては、LCCコンテンツ受信処理が行われ、例えばアプリケーションなどのLCCコンテンツが取得される。ステップＳ２３５においては、ローカルキャッシュ処理が行われ、ステップＳ２３４の処理で取得されたLCCコンテンツが、ストレージ（不図示）に蓄積（ダウンロード）される。
【０２０４】
ステップＳ２３０，Ｓ２３３，又はＳ２３５の処理が終了すると、図１１の放送ストリーム受信処理は終了され、処理は、図９のステップＳ２０５又は図１０のステップＳ２１２に戻り、それ以降の処理が実行される。
【０２０５】
以上、放送ストリーム受信処理の流れについて説明した。
【０２０６】
（EAT受信処理の流れ）
次に、図１２のフローチャートを参照して、図１１のステップＳ２２６の処理に対応する、EAT受信処理の流れについて説明する。
【０２０７】
ステップＳ２４１において、MW部２１３は、EATメタデータを取得する。
【０２０８】
ステップＳ２４２において、MW部２１３は、ステップＳ２４１の処理で取得されたEATメタデータの解析処理を行う。
【０２０９】
ステップＳ２４３において、MW部２１３は、ステップＳ２４２の解析結果に基づいて、自動選局処理を行うかどうかを判定する。ここでは、XML形式のEATメタデータに記述されるAutomaticTuningService要素で指定される自動選局サービスに関する情報に基づいて、自動選局処理の実行が判定される。
【０２１０】
ステップＳ２４３において、自動選局処理を行うと判定された場合、処理は、ステップＳ２４４に進められる。ステップＳ２４４においては、緊急放送の選局処理が行われる。ここでは、EATメタデータに記述されるAutomaticTuningService要素のbroadcastStreamID属性と、serviceId属性で指定される自動選局サービスのブロードキャストストリームIDと、サービスIDに基づいて、緊急放送の選局処理が行われる。
【０２１１】
ステップＳ２４４の処理が終了すると、図１２のEAT受信処理は終了され、処理は、図１１のステップＳ２２６の処理に戻り、それ以降の処理が実行される。
【０２１２】
一方で、ステップＳ２４３において、自動選局処理を行わないと判定された場合、処理は、ステップＳ２４５に進められる。
【０２１３】
ステップＳ２４５において、MW部２１３は、ステップＳ２４２の解析結果に基づいて、緊急情報の対象地域かどうかを判定する。ここでは、EATメタデータに記述されるEaGeolocation要素で指定される緊急情報の対象地域に関する情報に基づいて、緊急情報の対象地域であるかどうかの判定処理が行われる。
【０２１４】
ステップＳ２４５において、緊急情報の対象地域であると判定された場合、処理は、ステップＳ２４６に進められる。ステップＳ２４６において、MW部２１３は、ステップＳ２４２の解析結果に基づいて、バナーテキストを含むかどうかを判定する。ここでは、EATメタデータに記述されるEaMessage要素のEaBannerMessage要素とEaBannerDescription要素で指定されるバナーテキストに関する情報に基づいて、EATメタデータに、バナーテキストを含むかどうかの判定処理が行われる。
【０２１５】
ステップＳ２４６において、バナーテキストを含むと判定された場合、処理は、ステップＳ２４７に進められる。ステップＳ２４７において、MW部２１３及び出力部２０４等は、バナーテキスト表示処理を行う。このバナーテキスト表示処理では、EATメタデータに基づいて、焼き込みテキストの表示位置に応じてバナーテキストが表示されることになる。なお、このバナーテキスト表示処理の詳細な内容については、図１３のフローチャートを参照して後述する。
【０２１６】
ステップＳ２４７の処理が終了すると、処理は、ステップＳ２４８に進められる。また、ステップＳ２４６において、バナーテキストを含まないと判定された場合、ステップＳ２４７の処理はスキップされ、処理は、ステップＳ２４８に進められる。
【０２１７】
ステップＳ２４８において、MW部２１３は、ステップＳ２４２の解析結果に基づいて、EATメタデータに、音声情報を含むかどうかを判定する。ここでは、EATメタデータに記述されるSpeechInfo要素又はSpeechInfoURI要素で指定される音声発話メタデータに関する情報に基づいて、音声情報を含むかどうかの判定処理が行われる。
【０２１８】
ステップＳ２４８において、音声情報を含むと判定された場合、処理は、ステップＳ２４９に進められる。ステップＳ２４９において、MW部２１３及び出力部２０４等は、音声出力処理を行う。この音声出力処理では、音声発話メタデータに基づいて、緊急情報（テキスト情報）の読み上げが行われる。
【０２１９】
ステップＳ２４９の処理が終了すると、処理は、ステップＳ２５０に進められる。また、ステップＳ２４８において、音声情報を含まないと判定された場合、ステップＳ２４９の処理はスキップされ、処理は、ステップＳ２５０に進められる。
【０２２０】
ステップＳ２５０において、MW部２１３は、ステップＳ２４２の解析結果に基づいて、EATメタデータに、緊急情報アプリケーションを含むかどうかを判定する。ここでは、EATメタデータに記述されるEaApplication要素で指定される緊急情報アプリケーションに関する情報に基づいて、緊急情報アプリケーションを含むかどうかの判定処理が行われる。
【０２２１】
ステップＳ２５０において、緊急情報アプリケーションを含むと判定された場合、処理は、ステップＳ２５１に進められる。ステップＳ２５１において、ブラウザ２１４及び出力部２０４等は、緊急情報アプリケーション出力処理を行う。この緊急情報アプリケーション出力処理では、EATメタデータに記述されるEaApplication要素で指定される情報に基づいて、ROUTEセッションで伝送される緊急情報アプリケーション（LCCコンテンツ）が取得されて、実行される。
【０２２２】
ステップＳ２５１の処理が終了されると、図１２のEAT受信処理は終了される。また、ステップＳ２５０において、緊急情報アプリケーションを含まないと判定された場合、ステップＳ２５１の処理はスキップされ、図１２のEAT受信処理は終了される。さらに、ステップＳ２４５において、緊急情報の対象地域ではないと判定された場合、ステップＳ２４６乃至Ｓ２５１の処理はスキップされ、図１２のEAT受信処理は終了される。そして、図１２のEAT受信処理が終了すると、処理は、図１１のステップＳ２２６の処理に戻り、それ以降の処理が実行される。
【０２２３】
以上、EAT受信処理の流れについて説明した。
【０２２４】
（バナーテキスト表示処理の流れ）
最後に、図１３のフローチャートを参照して、図１２のステップＳ２４７の処理に対応する、バナーテキスト表示処理の流れについて説明する。
【０２２５】
ステップＳ２６１において、MW部２１３は、ステップＳ２４２（図１２）の解析結果に基づいて、焼き込みテキストが存在するかどうかを判定する。ここでは、EATメタデータに、BurnedInMessageRegion要素が記述されているかどうかにより、焼き込みテキストが存在するかどうかの判定処理が行われる。
【０２２６】
ステップＳ２６１において、焼き込みテキストが存在する、すなわち、EATメタデータに、１以上のBurnedInMessageRegion要素が記述されていると判定された場合、処理は、ステップＳ２６２に進められる。
【０２２７】
ステップＳ２６２において、MW部２１３は、ステップＳ２４２（図１２）の解析結果に基づいて、ビデオスケーリングを行っているかどうかを判定する。ここでは、EATメタデータに記述されるMessageLayoutPolicy要素で指定されるバナーテキストの表示レイアウト情報に基づいて、例えばバナーテキストがビデオスケーリング表示されるかどうかにより、ビデオスケーリングを行っているかどうかの判定処理が行われる。
【０２２８】
ステップＳ２６２において、ビデオスケーリングを行っていると判定された場合、すなわち、EATメタデータのMessageLayoutPolicy要素で、バナーテキストの表示レイアウト情報として、ビデオスケーリング表示が指定されている場合、処理は、ステップＳ２６３に進められる。
【０２２９】
ステップＳ２６３において、コンポーネント処理部２１２は、ビデオスケーリング処理を行い、テレビ番組等のコンテンツの映像の縦横のサイズを縮小する。例えば、第３の方式Ｂが採用されている場合、バナーテキストがビデオスケーリング表示されるので、ビデオスケーリング処理が行われる。ステップＳ２６３の処理が終了すると、処理は、ステップＳ２６５に進められる。
【０２３０】
一方、ステップＳ２６２において、ビデオスケーリングを行っていないと判定された場合、すなわち、EATメタデータのMessageLayoutPolicy要素で、バナーテキストの表示レイアウト情報として、オーバーレイ表示が指定されている場合、処理は、ステップＳ２６４に進められる。
【０２３１】
ステップＳ２６４において、MW部２１３は、ステップＳ２４２（図１２）の解析結果に基づいて、焼き込みテキストの表示位置情報を取得する。ここでは、EATメタデータに記述されるBurnedInMessageRegion要素の値として、対象の焼き込みテキストの表示位置情報が指定されているので、この表示位置情報を取得することができる。例えば、第３の方式Ａが採用されている場合には、焼き込みテキストの表示位置情報が取得される。
【０２３２】
ステップＳ２６４の処理が終了すると、処理は、ステップＳ２６５に進められる。また、ステップＳ２６１において、焼き込みテキストが存在しない、すなわち、EATメタデータに、BurnedInMessageRegion要素が記述されていないと判定された場合、ステップＳ２６２乃至Ｓ２６４の処理はスキップされ、処理は、ステップＳ２６５に進められる。
【０２３３】
ステップＳ２６５において、MW部２１３は、ステップＳ２６１乃至Ｓ２６４の処理結果に基づいて、バナーテキストの表示位置を決定する。
【０２３４】
具体的には、焼き込みテキストが存在しない場合（Ｓ２６１の「NO」）、このケースは、第２の方式（第２の方式Ａ，第２の方式Ｂ）に相当し、バナーテキストが、焼き込みテキストを邪魔することはないので、バナーテキストの表示位置としては、例えば、画面の下側の領域など、任意の領域を表示位置とすることができる。
【０２３５】
また、焼き込みテキストが存在し（Ｓ２６１の「YES」）、かつ、ビデオスケーリングを行っている場合（Ｓ２６２の「YES」）、このケースは、第３の方式Ｂに相当し、バナーテキストの表示位置としては、ステップＳ２６３の処理（ビデオスケーリング処理）で生じた領域内の任意の領域を表示位置とすることができる。なお、この場合、バナーテキストは、ビデオスケーリング処理で生じた領域に表示されることから、焼き込みテキストを邪魔することはない。
【０２３６】
さらに、焼き込みテキストが存在し（Ｓ２６１の「YES」）、かつ、ビデオスケーリングを行っていない場合（Ｓ２６２の「NO」）、このケースは、第３の方式Ａに相当し、バナーテキストがテレビ番組の映像に重畳表示されるため、バナーテキストを任意の領域に表示すると、焼き込みテキストを邪魔してしまう可能性がある。この場合、ステップＳ２６４の処理が実行され、EATメタデータから、焼き込みテキストの表示位置情報が取得されているので、この表示位置情報が示す領域には、バナーテキストが表示されないようにする（バナーテキストの表示を禁止する）。
【０２３７】
具体的には、例えば、焼き込みテキストの表示位置情報として、焼き込みテキストの表示領域の座標が指定されている場合には、当該座標で指定される表示領域外の領域に、バナーテキストの表示位置が決定されるようにする。また、例えば、焼き込みテキストの表示位置情報として、画面の下側の領域（bottom）が指定されている場合には、バナーテキストの表示位置として、画面の上側の領域（upper）又は真ん中の領域（middle）が決定されるようにする。
【０２３８】
ステップＳ２６５の処理でバナーテキストの表示位置が決定されると、処理は、ステップＳ２６６に進められる。ステップＳ２６６において、出力部２０４は、ステップＳ２６５の決定結果に基づいて、バナーテキストを表示する。例えば、第３の方式Ａが採用された場合には、焼き込みテキストとバナーテキストの両者が同時に表示されることになるが、バナーテキストは、焼き込みテキストの表示位置とは異なる位置に表示されるため、バナーテキストが、焼き込みテキストを邪魔してしまうことはない。
【０２３９】
ステップＳ２６６の処理が終了すると、図１３のバナーテキスト表示処理は終了される。そして、処理は、図１２のステップＳ２４７の処理に戻り、それ以降の処理が実行される。
【０２４０】
以上、バナーテキスト表示処理の流れについて説明した。
【０２４１】
＜５．変形例＞
【０２４２】
上述した説明としては、デジタル放送の規格として、米国等で採用されている方式である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９０２や記録部９０８に、あらかじめインストールしておくことができる。
【０２５２】
ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含む。また、プログラムは、１のコンピュータ（プロセッサ）により処理されるものであってもよいし、複数のコンピュータによって分散処理されるものであってもよい。
【０２５３】
なお、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
【０２５４】
また、本技術は、以下のような構成をとることができる。
【０２５５】
（１）
デジタル放送信号を受信する受信部と、
前記デジタル放送信号で伝送されるメタデータであって、緊急に告知する必要がある情報である第１の緊急情報と、非圧縮のビデオデータに第２の緊急情報が埋め込まれているかどうかを示すとともに、前記第２の緊急情報が前記非圧縮のビデオデータに埋め込まれている場合にその画面上の表示位置を示す表示位置情報とを含む前記メタデータを取得する取得部と、
前記メタデータを処理して、前記第２の緊急情報が前記非圧縮のビデオデータに埋め込まれている場合、前記第２の緊急情報の画面上の表示位置と異なる位置に、前記第１の緊急情報を表示させる処理部と
を備える受信装置。
（２）
前記第１の緊急情報は、前記メタデータに含めて伝送されるテキスト情報であり、
前記第２の緊急情報は、前記ビデオデータに埋め込まれて伝送されるテキスト情報である
（１）に記載の受信装置。
（３）
前記第１の緊急情報は、緊急に告知する必要がある情報の見出しであるメッセージと、その詳細な内容である説明文とから構成される
（２）に記載の受信装置。
（４）
前記メッセージと、前記説明文とは、異なるレイアウトで表示される
（３）に記載の受信装置。
（５）
前記メタデータは、前記第１の緊急情報の表示レイアウトに関する表示レイアウト情報をさらに含み、
前記処理部は、前記表示レイアウト情報に基づいて、前記第１の緊急情報が、前記ビデオデータに対応する映像に重畳表示される場合にのみ、前記第１の緊急情報を、前記第２の緊急情報の画面上の表示位置と異なる位置に表示させる
（１）乃至（４）のいずれかに記載の受信装置。
（６）
前記表示位置情報は、前記第２の緊急情報が表示される画面上の座標、又は画面上の所定の領域を示す情報である
（１）乃至（５）のいずれかに記載の受信装置。
（７）
前記受信部は、IP(Internet Protocol)伝送方式のデジタル放送信号を受信する
（１）乃至（６）のいずれかに記載の受信装置。
（８）
受信装置のデータ処理方法において、
前記受信装置が、
デジタル放送信号を受信し、
前記デジタル放送信号で伝送されるメタデータであって、緊急に告知する必要がある情報である第１の緊急情報と、非圧縮のビデオデータに第２の緊急情報が埋め込まれているかどうかを示すとともに、前記第２の緊急情報が前記非圧縮のビデオデータに埋め込まれている場合にその画面上の表示位置を示す表示位置情報とを含む前記メタデータを取得し、
前記メタデータを処理して、前記第２の緊急情報が前記非圧縮のビデオデータに埋め込まれている場合、前記第２の緊急情報の画面上の表示位置と異なる位置に、前記第１の緊急情報を表示させる
ステップを含むデータ処理方法。
（９）
緊急に告知する必要がある情報である第１の緊急情報と、非圧縮のビデオデータに第２の緊急情報が埋め込まれているかどうかを示すとともに、前記第２の緊急情報が前記非圧縮のビデオデータに埋め込まれている場合に受信装置の画面上の表示位置を示す表示位置情報とを含むメタデータを生成する生成部と、
前記メタデータを、デジタル放送信号として送信する送信部と
を備える送信装置。
（１０）
前記第１の緊急情報は、前記メタデータに含めて伝送されるテキスト情報であり、
前記第２の緊急情報は、前記ビデオデータに埋め込まれて伝送されるテキスト情報である
（９）に記載の送信装置。
（１１）
前記第１の緊急情報は、緊急に告知する必要がある情報の見出しであるメッセージと、その詳細な内容である説明文とから構成される
（１０）に記載の送信装置。
（１２）
前記メッセージと、前記説明文とは、異なるレイアウトで表示される
（１１）に記載の送信装置。
（１３）
前記メタデータは、前記第１の緊急情報の表示レイアウトに関する表示レイアウト情報をさらに含む
（９）乃至（１２）のいずれかに記載の送信装置。
（１４）
前記表示位置情報は、前記第２の緊急情報が表示される画面上の座標、又は画面上の所定の領域を示す情報である
（９）乃至（１３）のいずれかに記載の送信装置。
（１５）
前記送信部は、前記メタデータを、IP伝送方式のデジタル放送信号として送信する
（９）乃至（１４）のいずれかに記載の送信装置。
（１６）
送信装置のデータ処理方法において、
前記送信装置が、
緊急に告知する必要がある情報である第１の緊急情報と、非圧縮のビデオデータに第２の緊急情報が埋め込まれているかどうかを示すとともに、前記第２の緊急情報が前記非圧縮のビデオデータに埋め込まれている場合に受信装置の画面上の表示位置を示す表示位置情報とを含むメタデータを生成し、
前記メタデータを、デジタル放送信号として送信する
ステップを含むデータ処理方法。
【符号の説明】
【０２５６】
１  伝送システム，  １０−１，１０−２，１０  送信装置，  ２０，２０−１，２０−２，２０−３  受信装置，  ３０  電波塔，  ４０  EAサーバ，  ８０  伝送路，  ９０  通信回線，  １０１  EAパーサ，  １０２  ライブコンテンツ取得部，  １０３  ストレージ，  １０４  コンポーネント処理部，  １０５  シグナリング処理部，  １０６  LCC処理部，  １０７  エンコーダ，  １０８  マルチプレクサ，  １０９  変調部，  １１０  RF部，  ２０１  RF部，  ２０２  復調部，  ２０３  処理部，  ２０４  出力部，  ２０５  通信I/F，  ２１１  FW/HW部，  ２１２  コンポーネント処理部，  ２１３  MW部，  ２１４  ブラウザ，  ２２１  デマルチプレクサ，  ２２２  デコーダ，  ２３１  パーサ，  ２３２  フィルタ，  ９００  コンピュータ，  ９０１  CPU
【図１】
2017038482.tif 000003
【図２】
2017038482.tif 000004
【図３】
2017038482.tif 000005
【図４】
2017038482.tif 000006
【図５】
2017038482.tif 000007
【図６】
2017038482.tif 000008
【図７】
2017038482.tif 000009
【図８】
2017038482.tif 000010
【図９】
2017038482.tif 000011
【図１０】
2017038482.tif 000012
【図１１】
2017038482.tif 000013
【図１２】
2017038482.tif 000014
【図１３】
2017038482.tif 000015
【図１４】
2017038482.tif 000016
【国際調査報告】
2017038482.tif 000017
2017038482.tif 000018
2017038482.tif 000019
2017038482.tif 000020