專利名稱：條件訪問系統(tǒng)的制作方法
背景技術(shù)：
典型的數(shù)字本地網(wǎng)絡(luò)包括多個設(shè)備，例如無線電接收機、調(diào)諧器/譯碼器、CD播放器、一對揚聲器、電視機、VCR、磁帶機等等。這些設(shè)備通?；ヂ?lián)以允許一種設(shè)備(例如電視機)控制另一種設(shè)備(例如VCR)。諸如調(diào)諧器/譯碼器或者機頂盒(STB)之類的設(shè)備通常是中央設(shè)備，用于在其他設(shè)備之上提供中央控制。控制按鈕和開關(guān)通常位于調(diào)諧器的前端，同時還位于手持遙控裝置上。用戶可以通過中央設(shè)備或者遙控單元來控制所有的設(shè)備。
隨著這些設(shè)備變得越發(fā)通用且越發(fā)復雜，簡單的人工控制已經(jīng)無法再滿足。此外，隨著越來越多的設(shè)備可以利用，所以它們之間的互用性開始成為一個問題。許多供應商使用他們自己的通信協(xié)議來允許他們的設(shè)備交互，但是來自于不同供應商的設(shè)備無法進行交互。為了克服這些問題，已經(jīng)定義了多個互用性標準，這些互用性標準允許不同設(shè)備交換消息和信息，并且允許不同設(shè)備互相控制。一種眾所周知的標準是本地音頻/視頻互用性(Home Audio/VideoInteroperability，HAVi)標準，其1.0版本在2000年1月問世，并且能夠以地址http//www.havi.org/在互聯(lián)網(wǎng)上獲得。其他眾所周知的標準有家用數(shù)字總線(domestic digital bus，D2B)標準、以IEC1030描述的通信協(xié)議以及通用的即插即用(Universal Plug andPlay)(http//www.upnp.org)。
在依照這種標準的系統(tǒng)中，設(shè)備使用諸如IEEE 1394串行通信總線的標準總線在網(wǎng)絡(luò)中互聯(lián)，并且依照所述標準經(jīng)由此網(wǎng)絡(luò)來交換信息，所述信息諸如像消息、數(shù)據(jù)和命令。諸如HAVi之類的標準定義了用于這種交換的協(xié)議，其允許來自于不同供應商的設(shè)備進行交互。用戶可以向網(wǎng)絡(luò)添加新的設(shè)備，并且它們立即可為其他設(shè)備所利用。用于“發(fā)現(xiàn)”這種新設(shè)備的協(xié)議也得到標準化。
在本地內(nèi)數(shù)字網(wǎng)絡(luò)(KDN)中的一些設(shè)備可以具有外部連接。利用這種連接，內(nèi)容可以使用寬帶傳輸或者通過從互聯(lián)網(wǎng)下載而進入網(wǎng)絡(luò)。內(nèi)容還可以通過從諸如數(shù)字化多用途盤(DVD)或者硬盤的存儲介質(zhì)中將其讀出來進入網(wǎng)絡(luò)。
存在于此文獻的解決方案所致力于解決的難題是在保持端對端控制并且在不引入大量復雜性的情況下、如何通過此系統(tǒng)來實現(xiàn)內(nèi)容的安全傳輸。

發(fā)明內(nèi)容
依照本發(fā)明的第一方面，提供了一種條件訪問系統(tǒng)，所述系統(tǒng)包括在網(wǎng)絡(luò)中互聯(lián)的多個設(shè)備，將所述設(shè)備分組成第一組和第二組，第一組的設(shè)備依照第一安全框架操作，而第二組設(shè)備依照第二安全框架操作，每個設(shè)備利用特定的中間件層操作，將所述中間件層設(shè)置為驗證另一個設(shè)備的另一個中間件層，所述中間件層由設(shè)備操作所依照的安全框架來驗證。
網(wǎng)絡(luò)中的所有設(shè)備都執(zhí)行安全框架。利用這個框架，這些設(shè)備可以互相驗證，并且安全地分配內(nèi)容以及訪問由安全系統(tǒng)管理的內(nèi)容。這樣做可以防止未保護的內(nèi)容“泄漏”到未被授權(quán)的設(shè)備。為此，所述設(shè)備必須彼此信任，并且必須相信他們自己的中間件層以及另一個設(shè)備的安全框架。本發(fā)明避免了安全框架必須驗證系統(tǒng)中的每個中間件層并且必須支持專用于所有不同中間件層的各種中間件。
在一實施例中，來自于第一組的設(shè)備通過對來自于第二組的設(shè)備的中間件層進行遠程過程調(diào)用(RPC)可以執(zhí)行第二安全框架的功能。此實施例允許安全框架互相定位以及進行通信，并且獨立于HN-MW以及網(wǎng)絡(luò)技術(shù)。
在進一步的實施例中，將RPC經(jīng)由安全驗證通道(secureauthenticated channel，SAC)發(fā)送到來自于第二組的設(shè)備中。這樣允許想要相互通信的安全框架安全地執(zhí)行此操作。當多個安全設(shè)備存在于網(wǎng)絡(luò)中時，可以將它們之間的SAC集合看作為虛擬專用網(wǎng)絡(luò)(VPN)。
在進一步的實施例中，所述設(shè)備被允許依照目的的特定類來訪問內(nèi)容，定義了這種類的集合，每個類都包括多個條件訪問操作或者目的。所述中間件將處理在所述類范圍內(nèi)的這些內(nèi)容的內(nèi)容。
優(yōu)選的是，來自于所述集合的第一類包括操作RENDER(顯示)、MOVE(移動)和COPY(復制)。此外優(yōu)選的是，來自于所述集合的第二類包括操作STORE(存儲)、RENDER(再現(xiàn))、EDIT(編輯)、DELETE(刪除)和PROCESS(處理)。在進一步的實施例中，優(yōu)選的是，PROCESS操作獨立于對與所述內(nèi)容相關(guān)聯(lián)的權(quán)限的任何限制而被授權(quán)。所述PROCESS操作允許網(wǎng)絡(luò)中適應的設(shè)備訪問受保護內(nèi)容，以便在不改變所述權(quán)限的情況下、執(zhí)行不改變有關(guān)內(nèi)容的權(quán)限的操作。這種操作的例子是內(nèi)容和比特率代碼轉(zhuǎn)換、需要支持特技播放的處理、圖像改善。
依照本發(fā)明的第二方面，提供了一種用于允許設(shè)備有條件地訪問一條內(nèi)容的方法，其中所述設(shè)備被允許依照目的的特定類來訪問內(nèi)容，定義了這種類的集合，每個類包括多個條件訪問操作或者目的。
在一實施例中，來自于所述集合的第一類包括操作STORE(存儲)、RENDER(顯示)、EDIT(編輯)、DELETE(刪除)和PROCESS(處理)。在進一步的實施例中，PROCESS(處理)操作獨立于對與內(nèi)容相關(guān)聯(lián)的權(quán)限的任何限制而被授權(quán)。


本發(fā)明的這些及其他方面將通過參照附圖中所示的例證性的實施例的闡明而更加顯而易見，其中圖1示意性地舉例說明了依照本發(fā)明的本地內(nèi)網(wǎng)絡(luò)的優(yōu)選布局，其包括一個源、一個匯點(sink)以及兩個存儲介質(zhì)；圖2舉例說明了權(quán)限管理與保護(RMP)的優(yōu)選安全框架的基本結(jié)構(gòu)；圖3描述了從一個安全框架發(fā)送到另一個安全框架的消息；圖4舉例說明了如何利用RPC調(diào)用對OPIMA OVM的公共接口進行調(diào)用。
圖5舉例說明了如何實現(xiàn)分布式內(nèi)容訪問；以及圖6舉例說明了如何優(yōu)選地管理RPC調(diào)用。
貫穿整個附圖，相同的參考標記表示相同或相應的特征。附圖中表示的一些特征通常以軟件來實現(xiàn)，并且照此表示軟件實體，諸如軟件模塊或者對象。
具體實施例方式
本地內(nèi)(IN-HOME)網(wǎng)絡(luò)體系結(jié)構(gòu)圖1示意性地舉例說明了依照本發(fā)明的本地內(nèi)網(wǎng)絡(luò)的優(yōu)選布局，包括一個源、一個匯點以及兩個存儲介質(zhì)S1和S2。將網(wǎng)絡(luò)在概念上按照條件訪問(CA)域和復制保護(CP)域來分隔。
大多數(shù)的內(nèi)容進入本地內(nèi)網(wǎng)絡(luò)的CA域中，所述內(nèi)容通常包括像音樂、歌曲、電影、TV節(jié)目、圖像等等的東西。所述源可以連接到寬帶電纜網(wǎng)絡(luò)、互聯(lián)網(wǎng)聯(lián)接、衛(wèi)星下行鏈路等等?？梢詫⒂眠@種方式接收的內(nèi)容存儲在存儲介質(zhì)S1中，從而稍后可以讀出并且顯示在匯點上。所述存儲介質(zhì)S1可以是某些類型的個人數(shù)字記錄器(PDR)，例如DVD+RW記錄器。源還可以是DVD播放器，其中可以插入DVD盤，從而可以從所述盤中讀取內(nèi)容。
顯示內(nèi)容項的確切方式取決于匯點類型以及內(nèi)容類型。舉例來說，在無線電接收機中，顯示包括產(chǎn)生音頻信號并且將它們饋送到擴音器。對于電視接收機來說，顯示包括產(chǎn)生音頻與視頻信號并且將它們饋送到顯示屏幕以及擴音器。對于其他類型的內(nèi)容來說，必須采取相似的適當動作。顯示還可以包括諸如譯碼或者去擾所接收的信號、使音頻與視頻信號同步等等的操作。
舉例來說，匯點可以是電視系統(tǒng)或者音頻回放設(shè)備。通常，所述匯點位于CP域。這樣可以確保當向匯點提供內(nèi)容時，由于CP域中適當位置上的復制保護而不可以產(chǎn)生內(nèi)容的未被授權(quán)的副本。所述CP域包括存儲介質(zhì)S2，在所述存儲介質(zhì)S2上可以依照復制保護規(guī)則來存儲內(nèi)容的(臨時)副本。
用于實現(xiàn)安全框架的本地內(nèi)網(wǎng)絡(luò)中的所有設(shè)備都依照實施要求來這樣做。利用此框架，這些設(shè)備可以互相驗證，并且安全地分配內(nèi)容以及訪問由安全系統(tǒng)管理的內(nèi)容。這樣做可以防止未保護的內(nèi)容“泄漏”到未被授權(quán)的設(shè)備。
安全框架圖2說明了用于權(quán)限管理與保護(RMP)的優(yōu)選安全框架的基本結(jié)構(gòu)。此安全框架依照TV Anytime Call For Contributions(CFC)來定義，參見位于http//www.tv-anytime.org/cfcs/的TV Anytime網(wǎng)站。在圖2中，描述了以下元件-應用程序API允許應用程序依照共同操作的方式與RMP系統(tǒng)進行通信。
-應用程序能夠使用戶依照RMP條件訪問內(nèi)容和PDR特征的軟件和/或服務(wù)。
-基線RMP系統(tǒng)所述功能遵循TV Anytime RMP基線規(guī)范。
-專有RMP系統(tǒng)經(jīng)由RMP服務(wù)API與TVA RMP基線系統(tǒng)接口的專有內(nèi)容保護系統(tǒng)。
-RMP信息管理器判定對內(nèi)容允許什么樣的動作，例如播放、復制、移動等，并且可以將密鑰傳遞到安全工具。
-RMP服務(wù)API允許RMP系統(tǒng)依照能共同操作的方式與RMP基線安全功能進行通信。
-RMP系統(tǒng)功能層實現(xiàn)基線系統(tǒng)的功能集合。
-RMP系統(tǒng)管理器管理基線系統(tǒng)的操作。
-安全工具盡可能地包含解擾器、水印檢測器/嵌入器、簽名檢驗器等等。
-對TVA基線RMP系統(tǒng)的標準化增強對TVA RMP基線系統(tǒng)的可選TVA標準化擴展。
-TVAF RMP基線設(shè)備接口TVA適應設(shè)備之間的安全通信層。
此文獻提供了以下系統(tǒng)元件的解決方案-應用程序API-RMP服務(wù)API-設(shè)備間通信應用程序API當必須開發(fā)來自于第三方的軟件時需要標準化的API。因此，只對具有此需求的平臺要求標準化的應用程序API。這種平臺的例子有支持下載的應用程序的平臺。只有對這種設(shè)備，才需要應用程序API。
DAVIC CA-API(DAVIC(Digital Audio-Visual Council)，于1998年提出的DAVIC 1.4規(guī)范，http//ww.davic.org/)被推薦為應用程序API。DAVIC CA API提出使用來自于應用程序的受保護內(nèi)容所需要的大多數(shù)功能。然而，可能需要一些擴展來尋址與存儲器和網(wǎng)絡(luò)相關(guān)的出口。
RMP服務(wù)APIRMP服務(wù)API允許RMP系統(tǒng)依照能共同操作的方式與RMP基線安全功能進行通信。所述RMP服務(wù)API應該包括來自于OPIMA的方法的子集，如在這一節(jié)里所給出的。在以后幾節(jié)里，用于RMP API的OPIMA方法依照功能而被分組。對于OPIMA來說，參見OPIMA(Open PlatformInitiative for Multimedia Access)，1.1,2000規(guī)范版本，網(wǎng)址為http//www.cselt.it/opima/，將這部分內(nèi)容引入于此，以供參考。
內(nèi)容訪問這一部分反映了‘抽象(Abstract)內(nèi)容訪問’接口的接口定義、OPIMA標準的3.3.4.7節(jié)。經(jīng)由這個接口，應用程序可以表明對內(nèi)容所要求的動作。
在OPIMA中，當RMP決定不再允許訪問內(nèi)容時(例如，因為內(nèi)容規(guī)則在訪問權(quán)限方法發(fā)生改變)，RMP系統(tǒng)在內(nèi)容的停止動作上不具有控制。對于RMP系統(tǒng)可用的唯一機制在于向OPIMA虛擬機(OVM)發(fā)送錯誤解密密鑰。此舉是否會導致系統(tǒng)崩潰，取決于OVM的實現(xiàn)。作為另外的方法，更加適度地停止內(nèi)容訪問是必要的。
應該將以下方法用于內(nèi)容訪問-installCallbackContentAccess-AbstractContentAccess-replyToContentAccess可選擇的是，可以使用以下附加的方法-stopContent(ContentId)訪問規(guī)則/密鑰這一部分反映了‘規(guī)則抽象訪問’接口的接口定義、OPIMA標準的3.3.4.8節(jié)。經(jīng)由這個接口，RMP系統(tǒng)可以表明其希望接收的規(guī)則/權(quán)限數(shù)據(jù)。
應該將以下方法用于用戶交互-obtainUserRules-obtainContentRules-newRules-updateContentRules可選擇的是，可以使用以下附加的方法-addContentRules智能卡這一部分反映了‘智能卡’接口的接口定義、OPIMA標準的3.3.4.6節(jié)。所述RMP系統(tǒng)可以通過此系統(tǒng)來訪問智能卡，并且發(fā)送/接收標準ISO 7816 APDU。
應該將以下方法用于智能卡交互-addCTListener-removeCTListener-cardInserted-cardRemoved-getSlotId-isCardPresent-openSlotChannel-closeSlotChannel-getATR-reset-sendAPDU加密與解密這一部分反映了‘加密與解密引擎’接口的接口定義、OPIMA標準的3.3.4.3節(jié)。所述RMP系統(tǒng)可以經(jīng)由這個接口來控制內(nèi)容加密以及對雜項數(shù)據(jù)的加密動作。
應該將以下方法用于加密與解密-queryEncryptionAlgorithms-encrypt-initEncryption-updateEncryptionKeys-stopEncryption-decrypt-intiDecryption-updateDecryptionKeys-stopDecryption簽名這一部分反映了‘簽名引擎’接口的接口定義、OPIMA標準的3.3.4.4節(jié)。經(jīng)由這個接口，RMP系統(tǒng)可以檢驗并且產(chǎn)生內(nèi)容上的簽名以及雜項數(shù)據(jù)上的簽名兩者。
應該將以下方法用于簽名-querySignatureAlgorithms-verifySignature-verifyContentSignature-generateSignature-generateContentSignature水印此部分反映了‘水印引擎’接口的接口定義、OPIMA標準的3.3.4.5節(jié)。經(jīng)由此接口，RMP系統(tǒng)可以檢測并且將水印嵌入內(nèi)容中。
應該將以下方法用于水印-queryWatermarkAlgorithms-extractWatermark-stopWatermarkExtraction-insertWatermark-stopWatermarkInsertionRMP訪問這一部分反映了‘OPIMA對等抽象訪問’接口的接口定義、OPIMA標準的3.3.4.9節(jié)。經(jīng)由這個接口，基線系統(tǒng)可以彼此交互。
應該將以下方法用于RMP系統(tǒng)之間的交互-openConnection-colseConnection-addConnectionListener-sendMessage-newConnection-receiveMessageFromPeer用戶交互這一部分反映了‘用戶接口’的接口定義、OPIMA標準的3.3.4.1節(jié)。經(jīng)由這個接口，用戶可以與RMP系統(tǒng)交換信息。
應該將以下方法用于用戶交互-sendMessageToUser-receiveMessageFromPeer所述receiveMessageFromPeer方法只允許在RMP系統(tǒng)和用戶之間傳輸字符串。所述RMP系統(tǒng)不能控制信息的格式化和顯示。為了在receiveMessageFromPeer方法中支持這種格式化，消息文本值應該依照作為CENELEC EN 502211997標準化的公用接口高級MMI消息，用于條件訪問的公用接口及其他數(shù)字視頻譯碼器應用程序；以及CENELEC R 206-0011997，DVB 15譯碼器應用程序的公用接口的實現(xiàn)和使用的方針。
應用程序交互這一部分反映了‘應用程序抽象訪問’的接口定義、OPIMA標準的3.3.4.10節(jié)。這個接口定義了應用程序和RMP系統(tǒng)之間的透明的位通道。
在DVB框架中，可以存在多個應用程序和多個RMP系統(tǒng)。因此，采用一些特定的方法將會增強這個接口，以便能夠進行應用程序和RMP系統(tǒng)之間、對一些基本功能的互用性。
應該將以下方法用于應用程序交互-installCallbackApplication-replyMessage-receiveMessageFromApplication以下擴展是可選的所述receiveMessageFromApplication方法應該包含附加的消息類型‘QUERY_ENTITLEMENT’。作為此消息類型的響應，RMP系統(tǒng)應該經(jīng)由標準的‘replyMessage’返回當前用戶可得到的權(quán)限的列表。
生存期控制這一部分反映了‘生存期控制’接口的接口定義、OPIMA標準的3.3.4.11節(jié)。
應該將以下方法用于生存期控制-initialize(初始化)-terminate(終止)-update(更新)-remove(移除)TVAF RMP基線設(shè)備接口所述設(shè)備接口應該提供TVA適應設(shè)備之間的安全通信層。與這個接口相關(guān)的元件包括安全框架與其他系統(tǒng)元件的關(guān)系，所述其他系統(tǒng)元件類似于本地網(wǎng)絡(luò)中間件(例如UPnP、HAVi和Jini)。此外，這些設(shè)備之間的適應設(shè)備和安全通信的驗證通過基線設(shè)備接口來尋址。已經(jīng)將所述設(shè)備接口定義為OPIMA對本地網(wǎng)絡(luò)的擴展。
基線RMP系統(tǒng)所述基線RMP系統(tǒng)為TVA系統(tǒng)提供標準化復制保護系統(tǒng)。因為其是標準化的并且在實現(xiàn)框架的每個設(shè)備中是強制性的，所以實現(xiàn)基線RMP系統(tǒng)的任何設(shè)備都可以訪問由這個RMP系統(tǒng)保護的內(nèi)容。此外，非常重要的是，基線系統(tǒng)很簡單并且易于實現(xiàn)。由于基線系統(tǒng)還必須由小型廉價的移動裝置來支持，所以這是最重要的。
類似于任何RMP系統(tǒng)的基線RMP系統(tǒng)包括兩個部分密鑰管理和內(nèi)容加密。使用在下一節(jié)中說明的系統(tǒng)，其允許專有的RMP系統(tǒng)使用基線內(nèi)容加密方案來實行端對端控制。雖然沒有建議基線RMP系統(tǒng)，但是建議的任何RMP系統(tǒng)都應該與OPIMA RMP服務(wù)API兼容。
簡單的基線系統(tǒng)應該支持至少所述內(nèi)容規(guī)則copy_free、copy_one_generation、copy_no_more。由于此基線RMP系統(tǒng)將會出現(xiàn)于每個適應的設(shè)備中，所以內(nèi)容加密算法應該低廉、可易于訪問并且穩(wěn)固。由于AES滿足所有這些必要條件，所以優(yōu)選的是使用先進的加密標準(AES)作為基線內(nèi)容加密方案。
基線設(shè)備接口在先前的節(jié)中，介紹了OPIMA系統(tǒng)。OPIMA為應用程序和數(shù)字權(quán)限管理(DRM)系統(tǒng)提供了安全框架以便共同操作。在本節(jié)中，擴展OPIMA系統(tǒng)以便在本地網(wǎng)絡(luò)內(nèi)操作。對于在本地網(wǎng)絡(luò)中使用DRM的介紹，可以參見IBC 2001商業(yè)出版社出版的、由F.L.A.J.Kamperman，S.A.F.A.van den Heuvel，M.H.Verberkt所著的Digital RightsManagement in Home Networks，Philips Research，The Netherlands中的第I卷，第70-77頁。
本地網(wǎng)絡(luò)可以被定義成一組設(shè)備，所述設(shè)備使用某種網(wǎng)絡(luò)技術(shù)進行互聯(lián)(例如以太網(wǎng)、IEEE 1394、藍牙，802.11b，...)。雖然網(wǎng)絡(luò)技術(shù)允許不同的設(shè)備進行通信，但是這不足以允許設(shè)備共同操作。為了能夠這樣做，需要設(shè)備能夠發(fā)現(xiàn)并且尋址網(wǎng)絡(luò)中其他設(shè)備上存在的功能。這種互用性由本地網(wǎng)絡(luò)中間件(HN-MW)提供。本地網(wǎng)絡(luò)中間件的例子有Jini、HAVi、UPnP、AVC。
網(wǎng)絡(luò)技術(shù)以及HN-MW的使用將一組個體設(shè)備改變?yōu)橐粋€大容量的虛擬設(shè)備。根據(jù)HN-MW觀點，可以把網(wǎng)絡(luò)看作為一組可以使用并且連接的功能。這種系統(tǒng)向用戶提供能力以便從本地網(wǎng)絡(luò)中的任何地方尋址任何內(nèi)容或者服務(wù)。
可以將HN-MW定義成提供兩種服務(wù)的系統(tǒng)。它允許網(wǎng)絡(luò)中的應用程序定位網(wǎng)絡(luò)中的設(shè)備與功能。此外，幾種遠程過程調(diào)用機制(RPC)定義了如何使用這些功能。
根據(jù)HN-MW觀點，與處理安全內(nèi)容相關(guān)的系統(tǒng)以多種方式出現(xiàn)。網(wǎng)絡(luò)中確定的功能需要訪問受保護的內(nèi)容。網(wǎng)絡(luò)中的其他功能提供可以由網(wǎng)絡(luò)中處理內(nèi)容安全的元件使用的功能。此外，類似于OPIMA的安全框架可以使用HN-MW來一共同操作的方式互相定位以及進行通信。
安全框架和本地網(wǎng)絡(luò)這段討論此最后的選項如何使用本地網(wǎng)絡(luò)中間件來在安全框架之間進行定位以及通信。在該情況下，可以將安全框架表示為本地網(wǎng)絡(luò)中的功能。這允許安全功能來定位以及尋址網(wǎng)絡(luò)中的其他安全功能。
使用此方法，我們可以定位其他安全框架并且使用它們的功能。這對于常規(guī)應用程序來說足夠了。在應用程序?qū)ぶ钒踩珒?nèi)容的情況下，人們要求內(nèi)容保持安全狀態(tài)，并且保護內(nèi)容的秘訣無法被偵聽。此外，需要另一個安全設(shè)備可以被信任的證據(jù)。
優(yōu)選的是，通過安全驗證通道(SAC)來提供這種功能。當創(chuàng)建SAC時，雙方互相驗證，并且創(chuàng)建加密消息的安全通道。這樣允許想要相互通信的安全框架安全地執(zhí)行此操作。當多個安全設(shè)備存在于網(wǎng)絡(luò)中時，可以將它們之間的SAC集合看作虛擬專用網(wǎng)絡(luò)(VPN)。
在這種VPN內(nèi)，此外的設(shè)備與功能需要被定位以及尋址。因此，需要本地網(wǎng)絡(luò)中間件(HN-MW)在VPN內(nèi)進行操作。當這種功能已經(jīng)存在于系統(tǒng)(用于定位安全設(shè)備的HN-MW)時，可以在VPN范圍內(nèi)再次使用它。
為了這樣做，安全框架將能夠發(fā)送和接收消息，并且應該實現(xiàn)允許使用HN-MW技術(shù)將消息發(fā)送給它的方法(參見附錄E)。
為了更詳細地解釋這一點，圖3描述了從一個安全框架發(fā)送到另一個安全框架的消息。在此圖中，在左邊的灰色塊表示消息報頭，白色塊表示消息體。所述網(wǎng)絡(luò)消息包含HN-MW消息，所述HN-MW消息是對安全功能的遠程過程調(diào)用(RPC)。
遠程過程調(diào)用的數(shù)據(jù)是待由SAC處理的消息體。雖然可以為每個HN-MW標準定義SAC，但是我們建議為所有HN-MW標準使用一個SAC，優(yōu)選的是SSl(RFC 2246)。SAC的數(shù)據(jù)元是再次的遠程過程調(diào)用，但是這次是有關(guān)安全功能的功能。在該情況下，它是OPIMA函數(shù)調(diào)用。然后將所述HN-MW消息并入網(wǎng)絡(luò)消息，并且經(jīng)由本地網(wǎng)絡(luò)發(fā)送。
所述解決方案允許安全框架互相定位以及進行通信，并且獨立于HN-MW以及網(wǎng)絡(luò)技術(shù)。當然，還可以將SAC并入HN-MW或者網(wǎng)絡(luò)技術(shù)。在這種情況下，圖像將會有少許改變，但是功能將會保持。
驗證和信任為了設(shè)備能夠以安全的方式使用受保護的內(nèi)容，網(wǎng)絡(luò)中的RMP系統(tǒng)與安全框架需要互相信任?？梢云诖湃蔚脑O(shè)備在按標準的參數(shù)集內(nèi)工作。為了做到這一點，信任的第三方需要在提供驗證所需密鑰以前先檢驗設(shè)備。
這是使用兩步法來實現(xiàn)的RMP系統(tǒng)驗證TVAF，然后TVAF互相驗證。這樣避免了RMP系統(tǒng)必須驗證系統(tǒng)中的每個TVAF，并且避免了必須支持各種特定HN-MW。
當將RMP系統(tǒng)嵌入設(shè)備時，由于它們能互相信任，可以不需要驗證安全框架。這樣做有下列好處，即可以跳過由RMP系統(tǒng)執(zhí)行的安全框架的驗證(費時的)。
使用遠程工具如上文所釋，在有關(guān)安全框架以及本地網(wǎng)絡(luò)上的節(jié)中，在TVAF之間創(chuàng)建VPN?？梢园阉醋鳛橐粋€大的TVAF。所述VPN可用于本地提供遠程TVAF的工具。在這種情況下，使用對另一個TVAF的公共接口的RPC調(diào)用來進行調(diào)用。在OPIMA OVM(可以用作TVAF)環(huán)境中的這種調(diào)用的例子在圖4中示出。在設(shè)備2上，將調(diào)用和返回經(jīng)由OVM路由，以代表提取并且調(diào)用了具有SAC的RPC。
用于提供網(wǎng)絡(luò)中其它地方執(zhí)行的工具的TVAF的另一個選項是提供直接地可以在HN-MW上可利用的工具。這種工具的最好的例子大概是智能卡閱讀器。與智能卡的通信已經(jīng)受到RMP系統(tǒng)的保護，并且可以經(jīng)由未保護的通道訪問。
此配置允許TVAF提供HN-MW中的工具以及VPN中其他TVAF上可以利用的工具。根據(jù)性能觀點，當可以利用本地工具時，建議使用本地工具。利用常規(guī)的OPIMA API來呈現(xiàn)網(wǎng)絡(luò)化的工具。當然，可以選擇TVAF實現(xiàn)方式來提供網(wǎng)絡(luò)化的工具，但是決不是非得這樣做。
內(nèi)容譯碼、流以及HN-MW當在網(wǎng)絡(luò)化的環(huán)境中訪問內(nèi)容時，所述內(nèi)容可能待從源流入/傳送到其他設(shè)備。在大多數(shù)情況下，這樣需要一些來自網(wǎng)絡(luò)的QoS支持。在網(wǎng)絡(luò)中配置連接的方式以及管理器QoS的方式嚴重依賴于網(wǎng)絡(luò)技術(shù)。通常，使用在HN-MW中所定義的機制來創(chuàng)建并且停止這種流。
由于可以在設(shè)備接口上始終偵聽內(nèi)容，所以離開TVAF的任何內(nèi)容都應用受到保護。通常，使用幾種加密方法來執(zhí)行這一點。所述RMP系統(tǒng)通過控制允許解擾內(nèi)容的訪問密鑰來保持對內(nèi)容的控制。內(nèi)容只應當留下受到幾種RMP系統(tǒng)保護的TVA設(shè)備的域。此外，從一個RMP系統(tǒng)到另一個RMP系統(tǒng)的內(nèi)容的每次傳輸都由RMP系統(tǒng)控制。以這種方式，RMP系統(tǒng)保持對內(nèi)容的控制。
分布式內(nèi)容訪問使用本地網(wǎng)絡(luò)中間件的另一方式是使用在其他設(shè)備上實現(xiàn)的元件來實現(xiàn)內(nèi)容訪問?？梢栽趫D5中看到如何實現(xiàn)這種分布式內(nèi)容訪問的例子。在此例子中，可以區(qū)別以下角色-源，內(nèi)容的源。
-匯點，內(nèi)容的匯點。
-處理，可以出現(xiàn)于流路徑中的一個或多個處理功能。處理功能是其中對內(nèi)容執(zhí)行一些操作的功能。
-應用程序，連接不同HN-MW功能并且啟動內(nèi)容訪問的應用程序。注意，此‘應用程序’實際上是DVB-MHP API(或者任何其他相似的API)的實現(xiàn)方式。
-RMP，控制內(nèi)容的RMP系統(tǒng)。
在分布式內(nèi)容訪問中，這些角色的每一個都可以位于不同的設(shè)備上。
HN-MW和OPIMA隔離間(compartments)存在大量的內(nèi)容格式以及RMP系統(tǒng)。為避免必須建模以及支持每個可能的選項，OPIMA使用隔離間原理。依照OPIMA，隔離間是OPIMA類，其能夠使設(shè)備共享它們RMP接口和/或結(jié)構(gòu)部件中的一些公共元件。例如，可以將DVB認為成隔離間，其也包含由特定RMP系統(tǒng)定義的其他隔離間。隔離間可以是分級的。也就是說，隔離間可以包含子隔離間。
隔離間定義不同的系統(tǒng)元件以及在此隔離間內(nèi)可利用的工具。當RMP系統(tǒng)在隔離間范圍內(nèi)操作時，它知道它期待什么工具以及系統(tǒng)。在隔離間范圍內(nèi)定義的元件的例子是加密算法和規(guī)則過濾器。
在HN-MW范圍內(nèi)，使用隔離間定義IHDN中可用的網(wǎng)絡(luò)功能，該IHDV將使用HN-MW互聯(lián)。在隔離間中定義了這些安全功能，并且可以作為具有HN-MW的獨立功能來實現(xiàn)，或者可以將它們并入另一功能(例如，調(diào)諧器可以支持規(guī)則過濾器、顯示器、解擾器)。使用隔離間安全功能能夠以這樣一種方式定義，所述方式為內(nèi)容只可以在受到幾種RMP系統(tǒng)保護的設(shè)備接口上獲得。
受保護的內(nèi)容和元數(shù)據(jù)為了訪問內(nèi)容，保護內(nèi)容的RMP系統(tǒng)必須是已知的。在傳統(tǒng)的配置過程中，在設(shè)備中內(nèi)容是可用的，所述設(shè)備還支持安全部件。在網(wǎng)絡(luò)中，不再是這種情況。因此，應用程序需要裝置確定使用什么樣的RMP系統(tǒng)來保護內(nèi)容。這是在已經(jīng)存在的像內(nèi)容格式這樣的元數(shù)據(jù)之上需要的輔助信息。
在理想的世界中，往往只在顯示內(nèi)容時，才必須處理所述內(nèi)容。然而有時，RMP系統(tǒng)可能需要一些將要對內(nèi)容執(zhí)行的操作。這種操作的例子有密鑰置換以及重新加密。這些操作取決于對內(nèi)容需要并且應該為應用程序所知的操作。這種場合的例子是當被復制時，與內(nèi)容相關(guān)聯(lián)的規(guī)則可以改變(copy_one_generation-＞copy_no_more)。只有當應用程序知道確定操作需要一些操作時，才可以將這些操作并入流路徑(streaming path)。其他元件應該并入流路徑特殊的規(guī)則過濾器。
因此，應用程序?qū)⒈仨氈缹⒛膫€安全功能并入流路徑。所述應用程序可以根據(jù)元數(shù)據(jù)獲悉這些功能。所述內(nèi)容元數(shù)據(jù)將包含應該包括的操作的每個內(nèi)容訪問類型列表。
需要的安全功能取決于內(nèi)容需要的訪問類型。換言之，它們?nèi)Q于內(nèi)容訪問的目的。在OPIMA內(nèi)，定義了目的集合。根據(jù)網(wǎng)絡(luò)觀點，此集合已經(jīng)被擴展以便適合內(nèi)容訪問的全部集合。
定義了目的的三個主類。在下面的附錄B中給出了目的的全部列表。
-RELEASE(釋放)，此目的類管理從一個RMP系統(tǒng)到另一RMP系統(tǒng)的內(nèi)容傳輸。緊接于所述目的類，另一個RMP系統(tǒng)中的內(nèi)容目的被表示。
-RECEIVE(接收)，此目的類表示從另一RMP系統(tǒng)接收內(nèi)容。
-ACCESS(訪問)，所述目的類處理對一個RMP系統(tǒng)中的內(nèi)容的訪問。緊接于所述目的類，更詳細地表示了該目的。
當將內(nèi)容的權(quán)限從RMP系統(tǒng)傳輸?shù)搅硪籖MP系統(tǒng)時需要釋放內(nèi)容，通常，這需要改變內(nèi)容中的規(guī)則并且還可能重新加密。像內(nèi)容(格式)代碼轉(zhuǎn)換、特技播放的訪問以及圖像改進處理不改變所述內(nèi)容，并且應該允許在RMP系統(tǒng)的范圍內(nèi)。這種功能往往通常是處理功能的一部分。
因此，與RMP系統(tǒng)相關(guān)的元數(shù)據(jù)應該保持以下信息-隔離間定義(參見附錄C)。
-RMP定義(參見附錄C)。
-具有對于每個目的來說需要的安全功能的URN的目的列表。
-可能的一些隔離間專用信息。
為了識別出現(xiàn)于HN-MW內(nèi)的功能中的安全功能，HN-MW中的每個相關(guān)函數(shù)將實現(xiàn)表示這一點的方法。
安全功能和框架就此，可以創(chuàng)建保持所有需要的安全功能的流動圖，因此，可以啟動此特殊的內(nèi)容對話?？梢枣溄右粋€或多個這種對話，以便涉及所有需要訪問該內(nèi)容的元件。
在OPIMA中，這種對話由所謂的ContentId表示，其唯一地識別TVAF中的流之一。在網(wǎng)絡(luò)環(huán)境中，能夠依照使每個ContentId唯一的定義來定義這種ContentId已經(jīng)變得十分重要。這一點通過采用包含以下值的結(jié)構(gòu)替換OPIMA ContentId來執(zhí)行，所述值為-tvafId，TVAF的唯一標識符。
-contentAccessId，在此TVAF范圍內(nèi)識別此對話的唯一標識符。
-streamId，表示所提及的此對話內(nèi)的流的數(shù)目。
在附錄C的C.1.5中，以IDL(ContentSessionId)表示此結(jié)構(gòu)。
tvafId和contentAccessId的組合唯一地標識了此對話。使用此信息，網(wǎng)絡(luò)中的安全功能的TVAF可以用主TVAP注冊以接收與此內(nèi)容訪問相關(guān)的消息。因此，必須創(chuàng)建第一新的對話。附錄A包含定義內(nèi)部方法的例子，所述方法可用于創(chuàng)建對話。
使用tvafId和ContentAccessId，涉及此內(nèi)容訪問的安全功能可以用TVAF注冊它們自己，其中啟動內(nèi)容訪問(主TVAP)。對安全功能的HN-MW API、使用attachToContentAccess方法來執(zhí)行這一點。當調(diào)用此方法時，安全功能的TVAF將用主TVAF注冊它自己。
當注冊時，主TVAF將調(diào)用注冊TVAF，證實注冊并且表明與此內(nèi)容訪問相關(guān)聯(lián)的目的。所述TVAF將在此目的范圍內(nèi)處理這些內(nèi)容訪問的內(nèi)容。
當注冊了所有安全功能時，可以啟動對話。所述對話通過啟動本地網(wǎng)絡(luò)中的流開始，然后表明需要訪問內(nèi)容。因為位于其他設(shè)備的規(guī)則過濾器而不是源設(shè)備需要訪問內(nèi)容，所以應該首先啟動流。這需要待啟動的流。為支持專有的擴展，在任一點，應用程序可以直接與RMP系統(tǒng)進行通信(參見附錄A的A.3和A.4)。
就此，可以啟動對話。所述TVAF將聯(lián)系RMP系統(tǒng)，規(guī)則將被過濾，并且將允許或者拒絕訪問內(nèi)容。
分布式內(nèi)容訪問和RPC在RMP系統(tǒng)中，應該以相同的方式來處理本地及分布式內(nèi)容訪問。為了使用無關(guān)網(wǎng)絡(luò)訪問的OPIMA API，需要一些對RPC處理的方針(guideline)。依照圖6中表明的系統(tǒng)來管理RPC調(diào)用。
以“Call”顯示的所有RMP系統(tǒng)調(diào)用由主OVM路由至利用對話注冊的所有OVM。合并所有調(diào)用的響應，并且在對RMP系統(tǒng)的調(diào)用返回中表明返回值。
可以確定兩個類型(遠程過程)的調(diào)用，其與內(nèi)容訪問以及正在使用工具的調(diào)用相關(guān)。內(nèi)容訪問涉及的調(diào)用使用ContentId來涉及內(nèi)容訪問。正常的情況下，如果可利用的話，則不本地調(diào)用關(guān)于工具的內(nèi)容訪問涉及的調(diào)用，否則就遠程調(diào)用。內(nèi)容訪問涉及的調(diào)用使用以下方針處理1.如果所述調(diào)用是RPC，那么本地處理它并且返回結(jié)果。
2.如果所述調(diào)用是本地的，并且如果此調(diào)用的內(nèi)容訪問是本地的，那么對所有寄存的TVAF(如果此TVAF是流的一部分，那么也可以本地)調(diào)用功能。
3.如果所述調(diào)用是本地的，但是此調(diào)用的內(nèi)容訪問不是本地的，那么調(diào)用保持內(nèi)容訪問的主TVAF。
由于不同的TVAP不是必須知道哪個功能位于什么樣的TVAF，這種解決方案的主從本性簡化了通信。
附錄A應用服務(wù)API在此文獻范圍內(nèi)，所述DAVIC CA API充當應用程序API。為了實現(xiàn)此API，在集合(hosting)此API的設(shè)備內(nèi)部中，必須將一些專用信息傳遞到TVAF。使用不需要被指定的內(nèi)部專有API來執(zhí)行這一點。以下(提供消息的)方法給出了用于啟動、停止和控制內(nèi)容訪問的方法的例子。
attachToContentAccess此方法用管理所示內(nèi)容訪問的TVAF注冊它的TVAF，因此它將接收任何涉及的RPC。當啟動內(nèi)容訪問時，由TVAF表明所有值。
A.1應用服務(wù)A.1.1 createContentRelease以向另一RMP系統(tǒng)釋放內(nèi)容為目的，利用TVAF來創(chuàng)建對話。

A.1.2 createContentAccess以訪問內(nèi)容為目的、依照TVAF創(chuàng)建對話。


A.1.3 creatContentReceive以接收來自于另一RMP系統(tǒng)的內(nèi)容為目的，利用TVAF來創(chuàng)建對話。


A.1.4 startContentSession啟動這一對話

A.1.5 stopContent停止內(nèi)容訪問、釋放或者接收。


A.2應用服務(wù)收聽器A.2.1 startContentSessionResponse此異步響應由TVAP發(fā)送到應用程序，以便通知出現(xiàn)了確定事件；它可以用于同步目的。

A.3應用程序RMP服務(wù)A.3.1 queryRMPSystems此方法允許應用程序向RMP系統(tǒng)發(fā)送消息并且接收應答，所述RMP系統(tǒng)安裝在TVAF處。


A.3.2sendMessageToRMP此方法允許應用程序向RMP系統(tǒng)發(fā)送消息并且接收應答，所述RMP系統(tǒng)安裝在TVAF處。


A.4應用程序RMP服務(wù)收聽器A.4.1 msgFromRMP此異步響應由TVAP發(fā)送到應用程序，以通知出現(xiàn)確定事件；它可以用于同步化目的。

A.4.2 indicateRmpList此異步響應由TVAF發(fā)送到應用程序以便通知可利用的RMP系統(tǒng)的列表。

附錄B目的(PURPOSE)以下目的已經(jīng)定義。


附錄C涉及HN-MW使用的TVAF APIC.1 TVAF網(wǎng)絡(luò)服務(wù)C.1.1 getTVAFId返回此TVAF的TVAF id。

C.1.2 registerWithContentSession注冊具有所示內(nèi)容對話的調(diào)用TVAP


C.1.3 unRegisterWithContentSession不注冊具有所示內(nèi)容對話的調(diào)用TVAF

C.1.4 contentSessionRegistered由主TVAP的注冊確認。表明與此內(nèi)容訪問相關(guān)目的的目的。所述TVAF應該在此目的范圍內(nèi)處理內(nèi)容。


C.1.5 contentSessionStopped指示已經(jīng)停止內(nèi)容對話的其他TVAF。

C.2 IDL先前方法的IDL代碼是//通用結(jié)構(gòu)enum Purpose{RELEASE_RENDER，RELEASE_MOVE，RELEASE_COPY，RECEIVE，ACCESS_STORE，ACCESS_RENDER，ACCESS_EDIT，ACCESS_DELETE，ACCESS_PROCESS，OTHER}；typedef sequence<octet，16>TvafId；struct Content IdTvafId tvafId；long contentSessionId；long streamId}；
//TVAF網(wǎng)絡(luò)涉及的接口interface TvafNetworkServices{long getTvafId(out TvafId tvafId)；long registerWithContentSession(in TvafIdtvafId，in long contentSessionId)；long unRegisterWithContentSession(in TvafIdtvafId，in long contentSessionId)；long contentSessionRegistered(in TvafIdtvafId，in long contentSessionId，Purpose p)；}附錄DTVAF URLS以及URNSD.1統(tǒng)一資源定位器(URL)定義供TVAF之用，給出以下URL定義-RMP系統(tǒng)tvaf//<network_address>/<TVAFid>/ipmp/<rmp_id>
-應用程序tvaf//<network_address>/<TVAFid>/app/<app_id>
-工具tvaf//<network_address>/<TVAFid>/tool/<tool_id>
在這些uRL中，不同的字段具有以下含義tvaf，表明將消息經(jīng)由SAC發(fā)送。
<network_address>，集合TVAF的設(shè)備地址。
<TVAF_id>，TVAF的id。
<RMP_id>，RMP模塊的id。
<app_id>，應用程序的id<tool_id>，工具的id例子tvaf//130.130.120.4/34535/ipmp/1213tvaf//130.130.120.4/34535/app/113tvaf//130.130.120.4/34535/tool/12234D.2統(tǒng)一資源名(URN)定義將TVAF系統(tǒng)URN定義為-隔離間tvaf//<compartment_source>/compartment-安全函數(shù)tvaf//<compartment_source>/compartment/<function>
在這些URN中，不同的字段具有以下含義<compartment_source>，定義的隔離間體的名稱(互聯(lián)網(wǎng)格式)。
<function>，在此隔離間中此特定函數(shù)的名稱。
例子tvaf//org.dvb/mpeg2tvaf//org.dvb/mpeg2/sinktvaf//org.dvb/mpeg2/receivetvaf//org.dvb/mpeg2/sourcetvaf//org.dvb/mpeg2/processor附錄E關(guān)于HN-MW方法的方法E.1 TVAF API按照獨立的方法在HN-MW表示TVAF。對這種函數(shù)以下方法是可利用的。
E.1.1newMessage已經(jīng)接收用于此TVAF的新消息。

E.2安全函數(shù)API在支持安全函數(shù)的HN-MW中，對函數(shù)應該可利用以下方法。
E.2.1 getSecurityFunctions此方法表明安全函數(shù)(附錄D)的URN，所述安全函數(shù)由此HN-MW函數(shù)支持

E.2.2 attachTocontentAccess此方法用管理所示的內(nèi)容訪問的TVAF來注冊其TVAP，以便它將接收任何相關(guān)RPC。當啟動內(nèi)容訪問時，由TVAF表明所有值。

附錄F縮寫下面是用于此文檔的縮寫，以及它們所指的含義。
AES先進的加密標準APDU 應用程序協(xié)議數(shù)據(jù)單元
API應用編程接口CFC基值要求(Call for Contribution)DAVIC 數(shù)字音頻與視覺理事會DVB數(shù)字視頻廣播HAVi 本地音頻視頻互用性HN-MW 本地網(wǎng)絡(luò)中間件ISO標準化國際組織MMI人機接口MPEG 運動圖像專家組OVMOPIMA虛擬機QoS服務(wù)質(zhì)量RMP權(quán)限管理以及保護RPC遠程過程調(diào)用SAC安全驗證通道TLS傳輸層安全協(xié)議TTP信任的第三方TVATV-隨時(TV-Anytime)TVAF TV-隨時框架UPnP 通用的即插即用VPN虛擬專用網(wǎng)絡(luò)應該注意的是，上述實施例是舉例說明，而非限制本發(fā)明，并且在不脫離所附權(quán)利要求的范圍的情況下，本領(lǐng)域技術(shù)人員將能設(shè)計許多可替代的實施例。舉例來說，雖然在上文中使用了OPIMA，但是其他安全框架當然也可以使用。例如，可以依照相同的方式使用MPEG-4 IPMP擴展。
在權(quán)利要求書中，不應該將置于括號內(nèi)的所有參考標記看作是對權(quán)利要求的限制。詞語“包括”不排除存在不同于權(quán)利要求所列的那些元件或者步驟。元件之前的單詞“一”或者“一個”不排除存在多個這種元素。本發(fā)明可以通過包括多個不同元件的硬件、并且通過適當?shù)鼐幊逃嬎銠C來實現(xiàn)。
在列舉了多個裝置的設(shè)備權(quán)利要求中，部分這些裝置可以由完全一樣的硬件項來實現(xiàn)。在互相不同的從屬權(quán)利要求中記載的確定測量值僅僅是這樣一個事實，其不表示這些測量值的組合無法用于優(yōu)點。
權(quán)利要求
1.一種條件訪問系統(tǒng)，包括多個在網(wǎng)絡(luò)中互聯(lián)的設(shè)備，所述設(shè)備被分組成第一組以及第二組，第一組的設(shè)備依照第一安全框架操作，而第二組的設(shè)備依照第二安全框架操作，每個設(shè)備使用特定的中間件層操作，所述中間件層被設(shè)置為驗證另一個設(shè)備的另一個中間件層，所述中間件層由所述設(shè)備操作所依照的安全框架來驗證。
2.如權(quán)利要求1所述的系統(tǒng)，其中第一組的設(shè)備通過對第二組的設(shè)備的中間件層進行遠程過程調(diào)用(RPC)可以執(zhí)行第二安全框架的功能。
3.如權(quán)利要求2所述的系統(tǒng)，其中將RPC經(jīng)由安全驗證通道(SAC)傳送到第二組的設(shè)備中。
4.如權(quán)利要求1所述的系統(tǒng)，其中所述設(shè)備被允許依照目的的特定類來訪問內(nèi)容，定義了此類的集合，每個類包括多個條件訪問操作或者目的。
5.如權(quán)利要求4所述的系統(tǒng)，其中來自于所述集合的第一類包括操作RENDER、MOVE以及COPY。
6.如權(quán)利要求5所述的系統(tǒng)，其中來自于所述集合的第二類包括操作STORE、RENDER、EDIT、DELETE以及PROCESS。
7.如權(quán)利要求6所述的系統(tǒng)，其中獨立于任何對與所述內(nèi)容相關(guān)聯(lián)權(quán)限的限制來授權(quán)PROCESS操作。
8.一種允許設(shè)備有條件地訪問一條內(nèi)容的方法，其中所述設(shè)備被允許依照目的的特定類來訪問內(nèi)容，定義了此類的集合，每個類包括多個條件訪問操作或者目的。
9.如權(quán)利要求8所述的方法，其中來自于所述集合的第一類包括操作STORE、RENDER、EDIT、DELETE以及PROCESS。
10.如權(quán)利要求9所述的方法，其中獨立于任何對與所述內(nèi)容相關(guān)聯(lián)權(quán)限的限制來授權(quán)PROCESS操作。
全文摘要
一種條件訪問系統(tǒng)，包括多個在網(wǎng)絡(luò)中互聯(lián)的設(shè)備，所述設(shè)備被分組成第一組以及第二組，第一組的所述設(shè)備依照第一安全框架操作，而第二組的設(shè)備依照第二安全框架操作，每個設(shè)備使用特定的中間件層操作，所述中間件層被設(shè)置為驗證另一個設(shè)備的另一個中間件層，所述中間件層由所述設(shè)備操作所依照的安全框架來驗證。
文檔編號G06F21/10GK1596531SQ02823524
公開日2005年3月16日 申請日期2002年11月14日 優(yōu)先權(quán)日2001年11月27日
發(fā)明者S·A·F·A·范登休維, P·J·勒努瓦, F·L·A·J·坎佩曼 申請人:皇家飛利浦電子股份有限公司