Digital rights management engine systems and methods

CROSS-REFERENCE TO RELATED APPLICATIONS

0001This application claims the benefit of U.S. Provisional Application No. 60/728,089, filed Oct. 18, 2005, U.S. Provisional Application No. 60/772,024, filed Feb. 9, 2006, U.S. Provisional Application No. 60/744,574, filed Apr. 10, 2006, U.S. Provisional Application No. 60/791,179, filed Apr. 10, 2006, U.S. Provisional Application No. 60/746,712, filed May 8, 2006, U.S. Provisional Application No. 60/798,925, filed May 8, 2006, and U.S. Provisional Application No. 60/835,061, filed Aug. 1, 2006. U.S. Provisional Application Nos. 60/728,089, 60/772,024, 60/744,574, 60/791,179, 60/746,712, 60/798,925, and 60/835,061 are incorporated herein by reference in their entirety for any purpose.

COPYRIGHT AUTHORIZATION

0002A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

BACKGROUND AND SUMMARY

0003In modem computing systems, it is often desirable to limit access to electronic content, services, and/or processing resources, and/or to allow only certain entities to perform certain actions. A variety of techniques have been developed or proposed to enable such control. These techniques are often referred to as digital rights management (DRM) techniques because, in general terms, their goal is to manage the rights of various entities in digital or other electronic content, services, or resources. A problem with many prior art techniques is that they are overly complex, overly restrictive, relatively inflexible, fail to enable certain natural types of relationships and processes, and/or are uninteroperable with other DRM systems.

0004Systems and methods are described herein that can be used to ameliorate some or all of these problems. It should be appreciated that embodiments of the presently described inventive body of work can be implemented in numerous ways, including as processes, apparatuses, systems, devices, methods, computer readable media, and/or as a combination thereof. Several illustrative embodiments are described below.

BRIEF DESCRIPTION OF THE DRAWINGS

0005The inventive body of work will be readily understood by referring to the following detailed description in conjunction with the accompanying drawings, in which:

0006<figref idref="DRAWINGS">FIG. 1</figref> shows an illustrative system for managing the use of electronic content.

0007<figref idref="DRAWINGS">FIG. 2</figref> shows a more detailed example of a system that could be used to practice embodiments of the inventive body of work.

0008<figref idref="DRAWINGS">FIG. 3</figref> shows how an illustrative digital rights management (DRM) engine might function in a network that uses DRM.

0009<figref idref="DRAWINGS">FIG. 4</figref> shows a collection of nodes and links used to model the relationships in a DRM system.

0010<figref idref="DRAWINGS">FIG. 5</figref> is a flowchart illustrating how an embodiment of a DRM engine might determine whether a requested action is authorized.

0011<figref idref="DRAWINGS">FIG. 6</figref> shows an example of a DRM license in accordance with one embodiment of the inventive body of work.

0012<figref idref="DRAWINGS">FIGS. 7A and 7B</figref> illustrate the use of agents in one embodiment.

0013<figref idref="DRAWINGS">FIG. 8</figref> shows an example of a DRM license.

0014<figref idref="DRAWINGS">FIG. 9</figref> is a more detailed example of how a DRM engine might determine whether a requested action is authorized.

0015<figref idref="DRAWINGS">FIG. 10</figref> is a more detailed example of how a DRM engine executes a control program in one embodiment object.

0016<figref idref="DRAWINGS">FIG. 11</figref> shows an illustrative embodiment DRM engine running on a device.

0017<figref idref="DRAWINGS">FIG. 12</figref> is a flowchart illustrating the steps involved in executing a control program in one embodiment.

0018<figref idref="DRAWINGS">FIG. 13</figref> shows the elements that make up a content consuming client application in one embodiment.

0019<figref idref="DRAWINGS">FIG. 14</figref> shows the elements that make up a content packaging application in one embodiment.

0020<figref idref="DRAWINGS">FIG. 15</figref> shows a key derivation mechanism in accordance with one embodiment.

0021<figref idref="DRAWINGS">FIG. 16</figref> shows an example of a DRM system.

0022<figref idref="DRAWINGS">FIG. 17</figref> shows an example of a DRM system that provides for temporary login.

0023<figref idref="DRAWINGS">FIG. 18</figref> shows the high-level architecture of an illustrative system for managing enterprise documents.

0024<figref idref="DRAWINGS">FIG. 19</figref> shows an example of a how a system such as that shown in <figref idref="DRAWINGS">FIG. 18</figref> can be used to manage access to or other use of a document.

0025<figref idref="DRAWINGS">FIG. 20</figref> shows an additional example of a how a system such as that shown in <figref idref="DRAWINGS">FIG. 18</figref> can be used to manage access to or other use of a document.

0026<figref idref="DRAWINGS">FIG. 21</figref> shows additional features of the example shown in <figref idref="DRAWINGS">FIG. 20</figref>.

0027<figref idref="DRAWINGS">FIG. 22</figref> shows another illustrative system for managing electronic content within an enterprise.

0028<figref idref="DRAWINGS">FIG. 23</figref> illustrates how the systems and methods described herein could be applied to manage healthcare records.

0029<figref idref="DRAWINGS">FIG. 24</figref> is an illustration of how the systems and methods presented herein could be used in a context of an electronic subscription service.

0030<figref idref="DRAWINGS">FIG. 25</figref> is an illustration of how the systems and methods described herein could be used in a context of a home network domain.

0031<figref idref="DRAWINGS">FIG. 26</figref> illustrates the interactions that take place between a host application and a DRM client engine in one example embodiment.

0032<figref idref="DRAWINGS">FIG. 27</figref> illustrates the interactions that take place between a host application and a packaging engine in one illustrative embodiment.

0033<figref idref="DRAWINGS">FIG. 28A</figref> is a more detailed illustration of a license in accordance with one embodiment.

0034<figref idref="DRAWINGS">FIG. 28B</figref> illustrates the relationship between links and nodes in one example embodiment.

0035<figref idref="DRAWINGS">FIG. 29</figref> illustrates the operating environment of an illustrative implementation of a virtual machine.

0036<figref idref="DRAWINGS">FIG. 30</figref> illustrates an extended status block data structure in accordance with one embodiment.

0037<figref idref="DRAWINGS">FIG. 31A</figref> shows a memory image of a data segment in one embodiment.

0038<figref idref="DRAWINGS">FIG. 31B</figref> shows an example of the memory image of a code segment in one embodiment;

0039<figref idref="DRAWINGS">FIG. 31C</figref> shows an example of an export entry memory image in one embodiment.

0040<figref idref="DRAWINGS">FIG. 31D</figref> shows a generic example of an export table entry in one embodiment.

0041<figref idref="DRAWINGS">FIG. 31E</figref> shows an example of an export table entry for an example entry point.

0042<figref idref="DRAWINGS">FIG. 32</figref> shows an example of a license transfer protocol.

0043<figref idref="DRAWINGS">FIG. 33</figref> shows another example of a license transfer protocol in accordance with one embodiment.

0044<figref idref="DRAWINGS">FIG. 34</figref> shows a mechanism for protecting the integrity of license objects in one embodiment.

0045<figref idref="DRAWINGS">FIG. 35</figref> shows a mechanism for protecting the integrity of license objects in another embodiment.

0046<figref idref="DRAWINGS">FIG. 36</figref> illustrates a proximity checking protocol in accordance with one embodiment.

0047<figref idref="DRAWINGS">FIG. 37</figref> illustrates the use of a proximity check protocol in accordance with one embodiment.

0048<figref idref="DRAWINGS">FIG. 38</figref> illustrates an interaction between a client and a license server in one embodiment.

0049<figref idref="DRAWINGS">FIG. 39</figref> is more detailed illustration of an interaction between a client and a license server in one embodiment.

0050<figref idref="DRAWINGS">FIG. 40</figref> shows an example of an entity with multiple roles.

0051<figref idref="DRAWINGS">FIG. 41</figref> illustrates a bootstrap protocol in accordance with one embodiment.

0052<figref idref="DRAWINGS">FIG. 42</figref> shows the relationship between c14n-ex and an illustrative XML canonicalization in one embodiment.

DETAILED DESCRIPTION

0053A detailed description of the inventive body of work is provided below. While several embodiments are described, it should be understood that the inventive body of work is not limited to any one embodiment, but instead encompasses numerous alternatives, modifications, and equivalents. In addition, while numerous specific details are set forth in the following description in order to provide a thorough understanding of the inventive body of work, some embodiments can be practiced without some or all of these details. Moreover, for the purpose of clarity, certain technical material that is known in the related art has not been described in detail in order to avoid unnecessarily obscuring the inventive body Work.

0054Commonly-assigned U.S. patent application Ser. No. 10/863,551, Pub. No. 2005/0027871 A1 (“the '551 application”), which is hereby incorporated by reference, describes embodiments of a digital rights management (DRM) architecture and a novel DRM engine that overcome some of the weaknesses that characterize many previous DRM implementations. The present application describes enhancements, extensions, and modifications to, as well as alternative embodiments of, the architecture and DRM engine described in the '551 application, as well as new components, architectures, and embodiments. It will thus be appreciated that the material described herein can be used in the context of an architecture and/or DRM engine such as that described in the '551 application, as well as in other contexts.

00001. Example DRM System

0055<figref idref="DRAWINGS">FIG. 1</figref> shows an illustrative system <b>100</b> for managing electronic content. As shown in <figref idref="DRAWINGS">FIG. 1</figref>, an entity <b>102</b> holding rights in electronic content <b>103</b>, packages the content for distribution and consumption by end users <b>108</b><i>a</i>-<i>e </i>(referred to collectively as “end users <b>108</b>,” where reference numeral <b>108</b> refers interchangeably to the end user or the end user's computing system, as will be clear from the context). For example, entity <b>102</b> may comprise a content owner, creator, or provider, such as a musician, movie studio, publishing house, software company, author, mobile service provider, Internet content download or subscription service, cable or satellite television provider, the employee of a corporation, or the like, or an entity acting on behalf thereof, and content <b>103</b> may comprise any electronic content, such as digital video, audio, or textual content, a movie, a song, a video game, a piece of software, an email message, a text message, a word processing document, a report, or any other entertainment, enterprise, or other content.

0056In the example shown in <figref idref="DRAWINGS">FIG. 1</figref>, entity <b>102</b> uses a packaging engine <b>109</b> to associate a license <b>106</b> with the packaged content <b>104</b>. License <b>106</b> is based on the policies <b>105</b> or other wishes of entity <b>102</b>, and specifies permitted and/or prohibited uses of the content and/or one or more conditions that must be satisfied in order to make use of the content, or that must be satisfied as a condition or consequence of use. The content may also be secured by one or more cryptographic mechanisms such as encryption or digital signature techniques, for which a trust authority <b>110</b> may be used to obtain the appropriate cryptographic keys, certificates, and/or the like.

0057As shown in <figref idref="DRAWINGS">FIG. 1</figref>, packaged content <b>104</b> and licenses <b>106</b> can be provided to end users <b>108</b> by any suitable means, such as via a network <b>112</b> like the Internet, a local area network <b>103</b>, a wireless network, a virtual private network <b>107</b>, a wide area network, and/or the like, via cable, satellite, broadcast, or cellular communication <b>114</b>, and/or via recordable media <b>116</b> such as a compact disc (CD), digital versatile disk (DVD), a flash memory card (e.g., an Secure Digital (SD) card), and/or the like. Packaged content <b>104</b> can be delivered to the user together with license <b>106</b> in a single package or transmission <b>113</b>, or in separate packages or transmissions received from the same or different sources.

0058The end user's system (e.g., a personal computer <b>108</b><i>e</i>, a mobile telephone <b>108</b><i>a</i>, a television and/or television set-top box <b>108</b><i>c</i>, a portable audio and/or video player, an eBook reader, and/or the like) contains application software <b>116</b>, hardware, and/or special-purpose logic that is operable to retrieve and render the content. The user's system also includes software and/or hardware, referred to herein as a digital rights management engine <b>118</b>, for evaluating the license <b>106</b> associated with the packaged content <b>104</b> and enforcing the terms thereof (and/or enabling application <b>116</b> to enforce such terms), such as by selectively granting the user access to the content only if permitted by the license <b>106</b>. Digital rights management engine. <b>118</b> may be structurally or functionally integrated with application <b>116</b>, or may comprise a separate piece of software and/or hardware. Alternatively, or in addition, a user's system, such as system <b>108</b><i>c</i>, may communicate with a remote system, such as system <b>108</b><i>b</i>, (e.g., a server, another device in the user's network of devices, such as a personal computer or television set-top box, and/or the like) that uses a digital rights management engine to make a determination <b>120</b> as to whether to grant the user access to content previously obtained or requested by the user.

0059The digital rights management engine, and/or other software on the user's system, or in remote communication therewith, may also record information regarding the user's access to or other use of the protected content. In some embodiments, some or all of this information might be communicated to a remote party (e.g., a clearinghouse <b>122</b>, the content creator, owner, or provider <b>102</b>, the user's manager, an entity acting on behalf thereof, and/or the like), e.g., for use in allocating revenue (such as royalties, advertisement-based revenue, etc.), determining user preferences, enforcing system policies (e.g., monitoring how and when confidential information is used), and/or the like. It will be appreciated that while <figref idref="DRAWINGS">FIG. 1</figref> shows an illustrative DRM architecture and a set of illustrative relationships, the systems and methods described herein can be practiced in any suitable context, and thus it will be appreciated that <figref idref="DRAWINGS">FIG. 1</figref> is provided for purposes of illustration and explanation, not for purposes of limitation.

0060<figref idref="DRAWINGS">FIG. 2</figref> shows a more detailed example of a system <b>200</b> that could be used to practice embodiments of the inventive body of work. For example, system <b>200</b> might comprise an embodiment of an end user's device <b>108</b>, a content provider's device <b>109</b>, and/or the like. For example, system <b>206</b> may comprise a general-purpose computing device such as a personal computer <b>108</b><i>e </i>or network server <b>105</b>, or a specialized computing device such as a cellular telephone <b>108</b><i>a</i>, personal digital assistant, portable audio or video player, television set-top box, kiosk, gaming system, or the like. System <b>200</b> will typically include a processor <b>202</b>, memory <b>204</b>, a user interface <b>206</b>, a port <b>207</b> for accepting removable memory <b>208</b>, a network interface <b>210</b>, and one or more buses <b>212</b> for connecting the aforementioned elements. The operation of system <b>200</b> will typically be controlled by processor <b>202</b> operating under the guidance of programs stored in memory <b>204</b>. Memory <b>204</b> will generally include both high-speed random-access memory (RAM) and non-volatile memory such as a magnetic disk and/or flash EEPROM. Some portions of memory <b>204</b> may be restricted, such that they cannot be read from or written to by other components of the system <b>200</b>. Port <b>207</b> may comprise a disk drive or memory slot for accepting computer-readable media <b>208</b> such as floppy diskettes, CD-ROMs, DVDs, memory cards, SD cards, other magnetic or optical media, and/or the like. Network interface <b>210</b>. is typically operable to provide a connection between system <b>200</b> and other computing devices (and/or networks of computing devices) via a network <b>220</b> such as the Internet or an intranet (e.g., a LAN, WAN, VPN, etc.), and may employ one or more communications technologies to physically make such connection (e.g., wireless, Ethernet, and/or the like). In some embodiments, system <b>200</b> might also include a processing unit <b>203</b> that is protected from tampering by a user of system <b>200</b> or other entities. Such a secure processing unit can help enhance the security of sensitive operations such as key management, signature verification, and other aspects of the digital rights management process.

0061As shown in <figref idref="DRAWINGS">FIG. 2</figref>, memory <b>204</b> of computing device <b>200</b> may include a variety of programs or modules for controlling the operation of computing device <b>200</b>. For example, memory <b>204</b> will typically include an operating system <b>220</b> for managing the execution of applications, peripherals, and the like; a host application <b>230</b> for rendering protected electronic content; and a DRM engine <b>232</b> for implementing some or all of the rights management functionality described herein. As described elsewhere herein, DRM engine <b>232</b> may comprise, interoperate with, and/or control a variety of other modules, such as a virtual machine <b>222</b> for executing control programs, and a state database <b>224</b> for storing state information for use by virtual machine <b>222</b>, and/or one or more cryptographic modules <b>226</b> for performing cryptographic operations such as encrypting and/or decrypting content, computing hash functions and message authentication codes, evaluating digital signatures, and/or the like. Memory <b>204</b> will also typically include protected content <b>228</b> and associated licenses <b>229</b>, as well as cryptographic keys, certificates, and the like (not shown).

0062One of ordinary skill in the art will appreciate that the systems and methods described herein can be practiced with computing devices similar or identical to that illustrated in <figref idref="DRAWINGS">FIG. 2</figref>, or with virtually any other suitable computing device, including computing devices that do not possess some of the components shown in <figref idref="DRAWINGS">FIG. 2</figref> and/or computing devices that possess other components that are not shown. Thus it should be appreciated that <figref idref="DRAWINGS">FIG. 2</figref> is provided for purposes of illustration and not limitation.

0063A digital rights management engine and related systems and methods are described herein that can be used to provide some or all of the rights management functionality of systems such as those shown in <figref idref="DRAWINGS">FIGS. 1 and 2</figref>, or in other types of systems. In addition, a variety of other systems and methods are described below that could be used in the context of systems such as those shown in <figref idref="DRAWINGS">FIGS. 1 and 2</figref>, as well as in other contexts, including contexts unrelated to digital rights management.

00002. DRM Engine Architecture

0064In one embodiment a relatively simple, open, and flexible digital rights management (DRM) engine is used to implement core DRM functions. In a preferred embodiment, this DRM engine is designed to integrate relatively easily into a web services environment such as that described in the '551 application, and into virtually any host environment or software architecture. In a preferred embodiment, the DRM engine is independent of particular media formats and cryptographic protocols, allowing designers the flexibility to use standardized or proprietary technologies as required by the particular situation. The governance model used by preferred embodiments of the DRM engine is simple, but can be used to express sophisticated relationships and business models.

0065Some of the illustrative embodiments of a DRM engine that are described below relate to an example implementation referred to as “Octopus”; however, it will be appreciated that the present inventions are not limited to the specific details of the Octopus example, which are provided for purposes of illustration, not limitation.

00661.1. Overview

0067<figref idref="DRAWINGS">FIG. 3</figref> shows how an illustrative DRM engine <b>303</b><i>a </i>might function in a system <b>302</b> that uses DRM. As shown in <figref idref="DRAWINGS">FIG. 3</figref>, in one embodiment DRM engine <b>303</b><i>a </i>is embedded or integrated within a host application <b>304</b><i>a </i>(e.g., a content rendering application such as an audio and/or video player, a text-rendering application such as an email program, word processor, eBook reader, or document reader, and/or the like) or is in communication therewith. In one embodiment, DRM engine <b>303</b><i>a </i>performs DRM functions and relies on host application <b>304</b><i>a </i>for services such as encryption, decryption, file management, and/or other functions can be more effectively provided by the host. For example, in a preferred embodiment DRM engine <b>303</b><i>a </i>is operable to manipulate the DRM objects <b>305</b> which comprise a license <b>306</b> to protected content <b>308</b>. In some embodiments, DRM engine <b>303</b><i>a </i>may also delivers keys to host application <b>304</b><i>a</i>. As shown in <figref idref="DRAWINGS">FIG. 3</figref>, either or both of DRM engine <b>303</b><i>a </i>and host application <b>304</b><i>a </i>may make use of web services <b>305</b><i>a </i>and/or host services <b>306</b><i>a </i>for processing and/or information needed to complete their respective tasks. The '551 application provides examples of such services, and the manner in which a DRM engine <b>303</b><i>a </i>and host application <b>304</b><i>a </i>might interoperate therewith.

0068In the example shown in <figref idref="DRAWINGS">FIG. 3</figref>, DRM engine <b>303</b><i>a</i>, host application <b>304</b><i>a</i>, host services <b>306</b><i>a</i>, and web services interface <b>305</b><i>a </i>are loaded onto a device <b>300</b><i>a</i>, such as an end user's personal computer (PC). Device <b>300</b><i>a </i>is communicatively coupled to a server <b>300</b><i>b</i>, from which content <b>308</b> and license <b>306</b> were obtained, as well as a portable device <b>300</b><i>d</i>, to which device <b>300</b><i>a </i>may forward content <b>308</b> and/or license <b>306</b>. Each of these other devices may include a DRM engine <b>303</b> that is similar or identical to DRM engine <b>300</b><i>a</i>, which can be integrated with the particular host application and host environment of the device. For example, server <b>300</b><i>b </i>might include a host application <b>304</b><i>b </i>that performs bulk packaging of content and/or licenses, and makes use of a DRM engine <b>300</b><i>a </i>to evaluate controls associated with the content that is being packaged in order to comply with any redistribution restrictions. Similarly, device <b>300</b><i>c </i>might include a host application <b>304</b><i>c </i>that is capable of both rendering and packaging content, while device <b>300</b><i>a </i>might include a host application that is simply able to render content. As yet another example of the potential diversity of host environments, device <b>300</b><i>d </i>might not include a web services interface, but may instead rely on communication with device <b>300</b><i>a</i>, and web services interface <b>305</b><i>a </i>to the extent host application <b>304</b><i>d </i>and/or DRM engine <b>303</b><i>d </i>require the use of any web services. <figref idref="DRAWINGS">FIG. 3</figref> is only one example of a system in which a DRM engine might be used; it will be appreciated that embodiments of the DRM engines described herein can be implemented and integrated with applications and systems in many different ways, and are not limited to the illustrative examples shown in <figref idref="DRAWINGS">FIG. 3</figref>.

00691.2. Objects

0070In preferred embodiments, content protection and governance objects are used to represent entities in a system, to protect content, to associate usage rules with the content, and to determine if access can be granted when requested.

0071As described in more detail below, in one embodiment, the following objects are used: <tables id="TABLE-US-00001" num="1"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="49PT" align="left" /><colspec colname="2" colwidth="154PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row><row><entry /><entry>Object Type</entry><entry>Function</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Node</entry><entry>Represents entities</entry></row><row><entry /><entry>Link</entry><entry>Represents a directed relationship between</entry></row><row><entry /><entry /><entry>entities</entry></row><row><entry /><entry>Content</entry><entry>Represents content (e.g., media content)</entry></row><row><entry /><entry>ContentKey</entry><entry>Represents encryption keys used to encrypt</entry></row><row><entry /><entry /><entry>content</entry></row><row><entry /><entry>Control</entry><entry>Represents usage rules that govern interaction</entry></row><row><entry /><entry /><entry>with content</entry></row><row><entry /><entry>Controller</entry><entry>Represents associations between Control and</entry></row><row><entry /><entry /><entry>ContentKey objects</entry></row><row><entry /><entry>Protector</entry><entry>Represents associations between Content and</entry></row><row><entry /><entry /><entry>ContentKey objects</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

00721.2.1. Node Objects

0073Node objects are used to represent entities in the system. In practice, a node will usually represent a user, a device, or a group. Node objects will also typically have associated attributes that represent certain properties of the entity associated with the node.

0074For example, <figref idref="DRAWINGS">FIG. 4</figref> shows two users (Xan <b>400</b> and Knox <b>402</b>), two devices (PC <b>404</b> and portable device <b>406</b>), and several entities that represent groups (e.g., members of the Carey family <b>408</b>, members of the public library <b>410</b>, subscribers to a particular music service <b>412</b>, RIAA-approved devices <b>414</b>, and devices manufactured by a specific company <b>416</b>), each having an associated node object.

0075In one embodiment node objects include attributes that define what the node represents. One example of an attribute is a node type. Besides representing users, groups, or devices, the node type attribute could be used to represent other entities. In some embodiments, a node object can also include cryptographic key information, such as when an embodiment of the key derivation and distribution techniques described elsewhere herein is used.

0076In some embodiments, node objects also include a confidentiality asymmetric key pair that is used for targeting confidential information to the subsystems that have access to the confidential parts of the node object. This could be the entity that the node represents (for example, the Music Service <b>412</b>) or some entity responsible for managing the node (for example, the end user (e.g., Knox <b>402</b>) could be responsible for managing his or her portable device <b>406</b>).

00771.2.2. Link Objects

0078In a preferred embodiment, link objects are signed objects used to show the relationship between two nodes. For example, in <figref idref="DRAWINGS">FIG. 4</figref> the link <b>418</b> from the PC node <b>404</b> to Knox <b>402</b> shows ownership. The link from Knox <b>402</b> to the Carey family node <b>408</b> shows membership, as does the link from the Carey family node <b>408</b> to the Music Service Subscribers node <b>412</b>. In one embodiment, link objects express the relationship between two nodes, and thus the relationships shown in <figref idref="DRAWINGS">FIG. 4</figref> could be represented using ten links.

0079As shown in <figref idref="DRAWINGS">FIG. 4</figref>, a graph <b>420</b> can be used to express the relationship between nodes, where link objects are the directed edges between nodes. For example, in <figref idref="DRAWINGS">FIG. 4</figref>, the relationship between the Carey family node <b>408</b> and the Music Service node <b>412</b> asserts that there exists a directed edge <b>422</b> in the graph whose vertices are the Carey family node <b>408</b> and the Music Service node <b>412</b>. Knox <b>402</b> and Xan <b>400</b> are members of the Carey family <b>408</b>. Because Knox <b>402</b> is linked to the Carey family <b>408</b> and the Carey family <b>408</b> is linked to the Music Service <b>412</b> there is said to be a path between Knox <b>402</b> and the Music Service <b>412</b>. A DRM engine considers a node to be reachable from another node when there is a path from that node to the other node. This allows a control to be written that allows permission to access protected content based on the condition that a node is reachable from the device where the application that requests access to the protected content is executing.

0080As described in more detail below, link objects can also optionally contain some cryptographic data that allows derivation of content keys. Link objects may also contain control programs that define the conditions under which the link may be deemed to be valid. Such control programs can be executed or interpreted (these terms are used interchangeably herein) by a DRM engine's virtual machine to evaluate the validity of a link (e.g., to determine whether the link may be used to reach a given node in an authorization graph).

0081In one embodiment, links are signed. Any suitable digital signature mechanism can be used, and in one embodiment the DRM engine does not define how the link objects are signed and does not evaluate any associated certificates, instead, it relies on the host system to verify any such signatures and/or certificates. This allows the system architect or administrator to define the lifetime of a link object, to revoke it, and so on (e.g., by using expiring keys or certificates, revocation, and/or the like), thus providing an additional layer of policy management and security on top of the policy management and security provided by the DRM engine's evaluation of control programs and DRM objects in the context of specific pieces of protected content and/or links (for example, expiration of a link could alternatively, or in addition, be implemented by including an appropriate control program in the link object itself, which, when executed would enforce the expiration date or other validity period). In one embodiment, the DRM engine is generic, and works with any suitable encryption, digital signature, revocation, and/or other security scheme that is used by the host application and/or environment. Thus, for example, if the DRM engine needs to determine if a particular link has been properly signed, it might simply call the host application (and/or a host or system cryptographic service) to verify the signature in accordance with the particular signature scheme chosen by the system designer, the-details of which the DRM engine itself may be unaware. In other embodiments, the DRM engine itself performs the actual signature evaluation, relying on the host simply to indicate the appropriate signature algorithm to use.

00821.2.3. Content Protection and Governance

0083Referring once again to <figref idref="DRAWINGS">FIG. 3</figref>, in a typical scenario, a content provider <b>300</b><i>b </i>uses an application <b>304</b><i>b </i>that includes a packaging engine to encrypt or otherwise cryptographically secure a piece of electronic content <b>308</b> and creates a license <b>306</b> that governs access to or other use of that content. In one embodiment, license <b>308</b> comprises a set of objects <b>305</b> that specify how content <b>308</b> may be used, and also includes the content's encryption key(s) and/or the information needed to obtain them. In one embodiment, content <b>308</b> and license <b>306</b> are logically separate, but are bound together by internal references (e.g., using object IDs <b>310</b>). In many situations it may be convenient to store and/or deliver the content and the license together; however, this is not required in preferred embodiments. In one embodiment, a license can apply to more than one item of content, and more than one license can apply to any single item of content.

0084As shown in <figref idref="DRAWINGS">FIG. 3</figref>, when a host application <b>304</b><i>a </i>running on a client device <b>300</b><i>a </i>wants to perform an action on a particular piece of content <b>308</b>, it asks DRM engine <b>303</b><i>a </i>to check if the action it intends to perform (e.g., “play”) is allowed. In one embodiment, the DRM engine <b>303</b><i>a </i>will, from the information contained in the objects <b>305</b> comprising content license <b>306</b>, load and execute a control program associated with content <b>308</b>, and permission to perform the action will be granted or denied based on the result returned by the control program. Permission will typically require that some conditions be met, such as the condition that a node be reachable from the node representing the requesting entity/device <b>300</b><i>a. </i>

0085<figref idref="DRAWINGS">FIG. 5</figref> is a flowchart illustrating how an embodiment of a DRM engine might determine whether a requested action (e.g., viewing a piece of content) is authorized. As shown in <figref idref="DRAWINGS">FIG. 5</figref>, a request to evaluate a license for a given action is received (<b>500</b>). For example, this request might be received from the host application, after the host received a request from a user to perform the specified action. As shown in <figref idref="DRAWINGS">FIG. 5</figref>, the DRM engine evaluates the specified license (<b>502</b>), and determines whether the requested action is authorized (<b>504</b>). For example, the license may contain a control program that the DRM engine executes, the output of which is used to make the authorization decision. If the license authorizes the requested action (i.e., a “yes” exit from block <b>504</b>), then the DRM engine indicates to the. host application that the request is granted (<b>506</b>). Otherwise, the DRM engine indicates to the host application that the request is denied (<b>508</b>). In some embodiments, the DRM engine may also return to the host application a variety of metadata that e.g., associates conditions with a grant of authorization (e.g., obligations and/or callbacks), or provides additional information regarding the cause of a denial of authorization. For example, the DRM engine may indicate that the requested-action is allowed only if the host application logs certain information regarding performance of the requested action, or as long as the host application calls the DRM engine back at predefined time intervals to, e.g., re-evaluate the license. Additional information on such obligations, callbacks, and other metadata returned by the DRM engine is provided below. If the requested action is authorized, the content key will be retrieved (e.g., from the license's ContentKey object), and used to release the content for the requested use.

00861.2.4. License DRM Objects

0087As shown in <figref idref="DRAWINGS">FIG. 6</figref>, in preferred embodiment a license <b>600</b> is a collection of objects. In the example shown in <figref idref="DRAWINGS">FIG. 6</figref>, license <b>600</b> comprises a ContentKey object <b>602</b>, a protector object <b>604</b>, a controller object <b>606</b>, and a control object <b>608</b>. As shown in <figref idref="DRAWINGS">FIG. 6</figref>, ContentKey object <b>602</b> includes encrypted key data <b>610</b> (e.g., an encrypted version of the key needed to decrypt encrypted content item <b>612</b>) and information regarding the cryptosystem used to encrypt the key data. Protector object <b>604</b> binds ContentKey object <b>602</b> to one or more content objects <b>614</b>. As shown in <figref idref="DRAWINGS">FIG. 6</figref>, control object <b>608</b> includes and protects a control program <b>616</b> that specifies how content object <b>614</b> is governed. In a preferred embodiment, control program <b>616</b> is a piece of executable bytecode that runs on a virtual machine operated by the DRM engine. The control program governs whether certain actions can be performed on the content by checking for satisfaction of conditions specified in the control program, such as whether certain nodes are reachable using valid link objects, whether certain state objects have been stored, whether the host environment has certain characteristics, and/or the like. Referring once again to <figref idref="DRAWINGS">FIG. 6</figref>, controller object <b>606</b> is used to bind one or more ContentKey object <b>602</b> to control object <b>608</b>.

0088License <b>600</b> may also comprise additional objects, such as metadata providing a machine- or human-readable description of the content-access conditions required by the license. Alternatively, or in addition, such metadata can be included as a resource extension of one of the other objects (e.g., control object <b>608</b>). In the embodiment shown in <figref idref="DRAWINGS">FIG. 6</figref>, control object <b>608</b> and controller object <b>606</b> are both signed, so that the system can verify that the control information is from a trusted source before using it to make content-access decisions. In one embodiment, the validity of control object <b>608</b> can also be checked through verification of a secure hash included in controller object <b>606</b>. Controller object <b>606</b> can also contain a hash value for each of the keys or other key data contained in the ContentKey object(s) <b>602</b> that it references, thereby rendering it relatively difficult for an attacker to tamper with the binding between the key data and the ContentKey object.

0089As shown in <figref idref="DRAWINGS">FIG. 6</figref>, in one embodiment content <b>612</b> is encrypted and is included in a content object <b>614</b>. The decryption key <b>610</b> that is used is included within (or referenced by) ContentKey object <b>602</b>, and the binding between the two is represented by the protector object <b>604</b>. As shown in <figref idref="DRAWINGS">FIG. 6</figref>, unique IDs are used to facilitate the binding between content object <b>614</b> and ContentKey object <b>602</b>. The rules that govern the use of key <b>610</b> to decrypt content <b>612</b> are included within control object <b>608</b>, and the binding between control object <b>608</b> and ContentKey <b>602</b> is represented by controller object <b>606</b>, again using unique IDs.

0090It will be appreciated that while <figref idref="DRAWINGS">FIG. 6</figref> shows the objects that comprise a license in one preferred embodiment, the DRM systems and methods described herein are not limited to the use of this license structure. For example, without limitation, licenses could be used in which the functionality of the various objects shown in <figref idref="DRAWINGS">FIG. 6</figref> are combined in a smaller number of objects, or spread out over additional objects, or broken up between objects in a different manner. Alternatively, or in addition, embodiments of the systems and methods described herein can be practiced with licenses that lack some of the functionality enabled by the license structure shown in <figref idref="DRAWINGS">FIG. 6</figref>, and/or that provide additional functionality. Thus it will be appreciated that any suitable mechanism for associating licenses with content can be used in accordance with the principles described herein, although in preferred embodiments the advantageous structure shown in <figref idref="DRAWINGS">FIG. 6</figref> is used.

00911.3. State Database

0092In one embodiment, the DRM engine includes, or has access to, a secure, persistent object store that can be used to provide a secure state storage mechanism. Such a facility is useful to enable control programs to be able to read and write state information that is persistent from invocation to invocation. Such a state database can be used to store state objects such as play-counts, date of first use, accumulated rendering times, and/or the like, as well as membership status, and/or any other suitable data. In some embodiments, a DRM engine executing on a first system may not have access to a local state database, and may be operable to access a remote state database, e.g., using web and/or host services. In some situations, it may be necessary for a DRM engine executing on a first system to access state information stored in a database on a remote system. For example the first system may not include a state database, or may not have the information it needs in its own state database. In some embodiments, when a DRM engine is faced with such a situation, it might access a remote state database via a services interface, and/or by using agent programs, as described in more detail below.

00931.4. About Control Programs

0094The systems and methods described herein make use of control programs in a variety of contexts. For example, control programs contained in control objects can be used to express the rules and conditions governing the use of protect content. In addition, control programs in link objects can be used to express the rules and conditions used to determine whether the link is valid for a given purpose (e.g., a node reachability analysis). Such control programs are sometimes referred to herein as link constraints. Yet another context in which control programs may be used is in agent or delegate objects, were the control code is used to perform an action on behalf of another entity (in the case of agent control programs) or on behalf of another control (in the case of delegate control programs).

0095In one embodiment, control programs are executed or interpreted by a virtual machine hosted by a DRM engine, as opposed to being executed directly by a physical processor. It will be appreciated, however, that a physical processor or other hardware logic could be readily constructed to execute control programs. In one embodiment, the control programs are in byte-code format, which facilitates interoperability across platforms.

0096In a preferred embodiment, control programs are written in assembly language and converted into byte code by an assembler program. In other embodiments, templates and/or high-level rights expression languages could be used to provide the initial expression of rights, rules, and/or conditions, and a compiler could be used to convert the high-level expression into byte code for execution by an embodiment of the DRM engine described herein. For example, rights expressions written in a proprietary DRM format could, with an appropriate compiler, be converted or translated into a functionally equivalent byte code expression for execution on an embodiment of the DRM engine described herein, thus enabling a protected piece of content to be used, in accordance with the conditions specified by the content provider, on systems that understand the proprietary DRM format, as well as systems that included a DRM engine such as that described herein. It should also be appreciated that the digital rights management engine systems and methods described herein are not limited to the use of byte code rights expressions, interpreted by a virtual machine. Instead, in some embodiments, rights can be expressed in any suitable manner (e.g., using a high-level rights expression language (REL), a template, etc.), and the authorization graph and/or other techniques described herein performed using an application program designed to recognize and evaluate such rights expressions.

00971.4.1. Conditions

0098As previously indicated, control programs typically express one or more conditions that must be satisfied in order for a request to use a piece of content to be granted, for a link to be deemed valid, and/or the like. Any suitable conditions can be used, depending on the requirements of the content provider or system architect, and/or the functionality provided by the system.

0099In preferred embodiments, the virtual machine used by the DRM engine supports arbitrarily complex programs that are capable of testing for conditions such as some or all of the following: <ul id="ul0001" list-style="none"><li id="ul0001-0001" num="0100"> Time-based conditions: Comparing a client time value to a value or values specified in the control program. </li><li id="ul0001-0002" num="0101"> Targeting a particular node: Checking whether a certain node is reachable from another node. This concept provides support for such models as domains, subscriptions, memberships, and the like. </li><li id="ul0001-0003" num="0102"> Testing if certain node attributes match specified values: Checking any of a node's attributes, such as, for example, whether the rendering capabilities of a device associated with a node meet fidelity requirements. </li><li id="ul0001-0004" num="0103"> Testing if the security-related metadata at the client is up-to-date: Checking, for example, whether the client has an acceptable version of the client software and an accurate measure of time. In some embodiment, such a check might rely, for example, on assertions in one or more certificates from a data certification service. </li><li id="ul0001-0005" num="0104"> State-based conditions: Checking information in the state database. For example, the state database may contain information generated as a result of previous execution of control programs, and/or tokens attesting to ownership of subscriptions, membership, and/or the like, thereby enabling evaluation of conditions involving counters (e.g., number of plays, number of exports, elapsed time limits, etc.) and other information regarding recorded events and conditions. </li><li id="ul0001-0006" num="0105"> Environmental characteristics: For example, checking whether hardware and/or software in the host environment has certain characteristics, such as the ability to recognize and enforce obligations; checking for the presence or absence of certain software or hardware components, such as a secure output channel; checking proximity information, such as the proximity of a requesting device to another device or application; checking the characteristics of, and/or data stored on, remote systems using network services and/or agents; and/or the like. </li></ul>

0106Using these or any other suitable conditions, a control object can express rules that govern how content can be rendered, transferred, exported, and/or the like. It will be appreciated that the above list of conditions is illustrative in nature, and that any suitable conditions could be defined and used by, e.g., implementing a system call for use in testing for the desired condition. For example, without limitation, if it were desired to require that a device be located on a particular sub-network, a system call could be defined (e.g., GetIPConfig) that would be operable to return the host device's IPConfig information (or a remote device's IPConfig information, if the system call were run on a remote device using an agent), which could be used by a control program to test for whether the device was located on the prescribed sub-network.

01071.4.2. Agents

0108Preferred embodiments of the DRM engine-related systems and methods described herein provide support for independent objects that carry control programs. Such “agents” can be distributed to a DRM engine running on a remote system in order to accomplish specified functions, such as writing into the remote DRM engine's secure state store. For example, an agent could be sent as a consequence of contacting a remote service, or executing a remote control program. An agent can also be used to effect a content move operation, to initialize a counter, to deregister a node, and/or the like. As yet another example, an agent could be used to perform a reachability analysis from a remote node to another node. Such an agent could, e.g., be useful in enforcing a policy that prohibited a device registered to a first user from being registered to a second user. If the second user requested registration, an agent could be sent to the device by the second user, or a registration service acting on his or her behalf, to determine if the device was already registered to the first user, in which case the second user's registration request would be denied.

0109<figref idref="DRAWINGS">FIGS. 7A and 7B</figref> illustrate the use of agents in one embodiment. As shown in <figref idref="DRAWINGS">FIG. 7A</figref>, assume that two entities—system A <b>700</b> and system B <b>702</b>—wish to communicate with each other over a computer network <b>703</b>, and that a DRM system is being used that is capable of describing and enforcing rules for certain operations, such as accessing protected content, or creating DRM objects that can be used to represent memberships, registration status, and/or the like. In some cases, the rule(s) will be evaluated on system A <b>700</b>, but will require information that depends on the state of system B <b>702</b>. That information needs to be trusted by the DRM system <b>704</b> that is enforcing the rule(s) on system A <b>700</b>.

0110For example, the DRM system <b>704</b> on system A <b>700</b> may be evaluating/enforcing a rule for performing a remote rendering of content from system A <b>700</b> to system B <b>702</b>, and the rule might indicate that such an operation is permitted only if system B <b>702</b> is part of a certain group of devices, where the membership in that group is asserted by the presence of a state object <b>711</b> in a secure state database <b>716</b> accessible on system B <b>702</b>.

0111A method used in a preferred embodiment to handle such situations makes use of agents. For example, if system A <b>700</b> needs information from system B <b>702</b>, system A <b>700</b> prepares an agent <b>705</b>, which, in one embodiment, is a control program (e.g., a sequence of instructions that can be executed by a DRM engine) that is sent from system A <b>700</b> to system B <b>702</b>. In one embodiment, system A <b>700</b> sends agent code <b>705</b> to system B <b>702</b> over an authenticated communication channel <b>720</b> so that system A <b>700</b> can be confident that it is indeed on system B <b>702</b> that agent <b>705</b> will run. In some embodiments, along with agent code <b>705</b>, system A <b>700</b> may also communicates to system B <b>702</b> one or more parameters that may be used by agent code <b>705</b> to perform its work.

0112As shown in <figref idref="DRAWINGS">FIG. 7B</figref>, system B <b>702</b> receives agent <b>705</b> and any associated agent parameters, and runs the agent code <b>705</b>. When agent <b>705</b> is run on system B <b>702</b>, it accesses system B's state database <b>716</b>, retrieves state information <b>711</b> and/or performs one or more computations therewith, and sends the results <b>713</b> back to system A <b>700</b>, preferably over authenticated communication channel <b>710</b>. At this point, system A <b>700</b> has the information it needs to continue with its evaluation.

01131.4.3. Link Constraints

0114In one embodiment, the set of routines that represent the rules that govern the performance of a certain operation (such as “play”) on a content item is called an “action control”. The set of routines that represent validity constraints on a link object is called a “link constraint”. Like action controls, in preferred embodiments link constraints can express any suitable combination of conditions. Also like action controls, link constraints can be evaluated locally and/or remotely using a services interface or an agent.

01151.4.4. Obligations and Callbacks

0116In one embodiment, certain actions, when granted, require further participation from the host application. Obligations represent operations that need to be performed by the host application upon or after the use of the content key it is requesting. Callbacks represent calls to one or more of the control program's routines that need to be performed by the host application upon or after the use of the content key it is requesting. Examples of obligations include, without limitation, a requirement that certain outputs and/or controls be turned off while content is being rendered (e.g., to prevent writing the content to an unprotected output or to prevent fast-forwarding through certain important segments of the content); a requirement that information regarding use of the content be recorded (e.g., metering or audit information) and/or sent to a remote site (e.g., a clearinghouse, service provider, or the like); a requirement that an agent program be executed locally or remotely; and/or the like. Examples of callbacks include, without limitation a requirement that the host call the control program back at a certain absolute time, after a certain elapsed time (e.g., an elapsed time of content usage), after occurrence of a certain event (e.g., the completion of a trial content-rendering period), when the content has stopped being used, and/or the like. For example, a callback after a certain elapsed time could be used to increment or decrement budgets, playcounts, and the like (e.g., only debiting the users budget if they use a piece of content for at least a certain amount of time), thus protecting the user from having his or her account debited if he or she accidently presses the play button but immediately presses stop.

0117In one embodiment, there are different types of obligations and callbacks, and if an application encounters any critical obligation or callback that it does not support, or does not understand (for example because the obligation type may have been defined after the application was implemented), the application is required to refuse to continue the action for which this obligation or callback parameter was returned.

01181.4.5. Example

0119<figref idref="DRAWINGS">FIGS. 8-12</figref> show an example of how an illustrative embodiment of a DRM engine might control the use of a piece of content. Referring to <figref idref="DRAWINGS">FIG. 8</figref>, assume that the DRM engine has received a request to play a group <b>800</b> of content items <b>802</b>, <b>804</b>. For example, content items <b>802</b>, <b>804</b> might comprise different sub-parts of a multimedia presentation, different tracks of an album, different pieces of content obtained from a subscription service, email attachments, or the like. The request may have been received by the DRM engine from a host application, which, in turn, received the request from a user of the computing device upon which the host application was running. The request from the host application will typically identify the requested action, the piece or pieces of content upon which the action is to be taken, and the license(s) that govern the content. DRM engine follows the process illustrated in <figref idref="DRAWINGS">FIG. 5</figref> to determine whether the request should be granted.

0120<figref idref="DRAWINGS">FIGS. 8 and 9</figref> provide a more detailed non-limiting example of the process shown in <figref idref="DRAWINGS">FIG. 5</figref>. Referring to <figref idref="DRAWINGS">FIG. 9</figref>, upon receiving the request to access content items <b>802</b> and <b>804</b> (block <b>900</b>), the DRM engine examines the license(s) identified in the request, or otherwise in its possession, to see if a valid license exists. For example, the DRM engine might first identify the protector objects <b>806</b> and <b>808</b> that contain the unique identifiers of content items <b>802</b> and <b>804</b> (i.e., NS:007 and NS:008respectively)(block <b>902</b> in <figref idref="DRAWINGS">FIG. 9</figref>). Next, the DRM engine locates the ContentKey objects <b>810</b> and <b>812</b> identified in protector objects <b>806</b> and <b>808</b> (block <b>904</b> in <figref idref="DRAWINGS">FIG. 9</figref>), which, in turn, enables the DRM engine to identify controller <b>814</b> which references both ContentKey objects <b>810</b> and <b>812</b> (block <b>906</b> in <figref idref="DRAWINGS">FIG. 9</figref>). In a preferred embodiment, controller <b>814</b> is signed, and DRM engine verifies its signature (or asks host services to verify it). The DRM engine uses controller <b>814</b> to identify the control object <b>816</b> that governs use of ContentKey objects <b>810</b> and <b>812</b> (and, thus, content items <b>802</b> and <b>804</b>)(block <b>908</b> in <figref idref="DRAWINGS">FIG. 9</figref>). In a preferred embodiment, the DRM engine verifies the integrity of control object <b>816</b> (e.g., by computing a digest of control object <b>816</b> and comparing it to a digest contained in controller <b>814</b>. If the integrity verification succeeds, the DRM engine executes the control code contained in control object <b>816</b> (block <b>910</b>), and returns the result (block <b>912</b>) to the host application, which uses it to grant or deny the user's request to access the content. The result of the control code might also optionally specify one or more obligations or callbacks which the host application will need to fulfill.

0121<figref idref="DRAWINGS">FIG. 10</figref> is a more detailed example of how a DRM engine might perform the actions specified in blocks <b>910</b> and <b>912</b> of <figref idref="DRAWINGS">FIG. 9</figref> (i.e., executing a control program and returning the result). As shown in <figref idref="DRAWINGS">FIG. 10</figref>, upon identifying the relevant control object, the DRM engine loads the byte code contained in the control object into a virtual machine that is preferably hosted by the DRM engine (block <b>1000</b>). The DRM engine and/or the virtual machine will also typically initialize the virtual machine's runtime environment (block <b>1002</b>). For example, the virtual machine might allocate the memory needed for execution of the control program, initialize registers and other environment variables, and/or obtain information about the host environment in which the virtual machine is operating (e.g., by making a System.Host.GetObject call, as described below). It will be appreciated that in some embodiments blocks <b>1000</b> and <b>1002</b> could effectively be combined or interleaved, and/or their order reversed. As shown in <figref idref="DRAWINGS">FIG. 10</figref>, the virtual machine next executes the control program's byte code (block <b>1004</b>). As described elsewhere herein, this may involve making calls to other virtual machine code, retrieving state information from secure storage, and/or the like. When the control program has finished executing, it provides an output (e.g., in a preferred embodiment, an ExtendedStatusBlock) that may, for example, be used by the calling application to determine whether a request has been granted, and, if so, whether any obligations or callbacks are associated therewith; whether a request has been denied, and, if so, the reason for denial; or whether any errors occurred during execution (block <b>1006</b>).

0122As previously indicated, the control code contained in control object <b>816</b> specifies the conditions or other requirements that must be satisfied in order to make the requested use of content items <b>802</b> and <b>804</b>. The systems and methods described herein enable the specification of arbitrarily complex sets of conditions; however, for purposes of this example, assume that the control program is designed to require that, in order to play content items <b>802</b> and <b>804</b>, (a) a given user's node must be reachable from the device on which the request to play the content was made, and (b) the current date must be after a specified date.

0123<figref idref="DRAWINGS">FIG. 11</figref> shows how an illustrative embodiment of a DRM engine <b>1100</b> running on a device <b>1102</b> might execute the example control program described above, and <figref idref="DRAWINGS">FIG. 12</figref> is a flowchart of the steps involved in the execution process. As shown in <figref idref="DRAWINGS">FIG. 11</figref>, DRM engine <b>1100</b> creates a virtual machine execution context (e.g., by calling System.Host.SpawnVm) <b>1104</b> and loads the control program. Virtual machine <b>1104</b> begins execution of the control program at the entry point specified by DRM engine <b>1100</b> (e.g., at the location of the Control.Actions.Play.perform routine). In this example, the control program needs to determine whether a given node is reachable from the personality node of the device <b>1102</b> on which the DRM engine <b>1100</b> is running. To make this determination, the control program makes a call <b>1105</b> to a link manager service <b>1106</b> provided by the DRM engine <b>1100</b>, specifying the node to which linkage is required (block <b>1200</b> in <figref idref="DRAWINGS">FIG. 12</figref>). Link manager <b>1106</b> is responsible for evaluating link objects to determine if one node is reachable from another. To do this efficiently, link manager <b>1106</b> may pre-compute whether a path exists from the personality node <b>1110</b> of device <b>1102</b> to the various nodes <b>1114</b> specified in any link objects that device <b>1102</b> possesses. That is, link manager <b>1106</b> may, simply by checking the “to” and “from” fields of the links to which it as access, determine which nodes are potentially reachable from the personality node <b>1110</b> of device <b>1102</b>. When link manager <b>1106</b> receives the call <b>1105</b> from virtual machine <b>1104</b>, it determines whether the specified node <b>1112</b> is reachable by first determining if a path exists from personality node <b>1110</b> to the specified node <b>1112</b> (e.g., by checking for the node's ID in the list of nodes that it previously determined to be theoretically reachable)(block <b>1202</b> in <figref idref="DRAWINGS">FIG. 12</figref>). If a path exists, link manager <b>1106</b> evaluates any control programs contained in the links to see if the links are valid (blocks <b>1204</b>-<b>1210</b> in <figref idref="DRAWINGS">FIG. 12</figref>). To evaluate the control programs in the link objects (block <b>1206</b> in <figref idref="DRAWINGS">FIG. 12</figref>), link manager <b>1106</b> may use its own virtual machine <b>1108</b>, on which it executes the control programs included in the link objects. Link manager <b>1106</b> returns the results of its determination (i.e., whether the given node is reachable) to the control program executing in virtual machine <b>1104</b>, where it is used in the overall evaluation of whether the request to play the piece of content will be granted. Upon determining that the specified node <b>1112</b> is reachable from the personality node <b>1110</b> of device <b>1102</b>, the control program executing on virtual machine <b>1104</b> next determines if the specified date restriction is met (block <b>1212</b> in <figref idref="DRAWINGS">FIG. 12</figref>). If the date restriction has been met (i.e., a “yes” exit from block <b>1212</b>), then the control program returns a result indicating that the specified conditions have been met (block <b>1214</b> in <figref idref="DRAWINGS">FIG. 12</figref>); otherwise, control program returns a result indicating that the specified conditions were not satisfied (block <b>1216</b> in <figref idref="DRAWINGS">FIG. 12</figref>).

0124An example of a control program such as that described above is shown below: <tables id="TABLE-US-00002" num="2"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="280PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>; Sample Control</entry></row><row><entry>;</entry></row><row><entry>; This Control checks that a user node is reachable</entry></row><row><entry>; and that the date is after a specific start date</entry></row><row><entry>; and before a specific end date</entry></row><row><entry>; The values are retrieved from attributes in the control</entry></row><row><entry>; =========================</entry></row><row><entry>; constants</entry></row><row><entry>; =========================</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="175PT" align="left" /><colspec colname="2" colwidth="14PT" align="char" char="." /><colspec colname="3" colwidth="91PT" align="center" /><tbody valign="top"><row><entry>  .equ DEBUG_PRINT_SYSCALL,</entry><entry>1</entry><entry /></row><row><entry>  .equ FIND_SYSCALL_BY_NAME,</entry><entry>2</entry></row><row><entry>  .equ SYSTEM_HOST_GET_OBJECT_SYSCALL,</entry><entry>3</entry></row><row><entry>  .equ SUCCESS,</entry><entry>0</entry></row><row><entry>  .equ FAILURE,</entry><entry>−1</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="280PT" align="left" /><tbody valign="top"><row><entry>; =========================</entry></row><row><entry>; data</entry></row><row><entry>; =========================</entry></row><row><entry>.data</entry></row><row><entry>ControlTargetNodeIdAttributePath:</entry></row><row><entry>  .string “Octopus/Control/Attributes/TargetNodeId”</entry></row><row><entry>ControlStartDateAttributePath:</entry></row><row><entry>  .string “Octopus/Control/Attributes/StartDate”</entry></row><row><entry>ControlEndDateAttributePath:</entry></row><row><entry>  .string “Octopus/Control/Attributes/EndDate”</entry></row><row><entry>TargetNodeId:</entry></row><row><entry>  .zeros 256</entry></row><row><entry>StartDate:</entry></row><row><entry>  .long 0</entry></row><row><entry>EndDate:</entry></row><row><entry>  .long −1</entry></row><row><entry>IsNodeReachableFunctionName:</entry></row><row><entry>  .string “Octopus.Links.IsNodeReachable”</entry></row><row><entry>IsNodeReachableFunctionNumber:</entry></row><row><entry>  .long  0</entry></row><row><entry>GetTimeStampFunctionName:</entry></row><row><entry>  .string “System.Host.GetLocalTime”</entry></row><row><entry>GetTimeStampFunctionNumber:</entry></row><row><entry>  .long  0</entry></row><row><entry>; =========================</entry></row><row><entry>; code</entry></row><row><entry>; =========================</entry></row><row><entry>.code</entry></row><row><entry>Global.OnLoad:</entry></row><row><entry>; load global functions</entry></row><row><entry>  ; get the syscall number for Octopus.Links.IsNodeReachable</entry></row><row><entry>  PUSH @IsNodeReachableFunctionName</entry></row><row><entry>  PUSH FIND_SYSCALL_BY_NAME</entry></row><row><entry>  CALL</entry></row><row><entry>  DUP</entry></row><row><entry>  PUSH @IsNodeReachableFunctionNumber</entry></row><row><entry>  POKE</entry></row><row><entry>  BRN OnLoad_Fail</entry></row><row><entry>  ; get the syscall number for System.Host.GetTimeStamp</entry></row><row><entry>  PUSH @GetTimeStampFunctionName</entry></row><row><entry>  PUSH FIND_SYSCALL_BY_NAME</entry></row><row><entry>  CALL</entry></row><row><entry>  DUP</entry></row><row><entry>  PUSH @GetTimeStampFunctionNumber</entry></row><row><entry>  POKE</entry></row><row><entry>  BRN OnLoad_Fail</entry></row><row><entry>  ; ok</entry></row><row><entry>  PUSH 0</entry></row><row><entry>  RET</entry></row><row><entry>OnLoad_Fail:</entry></row><row><entry>  PUSH FAILURE</entry></row><row><entry>  RET</entry></row><row><entry>Control.Actions.Play.Init:</entry></row><row><entry>  ; get the values from the attributes</entry></row><row><entry>  ; get the target node (guaranteed to be there)</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="182PT" align="left" /><colspec colname="2" colwidth="98PT" align="left" /><tbody valign="top"><row><entry>  PUSH 256</entry><entry>; ReturnBufferSize (256 bytes)</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="189PT" align="left" /><colspec colname="2" colwidth="91PT" align="left" /><tbody valign="top"><row><entry>  PUSH @TargetNodeId</entry><entry>; Return value</entry></row><row><entry>  PUSH @ControlTargetNodeIdAttributePath</entry><entry>; Name</entry></row><row><entry>  PUSH 0</entry><entry>; Parent = root container</entry></row><row><entry>  PUSH SYSTEM_HOST_GET_OBJECT_SYSCALL</entry></row><row><entry>  CALL</entry></row><row><entry>  ; get the start date</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="182PT" align="left" /><colspec colname="2" colwidth="98PT" align="left" /><tbody valign="top"><row><entry>  PUSH 4</entry><entry> ; ReturnBufferSize (4 bytes)</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="189PT" align="left" /><colspec colname="2" colwidth="91PT" align="left" /><tbody valign="top"><row><entry>  PUSH @StartDate</entry><entry>; Return value</entry></row><row><entry>  PUSH @ControlStartDateAttributePath</entry><entry>; Name</entry></row><row><entry>  PUSH 0</entry><entry>; Parent = root container</entry></row><row><entry>  PUSH SYSTEM_HOST_GET_OBJECT_SYSCALL</entry></row><row><entry>  CALL</entry></row><row><entry>  ; get the end date</entry></row><row><entry>  PUSH 4</entry><entry>; ReturnBufferSize (4 bytes)</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="182PT" align="left" /><colspec colname="2" colwidth="98PT" align="left" /><tbody valign="top"><row><entry>  PUSH @EndDate</entry><entry> ; Return value</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="189PT" align="left" /><colspec colname="2" colwidth="91PT" align="left" /><tbody valign="top"><row><entry>  PUSH @ControlEndDateAttributePath</entry><entry>; Name</entry></row><row><entry>  PUSH 0</entry><entry>; Parent = root container</entry></row><row><entry>  PUSH SYSTEM_HOST_GET_OBJECT_SYSCALL</entry></row><row><entry>  CALL</entry></row><row><entry>  ; success</entry></row><row><entry>  PUSH 0</entry></row><row><entry>  PUSH SUCCESS</entry></row><row><entry>  STOP</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="280PT" align="left" /><tbody valign="top"><row><entry>Control.Actions.Play.Perform:</entry></row><row><entry>Control.Actions.Play.Check:</entry></row><row><entry>  ; check that the target node is reachable</entry></row><row><entry>  PUSH @TargetNodeId</entry></row><row><entry>  PUSH @IsNodeReachableFunctionNumber</entry></row><row><entry>  PEEK</entry></row><row><entry>  CALL</entry></row><row><entry>  BRN Play_Fail</entry></row><row><entry>  ; put the current time on the stack</entry></row><row><entry>  PUSH @GetTimeStampFunctionNumber</entry></row><row><entry>  PEEK</entry></row><row><entry>  CALL</entry></row><row><entry>  ; check that the date is before the end date</entry></row><row><entry>  DUP   ; current time</entry></row><row><entry>  PUSH @EndDate</entry></row><row><entry>  PEEK</entry></row><row><entry>  SWAP</entry></row><row><entry>  CMP</entry></row><row><entry>  BRN Play_Fail</entry></row><row><entry>  ; check that the date is after the start date</entry></row><row><entry>  ; the current time is on the stack</entry></row><row><entry>  PUSH @StartDate</entry></row><row><entry>  PEEK</entry></row><row><entry>  CMP</entry></row><row><entry>  BRN Play_Fail</entry></row><row><entry>  ; success</entry></row><row><entry>  PUSH 0</entry></row><row><entry>  PUSH SUCCESS</entry></row><row><entry>  STOP</entry></row><row><entry>Play_Fail:</entry></row><row><entry>  PUSH 0</entry></row><row><entry>  PUSH FAILURE</entry></row><row><entry>  STOP</entry></row><row><entry>.export Global.OnLoad</entry></row><row><entry>.export Control.Actions.Play.Init</entry></row><row><entry>.export Control.Actions.Play.Check</entry></row><row><entry>.export Control.Actions.Play.Perform</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0125An additional example of a control program is included in Appendix E.

00003. Content Consumption and Packaging Applications

0126The following is a more detailed description of illustrative embodiments of an application that consumes DRM-protected content (e.g., a media player, a word processor, an email client, etc., such as applications <b>303</b><i>a</i>, <b>303</b><i>c</i>, and <b>303</b><i>d </i>in <figref idref="DRAWINGS">FIG. 3</figref>), and a packaging application, such as application <b>303</b><i>b</i>, that packages content targeted to consuming applications.

01271.5. Content-Consuming Application Architecture

0128A content-consuming application will typically focus on accessing protected content, or could be part of a general-purpose application that also performs other functions, such as packaging content. In various embodiments, a content-consuming application might perform some or all of the following: <ul id="ul0002" list-style="none"><li id="ul0002-0001" num="0129"> Provide an interface by which a user can request access to protected content objects and receive information about the content or error information; </li><li id="ul0002-0002" num="0130"> Manage interaction with the file system; </li><li id="ul0002-0003" num="0131"> Recognize the format of protected content objects; </li><li id="ul0002-0004" num="0132"> Request a DRM engine to evaluate licenses for pieces of content to see if permission to access the content can be granted; </li><li id="ul0002-0005" num="0133"> Verify digital signatures and deal with other general-purpose cryptographic functions that the DRM engine needs performed; </li><li id="ul0002-0006" num="0134"> Request the DRM engine to provide the keys needed to decrypt protected content; and/or </li><li id="ul0002-0007" num="0135"> Decrypt the protected content and interact with media rendering services to render the content. </li></ul>

0136In one embodiment, a DRM client engine evaluates the licenses associated with content, confirms or denies permission to use the content, and provides decryption keys to the content-consuming application. The DRM client engine may also issue one or more obligations and/or callbacks to the content-consuming application, requiring the application to perform certain actions as a consequence of having been given access to the content.

0137<figref idref="DRAWINGS">FIG. 13</figref> shows the elements that make up a content-consuming client application <b>1300</b> in one embodiment. As shown in <figref idref="DRAWINGS">FIG. 13</figref>, host application <b>1302</b> is the logical central point of the client. It is responsible for driving the interaction pattern between the other modules, as well as interaction with the user through user interface <b>1304</b>. The host application <b>1302</b> provides a set of services to DRM engine <b>1306</b> via a host services interface <b>1308</b>. The host services interface <b>1308</b> allows the DRM engine <b>1306</b> to get access to data managed by the host application <b>1302</b>, as well as certain library functions implemented by the host application <b>1302</b>. In one embodiment, the host services interface <b>1308</b> it is the only outbound interface for the DRM engine <b>1306</b>.

0138In one embodiment, the DRM engine <b>1306</b> does not interact directly with the multimedia content managed by the host application <b>1302</b>. The host application <b>1302</b> logically interacts with content services <b>1310</b> for accessing the multimedia content, and passes on to the DRM engine <b>1306</b> only the portions of data that must be processed by the engine. Other interactions with the content are performed by the media rendering engine <b>1312</b>. For example, in one embodiment content services <b>1310</b> are responsible for acquiring content from media servers, and storing and managing the content on the client's persistent storage, while media rendering engine <b>1312</b> is the subsystem responsible for accessing the multimedia content and rendering it (e.g., on a video and/or audio output). In one embodiment, the media rendering engine <b>1312</b> receives some information from DRM engine <b>1306</b> (such as content decryption keys), but in one embodiment the DRM engine <b>1306</b> does not interact with media rendering engine <b>1312</b> directly, but rather through the host application <b>1302</b>.

0139Some of the information needed by the DRM engine <b>1306</b> might be available in-band with the multimedia content, and can be acquired and managed through the content services <b>1310</b>, but some of this information may need to be obtained via means of other services such as a personalization service or a membership service (not shown).

0140In the embodiment shown in <figref idref="DRAWINGS">FIG. 13</figref>, cryptographic operations (e.g., encryption, signature verification, etc.) are handled by crypto services block <b>1314</b>. In one embodiment, the DRM engine <b>1306</b> does not interact directly with the crypto services block <b>1314</b>, but instead interacts indirectly via the host <b>1302</b> (using host services interface <b>1308</b>), which forward its requests. Crypto services <b>1314</b> may also be used by, e.g., the media rendering engine <b>1312</b> in order to perform content decryption

0141It will be appreciated that <figref idref="DRAWINGS">FIG. 13</figref> is provided for purposes of illustration, and that in other embodiments the various components shown in <figref idref="DRAWINGS">FIG. 13</figref> could be rearranged, merged, separated, eliminated, and/or new components could be added. For example, without limitation, the logical division of functionality between the DRM engine and the host application in <figref idref="DRAWINGS">FIG. 13</figref> is simply illustrative of one possible embodiment, and in practical implementations variations can be made. For example, the DRM engine could be integrated wholly or partially with the host application. Thus, it will be appreciated that any suitable division of functionality between host application and DRM engine can be used.

01421.6. Packager Architecture

0143The following provides an example of the functions that a packaging engine might perform for a host application that packages electronic content. In practice, a packaging application may focus on packaging specifically, or could be part of a general-purpose application operating at a user system that also accesses protected content (either packaged locally or elsewhere, e.g., on a network).

0144In various embodiments, a packaging host application might perform some or all of the following: <ul id="ul0003" list-style="none"><li id="ul0003-0001" num="0000"><ul id="ul0004" list-style="none"><li id="ul0004-0001" num="0145"> Provide a user interface by which content and license information can be specified; </li><li id="ul0004-0002" num="0146"> Encrypt content; </li><li id="ul0004-0003" num="0147"> Create the DRM objects that make up a license; and/or </li><li id="ul0004-0004" num="0148"> Create a content object that contains or references the content and contains or references a license </li></ul></li></ul>

0149<figref idref="DRAWINGS">FIG. 14</figref> shows the elements that make up a packaging application <b>1400</b> in one embodiment. DRM packaging engine <b>1416</b> is responsible for packaging licenses such as those described herein (e.g., licenses comprising DRM objects such as controls, controllers, protectors, and the like). In some embodiments, DRM packaging engine <b>1416</b> may also associate metadata a license to explain, in human-readable form, what the license does.

0150In one embodiment, a host application <b>1402</b> provides a user interface <b>1404</b> and is responsible for obtaining information such as content references and the action(s) the user (typically a content owner or provider) wants to perform (e.g., to whom to bind content, what content-usage conditions to include in a license, etc). User interface <b>1404</b> can also display information about the packaging process, such as the text of the license issued and, if a failure occurs, the reason for the failure. In some embodiments, some information needed by the host application <b>1402</b> may require the use of other services, such as authentication or authorization services, and/or membership through a Service Access Point (SAP). Thus, in some embodiments the packaging application <b>1400</b> and/or the host application <b>1402</b> may need to implement some or all of the following: <ul id="ul0005" list-style="none"><li id="ul0005-0001" num="0151"> Media format services <b>1406</b>: In one embodiment, this element is responsible for managing media format operations such as transcoding and packaging. It is responsible as well for content encryption, which is achieved via content encryption services module <b>1408</b>. </li><li id="ul0005-0002" num="0152"> General-purpose cryptographic services <b>1410</b>: In one embodiment, this element is responsible for issuing/verifying signatures, as well as encrypting/decrypting some data. Requests for such operations could be issued by the Service Access Point <b>1414</b> or by the DRM packaging engine <b>1416</b> via host services interface <b>1412</b>. </li><li id="ul0005-0003" num="0153"> Content encryption services <b>1408</b>: In one embodiment, this module is logically separated from the general-purpose cryptographic services <b>1410</b> because it does not know about the application. It is driven by the media format services at content packaging time with a set of keys previously issued by the DRM packaging engine <b>1416</b>. <br /> 4. Key Derivation </li></ul>

0154The following describes a key derivation system that fits naturally with preferred embodiments of the DRM engine and system architecture described herein, and/or can be used in other contexts. Some of the examples in the following section are taken from a reference implementation of a preferred embodiment of this key derivation system known as “Scuba”. Additional embodiments are described in the '551 application.

0155As shown in <figref idref="DRAWINGS">FIG. 15</figref>, in some embodiments link objects <b>1530</b><i>a</i>, <b>1530</b><i>b </i>are used to distribute keys, in addition to their primary purpose of establishing relationships between nodes <b>1500</b><i>a</i>, <b>1500</b><i>b</i>, <b>1500</b><i>c</i>. As described above, a control object can contain a control program that can be used to decide if a request to perform an action should be granted or not. To do this, the control program may check whether a specific node is reachable via a chain of links. The key derivation techniques described herein take advantage of the existence of this chain of links to facilitate the distribution of a key, such that the key can be made available to the DRM engine that is executing the control program.

0156In one illustrative embodiment, each node object <b>1500</b><i>a</i>, <b>1500</b><i>b</i>, <b>1500</b><i>c </i>in a given deployment that uses the optional key distribution system has a set of keys that are used to encrypt content keys and other nodes' keys. Link objects <b>1530</b><i>a</i>, <b>1530</b><i>b </i>created for use in the same deployment contain some cryptographic data as a payload that allows key information do be derived when chains of links are processed by a DRM engine.

0157With nodes and links carrying keys in this manner, given a chain of links <b>1530</b><i>a</i>, <b>1530</b><i>b </i>from a node A <b>1500</b><i>a </i>to a node C <b>1500</b>C, an entity (e.g., the DRM engine of a client host application) that has access to the secret sharing keys of node A <b>1515</b><i>a</i>, <b>1525</b><i>a</i>, also has access to the secret sharing keys of node C <b>1515</b><i>c</i>, <b>1525</b><i>c</i>. Having access to node C's secret sharing keys gives the entity access to any content key encrypted with those keys.

01581.7. Nodes, Entities, and Keys

01591.7.1. Entities

0160In one embodiment of a DRM system, nodes are data objects, not active participants in the system. Active participants, in this context, are called entities. Examples of entities are media players, devices, a subscription service, content packagers, and the like. Entities typically have nodes associated with them. An entity that consumes content uses a DRM engine and manages at least one node object that constitutes its personality. In one embodiment, an entity is assumed to have access to all the data of the node objects it manages, including all the private information of those objects.

01611.7.2. Nodes

0162Node objects that participate in an illustrative embodiment of the key derivation system contain keys as part of their data. In one embodiment, nodes may contain two general types of keys: sharing keys and confidentiality keys. The following sections list the different key types that can be used in various embodiments. It will be appreciated, however, that a specific deployment may use only a subset of these keys. For example, a system could be configured to work only with key pairs, omitting the use of secret symmetric keys. Or a system could be deployed without provisioning nodes with confidentiality keys if it only needed to use the sharing keys.

01631.7.2.1. Sharing Keys

0164Sharing keys are public/private key pairs and/or symmetric keys that are shared by a node N and all the nodes Px for which there exists a link from Px to N that contains key derivation extensions.

0165Sharing Public Key: Kpub-share[N] This is the public part of a pair of public/private keys for the public key cipher. This key typically comes with a certificate so that its credentials can be verified by entities that want to cryptographically bind confidential information to it.

0166Sharing Private Key: Kpriv-share[N] This is the private part of the public/private key pair. The entity that manages the node is responsible for ensuring that this private key is kept secret. For that reason, this private key will generally be stored and transported separately from the rest of the node information. This private key can be shared downstream with other nodes through the key derivation extensions of links.

0167Sharing Symmetric Key: Ks-share[N] This is a key that is used with a symmetric cipher. As with the private key, this key is confidential, and the entity that manages the node is responsible for keeping it secret. This secret key can be shared downstream with other nodes through the key derivation extensions of links.

01681.7.2.2. Confidentiality Keys

0169Confidentiality keys are key pairs and/or symmetric keys that are only known to the entity that manages the node to which they belong. The difference between these keys and the sharing keys described above is that they will not be shared with other nodes through the key derivation extensions in links.

0170Confidentiality Public Key: Kpub-conf[N] This is the public part of a pair of public/private keys for the public key cipher. This key typically comes with a certificate so that its credentials can be verified by entities that want to cryptographically bind confidential information to it.

0171Confidentiality Private Key: Kpriv-conf[N] This is the private part of the public/private key pair. The entity that manages the node is responsible for ensuring that this private key is kept secret. For that reason, this private key will generally be stored and transported separately from the rest of the node information.

0172Confidentiality Symmetric Key: Ks-conf[N] This is a key that is used with a symmetric cipher. As with the confidentiality private key, this key is kept secret.

01731.8. Cryptographic Elements

0174Preferred embodiments of the key derivation and distribution systems described herein can be implemented using a variety of different cryptographic algorithms, and are not restricted to any specific choice of cryptographic algorithm. Nevertheless, for a given deployment or profile, all participating entities will generally need to agree on a set of supported algorithms (where the term profile will generally refer to the specification of a set of actual technologies used in a particular implementation (e.g., an RSA for key derivation; XML for encoding objects; MP4 for the file format, etc.) and/or other representation of the semantic context that exists when objects are defined in a practical deployment).

0175In one embodiment, deployments include support for at least one public key cipher (such as RSA) and one symmetric key cipher (such as AES).

0176The following notation will be used when referring to cryptographic functions: <ul id="ul0006" list-style="none"><li id="ul0006-0001" num="0177"> Ep(Kpub[N], M) means “the message, M, encrypted with the public key, Kpub, of node, N, using a public key cipher”</li><li id="ul0006-0002" num="0178"> Dp(Kpriv[N], M) means “the message, M, decrypted with the private key, Kpriv, of node, N, using a public key cipher”</li><li id="ul0006-0003" num="0179"> Es(Ks[N], M) means “the message, M, encrypted with the symmetric key, Ks, of node, N, using a symmetric key cipher”</li><li id="ul0006-0004" num="0180"> Ds(Ks[N], M) means “the message, M, decrypted with the symmetric key, Ks, of node, N, using a symmetric key cipher”</li></ul>

01811.9. Targeting of Content Keys

0182In a preferred embodiment, two types of cryptographic targeting are used. Targeting a content key to a target node's sharing keys means making that key available to all entities that share the secret sharing keys of that target node. Targeting a content key to a node's confidentiality keys means making that key available only to the entity that manages that node. Targeting of a content key is done by encrypting the content key, CK, carried in a ContentKey object using one or both of the following methods: <ul id="ul0007" list-style="none"><li id="ul0007-0001" num="0183"> Public Binding: Create a ContentKey object that contains Ep(Kpub[N], CK) </li><li id="ul0007-0002" num="0184"> Symmetric Binding: Create a ContentKey object that contains Es(Ks[N], CK) </li></ul>

0185In a preferred embodiment, symmetric binding is used where possible, as it involves a less computationally intensive algorithm, and therefore makes it less onerous to the receiving entity. However, the entity (typically, a content packager) that creates the ContentKey object may not always have access to Ks[N]. If the packager does not have Ks[N], then it can use public binding, since Kpub[N] is not confidential information and therefore can be made available to entities that need to do public binding. Kpub[N] will usually be made available to entities that need to target content keys, accompanied by a certificate that can be inspected by the entity to decide whether Kpub[N] is indeed the key of a node that can be trusted to handle the content key in accordance with some agreed-upon policy (e.g., that the node corresponds to an entity running a DRM engine and host application that comply with the functional, operational, and security policies of the system).

01861.10. Derivation of Keys Using Links

0187To allow an entity to have access to the sharing keys of all the nodes reachable from its personality node, in one embodiment link objects contain an optional key extension payload. This key extension payload allows entities that have access to the private/secret keys of the link's “from” node to also have access to the private/secret sharing keys of the link's “to” node. In this way, an entity can decrypt any content key targeted to a node that is reachable from its personality node (if the targeting was done using the target node's sharing keys).

0188In one embodiment, when a DRM engine processes link objects, it processes the key extension payload of each link in order to update an internal chain of keys to which it has access. In one embodiment, the key extension payload of a link, L, from node, F, to node, T, comprises either: <ul id="ul0008" list-style="none"><li id="ul0008-0001" num="0000"><ul id="ul0009" list-style="none"><li id="ul0009-0001" num="0189"> Public derivation information: Ep(Kpub-share[F], {Ks-share[T],Kpriv-share[T]}) or </li><li id="ul0009-0002" num="0190"> Symmetric derivation information: Es(Ks-share[F], {Ks-share[T],Kpriv-share[T]}) </li></ul></li></ul>

0191Where {Ks-share[T], Kpriv-share[T]} is a data structure containing Ks-share[T] and Kpriv-share[T].

0192The public derivation information is used to convey the secret sharing keys of node T, Ks-share[T] and Kpriv-share[T], to any entity that has access to the private sharing key of node F, Kpriv-share[F].

0193The symmetric derivation information is used to convey the secret sharing keys of node T, Ks-share[T] and Kpriv-share[T], to any entity that has access to the symmetric sharing key of node F, Ks-share[F].

0194As for targeting content keys to nodes, the preferred payload to include in a link is the symmetric derivation information. This is possible when the link creator has access to Ks-share[F]. If not, then the link creator will fall back to including the public derivation information as the payload for the link.

0195Assuming that the DRM engine processing a link already had Ks-share[F] and Kpriv-share[F] in its internal key chain, after processing the link, L[F→T], it will also have Ks-share[T] and Kpriv-share[T].

0196Since, in one embodiment, links can be processed in any order, the DRM engine may not be able to do the key derivation computations at the time a given link, L, is processed. This might be due to the fact that, at that time, the DRM engine's key chain might not yet contain the keys of the “from” node of that link. In this case, the link is remembered, and processed again when new information becomes available to the DRM engine, such as after processing a new link, P. If the “to” node of link P is the same as the “from” node of link L, and the “from” node of link P is a reachable node, then the “from” node of link L will also be reachable, and the key derivation step adds the private sharing keys of the “from” node of link L to the key chain.

00005. Implementation Examples

0197Several examples are provided below to illustrate how various embodiments of the systems and methods described herein could be applied in practice. The systems and methods described herein can enable a wide range of rights management and other functionality, and thus it will be appreciated that the specific examples that are given here are not intended to be exhaustive, but are rather illustrative of the scope of the inventive body of work.

01981.11. Example: Users, PCs, and Devices

0199Assume that you want to implement a DRM system that ties the right to play content to a particular user, and you want to make it easy for the user to play content on all the playback devices that he or she owns. Assume that you decide that you are going to provide users with software that enables them to add playback devices as needed (e.g., mobile players). Also assume, however, that you want to set some policy to limit the number of general-purpose devices to which the user can transfer the content, so that the user does not have the ability to act as a distribution agency.

0200Based on these system requirements, it might, for example, make sense to tie the licenses you create to users, and to establish relationships between users and the devices that they use. Thus, in this example, you might first decide what kinds of nodes you need to establish the sorts of relationships that you require. For example, you might define the following types of nodes: <ul id="ul0010" list-style="none"><li id="ul0010-0001" num="0201"> User (e.g., an individual who owns the rights to use the content) </li><li id="ul0010-0002" num="0202"> PC (e.g., a software application, running on a personal computer, that can play content and specify additional playback devices) </li><li id="ul0010-0003" num="0203"> Device (e.g., a portable content-rendering device) </li></ul>

0204Each node object can include a type attribute that indicates whether the object represents a user, a PC, or a device.

0205Say, for example, that you decide to restrict the maximum number of PC node objects that can be attached to any one user at a particular time to four (4). You decide there is no need to restrict the number of devices attached to the user as long as you provide restriction on the number of PCs. Based on this, a control program can be set up to allow access if a relationship can be established between the user node and the node that requests access. That node, then, could be either a PC or a device.

0206<figref idref="DRAWINGS">FIG. 16</figref> shows a system designed to fulfill the foregoing requirements. Server <b>1600</b> assigns a user node object <b>1602</b><i>a</i>, <b>1602</b><i>b </i>to each new user <b>1604</b><i>a</i>, <b>1604</b><i>b</i>, and manages the ability of users <b>1604</b><i>a</i>, <b>1604</b><i>b </i>to associate devices <b>1606</b>, <b>1608</b> and PCs <b>1610</b>, <b>1612</b> therewith for the purpose of accessing protected content. When a user <b>1604</b><i>a </i>wishes to associate a new device <b>1606</b> with his or her user node <b>1602</b><i>a</i>, server <b>1600</b> determines whether the device <b>1606</b> already contains personalization information <b>1614</b>, as might be the case if the device <b>1606</b> was personalized at the time manufacture. If the device does contain personalization information <b>1614</b>, server <b>1600</b> uses that personalization information <b>1614</b> to create a link <b>1616</b> from the device <b>1606</b> to the user's node <b>1602</b><i>a</i>, and sends link <b>1616</b> to the user's device <b>1606</b>. When user <b>1604</b><i>a </i>obtains protected content <b>1618</b> (e.g., from server <b>1600</b> or from some other content provider), that content <b>1618</b> is targeted to the user's node <b>1602</b><i>a </i>(e.g., by encrypting the content's decryption key with one of the secret sharing keys associated with the user's node <b>1602</b><i>a</i>) and a license <b>1619</b> is associated therewith specifying the conditions under which the content can be accessed. When user <b>1604</b><i>a </i>attempts to play content <b>1618</b> on device <b>1606</b>, the DRM engine <b>1620</b> running on device <b>1606</b> evaluates the license <b>1619</b>, which indicates that the content <b>1618</b> can be played as long as user node <b>1602</b><i>a </i>is reachable. DRM engine <b>1620</b> evaluates link <b>1616</b>, which shows that user node <b>1602</b><i>a </i>is reachable from device <b>1606</b>, and grants user <b>1604</b><i>a</i>'s request to access content <b>1618</b>, e.g., by authorizing decryption of the content decryption key contained within license <b>1619</b>.

0207Since the content decryption key, in this example, is encrypted using a secret key associated with the user's node <b>1602</b><i>a</i>, this secret key will need to be obtained in order to decrypt the content decryption key. If the optional key derivation techniques described elsewhere herein have been used, the user node's key can be obtained simply by decrypting the key derivation information contained in link <b>1616</b> using one of device <b>1606</b>'s secret keys. The decrypted key derivation information will contain the key needed to decrypt the content decryption key contained in license <b>1619</b> (or information from which it can be derived or obtained).

0208Referring once again to <figref idref="DRAWINGS">FIG. 16</figref>, assume user <b>1604</b><i>a </i>wishes to associate a new PC <b>1610</b> with his or her user node <b>1602</b><i>a</i>. Server <b>1600</b> verifies that the maximum number of PCs have not already been associated with user node <b>1602</b><i>a</i>, and authorizes PC <b>1610</b> to be associated with user node <b>1602</b><i>a</i>. To perform the association, however, server <b>1600</b> needs to obtain personalization information from PC <b>1610</b> (e.g., cryptographic keys, a unique identifier, etc.). If, however, the PC <b>1610</b> has not been previously personalized (as might be the case if the user simply downloaded a copy of the PC software) server <b>1600</b> will perform the personalization process (e.g., by creating a PC node object using the bootstrap protocol described elsewhere herein) or direct the user to a service provider who can perform the personalization process. Upon completion of the personalization process, server <b>1600</b> can create a link <b>1624</b> from PC <b>1610</b> to user node <b>1602</b><i>a </i>and send the link to the PC <b>1610</b>, which could continue to use it as long as it remained valid.

0209The user could request to add additional PCs later, and the server would enforce the policy that limits the number of PC node objects per user to 4 (typically it would also provide the ability for users to remove PCs from its active list as needed).

0210As yet another example, assume now that the service provider has decided that users should be able to play any content that they own on any device that they own. The service provider might also wish to allow the user's PC software to create links to each of his or her devices, rather than requiring the user to contact server <b>1600</b>. In such an embodiment, when the user wished to play content on a new device, the user's PC software would access the new device's confidential personalization information and use it to create a new link for that device (e.g., a link from the new device to the user's node <b>1602</b><i>a</i>). If the device was not personalized, then the PC software might access a remote service, or direct the device to access the remote service, to perform the personalization process. The PC software would then send the link to the new device, at which point the new device would be able to play the content as long as it remained valid, since, in one embodiment, once a link object exists there is no need to create another one unless the link object expires or is otherwise invalidated.

0211In the examples shown above, content is targeted to the user. To do this, a packager application chooses a new ID for the content, or uses an existing one, creates an encryption key and associated ContentKey object, as well as a protector object to bind the content object and the ContentKey object. The packager then creates a control object with a control program (e.g., compiled in byte code executable by the DRM engine's virtual machine) that allows the “play” action to take place if and only if the user node is reachable from the PC or device node that is requesting the action. Typically, the control, controller, protector and ContentKey objects are embedded in the packaged content if appropriate, so that the PCs and devices do not have to obtain them separately.

0212In one embodiment, when a device or a PC wants to play content, it follows a process such as that previously described in connection with <figref idref="DRAWINGS">FIG. 9</figref>. That is, the DRM engine finds the protector object for the content ID of the content, then the ContentKey object referenced by that protector, then the controller object that references that ContentKey object, and finally the control object referenced by that controller. The DRM engine executes the control program of the control object, which checks whether or not the user node is reachable. If the device or PC node has the necessary link objects to verify that there exists a path between its node and the user node, then the condition is met and the control program allows the use of the key represented in the ContentKey object. The media rendering engine of the device or PC can then decrypt and play the content.

02131.12. Example: Temporary Login

0214<figref idref="DRAWINGS">FIG. 17</figref> is another example of a potential application of the DRM systems and methods described herein. This example is similar to the example in the preceding section, except here the policy that governs creation of link objects between PC node objects and user node objects allows for a temporary login of no more than 12 hours, as long as the user does not already have a temporary login on another PC. This feature would allow a user <b>1700</b> to take his content <b>1702</b> to a friend's PC <b>1704</b>, log in to that PC <b>1704</b> for a period of time, and play the content <b>1702</b> on the friend's PC <b>1704</b>.

0215To accomplish this, a link object <b>1710</b> would be created with a limited validity period. In one embodiment, this could be done as follows:

0216For ease of explanation, assume that the DRM-enabled consuming software <b>1714</b> required to play the DRM-protected content <b>1702</b> is already present on the friend's PC <b>1704</b>. The file containing the content <b>1702</b> and license <b>1708</b> is transferred to the friend's PC <b>1704</b>. When the user tries to play the content <b>1702</b>, the software <b>1714</b> recognizes that there is no valid link object linking the local PC node with the node of the user who owns the content. Software <b>1714</b> prompts the user for his credentials <b>1712</b> (this could be provided via a username/password, a mobile phone authentication protocol, a smartcard, or any authentication system allowed under the policy of the system) and communicates with a backend system <b>1706</b>. The backend system <b>1706</b> checks the attributes of the user node object and PC node object for which the link is requested, and checks that there is no active temporary login link object still valid. If those conditions are met, the backend service <b>1706</b> creates a link object <b>1710</b> linking the friend's PC node object and user's node, with a validity period limited to the requested login duration (e.g., less than 12 hours, to comply with the policy in this example). Having the link object <b>1710</b> now enables the friend's PC <b>1704</b> to play the user's content <b>1702</b> until the link <b>1710</b> expires.

02171.13. Example: Enterprise Content Management

0218<figref idref="DRAWINGS">FIG. 18</figref> shows the high-level architecture of an illustrative system <b>1800</b> for managing enterprise documents (e.g., email, word processing documents, presentation slides, instant messaging text, and/or the like). In the example shown in <figref idref="DRAWINGS">FIG. 18</figref>, a document editing application (e.g., a word processor) <b>1802</b>, an email client <b>1804</b>, and a directory server (e.g., an Active Directory server) <b>1806</b> make use of a digital rights management (DRM) plug-in <b>1808</b>, a network service orchestration layer <b>1810</b>, a registration service <b>1812</b>, and a policy service <b>1816</b> to facilitate management of documents, email messages, and/or the like in accordance with policies. In a preferred embodiment, the DRM plug-in <b>1808</b>, network service orchestration layer <b>1810</b>, policy service <b>1816</b>, and registration service <b>1812</b> are implemented using the DRM engine and service orchestration technologies described elsewhere herein and in the '551 application. For example, in one embodiment DRM plug-in <b>1808</b> may comprise an embodiment of the DRM engine described above. It will be appreciated that while <figref idref="DRAWINGS">FIG. 18</figref> shows an embodiment in which existing applications such as word processor <b>1802</b> and email client <b>1804</b> are integrated with the DRM engine via a plugin that the applications can call, in other embodiments the DRM engine could be included as an integral part of either or both of the applications themselves. It will also be appreciated that the illustrative system shown in <figref idref="DRAWINGS">FIG. 18</figref> can be implemented within a single enterprise or may span multiple enterprises.

0219In the illustration shown in <figref idref="DRAWINGS">FIG. 18</figref>, the directory server <b>1806</b> may, for example, contain user profiles and group definitions. For example, a group called “Special Projects Team” may be set up by a company's system administrator to identify the members of the company's Special Projects Team.

0220In one embodiment the directory server <b>1806</b> may comprise an Active Directory server running web services, such as those described in the '551 application (and implemented, e.g., with standard IS based technologies on the Windows® platform), that issue nodes, links, and licenses to the people in the Special Projects Team group based on content that is accessed. If membership changes in the group, then new tokens may be issued. For revocation of rights, the directory server <b>1806</b> can run a security metadata service based on technology such as that described in the '551 application (occasionally referred to herein as “NEMO” technology). In some embodiments, the client can be required to have an to-date time value or notion of time (based on whatever freshness value the company chooses to define (e.g., 1 week, 1 day, 1 hour, every 5 minutes, etc.)) in order to use DRM licenses. For example, a token that the security metadata service provides might include a trusted and authenticable time value. In some embodiments, the client can identify user node IDs in security metadata service interactions. Security metadata can be evaluated directly in the context of license controls to determine if a user still has a given membership. Security metadata can also return agents that can determine if relationships such as being a member in the Special Projects Team are valid. Thus, in some embodiments it is possible to leverage a company's existing authorization and authentication infrastructure (e.g., the company's Active Directory server) with just the addition of a few well-defined web services.

0221<figref idref="DRAWINGS">FIG. 19</figref> shows an example of how a system such as that shown in <figref idref="DRAWINGS">FIG. 18</figref> can be used to manage access to or other use of a document. In this example, a particular employee (John) might frequently work on highly confidential strategic projects, and may have already installed the DRM plugin <b>1908</b> for his applications (e.g., a word processing program <b>1902</b>, an email program <b>1904</b>, a calendar program, a program or program suite that integrates such programs, and/or the like). At some point during the creation of his document, John accesses a “permissions” pull-down menu item that has been added to his application's toolbar (action <b>1913</b>). A permissions dialog box appears which contacts his company's Active Directory Server <b>1906</b> for a directory of individuals and groups that have been set up on the system. He selects “Special Projects Team” from the list, and elects to give everyone on the team permission to view, edit, and print the document. Using the NEMO service orchestration technologies described in the '551 application, the DRM plugin <b>1908</b> contacts a NEMO-enabled Policy Service extension <b>1916</b> to the Active Directory <b>1906</b> and requests a copy of the Policy to use.to protect files for the Special Projects Team (action <b>1914</b>). When John saves the document, the DRM plugin automatically encrypts the file <b>1912</b>, and creates a license object targeted and bound to the group known as “Special Projects Team” <b>1910</b>. The license <b>1910</b> allows the file <b>1912</b> to be accessed (e.g., viewed, edited, printed, etc.) by any device that can produce a valid chain of links from its Device Node to the Special Projects Team Group Node.

0222John can access the document <b>1912</b> because his device has a link to John's User Node, and it also has a link from John's User Node to the “Special Projects Team” Group Node. Likewise, if he forwards this document to others, they can only access it if they also can produce a valid chain of links to the “Special Projects Team” Group Node (e.g., by requiring that the Special Projects Team Node be reachable by the device).

0223John might save the file (already protected) on his computer, and later attach it to an email message (action <b>1920</b>). For example, he might open an old email to his boss (George), attach the file as he normally does, and send the message. As shown in <figref idref="DRAWINGS">FIG. 20</figref>, George also has the DRM plugin <b>2000</b> installed on his computer <b>2014</b>. When he logged in to his computer <b>2014</b>, the plugin <b>2000</b> opportunistically checked all of the groups that he has been added to (action <b>2006</b>), and downloaded new, refreshed links for any that had expired (action <b>2012</b>). If he had been added to “Special Projects Team” since his last login, his plugin <b>2000</b> would download a Link Object <b>2008</b> that links his User Node to the “Special Projects Team” Group Node. This Link <b>2008</b> signifies that User Node “George” is a member of the Group Node “Special Projects Team”. In this example, assume Link Object <b>2008</b> has an expiration date after which it will no longer be valid (e.g., 3 days).

0224As shown in <figref idref="DRAWINGS">FIG. 21</figref>, when George tries to open the document (actions <b>2130</b>, <b>2132</b>), the DRM plugin <b>2108</b> checks the embedded (or attached) license, and learns that the “Special Projects Team” node must be reachable. His plugin <b>2108</b> constructs (and validates) a chain of links <b>2120</b>, <b>2122</b> from his computer's Device Node to the User Node “George”; and from User Node “George” to Group Node “Special Projects Team” (action <b>2134</b>). Since the device has a valid chain of Links <b>2120</b>, <b>2122</b>, his plugin <b>2108</b> permits access to the file.

0225As described elsewhere herein, in some embodiments links can also carry a secure chain of keys. Thus, in some embodiments, by producing a chain of Links to the Special Projects Team Node, the plugin can not only prove that it is permitted to access the content, but also that it is capable of decrypting a chain of keys that enable it to decrypt the content.

0226If, for example, another employee (“Carol”) receives John's email accidentally, and attempts to open the document, her DRM plugin will retrieve the license bundled with the file and evaluate the terms of the license. Her PC has a link to her User Node “Carol”; but since she is not a member of the team, there is no Link from “Carol” to the “Special Projects Team” Group Node. Since “Special Projects Team” is not reachable, she is not permitted to access the file.

0227If Carol is eventually added to the group “Special Projects Team”. The next time her DRM plugin refreshes her memberships, it will detect this new group, and download a Link Object that links her User Node to the Special Projects Team Node. Her plugin now has all of the links it needs to construct a chain from her Device Node to her User Node to the Special Projects Team Node. The Special Projects Team node now “is reachable” and she can open any documents or emails that are targeted to the Special Projects Team—even those that were created before she joined the team.

0228Assume that a month later George moves on to a new role and is removed from the Special Projects Team Group in the Active Directory. The next time George logs in, his plugin does not receive a new, refreshed Link Object associating his User Node “George” to the “Special Projects Team”. When, weeks later, he tries to open John's file, his plugin attempts to construct a chain of links to the Special Projects Team. His PC still has a link to the User Node “George” (George's PC still belongs to him); but the Link from “George” to the “Special Projects Team” has expired. Since “Special Projects Team” is not reachable, he is not permitted to access the file.

0229Assume that the company has a policy that requires access to all confidential information to be logged. In one such an embodiment, the policy for the Special Projects Team dictates that all licenses that are created for this group also need to require collection and reporting of usage information to, e.g., a central repository. Thus, in this example, when evaluating (e.g., executing) the control program in the license, the plugin executes the requirement to log the access and does so. For example, activity of consequences can be logged in a local protected state database such as that described herein, and when network connectivity is re-established the relevant content can be reported via services previously described.

0230<figref idref="DRAWINGS">FIG. 22</figref> shows another illustrative system <b>2200</b> for managing electronic content within an enterprise. In the example shown in <figref idref="DRAWINGS">FIG. 22</figref> an LDAP server <b>2206</b> is used to manage user profiles, group definitions, and role assignments, and contains a group definition called “Special Projects Team”, and a role definition of “Attorney”.

0231Assume that John is an attorney and wishes to send an email with an attachment to other members of the Special Projects Team. When John installs the DRM plug-in <b>2208</b> for his applications, it also installs items to his email toolbar. At some point during his composition of the email message, John accesses “Set Permissions” from a pull-down menu that was added to his toolbar. The DRM plug-in <b>2208</b> contacts a Policy Servic <b>2216</b> and displays a list of corporate messaging policies from which to choose. John selects “Special Project DRM Template” and the DRM plug-in <b>2208</b> uses the NEMO protocol to request and ensure the authenticity, integrity, and confidentiality of policy object that it receives. The policy describes how the licenses that use this template should be created, including how they should be targeted and bound.

0232When John hits “Send”, the DRM plugin <b>2208</b> encrypts the message and attachment, and generates the associated license(s). The license requires that in order to access the email or the attachment, either the Special Projects Team Group Node or the “Attorneys” Group Node must be reachable.

0233The license(s) are bundled with the encrypted message payload and encrypted attachment. The message is subsequently sent to a list of recipients using standard email functionality. Since the license rules and encryption are not dependent on the addressing of the email, the fact that an incorrect email recipient might be erroneously included does not put the contents of the email or attachment at risk.

0234Since such an unintended recipient will not have a valid Link Object linking his User Node to the Special Projects Team, he is not permitted to access the content if and when he attempts to do so. Furthermore, since his device does not have the necessary chain of Links (and the keys they contain), his device does not even have the capability to decrypt the content.

0235However, if the unintended recipient, in turn, forwards the same, unmodified email using standard email functionality to a member of the Special Projects Team. That member will have a Link Object that Links his User Node to the “Special Projects Team” Group Node, and will be able to access the email's contents.

0236Assume that another attorney (“Bill”) at the company has also received a Link Object that associates him with the “Special Projects Team” Group Node. Bill can also view the file. If he forwards the message to a paralegal (“Trent”), who is neither an attorney nor associated with the Special Projects Team, Trent will not have a Link Object that connects him with the “Special Projects Team” Group Node, and he will not be able to access the document.

0237If Trent is subsequently added to the Special Projects Team group in the LDAP directory <b>2206</b>, he will be given the necessary Link Object(s) and will be able to access the previously forwarded email.

0238If, as previously discussed, the company has a policy indicating that a reporting requirement be included in all licenses, then, in one embodiment, whenever a control program within one of these licenses is executed (e.g., when someone attempts to access the file), a reporting event can be triggered. The reporting step can additionally include an indicator as to whether or not access was granted or denied—this is a matter of implementation choice. If such an indicator is used, a log can be maintained of the number of attempts to access a particular document, and status or other information on each (e.g., success, failure, etc.).

0239As yet another example, assume that one of the members (“Stephen”) of the Special Projects Team travels to another company to perform work on the special project. Before leaving for the other company, Stephen's email client downloads a local copy of all the email in is Inbox. The protected report attached to one of these emails also includes an embedded (or attached) license. This license object includes both the rules for accessing the content as well as an encrypted content key. The only “missing link” required to access the content is the necessary link objects to reach the “Special Projects Team” Group Node.

0240Since, in this example, the company's policy is to allow Link Objects to remain valid for 3 days, the Link Object that links Stephen's User Node to the Special Projects Team Node, will remain valid while he is traveling and disconnected. If he attempts to access the file while offline, the Special Projects Team Group Node will still be reachable, and he will be permitted to access the file.

0241If, however, Stephen stays offline for more than three days, the Link Object linking him to the Special Projects Team will expire. The Special Projects Team Group Node will then no longer be reachable, and he will not be permitted to access the file.

0242If Stephen eventually travels to a location where he can connect to the company's system (e.g., via VPN), his DRM plug-in will request refreshed copies of Link Objects for each of the groups to which he belongs. Since he is still part of the “Special Projects Team” group, he will receive a new link object from his User Node to the Special Projects Team Group Node. This link replaces the ‘old’ link which has expired and is no longer valid.

0243Since the “Special Projects Team” Node is now reachable using this new, refreshed Link, he is once again able to access the protected report. The new link object will be valid for a period of 3 days, after which it will also expire.

0244As yet another example, assume that a member (“Sally”) of the Special Projects Team wishes to communicate with another team member via an instant messenger, save a copy of the communication, and give it to another member of the team (e.g., via an email attachment, a diskette, a dongle, or the like). In this example, the instant messenger client (and, potentially any other messaging or communication products which the company offers its employees) is linked to a DRM plugin which, as in the previous examples, accesses the Policy “Special Project DRM Template” that dictates how licenses are to be targeted and bound. When Sally attempts to save her instant messaging conversation (e.g., by selecting “Save-As”), the plug-in chooses an encryption key (e.g., randomly) and packages (encrypts) the text of the conversation. Per company policy, the DRM plugin then generates a license object that is targeted and bound to the Special Projects Team Group Node.

0245The file containing the protected IM transcript is bundled with the license to access the transcript contents. As in the previous examples, the License contains both the rules that govern access to the content, as well as an encrypted copy of the content key. Sally can transfer this bundled file to an email, USB dongle, diskette, etc. using standard ‘drag and drop’ procedures, and send it to someone else. Provided that the recipient's device can produce valid links to the Special Project Group Node, access to the content is permitted and possible.

0246Assume that Sally gives the file to John, who is also a member of the Special Projects Team. If John has a recently-refreshed Link Object that identifies him as a member of the Special Projects Team, he will be able to access the file. Per the company's policy, this Link Object contains an expiration date that will cause it to expire in three days. Therefore, even if John remains disconnected, he will still have access as long as that link remains valid.

0247If, at some later time, John leaves the Special Projects Team for another job assignment, and finds the USB dongle from Sally in his bag and attempts to open the file using his desktop computer, the Link Object associating his User Node to the Special Projects Team will have expired. Since he is no longer part of the team, the DRM plugin on his device no longer can acquire new, refreshed links. Since the “Special Projects Team” Group Node is no longer reachable by his device, access is not permitted.

0248Figuring that his laptop has not been connected to the network since he changed jobs, he also tries to open the file with that device. Since the maximum allotted time has passed, that Link is also no longer valid. In some embodiments, each time he attempts to access the file, a report can be generated and queued to be sent to a central repository.

0249The central repository receives multiple reports of unsuccessful attempts to access the file and flags a manager via email. The manager reminds John that he is no longer permitted to access the confidential material and asks for all files to be destroyed (even though the system indicates that access has not been granted).

0250As yet another example, assume that a governmental agency or outside auditor wishes to investigate or audit the Special Projects Team's handling of confidential information. To support the investigation, the company wishes to demonstrate audit records for access to sensitive information related to the Special Project.

0251To this end, the company first scans all cleartext message archives for any messages related to the Special Project. To their relief, they discover that, in adherence to company policy, no employees sent messages discussing the Special Project without appropriate DRM protection (e.g. outside of the system).

0252The company then uses the DRM access records to produce an audit trail detailing who was given access to protected information, and when.

0253Per company procedure, when the Special Projects Team Group was established, it also included the Chief Compliance Officer (CCO) by default. A Link Object for Chief Compliance Officer was created and saved to the archive server, which allows him or her to review the contents of all messages if needed in the future.

0254In this example, the policy defined for the Special Projects Team indicated that all Licenses generated by the team must include the requirement to report any attempted access to the file, including the date and time, UserNode, and whether or not access was granted. These reports were saved in an access log on a central repository.

0255The CCO checks the access logs for all accesses associated with the Special Projects Team prior to the date when any leak or other irregularity was suspected to have occurred. The CCO also searches the email, IM, and network backup archives for all message traffic and system files on or before that date. Since each file has an attached license (with content key), and the CCO has the necessary Link Objects to satisfy the requirements of the License, he or she is permitted to access the contents of each and every message that was accessed prior to the time in question.

0256The access logs and unencrypted message contents are made fully available to the agency/auditor as part of the investigation.

0257In some embodiments the policy for the Special Projects Team could also have included the requirement to set an expiration date for the all licenses related to the Special Project. For example, if the company were only statutorily required to keep records of this nature for a period of 1 year, they could indicate in the policy that Licenses expire one year following date of issue. In that case, the company might only keep records as long as legally required to do so. Even the CCO would not have access after that time.

0258In the foregoing discussion, reference has occasionally been made to “targeting” and “binding”. In preferred embodiments, targeting and binding represent two different, yet closely related processes. In preferred embodiments, “binding” is primarily a cryptographic process, concerned with protecting the key that was used to encrypt the content. When a License is ‘bound’ to a Node (for example the “Special Projects Team” Node), it can mean, e.g., that the content key is encrypted with the public key associated with that Node. Thus, only devices that have access to the private key of the Node will have the necessary key to decrypt the content (and in preferred embodiments, the only way to get access to the private key of a Node is to decrypt a chain of Links to that Node); however, simply having the correct private key only indicates that the device has the capability to decrypt the content, if it is also permitted to do so.

0259In preferred embodiments, whether or not a device is permitted to access the content is determined by a Control Program within the License, and specifically, how it is “targeted”. “Targeting” refers to adding a requirement in the Control Program to specify that a particular node (or nodes) “are reachable” to perform a use of the content. In the examples shown above, the Control Program typically specifies that a particular Node “Special Projects Team” is reachable by the consuming device.

0260In some instances, it may be desirable to have licenses targeted to more than one Node, such as a new product development team at a company (“Company”) that is working with multiple suppliers to bid on components for a new top secret product. Assume that during the early stages of the project, Supplier A and Supplier B (competitors) both have links to “SecretProjectX”. Supplier A wants its ideas to be shared with all members of SecretProjectX, but does not want them to inadvertently leak to Supplier B. Supplier A can target these licenses such that: (“SecretProjectX is reachable”) AND (“Supplier A is reachable” or “Company is reachable”). If Company inadvertently shares this information to everyone in Secret Project X (including Supplier B), those at supplier B will not be permitted to look at it, limiting any non-disclosure risk to Company and eliminating the prospect of Supplier A losing its trade-secrets.

02611.14. Example: Healthcare Records

0262<figref idref="DRAWINGS">FIG. 23</figref> illustrates how the systems and methods described herein could be applied to manage healthcare records. Assume that medical records have different levels of confidentiality, and that it is desirable to grant different access rights to different entities in the system (e.g., patients, doctors, insurance companies, and the like). For example, it may be desirable to permit some records to be viewed only by the patient, to permit some records to be viewed only by the patient's doctor, to permit some records to be viewable by the patient but only editable by the patient's doctor, to permit some records to be viewable by all doctors, to permit some records to be viewed by all insurance companies, to permit some records to be viewable only by the patient's insurance company, and/or the like.

0263As shown in <figref idref="DRAWINGS">FIG. 23</figref>, this healthcare ecosystem <b>2300</b> can be modeled using DRM objects like nodes and links, such as those describe elsewhere herein. For example, nodes could be assigned to the patient <b>2302</b>, the patient's doctors <b>2304</b>, the patient's insurance company <b>2306</b>, the patient's devices (<b>2308</b>, <b>2310</b>) a specific one of patient's doctors <b>2312</b>, the doctor's computing devices <b>2314</b>, <b>2316</b>, the group of all doctors <b>2318</b>, the group of doctors of a certain specialty <b>2320</b>, a medical institution <b>2322</b>, an insurance company <b>2324</b>, the computing devices used by the insurance company <b>2326</b>, the group of all insurance companies <b>2328</b>, and the like.

0264Assume that the patient's doctor uses his or her PC to create a medical record regarding the patient. For example, the medical record may comprise a document template with a number of fields for his or her notes, diagnoses, prescription instructions, instructions for the patient and/or the like. The template may also allow the doctor to select the security policies for governing the document and/or the individual field thereof. For example, the doctor's application may present a set of standard security policy choices, and, upon obtaining the doctor's selection, may automatically generate a license based on those choices and associate with the protected (e.g., encrypted) content of the medical record.

0265For purposes of this example, assume the license grants viewing access to the patient, to all healthcare providers who treat the patient, and to all insurance companies that provide coverage for the patient. Further assume, for the sake of illustration, that the license grants editing rights only to cardiologists at medical institution x.

0266The packaging application accepts the doctor's policy specification input (which may simply comprise a mouse click on a standard template) and generates a license that includes a control program such as that shown below: <tables id="TABLE-US-00003" num="3"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="28PT" align="left" /><colspec colname="1" colwidth="189PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Action.Edit.Perform( ) {</entry></row><row><entry /><entry>  if (IsNodeReachable(“MedicalFoundationX”) &amp;&amp;</entry></row><row><entry /><entry>   IsNodeReachable(“Cardiologist”)) {</entry></row><row><entry /><entry>   return new ESB(ACTION_GRANTED);</entry></row><row><entry /><entry>  } else {</entry></row><row><entry /><entry>   return new ESB(ACTION_DENIED);</entry></row><row><entry /><entry>  }</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry>Action.View.Perform( ) {</entry></row><row><entry /><entry>  if (IsNodeReachable(“PatientY”) ||</entry></row><row><entry /><entry>   IsNodeReachable(“HCPsPatientY”) ||</entry></row><row><entry /><entry>   IsNodeReachable(“ICsPatientY”) {</entry></row><row><entry /><entry>   return new ESB(ACTION_GRANTED);</entry></row><row><entry /><entry>  } else if (EmergencyException == TRUE) {</entry></row><row><entry /><entry>   return new ESB(ACTION_GRANTED, new</entry></row><row><entry /><entry>   NotificationObligation( )); }</entry></row><row><entry /><entry>  else {</entry></row><row><entry /><entry>   return new ESB(ACTION_DENIED);</entry></row><row><entry /><entry>  }</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0267The medical record and its associated license might then be stored in a central database of medical records, a database operated by the particular medical foundation, and/or the like. If patient Y subsequently visits another healthcare provider, and authorizes that healthcare provider as one of his approved healthcare providers (e.g., by signing an authorization form), that healthcare provider will obtain a link to the patient y approved healthcare providers node, which the healthcare provider would store on his computer system. If that healthcare provider were to then obtain the medical record created by doctor x, he would be able to gain viewing access to that medical record, since patient y's approved healthcare provider node would be reachable from the new healthcare provider's computer system. If on the other hand, an unapproved healthcare provider were to obtain a copy of the (encrypted) medical record, he would be unable to access it since none of the required nodes (i.e., patient y's node, the node for all of patient y's approved healthcare providers, and the node for all of patient y's approved insurance companies) would be reachable from his computing system.

0268Note, however, that the example control program shown above includes an override feature that can be invoked, e.g., in emergencies if, for example, a healthcare provider needs to access the protected medical record, but is unable to satisfy the conditions of the control program (e.g., because the healthcare provider attempting to make emergency access to the medical record has not previously been registered as a healthcare provider of patient Y). Note also, however, that invocation of the emergency access exception will cause information to be automatically recorded regarding the invocation and/or other circumstances, and, in this example, will also cause a notification to be sent (e.g., to the patient's preferred healthcare provider—i.e., an entity explicitly authorized by the patient—and/or the patient himself). The association of such obligations with the emergency exception may discourage abuse of the exception, since a record of the abuse would exist.

0269It will be appreciated that this example program has been provided to facilitate explanation of certain embodiments of the systems and methods described herein. For example, whether a system includes support for emergency exceptions will typically depend on the requirements and desires of the system architect. Thus, for example, some embodiments may not support emergency exceptions, others may support emergency exceptions, but limit the class of entities who can invoke such exceptions to the class of “all doctors” (e.g., by requiring that the EmergencyException flag be set to “true” AND the All Doctors node be reachable), and others still may support emergency exceptions, but not associate mandatory obligations therewith (since inability to comply with the obligation would, in a preferred embodiment, render the content inaccessible), relying instead on non-technical, legal or institutional means for enforcement (e.g., by trusting healthcare providers not to abuse the ability to invoke the exception, and/or relying on industry certification and the legal system to prevent abuse).

0270Yet another variation that could be made to the examples provided above might be to require stronger proof that a doctor, or a specifically named doctor, was actually the one accessing a medical record, as opposed to someone else sitting at the computer that the doctor uses to access records (and thus a computer potentially containing the links necessary to satisfy a reachability analysis). Such a stronger form of authentication could be enforced in any suitable manner. For example, it could be wholly or partially enforced at the application or system level by protecting the doctor's computer and/or the software used to access medical records using passwords, dongles, biometric identification mechanisms, and/or the like. Alternatively, or in addition, the control programs associated with certain medical records could themselves include an obligation or condition require such stronger identification, such as checking for the presence of a dongle, requiring the host to obtain a password, and/or the like.

02711.15. Example: Subscriptions

0272<figref idref="DRAWINGS">FIG. 24</figref> is an illustration of how the systems and methods presented herein could be used in the context of an electronic subscription service. Say, for example, that a user (Alice) wishes to obtain a subscription to jazz music from an Internet service provider (XYZ ISP). The Internet service provider may offer a variety of different subscription options, including a trial subscription that is free of charge, but can only be used to play subscription content five times before expiring (e.g., by playing one song five times, by playing five different songs once each, or the like). The trial subscription also will only make the content available in slightly degraded form (e.g., reduced fidelity or resolution). Alice uses her personal computer to access the service provider's Internet website, and opts for the trial subscription. The service provider then issues a link object <b>2400</b> and an agent <b>2401</b> and sends them to Alice's personal computer <b>2406</b>. The agent <b>2401</b> is operable to initialize a state in Alice's secure state database that will be used to keep track of the number of times Alice has used trial content. The link <b>2400</b> is from Alice's ISP account node (Alice@XYZ_ISP) <b>2402</b> to subscription node <b>2404</b> and includes a control program that, when Alice requests to play a piece of content, checks the current value of the state variable set by the agent <b>2401</b> to see if additional plays are allowed.

0273When Alice downloads a piece of content to her PC and attempts to play it, the DRM engine on her PC evaluates the license associated with the content, which indicates that subscription node <b>2404</b> must be reachable in order to play the content. Alice had previously registered her PC with her ISP, at which time she received a link <b>2405</b> from her PC node <b>2406</b> to her account node <b>2402</b>. The DRM engine thus possess link objects <b>2405</b>, <b>2400</b> connecting PC node <b>2406</b> to subscription node <b>2404</b>; however, before granting Alice's request to play the content, the DRM engine first determines whether the links are valid by executing any control programs that the links contain. When the control program in link <b>2400</b> is executed, the DRM engine checks the state database entry to determine if 5-plays have already been made, and, if they have not, grants her request to play the content, but also issues an obligation to the host application. The obligation requires the host to degrade the content before rendering. The host application determines that it is able to fulfill this obligation, and proceeds to render the content. In order to enable Alice to preview content before counting that content against her five free trial-offer plays, the control program might also include a callback that checks, e.g., 20 seconds after a request to play a piece of content has been granted, to see if the content is still being played. If the content is still being played, the play count is decremented, otherwise it is not. Thus, Alice can select from any of the content items offered by the subsrcription service, and play any five of them before her trial subscription expires.

0274Once Alice's trial subscription expires, Alice decides to purchase a full, monthly subscription which enables her to play as many content items as she wishes for a monthly fee. Alice use's her PC to sign up for the subscription, and receives a link <b>2410</b> from her account node <b>2402</b> to the-subscription node <b>2404</b>. The link includes a control program indicating that the link is only valid for one month (e.g., the control program checks an entry in the state database to see if one month has elapsed since the link was issued). This link <b>2410</b> is sent to Alice's PC, along with an agent program that is operable to initialize an appropriate entry in the state database of the PC's DRM engine indicating the date on which the link was issued. When Alice downloads a piece of content from the subscription service and attempts to play it, her PC's DRM engine determines that a path to the subscription node exists comprised of links <b>2405</b>, <b>2410</b>. The DRM engine executes any control programs contained in links <b>2405</b>, <b>2410</b> to determine if the links are valid. If less than a month has elapsed since link <b>2410</b> was issued, the control program in link <b>2410</b> will return a result indiating that link <b>2410</b> is still valid, and Alice's request to play the piece of content. If Alice attempts to play a piece of content she previously obtained during her free trial period, the DRM engine on her PC will perform the same analysis and grant her request. Since the license associated with the piece of content obtained during the trial period indicates that if the TrialState variable in the secure database is not set, the only condition is that the subscription node must be reachable, Alice can now access that content once again since the subscription node is once again reachable from Alice's PC, this time via link <b>2410</b>, not link <b>2400</b>, which is no longer valid. Thus, Alice does not need to obtain a second copy of the content item to replace the copy she obtained during the free trial offer. Similarly, if Alice obtains a piece of subscription content from her friend, Bob, who is also a subscriber to the same service, Alice will, in this example, be able to play that content, too, since the content's license simply requires that the subscription node be reachable, not that it be reachable via Bob's PC or account.

0275It will be appreciated that the above examples are simply intended to illustrate some of the functionality that can be enabled by the systems and methods described herein, and is not intended to suggest that subscriptions must be implemented in precisely the manner described above. For example, in other embodiments, the license associated with a piece of subscription content might be bound to a user's node, rather than the subscription node, thus preventing two subscribers from sharing content like Bob and Alice were able to do in the example described above. It will be appreciated that many other variations to the above examples could be made.

0276The table below provides some illustrative pseudo-code for the agent, link, and license control programs in the example described above: <tables id="TABLE-US-00004" num="4"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>================================</entry></row><row><entry>The subscription trial gives you access to up to 5 pieces of</entry></row><row><entry>subscription content. The content will be marked as rendered only after</entry></row><row><entry>20 seconds of rendering. Content rendered in the context of the trial</entry></row><row><entry>will have to be degraded by the rendering applicatio.</entry></row><row><entry>The real subscription will be renewed every month and has no such</entry></row><row><entry>limitations on the number or quality of the renderings.</entry></row><row><entry>The code of the agent is as follows:</entry></row><row><entry>==================================</entry></row><row><entry>TrialAgent( ) {</entry></row><row><entry>  SetObject(“TrialState”, 5);</entry></row><row><entry>}</entry></row><row><entry>==================================</entry></row><row><entry>The code of the control program in the trial link will be:</entry></row><row><entry>==================================</entry></row><row><entry>Control.Link.Constraint.Check( ) {</entry></row><row><entry>  if (GetObject(“TrialState”, 5) > 0) {</entry></row><row><entry>   return SUCCESS;</entry></row><row><entry>  } else {</entry></row><row><entry>   return FAILURE;</entry></row><row><entry>  }</entry></row><row><entry>}</entry></row><row><entry>==================================</entry></row><row><entry>When Alice registers for real to the subscription service, she gets back</entry></row><row><entry>a link (from: Alice, to: Subscription) and an agent</entry></row><row><entry>The code of the agent is as follows:</entry></row><row><entry>==================================</entry></row><row><entry>RealSubscriptionAgent( ) {</entry></row><row><entry>  // erase the TrialState if present</entry></row><row><entry>  trialState = GetObject(“TrialState”);</entry></row><row><entry>  if (trialState != NULL) {</entry></row><row><entry>   SetObject(“TrialState”, NULL); // erase</entry></row><row><entry>  }</entry></row><row><entry>}</entry></row><row><entry>==================================</entry></row><row><entry>The code of the link will be:</entry></row><row><entry>==================================</entry></row><row><entry>Control.Link.Constraint.Check( ) {</entry></row><row><entry>  if (GetTrustedTime( ) < ExpirationDate) {</entry></row><row><entry>   return SUCCESS;</entry></row><row><entry>  } else {</entry></row><row><entry>   return FAILURE;</entry></row><row><entry>  }</entry></row><row><entry>}</entry></row><row><entry>==================================</entry></row><row><entry>The content licenses targeted to the subscription all have the same</entry></row><row><entry>control program:</entry></row><row><entry>==================================</entry></row><row><entry>Action.Play.Perform( ) {</entry></row><row><entry>  // first check if the subscription node is reachable</entry></row><row><entry>  if (!IsNodeReachable(“SubscriptionNode”)) {</entry></row><row><entry>   return new ESB(ACTION_DENIED);</entry></row><row><entry>  }</entry></row><row><entry>  // now check if the TrialState is present</entry></row><row><entry>  if (GetObject(“TrialState) != NULL) {</entry></row><row><entry>   // we're in the trial mode: we need a callback and an obligation</entry></row><row><entry>   return new ESB(ACTION_GRANTED,</entry></row><row><entry>     new OnTimeElapsedCallback(20, DecrementCounter),</entry></row><row><entry>     new DegradeRenderingObligation( ));</entry></row><row><entry>  } else {</entry></row><row><entry>   // we're in paid subscription mode: just return</entry></row><row><entry>   ACTION_GRANTED</entry></row><row><entry>   return new ESB(ACTION_GRANTED);</entry></row><row><entry>  }</entry></row><row><entry>}</entry></row><row><entry>// code of the callback function of OnTimeElapsed</entry></row><row><entry>DecrementCounter( ) {</entry></row><row><entry>  SetObject(“TrialState”, GetObject(“TrialState”) − 1); }</entry></row><row><entry>==================================</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0277Referring once again to <figref idref="DRAWINGS">FIG. 24</figref>, Alice also has an account <b>2420</b> with her mobile service provider, which remains valid as long as she remains connected to the network. Alice is not required to make a special payment for the subscription, in exchange for which she gets sent a link; instead renewal links <b>2424</b> are sent to her phone automatically when she connects to the network. These links enable her to access any of the content items or services offered by the mobile service provider, which have licenses that require only that the subscription node <b>2422</b> be reachable. If Alice changes mobile service providers, she will unable to access previously acquired content once her links <b>2424</b> expire.

0278<figref idref="DRAWINGS">FIG. 25</figref> shows an example of how a service provider might interact with a home network domain <b>2500</b>. In this example, devices are registered to a home network domain which enforces a policy that allows up to <b>5</b> devices to belong to the domain at any one time. Although the Smith family's cable service provider did not provide the domain manager software used to set up the home network domain <b>2500</b>, cable service provider knows that the domain manager has been implemented by a certified provider of home network domain manager software, and thus trusts the domain manager software to operate as intended. As shown in <figref idref="DRAWINGS">FIG. 25</figref>, the Smith family connects Alice's phone and PC, Carl's PVR, and Joe's PSP to the domain <b>2500</b>, resulting in links being issued from each of these devices to the domain node <b>2500</b>. When new content is received, e.g., at the PVR, discovery services such as those described in the '551 application enable the other devices in the domain to automatically obtain the content and any necessary links. Links are issued from the domain node <b>2500</b> to the service provider account node <b>2502</b>. Some of the cable service provider's content has a license with an obligation that fast forward and rewind must be disabled so that advertisements will be viewed. Carl's PVR and PC Alice's PC are able to enforce the obligation, and thus can play the content. Alice's mobile phone is unable to enforce the obligation and thus denies access to the content.

02791.16. Additional Examples: Content and Rights Sharing

0280As the preceding examples illustrate, embodiments of the systems and methods presented herein enable electronic content to be shared in natural ways. For example, the systems and methods described herein can be used to enable consumers to share entertainment content with their friends and family members, and/or enjoy it on all of their family's devices, while simultaneously protecting against wider, unauthorized distribution. For example, automated peer-to-peer discovery and notification services can be used, such that when one device obtains content or associated rights, other devices can automatically become aware of that content, thereby providing a virtual distributed library that can be automatically updated. For example, in one embodiment if one user obtains content or rights on a portable device at one location, then comes home, the user's family's devices can automatically discover and make use of those rights. Conversely, if a user obtains rights on a device on his or her home network, his or her portable devices can discover and carry away that content for use elsewhere. Preferred embodiments of the systems and methods described herein can be used to create services and rights objects that allow the above-described scenarios to be completely automated, using, for example, the service discovery and inspection techniques described in the '551 application. For example, the devices registered to a particular domain may provide services to each other (e.g., sharing of rights and content), and/or remote services can be invoked to facilitate local sharing of content. The systems and methods described enable the creation of DRM frameworks that are not focused on preventing the creation of copies per se, but rather are designed to work harmoniously with network technology to allow content to be shared, while protecting against consumers becoming illicit distributors of the content.

0281Preferred embodiments of the DRM systems and methods described herein also enable the determination of rights without the verbose types of rights expressions characteristic of some other DRM systems. Instead, preferred embodiments use a set of crafted rights objects that can interact contextually. These objects describe relationships and controls among entities such as users, devices, content, and groups thereof. For example, such contextual interactions might allow a device to determine that a given piece of content can be played because (a) the content was obtained from a legitimate content service that the user currently subscribes to, (b) the user is part of a specific family group, and (c) the device is associated with this specific family group. There are numerous types of relationships such as those described in this example, which users understand intuitively, and preferred embodiments of the systems and methods described herein enable the creation of systems that naturally understand these kinds of relationships. The relationships among entities can be created, destroyed, and changed over time, and preferred embodiments provide a natural way of determining rights in a dynamic networked environment—an environment that consumers can naturally understand. Nevertheless, if a content deployer wants to use a more traditional rights expression approach, preferred embodiments can accommodate that as well. For example, tools can be used to translate traditional rights expressions into sets of objects such as those described above, and/or a DRM engine can be implemented that operates directly on such rights expressions. Alternatively, in some embodiments, devices do not need to understand such traditional rights expressions, and are not constrained by their limitations.

0282Preferred embodiments of the systems and methods described herein also have a very general notion of a media service. A broadcast service and an Internet download or subscription service are examples of media services. Restrictions associated with these services can make content difficult to share. With preferred embodiments of the systems and methods described herein, content can be obtained on broadcast, broadband, and mobile services, and shared on a group of networked devices in the home, including portable devices. Alternatively, or in addition, services can be offered by individual devices in a peer-to-peer fashion via wireless connectivity. For example, the new generation of WiFi enabled cellphones can provide content catalog services to other devices. Such a service allows other devices to “see” what content is available to be shared from the device. The service provides information that can be used to determine the rights so that any limitations can be accepted or easily eliminated.

0283Preferred embodiments of the systems and methods described herein are not confined to one service or to one platform. As explained above, preferred embodiments are capable of working with numerous services, including “personal” services. This is becoming more and more important as home and personal networks become more ubiquitous. For example, digital cameras are now available with WiFi connectivity, making it very convenient to share photos over networks. It is nice to be able to automate the sharing of photographs, but the camera will encounter many different networks as it is carried about. Automated sharing is convenient, but personal photos are, of course, personal. Embodiments of the systems and methods described herein make it easy to share photos within a family on the family's devices, but not with arbitrary devices that happen to encounter the camera on a network. In general, as more devices become networked, it is going to be increasingly important to manage the rights of all content on those devices. Although the purpose of networking is to allow information on the networked devices to be shared, networks will overlap and merge into one another. Networks enable content to be shared easily but it should not be shared arbitrarily. Thus, it is desirable to have a DRM system that is network-aware and that can use the context provided by the content, the user, the network, and characteristics of devices to determine if and how content should be shared. Preferred embodiments of systems and methods described herein enable such an approach.

00006. Reference Architecture for Content Consumption and Packaging

0284The following is a description of a reference architecture for a consuming application (e.g., a media player) that consumes DRM-protected content, and a packaging application (e.g., an application residing on a server) that packages content targeted to consuming applications.

02851.17. Client Architecture

0286The following provides an example of functions that an illustrative embodiment of a DRM engine might perform for a host application that consumes content.

02871.17.1. Host Application to DRM Engine Interface

0288Although in a preferred embodiment there is no required API for DRM engines, the following are high-level descriptions of the type of interface provided by an illustrative DRM engine (referred to as the “Octopus” DRM engine) to a host application in one illustrative embodiment:

0289Octopus::CreateSession(hostContextObject)→Session—Creates a session given a Host Application Context. The context object is used by the Octopus DRM engine to make callbacks into the application.

0290Session::ProcessObject(drmObject)—This function should be called by the host application when it encounters certain types of objects in the media files that can be identified as belonging to the DRM subsystem. Such objects include content control programs, membership tokens, etc. The syntax and semantics of those objects is opaque to the host application.

0291Session::OpenContent(contentReference)→Content—The host application calls this function when it needs to interact with a multimedia content file. The DRM engine returns a Content object that can be used subsequently for retrieving DRM information about the content, and interacting with it.

0292Content::GetDrmInfo( )—Returns DRM metadata about the content that is otherwise not available in the regular metadata for the file.

0293Content::CreateAction(actionInfo)→Action—The host application calls this function when it wants to interact with a Content object. The actionInfo parameter specifies what type of action the application needs to perform (e.g., Play), as well as any associated parameters, if necessary. The function returns an Action object that can then be used to perform the action and retrieve the content key.

0294Action::GetKeyInfo( )—Returns information that is necessary for the decryption subsystem to decrypt the content.

0295Action::Check( )—Checks whether the DRM subsystem will authorize the performance of this action (i.e whether Action::Perform( ) would succeed).

0296Action::Perform( )—Performs the action, and carries out any consequences (with their side effects) as specified by the rule that governs this action.

02971.17.2. DRM Engine to Host Services Interface

0298The following is an example of the type of Host Services interface needed by an illustrative embodiment of a DRM engine from an illustrative embodiment of a host application.

0299HostContext::GetFileSystem(type)→FileSystem—Returns a virtual FileSystem object that the DRM subsystem has exclusive access to. This virtual FileSystem will be used to store DRM state information. The data within this FileSystem should only be readable and writeable by the DRM subsystem.

0300HostContext::GetCurrentTime( )—Returns the current date/time as maintainted by the host system.

0301HostContext::GetIdentity( )—Returns the unique ID of this host.

0302HostContext::ProcessObject(dataObject)—Gives back to the host services a data object that may have been embedded inside a DRM object, but that the DRM subsystem has identified as being managed by the host (e.g., certificates).

0303HostContext::VerifySignature(signatureInfo)—Checks the validity of a digital signature over a data object. In one embodiment the signatureinfo object contains information equivalent to the information found in an XMLSig element. The Host Services are responsible for managing the keys and key certificates necessary to validate the signature.

0304HostContext::CreateCipher(cipherType, keyinfo)→Cipher—Creates a Cipher object that the DRM subsystem can use to encrypt and decrypt data. A minimal set of cipher types will be defined, and for each a format for describing the key info required by the cipher implementation.

0305Cipher::Encrypt(data)

0306Cipher::Decrypt(data)

0307HostContext::CreateDigester(digesterType)→Digester—Creates a Digester object that the DRM subsystem can use to compute a secure hash over some data. In one embodiment, a minimal set of digest types can be defined.

0308Digester::Update(data)

0309Digester::GetDigest( )

03101.17.3. UML Sequence Diagram

0311<figref idref="DRAWINGS">FIG. 26</figref> illustrates the use of the illustrative APIs set forth in the preceding sections, and the interactions that take place between the host application and the DRM client engine in an exemplary embodiment.

03121.18. Packager Reference Architecture

0313The following provides an example of the functions that a packaging engine might perform for a host application that packages content. In practice, a packaging application may focus on packaging specifically, or could be part of a general purpose application operating at a user system that also accesses protected content (either packaged locally or elsewhere in a network).

03141.18.1. Host Application to Packaging Engine Interface

0315This section provides a high-level description of an illustrative API between a host application and a packaging engine used in connection with a reference DRM engine referred to as “Octopus”.

0316Octopus::CreateSession(hostContextObject)→Session. Creates a session given a host application context. The context object that is returned by this function is used by the packaging engine to make callbacks into the application.

0317Session::CreateContent(contentReferences[])→Content. The host application calls this function in order to create a content object that will be associated with license objects in subsequent steps. Having more than one content reference in the contentReferences array implies that these are bound together in a bundle (e.g., one audio and one video track) and that the license issued should be targeted to these as one indivisible group.

0318Content::SetDrmInfo(drmInfo). The drmInfo parameter specifies the metadata of the license that will be issued. The drmInfo will act as a guideline to translate the license into bytecode for the virtual machine.

0319Content::GetDRMObjects(format)→drmObjects. This function is called when the host application is ready to get the drmObjects that the packager engine created. The format parameter will indicate the format expected for these objects (e.g., XML or binary atoms).

0320Content::GetKeys( )→keys[]. This function is called by the host packaging application when it needs keys in order to encrypt content. In one embodiment, there is one key per content reference.

03211.18.2. Packaging Engine to Host Services Interface

0322The following is an example of the type of interface that an illustrative packaging engine needs the host application to provide in one embodiment.

0323HostContext::GetFileSystem(type)→FileSystem. Returns a virtual FileSystem object that the DRM subsystem has exclusive access to. This virtual FileSystem can be used to store DRM state information. The data within this FileSystem should only be readable and writeable by the DRM subsystem.

0324HostContext::GetCurrentTime( )→Time. Returns the current date/time as maintainted by the host system.

0325HostContext::Getldentity( )→ID. Returns the unique ID of this host.

0326HostContext::PerformSignature(signatureInfo, data). Some DRM objects created by the packaging engine will have to be trusted. This service provided by the host will be used to sign a specified object.

0327HostContext::CreateCipher(cipherType, keyInfo)→Cipher. Creates a cipher object (an object that is able to encrypt and decrypt data) that the packaging engine can use to encrypt and decrypt data. In one embodiment, the cipher object is used to encrypt the content key data in the ContentKey object.

0328Cipher::Encrypt(data). Encrypts data.

0329Cipher::Decrypt(data). Decrypts data.

0330HostContext::CreateDigester(digesterType)→Digester. Creates a digester object that the packaging engine can use to compute a secure hash over some data.

0331Digester::Update(data). Feeds data to the digester object.

0332Digester::GetDigest( ). Computes a digest.

0333HostContext::GenerateRandomNumber( ). Generates a random number that can be used for generating a key.

0334<figref idref="DRAWINGS">FIG. 27</figref> is a UML diagram showing an example of the use of the illustrative APIs set forth above, and the interactions that take place between the host application and the packaging engine in one illustrative embodiment.

00007. Objects

0335This section provides more information regarding the DRM objects that serve as the building blocks of an illustrative implementation of a DRM engine. First, a relatively high-level overview is given of the types of objects the DRM engine uses for content protection and governance. Next, a more detailed description of these objects and the information they convey is provided, along with some example data structures used in one illustrative embodiment.

03361.19. Content Protection and Governance DRM Objects

0337As previously described in connection with <figref idref="DRAWINGS">FIG. 6</figref>, content governance objects (sometimes referred to, collectively with node and link objects, as “DRM objects”) are used to associate usage rules and conditions with protected content. Together, these objects form a license.

0338As shown in <figref idref="DRAWINGS">FIG. 6</figref>, the data represented by content object <b>614</b> is encrypted using a key. That key needed to decrypt the content is represented by ContentKey object <b>602</b>, and the binding between the content and the key used to encrypt it is represented by protector object <b>604</b>. The rules that govern the use of the decryption key are represented by control object <b>608</b>, and the binding between the ContentKey <b>602</b> and the control object <b>608</b> is represented by controller object <b>606</b>. In one embodiment, trusted systems will only make use of the content decryption key under governance of the rules expressed by the byte code in control object <b>608</b>. <figref idref="DRAWINGS">FIG. 28A</figref> is a more detailed illustration of a license such as that shown in <figref idref="DRAWINGS">FIG. 6</figref>, and illustrates a signature scheme that is used in one embodiment.

03391.19.1. Common Elements

0340In one embodiment, objects share common basic traits: they can each have an ID, a list of attributes, and a list of extensions.

03411.19.1.1. IDs

0342Objects that are referenced by other objects have a unique ID. In one embodiment, IDs are simply URIs, and the convention is that those URIs are URNs

03431.19.1.2. Attributes

0344Attributes are typed values. Attributes can be named or unnamed. The name of a named attribute is a simple string or URI. The value of an attribute is of a simple type (string, integer, or byte array) or a compound type (list and array). Attributes of type ‘list’ contain an unordered list of named attributes. Attributes of type ‘array’ contain an ordered array of unnamed attributes.

0345An object's ‘attributes’ field is a (possibly empty) unordered collection of named attributes.

03461.19.1.3. Extensions

0347Extensions are elements that can be added to objects to carry optional or mandatory extra data. Extensions are typed, and have unique IDs as well. Extensions can be internal or external.

03481.19.1.3.1. Internal extensions

0349Internal extensions are contained in the object they extend. They have a ‘critical’ flag that indicates whether the specific extension data type for the extension is required to be known to the implementation that uses the object. In one embodiment, if an implementation encounters an object with a critical extension with a data type that it does not understand, it must reject the entire object.

0350In one embodiment, the ID of an internal extension needs to be locally unique: an object cannot contain two extensions with the same ID, but it is possible that two different objects each, contain an extension with the same ID as that of an extension of the other object.

0351An object's ‘extensions’ field is a (possibly empty) unordered collection of internal extensions.

03521.19.1.3.2. External extensions

0353External extensions are not contained in the object they extend. They appear independently of the object, and have a ‘subject’ field that contains the ID of the object they extend. In one embodiment, the ID of an external extension needs to be globally unique.

03541.19.2. Content

0355In one embodiment, the content object is an “external” object. Its format and storage are not under the control of the DRM engine, but under the content management subsystem of the host application (for instance, the content could be an MP4 movie file, an MP3 music track, etc.). In one embodiment, the format for the content needs to provide support for associating an ID with the content payload data. The content payload is encrypted in a format-dependent manner (typically with a symmetric cipher, such as AES).

03561.19.3. ContentKey

0357The ContentKey object represents a unique encryption key, and associates an ID with it. The purpose of the ID is to enable Protector objects and Controller objects to make references to ContentKey objects. The actual key data encapsulated in the ContentKey object is itself encrypted so that it can only be read by the recipients that are authorized to decrypt the content. The ContentKey object specifies which cryptosystem was used to encrypt the key data. The cryptosystem used to protect the content key data is called the Key Distribution System. Different Key Distribution Systems can be used. An example of a Key Distribution System is the Scuba Key Distribution System described above.

03581.19.4. Protector

0359The Protector object contains the information that makes it possible to find out which key was used to encrypt the data of Content objects. It also contains information about which encryption algorithm was used to encrypt that data. In one embodiment, the Protector object contains one or more IDs that are references to Content objects, and exactly one ID that is a reference to the ContentKey object that represents the key that was used to encrypt the data. If the Protector points to more than one Content object, all those Content objects represent data that has been encrypted using the same encryption algorithm and the same key. In one embodiment, unless the cryptosystem used allows a safe way of using the same key for different data items, it is not recommended that a Protector object point to more than one Content object.

03601.19.5. Control

0361The control object contains the information that allows the DRM engine to make decisions regarding whether certain actions on the content should be permitted when requested by the host application. In one embodiment, the rules that govern the use of content keys are encoded in the control object as byte code for execution by the virtual machine. The control object also has a unique ID so that it can be referenced by a controller object. In one embodiment, control objects are signed, so that the DRM engine can verify that the control byte code is valid and trusted before it is used to make decisions. The validity of the control object can also optionally be derived through the verification of a secure hash contained in a controller object.

03621.19.6. Controller

0363The controller object contains the information that allows the DRM engine to find out which control governs the use of one or more keys represented by ContentKey objects. The controller object contains information that binds it to the ContentKey objects and the control object that it references. In one embodiment, controller objects are signed (e.g., by a packager application that has a certificate allowing it to sign controller objects), so that the validity of the binding between the ContentKey and the control object that governs it, as well as the validity of the binding between the ContentKey ID and the actual key data, can be established. The signature of the controller object can be a public key signature or a symmetric key signature, or a combination of both. Also, when the digest of the control object referenced by the controller object is included in the controller object, the validity of the control object can be derived without having to separately verify the signature of the control object.

03641.19.6.1. Symmetric Key Signature

0365In one embodiment, this is the preferred type of signature for controller objects, and is implemented by computing a Message Authentication Code (MAC) of the controller object, keyed with the same key as the key represented by the corresponding ContentKey object. In one embodiment, the canonical method for this MAC is to use HMAC with the same hashing algorithm as the one chosen for the PKI signature algorithm used in the same deployment.

03661.19.6.2. Public Key Signature

0367This type of signature is used when the identity of the signer of the controller object needs to be known. This type of signature is implemented with a public key signature algorithm, signing with the private key of the principal who is asserting the validity of this object. In one embodiment, when using this type of signature, a symmetric key signature will also be present, and sign both the controller object as well as the public key signature, so that is can be guaranteed that the principal who signed with its private key also had knowledge of the actual value of the content key carried in the ContentKey object.

03681.20. Identity and Key Management DRM Objects

0369As previously described, node objects represent entities in a DRM profile, and no implicit or explicit semantics are used to define what the node objects represent. A given deployment (DRM profile) of a system will define what types of principals exist, and what roles and identities different node objects represent. That semantic information is typically expressed using attributes of the node object.

0370Link objects represent relationships between nodes. Link objects can also optionally contain some cryptographic data that allows the link to be used for content key derivation. Just as for nodes, in one embodiment no implicit or explicit semantics are used to define what a link relationship means. Depending on what the from and to nodes of the link represent in a given DRM Profile, the meaning of the link relationship can express membership, ownership, association, and/or many other types of relationships. In a typical DRM profile, some node objects could represent users, other nodes could represent devices, and other nodes could represent user groups or authorized domains (ADs). In such a context, links between devices and users might represent an ownership relationship, and links between users and user groups or authorization domains might represent membership relationships. <figref idref="DRAWINGS">FIG. 28B</figref> illustrates the structure and interrelationship between nodes and links in one example embodiment.

03711.20.1. Node

0372The node object represents an entity in the system. The node object's attributes define certain aspects of what the node object represents, such as the role or identity represented by the node object in the context of a DRM profile. The node object may also have a confidentiality asymmetric key pair that is used for targeting confidential information to the subsystems that have access to the confidential parts of the node object (typically, the entity represented by the node, or some entity that is responsible for managing that node). Confidential information targeted at a node can be encrypted with that node's confidentiality public key. The node object may also have a sharing asymmetric key pair and a sharing symmetric key can be used in conjunction with link objects when the system uses a ContentKey derivation system for ContentKey distribution, such as that described elsewhere herein. In a preferred embodiment, only entities that need to be referenced by link or control objects, or to receive cryptographically targeted information, need to have corresponding node objects.

03731.20.2. Link

0374The link object is a signed assertion that there exists a directed edge in the graph whose vertices are the node objects. For a given set of nodes and links, we say that there is a path between a node X and a node Y if there exists a directed path between the node X vertex and the node Y vertex in the graph. When there is a path between node X and node Y, we say that node Y is reachable from node X. The assertions represented by link objects are used to express which nodes are reachable from other nodes. The controls that govern content objects can check, before they allow an action to be performed, that certain nodes are reachable from the node associated with the entity performing the action. For example, if node D represents a device that wants to perform the “play” action on a content object, a control that governs the content object can test if a certain node, U, representing a certain user, is reachable from node D. To determine if node U is reachable, the DRM engine can check whether there is a set of link objects that can establish a path between node D and node U.

0375In one embodiment, the DRM engine verifies link objects before it uses them to decide the existence of paths in the node graph. Depending on the specific features of the certificate system (e.g., x509v3) used to sign link objects, link objects can be given limited lifetimes, be revoked, etc. In one embodiment, the policies that govern which keys can sign link objects, which link objects can be created, and the lifetime of link objects are not directly handled by the DRM engine. Instead, those policies leverage the node's attribute information. To facilitate the task of enforcing certain policies, in one embodiment, a way to extend standard certificate formats with additional constraint checking is provided. These extensions make it possible to express validity constraints on certificates for keys that sign links, such that constraints such as what type of nodes the link is connecting, as well as other attributes, can be checked before a link is considered valid.

0376In one embodiment, a link object can contain a control object that will be used to constrain the validity of the link. In addition, in one embodiment a link object may contain cryptographic key derivation data that provides the user with sharing keys for key distribution. That cryptographic data will contain, in addition to metadata, the private and/or symmetric sharing keys of the “from” node, encrypted with the sharing public key and/or the sharing symmetric key of the “to” node.

03771.21. Data Structures

0378The following paragraphs describe, in more detail, an illustrative object model for the objects discussed above, defining the fields that each type of object has in one illustrative embodiment. Data structures are described using a relatively simple object description syntax. Each object type is defined by a class that can extend a parent class (this is an “is-a” relationship). The class descriptions are in terms of the simple abstract types “string” (character strings), “int” (integer value), “byte” (8-bit value), and “boolean” (true or false) but do not define any specific encoding for those data types, or for compound structures containing those types. The way objects are encoded, or represented, can vary depending on the implementation of the engine. In practice, a given profile of use of the DRM engine can specify how the fields are represented (e.g., using an XML schema).

0379In one illustrative embodiment, the following notations are used: <tables id="TABLE-US-00005" num="5"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="98PT" align="left" /><colspec colname="2" colwidth="119PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>class ClassName {</entry><entry>Defines a class type. A class type is a</entry></row><row><entry>  field1;</entry><entry>heterogeneous compound data type</entry></row><row><entry>  field2;</entry><entry>(also called object type). This</entry></row><row><entry>  ....</entry><entry>compound type is made up of one or</entry></row><row><entry>}</entry><entry>more fields, each of a simple or</entry></row><row><entry /><entry>compound type. Each field can be of a</entry></row><row><entry /><entry>different type.</entry></row><row><entry>type[ ]</entry><entry>Defines a homogeneous compound data</entry></row><row><entry /><entry>type (also called list or array type). This</entry></row><row><entry /><entry>compound type is made up of 0 or more</entry></row><row><entry /><entry>elements of the same type (0 when the</entry></row><row><entry /><entry>list is empty).</entry></row><row><entry>String</entry><entry>Simple type: represents a character</entry></row><row><entry /><entry>string</entry></row><row><entry>Int</entry><entry>Simple type: represents an integer value</entry></row><row><entry>Byte</entry><entry>Simple type: represents an integer value</entry></row><row><entry /><entry>between 0 and 255</entry></row><row><entry>Boolean</entry><entry>Simple type: represents a boolean value</entry></row><row><entry /><entry>(true or false)</entry></row><row><entry>class SubClass extends</entry><entry>Defines a class type that extends</entry></row><row><entry>  SuperClass {...}</entry><entry>another class type. A class that extends</entry></row><row><entry /><entry>another one contains all the fields of the</entry></row><row><entry /><entry>class it extends (called the superclass)</entry></row><row><entry /><entry>in addition to its own fields.</entry></row><row><entry>Abstract class {...}</entry><entry>Defines an abstract class type. Abstract</entry></row><row><entry /><entry>class types are types that can be</entry></row><row><entry /><entry>extended, but are never used by</entry></row><row><entry /><entry>themselves.</entry></row><row><entry>{type field;}</entry><entry>Defines an optional field. An optional</entry></row><row><entry /><entry>field is a field that may be omitted from</entry></row><row><entry /><entry>the compound data type that contains it.</entry></row><row><entry>(type field;)</entry><entry>Defines a field that will be skipped</entry></row><row><entry /><entry>when computing the canonical byte</entry></row><row><entry /><entry>sequence for the enclosing compound</entry></row><row><entry /><entry>field</entry></row><row><entry>class SubClass extends</entry><entry>Defines a subclass of a class type and</entry></row><row><entry> SuperClass(field=value) {...}</entry><entry>specifies that for all instances of that</entry></row><row><entry /><entry>subclass, the value of a certain field of</entry></row><row><entry /><entry>the superclass is always equal to a fixed</entry></row><row><entry /><entry>value.</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

03801.21.1. Common structures

0381In one illustrative embodiment, the following common structures are used: <tables id="TABLE-US-00006" num="6"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="56PT" align="left" /><colspec colname="1" colwidth="161PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>abstract class Octobject {</entry></row><row><entry /><entry> {string id;}</entry></row><row><entry /><entry> Attribute[ ] attributes;</entry></row><row><entry /><entry> InternalExtension[ ] extensions;</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry>class Transform {</entry></row><row><entry /><entry> string algorithm;</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry>class Digest {</entry></row><row><entry /><entry> Transform[ ] transforms;</entry></row><row><entry /><entry> string algorithm;</entry></row><row><entry /><entry> byte[ ] value;</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry>class Reference {</entry></row><row><entry /><entry> string id;</entry></row><row><entry /><entry> {Digest digest;}</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

03821.21.1.1. Attributes

0383In one embodiment, there are four kinds of attributes: IntegerAttribute, StringAttribute, ByteArrayAttribute, and ListAttribute, each having a name and a type. <tables id="TABLE-US-00007" num="7"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="21PT" align="left" /><colspec colname="1" colwidth="196PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>abstract class Attribute {</entry></row><row><entry /><entry> {string name;}</entry></row><row><entry /><entry> string type;</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry>class IntegerAttribute extends Attribute(type=’int’) {</entry></row><row><entry /><entry> int value;</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry>class StringAttribute extends Attribute(type=’string’) {</entry></row><row><entry /><entry> string value;</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry>class ByteArrayAttribute extends Attribute(type=’bytes’) {</entry></row><row><entry /><entry> byte[ ] value;</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry>Class ListAttribute extends Attribute(type=’list’) {</entry></row><row><entry /><entry> Attribute[ ] attributes; // must all be named</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry>Class ArrayAttribute extends Attribute(type=’array’) {</entry></row><row><entry /><entry> Attribute[ ] attributes; // must all be unnamed</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

03841.21.1.2. Extensions

0385In the illustrative embodiment under discussion, there are two types of extensions: internal extensions, which are carried inside the Octobject, and external extensions, which are carried outside the Octobject. <tables id="TABLE-US-00008" num="8"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="42PT" align="left" /><colspec colname="1" colwidth="175PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>abstract class ExtensionData {</entry></row><row><entry /><entry> string type;</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry>abstract class Extension {</entry></row><row><entry /><entry> string id;</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry>class ExternalExtension extends Extension {</entry></row><row><entry /><entry> string subject;</entry></row><row><entry /><entry> ExtensionData data;</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry>class InternalExtension extends Extension {</entry></row><row><entry /><entry> boolean critical;</entry></row><row><entry /><entry> {Digest dataDigest;}</entry></row><row><entry /><entry> (ExtensionData data;)</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0386In some embodiments, it will be important to be able to verify the signature of an object even if a particular type of ExtensionData is not understood by a given implementation. Thus, in one embodiment, a level of indirection with the dataDigest field is added. If the specification of the ExtensionData mandates that the data is part of the signature within the context of a particular object, then the dataDigest field will be present. An implementation that understands this ExtensionData, and is therefore capable of computing its canonical representation, can then verify the digest. If, in such an embodiment, the specification of this ExtensionData mandates that the data is not part of the signature, then the dataDigest field will not be present.

03871.21.2. Node Objects <tables id="TABLE-US-00009" num="9"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="63PT" align="left" /><colspec colname="1" colwidth="154PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>class Node extends Octobject {</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

03881.21.3. Link Objects <tables id="TABLE-US-00010" num="10"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="63PT" align="left" /><colspec colname="1" colwidth="154PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>class Link extends Octobject {</entry></row><row><entry /><entry> string fromId;</entry></row><row><entry /><entry> string toId;</entry></row><row><entry /><entry> {Control control;}</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

03891.21.4. Control Objects <tables id="TABLE-US-00011" num="11"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="56PT" align="left" /><colspec colname="1" colwidth="161PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>class Control extends Octobject {</entry></row><row><entry /><entry> string protocol;</entry></row><row><entry /><entry> string type;</entry></row><row><entry /><entry> byte[ ] codeModule;</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

03901.21.5. ContentKey Objects <tables id="TABLE-US-00012" num="12"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="49PT" align="left" /><colspec colname="1" colwidth="168PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>abstract class Key {</entry></row><row><entry /><entry>  string id;</entry></row><row><entry /><entry>  string usage;</entry></row><row><entry /><entry>  string format;</entry></row><row><entry /><entry>  byte[ ] data;</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry>abstract class PairedKey extends Key {</entry></row><row><entry /><entry>  string pairId;</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry>class ContentKey extends Octobject {</entry></row><row><entry /><entry>  Key secretKey;</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0391In one embodiment, each key has a unique id, a format, a usage (that can be null), and data. The ‘usage’ field, if it is not empty, specifies the purpose for which the key can be used. For normal content keys, this field is empty. In embodiments in which a key distribution scheme such as that described above is used, this field may specify if this is a sharing key or a confidentiality key. The ‘format’ field specifies the format of the ‘data’ field (such as, for example, ‘RAW’ for symmetric keys, or ‘PKCS#8’ for RSA private keys, etc.). The ‘data’ field contains the actual key data, formatted according to the ‘format’ field.

0392For keys that are part of a key pair (such as RSA keys), the extra field ‘pairId’ gives a unique identifier for the pair, so that the pair can be referenced from other data structures.

0393In one embodiment the data field in the key object is the plaintext value of the actual key (i.e., it is the plaintext value of the key that will be hashed), even though the object's actual representation contains an encrypted copy of the key.

03941.21.6. Controller objects <tables id="TABLE-US-00013" num="13"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="49PT" align="left" /><colspec colname="1" colwidth="168PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>class Controller extends Octobject {</entry></row><row><entry /><entry>  Reference controlRef;</entry></row><row><entry /><entry>  Reference[ ] contentKeyRefs;</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> 8. Virtual Machine

0395Preferred embodiments of the DRM engine described herein use a virtual machine (sometimes referred to herein as the “control virtual machine,” the “control VM,” or simply the “VM”) to execute control programs that govern access to content. Illustrative embodiments of such a virtual machine are decribed below, as are various modifications and design considerations that could e made to this illustrative embodiment. The integration of an illustrative embodiment of the virtual machine (referred to as the “Plankton” virtual machine) with an illustrative embodiment of the DRM engine (referred to as “Octopus”) is also described. It should be appreciated, however, that embodiments of the digital rights management engine, architecture, and other systems and methods described herein can be used with any suitable virtual machine, or, in some embodiemts, without a virtual machine at all, and thus it will be appreciated that the details provided below regarding example embodiments of a virtual machine are for purposes of illustration and not limitation.

0396In a preferred embodiment, the control VM is a traditional virtual machine, designed to be easy to implement using various programming languages with a very small code footprint. It is based on a simple, stack-oriented instruction set that is designed to be minimalist, without undue concern for execution speed or code density. In situations where compact code is required, data compression techniques can be used to compress the virtual machine's byte code.

0397In preferred embodiments, the control virtual machine is designed to be suitable as a target for low or high level programming languages, and supports assembler, C, and FORTH. In addition, it will be appreciated that compilers for other languages, such as Java or custom languages, can be created in a relatively straightforward fashion to compile code into the format (e.g., byte code) used by the virtual machine. In one embodiment the control virtual machine is designed to be hosted within a host environment, not run directly on a processor or in silicon. In preferred embodiments, the natural host environment for the virtual machine is the DRM engine, although it will be appreciated that the virtual machine architecture described herein could alternatively, or in addition, be used in other contexts.

0398<figref idref="DRAWINGS">FIG. 29</figref> illustrates the operating environment of an illustrative implementation of the control virtual machine <b>2902</b>. As shown in <figref idref="DRAWINGS">FIG. 29</figref>, in one embodiment virtual machine <b>2902</b> runs within the context of its host environment <b>2904</b>, which implements some of the functions needed by the virtual machine as it executes programs <b>2906</b>. Typically, the control VM runs within the DRM engine <b>2908</b>, which implements its host environment. As shown in <figref idref="DRAWINGS">FIG. 29</figref>, in a preferred database, the virual machine <b>2902</b> and the DRM engine <b>2908</b> have access to a secure database <b>2910</b> for presistant storage of state information.

03991.22. Architecture

04001.22.1. Execution Model

0401In preferred embodiments, the VM runs programs by executing instructions stored in byte code in code modules. Some of these instructions can call functions implemented outside of the program itself by making system calls. System calls can be implemented by the VM itself or delegated to the host environment.

0402In one embodiment, the VM executes instructions stored in code modules as a stream of byte codes loaded into memory. The VM maintains a virtual register called the Program Counter (PC), which is incremented as instructions are executed. The VM executes each instruction, in sequence, until an OP_STOP instruction is encountered, an OP_RET instruction is encountered with an empty call stack, or a runtime exception occurs. Jumps are specified either as a relative jump (specified as a byte offset from the current value of PC), or as an absolute address.

04031.22.2. Memory Model

0404In one embodiment, the VM uses a relatively simple memory model, in which memory is separated into data memory and code memory. For example, data memory can be implemented as a single, flat, contiguous memory space, starting at address 0, and can be implemented as an array of bytes allocated within the heap memory of the host application or host environment. In one embodiment, attempts to access memory outside of the allocated space will cause a runtime exception which will cause program execution to terminate.

0405Data memory is potentially shared between several code modules concurrently loaded by the virtual machine. The data in the data memory can be accessed by memory-access instructions, which, in one embodiment, can be either 32-bit or 8-bit accesses. 32-bit memory accesses are performed using big-endian byte order. In a preferred embodiment, no assumptions are made with regards to alignment between the virtual machine-visible memory and the host-managed memory (i.e., the host CPU virtual or physical memory).

0406In one embodiment, code memory is a flat, contiguous memory space, starting at address <b>0</b>, and can be implemented as an array of bytes allocated within the heap memory of the host application or host environment.

0407The VM may support loading more than one code module. If the VM loads several code modules, in one embodiment all the code modules share the same data memory (although each module's data is preferably loaded at a different address), but each has its own code memory, thus preventing a jump instruction in one code module to cause a jump to code in another code module.

0408<b>1</b>.<b>22</b>.<b>3</b>. Data Stack

0409In one embodiment, the VM has the notion of a data stack, which represents 32-bit data cells stored in the data memory. The VM maintains a virtual register called the Stack Pointer (SP). After reset, the SP points to the end of the data memory, and the stack grows downward (when data is pushed on the data stack, the SP register is decremented). The 32-bit data cells on the stack are interpreted either as 32-bit addresses or 32-bit integers, depending on the instruction referencing the stack data. Addresses are unsigned integers. In one embodiment, all other 32-bit integer values on the data stack are interpreted as signed integers unless otherwise specified.

04101.22.4. Call Stack

0411In one embodiment, the VM manages a call stack used for making subroutine calls. In one embodiment, the values pushed on this stack cannot be read or written directly by the memory-access instructions. This stack is used internally by the VM when executing OP_JSR, OP_JSRR, and OP_RET instructions. For a given VM implementation, the size of this return address stack can be fixed to a maximum, which will allow only a certain number of nested calls.

04121.22.5. Pseudo Registers

0413In one embodiment, the VM reserves a small address space at the beginning of data memory to map pseudo-registers. In one embodiment, the addresses of these pseudo-registers are fixed. For example, the following registers could be defined: <tables id="TABLE-US-00014" num="14"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="35PT" align="center" /><colspec colname="2" colwidth="28PT" align="center" /><colspec colname="3" colwidth="21PT" align="left" /><colspec colname="4" colwidth="133PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row><row><entry>Address</entry><entry>Size</entry><entry>Name</entry><entry>Description</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="35PT" align="char" char="." /><colspec colname="2" colwidth="28PT" align="center" /><colspec colname="3" colwidth="21PT" align="left" /><colspec colname="4" colwidth="133PT" align="left" /><tbody valign="top"><row><entry>0</entry><entry>4</entry><entry>ID</entry><entry>32-bit ID of the currently executing code</entry></row><row><entry /><entry /><entry /><entry>segment. This ID is chosen by the VM</entry></row><row><entry /><entry /><entry /><entry>when a module is loaded. The VM</entry></row><row><entry /><entry /><entry /><entry>changes this register if it changes from</entry></row><row><entry /><entry /><entry /><entry>the code segment of one module to the</entry></row><row><entry /><entry /><entry /><entry>code segment of another module</entry></row><row><entry>4</entry><entry>4</entry><entry>DS</entry><entry>32-bit value set to the absolute data</entry></row><row><entry /><entry /><entry /><entry>address at which the data segment of the</entry></row><row><entry /><entry /><entry /><entry>currently executing module has been</entry></row><row><entry /><entry /><entry /><entry>loaded. This value is determined by the</entry></row><row><entry /><entry /><entry /><entry>VM's module loader</entry></row><row><entry>8</entry><entry>4</entry><entry>CS</entry><entry>32-bit value set to the absolute code</entry></row><row><entry /><entry /><entry /><entry>address at which the code segment of the</entry></row><row><entry /><entry /><entry /><entry>currently executing module has been</entry></row><row><entry /><entry /><entry /><entry>loaded. This value is determined by the</entry></row><row><entry /><entry /><entry /><entry>VM's module loader.</entry></row><row><entry>12</entry><entry>4</entry><entry>UM</entry><entry>32-bit value set to the absolute data</entry></row><row><entry /><entry /><entry /><entry>address of the first byte following the</entry></row><row><entry /><entry /><entry /><entry>region of the data memory space where</entry></row><row><entry /><entry /><entry /><entry>the data segments of code modules have</entry></row><row><entry /><entry /><entry /><entry>been loaded.</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

04141.22.6. Memory Map

0415The following shows the layout of data memory and code memory in an illustrative embodiment:

0416Data Memory <tables id="TABLE-US-00015" num="15"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="63PT" align="left" /><colspec colname="2" colwidth="154PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row><row><entry>Address Range</entry><entry>Description</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry> 0 to 15</entry><entry>Pseudo-registers</entry></row><row><entry> 16 to 127</entry><entry>Reserved for future VM/System use</entry></row><row><entry>128 to 255</entry><entry>Reserved for application use</entry></row><row><entry>256 to DS − 1</entry><entry>Unspecified. The VM may load the data</entry></row><row><entry /><entry>segments of code modules at any address at or</entry></row><row><entry /><entry>above 256. If it chooses an address larger than</entry></row><row><entry /><entry>256, the use of the address space between 256</entry></row><row><entry /><entry>and DS is left unspecified. This means that the</entry></row><row><entry /><entry>virtual machine implementation is free to use it</entry></row><row><entry /><entry>any way it sees fit.</entry></row><row><entry>DS to UM − 1</entry><entry>Image of the data segments of one or more code</entry></row><row><entry /><entry>modules loaded by the virtual machine.</entry></row><row><entry>UM to End</entry><entry>Shared address space. The code modules' data</entry></row><row><entry /><entry>and the data stack share this space. The data stack</entry></row><row><entry /><entry>is located at the end of that space and grows</entry></row><row><entry /><entry>down. The end represents the last address of the</entry></row><row><entry /><entry>data memory space. The size of the data memory</entry></row><row><entry /><entry>space is fixed by the VM based on memory</entry></row><row><entry /><entry>requirements contained in the code module and</entry></row><row><entry /><entry>implementation requirements.</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0417Code Memory <tables id="TABLE-US-00016" num="16"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="70PT" align="left" /><colspec colname="2" colwidth="147PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row><row><entry>Address Range</entry><entry>Description</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>0 to CS − 1</entry><entry>Unspecified. The virtual machine may load the</entry></row><row><entry /><entry>code segments of code modules at any address at</entry></row><row><entry /><entry>or above 0. If it chooses an address larger than 0,</entry></row><row><entry /><entry>the use of the address space between 0 and CS is</entry></row><row><entry /><entry>left unspecified. This means that the virtual</entry></row><row><entry /><entry>machine is free to use it in any way it sees fit.</entry></row><row><entry>CS to CS + size(code</entry><entry>Image of the code segment of a code module</entry></row><row><entry>segment) − 1</entry><entry>loaded by the virtual machine</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

04181.22.7. Executing Routines

0419Before executing a code routine, in one embodiment the virtual machine implementation resets the data stack pointer to point to the top of the initialized data stack. The initialized data stack contains the routine's input data, and extends to the end of the data memory. The initialized data stack may be used as a way to pass input arguments to a routine. When there is no initialized data stack, the data stack pointer points to the end of the data memory. In one embodiment, the initial call stack is either empty or contains a single terminal return address pointing to an OP_STOP instruction, which will force execution of the routine to end on an OP_STOP instruction in case the routine finished with an OP_RET instruction.

0420When execution stops, either because a final OP_RET instruction with an empty call stack has been executed or a final OP_STOP instruction has been executed, any data left on the data stack is considered to be the output of the routine.

04211.22.8. Runtime Exceptions

0422In one embodiment, any of the following conditions is considered to be a runtime exception which causes execution to stop immediately: <ul id="ul0011" list-style="none"><li id="ul0011-0001" num="0423"> An attempt to access data memory outside the current data memory address space. </li><li id="ul0011-0002" num="0424"> An attempt to set the PC to, or cause the PC to, reach a code address outside the current code memory address space. </li><li id="ul0011-0003" num="0425"> An attempt to execute undefined byte code. </li><li id="ul0011-0004" num="0426"> An attempt to execute an OP_DIV instruction with a top-of-stack operand equal to 0. </li><li id="ul0011-0005" num="0427"> An attempt to execute an OP_MOD instruction with a top-of-stack operand equal to 0. </li><li id="ul0011-0006" num="0428"> An overflow or underflow of the Call Stack. </li></ul>

04291.23. Instruction Set

0430In one embodiment, the control VM uses a relatively simple instruction set. Though limited, the number of instructions is sufficient to express programs of arbitrary complexity. Instructions and their operands are represented by a stream of byte codes. In one embodiment, the instruction set is stack-based, and except for the OP_PUSH instruction, none of the instructions have direct operands. Operands are read from the data stack, and results pushed on the data stack. In one embodiment, the VM is a 32-bit VM: all the instructions operate on 32-bit stack operands, representing either memory addresses or signed integers. Signed integers are represented with 2s complement binary encoding. An illustrative embodiment of an instruction set for use with the control VM is shown in the following table. In the table, the stack operands for instructions with two operands are listed as “A,B” where the operand on the top of the stack is listed last (i.e., “B”). Unless otherwise specified, the term “push,” as used in the following description of one illustrative embodiment, refers to pushing a 32-bit value onto the top of the data stack. <tables id="TABLE-US-00017" num="17"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="5"><colspec colname="1" colwidth="49PT" align="left" /><colspec colname="2" colwidth="42PT" align="left" /><colspec colname="3" colwidth="35PT" align="center" /><colspec colname="4" colwidth="35PT" align="left" /><colspec colname="5" colwidth="105PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row><row><entry>OP CODE</entry><entry>Name</entry><entry>Byte Code</entry><entry>Operands</entry><entry>Description</entry></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="5"><colspec colname="1" colwidth="49PT" align="left" /><colspec colname="2" colwidth="42PT" align="left" /><colspec colname="3" colwidth="35PT" align="char" char="." /><colspec colname="4" colwidth="35PT" align="left" /><colspec colname="5" colwidth="105PT" align="left" /><tbody valign="top"><row><entry>OP_NOP</entry><entry>No</entry><entry>0</entry><entry /><entry>Do Nothing</entry></row><row><entry /><entry>Operation</entry></row><row><entry>OP_PUSH</entry><entry>Push</entry><entry>1</entry><entry>N (direct)</entry><entry>Push a 32-bit constant</entry></row><row><entry /><entry>Constant</entry></row><row><entry>OP_DROP</entry><entry>Drop</entry><entry>2</entry><entry /><entry>Remove the top cell of the data</entry></row><row><entry /><entry /><entry /><entry /><entry>stack</entry></row><row><entry>OP_DUP</entry><entry>Duplicate</entry><entry>3</entry><entry /><entry>Duplicate the top cell of the</entry></row><row><entry /><entry /><entry /><entry /><entry>data stack</entry></row><row><entry>OP_SWAP</entry><entry>Swap</entry><entry>4</entry><entry /><entry>Swap top two stack cells</entry></row><row><entry>OP_ADD</entry><entry>Add</entry><entry>5</entry><entry>A, B</entry><entry>Push the sum of A and B (A + B)</entry></row><row><entry>OP_MUL</entry><entry>Multiply</entry><entry>6</entry><entry>A, B</entry><entry>Push the product of A and B</entry></row><row><entry /><entry /><entry /><entry /><entry>(A * B)</entry></row><row><entry>OP_SUB</entry><entry>Subtract</entry><entry>7</entry><entry>A, B</entry><entry>Push the difference between A</entry></row><row><entry /><entry /><entry /><entry /><entry>and B (A − B)</entry></row><row><entry>OP_DIV</entry><entry>Divide</entry><entry>8</entry><entry>A, B</entry><entry>Push the division of A by B</entry></row><row><entry /><entry /><entry /><entry /><entry>(A/B)</entry></row><row><entry>OP_MOD</entry><entry>Modulo</entry><entry>9</entry><entry>A, B</entry><entry>Push A modulo B (A % B)</entry></row><row><entry>OP_NEG</entry><entry>Negate</entry><entry>10</entry><entry>A</entry><entry>Push the 2's complement</entry></row><row><entry /><entry /><entry /><entry /><entry>negation of A (−A)</entry></row><row><entry>OP_CMP</entry><entry>Compare</entry><entry>11</entry><entry>A, B</entry><entry>Push − 1 if A less than B, 0 if A</entry></row><row><entry /><entry /><entry /><entry /><entry>equals B, and 1 if A greater</entry></row><row><entry /><entry /><entry /><entry /><entry>than B</entry></row><row><entry>OP_AND</entry><entry>And</entry><entry>12</entry><entry>A, B</entry><entry>Push bit-wise AND of A and B</entry></row><row><entry /><entry /><entry /><entry /><entry>(A & B)</entry></row><row><entry>OP_OR</entry><entry>Or</entry><entry>13</entry><entry>A, B</entry><entry>Push the bit-wise OR of A and</entry></row><row><entry /><entry /><entry /><entry /><entry>B (A | B)</entry></row><row><entry>OP_XOR</entry><entry>Exclusive</entry><entry>14</entry><entry>A, B</entry><entry>Push the bit-wise eXclusive OR</entry></row><row><entry /><entry>Or</entry><entry /><entry /><entry>of A and B (A {circumflex over ( )} B)</entry></row><row><entry>OP_NOT</entry><entry>Logical</entry><entry>15</entry><entry>A</entry><entry>Push the logical negation of A</entry></row><row><entry /><entry>Negate</entry><entry /><entry /><entry>(1 if A is 0, and 0 if A is not 0)</entry></row><row><entry>OP_SHL</entry><entry>Shift Left</entry><entry>16</entry><entry>A, B</entry><entry>Push A logically shifted left by</entry></row><row><entry /><entry /><entry /><entry /><entry>B bits (A << B)</entry></row><row><entry>OP_SHR</entry><entry>Shift Right</entry><entry>17</entry><entry>A, B</entry><entry>Push A logically shifted right</entry></row><row><entry /><entry /><entry /><entry /><entry>by B bits (A >> B)</entry></row><row><entry>OP_JMP</entry><entry>Jump</entry><entry>18</entry><entry>A</entry><entry>Jump to A</entry></row><row><entry>OP_JSR</entry><entry>Jump to</entry><entry>19</entry><entry>A</entry><entry>Jump to subroutine at absolute</entry></row><row><entry /><entry>Subroutine</entry><entry /><entry /><entry>address A. The current value of</entry></row><row><entry /><entry /><entry /><entry /><entry>PC is pushed on the call stack.</entry></row><row><entry>OP_JSRR</entry><entry>Jump to</entry><entry>20</entry><entry>A</entry><entry>Jump to subroutine at PC + A.</entry></row><row><entry /><entry>Subroutine</entry><entry /><entry /><entry>The current value of PC is</entry></row><row><entry /><entry>(Relative)</entry><entry /><entry /><entry>pushed on the call stack.</entry></row><row><entry>OP_RET</entry><entry>Return from</entry><entry>21</entry><entry /><entry>Return from subroutine to the</entry></row><row><entry /><entry>Subroutine</entry><entry /><entry /><entry>return address popped from the</entry></row><row><entry /><entry /><entry /><entry /><entry>call stack.</entry></row><row><entry>OP_BRA</entry><entry>Branch</entry><entry>22</entry><entry>A</entry><entry>Jump to PC + A</entry></row><row><entry /><entry>Always</entry></row><row><entry>OP_BRP</entry><entry>Branch if</entry><entry>23</entry><entry>A, B</entry><entry>Jump to PC + B if A > 0</entry></row><row><entry /><entry>Positive</entry></row><row><entry>OP_BRN</entry><entry>Branch if</entry><entry>24</entry><entry>A, B</entry><entry>Jump to PC + B if A < 0</entry></row><row><entry /><entry>Negative</entry></row><row><entry>OP_BRZ</entry><entry>Branch if</entry><entry>25</entry><entry>A, B</entry><entry>Jump to PC + B if A is 0</entry></row><row><entry /><entry>Zero</entry></row><row><entry>OP_PEEK</entry><entry>Peek</entry><entry>26</entry><entry>A</entry><entry>Push the 32-bit value at address A</entry></row><row><entry>OP_POKE</entry><entry>Poke</entry><entry>27</entry><entry>A, B</entry><entry>Store the 32-bit value A at</entry></row><row><entry /><entry /><entry /><entry /><entry>address B</entry></row><row><entry>OP_PEEKB</entry><entry>Peek Byte</entry><entry>28</entry><entry>A</entry><entry>Read the 8-bit value at address</entry></row><row><entry /><entry /><entry /><entry /><entry>A, 0-extend it to 32-bits and</entry></row><row><entry /><entry /><entry /><entry /><entry>push it on the data stack</entry></row><row><entry>OP_POKEB</entry><entry>Poke Byte</entry><entry>29</entry><entry>A, B</entry><entry>Store the least significant 8 bits</entry></row><row><entry /><entry /><entry /><entry /><entry>of value A at address B</entry></row><row><entry>OP_PUSHSP</entry><entry>Push Stack</entry><entry>30</entry><entry /><entry>Push the value of SP</entry></row><row><entry /><entry>Pointer</entry></row><row><entry>OP_POPSP</entry><entry>Pop Stack</entry><entry>31</entry><entry>A</entry><entry>Set the value of SP to A</entry></row><row><entry /><entry>Pointer</entry></row><row><entry>OP_CALL</entry><entry>System Call</entry><entry>32</entry><entry>A</entry><entry>Perform System Call with</entry></row><row><entry /><entry /><entry /><entry /><entry>index A</entry></row><row><entry>OP_STOP</entry><entry>Stop</entry><entry>255</entry><entry /><entry>Terminate Execution</entry></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

04311.24. Code Modules

0432In a preferred embodiment, code modules are stored in an atom-based format, similar or identical to that used for the MPEG-4 file format, in which atoms contain a 32-bit size (e.g., represented by 4 bytes in big-endian byte order), followed by a 4-byte type (e.g., bytes that correspond to ASCII values of letters of the alphabet), followed by a payload (e.g., 8 bytes).

0433<figref idref="DRAWINGS">FIG. 30</figref> shows the format of an illustrative code module <b>3000</b>. Referring to <figref idref="DRAWINGS">FIG. 30</figref>, pkCM atom <b>3002</b> is the top-level code module atom. It contains a sequence of sub-atoms. In one embodiment, pkCM atom <b>3002</b> contains one pkDS atom <b>3004</b>, one pkCS atom <b>3006</b>, one pkEX atom <b>3008</b>, and possibly one pkRQ atom <b>3010</b>. The pkCM atom <b>3002</b> may also contain any number of other atoms that, in one embodiment, are ignored if present. In one embodiment, the order of the sub-atoms is not specified, so implementations should not assume a specific order.

04341.24.1. pkDS Atom

0435As shown in <figref idref="DRAWINGS">FIG. 30</figref>, pkDS atom <b>3004</b> contains a memory image <b>3005</b> of a data segment that can be loaded into data memory. As shown in <figref idref="DRAWINGS">FIG. 31A</figref>, in one embodiment memory image <b>3005</b> is represented by a sequence of bytes <b>3112</b>, consisting of one header byte <b>3114</b> followed by zero or more data bytes <b>3116</b>. Header byte <b>3114</b> encodes a version number that identifies the format of the bytes that follow <b>3116</b>.

0436In one embodiment, only one version number is defined (i.e., DataSegmentFormatVersion=0), and in this format the data bytes of the memory image represent a raw image to be loaded into memory. The virtual machine loader only loads the data bytes <b>3116</b> of the memory image <b>3105</b>, not including the header byte <b>3114</b>. In one embodiment, the virtual machine loader is operable to refuse to load an image in any other format.

04371.24.2. pkCS Atom

0438As shown in <figref idref="DRAWINGS">FIG. 30</figref>, pkCS atom <b>3006</b> contains a memory image <b>3007</b> of a code segment that can be loaded into code memory. As shown in <figref idref="DRAWINGS">FIG. 31B</figref>, in one embodiment memory image <b>3007</b> is represented by a sequence of bytes <b>3120</b> consisting of one header byte <b>3122</b> followed by zero or more data bytes <b>3124</b>. Header byte <b>3122</b> encodes a version number that identifies the format of the bytes that follow <b>3124</b>.

0439In one embodiment, only one version number is defined (i.e., CodeSegmentFormatVersion=0), and, as shown in <figref idref="DRAWINGS">FIG. 31C</figref>, in this version the byte following header byte <b>3122</b> contains another header byte <b>3130</b> containing a version number that identifies the byte code encoding of the following bytes <b>3132</b>. In the example shown in <figref idref="DRAWINGS">FIG. 31C</figref>, header byte <b>3130</b> identifies ByteCodeVersion=0, which specifies that data bytes <b>3132</b> contain a raw byte sequence with byte code values such as those defined in the example instruction set that is set forth above. In a preferred embodiment, the virtual machine loader only loads the byte code portion <b>3132</b> of the data bytes, not the two header bytes <b>3122</b>, <b>3130</b>.

04401.24.3. pkEX Atom

0441Referring once again to <figref idref="DRAWINGS">FIG. 30</figref>, the pkEX atom <b>3008</b> contains a list of export entries. In the example shown in <figref idref="DRAWINGS">FIG. 30</figref>, the first four bytes <b>3009</b> of pkEX atom <b>3008</b> encode a 32-bit unsigned integer in big-endian byte order equal to the number of entries that follow. As shown in <figref idref="DRAWINGS">FIG. 31D</figref>, each following export entry <b>3160</b> consists of a name, encoded as one byte <b>3162</b> containing the name size, S, followed by S bytes <b>3164</b> containing the ASCII characters of the name, including a terminating zero <b>3166</b>, followed by a 32-bit unsigned integer <b>3168</b> in big-endian byte order representing the byte offset of the named entry point, measured from the start of the byte code data stored in the <b>31</b>CS atom. <figref idref="DRAWINGS">FIG. 31E</figref> shows an example of an export table entry <b>3170</b> for the entry point MAIN at offset 64, in which the first byte <b>3172</b> indicates that the size of the name (i.e., “MAIN”), plus the terminating zero, is five bytes, and in which the last four bytes <b>3174</b> indicate that the byte offset is 64.

04421.24.4. pkRQ Atom

0443As shown in <figref idref="DRAWINGS">FIG. 30</figref>, pkRQ atom <b>3010</b> contains requirements that need to be met by the virtual machine implementation in order to execute the code in the code module. In one embodiment, this atom is optional, and if it is not present, the virtual machine uses default implementation settings, such as may be defined by an implementation profile.

0444In one embodiment, the pkRQ atom consists of an array of 32-bit unsigned integer values, one for each field: <tables id="TABLE-US-00018" num="18"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="70PT" align="left" /><colspec colname="2" colwidth="147PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row><row><entry>Field Name</entry><entry>Description</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>vmVersion</entry><entry>Version ID of the VM Spec</entry></row><row><entry>minDataMemorySize</entry><entry>Minimum size in bytes of the data memory</entry></row><row><entry /><entry>available to the code. This includes the data</entry></row><row><entry /><entry>memory used to load the image of the Data</entry></row><row><entry /><entry>Segment, as well as the data memory used by</entry></row><row><entry /><entry>the Data Stack. In one embodiment, the VM</entry></row><row><entry /><entry>must refuse to load the module if it cannot</entry></row><row><entry /><entry>satisfy this requirement.</entry></row><row><entry>minCallStackDepth</entry><entry>Minimum number of nested subroutine calls</entry></row><row><entry /><entry>(OP_JSR and OP_JSRR) that must be</entry></row><row><entry /><entry>supported by the VM. In one embodiment,</entry></row><row><entry /><entry>the VM must refuse to load the module if it</entry></row><row><entry /><entry>cannot satisfy this requirement.</entry></row><row><entry>Flags</entry><entry>Set of bit-flags to signal required features of</entry></row><row><entry /><entry>the VM.</entry></row><row><entry /><entry>In one embodiment, a VM implementation</entry></row><row><entry /><entry>must refuse to load a code module that has</entry></row><row><entry /><entry>any unknown flag set. For example, if there</entry></row><row><entry /><entry>are no flags defined, in one embodiment a</entry></row><row><entry /><entry>VM implementation must check that this flag</entry></row><row><entry /><entry>is set to 0.</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

04451.24.5. Module Loader

0446The virtual machine is responsible for loading code modules. When a code module is loaded, the Data Segment memory image encoded in the pkDS atom is loaded at a memory address in the Data Memory. That address is chosen by the VM loader, and is stored in the DS pseudo-register when the code executes.

0447The Code Segment memory image encoded in the pkCS atom is loaded at a memory address in the Code Memory. That address is chosen by the VM loader, and is stored in the CS pseudo-register when the code executes.

0448When a code module is loaded, the special routine named “Global.OnLoad” is executed if this routine is found in the entries of the Export table. This routine takes no argument on the stack, and returns an integer status upon return, 0 signifying success, and a negative error code signifying an error condition.

0449When a code module is unloaded (or when the virtual machine that has loaded the module is disposed of), the special routine named “Global.OnUnload” is executed if it is found in the Export table. This routine takes no argument on the stack, and returns an integer status upon return, 0 signifying success, and a negative error code signifying an error condition.

04501.25. System Calls

0451The virtual machine's programs can call functions implemented outside of their code module's Code Segment. This is done through the use of the OP_CALL instruction, which takes an integer stack operand specifying the System Call Number to call. Depending on the System Call, the implementation can be a byte code routine in a different code module (for instance, a library of utility functions), executed directly by the VM in the VM's native implementation format, or delegated to an external software module, such as the VM's host environment.

0452In one embodiment, if an OP_CALL instruction is executed with an operand that contains a number that does not correspond to any System Call, the VM behaves as if the SYS_NOP system call was called.

04531.25.1. System Call Numbers Allocation

0454In the illustrative embodiment under discussion, System Call Numbers 0 to <b>1023</b> are reserved for fixed System Calls (these System Calls will have the same number on all VM implementations). System Call Numbers <b>1024</b> to <b>16383</b> are available for the VM to assign dynamically (for example, the System Call Numbers returned by System.FindSystemCallByName can be allocated dynamically by the VM, and do not have to be the same numbers on all VM implementations).

0455In one example embodiment, the following fixed System Call Numbers are specified: <tables id="TABLE-US-00019" num="19"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="140PT" align="left" /><colspec colname="2" colwidth="28PT" align="center" /><colspec colname="3" colwidth="98PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Mnemonic</entry><entry>Number</entry><entry>System Call</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>SYS_NOP</entry><entry>0</entry><entry>System.NoOperation</entry></row><row><entry>SYS_DEBUG_PRINT</entry><entry>1</entry><entry>System.DebugPrint</entry></row><row><entry>SYS_FIND_SYSTEM_CALL_BY_NAME</entry><entry>2</entry><entry>System.FindSystemCallByName</entry></row><row><entry>SYS_SYSTEM_HOST_GET_OBJECT</entry><entry>3</entry><entry>System.Host.GetObject</entry></row><row><entry>SYS_SYSTEM_HOST_SET_OBJECT</entry><entry>4</entry><entry>System.Host.SetObject</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

04561.25.2. Standard System Calls

0457In one embodiment, a few standard system calls are supported that are useful for writing control programs. These calls include the fixed-number system calls listed in the table above, as well as system calls that have dynamically determined numbers (i.e., their system call number is retrieved by calling the System.FindSystemCallByName system call with their name passed as the argument).

0458In one embodiment, the system calls specified in this section that can return a negative error code may return error codes with any negative value. Section 8.4.4 defines specific, illustrative values. In one embodiment, if negative error code values are returned that are not predefined, they are interpreted as if they were the generic error code value FAILURE.

0459System.NoOperation. This call takes no inputs and returns no outputs, and simply returns without doing anything. It is used primarily for testing the VM.

0460System.DebugPrint. This call takes as its input, from the top of the stack, the address of a memory location containing a null-terminated string, and returns no output. A call to this function causes the string of text to be printed to a debug output, which can be useful in debugging. If the VM implementation does not include a facility to output debug text (such as might be the case in a non-development environment), the VM may ignore the call and treat it as if System.NoOperation had been called.

0461System.FindSystenCallByName. This call finds the number of a system call given its name. The call takes as its input (from the top of the stack) the address of a null-terminated ASCII string containing the name of the system call for which to look, and returns (to the top of the stack) the system call number if a system call with the specified name is implemented, an ERROR_NO_SUCH_ITEM if the system call is not implemented, and a negative error code if an error occurs.

0462System.Host.GetLocalTime. This call takes no inputs, and returns, to the top of the stack, the current value of the local time of the host, which, in one embodiment, is expressed as a 32-bit signed integer equal to the number of minutes elapsed since Jan. 1, 1970 00:00:00, or a negative error code.

0463System.Host.GetLocalTimeOffset. This call takes no inputs, and returns, to the top of the stack, the current time offset (from UTC time) of the host, which, in one embodiment, is expressed as a 32-bit signed integer number equal to the number of minutes difference between local time and UTC time (i.e. LocalTime—UTC).

0464System.Host.GetTrustedTime. This call takes no inputs, and returns, to the top of the stack, the trusted time and the value of one or more flags. In one embodiment, the trusted time is the current value of the trusted time clock (if the system includes such a trusted clock), or a negative error code if the trusted time is not available. In one embodiment, the value of trusted time is expressed as a 32-bit signed integer equal to the number of minutes elapsed since Jan. 1, 1970 00:00:00 UTC, or a negative error code. In one embodiment the flags are the bit-set of flags that further define the current state of the trusted clock. In one embodiment, if an error has occurred (e.g., the value of TrustedTime is a negative error code) the value returned for the flags is 0.

0465In one embodiment, the following flag is defined: <tables id="TABLE-US-00020" num="20"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="35PT" align="center" /><colspec colname="2" colwidth="77PT" align="left" /><colspec colname="3" colwidth="105PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Bit index</entry><entry /><entry /></row><row><entry>(0 is LSB)</entry><entry>Name</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>0</entry><entry>TIME_IS_ESTIMATE</entry><entry>The value of TrustedTime is</entry></row><row><entry /><entry /><entry>known to not be at its most</entry></row><row><entry /><entry /><entry>accurate value, and therefore</entry></row><row><entry /><entry /><entry>should be considered an estimate.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0466This system call is relevant on systems that implement a trusted clock that can be synchronized with a trusted time source and maintain a monotonic time counter. The value of the trusted time is not guaranteed to always be accurate, but in one embodiment the following properties are required to be true: <ul id="ul0012" list-style="none"><li id="ul0012-0001" num="0467"> The value of the trusted time is expressed as a UTC time value (the trusted time is not in the local time zone, as the current locality usually cannot be securely determined). </li><li id="ul0012-0002" num="0468"> The trusted time never goes back. </li><li id="ul0012-0003" num="0469"> The trusted clock does not advance faster than realtime. </li></ul>

0470Therefore, in this example embodiment, the value of TrustedTime is between the value of the last synchronized time (synchronized with a trusted time source) and the current real time. If the system is able to determine that its trusted clock has been operating and updating continuously and normally without interruption since the last synchronization with a trusted time source, it can determine that the value of TrustedTime is not an estimate, but an accurate value, and set the TIME_IS_ESTIMATE flag to 0.

0471In one embodiment, if the trusted clock detects that a hardware or software failure condition has occurred, and it is unable to return even an estimate of the trusted time, an error code is returned, and the value of the returned flags is set to 0.

0472System.Host.GetObject: This system call is a generic interface that allows a program to access objects provided by the virtual machine's host. The System.Host.GetObject call takes the following inputs (listed from the top of the stack downwards): Parent, Name, ReturnBuffer, and ReturnBuffer Size. Where “Parent” is the 32-bit handle of the parent container; “Name” is the address of a null-terminated string containing the path to the requested object, relative to the parent container; “ReturnBuffer” is the address of a memory buffer where the value of the object is to be stored; and “RetumBufferSize” is a 32-bit integer indicating the size in bytes of the memory buffer in which the value of the object is to be stored.

0473The System.Host.GetObject call produces the following outputs (listed from the top of the stack downwards): TypeID, Size. Where “TypeId” is the object type id, or a negative error code if the call failed. If the requested object does not exist, the error returned is ERROR_NO_SUCH_ITEM. If the buffer supplied for the return value is too small, the error returned is ERROR_INSUFFICIENT_SPACE. If the part of the object tree that is being accessed is access-controlled, and the calling program does not have the permission to access the object, ERROR_PERMISSION_DENIED is returned. Other error codes may be returned. “Size” is a 32-bit integer indicating the size in bytes of the data returned in the buffer supplied by the caller, or the size required if the caller provided a buffer that was too small.

0474In one embodiment, there are four types of host objects: strings, integers, byte arrays, and containers. <tables id="TABLE-US-00021" num="21"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="49PT" align="left" /><colspec colname="2" colwidth="112PT" align="left" /><colspec colname="3" colwidth="56PT" align="center" /><thead><row><entry /></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Object Type</entry><entry>Type Id Name</entry><entry>Type Id Value</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Container</entry><entry>OBJECT_TYPE_CONTAINER</entry><entry>0</entry></row><row><entry>Integer</entry><entry>OBJECT_TYPE_INTEGER</entry><entry>1</entry></row><row><entry>String</entry><entry>OBJECT_TYPE_STRING</entry><entry>2</entry></row><row><entry>Byte Array</entry><entry>OBJECT_TYPE_BYTE_ARRAY</entry><entry>3</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0475In one embodiment, the value of a byte array object is an array of 8-bit bytes, the value of a string object is a null-terminated character string incoded in UTF-8, and the value of an integer object is a 32-bit signed integer value. Containers are generic containers that contain a sequence of any number of objects of any combination of types. Objects contained in a container are called the children of that container. The value of a container is a 32-bit container handle that is unique within a given VM instance. In one embodiment, the root container ‘/’ has the fixed handle value 0.

0476In one embodiment, the namespace for host objects is hierarchical, where the name of a container's child object is constructed by appending the name of the child to the name of the parent container, separated by a ‘/’ character. String and integer objects do not have children. For example, if a container is named ‘/Node/Attributes’, and has a string child named ‘Type’, then ‘/Node/Attributes/Type’ refers to the child string.

0477The root of the namespace is ‘/’. All absolute names start with a ‘/’. Names that do not start with a ‘/’ are relative names. Relative names are relative to a parent container. For example, the name ‘Attributes/Type’, relative to parent ‘/Node’, is the object with the absolute name ‘/Node/Attributes/Type’.

0478In one embodiment, container objects can also have real and virtual child objects that be accessed by using virtual names. Virtual names are names that are not attached to host objects, but a convention to identify either unnamed child objects, child objects with a different name, or virtual child objects (child objects that are not real children of the container, but created dynamically when requested).

0479In one embodiment, for objects, the following virtual names are defined as virtual child object names: <tables id="TABLE-US-00022" num="22"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="63PT" align="left" /><colspec colname="2" colwidth="154PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row><row><entry>Virtual Name</entry><entry>Description</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>@Name</entry><entry>Virtual string object: the name of the object.</entry></row><row><entry /><entry>If the object is unnamed, the value is an empty</entry></row><row><entry /><entry>string. Note that unnamed objects are only</entry></row><row><entry /><entry>accessible through the @<n> virtual name of a</entry></row><row><entry /><entry>container object (see below)</entry></row><row><entry>@Size</entry><entry>Virtual integer object. The integer value is equal</entry></row><row><entry /><entry>to the size in bytes required to store this object.</entry></row><row><entry /><entry>For integers, this value is 4; for strings, it is the</entry></row><row><entry /><entry>number of bytes needed to store the UTF-8</entry></row><row><entry /><entry>string plus a null byte terminator. For byte</entry></row><row><entry /><entry>arrays, this is the number of bytes in the array.</entry></row><row><entry>@Type</entry><entry>Virtual integer object. The integer value is equal</entry></row><row><entry /><entry>to the object's Type Id.</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0480For containers, the following virtual names are defined as virtual child object names in one embodiment: <tables id="TABLE-US-00023" num="23"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="28PT" align="left" /><colspec colname="1" colwidth="49PT" align="left" /><colspec colname="2" colwidth="140PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row><row><entry /><entry>Virtual Name</entry><entry>Description</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="28PT" align="left" /><colspec colname="2" colwidth="49PT" align="left" /><colspec colname="3" colwidth="140PT" align="left" /><tbody valign="top"><row><entry>Virtual</entry><entry>@<n></entry><entry>Virtual object: the <n>th object in a container.</entry></row><row><entry>Index</entry><entry /><entry>The first object in a container has index 0. <n></entry></row><row><entry /><entry /><entry>is expressed as a decimal number.</entry></row><row><entry /><entry /><entry>Example: if ‘Attributes’ is a container that</entry></row><row><entry /><entry /><entry>contains 5 child objects, ‘Attributes/@4’ is the</entry></row><row><entry /><entry /><entry>5^thchild of the container.</entry></row><row><entry>Virtual</entry><entry>@Size</entry><entry>Virtual integer object. The integer value is</entry></row><row><entry>Size</entry><entry /><entry>equal to the number of objects in the container.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0481Example

0482The following table shows an example of a hierarchy of Host Objects: <tables id="TABLE-US-00024" num="24"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="7"><colspec colname="1" colwidth="28PT" align="left" /><colspec colname="2" colwidth="28PT" align="left" /><colspec colname="3" colwidth="42PT" align="left" /><colspec colname="4" colwidth="42PT" align="left" /><colspec colname="5" colwidth="35PT" align="left" /><colspec colname="6" colwidth="42PT" align="left" /><colspec colname="7" colwidth="42PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="7" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Name</entry><entry>Value</entry><entry>Children</entry></row><row><entry namest="1" nameend="7" align="center" rowsep="1" /></row><row><entry>Node</entry><entry>1</entry><entry>Name</entry><entry>Value</entry><entry>Children</entry></row><row><entry /><entry /><entry>Type</entry><entry>“Device”</entry></row><row><entry /><entry /><entry>Name</entry><entry>Value</entry><entry>Children</entry></row><row><entry /><entry /><entry>Attributes</entry><entry>2</entry><entry>Name</entry><entry>Value</entry><entry>Children</entry></row><row><entry /><entry /><entry /><entry /><entry>Color</entry><entry>“Red”</entry></row><row><entry /><entry /><entry /><entry /><entry>Size</entry><entry>78</entry></row><row><entry /><entry /><entry /><entry /><entry>Domain</entry><entry>“TopLevel”</entry></row><row><entry namest="1" nameend="7" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0483In this example, calling System.Host.GetObject(parent=0, name=“Node”) returns a type ID of 0 (i.e., container), and causes the handle value of 1 to be written in the buffer supplied by the caller. The size of the value is 4 bytes.

0484Calling System.Host.GetObject(parent=0, name=“Node/Attributes/Domain”) returns a type ID of 2 (i.e., string), and causes the string “TopLevel” to be written in the buffer supplied by the caller. The size of the value is 9 bytes.

0485Calling System.Host.GetObject(parent=1, name=“Attributes/@ 1”) returns a type ID of 1 (i.e., integer), and causes the integer <b>78</b> to be written in the buffer supplied by the called. The size of the value is 4 bytes.

0486Calling System.Host.GetObject(parent=0, name=“DoesNotExist”) returns the error code ERROR_NO_SUCH_ITEM.

0487System.Host.SetObject. This system call is a generic interface that allows a program to create, write, and destroy objects provided by the virtual machine's host. The description of the object names and types is the same as for the System.Host.GetObject call described above. Not all host objects support being written to or destroyed, and not all containers support having child objects created. When a SetObject call is made for an object that does not support the operation, ERROR_PERMISSION_DENIED is returned.

0488The System.Host.SetObject system call takes as input the following parameters,listed from the top of the stack downwards: <tables id="TABLE-US-00025" num="25"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><thead><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Top of stack</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="84PT" align="left" /><colspec colname="1" colwidth="133PT" align="left" /><tbody valign="top"><row><entry /><entry>Parent</entry></row><row><entry /><entry>Name</entry></row><row><entry /><entry>ObjectAddress</entry></row><row><entry /><entry>ObjectType</entry></row><row><entry /><entry>ObjectSize</entry></row><row><entry /><entry>...</entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0489Parent: 32-bit handle of the parent container.

0490Name: address of a null-terminated string containing the path to the object, relative to the parent container.

0491ObjectAddress: address of a memory buffer where the value of the object is stored. If the address is 0, the call is interpreted as a request to destroy the object. The data at the address depends on the type of the object.

0492ObjectType: the type ID of the object.

0493ObjectSize: 32-bit integer indicating size in bytes of the memory buffer where the value of the object is stored. In the illustrative embodiment under discussion, the size is set to 4 for integer objects, and to the size of the memory buffer, including the null terminator, for string objects. For byte array objects, the size is the number of bytes in the array.

0494The System.Host.SetObject system call returns a ResultCode to the top of the stack as an output. The ResultCode is 0 if the call succeeded, and a negative error code if the call failed. If the call is a request to destroy an object and the requested object does not exist, or the call is a request to create or write an object and the object's parent does not exist, the error code returned is ERROR_NO_SUCH_ITEM. If the part of the object tree that is being accessed is access-controlled, and the calling program does not have the permission to access the object, ERROR_PERMISSION_DENIED is returned. Other error codes may also be returned.

0495There is a special case when the object refers to a container and the ObjectAddress is not 0. In this case the ObjectSize parameter is set to 0 and the value of ObjectAddress is ignored. If the container already exists, nothing is done, and a SUCCESS ResultCode is returned. If the container does not exist, and the parent of the container is writeable, an empty container is created.

0496Octopus.Links.IsNodeReachable. This system call is used by control programs to check whether a given node is reachable from the node associated with the entity hosting this instance of the virtual machine. The call takes as its input a NodeId from the top of the stack, where the Nodeld is a null-terminated string containing the ID of the target node to be tested for reachability. As output, the call returns a ResultCode and a StatusBlockPointer to the top of the stack. The ResultCode is an integer value that is 0 if the node is reachable, or a negative error code if it is not. The StatusBlockPointer is the address of a standard ExtendedStatusBlock, or 0 if no status block is returned.

0497System.Host.SpawnVm. This system call is used by control programs to request that a new instance of a virtual machine be created, and a new code module loaded. In one embodiment, the host of the newly created virtual machine exposes the same host objects as the ones exposed to the caller, except the host object “/Octopus/Runtime/Parent/Id” is set to the identity of the caller. In one embodiment, this host object is a container. The children of this container are objects of type string, each with a value representing a name. In one embodiment, the semantics and specific details of those names are specified by the specification of the virtual mchine's host.

0498In one embodiment, when the virtual machine that is running the code for the caller terminates, any spawned virtual machine that has not been explicitly released by calling System.Host.ReleaseVm is automatically released by the system as if System.Host.ReleaseVm had been called.

0499The System.Host.SpawnVm call takes as its input a ModuleId from the top of the stack. The ModuleId identifies the code module to be loaded into the new virtual machine instance. In one embodiment, the specification of the virtual machine's host describes the mechanism by which the actual code module corresponding to this module ID is to be located.

0500The System.Host.SpawnVm call returns a ResultCode and a VmHandle to the top of the stack. The ResultCode is an integer value that is 0 if the call was successful, and a negative error code if it failed. The VmHandle is an integer value identifying the instance of the virtual machine that has been created. If the call fails, this handle is set to 0. In one embodiment, this handle is only guaranteed to be unique within the virtual machine in which this call is made.

0501System.Host.CallVm. This system call is used by control programs to call routines that are implemented in code modules loaded in virtual machine instances created using the System.Host.SpawnVm system call. This system call takes the following input from the top of the stack:

0502Top of Stack <tables id="TABLE-US-00026" num="26"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="70PT" align="left" /><colspec colname="1" colwidth="147PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>VmHandle</entry></row><row><entry /><entry>EntryPoint</entry></row><row><entry /><entry>ParameterBlockAddress</entry></row><row><entry /><entry>ParameterBlockSize</entry></row><row><entry /><entry>ReturnBufferAddress</entry></row><row><entry /><entry>ReturnBufferSize</entry></row><row><entry /><entry>...</entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0503VmHandle: an integer value representing the handle of a virtual machine that was created by calling System.Host.SpawnVm.

0504EntryPoint: the address of a null-terminated string that specifies the name of the entry point to call. This name needs to match one of the entry points in the Export Table of the code module that was loaded into the virtual machine instance that corresponds to the VmHandle parameter.

0505ParameterBlockAddress: the address of a memory block that contains data to be passed to the callee. If no parameters are passed to the callee, this address is set to 0.

0506ParameterBlockSize: the size in bytes of the memory block at address ParameterBlockAddress, or 0 if ParameterBlockAddress is 0.

0507ReturnBufferAddress: the address of a memory buffer where the caller can receive data from the callee. If the caller does not expect any data back from the callee, this address is set to 0.

0508ReturnBufferSize: the size in bytes of the memory buffer at address ReturnBufferAddress, or 0 if ReturnBufferAddress is 0.

0509The System.Host.CallVm call returns the following output to the top of the stack:

0510Top of Stack <tables id="TABLE-US-00027" num="27"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="77PT" align="left" /><colspec colname="1" colwidth="140PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>SystemResultCode</entry></row><row><entry /><entry>CalleeResultCode</entry></row><row><entry /><entry>ReturnBlockSize</entry></row><row><entry /><entry>...</entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0511SystemResultCode: an integer value that is 0 if the call was successful or a negative error code if it failed. This value is determined by the system, not by the callee. Success only indicates that the system was able to successfully find the routine to call, execute the routine, and get the return value from the routine. The return value from the routine itself is returned in the CalleeResultCode value.

0512CalleeResultCode: an integer value that is returned by the callee.

0513ReturnBlockSize: the size in bytes of the data returned in the buffer supplied by the caller, or the size required if the caller provided a buffer that was too small. If no data was returned by the callee, the value is 0.

0514In the illustrative embodiment under discussion, the called routine complies with the following interface conventions: When the routine is called, the top of the stack contains the value ParameterBlockSize, supplied by the caller, indicating the size of the parameter block, followed by ParameterBlockSize bytes of data. If the size is not a multiple of 4, the data on the stack will be padded with zeros to ensure that the stack pointer remains a multiple of 4. Upon return, the called routine provides the following return values on the stack:

0515Top of Stack <tables id="TABLE-US-00028" num="28"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="77PT" align="left" /><colspec colname="1" colwidth="140PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>ResultCode</entry></row><row><entry /><entry>ReturnBlockAddress</entry></row><row><entry /><entry>ReturnBlockSize</entry></row><row><entry /><entry>...</entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0516ReturnBlockAddress: the address of a memory block that contains data to be returned to the caller. If no data is returned, this address is set to 0.

0517ReturnBlockSize: size in bytes of the memory block at address ReturnBlockAddress, or 0 if ReturnBlockAddress is 0.

0518System.Host.ReleaseVm. This system call is used by control programs to release a virtual machine that was spawned by a previous call to System.Host.SpawnVm. Any virtual machines spawned by the released virtual machine are released, and so on, recursively. The System.Host.ReleaseVm call takes as its input a VmHandle from the top of the stack, the VmHandle representing the handle of a virtual machine that was created by calling System.Host.SpawnVm. The System.Host.ReleaseVm call returns a ResultCode to the top of the stack as an output. The ResultCode is an integer value that is 0 if the call was successful or a negative error code if it failed.

05191.25.3. Standard Data Structures

0520The following are standard data structures used by some of the standard system calls.

05211.25.3.1. Standard Parameters

0522ParameterBlock: <tables id="TABLE-US-00029" num="29"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="49PT" align="left" /><colspec colname="1" colwidth="70PT" align="left" /><colspec colname="2" colwidth="98PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row><row><entry /><entry>Name</entry><entry>Type</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Name</entry><entry>NameBlock</entry></row><row><entry /><entry>Value</entry><entry>ValueBlock</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0523Name: name of the parameter.

0524Value: value of the parameter

0525ExtendedParameterBlock: <tables id="TABLE-US-00030" num="30"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="42PT" align="left" /><colspec colname="1" colwidth="77PT" align="left" /><colspec colname="2" colwidth="98PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row><row><entry /><entry>Name</entry><entry>Type</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Flags</entry><entry>32-bit bit field</entry></row><row><entry /><entry>Parameter</entry><entry>ParameterBlock</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0526Flags: vector of boolean flags.

0527Parameter: parameter block containing a name and a value.

0528NameBlock: <tables id="TABLE-US-00031" num="31"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="35PT" align="left" /><colspec colname="1" colwidth="70PT" align="left" /><colspec colname="2" colwidth="112PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row><row><entry /><entry>Name</entry><entry>Type</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Size</entry><entry>32-bit integer</entry></row><row><entry /><entry>Characters</entry><entry>Array of 8-bit characters</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0529Size: 32-bit unsigned integer equal to the size in bytes of the “characters” field that follows. If this value is 0, the characters field is left empty (i.e., nothing follows).

0530Characters: Null-terminated UTF-8 string.

0531ValueBlock: <tables id="TABLE-US-00032" num="32"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="42PT" align="left" /><colspec colname="1" colwidth="63PT" align="left" /><colspec colname="2" colwidth="112PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row><row><entry /><entry>Name</entry><entry>Type</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Type</entry><entry>32-bit integer</entry></row><row><entry /><entry>Size</entry><entry>32-bit integer</entry></row><row><entry /><entry>Data</entry><entry>Array of 8-bit bytes</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0532Type: 32-bit type identifier. In one embodiment, the following types are defined: <tables id="TABLE-US-00033" num="33"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="49PT" align="center" /><colspec colname="2" colwidth="70PT" align="left" /><colspec colname="3" colwidth="98PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Identifier</entry><entry>Type Name</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>0</entry><entry>Integer</entry><entry>32-bit integer value,</entry></row><row><entry /><entry /><entry>encoded as four 8-bit bytes</entry></row><row><entry /><entry /><entry>in big-endian byte order. In</entry></row><row><entry /><entry /><entry>one embodiment the value</entry></row><row><entry /><entry /><entry>is considered signed unless</entry></row><row><entry /><entry /><entry>otherwise specified.</entry></row><row><entry>1</entry><entry>Real</entry><entry>32-bit floating point value,</entry></row><row><entry /><entry /><entry>encoded as IEEE-754 in</entry></row><row><entry /><entry /><entry>big-endian byte order</entry></row><row><entry>2</entry><entry>String</entry><entry>Null-terminated UTF-8</entry></row><row><entry /><entry /><entry>string</entry></row><row><entry>3</entry><entry>Date</entry><entry>32-bit unsigned integer</entry></row><row><entry /><entry /><entry>value, representing the</entry></row><row><entry /><entry /><entry>number of minutes elapsed</entry></row><row><entry /><entry /><entry>since January 1, 1970</entry></row><row><entry /><entry /><entry>00:00:00. In one</entry></row><row><entry /><entry /><entry>embodiment, unless</entry></row><row><entry /><entry /><entry>otherwise specified, the</entry></row><row><entry /><entry /><entry>value is considered to be a</entry></row><row><entry /><entry /><entry>UTC date, the most</entry></row><row><entry /><entry /><entry>significant bit of which</entry></row><row><entry /><entry /><entry>must be 0.</entry></row><row><entry>4</entry><entry>Parameter</entry><entry>ParameterBlock structure</entry></row><row><entry>5</entry><entry>ExtendedParameter</entry><entry>ExtendedParameterBlock</entry></row><row><entry /><entry /><entry>structure</entry></row><row><entry>6</entry><entry>Resource</entry><entry>The value is a resource. The</entry></row><row><entry /><entry /><entry>resource here is referenced</entry></row><row><entry /><entry /><entry>by ID: the Data field of the</entry></row><row><entry /><entry /><entry>value is a null-terminated</entry></row><row><entry /><entry /><entry>ASCII string containing the</entry></row><row><entry /><entry /><entry>ID of the resource that</entry></row><row><entry /><entry /><entry>should be de-referenced to</entry></row><row><entry /><entry /><entry>produce the actual data.</entry></row><row><entry>7</entry><entry>ValueList</entry><entry>An array of values (encoded</entry></row><row><entry /><entry /><entry>as a ValueListBlock)</entry></row><row><entry>8</entry><entry>ByteArray</entry><entry>The value is an array of 8-</entry></row><row><entry /><entry /><entry>bit bytes</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0533Size: 32-bit unsigned integer equal to the size in bytes of the “data” field that follows. If this value is 0, the data field is left empty (i.e., nothing follows the size field in the ValueBlock).

0534Data: array of 8-bit bytes representing a value. The actual bytes depend on the data encoding specified by the type field.

0535ValueListBlock: <tables id="TABLE-US-00034" num="34"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="42PT" align="left" /><colspec colname="1" colwidth="84PT" align="left" /><colspec colname="2" colwidth="91PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row><row><entry /><entry>Name</entry><entry>Type</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>ValueCount</entry><entry>32-bit integer</entry></row><row><entry /><entry>Value0</entry><entry>ValueBlock</entry></row><row><entry /><entry>Value1</entry><entry>ValueBlock</entry></row><row><entry /><entry>. . .</entry><entry>. . .</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0536ValueCount: 32-bit unsigned integer equal to the number of ValueBlock structures that follow. If this value is 0, no ValueBlocks follow.

0537Value<b>0</b>, Value<b>1</b>, . . . : sequence of zero or more ValueBlock structures.

05381.25.3.2. Standard ExtendedStatus

0539The standard ExtendedStatusBlock is a data structure typically used to convey extended information as a return status from a call to a routine or a system call. It is a generic data structure that can be used in a variety of contexts, with a range of different possible values for its fields. In one embodiment, an ExtendedStatusBlock is defined as follows:

0540ExtendedStatusBlock: <tables id="TABLE-US-00035" num="35"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="35PT" align="left" /><colspec colname="1" colwidth="77PT" align="left" /><colspec colname="2" colwidth="105PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row><row><entry /><entry>Name</entry><entry>Type</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>GlobalFlags</entry><entry>32-bit bit field</entry></row><row><entry /><entry>Category</entry><entry>32-bit integer</entry></row><row><entry /><entry>SubCategory</entry><entry>32-bit integer</entry></row><row><entry /><entry>LocalFlags</entry><entry>32-bit bit field</entry></row><row><entry /><entry>CacheDuration</entry><entry>CacheDurationBlock</entry></row><row><entry /><entry>Parameters</entry><entry>ValueListBlock</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0541GlobalFlags: boolean flags whose semantics are the same regardless of the category field. The position and meaning of the flags are defined by profiles that use standard ExtendedStatusBlock data structures.

0542Category: Unique integer identifier of a category to which this status belongs. The category identifier values are defined by profiles that use standard ExtendedStatusBlock data structures.

0543SubCategory: Integer identifier (unique within the category) of a sub-category that further classifies the type of status described by this block.

0544LocalFlags: Boolean flags whose semantics are local to the category and subcategory of this status block. The position and meaning of the flags are defined by profiles that define and use the semantics of the category.

0545CacheDuration: Indicates the duration for which this status can be cached (i.e remains valid). See the definition of the CacheDurationBlock type, below, for how the actual value of the duration is defined.

0546Parameters: List of zero or more ValueBlocks. Each ValueBlock contains a parameter encoded as a value of type Parameter or ExtendedParameter. Each parameter binds a name to a typed value, and is used to encode flexible variable data that describes the status block in more detail than just the category, sub-category, cache duration, and flags.

0547CacheDurationBlock: <tables id="TABLE-US-00036" num="36"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="49PT" align="left" /><colspec colname="1" colwidth="70PT" align="left" /><colspec colname="2" colwidth="98PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row><row><entry /><entry>Name</entry><entry>Type</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Type</entry><entry>32-bit integer</entry></row><row><entry /><entry>Value</entry><entry>32-bit integer</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0548Type: Integer identifier for the type of the value. In one embodiment, the following types are defined: <tables id="TABLE-US-00037" num="37"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="21PT" align="left" /><colspec colname="1" colwidth="42PT" align="left" /><colspec colname="2" colwidth="154PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row><row><entry /><entry>Type</entry><entry>Description</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>0</entry><entry>The value is a 32-bit unsigned integer that</entry></row><row><entry /><entry /><entry>represents the number of seconds from the</entry></row><row><entry /><entry /><entry>current time. A value of 0 means that the</entry></row><row><entry /><entry /><entry>status cannot be cached at all, and therefore</entry></row><row><entry /><entry /><entry>can only be used once. The special value</entry></row><row><entry /><entry /><entry>0xFFFFFFFF is interpreted as an infinite</entry></row><row><entry /><entry /><entry>duration (i.e., the status can be cached</entry></row><row><entry /><entry /><entry>indefinitely).</entry></row><row><entry /><entry>1</entry><entry>The value is a 32-bit unsigned integer that</entry></row><row><entry /><entry /><entry>represents an absolute local time, expressed</entry></row><row><entry /><entry /><entry>as the number of minutes elapsed since</entry></row><row><entry /><entry /><entry>Jan. 1, 1970 00:00:00. In one</entry></row><row><entry /><entry /><entry>embodiment, the most significant bit must be</entry></row><row><entry /><entry /><entry>0.</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0549Value: 32-bit integer, the meaning of which depends on the Type field.

05501.25.4. Standard Result Codes

0551Standard result codes are used in various APIs. Other result codes may be defined for use in more specific APIs. <tables id="TABLE-US-00038" num="38"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="28PT" align="center" /><colspec colname="2" colwidth="112PT" align="left" /><colspec colname="3" colwidth="77PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Value</entry><entry>Name</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="28PT" align="char" char="." /><colspec colname="2" colwidth="112PT" align="left" /><colspec colname="3" colwidth="77PT" align="left" /><tbody valign="top"><row><entry>0</entry><entry>SUCCESS</entry><entry>Success</entry></row><row><entry>−1</entry><entry>FAILURE</entry><entry>Unspecified failure</entry></row><row><entry>−2</entry><entry>ERROR_INTERNAL</entry><entry>An internal</entry></row><row><entry /><entry /><entry>(implementation) error</entry></row><row><entry /><entry /><entry>has occurred</entry></row><row><entry>−3</entry><entry>ERROR_INVALID_PARAMETER</entry><entry>A parameter has an</entry></row><row><entry /><entry /><entry>invalid value</entry></row><row><entry>−4</entry><entry>ERROR_OUT_OF_MEMORY</entry><entry>Not enough memory</entry></row><row><entry /><entry /><entry>available to complete</entry></row><row><entry /><entry /><entry>successfully</entry></row><row><entry>−5</entry><entry>ERROR_OUT_OF_RESOURCES</entry><entry>Not enough resources</entry></row><row><entry /><entry /><entry>available to complete</entry></row><row><entry /><entry /><entry>successfully</entry></row><row><entry>−6</entry><entry>ERROR_NO_SUCH_ITEM</entry><entry>The requested item</entry></row><row><entry /><entry /><entry>does not exist or was</entry></row><row><entry /><entry /><entry>not found</entry></row><row><entry>−7</entry><entry>ERROR_INSUFFICIENT_SPACE</entry><entry>Not enough memory</entry></row><row><entry /><entry /><entry>supplied by the caller</entry></row><row><entry /><entry /><entry>(typically used when a</entry></row><row><entry /><entry /><entry>return buffer is too</entry></row><row><entry /><entry /><entry>small)</entry></row><row><entry>−8</entry><entry>ERROR_PERMISSION_DENIED</entry><entry>Permission to perform</entry></row><row><entry /><entry /><entry>the call is denied to the</entry></row><row><entry /><entry /><entry>caller.</entry></row><row><entry>−9</entry><entry>ERROR_RUNTIME_EXCEPTION</entry><entry>An error has occurred</entry></row><row><entry /><entry /><entry>during execution of</entry></row><row><entry /><entry /><entry>byte code</entry></row><row><entry>−10</entry><entry>ERROR_INVALID_FORMAT</entry><entry>Error caused by data</entry></row><row><entry /><entry /><entry>with an invalid format</entry></row><row><entry /><entry /><entry>(for example, invalid</entry></row><row><entry /><entry /><entry>data in a code module)</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

05521.26. Assembler Syntax

0553This section describes an example syntax for use in compiling programs into the bytecode format described elsewhere herein. It should be appreciated that this is just one example of one possible syntax, and that any suitable syntax could be used. As previously indicated, it should also be understood that the bytecode format presented herein is also just an example, and the systems and methods described herein could be used with any other suitable byte code format or other code format.

0554An assembler reads source files containing code, data, and processing instructions, and produces binary code modules that can be loaded by a control virtual machine. In one illustrative embodiment, the assembler processes a source file sequentially line by line. Lines can be zero or more characters, followed by a newline. Each line can be one of: an empty line (whitespace only), a segment directive, a data directive, an assembler directive, a code instruction, a label, or an export directive. In addition, each line can end with a comment, which starts with a ‘;’ character and continues until the end of the line.

0555Data and instructions read from the source files have an implicit destination segment (i.e., where they end up when loaded by the VM). At any point during the parsing process, the assembler will have a “current” segment which is the implicit destination segment for data and instructions. The current segment can be changed using segment directives.

05561.26.1. Segment Directives

0557Segment directives change the current segment of the parser. In one embodiment, the supported segment directives are .code and .data. The .code segment holds the byte code instructions, and the .data segment holds global variables.

05581.26.2. Data Directives

0559Data directives specify data (e.g., integers and strings) that will be loaded in the virtual machine's data segment. In one embodiment, the supported data directives are: <ul id="ul0013" list-style="none"><li id="ul0013-0001" num="0560"> . string “<some chars>”—Specifies a string of characters. In one embodiment, the assembler adds an octet with value 0 at the end of the string. </li><li id="ul0013-0002" num="0561"> .byte <value>—Specifies an 8-bit Value. <value> can be expressed as a decimal number, or a hexadecimal number (prefixed by 0x). </li><li id="ul0013-0003" num="0562"> .long <value>—Specifies a 32-bit value. <value> can be expressed as a decimal number, or a hexadecimal number (prefixed by 0x). </li></ul>

05631.26.3. Assembler Directives

0564In one embodiment, the supported assembler directives are .equ <symbol>, <value>, which sets the symbol <symbol> to be equal to the value <value>. Symbols are typically used as operands or code instructions.

05651.26.4. Labels

0566Labels are symbols that point to locations within segments. Labels pointing to instructions in the code segment are typically used for jump/branch instructions. Labels pointing to data in the data segment are typically used to refer to variables. In one embodiment, the syntax for a label is: <LABEL>:

0567Note that there is nothing after the “:”, except an optional comment. A label points to the location of the next data or instruction. In one embodiment, it is ok to have more than one label pointing to the same address.

05681.26.5. Export Directives

0569Export directives are used to create entries in the “export” section of the code module produced by the assembler. Each entry in the export section is a (name, address) pair. In the illustrative embodiment under discussion, only addresses within the code segment can be specified in the export section.

0570The syntax of the export directive is: export <label>, which will export the address pointed to by <label>, with the name “<label>”.

05711.26.6. Code Instructions

0572When compiling data destined for the code segment, the assembler reads instructions that map directly, or indirectly, into byte codes. In the example instruction set shown above, most virtual machine byte codes have no direct operands, and appear with a simple mnemonic on a single line. To make the assembler syntax more readable, some instructions accept pseudo-operands, which look as if they were byte code operands, but are not really; in this case, the assembler generates one or more byte code instructions to produce the same effect as if the instruction did have a direct operand. For example, the branch instructions use pseudo-operands.

05731.26.6.1. Branch Operands

0574Branch instructions can be specified verbatim (without any operand), or with an optional operand that will be converted by the assembler into a corresponding byte code sequence. The optional operand is an integer constant or a symbol. When the operand is a symbol, the assembler computes the correct integer relative offset so that the branch ends up at the address corresponding to the symbol.

05751.26.6.2. Push Operands

0576In one embodiment, the PUSH instruction always takes one operand. The operand can be one of an integer constant, a symbol, or the prefix “@” directly followed by a label name. When the operand is a symbol, the value that is pushed is the direct value of that symbol, whether the symbol is a label or an .equ symbol (the value is not incremented by a segment offset). When the operand is a label name prefixed with “@”, the value pushed depends on what the label points to. The value pushed on the stack is the absolute address represented by the label (i.e., the local label value added to the segment offset).

05771.26.7. Examples <tables id="TABLE-US-00039" num="39"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>; constants</entry></row><row><entry>  .equ SOMECONST, 7</entry></row><row><entry>; what follows goes into the data segment</entry></row><row><entry>  .data</entry></row><row><entry>VAR1:</entry></row><row><entry>  .byte 8</entry></row><row><entry>VAR2:</entry></row><row><entry>  .string “hello\0”</entry></row><row><entry>VAR3:</entry></row><row><entry>  .long 0xFFFCDA07</entry></row><row><entry>VAR4:</entry></row><row><entry>  .long 0</entry></row><row><entry>; what follows goes into the code segment</entry></row><row><entry>  .code</entry></row><row><entry>FOO:</entry></row><row><entry>  PUSH 1</entry></row><row><entry>  ADD</entry></row><row><entry>  RET</entry></row><row><entry>BAR:</entry></row><row><entry>  PUSH 2</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="84PT" align="left" /><colspec colname="2" colwidth="133PT" align="left" /><tbody valign="top"><row><entry>  PUSH @FOO</entry><entry>; push the address of the label FOO</entry></row><row><entry>  JSR</entry><entry>; jump to the code at label FOO</entry></row><row><entry>  PUSH SOMECONST</entry><entry>; push the value 7</entry></row><row><entry>  PUSH @VAR1</entry><entry>; push the addr of VAR1</entry></row><row><entry>  PUSH VAR1</entry><entry>; push the offset of VAR1 within the data</entry></row><row><entry /><entry>  segment</entry></row><row><entry>  PUSH @VAR3</entry><entry>; push the addr of VAR3</entry></row><row><entry>  PEEK</entry><entry>; push the value of VAR3</entry></row><row><entry>  PUSH @VAR4</entry><entry>; push the addr of VAR4</entry></row><row><entry>  POKE</entry><entry>; store the value on top of the stack into</entry></row><row><entry /><entry>  VAR4</entry></row><row><entry>  PUSH @VAR2</entry><entry>; push the addr of the string “hello”</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

05781.26.8. Command Line Syntax

0579In one embodiment, the assembler is a command-line tool that can be invoked with the following syntax: “PktAssembler [options] <input_file_path> <output_file_path>”, where the [options] can be: -cs int, -ds int, -xml id, or -h, where “-cs int” is a Code Segment Address Value (default=8), “-ds int” is a Data Segment Address Value (default=4), “-xml id” is used to output a control object as an XML file with the specified ID, and “-h” is used to display help information.

00009. Controls

0580This section describes illustrative embodiments of control objects. Control objects can be used to represent rules that govern access to content by granting or denying the use of the ContentKey objects they control. They can also be used to represent constraints on the validity of a link object in which they are embedded. They can also be used as standalone program containers that are run on behalf of another entity, such as in agents or delegates. In one embodiment, controls contain metadata and byte-code programs, which implement a specific interaction protocol. The purpose of a Control Protocol is to specify the interaction between the DRM engine and a control program or between a host application and a control program through the DRM engine. This section also describes illustrative actions the application can perform on the content, which action parameters should be supplied to the control program, and how the control program encodes the return status indicating that the requested action can or cannot be performed, as well as parameters that can further describe the return status.

0581In this section, the following abbreviations and acronyms are used: <ul id="ul0014" list-style="none"><li id="ul0014-0001" num="0582"> ESB: Extended Status Block </li><li id="ul0014-0002" num="0583"> LSB: Least Significant Bit </li><li id="ul0014-0003" num="0584"> Byte: 8-bit value, or octet </li><li id="ul0014-0004" num="0585"> Byte Code: stream of bytes that encode executable instructions and their operands </li></ul>

05861.27. Control Programs

0587In one embodiment, a control object contains a control program. The control program includes a code module containing byte-code that is executable by a virtual machine, and a list of named routines (e.g., entries in the export table).

0588In one embodiment, the set of routines that represent the rules that govern the performance of a certain operation (such as “play”) on a content item is called an ‘action control’. The set of routines that represent validity constraints on a link object is called a “link constraint”. The set of routines that are intended to be executed on behalf of a remote entity (such as during a protocol session with a DRM engine running on a different host) is called an “agent”. The set of routines that are intended to be executed on behalf of another control (such as when a control program uses the System.Host.CallVm system call) is called a “delegate”.

05891.27.1. Interface to Control Programs

0590In one embodiment, control programs are executed by a virtual machine running in a host environment. The host environment can be implemented in any suitable manner; however, for ease of explanation and for purposes of illustration, it will be assumed in the following discussion that the implementation of the virtual machine's host environment can be logically separated into two parts: a host application, and a DRM engine. It will be appreciated, however, that other embodiments may have a different logical separation of functions, which may be equivalent to the logical structure described above.

0591As was shown in <figref idref="DRAWINGS">FIG. 29</figref>, in preferred embodiments, the DRM engine <b>2908</b> is the logical interface between the host application <b>2900</b> and control programs <b>2906</b>. The host application <b>2900</b> makes logical requests to the engine <b>2908</b>, such as requesting access to a content key for a certain purpose (e.g., to play or render a content stream). In one embodiment, the engine <b>2908</b> ensures that the interaction protocol described below is implemented correctly, such as by ensuring that any guarantees regarding a control program's initialization, call sequence, and other interaction details are met.

0592When the host application <b>2900</b> requests the use of content keys for a set of content IDs, the DRM engine <b>2908</b> determines which Control object to use. The Protector objects allow the engine to resolve which ContentKey objects need to be accessed for the requested content IDs. The engine then finds the Controller object that references those ContentKey objects. In one embodiment, a Controller object can reference more than one ContentKey object. This allows multiple ContentKey objects to be governed by the same Control object. When the host application requests access to a content key by invoking an action, it can request content IDs as a group, to the extent that the ContentKey objects that correspond to them are referenced by the same Controller object. In one embodiment, a request to access a group of content keys referenced by more than one controller object is not allowed.

0593In one embodiment, the DRM engine follows a convention for mapping actions to routine names. For example, in one embodiment, for each of the routines described below, the name that appears in the Export Table entry in the code module is the respective string shown below in Sections 9.1.4-9.1.7.

05941.27.1.1. Control Loading

0595In one embodiment, before the engine can make calls to control routines, it needs to load the control's code module into the virtual machine. In one embodiment, only one code module per VM is loaded.

05961.27.1.2. Atomicity

0597In one embodiment, the engine ensures that calls to routines within control programs are atomic with respect to the resources it makes available to the routine, such as the object (or “state”) database. Thus, in such an embodiment, the engine needs to ensure that those resources remain unmodified during the execution of any of the routines it calls. This may be done by effectively locking those resources during a routine call, or by preventing multiple VMs to run concurrently. However, the engine need not guarantee that those resources are unmodified across successive routine invocations.

05981.27.2. Control Protocol

0599In one embodiment, the routine naming, the input/output interface, and the data structures for each routine in a code module, together, constitute a Control Protocol. The protocol implemented by a code module is signaled in the Control object's “protocol” field. The illustrative Control Protocol described below will be called the Standard Control Protocol, and its identifier (the value of the ‘protocol’ field) is “http://www.octopus-drm.com/specs/scp-1_—0”.

0600In one embodiment, before the DRM engine loads a code module and calls routines in the control program, it needs to guarantee that the interaction with the control program will be consistent with the specification for the specific protocol id signaled in the protocol field. That includes any guarantee about the features of the virtual machine that need to be implemented, guarantees about the size of the address space available to the control program, and the like.

0601It is possible for control protocols, such as the Standard Control Protocol, to evolve over time without having to create a new protocol specification. As long as the changes made to the protocol are consistent with previous revisions of the specification, and as long as existing implementations of the DRM engine, as well as existing control programs that comply with that protocol, continue to perform according to the specification, then the changes are deemed compatible. Such changes may include, for instance, new action types.

06021.27.3. Byte Code Type

0603In the illustrative embodiment described above involving the Standard Control Protocol, the type of the byte-code module is “Plankton byte-code module version 1.0”. In this example embodiment, the value for the “type” field of the Control object is “http://www.octopus-drm.com/specs/pkcm-1_—0”.

06041.27.4. General Control Routines

0605General routines are routines that are applicable to the control as a whole, and are not specific to a given action or link constraint. The following general control routines are used in one illustrative embodiment:

06061.27.4.1. Control.Init

0607This routine is optional (i.e., it is not required in all controls). If this routine is used, the engine calls it once before any other control routine is called. The routine has no inputs, and returns a ResultCode to the top of the stack as an output. The ResultCode is 0 on success, or a negative error code on failure. In one embodiment, if the ResultCode is not 0, the engine aborts the current control operation and does not make any further calls to routines for this control.

06081.27.4.2. Control.Describe

0609This routine is optional. The routine is called when the application requests a description of the meaning of the rules represented by the control program in general (i.e. not for a specific action). The routine has no inputs, and returns a ResultCode and a StatusBlockPointer to the top of the stack as outputs, where the ResultCode is an integer value (0 if the routine completed successfully, or a negative error code otherwise), and where the StatusBlockPointer is the address of a standard ExtendedStatusBlock. The ExtendedStatusBlock contains information that an application can interpret and use to provide information to the user regarding the meaning of the rules represented by the control program.

06101.27.4.3. Control.Release

0611This routine is optional. If this routine exists, the DRM engine calls it once after it no longer needs to call any other routine for the control. No other routine will be called for the control unless a new use of the control is initiated (in which case, the Control.Init routine will be called again). The routine has no inputs, and returns a ResultCode to the top of the stack as an output. The ResultCode is 0 on success, or a negative error code on failure.

06121.27.5. Action Routines

0613Each possible action has a name (e.g., play, transfer, export, etc.). In one illustrative embodiment, for a given action <Action>, the following routine names are defined (where “<Action>” denotes the actual name of the action (e.g., “play”, “transfer”, “export”, etc.)):

06141.27.5.1. Control.Actions.<Action>.Init

0615This routine is optional. If it exists, the engine calls it once before any other routine is called for this action. The routine has no inputs, and returns a ResultCode to the top of the stack as an output. The ResultCode is 0 on success, or a negative error code on failure. In one embodiment, if ResultCode is not 0, the engine aborts the current action and does not make any further calls to routines for this action in this control.

06161.27.5.2. Control.Actions.<Action>.Check

0617In the illustratie embodiment being discussed, this routine is required, and is called to check, without actually performing a given action, what the return status would be if the Perform routine were to be called for that action. It is important for this routine not to have any side effects. Note that if the Perform routine also has no side effects, the Check and Perform entries in the control's Entries Table can point to the same routine. This routine has the same inputs and outputs as the Perform routine described below.

06181.27.5.3. Control.Actions.<Action>.Perform

0619In one embodiment, this routine is required, and is called when the application is about to perform the action. The routine has no inputs, and returns a ResultCode and a StatusBlockPointer to the top of the stack as outputs, where the ResultCode is an integer value (0 if the routine completed successfully, or a negative error code otherwise), and where the StatusBlockPointer is the address of a standard ExtendedStatusBlock. Note that in one embodiment a success ResultCode (i.e., 0) does not mean that the request was granted. It only means that the routine was able to run without error. It is the ExtendedStatusBlock that indicates whether the request was granted or denied. However, if the ResultCode indicates a failure, the host application proceeds as if the request was denied. For example, in one embodiment the StatusBlock's category should be ACTION_DENIED, or the returned ExtendedStatusBlock is rejected, and the host application aborts the action.

0620When an action is performed, only the Perform routine needs to be called. The engine does not need to call the Check routine beforehand. An implementation of the Perform routine can call the Check routine internally if it chooses to do so, but should not assume that the system will have called the Check routine beforehand.

06211.27.5.4. Control.Actions.<Action>.Describe

0622This routine is optional, and is called when an application requests a description of the meaning of the rules and conditions represented by the control program for the given action. The routine has no inputs, and returns a ResultCode and a StatusBlockPointer to the top of the stack as outputs, where the ResultCode is an integer value (0 if the routine completed successfully, or a negative error code otherwise), and where the StatusBlockPointer is the address of a standard ExtendedStatusBlock.

06231.27.5.5. Control.Actions.<Action>.Release

0624This routine is optional. If it exists, it is called once after the DRM engine no longer needs to call any other routines for the given action. No other routine are called for the given action unless a new use of the action is initiated (in which case, the Init routine will be called again). The routine has no inputs, and returns a ResultCode to the top of the stack as an output. The ResultCode is 0 on success and a negative error code on failure. If the ResultCode is not 0, the engine does not make any further calls to routines for the given action

06251.27.6. Link Constraint Routines

0626In one embodiment, when a link object has an embedded control, the DRM engine calls the link constraint routines in that control to verify the validity of the link object. The following link constraint routines are used in one illustrative embodiment:

06271.27.6.1. Control.Link.Constraint.Init

0628This routine is optional, and, if it exists, is called exactly once before any other routine is called for the given link constraint. The routine has no inputs, and returns a ResultCode to the top of the stack as an output. The ResultCode is 0 on success and a negative error code on failure. If the ResultCode is not 0, the engine deems the validity constraint for the link object to be unsatisfied, and avoids making further calls to routines for the link control.

06291.27.6.2. Control.Link.Constraint.Check

0630In the illustrative embodiment being discussed, this routine is required, and is called to check if the validity constraint for a given link is satisfied. The routine has no inputs, and returns a ResultCode and a StatusBlockPointer to the top of the stack as outputs, where the ResultCode is an integer value (0 if the routine completed successfully, or a negative error code otherwise), and where the StatusBlockPointer is the address of a standard ExtendedStatusBlock. If the ResultCode is not 0, the engine deems the validity constraint for the link object to be unsatisfied, and avoids making further calls to routines for the link control. Even if the ResultCode is 0 (success), this does not mean that the constraint has been satisfied; it only means that the routine was able to run without error. It is the StatusBlock that indicates whether the constraint is satisfied or not.

06311.27.6.3. Control.Link.Constraint.Describe

0632This routine is optional, and is called when the application requests a description of the meaning of the constraint represented by the control program for a given link. The routine has no inputs, and returns a ResultCode and a StatusBlockPointer to the top of the stack as outputs, where the ResultCode is an integer value (0 if the routine completed successfully, or a negative error code otherwise), and where the StatusBlockPointer is the address of a standard ExtendedStatusBlock.

06331.27.6.4. Control.Link.Constraint.Release

0634This routine is optional, and, if it exists, is called by the engine once after the engine no longer needs to call any other routine for the given constraint. The routine has no inputs, and returns a ResultCode to the top of the stack as an output. The ResultCode is 0 on success and a negative error code on failure. In the embodiment being discussed, after calling this routine, no other routine can be called for the given constraint unless a new cycle is initiated (in which case, the Init routine is called again). Similarly, if the ResultCode is not 0, the engine does not make further calls to routines for the given link constraint.

06351.27.7. Agent Routines

0636In one embodiment, an agent is a control object that is designed to run on behalf of an entity. Agents are typically used in the context of a service interaction between two endpoints, where one endpoint needs to execute some virtual machine code within the context of the second endpoint, and possibly obtain the result of that execution. In one embodiment, a control can contain multiple agents, and each agent can contain any number of routines that can be executed; however, in practice, agents typically have a single routine.

0637In one illustrative embodiment, the following entry points are defined for agents, where <Agent> is a name string that refers to the actual name of an agent.

06381.27.7.1. Control.Agents.<Agent>.Init

0639This routine is optional, and, if it exists, the engine calls it once before any other routine is called for the given agent. The routine has no inputs, and returns a ResultCode to the top of the stack as an output. The ResultCode is 0 on success and a negative error code on failure.

06401.27.7.2. Control.Agents.<Agent>.Run

0641In the illustrative embodiment under discussion, this routine is required, and is the main routine of the agent. The routine has no inputs, and returns a ResultCode, a ReturnBlockAddress, and a ReturnBlockSize to the top of the stack as outputs. The ResultCode is an integer value (0 if the routine completed successfully, or a negative error code otherwise), the ReturnBlockAddress is the address of a block of memory that contains data that the agent code is expected to return to the caller (if the routine does not need to return anything, the address is 0), and the ReturnBlockSize is the size in bytes of the block of memory at the ReturnBlockAddress. In one embodiment, if ReturnBlockAddress is 0, the value of ReturnBlockSize is also 0.

06421.27.7.3. Control.Agents.<Agent>.Describe

0643This routine is optional, and is called when an application request a description of a given agent. The routine has no inputs, and returns a ResultCode and a StatusBlockPointer to the top of the stack as outputs, where the ResultCode is an integer value (0 if the routine completed successfully, or a negative error code otherwise), and where the StatusBlockPointer is the address of a standard ExtendedStatusBlock.

06441.27.7.4. Control.Agents.<Agent>.Release

0645This routine is optional, and, if it exists, the engine calls it once after the engine no longer needs to call any other routines for this agent. No other routine will be called for this ,agent unless a new cycle is initiated (in which case, the Init routine will be called again). The routine has no inputs, and returns a ResultCode to the top of the stack as an output. The ResultCode is 0 on success and a negative error code on failure.

06461.28. Extended Status Blocks

0647The following example definitions are applicable to the ExtendedStatusBlock data structures returned by illustrative embodiments of several of the routines described above. Examples of ExtendedStatusBlock data structures are described in connection with the description of the virtual machine.

0648In one embodiment, there are no global ExtendedStatusBlock flags. In this embodiment, control programs set the GlobalFlag field of the ExtendedStatuBlock to 0.

06491.28.1. Categories

0650The following paragraphs define values for the Category field of ExtendedStatusBlocks in accordance with one embodiment. In one embodiment, none of these categories have sub-categories, and thus the value of the SubCategory field of the ExtendedStatusBlocks is set to 0.

0651In one embodiment, the following category codes are defined:

06521.28.1.1. Actions Check and Perform Routines <tables id="TABLE-US-00040" num="40"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="21PT" align="center" /><colspec colname="2" colwidth="70PT" align="left" /><colspec colname="3" colwidth="168PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Value</entry><entry>Name</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>0</entry><entry>ACTION_GRANTED</entry><entry>The application is authorized to use the content</entry></row><row><entry /><entry /><entry>keys controlled by the control program for the</entry></row><row><entry /><entry /><entry>purpose of the requested action.</entry></row><row><entry /><entry /><entry>The parameter list of the returned</entry></row><row><entry /><entry /><entry>ExtendedStatusBlock should not contain any of</entry></row><row><entry /><entry /><entry>the constraint parameters, but may contain</entry></row><row><entry /><entry /><entry>obligation and/or callback parameters.</entry></row><row><entry>1</entry><entry>ACTION_DENIED</entry><entry>The application is not authorized to use the content</entry></row><row><entry /><entry /><entry>keys controlled by the control program for the</entry></row><row><entry /><entry /><entry>purpose of the requested action.</entry></row><row><entry /><entry /><entry>When an action is denied, the control program</entry></row><row><entry /><entry /><entry>should include in the parameter list of the returned</entry></row><row><entry /><entry /><entry>ExtendedStatusBlock one or more of the</entry></row><row><entry /><entry /><entry>constraints that were not met and caused the action</entry></row><row><entry /><entry /><entry>to be denied (the constraints that were not</entry></row><row><entry /><entry /><entry>evaluated and the constraints that did not cause the action</entry></row><row><entry /><entry /><entry>to fail should be omitted).</entry></row><row><entry /><entry /><entry>In one embodiment, the parameter list of the</entry></row><row><entry /><entry /><entry>returned ExtendedStatusBlock must not contain any</entry></row><row><entry /><entry /><entry>obligation or callback parameter.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0653In one embodiment, in the context of ExtendedStatusBlock parameters returned by action routines, a constraint means a condition that is required to be true or a criterion that is required to be met in order for the result of the routine to return an ExtendedStatusBlock with the category ACTION_GRANTED.

0654In one embodiment, values for the LocalFlags field common to both categories described above include: <tables id="TABLE-US-00041" num="41"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="35PT" align="center" /><colspec colname="2" colwidth="98PT" align="left" /><colspec colname="3" colwidth="126PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Bit Index</entry><entry /><entry /></row><row><entry>(0 is LSB)</entry><entry>Name</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>0</entry><entry>OBLIGATION_NOTICE</entry><entry>The parameter list contains one or</entry></row><row><entry /><entry /><entry>more parameters that are related to</entry></row><row><entry /><entry /><entry>obligations</entry></row><row><entry>1</entry><entry>CALLBACK_NOTICE</entry><entry>The parameter list contains one or</entry></row><row><entry /><entry /><entry>more parameters that are related to</entry></row><row><entry /><entry /><entry>callbacks</entry></row><row><entry>2</entry><entry>GENERIC_CONSTRAINT</entry><entry>The parameter list contains one or</entry></row><row><entry /><entry /><entry>more parameters that are related to generic</entry></row><row><entry /><entry /><entry>constraints</entry></row><row><entry>3</entry><entry>TEMPORAL_CONSTRAINT</entry><entry>The parameter list contains one or</entry></row><row><entry /><entry /><entry>more parameters that are related to</entry></row><row><entry /><entry /><entry>temporal constraints</entry></row><row><entry>4</entry><entry>SPATIAL_CONSTRAINT</entry><entry>The parameter list contains one or</entry></row><row><entry /><entry /><entry>more parameters that are related to</entry></row><row><entry /><entry /><entry>spatial constraints</entry></row><row><entry>5</entry><entry>GROUP_CONSTRAINT</entry><entry>The parameter list contains one or</entry></row><row><entry /><entry /><entry>more parameters that are related to</entry></row><row><entry /><entry /><entry>group constraints</entry></row><row><entry>6</entry><entry>DEVICE_CONSTRAINT</entry><entry>The parameter list contains one or</entry></row><row><entry /><entry /><entry>more parameters that are related to</entry></row><row><entry /><entry /><entry>device constraints</entry></row><row><entry>7</entry><entry>COUNTER_CONSTRAINT</entry><entry>The parameter list contains one or</entry></row><row><entry /><entry /><entry>more parameters that are related to counter</entry></row><row><entry /><entry /><entry>constraints</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0655In the table shown above, the parameter list that is referred to is the “Parameters” field of the ExtendedStatusBlock data structure.

06561.28.1.2. Describe Routine Category Codes

0657In one embodiment, no category codes are defined for Describe routines. In one embodiment, the same local flags as the ones defined for Action routines apply to Describe routines, and Describe routines should include in their retuned ExtendedStatusBlock a parameter named ‘Description’ as specified below. In one embodiment, Describe routines do not contain in their retuned ExtendedStatusBlock any obligation or callback parameters; however, Describe routines should include in their returned ExtendedStatusBlock parameters that describe some or all of the constraints that are applicable for the corresponding action or link constraint.

06581.28.1.3. Link Constraint Routine Category Codes <tables id="TABLE-US-00042" num="42"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="21PT" align="center" /><colspec colname="2" colwidth="56PT" align="left" /><colspec colname="3" colwidth="140PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Value</entry><entry>Name</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>0</entry><entry>LINK_VALID</entry><entry>The link constrained by this control program is</entry></row><row><entry /><entry /><entry>valid.</entry></row><row><entry /><entry /><entry>The parameter list of the returned ESB should</entry></row><row><entry /><entry /><entry>not contain any of the constraint parameters,</entry></row><row><entry /><entry /><entry>and, in one embodiment, must not contain</entry></row><row><entry /><entry /><entry>obligation or callback parameters</entry></row><row><entry>1</entry><entry>LINK_INVALID</entry><entry>The link constrained by this control program is</entry></row><row><entry /><entry /><entry>invalid.</entry></row><row><entry /><entry /><entry>When a link is invalid, the control program</entry></row><row><entry /><entry /><entry>should include in the parameter list of the</entry></row><row><entry /><entry /><entry>returned ESB one or more of the constraints</entry></row><row><entry /><entry /><entry>that were not met and caused the</entry></row><row><entry /><entry /><entry>link to be invalid (the constraints</entry></row><row><entry /><entry /><entry>that were not evaluated and the constraints</entry></row><row><entry /><entry /><entry>that did not cause the action to fail</entry></row><row><entry /><entry /><entry>should be omitted).</entry></row><row><entry /><entry /><entry>In one embodiment,</entry></row><row><entry /><entry /><entry>the parameter list of the</entry></row><row><entry /><entry /><entry>returned ESB must not contain any obligation</entry></row><row><entry /><entry /><entry>or callback parameter.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0659In one embodiment, the same local flags as the ones defined for Action routines apply for each of these categories.

0660In one embodiment, in the context of ExtendedStatusBlock parameters returned by link constraint routines, a constraint means a condition that is required to be true or a criterion that is required to be met in order for the result of the routine to return an ExtendedStatusBlock with the category LINK_VALID.

06611.28.2. Cache Durations

0662The CacheDuration field of an ExtendedStatusBlock is an indication of the validity period of the information encoded in the ExtendedStatusBlock. When an ExtendedStatusBlock has a non-zero validity period, it means that the ExtendedStatusBlock can be stored in a cache, and that during that period of time a call to the exact same routine call with the same parameters would return the same ExtendedStatusBlock, so the cached value may be returned to the host application instead of calling the routine.

06631.28.3. Parameters

0664Some parameters are used to convey detailed information about the return status, as well as variable bindings for template processing (see Section 9.4).

0665In one embodiment, except for obligations and callbacks, all the constraints described here are strictly for the purpose of helping the host application classify and display, not for enforcement of the usage rules. The enforcement of the rules is the responsibility of the control program.

0666In one embodiment, the parameters defined in the following section are encoded either as a ParameterBlock, if no parameter flags are applicable, or as an ExtendedParameterBlock, of one or more flags are applicable. Representative flags are described below:

06671.28.3.1. Description

0668Parameter Name: Description

0669Parameter Type: ValueList

0670Description: List of description parameters. Each value in the list is of type Parameter or Extended Parameter. In one embodiment, the following parameters are defined: Default, Short and Long. Each of them, if present has for a value the ID of one of the control's resources. That resource should contain a textual payload, or a template payload. If the resource is a template, it is processed to obtain a textual description of the result (either a description of the entire control program, or of a specific action). The template is processed using as variable bindings the other parameters of the list in which the ‘Description’ parameter appears.

0671In one embodiment, the ‘Short’ and ‘Long’ descriptions can only be included if a ‘Default’ description is also included. <tables id="TABLE-US-00043" num="43"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="28PT" align="left" /><colspec colname="2" colwidth="42PT" align="left" /><colspec colname="3" colwidth="133PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="3" align="center" rowsep="1" /></row><row><entry /><entry>Name</entry><entry>Type</entry><entry>Description</entry></row><row><entry /><entry namest="OFFSET" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Default</entry><entry>Resource</entry><entry>Id of the resource that contains the normal</entry></row><row><entry /><entry /><entry /><entry>description text or template</entry></row><row><entry /><entry>Short</entry><entry>Resource</entry><entry>Id of the resource that contains the short</entry></row><row><entry /><entry /><entry /><entry>description text or template</entry></row><row><entry /><entry>Long</entry><entry>Resource</entry><entry>Id of the resource that contains the long</entry></row><row><entry /><entry /><entry /><entry>description text or template</entry></row><row><entry /><entry namest="OFFSET" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

06721.28.3.2. Constraints

0673In one embodiment, constraint parameters are grouped in lists that contain constraints of similar types. In one embodiment, standard constraints are defined for some of the types. In one embodiment, controls may return constraint parameters that are not included in the set of standard constraints, provided that the name of the constraint parameters be a URN in a namespace that guarantees the uniqueness of that name. This may include vendor-specific constraints, or constraints defined in other specifications.

06741.28.3.2.1. Generic Constraints

0675Parameter Name: GenericConstraints

0676Parameter Type: ValueList

0677Description: List of generic constraints that may be applicable. Each value in the list is of type Parameter or ExtendedParameter.

0678In one embodiment, generic constraints are constraints that do not belong to any of the other constraint types defined in this section. In one embodiment, no generic constraint parameters are defined.

06791.28.3.2.2. Temporal Constraints

0680Parameter Name: TemporalConstraints

0681Parameter Type: ValueList

0682Description: List of temporal constraints that may be applicable. Each value in the list is of type Parameter or Extended Parameter. Temporal constraints are constraints that are related to time, date, duration, and/or the like. In one embodiment, the following temporal constraint parameters are defined: <tables id="TABLE-US-00044" num="44"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="56PT" align="left" /><colspec colname="2" colwidth="35PT" align="left" /><colspec colname="3" colwidth="126PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Name</entry><entry>Type</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>NotBefore</entry><entry>Date</entry><entry>Date before which the action is denied</entry></row><row><entry>NotAfter</entry><entry>Date</entry><entry>Date after which the action is denied</entry></row><row><entry>NotDuring</entry><entry>ValueList</entry><entry>List of 2 values of type Date. The first</entry></row><row><entry /><entry /><entry>value is the start of the period, and the</entry></row><row><entry /><entry /><entry>second is the end of the period</entry></row><row><entry /><entry /><entry>that is excluded.</entry></row><row><entry>NotLongerThan</entry><entry>Integer</entry><entry>Max number of seconds after first use.</entry></row><row><entry /><entry /><entry>In one embodiment, this value is unsigned.</entry></row><row><entry>NotMoreThan</entry><entry>Integer</entry><entry>Max number of seconds of accumulated</entry></row><row><entry /><entry /><entry>use time. In one embodiment,</entry></row><row><entry /><entry /><entry>this value is unsigned.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

06831.28.3.2.3. Spatial Constraints

0684Parameter Name: SpatialConstraints

0685Parameter Type: ValueList

0686Description: List of spatial constraints that may be applicable. In one embodiment, each value in the list is of type Parameter or ExtendedParameter. Spatial constraints are constraints that are related to physical locations. In one embodiment, no standard spatial constraints are defined.

06871.28.3.2.4. Group Constraints

0688Parameter Name: GroupConstraints

0689Parameter Type: ValueList

0690Description: List of group constraints that may be applicable. Each value in the list is of type Parameter or Extended Parameter. Group constraints are constraints that are related to groups, group membership, identity groups, and/or the like. In one embodiment, the following parameters are defined: <tables id="TABLE-US-00045" num="45"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="70PT" align="left" /><colspec colname="2" colwidth="42PT" align="left" /><colspec colname="3" colwidth="105PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Name</entry><entry>Type</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>MembershipRequired</entry><entry>Resource</entry><entry>Id of the resource that contains</entry></row><row><entry /><entry /><entry>the text or template for the</entry></row><row><entry /><entry /><entry>name or identifier of a group</entry></row><row><entry /><entry /><entry>of which a membership is required</entry></row><row><entry>IdentityRequired</entry><entry>Resource</entry><entry>Id of the resource that contains</entry></row><row><entry /><entry /><entry>the text or template for the name or</entry></row><row><entry /><entry /><entry>identifier of an individual</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

06911.28.3.2.5. Device Constraints

0692Parameter Name: DeviceConstraints

0693Parameter Type: ValueList

0694Description: List of device constraints that may be applicable. Each value in the list is of type Parameter or Extended Parameter. Device constraints are constraints that are related to characteristics of a device, such as features, attributes, names, identifiers, and/or the like. In one embodiment, the following parameters are defined: <tables id="TABLE-US-00046" num="46"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="77PT" align="left" /><colspec colname="2" colwidth="42PT" align="left" /><colspec colname="3" colwidth="98PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Name</entry><entry>Type</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>DeviceTypeRequired</entry><entry>Resource</entry><entry>Id of the resource that contains</entry></row><row><entry /><entry /><entry>the text or template for the</entry></row><row><entry /><entry /><entry>type of host device that is</entry></row><row><entry /><entry /><entry>required</entry></row><row><entry>DeviceFeatureRequired</entry><entry>Resource</entry><entry>Id of the resource that</entry></row><row><entry /><entry /><entry>contains the text or</entry></row><row><entry /><entry /><entry>template for name of feature</entry></row><row><entry /><entry /><entry>that the host device must have</entry></row><row><entry>DeviceIdRequired</entry><entry>String</entry><entry>Id that the device</entry></row><row><entry /><entry /><entry>is required to have. This</entry></row><row><entry /><entry /><entry>Id may be any string that can</entry></row><row><entry /><entry /><entry>be used to identify the device</entry></row><row><entry /><entry /><entry>(e.g., device name, device serial</entry></row><row><entry /><entry /><entry>number, a node id, and/or the</entry></row><row><entry /><entry /><entry>like).</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

06951.28.3.2.6. Counter Constraints

0696Parameter Name: CounterConstraints

0697Parameter Type: ValueList

0698Description: List of counter constraints that may be applicable. Each value in the list is of type Parameter or ExtendedParameter. Counter constraints are constraints that are related to counted values, such as play counts, accumulated counts, and/or the like. In one embodiment, no standard counter constraints are defined.

06991.28.3.3. Parameter Flags

0700In one embodiment, the following flags may be used for all the parameters described in Section 9.2.3, when they are encoded as an ExtendedStatusBlock: <tables id="TABLE-US-00047" num="47"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="21PT" align="center" /><colspec colname="2" colwidth="77PT" align="left" /><colspec colname="3" colwidth="161PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Bit</entry><entry /><entry /></row><row><entry>Index</entry></row><row><entry>(0 is</entry></row><row><entry>LSB)</entry><entry>Name</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>0</entry><entry>CRITICAL</entry><entry>The semantics associated with this parameter</entry></row><row><entry /><entry /><entry>need to be understood by the host application.</entry></row><row><entry /><entry /><entry>If they are not, the entire ExtendedStatusBlock</entry></row><row><entry /><entry /><entry>should be treated as not understood and rejected.</entry></row><row><entry /><entry /><entry>In one embodiment, this flag should not be</entry></row><row><entry /><entry /><entry>used for parameters that are descriptive in</entry></row><row><entry /><entry /><entry>nature.</entry></row><row><entry>1</entry><entry>HUMAN_READABLE</entry><entry>This parameter represents a value whose name</entry></row><row><entry /><entry /><entry>and value are suitable to display in a textual or</entry></row><row><entry /><entry /><entry>graphical user interface. Any parameter that</entry></row><row><entry /><entry /><entry>does not have this flag set should be reserved</entry></row><row><entry /><entry /><entry>for the host application, and not be shown to a</entry></row><row><entry /><entry /><entry>user. For parameter values of type Resource, it</entry></row><row><entry /><entry /><entry>is not the resource ID, but the resource data</entry></row><row><entry /><entry /><entry>payload referenced by the ID, that is human-readable.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

07011.29. Obligations and Callbacks

0702In one embodiment, certain actions, when granted, require further participation from the host application. Obligations represent operations that need to be performed by the host application upon or after the use of the content key it is requesting. Callbacks represent calls to one or more of the control program routines that need to be performed by the host application upon or after the use of the content key they are requesting.

0703In one embodiment, if an application encounters any critical obligation or callback that it does not support, or does not understand (for example because the obligation type may have been defined after the application was implemented), it must refuse to continue the action for which this obligation or callback parameter was returned. In one embodiment, a critical obligation or callback is indicated by setting the CRITICAL parameter flag for the parameter that describes it.

0704If a control has side effects (such as decrementing a play count, for example), it should use the OnAccept callback to require the host application to call a certain routine if it is able to understand and comply with all critical obligations and callbacks. The side effect should happen in the callback routine. In one example embodiment, implementations are required to understand and implement the OnAccept callback, since it can be useful in preventing side effects (e.g., updates to the state database) from occuring prematurely (e.g., before the host application determines that it is unable to comply with a given critical obligation or callback and needs to terminate performance of an action), thus providing a measure of transactional atomicity.

07051.29.1. Parameters

0706The following parameters define several types of obligations and callbacks that can be returned in ExtendedStatusBlock data structures.

07071.29.1.1. Obligations

0708Parameter Name: Obligations

0709Parameter Type: ValueList

0710Description: List of obligation parameters. Each value in the list is of type Parameter or Extended Parameter. In one embodiment, the following obligation parameters are defined: <tables id="TABLE-US-00048" num="48"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="56PT" align="left" /><colspec colname="2" colwidth="35PT" align="left" /><colspec colname="3" colwidth="126PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Name</entry><entry>Type</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>RunAgentOnPeer</entry><entry>ValueList</entry><entry>The host application needs to send</entry></row><row><entry /><entry /><entry>an agent control to run on a peer of the</entry></row><row><entry /><entry /><entry>currently running protocol session</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="91PT" align="left" /><colspec colname="1" colwidth="35PT" align="left" /><colspec colname="2" colwidth="91PT" align="left" /><tbody valign="top"><row><entry /><entry>Type</entry><entry>Description</entry></row><row><entry /><entry>String</entry><entry>Id of the Control that contains</entry></row><row><entry /><entry /><entry>the agent to run.</entry></row><row><entry /><entry>String</entry><entry>Name of the agent to run.</entry></row><row><entry /><entry>Integer</entry><entry>Instance Id. This value is</entry></row><row><entry /><entry /><entry>used to uniquely</entry></row><row><entry /><entry /><entry>identify this agent</entry></row><row><entry /><entry /><entry>obligation instance.</entry></row><row><entry /><entry /><entry>This id will</entry></row><row><entry /><entry /><entry>also allow the system to</entry></row><row><entry /><entry /><entry>correlate this agent obligation</entry></row><row><entry /><entry /><entry>with an OnAgentCompletion</entry></row><row><entry /><entry /><entry>callback parameter.</entry></row><row><entry /><entry>String</entry><entry>Context Id. This Id will be</entry></row><row><entry /><entry /><entry>visible to the running agent on</entry></row><row><entry /><entry /><entry>the peer under the agent's</entry></row><row><entry /><entry /><entry>session context Host Object</entry></row><row><entry /><entry /><entry>path:</entry></row><row><entry /><entry /><entry>Octopus/Agent/Parameters/</entry></row><row><entry /><entry /><entry>Session/ContextId.</entry></row><row><entry /><entry>ValueList</entry><entry>List of values of</entry></row><row><entry /><entry /><entry>type Parameter.</entry></row><row><entry /><entry /><entry>All those parameters will be</entry></row><row><entry /><entry /><entry>visible to the agent as input</entry></row><row><entry /><entry /><entry>parameters.</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

07111.29.1.2. Callbacks

0712Parameter Name: Callbacks

0713Parameter Type: ValueList

0714Description: List of callback parameters. Each value in the list is of type Parameter or Extended Parameter. In one embodiment, the following callbacks parameters are defined: <tables id="TABLE-US-00049" num="49"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="63PT" align="left" /><colspec colname="2" colwidth="35PT" align="left" /><colspec colname="3" colwidth="161PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Name</entry><entry>Type</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>OnAccept</entry><entry>Callback</entry><entry>The host application must call back if it is able to</entry></row><row><entry /><entry /><entry>understand all the critical obligations and callback</entry></row><row><entry /><entry /><entry>parameters contained in this ESB.</entry></row><row><entry /><entry /><entry>In one embodiment, there can be at most one</entry></row><row><entry /><entry /><entry>OnAccept callback parameter in a list of callback</entry></row><row><entry /><entry /><entry>parameters. If other callback parameters are</entry></row><row><entry /><entry /><entry>specified in the list, the OnAccept is executed first.</entry></row><row><entry>OnTime</entry><entry>ValueList</entry><entry>The host application must call back after the</entry></row><row><entry /><entry /><entry>specified date/time.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="98PT" align="left" /><colspec colname="1" colwidth="35PT" align="left" /><colspec colname="2" colwidth="126PT" align="left" /><tbody valign="top"><row><entry /><entry>Type</entry><entry>Description</entry></row><row><entry /><entry>Date</entry><entry>The date after which the host</entry></row><row><entry /><entry /><entry>application needs to perform the callback.</entry></row><row><entry /><entry>Callback</entry><entry>Routine to call back, and associated</entry></row><row><entry /><entry /><entry>cookie.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="63PT" align="left" /><colspec colname="2" colwidth="35PT" align="left" /><colspec colname="3" colwidth="161PT" align="left" /><tbody valign="top"><row><entry>OnTimeElapsed</entry><entry>ValueList</entry><entry>The host application must call back after the</entry></row><row><entry /><entry /><entry>specified duration has elapsed (the counting starts</entry></row><row><entry /><entry /><entry>when the host application actually performs the</entry></row><row><entry /><entry /><entry>action for which the permission that was granted).</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="98PT" align="left" /><colspec colname="1" colwidth="35PT" align="left" /><colspec colname="2" colwidth="126PT" align="left" /><tbody valign="top"><row><entry /><entry>Type</entry><entry>Description</entry></row><row><entry /><entry>Integer</entry><entry>Number of seconds. The value is</entry></row><row><entry /><entry /><entry>unsigned.</entry></row><row><entry /><entry>Callback</entry><entry>Routine to call back, and associated</entry></row><row><entry /><entry /><entry>cookie.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="63PT" align="left" /><colspec colname="2" colwidth="35PT" align="left" /><colspec colname="3" colwidth="161PT" align="left" /><tbody valign="top"><row><entry>OnEvent</entry><entry>ValueList</entry><entry>The host application must call back when a certain</entry></row><row><entry /><entry /><entry>event occurs.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="98PT" align="left" /><colspec colname="1" colwidth="35PT" align="left" /><colspec colname="2" colwidth="126PT" align="left" /><tbody valign="top"><row><entry /><entry>Type</entry><entry>Description</entry></row><row><entry /><entry>String</entry><entry>Event Name</entry></row><row><entry /><entry>Integer</entry><entry>Event Flags (the integer valus is</entry></row><row><entry /><entry /><entry>interpreted as a bit-field)</entry></row><row><entry /><entry>Integer</entry><entry>Event Parameter</entry></row><row><entry /><entry>Callback</entry><entry>Routine to call back, and associated</entry></row><row><entry /><entry /><entry>cookie.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="98PT" align="left" /><colspec colname="1" colwidth="161PT" align="left" /><tbody valign="top"><row><entry /><entry>See the paragraph about events for more</entry></row><row><entry /><entry>details about the events.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="63PT" align="left" /><colspec colname="2" colwidth="35PT" align="left" /><colspec colname="3" colwidth="161PT" align="left" /><tbody valign="top"><row><entry>OnAgentCompletion</entry><entry>ValueList</entry><entry>The host application must call back when an agent</entry></row><row><entry /><entry /><entry>specified in one of the obligation parameters has</entry></row><row><entry /><entry /><entry>completed, or failed to run.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="98PT" align="left" /><colspec colname="1" colwidth="35PT" align="left" /><colspec colname="2" colwidth="126PT" align="left" /><tbody valign="top"><row><entry /><entry>Type</entry><entry>Description</entry></row><row><entry /><entry>Integer</entry><entry>Agent instance id.</entry></row><row><entry /><entry /><entry>The instance id specified in an agent</entry></row><row><entry /><entry /><entry>obligation.</entry></row><row><entry /><entry>Callback</entry><entry>Routine to call back, and associated</entry></row><row><entry /><entry /><entry>cookie.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="98PT" align="left" /><colspec colname="1" colwidth="161PT" align="left" /><tbody valign="top"><row><entry /><entry>When calling back, the host application must</entry></row><row><entry /><entry>provide the following ArgumentsBlock:</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="OFFSET" colwidth="98PT" align="left" /><colspec colname="1" colwidth="35PT" align="left" /><colspec colname="2" colwidth="35PT" align="left" /><colspec colname="3" colwidth="91PT" align="left" /><tbody valign="top"><row><entry /><entry>Type</entry><entry>Encoding</entry><entry>Description</entry></row><row><entry /><entry>32-bit</entry><entry>4 bytes in</entry><entry>Completion status</entry></row><row><entry /><entry>integer</entry><entry>big-endian</entry><entry>code.</entry></row><row><entry /><entry /><entry>order</entry></row><row><entry /><entry>32-bit</entry><entry>4 bytes in</entry><entry>Agent result code</entry></row><row><entry /><entry>integer</entry><entry>big-endian</entry></row><row><entry /><entry /><entry>order</entry></row><row><entry /><entry>8-bit byte</entry><entry>Byte</entry><entry>Agent ReturnBlock</entry></row><row><entry /><entry>array</entry><entry>sequence</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="98PT" align="left" /><colspec colname="1" colwidth="161PT" align="left" /><tbody valign="top"><row><entry /><entry>The completion status code value is 0 if the agent</entry></row><row><entry /><entry>was able to run or a negative error code if it was</entry></row><row><entry /><entry>not.</entry></row><row><entry /><entry>The agent ReturnBlock is the data returned by the</entry></row><row><entry /><entry>agent. This is omitted if the agent was unable to run</entry></row><row><entry /><entry>(the Completion status code is not 0).</entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0715In one embodiment, the ‘Callback’ type mentioned in the table above is a ValueListBlock with three ValueBlock elements: <tables id="TABLE-US-00050" num="50"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="28PT" align="left" /><colspec colname="2" colwidth="189PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row><row><entry>Value</entry><entry /></row><row><entry>Type</entry><entry>Description</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Integer</entry><entry>ID of the callback type. In one embodiment, two types</entry></row><row><entry /><entry>of callbacks are defined:</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="28PT" align="left" /><colspec colname="1" colwidth="56PT" align="left" /><colspec colname="2" colwidth="133PT" align="left" /><tbody valign="top"><row><entry /><entry>ID</entry><entry>Description</entry></row><row><entry /><entry>RESET = 0</entry><entry>All pending callbacks requests and active</entry></row><row><entry /><entry /><entry>obligations are cancelled upon calling the</entry></row><row><entry /><entry /><entry>callback routine. The callback routine</entry></row><row><entry /><entry /><entry>returns an ESB that indicates if and how the</entry></row><row><entry /><entry /><entry>application can continue with the current</entry></row><row><entry /><entry /><entry>operation.</entry></row><row><entry /><entry>CONTINUE = 1</entry><entry>The callback routine is called while all</entry></row><row><entry /><entry /><entry>other pending callback requests and active</entry></row><row><entry /><entry /><entry>obligations remain in effect. The callback</entry></row><row><entry /><entry /><entry>routine returns a simple result code. The</entry></row><row><entry /><entry /><entry>application can continue with the current</entry></row><row><entry /><entry /><entry>operation unless that result code indicates a</entry></row><row><entry /><entry /><entry>failure.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="28PT" align="left" /><colspec colname="2" colwidth="189PT" align="left" /><tbody valign="top"><row><entry>String</entry><entry>Entry point to call in the code module. In one</entry></row><row><entry /><entry>embodiment, this must be one of the entries in</entry></row><row><entry /><entry>the Export Table of the code module for the</entry></row><row><entry /><entry>same control as the one containing the routine</entry></row><row><entry /><entry>that returned the ESB with this parameter.</entry></row><row><entry>Integer</entry><entry>Cookie. This value will be passed on the stack to</entry></row><row><entry /><entry>the routine that is called.</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

07161.29.1.3. Parameter Flags

0717In one embodiment, the same parameter flags as defined in the previous section are used. In one embodiment, callbacks and obligations that a caller is required to implement are marked as CRITICAL, so as to avoid giving a host application the choice to ignore these parameters.

07181.29.2. Events

0719In one embodiment, events are specified by name. Depending on the type of event, there may be a set of flags defined that further specify the event. In one embodiment, if no flags are defined for a specific event, the value of the flag field is set to 0. Also, some events may specify that some information be supplied to the callback routine when the event occurs. In one embodiment, if no special information is required from the host application, the host application must call with an empty ArgumentsBlock (see the description of the callback routine interface in section 3.3, below).

0720In one embodiment, if the name of an event in a callback parameter marked CRITICAL is not understood or not supported by the host application, the host application must consider this parameter as a not-understood CRITICAL parameter (and the action for which permission was requested must not be performed).

0721In one embodiment, the following event names are defined: <tables id="TABLE-US-00051" num="51"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="42PT" align="left" /><colspec colname="2" colwidth="42PT" align="left" /><colspec colname="3" colwidth="49PT" align="left" /><colspec colname="4" colwidth="126PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry /><entry>Event</entry><entry /></row><row><entry>Event Name</entry><entry>Event Flags</entry><entry>Parameter</entry><entry>Description</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row><row><entry>OnPlay</entry><entry>None</entry><entry>None</entry><entry>The host application must call back</entry></row><row><entry /><entry /><entry /><entry>when the multimedia object starts playing.</entry></row><row><entry>OnStop</entry><entry>None</entry><entry>None</entry><entry>The host application must call back</entry></row><row><entry /><entry /><entry /><entry>when the multimedia stops playing (or is</entry></row><row><entry /><entry /><entry /><entry>paused)</entry></row><row><entry>OnTimecode</entry><entry>None</entry><entry>Presentation</entry><entry>The host application must call back</entry></row><row><entry /><entry /><entry>time</entry><entry>when the specified presentation time has</entry></row><row><entry /><entry /><entry>expressed in</entry><entry>been reached or exceeded (during</entry></row><row><entry /><entry /><entry>number of</entry><entry>normal real-time playback or after a</entry></row><row><entry /><entry /><entry>seconds since</entry><entry>seek). The origin of the presentation</entry></row><row><entry /><entry /><entry>the start of</entry><entry>time is when the rendering begins. The</entry></row><row><entry /><entry /><entry>the</entry><entry>presentation time relates to the source</entry></row><row><entry /><entry /><entry>presentation</entry><entry>media time, not the wall-clock time</entry></row><row><entry /><entry /><entry /><entry>(e.g., when a presentation is paused, the</entry></row><row><entry /><entry /><entry /><entry>presentation time does not change).</entry></row><row><entry>OnSeek</entry><entry>None</entry><entry>None</entry><entry>The host application must call back</entry></row><row><entry /><entry /><entry /><entry>when a direct access to an arbitrary point</entry></row><row><entry /><entry /><entry /><entry>in a multimedia presentation occurs.</entry></row><row><entry /><entry /><entry /><entry>In one embodiment, when calling back,</entry></row><row><entry /><entry /><entry /><entry>the host application must provide the</entry></row><row><entry /><entry /><entry /><entry>following data in a ArgumentsBlock:</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="OFFSET" colwidth="133PT" align="left" /><colspec colname="1" colwidth="35PT" align="left" /><colspec colname="2" colwidth="35PT" align="left" /><colspec colname="3" colwidth="56PT" align="left" /><tbody valign="top"><row><entry /><entry>Type</entry><entry>Encoding</entry><entry>Description</entry></row><row><entry /><entry>32-bit</entry><entry>4 bytes in</entry><entry>Seek</entry></row><row><entry /><entry>unsigned</entry><entry>big-endian</entry><entry>position</entry></row><row><entry /><entry>integer</entry><entry>order</entry><entry>offset</entry></row><row><entry /><entry>32-bit</entry><entry>4 bytes in</entry><entry>Seek</entry></row><row><entry /><entry>unsigned</entry><entry>big-endian</entry><entry>position</entry></row><row><entry /><entry>integer</entry><entry>order</entry><entry>range</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="133PT" align="left" /><colspec colname="1" colwidth="126PT" align="left" /><tbody valign="top"><row><entry /><entry>The position within the multimedia</entry></row><row><entry /><entry>presentation is offset “marks” out of</entry></row><row><entry /><entry>range total “marks” in the presentation.</entry></row><row><entry /><entry>For instance, for a presentation that is</entry></row><row><entry /><entry>327 seconds long, seeking to the 60^th</entry></row><row><entry /><entry>second can be represented with</entry></row><row><entry /><entry>offset = 60, range = 327. It is up to the</entry></row><row><entry /><entry>caller to choose the unit that corresponds</entry></row><row><entry /><entry>to the measurement of the offset and</entry></row><row><entry /><entry>range (it could be a time unit, a byte-size</entry></row><row><entry /><entry>unit, or any other unit), provided that the</entry></row><row><entry /><entry>“marks” are homogeneously distributed</entry></row><row><entry /><entry>over the entire presentation. The value</entry></row><row><entry /><entry>of offset must be less than or equal to the</entry></row><row><entry /><entry>value of range.</entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

07221.29.3. Callback Routines

0723In one embodiment, callback routines take the same input:

0724Input: Top of stack: <tables id="TABLE-US-00052" num="52"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="70PT" align="left" /><colspec colname="1" colwidth="147PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Cookie</entry></row><row><entry /><entry>ArgumentsBlockSize</entry></row><row><entry /><entry>...data...</entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0725Cookie: the value of the Cookie field that was specified in the callback parameter.

0726ArgumentsBlockSize: number of bytes of data passed on the stack below this parameter. When the routine is called, the stack contains the value ArgumentsBlockSize supplied by the caller, indicating the size of the arguments block at the top, followed by ArgumentsBlockSize bytes of data. In one embodiment, if the size is not a multiple of 4, the data on the stack will be padded with 0-value bytes to ensure that the stack pointer remains a multiple of 4.

07271.29.3.1. CONTINUE Callbacks

0728In one embodiment, callbacks with the type CONTINUE (type ID=0) have the following output:

0729Output: Top of stack: <tables id="TABLE-US-00053" num="53"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="84PT" align="left" /><colspec colname="1" colwidth="133PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>ResultCode</entry></row><row><entry /><entry>...</entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0730ResultCode: an integer value. The result value is 0 if the routine was able to execute or a negative error code if an error occurred.

0731Description: if the ResultCode indicates that the callback routine was able to run (i.e., the value is 0), the host application can continue the current operation. If the ResultCode indicates that an error occurred, the host application aborts the current operation and cancels all pending callbacks and obligations.

07321.29.3.2. RESET Callbacks

0733When a control routine has specified one or more callbacks of type RESET in the ESB returned from a routine, the host application will call any specified callback routine when the condition for that callback is met. In one embodiment, as soon as the conditions of any of the callbacks are met, the host application needs to: <ul id="ul0015" list-style="none"><li id="ul0015-0001" num="0734"> Cancel all other pending callbacks </li><li id="ul0015-0002" num="0735"> Cancel all current obligations </li><li id="ul0015-0003" num="0736"> Provide the required parameters (if any) for that callback </li><li id="ul0015-0004" num="0737"> Call the specified callback routine. </li></ul>

0738The return status from the routine indicates to the host application if it can continue performing the current operation. In one embodiment, if the permission is denied or the routine fails to execute successfully, the host application must abort the performance of the current operation. Similarly, if the permission is granted, the host application must comply with any obligation or callback that may be returned in an ESB, just as if it had called the original Control.Actions.<Action>.Perform routine. Previous obligations or callback specifications are no longer valid.

0739In one embodiment, all routines specified as callback entry points for this type of callback have the following output:

0740Output: Top of stack: <tables id="TABLE-US-00054" num="54"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="77PT" align="left" /><colspec colname="1" colwidth="140PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>ResultCode</entry></row><row><entry /><entry>StatusBlockPointer</entry></row><row><entry /><entry>...</entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0741ResultCode: an integer value. The result value is 0 if the routine was able to execute, or a negative error code if an error occurred.

0742StatusBlockPointer: address of a standard ExtendedStatusBlock.

0743Description: the return semantics of this routine are equivalent to what is described for the Control.Actions.<Action>.Perform routine.

07441.30. Metadata Resources

0745In one embodiment, control objects can contain metadata resources, which can be referenced from the parameters returned in ExtendedStatusBlock data structures. Resources can be simple text, text templates, or other data types. Each resource is identified by a resource ID, and can contain one or more text strings or encoded data, one for each version in a different language. It is not required that resources be provided for all languages. It is up to the host application to choose which language version is most appropriate for its needs. <tables id="TABLE-US-00055" num="55"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="49PT" align="left" /><colspec colname="2" colwidth="56PT" align="left" /><colspec colname="3" colwidth="112PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Field</entry><entry>Type</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><tbody valign="top"><row><entry>Resource</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="49PT" align="left" /><colspec colname="2" colwidth="56PT" align="left" /><colspec colname="3" colwidth="112PT" align="left" /><tbody valign="top"><row><entry>Id</entry><entry>ASCII String</entry><entry>URI (typically a URN referring to</entry></row><row><entry /><entry /><entry>the Id of an Extension of the</entry></row><row><entry /><entry /><entry>Control object that contains the</entry></row><row><entry /><entry /><entry>code module with the routine that is</entry></row><row><entry /><entry /><entry>currently running)</entry></row><row><entry>Type</entry><entry>ASCII String</entry><entry>MIME-type of the resource data as</entry></row><row><entry /><entry /><entry>described in IETF RFC 2046</entry></row><row><entry>Data</entry><entry>List of</entry><entry>List of all the different versions of</entry></row><row><entry /><entry>LocalizedData</entry><entry>the resource, for different locales</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><tbody valign="top"><row><entry>LocalizedData</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="49PT" align="left" /><colspec colname="2" colwidth="56PT" align="left" /><colspec colname="3" colwidth="112PT" align="left" /><tbody valign="top"><row><entry>Language</entry><entry>ASCII String</entry><entry>Language code as specified in IETF</entry></row><row><entry /><entry /><entry>RFC 3066</entry></row><row><entry>Data</entry><entry>Type depends</entry><entry>The actual data for the resource</entry></row><row><entry /><entry>on the specified</entry><entry>(text, etc . . . )</entry></row><row><entry /><entry>mime type</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0746Resources accompany control programs by being included as Extensions in a Control object. The resource Id maps to the Id of an internal extension of the Control object that contains the code module with the routine that is currently running.

0747For the purpose of computing the canonical byte sequence for Resource objects, in one embodiment the data structure description is the following: <tables id="TABLE-US-00056" num="56"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="70PT" align="left" /><colspec colname="1" colwidth="147PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>class LocalizedData {</entry></row><row><entry /><entry>  string language</entry></row><row><entry /><entry>  byte[ ] data;</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry>class Resource {</entry></row><row><entry /><entry>  string id</entry></row><row><entry /><entry>  string type;</entry></row><row><entry /><entry>  LocalizedData data;</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

07481.30.1. Simple Text

0749Simple text is specified as MIME-type ‘text’

07501.30.2. Text Templates

0751In addition to the standard text resources, in one embodiment, a text template type is defined. The MIME-type for this is ‘text/vnd.intertrust.octopus-text-template’.

0752In one embodiment, a text template contains text characters encoded in UTF-8, as well as named placeholders that are to be replaced by text values obtained from parameters returned in the parameters list, such as that of an ExtendedStatusBlock. The syntax for a placeholder is ‘\PLACEHOLDER\’, where PLACEHOLDER specifies the name of a Parameter Block and an optional formatting hint. In one embodiment, the template processor must replace the entire token ‘\PLACEHOLDER\’ with the formateed representation of the Value field of that Parameter Block, and the formatting of the Value data is specified below in Section 4.2.1.

0753In one embodiment, if the character ‘\’ appears in the text outside of a placeholder, it must be encoded as ‘\\’, and all occurrences of ‘\\’ in the text will be reverted to ‘\’ by the template processor.

0754The syntax for the placeholder is: FORMAT|NAME, where NAME is the name of a Parameter Block, and FORMAT is the formatting hint to convert the parameter's data into text. If the default formatting rules for the parameter value's data type are sufficient, then the formatting hint can be omitted, and the placeholder is simply NAME.

07551.30.2.1. Formatting

07561.30.2.1.1. Default Formatting

0757In one embodiment, the default formatting rules for the different value types are: <tables id="TABLE-US-00057" num="57"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="63PT" align="left" /><colspec colname="2" colwidth="203PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row><row><entry>Type</entry><entry>Formatting</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Integer</entry><entry>Text representation of the integer value as a signed</entry></row><row><entry /><entry>decimal. The text is composed only of the characters for</entry></row><row><entry /><entry>the digits “0” to “9” and the character “—”. If the value is 0,</entry></row><row><entry /><entry>the text is the string “0”. If the value is not 0, the text does</entry></row><row><entry /><entry>not start with the character “0”. If the value is negative, the</entry></row><row><entry /><entry>text starts with the character “—”. If the value is positive, the</entry></row><row><entry /><entry>text starts with a non-zero digit character.</entry></row><row><entry>Real</entry><entry>Text representation of the floating point value in decimal.</entry></row><row><entry /><entry>The integral part of the value is represented using the same</entry></row><row><entry /><entry>rules as for Integer values. The decimal separator is</entry></row><row><entry /><entry>represented with the host application's preferred decimal</entry></row><row><entry /><entry>separator. The factional part of the value consists of up to 6</entry></row><row><entry /><entry>“0” characters followed by up to 3 non-zero digit</entry></row><row><entry /><entry>characters.</entry></row><row><entry>String</entry><entry>The string value itself</entry></row><row><entry>Date</entry><entry>A human readable representation of the date, according to</entry></row><row><entry /><entry>the host's preferred text representation of dates</entry></row><row><entry>Parameter</entry><entry>The text “<name>=<value>”, where <name> is the</entry></row><row><entry /><entry>parameter name, and <value> is the parameter value</entry></row><row><entry /><entry>formatted according to the default formatting rules for its type.</entry></row><row><entry>ExtendedParameter</entry><entry>Same as for Parameter</entry></row><row><entry>Resource</entry><entry>Text string of the resource's data. In one embodiment, the</entry></row><row><entry /><entry>resource referenced by the placeholder must have a MIMI-</entry></row><row><entry /><entry>type that is text-based (e.g., text or</entry></row><row><entry /><entry>text/vnd.intertrust.octopus-text-template).</entry></row><row><entry>ValueList</entry><entry>The text “<value>, <value>, . . . ” with all the values in the</entry></row><row><entry /><entry>list formatted according to the default formatting rules for their type.</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

07581.30.2.1.2. Explicit Formatting

0759Explicit format names can be used as the FORMAT part of a placeholder tag. If an unknown FORMAT name is encountered, the template processing engine will use the default formatting rules. <tables id="TABLE-US-00058" num="58"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="28PT" align="left" /><colspec colname="2" colwidth="189PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row><row><entry>Name</entry><entry>Formatting</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Hex</entry><entry>Hexadecimal representation of an integer value interpreted as</entry></row><row><entry /><entry>unsigned. In one embodiment, this formatting hint should be</entry></row><row><entry /><entry>ignored for data types that are not integers.</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

07601.31. Context Objects

0761In one embodiment, when a control routine is executing, it has access to a number of context objects through the use of the System.Host.GetObject system call.

07621.31.1. General Context

0763In one embodiment, the following context is present for running controls. <tables id="TABLE-US-00059" num="59"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="91PT" align="left" /><colspec colname="2" colwidth="49PT" align="left" /><colspec colname="3" colwidth="77PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Name</entry><entry>Type</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Octopus/Personality/Id</entry><entry>String</entry><entry>ID of the current</entry></row><row><entry /><entry /><entry>personality Node</entry></row><row><entry>Octopus/Personality/Attributes</entry><entry>Container of</entry><entry>Attributes of the current</entry></row><row><entry /><entry>Attributes</entry><entry>personality Node</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

07641.31.2. Runtime Context

0765In one embodiment, the following context is present for all controls that are running in a VM that has been created using the System.Host.SpawnVm system call. In one embodiment, this context must be non-existent or an empty container for controls that are running in a VM that was not created using System.Host.SpawnVm. <tables id="TABLE-US-00060" num="60"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="84PT" align="left" /><colspec colname="2" colwidth="42PT" align="left" /><colspec colname="3" colwidth="91PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Name</entry><entry>Type</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Octopus/Runtime/Parent/Id</entry><entry>Container</entry><entry>The identity under which the</entry></row><row><entry /><entry>of</entry><entry>caller of the system call is</entry></row><row><entry /><entry>unnamed</entry><entry>running.</entry></row><row><entry /><entry>String</entry></row><row><entry /><entry>objects</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

07661.31.3. Control Context

0767In one embodiment, the following context is present whenever a routine of a control is running: <tables id="TABLE-US-00061" num="61"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="84PT" align="left" /><colspec colname="2" colwidth="35PT" align="left" /><colspec colname="3" colwidth="98PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Name</entry><entry>Type</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Octopus/Control/Id</entry><entry>String</entry><entry>Id of the running control</entry></row><row><entry>Octopus/Control/Attributes</entry><entry>Container</entry><entry>Attributes of the running control.</entry></row><row><entry /><entry /><entry>This object may be omitted if</entry></row><row><entry /><entry /><entry>the control has no attributes.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

07681.31.4. Controller Context

0769In one embodiment, the following context is present whenever a routine of a control is running and the control was pointed to by a controller object (e.g., when accessing a ContentKey object in order to consume protected content). <tables id="TABLE-US-00062" num="62"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="70PT" align="left" /><colspec colname="2" colwidth="35PT" align="left" /><colspec colname="3" colwidth="112PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Name</entry><entry>Type</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Octopus/Controller/Id</entry><entry>String</entry><entry>Id of the Controller that points to the</entry></row><row><entry /><entry /><entry>currently running control</entry></row><row><entry>Octopus/Controller/</entry><entry>Container</entry><entry>Attributes of the Controller pointing</entry></row><row><entry>Attributes</entry><entry /><entry>to the currently running control. This</entry></row><row><entry /><entry /><entry>object may be omitted if the</entry></row><row><entry /><entry /><entry>controller has no attributes.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0770In embodiments where a host application is allowed to only group content keys that are controlled by a single controller object, for a given action, there will be only one applicable controller object.

07711.31.5. Action Context

0772In one embodiment, the following context is present whenever a control is called for the purpose of controlling an Action. <tables id="TABLE-US-00063" num="63"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="56PT" align="left" /><colspec colname="2" colwidth="42PT" align="left" /><colspec colname="3" colwidth="119PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Name</entry><entry>Type</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Octopus/Action/</entry><entry>Container</entry><entry>Array of Name/Value pairs</entry></row><row><entry>Parameters</entry><entry /><entry>representing the parameters that are</entry></row><row><entry /><entry /><entry>relevant for the current action, if any.</entry></row><row><entry /><entry /><entry>In one embodiment, each action type</entry></row><row><entry /><entry /><entry>defines a list of optional and required</entry></row><row><entry /><entry /><entry>parameters. This container may be</entry></row><row><entry /><entry /><entry>omitted if the action has no parameters.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

07731.31.6. Link Context

0774In one embodiment, the following context is present whenever a control is called for the purpose of limiting the validity of a link object (e.g., a control object embedded in a link object): <tables id="TABLE-US-00064" num="64"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="56PT" align="left" /><colspec colname="2" colwidth="35PT" align="left" /><colspec colname="3" colwidth="126PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Name</entry><entry>Type</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Octopus/Link/Id</entry><entry>String</entry><entry>Id of the Link object</entry></row><row><entry>Octopus/Link/</entry><entry>Container</entry><entry>Attributes of the Link object that contains</entry></row><row><entry>Attributes</entry><entry /><entry>the running control. This object may be</entry></row><row><entry /><entry /><entry>omitted if the link has no attributes.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

07751.31.7. Agent Context

0776In one embodiment, the following context is present when an agent routine of a control is running: <tables id="TABLE-US-00065" num="65"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="84PT" align="left" /><colspec colname="2" colwidth="35PT" align="left" /><colspec colname="3" colwidth="98PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Name</entry><entry>Type</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Octopus/Agent/Parameters</entry><entry>Container</entry><entry>Array of Name/Value parameter</entry></row><row><entry /><entry /><entry>pairs representing the input</entry></row><row><entry /><entry /><entry>parameters for the agent.</entry></row><row><entry>Octopus/Agent/Session/</entry><entry>String</entry><entry>Identifier for the session context</entry></row><row><entry>ContextId</entry><entry /><entry>in which the agent is running.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0777The Parameter and Session containers are normally used to allow the protocols that require one entity to send and run an agent on another entity to specify which input parameters to pass to the agent, and which session context objects the host needs to set under certain conditions. The presence or absence of certain session context objects may allow the agent code to decide whether it is running as part of the protocol it was designed to support, or if it is running out of context, in which case it may refuse to run. For example, an agent whose purpose is to create a state object on the host on which it runs may refuse to run unless it is being executed during a specific protocol interaction.

07781.32. Actions

0779In one embodiment, each action has a name and a list of parameters. In one embodiment, some parameters are required—the application must provide them when performing this action—and some are optional—the application may provide them or may omit them.

0780In one embodiment, the following standard actions are defined:

07811.32.1. Play

0782Description: Normal real-time playback of the multimedia content.

07831.32.2. Transfer

0784Description: Transfer to a compatible target system.

0785Transferring to a compatible target system is used when the content has to be made available to a system with the same DRM technology, such that the target system can use the same license as the one that contains this control, but state information may need to be changed on the source, the sink, or both. The system from which the transfer is being done is called the source. The target system to which the transfer is being done is called the sink.

0786This action is intended to be used in conjunction with a service protocol that allows an Agent to be transferred from the source to the sink in order to do the necessary updates in the source's and sink's persistent states (e.g., objects in the state database described herein). In one embodiment, a control uses the RunAgentOnPeer obligation for that purpose. Additional information about illustrative embodiments of this service protocol are provided below in connection with the discussion of the state database.

0787Parameters: <tables id="TABLE-US-00066" num="66"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="49PT" align="left" /><colspec colname="2" colwidth="35PT" align="left" /><colspec colname="3" colwidth="175PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Name</entry><entry>Type</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Sink/Id</entry><entry>String</entry><entry>Node Id of the Sink</entry></row><row><entry>Sink/Attributes</entry><entry>Container</entry><entry>Attributes of the Sink's node. This container may be</entry></row><row><entry /><entry /><entry>omitted if the node has no attributes.</entry></row><row><entry>TransferMode</entry><entry>String</entry><entry>Transfer Mode ID indicating in which mode the content is</entry></row><row><entry /><entry /><entry>being transferred. This ID can be a standard mode as</entry></row><row><entry /><entry /><entry>defined below, or a URN for a system proprietary mode.</entry></row><row><entry /><entry /><entry>In one embodiment, the following standard modes are</entry></row><row><entry /><entry /><entry>defined:</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="84PT" align="left" /><colspec colname="1" colwidth="35PT" align="left" /><colspec colname="2" colwidth="140PT" align="left" /><tbody valign="top"><row><entry /><entry>ID</entry><entry>Description</entry></row><row><entry /><entry>Render</entry><entry>The sink is receiving the content for the</entry></row><row><entry /><entry /><entry>purpose of rendering</entry></row><row><entry /><entry>Copy</entry><entry>The sink is receiving a copy of the content</entry></row><row><entry /><entry>Move</entry><entry>The content is being moved to the sink.</entry></row><row><entry /><entry>CheckOut</entry><entry>The content is being checked-out to the</entry></row><row><entry /><entry /><entry>sink. This is similar to Move but with the</entry></row><row><entry /><entry /><entry>distinction that the resulting state on the</entry></row><row><entry /><entry /><entry>sink may prevent any other move than a</entry></row><row><entry /><entry /><entry>move back to the source.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="49PT" align="left" /><colspec colname="2" colwidth="35PT" align="left" /><colspec colname="3" colwidth="175PT" align="left" /><tbody valign="top"><row><entry>TransferCount</entry><entry>Integer</entry><entry>Integer value indicating how many instances of the state</entry></row><row><entry /><entry /><entry>counters associated with this control need to be transferred</entry></row><row><entry /><entry /><entry>to the sink.</entry></row><row><entry /><entry /><entry>In one embodiment, this parameter is optional. If it is not</entry></row><row><entry /><entry /><entry>present, only one instance is being transferred. It should not</entry></row><row><entry /><entry /><entry>be present when the transfer mode is Render or Copy.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

07881.32.3. Export

0789Description: Export to a foreign target system.

0790Exporting to a foreign target system is an action that is used when the content has to be exported to a system where the original content license cannot be used. This could be a system with a different DRM technology; a system with no DRM technology, or a system with the same technology but under a situation that requires a license different from the original license. The system from which the transfer is being done is called the source. The target system to which the transfer is being done is called the sink.

0791In one embodiment, in the Extended Status result for the Describe, Check, and Perform methods of this action, the following parameter shall be set: <tables id="TABLE-US-00067" num="67"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="35PT" align="left" /><colspec colname="2" colwidth="21PT" align="left" /><colspec colname="3" colwidth="161PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Name</entry><entry>Type</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>ExportInfo</entry><entry>Any</entry><entry>Information that is relevant when exporting content to</entry></row><row><entry /><entry /><entry>the target system specified in the action parameters.</entry></row><row><entry /><entry /><entry>The actual type and content of this information is</entry></row><row><entry /><entry /><entry>specific to each target system. For example, for</entry></row><row><entry /><entry /><entry>CCI-based systems, this would contain the CCI bits</entry></row><row><entry /><entry /><entry>to set for the exported content.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0792Parameters: <tables id="TABLE-US-00068" num="68"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="49PT" align="left" /><colspec colname="2" colwidth="28PT" align="left" /><colspec colname="3" colwidth="182PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Name</entry><entry>Type</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>TargetSystem</entry><entry>String</entry><entry>System ID of the foreign system to which the export is being</entry></row><row><entry /><entry /><entry>made. This ID is a URN.</entry></row><row><entry>ExportMode</entry><entry>String</entry><entry>Export Mode ID indicating in which mode the content is</entry></row><row><entry /><entry /><entry>being exported. This ID can be a standard mode as</entry></row><row><entry /><entry /><entry>defined below, or a URN for a system proprietary mode.</entry></row><row><entry /><entry /><entry>In one embodiment, the following standard modes are defined:</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="77PT" align="left" /><colspec colname="1" colwidth="42PT" align="left" /><colspec colname="2" colwidth="140PT" align="left" /><tbody valign="top"><row><entry /><entry>ID</entry><entry>Description</entry></row><row><entry /><entry>DontKnow</entry><entry>The caller does not know what the sink's</entry></row><row><entry /><entry /><entry>intended mode is. In this case, the control</entry></row><row><entry /><entry /><entry>program should assume that any of the</entry></row><row><entry /><entry /><entry>allowed modes for the TargetSystem can</entry></row><row><entry /><entry /><entry>be assumed by the sink, and should</entry></row><row><entry /><entry /><entry>indicate any restriction in the return</entry></row><row><entry /><entry /><entry>status of the action routines. For</entry></row><row><entry /><entry /><entry>example, for a CCI-based system, the</entry></row><row><entry /><entry /><entry>control can return CCI bits that will</entry></row><row><entry /><entry /><entry>either allow the equivalent of Render or</entry></row><row><entry /><entry /><entry>Copy depending on what the license</entry></row><row><entry /><entry /><entry>permits.</entry></row><row><entry /><entry>Render</entry><entry>The sink is receiving the content for the</entry></row><row><entry /><entry /><entry>purpose of rendering, and will not retain</entry></row><row><entry /><entry /><entry>a usable copy of the content except for</entry></row><row><entry /><entry /><entry>caching purposes as specified by each</entry></row><row><entry /><entry /><entry>target system</entry></row><row><entry /><entry>Copy</entry><entry>The sink is receiving a copy of the</entry></row><row><entry /><entry /><entry>content</entry></row><row><entry /><entry>Move</entry><entry>The content is being moved to the sink.</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0793Other input parameters may be required by specific target systems.

07941.32.3.1. Standard Target Systems

07951.32.3.1.1. Audio CD or DVD

0796In one embodiment, the standard TargetSystem ID ‘CleartextPcmAudio’ is used when the target system is an unencrypted medium onto which uncompressed PCM audio is written, such as a writeable audio CD or DVD. For this target system, the ExportInfo parameter is a single Integer parameter representing a copyright flag. This flag is indicated in the least significant bit of the integer value. <tables id="TABLE-US-00069" num="69"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="42PT" align="left" /><colspec colname="2" colwidth="175PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row><row><entry>Bit index</entry><entry>Description</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>0 (LSB)</entry><entry>When this flag is set, the Copyright bit or flag must be set</entry></row><row><entry /><entry>in the format of the recoded audio if the format supports the</entry></row><row><entry /><entry>signaling of such a bit or flag.</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> 10. State Database

0797A secure object store that can be used by preferred embodiments of a DRM engine to provide a secure state storage mechanism is described below. Such a facility is useful to enable control programs to be able to read and write in a protected state database that is persistent from invocation to invocation. Such a state database can be used to store state objects such as play-counts, date of first use, accumulated rendering times, and/or the like. In a preferred embodiment, the secure database is implemented in non-volatile memory, such as flash memory on a portable device, or an encrypted area of the hard disk drive on a PC. It will be appreciated, however, that the secure database could implemented on any suitable medium.

0798The term “object”, as used in this section, generally refers to the data objects contained within the secure object store, and not to the objects (e.g., controls, controllers, links, etc.) discussed elsewhere herein; if necessary to distinguish between these two categories of objects, the term “DRM object” will be used to refer to the objects described elsewhere herein (i.e., controls, controllers, protectors, ContentKeys, links, nodes, and the like), while the term “state object” will be used to refer to the objects stored within the state database. In the following discussion, reference will occasionally be made to an illustrative implementation of the state database, called “Seashell,” which is used in connection with the Octopus DRM engine embodiment described elsewhere herein. It will be appreciated; however, that embodiments of the systems and methods described herein can be practiced without some or all of the features of this illustrative implementation.

07991.33. Database Objects

0800The object store (e.g., a database) contains data objects. In one embodiment, objects are arranged in a logical hierarchy, where container objects are parents of their contained children objects. In one embodiment, there are four types of objects: string, integer, byte array, and container. Each object has associated metadata and a type. Depending on its type, an object can also have a value.

0801In one embodiment, state objects can be accessed from virtual machine programs using the System.Host.GetObject and System.Host.SetObject system calls, and, as described in more detail below, object metadata can be accessed using virtual names. In one embodiment, some of the metadata fields can be changed by clients of the database (i.e., they are read-write (RW) accessible), while other metadata fields are read-only (RO).

0802In one embodiment, the metadata fields shown in the following table are defined: <tables id="TABLE-US-00070" num="70"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="56PT" align="left" /><colspec colname="2" colwidth="35PT" align="left" /><colspec colname="3" colwidth="42PT" align="left" /><colspec colname="4" colwidth="126PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row><row><entry>Field</entry><entry>Type</entry><entry>Accessibility</entry><entry>Description</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Name</entry><entry>String</entry><entry>RO</entry><entry>Name of the object. In one</entry></row><row><entry /><entry /><entry /><entry>embodiment only the following</entry></row><row><entry /><entry /><entry /><entry>characters are allowed as object</entry></row><row><entry /><entry /><entry /><entry>names (all the other ones are</entry></row><row><entry /><entry /><entry /><entry>reserved): a-z, A-Z, 0-9, ‘_’, ‘-’,</entry></row><row><entry /><entry /><entry /><entry>‘+’, ‘:’, ‘.’, ‘$’, ‘!’, ‘*’, ‘ ’</entry></row><row><entry>Owner</entry><entry>String</entry><entry>RW</entry><entry>Id of the owner of that object</entry></row><row><entry>CreationDate</entry><entry>Unsigned</entry><entry>RO</entry><entry>Time at which the object was</entry></row><row><entry /><entry>32-bit</entry><entry /><entry>created, expressed as the number</entry></row><row><entry /><entry>integer</entry><entry /><entry>of minutes elapsed since Jan. 1,</entry></row><row><entry /><entry /><entry /><entry>1970 00:00:00 local time.</entry></row><row><entry>ModificationDate</entry><entry>Unsigned</entry><entry>RO</entry><entry>Time at which the object was last</entry></row><row><entry /><entry>32-bit</entry><entry /><entry>modified, expressed as the number</entry></row><row><entry /><entry>integer</entry><entry /><entry>of minutes elapsed since Jan. 1,</entry></row><row><entry /><entry /><entry /><entry>1970 00:00:00 local time.</entry></row><row><entry /><entry /><entry /><entry>For container objects, this is the</entry></row><row><entry /><entry /><entry /><entry>time at which a child was last</entry></row><row><entry /><entry /><entry /><entry>added to or removed from the</entry></row><row><entry /><entry /><entry /><entry>container. For other objects, this is</entry></row><row><entry /><entry /><entry /><entry>the time at which their value was</entry></row><row><entry /><entry /><entry /><entry>last changed.</entry></row><row><entry>ExpirationDate</entry><entry>Unsigned</entry><entry>RW</entry><entry>Time at which the object expires,</entry></row><row><entry /><entry>32-bit</entry><entry /><entry>expressed as the number of</entry></row><row><entry /><entry>integer</entry><entry /><entry>minutes elapsed since Jan. 1, 1970</entry></row><row><entry /><entry /><entry /><entry>00:00:00 local time. A value of 0</entry></row><row><entry /><entry /><entry /><entry>means the object does not expire.</entry></row><row><entry>Flags</entry><entry>32-bit bit</entry><entry>RW</entry><entry>Set of boolean flags indicating properties</entry></row><row><entry /><entry>field</entry><entry /><entry>of the object.</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0803In one embodiment, the metadata flag shown in the following table is defined: <tables id="TABLE-US-00071" num="71"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="42PT" align="left" /><colspec colname="2" colwidth="56PT" align="left" /><colspec colname="3" colwidth="119PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Bit index</entry><entry>Name</entry><entry>Meaning</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>0 (LSB)</entry><entry>PUBLIC_READ</entry><entry>If set, indicates that the access control</entry></row><row><entry /><entry /><entry>for this object is such that any client can</entry></row><row><entry /><entry /><entry>read the object and its metadata.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0804As previously indicated, in one embodiment there are four types of state objects: strings, integers, byte arrays, and container. In this embodiment, the value of a string object is a UTF-8 encoded character string, the value an integer object is a 32-bit integer value, and the value of a byte array object is an array of bytes. In this embodiment, a container object contains zero or more objects. A container object is referred to as the parent of the objects it contains. The contained objects are referred to as the children of the container. All the container objects that make up the chain of an object's parent, the parent's parent, and so on, are called the object's ancestors. If an object has another object as it ancestor, that object is called a descendant of the ancestor object.

08051.34. Object Lifetime

0806In one embodiment, the lifetime of objects in the state database follows a number of rules. Objects can be explicitly destroyed, or implicitly destroyed. Objects can also be destroyed as the result of a database garbage collection. Regardless of how an object is destroyed, in one embodiment the following rules apply: <ul id="ul0016" list-style="none"><li id="ul0016-0001" num="0807"> The ModificationDate for the parent container of that object is set to current local time. </li><li id="ul0016-0002" num="0808"> If the object is a container, all its children are destroyed when the object is destroyed. </li></ul>

08091.34.1. Explicit Object Destruction

0810Explicit object destruction happens when a client of the database requests that an object be removed (see Object Access for more details on how this can be done using the Host.SetObject system call).

08111.34.2. Implicit Object Destruction

0812Implicit object destruction happens when an object is being destroyed as the result of one of the objects in its ancestry being destroyed.

08131.34.3. Garbage Collection

0814In one embodiment, the state database destroys any object that has expired. An object is considered to have expired when the local time on the system that implements the database is later than the ExpirationDate field of the object's metadata. An implementation may periodically scan the database for expired objects and destroy them, or it may wait until an object is accessed to check its expiration date. In one embodiment, an implementation must not return to a client an expired object. In one embodiment, when a container object is destroyed (e.g., because it has expired), its children objects are also destroyed (and all their descendants, recursively) even if they have not expired yet.

08151.35. Object Access

0816In one embodiment, the objects in the state database can be accessed from virtual machine programs through a pair of system calls: System.Host.GetObject to read the value of an object, and System.Host.SetObject to create, destroy, or set the value of an object.

0817In one embodiment, to be visible as a tree of host objects, the state database is “mounted” under a certain name in the host object tree. This way, the database is visible as a sub-tree in the more general tree of host objects. To achieve this, in one embodiment the state database contains a top-level, built-in root container object that always exists. This root container is essentially the name of the database. All other objects in the database are descendants of the root container. Multiple state databases can be mounted at different places in the host object tree (for two databases to be mounted under the same host container, they need to have different names for their root container). For example, if a state database whose root container is named Database<b>1</b>, contains a single integer child object named Child<b>1</b>, the database could be mounted under the host object container “/SeaShell”, in which case the Child<b>1</b> object would be visible as “/SeaShell/Database<b>1</b>/Child<b>1</b>”. In one embodiment, accesses to objects in the state database are governed by an access policy.

08181.35.1. Reading Objects

0819The value of an object can be read by using the system call System.Host.GetObject. In one embodiment of the state database, the four object types (integer, string, byte array, and container) that can exist in the database map directly onto their counterparts in the virtual machine. The object values can be accessed in the normal way, and the standard virtual names can be implemented.

08201.35.2. Creating objects

0821Objects can be created calling System.Host.SetObject for an object name that does not already exist. The object creation is done according to the system call specification. In one embodiment, when an object is created, the state database does the following: <ul id="ul0017" list-style="none"><li id="ul0017-0001" num="0822"> Sets the “owner” field of the object metadata to the value of the “owner” field of the parent container object's metadata. </li><li id="ul0017-0002" num="0823"> Sets the CreationDate field of the metadata to the current local time. </li><li id="ul0017-0003" num="0824"> Sets the ModificationDate field of the metadata to the current local time. </li><li id="ul0017-0004" num="0825"> Sets the ExpirationDate field of the metadata to 0 (does not expire). </li><li id="ul0017-0005" num="0826"> Sets the Flags field of the metadata to 0. </li><li id="ul0017-0006" num="0827"> Sets the ModificationDate of the parent container to the current local time. </li></ul>

0828When creating an object under a path deeper than the existing container hierarchy, in one embodiment the state database implicitly creates the container objects that need to exist to create a path to the object being created. In one embodiment, implicit container object creation follows the same rules as an explicit creation. For example, if there is a container “A” with no children, a request to set “A/B/C/SomeObject” will implicitly create containers “A/B” and “A/B/C” before creating “A/B/C/SomeObject”.

08291.35.3. Writing Objects

0830The value of objects can be changed by calling System.Host.SetObject for an object that already exists. If the specified ObjectType does not match the type ID of the existing object, ERROR_INVALID_PARAMETER is returned. In one embodiment, if the type ID is OBJECT_TYPE_CONTAINER, no value needs to be specified (the ObjectAddress must be non-zero, but its value will be ignored). When an existing object is set, the state database sets the ModificationDate of object to the current local time.

08311.35.4. Destroying Objects

0832Objects can be explicitly destroyed by calling System.Host.SetObject for an object that already exists, with an ObjectAddress value of 0. When an object is destroyed, the state database preferably: <ul id="ul0018" list-style="none"><li id="ul0018-0001" num="0000"><ul id="ul0019" list-style="none"><li id="ul0019-0001" num="0833"> Sets the ModificationDate of the parent container to the current local time. </li><li id="ul0019-0002" num="0834"> Destroys all its child objects if the destroyed object is a container. </li></ul></li></ul>

08351.35.5. Object Metadata

0836In one embodiment, the metadata for state database objects is accessed by using the System.Host.GetObject and System.Host.SetObject system calls with virtual names. The following table lists the standard and extended virtual names that are available for objects in one embodiment of the state database, and how they map to the metadata fields. <tables id="TABLE-US-00072" num="72"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="70PT" align="left" /><colspec colname="2" colwidth="49PT" align="left" /><colspec colname="3" colwidth="98PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Virtual Name</entry><entry>Type</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>@Name</entry><entry>String</entry><entry>The Name field of the object</entry></row><row><entry /><entry /><entry>metada</entry></row><row><entry>@Owner</entry><entry>String</entry><entry>The Owner field of the</entry></row><row><entry /><entry /><entry>object metadata</entry></row><row><entry>@CreationDate</entry><entry>32-bit unsigned</entry><entry>The CreationDate field of the</entry></row><row><entry /><entry>integer</entry><entry>object metadata</entry></row><row><entry>@ModificationDate</entry><entry>32-bit unsigned</entry><entry>The ModificationDate field</entry></row><row><entry /><entry>integer</entry><entry>of the object metadata</entry></row><row><entry>@ExpirationDate</entry><entry>32-bit unsigned</entry><entry>The ExpirationDate field of</entry></row><row><entry /><entry>integer</entry><entry>the object metadata</entry></row><row><entry>@Flags</entry><entry>32-bit bit field</entry><entry>The Flags field of the object</entry></row><row><entry /><entry /><entry>metadata</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0837In one embodiment, an implementation must refuse a request to set the Flags metadata field if one or more undefined flags are set to 1. In this case, the return value for the System.Host.SetObject is ERROR_INVALID_PARAMETER. In one embodiment, when reading the Flags metadata field, a client must ignore any flag that is not predefined, and when setting the Flags field of an object, a client must first read its existing value and preserve the value of any flag that is not predefined (e.g., in a system specification).

08381.36. Object Ownership and Access Control

0839In one embodiment, whenever a request is made to read, write, create, or destroy an object, the state database implementation first checks whether the caller has the permission to perform the request. The policy that governs access to objects is based on the concepts of principal identities and delegation. In order for the policy to be implemented, the trust model under which the implementation operates needs to support the notion of authenticated control programs. This is typically done by having the virtual machine code module that contains the program be digitally signed (directly or indirectly through a secure reference) with the private key of a PKI key pair, and having a name certificate that associates a principal name with the signing key; however, it will be appreciated that different ways of determining control program identities are possible, any sutiable one of which could be used.

0840In one embodiment, the access policy for the objects in the state database is comprised of a few simple rules: <ul id="ul0020" list-style="none"><li id="ul0020-0001" num="0841"> Read access to an object's value is granted if the caller's identity is the same as the owner of the object or if the PUBLIC_READ flag is set in the object's Flags metadata field. </li><li id="ul0020-0002" num="0842"> Read access to an object's value is granted if the caller has Read access to the object's parent container. </li><li id="ul0020-0003" num="0843"> Write access to an object's value is granted if the caller's identity is the same as the owner of the object. </li><li id="ul0020-0004" num="0844"> Write access to an object's value is granted if the caller has Write access to the object's parent container. </li><li id="ul0020-0005" num="0845"> Create or Destroy access to an object is granted if the caller has Write access to the parent container of the object. </li><li id="ul0020-0006" num="0846"> Read and Write access to an object's metadata (using virtual names) follows the same policy as Read and Write access to the object's value, with the additional restriction that read-only fields cannot be written to. </li></ul>

0847In one embodiment, when the access policy denies a client's request, the return value of the system call for the request is ERROR_PERMISSION_DENIED.

0848The root container of the state database is preferably fixed when the database is created. When an object is created, the value of its Owner metadata field is set to the same value as that of its parent container Owner metadata field. Ownership of an object can change. To change the ownership of an object, the value of the Owner metadata field can be set by calling the Sytem.Host.SetObject system call for the ‘@Owner’ virtual name of that object, provided that it is permitted under the access control rules.

0849In embodiments where it is not possible for a control program to access objects that are not owned by the same principal as the one whose identity it is running under, a control program needs to delegate access to “foreign” objects to programs loaded from code modules that have the ability to run under the identity of the owner of the “foreign” object. To do this, a control program may use the System.Host.SpawnVm, System.Host.CallVm, and System.Host.ReleaseVm system calls in the control virtual machine.

08501.37. License Transfer Protocol

0851The storage of state information in a database such as that described above enables rights to be moved between devices or exported from a domain (e.g., by transferring the state information to another device). The following section describes embodiments of protocols by which the state of a database can be transferred from a source to a sink. Note that although this process will be referred to as a license transfer protocol, it is the state of the state database that is being transferred, as opposed to merely an actual license (e.g., a control object, etc.). The protocol is referred to as a license transfer protocol because, in one embodiment, the transfer is initiated by execution of a transfer action in a control program, and because transfer of the state information enables the sink to successfully execute the relevant license for a piece of content.

0852<figref idref="DRAWINGS">FIG. 32</figref> shows an example of a license transfer <b>3200</b> composed of three messages <b>3202</b>, <b>3204</b>, <b>3206</b>. In the example shown in <figref idref="DRAWINGS">FIG. 32</figref>, the protocol is initiated by sink <b>3210</b> by sending a request <b>3202</b> to source <b>3212</b>. In one embodiment, request <b>3202</b> holds the ID of a piece of content to be transferred. Source <b>3212</b> sends a response <b>3204</b> to sink <b>3210</b>, containing (i) an agent that will set a state in the state database of sink <b>3210</b>, as well as (ii) the ContentKey object(s) targeted to the sink <b>3210</b>. As shown in <figref idref="DRAWINGS">FIG. 32</figref> sink <b>3210</b> sends the source <b>3212</b> a confirmation <b>3206</b> that the agent has run. Upon receiving the Content Key(s) and/or the piece of content, the sink may then use the content (e.g., play it through speakers, display it on a video screen, and/or render it in some other manner) in accordance with its associated controls.

0853While the approach shown in <figref idref="DRAWINGS">FIG. 32</figref> can be used in some embodiments, some potential problems include:

0854There is no way to proactively tell the source that rendering is over. In one embodiment, the protocol shown in <figref idref="DRAWINGS">FIG. 32</figref> supports two modes where this is a problem: (i) render (no stop render), and (ii) checkout (no check-in). Because of this problem, control issuers may be led to issue timeouts on the states that are transferred. However, this can result in a bad consumer experience when, for example, a user wants to render content on one device but decides that she actually wants to render this content on another one: with the current design, it is likely that she will have to wait for the entire piece of content to be rendered on the first device before she is able to render it on the other device. This might be undesirable if the content is relatively long (e.g., a movie).

0855It can be difficult to resolve the license associated with the Content IDs in the request. In one embodiment, the request contains only the Content IDs, and the source retrieves the license associated with the Content IDs from its license database. However, this process can be prone to error, since the licenses may be stored on a removable media, and at the time of engagement of the protocol, a particular license may not be available if the media has been removed. Moreover, even if the licenses are available, it can be cumbersome to perform a lookup for the licenses in the license store. Also, because there can be multiple licenses associated with-a set of Content IDs, it may be difficult to determine if the resolved license is the same as the one that was intended in the request.

0856There is no way for the Control program to proactively ask for a proximity check. In one embodiment, the set of system calls/callbacks/obligations does not support a way for a Control to ask for proximity checking of a peer. Instead, a control can only read a value of a host object Octopus/Action/Parameters/Sink/Proximity/LastProbe that is populated by the application during a transfer with a value it got from a previous execution of a proximity checking protocol. This can be a problem in the case where it may be desirable to avoid a proximity check if such a proximity check is not needed (e.g., if the sink is known to be within a certain domain).

0857There are only three rounds to the protocol. In the embodiment shown in <figref idref="DRAWINGS">FIG. 32</figref>, the protocol is limited to three rounds. This can be a serious limitation, since the the protocol will be unable to handle the case where the OnAgentCompletion callback returns an extended status block with another RunAgentOnPeer obligation. Moreover, after the protocol is finished, the sink will not really know if the protocol has succeeded or not. In addition, the proximity check will need to occur before the response is sent (see previous problem) but this is not needed in the case where the source and the sink are in the same domain. In addition, in the protocol shown in <figref idref="DRAWINGS">FIG. 32</figref>, the source gives the content key to the sink without knowing if this content key will ever be used.

0858No way in the ESB to hint that a License Transfer is needed. In the embodiment shown in <figref idref="DRAWINGS">FIG. 32</figref>, when a DRM Client evaluates a license (e.g. Control.Actions.Play.Check), there is no easy way for the control writer to hint that a license transfer is needed in order to get the state that will enable a successful evaluation of the control.

0859The source cannot initiate the transfer. In the protocol shown in <figref idref="DRAWINGS">FIG. 32</figref>, the license transfer is initiated by the sink. It would be desirable for the source to be able to initiate the transfer as well.

0860Improved Embodiments

0861The embodiments described below can solve or ameliorate some or all of the problems described above.

0862Solution for the release problem. In one embodiment, a new release operation is introduced. When this operation is specified in the request, the Transfer Mode ID is set to Release. In order, for the client to do the correlation between a render/checkout and a release operation, an optional element SessionId is added to the request (see section below). In one embodiment, when this element is present, it is reflected in the host object tree of the Transfer Action context under SessionId.

0863The sink knows that it has to send this SessionId in the release request if the Extended Status Block it will get in the Teardown message (see below) contains a parameter:

0864Parameter Name: SessionId

0865Parameter Type: String

0866The flag of this parameter is set to CRITICAL.

0867Solution for the license resolution problem (refactoring the request). In one embodiment, the solution consists of having the sink device put the license bundle(s) in the request so that there is essentially a guarantee that the sink and the source will execute the same license. In the embodiment shown in <figref idref="DRAWINGS">FIG. 32</figref>, the XML schema for the request is the following: <tables id="TABLE-US-00073" num="73"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="203PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry><xs:complexType name=“LicenseTransferRequestPayloadType”></entry></row><row><entry /><entry>  <xs:sequence></entry></row><row><entry /><entry>    <xs:element ref=“ContentIdList”/></entry></row><row><entry /><entry>    <xs:element ref=“Operation”/></entry></row><row><entry /><entry>    <xs:element ref=“oct:Bundle”/></entry></row><row><entry /><entry>  </xs:sequence></entry></row><row><entry /><entry></xs:complexType></entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0868Where the ContentIdList contains the list of Content IDs (one per track/stream) identifying the content, the Operation contains the type of license transfer operation, and the Bundle contains the Personality node of the requestor and the associated signature.

0869To avoid the license resolution problem described above, the license bundle(s) can be included in the request, e.g., by amending the schema as follows: <tables id="TABLE-US-00074" num="74"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry><!--new elements →</entry></row><row><entry><xs:element name=“LicensePart” type=“LicensePartType”/></entry></row><row><entry><xs:complexType name=“LicensePartType”></entry></row><row><entry> <xs:sequence></entry></row><row><entry>  <xs:element ref=“oct:Bundle” minOccurs=”0”/></entry></row><row><entry> </xs:sequence></entry></row><row><entry> <xs:attribute name=“contentId” use=“optional”/></entry></row><row><entry></xs:complexType></entry></row><row><entry><xs:element name=“License” type=“LicenseType”/></entry></row><row><entry><xs:complexType name=“LicenseType”></entry></row><row><entry> <xs:sequence></entry></row><row><entry>  <xs:element ref=“LicensePart” maxOccurs=“unbounded”/></entry></row><row><entry> </xs:sequence></entry></row><row><entry></xs:complexType></entry></row><row><entry><!-- modified LicenseTransferRequestPayloadType --></entry></row><row><entry><xs:complexType name=“LicenseTransferRequestPayloadType”></entry></row><row><entry> <xs:sequence></entry></row><row><entry>  <xs:element ref=“License”/> <!-- see above for definition --></entry></row><row><entry>  <xs:element ref=“Operation”/></entry></row><row><entry>  <xs:element ref=“oct:Bundle”/></entry></row><row><entry>  <xs:element name=“SessionId” type=”xs:string” minOccurs=”0”/></entry></row><row><entry>  <xs:element name=“NeedsContentKeys” type=”xs:boolean”</entry></row><row><entry>  minOccurs=”0”/></entry></row><row><entry> </xs:sequence></entry></row><row><entry></xs:complexType></entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0870In this schema, the ContentIdList element is replaced by a License element. This element carries a set of LicensePart elements. A LicensePart element carries an oct:Bundle element containing license objects as well as an optional ContentId attribute indicating that the license objects are applied to this particular ContentId. A LicensePart element with no ContentId attribute means that the objects contained in the underlying bundle are applied to all Content IDs (generally the controller and the control objects).

0871In one embodiment, the SessionId optional element cannot be present, except if the operation is urn:marlin:core: <b>1</b>-<b>2</b>:service:license-transfer:release in which case it may be present if a SessionId parameter was received in the Extended Status Block of the corresponding render or checkout action (see above).

0872In one embodiment, the NeedsContentKeys optional element should be present with a value of false if the sink knows that it is already capable of decrypting the content keys. The absence of this element means that the source has to re-encrypt the Content Keys of the sink in case of success of the protocol.

0873In one embodiment, when receiving such a request, the license element will be processed as follows:

0874(1) Collect all the ContentId attributes found in the LicensePart elements.

0875(2) Process all the Bundle elements found in the LicensePart elements.

0876(3) Open the set of content IDs collected above.

0877(4) Verify the appropriate signatures on the relevant objects.

0878(5) Optionally invoke the Control.Actions.Transfer.Check method on the processed Control object.

0879(6) Invoke the Control.Actions.Transfer.Perform on the process Control object.

0880Allowing the Control programs to proactively ask for proximity check of the sink. In order to allow Control programs to do this, a new pair of Obligations/Callbacks can be defined. Specifically, the control can put a “ProximityCheckSink” obligation in its extended status block. This indicates to the application that proximity with the sink has to be checked. When the proximity check is done, the application will call back the control using the “OnSinkProximityChecked” callback.

0881In one embodiment, a ProximityCheck obligation is defined that is only applicable in the context of a License Transfer. In this embodiment, there needs to be zero or one such obligation per extended status block, and, if present, an OnSinkProximityChecked callback needs to be present as well. <tables id="TABLE-US-00075" num="75"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="56PT" align="left" /><colspec colname="2" colwidth="35PT" align="left" /><colspec colname="3" colwidth="126PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Name</entry><entry>Type</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>ProximityCheck</entry><entry>ValueList</entry><entry>The host application needs to perform a</entry></row><row><entry /><entry /><entry>proximity check protocol with the sink</entry></row><row><entry /><entry /><entry>device.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="91PT" align="left" /><colspec colname="1" colwidth="28PT" align="left" /><colspec colname="2" colwidth="98PT" align="left" /><tbody valign="top"><row><entry /><entry>Type</entry><entry>Description</entry></row><row><entry /><entry>String</entry><entry>Id of the Personality Node that</entry></row><row><entry /><entry /><entry>has to be proximity checked</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0882OnSinkProximityChecked Callback <tables id="TABLE-US-00076" num="76"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="70PT" align="left" /><colspec colname="2" colwidth="21PT" align="left" /><colspec colname="3" colwidth="126PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Name</entry><entry>Type</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>OnProximityChecked</entry><entry>Value</entry><entry>The host application needs to callback</entry></row><row><entry /><entry>List</entry><entry>when a proximity check in one of the</entry></row><row><entry /><entry /><entry>obligation parameters has completed.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="91PT" align="left" /><colspec colname="1" colwidth="35PT" align="left" /><colspec colname="2" colwidth="91PT" align="left" /><tbody valign="top"><row><entry /><entry>Type</entry><entry>Description</entry></row><row><entry /><entry>Callback</entry><entry>Routine to call back, and</entry></row><row><entry /><entry /><entry>associated cookie.</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0883Allowing multiple round trips in the protocol. <figref idref="DRAWINGS">FIG. 33</figref> outlines a modification of the protocol that would allow multiple round trips. In the embodiment shown in <figref idref="DRAWINGS">FIG. 33</figref>, the Setup message <b>3302</b> can, for example, be the same as the improved license transfer request message described above in connection with the license resolution problem/solution.

0884As shown in <figref idref="DRAWINGS">FIG. 33</figref>, after the Setup <b>3302</b>, the application will run the Control as explained above and will get an Extended Status Block (ESB). This ESB may contain a RunAgentOnPeer obligation/OnAgentCompletion callback. In one embodiment, the RunAgentOnPeer obligation will contain all the parameters that the Source <b>3312</b> application needs to build the RunAgent message <b>3304</b>. Note that in one embodiment, the RunAgent message <b>3304</b> will also be sent if the application encounters another RunAgentOnPeer/OnAgentCompletion callback/obligation pair in the Extended Status Block of the OnAgentCompletion callback (after one or more RunAgent/AgentResult message exchanges).

0885In one embodiment, if the ESB does not contain a RunAgentOnPeer obligation/OnAgentCompletion callback, it means that the Teardown message (see below) needs to be sent. Note that this ESB may contain a ProximityCheck obligation/OnSinkProximityChecked callback in which case the proximity check protocol will be performed and the result will be read from the ESB of the OnSinkProximity checked callback before sending the Teardown message.

0886In one embodiment, the payload of the RunAgent message <b>3304</b> is identical to the Response message of the previous design except that it does not carry a ContentKeyList.

0887As shown in <figref idref="DRAWINGS">FIG. 33</figref>, after the sink <b>3310</b> has run the agent sent by the source in the RunAgent message <b>3304</b>, the sink <b>3310</b> sends an AgentResult message <b>3306</b> to the source <b>3312</b>. In one embodiment, the message payload is the same as the Confirmation message described in connection with <figref idref="DRAWINGS">FIG. 32</figref>.

0888As shown in <figref idref="DRAWINGS">FIG. 33</figref>, the Teardown message <b>3308</b> is sent by the Source application <b>3312</b> when the extended status block of the OnAgentCompletion does not carry any RunAgentOnPeer/OnAgentCompletion callback/obligation pair which means that the protocol is over. In one embodiment, the Teardown message <b>3308</b> carries two pieces of information: (i) a description of the protocol result so that the sink <b>3310</b> knows if the protocol has succeeded or not and if not, an indication of why it failed (see below for more details), and (ii) in case of success of the protocol, the updated ContentKey objects (the ContentKeyList of the Response in the previous message) if the NeedsContentKey element of the setup message is set to true or not present.

0889In one embodiment, the description of the protocol result is actually the Extended Status Block (ESB) of the last invocation of the control carrying no agent related obligation/callback pair.

0890In case of failure, the parameters of the ESB may point to resources. In one embodiment, these resources are located in the ResourceList extension of the Control that was sent in the Setup message.

0891In case of success, in one embodiment the cache duration will indicate for how much time the Content Keys may be used without asking the control again.

0892An example of such an ESB XML representation is shown below, and can be added to the virtual machine schema: <tables id="TABLE-US-00077" num="77"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="203PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry><xs:element name=“CacheDuration” type=“CacheDurationType”/></entry></row><row><entry /><entry><!-- CacheDurationType --></entry></row><row><entry /><entry><xs:complexType name=“CacheDurationType”></entry></row><row><entry /><entry>  <xs:attribute name=“type” type=“xs:int”/></entry></row><row><entry /><entry>  <xs:attribute name=“value” type=“xs:int”/></entry></row><row><entry /><entry></xs:complexType></entry></row><row><entry /><entry><xs:element name=“ExtendedStatusBlock”</entry></row><row><entry /><entry>type=“ExtendedStatusBlockType”/></entry></row><row><entry /><entry><!-- ExtendedStatusBlockType --></entry></row><row><entry /><entry><xs:complexType name=“ExtendedStatusBlockType”></entry></row><row><entry /><entry> <xs:sequence></entry></row><row><entry /><entry>  <xs:element ref=“CacheDuration”/></entry></row><row><entry /><entry> <xs:element name=“Parameters” type=“ValueListBlockType”</entry></row><row><entry /><entry> minOccurs=“0”/></entry></row><row><entry /><entry> </xs:sequence></entry></row><row><entry /><entry> <xs:attribute name=“globalFlags” type=“xs:int” default=“0”</entry></row><row><entry /><entry> use=“optional”/></entry></row><row><entry /><entry> <xs:attribute name=“category” type=“xs:int” use=“required”/></entry></row><row><entry /><entry> <xs:attribute name=“subcategory” type=“xs:int” use=“optional”/></entry></row><row><entry /><entry> <xs:attribute name=“localFlags” type=“xs:int” use=“required”/></entry></row><row><entry /><entry></xs:complexType></entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0893The following is an example of a rendering use case in accordance with an embodiment of the improved license transfer mechanisms described above. In this example, a broadcast import function imports a piece of content with the following license: <ul id="ul0021" list-style="none"><li id="ul0021-0001" num="0894"> Play: OK if a local state is present </li><li id="ul0021-0002" num="0895"> Transfer: <ul id="ul0022" list-style="none"><li id="ul0022-0001" num="0896"> Render OK if sink is in domain X or if sink is in proximity. Only one parallel stream can be rendered at a time. </li></ul></li></ul>

0897Assume a Core DRMClient<b>1</b> requests permission to render the content stream. A Setup Request is sent from the sink (Core DRMClient<b>1</b>) to the Source (BC Import function) containing the following parameters: <ul id="ul0023" list-style="none"><li id="ul0023-0001" num="0000"><ul id="ul0024" list-style="none"><li id="ul0024-0001" num="0898"> License: the license associated with the content that the sink wants to render </li><li id="ul0024-0002" num="0899"> Operation=urn:marlin:core: <b>1</b>-<b>0</b>:service:license-transfer:render </li><li id="ul0024-0003" num="0900"> Bundle=Personality node of the sink </li></ul></li></ul>

0901Upon receiving the request, the source application populates the relevant host objects and invokes the Control.Actions.Transfer.Perform method. Illustrative pseudo-code for the method governing rendering transfer is shown below: <tables id="TABLE-US-00078" num="78"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="203PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>/* pseudo-code of the method governing</entry></row><row><entry /><entry>  rendering transfer */</entry></row><row><entry /><entry>ESB* TransferRenderPerform(HostObjectTree* t) {</entry></row><row><entry /><entry> // check the lock</entry></row><row><entry /><entry> if (t->GetObject(“SeaShell/.../lock”) != NULL) {</entry></row><row><entry /><entry>  return new ESB(ACTION_DENIED);</entry></row><row><entry /><entry> } else {</entry></row><row><entry /><entry>  // time limited lock, we will unlock in case of failure</entry></row><row><entry /><entry>  t->SetObject(“SeaShell/.../lock”, 1);</entry></row><row><entry /><entry>  t->SetObject(“SeaShell/.../lock@ExpirationTime,</entry></row><row><entry /><entry>         Time.GetCurrent( ) + 180);</entry></row><row><entry /><entry>  // return an ESB that contains a RunAgentOnPeer</entry></row><row><entry /><entry>  // obligation and a OnAgentCompleted callback</entry></row><row><entry /><entry>   return new ESB(ACTION_GRANTED,</entry></row><row><entry /><entry>        new Obligation(RUN_AGENT_ON_PEER,</entry></row><row><entry /><entry>                CheckDomainAgent),</entry></row><row><entry /><entry>        new Callback(ON_AGENT_COMPLETED,</entry></row><row><entry /><entry>               RenderAgentCompleted));</entry></row><row><entry /><entry> }</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0902Assuming that the rendering is not locked, the RunAgentOnPeer obligation is executed. A RunAgent message is sent with the Control containing the CheckDomainAgent Method. Upon receiving this message, the sink will populate the relevant host objects and invoke the CheckDomainAgent method. Illustrative pseudo-code for the CheckDomainAgent is shown below: <tables id="TABLE-US-00079" num="79"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="21PT" align="left" /><colspec colname="1" colwidth="196PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>/* pseudo-code of the CheckDomainAgent */</entry></row><row><entry /><entry>AgentResult* CheckDomainAgent(HostObjectTree* t) {</entry></row><row><entry /><entry> // check if the domain node is reachable</entry></row><row><entry /><entry> if (IsNodeReachable(“urn:marlin:...:domain2042x”)) {</entry></row><row><entry /><entry>  return new AgentResult(SUCCESS);</entry></row><row><entry /><entry> } else {</entry></row><row><entry /><entry>  return new AgentResult(FAILURE);</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0903Assume for purposes of this illustration that the sink is indeed in the domain. The sink will then send an AgentResult message containing this agent result. Upon receiving the AgentResult, the Source will invoke the callback method. Illustrative pseudo-code for RenderAgentCompleted is shown below: <tables id="TABLE-US-00080" num="80"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>/* pseudo-code of the RenderAgentCompleted */</entry></row><row><entry>ESB* RenderAgentCompleted(HostObjectTree* t,</entry></row><row><entry>        AgentResult* ar)</entry></row><row><entry>{</entry></row><row><entry> if (ar->IsSuccess( )) {</entry></row><row><entry>  // give an ESB with no obligation/callback</entry></row><row><entry>  // and a Cache duration</entry></row><row><entry>  return new ESB(ACTION_GRANTED, new CacheDuration(0));</entry></row><row><entry> } else {</entry></row><row><entry>  // try to do a proximity check</entry></row><row><entry>  return new ESB(ACTION_GRANTED,</entry></row><row><entry>      new obligation(CHECK_PROXIMITY,</entry></row><row><entry>        t->GetObject(“.../Sink/Id”),</entry></row><row><entry>      new Callback(ON_SINK_PROXIMITY_CHECKED,</entry></row><row><entry>          ProximityCheckCompleted));</entry></row><row><entry> }</entry></row><row><entry>}</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0904We had assumed that the agent successfully checked the domain membership on the sink. A Teardown message is sent with (i) the re-encrypted content keys for the sink (using the keys provided with the sink node in the Setup request), and (ii) the ESB carrying the cache duration specified above (0 in this case, meaning that the sink has to re-ask next time it wants to access the content). When the sink receives this message, it knows it is allowed to render the content and has the needed content keys.

0905Now assume that the user wants to render the content on his other device, DRMClient<b>2</b>. The problem is that the content is locked for 180 minutes on the source. Fortunately, when the user presses STOP on DRMClient<b>1</b>, DRMClient<b>1</b> will initiate a new license transfer protocol with the operation: Release. Upon receiving the request, the source application will populate the relevant host objects and invoke the Control.Actions.Transfer.Perform method. Illustrative pseudo-code for the method governing transfer release is shown below: <tables id="TABLE-US-00081" num="81"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="28PT" align="left" /><colspec colname="1" colwidth="189PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>/* pseudo-code of the method governing</entry></row><row><entry /><entry>transfer release */</entry></row><row><entry /><entry>ESB* TransferReleasePerform(HostObjectTree* t) {</entry></row><row><entry /><entry> // check the lock</entry></row><row><entry /><entry> if (t->GetObject(“SeaShell/.../lock”) != NULL) {</entry></row><row><entry /><entry>  t->SetObject(“SeaShell/.../lock, NULL); // delete</entry></row><row><entry /><entry>  return new ESB(ACTION_GRANTED);</entry></row><row><entry /><entry> } else {</entry></row><row><entry /><entry>  return new ESB(ACTION_DENIED);</entry></row><row><entry /><entry> }</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0906Since no obligation/callback is found in the ESB, this means that a Teardown message will be sent back with this ESB.

0907This rendering use case thus illustrates that, in certain embodiments, there is no need for the requesting DRMClient of a render operation to re-evaluate the control locally, state does not have to be transferred from the source to the sink, the control can proactively ask for a proximity check, and the content can be released when the renderer is done with it.

000011. Certificates

0908In one embodiment, certificates are used to check the credentials associated with cryptographic keys before making decisions based on the digital signature created with those keys.

0909In some embodiments, the DRM engine is designed to be compatible with standard certificate technologies, and can leverage information found in the elements of such certificates, such as validity periods, names, and the like. In addition to those basic constraints, in some embodiments additional constraints can be defined about what a certified key can and cannot be used for. This can accomplished by, for example, using key-usage extensions available as part of the standard encoding of the certificates. The information encoded in such extensions allows the DRM engine to check if the key that has signed a specific object was authorized to be used for that purpose. For example, a certain key may have a certificate that allows it to sign link objects only if the link is from a node with a specific attribute, to a node with another specific attribute, and no other link. Since the semantics of the generic technology used to express the certificate will generally not be capable of expressing such a constraint, as it will have no way of expressing conditions that relate to DRM engine-specific elements such as links and nodes, in one embodiment such DRM engine-specific constraints are conveyed as a key usage extension of the basic certificate that will be processed by applications that have been configured to use the DRM engine.

0910In one embodiment, the constraints in the key usage extension are expressed by a usage category and a VM constraint program. The usage category specifies what type of objects a key is authorized to sign. The constraint program can express dynamic conditions based on context. In one embodiment, any verifier that is being asked to verify the validity of such a certificate is required to understand the DRM engine semantics, and delegates the evaluation of the key usage extension expression to a DRM engine, which uses an instance of the virtual machine to execute the program. The certificate is considered valid if the result of the execution of that program is successful.

0911In one embodiment, the role of a constraint program is to return a boolean value. “True” means that the constraint conditions are met, and “false” means that they are not met. In one embodiment the control program will have access to some context information that can be used to reach a decision, such as information available to the program through the virtual machine's Host Object interface. The information available as context depends on what type of decision the DRM engine is trying to make when it requests the verification of the certificate. For example, before using the information in a link object, in one embodiment a DRM engine will need to verify that the certificate of the key that signed the object allows that key to be used for that purpose. When executing the constraint program, the virtual machine's environment will be populated with information regarding the link's attributes, as well as the attributes of the nodes referenced by the link.

0912In one embodiment, the constraint program embedded in the key usage extension is encoded as a virtual machine code module that exports at least one entry point named “Octopus.Certificate.<Category>.Check”, where “Category” a name indicating which category of certificates needs to be checked. Parameters to the verification program will be pushed on the stack before calling the entry point. The number and types of parameters passed on the stack will generally depend on the category of certificate extension being evaluated.

000012. Digital Signatures

0913In preferred embodiments, some or all of the objects used by the DRM engine are signed. The following is a description of how objects are digitally signed in one embodiment using the XML digital signature specification (http://www.w3.org/TR/xmldsig-core) (“XMLDSig”). In addition, a canonicalization method of XML compatible with the XML exclusive canonicalization (http://www.w3.org/TR/xml-exc-cl4n/) (“cl4n-ex”) is also described, the output of which can be processed by a non-XML-namespace-aware parser. Appendix D provides more information on an exemplary object serialization, including an illustrative way to compute a canonical byte sequence for objects in an encoding-independent manner.

0914As shown in <figref idref="DRAWINGS">FIGS. 28, 34</figref>, and <b>35</b> in preferred embodiments certain elements in a DRM license are signed. Techniques such as those shown in <figref idref="DRAWINGS">FIGS. 28, 34</figref>, and <b>35</b> are useful in prevent or impeding tampering with or replacement of the license components. As shown in <figref idref="DRAWINGS">FIG. 34</figref>, in a preferred embodiment, controller object <b>3402</b> includes cryptographic digests or hashes (or other suitable bindings) <b>3405</b>, <b>3407</b> of contentkey object <b>3404</b> and control object <b>3406</b>, respectively. Controller <b>3402</b> is itself signed with a MAC (or, preferably, an HMAC that makes use of the content key) and a public key signature (typically of the content or license provider) <b>3412</b>. In a preferred embodiment, the public key signature of the controller <b>3412</b> is itself signed with an HMAC <b>3410</b> using the content key. It will be appreciated that in other embodiments, other signature schemes could be used, depending on the desired level of security and/or other system requirements. For example, different signature schemes could be used for the signature of the controller and/or control, such as PKI, standard MACs, and/or the like. As another example, a separate MAC signature could be computed for both the control and the controller, rather than including a digest of the control in the controller and computing a single MAC signature of the controller. In yet another example, the controller could be signed with both a MAC and a public key signature. Alternatively or in addition different keys than those described above could be used to generate the various signatures. Thus while <figref idref="DRAWINGS">FIGS. 28, 34</figref>, and <b>35</b> illustrate several advantageous signature techniques in accordance with some embodiments, it will be appreciated that these techniques are illustrative and non-limiting. <figref idref="DRAWINGS">FIG. 35</figref> illustrates an embodiment in which a controller references multiple content keys. As shown in <figref idref="DRAWINGS">FIG. 35</figref>, in one embodiment, each of the content keys is used to generate an HMAC of the controller and the PKI signature.

0915In one embodiment the data mode, processing, input parameters, and output data for XML canonicalization are the same as for Exclusive Canonical XML (cl4n-ex) except that namespace prefixes are removed (namespaces are indicated using the default namespace mechanism) and external entities are not supported, only character entities are. The first limitation implies that an attribute and its element need to be in the same namespace.

0916<figref idref="DRAWINGS">FIG. 42</figref> shows the relationship between cl4n-ex and an illustrative XML canonicalization in one embodiment, where <xml> is any valid XML, and where <xml>′=<xml>″ only if <xml> has no external entities and no namespace prefixes.

0917A simple example of the simplified signature scheme is provided below: In a preferred embodiment, however, the standard XML canonicalization is used. <tables id="TABLE-US-00082" num="82"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="42PT" align="left" /><colspec colname="2" colwidth="161PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>original</entry><entry><n1:elem2 id=“foo”</entry></row><row><entry /><entry /><entry>   xmlns:n0=“foo:bar”</entry></row><row><entry /><entry /><entry>   xmlns:n1=“http://example.net”</entry></row><row><entry /><entry /><entry>   xmlns:n3=“ftp://example.org”></entry></row><row><entry /><entry /><entry> <n3:stuff/></entry></row><row><entry /><entry /><entry></n1:elem2></entry></row><row><entry /><entry>processed</entry><entry><elem2 xmlns=“http://example.net” id=“foo”></entry></row><row><entry /><entry /><entry> <stuff xmlns=“ftp://example.org”/></entry></row><row><entry /><entry /><entry></elem2></entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0918The signature elements discussed in this section belong to the XMLDSig namespace (xmlns=http://www.w3.org/2000/09/xmldsig#) and are defined in the XML schema defined in the XMLDSig specification. In one embodiment, the container element of the XML representation of DRM objects is the <Bundle> element.

0919In one embodiment, the following objects need to be signed: <ul id="ul0025" list-style="none"><li id="ul0025-0001" num="0920"> Nodes </li><li id="ul0025-0002" num="0921"> Links </li><li id="ul0025-0003" num="0922"> Controllers </li><li id="ul0025-0004" num="0923"> Controls (optional) </li><li id="ul0025-0005" num="0924"> Extensions (depending on the data they carry) </li></ul>

0925In one embodiment, the signatures need to be detached and the <Signature> element needs to be present in the <Bundle> object that contains the XML representation of the objects that need to be signed.

0926In one embodiment, the <Signature> block will contain: <ul id="ul0026" list-style="none"><li id="ul0026-0001" num="0927"> A <SignedInfo> element </li><li id="ul0026-0002" num="0928"> A <SignatureValue> element </li><li id="ul0026-0003" num="0929"> A <KeyInfo> element </li></ul>

0930In one embodiment, the <SignedInfo> embeds the following elements:

0931<CanonicalizationMethod>—In one embodiment, the <CanonicalizationMethod> element is empty and its Algorithm attribute has the following value: http://www.w3.org/2001/10/xml-exc-cl4n#

0932<SignatureMethod>—In one embodiment, the <SignatureMethod> element is empty and its Algorithm attribute can have the following values: <ul id="ul0027" list-style="none"><li id="ul0027-0001" num="0933"> http://www.w3.org/2000/09/xmldsig#hmac-sha1 (HMAC signature) </li><li id="ul0027-0002" num="0934"> http://www.w3.org/2000/09/xmldsig#rsa-sha1 (Public Key Signature) </li></ul>

0935<Reference>—In one embodiment, there can be one or more <Reference> elements inside the <SignedInfo> block if more than one objects need to be signed by the same key (e.g., this would be the case for the Control and the Controller object).

0936In one embodiment, when signing an object, the value of the ‘URI’ attribute of the <Reference> element is the ID of the referenced object. When signing a local XML element (for example, in the multiple signature case of the public signature method for Controller objects), the value of the URI is the value of the ‘Id’ attribute of the referenced element.

0937In one embodiment, when a reference points to an object, what is digested in the reference is not the XML representation of the object but its canonical byte sequence. This transform of the object is indicated in XMLDSig by the means of the <Tranforms> block. Therefore, in one embodiment, the <Reference> element will embed this block: <tables id="TABLE-US-00083" num="83"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry><Tranforms></entry></row><row><entry> <Transform Algorithm=“http://www.intertrust.com/octopus/cbs-1_0”/></entry></row><row><entry></Tranforms></entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0938Appendix D provides additional information. In one embodiment, no other <Tranform> is allowed for object references.

0939In one embodiment, the <DigestMethod> element is empty and its Algorithm attribute has the following value: http://www.w3.org/2000/09/xmldsig#sha1

0940The <DigestValue> element contains the base<b>64</b> encoded value of the digest.

0941<SignatureValue>—In one embodiment, the signature value is the base<b>64</b> encoded value of the signature of the canonicalized (ex-cl4n) <SignedInfo> element with the key described in the <KeyInfo> element.

0942<KeyInfo>

0943HMAC-SHA1 Case For Signatures of Controller Objects

0944In one embodiment, in this case the <KeyInfo> will only have one child: <KeyName> that will indicate the ID of the key that has been used for the HMAC signature.

0945Example: <tables id="TABLE-US-00084" num="84"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="21PT" align="left" /><colspec colname="1" colwidth="196PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry><KeyInfo></entry></row><row><entry /><entry> <KeyName>urn:x-octopus:secret-key:1001</KeyName></entry></row><row><entry /><entry></KeyInfo></entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0946RSA-SHA1 Case

0947In one embodiment, in this case the public key used to verify the signature will be carried in an X.509 v3 certificate, and may be accompanied by other certificates that may be necessary to complete the certificate path to a CA root.

0948These certificates are carried, encoded in base<b>64</b>, in <X509Certificate> elements. These <X509Certificate> elements are embedded in an <X509Data> element child of the <KeyInfo> element, and appear in sequential order, starting from the signing key's certificate. The certificate of the root is usually omitted.

0949Example (for the sake of brevity, the entire values of the example certificates have not been reproduced; the material that has been deleted is indicated by ellipses): <tables id="TABLE-US-00085" num="85"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="28PT" align="left" /><colspec colname="1" colwidth="189PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry><KeyInfo></entry></row><row><entry /><entry> <X509Data></entry></row><row><entry /><entry>  <!-- cert of the signing public key --></entry></row><row><entry /><entry>  <X509Certificate>MIICh...</X509Certificate></entry></row><row><entry /><entry>  <!-- intermediate cert to the trust root --></entry></row><row><entry /><entry>  <X509Certificate>MIICo...</X509Certificate></entry></row><row><entry /><entry>  </X509Data></entry></row><row><entry /><entry></KeyInfo></entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0950In one embodiment, controller objects need to have at least one HMAC signature for each ContentKey referenced in their list of controlled targets. The key used for each of those signatures is the value of the content key contained in the ContentKey object referenced.

0951Controllers may also have an RSA signature. In one embodiment, if such a signature is present, this signature also appears as a <Reference> in each of the HMAC signatures for the object. To achieve this, in one embodiment the <Signature> element for the RSA signature must have an ‘Id’ attribute, unique within the enclosing XML document, which is used as the ‘URI’ attribute in one of the <Reference> elements of each of the HMAC signatures. In one embodiment, the verifier must reject RSA signatures that are not corroborated by the HMAC signature.

0952Example: <tables id="TABLE-US-00086" num="86"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="322PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry><Signature Id=“Signature.0” xmlns=“http://www.w3.org/2000/09/xmldsig#”></entry></row><row><entry> <SignedInfo></entry></row><row><entry>  <CanonicalizationMethod Algorithm=“http://www.w3.org/2001/10/xml-exc-c14n#”/></entry></row><row><entry>  <SignatureMethod Algorithm=“http://www.w3.org/2000/09/xmldsig#rsa-sha1”/></entry></row><row><entry>  <Reference URI=“urn:x-octopus.intertrust.com:controller:37A50262EE3389A14ABC0BC7BE5D43E5”></entry></row><row><entry>   <Transforms></entry></row><row><entry>    <Transform Algorithm=“http://www.intertrust.com/Octopus/xmldsig#cbs-1_0”/></entry></row><row><entry>   </Transforms></entry></row><row><entry>   <DigestMethod Algorithm=“http://www.w3.org/2000/09/xmldsig#sha1”/></entry></row><row><entry>   <DigestValue>G1zXF9Sz/zCwH6MaFm0ObOQcxuk=</DigestValue></entry></row><row><entry>  </Reference></entry></row><row><entry> </SignedInfo></entry></row><row><entry><SignatureValue>mjoyW+w2S9iZDG/ha4eWYD1RmhQuqRuuSN977NODpzwUD02FdsAICVjAcw7f4nF</entry></row><row><entry>WuvtawW/clFzYP/pjFebESCvurHUsEaR1/LYLDkpWWxh/LlEp4r3yR9kUs0AU5a4BDxDxQE7nUdqU9</entry></row><row><entry>YMpnjAZEGpuxdPeZJM1vyKqNDpTk94=</SignatureValue></entry></row><row><entry> <KeyInfo></entry></row><row><entry>  <X509Data><X509Certificate>MIICh...</X509Certificate></X509Data> </KeyInfo></entry></row><row><entry></Signature></entry></row><row><entry><Signature xmlns=“http://www.w3.org/2000/09/xmldsig#”></entry></row><row><entry> <SignedInfo></entry></row><row><entry>  <CanonicalizationMethod Algorithm=“http://www.w3.org/2001/10/xml-exc-c14n#”/></entry></row><row><entry>  <SignatureMethod Algorithm=“http://www.w3.org/2000/09/xmldsig#hmac-sha1”/></entry></row><row><entry>  <Reference URI=“#Signature.0”></entry></row><row><entry>   <DigestMethod Algorithm=“http://www.w3.org/2000/09/xmldsig#sha1”/></entry></row><row><entry>   <DigestValue>AqPV0nvNj/vc51IcMyKJngGNKtM=</DigestValue></entry></row><row><entry>  </Reference></entry></row><row><entry>  <Reference URI=“urn:x-octopus.intertrust.com:controller:1357”></entry></row><row><entry>   <Transforms></entry></row><row><entry>    <Transform Algorithm=“http://www.intertrust.com/Octopus/xmldsig#cbs-1_0”/></entry></row><row><entry>   </Transforms></entry></row><row><entry>   <DigestMethod Algorithm=“http://www.w3.org/2000/09/xmldsig#sha1”/></entry></row><row><entry>   <DigestValue>G1zXF9Sz/zCwH6MaFm0ObOQcxuk=</DigestValue></entry></row><row><entry>  </Reference></entry></row><row><entry> </SignedInfo></entry></row><row><entry> <SignatureValue>TcKBsZZy+Yp3doOkZ62LTfY+ntQ=</SignatureValue></entry></row><row><entry> <KeyInfo></entry></row><row><entry>  <KeyName>urn:x-octopus.intertrust.com:secret-key:2001</KeyName></entry></row><row><entry> </KeyInfo></entry></row><row><entry></Signature></entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> 13. Proximity Check Protocol

0953In some embodiments, it may be desirable to restrict access to content, services, and/or other system resources based on the physical proximity of the requesting entity (e.g., to help enforce rules indicating that a protected piece of content cannot be copied outside a user's home network, office complex, and/or the like). Embodiments of a proximity check protocol are described below that provide security without unduly impeding the performance of the proximity check itself. The proximity check protocol lends itself to application in a wide variety of contexts, one of which is, as indicated above, in the context of digital rights management controls; however, it will be appreciated that the proximity checking systems and methods described below are not limited in application to the digital rights management context. For example, without limitation, the proximity checking techniques presented herein can also be used in the context of a network service orchestration system such as that described in the '551 application and/or any other suitable context.

0954In one embodiment, a proximity check is performed by measuring the amount of time it takes a first computing node to receive a response from a second computing node to the first computing node's request. If the amount of time is less than a predefined threshold (generally indicating that the second computing node is within a certain physical distance of the first computing node), then the proximity check is deemed a success.

0955It will be appreciated that due to the wide variety of different network connections over which the request and/or the response might be sent, a given amount of time may correspond to range of possible distances. In some embodiments, this variation is simply ignored, and the proximity check is deemed a success if the round-trip time of the request/response exchange is less than the predefined threshold (e.g., 8 milliseconds, or any other suitable amount of time), regardless of whether, e.g., a fast network connection is being used that could mean that the requesting and responding nodes are actually relatively distant from each other. In other embodiments, a determination could be made as to the type of network connection being used, and different round-trip time requirements could be applied to each different network connection.

0956In a preferred embodiment, the proximity check allows an anchor (e.g., a client) to check the proximity of a target (e.g., a service). In one embodiment, the protocol is asymmetric, in that the anchor generates the secret seed that is used, and is the only one that makes use of a secure timer. Moreover, the target does not need to trust the anchor. Preferred embodiments of the proximity check are also cryptographically efficient: in one embodiment making use of only two public key operations.

0957Generation of a Set, R, of Q Pairs from a Seed, S

0958In one embodiment, a set R is obtained from a seed S according to the following formula: R_i=H^2Q-i(S). Where H(M) is the digest value of the hash function H over the message M, and Hⁿ(M)=H(H^n-1(M)) for n>=1 and H⁰(M)=M. It will be appreciated that this is simply one illustrative technique for generating a shared secret, and that in other embodiments other techniques could be used without departing from the principles hereof.

0959In one embodiment, the algorithm used for the hash function H is SHA1 (see, e.g., FIPS PUB 180-1. Secure Hash Standard. U.S. Department of Commerce/National Institute of Standards and Technology), although it will be appreciated that in other embodiments, other hash, message digest, or functions could be used.

0960In one embodiment, a proximity check is performed as follows, where “A” is the anchor (e.g., client) and “B” is the target (e.g., service):

0961(a) A generates a set R of Q pairs of random numbers {R₀, R₁}, {R₂, R₃}. . . {R_2Q-2, R_2Q-1}, as shown above.

0962(b) A sends to B: E(PubB, {Q,S}), where E(Y, X) denotes the encryption of X with the key Y, and PubB denotes B's public key in a public/private key pair.

0963(c) B decrypts {Q,S} and precomputes R as shown above.

0964(d) B sends A an acknowledgement to indicate that it is ready to proceed.

0965(e) A sets a loop counter, k, to zero.

0966(f) A measures T₀=current time.

0967(g) A sends to B: {k, R_2*k}.

0968(h) If the value of R_2*kis correct, B responds with R_2*k+1.

0969(i) A measures D=new current time−T₀.

0970(j) If B responded to A with the correct value for R_2*k+1, and D is less than a pedefined threshold, then the proximity check is deemed a success.

0971If k+1&lt;Q, A can retry a new measurement by incrementing k and going to step (f). If it is needed to perform more than Q measurements, A can start from step (a) with a new set R. For example, in some embodiments the proximity check can be performed repeatedly (or a predefined number of times) until a correct response is received within the predefined threshold (or if correct responses are received within the predefined threshold more than a predefined percentage of a sequence of challenge/responses), since even if two computing nodes are within the required proximity of each other, an abnormally slow network connection, heavy traffic, noise, and/or the like can cause B's response to be delayed.

0972<figref idref="DRAWINGS">FIG. 36</figref> illustrates an embodiment of the protocol described above, in which anchor (A) determines whether target (B) is within an acceptable proximity of anchor (A). For example, as shown in <figref idref="DRAWINGS">FIG. 36</figref>, A may comprise a computing node <b>3602</b> that contains protected content (e.g., music, video, text, software, and/or the like) and/or content-access material (e.g., a link, a key, and/or the like) needed by a remote computing node (B) <b>3606</b> to access protected content stored at, or accessible to, computing node B <b>3606</b>. Controls associated with the content or content-access material may indicate that it can only be shared with devices within a certain proximity of node A <b>3602</b> (e.g., to approximate limiting the distribution of the content to a home network). Alternatively, or in addition, such a policy may be enforced at the system level of computing node A <b>3602</b> (which may, for example, comprise the domain manager of a home or enterprise network). That is, the proximity check need not be a condition in a control program executed by a virtual machine; it could instead simply be something that computing node A <b>3602</b> requires as a matter of operational policy before sending content or content access material to computing node B <b>3606</b>. To enforce such controls and/or policies, software and/or hardware running on computing node A <b>3602</b> can perform the proximity checking protocol described above each time a request is made to distribute protected content or content-access material to computing node B <b>3606</b>. Alternatively, or in addition, a proximity check could be performed at predefined intervals (e.g., once a day) to determine if node B <b>3606</b> is in the required proximity, and, if the proximity check is successful, node B <b>3606</b> could be treated as being within the required proximity for a predefined period (e.g., until the next check is performed, until a predefined amount of time elapse, and/or the like).

0973As shown in <figref idref="DRAWINGS">FIG. 36</figref>, once A and B complete any initial set-up steps (e.g., steps (a) through (e), above) <b>3604</b>, <b>3608</b>, A and B engage in a secure, timed, challenge-response exchange (e.g., steps (f) through (i), above) <b>3610</b> that enables A to determine whether B is within an acceptable proximity.

0974As shown in <figref idref="DRAWINGS">FIG. 36</figref>, in one embodiment A <b>3602</b> sends B <b>3606</b> a Setup Request <b>3604</b> comprising E(PubB, {Q, S})—i.e., the number of pairs, Q, as well as the secret pairs seed, S, encrypted with B's public encryption key (e.g., a key used by B in the context of service orchestration). In one embodiment, {Q, S } is the byte stream concatenation of Q (1 byte) and S (16 bytes) in network byte order. In one embodiment, the encryption is performed using RSA public key encryption (e.g., as described in B. Kaliski, J. Staddon, PKCS #1: RSA Cryptography Specifications Version 2.0. IETF RFC2437. October 1998). In a preferred embodiment, PubB will have been previously accessed by A through inspection, and its certificate will have been verified. Although a Setup Response <b>3608</b> from B <b>3606</b> to A <b>3602</b> is shown in <figref idref="DRAWINGS">FIG. 36</figref>, in other embodiments, a Setup Response <b>3608</b> is not used. As previously indicated, after receiving the Setup Request <b>3604</b>, B <b>3606</b> preferably precomputes the set R, so as to facilitate rapid response to subsequent challenges from A <b>3602</b>.

0975As shown in <figref idref="DRAWINGS">FIG. 36</figref>, A <b>36</b>-<b>2</b> sends B a Challenge Request <b>3612</b> consisting of [k, R_2*k]—i.e., the index, k, and the corresponding secret computed from the seed. In one embodiment, [k, R_2*k] is the byte stream concatenation of k (1 byte) and R_2*k(20 bytes) in network byte order, encoded in base<b>64</b> for transport. As shown in <figref idref="DRAWINGS">FIG. 36</figref>, in one embodiment, B <b>3606</b> is operable to send a Challenge Response <b>3614</b> to A <b>3602</b>, the Challenge Response <b>3614</b> consisting of R_2*k+1—i.e., the corresponding secret from the Challenge Request <b>3612</b>. In one embodiment, R_2*k+1is the byte stream of R_2*k+1(20 bytes) in network byte order, encoded in base<b>64</b> for transport.

0976<figref idref="DRAWINGS">FIG. 37</figref> shows an example of how an embodiment of the proximity check protocol described above could be used to control access to protected content. Referring to <figref idref="DRAWINGS">FIG. 37</figref>, assume that a cable or satellite content provider has a policy of allowing all devices within a predefined proximity <b>3708</b> of a user's personal video recorder (PVR) <b>3702</b> to access content through the PVR. Thus, for example, domain manager software running on the PVR <b>3702</b> might perform a proximity check on device <b>3704</b> and <b>3706</b> requesting access to content through PVR <b>3702</b>. In the example, shown in <figref idref="DRAWINGS">FIG. 37</figref>, device <b>3706</b> is not within the proximity <b>3708</b> defined by the service provider's policy, and would be denied access by PVR <b>3702</b>. In contrast, device <b>3704</b> is within the proximity, and would be provided with access (e.g., by receiving the content along with an expiring link from device <b>3704</b> to the PVR <b>3702</b>. Alternatively, or in addition, the link might contain a control program that was itself operable to initiate a proximity check with PVR <b>3702</b>, and deny device <b>3704</b> further access to the content if device <b>3704</b> moved beyond the predefined proximity <b>3708</b> of PVR <b>3702</b>.

0977Security Considerations

0978In preferred embodiments, care should be taken to adhere to some or all of the following: <ul id="ul0028" list-style="none"><li id="ul0028-0001" num="0979"> The loop comprising steps (f) through (i) is not repeated with the same value of k for any set R. </li><li id="ul0028-0002" num="0980"> The protocol is aborted if an unexpected message is received by either party, including: <ul id="ul0029" list-style="none"><li id="ul0029-0001" num="0981"> If B receives an incorrect. value for R_2*kin step (g) </li><li id="ul0029-0002" num="0982"> If Q is not within a specified range in step (a) </li><li id="ul0029-0003" num="0983"> If k is repeated in the loop </li><li id="ul0029-0004" num="0984"> If k exceeds Q </li></ul></li></ul>

0985The protocol can alternatively or in addition be aborted if A receives an incorrect value of R_2*k+1in step (h). In other embodiments, a certain number of incorrect responses from B may be tolerated.

0986It will be appreciated that optimal values for Q and the predefined time threshold will typically depend on the unique circumstances of the application at hand (e.g., the speed of the network, the importance of ensuring a relatively tight proximity, etc.). Therefore, implementations should preferably provide for flexibility in configuring these values. In one embodiment, it is assumed that implementations will support a minimum value of 64 for Q and a value of 8 ms for the threshold (where, at some of today's network speeds, 8 ms may correspond to a proximity of a few miles).

0987Protocol Security Policies

0988In a preferred embodiment, no additional security is needed for the exchange of the request and the response. Because of the size of the messages being exchanged (e.g., 20 bytes), and their effective randomness (through use of the SHA1 hashing algorithm or other method), it will be cryptographically infeasible for an attacker to determine the correct response, even if the attacker manages to intercept the request.

0989It should be appreciated that the above-described embodiments are illustrative, and that numerous modifications could be made without departing from the inventive principles presented herein. For example, while a recursively hashed secret seed is described above, any suitable shared secret could be used for the challenge/response. In one embodiment, the shared secret might simply comprise an encrypted number/message sent from A to B, and the challenge/response could simply comprise A and B exchanging portions of the number/message (e.g., A sends B the first character of the message, and B sends A the second character of the message, and so forth). Although such a technique may lack the security of the embodiment described in connection with <figref idref="DRAWINGS">FIG. 36</figref> (since a character in a message would be much easier to guess than a 20 byte hash), in some embodiments such a level of security may be adequate (especially where, for example, the variability of network delays makes the proximity checking mechanism a fairly coarse control of actual proximity anyway), and in other embodiments security could be enhanced by performing the proximity check multiple times, where, although any particular digit or bit may be relatively easy to guess, the likelihood that an attacker would be able to correctly guess a given sequence of digits or bits will rapidly decrease with the length of the sequence. In such an embodiment, the proximity check could be deemed a success only if B is able to provide more than a predefined number of consecutive correct responses (or a predefined percentage of correct responses).

0990For purposes of illustration and explanation, an additional illustrative example of a proximity check protocol is provided below. In this example, a first device, SRC, communicates with a second device, SNK, over a communication channel (e.g., a computer network). We want to be able to securely determine if SRC and SNK are within proximity of each other, as measured by the time it takes for SNK to respond to a communication request from SRC. A challenge or probe message is sent from SRC to SNK, and SNK replies with a response message. The period of time between the emission of the challenge and the reception of the response will be called the round trip time or RTT. To avoid introducing unnecessary overhead in the time it takes SNK to compute and send back a response to the challenge, it will generally be desirable to make the challenge/response communication as lightweight as practical. In particular, it will typically be desirable to avoid requiring cryptographic operations by SRC or SNK between the emission of the challenge and the reception of the response.

0991Also, to ensure that only SNK is able to produce a valid response to the challenge from SRC (e.g., to avoid a man-in-the-middle attack, where a third party could intercept the challenge from SRC and send a response back, as if SNK had responded), the protocol could proceed as follows:

0992(1) SRC creates a secret. This secret is composed of one or more pairs of random or pseudo-random numbers.

0993(2) SRC sends to SNK the secret. This part of the protocol is not time-sensitive. The secret is kept confidential by SRC and SNK. The secret is also sent in a way that ensures that only SNK knows it. This typically involves sending the secret over a secure authenticated channel between SRC and SNK (for example, SRC can encrypt the secret data with a public key for which it knows that only SNK has the corresponding private key). The secret data does not have to be the pair(s) of random or pseudo-random numbers described above. Even in embodiments where such pairs are used, the secret data transmitted in this step only needs to be enough information to allow SNK to compute or deduct the values of the pair(s) of numbers. For example, the secret data could be a random seed number from which one or more pair(s) of pseudo-random numbers can be generated using a seeded pseudo-random number generator.

0994(3) Once SRC knows that SNK is ready to receive a challenge (for example, SNK may send a READY message after receiving and processing the secret data), SRC creates a challenge message. To create the challenge message. For example, in a preferred embodiment, SRC selects one of the random number pairs. If more than one pair is used, the challenge message data contains the information to indicate which pair was chosen, as well as one of the two numbers in that pair.

0995(4) SRC measures the value of the current time, TO. Immediately after, SRC sends the challenge message (no need for encryption or digital signature), to SNK and waits for the response. Alternatively, SRC could measure the current time, T<b>0</b>, immediately before sending the challenge message, although preferably after any concomitant cryptographic operations (e.g., encryption, signing, and/or the like) had been performed.

0996(5) SNK receives the challenge, from which it can identify one of the pairs it has received previously. SNK checks that the random number in the challenge is part of the pair, and constructs a response message that contains the value of the other random number of that pair.

0997(6) SNK sends the response message to SRC (no need for encryption or digital signature).

0998(7) SRC receives the response message, and measures the value of the current time, T<b>1</b>. The round trip time RTT is equal to T<b>1</b>-T<b>0</b>.

0999(8) SRC verifies that the number received in the response is equal to the other value in the pair that was chosen for the challenge. If the numbers match, the challenge response is successful, and SRC can be assured that SNK was within the proximity indicated by the roundtrip time. If the numbers do not match, SRC can abort the protocol, or, if more than one pair was shared, and there is at least one pair that has not been used, go back to step (3), and use a different pair.

1000It will be appreciated that a number of variations could be made to the illustrative proximity checking protocols described above without departing from the principles thereof. For example, without limitation, different cryptographic algorithms could be used, different shared secrets could be used, and/or the like.

000014. Security

1001In practical applications of the systems and methods described herein, security can be provided at a variety of different levels and using a variety of different techniques. The discussion herein has focused primarily on the design and operation of a DRM engine and related host application for use in efficiently regulating potentially complex business relationships. When the DRM engine and host application operate as intended, content is protected from unauthorized access or other use by the enforcement of the license terms associated therewith.

1002Protection of the DRM engine and/or the environment in which the DRM engine runs (e.g., the applications and hardware with which it interacts) from malicious tampering or modification can be done using any suitable combination of security techniques. For example, cryptographic mechanisms such as encryption, digital signatures, digital certificates, message authentication codes, and the like can be employed, e.g., as described elsewhere herein, to protect the DRM engine, host application, and/or other system software or hardware from tampering and/or other attack, as could structural and/or tactical security measures such as software obfuscation, self-checking, customization, watermarking, anti-debugging, and/or other mechanisms. Representative examples of such techniques can be found, for example, in U.S. Pat. No. 6,668,325 B1, Obfuscation Techniques for Enhancing Software Security, and in commonly assigned U.S. patent application Ser. No. 11/102,306, published as US-2005-0183072-A1; U.S. patent application Ser. No. 09/629,807; U.S. patent application Ser. No. 10/172,682, published as US-2003-0023856-A1; U.S. patent application Ser. No. 11/338,187, published as US-2006-0123249-A1; and U.S. Pat. No. 7,124,170 B1, Secure,Processing Unit Systems and Methods, each of which is hereby incorporated by reference herein in its entirety. Alternatively or in addition, physical security techniques (e.g., the use of relatively inaccessible memory, secure processors, secure memory management units, hardware-protected operating system modes, and/or the like) can be used to further enhance security. Such security techniques will be well-known to one of ordinary skill in the art, and it will be appreciated that any suitable combination of some, none, or all of these techniques could be used depending on desired level of protection and/or the details of the particular application at hand. Thus, it will be appreciated that while certain security mechanisms (e.g., key derivation techniques, digital signature techniques, encryption techniques, and the like) are described herein in connection with certain embodiments, use of these techniques is not required in all embodiments.

1003Yet another form of security can be provided by the institutional design and operation of the system, and by the legal and social regulation of the participants therein. For example, in order to obtain a personality node, keying material, protected content, and/or the like, a device or entity may be required to contractually agree to adhere to system specifications and requirements, may need to submit to a certification process during which the entity's compliance with system requirements could be verified, and/or the like. For example, a device or application may be required to implement the DRM engine in a way that is compatible with other implementations in the environment, and/or be required to provide a certain type or level of tamper resistance or other security. Digital certificates could be issued that attested to a device's or other entity's compliance with such requirements, and these certificates could be verified before allowing the device or entity to participate in the system, or as a condition of allowing continuing access.

1004Additional, non-limiting information on security techniques that can be used in connection with the inventive body of work is provided below.

1005System Security

1006In some embodiments, a system designer may choose to use a combination of renewability, refusal, and/or remediation techniques to manage risks and mitigate threats that may arise from attacks on and compromise of devices, applications, and services. Examples of various technical mechanisms that can be used to mitigate threats are presented below.

1007Renewal mechanisms can be used to serve at least two distinct purposes. First, they can be used to convey up-to-date information to trusted system entities that allow them to refuse access or service to untrusted system entities. Second, renewal mechanisms enable an untrusted entity to regain trusted status by updating any compromised component(s). Refusal countermeasures can be further characterized as exhibiting one or more of the following behaviors: <ul id="ul0030" list-style="none"><li id="ul0030-0001" num="1008"> Revocation, or annulling a credential (typically by blacklisting some entity) </li><li id="ul0030-0002" num="1009"> Exclusion, or denying access by applying cryptographic or policy enforcement mechanisms </li><li id="ul0030-0003" num="1010"> Shunning, or denying access or a service based on an identity or some other attribute bound to a credential </li><li id="ul0030-0004" num="1011"> Expiration, or annulling a credential or privilege based on a temporal event. </li></ul>

1012For example, refusal mechanisms can be used to counter threats such as device cloning, impersonation attack, protocol failures, policy enforcement failures, application security failures, and stale or suspicious information.

1013The following table provides examples of potential threats, some of the risks they pose, and mechanisms to remedy the threat and renew system security. <tables id="TABLE-US-00087" num="87"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="56PT" align="left" /><colspec colname="2" colwidth="91PT" align="left" /><colspec colname="3" colwidth="56PT" align="left" /><colspec colname="4" colwidth="56PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row><row><entry /><entry /><entry>Remediation</entry><entry>Renewal</entry></row><row><entry>Threat</entry><entry>Risks</entry><entry>Mechanism</entry><entry>Mechanism</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Cloned Device</entry><entry>Free-access devices.</entry><entry>Broadcast</entry><entry>BKB Update.</entry></row><row><entry /><entry /><entry>Encryption</entry></row><row><entry>Compromised</entry><entry>Unauthorized licenses,</entry><entry>Certificate</entry><entry>CRL Distribution.</entry></row><row><entry>Certified Key</entry><entry>links, device state,</entry><entry>Revocation</entry><entry>Key renewal.</entry></row><row><entry /><entry>identities, service access.</entry></row><row><entry>Implementation</entry><entry>Recipes for device</entry><entry>Specification</entry><entry>Software upgrade</entry></row><row><entry>Failure</entry><entry>hacking.</entry><entry>Version Assertion</entry></row><row><entry>Protocol Failure</entry><entry>Compromised keys.</entry><entry>Security Metadata</entry><entry>Software upgrade</entry></row><row><entry /><entry>Ungoverned access to</entry><entry>Assertion</entry></row><row><entry /><entry>licensed content.</entry></row><row><entry>Stale Security</entry><entry>Bogus service interaction.</entry><entry>Security Metadata</entry><entry>Security Metadata</entry></row><row><entry>Metadata</entry><entry>Clock rollback, reliance</entry><entry>Assertion</entry><entry>update service.</entry></row><row><entry /><entry>on compromised information.</entry><entry /><entry>Software upgrade.</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

1014Revocation

1015Revocation can be viewed as a remediation mechanism that relies on blacklisting an entity. Typically, what is revoked is a credential such as a public-key certificate. Upon revoking the credential, the blacklist will need to be updated and a renewal mechanism used to convey the update so that a relying party may benefit therefrom.

1016Thus, for example, devices, users, and/or other entities can be required to present identity certificates, other credentials, and a variety of security data before they are given the information necessary to consume content or a service. Similarly, in order for a client to trust a service, the service may need to provide its credentials to the client.

1017Examples of ways that an entity can effectively invalidate information necessary for accessing a service include: <ul id="ul0031" list-style="none"><li id="ul0031-0001" num="1018"> Certificate Revocation Lists (CRLs) </li><li id="ul0031-0002" num="1019"> Credential and data validity services, such as an Online Certificate Status Protocol (OCSP) responder </li><li id="ul0031-0003" num="1020"> Commands for self-destruction of credentials and data </li></ul>

1021Certificate Revocation Lists (CRLs)

1022Revocation lists can be used by different entities to revoke identity certificates, licenses, links, and other security assertions. This mechanism is most effective to remedy the situation which results from a service being compromised. A number of techniques can be used for distributing CRLs. For example, some systems may employ an indirect CRL, so that there is a single CRL governing the entire ecosystem. In addition, entities can advertise (or publish) the CRL(s) in their possession, and/or subscribe to an update service. CRL(s) can be distributed peer-to-peer in a viral fashion and/or portable devices can receive published CRL(s) when tethered. The service orchestration techniques described in the '551 application can also be used for this purpose.

1023Validity Services

1024Validity services can be used to provide up-to-date information on the status of credentials and other security related data. Validity services can perform either active validation operations on behalf of a relying party or they can be used to manage security information on behalf of relying parties. An example of an active validity service is one that can check the validity of a credential or attribute. Examples of validity services that manage security information are those which disseminate CRL or security policy updates, or provide a secure time service. The use of validity services can help ensure that relying parties have current data to inform governance decisions.

1025Typically, not all system entities will need up-to-the-minute information on the validity of credentials and security data. For example, not all consumer devices will use an Online Certificate Status Protocol (OCSP) service to validate a license server's certificate chain each time a license is used or a new license is obtained. However, a license server may use an OCSP service with some frequency to check the validity of subscriber credentials. Policy (which can be easily updated) can determine when and what services must be used. By providing an opportunity to dynamically update policy, license servers can adapt to operational changes. Thus, security policy can evolve based on experience, technological progress, and market factors.

1026Directed Self-Destruction of Security Objects

1027Self-destruction of credentials and data by an entity is appropriate when the integrity of the entity's security processing is not suspect. When this option is available, it is often the most straightforward, expeditious, and efficient method of revocation. It can be particularly useful when there is little or no suspicion of breach of integrity, and bi-directional communication supports a protocol allowing specific directions for destruction along with verification that destruction has been completed.

1028There are a number of security objects that will often be useful to have destroyed or disabled. For example, when a device leaves a domain, or a content license times out, it will be useful for the associated objects that contain keys and can be used to access content to be destroyed. The agent control programs desdcribed in more detail elsewhere herein are well-suited to the implementation of self-destruction mechanisms. Agents can be crafted to destroy state in secure storage (e.g., the state database) to affect changes in domain membership or to remove keys that are no longer usable (e.g., due to changes in membership or policy).

1029Exclusion

1030Exclusion is a remediation mechanism which bars a bad actor (or group of bad actors) from participating in future consumption of goods and services. Due to the severe consequences exclusion imposes, it is typically only used as a last resort when circumstances warrant. Exclusion relies on a mechanism that effectively blacklists the bad actors, thereby prohibiting them from consuming media and media-related services. Dissemination of the blacklist relies upon a renewal mechanism to enable this remediation. However, exclusion does not necessarily provide a renewal mechanism to restore a bad actor to a trusted status.

1031Key Exclusion

1032Key exclusion is a key management mechanism that is used to broadcast key information to a set of receivers in such a way that at any given time a decision can be made to logically exclude some subset of receivers from the ability to decrypt future content. This is activated by using efficient techniques to construct a Broadcast Key Block (BKB) that includes information necessary for each member of a large group of receivers to decrypt content. The BKB is structured in such a way that it can be easily updated, excluding one or more members of the group from the ability to decrypt the content. In other words, the design of the BKB allows for an authority to update the system with a new BKB, so that a content provider can specifically exclude a target set of devices from making use of the BKB, even though s/he may have access to it.

1033This mechanism is particularly effective against a cloning attack, where a pirate reverse engineers a legitimate device, extracts its keys, and then deploys copies of those keys to clone devices. The clones externally act like the original, except that these clones will not necessarily adhere to the governance model. Once the compromise is discovered, an updated BKB can be deployed that excludes the compromised device and all of its clones. However, key exclusion incurs some storage, transport, and computation overhead that in some situations make it less efficient than other methods. This is especially true when the content is not broadcast or when there is a back channel.

1034Shunning

1035Shunning is a remediation mechanism very similar in behavior to exclusion but with less severe repercussions. Essentially, it is a means for refusing service because of a runtime policy decision. Instead of more heavy-handed approaches to disable a device's capability through directed self-destruction or access denial via key exclusion, shunning offers a simple approach to disabling a device by having service providers refuse to supply it with services. With the current trend towards extending the value of devices by using externally provided services, shunning becomes a more effective security mechanism.

1036Device shunning is driven by policy and can be used to discriminate against entities (e.g., clients, servers, and specific role players) that do not produce all of the appropriate credentials that policy requires. Policy could, for example, require that an entity demonstrate it has administered the latest security update. Therefore shunning can be either a consequence of revocation or the failure to take some specific action. Shunning can be facilitated in a peer-to-peer fashion using the inspection services and services such as those describe in the '551 application. Also, a data certification service (e.g., an instance of a validity service) can perform shunning at policy enforcement time. After a system entity has been shunned, it can be informed of the specific credential or object that is failing to comply with the policy of the service. This can trigger the shunned entity to renew the object through an appropriate service interface.

1037Expiration

1038Expiration is a remediation mechanism that relies upon some temporal event to invalidate a credential or object. Expiration is effective in enabling temporary access to media or media services; once these have expired, the governance model ensures that access is no longer permitted. Effective use of expiration may require renewal mechanisms whereby the credential or object can be refreshed to enable continued access to media or media services.

1039Expiration of Credentials

1040Certified keys can have various expiry attributes assigned to protect relying parties. Expiration of credentials can be used to ensure that entities whose certificates have expired are refused service and used in conjunction with key rollover and key renewal procedures. When entities are expected to be frequently connected to a wide area network, best-practice dictates renewing credentials and other security data regularly. Another best-practice is to keep the validity period of these objects as short as reasonable. Various techniques such as overlapping validity periods and grace periods in validity checking policies can be used to ensure smooth operation during transitions. Short validity periods also help to reduce the size of CRLs.

1041Expiration of Links

1042As previously described, link objects may be assigned validity periods. Upon expiration, a link is deemed invalid and a DRM engine will not consider it in the construction of its graph. This mechanism can be used to enable temporary access to goods and services. Links can be renewed so that continued access to media may be granted as long as it is permitted by policy. Because, in one embodiment, links are relatively lightweight, self-protected objects they can be easily distributed over peer-to-peer protocols.

1043Renewability Mechanisms: Application and Policy Renewability

1044Efficient renewability will typically entail the rapid deployment of remedies to protocol failures, which are often the dominant security problems seen in security applications (including in DRM systems). Software updates can then be used to update the business logic and security protocols. When applications are designed to separate security policy and trust policy from application logic, a separate mechanism can be used to update policy; this is a less risky approach. In fact, peer-to-peer publishing mechanisms can be used to rapidly update policy. Otherwise, the application deployer's software update methods can be used to update security and trust policy.

1045Using the Right Tool for the Right Job

1046It will generally be desirable to use relatively lightweight tools when possible. Using credentials with limited validity periods and policies that check validity dates can help keep the overall population of entities to a manageable size and eliminate the need for growing CRLs too rapidly. Shunning an entity rather than excluding it from access to keys can extend the lifetime of BKBs; moreover, it has the advantage of enabling fine-grained policies that can be temporary and change with circumstances. Different CRLs that track specific types of credentials of interest to different role players can be used instead of BKBs which can be deployed where they are most effective (such as dealing with cloned receivers). Policies can direct the use of online validity services when those services can be expected to provide a reasonable return on investment of time and effort, where fresh credentials are very important, and where slower revocation mechanisms are inadequate. When a node is likely to have integrity and can be expected to do the right thing, and when a license or security object (such as a link for a subscription or a domain link) needs to be revoked, then a reasonable approach will typically be to tell the node to destroy the object. In such a situation, there is no need to tell the world that the license is invalid and there is no need to deploy a BKB or re-key a domain. Self-destruction driven by local policy or by an authoritative command is one of the more efficient methods for revocation.

1047It will be appreciated that while a variety of revocation, renewal, remediation, and other technologies and practices have been described, it will be appreciated that different situations call for different tools, and that preferred embodiments of the systems and methods described herein can be practiced using any suitable combination of some or none of these techniques.

1048Network Services Security

1049The following discussion illustrates some of the security considerations and techniques that can be relevant to embodiments in which the DRM engine and applications described above are used in connection with networked service orchestration systems and methods such as those described in the '551 application.

1050Practical implementations of DRM systems employing a DRM engine and architecture such as those disclosed herein will often perform networked transactions for accessing content and DRM objects. In such a context, the systems and methods described in the '551 application can be used to inter alia standardize message-layer security, including entity authentication and formats for authorization attributes (roles).

1051For the sake of discussion, the transactions that occur in a DRM system can be separated into at least two general categories based on the type of information being accessed, acquired, or manipulated:

1052Content Access Transactions involve direct access to or manipulation of media or enterprise content or other sensitive information protected by the DRM system. Examples of content access transactions include rendering a protected video clip, burning a copy of a protected audio track to a compact disc, moving a protected file to a portable device, emailing a confidential document, and the like. Content access transactions typically involve direct access to a content protection key and are performed at the point of consumption under the direction of a user.

1053Object Transactions are transactions in which a user or system acquires or interacts with objects defined by the DRM system that in some way govern access to protected content. Such objects include DRM licenses, membership tokens, revocation lists, and so forth. One or more object transactions are usually required before all of the collateral necessary to perform a content access transaction is available. Object transactions are typically characterized by the use of some type of communications network to assemble DRM objects at the point of consumption.

1054These two types of transactions define two points of governance that are generally relevant to most DRM systems. <figref idref="DRAWINGS">FIG. 38</figref> shows a typical pair of interactions in which a DRM-enabled client <b>3800</b> requests a DRM license <b>3802</b> from an appropriate DRM license service <b>3804</b>. In the example shown in <figref idref="DRAWINGS">FIG. 38</figref>, the DRM license <b>3802</b> is sent from the DRM license service <b>3804</b> to the client <b>3800</b>, where it is evaluated in order to provide access to content <b>3806</b>.

1055DRM systems typically require that both content access and object transactions be performed in a manner that prevents unauthorized access to content and creation of objects that protect the content. However, the security concerns for the two types of transactions are naturally different. For example:

1056Content Access Transactions may require authenticating a human principal, checking a secure render count, evaluating a DRM license to derive a content protection key, etc. A major threat against legitimate execution of a content access transaction is breach of the tamper-resistant boundary that protects the objects and the data inside.

1057Object Transactions usually involve a communications channel between the entity that requires the DRM object and the entity that can provide it. As such, object transactions face communications-based threats such as man-in-the-middle attacks, replay attacks, denial-of-service attacks, and attacks in which unauthorized entities acquire DRM objects that they should not legitimately possess.

1058In general, object transactions involve authentication of two interacting entities, the protection of the messages passed between them, and authorization of the transaction. The primary purpose of such transactions is to gather integrity-protected DRM objects from legitimate sources so that content access transactions can be performed. From the perspective of a content access transaction, the mechanisms by which legitimate DRM objects are obtained and the collateral information used in obtaining them are essentially irrelevant; these mechanisms can (and preferably should) be invisible to the content access itself. This natural separation of concerns leads, in a preferred embodiment, to a layered communications model that distinguishes the trusted communications framework from applications that are built on top of it.

1059The simplified license acquisition and consumption example shown in <figref idref="DRAWINGS">FIG. 38</figref> obscures some details that will generally be important in practical applications. For example, it does not show how the DRM license service verifies that the entity requesting a DRM license is in fact a legitimate DRM client and not a malicious entity attempting to obtain an unauthorized license or to deny service to legitimate clients by consuming network bandwidth and processing power. Nor does it show how sensitive information is protected for confidentiality and integrity as it moves through the communications channels connecting the client and service.

1060A more detailed view of this example transaction is shown in <figref idref="DRAWINGS">FIG. 39</figref>. Referring to <figref idref="DRAWINGS">FIG. 39</figref>, the dotted line represents the logical transaction from the point of view of the application-layer content rendering client <b>3800</b> and DRM license server <b>3804</b>. The stack <b>3900</b> below represents the layers of processing used to ensure trusted and protected delivery between the two endpoints.

1061In <figref idref="DRAWINGS">FIG. 39 a</figref> rendering client <b>3800</b> requests a license <b>3802</b> from a DRM license server <b>3804</b>. The dotted line in the diagram indicates that the original source and ultimate consumer of the information are the content rendering client <b>3800</b> and the DRM license server <b>3804</b>. However, in practice the message payload may actually be handled by several layers of processing interposed between the application-layer logic and the unsecured communications channel <b>3902</b> connecting the two endpoints.

1062The processing layers that separate the application layer components from the unsecured communications channel will be referred to collectively as the security stack. The security stack can be thought of as a secure messaging framework that ensures integrity-protected, confidential delivery of messages between trusted endpoints. The layered stack model offers advantages such as:

1063(1) Designers of the application layer logic do not need to expend effort developing the underlying secure communications mechanisms that connect endpoints. The trusted messaging infrastructure is a common design pattern that, once designed, can be deployed in many different situations regardless of the application layer logic that they are supporting.

1064(2) The messaging framework itself can remain agnostic to the precise semantics of the messages it is conveying and focus its efforts on preventing communications-related attacks and attacks on the authenticity of the messaging endpoints.

1065In one embodiment, the security stack consists of several distinct layers of processing, as described below. In one embodiment the service orchestration systems and methods described in the '551 application can be used to provide some or all of the operations of the security stack.

1066Authentication

1067In one embodiment, messaging endpoints may be authenticated. Authentication is a process by which a given endpoint demonstrates to another that it has been given a valid name by an authority trusted for this purpose. The naming authority should be trusted by the relying endpoint in a transaction; establishing such an authority is typically undertaken by the organizations deploying the trusted technology.

1068A common mechanism for demonstrating possession of a valid name uses public key cryptography and digital signatures. Using this approach, an entity is provided with three pieces of information:

1069(1) A distinguished name that provides an identifier for the entity;

1070(2) An asymmetric key pair, consisting of a public key and a secret private key; and

1071(3) A digitally signed certificate that asserts that the holder of the private key has the given distinguished name.

1072The certificate binds the distinguished name and the private key. An entity that uses the private key to sign a piece of information is trusted to have the given distinguished name. The signature can be verified using only the public key. For example, authentication can be based on the X.509v3 standard.

1073Since, in one embodiment, an entity that can demonstrate possession of a certified private key is trusted to have the distinguished name indicated in the certificate, protecting the private key used to sign information becomes an important consideration. In effect, the ability to use the private signing key defines the boundaries of the entity identified by the distinguished name. At the application layer, senders and recipients need to know that messages originate from trusted counterparts. As such, in one embodiment it is important that the application layer logic itself be part of the authenticated entity. For this reason, in one embodiment the security stack and the application layers that rely upon it are preferably enclosed in a trust boundary, such that a subsystem contained within the trust boundary is assumed to share access to the entity's private message signing key.

1074Authorization

1075The authentication mechanism described above proves to distributed messaging endpoints that their correspondent's identity is trustworthy. In many applications, this information is too coarse—more detailed information about the capabilities and properties of the endpoints may be needed to make policy decisions about certain transactions. For example, in the context of <figref idref="DRAWINGS">FIG. 38</figref>, the content rendering client may need to know not only that it is communicating with an authenticated endpoint, but also whether it is communicating with a service that has been deemed competent to provide valid DRM license objects.

1076Embodiments of the security stack provide a mechanism for asserting, conveying, and applying policy that is based on more fine-grained attributes about authenticated entities via an authorization mechanism. Using this mechanism, entities that already possess authentication credentials are assigned role assertions that associate a named set of capabilities with the distinguished name of the entity. For example, role names can be defined for a DRM client and a DRM license server.

1077The named roles are intended to convey specific capabilities held by an entity. In practice, roles can be attached to an entity by asserting an association between the entity's distinguished name and the role name. As with authentication certificates, which associate keys with distinguished names, in one embodiment role assertions used for authorization are signed by a trusted role authority that may be different from the name issuer. Inside an entity, role assertions are verified along with the authentication credentials as a condition for granting access to a messaging endpoint's application layer.

1078An entity may hold as many role attributes as are required by the application being built. The example in <figref idref="DRAWINGS">FIG. 40</figref> shows an entity with multiple roles: one role that indicates the ability to function as a DRM client and two service roles. For example, one entity may be simultaneously a DRM client, a DRM object provider, and a security data provider. In one embodiment, SAML 1.1 is used for assertions regarding entity attributes.

1079Message Security

1080The bottom layer of the security stack is the message security layer, which provides integrity, confidentiality, and freshness protection for messages, and mitigates the risk of attacks on the communications channel such as replay attacks. In the message security layer: <ul id="ul0032" list-style="none"><li id="ul0032-0001" num="1081"> Messages between application layer processes are signed using the entity's private message signing key, providing integrity protection and resistance to man-in-the-middle attacks. </li><li id="ul0032-0002" num="1082"> Messages are encrypted using a public key held by the destination entity. This guarantees that unintended recipients cannot read messages intercepted in transit. </li><li id="ul0032-0003" num="1083"> Nonces and timestamps are added to the message, providing immunity to replay attacks and facilitating proofs of liveness between the messaging endpoints. </li><li id="ul0032-0004" num="1084"> Using server timestamps for updating trusted time of the DRM engine </li></ul>

1085In one illustrative embodiment, support is provided for AES symmetric encryption, RSA public key cryptography, SHA-256 signature digests, and mechanisms to signal other algorithms in messages.

000015. Bootstrap Protocol

1086In some embodiments, a bootsrap protocol is used to deliver initial confidential configuration data to entities such as devices and software clients. For example, when an entity wishes to to join a larger network or system and communicate with other entities using cryptographic protocols, it may need to be configured with personalized data, including a set of keys (shared, secret, and public). When it is not possible or practical for the entity to be pre-configured with personalized data, it will need to “bootstrap” itself using a cryptographic protocol.

1087The example protocol described below uses a shared secret as the basis for bootstrapping an entity with a set of keys and other configuration data. In the following sections, the following notation will be used: <ul id="ul0033" list-style="none"><li id="ul0033-0001" num="0000"><ul id="ul0034" list-style="none"><li id="ul0034-0001" num="1088"> E (K, D) is the encryption of some data D with a key K. </li><li id="ul0034-0002" num="1089"> D (K, D) is the decryption of some encrypted data D with a key K. </li><li id="ul0034-0003" num="1090"> S (K, D) is the signature of some data D with a key K. This can be a Public Key signature, or a MAC. </li><li id="ul0034-0004" num="1091"> H (D) is the message digest of data D. </li><li id="ul0034-0005" num="1092"> V (K, D) is the verification of the signature over some data D with a key K. It can be the verification of a Public Key signature or of a MAC. </li><li id="ul0034-0006" num="1093"> CertChain (K) is the certificate chain associated with Public Key K. The value of K is included in the first certificate in the chain. </li><li id="ul0034-0007" num="1094"> CertVerify(RootCert, CertChain) is the verification that the certificate chain CertChain (including the Public Key found in the first certificate of the chain) is valid under the root certificate RootCert </li><li id="ul0034-0008" num="1095"> A|B|C| . . . is the byte sequence obtained by concatenating the individual byte sequences A, B, C, . . . </li><li id="ul0034-0009" num="1096"> CN (A) is the canonical byte sequence for A </li><li id="ul0034-0010" num="1097"> CN (A, B, C, . . . ) is the canonical byte sequence for compound fields A, B, C . . . </li></ul></li></ul>

10981.38. Initial State

10991.38.1. Client

1100In one embodiment, the client has the following set of bootstrap tokens (preloaded at manufacturing time and/or in firmware/software): <ul id="ul0035" list-style="none"><li id="ul0035-0001" num="0000"><ul id="ul0036" list-style="none"><li id="ul0036-0001" num="1101"> One or more read-only certificates that are the root of trust for the bootstrap process: BootRootCertificate </li><li id="ul0036-0002" num="1102"> One or more secret Bootstrap Authentication Keys: BAK (shared) </li><li id="ul0036-0003" num="1103"> An optional secret Bootstrap Seed Generation Key (unique to each client) BSGK. If the client has a good source of random data, this seed is not needed. </li><li id="ul0036-0004" num="1104"> Some information, ClientInformation, the client will need to give to the Bootstrap service in order to get its confidentiality key (e.g., ClientInformation can include a device's serial number, the name of the manufacturer, etc.). This information consists of a list of attributes. Each attribute is a (name, value) pair. </li></ul></li></ul>

1105The client may be configured with multiple BootRootCertificate certificates and BAK authentication keys, in order to be able to participate in the Boot Protocol with different Boot Servers that may require different trust domains.

11061.38.2. Server

1107In one embodiment the server has the following tokens: <ul id="ul0037" list-style="none"><li id="ul0037-0001" num="0000"><ul id="ul0038" list-style="none"><li id="ul0038-0001" num="1108"> At least one of the client's Bootstrap Authentication Keys: BAK (the shared secret) </li><li id="ul0038-0002" num="1109"> A Public/Private Key pair used for signature: (Es, Ds) </li><li id="ul0038-0003" num="1110"> A certificate chain ServerCertificatechain=CertChain(Es) that is valid under one of the root certificates: BootRootCertificate </li><li id="ul0038-0004" num="1111"> A Public/Private Key Pair used for Encryption: (Ee/De) 1.39. Protocol Description </li></ul></li></ul>

1112An illustrative embodiment of a bootstrap protocol is shown in <figref idref="DRAWINGS">FIG. 41</figref> and described below. A failure during the process (for example, when verifying a signature or a certificate chain) will lead to an error and stop the protocol progression.

1113BootstrapRequestMessage

1114The client sends a request to the server, indicating that it wants to initiate a bootstrap session and provides some initial parameters (e.g., protocol version, profile, etc.), as well as a session ID (to prevent replay attacks) and a list of Trust Domains in which it can participate. The following table shows an illustrative format for a BootStrapRequestMessage: <tables id="TABLE-US-00088" num="88"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="35PT" align="left" /><colspec colname="2" colwidth="252PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Name</entry><entry>BootstrapRequestMessage</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="35PT" align="left" /><colspec colname="2" colwidth="28PT" align="left" /><colspec colname="3" colwidth="224PT" align="left" /><tbody valign="top"><row><entry>Attributes</entry><entry>Name</entry><entry>Description</entry></row><row><entry /><entry>Protocol</entry><entry>Symbolic name of the protocol</entry></row><row><entry /><entry>Version</entry><entry>Protocol Version</entry></row><row><entry /><entry>Profile</entry><entry>Name of the Profile for this protocol/version</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="35PT" align="left" /><colspec colname="2" colwidth="252PT" align="left" /><tbody valign="top"><row><entry>Direction</entry><entry>Client → Server</entry></row><row><entry>Payload</entry><entry>BootstrapRequest</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="OFFSET" colwidth="35PT" align="left" /><colspec colname="1" colwidth="49PT" align="left" /><colspec colname="2" colwidth="49PT" align="left" /><colspec colname="3" colwidth="154PT" align="left" /><tbody valign="top"><row><entry /><entry>Name</entry><entry>Type</entry><entry>Description</entry></row><row><entry /><entry>SessionId</entry><entry>String</entry><entry>Unique session ID chosen by the client</entry></row><row><entry /><entry>TrustDomains</entry><entry>List of Strings</entry><entry>Names of all the Trust Domains in which the client</entry></row><row><entry /><entry /><entry /><entry>can participate.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="35PT" align="left" /><colspec colname="2" colwidth="252PT" align="left" /><tbody valign="top"><row><entry>Expected</entry><entry>ChallengeRequestMessage</entry></row><row><entry>Response</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

1115The Protocol and version message attributes specify which protocol specification the client is using, and the Profile field identifies a predefined set of cryptographic protocols and encoding formats used for exchanging messages and data.

1116The Client chooses a SessionId, which should be unique to that client and not re-used. For example, a unique ID for the client and an incrementing counter value can be used as a way to generate a unique session ID.

1117In one embodiment, the Client also sends a list of all the Trust Domains for which it has been configured.

1118In one embodiment, the server receives the BootstrapRequestMessage and performs the following steps: <ul id="ul0039" list-style="none"><li id="ul0039-0001" num="0000"><ul id="ul0040" list-style="none"><li id="ul0040-0001" num="1119"> Checks that it supports the specified Protocol,Version, and Profile requested by the client. </li><li id="ul0040-0002" num="1120"> Generates a Nonce (strongly random number). </li><li id="ul0040-0003" num="1121"> Optionally generates a Cookie in order to carry information such as a timestamp, session token, or any other server-side information that will persist throughout the session. The value of the cookie is meaningful only to the server, and is considered as an opaque data block by the client. </li><li id="ul0040-0004" num="1122"> Extract the value of SessionId from the BootstrapRequestMessage. </li><li id="ul0040-0005" num="1123"> Generate a challenge: Challenge=[Nonce, Ee, Cookie, SessionId]. </li><li id="ul0040-0006" num="1124"> Compute S (Ds, Challenge) to sign the challenge with Ds. </li><li id="ul0040-0007" num="1125"> Construct a ChallengeRequestMessage and send it back to the client in response. </li></ul></li></ul>

1126ChallengeRequestMessage

1127The following table shows an illustrative format for a ChallengeRequestMessage: <tables id="TABLE-US-00089" num="89"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="49PT" align="left" /><colspec colname="2" colwidth="231PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Name</entry><entry>ChallengeRequestMessage</entry></row><row><entry>Direction</entry><entry>Server → Client</entry></row><row><entry>Payload</entry><entry>Challenge</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="OFFSET" colwidth="49PT" align="left" /><colspec colname="1" colwidth="70PT" align="left" /><colspec colname="2" colwidth="49PT" align="left" /><colspec colname="3" colwidth="112PT" align="left" /><tbody valign="top"><row><entry /><entry>Name</entry><entry>Type</entry><entry>Description</entry></row><row><entry /><entry>Nonce</entry><entry>Byte Sequence</entry><entry>Server-generated random nonce</entry></row><row><entry /><entry>ServerEncryptionKey</entry><entry>Byte Sequence</entry><entry>Encoded Public Key Ee used for</entry></row><row><entry /><entry /><entry /><entry>message payload encryption</entry></row><row><entry /><entry>Cookie</entry><entry>Byte Sequence</entry><entry>Server-generated opaque data</entry></row><row><entry /><entry>SessionId</entry><entry>String</entry><entry>Client-generated session ID</entry></row><row><entry /><entry>Signature</entry><entry>Byte Sequence</entry><entry>Encoded Digital Signature S(Ds,</entry></row><row><entry /><entry /><entry /><entry>CN(Challenge)) of the</entry></row><row><entry /><entry /><entry /><entry>Challenge's canonical byte sequence</entry></row><row><entry /><entry /><entry /><entry>Canon(Challenge) =</entry></row><row><entry /><entry /><entry /><entry>CN(CN(Nonce),</entry></row><row><entry /><entry /><entry /><entry>CN(ServerEncryptionKey),</entry></row><row><entry /><entry /><entry /><entry>CN(Cookie), CN(SessionId))</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="49PT" align="left" /><colspec colname="1" colwidth="231PT" align="left" /><tbody valign="top"><row><entry /><entry>ServerCertificateChain</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="OFFSET" colwidth="49PT" align="left" /><colspec colname="1" colwidth="42PT" align="left" /><colspec colname="2" colwidth="42PT" align="left" /><colspec colname="3" colwidth="147PT" align="left" /><tbody valign="top"><row><entry /><entry>Name</entry><entry>Type</entry><entry>Description</entry></row><row><entry /><entry>TrustDomain</entry><entry>String</entry><entry>Trust Domain in which the certificate chain is</entry></row><row><entry /><entry /><entry /><entry>valid</entry></row><row><entry /><entry>Certificates</entry><entry>List of Byte</entry><entry>An list of Encoded Certificates that form a</entry></row><row><entry /><entry /><entry>Sequences</entry><entry>chain: CertChain(Es). The first certificate</entry></row><row><entry /><entry /><entry /><entry>in the array certifies the Public Key Es, and</entry></row><row><entry /><entry /><entry /><entry>each of the following certificates, in turn,</entry></row><row><entry /><entry /><entry /><entry>certify the Public Key of the preceding</entry></row><row><entry /><entry /><entry /><entry>certificate. The last certificate in the array has</entry></row><row><entry /><entry /><entry /><entry>a public key certified by the Root CA</entry></row><row><entry /><entry /><entry /><entry>Certificate for the Trust Domain</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="49PT" align="left" /><colspec colname="2" colwidth="231PT" align="left" /><tbody valign="top"><row><entry>In Response To</entry><entry>BootstrapRequestMessage</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

1128In one embodiment, after receiving the ChallengeRequestMessage, the client performs the following steps: <ul id="ul0041" list-style="none"><li id="ul0041-0001" num="0000"><ul id="ul0042" list-style="none"><li id="ul0042-0001" num="1129"> Verify that the certificate chain ServerCertificateChain is valid under the root certificate BootRootCertificate: </li><li id="ul0042-0002" num="1130"> CertVerif(BootRootcertificate, ServerCertificatechain). </li><li id="ul0042-0003" num="1131"> Extract the Public Key Es from the ServerCertificateChain. </li><li id="ul0042-0004" num="1132"> Verify the signature of the challenge: V (Es, Challenge). </li><li id="ul0042-0005" num="1133"> Check that the SessionId matches the one chosen for the session when the BootRequestMessage was sent. </li><li id="ul0042-0006" num="1134"> Construct a ChallengeResponseMessage and send it to the server. </li></ul></li></ul>

1135ChallengeResponseMessage

1136To generate a ChallengeResponseMessage, the client performs the following steps: <ul id="ul0043" list-style="none"><li id="ul0043-0001" num="0000"><ul id="ul0044" list-style="none"><li id="ul0044-0001" num="1137"> Generate a Session Key SK using one of the two following methods: <ul id="ul0045" list-style="none"><li id="ul0045-0001" num="1138"> Directly using a secure random key generator </li><li id="ul0045-0002" num="1139"> Indirectly using the Nonce and BSGK: compute HSK=H (BSGK|Nonce), and set SK=First N bytes of HSK </li></ul></li><li id="ul0044-0002" num="1140"> Generate a ChallengeRepsonse object that contains [Challenge, ClientInformation, SessionKey]. Here, the Challenge is the one from the previously received ChallengeRequestMessage, with the ServerEncryptionKey omitted. </li><li id="ul0044-0003" num="1141"> Compute S (BAK, ChallengeResponse) to sign the response with BAK. </li><li id="ul0044-0004" num="1142"> Encrypt the signed ChallengeReponse with SK: E(SK, [ChallengeResponse, S (BAK, ChallengeResponse)]) </li><li id="ul0044-0005" num="1143"> Encrypt the SessionKey with the Server's Public Key Ee </li></ul></li></ul>

1144Construct a ChallengeResponseMessage and send it to the server <tables id="TABLE-US-00090" num="90"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="35PT" align="left" /><colspec colname="2" colwidth="252PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Name</entry><entry>ChallengeResponseMessage</entry></row><row><entry>Direction</entry><entry>Client → Server</entry></row><row><entry>Payload</entry><entry>SessionKey [encrypted with Ee]</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="OFFSET" colwidth="35PT" align="left" /><colspec colname="1" colwidth="42PT" align="left" /><colspec colname="2" colwidth="35PT" align="left" /><colspec colname="3" colwidth="175PT" align="left" /><tbody valign="top"><row><entry /><entry>Name</entry><entry>Type</entry><entry>Description</entry></row><row><entry /><entry>SessionKey</entry><entry>Byte</entry><entry>Encoded Session key SK encrypted with the Server's Public</entry></row><row><entry /><entry /><entry>Sequence</entry><entry>Key Ee</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="35PT" align="left" /><colspec colname="1" colwidth="252PT" align="left" /><tbody valign="top"><row><entry /><entry>ChallengeResponse [encrypted with SK]</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="OFFSET" colwidth="35PT" align="left" /><colspec colname="1" colwidth="56PT" align="left" /><colspec colname="2" colwidth="35PT" align="left" /><colspec colname="3" colwidth="161PT" align="left" /><tbody valign="top"><row><entry /><entry>Name</entry><entry>Type</entry><entry>Description</entry></row><row><entry /><entry>Challenge</entry><entry>Object</entry><entry>Challenge</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="OFFSET" colwidth="126PT" align="left" /><colspec colname="1" colwidth="35PT" align="left" /><colspec colname="2" colwidth="35PT" align="left" /><colspec colname="3" colwidth="91PT" align="left" /><tbody valign="top"><row><entry /><entry>Name</entry><entry>Type</entry><entry>Description</entry></row><row><entry /><entry>Nonce</entry><entry>Byte</entry><entry>Server-generated</entry></row><row><entry /><entry /><entry>Sequence</entry><entry>random nonce</entry></row><row><entry /><entry>Cookie</entry><entry>Byte</entry><entry>Server-generated</entry></row><row><entry /><entry /><entry>Sequence</entry><entry>opaque data</entry></row><row><entry /><entry>SessionId</entry><entry>String</entry><entry>Unique session</entry></row><row><entry /><entry /><entry /><entry>ID</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="OFFSET" colwidth="35PT" align="left" /><colspec colname="1" colwidth="56PT" align="left" /><colspec colname="2" colwidth="35PT" align="left" /><colspec colname="3" colwidth="161PT" align="left" /><tbody valign="top"><row><entry /><entry>ClientInformation</entry><entry>Array of</entry><entry>Array of 0 or more Attribute Objects:</entry></row><row><entry /><entry /><entry>Attributes</entry><entry>Attribute</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="OFFSET" colwidth="126PT" align="left" /><colspec colname="1" colwidth="35PT" align="left" /><colspec colname="2" colwidth="35PT" align="left" /><colspec colname="3" colwidth="91PT" align="left" /><tbody valign="top"><row><entry /><entry>Name</entry><entry>Type</entry><entry>Description</entry></row><row><entry /><entry>Name</entry><entry>String</entry><entry>Name of the</entry></row><row><entry /><entry /><entry /><entry>attribute</entry></row><row><entry /><entry>Value</entry><entry>String</entry><entry>Value of the</entry></row><row><entry /><entry /><entry /><entry>attribute</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="OFFSET" colwidth="35PT" align="left" /><colspec colname="1" colwidth="56PT" align="left" /><colspec colname="2" colwidth="35PT" align="left" /><colspec colname="3" colwidth="161PT" align="left" /><tbody valign="top"><row><entry /><entry>SessionKey</entry><entry>Byte</entry><entry>Encoded value of secret session key SK</entry></row><row><entry /><entry /><entry>Sequence</entry></row><row><entry /><entry>Signature</entry><entry>Byte</entry><entry>Encoded Digital Signature S(BAK,</entry></row><row><entry /><entry /><entry>Sequence</entry><entry>CN(ChallengeResponse)) of the canonical byte</entry></row><row><entry /><entry /><entry /><entry>sequence CN(ChallengeResponse) = CN</entry></row><row><entry /><entry /><entry /><entry>(CN(Challenge),</entry></row><row><entry /><entry /><entry /><entry>CN(ClientInformation), CN(SessionKey))</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="35PT" align="left" /><colspec colname="2" colwidth="252PT" align="left" /><tbody valign="top"><row><entry>Expected</entry><entry>BootstrapResponseMessage</entry></row><row><entry>Response</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

1145The server receives the BootstrapChallengeResponse and performs the following steps: <ul id="ul0046" list-style="none"><li id="ul0046-0001" num="0000"><ul id="ul0047" list-style="none"><li id="ul0047-0001" num="1146"> Decrypt the session key SK using its private key De: D(De, SessionKey) </li><li id="ul0047-0002" num="1147"> Decrypt the ChallengeResponse with the session key SK from the previous step: D(SK, Challenge) </li><li id="ul0047-0003" num="1148"> Verify the signature of the challenge: V (BAK, ChallengeResponse) </li><li id="ul0047-0004" num="1149"> Check that the session key SK matches the one used to decrypt </li><li id="ul0047-0005" num="1150"> Check the Cookie and Nonce values if needed (e.g., a timestamp) </li><li id="ul0047-0006" num="1151"> Check that the SessionId matches the one chosen for the session when the BootRequestMessage was sent. </li><li id="ul0047-0007" num="1152"> Construct a BootstrapResponseMessage and send it to the Server. </li></ul></li></ul>

1153BootstrapResponseMessage

1154To generate a BootstrapResponseMessage, the server performs the following steps: <ul id="ul0048" list-style="none"><li id="ul0048-0001" num="0000"><ul id="ul0049" list-style="none"><li id="ul0049-0001" num="1155"> Parse the ClientInformation received in the ChallengeResponseMessage and lookup or generate the client configuration Data that needs to be sent for this bootstrap request (this may include confidentiality keys (Ec/Dc) for the node that represents the client). </li><li id="ul0049-0002" num="1156"> The server will typically use the value of the Nonce and Cookie to help retrieve the correct information for the client. </li><li id="ul0049-0003" num="1157"> Create a BootstrapResponse with the SessionId and the configuration Data </li><li id="ul0049-0004" num="1158"> Computes (Ds, BootstrapResponse) to sign Data with Ds </li></ul></li></ul>

1159Encrypt the signed BootstrapResponse with the session key SK: E (SK, [BootstrapResponse, S(Ds, BootstrapResponse)]) <tables id="TABLE-US-00091" num="91"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="49PT" align="left" /><colspec colname="2" colwidth="231PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Name</entry><entry>BootstrapResponseMessage</entry></row><row><entry>Direction</entry><entry>Server → Client</entry></row><row><entry>Payload</entry><entry>BootstrapResponse [encrypted with SK]</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="OFFSET" colwidth="49PT" align="left" /><colspec colname="1" colwidth="35PT" align="left" /><colspec colname="2" colwidth="35PT" align="left" /><colspec colname="3" colwidth="161PT" align="left" /><tbody valign="top"><row><entry /><entry>Name</entry><entry>Type</entry><entry>Description</entry></row><row><entry /><entry>SessionId</entry><entry>String</entry><entry>Session ID</entry></row><row><entry /><entry>Data</entry><entry>Byte</entry><entry>Configuration data for the client</entry></row><row><entry /><entry /><entry>Sequence</entry></row><row><entry /><entry>Signature</entry><entry>Signature</entry><entry>Digital Signature S(Ds, CN(BootstrapResponse)) of</entry></row><row><entry /><entry /><entry /><entry>the canonical byte sequence CN(BootstrapResponse) =</entry></row><row><entry /><entry /><entry /><entry>CN(CN(SessionID), CN(Data))</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="49PT" align="left" /><colspec colname="2" colwidth="231PT" align="left" /><tbody valign="top"><row><entry>In Response To</entry><entry>ChallengeResponseMessage</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

11601.40. Trust Domains

1161In one embodiment, each trust domain includes a Root Certificate Authority and a unique name for the domain. When a client sends a BootstrapRequest, it identifies all the trust domains that it is willing to accept (i.e. which certificates it will consider valid). The server selects a trust domain from the list sent by the client, if it supports any.

11621.41. Signatures

1163In one embodiment, whenever signatures are used in message payloads, the signatures are computed over a canonical byte sequence for the data fields contained in the signed portion(s) of the message. The canonical byte sequence is computed from the field values, not from the encoding of the field values. Each profile preferably defines the algorithm used to compute the canonical byte sequence of the fields for each message type.

11641.42. Profiles

1165A profile of the bootstrap protocol is a set of choices for the various cryptographic ciphers and serialization formats. Each profile preferably has a unique name, and includes choice of: <ul id="ul0050" list-style="none"><li id="ul0050-0001" num="1166"> Public Key Encryption Algorithm </li><li id="ul0050-0002" num="1167"> Public Key Signature Algorithm </li><li id="ul0050-0003" num="1168"> Secret Key Encryption Algorithm </li><li id="ul0050-0004" num="1169"> Secret Key Signature Algorithm </li><li id="ul0050-0005" num="1170"> Public Key encoding </li><li id="ul0050-0006" num="1171"> Digest Algorithm </li><li id="ul0050-0007" num="1172"> Canonical Object Serialization </li><li id="ul0050-0008" num="1173"> Certificate Format </li><li id="ul0050-0009" num="1174"> Minimum Nonce Size </li><li id="ul0050-0010" num="1175"> Message Marshalling </li></ul>

Appendix A

1176The following is an example of a controller object with multiple, interlocking signatures.

1177NOTE: in this example, the content keys are not encrypted <tables id="TABLE-US-00092" num="92"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="308PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry><Controller xmlns=“http://www.intertrust.com/Octopus/1.0” id=“urn:x-</entry></row><row><entry>octopus.intertrust.com:controller:37A50262EE3389A14ABC0BC7BE5D43E5”></entry></row><row><entry><ControlReference></entry></row><row><entry> <Id>urn:x-octopus.intertrust.com:control:0001</Id></entry></row><row><entry><Digest></entry></row><row><entry> <DigestMethod xmlns=“http://www.w3.org/2000/09/xmldsig#”</entry></row><row><entry>Algorithm=“http://www.w3.org/2000/09/xmldsig#sha1” /></entry></row><row><entry> <DigestValue</entry></row><row><entry>xmlns=“http://www.w3.org/2000/09/xmldsig#”>1z95n10V7CBiKs/rSQdXvKyZmfA=</DigestValue></entry></row><row><entry> </Digest></entry></row><row><entry> </ControlReference></entry></row><row><entry><ControlledTargets></entry></row><row><entry><ContentKeyReference></entry></row><row><entry> <Id>urn:x-octopus.intertrust.com:content-key:2001</Id></entry></row><row><entry> </ContentKeyReference></entry></row><row><entry><ContentKeyReference></entry></row><row><entry> <Id>urn:x-octopus.intertrust.com:content-key:2002</Id></entry></row><row><entry> </ContentKeyReference></entry></row><row><entry><ContentKeyReference></entry></row><row><entry> <Id>urn:x-octopus.intertrust.com:content-key:2003</Id></entry></row><row><entry> </ContentKeyReference></entry></row><row><entry> </ControlledTargets></entry></row><row><entry> </Controller></entry></row><row><entry><Signature Id=“Signature.0” xmlns=“http://www.w3.org/2000/09/xmldsig#”></entry></row><row><entry><SignedInfo></entry></row><row><entry> <CanonicalizationMethod Algorithm=“http://www.w3.org/2001/10/xml-exc-c14n#” /></entry></row><row><entry> <SignatureMethod Algorithm=“http://www.w3.org/2000/09/xmldsig#rsa-sha1” /></entry></row><row><entry><Reference URI=“urn:x-octopus.intertrust.com:controller:37A50262EE3389A14ABC0BC7BE5D43E5”></entry></row><row><entry><Transforms></entry></row><row><entry> <Transform Algorithm=“http://www.intertrust.com/Octopus/xmldsig#cbs-1_0” /></entry></row><row><entry> </Transforms></entry></row><row><entry> <DigestMethod Algorithm=“http://www.w3.org/2000/09/xmldsig#sha1” /></entry></row><row><entry> <DigestValue>G1zXF9Sz/zCwH6MaFm0ObOQcxuk=</DigestValue></entry></row><row><entry> </Reference></entry></row><row><entry> </SignedInfo></entry></row><row><entry><SignatureValue>mjoyW+w2S9iZDG/ha4eWYD1RmhQuqRuuSN977NODpzwUD02FdsAICVjAcw7f4n</entry></row><row><entry>FWuvtawW/clFzYP/pjFebESCvurHUsEaR1/LYLDkpWWxh/LlEp4r3yR9kUs0AU5a4BDxDxQE7nUdqU</entry></row><row><entry>9YMpnjAZEGpuxdPeZJM1vyKqNDpTk94=</SignatureValue></entry></row><row><entry><KeyInfo></entry></row><row><entry><X509Data></entry></row><row><entry><X509Certificate>MIIC6jCCAlOgAwIBAgIBBjANBgkqhkiG9w0BAQUFADCBszELMAkGA1UEBhM</entry></row><row><entry>CVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFDASBgNVBAcTC1NhbnRhIENsYXJhMSAwHgYDV</entry></row><row><entry>QQKExdJbnRlcnRydXN0IFRlY2hub2xvZ2llczEUMBIGA1UECxMLT2N0b3B1cyBEUk0xGDAWBgNV</entry></row><row><entry>BAMTD09jdG9wdXMgVGVzdCBDQTEnMCUGCSqGSIb3DQEJARYYb2N0b3B1cy10ZXN0LWNhQ</entry></row><row><entry>DhwdXMubmV0MB4XDTA0MDQwODAwNTUyOVoXDTA0MDUwODAwNTUyOVowgcExCzAJBg</entry></row><row><entry>NVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtTYW50YSBDbGFy</entry></row><row><entry>YTEgMB4GA1UEChMXSW50ZXJ0cnVzdCBUZWNobm9sb2dpZXMxFDASBgNVBAsTC09jdG9wdX</entry></row><row><entry>MgRFJNMR8wHQYDVQQDExZPY3RvcHVzIFRlc3QgTm9kZSAwMDAxMS4wLAYJKoZIhvcNAQkB</entry></row><row><entry>Fh9vY3RvcHVzLXRlc3Qtbm9kZS0wMDAxQDhwdXMubmV0MIGfMA0GCSqGSIb3DQEBAQUAA4</entry></row><row><entry>GNADCBiQKBgQDU8AJQArJg+VTuwUO2fMv5sCtfmZECyJjA0vbgQc+cPXpfeIdACiCL1n1eml/ZLlu</entry></row><row><entry>7ZaRwQeo1yJSeK57bxv+zhW14F1jnqS/IKLG84RG1eoMiOT1lhErb2nU3xT0KCgxsEXFAbfwAYnLX7</entry></row><row><entry>hpy/1ho2mTmJbgksWoPrPw3xMPCYwIDAQABMA0GCSqGSIb3DQEBBQUAA4GBAH1rHStXcQkFm</entry></row><row><entry>cYhl5zck6twsNIRF+/1HZGuTGKeb6+J2ZLk6sNUWXLOlD1oPRMde7X1RiqpDNkbG4xoPoxHiK9Vdf</entry></row><row><entry>Bstjv9Q8iUceziMIXVV/q+XJMd7HfBJq25XqBScS9/RAKKKwuRRkQHEV3uBABvLSCzIRSJH9bFuYz</entry></row><row><entry>NeVne</X509Certificate></entry></row><row><entry> </X509Data></entry></row><row><entry> </KeyInfo></entry></row><row><entry> </Signature></entry></row><row><entry><Signature xmlns=“http://www.w3.org/2000/09/xmldsig#”></entry></row><row><entry><SignedInfo></entry></row><row><entry> <CanonicalizationMethod Algorithm=“http://www.w3.org/2001/10/xml-exc-c14n#” /></entry></row><row><entry> <SignatureMethod Algorithm=“http://www.w3.org/2000/09/xmldsig#hmac-sha1” /></entry></row><row><entry><Reference URI=“#Signature.0”></entry></row><row><entry> <DigestMethod Algorithm=“http://www.w3.org/2000/09/xmldsig#sha1” /></entry></row><row><entry> <DigestValue>AqPV0nvNj/vc51IcMyKJngGNKtM=</DigestValue></entry></row><row><entry> </Reference></entry></row><row><entry><Reference URI=“urn:x-octopus.intertrust.com:controller:37A50262EE3389A14ABC0BC7BE5D43E5”></entry></row><row><entry><Transforms></entry></row><row><entry> <Transform Algorithm=“http://www.intertrust.com/Octopus/xmldsig#cbs-1_0” /></entry></row><row><entry> </Transforms></entry></row><row><entry> <DigestMethod Algorithm=“http://www.w3.org/2000/09/xmldsig#sha1” /></entry></row><row><entry> <DigestValue>G1zXF9Sz/zCwH6MaFm0ObOQcxuk=</DigestValue></entry></row><row><entry> </Reference></entry></row><row><entry> </SignedInfo></entry></row><row><entry> <SignatureValue>TcKBsZZy+Yp3doOkZ62LTfY+ntQ=</SignatureValue></entry></row><row><entry><KeyInfo></entry></row><row><entry> <KeyName>urn:x-octopus.intertrust.com:secret-key:2001</KeyName></entry></row><row><entry> </KeyInfo></entry></row><row><entry> </Signature></entry></row><row><entry><Signature xmlns=“http://www.w3.org/2000/09/xmldsig#”></entry></row><row><entry><SignedInfo></entry></row><row><entry> <CanonicalizationMethod Algorithm=“http://www.w3.org/2001/10/xml-exc-c14n#” /></entry></row><row><entry> <SignatureMethod Algorithm=“http://www.w3.org/2000/09/xmldsig#hmac-sha1” /></entry></row><row><entry><Reference URI=“#0”></entry></row><row><entry> <DigestMethod Algorithm=“http://www.w3.org/2000/09/xmldsig#sha1” /></entry></row><row><entry> <DigestValue>AqPV0nvNj/vc51IcMyKJngGNKtM=</DigestValue></entry></row><row><entry> </Reference></entry></row><row><entry><Reference URI=“urn:x-octopus.intertrust.com:controller:37A50262EE3389A14ABC0BC7BE5D43E5”></entry></row><row><entry><Transforms></entry></row><row><entry> <Transform Algorithm=“http://www.intertrust.com/Octopus/xmldsig#cbs-1_0” /></entry></row><row><entry> </Transforms></entry></row><row><entry> <DigestMethod Algorithm=“http://www.w3.org/2000/09/xmldsig#sha1” /></entry></row><row><entry> <DigestValue>G1zXF9Sz/zCwH6MaFm0ObOQcxuk=</DigestValue></entry></row><row><entry> </Reference></entry></row><row><entry> </SignedInfo></entry></row><row><entry> <SignatureValue>qAunQpXC18kl8Veo8UHbcXTqHCA=</SignatureValue></entry></row><row><entry><KeyInfo></entry></row><row><entry> <KeyName>urn:x-octopus.intertrust.com:secret-key:2002</KeyName></entry></row><row><entry> </KeyInfo></entry></row><row><entry> </Signature></entry></row><row><entry><Signature xmlns=“http://www.w3.org/2000/09/xmldsig#”></entry></row><row><entry><SignedInfo></entry></row><row><entry> <CanonicalizationMethod Algorithm=“http://www.w3.org/2001/10/xml-exc-c14n#” /></entry></row><row><entry> <SignatureMethod Algorithm=“http://www.w3.org/2000/09/xmldsig#hmac-sha1” /></entry></row><row><entry><Reference URI=“#0”></entry></row><row><entry> <DigestMethod Algorithm=“http://www.w3.org/2000/09/xmldsig#sha1” /></entry></row><row><entry> <DigestValue>AqPV0nvNj/vc51IcMyKJngGNKtM=</DigestValue></entry></row><row><entry> </Reference></entry></row><row><entry><Reference URI=“urn:x-octopus.intertrust.com:controller:37A50262EE3389A14ABC0BC7BE5D43E5”></entry></row><row><entry><Transforms></entry></row><row><entry> <Transform Algorithm=“http://www.intertrust.com/Octopus/xmldsig#cbs-1_0” /></entry></row><row><entry> </Transforms></entry></row><row><entry> <DigestMethod Algorithm=“http://www.w3.org/2000/09/xmldsig#sha1” /></entry></row><row><entry> <DigestValue>G1zXF9Sz/zCwH6MaFm0ObOQcxuk=</DigestValue></entry></row><row><entry> </Reference></entry></row><row><entry> </SignedInfo></entry></row><row><entry> <SignatureValue>bRxLSM82d4ktWsYz6uhBxzJfsOo=</SignatureValue></entry></row><row><entry><KeyInfo></entry></row><row><entry> <KeyName>urn:x-octopus.intertrust.com:secret-key:2003</KeyName></entry></row><row><entry> </KeyInfo></entry></row><row><entry> </Signature></entry></row><row><entry> </Bundle></entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

Appendix B

1178This Appendix B presents the XML encoding of objects in one embodiment of a system using the example Octopus DRM engine described elsewhere herein. For a particular application, an application-specific XML schema can be created by importing the XML schema shown below (the “Octopus XML Schema”) and adding elements specific to the application (e.g., extensions used for revocation). In one embodiment, the encoding of objects in XML need to be able to be validated against the application-specific XML schema. Additional possible constraints on these XML encodings can be found below.

1179In the example illustrated in this Appendix B, the base XML-Schema Type for all the DRM objects is OctopusObjectType. This means that all the objects support attributes and extensions. The type of each Octopus object element is derived from this base type. These types may aggregate other elements such as the SecretKey element for the ContentKeyType for instance.

1180In this example embodiment, the Scuba key distribution system keys are described in terms of an extension: the Scuba keys element will then be a child of the extension element. The same applies for revocation keys with the Torpedo extension.

1181As described elsewhere herein, there are different kinds of Octopus Objects (e.g., ContentKey, Protector, Controller, Control, Node, and Link). These objects can be bundled together along with extensions using the <Bundle> element. In one embodiment, if objects or extensions are signed within the <Bundle>, the <Bundle> will contain <Signature> elements as described elsewhere herein.

1182Octopus XML Schema (Octopus.xsd): <tables id="TABLE-US-00093" num="93"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="308PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry></entry></row><row><entry><xs:schema targetNamespace=“http://intertrust.com/Octopus/1.0”</entry></row><row><entry>xmlns=“http://intertrust.com/Octopus/1.0” xmlns:xs=“http://www.w3.org/2001/XMLSchema”</entry></row><row><entry>xmlns:ds=“http://www.w3.org/2000/09/xmldsig#” xmlns:xenc=“http://www.w3.org/2001/04/xmlenc#”</entry></row><row><entry>elementFormDefault=“qualified” attributeFormDefault=“unqualified”></entry></row><row><entry> <!-- imports --></entry></row><row><entry> <xs:import namespace=“http://www.w3.org/2000/09/xmldsig#” schemaLocation=“xmldsig-core-</entry></row><row><entry>schema.xsd”/></entry></row><row><entry> <xs:import namespace=“http://www.w3.org/2001/04/xmlenc#” schemaLocation=“xenc-schema.xsd”/></entry></row><row><entry> <!-- top level elements --></entry></row><row><entry> <xs:element name=“RootLevelObject” type=“RootLevelObjectType” abstract=“true”/></entry></row><row><entry> <xs:element name=“OctopusObject” type=“OctopusObjectType” abstract=“true”/></entry></row><row><entry> <!-- base element --></entry></row><row><entry> <xs:element name=“Bundle” type=“BundleType”/></entry></row><row><entry> <xs:element name=“Link” type=“LinkType” substitutionGroup=“RootLevelObject”/></entry></row><row><entry> <xs:element name=“Node” type=“NodeType” substitutionGroup=“RootLevelObject”/></entry></row><row><entry> <xs:element name=“Control” type=“ControlType” substitutionGroup=“RootLevelObject”/></entry></row><row><entry> <xs:element name=“Controller” type=“ControllerType” substitutionGroup=“RootLevelObject”/></entry></row><row><entry> <xs:element name=“Protector” type=“ProtectorType” substitutionGroup=“RootLevelObject”/></entry></row><row><entry> <xs:element name=“ContentKey” type=“ContentKeyType” substitutionGroup=“RootLevelObject”/></entry></row><row><entry> <!-- key elements --></entry></row><row><entry> <xs:element name=“SecretKey” type=“KeyType”/></entry></row><row><entry> <xs:element name=“PublicKey” type=“PairedKeyType”/></entry></row><row><entry> <xs:element name=“PrivateKey” type=“PairedKeyType”/></entry></row><row><entry> <xs:element name=“KeyData” type=“KeyDataType”/></entry></row><row><entry> <!-- other elements --></entry></row><row><entry> <xs:element name=“AttributeList” type=“AttributeListType”/></entry></row><row><entry> <xs:element name=“Attribute” type=“AttributeType”/></entry></row><row><entry> <xs:element name=“ExtensionList” type=“ExtensionListType”/></entry></row><row><entry> <xs:element name=“Extension” type=“ExtensionType” substitutionGroup=“RootLevelObject”/></entry></row><row><entry> <xs:element name=“LinkFrom” type=“OctopusObjectReferenceType”/></entry></row><row><entry> <xs:element name=“LinkTo” type=“OctopusObjectReferenceType”/></entry></row><row><entry> <xs:element name=“Id” type=“xs:string”/></entry></row><row><entry> <xs:element name=“Digest” type=“DigestType”/></entry></row><row><entry> <xs:element name=“ControlProgram” type=“ControlProgramType”/></entry></row><row><entry> <xs:element name=“CodeModule” type=“CodeModuleType”/></entry></row><row><entry> <xs:element name=“ControlReference” type=“OctopusObjectReferenceType”/></entry></row><row><entry> <xs:element name=“ContentKeyReference” type=“OctopusObjectReferenceType”/></entry></row><row><entry> <xs:element name=“ContentReference” type=“OctopusObjectReferenceType”/></entry></row><row><entry> <xs:element name=“ProtectedTargets” type=“ProtectedTargetsType”/></entry></row><row><entry> <xs:element name=“ControlledTargets” type=“ControlledTargetsType”/></entry></row><row><entry> <!-- scuba --></entry></row><row><entry> <xs:element name=“ScubaKeys” type=“ScubaKeysType”/></entry></row><row><entry> <!-- base type for Octopus Objects --></entry></row><row><entry> <xs:complexType name=“RootLevelObjectType”/></entry></row><row><entry> <xs:complexType name=“OctopusObjectType”></entry></row><row><entry>  <xs:complexContent></entry></row><row><entry>   <xs:extension base=“RootLevelObjectType”></entry></row><row><entry>    <xs:sequence></entry></row><row><entry>     <xs:element ref=“AttributeList” minOccurs=“0”/></entry></row><row><entry>     <xs:element ref=“ExtensionList” minOccurs=“0”/></entry></row><row><entry>    </xs:sequence></entry></row><row><entry>    <xs:attribute name=“id” type=“xs:string” use=“optional”/></entry></row><row><entry>   </xs:extension></entry></row><row><entry>  </xs:complexContent></entry></row><row><entry> </xs:complexType></entry></row><row><entry> <xs:complexType name=“AnyContainerType”></entry></row><row><entry>  <xs:complexContent></entry></row><row><entry>   <xs:extension base=“RootLevelObjectType”></entry></row><row><entry>    <xs:sequence></entry></row><row><entry>     <xs:any processContents=“lax”/></entry></row><row><entry>    </xs:sequence></entry></row><row><entry>   </xs:extension></entry></row><row><entry>  </xs:complexContent></entry></row><row><entry> </xs:complexType></entry></row><row><entry> <xs:complexType name=“ExtensionType”></entry></row><row><entry>  <xs:complexContent></entry></row><row><entry>   <xs:extension base=“AnyContainerType”></entry></row><row><entry>    <xs:sequence minOccurs=“0”></entry></row><row><entry>     <xs:element ref=“Digest” minOccurs=“0”/></entry></row><row><entry>    </xs:sequence></entry></row><row><entry>    <xs:attribute name=“id” type=“xs:string” use=“required”/></entry></row><row><entry>    <xs:attribute name=“subject” type=“xs:string”/></entry></row><row><entry>   </xs:extension></entry></row><row><entry>  </xs:complexContent></entry></row><row><entry> </xs:complexType></entry></row><row><entry> <xs:complexType name=“ExtensionListType”></entry></row><row><entry>  <xs:sequence></entry></row><row><entry>   <xs:element ref=“Extension” maxOccurs=“unbounded”/></entry></row><row><entry>  </xs:sequence></entry></row><row><entry> </xs:complexType></entry></row><row><entry> <xs:complexType name=“AttributeListType”></entry></row><row><entry>  <xs:sequence></entry></row><row><entry>   <xs:element ref=“Attribute” maxOccurs=“unbounded”/></entry></row><row><entry>  </xs:sequence></entry></row><row><entry> </xs:complexType></entry></row><row><entry> <xs:complexType name=“AttributeType”></entry></row><row><entry>  <xs:simpleContent></entry></row><row><entry>   <xs:extension base=“xs:string”></entry></row><row><entry>    <xs:attribute name=“name” type=“xs:string” use=“required”/></entry></row><row><entry>    <xs:attribute name=“type” type=“xs:string” default=“string”/></entry></row><row><entry>   </xs:extension></entry></row><row><entry>  </xs:simpleContent></entry></row><row><entry> </xs:complexType></entry></row><row><entry> <xs:complexType name=“DigestType”></entry></row><row><entry>  <xs:sequence></entry></row><row><entry>   <xs:element ref=“ds:DigestMethod”/></entry></row><row><entry>   <xs:element ref=“ds:DigestValue”/></entry></row><row><entry>  </xs:sequence></entry></row><row><entry> </xs:complexType></entry></row><row><entry> <xs:complexType name=“OctopusObjectReferenceType”></entry></row><row><entry>  <xs:sequence></entry></row><row><entry>   <xs:element ref=“Id”/></entry></row><row><entry>   <xs:element ref=“Digest” minOccurs=“0”/></entry></row><row><entry>  </xs:sequence></entry></row><row><entry> </xs:complexType></entry></row><row><entry> <xs:complexType name=“ProtectedTargetsType”></entry></row><row><entry>  <xs:sequence></entry></row><row><entry>   <xs:element ref=“ContentReference” maxOccurs=“unbounded”/></entry></row><row><entry>  </xs:sequence></entry></row><row><entry> </xs:complexType></entry></row><row><entry> <xs:complexType name=“ControlledTargetsType”></entry></row><row><entry>  <xs:sequence></entry></row><row><entry>   <xs:element ref=“ContentKeyReference” maxOccurs=“unbounded”/></entry></row><row><entry>  </xs:sequence></entry></row><row><entry> </xs:complexType></entry></row><row><entry> <!-- Bundle Type --></entry></row><row><entry> <xs:complexType name=“BundleType”></entry></row><row><entry>  <xs:sequence></entry></row><row><entry>   <xs:element ref=“RootLevelObject” maxOccurs=“unbounded”/></entry></row><row><entry>   <xs:element ref=“ds:Signature” minOccurs=“0” maxOccurs=“unbounded”/></entry></row><row><entry>  </xs:sequence></entry></row><row><entry> </xs:complexType></entry></row><row><entry> <!-- Node Types --></entry></row><row><entry> <xs:complexType name=“NodeType”></entry></row><row><entry>  <xs:complexContent></entry></row><row><entry>   <xs:extension base=“OctopusObjectType”/></entry></row><row><entry>  </xs:complexContent></entry></row><row><entry> </xs:complexType></entry></row><row><entry> <!-- Link Types --></entry></row><row><entry> <xs:complexType name=“LinkType”></entry></row><row><entry>  <xs:complexContent></entry></row><row><entry>   <xs:extension base=“OctopusObjectType”></entry></row><row><entry>    <xs:sequence></entry></row><row><entry>     <xs:element ref=“LinkFrom”/></entry></row><row><entry>     <xs:element ref=“LinkTo”/></entry></row><row><entry>     <xs:element ref=“Control” minOccurs=“0”/></entry></row><row><entry>    </xs:sequence></entry></row><row><entry>   </xs:extension></entry></row><row><entry>  </xs:complexContent></entry></row><row><entry> </xs:complexType></entry></row><row><entry> <!-- Protector Types --></entry></row><row><entry> <xs:complexType name=“ProtectorType”></entry></row><row><entry>  <xs:complexContent></entry></row><row><entry>   <xs:extension base=“OctopusObjectType”></entry></row><row><entry>    <xs:sequence></entry></row><row><entry>     <xs:element ref=“ContentKeyReference”/></entry></row><row><entry>     <xs:element ref=“ProtectedTargets”/></entry></row><row><entry>    </xs:sequence></entry></row><row><entry>   </xs:extension></entry></row><row><entry>  </xs:complexContent></entry></row><row><entry> </xs:complexType></entry></row><row><entry> <!-- Control Types --></entry></row><row><entry> <xs:complexType name=“CodeModuleType”></entry></row><row><entry>  <xs:simpleContent></entry></row><row><entry>   <xs:extension base=“xs:string”></entry></row><row><entry>    <xs:attribute name=“byteCodeType” use=“required”/></entry></row><row><entry>   </xs:extension></entry></row><row><entry>  </xs:simpleContent></entry></row><row><entry> </xs:complexType></entry></row><row><entry> <xs:complexType name=“ControlProgramType”></entry></row><row><entry>  <xs:sequence></entry></row><row><entry>   <xs:element ref=“CodeModule”/></entry></row><row><entry>  </xs:sequence></entry></row><row><entry>  <xs:attribute name=“type” use=“required”/></entry></row><row><entry> </xs:complexType></entry></row><row><entry> <xs:complexType name=“ControlType”></entry></row><row><entry>  <xs:complexContent></entry></row><row><entry>   <xs:extension base=“OctopusObjectType”></entry></row><row><entry>    <xs:sequence></entry></row><row><entry>     <xs:element ref=“ControlProgram”/></entry></row><row><entry>    </xs:sequence></entry></row><row><entry>   </xs:extension></entry></row><row><entry>  </xs:complexContent></entry></row><row><entry> </xs:complexType></entry></row><row><entry> <!-- Controller Type --></entry></row><row><entry> <xs:complexType name=“ControllerType”></entry></row><row><entry>  <xs:complexContent></entry></row><row><entry>   <xs:extension base=“OctopusObjectType”></entry></row><row><entry>    <xs:sequence></entry></row><row><entry>     <xs:element ref=“ControlReference”/></entry></row><row><entry>     <xs:element ref=“ControlledTargets”/></entry></row><row><entry>    </xs:sequence></entry></row><row><entry>   </xs:extension></entry></row><row><entry>  </xs:complexContent></entry></row><row><entry> </xs:complexType></entry></row><row><entry> <!-- Key types --></entry></row><row><entry> <xs:complexType name=“KeyType”></entry></row><row><entry>  <xs:sequence></entry></row><row><entry>   <xs:element ref=“KeyData”/></entry></row><row><entry>  </xs:sequence></entry></row><row><entry>  <xs:attribute name=“id” type=“xs:string” use=“required”/></entry></row><row><entry>  <xs:attribute name=“usage” type=“xs:string” use=“optional”/></entry></row><row><entry> </xs:complexType></entry></row><row><entry> <xs:complexType name=“PairedKeyType”></entry></row><row><entry>  <xs:complexContent></entry></row><row><entry>   <xs:extension base=“KeyType”></entry></row><row><entry>    <xs:attribute name=“pair” type=“xs:string” use=“required”/></entry></row><row><entry>   </xs:extension></entry></row><row><entry>  </xs:complexContent></entry></row><row><entry> </xs:complexType></entry></row><row><entry> <xs:complexType name=“KeyDataType” mixed=“true”></entry></row><row><entry>  <xs:sequence></entry></row><row><entry>   <xs:element ref=“xenc:EncryptedData” minOccurs=“0”/></entry></row><row><entry>  </xs:sequence></entry></row><row><entry>  <xs:attribute name=“encoding” use=“required”></entry></row><row><entry>   <xs:simpleType></entry></row><row><entry>    <xs:restriction base=“xs:string”></entry></row><row><entry>     <xs:enumeration value=“xmlenc”/></entry></row><row><entry>     <xs:enumeration value=“base64”/></entry></row><row><entry>    </xs:restriction></entry></row><row><entry>   </xs:simpleType></entry></row><row><entry>  </xs:attribute></entry></row><row><entry>  <xs:attribute name=“format” use=“required”></entry></row><row><entry>   <xs:simpleType></entry></row><row><entry>    <xs:restriction base=“xs:string”></entry></row><row><entry>     <xs:enumeration value=“PKCS#8”/></entry></row><row><entry>     <xs:enumeration value=“X.509”/></entry></row><row><entry>     <xs:enumeration value=“RAW”/></entry></row><row><entry>    </xs:restriction></entry></row><row><entry>   </xs:simpleType></entry></row><row><entry>  </xs:attribute></entry></row><row><entry> </xs:complexType></entry></row><row><entry> <!-- ContentKey Types --></entry></row><row><entry> <xs:complexType name=“ContentKeyType”></entry></row><row><entry>  <xs:complexContent></entry></row><row><entry>   <xs:extension base=“OctopusObjectType”></entry></row><row><entry>    <xs:sequence></entry></row><row><entry>     <xs:element ref=“SecretKey”/></entry></row><row><entry>    </xs:sequence></entry></row><row><entry>   </xs:extension></entry></row><row><entry>  </xs:complexContent></entry></row><row><entry> </xs:complexType></entry></row><row><entry> <!-- Scuba extensions --></entry></row><row><entry> <xs:complexType name=“ScubaKeysType”></entry></row><row><entry>  <xs:sequence></entry></row><row><entry>   <xs:element ref=“SecretKey” minOccurs=“0” maxOccurs=“unbounded”/></entry></row><row><entry>   <xs:element ref=“PublicKey” minOccurs=“0” maxOccurs=“unbounded”/></entry></row><row><entry>   <xs:element ref=“PrivateKey” minOccurs=“0” maxOccurs=“unbounded”/></entry></row><row><entry>  </xs:sequence></entry></row><row><entry> </xs:complexType></entry></row><row><entry></xs:schema></entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

1183An Illustrative Application-Specific Schema: <tables id="TABLE-US-00094" num="94"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="294PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry></entry></row><row><entry><xs:schema targetNamespace=“http://intertrust.com/kformat/1.0”</entry></row><row><entry>xmlns=“http://intertrust.com/kformat/1.0” xmlns:oct=“http://intertrust.com/Octopus/1.0”</entry></row><row><entry>xmlns:xs=“http://www.w3.org/2001/XMLSchema” xmlns:ds=“http://www.w3.org/2000/09/xmldsig#”</entry></row><row><entry>xmlns:xenc=“http://www.w3.org/2001/04/xmlenc#” elementFormDefault=“qualified”</entry></row><row><entry>attributeFormDefault=“unqualified”></entry></row><row><entry> <!-- imports --></entry></row><row><entry> <xs:import namespace=“http://intertrust.com/Octopus/1.0” schemaLocation=“Octopus.xsd”/></entry></row><row><entry> <!-- elements --></entry></row><row><entry> <xs:element name=“Torpedo” type=“TorpedoType”/></entry></row><row><entry> <xs:element name=“BroadcastKey” type=“BroadcastKeyType”/></entry></row><row><entry> <xs:element name=“BroadcastKeyMethod” type=“BroadcastKeyMethodType”/></entry></row><row><entry> <!-- types --></entry></row><row><entry> <xs:complexType name=“TorpedoType”></entry></row><row><entry>  <xs:sequence></entry></row><row><entry>   <xs:element ref=“BroadcastKey”/></entry></row><row><entry>  </xs:sequence></entry></row><row><entry> </xs:complexType></entry></row><row><entry> <xs:complexType name=“BroadcastKeyType”></entry></row><row><entry>  <xs:sequence></entry></row><row><entry>   <xs:element ref=“BroadcastKeyMethod”/></entry></row><row><entry>   <xs:element ref=“oct:KeyData”/></entry></row><row><entry>  </xs:sequence></entry></row><row><entry>  <!-- the id is the name of the MNK --></entry></row><row><entry>  <xs:attribute name=“id” type=“xs:string”/></entry></row><row><entry>  <!-- the source is the name of the MKT --></entry></row><row><entry>  <xs:attribute name=“source” type=“xs:string”/></entry></row><row><entry> </xs:complexType></entry></row><row><entry> <xs:complexType name=“BroadcastKeyMethodType”></entry></row><row><entry>  <xs:attribute name=“Algorithm” fixed=“http://marlin-drm.com/mangrove/1.0”/></entry></row><row><entry> </xs:complexType></entry></row><row><entry></xs:schema></entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

1184B.1. Additional Constraints

1185B.1.1. Nodes

1186In one embodiment, the following types of nodes are defined: <ul id="ul0051" list-style="none"><li id="ul0051-0001" num="1187"> Octopus Personality nodes, which are the root nodes of a given DRM engine (e.g., Device Node or PC Software Node). </li><li id="ul0051-0002" num="1188"> Other types of nodes, such as User Nodes, or nodes for group of users, such as Subscription Nodes or Membership Nodes. </li></ul>

1189In one embodiment, nodes contain keys (e.g., in Extensions such as ScubaKeys) and it is necessary to be able to separate the public information of the node (e.g., the id, attributes, and public keys) and its private extensions (that will, e.g., carry the secret and private keys). Moreover, there will be one signature per part (the public and the private) so that the public node with its signature can be exported as is (as a parameter of the request to the license service for example).

1190In one embodiment, the private extensions will be carried in an ExternalExtension and signed. The public node and its private extensions can be packaged in the same <Bundle> element or can arrive separately. An example of a signed Octopus Personality Node is given below in Annex A to Appendix B.

1191B.1.1.1 Attributes

1192In one embodiment, each XML encoding of a Node object will carry an <AttributeList> with the following <Attribute> (s):

1193For Octopus Personalities: <tables id="TABLE-US-00095" num="95"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry><AttributeList xmlns=“http://intertrust.com/Octopus/1.0”></entry></row><row><entry> <Attribute name=“urn:x-marlin.intertrust.com:type”>...</Attribute></entry></row><row><entry> <Attribute name=“urn:x-marlin.intertrust.com:dnk_id”>...</Attribute></entry></row><row><entry> <Attribute name=“urn:x-marlin.intertrust.com:manufacturer”>...</entry></row><row><entry> </Attribute></entry></row><row><entry> <Attribute name=“urn:x-marlin.intertrust.com:model”>...</Attribute></entry></row><row><entry> <Attribute name=“urn:x-marlin.intertrust.com:version”>...</Attribute></entry></row><row><entry></AttributeList></entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

1194For other type of nodes: <tables id="TABLE-US-00096" num="96"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry><AttributeList xmlns=“http://intertrust.com/Octopus/1.0”></entry></row><row><entry> <Attribute name=“urn:x-marlin.intertrust.com:type”>...</Attribute></entry></row><row><entry></AttributeList></entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

1195B.1.1.2 Extensions

1196As shown in Annex A to this Appendix B, in one embodiment Octopus personality nodes carry extensions for ScubaKeys (both sharing and confidentiality keys) and Torpedo (broadcast secret key). Other types of nodes carry only Scuba sharing keys.

1197All the public keys are carried inside the <Node> element in an <Extension> element in the <ExtensionList>. Other keys are carried in a separate <Extension> element outside of the <Node> element.

1198In one embodiment, the <ScubaKeys> extensions are signed in the <Node>. In this embodiment, the internal <Extension> carrying <ScubaKeys> inside the <Node> (public keys) will need to include a <ds:DigestMethod> element as well as a <ds:DigestValue> element. The private keys carried in an external <Extension> will need to be signed and this by signing the whole extension. Likewise, the <Torpedo> extension will be signed.

1199B.1.2 Links

1200In one embodiment, the <LinkTo> and <LinkFrom> elements of the <Link> element contain only an <Id> element and no <Digest> element. The <Control> element is optional. Annex C to this Appendix B contains an example of a signed link object.

1201B.1.1.1 Attributes

1202In one embodiment, links do not have mandatory attributes. This means that the <AttributeList> is not required and will be ignored by a compliant implementation.

1203B.1.1.2 Extensions

1204In the example embodiment shown in this Appendix B, links have <ScubaKeys> internal extensions carried inside the <Link>, and thus the <ExtensionList> element is mandatory. In addition, the <ScubaKeys> extension in a link is not signed, and thus, no <ds:DigestMethod> and <ds:DigestValue> element are carried inside the <Extension> element. This <ScubaKeys> extension contains an encrypted version of the private/secret Scuba Sharing keys (in a <PrivateKey> and a <SecretKey> element) of the “To Node” with the public or secret Scuba Sharing key of the “From Node”. This encryption is signaled using the XML encryption syntax. In the embodiment illustrated in this Appendix B, the “encoding” attribute of the <KeyData> element, child of the <PrivateKey> and <SecretKey> elements, is set to “xmlenc”. The child of this <KeyData> element will be an <xenc:EncryptedData> element. The name of the encryption key will be advertised in the <KeyInfo>/<KeyName> element.

1205In one embodiment, if the encryption key is a public key, then: <ul id="ul0052" list-style="none"><li id="ul0052-0001" num="0000"><ul id="ul0053" list-style="none"><li id="ul0053-0001" num="1206"> The <KeyName> element is the name of the pair to which the key belongs. </li><li id="ul0053-0002" num="1207"> If the encrypted data (e.g., a private key) is too big to get encrypted directly with a public key, an intermediary 128-bit secret key is generated. The data is then encrypted with this intermediary key using, e.g., aes-128-cbc, and the intermediary key is encrypted with the public key (using the <EncryptedKey> element). </li></ul></li></ul>

1208The XML chunk will then look like: <tables id="TABLE-US-00097" num="97"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="266PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry><!---E(I, data) --></entry></row><row><entry><EncryptedData xmlns=“http://www.w3.org/2001/04/xmlenc#”></entry></row><row><entry> <EncryptionMethod Algorithm=“http://www.w3.org/2001/04/xmlenc#aes128-cbc”/></entry></row><row><entry> <KeyInfo xmlns=“http://www.w3.org/2000/09/xmldsig#”></entry></row><row><entry>  <!-- E(PUBa, I) --></entry></row><row><entry>  <EncryptedKey xmlns=“http://www.w3.org/2001/04/xmlenc#”></entry></row><row><entry>   <EncryptionMethod Algorithm=“http://www.w3.org/2001/04/xmlenc#rsa-1_5”/></entry></row><row><entry>    <KeyInfo xmlns=“http://www.w3.org/2000/09/xmldsig#”></entry></row><row><entry>     <KeyName>urn:x-octopus.intertrust.com:key-pair:300a</KeyName></entry></row><row><entry>    </KeyInfo></entry></row><row><entry>    <CipherData></entry></row><row><entry>     <CipherValue></entry></row><row><entry>fFeGD4KAPEmESz/jW6CkbRegpM5kyH0Oy/o/uDQ78PaShtvUMoozeO4a0b785YnB</entry></row><row><entry>13Qa1ZUEYqR9V5TCUaOcH7wxxvBEIsd1nYKkVOgW/kFnRr98UDFvU90PRqaEP/SA</entry></row><row><entry>Bb+JuAUmvxYX47qOVQqBQGGqzFssBDKmUk+s98dkPR8=</entry></row><row><entry>     </CipherValue></entry></row><row><entry>    </CipherData></entry></row><row><entry>   </EncryptedKey></entry></row><row><entry>  </KeyInfo></entry></row><row><entry>  <CipherData></entry></row><row><entry>   <CipherValue></entry></row><row><entry>c8LBj4BLzGOYv/GT3Y4w2XcwTYbr8fHNJhCOQjULuvoha/QYvZKKCpUY+nuCXC/s</entry></row><row><entry>t9TU+8tMtaMt1GUpkCZQhSaTNcluCSxOyBoA6Xh/bmyZLDJ78+aJ/sITmfNpJGdb</entry></row><row><entry>vTaI7x9DD1Mp1mvFEjpAUjTTvruN32g4bxsF7FD8C1RWNAc4hS96nFDgrmzoO5pR</entry></row><row><entry>dda6mswFKG5B0kY7mYbhacb1owXkAk1Wc/OuXA+QLHdUthxeajoXNPfAGRz9FM3b</entry></row><row><entry>puJxbxDAaaAJDxoReiTtS1nGaHhqa1hvLCpKk1zHBowHyvTvDLElLjHYEPeG6xSH</entry></row><row><entry>BbzpT298tdKUhXfaY6vvdceMdVXuBVL3eZP1jkJHDxeaBy1ce8xlQKZpo6Pjuxlb</entry></row><row><entry>bn5KUMt/PxWp7rLa5s786S740cwuN63+ZRgienxPK1CnYO3htMJ7hh/agvO9IyUD</entry></row><row><entry>RvcgnSEY9KA5Exy/6gIS/gouIjFU8r7056XcE4/IBodTWDkfyli/y8q5QA/0VaD9</entry></row><row><entry>Y3oER1p3pYuHwn/IeXM4gsBD31cgd7nvfK7lKYkZjowR9P6pSy57a+K4LZKDmfUH</entry></row><row><entry>zG/gZs2XcoPb9o6mVAEEej7+aLwqmoileykkR+0pkFntvqvXYRPkphhcVdzjzlMV</entry></row><row><entry>scpXBXfWx7wbQURXkiew7R4RihQy3wcv+ZFJpl9NsAE1yqyWy4rBobzZ7cTNMtfR</entry></row><row><entry>znhVlt+Wwq5G0IBxzU9WIFzFd/Rn2H9L4TI71LCa4VR3uNpf+XM8lp9LjLPRUnNh</entry></row><row><entry>28KrMdAddceyopYyiIF5p8idfh0//a/LKdE7JAk0q9ewk19ryqfl6CFeKI5oOMjh</entry></row><row><entry>kzNx3BR/iHxm31HIe3ZKtA==</CipherValue></entry></row><row><entry>  </CipherData></entry></row><row><entry></EncryptedData></entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

1209B.1.3 License objects

1210Annex C to this Appendix B provides an example of a signed license (before the first revocation has occurred, see the ContentKey section, below).

1211B.1.3.1 Protector

1212In the example embodiment shown in this Appendix B, the <ContentKeyReference> element and the <ContentReference> elements (e.g., inside the <ProtectedTargets> element) contain only an <Id> element and no <Digest> element. In this illustrative embodiment, Protector objects contain no mandatory attributes or extensions; the <AttributeList> and <ExtensionList> elements are optional and will be ignored.

1213B.1.3.2 ContentKey

1214In the example embodiment shown in this Appendix B, ContentKey objects contain no mandatory attributes or extensions. Therefore, the <AttributeList> and <ExtensionList> elements are optional and will be ignored.

1215In one embodiment, <ContentKey> elements contain a <SecretKey> element which represent the actual key that will be used to decrypt the content. The <KeyData> associated with the <SecretKey> is encrypted. In one embodiment, it is mandatory that the “encoding” attribute of <KeyData> is set to “xmlenc”.

1216In one embodiment, there are two distinct cases for ContentKey objects: (1) Before the first revocation of a device or a PC application: in this case, the content key Kc represented by the <SecretKey> element will be only encrypted by the Scuba key (public or secret) of the entity the content is bound to (the user for example). (2) After the first revocation where the content key is encrypted according to the Mangrove broadcast encryption scheme. The resulting data is then encrypted with the Scuba key (public or secret) of the entity the content is bound to. In this case, we have super-encryption.

1217Illustrative methods for encrypting the <EncryptedData> element in case of super-encryption are described elsewhere herein. The following explains how to apply this to case b.

1218In one embodiment, the xmlenc syntax for the encryption of the content key Kc with the Mangrove Broadcast Encryption scheme is: <tables id="TABLE-US-00098" num="98"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry><EncryptedData xmlns=“http://www.w3.org/2001/04/xmlenc#”></entry></row><row><entry> <EncryptionMethod Algorithm=“see (*)”/></entry></row><row><entry> <KeyInfo xmlns=“‘http://www.w3.org/2000/09/xmldsig#”></entry></row><row><entry>  <KeyName>see (**)</KeyName></entry></row><row><entry> </KeyInfo></entry></row><row><entry> <CipherData></entry></row><row><entry>  <CipherValue>see (***)</CipherValue></entry></row><row><entry> </CipherData></entry></row><row><entry></EncryptedData></entry></row><row><entry>(*) is the URL identifying the Mangrove Broadcast Encryption scheme,</entry></row><row><entry>which, in one embodiment, is also the <BroadcastKeyMethod> Algorithm</entry></row><row><entry>of the <Torpedo> extension in an application-specific xml schema call</entry></row><row><entry>“kformat.xsd”.</entry></row><row><entry>(**) is the name of the Mangrove Key Tree. In one embodiment, this</entry></row><row><entry>value must be the same as the source attribute of the <BroadcastKey></entry></row><row><entry>element defined in kformat.xsd.</entry></row><row><entry>(***) is the base64 encoded value of the ASN.1 sequence representing the</entry></row><row><entry>encryption of the content key Kc according to the Mangrove Broadcast</entry></row><row><entry>Key algorithm:</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="63PT" align="left" /><colspec colname="1" colwidth="154PT" align="left" /><tbody valign="top"><row><entry /><entry>SEQUENCE {</entry></row><row><entry /><entry>  tags BIT STRING</entry></row><row><entry /><entry>  keys OCTET STRING</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

1219In one embodiment, the byte sequence of the <EncryptedData> referred to above is encrypted with the scuba sharing key (public or secret) of the entity the license is bound to. If the public key is used, then the same conventions apply as the one described in below (e.g., see encrypting with a public key) and an intermediary key is needed if the byte sequence of the <EncryptedData> is too big for a RSA 1024 public key. An example of the XML encoding of such a ContentKey object can be found in Annex D to this Appendix B.

1220B.1.3.3 Controller

1221In one embodiment, controller objects contain no mandatory attributes or extensions. Therefore the <AttributeList> and <ExtensionList> elements are optional and will be ignored by a compliant implementation.

1222In one embodiment, the value of the Algorithm attribute of the <DigestMethod> elements is always http://www.w3.org/2000/09/xmldsig#sha1.

1223In one embodiment, the <ControlReference> must have a <Digest> element. The <DigestValue> element must contain the base<b>64</b> encoding of the digest of the referenced control.

1224In one embodiment, if the signature over the Controller is a PKI signature (rsa-sha<b>1</b>), the <ContentKeyRefence> elements (within the <ControlledTargets> elements) need to include a <Digest> element and the <DigestValue> element must contain the digest of the plain-text content key embedded in the ContentKey object.

1225B.1.3.4 Control

1226In one embodiment, control objects contain no mandatory attributes or extensions. Therefore the <AttributeList> and <ExtensionList> elements are optional and will be ignored by a compliant implementation.

1227In one embodiment, the type attribute of the <ControlProgram> element is set to “plankton,” and the byteCodeType attribute of the <CodeModule> element is set to “Plankton-1-0.”

1228Appendix B—Annex A: Example of Signed Octopus Personality Node <tables id="TABLE-US-00099" num="99"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="322PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry><Bundle xmlns:ds=“http://www.w3.org/2000/09/xmldsig#”</entry></row><row><entry>xmlns:xenc=“http://www.w3.org/2001/04/xmlenc#” xmlns=“http://intertrust.com/Octopus/1.0”</entry></row><row><entry>xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”</entry></row><row><entry>xsi:schemaLocation=“http://intertrust.com/kformat/1.0</entry></row><row><entry>C:\DOCUME˜1\julien\Desktop\kformat\kformat.xsd”></entry></row><row><entry> <!-- FIRST THE NODE with PUBLIC INFO--></entry></row><row><entry> <Node id=“urn:kformat:device:0001”></entry></row><row><entry>  <AttributeList></entry></row><row><entry>   <Attribute name=“urn:x-marlin.intertrust.com:type”>device</Attribute></entry></row><row><entry>   <Attribute name=“urn:x-marlin.intertrust.com:dnk_id”>urn:kformat:mangrove:0001</Attribute></entry></row><row><entry>   <Attribute name=“urn:x-marlin.intertrust.com:manufacturer_id”>SONY</Attribute></entry></row><row><entry>   <Attribute name=“urn:x-marlin.intertrust.com:model”>urn:sony:walkman</Attribute></entry></row><row><entry>   <Attribute name=“urn:x-marlin.intertrust.com:version”>urn:sony:walkman:002a</Attribute></entry></row><row><entry>  </AttributeList></entry></row><row><entry>  <ExtensionList></entry></row><row><entry>   <Extension id=“urn:kformat:device:0001:scuba:public”></entry></row><row><entry>    <ScubaKeys></entry></row><row><entry>     <PublicKey id=“urn:kformat:device:0001:scuba:public:sharing”</entry></row><row><entry>          pair=“urn:kformat:device:0001:scuba:pair:sharing”></entry></row><row><entry>      <KeyData encoding=“base64” format=“X509”>MIIC...MEbB</KeyData></entry></row><row><entry>     </PublicKey></entry></row><row><entry>     <PublicKey id=“urn:kformat:device:0001:scuba:public:confidentiality”</entry></row><row><entry>          usage=“confidentiality”</entry></row><row><entry>          pair=“urn:kformat:device:0001:scuba:pair:confidentiality”></entry></row><row><entry>      <KeyData encoding=“base64” format=“X.509”>MIIChDCC... vh8BM52</KeyData></entry></row><row><entry>     </PublicKey></entry></row><row><entry>    </ScubaKeys></entry></row><row><entry>    <Digest></entry></row><row><entry>     <DigestMethod xmlns=“http://www.w3.org/2000/09/xmldsig#”</entry></row><row><entry>            Algorithm=“http://www.w3.org/2000/09/xmldsig#sha1”/></entry></row><row><entry>     <DigestValue xmlns=“http://www.w3.org/2000/09/xmldsig#”>OGZGBY8OpQXs</DigestValue></entry></row><row><entry>    </Digest></entry></row><row><entry>   </Extension></entry></row><row><entry>  </ExtensionList></entry></row><row><entry> </Node></entry></row><row><entry> <!-- THEN the PRIVATE Scuba extension --></entry></row><row><entry> <Extension id=“urn:kformat:device:0001:scuba:private” subject=“urn:kformat:device:0001”></entry></row><row><entry>  <ScubaKeys></entry></row><row><entry>   <PrivateKey id=“urn:kformat:device:0001:scuba:private:sharing”</entry></row><row><entry>          pair=“urn:kformat:device:0001:scuba:pair:sharing”></entry></row><row><entry>    <KeyData encoding=“base64” format=“PKCS8”>MIICdgIBADAN... DXywQLg==</KeyData></entry></row><row><entry>   </PrivateKey></entry></row><row><entry>   <PrivateKey id=“urn:kformat:device:0001:scuba:private:confidentiality”</entry></row><row><entry>          usage=“confidentiality”</entry></row><row><entry>          pair=“urn:kformat:device:0001:scuba:pair:confidentiality”></entry></row><row><entry>    <KeyData encoding=“base64” format=“PKCS8”>MIICdwIBADAN... q4olog34=</KeyData></entry></row><row><entry>   </PrivateKey></entry></row><row><entry>   <SecretKey id=“urn:kformat:device:0001:scuba:secret:sharing”></entry></row><row><entry>    <KeyData encoding=“base64” format=“RAW”>Z1n2/2cbz1oO/fZo9xtmyA==</KeyData></entry></row><row><entry>   </SecretKey></entry></row><row><entry>   <SecretKey id=“urn:kformat:device:0001:scuba:secret:confidentiality”</entry></row><row><entry>          usage=“confidentiality”></entry></row><row><entry>    <KeyData encoding=“base64” format=“RAW”>0CJ8bcORW6GLX4GzT7XKvg==</KeyData></entry></row><row><entry>   </SecretKey></entry></row><row><entry>  </ScubaKeys></entry></row><row><entry> </Extension></entry></row><row><entry> <!-- Then the PRIVATE Torpedo extension --></entry></row><row><entry> <Extension id=“urn:kformat:device:0001:torpedo” subject=“urn:kformat:device:0001”></entry></row><row><entry>  <Torpedo xmlns=“http://intertrust.com/kformat/1.0”></entry></row><row><entry>   <BroadcastKey id=“urn:kformat:mangrove:0001”></entry></row><row><entry>    <BroadcastKeyMethod Algorithm=“http://marlin-drm.com/mangrove/1.0”/></entry></row><row><entry>    <KeyData xmlns=“http://intertrust.com/Octopus/1.0” encoding=“base64”</entry></row><row><entry> format=“RAW”>....</KeyData></entry></row><row><entry>    </BroadcastKey></entry></row><row><entry>   </Torpedo></entry></row><row><entry> </Extension></entry></row><row><entry> <!-- Then the signature on the public part --></entry></row><row><entry> <Signature xmlns=“http://www.w3.org/2000/09/xmldsig#”></entry></row><row><entry>  <SignedInfo></entry></row><row><entry>   <CanonicalizationMethod Algorithm=“http://www.w3.org/2001/10/xml-exc-c14n#”/></entry></row><row><entry>   <SignatureMethod Algorithm=“http://www.w3.org/2000/09/xmldsig#rsa-sha1”/></entry></row><row><entry>   <Reference URI=“urn:kformat:device:0001”></entry></row><row><entry>    <Transforms></entry></row><row><entry>     <Transform Algorithm=“http://www.octopus-drm.com/2004/07/format-independent-cano#”/></entry></row><row><entry>    </Transforms></entry></row><row><entry>    <DigestMethod Algorithm=“http://www.w3.org/2000/09/xmldsig#sha1”/></entry></row><row><entry>    <DigestValue>gI5QoD7MUAgjcpkPiciZhoSHbEQ=</DigestValue></entry></row><row><entry>   </Reference></entry></row><row><entry>  </SignedInfo></entry></row><row><entry>  <SignatureValue>gI5QoD7MUAgjcpkPiciZhoSHbEQ=</SignatureValue></entry></row><row><entry>  <KeyInfo></entry></row><row><entry>   <X509Data></entry></row><row><entry>   <!-- Put the public key cert of the signing key here --></entry></row><row><entry>   <X509Certificate>...</X509Certificate></entry></row><row><entry>   <!-- and the certificate chain without the root if needed --></entry></row><row><entry>   <X509Certificate>...</X509Certificate></entry></row><row><entry>  </X509Data></entry></row><row><entry> </KeyInfo></entry></row><row><entry></Signature></entry></row><row><entry><!-- Then the signature on the private part --></entry></row><row><entry><Signature xmlns=“http://www.w3.org/2000/09/xmldsig#”></entry></row><row><entry> <SignedInfo></entry></row><row><entry>  <CanonicalizationMethod Algorithm=“http://www.w3.org/2001/10/xml-exc-c14n#”/></entry></row><row><entry>  <SignatureMethod Algorithm=“http://www.w3.org/2000/09/xmldsig#rsa-sha1”/></entry></row><row><entry>  <Reference URI=“urn:kformat:0001:scuba:private”></entry></row><row><entry>   <Transforms></entry></row><row><entry>    <Transform Algorithm=“http://www.octopus-drm.com/2004/07/format-independent-cano#”/></entry></row><row><entry>   </Transforms></entry></row><row><entry>   <DigestMethod Algorithm=“http://www.w3.org/2000/09/xmldsig#sha1”/></entry></row><row><entry>   <DigestValue>gI5QoD7MUAgjcpkPiciZhoSHbEQ=</DigestValue></entry></row><row><entry>  </Reference></entry></row><row><entry>  <Reference URI=“urn:kformat:device:0001:torpedo”></entry></row><row><entry>   <Transforms></entry></row><row><entry>    <Transform Algorithm=“http://www.octopus-drm.com/2004/07/format-independent-cano#”/></entry></row><row><entry>   </Transforms></entry></row><row><entry>   <ds:DigestMethod Algorithm=“http://www.w3.org/2000/09/xmldsig#sha1”/></entry></row><row><entry>   <ds:DigestValue>97mDfnw0vF/ECQHcvDk</ds:DigestValue></entry></row><row><entry>  </Reference></entry></row><row><entry> </SignedInfo></entry></row><row><entry> <SignatureValue>gI5QoD7MUAgjcpkPiciZhoSHbEQ=</SignatureValue></entry></row><row><entry> <KeyInfo></entry></row><row><entry>  <X509Data></entry></row><row><entry>   <!-- Put the public key cert of the signing key here --></entry></row><row><entry>   <X509Certificate>...</X509Certificate></entry></row><row><entry>   <!-- and the certificate chain without the root if needed --></entry></row><row><entry>   <X509Certificate>...</X509Certificate></entry></row><row><entry>  </X509Data></entry></row><row><entry> </KeyInfo></entry></row><row><entry> </Signature></entry></row><row><entry></Bundle></entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

1229Appendix B—Annex B: Example of a Signed Octopus Link <tables id="TABLE-US-00100" num="100"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="308PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry></entry></row><row><entry><!--Sample XML file generated by XMLSPY v2004 rel. 2 U (http://www.xmlspy.com)--></entry></row><row><entry><Bundle xmlns=“http://intertrust.com/Octopus/1.0” xmlns:ds=“http://www.w3.org/2000/09/xmldsig#”</entry></row><row><entry>xmlns:xenc=“http://www.w3.org/2001/04/xmlenc#” xmlns:xsi=“http://www.w3.org/2001/XMLSchema-</entry></row><row><entry>instance” xsi:schemaLocation=“http://intertrust.com/Octopus/1.0</entry></row><row><entry>C:\ws\Octopus\Source\Xml\Schemas\Octopus.xsd”></entry></row><row><entry> <Link id=“urn:kformat:link:device:0001:to:user:1234”></entry></row><row><entry>  <ExtensionList></entry></row><row><entry>   <Extension id=“urn:kformat:link:device:0001:to:user:1234:scuba”></entry></row><row><entry>    <ScubaKeys></entry></row><row><entry>     <!-- E(PUBdevice, PRIVuser) --></entry></row><row><entry>     <PrivateKey id=“urn:kformat:user:1234:scuba:private:sharing”</entry></row><row><entry>        pair=“urn:kformat:user:1234:scuba:pair:sharing”></entry></row><row><entry>      <KeyData encoding=“xmlenc” format=“PKCS8”></entry></row><row><entry>       <!-- E(I, PRIVuser) I: intermediate key--></entry></row><row><entry>       <EncryptedData xmlns=“http://www.w3.org/2001/04/xmlenc#”></entry></row><row><entry>        <EncryptionMethod Algorithm=“http://www.w3.org/2001/04/xmlenc#aes128-cbc”/></entry></row><row><entry>        <KeyInfo xmlns=“http://www.w3.org/2000/09/xmldsig#”></entry></row><row><entry>         <!-- E(PUBdevice, I) --></entry></row><row><entry>         <EncryptedKey xmlns=“http://www.w3.org/2001/04/xmlenc#”></entry></row><row><entry>          <EncryptionMethod Algorithm=“http://www.w3.org/2001/04/xmlenc#rsa-1_5”/></entry></row><row><entry>          <KeyInfo xmlns=“http://www.w3.org/2000/09/xmldsig#”></entry></row><row><entry>           <KeyName>urn:kformat:device:0001:scuba:pair:sharing</KeyName></entry></row><row><entry>          </KeyInfo></entry></row><row><entry>          <CipherData></entry></row><row><entry>           <CipherValue>fFeGD4K... s98dkPR8=</CipherValue></entry></row><row><entry>          </CipherData></entry></row><row><entry>         </EncryptedKey></entry></row><row><entry>        </KeyInfo></entry></row><row><entry>        <CipherData></entry></row><row><entry>         <CipherValue></entry></row><row><entry>c8LBj4BLzGOYv...HIe3ZKtA==</CipherValue></entry></row><row><entry>        </CipherData></entry></row><row><entry>       </EncryptedData></entry></row><row><entry>      </KeyData></entry></row><row><entry>     </PrivateKey></entry></row><row><entry>     <!-- E(PUBdevice, Suser) --></entry></row><row><entry>     <SecretKey id=“urn:kformat:user:1234:secret:sharing”></entry></row><row><entry>      <KeyData encoding=“xmlenc” format=“RAW”></entry></row><row><entry>       <EncryptedData xmlns=“http://www.w3.org/2001/04/xmlenc#”></entry></row><row><entry>        <EncryptionMethod Algorithm=“http://www.w3.org/2001/04/xmlenc#rsa-1_5”/></entry></row><row><entry>        <KeyInfo xmlns=“http://www.w3.org/2000/09/xmldsig#”></entry></row><row><entry>         <KeyName>urn:kformat:device:0001:scuba:pair:sharing</KeyName></entry></row><row><entry>        </KeyInfo></entry></row><row><entry>        <CipherData></entry></row><row><entry>         <CipherValue>OHVaH... kjLA=</CipherValue></entry></row><row><entry>        </CipherData></entry></row><row><entry>       </EncryptedData></entry></row><row><entry>      </KeyData></entry></row><row><entry>     </SecretKey></entry></row><row><entry>    </ScubaKeys></entry></row><row><entry>   </Extension></entry></row><row><entry>  </ExtensionList></entry></row><row><entry>  <LinkFrom></entry></row><row><entry>   <Id>urn:kformat:device:0001</Id></entry></row><row><entry>  </LinkFrom></entry></row><row><entry>  <LinkTo></entry></row><row><entry>   <Id>urn:kformat:user:1234</Id></entry></row><row><entry>  </LinkTo></entry></row><row><entry> </Link></entry></row><row><entry> <Signature xmlns=“http://www.w3.org/2000/09/xmldsig#”></entry></row><row><entry>  <SignedInfo></entry></row><row><entry>   <CanonicalizationMethod Algorithm=“http://www.w3.org/2001/10/xml-exc-c14n#”/></entry></row><row><entry>   <SignatureMethod Algorithm=“http://www.w3.org/2000/09/xmldsig#rsa-sha1”/></entry></row><row><entry>   <Reference URI=“urn:kformat:link:device:0001:to:user:1234”></entry></row><row><entry>    <Transforms></entry></row><row><entry>     <Transform Algorithm=“http://www.octopus-drm.com/2004/07/format-independent-cano#”/></entry></row><row><entry>    </Transforms></entry></row><row><entry>    <DigestMethod Algorithm=“http://www.w3.org/2000/09/xmldsig#sha1”/></entry></row><row><entry>    <DigestValue>gI5QoD7MUAgjcpkPiciZhoSHbEQ=</DigestValue></entry></row><row><entry>   </Reference></entry></row><row><entry>  </SignedInfo></entry></row><row><entry>  <SignatureValue>gI5QoD7MUAgjcpkPiciZhoSHbEQ=</SignatureValue></entry></row><row><entry>  <KeyInfo></entry></row><row><entry>   <X509Data></entry></row><row><entry>    <!-- Put the public key cert of the signing key here --></entry></row><row><entry>    <X509Certificate>...</X509Certificate></entry></row><row><entry>    <!-- and the certificate chain without the root if needed --></entry></row><row><entry>    <X509Certificate>...</X509Certificate></entry></row><row><entry>   </X509Data></entry></row><row><entry>  </KeyInfo></entry></row><row><entry>  </Signature></entry></row><row><entry></Bundle></entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

1230Appendix B—Annex C: Example of a Signed Octopus License (without Revocation) <tables id="TABLE-US-00101" num="101"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="322PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry><Bundle xmlns=“http://intertrust.com/Octopus/1.0” xmlns:xsi=“http://www.w3.org/2001/XMLSchema-</entry></row><row><entry>instance” xsi:schemaLocation=“http://intertrust.com/Octopus/1.0</entry></row><row><entry>C:\ws\Octopus\Source\Xml\Schemas\Octopus.xsd”></entry></row><row><entry> <ContentKey id=“urn:x-octopus.intertrust.com:content-key:2002”></entry></row><row><entry>  <SecretKey id=“urn:x-octopus.intertrust.com:secret-key:2002”></entry></row><row><entry>   <KeyData encoding=“xmlenc” format=“RAW”></entry></row><row><entry>    <EncryptedData xmlns=“http://www.w3.org/2001/04/xmlenc#”></entry></row><row><entry>     <EncryptionMethod Algorithm=“http://www.w3.org/2001/04/xmlenc#aes128-cbc”/></entry></row><row><entry>     <KeyInfo xmlns=“http://www.w3.org/2000/09/xmldsig#”></entry></row><row><entry>      <KeyName>urn:x-octopus.intertrust.com:secret-key:303c</KeyName></entry></row><row><entry>     </KeyInfo></entry></row><row><entry>     <CipherData></entry></row><row><entry>      <CipherValue></entry></row><row><entry>MCR0LGaoyuO2o6zsIW9IrOOSMfhuZCtV20o94/OfQ5dHbIJ3q2vZrgwRbJepLvRa</entry></row><row><entry>      </CipherValue></entry></row><row><entry>     </CipherData></entry></row><row><entry>    </EncryptedData></entry></row><row><entry>   </KeyData></entry></row><row><entry>  </SecretKey></entry></row><row><entry> </ContentKey></entry></row><row><entry> <ContentKey id=“urn:x-octopus.intertrust.com:content-key:2001”></entry></row><row><entry>  <SecretKey id=“urn:x-octopus.intertrust.com:secret-key:2001”></entry></row><row><entry>   <KeyData encoding=“xmlenc” format=“RAW”></entry></row><row><entry>    <EncryptedData xmlns=“http://www.w3.org/2001/04/xmlenc#”></entry></row><row><entry>     <EncryptionMethod Algorithm=“http://www.w3.org/2001/04/xmlenc#rsa-1_5”/></entry></row><row><entry>     <KeyInfo xmlns=“http://www.w3.org/2000/09/xmldsig#”></entry></row><row><entry>      <KeyName>urn:x-octopus.intertrust.com:key-pair:300c</KeyName></entry></row><row><entry>     </KeyInfo></entry></row><row><entry>     <CipherData></entry></row><row><entry>      <CipherValue></entry></row><row><entry>LD51cJ71Bswwb2GttPoPjMytFn3ooeI7vhZPA5mKY06R82KZjxFDtcCmbOlYZ5Hv</entry></row><row><entry>6ldqQ3hy74/mQF3AJ1jRXa9/ymmasVBxsJnv426B9/JkzTT4CGqNjS+WPOKL9NZC</entry></row><row><entry>qnRWguJmk8dQ+jaxW51SQSjp4MCpGZB63zfvcuBD7qE=</entry></row><row><entry>      </CipherValue></entry></row><row><entry>     </CipherData></entry></row><row><entry>    </EncryptedData></entry></row><row><entry>   </KeyData></entry></row><row><entry>  </SecretKey></entry></row><row><entry> </ContentKey></entry></row><row><entry> <Control id=“urn:x-octopus.intertrust.com:control:0001”></entry></row><row><entry>  <ControlProgram type=“Plankton”></entry></row><row><entry>   <CodeModule byteCodeType=“Plankton-1-0”></entry></row><row><entry>AAABUnBrQ00AAAA2cGtFWAAAAAIOR2xvYmFsLk9uTG9hZAAAAAAAEkFjdGlvbi5QbGF5LkNo</entry></row><row><entry>ZWNrAAAAAFgAAACmcGtDUwEAAAAEGgEAAAAABQEAAAACIAMBAAAABBoBAAAAHgUb</entry></row><row><entry>AQAAACwYAQAAAAQaAQAAACIFAQAAAAIgAwEAAAAEGgEAAAA7BRsBAAAABhgBAAAA</entry></row><row><entry>ABUB/////xUBAAAABBoBAAAAPwUBAAAABBoBAAAAHgUaIAEAAAAgGAEAAAAEGgEAAAA</entry></row><row><entry>7BRogAQEOX3oLAQAAAAYYAQAAAAAVAf////8VAAAAbnBrRFNPY3RvcHVzLkxpbmtzLklzTm9</entry></row><row><entry>kZVJ1YWNoYWJsZQAAAAAAU3lzdGVtLkhvc3QuR2V0VGltZVN0YW1wAAAAAAB1cm46eC1vY3</entry></row><row><entry>RvcHVzLmludGVydHJ1c3QuY29tOm5vZGU6MDAwMwA=</entry></row><row><entry>  </CodeModule></entry></row><row><entry>  </ControlProgram></entry></row><row><entry> </Control></entry></row><row><entry> <Protector></entry></row><row><entry>  <ContentKeyReference></entry></row><row><entry>   <Id>urn:x-octopus.intertrust.com:content-key:2002</Id></entry></row><row><entry>  </ContentKeyReference></entry></row><row><entry>  <ProtectedTargets></entry></row><row><entry>   <ContentReference></entry></row><row><entry>    <Id>urn:x-octopus.intertrust.com:content:2001</Id></entry></row><row><entry>   </ContentReference></entry></row><row><entry>   <ContentReference></entry></row><row><entry>    <Id>urn:x-octopus.intertrust.com:content:2002</Id></entry></row><row><entry>   </ContentReference></entry></row><row><entry>  </ProtectedTargets></entry></row><row><entry> </Protector></entry></row><row><entry> <Protector></entry></row><row><entry>  <ContentKeyReference></entry></row><row><entry>   <Id>urn:x-octopus.intertrust.com:content-key:2001</Id></entry></row><row><entry>  </ContentKeyReference></entry></row><row><entry>  <ProtectedTargets></entry></row><row><entry>   <ContentReference></entry></row><row><entry>    <Id>urn:x-octopus.intertrust.com:content:2003</Id></entry></row><row><entry>   </ContentReference></entry></row><row><entry>   <ContentReference></entry></row><row><entry>    <Id>urn:x-octopus.intertrust.com:content:2004</Id></entry></row><row><entry>   </ContentReference></entry></row><row><entry>  </ProtectedTargets></entry></row><row><entry> </Protector></entry></row><row><entry> <Controller id=“urn:x-octopus.intertrust.com:controller:0001”></entry></row><row><entry>  <ControlReference></entry></row><row><entry>   <Id>urn:x-octopus.intertrust.com:control:0001</Id></entry></row><row><entry>    <Digest></entry></row><row><entry>    <DigestMethod Algorithm=“http://www.w3.org/2000/09/xmldsig#sha1”</entry></row><row><entry>xmlns=“http://www.w3.org/2000/09/xmldsig#”/></entry></row><row><entry>    <DigestValue</entry></row><row><entry>xmlns=“http://www.w3.org/2000/09/xmldsig#”>02ACF5674287FF45CFA5A66D70125FF5601A63F7</Digest</entry></row><row><entry>Value></entry></row><row><entry>    </Digest></entry></row><row><entry>   </ControlReference></entry></row><row><entry>   <ControlledTargets></entry></row><row><entry>    <ContentKeyReference></entry></row><row><entry>     <Id>urn:x-octopus.intertrust.com:content-key:2002</Id></entry></row><row><entry>    </ContentKeyReference></entry></row><row><entry>    <ContentKeyReference></entry></row><row><entry>     <Id>urn:x-octopus.intertrust.com:content-key:2001</Id></entry></row><row><entry>    </ContentKeyReference></entry></row><row><entry>   </ControlledTargets></entry></row><row><entry>  </Controller></entry></row><row><entry>  <Signature xmlns=“http://www.w3.org/2000/09/xmldsig#”></entry></row><row><entry>   <SignedInfo></entry></row><row><entry>    <CanonicalizationMethod Algorithm=“http://www.w3.org/2001/10/xml-exc-c14n#”/></entry></row><row><entry>    <SignatureMethod Algorithm=“http://www.w3.org/2000/09/xmldsig#hmac-sha1”/></entry></row><row><entry>    <Reference URI=“urn:x-octopus.intertrust.com:controller:0001”></entry></row><row><entry>     <Transforms></entry></row><row><entry>      <Transform Algorithm=“http://www.octopus-drm.com/2004/07/format-independent-cano#”/></entry></row><row><entry>     </Transforms></entry></row><row><entry>     <DigestMethod Algorithm=“http://www.w3.org/2000/09/xmldsig#sha1”/></entry></row><row><entry>     <DigestValue>A42CZFK4DQvb/M0wqOLZRnyiS1Y=</DigestValue></entry></row><row><entry>    </Reference></entry></row><row><entry>   </SignedInfo></entry></row><row><entry>   <SignatureValue>gI5QoD7MUAgjcpkPiciZhoSHbEQ=</SignatureValue></entry></row><row><entry>   <KeyInfo></entry></row><row><entry>    <KeyName>urn:x-octopus.intertrust.com:secret-key:2002;urn:x-octopus.intertrust.com:secret-</entry></row><row><entry>key:2001</KeyName></entry></row><row><entry>  </KeyInfo></entry></row><row><entry> </Signature></entry></row><row><entry></Bundle></entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

1231Appendix B—Annex D: Example of a ContentKey with Revocation <tables id="TABLE-US-00102" num="102"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="280PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry><ContentKey id=“urn:x-octopus.intertrust.com:content-key:2001”></entry></row><row><entry> <SecretKey id=“urn:x-octopus.intertrust.com:secret-key:2001”></entry></row><row><entry>  <KeyData encoding=“xmlenc” format=“RAW”></entry></row><row><entry>   <EncryptedData xmlns=“http://www.w3.org/2001/04/xmlenc#”></entry></row><row><entry>    <EncryptionMethod Algorithm=“http://www.w3.org/2001/04/xmlenc#aes128-cbc”/></entry></row><row><entry>    <KeyInfo xmlns=“http://www.w3.org/2000/09/xmldsig#”></entry></row><row><entry>     <EncryptedKey xmlns=“http://www.w3.org/2001/04/xmlenc#”></entry></row><row><entry>      <EncryptionMethod Algorithm=“http://www.w3.org/2001/04/xmlenc#rsa-1_5”/></entry></row><row><entry>      <KeyInfo xmlns=“http://www.w3.org/2000/09/xmldsig#”></entry></row><row><entry>       <KeyName>urn:kformat:user:0001:scuba:pair:sharing</KeyName></entry></row><row><entry>      </KeyInfo></entry></row><row><entry>      <CipherData></entry></row><row><entry>       <CipherValue>E(PUBuser, I)</CipherValue></entry></row><row><entry>      </CipherData></entry></row><row><entry>     </EncryptedKey></entry></row><row><entry>    </KeyInfo></entry></row><row><entry>    <CipherData></entry></row><row><entry>     <CipherValue></entry></row><row><entry>     Encryption of the EncryptedData element containing</entry></row><row><entry>     the encryption of Kc with the broadcast encryption</entry></row><row><entry>     scheme (see note on xmlenc and broadcast key encryption</entry></row><row><entry>     in the ContentKey section) with the intermediate key I.</entry></row><row><entry>     </CipherValue></entry></row><row><entry>    </CipherData></entry></row><row><entry>   </EncryptedData></entry></row><row><entry>  </KeyData></entry></row><row><entry> </SecretKey></entry></row><row><entry></ContentKey></entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

Appendix C

1232This Appendix C shows an example of simple profile for use with the bootstrap protocol described above. Also provided are a simple canonical serialization, an example XML marshalling, and example WSDL for the Octopus Bootstrap SOAP Web Serivce.

1233Simple Profile

1234In one embodiment, a simple profile is used that consists of the following: <tables id="TABLE-US-00103" num="103"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="105PT" align="left" /><colspec colname="2" colwidth="112PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row><row><entry>Profile Name</entry><entry>SimpleProfile</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Public Key Encryption Algorithm</entry><entry>http://www.w3.org/2001/04/</entry></row><row><entry /><entry>xmlenc#rsa-1_5</entry></row><row><entry>Public Key Signature Algorithm</entry><entry>http://www.w3.org/2000/09/</entry></row><row><entry /><entry>xmldsig#rsa-sha1</entry></row><row><entry>Secret Key Encryption Algorithm</entry><entry>http://www.w3.org/2001/04/</entry></row><row><entry /><entry>xmlenc#aes128-cbc</entry></row><row><entry>Secret Key Signature Algorithm</entry><entry>http://www.w3.org/2000/09/</entry></row><row><entry /><entry>xmldsig#hmac-sha1</entry></row><row><entry>Digest Algorithm</entry><entry>http://www.w3.org/2000/09/</entry></row><row><entry /><entry>xmldsig#sha1</entry></row><row><entry>Certificate Format</entry><entry>X.509 (version 3)</entry></row><row><entry>Message Marshalling</entry><entry>Simple XML Marshalling 1.0</entry></row><row><entry>Minimum Nonce Size</entry><entry>16 bytes</entry></row><row><entry>Canonical Object Serialization</entry><entry>Simple Canonical Serialization 1.0</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

1235Simple Canonical Serialization 1.0

1236In one embodiment, the simple canonical byte sequence used in the simple profile described above consists of constructing sequences of bytes from the values of the fields of the objects in the messages. Each message and each object is made of one or more fields. Each field is either a simple field, or a compound field.

1237Simple fields can be one of four types: integer, string, byte sequence, or arrays of fields. Compound fields consist of one or more sub-fields, each sub-field being simple or compound.

1238In one embodiment, the rules for constructing the canonical byte sequence for each field type are as follows:

1239Compound Fields <tables id="TABLE-US-00104" num="104"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="5"><colspec colname="OFFSET" colwidth="21PT" align="left" /><colspec colname="1" colwidth="28PT" align="center" /><colspec colname="2" colwidth="70PT" align="center" /><colspec colname="3" colwidth="28PT" align="center" /><colspec colname="4" colwidth="70PT" align="center" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="4" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Field 0</entry><entry>Field 1</entry><entry>Field 2</entry><entry>. . .</entry></row><row><entry /><entry namest="OFFSET" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

1240The canonical byte sequence is the concatenation of the canonical byte sequences of each sub-field (optional fields are not skipped, but serialized according to the rule for optional fields).

1241Arrays of Fields <tables id="TABLE-US-00105" num="105"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="5"><colspec colname="OFFSET" colwidth="21PT" align="left" /><colspec colname="1" colwidth="42PT" align="center" /><colspec colname="2" colwidth="70PT" align="center" /><colspec colname="3" colwidth="28PT" align="center" /><colspec colname="4" colwidth="56PT" align="center" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="4" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Field count</entry><entry>Field 0</entry><entry>Field 1</entry><entry>. . .</entry></row><row><entry /><entry namest="OFFSET" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

1242The field count, encoded as a sequence of 4 bytes in big-endian order, followed by each field's canonical byte sequence. If the field count is 0, then nothing follows the 4-bytes field count (in this case, all 4 bytes have the value 0).

1243Integer <tables id="TABLE-US-00106" num="106"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="5"><colspec colname="OFFSET" colwidth="35PT" align="left" /><colspec colname="1" colwidth="14PT" align="center" /><colspec colname="2" colwidth="70PT" align="center" /><colspec colname="3" colwidth="14PT" align="center" /><colspec colname="4" colwidth="84PT" align="center" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="4" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>I0</entry><entry>I1</entry><entry>I2</entry><entry>I3</entry></row><row><entry /><entry namest="OFFSET" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

124432-bit signed value, encoded as a sequence of 4 bytes, in big-endian order.

1245String <tables id="TABLE-US-00107" num="107"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="5"><colspec colname="OFFSET" colwidth="21PT" align="left" /><colspec colname="1" colwidth="42PT" align="center" /><colspec colname="2" colwidth="70PT" align="center" /><colspec colname="3" colwidth="28PT" align="center" /><colspec colname="4" colwidth="56PT" align="center" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="4" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Byte Count</entry><entry>Byte 0</entry><entry>Byte 1</entry><entry>. . .</entry></row><row><entry /><entry namest="OFFSET" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

1246The string is represented by a UTF-8 encoded sequence of 8-bit bytes. The byte count of the encoded byte sequence is encoded as a sequence of 4 bytes in big-endian order. The byte count is followed by the sequence of bytes of the UTF-8 encoded string.

1247Byte Sequence <tables id="TABLE-US-00108" num="108"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="5"><colspec colname="OFFSET" colwidth="21PT" align="left" /><colspec colname="1" colwidth="42PT" align="center" /><colspec colname="2" colwidth="70PT" align="center" /><colspec colname="3" colwidth="28PT" align="center" /><colspec colname="4" colwidth="56PT" align="center" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="4" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Byte Count</entry><entry>Byte 0</entry><entry>Byte 1</entry><entry>. . .</entry></row><row><entry /><entry namest="OFFSET" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

1248The byte count is encoded as a sequence of 4 bytes in big-endian order (if the byte sequence is empty, or the corresponding field has been omitted, the Byte Count is 0, and no byte value follows the 4-byte byte count). Each byte is encoded as-is.

1249Simple XML Marshalling 1.0

1250Schema SimpleBootProtocol.xsd <tables id="TABLE-US-00109" num="109"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="287PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry><xs:schema xmlns:xs=“http://www.w3.org/2001/XMLSchema” elementFormDefault=“qualified”></entry></row><row><entry>  <xs:element name=“BootstrapRequestMessage”></entry></row><row><entry>    <xs:complexType></entry></row><row><entry>      <xs:sequence></entry></row><row><entry>        <xs:element ref=“BootstrapRequest”/></entry></row><row><entry>      </xs:sequence></entry></row><row><entry>      <xs:attribute name=“Protocol” type=“xs:string” use=“required”/></entry></row><row><entry>      <xs:attribute name=“Profile” type=“xs:string” use=“required”/></entry></row><row><entry>      <xs:attribute name=“Version” type=“xs:decimal” use=“required”/></entry></row><row><entry>    </xs:complexType></entry></row><row><entry>  </xs:element></entry></row><row><entry>  <xs:element name=“BootstrapRequest”></entry></row><row><entry>    <xs:complexType></entry></row><row><entry>      <xs:sequence></entry></row><row><entry>        <xs:element ref=“SessionId”/></entry></row><row><entry>        <xs:element ref=“TrustDomain” maxOccurs=“unbounded”/></entry></row><row><entry>      </xs:sequence></entry></row><row><entry>    </xs:complexType></entry></row><row><entry>  </xs:element></entry></row><row><entry>  <xs:element name=“ChallengeRequestMessage”></entry></row><row><entry>    <xs:complexType></entry></row><row><entry>      <xs:sequence></entry></row><row><entry>        <xs:element ref=“ChallengeRequest”/></entry></row><row><entry>      </xs:sequence></entry></row><row><entry>    </xs:complexType></entry></row><row><entry>  </xs:element></entry></row><row><entry>  <xs:element name=“ChallengeRequest”></entry></row><row><entry>    <xs:complexType></entry></row><row><entry>      <xs:sequence></entry></row><row><entry>        <xs:element ref=“Challenge”/></entry></row><row><entry>        <xs:element ref=“Signature”/></entry></row><row><entry>        <xs:element ref=“CertificateChain”/></entry></row><row><entry>      </xs:sequence></entry></row><row><entry>    </xs:complexType></entry></row><row><entry>  </xs:element></entry></row><row><entry>  <xs:element name=“ChallengeResponseMessage”></entry></row><row><entry>    <xs:complexType></entry></row><row><entry>      <xs:sequence></entry></row><row><entry>        <xs:element ref=“SessionKey”/></entry></row><row><entry>        <xs:element ref=“EncryptedChallengeResponse”/></entry></row><row><entry>      </xs:sequence></entry></row><row><entry>    </xs:complexType></entry></row><row><entry>  </xs:element></entry></row><row><entry>  <xs:element name=“EncryptedChallengeResponse” type=“xs:base64Binary”/></entry></row><row><entry>  <xs:element name=“ChallengeResponse”></entry></row><row><entry>    <xs:complexType></entry></row><row><entry>      <xs:sequence></entry></row><row><entry>        <xs:element ref=“ClientInfo”/></entry></row><row><entry>        <xs:element ref=“Challenge”/></entry></row><row><entry>        <xs:element ref=“SessionKey”/></entry></row><row><entry>        <xs:element ref=“Signature”/></entry></row><row><entry>      </xs:sequence></entry></row><row><entry>    </xs:complexType></entry></row><row><entry>  </xs:element></entry></row><row><entry>  <xs:element name=“Challenge”></entry></row><row><entry>    <xs:complexType></entry></row><row><entry>      <xs:sequence></entry></row><row><entry>        <xs:element ref=“Cookie”/></entry></row><row><entry>        <xs:element ref=“Nonce”/></entry></row><row><entry>        <xs:element ref=“SessionId”/></entry></row><row><entry>        <xs:element ref=“EncryptionKey” minOccurs=“0”/></entry></row><row><entry>      </xs:sequence></entry></row><row><entry>    </xs:complexType></entry></row><row><entry>  </xs:element></entry></row><row><entry>  <xs:element name=“BootstrapResponseMessage”></entry></row><row><entry>    <xs:complexType></entry></row><row><entry>      <xs:sequence></entry></row><row><entry>        <xs:element ref=“EncryptedBootstrapResponse”/></entry></row><row><entry>      </xs:sequence></entry></row><row><entry>    </xs:complexType></entry></row><row><entry>  </xs:element></entry></row><row><entry>  <xs:element name=“EncryptedBootstrapResponse” type=“xs:base64Binary”/></entry></row><row><entry>  <xs:element name=“BootstrapResponse”></entry></row><row><entry>    <xs:complexType></entry></row><row><entry>      <xs:sequence></entry></row><row><entry>        <xs:element ref=“SessionId”/></entry></row><row><entry>        <xs:element ref=“Data”/></entry></row><row><entry>        <xs:element ref=“Signature”/></entry></row><row><entry>      </xs:sequence></entry></row><row><entry>    </xs:complexType></entry></row><row><entry>  </xs:element></entry></row><row><entry>  <xs:element name=“ErrorResponseMessage”></entry></row><row><entry>    <xs:complexType></entry></row><row><entry>      <xs:sequence></entry></row><row><entry>        <xs:element ref=“ErrorResponse”/></entry></row><row><entry>      </xs:sequence></entry></row><row><entry>    </xs:complexType></entry></row><row><entry>  </xs:element></entry></row><row><entry>  <xs:element name=“ErrorResponse” type=“xs:string”/></entry></row><row><entry>  <xs:element name=“CertificateChain”></entry></row><row><entry>    <xs:complexType></entry></row><row><entry>      <xs:sequence></entry></row><row><entry>        <xs:element ref=“Certificate” maxOccurs=“unbounded”/></entry></row><row><entry>      </xs:sequence></entry></row><row><entry>      <xs:attribute name=“TrustDomain” type=“xs:string” use=“required”/></entry></row><row><entry>    </xs:complexType></entry></row><row><entry>  </xs:element></entry></row><row><entry>  <xs:element name=“Certificate” type=“xs:base64Binary”/></entry></row><row><entry>  <xs:element name=“ClientInfo”></entry></row><row><entry>    <xs:complexType></entry></row><row><entry>      <xs:sequence></entry></row><row><entry>        <xs:element ref=“Attribute”/></entry></row><row><entry>      </xs:sequence></entry></row><row><entry>    </xs:complexType></entry></row><row><entry>  </xs:element></entry></row><row><entry>  <xs:element name=“Attribute” type=“xs:string”/></entry></row><row><entry>  <xs:element name=“Cookie” type=“xs:base64Binary”/></entry></row><row><entry>  <xs:element name=“Data” type=“xs:base64Binary”/></entry></row><row><entry>  <xs:element name=“EncryptionKey” type=“xs:base64Binary”/></entry></row><row><entry>  <xs:element name=“Nonce” type=“xs:base64Binary”/></entry></row><row><entry>  <xs:element name=“SessionId” type=“xs:string”/></entry></row><row><entry>  <xs:element name=“SessionKey” type=“xs:base64Binary”/></entry></row><row><entry>  <xs:element name=“Signature” type=“xs:base64Binary”/></entry></row><row><entry>  <xs:element name=“TrustDomain” type=“xs:string”/></entry></row><row><entry></xs:schema></entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

1251Example: <tables id="TABLE-US-00110" num="110"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="308PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry><BootstrapRequestMessage Protocol=“OctopusSimpleBoot” Profile=“SimpleProfile” Version=“1.0”></entry></row><row><entry> <BootstrapRequest></entry></row><row><entry>  <SessionId>some-unique-session-id-0008</SessionId></entry></row><row><entry>  <TrustDomain>urn:x-octopus.intertrust.com:scuba:boot:trust-domain:test001</TrustDomain></entry></row><row><entry> </BootstrapRequest></entry></row><row><entry></BootstrapRequestMessage></entry></row><row><entry><ChallengeRequestMessage></entry></row><row><entry> <ChallengeRequest></entry></row><row><entry>  <Challenge></entry></row><row><entry>   <Cookie>c29tZS11bmlxdWUtc2Vzc2lvbi1pZC0wMDA4</Cookie></entry></row><row><entry>   <Nonce>Mv5VIv73cxo5b+gisQJP8Q==</Nonce></entry></row><row><entry>   <SessionId>some-unique-session-id-0008</SessionId></entry></row><row><entry>   <EncryptionKey></entry></row><row><entry>MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCpMY4wvgTJvVPTufNVbdIfTUwOi4FZPtzi</entry></row><row><entry>3ezetY9gx51O6dfRn+LKPq1nJsSXCR5ZIvRUyoNZC0Qc3SLobUhXD6uTsrV5xtRKOSxZTLt5DZ15At</entry></row><row><entry>ddSrAAfF9baDGMi5KQP9w7qB2Ci/MmYha4Jix1iUltv0zWIKmSpytgHC8i/QIDAQAB</entry></row><row><entry>   </EncryptionKey></entry></row><row><entry>  </Challenge></entry></row><row><entry>  <Signature></entry></row><row><entry>GsWP3yPT36r3e1jZfulUS7xp5w2ei7iTsAJ/YD13fX+pSJrpeKAtq2BTzHQ1AclOorPJwzWHDanc</entry></row><row><entry>cui9/rinlg3Drw52bQXLzhZbZLXadIGFP3YP1gTKPuazUCYCLAjYTJbdulWlnTKDtmf34/66H0sz</entry></row><row><entry>DCCyxQsdFZhSNk6pyQE=</entry></row><row><entry>  </Signature></entry></row><row><entry>  <CertificateChain TrustDomain=“urn:x-octopus.intertrust.com:scuba:boot:trust-domain:test001”></entry></row><row><entry>   <Certificate></entry></row><row><entry>          MIID...<!-- End entity cert --></entry></row><row><entry>   </Certificate></entry></row><row><entry>          MIID...<!-- intermediary cert --></entry></row><row><entry>   <Certificate></entry></row><row><entry>          MIIE...<!-- intermediary cert --></entry></row><row><entry>   </Certificate></entry></row><row><entry>   <Certificate></entry></row><row><entry>         MIID...<!-- cert that chains directly to the trust anchor --></entry></row><row><entry>   </Certificate></entry></row><row><entry>  </CertificateChain></entry></row><row><entry> </ChallengeRequest></entry></row><row><entry></ChallengeRequestMessage></entry></row><row><entry><ChallengeResponseMessage></entry></row><row><entry> <SessionKey></entry></row><row><entry>PtzJcFT2s1sW7oRZ1a+HASdRmZer4pk4QArFZWYlkUWZcIZTN2g2YeCQwORq2J9QXOksU6utKm</entry></row><row><entry>OmgfEHY151UdcMFake3CwquvVN6w/7mFH0qtDoc+GhuKe9eQXN2RHa3SlhfR5ShF2A/cwZHd4Nk</entry></row><row><entry>nt4w8MWMDDn3SUDd6aS/ZI=</entry></row><row><entry> </SessionKey></entry></row><row><entry> <EncryptedChallengeResponse></entry></row><row><entry>      mQCkPL560D00o...</entry></row><row><entry> </EncryptedChallengeResponse></entry></row><row><entry></ChallengeResponseMessage></entry></row><row><entry><ChallengeResponse></entry></row><row><entry> <ClientInfo></entry></row><row><entry>  <Attribute Name=“SomeAttribute”>Bla Bla</Attribute></entry></row><row><entry> </ClientInfo></entry></row><row><entry> <Challenge></entry></row><row><entry>  <Cookie>c29tZS11bmlxdWUtc2Vzc2lvbi1pZC0wMDA4</Cookie></entry></row><row><entry>  <Nonce>Mv5VIv73cxo5b+gisQJP8Q==</Nonce></entry></row><row><entry>  <SessionId>some-unique-session-id-0008</SessionId></entry></row><row><entry> </Challenge></entry></row><row><entry> <SessionKey>bbBG8JsGaApFdNJq6hFrIQ==</SessionKey></entry></row><row><entry> <Signature>WYMULPpF4lOJ6MiAxd1lueN7p/4=</Signature></entry></row><row><entry></ChallengeResponse></entry></row><row><entry><BootstrapResponseMessage></entry></row><row><entry> <EncryptedBootstrapResponse></entry></row><row><entry>chXTp20+yI7/i1pHLawFOLXdGb...</entry></row><row><entry> </EncryptedBootstrapResponse></entry></row><row><entry></BootstrapResponseMessage></entry></row><row><entry><BootstrapResponse></entry></row><row><entry> <SessionId>some-unique-session-id-0008</SessionId></entry></row><row><entry> <Data></entry></row><row><entry>PD94bWwgdmVyc...</entry></row><row><entry> </Data></entry></row><row><entry> <Signature></entry></row><row><entry>XqCeVRb4YaYAK9Ilj60B5R1hQ03tFpHPw3wMMATbeUfqCpEXfAB7u2/qnjs9jLgWTOOvLDE5C5a</entry></row><row><entry>VVMvzlnRnDv0GHLls6g43HusVx7fpazwHoFrb3M3eKwXMoYsI6xpdYy2BX1bs5QT2xdwBv2ClBjo7</entry></row><row><entry>KzQfmb/3bYEO+xGdg48=</entry></row><row><entry> </Signature></entry></row><row><entry></BootstrapResponse></entry></row><row><entry><ErrorResponseMessage></entry></row><row><entry> <ErrorResponse Code=“6”>Some Error Info</ErrorResponse></entry></row><row><entry></ErrorResponseMessage></entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

1252WSDL for the Bootstrap SOAP Web Service <tables id="TABLE-US-00111" num="111"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="308PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry></entry></row><row><entry><!--</entry></row><row><entry>This wsdl file describes the interface for a stateless multiround bootstrap protocol</entry></row><row><entry>The protocol works this way:</entry></row><row><entry>1. C->S: BootstrapRequestMessage</entry></row><row><entry>2. S->C: ChallengeRequestMessage</entry></row><row><entry>3. C->S: ChallengeResponseMessage</entry></row><row><entry>4. S->C: BootstrapResponseMessage</entry></row><row><entry>--></entry></row><row><entry><wsdl:definitions name=“OctopusBootstrap”</entry></row><row><entry>targetNamespace=“http://www.intertrust.com/services/OctopusBootstrap”</entry></row><row><entry>xmlns=“http://schemas.xmlsoap.org/wsdl/” xmlns:apachesoap=“http://xml.apache.org/xml-soap”</entry></row><row><entry>xmlns:impl=“http://www.intertrust.com/services/OctopusBootstrap”</entry></row><row><entry>xmlns:intf=“http://www.intertrust.com/services/OctopusBootstrap”</entry></row><row><entry>xmlns:soapenc=“http://schemas.xmlsoap.org/soap/encoding/”</entry></row><row><entry>xmlns:tnstype=“http://www.intertrust.com/services/OctopusBootstrap”</entry></row><row><entry>xmlns:wsdl=“http://schemas.xmlsoap.org/wsdl/” xmlns:wsdlsoap=“http://schemas.xmlsoap.org/wsdl/soap/”</entry></row><row><entry>xmlns:xsd=“http://www.w3.org/2001/XMLSchema”</entry></row><row><entry>xmlns:ob=“http://www.intertrust.com/Octopus/Bootstrap/1.0”</entry></row><row><entry>xmlns:nc=“http://www.intertrust.com/core”></entry></row><row><entry> <wsdl:types></entry></row><row><entry>  <schema targetNamespace=“http://www.intertrust.com/services/OctopusBootstrap”</entry></row><row><entry>xmlns=“http://www.w3.org/2001/XMLSchema”></entry></row><row><entry>   <!-- imports --></entry></row><row><entry>   <import namespace=“http://www.intertrust.com/Octopus/Bootstrap/1.0”</entry></row><row><entry>schemaLocation=“./SimpleBootProtocol.xsd”/></entry></row><row><entry>   <!-- elements --></entry></row><row><entry>   <element name=“requestdata”></entry></row><row><entry>    <complexType></entry></row><row><entry>     <!-- This is a multiround stateless (thanks to the cookie) protocol:</entry></row><row><entry>       the client can send a BootstrapRequestMessage or</entry></row><row><entry>       ChallengeReponseMessage --></entry></row><row><entry>     <choice></entry></row><row><entry>      <element ref=“ob:BootstrapRequestMessage”/></entry></row><row><entry>      <element ref=“ob:ChallengeResponseMessage”/></entry></row><row><entry>     </choice></entry></row><row><entry>    </complexType></entry></row><row><entry>   </element></entry></row><row><entry>   <element name=“responsedata”></entry></row><row><entry>    <complexType></entry></row><row><entry>     <!-- This is a multiround stateless (thanks to the cookie) protocol:</entry></row><row><entry>     the server can send back a ChallengeRequestMessage or</entry></row><row><entry>     BootstrapResponseMessage or an ErrorResponseMessage --></entry></row><row><entry>     <choice></entry></row><row><entry>      <element ref=“ob:ChallengeRequestMessage”/></entry></row><row><entry>      <element ref=“ob:BootstrapResponseMessage”/></entry></row><row><entry>      <element ref=“ob:ErrorResponseMessage”/></entry></row><row><entry>     </choice></entry></row><row><entry>    </complexType></entry></row><row><entry>   </element></entry></row><row><entry>  </schema></entry></row><row><entry> </wsdl:types></entry></row><row><entry> <!-- message declarations --></entry></row><row><entry> <wsdl:message name=“invokeRequest”></entry></row><row><entry>  <wsdl:part element=“tnstype:requestdata” name=“invokeRequest”/></entry></row><row><entry> </wsdl:message></entry></row><row><entry> <wsdl:message name=“invokeResponse”></entry></row><row><entry>  <wsdl:part element=“tnstype:responsedata” name=“invokeResponse”/></entry></row><row><entry> </wsdl:message></entry></row><row><entry> <!-- port type declarations --></entry></row><row><entry> <wsdl:portType name=“OctopusBootstrap”></entry></row><row><entry>  <wsdl:operation name=“invoke”></entry></row><row><entry>   <wsdl:input message=“impl:invokeRequest” name=“invokeRequest”/></entry></row><row><entry>   <wsdl:output message=“impl:invokeResponse” name=“invokeResponse”/></entry></row><row><entry>  </wsdl:operation></entry></row><row><entry> </wsdl:portType></entry></row><row><entry> <!-- binding declarations --></entry></row><row><entry> <wsdl:binding name=“OctopusBootstrapSoapBinding” type=“impl:OctopusBootstrap”></entry></row><row><entry>  <wsdlsoap:binding style=“document” transport=“http://schemas.xmlsoap.org/soap/http”/></entry></row><row><entry>  <wsdl:operation name=“invoke”></entry></row><row><entry>   <wsdlsoap:operation soapAction=“”/></entry></row><row><entry>    <wsdl:input name=“invokeRequest”></entry></row><row><entry>    <wsdlsoap:body encodingStyle=“”</entry></row><row><entry>namespace=“http://www.intertrust.com/services/OctopusBootstrap” use=“literal”/></entry></row><row><entry>   </wsdl:input></entry></row><row><entry>   <wsdl:output name=“invokeResponse”></entry></row><row><entry>    <wsdlsoap:body encodingStyle=“”</entry></row><row><entry>namespace=“http://www.intertrust.com/services/OctopusBootstrap” use=“literal”/></entry></row><row><entry>   </wsdl:output></entry></row><row><entry>  </wsdl:operation></entry></row><row><entry> </wsdl:binding></entry></row><row><entry> <!-- service declarations --></entry></row><row><entry> <wsdl:service name=“OctopusBootstrapService”></entry></row><row><entry>  <wsdl:port binding=“impl:OctopusBootstrapSoapBinding” name=“OctopusBootstrap”></entry></row><row><entry>   <wsdlsoap:address location=“http://localhost:8080/OctopusBootstrap/services/OctopusBootstrap”/></entry></row><row><entry>  </wsdl:port></entry></row><row><entry> </wsdl:service></entry></row><row><entry></wsdl:definitions></entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

Appendix D

1253An encoding-neutral way of computing a canonical byte sequence (CBS) for objects is presented below and used, in preferred embodiments, in the calculation of digests for use digitally signing objects. This byte sequence is independent of the way the objects are represented or transmitted, thus enabling the same digest and signature values to be used throughout systems in which multiple encoding formats (e.g., XML, ANS1), programming languages, or the like are used.

00001. Canonical Byte Sequence Algorithm

1254The canonical byte sequence algorithm consists of constructing sequences of bytes from value of fields. Each field has a value with a simple type or a compound type. Some fields can be specified to be optional (the field may be present or omitted).

1255In one embodiment, simple types are: integer, string, byte, and boolean.

1256Compound types consist of one or more sub-fields; each sub-field having a value with a simple or compound type. Compound types are either heterogeneous or homogenous, meaning that there are one or more sub-field values (simple or compound) of different types (i.e., heterogeneous), or that there are one or more sub-field values (simple or compound) all of the same type (homogeneous).

1257The canonical byte sequence of a field is obtained by applying the encoding rule to the field's value when the field is always present or the encoding rule for optional fields when the field is specified to be optional. In the following encoding rule descriptions, the term byte means an 8-bit value (octet):

12581.1. Optional Fields

1259If an optional field is present, its value is serialized as the byte value 1 followed by the canonical byte sequence of the field value. If it is omitted, its value is serialized as the byte value 0.

12601.2. Heterogeneous Compound

1261The canonical byte sequence is the concatenation of the canonical byte sequences of each sub-field value (optional fields are not skipped, but serialized according to the rule for optional fields).

12621.3. Homogeneous Compound

1263The canonical byte sequence is the sub-field count, encoded as a sequence of 4 bytes in big-endian order, followed by the concatenation of each sub-field value's canonical byte sequence. If the sub-field count is 0, then nothing follows the 4-bytes field count (in this case, all 4 bytes have the value 0).

12641.4. Integer

126532-bit integer value, encoded as a sequence of 4 bytes, in big-endian order.

12661.5. String <tables id="TABLE-US-00112" num="112"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="5"><colspec colname="OFFSET" colwidth="21PT" align="left" /><colspec colname="1" colwidth="42PT" align="center" /><colspec colname="2" colwidth="70PT" align="center" /><colspec colname="3" colwidth="28PT" align="center" /><colspec colname="4" colwidth="56PT" align="center" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="4" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Byte Count</entry><entry>Byte 0</entry><entry>Byte 1</entry><entry>. . .</entry></row><row><entry /><entry namest="OFFSET" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

1267Strings are represented by a UTF-8 encoded byte sequence (not null-terminated). The canonical byte sequence for a string consists of (1) the byte count of the string, encoded as a sequence of 4 bytes in big-endian order, followed by (2) the sequence of bytes of the string. 1.6. Byte

12688-bit value

12691.7. Boolean

12708-bit value: 0 for false, and 1 for true

00002. Application to Octopus Objects

1271In one embodiment, the canonical byte sequence for an Octopus object is the concatenation of the canonical byte sequences of each of its fields, in the order they are defined in the object model.

1272For heterogeneous compound types, the order of the fields is the one specified in the type definition. For homogeneous compound types, the order of the elements is specified in the following paragraphs.

0000Attributes

1273An object's “attributes” field is treated as an unnamed attribute of type “list” (it is an unsorted container of named attributes). Named attributes contained in the value of attributes of type “list” are sorted lexicographically by their “name” field. Unnamed Attributes contained in the value attribute of type “array” are not sorted (they are serialized in their array order).

0000Extensions

1274An object's internal extensions are sorted lexicographically by their ‘id’ field. In one embodiment, for internal extensions, the ‘extensionData’ field is not used in the computation of the canonical byte sequence. For such extensions, if they need to be included in the computation of a digest for the purpose of a signature, they will contain a ‘digest’ field that will represent the digest of the actual data carried in the ‘extensionData’. For each type of extension data, a definition will be given that allows the computation of its canonical byte sequence.

0000Controller

1275ContentKey references are sorted lexicographically by their ‘id’ field.

00003. ScubaKeys

1276The keys in the ‘publicKeys’, ‘privateKeys’ and ‘secretKeys’ fields are sorted lexicographically by their ‘id’ field.

12774. Example <tables id="TABLE-US-00113" num="113"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="63PT" align="left" /><colspec colname="1" colwidth="154PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Class X {</entry></row><row><entry /><entry>  int i;</entry></row><row><entry /><entry>  int j;</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry>class A {</entry></row><row><entry /><entry>  int a[ ];</entry></row><row><entry /><entry>  string s;</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry>class B extends A {</entry></row><row><entry /><entry>  {X optional_x;}</entry></row><row><entry /><entry>  X x;</entry></row><row><entry /><entry>  (string toDiscardInCano;)</entry></row><row><entry /><entry>  string s2;</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

1278The canonical byte sequence of an instance of class B where a[] ={7,8,9}, s=“Abc”, x={5,4}, s<b>2</b>=″″, and optional_x is not present is serialized as: <tables id="TABLE-US-00114" num="114"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="9"><colspec colname="1" colwidth="21PT" align="center" /><colspec colname="2" colwidth="21PT" align="center" /><colspec colname="3" colwidth="21PT" align="center" /><colspec colname="4" colwidth="21PT" align="center" /><colspec colname="5" colwidth="21PT" align="center" /><colspec colname="6" colwidth="35PT" align="center" /><colspec colname="7" colwidth="21PT" align="center" /><colspec colname="8" colwidth="35PT" align="center" /><colspec colname="9" colwidth="21PT" align="center" /><thead><row><entry /></row><row><entry namest="1" nameend="9" align="center" rowsep="1" /></row><row><entry /><entry /><entry /><entry /><entry /><entry>“Abc” as</entry><entry /><entry /><entry /></row><row><entry>3</entry><entry>7</entry><entry>8</entry><entry>9</entry><entry>3</entry><entry>UTF-8</entry><entry>0</entry><entry>Cano(X)</entry><entry>0</entry></row><row><entry namest="1" nameend="9" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>4</entry><entry>4</entry><entry>4</entry><entry>4</entry><entry>4</entry><entry>3 bytes</entry><entry>1</entry><entry>8 bytes</entry><entry>4</entry></row><row><entry>bytes</entry><entry>bytes</entry><entry>bytes</entry><entry>bytes</entry><entry>bytes</entry><entry /><entry>byte</entry><entry /><entry>bytes</entry></row><row><entry namest="1" nameend="9" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

1279Where Cano(X) is: <tables id="TABLE-US-00115" num="115"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="49PT" align="left" /><colspec colname="1" colwidth="28PT" align="center" /><colspec colname="2" colwidth="140PT" align="center" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row><row><entry /><entry>5</entry><entry>4</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>4 bytes</entry><entry>4 bytes</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

Appendix E

1280An example of a control program is provided below. In this example, the license indicates that the play action can be granted if the membership state (provisioned during registration) or the license state (provisioned during a license transfer) can be found in the state database (referred to as the “Seashell” database in this example embodiment). The license also allows a peer to request a license transfer. This transfer will be granted if the two peers are in a given proximity. The license contains an agent that will set the license state on the peer.

1281In the code files that follow, “MovableDomainBoundLicense.asm” is the main control, “LicenseUtils/*” are helpers for the license, “GenericUtils/*” are generic helpers that perform functions such as computing the lengh of a string, comparing strings, manipulating the stack, and/or the like, and “ExtendedStatusBlockParameters/*” contains an XML description of an extended status block parameter and the corresponding representation as a series of bytes compiled from the XML.

1282E.1 MovableDomainBound.asm <tables id="TABLE-US-00116" num="116"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>;**********************************************************</entry></row><row><entry>;  File Name: MovableDomainBoundLicense.asm</entry></row><row><entry>;  Description: Example of a movable license</entry></row><row><entry>;**********************************************************;</entry></row><row><entry>; =========================</entry></row><row><entry>; constants</entry></row><row><entry>; =========================</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="161PT" align="left" /><colspec colname="2" colwidth="14PT" align="char" char="." /><colspec colname="3" colwidth="42PT" align="center" /><tbody valign="top"><row><entry>EBUG_PRINT_SYSCALL,</entry><entry>1</entry><entry /></row><row><entry>.equ FIND_SYSCALL_BY_NAME_SYSCALL,</entry><entry>2</entry></row><row><entry>.equ SYSTEM_HOST_GET_OBJECT_SYSCALL,</entry><entry>3</entry></row><row><entry>.equ SYSTEM_HOST_SET_OBJECT_SYSCALL,</entry><entry>4</entry></row><row><entry>.equ SUCCESS,</entry><entry>0</entry></row><row><entry>.equ FAILURE,</entry><entry>−1</entry></row><row><entry>.equ ERROR_NO_SUCH_ITEM,</entry><entry>−6</entry></row><row><entry>.equ CONTAINER_IGNORED_ADDRESS,</entry><entry>1</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="left" /><tbody valign="top"><row><entry>; =========================</entry></row><row><entry>; includes</entry></row><row><entry>; =========================</entry></row><row><entry>.include “StrCmp.asm”</entry></row><row><entry>.export Global.OnLoad</entry></row><row><entry>.export Control.Actions.Play.Check</entry></row><row><entry>.export Control.Actions.Play.Perform</entry></row><row><entry>.export Control.Actions.Transfer.Check</entry></row><row><entry>.export Control.Actions.Transfer.Perform</entry></row><row><entry>.export Control.Agents.SetStateContent0023.Run</entry></row><row><entry>.export Control.Agents.SetStateContent0023.OnAgentCompletion</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

1283E.2 LicenseUtils

1284E.2.1 LicenseStateUtils.asm <tables id="TABLE-US-00117" num="117"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>;**********************************************************</entry></row><row><entry>; File Name: LicenseStateUtils.asm</entry></row><row><entry>; Description: Utils for License States</entry></row><row><entry>;**********************************************************;</entry></row><row><entry>;=========================</entry></row><row><entry>; data</entry></row><row><entry>;=========================</entry></row><row><entry>.data</entry></row><row><entry>LicenseStatePathControlAttribute:</entry></row><row><entry>  .string “Octopus/Control/Attributes/LicenseStatePath”</entry></row><row><entry>LicenseStatePath:</entry></row><row><entry>  .zeros 256</entry></row><row><entry>LicenseStateValue:</entry></row><row><entry>  .long 0</entry></row><row><entry>; debug</entry></row><row><entry>LicenseStatePath.Query.Debug:</entry></row><row><entry> .string “--------- Entering LicenseStatePath.Query --------------\n”</entry></row><row><entry>LicenseStateValue.Query.Debug:</entry></row><row><entry> .string “--------- Entering LicenseStateValue.Query --------------\n”</entry></row><row><entry>LicenseState.Erase.Debug:</entry></row><row><entry> .string “--------- Entering LicenseState.Erase --------------\n”</entry></row><row><entry>LicenseState.Set.Debug:</entry></row><row><entry> .string “--------- Entering LicenseState.Set --------------\n”</entry></row><row><entry>;=========================</entry></row><row><entry>; code</entry></row><row><entry>;=========================</entry></row><row><entry>.code</entry></row><row><entry>;</entry></row><row><entry>; LicenseStatePath.Query</entry></row><row><entry>;</entry></row><row><entry>LicenseStatePath.Query:</entry></row><row><entry>  ;debug</entry></row><row><entry>  PUSH @LicenseStatePath.Query.Debug</entry></row><row><entry>  PUSH DEBUG_PRINT_SYSCALL</entry></row><row><entry>  CALL</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="140PT" align="left" /><colspec colname="2" colwidth="77PT" align="left" /><tbody valign="top"><row><entry>  PUSH 256</entry><entry>; ReturnBufferSize</entry></row><row><entry>  PUSH @LicenseStatePath</entry><entry>; ReturnBuffer</entry></row><row><entry>  PUSH @LicenseStatePathControlAttribute</entry><entry>; Name</entry></row><row><entry>  PUSH 0</entry><entry>; Parent = root container</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="left" /><tbody valign="top"><row><entry>  PUSH SYSTEM_HOST_GET_OBJECT_SYSCALL</entry></row><row><entry>  CALL</entry></row><row><entry>  RET</entry></row><row><entry>;</entry></row><row><entry>; LicenseStateValue.Query</entry></row><row><entry>;</entry></row><row><entry>LicenseStateValue.Query:</entry></row><row><entry>  ;debug</entry></row><row><entry>  PUSH @LicenseStateValue.Query.Debug</entry></row><row><entry>  PUSH DEBUG_PRINT_SYSCALL</entry></row><row><entry>  CALL</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="119PT" align="left" /><colspec colname="2" colwidth="98PT" align="left" /><tbody valign="top"><row><entry>  PUSH 4</entry><entry>; ReturnBufferSize (4 bytes)</entry></row><row><entry>  PUSH @LicenseStateValue</entry><entry>; ReturnBuffer (type is long)</entry></row><row><entry>  PUSH @LicenseStatePath</entry><entry>; Name</entry></row><row><entry>  PUSH 0</entry><entry>; Parent = root container</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="left" /><tbody valign="top"><row><entry>  PUSH SYSTEM_HOST_GET_OBJECT_SYSCALL</entry></row><row><entry>  CALL</entry></row><row><entry>  RET</entry></row><row><entry>;</entry></row><row><entry>; LicenseState.Erase</entry></row><row><entry>;</entry></row><row><entry>LicenseState.Erase:</entry></row><row><entry>  ;debug</entry></row><row><entry>  PUSH @LicenseState.Erase.Debug</entry></row><row><entry>  PUSH DEBUG_PRINT_SYSCALL</entry></row><row><entry>  CALL</entry></row><row><entry>  ; erase the local state</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="119PT" align="left" /><colspec colname="2" colwidth="98PT" align="left" /><tbody valign="top"><row><entry>  PUSH 0</entry><entry>; Object Size (container)</entry></row><row><entry>  PUSH 0</entry><entry>; Object Type (container)</entry></row><row><entry>  PUSH 0</entry><entry>; Delete the container</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="98PT" align="left" /><colspec colname="2" colwidth="119PT" align="left" /><tbody valign="top"><row><entry>  PUSH @LicenseStatePath</entry><entry>; Name</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="119PT" align="left" /><colspec colname="2" colwidth="98PT" align="left" /><tbody valign="top"><row><entry>  PUSH 0</entry><entry>; Parent = root container</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="left" /><tbody valign="top"><row><entry>  PUSH SYSTEM_HOST_SET_OBJECT_SYSCALL</entry></row><row><entry>  CALL</entry></row><row><entry>  RET</entry></row><row><entry>;</entry></row><row><entry>; LicenseState.Set</entry></row><row><entry>;</entry></row><row><entry>LicenseState.Set:</entry></row><row><entry>  ;debug</entry></row><row><entry>  PUSH @LicenseState.Set.Debug</entry></row><row><entry>  PUSH DEBUG_PRINT_SYSCALL</entry></row><row><entry>  CALL</entry></row><row><entry>; set the state</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="119PT" align="left" /><colspec colname="2" colwidth="98PT" align="left" /><tbody valign="top"><row><entry>  PUSH 0</entry><entry>; Object Size (container)</entry></row><row><entry>  PUSH 0</entry><entry>; Object Type (container)</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="left" /><tbody valign="top"><row><entry>  PUSH CONTAINER_IGNORED_ADDRESS</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="98PT" align="left" /><colspec colname="2" colwidth="119PT" align="left" /><tbody valign="top"><row><entry>  PUSH @LicenseStatePath</entry><entry>; Name</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="119PT" align="left" /><colspec colname="2" colwidth="98PT" align="left" /><tbody valign="top"><row><entry>  PUSH 0</entry><entry>; Parent = root container</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="left" /><tbody valign="top"><row><entry>  PUSH SYSTEM_HOST_SET_OBJECT_SYSCALL</entry></row><row><entry>  CALL</entry></row><row><entry>  RET</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

1285E.2.2 MembershipUtils.asm <tables id="TABLE-US-00118" num="118"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>;**********************************************************</entry></row><row><entry>;  File Name: MembershipUtils.asm</entry></row><row><entry>;  Description: Utils for Broadcast Membership</entry></row><row><entry>;</entry></row><row><entry>;**********************************************************;</entry></row><row><entry>;=========================</entry></row><row><entry>; data</entry></row><row><entry>;=========================</entry></row><row><entry>.data</entry></row><row><entry>MembershipStatePathControlAttribute:</entry></row><row><entry>  .string “Octopus/Control/Attributes/MembershipStatePath”</entry></row><row><entry>MembershipStatePath:</entry></row><row><entry>  .zeros 256</entry></row><row><entry>MembershipStateValue:</entry></row><row><entry>  .long 0</entry></row><row><entry>; debug</entry></row><row><entry>intStrOutput:</entry></row><row><entry>  .string “.............”</entry></row><row><entry>MembershipStatePath.Query.Debug:</entry></row><row><entry> .string “--------- Entering MembershipStatePath.Query -----------\n”</entry></row><row><entry>MembershipStateValue.Query.Debug:</entry></row><row><entry>  .string “--------- Entering MembershipStateValue.Query ---------\n”</entry></row><row><entry>Membership.Check.Debug:</entry></row><row><entry>  .string “--------- Entering Membership.Check --------------\n”</entry></row><row><entry>Membership_Check_Success.Debug:</entry></row><row><entry>  .string “####### Membership Check Success #######\n”</entry></row><row><entry>Membership_Check_Failure.Debug:</entry></row><row><entry>  .string “####### Membership Check Failure #######\n”</entry></row><row><entry>MembershipPath.Debug:</entry></row><row><entry>  .string “MembershipState path: ”</entry></row><row><entry>MembershipGetObjOutput.Debug:</entry></row><row><entry>  .string “MembershipState get object returns: ”</entry></row><row><entry>Membership_Expired.Debug:</entry></row><row><entry>  .string “MembershipState has expired. Check the Value of the</entry></row><row><entry>      Membership SeaShell token against the local time.”</entry></row><row><entry>NewlineString:</entry></row><row><entry>  string “\n”</entry></row><row><entry>;=========================</entry></row><row><entry>; code</entry></row><row><entry>;=========================</entry></row><row><entry>.code</entry></row><row><entry>;</entry></row><row><entry>; MembershipStatePath.Query</entry></row><row><entry>;</entry></row><row><entry>MembershipStatePath.Query:</entry></row><row><entry>  ;debug</entry></row><row><entry>  PUSH @MembershipStatePath.Query.Debug</entry></row><row><entry>  PUSH DEBUG_PRINT_SYSCALL</entry></row><row><entry>  CALL</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="140PT" align="left" /><colspec colname="2" colwidth="77PT" align="left" /><tbody valign="top"><row><entry>  PUSH 256</entry><entry>; ReturnBufferSize</entry></row><row><entry>  PUSH @MembershipStatePath</entry><entry>; ReturnBuffer</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="left" /><tbody valign="top"><row><entry>  PUSH @MembershipStatePathControlAttribute ; Name</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="140PT" align="left" /><colspec colname="2" colwidth="77PT" align="left" /><tbody valign="top"><row><entry>  PUSH 0</entry><entry>; Parent = root container</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="left" /><tbody valign="top"><row><entry>  PUSH SYSTEM_HOST_GET_OBJECT_SYSCALL</entry></row><row><entry>  CALL</entry></row><row><entry>  RET</entry></row><row><entry>;</entry></row><row><entry>; MembershipStateValue.Query</entry></row><row><entry>;</entry></row><row><entry>MembershipStateValue.Query:</entry></row><row><entry>  ;debug</entry></row><row><entry>  PUSH @MembershipStateValue.Query.Debug</entry></row><row><entry>  PUSH DEBUG_PRINT_SYSCALL</entry></row><row><entry>  CALL</entry></row><row><entry>  PUSH @MembershipPath.Debug</entry></row><row><entry>  PUSH DEBUG_PRINT_SYSCALL</entry></row><row><entry>  CALL</entry></row><row><entry>  PUSH @MembershipStatePath</entry></row><row><entry>  PUSH DEBUG_PRINT_SYSCALL</entry></row><row><entry>  CALL</entry></row><row><entry>  PUSH @NewlineString</entry></row><row><entry>  PUSH DEBUG_PRINT_SYSCALL</entry></row><row><entry>  CALL</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="119PT" align="left" /><colspec colname="2" colwidth="98PT" align="left" /><tbody valign="top"><row><entry>  PUSH 4</entry><entry>; ReturnBufferSize (4 bytes)</entry></row><row><entry>  PUSH @MembershipStateValue</entry><entry>; ReturnBuffer (type is long)</entry></row><row><entry>  PUSH @MembershipStatePath</entry><entry>; Name</entry></row><row><entry>  PUSH 0</entry><entry>; Parent = root container</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="left" /><tbody valign="top"><row><entry>  PUSH SYSTEM_HOST_GET_OBJECT_SYSCALL</entry></row><row><entry>  CALL</entry></row><row><entry>  PUSH @MembershipGetObjOutput.Debug</entry></row><row><entry>  PUSH DEBUG_PRINT_SYSCALL</entry></row><row><entry>  CALL</entry></row><row><entry>  ; print result -- first convert int to string</entry></row><row><entry>  DUP</entry></row><row><entry>  PUSH @intStrOutput</entry></row><row><entry>  ADD</entry></row><row><entry>  SWAP</entry></row><row><entry>  JSR printInt</entry></row><row><entry>  ; call print result</entry></row><row><entry>  PUSH @intStrOutput</entry></row><row><entry>  PUSH DEBUG_PRINT_SYSCALL</entry></row><row><entry>  CALL</entry></row><row><entry>  PUSH @NewlineString</entry></row><row><entry>  PUSH DEBUG_PRINT_SYSCALL</entry></row><row><entry>  CALL</entry></row><row><entry>  RET</entry></row><row><entry>;</entry></row><row><entry>; Membership.Check</entry></row><row><entry>;</entry></row><row><entry>Membership.Check:</entry></row><row><entry>  ;debug</entry></row><row><entry>  PUSH @Membership.Check.Debug</entry></row><row><entry>  PUSH DEBUG_PRINT_SYSCALL</entry></row><row><entry>  CALL</entry></row><row><entry>  ; query the membership state</entry></row><row><entry>  JSR MembershipStateValue.Query</entry></row><row><entry>  ; see if we succeeded</entry></row><row><entry>  BRN Membership_Check_Failed</entry></row><row><entry>  ; check that time is &lt; the one retrieved in the membership state</entry></row><row><entry>  PUSH @MembershipStateValue ; timestamp</entry></row><row><entry>  PEEK</entry></row><row><entry>  PUSH @GetTrustedTimeFunctionNumber</entry></row><row><entry>  PEEK</entry></row><row><entry>  CALL</entry></row><row><entry>  SWAP</entry></row><row><entry>  DROP ; we just need the value (not the estimate)</entry></row><row><entry>  SUB</entry></row><row><entry>  BRN Membership_Expired</entry></row><row><entry>  ; success</entry></row><row><entry>  ;debug</entry></row><row><entry>  PUSH @Membership_Check_Success.Debug</entry></row><row><entry>  PUSH DEBUG_PRINT_SYSCALL</entry></row><row><entry>  CALL</entry></row><row><entry>  PUSH SUCCESS</entry></row><row><entry>  RET</entry></row><row><entry>Membership_Expired:</entry></row><row><entry>  ;debug</entry></row><row><entry>  PUSH @Membership_Expired.Debug</entry></row><row><entry>  PUSH DEBUG_PRINT_SYSCALL</entry></row><row><entry>  CALL</entry></row><row><entry>  BRA Membership_Check_Failed</entry></row><row><entry>Membership_Check_Failed:</entry></row><row><entry>  ;debug</entry></row><row><entry>  PUSH @Membership_Check_Failure.Debug</entry></row><row><entry>  PUSH DEBUG_PRINT_SYSCALL</entry></row><row><entry>  CALL</entry></row><row><entry>  PUSH FAILURE</entry></row><row><entry>  RET</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

1286E.3 GlobalUtils

1287E.3.1 IntUtils.asm <tables id="TABLE-US-00119" num="119"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>;**********************************************************</entry></row><row><entry>;  File Name: IntUtils.asm</entry></row><row><entry>;  Description: utils for comparing 2 ints</entry></row><row><entry>;**********************************************************</entry></row><row><entry>;=========================</entry></row><row><entry>; includes</entry></row><row><entry>;=========================</entry></row><row><entry>.include “StackUtils.asm”</entry></row><row><entry>;=========================</entry></row><row><entry>; code</entry></row><row><entry>;=========================</entry></row><row><entry>.code</entry></row><row><entry>;</entry></row><row><entry>; min</entry></row><row><entry>;</entry></row><row><entry>; computes the min between 2 ints</entry></row><row><entry>;</entry></row><row><entry>; input: . . . a b</entry></row><row><entry>; output: . . . a<b?a:b</entry></row><row><entry>;</entry></row><row><entry>min:</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="63PT" align="left" /><colspec colname="2" colwidth="140PT" align="left" /><tbody valign="top"><row><entry /><entry>DUP</entry><entry>; . . . a b b</entry></row><row><entry /><entry>PUSH 2</entry></row><row><entry /><entry>JSR pick</entry><entry>; . . . a b b a</entry></row><row><entry /><entry>CMP</entry><entry>; . . . a b cmp_result</entry></row><row><entry /><entry>BRN Swap_Stack</entry><entry>; . . . a b</entry></row><row><entry /><entry>DROP</entry></row><row><entry /><entry>RET</entry><entry>; a</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="left" /><tbody valign="top"><row><entry>Swap_Stack:</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="63PT" align="left" /><colspec colname="2" colwidth="140PT" align="left" /><tbody valign="top"><row><entry /><entry>SWAP</entry><entry /></row><row><entry /><entry>DROP</entry></row><row><entry /><entry>RET</entry><entry>; b</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="left" /><tbody valign="top"><row><entry>;</entry></row><row><entry>; max</entry></row><row><entry>;</entry></row><row><entry>; computes the max between 2 ints</entry></row><row><entry>;</entry></row><row><entry>; input: . . . a b</entry></row><row><entry>; output: . . . a>b?a:b</entry></row><row><entry>;</entry></row><row><entry>max:</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="63PT" align="left" /><colspec colname="2" colwidth="140PT" align="left" /><tbody valign="top"><row><entry /><entry>DUP</entry><entry>; . . . a b b</entry></row><row><entry /><entry>PUSH 2</entry></row><row><entry /><entry>JSR pick</entry><entry>; . . . a b b a</entry></row><row><entry /><entry>CMP</entry><entry>; . . . a b cmp_result</entry></row><row><entry /><entry>NEG</entry></row><row><entry /><entry>BRN Swap_Stack</entry></row><row><entry /><entry>DROP</entry></row><row><entry /><entry>RET</entry><entry>; a</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

1288<tables id="TABLE-US-00120" num="120"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>;**********************************************************</entry></row><row><entry>;   File Name: PrintInt.asm</entry></row><row><entry>;   Description: converts an integer (signed or unsigned) into a</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="49PT" align="left" /><colspec colname="2" colwidth="168PT" align="left" /><tbody valign="top"><row><entry /><entry>string</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="left" /><tbody valign="top"><row><entry>;**********************************************************</entry></row><row><entry>;; NOTE: requires “StackUtils.asm” to have been included already</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="49PT" align="left" /><colspec colname="2" colwidth="168PT" align="left" /><tbody valign="top"><row><entry>; data section</entry><entry /></row><row><entry /><entry>.data</entry></row><row><entry>; code section</entry></row><row><entry /><entry>.code</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="left" /><tbody valign="top"><row><entry>; converts an integer into string representation</entry></row><row><entry>; params: dest, int</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="49PT" align="left" /><colspec colname="2" colwidth="168PT" align="left" /><tbody valign="top"><row><entry>printInt:</entry><entry /></row><row><entry /><entry>; duplicate dest param</entry></row><row><entry /><entry>SWAP</entry></row><row><entry /><entry>DUP</entry></row><row><entry /><entry>PUSH 2</entry></row><row><entry /><entry>JSR pick</entry></row><row><entry /><entry>; STACK: origval, startstring, startstring,</entry></row><row><entry /><entry>unsignedval</entry></row><row><entry /><entry>; now, we end up with an extra copy of int at bottom</entry></row><row><entry /><entry>; we use this to test original sign later</entry></row><row><entry>printIntLoop:</entry></row><row><entry /><entry>; get the single digit</entry></row><row><entry /><entry>DUP</entry></row><row><entry /><entry>PUSH 10</entry></row><row><entry /><entry>MOD</entry></row><row><entry /><entry>; convert to ascii</entry></row><row><entry /><entry>PUSH 48 ; ASCII for ‘0’</entry></row><row><entry /><entry>ADD</entry></row><row><entry /><entry>; get the address for the output buffer</entry></row><row><entry /><entry>PUSH 2</entry></row><row><entry /><entry>JSR pick</entry></row><row><entry /><entry>POKEB ; print to the buffer</entry></row><row><entry /><entry>; move our buffer pointer along</entry></row><row><entry /><entry>SWAP</entry></row><row><entry /><entry>PUSH 1</entry></row><row><entry /><entry>ADD</entry></row><row><entry /><entry>SWAP</entry></row><row><entry /><entry>; divide by 10 and see where we're at</entry></row><row><entry /><entry>PUSH 10</entry></row><row><entry /><entry>DIV</entry></row><row><entry /><entry>DUP</entry></row><row><entry /><entry>BRP printIntLoop</entry></row><row><entry /><entry>DROP ; gets rid of the 0 at the top</entry></row><row><entry /><entry>; STACK = orignum, startofstring, endofstring</entry></row><row><entry /><entry>; if original number was negative, put a minus sign</entry></row><row><entry /><entry>; terminate with a null</entry></row><row><entry /><entry>DUP</entry></row><row><entry /><entry>PUSH 0</entry></row><row><entry /><entry>SWAP</entry></row><row><entry /><entry>POKEB</entry></row><row><entry /><entry>; move end of string up 1, so don't flip terminator</entry></row><row><entry /><entry>PUSH 1</entry></row><row><entry /><entry>SUB</entry></row><row><entry /><entry>; we're done: just need to reverse string</entry></row><row><entry>fliploop:</entry></row><row><entry /><entry>; get second byte</entry></row><row><entry /><entry>DUP</entry></row><row><entry /><entry>PEEKB</entry></row><row><entry /><entry>; get first byte</entry></row><row><entry /><entry>PUSH 2</entry></row><row><entry /><entry>JSR pick</entry></row><row><entry /><entry>PEEKB</entry></row><row><entry /><entry>; put first byte in last place</entry></row><row><entry /><entry>PUSH 2</entry></row><row><entry /><entry>JSR pick</entry></row><row><entry /><entry>POKEB</entry></row><row><entry /><entry>; put last byte in first place</entry></row><row><entry /><entry>PUSH 2</entry></row><row><entry /><entry>JSR pick</entry></row><row><entry /><entry>POKEB</entry></row><row><entry /><entry>; move the end pointer up one</entry></row><row><entry /><entry>PUSH 1</entry></row><row><entry /><entry>SUB</entry></row><row><entry /><entry>; move the start pointer down one</entry></row><row><entry /><entry>SWAP</entry></row><row><entry /><entry>PUSH 1</entry></row><row><entry /><entry>ADD</entry></row><row><entry /><entry>SWAP</entry></row><row><entry /><entry>; see if the pointers have met</entry></row><row><entry /><entry>; must dup the values first</entry></row><row><entry /><entry>DUP</entry></row><row><entry /><entry>PUSH 2</entry></row><row><entry /><entry>JSR pick</entry></row><row><entry /><entry>SUB</entry></row><row><entry /><entry>BRP fliploop</entry></row><row><entry /><entry>; get rid of some detritus on the stack</entry></row><row><entry /><entry>DROP</entry></row><row><entry /><entry>DROP</entry></row><row><entry /><entry>DROP</entry></row><row><entry /><entry>RET</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

1289E.3.3 StackUtils.asm <tables id="TABLE-US-00121" num="121"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>;**********************************************************</entry></row><row><entry>;  File Name: StackUtils.asm</entry></row><row><entry>;  Description: Stack utils functions inspired from FORTH</entry></row><row><entry>;</entry></row><row><entry>;**********************************************************</entry></row><row><entry>.ifndef _STACK_UTILS_—</entry></row><row><entry>.define _STACK_UTILS_—</entry></row><row><entry>;=========================</entry></row><row><entry>; code</entry></row><row><entry>;=========================</entry></row><row><entry>.code</entry></row><row><entry>;</entry></row><row><entry>; over</entry></row><row><entry>;</entry></row><row><entry>; copy the second item on the stack</entry></row><row><entry>;</entry></row><row><entry>; input: ... a b</entry></row><row><entry>; output: ... a b a</entry></row><row><entry>;</entry></row><row><entry>over:</entry></row><row><entry>      PUSH 1</entry></row><row><entry>      JSR pick</entry></row><row><entry>      RET</entry></row><row><entry>;</entry></row><row><entry>; pick</entry></row><row><entry>;</entry></row><row><entry>; input: ... v3 v2 v1 v0 N</entry></row><row><entry>; output: ... v3 v2 v1 v0 vN</entry></row><row><entry>;</entry></row><row><entry>pick:</entry></row><row><entry>      PUSH 1</entry></row><row><entry>      ADD</entry></row><row><entry>      PUSH 4</entry></row><row><entry>      MUL</entry></row><row><entry>      PUSHSP</entry></row><row><entry>      ADD</entry></row><row><entry>      PEEK</entry></row><row><entry>      RET</entry></row><row><entry>.endif ; _STACK_UTILS_—</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

1290E.3.4 StdLib.asm <tables id="TABLE-US-00122" num="122"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="49PT" align="left" /><colspec colname="1" colwidth="168PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>; Standard Library for Plankton</entry></row><row><entry /><entry>      .equ HEAP_ADDR, 16</entry></row><row><entry /><entry>; data section</entry></row><row><entry /><entry>; code section</entry></row><row><entry /><entry>      .code</entry></row><row><entry /><entry>strlen:</entry></row><row><entry /><entry>      DUP</entry></row><row><entry /><entry>loop:</entry></row><row><entry /><entry>      DUP</entry></row><row><entry /><entry>      PEEKB</entry></row><row><entry /><entry>      BRZ done</entry></row><row><entry /><entry>      PUSH 1</entry></row><row><entry /><entry>      ADD</entry></row><row><entry /><entry>      BRA loop</entry></row><row><entry /><entry>done:</entry></row><row><entry /><entry>      SWAP</entry></row><row><entry /><entry>      SUB</entry></row><row><entry /><entry>      RET</entry></row><row><entry /><entry>      .export strlen</entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

1291E.3.5 StrCmp.asm <tables id="TABLE-US-00123" num="123"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>;**********************************************************</entry></row><row><entry>;  File Name: StrCmp.asm</entry></row><row><entry>;  Description: streq tests for the equality of two strings</entry></row><row><entry>;**********************************************************</entry></row><row><entry>.ifndef _STR_CMP_—</entry></row><row><entry>.define _STR_CMP_—</entry></row><row><entry>;=========================</entry></row><row><entry>; includes</entry></row><row><entry>;=========================</entry></row><row><entry>.include “StackUtils.asm”</entry></row><row><entry>;=========================</entry></row><row><entry>; code</entry></row><row><entry>;=========================</entry></row><row><entry>.code</entry></row><row><entry>;</entry></row><row><entry>; streq</entry></row><row><entry>;</entry></row><row><entry>; test for the equality of two strings</entry></row><row><entry>;</entry></row><row><entry>; input: ... @str1 @str2</entry></row><row><entry>; output: ... res (res = 0 if strings are equal, −1 otherwise)</entry></row><row><entry>;</entry></row><row><entry>streq:</entry></row><row><entry>    ; get the offset btw the 2 strings</entry></row><row><entry>    JSR over</entry></row><row><entry>    SUB</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="70PT" align="left" /><colspec colname="2" colwidth="147PT" align="left" /><tbody valign="top"><row><entry>    SWAP</entry><entry>; ... offset @str1</entry></row><row><entry>streqloop:</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="left" /><tbody valign="top"><row><entry>    ; get the cur char of str1</entry></row><row><entry>    DUP</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="70PT" align="left" /><colspec colname="2" colwidth="147PT" align="left" /><tbody valign="top"><row><entry>    PEEKB</entry><entry>; ... offset @str1 char1</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="left" /><tbody valign="top"><row><entry>    ; get the cur char of str2</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="70PT" align="left" /><colspec colname="2" colwidth="147PT" align="left" /><tbody valign="top"><row><entry>    JSR over</entry><entry>; ... offset @str1 char1 @str1</entry></row><row><entry>    PUSH 3</entry></row><row><entry>    JSR pick</entry><entry>; ... offset @str1 char1 @str1 offset</entry></row><row><entry>    ADD</entry></row><row><entry>    PEEKB</entry><entry>; ... offset @str1 char1 char2</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="left" /><tbody valign="top"><row><entry>    ; now compare the two chars</entry></row><row><entry>    JSR over</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="70PT" align="left" /><colspec colname="2" colwidth="147PT" align="left" /><tbody valign="top"><row><entry>    SUB</entry><entry>; ... offset @str1 char1 char1-char2</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="left" /><tbody valign="top"><row><entry>    ; fail if the char1 != char2</entry></row><row><entry>    NOT</entry></row><row><entry>    BRZ streqfailure</entry></row><row><entry>    ; if char1 is 0 (char1 == char2 == 0) we're done</entry></row><row><entry>    BRZ streqsuccess   ; ... offset @str1</entry></row><row><entry>    ; increment the @str1 pointer and loop</entry></row><row><entry>    PUSH 1</entry></row><row><entry>    ADD</entry></row><row><entry>    BRA streqloop</entry></row><row><entry>streqfailure:</entry></row><row><entry>    ; ... offset @str1 char1</entry></row><row><entry>    DROP</entry></row><row><entry>    DROP</entry></row><row><entry>    DROP</entry></row><row><entry>    PUSH −1</entry></row><row><entry>    RET</entry></row><row><entry>streqsuccess:</entry></row><row><entry>    ; ... offset @str1</entry></row><row><entry>    DROP</entry></row><row><entry>    DROP</entry></row><row><entry>    PUSH 0</entry></row><row><entry>    RET</entry></row><row><entry>.endif ; _STR_CMP_—</entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

1292E.4 ExtendedStatusBlock Parameters

1293E.4.1 TransferXStatusProximityCheckSucceeded.xml <tables id="TABLE-US-00124" num="124"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="308PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry><u style="single">-</u> <ValueListBlock></entry></row><row><entry> <u style="single">-</u> <ValueBlock type=“Parameter”></entry></row><row><entry>  <u style="single">-</u> <ParameterBlock name=“Obligations”></entry></row><row><entry>   <u style="single">-</u> <ValueBlock type=“ValueList”></entry></row><row><entry>    <u style="single">-</u> <ValueListBlock></entry></row><row><entry>     <u style="single">-</u> <ValueBlock type=“ExtendedParameter”></entry></row><row><entry>      <u style="single">-</u> <ParameterBlock name=“RunAgentOnPeer” flags=“1”></entry></row><row><entry>       <u style="single">-</u> <ValueBlock type=“ValueList”></entry></row><row><entry>        <u style="single">-</u> <ValueListBlock></entry></row><row><entry>         - <!-- Control ID --></entry></row><row><entry>          <ValueBlock type=“String”>urn:marlin:control:0023</ValueBlock></entry></row><row><entry>        - <!-- Agent Name --></entry></row><row><entry>         <ValueBlock type=“String”>SetStateContent0023</ValueBlock></entry></row><row><entry>        - <!-- instance ID --></entry></row><row><entry>        <ValueBlock type=“Integer”>240343</ValueBlock></entry></row><row><entry>      - <!-- Context ID --></entry></row><row><entry>        <ValueBlock type=“String”>MoveStateContent0023</ValueBlock></entry></row><row><entry>      - <!-- additional parameters --></entry></row><row><entry>      <u style="single">-</u> <ValueBlock type=“ValueList”></entry></row><row><entry>       <u style="single">-</u> <ValueListBlock></entry></row><row><entry>        <u style="single">-</u> <ValueBlock type=“Parameter”></entry></row><row><entry>         - <!-- The ONLY thing that changes with</entry></row><row><entry>             TransferXStatusProximityCheckFailed.xml --></entry></row><row><entry>          <u style="single">-</u> <ParameterBlock name=“ProximityChecked”></entry></row><row><entry>           <ValueBlock type=“Integer”>1</ValueBlock></entry></row><row><entry>          </ParameterBlock></entry></row><row><entry>         </ValueBlock></entry></row><row><entry>        </ValueListBlock></entry></row><row><entry>       </ValueBlock></entry></row><row><entry>      </ValueListBlock></entry></row><row><entry>      </ValueBlock></entry></row><row><entry>     </ParameterBlock></entry></row><row><entry>     </ValueBlock></entry></row><row><entry>    </ValueListBlock></entry></row><row><entry>   </ValueBlock></entry></row><row><entry>  </ParameterBlock></entry></row><row><entry> </ValueBlock></entry></row><row><entry><u style="single">-</u> <ValueBlock type=“Parameter”></entry></row><row><entry> <u style="single">-</u> <ParameterBlock name=“Callbacks”></entry></row><row><entry>  <u style="single">-</u> <ValueBlock type=“ValueList”></entry></row><row><entry>   <u style="single">-</u> <ValueListBlock></entry></row><row><entry>    <u style="single">-</u> <ValueBlock type=“ExtendedParameter”></entry></row><row><entry>     <u style="single">-</u> <ParameterBlock name=“OnAgentCompletion” flags=“1”></entry></row><row><entry>      <u style="single">-</u> <ValueBlock type=“ValueList”></entry></row><row><entry>       <u style="single">-</u> <ValueListBlock></entry></row><row><entry>       - <!--  Agent instance ID  --></entry></row><row><entry>        <ValueBlock type=“String”>240343</ValueBlock></entry></row><row><entry>        - <!-- Callback Routine --></entry></row><row><entry>        <u style="single">-</u> <ValueBlock type=“ValueList”></entry></row><row><entry>        <u style="single">-</u> <ValueListBlock></entry></row><row><entry>        - <!-- RESET --></entry></row><row><entry>         <ValueBlock type=“Integer”>0</ValueBlock></entry></row><row><entry>        - <!-- Name --></entry></row><row><entry>         <ValueBlock</entry></row><row><entry>       type=“String”>Control.Agents.SetStateContent0023.OnAgentCompletion</ValueBlock></entry></row><row><entry>       - <!-- cookie --></entry></row><row><entry>         <ValueBlock type=“Integer”>0</ValueBlock></entry></row><row><entry>        </ValueListBlock></entry></row><row><entry>       </ValueBlock></entry></row><row><entry>      </ValueListBlock></entry></row><row><entry>      </ValueBlock></entry></row><row><entry>     </ParameterBlock></entry></row><row><entry>     </ValueBlock></entry></row><row><entry>    </ValueListBlock></entry></row><row><entry>   </ValueBlock></entry></row><row><entry>  </ParameterBlock></entry></row><row><entry> </ValueBlock></entry></row><row><entry></ValueListBlock></entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

1294E.4.2 TransferXStatusProximityCheckFailed.xml <tables id="TABLE-US-00125" num="125"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="364PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry><u style="single">-</u> <ValueListBlock></entry></row><row><entry> <u style="single">-</u> <ValueBlock type=“Parameter”></entry></row><row><entry>  <u style="single">-</u> <ParameterBlock name=“Obligations”></entry></row><row><entry>     <u style="single">-</u> <ValueBlock type=“ValueList”></entry></row><row><entry>      <u style="single">-</u> <ValueListBlock></entry></row><row><entry>       <u style="single">-</u> <ValueBlock type=“ExtendedParameter”></entry></row><row><entry>        <u style="single">-</u> <ParameterBlock name=“RunAgentOnPeer” flags=“1”></entry></row><row><entry>         <u style="single">-</u> <ValueBlock type=“ValueList”></entry></row><row><entry>         <u style="single">-</u> <ValueListBlock></entry></row><row><entry>          - <!-- Control ID --></entry></row><row><entry>             <ValueBlock type=“String”>urn:marlin:control:0023</ValueBlock></entry></row><row><entry>            - <!--  Agent Name --></entry></row><row><entry>             <ValueBlock type=“String”>SetStateContent0023</ValueBlock></entry></row><row><entry>            - <! -- instance ID  --></entry></row><row><entry>             <ValueBlock type=“Integer”>240343</ValueBlock></entry></row><row><entry>            - <!--  Context ID  --></entry></row><row><entry>             <ValueBlock type=“String”>MoveStateContent0023</ValueBlock></entry></row><row><entry>            - <!--  additional parameters  --></entry></row><row><entry>            <u style="single">-</u> <ValueBlock type=“ValueList”></entry></row><row><entry>              <u style="single">-</u> <ValueListBlock></entry></row><row><entry>               <u style="single">-</u> <ValueBlock type=“Parameter”></entry></row><row><entry>             - <!-- The ONLY thing that changes with TransferXStatusProximityCheckSucceed.xml --></entry></row><row><entry>               <u style="single">-</u> <ParameterBlock name=“ProximityChecked”></entry></row><row><entry>                  <ValueBlock type=“Integer”>0</ValueBlock></entry></row><row><entry>                </ParameterBlock></entry></row><row><entry>               </ValueBlock></entry></row><row><entry>              </ValueListBlock></entry></row><row><entry>             </ValueBlock></entry></row><row><entry>            </ValueListBlock></entry></row><row><entry>            </ValueBlock></entry></row><row><entry>           </ParameterBlock></entry></row><row><entry>          </ValueBlock></entry></row><row><entry>         </ValueListBlock></entry></row><row><entry>        </ValueBlock></entry></row><row><entry>       </ParameterBlock></entry></row><row><entry>      </ValueBlock></entry></row><row><entry><u style="single">-</u> <ValueBlock type=“Parameter”></entry></row><row><entry> <u style="single">-</u> <ParameterBlock name=“Callbacks”></entry></row><row><entry>  <u style="single">-</u> <ValueBlock type=“ValueList”></entry></row><row><entry>   <u style="single">-</u> <ValueListBlock></entry></row><row><entry>    <u style="single">-</u> <ValueBlock type=“ExtendedParameter”></entry></row><row><entry>     <u style="single">-</u> <ParameterBlock name=“OnAgentCompletion” flags=“1”></entry></row><row><entry>      <u style="single">-</u> <ValueBlock type=“ValueList”></entry></row><row><entry>       <u style="single">-</u> <ValueListBlock></entry></row><row><entry>          - <!--  Agent instance ID  --></entry></row><row><entry>        <ValueBlock type=“String”>240343</ValueBlock></entry></row><row><entry>          - <!--  Callback Routine  --></entry></row><row><entry>         <u style="single">-</u> <ValueBlock type=“ValueList”></entry></row><row><entry>          <u style="single">-</u> <ValueListBlock></entry></row><row><entry>          - <!--  RESET  --></entry></row><row><entry>          <ValueBlock type=“Integer”>0</ValueBlock></entry></row><row><entry>         - <!--  Name  --></entry></row><row><entry>     <ValueBlock type=“String”>Control.Agents.SetStateContent0023.OnAgentCompletion</ValueBlock></entry></row><row><entry>         - <!--  cookie  --></entry></row><row><entry>        <ValueBlock type=“Integer”>0</ValueBlock></entry></row><row><entry>        </ValueListBlock></entry></row><row><entry>        </ValueBlock></entry></row><row><entry>       </ValueListBlock></entry></row><row><entry>       </ValueBlock></entry></row><row><entry>      </ParameterBlock></entry></row><row><entry>      </ValueBlock></entry></row><row><entry>     </ValueListBlock></entry></row><row><entry>     </ValueBlock></entry></row><row><entry>    </ParameterBlock></entry></row><row><entry>    </ValueBlock></entry></row><row><entry>   </ValueListBlock></entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

1295E.4.3 TransferXStatusProximityCheckSucceeded.asm <tables id="TABLE-US-00126" num="126"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="12"><colspec colname="1" colwidth="21PT" align="left" /><colspec colname="2" colwidth="21PT" align="left" /><colspec colname="3" colwidth="21PT" align="left" /><colspec colname="4" colwidth="21PT" align="left" /><colspec colname="5" colwidth="21PT" align="left" /><colspec colname="6" colwidth="21PT" align="left" /><colspec colname="7" colwidth="21PT" align="left" /><colspec colname="8" colwidth="21PT" align="left" /><colspec colname="9" colwidth="21PT" align="left" /><colspec colname="10" colwidth="28PT" align="left" /><colspec colname="11" colwidth="21PT" align="left" /><colspec colname="12" colwidth="21PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="12" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x02</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x04</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x20</entry></row><row><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x0C</entry><entry>0x4F</entry><entry>0x62</entry><entry>0x6C</entry><entry>0x69</entry><entry>0x67</entry><entry>0x61</entry><entry>0x74</entry><entry>0x69</entry></row><row><entry>0x6F</entry><entry>0x6E</entry><entry>0x73</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x07</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x0C</entry></row><row><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x01</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x05</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x04</entry></row><row><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x01</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x0F</entry><entry>0x52</entry><entry>0x75</entry><entry>0x6E</entry><entry>0x41</entry></row><row><entry>0x67</entry><entry>0x65</entry><entry>0x6E</entry><entry>0x74</entry><entry>0x4F</entry><entry>0x6E</entry><entry>0x50</entry><entry>0x65</entry><entry>0x65</entry><entry>0x72</entry><entry>0x00</entry><entry>0x00</entry></row><row><entry>0x00</entry><entry>0x00</entry><entry>0x07</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x92</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x05</entry><entry>0x00</entry></row><row><entry>0x00</entry><entry>0x00</entry><entry>0x02</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x18</entry><entry>0x75</entry><entry>0x72</entry><entry>0x6E</entry><entry>0x3A</entry><entry>0x6D</entry></row><row><entry>0x61</entry><entry>0x72</entry><entry>0x6C</entry><entry>0x69</entry><entry>0x6E</entry><entry>0x3A</entry><entry>0x63</entry><entry>0x6F</entry><entry>0x6E</entry><entry>0x74</entry><entry>0x72</entry><entry>0x6F</entry></row><row><entry>0x6C</entry><entry>0x3A</entry><entry>0x30</entry><entry>0x30</entry><entry>0x32</entry><entry>0x33</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x02</entry><entry>0x00</entry></row><row><entry>0x00</entry><entry>0x00</entry><entry>0x14</entry><entry>0x53</entry><entry>0x65</entry><entry>0x74</entry><entry>0x53</entry><entry>0x74</entry><entry>0x61</entry><entry>0x74</entry><entry>0x65</entry><entry>0x43</entry></row><row><entry>0x6F</entry><entry>0x6E</entry><entry>0x74</entry><entry>0x65</entry><entry>0x6E</entry><entry>0x74</entry><entry>0x30</entry><entry>0x30</entry><entry>0x32</entry><entry>0x33</entry><entry>0x00</entry><entry>0x00</entry></row><row><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x04</entry><entry>0x00</entry><entry>0x03</entry><entry>0xAA</entry><entry>0xD7</entry><entry>0x00</entry></row><row><entry>0x00</entry><entry>0x00</entry><entry>0x02</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x15</entry><entry>0x4D</entry><entry>0x6F</entry><entry>0x76</entry><entry>0x65</entry><entry>0x53</entry></row><row><entry>0x74</entry><entry>0x61</entry><entry>0x74</entry><entry>0x65</entry><entry>0x43</entry><entry>0x6F</entry><entry>0x6E</entry><entry>0x74</entry><entry>0x65</entry><entry>0x6E</entry><entry>0x74</entry><entry>0x30</entry></row><row><entry>0x30</entry><entry>0x32</entry><entry>0x33</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x07</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x25</entry></row><row><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x01</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x04</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x1D</entry></row><row><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x11</entry><entry>0x50</entry><entry>0x72</entry><entry>0x6F</entry><entry>0x78</entry><entry>0x69</entry><entry>0x6D</entry><entry>0x69</entry><entry>0x74</entry></row><row><entry>0x79</entry><entry>0x43</entry><entry>0x68</entry><entry>0x65</entry><entry>0x63</entry><entry>0x6B</entry><entry>0x65</entry><entry>0x64</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry></row><row><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x04</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x01</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry></row><row><entry>0x04</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x1E</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x0A</entry><entry>0x43</entry><entry>0x61</entry><entry>0x6C</entry></row><row><entry>0x6C</entry><entry>0x62</entry><entry>0x61</entry><entry>0x63</entry><entry>0x6B</entry><entry>0x73</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x07</entry><entry>0x00</entry></row><row><entry>0x00</entry><entry>0x00</entry><entry>0x0C</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x01</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x05</entry><entry>0x00</entry></row><row><entry>0x00</entry><entry>0x00</entry><entry>0x04</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x01</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x12</entry><entry>0x4F</entry></row><row><entry>0x6E</entry><entry>0x41</entry><entry>0x67</entry><entry>0x65</entry><entry>0x6E</entry><entry>0x74</entry><entry>0x43</entry><entry>0x6F</entry><entry>0x6D</entry><entry>0x70</entry><entry>0x6C</entry><entry>0x65</entry></row><row><entry>0x74</entry><entry>0x69</entry><entry>0x6F</entry><entry>0x6E</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x07</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry></row><row><entry>0x6C</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x02</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x02</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry></row><row><entry>0x07</entry><entry>0x32</entry><entry>0x34</entry><entry>0x30</entry><entry>0x33</entry><entry>0x34</entry><entry>0x33</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x07</entry></row><row><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x55</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x03</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry></row><row><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x04</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x02</entry></row><row><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x35</entry><entry>0x43</entry><entry>0x6F</entry><entry>0x6E</entry><entry>0x74</entry><entry>0x72</entry><entry>0x6F</entry><entry>0x6C</entry><entry>0x2E</entry></row><row><entry>0x41</entry><entry>0x67</entry><entry>0x65</entry><entry>0x6E</entry><entry>0x74</entry><entry>0x73</entry><entry>0x2E</entry><entry>0x53</entry><entry>0x65</entry><entry>0x74</entry><entry>0x53</entry><entry>0x74</entry></row><row><entry>0x61</entry><entry>0x74</entry><entry>0x65</entry><entry>0x43</entry><entry>0x6F</entry><entry>0x6E</entry><entry>0x74</entry><entry>0x65</entry><entry>0x6E</entry><entry>0x74</entry><entry>0x30</entry><entry>0x30</entry></row><row><entry>0x32</entry><entry>0x33</entry><entry>0x2E</entry><entry>0x4F</entry><entry>0x6E</entry><entry>0x41</entry><entry>0x67</entry><entry>0x65</entry><entry>0x6E</entry><entry>0x74</entry><entry>0x43</entry><entry>0x6F</entry></row><row><entry>0x6D</entry><entry>0x70</entry><entry>0x6C</entry><entry>0x65</entry><entry>0x74</entry><entry>0x69</entry><entry>0x6F</entry><entry>0x6E</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry></row><row><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x04</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry></row><row><entry namest="1" nameend="12" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

1296E.4.4 TransferXStatusProximityCheckFailed.asm <tables id="TABLE-US-00127" num="127"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="12"><colspec colname="1" colwidth="21PT" align="left" /><colspec colname="2" colwidth="21PT" align="left" /><colspec colname="3" colwidth="21PT" align="left" /><colspec colname="4" colwidth="21PT" align="left" /><colspec colname="5" colwidth="21PT" align="left" /><colspec colname="6" colwidth="21PT" align="left" /><colspec colname="7" colwidth="21PT" align="left" /><colspec colname="8" colwidth="21PT" align="left" /><colspec colname="9" colwidth="21PT" align="left" /><colspec colname="10" colwidth="28PT" align="left" /><colspec colname="11" colwidth="21PT" align="left" /><colspec colname="12" colwidth="21PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="12" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x02</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x04</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x20</entry></row><row><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x0C</entry><entry>0x4F</entry><entry>0x62</entry><entry>0x6C</entry><entry>0x69</entry><entry>0x67</entry><entry>0x61</entry><entry>0x74</entry><entry>0x69</entry></row><row><entry>0x6F</entry><entry>0x6E</entry><entry>0x73</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x07</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x0C</entry></row><row><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x01</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x05</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x04</entry></row><row><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x01</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x0F</entry><entry>0x52</entry><entry>0x75</entry><entry>0x6E</entry><entry>0x41</entry></row><row><entry>0x67</entry><entry>0x65</entry><entry>0x6E</entry><entry>0x74</entry><entry>0x4F</entry><entry>0x6E</entry><entry>0x50</entry><entry>0x65</entry><entry>0x65</entry><entry>0x72</entry><entry>0x00</entry><entry>0x00</entry></row><row><entry>0x00</entry><entry>0x00</entry><entry>0x07</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x92</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x05</entry><entry>0x00</entry></row><row><entry>0x00</entry><entry>0x00</entry><entry>0x02</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x18</entry><entry>0x75</entry><entry>0x72</entry><entry>0x6E</entry><entry>0x3A</entry><entry>0x6D</entry></row><row><entry>0x61</entry><entry>0x72</entry><entry>0x6C</entry><entry>0x69</entry><entry>0x6E</entry><entry>0x3A</entry><entry>0x63</entry><entry>0x6F</entry><entry>0x6E</entry><entry>0x74</entry><entry>0x72</entry><entry>0x6F</entry></row><row><entry>0x6C</entry><entry>0x3A</entry><entry>0x30</entry><entry>0x30</entry><entry>0x32</entry><entry>0x33</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x02</entry><entry>0x00</entry></row><row><entry>0x00</entry><entry>0x00</entry><entry>0x14</entry><entry>0x53</entry><entry>0x65</entry><entry>0x74</entry><entry>0x53</entry><entry>0x74</entry><entry>0x61</entry><entry>0x74</entry><entry>0x65</entry><entry>0x43</entry></row><row><entry>0x6F</entry><entry>0x6E</entry><entry>0x74</entry><entry>0x65</entry><entry>0x6E</entry><entry>0x74</entry><entry>0x30</entry><entry>0x30</entry><entry>0x32</entry><entry>0x33</entry><entry>0x00</entry><entry>0x00</entry></row><row><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x04</entry><entry>0x00</entry><entry>0x03</entry><entry>0xAA</entry><entry>0xD7</entry><entry>0x00</entry></row><row><entry>0x00</entry><entry>0x00</entry><entry>0x02</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x15</entry><entry>0x4D</entry><entry>0x6F</entry><entry>0x76</entry><entry>0x65</entry><entry>0x53</entry></row><row><entry>0x74</entry><entry>0x61</entry><entry>0x74</entry><entry>0x65</entry><entry>0x43</entry><entry>0x6F</entry><entry>0x6E</entry><entry>0x74</entry><entry>0x65</entry><entry>0x6E</entry><entry>0x74</entry><entry>0x30</entry></row><row><entry>0x30</entry><entry>0x32</entry><entry>0x33</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x07</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x25</entry></row><row><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x01</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x04</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x1D</entry></row><row><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x11</entry><entry>0x50</entry><entry>0x72</entry><entry>0x6F</entry><entry>0x78</entry><entry>0x69</entry><entry>0x6D</entry><entry>0x69</entry><entry>0x74</entry></row><row><entry>0x79</entry><entry>0x43</entry><entry>0x68</entry><entry>0x65</entry><entry>0x63</entry><entry>0x6B</entry><entry>0x65</entry><entry>0x64</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry></row><row><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x04</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry></row><row><entry>0x04</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x1E</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x0A</entry><entry>0x43</entry><entry>0x61</entry><entry>0x6C</entry></row><row><entry>0x6C</entry><entry>0x62</entry><entry>0x61</entry><entry>0x63</entry><entry>0x6B</entry><entry>0x73</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x07</entry><entry>0x00</entry></row><row><entry>0x00</entry><entry>0x00</entry><entry>0x0C</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x01</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x05</entry><entry>0x00</entry></row><row><entry>0x00</entry><entry>0x00</entry><entry>0x04</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x01</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x12</entry><entry>0x4F</entry></row><row><entry>0x6E</entry><entry>0x41</entry><entry>0x67</entry><entry>0x65</entry><entry>0x6E</entry><entry>0x74</entry><entry>0x43</entry><entry>0x6F</entry><entry>0x6D</entry><entry>0x70</entry><entry>0x6C</entry><entry>0x65</entry></row><row><entry>0x74</entry><entry>0x69</entry><entry>0x6F</entry><entry>0x6E</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x07</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry></row><row><entry>0x6C</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x02</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x02</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry></row><row><entry>0x07</entry><entry>0x32</entry><entry>0x34</entry><entry>0x30</entry><entry>0x33</entry><entry>0x34</entry><entry>0x33</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x07</entry></row><row><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x55</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x03</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry></row><row><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x04</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x02</entry></row><row><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x35</entry><entry>0x43</entry><entry>0x6F</entry><entry>0x6E</entry><entry>0x74</entry><entry>0x72</entry><entry>0x6F</entry><entry>0x6C</entry><entry>0x2E</entry></row><row><entry>0x41</entry><entry>0x67</entry><entry>0x65</entry><entry>0x6E</entry><entry>0x74</entry><entry>0x73</entry><entry>0x2E</entry><entry>0x53</entry><entry>0x65</entry><entry>0x74</entry><entry>0x53</entry><entry>0x74</entry></row><row><entry>0x61</entry><entry>0x74</entry><entry>0x65</entry><entry>0x43</entry><entry>0x6F</entry><entry>0x6E</entry><entry>0x74</entry><entry>0x65</entry><entry>0x6E</entry><entry>0x74</entry><entry>0x30</entry><entry>0x30</entry></row><row><entry>0x32</entry><entry>0x33</entry><entry>0x2E</entry><entry>0x4F</entry><entry>0x6E</entry><entry>0x41</entry><entry>0x67</entry><entry>0x65</entry><entry>0x6E</entry><entry>0x74</entry><entry>0x43</entry><entry>0x6F</entry></row><row><entry>0x6D</entry><entry>0x70</entry><entry>0x6C</entry><entry>0x65</entry><entry>0x74</entry><entry>0x69</entry><entry>0x6F</entry><entry>0x6E</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry></row><row><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x04</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry><entry>0x00</entry></row><row><entry namest="1" nameend="12" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

1297Although the foregoing has been described in some detail for purposes of clarity, it will be apparent that certain changes and modifications may be made within the scope of the appended claims. It should be noted that there are many alternative ways of implementing both the processes and apparatuses described herein. Accordingly, the present embodiments are to be considered as illustrative and not restrictive, and the inventive body of work is not to be limited to the details given herein, but may be modified within the scope and equivalents of the appended claims.