專利名稱：按照數(shù)據(jù)權限管理(drm)系統(tǒng)在一個定義域諸如—組織內(nèi)發(fā)行數(shù)字內(nèi)容的制作方法
技術領域：
本發(fā)明涉及數(shù)據(jù)權限管理(DRM)系統(tǒng)。更具體地說，本發(fā)明涉及使用DRM系統(tǒng)在諸如組織、辦公室、公司等等定義域內(nèi)發(fā)行數(shù)字內(nèi)容，因此在這個域內(nèi)可按照相應的使用或許可條款約束內(nèi)容的再現(xiàn)和使用。
背景技術：
在數(shù)字內(nèi)容諸如數(shù)字音頻、數(shù)字視頻、數(shù)字文本、數(shù)字數(shù)據(jù)、數(shù)字多媒體等方面，在其中這樣的數(shù)字內(nèi)容要被分發(fā)至一或多個用戶，數(shù)據(jù)權限管理和實施是非常需要的。數(shù)字內(nèi)容可能是靜態(tài)的，諸如文本文檔，或者它可能是被流化的，諸如流化的實況轉(zhuǎn)播事件的音頻/視頻。典型的分發(fā)模式包括有形的設備諸如磁(軟)盤、磁帶、光(激光)盤(CD)等，和無形的媒體諸如電子公告板、電子網(wǎng)絡、因特網(wǎng)等。在由用戶接收時，這樣的用戶在適當?shù)脑佻F(xiàn)設備諸如個人計算機等等上的媒體播放器再現(xiàn)或‘播放’數(shù)字內(nèi)容。
在一個情景中，內(nèi)容所有者或權限所有者諸如作者、發(fā)行人、廣播員等，想要將這樣的數(shù)字內(nèi)容分發(fā)給許多用戶或接受者的每一個以交換許可費或一些其它的費用。那么，在這樣的情景中，內(nèi)容可能是歌曲、歌曲集、電影等，而分發(fā)的目的是產(chǎn)生許可費。如果讓這樣的內(nèi)容所有者選擇，很可能想要對用戶能夠?qū)@樣被分發(fā)的數(shù)字內(nèi)容能做什么進行限制。例如，內(nèi)容所有者意欲限制用戶復制和重新分發(fā)這樣的內(nèi)容至第二個用戶，至少是在這樣的第二個用戶向拒絕內(nèi)容所有者許可費時。
另外，內(nèi)容所有者可能想要為用戶提供以不同許可費購買不同類型的用戶許可的靈活性，而同時使用戶遵守實際購買的無論什么類型的許可的條款。例如，內(nèi)容所有者可能想要允許被分發(fā)的數(shù)字內(nèi)容只被播放有限的次數(shù)，只被播放某個總的時間，只在某種類型的機器上播放，只在某種類型的媒體播放器上播放，只由某種類型的用戶播放。
在另一個情景中，諸如在一組織內(nèi)的職工或組織的成員想要將這樣的數(shù)字內(nèi)容分發(fā)給組織內(nèi)的其它職工或成員或者分發(fā)給組織外的其它個人，但內(nèi)容開發(fā)者，往往欲阻止其它人再現(xiàn)這個內(nèi)容。這里，內(nèi)容的分發(fā)與以機密的或限制的方式共享基于組織的內(nèi)容非常相似，而與以交換許可費或一些其它報酬的無限的(broad-based)分發(fā)相反。
在這樣的情景中，內(nèi)容可能是文檔報告、電子表格、數(shù)據(jù)庫、電子郵件等等，諸如在辦公室環(huán)境內(nèi)可被交流的，以及內(nèi)容開發(fā)者可能想要確保內(nèi)容保持在組織或辦公室環(huán)境內(nèi)并且不被未經(jīng)授權的個人諸如例如競爭者或?qū)κ衷佻F(xiàn)。再一次，這樣內(nèi)容開發(fā)者想要對接受者能夠?qū)@樣被分發(fā)的數(shù)字內(nèi)容所做的事進行限制。例如，內(nèi)容所有者意欲限制用戶，復制和重新分發(fā)這樣的內(nèi)容至第二個用戶，至少是在被允許再現(xiàn)內(nèi)容的個人范圍之外暴露內(nèi)容時。
此外，內(nèi)容開發(fā)者可能想要為各種接受者提供不同級別的再現(xiàn)權限。例如，內(nèi)容開發(fā)者可能想要允許受保護的數(shù)字內(nèi)容相對于一類個人可被觀看而不可被打印，并且相對于另一類個人可被觀看且可被打印。
不過，在任一情景中，在分發(fā)已經(jīng)發(fā)生后，這樣的內(nèi)容所有者/開發(fā)者即使對數(shù)字內(nèi)容有控制也只具有很少的控制。實際上任何個人計算機包括制作這樣的數(shù)字內(nèi)容的準確的數(shù)字拷貝所需的軟件和硬件，和將這樣準確的數(shù)字拷貝下載至可寫的磁或光盤所需的軟件和硬件，以及通過網(wǎng)絡諸如因特網(wǎng)將這樣準確的數(shù)字拷貝送到任何目的地所需的軟件和硬件，所以這特別成問題。
當然，作為分發(fā)內(nèi)容的交易的一部分，內(nèi)容所有者/開發(fā)者可能要求數(shù)字內(nèi)容的用戶/接受者承諾不以討厭的方式重新分發(fā)這樣的數(shù)字內(nèi)容。然而，這樣的承諾很容易作出也很容易打破。內(nèi)容所有者/開發(fā)者可能試圖通過幾種已知的通常包括加密和解密的安全設備阻止這樣的重新分發(fā)。但是，要阻止適當?shù)乇淮_定的用戶不解密被加密的數(shù)字內(nèi)容，以非加密的形式保存這樣的數(shù)字內(nèi)容，然后重新分發(fā)同一數(shù)字內(nèi)容，其存在的可能性非常小。
于是，存在一種需求，用于提供數(shù)據(jù)權限管理(DRM)和實施結構和方法，允許受控制地再現(xiàn)或播放任意形式的數(shù)字內(nèi)容，在其中該控制是靈活的且可由這樣的數(shù)字內(nèi)容的內(nèi)容所有者/開發(fā)者定義的。更明確地說，存在對這樣一種結構的需求，該結構允許和促進這樣的受控制的再現(xiàn)，特別是在辦公室或組織環(huán)境等等中，在其中文檔要在規(guī)定的一組個人或一類個人中共享。
概述至少部分地由本發(fā)明滿足上述需求，在本發(fā)明中，許可證頒發(fā)者向請求者發(fā)布允許請求者再現(xiàn)相應的數(shù)字內(nèi)容的數(shù)字許可證。在本發(fā)明中，許可證頒發(fā)者可以使用一個包括請求者的列表的目錄，在其中這個列表包括請求者的標識符和請求者是其成員的每個組的標識符。
許可證頒發(fā)者從請求者接收一個請求，在其中該請求包括一標識請求者的標識符以及與內(nèi)容關聯(lián)的權限數(shù)據(jù)，且在其中權限數(shù)據(jù)列出至少一標識符和與其關聯(lián)的權限。許可證頒發(fā)者之后在目錄中找到請求者的標識符，以及由在目錄中被找到的請求者標識符，在目錄中找到請求者是其成員的每個組的標識符。將每個被找到的請求者標識符和每個被找到的組標識符，與在權限數(shù)據(jù)中列出的每個標識符比較，以找到一個匹配，以及向請求者發(fā)布帶有與匹配的標識符關聯(lián)的權限的許可證。


結合附圖閱讀時將更好地理解前面的概述，以及后面本發(fā)明實施例的詳細說明。為了例示本發(fā)明，在附圖中所示的實施例目前是較佳的。不過，如應該理解的，本發(fā)明不受限于所示的精確安排和工具。在附圖中圖1是一表示典型的非限制的計算環(huán)境的方框圖，在該環(huán)境中可實現(xiàn)本發(fā)明；圖2是一表示具有各種計算設備的典型網(wǎng)絡環(huán)境的方框圖，在該環(huán)境中可實現(xiàn)本發(fā)明；圖3是按照本發(fā)明的系統(tǒng)和方法的一個實施例的功能方框圖，用于發(fā)行數(shù)字內(nèi)容；圖4是按照本發(fā)明的方法的一個實施例的流程圖，用于發(fā)行權限管理的數(shù)字內(nèi)容；圖4A是一方框圖，示出如由圖4的方法產(chǎn)生的簽署的權限標簽的結構；圖5是按照本發(fā)明的系統(tǒng)和方法的一個實施例的方框圖，用于許可權限管理的數(shù)字內(nèi)容；圖6A和6B是按照本發(fā)明的方法的一個實施例的流程圖，用于許可權限管理的數(shù)字內(nèi)容；圖7是一流程圖，示出按照本發(fā)明的一個實施例在重新發(fā)行一權限標簽時所執(zhí)行的關鍵步驟；圖8是一方框圖，示出按照本發(fā)明的一個實施例的一證書，它由一DRM服務器發(fā)布，以允許用戶執(zhí)行離線發(fā)行；圖9是一方框圖，示出按照本發(fā)明的一個實施例的一權限模板，指定要被結合到一權限標簽中的信息；圖10是一流程圖，示出按照本發(fā)明的一個實施例，在創(chuàng)建圖9的權限模板和基于權限模板創(chuàng)建圖4A的簽署的權限標簽的時候所執(zhí)行的關鍵步驟；圖11是一方框圖，示出基于信任的系統(tǒng)的實例的實施結構；圖12是一方框圖，示出按照本發(fā)明的一個實施例的處理對一許可證的請求的許可證頒發(fā)者；圖13是一流程圖，示出由圖12的許可證頒發(fā)者在發(fā)布許可證時所執(zhí)行的與一目錄有關的步驟；以及圖14是一流程圖，示出由圖12的許可證頒發(fā)者在將政策插入一要被發(fā)行的許可證中時所執(zhí)行的步驟。
詳細說明圖1和下面的討論旨在提供一合適的計算環(huán)境的簡要概括的說明，在該環(huán)境中可實現(xiàn)本發(fā)明。不過，應該理解，手持的、便攜的和其它所有種類的計算設備被預期結合于本發(fā)明使用。盡管下面描述是通用計算機，但是這只是一個實例，并且本發(fā)明只要求具有網(wǎng)絡服務器互操作性和交互性的瘦客戶機。因而，可在一網(wǎng)絡化主機化服務的環(huán)境中實現(xiàn)本發(fā)明，在該環(huán)境中，包含非常少或最小程度的客戶機資源，例如，一個在其中客戶機設備只用作為對于萬維網(wǎng)的瀏覽器或接口的網(wǎng)絡化環(huán)境。
盡管不要求，但可通過由開發(fā)者使用的應用編程接口(API)實現(xiàn)本發(fā)明，和/或?qū)⒈景l(fā)明包括在網(wǎng)絡瀏覽軟件內(nèi)，將在計算機可執(zhí)行指令諸如程序模塊的一般背景中描述網(wǎng)絡瀏覽軟件，由一或多個計算機諸如客戶工作站、服務器或其它設備執(zhí)行。通常，程序模塊包括執(zhí)行特定任務或?qū)崿F(xiàn)特定的抽象數(shù)據(jù)類型的例程、程序、對象、組件、數(shù)據(jù)結構等等。一般地，可將程序模塊的功能按要求結合或分發(fā)到各種實施例中。而且，本領域熟練技術人員將意識到，可用其它計算機系統(tǒng)配置實施本發(fā)明。其它可能適合于本發(fā)明使用的知名的計算系統(tǒng)、環(huán)境和/或配置包括，但不限于，個人計算機(PC)、自動出納機(automatedteller machine)、服務器計算機、手持或膝上型設備、多處理器系統(tǒng)、基于微處理器的系統(tǒng)、可編程消費電子產(chǎn)品、網(wǎng)絡PC、小型機、大型機等等。還可在分布式計算環(huán)境中實施本發(fā)明，在該環(huán)境中，由通過通信網(wǎng)絡或其它數(shù)據(jù)傳輸媒體連接的遠程處理設備執(zhí)行任務。在一分布式環(huán)境中，可將程序模塊放在包括存儲器設備的本地或遠程計算機存儲媒體兩者之中。
圖1這樣示出一合適的計算系統(tǒng)環(huán)境100的實例，在該環(huán)境中可實現(xiàn)本發(fā)明，盡管如上面清楚地說明的，計算系統(tǒng)環(huán)境100只是合適的計算系統(tǒng)環(huán)境的一個實例，而非意指關于本發(fā)明的使用或功能的范圍的任何限制。也不應該將計算環(huán)境100解釋為具有與在典型操作環(huán)境100中所示的組件的任何一個或組合有關的任何依賴性或要求。
參考圖1，用于實現(xiàn)本發(fā)明的典型系統(tǒng)包括一以計算機110形式的通用計算設備。計算機110的組件可包括，但不限于，處理單元120，系統(tǒng)存儲器130，和將各種系統(tǒng)組件包括系統(tǒng)存儲器在內(nèi)連接至處理單元120的系統(tǒng)總線121。系統(tǒng)總線121可以是幾種類型總線結構的任何一種，包括使用各種總線結構的存儲器總線或存儲控制器，外部設備總線，和局部總線。作為實例，但不限制，這樣結構包括工業(yè)標準結構(ISA)總線、微通道結構(MCA)總線、增強ISA(EISA)總線、視頻電子標準協(xié)會(VESA)局部總線、以及周邊元件互連(PCI)總線(也被稱為夾層(Messanine)總線)。
計算機110一般包括多種多樣的計算機可讀媒體。計算機可讀媒體可以是能夠由計算機110存取的任何可用媒體，并包括易失的或非易失的媒體，可移動的和不可移動的媒體。作為例子，不是限制，計算機可讀媒體可包括計算機存儲媒體和通信媒體。計算機存儲媒體包括易失的和非易失的、可移動的和不可移動的媒體兩者，它們是以任何用于存儲信息諸如計算機可讀指令、數(shù)據(jù)結構、程序模塊或其它數(shù)據(jù)的方法和技術實現(xiàn)的。計算機存儲媒體的實例包括，但不限于，RAM(隨機存取存儲器)、ROM(只讀存儲器)、EEPROM(電可擦除可編程只讀存儲器)、閃存或其它存儲技術、CD-ROM(光盤)、數(shù)字通用盤(DVD)或其它光盤存儲器、磁盒、磁帶、磁盤存儲器或其它磁存儲設備，或者可能被用于存儲想要的信息和能由計算機110存取的任何其它媒體。通信媒體一般包括計算機可讀指令、數(shù)據(jù)結構、程序模塊或其它數(shù)據(jù)，它們在調(diào)制的數(shù)據(jù)信號諸如載波或其它傳輸機制中，還包括任何信息傳送媒體。術語“調(diào)制的數(shù)據(jù)信號”指具有以將信息編碼在信號中的方式設置或改變的一或多個特征的信號。作為實例，但不是限制，通信媒體包括有線的媒體，諸如有線的網(wǎng)絡或直接線連接，以及無線的媒體，諸如耦合器、RF(射頻)和其它無線媒體。任何上述各項的組合應該也包括在計算機可讀媒體的范圍之內(nèi)。
系統(tǒng)存儲器130包括以易失的和/或非易失的存儲器形式的計算機存儲媒體，諸如只讀存儲器(ROM)131和隨機存取存儲器(RAM)132?；据斎?輸出系統(tǒng)133(BIOS)，包含幫助計算機110內(nèi)部件之間傳送信息的基本例程，諸如在起動期間，它一般被存儲在ROM131中。RAM132一般包含由處理單元120可直接存取和/或目前操作的數(shù)據(jù)和/或程序模塊。作為例子，不是限制，圖1示出操作系統(tǒng)134、應用程序135、其它程序模塊136和程序數(shù)據(jù)137。
計算機110還可包括其它可移動的/不可移動的、易失的/非易失計算機存儲媒體。只是作為例子，圖1示出讀寫不可移動的、非易失的磁媒體的硬盤驅(qū)動器141，讀寫可移動的、非易失的磁盤152的磁盤驅(qū)動器151，和讀寫可移動的、非易失的光盤156諸如CD ROM或其它光媒體的光盤驅(qū)動器155。能用于典型操作環(huán)境的其它可移動的/不可移動的、易失的/非易失的計算機存儲媒體包括，但不限于，磁帶盒、閃存卡、數(shù)字通用盤、數(shù)字視頻帶、固態(tài)ROM(solidstate ROM)等等。硬盤驅(qū)動器141一般通過一不可移動的存儲器接口諸如接口140連接至系統(tǒng)總線121，以及磁盤驅(qū)動器151和光盤驅(qū)動器155一般由可移動的存儲器接口諸如接口150連接至系統(tǒng)總線121。
上面所述和在圖1中所示的驅(qū)動器及其關聯(lián)的計算機存儲媒體，為計算機110提供計算機可讀指令、數(shù)據(jù)結構、程序模塊和其它數(shù)據(jù)的存儲。在圖1中，例如，硬盤驅(qū)動器141被示為存儲操作系統(tǒng)144、應用程序145、其它程序模塊146和程序數(shù)據(jù)147。注意這些組件可以與操作系統(tǒng)134、應用程序135、其它程序模塊136和程序數(shù)據(jù)137或者相同，或者不同。操作系統(tǒng)144、應用程序145、其它應用模塊146和程序數(shù)據(jù)147在這里給出不同的編號，以說明在最低程度上它們是不同的拷貝。用戶可通過輸入設備，諸如鍵盤162和普通被稱為鼠標的定點設備161、軌跡球或觸摸墊，將命令和信息輸入到計算機110中。其它輸入設備(未示出)可包括話筒、游戲桿、游戲墊、衛(wèi)星天線等等。這些和其它輸入設備常常通過連接到系統(tǒng)總線的用戶輸入接口160連接至處理單元120，但是也可以通過其它接口和總線結構連接，諸如并行端口、游戲端口或通用串行總線(USB)。
顯示器191或其它類型的顯示設備也通過一個接口諸如視頻接口190連接至系統(tǒng)總線121。圖形接口182，諸如北橋(Northbridge)，也可連接至系統(tǒng)總線121。北橋是一芯片組，與CPU或主機處理單元120通信，并承擔加速圖形接口(AGP)的通信職責。一或多個圖形處理單元(GPU)184可與圖形接口182通信。在這點上，GPU184一般包括芯片內(nèi)的的存儲器，諸如寄存存儲，且GPU184與視頻存儲器186通信。不過，GPU184只是協(xié)處理器的一個實例，且因而多種多樣的協(xié)處理器可包括在計算機110之內(nèi)。顯示器191或其它類型的顯示設備也通過一個接口諸如視頻接口190連接至系統(tǒng)總線121。除顯示器之外，計算機還可包括其它外部輸出設備諸如揚聲器197和打印機196，它們可通過輸出外部接口195連接。
計算機110可在一個使用邏輯連接至一或多個計算機諸如遠程計算機180的網(wǎng)絡化環(huán)境中運行。遠程計算機180可以是個人計算機、服務器、路由器、網(wǎng)絡PC、對等設備或其它普通網(wǎng)絡節(jié)點，并且一般包括上面相對于計算機110所述的組件的許多或全部，盡管在圖1中只示出存儲器設備181。圖1中所示的邏輯連接包括局域網(wǎng)(LAN)171和廣域網(wǎng)(WAN)173，還可包括其它網(wǎng)絡。這樣的網(wǎng)絡環(huán)境在辦公室、企業(yè)級計算機網(wǎng)絡、企業(yè)內(nèi)部互聯(lián)網(wǎng)和因特網(wǎng)中是普通的。
當在LAN網(wǎng)絡環(huán)境中使用時，計算機110通過網(wǎng)絡接口或適配器170連接至LAN171。當在WAN網(wǎng)絡環(huán)境中使用時，計算機110一般包括調(diào)制解調(diào)器172或用于建立在WAN173諸如因特網(wǎng)上的通信的其它工具。調(diào)制解調(diào)器172，可以是內(nèi)置的或外置的，可通過用戶輸入接口160或其它適當?shù)臋C制連接至系統(tǒng)總線121。在網(wǎng)絡化環(huán)境中，相對于計算機110所述的程序模塊，或其一部分，可存儲在遠程存儲器設備中。作為例子，不是限制，圖1示出遠程應用程序185為駐留在存儲設備181上。將意識到所示的網(wǎng)絡連接是典型的，并且可使用用于在計算機之間建立通信鏈路的其它方法。
本領域的一個普通熟練技術人員能意識到，計算機100或其它客戶機設備能作為計算機網(wǎng)絡配置的一部分。在這點上，本發(fā)明適合于任何具有出現(xiàn)在任意數(shù)量存儲單元或卷上的任意數(shù)量應用程序和過程的計算機系統(tǒng)。本發(fā)明可應用于帶有配置在一網(wǎng)絡環(huán)境中的、具有遠程或地存儲的服務器計算機和客戶計算機的環(huán)境。本發(fā)明也可應用于具有編程語言功能、解釋和執(zhí)行能力的獨立的計算設備。
分布式計算促進通過計算設備和系統(tǒng)之間的直接交流共享計算機資源和服務。這些資源和服務包括信息交換、高速緩沖和用于文件的磁盤存儲。分布式計算利用網(wǎng)絡連接，允許客戶機平衡其集體的能力以有利于整個企業(yè)。在這點上，多種多樣的設備可具有應用程序、對象和資源，它們可交互以包含用于可信的圖形流水線(trusted graphics pipeline)的本發(fā)明的認證技術。
圖2提供一典型的網(wǎng)絡化或分布式計算環(huán)境的示意圖。這個分布式計算環(huán)境包括計算對象10a、10b等，以及計算對象或設備110a、110b、110c等。這些對象可包括程序、方法、數(shù)據(jù)存儲、可編程邏輯等。這些對象可包括同一或不同設備諸如PDA、電視、MP3播放器、電視、個人計算機等的部分。每個對象經(jīng)由通信網(wǎng)絡14能與另一個對象通信。這個網(wǎng)絡可自包含其它計算對象和計算設備，它們?yōu)閳D2的系統(tǒng)提供服務。按照本發(fā)明的一個方面，每個對象10或110可包含一個可請求用于可信的圖形流水線的本發(fā)明的認證技術的應用程序。
還能意識到，一個對象諸如110c可以另一個計算設備10或110為主機。這樣，盡管所示的物理環(huán)境可將連接的設備示為計算機，這樣的例示只是示范性，且可以可替換地包括各種數(shù)字設備諸如PDA，電視，MP3播放器等，軟件對象如接口，COM對象等來圖示或描述這個物理環(huán)境。
存在各種各樣支持分布式計算環(huán)境的系統(tǒng)、組件和網(wǎng)絡配置。例如，計算系統(tǒng)可通過有線的或無線的系統(tǒng)、通過本地網(wǎng)絡或廣泛分布的網(wǎng)絡連接在一起。目前，許多網(wǎng)絡被連接到因特網(wǎng)，它提供廣泛的分布式計算基礎設施和包含許多不同的網(wǎng)絡。
在家庭網(wǎng)絡環(huán)境中，存在至少四個全異的網(wǎng)絡傳輸媒體，它們每個可支持一唯一的協(xié)議，諸如電源線、數(shù)據(jù)(無線的或有線的兩者)、語音(例如電話)和娛樂媒體(entertainment media)。大多數(shù)家庭控制設備諸如電燈開關和器具可使用電源線用于連接。數(shù)據(jù)服務可作為寬帶(例如或者DSL或者線纜調(diào)制解調(diào)器)進入家庭，且在家庭中使用或者無線的(例如家用射頻(HomeRF)8021.b)或者有線的(例如家用PNA(Home PNA)、5類線(Cat 5)甚至電源線)連接，數(shù)據(jù)服務是可訪問的。語音業(yè)務可作為或者有線的(例如3類線(Cat 3))或者無線的(例如蜂窩電話)進入家庭，且可在家庭內(nèi)使用3類配線分布語音業(yè)務。娛樂媒體可或者通過衛(wèi)星或線纜進入家庭，且一般在家庭中使用同軸電纜分布娛樂媒體。IEEE1394和DVI也可作為用于媒體設備群的數(shù)字互連出現(xiàn)。所有這些網(wǎng)絡環(huán)境和可作為協(xié)議標準出現(xiàn)的其它環(huán)境，可互聯(lián)以構成一內(nèi)部互聯(lián)網(wǎng)，它可經(jīng)由因特網(wǎng)連接到外部世界。簡而言之，多種多樣全異的源存在，用于存儲和傳輸數(shù)據(jù)，并且因此，在前進中，計算設備將要求在數(shù)據(jù)處理流水的所有部分保護內(nèi)容的方法。
‘因特網(wǎng)(Internet)’一般指利用TCP/IP協(xié)議組的網(wǎng)絡和網(wǎng)關的集合，在計算機網(wǎng)絡領域中是眾所周知的。TCP/IP是“Transport ControlProtocol/Interface Program(傳輸控制協(xié)議/接口程序)”的首字母縮寫。因特網(wǎng)可被描述為在地理上分布式的由執(zhí)行允許用戶通過網(wǎng)絡交互和共享信息的網(wǎng)絡協(xié)議的計算機互連的遠程計算機網(wǎng)絡的系統(tǒng)。因為這樣廣泛的信息共享，遠程網(wǎng)絡諸如因特網(wǎng)因而已經(jīng)很一般地卷入到開放系統(tǒng)中，對于這個系統(tǒng)開發(fā)者能在基本上沒有限制的情況下，設計用于執(zhí)行特殊的操作或服務的軟件應用程序。
這樣，網(wǎng)絡基礎設施啟用網(wǎng)絡布局的主機諸如客戶機/服務器、對等網(wǎng)絡或混合結構。“客戶機(client)”是一類或組的成員，使用與其無關的另一類或組的服務。這樣，在計算中，客戶是一過程，也就是說，約略地為一組指令或任務，它們請求由另一個程序提供的服務?？蛻暨^程在不必“了解”有關其它程序或服務本身的任何運行細節(jié)的情況下，使用所請求的服務。在客戶機/服務器結構中，特別是一個網(wǎng)絡化的系統(tǒng)，客戶通常是訪問由另一個計算機例如服務器提供的共享網(wǎng)絡資源的計算機。在圖2的實例中，計算機110a、110b等可被認為是客戶機，而計算機10a、10b等可被認為是服務器，其中服務器10a、10b等維護在然后被復制到客戶計算機110a、110b等中的數(shù)據(jù)。
服務器一般是可通過遠程網(wǎng)絡諸如因特網(wǎng)訪問的遠程計算機?？蛻魴C過程可在第一計算機系統(tǒng)中激活，而服務器過程可在第二計算機系統(tǒng)中激活，通過通信媒體彼此通信，因而提供分布式功能且允許多個客戶機利用服務器的信息收集能力。
客戶機和服務器使用由協(xié)議層提供的功能彼此通信。例如，超文本傳輸協(xié)議(HTTP)是一個和萬維網(wǎng)(WWW)一起使用的普通協(xié)議。一般地，計算機網(wǎng)絡地址諸如通用資源定位符(Universal Resource Locator)(URL)或互聯(lián)網(wǎng)協(xié)議(IP)地址，被用于互相識別服務器或客戶計算機。網(wǎng)絡地址可被稱為通用資源定位符地址。例如，可通過通信媒體提供通信。更具體地說，客戶機和服務器可通過TCP/IP連接互相耦合用于高性能通信。
這樣，圖2示出一典型的網(wǎng)絡化的或分布式的環(huán)境，帶有通過網(wǎng)絡/總線與客戶計算機通信的服務器，在其中可使用本發(fā)明。更詳細地說，按照本發(fā)明，許多服務器10a、10b等可通過通信網(wǎng)絡/總線14互相連接，網(wǎng)絡/總線14可以是LAN、WAN、內(nèi)部互聯(lián)網(wǎng)、因特網(wǎng)等，帶有許多客戶機或遠程計算設備110a、110b、110c、110d、110e等，諸如便攜式計算機、手持計算機、瘦客戶機、網(wǎng)絡化的器具或其它設備，諸如VCR(錄像機)、TV(電視機)、微波爐、電燈、取暖器等等。因而這是預期的，即本發(fā)明可應用任何計算設備，想要結合這些設備處理、存儲或再現(xiàn)來自一受托源(trusted source)的安全內(nèi)容。
在通信網(wǎng)絡/總線14為因特網(wǎng)的網(wǎng)絡環(huán)境中，例如，服務器10可以是網(wǎng)絡服務器，客戶機110a、110b、110c、110d、110e等通過許多已知的協(xié)議諸如HTTP與其通信。服務器10也可用作為客戶機110，可作為是分布式計算環(huán)境的特性。通信可以是有線的或無線的，只要適當?？蛻魴C設備110可通過或可不通過通信網(wǎng)絡/總線14通信，且可具有與其關聯(lián)的獨立的通信。例如，在TV或VCR的情況下，可存在或可不存在網(wǎng)絡化的方面以控制它們。每個客戶計算機110和服務器計算機10可配備各種應用程序模塊或?qū)ο?35，并連接或訪問各種類型的存儲部件或?qū)ο?，通過它們可存儲文件或可將文件的部分下載或移動到它們中。這樣，本發(fā)明能夠被用在具有能夠用計算機網(wǎng)絡/總線14訪問和交互的客戶計算機110a、110b等，以及可與客戶計算機110a、110b等和其它設備111及數(shù)據(jù)庫20交互服務器計算機10a、10b等。
數(shù)據(jù)權限管理(DRM)概述如已知的，且現(xiàn)在參考圖11，在數(shù)字內(nèi)容12方面，諸如數(shù)字音頻、數(shù)字視頻、數(shù)字文本、數(shù)字數(shù)據(jù)、數(shù)字多媒體等，在這樣的數(shù)字內(nèi)容要被分發(fā)至用戶時，數(shù)據(jù)權限管理(DRM)和實施是可取的。在由用戶接收時，這樣的用戶在合適的再現(xiàn)設備諸如在個人計算機14上的媒體播放器等等的幫助下再現(xiàn)或‘播放’數(shù)字內(nèi)容。
一般地，分發(fā)這樣的數(shù)字內(nèi)容12的內(nèi)容所有者或開發(fā)者(在下文中‘所有者’)想要對用戶能用這樣被分發(fā)的數(shù)字內(nèi)容12所做的進行限制。例如，內(nèi)容所有者可能想要限制用戶將這樣的內(nèi)容12拷貝和重新分發(fā)至第二個用戶，或者可能想要允許被分發(fā)的數(shù)字內(nèi)容12只被播放有限的次數(shù)、只播放某個總的時間、只在某種類型的機器上播放、只在某種類型的媒體播放器上播放、只由某種類型的用戶播放等等。
不過，在分發(fā)已經(jīng)發(fā)生后，這樣的內(nèi)容所有者即使對數(shù)字內(nèi)容12有控制，也只有非常少的控制。DRM系統(tǒng)10則允許任意形式的數(shù)字內(nèi)容12的受控制的再現(xiàn)或播放，在其中這樣的控制是靈活的且可由該數(shù)字內(nèi)容的內(nèi)容所有者定義。一般地，內(nèi)容12以包13的形式經(jīng)由任何合適的分發(fā)通道被分發(fā)到用戶。如分發(fā)的數(shù)字內(nèi)容包13可包括用對稱加密/解密密鑰(KD)(即(KD(內(nèi)容))加密的數(shù)字內(nèi)容12，以及標識內(nèi)容的其它信息，如何獲得用于這樣的內(nèi)容的許可證等等。
基于信任的DRM系統(tǒng)10允許數(shù)字內(nèi)容12的所有者指定許可規(guī)則，在這樣的數(shù)字內(nèi)容12被允許在用戶的計算設備14上再現(xiàn)之前必須滿足這些許可規(guī)則。這樣的許可規(guī)則可包括前述時間要求，以及可被包含在數(shù)字許可證或者使用文檔(在下文中‘許可證’)16內(nèi)，用戶/用戶的計算設備14(在下文中，這樣的術語是可互換的，除了在環(huán)境要求另外的情況下)必須從內(nèi)容所有者或其代理人獲得許可證。這樣的許可證16還包括解密密鑰(KD)用于解密數(shù)字內(nèi)容，它可能是按照可由用戶的計算設備解密的密鑰加密的。
一件數(shù)字內(nèi)容12的內(nèi)容所有者必須信任用戶的計算設備14將遵守由這樣的內(nèi)容所有者在許可證16中所指定的規(guī)則和要求，即數(shù)字內(nèi)容12將不會被再現(xiàn)，除非在滿足許可證16內(nèi)的規(guī)則和要求。然后最好，為用戶的計算設備14提供可信的組件(trusted component)和機制18，它將不再現(xiàn)數(shù)字內(nèi)容12，除了按照包含在與數(shù)字內(nèi)容12關聯(lián)的且由用戶獲得的許可證16中的許可規(guī)則之外。
可信的組件18一般具有一許可證鑒別器(1icense evaluator)20，它確定許可證16是否是有效的，檢查在這樣的有效許可證16中的許可規(guī)則和要求，并基于所檢查的許可規(guī)則和要求，確定請求的用戶是否具有其中以尋找的方式再現(xiàn)所請求的數(shù)字內(nèi)容12的權限。應該理解，許可證鑒別器20在DRM系統(tǒng)10中是可信的，以按照在許可證16中的規(guī)則和要求完成數(shù)字內(nèi)容12的所有者的愿望，且用戶應該不能夠容易地為了任何不法的或其它的目的而改變這樣的可信的單元。
如應該理解的，在許可證16中的規(guī)則和要求能指定用戶是否具有基于幾個因素的任何因素再現(xiàn)數(shù)字內(nèi)容12的權限，這些因素包括用戶是誰，用戶在什么地方，用戶使用的是什么類型的計算設備，什么再現(xiàn)應用程序在調(diào)用DRM系統(tǒng)，日期，時間等等。此外，許可證16的規(guī)則和要求可限制許可證16為，例如，預定次數(shù)的播放，或預定的播放時間。
可按照任何合適的語言和語法在許可證16中指定規(guī)則和要求。例如，該語言可簡單地指定必須滿足的屬性和值(例如，日期必須比X晚)，或者可要求按照一指定的腳本執(zhí)行功能(例如，如果日期大于X，那么做...)。
在許可證鑒別器20確定許可證16是有效的且用戶滿足在其中的規(guī)則和要求時，于是可再現(xiàn)數(shù)字內(nèi)容12。更具體地說，要再現(xiàn)內(nèi)容12，從許可證16獲得解密密鑰(KD)，并將它應用于來自內(nèi)容包13的(KD(內(nèi)容))，以產(chǎn)生實際內(nèi)容12，然后實際上再現(xiàn)實際內(nèi)容12。
發(fā)行數(shù)字內(nèi)容圖3是按照本發(fā)明的系統(tǒng)和方法的一實施例的功能方框圖，用于發(fā)行數(shù)字內(nèi)容。在這里所使用的術語“發(fā)行(publishing)”，指應用程序或服務依從的一個過程，以對于可信的實體(trusted entity)建立一組權限和條件，該實體能為那個內(nèi)容發(fā)布這組權限和條件，以及那些權限和條件能對誰發(fā)布。按照本發(fā)明，發(fā)行過程包括加密數(shù)字內(nèi)容和將它關聯(lián)于一永久可實施的權限列表，永久可實施的權限是內(nèi)容的作者想要用于內(nèi)容的所有可能的用戶的權限。這個過程可以安全的方法執(zhí)行，以阻止對任何權限或?qū)?nèi)容的訪問，除非內(nèi)容的作者想要。
在本發(fā)明的一個實施例中，具體地說，可使用三個實體發(fā)行安全的數(shù)字內(nèi)容一個內(nèi)容準備應用程序(content preparation application)302，在客戶機300上執(zhí)行并用于準備發(fā)行的內(nèi)容，一個數(shù)據(jù)權限管理(DRM)應用編程接口(API)306，也駐留在客戶機設備300上，以及一個DRM服務器320，以通信方式通過通信網(wǎng)絡330連接到客戶機300。在本發(fā)明的一個實施例中，通信網(wǎng)絡330包括因特網(wǎng)，盡管應該理解，通信網(wǎng)絡330可能是任何局域或廣域網(wǎng)，例如一私有的內(nèi)部互聯(lián)網(wǎng)。
內(nèi)容準備應用程序302可以是任何產(chǎn)生數(shù)字內(nèi)容的應用程序。例如，應用程序302可以是一個字處理器或其它發(fā)行物，它產(chǎn)生數(shù)字文本文件、數(shù)字音樂、視頻或其它這樣的內(nèi)容。內(nèi)容也可能包括流化的內(nèi)容，諸如例如流化的實況或錄制的事件的音頻/視頻。按照本發(fā)明，內(nèi)容準備應用程序請求其用戶使用用戶提供的密鑰加密內(nèi)容。應用程序302使用這個密鑰加密數(shù)字內(nèi)容，因而形成加密的數(shù)字內(nèi)容文件304?？蛻魴C應用程序也請求用戶為數(shù)字內(nèi)容文件304提供權限數(shù)據(jù)。權限數(shù)據(jù)包括用于每個具有數(shù)字內(nèi)容中的權限的實體的相應的身份。
這樣的實體可以是，例如，個人、一類個人或設備。對于每個這樣的實體，權限數(shù)據(jù)還包括一個那個實體在內(nèi)容中具有的權限的列表，以及可被強加于那些權限的任何或全部的任何條件。這樣的權限可包括對數(shù)字內(nèi)容讀、編輯、復制、打印等的權限。另外，權限可以是內(nèi)含的或除外的。內(nèi)含的權限表示一指定的用戶具有在內(nèi)容中指定的權限(例如，用戶能夠編輯數(shù)字內(nèi)容)。除外的權限表示一指定的用戶具有在內(nèi)容中的全部權限，除了那些指定的(例如，用戶能對數(shù)字內(nèi)容做任何事，除復制它之外)。
按照本發(fā)明的一個實施例，客戶機API 306可將加密的數(shù)字內(nèi)容和權限數(shù)據(jù)傳遞至DRM服務器320。使用下面詳細說明的過程，DRM服務器320確定它是否能夠?qū)嵤┯脩粢呀?jīng)分配的權限，如果是，則DRM320簽署權限數(shù)據(jù)以形成一簽署的權限標簽(signed rights label)(SRL)308。不過，一般而言，任何可信的實體能夠簽署權限數(shù)據(jù)，最好使用由DRM服務器320信任的密鑰。例如，客戶機能夠使用由DRM服務器320為它提供的密鑰簽署權限數(shù)據(jù)。
權限標簽308可包括代表權限描述的數(shù)據(jù)、加密的內(nèi)容密鑰和在權限描述和加密的內(nèi)容密鑰上的數(shù)字簽名。如果DRM服務器正在簽署權限標簽，則它將簽署的權限標簽308通過客戶機API306傳遞回到客戶機，API306將簽署的權限標簽308存儲在客戶機設備300上。內(nèi)容準備應用程序302然后將簽署的權限標簽308與加密的數(shù)字內(nèi)容文件304關聯(lián)。例如，SRL308與加密的數(shù)字內(nèi)容文件集中在一起以形成權限管理的內(nèi)容文件310。
不過，一般而言，權限數(shù)據(jù)不需要與數(shù)字內(nèi)容結合。例如，權限數(shù)據(jù)可能被存儲在一個已知的位置，而被存儲的權限數(shù)據(jù)的參考可能與加密的數(shù)字內(nèi)容結合。這個參考可能包括指示存儲權限數(shù)據(jù)的位置(例如，包含這個權限數(shù)據(jù)的數(shù)據(jù)存儲)的標識符，以及相應于那個特定的權限數(shù)據(jù)在那個特定的存儲位置的標識符(例如，標識包含感興趣的特定的權限數(shù)據(jù)的文件)。權限管理的內(nèi)容310然后可被傳送到任何人任何地方，且只有那些具有恢復內(nèi)容的權限的實體能夠恢復內(nèi)容，且只按照它們被分配的權限。
圖4是按照本發(fā)明的典型方法400的流程圖，用于發(fā)行權限管理的數(shù)字內(nèi)容，在其中由DRM服務器簽署權限標簽。不過應該理解，這個實施例僅僅是示范的，且一般而言，可由任何可信的實體簽署權限標簽。一般而言，按照本發(fā)明用于發(fā)行數(shù)字內(nèi)容的方法可包括使用一內(nèi)容密鑰(CK)加密數(shù)字內(nèi)容，生成與數(shù)字內(nèi)容關聯(lián)的權限描述，按照用于DRM服務器的公用密鑰(PU-DRM)以產(chǎn)生(PU-DRM(CK))，并基于一相應于(PU-DRM)的私有密鑰(PR-DRM)在權限描述和(PU-DRM(CK))上創(chuàng)建一數(shù)字簽名。
在步驟402，應用程序302生成一個被用于加密數(shù)字內(nèi)容的內(nèi)容密鑰(CK)。最好，內(nèi)容密鑰(CK)是一個對稱密鑰，盡管一般而言，任何密鑰可被用于加密數(shù)字內(nèi)容。對稱密鑰算法，有時被稱為“秘密關鍵碼(secret key)”算法，在它們要加密一消息時使用同一密鑰加密該消息。為了那個原因，最好將那個(CK)保密。在發(fā)送者與接收者之間的共用(CK)應該做得非常小心，以避免未經(jīng)授權的竊聽這樣的(CK)。因為(CK)是在加密者和解密者之間共用的，(CK)最好在傳輸任何加密的消息之前被傳送。
在本領域中幾個對稱密鑰生成算法是眾所周知的。在一個實施例中，使用數(shù)據(jù)加密標準(Data Encryption Standard)(DES)，盡管應該理解可使用任何對稱算法。這樣的對稱密鑰算法的實例包括，但不是限制，AES、Triple-DES(三重數(shù)據(jù)加密標準)、國際數(shù)據(jù)加密算法(International Data EncryptionAlgorithm)(IDEA)、Cast、Cast-128、RC4、RC5和SkipJack。
在步驟404，應用程序302用對稱內(nèi)容密鑰(CK)加密數(shù)字內(nèi)容形成加密的數(shù)字內(nèi)容304，它可使用符號(CK(content))書寫。使用應用程序302的作者也可生成與數(shù)字內(nèi)容關聯(lián)的權限數(shù)據(jù)。這個權限數(shù)據(jù)可包括一個將授權恢復內(nèi)容的實體列表，以及每個實體相對于內(nèi)容所擁有的專用權限，連同可被強加于那些權限的任何條件。這樣的權限例如可包括觀看內(nèi)容、打印內(nèi)容等。應用程序302為API306提供權限數(shù)據(jù)。以XML/XrML格式的權限數(shù)據(jù)的實例作為附1附在這里。
在步驟406，API306生成第二加密密鑰(DES1)，它可被用于加密內(nèi)容密鑰(CK)。最好(DES1)也是一個對稱密鑰。在步驟408，API306用(DES1)加密(CK)以產(chǎn)生(DES1(CK))。在步驟410，API306丟棄(CK)，因為現(xiàn)在只能通過解密的(DES1(CK))得到(CK)的結果。要確保(CK(content))受中央DRM服務器320保護和在中央按照權限數(shù)據(jù)完成所有用于內(nèi)容的“許可請求”，API306在步驟412，與所提供的DRM服務器320聯(lián)系并取回它的公用密鑰(PU-DRM)。在步驟414，API306用(PU-DRM)加密(DES1)以產(chǎn)生(PU-DRM(DES1))。這樣，(CK)可受(PU-DRM)保護，以確保DRM服務器320是將來能夠取得對(CK)訪問的唯一的實體，如解密(CK(content))所要求的。在步驟416，API306用(DES1)加密權限數(shù)據(jù)(即，授權的實體列表和與在這個列表中每個授權的實體關聯(lián)的相應的權限和條件)，以產(chǎn)生(DES1(權限數(shù)據(jù)))。
在一個可替換的實施例中，(CK)可被用于直接加密權限數(shù)據(jù)以產(chǎn)生(CK(權限數(shù)據(jù)))，且(PU-DRM)可被用于直接加密(CK)以產(chǎn)生(PU-DRM(CK))，因此完成前述的(DES1)的使用。不過，使用(DES1)加密權限數(shù)據(jù)和(CK)允許這樣的(DES1)遵守可能服從DRM服務器的任何特定的算法，然而(CK)可能由一個與DRM服務器獨立的實體指定且可能不服從DRM服務器。
在步驟418，內(nèi)容準備應用程序302可將(PU-DRM(DES1))和(DES1(權限數(shù)據(jù)))作為用于簽署的權限標簽提交給DRM服務器320?？商鎿Q地，客戶機本身可簽署權限數(shù)據(jù)。如果正在將權限數(shù)據(jù)提交至服務器用于簽署，那么在步驟420，DRM服務器320訪問權限數(shù)據(jù)并驗證它能夠?qū)嵤┰谒峤坏臋嘞迾撕炛械臋嘞藓蜅l件。要驗證它能夠?qū)嵤嘞迶?shù)據(jù)，DRM服務器320將(PR-DRM)應用于(PU-DRM(DES1))以產(chǎn)生(DES1)，然后將(DES1)應用于(DES1(權限數(shù)據(jù)))以產(chǎn)生不用密碼的權限數(shù)據(jù)。服務器320然后可進行任何政策檢查以驗證在權限數(shù)據(jù)中指定的用戶、權限和條件是在由服務器320所實施的任何政策之內(nèi)的。服務器320原來提交的包括(PU-DRM(DES1))和(DES1(權限數(shù)據(jù)))的權限標簽，以產(chǎn)生簽署的權限標簽(SRL)308，在其中簽字是基于DRM服務器320的私有密鑰(PR-DRM)的，并將SRL308返回至API306，API306然后將返回的SRL308提供給客戶機應用程序302。
SRL308是以數(shù)字方式簽署的文檔，使它防篡改。另外，SRL308獨立于用于加密內(nèi)容的實際的密鑰類型和算法，但與它正在保護的內(nèi)容保持1-1關系?，F(xiàn)在參考圖4A，在本發(fā)明的一個實施例中，SRL308可包括關于內(nèi)容的信息，它是SRL308的基礎，有可能包括一個內(nèi)容的ID(標識符)；關于簽署這個SRL308的DRM服務器的信息，包括(PU-DRM(DES1))和參考信息(referral information)諸如用于在網(wǎng)絡上定位DRM服務器的URL及這個URL失敗時的退回信息；描述SRL308本身的信息；(DES1(權限數(shù)據(jù)))；(DES1(CK))；和其中的S(PR-DRM)。用XML/XrML的實例SRL308作為附錄2附在這里。
通過確?？尚诺膶嶓w簽署權限數(shù)據(jù)以創(chuàng)建簽署的權限標簽308，按照由發(fā)行人在權限標簽308中的權限數(shù)據(jù)中所述的條款，DRM服務器聲稱它將發(fā)布用于內(nèi)容的許可證。如應該意識到的，要求用戶獲得許可證以再現(xiàn)內(nèi)容，尤其是因為許可證包含內(nèi)容密鑰(CK)。當用戶想要獲得用于加密內(nèi)容的許可證時，用戶可向DRM服務器320或其它許可證發(fā)布實體(license issuing entity)提供許可證請求，該請求包括用于內(nèi)容的簽署的權限標簽308和驗證用戶的憑證的證書。許可證發(fā)布實體然后可解密(PU-DRM(DES1))和(DES1(權限數(shù)據(jù)))以產(chǎn)生權限數(shù)據(jù)，向許可證請求實體(license requesting entity)列出由作者準予的所有權限(如果有的話)，并構造一個只具有那些特定權限的許可證。
最好，在應用程序302接收SRL308時，這樣的應用程序302將簽署的權限標簽308與相應的(CK(內(nèi)容))304集中以構成權限管理的數(shù)字內(nèi)容?？商鎿Q地，可將權限數(shù)據(jù)存儲在一個已知的位置中，帶有為加密的數(shù)字內(nèi)容提供的那個位置的參考。這樣，DRM允許的再現(xiàn)應用程序能夠通過再現(xiàn)應用程序從正在試圖再現(xiàn)的這件內(nèi)容發(fā)現(xiàn)簽署的權限標簽308。這個發(fā)現(xiàn)觸發(fā)再現(xiàn)應用程序發(fā)起一個對于DRM許可服務器320的許可證請求。發(fā)行應用程序302可存儲一個指向DRM許可服務器320的URL，例如，或者DRM許可服務器320可將它自己的URL，在以數(shù)字方式簽署權限標簽之前作為一件元數(shù)據(jù)嵌入到權限標簽中，因此由再現(xiàn)應用程序調(diào)用的DRM客戶機API306能夠識別正確的DRM許可服務器320。最好，在簽署權限標簽之前，將一個唯一的標識符，諸如全球唯一標識符(globally unique identifier)(GUID)放入權限標簽中。
在本發(fā)明的一個實施例中，簡單對象訪問協(xié)議(simple object accessprotocol)(SOAP)可用于內(nèi)容準備應用程序302或再現(xiàn)應用程序和DRM服務器320之間的通信。另外，可提供API庫諸如API306，因此不要求應用程序諸如應用程序302實現(xiàn)DRM協(xié)議的客戶端，而是能夠只進行本地API調(diào)用。最好，使用XrML，一種XML語言，描述用于數(shù)字內(nèi)容的權限描述、許可證和權限標簽，盡管應該理解，任何合適的格式能夠被用于權限描述和其它數(shù)據(jù)。
獲得用于發(fā)行的內(nèi)容的許可證圖5是按照本發(fā)明的系統(tǒng)和方法的一個實施例的功能方框圖，用于許可權限管理的數(shù)字內(nèi)容。“許可(licensing)”，作為在此所使用的術語，指應用程序或服務遵守的請求和接收許可證的過程，許可證將使一個在許可證中指定的實體能夠按照在許可證中所指定的條款恢復內(nèi)容。許可過程的輸入可包括與正在請求的許可證所用于的內(nèi)容關聯(lián)的簽署的權限標簽(SRL)308，和正在請求的許可證所用于的實體的公用密鑰證書。注意，請求許可證的實體不需要必須是正在請求的許可證所用于的實體。一般地，許可證包括來自SRL308的權限描述，能夠解密加密的內(nèi)容的加密的密鑰，和在權限描述和加密的密鑰上的數(shù)字簽名。數(shù)字簽名斷言所指定的實體和權限是合法的。
一種用于應用程序302恢復權限管理的內(nèi)容310的方法是，客戶機API306將權限管理的內(nèi)容3 10簽署的權限標簽308通過通信網(wǎng)絡330傳送到DRM服務器320。DRM服務器320的位置，例如可在SRL308中的參考信息中找到。在這樣一個實施例中，DRM許可服務器320，通過下面詳細描述的過程，可使用權限標簽中的權限描述確定它是否能夠發(fā)布許可證，如果能，則導出權限描述以包括許可證。
如上所述，權限標簽308包含按照DRM服務器320的公用密鑰(PU-DRM)加密的內(nèi)容密鑰(CK)(即(PU-DRM(CK)))。在發(fā)布許可證的過程中，DRM服務器320安全地解密這個值以獲得(CK)。然后它使用公用密鑰證書中的公用密鑰(PU-ENTITY)以重新加密(CK)(即(PU-ENTITY(CK)))，公用密鑰證書是在許可證請求中被向上傳遞的。重新被加密的(PU-ENTITY(CK))是服務器320放在許可證中的內(nèi)容。這樣，可在沒有暴露(CK)的危險的情況下，將許可證返回給調(diào)用者，因為只有關聯(lián)于私有密鑰(PR-ENTITY)的持有者能夠從(PU-ENTITY(CK))恢復(CK)?？蛻鬉PI306然后使用(CK)解密加密的內(nèi)容以構成解密的數(shù)字內(nèi)容312。客戶應用程序302然后能夠使用按照在許可證中所提供的權限的解密的數(shù)字內(nèi)容312。
可替換地，例如，諸如發(fā)行客戶機的客戶機，能夠發(fā)布它自己的許可證以恢復內(nèi)容。在這樣一個實施例中，受保護的過程可在客戶計算機上運行，為客戶機提供在合適的環(huán)境下解密數(shù)字內(nèi)容所需要的密鑰。
圖6A和6B提供按照本發(fā)明的方法600的一個實施例的流程圖，用于許可權限管理的數(shù)字內(nèi)容。按照本發(fā)明，請求實體可提交一個代表一或多個可能的許可證持有人的許可證請求。請求實體可以是/可以不是可能的許可證持有人之一。可能的許可證持有人可以是一個人、一個組、一個設備或任何能夠以任何方式恢復內(nèi)容的其它實體?，F(xiàn)在將參考一個實施例描述方法600，在這個實施例中，DRM服務器處理許可證請求，盡管應該理解，可在客戶機上執(zhí)行許可證請求處理，以及由客戶機直接發(fā)布許可證。
在步驟602，許可證發(fā)布實體諸如DRM服務器，例如，接收一個許可證請求。最好，許可證請求包括用于一或多個被請求的許可證持有人的每一個的公用密鑰證書或者身份。
在步驟604，認證請求實體(即產(chǎn)生許可證請求的實體)。按照本發(fā)明的一個實施例，許可證發(fā)布實體可被配置為使用協(xié)議(例如質(zhì)詢-應答(challenge-response))認證以確定請求實體的身份，或者它可被配置為不要求認證請求實體(也被稱為“允許匿名認證(allowing anonymous authentication)”)。當要求認證時，可使用任何類型的認證方案(例如，上面提到的質(zhì)詢-應答方案，用戶標識符和口令(user-id-and-password)方案諸如MICROSOFT.NET、PASSPORT、WINDOWS授權、x509等)。最好，既允許匿名認證，又支持由集成信息系統(tǒng)支持的任何協(xié)議認證方案。認證步驟的結果將是一個身份，諸如例如，一個“匿名”身份(對于匿名認證)，或者一個個人帳戶身份。如果因任何原因不能認證許可證請求，則返回一個錯誤并不準予許可證。
在步驟606，授權認證的實體一即，確定在步驟608被認證的實體是否被允許請求許可證(或者為它自己或者代表另一個實體)。最好，許可證發(fā)布實體存儲一個被允許(或者不被允許)請求許可證的實體列表。在一個實施例中，在身份列表中的一個身份是產(chǎn)生請求的實體的身份，而不是正在請求的許可證所用于的實體的身份，盡管它可能是任一個。例如，可允許個人帳戶身份直接產(chǎn)生許可證請求，但是可信的服務器過程可代表這樣一個實體產(chǎn)生許可證請求。
按照本發(fā)明，許可證請求能夠包括用于每個可能的許可證持有人的公用密鑰證書或者身份。如果只為一個許可證持有人請求許可證，則只指定一個證書或身份。如果為多個許可證持有人請求許可證，則可為每個可能的許可證持有人指定證書或身份。
最好，許可證發(fā)布實體具有用于每個有效許可證持有人的公用密鑰證書。不過，應用程序302可能想要為給定用戶生成許可證，但是應用程序302不能訪問用于那個用戶的公用密鑰證書。在這樣一種情況下，應用程序302可在許可證請求中指定用戶的身份，并且結果，許可證發(fā)布實體可調(diào)用已注冊的證書插件模塊，該模塊在目錄服務中執(zhí)行查找并返回合適的公用密鑰證書。
如果在步驟608，發(fā)布實體確定公用密鑰證書沒有被包括在許可證請求中，那么發(fā)布實體使用指定的身份在目錄服務或數(shù)據(jù)庫中查找合適的公用密鑰證書。如果在步驟610，發(fā)布實體確定證書在目錄中，那么在步驟612，取回證書。在一個實施例中，使用證書插件經(jīng)由目錄訪問協(xié)議從目錄服務取回公用密鑰證書。如果或者在請求中或者在目錄中，都不能為一給定的可能的許可證持有人找到證書，那么許可證服務器不為那個可能的許可證持有人生成許可證，且在步驟614，返回一個錯誤至請求實體。
假定許可證發(fā)布實體具有用于至少一個可能的許可證持有人的公用密鑰證書，那么在步驟616，發(fā)布實體驗證許可證持有人證書的可信性。最好，用一組可信的證書發(fā)布者證書(trusted certificate issuer certificate)配置發(fā)布實體，并確定許可證持有人證書的發(fā)布者是否在可信的發(fā)布者列表中。如果在步驟616，發(fā)布實體確定許可證持有人證書的發(fā)布者不在可信的發(fā)布者列表中，那么對于那個許可證持有人的請求失敗，且在步驟614產(chǎn)生一個錯誤。這樣，可信的發(fā)布者沒有發(fā)布其證書的任何可能的許可證持有人，將接收不到許可證。
另外，發(fā)布實體最好對證書鏈中所有的數(shù)字簽名執(zhí)行數(shù)字簽名驗證，該證書鏈從可信的發(fā)布者證書到個人許可證持有人公用密鑰證書。在一個鏈中驗證數(shù)字簽名的過程是一個眾所周知的算法。如果沒有證實用于一給定的可能的許可證持有人的公用密鑰證書，或者沒有證實在鏈中的一個證書，則可能的許可證持有人是不可信的，且因此不為那個可能的許可證持有人發(fā)布證書。否則，在步驟618，可發(fā)布證書。這個過程在步驟620重復，直到已經(jīng)處理所有已經(jīng)請求許可證的實體為止。
如在圖6B中所示，許可證發(fā)布實體進行至驗證在許可證請求中所接收的簽署的權限標簽308。在一個實施例中，發(fā)布實體可使用權限標簽插件和后端數(shù)據(jù)庫，該數(shù)據(jù)庫在服務器上存儲由發(fā)布實體簽署的每個權限標簽的主拷貝。權限標簽是由在發(fā)行時放入它們中的GUID標識的。在許可時間(在步驟622)，發(fā)布實體解析在許可證請求中的權限標簽輸入并取回其GUID。然后它將這個GUID傳遞至權限標簽插件，該插件向數(shù)據(jù)庫發(fā)布一個查詢以取回主權限標簽的一個拷貝。這個主權限標簽直到現(xiàn)在可能比在許可證請求中發(fā)送的權限標簽的拷貝更多，并且它將是在下面的步驟中在請求中所使用的權限標簽。如果基于GUID在數(shù)據(jù)庫中找不到權限標簽，發(fā)布實體在步驟624檢查其政策，以基于在請求中的權限標簽確定它是否還允許發(fā)布許可證。如果政策不允許這個，則許可證請求將在步驟626失敗，且在步驟628將向API306返回一個錯誤。
在步驟630，許可證發(fā)布實體驗證權限標簽308。驗證在權限標簽上的數(shù)字簽名，且如果許可證發(fā)布實體不是權限標簽的發(fā)布者(簽署它的實體)，那么許可證發(fā)布實體確定權限標簽的發(fā)布者是否是另一個可信的實體(例如，一個使許可證發(fā)布實體能夠與其共用密鑰材料的實體)。如果權限標簽沒有證實，或者它不是由可信的實體發(fā)布的，那么在步驟626許可證請求失敗，且在步驟628將向API306返回一個錯誤。
在所有的驗證已經(jīng)發(fā)生后，許可證發(fā)布實體將權限標簽308譯成用于每個被批準的許可證持有人的許可證。在步驟632，許可證發(fā)布實體為要向每個許可證持有人發(fā)布的許可證生成一個相應的權限描述。對于每個許可證，發(fā)布實體對照權限標簽中的權限描述所指定的身份，鑒定在那個許可證持有人的公用密鑰證書中指定的身份。權限描述將一組身份分配給每個權限或權限組，該組身份能夠行使在一許可證中的那個權限或那組權限。對于與這個許可證持有人的身份相關聯(lián)的每個權限或權限組，那個權限或那組權限被復制到一個用于這個許可證的新數(shù)據(jù)結構中。最后得到的數(shù)據(jù)結構是在用于特定的許可證持有人的許可證中的權限描述。作為這個過程的一部分，許可證發(fā)布實體鑒定任何先決條件，它們可能與在權限標簽的權限描述中的任何權限或權限組關聯(lián)。例如，一個權限可具有與其關聯(lián)的時間先決條件，它限制許可證發(fā)布實體在一指定的時間之后發(fā)布許可證。在這種情況下，發(fā)布實體將需要檢查當前時間，且如果過了在先決條件中所指定的時間，那么發(fā)布實體將不能夠向許可證持有人發(fā)布那個權限，即使那個許可證持有人的身份與那個權限關聯(lián)。
在步驟636，發(fā)布實體從權限標簽308獲得(PU-DRM(DES1))和(DES1(CK))并應用(PR-DRM)以獲得(CK)。發(fā)布實體然后使用(PU-ENTITY)許可證持有人的公用密鑰證書重新加密(CK)以產(chǎn)生(PU-ENTITY(CK))。在步驟638，發(fā)布實體將所生成的權限描述與(PU-ENTITY(CK))集中，并使用(PR-DRM)以數(shù)字方式簽署最后得到的數(shù)據(jù)結構。這個簽署的數(shù)據(jù)結構是用于這個特定的許可證持有人的許可證。
當在步驟640發(fā)布實體確定沒有更多的許可證要為特定的請求生成時，它將已經(jīng)生成零或多個許可證。在步驟642將所生成的許可證返回至請求實體，連同與那些許可證關聯(lián)的證書鏈一起(例如，服務器自己的公用密鑰證書和發(fā)布其證書的證書等等)。
在按照本發(fā)明的系統(tǒng)的一個實施例中，可使用多個許可證頒發(fā)者密鑰。在這樣一個實施例中，加密地通過權限標簽308傳播并到許可證持有人的內(nèi)容密鑰(CK)，實際上可以是任何任意的數(shù)據(jù)。一個特別有用的變化是使用一組獨立的、加密的、分別與權限描述中不同的權限或不同的原則關聯(lián)的內(nèi)容密鑰(CK)。例如，在一歌集中歌曲的數(shù)據(jù)版本可全部用不同的密鑰(CK)加密?？蓪⑦@些密鑰(CK)包括在同一權限標簽中，但一個原則可具有播放歌曲中的一首的權限(例如，他可能只具有在他的許可證中取得一個密鑰的權限)，而第二個原則可能具有播放所有歌曲的權限(她可能具有在她的許可證中取得所有密鑰的權限)。
最好，按照本發(fā)明的系統(tǒng)使發(fā)行應用程序/用戶能夠在權限標簽308中指定許可證持有人的組或類。在這樣一個實施例中，許可證發(fā)布實體將鑒定在權限標簽中指定的任何組/類，以確定當前的許可證持有人身份是否是那些組類的成員。如果在指定的組/類中找到成員資格，則發(fā)布實體可將與組/類關聯(lián)的權限或權限組添加到用于許可證持有人的權限描述數(shù)據(jù)結構。
在本發(fā)明的一個實施例中，在DRM服務器中的發(fā)行和許可協(xié)議接口(publish and license protocol interface)支持調(diào)用應用程序或用戶的認證和授權，以及用于DRM服務器的管理控制臺(administrative console)允許管理者為許可和發(fā)行接口兩者生成一個訪問控制列表。這使服務器的客戶能夠應用政策，通過政策允許用戶/應用程序或者發(fā)行或者許可，或者兩者。
修改或重新發(fā)行簽署的權限標簽308在本發(fā)明的一個實施例中，可“再發(fā)行(republish)”SRL308，如果已經(jīng)準予內(nèi)容的用戶有足夠的許可這么做。也就是說，如果允許，則用戶可改變在SRL308內(nèi)的權限數(shù)據(jù)。注意，應該謹慎地和深思遠慮地準予改變權限數(shù)據(jù)這樣的許可，特別是因為具有改變權限數(shù)據(jù)的許可的用戶基本上能夠準予它自己相關于所關聯(lián)的內(nèi)容的寬廣的權限。想象得到的，這樣一個用戶甚至能夠準予它自己暴露內(nèi)容和向世界傳送同一內(nèi)容的權限。
這里，改變的許可是通過在SRL308中權限數(shù)據(jù)內(nèi)包括一個一個標志表示的，這個標志表示特定的用戶或用戶類能夠?qū)嶋H上改變或‘再發(fā)行’權限數(shù)據(jù)和權限標簽308。當DRM服務器320接收帶有與對許可證的請求有關的這樣的許可的SRL308時，DRM服務器320在用戶所請求的許可證內(nèi)包括按照用戶的公用密鑰(即PU-ENTITY)加密的對稱密鑰(DES1)，以產(chǎn)生(PU-ENTITY(DES1))。
這樣，要在SRL308內(nèi)編輯權限數(shù)據(jù)，以及現(xiàn)在轉(zhuǎn)到圖7，用戶從許可證取回(PU-ENTITY(DES1))(步驟701)，對它應用(PR-ENTITY)以產(chǎn)生(DES1)(步驟703)，從SRL308取回(DES1(權限數(shù)據(jù)))(步驟705)，并對它應用(DES1)以產(chǎn)生權限數(shù)據(jù)(步驟707)。之后，用戶按需要改變權限數(shù)據(jù)(步驟709)，并以結合圖4闡述的方式將改變的權限數(shù)據(jù)提交給DRM服務器320，以獲得簽署的權限標簽308(步驟711)。當然，這里，簽署的權限標簽308實際上是一個再發(fā)行的SRL308，且因此一旦接收到SRL308(步驟713)，用戶剝?nèi)ゼ性陉P聯(lián)的內(nèi)容中的原來的SRL308(步驟715)，并然后將再發(fā)行的SRL308集中到這樣的內(nèi)容中(步驟717)。
這樣，以及可意識到的，再發(fā)行SRL308使用戶能夠在不必改變所關聯(lián)的內(nèi)容的情況下，更新SRL308中的權限數(shù)據(jù)，包括權限、條件或用戶。具體地說，再發(fā)行不要求用新的(CK)重新加密所關聯(lián)的內(nèi)容。而且，再發(fā)行不要求從零開始生成新的SRL，特別是因為原來的SRL308在其中具有許多條款，可將它們復制到新的SRL308。
自發(fā)行簽署的權限標簽308
在本發(fā)明的一個實施例中，可通過請求用戶本身簽署SRL308。因此，用戶不需要聯(lián)系DRM服務器320以獲得用于一件關聯(lián)的內(nèi)容的SRL308。結果，自發(fā)行也可指離線發(fā)行。在這樣的實施例中，可要求用戶與DRM服務器320聯(lián)系以請求一個基于這樣一個自發(fā)行的SRL308的許可證。應該理解，可使發(fā)行實體能夠發(fā)布它自己的許可證。
具體地說，以及現(xiàn)在參考圖8，在實施例中，首先通過從DRM服務器320接收一DRM證書為用戶提供自發(fā)行，DRM證書包括一公用密鑰(PU-CERT)和按照用戶的公用密鑰(PU-ENTITY)加密的相應的私有密鑰以產(chǎn)生(PU-ENTITY(PR-CERT))。這個證書應該由DRM服務器320的私有密鑰(PR-DRM)簽署，因此DRM服務器320可驗證完全一致，在下面將更詳細地討論。如可意識到的，DRM證書810授權用戶自發(fā)行。如也可意識到的，密鑰對(PU-CERT，PR-CERT)是與(PU-ENTITY，PR-ENTITY)分開的，且專門為自發(fā)行使用。注意，沒有密鑰對(PU-CERT，PR-CERT)也行，在這個情況下DRM證書810只包括用戶的公用密鑰(PU-ENTITY)，并由DRM服務器的私有密鑰(PR-DRM)簽署，這樣的DRM服務器320也可驗證完全一致。
自發(fā)行與如在圖4中所示的發(fā)行不同，在于用戶基本上取代DRM服務器320相關的在那里執(zhí)行的步驟。值得注意，用戶用如由DRM證書810獲得的(PR-CERT)簽署所提交的包括(PU-DRM(DES1))和(DES1(權限數(shù)據(jù)))的權限標簽，以產(chǎn)生簽署的權限標簽(SRL)308。如應該意識到的，用戶通過從這樣的DRM證書810獲得(PU-ENTITY(PR-CERT))并將(PR-ENTITY)應用于它，并從DRM證書810獲得(PR-CERT)。注意，盡管用戶不能驗證DRM服務器320能夠?qū)嵤┰谒峤坏臋嘞迾撕炛械臋嘞?，特別是因為用戶不具有要應用于(PU-DRM(DES1))的(PR-DRM)。因此，在基于自發(fā)行的SRL308請求許可證的時候，DRM服務器320本身應該執(zhí)行驗證。
一旦用戶自發(fā)行SRL308，用戶將這樣自發(fā)行的SRL308與使用的DRM證書810集中以產(chǎn)生與該內(nèi)容相同的內(nèi)容，以及將帶有SRL308和DRM證書810的這樣的內(nèi)容分發(fā)至另一個用戶。其后，其它用戶實質(zhì)上以如在圖6A和6B中所示的相同的方式，從DRM服務器320請求和獲得用于內(nèi)容的許可證。這里，然而，許可證請求用戶向DRM服務器提交作為集中于內(nèi)容中的自發(fā)行SRL308和DRM證書810兩者。DRM服務器320然后基于相應的(PU-DRM)驗證在DRM證書810中的S(PR-DRM)，且從DRM證書810獲得(PU-CERT)。DRM服務器320然后基于獲得的(PU-CERT)驗證SRL308中的S(PR-CERT)，且象以前一樣繼續(xù)。然而注意，由于用戶沒有驗證DRM服務器320能夠?qū)嵤┰赟RL308中的權限，以如上面所闡述的，DRM服務器320本身應該在這時執(zhí)行這個驗證。
權限模板如上所述，通過定義用戶或用戶類，定義用于每個被定義的用戶或用戶類的權限，且然后定義任何使用條件，在權限標簽中為用戶提供創(chuàng)建大多數(shù)任何種類的權限數(shù)據(jù)的自由。不過，值得注意，反復地為多個權限標簽定義權限數(shù)據(jù)是討厭的和重復的，特別是當為不同件內(nèi)容反復地定義同一用戶或用戶類、權限和條件的時候。這樣一個情況例如能發(fā)生在公司或辦公室環(huán)境中，在用戶反復地發(fā)行要由特定定義的用戶團隊共享的不同件內(nèi)容的時候。于是，在這樣一個情況下，且在本發(fā)明的一個實施例中，創(chuàng)建權限模板，在權限模板是已經(jīng)包括預定義的用戶組或用戶類、用于每個定義的用戶或用戶類的預定義的權限和預定義的使用條件的時候，用戶可在創(chuàng)建權限標簽時反復地使用權限模板。
在本發(fā)明的一個實施例中，且現(xiàn)在轉(zhuǎn)到圖9，權限模板900實質(zhì)上具有與將在權限標簽中的相同的權限數(shù)據(jù)。不過，由于(DES1)是不知道的，直到發(fā)行內(nèi)容為止，權限數(shù)據(jù)不能按照這樣的(DES1)加密，如在權限標簽中的情況。在本發(fā)明的一個實施例中，然后，在圖4的步驟416的用(DES1)加密權限數(shù)據(jù)的期間，提交帶有未加密的權限數(shù)據(jù)的權限模板900，以產(chǎn)生(DES1(權限數(shù)據(jù)))。當然，在這樣加密之前，從所提交的權限模板900取回權限數(shù)據(jù)。
可以是或可以不是這個情況，即在構建權限模板的時候，DRM服務器320和它的公用密鑰(PU-DRM)是已知的。另外，即使知道，可以是或可以不是這個情況，即存在多于一個DRM服務器320，每個具有其自己的(PU-DRM)。然而，在構建權限模板的時候DRM服務器320和其公用密鑰(PU-DRM)是已知的情況下，以及在只使用一個DRM服務器320，或者只有一個DRM服務器320要結合權限模板900使用的情況下，這樣的權限模板也可在其中包括關于DRM服務器的信息，該DRM服務器是要簽署從權限模板900得到的權限標簽，包括其公用密鑰(PU-DRM)。盡管這樣的(PU-DRM)出現(xiàn)在SRL308用作加密(DES1)以產(chǎn)生(PU-DRM(DES1))，要再次意識到(DES1)是不知道的，直到發(fā)行內(nèi)容為止，并因此在權限模板900中的(PU-DRM)不能加密這樣的(DES1)，如在權限標簽中的情況。然后，在本發(fā)明的一個實施例中，在圖4的步驟414的用(PU-DRM)加密(DES1)期間，提交帶有未加密的(PU-DRM)的權限模板900，以產(chǎn)生(PU-DRM(DES1))。當然，在使用之前，從所提交的權限模板900取回(PU-DRM)。
還是在上述情況下，可被包括在權限模板中的關于DRM服務器的其它信息也可包括參考信息，諸如用于在網(wǎng)絡上定位DRM服務器的URL，和如果URL失敗時退回的信息。在任何情況下，權限模板還可在其中包括描述權限模板900本身的信息。注意，權限模板900也可為與被發(fā)行的內(nèi)容相關的信息提供空間，諸如出現(xiàn)在與內(nèi)容和/或加密的密鑰(CK)和(DES1)有關的權限標簽中的信息，盡管如果將權限模板的實例化實際地轉(zhuǎn)換到權限標簽中，這樣的空間是不必要的。
盡管如到現(xiàn)在為止所揭示的權限模板900主要是為了方便用戶，也要意識到在某些環(huán)境中，用戶不應該具有無限制的自由以在權限標簽中定義權限數(shù)據(jù)，并且可使用權限模板900限制能創(chuàng)建的權限標簽的范圍或類型。例如，且特別是在公司或辦公室環(huán)境的情況下，它可被預定義為一特定用戶應該始終只向一類特定的用戶發(fā)行內(nèi)容或者該用戶應該從不向一類特定的用戶發(fā)行內(nèi)容的政策。在任何情況下，以及在本發(fā)明的一個實施例中，這樣的政策被作為權限數(shù)據(jù)包含在一或多個權限模板900中，且可在發(fā)行內(nèi)容時限制用戶使用這樣的權限模板以創(chuàng)建權限標簽。值得注意，使可用于用戶為該用戶指定發(fā)行政策的一個權限模板900或一組權限模板900，可在不脫離本發(fā)明的精神和范圍的情況下，指定任何特殊類型的發(fā)行政策。
要為受限制的用戶等等指定權限模板900，以及現(xiàn)在轉(zhuǎn)到圖10，管理者等等實際上通過預定義的權限數(shù)據(jù)(步驟1001)，以及定義可能是必需的和適當?shù)娜魏纹渌鼣?shù)據(jù)，諸如相關與特定的DRM服務器320相關的信息(步驟1003)，構建權限模板900。值得注意，要完成由受限制的用戶等等使用的權限模板，必須使權限模板900為正式的。也就是說，權限模板900必須可被識別為一個受限制的用戶等等可使用的權限模板。因此，在本發(fā)明的一個實施例中，如由管理者等等構建的權限模板被提交至DRM服務器320用于由其簽署，在這里這樣的簽署使權限模板為正式的(步驟1005)。
注意，如果這樣的信息實際上真的存在于權限模板900中，簽署的DRM服務器320是其信息在權限模板900中的DRM服務器320。還注意，DRM服務器320可只在進行任何必要的檢查時，簽署權限模板900，或者在根本沒有任何檢查的情況下可簽署權限模板900。最后注意，來自DRM服務器320的模板簽名S(PR-DRM-T)(在這時-T表示用于ORT(正式的權限模板)900的簽名)，應該基于至少在權限模板900中預定義的權限數(shù)據(jù)，但在不脫離本發(fā)明的精神和范圍的情況下，還可以基于其它信息。如下面所述，將簽名S(PR-DRM-T)合并到權限標簽中，并且結合權限標簽驗證這個簽名，且因此無論簽名基于什么，應該將它以非改變的形式合并到權限標簽中。
在DRM服務器320簽署權限模板900和將它返回至管理者等等的時候，管理者接收帶有S(PR-DRM-T)的簽署的和現(xiàn)在正式的權限模板900(步驟1007)，并將正式的權限模板(ORT)900傳送至使用它的一或多個用戶(步驟1009)。因此，對于一個基于ORT900發(fā)行內(nèi)容的用戶，該用戶取回ORT900(步驟1011)，并通過提供任何需要的信息，諸如關于內(nèi)容的信息；合適的密鑰信息；由(DES1)加密以產(chǎn)生(DES1(權限數(shù)據(jù)))的來自ORT900的權限數(shù)據(jù)；以及任何來自ORT900的其它信息，基于ORT900來構建權限標簽(步驟1013)。值得注意地，用戶還用權限標簽包括來自ORT900的簽名S(PR-DRM-T)。
其后，以及象以前一樣，用戶將權限標簽提交至DRM服務器320用于簽署(步驟1015)。這里，然而，DRM服務器320將不簽署所提交的權限標簽，除非在其中的S(PR-DRM-T)證實。也就是說，DRM服務器320通過拒絕簽署所提交的權限標簽，除非所提交的權限標簽包括簽名S(PR-DRM-T)，實施用戶必須將所提交的權限標簽以ORT900為基礎。具體地說，DRM服務器320從所提交的權限標簽中，取回該S(PR-DRM-T)和該簽名所基于的無論什么信息，然后基于(PU-DRM)驗證這樣的簽名。注意，在所提交的權限標簽中權限數(shù)據(jù)是按照(DES1)加密的(即(DES1(權限數(shù)據(jù)))。因此，DRM服務器320必須首先獲得(DES1)并用它解密(DES1(權限數(shù)據(jù)))，如結合圖7所述的，要能夠驗證基于在所提交的權限標簽中的權限數(shù)據(jù)的簽名。
一旦被驗證，DRM服務器320用S(PR-DRM-L)簽署所提交的權限標簽以產(chǎn)生SRL308，如前面一樣(在這里-L表示簽名是用于SRL308的)。這里，S(PR-DRM-L)可代替S(PR-DRM-T)，或可以是附加于S(PR-DRM-T)。如果附加，則S(PR-DRM-L)可部分地基于S(PR-DRM-T)。注意，可使用(PR-DRM)產(chǎn)生S(PR-DRM-T)和S(PR-DRM-L)兩者，或者可使用不同的(PR-DRM)用于S(PR-DRM-T)和S(PR-DRM-L)的每一個。在DRM服務器320簽署權限標簽和將SRL308返回至用戶時，用戶接收帶有S(PR-DRM-L)的SRL308(步驟1017)并進行將前者集中到正在發(fā)行的內(nèi)容上，如前面一樣。
如果ORT900的簽名S(PR-DRM-T)是至少部分地基于在ORT900中預定義的權限數(shù)據(jù)的，那么這樣的權限數(shù)據(jù)如出現(xiàn)在SRL308中時(在DES1(權限數(shù)據(jù))中)不能被修改或改變。否則，S(PR-DRM-T)將不能證實。然而，在本發(fā)明的一個實施例中，在ORT900中的權限數(shù)據(jù)能夠在也被包括在ORT900中的規(guī)定的規(guī)則內(nèi)變化。例如，這些規(guī)則可指定要被包括在SRL308中的兩個權限數(shù)據(jù)組中的一個，或者可允許從一組選擇對象中選擇。如可意識到的，在不脫離本發(fā)明的精神和范圍的情況下，這些規(guī)則可以是以任何合適的語法闡述的任何特定的規(guī)則。這里，在創(chuàng)建權限標簽的時候，由合適的規(guī)則解釋器為用戶解釋規(guī)則。盡管權限數(shù)據(jù)可變化，但是規(guī)則不同樣變化，且因此用于ORT900的模板簽名S(PR-DRM-T)是至少部分地基于規(guī)則且不基于權限數(shù)據(jù)本身。結果，用ORT900包括的規(guī)則也必須用SRL308包括。
在本發(fā)明的一個實施例中，在ORT900中預定義的權限數(shù)據(jù)是部分地固定的和不變的，以及是部分地可變的和規(guī)則驅(qū)動的，如上所述。這里，用于ORT900的模板簽名S(PR-DRM-T)是至少部分地基于規(guī)則的固定的部分和基于用于權限數(shù)據(jù)的可變部分的規(guī)則。
如可意識到的，如由用戶擁有的ORT900可變成過時的或失效的。也就是說，ORT900通過在其中的權限數(shù)據(jù)可反映已經(jīng)變成過時的、不相關的或簡單地不可再應用的政策。例如，在ORT900的權限數(shù)據(jù)中指定的一或多個用戶或用戶類在政策環(huán)境內(nèi)可能不再存在，或者在ORT900的權限數(shù)據(jù)中指定的一特定的用戶或用戶類在政策環(huán)境內(nèi)可能不再具有同樣的權限。在這樣的情況下，可能是管理者已經(jīng)發(fā)布一個修改的ORT900，但用戶還使用先前的、失效的版本的ORT900。
在這樣的情況下，且在本發(fā)明的一個實施例中，然后，DRM服務器320在簽署提交的權限模板900以創(chuàng)建一個ORT900時保留ORT900的一個拷貝，每個ORT900具有唯一的辨識標記，且基于一個在其中包括這樣的ORT900的辨識標記的ORT900構建每個權限標簽。因此，在諸如結合圖10接收所提交的權限標簽時，DRM服務器320找出在權限標簽中ORT900的辨識標記，基于所找到的辨識標記取回這樣的ORT900的最新的拷貝，從所提交的權限標簽中刪除權限數(shù)據(jù)，然后至少部分地基于所插入的權限數(shù)據(jù)簽署權限標簽。當然，DRM服務器還執(zhí)行在如所述的過程中必需的和有義務的任何必需的加密和解密步驟，包括解密或重新加密(DES1(權限數(shù)據(jù)))。注意，如果DRM服務器自適應地替換所提交的權限標簽中的權限數(shù)據(jù)，這樣的權限標簽和由其構建這樣的權限標簽的ORT900就不必要在其中包括權限數(shù)據(jù)。改為，權限數(shù)據(jù)只需要駐留在DRM服務器320上。不過，用權限標簽和由其構建這樣的權限標簽的ORT900包括權限數(shù)據(jù)，對于用戶可能是有用的，并因此在某些情況下是有用的。
經(jīng)由目錄許可當為受保護的內(nèi)容發(fā)布許可證時，許可證發(fā)布實體(在下文中‘許可證頒發(fā)者(1icensor)’)從內(nèi)容查閱所發(fā)送的SRL308，以確定要為哪個用戶/組(group)/群(cluster)/部門(division)/平臺(platform)/等(在下文中‘實體(entity)’)提供權限，以及查閱所發(fā)送的證書以識別許可證請求者?；谏厦娴?，許可證頒發(fā)者確定要將在SRL308中所列出那些中哪些權限發(fā)布給請求者。概念地，許可證頒發(fā)者檢查在SRL308中所列出的實體并將這樣的實體與請求者比較。這樣，如果SRL308指定一特定的組要接收許可證且請求者是這樣的組的成員，則請求者被準予帶有如在SRL308中為這個組所述的權限的許可證。同樣，如果SRL308指定一特定的用戶要接收許可證且請求者是這樣的用戶，則請求者被準予帶有在SRL308中為這樣的用戶所述的權限的許可證。如可意識到的，特定的SRL308可列出用于它的幾個實體和權限，且一特定的請求者可被準予基于是一或多個實體的成員的許可證。
在本發(fā)明的一個實施例中，且如在圖12中所看到的，在所發(fā)送的證書1202中經(jīng)由標識符1204識別請求者，在這里標識符1204例如可以是一個別名，通過別名在一組織的目錄1206中識別請求者。因此，SRL308在其中按照這樣一個標識符1204列出每個被授權的實體。這樣，且作為處理對許可證1208的請求的部分，許可證頒發(fā)者1210從證書1202獲得請求者的標識符1204，并將所獲得的標識符1204與如在所發(fā)送SRL308中所列出的所有標識符1204比較。如果找到一個匹配，則許可證頒發(fā)者1210向請求者發(fā)布帶有在SRL308中為這樣的請求者的標識符1204指定的權限的許可證。
而且，在目錄1206有效的情況下，許可證頒發(fā)者1210也可確定請求者是否是在SRL308中所列出的任何其它實體，假定目錄1206包含適當?shù)慕徊嬉眯畔?，它能夠反映在每個這樣的其它實體中請求者的成員資格狀態(tài)。一般地，目錄1206為每個請求者不只是列出其標識符1204，還列出請求者其成員的每個組/群/部門/平臺/其它實體/等的標識符1208。注意，目錄1206可包括標識符1208，諸如郵件地址、可替換的郵件地址、ID(標識符)、可替換的ID、組成員資格、歷史標識符和/或等等。
有了從請求者接收的在其中帶有其標識符1204的證書1202，以及有了來自從請求者接收的SRL308的權限數(shù)據(jù)，然后，以及現(xiàn)在參考圖13，許可證頒發(fā)者1210以下列方式為請求者發(fā)布許可證1208。最初，許可證頒發(fā)者1210從所接收的證書1202獲得標識符1204(步驟1301)，并在目錄1206中找到所獲得的標識符1204(步驟1303)。之后，許可證頒發(fā)者1210基于被找到的標識符1204，在目錄1206中找到請求者1204是其成員的每個成員的標識符1204(步驟1305)。這樣，對于每個被找到的請求者標識符1204和所有被找到的實體標識符1204，許可證頒發(fā)者1210將這樣的標識符1204與如在所發(fā)送的SRL308中列出的所有標識符1204比較(步驟1307)。再一次，如果找到匹配，許可證頒發(fā)者1210為請求者發(fā)布帶有在SRL308中為所匹配的標識符1204指定的權限的許可證(步驟1309a)。
注意，由于將多個標識符1204與SRL308的比較，可能的情況是，在SRL308中找到多個匹配的標識符1204。如果這樣，許可證頒發(fā)者1210在SRL308中選擇一個合適的匹配的標識符1204，并向請求者發(fā)布帶有在SRL308中為所選擇的匹配的標識符1204指定的權限的許可證(步驟1309b)。例如，許可證頒發(fā)者可選擇向請求者傳送最多權限的匹配標識符1204(步驟1309b-1)。注意，許可證頒發(fā)者可能能夠確定哪個匹配的標識符1204傳送最多的權限，或者可能必須依賴于在SRL308中的某種類型的優(yōu)先標記。在后一種情況下，在SRL308中的每個匹配的標識符(用戶)1204具有一相應的優(yōu)先級標記1212，且較高標記1212例如表示較大范圍的準予的權限。這樣，如果許可證頒發(fā)者1210在SRL308中找到多個匹配的標識符1204，這樣的許可證頒發(fā)者1210選擇具有最高優(yōu)先級標記1212的匹配標識符1204(步驟1309b-2)。
注意，在參考目錄1206以生成另外的相關于請求者的標識符1204時，許可證頒發(fā)者1210將增加找到匹配的可能性，即使在這樣的情況下，例如，請求者的郵件地址或ID從創(chuàng)建SRL308時起已經(jīng)改變。一般而言，目錄1206提供從一個請求者的標識符1204映射到其它可能的請求者的標識符1204，由此就可使用所有的標識符1204試圖找到一個與在SRL308中的標識符1204的匹配。
對組的許可在本發(fā)明的一個實施例中，所發(fā)送的證書1202，如由請求者所提交的，可代表一組或群或一些其它的個人的集合(在下文中‘組’)，在這里這樣的組在目錄1206中被適當?shù)卮?。這樣的組可包括郵件激活的組諸如一分發(fā)列表或郵件別名，或一安全組諸如可結合網(wǎng)絡操作系統(tǒng)等等定義的。因此，許可證頒發(fā)者1210在接收所發(fā)送的‘組’證書1202時，實際上如前面一樣地進行。注意，然而，因為所發(fā)送的證書1202代表一特定的組，它可以是，明確地說，來自許可證頒發(fā)者1210所發(fā)布的許可證1208是用于在證書1202中識別的組而不是請求者?？商鎿Q地，許可證頒發(fā)者1210可從目錄1206確定請求者是在證書1202中識別的組的部分，且如果是則所發(fā)布的1210是用于請求者的。
在前一種情況下，所發(fā)布的許可證1208可包括按照組的公用密鑰加密的內(nèi)容密鑰，且請求者因而需要獲得相應的組的私有密鑰。因此，請求者可具有帶有這樣的私有密鑰的組成員資格證書，它有可能是按照請求者的公用密鑰加密的且可按照請求者的私有密鑰解密的。
在后一種情況下，要將按照請求者的公用密鑰加密的內(nèi)容密鑰包括在所發(fā)布的許可證1208中，許可證頒發(fā)者1210可附加地從請求者接收帶有這樣的公用密鑰的證書?？商鎿Q地，許可證頒發(fā)者1210可以在文件上具有這樣一個證書(見圖6A和6B的步驟608-612)，且在從目錄1206確定請求者是在所發(fā)送的組證書1202中所識別的組的一部分時，使用在證書中的公用密鑰。
值得注意，在SRL 308中指定權限和按照組發(fā)布許可證1208在企業(yè)或組織環(huán)境中完成數(shù)據(jù)權限管理。例如，文檔或電子郵件可以是受DRM保護的，因此一給定部門的所有成員具有讀文檔或電子郵件的權限。假定用這樣一個部門的組(例如電子郵件別名)存在于組織的目錄1206中，這是最經(jīng)常的情況，文檔或電子郵件的作者將基于組而不是個人準予權限。如可意識到的，這樣的組級權限準予的好處包括對于作者在指定具有權限的個人的類時易于使用。另外，通過按照組指定權限，在新的個人加入組和老的個人離開組的時候所指定的權限不會變成‘失效的’。改為，組的所有當前的成員能夠行使這些權限，只要直到現(xiàn)在這樣的組的成員資格被保持在組織的目錄1206中。
在許可期間插入政策在本發(fā)明的一個實施例中，且如上面結合圖9的ORT900間接提到的，當基于這樣的SRL308發(fā)布許可證1208時，DRM服務器/許可證頒發(fā)者1210能自適應地修改或代替來自所提交的SRL308的權限數(shù)據(jù)。具體地說，在明確地忽略在所提交的SRL308中的權限數(shù)據(jù)時幾種情況會發(fā)生，且當基于這樣的SRL308創(chuàng)建許可證1208時，許可證頒發(fā)者1210改為代替或‘插入(inject)’一可替換的政策。注意，盡管在此所揭示的幾個許可證頒發(fā)者1210將政策插入許可證1208的特定的情況，但是許可證頒發(fā)者1210在不脫離本發(fā)明的精神和范圍的情況下，也可將政策插入在任何其它類型的情況中的許可證頒發(fā)者1208。
在第一種情況中，且現(xiàn)在參考圖14，許可證頒發(fā)者1208保存一個被授予特殊權限的特殊實體(用戶、組等)的列表(圖12)。例如，特殊的實體可包括在組織中某些高級別的個人，某些管理的個人，某些應該能夠再現(xiàn)所有內(nèi)容的個人，和前述的個人的組。這樣的列表1214實際上被包含在組織的目錄1206內(nèi)，作為在目錄中為每個特殊實體列出的辨識信息，或更簡單地通過創(chuàng)建一或多個這樣的特殊實體的組。這樣，這樣的特殊實體能再現(xiàn)內(nèi)容，即使用于它們的SRL308相反將阻止這樣的再現(xiàn)。
在一實體提交SRL308作為對許可證1208的請求的部分時，然后，現(xiàn)在參考圖14，許可證頒發(fā)者1210用目錄1206以合適的方式檢查，以確定所提交的實體是否被鑒定為一特殊實體(步驟1401)，且如果是，則許可證頒發(fā)者1210為這個特殊實體創(chuàng)建帶有不同于在所提交的SRL308中提供的權限數(shù)據(jù)的特殊權限的許可證1208(步驟1403)。注意，特殊權限可能是在不脫離本發(fā)明的精神和范圍的情況下的任何權限。例如，特殊權限可以是來自一特定組的所有特殊實體能夠完全訪問和再現(xiàn)內(nèi)容，一個特定的特殊實體接收增強的權限諸如更高的播放次數(shù)或在許可證1208期滿前更長的時間等。注意，如果特殊權限對于個人或組是特定的，在目錄1206中可在用于這個個人或組的目錄項中指定這樣的權限，這樣的目錄項可具有對一位置的合適的參考，該位置放置特殊的權限，許可證頒發(fā)者1210可基于這個個人或組的標識符1204在數(shù)據(jù)庫找到這個特殊的權限，等等。
在第二種情況中，現(xiàn)在轉(zhuǎn)到圖15，許可證頒發(fā)者1208保存一個對其要限制或拒絕權限的受限制的實體(用戶、組等)的列表1216(圖12)。例如，受限制的實體可包括已經(jīng)離開組織的個人，在組織中不應該正常地具有對于任何內(nèi)容的任何權限的個人，諸如維修和建筑人員，在組織中只具有有限的地位的個人，諸如接線員和臨時職工，以及上述個人的組。象上述‘特殊的’列表1214，受限制的列表1216也可被包含在組織的目錄1206中，作為在目錄中為每個受限制的實體列出的辨識信息，或更簡單地通過創(chuàng)建一或多個這樣的受限制的組。這樣，這樣的受限制的實體被限制再現(xiàn)內(nèi)容，即使用于它們的SRL308相反將允許這樣的再現(xiàn)。
在一實體提交SRL308作為對許可證1208的請求的部分，然后，仍參考圖14，許可證頒發(fā)者1210用目錄1206以合適的方式檢查，以確定所提交的實體是否被鑒定為受限制的實體(步驟1405)，且如果是，則許可證頒發(fā)者1210為受限制的實體創(chuàng)建帶有與在所提交的SRL308中提供的權限不同的受限制的權限的許可證1208(步驟1407)。注意，受限制的權限可以是在不脫離本發(fā)明的精神和范圍的情況下的任何權限。例如，受限制的權限可以是所有受限制的實體不能以任何方式訪問和再現(xiàn)相應的內(nèi)容，所有來自一特定組的受限制的實體只能以短暫的形式再現(xiàn)內(nèi)容，一特定的受限制的實體只能打印一件內(nèi)容的單一拷貝，等等。另外，受限制的權限可以是無論什么權限也不準予受限制的實體。如關于特殊權限一樣，如果受限制的權限是特定于一個個人或組，則可在目錄1206中為這個個人或組在一目錄項指定這樣的權限，這樣的目錄項可具有對于一位置的合適的參考，該位置放置受限制的權限，許可證頒發(fā)者1210可基于這個個人或組的標識符1204在數(shù)據(jù)庫中找到受限制的權限，等等。
在第三種情況中，許可證頒發(fā)者1208可將政策插入許可證1208中以指定最低程度的系統(tǒng)要求，這些要求是在計算設備14(圖11)上要再現(xiàn)相應的內(nèi)容所必需的(步驟1409)。這樣的最低程度的系統(tǒng)要求一般涉及計算設備14的確實性和安全性，盡管在不脫離本發(fā)明的精神和范圍的情況下，這樣的要求可涉及任何其它內(nèi)容。
將關系到許可證頒發(fā)者1210的確實性和安全性的基本的實例是，計算設備14的可信的組件18或其安全部分是否是當前的。如可意識到的，這樣的當前性可通過版本編號、建立日期等等代表，并反映可信的組件18或其部分的使用時間。如也可意識到的，隨著這樣的可信的組件18或其部分的使用時間，可信的組件18或其部分更易受到不法的實體的安全性攻擊。因此，許可證頒發(fā)者1210可決定超過某個使用時間的可信的組件18或其部分應該是不可信的，且可將政策插入由它發(fā)布的許可證1208，要求在允許再現(xiàn)相應的內(nèi)容之前，先更新這樣的不可信的可信的組件18或其部分。
關系到許可證頒發(fā)者1210的確實性和安全性的另一個實例是，要再現(xiàn)內(nèi)容的應用程序事實上應該是可信的。如可意識到的，可以是這個情況，即一個應用程序可以是可信的，以通過不允許以不受保護的形式保存內(nèi)容，在許可證頒發(fā)者1208的限制內(nèi)再現(xiàn)內(nèi)容，而另一個應用程序不能同樣是可信的。因此，許可證頒發(fā)者1210可決定只有某個應用程序能夠被使用，以再現(xiàn)相應的內(nèi)容，并可將政策插入由它發(fā)布的許可證1208中，要求只使用這樣的應用程序再現(xiàn)這樣的內(nèi)容。
當然，其它政策插入情況是大量的。一般而言，可執(zhí)行政策插入以增加附加的權限至SRL308的權限數(shù)據(jù)中，或者從SRL308的權限數(shù)據(jù)中刪除權限，有可能基于請求者(步驟1411)；且同樣將條件添加到這樣的權限數(shù)據(jù)中，或者從這樣的權限數(shù)據(jù)中刪除條件，再一次有可能基于請求者(步驟1413)。
結論完成結合本發(fā)明執(zhí)行的過程所需要的編程是相對直接的且對于相關的編程人員是顯而易見的。因此，沒有將這樣的編程附在這里。于是，可使用任何特定的編程，在不脫離本發(fā)明的的精神和范圍的情況下，以完成本發(fā)明。
應該意識到，在不脫離其發(fā)明的概念的情況下，可對所述的實施例進行修改。值得注意地，盡管按照規(guī)定的領域諸如組織來描述本發(fā)明，但是還可以在為組織的子集或者包含多個組織的規(guī)定領域內(nèi)使用本發(fā)明，所有在不脫離本發(fā)明的精神和范圍的情況下。因此，應該理解，這個發(fā)明不是受限于所揭示的特定實施例，而是旨在覆蓋在如由所附的權利要求書所定義的本發(fā)明精神和范圍內(nèi)的修改方案。
附錄1取樣權利數(shù)據(jù)Sample Rights Data<？xml version＝″1.0″？>
<XrML version＝″1.2″>
<BODY type＝″Rights Template″>
<DESCRIPTOR>
<OBJECT>
<ID type＝″GUID″>c43...</ID>
<NAME>$$411$411name$411desc</NAME>
</OBJECT>
</DESCRIPTOR>
<WORK>
<OBJECT>
<ID/>
</OBJECT>
<RIGHTSGROUP name＝″MAIN RIGHTS″>
<RIGHTSLIST>
<VIEW>
<CONDITIONLIST>
<ACCESS>
<PRINCIPAL>
<OBJECT>
<ID/>
<NAME>test@company.com</NAME>
</OBJECT>
</PRINCIPAL>
</ACCESS>
</CONDITIONLIST>
</VIEW>
<RIGHT name＝″generic″>
<CONDITIONLIST>
<ACCESS>
<PRINCIPAL>
<OBJECT>
<ID/>
<NAME>test@company.com</NAME>
</OBJECT>
</PRINCIPAL>
</ACCESS>
</CONDITIONLIST>
</RIGHT>
</RIGHTSLIST>
</RIGHTSGROUP>
</WORK>
</BODY>
<SIGNATURE>
<ALGORITHM>RSA PKCS#1-V1.5</ALGORITHM>
<DIGEST>
<ALGORITHM>SHA1</ALGORITHM>
<PARAMETER name＝″codingtype″>
<VALUE encoding＝″string″>surface-coding</VALUE>
</PARAMETER>
<VALUE encoding＝″base64″size＝″160″>Mwl...＝</VALUE>
</DIGEST>
<VALUE encoding＝″base64″size＝″1024″>Msi...＝</VALUE>
</SIGNATURE>
</XrML>
附錄2經(jīng)簽名的取樣權利標簽(SRL)308Sample Signed Rights Label(SRL)308<？xml version＝″1.0″？>
<XrML version＝″1.2″>
<BODY type＝″Rights Label″version＝″3.0″>
<ISSUEDTIME>2002-01-01_12:00:00</ISSUEDTIME>
<DESCRIPTOR>
<OBJECT>
<ID/>
<NAME>$$409$...</NAME>
</OBJECT>
</DESCRIPTOR>
<ISSUER>
<OBJECT type＝″DRM-Server″>
<ID type＝″GUID″>{d81 ...}</ID>
<NAME>Test DRM Server</NAME>
<ADDRESS type＝″URL″>http//licensing.dev.com</ADDRESS>
</OBJECT>
<PUBLICKEY>
<ALGORITHM>RSA</ALGORITHM>
<PARAMETER name＝″public-exponent″>
<VALUE encoding＝″integer32″>65537</VALUE>
</PARAMETER>
<PARAMETER name＝″modulus″>
<VALUE encoding＝″base64″ size＝″1024″>NcO...＝</VALUE>
</PARAMETER>
</PUBLICKEY>
<ENABLINGBITS type＝″sealed-key″>
<VALUE encoding＝″base64″ size＝″1024″>tFg...＝</VALUE>
</ENABLINGBITS>
<SECURITYLEVEL name＝″Server-Version″value＝″2.0″/>
<SECURITYLEVEL name＝″Server-SKU″value＝″22222-3333″/>
</ISSUER>
<DISTRIBUTIONPOINT>
<OBJECT type＝″LICENSE ACQUISITION URL″>
<ID type＝″GUID″>{OF4..，}</ID>
<NAME>DRM Server Cluster</NAME>
<ADDRESS type＝″URL″>http//Iocalhost/Licensing</ADDRESS>
</OBJECT>
</DISTRIBUTIONPOINT>
<WORK>
<OBJECT type＝″TEST-FORMAT″>
<ID type＝″MYID″>FDB-1</ID>
</OBJECT>
<METADATA>
<SKU type＝″PIDTYPE″>PID</SKU>
</METADATA>
<PRECONDITIONLIST>
<TIME/>
</PRECONDITIONLIST>
</WORK>
<AUTHDATA name＝″Encrypted Rights data″>PAB...</AUTHDATA>
</BODY>
<SIGNATURE>
<ALGORITHM>RSA PKCS#1-V1.5</ALGORITHM>
<DIGEST>
<ALGORITHM>SHA1</ALGORITHM>
<PARAMETER name＝″codingtype″>
<VALUE encoding＝″string″>surface-coding</VALUE>
</PARAMETER>
<VALUE encoding＝″base64″size＝″160″>Prc...＝</VALUE>
</DIGEST>
<VALUE encoding＝″base64″size＝″1024″>EHd...＝</VALUE>
</SIGNATURE>
</XrML>
權利要求
1.一種方法，用于許可證頒發(fā)者向一個請求者發(fā)布數(shù)字許可證，以允許請求者再現(xiàn)相應的數(shù)字內(nèi)容，許可證頒發(fā)者可以訪問一個包括用于請求者的列表的目錄，列表包括請求者的標識符和請求者是其成員的每個組的標識符，所述方法包括從請求者接收請求，請求包括標識請求者的標識符和與內(nèi)容關聯(lián)的權限數(shù)據(jù)，權限數(shù)據(jù)列出至少一個標識符和與其關聯(lián)的權限；在目錄中找到請求者的標識符；根據(jù)在目錄中找到的請求者標識符，在目錄中找到請求者是其成員的每個組的標識符；將找到的請求者標識符的每一個和每個找到的組標識符與在權限數(shù)據(jù)中的每個標識符比較，以找到一個匹配；以及向請求者發(fā)布帶有與匹配標識符關聯(lián)的權限的許可證。
2.如權利要求1所述的方法包括，從請求者接收一個請求包括，帶有識別請求者的標識符的數(shù)字證書。
3.如權利要求1所述的方法包括，從請求者接收一個請求包括，帶有基于以上的數(shù)字簽名的權限數(shù)據(jù)。
4.如權利要求3所述的方法，還包括，驗證數(shù)字簽名。
5.如權利要求1所述的方法包括對于每個找到的請求者標識符和每個找到的組標識符將這樣的標識符與在權限數(shù)據(jù)中列出的每個標識符比較；以及注意被比較的標識符是否是一個匹配標識符；產(chǎn)生至少兩個匹配標識符；選擇匹配標識符中的一個；以及向請求者發(fā)布帶有與選擇的匹配標識符關聯(lián)的權限的許可證。
6.如權利要求5所述的方法包括，選擇向請求者傳送最大量權限的匹配標識符。
7.如權利要求5所述的方法，其特征在于，在權限數(shù)據(jù)中的每個標識符具有一相應的優(yōu)先級標記，所述方法包括，選擇具有最高優(yōu)先級標記的匹配標識符。
8.一個具有存儲在其上的計算機可執(zhí)行指令的計算機可讀媒體，所述指令用于執(zhí)行一種方法，用于許可證頒發(fā)者向請求者發(fā)布數(shù)字許可證，以允許請求者再現(xiàn)相應的數(shù)字內(nèi)容，許可證頒發(fā)者可以訪問包括用于請求者的列表的目錄，列表包括請求者的標識符和請求者是其成員的每個組的標識符，所述方法包括從請求者接收請求，請求包括標識請求者的標識符和與內(nèi)容關聯(lián)的權限數(shù)據(jù)，權限數(shù)據(jù)列出至少一個標識符和與其關聯(lián)的權限；在目錄中找到請求者的標識符；根據(jù)在目錄中找到的請求者標識符，在目錄中找到請求者是其成員的每個組的標識符；將找到的請求者標識符的每一個和每個找到的組標識符與在權限數(shù)據(jù)中的每個標識符比較，以找到一個匹配；以及向請求者發(fā)布帶有與匹配標識符關聯(lián)的權限的許可證。
9.如權利要求8所述的媒體，其特征在于，所述方法包括，從請求者接收一個請求包括，一個帶有識別請求者的標識符的數(shù)字證書。
10.如權利要求8所述的媒體，其特征在于，所述方法包括，從請求者接收一個請求包括，帶有一個基于以上的數(shù)字簽名的權限數(shù)據(jù)。
11.如權利要求10所述的媒體，其特征在于，所述方法包括，驗證數(shù)字簽名。
12.如權利要求8所述的媒體，所述方法包括對于每個找到的請求者標識符和每個找到的組標識符將這樣的標識符與在權限數(shù)據(jù)中列出的每個標識符比較；以及注意被比較的標識符是否是一個匹配標識符；產(chǎn)生至少兩個匹配標識符；選擇匹配標識符中的一個；以及向請求者發(fā)布帶有與選擇的匹配標識符關聯(lián)的權限的許可證。
13.如權利要求12所述的媒體，其特征在于，所述方法包括，選擇向請求者傳送最大量權限的匹配標識符。
14.如權利要求12所述的媒體，其特征在于，在權限數(shù)據(jù)中的每個標識符具有相應的優(yōu)先級標記，所述方法包括，選擇具有最高優(yōu)先級標記的匹配標識符。
15.一種方法，用于許可證頒發(fā)者向請求者發(fā)布數(shù)字許可證，以允許請求者再現(xiàn)相應的數(shù)字內(nèi)容，請求者是一個組的成員，所述方法包括從請求者接收一個請求，請求包括一標識組的標識符和與內(nèi)容關聯(lián)的權限數(shù)據(jù)，權限數(shù)據(jù)列出至少一個標識符和與其關聯(lián)的權限；將來自請求者的組標識符與在權限數(shù)據(jù)中的每個標識符比較，以找到一個匹配；以及向請求者發(fā)布帶有與匹配的組標識符關聯(lián)的權限的許可證，發(fā)布的許可證包括相應于按照組的公用密鑰加密的內(nèi)容的內(nèi)容密鑰，由此請求者用相應于組的公用密鑰的組的私有密鑰能夠獲得內(nèi)容密鑰。
16.如權利要求15所述的方法包括，從請求者接收一個請求包括，一個帶有識別組的標識符的數(shù)字證書。
17.如權利要求15所述的方法包括，從請求者接收一個請求包括，帶有一基于以上的數(shù)字簽名的權限數(shù)據(jù)。
18.如權利要求17所述的方法包括，驗證數(shù)字簽名。
19.如權利要求15所述的方法，其特征在于，許可證頒發(fā)者可以訪問一個包括用于組的列表的目錄，列表包括組的標識符和組的每個成員的標識符，所述方法還包括從每個請求者接收其標識符；在目錄中基于組的標識符找到用于組的列表；以及驗證在目錄找到的用于組的列表包括請求者的標識符。
20.一個具有存儲在其上的計算機可執(zhí)行指令的計算機可讀媒體，所述指令用于執(zhí)行一種方法，用于許可證頒發(fā)者向請求者發(fā)布數(shù)字許可證，以允許請求者再現(xiàn)相應的數(shù)字內(nèi)容，請求者是一個組的成員，所述方法包括從請求者接收一個請求，請求包括一標識組的標識符和與內(nèi)容關聯(lián)的權限數(shù)據(jù)，權限數(shù)據(jù)列出至少一個標識符和與其關聯(lián)的權限；將來自請求者的組標識符與在權限數(shù)據(jù)中的每個標識符比較，以找到一個匹配；以及向請求者發(fā)布帶有與匹配的組標識符關聯(lián)的權限的許可證，發(fā)布的許可證包括一相應于按照組的公用密鑰加密的內(nèi)容的內(nèi)容密鑰，由此請求者用相應于組的公用密鑰的組的私有密鑰能夠獲得內(nèi)容密鑰。
21.如權利要求20所述的媒體，所述方法包括，從請求者接收一個請求包括，一個帶有識別組的標識符的數(shù)字證書。
22.如權利要求20所述的媒體，其特征在于，所述方法包括，從請求者接收一個請求包括，帶有一個基于以上的數(shù)字簽名的權限數(shù)據(jù)。
23.如權利要求22所述的媒體，其特征在于，所述方法包括，驗證數(shù)字簽名。
24.如權利要求20所述的媒體，其特征在于，許可證頒發(fā)者可以訪問一個包括用于組的列表的目錄，列表包括組的標識符和組的每個成員的標識符，所述方法還包括從請求者接收其標識符；在目錄中基于組的標識符找到用于組的列表；以及驗證在目錄找到的用于組的列表包括請求者的標識符。
25.一種方法，用于許可證頒發(fā)者向請求者發(fā)布數(shù)字許可證，以允許請求者再現(xiàn)相應的數(shù)字內(nèi)容，請求者是一組的成員，許可證頒發(fā)者可以訪問一個包括用于組的列表的目錄，列表包括組的每個成員的標識符，所述方法包括從請求者接收一個請求，所述請求包括標識所述組的標識符，標識請求者的標識符，和關聯(lián)于內(nèi)容的權限數(shù)據(jù)，權限數(shù)據(jù)列出至少一個標識符及其關聯(lián)的權限；將來自請求者的組標識符與在權限數(shù)據(jù)中的每個標識符比較，以找到一個匹配；在目錄中基于組的標識符找到用于組的列表；從找到的列表中驗證在其中包括請求者的標識符；以及向請求者發(fā)布帶有與匹配的組標識符關聯(lián)的權限的許可證，發(fā)布的許可證包括一個相應于按照請求者的公用密鑰加密的內(nèi)容的內(nèi)容密鑰，由此請求者用相應于請求者的公用密鑰的組的私有密鑰能夠獲得內(nèi)容密鑰。
26.如權利要求25所述的方法包括，從請求者接收一個請求包括，一個帶有識別組的標識符的數(shù)字證書。
27.如權利要求25所述的方法包括，從請求者接收一個請求包括，一個帶有識別請求者的標識符的數(shù)字證書。
28.如權利要求27所述的方法，還包括，從數(shù)字證書中獲得請求者的公用密鑰。
29.如權利要求25所述的方法包括，從請求者接收一個請求包括，帶有一個基于以上的數(shù)字簽名的權限數(shù)據(jù)。
30.如權利要求29所述的方法還包括，驗證數(shù)字簽名。
31.如權利要求25所述的方法，還包括，從一文件上的數(shù)字證書獲得請求者的公用密鑰，所述數(shù)字證書包括請求者的標識符。
32.一個具有存儲在其上的計算機可執(zhí)行指令的計算機可讀媒體，所述指令用于執(zhí)行一種方法，用于許可證頒發(fā)者向請求者發(fā)布數(shù)字許可證，以允許請求者再現(xiàn)相應的數(shù)字內(nèi)容，請求者是一個組的成員，許可證頒發(fā)者可以訪問一個包括用于組的列表的目錄，列表包括組的每個成員的標識符，所述方法包括從請求者接收一請求，所述請求包括標識所述組的標識符，一標識請求者的標識符，和關聯(lián)于內(nèi)容的權限數(shù)據(jù)，權限數(shù)據(jù)列出至少一個標識符及其關聯(lián)的權限；將來自請求者的組標識符與在權限數(shù)據(jù)中的每個標識符比較，以找到一個匹配；在目錄中基于組的標識符找到用于組的列表；從找到的列表中驗證在其中包括請求者的標識符；以及向請求者發(fā)布帶有與匹配的組標識符關聯(lián)的權限的許可證，發(fā)布的許可證包括一個相應于按照請求者的公用密鑰加密的內(nèi)容的內(nèi)容密鑰，由此請求者用相應于請求者的公用密鑰的組的私有密鑰能夠獲得內(nèi)容密鑰。
33.如權利要求32所述的媒體，其特征在于，所述方法包括，從請求者接收一個請求包括，一個帶有識別組的標識符的數(shù)字證書。
34.如權利要求32所述的媒體，其特征在于，所述方法包括，從請求者接收一個請求包括，一個帶有識別請求者的標識符的數(shù)字證書。
35.如權利要求34所述的媒體，其特征在于，所述方法還包括，從數(shù)字證書中獲得請求者的公用密鑰。
36.如權利要求32所述的媒體，其特征在于，所述方法包括，從請求者接收一個請求包括，帶有一個基于以上的數(shù)字簽名的權限數(shù)據(jù)。
37.如權利要求36所述的媒體，其特征在于，所述方法還包括，驗證數(shù)字簽名。
38.如權利要求32所述的媒體，其特征在于，所述方法還包括，從一個文件上的數(shù)字證書獲得請求者的公用密鑰，所述數(shù)字證書包括請求者的標識符。
全文摘要
許可證頒發(fā)者從請求者接收一個請求，包括標識請求者的標識符和與數(shù)字內(nèi)容關聯(lián)的權限數(shù)據(jù)，在其中權限數(shù)據(jù)列出至少一個標識符和與其關聯(lián)的權限。之后許可證頒發(fā)者在一目錄中找到請求者的標識符，且在此基礎上，在目錄中找到請求者是其成員的每個組的標識符。將找到的請求者標識符的每一個和每個找到的組標識符與在權限數(shù)據(jù)中的每個標識符比較，以找到一個匹配，以及向請求者發(fā)布帶有與匹配標識符關聯(lián)的權限的許可證以再現(xiàn)內(nèi)容。
文檔編號G09C1/00GK1521980SQ20041000538
公開日2004年8月18日 申請日期2004年2月11日 優(yōu)先權日2003年2月11日
發(fā)明者A·納林, C·文卡特施, F·D·比魯姆, M·A·德米羅, P·D·瓦科斯曼, P·馬里克, R·U·馬拉維亞拉奇切, S·包爾尼, V·科里什納斯瓦米, Y·(E)羅森菲爾德, A 納林, ㄌ厥, 德米羅, 比魯姆, 瓦科斯曼, 羅森菲爾德, 錕, 鍤材傷雇咼, 馬拉維亞拉奇切 申請人:微軟公司