[go: up one dir, main page]

WO2003019334A2 - Procede et systeme d'acces securise - Google Patents

Procede et systeme d'acces securise Download PDF

Info

Publication number
WO2003019334A2
WO2003019334A2 PCT/US2002/027303 US0227303W WO03019334A2 WO 2003019334 A2 WO2003019334 A2 WO 2003019334A2 US 0227303 W US0227303 W US 0227303W WO 03019334 A2 WO03019334 A2 WO 03019334A2
Authority
WO
WIPO (PCT)
Prior art keywords
content
media
host
certificate
identifier
Prior art date
Application number
PCT/US2002/027303
Other languages
English (en)
Other versions
WO2003019334A3 (fr
Inventor
Timothy R. Feldman
Lane W. Lee
Michael F. Braitberg
Douglas M. Rayburn
Gary G. Kiwimagi
Steven B. Volk
Original Assignee
Dataplay, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US09/940,025 external-priority patent/US20030188175A1/en
Priority claimed from US09/940,026 external-priority patent/US7310821B2/en
Priority claimed from US09/940,174 external-priority patent/US7729495B2/en
Priority claimed from US09/940,083 external-priority patent/US7110982B2/en
Priority claimed from US09/940,035 external-priority patent/US20030188183A1/en
Priority claimed from US09/939,960 external-priority patent/US20030135465A1/en
Priority claimed from US09/939,896 external-priority patent/US7672903B2/en
Application filed by Dataplay, Inc. filed Critical Dataplay, Inc.
Priority to AU2002323431A priority Critical patent/AU2002323431A1/en
Publication of WO2003019334A2 publication Critical patent/WO2003019334A2/fr
Publication of WO2003019334A3 publication Critical patent/WO2003019334A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]

Definitions

  • the present invention relates to the field of digital rights management. More particularly, this invention relates to security and systems and methods that ensure that content is accessed, copied and controlled in secure ways in an electronic environment. Description of the Related Art
  • Entities including people, companies, systems and computers transfer information faster than ever since the advent of the Internet and technologically advanced electronic appliances. Facsimile machines, computers, and electronic appliances such as personal digital assistants (PDAs) and wireless phones with Internet access enable the quick transfer of information to remote locations around the world.
  • PDAs personal digital assistants
  • wireless phones with Internet access enable the quick transfer of information to remote locations around the world.
  • Cryptographic solutions not only provide confidentiality to transactions and content, but provide methods for authentication, integrity (e.g., verifying that a message has not been modified in transit), and non-repudiation (preventing false denials of transactions). Some cryptographic solutions are referred to as restricted algorithms that typically are used by low-security applications. More recently, cryptographic keys protect content by requiring a key for both encryption and decryption of content. Key- based cryptographic solutions enable the spreading of an algorithm without risking security breaches because the security onus is on the keys themselves.
  • a more secure key solution is the public-key solution, or asymmetric solution, in which the key used for encryption is different from the key used for decryption.
  • the public-key solution is part of the ISO authentication specifications, commonly known as the X.509 protocols. More specifically, the X.509 protocols provide a framework for authentication across networks, such as the Internet. The X.509 protocols do not specify a particular algorithm. Instead, the protocols focus on using public-key certificates. Under the specification, each user has a distinct name and has a signed certificate with a name and a public key issued by a trusted certification authority (CA).
  • CA trusted certification authority
  • Typical fields in an X.509 certificate include: version; serial number; algorithm identifier; issuer; period of validity; subject; subject's public key; and signature. More specifically, a version field identifies a format for the certificate. A serial number is unique for the certification authority.
  • the algorithm field identifies the type of algorithm used to sign the certificate and includes necessary parameters to run the algorithm.
  • the issuer field identifies the name of the CA.
  • the period of validity field provides the time period during which the certificate is valid.
  • the subject field identifies the name of the user.
  • the subject's public key field provides the algorithm name, parameters and such related to the public key.
  • Communicating using certificates configured according to the X.509 protocol is known in the art.
  • a user desiring to communicate with another retrieves the destination certificate from a database and verifies authenticity. Verifying authenticity often involves several CAs if there is a hierarchy of CAs between the user's CA and the destination CA. After verification, communication may take place. Typically, timestamps are used to confirm that messages are current.
  • a three-way protocol is one authentication protocol that does not use timestamps, however, additional steps are required involving the user checking a random number that was originally generated by the user, sent to the destination, and received back from the destination. Likewise, the destination checks a random number received from the user that was originally generated at the destination.
  • Fingerprinting is typically accomplished using a hash function.
  • a common hash function is the one-way hash function that provides a fixed- length hash value, h, after operating on an arbitrary-length pre-image message. The i is unique to the message associated with it.
  • the security of the h depends on the number of bits of the hash. A practical size is 128 bits.
  • hashing algorithms including the Message Digest (MD) 4 algorithm, the MD5 algorithm, which is more complex than the MD4 algorithm.
  • MD5 algorithm is more complex than the MD4 algorithm.
  • Another type of hash function is the n-hash algorithm.
  • DRM digital rights management
  • DRMs use the extensible Rights Markup Language (XML) to implement access and use controls for the exchange of secure digital content.
  • Markup languages are typically based on the Standard Generalized Markup Language (SGML).
  • SGML is a standard language for defining the format in a text document that allows sharing of documents among computers, regardless of hardware and operating system configurations.
  • Markup language files use a standard set of code tags embedded in text that describes the elements of a document. The web browser interprets the code tags so that each computer having its own unique hardware and software capabilities is able to display the document while preserving the original format of the document.
  • An SGML document uses a separate document type definition (DTD) file that defines the format code tags embedded within it.
  • DTD document type definition
  • DRM schemes are implemented with C, Fortran and other known programming languages.
  • Known systems include Interleaf, ArborText, and TexCel.
  • the system includes a controller including an interface component, a host system coupled to the controller, the host system configured to present content under predetermined conditions, the host system operable with a navigation protocol, the host system further including a system manager operable with an associations component configured to be at least partially run by the host system, a translator configured to provide meanings and generate commands within the host system at least a first digital rights management (DRM) component configured to provide encoding and access rules for the content; and a file system component including a file system application programming interface (API) configured to provide a logical interface between a plurality of components.
  • DRM digital rights management
  • API file system application programming interface
  • a method for securing electromc content includes interfacing a controller to provide input and output of data, coupling a host system to the controller, configuring the host system to present content under predetermined conditions, operating the host system with a navigation protocol, and operating a system manager on the host system.
  • the host system is operable to configure an associations component to be at least partially run by the host system configure a translator to provide meanings and generate commands within the host system, configure at least a first digital rights management (DRM) component to provide encoding and access rules for the content, and configure a file system component including a file system application programming interface (API) to provide a logical interface between a plurality of components.
  • DRM digital rights management
  • API file system application programming interface
  • a system and method for detecting unauthorized actions with respect to encrypted data on a media disk, the media disk including a first portion for prerecorded content and a second portion for written content.
  • the method includes reading an identifier on the media disk, wherein the identifier includes one or more sections located in one of the first portion for pre-recorded content, the second portion for written content, and both the first portion for pre-recorded content and the second portion for written content, determining whether the identifier includes a section located in the second portion written content, comparing the identifier with one or more predetermined types of identifiers for which a section is located in the second portion for written content, and if the identifier is of a type that is one of the one or more predetermined types of identifiers, detecting an unauthorized action.
  • a method of identifying one or more vendors associated with a media disk includes providing instructions for the media disk, during a first install of the media disk into a host according to the instructions, installing a unique identifier on the media disk, the unique identifier including a code identifying the vendor from which the media disk originated, and after transmitting data to a server, reading the unique identifier to find a location associated with the vendor.
  • Another embodiment is directed to a method of identifying a location via a media disk, the media disk having at least a writeable portion and a non-rewriteable portion.
  • the method includes writing the location on the writeable portion, distributing one or more of the media disks to one or more entities, the location associating the media disks to the one or more entities, and if a return of the media disks occurs, altering the location according to predetermined conditions.
  • a system and method for altering secured data on a storage medium.
  • the method includes establishing a secure session with a host, receiving, via a communications channel, a command to unlock the secured data governed by at least one of a plurality of content storage models, and unlocking the secured data wherein the command responds to an identifier on the medium, the identifier configured to govern access to the secured data, and at least one of the plurality of content storage models is a secure content manager.
  • a system includes a plurality of content storage models for locked data stored on the storage medium, and an engine capable of unlocking secured data wherein the engine modifies attributes of the data on the storage medium to unlock the secured data according to a content storage model in response to a command to unlock the data.
  • a system and method for authenticating a device.
  • a method includes receiving a certificate from the device, the certificate including a plurality of fields, including a field holding a digital signature from a certifying authority, verifying the digital signatures in the certificate, the verifying including at least one of verifying the certifying authority digital signature using the certifying authority public key; and verifying a device digital signature using a device public key, and receiving validation data from a source, the validation data identifying one or more data in the certificate as valid or invalid according to predetermined criteria, and if the digital signatures are verified and validated, transmitting a session key to the device to establish a secure communication channel.
  • a system and method for revoking a device.
  • a method includes receiving a certificate from the device, the certificate including one or more of fields, at least one of the fields holding a signature, attempting to verify the signature, receiving a revocation list from a source, the revocation list identifying one or more data on the certificate as valid or invalid, the data including at least one of the fields of the certificate; and if one of one or more signatures identified unsuccessfully verified and one or more data is identified as invalid, preventing the transmission of a session key to the device, the session key being required to establish a secure communication channel.
  • a system and method for securing content stored on media includes attaching content privileges to the media, wherein the privileges govern a plurality of levels of access, and configuring the media to permit access to the content according to the content privileges and predetermined conditions.
  • An apparatus for securing content stored on media includes at least one tool for transferring content onto the media, the tool configured to attach a plurality of levels of access, wherein content privileges and predetermined conditions govern access to the content.
  • Fig. 1 illustrates the interoperability of digital rights management systems within the secure electronic content system according to an embodiment of the present invention.
  • Fig. 2 illustrates a content flow diagram according to an embodiment of the present invention.
  • Fig. 3 illustrates method supported by a secure electronic content system according to an embodiment of the present invention.
  • Fig. 4 illustrates an Open System Interconnection Model (OSI Model) of a secure electronic content system architecture in accordance with an embodiment of the present invention.
  • OSI Model Open System Interconnection Model
  • Fig. 5 A illustrates content flow for secure and insecure metadata according to an embodiment of the present invention.
  • Fig. 5B illustrates a secure method of extracting data from media according to an embodiment of the present invention.
  • Fig. 5C illustrates a certification procedure according to an embodiment of the present invention.
  • Fig. 6 illustrates a procedure using a certificate to establish a secure authenticated channel according to an embodiment of the present invention.
  • Fig. 7A illustrates an apparatus that performs a verification process according to an embodiment of the present invention.
  • Fig. 7B illustrates a method for securely delivering data across a channel is shown in flow diagram form according to an embodiment of the present invention.
  • Fig. 7C illustrates a method for revoking a content rendering device according to an embodiment of the present invention.
  • Fig. 7D illustrates a flow diagram of the evaluation of a revocation list according to an embodiment of the present invention.
  • Fig. 7E illustrates a method performed by an engine when presented with a revocation list according to an embodiment of the present invention.
  • Fig. 7F illustrates the evaluation method for revocation list results according to an embodiment of the present invention.
  • Fig. 7G illustrates a method for organizing content according to an embodiment of the present invention.
  • Fig. 7H is a process flow diagram for an embodiment of a mastering process.
  • Fig. 71 is a process flow diagram of an embodiment of a process for creation of package collection, packaged advertisements, and SKUs.
  • Fig. 8 illustrates a flow diagram of the API for the CKDRM play function according to an embodiment of the present invention.
  • Fig. 9 illustrates a method for the CKDRM copy API protocol according to an embodiment of the present invention.
  • Fig. 10 illustrates a third party DRM copy method according to an embodiment of the present invention.
  • Fig. 11 illustrates a method of recording content using the CKDRM according to an embodiment of the present invention.
  • Fig. 12 illustrates a method of unlocking content according to an embodiment of the present invention.
  • Fig. 13 illustrates a method for the CKDRM copy API protocol according to an embodiment of the present invention.
  • Fig. 14 illustrates an engine performing a CKDRM Copy method that copies content within the CKDRM domain according to an embodiment of the present invention.
  • Fig. 15 illustrates a recording scenario according to an embodiment of the present invention.
  • Fig. 16 illustrates a method of playing content governed by CKDRM according to an embodiment of the present invention.
  • Fig. 17 illustrates a more detailed play method using commands according to an embodiment of the present invention.
  • Fig. 18 illustrates a flow diagram for a CKDRM unlock according to an embodiment of the present invention.
  • Fig. 19 illustrates a TPDRM Copy protocol in flow diagram form according to an embodiment of the present invention.
  • Fig. 20 illustrates a flow diagram of a method for TPDRM Copy according to an embodiment of the present invention.
  • Fig. 21 illustrates a Read Secure Metadata protocol according to an embodiment of the present invention.
  • Fig. 22A illustrates a flow diagram of a protocol for a host to write its secure metadata according to an embodiment of the present invention.
  • Fig. 22B illustrates a flow diagram for a method of detecting counterfeit media according to an embodiment of the present invention.
  • FIG. 23 A an architecture diagram provides an embodiment of the interactions between servers, hosts and engines.
  • Fig. 23B illustrates a flow diagram showing an authoring process.
  • Fig. 24 illustrates a flow diagram for a process of setting up a secure database and secure media.
  • Fig. 25 illustrates a process for a setup for an electronic retailer.
  • Fig. 26 provides a flow diagram from a consumer perspective of a transaction to unlock content according to an embodiment of the present invention.
  • Fig. 27 illustrates an exemplary user interface illustrating a consumer perspective of a transaction to unlock content according to an embodiment of the present invention.
  • Fig. 28 illustrates a flow diagram of components enabling an unlock process in the SEC system according to an embodiment of the present invention.
  • Fig. 29 illustrates a secure electronic content flow diagram according to an embodiment of the present invention.
  • Fig. 30 illustrates content types available on media according to an embodiment of the present invention.
  • Fig. 31 A illustrates a flow diagram of transaction types according to an embodiment of the present invention.
  • Fig. 3 IB illustrates a method for a user interface including a method for locating a URL associated with a media disk according to an embodiment of the present invention.
  • Fig. 31C illustrates a method for connection to a CKU Server according to an embodiment of the present invention.
  • Fig. 32 illustrates a method for a server after a connection is requested from a client according to an embodiment of the present invention.
  • Fig. 33 illustrates a method performed by the Master Server according to an embodiment of the present invention.
  • Fig. 34 illustrates a method for a web page and a CKU client server according to an embodiment of the present invention.
  • Fig. 35 illustrates a method for unlocking content from a system viewpoint according to an embodiment of the present invention.
  • Fig. 36 illustrates a method for unlocking content from an engine perspective according to an embodiment of the present invention.
  • Fig. 37 illustrates a process flow diagram for a complete unlock transaction according to an embodiment of the present invention.
  • Fig. 38 illustrates a flow diagram of a method according to one embodiment for a process to unlock content.
  • Fig. 39 illustrates a flow diagram illustrating an object interaction among components.
  • Fig. 40 illustrates a flow diagram of an unlock transaction according to an embodiment.
  • Fig. 41 illustrates a block diagram of object interactions among components.
  • a secure electronic content (SEC) system provides a solution to electronic content concerns of the content creators, content providers, content owners, and content users.
  • the scope of the SEC system includes media, an engine capable of providing read and write access to the media, encryption and access rules, encoding, decoding, meanings, associations, navigation and presentation, the standardization of each of which results in a seamless security system for electronic content.
  • the encryption and access rules disclosed in embodiments herein provide an invisible and seamless ContentKeyTM digital rights management (CKDRM) system that secures content and allows content to be portable and interoperable with appropriate electronic devices.
  • the CKDRM supports fair use by content purchasers and users with the CKDRM directly supporting personal use copies of electronic content and allowing import and export of content.
  • pre-recorded, unlocked content located on media is playable at a point of sale by a device designed to render content protected with the CKDRM or other third party digital rights management schemes (TPDRMs).
  • TDRMs third party digital rights management schemes
  • pre-recorded content includes mastered content.
  • pre-recorded locked content on media may be unlocked by a device/player operating in accordance with an embodiment by connecting with a clearinghouse. Depending on the permissions granted on media, any player may render the content after unlocking. Moreover, unlocked content may be moved onto CKDRM associated media and be rendered on a player. The embodiments further disclose that the media may be written to without resulting in content capable of being rendered on any player, but only on predetermined players. According to one embodiment, for example, the CKDRM permits a predetermined number of copies of pre-recorded, unlocked content as determined by content providers and licenses and the like.
  • the CKDRM supports new content consumer experiences by providing a method of unlocking content and managing content.
  • the disclosed CKDRM is implemented by devices capable of rendering electronic content, hereinafter "players.”
  • Players implement the CKDRM and interface with servers, kiosks, replicators, and the like.
  • Players either embed an engine that operates with the CKDRM to provide security or couple to the engine, for example, a personal computer (PC).
  • PC personal computer
  • players render content on digital media, such as disks.
  • a PC implements a player.
  • the CKDRM is also extensible by, in part, providing a flexible unlocking method and supporting the transfer of content and rules to other DRM implementations.
  • a player implementing CKDRM is further capable of implementing third party DRMs (TPDRMs).
  • a player with an embedded engine implements CKDRM and exposes a file system and a CKDRM application programming interface (API) through general purpose interfaces.
  • the CKDRM advantageously provides numerous functions, including unlocking, play, counting copies, importing from certified sources, exporting to certified destinations, and securing metadata storage.
  • the CKDRM system includes security and access rules as part of the secure electronic content system.
  • SEC Secure Electronic Content
  • AES Advanced Encryption Standard
  • API Application programming interface. This term refers to the logical interface between components
  • Certificate Authority is the entity that issues certificates.
  • the Content Provider is the entity that owns the rights to the content and participates in the delivering content to the marketplace.
  • DFS DataPlay File System.
  • DFS is an open application programming interface (API).
  • API application programming interface
  • USB Universal Serial Bus - Physical connection between the Client PC and a connected engine
  • MAC is an acronym for Message Authentication Code.
  • SHA-1 SKA is an acronym for Secure Hash Algorithm, which is defined by NIST FIPS PUB 186.
  • Protected Content - Content that is stored on the digital media in an encrypted form under the governance of CKDRM.
  • Unlocked Content - Protected Content that is available to be rendered on any certificated device capable of rendering the content. Unlocked Content that was pre- mastered onto the media in this state may also referred to as Primary Content. Locked Content: Protected Content that is not available to be rendered until a
  • Locked Content is also referred to as Secondary Content.
  • Table 1 A provides an interoperability stack showing the layers with which the CKDRM operates.
  • the stack further includes layers supplied by other TPDRMs, players on which an appropriate engine is embedded, and players coupled to such players.
  • engine refers to a component that provides read and write access to digital media. As such, embodiments include one or more of a firmware, software, and hardware, or any combination thereof implementation of an engine.
  • the CKDRM is focused on layers 107 and 108 of the interoperability stack.
  • a disk in accordance with an embodiment allows secure pre-recorded content, written content or both prerecorded and written content on the same disk.
  • Data may be stored on the disk in large blocks or small blocks of data.
  • the system supports a hierarchical directory structure with file data.
  • data written by the file system "writes" and returned for file system file "reads” are stored as file data.
  • only the data stored in files is accessible through the file system application-programming interface (API).
  • API application-programming interface
  • an API refers to a logical interface between components. The interpretation of the file data is indicated by file type, as, for example, a
  • MIME string MIME string, directory and file name.
  • Layer 109 does not allow full access to metadata through file system reads and writes. Rather, metadata allows an engine to support the storage of data outside the file system. Thus, some metadata is visible to the host, such as file names, MEVIE type, size and attributes. Other metadata is exposed only via the CKDRM API. Yet other metadata is only available to an engine. For example, according to an embodiment, secret media identifiers and private metadata is visible only to an engine. Data may be associated with a disk, a directory and a file. The engine, in accordance with the CKDRM may change and manage the metadata and thus, updates consume less of available disk capacity.
  • predetermined metadata is bound to the engine and not stored on a disk. Further, the predetermined metadata is not accessible through the file system API.
  • This information includes the engine's firmware, and public and private key pair. The key pair is generated in conjunction with engine manufacturing, and according to a secure process.
  • field updates of engine private storage are supported by the CKDRM via a secure process.
  • the SEC system advantageously allows TPDRM metadata to be stored with each file, if desired. Moreover, an embodiment allows multiple TPDRM metadata for any individual file. TPDRM metadata may have an ownership identifier that matches a received CKDRM Certificate, as described in further detail below, to gain access to the metadata.
  • TPDRM metadata is stored with each file, and, therefore uses the metadata system already used in an appropriate file system, such as the DataPlay File System (DFS).
  • TPDRM metadata nodes may have a bit set in a file system flag definition to identify the data as TPDRM metadata.
  • a metadata packet may be that shown in Table IB. Each symbol showing "U” followed by a number indicates an unsigned value and a bit length of the value.
  • TPDRM metadata is stored in RAM type memory. However, if TPDRM metadata it too large to store all of it in RAM, then a lookup system may be employed wherein the TPDRM metadata is replaced with a value that represents the location for the metadata item.
  • Certain data is available only through the CKDRM API, including data managed by the engine, including metadata providing play keys and remaining copy counts. According to some embodiments, data available through the CKDRM API includes data managed by a second TPDRM, in which case the format is defined by the TPDRM.
  • Fig. 1 a block diagram illustrates a content storage model for electronic content. As shown, there are five basic models in which content may be stored and governed. One type is shown as ungoverned content using file system methods only 120.
  • Ungoverned content 120 includes basic information such as cleartext data, such as in a general computer storage model. Also shown in Fig. 1 is TPDRM-governed content 130. Such governed content may use the same methods and facilities as ungoverned content 120. Such content includes TPDRM-governed content using file system methods only 180. In this model 180, the TPDRM has responsibility for securing the content and the metadata. Model 180 does not require pre-qualification of the TPDRM by the CKDRM, thus any TPDRM may be operable to govern content in this model. This matches the model of TPDRM-governed content on storage without security facilities. In another type of storage of electronic content, TPDRM-governed content is accessed with the file system, but metadata accesses use CKDRM facilities such as CKDRM APIs 182.
  • Block 184 relates to a model of governing content using CKDRM metadata rules and a TPDRM API wherein theTPDRM API governs rendering of electronic content.
  • the model provides a high level of security for the content itself as additional layers of encryption are implemented by an engine.
  • Another content storage model 140 provides that content is governed by both a TPDRM and by CKDRM rules for content and metadata. This model 140 permits an overlap between CKDRM governed content and third party DRM governed content. Thus, the system supports content accessed through a CKDRM API and governed by a third-party DRM.
  • Access model 150 provides the content and metadata are governed by the CKDRM. Model 150 provides a higher level of security for the content by providing that predetermined metadata never leaves the engine. One type of content appropriate for this model is pre-recorded content.
  • a third party DRM controlling content has a choice of models for moving content to a disk.
  • rules governing the content may constrain the choice of models available.
  • required security requirements may govern the choice of model, with CKDRM models providing greater security.
  • the CKDRM models when sufficient to govern necessary permissions of the content, provide efficient and value-added benefits to consumers and content providers.
  • Fig. 1 further shows that the system provides for at least two types of access to content. More particularly, access 160 shows that content may be accessed directly if ungoverned by using a file system access. Protected content may be accessed via access 160 via the file system API. Access 170 provides that protected content may be accessed via the CKDRM. Referring now to Fig.
  • a content flow diagram 200 illustrates how content organized in one of the plurality of models shown in Fig. 1 flows in the secure electronic content system.
  • a content provider 202 decides the content following one of the models shown in Fig. 1.
  • a replicator 204 creates multiple copies for distribution. Examples of media following this content flow path include compact disks (CDs), digital versatile disks (DVDs), optical disks such as DataPlayTM optical disks and magnetic media such as floppy disks and tapes.
  • the replicator 204 is a manufacturer that includes on any media any necessary data to enable secure functionality of the content as described above with reference to Fig. 1.
  • the content flows from a content provider to a server 206.
  • Server 206 transfers the secure content to one or more of a kiosk 207, directly to an engine equipped to receive secure data 208(3), or to a connected host 210 that is coupled to an engine 208(3).
  • the connected host 210 in one embodiment, is a personal computer that enables CKDRMs, TPDRMs and file system rules.
  • Content also flows from an engine 208(3) to an embedding device 211.
  • the embedding device 211 in an embodiment, enables CKDRM and TPDRMs.
  • CKDRM operates in the context of the secure electronic content system (SEC system).
  • Fig. 3 illustrates methods supported by the secure electronic content system in block form.
  • the components include a content provider 302, tools and processes for producing pre-recorded content 304, appropriate media, such as a disk 306, an engine
  • the components are organized into an architecture that partitions the SEC system and assigns responsibilities.
  • a content provider 302 brings the original content and makes decisions for all of the variable qualities. The decisions include: which files are initially locked and unlocked; when the file is unlocked, whether the content may be played by player running CKDRM or
  • TPDRMs how many copies may be made according to CKDRM rules and TPDRM rules; and what rules are to be governed in the CKDRM domain and the TPDRM domain.
  • the electronic content system supports global TPDRM rules that limit the number of subsequent copies a TPDRM is allowed to make. In other embodiments, the electronic content system supports rules for specific TPDRMs.
  • the tools and processes for producing pre-recorded content 304 take all of the inputs from a content provider 302 and create appropriate digital media 306 that conforms to all of the requirements of pre-recorded content.
  • the content is encoded, if not already, in one of a plurality of formats.
  • the content is encrypted in layers of encryption with keys generated and stored in predetermined methods as described herein.
  • Digital media 306 contains all of the information needed to support all of the usage models and permissions specified by content provider
  • a player 310 is a certified host 316 that receives a certificate
  • Certificate 318 provides an authentication portion of the protocols, and establishes an authenticated channel for access to secure API's.
  • Engine 308 presents APIs to the players 310 and TPDRMs and CKDRMs to support a plurality of the usage models.
  • engine 308 supports security through the methods implemented in hardware and firmware, but also by embodying cryptographic keys.
  • the cryptographic keys are unique to each engine and some are global among all engines.
  • each engine may include non-volatile memory that stores a signature key list.
  • the list is an array of public keys used for validating CA signatures.
  • the engine 308 is an endpoint in the authenticated connections that are established.
  • the engine 308 decrypts and encrypts various encryption layers in the play, copy and handoff functions.
  • the engine 308 enforces the basic unlock transactions at the disk 306 level.
  • the engine 308 governs the play and copy permissions, including decrementing the copy counts on the disk 306.
  • the engine 308 operates with a USB or other interconnection driver that conforms with APIs used by the CKDRM and DFS APIs.
  • the driver in an exemplary embodiment allows the engine to communicate with hosts, including players, such as PCs regardless of the host hardware manufacturer or configuration.
  • the operating system may communicate with a WindowsTM Registry or .inf file(s) to locate the driver on a system when multiple engines are connected to a host.
  • player 310 is a host portion of a device that embeds an engine 308.
  • a player 310 may be an application on a platform coupled to a device with an embedded engine 308.
  • player 310 uses the APIs exposed by the engine 308 to access content and presentation information on a disk 306. The player 310 uses that information to present data to a user and render the content.
  • player 310 is an endpoint in the authenticated connection that is established in the secure API 309.
  • a player 310 in accordance with an embodiment, must request an authenticated channel after an authority 320 certifies the player 310.
  • the certification process includes issuing player 310 a public key and private key pair, and a certificate 318.
  • the authenticated channel allows access to a secure API 309.
  • CKDRM and, if media is configured to use TPDRMs, one or more TPDRMs manage rights and govern operations on secure content.
  • CKDRM and/or TPDRMs implement the rules specified by the content provider 302 and stored on the disk 306.
  • the CKDRM or a TPDRM is an endpoint in the authenticated connection that is established in the secure API 309.
  • the TPDRM implementation is outside of the engine 308. Nonetheless, the engine 308 through a secure API 309 offers secure storage on media 306.
  • the TPDRMs must be compliant with the disclosed secure electronic content system. More particularly, a compliant TPDRM must request an authenticated channel before accessing content and secure data.
  • the authenticated channel is created by first certifying the TPDRM and issuing a public key and private key pair, and a CKDRM certificate.
  • the CKDRM certificate may include a CA Signature Public Key ID or public key identifier that acts as an index to a valid signature key list of an engine 308 for a number of purposes as explained in further detail below.
  • the authenticated channel is created for further access to a secure API.
  • FIG. 4 an Open System Interconnection Model (OSI Model) 400 of the SEC system is shown that provides an overview of the architecture for supporting the functions described with reference to Fig. 2 and other functions.
  • the layered OSI model 400 shows the supported paths in the host 310, engine 308 and media 306.
  • Fig. 4 includes a physical layer 410, a command- data layer 406, a data link layer 408, a session layer 404 and an application layer 402.
  • Fig. 4 describes each of the layers with reference to components of interconnection between a host 310, an engine 308 and digital media 306. Interconnections outside of the host 310, engine 308 and digital media are within the scope of present invention and the exclusion with reference to Fig. 4 is by no means intended to be limiting.
  • the OSI model 400 is described below with reference to the flow of electronic content as shown in Fig. 2.
  • a media 306, such as a disk or other portable media, or media permanently stationed in an engine 308, includes file system file data 470, file system metadata 472 and CKDRM metadata 474 as part of its physical layer.
  • the data flows through physical layer interfaces 424 and 448.
  • the data on the media 306 flows through a data link layer 408 that interprets the data in optics 460 in an optical disk embodiment.
  • an interface protocol 422 provides the data link layer 408.
  • a player reads or writes to the media 306 via read/write 440.
  • the interface protocol runs either a file system 420 and/or the CKDRM 430, depending on data read at read/write 454. More particularly, according to one embodiment, a host 310 must be certified at the application layer 413 to run CKDRM 430. The certification process as more fully described below, determines whether the host 310 is secure 416 or insecure 414.
  • a certified host runs encrypt-decrypt processes in the session layer 404 to authenticate a channel as more fully described herein.
  • An uncertified host 412 runs insecure processes 414 at the session layer 404 via an open file system 420.
  • the engine 308 For insecure content, the engine 308 performs file and metadata mapping 440 at the application layer and runs open file systems 420 at the command data layer 406. For secure content, the engine 308 processes files and maps metadata at block 440, but also encrypts and decrypts the secure data at the session layer via secure 416(2) and encrypt- decrypt 418(2) using the CKDRM rules 430 at the command data layer 406. In an embodiment, the host 310 and the engine 308 work with the media by having servo positioning 452 direct a player to locations on the media 306 where secure content should be found at the session layer 404. The secure and insecure data are then managed at block manager 450 at the application layer 402. Fig.
  • the CKDRM implements an efficient security model wherein electromc content is created and secured via an application 516 and represented in files 502 as well as metadata 504.
  • the content elements 502 and 504 are encrypted.
  • an encrypted form is returned.
  • content is accessed for play or handoff to a TPDRM the content with a lighter form of encryption may be returned.
  • Open APIs 506 only allow plain file read and write access 512; the secure metadata and unencrypted content are not available via open APIs 506.
  • block level access of contents on media is via firmware including a block driver.
  • Block level access to content on a hard drive of a computer is generally accessible via only a block driver.
  • the firmware prevents open access by not supporting block access for block drivers.
  • the file system may be hierarchical in nature.
  • the media disk may have a writeable, write-once portion, and a read-only portion with pre-mastered content.
  • a media identifier may be in one or each of the portions and may or may not be the same identifier. Further, in one embodiment, the identifier is read from the media disk and extracted for use in an application specific integrated circuit (ASIC) and/or firmware. The identifier may be used as a seed to an encryption block with or without a decryption block. In one embodiment, the encryption block may be a triple-DES block.
  • ASIC application specific integrated circuit
  • a method according to an embodiment is directed to media including an identifier, and more particularly, to a secure method of extracting data from media.
  • Block 530 includes enabling access to the data via firmware.
  • the data may be stored in blocks and accessible via a block driver within the firmware.
  • Block 532 provides for preventing access to the data outside the firmware.
  • the firmware is included within an application specific integrated circuit (ASIC).
  • the firmware and the ASIC may be within a host, one embodiment, the firmware may include, a TPDRM API, a CKDRM API and/or a DFS API.
  • hosts receive a certificate 514 from an entity controlling certification of hosts.
  • the certificate 514 specifies the secure APIs 508 to which an application 516 may have access.
  • a host includes any physical device that embeds an engine, a TPDRM, an application running in an open computing environment, or a clearinghouse server.
  • CKDRM Certificates may be signed by a private key assigned according to a class of device. In one embodiment, private keys are used only for one class, and the corresponding public key belongs to a class of devices.
  • the device classes may include engines, host devices embedding an engine, but with no external digital I/O port, host devices embedding an engine, and with digital I/O ports, and host applications not embedding an engine.
  • engines have the public keys for the devices they wish to authenticate, and the engine may need only to authenticate one embedding host.
  • each engine receives a certificate.
  • Engines also need to authenticate host applications not embedding an engine by receiving a certificate.
  • the entity controlling certification cryptographically signs certificate 514.
  • the certificate 514 specifies a category that designates the secure APIs 508 to which the certificate holder host receives access.
  • certificates 514 specify the company to which the certificate 514 was issued.
  • certificate 514 also specify one or more of the product category, product line, model, revision and serial number of the engine and/or host.
  • the first eight items in Table 2A are supplied to a certifying authority (CA) by the company requesting a certificate.
  • a company retains a private key that corresponds, to the Host Signature Key.
  • the CA signature is created using a private key that corresponds to a public key specified in a Signature Key ID.
  • the first eight fields are returned to the manufacturer when a device passes qualification.
  • the last three fields, 9-11, are added by the manufacturer.
  • the certificate enables an entity to control quality of hosts and engines by invalidating false devices, and devices with latent defects
  • the fields 1-8 are issued by the entity controlling hosts and engines and provided to a device manufacturer. The device manufacturer then appends fields 9-11.
  • the certificates haye certificate classes that provide a set of methods that may be exposed as specified by a CKDRM certificate. Any combination of methods may be exposed by the certificate format. However, an example of possible exposed methods that may be exposed via the certificate class is provided in Table 2B.
  • the classes may include an engine, a player, a TPDRM domain, a CKDRM mastering tool domain, a kiosk, and a clearinghouse server domain.
  • the exposed methods are TPDRM and CKDRM methods. Although any combination of exposed methods is possible for any particular class, Table 2B shows one possible embodiment.
  • a SEC system may provide for host sanctioning. More particularly, in host sanctioning CKDRM secure APIs are available only to hosts that are officially and formally sanctioned by an entity, such as DataPlay, Inc.
  • the authorization in an embodiment includes issuance in block 556 by the entity, such as DataPlay, Inc., of a certificate indicating the CKDRM secure APIs that are available.
  • Another more specific form of a CKDRM Certificate Format is provided below in
  • the fields in Table 2C include the following: CAIdentifier uniquely identifies the CA; CertificateFormatVersion uniquely identifies this version of the CKDRM certificate format; CASignaturePublicKeyld is selected by the CA; CryptographyVersion uniquely identifies the cryptographic methods used by the certificate; ExposedMethods identifies the CKDRM methods to which this certificate allows access
  • the fields in Table 2C further include fields that are more specifically described below.
  • a company may uniquely identify the company to which the certificate is issued.
  • the field size supports 65,536 different companies.
  • a larger or smaller size field is within the scope of the present invention.
  • the exemplary field size shown in Table 2C supports, at a rate of 10 per day, 365 days per year, 18 years of valid certificates.
  • the company may further supply the Division, ProductLine, Model and Revision values of their choice to the CA. Together, the information supplied uniquely identifies the product design to which the certificate is issued.
  • the CA allocates Metadataldentifier values. These uniquely identify access to secure metadata in the Read Secure Metadata and Write Secure Metadata methods, as explained in greater detail below.
  • the Company also supplies the HostSignaturePublicKey with the Company retaining the corresponding private key. CompanySignature is created using this corresponding private key and is verified with CompanySignaturePublicKey.
  • CASignature is created using the private key that corresponds to the public key specified by CASignaturePublicKeyld.
  • the last three fields may be added by the Company on a device-by-device basis.
  • Deviceldentifier is a value such as a serial number that uniquely identifies the device to which the certificate is issued.
  • ProtocolPublicKey is selected by the Company; the corresponding private key is embedded in the device.
  • ProtocolPublicKey when encrypting with the host's public key in the CKDRM protocols, ProtocolPublicKey is used, not CompanySignaturePublicKey.
  • CompanySignaturePublicKey is used only to authenticate ProtocolPublicKey through CompanySignature.
  • Metadataldentifier field in combination with the Company field identifies a host for purposes of access to secure metadata.
  • the values may be allocated by the CA in response to requests for new values from the Company.
  • one of revocation methods 518 includes transmitting an encrypted identifier from the device via a communication channel and receiving a certificate identifying the device as one of an authenticated device and a non-authenticated device.
  • revocation methods 518 revoke compromised certificates and cryptographic keys. Specifically, revocation methods 518 revoke compromised certificates and private keys. In one embodiment, information as to whether certificates and/or private keys have been revoked is stamped on the media. Thus, revocation is enforced in stand alone, unconnected environments.
  • APIs 506 and 508 shown in Fig. 5A may be encrypted. Further, cryptographic keys with which the content/API is encrypted may themselves be encrypted. By encrypting content it is possible to allow open file system read access to files containing content. The file system reads and delivers the encrypted content without the decryption keys. When access is made through a secure protocol, the content may be delivered in a form that is different from the stored form. Thus, according to an embodiment, even if playback keys are compromised there is not enough information to decrypt any open API files.
  • cryptographic keys are bound to the media.
  • content access follows the media and access rights are not bound to a particular playback device.
  • key binding not only stores the keys on the media, but also encrypts the keys to media identifiers. Therefore, the content being doubly encrypted, when and if bound play or copy keys are compromised there is not enough information to decrypt the content.
  • Fig. 5C the binding of keys to the media is described in a flow diagram. As shown, block 552 provides that a method of securing content stored on media includes attaching content rights to the media. The attaching of the content rights to the media may preclude content being located in a player or engine.
  • Block 554 provides for permitting access under predetermined conditions.
  • the access to the content as described in block 554 may include one or more of playback of contents, copying of content, allowing one or more copies or a limited number of copies.
  • the predetermined conditions identified in block 554 may include following an authentication procedure as outlined in Fig. 6, and may include authenticating a channel for delivery of content, checking a revocation list and unlocking content.
  • the unlocking is according to a method performed between an engine and a server as further explained below. Unlocking may entail, connecting with a server, following a protocol to retrieve a secure key, and using the secure key to unlock one or more portions of the content.
  • Block 556 provides for performing one or more of authenticating a channel, checking a revocation list and unlocking content.
  • Fig. 6 illustrates an embodiment of an authentication procedure 600.
  • the three components required for certification according to the present embodiment include media 602, engine 604 and host 606.
  • the host 606 holds a certificate 610 with protocol public key signed by a CA. Additionally, the host 606 holds a protocol private key 612.
  • the certificate 610 is received via a communication channel by the engine 604 and signatures on the certificate are verified at block 612.
  • a certificate is verified in two steps.
  • signatures are verified in block 612. In one embodiment, all but the last three fields are verified with the field CASignature and the public key specified by CASignaturePublicKeyld in block 612. Thus, the authenticity of these fields including CompanySignaturePublicKey is established.
  • Second, in block 612 the host is verified, which, in one embodiment the whole certificate is verified with CompanySignature and the CompanySignaturePublicKey.
  • the verification process is a double verification process.
  • the host is verified for revocation. Revocation is available at all of the levels of granularity of the certificate as implied by all of the fields. Part of the validation, in one embodiment, requires checking a revocation list 608 on media 602.
  • the engine 604 retrieves the revocation list 608 from the media 602. If the validation process 614 passes at block 616, the engine 604 generates a random number via random number generator 618 to obtain a first portion of a secure session key 620.
  • the engine 604 performs a public key encryption 622 using the first portion of the secure session key 620 and a protocol public key 624 retrieved from the certificate 610.
  • the host 606 receives the encrypted session key, decrypts the encrypted session key at block 626 and produces the secure session key 628.
  • Fig. 7A in combination with Fig. 3, the apparatus that performs the verification process is shown.
  • the apparatus is part of the engine 308.
  • Fig. 3 illustrates that a communication channel couples the engine 308 to a host holding a certificate 318.
  • the certificate 318 is received and an identifier 710, which could be implemented as a public key, is compared within the engine with a verify function 720.
  • the verify function 720 receives both the identifier and an output from a validation engine 730.
  • the validation engine 730 produces a global pass/fail indication that is output to the verify function 720.
  • the verify function 720 if it receives a fail indication from the validation engine 730, will deny further access to content.
  • Permissions block 750 includes multiple pass/fail permissions for the player 310 that are provided to validation engine 730. After processing the permissions, the validation engine 730 outputs a session key 780 permitting data delivery.
  • a method for certifying a device includes transmitting an encrypted identifier from the device via a communication channel and receiving a certificate identifying the device as one of an authenticated device and a non- authenticated device.
  • a method for securely delivering data across a channel is shown in flow diagram form.
  • the method for authenticating a destination for the data includes receiving a certificate from the destination in block 702 and, in block 704, using an identifier to qualify the destination.
  • the method continues in block 706 with transmitting a session key.
  • the session key allows the delivery of the data according to predetermined criteria in the certificate.
  • the certification procedure certifies and the authentication procedure authenticates hosts and engines. Authentication allows an entity to verify and validate another. The result of a successful authentication is that one entity knows the public key and other attributes of the other entity. Successful authentication also results in the establishment of an authenticated channel through which the allowed secure API's are exposed.
  • the host is one of a player, a player in a PC, a player in a device, a clearinghouse, a server, and a TPDRM application.
  • a revocation list is stored on media inserted into an engine. The revocation list is used in the validation process. Thus, if a known serial number for a device relates to a compromised or later rejected manufacturer, the host will not be authenticated.
  • the revocation list can be copied on each device to prevent the device from playing, or the revocation list can remain media dependent.
  • the revocation list may be maintained by a server such that players communicating with a server will receive updated revocation lists directly to the engine during changing state processes, such as unlock and lock.
  • a plurality of revocation lists are stored on media on a file by file basis, such that one or more files on the media may have a revocation list associated with the file.
  • Fig. 7C a method for revoking a content rendering device is provided.
  • Fig. 7C begins with block 712, wherein a revocation list is evaluated upon a file access.
  • each file may have one list, with duplicative entries being limited by centrally storing the details and providing each file with a list of identifiers or pointers that reference a location of complete details regarding revocation information.
  • the revocation information hereinafter referred to as a node, is centrally located with a unique identifier.
  • Each file may optionally have list node identifiers instead of storing complete revocation information.
  • the result for each node is stored.
  • the authentication process may include reading evaluation results rather than re-executing an evaluation, i.e., each node may be pre-evaluated.
  • the revocation list is copied onto the engine from media and could include a "poison pill" that prevents a player from working if it is not a proper player, if the manufacturer had defects, latent defects, or the like.
  • the revocation list can be updated, as shown in block 718, when a player is connected to a server to unlock data.
  • revocation of a content rendering device includes at least revocation of one or more signature keys.
  • the revocation of the one or more signature keys also revokes, in block 722, a set of CKDRM Certificates signed with the one or more keys. More specifically, the revocation of a signature key will revoke any corresponding signature.
  • the key signature list that is stored in non- volatile memory in an engine is not capable of update outside of a manufacturing process.
  • the key signature list may be revoked on a per-media basis by revoking a particular index value in the CA Signature Public Key ID field of the CKDRM Certificate.
  • revocation lists are used to provide a mechanism to prevent access to CKDRM methods for a given device or set of devices.
  • the CKDRM revocation method allows revocation to occur on any of the fields within the host certificate. Therefore, revocation may be as explicit as a single Device Identifier or Protocol Public Key, or as broad as an entire company, or perhaps a particular product line, or a particular product model as shown in block 724.
  • each file may have an associated revocation list.
  • the revocation list is associated with the file during a create-file command.
  • the revocation list is transmitted to the destination copy during the CKDRM Copy method.
  • a revocation list may be made up of a list of revocation nodes.
  • Each revocation node is made up of a list of clause nodes and a rule of how to combine the clauses to determine revocation for the node.
  • Each clause node is made up of a set of data and functions that define how to apply the data and evaluate them against the fields in a received CKDRM Certificate.
  • Block 732 provides for evaluation of the data in a clause node according to the function results of a true or false result when evaluated against the contents of a CKDRM certificate.
  • a set of results from the clause nodes are combined in block 734 according to the clause rules to result in a true or false result for the revocation node. If any revocation node in the revocation list evaluates to true, in block 736 the host is revoked.
  • Table 2E provides one exemplary embodiment of a revocation list.
  • Table 2F provides an embodiment of a revocation node structure. Table 2F
  • Table 2G provides an embodiment of a clause node structure to support multiple functions with a general format.
  • Table 2H provides for an exemplary clause node structure for a match function:
  • the revocation list for multiple files may contain revocation nodes that are already present on the media.
  • a revocation list may be maintained as an object within the DFS file system with a separate and distinct handle that is not a file or directory.
  • the Dfsld field may be used as a reference number for files to use in the RevocationldList field of the ContentKey metadata structure.
  • an exemplary revocation node structure may be that shown in Table 21.
  • a method performed by an engine when presented with a revocation list is provided.
  • Block 752 provides that during allocation of the CKDRM metadata, use the NodeCount value to create enough space in memory for a list of 16-bit identifiers that will reference each revocation node, h block 754, for each node in the revocation list, the engine compares the node to each node that is in the existing revocation list. In block 756, if an identical node is found, add the Dfsld number of the existing node to the RevocationldList in the CKDRM metadata structure. In block 758, if the node is not found, create a new node with a unique Dfsld. In block 762, the engine adds the new Dfsld value into the ContentKey metadata structure.
  • the evaluation method for revocation list results is explained in detail.
  • the revocation list is evaluated each time the CKCMD_AUTHENTICATE command occurs, or when a new piece of media is inserted into the engine.
  • the revocation list is evaluated against a received CKDRM Certificate.
  • the evaluation results in a revoked or not revoked status for that node. Because nodes are file dependent, these states are evaluated each time a CKDRM operation that is specific to a particular file is attempted.
  • revocation results are finalized not by CKCMD_AUTHENTICATE, but rather from CKCMD_DRM_PLAY, CKCMD_GET_METADATA, CKCMD_GET_PLAY__KEY, CKCMD_ PLAY, CKCMD_RECORD_APPEND, CKCMD_SET_KEYBOX, CKCMD_SET METADATA, and CKCMD UNLOCK FILES.
  • the commands are discussed in further detail below.
  • the results of evaluation are stored in a EvaluationResult field of the Revocation node structure.
  • the media disks discussed herein in an exemplary embodiment, organize content according to the method shown in Fig. 7G. As shown, the method begins with block 782, wherein content is organized on the media using a predetermined application.
  • the application uses a dongle attached to a machine that is running a tool. Within the dongle, an ASIC with an embedded random key generator may act as a secret key generator, h another embodiment, the application is not part of the mastering process, but is delivered as a DLL or library to third-party authoring houses. The DLL or library may require a third-party authoring house to authenticate itself to the DLL or library prior to creating CKDRM content.
  • the dongle and the application work together such that the dongle does not work except with a particular registered version of a DLL or library.
  • the application is responsible for content security by, as shown in block 784, creating a public identifier and a CKDRM identifier; in block 786, encrypting the content files; in block 788, adding engine-managed copy and play rules as specified by the content owner; in block 792, adding TPDRM specific rules as specified by the content owner; in block 794, adding a revocation list.
  • the functions performed by the mastering application may include a portion, all or one of the above-provided functions.
  • the application discussed above could be a part of a mastering, an authoring or a premastering portion of manufacturing a media disk.
  • the application includes a business method for creating locked and unlocked content on a disk wherein the mastering process is followed by an authoring process, followed by a premastering process.
  • the use of mastered content on the disk provides a method of detecting counterfeit disks posing as pre-mastered disks.
  • an identifier for pre-mastered disks has at least a portion of the identifier pre-mastered. This enables detection of identifiers posing as pre-mastered, as more fully explained herein.
  • Fig. 7H a process flow diagram presents one embodiment of a process flow for a process including a mastering process for creating media and setting up a clearing type server. The process begins at block 7002.
  • Block 7004 provides for a new release process for asset and information procurement.
  • Block 7006 provides that one or more of content files, metadata information, security information and package collection information is transferred to media.
  • Content files may include files that a consumer or user will play and any asset files tied to particular content, hi one embodiment, the process assumes that all files are encoded with a proper media coder- decoder (codec).
  • codec media coder- decoder
  • the metadata information provides a description of the assets that will accompany a content file.
  • the metadata information may include graphics and lyrics.
  • the information is provided in a structured format which may are may not be in a standard format for all content providers.
  • the metadata is on a per-track and per-media basis.
  • the security information transferred to the media provides rules governing the way the consumer or user can interact with the content.
  • the interactions with the content may include copying, rendering, and manipulating the content, as in, for example, placing notes in a margin or electronic highlighting of electronic books.
  • the rules provide a revocation list and TPDRM rules for a third-party digital rights management scheme.
  • the TPDRM rules provide the rules that the consumer may be restricted to regarding playing and copying content.
  • the TPDRM rules further include details such that authoring and mastering process as described herein receive data as to the files that are initially locked.
  • a revocation list is defined by a content provider, the revocation list providing a list of all player devices, player applications and servers that have been revoked for reasons determined by a revoking party.
  • the package collection information provides a specification as to how any secondary content is to be grouped and how it should be displayed to a user or consumer.
  • the package collection information must include specifications for each package, such as display images and package description.
  • Block 7008 provides for an authoring process wherein all the files provided by a content provider are packaged according to predetermined specifications.
  • the specifications include organizing the data in a directory structure such as a DataPlay MMF directory structure.
  • the structure requires directories containing encoded content files, a directory structure, a content manager, an autorun.inf and a contents.ddl file.
  • the content manager provides files that are used to present the content on media to a consumer or a user, such as an executable file, a mini-website, or a proprietary or form defined by a content provider.
  • the autorun.inf file provides data to the autorun handler as discussed herein and interacter therewith to launch the content manager.
  • the contents.ddl file may be stored within the MMF directory structure to be used with a TPDRM.
  • the contents.ddl file may include a package collection, advertisements and package SKUs. More particularly, a package collection may include a unique identifier for all secondary content on a side of a media and may contain a reference to one or more advertisements.
  • the advertisements may be grouped as a package and used by a presentation layer to display the secondary content and offers.
  • An SKU herein may be defiend by a content provider and reference one or more files on the media.
  • the MMF DDL files include files that describe the relationship between content and asset files.
  • Block 7012 provides for a pre-mastering process in which a master file set is stored and delivered on a media, such as a tape.
  • a media such as a tape.
  • each file set may provide a single side on a media disk.
  • Another process performed in the premastering process is generating a keyComplement.ddl file that configures a secure database, such as the CKDRM secure database.
  • the KeyComplement.ddl file may include a package collection identifier including a full file path, a file handle, a key complement such as a complement to a 128 bit number and a key version.
  • the premastering process includes passing the contents.ddl file.
  • Block 7022 and 7026 provide for passing the mastered file set on a media such as a tape to a glass master for stamping the content in manufacturing to produce, in block 7026, a media disk.
  • the glass masters create one or more stampers for mass producing the media disks that may be distributed to consumers or other users.
  • block 7020 provides that a master server receive data in a secure database.
  • a server process includes loading a key complement and package to a key mapping database table or tables with information specified in the keycomplementddl and contents.ddl files.
  • Fig. 71 the process described in Fig. 7H is performed with another process that may be performed at the same time as the process described in Fig. 7H. More particularly, Fig. 71 provides for creation of a package collection, packaged advertisements and SKUs to be provided during the process of Fig. 7H.
  • Block 7028 provides for a start of the process to set up an Internet retailer (eTailer).
  • Block 7030 provides for a content provider to perform a package setup and a change process "package definition.” More particularly, in blocks 7032 and 7034, content providers provide eTailers with a contents.ddle file 7034 and package display graphics and information 7032 that may be part of a package presentation to a consumer or user. Generally, eTailers are interested in a packageCollectionSKU. ETailers may not be interested in a PackageCollectionlD, which is passed to the eTailer via a URL. An eTailer may pass the PackageCollectionlD to a clearinghouse server and then discard.
  • Block 7036 provides that an eTailer sets up and changes pricing for packages received based on packages specified as available by a content provider, h one embodiment, the configuring a databse with package pricing and package presentation data is defined completely or in pertinent part by an eTailer such that the configuration conforms with an existing format of the eTailer, such as a "shopping cart," or "catalog maintenance" format.
  • Another configuration performed by an eTailer may include choosing to specify discount models and advertising. This embodiment enables an eTailer to advertise based on demographics and particular consumers and users.
  • a random number reaches the media via a mastering process.
  • a random number generator is also present within an engine.
  • each engine produced may include non-volatile memory holding a random number.
  • One method of generating the random number is by using high quality generation software, such as FIPS-186- compliant software.
  • the random number generator within an engine may be receptive to seeding by one or more techniques.
  • a seed may be a random number created at the time a master is created; a random number created upon manufacturing of the engine; a random number created and embedded in the firmware; a PubhcSideld; a number generated from a spin up time number; a number generated from a servo calibration time number; a seek time; BCA fields; a number generated from long-term collection data such as spin-up count, read/write error rate, or the like; a number generated from servo/read/write calibration values from manufacturing stored in the nonvolatile memory; a number generated from calculating read-write-read timing; a number generated from inputs to analog-to-digital converters; and any number that may be a function of any of the above numbers.
  • the host may be a Player, DRM, kiosk or server.
  • a destination engine is a host.
  • the primary functions include CKDRM play 312, TPDRM play 320,
  • CKDRM copy 330, TPDRM copy 340, record content 350 including recording locked content 364 and recording unlocked content 362 and CKDRM Unlock 360.
  • One media optionally holds both content 362 and 364 as pre-recorded CKDRM content.
  • the authoring, pre-mastering and mastering tools each play a role.
  • a content provider may specify the CKDRM properties including the lock/unlock state, play/no- play state, number of allowed CKDRM copies, number of allowed TPDRM copies, and the number of copies a TPDRM may make from its copy. Additional TPDRM rules may be specified for specific TPDRMs. Play Function More specifically, CKDRM play 312 permits unlocked, playable CKDRM content to play on any player.
  • the CKDRM play function delivers electronic content from an engine to a player along with the information needed to decrypt and render the delivered format.
  • the engine governs whether permissions exist for the play 312 function.
  • function 312 does not decrement a play count. Rather, play permissions for unlocked and playable CKDRM content are implicitly unbounded by count or time.
  • a flow diagram illustrates the API for the CKDRM play function 312.
  • the API requires that a player or host be certified following a certification procedure prior to opening the API.
  • the host is not allowed to store the content in any way that allows access to any other entity, even encrypted until the host is authenticated.
  • block 804 provides for a host to deliver a certificate qualifying a host.
  • An engine coupled to the host in block 806, transmits a session key. After authentication, the engine selects a decryption play session key 830.
  • Block 832 requires delivery of a play session key from the engine to the host, such as a player. A player receives this play session's decryption key for a specified file.
  • Block 834 provides that a host decrypts the play session key using a session key.
  • Block 840 provides that the player receives encrypted content.
  • Block 850 provides that the play session decryption key received at block 832 decrypts the content.
  • the TPDRM play 320 permits unlocked CKDRM content to play via a TPDRM.
  • the TPDRM play function 320 delivers electronic content from an engine to the TPDRM along with the information needed to decrypt and render the delivered format. The governance of whether permissions exist for this function is enforced by the TPDRM.
  • the CKDRM does not decrement play counts, check for time restrictions or any other governance. Rather, the TPDRM is capable of governing and/or changing its own metadata as part of its play function. Copy Function
  • CKDRM copy function 330 Another function is the CKDRM copy function 330.
  • Function 330 permits copying of pre-recorded, unlocked content from one media to another media when there are remaining copy permissions.
  • the CKDRM copy function 330 decrements the number of permissible copies remaining on an original media. More particularly, CKDRM, in one embodiment, provides for creating a limited number of copies. Any copies from media with a limited number of copies using the CKDRM copy function 330 share the qualities of the original copy in that they are playable in any player. The copies, however, may not themselves be copied.
  • a content provider optionally specifies the number of copies that may be made from an original. Each time a copy is made the CKDRM copy function 330 decrements the number of remaining allowed copies.
  • Block 910 provides for authentication of the destination engine. More specifically, a source engine makes sure that the destination is a valid engine so that secure content is not given out indiscriminately.
  • Block 920 provides that the destination engine delivers a media identifier to which the new copy is to be bound.
  • Block 930 provides for delivering of a key box for the destination. In block 930 the destination engine receives the keys necessary to use the content. In particular, these are the decryption keys for playing the content. In an exemplary embodiment, the keys are delivered pre-bound to the destination media.
  • Block 940 provides for copying the encrypted content. DFS commands are used for copying the content.
  • the copy function 330 is supported in environments with one engine and sufficient buffer for temporary storage of content, as well as in environments with two engines.
  • TDDRM copy function 340 permits unlocked content to be copied by a TPDRM if there are remaining TPDRM copy permissions.
  • the TPDRM copy function 340 decrements the number of permissible copies remaining for a source file.
  • TDDRM copy function 340 provides for creating a limited number of copies. The resultant copies are governed by the TPDRM.
  • a content provider may specify the number of copies that may be made from a file.
  • a certified TPDRM copies content from the domain of the CKDRM to the TPDRM.
  • the content delivered will be encrypted and the decryption key(s) will be delivered to the receiving DRM.
  • Block 1010 provides for host authentication. More specifically, as described above relative to Fig. 6, an engine verifies that a host is a certified DRM and trusted to receive content.
  • Block 1020 provides for allowing a TPDRM to specify the content the TPDRM is requesting to receive.
  • An engine governs the number of copies allowed for TPDRMs based on the initial number specified by a content provider and the number of copies previously delivered.
  • an engine responds to valid requests by delivering the keys with which the delivered content must be decrypted. The delivery of keys is a sufficient action for a TPDRM copy and decrements the number of remaining allowed copies.
  • Block 1040 provides that the TPDRM receives the content, encrypted with the key(s) just delivered. Record Function
  • Recording content 350 Another function provided by the CKDRM is recording content 350.
  • Recording content 362 permits content providers that author, pre-master and master content to provide electronic content that may be replicated as unlocked content. The data imported as unlocked is readable and encrypted.
  • recording content 364 permits content providers that author, pre-master, and master pre-recorded to provide content that may be replicated as locked content. This content is not playable until it is unlocked. The locked content may, however, be unlocked using the CKDRM, after which the content has the same qualities as unlocked content.
  • CKDRM record 350 further includes importing to the domain of CKDRM from a kiosk, player or a TPDRM. In this form, the content will play in any player.
  • Other types of CKDRM recording 350 include acquiring content through electronic distribution and playing the content on players.
  • Fig. 11 illustrates a method of recording content.
  • Block 1110 provides for a source, one of a TPDRM, player, server or kiosk, to be authenticated according to an authentication procedure.
  • Block 1120 provides that the source determine whether a file system write protocol or a CKDRM record protocol applies to the content to be imported.
  • portions of a file format that are to be encrypted and written with a CKDRM Record API are transmitted according to the CKDRM protocol.
  • portions that are to remain unencrypted are written with the file system API.
  • Governed content can be brought into the CKDRM domain in three ways.
  • One way is to use a TPDRM that governs the content and is capable of a handoff into CKDRM.
  • Another is to construct a server that governs the content and uses the CKDRM record protocol. In contrast to the CKDRM unlock method, recording requires transfer of all of the content information.
  • the third way is to construct a kiosk.
  • the kiosk in an embodiment, has its own engine and functions as a server with an engine.
  • Unlock Function CKDRM unlock 360 is another function shown in Table 3.
  • the unlock content 360 function applies only to locked content.
  • An application that can connect to a clearinghouse is required for the unlock transaction.
  • a secure method changes the state of the content on a media from locked to unlock.
  • locked content can be unlocked by authorized transactions.
  • the authorized transactions include those transactions following rules selected by a content provider. For example, a content provider may control whether content can be played and the number of copies that may be made by TPDRMs.
  • Content that is pre-recorded in a locked state can be unlocked.
  • in the locked state the set of keys on the media are not sufficient to render the content.
  • the unlock method delivers the complement of the keys.
  • the unlock method delivers data that matches the keys on the media to prove the authenticity of the clearing house. This data may also be referred to as key complements.
  • Figure 12 illustrates a method of unlocking content. More specifically, block 1210 provides that a first step in the method is mutual authentication of both source and destination.
  • Block 1220 provides that a source, such as a server, retrieve a media identifier to which the content is bound.
  • Block 1220 provides that the source specifies the content to be unlocked and the complement of encryption keys.
  • Block 1230 provides that the destination, such as an engine, govern the validity of the request based on the specifications from a content provider via a server.
  • the server performing the unlocking must be specified as a legitimate unlocking source by the content provider at the time of authoring or mastering the media on which the content is stored.
  • a default function of CKDRM is governed by the file system 374 of Table 3, above.
  • the file system allows access at the file level.
  • the file system API does not participate in rules governance or the encryption methods used by the CKDRM.
  • the file system functions include a file read 372. More particularly, only data in the file storage area may be read by any device via the file system.
  • an engine interface and the file system are open architectures, with a file system API that is open without requiring an authenticated host.
  • the file read 372 may be used by any host, such as a player, to access data without establishing an authenticated connection and without using cryptographic methods that may be in an engine.
  • Write function 374 identifies a file system write function, whereby a device writes data into the file storage area through the file system API.
  • the write function 374 is optionally part of an open architecture such that an engine interface and the file system are open and the file system API is open, obviating the need for an authenticated host.
  • the file write function 374 may be used by any host to store data without establishing an authenticated connection and without using an engine's cryptographic methods. Methods performed by the Engine
  • An engine performs these functions in conjunction with other parts of the SEC system as described above with reference to Fig. 2.
  • An engine as referred to herein, is a component that provides read and write access to digital media.
  • the engine may reside in a host or be coupled to a host and performs the functions using commands that one of skill in the art will appreciate are exemplary in nature and can be defined according to system and design requirements. Additional functions between components and applications in a host application are within the scope of the present invention.
  • the term host application may refer to the device to which the engine is directly attached, an application on a connected device such as a PC, or a server implementing the CKDRM clearinghouse.
  • Each of the methods of a protocol includes either or both CKDRM and file system commands.
  • the methods described below are available to any certified entity as limited by the entity's certificate.
  • Devices embedding an engine are required to expose the file system and CKDRM APIs through data I/O interfaces implemented by the device. In one embodiment, exposing the file system and CKDRM APIs allows a device embedding an engine to act as a surrogate for another entity.
  • FIG. 13 illustrates an exemplary embodiment for obtaining a secure session via an authentication procedure.
  • Block 1320 provides that the secure session key is transferred under asymmetric cryptography.
  • the session key is a symmetric key, thereby allowing for fast encryption and decryption of data.
  • Block 1340 asks whether a host change occurred or if media was ejected from a device. When block 1340 is true, the secure session is ended in block 1350. If false, the secure session continues in block 1360. Thus, a secure session is unique to a particular host, engine and media combination.
  • the engine firmware provides functionality to the CKDRM and TPDRM methods, including lock/unlock, CKDRM play, CKDRM copy permissions, and CKDRM copy permissions. For CKDRM and TPDRM copy permissions, the engine allows one of copy freely, counted first generation copies and unlimited first generation copies.
  • a secure session enables an engine to enter the CKDRM domain, including performing the CKDRM and TPDRM functions.
  • the CKDRM functions performed by an engine follow protocols. Each protocol from the perspective of an engine is explained in further detail below.
  • Fig. 14 illustrates an engine performing a CKDRM Copy method that copies content within the CKDRM domain.
  • a source engine 1410 holds governed content that is within the CKDRM domain.
  • a source file 1420 may be designed to such that source fiel 1420 must be unlocked and have remaining CKDRM copy permissions before the method continues.
  • the status of source file 1420 is irrelevant, for example, in superdistribution models.
  • the destination 1440 is the CKDRM domain.
  • the resulting copy 1430 will be governed content and the file will be unlocked and have CKDRM play permissions but no CKDRM copy permissions.
  • a key box 1450 is transferred.
  • the source file 1420 decrements remaining CKDRM copy permissions.
  • a secure session is established between, for example, two engines, a source engine 1410 and destination engine 1440.
  • source engine 1410 runs a secure API and is exposed only to hosts with CKDRM Copy permissions.
  • the destination engine 1440 includes an open API.
  • the method is exposed to all hosts.
  • Each engine has a host.
  • a single device may be the host for both the source and destination engines, or each engine may have a different host. In the latter case, the two hosts must communicate according to a host protocol.
  • the CKDRM Copy protocol uses commands that one of skill in the art appreciates are exemplary in nature, but are provided for purposes of explanation.
  • the protocol uses the CKDRM commands CKCMD_AUTHENTICATE and CKCMD_GET_CKDRM_COPY.
  • the command CKCMD_AUTHENTICATE provides that the destination engine 1440 authenticates itself to source engine 1410 to establish the trust that source engine must have in the destination engine to allow CKDRM methods to be used.
  • the source host sends the destination engine's CKDRM certificate in the command packet.
  • the source engine responds with the session key for the secure session.
  • a key box is requested for a specified file and destination.
  • the source engine 1410 returns the key box 1450 and a revocation list for the file and the destination.
  • CKDRM record Another method performed by an engine is the CKDRM record, which provides a method of bringing content into the CKDRM domain. The method assumes that a source is governed content that is outside the CKDRM domain. The destination is the CKDRM domain. The resulting copy is governed content.
  • the CKDRM Record method begins with establishing a secure session between an engine and a host.
  • the method is a secure API that is exposed only to hosts with CKDRM record permissions.
  • CKCMD_RECORD_APPEND are included in the record protocol. More particularly, CKCMD_AUTHENTICATE provides that the host supplying the content authenticates itself to an engine to establish the trust that the engine must have in the host to allow CKDRM methods to be used. Accordingly, the host sends its CKDRM certificate in a command packet, and the engine responds with the session key for the secure session.
  • the command CKCMD__GET_CERTIFICATE directs the host supplying the content to authenticate the engine to establish the trust that the host must have in the engine to allow content to be sent.
  • the engine sends its CKDRM certificate in the data transfer.
  • the command CKCMD_CREATE_FILE creates a new CKDRM file. More particularly, the host specifies the record session key for transferring content and the content is transferred with CKCMD_RECORD_APPEND commands from the host to the engine.
  • the command packet sent by the host includes basic DFS elements including the location in the directory structure and the file name, which may be explicitly specified in the command packet.
  • the command packet further explicitly specifies CKDRM rules and a revocation list.
  • the balance of the command packet includes other objects in a file that may be set to defaults and may be modified using DFS commands, h one embodiment, the received content is appended to the end of the file. From the viewpoint of a host, the record scenario is described with reference to Fig. 15.
  • a host application determines the file to import into CKDRM and its directory path.
  • the host determines the attributes of the file to be created including its directory path, file name, attributes, MIME type, CKDRM permissions, revocation list, allowed CKDRM copies and allowed DRM copies.
  • the host determines the DFS handle of the destination directory.
  • the host issues the command CKCMD_AUTHENTICATE to initiate a secure session between the host and the engine. Certificate is set to the host's CKDRM certificate.
  • the engine returns the secure session key in ESessionKey.
  • the host issues CKCMD_GET_CERTIFICATE to authenticate the engine. Certificate is set to the engine's CKDRM certificate.
  • the host verifies the engine and extracts its public key.
  • the host creates the destination file using CKCMD_CREATE_FILE.
  • the created destination file includes data that controls the use of the file.
  • the data optionally includes information such as: the handle of the destination directory; the length of the revocation list; the encoded CKDRM permissions and attributes; the allowed CKDRM copies; the allowed DRM copies; the encrypted secure session key; and the value which is the ESessionKey value returned by the engine for CKCMD_AUTHENTICATE.
  • Additional data includes the encrypted record session key selected by the host; the message authentication code calculated by the host for the revocation list data; the message authentication code calculated by the host for the command packet; the name of the file encoded as a DFSNAME data type; and the revocation data associated with the file.
  • the host issues a DFSCMD_GETHANDLE command to retrieve the handle for the newly created file.
  • the host sets the attributes and MIME type to the correct state.
  • the host writes the content to the file using one or more CKCMD_RECORD_APPEND commands.
  • the CKCMD_RECORD_APPEND command includes the following fields: RecordOptions, which may have
  • ERecordKey must always be the same and the data must always be the content encrypted with the single record session key represented by the single ERecordKey value.
  • the ErecordKey may change for each CKCMD_RECORD_APPEND command.
  • CKDRM Play is a method of playing content governed by CKDRM. As shown in Fig. 16, a source is governed content that is within the CKDRM domain. According to the method, the source file must be unlocked and have CKDRM play permissions. The destination is a host acting in the role of a Player.
  • the CKDRM play protocol first establishes a secure session between an engine and a host.
  • the CKDRM Play method is a secure API and is exposed only to hosts with CKDRM Play permissions.
  • the CKDRM Play protocol uses the commands CKCMD_AUTHENTICATE, CKCMD J3ET_CKDRM_PLAY_KEY and CKCMD_PLAY.
  • the method begins in block 1610 with the command CKCMD_AUTHENTICATE which directs the host Player to authenticate itself to the engine to establish the trust that the engine must have in the destination to allow CKDRM methods to be used.
  • the host sends its CKDRM certificate in the command packet.
  • the engine responds in block 1630 with the session key for the secure session.
  • the command CKCMD_GET_CKDRM_PLAY_KEY directs that the CKDRM Play permissions be checked.
  • the play session is established and the play session key is returned for a specified file.
  • the command CKCMD_PLAY directs the engine to return the content from the specified file.
  • Fig. 17 illustrates a more detailed play method using the commands described above.
  • a Player determines the file to play.
  • a user inserts the source media in the engine and the host, in block 1720, issues a CKCMD_AUTHENTICATE command to initiate a secure session between the engine and the host.
  • the certificate is set to the host's CKDRM certificate.
  • the engine returns the secure session key in ESessionKey.
  • the host issues a CKCMD_GET_CKDRM_PLAY_KEY command to establish a play session and get the play session key for the file.
  • the ESessionKey is the encrypted secure session key, and holds the same value as the ESessionKey value returned by the engine for CKCMD_AUTHENTICATE.
  • the engine returns the play session key in EplayKey.
  • the host issues one or more CKCMD_PLAY commands to retrieve the contents. In response, the engine returns the contents in block 1780.
  • the CKCMD Play command provides that the contents are retrieved and does not stop retrieving due to unrecoverable errors. More specifically, in one embodiment, a field PlayOptions is set with PLAY_STREAMING asserted, which provides for streamed play and no stopping on a play error. Additionally, with the command PLAY_TO_EOF asserted, the content is played to the end of file, ignoring the ByteCount field.
  • the CKDRM for the play commands works with the DFS API.
  • the command PlayFile is a DFS command that is set to specify the DFS handle of the file to play.
  • the Play function ESessionKey is the encrypted secure session key, and the same value as the ESessionKey value returned by the engine for CKCMD_AUTHENTICATE.
  • Other useful data fields include ByteOffset, which is set to zero to start the play at the start of the file; and ByteCount, which may be set to the number of bytes the host wishes to receive.
  • CKDRM Unlock is a method of changing the state of a CKDRM file from locked to unlocked.
  • the target is governed content that is within the CKDRM domain.
  • the target file will be unlocked.
  • the permissions and metadata are otherwise unchanged.
  • Fig. 18 illustrates the protocol for CKDRM Unlock.
  • the commands used in the protocol include CKCMD_AUTHENTICATE, CKCMD_GET_CERTIFICATE and CKCMD_UNLOCK_FILES.
  • the security required for the unlock mandates that a secure session exist between an engine and a host.
  • the CKDRM Unlock method is a secure API and is exposed only to hosts with CKDRM Unlock permissions.
  • the host After the host determines the files to unlock in block 1860, the host, in block 1862 gets the handles for the locked files in the form of a list.
  • the list is obtained by traversing the directory structure and noting all of the files whose attributes indicate that the file is locked.
  • the associations format also specifies the locked content and some information about offer packages.
  • the host application issues the CKCMD_AUTHENTICATE command to authenticate itself to the engine and initiate a secure session. Certificate is set to a clearinghouse server's CKDRM certificate.
  • the engine returns the secure session key in field ESessionKey.
  • the host issues the command CKCMD_GET_CERTIFICATE to authenticate the engine. Certificate is set to the engine's CKDRM certificate.
  • the host verifies the engine and extracts its public key.
  • the command CKCMD JJNLOCKJFILES directs that the host specify the files to unlock.
  • the number of files to unlock is specified in a FileCount field in the data transfer.
  • the DFS handles of the files to unlock are specified in the Handle field of the FileSet array of the data transfer.
  • the engine modifies the Lock attribute of the files specified by field FileSet.
  • FileCount which is set to the number of files to unlock
  • EunlockKey which is the encrypted unlock key for the encryption and decryption of key complements
  • Emediald which is the encrypted media identifier and the public media identifier of the destination media
  • FileSet which is set to the list of identifiers of the files to unlock, including the DFS handle of the file in each entry
  • EKeyComplement field which is the encrypted key complement, where the key complement comes from the appropriate database.
  • the unlock key is used to encrypt the key complement values.
  • the field DataMac is set to the hash of FileSet field of the data packet.
  • the host application checks whether the transaction was successful by getting the state of the files that were to be unlocked. TPDRM Copy
  • TPDRM Copy is a method of sending governed content out of the CKDRM domain.
  • the source is governed content that is within the CKDRM domain.
  • the source file must be unlocked and have TPDRM copy permissions.
  • the TPDRM copy permissions include either a non-zero TPDRM Copy Count value, a TPDRM Copy Freely state, or an Unlimited First Generation TPDRM Copy state.
  • the destination is the domain of a TPDRM.
  • the resulting copy is governed content governed by the destination TPDRM.
  • the source file's remaining TPDRM Copy Count is decremented during the CKCMD_GET_DRM_COP Y command, if necessary.
  • Fig. 19 illustrates the TPDRM Copy protocol.
  • the TPDRM Copy requires a secure session between an engine and a host.
  • the TPDRM Copy method is a secure API and is exposed only to hosts with DRM Copy permissions.
  • DRM Copy protocol uses commands CKCMD_AUTHENTICATE, CKCMD_GET_METADATA, CKCMD_GET_DRM_COPY and CKCMD_PLAY.
  • the command CKCMD_AUTHENTICATE directs the TPDRM to authenticate itself to the engine to establish the trust that the engine must have in the TPDRM to allow CKDRM methods to be used.
  • the host sends the TPDRM' s CKDRM certificate in the command packet.
  • the engine responds with the session key for the secure session.
  • the command CKCMD_GETJvIETADATA directs that the TPDRM retrieve secure metadata associated with the file to be played.
  • the engine returns a key for decrypting the metadata.
  • the engine also returns, in block 1950, the encrypted metadata.
  • the command CKCMD_GET_DRM_COPY directs that the engine checks TPDRM Copy permissions, establish the play session and return the play session key and revocation list for a specified file.
  • the command TPDRM Copy Count directs that the value for the file be decremented, if necessary.
  • the command CKCMD_PLAY directs that the engine return the content from the specified file.
  • Fig. 20 illustrates an exemplary method of the TPDRM Copy.
  • the TPDRM application determines the set of files to copy, hi block 2010 a user inserts the source media in the engine.
  • the host issues a CKCMD_AUTHENTICATE command to initiate a secure session between the engine and the host.
  • the certificate is set to the TPDRM' s CKDRM Certificate.
  • the engine returns the secure session key in ESessionKey.
  • the host TPDRM' s CKDRM Certificate includes a Metadataldentifier field.
  • the host issues a CKCMD_GET_METADATA command to retrieve the TPDRM' s secure metadata associated with the file.
  • AssociatedFile is set to the DFS handle of the associated file, the file to copy.
  • ESessionKey is the encrypted secure session key, and has the same value as the ESessionKey value returned by the engine for CKCMD_AUTHENTICATE.
  • the engine returns Metadata, i.e., the metadata associated with the file specified by AssociatedFile and with the TPDRM specified by the certificate received in the CKCMD_AUTHENTICATE command.
  • the TPDRM enforces TPDRM governance rales, including the rules specified by its metadata, and determines whether there currently are copy permissions for the TPDRM for the file. In an embodiment of the method, the TPDRM must not copy the content if there are no copy permissions.
  • the host issues a CKCMD_GET_DRM_COPY command to establish the play session and get the play session key for the file.
  • the field SourceFile is the DFS handle of the file to be copied.
  • the engine returns the play session key in EPlayKey, and the revocation list in RevocationList.
  • the host issues one or more CKCMD_PLAY commands to retrieve the contents.
  • the fields of the play commands include: PlayOptions,which is set with PLAY_STREAMING deasserted (play normal; stop on play error) and PLAY_TO_EOF asserted (play to the end of the file; ignore the ByteCount field); PlayFile, which is set to specify the desired file, which may be the DFS handle of the file to copy; ByteOffset, which is set to zero to start the play (copy) at the start of the file; ByteCount, which may be set to any value; and EsessionKey, which is the encrypted secure session key, and the same value as the ESessionKey value returned by the engine for CKCMD_AUTHENTICATE. In block 2090, the engine returns the content.
  • PlayOptions which is set with PLAY_STREAMING deasserted (play normal; stop on play error) and PLAY_TO_EOF asserted (play to the end of the file; ignore the ByteCount field
  • PlayFile which is set to specify the desired file, which may be the
  • Read Secure Metadata is a method of accessing content that is in the CKDRM domain and owned by a third party.
  • the associated file must be unlocked.
  • the metadata is associated with the file and with the host identified for the secure session.
  • the protocol first establishes a secure session between an engine and a host.
  • the Read Secure Metadata method is a secure API and is exposed only to hosts with Read Secure Metadata permissions.
  • Fig. 21 illustrates the Read Secure Metadata Protocol.
  • the Read Secure Metadata protocol uses the commands CKCMD_AUTHENTICATE and CKCMD_GET_METADATA.
  • the command CKCMD_AUTHENTICATE directs the host to authenticate itself to the engine to establish the trust that the engine must have in the destination to allow CKDRM methods to be used.
  • the host sends its CKDRM certificate in the command packet.
  • the engine responds with the session key for the secure session.
  • the command CKCMD_GET_METADATA directs the host to read its secure metadata associated with the file, h response, the engine returns a key for decrypting the metadata and also returns the encrypted metadata.
  • the host first determines the file associated with the metadata to be read. Accordingly, the exchange includes, in block 2120, a user inserting the source media in the engine.
  • the host issues a CKCMD_AUTHENTICATE command to initiate a secure session between the engine and the host. The certificate is set to the host's CKDRM certificate.
  • the engine returns the secure session key in ESessionKey.
  • the host issues a CKCMD_GET_METADATA command to retrieve the host's secure metadata associated with the file.
  • the field AssociatedFile is set to the DFS handle of the file with which the metadata is associated.
  • the field ESessionKey is the encrypted secure session key, and holds the same value as the ESessionKey value returned by the engine for
  • the engine returns Metadata, the metadata associated with the file specified by AssociatedFile and with the host specified by the certificate received in the CKCMD_AUTHENTICATE command.
  • Write Secure Metadata The Write Secure Metadata provides a method asserting content that is in the
  • the metadata is associated with the file and with the host identified for the secure session.
  • the protocol establishes a secure session between an engine and a host.
  • Write Secure Metadata method is a secure API and is exposed only to hosts with Write Secure Metadata permissions.
  • the Write Secure Metadata protocol uses the commands
  • command CKCMD_AUTHENTICATE directs a host to authenticate itself to an engine to establish the trust that the engine must have in the destination to allow CKDRM methods to be used. In response, the host sends its
  • the engine responds with the session key for the secure session.
  • the command CKCMD_GET_CERTIFICATE directs the host supplying the content to authenticate the engine to establish the trust that the host must have in the engine to allow content to be sent.
  • the engine sends its CKDRM certificate in the data transfer.
  • the command CKCMD_SET_METADATA directs the host to write its secure metadata associated with the file.
  • the host sends a key for decrypting the metadata and the encrypted metadata.
  • Fig. 22A illustrates the protocol for the Write Secure Metadata method, hi block
  • the host first determines the file associated with the metadata to be written.
  • a user inserts the destination media in the engine.
  • the host issues a CKCMD AUTHENTICATE command to initiate a secure session between the engine and the host.
  • the certificate is set to the host's CKDRM certificate.
  • the engine returns the secure session key in ESessionKey.
  • the host issues CKCMD_GET_CERTIFICATE to authenticate the engine.
  • the certificate is set to the engine's CKDRM certificate.
  • the host verifies the engine and extracts its public key.
  • the host issues a CKCMD_SET_METADATA command to send the host's secure metadata associated with the file.
  • the field AssociatedFile is set to the
  • the field ESessionKey is the encrypted secure session key, and same value as the ESessionKey value returned by the engine for CKCMD_AUTHENTICATE.
  • the field Metadata is the metadata associated with the file specified by AssociatedFile and with the host specified by the certificate received in the CKCMD_AUTHENTICATE command.
  • the following commands, RECORD_APPEND, PLAY, GET_DRM_PLAY_KEY, GET_DRM_COPY, GET_CKDRM_PLAY_KEY, GET_CKDRM_COPY and CREATE_FILE each include as part of their protocol a consideration of a media identifier.
  • One media identifier is a unique identifier that is created during the mastering or pre-mastering process of a media. It may be unique for a master or for each media, depending on design requirements.
  • Another media identifier is a unique identifier that is created during field use of the media. It is unique for each media, e.g., media disk.
  • the media identifier may be pre-recorded on a disk for content that was mastered or pre-mastered, or the like. Further, in each case, the media identifier may be written on media, such as a disk, for content that was written.
  • the pre-recorded media identifier may, therefore, exist only in that portion of media dedicated to mastered/pre-mastered content, and the written media identifier will exist only in that portion of a media dedicated to written information. Referring to Table 4B, below, the types of identifiers that are possible in the SEC system are provided.
  • identifiers there are four types of identifiers including pre-recorded identifiers for prerecorded content, pre-recorded identifiers for written content, written identifiers for prerecorded content and written identifiers for written content.
  • Pre-recorded locked content and pre-recorded locked content that was later unlocked uses only the media identifier that was pre-recorded.
  • the SEC system uses two of the four types of identifiers, so the existence of the other two types indicates a counterfeit disk.
  • the media identifier is a unique identifier that is created during the mastering or pre-mastering process for media. It may be unique for a master or for each disk, depending on design requirements, hi each case, however, the media identifier will be pre-recorded on a disk if the content was mastered or pre- mastered, or the like.
  • the media identifier will, therefore, exist only in that portion of a disk dedicated to mastered/pre-mastered content.
  • Table 4C the types of identifiers that are possible in the SEC system are provided. As shown, there are four types of identifiers, including pre-recorded, hybrid with both pre-recorded and written components to the identifiers, written-only identifiers, and counterfeit.
  • the media types for the four types of identifiers include media holding pre-recorded locked content that was later unlocked, media holding only unlocked content, and those holding a mixture of both types.
  • the identifier for the content has a portion of the identifier that is pre-recorded and a portion of the identifier that is written.
  • the identifier will always have a pre-recorded identifier associated with it.
  • Block 2202 provides for performing a key box lookup.
  • Block 2204 provides for retrieving the key box for a file.
  • the key box is encrypted and bound to a location.
  • an engine determines whether the media identifier should be written or pre-recorded according to the action desired by the command.
  • the key box binding identifier flag is compared with a key box read method, however, the implementation depends on the command chosen. Further, in block 2208, the method according to the command chosen is compared against the associated media identifier for the command and/or an identifier flag associated with the media identifier. If the identifier or identifier flag is not pre-recorded for those identifiers that require a pre-recorded identifier or flag, block 2212 provides for a revocation of some or all of the functionality of the command.
  • an identifier that is a counterfeit will identify itself to an engine as a pre-recorded identifier, when, in fact, the identifier is located in a portion of a disk for written content.
  • the determination by the engine of whether the identifier is pre-recorded or written will depend on how the identifier identifies itself as well as the location of the identifier on the media. Thus, counterfeit media disks will be prevented from full functionality.
  • the first part of each entry is the state of the DFS permission attribute, and the second part is the state of the field in the DFS Attribute Modification Mask. When the Attribute Modification Mask is off further changes to the permission attribute are disallowed.
  • CKDRM Commands discussed above are part of the CKDRM and function according to the tables provided below:
  • CKCMD_AUTHENTICATE Verifies and validates host authenticity and establishes a secure session.
  • any host is allowed access to CKCMD_AUTHENTICATE.
  • the host must deliver a valid CKDRM Certificate for the command to be successful. Any current secure session is broken. A successful execution results in a new current secure session.
  • the parameters for the command and the settings include: HostCmd set to DPICMD_CK_COMMAND; CkSubCmd is set to CKCMD_AUTHENTICATE; Certificate is set to the host's CKDRM certificate; and ESessionKey is the secure session key encrypted using Protocol Public Key from the host's CKDRM Certificate. An implicit authentication occurs if the host can correctly decrypt ESessionKey.
  • the authenticate command causes a host to deliver its CKDRM certificate to the engine.
  • the engine verifies and validates the certificate.
  • the engine also extracts the method permissions.
  • the engine creates a secure session key and saves the key and the host certificate.
  • the host becomes the current host for the secure session and subsequent CKDRM commands.
  • initiating the authenticate command terminates any existing secure session.
  • a successful command initiates a new secure session.
  • the ESessionKey value also serves as the secure session identifier.
  • CKCMD_GET_CERTIFICATE Transfers the engine' s CKDRM certificate to the host.
  • the parameters used by the command include: HostCmd set to DPICMD_CK _COMMAND; CkSubCmd set to CKCMD_GET_CERT CATE; Certificate, i.e., the engine's CKDRM certificate.
  • the CKCMD_GET CERTIFICATE command transfers the engine's CKDRM certificate to the host so that the engine's certificate may be sent to another engine (through CKCMD_AUTHENTICATE) as part of the CKDRM Copy method, Record method, Write Metadata method and Unlock method, as required.
  • CKCMD_CREATE_FILE Checks CKDRM Record permissions, creates a new CKDRM file object within the given directory and establishes a write/record session.
  • the command CKCMD_CREATE_FILE requires a current secure session. Only hosts with CKDRM Record method permissions are allowed access to CKCMD_CREATE_FILE. Parent must specify a directory with write permissions.
  • the parameters of the command with settings includes: HostCmd is set to
  • RevocationByteCount is the number of bytes to expect in the data phase of the command
  • CKDRMState are the CKDRM attributes and permissions of the file.
  • the member fields of the CKDRMState field is specified by the CKDRMState Fields table.
  • CKDRMCopies specifies the number of CKDRM copies that are allowed for the file.
  • the CKDRM Copy method must be allowed to make use of a non-zero value.
  • DrmCopies specifies the number of DRM copies that are allowed for the file. This is the initial value of the DRM Copy Count value.
  • the DRM Copy method must be allowed to make use of a non-zero value.
  • ESessionKey is the current secure session key and is related to the CKDRM method CKCMD_AUTHENTICATE.
  • ERecordKey is the record session key for this file and is encrypted with the engine's public key. This is the ERecordKey value that must be used for all
  • RevocationMac is the message authentication code of the data phase.
  • CommandMac is the message authentication code for the command packet. It is calculated over the preceding fields of the command packet, bytes 0 through 67, inclusive.
  • Name is the DFS name of the file.
  • RevocationList is the revocation list for the file.
  • the command CKCMD_CREATE_FILE creates a CKDRM file object in the specified directory.
  • the file initially has a file length of zero.
  • the handle for the created file may be obtained using the DFSCMD_GETHANDLE command.
  • the handle is used in subsequent CKCMD_RECORD_APPEND commands.
  • the file attributes, and MIME type are set to default values.
  • the CKDRM metadata is set as specified by the CKDRMState, CKDRMCopies, DrmCopies and RevocationList fields.
  • CKCMD_GET_CKDRM_COPY Checks CKDRM Copy permissions and transfers the key box for a particular file and destination identifier. Decrements the CKDRM Copy Count for the file, if necessary. The transfer is from the engine to the host.
  • the command CKCMD_GET_CKDRM_COPY functions only during a current secure session. Only hosts with CKDRM Copy method permissions are allowed access to CKCMD_GET_CKDRM_COPY.
  • Sourcefile must have either a nonzero CKDRM Copy Count value, a CKDRM Copy Freely state or an Unlimited First Generation CKDRM Copies state, h one embodiment, CKCMD_GET_CKDRM_COPY is allowed for locked files or files with zero copy counts in cases in which the destination file is marked as locked.
  • HostCmd is set to DPICMD_CK_COMMAND
  • CkSubCmd is set to CKCMD_GET_CKDRM_COPY
  • SourceFile is the DFS handle for the file for which to get the key box
  • CKDRMId is the identifier the destination to which the delivered key box belongs. The identifier must be the delivered results of a CKCMD_GET_CKDRMJD command to the destination engine.
  • ESessionKey is the current secure session key.
  • KeyBox is created by the engine. KeyBox is the keys and revocation list for the file specified by SourceFile and the destination specified by CKDRMId. The engine returns KeyBox to the host.
  • the command CKCMD_GET_CKDRM_COPY is used during the CKDRM Copy method to obtain a key box which may be delivered to a destination.
  • This key box is associated with SourceFile. It provides the necessary information for accessing (playing) the content that is secured in the file in the copy that resides at the destination. If SourceFile has a CKDRM Copy Freely state then the resulting copy also has a CKDRM Copy Freely State. Otherwise, the resulting copy has no CKDRM copy permissions.
  • SourceFile has an Unlimited First Generation CKDRM Copy state then the CKDRM Copy Count is unchanged. Otherwise, if the CKDRM Copy Count is not zero then the CKDRM Copy Count is decremented by the engine and stored back to the media prior to completion of the command. Delivery of KeyBox is associated with decrementing the Copy Count.
  • SourceFile has a CKDRM Copy Freely state then the resulting copy also has a CKDRM Copy Freely State. Otherwise, the resulting copy has no DRM copy permissions.
  • the field KeyBox must subsequently be delivered to the destination engine to complete the CKDRM Copy transaction as described by the CKDRM Copy Method section.
  • CKCMD_GET_CKDRMJD Returns information for the currently inserted media.
  • Table 19 Command Initiation
  • the command CKCMD_GET_CKDRM_ID allows any host access to CKCMD_GET_CKDRM_ID.
  • the engine must have media inserted.
  • HostCmd which may be set to DPICMD_CK_COMMAND.
  • CkSubCmd which may be set to CKCMD_GET_CKDRM_ID.
  • ESessionKey is the current secure session key.
  • CKDRMId represents the identifier for the currently inserted media and the current secure session.
  • CKCMD_GET_CKDRM_TD returns information specific to the media and is used by various CKDRM methods to provide media-specific information.
  • Other identifiers such as a public media identifier are available through the DFS API.
  • CKCMD_GET_CKDRM_PLAY_KEY Checks CKDRM Play permissions and establishes a play session.
  • the command requires a current secure session. Further, only hosts with CKDRM Play method permissions are allowed access to CKCMD_GET_CKDRM_PLAY_KEY. PlayFile must specify a file that is unlocked and has CKDRM Play and DFS Read permissions.
  • the parameters used by the command include: HostCmd set to DPICMD_CK_COMMAND; CkSubCmd set to CKCMD_GET_CKDRM_PLAY_KEY; PlayFile is the DFS handle for the file for which the play session key is to be returned; ESessionKey is the current secure session key. EPlayKey is the play session key encrypted with the secure session key. The play session key is specific to the file specified by PlayFile. More particularly, the play session key is the key with which the file will be encrypted in the subsequent CKCMD_PLAY commands for PlayFile.
  • CKCMD_GET_CKDRM_PLAY_KEY transfers the decryption key for a particular file from the engine to the host.
  • the command must be issued prior to every CKDRM play session.
  • the key value selected is used for the duration of the play session.
  • the host must not assume that the key will be the same for the file each time it is played off the media.
  • the content of the file in the form that can be decrypted by the play session key may be obtained through the CKCMD_PLAY command.
  • CKCMD_GET_DRM_COPY Checks TPDRM Copy permissions and establishes a play session. Decrements the TPDRM Copy Count value, if necessary.
  • CKCMD_GET_DRM_COPY requires a current secure session. Only hosts with TPDRM Copy method permissions are allowed access to CKCMD_GET_DRM_COPY.
  • SourceFile must specify a file that is unlocked. Source file must have either a non-zero TPDRM Copy Count value, a TPDRM Copy Freely state or an Unlimited First Generation TPDRM Copies state.
  • CKCMD_GET_DRM_COPY and settings include: HostCmd is set to DPICMD_CK_COMMAND; CkSubCmd is set to CKCMD_GET_DRM_COPY; SourceFile is the DFS handle for the file for which to get the key; ESessionKey is the current secure session key.
  • the field EPlayKey is the play session key encrypted with the secure session key.
  • the play session key is specific to the file specified by SourceFile. That is, the play session key is the key with which the content is encrypted in subsequent CKCMD_PLAY commands for SourceFile.
  • RevocationList is the revocation list for the file.
  • CKCMD_GET_DRM_COPY is used to obtain the key for a file. It is used in the DRM Copy method. If the DRM Copy Count value associated with the file is not zero then the DRM Copy Count is decremented and rewritten to the media prior to completion of the command.
  • CKCMD_GET_DRM_COPY is used during the DRM Copy method to obtain a play session key which may be stored along with the contents from a CKCMDJPLAY command. The files revocation list is also obtained and must be delivered whenever this content is imported to CKDRM. If SourceFile has a CKDRM Copy Freely state then the resulting copy also has a CKDRM Copy Freely State. Otherwise, the resulting copy has no CKDRM copy permissions. If SourceFile has a TPDRM Copy Freely or Unlimited First Generation CKDRM Copy state then the
  • TPDRM Copy Count is unchanged. Otherwise, if the TPDRM Copy Count is not zero then the TPDRM Copy Count is decremented by the engine and stored back to the media prior to completion of the command. Delivery of EPlayKey is associated with decrementing the TPDRM Copy Count.
  • CKCMD_GET_METADATA Checks Read Secure Metadata permissions and transfers third-party, host-specific secure metadata from the media to the host.
  • CKCMD_GET_METADATA functions during a current secure session. Only hosts with Read Secure Metadata method permissions are allowed access to CKCMD_GET_METADATA.
  • SourceFile must specify a file that is unlocked.
  • SourceFile must specify a file that has metadata specific to the Metadataldentifier value for the host.
  • the parameters required by the command and settings include: HostCmd is set to DPICMD_CK_COMMAND; CkSubCmd is set to CKCMD_GET_METADATA; ESessionKey is the current secure session key. See CKCMD_AUTHENTICATE for more information; Metadata is the metadata for the file that is securely stored. The metadata may be limited to 1024 bytes per file per host.
  • CKCMD_GET_METADATA returns third-party, host-specific secure metadata associated with a file.
  • the metadata returned may be the metadata written by the last CKCMD_SET_METADATA for this host and file. If there has been no such command issued then the metadata pre-recorded for this file and host is returned.
  • the engine does not interpret the metadata in any way.
  • the metadata may only be accessible to the host for the current secure session and only the metadata for that specific host may be accessible.
  • CKCMD_PLAY Transfers secure content from the engine to the host under an established play session.
  • the command operates during a current secure session. Only hosts with CKDRM Play or DRM Copy method permissions are allowed access to CKCMDJPLAY. PlayFile must specify a file that is unlocked. PlayFile must specify a file that has DFS Read permissions. PlayFile must specify a file that has CKDRM Play or DRM Copy permissions, hi the CKDRM Play method the received content may not be stored; in the DRM Copy method the received content may be stored.
  • the parameters required by the command include: HostCmd, which may be set to DPICMD_CK_COMMAND; CkSubCmd may be set to CKCMD_PLAY; PlayOptions are the options for this command. PlayFile is the DFS handle of the file to access; ByteOffset is the location within the file to start the transfer.
  • the ByteOffset value could be a multiple of 16. In one embodiment, the value must be a multiple of 16.
  • ByteCount is the number of bytes to transfer. If the PLAY_TO_EOF bit is asserted in PlayOptions then this field is ignored; otherwise, ByteCount must be a multiple of 16.
  • ESessionKey is the current secure session key. See CKCMD_AUTHENTICATE for more information.
  • EPlayKey is the play session key for the file specified by PlayFile, encrypted with the secure session key. The value may be the same as the value returned by the engine in the EPlayKey field in a preceding command for the same file.
  • the preceding command is CKCMD_GET_CKDRM_PLAY_KEY.
  • the preceding command is CKCMD_GET_DRM_COPY.
  • the data returned is the file contents, encrypted with the play session key.
  • CKCMD_PLAY returns the content of the file encrypted with the play session key.
  • CKCMD_PLAY is functionally equivalent to DFS_READFILE. Refer to the DataPlay File System commands specification for a complete description of the options and end-of-file behavior.
  • CKCMD_RECORD_APPEND Checks CKDRM Record permissions and transfers secure content from a host to the end of a file.
  • the CKCMD_RECORD_APPEND requires a current secure session. Only hosts with CKDRM Record method permissions are allowed access to CKCMD_RECORD_APPEND. RecordFile must specify a file with CKDRM Record and DFS Write permissions. The file may be locked or unlocked.
  • the parameters used by the command include: HostCmd, which may be set to
  • DPICMD_CK_COMMAND may be set to CKCMD_RECORD_APPEND;
  • RecordOptions are the options for this command and are encoded and behave as described by a RecordOptions Encoding table; RecordFile is the DFS handle of the file to access; ByteCount is the number of bytes to transfer, however, if the
  • ESessionKey is the current secure session key
  • ERecordKey is the current record session key and may be encrypted with the engine's protocol key. In an embodiment, the same record session key must be used for all instances of this command, and must match the record session key from the CKCMD_CREATE_FILE command that created the file.
  • the data received is the content to add to the file.
  • the data is encrypted with at least the record session key.
  • CKCMD_RECORD_APPE ⁇ D adds content to the end of the file specified.
  • CKCMD_RECORD_APPEND is functionally the opposite of
  • CKCMD_PLAY It is functionally equivalent to DFSCMD_WRITE_APPEND except for the encryption of the data.
  • CKCMD_SET_KEYBOX Transfers a key box from the host for a particular file.
  • the key box provides keys for unlocking data and may be bound to the media when content is pre-mastered.
  • CKCMD_SET_KEYBOX There must be a current secure session. Any host may be allowed access to CKCMD_SET_KEYBOX. AssociatedFile must specify a file that is unlocked and does not have a key box or CKDRM metadata.
  • the parameters required by the command include: HostCmd is set to DPICMD_CK_COMMAND; CkSubCmd is set to CKCMD_SET_KEYBOX; AssociatedFile is the DFS handle for the file with which KeyBox is associated; KeyBox is the key box for the file specified by AssociatedFile and the destination specified by CKDRMId.
  • the command directs that the engine writes the key box to the media and associates it with the specified file, thereby enabling the file for permissible CKDRM methods.
  • CKCMD_SET_METADATA Checks Write Secure Metadata permissions and transfers third-party, host-specific secure metadata from the host to the media.
  • HostCmd is set to DPICMD_CK_COMMAND; CkSubCmd is set to CKCMD_SET_METADATA; AssociatedFile is the DFS handle for the file with which the metadata is associated; ESessionKey is the current secure session key. See CKCMD_AUTHENTICATE for more information; Metadata is the metadata associated with the file for the current host to be securely stored.
  • CKCMD_SET_METADATA is the complement function to CKCMD_GET_METADATA. This command writes DRM- or host-specific secure metadata to the DataPlay media for a particular file. The metadata received will be returned for subsequent CKCMD_GET_METADATA commands for this host and file. If AssociatedFile aheady has metadata specific to the Metadataldentifier value for the host then it is overwritten by the new metadata.
  • the engine writes the metadata to the media and associates it with the specified file and the host for the current secure session.
  • the engine does not interpret the metadata in any way.
  • the secure metadata will only be accessible to the host specified by the Metadata Identifier fields of the host CKDRM certificate for the current secure session.
  • CKCMD NLOCK FILES Checks CKDRM Unlock permissions and unlocks files.
  • the parameters for the CKCMD_UNLOCK_FILES include: HostCmd is set to DPICMD_CK_COMMAND; CkSubCmd is set to CKCMD_UNLOCK_FILES;
  • EMediald is the encrypted media identifier;
  • DataMac is the message authentication code for the data packet. It is calculated over the FileSet field;
  • FileSet is an array of identifiers of the files to unlock, the number of entries for which is the value specified by FileCount, each entry for which is a FileSet Element;
  • the Handle field is the DFS handle of the file to unlock;
  • the EKeyComplement field is the complement of the key set for the file, i.e., the complete key box may not be on the media and this field provides the remaining key box information needed to decrypt the file;
  • EKeyComplement is the complement value encrypted with the engine' s public key.
  • CKCMD_UNLOCK_FILES instructs the engine to unlock a set of files.
  • a secure session must be active with the host, and the host must have CKDRM Unlock permissions, i a successful CKCMD_UNLOCK_FILES command, the engine completes each file's key box and changes the attribute from locked to unlocked.
  • the above-described methods for the TPDRM, CKDRM and DFS use cryptographic algorithms.
  • the manner in which the cryptographic algorithms apply to the methods depends on design requirements. Encryption techniques disclosed herein, therefore, are exemplary in nature, with the number of bits applicable to encrypted techniques being a function of available bit space and cost-efficiency, h one embodiment, AES functions may use 128-bit keys.
  • the public key cryptography may be elliptic curve cryptography or another appropriate type of cryptography.
  • key encryption applies to key complements in the UNLOCK methods.
  • the method CKCMD_UNLOCK_FILES requires that key complements be transported.
  • an embodiment provides that key complements are transported in EKeyComplement fields.
  • the key complement may be encrypted and decrypted using AES with the unlock key as the AES key pair.
  • Other fields applicable to the UNLOCK method include media identifiers and Emediald fields.
  • CKCMD_UNLOCK_FILES provides that media identifiers are transported in EMediald fields.
  • the media identifier may be encrypted and decrypted using AES with a secure session key as the AES key.
  • RevocationMac also apply to the UNLOCK method, and further apply to the CKDRM CREATE FILE method. More specifically, message authentication codes are transported in CommandMac, DataMac, and RevocationMac fields.
  • the message authentication code may be generated using the SHA-1 MAC function.
  • the key for the MAC function is the current secure session key.
  • Play Session Content Encryption applies to the CKDRM method CKCMD_PLAY. More specifically, play session content may be transported in the data transfer phase of the CKCMD_PLAY method. The content may be encrypted and decrypted using AES with the play session key as the AES key. Play Session Key encryption applies to the CKDRM methods
  • play session keys may be transported in EPlayKey fields or another appropriate field.
  • the play session key may be encrypted and decrypted using AES with the secure session key as the AES key.
  • the CKDRM uses the method
  • CKCMD_RECORD_APPEND Record session content may be transported in the data transfer phase of the CKCMD_RECORD_APPEND method.
  • the content may be encrypted and decrypted using AES with the record session key as the AES key.
  • the method CKCMD_CREATE_FILE and CKCMDJ ECORD_APPEND.
  • Record session keys are transported in ERecordKey fields.
  • the record session key is encrypted using the public key encryption function with the engine's Protocol Public Key as the public key. This public key is from the engine's CKDRM certificate.
  • the encrypted record session key may be decrypted using the private key decryption function with the engine's private key corresponding to the engine's Protocol Public Key.
  • the field EsessionKey is for the CKDRM methods CKCMD_AUTHENTICATE, CKCMD_CREATE_FILE, CKCMD_GET_CKDRM_COPY, CKCMD_GET_CKDRM_PLAY_KEY, CKCMD_GET_CKDRM_ID, CKCMD_GET_DRM_COPY, CKCMD_GET_METADATA, CKCMD_PLAY, CKCMD_RECORD_APPEND, CKCMD_SET_METADATA, and CKCMD_UNLOCK_FILES.
  • Secure session keys may be transported in ESessionKey fields.
  • the secure session key is encrypted using the public key encryption function with the host's Protocol Public Key as the public key. This public key is from the host's CKDRM certificate for the current secure session.
  • the encrypted secure session key may be decrypted using the private key decryption function with the private key corresponding to the host's Protocol Public Key.
  • an embodiment uses the EunlockKey fields with the CKDRM method CKCMD_UNLOCK_FILES.
  • the unlock keys are transported in EUnlockKey fields.
  • the unlock key is encrypted using the public key encryption function with the engine's Protocol Public Key as the public key.
  • the public key may be from the engine's CKDRM Certificate.
  • the encrypted unlock key may be decrypted using the private key decryption function with the engine's private key corresponding to the engine's Protocol Public Key.
  • manifest constants including the opcodes below, which of ordinary skill in the art appreciates can be any opcode that doesn't collide.
  • the manifest constants provided below pertain to one exemplary embodiment of non- colliding opcodes.
  • TYPEDEF U128, AES_KEY
  • TYPEDEF U160, MAC
  • TYPEDEF U1S, EXPOSED_METHODS
  • HOST_CKDRM_UNLOCK 0x0040 // bit 6 // CKDRM_STATE definition, CKDRM permission and attribute flags.
  • TYPEDEF U16, CKDRM_STATE
  • AES_KEY ESessionKey // 4:19 ⁇ CKCMD GET CKDRM_ID_COMMAND_PACKET;
  • AES_KEY ESessionKey // 8:23 ⁇ CKCMD GET PLAY KEY COMMAND PACKET;
  • AES_KEY ESessionKey // 8:23 ⁇ CKCMD GET DRM COPY COMMAND PACKET;
  • AES_KEY ESessionKey // 8:23 ⁇ CKCMD GET METADATA COMMAND PACKET;
  • AES_KEY ESessionKey // 8:23 ⁇ CKCMD_SET_METADATA_COMMAND_PACKET; TYPEDEF (CKCMD_SET_METADATA_COMMAND_PACKET, sCKCMD_SET_METADATA_COMMAND_PACKET) ;
  • the secure electronic content system includes interactions between servers and hosts and engines to unlock and render secure content.
  • the CKDRM, DFS and TPDRMs described above interact to permit unlocking content in a secure environment.
  • an architecture diagram provides an embodiment of the interactions between servers, hosts and engines.
  • the server such as a digital clear server 2394 interacts with both an electronic retailer (eTailer) via web-enabled communication line 2360 and with a device connected to a personal computer (PC) 2398 via a secure access channel 2334.
  • the device connected to the PC 2398 receives the communications from server 2394 via a web browser 2318 wherein a CKU client 2322 receives the communication.
  • the web browser 2318 further includes a dynamic web page(s) that is generated by an eTailer 2324, which receives signals from an application server 2354.
  • Application server 2354 in one embodiment includes a HTML and a GUI generator object 2336, a package display and pricing object 2338, a customer management object 2344, a session management object 2346, a credit card authorization object 2348, a digital clearing server (DCS) interface 2352 and a database connection layer 2342 that couples the application server 2354 to a plurality of databases 2356.
  • the plurality of databases 2356 and the application server 2354 are part of the eTailer web store front 2396.
  • the databases included in the eTailer web store front 2396 include a customer database 2358, package and pricing database 2362 and a session and transaction database 2364.
  • the databases in the eTailer web store front are according to design requirements and may include more or less of the objects and databases described herein.
  • the web browser 2318 within the device connected to the PC connects via a secure access channel 2334 to a server, such as the digital clearing server 2394.
  • the web browser 2318 is further connected via a secure access channel 2316 to a USB driver 2312 which also follows a secure access protocol to connect the USB driver 2312 to a USB port 2308 and to an engine 2306 coupled within a device 2304.
  • the device 2304 is coupled to media 2302.
  • the USB driver 2312 is coupled, not only via secure access channel 2316, but also via a signal line 2313 to an Installable File System (IFS) 2314.
  • IFS 2314 is coupled to an auto run handler 2328 as described herein, as well as a content manager 2326.
  • Content manager receives signals from both the IFS 2314 and the auto run handler 2328 and provides content as managed by the content manager 2326 to the web browser 2318.
  • the server 2394 receiving signals via both signal line 2360 and signal line 2334 communicates with both the eTailer web store front 2396 and with the device connected to the PC 2398 using HTTP or other appropriate protocol in a web environment.
  • the signal line 2360 coupling the application server 2354 to the digital clearing house server 2394 receives signals at an eTailer interface 2382 within a clearing server 2399.
  • the digital clearing server 2394 includes a clearing server 2399.
  • Clearing server 2399 includes the eTailer interface 2382 which communicates with a plurality of databases, including a packaged database 2386, a customer and eTailer database 2388, a customer database 2390, and a session and transactions database 2392.
  • Also included in the clearing server 2399 is a digital clearing services object 2384.
  • the clearing server 2399 is coupled to a integration object 2376 within the clearing server 2394. Integration object includes a database, more particularly a package to key mapping database 2380.
  • Communication protocol object is coupled to a CKU master server 2368 as well as the package database 2386 within the clearing server 2399.
  • CKU master server 2368 is within the content key server 2374.
  • Content key server 2374 includes at least a key complement database 2370 and a transactions database 2372, each of which are coupled to the CKU master server 2368.
  • CKU master server 2368 is further coupled to a CKU server 2366 which communicates via signal line 2334 to the CKU client 2322 located in the device connected to the PC 2398.
  • Fig. 23B describes a process from a creation standpoint, showing an authoring process 2300.
  • Block 2310 provides that content is authored for mastering onto media with the Content Provider having the option in block 2320 of including secondary content that can be unlocked by the consumer at some time after the original purchase. If secondary content is not included on the media, block 2350 provides for distributing unlocked content on media. If secondary content is included on the media, the media will include a key mastered onto the media in block 2330. Therefore, media with locked content outputs a Key Complement for every locked file on the media.
  • media and clearing house type servers are set up as part of a mastering process, or in other embodiments as part of a setup process for a server and media. More particularly, referring to Fig. 24, a flow diagram illustrates a setup process that results in a secure database and a media, such as a media disk.
  • the clearing house server database configuration flow diagram provides a method of setting up a clearing house type server. Specifically, the process begins with block 2402.
  • Block 2404 provides for a content provider to provide a new release of content to the server in a procurement process such as an "Asset and Information Procurement" as shown.
  • the components included in the procurement process include content files, metadata infom ation, security information, and package collection information, if any.
  • the content files refer to files tied to a particular type or categorized content. These content files, in one embodiment, may include an appropriate media coder-decoder (codec).
  • Metadata information includes any description of components that accompany a content file, such as graphics and lyrics, h one embodiment, the metadata is in a structured format, in other embodiments the format may be determined by individual content providers. Further, an embodiment requires that metadata must be provided on a per- track and per-album basis.
  • the security information refers to mles governing the way the consumer interacts with the content.
  • the information may include a revocation list and TPDRM and CKDRM mles.
  • the revocation list may be denied by a content provider and may include a list of all player devices, player applications and servers that have been revoked.
  • DRM mles providing restrictions on consumers regarding playing and copying of content.
  • the DRM mles may also include details so that an authoring and mastering process or processes will know the files that require initial locking.
  • package collection information t that specifies how secondary content is to be grouped and how to display the secondary content to the user.
  • Block 2408 relates to an authoring process which may be accomplished via a DataPlay or third party.
  • the authoring process includes packaging all files received by a content provider according to predetermined specifications.
  • directories are established with the following data: content files (encoded); direction structure; content manager; autorum.inf; and contents.ddl.
  • the content manager includes files used to present content or media to the consumer, such as an executable, mini- website or some of the form defined by the content provider.
  • the autoruninf launches the content manager.
  • the contents.ddl file is stored in a common area for use with any DRM.
  • the contents.ddl may include a package collection, advertisements and SKUs.
  • the SKUs may reference one ore more files.
  • the package collection is, in one embodiment, a unique identifier (PCID) for all secondary content or for a side of media.
  • the package collection may include a reference to one or more advertisements, for example, referring to a package collection.
  • Block 2410 provides that part of the authoring process includes providing DPMMF DDL files for describing the relationship between content and asset files.
  • Block 2412 provides for a pre-mastering process to begin after the authoring process described with regard to block 2408. More particularly, the pre-mastering process includes a content provider providing content subject to a DLM. The premastering process includes three components, 2414, 2416, and 2418. Flag 2414 refers to a key component. ddl function wherein a file called KeyComplement.ddl is generated that will be used to configure a secure content key database.
  • the KeyComplement.ddl file includes a package collection identifier.
  • the package collection identifier includes a full file path name, a file handle, a key complement, which may be 128 bits, and a key version.
  • the pre-mastering process further includes a function of passing along a file, contents.ddl that was created during authoring.
  • the file, contents.ddl 2416 is input into a next process, content key packaging process into a content key packaging process.
  • Another portion of the pre-mastering process 2412 is a DataPlay media mastering process wherein files are set on a tape. More particularly, the mastering file set is created in block 2418 that is stored and delivered on a tape, in one embodiment. In other embodiments, the mastering file may be at another type of media.
  • Each mastering file set refers to, in one embodiment, a single side on a media disc.
  • Block 2420 is shown coupled to the contents.ddl block 2416 and the KeyComponent.ddl block 2414.
  • Block 2420 more specifically refers to a master server key complement setup process also known as a digital clearing server setup process that relates to the data migration to a secured database 2424.
  • the master server key complement setup process 2420 provides for loading tables for packaging a key mapping database such that the tables are loaded with information specified in the KeyComponent.ddl and Contents.ddl files.
  • the block 2418, DataPlay mastering file set on tape is shown coupled to the pre-mastering process 2412. More particularly the mastering file set on a tape process 2418 refers to creating one or more "glass masters" if the media is a optical disc, hi other embodiments, the mastering file set will be mastered on to an appropriate media type, h an embodiment, glass masters are used to create one or more stampers. Stampers are then used to mass produce media 2426 that will be distributed or available for purchase.
  • the stamping process is a manufacturing process.
  • a setup process is provided in a flow diagram for setting up the electronic retailer (eTailer).
  • the eTailer web store front 2396 is shown including an application server 2354 and databases 2356.
  • the setup for that process is described in Fig. 25. More particularly, the process starts at 2502.
  • Block 2504 provides that the content provider package is setup and a change process occurs regarding a package definition.
  • the eTailers generally require a package collection SKU for auditing purposes and other purposes and may not use a package collection ID as described above.
  • the package collection ID is passed on to an eTailer through a URL, and the eTailer will simply hold it until passing it to a digital clearing server.
  • the eTailer discards the package collection ID.
  • the content provider supplies the eTailers with Contents.dll file as described with reference to Fig. 24, and any graphics that are to be a part of the package presentation to a consumer in block 2508 and 2506.
  • Blocks 2506 and 2508 are shown coupled to block 2510, the eTailer package and pricing setup and change process "pricing definition." More particularly, after a content provider has supplied available packages, the eTailers setup their pricing roles.
  • eTailer Technical details for configuring a database with package, pricing, and package presentation data may be completely defined by an eTailer and may conform to an existing "shopping cart" and/or catalog maintenance functionality of the eTailer.
  • an eTailer in one embodiment, may choose to specify discount models and advertising specifications. For example, a customer may choose a particular package along with an advertisement tailored for that consumer.
  • Block 2510 is shown coupled to database 2512, eTailer secure database package pricing and presentation tables, the end product of the eTailer database setup.
  • the eTailer secure database tables shown in block 2512 are included in Fig. 23B as package and pricing database 2352 and may it further include customer database 2358.
  • Fig. 26 provides a flow diagram from a consumer perspective of a transaction to unlock the content. More specifically, process 2600 provides in block 2610, that a consumer is presented with offers. Block 2620 provides for receiving satisfying conditions for unlocking. For example, conditions for an unlock transaction may be providing payment and/or demographic data. Block 2630 provides for delivering the Key Complement to an engine, for example, through a Secure Authenticated Channel (SAC). The engine then writes this data to the media changing the state of the content from Locked to Unlocked. Referring to Fig. 27, an exemplary user interface 2700 is shown. The user interface may be generated by a web server and may include the presentation of a user option that allows the user to elect not to be presented with offers of some sort on future insertions of this media.
  • SAC Secure Authenticated Channel
  • the user interface 2700 shows an embodiment enabling an unlock transaction. More particularly, the interface 2700 may be a web page with hyperlinks, such as 2730 that direct the user to an activation center for entering data necessary to complete an unlock method. Also shown on the web page are indications 2710 of status as to whether media read and interpreted for the interface 2700 contains locked and unlocked files. If a file on the media is locked, a hyperlink to buy 2750 may be presented to the user. For unlocked files, the interface provides a hyperlink 2720 allowing the user to play a selection on the media.
  • the interface 2700 may be a web page with hyperlinks, such as 2730 that direct the user to an activation center for entering data necessary to complete an unlock method. Also shown on the web page are indications 2710 of status as to whether media read and interpreted for the interface 2700 contains locked and unlocked files. If a file on the media is locked, a hyperlink to buy 2750 may be presented to the user. For unlocked files, the interface provides a hyperlink 2720 allowing the user to play a
  • the unlock portion of the SEC system is a framework of several components that work together. On embodiment is shown in Fig. 28. As shown, several components work together to unlock secondary mastered content that is stored on pre-mastered media.
  • the framework for the CKU portion of the SEC system includes communication protocols that allow flexibility in user choice of both client and server platforms. Further, according to an embodiment, the communication protocols support various business models for unlocking and clearing which may include different components residing at different related component locations.
  • Fig. 28 shows an embodiment of connectivity among components included in Fig. 23B, and a broader perspective of the SEC system.
  • the unlock system includes one or more databases coupled to a master server.
  • the databases coupled to the master server include a key complement database 2810, a transactions database 2820 and a revocation list database 2830.
  • the master server 2840 is coupled to a web server 2850 that is further coupled to a secure CKU server 2860.
  • CKU Master Server 2840 may be hosted by a Certificate Authority or other entity responsible for authenticating both engine certificates and CKU Server certificates by checking them against a revocation list.
  • CKU Master Server 2840 may also be responsible for securely delivering Key Complements from a master Key Complement database 2810 to the CKU Servers 2660 that may deliver them to engines 2898.
  • the CKU Server 2860 may be a server-side runtime object that works with a web application server 2850 and several databases 2870, 2880 and 2890 to manage portions of the CK unlock.
  • CKU server 2860 may be hosted by any entity that requires the capabilities to transact and unlock CKDRM secondary content such as a clearing partner (Reciprocal, DWS, Magex, etc), retailer website or DataPlay.
  • Each CKU Server 2860 may be issued a unique CKDRM Certificate and public- private encryption key pair for use in establishing the secure authenticated channels
  • the CKU Server 2860 may incorporate cryptography functionality.
  • the CKU Server 2860 may include functions such as PKI, AES, triple-DES and MAC algorithms.
  • a Random Number Generator (RNG) algorithm such as one that complies with FIPS-140, may be appropriate.
  • the web server 2850 is coupled to one or more databases, depending on requirements of the system, such as co-branded elements from third party distributors 2870, offers database 2880, and a transactions database 2890.
  • the CKU server 2860 is coupled to a client server 2896 and a web page 2892 hosted by the client server 2896.
  • the web page 2892 provides an interface for a user to communicate with the other components in the secure electronic content system. More particularly, a host device 2894 holding an engine 2898 may communicate via the web page 2892. The communication between components may be via a standard TCP/IP protocol.
  • the user interface is presented by a web-server 2850 through a browser to an end-user.
  • Fig. 28 shows an offers database 2880 that may contain information about the available secondary content on each pre-mastered media disk, including, for example, pricing, titles, descriptions, etc. Either content providers or retailers may maintain this database.
  • transactions database 2890 which provides a place for recording unlock transactions.
  • the data collected may be used to determine payments to the various entities that take part in the value chain of unlock transactions.
  • the transactions database 2890 may also store temporary state information about transactions in progress.
  • the CKU Server 2860 and Web Server 2850 may require access to this temporary data.
  • the Ul Elements database 2870 may contain information that the web server 2850 uses to construct custom branded pages and sites. This may include branding at the retailer level as well as individual branding based on the particular SKU of media that is being offered.
  • the databases Key Compliment database 2810 may include unlock codes, such as Key Complements for mastered media. Each individual file that is locked on a piece of media may have a unique Key Complement. These Key Complements, in an exemplary embodiment, are securely delivered from the pre-mastering for manufacturing and stored with corresponding SCID information about the media. Access to this database is strongly guarded. Only a valid CKU Master Server 2840 may have access to this database.
  • the revocation database 2830 may contain information about revoked engine certificates and revoked CKU Server certificates. The revocation database 2830, in one embodiment, is checked in every transaction to ensure that only authorized participants are allowed to take part in the unlock process.
  • the transactions database 2820 may record transactions between CKU Servers
  • CKU Master Server 2840 has exclusive access to the Key Complements Database.
  • the CKU Master Server 2840 may be similar in construction to the CKU Server 2860 and sets up an active "listen" socket that accepts incoming connections. It accepts connections from CKU Servers 2860 seeking to obtain Key complements to perform unlocking operations.
  • Fig. 29, shows an embodiment of a process beginning with a media disk being inserted into an engine 2952 via a PC 2950 presents a record label or retailer-branded web site 2710 that provides offers 2720, transactions 2730 and unlocks content 2740 via a clearing-house web server 2760 coupled to a tiansaction database 2680 and an offer database 2670.
  • How the media directs the engine to a particular web site is a method according to an embodiment of the present invention. More particularly, referring to Fig. 30, the media such as DP discs 3010 may be purchased with both primary content 3020 for which the user may have paid, and secondary content 3030, which may include bonus content 3040.
  • both or one of the primary and secondary content may be locked or unlocked, depending on the marketing desired and on the content provider's requirements.
  • a content provider may provide free disks that have a minimal amount of unlocked content.
  • An engine in a player may therefore, be enabled to play only a minimal amount of content.
  • media may be purchased at a number of facilities such as those shown in 3120.
  • a consumer may purchase a pre- mastered disk 3110 in a primary transaction and render the content available, as shown in block 3130.
  • the consumer may choose to exercise offers presented via an Internet connection coupled to an engine in 3140 to unlock content 3151 via a secure clearing house 3150.
  • the user interface and, more particularly, an auto-run handler associated with a user interface performs method 3000.
  • the auto-run handler may be responsible for detecting when media, such as a disk, is inserted into a device connected to a personal computer. Upon detecting the media insertion, the auto-mn connects to an engine and determines the state of the media. The state may include identifying the specific media and side and whether or not there is any content available to offer for sale to the consumer.
  • the auto-run handler may also check either the user's system or the media to determine if the user has requested not to be presented any more offers for this disk. Block 3122 determines whether there is locked content that could be offered to the consumer via a user interface.
  • One embodiment of the present invention is directed to a method for a user interface which may be operable via a driver for an engine, or operate in conjunction with the auto-run handler that executes at system startup or upon user selection.
  • the user interface may present menu options to the user including PLAY, EJECT, PURCHASE ADDITIONAL CONTENT, and EXIT.
  • Block 3152 provides for connecting to a URL, such as for a CKDRM compliant unlock server address or associated server address that may be mastered onto the media and pass the data to the server, such as by a query string in the URL. hi other embodiments, block 3152 connects to a URL that is according to a serial number mastered on the media.
  • the number mastered on the media may be a time stamp, indicating the date of the master, a serial number associated with a server or URL, neither or both, hi one embodiment, for example, the serial number or time stamp advantageously allows distributors of pre-mastered media to return media disks to their source.
  • Block 3152 provides for connecting to a URL, such as for a CKDRM compliant unlock server address or associated server address that may be mastered onto the media and pass the data to the server, such as by a query string in the URL.
  • block 3152 connects to a URL that is according to a serial number mastered on the media.
  • the number mastered on the media may be a time stamp, indicating the date of the master, a serial number associated with a server or URL, neither or both.
  • the serial number or time stamp advantageously allows distributors of pre-mastered media to return media disks to their source. More particularly, in one embodiment a method is directed to identifying one or more vendors associated with a media disk.
  • the method includes providing instructions for the media disk, such as including a URL in the instructions, or providing a code that may be associated with a URL. Further, during an install of the media disk into a host according to the instructions, the method provides for installing an identifier on the media disk.
  • the identifier may be a code identifying the vendor from which the media disk originated. For example, one method of identifying a location associated with a vendor of a media disk holding hidden content can include finding a location associated with the vendor, the location being associated with the vendor of the media disk and independent of any vendors that are not associated with the media disk.
  • the instructions for the media disk may include identifying a vendor from whom the media disk was purchased.
  • the media disk may provide instructions that include a code, a universal resource locator (URL), a cryptographic key associated with the vendor, and a part of a cryptographic key associated with the vendor, each of which may be a explicit or implicit location.
  • a system in accordance with such a method may include mstmctions for the media disk, and a software installation component associated with the media disk, the software installation component instantiable during an install of the media disk into a host according to the instructions.
  • the software installation component may be operable to install an identifier on the media disk, the identifier including a code associated with the vendor.
  • the identifier is associated with a location of the vendor such that a connection between the host and a server is operable to open the location.
  • the location could be an Internet location including web pages for unlocking content stored on the media disk, the Internet location further providing optional offers for purchase over the Internet by the vendor.
  • a method of identifying a location via a media disk relates to the media disk having at least a writeable portion and a non-rewriteable portion.
  • the method includes writing the location on the writeable portion, distributing one or more of the media disks to one or more entities, the location associating the media disks to the one or more entities, and if a return of the media disks occurs, altering the location according to predetermined conditions.
  • the location may be universal resource locator (URL) and the predetermined conditions may include determining a market share of the one or more entities.
  • URL universal resource locator
  • the altering the location may be by a content provider, the content provider receiving the media disk, including one or more media disks, and distributing the returned media disks to same or different entities of the one or more entities after the altering.
  • the distributing may be pursuant to a lease agreement for media disks, the lease agreement allowing return of unsold media disks.
  • content providers provide media holding content to distributors via a lease arrangement under which distributors pay only for those media disks that are sold. Unsold media disks are returned to the content providers.
  • the pre- mastered media disks may or may not permanently identify a distributor or content provider URL for unlocking content.
  • a distributor that desires having a pre- mastered media disk being associated with the distributor's URL for presenting offers, coupons, etc., and also desires the flexibility of returning unsold media disks, may receive media disks with serial numbers and/or time stamps that allow a main server to direct a user to the distributor's URL. Other distributors may be satisfied with a sticker identifying a URL for unlocking content.
  • the main server URL is permanently mastered on the media disk along with a serial number and/or time stamp. The main server receives direction from a plurality of content providers and/or authorized distributors that identify URLs for distributors that are associated with serial numbers.
  • the time-stamp associated with the serial number may be used to more specifically identify a group of media disks with a same serial number, or the serial number alone may identify the media disks.
  • the identified media disks are then redirected from the distributor's URL to a second distributor's URL or to a generic URL.
  • each media disk is directed to a main server and redirected according to a market share percentage such that the number of accesses that are redirected to a distributor URL is proportional to the market share held by the distributor.
  • the interface determines whether there is an authored autorun INF file on the media. If the user selects PLAY, the PLAY method as described above is executed in block 3180.
  • the auto-run handler may cause a URL connection.
  • a web server may then generate a client side script to embed an object and call an entry point with variables according to a client object API.
  • the commands for the object may include: ConnectCKUServer(NARCHAR ServerIP, UI ⁇ T Port, UT ⁇ T SessionID, UI ⁇ T ContentlD, UI ⁇ T USBDriverlD ).
  • ServerIP is a string variable that describes the URL to which the object is to connect.
  • SessionID is a unique identifier assigned by the server.
  • the SessionID may associate a Socket connection with the particular web session that was initiated so that the server can synchronize its state.
  • the SessionID may also be stored as the key in the temporary portion of a transaction database, such as database 2890, shown in Fig. 28, for information passing between a web server 2850 and the CKU Server 2860.
  • ContentlD is an identifier for the side and disk that contains the content to be offered to a consumer.
  • USBDriverlD is an identifier that allows a CKU Client 2896 to locate a specific instance of a drive that generated an auto-h sert notification that started an unlock session.
  • the autorun connects to a CKU Server 2860 by passing the SCID and locked-state flags in a query string to a URL mastered onto the disk, a URL identified by a user, or a default URL.
  • the URL is connected to by a "Shell Executing" the URL launches a browser on a user's system and connect to server 2860.
  • the URL may optionally point to a CKU Portal, which may be an intelligent redirector. The redirector may decide, based on, for example, Media identification information, the web server to which the client will be connected.
  • block 3182 provides for presenting offers according to the URL, auto run, or other mechanism for presenting offers.
  • Block 3114 provides for locating a driver for a connected device.
  • Block 3124 provides for connection to an engine and retrieving a CKDRM certificate, such as those described above.
  • Block 3126 provides for connecting to a CKU Server 2860, using, for example, a socket mode set such as BSD/WinSock with SOCKET_STREAM mode set.
  • Block 3128 provides for awaiting acknowledgment from the CKU Server 2860.
  • Block 3134 provides for delivering the engine's CKDRM Certificate to the CKU Server 2860.
  • Block 3144 provides for receiving the CKU Server 2660 CKDRM Certificate.
  • Block 3154 provides for passing the server certificate to the engine 2698 using
  • Block 3164 provides for retrieving a ESessionKey and passing it to the CKU Server 2860.
  • Block 3174 provides for receiving the unlock data block from the server 2860 and passing it to the engine 2898 using CKCMD JJNLOCKJFILES.
  • Block 3184 provides for reporting status of the unlock operation to the server 2860.
  • Block 3194 provides for updating a play list on media that is coupled to the engine 2898 to include newly unlocked content.
  • the CKU Server 2860 manages many concurrent connections and unlock-tiansactions as described, for example in Fig. 31. Once a connection is requested from a client the server must accept the connection and proceed with the method shown in Fig. 32. As shown, in block 3202, the CKU Server 2860 acknowledges a client connection. In block 3204, the CKU Server 2860 receives an engine's CKDRM Certificate and Session ID from the client 2896. In block 3206, the CKDRM retrieves SCID and a list of DFS file handles to be unlocked from the Transaction Database 2890 using the SessionID as the index or key. In block 3208 the CKU Server 2860 connects to the CKU Master Server 2840.
  • the CKU Server 2860 awaits the connection acknowledgement from CKU Master Server 2840.
  • the CKU Server 2860 passes a Server CKDRM Certificate, the engine 2898 CKDRM Certificate, media SCID and DFS file handles to the Master CKU Server 2840.
  • the CKU Server 2860 receives the Key Complements from the CKU Master Server 2840. In one embodiment the keys are encrypted using the CKU Server 2840 public key.
  • the CKU Server 2860 acknowledges the receipt to the CKU Master Server 2840.
  • CKU Server 2860 disconnects from CKU Master Server 2840.
  • CKU Server 2860 passes the Server CKDRM Certificate to the Client 2896.
  • CKU Server 2860 receives the ESessionKey from the Client 2896 that may be encrypted with the CKU Server 2860 public key.
  • CKU Server 2860 decrypts the Session Key using a Server Private Key.
  • CKU Server 2860 decrypts Key Complements, for example, using PKI with a Server Private Key and add Session Key information
  • CKU Server 2860 generates a random key using, for example, AES and/or triple-DES to be used to re-encrypt the Key Complements that provide unlock capability.
  • Block 3230 provides that the CKU Server 2860 encrypts the Key Complements using the Unlock Key, using, for example, AES and/or triple-DES.
  • CKU Server 2860 encrypts the Unlock Key using the engine public key using, for example, PKI.
  • CKU Server 2860 constructs a CKCMD_UNLOCK_FILES data block and transmit to the Client 2896.
  • CKU Server 2860 constructs a MAC for the data portion of the block.
  • CKU Server 2860 transmits the data block to the Client 2896.
  • CKU Server 2660 receives unlock status from Client 2896. hi block 3242, the transaction status is marked in the Transaction Database 2890.
  • the CKU Server 2860 disconnects from Client.
  • a web server 2850 completes the financial transaction after receiving indication from the CKU Client 2896 that the unlock has completed successfully.
  • Block 3310 provides that Master Server 2840 accept connection from CKU Server 2860.
  • the Master Server 2840 acknowledges the connection.
  • Master Server 2840 receives the CKU Server 2860 CKDRM Certificate, the engine's CKDRM Certificate, media SCID and DFS file handles from the CKU Server 2860.
  • Master Server 2840 verifies the validity of both certificates by, for example, checking MAC and PKI signatures, h block 3336, the Master Server 2840 checks the Revocation database 2530 to make sure there are no revoked certificates participating, hi block 3340, Master Server 2840 retrieves requested Key Complements from Key Complement Database 2810.
  • Master Server 2840 encrypts the Key Complements using the CKU Server 2860 Public Key.
  • Master Server 2840 transmits the encrypted data to the CKU Server 2860.
  • Master Server 2840 receives an acknowledgment from CKU Server 2860 and disconnects.
  • the methods described above for the servers shown in Fig. 28 begin with a client, such as CKU Client 2896 beginning a method. Referring to Fig. 34, the method for web page 2892 and CKU client server 2896 is described.
  • a client 2896 begins the method in 3410 by accessing a formatted URL, such as a URL on a media disk as described above, or a URL associated with a serial number on a media disk or other source.
  • the client 2896 presents a query string containing the SCID and locked content status.
  • web server 2850 constructs a page to present the offers to a consumer using data from the Offers database 2880 and the Ul Elements 2870 databases. After user selections have been made in block 3440, and the conditions of the transaction have been satisfied web server 2850 delivers an "Unlocking in Progress" page to the client.
  • the web server 2850 generates a unique SessionID that is used later to commit the transaction after the unlock process is verified.
  • the web page 2892 embeds a CKU Client 2896 object and contains client-side script that tells the CKU Client 2696 to begin the unlock process.
  • the web server 2850 may also store in block 3454 the SCID and a list of DFS File Handles indexed by the SessionID in the Transaction Database for later use by the CKU Server object.
  • CKU Client 2896 may be an embedded object within the web page delivered to an end user's computer.
  • the object may be developed as both an ActiveX control and Netscape Plug-in to support the majority of browser client environments.
  • the objects methods and properties may be accessed via Java Script.
  • the object sends an OLE event to the page at the completion or error of the transaction.
  • the web server When the web server receives a connection from a client browser with media information, it constructs the first page of the offers presentation. In some cases the SCID and locked-state flags will be enough data to determine the branding of the page (if the media was mastered with a unique ID specific to a single retailer or promotion). In other cases the user may have to be prompted to enter a code from a sticker on the packaging or select the retailer where they purchased the disk. Offers and pricing are retrieved from the Offers Database and presented to the consumer in a branded page. The user makes selections from the offers and must satisfy the conditions of the transaction. These conditions may require the entry of payment information or demographic data in exchange for unlocking the content.
  • the web server constmcts an "Unlock in Progress" page.
  • This page embeds a CKU Client object and script to instantiate the object with the correct parameters.
  • the web server also makes a temporary entry in the Transactions Database that contains a unique SessionID, SCID, authorization code for the credit card transaction and a list of DFS file handles to be unlocked.
  • Block 3510 provides for delivering a page to the client, the CKU Client object is instantiated and initialized with the Session ID, SCID and the IP: PORT address for the CKU Server.
  • the CKU Client locates a driver for the device that contains the media with content to be offered.
  • CKU Client obtains the engine's CKDRM Certificate.
  • CKU Client makes a connection, for example, a socket connection, to a listening port on the CKU Server.
  • CKU Server accepts the incoming connection from the client and acknowledges the connection with an acknowledgment message.
  • the CKU Client transmits the engine's CKDRM Certificate and the SessionID to the CKU Server using a connect message.
  • the CKU Server responds with either an acknowledgment or a retransmit message.
  • CKU Server locates the corresponding record in the Transaction Database by indexing the unique SessionID for this session.
  • CKU Server connects to the CKU Master Server listening port using a socket connection.
  • CKU Master Server accepts the connection and replies with an acknowledgment message.
  • CKU Server assembles a message packet to request keys and transmits it to the CKU Master server.
  • the packet may contain an engine CKDRM Certificate, the CKU Server CK Certificate, SCID for the media and the list of DFS File Handles for which Key Complements are requested.
  • the message sent by CKU Server to CKU Master Server to request the keys to unlock content takes the form as shown in Table 47.
  • message shown in Table 47 contains both the engine and server CKDRM certificates, the identifier (SCID) for the media containing the files and the list of DFS Handles for each file to be unlocked.
  • CKU Master Server responds with an acknowledgment or, if any problems occur a retransmit packet.
  • CKU Master Server validates or denies the CKDRM certificates of both the engine and CKU Server. Validation could include verifying digital signatures using, for example, CerticomTM.
  • CKU Master Server checks for the presence of the certificates in the Revocation database. If the certificates are invalid or revoked, the CKU Master Server responds in 3548 with an error message. If the certificates are valid, CKU Master Server retrieves in block 3550 the Key Complements from an associated database, encrypts them, using for example, PKI, using for example, a Server Public Key from a Server Certificate, hi block 3552, the CKU Master Server transmits the key complements to CKU Server. Referring to Table 48, the message sent by CKU Master Server may be an encrypted list of Key Complements for requested files as shown. The Key Complements may be encrypted using the CKU Server's public key or another appropriate public key.
  • CKU Server receives the Key Complements, acknowledges the receipt of the data by sending an acknowledgment message, and disconnects from the CKU Master Server.
  • CKU Server responds with a retransmit message.
  • CKU Server transmits its CK Certificate to the CKU Client using an authenticate message.
  • CKU Client responds with either an acknowledgment or a retransmit.
  • CKU Client constructs an authentication command packet to send through the driver to the engine.
  • engine responds with an encrypted session key that the CKU Client then passes in block 3566 to the CKU Server in a session key message.
  • CKU Server responds with either a server acknowledgment or a retransmit message.
  • CKU Server decrypts the session key and the key complements with a private key.
  • the CKU Server generates in 3572 a random key, for example, a 128-bit AES key to re-encrypt the key complements.
  • a session key may be used to encrypt an unlock key and to construct an unlock message.
  • the message may contain a complete packet for an unlock command to the engine. In one embodiment, the command may require calculation of the MAC for the data.
  • CKU Server sends an unlock message to CKU Client.
  • CKU Client responds with an acknowledgment or a retransmit message.
  • CKU Client uses the data to send a command to unlock files to the engine.
  • CKU Server marks the status of the unlock operation in the Transaction Database and disconnects from the CKU Client.
  • CKU Client reports the status of the transaction to the web page by sending an event to an event handler in the web page.
  • the web page displays the transaction status.
  • a number of opportunities occur for errors. As shown in Table 49, those errors that may be sent in a message include those listed.
  • the security of the SEC system is enhanced by a plurality of identifiers located on the media.
  • the identifiers may be public, private or both. As described above, the identifiers may be created during a mastering process or later during other transactions, depending on system requirements as shown in Table 50.
  • Public Identifier structure Created Statistically unique identifier created in the field. in the field.
  • Private Identifier structure Created Statistically unique identifier for each master with by the mastering process ContentKey content. This is the identifier to which pre-recorded content is bound.
  • Private Identifier structure Created Statistically unique for each individual media with in the field.
  • written ContentKey content This is the identifier to which written or field-recorded (non-mastered, not pre-recorded) content is bound.
  • Private Non-volatile memory Created by the engine GUID for each engine created. manufacturing process-
  • the method for unlocking content stored on media shown in Fig. 35 illustrates a protocol for authenticating and performing an unlock protocol.
  • the unlock protocol includes the method shown in Fig. 36.
  • the engine receives a handle, and a key complement to a key box.
  • the key box may be bound to a written identifier.
  • the engine performs a key box look up.
  • the keys within the key box are unbound and decrypted.
  • block 3640 the transaction is completed and keys are rebound, encrypted and locked.
  • the APIs are protected when data passes from a server.
  • Fig. 37 provides a process flow diagram for an unlock transaction according to another embodiment. More particularly, process flow diagram 3700 begins with a process start indication 3702, which may include powering up a device.
  • Block 3704 provides that media, such as a portable disk is inserted into a device connected to a personal computer via, for example, a universal serial bus port.
  • Block 3706 of the process flow provides that an auto-mn handler as described above is initiated.
  • the auto-run handler is a server installed in a driver stack that waits for an insert event, such as the insertion of media into a device.
  • the auto-run handler goes through the file system to retrieve an autorun.inf file with instmctions as to launching a "Content Manager.”
  • Block 3708 is directed to the content manager, which presents locked content, hi one embodiment, the content manager is a presentation layer that a user interacts with to play the contents of a media disk.
  • the content manager may dynamically build a table of contents that distinguishes between locked and unlocked content with a contents.ddl file. For locked content the content manager may provide the customer with a link that directions a consumer or user to a location that allows unlocking of content. Further, auto-run hander 3706 may detect a lack of a content manager and perform a read of the contents.ddl file to locate URL data.
  • media may contain multiple offers as in a Kiosk or download model, and may or may not have multiple URLs associated with the offers. If multiple URLs exist, the customer or user may select one before proceeding.
  • the content manager is Block 3710 provides an optional CKDRM portal for those
  • CKDRM content files In one embodiment, the need for a CKDRM portal is necessary only if one of the following situations are present.
  • a package collection ID appended to a URL points to a package or set thereof that can be unlocked by more than one eTailer, such as a secondary music transaction for unlocking by another eTailer.
  • a package collection ID that was appended to the URL that points to two or more packages that can be unlocked by a different eTailer. In either case, the presence of optional eTailers requires a user or consumer to choose an eTailer before continuing the transaction.
  • Block 3712 provides for a login into the CKDRM domain. More particularly, a login process may be according to the particular eTailer. Thus if a customer or user does not have an account with a desired eTailer, they can establish an account at block 3712 or, depending on the eTailer, choose a guest login access and provide valid billing data for processing transaction with credit card authorization required.
  • block 3714 provides for a package/pricing presentation to a consumer or other user. The consumer of user selects content to unlock or ends the procedure if no selection is made.
  • a package listing in block 3714 provides a customer with a procedure to select one or more packages to unlock, hi block 3716, a customer information questionaire is presented to the customer/user in which billing or other data is required or requested to be entered.
  • Block 3718 provides for a presentation of the transaction summary, for example according to data entered in the questionaire.
  • Block 3720 provides for credit card authorization, which may or may not be desired depending on system requirements. For example, a code may allow for free unlocking of content in return for other or no compensation at the questionaire 3716.
  • Block 3722 provides for digital clearing server notification of the transaction. More particularly, an eTailer may be responsible for using a protocol required by a digital clearing server to communicate that an unlock transaction has taken place. In one embodiment, an eTailer must provide the digital clearing server with the package collection ID and list of packages that a customer/user desired/purchased. Also, the digital clearing server may also require a certain level of customer information to be provided.
  • Block 3724 provides for a presentation to the user or consumer of CKDRM enabling status.
  • Block 3726 provides for an engine and a server conversing according to an authentication procedure.
  • Block 3728 provides for a key complement lookup and delivery and writing of the key complement to the device/disk or other location requiring a key complement to complete cryptographic requirements.
  • Block 3730 provides for an update of a contents.ddl file.
  • Block 3732 provides for a procedure to complete the CKDRM transaction for unlocking content.
  • Block 3734 provides for a transaction by an eTailer, e.g., a party that retails over the Internet, to complete the notification of the completed transaction.
  • Block 3736 provides for an optional congratulations presentation to the user or consumer.
  • Fig. 38 provides a flow diagram of a method according to one embodiment for a process to unlock content.
  • the object interaction among components of the SEC system is shown in Fig. 39. More particularly, referring to Fig. 38, block 3802 provides for the Digital Clearing Server (DCS) Order Management Server 3908 to insert records DCS_STAGE table with or without a media identifier to the DataPlay (DP) Secure Database 3914 in Fig. 39 shown by INSERT INTO DCS_STAGE 3918.
  • DCS Digital Clearing Server
  • DP DataPlay
  • block 3804 provides that the DCS Order Management Server 3908 generates a web page with a CKU client 3904 instantiated with a transaction identifier.
  • the connection 3916 of the branded Web Page with CKU client Embedded is shown.
  • Block 3806 provides for the CKU client 3904 obtaining the engine's 3902
  • Block 3806 provides that engine 3902 responds by passing CKU client 3904 a CKDRM certificate, as shown connection 3922.
  • CKU client 3904 sends the DFSCMD_GET_MEDIA_METADAT command to engine 3902 to retrieve the unique media identifier.
  • Block 3808 provides that the CKU client 3904 obtains the unique media identifier shown as connection 3926. In one embodiment, if the obtaining the unique media identifier is not established, engine 3902 obtains the identifier.
  • CKU client 3904 sends an HTTP post 3928, or a post according to another protocol appropriate for client server communication, to CKU server 3906.
  • CKU server 3906 instantiates a GetServerCert servlet 3930, which runs function
  • CKU master 3910 obtains the certificate requested from Crypto Library 3912 with the GetServerContentKeyCertificate 0 function to the Crypto Library 3912 via connection 3934.
  • Block 3810 provides for the CKU client 3904 obtaining the server 3906 content key certificate. As shown in Fig. 39, either a certificate or an error is sent back from the Crypto Library 3912 to the CKU master 3910 via connection 3938 and 3936.
  • CKU client 3904 requests an ESessionKey with the received certificate by the command in connection 3940
  • CKCMD_AUTHENTICATE server certificate
  • Block 3812 provides for the CKU client 3904 obtaining the ESessionKey from the engine 3902 via 3942 using the CKU server 3906 CKDRM certificate, via connection 3940.
  • Block 3814 provides for the client 3904 making a final unlock request for validating and/or updating a table with the media identifier.
  • the table is a DCS_STAGE table.
  • block 3814 provides for the client 3904 requests authenticating the engine 3902, obtaining the File Handle/Key Complement/Version list and wrapping the File Set.
  • the CKU client 3904 by connection 3944, sends an HTTP Post to CKU server 3906 of, for example: EsessionKey, Engine Certificate, Media ID and Transaction ID.
  • the UnlockContent Servlet 3946 within CKU server 3906 connects via 3948 using function UnlockContent (EsessionKey, Engine Certificate, Media ID, Transaction ID) to make the unlock request from CKU master 3910.
  • CKU master 3910 accesses the DP Secure Database 3914 and, by connection 3950, sends the command
  • P_KEY Transaction ID, Media ID, Password, ResultSet Out
  • the DP Secure Database 3914 responds via connection 3952 with a ResultSet (File Handle - Key - Version) or an error.
  • CKU master also requests the Wrap File Set via function WrapFileSet (ESessionKey, Engine Certificate, File Set String, Key Count, Media ID) by connection 3954 to the Crypto Library 3912.
  • Block 3816 provides for CKU client 3904 sending the wrapped file to engine 3902 so the engine 3902 can unlock the content. More particularly, Crypto Library 3912 sends either the Wrapped File Set or an error via connection 3960 to the CKU master 3910.
  • CKU Master 3910 sends the transmission to the CKU server 3906 by connection 3958, and then from the CKU server 3906 to the CKU client 3904 by connection 3956.
  • CKU client 3904 sends a command CKCMD_UNLOCK_FILES to the engine 3902, via connection 3962, with the wrapped file set.
  • Engine 3902 sends back to the CKU client 3904 either a message of success, success with qualification, or failure by connection 3964.
  • Block 3818 provides that CKU client 3904 sends a final transaction status message to CKU server 3906 and displays a transaction complete ("Trx Complete") message to a customer/user.
  • CKU client 3904 sends an HTTP Post: Transaction ID and Status Message 3966 to CKU server 3906.
  • Block 3820 provides for the DCS Order Management Server 3908 to receive the status complete notice, and delete the DCS_STAGE records for that tiansaction and update transaction.
  • the UpdateStatus Servlet 3968 responds to the post 3966 by sending function UpdateStatus (Transaction ID and Status Message) by connection 3970 to DCS Order Management Server 3908.
  • the UpdateStatus servlet 3968 connects with the DP Secure Database 3914 with the function Update SQL Statement(s) (Transaction ID, Status Message) 3972.
  • Fig. 40 provides a flow diagram of an unlock transaction according to an embodiment, with Fig. 41 providing a block diagram of object interactions among components of the SEC system.
  • Block 4002 provides for reception of media containing locked content, for example, a disk being placed in a player or device coupled to a computer system, each of which is coupled to an engine 4102.
  • Block 4004 provides that auto-mn handler 4104, or a Content Manager, requests a contents.ddl file.
  • the request is shown by engine 4102 transmitting a signal to the Auto-Run Handler of the Disc Insert Event being fired shown as connection 4114.
  • the auto-run handler 4104 sends a command 4116 of DFSCMD_GET_FILE to engine 4102.
  • Engine 4102 responds by sending a contents.ddl file as shown by 4118.
  • Block 4006 provides for auto-run handler 4104 (or Content Manager) to parse the contents.ddl file to obtain one or more of a PackageCollectionlD,
  • Auto-run handler 4104 includes internal logic 4120 that operates after the contents.ddl file is returned.
  • Block 4008 provides that auto-run handler 4104 or a Content Manager appends the data to a URL and open a default browser that will display a web page created by an eTailer 4106.
  • the choice of eTailer may be according to an embodiment described above.
  • Block 4010 provides that the Etailer 4106 presents user/customer with a series of pages to process an eCommerce transaction.
  • a User/customer interacts with the eTailer' s 4106 "shopping cart" web pages 4122.
  • Block 4012 provides that after a user/customer completes the transaction, for example, by clicking a button and prompting eTailer 4106, thereby requesting eTailor to notify the DCS of the ContentKey Unlock Transaction. ETailor passes the DCS to the PCID, and a list of PackageSKU' s that are to be unlocked as shown in the HTTP Post (PCID, Package List) 4124 from the eTailor 4106 to the DCS Order Management Server 4108.
  • Block 4014 provides that the DCS Order Management Component generates a unique transaction ID and insert one record for each package purchased.
  • the command Insert SQL Statement(s) (Transaction ED, PCID, Package ID) 4126 is transmitted from the DCS Order Management Server 4108 to the DCS Order Management Database 4110. At this point, the media identifier is not known, so it will contain a null value.
  • Block 4016 provides that the DCS Order Management Server 4108 replies to the eTailer 4106 with a failure message or a URL 4128.
  • a user/customer uses the URL to unlock content.
  • the unlock URL contains the Transaction Identifier that was generated by the DCS Order Management Server 4108.
  • Block 4018 provides that the eTailor 4106 generates a final confirmation and unlock instructions page that contains the Unlock URL 4130.
  • embodiments disclosed herein may be implemented as software program mstmctions capable of being distributed as one or more program products, in a variety of forms including computer program products, and that the present invention applies equally regardless of the particular type of program storage media or signal bearing media used to actually carry out the distribution.
  • program storage media and signal bearing media include recordable type media such as floppy disks, CD-ROM, and magnetic tape transmission type media such as digital and analog communications links, as well as other media storage and distribution systems.
  • the present invention may be implemented as those skilled in the art will recognize, in whole or in part, in standard Integrated Circuits, Application Specific Integrated Circuits (ASICs), as a computer program running on a general-purpose machine having appropriate hardware, such as one or more computers, as firmware, or as virtually any combination thereof and that designing the circuitry and/or writing the code for the software or firmware would be well within the skill of one of ordinary skill in the art, in view of this disclosure.
  • ASICs Application Specific Integrated Circuits

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Technology Law (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Multimedia (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)
  • Storage Device Security (AREA)
  • Stored Programmes (AREA)

Abstract

L'invention concerne un système et un procédé d'accès sécurisé à un contenu électronique. Ce système comprend un dispositif de commande comprenant un composant d'interface, un système hôte relié au dispositif de commande, ce système hôte étant configuré pour présenter un contenu dans des conditions prédéterminées, et pouvant fonctionner avec un protocole de navigation. Ce système hôte comprend également un gestionnaire de système pouvant fonctionner avec un composant d'associations configuré pour être au moins partiellement piloté par le système hôte, un traducteur configuré pour fournir des significations et générer des instructions à l'intérieur du système hôte, au moins un premier composant de gestion des droits numériques (DRM), configuré pour fournir un codage et des règles d'accès pour le contenu; et un composant de système de fichier comprenant une interface de programme d'application (API) de système de fichier, configurée pour fournir une interface logique entre une pluralité de composants.
PCT/US2002/027303 2001-08-27 2002-08-26 Procede et systeme d'acces securise WO2003019334A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2002323431A AU2002323431A1 (en) 2001-08-27 2002-08-26 A secure access method and system

Applications Claiming Priority (14)

Application Number Priority Date Filing Date Title
US09/940,025 US20030188175A1 (en) 2001-08-27 2001-08-27 System and method for identifying vendors of hidden content
US09/940,174 2001-08-27
US09/940,026 US7310821B2 (en) 2001-08-27 2001-08-27 Host certification method and system
US09/940,174 US7729495B2 (en) 2001-08-27 2001-08-27 System and method for detecting unauthorized copying of encrypted data
US09/940,083 US7110982B2 (en) 2001-08-27 2001-08-27 Secure access method and system
US09/940,035 US20030188183A1 (en) 2001-08-27 2001-08-27 Unlocking method and system for data on media
US09/939,896 2001-08-27
US09/940,083 2001-08-27
US09/939,960 US20030135465A1 (en) 2001-08-27 2001-08-27 Mastering process and system for secure content
US09/939,896 US7672903B2 (en) 2001-08-27 2001-08-27 Revocation method and apparatus for secure content
US09/939,960 2001-08-27
US09/940,025 2001-08-27
US09/940,035 2001-08-27
US09/940,026 2001-08-27

Publications (2)

Publication Number Publication Date
WO2003019334A2 true WO2003019334A2 (fr) 2003-03-06
WO2003019334A3 WO2003019334A3 (fr) 2003-05-15

Family

ID=27569943

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2002/027303 WO2003019334A2 (fr) 2001-08-27 2002-08-26 Procede et systeme d'acces securise

Country Status (2)

Country Link
AU (1) AU2002323431A1 (fr)
WO (1) WO2003019334A2 (fr)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007027153A1 (fr) * 2005-09-01 2007-03-08 Encentuate Pte Ltd Systeme d'authentification portable et de commande d'acces impliquant de multiples identites
US8296240B2 (en) 2007-03-22 2012-10-23 Sony Corporation Digital rights management dongle
WO2013098308A1 (fr) * 2011-12-29 2013-07-04 Koninklijke Kpn N.V. Procédé et système de distribution de contenu
CN109196816A (zh) * 2016-07-01 2019-01-11 英特尔公司 使用区块链的公钥基础结构
US20230396616A1 (en) * 2020-11-30 2023-12-07 Shenzhen National Engineering Laboratory Of Digital Television Co., Ltd. Data transmission method, electronic device and computer-readable storage medium

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8984636B2 (en) 2005-07-29 2015-03-17 Bit9, Inc. Content extractor and analysis system

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07175868A (ja) * 1993-10-15 1995-07-14 Internatl Business Mach Corp <Ibm> デジタル情報を媒体に出力するための方法およびシステム
CN101303717B (zh) * 1995-02-13 2015-04-29 英特特拉斯特技术公司 用于安全交易管理和电子权利保护的系统和方法
US20020111911A1 (en) * 2001-02-13 2002-08-15 Kennedy Kelli Hodge Document distribution system and method with consolidated document services management

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007027153A1 (fr) * 2005-09-01 2007-03-08 Encentuate Pte Ltd Systeme d'authentification portable et de commande d'acces impliquant de multiples identites
US7620976B2 (en) 2005-09-01 2009-11-17 International Business Machines Corporation Portable authentication and access control involving multiple identities
US8296240B2 (en) 2007-03-22 2012-10-23 Sony Corporation Digital rights management dongle
WO2013098308A1 (fr) * 2011-12-29 2013-07-04 Koninklijke Kpn N.V. Procédé et système de distribution de contenu
EP3901792A1 (fr) * 2011-12-29 2021-10-27 Koninklijke KPN N.V. Procédé et système de distribution de contenu
CN109196816A (zh) * 2016-07-01 2019-01-11 英特尔公司 使用区块链的公钥基础结构
CN109196816B (zh) * 2016-07-01 2023-04-07 英特尔公司 使用区块链的公钥基础结构
US20230396616A1 (en) * 2020-11-30 2023-12-07 Shenzhen National Engineering Laboratory Of Digital Television Co., Ltd. Data transmission method, electronic device and computer-readable storage medium

Also Published As

Publication number Publication date
AU2002323431A1 (en) 2003-03-10
WO2003019334A3 (fr) 2003-05-15

Similar Documents

Publication Publication Date Title
US7110982B2 (en) Secure access method and system
US7310821B2 (en) Host certification method and system
US7729495B2 (en) System and method for detecting unauthorized copying of encrypted data
US7958377B2 (en) Secure access system and method
US7672903B2 (en) Revocation method and apparatus for secure content
US20030135465A1 (en) Mastering process and system for secure content
RU2331917C2 (ru) Выдача лицензий на использование средства публикации в автономном режиме в системе управления правами на цифровое содержимое drm
RU2348073C2 (ru) Регистрация/субрегистрация сервера управления цифровыми правами (уцп) в архитектуре уцп
KR100605071B1 (ko) 디지털 전자 콘텐츠의 안전하고 편리한 관리 시스템 및 방법
KR101050594B1 (ko) 데이터 객체 전송 방법 및 디바이스
US20030188175A1 (en) System and method for identifying vendors of hidden content
US20090037732A1 (en) Tethered device systems and methods
KR20040054688A (ko) 컨텐츠 분배 애플리케이션에서의 디지털 저작권 관리 방법및 시스템
JP2011018342A (ja) 相互運用キー収納箱
WO2003019334A2 (fr) Procede et systeme d&#39;acces securise
Gaber Support Consumers' Rights in DRM: A Secure and Fair Solution to Digital License Reselling Over the Internet
Bros Advanced Access Content System (AACS) Prepared Video Book
HK1067432B (en) Issuing a publisher use licence off-line in a digital rights management (drm) system
HK1067478B (en) Enrolling / sub-enrolling a digital rights management (drm) server into a drm architecture

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SD SE SG SI SK SL TJ TM TN TR TT TZ UA UG UZ VC VN YU ZA ZM ZW

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BY BZ CA CH CN CO CR CU CZ DE DM DZ EC EE ES FI GB GD GE GH HR HU ID IL IN IS JP KE KG KP KR LC LK LR LS LT LU LV MA MD MG MN MW MX MZ NO NZ OM PH PL PT RU SD SE SG SI SK SL TJ TM TN TR TZ UA UG UZ VC VN YU ZA ZM

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LU MC NL PT SE SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ UG ZM ZW AM AZ BY KG KZ RU TJ TM AT BE BG CH CY CZ DK EE ES FI FR GB GR IE IT LU MC PT SE SK TR BF BJ CF CG CI GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP