TWI362872B - Enrolling/sub-enrolling a digital rights management (drm) server into a drm architecture - Google Patents

Abstract

A Digital Rights Management (DRM) system has a plurality of DRM servers performing DRM functionality and an entering DRM-E server is enrolled into the system by an enrolling DRM-R server such that the entering DRM-E server is to be trusted within the system. The DRM-E server sends an enrollment request to the DRM-R server including a proffering identification and a public key (PU-E). The DRM-R server validates the proffering identification, and, if the request is to be honored, generates a digital enrollment certificate with (PU-E) for the DRM-E server to enroll such DRM-E server into the DRM system. The now-enrolled DRM-E server with the generated enrollment certificate is able to employ same to issue DRM documents within the DRM system. <IMAGE>

Description

1362872 [Technical field to which the invention pertains]

The present invention relates to a digital rights management (DRM) system. In particular, the present invention relates to an application DRM system for distributing digital content to an organization, such as an office or company or similar, to force the digital content to be visualized and used in the organization based on the corresponding usage or licensing items. More particularly, the present invention relates to a DRM server network for performing the DRM system and a method of registering or subregistering a DRM system into a network. [Prior Art] Digital rights management and implementation has a high degree of need to combine digital content, such as digital audio, digital video, digital text, digital data, digital multimedia, etc., where digital content is intended to be distributed to one or more users. Digital content can be static, such as a text file, or can be a stream, such as streaming audio/video for instant events. Typical patterns of dispersion include shaped devices such as magnetic (soft) discs, magnetic tape, optical (compressed) discs (CD), etc., and intangible media, such as electronics.

Bulletin board, electronic network, internet, etc. After the user receives it, the user performs or "plays" the digital content, such as a media player or the like on a personal computer, with the help of a suitable execution device. In one case, the content owner or rights holder, such as an author, publisher, broadcaster, etc., would like to distribute digital content to individual users or participants, exchange license fees or otherwise. However, in this case, the content may be a song, a record, a movie, etc., and the purpose of the distribution is to generate a license fee. This type of content owner, if available, would like to limit the user's right to do something about such distributed digital content. For example, the content owner wants to restrict the user from copying and redistributing the content to the second user, at least to reject those second users who do not pay the content owner license fee.

In addition, content owners will want to provide users with the flexibility to purchase different types of licenses at different license fees, while at the same time knowing what type of license the user actually purchased. For example, content owners may wish to allow spread digital content to be played only for a limited number of times, only for a specific total time, for a particular type of machine, for a particular type of media player, for a particular type of user, etc. Wait. In another case, a content developer, such as an employee or member of an organization, wants to distribute digital content to employees or members of one or more other organizations or to individuals outside of other groups, but wants to prevent others from executing content. . Here, the dissemination of content is more like sharing the organizational content in a confidential or restricted manner, as opposed to being widely distributed in exchange for licensing fees or other means.

However, in this case, the content may be a document presentation, a spreadsheet, a database, an email, or something like exchangeable in an office setting, and the content developer may wish to ensure that the content remains in the organization or office settings, and Not performed by unauthorized individuals, such as competitors or opponents. Similarly, content developers want to limit the amount of content that can be exploited by recipients. For example, a content owner wants to restrict the user from copying and redistributing content to a second user, at least in a manner that exposes the content to a range of individuals who are allowed to execute the content. In addition, content developers may wish to provide different levels of execution rights to different recipients. For example, content developers may wish to allow 6 £ to be called 872-protected number-like individuals, however, 1 developer for two-person computers and downloading real-net networks. Of course, it may be necessary to scatter the content again. Moderately decisive storage of the number, however, allows control of its control. Specific—especially in personal or individual servos. [The above-mentioned bud (DRM) system's content can be reviewed by one type of individual but not printed, and can be reviewed and printed separately. In either case, the content owner/digital content has very little control after the spread occurs. In particular, the problem lies in the fact that each software and hard copy containing the actual digital copying of the digital content is copied to a writable disk or disc to be copied to another destination by transmitting the actual digits such as the Internet. In the processing part of the content distribution, the user/receiver of the content owner/developer digital content guarantees that the content is not in the undesired cloth. However, the guarantee is easy to make and the report is easy to fight. You may want to avoid encrypting and decrypting through any known security patch. However, it seems that users who are difficult to avoid decrypt the encrypted digital content, unencrypted values, and then distribute it again. There is a need to provide a method of digital rights management (DRM) and execution architecture and any form of execution or playback of digital content, which is flexible and can be allowed and promoted by content owners/developers of digital content. This control performs the requirements of the architecture, the office or organizational environment, or a similar file that is intended to define the community of people in the group. In other words, there is a need to register the method of obtaining the authenticator into the architecture. At least partially satisfied by the present invention, wherein the digital rights management has multiple DRM servers performing DRM functions, and the input 1362872 into the DRM-E server is registered in the system by registering the DRM-R server, so that the input The DRM-E server is trusted in the system. In the present invention, the DRM-E server obtains a public/private key (PU-E, PR-E) for identifying the DRM-E server in the DRM system, obtaining the identification thereof, and transmitting the registration request to include A DRM-R server that provides identification and (PU-E).

The DRM-R server verification provides identification and, if required, will generate a digital registration voucher for the DRM-E server to register the DRM-E server to the DRM system. The resulting registration voucher is based at least in part on (PU-E). The DRM-R server returns the generated registration credentials to the required DRM-E server, and the currently registered DRM-E server stores the returned registration credentials in place for future use. A DRM-E server with registration credentials can be applied to issue DRM files in the DRM system. [Embodiment] Computer environment

BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 and the following description are intended to provide a general short description of a suitable computer environment in which the present invention may be implemented. However, it should be understood that handheld, portable and all other types of computer devices can be used in the present invention. However, the general purpose computer described below is merely illustrative, and the present invention requires only a thin client with a network server that is interoperable and interactive. Therefore, the present invention can be implemented in an environment of a web host service, which contains very few client resources, such as a web environment in which the client device only serves the browser and interface of the World Wide Web. Although not required, the present invention may be implemented via an application interface (API), for use by a developer, and/or included in a computer executable instruction of a program module executed by one or more computers. The general content of the web is like a client workstation's server or other device. A general program module contains subprograms, programs, objects, components, data, and the like that perform a specific job or perform a specific profile type. It is said that the functions of the program modules can be combined or distributed in each of them if necessary. Moreover, those skilled in the art will appreciate that the present invention can be implemented in other architectures. Other known computing systems and/or architectures that may be suitable for use in the present invention include, but are not limited to, personal computers (PCs), automated teller machines, handheld or laptop devices, multiprocessor systems, microsystems, programmable Customer electronics, network PCs, mini motor computers, and more. The present invention can also be implemented in a distributed computing environment where the remote processing device operates over a communication network or other data transmission medium. In a distributed computing environment, the program module can be placed in a regional computer storage medium, including a memory storage device. Thus, Figure 1 illustrates an example of a suitable computer environment 100 that can be implemented by the present invention, although it has been clearly stated that the computer system loop is only one example of a suitable computer environment and is not intended to be limited to only the use or scope of functionality. The computer environment 1 〇 0 does not need to have any requirements related to any of the components described in the Industry Environment 100. Referring to Figure 1, a general purpose computer device in the form of an exemplary system of the present invention, package 110. The components of computer 110 are accessible to the present invention. Not limited to processing unit 120, system memory 1 30, and system bus. It couples different system components including system memory to processing 1 2 0. The system bus 1 1 1 can be any type of bus structure, έ software says, with the implementation of the brain system, ring:, word processor i, the main execution of the remote system ring: 100 invention case computer However, 121, 〇〇—early 7G occupies 1362287. The area bus of the body bus or memory control architecture. For example, but not limited to 'this architecture includes industry standard architecture (ISA) bus, micro channel architecture (MCA) bus, add ISA (EISA) bus, video electronic standard association (VESA) area bus and peripheral components Connected (PCI)® stream (also known as Mezzanine bus) The computer 110 generally contains a variety of different computer readable media. The computer readable medium can be any available media that can be accessed by the computer 11 and includes both volatile and non-volatile media, removable and non-removable media. By way of example and not limitation, 'computer-readable media can include computer storage media and communication media. Computer storage media includes volatile and non-volatile media, removable and non-removable in any method or technology. In addition to media for storing information, such as computer readable instructions, data structures, squat modules or other materials. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM 'Flash § Remembrance or other memory technology, (10) Digital Multi-Disc (DVD) or other CD storage, magnetic fi, tape, disk storage or other magnetic storage Any other media that can be used to store the desired information and can be accessed by the computer]1. The communication medium generally implements computer readable instructions, data structures, program wedges or other data on modular data signals like carrier waves or other transport mechanisms, and contains any information delivery media. "Modified data loss", 〇, J - 思思思 is one or more of its characteristic groups or changes in its way to encode the current 仏唬 仏唬 仏唬 仏唬 仏唬 仏唬 仏唬 仏唬 仏唬 仏唬 仏唬 仏唬 仏唬 仏唬 仏唬 仏唬 仏唬 仏唬 仏唬 仏唬 仏唬 仏唬 仏唬 仏唬 仏唬 仏唬 仏唬 仏唬 仏唬 仏唬 仏唬 仏唬 仏唬Print this a* ^ All-in-one media contains wired media, such as wired network or direct connection connection, and the wireless media of the benefit line... is sonar, radio frequency, infrared or other •, the above combination should also be included in the computer Readable media

S 1362872 in the range. System memory 130 includes volatile and/or non-volatile notes*. The hidden computer storage medium is like a read only memory (r〇M) 131 and a form random access memory (RAM) 132. The basic output/input system 133 (BI0S) contains an ancient program that helps to transfer information between components in the computer during the power-on period, and is stored in the ROM 131. The RAM 132 is generally referred to as a data file and/or a program module currently stored in the processing unit 120 and/or currently operating on the processing unit 120. By way of example and not limitation, FIG. 1 illustrates, for example, the operating system 134' application 135, other program modules 136, and program sounds such as Beca 137. The computer 110 can also include other removable/non-removable, volatile, stationary computer storage media. By way of example only, the figure/non-illustration illustrates reading or writing a non-removable, non-volatile magnetic media J hard device 141, reading or writing a removable, non-volatile disk. 152 * 叩 Disk Dreamer 151 and read or write removable, non-volatile discs 156, straight j-distribution 155, such as CD R0M or other optical media. Can be used as an example for other removable/non-removable, volatile/non-volatile industry rings. Computer health media includes but is not limited to tape cartridges, flash memory cards' Γ double m discs; Take

Things: video tape, ... AM, solid state R0M and so on. The hard disk device 141 is connected to the s stream 12 through a non-removable memory interface such as the interface 140, and the disk device 151 and the optical device 155 are generally removable memory of the interface 150. The interface is connected to the system bus ^^ by knowing the above and the first! The device shown in the figure and its associated computer. For the computer to read the ♦, f material structure program module and electricity month (1), the storage of physical information. For example, in the figure, the hard disk device II =

11 1362872

The storage operating system 144, the application program 145, the other program modules 146, and the program data 1 4 7 are exemplified. It should be noted that these components may be the same or different from operating system 134, application 135, other programming modules 136, and program data 137. The operating system 144, application 145 'other program modules 146 and program data 147 are given different numbers here to exemplify at least that they are different copies. The user can input commands and information into the computer 110 through the input device, such as the keyboard 162 and the indicator device 161, generally referred to as a mouse, a trackball or a touchpad. Other input devices (not shown) may include a microphone, a joystick, a game board, a satellite dish, a scanner, and the like. These and other input devices are typically coupled to the processing unit 120 via a user input interface 160 coupled to the system bus 121, but may be connected to the bus structure by other interfaces, such as a parallel port, a gaming device, or a universal serial port (USB).

The screen 191 or other type of display device can also be connected to the system bus 1 1 1 via the interface, such as the video interface 190. For example, the north bridge's graphical interface 1 8 2 can be connected to the system bus 1 1 1. The Northbridge is a chipset that communicates with the C P U or host processing unit 120 and is assumed to be responsible for Accelerated Graphics (AGP) communications. One or more graphics processing units (GPUs) 184 can communicate with graphics interface 182. Here, GPU 1 84 typically includes on-wafer memory storage as stored by the scratchpad, while GPU 1 84 communicates with video memory 186. However, GPU 1 8 4 is not an example of a processor, and thus various different processing devices may be included in computer 110. The screen 191 or other type of display device can also be connected to the system bus 1 1 1 via the interface, such as the image interface 190, which can then communicate with the image memory 186. In addition to the screen 191, the computer can also contain other peripheral output devices, such as a la. Eight 1 9 7 with printer 1 9 6 ’

S 12 1362872 The output peripheral computer 110 can be logically connected to - or multiple remote computers to operate in a network computer - such as a remote computer 180 〇 remote computer 18 〇 can be a personal computer, server, router A network PC, an equivalent device, or other general purpose network node, and generally includes many or all of the elements described above in connection with the computer 11', although only the memory storage device 181 is illustrated in FIG. The logical connections depicted in Figure 1 include a local area network (LAN) 171 and a wide area network (WAN) 173&apos; but may also include other networks. This network environment is typically found in offices, corporate computer networks, internal networks, and the Internet. When used in a LAN network environment, the computer 11 is connected to the LAN 171 through a network interface or adapter 170. When used in a Wan network environment, the computer 110 typically includes a data machine 172 or other device for establishing communications over the WAN 173, such as the Internet. The internal or external data engine 172 can be coupled to the system bus 1 1 1 via a user input interface 16 or other suitable mechanism. In a networked environment, a program module describing a computer or its portion can be stored in a remote memory storage device. By way of example, but not limitation, the figure exemplifies that the remote application 185 is located in the memory device 81. It should be understood that the network connection example shown is 'and other means of establishing a communication link between computers can be used. Those skilled in the art should be aware that the computer 110 or other client can be configured as part of a computer network. Accordingly, the present invention relates to a computer having a memory or client with any amount of memory or storage unit and any number of applications and processes occurring in any number of storage orders _ 3 θ The computer is located in the environment of the ring c 13 1362872, with remote or regional storage. The invention can also be applied to an independent computing device having a programming language function, a literal translation and an execution function. Decentralized computing devices share computer resources and services with the system through direct exchange of computing devices. These resources and services include files for exchanging information, caches, and disk storage. Decentralized computing utilizes network connectivity, allowing clients to leverage their energy collection to take advantage of the entire professional system. Here, a variety of different devices may have applications, objects or resources that are interactive to generate the authorization technology of the present invention for the trusted graphics pipeline. Figure 2 provides an architectural diagram of an example network or decentralized computing environment. The decentralized computing environment includes computing objects l〇a, 丨〇b, etc. and computing objects or devices 110a, 110b, 110c, and the like. Objects can contain programs, methods, data storage, program logic, and more. Objects may contain parts of the same or different devices, such as PDAs, televisions, MP3 players, televisions, personal computers, and the like. Each item can communicate with another item in the manner of a communication network 14. The network itself can contain other computing objects and computing devices, providing services to the system in Figure 2. In accordance with the teachings of the present invention, each object 1〇 or 11〇 may contain an application β φ that may require the authorization technique of the present invention to trust the graphics cable. It should also be understood that an object such as 110c may be located on another computing device 1 or 11 . Thus, although the physical environment may display a connection device such as a computer, this illustration is merely an example 'and the physical environment may be described as including a (four) bit device' such as a PDA, a television, an MP3 player, etc., a soft object , like interfaces, COM objects, and so on. There are a variety of different systems, components, and network architectures that support a decentralized computing environment. For example, a computing system can be connected by a line or wireless system to a regional network 14 1362872 or a widely distributed network. Currently, many networks are coupled to the Internet, which provides a widely distributed computing infrastructure and contains many different networks.

In a home network environment, there are at least four separate network delivery media that each support unique protocols such as power lines, data (wireless and wired), voice (such as phones), and entertainment media. For example, the light switch and most of the household control devices of the device are connected by a power cord. Data services can be transferred to the home with broadband (such as DSL or cable modems) and can be connected to the home using wireless (HomeRF or 802.lib) or wired (H〇me PN A, Cat 5, or even power cord) take. Sound transmissions can be wired (such as Cat 3) or wireless (such as mobile phones) into the home' and can be dispersed throughout the home using Cat 3 lines. Entertainment Media can enter the home via satellite or cable, and in general can be dispersed in the home using coaxial cable. IEEE 13 94 and DVI also form a digital interconnect of the cluster of media devices. All network environments can be interconnected with other standards that form communication protocols to form an internal network that can be connected in the Internet: in the external world. In short, different resources exist for data storage and transmission. And then, even the computer device will need a method to protect the contents of the data processing pipeline.

"Internet" is generally referred to as a collection of networks and gateways that utilize the TCP/IP group protocol, which is well known in the art as a computer network, TCP/IP 网路 Network Transmission Control / International Network Protocol J abbreviation. The Internet can be described as a system of geographically dispersed remote computer networks interconnected by computers that perform the interaction of users through network interaction and sharing of information. Because of the sharing of if&quot;skin/JL·slip information, such as the Internet's remote network, it is gradually integrated into the open system, where developers can design software applications to execute

S 15 1362872 There are basically no restrictions on a particular operation or service.

Therefore, the network infrastructure starts the host of the network layout, such as a client/server, peer-to-peer or hybrid architecture. A "client" is a member of a category or group of services that use another category or group associated with it. Therefore, in a computer, the client is processing, that is, roughly a set of instructions or work, and a service provided by another program is required. The client handles the requested service without having to "know" any work details about other programs or services themselves. In a client/server architecture, especially a network system, a client is often a computer that accesses shared network resources provided by another computer such as a server. In the example of FIG. 2, the computers 110a, 110b, etc. can be regarded as clients, and the computers 1 Oa, 1 Ob, etc. can be regarded as servers, wherein the servers 1 Oa, 1 Ob, etc. are maintained and then copied to the client computer. 1 1 〇a, 1 1 〇b, etc.

The server is typically a remote computer system that can be accessed via a remote network such as the Internet. The client processing can be active in the first computer system, and the server processing can be active in the second computer system and communicate with each other through the communication medium, thereby providing a distributed function and allowing multiple clients to utilize the server's information collection function. The client and server communicate with each other using the functionality provided by the protocol layer. For example, Hypertext Transfer Protocol (HTTP) is a universal communication protocol used to integrate the World Wide Web (WWW). In general, computer network addresses such as Uniform Resource Locator (URL) or Internet Protocol (IP) addresses are used to identify each other to the server or client computer. A network address can be referred to as a unified resource locator address. For example, communication can be provided via a communication medium. In particular, the client and server can connect to high-capacity communication via TCP/IP.

S 16 1362872 is mutually compatible.

Thus, Figure 2 illustrates an exemplary network or distributed environment in which the present invention can be applied, with a server that communicates with client computers via a network/bus. In more detail, according to the present invention, a plurality of servers 10a, 10b, etc. are interconnected via a communication network/busbar 14, which can be a LAN, a WAN, an internal network, an internet, etc., with many clients or far End computer devices 110a, 11〇b, 11〇c, 11〇d, 110e, etc., such as portable computers, handheld computers, thin clients, network devices or other devices, such as VCR, TV' ovens , lights, heating, etc. It is therefore believed that the present invention is applicable to any connected computer device in which it is desired to process, store or execute secure content from a source of confidence. For example, 'in the communication network / bus 1 4 is the Internet environment of the network' server 10 can be a network server, where the client 1丨〇a, 丨丨〇b, 1 10c, 1 L〇d, 1 10e, etc. communicate via any known communication protocol such as HTTP. Server 10 can also act as a client 1 1 〇, which can be a feature of a decentralized computing environment. The communication can be wired or wireless as appropriate. Client device

I 1 0 may or may not communicate via the communication network/bus 14 and may be associated with independent communication. For example, in the case of a TV or VCR, there may or may not be its network control. Each client computer 11 and the server computer 10 can be provided with different application modules or objects, and can connect or access different types of storage elements or objects, wherein the files can be stored or some of the buildings can be downloaded or moved. Therefore, the present invention can be used in a computer network environment having a client computer II 0a, 〇 〇b, etc., which can access or interact with a computer network/busbar 1 4, and the server computer 10 a, 丨〇b and so on can interact with 17 1362872 computers 110a, 110b, etc. and other devices ill and database 2〇. The DRM overview is known, and referring to the figure, digital rights management (DRM) and implementation highly need to combine digital content 12' like digital audio, digital video, digital text, digital data, digital multimedia Etc., where the digital content 12 is intended to be distributed to the user. After receiving by the user, the user performs or "plays" digital content, such as a media player on the personal computer 14, by means of appropriate execution of the device. In general, the content owner or developer (which is collectively referred to as "owner j") that distributes this digital content 12 wishes to limit what the user can do with the distributed digital content 12. For example, the content owner may wish Restricting the user from copying and redistributing this content 12 to the second user, or may wish to allow the distributed digital content 12 to only play a limited number of times, only for a specific total time, only for a particular type of machine, only for a particular type of media Playing on the player, playing only by a specific type of user, etc. However, after the occurrence of the distribution, the content owner has little control over the digital content 12. Then the 'DRM system 10 allows the execution of the control or plays any form of digits. Content 12, which is controlled to be flexible and can be defined by the content owner of the digital content. In general, the content 12 is distributed to the user in the form of a packet 13 by any suitable scatter channel. When scatter, the digital content packet 13 It may contain digital content 12 (ie (KD (CONTENT))) encrypted with symmetric encryption/decryption record (KD), and other resources for identifying content. How to obtain a license for this content, etc. The trusted DRM system 10 allows the owner of the digital content 12 to specify a mandatory amount of 18 £1,362,872 to which the digital content 12 is permitted to be executed prior to the user's computing device 14. The license rules may include the aforementioned timing requirements and may be implemented in a digital license or usage file (hereinafter referred to as "license") 16 of the user/user's computer device 14 (hereinafter, unless otherwise required, this column may be Interchange) must be obtained from the content or its agent. This license ^ also contains the decryption key (KD) used to decrypt the digital content, perhaps encrypted by a key that can be decrypted by the user's computer device. A content owner of a digital content 12 must rely on the user's computer device 14 to comply with the rules and requirements specified by the owner of the valley in the license 16, that is, unless the rules in the license 16 meet the requirements, Otherwise the digital content 12 will not be executed. Next, preferably the user's computer device 14 is provided with a trusted component or mechanism 18. Unless the license rule associated with the digital content 12 is implemented on the license 丨6 and is obtained by the user, the digital content 1 2 will not carried out. The trust component 18 generally has a license evaluator 2, determines whether the license 噔 16 is valid, reviews the license rules and requirements of the valid license 16, and determines whether the user of the request is authorized according to the license rules and requirements of the review. The way to execute the required digital content 12 is. It should also be understood that the license = estimator 20 relies on the DRM system to implement the hope of the owner of the digital content 12 in accordance with the rules and requirements of the license 2, and the test can not easily change the trust for any purpose. Components, whether malicious or not. It should be understood that the rules and requirements in License 16 may specify whether the user has authority to perform digital content 12 based on any facts, including the user, where the user is located, what type of electrical clothing the user uses, and the implementation.

S 19 1362872 Programs to call the DRM system, date, time, etc. In addition to this, for example, the rules and requirements in the license 16 may limit the license 16 to a predetermined number of times of play or a predetermined play time. Rules and requirements can be specified in License 16 based on the appropriate language and grammar. For example, the language can simply specify the attributes and values that must be met (eg, the period must be greater than X) or can require that the function be executed according to a specific law (if the period is greater than X, execute...).

After the license evaluator 20 determines that the license 16 is valid and the user complies with its rules on the requirements, the digital content 12 is then executable. In particular, to execute the content 12, the decryption key (KD) is obtained from the license 16 and is used (KD(CONTENT)) from the content package 13 to cause the actual content 12, and the actual content 12 is actually executed. Publishing digital content

Figure 3 is a functional block diagram of a system and method for distributing digital content. "Distribution" is the term used herein to mean the application or service that follows the set of permissions and conditions that an entity in a trusted entity can issue for content, and who the rights and conditions can be issued to. In accordance with the present invention, the issuance process includes encrypting the digital content and associated with a series of continuously enforceable permissions that the content author wants to give to all possible content users. This process can be performed securely to block access to any permissions or content unless the content author wants it. A special three entities are implemented to issue secure digital content: a content preparation application 302 executing on the client 300 and preparing to distribute content, a digital rights management (DRM) application interface (API) 306 also located on the client device 300, and via Communication network 330 is communicatively coupled to client 300

S 20 1362872 DRM server 320, such as an internet, regional or wide area network or a combination thereof.

The content preparation application 302 can be any application that produces digital content. For example, application 302 can be a word processor or other publisher that produces digital text files, digital music, images, or other such content. Or for example, the content may also contain streaming content, such as streaming audio/video for instant or recorded events. The application 302 is provided with a cryptographic key to encrypt the digital content, thus forming an encrypted digital content file 304, and the user provides the privilege data closely related to the encrypted content in the digital content file 304. The privilege profile contains the identification of entities with digital content rights, and each recognition entity has a set of permissions and conditions. For example, this entity can be an individual, a personal category, or a device. This privilege can include permissions to read, edit, copy, print, and more. Conditions can include minimum system requirements, date and time limits, number of plays, and more.

The client API 3 06 passes the encrypted digital content and rights data to the DRM server 320. Using the processing described below, the DRM server 320 determines whether it implements the rights profile, and if so, the DRM server 322 issues the rights profile to form the signed rights tag (SRL) 308. However, in general, any trusted entity may issue rights information, preferably using the key trusted by the DRM server 320. For example, the client can use the DRM server 320 to issue the rights information for the key it provides. The rights label 3 0 8 may contain data indicating the rights description, the encrypted content key, and the digital signature of the encrypted content key and the encrypted content key. If the DRM server 320 issues a rights label, it will pass through the client API 306.

S 21 1362872 The permission label for storing the issued content The content permission label 308 issued by the preparation application 302 is transmitted back to the client 3〇8 on the client device 3〇〇. The associated authority can then be associated with the waiver. The 艮 织 308 and the φ digital content file 3 〇 4, for example, like the order of #士, drag defense #饰# ^ μ 疋 to form the authority official content file 310. However, it is noted that the SRL 308 should be stored in a known location, respectively, from the content file 3〇4, with the SRL 308 referenced to the content slot 3〇4 to form the content floor 31〇. Now refer to Figure 4, which shows the side of the distribution rights management digital content.

law. At step 402, the application 3〇2 generates a content key (ck) for encrypting the digital content. The content key (CK) is generally a symmetric key, although any key can be used to encrypt digital content. As is known, symmetric keys are applied to the symmetric key algorithm for encryption and decryption. Accordingly, (CK) should be hidden when sharing between the sender and the receiver.

At step 404, the application program 〇2 encrypts the digital content having (CK) to form the encrypted digital content 3〇4 (i.e., (CK(content))). In addition, permission data corresponding to (CK(e on tent)) is generated, whether by the issuer of the content or by other entities. Note that this permission data can be a custom permission profile or a permission profile obtained from a scheduled template. As noted above, the rights profile may include a series of entities that are eligible to consume content, specific permissions for each entity for content processing, and any conditions upon which such rights may be imposed. At step 406' API 306 generates a second encryption key (K2) for encrypting the content key (CK). Preferably, (K2) is also a symmetric key. At step 408,

API 306 is caused by (K2) encryption (CK) (K2(CK)). At step 410, API 306 discards (CK) and the result (CK) is now only available for decryption (K2(CK)). To ensure that (CK(content)) protection is the central DRM server 320, and the content

All "License Requirements" of S 22 1362872 are completed centrally according to the privilege data. At step 412, API 306 contacts the provided DRM server 320 and retrieves its public key (PU-DRM) » at 414, API 3 06 Caused by (PU-DRM) encryption (K2) (PU-DRM (K2)). Therefore, (CK) can protect (pu-DRM) to ensure that the DRM server 320 is an only accessible (CK) entity requiring decryption (CK(content)). At step 416, API 306 causes (f2 (rightsdata)) to encrypt the rights data (i.e., the list of authorized entities and the individual rights and conditions associated with each authorized entity in the list). In another embodiment, (CK) can be used to directly encrypt the rights data (CK (rightsdata)), and (pu-DRM) can be used to directly encrypt (CK) to cause (PU-DRM (CK)), thereby giving up Complete use (K2). However, using (K2) Encrypted Rights Data and (CK) allows this (K2) to be suitable for any particular algorithm that can be subject to the DRM server, however (CK) can be specified by an entity independent of the DRM server and can be disobedient. At step 418, the content protection application 3〇2 transmits (pu-DRM (K2)) and (K2 (rightsdata)) to the DRM server 320 as the issued rights label. Or the client itself can issue permission data in the following way. If the privilege data is passed to the server for issuance, then at step 420, the DRM server 322 accesses the privilege profile and verifies that it can enforce the privilege and conditions in the delivery privilege tab. To verify that the privilege profile can be enforced, the D RM server 3 2 0 applies a private key (PR_drm) corresponding to (PU-DRM) to (PU-DRM(K2)) resulting in (K2), and then (K2) (K2 (rightsdata)) causes the permission data in the purge. Server 3 2 0 can then perform any policy checks to verify that the users, permissions, and conditions specified in the rights profile are available in the 1362872 policy implemented by server 32. The server 320 issues the originally transmitted rights label, including (PU-DRM (K2)) and (K2 (rights data)) the issued rights label (SRL) 308, wherein the signature is based on the private key of the DRM server 320. The SRL 308 is passed back to the API 306, and the returned SRL 308 is then presented to the client application 302.

The SRL 3 08 coefficient is issued to make it resistant to intervention. In addition, SRL 308 is an independent real-world key type and algorithm that is used to encrypt content but maintain a strong one-to-one relationship for the content it protects. Referring now to FIG. 4A, in the embodiment of the present invention, ' SRL 308 may contain information on the content, according to SRL 308, and may include the ID of the content; information on the DRM server that issues SRL 308' includes (PU-DRM (K2) )) and reference information, such as to locate the URL of the DRM server on the network, and if the URL fails, the information is back; describe the information of the SRL 308 itself; (K2 (rightsdata)); and the digital signature (S (PR) -DRM)) and so on.

By ensuring that the trusted entity issues the rights information to establish the issued rights label 3 08, the DRM server 320 asserts that it will issue a license for the content as described in the rights information of the issuer in the rights tab 308. It should be understood that the user is required to obtain license execution content, especially since the license contains a content key (CK). When the user wants to obtain a license for the encrypted content, the user can present the license request for the content containing the SRL 308 and verify the user's credentials to the DRM server 320 or other license issuing entity. The license issuing entity can then decrypt (PU-DRM(K2)) and (K2(rightsdata)) to generate the rights information, list the permissions authorized by the author of the issuing entity (if any), and construct a license with only this specific permission. .

24 S 1362872 As described above, after the application 302 receives the SRL 308, the method 302 serializes the signed permission box with the corresponding (CK(content)) to form the rights management digital content. Alternatively, the rights data is stored in the location where the referenced digital content is provided. Thus, the application executing the launch can execute the portion of the rights issued 308 that is to be executed by the application. This discovery bursts the execution application and begins the licensing requirements for the D R Μ license server 3 2 0. For example, the application 302 can store the URL in the DRM license server 32, and the bite permission server 320 can use its own URL as a metadata in the permission label before the digital is issued, thus executing the DRM of the application. The end API 306 can identify the correct DRM license feeder 320. Obtaining a license for the content to be distributed Now, refer to Figure 5, which shows how the license rights manage digital content. The term "license" is used herein to mean the application or follower request and receipt will initiate the process of naming the license to consume the content entity based on the license. The input for the license processing may include the certifiable content-related issued Rights Label (SRL) 3〇8 to certify the entity's public key credentials. Note that the entity requires a license to be the entity to which the license is required. In general, the license contains a description of the permissions of SRL 3 08, an encryption key that decrypts the encrypted content, and a permission description and encryption key to claim a legitimate and avoidant digital signature: Initially, the client API 306 is transmitted via the communication network 330. The issued rights tab 3〇8 of the rights content 310 to the DRM server 320. The permission label 308 contains the public service 308 according to the DRM server 320. The DRM is issued to issue the DRM-partial customer service. The middle finger and the permit are not from the transmission. Management The above is the opening key 1362872 key (PU-DRM) encrypted content key (ck) (ie (PU-DRM(CK))). Next, in the process of issuing the license, the DRM server 320 uses (PR-DRM) for (?11-〇111^(0:〖)) to obtain ((^)«&gt; and then use the transfer to the license request. The public key (PU-ENTITY) in the public key certificate of re-encryption (CK) (ie (PU-ENTITY (CK))). The newly encrypted (PU-ENTITY (CK)) is then placed in the license. Therefore, the license may not (CK) be exposed to the risk and returned to the caller, since only the holder of the private key corresponding to (PU-ENTITY) (pr-ENTITY) is available from (PU-ENTITY (CK) Recovery) (CK). The client API 306 then uses (CK) to decrypt the encrypted content to form the decrypted digital content 312. The client application 302 can then use the decrypted digital content 3 1 based on the permissions provided in the license. 2. Or 'As described below, for example, a client that issues a client can issue a license to itself to consume content. Now to Figure 6A and Figure 6B, the method of displaying permission rights to manage digital content" is in the step In 602, a license issuing entity such as DRM server 320 receives a license request containing a public key certificate. Each entity that requires the licensor. Presumably, if the identification is specified, the DRM server 320 can obtain the corresponding public key vouchers from the catalog, the database, etc. If the license is only - the licensor requires, only one vouch or Identifying. If the license is for multiple licensees, 'name the credentials or identify each potential licensor. At step 604', if required, the certification requires the entity (entity manufacturing license requirements). At step 606, if necessary, Decide whether to allow the entity to request a license. In step 608, if the issuing entity decides that the public key certificate is not included in the request, the identification execution document is not authorized for the given potential. If the error is returned to the real hypothesis of the DR Μ key certificate, then the reliance on the step vouchers. If the certifier is not convinced, and any spoofs issued by the error creator, the DRM digital signature verification, the certificate. If the licensor's public gold licensor does not trust, then the issuer 320 may be required in step 6 of the license request. Each of the rights may be (step 622) a copy. The primary authority issuing entity uses the specified recording service or database for the appropriate public key certificate. In step 610, if the record is issued, then in step 612, the voucher is obtained. Found, whether in the request or in the directory, a license is issued for the potential licensor and at step 614, the service IS 3 2 0 has at least one potential licensor having a disclosure 616, and the DRM server 320 verifies each license If the verification is not verified, the DRM server 320 determines the list of the licensor's credentials, and then the licensor's request is lost in step 614. Therefore, the voucher is not issued by trust and the licensee will not receive the license. The feeder 3 2 〇 preferably performs execution of the self-trusted issuer certificate to all entities in the voucher key to the respective licensee public key certificate verification process is a known algorithm. If the given key certificate is not verified, or the certificate in the chain is not verified, the license is not issued to the potential licensor. No, a license can be issued. Processing repeats step 620 until an entity has processed it. The illustrated 'DRM word processor 320 handles the verification received by the permission token 308. In an embodiment, the 〇 r μ servo limit tag is the primary copy issued thereby. Then, in the license, the DRM server 320 obtains the label of the main authority and can be updated to the permission label to be transmitted to the license request.

A copy in S 1362872, and therefore no primary permission label is issued. The predetermined policy determines whether the policy is not allowed and the license is incorrectly passed back to API 306. In order to generate the required license, the current DRM server 320, according to the permission in the request, requires the permission label of the failure certificate in step 626. If at step 624, the license is issued in accordance with the signing. If and in step 628, the DRM server 320 verifies that the SRL 308 is signed earlier than its digits. If the SRL 308 is not verified, the license request fails at step 626 and the error is passed back to the API 306 at step 628. After all verifications have taken place, the DRM server constructs a license for each licensed license in accordance with SRL 3 08. In step 63 2, the DRM server 320 generates a relative permission specification for the license to be issued to each licensee. For each of the licensees, the DRM server 320 verifies the identification of the naming in the licensor's public key voucher relative to the naming identified in the privilege specification in the privilege tag. At step 63 6, DRM server 320 obtains (PU-DRM(K2)) and (K2(CK))' from SRL 308 and applies (PR-DRM) to obtain (CK). The issuing entity then re-encrypts (CK) with the public key certificate (PU-ΕΝΤΙΤΥ) from the licensor (PU-ENTITY (CK)). In step 308, the DRM server 320 serializes the generated permission description of (PU-ENTITY (CK)) and uses the (PR-DRM) digit to issue the result data structure (i.e., S(PR-DRM)). The information structure issued is therefore a license for this particular licensor. At step 640, DRM server 320 determines that no more licensors are required to generate specific requirements. At step 642, the generated license then passes back to the requesting entity&apos; and the appropriate credential chain that connects the license back to the trusted licensor. Self-issuance issued rights label 3 0 8 £ 28 1362872 In an embodiment of the invention, the SRL 308 may be issued by the requesting/issuing user itself. Accordingly, the user does not need to contact the DRM server 320 to obtain the SRL 308 for the relevant content. Therefore, self-issuance can also be called offline distribution. In this embodiment, the issuer should also be able to issue their own issuer licenses', especially because of the self-issued guilty DRM protection, and this issuer license requires that the issuer be allowed to perform the currently protected content. It should be understood that the issuer can initiate a license to other users.

In particular, referring now to FIG. 7, in an embodiment, a (PU-ENTITY) trusted component 1 including a public key (PU-OLP) and a direct or indirect access user is received from the DRM server 320. 8 (Fig. 11) The corresponding private key (PR-OLP) encrypted according to the public key causes the offline issuance (OLP) voucher 810 of the PU-ENTITY (PR-CERT) to be prepared for offline distribution. For example, the PU-ENTITY may be the public key of the trusted component 18 or may be the public key of the user accessed by the public key of the trusted component 18. The OLP credential 810 should be issued by the private key (PR-DRM) of the DRM server 320 so that the DRM server 320 can verify the OLP credential, as will be detailed below. In addition, the OLP credential 810 should contain a credential chain from (PU-DRM) back to the trusted licensor, which is trusted by the issuing user or another user's trusted component, such that the trusted component 18 can be verified This OLP voucher 8 1 0 and any other voucher or license associated with this 0 LP voucher 8 1 0 will be detailed below. In short, it should be understood that the credential chain begins with a root credential issued by the trusted licensor's private key and has the public key of the next credential in the chain. Then, each intermediate voucher in the chain is mapped to the previous one in the chain.

29 S 1362872 The public key of the public key of the certificate is issued and has the public key of the next document in the chain. Finally, the voucher or licensor attached to the chain is issued by the private account of the public Jin Yu corresponding to the last voucher in the chain.

Therefore, in order to verify the certificate or license attached to the chain, the public key of the corresponding trusted licensor's private key is obtained, and the public key of the trusted licensor is used to verify the root of the chain. The signature of the voucher. Following the 'preset root voucher signature verification, the public key from the root certificate is obtained and used to verify the signature of the first intermediate voucher in the chain. The program repeats sequentially in the chain until its signatures have been verified, and then the public key from the last intermediate voucher in the chain is obtained and used to verify the signature of the certificate or license attached to the chain. It should be appreciated that the OLP credential 810 establishes a chain of trust between the content 304 to be issued offline and the DRM server 320 that issues the license for the content 34. The OLP credential 8 10 0 can be established in accordance with the XML/XrML language or other appropriate language.

It should be understood that the OLP certificate 8 1 0 and the attached voucher chain authorize the issuer to self-issue. It should be further understood that the key pair (PU-OLP, PR-OLP) is separated from (PU-ENTITY, PR-ENTITY) and used for specific self-issuance. Note that the key pair (PU-OLP, PR-OLP) can be assigned, in which case the DRM credential 810 contains only the user's public key (PU-ENTITY) and is privately funded by the DRM server 320 (PR- DRM) Release ' makes DRM Server 320 verifiable. The self-issuance is different from the distribution shown in Fig. 4 in which the user of the step basically performs the replacement of the DRM server 320. The important thing is to use 30

S 1362872 is issued with (PU-DRM (K2)) and (K2 (rightsdata)) or contains (PU-DRM (CK)) and has (PR-OLP) (CK (rightsdata)) (shown later in the The transfer permission label of Figures 7 and 8 is the same as the SRM 308 from the DRM voucher 810 (i.e., S(PR-OLP)). The trust component 18 client utilizing the OLP credential 810 is typically authenticated against the attached credential chain. It should be understood that the user's trust component 18 is obtained from the 0LP voucher 810 (PU-ENTITY (PR-OLP)) and the application (PR-ENTITY) is obtained from this OLP voucher 810 (pR-〇Lp). It is not possible to verify that DRM server 320 can implement rights to self-issued SRL 308. Accordingly, the DRM server 320 itself should perform the verification when the license is requested by the self-issued SRL 308. Once the issuing user self-issued the SRL 308, the user serially issues the self-issued SRL 308, and the OLP credential 810 is used to generate it to the content 304, and the content with the SRL 308 is the same as the DRM credential 810, such as the rights management content 310. Spread to another user. Thus, other users request and obtain a license from the DRM server 320 for the content 3 04 Π 10 in substantially the same manner as shown in Figs. 6A and 6B. Here, however, the license is required to be transmitted by the user to the DRM server 320 to serialize the self-issued SRL 3 08 and OLP credentials 8 1 0 of the content 304. The DRM server 320 then verifies S(PR-DRM) in the 0LP voucher 810 according to the corresponding (PU-DRM) and obtains (PU-OLP) from the DRM voucher 810. The DRM server 320 then verifies the S (PR-OLP) in the SRL 308 based on the obtained (PU-CERT) and continues as before. However, it is noted that since the issuing user has not verified the DRM server 320, the authority can be enforced on the SRL 308. Medium, and 31 1362872 As described above, the DRM server 320 itself should perform verification at this time. Also note that the DRM server 320 only needs to verify the S (PR-DRM) of the 〇LP voucher 8.1, since the trust itself is preset. Accordingly, the credential chain associated with the Lp voucher 810 does not need to be passed to the DRM server 320 with this 〇lp v. 8 10, unless of course the chain needs, such as, for example, if the chain itself is at least partially S (PR) The basis of -DRM).

However, it is important that the issuing user should be able to perform the currently protected content 3 0 4/3 10 without having to go to the DRM server 320 to seek a license. On the other hand, an issue user who does not need to go to the DRM server 320 according to the OLP certificate 810 to issue the content 3 04/3 1 0 must also be able to issue the license itself offline - without going to the DRM server 320, so that this The user can execute the offline distribution content 304/310»According to this, the distribution user can continue to process the self-issued content 310 without connecting to the DRM server 320.

Next, in an embodiment of the present invention, and now referring to FIG. 8, the issuing user issues an offline issuer license 820 issued by itself (PR-OLP) and based on the self-signed SRL 308, and includes the 〇LP certificate. 810 and its credential chain. The default issuance license 82 2 0 allows the licensed user to fully process the permission of the self-issued content 310, although a smaller amount of access is also allowed. The publisher license 820 can be written in the XML/XrML language or in another language 'in this case there are other DRM licenses. It should be understood that the issuer license 820 includes a content key (CK) encrypted in accordance with (PU-ENTITY), which can be obtained by the trust element 18 of the user's computer device 14 to form (PU-ENTITY (CK)). The chain of issuer license 820 is therefore from this license 820 to OLP.

32 S 1362872 Certificate 8 1 Ο ’ then returns to the root certificate from the trusted licensor, perhaps by – or multiple intermediate vouchers. Since the user's trusted component 18 presets the public key corresponding to the private account of the trusted licensor for signing the root credential, the trust element 18 can verify the issuer license 820 by its credential key itself. And after verification, it can be obtained from it (pu-ENTITY (CK)), applying (PR-ENTITY) to obtain (CK), and using (CK) for (CK(content)) causes content 304 to be executed. the goal of. As a result, the issuing user can continue to process the offline published content while maintaining offline. Next, in accordance with the above, and referring now to Figure 9, the issuing user offline issues content 304/310 and issues the native offline publisher license 820 for this content 3〇4/31. Initially, it should be understood that the content 304 is developed in an appropriate manner and encrypted in accordance with a content key (CK) (step 901), and the issuing user has appropriate information 0 (PU-DRM (CK)) and (CK (right Sdata)). The content 304 of the } establishes a permission list (step 903). Thus, the issuing user who has prepared to have the OLP credential 810 from the drm server 320 obtains the 〇Lp credential 81〇 (step 905) and returns it to the highest licensor according to its signature (r〇〇t The certificate chain of the authority will be verified (step 9〇7). It will be appreciated that this verification is actually performed by the trusted component 18 on the computer device 14 of the issuing user. Assuming that the verification is successful, then the issue user/trust element 18 (hereinafter referred to as "issuing user") is retrieved from the 0LP voucher 810 (PU_ENTITY(pR_〇Lp)), and (PR-ENTITY) is applied to (pu-ENTITY). (PR-OLP)) Obtain (PR-0LP) (step 911), and then issue an establishment authority tag having this (pR〇Lp) to establish the SRL 308 (step 913). 1362872 Thus, the issuing user serializes the SRL 308 with the 〇LP voucher 810 for generating the content 304 to form the self-issued content 310 (step 915), and the rights management content 310 can therefore be distributed to another user. However, for the release user to continue to use or execute the content 310, this release use must issue its own corresponding offline issuer license 820. Therefore, the issuing user establishes the issuer license 820 (step 9 17) by self-defining the appropriate authority data and causing (CK(rightsdata) based on the content key (CK) encryption. It is noted here that this privilege profile may be obtained from the content 309 from the SRL 308 for certain pre-sets of privilege profiles that may be granted for partial or full access to the self-issued content 310, or may be from another Source obtained. In addition to this, the issuing user encrypts the content key (CK) according to (PU-ENTITY) to form (pu-ENTITY (CK)) (step 919). This (CK(rightsdata)) and (pu-ENTITY(CK)) are then formatted into the issuer license 820 (step 921), attached with the OLP credential 810 and its credential chain (step 923) and as obtained by step 911 This issuer license 82 is issued according to (Pr〇lP) (step 925). Here, note that the combined content 3〇4 (ie (CK(content)))), the issue license 820, and the 〇LP certificate form back to the trusted Lai’s authorizer’s digital project chain is 83〇. Next, for the issuer who executes the release content 31〇, and now,... Figure 10, the release user does not need to contact the DRM server 320' but the department obtains a trusted authorization corresponding to the signature of the root certificate. The public key of the private key of the person (step 1〇〇1), verify the root certificate (step 1〇〇3), and then check the intermediate voucher in the alpha chain (step 丨〇〇5), by means of each intermediate voucher From the front core, also obtained the public key and applied to verify the signing of this voucher

S 34 1362872 chapter. Thus, (PU-DRM) from the last credential in the chain is used to verify the signature of the OLP credential 810 (ie, S(PR-DRM)) (step 1007), (PU-OLP) is obtained from the OLP credential 810 (step 1009) And this (PU-〇LP) is used to verify the signature of the issuer license 820 (ie, S(PR-〇LP)) (step 1〇1〇). Once the issuer license 820 is verified, then (CK(rightsdata)) and (PU-ENTITY(CK)) are taken from it (step 1011), and (PR-ENTITY) is used for (PU-ENTITY(CK)) ( CK) (step 1013), and (CK) for (CK (right s data)) results in permission data (step 1015). It should now be understood that the privilege data is reviewed by the trusted component 18 of the computer device 4 used for distribution to determine that the privilege data is allowed to be executed in the manner seen (step 1 〇 1 7 ), and the reliant component 18 will therefore use (CK) The ((:{:((;〇114111))) from the content 310 results in the content (step 1019), and the content is then passed to the appropriate execution application for execution (step 1021). Therefore, the 'first map' The steps actually pass the chain 830 of the digital item to the content 304 from the trusted licensor. Note that the k ray element 18 can imaginarily use (c κ) for (CKCcontent) to cause the content without first reviewing the rights data. And regardless of the permission material, which may or may not be allowed' but is trusted and constructed to actually generate the inner valley only after reviewing the permission information and satisfying the permission data of the own permission. Similarly, after having the issuer license 820, As a result, the issuing user can continue to process the offline published content 310' while maintaining offline because there is no need to contact the drm server 320. The registration and sub-registration of the DRM server is in the architecture seen in FIG. Only a single drm word processor 320 is shown. However, it is understood that this architecture may include multiple servos 1362872 320. In particular, in an embodiment of the invention, this architecture includes a distributed network of DRM feeders 320. In addition to the spirit and scope of the present invention, each DRM server 320 may have a particular function, and all DRM servers 320 may be organized in a suitable manner. For example, 'now referring to Figure 12, a particular organization may have One or more user layer DRM servers 320' issue the rights label to generate the SRL 308, issue the license 16, approve the license 32, issue the license to the user, and issue the license to the computer device! For example, each user layer DRM server 320 can be geographically assigned or can be assigned according to function or load. Otherwise, to supervise multiple user layers DRM feeder 320' organization can have one or more management Drm server 320. If necessary, 'this organization type DRM server 320 can be located behind the organization firewall. In addition to the organization type DRM server 320, there may also be a transmission organization DRM word processor 32〇 promotion The functionality of the DRM server. For example, the transport organization DRM server 320 can allow a pair of organizations to share a particular DRM content 12. The same 'network that can have the administrator drm server 320 to launch all other DRM servers 320. For example, this administrator DRM feeder 320 can supervise and maintain all drm servers 320 and provide appropriate links for all DRM word processors 320 back to the highest (root) or trusted authority (Authority) Based on the voucher chain described, this unstructured DRM word processor 320 is not located behind any organization firewall. Importantly, each d RM server 3 2 0 in the architecture of Figure 12 must prove that it is trustworthy. Therefore' should be understood by the above voucher chain, entering the architecture

36 E 1362872 After the 'each DRM server 320 is provided with a registration voucher 1310, as seen from Figure 13, importantly, and in an embodiment of the invention, the registration voucher is served by another "registered" DRM servo already in the architecture The device 32 (hereinafter referred to as "DRM-R vocabulary 32") is supplied to the drm server 320 (hereinafter referred to as the r DRM-E server 320). Equally important, the DRM_R server 3 20 is attached to the provided registration voucher 丨〇3, which is the voucher chain 1 320 containing the registration voucher 13 10 of the registration drm server 320, and the registered DRM-R word processor 320 DRM. The server 32's registration credentials m〇 and so on all return to the root DRM server 32〇. The root DRM server 32 can present a root or trusted licensor, or the credential chain 132 can extend to the root or trusted licensor. It should now be understood that 'combined registration voucher m 凭证 and voucher chain

1320 forms an OLP credential 8 10 to be provided by the registration or input drm-E server 320 to the issuer's credential chain, as shown in FIG. In an embodiment of the invention, the registration voucher 1 3 1 0 provided by the DRM-R server 320 to the DRM-E vocabulary 320 is in the form of an XrML 1.2 type certificate. As should be understood, this type of document 13 is not independently proposed by any third party 'and therefore this type of certificate 13 3 is not the owner of this voucher 1 3丨〇 presented by the third party in any order of independent guarantee . In an embodiment of the invention, the particular DRM-E server 320 learns or has reason to rely on the method of registration of the incoming DRM-E server 320 in accordance with whether or not the DRM-R server 320 is registered. If not, the DRM-E feeder 320 should verify that the DRM-R server 320 is trusted and implement the DRM architecture. If so, the DRM-E server 320 should not require verification that the DRM-R server 320 is trusted, at least not to the same extent. Therefore, 1362872 is not trusted/not aware of the DRM-R server 320 "registering the j DRM-E server 320, and knowing/trusting the DRM-R server 320" sub-register jDRM-E server 320. In general, If both are operated by the interests of the same organization, the DRM-R server 320 knows/trusts the DRM-E server 320, although the knowledge/trust can be improved from other situations without departing from the spirit and scope of the present invention. The method of registering the specific DRM-E server 320 into the architecture generally depends on whether the DRM-R server 320 is registered as an organizational or non-organized type. Thus, the non-organized DRM-R server 320 is "registered." The DRM-E server 320, and the organization type DRM-R server 320 "sub-registers" the DRM-E server 320. Registration In the embodiment of the present invention, referring now to Figure 14, the unrecognized/non-trusted DRM-R server 320 registers the DRM-E server 320 in the following manner »

Importantly, it should be appreciated that the DRM-E server 320 that wishes to be registered by the unfamiliar/untrusted DRM-R server 320 does not appear to be known by this DRM-R server 3 20. Accordingly, and in an embodiment of the invention, the DRM-E server 326 must obtain a security voucher 1330 from a third party who wishes to secure this DRM-E server 320 (step 1401). Typically, this third party is an independent credential issuing agent trusted by the DRM-R server 320 to perform this warranty, such as VERISIGN, Inc. of Mountain View, California. For example, this warranty voucher 1 3 3 0 can be in the form of a certificate like X. 5 0 9 . Note that in the DRM-R server 320, the third party relying on trust is guaranteed by the DRM-E server 320, which is any bad behavior of the DRM-E server 320. DRM-R "The trust of the milk 1,1 server 320" The degree will decrease. It should be understood and, in general, and as seen in Figure 13, the warranty voucher 1 3 here is the public key (pu-v) and the corresponding private key (pr-v), by s The first person of Lai is issued 'and can be accompanied by a credential chain to root for verification purposes. Also, as a general rule, (PR-ν) in the guarantee voucher 1330 is accessible as a DRM-E word server. 32. The method of guarantee is based on the guarantee certificate 133. For example, as seen in Figure 13, (PR-V) can be encrypted according to the appropriate disclosure. In the DRM architecture, the input DRM-E The server 320 must have a unique identification here. It should be understood that the DRM identification seems to be separated from (PU-V, PR V). Although not beyond the spirit and scope of the present invention, dRM identification can also be associated with this (PIJ-V, PR- V) Matching "According to this, in order to establish this identification, this DRM-E word processor 32" generates or obtains a new public/private key pair (pu_E,

PR-E) (step 1403). Similarly, in the drm architecture, the registration DRM-E feeder 320 should determine what entity can cancel its participation authorization. Accordingly, the DRM-E Servo 3 20 identifies each of the canceled entities in the list, perhaps in the manner in which it is disclosed (step 1405). The DRM-E server 32 should be able to establish a dRM R server 320 that registers the DRM E server with the guarantee credentials 133 obtained in step 1401. Accordingly, the DRM-E server 320 can cause the (PR-V) application from the security credential 133〇 to be encrypted (Ρυ·Ε) (pR V(pU E)) as the ownership token, or as (PR-V). The issuance (pu-e) results in (PU.E)s (pR_v) as the ownership target. In either case, the (pu v) decryption or verification name establishes the ownership of (PR_V), and thus the guarantee voucher 133〇.

S 39 1362872

Therefore, the DRM-E server 320 has the security credentials 1 330, (PU-E) and 卩11-£), the deauthorization list, and (?11-¥(?1;-已)) or (?1;-£ ) 3 (?1^) as a token of ownership. Next, to request registration, the DRM-E server 320 transmits the security certificate 133, (PU-E), the deauthorization list, and (PR-V (PU-E)) or (PU-E) S (PR- V) is taken as a ownership token to the DRM-R server 320 (step 1 409), and the DRM-R server 320 processes the DRM-E server 320 that registers this request. Note that the requirement or part thereof may be (pr-E) issued by the voucher form. In particular, the DRM-R server 320 verifies the guarantee voucher by the trusted third party and the voucher chain leading to the known root according to its signature. 3 0 (step 1411). Therefore, the DRM-R server 320 establishes the DRM-E server 320.

Guaranteed. Similarly, the DRM-R server 320 verifies by applying the (PU-V) decryption (PU-E) from the request or verifying the signature and thus establishing the ownership of the (PR-γ) and thus the warranty certificate 1330 in the request. Ownership tag (step 14 10). In addition to this, 'DRM_R server 32' performs any custom logic that must decide whether or not to approve the request (step 14丨3). This custom logic may be any suitable logic without departing from the spirit of the present invention, and may include, for example, a background check of the DRM-E server 320 and/or its operator, determining whether the DRM-E server 320 has Currently trusted components 18 and 'or operating system, etc., decide whether the DRM-E server 320 is on the cancellation list or other watch list, and so on. Assuming that the custom logic permission requirements are accepted, then, in the embodiment of the present invention, the 'DRM-R server 320 generates registration for the DHM-E server 320.

&quot;a 1310 (step) 4] 5). In particular, as seen in Figure 13, drm-R 40

C 1362872 The server 3 2 0 is incorporated into the registration voucher 1 3 1 0: - the identifier of the DRM-R server 320, such as its public key (PU-R); - the identifier of the DRM-E server 320 , such as (PU-E); - identification of the certificate from the guarantee voucher 1330 containing the trusted third party to issue, the serial number from the security document 1 3 3 0 and the licensee identified in the security certificate 1 330;

- any verification range information specifies a valid range of registration credentials 1 3 1 0, such as a date range; - a deauthorization list; • a private key according to the DRM-R server 320 corresponding to (PU-R) ( PR-R) signature; - and any other appropriate information.

This other appropriate information may include, but is not limited to, the time at which the credential is issued; the registration server allows an indication of what order of DRM activity to perform, such as, for example, all activities, only account activation, only issuing permission labels, only issuing content licenses Certificates and their combinations; and the permitted time frame for performing DRM activities. Note that the license time range is different from the current time and must be in the verification scope to recognize any verification scope that includes the registration document 1 3 1 0 in the voucher chain. In contrast, the sub-voucher's issuance time must fall within the parent voucher's license time range to perform DRM activities.

It will be appreciated that in generating registration credentials 1310, DRM-R server 320 may initially generate credential information and then allow custom logic to generate additional information or correct current information. For example, this custom logic ensures DRM-R

S 41 1362872 The feeder 320 contains appropriate information or may implement a predetermined drm architecture strategy. Of course, the signature of the registration voucher 1310 is established after any such custom logic is established. It should also be appreciated that the DRM-R server 320 attaches a voucher chain 1 320 that is passed back to the trusted highest licensor to the generated registration voucher ι 31 〇 so that the generated registration voucher 1 3 1 0 can be verified against the voucher chain 1 320 . Pay special attention such as from the registration voucher! The vouchers in the 3 3 1 1 3 3 0 will follow the registration vouchers 1 3 丨〇 and serve as a bridge to the guarantee vouchers 1 3 3 0 . Therefore, similarly, the identification mark indicates that the Drm r word processor 3 2 0 relies on the third party issuer of the guarantee certificate 1 3 3 0 to guarantee the DRM-E server 320, and the DRM-R server 320 The reliability is impaired by any bad behavior of the DRM-E server 320.

Once DRM-R server 320 successfully generates registration credentials 1310 with additional credential chain 1320, DRM-R server 320 then passes it back to the required DRM-E server 320 (step 1417), and the currently registered DRM-E The server 320 saves it in place for future use. As implied above, the (PU-E) and the corresponding (pr-e) in the registration voucher 1 3 1 0 are public/private key pairs, and the DRM-E server 320 issues a rights tag to generate the SRL 3 08, The use of the OLP certificate 810 and the participation in the DRM architecture are (PU-DRM) and (PR-DRM). According to this, the combination of the registration voucher 1310 and the voucher chain 1 320 forms a voucher chain attached to the OLP voucher 810 and the like. Sub-registration In the embodiment of the present invention' and now referring to FIG. 5, the understanding/trust DRM-R server 3 20 registers the DRM-E server 320 in the following manner. Importantly, you should understand that you want to be understood/trusted to the DRM-R server 320 1362872

The registered DRM-E server 320 should still be required to identify itself to the DRM-R server 320, as this knowledge or trust may not be complete. However, this identification requirement does not require an increase in the level of trusted third party offers, since the DRM-R server 320 does not have some knowledge/trust of the DRM-E server 320. Accordingly, and in the embodiment of the present invention, the DRM-E server 320 obtains or provides some identifiable credentials 1340 (FIG. 13), and is expected to be recognized by the DRM-R server 320, and identifies the DRM- The E server 320 satisfies the DRM-R server 320 (step 1501). If the DRM-R and the DRM-E server 320 are in the same organization, the credentials 1 340 can be organization-type credentials. For example, if the server 320 is a general network, it is like a network ID, if the server 3 2 0 is a shared general domain like a domain ID and so on. If the DRM-R and the DRM-E server 320 are not in the same organization, the credentials 1 3 40 may still be the network ID if the server 3 2 0 is a general network, and if the server 320 is a common general domain. It can still be a domain ID or the like, or can be other credentials, such as, for example, a credential issued by a third party and recognized by the DRM-R server 320.

Note that in the present case, the DRM-R server 320 does not rely on a trusted third party to sponsor the DRM-E server 320, and thus the reliability of the DRM-R server 320 is not due to any of the DRM-E servers 320. Bad behavior is weakened. However, the DRM-R server 320 will venture to understand or trust the DRM-E server 320 without actually performing this undesirable behavior.

As mentioned above, in the DRM architecture, the incoming DRM-E server 320 must have a unique identification. Here, it should be understood that the DRM identification seems to be separated from the credentials 1 3 40, although the DRM 43 £ 1362872 identification may also be consistent with the credentials 1 340 without departing from the spirit and scope of the present invention. Accordingly, to establish this identification, this drm The -E word processor 320 generates or obtains a new public/private key pair (pu_E, PR-E) (step 1 50 3). As also mentioned above, in the DRM architecture, the sub-registration DRM-E server 320 should decide which entity can cancel its participation authorization. Accordingly, the DRM-E server 320 identifies each of the cancellation entities in the list, perhaps in the manner in which it is disclosed (step 1505). Thus, DRM-E server 320 has credentials 1340, (PU-E) and (pr-e) and a deauthorization list. Next, to request sub-registration, the DRM-E server 320 transmits the credentials 1340, (PU-Ε) and the de-authorization list to the DRM-R feeder 320 (step 1 507) 'and the DRM-R server 320 processor Register the DRM-E server 320 for this request. Note that as mentioned above, the requirement or part thereof may be in the form of a certificate issued by (PR-E).

In particular, DRM-R server 320 is required by logic or resource and can be used by this verifier to verify credentials 1 340 (step 1 509). Therefore, the DRM-R word processor 3 2 0 establishes a D R based on the verified credentials 1 3 4 E - E feeder 3 2 0 to trust the recognition and obey the DRM architecture. In addition to this, as described above, the DRM-R word processor 3 2 0 performs any custom logic that must decide whether or not to approve the request (step 151). The automatic logic permission request is recognized, and then, in the embodiment of the present invention, the 'DRM-R vocabulary 320 generates a sub-registration credential 13 for the DRM-E server 320 (step 1513). In particular, as seen in Figure 13, the DRM-R server 320 is incorporated into the sub-registration credentials 131: - the identifier of the DRM-R server 320, such as its public key (PU-R); 1362872 -DRM-E server 320 identifier, such as (PU-E); - Credential 1 340 or its reference; - Any verification range information specifies the range in which the sub-registration credential 1 3 1 0 is valid, for example, 曰Period range; - deauthorization list; - signature according to the private key (PR-R) of the DRM-R server 320 corresponding to (PU-R);

- and any other appropriate information. As previously described, in generating sub-registration credentials 1310, DRM-R server 320 may initially generate credential information and then allow custom logic to generate additional information or correct current information. Similarly, the signature of the sub-registration voucher 1310 is established after any such custom logic is established. As described above, the DRM-R server 320 attaches the voucher chain 1320 leading back to the trusted highest licensor to the generated sub-registration voucher 1 3 1 0 so that the generated sub-registration voucher 1 3 1 0 can be based on the voucher chain 1 3 2 0 verification.

Note that the credentials 1 3 4 0 or their references are not particularly required, but can be included for completeness. At the same time, note that the sub-registration voucher 1310 does not contain an identification mark from the security voucher 1 3 3 0, since no guarantee voucher is required in the case of this sub-registration. Once the DRM-R server 320 successfully generates the sub-registration credential 1310 with the additional credential chain 1 3 20, the DRM-R server 320 then passes it back to the requesting DRM-E server 320 (step 1515), and the current sub-registration The DRM-E server 320 stores it in place for future use (step 1517). As described above, the (PU-E) in the sub-registration voucher 1310 and the corresponding 45 S. 1362872 (PR-Ε) are tags for use in the certificate 1 3 1 0 ! Conclusion This bow is designed to be 'anything' to complete the control and can be used to promote the document/sub-signal. For example: This permission or sub-registration must make the specific implementation clear spirit and [simplified public/private key pair, DR Μ - Ε server 3 2 0 in issuing authority to SRL 3 08, issuing OLP certificate 810 and participating The drM frame is (PU-DRM) and (PR-DRM). According to this, the combination of the sub-registration humiliation [the voucher chain 1 32 〇 is attached to the OLP certificate 810, etc.; the execution of the program required to complete the program is relatively intuitive and should be apparent to the relevant public. Accordingly, the program is not attached here. The invention can be applied to specific programs that do not go beyond the spirit and scope of the present invention. Bu Mingzhong, Digital Rights Management (DRM) and implementation architecture and methods allow or play any form of digital content, where this control is defined by the content owner/developer of this digital content. The architecture allows for control execution, especially in an office or organizational environment, etc., to define sharing between individuals or individual categories. This architecture includes the mechanism of the ‘authenticated DRM server 320 to the architecture. In the above year, the above implementation can be improved without exceeding the concept of the present invention. If a license or authority label is issued according to its authority data, it is not necessary to encrypt. Similarly, in the Request and Architecture Registration Credentials 1310, the Deauthorization List and other similar information are not required. Therefore, it is to be understood that the invention is not limited to the examples disclosed herein, but the modifications in the scope of the invention as defined by the appended claims. Single explanation]

S 46 1362872 The foregoing summary, as well as the following detailed description of the embodiments of the invention, For purposes of illustrating the invention, the illustrated embodiments are preferred. However, it should be understood that the invention is not limited to the precise arrangements and means shown. In the drawings: Figure 1 is a block diagram showing an exemplary non-limiting computer environment in which the present invention may be implemented;

2 is a block diagram showing an exemplary network environment with different computer devices that can be implemented by the present invention; FIG. 3 is a functional block diagram of a preferred embodiment of a system and method for distributing digital content in accordance with the present invention; 4 is a flow chart of a preferred embodiment of a method for managing rights management content in accordance with the present invention; FIG. 4A is a block diagram showing the structure of a rights label issued by the method of FIG. 4; A block diagram of a preferred embodiment of a system and method for managing rights management content in accordance with the present invention;

6A and 6B are flowcharts of a preferred embodiment of a method for permitting rights management of digital content in accordance with the present invention; FIG. 7 is a diagram showing a certificate issued by a DRM server to a user in accordance with an embodiment of the present invention. A block diagram allowing the user to perform offline issuance; FIG. 8 is a block diagram showing the certificate of the seventh figure in accordance with an embodiment of the present invention and the issuer license for allowing the user to perform the offline distribution of the content; A flowchart showing the execution steps of the issuance license of S' 47 1362872 Figure 8 by the issuing user in accordance with an embodiment of the present invention; FIG. 10 shows the application by the issuing user in accordance with an embodiment of the present invention. The execution steps of the distribution license obtained by the figure to execute the corresponding content flow chart; FIG. 11 is a block diagram showing the implementation structure of the example of the trust type system;

Figure 12 is a block diagram showing that a plurality of DRM servers may be present in the architecture of the present invention, wherein each (input) DRM system is issued by another (registered) server to register or sub-register the same registration credentials into the architecture; Figure 13 is a block diagram showing the registration voucher of Figure 12 and the security voucher presented in at least some examples of the input DRM server to the registration DRM server; and Figures 14 and 15 are shown in Figure 13 And the flowchart of the registration and inputting of the DRM server in Fig. 14, the key steps of the execution of the DRM server input by registering (Fig. 14) or sub-registration (Fig. 15). [Simplified description of component symbol]

10 DRM system 10a Server object 10b Server object 12 (KD (CONTENT)) 13 Content packet 14 Communication network / bus 16 License 18 Trusted component 48 £ Library clock computer environment Computer computer device Computer device object object φ Computer device processing unit system bus system memory

ROM

RAM

BIOS Operating System Application ® Other Program Module Program Data Non-Removable Non-Volatile Memory Interface Hard Disk Device Operating System Application Other Program Module

49 S program data removable non-volatile memory interface disk device suspected unless volatile disk device is suspected unless volatile disk user input interface mouse keyboard network interface area network data machine wide area network remote computer Memory storage device graphic interface GPU · Remote application image memory image interface screen output peripheral interface printing mechanism port eight

S 50 client device content preparation application encrypted digital content

DRM Client API Issued Permissions Tab Rights Management Digital Content Unencrypted Digital Content DRM Server Communication Network Offline Release Document Release License Chain Registration/Sub-Registry Document Credential Chain Guarantee Document Credential

S 51

Claims (1)

1362872 * The first call of the ^y patent case deduction year 〖丨月修正十:: '¥ patent scope τ::—Γ ::: 1. A digital rights management combined with a plurality of DRM servers performing DRM functions (Digital Rights Management, DRM) system method for registering to a DRM-E server in a system by a registered DRM-R server, such that the input DRM-E server is subjected to the system By way of confidence, the method comprises the following steps: The DRM-E server obtains a public/private key pair (PU-E, PR-E) for identifying the DRM-E server in the DRM system; The E server obtains identification by itself; the DRM-E server transmits a registration request to the DRM-R server, the request includes the provision identification and (PU-E); the DRM-R server verifies the provision Identifying; if the request is to be approved, the DRM-R server generates a digital registration voucher for the DRM-E server to register the DRM-E server to the DRM system; the DRM-R server returns The generated registration certificate to the desired DRM-E server; and the currently registered DRM-E server Depositing the returned registration voucher to an appropriate location for future use, the DRM-E server having the registration voucher can use it to issue a DRM file in the DRM system, and the registration voucher that can be used to issue the DRM file is at least partially According to (PU-E). 2. The method of claim 1, wherein the DRM-R servo 52 1362872 f server does not have an existing reference to trust the DRM-E server, the method comprising the following steps: the DRM-E server One of the acquisitions provides identification, which includes a guarantee certificate from one of the guarantors of the DRM-E server that incorporates a public key (PU_V) and a corresponding private key (PR-V). ; The DRM-E server uses (PU_E) and (pR_v) to set the ownership token to indicate that the DRM-E server owns the guarantee certificate; the DRM-E server transmits a registration request to the dRM, R server, The request includes the guarantee certificate, (PU_E) and the ownership mark; the DRM-R server verifies the guarantee certificate; The DRM-R server validates the ownership token; and if the request is to be accepted, the DRM-R server generates a digital registration certificate for the DRM-E server to register the DRM-E server to the DRM system The resulting registration certificate is based at least in part on the security certificate and (PU-E). The method of claim 2, wherein the DRM-E server is free to rely on the DRM-R server and relies on an independent credential issuing agent to obtain the warranty voucher to perform the guarantee. The method of claim 2, comprising the DRM-E server obtaining an X.509 warranty certificate. The method of claim 2, comprising the steps of: the DRM-E server obtaining a guarantee issued by the guarantor with a security certificate of 53 1362872 / and the guarantee certificate is accompanied by a known root (root) a voucher chain for verification purposes; and the DRM-R server is secured by the signature of the guarantor and the verification of the vouchers by the 4a key to establish the DRM-E word service By. 6. The method of claim 2, wherein the method comprises the following steps: The DRM-E server performs one of the following: using (pR V) encryption (PU-E) to generate (PR_V(PU-E)) as the ownership token or (PR-V) signature (PU- E) generating (PU-E)S (PR-V) as the ownership mark; The DRM-R server verifies the ownership token by applying (pu_v) from the request to decrypt (PU-E) or verify the signature to verify that the DRM-E server owns (PR_V) and thus owns the Guarantee certificate. The method of claim 2, comprising the steps of: the DRM-R server generating the registration voucher to include (pu_E) as one of the DRM-E servers identifiers to generate an identification mark to identify the guarantee And generating a signature according to the private key of the DRM-R server, whereby the identification mark of the security certificate in the registration certificate acts as a bridge connecting the one of the guarantee certificates, and displaying the DRMR server system #赖与靠 The guarantor believes that the DRM_E server is guaranteed. The method of claim 7, comprising the step of: the DRM-R server generating the registration voucher to additionally include one of the drm r servos as one of the identifiers. 54 1362872 I Replacement page 9. The method of claim 7, comprising the step of: the DRM-R server generating the registration voucher to additionally include verification range information indicating a range of validity of the registration voucher. 10. The method of claim 1, wherein the DRM-R server has an existing reference for relying on the DRM-E server, the method comprising the steps of: obtaining the DRM-E server One of itself provides an identification containing credentials recognized and expected by the DRM-R server; the DRM-E server transmits a registration request to the DRM-R server, the request including the credentials and (PU-E The DRM-R server verifies the credential; and if the request is to be accepted, the DRM-R server generates a digital registration credential for the DRM-E server to register the DRM-E server to the DRM In the system, the generated registration voucher is based at least in part on the credential and (PU-E). 1 1. The method of claim 10, comprising the steps of: the DRM-E server obtaining a credential selected from a group containing a network ID or a domain ID and by a third party Credentials issued. 12. The method of claim 10, comprising the steps of: the DRM-R server generating the registration voucher to include (PU-E) as one of the DRM-E servers identifiers, generating an identification tag To identify the credential and generate a signature based on the private key of one of the DRM-R servers. 1 3. The method of claim 12, comprising the following steps: 55 1362872 t The year, month, and day corrections for the mJ The DRM-R server generates the registration voucher to additionally include one of the DRM-R servers as the identifier. 14. The method of claim 12, comprising the step of: the DRM-R server generating the registration voucher to additionally include verification range information indicating a range of validity of the registration voucher. 15. The method of claim 1, comprising the steps of: the DRM-R server performing a background check by one of the DRM-E servers and/or its operator to determine whether to verify the request, It is determined whether the DRM-E server and/or a portion thereof currently exists, and/or whether the DRM-E server is on a cancellation list or watch list. The method of claim 1, comprising the steps of: the DRM-R server generating the registration certificate to include (PU-E) as one of the DRM-E server identifiers, and A private key of one of the DRM-R servers generates a signature. 1 7. The method of claim 16, wherein the method comprises the steps of: the DRM-R server generating the registration voucher to additionally include one of the DRM-R servers as its identifier. The method of claim 16, wherein the method includes the following steps: The DRM-R server generates the registration voucher to additionally include verification range information indicating a range of validity of the registration voucher. 1 9. The method of claim 16, wherein the method comprises the steps of: the DRM-R server generating the registration voucher to additionally include an identification mark 56 1362872 曰 correction replacement page to identify the provision identification. 20. The method of claim 1, further comprising the steps of: the DRM-R server attaching a voucher chain to the generated registration voucher, which is returned to a trusted highest authenticator (root Authority), such that the generated registration voucher can be verified according to the voucher chain. 21. The method of claim 1, further comprising the steps of: the DRM-E server identifying at least one entity in the deauthorization list 'the at least one entity having an authorization to cancel the DRM in the DRM system- E server registration, the DRM-E server transmits a registration request to the DRM-R server, the request includes the provision identification, (PU_E) and the cancellation authorization list, and if the request is approved 'the DRM- The R server generates a digital registration voucher for the DRM-E server to register the DRM-E server into the DRM system. The resulting registration voucher is based at least in part on (pu_E) and the deauthorization list. The method of claim 21 includes the following steps: The DRM-E feeding device identifies each entity in the cancellation authorization list by its public key. 23. The method of claim 21, comprising the steps of: generating, by the DRM-R feeder, the registration voucher to include (pu E) as one of the DRM-E servo theft identifiers, resulting from the request The deauthorization list' and the private key generation based on one of the DRM-R servers 57 1362872 :.〇〇. 11. 1Ί5-年月曰曰Revision replacement page One signature. 24. The method of claim 1, comprising the steps of: the DRM-R server generating an XrML registration certificate 25. A method of combining a plurality of DRM servers having a DRM function for performing DRM functions, the method for inputting a DRM-E server for registration by a registered DRM-R server In the system, the input DRM-E server is trusted in the system, and the method comprises the following steps: the DRM-E server obtains a public/private key pair (PU-E, PR-E), To identify the DRM-E server in the DRM system; the DRM-E server obtains its identification; The DRM-E server transmits a registration request to the DRM-R server, the request including the provision identification and (PU-E), the DRM-R server verifies the provision identification, and if the request is to be recognized, The DRM-E server generates a digital registration voucher to register the DRM-E server into the DRM system, and returns the generated registration voucher to the requested DRM-E server; and the currently registered DRM- The E server stores the returned registration voucher in an appropriate location for future use, and the DRM-E server having the registration voucher can use the DRM-E server to issue the DRM file in the DRM system, which can be used to register the DRM file. The voucher is based at least in part on (PU-E). 26. The method of claim 25, wherein the DRM-R 58 1362872 η Tmmm\ server does not have an existing reference for relying on the DRM-E server, the method comprising the steps of: the DRM- The E server obtains one of the provisioning identities from the vouch for the guarantor of the DRM-E server, which incorporates a public key (PU-V) and a corresponding private key (PR-V); The DRM-E server uses (PU-E) and (PR-V) to set the ownership token to indicate that the DRM-E server owns the warranty certificate; the DRM-E server transmits a registration request to the DRM- R server, the request includes the guarantee certificate, (PU-E) and the right of the authority, the DRM-R server verifies the guarantee certificate, confirms the ownership mark; and if the request is to be recognized, The DRM-E server generates a digital registration voucher to register the DRM-E server into the DRM system, the generated registration voucher being based at least in part on the security voucher and (PU-E). 27. The method of claim 26, comprising the steps of: the DRM-E server free DRM-R server trusted and relying on one of the independent credential issuing agents to obtain the warranty voucher to perform the guarantee. 28. The method of claim 26, comprising the steps of: the DRM-E server obtaining an X.509 warranty certificate. 2 9 · The method of claim 26, comprising the steps of: the DRM-E server obtaining a security certificate issued by the guarantor, accompanied by a voucher chain leading to a known root, And the DRM-R server verifies the guarantee certificate according to the signature of the guarantor and the certificate chain to establish the guarantor of the DRM-E server. 30. The method of claim 26, comprising the steps of: the DRM-E server performing one of: using (PR_V) to encrypt (PU-E) to generate (pr-v (PU- E)) as the ownership mark, or (PR-V) sign (PU-E) to generate (PU-E)S (PR-V) as the ownership mark; and the DRM-R server is used by the application The request (pu_v) to verify the ownership token 'to decrypt (pu_E) or verify the signature to confirm that the DRM-E server owns (PR_V) and thus owns the warranty certificate. 3 1 · The method of claim 26, comprising the following steps: the currently registered DRM-E server stores the returned registration certificate, which includes (PU-E) as the drm-e One of the identifiers of the server, storing the identification mark to identify the security certificate, and storing a signature according to one of the DRM-R servers, whereby the identification mark of the security certificate in the registration certificate acts as a connection One of the guarantee vouchers, and shows that the DRM-R server is trusted and relied on the guarantee to guarantee the DRM-E server. 32. The method of claim 31, comprising the steps of: 60 1362872 JOQ, —— . 牟 t tf correction replacement page 丨 the currently registered DRM-E server stores the returned registration certificate, Also included is one of the DRM-R servers that exposes the key as its identifier. 33. The method of claim 31, comprising the steps of: the currently registered DRM-E server storing the returned registration voucher, further comprising verification scope information indicating a valid range of the registration voucher . 34. The method of claim 25, wherein the DRM-R server has an existing reference to trust the DRM-E server, the method comprising the steps of: the DRM-E server obtaining one of Providing an identification comprising credentials that are recognized by the DRM-R server and expected to be recognized; the DRM-E server transmitting a registration request to the DRM-R server, the request including the credential and (PU-E), The DRM-R server verifies the credentials, and if the request is to be approved, generates a digital registration voucher for the DRM-E server to register the DRM-E server into the DRM system, the generated registration voucher Based at least in part on the credentials and (PU-E). 35. The method of claim 34, comprising the steps of: the DRM-E server obtaining a credential selected from a group, the group comprising a network ID or a domain ID, and a first The credentials issued by the three. 36. The method of claim 34, comprising the steps of: the currently registered DRM-E server storing the returned registration voucher, 61 1362872 _ Qiao· brother · 1# positive replacement page contains (PU-E) as one of the DRM-E server identifiers, stores the identification mark identifying the credential, and according to one of the DRM-R servers Record a signature. 37. The method of claim 36, comprising the steps of: the currently registered DRM-E server storing the returned registration certificate, which additionally includes one of the DRM-R servers as a public record Its identifier. 38. The method of claim 36, comprising the steps of: the currently registered DRM-E server storing the returned registration voucher, further comprising verification scope information indicating a valid range of the registration voucher . 39. The method of claim 25, comprising the steps of: the currently registered DRM-E server storing the returned registration voucher comprising one of the DRM-E servers as an identifier ( PU-E) and a signature is stored according to the private key of one of the DRM-R servers. 40. The method of claim 39, comprising the steps of: the currently registered DRM-E server storing the returned registration certificate, which additionally includes one of the DRM-R servers as its identifier Public key. 4 1. The method of claim 39, comprising the steps of: the currently registered DRM-E server storing the returned registration voucher, further comprising verification scope information indicating that the registration voucher is valid A range. 62 1362872 42. The method of claim 39, comprising the steps of: the currently registered DRM-E server storing the returned registration voucher, further comprising an identification tag to identify the proposed identification. 43. The method of claim 25, comprising the steps of: the currently registered DRM-E server storing the returned registration voucher containing a voucher for returning to one of the trusted top certifiers The chain enables the generated registration voucher to be verified according to the voucher chain. 4. The method of claim 25, further comprising the steps of: the DRM-E server identifying at least one entity in a deauthorization list, the at least one entity having an authorization to cancel the DRM system Registration of the DRM-E server, the DRM-E server transmitting a registration request to the DRM-R server, the request including the provision identification, (PU-E) and the cancellation authorization list, and If the request is approved, the DRM-R server generates a digital registration voucher for the DRM-E server to register the DRM-E server into the DRM system, and the generated registration voucher is based on at least (PU- E) and the list of deauthorizations. 4 5. The method of claim 4, comprising the steps of: the DRM-E server identifying the entities in the deauthorization list by its public key. 4 6. The method of claim 4, comprising the steps of: the currently registered DRM-E server storing the returned registration voucher, 63 1362872 ΒΟΓΠΓΤΒ-year and day correction replacement page containing ( PU-E) acts as one of the DRM-E server identifiers, stores the deauthorization list from the request, and stores a signature according to one of the DRM-R servers. 47. The method of claim 25, comprising the currently registered DRM-E server storing the returned registration voucher, which stores an XrML registration voucher. 4 8. A method of combining a plurality of digital rights management (DRM) systems having a DRM server that performs DRM functions, the method for inputting a DRM-E server for registration by a registered DRM-R server Into the system, the input DRM-E server is trusted in the system, the method comprising the following steps: the DRM-R server receives a registration request from the DRM-E server, which includes a provision identification And a public key (PU-E) with one of the DRM-E servers for identifying the DRM-E servo in the DRM system, The DRM-R server verifies the proposed identification; if the request is to be accepted, the DRM-R server generates a digital registration certificate for the DRM-E server to register the DRM-E server to the DRM system And the DRM-R server returns the generated registration voucher to the required DRM-E server, and the currently registered DRM-E server stores the returned registration voucher in an appropriate location for future use, The DRM-E server of the registration voucher can use it to issue a 64 mm file of the DRM system in the DRM system, and the registration voucher that can be used to issue the DRM file is at least partially based on (PU-E). 49. The method of claim 48, wherein the DRMR server does not have an existing reference for relying on the DRM E server, the method comprising the steps of: the DRM-R server self-contained (pu_E) And providing the identified DRM-E server connection-registration request, the provision identification including a guarantee certificate from one of the guarantors of the DRM-E server, the public key (pu_v) With a corresponding private key (PR-V), the DRM-E server has used (pu_E) and (pR V) to set the ownership token to indicate that the DRM_E server owns the guarantee certificate. The ownership token; the DRM-R server verifies the guarantee certificate; the DRM-R server verifies the ownership token; and if the request is to be accepted, the DRM-R server generates a token for the DRM-E feeder The digital registration voucher is used to register the DR E - E word processor into the DRM system. The resulting registration voucher is based at least in part on the voucher and (PU-E). 50. The method of claim 49, wherein the method comprises the steps of: the DRM-R server receiving a registration request from the DRM-E server. The DRM-R server includes a security certificate, the The DRM-R server relies on relying on an independent credential to issue an agent to perform this warranty. 65 1362872 正 deleted. 5 1 · 52. 53. 54. The method described in claim 49 of the patent scope includes the following steps: The DRM-R server contains a dr_ of a .5〇9 warranty certificate. The E server receives a registration request. The method of claim 49, comprising the steps of: the DRM-R server receiving a registration request from the DRM-E server, the certificate is issued by the guarantor and accompanied by a guide to a known root One of the credential chains guarantees the voucher for verification purposes; and the DRM-R server verifies the voucher based on the sponsor's signature and credential chain to establish the DRM-E server guarantor. The method of claim 49, wherein the DRM-E server performs one of: using (1 &gt; R - V) encryption (PU - E) to generate (PR-V (PU-E) As the ownership token, or signed (PU-E) with (pr_v) to generate (PU-E)S(PR-V) as the ownership token, the method comprises the following steps: the DRM-R server application comes from The required (PU-V) to verify the ownership token to decrypt (PU-E) or verify the signature 'to confirm that the DRM-E server owns (PR-ν) and thus owns the warranty credentials. The method of claim 49, comprising the steps of: generating, by the DRM-R server, the registration voucher to include (PU-E) as one of the DRM-E servers identifiers, generating the identification The identification mark of the guarantee certificate 'and a signature according to the private record of the DRM-R server', whereby the identification mark of the security certificate in the registration certificate serves as a bridge to the security certificate and displays the DRM- R server 66 1362872 fW Correction Replacement Page Trusted and relied on the guarantor to guarantee the DRM-E server. 55. The method of claim 54, comprising the steps of: the DRM-R server generating the registration voucher to additionally include one of the DRM-R servers as its identifier. 56. The method of claim 54, wherein the method comprises the steps of: the DRM-R server generating the registration voucher to additionally include verification scope information indicating a range of validity of the enrollment voucher. 57. The method of claim 48, wherein the DRM-R server has an existing reference for relying on the DRM-E server, the method comprising the steps of: the DRM-R server Including (PU-E) and an identified DRM-E server receiving a registration request containing credentials that are identifiable and expected to be recognized by the DRM-R server; the DRM-R server authenticating the credentials; If the request is to be accepted, the DRM-R server generates a digital registration voucher for the DRM-E server to register the DRM-E server into the DRM system, the generated registration voucher being at least partially based on the credential And (PU-E). 58. The method of claim 57, comprising the steps of: the DRM-R server receiving a registration request from the DRM-E server, the credentials included in the DRM-E server being selected from the group consisting of A group containing a network ID or a domain ID and credentials issued by a third party. 67 1362872 ▼ For 1. Day 1 On Replacement page 59. The method of claim 57, comprising the steps of: the DRM-R server generating the registration voucher to be included as one of the DRM-E servers The identifier (PU-E), generates an identification tag to identify the credential, and generates a signature in accordance with the private key of one of the DRM-R servers. 60. The method of claim 59, comprising the steps of: the DRM-R server generating the registration voucher to additionally include a public key as one of the DRM-R servers of its identifier. 61. The method of claim 59, comprising the steps of: the DRM-R server generating the registration voucher to additionally include verification scope information indicating a range of validity periods of the registration voucher. 62. The method of claim 48, comprising the steps of: the DRM-R server determining whether to approve the request by performing a background check on the DRM-E server and/or its operator Determining whether the DRM-E server and/or a portion thereof currently exists, and/or determining whether the DRM-E server is on a cancellation list or watch list. 63. The method of claim 48, comprising the steps of: the DRM-R server generating the registration voucher to include (PU-E) as one of the DRM-E servers identifiers, And a signature is generated according to the private record of one of the DRM-R servers. 64. The method of claim 63, comprising the steps of: the DRM-R server generating the registration voucher to additionally include a public key as one of the DRM-R servers of its identifier. 68 1362872 Τΰ〇. II. 16'-τ月日修正 replacement page 65. The method of claim 63, comprising the steps of: the DRM-R server generating the registration certificate to additionally include a verification range Information indicating a range of validity periods of the registration voucher. 66. The method of claim 63, comprising the steps of: the DRM-R server generating the registration voucher to additionally include an identification tag to identify the offer identification. 67. The method of claim 48, comprising the step of: generating, by the DRM-R server, at least a portion of the information in the registration voucher by using custom logic to generate the registration voucher. 68. The method of claim 48, comprising the steps of: the DRM-R server attaching the generated registration voucher to a voucher chain, which is directed back to a trusted highest certifier (root authority) ), so that the generated registration voucher can be verified according to the voucher chain. 69. The method of claim 48, comprising the steps of: The DRM-R server receives a registration request from the DRM-E server, and further includes: a deauthorization list identifying at least one entity, the at least one entity having an authorization to cancel the DRM-E server in the DRM system Registering, and if the request is to be approved, the DRM-R server generates a digital registration voucher for the DRM-E server to register the DRM-E server to the DRM system, the generated registration voucher Based at least in part on the list of cancellation authorizations. 70. The method of claim 69, comprising the steps of: 69 1362872 f 岣Ml is replacing page DRM-E acknowledgment generation step: the DRM-R server generates the registration certificate to be included as One of the server identifiers (PU-E), generates a list of rights from the request, and a private key signature in accordance with one of the DRM-R servers. 71. The method of claim 48, comprising the following DRM-R server generating an XrML registration certificate. 70