本公開涉及接收設備、發(fā)送設備和數據處理方法。更具體地,本公開涉及例如經由廣播波或網絡進行數據接收的接收設備,例如經由廣播波或網絡進行數據發(fā)送的發(fā)送設備,以及用于數據通信的數據處理方法。
背景技術:
已經積極進行下述系統(tǒng)的開發(fā)和標準化,在該系統(tǒng)中,通過使用廣播波等的單向通信或通過經由網絡(諸如因特網等)的雙向或單向通信,在提供內容的發(fā)送設備(諸如廣播站或內容服務器)和接收設備(諸如電視、pc或移動終端)之間進行內容(諸如廣播節(jié)目)的發(fā)送和接收。
注意,在例如專利文獻1(日本專利申請公開no.2014-057227)中公開了這樣的相關技術:經由廣播波和網絡實現數據傳送的技術。
高級電視系統(tǒng)委員會(atsc)3.0的標準化已經作為與經由廣播波和網絡的數據傳送系統(tǒng)相關的標準之一。
在atsc3.0中,用于下載類型應用傳送管理的封包方案和離線應用注冊/更新管理方案仍在審查中。
同時,作為萬維網(www)使用技術的國際標準化組織的萬維網聯盟(w3c)正在開發(fā)服務工作者(sw)的規(guī)范,該規(guī)范包括用于實現便于客戶端使用應用的控制程序等。
為了在客戶端(廣播內容的接收設備)中實現服務工作者(sw)的框架的有效使用,需要能夠有效地管理傳送管理(其為廣播和傳送的應用部分)和服務工作者(sw)。
引用列表
專利文獻
專利文獻1:日本專利申請公開no.2014-057227
技術實現要素:
本發(fā)明待解決的問題
本公開的目的在于提供一種接收設備、發(fā)送設備和數據處理方法,它們能夠在用作廣播內容接收設備的客戶端中實現服務工作者(sw)框架的有效使用。
此外,具體地,本發(fā)明目的在于提供一種接收設備、發(fā)送設備和數據處理方法,它們能夠使用被應用至確定處理的控制信息來實現例如傳送控制,該確定處理用于確定在接收設備處是經由廣播還是經由網絡進行數據獲取。
問題的解決方案
根據本公開的第一方面,提供了接收設備,包括數據處理單元,接收其中記錄了類信息的信令數據,并且根據類信息確定是經由廣播還是經由網絡進行數據接收,所述類信息用于指示允許經由網絡進行數據接收的一組接收設備或用戶。
另外,根據本公開的第二方面,提供發(fā)送信令數據的發(fā)送設備,在該信令數據中記錄了類信息,所述類信息用于指示允許經由網絡進行數據接收的一組接收設備或用戶。
另外,根據本公開的第三方面,
提供了在接收設備中進行的數據處理方法,該方法包括:
由通信單元接收其中記錄了類信息的信令數據,所述類信息用于指示允許經由網絡進行數據接收的一組接收設備或用戶;和
由數據處理單元根據類信息確定是經由廣播還是經由網絡進行數據接收。
另外,根據本公開的第四方面,
提供了在發(fā)送設備中進行的數據處理方法,該方法包括:
發(fā)送其中記錄了類信息的信令數據,所述類信息用于指示允許經由網絡進行數據接收的一組接收設備或用戶。
通過基于接下來描述的本公開的實施例的具體實施方式和附圖,本公開的其他目的、特征和優(yōu)點將變得顯而易見。需注意,在本說明書中,系統(tǒng)是多個設備的邏輯集合配置并且不限于其中各個組件的設備在系統(tǒng)外殼中的配置。
本發(fā)明的效果
根據本公開的實施例的配置,實現了這種配置:接收設備可以基于信令數據確定是否允許經由網絡接收數據。
具體地,例如,將用于指示允許經由網絡進行數據接收的一組接收設備或用戶的類標識符記錄在從發(fā)送設備發(fā)送到接收設備的信令數據中。接收設備確定類標識符是否與已設置給接收設備或用戶的類標識符相同,并且當類標識符彼此相同時,經由網絡進行數據接收。應用于經由廣播波或網絡接收數據的url基本模式(basepattern)被記錄在信令數據中,并且接收設備獲取應用了url基本模式的數據。
根據本配置,實現了以下配置:接收設備可以基于信令數據確定是否允許經由網絡的數據接收。
需注意,在本說明書中描述的效果僅僅是示例而非限于此,并且可以獲得附加效果。
附圖說明
圖1是用于描述進行本公開的處理的通信系統(tǒng)的示例性配置的示圖。
圖2是用于描述發(fā)送設備的發(fā)送數據的示圖。
圖3是示出發(fā)送設備和接收設備的協(xié)議棧的示例的示圖。
圖4是用于描述使用服務工作者(sw)的處理的具體示例(用例)的示圖。
圖5是用于描述使用服務工作者(sw)的處理的具體示例(用例)的示圖。
圖6是用于描述使用服務工作者(sw)的處理的示例的示圖。
圖7是用于描述接收設備的示例性配置的示圖。
圖8是用于描述文件獲取處理順序的示圖。
圖9是用于描述文件獲取處理順序的示圖。
圖10是用于描述通過服務工作者(sw)對接收設備的存儲單元(永久緩存)的控制處理順序的示圖。
圖11是用于描述通過服務工作者(sw)對接收設備的存儲單元(永久緩存)的控制處理順序的示圖。
圖12是示出從發(fā)送設備發(fā)送的信令數據(元數據)的示例性配置的示圖。
圖13是用于描述用戶業(yè)務描述(usd)的整體示例性配置的示圖。
圖14是示出在構成信令數據的用戶業(yè)務束描述(usd)下的示例性分級配置的示圖。
圖15是示出在傳送方法(deliverymethod)元素下的信令數據配置的示圖。
圖16是示出當根據flute協(xié)議進行文件傳輸時在傳送方法(deliverymethod)元素中設置的flute的參考信息的示例的圖。
圖17是示出當根據flute協(xié)議進行文件傳輸時在傳送方法(deliverymethod)元素中設置的flute的參考信息的示例的圖。
圖18是示出當根據route協(xié)議進行文件傳輸時在傳送方法(deliverymethod)元素中設置的flute的參考信息的示例的圖。
圖19是示出當根據route協(xié)議進行文件傳輸時在傳送方法(deliverymethod)元素中設置的flute的參考信息的示例的圖。
圖20是用于描述fdt-實例元素的配置的示圖。
圖21(a)和21(b)是分別用于描述與fdt實例對應的屬性和與文件對應的屬性的詳細配置的示圖。
圖22是示出在route中規(guī)定的lsid下的數據配置的示圖。
圖23(a)和23(b)是分別用于描述在efdt元素單元中的屬性數據元素的細節(jié)和文件單元的屬性數據元素的細節(jié)的示圖。
圖24是示出根據傳送路徑的信令數據(usd)的配置和處理示例的示圖。
圖25是示出在傳送方法(deliverymethod)元素下的信令數據配置的示圖。
圖26是描述用于根據傳送路徑進行用于接收控制的信令數據(usd)的配置和處理示例的示圖。
圖27是示出在構成信令數據的用戶業(yè)務束描述(usd)下的示例性分級配置的示圖。
圖28是描述根據傳送路徑進行用于接收控制的信令數據(usd)的配置和處理示例的示圖。
圖29是描述根據傳送路徑進行用于接收控制的信令數據(usd)的配置和處理示例的示圖。
圖30是用于描述用作通信設備的發(fā)送設備和接收設備的示例性配置的示圖。
圖31是用于描述用作通信設備的發(fā)送設備和接收設備的示例性硬件配置的示圖。
具體實施方式
以下將參照附圖詳細描述本公開的接收設備、發(fā)送設備和數據處理方法。需注意,將根據以下部分形成說明書。
1.通信系統(tǒng)的示例配置
2.數據通信協(xié)議flute和route
3.由發(fā)送設備和接收設備進行的示例性通信處理
4.服務工作者(sw)
5.接收設備中的應用的獲取和執(zhí)行的示例
6.接收設備中的文件獲取處理順序
7.服務工作者(sw)對接收設備的存儲單元(永久緩存)的控制處理
8.使用信令數據(usd)通知數據接收路徑信息的配置
9.重定向策略的控制
9.1.經由網絡的傳送數據獲取允許示例1
9.2.經由網絡的傳送數據獲取允許示例2
9.3.經由網絡的傳送數據獲取允許示例3
10.發(fā)送設備和接收設備的示例配置
11.本公開的配置的結論
[1.通信系統(tǒng)的配置的示例]
首先,將參考圖1描述進行本公開的處理的通信系統(tǒng)的示例性配置。
通信系統(tǒng)10包括發(fā)送設備20和接收設備30,該發(fā)送設備20用作發(fā)送諸如圖像數據、音頻數據等內容的通信設備,該接收設備30用作接收從如圖1所示的發(fā)送設備20發(fā)送的內容的通信設備。
具體地,發(fā)送設備20是例如內容提供側的設備,諸如廣播站21和內容服務器22。另一方面,接收設備30是普通用戶的客戶端設備,具體而言,接收設備30包括例如電視31、pc32、移動終端33等。
像使用經由網絡(諸如因特網)的雙向通信或單向通信和經由廣播波等的單向通信中的至少一個或兩者的通信那樣,進行發(fā)送設備20和接收設備30之間的數據通信。
例如,根據為自適應流技術的標準的mpeg-dash標準,進行從發(fā)送設備20到接收設備30的內容發(fā)送。
mpeg-dash標準包括以下兩個標準:
(a)與用于描述元數據(用作運動圖像或音頻文件的管理信息)的清單文件(媒體呈現描述(mpd))相關的標準;和
(b)與用于運動圖像內容發(fā)送的文件格式(段格式)相關的標準。
根據mpeg-dash標準進行從發(fā)送設備20到接收設備30的內容傳送。
發(fā)送設備20編碼內容數據并且生成包括編碼數據和編碼數據的元數據的數據文件。
例如,根據在mpeg中指定的mp4文件格式進行編碼處理。
注意,當發(fā)送設備20生成mp4格式數據文件時,編碼數據的文件被稱為“mdat”,而元數據被稱為“moov”、“moof”等。
由發(fā)送設備20提供至接收設備30的內容是各種數據,例如音樂數據,視頻數據諸如電影、電視節(jié)目、視頻,照片,文檔,繪畫和示圖、游戲和軟件。
將參考圖2描述發(fā)送設備20的發(fā)送數據。
根據mpeg-dash標準進行數據傳輸的發(fā)送設備20發(fā)送的數據大致被分為如圖2所示的多種類型的以下數據:
(a)信令數據50;
(b)av段60;和
(c)其他數據(esg、nrt內容等)70。
例如,av段60配置有在接收設備中再現的圖像(視頻)或音頻數據,即,從廣播站提供的節(jié)目內容等。例如,av段60被配置有mp4編碼的數據(mdat)和元數據(moov和moof)。
另一方面,信令數據50配置有節(jié)目調度信息,諸如節(jié)目表、節(jié)目獲取所需的地址信息(統(tǒng)一資源定位符(url)等),包括用于諸如編解碼器信息(編碼方案等)等所需的信息的指南信息,以及控制信息。
在接收av段60(存儲有用作再現目標的節(jié)目內容)之前,接收設備30必須接收信令數據50。
例如,信令數據50作為可擴展標記語言(xml)格式的數據被發(fā)送到作為用戶設備(諸如智能電話或電視)的接收設備(客戶端)。
如上所述,根據需要重復發(fā)送信令數據。
例如,以100毫秒的間隔頻繁并重復地發(fā)送信令數據。
這是因為接收設備(客戶端)可以在任何時間立即獲取信令數據。
根據需要,客戶端(接收設備)可以基于可接收的信令數據,迅速地進行接收和再現節(jié)目內容所需的處理,諸如獲取必要節(jié)目內容的訪問地址,編解碼器設置處理等。
其他數據70包括例如電子業(yè)務指南(esg)、nrt內容等
esg是電子業(yè)務指南,例如,諸如節(jié)目表的指南信息。
nrt內容是非實時類型內容。
例如,在nrt內容中包括在用作客戶端的接收設備30的瀏覽器上執(zhí)行的數據文件,諸如各種應用文件、運動圖像或靜止圖像。
在nrt內容中還包括用作應用的控制程序的服務工作者(稍后將描述)等。
例如根據數據通信協(xié)議—單向傳輸的文件傳送(flute)發(fā)送圖2所示的以下數據:
(a)信令數據50;
(b)av段60;和
(c)其他數據(esg、nrt內容等)70。
[2.數據通信協(xié)議flute和route]
數據通信協(xié)議flute是這樣的協(xié)議:用于以多播方式進行待發(fā)送內容的會話管理。
例如,根據flute協(xié)議,將在用作發(fā)送設備的服務器側處生成的文件(其由url和版本識別)發(fā)送到用作接收設備的客戶端。
接收設備(客戶端)30將所接收到的文件的url和版本以及文件彼此相關聯地存儲在例如接收設備(客戶端)30的存儲單元(客戶端緩存)中。
當url相同但版本不同時,認為文件的內容被更新過。在flute協(xié)議中,僅進行單向文件傳輸控制,在客戶端中沒有文件的選擇性過濾功能,但是可以通過選擇文件實現選擇性過濾,該文件根據客戶端側的flute使用與該文件鏈接的元數據經歷傳輸控制,并配置、更新和管理反應用戶偏好的本地緩存。
注意,元數據可以被擴展并合并到flute協(xié)議中,或者可以通過諸如電子業(yè)務指南(esg)的協(xié)議單獨描述。
注意,flute最初就已經被標準化為多播中的文件傳輸協(xié)議。
flute配置有fdt和稱為alc的可擴展文件對象的多播協(xié)議,具體地,作為其構建塊的lct或fec組件的組合。
現有技術的flute主要被開發(fā)用于異步文件傳輸,并且目前flute被擴展以容易地應用于高級電視系統(tǒng)委員會(atsc)中的廣播實況流,該高級電視系統(tǒng)委員會(atsc)是與經由廣播波和網絡的數據傳送系統(tǒng)相關的標準化組織。
flute的擴展規(guī)范被稱為通過單向傳輸的實時對象傳送(route)。
高級電視系統(tǒng)委員會(atsc)3.0目前正在被標準化成與經由廣播波和網絡的數據傳送系統(tǒng)相關的標準之一。atsc3.0指定了代替相關技術的flute協(xié)議的棧配置,采用route用于信令數據、esg、異步文件、同步流等的發(fā)送。
[3.由發(fā)送設備和接收設備進行的示例性通信處理]
接下來,將描述由發(fā)送設備和接收設備進行的示例性通信處理。
圖3是示出發(fā)送設備和接收設備的協(xié)議棧的示例的示圖。
在圖3所示的示例中,示出了用于處理以下兩條通信數據的兩個協(xié)議棧:
(a)廣播(包括多播)通信(例如,廣播類型數據傳送);和
(b)單播(寬帶)通信(例如,http類型p2p通信)。
圖3的左側是(a)與廣播通信(例如,廣播類型數據傳送)對應的協(xié)議棧。
圖3的右側是(b)與單播(寬帶)通信(例如,http類型p2p通信)對應的協(xié)議棧。
與(a)在圖3的左側上示出的廣播通信(例如,廣播類型數據傳送)對應的協(xié)議棧從下層起依次具有以下層:
(1)廣播物理層(廣播phy);
(2)ip多播層(ip多播);
(3)udp層;
(4)route(=擴展flute)層;
(5)esg、nrt內容、dash(isobmff)和視頻/音頻/cc;和
(6)應用層(應用(html5))。
注意,信令層被設置為在ip多播層(ip多播)之上的層(2)。
信令層是應用于上面參照圖2描述的信令數據50的發(fā)送和接收的層。信令數據包括獲取節(jié)目所需的諸如節(jié)目表、地址信息(url等)的節(jié)目調度信息、指南信息以及控制信息,其中,指南信息包括對于諸如編解碼器信息(編碼方案或等)等內容再現處理所需的信息。
需注意,將來新協(xié)議的使用允許層(未來可擴展性)被設置為(1)廣播物理層(廣播phy)之上的層。
(1)廣播物理層(廣播phy)是配置有通信控制單元的物理層,該通信控制單元用于控制例如用于執(zhí)行廣播通信的廣播系統(tǒng)的通信單元。
(2)ip多播層(ip多播)是其中根據ip多播進行數據發(fā)送/接收處理的層。
(3)udp層是進行生成和分析udp分組的處理的層。
(4)route層是其中根據用作擴展flute協(xié)議的route協(xié)議存儲和提取傳輸數據的層。
與flute類似,route是被稱為alc的可擴展文件對象的多播協(xié)議,并且具體地,route被配置有作為其構建塊的lct或fec組件的組合。
(5)esg、nrt內容、dash(isobmff)和視頻/音頻/cc是根據route協(xié)議傳輸的數據。
根據dash標準的廣播類型傳送業(yè)務被稱為多媒體廣播多播業(yè)務(mbms)。存在作為用于在lte中有效實現mbms的方案的演進多媒體廣播多播業(yè)務(embms)。
mbms和embms是廣播類型傳送業(yè)務,即這樣的業(yè)務:用于通過公共載體向作為位于特定區(qū)域中的接收設備的多個用戶終端(ue)同時傳送諸如電影內容等的相同數據。通過根據mbms或embms的廣播傳送,可以將相同的內容同時提供到位于傳送業(yè)務提供區(qū)域中的諸如多個智能電話、pc或電視的接收設備。
在mbms和embms中,根據傳輸協(xié)議route或flute具體說明了根據3gpp文件格式(iso-bmff文件或mp4文件)的下載文件的處理。
將以上參考圖2描述的以下數據中的多數根據route協(xié)議或flute協(xié)議發(fā)送:
(a)信令數據50;
(b)av段60;和
(c)其他數據(esg、nrt內容等)70。
(5)esg、nrt內容、dash(isobmff)和視頻/音頻/cc是根據route協(xié)議傳輸的數據。
esg是電子業(yè)務指南,例如,諸如節(jié)目表的指南信息。
nrt內容是非實時類型內容。
如上所述,例如,在nrt內容中包括在用作客戶端的接收設備的瀏覽器上執(zhí)行的數據文件,諸如各種應用文件、運動圖像或靜止圖像。另外,在nrt內容中還包括用作應用的控制程序的服務工作者(sw)(稍后將描述)等。
視頻/音頻/cc是用作再現目標(諸如根據dash標準傳送的視頻或音頻)的實際數據。
(6)應用層(應用(html5))是這樣的應用層:在其中進行根據route協(xié)議待傳送的數據的生成或分析,以及進行各種數據的輸出控制,例如應用了html5的數據生成、分析、輸出處理等。
另一方面,與(b)在圖3的右側上示出的單播(廣播)通信(例如,http類型p2p通信)對應的協(xié)議棧從下層起依次具有以下層:
(1)寬帶物理層(寬帶phy);
(2)ip單播層(ip單播);
(3)tcp層;
(4)http層;
(5)esg、信令、nrt內容、dash(isobmff)和視頻/音頻/cc;
(6)應用層(應用(html5))。
(1)寬帶物理層(廣播phy)是配置有通信控制單元(諸如設備驅動器)的物理層,該通信控制單元用于控制用于執(zhí)行寬帶通信的通信單元(諸如網卡)。
(2)ip單播層(ip單播)是進行ip單播發(fā)送/接收處理的層。
(3)http層是http分組生成/分析處理層。
上層類似于圖3左側的(a)廣播通信(例如,廣播類型數據傳送)的棧配置。
需注意,發(fā)送設備(服務器)20和接收設備(客戶端)30進行根據圖3的兩個處理系統(tǒng)中的至少一個的處理,即以下兩個通信協(xié)議棧:
(a)廣播通信(例如,廣播類型數據傳送);
(b)單播(寬帶)通信(例如,http類型p2p通信)。
在圖3所示的協(xié)議棧中,當根據route(flute)多播并傳輸的文件組的屬性(包括用作文件標識符的url)可以在route(flute)的控制文件中描述時,其可以在描述文件傳輸會話的信令數據中描述。另外,文件傳輸會話的更詳細屬性可以由esg(其也可以用于向最終用戶呈現)來描述。
[4.服務工作者(sw)]
接下來,將描述由發(fā)送設備(服務器)20提供并主要在接收設備(客戶端)30中使用的服務工作者(sw)。
服務工作者(sw)從諸如廣播服務器21或數據傳送服務器22的發(fā)送設備20提供至接收設備。
服務工作者(sw)是進行獲取處理的程序、在存儲單元(緩存)的存儲處理、更新處理、刪除處理等,其中,該獲取處理用于在接收設備(客戶端)30中執(zhí)行的應用(=應用程序)、在執(zhí)行應用時使用的數據文件等。具體地,服務工作者(sw)例如用javascript(注冊商標)配置。
例如,服務工作者(sw)被設置為對應于與由傳送設備20(諸如廣播服務器21、數據傳送服務器22等)提供的廣播節(jié)目(廣播內容),并且作為從發(fā)送設備20提供至接收設備30的應用的控制/管理程序提供至接收設備30。
將執(zhí)行應用時所使用的服務工作者(sw)、應用和數據文件從發(fā)送設備20提供至接收設備30,例如作為以上參考圖1、圖2和圖3描述的nrt內容(非實時內容)。
另選地,與傳送廣播節(jié)目標服務器不同的數據提供服務器可以被配置為向接收設備30提供執(zhí)行應用時所使用的服務工作者(sw)、應用和數據文件。
例如,服務工作者(sw)對使用瀏覽器進行信息顯示的應用等進行管理(獲取、保留、更新、刪除等),其中,瀏覽器是用于在接收設備30上進行網頁等瀏覽的程序。
將參考4圖和圖5描述使用服務工作者(sw)的處理的具體示例(用例)。
圖4示出接收設備30從發(fā)送設備20(諸如廣播服務器21)接收某個節(jié)目內容并且在接收設備30的顯示單元上顯示該節(jié)目內容的狀態(tài)。
除了節(jié)目傳送之外,傳送設備20(諸如廣播服務器21)將用于顯示天氣信息的應用和用于天氣信息顯示應用的各種數據文件作為nrt內容(非實時內容)提供至接收設備30,例如,包括諸如運動圖像、靜止圖像和音頻的數據文件)的數據文件。
在下文中,應用和數據文件被稱為“資源”。
廣播服務器21還將用作用于管理“資源”的資源管理程序的服務工作者(sw)作為nrt內容(非實時內容)提供至接收設備30。
接收設備30可以使用從發(fā)送設備20接收的“資源”(即應用和數據文件)進行天氣信息的顯示以及圖4所示的節(jié)目顯示。
在上述數據傳送配置中,在由應用提供的內容結束時,同時禁用使用應用的此類數據顯示。
這是因為資源(諸如天氣信息顯示應用)在節(jié)目接收期間被設置為在接收設備30中可使用,例如,存儲在臨時存儲緩存中、并且被設置為可用狀態(tài),但是當節(jié)目結束時或用戶切換頻道時,將此類緩存數據擦除或設置成不可訪問狀態(tài)。
服務工作者(sw)用作資源管理程序,其使得即使在節(jié)目結束之后、甚至在頻道切換之后、或甚至在離線狀態(tài)(諸如廣播不可接收狀態(tài)或網絡不可連接狀態(tài))下,應用或與節(jié)目對應的數據能夠可用。
即使在由應用提供的節(jié)目結束之后、在切換到另一頻道之后、或者甚至在其中不能進行數據接收的離線狀態(tài)下,也可以使天氣信息顯示應用可用。換句話說,可以使天氣信息顯示在接收設備30的顯示單元上并進行瀏覽。
需注意,天氣信息顯示應用例如是顯示在瀏覽器上的程序。
天氣信息顯示應用在服務工作者(sw)的控制下存儲在接收設備30的存儲單元(永久緩存)中。例如,當存在請求(事件)(諸如來自用戶的顯示請求)時,在服務工作者(sw)的控制下從存儲單元(永久緩存)中讀取天氣信息顯示應用并且顯示在顯示單元上。
需注意,存儲資源(諸如應用)的存儲單元(永久緩存)優(yōu)選地是即使當接收設備30斷電時所存儲數據也不被擦除的非易失性存儲器。
如上所述,使用服務工作者(sw),可以使用與節(jié)目顯示或不顯示無關的各種節(jié)目對應的應用。
需注意,服務工作者(sw)例如設置在與特定節(jié)目相對應的資源單元中(在應用和應用相關數據的單元中),并且與資源一起或在發(fā)送資源之前或之后從發(fā)送設備20提供到接收設備30。
可以針對每個節(jié)目設置服務工作者(sw),但是也可以設置可以與包括多個節(jié)目的特定頻道相對應的資源共同使用的服務工作者(sw)。
服務工作者(sw)和由服務工作者(sw)管理的資源(應用和應用相關數據)存儲在接收設備30的存儲單元(永久緩存)中。
圖6是用于描述使用服務工作者(sw)的處理的示例的示圖。
圖6示出接收設備30從發(fā)送設備20獲取用作資源的網頁(例如,圖4和圖5所示的天氣信息顯示頁)、將網頁存儲在接收設備30的存儲單元(永久緩存)中并使用網頁的順序的示例。
需注意,使用預定網頁顯示應用和配置有顯示數據的資源顯示網頁。
圖6示出了作為接收設備中的輸出控制單元90的組件的顯示處理單元91,服務工作者(sw)92和緩存(存儲單元)93。
步驟s101至s102是所進行的資源(網頁)獲取處理,使得接收設備30對發(fā)送設備20進行第一訪問處理。
例如,從來自廣播服務器發(fā)送的nrt內容中獲取。
在獲取處理之后,顯示處理單元91使得網頁95顯示在接收設備30的顯示單元上。
該顯示是其中提供網頁的節(jié)目也被顯示的狀態(tài)并且對應于上面參考圖3描述的顯示狀態(tài)。
在該顯示期間中,例如,在步驟s103中,存在作為用戶指令的資源(網頁)注冊(安裝)請求時,服務工作者(sw)92開始資源(網頁)注冊(安裝)過程。
具體地,如在步驟s104中那樣進行將資源移交到緩存93并將資源存儲在存儲單元(永久緩存)中的處理。
此后,在節(jié)目結束之后,在頻道切換之后,或者在離線設置狀態(tài)下,在步驟s105中,用戶做出網頁瀏覽請求。
服務工作者(sw)92檢測作為抓取事件的瀏覽請求輸入,并且在步驟s106中,服務工作者(sw)92響應于抓取事件檢測獲取來自存儲單元(永久緩存)的資源。
在步驟s107中,顯示處理單元91顯示網頁96。
網頁顯示處理是在程序結束之后,頻道切換之后或者處于離線設置狀態(tài)的顯示處理并且對應于上面參照圖5所述的顯示狀態(tài)。
如上所述,使用服務工作者(sw),不管是否顯示節(jié)目,都可以使用各種節(jié)目對應應用,例如,可以進行顯示網頁的處理,該網頁被設置為在與節(jié)目無關的任意定時處的節(jié)目屬性的顯示信息。
如上所述,例如,服務工作者(sw)進行諸如資源的獲取、存儲、更新和刪除的資源管理,該資源包括作為組件的應用或在應用中使用的數據等,該應用具有網頁、html頁面、javascript(注冊商標)等。
其中,存儲資源的存儲單元(緩存)是其中存儲數據被永久存儲的存儲單元(緩存),并且即使當應用不像公共本地/臨時緩存那樣操作時也存儲數據。
在用作網頁顯示節(jié)目的瀏覽器中實現一種代理服務器,并且它是在任何時間可以根據需要訪問代理服務器、獲取網頁并顯示網頁的圖像。
需注意,服務工作者(sw)也存儲(安裝)在永久緩存中。當服務工作者(sw)安裝在接收設備中時,可以對用作該服務工作者(sw)的管理對象的資源進行各種控制。
例如,響應于對資源的訪問請求(對資源的抓取請求),在瀏覽器側處理(從本地緩存或網絡獲取資源)開始之前,服務工作者(sw)的處理開始并且進行從永久緩存提供資源。
此外,因為服務工作者(sw)由javascirpt(注冊商標)提供,所以可以兼容各種處理,并且可以對緩存控制(諸如更新永久緩存的一些資源)進行靈活的處理描述。
需注意,服務工作者(sw)也可以更新。服務工作者(sw)是從發(fā)送設備20提供的,但是更新處理所需的各種類型的信息(諸如更新日期/時間信息以及更新日期的訪問信息)被記錄在服務工作者(sw)的頭信息(http緩存控制)中,并且基于頭信息進行更新處理。
例如,當基于在頭部中設置的截止日期等到達截止日期時,接收設備30進行服務工作者(sw)的新版本的獲取處理,并且進行將存儲在緩存中的sw舊版本取代的處理。
[5.接收設備中的應用的獲取和執(zhí)行的示例]
如上所述,接收設備30可以執(zhí)行例如應用諸如上面參考圖4和5描述的天氣信息顯示應用,即,接收設備30可以使用服務工作者(sw)在任意定時執(zhí)行服務工作者(sw)的管理對象。
在接收設備30側處的用戶可以在任意定時執(zhí)行應用,并且可以隨時瀏覽天氣信息顯示頁面或各種網頁。
將參照圖7描述執(zhí)行應用的接收設備30的配置。
圖7示出主要應用于獲取和執(zhí)行應用的示例性配置,其作為用于執(zhí)行服務工作者(sw)管理應用(諸如天氣信息顯示應用)的接收設備30的部分配置。
如圖7所示,接收設備30包括中間件110、http代理服務器120和輸出控制單元130。
中間件110接收并分析廣播服務器21的提供數據。
中間件110包括通信單元(phy/mac)111、獲取信令數據的信令獲取單元112、分析信令數據的信令分析單元113以及文件獲取單元114,文件獲取單元114獲取信令數據和節(jié)目內容數據(諸如視頻和語音或諸如應用的nrt內容等的數據文件)。
中間件110接收的數據被存儲在代理服務器120的緩存單元(代理緩存)121中。代理服務器120還將經由網絡從數據傳送服務器22獲取的數據存儲在緩存單元(代理緩存)122中。
代理服務器120將從輸出控制單元130傳送的數據請求輸入到地址解析單元123,從緩存單元(代理緩存)121或122或外部獲取請求的數據,并提供所請求的數據。
輸出控制單元130是執(zhí)行服務工作者(sw)管理應用(諸如天氣信息顯示應用)的數據處理單元。例如,輸出控制單元130在瀏覽器上進行網頁顯示處理等。
輸出控制單元130包括顯示數據(例如,html/javascript(注冊商標))獲取和分析單元131和顯示處理單元(渲染器)132。
輸出控制單元130獲取并呈現中間件(客戶端本地atsc中間件)110或者經由公共網絡棧獲取并呈現應用和部分(html頁面和javascript),其中,在中間件110中經由代理服務器(客戶端本地http代理服務器)120實現廣播系統(tǒng)接收棧,在所述公共網絡棧中,執(zhí)行網絡系統(tǒng)發(fā)送/接收處理。
需注意,還可以在經由網絡(諸如lan)連接到接收設備30的外部設備140的輸出控制單元141中傳送應用和部分(html頁面或javascript),并且在外部設備140中執(zhí)行該應用。
輸出控制單元130可以將服務工作者(sw)和用作服務工作者(sw)的管理對象的資源(應用和應用相關數據)存儲在存儲單元(永久緩存)133中,并在任意定時進行使用服務工作者(sw)和存儲在存儲單元(永久緩存)中的資源的處理。
例如,如參考圖4和5的以上所述,在任意定時使用應用輸出各種數據。此外,輸出控制單元130根據需要進行服務工作者(sw)或資源(應用和應用相關數據)的更新處理或刪除處理。
這同樣應用于外部設備140的輸出控制單元141,并且服務工作者(sw)或資源(應用和應用相關數據)存儲在外部設備140的存儲單元(永久緩存)142中,并且在任意定時進行使用服務工作者(sw)或應用的各種數據處理。此外,根據需要進行服務工作者(sw)或資源(應用和應用相關數據)的更新處理或刪除處理。
需注意,在圖7所示的模型中,因為當進行對外部的訪問時,輸出控制單元130和140一致地經由代理服務器120訪問,所以不區(qū)分是經由廣播還是網絡獲取資源(諸如應用)。換句話說,提供了網絡透明度。
將描述根據來自輸出控制單元130的數據請求的示例性數據獲取/提供處理。
例如,當輸出控制單元130請求獲取構成應用(http請求)的html頁面或javascript(注冊商標)時,已經接收請求的代理服務器120確定是經由廣播接收棧還是經由地址解析單元(廣播/寬帶地址解析器)123中的網絡獲取html頁面或javascript(注冊商標)。
通過信令分析單元113從信令數據的分析結果中獲得用作確定材料的信息。
信令分析單元(信號分析器)113發(fā)送usbd(usd、sdp等)的獲取請求到信令取得單元(信令獲取器)112,該獲取請求是包括在atsc3.0的信令數據中的元數據。
信令分析單元(信令解析器)113提取包括在通過信令數據存儲lct分組發(fā)送的信令數據中的元數據,該分組經由通信單元(atsc調諧器:atsc3.0phy/mac)111被廣播和接收。
此外,信令分析單元(信令解析器)113基于包括在應用組件(部分)的獲取請求中的url解析廣播傳送地址信息,該廣播傳送地址信息用于從信令數據(元數據)中獲取所請求的文件。當確定應用組件(部分)是廣播傳送目標數據時,文件獲取單元(文件獲取器)114基于廣播傳送地址信息獲取其中存儲有期望文件的文件存儲lct分組,并且將該文件存儲lct分組存儲在緩存單元(代理緩存)121中。
代理服務器120將所緩存的文件返回到輸出控制單元130(作為http響應)。當包括在應用部分的獲取請求中的url未被設置在元數據(被包括在信令數據中)中時,代理服務器120經由公共網絡棧從數據傳送服務器22獲取文件。
[6.接收設備中的文件獲取處理順序]
接下來,將描述接收設備中的文件獲取處理順序。
接收設備(客戶端)30進行從發(fā)送設備20(包括廣播服務器21或數據傳送服務器22)發(fā)送的各種數據文件的獲取處理。
例如,獲取內容片段文件、諸如數據文件的應用文件、其中存儲有服務工作者(sw)的文件等,其中,內容片段文件為廣播節(jié)目(內容)的分割數據文件,數據文件存儲當執(zhí)行應用時所使用的運動圖像、靜止圖像、聲音等。
例如,根據在接收設備30中執(zhí)行的廣播流再現應用(其在瀏覽器或本地環(huán)境中執(zhí)行)的處理,接收設備(客戶端)30獲取作為獲取對象的各種文件的url。
例如,用于通知url(其用于激活應用)的觸發(fā)信息被包括在特定節(jié)目的廣播流中,并且再現應用可以基于該觸發(fā)信息獲取文件url。
例如,接收設備30從廣播流中提取由url指定的文件,或者使用url經由網絡獲取文件。
將參考圖8至圖9所示順序示圖描述文件獲取處理順序。
需注意,接收設備30獲取上述各種文件,諸如內容段文件,應用文件,存儲運動圖像、靜止圖像、聲音等的數據文件,具有存儲其中的服務工作者(sw)的文件等。
在圖8和圖9中,從左邊起示出以下組件。
(a)用作發(fā)送設備20的廣播服務器;
(b)用作發(fā)送設備20的數據傳送服務器;
(c)用作接收設備30的組件的中間件;
(d)用作接收設備30的組件的代理服務器;和
(e)用作接收設備30的組件的輸出控制單元。
將順序地描述圖8和圖9的順序圖中示出的步驟的處理。。
需注意,假設在圖8和圖9的處理順序開始之前,在接收設備30的輸出控制單元中激活瀏覽器上的本地流再現應用或流再現應用。
(步驟s211)
首先,由在瀏覽器上的本地流再現應用(其由作為接收設備30組件的輸出控制單元執(zhí)行)或流再現應用發(fā)送對特定數據文件的獲取請求。例如,發(fā)送指定了文件url的數據文件獲取請求。
需注意,如上所述,例如根據作為自適應流媒體技術標準的mpeg-dash標準來執(zhí)行從發(fā)送設備20到接收設備30的數據發(fā)送。
如以上參考圖2所述的,由根據mpeg-dash標準進行數據發(fā)送的發(fā)送設備20發(fā)送的數據大致分為以下數據的多種類型:
(a)信令數據50;
(b)av段60;和
(c)其他數據(esg、nrt內容等)70。
例如,av段60配置有在接收設備中再現的圖像(視頻)或音頻數據,即,從廣播站提供的節(jié)目內容等。例如,av段60被配置有mp4編碼數據(mdat)和元數據(moov和moof)。
信令數據50配置有獲取節(jié)目所需的節(jié)目調度信息(諸如節(jié)目表、地址信息(url等))、指南信息和控制信息,其中,指南信息包括對于諸如編解碼器信息(編碼方案或等)等的內容進行再現處理所需的信息。
其他數據70包括例如電子業(yè)務指南(esg)、nrt內容等
esg是電子業(yè)務指南,例如,指南信息(諸如節(jié)目表)。
nrt內容是非實時類型內容。
例如,在nrt內容中包括在用作客戶端的接收設備的瀏覽器上執(zhí)行的數據文件(諸如各種應用文件、運動圖像或靜止圖像)。服務工作者(sw)也包括在nrt內容中。
(媒體呈現描述(mpd))是描述元數據的清單文件,該元數據是運動圖像和音頻文件的管理信息。具體地,例如,記錄從廣播站傳送的節(jié)目內容的傳送開始時間信息、av段的訪問信息等。
在步驟s211中,例如,接收設備30的輸出控制單元獲取段url(該段url是mpd中描述的內容存儲段的訪問信息,該mpd是廣播內容流的dash流的控制文件),并且將用于內容段文件的獲取請求發(fā)送到使用所獲取的段url的代理服務器。
對于其他應用文件、數據文件、服務工作者(sw)文件等,從信令數據等獲取用作訪問信息的url,并且進行其中應用url的文件訪問。
(步驟s212至s213)
接著,在步驟s212中,當由文件url識別的文件存儲在由代理服務器管理的緩存中時,接收設備30的代理服務器從緩存獲取文件并作為響應將所獲取文件發(fā)送到控制單元。
另一方面,在步驟s213中,當確定由文件url識別的文件未存儲在由代理服務器管理的緩存中時,接收設備30的代理服務器將文件獲取請求輸出到中間件。
(步驟s214)
步驟s214的處理指示由廣播服務器21連續(xù)進行的處理。廣播服務器21連續(xù)地將信令數據(元數據等)以及節(jié)目內容提供至接收設備30,其中,信令數據包括與傳送內容有關的控制信息、管理信息等。
(步驟s215)
當在步驟s213中從代理服務器輸出文件請求時,由中間件執(zhí)行步驟s215的處理。
中間件基于從廣播服務器21接收的信令數據(元數據)確定是否能夠經由廣播接收針對從代理服務器輸出的獲取請求的文件,并且將指示確定信息的通知提供給代理服務器。
(步驟s216)
當從中間件接收了用于指示可以經由廣播接收文件的通知時,代理服務器處于待機狀態(tài),以將文件形成(存儲)到代理服務器的管理緩存。
另一方面,當從中間件接收到用于指示不能經由廣播接收文件的通知時,代理服務器經由網絡將用于獲取文件的獲取請求發(fā)送到數據傳送服務器22。
(步驟s217至s218)
步驟s217至s218的處理是當可以經由廣播接收到針對從代理服務器輸出的獲取請求的文件時進行的處理。
在這種情況下,在步驟s217中,廣播服務器21經由廣播波發(fā)送文件。
在步驟s218中,接收設備30的中間件接收從廣播服務器21發(fā)送的文件,并將該文件形成(存儲)到代理服務器的管理緩存中。
(步驟s219)
步驟s219的處理是當不能經由廣播接收到針對從代理服務器輸出的獲取請求的文件時進行的處理。
在這種情況下,在步驟s219中,數據傳送服務器22將接收設備30所請求的文件發(fā)送到接收設備30。
接收設備30的代理服務器接收所發(fā)送文件,并將該文件形成(存儲)到代理服務器的管理緩存中。
(步驟s220)
在步驟s220中,將從廣播服務器21或數據傳送服務器22獲取的并存儲在代理服務器管理緩存中的文件從代理服務器提供至輸出控制單元。
[7.服務工作者(sw)對接收設備的存儲單元(永久緩存)的控制處理]
接下來,將描述由根據文件獲取處理等存儲在接收設備30中的服務工作者(sw)對接收設備的存儲單元(永久緩存)的控制處理。
存儲在接收設備30中的服務工作者(sw)使用管理對象的資源(即作為管理進程之一的應用或與應用相關數據)控制存儲單元(永久緩存),即存儲資源的緩存。
首先,服務工作者(sw)根據在接收設備30的存儲單元(永久緩存)中的預定事件的檢測,存儲初始激活服務工作者(sw)的應用所需的文件。
接收到用作觸發(fā)服務工作者(sw)的資源存儲的事件的定時是執(zhí)行服務工作者(sw)的注冊處理或重新注冊(更新)處理的定時。此時,服務工作者(sw)接收注冊(安裝)事件。
此外,在應用請求html頁面或javascript(注冊商標)的定時(當接收到抓取事件時)或者在由服務工作者(sw)生成的定時器重新激活時,接收用作資源存儲處理的觸發(fā)的事件。
由服務工作者(sw)形成到存儲單元(永久緩存)中的應用(部分組)可以被激活為這樣的應用(離線應用):該應用不僅與廣播流相關聯地(同時)被激活,而且還被安裝在獨立于廣播流的客戶端。
將參照圖10至圖11所示的順序圖描述服務工作者(sw)對接收設備的存儲單元(永久緩存)的控制處理順序。
在圖10至11中,以下組件從左邊起示出:
(a)構成發(fā)送設備的廣播服務器;
(b)構成發(fā)送設備的數據傳送服務器;
(c)接收設備的中間件;
(d)接收設備的代理服務器;
(e)由接收設備的輸出控制單元執(zhí)行的瀏覽器管理的存儲單元(永久緩存)
(f)在由接收設備的輸出控制單元執(zhí)行的瀏覽器上執(zhí)行的服務工作者(sw);
(g)在由接收設備的輸出控制單元執(zhí)行的瀏覽器上執(zhí)行的應用;和
(h)由接收設備的輸出控制單元執(zhí)行的本地應用。
需注意,本地應用是由接收設備30執(zhí)行的應用,但是本地應用不是由服務工作者(sw)管理的應用,而是例如用于與內容(節(jié)目)對應的應用的激活處理的應用。
將順序地描述在圖10至圖11的順序圖中示出的步驟的處理。
(步驟s301)
步驟s301的處理是通過本地應用激活與內容(節(jié)目)相對應的應用的處理。
如上所述,本地應用是用于與內容(節(jié)目)相對應的應用的激活處理的應用。
在基于例如嵌入在程序中的觸發(fā)信息激活與內容(節(jié)目)對應的應用的設置的情況下,不需要本地應用的激活處理。
(步驟s302)
在步驟s302中,被激活的應用進行服務工作者(sw)的注冊處理。
通過注冊處理,服務工作者(sw)被存儲在存儲單元(永久緩存)中并且進入可以隨時使用該服務工作者(sw)的狀態(tài)。
服務工作者(sw)基于注冊(安裝)事件的檢測來檢測服務工作者(sw)注冊處理,并且服務工作者(sw)使用注冊(安裝)事件的檢測作為觸發(fā)來開始步驟s303的緩存控制。
(步驟s303至s305)
當檢測到注冊(安裝)事件時,在步驟s303中,服務工作者(sw)例如根據腳本描述開始存儲單元(永久緩存)的控制。
具體地,開始獲取處理和緩存形成(存儲)處理,該獲取處理和緩存形成(存儲)處理用于作為服務工作者(sw)的管理對象的資源(應用和應用相關數據)。
需注意,在步驟s304中,從發(fā)送設備(諸如廣播服務器、數據傳送服務器等)連續(xù)地發(fā)送用作服務工作者(sw)的管理對象的資源(應用和應用相關數據)。
需注意,在步驟s304中,進行以下處理:用資源處理取代在以上參考圖8至圖9描述的資源發(fā)送/接收處理(其具有用于資源的處理)中的在圖8至9的步驟中的段文件的處理(a-1至a-2)。
在步驟s305中,通過代理服務器的管理緩存將傳輸數據形成(存儲)到存儲單元(永久緩存)中。
(步驟s306至s309)
在步驟s306中,應用請求服務工作者(sw)發(fā)送應用部分,例如,執(zhí)行應用所需的運動圖像文件或靜止圖像文件,或者應用相關數據(諸如javascript(注冊商標)程序或音頻數據)。
該請求處理對應于在服務工作者(sw)中的抓取事件檢測。
在步驟s307至s309中,服務工作者(sw)從存儲單元(永久緩存)獲取所請求的部分,并將所請求的部分提供至應用。
(步驟s310至s311)
步驟s310至s311的處理是當服務工作者(sw)檢測到激活事件時的處理。
例如,當用戶輸入資源刪除請求時或者當應用的截止日期到期時,檢測到激活事件。
當服務工作者(sw)檢測到激活事件時,例如,根據腳本描述開始存儲單元(永久緩存)的控制。
具體地,例如,進行針對用作服務工作者(sw)的管理對象的資源(應用和應用相關數據)的刪除處理。
(步驟s312至s315)
步驟s312至s315的處理是當服務工作者(sw)檢測到定時器事件時的處理。
例如,當應用的截止日期到期時,當更新期限到達時等,檢測定時器事件。
根據定時器事件的處理的示例包括緩存資源的刪除和更新資源或添加資源的獲取處理。
步驟s313是與定時器事件對應的緩存資源的刪除處理的順序。
步驟s314至s315示出與定時器事件對應的更新資源或添加資源的獲取處理的順序。
注意,在步驟s314中,進行以下處理:將用于資源的處理替換在以上參考圖8至圖9描述的資源發(fā)送/接收處理中的圖8至圖9的步驟中用于段文件的處理。
[8.使用信令數據(usd)通知數據接收路徑信息的配置]
接下來,將描述使用信令數據(usd)來通知數據接收路徑信息的配置
圖7所示的接收設備30的中間件110基于從發(fā)送設備20發(fā)送的信令數據確定是否可以經由廣播接收目標文件,經由廣播將指示目標文件是否可以經由廣播接收的信息發(fā)送到http代理服務器120的地址解析單元(廣播/寬帶地址解析器)123,并且確定獲取是經由廣播的緩存獲取還是經由網絡的緩存獲取。
用戶業(yè)務描述(usd:userservicedescription)用作信令數據,在usd中存儲了以下信息:基于該信息執(zhí)行上述確定的信息。
圖12是示出從發(fā)送設備(諸如廣播服務器21)發(fā)送的信令數據(元數據)的示例性配置的示圖。
信令數據(元數據)具有如圖12所示的以下三個層:
(1)服務層(開放移動聯盟-電子業(yè)務指南(oma-esg));
(2)文件傳輸會話層(3gpp-mbms-usd);和
(3)flute(route)參數層(flute(route))。
(1)服務層是其中描述特別旨在呈現給用戶的服務或內容的屬性信息的層。
(2)文件傳輸會話層是其中描述文件等的傳輸參數的層。
(3)flute(route)參數層是其中描述與flute(route)協(xié)議對應的參數的層。
需注意,圖12的箭頭示出在屬性信息(元素)記錄區(qū)(片段)之間的參考關系。
例如,從業(yè)務段(a)延伸到調度段(d)的箭頭指示與在業(yè)務段(a)中記錄的業(yè)務(例如,頻道和節(jié)目)對應的傳送調度信息被記錄在調度段(d)中。
每個段(元素)被分類成其中記錄不同類型屬性信息的區(qū)域。
在節(jié)目或頻道的單元中設置的業(yè)務單元的信令數據(元數據)被記錄在(1)最高級服務層(oma-esg)中。
(2)文件傳輸會話層(3gpp-mbms-usd)設置在服務層(oma-esg)(1)下。用戶業(yè)務描述(usd)包括在信令數據(元數據)中。
需注意,usd存儲例如與傳送方法相關的信息,并且包括例如以下信令數據:
會話描述(sdp);
文件傳送描述(fdd);
修復流描述(rfd);和
調度描述(sd)。
另外,usd包括作為信令數據的媒體呈現描述(mpd),該信令數據具有其中存儲與內容(av段)對應的各種指南信息和控制信息的清單文件。
(3)flute(route)參數層設置在usd元數據下。在該層中設置根據flute(route)協(xié)議待傳送的特定傳送數據信息,例如route元數據,其中例如記錄了實際傳送的各個文件的傳輸參數。
下面將描述在(2)文件傳輸會話層(3gpp-mbms-usd)中記錄文件傳輸路徑信息的示例。
用戶業(yè)務描述(usd)是類集線器元件,其中存儲有構成業(yè)務的傳輸會話的屬性。此外,元素具有與段相同的含義。
圖13示出用戶業(yè)務描述(usd)的整體示例性配置。
用戶業(yè)務束描述(usd)210是多個用戶業(yè)務描述(usd)211的集合。
圖13所示的中空菱形箭頭指示在中空箭頭側的元素包括連接元素。
正常箭頭表示參考關系。
傳送方法(deliverymethod)元素212設置在用戶業(yè)務描述(usd)211下。
與每個文件的傳送處理相關的信息被記錄在傳送方法(deliverymethod)元素212中。
在本公開的實施例中,用于指示每個文件是經由廣播還是網絡發(fā)送的傳輸路徑信息被記錄在作為用戶業(yè)務描述(usd)211下級元素的傳送方法(deliverymethod)元素212中。
圖14示出在構成信令數據的用戶業(yè)務束描述(usd)200下的示例性分級配置。
以下元素設置在用戶業(yè)務束描述(usd)210下:
用戶業(yè)務描述(usd)元素211;和
傳送方法(deliverymethod)元素212。
圖15是示出在傳送方法(deliverymethod)元素211下的信令數據配置的示圖。
需注意,傳送方法設置在發(fā)送內容或發(fā)送數據的單元中。
例如,在信令數據(元數據)中指定設置在應用單元、服務工作者(sw)的單元、運動圖像的單元、靜止圖像的單元等中的傳送處理方法。
以下元素中的任何一個設置在如圖15所示的傳送方法(deliverymethod)元素212下。
(a)廣播應用服務(broadcastappservice)元素223;和
(b)單播應用服務(unicastappservice)元素224。
當(a)設置廣播應用服務(broadcastappservice)元素223并且文件url的基本模式記錄在其下面的基本模式(basepattern)信息225中時,這指示通過傳送方法(deliverymethod)待傳送的文件經由廣播傳送,例如,經由廣播波傳送。
另一方面,當(b)設置單播應用服務(unicastappservice)元素224并且文件url的基本模式記錄在其下面的基本模式(basepattern)信息226中時,這指示通過傳送方法(deliverymethod)待傳送的文件經由單播(寬帶傳送)傳送,例如,經由網絡。
當設置(a)廣播應用服務(broadcastappservice)元素223時,在其下記錄基本模式(basepattern)信息225。
基本模式(basepattern)信息225是指示與待經由廣播傳送的文件對應的url路徑組的數據。
接收設備使用url信息從廣播波獲取目標文件。
另一方面,當設置(b)單播應用服務(unicastappservice)元素224時,在其下記錄基本模式(basepattern)信息226。
基本模式(basepattern)信息226是指示與待經由單播傳送的文件對應的url路徑組的數據。
接收設備使用url信息經由網絡獲取目標文件。
例如,文件url的第一url的路徑部分在基本模式(basepattern)信息225和226中指示。具體地,例如http://a.com/bc,http://a.com/bb等。其指示具有從路徑開始的文件url的文件通過由其上的一個人元素指示的路徑(廣播或網絡)傳送。
例如,http://a.com/bc/x.js指示文件通過廣播傳送,
http://a.com/bb/y.js表示文件通過網絡傳送。
此外,屬性數據227設置在傳送方法(deliverymethod)元素212下,并且會話描述uri(sessiondescriptionuri)元素228設置在屬性數據222中,如圖15所示。
這里,存儲用于flute(route)的參考信息。
圖16是示出當根據flute協(xié)議進行文件傳輸時在傳送方法(deliverymethod)元素212中設置的flute的參考信息的示例的圖。
如圖16所示的以下信息記錄為sdp,其如圖16所示,涉及來自在傳送方法(deliverymethod)元素212下設置的屬性227之中的會話描述uri(sessiondescriptionuri)屬性228,
v=…
o=…
s=…
t=…
a=atsc-mode:frequencypipeid(bbpstreamid){具有在頻率內的不同頻率和調制/編碼參數的發(fā)送管道的id}
a=flute-tsi:(tsi-傳輸會話標識符)
s=sourcefilter:inip4ipaddress(源ip地址)
m=applicationport(端口號)flute/udp
c=inip4ipaddress(目標ip地址)
圖17示出根據上述信息指定的文件指定配置。
根據flute(route)協(xié)議傳輸的所有文件存儲在ip分組上的udp分組上的lct分組中并被傳輸。
在flute的情況下,文件由sdp指示的源ip地址(sourceipaddress)、目標ip地址(destinationipaddress)、端口號(port)和tsi指定。這是在flute會話的單元中進行的)。
源ip地址(sourceipaddress)和目標ip地址(destinationipaddress)用于指定ip分組,端口號(port)用于指定udp分組,而tsi用于指定lct分組字符串。
此外,通過存儲在lct分組中的toi(transportobjectidentifier)指定期望的文件。
文件描述表(fdt)存儲在toi為0的lct分組中,并且解析在每個文件url(存儲在fdt-instance/file/@contentlocatoin中)和對應的toi(存儲在fdt-instance/file/@toi)之間的關系,以用于由相同tsi指定的傳輸會話中的其他文件對象。
另一方面,圖18是示出當根據route協(xié)議進行文件傳輸時在傳送方法(deliverymethod)元素212中設置的flute的參考信息的示例的圖。
如圖18所示的以下信息被記錄為sdp,其如圖18所示涉及來自在傳送方法(deliverymethod)元素212下設置的屬性(屬性)227之中的會話描述uri(sessiondescriptionuri)屬性228:
v=…
o=…
s=…
t=…
a=atsc-mode:frequencypipeid(bbpstreamid){具有在頻率內的不同頻率和調制/編碼參數的發(fā)送管道的id}
s=sourcefilter:inip4ipaddress(源ip地址)
m=applicationport(端口號)route/udp
c=inip4ipaddress(目標ip地址)
圖19示出根據上述信息指定的文件指定配置。
在route的情況下,文件由sdp指示的源ip地址(sourceipaddress)、目標ip地址(destinationipaddress)和端口號(port)指定。其在route會話的單元中進行。
源ip地址(sourceipaddress)和目標ip地址(destinationipaddress)用于指定ip分組,且端口號用于指定udp分組。
在route會話中,lct會話實例描述(lsid)存儲在lct分組的tsi為0的lct分組中,并且toi為0,并且在route會話中存儲用于其他傳輸會話的屬性(由lct分組的tsi指定)存儲。解析在contentlocation屬性(用作lsid的transportsession/sourceflow/efdt/file元素的屬性)與toi(通過toi屬性與文件url對應)之間的關系。
如上面參考圖12所描述的,
信令數據(元數據)具有如圖12所示的以下三個層:
(1)服務層(oma-esg)
(2)文件傳輸會話層(3gpp-mbms-usd)
(3)flute(route)參數層(flute(route))。
flute(route)參數層(flute(route))包括描述了整個文件傳輸會話的flute的fdt(fdt實例)元素或描述了會話中攜帶的每個文件的屬性的文件元素。文件url存儲在作為文件元素的屬性的內容位置(content-location)屬性中。
圖20是示出構成信令數據的在flute(route)參數層中的fdt實例元素下的數據存儲配置的示圖。
在fdt實例元素301下,
集合是對應于fdt實例的屬性302以及
文件元素303
此外,在文件元素303下面,集合為
對應于文件的屬性304。
圖21(a)和21(b)示出了與fdt實例對應的屬性302和與該文件對應的屬性304的詳細配置。
文件url被存儲在與如圖21所示的文件對應的屬性304中設置的內容位置(content-location)屬性記錄區(qū)域305中。
另一方面,對于route,在flute中指定的文件元素被存儲在lsid(用作route中規(guī)定的信令數據)中。
圖22示出在route中規(guī)定的lsid下的數據配置。
如圖22所示,如下進行分層設置:
lsid元素351;
傳輸會話(transportsession)元素352;
源流(sourceflow)元素353;
efdt元素354;和
文件元素355。
如圖22所示,在route的情況下,設置了lsid/transportsession/sourceflow/efdt元素,作為描述了整個文件傳輸會話的數據元素,此外,存在文件元素355,其描述了在會話中攜帶的每個文件的屬性。這與上述flute的情況下的文件元素相同。
文件url存儲在作為文件元素355的屬性的內容位置(content-location)屬性記錄區(qū)域中。
圖23(a)和23(b)示出在圖22所示的屬性記錄區(qū)域的詳細配置,即,(a)efdt元素354單元的屬性數據元素361和(b)文件355單元的屬性數據元素362。
文件url記錄在如圖23所示的與文件對應的屬性362中的內容位置(content-location)屬性記錄區(qū)域363中,。
當通信協(xié)議是flute時,接收設備(客戶端)30的中間件分析(解析)fdt(fdt實例)。當通信協(xié)議是route時,接收設備(客戶端)30的中間件可以分析(解析)lsid并檢測通過文件傳輸會話傳輸的文件url。
接收設備(客戶機)30基于文件url檢查url路徑的上級部分記錄在上面參照圖15描述的usd的基本模式記錄區(qū)225和226中的哪一個中。
換句話說,可以通過檢查包括在以下記錄區(qū)域中的哪一個而確定傳送是廣播流傳送還是網絡傳送:
基本模式記錄區(qū)域225=[r12:broadcastappservice/basepattern];和
在bundledescription/userservicedescription/deliverymethod下的基本模式記錄區(qū)域226=[r12:unicastappservice/basepattern]。
當它被包括在基本模式記錄區(qū)域225中時,進行廣播流傳送。
當其包括在基本模式記錄區(qū)域226中時,進行經由網絡的傳送。
需注意,當它包括在基本模式記錄區(qū)域225和226中時,它指示經由網絡的傳送與廣播流傳送一起進行。
[9.重定向策略的控制]
接下來,將描述用于根據接收設備(設備)、接收設備的用戶、數據傳送時區(qū)等控制是否接收經由廣播的數據傳送或經由網絡的數據傳送的配置。
如上所述,接收設備30可以基于記錄在用戶業(yè)務描述(usd)中的數據獲得計劃要獲取的文件url并且使用獲得的文件url獲取預定數據文件(內容、應用、服務工作者(sw)或其他數據文件),該用戶業(yè)務描述(usd)是從發(fā)送設備發(fā)送的信令數據。
例如,當在接收設備30的瀏覽器上的應用使用某個文件url進行文件獲取請求時,如果經由廣播傳送目標文件,則從以上參考圖15描述的基本模式記錄區(qū)域225獲取url基本模式。
換句話說,從bundledescription/userservicedescription/deliverymethod下的基本模式記錄區(qū)域225=[r12:broadcastappservice/basepattern]獲取url基本模式。
文件url的路徑(整個路徑或者從頭開始的部分)存儲在基本模式記錄區(qū)域225中。在這種情況下,圖7所示的http代理服務器120的地址解析單元(廣播/寬帶地址解析器)123進行用于從廣播流獲取文件的設置,并且不經由網絡進行獲取。
圖24的(1)示出在經由廣播傳送的情況下的usd的記錄信息和可以經由廣播獲取的文件的url的示例。
另一方面,例如,當在接收設備30的瀏覽器上的應用使用某個文件url進行文件獲取請求時,如果經由網絡傳送目標文件,則從參考圖15所述的模式記錄區(qū)域226獲取url基本模式。
換句話說,從bundledescription/userservicedescription/deliverymethod下的基本模式記錄區(qū)域226=[r12:unicastappservice/basepattern]中獲取url基本模式。
文件url的路徑(整個路徑或者從頭開始的部分)存儲在基本模式記錄區(qū)域226中。在這種情況下,所圖7所示的http代理服務器120的地址解析單元(廣播/寬帶地址解析器)123經由網絡進行文件獲取。
圖24的(2)示出在經由網絡傳送的情況下的usd的記錄信息和可以經由網絡獲取的文件的url的示例。
需注意,當可以從基本模式記錄區(qū)域225和基本模式記錄區(qū)域226這兩者獲取文件url的路徑(整個路徑或者從頭開始的部分)時,圖7所示的http代理服務器120的地址解析單元(廣播/寬帶地址解析器)123進行從廣播流獲取文件的嘗試,但當經由網絡的獲取比經由廣播的文件獲取更快完成時(例如,當在網絡帶寬存在余量,并且在網絡路徑上的網絡配置設備的資源或文件服務器的可用容量足夠時),存在經由網絡進行獲取的情況,并且其也響應于請求源客戶端應用。
[9.1.允許經由網絡的獲取傳送數據的示例1]
接下來,將描述以下配置:執(zhí)行控制使得根據接收設備或其用戶允許或不允許接收待經由網絡傳送的數據文件,例如用作服務工作者(sw)管理對象的資源(應用文件或應用相關數據文件),或其他文件(內容、應用、服務工作者(sw)或其他數據文件)。
類(組)分配至接收設備(客戶端)30或擁有接收設備(客戶端)30的用戶。
控制是否可以根據類經由網絡獲取文件。
換句話說,使用信令數據進行控制,在所述信令數據中包括類信息,該類信息用于指示允許經由網絡進行數據接收的一組接收設備或用戶。
對于該控制,網絡傳送數據接收允許的類(allowedclass)屬性信息記錄在單播應用服務(unicastappservice)元素224中設置的屬性記錄區(qū)域371的數據記錄區(qū)域(任何)372中,該單播應用服務元素224是在圖25所示的usd中的傳送方法(deliverymethod)元素的下級元素。
這是因為取決于傳送服務提供商,當在網絡路徑上的網絡配置設備的資源或者文件服務器的可用容量不足時,存在期望僅允許高級類的用戶(設備)通過網絡進行訪問的操作要求。
例如,網絡傳送數據接收允許類(permittedclass)屬性的xml方案定義假定為以下定義:
<xs:attributename="permittedclass"type="stringlisttype"xmlns:xs="http://www.w3.org/2001/xmlschema"/>
<xs:simpletypename="stringlisttype"xmlns:xs="http://www.w3.org/2001/xmlschema">
<xs:listitemtype="xs:string">
</xs:simpletype>
基于上述定義,以下類標識符被存儲作為允許經由網絡的訪問的類的類標識符:
<unicastappservicepermittedclass="classn,classm">
例如,當設置和傳送包括圖26所示的信令數據的usd時,只有被分配了記錄在usd中的類n(classn)或類m(classm)的接收設備(客戶端)或用戶可以經由網絡獲取文件。
例如,僅當類n或類m被分配給自己時(例如,通過api參考接收設備(設備)或者使用設備的用戶的類),已經從由接收設備(客戶端)30正在執(zhí)行的應用接收到文件獲取請求的http中間件120的地址解析單元(廣播/寬帶地址解析器)123進行經由網絡的訪問。未分配類的設備僅使用通過廣播的傳送。
需注意,類信息被記錄在接收設備的存儲器中作為注冊信息,并且api參考注冊信息。
需注意,對于類設置,例如,可以基于各種條件進行分類,諸如根據接收其中設備或用戶所在的區(qū)域單元的分類或根據預先注冊的設備信息或用戶信息的分類。
[9.2.經由網絡的傳送數據獲取允許示例2]
對于執(zhí)行以下控制的配置:該控制使得根據接收設備或其用戶允許或不允許接收待經由網絡傳送的數據文件,例如,用作服務工作者(sw)的管理對象的資源(應用文件或應用相關數據文件))或其他文件(內容、應用、服務工作者(sw)或其他數據文件),除了以上配置外,傳送多條usd和分配usd至與接收設備(設備)或用戶對應的類的方法也是被考慮的。
在這種情況下,如圖27所示,目標類(targetclass)屬性被記錄在作為usd元素的根元素的用戶業(yè)務束描述(userservicebundledescription)元素下的屬性數據記錄區(qū)域381中的數據記錄字段(任何)382中。
目標類(targetclass)指示與被允許接收與記錄在用戶業(yè)務描述(usd)中的信令數據對應的數據文件的接收設備(客戶端設備)或用戶相關聯的類。
例如,目標類(targetclass)屬性的xml方案定義假設為以下定義:
<xs:attributename="targetclass"type="stringlisttype"xmlns:xs="http://www.w3.org/2001/xmlschema"/>
<xs:simpletype
name="stringlisttype"xmlns:xs="ttp://www.w3.org/2001/xmlschema"
<xs:listitemtype="xs:string">
</xs:simpletype>
定義如上所述進行。目標類標識符例如被存儲為以下設置:
<unicastappservicetargetclass="classn,classm">
例如,當設置和傳送圖28所示的包括信令數據的usd-1和usd-2時,僅一組被分配了類classn或classm的接收設備(客戶端設備)或者用戶可以使用usd-1并且經由網絡獲取文件。
在usd-1中,記錄與廣播傳送文件對應的文件url的基本模式,并且還記錄與經由網絡傳送的網絡傳送文件對應的文件url的基本模式。
允許使用該usd-1的類(n類或m類)的接收設備或用戶可以使用與廣播傳送文件相對應的文件url的基本模式和與網絡傳送文件對應的文件url的基本模式,并且經由廣播和網絡這兩者獲取文件,其中,文件url的基本模式從usd-1中獲取。
然而,除被允許使用usd-1的類(n類或m類)的用戶或接收設備之外的接收設備或用戶可以僅使用usd-2。
僅與廣播傳送文件對應的文件url的基本模式被記錄在usd-2中。
因此,除了類(n類或m類)的接收設備或用戶之外的接收設備或用戶僅可以使用與從usd-2獲得的與廣播傳送文件對應的文件url的基本模式,并且僅經由廣播獲取文件。
需注意,可以以各種形式分配在可以使用usd-1的類n或m的接收設備中的類的設置。
例如,可以根據用于允許經由網絡獲取數據的設備的能力設置類,例如,可以將這樣的設備設置為類n或m:其內的緩存單元121中不存在足夠空間,其中,該緩存單元121是在如圖7所示的http代理服務器120中的存儲廣播傳送文件的緩存。
另選地,可以根據隨時改變的狀態(tài)信息(諸如設備的用戶的網絡的擁塞狀態(tài))來分配類,該網絡可以是設備直接連接到的家庭局域網或者在家庭和網絡提供商的核心網絡之間的接入網絡。
另外,可以進行類分配以反映設備的終端用戶的獲取指令趨勢(例如,其中總是依賴于廣播傳送的趨勢或其中總是選擇經由網絡的訪問的趨勢)。
如上所述,存在各類的類型,并且可以靈活地改變和設置使用usd的目標設備的特性。
[9.3.經由網絡的傳送數據獲取允許示例3]
允許根據接收設備及其用戶接收或不接收經由網絡傳送的數據文件,例如由服務工作者(sw)作為管理對象的資源(應用文件、應用數據文件),或其他文件(內容、應用、服務工作者(sw))。除了上述配置之外,還可以通過時區(qū)進一步控制。
在圖29示出用于根據時區(qū)實現控制的usd的示例。
圖29所示的示例是用于控制時區(qū)的設置,在該時區(qū)中,傳送以上參考圖28描述的兩個usd(即,usd-1和usd-2)。
從左到右經過的時間軸在圖29中示出。
時間t0至t1例如是午夜,即其中網絡負載相對較低的時區(qū)。
時間t1至t2是白天,即其中網絡負載相對高的時區(qū)。
在網絡負載相對較低的時區(qū)t0至t1中,傳送兩個uisd,即usd-1和usd-2。
另一方面,在網絡負載相對較高的時區(qū)t1至t2中,僅傳送usd-2。
在網絡負載相對低的時區(qū)t0至t1中,與允許使用usd-2的類(類n或m)相關聯的用戶接收設備(客戶端)或可以經由網絡獲取文件。
另一方面,在網絡負載相對較高的時區(qū)t1至t2中,不傳送usd-2,并且所有接收設備(客戶端)經由廣播進行文件獲取。
如上所述,可以通過根據時區(qū)改變要傳送的usd來控制傳送路線。
需注意,因為usd信令數據被設置使得當接收設備30使用usd信令數據時使用最新的信令數據,所以可以根據時區(qū)進行控制。可以預先定義usd的時區(qū)和配置,并且還可以考慮根據網絡的動態(tài)變化動態(tài)地改變usd的配置的操作。
[10.發(fā)送設備和接收設備的示例配置]
接下來,將參照圖30和圖31描述作為通信設備的發(fā)送設備(服務器)20和接收設備(客戶端)30的示例性設備配置。
圖30示出發(fā)送設備(服務器)20和接收設備(客戶端)30的示例性配置。
發(fā)送設備(服務器)20包括數據處理單元751、通信單元752和存儲單元753。
接收設備(客戶端)30包括數據處理單元771、通信單元772、存儲單元773、輸入單元774和輸出單元775。
數據處理單元包括通信數據處理單元771a和再現處理單元771b。
發(fā)送設備(服務器)20的數據處理單元751執(zhí)行用于執(zhí)行數據傳送服務的各種數據處理。例如,數據處理單元751進行數據傳送服務的配置數據的生成和傳送控制。此外,數據處理單元751進行應用、服務工作者(sw)、各種其他數據和待提供給接收設備(客戶端)30的信令數據的生成和發(fā)送處理。
通信單元752還進行通信處理,諸如傳送應用、服務工作者(sw)、各種其它數據、信令數據等(除了av段)。
存儲單元753存儲待傳送的av段、應用和服務工作者(sw),應用使用的數據,信令數據等。
此外,存儲單元753被用作由數據處理單元751進行的數據處理的工作區(qū)域,并且還用作各種參數的存儲區(qū)域。
另一方面,接收設備(客戶端)30包括數據處理單元771、通信單元772、存儲單元773、輸入單元774和輸出單元775。
通信單元772接收從發(fā)送設備(服務器)20傳送的數據,例如,av段、應用、服務工作者(sw)、待由應用使用的數據、信令數據等。
數據處理單元771包括通信數據處理單元771a和再現處理單元771b,并且進行例如根據上述實施例的處理。
具體地,數據處理單元771使用應用、api、服務工作者(sw)等進行數據處理。
經由輸入單元774輸入用戶的指令命令,例如用于頻道選擇、應用激活、安裝等的各種命令。
再現數據被輸出到輸出單元775,諸如顯示單元或揚聲器。
存儲單元773存儲av段、服務工作者(sw)、應用、待由應用使用的數據、信令數據等。
此外,存儲單元773用作由數據處理單元771進行的數據處理的工作區(qū)域,并且還用作各種參數的存儲區(qū)域。
圖31示出可用作發(fā)送設備20和接收設備30的通信設備的示例性硬件配置。
中央處理單元(cpu)801用作數據處理單元,其根據存儲在只讀存儲器(rom)802或存儲單元808中的程序進行各種處理。
例如,cpu801根據上述實施例中描述的順序進行處理。
隨機存取存儲器(ram)803存儲由cpu801執(zhí)行的程序,數據等。cpu801、rom802和ram803經由總線804彼此連接。
cpu801經由總線804連接到輸入/輸出接口805、包括各種開關、鍵盤、鼠標、麥克風等的輸入單元806和包括顯示器、揚聲器等的輸出單元807。cpu801響應于從輸入單元806輸入的命令進行各種處理,并將處理結果輸出到例如輸出單元807。
連接到輸入/輸出接口805的存儲單元808被配置有例如硬盤等,并且存儲由cpu801執(zhí)行的程序和各種數據。通信單元809用作經由網絡諸如因特網或局域網(lan)的數據通信的收發(fā)單元和用于廣播波的收發(fā)單元,并且與外部設備通信。
連接到輸入/輸出接口805的驅動器810驅動可移除介質811諸如磁盤、光盤、磁光盤、半導體存儲器諸如存儲卡,并進行數據的記錄或讀取。
需注意,數據的編碼或解碼可以作為用作數據處理單元的cpu801的處理來執(zhí)行,但是可以提供用作專用硬件(用于執(zhí)行編碼處理或解碼處理)的編解碼器。
[11.本公開的配置的結論]
已經參考具體示例詳細描述本公開的實施例。然而,顯而易見的是,領域技術人員可以在不脫離本公開的要旨的情況下對實施例進行修改或替換。換句話說,該實施例旨在將本發(fā)明公開為示例性形式,而不旨在以限制的方式解釋。為了確定本公開的要旨,應當考慮以下闡述的權利要求。
注意,本說明書中公開的技術可以具有以下配置。
(1)一種接收設備,包括:
數據處理單元,接收其中記錄了類信息的信令數據,并且根據所述類信息確定是經由廣播還是經由網絡進行所述數據接收,所述類信息指示允許經由網絡進行所述數據接收的一組接收設備或用戶。
(2)根據(1)所述的接收設備,
其中類標識符記錄在所述信令數據中,
所述數據處理單元確定在所述信令數據中記錄的所述類標識符與預先分配至所述接收設備或所述用戶的類標識符是否相同,以及
當在所述信令數據中記錄的類標識符與預先分配至所述接收設備或所述用戶的類標識符相同時,經由所述網絡進行所述數據接收。
(3)根據(1)或(2)所述的接收設備,
其中類標識符記錄在所述信令數據中,
所述數據處理單元確定在所述信令數據中記錄的所述類標識符與預先分配至所述接收設備或所述用戶的類標識符是否相同,以及
當在所述信令數據中記錄的所述類標識符與預先分配至所述接收設備或所述用戶的類標識符不相同時,經由所述廣播進行所述數據接收。
(4)根據(1)至(3)中任一項所述的接收設備,
其中,用作應用于經由廣播波或網絡的數據接收的數據訪問信息的url基本模式被記錄在所述信令數據中,并且
所述數據處理單元應用能夠從所述信令數據獲取的url基本模式并進行數據獲取。
(5)根據(1)至(4)中任一項所述的接收設備,
其中,類標識符和用作應用于經由廣播波或網絡的數據接收的數據訪問信息的和url基本模式被記錄在所述信令數據中,并且
所述數據處理單元確定在所述信令數據中記錄的所述類標識符與預先分配至所述接收設備或所述用戶的類標識符是否相同,以及
當在所述信令數據中記錄的所述類標識符與預先分配至所述接收設備或所述用戶的所述類標識符相同時,應用被記錄在所述信令數據中且應用于經由所述網絡的所述數據接收的所述url基本模式被應用,并且進行經由所述網絡的數據獲取。
(6)根據(1)至(5)中任一項所述的接收設備,
其中,所述接收設備能夠接收兩種類型的信令數據,所述兩種類型的信令數據為其中記錄所述類信息的第一信令數據和其中未記錄所述類信息的第二信令數據,并且
所述數據處理單元確定在其中記錄所述類信息的所述第一信令數據中記錄的所述類標識符與預先分配至所述接收設備或所述用戶的類標識符是否相同,并且
當在其中記錄所述類信息的所述第一信令數據中記錄的所述類標識符與預先分配至所述接收設備或所述用戶的所述類標識符相同時,應用被記錄在所述第一信令數據中記錄且應用于經由所述網絡的所述數據接收的所述url基本模式,并且進行經由所述網絡的所述數據獲取。
(7)根據(6)所述的接收設備,
其中,所述數據處理單元確定在其中記錄所述類信息的所述第一信令數據中記錄的所述類標識符與預先分配至所述接收設備或所述用戶的類標識符是否相同,并且
當在其中記錄所述類信息的所述第一信令數據中記錄的所述類標識符與預先分配至所述接收設備或所述用戶的所述類標識符不相同時,應用被記錄在所述第二信令數據中且應用于經由所述廣播的所述數據接收的所述url基本模式,并且進行經由所述廣播的所述數據獲取。
(8)根據(1)至(7)中任一項所述的接收設備,
其中,所述接收設備根據時區(qū)接收不同設置的信令數據,類信息被記錄在所述信令數據中,并且
基于根據所述時區(qū)接收的所述不同設置的所述信令數據來改變接收路徑。
(9)根據(1)至(8)中任一項所述的接收設備,
其中,在其中記錄所述類信息的所述信令數據是用戶業(yè)務描述(usd),以及
所述數據處理單元參考所述用戶業(yè)務描述(usd)確定是經由所述廣播還是經由所述網絡進行所述數據接收。
(10)根據(1)至(9)中任一項所述的接收設備,
其中,在其中記錄所述類信息的所述信令數據是在用戶業(yè)務描述(usd)中設置的傳送方法(deliverymethod)元素中的數據,以及
所述數據處理單元參考所述用戶業(yè)務描述(usd)的所述傳送方法(deliverymethod)元素確定是經由所述廣播還是經由所述網絡進行所述數據接收。
(11)根據(1)至(10)中任一項所述的接收設備,
其中,所述類是基于所述接收設備或所述用戶的區(qū)域或者基于所述接收設備或所述用戶的注冊信息設置的類。
(12)根據(1)至(11)中任一項所述的接收設備,
其中,構成所述接收設備的所述數據處理單元的中間件根據所述類信息確定是經由所述廣播還是經由所述網絡進行所述數據接收。
(13)根據(1)至(12)中任一項所述的接收設備,
其中,其中記錄了數據傳送信息的信令數據,所述數據傳送信息與用作特定服務工作者(sw)的管理對象的數據相關,所述服務工作者為數據管理程序,以及
所述數據處理單元確定是經由所述廣播還是經由所述網絡進行接收用作所述服務工作者(sw)的所述管理對象的所述數據。
(14)根據(1)至(13)中任一項所述的接收設備,
其中,在所述接收設備的所述數據處理單元中執(zhí)行的應用將數據獲取請求輸出至處理接收數據的所述中間件,并且
響應于所述數據獲取請求,所述中間件分析其中記錄所述類信息的所述信令數據,并且根據作為分析結果的所獲得的所述類信息確定是經由所述廣播還是經由所述網絡進行所述數據接收。
(15)一種發(fā)送信令數據的發(fā)送設備,所述信令數據中記錄了類信息,所述類信息用于指示允許經由網絡進行數據接收的一組接收設備或用戶。
(16)根據(15)所述的發(fā)送設備,
中,所述信令數據為其中記錄了允許經由所述網絡進行所述數據接收的所述接收設備或所述用戶的類標識符和用作應用于經由廣播波或經由網絡的數據接收的數據訪問信息的url基本模式的信令數據。
(17)一種在接收設備中進行的數據處理方法,包括:
由通信單元接收其中記錄了類信息的信令數據,所述類信息指示允許經由網絡進行數據接收的一組接收設備或用戶;和
由數據處理單元根據所述類信息確定是經由廣播還是經由網絡進行所述數據接收。
(18)一種在發(fā)送設備中進行的數據處理方法,包括:
發(fā)送其中記錄了類信息的信令數據,所述類信息指示允許經由網絡進行數據接收的一組接收設備或用戶。
此外,說明書中描述的一系列處理可以通過硬件、軟件或兩者的復雜配置進行。當通過軟件進行處理時,可以將其中記錄有處理順序的程序安裝在結合到專用硬件的計算機的存儲器中并進行該程序,或者可以將程序安裝在能夠執(zhí)行各種處理的通用計算機中并進行程序。例如,程序可以預先記錄在記錄介質中。程序可以從記錄介質安裝在計算機中,并且該程序可以經由網絡諸如因特網或lan接收且安裝在記錄介質諸如內部硬盤中。
注意,本說明書中描述的各種處理不僅可以根據描述按時間順序進行,而且可以根據進行處理的設備的處理性能或根據需要并行或單獨進行。此外,在本說明書中,系統(tǒng)是多個設備的邏輯集合配置并且不限于其中各個組件的設備在系統(tǒng)外殼中的配置。
工業(yè)適用性
如上所述,根據本公開的實施例的配置,實現了接收設備可以基于信令數據確定是否允許經由網絡的數據接收的配置。
具體地,例如,用于指示允許經由網絡進行數據接收的一組接收設備或用戶的類標識符記錄在從發(fā)送設備發(fā)送到接收設備的信令數據中。
接收設備確定類標識符是否與為接收設備或用戶設置的類標識符相同并且當類標識符彼此相同時經由網絡進行數據接收。應用于經由廣播波或網絡數據接收的url基本模式被記錄在信令數據中,并且接收設備進行應用了url基本模式的數據獲取。
根據本配置,實現了接收設備可以基于信令數據確定是否允許經由網絡的數據接收的配置。
參考標記列表
10通信系統(tǒng)
20發(fā)送設備
21廣播服務器
22數據傳送服務器
30接收設備
31tv
32pc
33移動終端
50信令數據
60av段
70其他數據
110中間件
111通信單元(phy/mac)
112信令獲取單元
113信令分析單元
114文件獲取單元
120http代理服務器
121、122緩存單元
123地址解析單元
130輸出控制單元
131顯示數據(例如,html/javascript(注冊商標))獲取&分析單元
132顯示處理單元(渲染器)
133存儲單元(永久緩存)
140外部設備
141輸出控制單元
142存儲單元(永久緩存)
751數據處理單元
752通信單元
753存儲單元
771數據處理單元
772通信單元
773存儲單元
774輸入單元
775輸出單元
801cpu
802rom
803ram
804總線
805輸入/輸出接口
806輸入單元
807輸出單元
808存儲單元
809通信單元
810驅動器
811可移除介質。