TWI646833B - 用於傳訊緊急警示之系統及方法 - Google Patents

用於傳訊緊急警示之系統及方法 Download PDF

Info

Publication number
TWI646833B
TWI646833B TW106114210A TW106114210A TWI646833B TW I646833 B TWI646833 B TW I646833B TW 106114210 A TW106114210 A TW 106114210A TW 106114210 A TW106114210 A TW 106114210A TW I646833 B TWI646833 B TW I646833B
Authority
TW
Taiwan
Prior art keywords
service
message
information
low
parsing
Prior art date
Application number
TW106114210A
Other languages
English (en)
Other versions
TW201743621A (zh
Inventor
曉 黃
賽欽 G 迪斯潘迪
基朗 莫克許 米斯拉
克里斯多夫 安德魯 塞蓋爾
Original Assignee
夏普股份有限公司
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 夏普股份有限公司 filed Critical 夏普股份有限公司
Publication of TW201743621A publication Critical patent/TW201743621A/zh
Application granted granted Critical
Publication of TWI646833B publication Critical patent/TWI646833B/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
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/2362—Generation or processing of Service Information [SI]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • 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
    • H04H—BROADCAST COMMUNICATION
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/86—Arrangements characterised by the broadcast information itself
    • H04H20/93—Arrangements characterised by the broadcast information itself which locates resources of other pieces of information, e.g. URL [Uniform Resource Locator]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4345—Extraction or processing of SI, e.g. extracting service information from an MPEG stream

Landscapes

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

Abstract

一種裝置可經組態以接收來自一廣播串流之一低層級傳訊通知片段。該裝置可剖析該通知片段。該裝置可基於該通知片段而判定一緊急警示訊息是否直接整合至一服務之一媒體分量中。該裝置可基於一緊急警示訊息是否直接整合至形成該服務之一媒體分量中之該判定而修改該服務之呈現。

Description

用於傳訊緊急警示之系統及方法
本發明係關於互動電視之領域。
數位媒體播放能力可併入至範圍廣泛之裝置中，該等裝置包含數位電視(包含所謂的「智慧型」電視)、機上盒、膝上型或桌上型電腦、平板電腦、數位記錄裝置、數位媒體播放器、視訊遊戲裝置、蜂巢式電話(包含所謂的「智慧型」電話)、專用視訊串流裝置及諸如此類。數位媒體內容(例如，視訊及音訊節目)可源自複數個源，該等源包含(舉例而言)無線電視提供者、衛星電視提供者、有線電視提供者、在線媒體服務提供者(包含所謂的串流服務提供者)及諸如此類。可經由封包交換網路(包含諸如網際網路協定(IP)網路之雙向網路及諸如數位廣播網路之單向網路)遞送數位媒體內容。 可根據一傳輸標準將數位媒體內容自一源傳輸至一接收器裝置(例如，一數位電視或一智慧型電話)。傳輸標準之實例包含數位視訊廣播(DVB)標準、整合服務數位廣播標準(ISDB)標準及由進階電視系統委員會(ATSC)開發之標準(舉例而言，包含ATSC 2.0標準)。ATSC當前正開發所謂的ATSC 3.0標準套組。ATSC 3.0標準套組力圖透過多樣遞送機制支援範圍廣泛之多樣服務。舉例而言，ATSC 3.0標準套組力圖支援廣播多媒體遞送、所謂的廣播串流/檔案下載多媒體遞送、所謂的寬頻串流/檔案下載多媒體遞送及其組合(亦即，「混合服務」)。ATSC 3.0標準套組所預期之一混合服務之一實例包含一接收器裝置接收一無線視訊廣播(例如，透過一單向傳送)且透過一封包交換網路(亦即，透過一雙向傳送)自一在線媒體服務提供者接收一經同步次要音訊呈現(例如，一次要語言)。除定義數位媒體內容可如何自一源傳輸至一接收器裝置之外，傳輸標準亦可規定緊急警示訊息可如何自一源傳達至一接收器裝置。用於傳達緊急警示訊息及其他螢幕上通知之當前技術可能不太理想。
根據本發明之一項實例，揭示一種用於傳訊一訊息是否直接整合至形成一服務之一視訊分量中之方法，該方法包括：傳訊指示一低層級通知片段之一例項具有與直接整合至形成一服務之一視訊分量中之訊息相關聯之一類型的一值；及傳訊包含於該通知片段之該例項中之一或多個語法元素之值，該等值指示一訊息是否直接整合至一特定服務之一視訊分量中。 根據本發明之一項實例，揭示一種用於回應於一通知訊息而修改一服務之呈現之方法，該方法包括：接收具有與直接整合至形成一服務之一視訊分量中之訊息相關聯之一類型的一低層級通知片段之一例項；藉由剖析來自該通知片段之資訊而判定一通知訊息直接整合至形成一服務之一媒體分量中；且基於一通知訊息是否直接整合至形成該服務之一媒體分量中之該判定而修改該服務之呈現。 根據本發明之一項實例，揭示一種包括一非暫時性電腦可讀儲存媒體及一或多個處理器之裝置，該裝置經組態以：接收具有與直接整合至形成一服務之一視訊分量中之訊息相關聯之一類型的一低層級通知片段之一例項；藉由剖析來自該通知片段之資訊而判定一通知訊息直接整合至形成一服務之一媒體分量中；及基於一通知訊息是否直接整合至形成該服務之一媒體分量中之該判定而修改該服務之呈現。 在附圖及下文說明中陳述一或多個實例之細節。依據該說明及該等圖式且依據申請專利範圍將明瞭其他特徵、目標及優點。
一般而言，本發明闡述用於傳訊與通知訊息(舉例而言，包含緊急警示訊息)相關聯之資訊之技術。特定而言，本文中所闡述之技術可用於傳訊一類型之緊急警示訊息、與一緊急警示訊息相關聯之時序資訊及/或與一緊急警示訊息相關聯之其他資訊。在某些情形中，一接收器裝置可能夠剖析與緊急警示訊息相關聯之資訊且致使數位媒體內容之呈現/再現經修改，使得對應緊急訊息警示對於一使用者而言更明顯。舉例而言，若傳訊資訊指示存在一特定類型之緊急警示訊息，則一接收器裝置可經組態以關閉或暫時中止一應用程式。應注意，儘管在某些實例中關於緊急警示闡述本文中所闡述之技術，但本文中所闡述之技術可一般更適用於其他類型之警示及訊息。舉例而言，一廣告伺服器可經組態以產生可連同多媒體內容(例如，一電視節目)呈現之補充內容(例如，一橫幅廣告)。以類似於本文中關於緊急警示訊息闡述之方式之一方式，可根據本文中所闡述之技術傳訊與廣告訊息相關聯之資訊及諸如此類。應注意，儘管在某些實例中關於ATSC標準闡述本發明之技術，但本文中所闡述之技術一般可適用於任何傳輸標準。舉例而言，本文中所闡述之技術一般可適用於DVB標準、ISDB標準、ATSC標準、數位地面多媒體廣播(DTMB)標準、數位多媒體廣播(DMB)標準、混合廣播及寬頻電視(HbbTV)標準、全球資訊網聯盟(W3C)標準、通用隨插即用(UPnP)標準及其他視訊編碼標準中之任一者。進一步地，應注意，文件以引用方式併入本文中係出於闡述性目的且不應被解釋為關於本文中所使用之術語進行限制及/或產生歧義。舉例而言，在其中一個所併入參考文獻提供不同於另一所併入參考文獻之一術語之一定義之情形中及/或如本文中使用術語，應以廣義地包含每一各別定義之一方式及/或以在替代方案中包含特定定義中之每一者之一方式解釋術語。 根據本發明之一項實例，一種用於傳訊與一緊急警示訊息相關聯之資訊之方法包括：傳訊指示一緊急警示訊息直接整合至形成一服務之一媒體分量中之一語法元素及傳訊以下語法元素中之一或多者：識別對應於該服務之一資料通道之一語法元素、唯一地識別在該資料通道內之該服務之一語法元素、指示一緊急警示訊息之一開始時間之一語法元素及指示一緊急警示訊息之一持續時間之一語法元素。 根據本發明之另一實例，一種用於傳訊與一緊急警示訊息相關聯之資訊之裝置包括一或多個處理器，該一或多個處理器經組態以傳訊指示一緊急警示訊息直接整合至形成一服務之一媒體分量中之一語法元素且傳訊以下語法元素中之一或多者：識別對應於該服務之一資料通道之一語法元素、唯一地識別在該資料通道內之該服務之一語法元素、指示一緊急警示訊息之一開始時間之一語法元素及指示一緊急警示訊息之一持續時間之一語法元素。 根據本發明之另一實例，一種設備包括用於傳訊指示一緊急警示訊息直接整合至形成一服務之一媒體分量中之一語法元素之構件及用於傳訊以下語法元素中之一或多者之構件：識別對應於該服務之一資料通道之一語法元素、唯一地識別在該資料通道內之該服務之一語法元素、指示一緊急警示訊息之一開始時間之一語法元素及指示一緊急警示訊息之一持續時間之一語法元素。 根據本發明之另一實例，一種非暫時性電腦可讀儲存媒體包括儲存於其上之指令，該等指令在執行之後致使一裝置之一或多個處理器傳訊指示一緊急警示訊息直接整合至形成一服務之一媒體分量中之一語法元素且傳訊以下語法元素中之一或多者：識別對應於該服務之一資料通道之一語法元素、唯一地識別在該資料通道內之該服務之一語法元素、指示一緊急警示訊息之一開始時間之一語法元素及指示一緊急警示訊息之一持續時間之一語法元素。 根據本發明之一項實例，一種用於回應於一緊急警示訊息而修改一服務之呈現之方法包括：接收來自一廣播串流之一傳訊通知片段；藉由剖析來自該傳訊通知片段之資訊而判定一緊急警示訊息直接整合至形成一服務之一媒體分量中；及基於一緊急警示訊息是否直接整合至形成該服務之一媒體分量中之該判定而修改該服務之該呈現。 根據本發明之另一實例，一種用於回應於一緊急警示訊息而修改一服務之呈現之裝置包括一或多個處理器，該一或多個處理器經組態以接收來自一廣播串流之一傳訊通知片段，藉由剖析來自該傳訊通知片段之資訊而判定一緊急警示訊息直接整合至形成一服務之一媒體分量中，且基於一緊急警示訊息是否直接整合至形成該服務之一媒體分量中之該判定而修改該服務之該呈現。 根據本發明之另一實例，一種設備包括用於接收來自一廣播串流之一傳訊通知片段之構件、用於藉由剖析來自該傳訊通知片段之資訊而判定一緊急警示訊息直接整合至形成一服務之一媒體分量中之構件及用於基於一緊急警示訊息是否直接整合至形成該服務之一媒體分量中之該判定而修改該服務之該呈現之構件。 根據本發明之另一實例，一種非暫時性電腦可讀儲存媒體包括儲存於其上之指令，該等指令在執行之後致使一裝置之一或多個處理器接收來自一廣播串流之一傳訊通知片段，藉由剖析來自該傳訊通知片段之資訊而判定一緊急警示訊息直接整合至形成一服務之一媒體分量中，且基於一緊急警示訊息是否直接整合至形成該服務之一媒體分量中之該判定而修改該服務之該呈現。 傳輸標準可定義緊急警示可如何自一服務提供者傳達至接收器裝置。緊急警示通常由一緊急權威機構產生且傳輸至一服務提供者。可包含一緊急權威機構作為一政府機關之部分。舉例而言，緊急權威機構可包含美國國家氣象局、美國國土安全部、本機及區域機關(例如，警察及消防部門)及諸如此類。緊急警示可包含關於一當前或預期緊急情況之資訊。資訊可包含意欲促進生命、健康、安全及財產之保護之資訊，且可包含關於緊急情況及如何對緊急情況做出回應之關鍵細節。可與一緊急警示相關聯之緊急情況之類型之實例包含龍捲風、颶風、洪水、潮波、地震、結冰情況、大雪、廣泛火災、毒氣排放、廣泛電力故障、工業爆炸、內亂、即將發生之天氣變化之警告及預警及諸如此類。 諸如(舉例而言)一電視廣播者(例如，一區域網路聯合者)、一多頻道視訊節目分配者(MVPD) (例如，一有限電視服務運營商、一衛星電視服務運營商、一網際網路協定電視(IPTV)服務運營商)及諸如此類之一服務提供者可產生一或多個緊急警示訊息以用於分配至接收器裝置。緊急警示及/或緊急警示訊息可包含文本(例如，「惡劣天氣警示」)、影像(例如，一天氣圖)、音訊內容(例如，警告音、音訊訊息等)、視訊內容及/或電子文件中之一或多者。在某些實例中，緊急警示訊息可直接整合至一多媒體內容之呈現中(亦即，作為一捲動橫幅「預燒」至視訊或與一音軌混合)。進一步地，在某些實例中，緊急警示及/或緊急警示訊息可包含統一資源識別符(URI)。舉例而言，一緊急警示訊息可包含識別在何處可獲得與緊急情況相關之額外資訊(例如，視訊、音訊、文本、影像等)之統一資源定位符(URL) (例如，包含闡述緊急情況之一文件的一伺服器之IP位址)。接收包含一URL之一緊急警示訊息(透過一單向廣播或透過一雙向寬頻連接)之一接收器裝置可獲得闡述一緊急警示之一文件，剖析該文件，且在一顯示器上顯示包含於該文件中之資訊(例如，產生一捲動橫幅且在視訊呈現上疊加該捲動橫幅，再現影像，播放音訊訊息)。在某些實例中，可根據包含(舉例而言)共同警示協定(CAP)之一協定定義闡述一緊急警示之文件。協定可規定用於格式化一緊急警示訊息之一或多個模式，諸如(舉例而言)基於超文本標記語言(HTML)、動態HTML、可延伸標記語言(XML)、JavaScript物件記法(JSON)及級聯式樣表單(CSS)之模式。在以引用方式併入本文中之2010年7月1日之OASIS：「共同警示協定」版本1.2 (在下文為「CAP版本1.2」)中闡述之共同警示協定版本1.2提供可如何根據一XML模式格式化一緊急警示訊息之一實例。 運算裝置及/或傳輸系統可基於包含一或多個抽象層之模型，其中根據特定結構(例如，封包結構、調變方案等)表示每一抽象層處之資料。包含經定義抽象層之一模型之一實例係圖1中所圖解說明之所謂的開放系統互連(OSI)模型。該OSI模型定義一7層堆疊模型，包含一應用程式層、一呈現層、一工作階段層、一傳送層、一網路層、一資料連結層及一實體層。應注意，關於闡述一堆疊模型中之層使用術語上部及下部可基於應用程式層係最上部層且實體層係最下部層。進一步地，在某些情形中，術語「層1」或「L1」可用於係指一實體層，術語「層2」或「L2」可用於係指一連結層，且術語「層3」或「L3」或「IP層」可用於係指網路層。 一實體層可一般係指電信號在其處形成數位資料之一層。舉例而言，一實體層可係指定義經調變射頻(RF)符號如何形成數位資料之一訊框之一層。亦可稱為連結層之一資料連結層可係指在一發送側處在實體層處理之前且在一接收側處在實體層接收之後使用的一抽象化。如本文中所使用，一連結層可係指用於在一發送側處將資料自一網路層傳送至一實體層且用於在一接收側處將資料自一實體層傳送至一網路層的一抽象化。應注意，一發送側及一接收側係邏輯作用且一單個裝置可在一個例項中操作為一發送側且在另一例項中操作為一接收側兩者。一連結層可將囊封於特定封包類型(例如，動畫專家群－傳送串流(MPEG-TS)封包、網際網路協定版本4 (IPv4)封包等)中之各種類型之資料(例如，視訊、音訊或應用程式檔案)抽象化成一單個同屬格式以用於由一實體層處理。一網路層可一般係指在其處發生邏輯定址之一層。亦即，一網路層可一般提供定址資訊(例如，網際網路協定(IP)位址、URL、URI等)，使得資料封包可遞送至一網路內之一特定節點(例如，一運算裝置)。如本文中所使用，術語網路層可係指在一連結層上面之一層及/或具有呈一結構之資料使得其可經接收以用於連結層處理的一層。一傳送層、一工作階段層、一呈現層及一應用程式層中之每一者可定義如何遞送資料以供由一使用者應用程式使用。 包含當前在發展中之傳輸標準之傳輸標準可包含規定每一層之所支援協定之一內容遞送協定模型且可進一步定義一或多個特定層實施方案。再次參考圖1，圖解說明一實例性內容遞送協定模型。在圖1中所圖解說明之實例中，出於說明性目的，內容遞送協定模型100一般與7層OSI模型對準。應注意，不應將此一圖解說明解釋為限制內容遞送協定模型100之實施方案及/或本文中所闡述之技術。內容遞送協定模型100可一般對應於ATSC 3.0標準套組之當前所提議內容遞送協定模型。進一步地，本文中所闡述之技術可實施於經組態以基於內容遞送協定模型100而操作之一系統中。 ATSC 3.0標準套組包含ATSC標準A/321 (以其全文引用方式併入本文中之2016年3月23日之系統發現與傳訊文件A/321：2016 (在下文為「A/321」))。A/321闡述一ATSC 3.0單向實體層實施方案之一實體層波形之初始進入點。進一步地，當前正在發展中之ATSC 3.0標準套組之態樣闡述於候選標準、其修訂及工作草稿(WD)中，其中之每一者可包含用於包含於一ATSC 3.0標準之一已發行(亦即，「最終」或「所採用」)版本中之所提議態樣。舉例而言，ATSC標準：以其全文引用方式併入本文中之2015年9月6日之實體層協定文件S32-230r45闡述ATSC 3.0之一所提議單向實體層。該所提議ATSC 3.0單向實體層包含一實體層訊框結構，該實體層訊框結構包含一經定義啟動程式、前文及資料有效負載結構，從而包含一或多個實體層管線(PLP)。一PLP可一般係指在一RF頻道內之一邏輯結構或一RF頻道之一部分。所提議ATSC 3.0標準套組係指一RF頻道作為一廣播串流之抽象化。所提議ATSC 3.0標準套組進一步提供一PLP由一PLP識別符(PLPID)識別，該PLP識別符在其所屬之廣播串流內係唯一的。亦即，一PLP可包含具有特定調變及編碼參數之一RF頻道(例如，由一地理區及頻率識別之一RF頻道)之一部分。 所提議ATSC 3.0單向實體層提供一單個RF頻道可含有一或多個PLP且每一PLP可攜載一或多個服務。在一項實例中，多個PLP可攜載一單個服務。在所提議ATSC 3.0標準套組中，術語服務可用於係指合計呈現給使用者之媒體分量(例如，一視訊分量、一音訊分量及一副標題分量)之一集合，其中分量可係為多個媒體類型，其中一服務可係連續的或間斷的，其中一服務可係一即時服務(例如，對應於一直播事件之多媒體呈現)或一非即時服務(例如，一視訊按需服務、一電子服務導引服務)，且其中一即時服務可包含一電視節目序列。服務可包含基於應用程式之特徵。基於應用程式之特徵可包含包含一應用程式之服務分量、將由該應用程式使用之可選檔案及引導該應用程式在特定時間進行特定動作之可選通知。在一項實例中，一應用程式可係構成一經增強或互動式服務之一文件集合。一應用程式之文件可包含HTML、JavaScript、CSS、XML及/或多媒體檔案。應注意，所提議ATSC 3.0標準套組規定可在未來版本中定義新類型之服務。因此，如本文中所使用，術語服務可係指關於所提議ATSC 3.0標準套組所闡述之一服務及/或其他類型之數位媒體服務。如上文所闡述，一服務提供者可自一緊急權威機構接收一緊急警示且產生可連同一服務分配給接收器裝置之緊急警示訊息。一服務提供者可產生整合至一多媒體呈現中之一緊急警示訊息及/或產生一緊急警示訊息作為一基於應用程式之增強之部分。舉例而言，緊急資訊可在視訊中顯示為文本(其可稱為緊急螢幕上文本資訊)，且可包含(舉例而言)一捲動橫幅(其可稱為一爬行)。該捲動橫幅可由接收器裝置接收作為預燒至一視訊呈現之一文本訊息(例如，作為一螢幕上緊急警示訊息)及/或作為包含於一文件中之文本(例如，一CAP XML片段)。應注意，本文中所闡述之技術可一般適用於一服務提供者整合至一多媒體呈現中之任何類型之訊息收發，亦即，本文中所闡述之技術可一般適用於「預燒」傳訊。 參考圖1，內容遞送協定模型100透過ATSC廣播實體層使用在使用者資料報協定(UDP)及網際網路協定(IP)上方之MPEG媒體傳送協定(MMTP)以及在UDP及IP上方之單向傳送即時物件遞送(ROUTE)來支援串流及/或檔案下載。在ISO/IEC：ISO/IEC 23008-1，「資訊技術-異質環境中之高效編碼及媒體遞送-第1部分：MPEG媒體傳送(MMT)」中闡述MMTP。在ATSC候選標準：2016年1月14日之傳訊、遞送、同步及錯誤保護(A/331)文件S33-1-500r5 (2016年3月31日修訂版5) (在下文為「A/331」)中提供對ROUTE之一概述，該文件以其全文引用方式併入本文中。應注意，儘管ATSC 3.0在某些內容脈絡中使用術語廣播來係指一單向無線傳輸實體層，但所謂的ATSC 3.0廣播實體層透過串流或檔案下載支援視訊遞送。如此，如本文中所使用之術語廣播不應用於限制可根據本發明之一或多種技術傳送視訊及相關聯資料之方式。進一步地，內容遞送協定模型100支援在ATSC廣播實體層處傳訊(例如，使用實體訊框前文傳訊)、在ATSC連結層處傳訊(使用一連結映射表(LMT)傳訊)、在IP層處傳訊(例如，所謂的低層級傳訊(LLS))、服務層傳訊(SLS) (例如，使用MMTP或ROUTE中之訊息傳訊)及應用程式或呈現層傳訊(例如，使用一視訊或音訊浮水印傳訊)。 在某些實例中，接收一緊急警示訊息之一接收器裝置可接收對應於一緊急警示訊息之資訊。如上文所闡述，在所提議ATSC 3.0標準套組中，實體層包含一訊框結構，該訊框結構包含一啟動程式、一前文及一資料有效負載，從而包含一或多個PLP。A/321定義包含三個符號之一啟動程式。在A/321中，第一啟動程式符號包含一第一緊急警示喚醒單位元欄位ea_wake_up_1，且第二啟動程式符號包含一第二緊急警示喚醒單位元欄位ea_wake_up_2。所提議ATSC 3.0標準套組，根據表1定義ea_wake_up_1及ea_wake_up_2之值。 表1 因此，ea_wake_up_1及ea_wake_up_2中之每一者使得接收器裝置能夠偵測緊急資訊是否可用(亦即，當ea_wake_up_1及ea_wake_up_2中之任一者等於1時)。進一步地，在表1中，自一個設定至另一設定之一改變指示一新喚醒調用。應注意，在所提議ATSC 3.0標準套組中，不存在使用ea_wake_up_1及ea_wake_up_2之要求。亦即，一服務提供者可在不使用緊急警示喚醒位元之情況下分配一緊急警示訊息。進一步地，關於所提議ATSC 3.0標準套組，一設定意欲係相對靜態的(亦即，以一相對低頻率(例如，分鐘或小時)改變)。舉例而言，可在一冬季風暴預警緊急警示改變至一冬季風暴警告緊急警示之情況下/時發生自一個設定至另一設定之一改變。 如上文所闡述，所提議ATSC 3.0標準套組支援在IP層處傳訊，其稱為低層級傳訊(LLS)。在所提議ATSC 3.0標準套組中，LLS包含具有專用於此傳訊功能之一位址/埠之在IP封包之有效負載中攜載之傳訊資訊。所提議ATSC 3.0標準套組定義可以一LLS表之形式傳訊之四種類型之LLS資訊：服務清單表(SLT)、分級區域表(RRT)、系統時間片段及共同警示協定(CAP)訊息。表2提供經提供用於一LLS表之語法，如根據所提議ATSC 3.0標準套組所定義。在表2以及本文中所闡述之其他表中，uimsbf係指一無符號整數最高有效位元在先資料格式且var係指位元之一變數。 表2 A/331提供包含於表2中之語法元素之以下語義學： LLS_table_id －應識別在主體中遞送之表類型之一8位元無符號整數。 provider_id －應識別與在LLS_table()之此例項中傳訊之服務相關聯之提供者之一8位元無符號整數，其中一「提供者」係使用此廣播串流之部分或全部來廣播服務之一廣播者。provider _id在此廣播串流內應係唯一的。 LLS_table_version－每當由table_id識別之表中之任何資料改變時應遞增1之一8位元無符號整數。當值達到0xFF時，值應在遞增之後繞回至0x00。 SLT －以gzip [亦即，gzip檔案格式]壓縮之XML格式服務清單表。 RRT －以gzip壓縮之符合在[A/331之]Annex F中規定之結構之一分級區域表之一例項。 SystemTime －以gzip壓縮之XML格式系統時間片段。 CAP －以gzip壓縮之XML格式共同警示協定片段。 應注意，所提議ATSC 3.0標準套組規定根據CAP版本1.2格式化一共同警示協定片段。應注意，當前提議將對CAP版本1.2之修改包含於ATSC 3.0標準套組中。 如上文所闡述，所提議ATSC 3.0標準套組支援使用一視訊或音訊浮水印傳訊。一浮水印可用於確保一接收器裝置可擷取補充內容(例如，緊急訊息、交替音軌、應用程式資料、隱藏字幕資料等)而不管如何分配多媒體內容。舉例而言，一區域網路聯合者可將一浮水印嵌入於一視訊信號中以確保一接收器裝置可擷取與一地方電視呈現(例如，一地方新聞廣播)相關聯之補充資訊且因此將補充內容再現給一觀看者。舉例而言，一內容提供者可希望確保訊息在一重新分配情境期間與一媒體服務之呈現一起出現。一重新分配情境之一實例可包含其中一ATSC 3.0接收器裝置接收一多媒體信號(例如，一視訊及/或音訊信號)且自該多媒體信號恢復所嵌入資訊之一情景。舉例而言，一接收器裝置(例如，一數位電視)可自一多媒體介面(例如，一高清晰度多媒體介面(HDMI)或諸如此類)接收一未壓縮視訊信號且該接收器裝置可自該未壓縮視訊信號恢復所嵌入資訊。在某些情形中，當一MVPD充當一接收器裝置與一內容提供者(例如，一區域網路聯合者)之間的一中介機構時可出現一重新分配情境。在此等情形中，一機上盒可透過特定實體連結及/或網路層格式接收一多媒體服務資料串流且將一未壓縮多媒體信號輸出至一接收器裝置。應注意，在某些實例中，一重新分配情境可包含其中機上盒或一家用媒體伺服器充當家用式視訊分配器且伺服(例如，透過一區域有線或無線網路)於所連接裝置(例如，智慧型電話、平板等)之一情景。進一步地，應注意，在某些情形中，一MVPD可將一浮水印嵌入於一視訊信號中以增強源自一內容提供者(例如，提供一目標補充廣告)之內容。 ATSC候選標準：以其全文引用方式併入之2016年1月15日之內容恢復(A/336)文件S33-178r2 (在本文中為「A/336」)規定特定傳訊資訊可如何攜載於音訊浮水印有效負載、視訊浮水印有效負載及音軌之使用者區中且此資訊可如何用於在一重新分配情境中存取補充內容。A/336闡述一視訊浮水印有效負載可包含emergency_alert_message()之情況。一emergency_alert_message()支援視訊浮水印中之緊急警示資訊之遞送。表3提供一emergency_alert_message()之語法，如A/336中所提供。 表3 A/336提供各別語法元素CAP_message_ID_length、CAP_message_ID、CAP_message_url_length、CAP_message_url、expires、urgency、severity_certainty之以下定義。應注意，在表3及所包含之其他表中，bslbf可係指位元字串、左位元在先。 CAP_message_ID_length －此8位元無符號整數欄位以位元組為單位給出CAP_message_ID欄位之長度。 CAP_message_ID －此字串應給出在[CAP版本1.2]中定義之CAP訊息之ID。其應係由CAP_message_url指示之[共同警示協定(CAP)]訊息之cap.alert.identifier元素之值。 CAP_message_url_length －此8位元無符號整數欄位以位元組為單位給出CAP_message_url欄位之長度。 CAP_message_url －此字串應給出可用於擷取CAP訊息之URL。 expires －此參數應指示CAP訊息中之任一＜info＞元素之最新到期日及時間，其編碼為自1970年1月1日00：00：00 (國際原子時(TAI))起之秒數之一32位元計數。 urgency －當設定為「1」時，此旗標應指示CAP訊息中之最緊迫＜info＞元素之緊迫性係「立即的」。當設定為「0」時，其應指示相反情況。 severity_certainty －此係自所需要CAP元素之值導出之關於確實性及嚴重性之一4位元欄位碼。 以此方式，所提議ATSC 3.0標準套組提供用於使用嵌入於一浮水印信號中之一URL擷取一CAP XML片段及/或藉由剖析一LLS表擷取一CAP XML片段的一機制且提供使用一實體層訊框之前文中之兩個單位元欄位之緊急警示喚醒傳訊。當前所提議ATSC 3.0標準套組不提供用以傳訊一緊急警示訊息是否直接整合至一多媒體內容之呈現中(例如，視訊是否具有作為一螢幕上緊急警示訊息之部分預燒至視訊之一緊急警示訊息)之一機制。應注意，在某些情形中，為了確保直接整合至一多媒體內容之呈現中之一緊急警示訊息對於一使用者係明顯的，傳訊一緊急警示訊息是否直接整合至一多媒體內容之呈現中對於一服務提供者可係有用及/或必要的。舉例而言，一接收器裝置可運行最小化一多媒體呈現之大小之一應用程式(例如，一電子服務導引應用程式)或在掩蓋一緊急警示訊息之一顯示器上再現一基於應用程式之特徵(例如，蓋住一緊急警示之捲動文本之在一顯示器之底部處之一彈出廣告窗)。在此等實例中，暫時中止應用程式及/或改變再現一多媒體呈現之方式以便增加一使用者知曉緊急警示訊息之可能性對於一接收器裝置可係有用及/或必要的。 圖2係圖解說明可實施本發明中所闡述之一或多種技術之一系統之一實例之一方塊圖。根據本文中所闡述之技術，系統200可經組態以傳達資料。在圖2中所圖解說明之實例中，系統200包含一或多個接收器裝置202A至202N、電視服務網路204、電視服務提供者網站206、廣域網路212、一或多個內容提供者網站214、一或多個緊急權威機構網站216及一或多個緊急警示資料提供者網站218。系統200可包含軟體模組。軟體模組可儲存於一記憶體中且由一處理器執行。系統200可包含一或多個處理器及複數個內部及/或外部記憶體裝置。記憶體裝置之實例包含檔案伺服器、檔案傳遞協定(FTP)伺服器、網路附接儲存(NAS)裝置、本機磁碟機或能夠儲存資料之任一其他類型之裝置或儲存媒體。儲存媒體可包含藍光碟片、DVD、CD-ROM、磁碟、快閃記憶體或任一其他適合數位儲存媒體。當在軟體中部分地實施本文中所闡述之技術時，一裝置可將用於軟體之指令儲存於一適合非暫時性電腦可讀媒體中且使用一或多個處理器執行硬體中之指令。 系統200表示可經組態以允許數位媒體內容(諸如，舉例而言，一電影、一直播體育賽事等)與資料、應用程式及與其相關聯之媒體呈現(例如，緊急訊息警示)分配至諸如接收器裝置202A至202N之複數個運算裝置且由該複數個運算裝置存取的一系統之一實例。在圖2中所圖解說明之實例中，接收器裝置202A至202N可包含經組態以自電視服務提供者網站206接收資料之任何裝置。舉例而言，接收器裝置202A至202N可經配備以用於有線及/或無線通信且可經組態以透過一或多個資料通道接收服務且可包含電視(包含所謂的智慧型電視)、機上盒及數位視訊記錄器。進一步地，接收器裝置202A至202N可包含經組態以自電視服務提供者網站206接收資料之桌上型、膝上型或平板電腦、遊戲控制台、行動裝置(包含，舉例而言，「智慧型」電話)、蜂巢式電話及個人遊戲裝置。應注意，儘管系統200經圖解說明為具有不同網站，但此一圖解說明係出於闡述性目的且不將系統200限制於一特定實體架構。可使用硬體、韌體及/或軟體實施方案之任一組合實現系統200及包含於其中之網站之功能。 電視服務網路204係經組態以使得能夠分配可包含電視服務之數位媒體內容之一網路之一實例。舉例而言，電視服務網路204可包含公共無線電視網路、公共或基於訂閱之衛星電視服務提供者網路及公共或基於訂閱之有線電視提供者網路及/或雲上或網際網路服務提供者。應注意，儘管在某些實例中電視服務網路204可主要用於使得能夠提供電視服務，但電視服務網路204亦可使得能夠根據本文中所闡述之電信協定之任一組合提供其他類型之資料及服務。進一步地，應注意，在某些實例中，電視服務網路204可達成電視服務提供者網站206與接收器裝置202A至202N中之一或多者之間的雙向通信。電視服務網路204可包括無線及/或有線通信媒體之任何組合。電視服務網路204可包含同軸電纜、光纖電纜、雙絞線電纜、無線傳輸器及接收器、路由器、交換機、中繼器、基地台或可用於促進各種裝置及網站之間的通信之任何其他設備。電視服務網路204可根據一或多個電信協定之一組合來操作。電信協定可包含專屬態樣及/或可包含標準化電信協定。標準化電信協定之實例包含DVB標準、ATSC標準、ISDB標準、DTMB標準、DMB標準、纜上資料服務介面規格(DOCSIS)標準、HbbTV標準、W3C標準及UPnP標準。 再次參考圖2，電視服務提供者網站206可經組態以經由電視服務網路204分配電視服務。舉例而言，電視服務提供者網站206可包含一或多個廣播電台、一MVPD，諸如(舉例而言)一有線電視提供者或一衛星電視提供者或一基於網際網路之電視提供者。在圖2中所圖解說明之實例中，電視服務提供者網站206包含服務分配引擎208、內容資料庫210A及緊急警示資料庫210B。服務分配引擎208可經組態以接收包含(舉例而言)多媒體內容、互動式應用程式及訊息(包含緊急警示及/或緊急警示訊息)之資料，且透過電視服務網路204將資料分配至接收器裝置202A至202N。舉例而言，服務分配引擎208可經組態以根據上文所闡述之傳輸標準中之一或多者之態樣(例如，一ATSC標準)傳輸電視服務。在一項實例中，服務分配引擎208可經組態以透過一或多個源接收資料。舉例而言，電視服務提供者網站206可經組態以透過一衛星上行鏈路/下行鏈路或透過一直接傳輸自一地區或國家廣播網路(例如，NBC、ABC等)接收包含電視節目之一傳輸。進一步地，如圖2中所圖解說明，電視服務提供者網站206可與廣域網路212通信且可經組態以自內容提供者網站214接收多媒體內容及資料。應注意，在某些實例中，電視服務提供者網站206可包含一電視演播室且內容可源自其。 內容資料庫210A及緊急警示資料庫210B可包含經組態以儲存資料之儲存裝置。舉例而言，內容資料庫210A可儲存多媒體內容及與其相關聯之資料，包含(舉例而言)描述性資料及可執行互動式應用程式。舉例而言，一體育賽事可與提供統計更新之一互動式應用程式相關聯。緊急警示資料庫210B可儲存與緊急警示相關聯之資料，包含(舉例而言)緊急警示訊息。資料可根據一經定義資料格式(諸如，舉例而言，HTML、動態HTML、XML及JavaScript物件記法(JSON))來格式化，且可包含使得接收器裝置202A至202N能夠(例如)自緊急警示資料提供者網站218中之一者存取資料之URL及URI。在某些實例中，電視服務提供者網站206可經組態以提供對所儲存多媒體內容之存取且透過電視服務網路204將多媒體內容分配至接收器裝置202A至202N中之一或多者。舉例而言，儲存於內容資料庫210A中之多媒體內容(例如，音樂、電影及電視(TV)表演)可在一所謂的按需基礎上經由電視服務網路204提供給一使用者。 廣域網路212可包含一基於封包之網路且根據一或多個電信協定之一組合來操作。電信協定可包含專屬態樣及/或可包含標準化電信協定。標準化電信協定之實例包含全球行動通信系統(GSM)標準、碼分多重存取(CDMA)標準、第三代合作夥伴計劃(3GPP)標準、歐洲電信標準協會(ETSI)標準、歐洲標準(EN)、IP標準、無線應用協定(WAP)標準及電機電子工程師學會(IEEE)標準，諸如(舉例而言) IEEE 802標準(例如，Wi-Fi)中之一或多者。廣域網路212可包括無線及/或有線通信媒體之任何組合。廣域網路212可包含同軸電纜、光纖電纜、雙絞線電纜、乙太網路電纜、無線傳輸器及接收器、路由器、交換機、中繼器、基地台或可用於促進各種裝置及網站之間的通信之任何其他設備。在一項實例中，廣域網路212可包含網際網路。 再次參考圖2，內容提供者網站214表示可將多媒體內容提供至電視服務提供者網站206及/或在某些情形中提供至接收器裝置202A至202N之網站之實例。舉例而言，一內容提供者網站可包含具有經組態以將多媒體檔案及/或內容饋送提供至電視服務提供者網站206之一或多個演播室內容伺服器之一演播室。在一項實例中，內容提供者網站214可經組態以使用IP套組提供多媒體內容。舉例而言，一內容提供者網站可經組態以根據即時串流協定(RTSP)、超文本傳遞協定(HTTP)或諸如此類將多媒體內容提供至一接收器裝置。 緊急權威機構網站216表示可將緊急警示提供至電視服務提供者網站206之網站之實例。舉例而言，如上文所闡述，緊急權威機構可包含美國國家氣象局、美國國土安全部、本機及區域機關及諸如此類。一緊急權威機構網站可係與電視服務提供者網站206通信(直接或透過廣域網路212)之一緊急權威機構之一實體位置。一緊急權威機構網站可包含經組態以將緊急警示提供至電視服務提供者網站206之一或多個伺服器。如上文所闡述，一服務提供者(例如，電視服務提供者網站206)可接收一緊急警示且產生一緊急警示訊息以用於分配至一接收器裝置，例如，接收器裝置202A至202N。應注意，在某些情形中，一緊急警示及一緊急警示訊息可係類似的。舉例而言，電視服務提供者網站206可將自緊急權威機構網站216接收之一XML片段作為一緊急警示訊息之部分傳遞至接收器裝置202A至202N。電視服務提供者網站206可根據一經定義資料格式(諸如，舉例而言，HTML、動態HTML、XML及JSON)產生一緊急警示訊息。 如上文所闡述，一緊急警示訊息可包含識別可在何處獲得與緊急情況相關之額外資訊之URL。緊急警示資料提供者網站218表示經組態以透過廣域網路212將緊急警示資料(包含基於超文本之內容、XML片段及諸如此類)提供至接收器裝置202A至202N中之一或多者及/或(在某些實例中)電視服務提供者網站206之網站之實例。緊急警示資料提供者網站218可包含一或多個網頁伺服器。應注意，由緊急警示資料提供者網站218提供之資料可包含音訊及視訊內容。 如上文所闡述，服務分配引擎208可經組態以接收包含(舉例而言)多媒體內容、互動式應用程式及訊息之資料，且透過電視服務網路204將資料分配至接收器裝置202A至202N。因此，在一個實例性情境中，電視服務提供者網站206可自緊急權威機構網站216接收一緊急警示(例如，恐怖主義警告)。服務分配引擎208可基於緊急警示而產生一緊急警示訊息(例如，一螢幕上「恐怖主義警告」捲動文本)，致使緊急訊息直接整合至自一(若干)內容提供者網站214接收之內容中，且產生包含具有經整合緊急警示訊息之內容之一信號。舉例而言，服務分配引擎208可將一緊急警示訊息預燒至自一網路聯合者接收之電視節目中(例如，一螢幕上緊急警示訊息)且產生包含緊急警示訊息及電視節目之一信號以用於由接收器裝置202A至202N接收。 圖3係圖解說明可實施本發明之一或多種技術之一服務分配引擎之一實例之一方塊圖。服務分配引擎300可經組態以接收資料且輸出表示彼資料之一信號以用於經由一通信網路(例如，電視服務網路204)分配。舉例而言，服務分配引擎300可經組態以接收一或多個資料集合且輸出可使用一單個射頻頻帶(例如，一6 MHz頻道、一8 MHz頻道等)或一經接合頻道(例如，兩個單獨6 MHz頻道)傳輸之一信號。 如圖3中所圖解說明，服務分配引擎300包含分量囊封器302、傳送與網路封包產生器304、連結層封包產生器306、訊框建立器與波形產生器308及系統記憶體310。分量囊封器302、傳送與網路封包產生器304、連結層封包產生器306、訊框建立器與波形產生器308及系統記憶體310中之每一者可互連(實體地、通信地及/或操作地)以用於組件間通信且可實施為各種適合電路中之任一者，諸如一或多個微處理器、數位信號處理器(DSP)、特殊應用積體電路(ASIC)、場可程式化閘陣列(FPGA)、離散邏輯、軟體、硬體、韌體或其任何組合。應注意，儘管服務分配引擎300經圖解說明為具有不同功能區塊，但此一圖解說明係出於闡述性目的且不將服務分配引擎300限制於一特定硬體架構。可使用硬體、韌體及/或軟體實施方案之任一組合實現服務分配引擎300之功能。 可將系統記憶體310闡述為一非暫時性或有形電腦可讀儲存媒體。在某些實例中，系統記憶體310可提供暫時及/或長期儲存。在某些實例中，可將系統記憶體310或其部分闡述為非揮發性記憶體且在其他實例中可將系統記憶體310之部分闡述為揮發性記憶體。揮發性記憶體之實例包含隨機存取記憶體(RAM)、動態隨機存取記憶體(DRAM)及靜態隨機存取記憶體(SRAM)。非揮發性記憶體之實例包含磁性硬碟、光碟、軟碟、快閃記憶體或電可程式化記憶體(EPROM)或電可抹除且可程式化(EEPROM)記憶體形式。系統記憶體310可經組態以儲存可由服務分配引擎300在操作期間使用之資訊。應注意，系統記憶體310可包含包含於分量囊封器302、傳送/網路封包產生器304、連結層封包產生器306及訊框建立器與波形產生器308中之每一者內之個別記憶體元件。舉例而言，系統記憶體310可包含經組態以儲存資料以用於由服務分配引擎300之一組件處理之一或多個緩衝器(例如，先進先出(FIFO)緩衝器)。 分量囊封器302可經組態以接收一服務之一或多個分量且根據一經定義資料結構囊封該一或多個分量。舉例而言，分量囊封器302可經組態以接收一或多個媒體分量且基於MMTP而產生一封裝。進一步地，分量囊封器302可經組態以接收一或多個媒體分量且基於HTTP動態自適應串流(DASH)而產生媒體呈現。進一步地，分量囊封器302可經組態以接收一緊急警示之一視訊分量且將一緊急警示訊息直接整合至該視訊分量中。在一項實例中，分量囊封器302可藉由使用視訊編輯技術(例如，文本疊加視訊編輯技術)而將一緊急警示訊息直接整合至一視訊分量中。進一步地，應注意，在某些實例中，分量囊封器302可藉由將資料整合至經編碼視訊資料中而將一緊急警示訊息直接整合至一視訊分量中。舉例而言，在其中使用HEVC編碼視訊資料之情形中，分量囊封器302可藉由用包含一緊急警示訊息之一或多個圖塊或影像塊替換一或多個圖塊或影像塊(例如，對應於一圖片或訊框之底部之一圖塊)而將一緊急警示訊息直接整合至一視訊分量中。應注意，在此情形中，確保所替換圖塊及/或影像塊不用作經編碼視訊資料之其他部分之一參考(例如，用於對後續訊框之運動補償)可係必要的。應注意，可使用在HEVC中提供之一或多個訊息(例如，一補充增強資訊(SEI)訊息)傳訊關於圖塊及/或影像塊是否用作經編碼視訊資料之其他部分之一參考之資訊。以此方式，分量囊封器302可經組態以包含在經編碼視訊資料之一訊框中之一爬行而不完全解碼經編碼視訊資料。因此，本文中所闡述之技術可一般適用於一緊急警示訊息併入至一視訊呈現中。應注意，在某些實例中，分量囊封器302可經組態以產生服務層傳訊資料。 傳送與網路封包產生器304可經組態以接收一傳送封裝且將該傳送封裝囊封至對應傳送層封包(例如，UDP、傳送控制協定(TCP)等)及網路層封包(例如，IPv4、IPv6、經壓縮IP封包等)中。在一項實例中，傳送與網路封包產生器304可經組態以產生具有專用於傳訊功能之一位址/埠之在IP封包之有效負載中攜載之傳訊資訊。亦即，舉例而言，傳送與網路封包產生器304可經組態以根據本發明之一或多種技術產生LLS表。 連結層封包產生器306可經組態以接收網路封包且根據一經定義連結層封包結構(例如，一ATSC 3.0連結層封包結構)產生封包。訊框建立器與波形產生器308可經組態以接收一或多個連結層封包且輸出配置於一訊框結構中之符號(例如，OFDM符號)。如上文所闡述，一訊框可包含一或多個PLP，可稱為一實體層訊框(PHY層訊框)。如上文所闡述，一訊框結構可包含一啟動程式、一前文及一資料有效負載，從而包含一或多個PLP。一啟動程式可充當一波形之一通用進入點。一前文可包含所謂的層1傳訊(L1傳訊)。L1傳訊可提供必要資訊以組態實體層參數。訊框建立器與波形產生器308可經組態以產生用於在RF頻道類型中之一或多者內傳輸之一信號：一單個6 MHz頻道、一單個7 MHz頻道、單個8 MHz頻道、一單個11 MHz頻道及包含任何兩個或兩個以上單獨單一頻道之經接合頻道(例如，包含一6 MHz 頻道及一8 MHz頻道之一14 MHz頻道)。訊框建立器與波形產生器308可經組態以插入引示及保留音調以用於頻道估計及/或同步。在一項實例中，可根據一正交分頻多工(OFDM)符號及副載波頻率映射定義引示及保留音調。訊框建立器與波形產生器308可經組態以藉由將OFDM符號映射至副載波而產生一OFDM波形。應注意，在某些實例中，訊框建立器與波形產生器308可經組態以支援層分多工。層分多工可係指在同一RF頻道(例如，一6 MHz頻道)上疊置多個資料層。通常，一上部層係指支援一主要服務之一核心(例如，最穩健)層且一下部層係指支援經增強服務之一高資料速率層。舉例而言，一上部層可支援基本高清晰度視訊內容且一下部層可支援經增強超高清晰度視訊內容。 如上文所闡述，傳送與網路封包產生器304可經組態以根據本發明之一或多種技術產生LLS表。應注意，在某些實例中，根據本文中所闡述之技術，一服務分配引擎(例如，服務分配引擎208或服務分配引擎300)或其特定組件可經組態以產生傳訊訊息。如此，對關於傳送與網路封包產生器304之傳訊訊息(包含資料片段)之說明不應被解釋為限制本文中所闡述之技術。如上文所闡述，暫時中止應用程式及/或改變再現一多媒體呈現之方式以便增加一使用者知曉緊急警示訊息之可能性對於一接收器裝置可係有用及/或必要的。如上文所闡述，用於傳訊與緊急警示訊息相關聯之資訊之當前所提議技術對於使得一接收器裝置能夠回應於一緊急警示訊息而暫時中止應用程式及/或改變再現一多媒體呈現之方式可能不太理想。特定而言，將一布林旗標嵌入於CAP XML片段中以便指示一緊急警示訊息直接整合至多媒體內容中可能不太理想。舉例而言，關於當前所提議技術，一旦布林旗標設定為真，便需要一第二CAP XML片段將旗標設定為假以「關斷」緊急警示訊息通知。此可係有問題的，此乃因一不良接收區中之一接收器裝置可不能夠以一合理確定度接收一後續CAP XML片段。不接收將旗標設定為假之第二訊息CAP XML之一接收器裝置可「卡」在指示一緊急警示訊息直接整合至多媒體內容中之一狀態中且如此可繼續不必要地中止一應用程式或再現一多媒體呈現以便增加一使用者知曉緊急警示訊息之可能性。 傳送與網路封包產生器304可經組態以將一緊急警示訊息以一有效且高效方式直接整合至多媒體內容中傳訊至接收器裝置。在一項實例中，傳送與網路封包產生器304可經組態以基於表4A中所提供之實例性語法而產生一LLS表。在表4A中所圖解說明之實例中，一單獨項目EmergencyOnscreenNotification包含於一LLS表中。 表4A 在表4A中所圖解說明之實例中，LLS_table_id、provider_id、LLS_table_version、SLT、RRT、SystemTime及CAP中之每一者可基於上文關於表2所提供之語義學。然而，應注意，在某些實例中，CAP可基於下文所闡述之實例。另外，在一項實例中，語法元素EmergencyOnscreenNotification可包含以gzip壓縮之一XML格式緊急螢幕上通知。 如上文所闡述，本文中所闡述之技術可一般適用於一服務提供者整合至一多媒體呈現中之任何類型之訊息收發。在一項實例中，傳送與網路封包產生器304可經組態以基於表4B中所提供之實例性語法而產生一LLS表。在表4B中所圖解說明之實例中，一單獨項目OnscreenMessageNotification包含於一LLS表中。 表4B 在表4B中所圖解說明之實例中，LLS_table_id、provider_id、LLS_table_version、SLT、RRT、SystemTime及CAP中之每一者可基於上文關於表2所提供之語義學。然而，應注意，在某些實例中，CAP可基於下文所闡述之實例。另外，在一項實例中，語法元素OnscreenMessageNotification可包含以gzip壓縮之一XML格式螢幕上訊息通知。 參考表4A，在一項實例中，EmergencyOnscreenNotification可包含表5中所圖解說明之屬性。應注意，在表5及本文中所包含之其他表中，資料類型unsignedShort、dateTime及duration可對應於在由全球資訊網聯盟(W3C)維持之XML模式定義(XSD)推薦規範中提供之定義。進一步地，使用可對應於一元素或屬性之基數(亦即，該元素或屬性之出現次數)。 表5 在一項實例中，@bsid、@serviceID、@serviceIDrange、@start及@duration可基於以下語義學： @bsid -規定廣播者串流之識別符 @serviceID -規定在廣播串流之範疇內之一服務之唯一識別符。當不存在@serviceID時，EmergencyOnscreenNotification應用於由@bsid識別之廣播串流中之所有服務。 @serviceIDrange -規定在廣播串流之範疇內之服務範圍。@serviceIDrange可僅在存在@serviceID時存在。當存在@serviceID且不存在@serviceIDrange時，推斷@serviceIDrange具有值0。當存在@serviceIDrange時，EmergencyOnscreenNotification應用於在由@bsid識別之廣播串流中之由範圍介於自@serviceID至@ServiceID+@serviceIDrange內之識別符數字識別之服務。 @start －當存在時，規定螢幕上緊急事件開始時之日期時間資訊。當不存在@start時，推斷@start為當前時間。 @duration -規定以@start或當前時間(若不存在@start)開始之時間持續，螢幕上緊急事件針對該時間持續係有效的。保留值為「PT0」之@duration以傳訊EmergencyOnscreenNotification之取消。 以此方式，屬性@bsid、@serviceID、@serviceIDrange、@start及@duration可由一服務提供者使用以傳訊對應於一緊急警示訊息之緊急螢幕上資訊(例如，預燒爬行文本及/或圖形)之一通知。應注意，傳訊屬性@bsid、@serviceID、@serviceIDrange、@start及@duration可比在一CAP XML片段中傳訊布林旗標更適合於跨越其服務區經受變化程度之信號強度之一地面廣播系統。舉例而言，一接收器裝置可基於持續時間到期之值判定一緊急警示訊息並不在螢幕上且繼續正常操作。進一步地，應注意，傳訊強度跨越一服務區變化之程度在一天氣相關或地質緊急情況期間可係尤其顯著的。 進一步地，應注意，包含一緊急警示訊息直接整合至多媒體內容中的傳訊一廣播串流之識別符及一服務之識別符使得一服務提供者能夠傳訊一逐服務基礎之指示。舉例而言，一廣播者可將兩個視訊串流提供至接收器裝置(例如，使用頻道5-1及頻道5-2)，且在一特定時刻，視訊串流中之僅一者可包含一緊急警示訊息之一預燒。在此情形中，使用表4A及表5中所提供之實例性語法，廣播者可傳訊哪一視訊包含一預燒訊息。進一步地，使用表4A及表5中所提供之實例性語法，可使得一服務提供者能夠在一逐服務基礎上選擇是否應傳訊相對低優先級緊急警示訊息(例如，學校停課)之一通知，且因此可能影響一接收器裝置之操作。進一步地，應注意，在某些實例中，可意欲在多個服務提供者共用相同LLS表時使用@serviceIDrange。在此情形中，可期望每一服務提供者具有係連續且不重疊之服務ID之一範圍。 圖4係圖解說明根據本發明之一或多種技術之根據一模式格式化之一緊急通信訊息之一實例之一電腦程式列表。在圖4中所圖解說明之實例中，實例性XML模式基於表4A及表5中所圖解說明之實例。圖5係圖解說明根據本發明之一或多種技術之根據一模式格式化之緊急通信訊息之一實例之一電腦程式列表。在圖5中所圖解說明之實例中，提供基於表4A及表5中所圖解說明之模式之訊息之實例。特定而言，在圖5中所圖解說明之實例中，直接整合至一服務之一媒體分量中之一緊急警示訊息之一第一通知(亦即，EmergencyOnscreenNotification)在2016年4月1日9：12：34.567開始且針對一個服務具有31.234秒之一持續時間，且第二EmergencyOnscreenNotification在2016年4月1日12：34：56.789開始且針對所有服務具有一持續時間45.678秒，且一第三EmergencyOnscreenNotification應用於在當前時間開始具有54.321秒之一持續時間之一服務範圍。 應注意，在其他實例中，EmergencyOnscreenNotification可包含額外屬性及/或元素以及添加屬性及/或元素之任何組合，且上文關於表5所闡述之實例性屬性可包含於一EmergencyOnscreenNotification模式中。在某些實例中，EmergencyOnscreenNotification可包含表6中所圖解說明之EmergencyOnscreenNotification元素。 表6 在一項實例中，如表6中所圖解說明之EmergencyOnscreenNotification元素可基於以下語義學： EmergencyOnscreenNotification元素係用於指示緊急螢幕上通知之真(接通)或假(關斷)狀態之一布林旗標。 在一項實例中，可傳訊EmergencyOnscreenNotification之多個例項。在此一情形中，每一EmergencyOnscreenNotification可包含用於每一例項之一唯一識別符(例如，作為一屬性或元素)。任何後續傳訊(例如，取消一EmergencyOnscreenNotification)可使用唯一識別符來引用EmergencyOnscreenNotification之例項。應注意，在某些實例中，除了上文關於表4A至表6所闡述之技術或作為該等技術之一替代方案，在某些實例中，使用一CAP XML片段傳訊由@bsid、@serviceID、@start及@duration提供之資訊對於一服務提供者可係有用的。舉例而言，如表6中所圖解說明之EmergencyOnscreenNotification可包含於一LLS表中且一廣播串流及若干服務之對應識別符及/或時間及持續時間資訊可包含於一CAP XML片段中。在一項實例中，CAP版本1.2中之參數可用於攜載bsID及serviceID以在一特定廣播串流內傳訊特定服務。圖6圖解說明一電腦程式列表之一實例，該電腦程式列表圖解說明一參數用於指示一廣播串流之一識別符及一或多個服務之若干識別符之情況。應注意，在某些實例中，替代傳訊指示一bsid-serviceID對之一對數字，可傳訊一字元字串(例如，「ALL」)以指示EmergencyOnscreenNotification應用於在與LLS相關聯之廣播串流內之所有服務。 圖8A至圖8D圖解說明其中CAP XML片段之參數用於指示一緊急警示訊息是否直接整合至一服務之多媒體內容中(亦即，是否針對一服務接通預燒)之實例。在圖8A中所圖解說明之實例中，CAP XML片段指示具有bsid 3838之服務0001已接通預燒。在圖8B中所圖解說明之實例中，CAP XML片段指示bsid 3838中之服務0001及服務0002已接通預燒。舉例而言，服務0001可先前已起動預燒，且在服務0002開始預燒時繼續。在圖8C中所圖解說明之實例中，CAP XML片段指示bsid 3838中之服務0001已關斷預燒且bsid 3838中之服務0002已接通預燒。圖8D表示其中兩個服務提供者使用一頻道共用配置提供服務之一說明性實例。在圖8D中所圖解說明之實例中，在bsid 3838中服務提供者A具有服務0001至0004且服務提供者B具有服務0010至0013，且CAP XML片段指示針對服務0001關斷預燒且針對所有服務0011及0013接通預燒。應注意，在某些實例中，替代傳訊BurnInNotification之一接通或關斷值，BurnInNotification之存在可指示一服務包含一緊急螢幕上通知。進一步地，以一類似方式，在一項實例中，其他屬性或元素可指示一緊急螢幕上通知(例如，一服務識別符之存在可指示用於服務之一緊急螢幕上通知)。 在一項實例中，CAP版本1.2可經修改以包含@bsid及@serviceID屬性。在一項實例中，具有@bsid、@serviceID、@duration及視情況@start之一複雜元素@EmergencyOnscreenNotification可經定義以用於一CAP XML片段。應注意，在此情形中，由一布林旗標伺服之接通/關斷狀態暗含在屬性@duration之非零值中。圖9係圖解說明根據一CAP XML模式產生之一訊息之一實例之一電腦程式列表，該訊息包含具有@bsid、@serviceID、@duration及視情況@start之@EmergencyOnscreenNotification。在一項實例中，@EmergencyOnscreenNotification、@bsid、@serviceID、@duration及@start中之每一者可基於以下實例性語義學： EmergencyOnscreenNotification元素含有螢幕上緊急資訊之一廣播者、服務及時序資訊。 @bsid -規定廣播者串流之識別符。 @serviceID -規定在廣播串流之範疇內之一服務之唯一識別符。當不存在@serviceID時，EmergencyOnscreenNotification應用於由@bsid識別之廣播串流中之所有服務。 @serviceIDrange -規定在廣播串流之範疇內之服務範圍。@serviceIDrange可僅在存在@serviceID時存在。當存在@serviceID且不存在@serviceIDrange時，推斷@serviceIDrange具有值0。當存在@serviceIDrange時，EmergencyOnscreenNotification應用於在由@bsid識別之廣播串流中之由範圍介於自@serviceID至@ServiceID+@serviceIDrange內之識別符數字識別之服務。 @start －當存在時，規定螢幕上緊急事件開始時之日期時間資訊。當不存在@start時，推斷@start等於當前時間。在一實例中，當前時間係一接收器接收對應於EmergencyOnscreenNotification之傳訊時之時間。 @duration -規定以@start或當前時間(若不存在@start)開始之時間持續，螢幕上緊急事件針對該時間持續係有效的。在一實例中，保留值為「PT0」之@duration以傳訊EmergencyOnscreenNotification之取消。 圖10係圖解說明根據圖9中所圖解說明之一模式格式化之緊急通信訊息之一實例之一電腦程式列表。在圖10中針對廣播者串流3838中之服務3388至3391所圖解說明之實例中，一緊急螢幕上通知在2016年4月1日12：34：56.7開始且具有一持續時間31.234秒。 在一項實例中，圖11中所圖解說明之模式可用於指示一緊急警示訊息直接整合至服務之多媒體內容中。如圖11中所圖解說明，實例性模式包含係為xs:complexType之一XML元素服務。在一項實例中，服務可具有service@ID之一所需屬性及service@range之一可選屬性。以此方式，圖11中所圖解說明之實例性模式約束service@ID及service@range之使用，此可在某些例項中提供更有效傳訊。以此方式，服務分配引擎208表示根據本發明之一或多種技術之經組態以傳訊與相關聯於一服務之一緊急警示訊息相關聯之資訊之一裝置之一實例。 參考表4B，在一項實例中，OnscreenMessageNotification可包含表7中所圖解說明之元素及屬性。應注意，OnscreenMessageNotification係LLS資訊之例項類型中之一者。如表7中所圖解說明，OnscreenMessageNofication提供用於螢幕上重要文本/視覺資訊之服務資訊，其可包含已由廣播者在其視訊服務上再現之緊急情況相關資訊。應注意，本文中所闡述之技術一般係適用的而不管在一特定實施方案中用於元素及屬性之命名法如何。舉例而言，表7中之KeepScreenClear元素及KSCFlag屬性可使用命名法來關於一接收器裝置視角替代自一發射器(例如，服務提供者)視角表達行為。舉例而言，KeepScreenClear可在某些實例中實施為MessageNotification、OnscreenNotification或MessageStatus或諸如此類，且KSCFlag可實施為MessagePresent、OnScreenPresent、PresentFlag、Status、Flag或諸如此類。 表7 在一項實例中，表7中之OnscreenMessageNotification 、KeepScreenClear、@bsid、@serviceID、@serviceIDrange及@KSCflag可基於以下語義學： OnscreenMessageNotification －根元素含有用於螢幕上重要文本/視覺資訊之廣播者及服務，包含已由廣播者在其視訊服務上再現之緊急情況相關資訊。 KeepScreenClear －與OnscreenMessageNotification相關之服務資訊。 @bsid -整個廣播串流之識別符。bsid之值在一區域層級(舉例而言，北美洲)上應係唯一的。一管理或監管權威機構可起到一作用。 @serviceID -應在此廣播區之範疇內唯一地識別此服務之16位元整數。若不存在，則推斷KeepScreenClear應用於在由@bsid識別之廣播串流內之所有服務。 @serviceIDrange -規定在廣播串流之範疇內之服務範圍。當不存在@serviceID時不應存在@serviceIDrange。當存在@serviceID且不存在@serviceIDrange時，推斷@serviceIDrange具有值0。當存在@serviceIDrange時，KeepScreenClear應用於在由@bsid識別之廣播串流中之由自@serviceID開始至@ServiceID+@serviceIDrange之識別符數字識別之服務。 @KSCflag －指示在所識別廣播串流內之所識別服務之KeepScreenClear之狀態。若不存在，則推斷@KSCflag具有假值。 以此方式，表7中之OnscreenMessageNotification、KeepScreenClear、@bsid、@serviceID、@serviceIDrange及@KSCflag可由一服務提供者使用以傳訊螢幕上資訊(例如，預燒爬行文本及/或圖形)之一通知。應注意，關於@serviceIDrange，在範圍內之服務可並非全部為作用的。應注意，@KSCflag為真可指示一通知當前顯示於一視訊串流中。圖13係圖解說明根據本發明之一或多種技術之根據一模式格式化之一螢幕上通知通信訊息之一實例之一電腦程式列表。在圖13中所圖解說明之實例中，實例性XML模式基於表4B及表7中所圖解說明之實例。應注意，儘管圖13中之實例性所指示XML模式規定一OnscreenMessageNotification元素之規範語法，但表7可用於以一更具說明性方式闡述OnscreenMessageNotification元素之結構。 圖14係圖解說明根據本發明之一或多種技術之根據一模式格式化之螢幕上通知通信訊息之一實例之一電腦程式列表。在圖14中所圖解說明之實例中，實例性訊息基於圖13中所圖解說明之模式。在圖14中所圖解說明之實例中，一第一KeepScreenClear訊息針對廣播串流3838中之所有服務將KSCflag設定為真(例如，指示一螢幕上通知經預燒至與廣播串流3838相關聯之所有服務)，一第二KeepScreenClear訊息針對廣播串流8383中之服務3388將KSCflag設定為假(例如，指示一螢幕上通知未預燒至廣播串流8383中之服務3388)，且一第三KeepScreenClear訊息針對廣播串流3838中之服務3300至3304將KSCflag設定為假(亦即，KSCflag不存在於第三KeepScreenClear訊息中且經推斷為假以用於所識別服務)。應注意，在其中廣播串流3838除服務3300至3304之外亦包含服務3305之實例中，圖14中所圖解說明之實例中之第一KeepScreenClear訊息針對服務3305將KSCflag設定為真且圖14中所圖解說明之實例中之第三訊息KeepScreenClear訊息針對服務3305對KSCflag不具有影響(亦即，其保持為真)。 應注意，關於表7，KeepScreenClear之使用係0..N，因此，一OnscreenMessageNotification之一例項可係如下： ＜OnscreenMessageNotification＞ ＜/OnscreenMessageNotification＞ 且將指示不存在用於服務及廣播串流之任何組合之通知。 應注意，在其他實例中，表7中之@KSCflag可基於以下語義學： @KSCflag －指示在所識別廣播串流內之所識別服務之KeepScreenClear之狀態。若不存在，則推斷@KSCflag具有真值。 在其中推斷@KSCflag具有真值(若不存在)之情形中，一訊息： ＜KeepScreenClear bsid="3838" serviceID ="3300" serviceIDrange ="4" /＞ 針對廣播串流3838中之服務3300至3304將KSCflag設定為真。 在一項實例中，表7中之@KSCflag可基於以下語義學： @KSCflag －指示在所識別廣播串流內之所識別服務之KeepScreenClear之狀態。若不存在，則推斷@KSCflag針對所識別服務具有真值。 在其中推斷@KSCflag針對所識別服務具有真值(若不存在)之情形中，在一項實例中，一訊息： ＜OnscreenMessageNotification ＞ ＜KeepScreenClear bsid="3838" serviceID="3300" /＞ ＜/OnscreenMessageNotification＞ 針對廣播串流3838中之服務3300將KSCflag設定為真且針對廣播串流3838中之所有其他服務將KSCflag設定為假。 在另一實例中，KSCflag之所推斷值可取決於一所識別服務之一KeepScreenClear服務資訊是否存在於一OnscreenMessageNotification中。舉例而言，若一所識別服務之KeepScreenClear服務資訊存在於一OnscreenMessageNotification中，則可推斷KSCflag之值為真，且若一所識別服務之KeepScreenClear服務資訊不存在於該OnScreenMessageNotification中，則可推斷KSCflag之值為假。在此情形中，一訊息： ＜OnscreenMessageNotification＞ ＜KeepScreenClear bsid="3838" serviceID="3300" /＞ ＜/OnscreenMessageNotification＞ 針對廣播串流3838中之服務3300將KSCflag設定為真且針對廣播串流3838中之所有其他服務將KSCflag設定為假。 在一項實例中，表7中之KeepScreenClear、@serviceIDrange及@KSCflag可基於以下實例性語義學： KeepScreenClear －輸送關於保持螢幕清晰狀態之服務資訊。 @serviceIDrange -規定在此通知應用於之廣播串流之範疇內之服務範圍。當不存在@serviceID時不應存在@serviceIDrange。當存在@serviceID且不存在@serviceIDrange時，推斷@serviceIDrange具有值0。KeepScreenClear元素應用於包含在由@bsid識別之廣播串流中之由自@serviceID開始至@serviceID+@serviceIDrange之識別符數字識別之服務。 @KSCflag －指示在所識別廣播串流內之所識別服務之KeepScreenClear元素之狀態。若不存在，則推斷@KSCflag針對所識別服務具有真值且針對未由在母OnScreenMessageNotification元素內側之任一KeepScreenClear元素識別之由@bsid識別之廣播串流之所有服務具有假值。若一OnscreenMessageNotification元素不包含任一KeepScreenClear元素，則推斷@KSCflag針對所有廣播串流之所有服務等於假。 在一項實例中，一版本及/或一識別屬性可存在於KeepScreenClear元素中。一版本或識別屬性可使一版本或識別值與關於一保持螢幕清晰狀態之資訊之一特定例項相關聯。在一項實例中，一接收器裝置可基於一版本及/或識別屬性之值而判定一第一螢幕上事件及第二螢幕上事件等。在一項實例中，一接收器裝置可經組態以接受輸入(例如，透過一介面自一使用者)以基於一版本及/或一識別屬性而更改一KeepScreenClear元素之處理。舉例而言，一接收器裝置可經組態而以不同於與一第二識別值相關聯之一KeepScreenClear元素之一方式處理與一第一識別值相關聯之一KeepScreenClear元素。在一項實例中，一接收器裝置可經組態以接受指示使一接收器裝置忽視與特定識別及/或版本值(例如，5等)相關聯之KeepScreenClear元素之例項之一使用者偏好的輸入。在某些實例中，一接收器裝置忽視與特定識別及/或版本值相關聯之KeepScreenClear元素可導致一接收器裝置不執行該接收器裝置原本在接收一KeepScreenClear元素之一例項之後旋即執行之一或多個功能。 在某些實例中，一屬性可存在於KeepScreenClear元素中以使得一服務提供者能夠指示用於一特定服務之多個通知。舉例而言，一服務提供者可想要指示一颶風警告及一學校停課通知兩者皆直接整合至一視訊分量中。在一項實例中，包含一無符號整數資料類型之一id屬性可存在於KeepScreenClear元素中以指示用於一特定服務之多個通知。在一項實例中，包含一字串資料類型之一id屬性可存在於KeepScreenClear元素中以指示用於一特定服務之多個通知。在此情形中，一訊息： ＜OnscreenMessageNotification＞ ＜KeepScreenClear bsid="3838" serviceID="3300" id="1" id="2"/＞ ＜/OnscreenMessageNotification＞ 或一訊息： ＜OnscreenMessageNotification＞ ＜KeepScreenClear bsid="3838" serviceID="3300" id="hurricane" id="closing"/＞ ＜/OnscreenMessageNotification＞ 針對廣播串流3838中之服務3300將KSCFlag設定為真且指示用於服務3300之多個通知。在一項實例中，一id屬性可用於指示先前整合至一特定服務中之多個通知中之一或多者不再整合至特定服務中。在此情形中，一訊息： ＜OnscreenMessageNotification＞ ＜KeepScreenClear bsid="3838" serviceID="3300" id="2"/＞ ＜/OnscreenMessageNotification＞ 或一訊息： ＜OnscreenMessageNotification＞ ＜KeepScreenClear bsid="3838" serviceID="3300" id="closing"/＞ ＜/OnscreenMessageNotification＞ 可指示颶風警告在上文所闡述之實例中不再直接整合至一視訊分量中。在一項實例中，一接收器裝置可經組態以基於先前整合至一特定服務中之多個通知中之一或多者不再整合至該特定服務中之一判定而再現一螢幕上呈現。 在一項實例中，OnscreenMessageNotification可包含表8A中所圖解說明之元素及屬性。 表8A 在一項實例中，表8中之OnscreenMessageNotification、@bsid、ServiceNotificationInfo、@serviceID、@serviceIDrange、@NotificationStart、@NotificationDuration及@KeepScreenClear可基於以下語義學： OnscreenMessageNotification －根元素含有螢幕上重要文本/視覺資訊之廣播者、服務及時序資訊，包含已由廣播者在其視訊服務上再現之緊急情況相關資訊。 @bsid -整個廣播串流之識別符。bsid之值在一區域層級(舉例而言，北美洲)上應係唯一的。一管理或監督權威機構可起到一作用。 ServiceNotificationInfo －與OnscreenMessageNotification相關之服務資訊。若不存在，則推斷具有值@bsid之bsid中之所有服務具有等於假之@KeepScreenClear之值。 @serviceID -應在此廣播區之範疇內唯一地識別此服務之16位元整數。 @serviceIDrange -規定在廣播串流之範疇內之服務範圍。當不存在@serviceID時不應存在@serviceIDrange。當存在@serviceID且不存在@serviceIDrange時，推斷服務ID範圍具有值0。當存在@serviceIDrange時，通知應用於在由@bsid識別之廣播串流中之由自@serviceID開始至@ServiceID+@serviceIDrange之識別符數字識別之服務。 @NotificationStart －當存在時，規定螢幕上文本/視覺再現事件開始時之日期時間資訊。當不存在@start時，預設開始時間係當前時間。 @NotificationDuration －當存在時，規定以@start或當前時間(若不存在@start)開始之時間持續，螢幕上文本/視覺再現事件針對該時間持續係有效的。保留值為「PT0S」之@duration以傳訊OnscreenMessageNotification之取消。 @KeepScreenClear －當存在時，設定為真之一值指示通知係當前作用的，且當值設定為假時指示通知係當前不作用的。 以此方式，表8A中之OnscreenMessageNotification、@bsid、ServiceNotificationInfo、@serviceID、@serviceIDrange、@NotificationStart、@NotificationDuration及@KeepScreenClear可由一服務提供者使用以傳訊螢幕上資訊之一通知。應注意，在一項實例中，可約束一訊息之一例項以傳訊一@NotificationStart、@NotificationDuration pair或@KeepScreenClear中之一者。圖15係圖解說明根據本發明之一或多種技術之根據一模式格式化之一螢幕上通知通信訊息之一實例之一電腦程式列表。在圖15中所圖解說明之實例中，實例性XML模式基於表4B及表8A中所圖解說明之實例。 在一項實例中，OnscreenMessageNotification可包含表8B中所圖解說明之元素及屬性。 表8B 在一項實例中，表8B中之OnscreenMessageNotification、ServiceNotificationInfo、@bsid、@serviceID、@serviceIDrange、@NotificationDuration及@KeepScreenClear可基於以下語義學： OnscreenMessageNotification －根元素含有螢幕上重要文本/視覺資訊之廣播者、服務及時序資訊，包含已由廣播者在其視訊服務上再現之緊急情況相關資訊。 ServiceNotificationInfo －與OnscreenMessageNotification相關之服務資訊。 @bsid -整個廣播串流之識別符。bsid之值在一區域層級(舉例而言，北美洲)上應係唯一的。一管理或監管權威機構可起到一作用。 @serviceID -應在此廣播區之範疇內唯一地識別此服務之16位元整數。 @serviceIDrange -規定在廣播串流之範疇內之服務範圍。當不存在@serviceID時不應存在@serviceIDrange。當存在@serviceID且不存在@serviceIDrange時，推斷服務ID範圍具有值0。當存在@serviceIDrange時，通知應用於在由@bsid識別之廣播串流中之由自@serviceID開始至@ServiceID+@serviceIDrange之識別符數字識別之服務。 @NotificationDuration －此值應係在所識別廣播串流內之所識別服務之ServiceNotificationInfo元素之持續時間。出於計數之目的，時間以OnscreenMessageNotification之當前時間開始。在一實例中，當前時間係一接收器接收對應於OnscreenMessageNotification之傳訊時之時間(亦即，接收時間)。在一項實例中，一接收器裝置可將接收傳訊定義為偵測、解碼及/或剖析中之一或多者。若不存在，則@NotificationDuration應設定為一預設值(例如，「PT1M」，亦即，一分鐘)。在一項實例中，大於一特定值之一持續時間可由該特定值指示。舉例而言，在一項實例中，大於1小時之一@NotificationDuration值應設定為「PT1H」，亦即，1小時。0或更小之一@NotificationDuration值應被視為無效的。在所識別廣播串流內之所識別服務之@KeepScreenClear應由一接收器裝置在當前時間達到或超過(OnscreenMessageNotification reception time + @NotificationDuration)時設定為假。 @KeepScreenClear －當存在時，設定為真之一值指示通知係當前作用的，且當值設定為假時，指示通知係當前非作用的。 圖12係圖解說明可實施本發明之一或多種技術之一接收器裝置之一實例之一方塊圖。亦即，接收器裝置400可經組態以基於上文關於上文所闡述之表中之一或多者所闡述之語義學而剖析一信號。進一步地，接收器裝置400可經組態以確保包含(舉例而言)直接整合至一多媒體內容之呈現中之一緊急警示訊息之一螢幕上訊息回應於基於上文所闡述之語義學之一信號而對於一使用者係明顯的。舉例而言，一接收器裝置可經組態以暫時中止應用程式及/或改變再現一多媒體呈現之方式(例如，針對一或多個服務之一規定持續時間)以便增加一使用者知曉包含(舉例而言)一緊急警示訊息之螢幕上訊息之可能性。進一步地，在一項實例中，接收器裝置400可經組態以使得一使用者能夠設定包含(舉例而言)緊急訊息通知之螢幕上訊息如何由接收器裝置400處置。舉例而言，一使用者可在一設定選單中設定以下偏好中之一者：對應於總是被警示之一偏好、對應於警示一使用者之一頻率(例如，每五分鐘僅警示一次)之一偏好、對應於從不被警示之一偏好。在其中一設定對應於警示一使用者且接收一緊急警示訊息通知(例如，一EmergencyOnscreenNotification)之情形中，接收器裝置400可判定EmergencyOnscreenNotification是否對應於當前再現之服務。舉例而言，接收器裝置400可判定EmergencyOnscreenNotification中之一serviceID是否匹配當前顯示之一服務。進一步地，接收器裝置400可判定一當前時間是否等於或大於一@start值且小於@start與@duration之總和之一值。若當前時間在@start及@start與@duration之總和之範圍內，則接收器裝置400可最小化(及/或「取下」)當前顯示之圖形疊加。在某些情形中，取決於實施方案，可藉由將一圖形平面之透明度設定為全透明來完成此。以此方式，接收器裝置400可致使EmergencyOnscreenNotification中之具有serviceID之一服務在具有最少或不具有阻礙一緊急警示訊息之圖形疊加之情況下在一全螢幕視圖中再現。當當前時間變得大於@start與@duration之總和時，接收器裝置400可使此圖形平面恢復至其先前狀態。 在一項實例中，接收器裝置400可經組態以基於上文所闡述之實例性語義學之任何組合而接收OnScreenNotification訊息，剖析其，且然後採取一行動。舉例而言，接收器裝置400可接收一OnScreenNotification訊息，且若該訊息指示用於存取(例如，顯示)一服務之一KSCFlag之一真值，則接收器裝置400可致使任何疊加或應用程式停止顯示。在某些例項中，接收器裝置可執行必要比例縮放功能以達成用於顯示一視訊之完全可見性。進一步地，在一項實例中，接收器裝置400可接收一OnScreenNotification訊息，且若該訊息指示用於存取(例如，顯示)一服務之一KSCFlag之一假值，則接收器裝置400可致使任何疊加或應用程式經顯示(例如，繼續一應用程式之顯示)。 接收器裝置400係可經組態以經由一或多個類型之資料通道自一通信網路接收資料且允許一使用者存取多媒體內容之一運算裝置之一實例。在圖12中所圖解說明之實例中，接收器裝置400經組態以經由諸如(舉例而言)上文所闡述之電視服務網路204之一電視網路接收資料。進一步地，在圖12中所圖解說明之實例中，接收器裝置400經組態以經由一廣域網路發送且接收資料。應注意，在其他實例中，接收器裝置400可經組態以僅僅透過一電視服務網路204接收資料。本文中所闡述之技術可由經組態以使用通信網路之任何及所有組合通信之裝置利用。 如圖12中所圖解說明，接收器裝置400包含中央處理單元402、系統記憶體404、系統介面410、資料提取器412、音訊解碼器414、音訊輸出系統416、視訊解碼器418、顯示系統420、I/O裝置422及網路介面424。如圖12中所圖解說明，系統記憶體404包含作業系統406、應用程式408及文件剖析器409。中央處理單元402、系統記憶體404、系統介面410、資料提取器412、音訊解碼器414、音訊輸出系統416、視訊解碼器418、顯示系統420、I/O裝置422及網路介面424中之每一者可互連(實體地、通信地及/或操作地)以用於組件間通信且可實施為各種適合電路中之任一者，諸如一或多個微處理器、數位信號處理器(DSP)、特殊應用積體電路(ASIC)、場可程式化閘陣列(FPGA)、離散邏輯、軟體、硬體、韌體或其任何組合。應注意，儘管接收器裝置400經圖解說明為具有不同功能區塊，但此一圖解說明係出於闡述性目的且不將接收器裝置400限制於一特定硬體架構。可使用硬體、韌體及/或軟體實施方案之任一組合實現接收器裝置400之功能。 CPU 402可經組態以實施用於在接收器裝置400中執行之功能性及/或程式指令。CPU 402可包含單核心及/或多核心中央處理單元。CPU 402可能夠擷取且處理指令、碼及/或資料結構以用於實施本文中所闡述之技術中之一或多者。指令可儲存於諸如系統記憶體404之一電腦可讀媒體上。 可將系統記憶體404闡述為一非暫時性或有形電腦可讀儲存媒體。在某些實例中，系統記憶體404可提供暫時及/或長期儲存。在某些實例中，可將系統記憶體404或其部分闡述為非揮發性記憶體且在其他實例中可將系統記憶體404之部分闡述為揮發性記憶體。系統記憶體404可經組態以儲存可由接收器裝置400在操作期間使用之資訊。系統記憶體404可用於儲存程式指令以用於由CPU 402執行且可由在接收器裝置400上運行之程式使用以在程式執行期間暫時儲存資訊。進一步地，在其中接收器裝置400經包含為一數位視訊記錄器之部分之實例中，系統記憶體404可經組態以儲存眾多視訊檔案。 應用程式408可包含在接收器裝置400內實施或由接收器裝置400執行之應用程式且可實施或含納於接收器裝置400之組件內，可由該等組件操作、由該等組件執行及/或操作地/通信地耦合至該等組件。應用程式408可包含可致使接收器裝置400之CPU 402執行特定功能之指令。應用程式408可包含電腦程式化敍述(諸如，for循環、while循環、if敍述、do循環等)中表達之演算法。可使用一規定程式化語言發展應用程式408。程式化語言之實例包含JavaTM 、JiniTM 、C、C++、Objective C、Swift、Perl、Python、PhP、UNIX Shell、Visual Basic及Visual Basic Script。在其中接收器裝置400包含一智慧型電視之實例中，可由一電視製造商或一廣播者發展應用程式。如圖12中所圖解說明，應用程式408可連同作業系統406執行。亦即，作業系統406可經組態以促進應用程式408與CPU 402及接收器裝置400之其他硬體組件之交互作用。作業系統406可係經設計以安裝於機上盒、數位視訊記錄器、電視及諸如此類上之一作業系統。應注意，本文中所闡述之技術可由經組態以使用軟體架構之任何及所有組合操作之裝置利用。 如上文所闡述，一應用程式可係構成一經增強或互動式服務之一文件集合。進一步地，文件可用於根據一協定闡述一緊急警示或諸如此類。文件剖析器409可經組態以剖析一文件且致使一對應功能出現在接收器裝置400處。舉例而言，文件剖析器409可經組態以剖析來自一文件之一URL且接收器裝置400可擷取對應於該URL之資料。 系統介面410可經組態以達成接收器裝置400之組件之間的通信。在一項實例中，系統介面410包括使得資料能夠自一個同級裝置傳遞至另一同級裝置或傳遞至一儲存媒體之結構。舉例而言，系統介面410可包含支援基於加速圖形埠(AGP)之協定、基於周邊組件互連(PCI)匯流排之協定(諸如(舉例而言)由周邊組件互連特別興趣群維持之PCI ExpressTM (PCIe)匯流排規格)或可用於使同級裝置互連之任何其他形式之結構(例如，專屬匯流排協定)的一晶片集。 如上文所闡述，接收器裝置400經組態以經由一電視服務網路接收且視情況發送資料。如上文所闡述，一電視服務網路可根據一電信標準來操作。一電信標準可定義通信性質(例如，協定層)，諸如(舉例而言)實體傳訊、定址、頻道存取控制、封包性質及資料處理。在圖12中所圖解說明之實例中，資料提取器412可經組態以自一信號提取視訊、音訊及資料。可根據(舉例而言) DVB標準、ATSC標準、ISDB標準、DTMB標準、DMB標準及DOCSIS標準之態樣定義一信號。資料提取器412可經組態以自由上文所闡述之服務分配引擎300產生之一信號提取視訊、音訊及資料。亦即，資料提取器412可以與服務分配引擎300交互之一方式操作。 資料封包可由CPU 402、音訊解碼器414及視訊解碼器418處理。音訊解碼器414可經組態以接收且處理音訊封包。舉例而言，音訊解碼器414可包含經組態以實施一音訊編解碼器之態樣之硬體與軟體之一組合。亦即，音訊解碼器414可經組態以接收音訊封包且將音訊資料提供至音訊輸出系統416以用於再現。可使用多頻道格式(諸如由杜比與數位影院系統發展之彼等)編碼音訊資料。可使用一音訊壓縮格式編碼音訊資料。音訊壓縮格式之實例包含動畫專家群(MPEG)格式、進階音訊編碼(AAC)格式、DTS-HD格式及杜比數位(AC-3、AC-4等)格式。音訊輸出系統416可經組態以再現音訊資料。舉例而言，音訊輸出系統416可包含一音訊處理器、一數位轉類比轉換器、一放大器及一揚聲器系統。一揚聲器系統可包含各種揚聲器系統中之任一者，諸如頭戴耳機、一整合式立體揚聲器系統、一多揚聲器系統或一環繞聲系統。 視訊解碼器418可經組態以接收且處理視訊封包。舉例而言，視訊解碼器418可包含用於實施一視訊編解碼器之態樣之硬體與軟體之一組合。在一項實例中，視訊解碼器418可經組態以解碼根據任何數目個視訊壓縮標準(諸如ITU-T H.262或ISO/IEC MPEG-2 Visual、ISO/IEC MPEG-4 Visual、ITU-T H.264 (亦稱為ISO/IEC MPEG-4進階視訊編碼(AVC))及高效率視訊編碼(HEVC))編碼之視訊資料。顯示系統420可經組態以擷取且處理視訊資料以用於顯示。舉例而言，顯示系統420可自視訊解碼器418接收像素資料且輸出資料以用於視覺呈現。進一步地，顯示系統420可經組態以連同視訊資料輸出圖形，例如，圖形使用者介面。顯示系統420可包括各種顯示裝置中之一者，諸如一液晶顯示器(LCD)、一電漿顯示器、一有機發光二極體(OLED)顯示器或能夠將視訊資料再現給一使用者之另一類型之顯示裝置。一顯示裝置可經組態以顯示標準清晰度內容、高清晰度內容或超高清晰度內容。 I/O裝置422可經組態以在接收器裝置400之操作期間接收輸入且提供輸出。亦即，I/O裝置422可使得一使用者能夠選擇將再現之多媒體內容。輸入可產生自諸如(舉例而言)一按鈕遠端控制之一輸入裝置、包含一觸敏螢幕之一裝置、一基於運動之輸入裝置、一基於音訊之輸入裝置或經組態以接收使用者輸入之任何其他類型之裝置。I/O裝置422可使用一標準化通信協定(諸如，舉例而言，通用串列匯流排協定(USB)、藍芽、ZigBee)或一專屬通信協定(諸如，舉例而言，一專屬紅外線通信協定)操作地耦合至接收器裝置400。 網路介面424可經組態以使得接收器裝置400能夠經由一區域網路及/或一廣域網路發送且接收資料。網路介面424可包含一網路介面卡，諸如一乙太網路卡、一光學收發器、一射頻收發器或經組態以發送且接收資訊之任何其他類型之裝置。網路介面424可經組態以根據在一網路中利用之實體及媒體存取控制(MAC)層執行實體傳訊、定址及頻道存取控制。接收器裝置400可經組態以剖析根據上文關於圖12所闡述之技術中之任一者產生之一信號。以此方式，接收器裝置400表示經組態以回應於包含(舉例而言)緊急警示訊息通知之一螢幕上訊息而修改一服務之呈現之一裝置之一實例。 在一或多項實例中，可以硬體、軟體、韌體或其任何組合來實施所闡述之功能。若以軟體實施，則該等功能可儲存於一電腦可讀媒體上或作為該電腦可讀媒體上之一或多個指令或碼進行傳輸且由一基於硬體之處理單元執行。電腦可讀媒體可包含電腦可讀儲存媒體(其對應於諸如資料儲存媒體之一有形媒體)或通信媒體(包含促進一電腦程式(例如)根據一通信協定自一個地方傳遞至另一地方之任何媒體)。以此方式，電腦可讀媒體一般可對應於(1)有形電腦可讀儲存媒體，其係非暫時的或(2)一通信媒體，諸如一信號或載波。資料儲存媒體可係可由一或多個電腦或一或多個處理器存取以擷取指令、碼及/或資料結構以用於實施本發明中所闡述之技術之任何可用媒體。一電腦程式產品可包含一電腦可讀媒體。 藉由實例而非限制之方式，此電腦可讀儲存媒體可包括RAM、ROM、EEPROM、CD-ROM或其他光碟儲存裝置、磁碟儲存裝置或其他磁性儲存裝置、快閃記憶體或者可用於以指令或資料結構之形式儲存所要程式碼且可由一電腦存取之任何其他媒體。此外，可將任何連接適當地稱為一電腦可讀媒體。舉例而言，若使用一同軸電纜、光纖電纜、雙絞線、數位用戶線路(DSL)或諸如紅外線、無線電及微波等無線技術自一網站、伺服器或其他遠端源傳輸指令，則該同軸電纜、光纖電纜、雙絞線、DSL或例如紅外線、無線電及微波等無線技術皆包含於媒體之定義中。然而，應理解，電腦可讀儲存媒體及資料儲存媒體不包含連接、載波、信號或其他暫時媒體，而是替代地針對於非暫時有形儲存媒體。如本文中所使用，磁碟及碟片包含：壓縮碟片(CD)、雷射碟片、光碟、數位通用碟片(DVD)、軟碟及藍光碟片，其中磁碟通常以磁性方式複製資料，而碟片藉助雷射以光學方式複製資料。上述之組合亦應包含於電腦可讀媒體之範疇內。 指令可由一或多個處理器執行，諸如一或多個數位信號處理器(DSP)、一般用途微處理器、特殊應用積體電路(ASIC)、場可程式化邏輯陣列(FPGA)或其他等效積體或離散邏輯電路。因此，如本文中所使用之術語「處理器」可係指前述結構中之任一者或適合用於實施本文中所闡述之技術之任何其他結構。另外，在某些態樣中，本文中所闡述之功能性可提供於經組態以用於編碼及解碼之專用硬體及/或軟體模組內，或併入於一經組合編解碼器中。而且，該等技術可完全實施於一或多個電路或邏輯元件中。 可在各種各樣裝置或設備(包含一無線手持話機、一積體電路(IC)或一組IC (例如，一晶片集))中實施本發明之技術。在本發明中闡述各種組件、模組或單元以強調經組態以執行所揭示技術之裝置之功能態樣，但未必需要藉由不同硬體單元來實現。更確切而言，如上文所闡述，各種單元可組合於一編解碼器硬體單元中或由一互操作硬體單元集合(包含如上文所闡述之一或多個處理器)連同適合軟體及/或韌體提供。 此外，可由一電路實施或執行前述實施例中之每一者中所使用之基地台裝置及終端裝置(視訊解碼器及視訊編碼器)之每一功能區塊或各種特徵，該電路通常係一積體電路或複數個積體電路。經設計以執行本說明書中所闡述之功能之電路可包括一一般用途處理器、一數位信號處理器(DSP)、一特殊應用或一般應用積體電路(ASIC)、一場可程式化閘陣列(FPGA)或其他可程式化邏輯裝置、離散閘極或電晶體邏輯或一離散硬體組件或其一組合。該一般用途處理器可係一微處理器，或另一選擇係，該處理器可係一習用處理器、一控制器、一微控制器或一狀態機。該一般用途處理器或上文所闡述之每一電路可由一數位電路組態或可由一類比電路組態。進一步地，當製成取代目前時間之積體電路之一積體電路之一技術由於一半導體技術之進展而出現時，亦能夠使用藉由此技術而成之積體電路。 已闡述各種實例。此等及其他實例在以下申請專利範圍之範疇內。
100‧‧‧內容遞送協定模型
200‧‧‧系統
202A-202N‧‧‧接收器裝置
204‧‧‧電視服務網站
206‧‧‧電視服務提供者網站
208‧‧‧服務分配引擎
210A‧‧‧內容資料庫
210B‧‧‧緊急警示資料庫
212‧‧‧廣域網路
214‧‧‧內容提供者網站
216‧‧‧緊急權威機構網站
218‧‧‧緊急警示資料提供者網站
300‧‧‧服務分配引擎
302‧‧‧分量囊封器
304‧‧‧傳送與網路封包產生器/網路封包產生器
306‧‧‧連結層封包產生器
308‧‧‧訊框建立器與波形產生器
310‧‧‧系統記憶體
400‧‧‧接收器裝置
402‧‧‧中央處理單元
404‧‧‧系統記憶體
406‧‧‧作業系統
408‧‧‧應用程式
409‧‧‧文件剖析器
410‧‧‧系統介面
412‧‧‧資料提取器
414‧‧‧音訊解碼器
416‧‧‧音訊輸出系統
418‧‧‧視訊解碼器
420‧‧‧顯示系統
422‧‧‧輸入/輸出裝置
424‧‧‧網路介面
[圖1] 圖1係圖解說明根據本發明之一或多種技術之內容遞送協定模型之一實例之一概念圖。 [圖2] 圖2係圖解說明可實施本發明之一或多種技術之一系統之一實例之一方塊圖。 [圖3] 圖3係圖解說明可實施本發明之一或多種技術之一服務分配引擎之一實例之一方塊圖。 [圖4] 圖4係圖解說明根據本發明之一或多種技術之一緊急通信訊息模式之一實例之一電腦程式列表。 [圖5] 圖5係圖解說明根據本發明之一或多種技術之根據一模式格式化之緊急通信訊息之一實例之一電腦程式列表。 [圖6] 圖6係圖解說明根據本發明之一或多種技術之一緊急通信訊息模式之一實例之一電腦程式列表。 [圖7] 圖7係圖解說明根據本發明之一或多種技術之根據一模式格式化之緊急通信訊息之一實例之一電腦程式列表。 [圖8A] 圖8A係圖解說明根據本發明之一或多種技術之根據一模式格式化之緊急通信訊息之實例之電腦程式列表。 [圖8B] 圖8B係圖解說明根據本發明之一或多種技術之根據一模式格式化之緊急通信訊息之實例之電腦程式列表。 [圖8C] 圖8C係圖解說明根據本發明之一或多種技術之根據一模式格式化之緊急通信訊息之實例之電腦程式列表。 [圖8D] 圖8D係圖解說明根據本發明之一或多種技術之根據一模式格式化之緊急通信訊息之實例之電腦程式列表。 [圖9] 圖9係圖解說明根據本發明之一或多種技術之根據一模式格式化之一緊急通信訊息之一實例之一電腦程式列表。 [圖10] 圖10係圖解說明根據本發明之一或多種技術之根據一模式格式化之緊急通信訊息之一實例之一電腦程式列表。 [圖11] 圖11係圖解說明根據本發明之一或多種技術之一緊急通信訊息模式之一實例之一電腦程式列表。 [圖12] 圖12係圖解說明可實施本發明之一或多種技術之一接收器裝置之一實例之一方塊圖。 [圖13] 圖13係圖解說明根據本發明之一或多種技術之一螢幕上通知通信訊息模式之一實例之一電腦程式列表。 [圖14] 圖14係圖解說明根據本發明之一或多種技術之根據一模式格式化之螢幕上通知通信訊息之一實例之一電腦程式列表。 [圖15] 圖15係圖解說明根據本發明之一或多種技術之一螢幕上通知通信訊息模式之一實例之一電腦程式列表。

Claims (17)

  1. 一種用於傳訊一訊息是否直接整合至形成一服務之一視訊分量中之方法，該方法包括：傳訊指示一低層級通知片段之一例項具有與直接整合至形成一服務之一視訊分量中之訊息相關聯之一類型的一值；及傳訊包含於該低層級通知片段之該例項中之一或多個語法元素之值，該等值指示一訊息是否直接整合至一特定服務之一視訊分量中；且該一或多個語法元素包含規定一廣播串流之一識別符之一屬性。
  2. 如請求項1之方法，其中該一或多個語法元素包含規定在該廣播串流之範疇內之一服務之一唯一識別符之一屬性。
  3. 如請求項2之方法，其中該一或多個語法元素包含規定在該廣播串流之該範疇內之一服務範圍之一屬性。
  4. 如請求項1之方法，其中該一或多個語法元素包含識別一訊息直接整合至一視訊分量中之一持續時間之一屬性。
  5. 如請求項1之方法，其中該一或多個語法元素包含識別直接整合至一視訊分量中之一訊息之指示一接通或關斷狀態之一旗標的一屬性。
  6. 如請求項1之方法，其中該低層級通知片段包含一標記語言片段。
  7. 如請求項1之方法，其中一低層級通知片段包含被包含於一網際網路協定封包中之一片段。
  8. 一種用於回應於一通知訊息而修改一服務之呈現之方法，該方法包括：接收具有與直接整合至形成一服務之一視訊分量中之訊息相關聯之一類型的一低層級通知片段之一例項；藉由剖析來自該低層級通知片段之資訊而判定一通知訊息直接整合至形成一服務之一媒體分量中；及基於一通知訊息是否直接整合至形成該服務之一媒體分量中之該判定而修改該服務之該呈現；且剖析來自該低層級通知片段之資訊包含：剖析規定一廣播串流之一識別符之一屬性。
  9. 如請求項8之方法，其中剖析來自該低層級通知片段之資訊包含：剖析規定在該廣播串流之範疇內之一服務之一唯一識別符的一屬性。
  10. 如請求項9之方法，其中剖析來自該低層級通知片段之資訊包含：剖析規定在該廣播串流之範疇內之一服務範圍之一屬性。
  11. 如請求項9之方法，其中剖析來自該低層級通知片段之資訊包含：剖析識別一訊息直接整合至一視訊分量中之一持續時間的一屬性。
  12. 如請求項9之方法，其中剖析來自該低層級通知片段之資訊包含：剖析識別直接整合至一視訊分量中之一訊息之指示一接通或關斷狀態之一旗標的一屬性。
  13. 一種包括一非暫時性電腦可讀儲存媒體及一或多個處理器之裝置，該一或多個處理器經組態以：接收具有與直接整合至形成一服務之一視訊分量中之訊息相關聯之一類型的一低層級通知片段之一例項；藉由剖析來自該低層級通知片段之資訊而判定一通知訊息直接整合至形成一服務之一媒體分量中；及基於一通知訊息是否直接整合至形成該服務之一媒體分量中之該判定而修改該服務之呈現；且剖析來自該低層級通知片段之資訊包含：剖析規定一廣播串流之一識別符之一屬性。
  14. 如請求項13之裝置，其中剖析來自該通知片段之資訊包含：剖析規定在該廣播串流之範疇內之一服務之一唯一識別符的一屬性。
  15. 如請求項14之裝置，其中剖析來自該低層級通知片段之資訊包含：剖析規定在該廣播串流之該範疇內之一服務範圍之一屬性。
  16. 如請求項14之裝置，其中剖析來自該低層級通知片段之資訊包含：剖析識別一訊息直接整合至一視訊分量中之一持續時間的一屬性。
  17. 如請求項14之裝置，其中剖析來自該低層級通知片段之資訊包含：剖析識別直接整合至一視訊分量中之一訊息之指示一接通或關斷狀態之一旗標的一屬性。
TW106114210A 2016-04-28 2017-04-28 用於傳訊緊急警示之系統及方法 TWI646833B (zh)

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
US201662329182P 2016-04-28 2016-04-28
US62/329,182 2016-04-28
US201662349058P 2016-06-12 2016-06-12
US62/349,058 2016-06-12
US201662351261P 2016-06-16 2016-06-16
US62/351,261 2016-06-16
US201662354646P 2016-06-24 2016-06-24
US62/354,646 2016-06-24

Publications (2)

Publication Number Publication Date
TW201743621A TW201743621A (zh) 2017-12-16
TWI646833B true TWI646833B (zh) 2019-01-01

Family

ID=60159761

Family Applications (1)

Application Number Title Priority Date Filing Date
TW106114210A TWI646833B (zh) 2016-04-28 2017-04-28 用於傳訊緊急警示之系統及方法

Country Status (7)

Country Link
US (1) US20190124413A1 (zh)
KR (1) KR102080726B1 (zh)
CN (1) CN109417653A (zh)
CA (1) CA3021659C (zh)
MX (1) MX2018012899A (zh)
TW (1) TWI646833B (zh)
WO (1) WO2017188293A1 (zh)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10382824B2 (en) * 2015-07-17 2019-08-13 Tribune Broadcasting Company, Llc Video production system with content extraction feature
JP2019135806A (ja) * 2018-02-05 2019-08-15 ソニーセミコンダクタソリューションズ株式会社 復調回路、処理回路、処理方法、および処理装置
US11533600B2 (en) 2019-05-07 2022-12-20 West Pond Technologies, LLC Methods and systems for detecting and distributing encoded alert data
CN110109807B (zh) * 2019-05-13 2023-05-26 中国民航大学 一种空管重要设备的预警维护系统
WO2022034384A1 (en) * 2020-08-14 2022-02-17 Spectrum Co, Llc D.B.A., Bitpath Methods and systems for modulating electricity generation or consumption through multicast communications over broadcast mediums

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TW200400764A (en) * 1999-10-22 2004-01-01 Activesky Inc An object oriented video system
US20080005763A1 (en) * 2006-06-29 2008-01-03 Oh Jae W Broadcast receiver and method for performing closed caption

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7050109B2 (en) * 2001-03-02 2006-05-23 General Instrument Corporation Methods and apparatus for the provision of user selected advanced close captions
KR101259118B1 (ko) * 2007-02-23 2013-04-26 엘지전자 주식회사 방송 신호 송신 장치 및 방법
JP2010035085A (ja) * 2008-07-31 2010-02-12 Sanyo Electric Co Ltd デジタル放送受信装置
EP3035672B1 (en) * 2013-08-12 2019-04-17 LG Electronics Inc. Broadcast signal transmitting apparatus, broadcast signal receiving method, broadcast signal transmitting method, and broadcast signal receiving method.
JP2015061195A (ja) * 2013-09-18 2015-03-30 ソニー株式会社 送信装置及び送信方法、受信装置及び受信方法、並びにコンピューター・プログラム
KR101827277B1 (ko) * 2015-03-01 2018-02-08 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TW200400764A (en) * 1999-10-22 2004-01-01 Activesky Inc An object oriented video system
US20080005763A1 (en) * 2006-06-29 2008-01-03 Oh Jae W Broadcast receiver and method for performing closed caption

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
< ATSC Candidate Standard: Signaling, Delivery, Synchronization, and Error Protection (A/331)>，<Doc. S33-174r1>，<2016/01/05>，<PAGE 1~66> *

Also Published As

Publication number Publication date
TW201743621A (zh) 2017-12-16
CA3021659A1 (en) 2017-11-02
MX2018012899A (es) 2019-01-30
KR20180133909A (ko) 2018-12-17
WO2017188293A1 (en) 2017-11-02
CN109417653A (zh) 2019-03-01
KR102080726B1 (ko) 2020-02-24
CA3021659C (en) 2022-10-25
US20190124413A1 (en) 2019-04-25

Similar Documents

Publication Publication Date Title
TWI646833B (zh) 用於傳訊緊急警示之系統及方法
US11006189B2 (en) Primary device, companion device and method
TWI787218B (zh) 用於以信號發送與一緊急警報訊息相關聯之資訊之方法、裝置、設備、記錄媒體、剖析與一緊急警報訊息相關聯之資訊之裝置、用於以信號發送及剖析與一緊急警報訊息相關聯之資訊之系統、用於擷取與一緊急警報訊息相關聯之一媒體資源之方法及用於基於一緊急警報訊息而執行一動作之方法
US11615778B2 (en) Method for receiving emergency information, method for signaling emergency information, and receiver for receiving emergency information
US10506302B2 (en) Method for signaling opaque user data
US20190141361A1 (en) Systems and methods for signaling of an identifier of a data channel
WO2017047397A1 (ja) 受信装置、送信装置、及び、データ処理方法
TWI640962B (zh) 用於緊急警報訊息之傳訊之系統及方法
WO2017213234A1 (en) Systems and methods for signaling of information associated with a visual language presentation