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

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

Info

Publication number
TW201724787A
TW201724787A TW105126776A TW105126776A TW201724787A TW 201724787 A TW201724787 A TW 201724787A TW 105126776 A TW105126776 A TW 105126776A TW 105126776 A TW105126776 A TW 105126776A TW 201724787 A TW201724787 A TW 201724787A
Authority
TW
Taiwan
Prior art keywords
information
emergency information
data
emergency
embedded
Prior art date
Application number
TW105126776A
Other languages
English (en)
Other versions
TWI751112B (zh
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 TW201724787A publication Critical patent/TW201724787A/zh
Application granted granted Critical
Publication of TWI751112B publication Critical patent/TWI751112B/zh

Links

Classifications

    • 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
    • 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
    • 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
    • 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/431—Generation of visual interfaces for content selection or interaction; Content or additional data rendering
    • 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/431—Generation of visual interfaces for content selection or interaction; Content or additional data rendering
    • H04N21/4312—Generation of visual interfaces for content selection or interaction; Content or additional data rendering involving specific graphical features, e.g. screen layout, special fonts or colors, blinking icons, highlights or animations
    • 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/431—Generation of visual interfaces for content selection or interaction; Content or additional data rendering
    • H04N21/4312—Generation of visual interfaces for content selection or interaction; Content or additional data rendering involving specific graphical features, e.g. screen layout, special fonts or colors, blinking icons, highlights or animations
    • H04N21/4316—Generation of visual interfaces for content selection or interaction; Content or additional data rendering involving specific graphical features, e.g. screen layout, special fonts or colors, blinking icons, highlights or animations for displaying supplemental content in a region of the screen, e.g. an advertisement in a separate window
    • 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
    • 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
    • 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/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64322—IP

Landscapes

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

Abstract

本技術，係有關於能夠將在緊急時所被通知的緊急資訊顯示在適當之位置處之受訊裝置、送訊裝置以及資料處理方法。受訊裝置，係取得後設資料(meta data)，該後設資料，係為藉由數位播送訊號所傳輸之後設資料，並包含有：第1緊急資訊，係為有必要緊急進行告知之資訊、和顯示位置資訊，係代表在非壓縮之視訊資料中是否被嵌入有第2緊急資訊，並且當在非壓縮之視訊資料中被嵌入有第2緊急資訊的情況時而代表該第2緊急資訊之在該畫面上的顯示位置，對於前述後設資料進行處理，並當在非壓縮之視訊資料中被嵌入有第2緊急資訊的情況時，在與第2緊急資訊之畫面上的顯示位置相異之位置處，顯示第1緊急資訊。本技術，例如係可對於電視受像機作適用。

Description

受訊裝置、送訊裝置及資料處理方法
本技術，係有關於受訊裝置、送訊裝置以及資料處理方法，特別是有關於能夠將在緊急時所被通知的緊急資訊顯示在適當之位置處之受訊裝置、送訊裝置以及資料處理方法。
在數位播送的技術領域中，係進行有為了於緊急時將身為有必要緊急進行告知的資訊之緊急資訊作通知的各種之提案(例如，參考專利文獻1)。
〔先行技術文獻〕 〔專利文獻〕
〔專利文獻1〕日本特開2015-104055號公報
另外，在緊急情況時，當以複數之方式來通知緊急資訊時，由於係會有無法將緊急資訊顯示在適當之 位置的可能性，因此，係對於用以將緊急資訊顯示在適當之位置的方案有所需求。
本技術，係為有鑑於此種狀況而進行者，並為能夠將在緊急時所被通知的緊急資訊顯示於適當之位置處者。
本技術之第1側面之受訊裝置，其特徵為，係具備有：受訊部，係受訊數位播送訊號；和取得部，係取得後設資料(meta data)，該後設資料，係為藉由前述數位播送訊號所傳輸之後設資料，並包含有：第1緊急資訊，係為有必要緊急進行告知之資訊、和顯示位置資訊，係代表在非壓縮之視訊資料中是否被嵌入有第2緊急資訊，並且當在前述非壓縮之視訊資料中被嵌入有前述第2緊急資訊的情況時而代表前述第2緊急資訊之在該畫面上的顯示位置；和處理部，係對於前述後設資料進行處理，並當在前述非壓縮之視訊資料中被嵌入有前述第2緊急資訊的情況時，在與前述第2緊急資訊之畫面上的顯示位置相異之位置處，顯示前述第1緊急資訊。
本技術之第1側面之受訊裝置，係可為獨立之裝置，亦可為構成1個裝置的內部區塊。又，本技術之第1側面之資料處理方法，係為對應於上述之本技術之第1側面之受訊裝置的資料處理方法。
在本技術之第1側面之受訊裝置以及資料處 理方法中，係受訊數位播送訊號，並取得後設資料(meta data)，該後設資料，係為藉由前述數位播送訊號所傳輸之後設資料，並包含有：第1緊急資訊，係為有必要緊急進行告知之資訊、和顯示位置資訊，係代表在非壓縮之視訊資料中是否被嵌入有第2緊急資訊，並且當在前述非壓縮之視訊資料中被嵌入有前述第2緊急資訊的情況時而代表前述第2緊急資訊之在該畫面上的顯示位置，對於前述後設資料進行處理，並當在前述非壓縮之視訊資料中被嵌入有前述第2緊急資訊的情況時，在與前述第2緊急資訊之畫面上的顯示位置相異之位置處，顯示前述第1緊急資訊。
本技術之第2側面之送訊裝置，其特徵為，係具備有：產生部，係產生後設資料(meta data)，該後設資料，係包含有：第1緊急資訊，係為有必要緊急進行告知之資訊、和顯示位置資訊，係代表在非壓縮之視訊資料中是否被嵌入有第2緊急資訊，並且當在前述非壓縮之視訊資料中被嵌入有前述第2緊急資訊的情況時而代表前述第2緊急資訊之在受訊裝置之畫面上的顯示位置；和送訊部，係將前述後設資料，作為數位播送訊號來送訊。
本技術之第2側面之送訊裝置，係可為獨立之裝置，亦可為構成1個裝置的內部區塊。又，本技術之第2側面之資料處理方法，係為對應於上述之本技術之第2側面之送訊裝置的資料處理方法。
在本技術之第2側面之送訊裝置以及資料處 理方法中，係產生後設資料(meta data)，該後設資料，係包含有：第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‧‧‧濾波器
900‧‧‧電腦
901‧‧‧CPU
〔圖1〕係為對於適用有本技術之傳輸系統的其中一種實施形態之構成作展示之圖。
〔圖2〕係為對於當採用了IP傳輸方式之數位播送的情況時之緊急資訊之傳輸方式的概要作展示之圖。
〔圖3〕係為對於LLS表之語法(syntax)之例作展示之圖。
〔圖4〕係為對於緊急資訊之顯示例作展示之圖。
〔圖5〕係為對於橫幅文本(banner text)之顯示例作展示之圖。
〔圖6〕係為對於EAT後設資料之語法之例作展示之圖。
〔圖7〕係為對於傳輸系統的各裝置之構成例作展示之圖。
〔圖8〕係為對於送訊處理的流程作說明之流程圖。
〔圖9〕係為對於電源OFF、待機狀態時之受訊處理的流程作說明之流程圖。
〔圖10〕係為對於電源OFF狀態時之受訊處理的流程作說明之流程圖。
〔圖11〕係為對於播送串流受訊處理的流程作說明之流程圖。
〔圖12〕係為對於EAT受訊處理的流程作說明之流程圖。
〔圖13〕係為對於橫幅文本顯示處理的流程作說明之流程圖。
〔圖14〕係為對於電腦的構成例作展示之圖。
以下，參考圖面，對本技術之實施形態作說明。另外，係依照以下之順序而進行說明。
1. 適用有本技術之傳輸系統的運用 2. 語法之例 3. 各裝置之構成 4. 藉由各裝置所實行的處理之流程 5. 變形例 6. 電腦之構成 〈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資訊，嵌入至電視節目的影像(非壓縮之視訊資料)中而進行編碼，或者是轉換為特定之格式(例如，後述之EAT後設資料)，來產生緊急資訊。之後，播送台(之送訊裝 置10)，係將所產生的緊急資訊，對於播送區域內之多數的受訊裝置20(例如，受訊裝置20-1~20-3)而進行送訊。
藉由此，在受訊裝置20處，係成為在電視節目的影像上重疊顯示有緊急資訊。其結果，使用者，係能夠對於被顯示在受訊裝置20之畫面上的緊急資訊(例如文本資訊)作確認。
另外，在以下之說明中，係將被顯示在受訊裝置20之畫面上的緊急資訊(文本資訊)中之被嵌入至電視節目等的內容之影像(非壓縮之視訊資料)中並作了編碼的緊急資訊，稱作嵌入文本。此嵌入文本，係亦被記述為「Burned EA Message」或者是「EA text」。
另一方面，係將被顯示在受訊裝置20之畫面上的緊急資訊(文本資訊)中之將CAP資訊轉換為特定之格式(例如，後述之EAT後設資料)所得到的緊急資訊，稱作橫幅文本。此橫幅文本，係亦被記述為「banner text」。
又，播送台(之送訊裝置10)，係能夠基於與從緊急資訊來源而來之緊急資訊來源資訊相對應的CAP資訊，來產生緊急資訊應用程式(例如，關連於緊急資訊之更為詳細的資訊)，並提供至EA伺服器40處。另外，此緊急資訊應用程式，係亦被記述為「EA APP」。
受訊裝置20，當具備有通訊功能的情況時，係能夠經由網際網路或行動電話網路等之通訊線路90來 對於EA伺服器40進行存取，並要求緊急資訊應用程式。之後，受訊裝置20，係能夠透過通訊線路90，來受訊從EA伺服器40所配送的緊急資訊應用程式並實行之。藉由此，在受訊裝置20之畫面處，例如係成為顯示有關連於緊急資訊之更為詳細的資訊。
另外，在播送台(之送訊裝置10)處，作為緊急資訊之產生方法，係並不被限定於上述之方法，例如，係亦可構成為使用像是將CAP資訊直接以原本的形式來作使用等之其他的產生方法。又，作為用以產生緊急資訊的資訊之CAP資訊，係僅為其中一例，亦可構成為使用將緊急資訊來源資訊轉換為準據於其他方式之形式所得到的資訊等，來產生緊急資訊。
另外，在各國之數位播送的規格中，作為傳輸方式，係採用有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之資料傳輸。
(IP傳輸方式之緊急資訊之傳輸方式)
圖2，係為對於當採用了IP傳輸方式之數位播送的情況時之緊急資訊之傳輸方式的概要作展示之圖。
在圖2中，於左側所示之管狀圖，係代表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)、EAT(Emergency Alerting Table)等之後設資料。SLT後設資料，係包含有像是在服務之選台中所必要的資訊(選台資訊)等的代表播送網路中之串流或服務之構成的資訊。RRT後設資料，係包含有關於分級(RATING)之資 訊。EAT後設資料，係包含有關連於身為有必要緊急進行告知之資訊的緊急資訊(緊急警報資訊)之資訊。
另外，SLT或EAT等之後設資料，係藉由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後設資料，係為用以對於組件之串流的播放作管理之控制資訊。
另外，USD、S-TSID、MPD等之後設資料，係藉由XML等之標示語言而被作記述。又，MPD後設資 料，係準據於MPEG-DASH(Dynamic Adaptive Streaming over HTTP)之規格。
組件，係為構成視訊或音訊、字幕等的內容之資料。又，LCC內容，係為被積蓄(下載)於受訊裝置20之儲存設備中再被進行處理的內容。但是，LCC，係會有被稱作NRT(Non Real Time)的情況。
另外，雖係為了使說明簡略化而有所省略，但是，在PLP串流中，係成為亦被傳輸有作為時刻資訊之NTP(Network Time Protocol)和作為電子服務導引之ESG(Electronic Service Guide)服務等的串流。
在圖2之管狀圖中，於播送串流中，係包含有成為相異之PLP ID之2個的PLP串流，但是，其中一方(圖中之上方)之PLP串流，係被設為通常之PLP串流，另外一方(圖中之下方)之PLP串流，則係被設為高穩健性(robustness)之PLP串流。
在此例中，係藉由通常之PLP串流，來傳輸服務之組件和SLS訊令，並藉由高穩健性之PLP串流，來傳輸LLS訊令和LCC內容之串流。故而，係能夠確實地傳輸LLS訊令和LCC內容。又，在此例中，LLS訊令，係在複數之服務中被共通地使用。
於此，若是對於圖中之以點線L所包圍的部份、亦即是傳輸LLS訊令之串流作注目，則在緊急時，作為LLS訊令之EAT後設資料，係成為如同下述一般地被傳輸。
於此，在IP傳輸方式之通訊協定堆疊中，最下位之階層，係被設為物理層(L1：Layer1)，與此物理層相鄰接之上位之階層，係被設為Layer 2之階層(L2：Layer2)，進而，與Layer 2之階層相鄰接之上位之階層，係被設為IP層，與IP層相鄰接之上位之階層，係被設為UDP層。
亦即是，如同圖2之右側之訊框(封包)的構造圖中所示一般，物理層之L1訊框(L1 Frame)，係由L1標頭和L1酬載所構成。在此L1標頭中，係包含有用以在緊急時將電源OFF並且為待機狀態之受訊裝置20啟動的喚醒旗標(wake-up flag)。又，在L1酬載中，係被配置有複數之ALP(ATSC Link-layer Protocol)封包。
此ALP封包，係為Layer 2之階層之傳輸封包，在其之ALP酬載中，係被配置有LLS表。亦即是，LLS表，由於係被包含於IP/UDP封包中而被傳輸，因此，作為其之標頭，係除了LLS標頭(LLS_H)以外，亦被附加有IP標頭(IP_H)和UDP標頭(UDP_H)。又，在LLS表中，係被配置有LLS訊令之資料，亦即是，在此例中，係被配置有EAT後設資料。
於此，在圖3中，係對於LLS表之語法之例作展示。在圖3之LLS表中，於8位元之LLS_table_id中，係被指定有用以對於LLS表作辨識之LLS表ID。又，在8位元之LLS_table_version中，係被指定有LLS表之版本。另外，LLS_table_id和LLS_table_version，係 被包含在LLS標頭之中。
又，藉由switch文，作為LLS表ID，當被指定有"0x01"的情況時，係代表作為LLS訊令之資料而被配置有SLT後設資料。又，當作為LLS表ID而被指定有"0x02"的情況時，係代表作為LLS訊令之資料而被配置有RRT後設資料，當被指定有"0x03"的情況時，係代表作為LLS訊令之資料而被配置有EAT後設資料。
回到圖2之說明，在被包含於LLS表中之EAT後設資料中，係包含有關連於緊急資訊之資訊。受訊裝置20，當在EAT後設資料中包含有橫幅文本的情況時，係基於EAT後設資料，而顯示該橫幅文本。
但是，在EAT後設資料中，係存在有代表嵌入文本之有無的要素，該要素，當存在有嵌入文本的情況時，係包含有代表該嵌入文本之顯示位置的資訊(顯示位置資訊)。於此情況，受訊裝置20，係基於該EAT後設資料，而在與嵌入文本(EA text)之在畫面上的顯示位置相異之位置處，顯示橫幅文本(banner text)(S11)。
又，在EAT後設資料中，當作為LCC內容而提供有包含緊急資訊之詳細資訊(緊急詳細資訊)之緊急資訊應用程式的情況時，係包含有關連於緊急資訊應用程式之資訊。於此情況，受訊裝置20，係基於該EAT後設資料，來取得藉由ROUTE會談所傳輸的緊急資訊應用程式(EA APP)並實行，而能夠顯示緊急詳細資訊(S12)。
進而，在EAT後設資料中，當藉由EA伺服器40而提供有緊急詳細資訊的情況時，係包含有代表該EA伺服器40之URL(Uniform Resource Locator)的資訊。於此情況，受訊裝置20，係基於該EAT後設資料，來透過通訊線路90(Internet)而對於EA伺服器40進行存取，並要求緊急詳細資訊(S13、S14)。之後，受訊裝置20，係能夠顯示從EA伺服器40所配送的緊急詳細資訊(S14、S13)。但是，從EA伺服器40所配送的緊急詳細資訊，係可作為緊急資訊應用程式(EA APP)來提供之。
另外，在圖2之例中，作為傳送層(Transport layer)之傳輸通訊協定(傳送通訊協定)，雖係針對使用ROUTE的情況來作了說明，但是，係亦可構成為使用其他的傳送通訊協定。例如，在現今所規劃中之ATSC3.0中，作為傳送通訊協定，係對於ROUTE與MMT(MPEG Media Transport)之併存有所考慮，但是，除了ROUTE會談以外，係亦可構成為使用MMT會談來傳輸組件或訊令之串流。
如同上述一般，在ATSC3.0等之IP傳輸方式之數位播送中，當作為傳送通訊協定而使用有ROUTE或MMT的情況時，於緊急時，係能夠將與從緊急資訊來源(例如美國聯邦緊急事務管理署(FEMA))而來之緊急資訊來源資訊(例如在災害時所發行的緊急警報等)相對應之緊急資訊，對於受訊裝置20作提供(通知)。
於此，緊急資訊，係可分類為用以使多數之受訊裝置20迅速地作顯示的資訊和其之詳細資訊的2個種類，但是，前者主要係作為像是「注意龍捲風」或「注意地震」等之短文本資訊或者是適合於視覺障礙者之聲音的朗讀等來提供。另一方面，後者主要係作為與HTML5(HyperText Markup Language5)相對應之應用程式或者是靜止畫像等之複數之單一媒體檔案、多媒體檔案來提供。
關於前者，如同上述一般，存在有使播送台(之送訊裝置10)傳輸將緊急資訊(文本資訊)嵌入至電視節目之影像中的嵌入文本之方法、和使播送台(之送訊裝置10)與電視節目之影像及聲音相互獨立地而另外傳輸緊急資訊(文本資訊)並使受訊裝置20將橫幅文本重疊顯示在電視節目之影像上的方法。而，在受訊裝置20處，係並不僅會有將嵌入文本和橫幅文本之其中一者作顯示的情況，當從送訊裝置10而受訊了嵌入文本和橫幅文本之雙方時，也會有將嵌入文本和橫幅文本之兩者同時作顯示的情況。
於此情況，在受訊裝置20之畫面上，係要求將橫幅文本以不會對於嵌入文本之顯示造成妨礙的方式來作顯示。因此，在本技術中，係藉由在EAT後設資料中，包含有代表嵌入文本之有無之資訊，並且當存在有嵌入文本的情況時為包含有代表該嵌入文本之顯示位置資訊(橫幅文本之顯示禁止區域資訊)，來成為能夠使受訊裝 置20基於在該EAT後設資料中所包含的顯示位置資訊而在與嵌入文本之顯示位置相異的位置處顯示橫幅文本。
藉由此，在受訊裝置20處，當將嵌入文本和橫幅文本同時作顯示時，係成為能夠進行用以將此些之緊急資訊顯示在適當的位置處之控制。又，例如，可以推測到，依存於節目之製作者，也會有想要將緊急資訊並非進行視訊縮放顯示而是進行重疊顯示的情況，但是，就算是在此種情況，也能夠對於節目製作者之意願有所反映地而顯示緊急資訊。又，係能夠以對於使用者而言為易於觀看的佈置，來提示緊急資訊。進而，對於播送台側而言，由於係能夠將藉由相異之方式而傳輸之嵌入文本和橫幅文本的兩者同時作顯示，因此係成為能夠使緊急資訊之傳輸手段的選項增加。此事，例如在現今所規劃中之ATSC3.0的播送服務開始時，也會對於導入設備或導入方法之選項的增加有所助益，因此，以結果而言，係成為能夠得到像是能夠使導入成本降低等的好處。
另外，關於後者，由於係藉由以ROUTE會談來作為LCC內容而傳輸之緊急資訊應用程式或者是從EA伺服器40所配送之緊急資訊應用程式等來提供緊急詳細資訊，因此，例如，受訊裝置20，係能夠藉由取得緊急資訊應用程式，來顯示緊急詳細資訊。
(緊急資訊之顯示例)
圖4，係為對於緊急資訊之顯示例作展示之圖。
作為用以將緊急資訊顯示在畫面上的方式，係存在有僅顯示嵌入文本之第1方式、和僅顯示橫幅文本之第2方式、以及將嵌入文本和橫幅文本之兩者同時作顯示之第3方式。
在圖4中，係對於在棒球轉播節目之視聽中被通知有緊急資訊並因應於第1~第3方式之其中一個方式來將緊急資訊作顯示的模樣作示意性展示。
在第1方式(1.Burned EA Message in uncompressed video)中，如同圖中之上段所示一般，緊急資訊(龍捲風警報：「Tornado Warning」)，係被嵌入至棒球轉播節目之影像(非壓縮之視訊資料)中，並作為嵌入文本而被作顯示。
在第2方式(2.banner text)中，如同圖中之中段所示一般，緊急資訊(龍捲風警報：「Tornado Warning」、警報之場所與時刻資訊：「Fairfield CT.06/30/15 13：43：00 EDT.」)，係作為橫幅文本而被作顯示。於此，作為第2方式之顯示佈置，係存在有重疊顯示(overlay)和視訊縮放顯示(video scaling)之2種類。
當在第2方式中採用了重疊顯示的情況時，緊急資訊，係作為橫幅文本而被重疊顯示於棒球轉播節目之影像的一部分處。以下，將採用第2方式並且橫幅文本被作重疊顯示的情況，亦稱作「第2方式A」來作說明。
另一方面，當在第2方式中採用了視訊縮放顯示的情況時，棒球轉播節目之影像的縱橫之尺寸係被縮 小，並在藉由此所得到的倒L字型之區域中，將緊急資訊作為橫幅文本來作顯示。以下，將採用第2方式並且橫幅文本被作視訊縮放顯示的情況，亦稱作「第2方式B」來作說明。
在第3方式(3.Mixing burned EA Message and banner text)中，如同圖中之下段所示一般，緊急資訊(龍捲風警報：「Tornado Warning」)，係被嵌入至棒球轉播節目之影像(非壓縮之視訊資料)中，並作為嵌入文本而被作顯示。又，在第3方式中，緊急資訊(警報之場所與時刻資訊：「Fairfield CT.06/30/15 13：43：00 EDT.」)，係作為橫幅文本而被作顯示。
於此，作為第3方式之顯示佈置，係與第2方式之顯示佈置同樣的，存在有重疊顯示(overlay)和視訊縮放顯示(video scaling)之2種類。
當在第3方式中採用了重疊顯示的情況時，緊急資訊(警報之場所與時刻資訊：「Fairfield CT.06/30/15 13：43：00 EDT.」)，係作為橫幅文本而被重疊顯示於棒球轉播節目之影像的一部分處。以下，將採用第3方式並且橫幅文本被作重疊顯示的情況，亦稱作「第3方式A」來作說明。
另一方面，當在第3方式中採用了視訊縮放顯示的情況時，棒球轉播節目之影像的縱橫之尺寸係被縮小，並在藉由此所得到的倒L字型之區域中，將緊急資訊作為橫幅文本來作顯示。以下，將採用第3方式並且橫幅 文本被作視訊縮放顯示的情況，亦稱作「第3方式B」來作說明。
在本技術中，當於受訊裝置20處而將嵌入文本和橫幅文本之兩者同時作顯示的情況時，係構成為基於在EAT後設資料中所包含的嵌入文本之顯示位置資訊(橫幅文本之顯示禁止區域資訊)，來成為在與嵌入文本之顯示位置相異的位置處顯示橫幅文本，但是，可能會出現此種狀況的情形，係為第3方式A的情形。
另外，係可在EAT後設資料中，包含有代表要將橫幅文本作重疊顯示或者是作視訊縮放顯示的資訊(顯示佈置資訊)。又，橫幅文本之顯示佈置，係並不被限定於重疊顯示和視訊縮放顯示，而亦可為其他之顯示形態。進而，上述之第2方式B和第3方式B之視訊縮放顯示的顯示形態，係僅為其中一例，而並不被限定為倒L字型，只要是能夠確保用以顯示橫幅文本之區域，則例如，係亦可採用像是L字型等之其他的顯示形態。
(橫幅文本之顯示例)
圖5，係為對於橫幅文本之顯示例作展示之圖。
作為橫幅文本，係可藉由橫幅訊息和橫幅說明文之2個階段來提供緊急資訊。於此，橫幅訊息，係為緊急資訊之標題，例如，係為用以藉由短文章來對於緊急資訊之種類等進行通知者。又，橫幅說明文，係為用以通知緊急資訊之詳細文章(詳細資訊)者。
又，在橫幅訊息和橫幅說明文處，係可將顯示形態設為相異。例如，係亦可採用將橫幅訊息作強調顯示並且將橫幅說明文以較橫幅訊息而更小的文字來顯示等的顯示形態。
例如，在圖5之A中，於電視節目處，係被重疊顯示有橫幅文本。在此橫幅文本中，作為橫幅訊息，係強調顯示有代表緊急資訊乃身為氣象資訊之標題(「Severe Thunderstorm Warning」)，作為橫幅說明文，係以較標題更小之文字而顯示有該氣象資訊之詳細的內容(「The National Weather‧‧‧」)。
同樣的，在圖5之B中，例如，作為橫幅訊息，係強調顯示有代表緊急資訊乃身為安珀警報(AMBER Alert)之標題(「Child Abduction Emergency」)，作為橫幅說明文，係以較標題更小之文字而顯示有該安珀警報之詳細的內容(「Civil Authorities have‧‧‧」)。
〈2. 語法之例〉
圖6，係為對於XML形式之EAT後設資料之語法之例作展示之圖。另外，在圖6中，於要素與屬性中之屬性處，係附加有「@」。又，被作了內縮(indent)的要素和屬性，係成為被對於其之上位的要素作了指定者。
如同圖6中所示一般，作為根要素之EAT要 素，係成為AutomaticTuningService要素、BurnedInMessageRegion要素、MessageLayoutPolicy要素以及EaMessage要素之上位要素。
在AutomaticTuningService要素中，係被指定有關連於在將受訊裝置20強制性啟動的情況時之在啟動時所選台的服務(自動選台服務(ATS：Automatic Tuning Service))之資訊。
AutomaticTuningService要素，係成為broadcastStreamID屬性以及serviceId屬性之上位要素。在broadcastStreamID屬性中，係被指定有自動選台服務之廣播串流ID。在serviceId屬性中，係被指定有自動選台服務之服務ID。
在BurnedInMessageRegion要素中，當存在有嵌入文本的情況時，係被指定有代表該嵌入文本之顯示位置的資訊(顯示位置資訊)。於此，BurnedInMessageRegion要素，由於其之出現數(Cardinality)係成為"0..n"，因此，不僅是能夠記述1或複數之BurnedInMessageRegion要素，而亦可並不記述BurnedInMessageRegion要素。
當被記述有1或複數之BurnedInMessageRegion要素的情況時，係代表存在有嵌入文本，進而，作為其之要素之值，係成為被指定有對象之嵌入文本之顯示位置資訊。亦即是，當採用第1方式或第3方式的情況時，係被記述有1或複數之BurnedInMessageRegion要素。
另一方面，當並未被記述有BurnedInMessageRegion要素的情況時，係代表並不存在有嵌入文本。亦即是，當採用 第2方式的情況時，係不會被記述有BurnedInMessageRegion要素。
BurnedInMessageRegion要素，係成為type屬性之上位要素。在type屬性中，係被指定有代表嵌入文本之顯示位置的形式之型態資訊。作為此type屬性，例如，係被指定有"coordinates"或"upper/middle/bottom"。
"coordinates"，係代表將嵌入文本之顯示位置，例如以受訊裝置20之畫面的左上作為原點而以XY座標來表現。又，"upper/middle/bottom"，係代表在將受訊裝置20之畫面在水平方向上而分割成3個區域時之上側之區域(upper)、中央之區域(middle)以及下側之區域(bottom)，並藉由對於該些之其中一個區域作指定而在該指定區域中顯示嵌入文本。
另外，當被記述有複數之BurnedInMessageRegion要素的情況時，係成為在受訊裝置20之畫面上的複數之區域處被顯示有嵌入文本。另外，作為代表嵌入文本之顯示位置的資訊之形式，係並不被限定於上述之座標等，只要是能夠特定出嵌入文本之顯示位置的資訊，則亦可構成為採用其他的形式(例如，絕對性之位置或相對性之位置、百分比顯示等)。
在MessageLayoutPolicy要素中，係被指定有關連於橫幅文本之顯示佈置的資訊(顯示佈置資訊)。作為此MessageLayoutPolicy要素，例如，係被指定有"overlay"或"scaling"。
"overlay"，係代表橫幅文本為被作重疊顯示。亦即是，當採用第2方式A或者是第3方式A的情況時，作為MessageLayoutPolicy要素，係被指定有"overlay"。又，"scaling"，係代表橫幅文本為被作視訊縮放顯示。亦即是，當採用第2方式B或者是第3方式B的情況時，作為MessageLayoutPolicy要素，係被指定有"scaling"。
在EaMessage要素中，係被指定有關連於緊急資訊之資訊。EaMessage要素，係成為eaMessageId屬性、eaCategory屬性、EaGeolocation要素、EaBannerMessage要素、EaBannerDescription要素、SpeechInfo要素、SpeechInfoURI要素、EaApplication要素、EaService要素、EaAudio要素以及EaWww要素之上位要素。
在eaMessageId屬性中，係作為緊急資訊之識別符，而被指定有訊息ID。在eaCategory屬性中，係被指定有緊急資訊之範疇(Category)。
在EaGeolocation要素中，係被指定有關連於緊急資訊之對象區域的資訊。EaGeolocation要素，係成為type屬性之上位要素。在type屬性中，係被指定有代表關連於緊急資訊之對象區域的資訊。作為此type屬性，例如，係被指定有"zip"或"latitude/longitude"。
"zip"，例如係代表藉由美國郵政署(USPS)所使用的5碼或者是9碼的郵遞區號(ZIP code)來對於對象區域作指定。又，"latitude/longitude"，係代表藉由 緯度和經度來對於對象區域作指定。
在EaBannerMessage要素中，當緊急資訊係作為橫幅文本而被提供時，係被指定有該橫幅文本之橫幅訊息。另外，此橫幅訊息，係對應於圖5之橫幅訊息。
EaBannerMessage要素，係成為type屬性之上位要素。在type屬性中，係被指定有代表橫幅文本之橫幅訊息的種類之型態資訊。作為此type屬性，例如，係被指定有"CAP"或"text"、"EEE code"、"TTML"。
"CAP"，係代表作為橫幅訊息，而提供有作為緊急資訊來源(EA Authority)所發行的緊急資訊來源資訊(緊急資訊訊息)之CAP資訊的全部或者是一部分。"text"，係代表橫幅訊息乃身為文本資訊。"EEE code"，係代表橫幅訊息為準據於由聯邦通信委員會(FCC：Federal Communications Commission)所規定的EEE碼。"TTML"，係代表橫幅訊息為藉由TTML(Timed Text Markup Language)形式所記述者。
在EaBannerDescription要素中，當緊急資訊係作為橫幅文本而被提供的情況時，係被指定有該橫幅文本之橫幅說明文。另外，此橫幅說明文，係對應於圖5之橫幅說明文。
亦即是，當採用第2方式和第3方式的情況時，作為EaBannerMessage要素，係成為被記述有橫幅訊息，進而，作為EaBannerDescription要素，係成為被記述有橫幅說明文。
SpeechInfo要素，當被提供有語音發話後設資料的情況時，係被記述有該語音發話後設資料自身的內容。於此，所謂語音發話後設資料，係為為了進行製作者之對於緊急資訊所意圖的語音之發話，而關連於製作者所意圖的語音之發話之資訊。例如，此語音發話後設資料之內容，係藉由身為語音合成標記語言之SSML(Speech Synthesis Markup Language)形式而被記述。使用此語音發話後設資料，而進行適合於視覺障礙者之語音的朗讀。
SpeechInfo要素，係成為content-type屬性以及content-enc屬性之上位要素。在content-type屬性中，係被指定有代表在SpeechInfo要素中所記述的語音發話後設資料的種類之型態資訊。作為此content-type屬性，例如，係被指定有"SSML"。又，在content-enc屬性中，係被指定有代表在SpeechInfo要素中所記述的語音發話後設資料的編碼方式之資訊。作為此content-enc屬性，例如，係被指定有"zip"。
SpeechInfoURI要素，當提供有語音發話後設資料的情況時，係被指定有用以取得語音發話後設資料之位址資訊(例如，URI(Uniform Resource Identifier))。例如，當語音發話後設資料為從被與網際網路等之通訊線路90作了連接的EA伺服器40而提供的情況時，係作為位址資訊，而指定有用以對於此EA伺服器40進行存取之URL。
SpeechInfoURI要素，係成為content-type屬 性以及content-enc屬性之上位要素。在content-type屬性中，係被指定有代表藉由參考URI等之位址資訊所取得的語音發話後設資料之種類之型態資訊。作為此content-type屬性，例如，係被指定有"SSML"。又，在content-enc屬性中，係被指定有代表藉由參考URI等之位址資訊所取得的語音發話後設資料之編碼方式之資訊。作為此content-enc屬性，例如，係被指定有"zip"。
在EaApplication要素中，當提供有包含緊急詳細資訊之緊急資訊應用程式的情況時，係被指定有關連於該緊急資訊應用程式之資訊。EaApplication要素，係成為applicationId屬性之上位要素。在applicationId屬性中，係被指定有緊急資訊應用程式之應用程式ID。另外，此應用程式ID，係與藉由AIT(Application Information Table)等之應用程式控制資訊所管理的應用程式之識別符相互附加有關連。
在EaService要素中，當緊急詳細資訊係作為緊急資訊服務而被提供的情況時，係被指定有關連於該緊急資訊服務之資訊。EaService要素，係成為serviceId屬性之上位要素。在serviceId屬性中，係被指定有緊急資訊服務之服務ID。
在EaAudio要素中，當緊急資訊(緊急詳細資訊)係作為語音資訊而藉由被與其他服務作共有之分享音訊(shared audio)的組件而被提供的情況時，係被指定有關連於該分享音訊之資訊。EaAudio要素，係成為id 屬性之上位要素。在id屬性中，係被指定有用以對於音訊之組件作辨識的組件ID。
在EaWww要素中，當緊急詳細資訊係藉由被與網際網路等之通訊線路90作了連接的EA伺服器40而被提供的情況時，係被指定有關連於此EA伺服器40之資訊。EaWww要素，係成為uri屬性之上位要素。在uri屬性中，係被指定有提供緊急詳細資訊之EA伺服器40的URL。另外，EA伺服器40，係可作為緊急詳細資訊，而提供緊急資訊應用程式。
另外，在圖6中，雖係存在有出現數(Cardinality)，但是，當其被指定為"1"的情況時，該要素或者是屬性係決定僅被指定有1個，而當被指定為"0..1"的情況時，是否要指定該要素或屬性一事係為任意。又，當被指定為"1..n"的情況時，該要素或屬性係被指定有1以上，當被指定為"0..n"的情況時，是否要將該要素或屬性作1以上之指定一事係為任意。
又，作為Data Type，當被指定有"integer"的情況時，係代表該要素或屬性之值乃身為整數型，當被指定為"string"的情況時，則係代表該要素或屬性之值乃身為為文字列型。又，作為Data Type，當被指定有"anyURI"的情況時，係代表該要素或屬性之值乃身為anyURI資料型。
另外，在圖6中所示之EAT後設資料的語法，係僅為其中一例，例如，係亦可追加其他之要素或屬 性等而採用其他的語法。又，EAT後設資料，係並不被限定於XML形式，而亦可藉由其他之標示語言來作記述，或者是一可為區段(section)形式。
〈3. 各裝置之構成〉
接著，針對構成圖1之傳輸系統1的各裝置之詳細之構成作說明。於此，係以由播送台所設置的送訊裝置10之構成和由使用者所設置的受訊裝置20之構成為中心，來進行說明。
圖7，係為對於傳輸系統1的各裝置之構成例作展示之圖。
在圖7中，送訊裝置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處。
又，在緊急時，當採用有第1方式或第3方式的情況時，在受訊裝置20之畫面上，由於係顯示有嵌入文本(EA text)，因此，從EA剖析器101而來之緊急資訊，係被供給至組件處理部104處。組件處理部104，當從EA剖析器101而被供給有緊急資訊的情況時，係在內容(例如現場播送節目或事先收錄節目)之影像(非壓縮之視訊資料)中，嵌入從EA剖析器101而來之緊急資訊(文本資訊)。之後，編碼器107，係成為依據特定之編碼方式，來對於被嵌入有緊急資訊(文本資訊)之視訊資料進行編碼。
訊令處理部105，係產生LLS訊令或SLS訊令等之訊令，並供給至多工器108處。例如，作為LLS訊令，係產生有SLT後設資料等。又，作為SLS訊令，係產生有USD、S-TSID、MPD等之後設資料。
又，訊令處理部105，在緊急時，當從EA剖析器101而被供給有緊急資訊的情況時，係產生與緊急資訊相對應之EAT後設資料，並供給至多工器108處。但是，當採用有第2方式或第3方式的情況時，在受訊裝置20之畫面上，由於係顯示有橫幅文本(banner text)，因此，在EAT後設資料中，係包含有與從EA剖析器101而來之緊急資訊相對應的橫幅訊息和橫幅說明文。
LCC處理部106，當被提供有LCC內容的情況時，係產生LCC內容，並供給至多工器108處。又，LCC處理部106，在緊急時，當從EA剖析器101而被供給有緊急資訊的情況時，係基於該緊急資訊，而產生緊急資訊應用程式，並供給至多工器108處。
多工器108，係將從編碼器107所供給而來之組件的串流和從訊令處理部105所供給而來之訊令的串流作多工化，而產生多工化串流，並供給至調變部109處。又，多工器108，當被提供有LCC內容(緊急資訊應用程式)的情況時，係除了組件與訊令的串流之外，更進而將從LCC處理部106所供給而來之LCC內容(緊急資訊應用程式)的串流作多工化，而產生多工化串流。
調變部109，係進行對於從多工器108所供給 而來的多工化串流之資料的錯誤訂正編碼處理(例如，BCH編碼或LDPC編碼等)和調變處理(例如，OFDM(Orthogonal Frequency Division Multiplexing)調變等)，並將藉由該處理之結果所得到的訊號，供給至RF部110處。
RF部110，係將從調變部109所供給而來之訊號，轉換為RF(Radio Frequency)訊號，並透過天線(未圖示)，來作為IP傳輸方式之數位播送訊號而送訊。
送訊裝置10，係如同上述一般地而被構成。另外，在圖7中，為了便於說明，係針對送訊側之裝置為藉由送訊裝置10、亦即是藉由1個的裝置來構成的情況，而作了展示，但是，係亦可作為由具備有圖7之區塊的各功能之複數之裝置所成的送訊系統，而構成之。又，藉由使送訊裝置10成為具有通訊功能，緊急資訊應用程式(EA APP)或語音發話後設資料(SpeechInfo)，係亦可構成為從送訊裝置10來提供至EA伺服器40處。
又，在圖7中，受訊裝置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內容(緊急資訊應用程式)之串流的情況時，係將LCC內容(緊急資訊應用程式)的串流分離，並供給至瀏覽器214處。
解碼器222，係基於從解多工器221所供給而來之組件的串流，而將視訊和音訊的組件之資料解碼，並供給至組件處理部212處。
組件處理部212，係對於從解碼器222所供給而來之視訊和音訊的資料進行處理，並供給至輸出部204處。
但是，於緊急時，當採用有第1方式或第3方式的情況時，在內容(例如現場播送節目或事先收錄節目)之影像(非壓縮之視訊資料)中，係被嵌入有緊急資訊(文本資訊)，此係成為被作為嵌入文本(EA text)而顯示。
MW部213，係藉由中間軟體(MW：Middleware)所構成，並對於從解多工器221所供給而來之訊令的串流進行處理。MW部213，係由剖析器231以及濾波器232所構成。剖析器231，係進行對象之訊令的解析處理。濾波器232，係進行對象之訊令的抽出處理。之後，在處理部203處，係基於藉由MW部213而進行了處理的訊令，來進行對於組件和應用程式等之處理。
但是，於緊急時，由於係從送訊裝置10而被 通知有EAT後設資料，因此，MW部213，係成為取得該EAT後設資料並進行處理。進而，當採用有第2方式或第3方式的情況時，在EAT後設資料中，係包含有橫幅訊息和橫幅說明文，此係成為被作為橫幅文本(banner text)而顯示。
瀏覽器214，例如，係為對應於HTML5之瀏覽器，並實行從解多工器221所供給而來之緊急資訊應用程式。藉由此緊急資訊應用程式(EA APP)，例如係成為顯示有緊急詳細資訊。
輸出部204，係對於從組件處理部212所供給而來之視訊資料進行處理，並輸出至顯示部(未圖示)處。又，輸出部204，係對於從組件處理部212所供給而來之音訊資料進行處理，並輸出至揚聲器(未圖示)處。藉由此，在顯示部處，係被顯示有現場播送節目或事先收錄節目等之內容的影像，並從揚聲器而輸出有與該影像相互同步的聲音。
但是，於緊急時，當採用有第1方式或第3方式的情況時，在顯示部處，係成為顯示被嵌入有與緊急資訊相對應的嵌入文本(EA text)之現場播送節目等的內容之影像。又，於緊急時，當採用有第2方式或第3方式的情況時，在顯示部處，係成為在現場播送節目等的內容之影像上重疊顯示有包含橫幅訊息和橫幅說明文之橫幅文本(banner text)。進而，當藉由瀏覽器214而實行了緊急資訊應用程式(EA APP)的情況時，係成為顯示有其 之緊急詳細資訊。
通訊I/F205，係透過網際網路等之通訊線路90，來與EA伺服器40之間進行各種資料之交換。
例如，通訊I/F205，係能夠因應於EAT後設資料之解析結果，而藉由透過通訊線路90來對於EA伺服器40要求緊急資訊應用程式(EA APP)，而受訊從EA伺服器40所配送之緊急資訊應用程式(EA APP)，並供給至處理部203之瀏覽器214處。藉由此，瀏覽器214，係能夠實行從EA伺服器40所配送的緊急資訊應用程式(EA APP)。
又，例如，通訊I/F205，係能夠因應於EAT後設資料之解析結果，而藉由透過通訊線路90來對於EA伺服器40要求語音發話後設資料(SpeechInfo)，而受訊從EA伺服器40所配送之語音發話後設資料(SpeechInfo)，並供給至處理部203之FW/HW部211的解碼器222處。藉由此，解碼器222(之TTS引擎)，係能夠基於語音發話後設資料(SpeechInfo)來朗讀緊急資訊(文本資訊)。另外，TTS引擎，係為能夠根據文本資訊而人工性地作出人類的語音之語音合成機(Text To Speech Synthesizer)。
受訊裝置20，係如同上述一般地而被構成。另外，受訊裝置20，係除了可身為電視受像機、機上盒(STB：Set Top Box)或者是錄影機等之固定受訊機以外，亦可身為行動電話、智慧型手機或者是平板終端等之 攜帶受訊機。又，受訊裝置20，係亦可為被搭載於車輛處之車載機器。進而，在圖7之受訊裝置20的構成中，雖係針對顯示部和揚聲器為被設置於外部的構成作了展示，但是，顯示部和揚聲器，係亦可構成為被設置在受訊裝置20之內部。
〈4. 藉由各裝置所實行的處理之流程〉
接著，參考圖8~圖13之流程圖，針對藉由構成圖1之傳輸系統1的各裝置所實行之處理的流程作說明。
(送訊處理之流程〉
首先，參考圖8之流程圖，針對藉由圖7之送訊裝置10所實行之送訊處理的流程作說明。
在步驟S101中，組件處理部104以及編碼器107，係進行組件處理。
在此組件處理中，係取得藉由直播內容取得部102所取得之直播內容(例如現場播送節目)或者是被積蓄在儲存設備103中之已完成收錄之內容(例如事先收錄節目)，並對於構成所取得的內容之視訊和音訊的組件，而進行像是與特定之編碼方式相對應的編碼等之處理。
又，於緊急時，當採用有第1方式或第3方式的情況時，由於係在受訊裝置20之畫面上顯示嵌入文 本，因此，在組件處理中，係先在內容(例如現場播送節目或事先收錄節目)之影像(非壓縮之視訊資料)中，嵌入從EA剖析器101而來之緊急資訊(文本資訊)，之後再進行編碼。另外，當採用有第2方式的情況時，由於係僅顯示橫幅文本，因此，係並不需要在內容之影像中嵌入緊急資訊。
在步驟S102中，訊令處理部105，係進行訊令處理。
在此訊令處理中，係產生LLS訊令或SLS訊令等之訊令並進行處理。
又，在緊急時，於訊令處理中，作為LLS訊令，係產生與從EA剖析器101而來之緊急資訊相對應的EAT後設資料。
於此，當採用有第1方式的情況時，由於係僅顯示嵌入文本，因此，在EAT後設資料中，係並不需要記述關連於嵌入文本之資訊。又，當採用有第2方式的情況時，由於係僅顯示橫幅文本，因此，在EAT後設資料中，係並不需要記述關連於嵌入文本之資訊(例如嵌入文本之顯示位置資訊)。進而，當採用有第3方式的情況時，在EAT後設資料中，係記述有嵌入文本之顯示位置資訊和橫幅文本之顯示佈置資訊。
在步驟S103中，LCC處理部106，係進行應用程式處理。
此應用程式處理，例如，在緊急時，係於傳 輸緊急資訊應用程式的情況時會被實行，並產生與從EA剖析器101而來之緊急資訊相對應的緊急資訊應用程式。
在步驟S104中，多工器108，係進行多工化串流產生處理。
在此多工化串流產生處理中，藉由步驟S101之處理所得到的組件之串流、和藉由步驟S102之處理所得到的訊令之串流，係被多工化，而產生多工化串流。但是，於緊急時，在訊令中，係包含有EAT後設資料。又，在被產生有緊急資訊應用程式的情況時，其之串流係亦被多工化。
在步驟S105中，調變部109以及RF部110，係進行播送串流送訊處理。
在此播送串流送訊處理中，藉由步驟S104之處理所產生的多工化串流，係作為IP傳輸方式之數位播送訊號而被送訊。
若是步驟S105之處理結束，則圖8之送訊處理係結束。
以上，係針對送訊處理之流程作了說明。
(電源OFF、待機狀態時之受訊處理的流程)
接著，參考圖9之流程圖，針對藉由圖7之受訊裝置20所實行之在電源OFF、待機狀態時之受訊處理的流程作說明。但是，作為圖9之流程圖的處理會被實行的前提，假設係為受訊裝置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中，係進行播送串流受訊處理。
在此播送串流受訊處理中，基於訊令，視訊 和音訊之組件係被作處理，內容之影像和聲音係被播放。又，在緊急時，係顯示有嵌入文本或橫幅文本等之緊急資訊。另外，針對此播送串流受訊處理的詳細內容，係參考圖11之流程圖而於後再作敘述。
在步驟S206中，係判定步驟S205之播送串流受訊處理是否結束。在步驟S206中，當判定係持續進行播送串流受訊處理的情況時，處理係回到步驟S205處，步驟S205~S206之處理係被反覆進行。另一方面，在步驟S206中，當判定播送串流受訊處理係結束的情況時，圖9之在電源OFF、待機狀態時的受訊處理係結束。
以上，係針對在電源OFF、待機狀態時之受訊處理的流程作了說明。
(電源OFF狀態時之受訊處理的流程)
接著，參考圖10之流程圖，針對藉由圖7之受訊裝置20所實行之在電源OFF狀態時之受訊處理的流程作說明。但是，作為圖10之流程圖的處理會被實行的前提，假設係為受訊裝置20身為電源OFF狀態，亦即是在受訊裝置20處所有之功能均為無法實現之狀態。
在步驟S211中，例如，因應於使用者之操作，受訊裝置20之電源係被設為ON。
若是藉由步驟S211之處理而成為能夠實行受訊裝置20之所有的功能，則處理係前進至步驟S212處。在步驟S212中，係進行播送串流受訊處理。
在此播送串流受訊處理中，基於訊令，視訊和音訊之組件係被作處理，內容之影像和聲音係被播放。又，在緊急時，係顯示有嵌入文本或橫幅文本等之緊急資訊。另外，針對此播送串流受訊處理的詳細內容，係參考圖11之流程圖而於後再作敘述。
在步驟S213中，係判定步驟S212之播送串流受訊處理是否結束。在步驟S213中，當判定係持續進行播送串流受訊處理的情況時，處理係回到步驟S212處，步驟S212~S213之處理係被反覆進行。另一方面，在步驟S213中，當判定播送串流受訊處理係結束的情況時，圖10之在電源OFF狀態時的受訊處理係結束。
以上，係針對在電源OFF狀態時之受訊處理的流程作了說明。
(播送串流受訊處理的流程)
接著，參考圖11之流程圖，針對與圖9之步驟S205之處理或者是圖10之步驟S212之處理相對應的播送串流受訊處理之流程作說明。
在步驟S221中，解多工器221，係進行封包受訊處理。在此封包受訊處理中，係從藉由解調部202而作了處理的L1訊框，來使ALP封包和IP/UDP封包被作處理。
在步驟S222中，係基於在步驟S221之處理中所得到的封包，來判定是否取得了LLS訊令(LLS 表)。在步驟S222中，當判定係取得了LLS訊令的情況時，處理係前進至步驟S223處。
在步驟S223中，MW部213，係判別LLS訊令之種類和版本。於此，如同上述之參考圖3所作了說明一般，藉由對於在LLS表(之LL標頭)中所包含的LLS表ID和LLS表之版本進行解析，來判別出LLS訊令之種類和版本。
在步驟S224中，MW部213，係基於步驟S223之判別結果，來判定LLS訊令是否被作更新。在步驟S224中，當判定LLS訊令係被作更新的情況時，處理係前進至步驟S225處。
在步驟S225中，MW部213，係基於步驟S223之判別結果，來判定LLS訊令是否身為EAT後設資料。在步驟S225中，當判定LLS訊令係為EAT後設資料的情況時，處理係前進至步驟S226處。
在步驟S226中，係進行EAT受訊處理。在此EAT受訊處理中，係進行有關連於與EAT後設資料相對應的緊急資訊之處理。另外，針對此EAT受訊處理的詳細內容，係參考圖12之流程圖而於後再作敘述。
另一方面，在步驟S225中，當判定LLS訊令係並非為EAT後設資料的情況時，處理係前進至步驟S227處。在步驟S227中，係進行其他之LLS訊令受訊處理。在此LLS訊令受訊處理中，係進行對於SLT後設資料等之除了EAT後設資料以外的LLS訊令之處理。
另外，在步驟S224中，當判定LLS訊令係並未被作更新的情況時，由於係並不需要進行對於LLS訊令之處理，因此，步驟S225~S227之處理係被跳過。又，若是步驟S226或者是步驟S227之處理結束，則圖11之播送串流受訊處理係結束，處理係回到圖9之步驟S205或者是圖10之步驟S212處，並實行後續之處理。
又，在步驟S222中，當判定係並未取得LLS訊令的情況時，處理係前進至步驟S228處。在步驟S228中，係判定對象之ROUTE會談的種類。另外，如同上述一般，在ATSC3.0的情況時，雖然組件和訊令也會有藉由MMT會談而被傳輸的情況，但是，於此，為了使說明簡單化，係僅針對使用有ROUTE會談的情況來作說明。
在步驟S228中，當判定ROUTE會談之種類係為視訊或音訊等之組件的情況時，處理係前進至步驟S229處。在步驟S229~S230中，係進行關連於藉由ROUTE會談所被傳輸的組件之處理。
具體而言，在步驟S229中，解碼器222以及組件處理部212，係進行組件受訊處理。在此組件受訊處理中，係對於構成電視節目等之內容的視訊和音訊之組件，而進行與特定之解碼方式相對應的解碼等之處理。
在步驟S230中，輸出部204，係進行渲染(rendering)處理。在此渲染處理中，基於步驟S229之處理結果，電視節目等之內容的影像和聲音係被播放並輸出。
又，在步驟S228中，當判定ROUTE會談之種類係為SLS訊令的情況時，處理係前進至步驟S231處。在步驟S231~S233中，係進行關連於藉由ROUTE會談所被傳輸的SLS訊令之處理。
具體而言，在步驟S231中，MW部213，係進行SLS訊令受訊解析處理。在此SLS訊令受訊解析處理中，藉由ROUTE會談而被傳輸的USD後設資料和S-TSID後設資料等之SLS訊令係被取得並被作解析。
在步驟S232中，係基於步驟S231之解析結果，來判定SLS訊令是否被作了更新。在步驟S232中，當判定SLS訊令係被作更新的情況時，處理係前進至步驟S233處。
在步驟S233中，係基於步驟S231之解析結果，來將SLS訊令之更新內容作反映。另外，在步驟S232中，當判定SLS訊令係並未被作更新的情況時，步驟S233之處理係被跳過。
又，在步驟S228中，當判定ROUTE會談之種類係為LCC內容的情況時，處理係前進至步驟S234處。在步驟S234~S235中，係進行關連於藉由ROUTE會談所被傳輸的LCC內容之處理。
具體而言，在步驟S234中，係進行LCC內容受訊處理，並例如取得應用程式等之LCC內容。在步驟S235中，係進行本地快取(local cache)處理，在步驟S234之處理中所取得的LCC內容，係被積蓄(下載) 在儲存設備(未圖示)中。
若是步驟S230、S233或者是S235之處理結束，則圖11之播送串流受訊處理係結束，處理係回到圖9之步驟S205或者是圖10之步驟S212處，並實行後續之處理。
以上，係針對播送串流受訊處理的流程作了說明。
(EAT受訊處理之流程〉
接著，參考圖12之流程圖，針對與圖11之步驟S226之處理相對應的EAT受訊處理之流程作說明。
在步驟S241中，MW部213，係取得EAT後設資料。
在步驟S242中，MW部213，係進行在步驟S241之處理中所取得的EAT後設資料之解析處理。
在步驟S243中，MW部213，係基於步驟S242之解析結果，來判定是否進行自動選台處理。於此，係基於關連於藉由在XML形式之EAT後設資料中所記述的AutomaticTuningService要素而指定之自動選台服務的資訊、來判定自動選台處理之實行。
在步驟S243中，當判定係進行自動選台處理的情況時，處理係前進至步驟S244處。在步驟S244中，係進行緊急播送之選台處理。於此，係基於藉由在EAT後設資料中所記述的AutomaticTuningService要素之 broadcastStreamID屬性和serviceId屬性而指定的自動選台服務之廣播串流ID和服務ID，來進行緊急播送之選台處理。
若是步驟S244之處理結束，則圖12之EAT受訊處理係結束，處理係回到圖11之步驟S226之處理處，並實行後續之處理。
另一方面，在步驟S243中，當判定係並不進行自動選台處理的情況時，處理係前進至步驟S245處。
在步驟S245中，MW部213，係基於步驟S242之解析結果，來判定是否為緊急資訊之對象地區。於此，係基於關連於藉由在EAT後設資料中所記述的EaGeolocation要素而指定之緊急資訊之對象地區的資訊、來進行是否身為緊急資訊之對象地區的判定處理。
在步驟S245中，當判定係身為緊急資訊之對象地區的情況時，處理係前進至步驟S246處。在步驟S246中，MW部213，係基於步驟S242之解析結果，來判定是否包含橫幅文本。於此，係基於關連於藉由在EAT後設資料中所記述的EaMessage要素之EaBannerMessage要素和EaBannerDescription要素所指定的橫幅文本之資訊，來進行是否在EAT後設資料中包含橫幅文本之判定處理。
在步驟S246中，當判定係包含橫幅文本的情況時，處理係前進至步驟S247處。在步驟S247中，MW部213以及輸出部204等，係進行橫幅文本顯示處理。在 此橫幅文本顯示處理中，係成為基於EAT後設資料，而因應於嵌入文本之顯示位置來顯示橫幅文本。另外，針對此橫幅文本顯示處理的詳細內容，係參考圖13之流程圖而於後再作敘述。
若是步驟S247之處理結束，則處理係前進至步驟S248處。又，在步驟S246中，當判定係並不包含橫幅文本的情況時，步驟S247之處理係被跳過，處理係前進至步驟S248處。
在步驟S248中，MW部213，係基於步驟S242之解析結果，來判定在EAT後設資料中是否包含聲音資訊。於此，係基於關連於藉由在EAT後設資料中所記述的SpeechInfo要素或者是SpeechInfoURI要素所指定的語音發話後設資料之資訊，來進行是否包含聲音資訊之判定處理。
在步驟S248中，當判定係包含聲音資訊的情況時，處理係前進至步驟S249處。在步驟S249中，MW部213以及輸出部204等，係進行聲音輸出處理。在此聲音輸出處理中，係基於語音發話後設資料，來進行緊急資訊(文本資訊)之朗讀。
若是步驟S249之處理結束，則處理係前進至步驟S250處。又，在步驟S248中，當判定係並不包含聲音資訊的情況時，步驟S249之處理係被跳過，處理係前進至步驟S250處。
在步驟S250中，MW部213，係基於步驟 S242之解析結果，來判定在EAT後設資料中是否包含緊急資訊應用程式。於此，係基於關連於藉由在EAT後設資料中所記述的EaApplication要素而指定之緊急資訊應用程式的資訊、來進行是否包含緊急資訊應用程式的判定處理。
在步驟S250中，當判定係包含緊急資訊應用程式的情況時，處理係前進至步驟S251處。在步驟S251中，瀏覽器214以及輸出部204等，係進行緊急資訊應用程式輸出處理。在此緊急資訊應用程式輸出處理中，係基於藉由在EAT後設資料中所記述的EaApplication要素而指定之資訊、來取得藉由ROUTE會談所傳輸的緊急資訊應用程式(LCC內容)，並實行之。
若是步驟S251之處理結束，則圖12之EAT受訊處理係結束。又，在步驟S250中，當判定係並不包含緊急資訊應用程式的情況時，步驟S251之處理係被跳過，圖12之EAT受訊處理係結束。進而，在步驟S245中，當判定係並非為緊急資訊之對象地區的情況時，步驟S246~S251之處理係被跳過，圖12之EAT受訊處理係結束。而，若是圖12之EAT受訊處理結束，則處理係回到圖11之步驟S226之處理處，並實行後續之處理。
以上，係針對EAT受訊處理之流程作了說明。
(橫幅文本顯示處理之流程)
最後，參考圖13之流程圖，針對與圖12之步驟S247之處理相對應的橫幅文本顯示處理之流程作說明。
在步驟S261中，MW部213，係基於步驟S242(圖12)之解析結果，來判定是否存在有嵌入文本。於此，係基於在EAT後設資料中是否被記述有BurnedInMessageRegion要素一事，來進行是否存在有嵌入文本的判定處理。
在步驟S261中，當判定係存在有嵌入文本，亦即是判定在EAT後設資料中係被記述有1以上之BurnedInMessageRegion要素的情況時，處理係前進至步驟S262處。
在步驟S262中，MW部213，係基於步驟S242(圖12)之解析結果，來判定是否要進行視訊縮放。於此，係基於藉由在EAT後設資料中所記述的MessageLayoutPolicy要素而指定之橫幅文本之顯示佈置資訊，來例如基於橫幅文本是否被作視訊縮放顯示一事，而進行是否要進行視訊縮放之判定處理。
在步驟S262中，當判定係進行有視訊縮放的情況時、亦即是當藉由EAT後設資料的MessageLayoutPolicy要素來作為橫幅文本之顯示佈置資訊而指定有視訊縮放顯示的情況時，處理係前進至步驟S263處。
在步驟S263中，組件處理部212，係進行視訊縮放處理，而將電視節目等之內容的影像之縱橫的尺寸縮小。例如，當採用第3方式B的情況時，由於橫幅文本 係被作視訊縮放顯示，因此，係進行有視訊縮放處理。若是步驟S263之處理結束，則處理係前進至步驟S265處。
另一方面，在步驟S262中，當判定係並不進行視訊縮放的情況時、亦即是當藉由EAT後設資料的MessageLayoutPolicy要素來作為橫幅文本之顯示佈置資訊而指定有重疊顯示的情況時，處理係前進至步驟S264處。
在步驟S264中，MW部213，係基於步驟S242(圖12)之解析結果，來取得嵌入文本之顯示位置資訊。於此，作為在EAT後設資料中所被記述之BurnedInMessageRegion要素之值，由於係被指定有對象之嵌入文本的顯示位置資訊，因此，係能夠取得此顯示位置資訊。例如，當採用有第3方式A的情況時，係取得嵌入文本之顯示位置資訊。
若是步驟S264之處理結束，則處理係前進至步驟S265處。又，在步驟S261中，當判定係並不存在有嵌入文本，亦即是判定在EAT後設資料中係並未被記述有BurnedInMessageRegion要素的情況時，步驟S262~S264之處理係被跳過，處理係前進至步驟S265處。
在步驟S265中，MW部213，係基於步驟S261~S264之處理結果，來決定橫幅文本之顯示位置。
具體而言，當並不存在嵌入文本的情況時(S261之「NO」)，此情況係相當於第2方式(第2方式A、第2方式B)，橫幅文本，由於係並不會有對於嵌 入文本造成妨礙的情形，因此，作為橫幅文本之顯示位置，例如，係可將像是畫面之下側之區域等的任意之區域作為顯示位置。
又，當存在有嵌入文本(S261之「YES」)，並且係進行有視訊縮放的情況時(S262之「YES」)，此情況係相當於第3方式B，作為橫幅文本之顯示位置，係可將藉由步驟S263之處理(視訊縮放處理)所產生的區域內之任意之區域作為顯示位置。另外，於此情況，由於橫幅文本係被顯示在藉由視訊縮放處理所產生的區域中，因此，係並不會有對於嵌入文本造成妨礙的情況。
進而，當存在有嵌入文本(S261之「YES」)，並且係並未進行視訊縮放的情況時(S262之「NO」)，此情況係相當於第3方式A，由於橫幅文本係被重疊顯示於電視節目之影像上，因此，若是將橫幅文本顯示在任意之區域處，則可能會有對於嵌入文本造成妨礙的可能性。於此情況，步驟S264之處理係被實行，由於係從EAT後設資料而取得有嵌入文本之顯示位置，因此，在此顯示位置資訊所代表的區域中，係設為不會顯示橫幅文本(橫幅文本之顯示係被禁止)。
具體而言，例如，當作為嵌入文本之顯示位置而被指定有嵌入文本之顯示區域之座標的情況時，係設為將橫幅文本之顯示位置決定為除了被該座標所指定的顯示區域以外之區域。又，例如，當作為嵌入文本之顯示位 置而被指定有畫面之下側之區域(bottom)的情況時，作為橫幅文本之顯示位置，係構成為將其決定為畫面之上側之區域(upper)或者是正中央之區域(middle)。
若是在步驟S265之處理中而決定橫幅文本之顯示位置，則處理係前進至步驟S266處。在步驟S266中，輸出部204，係基於步驟S265之決定結果，來顯示橫幅文本。例如，當採用了第3方式A的情況時，係成為將嵌入文本和橫幅文本之兩者同時作顯示，但是，由於橫幅文本係被顯示在與嵌入文本之顯示位置相異的位置處，因此，係不會有橫幅文本對於嵌入文本造成妨礙的情況。
若是步驟S266之處理結束，則圖13之橫幅文本顯示處理係結束。而，處理，係回到圖12之步驟S247之處理，並實行後續之處理。
以上，係針對橫幅文本顯示處理之流程作了說明。
〈5. 變形例〉
作為上述之說明，針對數位播送之規格，係對於身為在美國等處所採用的方式之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)的情況，但是，此並非為實質性的內容上之差異。
進而，在上述之說明中，雖係針對嵌入文本和橫幅文本之顯示位置來作了敘述，但是，係並不被限定於文本資訊，例如，針對畫像或影像等之文本資訊以外的資訊，係亦可同樣的適用本技術。又，在上述之說明中，緊急資訊雖係作為被嵌入至視訊資料中者來作了說明，但是，緊急資訊係亦可被嵌入至音訊資料中。
〈6. 電腦之構成〉
上述之一連串的處理，係可藉由硬體來實行，亦可藉由軟體來實行。在藉由軟體來實行一連串的處理的情況時，構成該軟體之程式，係被安裝於電腦中。圖14，係為對於藉由程式來實行上述之一連串的處理之電腦的硬體之構成例作展示之圖。
在電腦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)
一種受訊裝置，其特徵為，係具備有：受訊部，係受訊數位播送訊號；和取得部，係取得後設資料(meta data)，該後設資料，係為藉由前述數位播送訊號所傳輸之後設資料，並包含有：第1緊急資訊，係為有必要緊急進行告知之資訊、和顯示位置資訊，係代表在非壓縮之視訊資料中是否被嵌入有第2緊急資訊，並且當在前述非壓縮之視訊資料中被嵌入有前述第2緊急資訊的情況時而代表前述第2緊急資訊之在該畫面上的顯示位置；和處理部，係對於前述後設資料進行處理，並當在前述非壓縮之視訊資料中被嵌入有前述第2緊急資訊的情況時，在與前述第2緊急資訊之畫面上的顯示位置相異之位置處，顯示前述第1緊急資訊。
(2)
如(1)中所記載之受訊裝置，其中，前述第1緊急資訊，係為被包含於前述後設資料中所傳輸之文本資訊，前述第2緊急資訊，係為被嵌入至前述視訊資料中所傳輸的文本資訊。
(3)
如(2)中所記載之受訊裝置，其中，前述第1緊急資訊，係由身為有必要緊急進行告知的資訊之標題的訊息、和身為其之詳細內容的說明文，而構成之。
(4)
如(3)中所記載之受訊裝置，其中，前述訊息和前述說明文，係藉由相異之佈置(layout)來顯示。
(5)
如(1)~(4)之任一者中所記載之受訊裝置，其中，前述後設資料，係更進而包含有關連於前述第1緊急資訊之顯示佈置的顯示佈置資訊，前述處理部，係基於前述顯示佈置資訊，而僅當前述第1緊急資訊會被與對應於前述視訊資料之影像作重疊顯示的情況時，將前述第1緊急資訊顯示在與前述第2緊急資訊之畫面上的顯示位置相異之位置處。
(6)
如(1)~(5)之任一者中所記載之受訊裝置，其中，前述顯示位置資訊，係為代表前述第2緊急資訊所被作顯示的畫面上之座標或者是畫面上之特定之區域的資訊。
(7)
如(1)~(6)之任一者中所記載之受訊裝置，其中，前述受訊部，係受訊IP(Internet Protocol)傳輸方式之數位播送訊號。
(8)
一種受訊裝置之資料處理方法，其特徵為，係包含有下述之步驟：使前述受訊裝置，受訊數位播送訊號，取得後設資料(meta data)，該後設資料，係為藉由前述數位播送訊號所傳輸之後設資料，並包含有：第1緊急資訊，係為有必要緊急進行告知之資訊、和顯示位置資訊，係代表在非壓縮之視訊資料中是否被嵌入有第2緊急資訊，並 且當在前述非壓縮之視訊資料中被嵌入有前述第2緊急資訊的情況時而代表前述第2緊急資訊之在該畫面上的顯示位置，對於前述後設資料進行處理，並當在前述非壓縮之視訊資料中被嵌入有前述第2緊急資訊的情況時，在與前述第2緊急資訊之畫面上的顯示位置相異之位置處，顯示前述第1緊急資訊。
(9)
一種送訊裝置，其特徵為，係具備有：產生部，係產生後設資料(meta data)，該後設資料，係包含有：第1緊急資訊，係為有必要緊急進行告知之資訊、和顯示位置資訊，係代表在非壓縮之視訊資料中是否被嵌入有第2緊急資訊，並且當在前述非壓縮之視訊資料中被嵌入有前述第2緊急資訊的情況時而代表前述第2緊急資訊之在受訊裝置之畫面上的顯示位置；和送訊部，係將前述後設資料，作為數位播送訊號來送訊。
(10)
如(9)中所記載之送訊裝置，其中，前述第1緊急資訊，係為被包含於前述後設資料中所傳輸之文本資訊，前述第2緊急資訊，係為被嵌入至前述視訊資料中所傳輸的文本資訊。
(11)
如(10)中所記載之送訊裝置，其中，前述第1緊急資訊，係由身為有必要緊急進行告知的資訊之標題的訊息、和身為其之詳細內容的說明文，而構成之。
(12)
如(11)中所記載之送訊裝置，其中，前述訊息和前述說明文，係藉由相異之佈置(layout)來顯示。
(13)
如(9)~(12)之任一者中所記載之送訊裝置，其中，前述後設資料，係更進而包含有關連於前述第1緊急資訊之顯示佈置的顯示佈置資訊。
(14)
如(9)~(13)之任一者中所記載之送訊裝置，其中，前述顯示位置資訊，係為代表前述第2緊急資訊所被作顯示的畫面上之座標或者是畫面上之特定之區域的資訊。
(15)
如(9)~(14)之任一者中所記載之送訊裝置，其中，前述受訊部，係將前述後設資料，作為IP(Internet Protocol)傳輸方式之數位播送訊號而送訊。
(16)
一種資料處理方法，係為送訊裝置之資料處理方法，其特徵為，係具備有下述之步驟：使前述送訊裝置，產生後設資料(meta data)，該後設資料，係包含有：第1緊急資訊，係為有必要緊急進行告知之資訊、和顯示位置資訊，係代表在非壓縮之視訊資料中是否被嵌入有第2緊急資訊，並且當在前述非壓縮之視訊資料中被嵌入有前述第2緊急資訊的情況時而代表前述第2緊急資訊之在受訊裝 置之畫面上的顯示位置，將前述後設資料，作為數位播送訊號來送訊。
1‧‧‧傳輸系統
10-1、10-2‧‧‧送訊裝置
20-1、20-2、20-3‧‧‧受訊裝置
30‧‧‧電波塔
40‧‧‧EA伺服器
80‧‧‧傳輸路徑
90‧‧‧通訊線路

Claims (16)

  1. 一種受訊裝置，其特徵為，係具備有：受訊部，係受訊數位播送訊號；和取得部，係取得後設資料(meta data)，該後設資料，係為藉由前述數位播送訊號所傳輸之後設資料，並包含有：第1緊急資訊，係為有必要緊急進行告知之資訊、和顯示位置資訊，係代表在非壓縮之視訊資料中是否被嵌入有第2緊急資訊，並且當在前述非壓縮之視訊資料中被嵌入有前述第2緊急資訊的情況時而代表前述第2緊急資訊之在該畫面上的顯示位置；和處理部，係對於前述後設資料進行處理，並當在前述非壓縮之視訊資料中被嵌入有前述第2緊急資訊的情況時，在與前述第2緊急資訊之畫面上的顯示位置相異之位置處，顯示前述第1緊急資訊。
  2. 如申請專利範圍第1項所記載之受訊裝置，其中，前述第1緊急資訊，係為被包含於前述後設資料中所傳輸之文本資訊，前述第2緊急資訊，係為被嵌入至前述視訊資料中所傳輸的文本資訊。
  3. 如申請專利範圍第2項所記載之受訊裝置，其中，前述第1緊急資訊，係由身為有必要緊急進行告知的資訊之標題的訊息、和身為其之詳細內容的說明文，而構成之。
  4. 如申請專利範圍第3項所記載之受訊裝置，其中，前述訊息和前述說明文，係藉由相異之佈置(layout)來顯示。
  5. 如申請專利範圍第1項所記載之受訊裝置，其中，前述後設資料，係更進而包含有關連於前述第1緊急資訊之顯示佈置的顯示佈置資訊，前述處理部，係基於前述顯示佈置資訊，而僅當前述第1緊急資訊會被與對應於前述視訊資料之影像作重疊顯示的情況時，將前述第1緊急資訊顯示在與前述第2緊急資訊之畫面上的顯示位置相異之位置處。
  6. 如申請專利範圍第1項所記載之受訊裝置，其中，前述顯示位置資訊，係為代表前述第2緊急資訊所被作顯示的畫面上之座標或者是畫面上之特定之區域的資訊。
  7. 如申請專利範圍第1項所記載之受訊裝置，其中，前述受訊部，係受訊IP(Internet Protocol)傳輸方式之數位播送訊號。
  8. 一種受訊裝置之資料處理方法，其特徵為，係包含有下述之步驟：使前述受訊裝置，受訊數位播送訊號，取得後設資料(meta data)，該後設資料，係為藉由前述數位播送訊號所傳輸之後設資料，並包含有：第1緊 急資訊，係為有必要緊急進行告知之資訊、和顯示位置資訊，係代表在非壓縮之視訊資料中是否被嵌入有第2緊急資訊，並且當在前述非壓縮之視訊資料中被嵌入有前述第2緊急資訊的情況時而代表前述第2緊急資訊之在該畫面上的顯示位置，對於前述後設資料進行處理，並當在前述非壓縮之視訊資料中被嵌入有前述第2緊急資訊的情況時，在與前述第2緊急資訊之畫面上的顯示位置相異之位置處，顯示前述第1緊急資訊。
  9. 一種送訊裝置，其特徵為，係具備有：產生部，係產生後設資料(meta data)，該後設資料，係包含有：第1緊急資訊，係為有必要緊急進行告知之資訊、和顯示位置資訊，係代表在非壓縮之視訊資料中是否被嵌入有第2緊急資訊，並且當在前述非壓縮之視訊資料中被嵌入有前述第2緊急資訊的情況時而代表前述第2緊急資訊之在受訊裝置之畫面上的顯示位置；和送訊部，係將前述後設資料，作為數位播送訊號來送訊。
  10. 如申請專利範圍第9項所記載之送訊裝置，其中，前述第1緊急資訊，係為被包含於前述後設資料中所傳輸之文本資訊，前述第2緊急資訊，係為被嵌入至前述視訊資料中所傳輸的文本資訊。
  11. 如申請專利範圍第10項所記載之送訊裝置，其中，前述第1緊急資訊，係由身為有必要緊急進行告知的資訊之標題的訊息、和身為其之詳細內容的說明文，而構成之。
  12. 如申請專利範圍第11項所記載之送訊裝置，其中，前述訊息和前述說明文，係藉由相異之佈置(layout)來顯示。
  13. 如申請專利範圍第9項所記載之送訊裝置，其中，前述後設資料，係更進而包含有關連於前述第1緊急資訊之顯示佈置的顯示佈置資訊。
  14. 如申請專利範圍第9項所記載之送訊裝置，其中，前述顯示位置資訊，係為代表前述第2緊急資訊所被作顯示的畫面上之座標或者是畫面上之特定之區域的資訊。
  15. 如申請專利範圍第9項所記載之送訊裝置，其中，前述受訊部，係將前述後設資料，作為IP(Internet Protocol)傳輸方式之數位播送訊號而送訊。
  16. 一種資料處理方法，係為送訊裝置之資料處理方法，其特徵為，係具備有下述之步驟：使前述送訊裝置，產生後設資料(meta data)，該後設資料，係包含有：第1緊急資訊，係為有必要緊急進行告知之資訊、和顯示位置資訊，係代表在非壓縮之視訊資料中是否被嵌入有第2緊急資訊，並且當在前述非壓縮之視訊資料中被嵌 入有前述第2緊急資訊的情況時而代表前述第2緊急資訊之在受訊裝置之畫面上的顯示位置，將前述後設資料，作為數位播送訊號來送訊。
TW105126776A 2015-09-01 2016-08-22 受訊裝置、送訊裝置及資料處理方法 TWI751112B (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2015172366 2015-09-01
JP2015-172366 2015-09-01

Publications (2)

Publication Number Publication Date
TW201724787A true TW201724787A (zh) 2017-07-01
TWI751112B TWI751112B (zh) 2022-01-01

Family

ID=58187390

Family Applications (1)

Application Number Title Priority Date Filing Date
TW105126776A TWI751112B (zh) 2015-09-01 2016-08-22 受訊裝置、送訊裝置及資料處理方法

Country Status (9)

Country Link
US (1) US11330344B2 (zh)
EP (1) EP3346713A4 (zh)
JP (1) JPWO2017038482A1 (zh)
KR (1) KR102535290B1 (zh)
BR (1) BR112018003441A2 (zh)
CA (1) CA2996276C (zh)
MX (1) MX2018002271A (zh)
TW (1) TWI751112B (zh)
WO (1) WO2017038482A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3190764A4 (en) * 2014-09-03 2018-04-25 LG Electronics Inc. Broadcast signal transmission device, broadcast signal reception device, broadcast signal transmission method and broadcast signal reception method

Family Cites Families (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7148909B2 (en) * 1998-05-27 2006-12-12 Canon Kabushiki Kaisha Image display system capable of displaying and scaling images on plurality of image sources and display control method therefor
WO2000074279A1 (fr) * 1999-05-28 2000-12-07 Matsushita Electric Industrial Co., Ltd. Systeme de radiodiffusion
US7308697B1 (en) * 1999-07-14 2007-12-11 Scientific-Atlanta, Inc. Systems and methods for multimedia messaging in a cable or satellite subscriber system
JP2001313911A (ja) * 2000-04-28 2001-11-09 Nippon Hoso Kyokai <Nhk> テレビジョン送信装置およびテレビジョン受信機
JP2004023641A (ja) 2002-06-19 2004-01-22 Fujitsu Ltd ホームページ表示装置
AU2003295492A1 (en) * 2002-11-15 2004-06-15 Thomson Licensing S.A. Methods for controlling apparatuses having an emergency alert function
US7486337B2 (en) 2003-12-22 2009-02-03 Intel Corporation Controlling the overlay of multiple video signals
KR101053596B1 (ko) * 2004-07-15 2011-08-03 엘지전자 주식회사 디지털 케이블 방송 수신기 및 긴급 경고 메시지 처리 방법
KR100995042B1 (ko) * 2004-07-23 2010-11-22 엘지전자 주식회사 디지털 방송 수신기 및 그의 긴급 경고 메시지 처리 방법
KR101108053B1 (ko) * 2005-10-21 2012-02-06 엘지전자 주식회사 지상파 방송의 비상 사태 채널 설정 방법, 데이터 구조 및이를 위한 방송 수신기
WO2008030069A1 (en) * 2006-09-08 2008-03-13 Lg Electronics Inc. Broadcasting receiver and method of processing emergency alert message
KR20080046325A (ko) * 2006-11-22 2008-05-27 엘지전자 주식회사 지상파 방송의 비상 사태 경보와 관련된 방송 신호, 이를처리하는 방법 및 이를 위한 방송 수신기
CN101355582B (zh) 2008-08-28 2011-08-24 中兴通讯股份有限公司 一种网页点击拨号的鉴权方法及系统
JP5463747B2 (ja) 2009-06-15 2014-04-09 ソニー株式会社 受信装置、送信装置、通信システム、表示制御方法、プログラム、及びデータ構造
US20110037590A1 (en) * 2009-08-12 2011-02-17 Qualcomm Incorporated System and apparatus for delivering emergency alert messages as a service content in a broadcast network
JP2012015930A (ja) * 2010-07-05 2012-01-19 Hitachi Consumer Electronics Co Ltd デジタル放送受信装置およびデジタル放送受信方法
JP2013009335A (ja) * 2011-05-20 2013-01-10 Nippon Hoso Kyokai <Nhk> 受信機
WO2012161552A2 (ko) 2011-05-25 2012-11-29 엘지전자 주식회사 송/수신 시스템 및 방송 신호 처리 방법
WO2013021643A1 (ja) * 2011-08-11 2013-02-14 パナソニック株式会社 放送通信連携システム、データ生成装置及び受信装置
CN103416080B (zh) * 2012-03-02 2016-10-19 Lg电子株式会社 经由移动广播提供紧急报警服务的方法及其设备
CN104798378B (zh) 2012-11-19 2016-08-24 三菱电机株式会社 数字广播接收装置及数字广播接收方法
US9165203B2 (en) * 2013-03-15 2015-10-20 Arris Technology, Inc. Legibility enhancement for a logo, text or other region of interest in video
EP2866436A1 (en) 2013-10-23 2015-04-29 Thomson Licensing Method and apparatus for transmission and reception of media data
JP2015104055A (ja) 2013-11-27 2015-06-04 ソニー株式会社 受信装置、受信方法、送信装置、及び、送信方法
KR101984066B1 (ko) * 2014-01-24 2019-09-03 한국전자통신연구원 방송 시스템을 이용한 재해 조기경보 방법 및 시스템
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
US20160127439A1 (en) * 2014-11-03 2016-05-05 Qualcomm Incorporated Interfacing multimedia public warning system alerts

Also Published As

Publication number Publication date
CA2996276A1 (en) 2017-03-09
TWI751112B (zh) 2022-01-01
US11330344B2 (en) 2022-05-10
MX2018002271A (es) 2018-03-23
KR20180044903A (ko) 2018-05-03
US20180213298A1 (en) 2018-07-26
JPWO2017038482A1 (ja) 2018-06-21
EP3346713A4 (en) 2019-01-16
KR102535290B1 (ko) 2023-05-22
CA2996276C (en) 2023-08-01
WO2017038482A1 (ja) 2017-03-09
BR112018003441A2 (pt) 2018-11-27
EP3346713A1 (en) 2018-07-11

Similar Documents

Publication Publication Date Title
US10623827B2 (en) Receiving device, receiving method, transmitting device, and transmitting method
US11374993B2 (en) Reception device, reception method, transmission device, and transmission method
KR101760445B1 (ko) 수신 장치, 수신 방법, 송신 장치 및 송신 방법
KR102527738B1 (ko) 비상 정보의 로케이션 기반 필터링을 위한 수신 장치, 수신 방법, 송신 장치 및 송신 방법
US11184095B2 (en) Receiving apparatus, transmitting apparatus, and data processing method
TWI751112B (zh) 受訊裝置、送訊裝置及資料處理方法