專利名稱：受保護的媒體路徑與拒絕響應使能器的制作方法
技術領域：
本發(fā)明涉及用于建立通過公共基本庫以受信任方式將內(nèi)容從各個源的任一個傳送到各個信宿(sink)的任一個的受保護媒體路徑的一種體系結構和方法。更特別地，本發(fā)明涉及這樣的一種體系結構和方法，通過它僅在路徑被建成為可靠并滿足對應于內(nèi)容的策略之后才傳遞內(nèi)容。
背景技術：
眾所周知，并參照圖1，極需要與諸如數(shù)字音頻、數(shù)字視頻、數(shù)字文本、數(shù)字數(shù)據(jù)、數(shù)字多媒體等的數(shù)字內(nèi)容12相關的權限管理(RM)和實施系統(tǒng)，其中這樣的數(shù)字內(nèi)容12要發(fā)布給用戶。在由用戶接收之后，用戶在諸如個人計算機14上的媒體播放機、便攜式回放裝置等的適當呈現(xiàn)裝置的幫助下呈現(xiàn)或‘播放’數(shù)字內(nèi)容。
通常，發(fā)布這種數(shù)字內(nèi)容12的內(nèi)容所有者想要限制用戶可對這種經(jīng)發(fā)布數(shù)字內(nèi)容12進行的操作。例如，內(nèi)容所有者可能想要限制用戶復制這種內(nèi)容12或將它再發(fā)布給第二個用戶，或者可能想要使發(fā)布數(shù)字內(nèi)容12僅能播放有限次、總共僅能播放某些時間、僅能在某類機器上播放、僅能在某類媒體播放機上播放、僅由某類用戶播放等。
然而，在已進行發(fā)布之后，內(nèi)容所有者對數(shù)字內(nèi)容12只有非常少(若有的話)控制。RM系統(tǒng)10允許任意形式的數(shù)字內(nèi)容12的經(jīng)控制呈現(xiàn)或播放，其中這樣的控制是靈活的，并可由這種數(shù)字內(nèi)容的內(nèi)容所有者定義的。通常，內(nèi)容12以包13的形式通過任何適當發(fā)布通道發(fā)布給用戶。所發(fā)布的數(shù)字內(nèi)容包13可包括用對稱加密/解密密鑰(KD)(即KD(內(nèi)容))加密的數(shù)字內(nèi)容12、以及標識該內(nèi)容的其它信息、如何獲取這種內(nèi)容的許可證等。
基于信任的RM系統(tǒng)10使數(shù)字內(nèi)容12的所有者能指定在允許呈現(xiàn)這種數(shù)字內(nèi)容12之前必須滿足的規(guī)則。這種規(guī)則可包括前述要求和/或其它，并可包含于用戶/用戶的計算裝置14(此后這樣的術語是可互相交換的，除非環(huán)境以其它方式要求)必須從內(nèi)容所有者或其代理獲取的數(shù)字許可證16內(nèi)，或者這種規(guī)則可能已附于內(nèi)容12。例如這種許可證16可包括用于解密數(shù)字內(nèi)容12的解密密鑰(KD)，該數(shù)字內(nèi)容12可能是根據(jù)可被用戶的計算裝置或其它回放裝置解密的另一密鑰加密的。
對一段數(shù)字內(nèi)容12的內(nèi)容所有者除非能相信用戶將遵守她在證書16或其它地方中所指定的規(guī)則，將選擇不把內(nèi)容發(fā)布給用戶。然后，最好向用戶的計算裝置14或其它回放裝置提供除遵守規(guī)則之外都不呈現(xiàn)數(shù)字內(nèi)容12的受信任組件或機制18。
受信任組件18通常具有查看各規(guī)則，并基于被查看規(guī)則確定請求用戶是否有權利以所尋求的方式呈現(xiàn)所請求的數(shù)字內(nèi)容12等的評價器20。應理解，評價器20在DRM系統(tǒng)10中受到信任以根據(jù)規(guī)則實現(xiàn)數(shù)字內(nèi)容12所有者的想法，且用戶應不能出于任何目的(惡意的或以其它方式的)簡單地更改這種受信任組件18和/或評價器20。
應理解，用于呈現(xiàn)內(nèi)容12的規(guī)則可指定用戶是否有權利基于若干因素的任一個來呈現(xiàn)，這些因素包括用戶是誰、用戶位于何處、用戶在使用的計算裝置14或其它回放裝置的類型、調(diào)用RM系統(tǒng)10的呈現(xiàn)應用程序、日期、時間等。此外，規(guī)則可將呈現(xiàn)限制為預定數(shù)量的播放次數(shù)、或預定播放時間等。
規(guī)則可根據(jù)任意適當語言和語法來指定。例如，語言可簡單地指定必須滿足的屬性和值(例如必須晚于X的日期等)，或可根據(jù)特定腳本(例如IF日期＞X，THEN DO……)要求各功能的性能。
在評價器20確定用戶滿足規(guī)則之后，可呈現(xiàn)數(shù)字內(nèi)容12。特別地，為了呈現(xiàn)內(nèi)容12，解密密鑰(KD)從預定源獲取并應用于來自內(nèi)容包13的(KD(內(nèi)容))以得到真實內(nèi)容12，然后真正呈現(xiàn)真實內(nèi)容12。
在RM系統(tǒng)10中，通過加密內(nèi)容12并使一規(guī)則集與該內(nèi)容12相關聯(lián)，內(nèi)容12被打包由用戶使用，從而內(nèi)容12可僅根據(jù)規(guī)則呈現(xiàn)。因為內(nèi)容12可僅根據(jù)規(guī)則呈現(xiàn)，則可自由發(fā)布內(nèi)容12。然而，可以理解，各段內(nèi)容12可根據(jù)多個RM系統(tǒng)10得到保護，每個系統(tǒng)都不必與每一個其它RM系統(tǒng)10兼容。
因此，需要一種定義用于將內(nèi)容12從多個系統(tǒng)10的任一個傳送到多個目標的任一個的受保護媒體路徑的體系結構和方法。特別地，存在對與這種體系結構相關的定義如何將路徑建成可靠并滿足對應于內(nèi)容12的策略的方法的需要。

發(fā)明內(nèi)容
前述需要至少部分地由本發(fā)明來滿足，其中計算裝置已在其上例示用于將內(nèi)容從至少一個源傳送到至少一個信宿的受保護媒體路徑。在該受保護媒體路徑中，媒體基本庫提供計算裝置中的一受保護環(huán)境，并包括實現(xiàn)對來自任一特定源的內(nèi)容的處理并將已處理內(nèi)容傳送到任一特定信宿的核心組件的一公共基礎結構，還包括代表每個源實施策略的策略引擎。該策略對應于來自源的內(nèi)容，并包括用于訪問和呈現(xiàn)內(nèi)容的規(guī)則和要求，而媒體基本庫使內(nèi)容能以受保護方式通過計算裝置流動，并允許受保護內(nèi)容在計算裝置中的任意處理。
與內(nèi)容的每個源相關聯(lián)并相對應的源可信權限(SOTA)擔當將該源連接到媒體基本庫的安全加鎖箱，代表受保護媒體路徑中的該源，如果必要解密來自該源的內(nèi)容，并且如果必要將與內(nèi)容相關聯(lián)的策略從原始格式翻譯成遵從策略引擎的格式。與內(nèi)容的每個信宿相關聯(lián)并相對應的信宿可信權限(SITA)擔當將該信宿連接到媒體基本庫的安全加鎖箱，代表受保護媒體路徑中的該信宿，如果必要加密傳送到該信宿的內(nèi)容，并且如果必要將與內(nèi)容相關聯(lián)的策略從策略引擎的格式翻譯成遵從信宿的格式。因而信宿接收內(nèi)容及相應策略，如果必要解密所接收的內(nèi)容，并基于所接收的策略予以呈現(xiàn)。
計算裝置上的應用程序在計算裝置上用內(nèi)容、源和信宿的定義來調(diào)用媒體基本庫而媒體基本庫基于所定義的內(nèi)容、源和信宿建立受保護的媒體路徑以實現(xiàn)這種傳送。代表源的SOTA建立對于受保護媒體路徑的信任，并在此后傳播對應于要傳送到受保護媒體路徑的內(nèi)容的策略。該SOTA確定要對通過受保護媒體路徑傳送的內(nèi)容采取的特定類動作，判定是否可對通過受保護媒體路徑傳送的內(nèi)容采取該特定類動作，并通知媒體基本庫有關內(nèi)容。媒體基本庫通知應用程序是否可采取該特定類動作，且如果可以應用程序通過命令媒體基本庫執(zhí)行該類動作而繼續(xù)。


結合附圖閱讀前面的發(fā)明內(nèi)容和以下本發(fā)明各實施例的詳細描述，能得到更好的理解。為了說明本發(fā)明，在附圖中示出當前優(yōu)選的各實施例；然而，應理解本發(fā)明并不限于所示的精確排列和裝置。在附圖中圖1是示出基于信任系統(tǒng)的示例的實施體系結構的框圖；圖2是示出其中可結合本發(fā)明各方面和/或其各部分的通用計算機系統(tǒng)的框圖；圖3是根據(jù)本發(fā)明一實施例示出在被應用程序調(diào)用之后由媒體基本庫定義的將內(nèi)容從源傳送到信宿的便攜式媒體路徑的框圖；圖4是根據(jù)本發(fā)明一實施例示出由圖3的便攜式媒體路徑在判定是否允許內(nèi)容從源傳送到信宿中執(zhí)行的關鍵步驟的流程圖；圖5是根據(jù)本發(fā)明一實施例示出圖3便攜式媒體路徑的一部分的框圖，包括帶有拒絕響應使能器的源可信權限，以及帶有用來接收和運行使能器的拒絕響應界面的應用程序；以及圖6是根據(jù)本發(fā)明一實施例示出由圖5單元響應于對執(zhí)行動作的拒絕而執(zhí)行的關鍵步驟的流程圖。
具體實施例方式
計算機環(huán)境圖2和以下討論旨在提供一種本發(fā)明和/或其部分可在其中實現(xiàn)的適當計算環(huán)境的簡要一般說明。盡管不是必需的，本發(fā)明將在由諸如客戶機工作站或服務器的計算機執(zhí)行的諸如程序模塊的計算機可執(zhí)行指令的一般環(huán)境中進行說明。通常，程序模塊包括執(zhí)行特定任務或實現(xiàn)具體抽象數(shù)據(jù)類型的例程、程序、對象、組件、數(shù)據(jù)結構等等。此外，本領域技術人員將理解，本發(fā)明和/或其部分可在其它計算機系統(tǒng)配置中實踐，包括手持式裝置、多處理器系統(tǒng)、基于微處理器的或可編程的電器消費品、網(wǎng)絡PC、小型計算機、大型計算機等等。本發(fā)明還可在任務由經(jīng)通信網(wǎng)絡鏈接的遠程處理裝置執(zhí)行的分布式計算環(huán)境中實踐。在分布式計算環(huán)境中，程序模塊可被置于本地和遠程存儲器存儲設備中。
如圖2所示，示例性通用計算系統(tǒng)具有常規(guī)個人計算機120等，包括處理單元121、系統(tǒng)存儲器122以及把包括系統(tǒng)存儲器的各種系統(tǒng)組件耦合到處理單元121的系統(tǒng)總線123。系統(tǒng)總線123可能是若干總線結構類型中的任何一種，包括存儲器總線或存儲器控制器、外圍總線、以及使用多種總線體系結構的任一種的局部總線。系統(tǒng)存儲器包括只讀存儲器(ROM)124和隨機存儲器(RAM)125。含有幫助如啟動期間在個人計算機120中元件之間傳遞信息的基本例程的基本輸入/輸出系統(tǒng)(BIOS)126被存儲在ROM 124中。
個人計算機120還包括讀取和寫入硬盤(未示出)的硬盤驅動器127、讀取或寫入可移動磁盤129的磁盤驅動器128、以及讀取或寫入諸如CD ROM或其它光學介質等可移動光盤131的光盤驅動器130。硬盤驅動器127、磁盤驅動器128和光盤驅動器130分別通過硬盤驅動器接口132、磁盤驅動器接口133和光盤驅動器接口134連接至系統(tǒng)總線123。諸驅動器及其相關聯(lián)計算機可讀介質為計算機120提供計算機可讀指令、數(shù)據(jù)結構、程序模塊和其它數(shù)據(jù)的非易失性儲存。
盡管在此所述示例性環(huán)境采用了硬盤、可移動磁盤129和可移動光盤131，但本領域技術人員應理解也可在示例性操作環(huán)境中使用其它類型計算機可訪問的能夠存儲數(shù)據(jù)的計算機可讀介質。這樣的其它類型的介質包括諸如磁帶盒、閃存卡、數(shù)字視頻盤、Bernoulli卡式磁帶、隨機存取存儲器(RAM)、只讀存儲器(ROM)等等。
包括操作系統(tǒng)135、一個或多個應用程序136、其它程序模塊137和程序數(shù)據(jù)138的眾多程序模塊，可存儲在硬盤、磁盤129、光盤131、ROM 124或RAM 125中。用戶可通過諸如鍵盤140和定位裝置142的輸入裝置把指令和信息輸入個人計算機120。其它輸入裝置(未示出)可包括諸如話筒、操縱桿、游戲墊、衛(wèi)星接收器、掃描儀等等。這些和其它輸入裝置常常通過與系統(tǒng)總線相耦合的串行端口接口146連接到處理單元121，但是它也可通過其它接口相連，如并行端口、游戲端口或通用串行總線(USB)。監(jiān)視器147或其它類型的顯示裝置也通過諸如視頻適配器148的接口和系統(tǒng)總線123相連。除了顯示器147，個人計算機通常包括其它外圍輸出裝置(未示出)，如揚聲器和打印機。圖2的示例性系統(tǒng)還包括主機適配器155、小型計算機系統(tǒng)接口(SCSI)總線156、以及與SCSI總線156相連的外部存儲裝置162。
個人計算機120可以在使用與一臺或多臺遠程計算機，諸如遠程計算機149的邏輯連接的網(wǎng)絡化環(huán)境中運行。遠程計算機149可以是另一臺個人計算機、服務器、路由器、網(wǎng)絡PC、對等裝置或其它公共網(wǎng)絡節(jié)點，而且通常包括上述與個人計算機120相關的許多或全部元件，盡管在圖2中僅顯示了存儲器存儲裝置150。圖2中所描繪的邏輯連接包括局域網(wǎng)(LAN)151和廣域網(wǎng)(WAN)152。這樣的網(wǎng)絡化環(huán)境在辦公室、企業(yè)范圍計算機網(wǎng)絡、企業(yè)內(nèi)聯(lián)網(wǎng)和因特網(wǎng)上是常見的。
當用于LAN網(wǎng)絡環(huán)境中時，個人計算機120通過網(wǎng)絡接口或適配器153與LAN 151連接。當用于WAN網(wǎng)絡環(huán)境中時，個人計算機120通常包括調(diào)制解調(diào)器154或其它用于在諸如因特網(wǎng)的廣域網(wǎng)152上建立通信的裝置?？梢允莾?nèi)置式或外置式的調(diào)制解調(diào)器154，與系統(tǒng)總線123通過串行端口接口146相連接。在網(wǎng)絡化環(huán)境中，所述與個人計算機120相關的程序模塊或其一部分，可以存儲在遠程存儲器存儲裝置中?？梢岳斫?，所示網(wǎng)絡連接是示例性的，也可以使用其它在計算機之間建立通信連接的裝置。
受保護的媒體路徑內(nèi)容保護表示用于保護數(shù)字內(nèi)容12使該內(nèi)容12不以與內(nèi)容所有者和/或提供者希望不一致的方式使用的一類方法和技術。方法包括版權保護(CP)、鏈接保護(LP)、條件訪問(CA)、權限管理(RM)和數(shù)字權限管理(DRM)等。任何內(nèi)容保護系統(tǒng)的基本是唯有確保適當遵守使用受保護內(nèi)容12的隱式和/或顯示規(guī)則的受信任應用程序才能以不受保護形式訪問該內(nèi)容。通常，內(nèi)容12通過以某些方式加密而受到保護，其中僅受信任的各方才能解密該內(nèi)容。
在嚴格意義上，拷貝保護具體地應用到駐留在存儲裝置上的內(nèi)容12，而鏈接保護應用到在各應用程序/裝置之間通過傳輸介質流動的內(nèi)容12。條件訪問可視作更高級形式的鏈接保護，其中付費節(jié)目、頻道和/或電影在傳輸中加密。只向為訪問這種內(nèi)容12付費的訂戶提供解密所需的密鑰。
數(shù)字權限管理是一可擴展體系結構，其中有關特定段內(nèi)容12的授權使用的規(guī)則是顯式的，并限于或關聯(lián)于內(nèi)容12本身。DRM機制可支持比其它方法更豐富和更有表現(xiàn)力的規(guī)則，同時在單段內(nèi)容或者甚至該內(nèi)容的子組件上提供更大的控制力和靈活性。數(shù)字權限管理系統(tǒng)的示例在申請?zhí)枮?9/290,363于1999年4月12日提交的美國專利申請以及申請?zhí)枮?0/126,614于1999年3月27日提交的美國臨時申請中陳述，它們在此全部被引入作為參考。
權限管理是一種有組織地基于內(nèi)容12的DRM形式，因為內(nèi)容12被保護或僅在一組織或其子集內(nèi)可訪問。權限管理系統(tǒng)的一個示例在申請?zhí)枮?0/185,257、10/185,278和10/185,511均于2002年6月28日提交的美國專利申請中陳述，這些申請在此全部引入作為參考。
在本發(fā)明中，在計算裝置14上定義受保護媒體路徑體系結構，以允許來自包括以上陳述系統(tǒng)的多個內(nèi)容管理系統(tǒng)的任一個的內(nèi)容處理和傳送。特別地，這種體系結構提供一種機制，用于將受保護內(nèi)容12從源30傳送到目標或‘信宿’32同時使該受保護內(nèi)容12能按需得到處理。注意，源30是傳送或‘溯源’內(nèi)容12的系統(tǒng)并可以是任何適當系統(tǒng)而不背離本發(fā)明的精神和范圍，當然假設源30可與該體系結構交互。例如，源30可以是若干高級功能或最少功能的權限管理系統(tǒng)(諸如DRM或RM系統(tǒng))的任一種，或可以是具有有限內(nèi)容保護的若干源30(諸如CP、LP或CA系統(tǒng))的任一種，或甚至可以是其中具有很少(若有的話)內(nèi)在內(nèi)容保護的若干源30(諸如基本數(shù)據(jù)存儲系統(tǒng)或服務器、文件存儲系統(tǒng)或服務器等)的任一種注意源30可從別的地方獲取實際內(nèi)容12。例如，受權限保護的內(nèi)容12可在遠程文件服務器上查找，但通過諸如計算裝置14上的權限管理系統(tǒng)的源30可訪問。
然后，源30能夠通過給定接口以一般方式溯源多媒體數(shù)據(jù)。源30的實現(xiàn)對應于訪問內(nèi)容的不同裝置，并可包括能夠從硬盤或其它文件系統(tǒng)讀取DRM文件的DRM源、能夠從DVD盤讀取DVD多媒體數(shù)據(jù)的DVD源等。注意，成為源30并不必然暗指其中內(nèi)容12的內(nèi)容保護。對于某些源30，內(nèi)容保護可對任一給定實例呈現(xiàn)或不呈現(xiàn)。
類似地，一個或多個信宿32的每一個是接收或‘引入’內(nèi)容12的系統(tǒng)，并可以是任何適當系統(tǒng)而不背離本發(fā)明的精神和范圍，當然再次假設信宿32可與該體系結構交互。例如，信宿32可以是用于接收要傳送給揚聲器的音頻的音頻系統(tǒng)、用于接收要傳送給顯示屏的視頻的視頻系統(tǒng)、用于接收要傳送給燈光系統(tǒng)控制器的燈光控制信號的燈光控制系統(tǒng)、用于接收要傳送給馬達系統(tǒng)控制器的馬達控制信號的馬達控制系統(tǒng)等。此外，信宿32可僅僅是連接到諸如網(wǎng)絡或數(shù)據(jù)電纜的管道的接口。注意，由于有源30，信宿32可將實際內(nèi)容12傳送到其它地方。例如，音頻內(nèi)容可通過諸如計算裝置14上聲卡的信宿32被傳送到遠程揚聲器。注意，給定信宿32與輸出資源而不是內(nèi)容保護系統(tǒng)相關聯(lián)。對于信宿32的任一實例，可有或沒有與之相關聯(lián)的內(nèi)容保護系統(tǒng)。
現(xiàn)在參看圖3，重要的是在該體系結構中，每個源30和每個信宿32可分別通過提供或訪問相應的源可信權限(SOTA)38或信宿可信權限(SITA)40被集成到計算裝置14上媒體基本庫36的策略引擎34。因而，每個源30和每個信宿32可位于計算裝置14的本地或遠程，但每個相應SOTA 38和SITA 40位于計算裝置本地，從而在至少某些方面擔當相應源30或信宿32的代理或代表。重要地且應被理解地，大多數(shù)任意源30或信宿32可通過分別具有相應SOTA 38或SITA 40來參與媒體基本庫36和受保護的媒體路徑體系結構。
每個SOTA 38代表在由該體系結構定義的受保護媒體路徑39中的相應源30，并行使在必要時提供用于解密來自源30的內(nèi)容12的解密功能，以及將與內(nèi)容12相關聯(lián)的策略從原始格式翻譯成遵從策略引擎34的格式的功能?？梢岳斫?，這種策略實質上是用于訪問并呈現(xiàn)內(nèi)容12的比如可在圖1許可證16中陳述的規(guī)則和要求。注意，SOTA 38也可用作源30，特別是關于與信任、策略和權限相關的問題。
類似地，每個SITA 40代表在由該體系結構定義的受保護媒體路徑39中的相應信宿32，并行使在必要時提供用于加密要傳送給信宿32的內(nèi)容12的加密功能，以及將與內(nèi)容12相關聯(lián)的策略從策略引擎34的格式翻譯成遵從信宿32的格式的功能。因而，信宿32接收內(nèi)容12和相應策略，在必要時解密所接收的內(nèi)容12，并基于接收策略呈現(xiàn)該內(nèi)容。注意，SITA 40可類似地用作信宿32，特別是關于與信任、策略和權限相關的問題。
還要注意，對應于任意特定內(nèi)容12的策略可以是任意適當策略，而不背離本發(fā)明的精神和范圍。這種策略通常在對特定源專用的前述原始格式中陳述，并可具有任意復雜性。例如，策略可被表達為一個序列的設為1或0的比特，可包括用預定義語言展示的要執(zhí)行的邏輯，和/或甚至可包括或指向可執(zhí)行的機器代碼。一般而言，策略可表達信息，諸如對于相應內(nèi)容12可采取的動作、在動作之前必須存在的條件、在必須采取動作之后的事件、對于內(nèi)容12要呈現(xiàn)或不可呈現(xiàn)的單元、這種單元上的條件、要與傳送內(nèi)容一起轉發(fā)的策略等等。
媒體基本庫36的策略引擎34是受保護媒體路徑體系結構的核心，并負責代表每個SOTA 38實施策略。因而，如以下將要詳細陳述的，策略引擎34在每個可應用源30和每個可應用信宿32之間協(xié)商策略，包括所需的信宿內(nèi)容保護系統(tǒng)、信宿內(nèi)容保護系統(tǒng)上的發(fā)送策略、以及媒體路徑組件包含和排除。策略引擎34還提供一受保護環(huán)境，其中所接收內(nèi)容12可以防止內(nèi)容12被邪惡實體竊取的一定保證度來處理。
具有策略引擎34的媒體基本庫36實際上是提供公共基礎機構所需的功能的公共集合，該基礎結構用于實現(xiàn)對來自任一特定源30的內(nèi)容12的處理并用于將已處理內(nèi)容12傳送到任一特定信宿32。重要的是，盡管內(nèi)容12及相關聯(lián)策略的格式可隨源30變化而變化，媒體基本庫仍可處理這樣的內(nèi)容12及相關聯(lián)策略，因為每個源30具有必要時解密內(nèi)容12并將相關聯(lián)策略從前述原始格式翻譯成遵從策略引擎34的前述格式的相應SOTA 38。類似地，盡管內(nèi)容12及相關聯(lián)策略的格式可隨信宿32變化而變化，媒體基本庫仍可處理這樣的內(nèi)容12及相關聯(lián)策略，因為每個信宿32具有必要時加密內(nèi)容12并將相關聯(lián)策略從前述遵從策略引擎34的格式翻譯成遵從信宿32的格式的相應SITA 40。
更具體地，媒體基本庫36提供一公共基礎結構以通過在計算裝置14的操作系統(tǒng)中提供一受保護環(huán)境以使媒體內(nèi)容12能流入流出該受保護環(huán)境，提供一個一般機制用于翻譯和談判跨受保護環(huán)境邊界的權限、規(guī)則和策略，并提供一個一般機制用于加密/解密高比特率的媒體數(shù)據(jù)同時將其在計算裝置14上的受保護環(huán)境和其它受保護環(huán)境之間安全地傳遞。因而，媒體基本庫36使受保護內(nèi)容12以受保護方式流出、流入并通過計算裝置14。結果，任何感興趣方都可通過發(fā)布適當?shù)腟OTA38和/或SITA 40將對任一內(nèi)容保護的支持加入計算裝置14上的操作系統(tǒng)。
通常，如圖3所示，媒體基本庫36包括提供該媒體基本庫36的前述公共基礎結構的眾多核心組件42。可以理解，每個組件42可以是任意適當組件而不背離本發(fā)明的精神和范圍。采用這樣的核心組件42通常是眾所周知的或對相關群體應當是顯而易見的，因此無需在此贅述。
除媒體基本庫36的核心組件42所提供的功能之外，如果必要，通過發(fā)布適當?shù)谋辉O計成結合媒體基本庫36工作以提供這種附加功能的補充組件或‘插件’44，任一感興趣方可將對附加的任意受保護功能的支持添加到計算裝置14上的操作系統(tǒng)?？梢岳斫?，每個插件44可以是任意適當?shù)牟寮槐畴x本發(fā)明的精神和范圍。采用這樣的插件44通常是眾所周知的或對相關群體應當是顯而易見的，因此無需在此贅述。
在本發(fā)明一實施例中，媒體基本庫36被驅使以通過計算裝置14上的媒體應用程序46來安排一個或多個選定源30的每一個與一個或多個選定信宿32的每一個之間的受保護媒體路徑39。假設媒體應用程序46在用戶、計算裝置14上或其它地方的另一應用程序的控制之下。因而媒體應用程序46選擇要呈現(xiàn)的內(nèi)容12，且其中選擇一個或多個選定源30，并在必要時選擇一個或多個信宿32。此后，媒體應用程序通過已安排的受保護媒體路徑39而不涉及受保護內(nèi)容12的呈現(xiàn)，除了有可能提供諸如開始、停止、重復、倒轉、快進等的呈現(xiàn)控制命令。
在本發(fā)明一實施例中，媒體基本庫36以及由此安排的受保護媒體路徑39單獨負責控制在已安排的受保護媒體路徑39內(nèi)的內(nèi)容12，而相應地應用程序46不控制在已安排的受保護媒體路徑39內(nèi)的內(nèi)容12。因而，應用程序46通過媒體基本庫36和由此安排的受保護媒體路徑39引導內(nèi)容12的呈現(xiàn)，但對該內(nèi)容12沒有任何實際訪問或控制，尤其是以任何未受保護形式。特別地，媒體基本庫36和受保護媒體路徑39不能由應用程序46或任何其它單元引導對內(nèi)容12采取違反與內(nèi)容12相對應的策略的動作。結果，重要的是應用程序46不需建立與圖3受保護媒體路徑39相關的任何特定信任度，并且實際上應用程序46并不被信任以任何受信任方式處理內(nèi)容12。當然，應用程序46中這種信任的缺乏并不是有害的，因為應用程序46實際上除了在媒體基本庫36和由此安排的受保護媒體路徑39的操作過程中發(fā)出上述呈現(xiàn)控制命令外并不處理內(nèi)容12。
總而言之，媒體基本庫36在應用程序46的引導下操作以安排受保護媒體路徑39，通過它將來自一個或多個源30的內(nèi)容12傳送到一個或多個信宿32。假設內(nèi)容12在通過已安排的受保護媒體路徑39傳輸時由媒體基本庫36以某方式操作，盡管媒體基本庫36對該內(nèi)容12的這種操作可按需是最少或最多發(fā)熱。重要的是，在每個源30允許內(nèi)容12通過已安排的受保護媒體路徑39傳輸之前且在本發(fā)明一實施例中，源30確信，簡單涉及或‘觸及’內(nèi)容12的媒體基本庫36、其處理引擎34、其每個采用組件42、其每個采用插件44、每個接收信宿32和任何其它組件是(a)可靠的并(b)具有基于與內(nèi)容12相關聯(lián)的策略觸及內(nèi)容12的權限。
根據(jù)本發(fā)明，可基于擔保單元的權標的提供示出可靠單元。這種擔保權標可以是任何適當?shù)膿鄻硕槐畴x本發(fā)明的精神和范圍。例如，特別是在數(shù)字領域中，這種擔保權標可包括來自擔保權威機構的數(shù)字證書，可能包括擴展回一眾所周知的并受信任的根源權威機構的各證書的校驗鏈。這樣的證書會包括可基于證書中的密鑰校驗的受信任單元的散列，從而出于任何目的對單元的更改(包括破壞了該單元的信任度)將導致散列無法得到校驗，在該情形中該單元不受信任。
還根據(jù)本發(fā)明，一旦認為單元可靠，則確信該單元要基于它是否可給予在與內(nèi)容12相關聯(lián)的策略中陳述的權限來判定它是否可觸及內(nèi)容12?；蛘?，確信單元要誠實地響應于來自另一單元的基于權限的查詢。例如，如果策略表述，一個單元必須至少具有某版本號，而該單元具有一較舊版本號，則確信單元被拒絕觸及內(nèi)容12，且在該特定情形中可能被期望向詢問方解釋這樣拒絕的理由。類似地，如果例如策略表述單元必須不以未受保護形式存儲內(nèi)容12，且該單元的確這樣做了，類似地確信該單元要拒絕觸及內(nèi)容12，且再次在該特定情形中可能被期望向詢問方解釋這樣拒絕的理由。
參看圖4，在本發(fā)明一實施例中，如圖3所示的受保護媒體路徑體系結構被用來以以下方式將內(nèi)容12從一個或多個源30傳送到一個或多個信宿32。起初，在用戶或另一單元引導下的應用程序46想要將內(nèi)容12從一個或多個源30傳送到一個或多個信宿32，并因而用內(nèi)容12的定義、從中獲取內(nèi)容12的每個源30、以及向其傳送內(nèi)容12的每個信宿32來調(diào)用媒體基本庫36(步驟401)。
作為響應，基于所定義內(nèi)容12、源30和信宿32的媒體基本庫36建立一受保護媒體路徑39以實現(xiàn)這樣的傳送(步驟403)。注意，其中媒體基本庫36可選擇在通過受保護媒體路徑39傳送時要對內(nèi)容12進行處理和操作的一個或多個組件42，并類似地可選擇在通過受保護媒體路徑39傳送時要對內(nèi)容12進行處理和操作的一個或多個插件44。媒體基本庫36可采用任何適當方法來建立受保護的媒體路徑39并選擇組件42和插件44而不背離本發(fā)明的精神和范圍。由媒體基本庫36對受保護媒體路徑39的建立以及對組件42和插件44的選擇是眾所周知的或對相關群體應當是顯而易見的，因此無需在此贅述。例如，本發(fā)明所采取并與媒體基本庫36相關的動作可包括在附錄中陳述的動作。
重要的是，在媒體基本庫36建立受保護媒體路徑39之后，對應于被定義路徑39的每個源30的SOTA 38被例示為將源30連接到媒體基本庫36的安全加鎖箱，如圖3(圖4步驟405)所示。這種例示可由源30、媒體基本庫36、或其組合實現(xiàn)而不背離本發(fā)明的精神和范圍。如上所述，每個SOTA 38都是可信權限且代表受保護媒體路徑39中的相應源30，并行使在必要時提供用于從源30解密內(nèi)容12的解密功能，以及將與內(nèi)容12相關聯(lián)的策略從原始格式翻譯成遵從媒體基本庫的策略引擎34的格式的功能。注意，SOTA38也可用作源30，特別是關于與信任、策略和權限相關的問題。
也重要的是，在媒體基本庫36建立受保護媒體路徑39之后，對應于被定義路徑39的每個信宿32的SITA 40被例示為將信宿32連接到媒體基本庫36的安全加鎖箱，如圖3(圖4步驟407)所示。類似地，這種例示可由信宿32、媒體基本庫36、或其組合實現(xiàn)而不背離本發(fā)明的精神和范圍。如上所述，每個SITA 40都是可信權限且代表受保護媒體路徑39中的相應信宿32，并行使在必要時提供用于加密要傳送給信宿32的內(nèi)容12的加密功能，以及將與內(nèi)容12相關聯(lián)的策略從策略引擎34的格式翻譯成遵從信宿32的格式的功能。還注意到，SITA 40可用作信宿32，特別是關于與信任、策略和權限相關的問題。
在本發(fā)明一實施例中，代表源30動作的SOTA 38建立對于受保護媒體路徑的信任。然后一旦建立信任，SOTA 38傳播要呈現(xiàn)的對應于內(nèi)容12的策略，如應用程序46在步驟401所定義。特別地，通過首先建立與媒體基本庫36的策略引擎34的信任SOTA 38建立信任(步驟409)。隨后，受信任的策略引擎34與剩下的受保護媒體路徑39建立信任，包括每個組件42、每個插件44以及由SITA 40代表的每個信宿32(步驟411)。
在建立信任時，如上所述，可基于權標的提供示出可靠單元，諸如來自擔保單元的擔保權威機構的數(shù)字證書。這樣的權標證書會包括可基于證書中的密鑰校驗的受信任單元的散列，從而建立對單元的信任可包括校驗該散列。注意，在信任未對單元建立的任何時候，該單元被拒絕訪問內(nèi)容12。因而，如果可能必須從受保護媒體路徑39中移除該單元。如果不可能，SOTA 38不把內(nèi)容12釋放給該受保護媒體路徑39。
假設受信任策略引擎34實際上建立了對受保護媒體路徑39的每個單元的信任，包括每個組件42、每個插件44、以及由SITA 40代表的每個信宿，然后SOTA38傳播對應于要呈現(xiàn)的內(nèi)容12的策略。特別地，SOTA 38向該策略引擎34傳播該策略(步驟413)。其中，SOTA 38采用將策略從原始格式翻譯成遵從媒體基本庫36的策略引擎34的格式所必須的功能，然后將經(jīng)翻譯策略傳送給策略引擎34。
然后，帶有經(jīng)翻譯策略的策略引擎34確立，媒體基本庫36的每個組件42和每個插件44具有觸及或訪問內(nèi)容12對應于經(jīng)翻譯策略的權限。特別地，基于該經(jīng)翻譯策略，策略引擎34按需確定媒體基本庫36的每個組件42和插件44滿足經(jīng)翻譯策略的條款(步驟415)。注意，受信任單元可仍然不具備基于該策略觸及或訪問內(nèi)容12的權限。例如，如上所述，如果策略表述單元必須至少具有某版本號，而該單元具有一較舊版本號，則雖然該單元被信任，仍不具備觸及或訪問內(nèi)容12的權限。注意，在受信任單元未具有由策略引擎34確定的訪問或觸及內(nèi)容12的任何時候，該單元被拒絕訪問內(nèi)容12。因而，如果可能必須從受保護媒體路徑39中移除該單元。如果不可能，SOTA 38不把內(nèi)容12釋放給該受保護媒體路徑39。
此外，帶有經(jīng)翻譯策略的策略引擎34確立，受保護媒體路徑39中的每個信宿具有觸及或訪問內(nèi)容12對應于經(jīng)翻譯策略的權限。特別地，策略引擎34將該經(jīng)翻譯策略傳播到信宿32的SITA 40(步驟417)。其中，類似地SITA 40采用將經(jīng)翻譯策略重新翻譯成遵從信宿32的格式所必須的功能，然后將經(jīng)重新翻譯的策略傳送給SITA 40。然后，作為受保護媒體路徑39的受信任單元的信宿32和SITA 40被確信遵守該經(jīng)重新翻譯的策略。
在本發(fā)明一實施例中，附加或另選的策略引擎34通過SITA 40向信宿32請求對應于策略信宿32想要對內(nèi)容12采取的動作(步驟419)。這種動作可包括例如播放內(nèi)容12、復制內(nèi)容12、以不受保護格式輸出內(nèi)容12等。注意因為包括SITA 40和信宿32的受保護媒體路徑39在應用程序46的命令下建立，該SITA 40/信宿32應顯式或隱式地知道對于內(nèi)容12要采取什么動作。注意，盡管策略引擎34可請求應用程序46這樣動作，應用程序46并不受信任以作誠實響應，而信宿32/SITA 40實際上是受信任的。
無論如何，受信任信宿32/SITA 40響應該動作，而策略引擎34將其轉發(fā)給SOTA 38(步驟421)。然后，SOTA 38判定SITA 40/信宿32是否可假設參照對應于內(nèi)容12的策略采取動作，并將其通知給策略引擎34(步驟423)。應理解，如果未采取該動作，SOTA 38將不允許內(nèi)容12釋放給受保護媒體路徑39。
假設采取了該動作，策略引擎34將其通知給應用程序46(步驟425)，然后應用程序46通過命令媒體基本庫36執(zhí)行該動作及相關動作繼續(xù)(步驟427)。例如，應用程序可命令媒體基本庫播放內(nèi)容12，并還可在以后時間命令媒體基本庫36停止、回放、快進、跳前、跳后等。
注意在采取該動作的過程中，內(nèi)容12通過由媒體基本庫36安排的受保護媒體路徑39。特別地，媒體基本庫36從源30中檢索內(nèi)容12，使用SOTA 38的解密功能來按需解密內(nèi)容12，然后向下發(fā)送內(nèi)容12。因而，媒體基本庫36及其組件42和插件44執(zhí)行對內(nèi)容12所必須的處理，且媒體基本庫36使用SITA 40的加密功能來按需加密內(nèi)容12并向信宿32發(fā)送內(nèi)容12。當然，信宿32隨后將內(nèi)容12發(fā)送到最終目標。
對內(nèi)容12采取的動作應由策略引擎34傳送給SOTA 38，從而SOTA 38可更新與對應于該內(nèi)容12的策略相關的任何狀態(tài)信息。例如，如果策略需要保留播放計數(shù)，SOTA 38應注意在某時刻之后會調(diào)整播放計數(shù)?；蛘?，作為內(nèi)容12傳送者的SOTA 38自己可感知所采取的動作并隨后按需更新任何狀態(tài)信息。
現(xiàn)在應理解，應用程序46可在以后某個時刻決定重新配置受保護媒體路徑39。例如，應用程序46可改變音頻信宿32和燈光信宿32。這樣，應理解，如圖4所述的過程必須重復以在經(jīng)重新配置路徑中建立信任，并將權限傳播到那里。
應理解，在本發(fā)明中，可指示媒體基本庫36基于源30和信宿32的某些任意或幾乎任意的組合來建立受保護媒體路徑39。重要的是，無論所建立的是什么路徑39，本發(fā)明的體系結構使該路徑39能被鑒定為可靠，并滿足有關對應于通過該路徑的內(nèi)容12的策略或權限。此外，盡管路徑39在應用程序46的命令下建立，這種應用程序46本身無需是可靠的，因為應用程序46本身從不以它可能有意或無意地竊取內(nèi)容12的方式觸及或訪問內(nèi)容12。
拒絕響應使能器及其界面如上結合圖4所示方法所述，受信任信宿32/SITA 40在步驟421提供響應于策略引擎34要采取的動作，而SOTA 38在步驟423判定SITA 40/信宿32是否可采取動作并將其通知策略引擎34。如果SOTA 38拒絕允許動作被采取，則SOTA 38不允許內(nèi)容12向受保護媒體路徑39釋放。
這樣的拒絕通常將結束圖4的過程，可能導致應用程序46的用戶有不甚滿意的體驗。然而，可以理解，可預期至少某些類型拒絕的底層基礎，可用相對直接的方法來處理至少某些底層基礎，并且SOTA 38因此可被構建為包括或訪問解決至少某些拒絕的底層基礎的功能。這種拒絕有很多并且是可變的，并可包括缺少適當許可證16(圖1)、缺少單元的當前版本、內(nèi)含被設置成執(zhí)行不適當功能的信宿32等。在本發(fā)明一實施例中，向受保護媒體路徑39的體系結構提供了拒絕響應功能以響應至少某些拒絕。
注意，這樣的拒絕響應功能可被包括在媒體基本庫36中而不背離本發(fā)明的精神和范圍。然而，由于這樣的拒絕響應功能可能與特定源30緊密相關，更可能的是這種功能應被包括在對應于該源30的SOTA 38或由其訪問。
注意，響應一拒絕有時可通過應用程序46請求用戶輸入，而有時則相反地可放棄這種用戶輸入，其中SOTA無需用戶的幫助而響應。然而，根據(jù)良好實踐，應用程序上的用戶應一直參與對拒絕的響應，特別是當響應需要從諸如網(wǎng)絡的遠程源獲取一條目或信息時。在本發(fā)明一實施例中，參看圖5，每個SOTA 38提供一個或多個拒絕響應使能器48，每個響應于一特定拒絕，而應用程序46包括可與每個使能器48通過界面連接的由媒體基本庫36提供的響應界面50。
因而，應當理解，被提供的使能器48和界面50通過應用程序46提供一抽象層以由SOTA 38實現(xiàn)拒絕響應的細節(jié)。特別地，SOTA 38的被提供使能器48陳述響應其特定拒絕的過程，包括一個或多個獲取用戶所需信息和輸入的位置的過程等，而界面50指定應用程序46和通過媒體基本庫36提供的使能器48之間的一致交互過程。重要的是，盡管被提供使能器48隨各拒絕和源30不同而不同，界面50不管被提供使能器48與哪個拒絕或哪個源30/SOTA 38相關聯(lián)都采用相同的界面過程。因而，應用程序46采用從被提供的使能器48中可得到的任何功能以執(zhí)行拒絕響應而無需區(qū)別提供這種使能器48的特定源30。注意，盡管應用程序46不受信任，通過使能器48獲取的任何信息或數(shù)據(jù)被提供給媒體基本庫36和/或便攜式媒體路徑39，并且它本身不得不證實在這種媒體基本庫36和/或便攜式媒體路徑39的環(huán)境中的可靠性。即，當界面50運行使能器48時在應用程序46所采取的措施中沒有固有的信任。
現(xiàn)在參照圖6可看到，結合受保護的媒體路徑39，受信任的SITA 40在步驟421提供了響應于策略引擎34要采取的動作，而SOTA 38此時已因為某些感覺到的缺陷拒絕使SITA 40采取動作如步驟423(步驟601)。然而，SOTA 38已認識到，通過這種SOTA 38可用的或包括其中的特定使能器48的應用程序可對拒絕的基礎作出響應(步驟603)，且SOTA 38因而通過媒體基本庫36把特定使能器48提供給應用程序46(步驟605)。注意，媒體基本庫36可具有對界面的指針或其它參考點，并可因而通過這種指針或其它參考點把被提供使能器指向應用程序46的界面50。
可以理解，被提供使能器48包括所有信息以及應用程序46通過其界面50獲取對使該被提供使能器48成為必需的拒絕作出響應所需的任何信息或數(shù)據(jù)的各方法。因而，被提供使能器48通過應用程序46的界面50經(jīng)由媒體基本庫36從SOTA38接收(步驟607)，而界面50把前述的一致交互過程應用于有效運行被提供使能器48(步驟609)。因而，有了被提供使能器48以及來自用戶的必須的和/或穩(wěn)健輸入，應用程序46及其界面50實際上嘗試獲取的是由來自必需源(本地或遠程的)的拒絕所必須的任何數(shù)據(jù)或信息(步驟611)。當然，所需的用戶交互程度基于環(huán)境而變化。例如，它在某些環(huán)境中可足以在下載數(shù)據(jù)或信息之前獲得用戶的許可，特別是當下載并無成本時。然而如果涉及到費用，則當然有必要獲取用戶對支付費用的許可，但無需提及如何支付費用的細節(jié)。
因而，如果拒絕基于缺少適當許可證16，則獲取許可證16。如果基于缺少單元的當前版本，則獲取該單元的當前版本，且如果基于信宿32的內(nèi)含被設置成執(zhí)行一不適當功能，用戶和/或應用程序適當?shù)卦O置信宿32，等等。注意，當然并不是所有的拒絕是可以補救的。例如，用戶可能不想獲取所需許可證、單元的當前版本可能不可用，或者信宿32可能無法以對SOTA 38滿意的方式設置。當然，在這種情形中響應失敗，且SOTA 38將拒絕允許SITA 40采取應存取的動作。
然而，假設拒絕實際上通過獲取必需數(shù)據(jù)或信息得到補救，則應用程序46向媒體基本庫36發(fā)送該數(shù)據(jù)或信息(步驟613)，且通過例如將許可證16存儲在許可證存儲中、安裝組件的當前版本、調(diào)整信宿32的設置等，媒體數(shù)據(jù)庫36按需適當采用該數(shù)據(jù)(步驟615)。
一旦完成，界面50通知SOTA 38、應用程序46、和/或應用程序46的用戶，由被提供使能器48所需承擔的響應是完整的，且可能響應是成功或失敗的(步驟617)。此外，情形可能是界面50的一致交互過程包括一周期性進展通知功能，它周期地向SOTA 38、應用程序46、和/或應用程序46的用戶通知響應的進展，從而可能上述無一會使響應超時并退出。在此情形中，實際上界面50向SOTA 38、應用程序46、和/或應用程序46的用戶周期性地通知期間響應的進展(步驟612)。
無論如何，在向SOTA 38通知響應完成(步驟617)之后，SOTA再次判定SITA40/信宿32是否可采取原來被拒絕的動作(步驟619)。如果SOTA38再次拒絕允許采取動作，則SOTA 38再次不允許內(nèi)容12向受保護的媒體路徑39釋放，但相反可再次認識到，通過這種SOTA 38可用的或包括其中的特定使能器48的應用程序可對拒絕的基礎作出響應(如步驟603)，且SOTA 38因而再次通過媒體基本庫36把特定使能器48提供給應用程序46(如步驟605)。
然而，假設SOTA 38現(xiàn)在實際上允許SITA 40采取要求動作，SOTA 38此時允許內(nèi)容12向受保護媒體路徑39釋放，且策略引擎34將其通知應用程序46，如圖4步驟425。應當理解，應用程序46可通過命令媒體基本庫36來執(zhí)行該動作及相關動作繼續(xù)，如圖4步驟427。
現(xiàn)在應當理解，SOTA 38采用由應用程序46的界面50執(zhí)行的使能器48以允許SOTA 38使用戶和/或應用程序46在SOTA拒絕SITA 40所請求的動作時執(zhí)行對SOTA 38的響應。盡管SOTA 38可能可自己執(zhí)行響應，但根據(jù)良好實踐，應用程序上的用戶應一直參與對拒絕的響應，特別是當響應需要從諸如網(wǎng)絡的遠程源獲取一條目或信息時。此外，無論如何，都有這種用戶對應用程序46的參與是必要的時候。
結論本發(fā)明可對任何適當源30和信宿32實踐，假設這種源30和信宿32分別具有相應SOTA 38和SITA 40，通過它們可獲取與媒體基本庫36的通信。因此，本發(fā)明的受保護媒體路徑39要被解釋成包括可以任意方式建立受保護媒體路徑39以便將內(nèi)容從源30傳送到信宿32的任何SOTA 38、媒體基本庫36和SITA 40。
注意，盡管本發(fā)明主要根據(jù)執(zhí)行呈現(xiàn)或回放的信宿32來揭示，信宿32可執(zhí)行其它動作而不背離本發(fā)明的范圍。這些其它動作包括但不限于，將內(nèi)容12傳送給獨立計算裝置，諸如個人計算機、便攜式裝置等；將內(nèi)容12傳送給便攜式存儲器、磁盤或光盤等；以不同的保護方式傳輸內(nèi)容12。無任何保護方案地輸出內(nèi)容12；以不同格式傳送或輸出內(nèi)容12等。
一般而言，可采用由媒體基本庫36安排的受保護媒體路徑39來呈現(xiàn)或回放內(nèi)容12，并執(zhí)行諸如內(nèi)容創(chuàng)建、編輯和分發(fā)的任務。例如，內(nèi)容12可具有允許或禁止內(nèi)容12以某些方式編輯的策略。因而，可采用受保護媒體路徑39來用遵從對應于內(nèi)容12的策略解密、編輯、以及重新加密內(nèi)容12。
實現(xiàn)結合本發(fā)明執(zhí)行的過程所需的編程是相對直接的，并且對于相關編程群體而言應是顯而易見的。因此，并未附加這種編程?？刹捎萌我馓囟ň幊虂韺崿F(xiàn)本發(fā)明而不背離其精神和范圍。
在上述描述中，可看到本發(fā)明包括定義用于把內(nèi)容12從多個源30的任一個傳送到多個信宿32的任一個的一種新的和有用的體系結構和方法。結合這種體系結構的方法定義如何將該路徑建立為可靠并滿足對應于內(nèi)容12的策略。
應理解，可對上述實施例作改變而不背離其中發(fā)明概念。因此，應理解，本發(fā)明并不限于所揭示的特定實施例，而旨在涵蓋由所附權利要求定義的本發(fā)明精神和范圍內(nèi)的更改。
附錄[注術語“回放”應被解釋為內(nèi)容向輸出的任意呈現(xiàn)，包括存檔為文件、廣播等。使用字“回放”僅是更為方便。]I.媒體基本庫API及功能本節(jié)及以下內(nèi)容將討論根據(jù)所展現(xiàn)功能的類型分類的API。
a.打開/關閉多媒體i.OpenURL無疑是最通用的使用媒體基本庫打開多媒體的方法，這將使媒體基本庫使用其源解析器來創(chuàng)建將能讀取特定URL上內(nèi)容的媒體源。
ii.OpenSource如果應用程序已創(chuàng)建了媒體源并想要使用該源呈現(xiàn)，他將調(diào)用OpenSource()，且媒體基本庫將直接使用該源。
iii.OpenBindable這用于不具有媒體源，但相反具有可從一媒體源對象獲取的實現(xiàn)IBindable的對象的應用程序。IBindable接口來自裝置目錄。
iv.OpenByteStream這用于具有從中可讀取要呈現(xiàn)的多媒體數(shù)據(jù)的IMFByteStream的應用程序。IMFByteStream是對從中可獲取順序數(shù)據(jù)的任何對象的媒體基本庫抽象。
v.OpenTopology先進的應用程序可能想要創(chuàng)建定義要在呈現(xiàn)中使用的源、信宿和變換的拓撲，而不依賴于媒體基本庫和媒體會話(參見III.a.iii)。這些應用程序可提供拓撲并繞過在其它情況應該做的任何源或拓撲的解析。
vi.Close關閉當前媒體。通過使用以上“Open”調(diào)用的任一個可隨后對新媒體重新使用媒體基本庫。
b.呈現(xiàn)控制i.Start應用程序調(diào)用它來開始回放。各參數(shù)使應用程序能指定回放的開始位置和終止位置，缺省是請求回放從頭開始直到結束。有定義這些開始和結束參數(shù)單位的第三個參數(shù)。缺省單位是10MHz時間單位，但是可使用在多媒體呈現(xiàn)中指定位置的其它系統(tǒng)，諸如幀數(shù)或時間代碼。在媒體基本庫已啟動式，也可調(diào)用Start；即尋找內(nèi)容中的新位置并從那里開始回放。
ii.Stop應用程序調(diào)用它來停止回放。時鐘上所示時間將回到零。如果應用程序再次調(diào)用帶有缺省參數(shù)的Start()，回放將從頭開始。
iii.Pause應用程序調(diào)用它來暫?；胤拧r鐘上所示時間將保持“不變”。如果應用程序再次帶有缺省參數(shù)地調(diào)用Start()，則回放將從其暫停之處恢復。
iv.SetPresentationTimeSource它用于想要驅動時鐘上時間用于呈現(xiàn)的先進應用程序。如果應用程序調(diào)用它，則所有的組件將嘗試根據(jù)該時間源展現(xiàn)的時間來運行。沒有這個調(diào)用，則媒體會話從提供時間源的所有組件中(參見III.b.iii)選擇一個時間源。
c.信息查詢以下API對于想要獲取更多有關呈現(xiàn)的信息的應用程序是有用的。
i.GetCapabilities該方法展現(xiàn)了在呈現(xiàn)期間可改變的媒體基本庫和媒體會話的各種能力。
ii. GetMetadata該方法使應用程序能獲取可查詢?nèi)魏斡嘘P呈現(xiàn)的元數(shù)據(jù)(例如持續(xù)時間、標題、作者等)的屬性存儲。
iii.GetDestination檢索指向使用中目標的指針。
iv.GetStatistics檢索有關媒體基本庫活動的統(tǒng)計數(shù)字。
d.Shutdown(關閉)一旦不再使用媒體基本庫就調(diào)用它。它釋放所有資源和對其它組件的參考點(包括媒體會話)，也關閉它們。
e.事件媒體基本庫將通過其媒體事件發(fā)生器向應用程序通知事件。以下是某些較常見事件的列表，盡管由媒體會話內(nèi)組件產(chǎn)生的其它事件也可被傳播到應用程序。
i.MEMediaOpened本事件伴有描述呈現(xiàn)的輸出看起來如何的呈現(xiàn)描述符。
ii.MEMediaStartediii.MEMediaStoppediv.MEMediaPausedv.MEMediaEndedvi.MEMediaClosedvii.MEMediaRateChangedViii.MEMediaStateChangedix.MENewPresentation本事件伴有描述源自媒體源的呈現(xiàn)看起來如何的呈現(xiàn)描述符。在作出“Open”調(diào)用之一后，以及對于媒體源在時間線情景中隨后輸出的每個新呈現(xiàn)都將接收一次該事件。應用程序可有選擇地使用該信息來配置新呈現(xiàn)預期中的目標。
x.MEPresentationSwitched新呈現(xiàn)真正回放時發(fā)送本事件一次。它反映進行呈現(xiàn)時所有的不同輸出。
xi.MEOutputsUpdated在目標(輸出)改變時一旦該改變已完全解析并到位時就發(fā)送本事件。它反映進行呈現(xiàn)時所有的不同輸出。
II.媒體會話API和功能使用媒體基本庫控制層的每個呈現(xiàn)通過由媒體基本庫例示或以其它方式獲取的媒體會話運行。盡管媒體基本庫提供了將用于各種各樣情形的媒體會話實現(xiàn)，可根據(jù)本說明書建立展現(xiàn)以下API的其它媒體會話。這通常在如果所呈現(xiàn)的多媒體不適用于將要在提供MF的多媒體會話中使用的媒體源、媒體信宿以及其它MF結構的概念時有用。例如，能運行Shockwave Flash呈現(xiàn)的媒體會話將在媒體基本庫中提供。
a.會話配置以下API使媒體基本庫能配置用于呈現(xiàn)的媒體會話i.ResolveTopology當媒體基本庫已創(chuàng)建用于呈現(xiàn)的需要解析到全部拓撲的部分拓撲(參見III.a.iii)時，調(diào)用它。
ii.SetTopology一旦具有將來呈現(xiàn)的全部拓撲，媒體基本庫調(diào)用它。媒體會話在媒體處理器上設置它，該處理器通過在拓撲中指定的所有轉換設置管線以獲得來自媒體源的數(shù)據(jù)。
iii.SetPresentationClock當調(diào)用它時，媒體會話確保所有組件(媒體信宿和某些媒體源)訂購接收來自時鐘的通知，該時鐘將被用于控制呈現(xiàn)。
iv.SetConfigurationPropertyStore使用本方法將配置參數(shù)的可擴展集被傳遞到媒體會話。
b.呈現(xiàn)控制以下API使媒體基本庫能控制呈現(xiàn)。對于II.b.i到II.b.iv，參見以上媒體基本庫章節(jié)(I.b)中的注解。
i.Startii.Stopiii.Pauseiv.SetPresentationTimeSourcev.Preroll媒體基本庫使用它來告知媒體會話已為將來呈現(xiàn)的開始準備好了一切。
c.信息查詢這些API使媒體基本庫能從媒體會話中獲得信息。
i.GetSessionGUID標識媒體會話的實現(xiàn)。如上所述，媒體基本庫提供用于各種情形的實現(xiàn)，但也可使用其它實現(xiàn)。
ii.GetSessionCapablities類似于I.c.i。
d.Shutdowne.事件由媒體會話產(chǎn)生的事件被媒體基本庫接收。對于某些事件，媒體基本庫將它們翻譯成列于媒體基本庫事件(I.e)列表中的事件之一。對于一部分，媒體基本庫在包含其中的信息上動作且并不將它們傳播給應用程序。對于其它，媒體基本庫將它們傳播給應用程序。
i.MESessionPrerolledii.MESessionStartediii.MESessionStoppediv.MESessionEndedv.MESessionPausedvi.MEMediaRateChangedIII.媒體基本庫中的呈現(xiàn)流本節(jié)是一典型多媒體情形的縱覽，以及對媒體基本庫和媒體會話為驅動呈現(xiàn)所作的描述。
a.媒體基本庫工作i.源的解析本步驟獲取從中可讀取多媒體數(shù)據(jù)的媒體源。本步驟在OpenURL或OpenByteStream被用于打開多媒體時是相關的。其它Open功能直接指定媒體源。
媒體基本庫將URL或字節(jié)流傳遞給源解析器。如果給予源解析器一URL，則它著眼于URL(file://，http://等)的方案來創(chuàng)建將從指定位置讀取的字節(jié)流。
在兩種情形中，源解析器能使用字節(jié)流的內(nèi)容來確定比特的格式(ASF、AVI、MEPG等)從而可例示將理解格式的媒體源。
ii.設置媒體會話向媒體源請求一呈現(xiàn)描述符。該描述符可指定要使用的客戶媒體會話。但這不是通常的情形；通常，在此例示缺省的媒體基本庫的媒體會話。
iii.部分拓撲解析媒體基本庫從媒體源獲取一呈現(xiàn)描述符，并通過MENewPresentation向應用程序通知該呈現(xiàn)。如果應用程序對處理該事件感興趣，則媒體基本庫等待應用程序來完成處理。
然后媒體基本庫與應用程序提供的目標協(xié)商，并為呈現(xiàn)的輸出創(chuàng)建媒體信宿。媒體基本庫構建一“部分拓撲”，它指示源媒體流和輸出流信宿而無需指定達到目的所需的轉換。
iv.拓撲解析和激活媒體基本庫請求媒體會話將部分拓撲解析成全部指定拓撲。然后媒體基本庫在媒體會話上設置新的全指定拓撲。
v.呈現(xiàn)控制通過調(diào)用媒體基本庫上的開始、停止和暫停，應用程序可控制呈現(xiàn)的進展。媒體基本庫將這些調(diào)用轉發(fā)給處理它們的媒體會話。
vi.處理來自媒體源的新呈現(xiàn)如果媒體源是時間線，則它將通過事件向媒體會話通知將來的新呈現(xiàn)，媒體會話將事件轉發(fā)給媒體基本庫。然后媒體基本庫使用新呈現(xiàn)的描述符從步驟III.a.iii到步驟III.a.iv。一旦新呈現(xiàn)的回放將要開始，向應用程序發(fā)送MEPresentationSwitch。
vii.處理輸出變化如果媒體基本庫接收了來自應用程序提供目標的通知它輸出方變化的事件，則它使用現(xiàn)有呈現(xiàn)的描述符從步驟III.a.iii到步驟III.a.iv。一旦使用新輸出的回放將要開始，向應用程序發(fā)送MEOutputsUpdated。
b.媒體會話工作以下詳細描述媒體會話的主要媒體基本庫實現(xiàn)如何工作。其它媒體會話必需提供以上(ii)列出的API和功能，但它們必需以不同方式完成它。
i.全拓撲解析會話使用拓撲載入器來解析拓撲，該載入器指出為從源媒體流中獲得數(shù)據(jù)到輸出流信宿哪些轉換是必要的。
ii.媒體處理器創(chuàng)建會話擁有媒體處理器。當拓撲在媒體會話上設置時，媒體會話在配置從媒體流到媒體信宿所需格式的管線的媒體處理器上設置拓撲。
iii.時間源選擇在開始呈現(xiàn)之后，媒體會話確定哪個可用時間源將被用于驅動呈現(xiàn)。每個組件將與來自時間源的時間同步地運行該呈現(xiàn)的一部分。
媒體信宿可有選擇地提供一時間源。通常，音頻呈現(xiàn)器將這樣做，且時間源上的時間將由機器上的音頻裝置確定，但其它媒體信宿也可這樣做。媒體源也可提供時間源。媒體會話確定哪個是“最高優(yōu)先級”的時間源，且該時間源被所有時鐘組件向它同步呈現(xiàn)的主呈現(xiàn)時鐘使用。
iv.呈現(xiàn)控制媒體會話將從媒體基本庫獲得對Preroll、Start、Stop、和Pause的調(diào)用。這些通常對應于媒體基本庫上的應用程序調(diào)用。
媒體會話將通過媒體基本庫給予的呈現(xiàn)時鐘來控制呈現(xiàn)。由于所有媒體信宿，啟動/停止/暫停呈現(xiàn)時鐘將導致所有信宿接收其通知并作適當反應。媒體會話通過直接調(diào)用其啟動/停止/暫停方法來啟動/停止/暫停媒體處理器。
在給定操作已由所有流完成之后，媒體會話將把一事件發(fā)送給媒體基本庫。
v.比特泵媒體會話驅動所有數(shù)據(jù)流從媒體處理器的流到流信宿。每個媒體信宿和流信宿對都與比特泵相關聯(lián)，它在啟動或預轉狀態(tài)時，以下列循環(huán)操作1.請求來自流信宿的樣本分配。
2.當樣本分配請求得到滿足時，請求媒體流用數(shù)據(jù)填充樣本。
3.當樣本填充請求得到滿足時，將樣本交給流信宿并請求另一樣本分配。
注意，在任何給定時間一個以上樣本可“在流傳中”。
vi.處理新呈現(xiàn)和輸出變化參見以上III.a.vi和III.a.vii。媒體會話負責把媒體處理器對將來呈現(xiàn)的通知轉發(fā)給媒體基本庫，并參與拓撲解析和激活。
IV.所需的最小媒體基本庫配置無疑地，媒體基本庫的最常見使用將是設立多媒體呈現(xiàn)的簡單回放。如在以上的“策略重要性”章節(jié)中所述，媒體基本庫的主要目標是使該設立非常簡單。
從應用程序的觀點而言，以下步驟描述應用程序至少必須做的事以便使用媒體基本庫來配置多媒體呈現(xiàn)a.創(chuàng)建一媒體基本庫。
b.創(chuàng)建一回放目標，向其中應呈現(xiàn)視頻的視窗提供一句柄。
c.調(diào)用IMFMediaEngine::OpenURL，向要呈現(xiàn)的多媒體文件提供一URL以及指向回放目標的一指針。
d.現(xiàn)在可使用IMFMediaEngine::Start/Stop/Pause API來回放多媒體呈現(xiàn)。
注意應用程序不需要等待任何事件到達；這些事件的處理是可選的。
V.附加服務的提供先進的多媒體應用程序將利用由媒體基本庫和媒體會話可用的廣泛和可擴展的服務范圍。這些通過使用由媒體基本庫展現(xiàn)的IMFGetService接口來訪問，該接口將返回由媒體基本庫、媒體會話、或使用中的媒體源、信宿或其它組件的任一個所展現(xiàn)的服務。
該服務體系結構是可擴展的，而以下是幾個示例a.速率支持和速率控制b.音頻的音量控制c.用于編輯情形的幀緩存支持d.視頻呈現(xiàn)器配置
權利要求
1.已例示其上用于將內(nèi)容從至少一源傳送到至少一信宿的受保護媒體路徑的一種計算裝置，其特征在于，所述受保護媒體路徑包括一媒體基本庫，提供所述計算裝置中的受保護環(huán)境，包括實現(xiàn)處理來自任何特定源的內(nèi)容并將所述已處理內(nèi)容傳送給任何特定信宿的核心組件的一公共基礎結構，并包括實施代表每個源的策略的策略引擎，所述策略對應于來自所述源的內(nèi)容并包括用于處理和呈現(xiàn)所述內(nèi)容的規(guī)則和要求，從而所述媒體基本庫使內(nèi)容能以受保護方式經(jīng)所述計算裝置流動，并允許所述受保護內(nèi)容在所述計算裝置中任意處理；與內(nèi)容的每個源相關聯(lián)和相對應的一源可信權限(SOTA)，每個SOTA擔當將所述源連接到所述媒體基本庫的安全加鎖箱并代表所述受保護媒體路徑中的源，如果必要解密來自所述源的所述內(nèi)容，并在必要時將與所述內(nèi)容相關聯(lián)的策略從原始格式翻譯成遵從策略引擎的格式；以及與內(nèi)容的每個信宿相關聯(lián)和相對應的一信宿可信權限(SITA)，每個SITA擔當將所述信宿連接到所述媒體基本庫的安全加鎖箱并代表所述受保護媒體路徑中的信宿，如果必要加密傳送到所述信宿的所述內(nèi)容，并在必要時將與所述內(nèi)容相關聯(lián)的策略從策略引擎格式翻譯成遵從信宿的格式，從而所述信宿接收所述內(nèi)容和相應策略，如果必要解密所述接收內(nèi)容，并基于所述接收策略呈現(xiàn)內(nèi)容。
2.如權利要求1所述的計算裝置，其特征在于，所述經(jīng)例示受保護媒體路徑的媒體基本庫還包括向所述計算裝置提供附加受保護功能的至少一補充組件。
3.如權利要求1所述的計算裝置，其特征在于，還例示其上的一媒體應用程序，它選擇要傳送的內(nèi)容、選擇用于通過所述受保護媒體路徑提供所述內(nèi)容的每個源、如果必要選擇用于通過所述受保護媒體路徑接收所述被提供內(nèi)容的每個信宿、驅使所述媒體基本庫根據(jù)每個選定源和每個選定信宿安排所述受保護媒體路徑。
4.如權利要求3所述的計算裝置，其特征在于，所述媒體應用程序向所述媒體基本庫提供傳送命令，以控制所述內(nèi)容從每個選定源到每個選定信宿的傳送。
5.如權利要求3所述的計算裝置，其特征在于，所述媒體基本庫防止所述媒體應用程序訪問所述受保護媒體路徑內(nèi)的內(nèi)容。
6.如權利要求3所述的計算裝置，其特征在于，所述媒體基本庫防止所述媒體應用程序對所述內(nèi)容采取違反與所述內(nèi)容相對應的所述策略的任何動作。
7.如權利要求1所述的計算裝置，其特征在于，僅當所述SOTA滿足所述媒體基本庫、其策略引擎、其每個使用組件的要求、且受保護媒體路徑的每個SITA是可靠的，并具有基于相應策略與所述內(nèi)容接觸的權限時，所述例示的受保護媒體路徑的每個SOTA允許其內(nèi)容通過所述受保護媒體路徑39傳送。
8.如權利要求7所述的計算裝置，其特征在于，任何單元可基于擔保所述單元的可接受權標的提供而被示為可靠的。
9.如權利要求8所述的計算裝置，其特征在于，任何單元可基于來自可接受擔保權威的可校驗數(shù)字證書的提供而被示為可靠。
10.如權利要求8所述的計算裝置，其特征在于，可靠單元受到信任來判定它是否可基于所述相應策略并基于它是否可遵從對應于所述內(nèi)容的所述策略與所述內(nèi)容接觸。
11.如權利要求8所述的計算裝置，其特征在于，可靠單元受到信任來真實地響應來自另一單元的基于權限的查詢。
12.一種通過計算裝置將內(nèi)容從源發(fā)送到信宿的方法，其特征在于，所述方法包括所述計算裝置上的應用程序用所述內(nèi)容、源、和信宿的定義來在所述計算裝置上調(diào)用媒體基本庫；所述媒體基本庫基于所述已定義的內(nèi)容、源和信宿建立受保護媒體路徑來實現(xiàn)該傳送，所述已建立的受保護媒體路徑包括所述媒體基本庫；與所述源相關聯(lián)和相對應的一源可信權限(SOTA)，所述SOTA擔當將所述源連接到所述媒體基本庫的安全加鎖箱并代表所述受保護媒體路徑中的源，如果必要解密來自所述源的所述內(nèi)容，并在必要時將與所述內(nèi)容相關聯(lián)的策略從原始格式翻譯成遵從策略引擎的格式；以及與所述信宿相關聯(lián)和相對應的一信宿可信權限(SITA)，所述SITA擔當將所述信宿連接到所述媒體基本庫的安全加鎖箱并代表所述受保護媒體路徑中的信宿，如果必要加密傳送到所述信宿的所述內(nèi)容，并在必要時將與所述內(nèi)容相關聯(lián)的策略從策略引擎格式翻譯成遵從信宿的格式，從而所述信宿接收所述內(nèi)容和相應策略，如果必要解密所述接收內(nèi)容，并基于所述接收策略呈現(xiàn)所述內(nèi)容；代表所述源的所述SOTA建立對所述受保護媒體路徑的信任；在對所述受保護媒體路徑建立的信任之后，所述SOTA傳播與要傳送到所述受保護媒體路徑的內(nèi)容相對應的策略；所述SOTA確定對通過所述受保護媒體路徑傳送的內(nèi)容要采取的特定類動作；所述SOTA判定對通過所述受保護媒體路徑傳送的內(nèi)容是否可采取特定類動作，并向所述媒體基本庫通知相關內(nèi)容；所述媒體基本庫通知所述應用程序是否可采取特定類動作，且如果是則通過命令所述媒體基本庫執(zhí)行這類動作繼續(xù)。
13.如權利要求12所述的方法，其特征在于，建立所述受保護媒體路徑的所述媒體基本庫包括選擇要處理和操作通過所述受保護媒體路徑傳送的內(nèi)容的核心組件的所述媒體基本庫，所述核心組件向所述媒體基本庫提供核心功能。
14.如權利要求13所述的方法，其特征在于，建立所述受保護媒體路徑的所述媒體基本庫還包括選擇要處理和操作通過所述受保護媒體路徑傳送的內(nèi)容的補充組件的所述媒體基本庫，所述補充組件向所述媒體基本庫提供補充功能。
15.如權利要求12所述的方法，其特征在于，建立對所述受保護媒體路徑的信任的所述SOTA包括所述SOTA建立對所述媒體基本庫的策略引擎的信任；所述受信任策略引擎建立對包括所述SITA的所述受保護媒體路徑的每個其它單元的信任。
16.如權利要求15所述的方法，其特征在于，建立對任何單元的信任包括接收擔保所述單元的可接受權標的提供。
17.如權利要求16所述的方法，其特征在于，建立對任何單元的信任包括接收來自可接受擔保權威的可校驗數(shù)字證書的提供。
18.如權利要求12所述的方法，其特征在于，所述SOTA傳播對應于要傳送到所述受保護媒體路徑的內(nèi)容的策略包括所述SOTA將策略傳播給所述媒體基本庫的策略引擎；所述策略引擎在必要時確定包括所述SITA的受保護媒體路徑的每個單元滿足所述策略。
19.如權利要求18所述的方法，其特征在于，如果所述策略引擎確定所述受保護媒體路徑的特定元素不滿足所述策略，所述策略引擎執(zhí)行從一組中選擇一個動作，所述組包括拒絕所述單元訪問所述內(nèi)容并防止內(nèi)容經(jīng)所述受保護媒體路徑傳送。
20.如權利要求12所述的方法，其特征在于，所述SOTA傳播對應于要傳送到所述受保護媒體路徑的內(nèi)容的策略包括所述SOTA將策略傳播給所述媒體基本庫的策略引擎；所述策略引擎將所述策略傳播給所述受保護媒體路徑中的SITA；以及所述SITA是遵從所述策略的所述受保護媒體路徑的受信任單元。
21.如權利要求12所述的方法，其特征在于，包括所述SOTA從所述SITA確定對通過所述受保護媒體路徑傳送的內(nèi)容要采取的特定類動作。
22.如權利要求12所述的方法，其特征在于，包括所述SOTA基于所述相應策略判定是否可采取特定類動作。
23.如權利要求12所述的方法，其特征在于，還包括所述SOTA以加密形式獲取來自所述源的所述內(nèi)容、解密所述經(jīng)加密內(nèi)容、并向所述媒體基本庫傳送所述經(jīng)解密內(nèi)容；所述媒體基本庫在必要時處理所述經(jīng)解密內(nèi)容，并向SIAT傳送所述經(jīng)處理內(nèi)容；以及所述SITA加密所述經(jīng)處理內(nèi)容，并將所述經(jīng)加密處理的內(nèi)容傳送給所述信宿。
全文摘要
一計算裝置已例示其上用于把內(nèi)容從源傳送到信宿的受保護媒體路徑。在該受保護媒體路徑中，媒體基本庫提供計算裝置中的受保護環(huán)境，包括實現(xiàn)處理來自任一特定源的內(nèi)容并將已處理內(nèi)容傳送到任一特定信宿的核心組件的公共基礎結構，還包括實施代表源的策略的策略引擎。該策略與來自源的內(nèi)容相對應，并包括用于訪問和呈現(xiàn)內(nèi)容的規(guī)則和要求，從而媒體基本庫允許內(nèi)容以受保護方式經(jīng)計算裝置流動，并允許在計算裝置中任意處理受保護內(nèi)容。
文檔編號G06F15/16GK1853178SQ200480003262
公開日2006年10月25日 申請日期2004年7月29日 優(yōu)先權日2003年10月23日
發(fā)明者J·M·阿科弗, C·諾爾頓, G·頓巴爾 申請人:微軟公司