TWI793106B

TWI793106B - 具內容識別符之恢復資料

Info

Publication number: TWI793106B
Application number: TW107105517A
Authority: TW
Inventors: 賽欽 G 迪斯潘迪
Original assignee: 日商夏普股份有限公司
Priority date: 2017-02-14
Filing date: 2018-02-14
Publication date: 2023-02-21
Also published as: US20200128290A1; CA3049348A1; US11019390B2; CA3049348C; TW201836362A; CN110226330A; WO2018151105A1

Abstract

本發明揭示一種用於擷取浮水印相關聯之恢復資料資訊之系統。

Description

具內容識別符之恢復資料

本發明大體上係關於一種具有視聽內容浮水印之系統。

在諸多數位廣播系統中，一廣播站傳輸視聽內容及一或多個增強型服務資料。該增強型服務資料可與該視聽(AV)內容一起提供以提供資訊及服務，或可獨立於該AV內容提供以提供資訊及服務。在諸多廣播環境中，AV內容及一或多個增強型服務資料並非由一AV呈現裝置自廣播站直接接收。確切而言，AV呈現裝置(諸如一電視)通常連接至一廣播接收裝置，該廣播接收裝置依一經壓縮形式接收該AV內容及該一或多個增強型服務資料並將未經壓縮AV內容提供至該AV呈現裝置。在一些廣播環境中，廣播接收裝置自一伺服器(有時被稱為一多頻道視訊節目分配者(MVPD))接收AV內容。該MVPD自廣播站接收一AV廣播信號、自該經接收AV廣播信號提取內容、將該經提取內容轉換成具有適於傳輸之一格式之AV信號、及將該等經轉換AV信號提供至該廣播接收裝置。在該轉換程序期間，該MVPD通常移除自廣播站提供之增強型服務資料，或可併入有提供至廣播接收裝置之一不同增強型服務資料。以此方式，廣播站可提供具有增強型服務資料之AV內容，但最終提供至AV呈現裝置及/或廣播接收裝置之增強型服務資料(若存在)可能與由廣播站提供之增強型服務資料不同。因為廣播接收裝置自從MVPD接收之信號提取AV內容，並僅將未經壓縮AV資料提供至AV呈現裝置，故僅提供至廣播接收裝置之增強型服務資料可用。此外，由廣播站提供之相同增強型服務資料可能不提供至廣播接收裝置及/或AV呈現裝置。在考量結合隨附圖式進行之本發明之以下詳細描述之後，將更容易理解前述內容及本發明之其他目的、特徵及優點。

根據本發明之一個實例，一種用於自一提供者接收一補充內容之方法包括以下步驟：(a)接收包含一RecoveryDataTable元素之呈一恢復檔案格式之一恢復資料表；(b)接收該RecoveryDataTable元素之描述關於一訊息中所提供之一內容識別符之資訊的一contentID欄位；(c)接收該contentID欄位之描述內容識別符之一類型及定義一統一資源名稱的一type欄位；(d)接收該contentID欄位之描述一廣告識別符之一cid欄位且其中該cid欄位具有一最大長度10；(e)接收該contentID欄位之描述內容識別符從何時起有效之一valid from欄位；(f)接收該contentID欄位之描述內容識別符有效至何時的一valid until欄位；(g)基於該恢復資料表接收該補充內容。根據本發明之另一實例，一種用於自一提供者接收一補充內容之接收器，包括以下步驟：(a)該接收器接收包含一RecoveryDataTable元素之呈一恢復檔案格式檔案之一恢復資料表；(b)該接收器接收該RecoveryDataTable元素之描述關於一訊息中所提供之一內容識別符之資訊的一contentID欄位；(c)該接收器接收該contentID欄位之描述內容識別符之一類型及定義一統一資源名稱的一type欄位；(d)該接收器接收該contentID欄位之描述一廣告識別符之一cid欄位且其中該cid欄位具有一最大長度10；(e)該接收器接收該contentID欄位之描述內容識別符從何時起有效之一valid from欄位；(f)該接收器接收該contentID欄位之描述內容識別符有效至何時之一valid until欄位；(g)該接收器基於該恢復資料表接收該補充內容。

參考圖1，系統可包含一內容源100、一內容辨識服務提供伺服器120、一MVPD 130、一增強型服務資訊提供伺服器140、一廣播接收裝置160、一網路170及一AV呈現裝置180。該內容源100可對應於廣播包含一或多個AV內容串流(例如，音訊及/或視訊)之一廣播信號之一廣播站。該廣播站可使用高階電視系統委員會(ATSC)發射規範。該廣播信號可進一步包含增強型服務資料及/或發訊資訊。該增強型服務資料較佳地係關於AV廣播串流之一或多者。增強型資料服務可具有任何合適格式，舉例而言，諸如服務資訊、後設資料、額外資料、經編譯執行檔案、網路應用程式、超文件標示語言(HTML)文件、可擴展標示語言(XML)文件、級聯式樣表單(CSS)文件、音訊檔案、視訊檔案、ATSC、未來版本內容及諸如一統一資源定位符(URL)之位址。內容辨識服務提供伺服器120提供容許AV呈現裝置180在來自內容源100之AV內容的基礎上辨識內容之一內容辨識服務。內容辨識服務提供伺服器120可視需要(諸如)藉由包含一浮水印而修改AV廣播內容。內容辨識服務提供伺服器120可包含一浮水印插入器。該浮水印插入器可插入數個浮水印，該等浮水印經設計以在觀看者感知不到或至少在最小程度上干擾觀看者的情況下攜載增強型服務資料及/或發訊資訊。在其他情況中，可插入一可容易觀察之浮水印(例如，可容易觀察可係在影像中可容易看見，及/或可容易觀察可係在音訊中可容易聽見)。例如，可容易觀察之浮水印可為一標誌，諸如各圖框之左上部或右上部處之一內容提供者之一標誌。內容辨識服務提供伺服器120可包含修改AV內容以包含一非可容易觀察之浮水印(例如，非可容易觀察可係在影像中非可容易看見，及/或非可容易觀察可係在音訊中非可容易聽見)之一浮水印插入器。例如，非可容易觀察之浮水印可包含安全資訊、追蹤資訊、資料或其他。另一實例包含頻道、內容、時序、觸發及/或URL資訊。 MVPD 130自一或多個廣播站接收廣播信號，且通常將經多工化之廣播信號提供至廣播接收裝置160。MVPD 130可對該等經接收廣播信號執行解調變及頻道解碼以提取AV內容及增強型服務資料。MVPD 130亦可對該經提取AV內容及增強型服務資料執行頻道編碼以產生一經多工化信號以供進一步分配。MVPD 130可排除該經提取增強型服務資料及/或可包含一不同增強型服務資料。廣播接收裝置160可調至由一使用者選擇之一頻道並接收該所調至之頻道之一AV信號。廣播接收裝置160通常對該經接收信號執行解調變及頻道解碼以提取所要AV內容。廣播接收裝置160使用任何合適技術(舉例而言，諸如H.264、動畫專家組(MPEG)進階視訊編碼(AVC)、H.265、高效視訊編碼(HEVC)、杜比數位(AC3)及/或進階音訊編碼(ACC)系統)解碼該經提取AV內容。廣播接收裝置160通常將未經壓縮AV內容提供至AC呈現裝置180。增強型服務資訊提供伺服器140回應於來自AV呈現裝置180之一請求將增強型服務資訊提供至AV內容。 AV呈現裝置180可包含一顯示器，舉例而言，諸如一電視、一筆記本電腦、一行動電話及一智慧型電話。AV呈現裝置180可自廣播接收裝置160接收未經壓縮(或經壓縮) AV內容或視訊或音訊內容，自內容源100接收包含經編碼AV內容或視訊或音訊內容之一廣播信號，及/或自MVPD 130接收經編碼或經解碼AV內容或視訊或音訊內容。在一些情況中，可經由一高清晰度多媒體介面(HDMI)纜線接收該未經壓縮視訊及音訊。AV呈現裝置180可透過網路170自內容辨識服務提供伺服器120接收與來自增強型服務資訊提供伺服器140之AV內容有關之一增強型服務之一位址。應理解，可視需要組合或省略內容源100、內容辨識服務提供伺服器120、MVPD 130及增強型服務資訊提供伺服器140。應理解，此等係邏輯角色。在某一情況中，此等實體中之一些可為單獨實體裝置。在其他情況中，此等邏輯實體中之一些可體現於同一實體裝置中。例如，若需要，可組合廣播接收裝置160與AV呈現裝置180。參考圖2，一經修改系統可包含一浮水印插入器190。該浮水印插入器190可修改AV (例如，音訊及/或視訊)內容以將額外資訊包含於該AV內容中。MVPD 130可接收並分配包含具有浮水印之經修改AV內容之一廣播信號。浮水印插入器190較佳依包含額外資訊之一方式修改信號，該額外資訊呈數位資訊之形式係非可容易觀察的(例如，在視覺及/或聽覺上)。在非可容易觀察之浮水印中，經插入資訊在音訊及/或視訊中可容易識別。在非可容易觀察之浮水印中，儘管資訊被包含於AV內容(例如，音訊及/或視訊)中，但一使用者不容易注意到該資訊。浮水印之一個用途係用於抑制數位媒體之非法複製之著作權保護。浮水印之另一用途係數位媒體之源追蹤。浮水印之一進一步用途係數位媒體之描述性資訊。浮水印之又另一用途係提供關於可在何處接收與數位媒體相關聯之額外內容之位置資訊。又另一用途係識別正被觀看之內容及內容源及該內容中之當前時間點，且接著容許裝置經由一網際網路連接存取所要額外功能性。浮水印資訊係包含於AV內容本身內，如與連同該AV內容一起遞送之後設資料區分開。藉由實例，可藉由使用一擴展頻譜技術、一量化技術及/或一振幅調變技術而包含浮水印資訊。參考圖3，繪示一例示性資料流。內容源100將包含至少一AV內容及一增強型服務資料201之一廣播信號傳輸至浮水印插入器190。浮水印插入器190接收內容源100提供之廣播信號，且將一可容易觀察及/或一非可容易觀察之浮水印包含於該AV內容中。將具有浮水印之經修改AV內容與增強型服務資料203一起提供至MVPD 130。與浮水印相關聯之內容資訊可包含(例如)提供AV內容之一內容提供者之識別資訊、AV內容識別(ContentID)資訊、內容資訊獲取中所使用之一內容區段之時間資訊、AV內容透過其廣播之頻道之名稱、AV內容透過其廣播之頻道之標誌、AV內容透過其廣播之頻道之描述、一使用資訊報告週期、使用資訊獲取之最小使用時間、體育賽事之統計資料、有用資訊之顯示、介面工具集、應用程式、與AV內容有關之可執行及/或可用增強型服務資訊。可用增強型服務資料之獲取路徑可依任何方式表示，諸如一基於網際網路協定(IP)之路徑或一ATSC-行動手持路徑。 MVPD 130接收包含加浮水印之AV內容及增強型資料服務之廣播信號，且可產生一經多工化信號以將其提供205至廣播接收裝置160。此時，該經多工化信號可排除該經接收增強型服務資料及/或可包含一不同增強型服務資料。廣播接收裝置160可調至一使用者選擇之一頻道且接收該所調至之頻道之信號、解調變該等經接收信號、對該等經解調變信號執行頻道解碼及視聽解碼以產生一未經壓縮視聽內容，且接著將該未經壓縮AV內容提供206至AV呈現裝置180。內容源100亦可透過一頻道將AV內容廣播207至AV呈現裝置180。MVPD 130可不經過廣播接收裝置160直接將包含AV內容之一廣播信號傳輸208至AV呈現裝置180。在又另一情況中，可經由一寬帶連接將部分AV資訊發送至AV呈現裝置180。在一些情況中，此可為經管理寬帶連接。在另一情況中，其可為未經管理寬帶連接。 AV呈現裝置180可自廣播接收裝置160接收未經壓縮(或經壓縮) AV內容。此外，AV呈現裝置180可透過一頻道自內容源100接收一廣播信號，且接著可解調變並解碼該經接收廣播信號以獲得AV內容。此外，AV呈現裝置180可自MVPD 130接收一廣播信號，且接著可解調變並解碼該經接收廣播信號以獲得AV內容。AV呈現裝置180 (或廣播接收裝置160)自一或多個視訊圖框或該經接收AV內容之音訊樣本之一選擇提取浮水印資訊。AV呈現裝置180可使用自該(等)浮水印獲得之資訊以向增強型服務資訊提供伺服器140 (或任何其他裝置)請求209額外資訊。增強型服務資訊提供伺服器140作為對AV呈現裝置180之回應可提供一回覆211。參考圖4，另一實例包含將AV內容連同增強型服務資料(若需要)一起提供至浮水印插入器190之內容源100。此外，內容源100可將一碼300連同AV內容一起提供至浮水印插入器190。該碼300可為用以識別複數個AV串流中之哪一者應使用浮水印修改之任何合適碼。例如，碼= 1可識別第一AV串流，碼= 2可識別第二AV串流，碼= 3可識別第三AV串流，碼= 4可識別第四AV串流等。該碼可包含AV內容內之暫時位置(temporal location)。該碼可包含其他後設資料(若需要)。由浮水印插入器190將加浮水印之AV內容及相關聯資料、發訊提供至MVPD，該MVPD繼而可將加浮水印之經壓縮AV內容提供至廣播接收裝置160 (例如，一機頂盒)。廣播接收裝置160可將(例如，通常未經壓縮之)加浮水印之AV內容提供至AV呈現裝置180。AV呈現裝置180可包含一具備浮水印能力之接收器310連同一浮水印用戶端320。該具備浮水印能力之接收器310適於偵測浮水印在AV內容內之存在，及自該AV內容內提取浮水印資料。該浮水印用戶端320適於使用自浮水印提取之該資料以基於其請求額外資料，且隨後以一合適方式使用此額外資料。 AV呈現裝置180可使用來自經提取浮水印之碼300以向一後設資料伺服器350提出一請求。一碼資料庫370自內容源100接收包含碼300及後設資料360之資料。該碼300及後設資料360係儲存於該碼資料庫370中以供後續使用。以此方式，提供至浮水印插入器190之在AV內容內編碼之碼300亦連同其後設資料360一起儲存於碼資料庫370中。在MVPD 130或以其他方式移除相關聯後設資料或以其他方式改變該相關聯後設資料之情況中，可由AV呈現裝置180自後設資料伺服器350恢復該資料，該後設資料伺服器350使用經提供碼351查詢碼資料庫370且將具有後設資料353之一相關聯回應提供至AV呈現裝置180。由後設資料伺服器350提供之回覆後設資料係由AV呈現裝置180用於形成提供至內容及發訊伺服器380之一請求355。該內容及發訊伺服器380回應於該請求將選定內容及發訊357提供至AV呈現裝置180。一般而言，內容及發訊伺服器380可不同於後設資料伺服器350。然而，歸因於所利用之兩個不同伺服器及/或請求，向後設資料伺服器提出一第一請求以獲得對所提供之碼之一回應，接著隨後使用該後設資料將一請求提供至內容及發訊伺服器380係繁重的且容易失敗。此外，其可增加延時。藉由實例，後設資料可由以下語法元素之一或多者組成： (1)內容及發訊伺服器之位置(例如，伺服器在何處，諸如其網路位址。網路位址之實例係域名、IP v4位址等)； (2)用於與內容及發訊伺服器通信之協定；例如，超文件傳送協定安全(HTTPS)或超文件傳送協定(HTTP)； (3)識別AV內容中之一暫時位置之時間碼(例如，應在AV內容內之何處與後設資料相關聯)； (4)時間敏感事件觸發(例如，AV內容中之一特定位置之一廣告或一事件)； (5)頻道識別(例如，頻道特定資訊；本地頻道內容)； (6)由用戶端隨機實施內容及發訊伺服器請求之持續時間(例如，針對負載平衡)。為簡潔起見，此語法元素亦可被稱為內容伺服器請求之持續時間； (7)等等。視聽內容中所嵌入之該(等)浮水印在加浮水印之視聽廣播具有非可容易觀察之資訊時通常具有僅攜載有效負載資訊之幾個位元的一容量。對於相對較小有效負載大小，時間碼(上文元素3)及/或內容及發訊伺服器之位置(上文元素1)往往占可用有效負載之一顯著百分比，從而為剩餘資料留下有限額外有效負載，此往往是有問題的。為在浮水印內包含足夠後設資料使得時間碼與位置資訊兩者皆可連同額外資訊一起提供，可期望跨多個浮水印有效負載分割該後設資料。同樣地，浮水印有效負載之各者較佳地包含於AV內容之不同部分內。自多個浮水印有效負載提取之資料組合在一起以形成用於提出一請求之一組符合需要之資訊。在下文描述中，術語有效負載可用於指示浮水印有效負載。語法元素之各者可包含於一單一有效負載內，延伸多個有效負載，及/或跨多個有效負載碎片化。出於識別目的，各有效負載可被指派一有效負載類型。此外，一關聯可建立於屬於相同或近似相同之時間線位置之多個有效負載之間。又，該關聯可視需要為單向或雙向的。所要時間碼資料可自延伸AV內容之若干暫時位置之(若干)有效負載獲得。因此，一些系統可建立規則以使該AV內容之經判定時間碼與一特定暫時位置相關聯。在一實例中，選定暫時位置可對應於一經預先判定浮水印有效負載之末尾處之暫時位置。例如，有效負載大小可為50個位元，而符合需要之後設資料可為70個位元，因此超過一單一浮水印之有效負載大小。符合需要之後設資料之一實例可為如下：內容及伺服器之位置(I) 32個位元(IP位址) 應用層協定(A) 1個位元(HTTP或HTTPS) 時間碼(T) 25個位元(針對1年單獨性，具有1秒之一粒度) 時間敏感觸發(D) 1個位元(一值1指示AV呈現裝置應查詢互動式內容。一值0指示AV呈現裝置不應查詢互動式內容(例如，如在時基觸發中))。頻道識別(L) 9個位元內容伺服器請求之持續時間(R) 2個位元符合需要之後設資料之另一實例可為如下：內容及伺服器之位置(I) 32個位元(IP位址) 應用層協定(A) 2個位元(00= HTTP，01= HTTPS，10=經保留，11=經保留) 時間碼(T) 25個位元(針對1年單獨性，具有1秒之一粒度) 時間敏感觸發(D) 1個位元頻道識別(L) 9個位元內容伺服器請求之持續時間(R) 2個位元分割後設資料之一種方式係在一個有效負載中包含內容及發訊伺服器通信資訊(CSSCI)，且在另一有效負載中包含時間線資訊。該CSSCI有效負載可包含例如資訊在哪裡(例如，內容及發訊伺服器之位置)、關聯資訊(例如，使該CSSCI有效負載與一或多個其他有效負載相關聯之一識別符)、及資訊如何(例如，應用層協定、內容伺服器請求之持續時間)。該時間線資訊可包含例如關聯資訊(例如，使該時間線與一或多個其他有效負載相關聯之一識別符)、「何時」資訊(例如，時間碼資訊)及「何者」資訊(例如，頻道識別)。參考圖5，繪示一例示性CSSCI有效負載。參考圖6，繪示一例示性時間位置(time location)有效負載。可替代地使用術語時間位置取代術語暫時位置(temporal location)。有效負載類型可由第一位元「Y」識別。當Y經設定為0時，有效負載對應於CSSCI有效負載，且14位元有效負載識別符(P)係用於標記該CSSCI。當Y經設定為1時，該有效負載對應於暫時位置有效負載，且14位元有效負載識別符(P)發訊對應CSSCI。因此，具有相同有效負載識別符(P)值之不同有效負載類型係彼此相關聯。識別符R指示傳播內容及發訊伺服器請求之一持續時間。在一實例中，「Y」可對應於一2位元欄位，其中值00指示一CSSCI有效負載，值01指示一暫時位置有效負載，且值10、11經保留以供未來使用。參考圖7，繪示一例示性時間線。一第一CSSCI類型有效負載(例如，CSSCI-0)具有一第一組關聯資訊P，而一第二CSSCI類型有效負載(例如，CSSCI-1)具有一第二組不同關聯資訊P。針對CSSCI-0與CSSCI-1存在兩種不同關聯資訊P區分並識別該兩個CSSCI有效負載。一第一時間位置有效負載(例如，Timeline-0)具有匹配CSSCI-0之關聯資訊P之第一組關聯資訊P，一第二時間位置有效負載(例如，Timeline-1)具有匹配CSSCI-0之關聯資訊P之相同第一組關聯資訊P，一第三時間位置有效負載(例如，Timeline-2)具有匹配CSSCI-1之關聯資訊P之相同第二組關聯資訊P。以此方式，CSSCI-0、Timeline-0；CSSCI-1、Timeline-1；與CSSCI-1、Timeline-2相關聯在一起作為具有延伸的加浮水印資訊之對。此准許相同CSSCI類型有效負載用於多個不同時間位置有效負載。如所繪示，各暫時位置有效負載與一先前經接收CSSCI類型有效負載相關聯，且因此，在其關聯中係單向的。在匹配一暫時位置有效負載之一先前CSSCI類型有效負載不可用之情況中，則系統能夠判定一封包已丟失或另外浮水印係無效的。浮水印資料之丟失因為視聽內容往往藉由視聽轉碼修改例如以減小該視聽內容之位元率而依某一頻率發生。參考圖8，繪示一例示性時間線。一第一CSSCI類型有效負載(例如，CSSCI-0)具有一第一組關聯資訊P，而一第二CSSCI類型有效負載(例如，CSSCI-1)具有一第二組不同關聯資訊P。針對CSSCI-0與CSSCI-1存在兩種不同關聯資訊P區分並識別該兩個CSSCI有效負載。一第一時間位置有效負載(例如，Timeline-0)具有匹配CSSCI-0之關聯資訊P之第一組關聯資訊P，一第二時間位置有效負載(例如，Timeline-1)具有匹配CSSCI-0之關聯資訊P之相同第一組關聯資訊P，一第三時間位置有效負載(例如，Timeline-2)具有匹配CSSCI-1之關聯資訊P之相同第二組關聯資訊P。以此方式，CSSCI-0、Timeline-0；CSSCI-1、Timeline-1；與CSSCI-1、Timeline-2相關聯在一起作為具有延伸的加浮水印資訊之對。此准許相同CSSCI類型有效負載用於多個不同時間位置有效負載。如所繪示，暫時位置有效負載之兩者與一先前接收之CSSCI類型有效負載相關聯，且CSSCI類型有效負載之一者與一隨後接收之暫時位置有效負載相關聯，且因此在其關聯中係雙向的。在匹配一暫時位置有效負載之一對應CSSCI類型有效負載不可用之情況中，則系統能夠判定一封包已丟失或另外浮水印係無效的。類似地，在匹配一CSSCI有效負載之一對應時間線類型有效負載不可用之情況中，則系統能夠判定一封包已丟失或另外浮水印係無效的。浮水印資料之丟失因為視聽內容往往藉由視聽轉碼修改(諸如)以減小該視聽內容之位元率而依某一頻發發生。在一實例中，一CSSCI類型有效負載(例如，CSSCI-0)具有兩組關聯資訊P0與P1。一時間位置有效負載(例如，Timeline-0)具有匹配CSSCI-0之關聯資訊P0與P1之兩組關聯資訊P0與P1。在此實例中，針對對CSSCI-0、Timeline-0存在一雙向關聯，其中P0指向CSSCI-0且P1指向Timeline-0。可視需要(例如，針對一所要穩健性)修改指派給有效負載識別符(P)之位元之數目。類似地，可視需要修改指派給I、A、T、D、L及R之位元之數目。在一實例中，AV呈現裝置180可維持由(例如)「c」個最近接收之CSSCI有效負載之一可變listC標示之一清單。若需要，可將「c」提供於浮水印中，或可由系統以其他方式設定「c」。以此方式，AV呈現裝置180可僅必須在記憶體中維持有限數目個CSSCI有效負載。在c=1之情況中，一旦接收一CSSCI有效負載，其即保持生效直至接收另一CSSCI有效負載，如圖9中所繪示。可使用有效負載識別符(P)偵測一CSSCI有效負載之一丟失；例如，暫時位置有效負載含有並不對應於listC中之CSSCI有效負載之任一者之一P。以此方式，可跨不同AV呈現裝置實現相同使用者體驗。在一實例中，AV呈現裝置180可維持(若干)經接收CSSCI有效負載之一個以上清單。各清單之大小可不同，且可使用一組不同規則維持各清單(即，清單內之項目之添加或移除)。應理解，此不排除清單之一子組可具有相同大小及/或相同維持規則之可能性。作為一實例，可能存在由180維持之兩個清單，其中一個清單含有(若干)「c1」最近接收之CSSCI有效負載，其中按(若干)「0」CSSCI有效負載之一間隔接收各有效負載；而另一清單含有(若干)「c2」最近接收之CSSCI有效負載，其中按(若干)「d」CSSCI有效負載之一間隔接收各有效負載。參考圖10，一經修改系統可包含內容源100、浮水印插入器190、MVPD 130、廣播接收裝置160、及AV呈現裝置180，連同其具備浮水印能力之接收器310及浮水印用戶端320。內容伺服器400可經修改以包含碼資料庫370、後設資料伺服器350、及內容及發訊伺服器380之一或多者。碼300及後設資料360係由內容源100提供至內容伺服器400。內容及發訊資料係提供至(若干)內容及發訊伺服器390。 AV呈現裝置180可基於自視聽廣播解碼之一或多個浮水印將一碼提供於一請求中。內容伺服器400自AV呈現裝置180接收具有該碼之該請求。接著，後設資料伺服器350剖析該經接收碼請求，且基於來自碼資料庫370之資訊，向(若干)內容及發訊伺服器390提出一請求來判定接著提供至AV呈現裝置180之內容及發訊資訊。以此方式，AV呈現裝置180僅需向一內容伺服器400提出一單一請求，該內容伺服器400繼而將回應提供至AV呈現裝置180。應理解，可藉由將既有功能組合在一起、將該等既有功能分離至更多組件中、省略組件及/或藉由任何其他技術實現內容伺服器400之不同功能。當時間敏感觸發D等於1時，對應於圖5及圖6中之(若干)有效負載之一HTTP或HTTPS請求URL (其將被發送至內容伺服器400)可如下定義：若A等於0，則HTTP請求URL係： HTTP://IIIIIIII.IIIIIIII.IIIIIIII.IIIIIIII/LLLLLLLLL?time=TTTTTTTTTTTTTTTTTTTTTTTTT 否則，HTTPS請求URL係： HTTPS://IIIIIIII.IIIIIIII.IIIIIIII.IIIIIIII/LLLLLLLLL?time=TTTTTTTTTTTTTTTTTTTTTTTTT 其中以上IIIIIIII.IIIIIIII.IIIIIIII.IIIIIIII對應於CSSCI有效負載中發訊之32位元IP位址。在一實例中，依一指定有效負載類型攜載指定資訊(諸如：內容伺服器位置、通信協定、通信埠、登錄資訊、內容伺服器上之文件庫)之URL之子組。在一些實施方案中，可使用可存取延伸多個有效負載之資訊之一解碼程序導出一語法元素之值。例如，時間碼可經碎片化至多個浮水印有效負載中，且接著經重新組裝以建構一完整時間碼。在一實例中，時間碼可對應於AV內容內之一暫時位置。在一實例中，時間碼可對應於AV內容之時間線資料。例如，有效負載大小可為50個位元，而符合需要之後設資料可為66個位元，因此超過一單一浮水印之有效負載大小。符合需要之後設資料之一實例可為如下：內容及伺服器之位置(I) 32個位元(IP位址) 應用層協定(A) 1個位元(HTTP或HTTPS) 時間碼(T) 25個位元(針對1年單獨性，具有1秒之一粒度) 時間敏感觸發(D) 1個位元頻道識別(L) 5個位元內容伺服器請求之持續時間(R) 2個位元符合需要之後設資料之另一實例可為如下：內容及伺服器之位置(I) 32個位元(IP位址) 應用層協定(A) 2個位元(00= HTTP，01= HTTPS，10=經保留，11=經保留) 時間碼(T) 25個位元(針對1年單獨性，具有1秒之一粒度) 時間敏感觸發(D) 1個位元頻道識別(L) 5個位元內容伺服器請求之持續時間(R) 2個位元參考圖11，一狀態轉變圖繪示計算時間碼之一技術。為獲得一時間碼同步，以一有效負載類型「start sync」開始之數個連續有效負載其後接著類型「not start sync」之有效負載，其中一總數等於「r」。藉由使用總數「r」個連續有效負載(其內各具有所含之一些時間資訊)，可藉由計算一錨時間而判定時間同步。在計算錨時間碼之後，可藉由以使得無需接收另一總數「r」個連續有效負載來判定下一時間碼之一方式接收包含其中之部分時間碼資訊之額外有效負載而更新該時間碼。實現此時間同步之一技術係分割連續有效負載中之時間碼及連續有效負載之各者中之一增量式時間碼。當同步(諸如)由於改變頻道而丟失時，執行獲得同步程序。一視訊顯示器裝置在第一次初始化或開啟時進入初始獲得同步狀態。參考圖12，繪示一浮水印有效負載之一例示性結構。Z指示有效負載類型，其中Z等於1指示時間同步之開始，且Z等於0指示時間同步未開始。S指示用於判定絕對時間碼之時間同步有效負載位元。M指示用於維持時間碼之時間同步有效負載位元。藉由實例，AV呈現裝置180可接收n=7個連續浮水印有效負載，其中第一有效負載具有Z=1而其餘有效負載具有Z=0。對應於「SSSS」之位元係自第(t-n+1)個浮水印有效負載至第t個浮水印有效負載提取且級聯在一起以獲得一暫時位置之時間碼「T_t 」之一28位元表示。錨時間碼「C_t 」亦經設定為「T_t 」。可將「T_t 」表示為SSSS_z=1,t-n+1 …SSSS_z=0,t-1 SSSS_z=0,t ；「C_t 」=「T_t 」。在另一實例中，可對經導出值加上常數(以選擇一未來時間)及/或乘以常數(以改變粒度)。在一實例中，藉由使用一映射函數將經導出值映射至另一值。一旦獲得初始化同步，即使用各有效負載更新錨時間及有效負載時間。此可(例如)如下執行： T_t =f (C_t-1 , MMMM_t ) C_t =g (T_t ) 其中，f表示取2個值作為輸入且輸出1個值之一映射函數；g表示取1個值作為輸入且輸出1個值之一映射函數；/表示朝向零截尾之整數除法，例如，7 / 4及-7 / -4經截尾為1且-7 / 4及7 / -4經截尾為-1。在一實例中： T_t =C_t-1 + MMMM_t C_t =T_t 如上文所描述，每「n」個有效負載亦可使用對應於「SSSS」之位元判定錨時間。使用「SSSS」判定之該錨時間可匹配上文之錨時間導出，且可用於驗證所維持時間碼之正確性。因為浮水印可延伸一非零時間，故時間碼T_t 之暫時位置可由一組規則判定，舉例而言，諸如T_t 可對應於第t個浮水印有效負載之末尾處之一時刻。應理解，多個語法元素可經組合以形成碼。接著碼可由AV呈現裝置180映射或使用另一伺服器映射至不同語法元素值。例如，伺服器資訊(例如，(若干)內容及發訊伺服器之位置及/或應用層協定等)與時間碼組合成一單一碼。該單一碼接著映射至未經壓縮視聽串流中之一暫時位置及(若干)內容及發訊伺服器之位置。以此方式，可向伺服器提出對額外資訊之一單一請求。有限數目個位元可依此一方式用於時間碼以准許時間碼中之衝突。例如，針對時間碼使用20個位元容許1秒之一粒度下之至多12天之單獨性。在12天之後，將重新使用對應於時間碼之碼空間，從而導致衝突。在一實例中，浮水印有效負載可使用一或多個cmdID囊封於一SDO私用資料命令內作為SDO有效負載。作為一實例，圖5或圖6之浮水印有效負載可經囊封為SDO有效負載。一cmdID值0x05可係指一基於浮水印之互動式服務觸發或一經觸發聲明物件(TDO)模型。一cmdID值0x06可係指一基於浮水印之互動式服務觸發(直接執行模型)。此促進既有分段及針對觸發運輸建置之重新組裝模組之重新使用。若需要，則可將經分段命令嵌入於浮水印中。可期望SDO私用資料，諸如圖13中所繪示，其中包含封包作為SDO_payload()之部分。在一些實例中，以此方式接收之浮水印有效負載可傳遞至接收器中之處置此等經定義cmdID類型之一實體/模組。接著，若浮水印有效負載封包需分離至多個封包中，則可重新使用該模組之分段及重新組裝功能性，此取決於就位元數目而言之選定浮水印方案之容量。參數類型T係一2位元欄位，其指示SDO私用資料或SDOPrivateData命令之例項是否為一經分段可變長度命令之部分，且若如此，則無論該例項是否為該經分段可變長度命令之第一分段、中間分段或最後分段。在一個實例中，SDOPrivateData係藉由「CEA：「數位電視(DTV)隱藏字幕，CEA-708-E，消費電子協會，2013年6月」」(CEA-708)之章節7.1.11.2中予以定義，且SDO私用資料命令中之type欄位係如CEA-708之章節7.1.11.2中所指定般編碼。pr係一旗標，其在設定為「1」時指示命令之內容經確證為相關程式。當該旗標設定為「0」時，命令之內容並不如此確證。長度(L)係指示標頭之後之位元組之數目(在2至27範圍內)之不帶正負號整數，且其在SDO私用資料命令中表示為該組位元L₄ 至L₀ ，其中L₄ 係最高有效的，且L₀ 係最低有效的。cmdID係識別已定義需遵循之SDO_payload()資料結構之語法及語義之SDO的一信號。在一實例中，cmdID係一8位元欄位。後設資料可使用一或多個cmdID囊封於SDO私用資料內作為SDO有效負載，如圖14中所展示。圖5及圖6中所定義之有效負載可使用一或多個cmdID囊封於一SDO私用資料命令內作為SDO有效負載。一cmdID值0x05及0x06可係指圖5及圖6中分別定義之有效負載之囊封。此促進既有分段及針對觸發運輸所建置之重新組裝模組之重新使用。若需要，則可將經分段命令嵌入於浮水印中。可期望SDO私用資料，諸如圖13中所繪示，其中包含有效負載封包作為SDO_payload()之部分。圖12中所定義之有效負載可使用一或多個cmdID囊封於一SDO私用資料命令中作為SDO有效負載。一cmdID值0x05可係指圖12中所定義之有效負載之囊封。此促進既有分段及針對觸發運輸建置之重新組裝模組之重新使用。若需要，則可將經分段命令嵌入於浮水印中。可期望SDO私用資料，諸如圖13中所繪示，其中包含封包作為SDO_payload()之部分。接下來描述一浮水印相關聯之資訊擷取系統之一實例。該系統由一浮水印偵測器、一AV呈現裝置、一浮水印資訊伺服器組成。在一個實例中，該浮水印偵測器可駐留於一AV呈現裝置內部。在一個實例中，該AV呈現裝置可為一AV呈現裝置180。在一個實例中，該浮水印資訊伺服器可為一增強型服務資訊提供伺服器140。在一個實例中，浮水印偵測器可偵測及解碼浮水印。浮水印可為一音訊浮水印。浮水印偵測器及/或AV呈現裝置可使用浮水印中之資訊以識別可經級聯以獲得與該浮水印相關聯之進一步資訊之其中嵌入該浮水印之媒體內容之一時間線位置及/或一伺服器之一位址(例如，IP位址)。在一實例中，此可為必須的，因為浮水印有效負載容量可僅為幾個位元。例如，在1秒或1.5秒或2秒之一時間段內，容量可為50個位元。在此情況中，AV呈現裝置可接觸一浮水印資訊伺服器以獲得關於當前媒體之當前時間線位置之更多資訊。浮水印伺服器可發送「浮水印相關聯資訊」作為對此請求之一回應。 JavaScript物件標記法(JSON)係一資料交換格式。 JSON方案定義用於定義JSON資料之結構之一基於JSON之格式。 JSON方案旨在定義JSON資料之驗證、文件化、超鏈接導航及互動控制。物件係零個或多個名稱及值對之一無序集合，其中名稱係一字串且值係一字串、數字、布林值(Boolean)、空值、物件或陣列。 JSON方案係一JSON文件，其可為一物件。藉由JSON方案定義之物件性質被稱為關鍵字或方案關鍵字。 JSON方案可含有並非為方案關鍵字之性質。 JSON值可為一物件、陣列、數字、字串，或假、空值或真之一者。術語元素及索引鍵及關鍵字及名稱在此文件中可交換使用。術語索引鍵可用於指代此文件中之一物件之名稱。術語恢復檔案格式及恢復資料表在此文件中可交換使用。圖15展示用於浮水印相關聯資訊之一例示性JSON方案。關於圖15應注意以下。可使用JSON代替使用XML來表示經擷取之浮水印相關聯資訊。在此情況中，使用JSON物件以及其等性質而非使用元素(例如，XML元素)及屬性(XML屬性)。娛樂識別符暫存器(EIDR)係用於電影及電視資產之一通用識別符系統。自頂級標題、編輯及DVD至編碼、剪輯及混搭，EIDR為與娛樂商務有關之整個視聽物件類型範圍提供全域識別符。EIDR格式在HTTP://eidr.org/documents/EIDR_ID_Format_v1.2.pdf描述且以引用的方式併入本文中。可使用EIDR識別符格式之後續版本。廣告識別符(AD-ID) (其亦可被稱為Ad-ID)係用於識別跨媒體平台之廣告資產之一業界標準。Ad-ID碼結構係展示於HTTP://www.Ad-ID.org/how-it-works/Ad-ID-structure中且以引用的方式併入本文中。關於圖15，在JSON方案中針對包含於ContentID事件中之EIDR及Ad-ID資訊定義一基於正規表達式之語法。與使用一字串相反，此形式語法強制針對EIDR及Ad-ID可僅發訊有效值。此繪示於如下來自圖15之JSON方案之經提取部分中： "ContentID": { "type": "object", "properties": { "oneOf": [ {"Type": {"type": "string", "enum": ["EIDR"]}, "CID": {"type": "string", "pattern": "^10\\.5240\\/([0-9a-fA-F]{4}-){5}[0-9A-Z]$", "minLength": 34, "maxLength": 34}}, {"Type": {"type": "string", "enum": ["AD-ID"]}, "CID": {"type": "string", "pattern": "^[1-9a-zA-Z]{1}[0-9a-zA-Z]{10}(H|D)?$", "minLength": 11, "maxLength": 12}} ] } }, 在此方案中藉由使用基於正規表達式之「型樣」，作為一EIDR類型之內容識別符值(CID)或ContentID索引鍵之一值而包含之字串按照設計始終係一有效EIDR字串。在此方案中藉由使用基於正規表達式之型樣，針對一AD-ID類型之CID索引鍵包含之字串按照設計始終係一有效Ad-ID字串。因此，在JSON資料中不能自浮水印伺服器發送無效EIDR及Ad-ID字串。進一步關於圖15，針對ContentID類型定義一經枚舉資料類型來代替一通用字串。此使值僅限於有效值。因此，不可針對ContentID類型定義一無效值。此可見於針對圖15中之方案中之ContentID物件內部之各自Type (或類型)字串所定義之“enum”: [“EIDR”]及“enum”: [“AD-ID”]值之使用中。因此可定義並傳回無效ContentID類型值。進一步參考圖15，針對藉由圖15中之一觸發索引鍵表示之觸發事件定義一擴展機制以在未來傳回除了一當前定義之統一資源識別符(URI)類型以外之一URI事件類型之一或多者。經擴展URI類型係以一指定首碼予以定義。此繪示於下文來自圖15之JSON方案之經提取部分中。在一實例中，JSON方案包含一應用程式資訊表(AIT)、一媒體呈現描述(MPD)及/或一電子服務導引(ESG)值。 "Trigger": { "type": "object", "properties": { "Trigger": {"type": "string", "format": "uri"}, "Version": {"type": "integer"}, "UriType": {"type": "string", "oneOf": [ {"enum": ["AIT", "MPD","ESG"]}, {"pattern": "^EXT"} ]}, "required": ["Trigger","UriType"] } }, 可見觸發類型(諸如AIT、MPD及ESG)係定義為有效字串值。此係藉由UriType字串之"enum": ["AIT", "MPD","ESG"]表示。在未來可定義其他有效觸發類型。此係藉由容許將其他字串值用於UriType來完成。在一實例中，此等字串可以一首碼EXT開始。此行為係藉由如下對UriType字串使用「oneOf」約束而予以定義： "UriType": {"type": "string", "oneOf": [ {"enum": ["AIT", "MPD","ESG"]}, {"pattern": "^EXT"} ]}, 上文所定義之首碼係標示為EXT，此意謂一擴展UriType可以字元EXT開始。可代替性地使用其他字元。例如，可使用字串FUT、NEXT或任何其他合適字串來代替EXT。在一實例中，可容許一未來UriType作為任何有效字串，在此情況中方案之相關部分可定義為： "UriType": {"type": "string", "oneOf": [ {"enum": ["AIT", "MPD","ESG"]}, {"pattern": ".+"} ]}, 在另一實例中，針對未來可擴展性支援圖15及圖16A至圖16D中所展示之方案之額外整體擴展。在另一實例中，為容許未來可擴展性，JSON方案可用additionalProperties: true之索引鍵、值對予以定義。例如JSON方案之最後4行可用以下代替： "required": ["TimeAnchor","IntervalCodeAnchor","Event"], "additionalProperties": true } } 此容許用經傳回之JSON資料內部之性質來定義額外物件及類型。圖16A至圖16D展示用於浮水印相關聯之資訊擷取之JSON方案之一邏輯結構。圖16A至圖16D結構對應於圖15 JSON方案。然而，該邏輯結構之一些或部分可用不同JSON方案表現。在一實例中，經由圖15及/或圖16A至圖16D中所繪示之JSON方案自一浮水印伺服器傳回之浮水印相關聯之資訊可為一恢復檔案格式。在另一實例中，可使用XML格式代替使用JSON來表示自浮水印伺服器傳回之浮水印相關聯之資訊。接下來描述自浮水印伺服器傳回XML格式資料及與所定義之XML方案的一致性之一些改進及方法。在一實例中，使用XML之一基於型樣之語法係針對包含於ContentID事件中之一EIDR及一Ad-ID資訊之一或多者予以定義。與使用一通用xs:String資料類型相反，此形式語法強制針對EIDR及AD-ID可僅發訊有效值。在一實例中，針對包含之EIDR資訊之XML方案係：＜xs:simpleType name="CID"＞＜xs:restriction base="xs:token"＞＜xs:pattern value="(10\.5240/([0-9a-fA-F]{4}-){5}[0-9A-Z])"/＞＜/xs:restriction＞＜/xs:simpleType＞在一實例中，針對包含之Ad-ID資訊之XML方案係：＜xs:simpleType name="CID"＞＜xs:restriction base="xs:token"＞＜xs:pattern value="([1-9a-zA-Z]{1}[0-9a-zA-Z]{10}(H|D)?)"/＞＜/xs:restriction＞＜/xs:simpleType＞針對包含之EIDR或Ad-ID之一經組合XML方案係如下所展示：＜xs:simpleType name="CID"＞＜xs:restriction base="xs:token"＞＜xs:pattern value="([1-9a-zA-Z]{1}[0-9a-zA-Z]{10}(H|D)?)|(10\.5240/([0-9a-fA-F]{4}-){5}[0-9A-Z])"/＞＜/xs:restriction＞＜/xs:simpleType＞在另一實例中，針對ContentID之類型或ContentIDType定義一經枚舉資料類型來代替一通用字串。此使值僅限於有效值。在一實例中，針對此之XML方案係：＜xs:simpleType name="ContentIDType"＞＜xs:restriction base="xs:string"＞＜xs:enumeration value="EIDR" /＞＜xs:enumeration value="Ad-ID" /＞＜xs:enumeration value="EXT" /＞＜/xs:restriction＞＜/xs:simpleType＞針對包含經約束類型及contentID屬性之ContentID事件之整個XML方案係如下展示：＜xs:element name="ContentID"＞＜xs:complexType＞＜xs:attribute name="type" type="ContentIDType"/＞＜xs:attribute name="contentID" type="CID"/＞＜/xs:complexType＞＜/xs:element＞接下來描述使用XML方案之另一實例。以上XML方案定義容許定義具有等於Ad-ID之類型之一ContentID事件但ContentID值針對EIDR識別符而定義。類似地，以上XML方案定義容許定義具有等於EIDR之類型之一ContentID事件但ContentID值針對Ad-ID識別符而定義。為防止此定義，XML方案可如下定義：＜xs:simpleType name="ContentIDType1"＞＜xs:restriction base="xs:string"＞＜xs:enumeration value="EIDR" /＞＜/xs:restriction＞＜/xs:simpleType＞＜xs:simpleType name="ContentIDType2"＞＜xs:restriction base="xs:string"＞＜xs:enumeration value="Ad-ID" /＞＜/xs:restriction＞＜/xs:simpleType＞＜xs:simpleType name="CIDToken1"＞＜xs:restriction base="xs:token"＞＜xs:pattern value="10\.5240/([0-9a-fA-F]{4}-){5}[0-9A-Z]"/＞＜/xs:restriction＞＜/xs:simpleType＞＜xs:simpleType name="CIDToken2"＞＜xs:restriction base="xs:token"＞＜xs:pattern value="[1-9a-zA-Z]{1}[0-9a-zA-Z]{10}(H|D)?"/＞＜/xs:restriction＞＜/xs:simpleType＞＜xs:element name="ContentID"＞＜xs:complexType＞＜xs:choice＞＜xs:sequence＞＜xs:element name="CID1"＞＜xs:complexType＞＜xs:attribute name="type" type="ContentIDType1"/＞＜xs:attribute name="contentID" type="CIDToken1"/＞＜/xs:complexType＞＜/xs:element＞＜/xs:sequence＞＜xs:sequence＞＜xs:element name="CID2"＞＜xs:complexType＞＜xs:attribute name="type" type="ContentIDType2"/＞＜xs:attribute name="contentID" type="CIDToken2"/＞＜/xs:complexType＞＜/xs:element＞＜/xs:sequence＞＜/xs:choice＞＜/xs:complexType＞＜/xs:element＞此XML方案嚴格強制在ContentID事件具有等於Ad-ID之類型時ContentID值可僅為一有效Ad-ID識別符值。又，XML方案強制在ContentID事件具有等於EIDR之類型時ContentID值可僅為一有效EIDR識別符值。查詢傳播屬性之基數係自0..N修改至0..1。發訊多個查詢傳播值可導致混淆接收器行為，因此至多僅發訊查詢傳播之1值。在一實例中，針對此之XML方案係：＜xs:element name="RecoveryData"＞＜xs:complexType＞＜xs:attribute name="querySpread" type="xs:string" use="optional"/＞＜/xs:complexType＞＜/xs:element＞針對未來擴展定義一擴展元素。類型「RecoveryExtType」之一RecoveryExt元素經定義以容許定義浮水印相關聯資訊之專屬擴展。在一實例中，以下XML方案可針對此定義。該擴展元素可如下定義為整個XML方案中之整體根元素或任何其他合適地方處之一子代元素：＜xs:element name="RecoveryExt" type="RecoveryExtType" minOccurs="0"/＞在一實例中，用於擴展元素RecoveryExtType之XML資料類型係：＜xs:complexType name="RecoveryExtType"＞＜xs:sequence＞＜xs:annotation＞＜xs:documentation＞恢復檔案格式之專屬擴展。要求不同名稱空間可用於專屬擴展。＜/xs:documentation＞＜/xs:annotation＞＜xs:any namespace="##other" processContents="skip" minOccurs="0" maxOccurs="unbounded"/＞＜/xs:sequence＞＜/xs:complexType＞現針對JSON方案描述使該方案可擴展之額外實例。圖17中展示用於浮水印相關聯之資訊擷取之一額外JSON方案。在該方案中包含針對JSON方案之可擴展性之支援以用於可擴展性。在圖17中之JSON方案中，與圖15中之JSON方案相比，對於可擴展性包含以下各者： (1)一頂級索引鍵(諸如RecoveryFF)經定義且圖17中之當前恢復檔案格式方案定義為針對此頂級索引鍵之一物件。因此，圖15中之方案可包裝在該頂級索引鍵內部。此藉由使用一JSON方案之「allOf」及「$ref」關鍵字而容許當前恢復檔案格式之可擴展性。 JSON關鍵字「allOf」(其以引用的方式併入本文)係在HTTP://tools.ietf.org/html/draft-fge-json-Schema-validation-00中予以定義。在一實例中，「allOf」定義給定資料可針對藉由一關鍵字值定義之所有方案有效。在一實例中，為針對「allOf」進行驗證，給定資料可針對藉由此關鍵字之值定義之所有方案有效。一方案之部分可係指使用$ref關鍵字。$ref在邏輯上由其指向之該方案部分取代。 (2)使索引鍵獨有。因此索引鍵(即使其等屬於不同物件)不具有相同索引鍵名稱。此促進可擴展性。進行擴展之一個實例係在定義一恢復檔案格式之一第二版本時。在此情況中可將新索引鍵及值對添加至一方案，同時為與圖17中之方案之回溯相容性保持舊索引鍵值對。當擴展圖17中之JSON方案時，以下類型之新索引鍵可經定義： "RecoveryFFV2": { "type": "object", "properties": { "V2": {"allOf": [ {"$ref": "#/RecoveryFF"}, { "properties": { "newkeyA": "valueA", "newkeyB": "valueB" }, "required": ["newkeyA"] } ]} } } 在一實例中，新索引鍵係「RecoveryFFV2」索引鍵。在此情況中藉由使用allOf關鍵字，資料可針對所有給定方案有效。 AllOf關鍵字內所包含之第一方案係{"$ref": "#/RecoveryFF"}，其係指用於如圖17中所展示之恢復檔案格式之第一版本之方案。接著包含如下用於恢復檔案格式之第二版本之方案之新索引鍵及值： { "properties": { "newkeyA": "valueA", "newkeyB": "valueB" }, "required": ["newkeyA"] } 因此用於恢復檔案格式之第二版本之整體例示性方案係如圖18中所展示。下文繪示用於提供一可擴展方案之一第二實例。在此實例中，藉由包含@context關鍵字而定義基於連結資料之JSON (JSON-LD)之擴展機制。JSON-LD係序列化連結資料之一格式。JSON-LD語法經設計以整合至已使用JSON之系統中且提供自JSON至JSON-LD之一升級路徑。JSON-LD主要意欲為在基於網頁之程式設計環境中使用連結資料、建置可互通網頁服務及將連結資料儲存於基於JSON之儲存引擎中之一方法。連結資料係跨不同文件及網站建立基於標準之機器可譯資料之一網路的一方法。此容許應用程式以一個連結資料片段開始且沿著嵌入鏈路至不同位點上擁有之其他連結資料片段。圖19展示用於一浮水印相關聯之資訊擷取之一JSON方案之一實例。在圖19中之JSON方案中，與圖15中之JSON方案相比，針對可擴展性添加以下各者： (1)一索引鍵(@context)經定義且圖19中之當前恢復檔案格式方案作為"RecoveryFF": HTTP://www.atsc.org/contexts/3.0/RecoveryFF包含在該索引鍵(@context)內部。該方案接著包裝在索引鍵「RecoveryFF」內部。 (2)使索引鍵獨有的，其中索引鍵不具有相同索引鍵名稱，即使其等屬於不同物件。此促進可擴展性。實現擴展之一個實例係定義恢復檔案格式之一第二版本。在此實例中，將新索引鍵及值對添加至一方案，同時為與圖19中之方案之回溯相容性保持舊索引鍵值對。當實現圖19中之JSON方案之一擴展時，可如下針對新索引鍵及值包含@context： { "RecoveryFF2": "HTTP://www.atsc.org/contexts/3.1/RecoveryFF" }, "RecoveryFF2": { "type": "object", "properties": { "newkeyA": "valueA", "newkeyB": "valueB" }, "required": ["newkeyA"] } 在此情況中新索引鍵係「RecoveryFF2」。針對該新索引鍵「RecoveryFF2」之新「@context」係 "RecoveryFF2": "HTTP://www.atsc.org/contexts/3.1/RecoveryFF" 在一實例中，用於恢復檔案格式之第二版本之方案之新索引鍵及值則為： "RecoveryFF2": { "type": "object", "properties": { "newkeyA": "valueA", "newkeyB": "valueB" }, "required": ["newkeyA"] } 圖20中展示用於恢復檔案格式之第二版本之整體例示性方案。在一實例中，當進行擴展時定義恢復檔案格式之一第二版本，可如下針對舊及新索引鍵及值包含僅一個新@context： "@context": { "RecoveryFF": "HTTP://www.atsc.org/contexts/3.1/RecoveryFF" }, 在此實例中，用於恢復檔案格式之此第二版本之新索引鍵及值係： "newkeyA": "valueA", "newkeyB": "valueB", 其等可與圖19中之方案之先前版本中之其他索引鍵及值一起包含。因此，在此實例中，藉由改變「@context」內部之「RecoveryFF」索引鍵之值，新舊索引鍵及值可如圖21中所展示般包含在一起。因此用於一恢復檔案格式之整體方案係如圖21中所展示。現提供恢復檔案格式結構之替代實例。在圖22中展示恢復檔案格式表之一替代邏輯結構。在圖23中展示組件描述之邏輯結構。在圖24A、圖24B及圖24C中展示組件錨之三個不同邏輯結構。參考圖22，如下描述各種元素之語義。 ThisComponent- 嵌入有一浮水印之媒體組件之一描述。 serverCode-當存在時，此元素可提供HTTP請求中所採用的serverCode值，此恢復檔案作為對HTTP請求之一回應而提供。 intervalCode-當存在時，此元素可自查詢請求提供intervalCode值，恢復資料表作為對該查詢請求之一回應而提供。 ComponentDescription- 以圖23中所定義之格式描述ThisComponent之一資料元素。 querySpread-當存在時，此元素可表示建議接收器延遲提交一HTTP請求之最大持續時間。 OtherComponent-以圖23中所定義之格式描述與相同於ThisComponent之服務相關聯之另一加浮水印之媒體組件之一元素。 ContentID-此欄位可識別一內容識別符。代替使用一ContentID List容器物件，ContentID物件陣列係藉由0..N而非1..N之有效基數(即，該陣列中之0至N個項目)予以定義。此藉由不需要一容器物件(其增加更多剖析複雜性)而容許更容易剖析JSON資料且簡化整體資料結構，同時仍維持所要靈活性。 ContentID.type-在包含ContentId元素時較佳需要之一欄位。兩個值可經定義：「EIDR」指示依據EIDR記錄之一內容識別。「Ad-ID」指示依據Ad-ID記錄之一內容識別符。 ContentID.cid-在包含ContentId元素時使用之提供內容識別之一欄位。內容識別符之類型可如ContentID.type屬性中所給出。可包含一EIDR (具有連字符之34字元規範形式)或Ad-ID (11字元或12字元規範形式)。 ContentID.validFrom-提供關於ContentId從何時起有效之資訊之一欄位。 ContentID.validUntil-提供關於ContentId有效至何時之資訊之一欄位。 SourceID-描述採用ATSC發射規範之一分配源之一元素。此元素適用於在根據ATSC發射規範廣播之一服務之重新分配中包含加浮水印之內容的境況。 country-與主要管理實體相關聯之國家碼，在該主要管理實體下使用如ISO 3166-1中所定義之適用alpha-2國家碼格式指派bsid中所提供之值。可於http://webstore.ansi.org/RecordDetail.aspx?sku=ISO%203166-1:2013獲得之ISO 3166-1係以引用的方式併入本文。bsid- ATSC分配源之廣播服務識別符(BSID)。 majorChannelNo-指派給ATSC分配源之主要頻道號碼。此值約制於(scoped to)BSID。 minorChannelNo-指派給ATSC分配源之次要頻道號碼。此值約制於BSID。 Service-此元素描述服務、其發訊格式及寬帶位置。 serviceId-可唯一地識別此廣播區域之範疇內之此服務的16位元整數。 sltSvcSeqNum-此整數可指示具有等於上文之serviceId屬性之服務識別符之服務資訊之序列號。sltSvcSeqNum值可針對各服務開始於0且每當此服務元素之任何屬性或子代元素改變時可遞增1。若相較於具有serviceID之一特定值之先前服務元素，屬性或子代元素值未改變，則sltSvcSeqNum可不遞增。sltSvcSeqNum欄位可在達到最大值之後繞回至0。 slsProtocol-指定與此服務相關聯之發訊格式。 slsMajorProtcolVersion-用於slsProtocol中所指定之發訊協定之主要版本號碼。 slsMinorProtocolVersion-用於slsProtocol中所指定之發訊協定之次要版本號碼。 svcInetUrl-提供關於經由寬帶存取用於此服務之ESG或服務層級發訊檔案之URL的資訊(若可用)。 URLtype-可用svcInetUrl提供之檔案之類型。 URLValue-存取用於藉由服務識別符serviceId識別之此服務之網際網路發訊檔案之URL。 URL值性質(URLValue)經定義以用於指示涵蓋服務網際網路URL相關性質之一容器物件內部之服務網際網路URL值。URLtype可為服務網際網路URL之一所需性質(而非選用性質)，因為原本將不會知道發訊之URL類型。關於圖23，如下描述各種元素之語義。 ComponentDescription- 提供與一服務相關聯之一加浮水印之媒體組件之一描述。 ComponentAnchor-關於加浮水印之媒體組件中之第一有效負載的資訊，如圖24A或圖24B或圖24C中所定義。 mediaType-具有用以指示描述僅應用於一音訊組件之值「音訊」、用以指示描述僅應用於一視訊組件之值「視訊」或用以指示描述應用於一音訊組件及一視訊組件兩者之值「兩者」之一字串。 descriptor-與意欲藉由一應用程式消費之加浮水印之媒體組件相關聯的一任意描述性字串。 priority-指示所描述組件之相對優先級之一數值。當對於一組件未指示優先級值時，其優先級可為0。關於圖24A，如下描述各種元素之語義。 ComponentAnchor-指定一視訊或音訊浮水印分段中之第一有效負載之特性的一元素。 intervalCodeAnchor-一視訊或音訊浮水印分段中之第一有效負載中之intervalCode。 PresentationTime- 視訊浮水印分段中之第一訊息塊之第一訊框之時鐘呈現時間，或對於音訊組件，音訊浮水印分段之第一單元中之第一符號之第一樣本之時鐘呈現時間。下文如圖25A至圖25D展示用於具有圖22、圖23、圖24A中所展示之邏輯結構之恢復檔案格式的JSON方案。關於JSON方案，在一替代實例中，可依一資料類型而非類型「字串」發訊presentationTime。例如，可使用類型「數字」。在此情況中，關於圖24，對應JSON方案部分將為如下： "presentationTime": {"type": "number"}而非為“"presentationTime": {"type": "string"} 在一替代實例中，可依一資料類型而非類型「字串」發訊presentationTime。例如，可使用類型「整數」。在此情況中，參考圖24，對應JSON方案部分將為如下： "presentationTime": {"type": "integer"}而非為“"presentationTime": {"type": "string"} 關於恢復檔案格式邏輯結構，在一替代實例中，在容器SourceID元素內可使用一父代元素ATSCSourceID及另外一選項選擇。此可容許在未來除ATSC外定義源識別符。恢復檔案格式邏輯結構之此部分可如下展示。

在此情況中SourceID及ATSCSourceID之語義可為如下： SourceID-描述加浮水印之內容所歸屬之一分配源之一元素。 ATSCSourceID-描述採用ATSC發射規範之一分配源之一元素。此元素適用於在根據ATSC發射規範廣播之一服務之重新分配中包含加浮水印之內容的境況。在此情況中對應於此之JSON方案之部分可如下展示。 "SourceID": { "type": "object", "properties": { "oneOf": [ { "ATSCSourceID": { "type": "object", "properties": { "country": {"type": "string","pattern": "^[a-zA-Z]{2}$"}, "bsid": { "type": "integer","minimum": 0, "maximum": 65535 }, "majorChannelNo":{"type": "integer","minimum": 1, "maximum": 999 }, "minorChannelNo":{"type": "integer","minimum": 1, "maximum": 999 } } }, "required": ["country","bsid","majorChannelNo","minorChannelNo"] }]}}, 圖24B中展示用於組件錨之替代例示性邏輯結構。圖24B與圖24A之間的主要差異在於，定義兩個元素或索引鍵或性質presentationTime及presentationTimeMsec，而非定義一單一presentationTime元素或索引鍵或性質來表示呈現時間。關於圖24B，如下描述各種元素之語義。 ComponentAnchor-指定一視訊或音訊浮水印分段中之第一有效負載之特性的一元素。 intervalCodeAnchor-一視訊或音訊浮水印分段中之第一有效負載中之intervalCode。 PresentationTimeInteger-整數部分-視訊浮水印分段中之第一訊息塊之第一訊框之64位元網路時間協定(NTP)格式化之時鐘呈現時間之前32個位元，或對於音訊組件，音訊浮水印分段中之第一單元中之第一符號之第一樣本之時鐘呈現時間。 PresentationTimeFraction-小數部分-視訊浮水印分段中之第一訊息塊之第一訊框之64位元NTP格式化之時鐘呈現時間之後32個位元，或對於音訊組件，音訊浮水印分段中之第一單元中之第一符號之第一樣本之時鐘呈現時間。在此32位元小數部分中非有效低階位元可設定為0。如圖26A至圖26D展示用於具有圖22、圖23、圖24B中所展示之邏輯結構之恢復檔案格式之JSON方案。圖24C中展示用於組件錨之替代例示性邏輯結構。圖24C與圖24A之間的主要差異在於，定義兩個元素或索引鍵或性質presentationTime及presentationTimeMsec，而非定義一單一presentationTime元素或索引鍵或性質來表示呈現時間。關於圖24C，如下描述各種元素之語義。 ComponentAnchor-指定一視訊或音訊浮水印分段中之第一有效負載之特性之一元素。 intervalCodeAnchor-一視訊或音訊浮水印分段中之第一有效負載之intervalCode。 PresentationTime-此32位元不帶正負號整數可指示視訊浮水印分段中之第一訊息塊之第一訊框之呈現時間，或對於音訊組件，作為自國際原子時間(TAI) 1970年1月1日00:00:00起之秒數之計數之最低有效32個位元。 PresentationTimeMsec- 在0至999範圍中之此10位元不帶正負號整數可指示自PresentationTime中指示之時間之毫秒偏移，使得公式PresentationTime + (PresentationTimeMsec /1000)產生視訊浮水印分段中之第一訊息塊之第一訊框之實際呈現時間，或對於音訊組件，最接近1毫秒。(PresentationTimeMsec /1000)意謂PresentationTimeMsec除以1000。如圖27A至圖27D展示用於具有圖22、圖23、圖24C中所展示之邏輯結構之恢復檔案格式之JSON方案。圖28中展示恢復檔案格式表之一替代邏輯結構。圖29中展示組件描述之邏輯結構。圖30中展示組件錨之邏輯結構。圖31繪示用於圖28中之恢復檔案格式之例示性slsProtocol值。圖32繪示用於圖28中之恢復檔案格式之例示性urlType值。關於圖28，如下描述各種元素之語義。 thisComponent-嵌入有含有VP1有效負載(其含有serverCode及intervalCode)之一浮水印之媒體組件之一描述。VP1有效負載係50位元音訊浮水印有效負載資料之特定配置。 serverCode-當存在時，此元素可提供HTTP請求中所採用之serverCode值，此恢復檔案作為對HTTP請求之一回應而提供。 intervalCode-當存在時，此元素可自查詢請求提供該intervalCode值，恢復資料表作為對該查詢請求之一回應而提供。 componentDescription-以圖29中所定義之格式描述thisComponent之一資料元素及其後接著之參數描述。 querySpread-當存在時，此元素可表示建議接收器延遲提交一動態事件HTTP請求之以1毫秒為單位之最大持續時間。期望接收器將應用足夠小的粒度級別以實現跨querySpread持續時間(諸如1毫秒)之一均勻查詢傳播。 otherComponent-以圖25A至圖25D及隨後之參數描述中所定義之格式描述與相同於ThisComponent之服務相關聯之另一加浮水印之媒體組件之一元素。 contentID-此欄位可識別一內容識別符。 contentID.type-用於此Content ID之Content ID系統之類型。當前藉由ATSC定義三個值：「EIDR」指示依據EIDR記錄之一內容識別，如(http://eidr.org)中所定義。「Ad-ID」指示依據Ad-ID記錄之一內容識別符，如(http://ad-id.org)中所定義。「UserPriv」指示一使用者私用內容識別符。在未來可藉由ATSC定義額外Content ID系統類型。對於「UserPriv」內容識別符，值得注意的是，contentID.cid係在此廣播串流中出現之Content ID系統類型中獨有。用於contentID.type之一替代語義可為如下：用於此Content ID之Content ID系統之類型。可(例如)藉由ATSC定義兩個值：「EIDR」指示依據EIDR記錄之一內容識別(http://eidr.org)。「Ad-ID」指示依據Ad-ID記錄之一內容識別符(http://ad-id.org)。可定義用於使用者私用內容識別符之額外類型。此等可使用一首碼「x-」指示一使用者私用內容識別符類型。可藉由ATSC定義額外Content ID系統類型。對於使用者私用內容識別符類型，用於此等系統之contentID.type較佳不複製藉由ATSC定義之任何Content ID系統類型且在廣播串流中出現之Content ID系統類型中獨有。應注意，可使用任何其他指定首碼，來代替需要使用「x-」作為使用者私用內容識別符之首碼。例如，可指定使用首碼「UserPriv-」。又，可使用術語「私用內容識別符」來代替「使用者私用內容識別符」。 contentID.cid-在包含contentID元素時需要之提供內容識別之一欄位。在EIDR Content ID系統之情況中，此可為識別符之34字元規範形式(具有連字符)。在Ad-ID Content ID系統之情況中，此可為識別符之11字元或12字元規範形式。在一UserPriv Content ID系統(例如，門牌號、ISCI等)之情況中，識別符之格式係藉由該系統之規格所判定。門牌號可包含廣播台特定私用內容識別符。例如，廣播公司A可使用其等私用內容識別符作為其等私用門牌號且廣播公司B可使用其等私用內容識別符作為其等私用門牌號。業界標準編碼識別(ISCI)係經建立以自1970年至2004年為廣告代理商及廣告商識別美國電視上播出之商業廣告之一標準。其在2005年由Ad-ID取代。用於contentID.值之一替代語義可為如下： contentID.cid-在包含contentID元素時使用之提供內容識別之一欄位。在EIDR Content ID系統之情況中，此可為識別符之34字元規範形式(具有連字符)。在Ad-ID Content ID系統之情況中，此可為識別符之11字元或12字元規範形式。在一使用者定義之Content ID類型(具有首碼「x-」用於contentID.type)或任何其他ATSC私用Content ID系統(例如，門牌號)之情況中，識別符之格式可藉由系統之規格所判定。 contentID.validFrom-contentID值之有效期之起始時間。 contentID.validUntil-contentID值之有效期之結束時間。 sourceID-描述採用ATSC發射規範之一歸屬分配源之一元素。此元素適用於在根據ATSC規範廣播之一服務之重新分配中包含加浮水印之內容的境況。 country-與主要管理實體相關聯之國家碼，在該主要管理實體下使用如ISO 3166-1中所定義之適用alpha-2國家碼格式指派下面bsid欄位中所提供之值。ISO 3166-1係在ISO: ISO 3166-1:2013 (E/F)，國際標準化組織2013年11月13日第3版「用於表示國家及其分支機構之名稱之碼-部分1：Country碼」中予以定義，且其全部內容以引用的方式併入本文。 Bsid-歸屬ATSC分配源之BSID。 majorChannelNo-指派給歸屬ATSC分配源之主要頻道號。此值約制於BSID。 minorChannelNo-指派給歸屬ATSC分配源之次要頻道號。此值約制於BSID。 Service-此元素描述服務、其發訊格式及寬帶位置。 serviceId-可唯一地識別此廣播區域之範圍內之此服務的16位元整數。 sltSvcSeqNum-此整數可指示具有等於上文之serviceId屬性之服務ID之服務清單表(SLT)服務資訊之序列號。sltSvcSeqNum值針對各服務可開始於0且每當此服務元素之任何屬性或子代元素改變時可遞增1。若相較於具有serviceID之一特定值之先前服務元素，屬性或子代元素值未改變，則sltSvcSeqNum可不遞增。sltSvcSeqNum欄位可在達到最大值之後繞回至0。 SLT係發訊資訊之一表，其用於建置一基本服務清單並提供發訊之發現，該發訊提供用於獲取ATSC 3.0服務及其等內容組件之資訊。 slsProtocol-指定與此服務相關聯之發訊格式，其中經准許值及其等含義如圖31中所展示。 slsMajorProtcolVersion-用於slsProtocol中所指定之發訊協定之主要版本號碼。 slsMinorProtocolVersion-用於slsProtocol中所指定之發訊協定之次要版本號碼。 svcInetUrl-經由寬帶存取用於此服務之電子服務導引(ESG)或服務層級發訊檔案之基本URL (若可用)。 urlType-可用svcInetUrl提供之檔案類型，具有如圖32中所展示之准許值及其等含義。 urlValue-存取用於藉由服務識別符serviceId識別之此服務之網際網路發訊檔案之URL。如圖33A至圖33E展示用於具有圖28中所展示之邏輯結構之恢復檔案格式之一例示性JSON方案。如圖34A至圖34D展示用於具有圖28中所展示之邏輯結構之恢復檔案格式之另一例示性JSON方案。如圖35A至圖35E展示用於具有圖28中所展示之邏輯結構之恢復檔案格式之另一例示性JSON方案。圖35A至圖35E中之方案在該等情況之一者中容許任何「字串」資料類型值用於「類型」欄位。此容許定義額外ATSC所定義之內容ID類型及使用者私用內容ID類型。在又另一實例中，可藉由如下定義一資料類型而在方案中強制關於將首碼「x-」用於使用者私用內容識別符的要求： "cid": { "type": "string", "pattern": "^x-", }, 圖33A至圖33E及圖34中之JSON方案之間的一差異係關於contentID.type與contentID.cid性質之語義之一差異。對於圖34A至圖34D中之方案，性質contentID.type與contentID.cid之語義可為如下： contentID.type-用於此Content ID之Content ID系統之類型。當前藉由ATSC定義以下值：「EIDR」指示依據EIDR記錄之一內容識別，如(http://eidr.org)中所定義。「Ad-ID」指示依據Ad-ID記錄之一內容識別符，如(http://ad-id.org)中所定義。在未來可藉由ATSC定義額外Content ID系統類型。使用(或可在本文出現)使用者定義之Content ID系統類型之一合適縮寫詞。當此進行時，值得注意的是，該縮寫詞在此廣播串流中出現之Content ID系統類型中係獨有的。 contentID.cid-Content ID值。在EIDR Content ID系統之情況中，此可為識別符之34字元規範形式。在Ad-ID Content ID系統之情況中，此可為識別符之11字元或12字元規範形式。在一使用者私用Content ID系統(例如，門牌號、ISCI等)之情況中，識別符之格式係藉由該系統之規格所判定。圖33A至圖33E及圖34A至圖34D中之JSON方案包含作為物件contentID之方案之部分之以下項： "type": "array", "items": { "type": "object", "properties": {"oneOf": [ { … }, { … }, … {"type": "object"} ]} }, "minItems": 0 }, 其中「…」指示如圖33A至圖33E及圖34A至圖34D中所展示之在本文省略之不同JSON方案部分。在此情況中，包含{"type": "object"}作為方案之部分提供未來可擴展性。包含{“type”:”object”}作為contentID物件之方案之部分除必須遵守EIDR或AD-ID或「userPriv」之方案性質之contentID之明確定義之經約束方案語法之外，亦容許用於contentID物件之一自由形式JSON物件。此物件之語法可在未來予以定義。因此此支援未來可擴展性。在此情況中接收器之當前版本可跳過一通用JSON物件。又在另一使用實例中，圖34A至圖34D中之在contentID物件內部包含{“type”:”object”}之方案可用作包含任何不同私用內容id值之另一方法。圖36繪示一例示性恢復檔案格式邏輯結構。圖28與圖36之間的一差異在於支援一緊緻Ad-ID形式。在此形式中Ad-ID可表示為表示4位元組不帶正負號整數緊緻Ad-ID識別符之十進制值之ASCII字元。如圖37A至圖37E中展示用於具有圖36中所展示之邏輯結構之恢復檔案格式之另一例示性JSON方案。圖37A至圖37E中之方案容許用於內容識別符之Ad-ID類型之一額外型樣項目，其容許Ad-ID表示為表示4位元組不帶正負號整數緊緻Ad-ID之十進制值之ASCII字元。在一實例中，此係藉由定義憑藉對各個別型樣執行一邏輯OR運算而建立之一型樣來完成。在一個實例中，方案之此部分可如下展示。 "cid": { "type": "string", "pattern": "^[1-9a-zA-Z]{1}[0-9a-zA-Z]{10}(H|D)? |^[0-9]{1,10}$", "maxLength": 12 }, 如圖38A至圖38J展示用於具有圖36中所展示之邏輯結構之恢復檔案格式之另一例示性JSON方案。在此情況中可如下修改圖36中之一些語法元素之語義： contentID.type-在包含contentId元素時需要之一欄位。當前定義兩個值：「urn:eidr」指示依據EIDR記錄之一內容識別(http://eidr.org)。用於如SMPTE 2092-1中所定義之「全」編碼或「緊緻」編碼之「Designator」指示依據Ad-ID記錄之一內容識別符(http://ad-id.org)。2015年出版之電影電視工程師協會之RP 2092-1的SMPTE：「廣告數位識別符(Ad-ID (註冊商標))表示」在此文件中被稱為「SMPTE 2092-1」且其全部內容以引用的方式併入本文中。可藉由將此欄位設定為如IETF RFC 4151之章節2.1中所定義之taggingEntity符記(例如，「atsc.org,2016」)而使用使用者私用內容識別符之額外類型。IETF RFC 4151可於https://www.ietf.org/rfc/rfc4151.txt獲得且其全部內容以引用的方式併入本文中。在未來可藉由ATSC定義額外Content ID系統類型。 contentID.cid-在包含ContentId元素時需要之提供內容識別之一欄位。在以下情況中：「urn:eidr」：EIDR Content ID系統，此將為如2013年出版之電影電視工程師協會之RP 2079-2013之SMPTE：「數位物件識別符(DOI)名稱及娛樂ID記錄(EIDR)識別符表示」(其全部內容以引用的方式併入本文中)中所定義之識別符之34字元規範形式(具有連字符)。用於如「SMPTE 2092-1」Ad-ID Content ID系統中所定義之「全」編碼或「緊緻」編碼之「Designator」，此將為表示4位元組不帶正負號整數緊緻Ad-ID識別符之十進制值之11字元或12字元規範形式或ASCII字元。對於其他域名，此欄位並非藉由ATSC定義。識別符之格式係藉由系統之規格所判定。與圖37A至圖37E中之方案相比，圖38A至圖38J中之方案包含以下改變：在圖37A至圖37E方案中，僅使用「ad-id.org,2016」之單一URN發訊Ad-ID「類型」之「全」形式及「緊緻」形式。與圖38A至圖38J中之此相比，兩個單獨URN (一個用於全形式且另一個用於緊緻形式)係用於兩個「類型」。在圖37A至圖37E方案中，用於單一「類型」之「cid」係兩個可能Ad-ID值(全值或緊緻值)之一邏輯OR (||)。與圖38A至圖38J中之此相比，可僅用「全」類型URN發訊全Ad-ID值且可用「緊緻」類型URN發訊緊緻Ad-ID值。又，在圖38A至圖38J方案中，相較於圖37A至圖37E方案對於「緊緻」形式改變maxLength限制。此容許更有效剖析「緊緻」形式值。關於圖38A至圖38J中之方案，應注意，可使用某一其他URN值來代替所指定之URN值。特定言之：在圖38A至圖38J中可使用實例「urn:smpte:ul:060E2B34.0101010C.0101110B.00000000」之另一URN或實例「urn:smpte:ul:060e2b34.01040101.01100200.00000000」之另一URN或某一其他URN或URI來代替「全」Ad-ID之「urn:smpte:ul:060E2B34.01040101.01200900.00000000」。在圖38A至圖38J中可使用實例「urn:smpte:ul:060e2b34.01040101.01010300.00000000」之另一URN或實例「urn:smpte:ul:060E2B34.0101010E.0101110E.00000000」之另一URN或某一其他URN或URI來代替「緊緻」Ad-ID之「urn:smpte:ul:060E2B34.01040101.01012009.00000000」在參考圖17、圖18、圖19、圖20、圖21、圖25A至圖25D、圖26A至圖26D、圖27A至圖27D、圖28、圖29、圖30、圖31、圖32的進一步可擴展性之實例中，JSON方案可藉由additionalProperties: true予以定義。在參考圖17、圖18、圖19、圖20、圖21、圖25A至圖25D、圖26A至圖26D、圖27A至圖27D、圖28、圖29、圖30、圖31、圖32的進一步可擴展性之防止改變方案之其他實例中，JSON方案可藉由additionalProperties: false予以定義。關於各種JSON方案，在一替代實例中元素或索引鍵或性質中之一些之資料類型可不同於方案中所指示之該等資料類型。例如，可使用一資料類型「整數」或「數字」或「布林值」或「陣列」或「物件」來代替資料類型「字串」。類似地，可代替性地發訊任何其他JSON資料類型作為任何其他JSON資料類型。結合［實施方式］中之實例期望所有此等變動。此外，可由一電路實施或執行用於前述實施例之各者中之基地台裝置及終端裝置之各功能區塊或各種特徵，該電路通常係一積體電路或複數個積體電路。經設計以執行本說明書中所描述之功能之電路可包括一通用處理器、一數位信號處理器(DSP)、一專用或通用積體電路(ASIC)、一場可程式化閘陣列(FPGA)或其他可程式化邏輯裝置、離散閘或電晶體邏輯或一離散硬體組件或其等之一組合。通用處理器可為一微處理器，或替代性地，處理器可為一習知處理器、一控制器、一微控制器或一狀態機。通用處理器或上文所描述之各電路可由一數位電路進行組態，或可由一類比電路進行組態。此外，當歸因於一半導體技術之進步而出現製造替代當前積體電路之一積體電路之一技術時，亦能夠使用藉由此技術製造之積體電路。應理解，發明申請專利範圍並不限於上文所繪示之精確組態及組件。可在不脫離發明申請專利範圍之範疇的情況下在本文所描述之系統、方法及設備之配置、操作及細節中進行各種修改、改變及變動。

100‧‧‧內容源120‧‧‧服務提供伺服器130‧‧‧多頻道視訊節目分配者(MVPD)140‧‧‧增強型服務資訊提供伺服器160‧‧‧廣播接收裝置170‧‧‧網路180‧‧‧視聽(AV)呈現裝置190‧‧‧浮水印插入器201‧‧‧增強型服務資料203‧‧‧增強型服務資料205‧‧‧加浮水印之視聽(AV)206‧‧‧未經壓縮之視聽(AV)207‧‧‧視聽(AV)208‧‧‧視聽(AV)209‧‧‧請求211‧‧‧回覆300‧‧‧碼310‧‧‧具備浮水印能力之接收器320‧‧‧浮水印用戶端350‧‧‧後設資料伺服器351‧‧‧碼353‧‧‧後設資料355‧‧‧請求357‧‧‧選定內容及發訊360‧‧‧後設資料370‧‧‧碼資料庫380‧‧‧內容及發訊伺服器390‧‧‧(若干)發訊伺服器400‧‧‧內容伺服器

圖1繪示具有增強型服務資訊之一系統。圖2繪示具有增強型資訊之另一系統。圖3繪示具有增強型資訊之一系統之一資料流。圖4繪示具有增強型資訊之另一系統。圖5繪示一浮水印有效負載。圖6繪示另一浮水印有效負載。圖7繪示浮水印有效負載之間的關係。圖8繪示浮水印有效負載之間的關係。圖9繪示浮水印有效負載之間的關係。圖10繪示具有增強型資訊之另一系統。圖11繪示獲得同步並維持同步。圖12繪示另一浮水印有效負載。圖13繪示一標準制定組織(SDO)私用資料。圖14繪示使用一或多個cmdID囊封於SDO私用資料內作為一SDO有效負載之後設資料。圖15繪示一例示性JavaScript物件標記法方案。圖16A繪示一JavaScript物件標記法方案之邏輯結構。圖16B繪示一JavaScript物件標記法方案之邏輯結構。圖16C繪示一JavaScript物件標記法方案之邏輯結構。圖16D繪示一JavaScript物件標記法方案之邏輯結構。圖17繪示一例示性浮水印相關聯之資訊擷取JavaScript物件標記法方案。圖18繪示一例示性恢復檔案格式JavaScript物件標記法方案。圖19繪示一例示性浮水印相關聯之資訊擷取JavaScript物件標記法方案。圖20繪示一例示性恢復檔案格式JavaScript物件標記法方案。圖21繪示一例示性恢復檔案格式JavaScript物件標記法方案。圖22繪示一例示性恢復檔案格式邏輯結構。圖23繪示一例示性組件描述邏輯結構。圖24A繪示一例示性組件錨邏輯結構。圖24B繪示一例示性組件錨邏輯結構。圖24C繪示一例示性組件錨邏輯結構。圖25A繪示一例示性恢復檔案格式JavaScript物件標記法方案。圖25B繪示圖25A之下一部分。圖25C繪示圖25B之下一部分。圖25D繪示圖25C之下一部分。圖26A繪示一例示性恢復檔案格式JavaScript物件標記法方案。圖26B繪示圖26A之下一部分。圖26C繪示圖26B之下一部分。圖26D繪示圖26C之下一部分。圖27A繪示一例示性恢復檔案格式JavaScript物件標記法方案。圖27B繪示圖27A之下一部分。圖27C繪示圖27B之下一部分。圖27D繪示圖27C之下一部分。圖28繪示一例示性恢復檔案格式邏輯結構。圖29繪示一例示性組件描述邏輯結構。圖30繪示一例示性組件錨邏輯結構。圖31繪示例示性slsProtocol值。圖32繪示例示性urlType值。圖33A繪示一例示性恢復檔案格式JavaScript物件標記法方案。圖33B繪示圖33A之下一部分。圖33C繪示圖33B之下一部分。圖33D繪示圖33C之下一部分。圖33E繪示圖33D之下一部分。圖34A繪示一例示性恢復檔案格式JavaScript物件標記法方案。圖34B繪示圖34A之下一部分。圖34C繪示圖34B之下一部分。圖34D繪示圖34C之下一部分。圖35A繪示一例示性恢復檔案格式JavaScript物件標記法方案。圖35B繪示圖35A之下一部分。圖35C繪示圖35B之下一部分。圖35D繪示圖35C之下一部分。圖35E繪示圖35D之下一部分。圖36A繪示一例示性恢復檔案格式邏輯結構。圖36B繪示圖36A之下一部分。圖37A繪示一例示性恢復檔案格式JavaScript物件標記法方案。圖37B繪示圖37A之下一部分。圖37C繪示圖37B之下一部分。圖37D繪示圖37C之下一部分。圖37E繪示圖37D之下一部分。圖38A繪示一例示性恢復檔案格式JavaScript物件標記法方案。圖38B繪示圖38A之下一部分。圖38C繪示圖38B之下一部分。圖38D繪示圖38C之下一部分。圖38E繪示圖38D之下一部分。圖38F繪示圖38E之下一部分。圖38G繪示圖38F之下一部分。圖38H繪示圖38G之下一部分。圖38I繪示圖38H之下一部分。圖38J繪示圖38I之下一部分。

100‧‧‧內容源

120‧‧‧服務提供伺服器

130‧‧‧多頻道視訊節目分配者(MVPD)

140‧‧‧增強型服務資訊提供伺服器

160‧‧‧廣播接收裝置

170‧‧‧網路

180‧‧‧視聽(AV)呈現裝置

Claims

一種用於藉由依據一經提取浮水印自一提供者接收一補充內容而恢復該補充內容之方法包括以下步驟：(a)接收呈一恢復檔案格式之一恢復資料表；(b)依據該恢復資料表接收該補充內容該恢復資料表包含：(1)一contentID欄位，其描述關於一訊息中所提供之一內容識別符之資訊，該內容識別符指示：用以識別該補充內容之資訊及對於該內容識別符建立之有效期；及(2)媒體組件之一描述，該媒體組件嵌入有含有一有效負載之一浮水印；該contentID欄位包含：(1)一type欄位，其描述內容識別符之一類型是否為娛樂識別符暫存器(EIDR)類型或廣告識別符(Ad-ID)類型，且定義該補充內容之一統一資源名稱；(2)ContentID欄位值之一欄位，其描述一廣告識別符且其中ContentID欄位值之該欄位具有一最大長度10；(3)一valid from欄位，其描述內容識別符從何時起有效；及(4)一valid until欄位，其描述內容識別符有效至何時；該媒體組件之該描述包含：(1)一整數，其具有匹配該有效負載中之一queryFlag值之0或1之一值；及 (2)一整數，其具有指示一顯示置換狀態關聯至該有效負載是否有效之0或1之一值。
如請求項1之方法，其中該統一資源名稱係060E2B34.01040101.01012009.00000000。
如請求項1之方法，其中該統一資源名稱係060E2B34.01040101.01200900.00000000。
如請求項1之方法，其中該恢復資料表係呈符合一java script物件標記法(JSON)方案之一java script物件標記法(JSON)格式。
如請求項1之方法，其中該恢復檔案格式係使用一第一介面接收且該補充內容係使用一第二介面接收。
如請求項1之方法，其中該補充內容係在該接收之後呈現。
一種用於藉由依據一經提取浮水印自一提供者接收一補充內容而恢復該補充內容之接收器，其包括以下步驟：(a)該接收器接收呈一恢復檔案格式檔案之一恢復資料表；(b)該接收器依據該恢復資料表接收該補充內容；該恢復資料表包含：(1)一contentID欄位，其描述關於一訊息中所提供之一內容識別符之資訊，該內容識別符指示：定義該補充內容之資訊及對於該內容識別符建立之有效期；及(2)媒體組件之一描述，該媒體組件嵌入有含有一有效負載之一浮水印；該contentID欄位包含：(1)一type欄位，其描述內容識別符之一類型是否為娛樂識別符暫存器(EIDR)類型或廣告識別符(Ad-ID)類型，且定義該補充內容之一統一資源名稱；(2)ContentID欄位值之一欄位，其描述一廣告識別符且其中ContentID欄位值之該欄位具有一最大長度10；(3)一valid from欄位，其描述內容識別符從何時起有效；及(4)一valid until欄位，其描述內容識別符有效至何時；該媒體組件之該描述包含：(1)一整數，其具有匹配該有效負載中之一queryFlag值之0或1之一值；及(2)一整數，其具有指示一顯示置換狀態關聯至該有效負載是否有效之0或1之一值。
如請求項7之接收器，其中該統一資源名稱係060E2B34.01040101.01012009.00000000。
如請求項7之接收器，其中該統一資源名稱係060E2B34.01040101.01200900.00000000。
如請求項7之接收器，其中該恢復資料表係呈符合一java script物件標記法(JSON)方案之一java script物件標記法(JSON)格式。
如請求項7之接收器，其中該恢復檔案格式係使用一第一介面接收且該補充內容係使用一第二介面接收。
如請求項7之接收器，其中該補充內容係在該接收之後呈現。