JP7264872B2 - 受信装置、受信方法、信号処理装置、及び信号処理方法 - Google Patents

受信装置、受信方法、信号処理装置、及び信号処理方法 Download PDF

Info

Publication number
JP7264872B2
JP7264872B2 JP2020508190A JP2020508190A JP7264872B2 JP 7264872 B2 JP7264872 B2 JP 7264872B2 JP 2020508190 A JP2020508190 A JP 2020508190A JP 2020508190 A JP2020508190 A JP 2020508190A JP 7264872 B2 JP7264872 B2 JP 7264872B2
Authority
JP
Japan
Prior art keywords
information
emergency alert
alert information
emergency
signaling
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2020508190A
Other languages
English (en)
Other versions
JPWO2019181552A1 (ja
Inventor
淳 北原
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Sony Group Corp
Original Assignee
Sony Corp
Sony Group Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Corp, Sony Group Corp filed Critical Sony Corp
Publication of JPWO2019181552A1 publication Critical patent/JPWO2019181552A1/ja
Application granted granted Critical
Publication of JP7264872B2 publication Critical patent/JP7264872B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/53—Arrangements specially adapted for specific applications, e.g. for traffic information or for mobile receivers
    • H04H20/59—Arrangements specially adapted for specific applications, e.g. for traffic information or for mobile receivers for emergency or urgency
    • G—PHYSICS
    • G08—SIGNALLING
    • G08B—SIGNALLING OR CALLING SYSTEMS; ORDER TELEGRAPHS; ALARM SYSTEMS
    • G08B21/00—Alarms responsive to a single specified undesired or abnormal condition and not otherwise provided for
    • G—PHYSICS
    • G08—SIGNALLING
    • G08B—SIGNALLING OR CALLING SYSTEMS; ORDER TELEGRAPHS; ALARM SYSTEMS
    • G08B27/00—Alarm systems in which the alarm condition is signalled from a central station to a plurality of substations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B1/00—Details of transmission systems, not covered by a single one of groups H04B3/00 - H04B13/00; Details of transmission systems not characterised by the medium used for transmission
    • H04B1/06—Receivers
    • H04B1/16—Circuits
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/44—Arrangements characterised by circuits or components specially adapted for broadcast
    • H04H20/46—Arrangements characterised by circuits or components specially adapted for broadcast specially adapted for broadcast systems covered by groups H04H20/53-H04H20/95
    • H04H20/47—Arrangements characterised by circuits or components specially adapted for broadcast specially adapted for broadcast systems covered by groups H04H20/53-H04H20/95 specially adapted for stereophonic broadcast systems
    • H04H20/48—Arrangements characterised by circuits or components specially adapted for broadcast specially adapted for broadcast systems covered by groups H04H20/53-H04H20/95 specially adapted for stereophonic broadcast systems for FM stereophonic broadcast systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23614—Multiplexing of additional data and video streams
    • H04N21/23617—Multiplexing of additional data and video streams by inserting additional data into a data carousel, e.g. inserting software modules into a DVB carousel
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/2362—Generation or processing of Service Information [SI]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/433—Content storage operation, e.g. storage operation in response to a pause request, caching operations
    • H04N21/4334—Recording operations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4348—Demultiplexing of additional data and video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/443—OS processes, e.g. booting an STB, implementing a Java virtual machine in an STB or power management in an STB
    • H04N21/4432—Powering on the client, e.g. bootstrap loading using setup parameters being stored locally or received from the server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/488—Data services, e.g. news ticker
    • H04N21/4882—Data services, e.g. news ticker for displaying messages, e.g. warnings, reminders
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/8126—Monomedia components thereof involving additional data, e.g. news, sports, stocks, weather forecasts
    • H04N21/814—Monomedia components thereof involving additional data, e.g. news, sports, stocks, weather forecasts comprising emergency warnings

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • Emergency Management (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Circuits Of Receivers In General (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Alarm Systems (AREA)

Description

本技術は、受信装置、受信方法、信号処理装置、及び信号処理方法に関し、特に、より適切に緊急警報情報を提示することができるようにした受信装置、受信方法、信号処理装置、及び信号処理方法に関する。
放送方式の中には、緊急時に緊急警報情報を提示するための緊急警報サービスについて規定しているものがある（例えば特許文献１参照）。特許文献１には、緊急警報サービスとして、物理層フレームに含まれるウェイクアップフラグに基づき、緊急時に、待機状態（スタンバイ状態）の受信機（例えばテレビ受像機）を強制的に起動することが開示されている。
国際公開第2017/047397号
ところで、緊急時に、スタンバイ状態の受信機を強制的に起動して緊急警報情報を提示する機能は、より多くの受信機が緊急警報情報を提示することができる反面、ユーザが意図しないタイミングで受信機を起動することが可能となり、その運用の仕方によっては、ユーザの利便性を損ねる可能性がある。そのため、より適切に緊急警報情報を提示するための提案が要請されていた。
本技術はこのような状況に鑑みてなされたものであり、より適切に緊急警報情報を提示することができるようにするものである。
本技術の第１の側面の受信装置は、放送信号を受信する受信部と、受信された前記放送信号を処理する処理部とを備え、前記処理部は、スタンバイ状態であるとき、受信された前記放送信号に含まれる緊急警報起動情報に基づいて起動状態となり、前記起動状態となったとき、受信された前記放送信号から得られるシグナリング、及び緊急警報情報の受信設定に関する受信設定情報に基づいて、前記緊急警報情報の提示を制御し、前記シグナリングは、前記緊急警報情報を識別するID、及び前記緊急警報情報が、新規、更新、又はキャンセルされたことを示す情報を含む受信装置である。
本技術の第１の側面の受信装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第１の側面の受信方法は、上述した本技術の第１の側面の受信装置に対応する受信方法である。
本技術の第１の側面の受信装置、及び受信方法においては、処理部が、スタンバイ状態であるとき、受信された放送信号に含まれる緊急警報起動情報に基づいて起動状態となり、起動状態となったとき、受信された放送信号から得られるシグナリング、及び緊急警報情報の受信設定に関する受信設定情報に基づいて、緊急警報情報の提示が制御される。また、シグナリングには、緊急警報情報を識別するID、及び緊急警報情報が、新規、更新、又はキャンセルされたことを示す情報が含まれる。
本技術の第２の側面の信号処理装置は、スタンバイ状態であるとき、受信された放送信号に含まれる緊急警報起動情報に基づいて起動状態となり、前記起動状態となったとき、受信された前記放送信号から得られるシグナリング、及び緊急警報情報の受信設定に関する受信設定情報に基づいて、前記緊急警報情報の提示を制御する制御部を備え、前記シグナリングは、前記緊急警報情報を識別するID、及び前記緊急警報情報が、新規、更新、又はキャンセルされたことを示す情報を含む信号処理装置である。
本技術の第２の側面の信号処理装置は、独立した装置であってもよいし、１つの装置を構成している内部ブロックであってもよい。また、本技術の第２の側面の信号処理方法は、上述した本技術の第２の側面の信号処理装置に対応する信号処理方法である。
本技術の第２の側面の信号処理装置、及び信号処理方法においては、スタンバイ状態であるとき、受信された放送信号に含まれる緊急警報起動情報に基づいて起動状態となり、起動状態となったとき、受信された放送信号から得られるシグナリング、及び緊急警報情報の受信設定に関する受信設定情報に基づいて、緊急警報情報の提示が制御される。また、シグナリングは、緊急警報情報を識別するID、及び緊急警報情報が、新規、更新、又はキャンセルされたことを示す情報が含まれる。
本技術の第１の側面、及び第２の側面によれば、より適切に緊急警報情報を提示することができる。
なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。
本技術を適用した伝送システムの一実施の形態の構成を示す図である。 EA Wake upのビットの構成の例を示す図である。 EA Wake upのビットの値の意味を示す図である。 想定運用の第１の例を示す図である。 想定運用の第２の例を示す図である。 想定運用の第３の例を示す図である。 想定運用の第３の例を示す図である。 想定運用の第４の例を示す図である。 ブートストラップの構成の例を示す図である。 Bootstrap Symbol 1のシンタックスの例を示す図である。 Bootstrap Symbol 2のシンタックスの例を示す図である。 IP伝送方式のプロトコルスタックの例を示す図である。 LLSテーブルのシンタックスの例を示す図である。 AEATメタデータのシンタックスの例を示す図である。 AEATメタデータのシンタックスの例を示す図である。 本技術を適用した受信装置の構成の例を示す図である。 本技術を適用した放送信号処理部（SoC）の詳細な構成の例を示す図である。 放送チューナ部の処理の流れを説明するフローチャートである。 放送信号処理部（SoC）の処理の流れを説明するフローチャートである。 放送信号処理部（SoC）の処理の流れを説明するフローチャートである。 受信システムの起動判定処理の詳細の流れを説明するフローチャートである。 受信システムの起動判定処理の比較項目の例を示す図である。 緊急警報情報の識別方法の例を示す図である。 緊急警報情報の受信設定処理の流れを説明するフローチャートである。 緊急警報情報の受信設定画面の例を示す図である。 コンピュータの構成例を示す図である。
以下、図面を参照しながら本技術の実施の形態について説明する。なお、説明は以下の順序で行うものとする。
１．本技術の実施の形態
２．変形例
３．コンピュータの構成
＜１．本技術の実施の形態＞
（伝送システムの構成例）
図１は、本技術を適用した伝送システムの一実施の形態の構成を示す図である。なお、システムとは、複数の装置が論理的に集合したものをいう。
伝送システム１において、各放送局は、送信装置１０（例えば、送信装置１０－１や送信装置１０－２）を設置している。送信装置１０は、放送番組やCM等のコンテンツを含む放送ストリームを、デジタル放送信号として送信する。
送信装置１０からのデジタル放送信号は、電波塔３０等を経由して、伝送路８０を介して受信装置２０により受信される。受信装置２０は、例えば、テレビ受像機、セットトップボックス（STB：Set Top Box）、又は録画機等の固定受信機（例えば、受信装置２０－１）や、例えば、携帯電話機、スマートフォン、タブレット端末等のモバイル受信機（例えば、受信装置２０－２や受信装置２０－３）である。受信装置２０は、デジタル放送信号から得られる放送ストリームを処理し、放送番組やCM等のコンテンツの映像や音声を再生する。
また、図１において、伝送システム１は、緊急告知のシステムに対応する構成を含んでおり、緊急時には、各放送局などが、受信装置２０に対して、緊急に告知する必要がある情報である緊急警報情報を提供（通知）することになる。
具体的には、伝送システム１では、緊急時に、緊急情報源５０から通知される緊急情報源情報（例えば災害時に発行される緊急警報など）が、CAP情報等の所定のフォーマットに変換され、各放送局（の送信装置１０）に提供される。なお、CAP情報は、構造化情報標準促進協会（OASIS：Organization for the Advancement of Structured Information Standards）で規定されているCAP(Common Alerting Protocol)に準拠したものとなる。
放送局（の送信装置１０）は、例えば、緊急情報源５０からの緊急情報源情報に応じたCAP情報を、放送番組の映像（非圧縮の映像データ）に埋め込んでエンコードしたり、あるいは、所定のフォーマットに変換したりすることで、緊急警報情報を生成する。そして、放送局（の送信装置１０）は、生成された緊急警報情報を、放送エリア内の多数の受信装置２０（例えば、受信装置２０－１乃至２０－３等）に対して送信する。
これにより、受信装置２０では、放送番組の映像に、緊急警報情報が重畳して提示されることになる。その結果、ユーザは、受信装置２０の画面に提示された緊急警報情報（例えばテキスト情報）を確認することができる。
また、放送局（の送信装置１０）は、緊急情報源５０からの緊急情報源情報に応じたCAP情報に基づいて、緊急情報アプリケーション（例えば、緊急警報に関するより詳細な情報）を生成し、EAサーバ４０に提供することができる。
受信装置２０は、通信機能を有している場合、インターネットや携帯電話網等の通信回線９０を介してEAサーバ４０にアクセスし、緊急情報アプリケーションを要求することができる。そして、受信装置２０は、通信回線９０を介してEAサーバ４０から配信される緊急情報アプリケーションを受信して実行することができる。これにより、受信装置２０の画面には、例えば、緊急警報情報に関するより詳細な情報が提示されることになる。
なお、放送局（の送信装置１０）において、緊急警報情報の生成方法としては、上述した方法に限らず、例えば、CAP情報をそのままの形式で用いるなど、他の生成方法を用いるようにしてもよい。また、緊急警報情報を生成するための情報としてのCAP情報は一例であって、緊急情報源情報を他の方式に準拠した形式に変換して得られる情報などを用いて、緊急警報情報が生成されるようにしてもよい。
また、例えば、図１の伝送システム１において、送信装置１０と受信装置２０とでは、伝送路８０を介して、米国の次世代放送規格であるATSC(Advanced Television Systems Committee)3.0に準拠したデータ伝送が行われるようにすることができる。
ここで、米国では、EAS(Emergency Alerting System)と称される緊急告知のシステムが構築されており、緊急時に、緊急情報源５０としての米国連邦緊急事態管理庁（FEMA：Federal Emergency Management Agency）や大統領官邸等から通知される緊急情報源情報（例えば災害時に発行される緊急警報など）が、CAP情報に変換され、各放送局に提供される。
すなわち、米国では、EASと称される緊急告知のシステムが整備されているので、このEASを利用して、大統領からの最優先事項からローカルな告知事項まで、様々なレベルの緊急情報（CAP情報）が、様々なメディア（例えば放送経由や通信経由など）により告知（通知）されることになる。
ところで、ATSC3.0等の放送方式の中には、緊急警報情報の配信に加えて、待機状態（スタンバイ状態）の受信装置２０を強制的に起動して緊急警報情報を提示する機能を規定しているものがある。
例えば、ATSC3.0では、物理層フレームのブートストラップにより、EAウェイクアップ情報（Emergency Alert Wakeup）を伝送する。このEAウェイクアップ情報は、図２に示すように、ea_wake_up_1, ea_wake_up_2の2ビットで構成され、ATSC3.0では、受信装置２０がEAウェイクアップ情報を受信したときの動作を規定している。
すなわち、ea_wake_up_1の1ビットを、最下位ビット（LSB：Least Significant Bit）とし、ea_wake_up_2の1ビットを、最上位ビット（MSB：Most Significant Bit）として、EAウェイクアップ情報を、2ビットとすることで、図３に示すように、"00", "01"， "10"， "11"の４通りの意味を持たせている。
具体的には、図３に示すように、EA Wakeup = "00"の場合には、緊急警報情報の伝送がないことを意味する。また、EA Wakeup = "01"，"10"，"11"の場合には、緊急警報情報の伝送があることを意味する。すなわち、EA Wakeup = "00"は、緊急警報情報が非アクティブであることを示し、EA Wakeup = "01"，"10"，"11"は、緊急警報情報がアクティブであることを示すが、アクティブ（"01"，"10"，"11"）の設定（設定１，２，３）をどのように使用するかは、放送事業者の運用等に応じて決定することになる。
ここでは、送信装置１０が、アクティブを示す"01", "10", "11"の３つの状態を変化させることで、緊急警報情報を変更（更新）したことを、受信装置２０に通知することができる。これにより、受信装置２０では、スタンバイ状態から強制的に起動することで、ユーザに対して早期に緊急警報情報を提供することができる。
例えば、受信装置２０の構成としては、放送チューナ部と放送信号処理部（例えば、後述する図１６の放送チューナ部２０１と放送信号処理部２０２）を含んで構成される。放送信号処理部は、放送チューナ部から出力されるパケットを処理して、映像や音声、放送アプリケーションなどをレンダリングする機能を有し、例えば、システムオンチップ（SoC：System on Chip）として構成される。
このような構成の場合において、EAウェイクアップ情報は、物理層フレームのブートストラップにより伝送されることから、放送チューナ部により取得されることが想定される。すなわち、受信装置２０においては、放送チューナ部がEAウェイクアップ情報に基づき、後段の放送信号処理部（SoC）を、スタンバイ状態から起動状態にするための指示を出すことで、放送信号処理部（SoC）が、緊急警報情報に関する処理を行うことが想定される。つまり、EAウェイクアップ情報は、緊急警報起動情報であるとも言える。
これにより、受信装置２０では、スタンバイモード時に、放送信号処理部（SoC）の電源をオフにして、消費電力を抑えつつ、緊急警報情報が発せられた場合には、放送信号処理部（SoC）を起動して、当該緊急警報情報を提示することができる。よって、迅速かつ多くの世帯に、緊急警報情報を届けることが可能となる。
また、受信装置２０では、EAウェイクアップ情報が、非アクティブ（"00"）から、アクティブ（"01", "10", "11"）に変わることで、放送信号処理部（SoC）が起動して緊急警報情報を提示するため、ユーザが放送サービスを視聴していない場合（受信装置２０がスタンバイモードである場合）に、緊急警報情報が放送経由で通知されたとき、自動的に電源が入って、迅速に緊急警報情報に気づくことができる。
このような、緊急時に、スタンバイ状態の受信装置２０を強制的に起動して緊急警報情報を提示する機能は、より多くの受信装置２０が緊急警報情報を提示することができる反面、ユーザが意図しないタイミングで受信装置２０を起動する（受信装置２０の電源を入れる）ことが可能となり、その運用の仕方によっては、ユーザの利便性を損ねる可能性があるのは、先に述べた通りである。
そこで、次に、図４乃至図８を参照して、以下、現状で想定される運用（以下、想定運用という）における問題点とその解決手段の概要について説明する。
（想定運用の第１の例）
図４は、想定運用の第１の例を示す図である。
図４においては、物理層フレームに含まれるEAウェイクアップ情報（EA Wakeup）の値（"00"，"01"，"10"，"11"）の変化を、図中の横方向の時系列で表している。また、図４では、EAウェイクアップ情報の値の変化に応じて、スタンバイモードで動作している受信装置２０が、強制的に起動（自動起動）して緊急警報情報を提示する様子を模式的に示している。
時刻t11乃至時刻t12においては、EA Wakeup = "00"となるので、受信装置２０は、スタンバイモードを継続し、その画面には何も表示されていない状態となる（画面D11）。その後、時刻t12において、EA Wakeupの値が"00"から"01"に変化して、新規の緊急警報が配信されたとき、スタンバイモードの受信装置２０では、強制的に起動されて（電源が入って）、受信した緊急警報情報A1が表示される（画面D12）。
例えば、この緊急警報情報A1は、ハリケーンが接近しているとの情報であり、ユーザ２は、緊急警報情報A1を確認した後に、リモートコントローラ２１を操作（電源オフ操作）して、受信装置２０を、再度スタンバイモードにする（画面D13）。
その後、時刻t13において、EA Wakeupの値が"10"に変化して、更新された緊急警報が配信されたとき、スタンバイモードの受信装置２０では、再度、強制的に起動されて、受信した緊急警報情報A2が表示される（画面D14）。
例えば、この緊急警報情報A2は、先ほどのハリケーンが通過したとの情報であり、ユーザ２は、緊急警報情報A2を確認した後に、電源オフ操作を行って、受信装置２０を、再度スタンバイモードにする（画面D15）。このとき、緊急警報情報A1と緊急警報情報A2とは、共にハリケーンに関する情報であって、ユーザ２からすれば、先ほど見た緊急警報が繰り返して表示されているため、緊急警報情報A2を表示しないでほしいと感じる可能性がある。
その後、時刻t14において、EA Wakeupの値が"11"に変化して、更新された緊急警報が配信されたとき、スタンバイモードの受信装置２０では、再度、強制的に起動されて、受信した緊急警報情報A3が表示される（画面D16）。
例えば、この緊急警報情報A3は、先ほどのハリケーンが低気圧になり、警報が解除されたとの情報であり、ユーザ２は、緊急警報情報A3を確認した後に、電源オフ操作を行って、受信装置２０を、再度スタンバイモードにする（画面D17）。このとき、緊急警報情報A3は、緊急警報情報A1と緊急警報情報A2と同様に、ハリケーンに関する情報であって、ユーザ２からすれば、緊急警報の解除通知ならば、受信装置２０の電源をオンにしないでほしいと感じる可能性がある。
以上のように、想定運用の第１の例では、緊急警報情報A1，A2，A3のように更新される度に、EA Wakeupの値も、"01"，"10"，"11"のように更新され、スタンバイモードの受信装置２０が強制的に起動されるため、ユーザの意図に関わらず、アクティブ状態を示すEA Wakeup（"01"，"10"，"11"）が受信されると自動起動することになる。そして、このようなEA Wakeupの更新時に常に自動起動する（電源が自動的に入る）という受信装置２０の動作は、ユーザによっては不便に感じてしまう。
特に、図４に示したような、ある緊急警報情報をユーザが確認して電源をオフしたにも関わらず、同じ緊急警報情報が更新される度に何度も自動起動（電源がオン）されるような状態は、ユーザの利便性を損ねる可能性がある。
このような想定運用の第１の例に対して、例えば、新しい緊急警報情報が発令された時のみ、受信装置２０の電源が入ってそれを提示してほしいことや、緊急警報情報が発令された時と更新された時のみ、受信装置２０の電源が入ってそれを提示してほしいこと（緊急警報情報の解除は通知不要）、さらには、ユーザインターフェースで緊急警報情報のアップデートを提示するかどうかを選択したいこと、といった要請がある。
このような要請に対し、本技術を適用した受信装置２０では、ユーザにより設定された緊急警報情報の受信設定に関する情報（以下、受信設定情報という）に基づき、そのタイプ（例えば新規、更新、又は解除など）に応じて緊急警報情報の提示を制御することで、ユーザが意図しない状況で自動起動してしまうことを防止することができるようにする。また、このような制御が行われることで、緊急警報情報の発信者側からしても、ユーザの利便性を損なうことなく、自身が意図する情報を伝えることが可能となる。
なお、図４は、EA Wakeupの値に変更があったときに、その変更に受信装置２０が反応して起動する例を示したが、EAウェイクアップ情報は、周期的に伝送されているため、実装によっては、例えば、次のような運用も想定される。すなわち、EAウェイクアップ情報として、EA Wakeup = "01"が受信され、受信装置２０が自動起動した後にユーザ２が電源をオフした場合、その後に、カルーセル伝送されているEAウェイクアップ情報が、EA Wakeup = "01"となったとき、それを受信した受信装置２０が再度自動起動するような場面も想定される。
（想定運用の第２の例）
図５は、想定運用の第２の例を示す図である。
図５においては、図４と同様に、スタンバイモードで動作している受信装置２０が、EAウェイクアップ情報の値の変化に応じて、強制的に起動して緊急警報情報を提示する様子を例示している。
時刻t21乃至時刻t22においては、EA Wakeup = "00"となるので、受信装置２０は、スタンバイモードを継続し、その画面には何も表示されていない状態となる（画面D21）。その後、時刻t22において、EA Wakeupの値が"00"から"01"に変化して、新規の緊急警報が配信されたとき、スタンバイモードの受信装置２０では、強制的に起動されて（電源が入って）、受信した緊急警報情報B1が表示される（画面D22）。
例えば、この緊急警報情報B1は、ハリケーンに関する情報であるが、ユーザ２の自宅の地域は、ハリケーンの進路には入ってないので、ユーザ２は、緊急警報情報B1を確認した後に、リモートコントローラ２１を操作して、受信装置２０を、再度スタンバイモードにする（画面D23）。
このとき、ユーザ２の自宅の地域がハリケーンの進路に入っていないにも関わらず、緊急警報が広域に出されているために、進路外の地域に設置された受信装置２０でも、緊急警報情報B1が表示されているが、ユーザ２からすれば、自分には関係のない緊急警報情報B1を表示しないでほしいと感じる可能性がある。
その後、時刻t23において、EA Wakeupの値が"10"に変化して、更新された緊急警報が配信されたとき、スタンバイモードの受信装置２０では、再度、強制的に起動されて、受信した緊急警報情報B2が表示される（画面D24）。
例えば、緊急警報情報B2は、その後のハリケーンに関する情報であるが、ユーザ２からすれば、自分には関係のない情報であるならば、何度も、受信装置２０の電源をオンにしないでほしいと感じる可能性がある。
以上のように、想定運用の第２の例では、ユーザの意図に関わらず、アクティブ状態を示すEA Wakeup（"01"，"10"，"11"）が受信されると、受信装置２０が強制的に起動されることになる。そして、緊急警報情報として、例えば、ユーザとは関連性が薄い情報や、ユーザの興味のない情報であっても、EA Wakeupの更新時に常に自動起動する受信装置２０の動作は、ユーザの利便性が損なわれると考えられる。また、受信装置２０においては、ある緊急警報情報をユーザが確認して電源をオフしたにも関わらず、緊急警報情報が更新される間は、スタンバイ状態から起動状態になる動作が繰り返し起きてしまう。
このような要請に対し、本技術を適用した受信装置２０では、受信設定情報に基づき、受信機のタイプや、緊急警報情報の優先度や該当地域、イベント種別などに応じて、緊急警報情報の提示を制御することで、ユーザが意図しない状況で自動起動してしまうことを防止することができるようにする。
（想定運用の第３の例）
図６及び図７は、想定運用の第３の例を示す図である。
図６及び図７においては、図４等と同様に、スタンバイモードで動作している受信装置２０の動作の様子を例示している。
ここで、スタンバイモードの受信装置２０において、待機中のシステムオンチップ（SoC）は、次の２通りの動作を行うことが想定される。すなわち、第１の動作としては、ユーザによるリモートコントローラ操作や視聴予約のタイマ設定などによって、待機中のシステムオンチップ（SoC）が起動され（電源がオンされ）、放送サービスに関する処理を行う動作が想定される。また、第２の動作としては、EA Wakeupの更新時に、待機中のシステムオンチップ（SoC）が起動され（電源がオンされ）、緊急警報に関する処理を行う動作が想定される。
前者の動作の場合には、放送サービスを受信するため、受信装置２０では、前回電源をオフしたときに受信していたチャンネル（いわゆるラストチャンネル）への選局と、その選局されたチャンネルの放送番組を提示するための処理が必要となる。
具体的には、図６に示すように、時刻t31において、ユーザ２が、リモートコントローラ２１を操作（電源オン操作）して、スタンバイモードの受信装置２０の電源をオンした場合、その画面には、ラストチャンネルの通常番組が表示される（画面D32）。
一方で、後者の動作の場合には、受信装置２０では、緊急警報情報を提示するに際して、緊急警報サービスが存在する場合には、緊急警報サービスの選局とその選局された緊急警報番組を提示するための処理が必要となり、緊急警報サービスが存在しない場合には、放送サービスの選局とその選局された放送番組を提示するための処理が必要となる。
具体的には、図７に示すように、時刻t41乃至時刻t42においては、EA Wakeup = "00"となるので、受信装置２０は、スタンバイモードを継続し、その画面には何も表示されていない状態となる（画面D41）。その後、時刻t42において、EA Wakeupの値が、"00"から"01"に変化して、新規の緊急警報が配信されたとき、スタンバイモードの受信装置２０では、強制的に電源が入って、緊急警報情報を含むメタデータ（例えばAEATメタデータ）に、緊急警報サービスに関する情報が含まれるかどうかが確認される（時刻t43）。なお、AEATメタデータの詳細は、図１４及び図１５等を参照して後述する。
そして、受信装置２０では、緊急警報サービスが存在する場合、時刻t44乃至時刻t45に、当該緊急警報サービスのチャンネルが選局され、その画面には、緊急警報情報C1に対応した緊急警報番組が表示される（画面D42）。一方で、受信装置２０では、緊急警報サービスが存在しない場合、時刻t44乃至時刻t45に、放送サービスのチャンネル（ラストチャンネル）が選局され、その画面には、緊急警報情報C1とともに通常番組が表示される（画面D43）。
以上のように、想定運用の第３の例では、ユーザ２によりリモートコントローラ２１の操作（電源オン操作）や視聴予約のタイマ設定が行われた場合と、EAウェイクアップ情報の値が変化した場合とでは、スタンバイモードの受信装置２０が電源をオンした後に期待される動作が異なる。つまり、受信装置２０においては、スタンバイモード時の起動要因によって、期待される起動後の動作が異なっているので、そのような期待動作の違いに対応したいという要請がある。
このような要請に対し、本技術を適用した受信装置２０では、通常起動モードと緊急警報優先モードとを区別して動作することで、スタンバイモード時の起動要因に応じて期待される起動後の動作が行われるようにする。
なお、ここでは、図６に示したような、ユーザ２のリモートコントローラ２１の操作や、視聴予約のタイマ設定などによって、スタンバイモードで動作する受信装置２０（の放送信号処理部（SoC））を起動して（電源をオンして）、放送サービスを受信する動作を、通常起動モードと規定する。
一方で、図７に示したような、物理層フレームのブートストラップから抽出されたEAウェイクアップ情報によって、スタンバイモードで動作する受信装置２０（の放送信号処理部（SoC））を起動して（電源をオンして）、緊急警報情報を受信する動作を、緊急警報優先モードと規定する。
このようなモードを規定することで、本技術を適用した受信装置２０では、スタンバイモード時に、ユーザ２のリモートコントローラ２１の操作などにより起動された場合には、通常起動モードにより動作して放送サービスを受信し、EAウェイクアップ情報によって起動された場合には、緊急警報優先モードにより動作して緊急警報情報を受信することができるようにする。
また、本技術を適用した受信装置２０は、緊急警報優先モードで動作する場合には、ユーザにより設定された受信設定情報のほか、過去に受信した緊急警報情報に関する情報（以下、履歴情報という）に基づき、緊急警報情報の提示を制御することができるようにする。
（想定運用の第４の例）
図８は、想定運用の第４の例を示す図である。
図８においては、図４等と同様に、スタンバイモードで動作している受信装置２０が、EAウェイクアップ情報の値の変化に応じて、強制的に起動して緊急警報情報を提示する様子を例示している。
ここで、想定運用の第４の例では、受信装置２０の事前設定として、新規の緊急警報情報を受信したときのみ電源をオンする設定がなされ、受信設定情報として記録されている（画面D51）。なお、受信設定情報の事前設定の詳細は、図２４及び図２５等を参照して後述する。
時刻t51乃至時刻t52においては、EA Wakeup = "00"となるので、受信装置２０は、スタンバイモードを継続し、その画面には何も表示されていない状態となる（画面D52）。その後、時刻t52において、EA Wakeupの値が、"00"から"01"に変化して、新規の緊急警報（緊急警報情報D1）が配信されたとき、スタンバイモードの受信装置２０では、緊急警報情報D1を含むメタデータ（例えばAEATメタデータ）を受信して、緊急警報サービスの有無が確認される。
そして、受信装置２０では、緊急警報サービスが存在する場合、時刻t53乃至時刻t54に、当該緊急警報サービスのチャンネルが選局され、その画面には、緊急警報情報D1に対応した緊急警報番組が表示される（画面D53）。ユーザ２は、緊急警報番組を確認した後に、リモートコントローラ２１を操作して、受信装置２０を、再度スタンバイモードにする（画面D54）。
その後、時刻t55において、EA Wakeupの値が"10"に変化したとき、スタンバイモードの受信装置２０では、受信したメタデータ（例えばAEATメタデータ）に含まれる緊急警報情報のタイプに基づき、次の２通りの動作を行うことが想定される。
すなわち、第１に、受信した緊急警報情報が、緊急警報情報D1の更新であると判断し、事前設定に基づき、スタンバイモードの受信装置２０を起動せずにスタンバイモードを維持する動作と、第２に、受信した緊急警報情報が、新規の緊急警報情報D2であると判断し、スタンバイモードの受信装置２０を起動して緊急警報番組等を表示する動作である。
具体的には、図８に示すように、前者の動作の場合には、受信装置２０は、スタンバイモードを継続し、その画面には何も表示されていない状態となる（画面D55）。一方で、後者の場合には、受信装置２０では、新規の緊急警報情報D2を受信して、緊急警報サービスが存在する場合には、当該緊急警報サービスのチャンネルが選局され、その画面には、緊急警報番組が表示される（画面D56）。
以上のように、想定運用の第４の例では、EA Wakeupの値として、非アクティブ状態を示す"00"と、アクティブ状態を示す"01"，"10"，"11"が規定され、緊急警報情報の更新があった場合には、"01"から"10"に変化し、さらに"10"から"11"に変化することで（"11"から"01"にループすることも想定）、システムオンチップに対し、更新を通知することになる。
この場合に、１つの緊急警報情報であれば、新規の緊急警報情報とその緊急警報情報に更新があることを、システムオンチップに通知することができるが、複数の緊急警報情報が同時に発生した場合には、どの緊急警報情報についての新規や更新なのかを、システムオンチップに通知することができないため、システムオンチップ側で、緊急警報情報を識別して起動するかどうかを判断することが要請されている。
このような要請に対し、本技術を適用した受信装置２０では、緊急警報情報を含むメタデータ（例えばAEATメタデータ）に含まれる識別情報（aeaId, refAEAId）に基づき、緊急警報情報の系列を同定し、同系列の緊急警報情報については、その緊急警報情報に含まれる新規、更新、又は解除を示すタイプ情報（aeaType）と、受信設定情報に基づき、自動起動するか、あるいはスタンバイモードを維持するかを判定できるようにする。なお、AEATメタデータの詳細は、図１４及び図１５等を参照して後述する。
これにより、例えば、緊急警報情報の内容に応じて受信装置２０を自動起動する機能を有効にするか否か、一度確認した緊急警報情報が更新された時に確認するか否か、緊急警報情報が解除された時に自動起動するか否かなどの受信装置２０の動作を、ユーザの選択に基づき決定することができる。
以上、想定運用における問題点とその解決手段の概要について説明したが、次に、図９乃至図２５を参照してより詳細な内容について説明する。
（物理層フレームの構成）
本技術を適用した物理層フレームとしては、例えば、ブートストラップ（Bootstrap）と、プリアンブル（Preamble）と、１以上のサブフレーム（Subframe）から構成されるようにすることができる。
物理層フレームは、ミリ秒単位などの所定のフレーム長で構成される。受信装置２０においては、物理層フレームを処理する際に、ブートストラップとプリアンブルを取得した後に、その後のサブフレームを取得することが可能となる。
図９は、ブートストラップの構成の例を示している。図９において、横方向は、時間を表し、縦方向は、周波数を表している。
図９において、ブートストラップは、Bootstrap Signalと、Post-Bootstrap Waveformから構成される。Bootstrap Signalのフィールドには、複数のBootstrap Symbolが配置される。例えば、Bootstrap Symbolとしては、図１０のBootstrap Symbol 1や、図１１のBootstrap Symbol 2が配置される。
図１０は、Bootstrap Symbol 1のシンタックスの例を示している。このBootstrap Symbol 1は、1ビットのea_wake_up_1のフィールドを含む。ea_wake_up_1は、緊急警報（Emergency Alert）に応じて受信装置２０を起動させるためのビットである。
図１１は、Bootstrap Symbol 2のシンタックスの例を示している。このBootstrap Symbol 2は、1ビットのea_wake_up_2のフィールドを含む。ea_wake_up_2は、緊急警報に応じて受信装置２０を起動させるためのビットである。
このように、図１０のBootstrap Symbol 1のea_wake_up_1の1ビットと、図１１のBootstrap Symbol 2のea_wake_up_2の1ビットは、受信装置２０を起動させるためのビットであって、それらのビットを連結した2ビットによって、上述の図２に示したように、EAウェイクアップ情報（のビット）を構成している。また、このEAウェイクアップ情報のビットの意味として、"00", "01"， "10"， "11"の４通りの意味を持たせることができるのは、上述の図３に示した通りである。
なお、ATSC3.0で規定されている物理層フレームにおいて、プリアンブルには、L1-Basicシグナリングや、L1-Detailシグナリング等のL1シグナリング（物理層のシグナリング）を含む。また、サブフレームには、ペイロード（データ）が配置される。物理層フレームにおいて、２以上のサブフレームを含む場合には、サブフレームごとに、FFTサイズやGI(Guard Interval)長などの変調パラメータを変更することができる。
また、ATSC3.0で規定されている物理層フレームにおいて、ブートストラップは、DVB-T2(Digital Video Broadcasting - Terrestrial 2)で規定されているT2フレームを構成するP1シンボルに対応している。また、プリアンブルは、T2フレームを構成するP2シンボルに対応している。したがって、ブートストラップは、プリアンブル信号であると言うこともできる。
なお、Bootstrap Symbol 1やBootstrap Symbol 2については、下記の非特許文献１の「6. BOOTSTRAP SIGNAL STRUCTURE」に、その詳細が記載されている。また、2ビットのWake-upビットの値の意味については、下記の非特許文献２の「Annex G: Emergency Alert Signaling」に、その詳細が記載されている。
非特許文献１：ATSC Standard: A/321, System Discovery and Signaling
非特許文献２：ATSC Candidate Standard: Signaling, Delivery, Synchronization, and Error Protection (A/331)
（プロトコルスタックの例）
図１２は、本技術を適用したIP伝送方式のプロトコルスタックの例を示す図である。
図１２において、最も下位の階層は、物理層（Physical Layer）とされる。例えばATSC3.0等のIP伝送方式のデジタル放送では、一方向の放送を利用した伝送に限らず、一部のデータを、双方向の通信を利用して伝送する場合があるが、放送（Broadcast）を利用する場合、その物理層は、サービス（チャネル）のために割り当てられた放送波の周波数帯域等が対応することになる。
物理層（Physical Layer）の上位の階層は、リンクレイヤプロトコル層（Link Layer Protocol）とされる。また、リンクレイヤプロトコル層の上位の階層は、IP(Internet Protocol)層とUDP(User Datagram Protocol)層とされる。IP層とUDP層は、通信の階層モデルにおけるネットワーク層とトランスポート層に相当する層であり、IPアドレスとポート番号により、IPパケットとUDPパケットが特定される。
ここで、上位層のシグナリング（制御情報）として、LLS(Low Level Signaling)とSLS(Service Layer Signaling)を用いることができる。LLSは、SLSよりも下位の層で伝送されるシグナリングである。SLSは、サービス単位のシグナリングである。すなわち、本技術を適用したプロトコルスタックでは、上位層のシグナリングが、LLSとSLSの２階層で伝送される。
LLSには、SLT(Service List Table)やAEAT(Advanced Emergency Alert Table)，RRT(Region Rating Table)等のメタデータが含まれる。
SLTメタデータは、放送サービス（チャネル）の選局に必要な情報など、放送ネットワークにおけるストリームや放送サービスの構成を示す基本情報を含む。AEATメタデータは、緊急に告知する必要がある情報である緊急警報情報に関する情報を含む。SLTメタデータやAEATメタデータは、UDPパケットを含むIPパケットであるUDP/IPパケットに含めて伝送される。
IP層とUDP層に隣接する上位の階層は、ROUTE(Real-time Object Delivery over Unidirectional Transport)とされる。ROUTEは、ストリーミングファイル転送用のプロトコルであって、FLUTE(File Delivery over Unidirectional Transport)を拡張したものである。
このROUTEセッションにより、放送サービスごとに、SLSのファイル（Signaling）や、NRT(Non Real Time)コンテンツのファイル（NRT）、DASHセグメントファイル（DASH）などが伝送される。
ここで、SLSは、サービスレベルのシグナリングであり、対象の放送サービスに属するコンポーネント（例えば、映像、音声、又は字幕等）の探索と選択に必要な情報や属性などを提供するものである。SLSは、USBD(User Service Bundle Description)，S-TSID(Service-based Transport Session Instance Description)，MPD(Media Presentation Description)等のメタデータを含む。また、NRTコンテンツは、放送経由で取得されるコンテンツであって、例えば、アプリケーションが含まれる。
なお、詳細な説明は省略するが、メディアトランスポート方式として、ROUTEプロトコルの代わりに、MMT(MPEG Media Transport)プロトコルを用いることもできる。
一方で、双方向の通信（Broadband）を利用する場合、その物理層（Physical Layer）の上位の階層は、データリンク層（Data Link Layer）とされる。また、データリンク層の上位の階層は、ネットワーク層に相当するIP層とされる。IP層に隣接する上位階層は、トランスポート層に相当するTCP(Transmission Control Protocol)層とされ、さらに、TCP層に隣接する上位階層は、アプリケーション層に相当するHTTP(Hypertext Transfer Protocol)層とされる。
すなわち、通信を利用する場合においては、これらの階層によって、インターネット等の通信回線で稼働するTCP/IPなどのプロトコルが実装される。
HTTP層に隣接する上位階層のうち、一部の階層は、シグナリング（Signaling）と、NRTコンテンツ（NRT）とされる。このシグナリング（制御情報）としては、上述したROUTEセッションで伝送されるシグナリングなど、すべてのシグナリング（制御情報）が含まれる。また、NRTコンテンツは、通信経由で取得されるコンテンツであって、例えば、アプリケーションが含まれる。
HTTP層に隣接する上位階層のうち、上述した階層以外の他の階層は、DASHセグメント（DASH）とされる。すなわち、双方向の通信系のストリーミング配信では、VOD(Video On Demand)番組等のコンテンツを構成するコンポーネント（例えば、映像、音声、又は字幕等）のストリームデータが、ISO BMFFの規格に準じたDASHセグメント単位で伝送されることになる。
以上のように、本技術を適用したIP伝送方式のプロトコルスタックにおいては、一方向の放送系の階層と、双方向の通信系の階層の一部が共通のプロトコルとなって、一方向の放送と双方向の通信で、コンテンツを構成するコンポーネント（例えば、映像、音声、又は字幕等）のストリームデータを、ISO BMFFの規格に準じたDASHセグメント単位で伝送することができる。
そのため、一方向の放送系のストリーミング配信と、双方向の通信系のストリーミング配信の双方を行う場合において、上位の階層のプロトコルが共通化されているため、伝送システム１を構成する各装置での実装の負担や処理の負担を軽減することができる。
（LLSパケットの構造）
図１３は、LLSテーブルのシンタックスの例を示す図である。
図１３のLLSテーブルにおいて、LLS_table_id, LLS_group_id, group_count_minus1, LLS_table_versionは、LLSを含むパケット（LLSパケット）のLLSヘッダに含まれる。
8ビットのLLS_table_idは、LLSテーブルを識別するIDを示している。8ビットのLLS_group_idは、LLSが属するグループを識別するIDを示している。8ビットのLLS_table_versionは、LLSテーブルのバージョンを示している。
また、switch文によって、LLSテーブルIDとして、"0x01"を指定した場合に、LLSのデータとして、SLTメタデータを配置することを示す。また、LLSテーブルIDとして、"0x02"を指定した場合には、LLSのデータとして、RRTメタデータを配置し、"0x03"を指定した場合には、LLSのデータとして、システム時間（System Time）を配置することを示す。さらに、LLSテーブルIDとして、"0x04"を指定した場合には、LLSのデータとして、AEATメタデータを配置することを示す。
すなわち、物理層フレーム（L1 Frame）は、L1ヘッダとL1ペイロードから構成されるが、このL1ヘッダ（例えばブートストラップ）には、緊急時にスタンバイモードの受信装置２０を起動させるためのEAウェイクアップ情報（EA Wakeup）が含まれる。また、L1ペイロードには、複数の伝送パケット（例えば、ALP(ATSC Link-Layer Protocol)パケット）を配置している。
この伝送パケットは、レイヤ２の階層（L2）のパケットであって、そのペイロードに、LLSテーブルを配置している。すなわち、LLSテーブルは、UDP/IPパケットに含めて伝送されるため、そのヘッダとして、LLSヘッダのほかに、IPヘッダとUDPヘッダが付加される。また、LLSテーブルには、LLSのデータ、すなわち、AEATメタデータ等が配置される。
（AEATメタデータの構造）
図１４及び図１５は、XML(Extensible Markup Language)形式のAEATメタデータのシンタックスの例を示す図である。
なお、図１４及び図１５において、要素と属性のうち、属性には「@」が付されている。また、インデントされた要素と属性は、その上位の要素に対して指定されたものとなる。
図１４に示すように、ルート要素としてのAEAT要素は、１又は複数のAEA要素を含む。このAEA要素は、aeaId属性、issuer属性、audience属性、aeaType属性、refAEAId属性、priority属性、wakeup属性、Header要素、AEAText要素、LiveMedia要素、及びMedia要素の上位要素となる。
aeaId属性は、AEAメッセージを識別するIDを指定する。issuer属性は、AEAメッセージの発行者を指定する。audience属性は、AEAメッセージの視聴者を指定する。
aeaType属性は、AEAメッセージのカテゴリを指定する。refAEAId属性は、aeaId属性が示すIDにより参照されるAEAメッセージを識別するIDを指定する。
priority属性は、AEAメッセージの優先度を指定する。wakeup属性は、AEAメッセージを、ea_wake_upビットに関連付けるかどうかを指定する。
Header要素は、effective属性、expires属性、EventCode要素、EventDesc要素、及びLocation要素の上位要素となる。
effective属性は、AEAメッセージが有効となる日時を指定する。expires属性は、AEAメッセージが失効する日時を指定する。
EventCode要素は、AEAメッセージのイベントの種別を指定する。type属性は、国ごとに割り当てられるイベントコードのドメインを指定する。
EventDesc要素は、緊急警報のイベントの短いテキスト情報の説明を指定する。lang属性は、EventDesc要素による説明の言語を指定する。
Location要素は、AEAメッセージのターゲットとなる地域の地理的なコードを指定する。type属性は、当該コードのドメインを指定する。
AEAText要素は、AEAメッセージのテキスト情報を指定する。AEATメタデータを利用する場合には、このAEAメッセージが、緊急警報情報に相当する。lang属性は、AEAメッセージのテキスト情報の言語を指定する。
LiveMedia要素は、緊急警報情報の関連情報の選択肢として、ユーザに提示可能な放送配信を識別するための情報を含む。AEATメタデータを利用する場合には、このLiveMedia要素の記述内容に基づき、緊急警報サービスが存在するかどうかを判定して、ライブ放送される緊急警報番組を選局することができる。
bsid属性とserviceId属性は、ライブ放送される緊急警報番組を識別するためのブロードキャストストリームIDとサービスIDを指定する。ServiceName要素は、ライブ放送される緊急警報番組の名称を指定する。lang属性は、サービスの名称の言語を指定する。
Media要素は、マルチメディアリソースのコンポーネント部分を含む。lang属性は、メディアリソースの言語を指定する。mediaDesc属性は、メディアリソースのコンテンツの説明を指定する。mediaType属性は、関連するメディアの使用目的を指定する。
url属性は、メディアのファイルのURLを指定する。alternateUrl属性は、メディアのファイルを通信経由でも利用可能な場合に、そのURLを指定する。contentType属性は、IANA(Internet Assigned Numbers Authority)により割り当てられたメディアタイプを指定する。
contentLength属性は、メディアのサイズをバイト単位で指定する。mediaAssoc属性は、この属性が関連付けられている別のメディア要素のURIを指定する。
なお、図１４及び図１５において、出現数（Use）であるが、"1"が指定された場合にはその要素又は属性は必ず１つだけ指定され、"0..1"が指定された場合には、その要素又は属性を指定するかどうかは任意である。また、"1..n"が指定された場合には、その要素又は属性は１以上指定され、"0..n"が指定された場合には、その要素又は属性を１以上指定するかどうかは任意である。
また、Data Typeとして、"string"が指定された場合には、その要素又は属性の値が、文字列型であることを示し、"unsignedByte"が指定された場合には、その要素又は属性の値が、unsignedByte型であることを示す。さらに、Data Typeとして、"boolean"が指定された場合には、ブーリアン型であることを示し、"date Time"が指定された場合には、日時型であることを示す。
さらに、Data Typeとして、"lang"が指定された場合には、言語型であることを示し、"anyURI"が指定された場合、anyURIデータ型であることを示す。また、Data Typeとして、"unsignedShort"，"unsignedLong"が指定された場合には、unsignedShort型、unsignedLong型であることをそれぞれ示す。
なお、図１４及び図１５に示したAEATメタデータのシンタックスは、一例であって、例えば、他の要素や属性を追加するなど、他のシンタックスを採用してもよい。また、AEATメタデータは、XML形式に限らず、他のマークアップ言語により記述してもよいし、あるいはセクション形式であってもよい。
また、AEATメタデータについては、上記の非特許文献２の「6.5 Advanced Emergency Alert Table」に、その詳細が記載されている。
（受信装置の構成）
図１６は、本技術を適用した受信装置の構成の例を示す図である。
図１６において、受信装置２０は、放送チューナ部２０１、放送信号処理部２０２、出力画面部２０３、及び音声出力部２０４を含んで構成される。
放送チューナ部２０１は、例えば、チューナモジュールや復調LSIなどから構成される受信部である。放送チューナ部２０１は、受信アンテナ（不図示）を介して入力される放送信号を受信して、放送信号から得られる物理層フレームに関する処理（例えば、復調処理や誤り訂正処理等）を行い、その処理の結果得られる放送ストリーム（放送データパケット）を、放送信号処理部２０２に供給する。なお、放送データパケットとしては、例えば、ALPパケット等の伝送パケットや、UDP/IPパケットなどを用いることができる。
放送信号処理部２０２は、例えば、システムオンチップ（SoC）などとして構成される処理部である。放送信号処理部２０２は、放送チューナ部２０１から供給される放送ストリーム（放送データパケット）を処理して、選局された放送番組に対応するストリームに含まれる映像や音声、字幕のデータのデコードなどを行う。放送信号処理部２０２は、処理の結果得られるデータのうち、映像や字幕のデータを出力画面部２０３に供給し、音声のデータを音声出力部２０４に供給する。
出力画面部２０３は、例えば、液晶ディスプレイや有機ELディスプレイ等の表示デバイスとして構成される。出力画面部２０３は、放送信号処理部２０２から供給される映像や字幕のデータに基づいて、放送番組の映像や字幕を表示する。
音声出力部２０４は、例えば、スピーカなどとして構成される。音声出力部２０４は、放送信号処理部２０２から供給される音声のデータに基づいて、放送番組の映像に同期した音声を出力する。
ここで、放送信号処理部２０２は、放送チューナ部２０１とは異なるチップ（Chip）として構成され、所定のインターフェースを介して接続されている。スタンバイモードで動作する受信装置２０においては、放送チューナ部２０１は起動して動作しているが、放送信号処理部２０２、出力画面部２０３、及び音声出力部２０４は動作していない（電力が供給されていない）ことになる。なお、図１６に示した構成では図示を省略しているが、受信装置２０には、各部に供給される電力を制御するための電源管理部が設けられ、動作モードに応じて、放送チューナ部２０１や放送信号処理部２０２等に電力が供給されることになる。
スタンバイモードで動作する受信装置２０において、放送チューナ部２０１は、物理層フレーム（のブートストラップ）から得られるEAウェイクアップ情報に基づき、放送信号処理部２０２に起動を指示する。その一方で、放送信号処理部２０２は、放送チューナ部２０１から起動指示がなされた場合、AEATメタデータ及び受信設定情報等に基づき、緊急警報情報の提示を制御する。また、放送信号処理部２０２は、放送チューナ部２０１に対し、周波数設定等のチューナ制御を行うことができる。なお、放送信号処理部２０２の詳細な構成は、図１７のブロック図を参照して後述する。
（放送信号処理部の構成）
図１７は、本技術を適用した放送信号処理部（SoC）の詳細な構成の例を示す図である。
図１７において、放送信号処理部２０２は、復調器I/F２２１、デマルチプレクサ２２２、放送ミドルウェア２２３、デスクランブラ部２２４、映像・音声・字幕デコーダ部２２５、提示処理部２２６、緊急警報制御部２２７、緊急警報情報出力部２２８、通信I/F２２９、通信ミドルウェア２３０、放送アプリケーション処理部２３１、リモコンI/F２３２、受信機管理部２３３、及び受信機アプリケーション処理部２３４を含んで構成される。
復調器I/F２２１は、放送チューナ部２０１（の復調器）とのインターフェースであって、入力端子２１１－１を介して入力される放送ストリーム（放送データパケット）を、デマルチプレクサ２２２に供給する。
デマルチプレクサ２２２は、復調器I/F２２１から供給される放送ストリーム（放送データパケット）を、複数のストリームに分離し、その結果得られるストリームを、放送ミドルウェア２２３、緊急警報制御部２２７、又は受信機管理部２３３に供給する。
放送ミドルウェア２２３は、デマルチプレクサ２２２から供給されるストリームを処理し、その結果得られるデータを、映像・音声・字幕デコーダ部２２５、緊急警報制御部２２７、放送アプリケーション処理部２３１、又は受信機アプリケーション処理部２３４に供給する。
デスクランブラ部２２４は、放送ミドルウェア２２３に入力されるストリームが暗号化（スクランブル）されている場合に、当該ストリームを、所定の鍵を用いて暗号化を解いて元の状態に戻すための復号（デスクランブル）を行う。
映像・音声・字幕デコーダ部２２５は、放送ミドルウェア２２３から供給される符号化ストリームをデコードし、その結果得られるデータを、提示処理部２２６に供給する。ここでは、例えば、符号化ストリームは、選局された放送番組のコンポーネント（例えば、映像、音声、又は字幕等）のストリームを含み、当該ストリームがデコードされる。
提示処理部２２６は、映像・音声・字幕デコーダ部２２５から供給されるデータを、出力画面部２０３又は音声出力部２０４に提示するための提示処理を行い、その結果得られる提示データを、出力端子２１２を介して、出力画面部２０３又は音声出力部２０４に出力する。
例えば、提示処理部２２６は、映像データ及び字幕データに対する提示処理を行い、その結果得られる提示データを、映像出力端子２１２－１及び字幕出力端子２１２－３を介して、出力画面部２０３に出力する。また、例えば、提示処理部２２６は、音声データに対する提示処理を行い、その結果得られる提示データを、音声出力端子２１２－２を介して、音声出力部２０４に出力する。
緊急警報制御部２２７は、放送ミドルウェア２２３から供給されるAEATメタデータ（緊急警報情報を含む）、及びユーザにより設定された緊急警報情報の受信設定に関する受信設定情報などに基づいて、緊急警報に関する制御を行う。緊急警報制御部２２７は、緊急警報情報を出力すると判定した場合、緊急警報情報を、緊急警報情報出力部２２８に供給する。
緊急警報制御部２２７は、不揮発性メモリ等の記録部２２７Ａを含む。記録部２２７Ａは、受信機管理部２３３からの緊急警報情報の受信設定の入力の結果に応じた受信設定情報を記録する。また、緊急警報制御部２２７は、緊急警報情報出力部２２８等と連携することで、過去に受信された緊急警報情報の状態や表示内容を、履歴情報として記録部２２７Ａに記録する。
緊急警報情報出力部２２８は、緊急警報制御部２２７から供給される緊急警報情報を処理し、提示処理部２２６に供給する。
提示処理部２２６は、緊急警報情報出力部２２８から供給される緊急警報情報を、出力画面部２０３に提示するための提示処理を行い、その結果得られる提示データを、映像出力端子２１２－１又は字幕出力端子２１２－３を介して、出力画面部２０３に出力する。
通信I/F２２９は、ネットワークカードや無線LANアダプタ等の通信部（不図示）とのインターフェースであって、入力端子２１１－２を介して入力される通信ストリームを、通信ミドルウェア２３０に供給する。
通信ミドルウェア２３０は、通信I/F２２９から供給される通信ストリームを処理し、その結果得られる放送アプリケーションを、放送アプリケーション処理部２３１に供給する。ここで、放送アプリケーションは、放送番組等のコンテンツに付随したアプリケーションである。
放送アプリケーション処理部２３１は、通信ミドルウェア２３０から供給される放送アプリケーションの起動や終了などの動作を制御し、当該放送アプリケーションに関するデータを、提示処理部２２６に供給する。
提示処理部２２６は、放送アプリケーション処理部２３１により動作が制御される放送アプリケーションを、出力画面部２０３に提示するための提示処理を行い、その結果得られる提示データを、放送アプリケーション出力端子２１２－５を介して、出力画面部２０３に出力する。
リモコンI/F２３２は、例えば赤外線受光部等の受光部（不図示）とのインターフェースであって、入力端子２１１－３を介して入力される、リモートコントローラ２１からの赤外線信号を、受信機管理部２３３に供給する。
受信機管理部２３３は、リモコンI/F２３２から供給される赤外線信号等の情報に基づいて、受信装置２０により実行される各部の動作を管理する。例えば、受信機管理部２３３は、通常起動モードや緊急警報優先モード等の受信装置２０の起動モードの管理を行う。また、例えば、受信機管理部２３３は、ユーザのリモートコントローラ操作に応じて、緊急警報情報の受信設定の入力を受け付け、その入力の結果を、緊急警報制御部２２７に通知する。
また、受信機管理部２３３は、赤外線信号に基づき、受信機アプリケーションを起動すると判定した場合、その旨を、受信機アプリケーション処理部２３４に通知する。ここで、受信機アプリケーションは、受信装置２０にあらかじめ組み込まれたアプリケーションである。
受信機アプリケーション処理部２３４は、受信機管理部２３３から供給される通知に基づいて、受信機アプリケーションを起動し、当該受信機アプリケーションに関するデータを、提示処理部２２６に供給する。
提示処理部２２６は、受信機アプリケーション処理部２３４により起動された受信機アプリケーションを、出力画面部２０３に提示するための提示処理を行い、その結果得られる提示データを、受信機アプリケーション出力端子２１２－４を介して、出力画面部２０３に出力する。
なお、図１７においては、放送アプリケーションと受信機アプリケーションとを区別しているが、放送アプリケーションは、放送番組等のコンテンツに付随したアプリケーションである一方で、受信機アプリケーションは、いわばレジデントアプリケーションであって、例えば、受信設定情報を設定するためのアプリケーション（図２５）などを含む。例えば、放送アプリケーションは、HTML5等のマークアップ言語や、JavaScript（登録商標）等のスクリプト言語により開発され、対応するブラウザにより表示することができる。
また、図１７に示した構成では、放送アプリケーションが、通信ストリームから取得される場合を説明したが、放送ストリームから取得されるようにしてもよい。さらに、放送番組を構成するコンポーネントの一部や、VODコンテンツが、通信経由で取得されて提示されるようにしてもよい。また、図１７に示した構成では、記録部２２７Ａが、緊急警報制御部２２７に含まれるとして説明したが、システムオンチップ（SoC）に内蔵されて各部により共通に用いられる不揮発性メモリや、システムオンチップ（SoC）の外部に設けられた不揮発性メモリに、受信設定情報等の情報を記録するようにしてもよい。さらに、図１７に示した構成では、ブロック間の矢印で示したように、各ブロックは、必要に応じて他のブロックとの間で、各種のデータをやり取りすることができる。
次に、図１８乃至図２３を参照しながら、緊急警報受信時の受信装置２０の動作の詳細について説明する。
（放送チューナ部の処理の流れ）
まず、図１８のフローチャートを参照して、放送チューナ部２０１により実行される処理の流れを説明する。
ただし、図１８に示した処理を実行するに際して、受信装置２０は、スタンバイモードで動作しており、放送チューナ部２０１には電源からの電力が供給されて起動されているが、その後段に設けられた放送信号処理部２０２、出力画面部２０３、及び音声出力部２０４等には、電力が供給されずに停止状態となっている。
ステップＳ１１において、放送チューナ部２０１は、受信周波数を設定する。例えば、この受信周波数としては、前回の起動時に最後に視聴したチャンネルであるラストチャンネルの周波数帯域が設定される。
ステップＳ１２において、放送チューナ部２０１は、受信アンテナを介して、放送信号を受信したかどうかを判定する。なお、この判定処理を行う際には、物理層フレームのうち、ブートストラップに対応した部分のみを監視すればよい。
ステップＳ１２において、放送信号を受信していないと判定された場合、ステップＳ１２の判定処理が繰り返される。一方で、ステップＳ１２において、放送信号を受信したと判定された場合、処理は、ステップＳ１３に進められる。
ステップＳ１３において、放送チューナ部２０１は、放送信号を処理し、物理層フレームのブートストラップを受信する。
ステップＳ１４において、放送チューナ部２０１は、受信したブートストラップに対応する部分を処理し、EAウェイクアップ情報（EA Wakeup）の値を抽出する。ここでは、EA Wake upビットを構成するea_wake_up_1，ea_wake_up_2の２ビットが抽出される。
ステップＳ１５において、放送チューナ部２０１は、抽出したEAウェイクアップ情報（EA Wakeup）の値に基づいて、EA Wakeup = "00"からアクティブ（"01"，"10"，"11"）に変更したか、又はアクティブ（"01"，"10"，"11"）の状態で前回受信したEA Wakeupの値から変更したかどうかを判定する。
ステップＳ１５において、２つの判定条件をいずれも満たしていないと判定された場合、処理は、ステップＳ１２に戻り、それ以降の処理が実行される。一方で、ステップＳ１５において、２つの判定条件のうちいずれか一方の判定条件を満たしたと判定された場合、処理は、ステップＳ１６に進められる。
ステップＳ１６において、放送チューナ部２０１は、放送信号処理部２０２に起動を指示する。すなわち、スタンバイモードで動作する受信装置２０では、電力が供給されずに停止状態の放送信号処理部２０２の電源がオンされ、緊急警報優先モードにより起動することになる。
ステップＳ１７において、放送チューナ部２０１は、電源を完全にオフするかどうかを判定する。ステップＳ１７において、電源を完全にオフしないと判定された場合、処理は、ステップＳ１２に戻り、それ以降の処理が実行される。すなわち、この場合、受信装置２０は、スタンバイモードでの動作を継続することになる。
一方で、ステップＳ１７において、電源を完全にオフすると判定された場合、放送チューナ部２０１への電源の供給が停止され、図１８に示した処理は終了する。なお、「電源を完全にオフする」とは、受信装置２０がスタンバイモードで動作するのではなく、所定の操作によって電源を完全に切った状態であって、放送チューナ部２０１にも電力が供給されずに起動していない状態とされる。
以上、放送チューナ部２０１の処理の流れを説明した。
（放送信号処理部（SoC）の処理の流れ）
次に、図１９及び図２０のフローチャートを参照して、放送信号処理部２０２により実行される処理の流れを説明する。
ただし、図１９及び図２０に示した処理を実行するに際して、放送チューナ部２０１の後段に設けられた放送信号処理部２０２、出力画面部２０３、及び音声出力部２０４等には、電源からの電力が供給されずに停止状態となっている。
すなわち、受信装置２０は、スタンバイモードで動作しているため、放送信号処理部２０２は、コマンド待ちの状態となる（Ｓ３１，Ｓ３２の「NO」）。そして、放送信号処理部２０２が、起動指示を受信したと判定された場合（Ｓ３２の「YES」）、処理は、ステップＳ３３に進められる。
ステップＳ３３において、放送信号処理部２０２は、受信した起動指示が、緊急警報優先モードによる起動指示であるかどうかを判定する。
ステップＳ３３において、緊急警報優先モードによる起動指示ではないと判定された場合、処理は、ステップＳ３４に進められる。
ステップＳ３４において、放送信号処理部２０２は、通常起動モードによる受信システムの起動と放送サービスを表示するための処理を実行する。
すなわち、ここでは、ユーザのリモートコントローラ操作や、視聴予約のタイマ設定などによって、スタンバイモードで動作する受信装置２０の電源オンが指示されることで、放送信号処理部２０２の起動が指示されたため、通常起動モードにより動作して放送サービスを表示することになる。なお、ここでは、受信装置２０の各部（の機能）を総称して、受信システムと呼ぶものとする。
このステップＳ３４の処理は、受信装置２０の電源オフが指示されるまで継続される（Ｓ３４，Ｓ３５の「NO」）。そして、受信装置２０の電源オフが指示された場合（Ｓ３５の「YES」）、処理は、ステップＳ３６に進められ、受信装置２０は、通常起動モードからスタンバイモードに遷移する（Ｓ３６）。なお、ステップＳ３６の処理が終了すると、図１９及び図２０に示した処理は終了する。
一方で、ステップＳ３３において、緊急警報優先モードによる起動指示であると判定された場合、処理は、ステップＳ３７に進められる。なお、この緊急警報優先モードによる起動指示は、上述した図１８のステップＳ１６の処理で、放送チューナ部２０１が、放送信号処理部２０２に対して行う起動指示に相当するものである。
ステップＳ３７において、緊急警報制御部２２７は、受信システムの起動判定処理を実行する。この受信システムの起動判定処理では、緊急警報情報を含むAEATメタデータ、受信設定情報、及び履歴情報に基づき、緊急警報優先モードにより受信システムを起動するかどうかが判定される。なお、受信システムの起動判定処理の詳細は、図２１のフローチャートを参照して後述する。
ステップＳ３８において、緊急警報制御部２２７は、受信システムの起動判定処理の判定結果に基づいて、緊急警報優先モードにより受信システムを起動するかどうかを判定する。
ステップＳ３８において、緊急警報優先モードにより受信システムを起動しないと判定された場合、処理は、ステップＳ３６に進められる。この場合、受信装置２０は、スタンバイモードでの動作を継続することになる（Ｓ３６）。
一方で、ステップＳ３８において、緊急警報優先モードにより受信システムを起動すると判定された場合、処理は、ステップＳ３９に進められ、緊急警報優先モードにより受信システムが起動される（Ｓ３９）。
ステップＳ４０において、緊急警報制御部２２７は、放送ミドルウェア２２３により放送ストリームから抽出されたAEATメタデータを取得する。
ステップＳ４１において、緊急警報制御部２２７は、取得したAEATメタデータ（例えば、図１５のLiveMedia要素の情報）に基づいて、緊急警報サービスの指定があるかどうかを判定する。
ステップＳ４１において、緊急警報サービスの指定があると判定された場合、処理は、ステップＳ４２に進められる。ステップＳ４２においては、起動した受信システムによって、緊急警報サービスを選局して、緊急警報番組（例えば、図７の画面D42等）を表示する。
また、ステップＳ４１において、緊急警報サービスの指定がないと判定された場合、処理は、ステップＳ４３に進められる。ステップＳ４３においては、起動した受信システムによって、選局中のチャンネル（ラストチャンネル）の放送サービスを選局して、通常番組（例えば、図７の画面D43等）を表示する。
ステップＳ４２又はＳ４３の処理が終了すると、処理は、ステップＳ４４に進められる。ステップＳ４４において、提示処理部２２６は、取得したAEATメタデータに含まれる緊急警報情報（例えば、図１５のAEAText要素のAEAメッセージのテキスト情報）を、出力画面部２０３に表示する（例えば、図７の画面D42又は画面D43等）。
ステップＳ４５において、緊急警報制御部２２７は、AEATメタデータに基づいて、緊急警報サービスの更新があるかどうかを判定する。
ステップＳ４５において、緊急警報サービスの更新があると判定された場合、処理は、ステップＳ４６に進められる。ステップＳ４６において、緊急警報制御部２２７は、緊急警報情報の更新処理を実行する。
また、ステップＳ４５において、緊急警報サービスの更新がないと判定された場合、ステップＳ４６の処理はスキップされ、処理は、ステップＳ４７に進められる。ステップＳ４７において、ユーザのリモートコントローラ操作等によって、受信装置２０の電源オフが指示されたかどうかが判定される。
ステップＳ４７において、受信装置２０の電源オフが指示されていないと判定された場合、処理は、ステップＳ４５に戻り、それ以降の処理が繰り返される。すなわち、受信装置２０において、例えば、緊急警報情報A1を表示中であって、電源オフが指示される前に、緊急警報サービスの更新があったときには、緊急警報情報A1から緊急警報情報A2への更新処理が行われる。一方で、ステップＳ４７において、受信装置２０の電源オフが指示されたと判定された場合、処理は、ステップＳ４８に進められる。
ステップＳ４８において、緊急警報制御部２２７は、緊急警報情報の状態や表示内容を、前回（過去）に受信された緊急警報情報に関する履歴情報として、記録部２２７Ａに記録する。このような履歴情報を記録しておくことで、次回以降の受信システムの起動判定処理に過去の履歴を反映させることができる。
そして、ステップＳ４８の処理が終了すると、処理は、ステップＳ４９に進められ、受信装置２０は、緊急警報モードからスタンバイモードでの動作に遷移する（Ｓ４９）。なお、ステップＳ４９の処理が終了すると、図１９及び図２０に示した処理は終了する。
以上、放送信号処理部２０２の処理の流れを説明した。
（受信システムの起動判定処理の流れ）
次に、図２１のフローチャートを参照して、図１９のステップＳ３７の処理に対応する受信システムの起動判定処理の詳細を説明する。
ステップＳ７１において、緊急警報制御部２２７は、放送ストリームから抽出されたAEATメタデータを取得する。また、ステップＳ７２において、緊急警報制御部２２７は、記録部２２７Ａに記録された受信設定情報を読み出して取得する。
ステップＳ７３において、緊急警報制御部２２７は、前回（又は過去）の起動時に履歴情報を記録しているかどうかを判定する。
ステップＳ７３において、前回（又は過去）の起動時に履歴情報を記録していると判定された場合、処理は、ステップＳ７４に進められる。ステップＳ７４において、緊急警報制御部２２７は、記録部２２７Ａに記録された前回（又は過去）の履歴情報（前回（又は過去）の緊急警報情報の状態や表示内容）を読み出して取得する。この履歴情報には、例えば、過去の緊急警報情報の表示内容や、どこまで（いわばどのバージョンまで）表示していたかなどの情報を含み、これらの情報を用いることで、例えば、同一の内容の緊急警報情報を再度提示しないなどの制御が可能となる。
ステップＳ７４の処理が終了すると、処理は、ステップＳ７５に進められる。また、ステップＳ７３において、前回（又は過去）の緊急警報情報の状態や表示内容を記録していないと判定された場合、ステップＳ７４の処理はスキップされ、処理は、ステップＳ７５に進められる。
ステップＳ７５において、緊急警報制御部２２７は、ステップＳ７１の処理で取得したAEATメタデータ（に含まれる緊急警報情報に関する情報）と、ステップＳ７２の処理で取得した受信設定情報及びステップＳ７４の処理で取得した前回（又は過去）の履歴情報（前回（又は過去）の緊急警報情報の状態や表示内容）とを比較して、緊急警報優先モードによる受信システムの起動の条件を満たすかどうかを判定する。
ただし、上述のステップＳ７３の判定処理で、前回の履歴情報を記録していないと判定された場合（Ｓ７３の「NO」）、ステップＳ７５の判定処理では、AEATメタデータと受信設定情報とを比較して、緊急警報優先モードによる受信システムの起動の条件を満たすかどうかが判定される。
ステップＳ７５において、緊急警報優先モードによる受信システムの起動の条件が一致すると判定された場合、処理は、ステップＳ７６に進められる。ステップＳ７６において、緊急警報制御部２２７は、緊急警報情報出力部２２８等に対して、緊急警報優先モードによる受信システムの起動指示を設定する。この起動指示の設定では、放送信号処理部２０２、出力画面部２０３、及び音声出力部２０４等の起動が指示される。
一方で、ステップＳ７５において、緊急警報優先モードによる受信システムの起動の条件が一致しないと判定された場合、処理は、ステップＳ７７に進められる。ステップＳ７７において、緊急警報制御部２２７は、緊急警報優先モードによる受信システムの起動指示を未設定とする。
ステップＳ７６又はＳ７７の処理が終了すると、処理は、図１９のステップＳ３７に戻り、それ以降の処理が実行される。
すなわち、ステップＳ７５の判定処理によって、起動の条件が一致すると判定された場合には、ステップＳ７６の処理が実行されるので、図１９のステップＳ３８の判定処理では、緊急警報優先モードにより受信システムを起動すると判定される。一方で、ステップＳ７５の判定処理によって、起動の条件が不一致であると判定された場合には、ステップＳ７７の処理が実行されるので、図１９のステップＳ３８の判定処理では、緊急警報優先モードにより受信システムを起動しないと判定される。
以上、受信システムの起動判定処理の流れを説明した。
ここで、受信システムの起動判定処理（図１９のステップＳ３７の処理）の具体的な例を説明する。図２２は、図２１のステップＳ７５において、緊急警報優先モードによる受信システムの起動の条件を満たすかどうかの判定処理を行う際に比較される項目を示している。
この比較項目としては、上述した図１４及び図１５のAEATメタデータに対応する項目を含めることができる。例えば、図２２に示すように、AEAT要素のAEA要素の子要素となる、audience属性、aeaType属性、priority属性、Header要素のEventCode要素、Header要素のLocation要素、及びaeaId属性とrefAEAId属性の組み合わせを用いることができる。
audience属性は、緊急警報情報の対象の受信機として、"public", "restricted", 又は"private"を指定することができる。"public"は、一般の受信機向けの緊急警報情報を示す。"restricted"は、制限された受信機向けの緊急警報情報を示す。"private"は、指定された受信機向けの緊急警報情報を示す。
aeaType属性は、緊急警報情報のタイプとして、"alert", "update", 又は"cancel"を指定することができる。"alert"は、新規の緊急警報情報を示す。"update"は、既に配信された緊急警報情報の更新情報であることを示す。"cancel"は、既に配信された緊急警報情報がキャンセルされたことを示す。
priority属性は、緊急警報情報の優先度として、0 ～ 4の値を指定することができる。4が最も優先度が高いことを示し、数字が小さくなるほど、優先度が低くなって、0が最も優先度が低いことを示す。
Header要素のEventCode要素は、緊急警報情報のイベント種別を示す。例えば、イベント種別として"EVI"が指定された場合、避難訓練（Evacuation Warning）を示す。
Header要素のLocation要素は、緊急警報情報の該当地域を示す。例えば、該当地域は、米国の場合、連邦情報処理標準（FIPS：Federal Information Processing Standard）と呼ばれる数字7桁のコードなどを用いることができる。
aeaId属性とrefAEAId属性の組み合わせによって、緊急警報情報を識別するIDを示す。
ここで、aeaId属性は、aeaType属性 = "alert"となるAEATメタデータに対して設定される。また、aeaType属性 = "update", "cancel"となるAEATメタデータに対しては、対象のAEATメタデータのaeaId属性の値を、refAEAId属性の値として記述する。
例えば、図２３に示すように、ハリケーン発生時の時刻t62において、ブートストラップのEA Wakeupの値が"00"から"01"に変化して、新規の緊急警報が配信されたとき、AEATメタデータには、aeaId属性 = 0001，priority属性 = 3 がそれぞれ記述される。
その後、ハリケーンが移動して大型化することで、時刻t63において、緊急警報が更新され、EA Wakeupの値は、"01"から"10"に変化する。このとき配信されるAEATメタデータには、aeaId属性 = 1001，refAEAId属性 = 0001，priority属性 = 4 がそれぞれ記述される。
さらにその後、ハリケーンが移動して消滅することで、時刻t64において、緊急警報がさらに更新され、EA Wakeupの値は、"10"から"11"に変化する。このとき配信されるAEATメタデータには、aeaId属性 = 1002，refAEAId属性 = 0001，priority属性 = 2 がそれぞれ記述される。
このように、緊急警報が更新される度に、refAEAId属性の値を、新規（更新前）のAEATメタデータのaeaId属性の値と同一の値とするとともに、aeaId属性の値を１ずつインクリメントすることで、受信装置２０では、aeaId属性とrefAEAId属性の組み合わせによって、緊急警報情報の系列を一意に識別することができる。これにより、例えば、上述の図８に示したように、AEATメタデータに含まれる識別情報（aeaId属性, refAEAId属性が示すID）に基づき、緊急警報情報の系列を同定して、同系列の緊急警報情報ごとに処理を行うことが可能となる。
また、このような受信システムの起動判定処理が行われるため、ユーザは、受信設定情報を設定（フィルタ設定）することで、例えば、自分が住む地域周辺で、かつ優先度が高い緊急警報情報（優先度が"2"以上の緊急警報情報）のみを受信するなど、自身が受信したい情報（所望の緊急警報情報）のみを得ることができる。
（緊急警報情報の受信設定処理の流れ）
また、受信システムの起動判定処理（図１９のステップＳ３７の処理、すなわち、図２１のステップＳ７５の処理）で用いられる緊急警報情報の受信設定情報は、受信装置２０にてあらかじめ設定しておくものである。そこで、次に、図２４のフローチャートを参照して、緊急警報情報の受信設定処理の流れを説明する。
受信装置２０は、ユーザからの緊急警報情報の受信設定の指示を待つ（Ｓ９１，Ｓ９２の「NO」）。そして、例えば、ユーザによりリモートコントローラ２１が操作され、緊急警報情報の受信設定の画面表示指示がなされた場合（Ｓ９２の「YES」）、処理は、ステップＳ９３に進められる。
ステップＳ９３において、提示処理部２２６は、緊急警報情報の受信設定画面を、出力画面部２０３に表示する。
ステップＳ９４において、受信機管理部２３３は、例えばユーザの操作に応じたリモートコントローラ２１からの赤外線信号に基づいて、緊急警報情報の受信設定の入力を受け付ける。
ステップＳ９５において、緊急警報制御部２２７は、受け付けた緊急警報情報の受信設定の入力に基づいて、緊急警報情報の受信設定情報を、記録部２２７Ａに記録する。
ステップＳ９５の処理が終了すると、処理は、ステップＳ９６に進められる。ステップＳ９６においては、緊急警報情報の受信設定の入力が終了したかどうかが判定される。
ステップＳ９６において、緊急警報情報の受信設定の入力が継続していると判定された場合、処理は、ステップＳ９４に戻り、ステップＳ９４乃至Ｓ９５の処理が繰り返される。これにより、各種の受信設定情報が順次入力され、記録部２２７Ａに記録されることになる。
また、ステップＳ９６において、緊急警報情報の受信設定の入力が終了したと判定された場合、図２４に示した処理は終了する。
以上、緊急警報情報の受信設定処理の流れを説明した。
ここで、図２５は、出力画面部２０３に表示される、緊急警報情報の受信設定画面の例を示している。図２５に示した受信設定画面の遷移では、緊急警報情報の受信時における緊急警報優先モードによる受信システムの起動の条件の設定例を示している。
ユーザによって緊急警報情報の受信設定の画面表示指示がなされていない場合、出力画面部２０３には、通常の放送番組が表示される（画面D61）。その後、ユーザがリモートコントローラ２１を操作して、「Settings」を選択した場合（図中のＳ１）、その表示領域の一部（右側の表示領域）に、設定画面が表示される（画面D62）。
この設定画面（画面D62）では、緊急警報情報の受信設定（「EAS wakeup」）の他に、例えば音声（「Audio」）やアプリケーション（「Application」）の設定などを選択することができる。ここでは、この設定画面（画面D62）の項目の中から、緊急警報情報の受信設定（「EAS wakeup」）を選択した場合（図中のＳ２）、右側の表示領域に表示された設定画面が、緊急警報情報の受信設定画面に切り替わる（画面D63）。
この受信設定画面（画面D63）では、緊急警報情報の対象を設定する「audience」や、緊急警報情報のタイプを設定する「type」、緊急警報情報の優先度を設定する「priority」などの項目を選択することができる。
ここでは、この受信設定画面（画面D63）の項目の中から、「type」を選択した場合（図中のＳ３）、右側の表示領域に表示された受信設定画面が、type設定画面に切り替わる（画面D64）。このtype設定画面（画面D64）では、新規の緊急警報情報を示す「new」（上述のaeaType属性の"alert"に相当する）、既に配信された緊急警報情報の更新情報を示す「update」、及び既に配信された緊急警報情報がキャンセルされたことを示す「cancel」の設定項目ごとに、受信の可否を設定することができる。
このtype設定画面（画面D64）の例では、「new」である設定項目に対し、「Y」である受信可が設定され、「update」である設定項目に対し、「Y」である受信可が設定され、「cancel」である設定項目に対し、「N」である受信否が設定されているので、新規の緊急警報情報、及び更新の緊急警報情報のみが提示されることになる。換言すれば、この設定の場合には、キャンセルの緊急警報情報が提示されることはない。
また、この受信設定画面（画面D63）の項目の中から、「priority」を選択した場合（図中のＳ４）、右側の表示領域に表示された受信設定画面が、priority設定画面に切り替わる（画面D65）。このpriority設定画面（画面D65）では、0 ～ 4である優先度に対応した「0」、「1」、「2」、「3」、及び「4」の設定項目ごとに、受信の可否を設定することができる。
このpriority設定画面（画面D65）の例では、「0」及び「1」である設定項目に対し、「N」である受信否が設定され、「2」乃至「4」である設定項目に対し、「Y」である受信可が設定されているので、2 ～ 4である優先度、すなわち、より優先度の高い緊急警報情報のみが提示されることになる。換言すれば、この設定の場合、0 ～ 1である優先度、すなわち、より優先度の低い緊急警報情報が提示されることはない。
なお、ここでは、type設定画面とpriority設定画面を一例に説明したが、audience設定画面などについても同様のユーザインターフェースにより提示して、ユーザのリモートコントローラ操作などによって、所望の受信設定情報を登録させることができる。
また、ユーザがリモートコントローラ２１を操作して、「back」を選択した場合には、１つ前に表示された画面が再表示される。例えば、type設定画面（画面D64）又はpriority設定画面（画面D65）の表示中に、「back」を選択した場合（図中のＳ５，Ｓ６）、受信設定画面（画面D63）が表示される。
さらに、例えば、受信設定画面（画面D63）の表示中に、「back」を選択した場合（図中のＳ７）、設定画面（画面D62）が表示され、設定画面（画面D62）の表示中に、「back」を選択した場合（図中のＳ８）、通常の放送番組（画面D61）が表示される。
＜２．変形例＞
上述した説明としては、デジタル放送の規格として、米国等で採用されている方式であるATSC（特に、ATSC3.0）を説明したが、本技術は、日本等が採用する方式であるISDB(Integrated Services Digital Broadcasting)や、欧州の各国等が採用する方式であるDVB(Digital Video Broadcasting)などに適用するようにしてもよい。
また、伝送システム１において、伝送路８０は、地上波放送に限らず、例えば、放送衛星（BS：Broadcasting Satellite）や通信衛星（CS：Communications Satellite）を利用した衛星放送、あるいは、ケーブルを用いた有線放送（CATV）などであってもよい。さらに、上述した説明では、米国の緊急告知のシステム（EAS）を一例に説明したが、各国で構築されている同様のシステムに適用するようにしてもよい。
また、上述した説明では、緊急警報情報がテキスト情報である場合を説明したが、テキスト情報に限らず、例えば、画像や映像など、テキスト情報以外の情報についても同様に、本技術を適用することができる。また、緊急警報情報のテキスト情報を、放送番組等のコンテンツの映像（非圧縮の映像データ）に埋め込んだり（いわゆる焼き込みテキスト）、あるいは、緊急警報情報に対応する音声を、音声データに埋め込んだりした場合についても同様に、本技術を適用することができる。
なお、上述したLLSやSLS等のシグナリングの名称は、一例であって、他の名称が用いられる場合があるが、これらの名称の違いは、形式的な違いであって、各シグナリングの実質的な内容が異なるものではない。さらに、シグナリングがXML等のマークアップ言語により記述される場合において、それらの要素や属性の名称は一例であって、他の名称が採用されるようにしてもよい。
また、放送アプリケーションは、ブラウザにより実行されるアプリケーションに限らず、いわゆるネイティブアプリケーションとして、OS（Operating System）環境などで実行されるようにしてもよい。さらに、上述したコンテンツとしては、放送番組やCMのほか、例えば、動画や音楽、電子書籍やゲーム、広告など、あらゆるコンテンツを含めることができる。
なお、上述した説明では、受信装置２０の動作モードについて述べているが、スタンバイモード（スタンバイ状態）においては、放送チューナ部２０１が起動している一方で、放送信号処理部２０２、出力画面部２０３、及び音声出力部２０４等の受信システムは、起動していない状態となる。また、上述した説明で、「電源をオン」するとは、スタンバイモードで動作する受信装置２０の電源を入れることを意味し（換言すれば、電力が供給されずに停止状態の放送信号処理部２０２等を起動するとも言える）、「電源をオフ」するとは、電源がオンされて動作中の受信装置２０を、スタンバイモードで動作させることを意味する。なお、上述した説明では、受信装置２０において、放送チューナ部２０１も起動していない状態を、「電源を完全にオフする」と表現し、上記の「電源をオフ」と区別している。
＜３．コンピュータの構成＞
上述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、コンピュータにインストールされる。図２６は、上述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示す図である。
コンピュータ１０００において、CPU(Central Processing Unit)１００１、ROM(Read Only Memory)１００２、RAM(Random Access Memory)１００３は、バス１００４により相互に接続されている。バス１００４には、さらに、入出力インターフェース１００５が接続されている。入出力インターフェース１００５には、入力部１００６、出力部１００７、記録部１００８、通信部１００９、及び、ドライブ１０１０が接続されている。
入力部１００６は、キーボード、マウス、マイクロフォンなどよりなる。出力部１００７は、ディスプレイ、スピーカなどよりなる。記録部１００８は、ハードディスクや不揮発性のメモリなどよりなる。通信部１００９は、ネットワークインターフェースなどよりなる。ドライブ１０１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブル記録媒体１０１１を駆動する。
以上のように構成されるコンピュータ１０００では、CPU１００１が、ROM１００２や記録部１００８に記録されているプログラムを、入出力インターフェース１００５及びバス１００４を介して、RAM１００３にロードして実行することにより、上述した一連の処理が行われる。
コンピュータ１０００（CPU１００１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブル記録媒体１０１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線又は無線の伝送媒体を介して提供することができる。
コンピュータ１０００では、プログラムは、リムーバブル記録媒体１０１１をドライブ１０１０に装着することにより、入出力インターフェース１００５を介して、記録部１００８にインストールすることができる。また、プログラムは、有線又は無線の伝送媒体を介して、通信部１００９で受信し、記録部１００８にインストールすることができる。その他、プログラムは、ROM１００２や記録部１００８に、あらかじめインストールしておくことができる。
ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含む。また、プログラムは、１のコンピュータ（プロセッサ）により処理されるものであってもよいし、複数のコンピュータによって分散処理されるものであってもよい。
なお、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
また、本技術は、以下のような構成をとることができる。
（１）
放送信号を受信する受信部と、
受信された前記放送信号を処理する処理部と
を備え、
前記受信部は、受信された前記放送信号に含まれる緊急警報起動情報に基づいて、待機中の前記処理部に起動を指示し、
前記処理部は、前記受信部から起動を指示された場合、受信された前記放送信号から得られる緊急警報情報を含むシグナリング、及びユーザにより設定された前記緊急警報情報の受信設定に関する受信設定情報に基づいて、前記緊急警報情報の提示を制御する
受信装置。
（２）
前記処理部は、
過去に受信された前記緊急警報情報に関する履歴情報を取得し、
前記シグナリング、前記受信設定情報、及び前記履歴情報に基づいて、前記緊急警報情報の提示を制御する
前記（１）に記載の受信装置。
（３）
通常の起動時の動作に対応した第１のモードと、
緊急警報時の動作に対応した第２のモードと
を有し、
前記処理部は、前記第２のモードでの起動を指示された場合、前記シグナリング、前記受信設定情報、及び前記履歴情報に基づいて、前記緊急警報情報の提示を制御する
前記（２）に記載の受信装置。
（４）
前記処理部は、
前記シグナリングに含まれる識別情報に基づいて、前記緊急警報情報の系列を同定し、
同定した系列ごとに、前記緊急警報情報の提示を制御する
前記（２）又は（３）に記載の受信装置。
（５）
前記受信設定情報は、前記緊急警報情報の対象の受信機、前記緊急警報情報のタイプ、前記緊急警報情報の優先度、前記緊急警報情報のイベント種別、及び前記緊急警報情報の該当地域に関する受信設定を少なくとも含む
前記（１）乃至（４）のいずれかに記載の受信装置。
（６）
前記履歴情報は、過去に受信された前記緊急警報情報の状態及び表示内容を少なくとも含む
前記（２）に記載の受信装置。
（７）
前記緊急警報起動情報は、物理層のフレームに含まれ、
前記緊急警報情報は、上位層のシグナリングに含まれる
前記（１）乃至（６）のいずれかに記載の受信装置。
（８）
前記受信設定情報及び前記履歴情報を記録する記録部をさらに備え、
前記処理部は、受信された前記シグナリングに含まれる前記緊急警報情報に関する情報と、記録された前記受信設定情報及び前記履歴情報とを比較して、その比較の結果が提示の条件に適合する場合にのみ、前記緊急警報情報を提示する
前記（２）乃至（４）のいずれかに記載の受信装置。
（９）
チューナ部としての前記受信部と、システムオンチップとしての前記処理部とを備えるテレビ受像機として構成される
前記（１）乃至（８）のいずれかに記載の受信装置。
（１０）
放送信号を受信する受信部と、
受信された前記放送信号を処理する処理部と
を備える受信装置の受信方法において、
前記受信部が、受信された前記放送信号に含まれる緊急警報起動情報に基づいて、待機中の前記処理部に起動を指示し、
前記処理部が、前記受信部から起動を指示された場合、受信された前記放送信号から得られる緊急警報情報を含むシグナリング、及びユーザにより設定された前記緊急警報情報の受信設定に関する受信設定情報に基づいて、前記緊急警報情報の提示を制御する
受信方法。
（１１）
待機中に放送信号を受信する受信部から起動を指示された場合、受信された前記放送信号から得られる緊急警報情報を含むシグナリング、及びユーザにより設定された前記緊急警報情報の受信設定に関する受信設定情報に基づいて、前記緊急警報情報の提示を制御する制御部を備える
信号処理装置。
（１２）
前記制御部は、
過去に受信された前記緊急警報情報に関する履歴情報を取得し、
前記シグナリング、前記受信設定情報、及び前記履歴情報に基づいて、前記緊急警報情報の提示を制御する
前記（１１）に記載の信号処理装置。
（１３）
通常の起動時の動作に対応した第１のモードと、
緊急警報時の動作に対応した第２のモードと
を有し、
前記制御部は、前記第２のモードでの起動を指示された場合、前記シグナリング、前記受信設定情報、及び前記履歴情報に基づいて、前記緊急警報情報の提示を制御する
前記（１２）に記載の信号処理装置。
（１４）
前記制御部は、
前記シグナリングに含まれる識別情報に基づいて、前記緊急警報情報の系列を同定し、
同定した系列ごとに、前記緊急警報情報の提示を制御する
前記（１２）又は（１３）に記載の信号処理装置。
（１５）
前記受信設定情報は、前記緊急警報情報の対象の受信機、前記緊急警報情報のタイプ、前記緊急警報情報の優先度、前記緊急警報情報のイベント種別、及び前記緊急警報情報の該当地域に関する受信設定を少なくとも含む
前記（１１）乃至（１４）のいずれかに記載の信号処理装置。
（１６）
前記履歴情報は、過去に受信された前記緊急警報情報の状態及び表示内容を少なくとも含む
前記（１２）に記載の信号処理装置。
（１７）
前記緊急警報情報は、上位層のシグナリングに含まれる
前記（１１）乃至（１６）のいずれかに記載の信号処理装置。
（１８）
前記受信設定情報及び前記履歴情報を記録する記録部をさらに備え、
前記制御部は、受信された前記シグナリングに含まれる前記緊急警報情報に関する情報と、記録された前記受信設定情報及び前記履歴情報とを比較して、その比較の結果が提示の条件に適合する場合にのみ、前記緊急警報情報を提示する
前記（１２）乃至（１４）のいずれかに記載の信号処理装置。
（１９）
システムオンチップとして構成される
前記（１１）乃至（１８）のいずれかに記載の信号処理装置。
（２０）
信号処理装置の信号処理方法において、
前記信号処理装置が、
待機中に放送信号を受信する受信部から起動を指示された場合、受信された前記放送信号から得られる緊急警報情報を含むシグナリング、及びユーザにより設定された前記緊急警報情報の受信設定に関する受信設定情報に基づいて、前記緊急警報情報の提示を制御する
信号処理方法。
１ 伝送システム， １０，１０－１，１０－２ 送信装置， ２０，２０－１，２０－２，２０－３ 受信装置， ２１ リモートコントローラ， ３０ 電波塔， ４０ EAサーバ， ８０ 伝送路， ９０ 通信回線， ２０１ 放送チューナ部， ２０２ 放送信号処理部（SoC）， ２０３ 出力画面部， ２０４ 音声出力部， ２１１－１乃至２１１－３ 入力端子， ２１２－１乃至２１２－５ 出力端子， ２２１ 復調器I/F， ２２２ デマルチプレクサ， ２２３ 放送ミドルウェア， ２２４ デスクランブラ部， ２２５ 映像・音声・字幕デコーダ部， ２２６ 提示処理部， ２２７ 緊急警報制御部， ２２８ 緊急警報情報出力部， ２２９ 通信I/F， ２３０ 通信ミドルウェア， ２３１ 放送アプリケーション処理部， ２３２ リモコンI/F， ２３３ 受信機管理部， ２３４ 受信機アプリケーション処理部， １０００ コンピュータ， １００１ CPU

Claims (20)

  1. 放送信号を受信する受信部と、
    受信された前記放送信号を処理する処理部と
    を備え、
    前記処理部は、
    スタンバイ状態であるとき、受信された前記放送信号に含まれる緊急警報起動情報に基づいて起動状態となり、
    前記起動状態となったとき、受信された前記放送信号から得られるシグナリング、及び緊急警報情報の受信設定に関する受信設定情報に基づいて、前記緊急警報情報の提示を制御し、
    前記シグナリングは、前記緊急警報情報を識別するID、及び前記緊急警報情報が、新規、更新、又はキャンセルされたことを示す情報を含む
    受信装置。
  2. 前記処理部は、
    過去に受信された前記緊急警報情報に関する履歴情報を取得し、
    前記シグナリング、前記受信設定情報、及び前記履歴情報に基づいて、前記緊急警報情報の提示を制御する
    請求項１に記載の受信装置。
  3. 通常の起動時の動作に対応した第１のモードと、
    緊急警報時の動作に対応した第２のモードと
    を有し、
    前記処理部は、前記第２のモードでの起動を指示された場合、前記シグナリング、前記受信設定情報、及び前記履歴情報に基づいて、前記緊急警報情報の提示を制御する
    請求項２に記載の受信装置。
  4. 前記処理部は、
    前記シグナリングに含まれる識別情報に基づいて、前記緊急警報情報の系列を同定し、
    同定した系列ごとに、前記緊急警報情報の提示を制御する
    請求項２に記載の受信装置。
  5. 前記受信設定情報は、前記緊急警報情報の対象の受信機、前記緊急警報情報のタイプ、前記緊急警報情報の優先度、前記緊急警報情報のイベント種別、及び前記緊急警報情報の該当地域に関する受信設定を少なくとも含む
    請求項２に記載の受信装置。
  6. 前記履歴情報は、過去に受信された前記緊急警報情報の状態及び表示内容を少なくとも含む
    請求項５に記載の受信装置。
  7. 前記緊急警報起動情報は、物理層のフレームに含まれ、
    前記緊急警報情報は、上位層のシグナリングに含まれる
    請求項２に記載の受信装置。
  8. 前記受信設定情報及び前記履歴情報を記録する記録部をさらに備え、
    前記処理部は、受信された前記シグナリングに含まれる前記緊急警報情報に関する情報と、記録された前記受信設定情報及び前記履歴情報とを比較して、その比較の結果が提示の条件に適合する場合にのみ、前記緊急警報情報を提示する
    請求項２に記載の受信装置。
  9. チューナ部としての前記受信部と、システムオンチップとしての前記処理部とを備える
    テレビ受像機として構成される
    請求項１に記載の受信装置。
  10. 放送信号を受信する受信部と、
    受信された前記放送信号を処理する処理部と
    を備える受信装置の受信方法において、
    前記処理部が、
    スタンバイ状態であるとき、受信された前記放送信号に含まれる緊急警報起動情報に基づいて起動状態となり、
    前記起動状態となったとき、受信された前記放送信号から得られるシグナリング、及び緊急警報情報の受信設定に関する受信設定情報に基づいて、前記緊急警報情報の提示を制御し、
    前記シグナリングは、前記緊急警報情報を識別するID、及び前記緊急警報情報が、新規、更新、又はキャンセルされたことを示す情報を含む
    受信方法。
  11. スタンバイ状態であるとき、受信された放送信号に含まれる緊急警報起動情報に基づいて起動状態となり、
    前記起動状態となったとき、受信された前記放送信号から得られるシグナリング、及び緊急警報情報の受信設定に関する受信設定情報に基づいて、前記緊急警報情報の提示を制御する制御部を備え、
    前記シグナリングは、前記緊急警報情報を識別するID、及び前記緊急警報情報が、新規、更新、又はキャンセルされたことを示す情報を含む
    信号処理装置。
  12. 前記制御部は、
    過去に受信された前記緊急警報情報に関する履歴情報を取得し、
    前記シグナリング、前記受信設定情報、及び前記履歴情報に基づいて、前記緊急警報情報の提示を制御する
    請求項１１に記載の信号処理装置。
  13. 通常の起動時の動作に対応した第１のモードと、
    緊急警報時の動作に対応した第２のモードと
    を有し、
    前記制御部は、前記第２のモードでの起動を指示された場合、前記シグナリング、前記受信設定情報、及び前記履歴情報に基づいて、前記緊急警報情報の提示を制御する
    請求項１２に記載の信号処理装置。
  14. 前記制御部は、
    前記シグナリングに含まれる識別情報に基づいて、前記緊急警報情報の系列を同定し、
    同定した系列ごとに、前記緊急警報情報の提示を制御する
    請求項１２に記載の信号処理装置。
  15. 前記受信設定情報は、前記緊急警報情報の対象の受信機、前記緊急警報情報のタイプ、前記緊急警報情報の優先度、前記緊急警報情報のイベント種別、及び前記緊急警報情報の該当地域に関する受信設定を少なくとも含む
    請求項１２に記載の信号処理装置。
  16. 前記履歴情報は、過去に受信された前記緊急警報情報の状態及び表示内容を少なくとも含む
    請求項１５に記載の信号処理装置。
  17. 前記緊急警報情報は、上位層のシグナリングに含まれる
    請求項１２に記載の信号処理装置。
  18. 前記受信設定情報及び前記履歴情報を記録する記録部をさらに備え、
    前記制御部は、受信された前記シグナリングに含まれる前記緊急警報情報に関する情報と、記録された前記受信設定情報及び前記履歴情報とを比較して、その比較の結果が提示の条件に適合する場合にのみ、前記緊急警報情報を提示する
    請求項１２に記載の信号処理装置。
  19. システムオンチップとして構成される
    請求項１１に記載の信号処理装置。
  20. 信号処理装置の信号処理方法において、
    前記信号処理装置が、
    スタンバイ状態であるとき、受信された放送信号に含まれる緊急警報起動情報に基づいて起動状態となり、
    前記起動状態となったとき、受信された前記放送信号から得られるシグナリング、及び緊急警報情報の受信設定に関する受信設定情報に基づいて、前記緊急警報情報の提示を制御し、
    前記シグナリングは、前記緊急警報情報を識別するID、及び前記緊急警報情報が、新規、更新、又はキャンセルされたことを示す情報を含む
    信号処理方法。
JP2020508190A 2018-03-22 2019-03-08 受信装置、受信方法、信号処理装置、及び信号処理方法 Active JP7264872B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2018054227 2018-03-22
JP2018054227 2018-03-22
PCT/JP2019/009266 WO2019181552A1 (ja) 2018-03-22 2019-03-08 受信装置、受信方法、信号処理装置、及び信号処理方法

Publications (2)

Publication Number Publication Date
JPWO2019181552A1 JPWO2019181552A1 (ja) 2021-04-15
JP7264872B2 true JP7264872B2 (ja) 2023-04-25

Family

ID=67987081

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2020508190A Active JP7264872B2 (ja) 2018-03-22 2019-03-08 受信装置、受信方法、信号処理装置、及び信号処理方法

Country Status (8)

Country Link
US (2) US11889161B2 (ja)
JP (1) JP7264872B2 (ja)
KR (1) KR20200131238A (ja)
CN (1) CN111869227B (ja)
BR (1) BR112020018802A2 (ja)
CA (1) CA3094045A1 (ja)
MX (1) MX2020009565A (ja)
WO (1) WO2019181552A1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024090194A1 (ja) * 2022-10-24 2024-05-02 ソニーグループ株式会社 送信装置、送信方法、受信装置、及び、受信方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011239296A (ja) 2010-05-12 2011-11-24 Sony Corp 受信装置、報知制御方法、およびプログラム
JP2012156606A (ja) 2011-01-24 2012-08-16 Hitachi Consumer Electronics Co Ltd デジタル放送受信装置およびデジタル放送受信方法、並びに、デジタル放送送信装置およびデジタル放送送信方法
JP2013005053A (ja) 2011-06-13 2013-01-07 Casio Comput Co Ltd 受信装置、および、プログラム
US20140059594A1 (en) 2012-08-24 2014-02-27 General Instrument Corporation Processing emergency alert system messages
US20150016453A1 (en) 2013-07-15 2015-01-15 Lg Electronics Inc. Apparatus for transmitting broadcast signals, apparatus for receiving broadcast signals, method for transmitting broadcast signals and method for receiving broadcast signals

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100506524B1 (ko) * 2003-07-18 2005-08-03 삼성전자주식회사 오픈 케이블에서 아웃-오브-밴드 채널 정보를 표시하는 방법
KR101108053B1 (ko) * 2005-10-21 2012-02-06 엘지전자 주식회사 지상파 방송의 비상 사태 채널 설정 방법, 데이터 구조 및이를 위한 방송 수신기
KR101227484B1 (ko) * 2005-11-16 2013-01-29 엘지전자 주식회사 양방향 케이블 디지털 방송의 비상 사태 경보 메시지 처리방법, 데이터 구조 및 이를 위한 방송 수신기
KR20080066423A (ko) 2007-01-12 2008-07-16 엘지전자 주식회사 방송 시스템 및 긴급 경고 처리 방법
US8832731B1 (en) * 2007-04-03 2014-09-09 At&T Mobility Ii Llc Multiple language emergency alert system message
KR20090039060A (ko) * 2007-10-17 2009-04-22 엘지전자 주식회사 방송 시스템 및 긴급 경고 메시지 처리 방법
EP3035672B1 (en) * 2013-08-12 2019-04-17 LG Electronics Inc. Broadcast signal transmitting apparatus, broadcast signal receiving method, broadcast signal transmitting method, and broadcast signal receiving method.
JP2015061195A (ja) 2013-09-18 2015-03-30 ソニー株式会社 送信装置及び送信方法、受信装置及び受信方法、並びにコンピューター・プログラム
EP3171534A4 (en) 2014-07-17 2018-03-21 LG Electronics Inc. Broadcast transmission device, method by which broadcast transmission device processes data, broadcast reception device and method by which broadcast reception device processes data
US10498792B2 (en) * 2015-05-17 2019-12-03 Lg Electronics Inc. Apparatus and method for transmitting or receiving broadcast signal
TW201725878A (zh) 2015-09-14 2017-07-16 Sony Corp 受訊裝置、送訊裝置及資料處理方法
EP3432618A1 (en) * 2017-07-18 2019-01-23 Thomson Licensing Emergency alert relaying using short range access communication devices

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011239296A (ja) 2010-05-12 2011-11-24 Sony Corp 受信装置、報知制御方法、およびプログラム
JP2012156606A (ja) 2011-01-24 2012-08-16 Hitachi Consumer Electronics Co Ltd デジタル放送受信装置およびデジタル放送受信方法、並びに、デジタル放送送信装置およびデジタル放送送信方法
JP2013005053A (ja) 2011-06-13 2013-01-07 Casio Comput Co Ltd 受信装置、および、プログラム
US20140059594A1 (en) 2012-08-24 2014-02-27 General Instrument Corporation Processing emergency alert system messages
US20150016453A1 (en) 2013-07-15 2015-01-15 Lg Electronics Inc. Apparatus for transmitting broadcast signals, apparatus for receiving broadcast signals, method for transmitting broadcast signals and method for receiving broadcast signals

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ATSC Standard: Signaling, Delivery, Synchronization, and Error Protection，Doc. A/331:2017，Advanced Television Systems Committee，2017年12月06日，p.180-188，[retrieved on 2019.04.10], Retrieved from the Internet: https://www.atsc.org/wp-content/uploads/2017/12/A331-2017-Signaling-Deivery-Sync-FEC-1.pdf

Also Published As

Publication number Publication date
BR112020018802A2 (pt) 2020-10-20
CA3094045A1 (en) 2019-09-26
WO2019181552A1 (ja) 2019-09-26
JPWO2019181552A1 (ja) 2021-04-15
CN111869227A (zh) 2020-10-30
US20210377621A1 (en) 2021-12-02
MX2020009565A (es) 2020-10-05
CN111869227B (zh) 2024-01-02
KR20200131238A (ko) 2020-11-23
US20240171828A1 (en) 2024-05-23
US11889161B2 (en) 2024-01-30

Similar Documents

Publication Publication Date Title
US10623827B2 (en) Receiving device, receiving method, transmitting device, and transmitting method
CN101159577B (zh) 接收自适应广播信号的装置及其方法
JP6276593B2 (ja) 受信装置、受信方法、及びプログラム
JP5586770B2 (ja) 受信機
CN101217642B (zh) 发送预览内容的方法和接收预览内容的方法与装置
KR102438011B1 (ko) 수신 장치 및 데이터 처리 방법
CN103081507B (zh) 集成并处理到视频流中相关视频内容的嵌入式链接以提供广告信息
EP2750309A1 (en) Receiver and reception method
KR102506963B1 (ko) 수신 장치, 송신 장치, 및 데이터 처리 방법
JP6617712B2 (ja) 受信装置、受信方法、送信装置、及び、送信方法
US11115335B2 (en) Information processing device and information processing method
CN101232613B (zh) 发送/接收数字内容的方法和接收数字内容的装置
US20240179100A1 (en) Transmission device, transmission method, reception device, and reception method
US20240171828A1 (en) Receiving device, receiving method, signal processing device, and signal processing method
WO2017047397A1 (ja) 受信装置、送信装置、及び、データ処理方法
JP6630570B2 (ja) 受信装置、及び、受信方法
US9197937B1 (en) Automatic on-demand navigation based on meta-data broadcast with media content
US9628743B2 (en) Method and device for data processing, and system comprising the device
CN101257612B (zh) Iptv接收器和在iptv接收器中处理分级信息的方法
US10972205B2 (en) Reception apparatus, transmission apparatus, and data processing method
JP5584729B2 (ja) 放送通信連携受信装置

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20220303

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20220927

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20221108

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230125

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20230322

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20230413

R150 Certificate of patent or registration of utility model

Ref document number: 7264872

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150