TW201725878A - 受訊裝置、送訊裝置及資料處理方法 - Google Patents

受訊裝置、送訊裝置及資料處理方法 Download PDF

Info

Publication number
TW201725878A
TW201725878A TW105127700A TW105127700A TW201725878A TW 201725878 A TW201725878 A TW 201725878A TW 105127700 A TW105127700 A TW 105127700A TW 105127700 A TW105127700 A TW 105127700A TW 201725878 A TW201725878 A TW 201725878A
Authority
TW
Taiwan
Prior art keywords
information
emergency
application
eaa
emergency alert
Prior art date
Application number
TW105127700A
Other languages
English (en)
Inventor
Jun Kitahara
Naohisa Kitazato
Yasuaki Yamagishi
Taketoshi Yamane
Original Assignee
Sony 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 filed Critical Sony Corp
Publication of TW201725878A publication Critical patent/TW201725878A/zh

Links

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
    • G08B25/00—Alarm systems in which the location of the alarm condition is signalled to a central station, e.g. fire or police telegraphic systems
    • G08B25/01—Alarm systems in which the location of the alarm condition is signalled to a central station, e.g. fire or police telegraphic systems characterised by the transmission medium
    • G08B25/08—Alarm systems in which the location of the alarm condition is signalled to a central station, e.g. fire or police telegraphic systems characterised by the transmission medium using communication transmission lines
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/28—Arrangements for simultaneous broadcast of plural pieces of information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/09—Arrangements for device control with a direct linkage to broadcast information or to broadcast space-time; Arrangements for control of broadcast-related services
    • H04H60/13—Arrangements for device control affected by the broadcast information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/76—Arrangements characterised by transmission systems other than for broadcast, e.g. the Internet
    • H04H60/81—Arrangements characterised by transmission systems other than for broadcast, e.g. the Internet characterised by the transmission system itself
    • H04H60/82—Arrangements characterised by transmission systems other than for broadcast, e.g. the Internet characterised by the transmission system itself the transmission system being the Internet
    • 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/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • 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/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/86—Arrangements characterised by the broadcast information itself
    • H04H20/91—Arrangements characterised by the broadcast information itself broadcasting computer programmes

Landscapes

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

Abstract

本技術，係有關於構成為能夠提供在緊急時所被通知的緊急資訊之詳細資訊之受訊裝置、送訊裝置以及資料處理方法。受訊裝置，係受訊數位播送訊號，並基於控制資訊，來進行關連於提示緊急資訊之詳細資訊的緊急資訊應用程式之處理，該控制資訊，係為在數位播送訊號中所包含之控制資訊，並包含關連於有必要緊急進行通知之緊急資訊的詳細資訊之資訊。本技術，例如係可對於電視受像機作適用。

Description

受訊裝置、送訊裝置及資料處理方法
本技術，係有關於受訊裝置、送訊裝置以及資料處理方法，特別是有關於構成為能夠提供在緊急時所被通知的緊急資訊之詳細資訊之受訊裝置、送訊裝置以及資料處理方法。
在數位播送的技術領域中，係進行有為了於緊急時將身為有必要緊急進行告知的資訊之緊急資訊作通知的各種之提案(例如，參考專利文獻1)。
[先行技術文獻] [專利文獻]
[專利文獻1]日本特開2015-104055號公報
另外，作為在緊急時所被通知之緊急資訊，係對於用以成為能夠除了文本等之簡易性的資訊以外亦提 供像是靜止像或動畫等之更為詳細的資訊之提案有所需求。
本技術，係為有鑑於此種狀況而進行者，並為構成為能夠提供在緊急時所被通知的緊急資訊之詳細資訊者。
本技術之第1側面之受訊裝置，其特徵為，係具備有：受訊部，係受訊數位播送訊號；和處理部，係基於控制資訊，來進行關連於提示緊急資訊之詳細資訊的緊急資訊應用程式之處理，該控制資訊，係為在前述數位播送訊號中所包含之控制資訊，並包含關連於有必要緊急進行通知之緊急資訊的詳細資訊之資訊。
本技術之第1側面之受訊裝置，係可為獨立之裝置，亦可為構成1個裝置的內部區塊。又，本技術之第1側面之資料處理方法，係為對應於上述之本技術之第1側面之受訊裝置的資料處理方法。
在本技術之第1側面之受訊裝置以及資料處理方法中，係受訊數位播送訊號，並基於控制資訊，來進行關連於提示緊急資訊之詳細資訊的緊急資訊應用程式之處理，該控制資訊，係為在前述數位播送訊號中所包含之控制資訊，並包含關連於有必要緊急進行通知之緊急資訊的詳細資訊之資訊。
本技術之第2側面之送訊裝置，其特徵為， 係具備有：產生部，係產生控制資訊，該控制資訊，係包含關連於有必要緊急進行通知之緊急資訊的詳細資訊之資訊，並被使用在關連於提示前述緊急資訊之詳細資訊的緊急資訊應用程式之處理中；和送訊部，係將所產生了的前述控制資訊，包含於數位播送訊號中並進行送訊。
本技術之第2側面之送訊裝置，係可為獨立之裝置，亦可為構成1個裝置的內部區塊。又，本技術之第2側面之資料處理方法，係為對應於上述之本技術之第2側面之送訊裝置的資料處理方法。
在本技術之第2側面之送訊裝置以及資料處理方法中，係產生控制資訊，該控制資訊，係包含關連於有必要緊急進行通知之緊急資訊的詳細資訊之資訊，並被使用在關連於提示前述緊急資訊之詳細資訊的緊急資訊應用程式之處理中，將所產生了的前述控制資訊，包含於數位播送訊號中並進行送訊。
若依據本技術之第1側面以及第2側面，則係能夠提供在緊急時所被通知的緊急資訊之詳細資訊。
另外，於此所記載之效果，係並不被作限定，而可為在本揭示中所記載之任一之效果。
1‧‧‧傳輸系統
10-1、10-2、10‧‧‧送訊裝置
20、20-1、20-2、20-3‧‧‧受訊裝置
30‧‧‧電波塔
40‧‧‧EA伺服器
80‧‧‧傳輸路徑
90‧‧‧通訊線路
101‧‧‧EA剖析器
102‧‧‧直播內容取得部
103‧‧‧儲存設備
104‧‧‧組件處理部
105‧‧‧訊令處理部
106‧‧‧LCC處理部
107‧‧‧編碼器
108‧‧‧多工器
109‧‧‧調變部
110‧‧‧RF部
201‧‧‧RF部
202‧‧‧解調部
203‧‧‧處理部
204‧‧‧輸出部
205‧‧‧通訊I/F
211‧‧‧FW/HW部
212‧‧‧組件處理部
213‧‧‧MW部
214‧‧‧瀏覽器
221‧‧‧解多工器
222‧‧‧解碼器
231‧‧‧剖析器
232‧‧‧濾波器
251‧‧‧播送、通訊I/F
252‧‧‧應用程式實行環境/中間軟體
900‧‧‧電腦
901‧‧‧CPU
[圖1]係為對於適用有本技術之傳輸系統的其中一種實施形態之構成作展示之圖。
[圖2]係為對於圖1之傳輸系統的各裝置之概要作展示之圖。
[圖3]係為對於當採用了IP傳輸方式之數位播送的情況時之緊急警報之傳輸方式的概要作展示之圖。
[圖4]係為對於LLS表之語法(syntax)之例作展示之圖。
[圖5]係為對於緊急警報應用程式(EAA)的啟動方式之例作展示之圖。
[圖6]係為對於在第1方式中之緊急警報的受訊時之畫面變遷作示意性展示之圖。
[圖7]係為對於在第2方式中之緊急警報的受訊時之畫面變遷作示意性展示之圖。
[圖8]係為對於在第3方式A中之緊急警報的受訊時之畫面變遷作示意性展示之圖。
[圖9]係為對於在第3方式B中之緊急警報的受訊時之畫面變遷作示意性展示之圖。
[圖10]係為對於E-AIT之語法之例作展示之圖。
[圖11]係為對於MPD之記述例作展示之圖。
[圖12]係為對於MPD之EventStream要素的構造之例作展示之圖。
[圖13]係為對於EventStream要素之第1具體例作展示之圖。
[圖14]係為對於EventStream要素之第2具體例作展示之圖。
[圖15]係為對於EventStream要素之第3具體例作展示之圖。
[圖16]係為對於DASH區段(DASH segment)之事件訊息盒的構造之例作展示之圖。
[圖17]係為對於事件訊息盒的第1具體例作展示之圖。
[圖18]係為對於事件訊息盒的第2具體例作展示之圖。
[圖19]係為對於傳輸系統的各裝置之構成例作展示之圖。
[圖20]係為對於HTML5應用程式(BCA、EAA)的啟動序列之例作展示之圖。
[圖21]係為對於送訊處理的流程作說明之流程圖。
[圖22]係為對於電源OFF、待機狀態時之受訊處理的流程作說明之流程圖。
[圖23]係為對於電源OFF狀態時之受訊處理的流程作說明之流程圖。
[圖24]係為對於播送串流受訊處理的流程作說明之流程圖。
[圖25]係為對於第1方式之E-AIT受訊處理的流程作說明之流程圖。
[圖26]係為對於第2方式與第3方式之E-AIT受訊 處理的流程作說明之流程圖。
[圖27]係為對於E-AIT受訊處理的流程作說明之流程圖。
[圖28]係為對於事件處理的流程作說明之流程圖。
[圖29]係為對於電腦的構成例作展示之圖。
以下，參考圖面，對本技術之實施形態作說明。另外，係依照以下之順序而進行說明。
1.適用有本技術之傳輸系統的運用
2.各裝置之構成
3.藉由各裝置所實行的處理之流程
4.變形例
5.電腦之構成
<1.適用有本技術之傳輸系統的運用> (傳輸系統之構成例)
圖1，係為對於適用有本技術之傳輸系統的其中一種實施形態之構成作展示之圖。另外，系統，係指複數之裝置作了邏輯性之集合者。
在傳輸系統1中，各播送台(Broadcaster)，係設置有送訊裝置10(例如，送訊裝置10-1和送訊裝置10-2)。送訊裝置10，係將包含有播送節目等之內容的播 送串流，作為數位播送訊號而送訊。
從送訊裝置10而來之數位播送訊號，係經由電波塔30等，而透過傳輸路徑80來藉由受訊裝置20所受訊。受訊裝置20，係為固定受訊機(例如，受訊裝置20-1)或行動受訊機(例如，受訊裝置20-2和受訊裝置20-3)。受訊裝置20，係對於從數位播送訊號所得到的播送串流進行處理，而播放播送節目等之內容的影像和聲音。
又，在圖1中，傳輸系統1，係包含有與在美國所建構的被稱作EAS(Emergency Alerting System)之緊急告知的系統相對應之構成，在緊急時，各播送局等係成為對於受訊裝置20而提供(通知)身為有必要緊急進行告知的資訊之緊急資訊(緊急警報資訊)。
具體而言，在傳輸系統1處，於緊急時，係將從美國聯邦緊急事務管理署(FEMA：Federal Emergency Management Agency)或總統官邸(政府)等之緊急資訊來源所通知的緊急資訊來源資訊(例如在災害時所發行的緊急警報等)，轉換為CAP資訊，並提供至各播送局(之送訊裝置10)處。
另外，CAP資訊，係成為準據於由資訊標準架構促進會(OASIS：Organization for the Advancement of Structured Information Standards)所規定之CAP(Common Alerting Protocol)者。亦即是，在美國，由於係整備有被稱作EAS之緊急告知的系統，因此，利用此 EAS，係成為藉由各種的媒體(例如經由播送或者是經由通訊)來將從起源於總統的最優先事項起乃至於地區性之告知事項等的各種等級之緊急資訊(CAP資訊)作告知(通知)。
播送台(之送訊裝置10)，例如，係藉由基於與從緊急資訊來源而來之緊急資訊來源資訊相對應的CAP資訊之解析結果，來例如在播送節目的影像(非壓縮之視訊資料)中，將緊急警報訊息(緊急警報)嵌入並進行編碼，而產生包含緊急警報訊息之內容。之後，播送台(之送訊裝置10)，係將包含緊急警報訊息之內容，對於播送區域內之多數的受訊裝置20(例如，受訊裝置20-1~20-3)而進行送訊。
藉由此，在受訊裝置20處，係成為在播送節目的影像上重疊顯示有緊急警報訊息(緊急警報)。其結果，使用者，係能夠對於被顯示在受訊裝置20之畫面上的緊急警報訊息(緊急警報)作確認。
又，播送台(之送訊裝置10)，係產生提示緊急警報之詳細的資訊(以下，亦稱作緊急詳細資訊)之緊急警報應用程式(EAA)，並對於播送區域內之多數的受訊裝置20(例如，受訊裝置20-1~20-3)而進行送訊。
亦即是，作為緊急資訊之緊急警報(緊急警報資訊)，係被分類為緊急警報訊息(Universal Alert)和進階內容(Advanced Content)的2種，對於先行顯示 的緊急警報訊息(之文本資訊)有所關心的使用者，係成為使進階內容(之緊急詳細資訊)作顯示並進行確認。
在以下之說明中，作為緊急警報訊息(Universal Alert)之其中一例，係將播送台(之送訊裝置10)藉由將與緊急資訊來源資訊相對應的CAP資訊嵌入至播送節目等之內容的影像(非壓縮之視訊資料)中並進行編碼一事而與內容之影像作重疊顯示的緊急警報訊息，稱作嵌入文本來作說明。又，此嵌入文本，係亦被記述為「burn-in text」。
又，進階內容(Advanced Content)，係藉由靜止像或動畫等之豐富媒體(Rich Media)，來提示緊急詳細資訊。在以下之說明中，作為此進階內容的其中一例，將藉由HTML5(HyperText Markup Language 5)所開發的能夠提示緊急詳細資訊之應用程式，稱作緊急警報應用程式(EAA：Emergency Alert Application)來作說明。另外，緊急警報應用程式(EAA)係亦可構成為由美國聯邦緊急事務管理署(FEMA))或政府等之發佈緊急資訊來源資訊的機關(EA Authority)來產生，並提供給播送台(之送訊裝置10)等的緊急警報資訊之配送者。
另外，在以下之說明中，係將適合於通常的播送服務之以HTML5所開發的應用程式，稱作播送應用程式(BCA：Broadcast Application)，來與緊急警報應用程式(EAA)作區分。但是，當並不需要特別對於緊急警報應用程式(EAA)和播送應用程式(BCA)作區分 時，係亦將該些稱為HTML5應用程式(HTML5 APP)。
又，作為用以控制HTML5應用程式之資訊，雖係可使用AIT(Application Information Table)，但是，係將在緊急警報應用程式(EAA)之控制中所使用的AIT，稱作E-AIT(Emergency-AIT)，而與在播送應用程式(BCA)之控制中所使用的AIT作區別。另外，E-AIT，係為將AIT作了擴張者。
另外，詳細內容雖係於後再述，但是，藉由此E-AIT，緊急警報應用程式(EAA)之從啟動起直到結束為止的生命周期(Lifecycle)係被作控制。又，在E-AIT中，係亦包含有關連於緊急警報(之詳細資訊)的資訊。進而，藉由對於事件訊息作利用，係亦能夠實行關連於緊急警報應用程式(EAA)之各種的處理，但是，針對其之詳細內容，係於後再述。
回到圖1之說明，播送台(之送訊裝置10)，係能夠將緊急資訊應用程式(EAA)提供至EA伺服器40處。EA伺服器40，係進行從播送台(之送訊裝置10)所提供而來的緊急資訊應用程式(EAA)之配送。
受訊裝置20，當具備有通訊功能的情況時，係能夠經由網際網路或行動電話網路等之通訊線路90來對於EA伺服器40進行存取，並要求緊急警報應用程式(EAA)。之後，受訊裝置20，係能夠透過通訊線路90，來受訊從EA伺服器40所配送的緊急警報應用程式(EAA)並實行(啟動)之。藉由此，在受訊裝置20之 畫面處，係成為顯示有緊急詳細資訊。
另外，在圖1中，當作為固定受訊機之受訊裝置20-1和作為行動受訊機之受訊裝置20-2與受訊裝置20-3為被與同一之家庭網路(家庭內LAN(Local Area Network))作連接的情況時，例如，受訊裝置20-1，係亦可構成為將從播送台(之送訊裝置10)所受訊了的緊急警報資訊(例如緊急警報應用程式(EAA))等送訊(轉送)至受訊裝置20-2或受訊裝置20-3處。藉由此，例如，作為行動受訊機之受訊裝置20-2與受訊裝置20-3，就算是在並不具備有播送功能的情況時，亦成為能夠受訊從作為固定受訊機之受訊裝置20-1所送訊而來的緊急警報資訊並作顯示。
(各裝置之概要)
圖2，係為對於圖1之傳輸系統1的各裝置之概要作展示之圖。
在圖2中，送訊裝置10，例如，係將從轉播場所所透過傳輸路徑或通訊線路而送來的直播內容(例如，體育轉播等之現場播送節目)或者是被積蓄在儲存設備中之已完成收錄之內容(例如，連續劇等之事先收錄節目)等的播送節目，作為數位播送訊號而送訊。
於此，在緊急時，送訊裝置10，係取得從緊急資訊來源(EA Authority)所通知而來之作為緊急資訊來源資訊之CAP資訊，並將與該CAP資訊之解析結果相 對應的緊急警報訊息(Universal Alert)，嵌入至播送節目的影像(非壓縮之視訊資料)中並進行編碼。但是，在緊急時，係成為亦藉由視覺障礙者用之蜂鳴訊號(tone signal)或副聲道聲音等，來配送視覺障礙者用之聲音(Universal Alert)。
又，送訊裝置10，係產生與CAP訊號之解析結果相對應的E-AIT。在此E-AIT中，係包含有關連於緊急警報(之詳細資訊)的資訊、和緊急警報應用程式(EAA)之控制資訊等。進而，送訊裝置10，係基於CAP資訊之解析結果，來作為LCC內容，而產生身為進階內容(Advanced Content)之緊急警報應用程式(EAA)。
又，在緊急時，包含緊急警報訊息之播送節目等的內容、包含E-AIT之訊令、以及包含緊急警報應用程式(EAA)之LCC內容的串流，係被多工化，並作為數位播送訊號而被送訊。
另外，在圖2中，為了便於說明，係針對在播送局(Broadcaster)處所設置的裝置為藉由送訊裝置10、亦即是藉由1個的裝置來構成的情況，而作了例示，但是，係亦可作為由複數之裝置所成的送訊系統，而構成之。
又，在圖2中，受訊裝置20，係受訊從送訊裝置10而經由傳輸路徑80所送訊而來之數位播送訊號。受訊裝置20，係對於從數位播送訊號所得到的播送串流 進行處理，而播放播送節目等之內容的影像和聲音。
於此，在緊急時，由於在播送節目等之內容的影像(非壓縮之視訊資料)中，係被嵌入有作為緊急警報訊息(Universal Alert)之嵌入文本(burned-in text)，因此，在受訊裝置20之畫面中，係與播送節目播送之影像相重疊地而顯示有嵌入文本(burned-in text)(圖中之「1. burned-in text & audio」)。但是，在緊急時，由於係成為亦藉由視覺障礙者用之蜂鳴訊號或副聲道聲音等，來配送視覺障礙者用之聲音(Universal Alert)，因此，係能夠將此聲音輸出。
又，在緊急時，作為訊令，由於E-AIT係被傳輸而來，因此，在受訊裝置20處，該E-AIT係被作解析，並基於該解析結果，來判定是否要進行緊急詳細資訊之顯示、亦即是判定是否要啟動身為進階內容(Advanced Content)之緊急警報應用程式(EAA)。之後，受訊裝置20，當判定要啟動緊急警報應用程式(EAA)的情況時，係取得作為LCC內容所被傳輸而來之緊急警報應用程式(EAA)並啟動之。藉由此，在受訊裝置20之畫面中，係與播送節目之影像相重疊地，而顯示有由緊急警報應用程式(EAA)所致之緊急詳細資訊、以及嵌入文本(burned-in text)(圖中之「2. burned-in text & audio & APP」)。但是，由緊急警報應用程式(EAA)所致之緊急詳細資訊，係亦可構成為被作全畫面顯示(圖中之「3. HTML5 Application」)。
另外，送訊裝置10，係亦可構成為將緊急資訊應用程式(EAA)提供至EA伺服器40處。於此情況，受訊裝置20，係能夠透過網際網路等之通訊線路90，來受訊從EA伺服器40所配送的緊急警報應用程式(EAA)並啟動之。又，詳細內容雖係於後再述，但是，係亦可利用在MPD(Media Presentation Description)之事件串流要素(圖中之「MPD」)或DASH(Dynamic Adaptive Streaming over HTTP)區段之事件訊息盒(圖中之「’emsg’box」)等之中所配置的事件訊息(Event Message)，來進行關連於緊急警報應用程式(EAA)之處理(圖中之「Event」)。但是，如同後述一般，作為傳送通訊協定，當使用MMT(MPEG Media Transport)的情況時，代替MPD之事件串流要素，係可在MMT訊令中，嵌入與MPD之事件串流要素相同的資訊，或者是作為獨立之訊令的資料，而將同樣的資訊作通知。
以上，係針對圖1之傳輸系統1的各裝置之概要作了說明。
(IP傳輸方式之緊急資訊之傳輸方式)
圖3，係為對於當採用了IP傳輸方式之數位播送的情況時之緊急警報之傳輸方式的概要作展示之圖。
另外，在各國之數位播送的規格中，作為傳輸方式，係採用有MPEG2-TS(Moving Picture Experts Group phase 2-Transport Stream)方式，但是，今後，可 以推測到，係會藉由導入將在通訊之領域中所使用的IP(Internet Protocol)封包使用於數位播送中的IP傳輸方式，來提供更高度化的服務。
特別是，在身為現在持續進行策劃的美國之下一世代播送規格之ATSC(Advanced Television Systems Committee)3.0中，係已決定要採用使用有IP傳輸方式之數位播送。例如，在圖1之傳輸系統1中，在送訊裝置10和受訊裝置20處，係可構成為透過傳輸路徑80而進行準據於ATSC3.0之資料傳輸。
在圖3中，於左側所示之管狀圖，係代表IP傳輸方式之數位播送的系統管狀模式。在此系統管狀模式中，於特定之頻率帶域(例如6MHz)之播送串流(Broadcast Stream)中，係包含有1或複數之PLP串流(PLP Stream)。又，在各PLP串流中，係包含有各訊令(signaling)或各服務(service)之串流。
另外，特定之頻率帶域之播送串流，係藉由播送串流ID(Broadcast Stream ID)來作辨識。又，各PLP串流，係藉由PLP ID來作辨識。進而，各服務，係藉由服務ID(Service ID)來作辨識。
於此，LLS(Link Layer Signaling)訊令，係被儲存在IP/UDP封包中而被作傳輸。LLS訊令，係為先於SLS(Service Layer Signaling)訊令之前所被取得的訊令，依據LLS訊令之資訊，SLS訊令係被取得。
作為此LLS訊令，例如，係包含有SLT (Service List Table)或RRT(Region Rating Table)、E-AIT(Emergency Alerting Table)等之後設資料。SLT後設資料，係包含有像是在服務之選台中所必要的資訊(選台資訊)等的代表播送網路中之串流或服務之構成的資訊。RRT後設資料，係包含有關於分級之資訊。E-AIT後設資料(以下，係記述為E-AIT)，係包含有緊急警報應用程式(EAA)之控制資訊和關連於緊急警報(之詳細資訊)的資訊。
另外，SLT、RRT或E-AIT等之後設資料，係藉由XML(Extensible Markup Language)等之標示語言(markup language)而被作記述。
又，各服務之串流，係藉由ROUTE(Real-Time Object Delivery over Unidirectional Transport)會談(session)而被傳輸。於此，所謂ROUTE，係為適合於將檔案以單方向來進行多撥(multicast)傳輸的協定，並為將FLUTE(File Delivery over Unidirectional Transport)作了擴張的協定。在各服務之串流中，藉由ROUTE會談，SLS訊令或組件(Component)、LCC(Locally Cached Content)內容之串流係被作傳輸。
作為此SLS訊令，例如，係包含有USD(User Service Description)、S-TSID(Service-based Transport Session Instance Description)、MPD(Media Presentation Description)等的後設資料。USD後設資料，係包含有其他之後設資料的取得目標等之資訊。S- TSID後設資料，係為將LSID(LCT Session Instance Description)適應於ATSC3.0所作了擴張者，並為ROUTE通訊協定之控制資訊。MPD後設資料(以下，係記述為MPD)，係為用以對於組件之串流的播放作管理之控制資訊。
另外，USD、S-TSID、MPD等之後設資料，係藉由XML等之標示語言而被作記述。又，MPD後設資料，係準據於MPEG-DASH(Dynamic Adaptive Streaming over HTTP)之規格。
組件，係為構成視訊或音訊、字幕等的內容之資料。又，LCC內容，係為被積蓄(下載)於受訊裝置20之儲存設備中再被進行處理的內容。但是，在圖3之例中，作為LCC內容，係被傳輸有緊急警報應用程式(EAA)。另外，LCC，係會有被稱作NRT(Non Real Time)的情況。
另外，雖係為了使說明簡略化而有所省略，但是，在PLP串流中，係成為亦被傳輸有作為時刻資訊之NTP(Network Time Protocol)和作為電子服務導引之ESG(Electronic Service Guide)服務等的串流。
在圖3之管狀圖中，於播送串流中，係包含有成為相異之PLP ID之2個的PLP串流，但是，其中一方(圖中之上方)之PLP串流，係被設為通常之PLP串流，另外一方(圖中之下方)之PLP串流，則係被設為高穩健性(robustness)之PLP串流。
在此例中，係藉由通常之PLP串流，來傳輸服務之組件和SLS訊令，並藉由高穩健性之PLP串流，來傳輸LLS訊令和LCC內容之串流。故而，係能夠確實地傳輸LLS訊令和LCC內容。又，在此例中，LLS訊令，係在複數之服務中被共通地使用。
於此，若是對於圖中之以點線L所包圍的部份、亦即是傳輸LLS訊令之串流作注目，則在緊急時，作為LLS訊令之E-AIT，係成為如同下述一般地被傳輸。
在IP傳輸方式之通訊協定堆疊中，最下位之階層，係被設為物理層(L1：Layer1)，與此物理層相鄰接之上位之階層，係被設為Layer 2之階層(L2：Layer2)，進而，與Layer 2之階層相鄰接之上位之階層，係被設為IP層，與IP層相鄰接之上位之階層，係被設為UDP(User Datagram Protocol)層。
亦即是，如同圖3之右側之訊框(封包)的構造圖中所示一般，物理層之L1訊框(L1 Frame)，係由L1標頭和L1酬載所構成。在此L1標頭中，係包含有用以在緊急時將電源OFF並且為待機狀態之受訊裝置20啟動的喚醒旗標(wake-up flag)。又，在L1酬載中，係被配置有1或複數之ALP(ATSC Link-layer Protocol)封包。
此ALP封包，係為Layer 2之階層之傳輸封包，在其之ALP酬載中，係被配置有LLS表。亦即是，LLS表，由於係被包含於IP/UDP封包中而被傳輸，因 此，作為其之標頭，係除了LLS標頭(LLS_H)以外，亦被附加有IP標頭(IP_H)和UDP標頭(UDP_H)。又，在LLS表中，係被配置有LLS訊令之資料，亦即是，在此例中，係被配置有E-AIT。
於此，在圖4中，係對於LLS表之語法之例作展示。在圖4之LLS表中，於8位元之LLS_table_id中，係被指定有用以對於LLS表作辨識之LLS表ID。又，在8位元之LLS_table_version中，係被指定有LLS表之版本。另外，LLS_table_id和LLS_table_version，係被包含在LLS標頭之中。
又，藉由switch文，作為LLS表ID，當被指定有"0x01"的情況時，係代表作為LLS訊令之資料而被配置有SLT後設資料。又，當作為LLS表ID而被指定有"0x02"的情況時，係代表作為LLS訊令之資料而被配置有RRT後設資料，當被指定有"0x03"的情況時，係代表作為LLS訊令之資料而被配置有E-AIT。
回到圖3之說明，在LSS表中所包含之E-AIT中，係包含有緊急警報應用程式(EAA)之控制資訊和關連於緊急警報(之詳細資訊)的資訊。受訊裝置20，當受訊了E-AIT的情況時，係對於該E-AIT進行解析，並基於該解析結果，來判定是否要顯示緊急詳細資訊(是否要啟動緊急警報應用程式(EAA))。於此，例如，係可因應於使用者操作來判定是否要顯示緊急詳細資訊，或者是因應於由使用者所預先設定的設定資訊來判定 是否要顯示緊急詳細資訊。
之後，受訊裝置20，當判定要顯示緊急詳細資訊的情況時、亦即是當判定要啟動緊急警報應用程式(EAA)的情況時，係取得作為LCC內容而藉由ROUTE會談所被傳輸而來之緊急警報應用程式(EAA)並啟動之(S1)。其結果，在受訊裝置20之畫面處，係成為顯示有由緊急警報應用程式(EAA)所致之緊急詳細資訊。
又，在E-AIT中，當緊急警報應用程式(EAA)係藉由EA伺服器40而被提供的情況時，係包含有代表該EA伺服器40之URL(Uniform Resource Locator)的資訊。於此情況，受訊裝置20，係基於該E-AIT，來透過通訊線路90(Internet)而對於EA伺服器40進行存取，並要求緊急警報應用程式(EAA)(S2、S3)。之後，受訊裝置20，係受訊從EA伺服器40來透過通訊線路90所配送的緊急警報應用程式(EAA)並啟動之(S3、S2)。其結果，在受訊裝置20之畫面處，係成為顯示有由緊急警報應用程式(EAA)所致之緊急詳細資訊。
藉由此，在緊急時，不僅是能夠藉由以嵌入文本等之文字列所成的緊急警報訊息(Universal Alert)來提示簡易的資訊，亦能夠針對關心該資訊之使用者，而藉由作為進階內容(Advanced Content)之緊急警報應用程式(EAA)，來例如提示包含有靜止像或動畫等之緊急詳細資訊。
另外，在圖3之例中，作為傳送層(Transport layer)之傳輸通訊協定(傳送通訊協定)，雖係針對使用ROUTE的情況來作了說明，但是，係亦可構成為使用其他的傳送通訊協定。例如，在現今所規劃中之ATSC3.0中，作為傳送通訊協定，係對於ROUTE與MMT(MPEG Media Transport)之併存有所考慮，但是，除了ROUTE會談以外，係亦可構成為使用MMT會談來傳輸組件或訊令之串流。
如同上述一般，在ATSC3.0等之IP傳輸方式之數位播送中，當作為傳送通訊協定而使用有ROUTE或MMT的情況時，於緊急時，係能夠將與從緊急資訊來源(例如美國聯邦緊急事務管理署(FEMA))而來之緊急資訊來源資訊(例如在災害時所發行的緊急警報等)相對應之緊急資訊(緊急警報)，對於受訊裝置20作提供(通知)。
(緊急警報應用程式(EAA)的啟動方式)
另外，在對於播送應用程式(BCA)和緊急警報應用程式(EAA)作比較的情況時，於緊急時所被啟動的緊急警報應用程式(EAA)，相較於在通常時所被啟動的播送應用程式(BCA)，啟動之優先度係變高。故而，在啟動緊急警報應用程式(EAA)的情況時，當播送應用程式(BCA)正被啟動時，係有必要構成為使由緊急警報應用程式(EAA)所致之緊急詳細資訊被優先性地作顯示。
作為此種優先啟動之解決方案，例如，在受訊裝置20處，係能夠啟動緊急警報應用程式(EAA)，並藉由該緊急警報應用程式(EAA)，來判定是否要進行緊急詳細資訊之顯示，但是，若是身為播送應用程式(BCA)已被作了啟動的狀態，則係成為先使啟動中之播送應用程式(BCA)暫時停止或者是結束，之後再啟動緊急警報應用程式(EAA)，並判定是否要進行緊急詳細資訊之顯示。
又，在有必要進行緊急詳細資訊之顯示的情況時，係只要藉由啟動中之緊急警報應用程式(EAA)來顯示緊急詳細資訊即可，但是，另一方面，當成為不需要進行緊急詳細資訊之顯示的情況時，係成為先使緊急警報應用程式(EAA)結束，之後再度使播送應用程式(BCA)之實行再度開始或者是啟動。亦即是，在受訊裝置20處，就算是在能夠啟動緊急警報應用程式(EAA)的情況時，依存於使用者，例如也會有僅需要緊急警報訊息(嵌入文本)便已充分，而並不需要對象之緊急詳細資訊的情況，於此種情況中，係並不需要使緊急警報應用程式(EAA)啟動。
因此，在本技術中，係藉由在將AIT作了擴張的E-AIT中，除了緊急警報應用程式(EAA)的控制資訊以外，亦包含有關連於緊急警報(之詳細資訊)的資訊，來構成為使受訊裝置20，因應於該E-AIT之解析結果，而判定是否要進行緊急詳細資訊之顯示，並僅當使緊 急詳細資訊作顯示的情況時，才啟動緊急警報應用程式(EAA)。或者是，在本技術中，係構成為藉由在E-AIT中包含CAP資訊，來使緊急警報應用程式(EAA)能夠直接接收CAP資訊並進行處理。又，在受訊裝置20處，於緊急警報應用程式(EAA)之啟動時，當播送應用程式(BCA)正被啟動的情況時，係構成為使播送應用程式(BCA)暫時停止或者是結束，並優先性地啟動緊急警報應用程式(EAA)。
於此，作為判定是否要啟動緊急警報應用程式(EAA)並顯示緊急詳細資訊一事之判定處理，係如同上述一般，可因應於使用者之操作，來判定是否要顯示緊急詳細資訊，亦可使受訊裝置20，因應於E-AIT之解析結果，而判定是否要進行緊急詳細資訊之顯示。
於後者的情況時，例如，受訊裝置20，係判定該視聽地區是否身為緊急警報之對象地區，當視聽地區係為緊急警報之對象地區外的情況時，並不啟動緊急警報應用程式(EAA)，而成為並不進行緊急詳細資訊之顯示。又，例如，受訊裝置20，係亦可基於使用者所預先作了登錄的設定資訊(例如，要顯示與氣象相關之資訊，但是並不顯示學校之臨時停課等之資訊，等等)，來判定是否要啟動緊急警報應用程式(EAA)。
圖5，係為對於緊急警報應用程式(EAA)的啟動方式之例作展示之圖。
如同圖5中所示一般，用以提示緊急警報之 詳細資訊(緊急詳細資訊)的緊急警報應用程式(EAA)，係可構成為藉由第1方式~第3方式之其中一者的方式而被啟動，並顯示緊急詳細資訊。但是，此些之第1方式~第3方式，係僅為緊急警報應用程式(EAA)之啟動序列的其中一例，亦可構成為藉由其他的方式，來啟動緊急警報應用程式(EAA)。
在第1方式中，係藉由常駐應用程式(RA)來啟動緊急警報應用程式(EAA)。
具體而言，在受訊裝置20處，在由使用者而對於播送節目進行視聽時，當受訊了E-AIT(autostart)的情況時，常駐應用程式(RA)，係依循該E-AIT(autostart)，而顯示代表受訊了緊急警報之詳細資訊(緊急詳細資訊)一事的圖符(EA圖符)等。之後，對於此顯示資訊(選擇資訊)作了確認的使用者，係判斷是否要顯示緊急詳細資訊，當下達了進行該顯示之指示的情況時，緊急警報應用程式(EAA)係被啟動(實行)，緊急詳細資訊係被顯示在受訊裝置20之畫面上。
之後，於受訊裝置20處，當受訊了E-AIT(terminate)的情況時，常駐應用程式(RA)，係依循該E-AIT(terminate)，而使啟動中之緊急警報應用程式(EAA)結束。藉由此，在受訊裝置20之畫面處，緊急詳細資訊之顯示係消失，並成為僅顯示有播送節目。
在第2方式中，係從播送應用程式(BCA)為未實行之狀態起，來啟動緊急警報應用程式(EAA)。
具體而言，在受訊裝置20處，在由使用者而對於播送節目進行視聽時，當受訊了E-AIT(autostart)的情況時，中間軟體(MW)或瀏覽器(BR)等，係依循該E-AIT(autostart)，而啟動(實行)緊急警報應用程式(EAA)，藉由此，緊急警報之詳細資訊(緊急詳細資訊)係被作顯示。
之後，於受訊裝置20處，當受訊了E-AIT(terminate)的情況時，中間軟體(MW)或瀏覽器(BR)等，係依循該E-AIT(terminate)，而使啟動中之緊急警報應用程式(EAA)結束。藉由此，在受訊裝置20處，緊急詳細資訊之顯示係消失，並成為僅顯示有播送節目。
在第3方式中，係從播送應用程式(BCA)正被實行之狀態起，來啟動緊急警報應用程式(EAA)。
具體而言，在受訊裝置20處，在由使用者而對於播送節目進行視聽並且播送應用程式(BCA)正被啟動時，當受訊了E-AIT(autostart)的情況時，中間軟體(MW)或瀏覽器(BR)等，係依循該E-AIT(autostart)，而啟動(實行)緊急警報應用程式(EAA)，藉由此，緊急警報之詳細資訊(緊急詳細資訊)係被作顯示。此時，啟動中之播送應用程式(BCA)，係被作暫時停止(結束)，其之影像係成為從受訊裝置20之畫面上而消失。
之後，於受訊裝置20處，當受訊了E-AIT (terminate)的情況時，中間軟體(MW)或瀏覽器(BR)等，係依循該E-AIT(terminate)，而使啟動中之緊急警報應用程式(EAA)結束。藉由此，在受訊裝置20處，緊急詳細資訊之顯示係消失，並成為顯示有播送節目。另外，當存在有暫時停止中之播送應用程式(BCA)的情況時，該播送應用程式(BCA)之實行係被再度開始，其之影像係被重疊顯示於播送節目處。
又，藉由對於事件訊息作利用，係成為能夠實行像是進行啟動中之緊急警報應用程式(EAA)的更新等之關連於緊急警報應用程式(EAA)之各種的處理。另外，在以下之說明中，係將第3方式中之對於事件訊息作了利用的情況，稱作第3方式B，以與並未利用事件訊息的情況時之第3方式A作區分。
以下，針對第1方式~第3方式之詳細內容作說明。
(1)第1方式
圖6，係為對於在第1方式中之緊急警報的受訊時之畫面變遷作示意性展示之圖。在圖6之例中，係藉由畫面D11~D15，來表現受訊裝置20之畫面的變遷，並藉由步驟S11~S15，來表現受訊裝置20之動作。另外，在圖6中，時間之方向，係設為從圖中之左側而朝向右側的方向。又，在圖6之例中，假設於時刻t1~時刻t2的期間中，係被通知有緊急警報(Emergency Alert)。另 外，常駐應用程式(RA)，係為預先被組入至受訊裝置20中的應用程式。
在較緊急警報被作通知的時刻t1而更之前的時間中，於受訊裝置20處，係在其之畫面上僅顯示有播送節目之影像，並由使用者而進行視聽(D11)。另外，於此時間點，播送應用程式(BCA)等之HTML5應用程式係並未被實行。
於此，在成為了時刻t1時，受訊裝置20，係受訊從送訊裝置10而經由傳輸路徑80所通知而來之緊急警報。之後，在受訊裝置20處，係於播送節目之影像上，被重疊顯示有嵌入文本(burned-in text)之文字列(D12)。藉由此，作為緊急警報訊息(Universal Alert)之嵌入文本的內容，係成為被使用者所確認。
又，受訊裝置20，係受訊從送訊裝置10而經由傳輸路徑80所通知而來之E-AIT(autostart)(S11)。在受訊裝置20處，常駐應用程式(RA)，係對於該E-AIT(autostart)進行解析，並將與該解析結果相對應之EA圖符顯示在畫面上(S12，D13)。藉由此EA圖符，例如，係與「存在有緊急警報之詳細資訊，要顯示嗎？」等之訊息一同地，而顯示有用以對於緊急詳細資訊之顯示作選擇的「是」按鍵和「否」按鍵。
另外，於此，係亦能夠將關連於緊急警報之緊急性或對象地區、範疇等的基於在E-AIT中所包含之資訊所得到的各種之資訊作顯示。又，常駐應用程式 (RA)，係亦可因應於設定資訊(例如顯示對象地區或顯示對象項目等之設定)，來判定是否需要進行緊急詳細資訊之顯示。
之後，在受訊裝置20處，當由使用者而對於作為EA圖符所被顯示之「是」按鍵作了選擇的情況時，緊急警報應用程式(EAA)之EAA啟動事件係被發行，緊急警報應用程式(EAA)係被啟動(S13)。其結果，在受訊裝置20之畫面中，由緊急警報應用程式(EAA)所致之緊急詳細資訊，係與嵌入文本(burned-in text)一同地而被重疊顯示於播送節目之影像上(D14)。
藉由此，在緊急時，不僅是能夠藉由以嵌入文本等之文字列所成的緊急警報訊息(Universal Alert)來提示簡易的資訊，亦能夠針對關心該資訊之使用者，而藉由作為進階內容(Advanced Content)之緊急警報應用程式(EAA)，來例如提示包含有靜止像或動畫等之緊急詳細資訊，而提供更為詳細之資訊。
之後，若是經過時刻t2，則從送訊裝置10而來之緊急警報之通知係結束。又，受訊裝置20，係受訊從送訊裝置10而經由傳輸路徑80所通知而來之E-AIT(terminate)(S14)。受訊裝置20，係對於該E-AIT(terminate)進行解析，並基於該解析結果，來使啟動中之緊急警報應用程式(EAA)結束(S15)。其結果，在受訊裝置20之畫面處，嵌入文本(burned-in text)和緊急詳細資訊(圖中之「EAA」)之顯示係消失，並成為僅 顯示有播送節目之影像(D15)。
如同上述一般，在第1方式中，常駐應用程式(RA)，係基於E-AIT(autostart)來顯示EA圖符，並且當使用者下達了緊急詳細資訊之顯示之指示的情況時，係啟動緊急警報應用程式(EAA)，並成為顯示緊急詳細資訊。藉由此，例如，由於並不需要顯示緊急詳細資訊的情況時，係並不啟動緊急警報應用程式(EAA)，而僅在有必要顯示緊急詳細資訊的情況時，才啟動緊急警報應用程式(EAA)，因此，係可藉由防止緊急警報應用程式(EAA)之無謂的啟動等而減輕在受訊裝置20處之處理的負載。又，常駐應用程式(RA)，係能夠基於E-AIT，來對於緊急警報應用程式(EAA)之生命周期(從啟動起直到結束為止的動作)作控制。
(2)第2方式
圖7，係為對於在第2方式中之緊急警報的受訊時之畫面變遷作示意性展示之圖。在圖7之例中，係藉由畫面D21~D25，來表現受訊裝置20之畫面的變遷，並藉由步驟S21~S25，來表現受訊裝置20之動作。另外，在圖7中，亦同樣的，時間之方向，係設為從圖中之左側而朝向右側的方向。又，在圖7之例中，假設於時刻t1~時刻t2的期間中，係被通知有緊急警報(Emergency Alert)。另外，中間軟體(MW)，係與後述之MW部213(圖19)相對應。又，瀏覽器(BR)，係與後述之瀏 覽器214(圖19)相對應。在此例中，雖係針對中間軟體(MW)或瀏覽器(BR)係成為處理之主體的情況作說明，但是，係亦可構成為使其他之軟體或硬體來進行處理。此些之關係，在後述之圖8以及圖9中，亦為相同。
在較緊急警報被作通知的時刻t1而更之前的時間中，於受訊裝置20處，係在其之畫面上僅顯示有播送節目之影像，並由使用者而進行視聽(D21)。另外，於此時間點，播送應用程式(BCA)等之HTML5應用程式係並未被實行。
於此，在成為了時刻t1時，受訊裝置20，係受訊從送訊裝置10而經由傳輸路徑80所通知而來之緊急警報。之後，在受訊裝置20處，係於播送節目之影像上，被重疊顯示有嵌入文本(burned-in text)之文字列(D22)。藉由此，作為緊急警報訊息(Universal Alert)之嵌入文本的內容，係成為被使用者所確認。
又，受訊裝置20，係受訊從送訊裝置10而經由傳輸路徑80所通知而來之E-AIT(autostart)(S21)。在受訊裝置20處，中間軟體(MW)或瀏覽器(BR)，係對於該E-AIT(autostart)進行解析，並因應於該解析結果，來下達緊急警報應用程式(EAA)之取得和啟動的指示(S22)。
另外，於此，中間軟體(MW)或瀏覽器(BR)，係可因應於從使用者而來之指示或者是設定資訊(例如顯示對象地區或顯示對象項目等之設定)，來判 定是否需要進行緊急詳細資訊之顯示。例如，係可作為緊急警報應用程式(EAA)之啟動畫面，而顯示代表受訊了緊急詳細資訊一事之圖符等，並當使用者判斷要顯示緊急詳細資訊並且下達了進行該顯示之指示的情況時，才顯示緊急詳細資訊。
之後，在受訊裝置20處，因應於從中間軟體(MW)或瀏覽器(BR)而來之指示(EAA啟動事件)，緊急警報應用程式(EAA)係被取得並被啟動(S23)。其結果，在受訊裝置20之畫面中，由緊急警報應用程式(EAA)所致之緊急詳細資訊，係與嵌入文本(burned-in text)一同地而被重疊顯示於播送節目之影像上(D24)。
藉由此，在緊急時，不僅是能夠藉由以嵌入文本等之文字列所成的緊急警報訊息(Universal Alert)來提示簡易的資訊，亦能夠針對關心該資訊之使用者，而藉由作為進階內容(Advanced Content)之緊急警報應用程式(EAA)，來例如提示包含有靜止像或動畫等之緊急詳細資訊，而提供更為詳細之資訊。
之後，若是經過時刻t2，則從送訊裝置10而來之緊急警報之通知係結束。又，受訊裝置20，係受訊從送訊裝置10而經由傳輸路徑80所通知而來之E-AIT(terminate)(S24)。在受訊裝置20處，中間軟體(MW)或瀏覽器(BR)，係對於該E-AIT(terminate)進行解析，並因應於該解析結果，來下達啟動中之緊急警 報應用程式(EAA)之結束的指示(S25)。
之後，在受訊裝置20處，因應於從中間軟體(MW)或瀏覽器(BR)而來之指示(EAA結束事件)，啟動中之緊急警報應用程式(EAA)係被結束(S26)。其結果，在受訊裝置20之畫面處，嵌入文本(burned-in text)和緊急詳細資訊(圖中之「EAA」)之顯示係消失，並成為僅顯示有播送節目之影像(D25)。
如同上述一般，在第2方式中，由於僅當中間軟體(MW)或瀏覽器(BR)基於E-AIT而判定要顯示緊急警報應用程式(EAA)的情況時，才會啟動緊急警報應用程式(EAA)，因此，例如，係可藉由防止緊急警報應用程式(EAA)之無謂的啟動等而減輕在受訊裝置20處之處理的負載。又，中間軟體(MW)或瀏覽器(BR)，係能夠基於E-AIT，來對於緊急警報應用程式(EAA)之生命周期(從啟動起直到結束為止的動作)作控制。
(3)第3方式A
圖8，係為對於在第3方式A中之緊急警報的受訊時之畫面變遷作示意性展示之圖。在圖8之例中，係藉由畫面D31~D35，來表現受訊裝置20之畫面的變遷，並藉由步驟S31~S39，來表現受訊裝置20之動作。另外，在圖8中，亦同樣的，時間之方向，係設為從圖中之左側而朝向右側的方向。又，在圖8之例中，於時刻t1 ~時刻t2的期間中，係被通知有緊急警報(Emergency Alert)。
在較緊急警報被作通知的時刻t1而更之前的時間中，於受訊裝置20處，係在其之畫面上僅顯示有播送節目之影像，並由使用者而進行視聽(D31)。又，受訊裝置20，係受訊有從送訊裝置10而經由傳輸路徑80所通知而來之AIT(S31)。在受訊裝置20處，中間軟體(MW)或瀏覽器(BR)，係對於該AIT進行解析，並因應於該解析結果，來下達播送應用程式(BCA)之取得和啟動的指示(S32)。
之後，在受訊裝置20處，因應於從中間軟體(MW)或瀏覽器(BR)而來之指示(BCA啟動事件)，播送應用程式(BCA)係被取得並被啟動(S33)。其結果，在受訊裝置20之畫面中，由播送應用程式(BCA)所致之資訊(例如畫像和影像、文字等)，係被重疊顯示於播送節目之影像上(D32)。
之後，在成為了時刻t1時，受訊裝置20，係受訊從送訊裝置10而經由傳輸路徑80所通知而來之緊急警報。之後，在受訊裝置20處，係與播送應用程式(BCA)之資訊一同地，而將嵌入文本(burned-in text)之文字列重疊顯示於播送結束之影像上(D33)。藉由此，作為緊急警報訊息(Universal Alert)之嵌入文本的內容，係成為被使用者所確認。
又，受訊裝置20，係受訊從送訊裝置10而經 由傳輸路徑80所通知而來之E-AIT(autostart)(S34)。在受訊裝置20處，中間軟體(MW)或瀏覽器(BR)，係對於該E-AIT(autostart)進行解析，並因應於該解析結果，來下達緊急警報應用程式(EAA)之取得和啟動的指示(S35)。
另外，於此，中間軟體(MW)或瀏覽器(BR)，係可因應於從使用者而來之指示或者是設定資訊(例如顯示對象地區或顯示對象項目等之設定)，來判定是否需要進行緊急詳細資訊之顯示。例如，係可作為緊急警報應用程式(EAA)之啟動畫面，而顯示代表受訊了緊急詳細資訊一事之圖符等，並當使用者判斷要顯示緊急詳細資訊並且下達了進行該顯示之指示的情況時，才顯示緊急詳細資訊。
之後，在受訊裝置20處，因應於從中間軟體(MW)或瀏覽器(BR)而來之指示(EAA啟動事件)，緊急警報應用程式(EAA)係被取得並被啟動(S36)。此時，啟動中之播送應用程式(BCA)，係被作暫時停止(suspend)或結束(terminate)。其結果，在受訊裝置20之畫面處，代替播送應用程式(BCA)之資訊，係成為顯示有緊急警報應用程式(EAA)之緊急詳細資訊(D34)。另外，在受訊裝置20之畫面處，嵌入文本(burned-in text)亦仍持續被重疊顯示於播送節目之影像上(D34)。
藉由此，在緊急時，不僅是能夠藉由以嵌入 文本等之文字列所成的緊急警報訊息(Universal Alert)來提示簡易的資訊，亦能夠針對關心該資訊之使用者，而藉由作為進階內容(Advanced Content)之緊急警報應用程式(EAA)，來例如提示包含有靜止像或動畫等之緊急詳細資訊，而提供更為詳細之資訊。
之後，若是經過時刻t2，則從送訊裝置10而來之緊急警報之通知係結束。又，受訊裝置20，係受訊從送訊裝置10而經由傳輸路徑80所通知而來之E-AIT(terminate)(S37)。在受訊裝置20處，中間軟體(MW)或瀏覽器(BR)，係對於該E-AIT(terminate)進行解析，並因應於該解析結果，來下達啟動中之緊急警報應用程式(EAA)之結束的指示(S38)。
之後，在受訊裝置20處，因應於從中間軟體(MW)或瀏覽器(BR)而來之指示(EAA結束事件)，啟動中之緊急警報應用程式(EAA)係被結束(S39)。又，在啟動緊急警報應用程式(EAA)時，當播送應用程式(BCA)被設為暫時停止(suspend)的情況時，該播送應用程式(BCA)之實行係被再度開始(被啟動)。其結果，在受訊裝置20之畫面處，嵌入文本(burned-in text)和緊急詳細資訊(圖中之「EAA」)之顯示係消失，播送應用程式(BCA)之資訊係被重疊顯示於播送節目之影像上(D35)。亦即是，受訊裝置20之畫面的顯示，係成為回到緊急警報被作通知之前的狀態(D32)。
另外，在啟動緊急警報應用程式(EAA) 時，當播送應用程式(BCA)被設為結束(terminate)的情況時，播送應用程式(BCA)之實行係並不會被再度開始，在受訊裝置20之畫面處，係成為僅被顯示有播送節目之影像。
如同上述一般，在第3方式A中，由於僅當中間軟體(MW)或瀏覽器(BR)基於E-AIT而判定要顯示緊急警報應用程式(EAA)的情況時，才會啟動緊急警報應用程式(EAA)，因此，例如，係可藉由防止緊急警報應用程式(EAA)之無謂的啟動等而減輕在受訊裝置20處之處理的負載。又，在第3方式A中，在啟動緊急警報應用程式(EAA)的情況時，當播送應用程式(BCA)正被啟動時，由於係先使該播送應用程式(BCA)暫時停止或者是結束，之後再啟動緊急警報應用程式(EAA)，因此，係能夠優先性地啟動緊急警報應用程式(EAA)。故而，係能夠對於使用者而確實地提示緊急詳細資訊。
(4)第3方式B：事件對應
圖9，係為對於在第3方式B中之於緊急警報的受訊時而進行事件對應的情況時之畫面變遷作示意性展示之圖。在圖9之例中，係藉由畫面D41~D45，來表現受訊裝置20之畫面的變遷，並藉由步驟S41~S49，來表現受訊裝置20之動作。另外，在圖9中，亦同樣的，時間之方向，係設為從圖中之左側而朝向右側的方向。又，在圖9之例中，於時刻t1~時刻t2的期間中，係被 通知有緊急警報(Emergency Alert)。
在較緊急警報被作通知的時刻t1而更之前的時間中，於受訊裝置20之畫面處，由播送應用程式(BCA)所致之資訊，係被重疊顯示於播送節目之影像上(D41)。另外，此播送應用程式之啟動方法，由於係與上述之第3方式A(圖8之S31~S33)相同，因此於此係省略其說明。
之後，在成為了時刻t1時，受訊裝置20，係受訊從送訊裝置10而經由傳輸路徑80所通知而來之緊急警報。其結果，在受訊裝置20之畫面處，係與播送應用程式(BCA)之資訊一同地，而將嵌入文本(burned-in text)之文字列重疊顯示於播送結束之影像上(D42)。藉由此，作為緊急警報訊息(Universal Alert)之嵌入文本的內容，係成為被使用者所確認。
又，受訊裝置20，係受訊從送訊裝置10而經由傳輸路徑80所通知而來之E-AIT(autostart)(S41)。在受訊裝置20處，中間軟體(MW)或瀏覽器(BR)，係對於該E-AIT(autostart)進行解析，並因應於該解析結果，來下達緊急警報應用程式(EAA1)之取得和啟動的指示(S42)。
另外，於此，與上述之第3方式A同樣的，係可因應於從使用者而來之指示或者是設定資訊(例如顯示對象地區或顯示對象項目等之設定)，來判定是否需要進行緊急詳細資訊之顯示。例如，係可作為緊急警報應用 程式(EAA)之啟動畫面，而顯示代表受訊了緊急詳細資訊一事之圖符等，並當使用者判斷要顯示緊急詳細資訊並且下達了進行該顯示之指示的情況時，才顯示緊急詳細資訊。
之後，在受訊裝置20處，因應於從中間軟體(MW)或瀏覽器(BR)而來之指示(EAA1啟動事件)，緊急警報應用程式(EAA1)係被取得並被啟動(S43)。此時，啟動中之播送應用程式(BCA)，係被作暫時停止(suspend)或結束(terminate)。其結果，在受訊裝置20之畫面處，代替播送應用程式(BCA)之資訊，係成為顯示有緊急警報應用程式(EAA1)之緊急詳細資訊(D43)。另外，在受訊裝置20之畫面處，嵌入文本(burned-in text)亦仍持續被重疊顯示於播送節目之影像上(D43)。
藉由此，在緊急時，不僅是能夠藉由以嵌入文本等之文字列所成的緊急警報訊息(Universal Alert)來提示簡易的資訊，亦能夠針對關心該資訊之使用者，而藉由作為進階內容(Advanced Content)之緊急警報應用程式(EAA)，來例如提示包含有靜止像或動畫等之緊急詳細資訊，而提供更為詳細之資訊。
之後，受訊裝置20，係受訊從送訊裝置10而經由傳輸路徑80所通知而來之事件訊息(S44)。在受訊裝置20處，中間軟體(MW)或瀏覽器(BR)，係對於該事件訊息進行解析，並因應於該解析結果，來下達從緊 急警報應用程式(EAA1)而變遷至緊急警報應用程式(EAA2)之指示(S45)。亦即是，中間軟體(MW)或瀏覽器(BR)，係將該事件訊息通知至緊急警報應用程式(EAA1)處。緊急警報應用程式(EAA1)，係基於在事件訊息中所記述之資訊(事件資訊)，而當該事件訊息係身為朝向緊急警報應用程式(EAA2)之變遷指示的情況時，實行變遷至緊急警報應用程式(EAA2)之處理。
之後，在受訊裝置20處，因應於從中間軟體(MW)或瀏覽器(BR)而來之指示(EAA2變遷事件)，緊急警報應用程式(EAA2)係被取得並被啟動(S46)。其結果，在受訊裝置20之畫面處，由緊急警報應用程式(EAA1)所致之緊急詳細資訊(的頁面)係被更新，並被顯示有由緊急警報應用程式(EAA2)所致之緊急詳細資訊(的頁面)。於此，緊急警報應用程式(EAA2)，係為除了代表將藉由緊急警報應用程式(EAA1)所顯示之頁面的全部作更新以外，亦代表將藉由緊急警報應用程式(EAA1)所顯示之頁面的一部分作更新等。
藉由此，係能夠針對關心緊急警報訊息之使用者，而提示與最初所提示的緊急詳細資訊(途中之EAA1」)相異之緊急詳細資訊(圖中之「EAA2」)，來提供更加詳細之資訊。
之後，若是經過時刻t2，則從送訊裝置10而來之緊急警報之通知係結束。又，受訊裝置20，係受訊 從送訊裝置10而經由傳輸路徑80所通知而來之E-AIT(terminate)(S47)。在受訊裝置20處，中間軟體(MW)或瀏覽器(BR)，係對於該E-AIT(terminate)進行解析，並因應於該解析結果，來下達啟動中之緊急警報應用程式(EAA(EAA2))之結束的指示(S48)。
之後，在受訊裝置20處，因應於從中間軟體(MW)或瀏覽器(BR)而來之指示(EAA(EAA2)結束事件)，啟動中之緊急警報應用程式(EAA(EAA2))係被結束(S49)。又，在啟動緊急警報應用程式(EAA1)時，當播送應用程式(BCA)被設為暫時停止(suspend)的情況時，該播送應用程式(BCA)之實行係被再度開始(被啟動)。其結果，在受訊裝置20之畫面處，嵌入文本(burned-in text)和緊急詳細資訊(圖中之「EAA2」)之顯示係消失，播送應用程式(BCA)之資訊係被重疊顯示於播送節目之影像上(D45)。亦即是，受訊裝置20之畫面的顯示，係成為回到緊急警報被作通知之前的狀態(D41)。
如同上述一般，在第3方式B中，由於僅當中間軟體(MW)或瀏覽器(BR)基於E-AIT而判定要顯示緊急警報應用程式(EAA)的情況時，才會啟動緊急警報應用程式(EAA)，因此，例如，係可藉由防止緊急警報應用程式(EAA)之無謂的啟動等而減輕在受訊裝置20處之處理的負載。又，在第3方式B中，中間軟體(MW)或瀏覽器(BR)，係能夠基於事件訊息，來對關 連於緊急警報應用程式(EAA)之處理(例如生命周期之控制或者是伴隨著起因於時間之經過所導致的緊急警報之更新而進行的緊急警報應用程式(EAA)之變遷等)作控制。
另外，於此，作為緊急警報應用程式(EAA)之啟動方式，雖係針對第1方式~第3方式來作了說明，但是，此些之方式係僅為為了方便說明所使用者，亦可構成為採用第1方式~第3方式以外之其他的啟動方式。
(E-AIT之語法)
圖10，係為對於XML形式之E-AIT之語法之例作展示之圖。另外，在圖10中，於要素與屬性中之屬性處，係附加有「@」。又，被作了內縮(indent)的要素和屬性，係成為被對於其之上位的要素作了指定者。
E-AIT，係包含有ServiceDiscovery要素以及ApplicationDiscovery要素。ApplicationDiscovery要素，係作為根要素(屬性性)，而包含有DomainName屬性、Version屬性、EmergencyApplicationList要素、EmergencyApplication要素以及CAPMessage要素。
在DomainName屬性中，係被指定有領域(domain)名稱。在Version屬性中，係被指定有版本。在EmergencyApplicationList要素中，係被指定有能夠藉由現行之程式來實行的緊急警報應用程式(EAA)之清 單。
在EmergencyApplication要素中，係被指定有關連於緊急警報應用程式(EAA)之資訊。EmergencyApplication要素，係成為appName要素、applicationIdentifier要素、CAPMessage要素、emergencyAlert要素、applicationDescriptor要素、applicationTransport要素、applicationLocation要素以及applicationBoundary要素之上位要素。
在appName要素中，係被指定有緊急警報應用程式(EAA)之名稱。appName要素，係成為language屬性之上位要素。在此language屬性中，係被指定有藉由ISO 639-2所規定的語言碼。
applicationIdentifier要素，係成為orgId要素以及appId要素之上位要素。在orgId要素中，係被指定有組織ID。在appId要素中，係被指定有應用程式ID。亦即是，藉由組織ID和應用程式ID之組合，係成為被指定有整體(global)性且獨特(unique)的應用程式ID。
在CAPMessage要素中，係能夠配置CAP資訊。亦即是，當以緊急警報應用程式(EAA)單位來將CAP資訊附加關連性的情況時，係成為在此EmergencyApplication要素之CAPMessage要素中配置CAP資訊。
emergencyAlert要素，係被指定有關連於緊急警報(之詳細資訊)的資訊(基本資訊)。 emergencyAlert要素，係成為senderName屬性、sentTime屬性、category屬性、priority屬性、alertStatusCode屬性、urgency屬性、severity屬性以及area要素之上位要素。
在senderName屬性中，例如係被指定有美國聯邦緊急事務管理署(FEMA)或播送台等之代表緊急警報之發行來源的資訊。在sentTime屬性中，係被指定有代表緊急警報之被發行的時刻之資訊。
在category屬性中，係被指定有緊急警報之範疇(Category)。作為此範疇，例如，係因應於運用，而被指定有"Geo(Geophysical)"、"Met(Meteorological)"、"Safety"等之用以分類緊急警報的資訊。
在priority屬性中，係被指定有代表緊急警報之優先度的資訊。作為此代表優先度之資訊，例如，係被指定有0、1、2、3、…等之數值。於此，係可因應於運用來決定優先度之分配，例如決定為0的優先度為最低並且數值越大則優先度會變得越高等。
在alertStatusCode屬性中，例如，係被指定有代表係身為測試用或者是正式使用等的緊急警報之狀態之碼。作為此碼，例如，係被指定有"exercise"、"actual"、"system"、"test"、"draft"等。
在urgency屬性中，係被指定有代表緊急警報之緊急性的資訊。作為此代表緊急性之資訊，例如，係被指定有"immediate"、"expected"、"future"、"past"等。於 此，"immediate"，係代表被要求立即進行避難等。"expected"，係代表要求即將(例如1小時以內)開始進行避難等。"future"，係代表要求儘快(較"expected"而有更長的時間)開始進行避難等。"past"，係代表已經沒有進行避難的需要。
在severity屬性中，係被指定有代表緊急警報之重大性的資訊。作為代表此重大性之資訊，例如，係因應於運用，而被指定有"extreme"、"severe"、"moderate"、"minor"等之用以分類緊急警報之重大性的資訊。
在area要素中，係被指定有代表緊急警報之對象地區的資訊(碼)。area要素，係成為type屬性之上位要素。在type屬性中，係被指定有代表對象區域的資訊(碼)之形態。作為此形態，例如，係被指定有"zip"或"latitude/longitude"。
於此，"zip"，例如係代表藉由美國郵政署(USPS)所使用的5碼或者是9碼的郵遞區號(ZIP code)來對於對象區域作指定。又，"latitude/longitude"，係代表藉由緯度和經度來對於對象區域作指定。
另外，藉由emergencyAlert要素所指定的關聯於緊急警報之資訊(基本資訊)，主要係為在緊急警報應用程式(EAA)之啟動時的判定處理(是否需要進行緊急詳細資訊之顯示的判定)中所使用者，該判定條件，係因應於各運用的不同而互為相異，因此，在基本資訊中， 係並不被限定於上述之資訊，而能夠指定與該判定處理之內容相對應的資訊。又，emergencyAlert要素之管轄下的要素或屬性中之alertStatusCode屬性，係成為必要之屬性，但是，關於是否要指定該屬性以外之要素或屬性一事，則為任意。
在applicationDescriptor要素中，係被指定有關連於緊急警報應用程式(EAA)之資訊。applicationDescriptor要素，係成為type要素、controlCode要素、serviceBound要素、priority要素、icon要素之上位要素。
type要素，係成為AtscApp要素之上位要素。在AtscApp要素中，係被指定有緊急警報應用程式(EAA)之形態。作為此形態，例如，係被指定有代表乃身為以HTML5所開發的應用程式一事之"ATSC-HTML"。
在controlCode要素中，係被指定有對於緊急警報應用程式(EAA)之控制碼(指令)。作為此控制碼，例如，係被指定有"AUTOSTART"、"PRESENT"、"KILL"、"TERMINATE"、"PREFETCH"、"SUSPEND"中之其中一者。
於此，"AUTOSTART"，係為用以自動性地即時實行緊急警報應用程式(EAA)之指令。"PRESENT"，係為用以使緊急警報應用程式(EAA)並不自動實行之指令。"KILL"與"TERMINATE"，係為用以使緊急警報應用程式(EAA)結束之指令。另外，在本實施形態中，作為 用以使緊急警報應用程式(EAA)結束之指令，雖係針對使用"TERMINATE"的情況來作例示，但是，亦可代替"TERMINATE"，而指定"KILL"。
"PREFETCH"，係為用以經由播送或經由通訊來取得緊急警報應用程式(EAA)之指令。"SUSPEND"，係為用以使緊急警報應用程式(EAA)暫時停止之指令。另外，"DESTROY"、"REMOTE"、"DISABLED"以及"PLAYBACK_AUTOSTART"，係並非為應作為控制碼來使用者。
在serviceBound要素中，係被指定有與緊急警報應用程式(EAA)連動而動作之服務等的範圍。在priority要素中，係被指定有在同一之應用程式的形態內之優先度。
在icon要素中，係被指定有關連於緊急警報應用程式(EAA)之圖符的資訊。icon要素，係成為filename屬性以及size屬性之上位要素。在filename屬性中，係被指定有關連於圖符之檔案名稱的資訊。在size屬性中，係被指定有關連於圖符之尺寸的資訊。
在applicationTransport要素中，係被指定有緊急警報應用程式(EAA)之傳輸方法和位置資訊。applicationTransport要素，係成為URLBase要素以及URLExtension要素之上位要素。在URLBase要素中m，係被指定有基礎(base)部分之URL。又，在URLExtension要素中，係被指定有擴張部分之URL。在 applicationLocation要素中，係被指定有緊急警報應用程式(EAA)之檔案的URL。亦即是，藉由基礎部分(first part)之URL和擴張部分(second part)之URL以及檔案部分(third part)之URL間的結合，緊急警報應用程式(EAA)之位置資訊(URL)係被作指定。
在applicationBoundary要素中，係被指定有代表緊急警報應用程式(EAA)之動作範圍的資訊(邊界資訊)。在此邊界資訊中，係被指定有特定之領域(domain)，若是為該領域之範圍內，則緊急警報應用程式(EAA)之動作係成為被容許。另外，代替此領域，係亦可構成為使用上述之緊急資訊應用程式(EAA)之位置資訊(URL)。
在(根要素之)CAPMessage要素中，係能夠配置CAP資訊。亦即是，當對於被記述在E-AIT中之(複數之)緊急警報應用程式(EAA)的全部而將同一之CAP資訊附加關連性的情況時(藉由E-AIT全體而傳輸CAP資訊的情況時)，係成為在此根要素之CAPMessage要素中配置CAP資訊。
另外，在圖10中，雖係存在有出現數(Cardinality)，但是，當其被指定為"1"的情況時，該要素或者是屬性係決定僅被指定有1個，而當被指定為"0..1"的情況時，是否要指定該要素或屬性一事係為任意。又，當被指定為"1..N"的情況時，該要素或屬性係被指定有1以上，當被指定為"0..N"的情況時，是否要將該 要素或屬性作1以上之指定一事係為任意。
又，作為Data Type，當被指定有"string"的情況時，係代表該要素或屬性之值乃身為文字列型。作為Data Type，當被指定有"unsignedShort"或"unsiguedInt"的情況時，係代表該要素或屬性之值乃身為整數型。作為Data Type，當被指定有"Boolean"的情況時，係代表該要素或屬性之值乃身為布耳型，當被指定為"Hexadecimal"的情況時，係代表該要素或屬性乃身為16進位數。作為Data Type，當被指定有"anyURI"的情況時，係代表該要素或屬性之值乃身為anyURI資料型。
另外，在圖10中所示之E-AIT的語法，係僅為其中一例，例如，係亦可追加其他之要素或屬性等而採用其他的語法。又，E-AIT，係並不被限定於XML形式，而亦可藉由其他之標示語言來作記述，或者是亦可為區段(section)形式。
(事件訊息之傳輸方式)
另外，如同上述一般，在受訊裝置20處，雖係可基於事件訊息來進行關連於緊急警報應用程式(EAA)之處理，但是，此事件訊息，例如，係可配置在MPD之事件串流要素或者是藉由ROUTE會談所傳輸的DASH區段之事件訊息盒中。因此，以下，係依序針對事件訊息為被配置在MPD之事件串流要素中的情況時和事件訊息為被配置在DASH區段之事件訊息盒中的情況時作說明。另外， 作為傳送通訊協定，當代替ROUTE而使用MMT的情況時，係只要構成為將與MPD之事件串流要素相同的要素作為MMT訊令之一部分來作傳輸或者是作為獨立之訊令的資料來作傳輸即可。又，事件訊息，係亦可構成為並非被嵌入至DASH區段中而是被嵌入至MMT之媒體區段中並作傳輸。
(1)將事件訊息配置在MPD之事件串流要素中的情況 (MPD之記述例)
圖11，係為對於XML形式之MPD之記述例作展示之圖。
如同圖11中所示一般，MPD，係將Period要素、AdaptationSet要素以及Representation要素，以階層構造來作記述。Period要素，係成為對於播送節目等之內容的構成作記述之單位。又，AdaptationSet要素以及Representation要素，係在視訊和音訊、字幕等之構件的各串流中被作利用，並成為能夠記述各個的串流之屬性。
具體而言，AdaptationSet要素，係代表從各種的來源(source)而被作了編碼之串流。又，為了在受訊裝置20側處而例如因應於位元率等之參數(parametric)來對於該串流作選擇，係在AdaptationSet要素內，配置Representation要素，並列舉有例如成為在位元率等之參數上為相異的複數之選項之串流。通常， AdaptationSet要素和Representation要素，係對應於像是視訊或音訊、字幕之串流等的單一之串流。
又，當使AdaptationSet要素表現將視訊串流或音訊串流、字幕串流等之複數之串流作了多工化之串流的情況時，係在AdaptationSet要素內，配置Representation要素，並列舉出例如成為在位元率等之參數上為相異的複數之選項之被作了多工化之串流。亦即是，在代表時間間隔之Period要素的每一者中，係被配置有代表被作了多工化的串流之複數之AdaptationSet要素，並能夠藉由被配置在該些之AdaptationSet要素內的複數之Representation要素，來列舉出複數之例如位元率為相異的被作了多工化之串流。
又，在MPD中，係能夠於Period要素內，記述EventStream要素。在此EventStream要素中，係能夠配置事件訊息。
在EventStream要素中，作為其之屬性，係能夠記述schemeIdUri屬性和timescale屬性。在schemeIdUri屬性中，係被指定有用以對於事件訊息之架構(scheme)作辨識的URI。在此記述例中，作為schemeIdUri屬性之屬性值，係被指定有"urn：atsc：appControlMessage"，藉由此屬性值，係辨識出其乃身為關連於緊急警報(緊急警報應用程式(EAA))之事件訊息。又，在timescale屬性中，作為其之屬性值，係被指定有身為'1000'之時間尺度。
EventStream要素，係成為Event要素之上位要素。在Event要素中，係能夠於其之開始標籤(tag)與結束標籤之間，記述事件訊息。又，在Event要素中，作為其之屬性，係能夠指定「指定有呈現時間(Presentation time)(開始時刻)之presentationTime屬性」和「指定有從該開始時刻起之期間的duration屬性」。
例如，在此記述例中，在EventStream要素之開始標籤和結束標籤之間，係被記述有2個的Event要素，但是，在上側之Event要素中，係表現有「在從身為'0'之開始時刻起，於'1000'之期間之間，在「緊急警報應用程式資訊1」中所記述之內容，係作為事件訊息而被發行」的內容。又，在下側之Event要素中，係表現有「從身為'1000'之開始時刻起，於'4000'的期間之間，在「緊急警報應用程式資訊2」中所記述之內容，係作為事件訊息而被發行」的內容。
於此，在「緊急警報應用程式資訊1」或「緊急警報應用程式資訊2」之中，例如，係包含有關連於藉由E-AIT(圖10)之emergencyAlert要素所指定的緊急警報之資訊(基本資訊)和緊急警報應用程式(EAA)之控制資訊等。故而，在受訊裝置20處，係能夠基於此事件訊息，而進行像是對緊急警報應用程式(EAA)作更新等的關連於緊急警報應用程式(EAA)之處理。
另外，MPD之EventStream要素，係具備有如同圖12中所示一般之構造，而並不被限定於上述之圖 11之MPD的記述例，可藉由與其他要素或屬性之組合等，來傳輸事件訊息。
(MPD之EventStream要素的構造)
圖12，係為對於MPD之EventStream要素的構造之例作展示之圖。
如同圖12中所示一般，EventStream要素，係成為xlink：href屬性、xlink：actuate屬性、schemeIdUri屬性、value屬性、timescale屬性以及Event要素之上位要素。
在xlink：href屬性中，係被指定有外部之事件串流要素的URI。在xlink：actuate屬性中，係被指定有遍歷(traversal)之時序。另外，XLink(XML Linking Language)，係為用以對於XML文書彼此之鏈結作定義的規格。
在schemeIdUri屬性中，係被指定有用以對於事件訊息之架構(scheme)作辨識的URI。在value屬性中，係作為屬性值而被指定有EventStream要素之值。在timescale屬性中，係被指定有代表時間尺度之資訊。在Event要素中，係被指定有關連於事件之資訊。
(EventStream要素之具體例)
於此，在圖13~圖15中，針對藉由具備有圖12中所示之構造的EventStream要素來通知關連於緊急警報 (之詳細資訊)之事件訊息的情況時之構造的具體例作例示。
(第1具體例)
圖13，係為對於EventStream要素之構造的第1具體例作展示之圖。
在圖13中，作為EventStream要素之schemeIdUri屬性，係被指定有"urn：atsc3：us：emergency_info"。亦即是，藉由此schemeIdUri屬性之屬性值，係辨識出此乃身為關連於緊急警報(緊急警報應用程式(EAA))之事件訊息。
在EventStream要素之value屬性中，作為其之屬性值，例如，係藉由逗點區隔，而被指定有E-AIT(圖10)之emergencyAlert要素的category屬性之屬性值、priority屬性之屬性值、urgency屬性之屬性值、severity屬性之屬性值、以及area要素及其type屬性之值，此些之中的至少1個的資訊。
此種事件訊息，由於係作為SLS訊令，而被包含於在各服務之每一者中而被作傳輸的MPD中，因此，受訊裝置20，係能夠基於在MPD中所包含之事件訊息，來在特定之時序處，進行關連於緊急警報應用程式(EAA)之處理。
另外，在EventStream要素之value屬性中所被指定之要素或屬性，係與關連於藉由E-AIT(圖10)之 emergencyAlert要素所指定的緊急警報之資訊(基本資訊)相對應，而並不被限定於圖13中所示之藉由value屬性所指定的資訊，而可指定與各種之運用相對應的資訊。又，係並不被限定於基本資訊，例如，係亦可構成為被指定有緊急警報應用程式(EAA)之控制資訊等。
(第2具體例)
圖14，係為對於EventStream要素之構造的第2具體例作展示之圖。
在圖14中，作為EventStream要素之schemeIdUri屬性，係被指定有"urn：atsc3：us：emergency_info"。亦即是，藉由此schemeIdUri屬性之屬性值，係辨識出此乃身為關連於緊急警報(緊急警報應用程式(EAA))之事件訊息。
EventStream要素之Event要素，係成為category要素、priority要素、urgency要素、severity要素以及area要素之上位要素。又，area要素，係成為type屬性之上位要素。另外，此些之要素和屬性，係與E-AIT(圖10)之emergencyAlert要素的要素和屬性相對應。
此種事件訊息，由於係作為SLS訊令，而被包含於在各服務之每一者中而被作傳輸的MPD中，因此，受訊裝置20，係能夠基於在MPD中所包含之事件訊息，來在特定之時序處，進行關連於緊急警報應用程式 (EAA)之處理。
另外，在EventStream要素之Event要素的下部所被指定之要素或屬性，係與關連於藉由E-AIT(圖10)之emergencyAlert要素所指定的緊急警報之資訊(基本資訊)相對應，而並不被限定於圖14中所示之藉由在Event要素的下部所被指定之要素或屬性而指定的資訊，而可指定與各種之運用相對應的資訊。又，係並不被限定於基本資訊，例如，係亦可構成為被指定有緊急警報應用程式(EAA)之控制資訊等。
(第3具體例)
圖15，係為對於EventStream要素之構造的第3具體例作展示之圖。
在圖15中，作為EventStream要素之schemeIdUri屬性，係被指定有"urn：atsc3：us：emergency_info"。亦即是，藉由此schemeIdUri屬性之屬性值，係辨識出此乃身為關連於緊急警報(緊急警報應用程式(EAA))之事件訊息。
在EventStream要素之Event要素中，係於藉由XML所規定的CDATA區段內，被配置有CAP資訊。此CAP資訊，係為與從緊急資訊來源而來之緊急資訊來源資訊相對應的資訊。
此種事件訊息(CPA資訊)，由於係作為SLS訊令，而被包含於在各服務之每一者中而被作傳輸的 MPD中，因此，受訊裝置20，係能夠基於在MPD中所包含之事件訊息(CPA資訊)，來在特定之時序處，進行關連於緊急警報應用程式(EAA)之處理。
另外，在EventStream要素之Event要素中，被配置在CDATA區段內的資訊，係並不被限定於CAP資訊，而可配置與各種之運用相對應的資訊。
(2)被配置在DASH區段之事件訊息盒中的情況 (事件訊息盒的構造)
圖16，係為對於藉由ROUTE會談所傳輸的DASH區段之事件訊息盒('emsg'盒)的構造之例作展示之圖。
在DASH區段之事件訊息盒中，係被儲存有scheme_id_uri、value、timescale、presentation_time_delta、event_duration、id以及message_data[ ]。
在文字列型之scheme_id_uri中，係被指定有用以對於事件訊息之架構作辨識之URI。在文字列型之value中，係被指定有各種之值。
32位元之無符號整數型之timescale，係被指定有代表時間尺度之資訊。在32位元之無符號整數型之presentation_time_delta中，係被指定有代表呈現時間(開始時刻)之資訊。在32位元之無符號整數型之event_duration中，係被指定有代表事件訊息之期間的資訊。
在32位元之無符號整數型之id中，係被指定有用以對於事件訊息作辨識之資訊。在8位元之無符號整數型之message_data[ ]中，係被配置有事件訊息之資料。
(DASH事件訊息盒的具體例)
於此，在圖17~圖18中，針對藉由具備有圖16中所示之構造的事件訊息盒來通知關連於緊急警報(之詳細資訊)之事件訊息的情況之具體例作例示。
(第1具體例)
圖17，係為對於DASH區段之事件訊息盒的構造之第1具體例作展示之圖。
在圖17中，作為box_type，係被指定有代表事件訊息盒之'emsg'。又，在scheme_id_uri中，係被指定有"urn：atsc3：us：emergency_info"。亦即是，藉由此scheme_id_uri，係辨識出此乃身為關連於緊急警報(緊急警報應用程式(EAA))之事件訊息。另外，在value中，係被指定有0。
在timescale中，作為時間尺度，係被指定有1000。又，在presentation_time_delta中，係作為呈現時間(開始時刻)，而被指定有0。進而，在event_duration中，係作為事件訊息之期間，而被指定有0xFFFF。
在id中，作為事件訊息ID，係被指定有1。 在message_data[ ]中，作為事件訊息之資料，係被配置有緊急警報關連資料1。作為此緊急警報關連資料1，係可配置關連於藉由E-AIT(圖10)之emergencyAlert要素所指定的緊急警報之資訊(基本資訊)。又，係並不被限定於基本資訊，例如，係亦可構成為被指定有緊急警報應用程式(EAA)之控制資訊等。進而，於此，係亦可構成為被配置有CAP資訊等。
另外，在圖17之例中，於message_data[ ]中，雖係配置有事件訊息之資料(E-AIT之基本資訊)，但是，係亦可構成為在value中，以逗點區隔來配置有事件訊息之資料(E-AIT之基本資訊)。
(第2具體例)
圖18，係為對於DASH區段之事件訊息盒的構造之第2具體例作展示之圖。
在圖18中，作為box_type，係被指定有代表事件訊息盒之'emsg'。又，在scheme_id_uri中，係被指定有"urn：atsc3：us：emergency_info"。亦即是，藉由此scheme_id_uri，係辨識出此乃身為關連於緊急警報(緊急警報應用程式(EAA))之事件訊息。另外，在value中，係被指定有0。
在timescale中，作為時間尺度，係被指定有1000。又，在presentation_time_delta中，係作為呈現時間(開始時刻)，而被指定有0。進而，在event_duration 中，係作為事件訊息之期間，而被指定有0xFFFF。
在id中，作為事件訊息ID，係被指定有2。在message_data[ ]中，作為事件訊息之資料，係被配置有緊急警報關連資料2。作為此緊急警報關連資料2，係可配置關連於藉由E-AIT(圖10)之emergencyAlert要素所指定的緊急警報之資訊(基本資訊)。又，係並不被限定於基本資訊，例如，係亦可構成為被指定有緊急警報應用程式(EAA)之控制資訊等。進而，於此，係亦可構成為被配置有CAP資訊等。
另外，在圖18之例中，於message_data[ ]中，雖係配置有事件訊息之資料(E-AIT之基本資訊)，但是，係亦可構成為在value中，以逗點區隔來配置有事件訊息之資料(E-AIT之基本資訊)。
<2.各裝置之構成>
接著，針對構成圖1之傳輸系統1的各裝置之詳細之構成作說明。於此，係以由播送台所設置的送訊裝置10之構成和由使用者所設置的受訊裝置20之構成為中心，來進行說明。
圖19，係為對於傳輸系統1的各裝置之構成例作展示之圖。
在圖19中，送訊裝置10，係由EA剖析器101、和直播內容取得部102、和儲存設備103、和組件處理部104、和訊令處理部105、和LCC處理部106、和編 碼器107、和多工器108、和調變部109、以及RF部110，而構成之。
EA剖析器101，在緊急時，係取得從緊急資訊來源(EA Authority)所通知而來之作為緊急資訊來源資訊之CAP資訊，並進行解析。EA剖析器101，係將CAP資訊之解析結果，供給至組件處理部104、訊令處理部105或者是LCC處理部106處。
直播內容取得部102，係因應於從組件處理部104而來之要求，而例如取得從轉播場所所透過傳輸路徑或通訊線路而送來的直播內容(例如，體育轉播等之現場播送節目)之資料，並供給至組件處理部104處。此直播內容，係由視訊或音訊、字幕等的組件所構成。
儲存設備103，例如，係積蓄有已完成收錄之內容(例如，連續劇等之事先收錄節目)。儲存設備103，係因應於從組件處理部104而來之要求，而將所積蓄的已完成收錄之內容，供給至組件處理部104處。此已完成收錄內容，係由視訊或音訊、字幕等的組件所構成。
組件處理部104，係取得從直播內容取得部102而來之直播內容或者是從儲存設備103而來之已完成收錄內容，並對於構成所取得的內容之視訊和音訊的組件進行處理，而供給至編碼器107處。
編碼器107，係將從組件處理部104所供給而來之視訊和音訊的組件之資料，依據特定之編碼方式來進行編碼，並供給至多工器108處。
又，在緊急時，在受訊裝置20之畫面上，由於係顯示有嵌入文本(EA text)，因此，從EA剖析器101而來之CAP資訊之解析結果，係被供給至組件處理部104處。組件處理部104，當從EA剖析器101而被供給有CAP資訊之解析結果的情況時，係在內容(例如現場播送節目或事先收錄節目)之影像(非壓縮之視訊資料)中，嵌入從EA剖析器101而來之與CAP資訊之解析結果相對應的緊急警報(文本資訊)。之後，編碼器107，係成為依據特定之編碼方式，來對於被嵌入有緊急警報(文本資訊)之視訊資料進行編碼。
訊令處理部105，係產生LLS訊令或SLS訊令等之訊令，並供給至多工器108處。例如，作為LLS訊令，係產生有SLT後設資料等。又，作為SLS訊令，係產生有USD、S-TSID、MPD等之後設資料。
又，訊令處理部105，在緊急時，當從EA剖析器101而被供給有CAP資訊之解析結果的情況時，係產生與CAP資訊之解析結果相對應的E-AIT，並供給至多工器108處。在此E-AIT中，係包含有關連於緊急警報(之詳細資訊)的資訊、和緊急警報應用程式(EAA)之控制資訊等。
LCC處理部106，當被提供有LCC內容的情況時，例如係產生播送應用程式(BCA)等之LCC內容，並供給至多工器108處。又，LCC處理部106，在緊急時，當從EA剖析器101而被供給有CAP資訊之解析結 果的情況時，係基於該CAP資訊之解析結果，而產生緊急警報應用程式(EAA)，並供給至多工器108處。
多工器108，係將從編碼器107所供給而來之組件的串流和從訊令處理部105所供給而來之訊令的串流作多工化，而產生多工化串流，並供給至調變部109處。又，多工器108，當被提供有LCC內容(例如播送應用程式(BCA)或緊急警報應用程式(EAA))的情況時，係除了組件與訊令的串流之外，更進而將從LCC處理部106所供給而來之LCC內容(例如播送應用程式(BCA)或緊急警報應用程式(EAA))的串流作多工化，而產生多工化串流。
調變部109，係進行對於從多工器108所供給而來的多工化串流之資料的錯誤訂正編碼處理(例如，BCH編碼或LDPC編碼等)和調變處理(例如，OFDM(Orthogonal Frequency Division Multiplexing)調變等)，並將藉由該處理之結果所得到的訊號，供給至RF部110處。
RF部110，係將從調變部109所供給而來之訊號，轉換為RF(Radio Frequency)訊號，並透過天線(未圖示)，來作為IP傳輸方式之數位播送訊號而送訊。
送訊裝置10，係如同上述一般地而被構成。另外，在圖19中，為了便於說明，係針對送訊側之裝置為藉由送訊裝置10、亦即是藉由1個的裝置來構成的情 況，而作了展示，但是，係亦可作為由具備有圖19之區塊的各功能之複數之裝置所成的送訊系統，而構成之。又，藉由使送訊裝置10成為具有通訊功能，緊急警報應用程式(EAA)，係亦可構成為從送訊裝置10來提供至EA伺服器40處。
又，在圖19中，受訊裝置20，係由RF部201、和解調部202、和處理部203、和輸出部204、以及通訊I/F部205，而構成之。
RF部201，係透過天線(未圖示)，而受訊IP傳輸方式之數位播送訊號，並將RF訊號，頻率轉換為IF(Intermediate Frequency)訊號，並供給至解調部202處。另外，RF部201，係作為RF IC(Integrated Circuit)而被構成。
解調部202，係對於從RF部201所供給而來之訊號進行解調處理(例如，OFDM解調等)。又，解調部202，係對於藉由解調處理所得到的解調訊號，而施加錯誤訂正解碼處理(例如LDPC解碼或BCH解碼等)，並將該處理之結果所得到之訊號，供給至處理部203處。另外，解調部202，例如，係作為解調LSI(Large Scale Integration)而被構成。
處理部203，係對於從解調部202所供給而來之訊號進行處理(例如解碼處理等)，並將該處理之結果所得到的視訊和音訊之資料，供給至輸出部204處。
另外，處理部203，例如，係作為主SoC (System on Chip)而被構成。亦即是，作為解調LSI之解調部202、和作為主SoC之處理部203，係作為相異之晶片(Chip)而被構成，並透過特定之介面而被作連接。
處理部203，係由FW/HW部211、和組件處理部212、和MW部213、以及瀏覽器214，而構成之。
FW/HW部211，係藉由韌體(FW：Firmware)或者是硬體(HW：Hardware)所構成，並對於從解調部202而來之訊號進行處理。FW/HW部211，係包含有解多工器221以及解碼器222而構成之。
在解多工器221處，係作為從解調部202所供給而來之訊號，而被輸入有多工化串流。解多工器221，係將多工化串流，分離為視訊或音訊等之組件的串流和訊令的串流，並供給至解碼器222和MW部213處。又，解多工器221，當在多工化串流中包含有LCC內容(例如播送應用程式(BCA)或緊急警報應用程式(EAA))之串流的情況時，係將LCC內容(例如播送應用程式(BCA)或緊急警報應用程式(EAA))的串流分離，並供給至瀏覽器214處。
解碼器222，係基於從解多工器221所供給而來之組件的串流，而將視訊和音訊的組件之資料解碼，並供給至組件處理部212處。又，解多工器221以及解碼器222，當在DASH區段中包含有事件訊息的情況時，係成為對於該事件訊息進行解析，並因應於該解析結果，來對於瀏覽器214進行控制。
組件處理部212，係對於從解碼器222所供給而來之視訊和音訊的資料進行處理，並供給至輸出部204處。
但是，於緊急時，在內容(例如現場播送節目或事先收錄節目)之影像(非壓縮之視訊資料)中，係被嵌入有緊急警報(文本資訊)，此係成為被作為嵌入文本(burned-in text)而顯示。
MW部213，係藉由中間軟體(MW：Middleware)所構成，並對於從解多工器221所供給而來之訊令的串流進行處理。MW部213，係由剖析器231以及濾波器232所構成。剖析器231，係進行對象之訊令的解析處理。濾波器232，係進行對象之訊令的抽出處理。
之後，在處理部203處，係基於藉由MW部213而進行了處理的訊令，來進行對於組件和應用程式等之處理。但是，於緊急時，由於係從送訊裝置10而被通知有E-AIT，因此，MW部213，係成為對於該E-AIT進行解析，並因應於該解析結果，來對於瀏覽器214進行控制。又，MW部213，當在MPD中包含有事件訊息的情況時，係成為對於該事件訊息進行解析，並因應於該解析結果，來對於瀏覽器214進行控制。
瀏覽器214，例如，係為對應於HTML5之瀏覽器，並實行從解多工器221所供給而來之播送應用程式(BCA)或緊急警報應用程式(EAA)。藉由此緊急警報應用程式(EAA)，例如係成為顯示有緊急詳細資訊(圖 中之「EAA」)。
輸出部204，係對於從組件處理部212所供給而來之視訊資料進行處理，並輸出至顯示部(未圖示)處。又，輸出部204，係對於從組件處理部212所供給而來之音訊資料進行處理，並輸出至揚聲器(未圖示)處。藉由此，在顯示部處，係被顯示有現場播送節目或事先收錄節目等之內容的影像，並從揚聲器而輸出有與該影像相互同步的聲音。
但是，於緊急時，在顯示部處，係成為顯示被嵌入有與緊急警報相對應的嵌入文本(burned-in text)之現場播送節目等的內容之影像。又，於緊急時，當因應於E-AIT而緊急警報應用程式(EAA)被啟動的情況時，係成為在現場播送節目等的內容之影像處重疊顯示有緊急詳細資訊。
通訊I/F205，係透過網際網路等之通訊線路90，來與EA伺服器40之間進行各種資料之交換。
例如，通訊I/F205，係能夠因應於E-AIT之解析結果，而藉由透過通訊線路90來對於EA伺服器40要求緊急警報應用程式(EAA)，而受訊從EA伺服器40所配送之緊急警報應用程式(EAA)，並供給至處理部203之瀏覽器214處。藉由此，瀏覽器214，係能夠實行(啟動)從EA伺服器40所配送的緊急警報應用程式(EAA)。
受訊裝置20，係如同上述一般地而被構成。 另外，受訊裝置20，係除了可身為電視受像機、機上盒(STB：Set Top Box)或者是錄影機等之固定受訊機以外，亦可身為行動電話、智慧型手機或者是平板終端等之攜帶受訊機。又，受訊裝置20，係亦可為被搭載於車輛處之車載機器。進而，在圖19之受訊裝置20的構成中，雖係針對顯示部和揚聲器為被設置於外部的構成作了展示，但是，顯示部和揚聲器，係亦可構成為被設置在受訊裝置20之內部。又，在圖19中，雖並未圖示，但是，於受訊裝置20處，係內藏有常駐應用程式(RA)，並藉由此常駐應用程式(RA)來實行各種之處理。
<BCA與EAA之啟動序列>
圖20，係為對於在圖19之受訊裝置20處的HTML5應用程式(BCA、EAA)的啟動序列之例作展示之圖。
於圖20中，播送、通訊I/F251，係相當於在圖19之受訊裝置20中作為播送I/F而起作用之RF部201和解調部202以及作為通訊I/F而起作用之通訊I/F205。又，應用程式實行環境/中間軟體252，係相當於在圖19之受訊裝置20中的處理部203之MW部213和瀏覽器214。
在圖19之受訊裝置20處，若是藉由播送、通訊I/F251而受訊AIT，則係藉由應用程式實行環境/中間軟體252，來對於該AIT進行解析，並因應於該解析結果，而受訊播送應用程式(BCA)(S71)。之後，應用 程式實行環境/中間軟體252，係啟動藉由播送、通訊I/F251所受訊了的播送應用程式(BCA)(S72)。
於此，被啟動了的播送應用程式(BCA)，係藉由addEventListener方法(method)，來對於應用程式實行環境/中間軟體252而進行特定之事件(例如E-AIT)的登錄(S73)。藉由此，在應用程式實行環境/中間軟體252處，係成為完成了當特定之事件(例如E-AIT受訊事件)被發行時將其通知至播送應用程式(BCA)處之準備。
之後，若是藉由播送、通訊I/F251而受訊E-AIT(S74)，則在應用程式實行環境/中間軟體252處，係發行回呼(callback)事件，該E-AIT受訊事件，係被通知至播送應用程式(BCA)處(S75)。於此，E-AIT，係從應用程式實行環境/中間軟體252而被供給至播送應用程式(BCA)處。
播送應用程式(BCA)，係對於E-AIT進行解析，並進行是否要啟動緊急警報應用程式(EAA)一事之判定處理(S76)。在此判定處理中，例如，係判定要啟動緊急警報應用程式(EAA)，該EAA啟動判定結果，係被通知至應用程式實行環境/中間軟體252處(S77)。
應用程式實行環境/中間軟體252，當基於從播送應用程式(BCA)而來之EAA啟動判定結果，而啟動緊急警報應用程式(EAA)的情況時，係使啟動中之播 送應用程式(BCA)暫時停止或者是結束(S78)。之後，若是藉由播送、通訊I/F251而受訊了緊急警報應用程式(EAA)(S79)，則應用程式實行環境/中間軟體252，係成為使該緊急警報應用程式(EAA)啟動(S80)。
如同上述一般，在圖19之受訊裝置20處，播送應用程式(BCA)和緊急警報應用程式(EAA)係被啟動。但是，圖20之啟動序列，係僅為其中一例，例如，在此例中，雖係於播送應用程式(BCA)側而進行緊急警報應用程式(EAA)之啟動判定處理，但是，亦可如同上述之例一般地，而在應用程式實行環境/中間軟體252側，進行緊急警報應用程式(EAA)之啟動判定處理。
又，在圖20之啟動序列中，雖係針對使播送應用程式(BCA)藉由addEventListener方法來作為特定之事件而將E-AIT受訊事件作了登錄的情況為例來作了說明，但是，其他之事件亦可同樣地作登錄並進行處理。例如，針對事件訊息，亦同樣的，藉由以addEventListener方法來事先作登錄，係能夠在回呼事件被發行的時序處，而接收事件訊息之通知。
<3.藉由各裝置所實行的處理之流程>
接著，參考圖21~圖28之流程圖，針對藉由構成圖1之傳輸系統1的各裝置所實行之處理的流程作說 明。
(送訊處理之流程)
首先，參考圖21之流程圖，針對藉由圖19之送訊裝置10所實行之送訊處理的流程作說明。
在步驟S101中，組件處理部104以及編碼器107，係進行組件處理。
在此組件處理中，係取得藉由直播內容取得部102所取得之直播內容(例如現場播送節目)或者是被積蓄在儲存設備103中之已完成收錄之內容(例如事先收錄節目)，並對於構成所取得的內容之視訊和音訊的組件，而進行像是與特定之編碼方式相對應的編碼等之處理。
又，於緊急時，當在受訊裝置20之畫面上顯示嵌入文本的情況時，在組件處理中，係先在內容(例如現場播送節目或事先收錄節目)之影像(非壓縮之視訊資料)中，嵌入與從EA剖析器101而來之CAP資訊的解析結果相對應的緊急警報(文本資訊)，之後再進行編碼。
在步驟S102中，訊令處理部105，係進行訊令處理。
在此訊令處理中，係產生LLS訊令或SLS訊令等之訊令並進行處理。例如，作為訊令，係產生有用以對於播送應用程式(BCA)之動作作控制的AIT。
又，在緊急時，於訊令處理中，作為LLS訊 令，係產生與從EA剖析器101而來之CAP資訊的解析結果相對應之E-AIT。在此E-AIT中，係包含有關連於緊急警報(之詳細資訊)的資訊、和緊急警報應用程式(EAA)之控制資訊等。
在步驟S103中，LCC處理部106，係進行應用程式處理。
於此應用程式處理中，作為LCC內容，係產生播送應用程式(BCA)。又，在緊急時，於應用程式處理中，作為LCC內容，係產生與從EA剖析器101而來之緊急警報相對應的緊急警報應用程式(EAA)。播送應用程式(BCA)和緊急警報應用程式(EAA)，係為藉由HTML5所開發的應用程式。
在步驟S104中，多工器108，係進行多工化串流產生處理。
在此多工化串流產生處理中，藉由步驟S101之處理所得到的組件之串流、和藉由步驟S102之處理所得到的訊令之串流，係被多工化，而產生多工化串流。但是，於緊急時，在訊令中，係包含有E-AIT。又，於緊急時，緊急警報應用程式(EAA)之串流係亦被多工化。
在步驟S105中，調變部109以及RF部110，係進行播送串流送訊處理。
在此播送串流送訊處理中，藉由步驟S104之處理所產生的多工化串流，係作為IP傳輸方式之數位播送訊號而被送訊。
若是步驟S105之處理結束，則圖21之送訊處理係結束。
以上，係針對送訊處理之流程作了說明。
(電源OFF、待機狀態時之受訊處理的流程)
接著，參考圖22之流程圖，針對藉由圖19之受訊裝置20所實行之在電源OFF、待機狀態時之受訊處理的流程作說明。但是，作為圖22之流程圖的處理會被實行的前提，假設係為受訊裝置20身為電源OFF並且為待機狀態，亦即是在受訊裝置20處僅有RF部201以及解調部202為可進行動作之狀態。
在步驟S201中，RF部201以及解調部202，係進行L1封包受訊處理。
在此L1封包受訊處理中，從送訊裝置10而來之數位播送訊號係被受訊，作為數位播送訊號而被送訊之L1訊框係被取得。
在步驟S202中，解調部202，係對於在藉由步驟S201之處理所取得的L1訊框之L1標頭中所包含的喚醒旗標(wake-up flag)作監視。
在步驟S203中，係基於步驟S202之監視結果，而判定喚醒旗標是否為"TRUE"。在步驟S203中，當判定喚醒旗標係為"FALSE"的情況時，處理係回到步驟S201處，步驟S201~S203之處理係被反覆進行。
又，在步驟S203中，當判定喚醒旗標係為 "TRUE"的情況時，處理係前進至步驟S204處。在步驟S204中，受訊裝置20之電源係被設為ON。藉由此，在受訊裝置20處，處理部203和輸出部204等之RF部201以及解調部202以外的其他之區塊，係亦成為可進行動作之狀態。
若是藉由步驟S204之處理而成為能夠實行受訊裝置20之所有的功能，則處理係前進至步驟S205處。在步驟S205中，係進行播送串流受訊處理。
在此播送串流受訊處理中，基於訊令，視訊和音訊之組件係被作處理，內容之影像和聲音係被播放。又，在緊急時，除了嵌入文本等之緊急警報以外，係亦顯示有由緊急警報應用程式(EAA)所致之緊急詳細資訊。另外，針對此播送串流受訊處理的詳細內容，係參考圖24之流程圖而於後再作敘述。
在步驟S206中，係判定步驟S205之播送串流受訊處理是否結束。在步驟S206中，當判定係持續進行播送串流受訊處理的情況時，處理係回到步驟S205處，步驟S205~S206之處理係被反覆進行。另一方面，在步驟S206中，當判定播送串流受訊處理係結束的情況時，圖22之在電源OFF、待機狀態時的受訊處理係結束。
以上，係針對在電源OFF、待機狀態時之受訊處理的流程作了說明。
(電源OFF狀態時之受訊處理的流程)
接著，參考圖23之流程圖，針對藉由圖19之受訊裝置20所實行之在電源OFF狀態時之受訊處理的流程作說明。但是，作為圖23之流程圖的處理會被實行的前提，假設係為受訊裝置20身為電源OFF狀態，亦即是在受訊裝置20處所有之功能均為無法實現之狀態。
在步驟S211中，例如，因應於使用者之操作，受訊裝置20之電源係被設為ON。
若是藉由步驟S211之處理而成為能夠實行受訊裝置20之所有的功能，則處理係前進至步驟S212處。在步驟S212中，係進行播送串流受訊處理。
在此播送串流受訊處理中，基於訊令，視訊和音訊之組件係被作處理，內容之影像和聲音係被播放。又，在緊急時，除了嵌入文本等之緊急警報以外，係亦顯示有由緊急警報應用程式(EAA)所致之緊急詳細資訊。另外，針對此播送串流受訊處理的詳細內容，係參考圖24之流程圖而於後再作敘述。
在步驟S213中，係判定步驟S212之播送串流受訊處理是否結束。在步驟S213中，當判定係持續進行播送串流受訊處理的情況時，處理係回到步驟S212處，步驟S212~S213之處理係被反覆進行。另一方面，在步驟S213中，當判定播送串流受訊處理係結束的情況時，圖23之在電源OFF狀態時的受訊處理係結束。
以上，係針對在電源OFF狀態時之受訊處理 的流程作了說明。
(播送串流受訊處理的流程)
接著，參考圖24之流程圖，針對與圖22之步驟S205之處理或者是圖23之步驟S212之處理相對應的播送串流受訊處理之流程作說明。
在步驟S221中，解多工器221，係進行封包受訊處理。在此封包受訊處理中，係從藉由解調部202而作了處理的L1訊框，來使ALP封包和IP/UDP封包被作處理。
在步驟S222中，係基於在步驟S221之處理中所得到的封包，來判定是否取得了LLS訊令(LLS表)。在步驟S222中，當判定係取得了LLS訊令的情況時，處理係前進至步驟S223處。
在步驟S223中，MW部213，係判別LLS訊令之種類和版本。於此，如同上述之參考圖4所作了說明一般，藉由對於在LLS表(之LL標頭)中所包含的LLS表ID和LLS表之版本進行解析，來判別出LLS訊令之種類和版本。
在步驟S224中，MW部213，係基於步驟S223之判別結果，來判定LLS訊令是否被作更新。在步驟S224中，當判定LLS訊令係被作更新的情況時，處理係前進至步驟S225處。
在步驟S225中，MW部213，係基於步驟 S223之判別結果，來判定LLS訊令是否身為E-AIT。在步驟S225中，當判定LLS訊令係為E-AIT的情況時，處理係前進至步驟S226處。
在步驟S226中，係進行E-AIT受訊處理。在此E-AIT受訊處理中，係進行有關連於提示與E-AIT相對應的緊急警報應用程式(EAA)之處理。另外，針對此E-AIT受訊處理的詳細內容，係參考圖25~圖27之流程圖而於後再作敘述。
另一方面，在步驟S225中，當判定LLS訊令係並非為E-AIT的情況時，處理係前進至步驟S227處。在步驟S227中，係進行其他之LLS訊令受訊處理。在此LLS訊令受訊處理中，係進行對於SLT後設資料等之除了E-AIT以外的LLS訊令之處理。
另外，在步驟S224中，當判定LLS訊令係並未被作更新的情況時，由於係並不需要進行對於LLS訊令之處理，因此，步驟S225~S227之處理係被跳過。又，若是步驟S226或者是步驟S227之處理結束，則圖24之播送串流受訊處理係結束，處理係回到圖22之步驟S205或者是圖23之步驟S212處，並實行後續之處理。
又，在步驟S222中，當判定係並未取得LLS訊令的情況時，處理係前進至步驟S228處。在步驟S228中，係判定對象之ROUTE會談的種類。另外，如同上述一般，在ATSC3.0的情況時，雖然組件和訊令也會有藉由MMT會談而被傳輸的情況，但是，於此，為了使說明 簡單化，係僅針對使用有ROUTE會談的情況來作說明。
在步驟S228中，當判定ROUTE會談之種類係為視訊或音訊等之組件的情況時，處理係前進至步驟S229處。在步驟S229~S232中，係進行關連於藉由ROUTE會談所被傳輸的組件之處理。
具體而言，在步驟S229中，解碼器222以及組件處理部212，係進行組件受訊處理。在此組件受訊處理中，係對於構成播送節目等之內容的視訊和音訊之組件，而進行與特定之解碼方式相對應的解碼等之處理。
在步驟S230中，輸出部204，係進行渲染(rendering)處理。在此渲染處理中，基於步驟S229之處理結果，播送節目等之內容的影像和聲音係被播放並輸出。
在步驟S231中，FW/HW部211，係判定在藉由ROUTE會談所傳輸的DASH區段之事件訊息盒中是否包含有事件訊息。在步驟S231中，當判定係包含事件訊息的情況時，處理係前進至步驟S232處。
在步驟S232中，FW/HW部211(或者是MW部213)，係進行事件處理。在此事件處理中，係因應於被配置在DASH區段之事件訊息盒中的事件訊息，來在特定之時序處，進行關連於緊急警報應用程式(EAA)之處理。另外，針對此事件處理的詳細內容，係參考圖28之流程圖而於後再作敘述。又，在步驟S231中，當判定係並未包含事件訊息的情況時，步驟S232之處理係被跳 過。
又，在步驟S228中，當判定ROUTE會談之種類係為SLS訊令的情況時，處理係前進至步驟S233處。在步驟S233~S237中，係進行關連於藉由ROUTE會談所被傳輸的SLS訊令之處理。
具體而言，在步驟S233中，MW部213，係進行SLS訊令受訊解析處理。在此SLS訊令受訊解析處理中，藉由ROUTE會談而被傳輸的身為USD或MPD等的後設資料之SLS訊令，係被取得並被作解析。
在步驟S234中，係基於步驟S233之解析結果，來判定SLS訊令是否被作了更新。在步驟S234中，當判定SLS訊令係被作更新的情況時，處理係前進至步驟S235處。
在步驟S235中，係基於步驟S233之解析結果，來將SLS訊令之更新內容作反映。另外，在步驟S234中，當判定SLS訊令係並未被作更新的情況時，步驟S235之處理係被跳過。
在步驟S236中，MW部213，係基於步驟S233之解析結果，來判定在MPD之EventStream要素中是否包含有事件訊息。在步驟S236中，當判定係包含事件訊息的情況時，處理係前進至步驟S237處。
在步驟S237中，MW部213，係進行事件處理。在此事件處理中，係因應於被配置在MPD之EventStream要素中的事件訊息，來在特定之時序處，進 行關連於緊急警報應用程式(EAA)之處理。另外，針對此事件處理的詳細內容，係參考圖28之流程圖而於後再作敘述。又，在步驟S236中，當判定係並未包含事件訊息的情況時，步驟S237之處理係被跳過。
又，在步驟S228中，當判定ROUTE會談之種類係為LCC內容的情況時，處理係前進至步驟S238處。在步驟S238~S239中，係進行關連於藉由ROUTE會談所被傳輸的LCC內容之處理。
具體而言，在步驟S238中，係進行LCC內容受訊處理，並例如取得應用程式(例如，播送應用程式(BCA))或者是積蓄用之內容等的LCC內容。在步驟S239中，係進行區域快取(local cache)處理，在步驟S238之處理中所取得的LCC內容，係被積蓄(下載)在儲存設備(未圖示)中。
若是步驟S232、S237或者是S239之處理結束，則圖24之播送串流受訊處理係結束，處理係回到圖22之步驟S205或者是圖23之步驟S212處，並實行後續之處理。
以上，係針對播送串流受訊處理的流程作了說明。
(EAT受訊處理之流程)
接著，參考圖25~圖27之流程圖，針對與圖24之步驟S226之處理相對應的E-AIT受訊處理之詳細的內容 作說明。
於此，首先，參考圖25之流程圖，針對當藉由第1方式而啟動緊急警報應用程式(EAA)的情況時之E-AIT受訊處理作說明。另外，E-AIT被受訊時，由於係亦身為從送訊裝置10而被通知有緊急警報的期間，因此，在開始圖25之流程圖的處理時，於受訊裝置20之畫面上，係被顯示有作為緊急警報訊息(Universal Alert)之嵌入文本(burned-in text)。
在步驟S241中，常駐應用程式(RA)，係進行作為LLS訊令而被受訊的E-AIT之解析處理。於此，在E-AIT中，例如，係除了代表緊急警報的緊急性、重大性、對象地區、範疇以及優先度之資訊(基本資訊)以外，亦作為控制碼，而被設定有緊急警報應用程式(EAA)之自動啟動(autostart)。
在步驟S242中，常駐應用程式(RA)，係基於步驟S241之解析結果，來提示緊急警報之概要。於此，例如，是否要顯示與在E-AIT中所包含之基本資訊(例如，緊急性或對象地區等)相對應的緊急詳細資訊一事之選擇資訊，係作為EA圖符，而被顯示在受訊裝置20之畫面上(例如，圖6之D13)。
在步驟S243中，係判定是否由對於在步驟S242之處理中所提示了的緊急警報之概要(例如EA圖符等之選擇資訊)作了確認的使用者而下達有緊急詳細資訊之提示的指示。
在步驟S243中，例如，當作為EA圖符而被顯示之「是」按鍵被作了操作的情況時，由於係成為被下達有緊急詳細資訊之提示的指示，因此，處理係前進至步驟S244處。另外，於此情況，常駐應用程式(RA)，係成為發行緊急警報應用程式(EAA)之啟動事件(EAA啟動事件)。
在步驟S244中，瀏覽器214，係因應於藉由常駐應用程式(RA)所發行的EAA啟動事件，而取得作為LCC內容所被傳輸而來之緊急警報應用程式(EAA)並啟動之。藉由此，在受訊裝置20之畫面中，由緊急警報應用程式(EAA)所致之緊急詳細資訊，係與嵌入文本(burned-in text)之文字列一同地而被重疊顯示於播送節目之影像上(例如，圖6之D14)。
另一方面，在步驟S243中，例如，當作為EA圖符而被顯示之「否」按鍵被作了操作的情況時，由於係成為拒絕緊急詳細資訊之提示，步驟S244之處理係成為被跳過。而，若是步驟S244之處理結束，則處理係回到圖24之步驟S226，並實行後續之處理。
另外，在上述之步驟S242~S243之處理中，雖係藉由顯示與在E-AIT中所包含之基本資訊相對應的選擇資訊(例如EA圖符)，來判定是否因應於使用者操作而提示緊急詳細資訊，但是，判定方法係並不被限定於此，例如，係亦可構成為基於由使用者所預先設定的設定資訊(例如，是否要顯示關於氣象之資訊、是否要顯示學 校之臨時停課等之資訊、等等)，來判定是否要提示緊急詳細資訊。
又，在步驟S244之處理中，於啟動緊急警報應用程式(EAA)時，當播送應用程式(BCA)正被啟動的情況時，係成為先使啟動中之播送應用程式(BCA)暫時停止或者是結束，之後再啟動緊急警報應用程式(EAA)。
以上，係針對當藉由第1方式而啟動緊急警報應用程式(EAA)的情況時之E-AIT受訊處理的流程而作了說明。
接著，參考圖26之流程圖，針對當藉由第2方式或第3方式而啟動緊急警報應用程式(EAA)的情況時之E-AIT受訊處理的流程作說明。另外，E-AIT被受訊時，由於係亦身為從送訊裝置10而被通知有緊急警報的期間，因此，在開始圖26之流程圖的處理時，於受訊裝置20之畫面上，係被顯示有作為緊急警報訊息(Universal Alert)之嵌入文本(burned-in text)。
在步驟S251中，MW部213，係進行作為LLS訊令而被受訊的E-AIT之解析處理。於此，在E-AIT中，例如，係除了代表緊急警報的緊急性、重大性、對象地區、範疇以及優先度之資訊(基本資訊)以外，亦作為控制碼，而被設定有緊急警報應用程式(EAA)之自動啟動(autostart)。
在步驟S252中，MW部213，係判定播送應 用程式(BCA)是否為啟動中。
在步驟S252中，當判定播送應用程式(BCA)係為啟動中的情況時，處理係前進至步驟S253處。於此情況，由於係相當於上述之第3方式，因此，在步驟S253~S256中，係進行關連於第3方式之處理。
在步驟S253中，MW部213，係進行事件通知處理。在此事件通知處理中，如同參考圖20所作了說明一般，例如，當啟動中之播送應用程式(BCA)為藉由addEventListener方法而登錄有E-AIT受訊事件的情況時，係發行回呼(callback)事件，E-AIT受訊事件，係被通知至播送應用程式(BCA)處。
在步驟S254中，MW部213(或者是播送應用程式(BCA))，係基於步驟S251之解析結果，而判定是否要啟動緊急警報應用程式(EAA)。於此，例如，係可因應於從使用者而來之指示或者是設定資訊(例如顯示對象地區或顯示對象項目等之設定)，來判定是否要啟動緊急警報應用程式(EAA)。
在步驟S254中，當判定要啟動緊急警報應用程式(EAA)的情況時，處理係前進至步驟S255處。於此情況，MW部213，係成為發行緊急警報應用程式(EAA)之啟動事件(EAA啟動事件)。
在步驟S255中，瀏覽器214，係因應於從MW部213所發行的EAA啟動事件，而使啟動中之播送應用程式(BCA)暫時停止或者是結束。
在步驟S256中，瀏覽器214，係因應於從MW部213所發行的EAA啟動事件，而取得作為LCC內容所被傳輸而來之緊急警報應用程式(EAA)並啟動之。藉由此，在受訊裝置20之畫面中，由緊急警報應用程式(EAA)所致之緊急詳細資訊，係與嵌入文本(burned-in text)之文字列一同地而被重疊顯示於播送節目之影像上(例如，圖8之D34)。
另外，在步驟S254中，當判定並不啟動緊急警報應用程式(EAA)的情況時，步驟S255~S256之處理係被跳過。
另一方面，在步驟S252中，當判定播送應用程式(BCA)係並非為啟動中的情況時，處理係前進至步驟S257處。於此情況，由於係相當於上述之第2方式，因此，在步驟S257~S258中，係進行關連於第2方式之處理。
在步驟S257中，MW部213，係基於步驟S251之解析結果，而判定是否要啟動緊急警報應用程式(EAA)。於此，例如，係可因應於從使用者而來之指示或者是設定資訊(例如顯示對象地區或顯示對象項目等之設定)，來判定是否要啟動緊急警報應用程式(EAA)。
在步驟S257中，當判定要啟動緊急警報應用程式(EAA)的情況時，處理係前進至步驟S258處。於此情況，MW部213，係成為發行緊急警報應用程式(EAA)之啟動事件(EAA啟動事件)。
在步驟S258中，瀏覽器214，係因應於從MW部213所發行的EAA啟動事件，而取得作為LCC內容所被傳輸而來之緊急警報應用程式(EAA)並啟動之。藉由此，在受訊裝置20之畫面中，由緊急警報應用程式(EAA)所致之緊急詳細資訊，係與嵌入文本(burned-in text)之文字列一同地而被重疊顯示於播送節目之影像上(例如，圖7之D24)。
另外，在步驟S257中，當判定並不啟動緊急警報應用程式(EAA)的情況時，步驟S258之處理係被跳過。
若是步驟S256或S258之處理結束，則處理係回到圖24之步驟S226，並實行後續之處理。
以上，係針對當藉由第2方式或第3方式而啟動緊急警報應用程式(EAA)的情況時之E-AIT受訊處理的流程而作了說明。
接著，參考圖27之流程圖，針對當藉由第1方式~第3方式而結束緊急警報應用程式(EAA)的情況時之E-AIT受訊處理的流程作說明。
但是，作為圖27之流程圖的處理會被實行的前提，假設上述之圖25或圖26之流程圖的處理係被實行，緊急警報應用程式(EAA)係為已完成啟動者。故而，在受訊裝置20之畫面中，係與作為緊急警報訊息(Universal Alert)之嵌入文本(burned-in text)一同地，而被顯示有與進階內容(Advenced Content)相對應 之緊急詳細資訊(例如，圖6之D14、圖7之D24、圖8之D34)。
在步驟S261中，MW部213，係進行作為LLS訊令而被受訊的E-AIT之解析處理。於此，在E-AIT中，係作為控制碼，而被設定有緊急警報應用程式(EAA)之結束(terminate)。於此，MW部213，係成為發行緊急警報應用程式(EAA)之結束事件(EAA結束事件)。
在步驟S262中，瀏覽器214，係因應於從MW部213所發行的EAA結束事件，而使啟動中之緊急警報應用程式(EAA)結束。
在步驟S263中，MW部213(或者是瀏覽器214)，係判定播送應用程式(BCA)是否為暫時停止。於此，例如，係在圖26之步驟S255的處理中，判定啟動中之播送應用程式(BCA)是否被作了暫時停止。
在步驟S263中，當判定播送應用程式(BCA)係為暫時停止的情況時，處理係前進至步驟S264處。於此情況，MW部213，係成為發行播送應用程式(BCA)之再度開始事件(BCA再度開始事件)。
在步驟S264中，瀏覽器214，係因應於從MW部213所發行的BCA再度開始事件，而使暫時停止中之播送應用程式(BCA)的實行再度開始。藉由此，在受訊裝置20之畫面中，播送應用程式(BCA)之資訊，係被重疊顯示於播送節目之影像上。
又，在步驟S263中，當判定播送應用程式(BCA)係並未暫時停止的情況時，步驟S264之處理係被跳過。若是步驟S264之處理結束，則處理係回到圖24之步驟S226，並實行後續之處理。
以上，係針對當藉由第1方式~第3方式而結束緊急警報應用程式(EAA)的情況時之E-AIT受訊處理的流程而作了說明。
(事件處理)
最後，參考圖28之流程圖，針對與圖24之步驟S232或S237之處理相對應的事件處理之詳細的內容作說明。
在步驟S271中，FW/HW部211或者是MW部213，係進行事件解析處理。在此事件解析處理中，係進行被配置在DASH區段之事件訊息盒中之事件訊息或者是被配置在MPD之EventStream要素中之事件訊息的解析。
在步驟S272中，FW/HW部211或者是MW部213，係基於步驟S271之解析結果，而判定事件訊息是否身為關連於緊急警報應用程式(EAA)之事件訊息(EAA事件)。
在步驟S272中，當判定事件訊息係身為EAA事件訊息的情況時，處理係前進至步驟S273處。在步驟S273中，MW部213或瀏覽器214，係進行應用程式啟動 判定處理。在此啟動判定處理中，係判定播送應用程式(BCA)或者是緊急警報應用程式(EAA)是否正被啟動。
在步驟S273中，當判定播送應用程式(BCA)係正被啟動中的情況時，處理係前進至步驟S274處。在步驟S274中，MW部213或者是瀏覽器214，係進行事件通知處理。在此事件通知處理中，如同參考圖20所作了說明一般，例如，當播送應用程式(BCA)為藉由addEventListener方法而登錄有事件訊息(之事件)的情況時，係發行回呼(callback)事件，事件訊息(之事件)，係成為被通知至播送應用程式(BCA)處。
在步驟S275中，MW部213或者是瀏覽器214，係基於步驟S271之解析結果，而判定是否要啟動緊急警報應用程式(EAA)。另外，此啟動判定處理，係亦可由播送應用程式(BCA)進行。又，於此，例如，係可因應於從使用者而來之指示或者是設定資訊(例如顯示對象地區或顯示對象項目等之設定)，來判定是否要啟動緊急警報應用程式(EAA)。
在步驟S275中，當判定要啟動緊急警報應用程式(EAA)的情況時，處理係前進至步驟S276處。於此情況，MW部213，係成為發行緊急警報應用程式(EAA)之啟動事件(EAA啟動事件)。
在步驟S276中，瀏覽器214，係因應於從 MW部213所發行的EAA啟動事件，而使啟動中之播送應用程式(BCA)暫時停止或者是結束。
在步驟S277中，瀏覽器214，係因應於從MW部213所發行的EAA啟動事件，而取得作為LCC內容所被傳輸而來之緊急警報應用程式(EAA)並啟動之。藉由此，在受訊裝置20之畫面中，由緊急警報應用程式(EAA)所致之緊急詳細資訊，係與嵌入文本(burned-in text)之文字列一同地而被重疊顯示於播送節目之影像上。
另外，在步驟S275中，當判定並不啟動緊急警報應用程式(EAA)的情況時，步驟S276~S277之處理係被跳過。
又，在步驟S273中，當判定緊急警報應用程式(EAA)係正被啟動中的情況時，處理係前進至步驟S278處。在步驟S278中，MW部213或者是瀏覽器214，係進行事件通知處理。在此事件通知處理中，如同參考圖20所作了說明一般，例如，當緊急警報應用程式(EAA)為藉由addEventListener方法而登錄有事件訊息(之事件)的情況時，係發行回呼(callback)事件，事件訊息(之事件)，係成為被通知至緊急警報應用程式(EAA)處。
在步驟S279中，MW部213或者是瀏覽器214，係基於步驟S271之解析結果，而判定是否要更新緊急警報應用程式(EAA)。另外，此更新判定處理，係亦 可由緊急警報應用程式(EAA)進行。
在步驟S279中，當判定要更新緊急警報應用程式(EAA)的情況時，處理係前進至步驟S280處。於此情況，MW部213，係成為發行緊急警報應用程式(EAA)之變遷事件(EAA變遷事件)。
在步驟S280中，瀏覽器214，係因應於從MW部213所發行的EAA變遷事件，而更新緊急警報應用程式(EAA)。於此，例如，當緊急警報應用程式(EAA1)正被啟動的情況時，藉由啟動緊急警報應用程式(EAA2)，由緊急警報應用程式(EAA)所致之資訊係成為有所變遷。藉由此，在受訊裝置20之畫面處，緊急警報應用程式(EAA1)之資訊係被更新，並被顯示有緊急警報應用程式(EAA2)之資訊(例如，圖9之D44)。
另外，在步驟S279中，當判定並不更新緊急警報應用程式(EAA)的情況時，步驟S280之處理係被跳過。
又，在步驟S273中，當判定播送應用程式(BCA)和緊急警報應用程式(EAA)均未被啟動的情況時，處理係前進至步驟S281處。
在步驟S281中，MW部213或者是瀏覽器214，係基於步驟S271之解析結果，而進行緊急警報應用程式(EAA)之啟動處理。藉由此，在受訊裝置20之畫面中，由緊急警報應用程式(EAA)所致之緊急詳細資 訊，係與嵌入文本(burned-in text)之文字列一同地而被重疊顯示於播送節目之影像上。
另外，在步驟S272中，當判定事件訊息係並非為EAA事件訊息的情況時，處理係前進至步驟S282處。在步驟S282中，MW部213或者是瀏覽器214等，係進行與EAA事件以外的其他之事件訊息相對應的事件處理。
若是步驟S277、S280、S281或者是S282之處理結束，則處理係回到圖24之步驟S232或S237之處理處，並實行後續之處理。
以上，係針對事件處理之流程作了說明。
<4.變形例>
作為上述之說明，針對數位播送之規格，係對於身為在美國等處所採用的方式之ATSC(特別是ATSC3.0)來作了說明，但是，本技術，係亦可對於身為在日本等處所採用的方式之ISDB(Integrated Services Digital Broadcasting)或者是身為在歐洲各國處所採用的方式之DVB(Digital Video Broadcasting)等作適用。又，在傳輸系統1中，傳輸路徑80，係並不被限定於地上波播送，例如，亦可為對於播送衛星(BS：Broadcasting Satellite)或通訊衛星(CS：Communications Satellite)作了利用的衛星播送，或者是使用有纜線之有線播送(CATV)等。進而，在上述之說 明中，雖係以美國之緊急通知的系統(EAS)作為其中一例來作了說明，但是，係亦可對於在各國所建構的同樣之系統作適用。
又，上述之LLS或SLS等之訊令的名稱，係僅為其中一例，而亦會有使用其他之名稱的情形。但是，此些之名稱的差異，係僅為形式上的差異，而並非為各訊令之實質性的內容上之差異。進而，在訊令為藉由XML等之標記語言來記述的情況時，該些之要素或屬性的名稱亦僅為其中一例，而亦可採用其他之名稱。但是，此些之名稱的差異，係僅為形式上的差異，而並非為該些之要素或屬性之實質性的內容上之差異。又，LCC(Locally Cached Content)，也會有被稱作NRT(Non Real Time)的情況，但是，此並非為實質性的內容上之差異。
<5.電腦之構成>
上述之一連串的處理，係可藉由硬體來實行，亦可藉由軟體來實行。在藉由軟體來實行一連串的處理的情況時，構成該軟體之程式，係被安裝於電腦中。圖29，係為對於藉由程式來實行上述之一連串的處理之電腦的硬體之構成例作展示之圖。
在電腦900中，CPU(Central Processing Unit)901、ROM(Read Only Memory)902、RAM(Random Access Memory)903，係藉由匯流排904而被相互作連接。在匯流排904處，係被連接有輸入輸出介面 905。在輸入輸出介面905處，係被連接有輸入部906、輸出部907、記錄部908、通訊部909以及驅動裝置910。
輸入部906，係由鍵盤、滑鼠、麥克風等所成。出力部907，係由顯示器、揚聲器等所成。記錄部908，係由硬碟或非揮發性之記憶體等所成。通訊部909，係由網路介面等所成。驅動裝置910，係驅動磁碟、光碟、光磁碟或者是半導體記憶體等之可移除式媒體911。
在如同上述一般所構成之電腦900中，CPU901，係將被記錄在ROM902或記錄部908中之程式，透過輸入輸出介面905以及匯流排904來載入至RAM903中並實行，藉由此，來進行上述之一連串的處理。
電腦900(CPU901)所實行的程式，例如，係可記錄在作為封裝媒體等之可移除式媒體911中並作提供。又，程式，係可透過像是區域網路、網際網路、數位衛星播送一般之有線或無線的傳輸媒體來提供之。
在電腦900處，程式，係可藉由將可移除式媒體911裝著在驅動裝置910中，來透過輸入輸出介面905而安裝至記錄部908中。又，程式，係可透過有線或無線的傳輸媒體，來藉由通訊部909而受訊，並安裝至記錄部908中。除此之外，程式，係亦可預先安裝在ROM902或記錄部908中。
於此，在本說明書中，電腦依據程式所進行之處理，係並非一定需要沿著作為流程圖所記載的順序來以時間系列而進行處理。亦即是，電腦依據程式所進行之處理，係亦包含平行地或者是個別地被實行之處理(例如，平行處理或者是由物件所致之處理)。又，程式，係可為藉由1個的電腦(處理器)所進行處理者，亦可為藉由複數之電腦而被進行分散處理者。
另外，本技術之實施形態，係並不被限定於上述之實施形態，在不脫離本技術之要旨的範圍內，係可作各種之變更。
又，本技術，係可如同下述一般地而構成。
(1)
一種受訊裝置，其特徵為，係具備有：受訊部，係受訊數位播送訊號；和處理部，係基於控制資訊，來進行關連於提示緊急資訊之詳細資訊的緊急資訊應用程式之處理，該控制資訊，係為在前述數位播送訊號中所包含之控制資訊，並包含關連於有必要緊急進行通知之前述緊急資訊的詳細資訊之資訊。
(2)
如(1)所記載之受訊裝置，其中，前述控制資訊，係包含代表前述緊急資訊之緊急性、重大性、對象地區、範疇(category)以及優先度的資訊中之至少1個的資訊，前述處理部，係基於前述控制資訊，來判定是否要啟 動前述緊急資訊應用程式。
(3)
如(2)所記載之受訊裝置，其中，前述處理部，係基於前述控制資訊，而顯示是否要提示前述緊急資訊的詳細資訊之選擇資訊，當由使用者而選擇了前述緊急資訊的詳細資訊之提示的情況時，啟動前述緊急資訊應用程式。
(4)
如(2)所記載之受訊裝置，其中，前述處理部，係基於預先由使用者所設定的設定資訊，來啟動前述緊急資訊應用程式。
(5)
如(2)~(4)中之任一項所記載之受訊裝置，其中，前述控制資訊，係更進而包含用以對於前述緊急資訊應用程式之生命周期作控制的指令，前述處理部，係基於前述控制資訊，來對於前述緊急資訊應用程式之動作作控制。
(6)
如(5)所記載之受訊裝置，其中，前述處理部，當在前述控制資訊中所包含之指令為代表前述緊急資訊應用程式之啟動，並且啟動前述緊急資訊應用程式的情況時，當於通常時所被實行之播送應用程式正被啟動時，進行使前述緊急資訊應用程式啟動並且使前述播送應用程式暫時停止或者是結束之控制，當在前述控制資訊中所包含之指令為代表前述緊急資訊應用程式之結束的情況時，當前述 緊急資訊應用程式正被啟動時，進行使前述緊急資訊應用程式結束之控制。
(7)
如(6)所記載之受訊裝置，其中，前述處理部，當在前述控制資訊中所包含之指令為代表前述緊急資訊應用程式之結束的情況時，當前述播送應用程式正成為暫時停止時，進行使暫時停止中之前述播送應用程式的動作再度開始之控制。
(8)
如(2)~(7)中之任一項所記載之受訊裝置，其中，前述處理部，係基於在前述數位播送訊號中所包含之事件訊息，來在特定之時序處，實行關連於前述緊急資訊應用程式之處理。
(9)
如(8)所記載之受訊裝置，其中，前述事件訊息，係被配置在藉由MPEG-DASH(Dynamic Adaptive Streaming over HTTP)所規定之MPD(Media Presentation Description)的事件串流要素、或者是DASH區段之事件訊息盒中。
(10)
如前述(1)~(9)中之任一項所記載之受訊裝置，其中，前述數位播送訊號，係為IP(Internet Protocol)傳輸方式之數位播送訊號，前述控制資訊，係被配置在IP封包中所包含之UDP(User Datagram Protocol)封包的酬 載(payload)中並被作傳輸。
(11)
一種資料處理方法，係為受訊裝置之資料處理方法，其特徵為，係包含有下述步驟：使前述受訊裝置，受訊數位播送訊號，並基於控制資訊，來進行關連於提示緊急資訊之詳細資訊的緊急資訊應用程式之處理，該控制資訊，係為在前述數位播送訊號中所包含之控制資訊，並包含關連於有必要緊急進行通知之前述緊急資訊的詳細資訊之資訊。
(12)
一種送訊裝置，其特徵為，係具備有：產生部，係產生控制資訊，該控制資訊，係包含關連於有必要緊急進行通知之緊急資訊的詳細資訊之資訊，並被使用在關連於提示前述緊急資訊之詳細資訊的緊急資訊應用程式之處理中；和送訊部，係將所產生了的前述控制資訊，包含於數位播送訊號中並進行送訊。
(13)
如(12)所記載之送訊裝置，其中，前述控制資訊，係包含代表前述緊急資訊之緊急性、重大性、對象地區、範疇(category)以及優先度的資訊中之至少1個的資訊。
(14)
如(13)所記載之送訊裝置，其中，前述控制資訊，係更進而包含用以對於前述緊急資訊應用程式之生命周期 作控制的指令。
(15)
如(13)或(14)所記載之送訊裝置，其中，前述產生部，係產生用以在特定之時序處而實行關連於前述緊急資訊應用程式之處理之事件訊息，前述送訊部，係將所產生了的前述事件訊息，包含於前述數位播送訊號中並進行送訊。
(16)
如(15)所記載之送訊裝置，其中，前述事件訊息，係被配置在藉由MPEG-DASH所規定之MPD的事件串流要素、或者是DASH區段之事件訊息盒中。
(17)
如(12)~(16)中之任一項所記載之送訊裝置，其中，前述數位播送訊號，係為IP傳輸方式之數位播送訊號，前述控制資訊，係被配置在IP封包中所包含之UDP封包的酬載中並被作傳輸。
(18)
一種資料處理方法，係為送訊裝置之資料處理方法，其特徵為，係包含有下述之步驟：使前述送訊裝置，產生控制資訊，該控制資訊，係包含關連於有必要緊急進行通知之緊急資訊的詳細資訊之資訊，並被使用在關連於提示前述緊急資訊之詳細資訊的緊急資訊應用程式之處理中，將所產生了的前述控制資訊，包含於數位播送訊號中並進行送訊。
1‧‧‧傳輸系統
10-1、10-2‧‧‧送訊裝置
20-1、20-2、20-3‧‧‧受訊裝置
30‧‧‧電波塔
40‧‧‧EA伺服器
80‧‧‧傳輸路徑
90‧‧‧通訊線路

Claims (18)

  1. 一種受訊裝置，其特徵為，係具備有：受訊部，係受訊數位播送訊號；和處理部，係基於控制資訊，來進行關連於提示緊急資訊之詳細資訊的緊急資訊應用程式之處理，該控制資訊，係為在前述數位播送訊號中所包含之控制資訊，並包含關連於有必要緊急進行通知之前述緊急資訊的詳細資訊之資訊。
  2. 如申請專利範圍第1項所記載之受訊裝置，其中，前述控制資訊，係包含代表前述緊急資訊之緊急性、重大性、對象地區、範疇(category)以及優先度的資訊中之至少1個的資訊，前述處理部，係基於前述控制資訊，來判定是否要啟動前述緊急資訊應用程式。
  3. 如申請專利範圍第2項所記載之受訊裝置，其中，前述處理部，係基於前述控制資訊，而顯示是否要提示前述緊急資訊的詳細資訊之選擇資訊，當由使用者而選擇了前述緊急資訊的詳細資訊之提示的情況時，啟動前述緊急資訊應用程式。
  4. 如申請專利範圍第2項所記載之受訊裝置，其中，前述處理部，係基於預先由使用者所設定的設定資訊，來啟動前述緊急資訊應用程式。
  5. 如申請專利範圍第2項所記載之受訊裝置，其中，前述控制資訊，係更進而包含用以對於前述緊急資訊 應用程式之生命周期作控制的指令，前述處理部，係基於前述控制資訊，來對於前述緊急資訊應用程式之動作作控制。
  6. 如申請專利範圍第5項所記載之受訊裝置，其中，前述處理部，當在前述控制資訊中所包含之指令為代表前述緊急資訊應用程式之啟動，並且啟動前述緊急資訊應用程式的情況時，當於通常時所被實行之播送應用程式正被啟動時，進行使前述緊急資訊應用程式啟動並且使前述播送應用程式暫時停止或者是結束之控制，當在前述控制資訊中所包含之指令為代表前述緊急資訊應用程式之結束的情況時，當前述緊急資訊應用程式正被啟動時，進行使前述緊急資訊應用程式結束之控制。
  7. 如申請專利範圍第6項所記載之受訊裝置，其中，前述處理部，當在前述控制資訊中所包含之指令為代表前述緊急資訊應用程式之結束的情況時，當前述播送應用程式正成為暫時停止時，進行使暫時停止中之前述播送應用程式的動作再度開始之控制。
  8. 如申請專利範圍第2項所記載之受訊裝置，其中，前述處理部，係基於在前述數位播送訊號中所包含之事件訊息，來在特定之時序處，實行關連於前述緊急資訊應用程式之處理。
  9. 如申請專利範圍第8項所記載之受訊裝置，其中， 前述事件訊息，係被配置在藉由MPEG-DASH(Dynamic Adaptive Streaming over HTTP)所規定之MPD(Media Presentation Description)的事件串流要素、或者是DASH區段之事件訊息盒中。
  10. 如申請專利範圍第1項所記載之受訊裝置，其中，前述數位播送訊號，係為IP(Internet Protocol)傳輸方式之數位播送訊號，前述控制資訊，係被配置在IP封包中所包含之UDP(User Datagram Protocol)封包的酬載(payload)中並被作傳輸。
  11. 一種資料處理方法，係為受訊裝置之資料處理方法，其特徵為，係包含有下述步驟：使前述受訊裝置，受訊數位播送訊號，並基於控制資訊，來進行關連於提示緊急資訊之詳細資訊的緊急資訊應用程式之處理，該控制資訊，係為在前述數位播送訊號中所包含之控制資訊，並包含關連於有必要緊急進行通知之前述緊急資訊的詳細資訊之資訊。
  12. 一種送訊裝置，其特徵為，係具備有：產生部，係產生控制資訊，該控制資訊，係包含關連於有必要緊急進行通知之緊急資訊的詳細資訊之資訊，並被使用在關連於提示前述緊急資訊之詳細資訊的緊急資訊應用程式之處理中；和送訊部，係將所產生了的前述控制資訊，包含於數位 播送訊號中並進行送訊。
  13. 如申請專利範圍第12項所記載之送訊裝置，其中，前述控制資訊，係包含代表前述緊急資訊之緊急性、重大性、對象地區、範疇(category)以及優先度的資訊中之至少1個的資訊。
  14. 如申請專利範圍第13項所記載之送訊裝置，其中，前述控制資訊，係更進而包含用以對於前述緊急資訊應用程式之生命周期作控制的指令。
  15. 如申請專利範圍第13項所記載之送訊裝置，其中，前述產生部，係產生用以在特定之時序處而實行關連於前述緊急資訊應用程式之處理之事件訊息，前述送訊部，係將所產生了的前述事件訊息，包含於前述數位播送訊號中並進行送訊。
  16. 如申請專利範圍第15項所記載之送訊裝置，其中，前述事件訊息，係被配置在藉由MPEG-DASH所規定之MPD的事件串流要素、或者是DASH區段之事件訊息盒中。
  17. 如申請專利範圍第12項所記載之送訊裝置，其中，前述數位播送訊號，係為IP傳輸方式之數位播送訊號，前述控制資訊，係被配置在IP封包中所包含之UDP封包的酬載中並被作傳輸。
  18. 一種資料處理方法，係為送訊裝置之資料處理方法，其特徵為，係包含有下述之步驟：使前述送訊裝置，產生控制資訊，該控制資訊，係包含關連於有必要緊急進行通知之緊急資訊的詳細資訊之資訊，並被使用在關連於提示前述緊急資訊之詳細資訊的緊急資訊應用程式之處理中，將所產生了的前述控制資訊，包含於數位播送訊號中並進行送訊。
TW105127700A 2015-09-14 2016-08-29 受訊裝置、送訊裝置及資料處理方法 TW201725878A (zh)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2015180785 2015-09-14

Publications (1)

Publication Number Publication Date
TW201725878A true TW201725878A (zh) 2017-07-16

Family

ID=58289047

Family Applications (1)

Application Number Title Priority Date Filing Date
TW105127700A TW201725878A (zh) 2015-09-14 2016-08-29 受訊裝置、送訊裝置及資料處理方法

Country Status (8)

Country Link
US (2) US10594419B2 (zh)
EP (1) EP3352468A4 (zh)
JP (1) JPWO2017047397A1 (zh)
KR (1) KR102468131B1 (zh)
CA (1) CA2997897C (zh)
MX (1) MX2018002853A (zh)
TW (1) TW201725878A (zh)
WO (1) WO2017047397A1 (zh)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102425988B1 (ko) * 2015-04-01 2022-07-29 삼성전자주식회사 방송 시스템에서의 비상 통보 메시지를 처리하는 장치 및 방법
MX2020009565A (es) 2018-03-22 2020-10-05 Sony Corp Dispositivo de recepción, método de recepción, dispositivo de procesamiento de señal y método de procesamiento de señal.
US11490169B2 (en) * 2019-07-02 2022-11-01 Tencent America LLC Events in timed metadata tracks
WO2023225711A1 (en) * 2022-05-24 2023-11-30 Emergency Warning Systems Ltd Mass communication system

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8572645B2 (en) * 2009-01-18 2013-10-29 Lg Electronics Inc. IPTV and method for controlling emergency alert system widget in IPTV
US8949885B2 (en) * 2010-07-30 2015-02-03 Echostar Technologies L.L.C. Systems, methods and apparatus for transmitting weather information in a television distribution network
US9078031B2 (en) 2010-10-01 2015-07-07 Sony Corporation Reception apparatus, reception method, and program
US9590814B2 (en) 2011-08-01 2017-03-07 Qualcomm Incorporated Method and apparatus for transport of dynamic adaptive streaming over HTTP (DASH) initialization segment description fragments as user service description fragments
WO2013129781A1 (ko) * 2012-03-02 2013-09-06 엘지전자 주식회사 모바일 방송을 통하여 긴급 경보 서비스를 제공하는 장치 및 방법
JP5974392B2 (ja) 2012-04-05 2016-08-23 ホアウェイ・テクノロジーズ・カンパニー・リミテッド Ｉｓｏベースメディアファイルフォーマットに基づく適応ストリーミングについてのセキュアな非同期イベント通知のためのシステム及び方法
US9288278B2 (en) 2013-03-14 2016-03-15 Arris Enterprises, Inc. Providing user content with streamed media chunks
JP2015080172A (ja) 2013-10-18 2015-04-23 ソニー株式会社 受信装置及び受信方法、コンピューター・プログラム、並びに外部機器
JP2015104055A (ja) 2013-11-27 2015-06-04 ソニー株式会社 受信装置、受信方法、送信装置、及び、送信方法
JP6252166B2 (ja) 2013-12-26 2017-12-27 株式会社Ｊｖｃケンウッド デジタル放送装置及びデジタル放送方法
JP2017511989A (ja) * 2014-01-02 2017-04-27 エルジー エレクトロニクス インコーポレイティド 放送受信装置及び放送受信装置の動作方法
WO2015199468A1 (ko) * 2014-06-26 2015-12-30 엘지전자 주식회사 방송 신호 송/수신 처리 방법 및 장치

Also Published As

Publication number Publication date
US20180205473A1 (en) 2018-07-19
WO2017047397A1 (ja) 2017-03-23
KR20180053647A (ko) 2018-05-23
KR102468131B1 (ko) 2022-11-18
EP3352468A4 (en) 2019-04-24
US11184095B2 (en) 2021-11-23
CA2997897C (en) 2022-09-27
EP3352468A1 (en) 2018-07-25
US20200280381A1 (en) 2020-09-03
MX2018002853A (es) 2018-06-15
US10594419B2 (en) 2020-03-17
CA2997897A1 (en) 2017-03-23
JPWO2017047397A1 (ja) 2018-07-05

Similar Documents

Publication Publication Date Title
US10623827B2 (en) Receiving device, receiving method, transmitting device, and transmitting method
US11184095B2 (en) Receiving apparatus, transmitting apparatus, and data processing method
US10863247B2 (en) Receiving device and data processing method
KR101760445B1 (ko) 수신 장치, 수신 방법, 송신 장치 및 송신 방법
KR102527738B1 (ko) 비상 정보의 로케이션 기반 필터링을 위한 수신 장치, 수신 방법, 송신 장치 및 송신 방법
TW201743621A (zh) 用於傳訊緊急警示之系統及方法
US20240171828A1 (en) Receiving device, receiving method, signal processing device, and signal processing method
TWI751112B (zh) 受訊裝置、送訊裝置及資料處理方法
JPWO2016035588A1 (ja) 受信装置、受信方法、送信装置、及び、送信方法
KR102723856B1 (ko) 수신 장치, 수신 방법, 신호 처리 장치 및 신호 처리 방법