A secure access method and system

Method and system for safe access

The invention relates to the field of digital rights management. In particular, the present invention relates to a system and method for data security, and in an electronic environment, capable of ensuring secure access, reproduction, and control of content.

Description of related skills

Since the advent of the Internet and advanced electronic devices, various entities (including people, companies, systems, and computers) have been able to transfer information faster than ever before. The advent of facsimile machines, computers, and electronic devices such as personal digital assistants (PDAs) and wireless phones with Internet access capabilities has enabled people to quickly transfer information to remote locations around the world position. However, the rapid transmission of information is not entirely without its drawbacks. Although information in digital form can be easily transmitted, it may also be easily accessed by many entities than ever before. The so-called "Hacker" is widely noticed by quickly retrieving information from computer systems before being detected. Similarly, web pages of the World Wide Web (WWW) may also quickly disseminate electronic content, such as music (MP3) data containing copyrighted content, on the Internet. As a result, electronic content may be delivered to unintentional individuals for a variety of reasons. In view of this, electronic content providers (regardless of company name or even individual citizens) are gradually attaching importance to data preservation issues of electronic content. At present, issues related to the preservation of electronic content and the Internet are being debated in a timely and lively manner. For example, Alanis Morissette was once in a show called " Online Entertainment and Copyright Law: Coming into a digital device around you (Online Entertainment and Copyright Law: Coming Soon To A Digital Device Near You ", to Orrin A US Senate Judiciary Committee led by Hatch specifically pointed out issues related to copyright and royalties. In her speech, Alanis made it clear that the goals of content creators, content providers, and content users are different. Among them, commercial content providers mostly expect to be able to obtain compensation for electronic content. These content providers are concerned with universal content reproduction issues that do not receive any compensation, such as: music compact discs (CDs) and digital audio-visual discs (DVDs). In addition, individual content users often have a purpose different from that of content providers. Most of them hope to be able to reproduce content without authorization, including digital music, software programs, movies, digital books, and the like. Compared to commercial content providers and individual content users, content creators are hoping to have as many listeners as possible, and they are often torn between the goal of distribution and the goal of compensation. The speed at which devices, computers, and the like disseminate electronic content is the main reason for the increase in sophisticated data security technologies. These sophisticated data security technologies are all trying to ensure data security for content and transactions. For example, a data security technology uses a timestamp or a counter to determine whether a transaction can be authenticated, thereby protecting the security of electronic transactions and content. Another data preservation technique focuses on cryptography and mathematical algorithms. Cryptography can not only provide the confidentiality of transactions and content, but also To provide authentication, integrity (for example: confirming whether a message has not been modified in transmission), and non-repudiation (to avoid incorrect rejection of a transaction). Some cryptographic methods are called "restrictive algorithms", which are usually used for low-level data preservation applications. Recently, a cryptographic key is a key that obtains both content encryption and content decryption to protect the security of the content. In this way, key-based cryptography can disseminate an algorithm without having to bear the risk of data security gaps caused by the data security obligation in the key itself. It is known that there are many cryptographic keys. Among them, one type is called a system key means. In this system key means, an encryption key can be calculated through the decryption key, and vice versa. In addition, a more secure key method is called a public key method (or non-systematic method). In this public key method, the key used for encryption is not the same as the key used for decryption. This public key approach is part of the International Standards Organization (ISO) authentication specification, which is commonly referred to as the X.509 protocol. In particular, these X.509 protocols can provide a framework for authentication across networks, such as the Internet. These X.509 protocols do not need to specify a specific algorithm. Instead, these agreements focus on the use of public key certificates. Under this specification, each user will have a unique name and also have a signed certificate (which has a name and a public key issued by a trusted certificate management center (CA)) . In an X.509 certificate, typical fields include: version, serial number, algorithm identification code, issuer, validity period, subject, subject public key, and signature. In particular, a version field is a format used to identify this certificate. A serial number is proprietary to this certificate authority (CA). The algorithm field is used to identify the type of algorithm used to sign the certificate and includes the parameters needed to execute the algorithm. The issuer field is the name used to identify this certificate authority (CA). The validity period field is used to provide the validity period of this certificate. This subject field is the name used to identify this user. The subject public key field is used to provide the algorithm name, parameters, and such information related to the public key. Communication using credentials based on the X.509 protocol is known to those skilled in the art. A user who wishes to communicate with others receives the destination certificate via a database and confirms the authentication action. Confirming this authentication action usually involves multiple certificate management centers (CA), if there is a hierarchical relationship between the user's certificate management center (CA) and the destination certificate management center (CA). After the confirmation is completed, the communication operation can be started. Usually, timestamp is used to confirm the flow of the message. It is known that a three-way protocol is an authentication protocol that does not require the use of timestamps. However, this authentication protocol requires the user to check a random number. The user initially generates, sends back to this destination, and then receives back from this destination. Similarly, this destination also needs to check a random number received by this user, which was originally generated at this destination. Another known data security technology is the use of fingerprint information. Generally, it means Grain information is achieved using a hash function. It is known that there are currently multiple types of hash functions. A common hash function is a one-way hash that provides a fixed-length hash value, h, after manipulating a preimage message of arbitrary length. )function. This hash value, h, is proprietary to the message with which it is associated. However, the data preservation of this hash value, h, depends on the number of bits of this hash function. At present, the actual size of the number of bits is 128. It is known that there are currently multiple different types of hash algorithms, including: Message Digest 4 (MD4) algorithm, and Message Digest 5 (MD5), which is far more complex than Message Digest 4 (MD4) algorithm Algorithm. Another type of hash function is an n-th order hash algorithm. A hash algorithm that is far more complicated than this one-way hash. An n-hash algorithm implements a randomizing function, a hash function ( hashing), and XOR function. The above description of cryptographic means is a sample representing a known digital data security system. Another feature of electronic content data preservation is the focus on digital rights management (DRM). Digital Rights Management (DRM) is used to restrict the establishment and management of various rights and the consent of digital content, and is used to support the distribution of digital content. Digital Rights Management (DRM) is an integral part of the digital distribution of educational content, professional content, transaction content, and entertainment content. Part of the known digital rights management (DRM) is the use of extended rights markup language (XML) to implement access actions and the use of controls to achieve secure digital content transactions. In general, markup languages are based on the Standard Generalized Markup Language (SGML). Standard Generalized Markup Language (SGML) is a standard language by which the format is defined in a text file to achieve file sharing among multiple computers, regardless of the hardware or operating system architecture used by individual computers. A markup language file uses a standard combination of code tags and is embedded in the text that describes a document component. A web browser is used to interpret these code tags so that each computer with its unique hardware and software features can display the document while retaining the original format of the document. A Standard General Markup Language (SGML) document uses a separate document element type definition (DTD) file, thereby defining the format code tag embedded therebetween. Other digital rights management (DRM) methods are implemented using the C programming language, Fortran programming language, and other known programming languages. Known systems include: Interleaf system, ArborText system, and TexCel system. In summary, content providers, content creators, and content users are in conflict. In this world of electronic content, known digital rights management (DRM) systems cannot resolve conflicts among these risk holders. In particular, in order to resolve these conflicts, the present invention provides a digital rights management (DRM) that can meet the expectations of content users, including: allowing a consumer of content to use it reasonably. In addition, content providers (including: content owners and producers) also need a digital rights management (DRM), which can maintain content data preservation, support novel and scalable business models, and create high value in the content market. In view of this, the present invention is improved in the following areas, that is, how to point content users to an area of the Internet.

[Overview of Invention]

In view of this, the present invention provides a system and method for secure electronic content. This system mainly includes: a controller including an interface element and a host system coupled to the controller, wherein the host system is structured to present content under predetermined conditions, and the host system uses a The navigation protocol is used for operation. In addition, the host system further includes: a system management device, which uses a related component to operate, wherein the related component is a framework for using the host system to perform at least some actions, and a translator , Its architecture to provide meaning and generate commands within this host system, at least one first digital rights management (DRM) component, its architecture to provide content encoding and access rules, and a file system component, including a file system application Program interface (API). The file system application program interface (API) is structured to provide a logical interface between multiple components. According to an embodiment of the present invention, a method for preserving electronic content includes: interfacing a controller to provide data input and output, coupling a host system to the controller, and constructing the host system to present content under predetermined conditions. , Using a navigation protocol to operate the host system, and operating a system management device on the host system. The host system is more operational: construct a related component to execute with the host system At least part of the action, constructing a translator to provide meaning and generate commands within the host system, constructing at least one first digital rights management (DRM) element to provide encoding and access rules for content, and constructing a file system element, Includes a file system application programming interface (API) to provide a logical interface between multiple components. In addition, the present invention also provides a system and method for detecting unauthorized actions related to encrypted data on a media disc. The media disc includes: a pre-recorded content of a first part, and a second Partial writing. This method involves reading an identification code on the media disc (where the identification code includes one or more sections, pre-recorded content in the first part, and writing in the second part Content, or both the pre-recorded content in the first part and the written content in the second part), determine whether the identifier has a section that is written in the second part, and compare the identifiers With one or more predetermined types of identification codes (wherein the one or more predetermined types of identification codes are located in an area in the content of this second part), and if the type of the identification code belongs to One or more of these predetermined types are determined to have detected an unauthorized action. In addition, the present invention also provides a method for identifying one or more manufacturers associated with a media disc. This method includes: providing instructions for the media disc, during the first installation of the media disc to a host according to these instructions, installing a unique identification code on the media disc, the unique identification code must include There is a code to identify the manufacturer of this media disc and to transfer the data to a server Device, read this unique identification code to find a location associated with the manufacturer. Another embodiment relates to a method for identifying a location via a media disc, wherein the media disc must have at least one writable portion and one non-rewriteable portion. This method includes writing the location to the writable portion, distributing one or more media discs to one or more entities, and disseminating locations associated with the media discs to the one or more The entity, and if a response to these media discs occurs, this location is changed according to predetermined conditions. In addition, the present invention also provides a system and method for changing security information on a storage medium. This method includes: establishing a secure conversation with a host, receiving a command via a communication channel, thereby unlocking security data managed using at least one of a plurality of content storage models, and unlocking the security data Locking, where this command corresponds to an identification code on the media, this identification code is structured to manage access to these security data, and at least one of these content storage models is a secure content management Device. In addition, a system includes: a plurality of content storage models for locking data on the storage medium, and an engine for unlocking security data, wherein the engine is used to adjust the data on the storage medium Attribute, so as to respond to an unlock command of a data, and unlock these security data according to a content storage model. In addition, the present invention also provides a system and method for identifying a device. One method includes: receiving a voucher by the device (where the voucher must include a plurality of fields and at least one field to ensure that Leave a digital signature from a certificate management center (CA), and confirm the digital signature in this certificate (where the confirmation action includes at least one of the following two actions: use the certificate management center (CA) public funds Key to confirm the digital signature of the Certificate Management Center (CA); and use a device public key to confirm a digital signature of a device and receive valid data from a source, where the valid data is used according to predetermined conditions for One or more pieces of data identifying this certificate are valid or invalid), and if these digital signatures are confirmed to be valid, a conversation key is transmitted to this device to establish a secure communication channel. In addition, the present invention also provides a system and method for abolishing a device. One method involves receiving a voucher by the device (where the voucher must include one or more fields and at least one field in order to retain a signature), attempt to confirm the signature, obtain a certificate Receive a revocation list (where the revocation list is used to identify whether one or more pieces of data of the certificate are valid or invalid, and the data includes at least one field of the certificate), and if Avoid transmitting a session key to this device (where this one is in one or more of the signatures marked as unsuccessful The conversation key is the key needed to establish a secure communication channel). In addition, the present invention also provides a system and method to preserve the content stored on the media. One method involves adding content privileges to the media (where these privileges manage access actions at multiple levels), and structuring the media to agree to this based on the content privileges and predetermined conditions Content access action. In addition, a device for preserving content stored on a medium includes: at least one tool for transmitting content to the medium, wherein the tool is structured to add multiple levels of access actions, among which, content privileges and predetermined conditions Is used to manage access to this content.

In order for those skilled in the art to understand the present invention more easily, including various objects, features, and advantages of the present invention, the present invention is described below with reference to the drawings. In the following drawings, the same numbers are used to indicate similar or identical elements. Figure 1 illustrates the interactive operation of a digital rights management (DRM) system in the secure electronic content (SEC) system according to an embodiment of the present invention. FIG. 2 is a flow chart of content according to an embodiment of the present invention. FIG. 3 illustrates a method supported by a secure electronic content (SEC) system according to an embodiment of the present invention. Figure 4 is an Open Systems Interconnection (OSI) model that introduces a secure electronic content (SEC) system architecture according to an embodiment of the present invention. Figure 5A illustrates the content flow of secure and unsecured metadata according to an embodiment of the present invention. FIG. 5B illustrates a security method for retrieving data from the media according to an embodiment of the present invention. FIG. 5C illustrates a voucher program according to an embodiment of the present invention. Figure 6 illustrates the use of a voucher in accordance with one embodiment of the present invention. A procedure for establishing a secure authentication channel. FIG. 7A illustrates an apparatus for performing a confirmation procedure according to an embodiment of the present invention. FIG. 7B illustrates a method for securely transmitting data on a channel using a flowchart according to an embodiment of the present invention. FIG. 7C illustrates a method for abolishing a content presentation device according to an embodiment of the present invention. FIG. 7D is a flowchart for evaluating a revocation list according to an embodiment of the present invention. FIG. 7E illustrates a method performed by an engine when presenting a revocation list according to an embodiment of the present invention. FIG. 7F illustrates an evaluation method for abolishing a listing result according to an embodiment of the present invention. Figure 7G is a method of organizing content according to an embodiment of the present invention. FIG. 7H is a flowchart showing a program for showing an embodiment of a main control program. FIG. 7I is a flow chart showing an embodiment of a process for creating software package collection, software package advertising, and storage unit (SKU). FIG. 8 is a flowchart illustrating an application programming interface (API) of the ContentKeyO digital rights management (CKDRM) playback function according to an embodiment of the present invention. FIG. 9 is an introduction of the ContentKeyO according to an embodiment of the present invention. Digital Rights Management (CKDRM) A method of copying application program interface (API) agreements. FIG. 10 illustrates a third-party digital rights management (TPDRM) copy method according to an embodiment of the present invention. FIG. 11 illustrates a method for recording content using the ContentKeyO digital rights management (CKDRM) according to an embodiment of the present invention. FIG. 12 illustrates a method for unlocking content according to an embodiment of the present invention. FIG. 13 illustrates a method for copying an Application Program Interface (API) agreement of the ContentKeyO digital rights management (CKDRM) according to an embodiment of the present invention. FIG. 14 illustrates an engine that executes a ContentKeyO digital rights management (CKDRM) replication method to replicate content in the ContentKeyO digital rights management (CKDRM) domain according to an embodiment of the present invention. FIG. 15 illustrates a recording scheme according to an embodiment of the present invention. FIG. 16 illustrates a method for playing content managed by ContentKeyO Digital Rights Management (CKDRM) according to an embodiment of the present invention. FIG. 17 illustrates a more detailed playback method using commands according to an embodiment of the present invention. FIG. 18 is a flowchart illustrating an unlocking step of ContentKeyO digital rights management (CKDRM) according to an embodiment of the present invention. Illustration. FIG. 19 illustrates a third party digital rights management (TPDRM) replication agreement using a flowchart according to an embodiment of the present invention. FIG. 20 is a flowchart illustrating a method of third-party digital rights management (TPDRM) copying according to an embodiment of the present invention. FIG. 21 illustrates a protocol for reading secure metadata (RSM) according to an embodiment of the present invention. Figure 22A is a flowchart illustrating a protocol for a host to write its security metadata according to an embodiment of the invention. FIG. 22B is a flowchart illustrating a method for detecting forged media according to an embodiment of the present invention. FIG. 23A illustrates an architecture diagram for providing an embodiment of server, host, and engine interaction. Figure 23B is a flowchart showing a writing procedure. Figure 24 is a flowchart showing a procedure for setting up a safety database and safety metadata. Figure 25 illustrates a process for setting up an e-retailer. FIG. 26 is a flowchart of providing a transaction to unlock content locks from the perspective of a consumer according to an embodiment of the present invention. FIG. 27 is an exemplary user interface according to an embodiment of the present invention, which is used to describe how a transaction unlocks content from the perspective of a consumer. FIG. 28 is a diagram illustrating elements for initiating an unlocking procedure in the secure electronic content (SEC) system according to an embodiment of the present invention. flow chart. FIG. 29 is a flowchart of a secure electronic content (SEC) according to an embodiment of the present invention. FIG. 30 is a diagram illustrating the types of content that can be obtained on the media according to an embodiment of the present invention. FIG. 31A is a flowchart illustrating a transaction type according to an embodiment of the present invention. FIG. 31B illustrates a method for introducing a user interface according to an embodiment of the present invention. The user interface includes a method for setting a global resource locator (URL) associated with a media disc. Figure 31C illustrates a method for connecting to a CKU server according to one embodiment of the present invention. FIG. 32 illustrates a method for a server to be requested by a client after a connection according to an embodiment of the present invention. Figure 33 illustrates a method performed by the master control server according to an embodiment of the present invention. Figure 34 illustrates a method for introducing 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 the perspective of a system according to an embodiment of the present invention. FIG. 36 illustrates a method for unlocking content from the perspective of an engine according to an embodiment of the present invention. FIG. 37 is a flowchart illustrating a procedure for completely unlocking a transaction lock according to an embodiment of the present invention. FIG. 38 is a flowchart illustrating a method for unlocking content according to an embodiment. Figure 39 is a flow chart for describing an object interaction between components. Fig. 40 is a flow chart illustrating the unlocking of a transaction according to an embodiment of the present invention. Figure 41 is a block diagram showing object interactions between components.

[Detailed description of the preferred embodiment] Summary of the invention

According to an embodiment of the present invention, a secure electronic content (SEC) system is a solution for providing content creators, content providers, content owners, and content users to focus on electronic content. The scope of this secure electronic content (SEC) system includes: media, capable of providing read and write access to this media, encryption and access rules, encoding, decoding, meaning, connection, navigation, and presentation An engine in which the standard for each action is a seamless security system that provides electronic content. The encryption and access rules disclosed in the embodiments of the present invention are to provide an invisible and seamless ContentKeyO digital rights management (CKDRM) system, so as to preserve the data of the content and enable the content to pass through the appropriate Electronic devices are carried and operated interactively. The ContentKeyO Digital Rights Management (CKDRM) can support the reasonable use of content purchasers and users. It uses the ContentKeyO Digital Rights Management (CKDRM) to directly support the personal use of electronic content, And agree to import and export these contents. According to the disclosed embodiment of the present invention, pre-recorded and unlocked content on the media can be played through a device after it is sold, where the device is designed to represent the ContentKeyO digital rights management ( CKDRM) or other third-party digital rights management (TPDRM) methods. In order to facilitate the disclosure of the present invention, in this specification, the term "pre-recorded content" also includes the main control content. Furthermore, the pre-recorded locked content on the media can also be unlocked by a device / player, where the device / player is connected to a clearing house and operates according to an embodiment of the present invention. According to the consent information granted on the media, any player can express the content after unlocking. In addition, unlocked content can also be moved to media related to ContentKeyO Digital Rights Management (CKDRM) and expressed through a player. These embodiments further disclose that this medium can also perform a writing operation, and thus will not generate content that can be expressed by any player, but only content that can be expressed by a predetermined player. According to an embodiment of the present invention, for example, the ContentKeyO Digital Rights Management (CKDRM) will only agree to a predetermined number of pre-recorded and unlocked content copies, which are determined by the content provider, the license agreement, and the like . Furthermore, this ContentKeyO Digital Rights Management (CKDRM) can also provide a method for unlocking content and managing content to support a variety of novel content consumer experiences. The ContentKeyO Digital Rights Management (CKDRM) disclosed in the manual is a The sub-content device (referred to as "player" in the description) is implemented. The player is used to implement such ContentKeyO digital rights management (CKDRM) and interface with servers, kiosks, duplicators, and the like. The player may have an engine built-in that works with the ContentKeyO Digital Rights Management (CKDRM) to provide data security, or it can be coupled to this engine, for example: a personal computer (PC). Moreover, the player can also represent content on digital media (such as: discs). In another embodiment, a personal computer (PC) can also be used to implement a player. This ContentKeyO digital rights management (CKDRM) can also be (partially) extended by providing a flexible method of unlocking and supporting the transfer of content and rules to other digital rights management (DRM) implementations. In particular, a player implementing ContentKeyO digital rights management (CKDRM) can further implement third party digital rights management (TPDRM). In one embodiment, a player with an embedded engine can not only implement ContentKeyO Digital Rights Management (CKDRM), but also present a file system and a ContentKeyO Digital Rights Management (CKDRM) application through a general-purpose interface. Interface (API). This ContentKeyO Digital Rights Management (CKDRM) can also advantageously provide many functions, including: unlocking, playback, counting the number of copies, importing from a certificate source, exporting to a certificate destination, and storing data for metadata preservation. A secure electronic content system. The ContentKeyO Digital Rights Management (CKDRM) system also includes Data security and access rules as part of this secure electronic content (SEC) system. To facilitate the discussion of this secure electronic content (SEC) system, the terms used in this specification are listed as follows: PKI: Public Key Infrastructure. AES: Advanced Encryption Standard. API: Application Programming Interface. The term application programming interface (API) refers to the logical interface between different components. CA: Credential Management Center. The term Certificate Management Center (CA) refers to the entity that issues the certificate. Content Provider: Content provider. The term Content Provider refers to the entity that owns the content rights and participates in delivering the content to the market. DFS: DataPlay file system. In at least one embodiment of the present invention, the term DataPlay file system (DFS) refers to an open application programming interface (API). Engine: Engine. This component is used to provide read and write access to digital media. Host: Host. This device is used to control the engine. USB: Universal Serial Port. This device refers to the physical connection between the client personal computer (PC) and a link engine. MAC: Message Authentication Code. The term message authentication code (MAC) is an abbreviation of Message Authentication Code. SHA-1: Security Hash Algorithm-1. The secure hash algorithm (SHA) is It is the abbreviation of Secure Hash Algorithm, which is defined by the Federal Information Processing Standards No. 186 Announcement Document (FIPS PUB 186) of the National Institute of Technical Standards (NIST). Protected Content: Protected content. The term Protected Content is the content stored on digital media in an encrypted form under the management of ContentKeyO Digital Rights Management (CKDRM). Unlocked Content: Unlocked content. The term "Unlocked Content" refers to protected content that can be expressed on any certificate issuing device (which can express content). In this case, the unlocked content that is pre-recorded on this media can also be referred to as Primary Content. Locked Content: Locked content. The term Locked Content refers to protected content that cannot be expressed before a ContentKeyO Digital Rights Management (CKDRM) unlocking transaction occurs (it is used to change content to unlocked content). Locked content can also be referred to as Secondary Content. Key Complement: Key Complement. This information is used to complete a set of decryption keys to turn the locked content into an unlocked one. Please refer to Table 1A, which shows the interaction of various parts of this secure electronic content (SEC) system.

Table 1A: Interactive Operation Stack

101. . .User interface 102. . .Present 103. . .Guided Tour 104. . .Connected 105. . .Significance 106. . .Coding 107. . .Access rules 108. . .Encryption 109. . .File system 110. . .media

Table 1A provides an interactive operation stack, which is used to indicate the various data layers used by the ContentKeyO digital rights management (CKDRM) operation. This stack further includes a data layer provided by other third party digital rights management (TPDRM), a player with an appropriate engine embedded in it, and a player coupled to such a player. In this specification, the term "engine" refers to an element capable of providing read and write access to digital media. As such, embodiments of the present invention may include one or more implementations, such as the implementation of an engine's firmware, software, hardware, or any combination thereof. This ContentKeyO Digital Rights Management (CKDRM) focuses on the data layers 107 and 108 stacked in this interactive operation. Please refer to the data layer 110. The pre-recorded or written electronic content is combined on this medium and cannot reside on a player or an engine. The system can activate multiple methods to store data on a media disc. For example, according to one embodiment of the invention, a dish The movie can hold secure pre-recorded content, written content, or both pre-recorded content and written content on the same disc. In addition, various data can also be stored on this disc in the form of large block or small block data. Please refer to the data layer 109, this system can support a hierarchical directory structure with file data. In this way, the data written by the file system "writes" and the data returned by the file system "reads" can be stored as file data. According to an embodiment of the present invention, only data stored as a file can be accessed through an application program interface (API) of the file system. In this specification, an application programming interface (API) refers to a logical interface between various components. This file data is interpreted by using the file type representation, for example: a multifunctional Internet mail extension (MIME) string, directory, and file name. According to an embodiment of the present invention, only data stored as a file can be accessed through an application program interface (API) of the file system. The data layer 109 cannot perform complete access operations on the metadata through the read and write commands of the file system. Conversely, metadata enables an engine to support stored data outside this file system. In this way, some metadata can be seen through the host, such as: file name, MIME type, size, and attributes. Other metadata can only be exposed through the ContentKeyO Digital Rights Management (CKDRM) application programming interface (API). Furthermore, other metadata can only be seen through one engine. For example, according to one embodiment of the present invention, secret media identification Unique codes and private metadata can only be seen through one engine. The data may be related to a disc, a directory, and a file. According to this ContentKeyO Digital Rights Management (CKDRM), the engine can change and manage this metadata, and thereby update consumption to less than the available disc capacity. According to an embodiment of the present invention, the predetermined metadata is linked to the engine instead of being stored on a disc. Furthermore, this predetermined metadata is usually not accessible through the application program interface (API) of the file system. This information includes: the engine's firmware, and public and private key pairs. This set of key pairs is generated during engine manufacturing according to a secure process. According to an embodiment of the present invention, the field update of the engine private storage is supported through a secure process and supported by the ContentKeyO digital rights management (CKDRM). This secure electronic content (SEC) system can advantageously allow third party digital rights management (TPDRM) metadata to be stored with individual files, if needed. Furthermore, according to an embodiment of the present invention, any individual file may also have a plurality of third party digital rights management (TPDRM) metadata. The third party digital rights management (TPDRM) metadata may include an ownership identifier, which matches a received ContentKeyO digital rights management (CKDRM) voucher (which will be further explained in this specification), so that This metadata is accessed. In one embodiment of the present invention, the metadata of the third party digital rights management (TPDRM) is stored with each file, and therefore, a metadata system that has been used in an appropriate file system is also used. various For example: DataPlay File System (DFS). The third-party digital rights management (TPDRM) metadata node may set a bit in a file system flag definition, thereby identifying these data as third-party digital rights management (TPDRM) metadata. A metadata packet can be as shown in Table 1B. Among them, each symbol represented as "U" followed by a number is used to represent an unsigned value and a bit length of the value.

Table 1B

Type Name Description / Use Struct META * psNext Internal indicator of linked list. DFSIDDfsId File disposal with this metadata attached. DFSFLAGFlags Flags for internal use-include a bit to define this object (such as metadata for digital rights management) must be set. U16MetadataOwner must match the metadata owner of this received ContentKey token to create an identifier for this metadata ownership. SYMMETRIC_KEYMetadataKey The key used to encrypt these data U16ByteCount Metadata U8 [] Metadata The digital rights management (DRM) metadata itself

In one embodiment of the present invention, the metadata of the third party digital rights management (TPDRM) is stored in a random access memory (RAM) type memory. However, if the third party digital rights management (TPDRM) metadata is too large to be completely stored in random access memory (RAM), the present invention can use a table lookup system to assist this metadata The metadata of the third-party digital rights management (TPDRM) is replaced by the storage location corresponding to the metadata object. In addition, specific data can only be accessed through the ContentKeyO Digital Rights Management (CKDRM) application program interface (API), which includes: data managed by this engine, including the provision of playback keys and retention of copy counts Metadata. According to some embodiments of the present invention, the data that can be accessed through the ContentKeyO digital rights management (CKDRM) application program interface (API) includes: a data managed by a second third party digital rights management (TPDRM), In this example, the data format is defined using this third-party digital rights management (TPDRM). Please refer to FIG. 1, which is a block diagram for introducing a content storage model of electronic content. As shown in the figure, this electronic content can be stored and managed according to a total of five basic models. Among them, one type is represented as "unmanaged content using file system method only" 120. The unmanaged content 120 includes basic information, such as: Cleartext data, like a general computer storage model. In addition, FIG. 1 also shows "Third Party Digital Rights Management (TPDRM) Management Content" 130. This type of content can use the same methods and methods as the unmanaged content 120. This type of content includes "Third Party Digital Rights Management (TPDRM) managed content using only a file system approach" 180. In this model 180, this third-party digital rights management (TPDRM) must take responsibility for data preservation of content and metadata. Model 180 does not need to use this ContentKeyO digital rights management (CKDRM) to this third party digital rights management (TPDRM ) Is pre-certified, so any type of third party digital rights management (TPDRM) can operate the management content of this model. This model matches the model of the third party digital rights management (TPDRM) management content, but there is no data retention method. In another type of electronic content storage, third-party digital rights management (TPDRM) manages content by using file system methods to access it, but access to metadata uses ContentKeyO digital rights management (CKDRM). Just like this ContentKeyO Digital Rights Management (CKDRM) Application Program Interface (API) 182. According to this embodiment, a content storage model can provide a higher level of data security for metadata and encryption keys. Box 184 is about a model that uses ContentKeyO digital rights management (CKDRM) metadata rules and a third-party digital rights management (TPDRM) application programming interface (API) to manage content. Among them, this third Digital Rights Management (TPDRM) application programming interface (API) is used to manage the performance of electronic content. This model can provide a high level of data preservation for the content itself, while other data layer encryption is implemented using an engine. Another content storage model 140 is used to indicate that content (content and metadata) is managed using a third-party digital rights management (TPDRM) and ContentKeyO digital rights management (CKDRM) rules at the same time. This model 140 can allow an overlap between ContentKey0 digital rights management (CKDRM) management content and third-party digital rights management (TPDRM) management content. Therefore, this system can also support transparent Access through a ContentKeyO digital rights management (CKDRM) application program interface (API) and use a third-party digital rights management (TPDRM) to manage the content. The access model 150 is used to indicate that content and metadata are managed using this ContentKeyO digital rights management (CKDRM). The model 150 is to provide a higher level of data preservation for this content by never allowing metadata to leave the engine. One type of content (which applies to this model) is pre-recorded content. A third party digital rights management (TPDRM) controlling the content can select the model to use to move the content to a disc. As those skilled in the art know, the rules governing this content may limit the choice of models to be adopted. In addition, the data preservation needs to be met may also change the choice of the adoption model. Among them, the ContentKeyO digital rights management (CKDRM) model can usually provide a higher level of data preservation. Furthermore, these ContentKeyO digital rights management (CKDRM) models can also provide consumers and content providers with more effective and valuable benefits when sufficient permissions are required to manage this content. Figure 1 further shows that this system provides at least two types of content access actions. In particular, the access action 160 indicates that the content can be directly accessed if the content is accessed using a file system and is not managed. In this example, the protected content can be accessed through the application program interface (API) of the file system through the access action 160. The access action 170 indicates that the protected content can be accessed through the ContentKeyO digital rights management (CKDRM). Please refer to FIG. 2, which uses a content flowchart 200 to introduce how content (which is organized as a model in the model shown in FIG. 1) flows in this secure electronic content (SEC) system. As shown in the figure, a content provider 202 must first decide to conform to the content in the model shown in FIG. When an original production movie is produced on the media, a duplicator 204 will generate a plurality of copies for distribution. Examples of content that fits this content flow path include: music compact discs (CDs), digital video discs (DVDs), optical discs such as DataPlayTM discs, and magnetic media such as floppy disks or magnetic tapes. The duplicator 204 is a manufacturer, and it can add any necessary data to any media to enable the data security function of the content, as shown in FIG. 1. According to another embodiment of the present invention, the content is flowed from a content provider to a server 206. In one embodiment of the present invention, the server 206 is used to transfer the secure content to one or more information stations 207, directly to an engine 208 (3) to receive secure information, or to a A connection host 210 is coupled to an engine 208 (3). In one embodiment of the present invention, the connection host 210 is a personal computer (PC), which can start ContentKeyO digital rights management (CKDRM), third party digital rights management (TPDRM), and file system rules. At the same time, content will also flow from an engine 208 (3) to an embedded device 211. In one embodiment of the present invention, the embedded device 211 can enable ContentKeyO digital rights management (CKDRM) and third-party digital rights management (TPDRM). In addition, as shown in Figure 2, content flow also includes flow from one engine to Engine Another engine between 208 (2) and 208 (3). This type of content flow occurs during a copy function, which will be explained further below.

System Architecture Overview

The ContentKeyO Digital Rights Management (CKDRM) operates in the context of this secure electronic content (SEC) system. Figure 3 is a block diagram of the methods supported by this secure electronic content (SEC) system. These components include: a content provider 302, tools and processes for generating pre-recorded content 304, appropriate media (such as a disc) 306, an engine 308, the players 310 previously discussed, and the digital rights management (DRM ) 312. According to one embodiment of the present invention, these elements are organized into a system architecture whereby the secure electronic content (SEC) system is divided and assigned its responsibilities. For example, a content provider 302 is responsible for bringing in the original content and executing all variable quality-related decisions. These decisions include: those files must be locked and unlocked first; when should this file be unlocked; whether this content can be carried out using a player that implements ContentKeyO Digital Rights Management (CKDRM) or third party digital rights management (TPDRM) Playback; how many copies can be made according to ContentKeyO Digital Rights Management (CKDRM) or Third Party Digital Rights Management (TPDRM) rules; and how it should be managed in ContentKeyO Digital Rights Management (CKDRM) and Third Party Digital Rights Management (TPDRM) What rules. In one embodiment of the present invention, the electronic content system can support global third-party digital rights management (TPDRM) rules to limit one Number of subsequent copies agreed by a third party Digital Rights Management (TPDRM). In other embodiments of the present invention, the electronic content system can support a specific third party digital rights management (TPDRM). These tools and procedures 304 for generating pre-recorded content 304 are to capture all inputs from a content provider 302 and generate the appropriate digital media 306 to conform to all the requirements of the pre-recorded content. This content is then encoded into one of a plurality of formats, if not already encoded. This content is encrypted in the encryption layer using a key generated and stored by a predetermined method (as described in the description). The Metadata of the ContentKeyO Digital Rights Management (CKDRM) and the Metadata of the Third Party Digital Rights Management (TPDRM), if any, are stored according to the method described in the description. According to an embodiment of the present invention, the digital medium 306 includes: all information required to support all adoption models and the content provider 302 to designate a license. According to an embodiment of the present invention, a player 310 is a credential host 316 to receive a credential 318 from a credential management center (CA) 320. The credential 318 is used to provide an authentication part of these protocols and establish an authentication channel to access the secure application programming interface (API). The engine 308 presents an application programming interface (API) to these players 310, and presents a third party digital rights management (TPDRM) and ContentKeyO digital rights management (CKDRM) to support a plurality of adopted models. In one embodiment of the present invention, the engine 308 is implemented through hardware and firmware. Application method, and also through the use of an encryption key, thereby supporting the data preservation of the present invention. In one embodiment of the present invention, these encryption keys are proprietary to each engine, and some encryption keys are common to all engines. For example, each engine may include non-volatile memory to store a list of signature keys. In one embodiment of the present invention, the list may be an array of public keys, through which the certificate of the certificate management center (CA) is signed. In one embodiment of the present invention, using a secure application programming interface (API), the engine 308 is an endpoint on which an authenticated connection is established. This engine 308 is used to perform decryption and encryption operations on various encryption layers in the playback, copy, and delivery functions. The engine 308 can perform basic unlock transactions at the level of the disc 306. This engine 308 is used to manage playback and copy permissions, including: decreasing the number of copies on this disc 306. In one embodiment of the present invention, the engine 308 utilizes a universal serial port (USB) or an application used with these ContentKeyO digital rights management (CKDRM) and DataPlay file system (DFS) application programming interfaces (APIs). Programmatic interface (API) conforms to other interconnected drivers for operation. This driver, in an example of the present invention, enables the engine to communicate with other hosts (including players, such as personal computers), regardless of the hardware manufacturer or architecture of the host. This operating system can use a WindowsTM Register or. inf file to communicate, so that when multiple engines are connected to a host, the driver Locations in the system. In some embodiments of the present invention, the player 310 is a host portion of a device with an engine 308 embedded therein. Alternatively, a player 310 may also be an application on a platform, which is coupled to a device with an engine 308 embedded therein. In either case, the player 310 uses the application program interface (API) presented by the engine 308 to access the content and presentation information on a disc 306. The player 310 uses this information to present data to a user and present the content. To access secure content, the player 310 is an endpoint of an authenticated connection established in the secure application programming interface (API) 309. Furthermore, in order to play content, according to an embodiment of the present invention, a player 310 must also request an authentication channel after a management center 320 issues a certificate to the player 310. The process of issuing the certificate includes issuing a public key and a private key pair, and a certificate 318 to the player 310. This authentication channel may agree on access to a secure application programming interface (API) 309. As mentioned earlier, ContentKeyO digital rights management (CKDRM) and one or more third-party digital rights management (TPDRM), if the media system is structured to use third-party digital rights management (TPDRM), is used to manage rights And manage the operation of secure content. ContentKeyO Digital Rights Management (CKDRM) and / or Third Party Digital Rights Management (TPDRM) are used to implement the rules specified by the content provider 302 and stored on the disc 306. To access secure content, the ContentKeyO Digital Rights Management (CKDRM) or a Third Party Digital Rights Management (TPDRM) is An endpoint of an authentication connection has been established in this secure application programming interface (API) 309. This third party digital rights management (TPDRM) implementation is outside of this engine 308. In addition, the engine 308 provides secure storage on the media 306 through a secure application programming interface (API) 309. Furthermore, if the media system is structured to utilize third party digital rights management (TPDRM), then these third party digital rights management (TPDRM) need to be consistent with the disclosed secure electronic content (SEC) system. In particular, a compliant third-party digital rights management (TPDRM) must require an authentication channel before accessing content and security data. According to an embodiment of the present invention, the authentication channel is through: first issuing a certificate to the third party digital rights management (TPDRM), and issuing a pair of public and private keys and a ContentKeyO digital rights management (CKDRM) The credentials are then generated. The ContentKeyO digital rights management (CKDRM) certificate can include a certificate management center signature public key identification number (CA Signature Public Key ID) or public key identification code, as a certification signature key table in an engine 308 An index of a column, used in a number of different purposes, which will be explained further below. This authentication channel was created for further access to a secure application programming interface (API). Please refer to FIG. 4, which is an Open System Interconnection Model (OSI Model) 400 representing the secure electronic content (SEC) system, to provide an overview of the architecture, and then to support the functions described with reference to FIG. 2 and Other functions. In Figure 4, this layered Open System Interconnection (OSI) model 400 is It is used to indicate the paths supported by the host 310, the engine 308, and the media 306. As shown in the figure, the fourth diagram includes an entity layer 410, a command data layer 406, a data link layer 408, a dialog layer 404, and an application layer 402. Figure 4 refers to the interconnection components between a host, an engine 308, and the digital media 306 to illustrate the purpose of each data layer. Furthermore, interconnections other than the host 310, the engine 308, and the digital media 306 should also fall within the scope of the present invention. Therefore, excluding such interconnections in FIG. 4 is not intended to limit the present invention. The Open System Interconnection (OSI) model 400 is described below with reference to the electronic content flow description shown in FIG. 2. A medium 306 (such as a disc or other portable media, or a medium permanently fixed in an engine 308) includes file system file data 470, file system metadata 472, and ContentKeyO Digital Rights Management (CKDRM) Metadata 474 as part of the entity layer 410. In the host 310 and the engine 308, these data flow through the physical layer interfaces 424 and 448. The data of this medium 306 flows through a data link layer 408, which is used to interpret the data located in the optical element 460 in an optical disc embodiment. Those skilled in the art should understand that interpretation of other types of media may require other types of interpreters. For example, magnetic media requires a magnetic interpreter. In the host 310 and the engine 308, an interface protocol 422 is used to provide the data link layer 408. On the command data layer 406, a player reads or writes the medium 306 through a read / write action 454. In the host 308 and the engine 308, on the command data layer 406, the interface protocol is Based on the data read in the read / write action 454, a file system 420 and / or the ContentKeyO digital rights management (CKDRM) 430 are executed. In particular, according to an embodiment of the present invention, a host 310 must issue a certificate 413 at the application layer to perform ContentKeyO digital rights management (CKDRM) 430. The procedure for issuing credentials (which will be described in more detail below) is to determine whether the host 310 is a secure 416 or an insecure 414. A credential host can perform encryption / decryption procedures in this dialog layer 404 to authenticate a channel (which will be explained further below). An uncertified host 412 executes an insecure process 414 in the dialog layer 404 through an open file system 420. For insecure content, the engine 308 performs file and metadata mapping actions 440 on the application layer, and executes the open file system 420 on the command data layer 406. In addition, for secure content, the engine 308 not only processes the files and mapping metadata at block 440, but also uses the ContentKeyO digital rights management (CKDRM) rule 430 on the command data layer 406, through data preservation actions 416 (2) and encryption / decryption operations 418 (2) to perform encryption and decryption operations on these secure data in this dialog layer. According to an embodiment of the present invention, the host 310 and the engine 308 use a servo positioning action 452 to point a player to the media 36, and should find the location of the secure content in the dialog layer 404 to communicate with the media. Simultaneous actions. Then, these secure and unsecure data can be managed in this application layer 402 by using the block management device 450. Figure 4 is used to show that the unauthenticated host application 412 cannot access the secure session 416 (1), perform data encryption or decryption 418 (1), and execute ContentKeyO Digital Rights Management (CkDRM) command 430 ( 1) and 430 (2). FIG. 4 further shows that the certificate host application 413 can access all file system methods provided by the uncertified application through the file system 420. ContentKeyO digital rights management data preservation overview Please refer to FIG. 5A, which is used to explain this ContentKeyO digital rights management (CKDRM) data preservation overview. The ContentKeyO Digital Rights Management (CKDRM) is used to implement an effective data preservation model, where electronic content is generated and preserved through an application 516, and is represented as a file 502 and metadata 504. These content elements 502 and 504 then perform an encryption operation. Therefore, when the content file 502 is read or copied through an open application programming interface (API), an encrypted form is returned. When content is accessed for playback or passed to a third party digital rights management (TPDRM), the content is returned in a higher encrypted form. The secure content 502 and 504 are accessed through the Open Application Programming Interface (API) 506 and the Secure Application Programming Interface (API) 508, respectively. The open application program interface (API) 506 only allows thorough file read and write access actions 512; these secure metadata and unencrypted content cannot be provided through the open application program interface (API) 506. Furthermore, neither the secure application programming interface (API) 508 nor the open application programming interface (API) 506 can reveal the original content and block the media. Take it. These secure application programming interfaces (APIs) 508 must restrict access to content 502 and 504. In this way, only secure application programming interfaces (APIs) can retrieve secure metadata 510. Furthermore, this access operation is also restricted by the cancel operation in the cancel method 518. These open and secure application programming interfaces (APIs) 506 and 508 emphasize a key difference between a hard disk interface and an interface that utilizes application programming interfaces (APIs) 506 and 508. According to an embodiment of the present invention, the block-level accessing action of the media content is performed through firmware having a block driver. Block-level access to content on a hard disk in a computer can usually only be performed by a block driver. This firmware can avoid the problem of open access through the block access action that does not support the block driver. The nature of this file system can be hierarchical. In one embodiment of the invention, the media disc may have a writable, write-once portion, and a read-only portion with pre-recorded content. A media identification code may be located in one or each section, and may or may not be the same identification code. Furthermore, in one embodiment of the present invention, the identification code is read from the media disc and retrieved for application in a special application integrated circuit (ASIC) and / or firmware. This identifier can be used as a seed for an encrypted block, whether or not the encrypted block has a decryption block. In the embodiment of the present invention, the encryption block may be a triple-DES block. Please refer to FIG. 5B. According to an embodiment of the present invention, a method is related to a media including an identification code, and more particularly to a media A secure method for media capture. Block 530 is a data access operation initiated by the firmware. This data can be stored in boxes and accessed through a box driver inside the firmware. Block 532 is used to avoid data access actions other than this firmware. In one embodiment of the present invention, the firmware is included in a special application integrated circuit (ASIC). This firmware and this special application integrated circuit (ASIC) can be located inside a host. In one embodiment of the invention, the firmware may include: a third party digital rights management (TPDRM) application program interface (API), a ContentKeyO digital rights management (CKDRM) application program interface (API), and / Or a DataPlay File System (DFS) Application Programming Interface (API). Please refer to FIG. 5A again. This block diagram is used to further indicate that these secure application programming interfaces (APIs) 508 and secure content 502 and 504 must require a certificate 514 to further qualify. According to a certificate issuing procedure shown in FIG. 5C, in block 550, the host receives a certificate 514 from an entity controlling the host certificate. This certificate 514 is used to designate the secure application programming interfaces (APIs) 508 that an application 516 can access. In this embodiment, a host may include any physical device embedded with an engine, a third-party digital rights management (TPDRM), an application program running in an open computing environment, or a clearing house server . In particular, a ContentKeyO digital rights management (CKDRM) certificate is capable of performing a signing action using a private key, which is assigned based on a type of device. In one embodiment of the invention, the private key can only be used for one category, and Moreover, the corresponding public key belongs to only one type of device. These device categories can include: engines, host devices with one engine embedded but no external digital I / O ports, host devices with one engine embedded and digital I / O ports, and no engine embedded Host application. In one embodiment of the present invention, the engine may have a public key that is expected to authenticate the device, and the engine only needs to authenticate an embedded host. Please refer to FIG. 5C. In block 552, in order to start an engine-to-engine copy action, each engine must receive a voucher. In addition, the engine also needs to receive a certificate to identify a host application that does not have an engine embedded in it. In block 554, the entity controlling the issue of the certificate is the cryptographically signed certificate 514. The certificate 514 is used to indicate a category, which is used to specify the secure application programming interface (API) 508 that the certificate holder host uses to receive access commands. In one embodiment of the invention, the credential 514 is used to indicate the company that issued the credential 514. In another embodiment of the present invention, the certificate 514 may also indicate one or more categories of these engines and / or hosts, which include: product type, product line, model, revision, and serial number. Table 2A shown below is used to indicate a certificate according to an embodiment of the present invention.

Table 2A

Field number field name assignment task 1 certificate management center (CA) identification code, version is assigned by the entity that controls the issuance of the host certificate 2 Signature key identification code (ID) assigned by the certificate management center (CA) 3 Disclosure method Assigned by the certificate management center (CA) to limit the host license 4 Companies assigned by the certificate management center (CA) 5 Model identification code (ID) , The revised version is assigned by the company 6 yuan data identification code (ID) set by the certificate management center (CA) 7 host signature key assigned by the company for host signature confirmation 8 certificate management center (CA) signature confirmation all Field 1-79 No. Assigned by Tian Company 10 Agreement key assigned by the company for secure key exchange 11 Host signature assigned by the company (Host agreement public key is performed by the private key of the corresponding host signature public key (Signature) Confirm all fields 1-10

The first eight items in Table 2A are supplied to a Certificate Management Center (CA) by a company that requires a certificate. A company keeps a private key to correspond to this host signing key. The certificate management center (CA) signature is generated using a private key, which is a public key corresponding to a signature key identification code (ID). When a device is certified, the first eight items are returned to the manufacturer. The last three fields, 9-11, were added by this manufacturer. Those skilled in the art will understand after the disclosure of the present invention that this certificate is to invalidate the wrong device and the device with potential defects, and then start an entity to control the quality of the host and the engine. In one embodiment of the present invention, these fields 1-8 are issued by the entity controlling the host and engine, And provided to a device manufacturer. Later, the device maker will add fields 9-11. In one embodiment of the present invention, the types of credentials that these credentials have are capable of providing a set of methods that can be exposed, as specified by a ContentKeyO digital rights management (CKDRM) credential. Any combination of methods can be exposed using this credential format. However, what Table 2B provides is an example of a possible method that can be exposed through this category of credentials. As shown in the table, these categories can include: an engine, a player, a third-party digital rights management (TPDRM) field, a ContentKeyO digital rights management (CKDRM) original video production tool field, an information station, And a clearing house server area. These disclosure methods are third-party digital rights management (TPDRM) and ContentKeyO digital rights management (CKDRM) methods. Although any combination of disclosure methods can be used for any particular category, Table 2B shows only one possible embodiment.

Form 2B

Category Exposure Method Engine ContentKeyO Digital Rights Management (CKDRM) Copy Player ContentKeyO Digital Rights Management (CKDRM) Record ContentKeyO Digital Rights Management (CKDRM) Play Third Party Digital Rights Management (TPDRM) ContentKeyO Digital Rights Management (CKDRM) Record Third Party Digital Rights Management (TPDRM) Copy Read Security Metadata Write Security Metadata ContentKeyO Digital Rights Management (CKDRM) original video production tool, information station ContentKeyO Digital Rights Management (CKDRM) records are written to a secure metadata information exchange ContentKeyO Digital Rights Management (CKDRM) records ContentKeyO Digital Rights Management (CKDRM) unlocked

Please refer to FIG. 5C again. In one embodiment of the present invention, in block 556, a secure electronic content (SEC) system may be used to provide host authentication. In particular, in host approval, the ContentKeyO Digital Rights Management (CKDRM) security application programming interface (API) can only be accessed through a host officially approved by an entity (such as: DataPlay). In one embodiment of the present invention, the authorization action includes: In block 556, a certificate is issued by the entity (such as: DataPlay Corporation) to indicate the ContentKeyO Digital Rights Management (CKDRM) security application program interface (available) API). Table 2C below is another more precise form for providing a ContentKeyO Digital Rights Management (CKDRM) format.

Form 2C

Byte shift field name type value 0: 1 Voucher management center identifier U16 (unsigned 16-bit value) assigned by an entity (such as DataPlay) 2: 3 voucher format version U16 by the voucher management center (CA ) Assigned 4: 5 Certificate Management Center signature public key identifier U16 is assigned by Certificate Management Center (CA) The 6: 7 encrypted version U16 is assigned by the certificate management center (CA). The 8: 0 exposure method EXPOSED_METHODS: indicates that the 16 flag combinations of the table 2B method are assigned by the certificate management center (CA). Each method is coded using an assigned bit level to identify the disclosure method 10:15 Reserved 1U16 [3] Reserved 16:17 Company U16 assigned by the Certificate Management Center (CA) 18:19 Department U16 assigned by the company 20:21 Product Line U16 is assigned by the company 22:23 Model U16 is assigned by the company 24:25 Revised U16 is assigned by the company 26:27 Metadata ID U16 is set by the Certificate Management Center (CA) 28:31 Reserved 2U16 [2] Reserved 32:77 Company signature public key The public key (46 bytes) is assigned by the company. 78: 121 Certificate management center signature (44 bytes) is assigned by the certificate management center (CA). This digit is the information signed by the private key corresponding to the public key identifier signed by the certificate management center. 122: 137 device identification code U128 (16 bytes) is assigned by the company 138: 183 Agreement Public Key Public key is assigned by the company. Used by this engine to perform public key encryption in some agreement steps (such as dialog key exchange). 184: 227 Company signatures and signatures are assigned by the company. This value is the rest of the certificate signed by the private key corresponding to the host's public key. The fields in Table 2C include: the certificate management center identification code to uniquely identify the certificate management center (CA); the certificate format version to uniquely identify the ContentKeyO digital rights management (CKDRM) certificate format. Version; certificate management center signature public key identifier, which is selected by this certificate management center (CA); encrypted version, used to uniquely identify the encryption method used for this certificate; disclosure method, used to identify this ContentKeyO Digital Rights Management (CKDRM) method for certificate-approved access. Table 2D is a field (EXPOSED_METHODS type) used to indicate these disclosure methods:

Form 2D

Bit name description HOST_CKDRM_COPY indicates whether to agree to the ContentKeyO digital rights management (CKDRM) replication method HOST_CKDRM_RECORD indicates whether to agree to the ContentKeyO digital rights management (CKDRM) recording method HOST_CKDRM_PLAY indicates whether to agree to the ContentKeyO digital rights management (CKDRM) playback method HOST_CKDRM_UNLOCK indicates whether to agree This ContentKeyO Digital Rights Management (CKDRM) unlock method HOST_DRM_COPY indicates whether to agree with this third-party digital rights management (TPDRM) copy method HOST_READ_SECURE_METADATA indicates whether to agree to this method of reading secure metadata HOST_WRITE_SECURE_METADATA indicates whether to agree to this method of writing secure metadata

The fields in Table 2C include other fields, which will be further described later. A company can uniquely identify the company that issued this voucher. In one embodiment of the present invention, for example, this field size can support 65536 different companies. However, those skilled in the art should understand that a larger or smaller field should also fall within the scope of the present invention. In Table 2C, the size of this example field is used to support valid credentials for eighteen years, calculated at a rate of ten per day and 365 days per year. The company can also supply its selected departments, product lines, models, and revised values to this certificate management center (CA). At the same time, this supply information can also be used to uniquely identify the product design that issued this certificate. This certificate management center (CA) is used to set the value of the metadata identifier. These values can be used to uniquely identify secure metadata access in this method of reading secure metadata and writing secure metadata, which will be described further below. The company can also provide the host-signed public key, while letting the company retain its corresponding private key. The company signature is generated using this corresponding private key and confirmed using the company signature public key. The certificate management center signature is generated by using the private key corresponding to the public key specified by the certificate management center signature public key identifier. The last three fields can be used by this company to join on a device-by-device basis. The device identification code is a value (such as a serial number), which uniquely identifies the issuing device of the voucher. The agreement public key is selected using this company; the corresponding private key is embedded in the device. In one embodiment of the present invention, when the host public key of the ContentKeyO digital rights management (CKDRM) is used for the encryption action, the present invention uses the agreement public key instead of the company signature public key. The company signature public key can only be used to authenticate the agreement public key through the company signature. Each of the above fields can be presented as this ContentKeyO Digital Rights Management (CKDRM) voucher. Furthermore, this metadata identifier field can be used with this company field to identify a host accessing secure metadata. These values can be set according to the new value requirements from this company and using this Certificate Management Center (CA). In this certificate, these fields are the 326-bit public key values designated to carry the 163-bit elliptic curve encryption method. However, other sizes and encryption types should also fall within the scope of the present invention. In addition, the present invention can also use this certificate to find an invalid device in multiple cases. Referring to FIG. 5A, a revocation method 518 includes: transmitting a cryptographic identification code by the device through a communication channel; and receiving a credential to identify the device as an authentication device or a non-authentication device. In one embodiment of the present invention, the revocation method 518 is used to Agreement and encryption key. In particular, the revocation method 518 is used to rescind compromise certificates and private keys. In one embodiment of the present invention, the information related to whether the certificate and / or the private key has been revoked is stamped on this medium. In this way, the abolition can be performed in a separate, disconnected environment. As shown in FIG. 5A, application program interfaces (APIs) 506 and 508 can perform encryption operations. Furthermore, the encryption key used by the content / application programming interface (API) can also perform encryption operations. By encrypting the content, the open file system can read and access the files containing the content. The file system reads and transmits the encrypted content without a decryption key. When accessed through a security protocol, this content can be transmitted in a different form than the stored form. Thus, according to an embodiment of the present invention, even if the playback key is compromised, it will not contain sufficient information to decrypt any open application program interface (API) file. According to another embodiment of the present invention, the encryption key is linked to the medium. Therefore, content access will follow this media, and access rights will be limited to a specific playback device. In this embodiment, the key link not only stores the keys on this media, but also encrypts those keys of the media identifier. Therefore, if the content that is suspected to be encrypted is compromised (if) the linked playback or copy key is compromised, it will not have sufficient information to decrypt the content. Please refer to Figure 5C, which is a flowchart to show how to link keys to this media. As shown in the figure, block 522 is a description of: a kind of data on the content stored on the media The method of preservation includes the step of attaching content rights to this media. Attaching content rights to this media precludes the possibility of content being loaded into a player or engine. In contrast, a player or engine can only operate to represent the stored content on this media. Block 554 is used to agree to an access action under a predetermined condition. This content access action (as described in block 554) may perform one or more of the following actions, including: content playback, content copying, allowing one or more copying, or a limited number of copying. In block 554, the specified predetermined conditions may include: an authentication procedure shown in FIG. 6, or may include: identifying a channel for content transmission, checking an abolition list, and unlocking the content. In one embodiment of the present invention, the unlocking action is based on a method performed between an engine and a server, which will be further described later. The unlocking operation, when connected to a server, may be limited to: follow a protocol to retrieve a security key, and use the security key to perform an unlocking operation on one or more parts of the content. Block 556 is used to perform one or more of the following actions, including: identifying a channel, checking an invalidated list, and unlocking content. FIG. 6 illustrates an embodiment of an authentication procedure 600. According to this embodiment, the three elements required to issue a certificate include: a media 602, an engine 604, and a host 606. The host 606 is used to hold a certificate 610, which has a public agreement key issued by a certificate management center (CA). In addition, the host 606 also holds a protocol private key 612. This certificate 610 is using this engine 604 via a The communication channel is for receiving, and the signature on this certificate is confirmed at block 612. Please refer to Table 2C and Figure 6. A certificate is confirmed in two steps. First, the signature is confirmed in block 612. In one embodiment of the present invention, except for the last three fields, all fields are public keys designated by using the field Certificate Management Center signature and the Certificate Management Center signature public key identifier in box 612. Undergo verification. Therefore, the authentication of these fields (including the company signature public key) can be established. Second, in block 612, the host must also be identified. In one embodiment of the present invention, the entire certificate is confirmed using a company signature and a company signature public key. Therefore, this confirmation procedure is a double confirmation procedure. In block 614, the host must perform the abandonment action after confirmation. The revocation action can be applied to all scopes of this voucher, for example: all fields. In one embodiment of the present invention, the part of the authentication action must check a revocation list 608 on the medium 602. The engine 604 retrieves the revocation list 608 from the media 602. If the authentication program 614 can pass the block 616, the engine 604 will generate a random number through a random number generator 618 to obtain a first part of a secure session key 620. The engine 604 can then use the first part of the secure session key 620 and a protocol public key 624 retrieved from the certificate to perform a public key encryption action 622. The host 606 then retrieves the encrypted session key, decodes the encrypted session key at block 626, and generates the secure session key 628. Please refer to FIG. 7A and FIG. 3, which show a device for performing this confirmation procedure. In one embodiment of the invention, the device is part of the engine 308. Figure 3 is used to introduce: a communication channel is used to couple this engine 308 to a host holding a credential 318. The credential 318 can then be received, and an identification code 710 (which can be implemented as a public key) can also be compared within the engine using a confirmation function 720. In particular, the confirmation function 720 also receives the identification code and an output from an authentication engine 730 at the same time. The authentication engine 730 is used to generate a global pass / fail indication, which is further output to the confirmation function 720. If the confirmation function 720 receives a failure indication from the authentication engine 730, it will refuse further content access actions. If a global pass instruction is received, the confirmation function 720 sends a pass instruction to the permission block 750. The permission block 750 includes a plurality of pass / fail permissions for the player 310, which can be provided to the authentication engine 730. After processing these permissions, the authentication engine 730 outputs a session key 780 to agree to the data transfer. According to an embodiment of the present invention, each time a device is coupled through a communication channel, an authentication program is started. Each device must perform an authorization action each time it receives this encrypted identification code. Thus, a method for issuing a credential to a device includes transmitting a cryptographic identification code of the device through a communication channel, and receiving a credential to identify whether the device is an authentication device or a non-authentication device. Please refer to Figure 7B, which is expressed in the form of a program diagram: safe on a channel A way to send data. This method of identifying the destination of the data includes: extracting a credential for the destination in block 702, and using an identification code to authenticate the destination in block 704. This method continues to send a conversation key in block 706. This conversation key can then agree to the transmission of data based on predetermined conditions in this certificate. As mentioned earlier, this certificate issuing procedure is used to issue certificates to the host and the engine, and this authentication procedure is used to authenticate the host and the engine. The authentication action enables one entity to confirm and authenticate another entity. The result of a successful authentication is that one entity can know this public key and other attributes of another entity. Successful authentication can also establish an authentication channel, so that the permitted secure application programming interface (API) can be exposed through this authentication. According to an embodiment of the present invention, the host is one of the following, which includes: a player, a player in a personal computer (PC), a player in a device, and a clearing house , A server, and a third-party digital rights management (TPDRM) application. According to an embodiment of the invention, an obsolete list is stored on a medium inserted into an engine. This revocation list is used in this certification process. Therefore, if a known serial number of a device is about a compromised or subsequently rejected manufacturer, the host cannot be authenticated. In another embodiment of the present invention, the revocation list may also be copied in various devices, so as to prevent the device from being unplayable, or the revocation list may be maintained as media-related. As such, when discs are released on pre-recorded content, or when blank discs are manufactured, new The revocation list can be included on these discs, so as to find appropriate players and hosts, and refuse to certify these players and hosts. In addition, in another embodiment of the present invention, the revocation list can also be maintained through a server, so that the player communicating with a server can directly change the state (such as: unlock and lock) during the state change Receive an updated revocation list on this engine. In another embodiment of the present invention, a plurality of revocation lists are stored on the medium in a file-by-file manner, so that one or more files on the medium can have a revocation list associated with it. Column. In this embodiment, the access action (s) for abolishing the list does not occur during an authentication process, but occurs during a file access process, or during an authentication process and a file access process. A combination period. Please refer to FIG. 7C, which is used to provide a method for abolishing a content presentation device. Figure 7C begins at block 712, where an abolition list is evaluated during a file access operation. In one embodiment of the present invention, each file may have a list. The copying entity is further limited by storing details in detail and providing a list of identification codes or indicators to each file. In addition, these files are limited. An identifier or indicator is a place to refer to complete details related to revocation information. This revocation information (hereafter referred to as a node) is centralized with a unique identification code. Each file can optionally have a list node identifier without storing complete revocation information. In block 714, during a file access and revocation information evaluation, the results of each node are added To save. This identification procedure may include: reading the evaluation result, rather than re-performing an evaluation action, that is, each node can be evaluated in advance. In an embodiment of the present invention, as shown in block 716, the revocation list is copied to the engine by the media, and may include a "poison" to prevent a player from performing a playback action, provided that the player does not An appropriate player, the manufacturer has a defect or potential defect, or in such cases. When a player is connected to a server to unlock the content, the revocation list can be updated, as shown in block 718. In one embodiment of the invention, the revocation of a content presentation device must include at least the revocation of one or more signature keys. In this embodiment, the revocation of the signature key (s) will also invalidate a set of ContentKey (R) Digital Rights Management (CKDRM) certificates issued using the key (s) in block 722. In particular, the revocation of a signature key will also invalidate any corresponding signatures. In one embodiment of the present invention, the key signature list stored in the non-volatile memory of an engine cannot be updated outside a manufacturing process. In this embodiment, the key signature list can be obtained by repealing the ContentKeyO Digital Rights Management (CKDRM) certificate management center signature public key identifier field with a specific index value in a media (per -media). Please refer to Figure 7C again. The abolition list is used to provide a mechanism to avoid access to the ContentKeyO of a given device or a group of given devices. Digital Rights Management (CKDRM) method. This ContentKeyO Digital Rights Management (CKDRM) revocation method enables revocation actions to occur in any field of this host certificate. Therefore, revocation can be as explicit as a single device identifier or a public key agreement, or as broad as an entire company, or it can be a specific product line, or it can be a specific product model, such as block 724 As shown. As mentioned earlier, each file can have an associated revocation list. This revocation list is related to this file in a create-file command. This revocation list is transmitted to this destination for copying during the ContentKeyO Digital Rights Management (CKDRM) copying method. A revocation list can be composed of the revocation node of a list. Each abolition node is composed of a list of clause nodes and a method of how to combine these clauses to determine whether the node is abolished or not. Each clause node is composed of a set of data and functions. Among them, these functions are used to define how to apply and evaluate these data to compare with the content of a receipt ContentKeyO digital rights management (CKDRM) voucher. Field. Please refer to Figure 7D, which is used to illustrate the abolition of the evaluation action. Block 732 is to evaluate the content of a ContentKeyO digital rights management (CKDRM) voucher, based on the function result of a true and false result, to provide data evaluation in a clause node. Subsequently, a set of results obtained by these clause nodes will perform a combined action in block 734 according to these clause rules, thereby obtaining a true and false result of the abolition node. If any revocation node is evaluated in this revocation list If the quantity is true, the host is discontinued in block 736. Table 2E is an example used to provide an abolition list.

Form 2E

Byte shift field name type value description / purpose 0: 1 byte count U16 (unsigned 16-bit value) i includes the number of bytes in the abolition list of this field, i. This value must be greater than or equal to 4. This node count field must exist. 2: 3 node counts the number of U16j nodes in this revocation list, j. 4: i-1 invalidate the node table REVACATION_NODE [j] each entity defines a revoked node

Table 2F is an example used to provide an abolition node structure.

Form 2F

Byte shift field name type value description / purpose 0: 1 byte count U16k includes the number of bytes in the abolition list of this field, k. This value must be greater than 4. Blank clause lists are not allowed. This value must be less than 1500. The size of the revocation node cannot exceed 1500 bytes. The 2 clause counts U81, the number of clauses in the abolition table. 1.3 The clause rule U8 defines the rules related to the evaluative sentence combination. Please refer to clause rule encoding to get the required value. 4: k-1 clause node list CLAUSE_NODE [1] Each entity defines a clause.

Table 2G is an embodiment for providing a clause node structure, which is used to support complex functions with a common format.

Form 2G

Byte shift field name type value description / purpose 0: 1 byte count U162m + 4 includes the number of bytes in the abolition table for this field, 2m + 4. The value m must be positive. Blank function data arrays are not allowed. The 2: 3 function U16 executes the function of this repeal clause. The only function defined is the matching function. 4: 2m + 3 function data U16 [m] uses m characters of data to execute this function.

Table 2H is used to provide an example clause node, which is used for a matching function.

Form 2H

Byte shift field name type value description / purpose 0: 1 byte count U162n + 8 includes the number of bytes in the abolition list for this field, 2n + 8. This value n must be positive. No blank matching data array is allowed. The 2: 3 function U16 matches the function that executes the abolition clause as the matching function. The 4: 5 start character U16 in this ContentKeyO digital rights management (CKDRM) voucher indicates the displacement of the starting position of the matching function. 6: 7 character count U16n Number of matching characters at the beginning of the shift start character n8: 2n + 7 Matching data U16 [n] The number of n characters matched

In one embodiment of the present invention, an engine receives the revocation list during the CKCMD_CREATE_FILE or CKCMD_SET_KEYBOX command. The revocation list of multiple files may also include revocation nodes that already exist on this media. In this media, a revocation list can be viewed as an object inside the DataPlay File System (DFS), maintained using a separate and distinct process (not a file or directory). The DataPlay file system identifier (DfsId) field can be used as a reference number for the file, and can be used in the RevocationIdList field of the ContentKey metadata structure. For the purpose of this embodiment, Table 2I is used to represent an example of the abolition node structure.

Form 2I

Type name description / purpose struct META * psNEXT Links the internal index of the list DFSIDDfsId The disposal of this abolition node DFSFLAGFlags Internal use flag-Sets a bit that defines this object as an abolition node U8Evaluation Result represents a three-state flag of revocation, non-revocation, and evaluation REVOCATION_NODERevocation Node The actual data contained in this revocation node and transmitted by the host

Please refer to Figure 7E, which is used to provide: a method performed by an engine when rendering an invalidation list. Block 752 is used during the setting of the ContentKey Digital Rights Management (CKDRM) metadata to use this node count value to generate enough memory space to accommodate a 16-bit identifier for a list of columns, and then refer to each abolished node. In block 754, for each node in the revocation list, the engine compares this node with each node in the existing revocation list. In block 756, if an identical node is found, the number of DataPlay file system identifiers of the existing node is added to the revocation list of the ContentKey Digital Rights Management (CKDRM) metadata structure. In block 758, if this node cannot be found, a new node is generated with a unique DataPlay file system identifier. In block 762, the engine adds the new DataPlay file system identifier value to the ContentKey Digital Rights Management (CKDRM) metadata structure. Please refer to Figure 7F, which is a detailed description of the evaluation method for abolishing the listed results. As shown in the figure, in block 772, the revocation list is evaluated every time the CKCMD_AUTHENTICATE command occurs, or when a piece of new media is inserted into the engine. In block 774, the revocation list is evaluated against a received ContentKey Digital Rights Management (CKDRM) certificate. For each item in this repeal list Nodes, in block 776, this evaluation action can obtain an abolition or non-abolition status of the node. Because nodes are archive-related, these states can be evaluated each time a ContentKey Digital Rights Management (CKDRM) operation is attempted, which is proprietary to a particular archive. Therefore, the decision to abolish the result does not depend on CCKMD_AUTHENTICATE, but on CCKMD_DRM_PLAY, CKCMD_GET_METADATA, CkCMD_GET_PLAY_KEY, CKCMD_PLAY, CKCMD_RECORD_APPEND, CKCMD_SET_KEYBOX, CKCMD_SET_METADATA, and CKCMD_UNLOCK_FILE. These commands will be explained further below. In block 778, the results of the evaluation are stored in an evaluation result field of the result of the revocation node.

Original movie maker

Another part of this data security system is the need for an original video production process. In one example, the media disc described in the description organizes the content according to the method shown in Figure 7G. As shown in the figure, the method begins at block 782, where the content is organized on the media using a predetermined application. In one embodiment of the invention, the application program uses a server key attached to a machine to execute a tool. Inside this server key, a special purpose integrated circuit (ASIC) with an embedded random key generator can be used as a secret key generator. In another embodiment of the present invention, the application program is not part of the original video production process, but is transmitted to a third-party writing tool room as a dynamic-link library (DLL) of the third-party writing tool room Or library. This dynamic link A library (DLL) or library may require a third-party authoring tool room to authenticate itself before generating ContentKey Digital Rights Management (CKDRM) content. In another embodiment of the present invention, the server key and the application program work together so that the server key is not performed outside a dynamic link library (DLL) or a specific registered version of the library. action. In one embodiment of the invention, the application program generates a public identification code and a ContentKey Digital Rights Management (CKDRM) identification code, as shown in block 784; in block 786, encrypts the content files; in In block 788, add engine-managed copy and play rules as specified by the content owner; in block 792, add third-party digital rights management (TPDRM) proprietary rules as specified by the content owner; In block 794, a revocation list is added to take care of the content data preservation. However, as those skilled in the art will understand, the functions performed by this master application can also include some, all, or even one of the previously provided functions. The application described above can be part of an original movie production action, a writing action, or a pre-recorded portion of a media disc. So, for example, this application can include a commercial method of generating locked and unlocked content on a disc, where the original video production process follows a writing process, which further follows a pre-recorded process . In one embodiment of the present invention, the use of the original film content on this disc is used to provide a way to pretend to detect a fake disc as a pre-recorded disc Methods. For example, as described below, in one embodiment of the present invention, an identification code of at least a part of an identification code of a pre-recorded disc is pre-recorded. In this way, the identification code can be pretended to be detected as pre-recorded, as further explained in the instruction manual. Please refer to FIG. 7H, which is a flowchart using a flowchart to represent a process (including an original movie production process including generating media and setting an information exchange type server). This procedure begins with block 7002. Block 7004 is used to provide a newly published asset and information procurement process. Block 7006 is used to enable one or more of the following data to be transferred to the media, including: content files, metadata information, security information, and software collection information. A content file can include a file that a consumer or user will play and any asset files associated with specific content. In one embodiment of the invention, the procedure assumes that all files are encoded using a suitable media codec. This metadata information can include graphics and lyrics. In one embodiment of the present invention, this information is provided in a structured format, which is a standard format that may or may not be all content providers. In one embodiment of the present invention, the metadata is based on a per-track or per-media basis. The security information transferred to this media is used to provide: rules that govern how consumers or users can interact with the content. Interaction with content can include copying, presenting, and processing content, such as, for example, adding annotations to a border area or adding an electronic focus to an electronic book. In one embodiment of the present invention, these rules are a revocation list and a third party digital rights management (TPDRM) rule used to provide a third party digital rights management (TPDRM) method. These third-party digital rights management (TPDRM) rules are designed to provide consumers with rules that may be restricted when playing and copying content. These third-party digital rights management (TPDRM) rules include additional details to enable authoring and original film production programs (as described in the instructions) to receive information related to the original locked files. In one embodiment of the present invention, a revocation list is defined by a content provider, and the revocation list is used to provide all player devices, player applications, and servers for a list. Devices, all of which have been abolished for some reason determined by an abolition entity. The software collection information is used to provide a specification that explains how any secondary content is grouped and how the software collection information should be displayed to a user or consumer. The information collected by this software package must include the specifications of each software package, such as display images and software package descriptions. Block 7008 is used to provide a writing process in which all files provided by a content provider are packaged according to predetermined specifications. In one embodiment of the present invention, the specifications include: organizing the data into a directory structure, such as a DataPlay Mass Memory File (MMF) directory structure. In a specification, this structure needs a directory, which includes: a coded content file, a directory structure, a content management device, an autorun.inf file, and a content.ddl file. In particular, this content management device is used to provide files. For example: an executable file, a micro-site, or a ownership or form defined by a content provider to present content on the media to a consumer or user. The autorun.inf file is used to provide the information of the automatic operation device described in the manual and the interactive device that launches the content management device. The content.ddl file can include a software package collection, advertising, and software package storage unit (SKU). In particular, a software package collection may include a unique identifier for all secondary content on one side of a medium, and may also include a reference to one or more advertisements. These ads can be grouped as a software package and provide a rendering layer to display this secondary content and proposal. A storage unit (SKU) described in the specification may be defined by a content provider and may reference one or more archives of the medium. The large-memory file (MMF) data description language (DDL) file includes files describing the relationship between the content and asset files. As part of writing a program, a content provider must choose whether to use one ContentKey Digital Rights Management (CKDRM), Third Party Digital Rights Management (TPDRM), or a combination of two Digital Rights Management (DRM). After the digital rights management (DRM) method is selected, according to this digital rights management (DRM) method, the content file can be encrypted and packaged with all the content and files required by the software to enable this selected digital rights management ( DRM) can operate appropriately. Block 7012 is used to provide a pre-recorded program, in which an original movie file set is stored and transmitted on a medium (such as a tape). In one embodiment of the present invention, each file group can provide a One side of each media disc. Another procedure executed in this pre-recorded program is: generating a keyComplement. Dll file to construct a secure database, such as the secure database of ContentKey Digital Rights Management (CKDRM). The keyComplement. Dll file can have a software collection identifier, which includes a complete file path, a file disposition, and a key complement, such as a 128-bit number and a key version complement. Finally, the pre-recording procedure includes transmitting the content.inf file. Blocks 7022 and 7026 are used to transfer the set of original film files on a medium (such as a tape) to a glass original film, so that the content is stamped when a media disc is produced (in block 7026). These original glass films produce one or more stamping machines to mass produce these media discs and distribute them to consumers and other users. On the server side, block 7020 is used to enable an original video server to receive data from a secure database. In particular, a server program includes package software that loads a key complement and a key mapping database table (which has the information specified in the keycomplement. Dll and content. Dll files). Please refer to FIG. 7I. The program described in FIG. 7H can also be executed by another program, which can be executed simultaneously with the program described in FIG. 7H. In particular, Figure 7I is used to generate a packaged software collection, packaged software advertisements, and storage units (SKUs), which will be provided during the Figure 7H process. Block 7028 is used to provide a starting action for this process to set up an Internet retailer (eTailer). Block 7030 enables a content provider to perform a software package setup and a change procedure "package software definition". In particular, in blocks 7032 and 7034, the content provider supplies a content.ddl file 7034 and software package display graphics and data 7032 to the retailer (eTailer), which can be presented to a consumer or user A part of a software package. Generally, retailers (eTailer) will be interested in a package collection collection unit (packageSKU). A retailer (eTailer) may not be interested in a package collection ID (packageCollectionID), which is transmitted to the retailer (eTailer) through a global resource locator (URL). A retailer (eTailer) may send the package collection ID (packageCollectionID) to an information exchange server and then discard it directly. Block 7036 is used to enable a retailer (eTailer) to create and change the pricing of packaged software based on the packaged software marked as a content provider. In one embodiment of the present invention, the framework database action performed by using package software pricing and package software presentation is performed by a retailer (eTailer) in whole or in part, so that the framework action can interact with the retailer ( eTailer) matches an existing format (such as a "shopping cart" or "catalog maintenance" format). Another architectural action performed by a retailer (eTailer) may include: selecting a designated discount model and advertising marketing. This embodiment enables a retailer (eTailer) to Users for ad marketing. Another feature of data security provided by this secure electronic content (SEC) system is the application of one or more random number generators. As mentioned previously, in one embodiment of the present invention, a random number can be associated with the media through an original film making process. In another embodiment of the present invention, a random number generator may also exist inside an engine. For example, each generated engine may include holding a random number of non-volatile memory. One way to generate this random number is by using high-quality generation software, such as software compatible with Federal Information Processing Standards Bulletin 186 (FIPS-186). This random number generator inside an engine can accept seeding from one or more technologies. For example, a seed can be a random number when an original movie is generated; a random number when the engine is manufactured; a random number generated and embedded in the firmware; a public face identifier (PublicSideId); A number generated by a number of roll-up times; a number generated by a number of servo-corrected time; a search time; a bridge certificate management center (BCA) field; long-term collection of data (such as: count-up, read / Write error rate, or the like); a number generated by servo / read / write correction values stored in non-volatile memory and manufacturing processes; calculated read-write-read Take the number produced by the timing; the number produced by the input of the analog-to-digital converter; and any number that may be a function of the above.

Functions between an engine and a host

Now refer to Table 3, which is a function used to introduce an engine and a host to exchange information. This host can be a player, digital rights management (DRM), kiosk, or server. In a replication mode, it will be further explained that a destination engine is a host.

Table 3

ContentKey Digital Rights Management (CKDRM) Functions Third Party Digital Rights Management (TPDRM) Functions DataPlay File System (DFS) Functions ContentKey Digital Rights Management (CKDRM) Play 12 Third Party Digital Rights Management (TPDRM) Play 320 File System Write 374 ContentKey Digital Rights Management (CKDRM) Unlock 360 Third Party Digital Rights Management (TPDRM) Copy 340 File System Read 372 ContentKey Digital Rights Management (CKDRM) Copy 330 Record Unlocked Content 362 Record Locked Content 364 ContentKey Digital Rights Management (CKDRM) Record 350

As shown in Table 3, these main functions include: ContentKey Digital Rights Management (CKDRM) Play 312, Third Party Digital Rights Management (TPDRM) Play 320, ContentKey Digital Rights Management (CKDRM) Copy 330, Third Party Digital Rights Management (TPDRM) copy 340 and record content 350, including: record lock content 364, record unlock content 362, and ContentKey Digital Rights Management (CKDRM) unlock 360. A media can optionally hold both content 362 and 364, borrowing As pre-recorded ContentKey Digital Rights Management (CKDRM) content. These authoring, pre-recording, and original video production tools each play a role. For example, a content provider can specify these ContentKey Digital Rights Management (CKDRM) features, which include: locked / unlocked status, play / unplay status, consent to the number of ContentKey Digital Rights Management (CKDRM) copies, consent to The number of three Digital Rights Management (TPDRM) copies and the number of copies a third party Digital Rights Management (TPDRM) can obtain from its copies. Other third party digital rights management (TPDRM) can be specified by a specific third party digital rights management (TPDRM).

Play function

In particular, the ContentKey Digital Rights Management (CKDRM) playback function 312 can allow unlocked, playable ContentKey Digital Rights Management (CKDRM) content to be played on any player. The ContentKey Digital Rights Management (CKDRM) playback function can transfer electronic content from an engine to a player, and it also accompanies the decryption and representation of the information required for this transmission format. This engine is used to manage: whether there is a license for this playback function 312. In one embodiment of the invention, the function 312 does not decrement a play count. Conversely, the release of released and playable ContentKey Digital Rights Management (CKDRM) content will not be counted or limited in time. Please refer to FIG. 8, which uses a flowchart to introduce the application process of the ContentKey Digital Rights Management (CKDRM) playback function 312 Interface (API). The application program interface (API) will require that a player or host must issue a certificate in accordance with a procedure for issuing a certificate before opening the application program interface (API). This host cannot store the content in any way that allows any other entity to access it, even if the content is encrypted in advance before authenticating the host. This application programming interface (API) does not allow the player to temporarily store the decrypted content or transfer the decrypted content through an insecure channel. According to a host authentication procedure 810, block 804 is used to enable a host to transmit a credential that authenticates a host. An engine coupled to the host in block 806 is used to transmit a session key 830. After the authentication process, the engine will select a decryption and playback session key 830. Block 832 is used to transmit a playback session key from the engine to the host (such as a player). A player then receives the decryption key for this playback session for a particular file. Block 834 is used to illustrate that a host uses a session key to decrypt the playback session key. Block 840 is used to illustrate: This player is used to receive encrypted content. Block 850 is used to explain: The playback session decryption key received at block 832 is used to decrypt the content. Unlike the ContentKey Digital Rights Management (CKDRM) playback function, this third-party digital rights management (TPDRM) playback function 320 enables unlocked ContentKey Digital Rights Management (CKDRM) content to be performed through a third-party digital rights management (TPDRM) Play. This third-party digital rights management (TPDRM) playback function 320 is used to transfer electronic content from An engine sends this third-party digital rights management (TPDRM), along with the information needed to decrypt and present the transfer format. The permission management action of this function is implemented using this third party digital rights management (TPDRM). This ContentKey Digital Rights Management (CKDRM) does not decrement the play count or check for time limits and any other regulatory requirements. Conversely, this third party digital rights management (TPDRM) can also manage and / or change its own metadata as part of its playback function.

Copy function

Another function is the ContentKey Digital Rights Management (CKDRM) copy function 330. When the copy permission is retained, the function 330 enables the pre-recorded and unlocked content to be copied from one medium to another. The ContentKey Digital Rights Management (CKDRM) copy function 330 decrements the number of licensed copies retained on an original medium. In particular, in one embodiment of the invention, ContentKey Digital Rights Management (CKDRM) is used to generate a limited number of copies. Any copying action performed via the media (which has a limited number of copies using this ContentKey Digital Rights Management (CKDRM) copy function 330) will share the amount that this original copy can be played in any player. However, these copies themselves may not be copied. A content provider can optionally specify the number of copies that can be made by one original. Whenever a copying operation is performed, the ContentKey Digital Rights Management (CKDRM) copying function 330 will decrease the allowable copying number. Please refer to Figure 9, which is used to introduce the method of ContentKey Digital Rights Management (CKDRM) replication application program interface (API) agreement. Block 910 is used to provide authentication for this destination engine. In particular, a source engine confirms that the destination is indeed an authenticated engine, so that secure content is not arbitrarily published. Block 920 is used to allow the destination engine to send a media identifier to link the new copy. Block 930 is a key box used to transmit this destination. In block 930, the destination engine receives the keys needed to use the content. In particular, these keys are the decryption keys for playing this content. In one example, these keys are transmitted in a way that is pre-linked to this destination media. Block 940 is used to copy this encrypted content. DataPlay File System (DFS) commands are used to copy this content. In one embodiment of the present invention, the replication function 330 is supported in an environment with one engine and sufficient buffering (for temporarily storing content), or in an environment with two engines. The third-party digital rights management (TPDRM) copy function 340 can enable a third-party digital rights management (TPDRM) copy to unlock content, provided that the third-party digital rights management (TPDRM) copy permission is retained. This third-party digital rights management (TPDRM) copy function 340 decrements the number of licensed copies retained by a source file. Unlike the ContentKey Digital Rights Management (CKDRM) copy function 330, the third party Digital Rights Management (TPDRM) copy function 340 is used to generate a limited number of copies. These resulting copies are managed by this third party digital rights management (TPDRM). A content provider can be used to specify a The number of copies that can be performed for each file. To receive a copy of the content, a voucher's third-party digital rights management (TPDRM) is the content key digital rights management (CKDRM) field that copies content to the third-party digital rights management (TPDRM). Subsequently, the transmitted content is encrypted, and the corresponding decryption key is also transmitted to the digital rights management (DRM) received. FIG. 10 is a diagram for explaining a third-party digital rights management (TPDRM) copy method according to an embodiment of the present invention. Block 1010 is used to perform a host authentication procedure. In particular, as shown in Figure 6, an engine is used to confirm that a host is a digital rights management (DRM) of a credential and is trusted to receive content. Block 1020 allows a third party digital rights management (TPDRM) to specify what the third party digital rights management (TPDRM) requires to receive. An engine manages the number of licensed copies based on the number of starts specified by a content provider and the number of previously transmitted copies. In block 1030, an engine responds to a valid request by transmitting keys (this content must use these keys for decryption actions). The key transfer is a necessary action of a third party digital rights management (TPDRM), and the number of reserved license copies is decremented. Block 1040 allows the third party digital rights management (TPDRM) to receive the content, which is encrypted using the key just sent.

Record function

Another function provided by the ContentKey Digital Rights Management (CKDRM) is to record content 350. Recording content 362 Content providers who record first and make the original video can provide electronic content to copy as unlocked content. Data imported as unlocked data is readable and encrypted. In contrast, recorded content 364 allows content providers who write, pre-record, and produce original movies to provide electronic content, which can be copied as locked content. This content cannot be played unless it is unlocked. However, the locked content can also be unlocked using the ContentKey Digital Rights Management (CKDRM), and the content obtained can have the same quality as the unlocked content. The ContentKey Digital Rights Management (CKDRM) record 350 further includes the field of importing ContentKey Digital Rights Management (CKDRM) from an information station, a player, or a third party Digital Rights Management (TPDRM). With this form, this content can be played in any player. Other types of ContentKey Digital Rights Management (CKDRM) records 350 include: obtaining content via electronic distribution, and playing the content on a player. Figure 11 is used to introduce a method of recording content. Block 1110 is based on an authentication process to provide a source that is one of the following components, including: a third party digital rights management (TPDRM), player, server, or kiosk. Block 1120 is used by the source to decide whether to apply a system write protocol or a ContentKey Digital Rights Management (CKDRM) record protocol to the content to be imported. In block 1130, in a file format, to encrypt operations and to use a ContentKey Digital Rights Management (CKDRM) to record the application world The part of the API that performs the write operation is transmitted according to this ContentKey Digital Rights Management (CKDRM) agreement. In block 1140, the portion to be left unencrypted is written using the application program interface (API) of the file system. Content management can be brought into this ContentKey Digital Rights Management (CKDRM) field in three ways. One way is to use a third party digital rights management (TPDRM), which is used to manage this content and can be passed as ContentKey digital rights management (CKDRM). Another way is to create a server that manages the content and uses the ContentKey Digital Rights Management (CKDRM) recording protocol. In contrast to this unlock method of ContentKey Digital Rights Management (CKDRM), records must transfer all content information. The third way is to build a kiosk. In one embodiment of the present invention, the information station has its own engine and functions, such as: a server with one engine.

Unlock function

ContentKey Digital Rights Management (CKDRM) unlock 360 is another function shown in Table 3. In one embodiment of the invention, this unlock function 360 can only be applied to locked content. An application that can connect to a clearing house is required in this unlocked transaction. When a user operating a medium (such as a disc) meets a predetermined transaction requirement, a secure method changes the state of the content on a medium from a locked state to an unlocked state. According to an embodiment of the present invention, the locked content can be changed to an unlocked state through an authorized transaction. These authorization transactions include: Those transactions performed by the provider's selected rules. For example, a content provider can control whether content is played and the number of copies that can be performed through third party digital rights management (TPDRM). Pre-recorded content in a locked state can also be unlocked. In one embodiment of the invention, in the locked state, the set of keys on the medium is not sufficient to represent the content. This unlock method is used to transmit the complement of these keys. In another embodiment of the present invention, the unlocking method is used to transmit data that can match the keys on the medium, so as to prove the authenticity of the clearing house. This data can also be called key complement. Figure 12 is used to introduce a method to unlock the content. In particular, block 1210 is used to provide the first step in this method by which the source and destination are interactively identified. Method 1220 is used to enable a source (such as a server) to retrieve a media identifier associated with the content. Block 1220 is used to allow this source to specify the content to be unlocked and the complement of the encryption key. Block 1230 is used to enable the destination (such as an engine) to manage the validity of the request through a server according to the specifications provided by a content provider. In one embodiment of the present invention, the server performing the unlocking action must have the content provider designate a legitimate source of unlocking when writing and original video production of the medium (contents are stored therein).

File system functions

A default function of ContentKey Digital Rights Management (CKDRM) is This file system 374 is managed using Table 3, as described above. This file system is able to grant file-level access. The application program interface (API) of the file system does not participate in rule management or the encryption method used by the ContentKey Digital Rights Management (CKDRM). These file system functions include a file reading function 372. In particular, only the data in this file storage area can be read by this file system and by any device. In an embodiment of the present invention, an engine interface and the file system are open architectures, which have an application program interface (API) of a file system, which can be opened without requiring an authentication host. According to an embodiment of the present invention, the file system read function 372 can be used by any host (such as a player), so that an authentication connection does not need to be established and an encryption method is not required (it is located in an engine) In the case of data access. The write function 374 is used to identify a file system write function, so that a device can write data into the file system storage area through an application program interface (API) of the file system. Unlike the read function 372 of the file system, the write function 374 is selectively part of an open architecture, so that an engine interface and the file system can be opened and the file system's application program interface (API) can also be performed without the need to have an authentication host. This file writing function 374 can be used by any host to perform data storage operations without the need to establish an authentication connection and the encryption method of an engine.

Methods executed by this engine

The above-mentioned ContentKey Digital Rights Management (CKDRM) function is used to provide an overview of the ContentKey Digital Rights Management (CKDRM) and functions. An engine cooperates with other parts of the secure electronic content (SEC) system (refer to Figure 2) to perform these functions. An engine, as described in the specification, is a component used to provide read and write access to digital media. This engine can exist in a host, or be coupled to a host, and can use commands to execute these functions. Among these commands, these commands may be easily understood by those skilled in the art, or may be based on system and design requirements definition. In addition, in a host application, components and other functions between applications should also fall within the scope of the present invention. The term "host application" can refer to the device to which the engine is directly connected, an application on a connected device (such as a personal computer (PC)), or to implement the ContentKey Digital Rights Management (CKDRM A server of the clearing house. Each method of an agreement includes one or two of ContentKey Digital Rights Management (CKDRM) and file system commands. These methods (which will be explained below) can be supplied to any credential entity and are defined by the credentials of this entity. In addition, the present invention also needs a device with an embedded engine, so as to expose the file system and ContentKey Digital Rights Management (CKDRM) application program interface (API) through the data I / O interface implemented by this device. In one embodiment of the present invention, these file systems and ContentKey Digital Rights Management (CKDRM) applications are disclosed. Interfaces (APIs) enable a device with an embedded engine to be used as a substitute for another entity. According to an embodiment of the present invention, communication using an engine requires a secure conversation. The authentication procedure described earlier can result in a new secure session and a secure session key. Figure 13 is an example of how to obtain a secure conversation through an authentication process. Block 1320 is used to enable this security key to be transferred in an asymmetric encryption process. In this embodiment, the dialog key is a symmetric key, which is used to obtain fast encryption and decryption of the data. Block 1340 is used to ask if a host change has occurred or if the media is ejected by a device. When block 1340 is true, the security conversation ends in block 1350. If not, the security conversation continues to block 1360. Therefore, a secure conversation is unique to a particular media, engine, and media combination. Whenever a secure conversation is established, the engine can execute various functions. This engine firmware is used to share the functions of these ContentKey digital rights management (CKDRM) and third-party digital rights management (TPDRM) methods, including: lock / unlock, ContentKey digital rights management (CKDRM) playback, ContentKey Digital Rights Management (CKDRM) Copy License, and Third Party Digital Rights Management (TPDRM) Copy License. For ContentKey Digital Rights Management (CKDRM) and Third Party Digital Rights Management (TPDRM) copy licenses, this engine can perform one of the following actions, including: free copy, first-generation copy of counting, and unrestricted first Generation copy. A secure conversation can enable an engine to enter the ContentKey Digital Rights Management (CKDRM) domain, which includes: performing functions of the ContentKey Digital Rights Management (CKDRM) and third party digital rights management (TPDRM). These ContentKey Digital Rights Management (CKDRM) functions executed by an engine are performed according to the agreement. With respect to the point of view of an engine, each agreement will be further explained as follows. ContentKey Digital Rights Management (CKDRM) Copy Figure 14 is used to introduce an engine to perform a ContentKey Digital Rights Management (CKDRM) copy method, which is used to copy content within the ContentKey Digital Rights Management (CKDRM) field . For example, please refer to FIG. 14, a source engine 1410 is used to hold management content located in the ContentKey Digital Rights Management (CKDRM) field. According to an embodiment of the present invention, a source file 1420 can be specified, so that the source file 1420 must perform an unlocking action and have a copy permission of retaining the ContentKey Digital Rights Management (CKDRM) before the method continues. According to another embodiment of the present invention, for example, the state of the source files 1420 of the hyper-dispersion model is not related to each other. In this example, the destination is the ContentKey Digital Rights Management (CKDRM) domain. In addition, the obtained copy 1430 is for managing content, and this file will also be unlocked. It has a ContentKey Digital Rights Management (CKDRM) playback license, but does not have a ContentKey Digital Rights Management (CKDRM) copy license. As part of this method and in order to play this content, a key box 1450 performs the transfer action. According to one embodiment of the invention, During the execution of the command to transfer the key box 1450, the source file 1420 will decrement the reserved ContentKey Digital Rights Management (CKDRM) copy permission. According to one embodiment of this replication agreement, for example, a secure conversation is established between two engines (a source engine 1410 and a destination engine 1440). In one embodiment of the present invention, the source engine 1410 is used to execute a secure application programming interface (API) and is only disclosed on a host having a ContentKey Digital Rights Management (CKDRM) replication license. The destination engine 1440 includes an open application programming interface (API). In this way, this method can be exposed to all hosts. Each engine has a host. A single device can serve as the host for these source and destination engines, or each engine can have a different host. In the latter example, the two hosts must be able to communicate according to a host agreement. This ContentKey Digital Rights Management (CKDRM) replication agreement uses commands known to those skilled in the art, and these commands are provided for illustrative purposes. This agreement is to use these ContentKey Digital Rights Management (CKDRM) commands, including: CKCMD_AUTHENTICATE and CKCMD_GET_CKCMD_COPY. The CKCMD_AUTHENTICATE command is used to enable the destination engine 1440 to authenticate the source engine 1410 to establish the trust of the source engine for the destination engine and to agree to the use of the ContentKey Digital Rights Management (CKDRM) method. The source host will send the destination engine's ContentKey Digital Rights Management (CKDRM) credentials. The source engine can then respond with the conversation key of this secure conversation. According to the CKCMD_GET_CKCMD_COPY command, a particular file or destination may require a key box. Subsequently, the source engine 1410 will return the file with the key box and a revocation list for the destination. ContentKey Digital Rights Management (CKDRM) records Another method performed by an engine is this ContentKey Digital Rights Management (CKDRM) record, which is used to provide a way to bring content into this ContentKey Digital Rights Management (CKDRM) field . This approach assumes that one source is managing content outside of the ContentKey Digital Rights Management (CKDRM) domain. The destination is the ContentKey Digital Rights Management (CKDRM) domain. And, the obtained copy is the management content. This ContentKey Digital Rights Management (CKDRM) recording method first establishes a secure conversation between an engine and a host. Therefore, this method is a secure application programming interface (API) that can only expose hosts with ContentKey Digital Rights Management (CKDRM) record permissions. The following commands are included in this record agreement: CKCMD_AUTHENTICATE, CKCMD_GET_CERTIFICATE, CKCMD_CREATE_FILE, CKCMD_RECORD_APPEND. In particular, the CKCMD_AUTHENTICATE command is used by the host that provides content to perform self-authentication on an engine, thereby establishing the engine for this Trust of each host to use the ContentKey Digital Rights Management (CKDRM) method. Therefore, the host will send its ContentKey Digital Rights Management (CKDRM) certificate in a command packet, and the engine will also use the session key of this secure session to respond. The CKCMD_GET_CERTIFICATE command is to enable the host that supplies the content to identify the engine, so as to establish the host's trust in the engine, so as to perform the content transfer action. The engine then sends its ContentKey Digital Rights Management (CKDRM) credentials during the data transfer process. The CKCMD_CREATE_FILE command is used to generate a new ContentKey Digital Rights Management (CKDRM) file. In particular, this host is used to specify the record dialogue key for transferring content, and this content can also be transferred from this host to this engine using the command CCKMD_RECORD_APPEND. The command packet sent by this host includes basic DataPlay file system (DFS) components (including: the location in the directory structure and the file name), which can be explicitly specified in this command packet. This command packet can clearly specify the ContentKey Digital Rights Management (CKDRM) rules and a revocation list. In an embodiment of the present invention, the rest of the command packet may include other objects of a file, which can be set to a preset value and can be adjusted by using DataPlay File System (DFS) commands. In one embodiment of the invention, the received content is appended to the end of the file. From the perspective of a host, the operation of this recording function is described with reference to FIG. 15. In block 1510, a host application is used to determine the file and its directory path to be imported into the ContentKey Digital Rights Management (CKDRM). In block 1520, the host is used to determine the attributes of the file to be generated, including: directory path, file name, attributes, multi-purpose Internet mail extension (MIME) type, ContentKey Digital Rights Management (CKDRM) License, revocation list, licensed ContentKey Digital Rights Management (CKDRM) copy, and licensed Digital Rights Management (DRM) copy. At block 1540, the host is the DataPlay File System (DFS) disposition used to determine the destination directory. In block 1560, the host is used to issue the CCKMD_AUTHENTICATE command to initiate a secure conversation between the host and the engine. Here, the certificate is a ContentKey Digital Rights Management (CKDRM) certificate set as this host. In block 1570, the engine is used to return the secure session key, which is the ESessionKey field. In block 1580, the host is used to issue the CCKMD_GET_CERTIFICATE command to authenticate the engine. Here, the certificate is a ContentKey Digital Rights Management (CKDRM) certificate set as this engine. In block 1590, the host is used to identify the engine and retrieve its public key. In block 1592, the host uses the CCKMD_CREATE_FILE command to generate the destination file. In one embodiment of the invention, this generated destination file includes Yes: Control the data used by this file. For example, this data optionally includes information such as: the disposition of the destination directory, the length of the revocation list, the encoded ContentKey Digital Rights Management (CKDRM) licenses and attributes, and the ContentKey digits of these licenses Rights Management (CKDRM) replication, these licensed digital rights management (DRM) replications, these encrypted secure session keys, and the ESessionKey value returned by the engine for the CKCMD_AUTHENTICATE command. Other data may include: the encryption record conversation key selected by the host, the message authentication code calculated by the host for the abolished list data, the message authentication code calculated by the host for the command packet, and the code as a The file name of the DFSNAME data type, and the obsolete data associated with this file. In block 1594, the host is used to issue a DFSCMD_GETHANDLE command to retrieve the disposal of the newly generated file. In block 1596, the host is used to set these attributes and the MIME type to the correct state. In block 1598, the host uses one or more CCKMD_RECORD_APPEND commands to write the content to the file. CKCMD_RECORD_APPEND This command is used to indicate the following fields, including: RecordOption field, which can be used to confirm the RECORD_FOREVER field, RecordFile field, which is the DataPlay File System (DFS) disposal and file to be written to the file. This engine is the disposal field and ByteCount field returned by the previous CKCMD_CREATE_FILE command, which is the number of bytes in this file (if confirmed in the Record option RECORD_FOREVER field, the ByteCount field can be any value), ESessionKey field, which is the encrypted secure session key, and has the same value as the ESessionKey value returned by the command CKCMD_AUTHENTICATE, and ErecordKey This field is the encrypted record session key selected by this host, and the ErecordKey field is transmitted by this host in the command CKCMD_CREATE_FILE. In block 1599, the host sends the entire file during the data transfer process. In one embodiment of the present invention, if more than one CKCMD_RECORD_APPEND command is used, the ErecordKey field must always be the same, and this data must also be encrypted using a single record dialog key (which is expressed as a single ERecordKey value). Content. In another embodiment of the present invention, the ErecordKey field can be changed with each CCKMD_RECORD_APPEND command. ContentKey Digital Rights Management (CKDRM) playback The ContentKey Digital Rights Management (CKDRM) playback function is a method of playing content, where this content is managed by ContentKey Digital Rights Management (CKDRM). As shown in Figure 16, one source is managing content within the ContentKey Digital Rights Management (CKDRM) field. According to the invention, this source file must be unlocked and have a ContentKey Digital Rights Management (CKDRM) playback license. This destination is a host that acts as a player. According to the agreement shown in Figure 16, the ContentKey Digital Rights Management (CKDRM) playback agreement must first be established between an engine and a host A secure conversation. According to an example of the present invention, the ContentKey Digital Rights Management (CKDRM) playback method is a secure application programming interface (API), and can only expose hosts with ContentKey Digital Rights Management (CKDRM) playback permissions. The ContentKey Digital Rights Management (CKDRM) playback protocol is completed using the following commands, which include: CKCMD_AUTHENTICATE, CKCMD_GET_CKDRM_PLAY_KEY, and CKCMD_PLAY. In block 1610, this method first starts with the CCKMD_AUTHENTICATE command, which is used to enable the host player to perform self-authentication procedures on the engine, thereby establishing the engine's trust in this destination, and performing ContentKey digital rights management (CKDRM) method. In block 1620, the host is used to transmit its ContentKey Digital Rights Management (CKDRM) credentials in the command packet. The engine can then use the conversation key of the secure conversation to respond. Next, in block 1640, the CKCMD_GET_CKDRM_PLAY_KEY command enables these ContentKey Digital Rights Management (CKDRM) playback licenses to be checked. In block 1650, the playback session is established and the playback session key for a particular file is returned. In block 1660, the CCKMD_PLAY command is used to enable the engine to return the contents of this particular file. Figure 17 is used to introduce a more detailed playback method, which uses the commands described previously. In block 1710, a player first decides The file to play. A user can insert source media into the engine, and the host will issue a CKCMD_AUTHENTICATE command in block 1720 to initiate a secure conversation between the engine and the host. In block 1720, the certificate is also set as the ContentKey Digital Rights Management (CKDRM) certificate of the host. In block 1740, the engine is used to return the secure session key, which is the ESessionKey field. In block 1750, the host is used to issue a CCMMD_GET_CKDRM_PLAY_KEY command to establish a playback session and obtain the playback session key for this file. The ESessionKey is the encrypted secure session key and will have the same value as the ESessionKey value returned by the engine for CCKMD_AUTHENTICATE. In this block 1760, the engine is used to return the playback session key, that is, the ESessionKey field. In block 1770, this host is used to issue one or more CCKMD_PLAY commands to retrieve the corresponding content. Corresponding to these commands, the engine can return these in block 1780. In one embodiment of the present invention, the CCKMD_PLAY command is used to explain that these contents are for retrieving actions and do not stop the retrieving actions due to unrecoverable errors. In particular, in one embodiment of the present invention, a PlayOptions field is set after confirming PLAY_STREAMING, which is used to perform serial playback and does not stop due to a certain playback error. In addition, after confirming the PLAY_TO_EOF command, this content will continue to play to the end of the file, completely ignored ByteCount. The ContentKey Digital Rights Management (CKDRM) of these playback commands is coordinated with the Application Programming Interface (API) of the DataPlay File System (DFS) to perform actions. For example, the PlayFile command is a DataPlay File System (DFS) command, which is set to specify the DataPlay File System (DFS) handling of the file to be played. Just like other methods implemented by the ContentKey Digital Rights Management (CKDRM), the playback function ESessionKey is an encrypted secure session key and has the same value as the ESessionKey value returned by the engine for CKCMD_AUTHENTICATE. Other useful data fields include the ByteOffset field, which is set to zero to start playback from the beginning of the file, and the ByteCount field, which can be set to the number of bytes this host desires to receive. ContentKey Digital Rights Management (CKDRM) unlocking Figure 18 is another way to introduce this ContentKey Digital Rights Management (CKDRM) implementation. ContentKey Digital Rights Management (CKDRM) unlocking is a method to change a ContentKey Digital Rights Management (CKDRM) file from a locked state to an unlocked state. After this method is successfully completed, the target file will be unlocked. Otherwise, these permissions and metadata will not be changed. Figure 18 is used to introduce the ContentKey Digital Rights Management (CKDRM) unlock agreement. The commands used in this agreement include: CKCMD_AUTHENTICATE, CKCMD_GET_CERTIFICATE, and CKCMD_UNLOCK_FILES. The data security required by this unlocking function requires a secure conversation between an engine and a host. In this way, this ContentKey Digital Rights Management (CKDRM) unlocking method can be a secure application programming interface (API), and can only expose hosts that have ContentKey Digital Rights Management (CKDRM) unlocking permissions. After the host decides to unlock the files in block 1860, the host can obtain the disposal of these locked files in a list manner in block 1862. In one embodiment of the present invention, the list is obtained by searching the directory structure and paying attention to all files with locked file attributes. In another embodiment of the present invention, this related format can also be used to specify locked content and some information related to the provisioning software package. In block 1864, the host application is used to issue the CCKMD_AUTHENTICATE command to perform a self-authentication process on the engine and start a secure conversation. Here, the certificate is a ContentKey Digital Rights Management (CKDRM) certificate set as a clearinghouse server. In block 1866, the engine is used to return the secure session key, which is the ESessionKey field. In block 1686, the host is used to issue the CCKMD_GET_CERTIFICATE command to authenticate the engine. Here, the certificate is a ContentKey Digital Rights Management (CKDRM) certificate set as this engine. In block 1870, the host is used to identify the engine and retrieve its public key. Then, in block 1872, CCKMD_ The UNLOCK_FILES command is used to allow this host to specify the files to be unlocked. The number of files to be unlocked is specified in a FileCount field during data transfer. The DataPlay File System (DFS) disposal of these files to be unlocked is specified in the Handle field of this FileSet array during data transfer. In block 1874, the engine is used to adjust the Lock attribute of these files, where these files are specified using the FileSet field. Other data useful in this unlocking method include the following fields: FileCount field, which is set to the number of files to be unlocked, and EunlockKey field, which is used to encrypt and decrypt the key complement. The required encryption and unlocking key and EmediaId field are the encrypted media identification code and public media identification code of the destination media, and the FileSet field is the identification code list of the file to be unlocked ( Including: DataPlay file system (DFS) disposal of files in each entity) and EkeyComplement field, which is an encrypted key complement (where this key complement is from an appropriate database). This unlocked key is used to encrypt the key's complement value. In addition, the DataMac field is a hash function set to the FileSet field in this data packet. Finally, in block 1876, the host application checks the success of the transaction by obtaining the status of the file to be unlocked.

Third Party Digital Rights Management (TPDRM) Copy

Third-party digital rights management (TPDRM) copying is one of the transfer of management content in the ContentKey digital rights management (CKDRM) field. Methods. This source is managing content within the ContentKey Digital Rights Management (CKDRM) field. This source file must be unlocked and must have a third party digital rights management (TPDRM) copy license. These third party digital rights management (TPDRM) copy licenses, according to an embodiment of the present invention, include: a non-zero third party digital rights management (TPDRM) copy count value, and a third party digital rights management (TPDRM) ) Free copy status, or an unlimited first-generation third-party digital rights management (TPDRM) copy status. This destination is an area of third party digital rights management (TPDRM). And, the obtained copy is the management content managed by the third party digital rights management (TPDRM) of this destination. In one example of the present invention, the reserved third party digital rights management (TPDRM) copy count of this source file will be decremented during the CKCMD_GET_DRM_COPY command, if necessary. Figure 19 is used to introduce this third party digital rights management (TPDRM) replication agreement. As with other methods described previously, this third-party digital rights management (TPDRM) replication requires a secure conversation between an engine and a host. In this way, this third-party digital rights management (TPDRM) replication method can become a secure application programming interface (API) and can only expose hosts with digital rights management (DRM) replication permissions. The digital rights management (DRM) copy license uses the following commands, including: CKCMD_AUTHENTICATE, CKCMD_GET_METADATA, CKCMD_GET_DRM_COPY, and CKCMD_PLAY. In block 1910, the CKCMD_AUTHENTICATE command is used to enable this third-party digital rights management (TPDRM) to perform self-authentication on the engine, thereby establishing the engine's trust in the third-party digital rights management (TPDRM) To use the ContentKey Digital Rights Management (CKDRM) method. In block 1920, the host transmits the content key digital rights management (CKDRM) certificate of the third party digital rights management (TPDRM) in the command packet. In block 1930, the engine responds with the conversation key of the secure conversation. In block 1940, the CKCMD_GET_METADATA command is used to enable the third party digital rights management (TPDRM) to retrieve the security metadata associated with the file to be played. In block 1950, the engine is used to return a key to decrypt the metadata. In addition, the engine will return the encrypted metadata in box 1950. In block 1960, the CCKMD_GET_DRM_COPY command is used to enable the engine to check the third party digital rights management (TPDRM) copy permission, establish the playback session, and return a special given this play session key and revocation list of files row . In block 1970, the TPDRM_COPY_Count command is used to decrement the value of this file, if needed. In block 1980, the CCKMD_PLAY command was used to enable the engine to return the contents of this particular file. Figure 20 is an example method used to introduce this third party digital rights management (TPDRM) copy. As shown in the figure, this third-party digital rights management (TPDRM) application is used to determine the set of files to be copied. In block 2010, a user first inserts the source media into the engine. In block 2020, this host is used to issue a CCKMD_AUTHENTICATE command to establish a secure conversation between this engine and this host. This certificate is a ContentKey Digital Rights Management (CKDRM) certificate set as this third party digital rights management (TPDRM). In block 2030, the engine is used to return the secure session key, which is the ESessionKey field. In one example of the present invention, the content key digital rights management (CKDRM) certificate of the host third party digital rights management (TPDRM) also includes a MetadataIdentifier field. In block 2040, the host is used to issue a CKCMD_GET_METADATA command to retrieve the security metadata of the third party digital rights management (TPDRM), which is related to this file. The AssociatedFile field is set by the DataPlay File System (DFS) of the related file (ie, the file to be copied). The ESessionKey field is the encrypted secure session key and has the same value as the ESessionKey field returned by the engine for CCKMD_AUTHENTICATE. In block 2050, the engine is used to return metadata, that is, related to the AssociatedFile field and related to the third-party digital rights management (TPDRM) specified by the certificate retrieved in the CCKMD_AUTHENTICATE command. Metadata. In an example of the present invention, the third-party digital rights management (TPDRM) is used to implement the management rules of the third-party digital rights management (TPDRM) (including the rules specified by the metadata) and determine this Whether the archive currently has a third party digital rights management (TPDRM) copy license. In one embodiment of the present invention, the third party digital rights management (TPDRM) must not perform the content copying action if the copying permission is not obtained. In block 2060, the host is used to issue a CKCMD_GET_DRM_COPY command to establish the playback session and obtain the playback session key for the file. The SourceFile field is the DataPlay File System (DFS) disposal of the file to be copied. In block 2070, the engine is used to return the playback session key (ie, the ESessionKey field) and the revocation list (ie, the RevocationList field). In block 2080, according to an embodiment of the present invention, the host is used to issue one or more CCKMD_PLAY commands to retrieve corresponding content. The fields of these play commands include: PlayOptions field, which is set after confirming the PLAY_STREAMING command (normal playback; stop when playback error) and confirming the PLAY_TO_EOF command (play to the end of the file; ignore the ByteCount field) The PlayFile field, which is set to specify the desired file, can be the DataPlay File System (DFS) disposal of the file to be copied, the ByteOffset field, which can be set to any value, and the ESessionKey field, which is encrypted And the same value as the ESessionKey field returned by this engine for CCKMD_AUTHENTICATE. In block 2090, the engine is used to return the corresponding content.

Read secure metadata

Reading secure metadata is a method of accessing content, which is located within the ContentKey Digital Rights Management (CKDRM) domain and is owned by a third party. In one embodiment of the present invention, the related file must be unlocked. This metadata is associated with this file and with the host specified by this secure conversation. As with other methods, this protocol must first establish a secure conversation between an engine and a host. In this way, this method for reading secure metadata may become a secure application programming interface (API) and only expose hosts that have permission to read secure metadata. Figure 21 is used to introduce this read security metadata protocol. This protocol for reading secure metadata is implemented using the following commands, including: CKCMD_AUTHENTICATE, and CKCMD_GET_METADATA. As mentioned earlier, the CKCMD_AUTHENTICATE command is used to enable the host to perform a self-authentication procedure on the engine, thereby establishing the engine's trust in this destination, and thus using the ContentKey Digital Rights Management (CKDRM) method. According to the CKCMD_AUTHENTICATE command, the host will send its ContentKey Digital Rights Management (CKDRM) credentials in this command packet. The engine can then use the conversation key of the secure conversation to respond. The CKCMD_GET_METADATA command is used to enable the host to read the security metadata associated with this file. According to the CKCMD_GET_METADATA command, the engine can return a key to decrypt the metadata, and also return the encrypted metadata. Referring to Figure 21, in block 2110, the host first determines the file associated with the metadata to be read. Therefore, the transaction, in block 2120, includes: A user inserts the source media into the engine. In block 2130, the host is used to issue a CCKMD_AUTHENTICATE command to establish a secure conversation between the engine and the host. This certificate is set as the ContentKey Digital Rights Management (CKDRM) certificate of this host. In block 2140, the engine is used to return the secure session key, which is the ESessionKey field. In block 2150, the host is used to issue a CKCMD_GET_METADATA command to retrieve the security metadata in the host that is associated with the file. The AssociatedFile field is the DataPlay File System (DFS) disposition of this file set to correlate these metadata. The ESessionKey field is the encrypted secure session key and will have the same value as the ESessionkey value returned by the engine for CCKMD_AUTHENTICATE. In block 2160, the engine is used to return the Metadata field, which is the file specified in the AssociatedFile field and the metadata associated with the host specified by the certificate in the command CKCMD_AUTHENTICATE.

Write secure metadata

The write security metadata function is used to provide a method for confirming the content. The content is included in the ContentKey Digital Rights Management (CKDRM) field and is owned by a third party. In one embodiment of the invention, this related source file must be unlocked However, the status of this related file may also change according to design requirements. This metadata is associated with this file and with the host specified by this secure conversation. This protocol first establishes a secure conversation between an engine and a host. In this way, this method of writing secure metadata can become a secure application programming interface (API) and can only expose hosts that have permission to write secure metadata. This protocol for writing secure metadata is implemented using the following commands, including: CKCMD_AUTHENTICATE, CKCMD_GET_CERTIFICATE, and CKCMD_SET_METADATA. As mentioned previously, the CKCMD_AUTHENTICATE command is used to enable a host to perform self-authentication on an engine, thereby establishing the engine's trust in this destination, and thereby using the ContentKey Digital Rights Management (CKDRM) method. According to the CKCMD_AUTHENTICATE command, the host will send its ContentKey Digital Rights Management (CKDRM) credentials in this command packet. The engine then uses the conversation key of the secure conversation in response. The CKCMD_AUTHENTICATE command is used to enable the host to provision and identify the content of the engine, so as to establish the host's trust in the engine, so as to carry out the content transfer action. The engine then sends its ContentKey Digital Rights Management (CKDRM) credentials during the data transfer process. The CKCMD_SET_METADATA command is used to enable this host to Write security metadata related to this file. According to the CKCMD_SET_METADATA command, the host will send a key to decrypt the metadata and the encrypted metadata. Figure 22A is a protocol used to introduce this method of writing secure metadata. In block 2210, the host first determines the files related to the metadata to be written. At block 2220, a user inserts the destination media into the engine. In block 2230, the host is used to issue a CCKMD_AUTHENTICATE command to initiate a secure conversation between the engine and the host. Here, this certificate is set as the ContentKey Digital Rights Management (CKDRM) certificate of this host. In block 2240, the engine is used to return the secure session key, which is the ESessionKey field. In block 2250, the host is used to issue a CCKMD_GET_CERTIFICATE command to authenticate the engine. Here, this certificate is set as the ContentKey Digital Rights Management (CKDRM) certificate of this engine. In block 2260, the host is used to identify the engine and retrieve its public key. In block 2270, the host is used to issue a CKCMD_SET_METADATA command to transmit the security metadata associated with the file in the host. The AssociatedFile field is handled by the DataPlay File System (DFS) of the file associated with this metadata. The ESessionKey field is an encrypted secure session key and has the same value as the ESessionKey field returned by the engine for CCKMD_AUTHENTICATE. Metadata field is It is about the file specified by the AssociatedFile field, and the host specified by the receiving certificate in the CCKMD_AUTHENTICATE command. Please refer to Table 4 below for permission to the above order.

Form 4A

Order the current secure session to lock the object host permission object permission annotation CKCMD_AUTHENTICATE to interrupt the current conversation, start a new conversation Cannot apply a valid CKDRM certificate Cannot apply a CKDRM certificate Signing must use a public key (including: the CA listed in the valid signature key list Public key) Confirmation CKCMD_CREATE_FILE needs to be unable to apply CKDRM record parent directory: DFS writes the directory to generate new files must have DEFENDANTS write permission CKCMD_GET_CERTIFICATE does not need to be unable to apply non-secure commands that cannot apply CKDRM application program interface. CKCMD_GET_CONTENT_KEY_COPY needs to not allow CKDRM to copy non-zero CK copy, CK free copy, or unlimited first generation CK copy. CKCMD_GET_CKDRM_ID does not need to be able to apply non-secure commands that cannot apply the CKDRM application program interface. CKCMD_GET_CKDRM_PLAY_KEY needs to disallow CKDRM to play CKDRM playback, DFS reads CKCMD_GET_TPDRM_COPY needs to disallow TPDRM to copy non-zero TPDRM copy, TPDRM free copy, or unlimited first-generation TPDRM copy CKCMD_GET_METADATA requires permission to read the secure metadata file must have the host's meta data. CKCMD_PLAY needs to not allow CKDRM to play CKDRM playback or TPDRM replay System, DFS reads CKCMD_RECORD_APPEND needs permission to CKDRM record CKDRM record, DFS write close DFS write and DFS write adjustment to reject further records. CKCMD_SET_KEYBOX does not require disallowed files. It does not need to have CKDRM metadata. Non-secure commands for the CKDRM application program interface. CKCMD_SET_METADATA requires permission to write secure metadata CKCMD_UNLOCK_FILES requires permission to unlock CKDRM files must have CKDRM metadata

Please refer to Table 4A. The following commands (including: RECORD_APPEND, PLAY, GET_DRM_PLAY_KEY, GET_DRM_COPY, GET_CKDRM_PLAY_KEY, GET_CKDRM_COPY, and CREATE_FILE) are included as part of their agreement, each of which includes a consideration of a media identification code. A media identification code is a unique identification code, which is generated during the production and pre-recording of the original film of a media. According to different design requirements, this unique media identification code may correspond to an original film or each media. The other media identification code is a unique identification code generated in the media field application. This unique media identification code corresponds to each media, such as media discs. In each example, however, this media identification code can be pre-recorded on a disc to correspond to the content produced by the original film production, pre-recording, or the like. Furthermore, in each example, this media identifier can also be written into the media (various (Eg: a disc) to correspond to what has been written. This pre-recorded media identification code, therefore, will only exist in the media portion to which the original film production / pre-recorded content belongs, and this written media identification code will only exist in the media portion to which the written material belongs. Please refer to Table 4B below, which is used to provide the type of identification code that may appear in this secure electronic content (SEC) system. As shown in Table 4B, this secure electronic content (SEC) system has a total of four types of identification codes, including: pre-recorded identification codes for pre-recorded content, pre-recorded identification codes for written content, and pre-recorded content. The write identification code and the write identification code of the content to be written. The pre-recorded locked content and the pre-recorded locked content that will be unlocked later will only use the pre-recorded media identification code. In one embodiment of the present invention, the secure electronic content (SEC) system uses two types of the four identification codes, so the existence of the other two types can be used to represent a forged disc.

Form 4B

Pre-recorded content written content Pre-recorded media identification code is forged by Secure Electronic Content (SEC) system Forged media ID is used by Secure Electronic Content (SEC) system

Please refer to Table 4A. The following commands (including: RECORD_APPEND, PLAY, GET_DRM_PLAY_KEY, GET_DRM_COPY, GET_CKDRM_PLAY_KEY, GET_CONTENT_KEY_COPY, and CREATE_FILE) are included as part of their agreement. There is a consideration of a media identification code. A media identification code is a unique identification code, which is generated during the production and pre-recording of the original film of a media. According to different design requirements, this unique media identification code may correspond to an original film or each media. In each example, however, the media identification code can be pre-recorded on a disc, provided that the content is obtained using original film production, pre-recording, or the like. This media identifier, therefore, will only exist for the portion of the media to which the original film production / pre-recorded content belongs. Please refer to Table 4C below, which is used to indicate the type of identification code that this secure electronic content (SEC) system may provide. As shown in Table 4C, this secure electronic content (SEC) system has a total of four types of identification codes, including: pre-recorded, pre-recorded mixed identification codes with both these pre-recorded and written components, and write-only Identification code, and forged identification code. These four types of identification code types include: media that holds pre-recorded locked content that is subsequently unlocked, media that only holds unlocked content, and media that holds both types of mixed content . According to an unlocking agreement, when the content is unlocked, a part of the identification code of the content is pre-recorded and written into another part of the identification code. In this way, for those media that holds the pre-recorded locked content that is subsequently unlocked, this identification code can always have a pre-recorded identification code associated with it.

Form 4C

Pre-recorded mixed write forgery Whether the media holding the pre-recorded unlocked content that will be unlocked later is not known at the time of purchase

Please refer to Table 4B and Figure 22B, which are used to provide a method to determine whether the content is fake. This method can be executed during the following commands according to design requirements, including: RECORD_APPEND, PLAY, GET_DRM_PLAY_KEY, GET_DRM_COPY, GET_CKDRM_PLAY_KEY, GET_CONTENT_KEY_COPY, CREATE_FILE, or any other command. Block 2202 is used to perform a table lookup of a key box. Box 2204 retrieves this key box through a file. In one embodiment of the invention, the key box must be encrypted and connected to a location. In block 2206, an engine is used to determine whether the media identification code should be written or pre-recorded based on the desired action of the command. In block 2208, the key box link identifier flag is compared to a key box reading method, however, this implementation will also depend on the selected command. Furthermore, in block 2208, this method based on the selected command is also compared with the media identifier associated with the command and / or with the identifier flag associated with the media identifier. If the identification code or identification flag is not pre-recorded for those identification codes that require a pre-recorded identification code or flag, block 2212 can provide an abolition action for some or all of the functions of this command. In the present invention In one embodiment, when the identification code is actually located in a part of a disc on which the content is written, a fake identification code will identify itself as a pre-recorded identification code in front of an engine. The decision made by the engine as to whether these IDs are pre-recorded or written depends on how the ID identifies itself and its location on the media. Therefore, the present invention can prevent the forged media disc from performing all functions. The following Table 5 is used to provide the DataPlay File System (DFS) command permission, which includes: the pre-recorded and recommended status of ContentKey Digital Rights Management (CKDRM) files.

Table 5

File Type Read / Adjust Write / Adjust Move / Adjust Rename / Adjust Delete / Adjust Comment On / Off On / Off / Switch / Switch / On / After Record Creation, Keep Record Permission During Record Completion Rear on / off off / off off / switch / switch / off turn off DFS write and DFS write adjustment. Denies move, reorder, and delete functions, but allows these permissions to be adjusted.

The first part of each item is the status of the DataPlay file system (DFS) permission attributes, and the second part is the status of the field of the property adjustment mask in the DataPlay file system (DFS). When the attribute adjustment mask is closed, the permission attributes cannot be changed further. The ContentKey Digital Rights Management (CKDRM) command described earlier is This ContentKey Digital Rights Management (CKDRM) part, and will act according to the following table: CKDRM_AUTHENTICATE: confirm and authenticate the authenticity of the host, and establish a secure dialog.

Table 6: Command start

Register Name Value Description Control Register FUNCTION CODE = 011 Reset the Byte Count Index to Low Byte Byte Count Register CKCMD_AUTHENTICATE_SIZE Command Packet Size Control Register FUNCTION_CODE = 001 Start Command

Table 7: Command packets

Byte shift field name type description 0 HostCmdU8 command code 1CkSubCmdU8 secondary command code 2: 241CertificateCKDRM_CERTIFICATE CKDRM certificate of host

Table 8: Data transfer (from engine to host)

Byte shift field name type description 0: 37ESessionKeyWRAPPED_KEY Session key for new secure session

According to an embodiment of the present invention, any host can access the command CKCMD_AUTHENTICATE. This host must be able to transmit a valid ContentKey Digital Rights Management (CKDRM) credentials to ensure the success of this command. Any current security dialogue will be interrupted. A successful execution will result in a new current security conversation. The parameters and settings of this command include: HostCmd is set to DPICMD_CK_COMMAND, CkSubCmd is set to CKCMD_AUTHENTICATE, the certificate is set to the ContentKey Digital Rights Management (CKDRM) certificate of this host, and ESessionKey is to use the ContentKey Digital Rights Management (CKDRM) of this host ) The protocol's agreement public key for secure session keys for cryptographic actions. If the host can decrypt the ESessionKey field correctly, it will perform an inherent authentication action. As mentioned in the method performed with reference to this engine, this authentication command enables a host to transmit its ContentKey Digital Rights Management (CKDRM) credentials to this engine. This engine is used to confirm and authenticate this certificate. In addition, this engine can be used to retrieve these method permissions. The engine then generates a secure session key and stores the key and the host certificate. At this point, the host can become the current host for this secure conversation and subsequent ContentKey Digital Rights Management (CKDRM) commands. In one example of the present invention, initiating this authentication command will interrupt all existing security conversations. Therefore, a successful order will only start a new secure conversation. In addition, the value of the ESessionKey field can also be used as the secure session identifier. CKCMD_GET_CERTIFICATE: Transfer the ContentKey Digital Rights Management (CKDRM) credentials of this engine to this host.

Table 9: Command start

Register Name Value Description Control Register FUNCTION_CODE = 011 Reset Byte Count Index to Low Byte Byte Count Register CkCMD_GET_CERTIFICATE_SIZE Command Packet Size Control Register FUNCTION_CODE = 001 Start Command

Table 10: Command packets

Byte shift field name type description 0 HostCmdU8 command code 1DfsSubCmdU8 command code

Table 11: Command transfer (from engine to host)

Byte shift field name type description 0: 239CertificateCKDRM_CERTIFICATE CKDRM certificate for this engine

Any host can access the CKCMD_AUTHENTICATE command. The parameters used by this command include: HostCmd, which is set to the DPICMD_CK_COMMAND command, CkSubCmd, which is set to CKCMD_GET_CERTIFICATE, Certificate, which is also the ContentKey Digital Rights Management (CKDRM) certificate for this engine. CKCMD_GET_ The CERTIFICATE command is used to transfer the ContentKey Digital Rights Management (CKDRM) credentials of this engine to this host, so that the credentials of this host can be transmitted (via CKCMD_AUTHENTICATE) to another engine, so as to use these ContentKey digits when necessary Part of rights management (CKDRM) copying method, recording method, writing metadata method, and unlocking method. CKCMD_CREATE_FILE: Checks ContentKey Digital Rights Management (CKDRM) record permissions, generates a new ContentKey Digital Rights Management (CKDRM) file object in a given directory, and establishes a write / record dialog.

Table 12: Command start

Register Name Value Description Control Register FUNCTION_CODE = 011 Reset Byte Count Index to Low Byte Byte Count Register CKCMD_CREATE_FILE_SIZE_NO_NAME + n Command Packet Size Control Register FUNCTION_CODE = 001 Start Command

Table 13: Command packets

Byte shift field name type description 0 HostCmdU8 command code 1DfsSubCmdU8 secondary command code 2: 3 RevocationByteCountU16 Expected number of bytes in the revocation list 4: 7ParentDFSHANDLE Directory of the file to be generated 8: 9CKDRMStateCKCMD_STA_TE Encoded CKDRM attribute and file permission. Please refer to the encoding method. 10CKDRMCopiesU8 agrees the number of CKDRM copies 11DrmCopiesU8 agrees the number of DRM copies 12: 15ReservedU16 [2] Reserves the secure conversation key of 16: 31ESessionKeyWRAPPED_KEY 32: 47ERecordKeyWRAPPED_KEY records the conversation key 48: 67RevocationMacMAC adds the MAC68: 87CommandMacMAC revocation list 88: n + 87NameDFSNAMEn byte file name

Table 14: CKDRMState field (CKCMD_STATE type)

Bit name description FILE_CKDRM_COPY_FREELY indicates whether these CKDRM copies can be performed unlimitedly FILE_CKDRM_LOCKEDO = Generate an unlocked file 1 = Generate a locked file FILE_CKDRM_PLAY indicates whether to agree with this CKDRM playback method FILE_DRM_COPY_FREELY indicates whether these DRM copies can be performed without restriction FILE_UNLIMITED_FIRST_GENERATION_CK_COPIES indicates whether the first generation of CKDRM replication can be performed without limit FILE_UNLIMITED_FIRST_GENERATION_DRM_COPIES table Shows whether the first-generation DRM replication can be performed without limit

Table 15: Data transfer (from host to engine)

Byte displacement field name type description 0: RevocationByteCount-1

The CKCMD_CREATE_FILE command may require a current secure conversation. Therefore, only the host with the permission of the ContentKey Digital Rights Management (CKDRM) recording method can access the CKCMD_CREATE_FILE command. Parent must specify a directory with write permission. The command parameters of the device include: HostCmd, which is set to DPICMD_CK_COMMAND, CkSubCmd, which is set to CKCMD_CREATE_FILE, RevocationByteCount, which is the number of bytes expected in the data phase of this command, Parent, which is written Directory disposal of archives. CKDRMState is the ContentKey Digital Rights Management (CKDRM) attribute and permission for this file. The member fields of the CKDRMState field are specified using the CKDRMState field table. CKDRMCopies is used to specify the number of ContentKey Digital Rights Management (CKDRM) copies that this file can perform. This number is the starting value of the ContentKey Digital Rights Management (CKDRM) copy count value. This ContentKey Digital Rights Management (CKDRM) replication method must be able to use a non-zero value. DrmCopies is used to specify the number of digital rights management (DRM) copies that this file can perform. This value is the copy count value of this digital rights management (DRM). This digital rights management (DRM) replication method must be able to use a non-zero value. ESessionKey is the current secure session key and is the CKDRM_AUTHENTICATE command related to this ContentKey Digital Rights Management (CKDRM) method. ERecordKey is the record conversation key of this file, and it uses the engine's public key to perform encryption operations. This ERecordKey value is the value that all CKDRM_RECORD_APPEND commands of this file must use. This value is used to imply that the CCKMD_RECORD_APPEND command data of this file is encrypted by using this record conversation key. RevocationMac is the message authentication code for this data phase. CommandMac is the message authentication code for this command packet. The message authentication code is calculated using the previous field of the command packet, and includes: Byte 0 to Byte 67. Name is the DataPlay File System (DFS) name of the file. RevocationList is the revocation list of this file. The CKDRM_CREATE_FILE command is used to generate a ContentKey Digital Rights Management (CKDRM) file object in this specified directory. This file has zero file length at the beginning. The disposal of the generated file can be obtained using the command DFSCMD_GETHANDLE. This treatment is then applied in the following CCKMD_RECORD_APPEND command. These file attributes and multiple Internet mail extensions (MIME) type is set to the default value. In addition, the ContentKey Digital Rights Management (CKDRM) metadata is set to the values specified in the fields CKDRMState, CKDRMCopies, DrmCopies, and RevocationList. CKDRM_GET_CKDRM_COPY: Check the ContentKey Digital Rights Management (CKDRM) copy permission, and transfer out the key box and destination ID of a specific file. In addition, the ContentKey Digital Rights Management (CKDRM) copy count of this file will be decremented as needed. This transfer action is transferred from this engine to this host.

Table 16: Command start

Register Name Value Description Control Register FUNCTION_CODE = 011 Reset Byte Count Index to Low Byte Byte Count Register CKCMD_GET_CKDRM_COPY_SIZE Command Packet Size Control Register FUNCTION_CODE = 001 Start Command

Table 17: Command packets

Byte displacement field name type description 0 HostCmdU8 command code 1DfsSubCmdU8 secondary command code 2: 3ReservedU16 Reserved 4: 7 SourceFileDFSHANDLE Get key box file 8: 39CKDRMIdU256 Copy destination identifier 40: 55ESessionKeyWRAPPED_KEY The current secure session key

Table 18: Data transfer (from engine to host)

Byte shift field name type description 0: nKeyBoxSorcefile and destination key box

In one embodiment of the present invention, the CCKMD_GET_CKDRM_COPY command can only perform actions in a current security session. In addition, only hosts that have permission for the ContentKey Digital Rights Management (CKDRM) replication method can access the CKCMD_GET_CKDRM_COPY command. The Sourcefile must have one of the following three states, including: non-zero ContentKey digital rights management (CKDRM) copy count value, a ContentKey digital rights management (CKDRM) free copy status, or a first-generation ContentKey digital right Unlimited replication status of management (CKDRM). In one embodiment of the present invention, CCKMD_GET_CKDRM_COPY is a file for locking or a file with a copy count of zero, provided that the destination file therein is marked as locked. The field parameters provided in these tables include: HostCmd, which is set to DPICMD_CK_COMMAND, CkSubCmd, which is set to CKCMD_GET_CKDRM_COPY, SourceFile, which is the DataPlay File System (DFS) processing to obtain the file of this key box, and CKDRMId, It is the identification code of the destination to which this transport key box belongs. The identification code must be a CCMMD_GET_CKDRM_ID command Transmission results to this destination engine. In addition, ESessionKey is the current secure session key. KeyBox is generated using this engine. In addition, KeyBox is the key and revocation list of the file specified by SourceFile and the destination specified by CKDRMId. The engine will then return the KeyBox to the host. The CKCMD_GET_CKDRM_COPY command is used in the ContentKey Digital Rights Management (CKDRM) replication method to obtain a key box that can be transmitted to a destination. This key box is related to SourceFile. In addition, this key box is used to provide the information needed to access (play) this content, which is kept in the copied file at this destination. If the SourceFile has a ContentKey Digital Rights Management (CKDRM) free copy status, the resulting copy will also have a ContentKey Digital Rights Management (CKDRM) free copy status. Otherwise, the resulting copy will not have any ContentKey Digital Rights Management (CKDRM) copy license. If SourceFile has an unlimited first-generation ContentKey Digital Rights Management (CKDRM) copy status, then this ContentKey Digital Rights Management (CKDRM) copy count can be maintained. Otherwise, if the ContentKey Digital Rights Management (CKDRM) copy count is not zero, the ContentKey Digital Rights Management (CKDRM) copy count will be decremented by this engine and saved back to the media before the command is completed. Therefore, the transmission of the KeyBox will be related to the decrementing action of this copy count. If the SourceFile has a ContentKey Digital Rights Management (CKDRM) free copy status, the resulting copy will also have a ContentKey Digital Rights Management (CKDRM) free copy status. Otherwise, the resulting copy will not have any digital rights management (DRM) copy permissions. In addition, the KeyBox field must then be transmitted to the destination engine to complete the ContentKey Digital Rights Management (CKDRM) copy transaction, as described previously for the ContentKey Digital Rights Management (CKDRM) copy method. CKCMD_GET_CKCRM_ID: Returns information about the currently inserted media.

Table 19: Commands Begin

Register Name Value Description Control Register FUNCTION_CODE = 011 Reset Byte Count Index to Low Byte Byte Count Register CKCMD_GET_CKDRM_ID_SIZE Command Packet Size Control Register FUNCTION_CODE = 001 Start Command

Table 20: Command packets

Byte shift field name type description 0 HostCmdU8 (unsigned octet value) command code 1DfsSubCmdU8 times command code 2: 3ReservedU16 Reserved 4:19 SourceFileWRAPPED_KEY Current secure session key

Table 21: Data transfer (from engine to host)

Byte displacement field name type description 0: 31CKDRM_IdU256 CKDRM identification code currently inserted into the media

According to an embodiment of the present invention, the command CKCMD_GET_CKDRM_ID allows any host to access the command CKCMD_GET_CKDRM_ID. However, this engine does not need to be inserted into the media in advance. The parameters indicated in the above tables include: HostCmd, which can be set to DPICMD_CK_COMMAND. CkSubCmd, which can be set to CKCMD_GET_CKDRM_ID. In addition, Esession is the current secure conversation key. In addition, CKDRMId is an identification code used to indicate the currently inserted media and the current secure conversation. CKCMD_GET_CKDRM_ID is used to return the media-specific information and can be used by various ContentKey digital rights management (CKDRM) methods to provide media-specific information. In addition, other identification codes (such as a public media identification code) can also be provided through the Application Programming Interface (API) of the DataPlay File System (DFS). CKCMD_GET_CKDRM_PLAY_KEY: Check the ContentKey Digital Rights Management (CKDRM) playback permission and establish a playback session.

Table 22: Command Begins

Register name value description Control register FUNCTION_CODE = 011 Reset the byte count index to the low byte Byte Count Register CKCMD_GET_CKDRM_PLAY_KEY_SIZE Command Packet Size Control Register FUNCTION_CODE = 001 Start Command

Table 23: Command packets

Byte shift field name type description 0HostCmdU8 command code 1DfsSubCmdU8 secondary command code 2: 3ReservedU16 reserved 4: 7PlayFileDFSHANDLE file processing required for this key 8: 23EssesionKeyWRAPPED_KEY current security dialog key

Table 24: Data transfer (from engine to host)

Byte shift field name type description 0: 15EPlayKeyAES_KEY Play dialog key for a specific file

According to one embodiment of the invention, this command will require the establishment of a current secure conversation. In addition, only the host with the permission of the ContentKey Digital Rights Management (CKDRM) playback method can access the CKCMD_GET_CKDRM_PLAY_KEY command. In addition, PlayFile must specify an unlocked file or have permission to play with ContentKey Digital Rights Management (CKDRM) playback and DataPlay file system (DFS) reading. The parameters used by this command include: HostCmd, which is set to DPICMD_CK_COMMAND, CkSubCmd, which are set to CKCMD_GET_CKDRM_PLAY_KEY, PlayFile, which is the DataPlay File System (DFS) processing, Esession, which is to return the file playing the session key, which is the current secure session key. In addition, EPlayKey is a play session key that uses this secure session key to perform encryption operations. This play session key is exclusive to this file specified by PlayFile. In particular, this playback session key is the key used by PlayFile in subsequent (KCMD_Play command to encrypt the file. In addition, the CKCMD_GET_CKDRM_PLAY_KEY command is used to decrypt a specific file. The engine is transferred to this host. Furthermore, this command must be issued before each ContentKey Digital Rights Management (CKDRM) playback dialog. This host cannot make the assumption that the file on this media will have the same each time it is played Then, the content of this file (which is stored in a form that can be decrypted using this playback session key) can be obtained using the command CKCMD_PLAY. CKCMD_GET_DRM_COPY: Check third party digital rights management (TPDRM) And a playback dialogue is established. In addition, the third party digital rights management (TPDRM) copy count value will be decremented as needed.

Table 25: Orders Begin

Register name value description Control register FUNCTION_CODE = 011 Reset the byte count index to Low byte byte count register CKCMD_GET_DRM_COPY_SIZE command packet size control register FUNCTION_CODE = 001 start command

Table 26: Command packets

Byte shift field name type description 0 HostCmdU8 command code 1DfsSubCmdU8 secondary command code 2: 3ReservedU16 reserved 4: 7 SourceFileDFSHANDLE file to obtain this key 8:23

Table 27: Data transfer (from engine to host)

Byte shift field name type description 0: 15EPlayKeyAES_KEY Play dialog key for a specific file 16: nRevocationList Related to this file's CKDRM revocation list

CKCMD_GET_DRM_COPY This command will request a current secure conversation. In addition, only the host that has the third-party digital rights management (TPDRM) copy command method permission can access the CCKMD_GET_DRM_COPY command. SourceFile must then specify an unlocked file. The source file must have one of the following statuses, including: _ non-zero third party digital rights management (TPDRM) A count value, a third party digital rights management (TPDRM) free copy status, and an unlimited first generation third party digital rights management (TPDRM) copy status. The parameters and settings required by this command of CKCMD_GET_DRM_COPY include: HostCmd, which is set to DPICMD_CK_COMMAND, CkSubCmd, which is set to CKCMD_GET_DRM_COPY, SourceFile, which is the DataPlay File System (DFS) disposal of the file to obtain the key, EsessionKey, which It is the current security dialogue. The EplayaKey field is the playback session key that uses this secure session key for encryption. This playback session key is proprietary to the file specified by SourceFile. That is, this playback session key is the key used to encrypt the content in the subsequent CCKMD_PLAY command of SourceFile. In addition, RevocationList is the revocation list of this file. CKCMD_GET_DRM_COPY This command is used to get the key of a file. CKCMD_GET_DRM_COPY This command is used in the digital rights management (DRM) copy method. If the digital rights management (DRM) copy count value associated with this file is not zero, the digital rights management (DRM) copy count is decremented and rewritten to the media before the command is completed. The CKCMD_GET_DRM_COPY command is applied during the digital rights management (DRM) copy method to obtain a playback session key, which can be stored with the content via CKCMD_PLAY command. In addition, the revocation list of this file can also be obtained through this and must be transmitted when the content is imported into ContentKey Digital Rights Management (CKDRM). if SourceFile has a ContentKey Digital Rights Management (CKDRM) free copy status, and the resulting copy will also have a ContentKey Digital Rights Management (CKDRM) free copy status. Otherwise, the obtained copy will not have the ContentKey Digital Rights Management (CKDRM) copy license. If SourceFile has a third-party digital rights management (TPDRM) free copy status or an unlimited first-generation ContentKey digital rights management (CKDRM) copy status, the third-party digital rights management (TPDRM) copy count will be maintained constant. Otherwise, if the third-party digital rights management (TPDRM) copy count is not zero, the engine will decrement the third-party digital rights management (TPDRM) copy count and decrement the third-party number before the command completes Rights Management (TPDRM) copy counts are stored back on the media. Therefore, the transmission of EplayKey will be accompanied by the decrement of the third party digital rights management (TPDRM) copy count. CKCMD_GET_METADATA: Check permission to read secure metadata, and transfer third party and host-specific security metadata from this medium to this host.

Table 28: Command start

Register Name Value Description Control Register FUNCTION_CODE = 011 Reset Byte Count Indicator to Low Byte Byte Count Register CKCMD_GET_METADATA_SIZE Command Packet Size Control Register FUNCTION_CODE = 001 Start Command

Table 29: Command packets

Byte displacement field name type description 0 HostCmdU8 command code 1DfsSubCmdU8 secondary command code 2: 3ReservedU16 reserved 4: 7AssociatedFileDFSHANDLE File processing related to this metadata 8: 23EssesionKeyWRAPPED_KEY

Table 30: Data transfer (from engine to host)

Byte displacement field name type description 0: n_1Metadata relates to metadata of a specific file and host; n bytes

The CKCMD_GET_METADATA command operates during a current security session. In addition, only hosts that have permission to read the secure metadata method can access the CKCMD_GET_METADATA command. SourceFile must specify an unlocked file. SourceFile must specify a file with metadata specific to the value of this host's MetadataIdentifier field. The parameters and settings required for this command include: HostCmd, which is set to DPICMD_CK_COMMAND, CkSubCmd, which is set to CKCMD_GET_METADATA, ESessionKey, which is the current secure dialog key. See CKCMD_AUTHENTICATE for more information. Metadata is the metadata for this secure storage file. In addition, this metadata can be limited to 1024 bytes per host and each file. In addition, the CKCMD_GET_METADATA command can also return third-party, host-specific security metadata associated with a file. This returned metadata can be written by the last CKCMD_SET_METADATA command for this host and file. If no such order has been issued, this file and the metadata pre-recorded by the host will be returned. In one example of the invention, the engine does not interpret this metadata in any way. In addition, this metadata can only be accessed by the host of the current secure conversation, and only the metadata of a specific host can be accessed. CKCMD_PLAY: In an established playback session, secure content is transferred from this engine to this host.

Table 31: Command Begins

Register Name Value Description Control Register FUNCTION_CODE = 011 Reset Byte Count Index to Low Byte Byte Count Register CKCMD_PLAY_SIZE Command Packet Size Control Register FUNCTION_CODE = 001 Start Command

Table 32: Command packets

Byte shift field name type description 0 HostCmdU8 command code 1DfsSubCmdU8 command code 2: 3PlayOptionsU16 playback options. Please refer to the encoding procedure. 4: 7PlayFileDFSHANDLE File to be played 8:15 ByteOffset U64 Bit shift to be played inside the file 16:23 Byte Count U64 Number of bytes to be transferred 24:39 ESessionKeyWRAPPED_KEY Current secure session key 40:55 EPlayKeyAES_KEY Current playback session key

Table 33: Play option encoding

Byte shift field name description 0PLAY_STREAMING0 = normal playback; interruption during playback error 1 = sequence playback; non-interruption when playback error occurs 1PLAY_TO_EOF0 = normal playback; interruption when reaching the positioning byte count 1 = playback to end of file ; Ignore the ByteCount field in the command packet 2:15 reserved

According to an embodiment of the invention, the command is to be acted upon during a current secure conversation. In addition, only hosts with ContentKey Digital Rights Management (CKDRM) playback or Digital Rights Management (DRM) copy method permission can access the CKCMD_PLAY command. PlayFile must specify an unlocked file. In addition, PlayFile must also specify a file with a DataPlay File System (DFS) read permission. Furthermore, PlayFile must also specify a ContentKey Digital Rights Management (CKDRM) playback or digital rights management (DRM) Copy Licensed Archives. In this ContentKey Digital Rights Management (CKDRM) playback method, the received content may not need to be stored; in addition, in this Digital Rights Management (DRM) copy method, the received content needs to be stored. The parameters required for this command include: HostCmd, which can be set to DPICMD_CK_COMMAND, CkSubCmd, which can be set to CKCMD_PLAY, PlayOptions, which are options of this command. In addition, PlayFile is the DataPlay File System (DFS) disposal of the file to be accessed, and ByteOffset is the position in the file where the transfer operation is to be started. Due to the encryption action of this file, the value of ByteOffset can be a multiple of sixteen. In one embodiment of the invention, this value must be a multiple of sixteen. In addition, ByteCount is the number of bytes to be transferred. If the PLAY_TO_EOF bit can be confirmed in PlayOptions, this field is odd to ignore; otherwise, ByteCount must be a multiple of sixteen. ESessionKey is the current secure session key. See CKCMD_AUTHENTICATE for more information. EplayKey is the playback session key of the file specified by PlayFile, and it is used to perform encryption operations using this secure session key. This value can be the same as the value returned by the EPlayKey field of the previous command of this engine in the same file. For this ContentKey Digital Rights Management (CKDRM) playback method, this previous command is CKCMD_GET_CKDRM_PLAY_KEY. For digital rights management (DRM) replication methods, this previous command is CKCMD_GET_DRM_COPY. another In addition, the returned data is the content of this file, which is used to encrypt the playback session key. CKCMD_PLAY is used to return the contents of this file, which is used to perform the encryption action using this playback session key. In addition to content encryption, the CKCMD_PLAY command is functionally equivalent to DSF_READFILE. Please refer to the DataPlay File System Command Specification for a complete description of these options and end-of-file behavior. CKCMD_RECORD_APPEND: Check the ContentKey Digital Rights Management (CKDRM) license and transfer secure content from a host to the end of a file.

Table 34: Command Begins

Register Name Value Description Control Register FUNCTION_CODE = 011 Reset Byte Count Index to Low Byte Byte Count Register CKCMD_RECORD_APPEND_SIZE Command Packet Size Control Register FUNCTION_CODE = 001 Start Command

Table 35: Command packets

Byte shift field name type description 0 HostCmdU8 command code 1DfsSubCmdU8 secondary command code 2: 3 RecordOptionsU16 record option. Please refer to the encoding procedure. 4: 7RecordFileDFSHANDLE 8: 15ByteCountU64 The number of bytes to be transferred 16: 31ESessionKeyWRAPPED_KEY The current secure session key 32: 47ERecordKeyWRAPPED_KEY The current record session key

Table 36: Recording option codes

Byte shift field name description 0RECORD_FOREVER0 = Recording is normal; the number of bytes specified by the transfer ByteCount 1 = always recorded; ignore the ByteCount field 1:15 reserved

The CKCMD_RECORD_APPEND command, in one embodiment of the present invention, will require a current secure conversation. In addition, only the host with the permission of the ContentKey Digital Rights Management (CKDRM) recording method can access the CKCMD_RECORD_APPEND command. In addition, RecordFile must specify a file with ContentKey Digital Rights Management (CKDRM) records and DataPlay File System (DFS) write permission. This file can be locked or unlocked. The parameters used by this command include: HostCmd, which can be set to DPICMD_CK_COMMAND, CkSubCmd, which can be set to CKCMD_RECORD_APPEND, Recordoptions, which are options of this command and are acted upon in the manner described by a RecordOptions encoding form, RecordFile It is the DataPlay File System (DFS) disposal and ByteCount to access the file, and it is the number of bytes to be transferred. However, if the RECORD_FOREVER bit can be confirmed in RecordOptions, this field can be ignored, ESessionKey, which is the current secure conversation key, ERecordKey, which is the current record conversation key, and Encryption can be performed using the engine's protocol key. In one embodiment of the present invention, all examples of this command can use the same recording session key, and the recording session key must match the recording session key of the command CKCMD_CREATE_FILE that generated the file. In addition, the received information is the content of the file to be added. Furthermore, at least this data will be encrypted using this recorded session key. According to an embodiment of the present invention, the CCKMD_RECORD_APPEND command is used to add content to the end of the specified file. In addition, the function of the CKCMD_RECORD_APPEND command is exactly the opposite of the CKCMD_PLAY command. The function of the CKCMD_RECORD_APPEND command is roughly equivalent to DFSCMD_WRITE_APPEND, except for the method of data encryption. CKCMD_SET_KEYBOX: A key box for transferring _ specific files by this host. This key box is used to provide a key to unlock the data and can be linked to this media if the content is pre-recorded.

Table 37: Commands Begin

Register name value description Control register FUNCTION_CODE = 011 Reset the byte count index to Low byte byte count register CKCMD_SET_KEYBOX_SIZE command packet size control register FUNCTION_CODE = 001 start command

Table 38: Command packets

Byte displacement field name type description 0 HostCmdU8 command code 1DfsSubCmdU8 secondary command code 2: 3ReservedU16 Reserved 4: 7AssociatedFileDFSHANDLE file related to KEYBOX

Table 39: Recording option codes

Byte shift field name type description 0: nKeyBox key box for file

There must be a current security dialogue here. Any host can access the CKCMD_SET_KEYBOX command. AssociatedFile must specify an unlocked file and cannot have a key box or ContentKey Digital Rights Management (CKDRM) metadata. The parameters required for this command include: HostCmd, which is set to DPICMD_CK_COMMAND, CkSubCmd, which is set to CKCMD_SET_KEYBOX, AssociatedFile, which is the file associated with KeyBox DataPlay File System (DFS) disposal, KeyBox, is the key box for the file specified by AssociatedFile and the destination specified by CKDRMId. This command is used to explain: the engine is used to write the key box to the media, and to associate the key box with a specific file, so that files that allow the ContentKey Digital Rights Management (CKDRM) method can start up. CKCMD_SET_METADATA: Check permission to write security metadata, and transfer third party, host-specific security metadata from this host to this media.

Table 40: Command Begins

Register Name Value Description Control Register FUNCTION_CODE = 011 Reset Byte Count Index to Low Byte Byte Count Register CKCMD_SET_METADATA_SIZE Command Packet Size Control Register FUNCTION_CODE = 001 Start Command

Table 41: Command packets

Byte displacement field name type description 0 HostCmdU8 command code 1DfsSubCmdU8 secondary command code 2: 3ReservedU16 Reserved 4: 7AssociatedFileDFSHANDLE metadata related file 8: 23ESessionKeyWRAPPED_KEY The current secure session key

Table 42: Data transfer (from host to engine)

Byte displacement field name type description 0: n-1Metadata Security metadata associated with a specific file and host; n bytes

There must be a current security dialogue here. In addition, only hosts that have permission to write secure metadata methods can access the CCKMD_SET_METADATA command. AssociatedFile must specify an unlocked file. In addition, AssociatedFile can already have metadata specific to this host's MetadataIdentifier value. The parameters required for this command include: HostCmd, which is set to DPICMD_CK_COMMAND, CkSubCmd, which is set to CKCMD_SET_KEYBOX, AssociatedFile, which is the DataPlay File System (DFS) disposition of the files associated with this metadata, EsessionKey, which is the current Security conversation key. Please refer to CKCMD_AUTHENTICATE for more information. In addition, Metadata is the securely stored metadata of the current host and associated with this file. The CKCMD_SET_METADATA command is a complementary function of the CKCMD_GET_METADATA command. This command is used to write digital rights management (DRM) or host-specific security metadata to a specific file of DataPlay media. This received metadata will be hosted here And the file's subsequent CKCMD_GET_METADATA command. If the AssociatedFile already has metadata specific to the MetadataIdentifier value of this host, the media will use this new metadata to perform the replication action. This engine is used to write this metadata to this media and associate this metadata with this specified file and this host of the current secure conversation. In addition, the engine will not interpret this metadata in any way. In addition, the security metadata can only be accessed through the host specified by the MetadataIdentifier field in the ContentKey Digital Rights Management (CKDRM) certificate of the host of the current secure conversation. CKCMD_UNLOCK_FILES: Check the ContentKey Digital Rights Management (CKDRM) unlock permission, and perform an unlock operation on the file.

Table 43: Command Begins

Register Name Value Description Control Register FUNCTION_CODE = 011 Reset Byte Count Indicator to Low Byte Byte Count Register CKCMD_UNLOCK_SIZE Command Packet Size Control Register FUNCTION_CODE = 001 Start Command

Table 44: Command packets

Byte shift field name type description 0 HostCmdU8 command code 1DfsSubCmdU8 command code 2: 3FileCountU16 Number of files to be unlocked, n. 4: 7ReservedU16 [2] Reserved 8: 23EunlockKeyWRAPPED_KEYEkeyComplement encrypted unlock key 24: 39EmediaIdU128 Public and unique media identifier 40:59 DataMacMAC Data transfer message authentication code

Table 45: Data transfer (from host to engine)

Byte shift field name type description 0: 24n_1FileSetFILE_SET [n] File ID of a table to be unlocked

Table 46: FILE_SET data structure

Byte displacement field name type description 0: 3HandleDFSHANDLE File to be unlocked 4: 23EKeyComplementU160 The complement of the key group of this file

There must be a current security dialogue here. In addition, only hosts with permission to unlock ContentKey Digital Rights Management (CKDRM) methods can access the CKCMD_UNLOCK_FILES command. In addition, the Handle field in this FileSet table must also specify a file and must have Metadata for ContentKey Digital Rights Management (CKDRM). The parameters required for this CKCMD_UNLOCK_FILES command include: HostCmd, which is set to DPICMD_CK_COMMAND, CkSubCmd, which is set to CKCMD_UNLOCK_FILES, FileCount, which is the number of files to be unlocked, EunlockKey, which is the encrypted unlock key and encryption key The key complements the key to form the EkeyComplement value, Emedia, which is the encrypted media identification code, DataMac, which is the message authentication code for this data packet. In addition, use the FileSet field for calculation. FileSet is an array of unlocked file identifiers, where the number of items is the value specified by FileCount, and each item is a FileSet component, and the Handle field is The DataPlay File System (DFS) disposal of the file to be unlocked, the EkeyComplement field is the key set complement of the file (that is, the complete key box does not exist on the media, and the field is It is used to provide the rest of the key box for decrypting this file), and EkeyComplement is the complement value using the engine's public key to perform the encryption action. The CKCMD_UNLOCK_FILES command is used to enable the engine to unlock a group of files. Here, a secure dialogue with this host must be initiated, and this host must also have ContentKey Digital Rights Management (CKDRM) unlock permission. In a successful CKCMD_UNLOCK_FILES command, this engine is used to complete the key box of each file and change its attributes from locked to unlocked.

Encryption algorithm

These third-party digital rights management (TPDRM), ContentKey digital rights management (CKDRM), and DataPlay file system (DFS) methods described above are implemented using encryption algorithms. The way these encryption algorithms are applied in these methods depends on the requirements of the design. Therefore, the encryption technology described in the specification is used as an example of the present invention. The number of bits applied to the encryption technology is a function related to the available bit space and cost efficiency. In one embodiment of the invention, the Advanced Encryption Standard (AES) function can use a 128-bit key. This public key encryption can be elliptic curve encryption, or another suitable type of encryption method. Please refer to these ContentKey Digital Rights Management (CKDRM) methods again. Key encryption is the key complement used in these UNLOCK methods. For example, the CKCMD_UNLOCK_FILES method requires the transfer of keys. Therefore, an embodiment of the present invention is used to explain that the key complement is transmitted in the EkeyComplement field. This key complement can use this unlocked key to perform encryption and decryption with Advanced Encryption Standard (AES), just like this Advanced Encryption Standard (AES) key pair. Other fields that can be applied to this UNLOCK method include: media identifier and EmediaId fields. In one embodiment of the present invention, the CCKMD_UNLOCK_FILES method is used to explain that the media identification code is transmitted in the EmediaId field. In addition, these media identification codes can also be used as a secure conversation key, using the Advanced Encryption Standard (AES) for encryption and decryption, just like this Advanced Encryption Standard (AES) key. The fields of message authentication code, CommandMac, DataMac, and RevocationMac can also be applied in the method of unlocking, and can also be applied in the method of CKCMD_CREATED_FILE. In particular, message authentication codes are transmitted in fields such as CommandMac, DataMac, and RevocationMac. In addition, the message authentication code can also be generated using the message authentication code (MAC) function of the secure hash algorithm-1 (SHA-1). Furthermore, the key of the message authentication code (MAC) function is the current secure conversation key. Encryption of playback conversation content is applied to CCKMD-PLAY of this ContentKey Digital Rights Management (CKDRM) method. In particular, the playback pair content can be transmitted in the data transfer phase of the CCKMD-PLAY method. In addition, this content can also play the conversation key, use the Advanced Encryption Standard (AES) to perform encryption and decryption actions, just like this Advanced Encryption Standard (AES) key. Play encrypts the key and applies it to CCKMD_GET_CKDRM_PLAY_KEY, CKCMD_GET_DRM_COPY, and CKCMD_PLAY in this ContentKey Digital Rights Management (CKDRM) method. In one embodiment of the present invention, the playback dialog key may be transmitted in the EplayKey field or another appropriate field. In addition, the playback session key can also use this secure session key to perform encryption and decryption using the Advanced Encryption Standard (AES), just like this Advanced Encryption Standard (AES) key. For encryption of recorded conversation content, the ContentKey Digital Rights Management (CKDRM) uses the method CCKMD_RECORD_APPEND. In addition, the recorded conversation content can also be found at CCKMD_RECORD_APPEND In this method, the transfer operation is performed during the data transfer phase. Furthermore, this content can also be used for this secure conversation key, using the Advanced Encryption Standard (AES) for encryption and decryption actions, just like this Advanced Encryption Standard (AES) key. Similarly, for record conversation key encryption, ErecordKey, this Contentkey Digital Rights Management (CKDRM) uses the methods CKCMD_CREATE_FILE and CKCMD_RECORD_APPEND. The record conversation key is transmitted in the fields of ErecordKey. For an embodiment of the present invention, the record dialogue key is a protocol public key of the engine as the public key, and an encryption operation is performed by using the public key encryption function. This public key is a ContentKey Digital Rights Management (CKDRM) certificate from this engine. In addition, the encrypted recording session key can be decrypted by using the engine's private key corresponding to the engine's protocol public key and using the private key decryption function. For secure session key encryption, the EsessionKey field is applied to these ContentKey digital rights management (CKDRM) methods, which include: CKCMD_AUTHENTICATE, CKCMD_CREATE_FILE, CKCMD_GET_CKDRM_COPY, CKCMD_GET_CKDRM_CMD, CKCMD, CKCMD, CKCMD, CKCMD , And CKCMD_UNLOCK_FILES. In addition, the secure session key can be transmitted in the EsessionKey field action. This secure session key is based on the host's protocol public key as the public key, and the public key encryption function is used to perform the encryption operation. This public key is the ContentKey Digital Rights Management (CKDRM) certificate from this host, which is used for the current secure conversation. In addition, the encrypted secure session key can also use the private key corresponding to the host agreement public key and use the private key decryption function to perform the decryption operation. For unlocking encryption, an embodiment of the present invention is to use the fields CKCMD_UNLOCK_FILES of the ContentKey Digital Rights Management (CKDRM) method and use the EunlockKey. For this method, these unlocked keys are transmitted in the EunlockKey field. For an embodiment of the present invention, the unlocked key is the public key of the engine protocol as the public key, and the public key encryption function is used to perform the encryption operation. In addition, the public key can come from the Engine's ContentKey Digital Rights Management (CKDRM) certificate. The encrypted unlocking key is a private key of the engine corresponding to the public key of the engine agreement, and the private key decryption function is used to perform the decryption operation. Furthermore, an embodiment of the present invention includes a clear routine with the following code, and a person skilled in the art can also obtain any other code that does not conflict. The following clear routine is an example of non-conflicting code.<img file="TW583568B_D0001.tif" /><img file="TW583568B_D0002.tif" /><img file="TW583568B_D0003.tif" /><img file="TW583568B_D0004.tif" /><img file="TW583568B_D0005.tif" /><img file="TW583568B_D0006.tif" /><img file="TW583568B_D0007.tif" /><img file="TW583568B_D0008.tif" /><img file="TW583568B_D0009.tif" /><img file="TW583568B_D0010.tif" /><img file="TW583568B_D0011.tif" />

Method implemented using a server

Another embodiment of the present invention relates to the interaction between a server and other entities (such as a player). Therefore, this secure electronic content (SEC) system can include interactions between the server, the host, and the engine, so as to unlock and display the secure content. In addition, the ContentKey Digital Rights Management (CKDRM), DataPlay File System (DFS), and Third Party Digital Rights Management (TPDRM) can also interact to unlock content in a secure environment. Please refer to FIG. 23A, which is a system architecture diagram of an embodiment for providing interaction between a server, a host, and an engine. As shown in the figure, this server (such as a digital information exchange server 2394) is a network-initiated communication connection 2360 to interact with an electronic retailer (eTailer). Take channel 2334 to interact with a device connected to a personal computer (PC) 2398. The device connected to the personal computer (PC) 2398 receives the communication message from the server 2394 through a web browser 2318, and a CKU client 2322 is used to receive the communication message. In addition, the web browser 2318 further includes a dynamic webpage generated by an e-tailer, which is used to receive signals from an application server 2354. The application server 2354, in an embodiment of the present invention, further includes a markup language (HTML) and a graphic User interface (GUI) generator object, an envelope display and pricing object 2338, a consumer management object 2344, a dialog management object 2346, a credit card authorization object 2348, a digital information exchange server (DCS) interface 2352 And a database connection layer, thereby coupling the application server 2354 to a plurality of databases 2356. These databases 2356 and the application server 2354 are part of the eTailer online storefront 2396. In particular, those databases in the eTailer online store storefront 2396 include a consumer database 2358, a software package and pricing database 2362, and a dialogue and transaction database 2364. As is known to those skilled in the art, however, the database in this eTailer online store is based on design requirements and can include more or fewer objects and databases as described in the manual. Please refer to the device connected to this personal computer (PC) 2398. As mentioned above, the web browser in this device connected to this personal computer (PC) is connected to a server through a secure access channel 2334. Such as: Digital Information Exchange Server 2394. The web browser 2318 further connects to a universal serial bus (USB) driver 2312 through a secure access channel 2316. It also uses a secure access protocol to connect the universal serial bus (USB) The driver 2312 is connected to a universal serial bus (USB) port and is connected to an engine 2306 coupled to a device 2304. This device 2304 is coupled to the media 2302. This universal serial bus (USB) driver 2312 is not only connected through a secure access channel 2316, but also can be coupled to one through a signal line 2313 Installable File System (IFS) 2314. The installable file system (IFS) 2314 is coupled to an automatic execution process 2328 (as described in the description) and a content management device 2326. The content management device is used to receive the signal of the installable file system (IFS) and the automatic execution processing 2328, and can also provide the content managed by the content management device 2326 to the web browser 2318. The server 2394 (which receives signals through the signal line 2360 and the signal line 2334 at the same time) is used to use the Hyper File Transfer Protocol (HTTP) or other appropriate protocols in a network environment to simultaneously communicate with this electronic retailer ( eTailer) online store storefront 2396 and a device connected to this personal computer (PC) 2398 perform communication operations. The signal line 2360 coupling the application server 2354 to the digital information exchange server 2394 is used to receive signals from an eTailer interface 2382 in an information exchange server 2399. This digital information exchange server 2394 includes an information exchange server 2399. In addition, the information exchange server 2399 includes the eTailer interface 2382, so as to communicate with a plurality of databases (including a software package database 2386, a consumer and eTailer database 2388, a consumer The user database 2390 and a dialogue and transaction database 2392) perform communication operations. In addition, a digital information exchange service object 2384 is also included in the information exchange server 2399. The information exchange server 2399 is an integrated object 2376 coupled to the digital information exchange server 2394. The integration object includes a software package, in particular, a key mapping database 2380. In addition, a communication protocol is included in the integration object 2376. Or application programming interface (API) 2378. The communication protocol object is coupled to a CKU original video production server 2368 and a package software database 2386 inside the information exchange server 2399. In addition, the original CKU video production server 2368 is located inside this content key server 2374. The content key server 2374 includes at least a key complement database 2370 and a transaction database 2372, which are respectively coupled to the CKU original video production server 2368. Furthermore, the original CKU video server 2368 is further coupled to a CKU server 2366, which communicates with the CKU client 2322 in a device connected to the personal computer (PC) 2398 through a signal line 2334. Figure 23B depicts a program from a creative perspective, thereby representing a writing program 2300. Block 2310 is used to write content to take advantage of this content provider (which has the option to include secondary content in block 2320, which can be unlocked by this consumer at some point after the original purchase) Perform the original movie production action on the media. If secondary content is not included on this media, block 2350 will distribute the unlocked content on the media. If this media includes secondary content, then this media will include a key, which is obtained in block 2330 by making the original film on this media. Therefore, media with locked content can output a key complement for each locked file on this media. Immediately after, these key complements (with the associated provisioning software package), DataPlay File System (DFS) file disposition, and media side content identification (SCID) can be collected and added to a security key in block 2340. Complement database, which can only pass through this CKU original video production server for access. According to an embodiment of the present invention, a server of the media and clearinghouse type is configured as a part of an original movie production process, or as a server and a part of a setting process in other embodiments. In particular, please refer to FIG. 24, which is a flowchart showing a setting procedure for obtaining a secure database and a medium (such as a media disc). This clearinghouse server database architecture flowchart is intended to provide a method for setting up a clearinghouse type server. In particular, the process begins at block 2402. Block 2404 is used to enable a content provider to provide a new version of the content to the server during a procurement process (such as the illustrated "asset and information procurement" process). Those supplements included in this procurement process include: content files, metadata information, data security information, and packaged software collection data (if required). These content files are files that are linked to a specific type or category of content. These content files may also include an appropriate media codec in one embodiment of the present invention. In addition, metadata information includes descriptions of any components that accompany a file's content, such as graphics or lyrics. In one embodiment of the invention, the metadata belongs to a structured format. In other embodiments of the invention, this format may be determined by individual content providers. Furthermore, an embodiment of the present invention also requires metadata to be provided on a per-track or per-album basis. This data protection information refers to the rules governing how consumers interact with content. For example, this information could include a revocation list, and Third Party Digital Rights Management (TPDRM) and ContentKey Digital Rights Management (CKDRM) rules. In addition, the revocation list can be defined by a content provider, and can include a list of player devices, player applications, and servers that have been retired. In addition, these components received by a content provider will also include digital rights management (DRM) rules to provide consumers with restrictions on playing and copying content. In addition, these digital rights management (DRM) rules can also include other details, so that the original movie production process can understand which files need to be locked initially. In addition, box 2406 also includes package software to collect information to specify how the secondary content should perform group actions and how the secondary content should be presented to this user. Block 2408 is about writing a program that can be done through DataPlay or a third party. In particular, this writing procedure also includes the action of putting all the files received by a content provider into software according to a predetermined specification. In one embodiment of the present invention, the directory is created using the following data, which includes: a content file (encoded), a directory structure, a content management device, autorun.inf, and contents.ddl. The content management device includes a file (such as an executable, mini-website, or some form defined by the content provider) for presenting content or media to consumers. The autorun.inf is used to start the content management device. The contents. Ddl is stored in a common area for use in any digital edition management (DRM). In addition, the contents. Ddl can also include a software package And storage units (SKUs). These storage units (SKUs) can reference one or more archives. This packaged software collection, in one embodiment of the present invention, is a unique identification number (PCID) on the side of all secondary content or media. In addition, the software package collection may also include a reference relationship with one or more advertisements (for example, referring to a software package collection). In addition, block 2410 is used to explain: part of the writing procedure includes the action of providing a DataPlay Massive Memory File (MMF) Data Description Language (DDL) file to explain the relationship between content and asset files. In addition, block 2412 is used to start a pre-recorded program after the writing procedure (as described in block 2408). In particular, this pre-recorded program includes three elements 2414, 2416, and 2418. The flag 2414 refers to a key element. The ddl function, where a file called KeyComplement. ddl is generated to construct a secure content key database. In addition, this KeyComplement. Ddl file also contains a software package collection identifier. This software package collects the identification code. In one embodiment of the present invention, it includes a complete file path name, a file disposition, a key complement (which can be 128 bits), and A key version. In addition, this pre-recorded program also includes: a function that transfers contents. Ddl (which is generated in the writing program) along a file. This file contents. Ddl 2416 is then imported into the next program (ie the content key package software program). Another part of this pre-recording program 2412 is a DataPlay media original film production program, which The file is set on a tape. In particular, the original video production file settings are generated in block 2418, which is an embodiment of the fundamental invention for storing and transmitting operations on a magnetic tape. In addition, in other embodiments of the present invention, the original movie production file may also be located on another type of media. Each original video production file setting refers to a single side on a media disc, according to an embodiment of the present invention. In addition, block 2420 (shown in the figure) is coupled to the contents. Ddl block 2416 and the KeyComponent. Ddl block 2414. In addition, block 2420 particularly refers to an original video production server key complement setting process, which can also be referred to as a digital information exchange server setting process, which involves data migration to a linked security database. The original video production server key complement setting procedure 2420 is used to load a software key mapping database table so that these tables can use the data specified in these KeyComponenet.ddl and Contents.ddl files to Perform the loading operation. This block 2418 (DataPlay original video production file settings on the tape) is coupled to this pre-recorded program 2412 (as shown in the figure). In particular, the setting of the original film making file on a tape program 2418 refers to: generating one or more "glass original films" if the medium is a disc. In other embodiments of the present invention, the original film making file setting will perform the original film production process on an appropriate media type. In addition, in one embodiment of the present invention, the original glass film is used to generate one or more stamping machines. The stamping machine can then be used to mass produce the media 2426 for distribution or supply for trading. Here, this stamping procedure It is a manufacturing process. Please refer to FIG. 25 and FIG. 23B, which use a flowchart to explain a setting procedure to set up the e-tailer. Please refer to FIG. 23B. The eTailer website store store 2396, as shown in the figure, includes an application server 2354 and a database 2356. Figure 25 is used to explain the setting operation of this program. In particular, the process begins at block 2502. Subsequently, block 2504 is used to explain that the content provider package software system is set and a change process related to a package software definition is started. This e-tailer (eTailer) usually requires a packaged software storage unit (SKU) for auditing purposes and other purposes, and may also use a packaged software to collect the identification code (as described earlier). Furthermore, the identification code collected by this software package is transmitted to an e-tailer through a global resource locator (URL), and the e-tailer will continue to hold the identification code until it is transmitted Give a digital information exchange server. In one embodiment of the invention, the e-tailer (eTailer) discards the software package to collect the identification code. The content provider (as described earlier) will supply Contents. Ddl (see Figure 24) and any graphics that will be part of the package presentation in blocks 2508 and 2506 to this e-retailer (eTailer). As shown in the figure, blocks 2506 and 2508 are coupled to block 2510, which is the e-tailer's software package and pricing setting and change procedure "pricing definition". In particular, wait for a content provider to provide an available package This e-tailer can then set its pricing role. The details of using a software package, pricing, and software package to structure a database can be fully defined by an eTailer and can also be used with an existing "shopping cart" and / or the electronic retail (eTailer) 's catalog maintenance functions are consistent with each other. In addition to pricing, in one embodiment of the present invention, an electronic retailer (eTailer) may also choose to specify a discount model and advertising specifications. For example, a customer can choose a software package and pair it with an advertisement that fits this consumer. As shown in the figure, block 2510 is coupled to the database 2512 and the eTailer security database software package pricing and presentation form, that is, the end product set by the eTailer database. The eTailer security database table shown in block 2512 is the software package and pricing database 2352 in FIG. 23B, and may further include a consumer database 2358. Figure 26 illustrates a transaction that unlocks content from the perspective of a consumer. In particular, program 2600 presents various supplies to a consumer in block 2610. Block 2620 is used to receive a satisfactory condition for unlocking. For example, a condition for unlocking a transaction might be to provide payment and / or statistics. Block 2630 passes this key complement to an engine through a secure authentication channel (SAC), for example. The engine then writes the material to the media, thereby changing the state of the content from locked to unlocked. Please refer to FIG. 27, which is a user interface 2700 used to illustrate an example. This user interface can be generated using a web server and can include a presentation of user options, so that the user can decide not to present some types of offerings when this media is inserted in the future. If this user selects this option, a note needs to be generated on the user's system, or on the media marked with this option. As shown in the figure, this user interface 2700 is one embodiment for initiating an unlock transaction. In particular, the user interface 2700 may also be a webpage with a hyperlink, such as a hyperlink 2730 that points the user to an activation center to enter necessary information to complete an unlocking method. In addition, this page also includes a status indication of whether the media is read or interpreted 2710, because this interface includes both locked and unlocked files. If a file on this media is locked, a hyperlink to purchase 2750 will be presented to the user. For unlocked files, this interface is used to provide a hyperlink 2720, so that users can play a selected clip on this media. The unlocked part of this secure electronic content (SEC) system is an architecture of several common tool components. One embodiment is shown in FIG. 28. As shown in the figure, several components are common tools to unlock the secondary original video production content. The secondary original video production content is stored on pre-recorded media. According to an embodiment of the present invention, in this secure electronic content (SEC) system, the architecture of the CKU part includes a communication protocol, so as to obtain flexible choices at the client and server platforms at the same time. In addition, according to one aspect of the present invention, In an embodiment, these communication protocols may also support various business models for unlocking and information exchange actions, which may have different components at different related component locations. FIG. 28 is an embodiment showing the connection relationship between the various elements in FIG. 23B and a broader view of the secure electronic content (SEC) system. As shown in Figure 28, this unlocking system includes one or more databases coupled to an original video production server. In one embodiment of the present invention, the databases coupled to the original video production server include a key complement database 2810, a transaction database 2820, and a revocation list database 2830. This original video production server 2840 is coupled to a web server 2850, which is further coupled to a secure CKU server. The CKU original film production server 2840 can be hosted by a certificate management center (CA) or other entity responsible for identifying the engine certificate and the CKU server certificate by referring to a revocation check action. In addition, the CKU original video production server 2840 can also be responsible for safely transmitting the key complement from an original video production key complement database 2810 to these CKU servers 2660, which can transmit it to the engine 2898. The CKU server 2860 can be a server-side runtime object, which is a common tool with a web application server 2850 and several databases 2870, 2880, and 2890 to manage the ContentKey unlocking action. part. In addition, the CKU server 2860 can also be hosted by any entity that requires these capabilities, thereby enabling secondary content management of ContentKey Digital Rights (CKDRM), such as: An information exchange partner (Reciprocal, DWS, Magex, etc.), the retailer's website, or DataPlay to conduct transactions and unlock actions. In addition, each CKU server 2860 can issue a unique ContentKey Digital Rights Management (CKDRM) certificate and a public-private encryption key pair to establish these security authentications with this engine 2898 and this CKU original video production server 2840 Channel (SAC). Moreover, this CKU server 2860 can also be equipped with encryption function. For example, the CKU server 2860 may include the following functions, such as: Public Key Infrastructure (PKI), Advanced Encryption Standard (AES), Triple Data Encryption Standard (triple-DES), and Message Authentication Code (MAC) Algorithm. Furthermore, a random number generator (RNG) algorithm, such as an algorithm consistent with Federal Information Processing Standards Document 140 (FIPS-140), may also be appropriate. The web server 2850 is coupled to one or more databases according to the requirements of the system, such as a common brand component 2870 of a third party dealer, a supply database 2880, and a transaction database 2890. The CKU server 2860 is coupled to a client server 2896 and a webpage 2892 hosted by the client server 2896. This webpage 2892 is used to provide an interface for a user to communicate with other components in the secure electronic content (SEC) system. In particular, a host device 2894 holding an engine can also perform communication operations through this webpage 2892. Communication between these components can also be performed through a standard TCP / IP protocol. Moreover, this user interface can also be presented to a browser via a browser and a web server 2850. End users. As those skilled in the art know, administrative and reporting tools may also be appropriate. Figure 28 is used to represent a supply database 2880, which may include related to the available secondary content on each pre-recorded media disc (for example, pricing, title, description, etc.) Information. And, both the content provider and the retailer can perform maintenance on this database. In addition, an exchange database 2890 is included in the illustration, which is used to provide a place to record unlocked transactions. Furthermore, these collected data can also be used to determine the payment methods of each entity participating in the unlocked transaction value chain. This transaction database 2890 can also store transient information related to ongoing transactions. In addition, these CKU servers 2860 and web servers 2850 may also request access to this temporary data. In addition, the user interface component database 2870 may also include information used by the web server 2850 to create a custom brand webpage or website. This action can include: tagging actions at the retailer level, and individual tagging actions based on the specific inventory unit (SKU) of the supply media. The database key complement database 2810 may also include an unlock code (such as a key complement of an original movie production medium). In addition, each individual file locked on a piece of media can also have a unique key complement. These key complements, in one example, are transmitted securely by a pre-recorded procedure in the manufacturing process and stored with the media side content identification code (SCID) information corresponding to this media. Moreover, this Access to each database also needs to be closely guarded. Therefore, only a certified original CKU original video production server 2840 can access the database. Furthermore, this revocation database 2830 may also include information related to revocation of engine certificates and revocation of CKU server certificates. This revocation database 2830, in one embodiment of the present invention, performs a check operation in each transaction to ensure that only authorized participants can participate in this unlocking process. In addition, the transaction database 2820 can also record transactions between the CKU server 2860 and the CKU original video production server 2840. In one embodiment of the present invention, the CKU original movie production server 2840 has exclusive access rights to this key complement database. In addition, the original CKU video production server 2840 may also be similar in structure to this CKU server 2860 and set an activated "listening" slot to receive incoming connection status. This slot is used to accept the connection of the CKU server 2860, which is used to obtain the key complement to perform various operations to unlock. FIG. 29 is an example of a program (which starts when a media disc is inserted into an engine 2952 through a personal computer (PC) 2950), in which such a program is through an information The clearing house website server 2960 presents a record label or retail brand website 2910 to provide supplies 2920, transactions 2930, and unlocked content 2940, and the clearing house website server 2960 is coupled to a transaction database 2980 And a supply database 2970. How is this media Pointing this engine to a particular website is a method according to one embodiment of the invention. In particular, please refer to FIG. 30, this media (such as: DataPlay disc 3010) is available for purchase, in which the user may have paid for the main content 3020 and the secondary content 3030 may include bonus content 3040. Alternatively, one or both of the primary and secondary content may also be locked or unlocked, depending on market demand and the requirements of the content provider. For example, a content provider can provide free discs with a minimum amount of unlocked content. Therefore, an engine in a player can be started to play only a minimum amount of content. Please refer to FIG. 31A. According to an embodiment of the present invention, the media can be bought and sold in a plurality of institutions, such as those shown in 3120. A consumer can purchase a pre-recorded disc in a major transaction and present this available content, as shown in block 3130. In addition, in a secondary transaction 3140, the consumer can choose to execute the various supplies presented through an Internet connection (which is coupled to an engine in 3140), through a secure intelligence exchange Therefore, the content 3151 is unlocked. Please refer to FIG. 31B. This user interface and, in particular, an automatic execution process related to a user interface is used to execute method 3000. This automatic execution is responsible for detecting when the media (such as a disc) is inserted into a device connected to a personal computer (PC). When this media insertion is detected, the self-executing action is connected to an engine and determines the state of the media. This state can include These include: identifying this particular medium and profile, and whether there is any content available or sold to this consumer. In addition, this automated execution can also check the user's system or the media to determine if the user has requested any additional supplies that do not have to present the disc. Furthermore, block 3122 is used to determine whether there is locked content available to this user through a user interface. An embodiment of the present invention relates to a method by which a user interface can be operated by a driver of an engine, or an automatic execution process (which is executed when the system is started or selected by the user) ) To proceed. In addition, this automatic execution of disposal can also present menu options to this user, which include the following options: PLAY, EJECT, PURCHASE ADDITIONAL CONTENT, and EXIT. If there is locked content, the interface will decide in block 3132: whether the user previously requested not to see the various supplies of the media again. If so, the method ends at block 3133. If not, block 3142 will let this interface determine the side content identification code (SCID) and lock status flag for this media. Block 3152 is used to connect to a Global Resource Locator (URL), such as a ContentKey Digital Rights Management (CKDRM) compatible unlocked server address or associated server address, which can use the original video production process To record to this media and send this data to this server, such as by querying the string in the Global Resource Locator (URL). In other embodiments of the present invention, block 3152 is connected to a global resource locator. (URL), which is a serial number recorded on this medium using the original movie production program. The number recorded on this media using the original video production program can be a timestamp (indicating the date of the original video), a serial number (both or both) associated with a server or Global Resource Locator (URL) Neither). In one embodiment of the present invention, for example, this serial number or timestamp will be helpful to the distributor who pre-recorded the media to return the media disc to its source. In addition, block 3152 is used to connect to a global resource locator (URL), such as a ContentKey Digital Rights Management (CKDRM) compatible unlock server address or associated server address, which can use the original video Make a program to record to this media and send this data to this server, such as by querying the strings in this Global Resource Locator (URL). In other embodiments of the present invention, block 3152 is connected to a global resource locator (URL), which is a serial number recorded on this medium using an original movie production program. The number recorded on this media using the original video production program can be a timestamp (representing the date of the original video), a serial number (both or both) associated with a server or Global Resource Locator (URL) non). In one embodiment of the present invention, for example, this serial number or timestamp will be helpful to the distributor who pre-recorded the media to return the media disc to its source. In particular, in one embodiment of the invention, a method is related to identifying one or more vendors associated with a media disc. This method includes: Provide instructions for this media disc, such as: The instruction includes a global resource locator (URL), or provides a code associated with a global resource locator (URL). In addition, this method can also be used to install an identification code on the media disc while the media disc is mounted on a host according to these instructions. The identification code can be a code used to identify the supplier, and the media disc is provided by the supplier. For example, a method is to identify an address of a supplier associated with a media disc (including hidden content), including: finding an address related to this supplier, where, This address is associated with the vendor of this media disc and is independent of any vendor that is not associated with this media disc. The instructions for the media disc may include the actions of identifying a supplier, wherein the media disc is purchased by the supplier. For example, the media disc may be provided with the following instructions, including: a code, a global resource locator (URL), an encryption key associated with the vendor, and an encryption associated with the vendor A part of a key, which can be an explicit or implicit location, respectively. In addition, a system according to such a method may also include instructions for the media disc and a software installation component associated with the media disc, wherein the software installation component may be installed on the media disc according to these instructions to A host period is used as an example. In particular, the software installation component is operable to install an identification code on the media disc, wherein the identification code includes a code associated with the supplier. In one embodiment of the invention, the identification code is associated with an address of the supplier, so that A connection between this host and a server can be operated to open this address. For example, this address can be an Internet location, which includes: a webpage that unlocks content stored on this media disc, and this Internet location can further provide selective provisioning, This allows this supplier to buy and sell on the Internet. In another embodiment of the present invention, a method for identifying a location through a media disc is related to the media disc, which has at least a writable portion and a non-rewritable portion. In this embodiment, the method includes: writing the position to the surface of the writable portion, and distributing one or more media discs to one or more entities, wherein the position is used to copy the position These media discs are associated with one or more entities, and if a return action occurs on these media discs, this position is changed according to predetermined conditions. The location may be a global resource locator (URL), and the predetermined conditions may include: determining a market share of the entity or entities. The action of changing this position can be performed by a content provider. To this end, the content provider first receives the media disc (including one or more media discs), and returns the returned Media disks are scattered to the same or different entities in this or these entities. For example, the distribution may be based on a lease contract for a media disc, and the lease contract may also allow the return of unsold media discs. Generally speaking, content providers use a rental contract (under this contract, distributors only need to pay for the media discs they sell), Provide the media holding the content to the distributor. In addition, unsold media discs are returned to these content providers. In this embodiment, the pre-recorded media disc may or may not always identify a global resource locator (URL) of a distributor or content provider, thereby performing an unlocking action on the content. For example, you want to have a pre-recorded media disc (which is linked to this dealer's Global Resource Locator (URL) to present a wide variety of offers, bonuses, etc.), and you want to keep returns unsold A distributor of media discs can receive media discs with serial numbers and / or timestamps, so that a host server can point the media discs to the distributor's Global Resource Locator (URL). In addition, other distributors may be content with a poster to identify a global resource locator (URL) for unlocking content. In one embodiment of the present invention, the global resource locator (URL) of the main server is always recorded on the media disc by using the original video production process, and is accompanied by a serial number and / or time stamp. . This master server receives instructions from a plurality of content providers and / or authorized distributors to identify the Global Resource Locator (URL) of the distributor associated with the serial number. When a distributor returns one or more media discs to a content provider for re-distribution, the timestamp associated with this serial number can be used to more clearly identify a group of media with the same serial number The disc, or this serial number can also be used to identify these media discs individually. These identified media discs can then be redirected from the distributor's global resource locator (URL) to a second distributor's global resource locator (URL) or to an ordinary global resource locator (URL). In another embodiment of the present invention, each media disc is directed to a main server and re-oriented according to a market share, so as to redirect the access to a distributor global resource locator (URL) The number can be directly proportional to the market share this dealer holds. In block 3160, if the media does not have locked content, or the user chooses to no longer see the various supplies of the media, this interface will determine whether there is an AUTORUN.INF file written on the media. If the user selects the PLAY option, block 3180 executes the PLAY method. This automated execution can result in a Global Resource Locator (URL) connection. Subsequently, a web server can also generate a client-side description language (script) to embed an object or call an entry point based on a client-side object application program interface (API) variable. Moreover, the commands of this object can include: ConnectCKUServer (VARCHARServerIP, UNIT Port, UNIT SessionID, UNIT ContentID, UNIT USBDriverID). In one embodiment of the present invention, ServerIP is a string variable, which is used to describe the global resource locator (URL) connected to this object. Port is the listening port number of the CKU server. SessionID is a unique identifier assigned by this server. This SessionID can associate a Socket connection with this specific website conversation, and it must initiate the action to ensure that the server can synchronize its state. In addition, this SessionID can also be stored as a temporary part of a transaction database The key in (such as: database 2890), as shown in FIG. 28, is used to transmit main bank information between a web server 2850 and the CKU server 2860. In addition, ContentID is an identification code of this side and a disc including content (which is supplied to a consumer). Furthermore, USBDriver is an identification code, so that a CKU client 2896 can locate a particular moment of a disc drive, thereby generating an automatic insertion notification to start an unlocking session. In one embodiment of the present invention, the AUTORUN is transmitted by sending the side content identification code (SCID) and the lock status flag in a query string to a global resource locator (URL), which may use the original video The production process is recorded on this disc, specified by a user, or a preset value, so as to connect to a CKU server 2860. In one embodiment of the present invention, the global resource locator (URL) is connected using "Shell Executing". To this end, the global resource locator (URL) starts a browser on a user system and Connects to server 2860. The global resource locator (URL) can optionally point to a CKU entry, which can be a smart redirector. In addition, the redirector can use, for example, media identification information to determine the web server to which this client will connect. Please refer to FIG. 31B again. Block 3182 is based on this global resource locator (URL), automatic execution (AURUN), or other mechanism for presenting a variety of supplies, thereby presenting a variety of supplies to consumers. Please refer to FIG. 31C, which shows a method for connecting the CKU server 2860. In one embodiment of the invention, this method can utilize a The description language (Script) executed by each client object is called. In addition, block 3114 is used to set a driver for a connected device. Furthermore, block 3124 is used to connect to an engine and retrieve a ContentKey Digital Edition Management (CKDRM) certificate, such as those previously described. In addition, the block 3126 is used, for example, a slot mode group (such as: BSD / WinSocK and SOCKET_STREAM mode group) to connect a CKU server 2860. In addition, block 3128 is used to wait for a confirmation message from the CKU server 2860. Furthermore, block 3134 is used to transmit the ContentKey Digital Edition Management (CKDRM) certificate of the engine to the CKU server 2860. In addition, block 3144 is used to receive the ContentKey Digital Edition Management (CKDRM) certificate of the CKU server 2660. Block 3154 uses CKCMD_AUTHENTICATE to send this server certificate to this engine 2698. Furthermore, block 3164 is used to receive an ESessionKey and send it to the CKU server 2860. Block 3174 is used to receive the unlocked data from this server 2860 and send it to this engine 2898 using CCKMD_UNLOCK_FILES. In addition, block 3184 is used to report the status of the unlock operation to the server 2860. Block 3194 is used to update a list on the media, which is coupled to this engine 2898 to include newly unlocked content. Now refer to Figure 32 and Figure 28. This CKU server 2860 is used to manage many simultaneous connections and unlock transactions, as described previously (for example: Figure 31). Whenever a client requests a connection, the server must accept the connection and continue to execute the 32nd The picture shows this method. As shown in the figure, in block 3202, the CKU server 2860 is used to confirm a client connection. In block 3204, the CKU server 2860 receives the ContentKey Digital Edition Management (CKDRM) certificate and Session ID from an engine received from the client 2896. In block 3206, the ContentKey Digital Edition Management (CKDRM) uses the Session ID as an indicator or key to receive a side content ID (SCID) and a SCID from the transaction database 2890. List the DataPlay File System (DFS) file disposal for unlock operation. In block 3208, the CKU server 2860 is connected to the CkU original video server 2840. In addition, in block 3210, the CKU server 2860 is used to wait for a confirmation message from the CKU original shadow server 2840. At block 3212, the CKU server 2860 sends a server's ContentKey Digital Edition Management (CKDRM) certificate, the engine's ContentKey Digital Edition Management (CKDRM) certificate, media side content identification code (SCID), and DataPlay file System (DFS) files to this original video CKU server 2840. In addition, in block 3214, the CKU server receives these key complements from the original CKU video server 2840. In one embodiment of the present invention, these keys are encrypted using the public keys of the original CKU video server 2840. In addition, in block 3216, the CKU server 2860 is used to confirm the receipt of the original CKU video server 2840. At block 3218, the CKU server 2860 will then disconnect from the CKU original video server 2840. In addition, in block 3220, the CKU server 2860 will copy this The ContentKey Digital Edition Management (CKDRM) certificate of the server is transmitted to this client 2898. In block 3222, the CKU server 2860 receives the ESessionKey by the client 2898, which can use the public key of the CKU server 2860 to perform the decryption action. In block 3224, the CKU server 2860 uses the server's private key to decrypt the session key. In addition, in block 3226, the CKU server 2860 uses, for example, a public key infrastructure (PKI), a server's private key, and a session key information to decrypt the key complement. . In addition, in block 3228, the CKU server 2860 uses, for example, the Advanced Encryption Standard (AES) and / or Triple Data Encryption Standard (Triple_DES) to generate a random key used to re-encrypt the key complement. To provide the ability to unlock. Furthermore, block 3230 is used to enable this CKU server 2860 to, for example, use Advanced Encryption Standard (AES) and / or Triple Data Encryption Standard (Triple-DES) to use this unlock key to pair these The key complement is used for encryption. In addition, in block 3232, the CKU server 2860 uses, for example, a public key infrastructure (PKI) to encrypt the unlocked key with the engine's public key. Furthermore, in block 3234, the CKU server 2860 is used to create a CCKMD_UNLOCK_FILES data block and send it to the client 2896. In block 3236, the CKU server 2860 is a message authentication code (MAC) used to create the data portion of the block. In block 3238, the CKU server 2860 is used to send this data block to the client 2896. Additionally, in block 3240, the CKU The server 2860 is in a state of unlocking by receiving from the client 2896. And, in block 3242, the transaction status is also marked in the transaction database 2890. Finally, in block 3244, the CkU server 2860 will terminate the connection with the client. In an embodiment of the present invention, in block 3245, when a web server 2850 receives an instruction that the unlocking action has been completed by the CKU client 2896, the web server 2850 completes the remaining financial transactions. Please refer to FIG. 33, which is a method performed by the original video server 2840 shown in FIG. 28. Among them, the block 3310 is used to enable the original video server 2840 to accept the connection of the CKU server 2860. In addition, in block 3320, the original video server 2840 is used to confirm the connection action. Subsequently, in block 3330, the original video server 2840 can receive the CKU server 2860's ContentKey Digital Rights Management (CKDRM) certificate, the engine's ContentKey Digital Rights Management (CKDRM) certificate, and the media's Disposal of side content identification code (SCID) and DataPlay file system (DFS). In addition, in block 3334, the original video server 2840 is used, for example, to check the signature authentication code (MAC) and public key infrastructure (PKI) signatures to verify the validity of these two certificates. . Furthermore, in block 3336, the original video server 2840 checks the revocation database 2530 to confirm that there is no participation in the revocation certificate. In block 3340, the original video server 2840 uses the key complement from the key complement database 2810 to retrieve the request. Also, in the box In 3350, the original video server 2840 uses the public keys of the CkU server 2860 to perform encryption operations on these key complements. Also, in block 3360, the original video server 2840 is used to send the encrypted data to the CKU server 2860. In addition, in block 3370, the original video server 2840 retrieves a confirmation message from the CKU server 2860 and terminates the connection with the CKU server 2860. The methods used for the server in Figure 28 are started by a client, such as the CKU client 2896. Please refer to FIG. 34, which is a method for explaining the webpage 2892 and the CKU client server 2896. In block 3410, a client 2896 accesses a formatted global resource locator (URL) (such as a global resource locator (URL) on a media disc, as previously described), Or a global resource locator (URL) associated with a serial number on a media disc or other source to enable this method. Then, in block 3420, the client 2896 presents a query string including the lateral content identification code (SCID) and the locked content status. In addition, in block 3430, the web server 2850 is used to create a webpage, so as to use this supply database 2880 and the user interface component database 2870 to present various supplies to a consumer. After the user chooses to complete in box 3440 and the conditions of this transaction are also met, the web server 2850 will send a "unlocking action" web page to this client. In block 3450, the web server 2850 is used to generate a unique SessionID, which will be used after confirmation of this unlocking process Make this transaction. In block 4354, the webpage 2892 is embedded with a CKU client 2896 object and includes a client's description language (Script) to inform the CKU client 2896 that the unlocking process can be started. In addition, the web server 2850 can also store the side content identification code (SCID) and a tabulated DataPlay file system (DFS) file in box 3454, which uses the conversation ID in the transaction database ( SessionID) for later use by this CKU server object. In addition, the CKU client 2896 can also be an embedded object inside this webpage, which is transmitted to an end user's computer. This object can be developed into an ActiveX control and Netscape Plug-in to support most browser client environments. In addition, these object methods and features can also be accessed through the Java description language (script). This object is to send an object link embedding (OLE) event to this page when the transaction is completed or an error occurs. When the web server receives a connection from a server browser with media information, the web server builds the home page for the presentation. In some examples, these side content identifiers (SCIDs) and lock status flags will be necessary information to determine the brand of this webpage (if the media has already recorded a unique and exclusive to a specific retailer using the original video production program Or promotion ID). In other examples, the user may have to be prompted to enter a code for the packaging label, or to choose the retailer where the disc was purchased. Supply and pricing are retrieved from this supply database and branded Presented to this consumer. The user chooses from these supplies and must meet all the conditions of the transaction. These conditions may require payment information or statistics to be exchanged for unlocking this content. Once all the conditions of the transaction are met, the web server can create a "Unlocking Action" page. This webpage has a CKU client object and a script embedded in it, using objects with the correct parameters as examples. In addition, this website server will also temporarily enter this transaction database, which includes a unique session ID (SessionID), side content identification (SCID), credit card transaction authorization code, and a list of unlocked DataPlay File System (DFS) file disposal. Please refer to FIG. 35, which illustrates a method from a system point of view, which is based on an embodiment of unlocking content. Among them, the block 3510 is used to send a web page to the client. The CKU client object uses these session identifiers (SessionID), side content identifiers (SCID), and the IP of the CKU server: PORT. Address as an example and start it. At block 3512, the CKU client system includes a ContentKey Digital Rights Management (CKDRM) certificate for the engine. At block 3516, the CKU client then establishes a connection to a listening port on the CKU server (for example: a socket connection). In block 3518, the CKU server will accept the incoming connection by the client and use a confirmation message to confirm the connection. In addition, in block 3520, this CKU client will use A connection message is used to transmit the ContentKey digital rights management (CKDRM) certificate of the engine and the session ID (SessionID) to the CKU server. In block 3522, the CKU server responds with a confirmation message or a resend message. Subsequently, at block 3534, the CKU server indexes the unique session ID (SessionID) of the conversation to set a corresponding record in the transaction database. In box 3536, the CKU server can also utilize a slot port to connect to this CKU original video server listening port. In block 3538, the original CKU video server accepts this connection and responds with a confirmation message. In block 3540, the CKU server combines a message packet to request a key and sends it to the original CKU video server. This packet can also include an Engine's ContentKey Digital Rights Management (CKDRM) certificate, the CKU server's ContentKey Digital Rights Management (CKDRM) certificate, the side content identifier (SCID) of the media, and the listing and request key Complementary DataPlay File System (DFS) file disposal. In one embodiment of the present invention, the message sent from the CKU server to the CKU original video server to request the key required to unlock the content is shown in the form of Table 47. In this embodiment, the message shown in Table 47 also includes these engines and ContentKey Digital Rights Management (CKDRM) vouchers, the side content identification code (SCID) of the media including these files, and this list, each DataPlay File System (DFS) disposal of locked files.

Table 47

Byte displacement type field name description 0: 1U16MessageID = 50X0005 CKU_REQ_KEYS2: 3U16MessageLength including the entire byte length of the header 4: 7U32Reserved reserved for future use 8: 247CK_CERTIFICATEServerCertCKU server CK certificate 248: 487CK_CERTIFICATEEngineCert engine 488: 491U32NumHandlesDFS Dispositions 492: nDFS_HANDLEHandleListDFS Disposal Tables

Please refer to Figure 35 again. In block 3542, the original CKU video server responds with a confirmation message or a retransmission packet (if any problems occur). In block 3544, the CKU original video server authenticates or rejects the Engine and the ContentKey Digital Rights Management (CKDRM) certificate of the CKU server. This authentication action includes: using, for example, CerticomTM to confirm digital signatures. In block 3546, the CKU original video server checks whether these certificates exist in this revocation database. If these credentials are invalid or revoked, the original CKU video server will respond with an error message in box 3548. If these credentials are valid, at block 3550, the original CKU video server retrieves the key complement from a connected database and uses, for example, the Public Key Infrastructure (PKI) to For example, a server public key in a server certificate encrypts these key complements. In addition, in block 3552, the original CKU video server is These key complements are sent to the CKU server. Please refer to Table 48. This message sent by the original CKU video server can be an encrypted list, used to request the key complement of the file, as shown in the table. In addition, these key complements can also be encrypted using the public key of this CKU server or another suitable public key.

Table 48

Byte displacement type field name description 0: 1U16MessageID = 60X0006 CKU_KEYS2: 3U16MessageLength = 8 including all byte lengths of the header 4: 7U32Reserved reserved for future use The number of key complements in the 8: 11U32NumKeys table 12: nU160EKeyComplimentList Encrypted Key Complement

In block 3554, the CKU server is used to receive these key complements, confirm receipt of this data by sending a confirmation message, and interrupt the connection to the original CKU video server. When a data mismatch occurs or an error message is received, the CKU server responds with a resend message in block 3556. In block 3558, the CKU server uses an authentication message to transmit its ContentKey Digital Rights Management (CKDRM) certificate to the CKU client. In block 3560, the CKU client is used to respond with a confirmation message or a resend message. In block 3562, the CKU client is used to create an authentication command packet for transmission to the engine through this driver. For this reason, in block 3564, the engine responds with an encrypted session And, in block 3566, the CKU client sends the encrypted session key to the CKU server in a session key message. In block 3568, the CKU server is used to respond to a server confirmation message or a resend message. In block 3570, the CKU server uses a private key to decrypt the conversation key and the complement of these keys. Immediately, the CKU server generates a random key in block 3572, for example: a 128-bit Advanced Encryption Standard (AES) key to re-encrypt the key complement Actions. In addition, a conversation key can be used to encrypt an unlocked key and create an unlocked message. This message may include a complete packet with an unlock message sent to the engine. In one embodiment of the present invention, the command may also request the calculation of the message authentication code (MAC) for the data. In block 3574, the CKU server is used to send an unlocked message to the CKU client. In block 3576, the CKU client is used to respond to a confirmation message or a resend message. In block 3576, the CKU client uses this data to send a command to unlock the file, which is sent to this engine. After receiving the status of the engine, the CKU client can send an error message or an unlocked completion message to the CKU server in block 3578. In block 3580, the CKU server is used to mark the state of the unlock operation in the transaction database and to interrupt the connection with the CKU client. In box 3590, the CKU client is on this page, borrowing Send an event to an event handler to report the status of the transaction to this web page. In block 3592, this page is used to display the transaction status. In the embodiment shown in FIG. 35, there are multiple opportunities for errors. As shown in Table 49, those errors transmitted in a message include the following types.

Table 49

Error code name description 0CKU_ERR_UNKNOWN An unknown or undefined error has occurred 7CKU_ERR_INVALID_MEDIA The media identifier is invalid. 8CKU_ERR_INVALID_HANDLE has an invalid disposition in the DFS file disposition table. Report this bad disposal index in the ContextData field. 9CKU_ERR_SAUTH_FAILED server authentication failed (either the engine or the original CKU video) 10CKU_ERR_UNLOCK_FAILED For some reason, this engine reports a failed unlock. Report this quote in the ContextData field Engine's status code.

In one or more embodiments of the present invention, the data security of the secure electronic content (SEC) system is enhanced with a plurality of identification codes set on the medium. These identification codes can be public, private, or both. As mentioned earlier, these identifiers can be generated during an original film production process or during other subsequent transactions, depending on the system requirements, as shown in Table 50.

Table 50

The location of the access action and the description of the generation are publicly generated by the original video production program and each GUID public identification code structure is used to stamp the original video. Generated in this field. In this field, a statistically unique identifier private identifier structure is generated. Produced by the original movie production program. A statistically unique identifier for each original movie with ContentKey content. This ID is the ID of the pre-recorded content link. Private identification code architecture. Generated in this field. Statistically unique for each independent media with ContentKey content written. This identification code is the private nonvolatile memory of the identification code linked to the content written or field-recorded (non-original video production, non-pre-recorded). Produced by this engine manufacturing process. GUID of each production engine The method of unlocking the content stored on the media (as shown in Figure 35) is to introduce an authentication agreement and implement an unlocking agreement. From an engine point of view, this unlocking agreement includes the method shown in Figure 36. In block 3610, the engine is used to receive a key and a key complement of a key box. This key box can be linked to a written identification code. In block 3620, the engine is used to perform a key box lookup. Then, in block 3630, the keys inside this key box are unlinked and decrypted. Subsequently, at block 3640, the transaction is completed and the key is relinked, encrypted, and locked. Thanks to the methods shown in Figures 35 and 36, these application programming interfaces (APIs) can be protected when transmitting data from a server. Thanks to the authentication actions on both sides of an unlocked transaction, communications can be established using a data dialog key. In one embodiment of the present invention, the data session key is received as a public key infrastructure (PKI) encryption block with a public key. Therefore, this communication channel can perform encryption when transmitting to a host. The host holds a private key and decrypts the data to receive a secret conversation key. The secret dialog key is received by an encryption block (such as an Advanced Encryption Standard (AES) block), which is accompanied by data, which can be a key box. Figure 37 is a flowchart for providing an unlocking transaction according to another embodiment of the present invention. In particular, the flowchart 3700 is started by a program start instruction 3702, which may include: starting a device. Box 3704 is used to allow media (such as a portable disc) to pass through, for example, a universal serial bus (USB) port and plug it into a device connected to a personal computer (PC) . Block 3706 of this process is used to initiate an automated execution process, as previously described. In one embodiment of the present invention, the automatic execution processing is a server which is installed in a disc drive stack to wait for an insertion event, such as an event of inserting a media into a device. Once the automatic execution process is started, the automatic execution process will pass through the file system to receive an auto.inf file with instructions, and then start a "content management device". Block 3708 is about this content management device, which is used to present locked content. In one embodiment of the present invention, the content management device is a presentation layer, so that a user can interact with it to play the content of a media disc. This content management device can dynamically create the contents of a table, using a contents. Ddl file to distinguish locked and unlocked content. For locked content, the content management device can provide the consumer with a link to point a consumer or user to a location that allows unlocking the content. Furthermore, the automatic execution processing 3706 can also detect the shortage of a content management device and perform a reading operation of the contents. Ddl file to set the global resource locator (URL) data. In one embodiment of the present invention, the media may also include multiple supplies (as in a kiosk or download model), and may or may not have multiple global resource locators (URLs) associated with these supplies ). If there are multiple Global Resource Locators (URLs), then this consumer Or the user can continue to choose any one of them. The content management device in block 3710 is used to provide an optional ContentKey Digital Rights Management (CKDRM) entry for those ContentKey Digital Rights Management (CKDRM) content files. In one embodiment of the present invention, a ContentKey Digital Rights Management (CKDRM) requirement only exists when the following situations occur. First, a package collection identifier attached to a global resource locator (URL) refers to a package or a combination thereof, which can be unlocked by at least one e-tailer (e.g., by another An e-tailer (eTailer) unlocks a second music transaction. Second, a software package collection identifier can also be attached to this Global Resource Locator (URL), which is used to point to two or more software packages that can be unlocked by a different e-tailer . In either case, the existence of a selective e-tailer (eTailer) will require a user or consumer to select an e-tailer (eTailer) before continuing the transaction. In addition, block 3712 is used to provide a login action in the ContentKey Digital Rights Management (CKDRM) field. In particular, a login program can also be based on this particular eTailer. Therefore, if a consumer or user does not have an account for the desired eTailer, they can create an account in box 3712 or select a guest to log in based on the eTailer Access and provide valid billing information to authorize transaction processing actions with the required credit card authorization. Wait for a login procedure to complete Block 3714 then provides a software package / pricing presentation to a consumer or other user. The consumer or user can then choose what to unlock or end the process if nothing is selected. A list of package software in block 3714 is used to provide a procedure whereby a consumer can choose one or more package software to be unlocked. In addition, at block 3716, a consumer information questionnaire will be presented to this consumer / user simultaneously when billing or other information is required or required. Furthermore, block 3718 provides, for example, a presentation of the transaction summary based on the data entered in the questionnaire. In addition, block 3729 is used to provide credit card authorization actions, which may or may not be required, depending on the system requirements. For example, a code could allow the content to be unlocked freely in exchange for other compensation, or even no compensation, for this questionnaire 3716. In addition, block 3722 is a digital information exchange server notification used to provide this transaction. In particular, an electronic retailer (eTailer) may be responsible for using a protocol required by a digital intelligence exchange server to communicate and in which an unlocked transaction occurs. In one embodiment of the present invention, an electronic retailer (eTailer) must provide the digital information exchange server with the software package to collect identification codes and a list of software packages that consumers / users want / purchase. In addition, this digital information exchange server can also request a certain level of consumer information. Block 3724 is used to provide the ContentKey Digital Rights Management (CKDRM) activation status to the user or consumer. In addition, block 3726 is It is based on an authentication process to provide an engine and a server conversation. In addition, block 3728 is used to provide a key complement lookup table and transfer action, and write this key complement to this device / disc or other locations that require a key complement to complete the encryption request. Block 3730 is used to provide an update action for the contents. Ddl file. In addition, block 3732 is used to provide a program to complete the ContentKey Digital Rights Management (CKDRM) transaction that unlocks the content. Block 3734 is a transaction provided by an eTailer (such as a group retailing on the Internet) to complete the notification action of completing the transaction. In addition, block 3736 provides an optional congratulations presentation to the user or consumer. Please refer to FIGS. 38 and 39 at the same time. FIG. 38 is a flowchart of a method, which is an embodiment of a program for unlocking content according to the present invention. In addition, in this secure electronic content (SEC) system, object interactions between components are shown in Figure 39. In particular, please refer to FIG. 38. Block 3802 is used to enable this Digital Information Exchange Server (DCS) order management server 2908 to insert a record DCS_STAGE table with or without a media identification code into FIG. 39 The DataPlay (DP) data security database 3914 is shown in INSERT_INTO_DCS_STAGE 3918. In particular, please refer to this DataPlay (DP) data security database 3914, an example of a summary of this database is provided in Tables 51A to 51D below.

Form 51A

<tables><img file="TW583568B_D0012.tif" /></tables>

<tables><img file="TW583568B_D0013.tif" /></tables>

<tables><img file="TW583568B_D0014.tif" /></tables><tables><img file="TW583568B_D0015.tif" /></tables>

<tables><img file="TW583568B_D0016.tif" /></tables>

Please refer to Figure 38 again. Block 3804 is used to enable this Digital Information Exchange Server (DCS) order management server 3908 to generate a web page. Among them, a client server 3904 uses a transaction identification code as a example. The connection 3916 of this brand webpage with the CKU client embedded is shown in the figure. Among them, block 3806 is used to enable the CKU client 3904 to obtain the ContentKey digital rights management (CKDRM) certificate of the engine 3902, as shown in the CKCMD_GET_CERTIFICATE command connection 3920. In addition, block 3806 is used to enable this engine 3902 to transmit a ContentKey Digital Rights Management (CKDRM ) The certificate is given to the CKU client 3904, and the response is completed, as shown in connection 3922 in the figure. In addition, the CKU client 3904 sends the DFSCMD_GET_MEDIA_METADAT command to the engine 3902 to retrieve this unique media identification code. Block 3808 is used to enable the CKU client 3904 to obtain this unique media identification code, as shown by connection 3916 in the figure. In one embodiment of the present invention, if the obtaining action of the unique media identification code cannot be established, the engine 3902 obtains the identification code. After obtaining this unique media identifier, the CKU client 3904 will send a HyperFile Transfer Protocol (HTTP) notice 3928, or a notice based on another protocol (which is suitable for client server communication) to the CKU serverDevice 3906. Based on this notice, the CKU server 3906 will use a GetServerCert program (Servlet) 3930 as an example, which is used to execute a CKU original movie 3910 (in one embodiment of the invention, this function is A Java class original movie) GetServerContentKeyCert () function 3932, and retrieve the requested string. The original CKU movie 3910 applies the GetServerContentKeyCert () function 3932 to the CryptoLibrary 3912 through the connection 3934, and obtains the required certificate from the Crypto Library 3912. In addition, block 3810 is used to enable the CKU client 3904 to obtain the content key certificate of the server 3906. As shown in Figure 39, either a credential or an error will be returned to the CKU source by the Crypto Library 3912 and 3938 and 3936. The version 3910.CKU client 3904 uses the CKCMD_AUTHENTICATE command (ie, server certificate) in the connection 3940 and is transmitted from the client 3904 to the engine 3902 to request a session key (ESessionKey) with the receiving certificate. ). Block 3812 is used to enable the CKU client 3904 to use the ContentKey Digital Rights Management (CKDRM) certificate of the CKU server 3906 to obtain the session key (ESessionKey) from the engine 3902 via connection 3940. . In addition, block 3814 is used to enable the client 3904 to generate an unlock request to authenticate and / or update a form with the media identification code. In one embodiment of the invention, this table is a DCS_STAGE table. Furthermore, block 3814 is used to enable the client 3904 to request the authentication action of the engine 3902, obtain the file disposal / key complement / version list, and wrap the file combination. In addition, the CKU client 3904 uses the connection 3944 to send a Hyper File Transfer Protocol (HTTP) announcement to the CKU server 3906, which includes, for example, a session key (ESessionKey), an engine certificate, Media ID and transaction ID. Those unlocked content programs (servlets) 3946 inside the CKU server 3906 are connected via 3948, using the UnlockContent function (which includes: ESessionKey, engine certificate, media identification code, and transaction identification Code) to issue an unlock request for the original CKU movie 3910. In addition, the original CKU video 3910 is accessed through the 2950 to access this DataPlay (DP) data security database 3914, and will A P_KEY command (which includes: transaction identification code, media identification code, password, and ResultSet output) is transmitted. The DataPlay (DP) data security database 3914 responds to a ResultSet (File Disposition-Key-Version) or an error by connecting 3952. In addition, the original CKU video can also be connected to the Crypto Library 3912 through WrapFileSet functions (which include: ESessionKey, engine certificate, file combination string, key count, media identification code). The connection 3954 is required to cover this portfolio of files. In addition, block 3816 is used to enable the CKU client 3904 to send the wrapper file to the engine 3902, so that the engine 3902 can perform an unlocking action on the content. In particular, the Crypto Library 3912 is connected to the original CKU video 3910 3960 to send the package file combination or an error message. The original CKU video 3910 uses the connection 3958 to transmit the transmission content to the CKU server 3906, and then uses the connection 3960 to transmit from the CKU server 3906 to the CKU client 3904. In addition, the CKU client 3904 uses this package file combination to send a CCKMD_UNLOCK_FILES command to the engine 3902 via the connection 3962. Then, the engine 3902 will use the connection 3964 to send a success message, authentication success message or failure message to the CKU client 3904. Block 3818 is used to enable the CKU client 3904 to send a final transaction status message to the CKU server 3906, and to a consumer / user The user is shown with a transaction completion message ("Transfer completed"). In particular, the CKU client 3904 will also send a Hyper File Transfer Protocol (HTTP) announcement to the CKU server 3906, which includes: a transaction identifier and a status message 3966. Block 3820 is used to enable the Digital Information Exchange Server (DCS) order management server 3908 to receive this status completion notification, and delete and update the DCS_STAGE record for that transaction. The UpdateStatus program (Servlet) 3968 uses the connection 3970 to send the UpdateStatus function (which includes: transaction ID and status information) to the Digital Information Exchange Server (DCS) order management server 3908, in response to this announcement 3966. In addition, the UpdateStatus program (Servlet) 3968 uses a function 3972 (including transaction ID and status information) to update the SQL syntax to connect with the DataPlay (DP) data security database 3914. Now read both Figures 40 and 41, where Figure 40 is a flowchart to illustrate an unlocked transaction according to an embodiment of the present invention, and Figure 41 is in this secure electronic content (SEC) A block diagram of the interaction between objects in the system. Among them, block 4002 is used to receive media including locked content (for example, a disc placed in a player or device (which is coupled to a personal computer)), which is respectively coupled to a Engine 4102. Block 4004 is used to enable automated processing 4104 (or a content management device) to request a Contents.ddl file. Please refer to Figure 41. This request is to use the engine 4102 to send a signal to the auto-execution of the magnetic insertion event. (This is shown as connection 4114). Subsequently, the auto-execute process 4104 sends a DFSCMD_GET_FILES command to the engine 4102. The engine 4102 responds by sending a contents. Ddl file, as shown in 4118. In addition, block 4006 is used to enable the automated processing 4104 (or content management device) to scan the contents. Ddl file to obtain one or more identification codes, which include: Package collection ID (PackageCollectionID), Package software collection inventory unit (PackageCollectionSKU), unlocked global resource locator (UnlockURL), main package software inventory unit (PackageSKU) list and business entity identifier, and a previously unlocked package software inventory unit (PackageSKU). In addition, the automatic execution processing 4104 also includes an internal logic circuit 4120, so that the operation can be performed after the contents.ddl file is returned. In addition, block 4008 is used to enable this automated processing 4104 or a content management device to attach data to a global resource locator (URL) and open a default browser to display an eTailer site. Generated a web page. This e-tailer (eTailer) was chosen based on an embodiment described previously. In addition, the block 4010 is used to enable the eTailer 4106 to present a sequence of web pages to the user / consumer for processing an e-commerce transaction. A user / consumer interacts via the e-tailer 4106's "shopping cart" web page 4122. In addition, the block 4012 is used to illustrate: After a user / consumer, for example, pushes a button and prompts the eTailer 4106 to complete the transaction, the eTailer 4106 is then requested upon completion Notify the Digital Information Exchange Server (DCS) of the results of this ContentKey unlock transaction. An e-tailer (eTailer) sends this PCID to this Digital Information Exchange Server (DCS) and lists a software package inventory unit list to be unlocked, as shown in HTTP Bulletin 4124 (PCID, package software list). Via the electronic retailer (eTailer) 4106 to the digital information exchange server (DCS) order management server 4108. In addition, block 4014 is used to enable this Digital Information Exchange Server (DCS) order management component to generate a unique transaction identification number and insert a record for each software package purchased. The command 4126 (transaction identification code, PCID, software package identification code) inserted into the SQL syntax is transmitted by the digital information exchange server (DCS) order management server 4108 to the digital information exchange server (DCS) order management data. Library 4110. At this time, the media identifier is unknown, so it will include a NULL value. In addition, the block 4016 is used to explain: The digital information exchange server (DCS) order management server 4108 responds to the e-tailer 4106 with a failure message or a global resource locator (URL) 4128. . A user / consumer can then use this global resource locator (URL) to unlock the content. The unlocked Global Resource Locator (URL) includes this A transaction identification code is generated by the digital information exchange server (DCS) order management server 4108. In addition, the block 4018 is used to explain that the e-tailer 4106 is used to generate a final confirmation message and perform an unlocking operation on a designated webpage including the unlocked global resource locator (URL) 4130.

Other embodiments

Those skilled in the art should understand that the embodiments mentioned in the specification can be implemented by software program instructions, which can be distributed in one or more program products in various forms (including: generated by computer programs). In addition, the present invention can also be applied to other embodiments without being limited to a specific type of program storage medium or signal bearing medium that implements the above-mentioned distribution behavior. Examples of program storage media and signal bearing media include: recordable media (such as: floppy disks, CD-ROMs), and tape transmission media (such as digital and analog communication links), and other media storage and Dispersion system. In addition, the previous detailed description uses block diagrams, flowcharts, and / or examples to present various embodiments of the present invention. Those skilled in the art should understand that the various block diagram components, flowchart steps, and the operations and / or components introduced are examples of these embodiments, which can be used in a wider range (such as hardware, software , Firmware, or any combination thereof), individually or collectively. In addition, those who are fully or partially familiar with the following fields (including: standard integrated circuit, special application integrated circuit (ASIC)) should understand that after the disclosure of the present invention, the present invention can be implemented as a A computer program, firmware, or any combination thereof running on a general-purpose machine such as one or more computers, and the software and firmware circuits and / or programming should also be written by a person skilled in the art To understanding. Although the present invention has been shown and described through specific embodiments, those skilled in the art should be able to make various adjustments and changes to the present invention based on the teachings of the specification without departing from the scope and characteristics of the present invention. Therefore, the following patent application scope is intended to include the scope of the present invention (including its adjustments and changes), and these adjustments and changes should also be regarded as the scope of the present invention.

<p>Figure 1</p><p>ContentKey Lock access restrictions a ContentKey Lock</p><p>100. . .a content storage model</p><p>120. . .a Utilizes only unmanaged content of the DataPlay File System (DFS)</p><p>130. . .a Non-ContentKey Digital Rights Management (DRM) management content</p><p>180. . .a Use only DataPlay File System (DFS) to manage content</p><p>182. . .a DataPlay File System (DFS) and ContentKey Metadata Application Programming Interface</p><p>184. . .a ContentKey metadata and digital rights management (DRM) playback application program interface</p><p>140. . .a Manage content using both ContentKey and another Digital Rights Management (DRM)</p><p>150. . .a ContentKey application interface</p><p>150. . .a ContentKey manages content</p><p>160. . .a DataPlay File System (DFS) access action</p><p>170. . .a ContentKey access action</p><p>Figure 2</p><p>202. . .a content provider</p><p>204. . .a Replicator</p><p>206. . .a server</p><p>207. . .a kiosk</p><p>208 (1), 208 (2), 208 (3). . .a engine</p><p>209 (1), 209 (2), 209 (3). . .a media</p><p>210. . .a Connect the host</p><p>ContentKey Digital Rights Management</p><p>211. . .a Built-in device</p><p>ContentKey Digital Rights Management</p><p>Figure 3</p><p>302. . .a Content provider determines the level of data preservation</p><p>304. . .a Tools and procedures for generating pre-recorded content</p><p>306. . .a Including media used and licensed by the content provider</p><p>308. . .a engine</p><p>309. . .a Application Programming Interface</p><p>310. . .a player</p><p>312. . .a Digital Rights Management</p><p>316. . .a Credential Host</p><p>318. . .a certificate</p><p>320. . .a Credential Management Center</p><p>Format encoding encryption layers. . .a format encoding encryption layer</p><p>Figure 4</p><p>306. . .a media</p><p>308. . .a engine</p><p>310. . .a host</p><p>402. . .a Application layer</p><p>404. . .a dialogue layer</p><p>406. . .a Command data layer</p><p>408. . .a data link layer</p><p>410. . .a physical layer</p><p>412. . .a undocumented</p><p>413. . .a certificate</p><p>414. . .a unsafe</p><p>416 (1), 416 (2). . .a safety</p><p>418 (1), 418 (2). . .a Encryption-Decryption</p><p>420 (1), 420 (2). . .a file system</p><p>430 (1), 430 (2). . .a ContentKey Digital Rights Management</p><p>422 (1), 422 (2). . .a Agreement interface</p><p>424 (1), 424 (2). . .a Physical interface</p><p>450. . .a Block management device</p><p>452. . .a Servo positioning action</p><p>454. . .a Read / write action</p><p>460. . .a Optical element</p><p>470. . .a File system (FS) file data</p><p>472. . .a File System (FS) Metadata</p><p>470. . .a ContentKey metadata</p><p>Figure 5A</p><p>502. . .a file</p><p>504. . .a Metadata</p><p>506. . .a Open Application Programming Interface</p><p>508. . .a Security Application Programming Interface</p><p>510. . .a Security Metadata</p><p>512. . .a Thorough file read / write access</p><p>514. . .a Specify the certificate for the security application</p><p>516. . .a application</p><p>518. . .a Abolition method</p><p>Figure 5B</p><p>530. . .a Data access via firmware</p><p>532. . .a Avoid data access from outside the firmware</p><p>Figure 5C</p><p>550. . .a Host receives credentials (514)</p><p>552. . .a Right to attach content to the media</p><p>554. . .a agree to access action under predetermined conditions</p><p>556. . .a Perform one or more of the following actions, including: identifying a channel; checking a revocation list; and unlocking content</p><p>Figure 7</p><p>602. . .a media</p><p>604. . .a engine</p><p>606. . .a host</p><p>608. . .a Repeal of listings</p><p>610. . .a ContentKey certificate with an agreement public key signed by the DataPlay Certificate Management Center (CA)</p><p>612. . .a Agreement private key</p><p>626. . .a Private key decryption</p><p>628. . .a Secure conversation key</p><p>612. . .a Confirmation of signature</p><p>614. . .a Certified Host</p><p>616. . .a passed?</p><p>618. . .a Random Number Generator</p><p>620. . .a Secure conversation key</p><p>622. . .a Public Key Encryption</p><p>624. . .a Agreement Public Key</p><p>Figure 7A</p><p>308. . .a engine</p><p>318. . .a certificate</p><p>710. . .a identification code</p><p>720. . .a Confirm action</p><p>730. . .a authentication engine</p><p>750. . .a Permission block determines multiple pass / fail permissions</p><p>780. . .a conversation key</p><p>pass. . .a through</p><p>global pass / fail. . .a Global Channel / Failure</p><p>Figure 7B</p><p>702. . .a receipt by destination</p><p>704. . .a Use identification codes to authenticate destinations</p><p>706. . .a Transfer session key</p><p>Figure 7C</p><p>712. . .a Perform abolished list evaluation during file access</p><p>714. . .a Storing the results of each node during file access and revocation of data evaluation</p><p>716. . .a Copy the repeal list to the engine by the media. The repeal list can have "poison" to avoid the player's action if the player is not a proper player, or the manufacturer has a defect or potential defect, or the like in the case of</p><p>718. . .a When the player connects to the server to unlock the content, update the revocation list</p><p>722. . .a The revocation action of one or more signature keys is to rescind a set of ContentKey Digital Rights Management (CKDRM) certificates signed with one or more keys</p><p>724. . .a The revocation action is to repeal one or more of the following fields, including: single device identification code or agreement public key, overall company, specific product line, specific product model</p><p>Figure 7D</p><p>732. . .a When evaluating the content of the ContentKey Digital Rights Management (CKDRM) voucher, evaluate the data in the quantum sentence node according to the true and false function structure</p><p>734. . .a Combine the results of clause nodes according to clause rules</p><p>736. . .a If any revocation node in the revocation list is evaluated as true, the revocation host</p><p>Figure 7E</p><p>752. . .a During ContentKey Digital Rights Management (CKDRM) metadata setup, use node count values to generate sufficient memory space</p><p>754. . .a For each node in the repeal table, compare this node with the existing Save and retire each node in the list</p><p>756. . .a If the same node is found, add the number of DataPlay file system identifiers of the existing node to the revocation list in the ContentKey Digital Rights Management (CKDRM) metadata structure</p><p>758. . .a If no node is found, generate a new node with a unique DataPlay file system identifier</p><p>762. . .a The engine adds the new DataPlay file system identifier value to the ContentKey Digital Rights Management (CKDRM) metadata structure</p><p>Figure 7F</p><p>772. . .a Each time the CKCMD_AUTHENTICATE command occurs, or when new media is inserted into the engine, the evaluation of the revocation list</p><p>774. . .a Abolish the list against the receipt of the ContentKey Digital Rights Management (CKDRM) voucher</p><p>776. . .a The abolition or non-abolition status of the node obtained by the evaluation action</p><p>778. . .a Evaluation results are stored in the field of abolished node structure</p><p>Figure 7G</p><p>782. . .a Organize content on the media with a scheduled application</p><p>784. . .a Generate public identification code and ContentKey digital rights management (CKDRM) identification code</p><p>786. . .a Encrypted Content File</p><p>788. . .a Add engine management content and playback rules, as specified by the content owner</p><p>792. . .a Add third party digital rights management (TPDRM) specific rules, as specified by the content owner</p><p>794. . .a Join the list of valid signature keys and repeal the list</p><p>Figure 7H</p><p>7002. . .a Program starts</p><p>7004. . .a New content provider release procedure "Asset and Information Procurement"</p><p>7006. . .a Content file (encoding)</p><p>Metadata information</p><p>Safety Information</p><p>Software collection information</p><p>7008. . .a DataPlay or third party writer "write"</p><p>7010. . .a DataPlay Mass Memory File (MMF) Directory Structure DataPlay Mass Memory File (MMF) Data Description Language (DDL) File</p><p>Safety Information</p><p>7012. . .a DataPlay pre-recording program "Pre-Record"</p><p>7014. . .a keycomplement. ddl</p><p>7016. . .a content. ddl</p><p>7018. . .a DataPlay Media Side-Original Video Production Archives on a Tape</p><p>7020. . .a DataPlay ContentKey original video production server key complement setting procedure "Digital Information Exchange Server Setting"</p><p>7022. . .a DataPlay Glass original film and stamping program "Made"</p><p>7024. . .a DataPlay Security Database-Key Complement Form</p><p>7026. . .a DataPlay Media</p><p>Figure 7I</p><p>7028. . .a Program starts</p><p>7030. . .a Content provider package software setting and changing procedure "package software definition"</p><p>7032. . .a Software package displays graphics and information</p><p>7034. . .a content. ddl</p><p>7036. . .a Retailer (eTailer) package software and pricing setting and change procedure "Pricing Definition"</p><p>7038. . .a Retailer (eTailer) Security Database-Package, Pricing and Package Presentation Form</p><p>Figure 8</p><p>810. . .a Host authentication</p><p>804. . .a Host sends credentials to authenticate host</p><p>806. . .a Engine sends conversation key</p><p>830. . .a Engine selects playback session key</p><p>832. . .a Host receives encrypted playback session key</p><p>834. . .a The host uses the session key to decrypt the playback session key</p><p>840. . .a Host receives encrypted content</p><p>850. . .a The host uses the playback session key to decrypt the content</p><p>Figure 9</p><p>910. . .a Destination engine begins authentication</p><p>920. . .a Destination engine transmits media identifier</p><p>930. . .a Keybox to send this destination</p><p>940. . .a Deliver encrypted content for this destination</p><p>Figure 10</p><p>1010. . .a Identification host</p><p>1020. . .a Enable third-party digital rights management (TPDRM) to specify what third-party digital rights management (TPDRM) requires to receive</p><p>1030. . .a The engine responds to a valid request by sending a key</p><p>1040. . .a Third Party Digital Rights Management (TPDRM) receives the content, which is encrypted using the key just sent</p><p>Figure 11</p><p>1110. . .a Identify the source (Third Party Digital Rights Management (TPDRM), player, server, or kiosk)</p><p>1120. . .a The source decides whether to apply the file system write protocol or the ContentKey Digital Rights Management (CKDRM) record protocol to the content to be recorded</p><p>1130. . .a According to the ContentKey Digital Rights Management (CKDRM) agreement, the part of the file format that is to be encrypted and the ContentKey Digital Rights Management (CKDRM) recording application program interface (API) is used to play the part</p><p>1140. . .a Using the file system application programming interface (API), write the part that you want to keep as unencrypted</p><p>Figure 12</p><p>1210. . .a Interactive source identification procedure</p><p>1220. . .a Media ID of the source extraction content link</p><p>1230. . .a Source specifies the content to be unlocked and the complement of the encryption key</p><p>1240. . .a Destination (such as engine) manages the validity of the request through the server according to the specifications of the content provider</p><p>Figure 13</p><p>1320. . .a Transfer of the same session key using asymmetric encryption</p><p>1340. . .a Does the host change fail security checks or does the media eject?</p><p>TRUE. . .a is</p><p>FALSE. . .a no</p><p>1350. . .a end</p><p>1360. . .a continue</p><p>Figure 14</p><p>1410. . .a Source Engine</p><p>1450. . .a key box</p><p>1420. . .a Licensed source files</p><p>1440. . .a destination</p><p>1430. . .a copy</p><p>Figure 15</p><p>1510. . .a Host application decides which files to import</p><p>1520. . .a The host application determines the attributes of the file to be generated</p><p>1540. . .a Host application decides DataPlay file system (DFS) disposal of destination directory</p><p>1560. . .a Host issues CCKMD_AUTHENTICATE</p><p>1570. . .a The engine returns a full secure conversation key</p><p>1580. . .a Host issues CCKMD_GET_CERTIFICATE</p><p>1590. . .a Host confirms the engine and retrieves the public key</p><p>1592. . .a Host generates destination file</p><p>1594. . .a Host issues DFSCMD_GETHANDLE to retrieve the disposal of new files</p><p>1596. . .a Host Setting Properties</p><p>1598. . .a Host writes content to file</p><p>1599. . .a Host sends files during data transfer</p><p>Figure 16</p><p>1610. . .a Host player self-authenticates the engine</p><p>1620. . .a Host transmits ContentKey digital rights management in command packet</p><p>(CKDRM) Voucher</p><p>1630. . .a engine responds with a conversation key</p><p>1640. . .a Check playback permission</p><p>1650. . .a Use the playback conversation key to establish a playback conversation</p><p>1660. . .a engine returns content</p><p>Figure 17</p><p>1710. . .a Player decides which file to play</p><p>1720. . .a Engine and host authentication to initiate a secure conversation</p><p>1740. . .a Engine returns the conversation key</p><p>1750. . .a Establish a playback conversation</p><p>1760. . .a Engine returns playback session key</p><p>1770. . .a Retrieve content</p><p>1780. . .a engine returns content</p><p>Figure 18</p><p>1860. . .a Host specifies the file to be unlocked</p><p>1862. . .a The host obtains the disposal of the locked file</p><p>1864. . .a Host application self-authenticates the engine and sets the certificate as the ContentKey digital rights management for the clearinghouse server (CKDRM) Voucher</p><p>1866. . .a Engine returns server session key</p><p>1868. . .a Host authentication engine</p><p>1870. . .a Host confirms the engine and retrieves the public key</p><p>1872. . .a The host issues a command to unlock the file</p><p>1874. . .a The engine adjusts the lock attribute of the file</p><p>1876. . .a Host application checks the success of the transaction</p><p>Figure 19</p><p>1910. . .a Third Party Digital Rights Management (TPDRM) self-authenticates the engine</p><p>1920. . .a Host sends third party digital rights management (TPDRM) credentials</p><p>1930. . .a engine responds with a conversation key</p><p>1940. . .a Third Party Digital Rights Management (TPDRM) Retrieval of Security Metadata</p><p>1950. . .a The engine returns the key to decrypt the metadata and encrypt the metadata</p><p>1960. . .a Third Party Digital Rights Management (TPDRM) checks the license and returns the file's playback dialogue key and revocation list</p><p>1970. . .a Decrement file value</p><p>1980. . .a Engine returns file content</p><p>Figure 20</p><p>2010. . .a User inserts source media into the engine</p><p>2020. . .a The host issues a CCKMD_AUTHENTICATE command to initiate a secure conversation</p><p>2030. . .a Engine returns secure session key</p><p>2040. . .a Host issues CKCMD_GET_METADATA command to retrieve files Third Party Digital Rights Management (TPDRM) Security Metadata</p><p>2050. . .a Engine returns metadata</p><p>2060. . .a The host issues a CKCMD_GET_DRM_COPY command to establish a playback session</p><p>2070. . .a The engine returns the dialogue key and cancels the list</p><p>2080. . .a Host retrieves the corresponding content</p><p>2090. . .a engine returns the corresponding content</p><p>Figure 21</p><p>2110. . .a Host decides the file related to the metadata to be read</p><p>2120. . .a User inserts source media into the engine</p><p>2130. . .a The host issues CCKMD_AUTHENTICATE to start a secure conversation</p><p>2140. . .a Engine returns the conversation key</p><p>2150. . .a The host issues a command to retrieve the security metadata of the file in the host</p><p>2160. . .a Engine returns metadata</p><p>Figure 22A</p><p>2210. . .a The host decides to have a file to write metadata</p><p>2220. . .a User inserts destination media into the engine</p><p>2230. . .a The host issues CCKMD_AUTHENTICATE to start a secure conversation</p><p>2240. . .a Engine returns secure conversation</p><p>2250. . .a The host authenticates the engine</p><p>2260. . .a Host confirms the engine and retrieves the public key</p><p>2270. . .a Host sends security metadata for files</p><p>Figure 22B</p><p>2202. . .a Perform a key box lookup</p><p>2204. . .a Key box for retrieving files</p><p>2206. . .a The engine determines whether the media ID is written or pre-recorded</p><p>2208. . .a Comparison of Key Box Linking Identifier Flag and Key Box Method</p><p>2212. . .a Abolition of some or all functions of the order</p><p>Figure 23A</p><p>2398. . .a Device connected to a personal computer (PC)</p><p>2302. . .a media</p><p>2304. . .a device</p><p>2306. . .a engine</p><p>2308. . .a Universal Serial Bus (USB) Port</p><p>2312. . .a Universal Serial Bus (USB) driver</p><p>2314. . .a Installable file system</p><p>2316. . .a Secure Access Channel (SAC)</p><p>2318. . .a web browser</p><p>2322. . .a CKU client</p><p>2324. . .a Dynamic webpage generated by eTailer</p><p>2326. . .a Content Management Device</p><p>2328. . .a Automated Disposal</p><p>2332. . .a Hyper File Transfer Protocol (HTTP)</p><p>2334. . .a Secure Access Channel (SAC) over Hyper File Transfer Protocol (HTTP)</p><p>2396. . .a eTailer Online Store Store</p><p>2354. . .a Application Server</p><p>2336. . .a Hyper Document Markup Language (HTML) and Graphical User Interface (GUI) generator</p><p>2338. . .a Software package display and pricing</p><p>2344. . .a Consumer Management</p><p>2346. . .a Dialogue management</p><p>2348. . .a Credit card authorization</p><p>2342. . .a Digital Information Exchange Server (DCS) interface</p><p>2342. . .a Database connection layer</p><p>2356. . .a database</p><p>2358. . .a Consumer database</p><p>2352. . .a Software package and pricing database</p><p>2364. . .a Dialogue and transaction database</p><p>2360. . .a Hyper File Transfer Protocol (HTTP)</p><p>2394. . .a Digital Information Exchange Server (DCS)</p><p>2366. . .a CKU server</p><p>2368. . .a CKU Original Video Production Server</p><p>2370. . .a Key complement database</p><p>2372. . .a Transaction database</p><p>2374. . .a ContentKey server</p><p>2378. . .a Protocol or application programming interface (API)</p><p>2380. . .a Software package for key mapping database</p><p>2376. . .a integration object</p><p>2399. . .a Information exchange server</p><p>2382. . .a eTailer interface</p><p>2384. . .a Digital Information Exchange Service</p><p>2386. . .a Software package database</p><p>2388. . .a Consumer and e-tailer database</p><p>2390. . .a Consumer database</p><p>2392. . .a Dialogue and transaction database</p><p>Figure 23B</p><p>2310. . .a Write content to the media</p><p>2320. . .a Include secondary content?</p><p>2330. . .a Include keys on locked content media</p><p>2340. . .a Collect and add key complements, data, and supplies to the database</p><p>2350. . .a Distribute unlocked content to the media</p><p>Figure 24</p><p>2402. . .a Program start</p><p>2404. . .a Content provider opens a new version of the program "asset and information procurement"</p><p>2406. . .a Content files (encoded), metadata information, data security information, packaged software collection information</p><p>2408. . .a DataPlay or third party writer "write"</p><p>2410. . .a DataPlay Mass Memory File (MMF) directory structure, DataPlay Mass Memory File (MMF) Data Description Language (DDL) file, security information</p><p>2412. . .a DataPlay pre-recording program "Pre-Record"</p><p>2414. . .a KeyComponent. ddl</p><p>2416. . .a Contents. ddl</p><p>2418. . .a DataPlay media side-original video production file settings on tape</p><p>2420. . .a DataPlay ContentKey original video production server key complement setting procedure "Digital Information Exchange Server Setting"</p><p>2422. . .a DataPlay glass original film production and stamping program "Make"</p><p>2424. . .a DataPlay Security Database-Key Complement-Form</p><p>2426. . .a DataPlay Media</p><p>Figure 25</p><p>2502. . .a Program start</p><p>2504. . .a Content provider package software setting and changing procedure "package software definition"</p><p>2506. . .a Software package displays graphics and information</p><p>2508. . .a Contents. ddl</p><p>2510. . .a Electronic retailer (eTailer) software package and pricing setting and change procedure "Pricing Definition"</p><p>2512. . .a eTailer security database package software, pricing, and package presentation form</p><p>Figure 26</p><p>2610. . .a Presentation to consumers with unlocked supplies</p><p>2620. . .a Receive a satisfactory unlock condition</p><p>2630. . .a Send the key complement to the engine</p><p>2640. . .a The engine responded by changing to an unlocked state</p><p>Figure 27</p><p>Figure 28</p><p>2810. . .a Key complement database</p><p>2820. . .a Transaction database</p><p>2830. . .a Suppression of tabular databases</p><p>2840. . .a CKU Original Video Production Server</p><p>2850. . .a web server</p><p>2860. . .a CKU server</p><p>2870. . .a and the same user interface component database</p><p>2880. . .a Supply database</p><p>2890. . .a Transaction database</p><p>2896. . .a CKU client</p><p>2892. . .a web page</p><p>2898. . .a DataPlay engine</p><p>2894. . .a DataPlay host device</p><p>Figure 29</p><p>2910. . .a Record label / retail brand website</p><p>2920. . .a supply</p><p>2930. . .a transaction</p><p>2940. . .a Unlock</p><p>2950. . .a personal computer</p><p>2952. . .a DataPlay engine</p><p>2960. . .a Clearinghouse web server</p><p>2970. . .a Secure ContentKey Server (DataPlay)</p><p>2980. . .a Credential Management Center (LMI)</p><p>2972. . .a DataPlay Security Key Database</p><p>2980. . .a Transaction database</p><p>2970. . .a Supply database</p><p>Figure 30</p><p>3010. . .a DataPlay disc</p><p>side A. . .a A side</p><p>side B. . .a B side</p><p>3020. . .a main content</p><p>Newest Album. . .a Latest Album</p><p>3030. . .a secondary content</p><p>earlier release. . .a earlier version</p><p>bonus interview. . .a bonus view</p><p>video. . .a video</p><p>tertiary content. . .a Third content</p><p>downloaded release. . .a Download Version</p><p>Figure 31A</p><p>3110. . .a Major transaction</p><p>Primary content. . .a main content</p><p>Newest Album. . .a Latest Album</p><p>Side A. . .a side A</p><p>Side B. . .a B side</p><p>Secondary content. . .a secondary content</p><p>Earlier release. . .a earlier version</p><p>Bonus interview. . .a bonus view</p><p>Video. . .a video</p><p>3140. . .a secondary transaction</p><p>3150. . .a Security Clearing House</p><p>3151. . .a Consumer unlocked content</p><p>Figure 31B</p><p>3122. . .a Interface decides if there is locked content available to consumers?</p><p>3132. . .a Has the user previously requested to no longer see the various supplies of this media</p><p>3133. . .a end</p><p>3142. . .a Interface determines the side content identifier (SCID) and lock status flag of the media</p><p>3152. . .a According to a ContentKey Digital Rights Management (CKDRM) compatible unlocked server address and associated server address (which may be recorded on the media using the original video production process) to connect to a Global Resource Locator (URL) , And send data to the server (such as by querying a string in the global resource locator (URL) or linking the global resource locator (URL) with the associated serial number)</p><p>3160. . .a Does the media not have lock-in content or a request to deny supply?</p><p>3180. . .a Perform the PLAY method</p><p>3182. . .a Presentation of various supplies</p><p>Figure 31C</p><p>3114. . .a Set the driver for the connected device</p><p>3124. . .a Connect the engine and retrieve the ContentKey Digital Edition Management (CKDRM) certificate</p><p>3126. . .a Use, for example, slot mode groups (such as: BSD / WinSock and SOCKET_STREAM mode groups) to connect to the CKU server</p><p>3128. . .a Waiting for confirmation from the CKU server</p><p>3134. . .a Send the ContentKey Digital Edition Management (CKDRM) certificate of the engine to the CKU server</p><p>3144. . .a Receive ContentKey Digital Edition Management (CKDRM) certificate from CKU server</p><p>3154. . .a Use CKCMD_AUTHENTICATE to send server credentials to the engine</p><p>3164. . .a Extract the ESessionKey and send it to the CKU server</p><p>3174. . .a Retrieve the unlocked content by the server and use CCKMD</p><p>UNLOCK_FILES passes it to the engine</p><p>3184. . .a Report the status of the unlock operation to the server</p><p>3194. . .a Update the playlist column on the media, which is coupled to the engine to include newly unlocked content</p><p>Picture 32</p><p>3202. . .a CKU server confirms client connection</p><p>3204. . .a CKU server receives the ContentKey Digital Rights Management (CKDRM) certificate and Session ID of an engine from the client</p><p>3206. . .a ContentKey Digital Rights Management (CKDRM) uses the conversation ID as an index or key, the transaction database receives the side content ID (SCID), and the DataPlay file system (DFS) file disposal for unlocking</p><p>3208. . .a CKU server connected to the original CKU video server</p><p>3210. . .a CKU server waits for connection confirmation from the original CKU video server</p><p>3212. . .a Content Key Digital Rights Management of CKU Server Delivery Server (CKDRM) voucher, Engine's ContentKey Digital Rights Management (CKDRM) voucher, media side content identification (SCID), and DataPlay file system (DFS) files are processed to the original video CKU server</p><p>3214. . .a The CKU server receives the key complement from the original CKU video server. In one embodiment of the present invention, the key is an encryption operation using a public key of the server.</p><p>3216. . .a CKU server confirms receipt of the original CKU video server</p><p>3218. . .a CKU server disconnected from the original CKU video server</p><p>3220. . .a CKU server sends the server's ContentKey Digital Rights Management (CKDRM) certificate to the client</p><p>3222. . .a The CKU server receives the ESessionKey from the client. It can use the public key of the CKU server to perform encryption operations.</p><p>3224. . .a CKU server uses the private key to decrypt the conversation key</p><p>3226. . .a CKU server decrypts the key complement</p><p>3228. . .a CKU server generates random keys to be used to re-encrypt key complements to provide unlocking capabilities</p><p>3230. . .a Enable the CKU server to use the unlock key to encrypt the key complement</p><p>3232. . .a CKU server uses the engine's public key to encrypt the unlocked key</p><p>3234. . .a CKU server creates CKCMD_UNLOCK_FILES data and sends it to the client</p><p>3236. . .a CKU server creates a message authentication code (MAC) in the data part</p><p>3238. . .a CKU server sends data to the client</p><p>3240. . .a CKU server receives unlocked content by client</p><p>3242. . .a Mark transaction status in transaction database</p><p>3244. . .a CKU server disconnected from the client</p><p>3245. . .a After the CKU client receives the instructions to complete the unlocking, the financial transaction is completed on the web server</p><p>Figure 33</p><p>3310. . .a The original video server accepts the connection from the CKU server</p><p>3320. . .a The original video server confirms this connection</p><p>3330. . .a The original video server receives the ContentKey Digital Rights Management (CKDRM) certificate of the CKU server, the ContentKey Digital Rights Management (CKDRM) certificate of the engine, the side content identification code (SCID) of the media, and the DataPlay file system ( DFS) file disposal</p><p>3334. . .a The original video server uses, for example, a check of the message authentication code (MAC) and public key infrastructure (PKI) signatures to verify the validity of these two certificates</p><p>3336. . .a The original video server checks the revocation database to confirm that no revocation certificate is pending</p><p>3340. . .a The original video server retrieves the requested key complement from the key complement database</p><p>3350. . .a The original video server uses the CKU server public key to encrypt the key complement</p><p>3360. . .a Original video server sends encrypted data to CKU server</p><p>3370. . .a The original video server received a confirmation message from the CKU server, and Disconnect from the CKU server</p><p>Figure 34</p><p>3410. . .a Client access to format global resource locators (URLs), such as global resource locators (URLs) on media discs or global resource locators (URLs) associated with serial numbers on media discs or other sources</p><p>3420. . .a The client presents a query string that includes a side content identification code (SCID) and the status of the content being released</p><p>3430. . .a Web server uses a database of supplies and user interface components to build web pages to present a wide variety of supplies to consumers</p><p>3440. . .a Web server sends "Unlocking action" page to client</p><p>3450. . .a Web server generates a unique SessionID, which can be used to execute transactions after confirming the unlock process</p><p>3454. . .a The CKU client object is embedded in the webpage and includes a client description language (script) to notify the CKU client to start the unlocking action</p><p>3456. . .a The web server stores these side content identification codes (SCID) and the listed DataPlay file system (DFS) files for disposal. It uses the session ID in the transaction database for indexing, which is subsequently used by the CKU server Object</p><p>Figure 35</p><p>3510. . .a Send a web page to the client, the CKU client is based on the session ID (SessionID), side content identification (SCID), and the IP: PORT address of the CKU server</p><p>3512. . .a Driver for the CKU client setup device, which includes media with content to be served</p><p>3514. . .a CKU client obtains the CK certificate of the engine</p><p>3516. . .a CKU client establishes a connection</p><p>3518. . .a CKU server accepts incoming connections from clients and uses a confirmation message to confirm the connection</p><p>3520. . .a CK certificate and session ID of the CKU client transmission engine to the CKU server</p><p>3522. . .a CKU server responds with a confirmation or resend message</p><p>3524. . .a CKU server sets corresponding records in the transaction database</p><p>3536. . .a CKU server connects to the listening port of the original CKU video server</p><p>3538. . .a CKU original video server accepts the connection and responds with a confirmation message</p><p>3540. . .a CKU server combines message packets to request a key and sends it to the CKU original video server</p><p>3542. . .a CKU original video server responds with a confirmation message or resends the message (if any issues occur)</p><p>3544. . .a CKU original video server certification and rejection of CKDRM certificate for engine and CKU server</p><p>3546. . .a CKU original video server checks whether the certificate exists in the revocation database</p><p>3548. . .a If the certificate is invalid or revoked, the original CKU video server responds with an error message</p><p>3550. . .a If the certificate is valid, the original CKU video server retrieves the key complement from the related database and encrypts it</p><p>3552. . .a The original CKU video server sends the key complement to the CKU server</p><p>3554. . .a CKU server retrieves key complement and confirms receipt of data</p><p>3556. . .a If the data does not match or is received incorrectly, the CKU server responds to resend the message</p><p>3558. . .a CKU server uses authentication messages to send CKDRM credentials to the CKU client</p><p>3560. . .a CKU client responds with confirmation or resend message</p><p>3562. . .a CKU client creates an authentication command packet to send to the engine through the driver</p><p>3564. . .a Engine responds with encrypted conversation key</p><p>3566. . .a CKU client sends the conversation key to the CKU server in the conversation key message</p><p>3568. . .a CKU server responds with server confirmation or resend message</p><p>3570. . .a CKU server uses the private key to decrypt the conversation key and key complement</p><p>3572. . .a CKU server generates a random key</p><p>3574. . .a CKU server sends unlock message to CKU client</p><p>3576. . .a CKU client responds with confirmation or resend message</p><p>3578. . .a CKU client sends an error or unlocked completion message to the CKU server</p><p>3580. . .a CKU server indicates the status of the unlock operation in the transaction database and disconnects from the CKU client</p><p>3590. . .a CKU client reports the status of the transaction to the webpage by sending the event to the event handler in the webpage</p><p>3592. . .a Web page displays transaction status</p><p>Figure 36</p><p>3610. . .a The engine receives the key and the key complement of the key box</p><p>3620. . .a Engine performs key box lookup</p><p>3630. . .a The key in the key box is unlinked and decrypted</p><p>3640. . .a Key system relinking, encryption, and locking</p><p>Fig. 37</p><p>3702. . .a Program starts</p><p>3704. . .a DataPlay media is plugged into the DataPlay boot device, which is connected to a personal computer (PC) via a universal serial bus (USB) port</p><p>3706. . .a Automated Disposal</p><p>3708. . .a Content management device rendering locked content</p><p>3710. . .a ContentKey entry (optional)</p><p>3712. . .a ContentKey login</p><p>3714. . .a Software Package / Pricing Presentation-Consumers choose what they want to unlock</p><p>3716. . .a Enter billing and / or consumer information questionnaire</p><p>3718. . .a Presentation of transaction summary</p><p>3720. . .a Credit card authorization (optional)</p><p>3722. . .a Digital Information Exchange Server Notification</p><p>3724. . .a ContentKey startup status rendering</p><p>3726. . .a ContentKey engine and server authentication</p><p>3728. . .a Key complement lookup, transmission, and writing</p><p>3730. . .a Contents.ddl file update</p><p>3732. . .a ContentKey transaction completion event</p><p>3734. . .a Electronic retailer (eTailer) transaction completion notice</p><p>3736. . .a "Congratulations" page presentation</p><p>Figure 38</p><p>3802. . .a Digital Information Exchange Server (DCS) Order Management Server inserts records with or without media ID DCS_STAGE form</p><p>3804. . .a Digital Information Exchange Server (DCS) order management server generates a web page where a CKU client uses a transaction identifier as an example</p><p>3806. . .a CkU client obtains the ContentKey Digital Rights Management (CKDRM) certificate for this engine</p><p>3808. . .a CKU client obtains a unique media identifier (if not already created, it is executed by this engine)</p><p>3810. . .a CKU client obtains the ContentKey Digital Rights Management (CKDRM) certificate for this server</p><p>3812. . .a CKU client uses the ContentKey digital rights management (CKDRM) certificate of the CKU server, so that the engine obtains the session key (ESessionKey)</p><p>3814. . .a CKU client generates a final unlock request to authenticate and / or update the DCS_STAGE form with the media identifier, identify the engine, obtain the file disposition / key complement / version list, and wrap the file combination</p><p>3816. . .a CKU client sends the package file combination to the engine, so that the engine can unlock the content</p><p>3818. . .a CKU client sends this final transaction status message to this server And display a "Transfer Complete" message to the consumer / user</p><p>3820. . .a Digital Information Exchange Server (DCS) Order Management Server receives this status completion notification and deletes the DCS_STAGE record of this transaction and updates the transaction</p><p>Figure 39</p><p>3902. . .a engine</p><p>3904. . .a CKU client (suggests browser)</p><p>3906. . .a CKU server (3 Java Servlets)</p><p>3908. . .a Digital Information Exchange Server (DCS)</p><p>3910. . .a CkU original movie (Java category)</p><p>3912. . .a C ++ Library</p><p>3914. . .a DataPlay (DP) data security database</p><p>3916. . .a Brand webpage with CKU client embedded</p><p>3918. . .a Insert DCS_STAGE (transaction identification code, PCID, package software storage unit (PackageSKU), selective media identification code)</p><p>3920. . .a CKCMD_GET_CERTIFICATE</p><p>3922. . .a Engine credentials</p><p>3924. . .a DFSCMD_GET_MEDIA_METADAT</p><p>3926. . .a Unique media identifier</p><p>3928. . .a HTTP host</p><p>3930. . .a GetServerCert program (Servlet)</p><p>3932. . .a string GetServerContentKeyCertificate ()</p><p>3934. . .a string GetServerContentKeyCertificate ()</p><p>3936. . .a Credential or errorCredential or error</p><p>3938. . .a certificate or error</p><p>3940. . .a CKCMD_AUTHENTICATE (Server Certificate)</p><p>3942. . .a Session Key</p><p>3944. . .a HTTP announcement: ESessionKey, engine certificate, media ID, transaction ID</p><p>3946. . .a Unlock Content Program (Servlet)</p><p>3948. . .a String UnlockContent (ESessionKey, engine certificate, media ID, transaction ID)</p><p>3950. . .a P_KEY (transaction identification code, media identification code, password, result combination output)</p><p>3952. . .a Combination of results (file disposal-key-version) or error</p><p>3954. . .a string WrapFileSet (conversation key, engine certificate, file combination string, key count, media identifier)</p><p>3956. . .a Wrap file combination or error</p><p>3958. . .a Wrap file combination or error</p><p>3960. . .a Wrap file combination or error</p><p>3962. . .a CKCMD_UNLOCK_FILES</p><p>3964. . .a Success message, authentication success message, or failure message</p><p>3966. . .a HTTP announcement: transaction ID and status message</p><p>3968. . .a Update Status program (Servlet)</p><p>3970. . .a Update SQL syntax (transaction ID, status message)</p><p>3972. . .a UpdateStatus (transaction ID, status message)</p><p>Picture 40</p><p>4002. . .a Receive media including locked content</p><p>4004. . .a Automate the processing (or content management device) request and obtain a content.ddl file</p><p>4006. . .a Automatically execute the disposition (or content management device) to scan the content.ddl file to obtain the package software collection identifier (PackageCollectionID), package software collection inventory unit (PackageCollectionSKU), unlocked global resource locator (UnlockURL), major package software List of Storage Units (PackageSKU) and business entity identifiers, and a previously unlocked Package Software Storage Unit (PackageSKU)</p><p>4008. . .a Automatically perform processing (or content management device) to attach additional data to this global resource locator (URL) and open the default browser to display a web page generated by this e-tailer</p><p>4010. . .a eTailer presents a series of web pages to users / consumers to perform e-commerce transactions</p><p>4012. . .a After the user / consumer completes the transaction (such as a button and prompts the e-retailer), the e-tailer (eTailer) is required to notify the Digital Key Exchange Server (DCS) of the ContentKey unlock transaction. eTailer) is to send the PCID and a software inventory unit of the software package to be unlocked to this digital information exchange server (DCS)</p><p>4014. . .a This Digital Information Exchange Server (DCS) order management component generates a unique transaction ID and inserts a record for each software package purchased. At this time, the media identification code is unknown, so it will have a NULL value.</p><p>4016. . .a The Digital Information Exchange Server (DCS) responds to the e-tailer with a failure message or a Global Resource Locator (URL) that the user / consumer uses to unlock the content. The unlocked Global Resource Locator (URL) includes a transaction identifier generated by the Digital Intelligence Exchange Server (DCS)</p><p>4018. . .a This e-tailer (eTailer) generates a final confirmation message and unlocks the web page that includes the instruction to unlock the Global Resource Locator (URL)</p><p>Figure 41</p><p>4102. . .a engine</p><p>4104. . .a Automated Disposal</p><p>4106. . .a Electronic retailer (suggested browser)</p><p>4108. . .a Digital Information Exchange Server (DCS) Order Management Server</p><p>4110. . .a Digital Information Exchange Server (DCS) Order Management Database</p><p>4112. . .a Digital Information Exchange Server (DCS) components</p><p>4114. . .a A magnetic insertion event occurred</p><p>4116. . .a DFSCMD_GET_FILE</p><p>4118. . .a Returns the Contents.ddl file</p><p>4120. . .a Internal logic circuit</p><p>4122. . .a "Shopping cart" page</p><p>4124. . .a HTTP announcement (PCID, software package list)</p><p>4126. . .a Insert SQL syntax (transaction ID, PCID, package ID)</p><p>4128. . .a Unlock global resource locator (URL) or failure message Fixed action</p><p>4130. . .a "Unlock Designation" page</p>

In order for those skilled in the art to understand the present invention more easily, including various objects, features, and advantages of the present invention, the present invention is described below with reference to the drawings. In the following drawings, the same numbers are used to indicate similar or identical elements. Figure 1 illustrates the interactive operation of a digital rights management (DRM) system in the secure electronic content (SEC) system according to an embodiment of the present invention. FIG. 2 is a flow chart of content according to an embodiment of the present invention. FIG. 3 illustrates a method supported by a secure electronic content (SEC) system according to an embodiment of the present invention. Figure 4 is an Open Systems Interconnection (OSI) model that introduces a secure electronic content (SEC) system architecture according to an embodiment of the present invention. Figure 5A illustrates the content flow of secure and unsecured metadata according to an embodiment of the present invention. FIG. 5B illustrates a security method for retrieving data from the media according to an embodiment of the present invention. FIG. 5C illustrates a voucher program according to an embodiment of the present invention. FIG. 6 illustrates a procedure for establishing a secure authentication channel using a credential according to an embodiment of the present invention. FIG. 7A illustrates an apparatus for performing a confirmation procedure according to an embodiment of the present invention. FIG. 7B illustrates a method for securely transmitting data on a channel using a flowchart according to an embodiment of the present invention. Figure 7C is an illustration of the abolition of a table of contents according to an embodiment of the present invention. A way to discover the device. FIG. 7D is a flowchart for evaluating a revocation list according to an embodiment of the present invention. FIG. 7E illustrates a method performed by an engine when presenting a revocation list according to an embodiment of the present invention. FIG. 7F illustrates an evaluation method for abolishing a listing result according to an embodiment of the present invention. Figure 7G is a method of organizing content according to an embodiment of the present invention. FIG. 7H is a flowchart showing a program for showing an embodiment of a main control program. FIG. 7I is a flow chart showing an embodiment of a process for creating software package collection, software package advertising, and storage unit (SKU). FIG. 8 is a flowchart illustrating an application programming interface (API) of the ContentKeyO digital rights management (CKDRM) playback function according to an embodiment of the present invention. FIG. 9 illustrates a method for copying an Application Program Interface (API) agreement of the ContentKeyO digital rights management (CKDRM) according to an embodiment of the present invention. FIG. 10 illustrates a third-party digital rights management (TPDRM) copy method according to an embodiment of the present invention. FIG. 11 illustrates a method for recording content using the ContentKeyO digital rights management (CKDRM) according to an embodiment of the present invention. law. FIG. 12 illustrates a method for unlocking content according to an embodiment of the present invention. FIG. 13 illustrates a method for copying an Application Program Interface (API) agreement of the ContentKeyO digital rights management (CKDRM) according to an embodiment of the present invention. FIG. 14 illustrates an engine that executes a ContentKeyO digital rights management (CKDRM) replication method to replicate content in the ContentKeyO digital rights management (CKDRM) domain according to an embodiment of the present invention. FIG. 15 illustrates a recording scheme according to an embodiment of the present invention. FIG. 16 illustrates a method for playing content managed by ContentKeyO Digital Rights Management (CKDRM) according to an embodiment of the present invention. FIG. 17 illustrates a more detailed playback method using commands according to an embodiment of the present invention. FIG. 18 is a flowchart illustrating an unlocking step of ContentKeyO digital rights management (CKDRM) according to an embodiment of the present invention. FIG. 19 illustrates a third party digital rights management (TPDRM) replication agreement using a flowchart according to an embodiment of the present invention. FIG. 20 is a flowchart illustrating a method of third-party digital rights management (TPDRM) copying according to an embodiment of the present invention. FIG. 21 is a diagram illustrating a read security element according to an embodiment of the present invention. Information (RSM) Agreement. Figure 22A is a flowchart illustrating a protocol for a host to write its security metadata according to an embodiment of the invention. FIG. 22B is a flowchart illustrating a method for detecting forged media according to an embodiment of the present invention. FIG. 23A illustrates an architecture diagram for providing an embodiment of server, host, and engine interaction. Figure 23B is a flowchart showing a writing procedure. Figure 24 is a flowchart showing a procedure for setting up a safety database and safety metadata. Figure 25 illustrates a process for setting up an e-retailer. FIG. 26 is a flowchart of providing a transaction to unlock content locks from the perspective of a consumer according to an embodiment of the present invention. FIG. 27 is an exemplary user interface according to an embodiment of the present invention, which is used to describe how a transaction unlocks content from the perspective of a consumer. FIG. 28 is a flowchart illustrating the elements that initiate an unlocking procedure in the secure electronic content (SEC) system according to an embodiment of the present invention. FIG. 29 is a flowchart of a secure electronic content (SEC) according to an embodiment of the present invention. FIG. 30 is a diagram illustrating the types of content that can be obtained on the media according to an embodiment of the present invention. FIG. 31A is a diagram illustrating a type of transaction according to an embodiment of the present invention. Flowchart. FIG. 31B illustrates a method for introducing a user interface according to an embodiment of the present invention. The user interface includes a method for setting a global resource locator (URL) associated with a media disc. Figure 31C illustrates a method for connecting to a CKU server according to one embodiment of the present invention. FIG. 32 illustrates a method for a server to be requested by a client after a connection according to an embodiment of the present invention. Figure 33 illustrates a method performed by the master control server according to an embodiment of the present invention. Figure 34 illustrates a method for introducing 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 the perspective of a system according to an embodiment of the present invention. FIG. 36 illustrates a method for unlocking content from the perspective of an engine according to an embodiment of the present invention. FIG. 37 is a flowchart illustrating a procedure for completely unlocking a transaction lock according to an embodiment of the present invention. FIG. 38 is a flowchart illustrating a method for unlocking content according to an embodiment. Figure 39 is a flow chart for describing an object interaction between components. Fig. 40 is a flow chart illustrating the unlocking of a transaction according to an embodiment of the present invention. Figure 41 is a block diagram showing object interactions between components.