專利名稱：：傳送對受保護(hù)內(nèi)容的策略更新的制作方法傳送對受保護(hù)內(nèi)容的策略更新些旦NT爾數(shù)字權(quán)限管理(DRM)指的是用于諸如通過控制或限制電子設(shè)備上對數(shù)字媒體內(nèi)容的使用來保護(hù)內(nèi)容的技術(shù)。DRM的一個特征是它可將媒體內(nèi)容綁定到給定機(jī)器或設(shè)備。由此，涉及特定一段內(nèi)容并定義了與該段內(nèi)容相關(guān)聯(lián)的權(quán)限和限制的許可證通常被綁定到給定的機(jī)器或設(shè)備。結(jié)果，用戶通常不能取得該段內(nèi)容并將其移至另一機(jī)器來回放該內(nèi)容。某些受DRM保護(hù)的內(nèi)容的另一特征是諸如ASF文件等某些內(nèi)容類型僅允許一組權(quán)限和限制，即"策略"應(yīng)用于整個文件。例如，當(dāng)呈現(xiàn)視頻文件時，或者需要在對整個文件的模擬視頻輸出上啟用宏視覺(Macrovision)，或者完全不需要宏視覺。對于這些特定類型的文件，不能在文件中間或流中間改變與內(nèi)容相關(guān)聯(lián)的策略。概述各實施例允許對給定一段受保護(hù)內(nèi)容傳送并更新諸如DRM策略更新等策略更新。在至少某些實施例中，可擴(kuò)展各種協(xié)議以允許該協(xié)議來表示并承載策略更新。在一個實施例中，利用超文本傳輸協(xié)議，即HTTP來承載策略更新。在另一實施例中，使用實時流傳送協(xié)議，即RTSP來承載策略更新。附圖簡述圖1示出了在一個實施例中可用于本發(fā)明實施例的協(xié)議的示例性注冊過程。圖2示出了在一個實施例中可用于本發(fā)明實施例的協(xié)議的示例性鄰近性檢測過程。圖3是在一個實施例中可用于本發(fā)明實施例的協(xié)議的示例性會話建立過程。圖4示出了在一個實施例中可用于本發(fā)明實施例的協(xié)議的示例性數(shù)據(jù)傳輸過程。圖5示出了在一個實施例中可用于本發(fā)明實施例的流傳送協(xié)議的各方面。圖6示出了根據(jù)一個實施例的與根許可證和葉許可證相關(guān)聯(lián)的各方面。圖7是描述根據(jù)一個實施例的方法中的各步驟的流程圖。圖8示出了根據(jù)一個實施例的根和葉許可證的通信。圖9示出了根據(jù)一個實施例的根和葉許可證的通信。詳細(xì)描述概述各實施例允許對給定一段受保護(hù)內(nèi)容傳送并更新諸如DRM策略更新等策略更新。在至少某些實施例中，可擴(kuò)展各種協(xié)議以允許由協(xié)議來表示和承載策略更新。在一個實施例中，利用超文本傳輸協(xié)議，即HTTP來承載策略更新。在另一實施例中，使用實時流傳送協(xié)議，即RTSP來承載策略更新。在以下討論中，提供了題為"內(nèi)容安全和許可證傳輸協(xié)議"的小節(jié)，該節(jié)描述了其中可采用本發(fā)明技術(shù)的一個特定系統(tǒng)。在此之后，提供了題為"RTSP"的小節(jié)，以向不熟悉RTSP的讀者給出用于理解RTSP空間中的本發(fā)明技術(shù)的至少某些上下文。在本節(jié)之后，提供了題為"用于傳送更新的策略的鏈許可證"的小節(jié)，該節(jié)描述了鏈許可證的概念以及可如何在本發(fā)明的上下文中利用鏈許可證。在該節(jié)之后，提供了題為"使用HTTP來傳送更新的策略"的小節(jié)，該節(jié)描述了如何可在HTTP的上下文中使用鏈許可證來傳送策略更新。在該節(jié)之后，提供了題為"使用RTSP來承載根和葉許可證"的小節(jié)，該節(jié)描述了如何可在RTSP的上下文中使用鏈許可證來傳送策略更新。內(nèi)容安全和許可證傳輸協(xié)議以下提供了為在數(shù)字鏈路上流動的內(nèi)容提供安全和傳輸許可證的示例性協(xié)議的討論。該協(xié)議僅構(gòu)成了可使用的各種發(fā)明技術(shù)的一個示例性協(xié)議。可以理解和明白，可利用其它協(xié)議而不脫離所要求保護(hù)的主題的精神和范圍。在此描述中使用以下密碼表示法&{數(shù)據(jù)}用機(jī)密密鑰K加密的數(shù)據(jù)K[數(shù)據(jù)]用機(jī)密密鑰K簽署的數(shù)據(jù){數(shù)據(jù)}^用設(shè)備的公鑰加密的數(shù)據(jù)[數(shù)據(jù)]m用設(shè)備的私鑰簽署的數(shù)在該特定協(xié)議中，有五個主要過程茲〕欽、_^>新嫁"、鄰近絲^^資/、會話建J和教薪傳翰。在^SM程中，發(fā)送器(即，具有要發(fā)送到另一設(shè)備的內(nèi)容的設(shè)備)可唯一并安全地標(biāo)識一預(yù)期接收器(即，要向其發(fā)送內(nèi)容的設(shè)備)。在該特定協(xié)議中，發(fā)送器維護(hù)具有注冊的接收器的數(shù)據(jù)庫，并且確保不會同時使用多于一較小的預(yù)定數(shù)目的接收器。在注冊過程期間，發(fā)送器還采用了鄰^近絲^^i^:程來確保接收器在網(wǎng)絡(luò)中位于發(fā)送器"附近"，以防止受保護(hù)內(nèi)容的大范圍分發(fā)。^1^:潘^(過程用于確保接收器持續(xù)地在發(fā)送器的"附近"。除非接收器已在過去的一段預(yù)定時間內(nèi)注冊或重新確認(rèn)，否則不向其傳送內(nèi)容。會話建J過程在接收器向發(fā)送器請求內(nèi)容的任何時候使用。發(fā)送器強制設(shè)備必須在完成會話^^J^前注冊并最近被確認(rèn)。一旦建立了會話，所請求內(nèi)容的J^游/^^可用一安全的方式來進(jìn)行。接收器可重復(fù)使用該會話來檢索內(nèi)容的特定部分(尋找)，但是必須建立新的會話來檢索不同的內(nèi)容。現(xiàn)在結(jié)合圖1以及下表來考慮)^，過程，下表描述了在注冊期間在發(fā)送器和接收器之間傳遞的各種消息。消總位描述注冊請求消息版本8位協(xié)議版本證書接收器的XML數(shù)字證書。設(shè)備標(biāo)識128位序列號。注冊響應(yīng)消息版本8位協(xié)議版本{種子}設(shè)備用于導(dǎo)出內(nèi)容加密密鑰和內(nèi)容完整性密鑰的128位種子。序列號128位序列號地址發(fā)送器傳入和傳出的鄰近分組套接字的地址。會話標(biāo)識128位隨機(jī)會話標(biāo)識。鄰近性檢測算法在帶外執(zhí)行鄰近性檢測算法。此處，接收器發(fā)送除其它信息外還包含接收器的數(shù)字證書的注冊請求消息。響應(yīng)于接收該注冊請求消息，發(fā)送器驗證接收器的證書，生成種子和隨機(jī)會話標(biāo)識，在注冊響應(yīng)消息中按上述格式向接收器返回同樣內(nèi)容。接收器然后驗證發(fā)送器的簽名，獲取會話標(biāo)識并執(zhí)行附圖中所示的其它動作。接收器和發(fā)送器然后可經(jīng)歷以下描述的鄰近性檢測過程。對于^^^P裙W，執(zhí)行與上述相同的過程，區(qū)別在于，在_^#:潘^(期間，接收器已在數(shù)據(jù)庫中注冊。對于鄰近絲檢漱，結(jié)合圖2考慮以下。在鄰^近絲^^i5i程期間，接收器向發(fā)送器發(fā)送包含鄰近性檢測初始化消息中指示的會話標(biāo)識的消息。發(fā)送器然后向接收器發(fā)送包含現(xiàn)時值(Nonce)(128位隨機(jī)值)的消息，并測量接收器以使用內(nèi)容加密密鑰加密的現(xiàn)時值來答復(fù)所花的時間。最后，發(fā)送器向接收器發(fā)送指示鄰近性檢測成功與否的消息。接收器可重復(fù)該過程，直到它確認(rèn)鄰近性檢測成功。當(dāng)該特定協(xié)議在基于IP的網(wǎng)絡(luò)上使用時，通過UDP來交換鄰近性檢測消息。接收器經(jīng)由注冊響應(yīng)消息知道發(fā)送器的地址。接收器的地址不需要單獨傳送，因為可通過檢査承載鄰近性檢測初始化消息的UDP分組的傳入IP報頭來確定。下表描述了在鄰近性檢測期間交換的消息:<table>tableseeoriginaldocumentpage8</column></row><table><table>tableseeoriginaldocumentpage9</column></row><table>在此示例中，從接收器向發(fā)送器發(fā)送許可證請求消息，它包含上述信息。作為響應(yīng)，發(fā)送器可發(fā)送包含上述信息的許可證響應(yīng)消息。在該特定示例中，用XMR格式表示許可證，許可證包括內(nèi)容加密密鑰、內(nèi)容完整性密鑰、發(fā)送器CRL的版本、128位權(quán)限標(biāo)識和128位序列號。許可證還包含使用OMAC用內(nèi)容完整性密鑰計算的OMAC。對于^"薪傳薪過程，結(jié)合圖4考慮以下。一旦會話;^J^成，即以控制協(xié)議專用的方式執(zhí)行數(shù)據(jù)傳輸。^"薪傳激請求和響應(yīng)兩者必須為控制協(xié)議和內(nèi)容類型特別定義。這概念性地表示在圖4中。現(xiàn)在提供了可用于本發(fā)明實施例的示例性協(xié)議的簡要概觀，現(xiàn)在考慮RTSP的一些背景信息。RTSP如本領(lǐng)域的技術(shù)人員所理解的，實時流傳送協(xié)議，即RTSP是用于對具有實時特性的數(shù)據(jù)傳送(即流傳送)進(jìn)行控制的應(yīng)用層協(xié)議。RTSP提供允許對諸如音頻和視頻等實時數(shù)據(jù)進(jìn)行受控的、按需的傳送的可擴(kuò)展框架。數(shù)據(jù)源可包括實況數(shù)據(jù)饋送和已存儲的剪輯兩者。該協(xié)議旨在控制多個數(shù)據(jù)傳送會話，提供用于選擇諸如UDP、組播UDP和TCP等傳送信道的手段，并提供用于基于RTP選擇傳送機(jī)制的手段。RTSP建立并控制單個或多個時間同步的連續(xù)媒體流，諸如音頻和視頻。它自己一般不傳送連續(xù)流，盡管連續(xù)媒體流與控制流的交織是可能的。換言之，RTSP用作多媒體服務(wù)器的"網(wǎng)絡(luò)遙控器"。要被控制的流的集合由演示描述來定義。在RTSP中，不存在RTSP連接的概念；相反，服務(wù)器維護(hù)由標(biāo)識符標(biāo)記的會話。RTSP會話決不綁定至傳輸層連接，諸如TCP連接。在RTSP會話期間，RTSP客戶機(jī)可打開或關(guān)閉至服務(wù)器的眾多可靠的傳輸連接以發(fā)出RTSP請求?；蛘撸绫绢I(lǐng)域的技術(shù)人員可以理解的，可使用諸如UDP等無連接傳輸協(xié)議。由RTSP控制的流可使用RTP，但RTSP的操作不依賴于用于承載連續(xù)媒體的傳輸機(jī)制?，F(xiàn)在結(jié)合圖5考慮客戶機(jī)/接收器500與服務(wù)器/發(fā)送器502之間的典型的RTSP請求/響應(yīng)交換。初步地，RTSP請求/響應(yīng)具有為簡潔起見未作描述的報頭。在RTSP中，客戶機(jī)/接收器500—般發(fā)出被稱為描述的請求，它針對從服務(wù)器502檢索由請求URL標(biāo)識的演示或媒體對象的描述。服務(wù)器502用以會話描述協(xié)議(SDP)表示的被請求資源的描述作出響應(yīng)。描述響應(yīng)(SDP)包含其所描述的資源的所有媒體初始化"(曰息。接著，客戶機(jī)500發(fā)送對指定要用于流傳送媒體的傳輸機(jī)制的URI的設(shè)置請求。在圖5的示例中，為音頻和視頻兩者發(fā)送設(shè)置請求?？蛻魴C(jī)500還在設(shè)置請求中指示它將利用的傳輸參數(shù)。設(shè)置請求中的傳輸報頭指定客戶機(jī)可接受用于數(shù)據(jù)傳輸?shù)膫鬏攨?shù)。來自服務(wù)器502的響應(yīng)包含由服務(wù)器所選的傳輸參數(shù)。服務(wù)器還響應(yīng)于該設(shè)置請求生成會話標(biāo)識符。此時，客戶機(jī)可發(fā)出播放請求，它告知服務(wù)器以經(jīng)由設(shè)置中指定的機(jī)制來開始發(fā)送數(shù)據(jù)。響應(yīng)于接收播放請求，服務(wù)器可開始流傳送內(nèi)容，在此示例中，該內(nèi)容為音頻/視頻內(nèi)容。如本領(lǐng)域的技術(shù)人員可以理解的，在此示例中，流傳送的內(nèi)容使用RTP分組封裝并通過UDP發(fā)送。RTSP協(xié)議具有感興趣的其它方法，包括暫停、拆卸、獲取參數(shù)、設(shè)置參數(shù)、重定向和記錄。對關(guān)于RTSP的其它背景，讀者應(yīng)査詢1998年4月的RTSP草案中Schulzrinne,H.，Rao，A.禾卩R.Lanphier的"RealTimeStreamingProtocol(實時流傳送協(xié)議)(RTSP)"，RFC2326，可在http:〃www.ietf.org/rfc/rfc2326.txt獲得。用于傳送更新的策略的鏈許可證在所示并描述的實施例中，在策略更新過程中利用了許可證鏈的概念。在該特定實施例中，采用了裙/f^證和^/f^證的概念。此處，利用根許可證來設(shè)置內(nèi)容密鑰并將其安全地傳送到客戶機(jī)/接收器，使得客戶機(jī)/接收器可使用該內(nèi)容密鑰來解密隨后傳送的策略更新。一旦將初始內(nèi)容密鑰安全地傳送到客戶機(jī)/接收器，就可由服務(wù)器/發(fā)送器使用該最初傳送的內(nèi)容密鑰加密后續(xù)內(nèi)容密鑰并將其發(fā)送給客戶機(jī)/接收器。使用最初傳送的內(nèi)容密鑰，客戶機(jī)可解密相關(guān)聯(lián)的策略更新。為提供關(guān)于可如何實現(xiàn)該特定方案的一個示例，結(jié)合圖6考慮以下。在該特定示例中，圖6的系統(tǒng)被配置成對公鑰密碼操作使用1024位RSA密鑰，而對對稱密碼操作使用128位AES密鑰。當(dāng)然，這僅作為一個示例來提供，并不旨在限制所要求保護(hù)的主題的應(yīng)用。在此示例中，客戶機(jī)/接收器600具有公鑰/私鑰對650，而服務(wù)器/發(fā)送器602具有客戶機(jī)/接收器的公鑰。在此示例中，客戶機(jī)/接收器的公鑰和私鑰中的每一個都是1024位RSA密鑰。使用客戶機(jī)/接收器的公鑰，服務(wù)器/發(fā)送器構(gòu)建一包含用客戶機(jī)/接收器的公鑰加密的初始內(nèi)容密鑰的根許可證。該初始內(nèi)容密鑰是128位AES內(nèi)容密鑰。該根許可證然后被發(fā)送到客戶機(jī)/接收器。在圖6中，這被示為在客戶機(jī)/接收器和服務(wù)器/發(fā)送器之間發(fā)生的第一通信，其中加密的內(nèi)容密鑰被表示為(內(nèi)容密鑰iHm。然而，可以理解，在所示的通信之前可發(fā)生其它通信。從服務(wù)器/發(fā)送器接收到加密的內(nèi)容密鑰之后，客戶機(jī)/接收器現(xiàn)在可使用其私鑰來解密該內(nèi)容密鑰，并且可安全地儲存解密的內(nèi)容密鑰以供將來使用。在以下描述中，該第一內(nèi)容密鑰被稱為衣^#/^#麥勢。此時，考慮發(fā)生了什么事情。服務(wù)器/發(fā)送器已向客戶機(jī)/接收器安全地傳送了現(xiàn)在可用作后續(xù)密碼操作的基礎(chǔ)的密鑰。更具體地，現(xiàn)在考慮要在流傳送期間作出涉及一段特定的受DRM保護(hù)的內(nèi)容的策略更新。在這一情況下，服務(wù)器/發(fā)送器可準(zhǔn)備一包含該更新的策略的葉許可證。該葉許可證包含策略更新以及加密版本的內(nèi)容密鑰2。在此示例中，內(nèi)容密鑰2是使用初始內(nèi)容密鑰來加密的128位AES內(nèi)容密鑰。由此，客戶機(jī)/接收器所經(jīng)歷并導(dǎo)致的、與解密新的以及附加的內(nèi)容密鑰相關(guān)聯(lián)的計算復(fù)雜度和開銷相對于與1024位RSA密鑰操作相關(guān)聯(lián)的計算復(fù)雜度開銷被減小，因為現(xiàn)在客戶機(jī)/接收器只需使用128位的AES內(nèi)容密鑰(即，初始內(nèi)容密鑰)來解密。對于其中利用XMR來表示許可證和許可證更新的實現(xiàn)示例，考慮以下。使用許可證鏈的一個目的是減少在許可證更新期間執(zhí)行的非對稱密鑰操作的數(shù)目。在此實現(xiàn)示例中，沒有強調(diào)將根許可證用作傳達(dá)權(quán)限和限制的機(jī)制。結(jié)果，根許可證是非常簡單的，并且沒有傳達(dá)任何權(quán)限或限制。然而，可以理解，在至少某些實現(xiàn)中，根許可證可隨其承載權(quán)限和限制。在此示例中，葉許可證經(jīng)由上行鏈接KID對象被鏈接到根許可證。以下小節(jié)著重于根據(jù)一個實施例在這些許可證中存在的對象。對于根許可證，以下描述了用于回放的根許可證上存在的一組XMR對象。XMR報頭結(jié)構(gòu)XMR容器對象I+--全局策略容器對象III+--最小環(huán)境對象III+--權(quán)限設(shè)置對象I+--回放策略容器對象III+--輸出保護(hù)對象I+--密鑰資料容器對象III+--內(nèi)容密鑰對象I+--乂1^11簽名對象回放策略容器對象必須存在，以允許進(jìn)行回放。另一方面，用于復(fù)制動作的根許可證應(yīng)當(dāng)包含復(fù)制權(quán)限容器對象而非回放策略容器。以下是存在于用于復(fù)制的根許可證上的一組XMR對象。XMR報頭結(jié)構(gòu)XMR容器對象I+__全局策略容器對象III+—最小環(huán)境對象III+--權(quán)限設(shè)置對象I+--回放策略容器對象III+—輸出保護(hù)對象I+--復(fù)制權(quán)限容器對象I+--密鑰資料容器對象III+--內(nèi)容密鑰對象I+--XMR簽名對象在此實施例中，復(fù)制權(quán)限容器對象必須存在，以指示復(fù)制是被允許的。注意，回放策略容器對象仍存在，因為回放的權(quán)限必須總是被授予。對于此具體實施例中的葉許可證，考慮以下。葉許可證可包含可經(jīng)由XMR來表達(dá)的任何類型的權(quán)限或限制。葉許可證與鏈和非鏈許可證之間的一個主要區(qū)別在于使用對稱密鑰來加密內(nèi)容密鑰，且其經(jīng)由上行鏈接KID對象向上鏈接到其它許可證o以下是用于回放的葉許可證的一個示例XMR報頭結(jié)構(gòu)XMR容器對象I+--全局策略容器對象III+--最小環(huán)境對象I+—回放策略容器對象III+--輸出保護(hù)對象III+—下采樣輸出列表對象III+--顯示模擬視頻輸出保護(hù)對象I+--密鑰資料容器對象III+--內(nèi)容密鑰對象III+--上行鏈接1^0對象I+--乂1^1簽名對象內(nèi)容密鑰對象必須將密鑰加密密碼類型設(shè)為0x0002(鏈許可證)，并將對稱密碼類型設(shè)為0x0001(AESCTR)。上行鏈接KID對象必須將上行鏈接KID字段設(shè)為根許可證的KID。以下是此具體實施例中用于復(fù)制的葉許可證的一個示例XMR報頭結(jié)構(gòu)XMR容器對象I+--全局策略容器對象III最小環(huán)境對象I—-回放策略容器對象III+--輸出保護(hù)對象I+復(fù)制權(quán)限容器對象III+--復(fù)制計數(shù)限制對象III+_-復(fù)制保護(hù)級別限制對象I+--密鑰資料容器對象III+--內(nèi)容密鑰對象III+—上行鏈接KID對象I+--乂1^簽名對象在此實施例中，復(fù)制權(quán)限容器對象必須存在，以指示復(fù)制是被允許的。如果對允許的復(fù)制次數(shù)有限制，則復(fù)制計數(shù)限制對象存在。如果對用作復(fù)制的目的地的系統(tǒng)有限制，則復(fù)制保護(hù)級別限制對象存在。注意，回放策略容器對象仍存在，因為回放的權(quán)限必須總是被授予。圖7是描述根據(jù)一個實施例的方法中的各步驟的流程圖。該方法可結(jié)合任何適當(dāng)?shù)挠布④浖?、固件或其組合來執(zhí)行。在一個實施例中，該方法可結(jié)合諸如以上示出并描述的那些系統(tǒng)來實現(xiàn)。另外，在以下討論中，所執(zhí)行的動作中的某一些被描述為由服務(wù)器/發(fā)送器來執(zhí)行，而其它動作被描述為由客戶機(jī)/接收器來執(zhí)行。服務(wù)器/發(fā)送器和客戶機(jī)/接收器的示例在上文中提供。步驟700使用客戶機(jī)/接收器的公鑰來加密初始內(nèi)容密鑰?？衫萌魏芜m當(dāng)?shù)膬?nèi)容密鑰，以上僅給出了其一個示例。步驟702將包含加密的初始內(nèi)容密鑰的根許可證發(fā)送給客戶機(jī)/接收器?？衫萌魏芜m當(dāng)?shù)姆椒▉韺崿F(xiàn)此步驟。在以下討論中，提供了利用兩種不同協(xié)議的兩個具體示例?？梢岳斫夂兔靼?，這些僅構(gòu)成示例，且并不旨在將所要求保護(hù)的主題的應(yīng)用僅限于所描述的特定協(xié)議。步驟704接收服務(wù)器/發(fā)送器發(fā)送的根許可證，且步驟706解密該加密的初始內(nèi)容密鑰。在此示例中，該步驟通過使用客戶機(jī)/接收器的私鑰解密該加密的初始內(nèi)容密鑰來執(zhí)行。步驟708準(zhǔn)備葉許可證，并用初始內(nèi)容密鑰來加密新內(nèi)容密鑰。步驟710將葉許可證發(fā)送給客戶機(jī)/接收器?？梢曰叵?，葉許可證可以且通常的確包含用于受DRM保護(hù)的內(nèi)容的策略和策略更新。應(yīng)當(dāng)理解和明白，步驟708和710可以對給定的一段受DRM保護(hù)的內(nèi)容執(zhí)行多次。g卩，當(dāng)策略對于特定的一段受DRM保護(hù)的內(nèi)容改變時，可準(zhǔn)備相應(yīng)的葉許可證并將其發(fā)送給客戶機(jī)/接收器。步驟712接收葉許可證，且步驟714通過使用先前接收到的初始內(nèi)容密鑰來解密新內(nèi)容密鑰。步驟716然后使用解密的新內(nèi)容密鑰來解密內(nèi)容，并更新葉許可證中包含的策略。可以理解和明白，步驟712、714和716可對客戶機(jī)/接收器接收到的每一新的葉許可證執(zhí)行。使用HTTP來傳送更新的策略討論了根和葉許可證的概念以及其各自可如何在上述上下文中采用之后，現(xiàn)在考慮可如何使用HTTP來傳送根和葉許可證。當(dāng)利用HTTP來承載受DRM保護(hù)的內(nèi)容時，客戶機(jī)向服務(wù)器/發(fā)送器發(fā)出兩個請求。首先，客戶機(jī)發(fā)出檢索根許可證的提出(POST)請求。其次，客戶機(jī)發(fā)出檢索受DRM保護(hù)的內(nèi)容的獲取(GET)請求。在此示例中客戶機(jī)發(fā)出請求，因為在HTTP中，服務(wù)器不能啟動與客戶機(jī)的通信。具體地，結(jié)合以下討論考慮圖8。當(dāng)客戶機(jī)希望接收根許可證時，它向服務(wù)器發(fā)出提出請求。提出請求如上所述包含許可證請求消息。響應(yīng)于接收到此通信，服務(wù)器用包含根許可證的許可證響應(yīng)消息來響應(yīng)，在至少一個實施例中，該根許可證用XMR來表達(dá)。接收到根許可證并相應(yīng)地處理它之后，客戶機(jī)向服務(wù)器發(fā)出要求受DRM保護(hù)的內(nèi)容的獲取請求。響應(yīng)于獲取請求，服務(wù)器用與一個或多個許可證響應(yīng)消息交錯的所請求內(nèi)容的各段來回復(fù)。許可證響應(yīng)消息各自包含涉及該受DRM保護(hù)的內(nèi)容的一特定部分的葉許可證?？墒褂萌魏芜m當(dāng)?shù)臋C(jī)制或交錯技術(shù)來形成服務(wù)器的回復(fù)。僅作為一個實現(xiàn)示例，在一個特定上下文中，考慮以下。在僅一個示例中，使用四字節(jié)的成幀報頭來封裝數(shù)據(jù)和控制塊。成幀報頭包含一字節(jié)的ASCII美元符號(0x24)，之后是一字節(jié)的塊類型標(biāo)識符，之后是兩字節(jié)的封裝數(shù)據(jù)的長度，以網(wǎng)絡(luò)字節(jié)順序來表示。<table>tableseeoriginaldocumentpage16</column></row><table>控制塊使用ASCII'c'字符(0x63)作為其類型標(biāo)識符。該塊包含消息，通常是許可證響應(yīng)消息。數(shù)據(jù)塊使用ASCII'd'字符(0x63)作為其類型標(biāo)識符。該塊包含數(shù)據(jù)段描述符，后面直接跟有媒體數(shù)據(jù)。數(shù)據(jù)段描述符可與加密的或明文的內(nèi)容相關(guān)聯(lián)。描述符中的已加密標(biāo)志傳達(dá)此信息。數(shù)據(jù)段描述符與所發(fā)送的文件的一部分相關(guān)聯(lián)，對該部分，如果其被加密，則向其應(yīng)用單個策略和內(nèi)容加密密鑰。換言之，內(nèi)容加密密鑰和策略不能在段內(nèi)改變。根據(jù)一個實施例，一典型的具有鏈接加密的HTTP響應(yīng)由以下塊組成-1.承載具有鏈許可證的許可證響應(yīng)消息的控制塊[Sc]。2.—個或多個數(shù)據(jù)塊[Sd]。在文件傳輸期間存在密鑰或策略改變的情況下，則增加以下步驟3.承載具有新的鏈許可證的許可證響應(yīng)消息的新控制塊[Sc]。4.一個或多個數(shù)據(jù)塊[Sd]。注意，在多次密鑰或策略改變的情況下，步驟3和4可發(fā)生多次。使用RTSP來承載根和葉許可證討論了根和葉許可證的概念以及其各自如何可使用HTTP來傳送之后，現(xiàn)在考慮如何可使用RTSP來傳送根和葉許可證。RTSP和HTTP之間的區(qū)別之一是RTSP比HTTP要復(fù)雜得多。具體地，RTSP具有對服務(wù)器發(fā)起的請求的規(guī)定，它允許服務(wù)器在任何時刻向客戶機(jī)發(fā)送命令。根據(jù)此實施例，結(jié)合圖9考慮以下。當(dāng)客戶機(jī)/接收器希望播放受DRM保護(hù)的內(nèi)容時，客戶機(jī)發(fā)送包含許可證請求消息的描述(DESCRIBE)請求。響應(yīng)于接收到該消息，服務(wù)器用嵌入了許可證響應(yīng)消息的會話描述協(xié)議(SESSIONDESCRIPTIONPROTOCOL)(SDP)來響應(yīng)。許可證響應(yīng)消息包含根證書，在此具體實施例中，根證書用XMR來表達(dá)?，F(xiàn)在，當(dāng)客戶機(jī)希望接收受DRM保護(hù)的內(nèi)容時，客戶機(jī)向服務(wù)器發(fā)送啟動流的PLAY(播放)請求。在任何適當(dāng)?shù)臅r刻，服務(wù)器可向客戶機(jī)發(fā)送承載包含葉許可證的許可證響應(yīng)消息的通知(ANNOUNCE)請求。作為一個實現(xiàn)示例，考慮以下。首先考慮以下根據(jù)一個實施例的描述請求摘錄，它結(jié)合了許可證請求消息。DESCRIBErtsp:〃eduardo01/file.麗vRTSP/l.OAccept:application/sdpCSeq:1Supported:com.microsoft.wmdrm-nd,com.microsoft.wm.eosmsg,method.announceRequire:com.microsoft.wmdrm-ndContent-Type:application/vnd.ms-麗d:rm-license-requestContent-:Length:1078/f^"ff請求教富在該示例中使用"R叫uire(要求)com.microsoft.wmdrm-nd"以指示接收器期望服務(wù)器為特定類型的發(fā)送器。在該示例中使用"Content-Type(內(nèi)容類型)application/vnd.ms-wmdrm-license-request"以指示該描述的正文包含許可證請求消息。除非存在錯誤，否則發(fā)送器應(yīng)以SDP描述來回復(fù)，該描述包括在下一節(jié)中描述的許可證響應(yīng)消息。接收到在正文中包含許可證請求消息的描述請求之后，服務(wù)器可返回許可證響應(yīng)消息。在此示例中，服務(wù)器返回不僅包含前述各個參數(shù)而且包含許可證響應(yīng)消息的SDP描述。在此實施例中，如前所述，許可證響應(yīng)消息將承載指定將對內(nèi)容應(yīng)用哪些策略的XMR許可證。僅作為一個實現(xiàn)示例，考慮以下根據(jù)一個實施例的SDP摘錄，它結(jié)合了許可證響應(yīng)消息。RTSP/1.0200OKLast-Modified:Thu,19Dec200215:36:18GMTContent-:Length:1891Content-Typeapplication/sdpCSeq:1Supported:com.microsoft.wmdrm畫nd,com.microsoft.wm.eosmsg,method.announceSDP箱述所返回的許可證對應(yīng)于將在會話期間使用的根許可證。該特定葉許可證在稍后的時刻經(jīng)由以下描述的通知請求來返回。根據(jù)一個實施例，由發(fā)送器返回的SDP包括根據(jù)RFC-2397中的規(guī)范(http:〃www.ietf.org/rfc/rfc2397.txt)被編碼在數(shù)據(jù)URL中的許可證響應(yīng)消息。在一個示例中，包含在數(shù)據(jù)URL中的數(shù)據(jù)必須是Base64編碼的，且MIME類型必須被設(shè)置為"application/vnd.ms-wmdrm-license-response"。作為句法的示例，考慮以下data:application/vnd.ms-wmdrm-license-response;base64,AggAAAAAAAABOFhNUgAAAAAB+TTbzXCRwls+/jfQQYOwADAAEAAAEgAAMAAgAAADwAAQADAAAAEAAEgBkAGQAZABkAGQAAwAJAAAApgABAAoAAACeajiAiUBMGrAGUA0IqMGBggABAAEAgC7VlQF54EzdtXlWx/AAEACwAAABwAAQAQZZaX5nGEUAV8w6p6BQr++Q==在該示例中，根據(jù)SDP密鑰管理擴(kuò)展規(guī)范，數(shù)據(jù)URL必須使用"a-key-mgmt"屬性被插入到SDP會話層，該規(guī)范迄今為止仍是進(jìn)展中的工作。句法如下a=key-mgmt:wmdrm-ndURL參數(shù)為上述數(shù)據(jù)URL。現(xiàn)在考慮使用通知請求在流的中間傳送更新的策略。具體地，根據(jù)一個實施例，以下通知請求摘錄示出了如何可傳送葉許可證。ANNOUNCErtsp:〃eduardo01/file.麗vRTSP/l.OCSeq:27Session:8322364901836665746Supported:com.microsoft.wmdrm-nd,com.microsoftwm.eosmsg,method.announceRequire:method.announceEvent-Type:4000wmdrm-nd-messageContent-Type:application/vnd.ms-wmdrm-license-responseContent-Liength:924許可證響應(yīng)消息在此示例中，必須使用"Content-Type(內(nèi)容類型)application/vnd.ms-wmdrm-license-response"J艮頭來f旨示i青求的正文包含i午可i正響應(yīng)消息。在此示例中，必須使用"Event-Type(事件類型)4000wmdrm-nd-message"來指示這是承載WMDRM-ND消息的事件。接收器應(yīng)當(dāng)處理許可證響應(yīng)消息，以確保權(quán)限標(biāo)識匹配許可證請求中的權(quán)限標(biāo)識。除非存在錯誤，否則接收器必須向發(fā)送器返回200OK響應(yīng)，諸如以下所示的。RTSP/1.0200OKCSeq:27Session:8322364901836665746Supported:com.microsoft.麗drm-nd,com.microsoft.wm.eosmsg,method.a皿oimce注意，由于描述請求中返回的許可證對應(yīng)于根證書。發(fā)送器在啟動數(shù)據(jù)傳送之前必須傳送允許接收器解密該內(nèi)容的葉許可證。這意味著緊接在接收器發(fā)送第一個PLAY請求之后，發(fā)送器要負(fù)責(zé)在啟動數(shù)據(jù)流之前在通知請求中發(fā)送葉許可證。對于發(fā)送器傳送通知消息和需要新許可證來解密內(nèi)容的時刻之間沒有嚴(yán)格的關(guān)系。這意味著發(fā)送器可在其開始傳送包含相關(guān)聯(lián)的受保護(hù)內(nèi)容的分組之前或甚至在此之后傳送通知?？捎糜诔休d受保護(hù)內(nèi)容的一種方法是如本領(lǐng)域的技術(shù)人員所理解的通過使用RTP分組。結(jié)論上述各實施例允許對給定的一段受保護(hù)內(nèi)容傳送并更新諸如DRM策略更新等策略更新。在至少某些實施例中，可擴(kuò)展各種協(xié)議以允許由該協(xié)議來表示和承載策略更新。盡管用結(jié)構(gòu)特征和/或方法步驟專用的語言描述了本發(fā)明，但可以理解，所附權(quán)利要求書中定義的本發(fā)明不必限于所述的特定特征或步驟。相反，這些特定特征和步驟是作為實現(xiàn)所要求保護(hù)的本發(fā)明的優(yōu)選形式而公開的。權(quán)利要求1.一種計算機(jī)實現(xiàn)的方法，包括構(gòu)建包含已加密初始內(nèi)容密鑰的根許可證，所述已加密初始密鑰是使用預(yù)期接收器的公鑰來加密的，所述根許可證涉及要流傳送到所述預(yù)期接收器的內(nèi)容；將所述根許可證發(fā)送到所述預(yù)期接收器；準(zhǔn)備鏈接到所述根許可證的一個或多個葉許可證，所述一個或多個葉許可證涉及與所述流傳送內(nèi)容相關(guān)聯(lián)的經(jīng)更新的策略，其中所述一個或多個葉許可證各自包含使用所述初始內(nèi)容密鑰來加密的不同內(nèi)容密鑰，其中所述不同內(nèi)容密鑰可由所述接收器用于解密受保護(hù)內(nèi)容；以及將所述一個或多個葉許可證發(fā)送到所述預(yù)期接收器。2.如權(quán)利要求l所述的方法，其特征在于，所述初始內(nèi)容密鑰具有比所述公鑰少的位。3.如權(quán)利要求2所述的方法，其特征在于，所述初始內(nèi)容密鑰包括128位AES密鑰。4.如權(quán)利要求l所述的方法，其特征在于，所述不同內(nèi)容密鑰具有比所述公鑰少的位。5.如權(quán)利要求4所述的方法，其特征在于，所述不同內(nèi)容密鑰包括128位AES密鑰。6.如權(quán)利要求1所述的方法，其特征在于，所述發(fā)送根許可證和一個或多個葉許可證的動作是使用HTTP來執(zhí)行的。7.如權(quán)利要求l所述的方法，其特征在于，所述發(fā)送根許可證和--個或多個葉許可證的動作是使用HTTP來執(zhí)行的，并且其中，所述發(fā)送一個或多個葉許可證的動作包括將受保護(hù)內(nèi)容與包括所述一個或多個葉許可證的數(shù)據(jù)交錯。8.如權(quán)利要求l所述的方法，其特征在于，所述發(fā)送根許可證和一個或多個葉許可證的動作是使用RTSP來執(zhí)行的。9.一種計算機(jī)實現(xiàn)的方法，包括-接收請求要流傳送到接收器的受保護(hù)內(nèi)容的根許可證的HTTP提出請求；響應(yīng)于所述接收，向所述接收器發(fā)送根許可證；接收請求受保護(hù)內(nèi)容的HTTP獲取請求；以及響應(yīng)于所述接收HTTP獲取請求，發(fā)送與包括鏈接到所述根許可證的一個或多個葉許可證的數(shù)據(jù)交錯的所請求的受保護(hù)內(nèi)容的各段。10.如權(quán)利要求9所述的方法，其特征在于，所述HTTP提出請求包含許可證請求消息。11.如權(quán)利要求9所述的方法，其特征在于，所述發(fā)送根許可證的動作是通過向所述接收器發(fā)送許可證響應(yīng)消息來執(zhí)行的。12.如權(quán)利要求9所述的方法，其特征在于，所述包括一個或多個葉許可證的數(shù)據(jù)分別包括一個或多個許可證響應(yīng)消息。13.—種計算機(jī)實現(xiàn)的方法，包括接收請求要流傳送到接收器的受保護(hù)內(nèi)容的根許可證的RTSP描述請求；向接收器發(fā)送根許可證；以及發(fā)送鏈接到所述根許可證的一個或多個葉許可證，其中所述發(fā)送一個或多個葉許可證是在內(nèi)容流傳送期間執(zhí)行的。14.如權(quán)利要求13所述的方法，其特征在于，所述描述請求包含許可證請求消息。15.如權(quán)利要求13所述的方法，其特征在于，所述發(fā)送根許可證的動作包括發(fā)送嵌入了包含根許可證的許可證響應(yīng)消息的RTSP會話描述協(xié)議(SDP)。16.如權(quán)利要求13所述的方法，其特征在于，所述發(fā)送一個或多個葉許可證的動作分別是使用一個或多個RTSP通知請求來執(zhí)行的。17.如權(quán)利要求13所述的方法，其特征在于，所述發(fā)送一個或多個葉許可證的動作分別是使用一個或多個RTSP通知請求來執(zhí)行的，并且其中，所述RTSP通知請求各自包含許可證響應(yīng)消息。18.如權(quán)利要求13所述的方法，其特征在于所述描述請求包含許可證請求消息；以及所述發(fā)送根許可證的動作包括發(fā)送嵌入了包含所述根許可證的許可證響應(yīng)消息的RTSP會話描述協(xié)議(SDP)。19.如權(quán)利要求13所述的方法，其特征在于所述發(fā)送根許可證的動作包括發(fā)送嵌入了包含所述根許可證的許可證響應(yīng)消息的RTSP會話描述協(xié)議(SDP》以及所述發(fā)送一個或多個葉許可證的動作分別是使用一個或多個RTSP通知請求來執(zhí)行的。20.如權(quán)利要求13所述的方法，其特征在于所述描述請求包含許可證請求消息；所述發(fā)送根許可證的動作包括發(fā)送嵌入了包含所述根許可證的許可證響應(yīng)消息的RTSP會話描述協(xié)議(SDP);以及所述發(fā)送一個或多個葉許可證的動作分別是使用一個或多個RTSP通知請求來執(zhí)行的。全文摘要各實施例允許對給定的一段受保護(hù)內(nèi)容傳送并更新諸如DRM策略更新等策略更新。在至少某些實施例中，可擴(kuò)展各種協(xié)議來允許由該協(xié)議表示和承載策略更新。在一個實施例中，利用超文本傳輸協(xié)議，即HTTP來承載策略更新。在另一實施例中，使用實時流傳送協(xié)議，即RTSP來承載策略更新。文檔編號H04L9/00GK101218778SQ200680025291公開日2008年7月9日申請日期2006年7月11日優(yōu)先權(quán)日2005年7月12日發(fā)明者A·E·克萊門茨,E·P·奧利夫拉,J·M·阿爾科夫申請人:微軟公司