TWI468969B - 授權對電子內容作存取的方法及授權對該電子內容執行動作之方法 - Google Patents

Description

授權對電子內容作存取的方法及授權對該電子內容執行動作之方法

本發明關係於數位權管理引擎系統與方法。

在現行電腦系統中，經常想要限制對電子內容、服務、及/或處理資源的存取、及/或只允許某些實體可以執行某些動作。已經有各種技術係針對此控制加以開發或提出。這些技術通常稱為數位權管理(DRM)技術，因為以名稱看來，其目標為管理各種實體在數位或其他電子內容、服務或資源中之權益。很多先前技藝的問題為它們係相當複雜、限制多、並沒有彈性、因而不能完成某些原來類型的關係與處理，及/或不能與其他DRM系統進行相互間之操作。

於此描述有關於改良DRM的系統與方法，其可以用以改善部份或所有之問題。應了解的是，本發明之實施例可以以各種方式加以實施，包含實施成為程序、設備、系統、裝置、方法、電腦可讀取媒體、及/或其組合。

用以控制對內容之存取的現行系統有時包含元件，其存取有關於授權存取電子內容的執照。然而，此等元件通常執行對有關於執照的權益管理資訊、鏈路或節點的鏈結或圖表執行僵硬的評估。它們常常不能適用於本質上不同 的授權設計及/或與某些DRM系統一起操作以授權對該內容的存取。本發明之實施例藉由儲存、使用及/或執行有關於該執照的其他常式或控制程式，來克服這些缺點，而提供動態授權特性、完成分散式授權資源、及/或流線存取功能。

再者，很多現行系統只有關於保有簡單授權/狀態有關資料的狀況。這些系統未能針對存取授權可能取決於多數層資料的狀況，例如，根據與其他節點相關之先前推出資料，來決定條件。本發明配合DRM控制程式，經由靜態資料庫的實施，而克服這些缺點，以提供安全之狀態儲存特性、提供一代一代之持續狀態資訊、或完成改良控制程式執行之讀寫功能、及/或執行更有效之存取授權。

其他現行系統可以實行DRM執照或結構，其包含涉及使用公鑰之元件，以保護執照元件。然而，有關於這些系統之缺點包含駭客可能偽造存取或執行執照所需之數位簽章，或者，探求存在於DRM執照結構中之相互關聯性。本發明之一或多數實施例可以經由實行包含使用特定保護鑰之執照物件的數位及/或互鎖簽章，而克服這些缺點。這些實施例之優點包含防止經由公鑰之未授權存取及由執照元件相互關聯性所推導之相關特性。

其他現行系統包含元件，其在第一實體與第二實體間完成鄰近決定，例如於兩權益管理實體間作鄰近決定。此等系統可能執行一些規則，例如藉由執行繁複之鄰近檢查程序，來表示一件保護內容不能被拷貝於某環境外。然而 ，這些系統之缺點為它們並無法在不妨礙鄰近檢查的效能下，對所保護內容提供安全性。本發明之實施例藉由提供精簡鄰近檢測協定而克服此與其他缺點，該協定經由有關於亂數及/或祕密種傳輸的特性加以保全。即使要求被截取，本案之一或多數實施例的相關優點包含可以使攻擊者很難取得密碼，來決定正確反應。

總結，有需要可以適當地授權對電子內容存取，同時也不會有太過複雜、限制過多及/或沒有彈性的技術之系統，也需要能完成某些原來類型關係與程序的系統、及/或需要能與其他DRM系統作相互間操作之系統。

以下將提供發明主體的詳細說明。雖然描述了幾個實施例，但應了解發明主體並不限定任一實施例，而是包含各種替代、修改及等效。另外，雖然各種特性細節係被說明中被說明，以提供對本發明主體的完整了解，但部份實施例可以沒有這些或所有細節下加以實施。再者，為了清楚起見，在本技藝中已知之技術內容並未加以詳細說明，以避免不必要地阻礙本發明主體。

A.群組(Octopus)架構

群組為一簡單、開放及彈性數位權管理(DRM)引擎，其可以為應用程式所使用以實施核心DRM功能。群組被設計以無縫地整合入網路服務環境中及任何主機環境或 軟體架構中。為了建立具有群組的完整客戶DRM，這些環境需要被實施與整合至群組引擎。在較佳實施例中，群組引係無關於特定媒體格式及加密協定，允許了設計者可以彈性如所需地使用標準或專有技術。為群組引擎所使用的管理模型很簡單，但可以用以表示智慧關係與商務模型。

有關於群組引擎架構的例示實施法的資訊係說明如下，包含參考實施法之資訊及樣品應用程式。該等段落被稱為群組物件、浮游生物(Plankton)、及潛水(Scuba)，並提供有關於群組引擎工具箱實施例之資訊。

1.簡介

第1圖顯示群組組件如何在使用DRM的網路中動作。如於第1圖所示，在一實施例中，群組引擎係內藏於主應用程式中。其執行特定DRM功能並依賴用於這些服務的主應用程式，該等服務可以為主機所有效提供，例如加密、解密及檔案管理。

群組建立DRM物件，其一起形成對該內容的執照條件。其也輸送鑰給主應用程式。

應注意的是，第1圖為群組組件可能被如何使用之一例子；群組DRM系統為有彈性的。引擎可以實現在小足跡(footprint)並可以容易地整合入各種類型的應用程式中。

2.了解DRM設定檔及群組物件

群組使用一組內容保護與管理物件，以代表在系統中之實體；保護內容；並將該內容與使用規則相關，並決定當被要求時是否核准存取。名詞DRAM設定檔係被用以代表在這些物件被定義於實際部署時所存在之語意上下文。

2.1.群組中之物件簡介

在一實施例中，群組引擎使用以下物件，這些係被更詳細說明如下：

2.2.節點物件

在一實施例中，在系統的每一實體可以以一節點物件代表。只有實體需要為鏈結物件所參考，或者為需要具有對應節點物件的加密目標資訊的接收者。實際上，節點通常代表使用者、裝置或一群體。節點物件也具有相關屬性，其代表有關於該節點的實體的某些特性。

例如，第2圖顯示兩使用者(Xan及Knox)、兩裝置(Mac與攜帶式裝置)、及幾個實體，其代表群體(例如凱莉(Mariah Carey)家族的會員、公立圖書館的會員、特定音樂服務的訂戶、RIAA許可之裝置、及由特定公司所製造之裝置)。這些的每一個將具有與之相關的節點物件。

2.3.鏈結物件

鏈結物件係為群組所用之已簽章物件，以顯示於兩節點間之關係。例如，在第2圖中之由Mac節點至Knox的鏈結顯示所有權。如同由凱莉家族節點至音樂服務用戶節點之鏈結般，由Knox至凱莉家族節點的鏈結顯示會員。在一實施例中，因為任一鏈結物件只表示於兩節點間之關係，所以，將花用十個鏈結物件以描述如第2圖所示之關係。

一圖表可以用以表示於節點間之關係。表示凱莉家族節點與音樂服務節點間關係之鏈結物件主張在圖中有一指向緣存在，圖中之頂點為凱莉家族與音樂服務節點。Knox及Xan為凱莉家族的會員。因為Knox被鏈結至凱莉家族及凱莉家族被鏈結至音樂服務，所以，在Knox與音樂服務間有一路徑。當有由另一節點到該音樂服務的路徑存在時，群組認為音樂服務節點可以由另一節點到達。這允許寫下一控制，其當要求存取之應用程式(例如群組DRM客戶主應用程式)被執行時，根據音樂服務可由該攜帶式 裝置到達的條件，而允許對受保護內容的存取。

鏈結物件也可以選用地包含部份加密資料，其允許群組使用該鏈結以導出內容鑰。如下所詳述，這對內容鑰提供富彈性之分散式方法。

在一實施例中，群組並未定義鏈結物件如何簽章也並未評估該證書。相反地，它會要求主系統以驗證該簽章，及任何可以使用之驗證系統。這允許系統架構者或管理者定義鏈結物件的壽命、喚醒它、等等。另外，也可以定義管理鏈結物件建立與壽命的政策。

2.4.更多有關節點物件

如前所述，在一實施例中，節點物件包含定義節點所代表之屬性。屬性的一例子為節點類型。除了代表使用者、群體、或裝置外，節點類型屬性也可以被用以代表其他實體。在部份實施例中，節點物件也可以包含加密鑰資訊，例如當使用群組節點與鏈結為主的“潛水”鑰資訊分佈系統。潛水鑰分佈系統將描述如下。

在部份實施例中，節點物件也包含一保密非對稱鑰對，其被用以針對已經存取節點物件的保密部份的次系統進行保密資訊。這也可以是節點所代表之實體(例如，音樂服務)或負責管理節點的其他實體(例如末端使用者(例如Knox)，用以負責管理他的攜帶式裝置)。

2.5.取得允許

當應用程式想要對一特定件內容執行一動作時，它首先會詢問該群組客戶引擎，以檢查是否其想要對該內容執行的動作是否被允許。在部份實施例中，群組引擎將由包含在含有內容執照的物件中之資訊中載入並執行有關於該內容的控制程式，並根據控制程式的決定，而允許執行該動作的核准與否決。允許通常需要符合部份條件，例如，一節點必須由要求節點所能到達的條件。

在一實施例中，如果核准允許，則節點必須取得內容鑰。該鑰係由執照的內容鑰物件取得，該內容鑰物件本身係由用以保護內容鑰物件的加密系統所保護。針對該目的，可以使用幾個不同加密系統，包含群組之內部鑰分佈加密系統，其平衡包含在節點與鏈結物件中之鑰。

2.6.內容保護與管理

在典型情形下，內容提供者使用應用程式，其包含有群組套裝引擎，以建立一組管理該內容使用的物件，並輸送取得內容加密鑰所需之資訊。為了容易解釋，名詞“執照”係被用以表示該組物件。

在一實施例中，內容與執照係被邏輯地分開，但為使用物件ID的內部參考所綁在一起。儲存在一起的內容與執照如有必要也可以分開存放。一執照可以應用至一項以上之內容，一個以上之執照也可以應用任一單項內容。

在一實施例中，一執照為物件的集合，如下：

‧內容鑰物件(包含加密鑰資料)

‧保護符物件(將內容綁至內容鑰物件)

‧控制物件(包含及保護控制程式)

‧控制符物件(綁住內容鑰物件與控制物件)

‧提供人類可讀取資訊的元資料，以描述為執照所需之條件。

第3圖顯示在執照中之物件的彼此關係及在一例示實施例中之內容物件。在第3圖所示之實施例中，控制物件與控制符物件係均被簽章，使得在給予主應用程式允許以存取內容前，群組客戶引擎可以驗證控制資訊係來自一信任源。

如第3圖所示，在一實施例中，內容被加密及為一內容物件所表示。被用之加密鑰係為內容鑰物件所表示，及在兩者間之束縛係為保護符物件所表示。如於第3圖所示，特有ID係被使用以促成於內容與內容鑰間之束縛。

管理用以解密內容的鑰的規則係為控制物件所表示。於內容鑰與控制間之用以管理其用途之束縛係以控制符物件表示，也再次使用與物件相關的ID來束縛它們。

2.6.1.內容物件

內容物件代表加密內容。在一實施例中，其格式與儲存係為內容類型與主應用程式所定義。套裝應用程式加密該等內容，並建立與管理該內容物件。群組設計允許系統架構者或管理者選擇所用之加密系統。在一實施例中，內容物件必須包含或參考一特有ID；該ID係被用以將內容 綁至其他物件。在一實施例中，套裝應用程式必須包含有能力以認出並處理內容本身(或取得可以提供該功能的服務)。在部份實施例中，這係藉由一結構檔案格式，例如MP4的選擇加以完成。

2.6.2.內容鑰物件

內容鑰物件描述並選用地包含用以加密該內容的鑰。當此物件包含內容鑰資料時，為了保密，該資料本身被加密。在一實施例中，內容鑰物件同時也指明用以加密內容鑰資料的加密系統；是否該資料包含在該內容鑰物件。內容鑰物件也為一特有ID所指明。在一實施例中，內容鑰物件，及其他於段落2.6所描述之物件係由群組套裝引擎所建立。

2.6.3.保護符物件

保護符物件將內容物件綁至內容鑰物件。其包含一或多數內容物件的ID及其所施加之內容鑰物件的ID。其也包含用以加密該內容的加密演算法上之資訊。

2.6.4.控制物件

控制物件為一簽章物件，其包含控制程式。該控制程式指明對於予以允許之內容的某些動作所必須符合之條件。控制物件同時也具有一特有ID。如上所述，控制物件被簽章，使得在作出任何決定前，群組可以驗證控制位元 組碼是否為有效與受信任的。當資訊可用時，控制物件的有效性也可以選用地經由包含在控制符物件中之安全散列(hash)的驗證加以導出。

2.6.5.控制符物件

控制符物件為一簽章物件，其參考一或多數內容鑰物件及一控制物件。群組使用為控制符物件所提供之資訊，找出哪一控制管理內容鑰物件的使用。

在一實施例中，因為控制物件同時也包含用於包含在其所參考的內容鑰物件中之每一鑰資料的散列值，所以，在鑰資料與內容鑰物件間之束縛並不能被迅速竄改。

控制符物件同時也包含促成控制物件完整性驗證的資訊。於一實施例中，控制符物件被簽章，使得群組可以信任在該內容鑰與管理它的控制物件間之束縛有效性，以及，在內容鑰ID與實際鑰資料間之束縛之有效性。或者，被參考的控制物件的散列也可以包含在控制符物件中，以允許群組推導出控制物件的有效性，而不必分開驗證該簽章。

2.6.6.元資料

部份物件將包含元資料，其協助應用程式了解到實際檢查什麼控制。

2.7.有關控制程式

在一實施例中，控制程式被包含在控制物件中，及群組使用一稱為“浮游生物(Plankton)VM”之虛擬機器，來執行這些控制程式。這些控制程式係為位元組碼格式，其促成在平台間之可交互運作性。

在一實施例中，浮游生物VM被設計以寄住在應用程式內，而不執行執行在一處理機中或作成積體電路。在一實施例中，控制程式可以被寫為組合語言並為浮游生物組合語言所轉換為位元組碼。在其他實施例中，可以使用模板，並開發權表示語言以配合群組。

在一實施例中，支援有控制程式，其根據關係及日期/時間，指明允許。

在一實施例中，群組規格書決定可以表示之條件；可以被允許的動作之特定實施。這兩者均表示於控制程式中。在一實施例中，動作係以名稱(例如“播放”)而特定給套裝介面。

以組合語言所表示之控制程式例係如下：

在浮游生物VM規格書及控制上的其他資訊係被提供如下。

2.8.實施法例

在一實施例中，當根據群組之DRM系統被實施時，DRM設定檔係被定義以描述使用節點物件、鏈結物件與執照的方式。加密系統也被定義，用以提供內容保護與保密性。另外，實施使用群組引擎的套裝及客戶(消費者)應用程式。在部份實施例中，也可以實施針對特定硬體及/或軟體平台的特定應用程式版的群組引擎。兩例示實施例 子係提供如下。

2.8.1.例子1：使用者、PC及裝置

假設想要實施一DRM系統，其將權力綁在對一特定使用者的播放內容，並想要使得使用者可以所有他所擁有的播放裝置上播放內容。假設決定提供使用者軟體使得使用者可以加至播放裝置上(例如行動播放器)。然而，假設想要設定部份政策以限制使用者可以傳送至一般目的裝置的次數，使得他們沒有作為散佈者的能力。

根據這些系統需求，例如，可能使得所建立給使用者的執照有所用途，並在使用者與其所用之裝置間建立一關係。

因此，在此例子中，首先決定需要建立何種關係的哪著節點。例如，需要界定以下各項：

‧使用者(擁有權力以使用該內容的個人)

‧PC(可以播放內容的軟體應用程式並指明其他播放裝置)

‧裝置(可以播放內容的硬體及/或軟體組合)。

一節點類型可以定義以用於這些項目的每一個。所建立的每一節點物件可以包含一類型屬性，其表示該物件是否代表一使用者、一PC或一裝置。

假設，例如決定限制任一使用者可以建立的PC節點物件之數量為4。只要提供PC數量上之限制，則不必限制裝置的數量。如果在使用者節點與要求存取之節點間建 立一關係，則控制程式可以據此設立以允許存取。然後，該節點可以為一PC或一裝置。

一種完成此功能的方式為建立一伺服器，來管理使用者並建立剛定義的屬性之群組物件。對於每一新使用者，伺服器將指定一使用者節點物件。對於每一PC，伺服器將指定一PC節點物件。在此時，伺服器將建立一鏈結物件，其將使用者節點物件鏈結至PC節點物件。使用者可以隨後要求增加其他PC，及伺服器將生效一政策，其限制每一使用者的PC節點物件的數量至4(典型將提供由其作動名單中移除PC的能力給使用者。一旦建立，該等物件將轉送給PC。只要該等物件保持有效，則在PC上之軟體將使用該等物件。

假設決定使用者能播放在他們所擁有的任意裝置上播放任何內容。也假設使用者下載內容至正執行PC軟體的PC，及軟體提供在該裝置上播放該內容的能力。為了完成此動作，PC軟體需要建立新裝置節點物件與鏈結物件的能力給該裝置，該鏈結物件將該裝置節點物件相關於該使用者節點物件。為了如此，PC軟體需要存取使用者節點的保密部份。裝置保有該鏈結物件並只有它有效時即使用它；即，一旦鏈結物件存在，就不必建立另一鏈結物件，除非該物件到期或變無效。

為了將內容綁至使用者，套裝應用程式選擇新ID用於該內容，並使用現行ID建立一加密鑰與相關內容鑰物件，及一保護符物件將內容物件與內容鑰物件綁在一起。 套裝程式然後建立具有一控制程式(例如編譯於浮游生物位元組碼中)之控制物件，並且，只有在使用者節點可以由要求播放動作之PC或裝置節點取得時，才允許發生“播放”動作。典型地，控制、控制符、保護符及內容鑰物件係適當地內藏在套裝內容中，使得PC與裝置並不必分開取得它們。

在一實施例中，當一裝置或PC想要播放內容時，群組尋找用於該內容的內容ID的保護符物件，然後，內容鑰物件為該保護符所參考，然後，控制符物件參考該內容鑰物件、最後，控制物件為該控制符所參考。群組執行該控制物件的控制程式，以檢查是否使用者節點可取得。如果裝置或PC節點具有必要之鏈結物件以驗證有其節點與使用者節點間有一路徑，則條件符合，及控制程式允許使用出現在該內容鑰物件中之鑰。裝置或PC的媒體描繪引擎然後可以解密並播放該內容。

2.8.2.例子2：暫時登入

在此例子中，使用了幾乎與例子1一樣的系統，另外加入一新特性：即一政策，其管理於PC節點物件與使用者節點物件間之鏈結物件之建立，只要使用者並未在另一PC上暫時登入，即允許不超出12小時之暫時登入。此特性將允許使用者將其內容帶至朋友的PC，登入在該PC一段時間，並在朋友的PC上播放該內容。

為了完成此功能，鏈結物件將以有限之有效性期加以 建立。在一實施例中，這將作動如下：為了簡單起見，我們假設需要播放DRM保護內容的消費軟體係在朋友的PC上。包含有該內容與執照的檔案被傳送至朋友的PC。當使用者想要播放該內容時，軟體認為沒有有效鏈結物件來鏈結本地PC節點物件與擁有該內容的使用者節點物件。它會提示使用者之憑證(可能是使用者名稱/密碼、行動電話鑑別、智慧卡、或任何允許該系統政策的鑑別系統)並與一後端系統相通訊。後端系統檢查鏈結所要之使用者節點物件與PC節點物件的屬性，並檢查有否正在作動之暫時登入鏈結物件。如果條件滿足，後端服務建立一鏈結物件，其鏈結該PC節點物件與該使用者節點物件，並將有效期限定至所要求之登入期(例如少於12小時，以符合此例子中之政策)。該鏈結物件隨即允許PC播放使用者內容，直到鏈結到期為止。

3.用於內容消耗及內容套裝之參考架構

以下為兩主要組件的參考架構說明，在部份實施例中，其完成了群組應用程式的佈署：￭消費應用(典型為媒體播放器)，其消費群組套裝內容；及￭套裝應用程式(典型內藏在伺服器上)，其包裝送至群組消費應用程式之內容。

3.1.群組DRM客戶參考架構

群組客戶參考架構提供一群組引擎將執行之功能的例子，用於消費內容的主應用程式。所開發之消費應用程式可以針對存取保護內容上或者可以為作動在使用者系統之一般目的應用程式也包裝內容的一部份。在各種實施例中，主應用程式可以執行部份或所有之以下事項：‧提供使用者介面，使用者要求對保護內容物件的存取可以藉由該使用者介面完成，並與使用者作成介面，以顯示有關於內容或錯誤資訊之元資料；‧管理與檔案系統之交互作用；‧認出保護內容物件的格式；‧要求DRM引擎以評估作成該執照的DRM物件(包含執行控制程式)，以檢查是否可以核准對該內容的存取；‧驗證所需之簽章，並處理DRM引擎所需要執行之任何其他之一般目的加密功能(例如，使用加密服務)；‧要求DRM引擎，以提供鑰給保護內容；及/或‧解密並與媒體描繪服務互動，以描繪該內容。

在一實施例中，DRM客戶引擎評估DRM物件，確認或否決許可，並提供鑰給該主應用程式。

第4圖顯示在一實施例中，完成群組為主之消費應用程式的元件。如於第4圖示，主應用程式為客戶的邏輯中心點。其負責驅動與其他模組間之相互作用，及經由一使用者介面與使用者互動。

主應用程式提供一組服務至群組引擎。第4圖表示用 以完成此之介面“主服務”。主服務允許群組引擎取得對主應用程式所管理之資料與為主機所實施之某些資料庫功能的存取。在一實施例中，其係群組引擎的唯一向外介面。

在一實施例中，群組引擎並不直接與為主應用程式所管理的多媒體內容相互作用。主應用程式邏輯地與內容服務交互作用，以存取多媒體內容，並只有傳送必須為該引擎所處理的部份資料至群組引擎。其他與內容的交互作用將為多媒體描繪引擎所執行。內容服務係負責自媒體伺服器取得內容，並儲存與管理儲存在客戶持久儲存體上之內容。

在第4圖所示之實施例中，媒體描繪引擎係為負責存取多媒體內容並描繪它(例如在視訊及音訊輸出上)之次系統。媒體描繪引擎自群組引擎接收部份資訊(例如內容解密鑰)，但在一實施例中，群組引擎並未與之直接互動。

為群組DRM引擎所需之部份資訊將可帶內取得多媒體內容，並將透過內容服務加以取得與管理，但部份之資訊可能需要經由其他服務裝置取得，例如個人化服務或會員制服務。

在第4圖所示之實施例中，加密操作(例如加密、簽章驗證等等)係為加密服務方塊所處理。群組引擎並未直接與之互動，而是經由會傳送要求的主機服務。加密服務也可以為媒體描繪引擎所使用，以執行內容解密。

3.1.1.至群組引擎介面的主應用程式

雖然在較佳實施例中，並沒有固定API用於群組引擎，但以下為在一例示實施例中，群組引擎所提供至主應用程式的介面類型的高階描述：

Octopus：CreateSession(hostContextObject)→Session

建立交談給予一主應用程式上下文。上下文物件係為群組所使用以對應用程式進入回呼(callback)

‧Session：：ProcessObject(drmObject)

當主應用程式在媒體檔案內遇到某類型物件，其可以被指明屬於DRM子系統時，此功能應為主應用程式所呼叫。此等物件包含內容控制程式，會員符記等等。這些物件的語法與語意對於主應用程式為不透明。

‧Session：：OpenContent(contentReference)→Content

當主應用程式需要與多媒體內容檔案進行互動時，主應用程式呼叫此功能。群組引擎送回隨後可用之內容物件，用以取回有關於該內容的DRM資訊，並與之互動。

‧Content：：GetDrmInfo()

送回有關內容的DRM元資料，否則該內容不能在該檔案的正常元資料中使用。

‧Content：：CreateAction(actionInfo)→Action

當想要與內容物件互動時，主應用程式呼叫此功能。ActionInfo參數指明應用程式需要執行之動作類型(例如播放)，並且，如有必要是任何相關參數。

‧Action：：GetKeyInfo()

送回解密次系統所需要解密該內容的資訊。

‧Action：：Check()

檢查是否DRM次系統將授權此動作之執行(即是否Action：：Perform()將成功)。

‧Action：：Perform()

執行該動作，並執行為管理此動作之規則所指明之結果(及其副作用)。

3.1.2.群組引擎至主服務介面

以下為在一例示實施例中，由主應用程式之群組引擎所需之主服務介面的類型例：‧HostContext：：GetFileSystem(type)→FileSystem

送回DRM次系統所專用之虛擬檔案系統物件。此虛擬檔案系統將被用以儲存DRM狀態資訊。在此檔案系統中之資料應可為DRM次系統所讀取及寫入。

‧HostContext：：GetCurrentTime()

送回為主系統所維持之現行日期/時間。

‧HostContext：：GetIdentity()

送回此主機的特有ID。

‧HostContext：：ProcessObject(dataObject)

將一資料物件送回主機服務，該物係已經被內藏在DRM物件內，但DRM次系已經被指明為主機所管理(例如證書)。

‧HostContext：：VerifySignature(signatureInfo)

檢查在資料物件上之數位簽章的有效性。在一實施例中，signatureInfo物件保有等效於在XMLSig元件中所找到之資訊的資訊。Host服務負責驗證該簽章的鑰與鑰證書。

‧HostContext：：CreateCipher(cipherType,keyinfo)→Cipher

建立一DRM次系統可以使用之加密物件，其可以加密並解密該資料。最小組之加密類型將被定義，及用於每一描述為加密實施法所需之鑰資訊的格式。

‧Cipher：：Encrypt(data)

‧Cipher：：Decrypt(data)

‧HostContext：：CreateDigester(digesterType)→Digester

建立一DRM次系統可以使用之消化物件，以計算在部份資料上之安全散列。在一實施例中，可以定義最小組消化類型。

‧Digester：：Update(data)

‧Digester：：GetDigest()

3.1.3.UML時序圖

第5圖顯示使用在前述段落中所述之例示API，及在例示實施例中，發生於主應用程式與DRM客戶引擎間之互動。

3.2.套裝參考架構

群組套裝參考架構提供群組套裝引擎可以執行套裝內容用於主應用程式的功能例子。套裝應用程式可以針對所開發之套裝或操作於使用者系統之一般目的應用程式，以存取保護內容(本地套裝或在網路的其他處)。

在一實施例中，套裝主機應用程式：‧提供部份使用者介面，內容及執照資訊可以藉由該介面指明；‧加密內容，及/或‧建立一內容物件，其包含或參考內容並包含或參考一執照(在套裝引擎建立構成執照的DRM物件後)。

第6圖顯示在一實施例中，作成群組為主套裝應用程式的元件。在一實施例中，套裝引擎負責套裝例如在此所述之物件(稱為群組執照)。執照係相關於元資料，該元資料以人可以讀取之方式解釋執照。

如上所述，在一實施例中，主應用程式提供使用者介面。其負責取得例如內容參考及使用者想要執行之動作之資訊(例如，將內容束縛至誰)。其也顯示有關例如執照發出文字之套裝程序有關之資訊，並且，如果發生故障，則故障理由。在部份實施例中，為主應用程式所需之資訊可能需要使用其他服務，例如鑑別或經由服務存取點(SAP)之鑑別及會員鑑定。因此，在部份實施例中，主應用程式可能需要執行部份或所有之以下服務：‧媒體格式服務：此元件負責管理所有媒體格式操作 ，例如資料格式轉換及套裝。其也負責內容加密，其可以經由內容加密服務完成。

‧一般目的加密服務：此元件係負責發出/驗證簽章及加密/解密部份資料。此等操作的要求可以為服務存取點所發出或由群組套裝引擎經由主服務發出。

‧內容加密服務：此模組邏輯上與一般目的加密服務分開，因為其並不知道該應用程式。其係為在內容套裝時之媒體格式服務，以一組事先為群組套裝引擎所發出之鑰加以驅動。

3.2.1.主應用程式至群組套裝引擎介面

此段落提供於主應用程式與群組套裝引擎間之例示API的高階描述。在一實施例中，套裝及客戶引擎儘可能使用相同物件。

Octopus：CreateSession(hostContextObject)→Session

建立交談給予一主應用程式上下文。上下文物件係為群組套裝引擎所使用以對應用程式進入回呼(callback)。

‧Session：：CreateContent(ContentReferences[])→Content

主應用程式呼叫此功能，以建立在後續步驟中之與執照物件有關的內容物件。一旦在內容參考陣列中超出一個內容參考，則表示這些係被束縛在一束中(例如一音訊及一視訊軌)及所發出之執照應送至這些參考，作為不可分 割之群。

‧Content：：SetDrminfo(drmInfo)

drumInfo參數指明將被發出之執照的元資料。該結構將被讀取並作為一導引，以計算執照成為用於浮游生物VM的位元組碼。

‧Content：：GetDRMObjects(format)→drmObjects

當主應用程式準備取得套裝引擎所建立的drmObjects時，此功能被呼叫。格式參數將指示期待用於這些物件的格式XML或二進制基元)。

‧Content：：getKeys()→keys[]

當主應用程式需要鑰時，此功能為主應用程式所呼叫，以加密該內容。每一內容參考具有一鑰。

3.2.2.群組套裝引擎至主服務介面

以下為在一實施例中，群組套裝引擎需要主應用程式提供之介面的類型例子。

-HostContext：：GetFileSystem(type)→FileSystem

送回一虛擬檔案系統物件，該物件為DRM次系統所專門存取。此虛擬檔案系統將被用以儲存DRM狀態資訊。在此檔案系統內之資料應只為DRM系統所讀取與寫入。

-HostContext：：GetCurrentTime()→Time送回為主系統所保持之現行日期/時間-HostContext：：GetIdentify()→ID 送回此主機的特有ID。

-HostContext：：PerformSignature(signatureInfo,data)

為群組套裝引擎所建立之部份DRM物件將受到信任。此為主機所提供之服務將被用以簽章所指定物件。

-HostContext：：CreateCypher(cipherType,keyInfo)→Cipher

建立一加密物件，其可以為套裝引擎所用以加密與解密資料。這可以用以加強在ContentKey物件內之內容鑰資料。

-Cipher：：Encrypt(data)

-Cipher：：Decrypt(data)

-HostContext：：CreateDigester(digesterType)→Digester

建立一消化物件，其可以為套裝引擎所用以計算部份資料的安全散列。

-Digester：：Update(data)

-Digester：：GetDigest()

-HostContext：：GenerateRadomNumber()

產生一亂數，其可以用以產生一鑰。

3.2.3.UML序向圖

第7圖顯示在前述段落中所述之例示API的使用，及發生在主應用程式與套裝引擎間之互動。

B.潛水鑰分配

潛水為一鑰分配系統，其很自然地配合上述之群組架構，及/或可以用於其他上下文。

以此潛水，除了建立在節點物件間之關係的主要目的外，群組鏈結物件也可以用以分配鑰。一群組控制物件包含一控制程式，其決定是否一要求動作應被核准。該控制程式經常檢查一特定群組節點可否經由集合一群組鏈結加以完成。潛水使得可以利用一群鏈結以促成鑰的分配，使得其可以為正執行控制之群組引擎所用。

於一實施例中，每一用於使用潛水鑰分配系統之群組佈署的群組節點物件具有潛水鑰。這些鑰係用以解密內容鑰及其他節點的潛水鑰。每一個建立以用於相同佈署的群組鏈結物件包含部份加密潛水資料酬載，當鏈結的鏈為群組引擎所處理時，此等酬載允許鑰資訊被推導出。

以具有此方式承載潛水鑰的節點與鏈結，假定由節點A至節點Z的鏈結集合，任何存取A的私潛水鑰的實體(例如一客戶主應用程式的群組引擎)也存取Z的公潛水共享鑰。一旦存取Z的私潛水共享鑰，則使實體存取以這些鑰加密的任何內容鑰。

1.節點、實體及潛水鑰 1.1.實體

在群組系統之實施例中，節點為資料物件，不是在系統中之作動參與者。在此上下文中，作動參與者被稱為實 體。實體的例子為媒體播放器、裝置、內容套裝等等。實體典型具有與之相關之群體節點。消費內容的實體使用群組引擎並管理構成群組個性之至少一節點物件。在此實施例中，一實體被假設已經存取其所管理之節點物件的所有資料，包含所有這些物件的私人資訊。

1.2.節點

參與潛水鑰分配系統之節點物件包含潛水鑰係為資料的一部份。在一實施例中，有兩種通用類型之潛水鑰：共享鑰與保密鑰。以下段落列出在各種實施例中，潛水可以使用之不同鑰類型。然而，可以了解的是，該技術的特殊佈署只使用一次組的這些鑰。例如，一系統可以被架構只與該等配對鑰一起動作，省略其他祕密對稱鑰的使用。或者，如果系統只需使用共享鑰，則系統可以被佈署而未提供保密鑰給節點。

1.2.1.共享鑰

共享鑰係為配對鑰及/或對稱鑰，其係為一節點所有所節點所共享，其包含潛水鑰推導延伸符。

‧潛水共享公鑰

Kpub-share〔N〕

這是一對公/私鑰的公共部份作為公鑰加密。此鑰典型有一證書，使得其憑證可以為想要加密束縛保密資訊的實體所驗證。

‧潛水共享私鑰

Kpriv-share〔N〕

這是公/私鑰對的私部份。管理該節點的實體係負責確保此私鑰保持祕密。為此，此私鑰將大致與其他節點資訊被分開儲存及傳送。此私鑰將為下游的其他節點透過鏈結的鑰推導延伸符加以共享。

‧潛水共享對稱鑰

Ks-share〔N〕

此鑰與一對稱加密符一起使用。至於私鑰，此鑰為保密，因此，管理節點的實體係負責為此鑰保密。此密鑰將為下游其他節點透過鏈結的鑰推導延伸符加以共享。

1.2.2.保密鑰

保密鑰係為配對鑰及/或對稱鑰，其係只為管理該節點的實體所知它們屬於誰。於這些鑰與上述共享鑰間之差異係為它們將不會為其他節點透過鏈結中之潛水鑰推導延伸符加以共享。

‧潛水保密公鑰

Kpub-conf〔N〕

這是用於公鑰加密符之一對公/私鑰的公部份。此鑰典型有一證書，使得其憑證可以為想要加密地束縛保密資訊的實體所驗證。

‧潛水保密私鑰

Kpriv-conf〔N〕

這是為公/私鑰對的私部份。管理該節點的實體係負責保守此私鑰的祕密。為此理由，此私鑰將與其他的節點資訊分開儲存與傳送。

‧潛水保密對稱鑰

Ks-conf〔N〕

此鑰可以與一對稱加密符一起使用。至於私鑰，此鑰為保密，使得管理該節點的鑰負責保密此鑰。

2.加密元件

潛水可以使用不同加密演算法加以實施。潛水並不限定於任何特定選擇之加密演算法。再者，對於一給定佈署或分佈，所有參與實體大致需要配合一組支援之演算法。在一實施例中，佈署包含用於至少一公鑰加密符(例如RSA)及一對稱鑰加密符(例如AES)之支援。

以下表示號將用以參考加密功能：￭Ep(Kpub〔N〕，M) 表示“使用公鑰加密符，以節點N之公鑰Kpub加密的信號M”

￭Dp(Kpri〔N〕，M) 表示“使用公鑰加密符，以節點N之私鑰Kpriv解密的信號M”

￭Es(Ks〔N〕，M) 表示“使用對稱鑰加密符，以節點N之對稱鑰Ks加密的信息M”

￭Ds(Ks〔N〕，M) 表示“使用對稱鑰加密符，以節點N之對稝鑰Ks解密的信息M”

3.內容鑰的目標

用於潛水中之加密目標有兩類型。將一內容鑰對準目標群組節點共享鑰表示使該鑰為所有實體所用，以共享該目標節點的私潛水鑰。將一內容鑰對準節點的保密鑰表示使得該鑰只為該節點所用。對準目標係藉由使用一或兩個以下之方法，將承載於ContentKey物件中之鑰CK加以完成。

‧公束縛：建立ContentKey物件，其包含Ep(Kpub〔N〕，CK)

‧對稱束縛：建立ContentKey物件，其包含Es(Ks〔N〕，CK)

在一較佳實施例中，對稱束縛係被儘可能地使用，因為其使用較少的密集計算的演算法，因此，對接收實體有較少之困擾。然而，建立ContentKey物件的實體(典型內容套裝)並不會一直存取Ks〔N〕。在此例子中，使用公共束縛，因為Kpub〔N〕應該可用，因為它並不是保密資訊。Kpub〔N〕將為需要針對內容鑰的實體所用，其跟隨著一證書，其可以為該實體所檢視以決定是否Kpub〔N〕實際為可以信任的節點之鑰，以依據部份同意政策處理內容。

4.使用鏈結之潛水鑰的推導

為了允許實體由個性節點可取得所有節點的潛水共享鑰，鏈結物件包含一潛水延伸符酬載。該酬載允許任何已 “由”節點存取鏈結的私/密潛水鑰至已存取鏈結私/密潛水鑰“至”節點。以此方式，一實體可以解密任何針對一個性節點可到達的節點的內容鑰(如果目標係使用目標節點之共享鑰)。

當群組引擎處理鏈結物件，其處理每一鏈結的潛水酬載，以更新潛水鑰的內部鏈至其已存取者。

在一實施例中，由節點F至節點T的一鏈路L的潛水延伸符酬載係由以下任一所構成：‧公共推導資訊：Ep(Kpub-share〔F〕，{Ks-share〔T〕，Kprive-share〔T〕})或‧對稱推導資訊：Es(Ks-share〔F〕，{Ks-share〔T〕，Kpriv-share〔T〕})其中{Ks-share〔T〕，Kpriv-share〔T〕}為資料結構，其包含Ks-share〔T〕及Kpriv-share〔T〕。

公共推導資訊係被用以輸送節點T的私潛水共享鑰Ks-share〔T〕及Kpriv-share〔T〕至已經存取節點F的私潛水鑰Kpri-share〔F〕的任一實體。

對稱推導資訊係用以輸送節點T的私潛水共享鑰Ks-share〔T〕及Kpriv-share〔T〕至已經存取節點F的對稱潛水共享鑰Ks-share〔F〕的任一實體。

至於將內容鑰對準至節點，較佳包含在鏈結的酬載為對稱推導資訊。這是當鏈結建立符已經存取Ks-share〔F 〕時為可能。如果不是，則鏈結建立符將下降至包含公共推導資訊作為鏈結的潛水酬載。

假設處理此鏈結的群組引擎已經在其內部潛水鑰鏈中具有Ks-share〔F〕及Kpriv-share〔F〕，在處理鏈結L〔F->T〕後，其將在鑰鏈上具有Ks-share〔T〕及Kprive-share〔T〕。

在一實施例中，因為群組鏈結可以以任何順序加以處理，所以群組引擎可能不能在鏈結L被處理時作鑰推導計算。這是由於在該時間，潛水鑰鏈可能不包含該鏈結的“自”節點的潛水鑰。在此時，當新資訊變成可為群組引擎所用時，鏈結被記住，及再次被處理。新資訊通常在處理新鏈結P後可用，鑰推導步驟將鏈結L的“自”節點的私潛水共享鑰加至鑰鏈結(此發生於當鏈結P的“至”節點與鏈結L的“自”節點相同，及鏈結P的“自”係為可到達節點)。

第8圖顯示在一實施例中，使用鏈結之潛水鑰的推導。

5.範例資料結構 5.1.潛水鑰

6.簽章

潛水鑰可以出現在不同上下文中。例如：

-節點：潛水鑰包含平文字鑰並需要被簽章作為節點物件的一部份(如果被載於內部延伸符中的話)。注意在一實施例中，潛水私及密鑰從未包含在節點的內部延伸符，而是包含在外部延伸符中。

-鏈結：潛水鑰包含點“至”節點的共享鑰。在一實施例中，在此上下文中，潛水鑰延伸符並未簽章作為物件的一部份(如果承載在內部延伸符內)，並且，如果承載於外部延伸符中，延伸符並未被簽章。

C.群組物件

此段落描述基本物件，其係為群娋之例示實施法之建構方塊。首先，一相當高階圖顯示群組所使用以內容保護與管理之物件的類型，及它們係如何彼此相關。再者，提供這些物件的更詳細說明與它們所傳輸的資訊。最後，提供用於規則條件、身份及鑰管理的實施例中所用之物件的說明。

1.內容保護及管理物件

第9圖為依據群組的實施例之各種內容保護與管理物件。內容管理物件為用以保護內容與保護內容相關的使用規則(控制)的物件。

為內容物件所代表之資料係為一鑰所加密。該鑰係為一內容鑰物件所代表，在內容與用以加密之鑰間之束縛係為保護符物件所代表。管理解密內容之鑰的規則係為控制物件所代表，及於內容鑰與用以管理其使用之控制間之束縛係為控制符物件所表示。在一實施例中，所有受信任之系統將只在控制物件中之位元組碼所表示之規則的管理下，使用內容解密鑰。

1.1共同元件

在一實施例中，所有群組物件共享共同基本特質：他們可以個別具有一ID、一列屬性、及一列延伸符。

1.1.1.ID

可以為其他物件所參考的物件具有特有之ID。在一實施例中，ID係為簡單之URI，及在群組中之習慣為URI及URN。

1.1.2.屬性

屬性為分類值。屬性可以有名字或無名字。有名字的屬性之名字為簡單字串或URI。值或屬性為一簡單類型( 字串、整數及位元組陣列)或一混合類型(名單或陣列)。

類型“名單”的屬性包含一未排序列之名字屬性。類型“陣列”的屬性包含已排序陣列之無名字屬性。

物件的“屬性”欄係為(可能空的)一未排序集合之有名字屬性。

1.1.3.延伸符

延伸符係為可以被加至物件之元件，以承載選用或備之額外資料。延伸符被分類，並具有特有ID。延伸符可以是內部或外部。

1.1.3.1內部延伸符

內部延伸符被包含在它們延伸的物件中。他們具有一“重要”旗標，其指示是否用於該延伸符之特定延伸資料類型需要被使用該物件的實施法所知道。在一實施例中，如果一實施法遭遇一具有重要延伸符之物件與一其所不了解的資料類型，則它們必須退回整個物件。

在一實施例中，內部延伸符的ID需要為內部特有的：一物件不能包含有相同ID的兩延伸符，但有可能兩不同物件包含有與其他物件延伸符相同的ID的延伸符。

物件的“延伸符”欄(可能是空的)為內部延伸符的未排序集合。

1.1.3.2.外部延伸符

外部延伸符並未包含在它們所延伸的物件中。它們獨立於物件之外出現，並具有“主題”欄，其包含它們所延伸之物件之ID。在一實施例中，內部延伸之ID需要為全球特有。

1.2.內容

在一實施例中，內容物件為“外部”物件。其格式與儲存並未為群組所控制，而是在主應用程式(例如，可能是MP4電影檔、MP3音樂軌跡等等)之內容管理次系統所控制。在一實施例中，內容的格式需要提供將ID相關於內容酬載資料的支援。內容酬載係以格式相關之方式加密(典型以一對稱加密符，例如AES)。

1.3.內容鑰

內容鑰物件代表一特定加密鑰，並以一ID與之相關。ID的目的為使得保護符物件與控制符物件參考內容鑰物件。包含在內容鑰物件中之實際鑰資料係被本身加密，使得其只可以為授權以解密該內容的接收者所讀取。內容鑰物件指明哪一加密系統被用以加密鑰資料。用以保護內容鑰資料的加密系統被稱為鑰分配系統。可以使用不同鑰分配系統。鑰分配系統的例子為上述潛水鑰分配系統。

1.4.保護符

保護符物件包含資訊，其允許群組找出哪一鑰被用以加密內容物件的資料。其也包含哪一加密演算法被用以加密該資料的資訊。在一實施例中，保護符物件包含一或多數ID，其係為內容物件所參考，並且，參考內容鑰物件代表用以加密該資料的鑰。如果保護符指向一個以上之內容物件，則這些內容物件代表已經使用相同加密演算法及相同鑰所加密的資料。

1.5.控制

當為主應用程式所要求時，控制物件包含資訊以允許群組作出有關是否在內容上之某些作動應被允許否的決定。在一實施例中，管理內容鑰的使用之規則係被編碼於控制物件中，作為浮游生物位元組碼。控制物件同時具有一特有ID，使得它可以為控制符物件所參考。在一實施例中，控制物件被簽章，使得在其作出任何決定前，群組可以驗證控制位元組碼為有效及受信任。當該資訊可用時，控制物件的有效性同時也可以選用地經由驗證包含在控制符物件中之安全散列加以推導出。

1.6.控制符

控制符物件包含資訊，其能允許群組找出哪一控制管理為內容鑰物件所代表之一或多數鑰的使用。它包含資訊，以將之束縛至內容鑰物件，及它所參考的控制物件。在一實施例中，控制符物件係被簽章(藉由套裝應用程式， 其具有一證書，以允許其簽章控制符物件)，使得群組可以信任於內容鑰與管理它的控制物件間之束縛的有效性，及於內容鑰ID與實際鑰資料間之束縛的有效性。控制符物件的簽章可以是一公鑰簽章或對稱鑰簽章，或兩者之組合。同時，當為控制符物件所參考的控制物件的消化包含在該控制符物件時，控制物件的有效性可以被推導出，而不必分開驗證控制物件的簽章。

1.6.1.對稱鑰簽章

這是用於控制符物件的最常用類型簽章。在一實施例中，此類型之簽章係藉由計算控制符物件的MAC(信息鑑別碼)加以實施，以相同於內容鑰物件所代表之鑰加以加鑰。於一實施例中，此MAC的標準方法係使用與選擇用於相同群組佈署的其他加密演算法的相同散列演算法之HMAC。

1.6.2.公鑰簽章

此類型之簽章係當控制符物件的簽章者的身份需要知道時被使用。此類型的簽章係以公鑰簽章演算法加以實施，以主張此物件有效性的人員的私鑰加以簽章。在一實施例中，當使用此類型的簽章時，對稱鑰簽章將出現，及簽章控制符物件與公鑰簽章，使得其可以保證以其私鑰簽章的人員已經認可承載在內容鑰物件中之內容鑰的實際值。

2.規則條件、身份及鑰管理物件

第10圖顯示各種依據群組實施例之規則條件、身份及鑰管理物件。節點物件代表在DRM設定檔中之實體。在一實施例中，群組並沒有節點物件所代表的暗示或明示語意。使用群組之系統的一給定佈署(DRM設定檔)將定義存在什麼類型之人員，以及，不同節點物件所代表之什麼角色與身份。語意資訊典型使用節點物件的屬性加以表示。

鏈結物件代表於節點間之關係。鏈結物件可以選擇地包含其他加密資料，以允許群組使用鏈結用於內容鑰推導計算。如同於節點般，在一實施例中，群組並沒有暗示或明示語意表示鏈結關係意思。取決於“自”及“至”鏈結的節點代表一給定DRM設定檔，鏈結關係的意思可以表示為會員身份、所有權、協會、及很多其他類型的關係。在典型DRM設定檔中，部份節點物件代表使用者、其他節點代表裝置、還一部份節點代表使用者群體或授權域(AD)。在該情形中，於裝置與使用者間之鏈結可能代表所有權關係，及於使用者與使用者群體或AD間之鏈結可能代表會員身份關係。

2.1.節點

節點物件代表在該系統中之實體。該節點物件的屬性定義節點物件代表的某些態樣，例如在DRM設定檔中之上下文中之節點物件所代表之角色或身份。節點物件也具 有一保密非對稱配對鑰，其係用以將保密資訊作為給已經存取節點物件(典型，為節點所代表之實體，或負責管理該節點的部份實體)的保密份之次系統為目標。目標針對一節點的保密資訊將以該節點的保密公鑰加以加密。或者，當系統使用一內容鑰推導系統，用於例如上述之內容鑰分配時，可以使用一內容保護非對稱配對鑰及內容保護對稱鑰配合上鏈結物件。

2.2.鏈結

鏈結物件為一簽章主張，其中在圖中存在一指向緣，其頂節點為節點物件。對於一給定組節點與鏈結，如果在圖中之節點X頂點與節點Y頂點間有一指向路徑，則認為在節點X與節點Y間有一路徑。當節點X與節點Y間有一路徑，則認為節點Y係由節點X可到達。因此，這些由鏈結物件所代表之主張係用以表示哪些節點係可以由其他節點所到達。在允許執行動作前，管理內容物件的控制可以檢查是否某些節點係可以由有關於執行動作的實體的節點所到達。例如，如果節點D表示一裝置想要在內容物件上執行“播放”動作，則管理此內容物件的控制可以測試是否某一節點U代表某一使用者係可以由節點D到達。為了決定節點U是否為可到達，群組將檢查是否存在一組鏈結物件，其可以建立於節點D與節點U間之路徑。

在一實施例中，在群組使用鏈結物件前，群組先驗證它但，以決定在節點圖中之路徑之存在。取決於用以簽章 鏈結物件的證書系統(例如，x509v3)之特定特性，鏈結物件可以給定有限之壽命，被廢止、等等。在一實施例中，管理哪些實體可以簽章鏈結物件、哪些鏈結物件可以被建立之政策、以及，鏈結物件的壽命未直接為群組所處理。相反地，存在於群組範圍外的政策，將典型對節點屬性資訊有影響力。為了促成加強某些政策的任務，在一實施例中，群組提供一種方法以延伸標準證書格式具有其他侷限檢查。這些延伸符有可能表示簽章鏈結的鑰之證書上之有效性侷限，使得例如鏈結正連接之節點什麼類型及其他屬性可以在鏈結為群組所認為有效前加以檢查。

在一實施例中，鏈結物件可以包含一控制物件，其可以被用以侷限鏈結的有效性。另外，在一實施例中，鏈結物件可以包含潛水加密資料，其提供使用者以節點的內容保護鑰，用於鑰分配。除了元資料外，該加密資料將包含“自”節點的私及/或對稱內容保護鑰，其被加密以“至”節點的內容保護公鑰及/或內容保護對稱鑰。

3.使用模式

在一實施例中，因為群組並未明示或暗示附著至這些基本物件上的語意，使用群組的系統將需要參與用於這些物件的一或多數使用模式，它們會將這些物件置於語意上下文中。我們稱這些語意上下文為DRM設定檔。在此時，我們認為群組物件為DRM樂高積木塊，其係用以建立DRM系統。

4.資料結構

以下段落更詳細說明用於上述物件的例示物件模型，定義在一例示實施例中，每一類型物件所擁有的欄位。

這些資料結構係使用相當簡單的物件描述語法加以描述。每一物件類型係為一可以延伸一母班級(即“一”關係)的班級所定義。班級描述係以簡單抽象類型“字串”(字元串)、‘int’(整數值)、‘byte’(8位元位元組值)、及‘boolean’(真或假)表示，但並未定義這些資料類型的任意特定編碼，或包含這些類型的合成結構。物件編碼、或呈現的方式可以取決於引擎的實施法加以改變。典型地，群組使用的給定模式將指明欄位係如何呈現(例如，使用XML設計)。

在一例示實施例中，使用以下表示法：

4.1.共同結構

在一例示實施例中，使用以下共同結構：

4.1.1.屬性

在一實施例中，有四種屬性：整數屬性、字串屬性、位元組陣列屬性、及名單屬性，每一個具有名字與類型。

4.1.2.延伸符

在一實施例中，有兩延伸符：

￭內部延伸符：承載於群組內

￭外部延伸符：承載於群組外

重要的是可以在如果某特定類型的延伸資料並不是一給定實施法所了解時，能驗證Octojbect的簽章。這就是為何在一實施例中加入與資料消化欄位間接有關之一階。如果此延伸資料的規格書指示該資料為特定Octobject上下文內之簽章的一部份，則該資料消化欄將出現。了解此延伸資料的實施法因此能計算其標準表示法，並可以驗證該消化。於此一實施例中，如果此延伸資料的規格書指示資料並不是簽章的一部份，則並不會出現資料消化欄位。

4.2.節點物件

4.3.鏈結物件

4.4.控制物件

4.5.內容鑰物件

在一實施例中，每一鑰具有一特有id、格式、用法(其可以是空的)、與資料。“用法”欄如果不是空的，則指明該鑰可以使用的目的。對於正常內容鑰，此欄為空的。對於潛水，此欄指明是否此為一鑰共享鑰或保密鑰。“格式”欄指明‘資料’欄的格式(例如，‘RAW’表示對稱鑰，或‘PKCS#8’表示RSA私鑰等等)。‘資料’欄包含依據‘格式’欄格式化之實質鑰資料。

對於配對鑰之一部份的鑰(例如RSA鑰)，額外欄‘pairId’給予該配對一特有識別碼，使得該對可以由其他資料結構參考。

在一實施例中，在鑰物件中之資料欄係為實際鑰的明文值，即使該件的呈現包含該鑰的加密拷貝。

4.6.控制符物件

D.浮游生物虛擬機器

浮游生物為群組引擎實施例所用之虛擬機器(VM)，以執行管理對內容存取之控制程式。以下將說明，浮游生物VM的例示樣品版，將解釋部份的設計決定及浮游生物VM配合群組架構，然後描述VM的基本元件，其後，有關記憶體模型的其他細節與指令集。最後，說明程式係如何包裝在碼模組中，及提供可為程式所用之系統呼叫組。

1.設計基本原理

在一實施例中，浮游生物虛擬機器(VM)為傳統虛擬機器，被設計以容易使用各種程式語言加以實施，同時具有很少之碼足跡。其係根據於可以被稱為TISC(簡易指令集電腦)的一堆疊導向之指令集。該指令集被設計為最低要求，不太關係於執行速度或碼密度。執行速度為非目標性，及碼密度為正交問題：當需要微型碼時，將使用資料壓縮技術以壓縮浮游生物碼，而不藉由設計使位元組碼變小。

浮游生物應適用於低或高階程式語言的目標。最少，虛擬機器本質上應支援組合語言、C及FORTH。應可能實施用於其他語言的編譯器，例如Java或專用語言，而沒有太多困難。

最後，在一實施例中，浮游生物VM被設計為理於主機環境內，不直接執行在處理機或積體電路上。用於浮游生物之自然主機環境為群組引擎。

2.架構

第11圖顯示浮游生物VM的例示實施法的作業環境。浮游生物VM執行於其主機環境的上下文內，當該主機環境執行程式時，其實施部份VM所需的功能。典型地，浮游生物VM執行於群組引擎內，其實施其主機環境。

VM藉由執行儲存在碼模組內之指令，而執行程式。部份這些指令可以藉由系統呼叫，而呼叫實施在程式本身外之功能。系統呼叫係為浮游生物VM本身所實行，或被指派到主機環境。

3.基本VM元件 3.1.執行模型

在一實施例中，浮游生物執行儲存在碼模組中之指令作為載在記憶體中之位元組碼流。VM維持一稱為程式計數器(PC)的虛擬暫存器，其係當指令被執行時增加。VM依序執行指令，直到遭遇OP_STOP指令、OP_RET指令遭遇空的呼叫堆疊、或發生例外為止。跳躍係被指明為相對跳躍(被指明為離開PC的現行值的位元組偏移)，或一絕對位址。

3.2.記憶體模型

在一實施例中，浮游生物VM具有簡單記憶體模型。VM記憶體被分成資料記憶體空間與碼記憶體空間。

資料記憶體為由位址0開始之均勻鄰接記憶體空間。資料記憶體典型為分配在主應用程式或主環境堆積記憶體內之一陣列位元組。對於一給定VM實施法，記憶體空間的尺寸將固定至指定最大值，及任何想要對該空間外的記憶體存取將造成故障，並將終止該程式執行。資料記憶體可能共享於幾個為VM所同時載入之碼模組間。在資料記憶體中之資料可以為記憶體存取指令所存取，指令可以為32位元或8位元存取。32位元記憶體存取係使用大尾序(big-endian)位元組順序完成。有關於VM可見與主機管理記憶體(主CPU虛擬或實體記憶體)間之排列，並未作出假設。

碼記憶體為均勻鄰接記憶體空間，由位址0開始。碼記憶體典型為在主應用程式或主環境之堆積記憶體內的一陣列位元組。

如果VM裝載幾個碼模組，則所有碼模組共享相同資料記憶體(然而，每一模組之資料被載於不同位址)，但每一個具有其本身碼記憶體(這表示對於來自一碼模組的跳躍指令不可能造成一跳躍直接至來自另一碼模組的碼)。

3.3.資料堆疊

VM具有資料堆疊的表示法，其代表儲存在資料記憶體中的32位元資料單元。VM維持一稱為堆疊指標器(SP)的虛擬暫存器。在重置後，SP指向資料記憶體的末端，及堆疊向下成長(當資料係被推至資料堆疊，SP暫存器被減量)。取決於參考堆疊資料的指令，而解釋在堆疊上之32位元值係為32位元定址，或32位元帶正負號整數。

3.4.呼叫堆疊

VM管理用以完成巢狀副程式呼叫的呼叫堆疊。推至此堆疊上之值不能為任一記憶體存取指令所直接讀取或寫入，而是當執行OP_JSP及OP_RET指令時，間接為VM所使用。對於一給定VM設定檔，此送回位址堆疊的尺寸將被固定至最大值，其允許某一量之巢狀呼叫不能被超出。

3.5.偽暫存器

VM在資料記憶體的開始處保留一小空間，以映圖偽暫存器。這些偽暫存器的記憶體位址為固定。

3.6.記憶體映圖

以下顯示資料記憶體及碼記憶體空間的佈局。

3.6.1.資料記憶體

3.6.2.碼記憶體

4.指令集

在一實施例中，浮游生物VM使用很簡單之指令集。指令的數量很有限，應足夠表示簡單程式。指令集係堆疊為主：除了OP_PUSH指令外，這些指令均沒有直接運算元。所有運算元件由資料堆疊所讀取，及結果被推至資料堆疊上。VM為32位元VM：所有指令操作於32位元堆疊運算元上，代表記憶體位址或帶正負號之整數。帶正負號之整數係以2的補數二進制編碼表示。

在以下表中，用於具有兩運算元的指令之堆疊運算元係被列為A、B，以堆疊的頂端最後(B)。

5.碼模組 5.1.模組格式

碼模組係被儲存於一基元為主的格式。基元係等同於用於MPEG-4檔案格式中之基元結構：一基元，由32位元尺寸構成，被以大尾序位元組順序被儲存為4-八位元組，其後有4-八位元組類型(通常八位元組對應於字母的ASCII值)、其後有基元的酬載(大小-8八位元組)。第12圖顯示例示浮游生物碼模組的格式。

5.2.pkCM基元

pkCM基元為頂級碼模組基元。其包含一順序之次基元。在一實施例中，此基元必須準確包含一pkDS、一pkCS及一pkEX基元。其也可以包含一pkRQ基元。在一實施例中，如果有的話，也可以包含任意量之其他應被忽略的基元。

5.3.pkDS基元

pkDS基元包含一記憶體影像的資料區段，其可以被載入資料記憶體中。基元的酬載為一順序之八位元組值。記憶體影像的第一八位元組包含一版本號，其指明以下之八位元組的格式。

在一實施例中，只有定義DataSegmentFormatVersion=0：以下之在順序中之八位元組形成一予以載入記憶體中之原始影像。VM載器只需要 將資料區段的酬載載入，而不是信頭位元組。

5.4.pkCS基元

pkCS基元包含一記憶體影像之碼區段，其可以被載入碼記憶體者。基元的酬載係為一順序之八位元組值。記憶體影像的第一八位元組包含一版本號，其指明以下之八位元組格式。

在一實施例中，只定義CodeSegmentFormatVersion=0，如下：下一個八位元組包含一版本號，以指明以下之八位元組的位元組碼編碼。ByteCodeVersion=0指明位元組碼值為以下所述者。以下八位元組包含位元組碼。VM載器只需要載入碼區段的酬載，不是兩信頭類型。

5.5.pkEX基元

pkEX基元包含一名單之出口輸入項。每一出口輸入項包含一名稱，編碼成為8位元名稱大小，其後有名稱的字元，包含終止於0；其後有32位元整數，代表該名稱之輸入點的位元組偏移(此係偏移開儲存於pkCS基元中之資料的開始處)。

5.6.pkRQ基元

pkRQ基元包含需要為虛擬機器實施法所符合之要求，以執行此碼。此基元為選用的。如果在此碼模組中沒有此基元，VM將使用預設實施設定，其可以為實施設定檔 所定義。

此基元由一陣列之32位元整數值構成，每一值用於一要求欄位：

5.7.模組載器

浮游生物VM負責載入碼模組。當碼模組被載入時，被編碼於pkDS基元中之資料區段影像係被載入於資料記憶體中之記憶體位址。該位址係為VM載器所選擇，並被儲存於DS偽暫存器中。為載器所選擇之位址需要足夠大以不會將載入資料與偽暫存器重疊並保留位址範圍。

編碼於pkCS基元中之碼區段記憶體影像係被載入於碼記憶體中之記憶體位址。該位址係為VM載器所選擇並被儲存在CS偽暫存器中。

當碼模組被載入時，如果“Global.OnLoad”特殊常式被發現在出口表的輸入項中，則執行該常式。此常式並不取在堆疊上之引數，並在送回時送回一整數狀態，0表示成 功，負數表示錯誤狀態。

當碼模組被卸載(或當載入模組的VM被丟棄)時，如果“Global.OnUnload”特殊常式在出口表中被找到，則該常式被執行。此常式並不取在堆疊上之引數，並在送回時送回一整數狀態，0表示成功，負數表示錯誤狀態。

6.系統呼叫

浮游生物程式可以呼叫實施在其碼模組的碼區段外之功能。此係藉由OP_CALL指令的使用加以完成，其採用一整數堆疊運算元來指明系統呼叫數。取決於系統呼叫，實施法可以為在不同碼模組中之浮游生物位元組碼常式(例如，一應用功能的資料庫)，直接藉由在VM本質實施格式中之VM，或指派至外部軟體模組，例如VM的主環境。

6.1.系統呼叫數配置

在討論中之例示實施例中，浮游生物保留用於固定系統呼叫(這些系統呼叫將在所有VM實施法上的相同數)系統呼叫數0至1023。系統呼叫數16384至32767係可為VM所用以動態指派(例如，為System.FindSystemCallByName所送回之系統呼叫數可以動態地為VM所配置，因此，並在所有VM實施法中，不必有相同數)。

在一實施例中，以下固定系統呼叫數係被指明：

6.2.標準系統呼叫

在一實施例，包含少數標準系統呼叫，其係可用於寫入控制程式。這些呼叫包含列在上表中之固定數系統呼叫，以及動態決定之系統呼叫(即其系統呼叫數係由System.FindSystemCallByName系統呼叫所取回，以其通過名稱作為引數)。

6.2.1.System.NoOperation

輸入：無 輸出：無

說明：此呼叫為無運算呼叫。其送回(沒事)。主要用以測試VM。

6.2.2.System.DebugPrint

輸入： 堆疊頂：

信息：包含一空終止字串的記憶體位置的位址。說明 ：列印文字字串至除錯輸出。

6.2.3.System.FindSystemCallByName

輸入：堆疊頂：

名稱：包含尋找的系統呼叫的名稱的空終止字串的位址。

輸出：堆疊頂：

Id：如果具有該名稱的系統呼叫之系統呼叫數被實施，如果不是，則-1。

說明：找出有其名稱之系統呼叫的ID。

6.2.4.System.Host.GetLocalTime

輸入：無

輸出：堆疊頂

本地時間：主機的當地時間之現行值。

說明：

當地時間係被表示為等於從1970年1月1日00：00：00開始之經由分鐘數時間的32位元整數。

6.2.5.System.Host.GetLocalTimeOffset

輸入：無

輸出：堆疊頂

當地時間偏移：主機的現行時間偏移(開UTC時間)。

說明：

時間偏移被表示為等於當地時間與UTC時間之差(即當地時間-UTC)之分鐘數的32位元帶正負號整數。

6.2.6.System.Host.GetTrustedTime

輸入：無

輪出：堆疊頂

信任時間：信任時鐘的現行值，如果無信任時間，則為負錯誤碼。該值被表示為一帶正負號32位元整數，其等於從1970年1月1日00：00：00UTC經過的分鐘數。

旗標：旗標位元組更定義信任時鐘的現行狀態。如果錯誤發生(信任時間值為負錯誤碼)，則旗標值必須為0。

定義有以下旗標

說明：

系統呼叫只有關於實施信任時鐘的系統，該信任時鐘與信任時間源同步並保有單調時間計數器。信任時間值並不一直保證正確，但在一實施例中，需要以下特性為真：

‧信任時間值被表示為UTC時間值(信任時間並不是當地時間區，因為當地並不能安全地決定)。

‧信任時間不會往回走。

‧信任時鐘並不會走得比真正時間快。

因此，信任時間一直在最後同步時間(與信任時間源同步)與當地真實時間之間。如果系統能決定其信任時鐘已操作並正常地連續更新，沒有干擾，自行與信任時間源的最後同步，則可以決定信任時間值不是評估，而是準確值，並設定TIME_IS_ESTIMATE旗標為0。

在一實施例中，如果信任時鐘檢測發生故障(硬體或軟體)，及甚至不能送回信任時間的評值值，則其必須送回一錯誤碼，所送回旗標的值必須設定為0。

6.2.7.System.Host.GetObject

輸入：堆疊頂：

母：母容器的32位元把(handle)

名稱：包含至要求物件的路徑之空終止的位址，相關於母容器

送回緩衝器：予以儲存物件值的記憶體緩衝器的位址

送回緩衝器大小：予以儲存物件值的記憶體緩衝器的大小(以位元組表示)

輸出：堆疊頂：

類型Id：物件類型id，如果呼叫失敗則為負錯誤碼。如果沒有要求物件，則錯誤送回為ERROR_NO_SUCH_ITEM。如果緩衝器所供給送回值太小，則送回錯誤為ERROR_INSUFFICIENT_SPACE。如果被存取的部份物件樹作存取控制及呼叫程式沒有取得物件許可，則送回ERROR_PERMISSION_DENIED。也可以送回其他錯誤碼。

大小：送回於呼叫者所供給的緩衝器中之資料的大小(以位元組表示)，或者，如果呼叫者提供太小之緩衝器時，則為所需之大小。

說明：系統呼叫為通用介面，其允許程式存取為VM主機所提供之物件。

6.2.7.1.物件類型

在一實施例中，有三類型之主物件：字串、整數、位元組陣列與容器。

6.2.7.1.1.位元組陣列

位元組陣列物件值為一陣列的8位元位元組。用於位元組陣列的物件類型Id為3

6.2.7.1.2.字串

字串物件的值為8位元字元的簡單空終止順序。用於字串的物件類型Id為2。

6.2.7.1.3.整數

整數物件的值為正常浮游生物32位元帶正負號整數值。用於整數的物件類型Id為1。

6.2.7.1.4.容器

容器為通用容器，其包含一順序之任意類型組合之任意數量物件。包含在容器中之物件被稱為該容器之子。容器的為32位元容器把，其在給定VM例中為特有的。用於容器的物件類型Id為0。

6.2.7.2.物件名稱

用於主物件的名稱空間為基礎名稱空間，其中容器的子物件的名稱係藉由將子的名稱附加至母容器的名稱加以建構，並以“/”字元加以分開。字元與整數物件並沒有子。例如，如果容器稱為‘節點/屬性’，並具有字串子名稱‘類型’，則‘節點/屬性/類型’表示子字串。

名稱空間的根為‘/’。所有絕對名稱以‘/’開始。未以‘/’開始的名稱為相對名稱。相對名稱係相對於一母容器。例如，相對於母‘/Node’之名稱‘屬性/類型’為具有絕對名稱‘/Node/Attributes/Type’的物件。根容器‘/’具有固定把值0。

6.2.7.2.1.虛擬名稱及虛擬物件

容器物件可以具有真及虛擬子物件，其係藉由使用虛擬名稱加以存取。虛擬名稱係為未附至主物件的名稱，而是用以指明沒名稱的子物件、具有不同名稱的子物件、或虛擬子物件(不是容器的真實親子但在要求時加以自動建立的子物件)。

對於任意物件，以下虛擬名稱被定義為虛擬子物件名 稱：

對於任意容器，定義以下虛擬名稱為虛擬子物件名稱：

6.2.7.2.2.例子

例如主物件的階層：

呼叫System.Host.GetObject(母=0，名稱=‘節點’)送回類型id0(容器)，並寫入把值1於為呼叫者所供給之緩衝器中(值的大小為4位元組)。

呼叫System.Host.GetObject(母=0，名稱=‘節點/屬性/領域’)送回類型id2(字串)，並寫入字串“頂層”於為呼叫者所供給之緩衝器中(值的大小為9位元組)。

呼叫System.Host.GetObject(母=1，名稱=‘屬性/@1’)送回類型id1(整數)，並寫入整數78於為呼叫者所供給之緩衝器中(值的大小為4位元組)。

呼叫System.Host.GetObject(母=0，名稱=‘不存在’)送回錯誤碼ERROR_NO_SUCH_ITEM。

6.2.8.System.Host.SetObject

輸入：堆疊頂：

母：母容器的32位元把

名稱：包含至物件路徑之空終止字串的位址，相對於母容器。

物件位址：物件值所儲存之記憶體緩衝器的位址。如果位址為0，則呼叫被解釋為摧毀該物件之要求。在位址上的資料取決於物件的類型。

物件類型：物件的類型Id。

物件大小：物件值所儲存之記憶體緩衝器的大小(以位元組表示)。在例示實施例中，對於整數物件，大小必須設定為4。對於字串物件，大小為記憶體緩衝器的大小，包含空終止碼。對於位元組陣列物件，大小為在陣列中之8位元之位元組的數目。

輸出：堆疊頂：

結果碼：如果呼叫成功，則為0，或者呼叫失敗，則為負錯誤碼。如果所要求之物件並不存在，則錯誤送回為ERROR_NO_SUCH_ITEM。如果物件樹的正存取部份被存取控制，及呼叫程式並未許可存取物件，則送回 ERROR_PERMISSION_DENIED。也可以送回其他錯誤碼。

說明：

此系統呼叫為通用介面，其允許程式建立、寫入及摧毀由VM主機所提供之物件。物件名稱與類型之說明係與System.Host.GetObject相同。

並非所有主物件支援被寫入或攜帶，及並非所有具有子物件的容器支援被建立。當用於一不支援操作之物件的設定物件呼叫完成時，送回一ERROR_PERMISSION_DENIED。

當物件參考一容器時，有一特殊情形，及物件位址不是0：物件大小參數必須設定為0。物件位址的值被忽略。如果容器已經存在，則不必作任何事，送回一成功的結果碼。如果沒有容器，及容器之母為可寫，則建立空容器。

6.2.9.Octopus.Links.IsNodeReachable

輸入：堆疊頂：

節點Id：包含予以測試可到達性之目標鏈結的ID的空終止字串的位址。

輸出：堆疊頂：

結果碼：整數值。如果節點可到達，則結果值為0，如果不是，則為負錯誤碼。

狀態塊指標器：標準延伸狀態塊的位址，如果未送回狀態塊，則為0。

說明：

此系統呼叫係為控制程式所使用，以檢查是否一給定節點可由相關於主管浮游生物VM之實體的節點所到達。

6.2.10.System.Host.SpawnVm

輸入：堆疊頂：

模組Id：應被載入VM中之碼模組的Id。

輸出：堆疊頂：

結果碼：整數值。如果呼叫成功，則結果值為0，如果失敗，則為負錯誤碼。

Vm把：整數值。有關VM例之把被建立(如果呼叫失敗，此被設定為0)。該把只被保證在現行VM中為特有。

說明：

此系統呼叫係為控制程式所使用，以要求被建立之浮游生物虛擬機器，及碼模組被裝載。

新建立VM的主機應展示相同主機物件作為呈現給呼叫者的主機物件，例外為主機物件“/Octopus/Runtime/Parent/Id”被設定給呼叫者的身份。

當正執行用於呼叫者的碼的VM終止時，未被呼叫System.Host.ReleaseVm所明示釋放的產生VM被自動地為系統所釋放，如同呼叫System.Host.ReleaseVm。

6.2.11.System.Host.CallVm

輸入：堆疊頂：

Vm把：一整數值。由呼叫System.Host.SpawnVm所建立之VM的把。

輸入點：空終止字串的位址，其指明輸入點的名稱。此名稱需要匹配在碼模組之輸出表中之輸入點之一，該碼模姐被載入對應於Vm把參數的VM實例。

參數塊位址：包含予以傳送至被呼叫者的資料的記憶體方塊的位址。如果沒有參數送至被呼叫者，則被設定為 0。

參數塊大小：在位址參數塊位址之記憶體方塊大小(以位元組表示)，如果參數塊位址為0，則為0。

送回緩衝器位址：呼叫者自被呼叫者接收的記憶體緩衝器的位址。如果呼叫者並未期待自被呼叫者送回資料，則此被設定為0。

送回緩衝器大小：在位址送回緩衝器位址之記憶體緩衝器的大小(以位元組表示)，如果送回緩衝器位址為0，則為0。

輸出：堆疊頂：

系統結果碼：一整數值。如果呼叫成功則結果值為0，如果失敗，則為負錯誤碼。此值係為系統所決定，而不是被呼叫者。成功只表示系統能成功找到呼叫的常式，執行常式並由常式取得送回值。來自常式之送回值被送回CalleeResultCode值中。

被呼叫者結果碼：整數值。此係為被呼叫者所送回之值。

送回塊大小：在為呼叫者所供給之緩衝器中之資料大小(以位元組表示)，或者如果呼叫者提供一太小之緩衝器，則為所需之大小。如果被呼叫者未送回資料，則值為 0。

說明：

系統呼叫係為控制程式所使用，以呼叫執行於碼模組中之常式，碼模組係被裝載於為System.Host.SpawnVm系統呼叫所建立的VM實例中。

在例示實施例中，被呼叫之常式需要配合以下介面習慣：當常式被呼叫時，堆疊包含為呼叫者所供之值參數塊大小，表示在頂的參數塊的大小、其後有資料的參數塊大小位元組。如果大小不是4的倍數，則在堆疊上之資料將被加上0值的位元組，以確保堆疊指標保持為4的倍數。

堆疊頂：

於送回時，常式必須在堆疊上，提供以下送回值：堆疊頂：

送回塊位址：包含予以送至呼叫者的資料之記憶體方塊之位址。如果沒資料要送回，則被設定為0。

送回塊大小：在位址送回塊位址的記憶體塊的大小(以位元組表示)，如果送回塊位址為0，則為0。

6.2.12.System.Host.ReleaseVm

輸入： 堆疊頂

Vm把：整數值。為呼叫System.Host.SpawnVm所建立的VM的把。

輸出：堆疊頂：

結果碼：整數值。如果呼叫成功，則結果值為0，如果失敗，則為負錯誤碼。

說明：

系統呼叫係為控制程式所使用，以要求被建立一浮游生物虛擬機器的新實例，及一碼模組被裝載。

新建立VM的主機應展現與展現給呼叫者的相同主物件，除了設定至呼叫者的身份之主物件“/Octopus/Runtime/Parent/Id”外。

6.3.標準資料結構

以下係為部份標準系統呼叫所用之標準資料結構。它們也可以為其他客戶系統呼叫所使用。

6.3.1.標準參數

參數塊：

名稱：參數名稱

值：參數值

延伸參數塊：

旗標：布林旗標的向量

參數：簡單名稱/值參數塊

名稱塊：

大小：32位元整數，等於隨後之字元欄的8位元位元組大小。如果此值為0，則字元欄為空(其後為空的)。

字元：空終止UTF-8字串值塊：

類型：32位元位元組識別碼。在一實施例中，定義以下類型：

大小：32位元整數，等於在後之資烞欄的8位元位元組的大小。如果值為0，則資料欄為空的(其後無值)。

資料：8位元位元組陣列代表一值。實際位元組取決於為類型欄所代表之資料編碼。

值名單塊：

值計數：32位元整等於其後之值塊結構的數量。如果值為0，則其後無值塊。

值0、值1、...：表示0或更大值塊結構的順序

6.3.2.標準延伸狀態

標準延伸狀態塊為一資料結構，典型用以傳輸延伸資訊作為由呼叫至常式或系統呼叫之送回狀態。這是為同屬資料結構，可以用於各種上下文中，對於其欄位具有不同可能值範圍。

延伸狀態塊：

通用旗標：布林旗標，不管類別欄，其語意係相同。旗標的位置與意義係為使用標準延伸狀態塊的設定檔所定義。

類別：狀態所屬之類別的整數特有識別碼。類別識別碼值係由使用標準延伸狀態塊的設定檔所定義。

次類別：進一步分類為此塊所述之狀態類型的次類別的整數識別碼(在該類別中所特有)。

本地旗標：布林旗標，其語意係限定於此狀態塊的類別及次類別。旗標的位置與意義係為定義與使用該類別語意的設定檔所定義。

快取時間：指示此狀態可以快取的時間(即保持有效)。見時間之實際值的快取時間塊定義。

參數：0或更多值塊的名單。每一值塊包含一參數， 其被編碼為類型參數或延伸參數的值。每一參數將一名稱束縛至一類別值，並被用以編碼描述狀態塊的彈性可變資料，並較類別、次類別、快取時間及旗標更詳細。

快取時間塊：

類型：用於值類型的整數識別碼。

以下類型可以使用：

值：32位元整數。此值的意義取決於類型欄。

6.4.標準結果碼

某些標準結果碼被用於各種API中。其他結果碼可以定義用於更特定API中。

7.用於浮游生物組合器之組合器語法

在一實施例中，浮游生物組合器讀取包含有碼、資料及處理指令的來源檔，與處理指令，及產生二次進碼模組，其可以為浮游生物VM所裝載。在一實施例中，浮游生物組合器係可操作以建立來自一組合語言檔的控制程式。有關浮游生物組合器的例示實施例之其他資訊係被提供如下。

在一例示實施例中，組合器一行一行地依序處理一來源檔。行可以為零或更多字元，其後有新行。

每一行可以為以下之一：

‧一空白行(只有空白空間)

‧區段指引

‧資料指引

‧組合器指引

‧碼指令

‧標籤

‧出口指引

每一行可以以一命令結束，其以“；”字元開始，並持續直到行結束為止。

由來源讀取的資料與指令具有一暗示目的地區段(其中，它們以VM裝載之一作結束)。在剖析程序中之任一點處，組合器將具有“現行”區段，其為資料與指令的暗示目的地區段。現行區段可以使用區段指引加以改變。

7.1.區段指引

區段指引改變剖析器的現行區段。在一實施例中，所支援的區段指引為：

‧.code

該碼區段保有位元組碼指令

‧.data

該資料區段保有通用變數

7.2.資料指引

資料指引指明將被載入VM的資料區段中之資料(整數與字串)。

.string“<some chars>”

指明一串之字元。組合器將在字串的末端加入一八位元組值0。

‧.byte<value>

指明8位元。<value>可以表示為十進制數，或十六進制數(字尾加上0x( )。

.long<value>

指明32位元。<value>可以表示為十進制數，或十六進制數(字尾加上0x)。

7.3.組合器指引

在一實施例中，組合器指引為：.equ<symbol>，<value>

設定符號<symbol>等於值<value>。符號典型被使用作為運算元或碼指令。

7.4.標籤

標籤為符號，其指向在區段內之位置。指向在碼區段中之指令的標籤典型用於跳躍/分支指令。指向資料區段中之資料的標籤典型用以表示變數。

用於標籤的語法為：<LEBEL>：

注意在“：”後為空白，除了選用命令外。標籤指向下一資料或指令。其可以具有一個以上之標籤指向相同位址。

7.5.出口指引

出口指引係用以在組合器所產生之碼模組之“出口”段落中建立輸入項。在出口段落的每一輸入項為一(名稱、位址)對。在例示實施例中，在碼區段內只有位址可以在出口段落中指明。

出口指引的語法為：.export<label>

這將出口為<label>所指向之位址，以名稱<label>。

7.6.碼指令

當編譯指定給碼區段的資料時，組合器讀取直接、間 接映圖至位元組碼的指令。多數浮游生物位元組碼沒有直接運算元，並在單行上出現一簡單助憶。為了使組合器語法更可靠，部份指令接受偽運算元，這看起來像它們為位元組碼運算元，但它們真正並不是；在此時，組合器產生一或多數位元組碼指令，以產生如同指令具有直接運算元般之作用。例如，分支指令使用偽運算元。

7.6.1.分支運算元

分支指令可以是特定的原樣呈現(沒有任何運算元)，或者具有一選用運算元，其將為組合器所轉換為對應之位元組碼順序。選用運算元為以下之一：

‧整數常數

‧符號

當運算元為符號時，組合器計算正確整數相對偏移，使得分支在對應於該符號之位址結束。

7.6.2.推入運算元

在一實施例中，推入指令一直採一運算元。運算元可以是以下之一：

‧整數常數

‧符號

‧前置‘@’，其後有標籤名稱

當運算元為符號時，被推入之值一直為該符號之直接值，不論該符號為標籤或.equ符號(該值並不增量一區段偏移)。

當運算元為前置有‘@’的標籤名稱時，被推入之值取決於標籤指向什麼而定。被推入堆疊之值係為標籤所代表之絕對位址(即被加入至區段偏移之本地標籤值)。

7.7.例子

7.8.命令行語法

在一實施例中，組合器為命令行工具，其可以以以下語法加以調用：

E.物件儲存

以下將說明可以為群組引擎實施法所用以提供安全狀態儲存機制之安全物件儲存。此一設施係有用於使得控制程式可以讀取並寫入保護狀態的資料庫，其由一調用至另一調用係持續的。此一狀態資料庫可以用以儲存例如遊戲次數、第一次使用日期、累積進行時間、及/或等等的狀態物件。

1.資料庫物件

“貝殼”資料庫包含物件。物件係被安排於邏輯階層中，其中容器物件為其包含子物件的母。在一實施例中，有四類型之物件。每一物件具有相關元資料及一類型。取決於其類型，一物件也可以具有一值。

貝殼物件可以由浮游生物程式使用System.Host.GetObject及System.Host.SetObject系統呼叫加以存取。如下所詳述，物件元資料可以使用虛擬名稱加以存取。在一實施例中，部份元資料欄可以藉由貝殼資料庫的客戶加以改變，但部份元資料欄為唯讀(它們整個為資料庫實施法所管理)。

1.1.物件元資料

1.2.物件類型 1.2.1.字串

字串物件的值為UTF-8編碼字元串。

1.2.2.整數

整數物件值為32位元正負號整數值。

1.2.3.位元組陣列

位元組陣列物件的值為一陣列之8位元位元組。

1.2.4.容器

容器物件包含零或更多物件。容器物件被稱為物件所包含之母。所被包含物件稱為容器的子。所有作成物件母、母的母，以此類推的鏈的容器物件係被稱為物件的祖先 。如果物件具有另一物件作為其祖先，則該物件被稱為該祖物件的孫物件。

2.物件壽命

在貝殼資料庫中之物件壽命遵循若干規則。物件可以被明示地摧毀，或暗示地摧毀。物件可以由於資料庫垃圾收集而摧毀。

不管物件如何摧毀，在一實施例中，永遠適用以下規則：

‧用於該物件的母容器的修改日期被設定為現行當地時間。

‧如果物件為容器，則所有其子被摧毀。

2.1.明示物件摧毀

明示物件摧毀發生於資料庫的客戶要求移除一物件(見物件存取，此係如何使用Host.SetObject浮游生物系統呼叫加以完成)。

2.2.暗示物件摧毀

暗示物件摧毀發生於物件正被摧毀，因為在其祖先中之物件之一正被摧毀。

2.3.垃圾收集

貝殼物件資料庫可以摧毀已經到期之物件。當系統上 之本地時間實施資料庫大於物件元資料的到期日期欄時，一物件被認為到期。直到資料庫實施法決定何時及如何執行到期物件的收集。

注意當容器物件因為到期而被摧毀時，即使子物件未到期，子物件(及其子子物件，以此類推)也被摧毀。

3.物件存取

在貝殼資料中之物件也可以經由一對系統呼叫由浮游生物程式存取。該兩系統呼叫為：System.Host.GetObject讀取物件的值，及System.Host.SetObject建立、摧毀或設定一物件的值。

為了看起來像主物件的樹，一貝殼資料庫需要“安裝”在主物件樹中之某名稱下。以此方式，資料庫係可以被視為主物件的更通用樹中之次樹。為了完成此，在一實施例中，所有貝殼資料庫包含一直存在之頂層內建根容器物件。此根容器基本上為資料庫的名稱。在資料庫中之所有其他物件將為根容器的子孫。多貝殼資料庫可以安裝在主物件樹中之不同處(兩資料庫需要被安裝在同一主容器下，它們需要在其根容器有不同名稱)。例如，如果具有根容器名稱為‘資料庫1’的貝殼資料庫包含一單一整數子容器物件，其名稱‘子1’，則該資料可以安裝在主物件容器“/貝殼”，其中‘子1’物件將可以被視為‘貝殼1/資料1/子1’。

在一實施例中，所有對物件的存取係為一存取政策所 管理。

3.1.讀取物件

物件的值可以藉由使用系統呼叫System.Host.GetObject加以讀取。可以存在於資料庫中之四物件類型(整數、字串、位元組陣列及容器)直接映圖至浮游生物虛擬機器規格書中之對應部份。物件值係以正常方式加以存取，及實施標準虛擬名稱。

3.2.建立物件

物件可以藉由呼叫System.Host.SetObject已經不存在的物件名稱而加以建立。物件建立係依據系統呼叫規格加以完成。當物件建立時，貝殼資料庫：

‧設定物件元資料的擁有者欄為正執行程式之本人身份的ID。此ID為URN。這是為用於執行系統之真模型規格，其指明如何決定該身份。通常，其被束縛至數位簽章，其係相關於碼模組，程式係由該碼模組載入。

‧設定元資料之建立資料欄至現行當地時間。

‧設定元資料之修正日期欄至現行當地時間。

‧設定元資料之到期日期欄至0(不到期)。

‧設定母容器的修正日期至現行當地時間。

當在一較現行容器階層為深的路徑建立物件時，在一實施例中，貝殼資料庫將需要暗示建立容器物件，其需要被存在以建立至被建立的物件之路徑。暗示容器物件建立 遵循與明示建立相同的規則。

例如，如果有一容器“A”沒有子，則在建立“A/B/C部份物件”前，設定“A/B/C部份物件”的要求將暗示建立容器“A/B”及“A/B/C”。

3.3.寫入物件

物件的值可以藉由呼叫System.Host.setObject已存在之物件而改變。如果所指定物件類型並不匹配現行物件的類型Id，則送回ERROR_INVALID_PARAMETER。如果類型Id為OBJECT_TYPE_CONTAINER，則不需要指定任何值(物件位址應不是零，但其值將被忽略)。

當現行物件被設定時，貝殼資料設定物件的修改日期為現行當地時間。

3.4.摧毀物件

物件可以藉由呼叫System.Host.SetObject已經存在之具有物件位址值0的物件，而被明示地摧毀。

當物件被摧毀時，貝殼資料庫：

‧設定母容器的修改日期至現行當地時間。

‧如果被摧毀的物件為容器，則摧毀其所有子物件。

3.5.物件元資料

用於貝殼物件的元資料係藉由使用具有虛擬名稱之System.Host.GetObject及System.Host.SetObject系統呼叫 加以存取。

下表列出可為在貝殼資料庫實施例中之物件所用的標準及延伸虛擬名稱及它們係如何映圖至元資料欄。

元資料欄為唯讀並不能被寫入。

4.物件擁有欄與存取控制

只要完成一讀取、寫入、建立或摧毀的要求時，貝殼資料庫實施法首先檢查是否呼叫者具有許可以執行該要求。管理對物件的存取之政策係根據本人身份與委託的概念。為了實現政策，有必要信任實施法所操作之模型支援鑑別控制程式之表示法。此典型係藉由令浮游生物碼模組包含以PKI鑰對的一私鑰作數位簽章的程式，並令一名稱證書將一本人名稱相關於一簽章鑰而加以完成；然而，仍有可能有不同方式來決定控制程式身份。

用於貝殼資料庫中之物件的存取政策係包含少數簡單規則：

‧如果呼叫者的身份與物件的擁者相同或是物件祖先容器之一相同，則讀取及寫入存取物件的值被核准。

‧如果呼叫者的身份與物件為子的容器的擁有者相同，則核准建立或摧毀存取。

‧對物件的元資料的讀取及寫入存取(使用虛擬名稱)遵循與對物件值的讀取與寫入存取相同的政策，具有其他的限制，其係為唯讀欄，不能被寫入。

當資料庫被建立時，貝殼資料庫的根容器較佳為固定。當物件被建立時，其擁有者的元資料欄的但被設定為呼叫者的身份。一物件的擁有權可以改變。為了改變物件的擁有權，擁有者元資料欄的值可以藉由呼叫System.Host.SetObject系統呼叫該物件的‘@擁有者’虛擬名稱加以設定。

因為，在一實施例中，控制程式不可能存取為與正執行在一控制程式進行下之身份相同主人所擁有的物件，該控制程式需要委託對‘外來’物件之存取至由碼模組所載入之程式，該碼模組具有能力以在‘外來’物件擁有者身份下執行。為了如此，控制程式可以使用在浮游生物虛擬機器中之System.Host.SpawnVm、System.Host.CallVm及System.Host.ReleaseVm系統呼叫。

雖然前述已經為了清楚起見在部份細節上詳細說明，但可以了解的是，部份改變與修正可以在不脫離本案之原理下完成。應注意的是，有各種方法用以實施於此所述之處理與設備。因此，本實施例係被認為是例示而不是限定用。

第1圖顯示群組(Octopus)數位權管理(DRM)引 擎組件如何在使用DRM的網路內動作的情形。

第2圖顯示群組節點的例子。

第3圖顯示在一執照中之物件彼此關係例示實施例中之內容物件的關係。

第4圖顯示在一實施例中，組成群組為主消費應用程式之元件。

第5圖顯示一例示組API的使用，及發生在例示實施例中之主機應用程式與DRM客戶引擎間之交互作用。

第6圖顯示在一實施例中，組成群組為主的套裝應用程式的元件。

第7圖顯示例示性API的使用，及發生在主機應用程式與套裝引擎間之交互作用。

第8圖顯示在一實施例中，使用鏈結之潛水鑰的推導。

第9圖顯示依據群組實施例的各種內容保護與管理物件。

第10圖顯示各種規則件、身份及鑰管理物件。

第11圖顯示用於浮游生物VM的例示性實施法的作業環境。

第12圖顯示例示浮游生物碼模組的格式。

Claims (12)

1. 一種在主電腦系統中授權對儲存在記憶體中之一件電子內容的存取之方法，該主電腦系統包含一使用者介面、該記憶體、一處理機及一數位權管理引擎被載入在該記憶體中並被執行在該處理機上，該方法包含步驟：自該使用者介面接收來自該主電腦系統使用者之存取該件電子內容的要求；自該記憶體取回有關於該件電子內容之執照，該執照包含一控制物件、一控制符物件、一保護符物件、及一內容鑰物件；自該控制物件取回一第一控制程式；將該第一控制程式載入為該數位權管理引擎所控制的記憶體中；及使用該數位權管理引擎，以執行該第一控制程式，以決定是否可以核准該要求，其中執行該第一控制程式包含評估儲存在該主電腦系統之該記憶體中之一或多數鏈結物件，其中每一鏈結物件代表於兩實體間之關係，其中該一或多數鏈結物件之至少之一包含一第二控制程式，及其中評估該一或多數鏈結物件包含：將該第二控制程式載入為該數位權管理引擎所控制之記憶體中，該第二控制程式表示必須實現的一或多數條件，以使得該鏈結被認為有效；及使用該數位權管理引擎，以執行該第二控制程式，以決定是否該鏈結為有效，包含決定該一或多數條件是否滿 足，其中該一或多數條件之至少之一包含要求儲存於記憶體中之計數器不超出一預定值。
2. 如申請專利範圍第1項所述之方法，其中該控制符物件係可操作以安全地束縛該控制物件與該內容鑰物件。
3. 如申請專利範圍第1項所述之方法，其中該保護符物件係可操作以安全地束縛該內容鑰物件與該件電子內容。
4. 如申請專利範圍第1項所述之方法，其中該一或多數條件之至少之一包含要求現行時間在一預定時間之前。
5. 如申請專利範圍第1項所述之方法，其中該一或多數條件之至少之一包含要求現行時間在某一時間之後。
6. 如申請專利範圍第1項所述之方法，其中該一或多數條件之至少之一包含要求該第二控制程式先前並未被執行超出一預定次數。
7. 如申請專利範圍第1項所述之方法，其中該一或多數條件之至少之一包含要求預定事件先前並未發生。
8. 如申請專利範圍第1項所述之方法，其中該一或多數條件之至少之一包含要求該主電腦系統必須具有一或多數預定特徵。
9. 如申請專利範圍第1項所述之方法，其中該一或多數條件之至少之一包含要求執行在該主電腦系統上之用 以描繪該件電子內容的軟體不能輸出該件電子內容至一預定介面。
10. 一種在主電腦系統中授權予以執行在儲存在記憶體中之一件電子內容的給定動作之方法，該主電腦系統包含一使用者介面、該記憶體、一處理機及一數位權管理引擎被載入在該記憶體中並被執行在該處理機上，該方法包含步驟：使用該數位權管理引擎，以執行一第一控制程式，該第一控制程式係可操作以決定是否該給定動作可以執行在該件電子內容上，其中該第一控制程式係可操作以評估第一組的一或多數條件，其必須滿足，以使該給定動作的執行被授權，及其中該第一組之一或多數條件之至少之一包含一要求，其中，該主電腦系統之該記憶體包含一或多數鏈結物件，該一或多數鏈結物件鏈結代表第一實體之第一節點至代表第二實體之第二節點；自記憶體取回一或多數鏈結物件，各個鏈結物件表示於兩實體間之關係，及至少一鏈結物件包含一第二控制程式，其中該第二控制程式係可操作以評估第二組之必須滿足的一或多數條件，以使得該至少一鏈結物件被認為是有效的；及使用該數位權管理引擎，以執行該第二控制程式，其中該第一組條件或第二組條件的至少之一包含要求儲存在記憶體中之計數器不超出一預定值。
11. 如申請專利範圍第10項所述之方法，其中該第 一組的一或多數條件包含一時間為主的條件。
12. 如申請專利範圍第10項所述之方法，其中該第二組的一或多數條件包含一時間為主的條件。