Publishing digital content within a defined universe such as an organization in accordance with a digital rights management (drm) system

Distribute digital content in a defined domain such as an organization in accordance with the data rights management (DRM) system

Cross-reference to related applications The following U.S. patent applications disclose the subject matter related to the subject matter of this application, and therefore they are included here in their entirety by reference: U.S. Patent Application No. _, which is listed in the Attorney Docket Number (attorney docket number) at the same time as the present invention. ) Filed under MSFT-1569 and titled "Publishing Digital Content Withina Defined Universe Such As an Organization in Accordance with a Digital Rights Management (DRM) System"; U.S. Patent Application No. 10/185,527, in the Attorney Abstract No. MSFT- Application under 1330 on June 28, 2002, and the title is "Obtaining a Signed Rights Label (SRL) for Digitial Content and Obtaining a Digital License Corresponding to the Content Based on the SRL in a Digital Rights Mangement System"; U.S. Patent Application No. 10/185,278, filed on June 28, 2002 under Attorney Abstract No. MSFT-1333, and titled "Using a Rights Template to Obtain a Signed Rights Label (SRL) for Digital Content in a Digtial Rights Management System"; and U.S. Patent Application No. 10/185,511, filed on June 28, 2002 under the Attorneys Abstract Number MSFT-1343, and titled "Systems And Methods For Issuing Usage Licenses For Digital Content And Services".

Technical field

The invention relates to a data rights management (DRM) system. More specifically, the present invention relates to the use of the DRM system to distribute digital content in a defined domain such as an organization, office, company, etc., so that the reproduction and use of the content can be restricted in this domain in accordance with the corresponding use or license terms.

Background technique

In terms of digital content such as digital audio, digital video, digital text, digital data, digital multimedia, etc., in which such digital content is to be distributed to one or more users, data rights management and implementation are very necessary. The digital content may be static, such as a text document, or it may be streamed, such as streaming audio/video of a live event. Typical distribution modes include tangible devices such as magnetic (floppy) disks, magnetic tapes, optical (laser) disks (CDs), etc., and intangible media such as electronic bulletin boards, electronic networks, and the Internet. When received by the user, such user reproduces or'plays' the digital content on a media player on a suitable reproduction device such as a personal computer or the like.

In one scenario, content owners or rights owners such as authors, distributors, broadcasters, etc. want to distribute such digital content to each of many users or recipients in exchange for license fees or some other fees. Then, in such a scenario, the content may be songs, albums, movies, etc., and the purpose of distribution is to generate license fees. If such content owners are allowed to choose, they may want to restrict what users can do with the digital content distributed in this way. For example, the content owner intends to restrict users from copying and redistributing such content to a second user, at least if such second user denies permission to the content owner to be time-consuming.

In addition, content owners may want to provide users with the flexibility to purchase different types of user licenses at different license fees, while at the same time enabling users to comply with the terms of whatever type of license is actually purchased. For example, content owners may want to allow distributed digital content to be played only a limited number of times, only for a certain total time, only on certain types of machines, and only on certain types of media players. Play, only played by a certain type of user.

In another scenario, for example, employees or members of an organization want to distribute such digital content to other employees or members in the organization or to other individuals outside the organization, but content developers often want to prevent Other people reproduce this content. Here, the distribution of content is very similar to sharing organization-based content in a confidential or restricted manner, as opposed to broad-based distribution in exchange for license fees or some other remuneration.

In such a scenario, the content may be document reports, spreadsheets, databases, e-mails, etc., such as those that can be communicated in an office environment, and content developers may want to ensure that the content remains in the organization or office environment and does not Reappeared by unauthorized individuals such as, for example, competitors or rivals. Once again, such content developers want to restrict what recipients can do with such distributed digital content. For example, the content owner intends to restrict users from copying and redistributing such content to a second user, at least when the content is exposed outside of the personal scope of the content allowed to be reproduced.

In addition, content developers may want to provide various recipients with different levels of reproduction rights. For example, a content developer may want to allow protected digital content to be viewable and not printable with respect to one type of individuals, and be viewable and printable with respect to another type of individuals.

However, in either scenario, after the distribution has occurred, such content owners/developers have little control even if they have control over the digital content. In fact, any personal computer includes the software and hardware required to make an accurate digital copy of such digital content, and the software and hardware required to download such an accurate digital copy to a writable magnetic or optical disk, and through a network such as the Internet The software and hardware required to deliver such accurate digital copies to any destination is particularly problematic.

Of course, as part of the transaction of distributing content, content owners/developers may require users/recipients of digital content to promise not to redistribute such digital content in an annoying way. However, such promises are easy to make and easy to break. The content owner/developer may try to prevent such redistribution through several known security devices that usually include encryption and decryption. However, to prevent appropriately determined users from not decrypting encrypted digital content, save such digital content in an unencrypted form, and then redistribute the same digital content, the possibility of its existence is very small.

Therefore, there is a need for providing data rights management (DRM) and implementing structures and methods that allow controlled reproduction or playback of any form of digital content, in which the control is flexible and the content of such digital content can be controlled Defined by the owner/developer. More specifically, there is a need for a structure that allows and facilitates such controlled reproduction, especially in an office or organizational environment, etc., in which documents are to be in a prescribed group of individuals or a category Shared among individuals.

Overview The above-mentioned needs are met at least in part by the present invention. In the present invention, the license issuer issues to the requester a digital license that allows the requester to reproduce the corresponding digital content. In the present invention, the license issuer can use a directory that includes a list of requesters, where this list includes the identifier of the requester and the identifier of each group of which the requester is a member.

The license issuer receives a request from the requester, where the request includes an identifier that identifies the requester and rights data associated with the content, and the rights data lists at least one identifier and the rights associated with it. The license issuer then finds the identifier of the requester in the directory, and from the requester identifier found in the directory, the identifier of each group of which the requester is a member is found in the directory. Compare each found requester identifier and each found group identifier with each identifier listed in the authorization data to find a match, and issue an identifier with the match to the requester The license of the permission associated with the character.

Description of the drawings

When you read in conjunction with the drawings, you will better understand the foregoing overview and the detailed description of the following embodiments of the present invention. In order to illustrate the present invention, the embodiments shown in the drawings are currently preferred. However, as should be understood, the present invention is not limited to the precise arrangements and tools shown. In the drawings: Figure 1 is a block diagram showing a typical non-limiting computing environment in which the present invention can be implemented; Figure 2 is a block diagram showing a typical network environment with various computing devices in which The present invention can be implemented; FIG. 3 is a functional block diagram of an embodiment of the system and method according to the present invention, used to distribute digital content; FIG. 4 is a flowchart of an embodiment of the method according to the present invention, used for distribution rights management Figure 4A is a block diagram showing the structure of the signed rights label generated by the method of Figure 4; Figure 5 is a block diagram of an embodiment of the system and method according to the present invention, used for license rights management Digital content; Figures 6A and 6B are a flowchart of an embodiment of the method according to the present invention, digital content used for license rights management; Figure 7 is a flow chart showing a re-issue according to an embodiment of the present invention 8 is a block diagram showing a certificate according to an embodiment of the present invention, which is issued by a DRM server to allow users to perform offline issuance; Fig. 9 is a block diagram, showing According to a permission template of an embodiment of the present invention, the information to be incorporated into a permission label is specified; FIG. 10 is a flowchart showing that according to an embodiment of the present invention, the permission template of FIG. 9 is created and based on The key steps performed when the permission template creates the signed permission label of Fig. 4A; Fig. 11 is a block diagram showing the implementation structure of an example of a trust-based system; Fig. 12 is a block diagram showing an implementation according to the present invention Example of a license issuer processing a request for a license; FIG. 13 is a flowchart showing the steps performed by the license issuer of FIG. 12 related to a directory when issuing a license; and FIG. 14 It is a flowchart showing the steps performed by the license issuer of FIG. 12 when inserting a policy into a license to be issued.

Detailed Description Figure 1 and the following discussion are intended to provide a brief summary description of a suitable computing environment in which the present invention can be implemented. However, it should be understood that handheld, portable, and all kinds of computing devices are contemplated for use in conjunction with the present invention. Although the following description is a general-purpose computer, this is only an example, and the present invention only requires a thin client with network server interoperability and interoperability. Thus, the present invention can be implemented in an environment of networked hosting services in which very few or minimal client resources are included, for example, a client device in which the client device is only used as a browser or for the World Wide Web The networked environment of the interface.

Although not required, the present invention can be implemented through an application programming interface (API) used by a developer, and/or the present invention can be included in web browsing software. The network will be described in the general context of computer-executable instructions such as program modules. Browsing software, executed by one or more computers such as client workstations, servers, or other devices. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. Generally, the functions of the program modules can be combined or distributed into various embodiments as required. Moreover, those skilled in the art will recognize that other computer system configurations can be used to implement the present invention. Other well-known computing systems, environments and/or configurations that may be suitable for use in the present invention include, but are not limited to, personal computers (PCs), automated teller machines, server computers, handheld or laptop devices, multi-processing Computer systems, microprocessor-based systems, programmable consumer electronics, network PCs, minicomputers, mainframes, etc. The present invention can also be implemented in a distributed computing environment, in which tasks are performed by remote processing devices connected through a communication network or other data transmission media. In a distributed environment, program modules can be placed in both local and remote computer storage media including memory devices.

Figure 1 thus shows an example of a suitable computing system environment 100 in which the present invention can be implemented, although as clearly explained above, the computing system environment 100 is only an example of a suitable computing system environment, not intended Any limitation regarding the scope of use or function of the present invention. Neither should the computing environment 100 be interpreted as having any dependency or requirement related to any one or combination of components shown in the typical operating environment 100.

Referring to FIG. 1, a typical system for implementing the present invention includes a general-purpose computing device in the form of a computer 110. The components of the computer 110 may include, but are not limited to, a processing unit 120, a system memory 130, and a system bus 121 connecting various system components including a system memory to the processing unit 120. The system bus 121 may be any of several types of bus structures, including a memory bus or memory controller using various bus structures, an external device bus, and a local bus. As an example, but not limited, such structures include industry standard architecture (ISA) bus, microchannel architecture (MCA) bus, enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and peripheral component interconnection (PCI ) Bus (also known as Messanine bus).

The computer 110 generally includes a variety of computer-readable media. Computer-readable media may be any available media that can be accessed by the computer 110, and includes volatile or nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer-readable media may include computer storage media and communication media. Computer storage media includes both volatile and nonvolatile, removable and non-removable media. They are based on any method and technology used to store information such as computer readable instructions, data structures, program modules or other data. Achieved. Examples of computer storage media include, but are not limited to, RAM (Random Access Memory), ROM (Read Only Memory), EEPROM (Electrically Erasable Programmable Read Only Memory), flash memory or other storage technology, CD-ROM (Compact Disk ), Digital Versatile Disk (DVD) or other optical disk storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or may be used to store desired information and any other media that can be accessed by the computer 110. Communication media generally include computer readable instructions, data structures, program modules, or other data, which are in a modulated data signal such as a carrier wave or other transmission mechanism, and also include any information delivery media. The term "modulated data signal" refers to a signal that has one or more characteristics set or changed in such a way that information is encoded in the signal. By way of example, but not limitation, communication media include wired media, such as a wired network or direct wire connection, and wireless media, such as couplers, RF (Radio Frequency), and other wireless media. Combinations of any of the above should also be included within the scope of computer-readable media.

The system memory 130 includes computer storage media in the form of volatile and/or nonvolatile memory, such as read only memory (ROM) 131 and random access memory (RAM) 132. The basic input/output system 133 (BIOS) contains basic routines that help transfer information between components in the computer 110. For example, during startup, it is generally stored in the ROM 131. The RAM 132 generally contains data and/or program modules that can be directly accessed by the processing unit 120 and/or currently operated. As an example, and not limitation, FIG. 1 shows an operating system 134, application programs 135, other program modules 136, and program data 137.

The computer 110 may also include other removable/non-removable, volatile/nonvolatile computer storage media. Just as an example, FIG. 1 shows a hard disk drive 141 that reads and writes non-removable, non-volatile magnetic media, a disk drive 151 that reads and writes a removable, non-volatile magnetic disk 152, and a removable, non-volatile A volatile optical disc 156 such as a CD ROM or other optical disc drive 155 for optical media. Other removable/non-removable, volatile/non-volatile computer storage media that can be used in a typical operating environment include, but are not limited to, tape cartridges, flash memory cards, digital versatile disks, digital video tapes, solid-state ROMs ( solidstate ROM) and so on. The hard disk drive 141 is generally connected to the system bus 121 through a non-removable memory interface such as the interface 140, and the magnetic disk drive 151 and the optical disk drive 155 are generally connected to the system bus 121 through a removable memory interface such as the interface 150.

The drives described above and shown in FIG. 1 and their associated computer storage media provide computer 110 with storage of computer-readable instructions, data structures, program modules, and other data. In FIG. 1, for example, the hard disk drive 141 is shown as storing an operating system 144, application programs 145, other program modules 146, and program data 147. Note that these components may be the same as or different from the operating system 134, application programs 135, other program modules 136, and program data 137. The operating system 144, application programs 145, other application modules 146, and program data 147 are given different numbers here to illustrate that they are different copies at a minimum. The user can input commands and information into the computer 110 through input devices, such as a keyboard 162 and a pointing device 161 commonly called a mouse, a trackball, or a touch pad. Other input devices (not shown) may include microphones, joysticks, game pads, satellite antennas, and so on. These and other input devices are often connected to the processing unit 120 through the user input interface 160 connected to the system bus, but may also be connected through other interfaces and bus structures, such as parallel ports, game ports, or universal serial bus (USB).

The display 191 or other types of display devices are also connected to the system bus 121 through an interface such as a video interface 190. A graphics interface 182, such as Northbridge, may also be connected to the system bus 121. The north bridge is a chipset that communicates with the CPU or the host processing unit 120, and assumes the communication responsibilities of the accelerated graphics interface (AGP). One or more graphics processing units (GPU) 184 may communicate with the graphics interface 182. In this regard, the GPU 184 generally includes on-chip memory, such as registered storage, and the GPU 184 communicates with the video memory 186. However, the GPU 184 is only an example of a coprocessor, and thus a variety of coprocessors may be included in the computer 110. The display 191 or other types of display devices are also connected to the system bus 121 through an interface such as a video interface 190. In addition to the display, the computer may also include other external output devices such as a speaker 197 and a printer 196, which may be connected through an output external interface 195.

The computer 110 may operate in a networked environment that is logically connected to one or more computers, such as a remote computer 180. The remote computer 180 may be a personal computer, a server, a router, a network PC, a peer-to-peer device, or other common network nodes, and generally includes many or all of the components described above with respect to the computer 110, although only the memory is shown in FIG. Equipment 181. The logical connection shown in FIG. 1 includes a local area network (LAN) 171 and a wide area network (WAN) 173, and may also include other networks. Such a network environment is common in offices, enterprise-level computer networks, corporate intranets, and the Internet.

When used in a LAN network environment, the computer 110 is connected to the LAN 171 through a network interface or adapter 170. When used in a WAN network environment, the computer 110 generally includes a modem 172 or other tools for establishing communications over the WAN 173 such as the Internet. The modem 172, which may be internal or external, may be connected to the system bus 121 through the user input interface 160 or other appropriate mechanisms. In a networked environment, the program modules described with respect to the computer 110, or a part thereof, may be stored in a remote storage device. As an example and not a limitation, FIG. 1 shows that the remote application 185 is resident on the storage device 181. It will be appreciated that the network connections shown are typical, and other methods for establishing communication links between computers can be used.

A person of ordinary skill in the art can realize that the computer 100 or other client devices can be used as part of a computer network configuration. In this regard, the present invention is suitable for any computer system with any number of applications and processes appearing on any number of storage units or volumes. The present invention can be applied to an environment with server computers and client computers configured in a network environment with remote or local storage. The present invention can also be applied to independent computing devices with programming language functions, interpretation and execution capabilities.

Distributed computing promotes the sharing of computer resources and services through direct communication between computing devices and systems. These resources and services include information exchange, high-speed buffering, and disk storage for files. Distributed computing uses network connections, allowing clients to balance their collective capabilities to benefit the entire enterprise. In this regard, a wide variety of devices can have applications, objects, and resources that can interact to include the authentication technology of the present invention for a trusted graphics pipeline.

Figure 2 provides a schematic diagram of a typical networked or distributed computing environment. This distributed computing environment includes computing objects 10a, 10b, etc., and computing objects or devices 110a, 110b, 110c, etc. These objects can include programs, methods, data storage, programmable logic, and so on. These objects may include parts of the same or different devices such as PDAs, TVs, MP3 players, TVs, personal computers, etc. Each object can communicate with another object via the communication network 14. This network can self-contain other computing objects and computing devices, which provide services for the system in Figure 2. According to one aspect of the present invention, each object 10 or 110 may contain an application program that can request the authentication technique of the present invention for a trusted graphics pipeline.

It can also be appreciated that an object such as 110c can be the host of another computing device 10 or 110. In this way, although the physical environment shown may show the connected device as a computer, such an illustration is only exemplary, and may alternatively include various digital devices such as PDAs, TVs, MP3 players, etc., software objects such as interfaces, COM Objects etc. to illustrate or describe this physical environment.

There are various systems, components, and network configurations that support distributed computing environments. For example, computing systems can be connected together through wired or wireless systems, through local networks, or widely distributed networks. Currently, many networks are connected to the Internet, which provides a wide range of distributed computing infrastructure and contains many different networks.

In the home network environment, there are at least four disparate network transmission media, each of which can support a unique protocol, such as power cord, data (wireless or wired both), voice (for example, telephone), and entertainment media (entertainment media). Most home control devices such as light switches and appliances can use power cords for connection. Data services can be used as broadband (such as DSL or cable modem) into the home, and used in the home either wireless (such as HomeRF (HomeRF) 8021.b) or wired (such as Home PNA (Home PNA), Category 5 Wire (Cat 5) or even power cord) connection, data service is accessible. The voice service can enter the home as either wired (for example, Category 3 line (Cat 3)) or wireless (for example, a cellular phone), and the voice service can be distributed by using Category 3 wiring in the home. Entertainment media can enter the home either via satellite or cable, and coaxial cables are generally used to distribute entertainment media in the home. IEEE1394 and DVI can also appear as digital interconnections for groups of media devices. All these network environments and other environments that can appear as protocol standards can be interconnected to form an internal Internet, which can be connected to the outside world via the Internet. In short, a variety of disparate sources exist for storing and transmitting data, and therefore, as it moves forward, computing devices will require methods to protect content in all parts of the data processing pipeline.

"Internet" generally refers to a collection of networks and gateways using the TCP/IP protocol suite, and is well known in the field of computer networks. TCP/IP is the acronym for "Transport Control Protocol/Interface Program". The Internet can be described as a geographically distributed system of remote computer networks interconnected by computers executing network protocols that allow users to interact and share information over the network. Because of such extensive information sharing, remote networks such as the Internet have generally been involved in open systems. For this system, developers can design software applications that perform special operations or services with basically no restrictions. program.

In this way, the network infrastructure enables the network layout of hosts such as client/server, peer-to-peer networks or hybrid structures. A "client" is a member of a class or group that uses services of another class or group that is unrelated to it. In this way, in computing, the client is a process, that is, roughly a set of instructions or tasks that request services provided by another program. The client process uses the requested service without having to "know" any operational details about other programs or the service itself. In a client/server structure, especially a networked system, the client is usually 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 considered clients, and the computers 10a, 10b, etc. can be considered servers, where the servers 10a, 10b, etc. are maintained and then copied to the client computers 110a, 110b, etc. The data.

The server is generally a remote computer accessible through a remote network such as the Internet. The client process can be activated in the first computer system, and the server process can be activated in the second computer system, communicating with each other through a communication medium, thereby providing distributed functions and allowing multiple clients to utilize the information collection capabilities of the server.

The client and server communicate with each other using the functions provided by the protocol layer. For example, Hypertext Transfer Protocol (HTTP) is a common protocol used with the World Wide Web (WWW). Generally, computer network addresses, such as Universal Resource Locator (URL) or Internet Protocol (IP) addresses, are used to mutually identify servers or client computers. The network address can be referred to as a universal resource locator address. For example, communication can be provided through a communication medium. More specifically, the client and server can be coupled to each other through a TCP/IP connection for high-performance communication.

Thus, Figure 2 shows a typical networked or distributed environment with a server communicating with client computers via a network/bus in which the present invention can be used. In more detail, according to the present invention, many servers 10a, 10b, etc. can be connected to each other through a communication network/bus 14. The network/bus 14 can be LAN, WAN, intranet, Internet, etc., with many clients or remote computing devices. 110a, 110b, 110c, 110d, 110e, etc., such as portable computers, handheld computers, thin clients, networked appliances or other equipment, such as VCR (video recorder), TV (TV), microwave oven, electric light, heater, etc. . Therefore, it is expected that the present invention can be applied to any computing device, and it is desired to combine these devices to process, store, or reproduce secure content from a trusted source.

In a network environment where the communication network/bus 14 is the Internet, for example, the server 10 may be a network server, and the clients 110a, 110b, 110c, 110d, 110e, etc. communicate with it through many known protocols such as HTTP. The server 10 can also be used as a client 110, which can be used as a feature of a distributed computing environment. Communication can be wired or wireless, as long as appropriate. The client device 110 may or may not communicate through the communication network/bus 14, and may have independent communication associated therewith. For example, in the case of TV or VCR, there may or may not be a networked aspect to control them. Each client computer 110 and server computer 10 can be equipped with various application modules or objects 135, and connect or access various types of storage components or objects, through which files can be stored or parts of files can be downloaded or moved to them . In this way, the present invention can be used with client computers 110a, 110b, etc. that can be accessed and interacted with the computer network/bus 14, as well as server computers 10a, 10b, etc. that can interact with client computers 110a, 110b, etc. and other devices 111 and database 20. .

An overview of data rights management (DRM) is as known, and referring now to Figure 11, in terms of digital content 12, such as digital audio, digital video, digital text, digital data, digital multimedia, etc., where such digital content is to be distributed to When users, data rights management (DRM) and implementation are desirable. When received by the user, such user reproduces or'plays' the digital content with the help of a suitable reproduction device such as a media player on the personal computer 14 or the like.

Generally, content owners or developers (hereinafter "owners") who distribute such digital content 12 want to restrict what users can do with the digital content 12 distributed in this way. For example, the content owner may want to restrict users from copying and redistributing such content 12 to a second user, or may want to allow the distributed digital content 12 to be played only a limited number of times and only for a certain total time. , Play only on certain types of machines, only play on certain types of media players, only play on certain types of users, and so on.

However, even if such content owners have control over the digital content 12 after the distribution has taken place, they have very little control. The DRM system 10 allows controlled reproduction or playback of any form of digital content 12, where such control is flexible and can be defined by the content owner of the digital content. Generally, the content 12 is distributed to users in the form of a package 13 via any suitable distribution channel. For example, the distributed digital content package 13 may include digital content 12 encrypted with a symmetric encryption/decryption key (KD) (ie (KD (content)), and other information identifying the content, how to obtain a license for such content and many more.

The trust-based DRM system 10 allows the owner of digital content 12 to specify license rules that must be met before such digital content 12 is allowed to be reproduced on the user's computing device 14. Such licensing rules may include the aforementioned time requirements, and may be included in a digital license or usage document (hereinafter "license") 16, the user/users computing device 14 (hereinafter, such terms are interchangeable Yes, unless otherwise required by the environment) must obtain a license from the content owner or its agent. Such a license 16 also includes a decryption key (KD) for decrypting digital content, which may be encrypted according to a key that can be decrypted by the user's computing device.

The content owner of a piece of digital content 12 must trust that the users computing device 14 will comply with the rules and requirements specified in the license 16 by the content owner, that is, the digital content 12 will not be reproduced unless the license is met. The rules and requirements in card 16. Then, preferably, the users computing device 14 is provided with a trusted component and mechanism 18, which will not reproduce the digital content 12, except as included in the license 16 associated with the digital content 12 and obtained by the user. Outside of the permission rules.

The trusted component 18 generally has a license evaluator (1icense evaluator) 20, which determines whether the license 16 is valid, checks the license rules and requirements in such a valid license 16, and based on the checked license rules And requirements, it is determined whether the requesting user has the right to reproduce the requested digital content 12 in the searched manner. It should be understood that the license discriminator 20 is trusted in the DRM system 10 to complete the owners wishes of the digital content 12 in accordance with the rules and requirements in the license 16, and the user should not be able to easily do anything illegal. Or other purposes to change such a trusted unit.

As should be understood, the rules and requirements in the license 16 can specify whether the user has the right to reproduce the digital content 12 based on any factor based on several factors, including who the user is, where the user is, and what the user uses The type of computing device, what reproduction application is calling the DRM system, date, time, etc. In addition, the rules and requirements of the license 16 may limit the license 16 to, for example, a predetermined number of plays, or a predetermined play time.

The rules and requirements may be specified in the license 16 in any suitable language and grammar. For example, the language may simply specify the attributes and values that must be met (for example, the date must be later than X), or it may require a function to be executed in accordance with a specified script (for example, if the date is greater than X, then do...).

When the license authenticator 20 determines that the license 16 is valid and the user satisfies the rules and requirements therein, the digital content 12 can then be reproduced. More specifically, to reproduce the content 12, obtain the decryption key (KD) from the license 16, and apply it to the (KD (content)) from the content package 13, to produce the actual content 12, and then actually reproduce the actual Content 12.

Distributing Digital Content FIG. 3 is a functional block diagram of an embodiment of the system and method according to the present invention for distributing digital content. The term "publishing" as used here refers to a process of application or service compliance to establish a set of permissions and conditions for a trusted entity that can publish this set of permissions for that content And conditions, and to whom those permissions and conditions can be issued. According to the present invention, the distribution process includes encrypting the digital content and associating it with a list of permanently enforceable permissions. The permanently enforceable permissions are the permissions of all possible users that the author of the content wants to use for the content. This process can be performed in a secure way to prevent access to any permissions or content unless the author of the content wants it.

In one embodiment of the present invention, specifically, three entities can be used to issue secure digital content: a content preparation application 302, which is executed on the client 300 and used to prepare content for distribution, and one A data rights management (DRM) application programming interface (API) 306 also resides on the client device 300, and a DRM server 320 is connected to the client 300 through a communication network 330 in a communication manner. In an embodiment of the present invention, the communication network 330 includes the Internet, although it should be understood that the communication network 330 may be any local area or wide area network, such as a private intranet.

The content preparation application 302 may be any application that generates digital content. For example, the application program 302 may be a word processor or other publication that generates digital text files, digital music, videos, or other such content. The content may also include streaming content, such as, for example, streaming live or audio/video of recorded events. According to the present invention, the content preparation application requests its user to encrypt the content using a key provided by the user. The application 302 uses this key to encrypt the digital content, thereby forming an encrypted digital content file 304. The client application also requests the user to provide permission data for the digital content file 304. The rights data includes a corresponding identity for each entity that has rights in the digital content.

Such an entity may be, for example, a person, a type of person, or a device. For each such entity, the rights data also includes a list of the rights that that entity has in the content, and any conditions that can be imposed on any or all of those rights. Such rights may include rights to read, edit, copy, print, etc. of digital content. In addition, permissions can be included or excluded. The contained authority means that a specified user has the authority specified in the content (for example, the user can edit the digital content). Excluded rights mean that a specified user has all rights in the content, except for those specified (for example, the user can do anything with the digital content except for copying it).

According to an embodiment of the present invention, the client API 306 can pass the encrypted digital content and rights data to the DRM server 320. Using the process described in detail below, the DRM server 320 determines whether it can implement the rights that the user has assigned, and if so, the DRM 320 signs the rights data to form a signed rights label (SRL) 308. However, generally speaking, any trusted entity can sign authority data, and it is better to use a key trusted by the DRM server 320. For example, the client can use the key provided by the DRM server 320 to sign the rights data.

The rights label 308 may include data representing a rights description, an encrypted content key, and a digital signature on the rights description and the encrypted content key. If the DRM server is signing the rights tag, it will pass the signed rights tag 308 back to the client through the client API 306, and the API 306 will store the signed rights tag 308 on the client device 300. The content preparation application 302 then associates the signed rights label 308 with the encrypted digital content file 304. For example, the SRL 308 and the encrypted digital content file are collected together to form the content file 310 for rights management.

However, in general, rights data does not need to be combined with digital content. For example, the rights data may be stored in a known location, and the reference to the stored rights data may be combined with encrypted digital content. This reference may include an identifier indicating the location where the authorization data is stored (for example, the data store containing this authorization data), and an identifier corresponding to that specific authorization data in that specific storage location (for example, the identifier contains the interested Specific permission data files). The rights-managed content 310 can then be delivered to anyone and anywhere, and only those entities with the rights to restore the content can restore the content, and only in accordance with their assigned rights.

Fig. 4 is a flowchart of a typical method 400 according to the present invention for issuing digital content for rights management, in which a rights label is signed by a DRM server. However, it should be understood that this embodiment is only exemplary, and in general, any trusted entity can sign the authority label. Generally speaking, the method for distributing digital content according to the present invention may include: encrypting the digital content using a content key (CK), generating a rights description associated with the digital content, and according to the public key (PU- DRM) to generate (PU-DRM(CK)), and create a digital signature on the rights description and (PU-DRM(CK)) based on a private key (PR-DRM) corresponding to (PU-DRM).

In step 402, the application 302 generates a content key (CK) used to encrypt the digital content. Preferably, the content key (CK) is a symmetric key, although in general, any key can be used to encrypt digital content. Symmetric key algorithms, sometimes called "secret key" algorithms, use the same key to encrypt a message when they want to encrypt the message. For that reason, it is best to keep that (CK) secret. The sharing (CK) between the sender and the receiver should be done very carefully to avoid unauthorized eavesdropping (CK). Because (CK) is shared between the encryptor and the decryptor, (CK) is best transmitted before any encrypted messages are transmitted.

Several symmetric key generation algorithms are well known in the art. In one embodiment, Data Encryption Standard (DES) is used, although it should be understood that any symmetric algorithm can be used. Examples of such symmetric key algorithms include, but are not limited, AES, Triple-DES (Triple Data Encryption Standard), International Data Encryption Algorithm (IDEA), Cast, Cast-128, RC4, RC5, and SkipJack .

In step 404, the application program 302 encrypts the digital content with a symmetric content key (CK) to form an encrypted digital content 304, which can be written using a symbol (CK (content)). The author using the application 302 can also generate permission data associated with the digital content. This rights data can include a list of entities that will be authorized to restore the content, as well as the specific rights that each entity has with respect to the content, along with any conditions that can be imposed on those rights. Such rights may include viewing content, printing content, and the like, for example. The application 302 provides permission data for the API 306. An example of permission data in XML/XrML format is attached here as Appendix 1.

In step 406, the API 306 generates a second encryption key (DES1), which can be used to encrypt the content key (CK). The best (DES1) is also a symmetric key. In step 408, API 306 encrypts (CK) with (DES1) to generate (DES1(CK)). In step 410, API 306 discards (CK), because now the result of (CK) can only be obtained by decrypting (DES1(CK)). To ensure that (CK(content)) is protected by the central DRM server 320 and complete all "licensing requests" for content in accordance with the authority data in the central, API 306 in step 412 contacts the provided DRM server 320 and retrieves its public Key (PU-DRM). In step 414, API 306 encrypts (DES1) with (PU-DRM) to generate (PU-DRM(DES1)). In this way, (CK) can be protected by (PU-DRM) to ensure that DRM server 320 is the only entity that can gain access to (CK) in the future, as required for decryption (CK (content)). In step 416, the API 306 encrypts the permission data (ie, a list of authorized entities and the corresponding permissions and conditions associated with each authorized entity in this list) with (DES1) to generate (DES1 (Permission Data)).

In an alternative embodiment, (CK) can be used to directly encrypt rights data to generate (CK (rights data)), and (PU-DRM) can be used to directly encrypt (CK) to generate (PU- DRM (CK)), thus completing the use of the aforementioned (DES1). However, the use of (DES1) to encrypt permission data and (CK) allows such (DES1) to comply with any specific algorithm that may obey the DRM server, however (CK) may be specified by an entity independent of the DRM server and may not obey the DRM server .

In step 418, the content preparation application 302 may submit (PU-DRM (DES1)) and (DES1 (right data)) to the DRM server 320 as a right label for signing. Alternatively, the client itself can sign the authorization data. If the authority data is being submitted to the server for signing, then in step 420, the DRM server 320 accesses the authority data and verifies that it can implement the authority and conditions in the submitted authority label. To verify that it can implement authority data, the DRM server 320 applies (PR-DRM) to (PU-DRM(DES1)) to generate (DES1), and then applies (DES1) to (DES1 (authority data)) to generate Permission data of the password. The server 320 may then conduct any policy checks to verify that the users, permissions, and conditions specified in the permissions data are within any policies implemented by the server 320. The authorization label originally submitted by the server 320 including (PU-DRM (DES1)) and (DES1 (authority data)) to generate a signed authorization label (SRL) 308, in which the signature is based on the private key of the DRM server 320 ( PR-DRM) and return the SRL308 to the API306, and the API306 then provides the returned SRL308 to the client application 302.

SRL308 is a digitally signed document, making it tamper-proof. In addition, SRL308 is independent of the actual key type and algorithm used to encrypt the content, but maintains a 1-1 relationship with the content it is protecting. Referring now to FIG. 4A, in an embodiment of the present invention, SRL308 may include information about content, which is the basis of SRL308, and may include a content ID (identifier); information about the DRM server that signed this SRL308, Including (PU-DRM (DES1)) and referral information (referral information) such as the URL used to locate the DRM server on the network and the return information when this URL fails; information describing the SRL308 itself; (DES1 (authority data)); (DES1(CK)); and S(PR-DRM) among them. The XML/XrML example SRL308 is attached here as Appendix 2.

By ensuring that a trusted entity signs the rights data to create a signed rights tag 308, the DRM server claims that it will issue a license for the content in accordance with the terms stated in the rights data in the rights tag 308 by the issuer. As should be appreciated, the user is required to obtain a license to reproduce the content, especially because the license contains a content key (CK). When a user wants to obtain a license for encrypting content, the user can provide a license request to the DRM server 320 or other license issuing entity. The request includes a rights tag 308 for signing the content and verification. The certificate of the user's credential. The license issuing entity can then decrypt (PU-DRM (DES1)) and (DES1 (Permission Data)) to generate permission data, and list all permissions granted by the author (if any) to the license requesting entity Words), and construct a license with only those specific permissions.

Preferably, when the application program 302 receives the SRL 308, such an application program 302 centralizes the signed permission label 308 and the corresponding (CK (content)) 304 to form the digital content for permission management. Alternatively, the rights data can be stored in a known location, with a reference to that location provided for encrypted digital content. In this way, the DRM-permitted reproduction application can discover the signed rights label 308 from the piece of content that is trying to be reproduced through the reproduction application. This discovery triggers the reproduction application to initiate a license request to the DRM license server 320. The issuing application 302 can store a URL pointing to the DRM license server 320, for example, or the DRM license server 320 can embed its own URL as a piece of metadata into the rights tag before digitally signing the rights tag, so The DRM client API 306 called by the reproduction application can identify the correct DRM license server 320. Preferably, before signing the permission label, a unique identifier, such as a globally unique identifier (GUID), is placed in the permission label.

In one embodiment of the present invention, a simple object access protocol (SOAP) can be used for communication between the content preparation application 302 or the reproduction application and the DRM server 320. In addition, an API library such as API306 can be provided, so applications such as application 302 are not required to implement the client of the DRM protocol, but only local API calls can be made. Preferably, XrML, an XML language, is used to describe rights descriptions, licenses and rights tags for digital content, although it should be understood that any suitable format can be used for rights descriptions and other data.

Obtaining a License for Distributed Content FIG. 5 is a functional block diagram of an embodiment of the system and method according to the present invention, which is used to license digital content for rights management. "Licensing", as the term used here, refers to the process of requesting and receiving a license that an application or service complies with. The license will enable an entity specified in the license to be able to comply with that specified in the license. The terms restore content. The input to the licensing process may include a signed rights label (SRL) 308 associated with the content for which the license is being requested, and the public key certificate of the entity for which the license is being requested. Note that the entity requesting the license does not need to be the entity for which the license is being requested. Generally, the license includes a permission description from SRL308, an encryption key capable of decrypting encrypted content, and a digital signature on the permission description and the encrypted key. The digital signature asserts that the specified entity and authority are legal.

A method for the application program 302 to restore the rights management content 310 is that the client API 306 transmits the rights label 308 signed by the rights management content 310 to the DRM server 320 through the communication network 330. The location of the DRM server 320 can be found in the reference information in the SRL308, for example. In such an embodiment, the DRM license server 320, through the process described in detail below, can use the rights description in the rights tag to determine whether it can issue a license, and if so, export the rights description to include the license.

As described above, the rights tag 308 contains the content key (CK) (ie (PU-DRM(CK))) encrypted in accordance with the public key (PU-DRM) of the DRM server 320. In the process of issuing the license, the DRM server 320 securely decrypts this value to obtain (CK). Then it uses the public key (PU-ENTITY) in the public key certificate to re-encrypt (CK) (ie (PU-ENTITY(CK))), and the public key certificate is passed upward in the license request. The re-encrypted (PU-ENTITY (CK)) is the content that the server 320 puts in the license. In this way, the license can be returned to the caller without the risk of exposing (CK), because only the holder associated with the private key (PR-ENTITY) can recover from (PU-ENTITY (CK)) (CK). The client API 306 then uses (CK) to decrypt the encrypted content to constitute the decrypted digital content 312. The client application 302 can then use the decrypted digital content 312 in accordance with the rights provided in the license.

Alternatively, for example, a client such as the issuing client can issue its own license to restore the content. In such an embodiment, the protected process can run on the client computer to provide the client with the keys needed to decrypt the digital content in a suitable environment.

6A and 6B provide a flow chart of an embodiment of a method 600 according to the present invention, which is used to license digital content for rights management. According to the present invention, the requesting entity can submit a license request representing one or more possible license holders. The requesting entity may/may not be one of the possible license holders. A possible license holder can be a person, a group, a device, or any other entity that can restore content in any way. The method 600 will now be described with reference to an embodiment. In this embodiment, the DRM server processes the license request, although it should be understood that the license request processing can be performed on the client, and the client can issue the license directly.

In step 602, a license issuing entity such as a DRM server, for example, receives a license request. Preferably, the license request includes a public key certificate or identity for each of the one or more requested license holders.

In step 604, the requesting entity (ie, the entity that generated the license request) is authenticated. According to an embodiment of the present invention, the license issuing entity may be configured to use protocol (for example, challenge-response) authentication to determine the identity of the requesting entity, or it may be configured to not require authentication of the requesting entity (also Known as "allowing anonymous authentication"). When authentication is required, any type of authentication scheme can be used (for example, the challenge-response scheme mentioned above, user-id-and-password schemes such as MICROSOFT.NET, PASSPORT, WINDOWS authorization, x509 Wait). Preferably, both allow anonymous authentication and support any protocol authentication scheme supported by the integrated information system. The result of the authentication step will be an identity, such as, for example, an "anonymous" identity (for anonymous authentication), or a personal account identity. If the license request cannot be authenticated for any reason, an error is returned and the license is not granted.

In step 606, the entity authorized to authenticate determines whether the entity authenticated in step 608 is allowed to request a license (either for itself or on behalf of another entity). Preferably, the license issuing entity stores a list of entities that are allowed (or not allowed) to request licenses. In one embodiment, an identity in the identity list is the identity of the entity making the request, not the identity of the entity for which the license is being requested, although it may be either. For example, individual account identities may be allowed to directly generate license requests, but a trusted server process may generate license requests on behalf of such an entity.

According to the invention, the license request can include a public key certificate or identity for each possible license holder. If a license is requested for only one license holder, only one certificate or identity is specified. If a license is requested for multiple license holders, then each possible license holder can be assigned a certificate or identity.

Preferably, the license issuing entity has a public key certificate for each valid license holder. However, the application 302 may want to generate a license for a given user, but the application 302 cannot access the public key certificate for that user. In such a case, the application 302 can specify the identity of the user in the license request, and as a result, the license issuing entity can call the registered certificate plug-in module, which performs a search in the directory service and returns the appropriate public Key certificate.

If in step 608, the issuing entity determines that the public key certificate is not included in the license request, then the issuing entity uses the specified identity to search for the appropriate public key certificate in the directory service or database. If in step 610, the issuing entity determines that the certificate is in the directory, then in step 612, the certificate is retrieved. In one embodiment, the certificate plug-in is used to retrieve the public key certificate from the directory service via the directory access protocol. If neither in the request nor in the directory can find a certificate for a given possible license holder, then the license server does not generate a license for that possible license holder, and in step 614, Return an error to the requesting entity.

Assuming that the license issuing entity has a public key certificate for at least one possible license holder, then in step 616, the issuing entity verifies the authenticity of the license holder certificate. Preferably, configure the issuing entity with a set of trusted certificate issuer certificates, and determine whether the issuer of the license holder certificate is in the trusted issuer list. If in step 616, the issuing entity determines that the issuer of the license holder certificate is not in the trusted issuer list, then the request for that license holder fails, and an error is generated in step 614. In this way, any possible license holders that a trusted issuer does not issue its certificate will not receive the license.

In addition, the issuing entity preferably performs digital signature verification on all digital signatures in the certificate chain, from the trusted issuer certificate to the public key certificate of the individual license holder. The process of verifying digital signatures in a chain is a well-known algorithm. If the public key certificate for a given possible license holder is not verified, or a certificate in the chain is not verified, then the possible license holder is not trusted and therefore not that Potential license holders issue certificates. Otherwise, in step 618, the certificate may be issued. This process is repeated in step 620 until all entities that have requested a license have been processed.

As shown in FIG. 6B, the license issuing entity proceeds to verify the signed rights tag 308 received in the license request. In one embodiment, the issuing entity may use the authorization tag plug-in and a back-end database that stores a master copy of each authorization tag signed by the issuing entity on the server. Permission tags are identified by GUIDs placed in them at the time of release. At the permission time (at step 622), the issuing entity parses the permission tag input in the license request and retrieves its GUID. It then passes this GUID to the authorization tag plugin, which issues a query to the database to retrieve a copy of the master authorization tag. This master authority tag may be more than a copy of the authority tag sent in the license request until now, and it will be the authority tag used in the request in the following steps. If the authorization tag is not found in the database based on the GUID, the issuing entity checks its policy in step 624 to determine whether it also allows the issuance of a license based on the authorization tag in the request. If the policy does not allow this, the license request will fail in step 626, and an error will be returned to API 306 in step 628.

In step 630, the license issuing entity verifies the authority label 308. Verify the digital signature on the authority label, and if the license issuing entity is not the issuer of the authority label (the entity that signed it), then the license issuing entity determines whether the issuer of the authority label is another trusted entity (for example, An entity that enables the license issuing entity to share key material with it). If the permission tag is not verified, or it is not issued by a trusted entity, then the license request fails in step 626, and an error is returned to API 306 in step 628.

After all verifications have occurred, the license issuing entity translates the rights label 308 into a license for each approved license holder. In step 632, the license issuing entity generates a corresponding permission description for the license to be issued to each license holder. For each license, the issuing entity verifies the identity specified in the public key certificate of that license holder against the identity specified in the permission description in the rights label. Permission description assigns a group of identities to each permission or permission group, and the group of identities can exercise the permission or group of permissions in a license. For each permission or permission group associated with the identity of this license holder, that permission or set of permissions is copied into a new data structure for this license. The resulting data structure is the description of the permissions in the license for the specific license holder. As part of this process, the license issuing entity identifies any prerequisites, which may be associated with any rights or rights groups in the rights description of the rights tab. For example, a right may have a time prerequisite associated with it, which restricts the license issuing entity from issuing a license after a specified time. In this case, the issuing entity will need to check the current time, and if the time specified in the prerequisites has passed, the issuing entity will not be able to issue that authority to the licensee, even if the license holder The identity of is associated with that permission.

In step 636, the issuing entity obtains (PU-DRM(DES1)) and (DES1(CK)) from the rights tag 308 and applies (PR-DRM) to obtain (CK). The issuing entity then uses the public key certificate of the (PU-ENTITY) license holder to re-encrypt (CK) to generate (PU-ENTITY(CK)). In step 638, the issuing entity integrates the generated authority description with (PU-ENTITY (CK)), and uses (PR-DRM) to digitally sign the resulting data structure. This signed data structure is used for the license of this particular license holder.

When the issuing entity determines in step 640 that there are no more licenses to be generated for a particular request, it will have generated zero or more licenses. In step 642, the generated licenses are returned to the requesting entity, along with the certificate chains associated with those licenses (for example, the server's own public key certificate and the certificate that issued its certificate, etc.).

In one embodiment of the system according to the invention, multiple license issuer keys may be used. In such an embodiment, the content key (CK), which is encrypted and propagated through the rights tag 308 and sent to the license holder, can actually be any arbitrary data. A particularly useful change is the use of a set of independent, encrypted content keys (CK) that are respectively associated with different rights or different principles in the rights description. For example, data versions of songs in a songbook can all be encrypted with different keys (CK). These keys (CK) can be included in the same authority tag, but a principle can have the authority to play one of the songs (for example, he may only have the authority to obtain one key in his license), and The second principle may have the authority to play all songs (she may have the authority to obtain all keys in her license).

Preferably, the system according to the present invention enables the issuing application/user to specify the group or class of license holders in the rights tag 308. In such an embodiment, the license issuing entity will authenticate any groups/categories specified in the rights tag to determine whether the current license holder identity is a member of those group categories. If membership is found in the designated group/class, the issuing entity may add the authority or authority group associated with the group/class to the authority description data structure for the license holder.

In an embodiment of the present invention, the publish and license protocol interface in the DRM server supports the authentication and authorization of calling applications or users, and an administrative console (administrative console) for the DRM server Allows the administrator to generate an access control list for both the licensing and issuing interfaces. This enables clients of the server to apply policies, which allow users/applications to be issued or licensed, or both.

Modifying or re-issuing the signed rights label 308 In one embodiment of the present invention, the SRL 308 can be "republished" if the user who has granted the content has sufficient permission to do so. In other words, if allowed, the user can change the permission data in SRL308. Note that the permission to change the permission data should be granted carefully and deliberately, especially because a user with permission to change the permission data can basically grant himself a wide range of permissions related to the associated content. As you can imagine, such a user can even grant itself the right to expose content and deliver the same content to the world.

Here, the permission to change is indicated by including a flag in the permission data in the SRL 308, which indicates that a specific user or user class can actually change or'reissue' the permission data and the permission label 308. When the DRM server 320 receives the SRL 308 with such a license related to the request for a license, the DRM server 320 includes a symmetric secret encrypted according to the user's public key (ie PU-ENTITY) in the license requested by the user. Key (DES1) to generate (PU-ENTITY(DES1)).

In this way, to edit the authority data in SRL308, and now turning to Figure 7, the user retrieves (PU-ENTITY(DES1)) from the license (step 701), applies (PR-ENTITY) to it to generate (DES1)( Step 703), retrieve (DES1 (authorization data)) from SRL308 (step 705), and apply (DES1) to it to generate authorization data (step 707). After that, the user changes the authority data as needed (step 709), and submits the changed authority data to the DRM server 320 in the manner described in conjunction with FIG. 4 to obtain the signed authority label 308 (step 711). Of course, here, the signed permission label 308 is actually a reissued SRL308, and therefore once the SRL308 is received (step 713), the user strips off the original SRL308 concentrated in the associated content (step 715), and then The reissued SRL308 is integrated into such content (step 717).

In this way, and cognizably, re-issuing the SRL308 enables users to update the permission data in the SRL308, including permissions, conditions, or users, without having to change the associated content. Specifically, re-distribution does not require re-encryption of the associated content with a new (CK). Moreover, the reissue does not require a new SRL to be generated from scratch, especially because the original SRL308 has many clauses in it, which can be copied to the new SRL308.

Self-issued and signed authority label 308

In an embodiment of the present invention, the SRL308 can be signed by the user himself. Therefore, the user does not need to contact the DRM server 320 to obtain the SRL 308 for a piece of associated content. As a result, self-distribution can also refer to offline distribution. In such an embodiment, the user may be required to contact the DRM server 320 to request a license based on such a self-issued SRL308. It should be understood that the issuing entity may be able to issue its own license.

Specifically, and referring now to FIG. 8, in the embodiment, the user is first provided with self-issuance by receiving a DRM certificate from the DRM server 320. The DRM certificate includes a public key (PU-CERT) and a public key according to the user. (PU-ENTITY) encrypted corresponding private key to generate (PU-ENTITY(PR-CERT)). This certificate should be signed by the private key (PR-DRM) of the DRM server 320, so the DRM server 320 can verify that it is completely consistent, which will be discussed in more detail below. As can be appreciated, the DRM certificate 810 authorizes the user to self-issue. As can also be realized, the key pair (PU-CERT, PR-CERT) is separate from (PU-ENTITY, PR-ENTITY), and is specifically for self-issued use. Note that there is no key pair (PU-CERT, PR-CERT). In this case, the DRM certificate 810 only includes the user's public key (PU-ENTITY), and the private key (PR-DRM) of the DRM server ) Signing, such DRM server 320 can also verify that they are completely consistent.

The self-publishing is different from the distribution as shown in FIG. 4 in that the user basically replaces the steps performed there related to the DRM server 320. It is worth noting that the user signs the submitted authorization label including (PU-DRM (DES1)) and (DES1 (authority data)) with the (PR-CERT) obtained by the DRM certificate 810 to generate a signed authorization label (SRL) ) 308. As should be appreciated, the user obtains (PU-ENTITY (PR-CERT)) from such a DRM certificate 810 and applies (PR-ENTITY) to it, and obtains (PR-CERT) from the DRM certificate 810. Note that although the user cannot verify that the DRM server 320 can enforce the rights in the submitted rights tag, especially because the user does not have (PR-DRM) to be applied to (PU-DRM(DES1)). Therefore, when requesting a license based on the self-issued SRL 308, the DRM server 320 itself should perform verification.

Once the user self-issues the SRL308, the user collects the self-issued SRL308 and the used DRM certificate 810 to generate the same content as the content, and distributes such content with the SRL308 and the DRM certificate 810 to another user. Thereafter, other users request and obtain a license for content from the DRM server 320 in substantially the same manner as shown in FIGS. 6A and 6B. Here, however, the license request user submits both the self-issued SRL 308 and the DRM certificate 810 as concentrated in the content to the DRM server. The DRM server 320 then verifies the S(PR-DRM) in the DRM certificate 810 based on the corresponding (PU-DRM), and obtains (PU-CERT) from the DRM certificate 810. The DRM server 320 then verifies the S (PR-CERT) in the SRL 308 based on the obtained (PU-CERT), and continues as before. Note, however, that since the user has not verified that the DRM server 320 can implement the authority in the SRL 308, as explained above, the DRM server 320 itself should perform this verification at this time.

The permission template is as described above, by defining users or user classes, defining permissions for each defined user or user class, and then defining any usage conditions, providing users with most of any kind of permission data in the permissions tab freedom of. However, it is worth noting that repeatedly defining permission data for multiple permission tags is annoying and repetitive, especially when the same user or user class, permissions, and conditions are repeatedly defined for different pieces of content. Such a situation can occur, for example, in a company or office environment, when users repeatedly publish different pieces of content to be shared by a specifically defined user team. Therefore, in such a case, and in an embodiment of the present invention, an authorization template is created, where the authorization template already includes a predefined user group or user class, and a predefined user or user class for each defined user or user class. The user can use the permission template repeatedly when creating permission labels.

In one embodiment of the present invention, and now turning to FIG. 9, the rights template 900 has essentially the same rights data as will be in the rights tag. However, since (DES1) is not known, the rights data cannot be encrypted according to this (DES1) until the content is released, as is the case in the rights tag. In an embodiment of the present invention, then, during step 416 of FIG. 4 during the encryption of the right data with (DES1), the right template 900 with unencrypted right data is submitted to generate (DES1 (right data)) . Of course, before such encryption, the permission data is retrieved from the submitted permission template 900.

This may or may not be the case, that is, when the rights template is constructed, the DRM server 320 and its public key (PU-DRM) are known. In addition, even if it is known, this may or may not be the case, that is, there is more than one DRM server 320, each with its own (PU-DRM). However, when the DRM server 320 and its public key (PU-DRM) are known when constructing the rights template, and when only one DRM server 320 is used, or only one DRM server 320 should be used in conjunction with the rights template 900 In this case, such a rights template may also include information about the DRM server, and the DRM server is to sign the rights label obtained from the rights template 900, including its public key (PU-DRM). Although such (PU-DRM) appears in SRL308 as encryption (DES1) to generate (PU-DRM(DES1)), it is necessary to realize again that (DES1) is not known until the content is released, and therefore in the rights template The (PU-DRM) in 900 cannot encrypt such (DES1), as is the case in the authority tag. Then, in an embodiment of the present invention, during the encryption (DES1) with (PU-DRM) in step 414 of FIG. 4, the permission template 900 with unencrypted (PU-DRM) is submitted to generate (PU-DRM). -DRM(DES1)). Of course, before use, it is retrieved from the submitted permission template 900 (PU-DRM).

Also in the above case, other information about the DRM server that can be included in the rights template can also include reference information, such as the URL used to locate the DRM server on the network, and information returned if the URL fails. In any case, the rights template may also include information describing the rights template 900 itself. Note that the rights template 900 can also provide space for information related to the content to be distributed, such as the information appearing in the rights tags related to the content and/or encryption keys (CK) and (DES1), although if the rights are changed The instantiation of the template is actually converted to the permission tag, and such space is unnecessary.

Although the permission template 900 disclosed so far is mainly for the convenience of the user, it should be realized that in some environments, the user should not have unlimited freedom to define permission data in the permission tag, and the permission template 900 can be used. Restrict the scope or type of permission tags that can be created. For example, and especially in the case of a company or office environment, it can be pre-defined as a policy that a specific user should always only distribute content to a specific class of users or the user should never distribute content to a specific class of users . In any case, and in an embodiment of the present invention, such a policy is included as permission data in one or more permission templates 900, and users can be restricted from using such permission templates to create permission tags when publishing content. . It is worth noting that a permission template 900 or a group of permission templates 900 that can be used by a user to specify a distribution policy for the user can specify any special type of distribution policy without departing from the spirit and scope of the present invention.

To specify the authorization template 900 for restricted users, etc., and now turning to FIG. 10, the administrator, etc. actually pass the predefined authorization data (step 1001), and define any other data that may be necessary and appropriate, For example, information related to a specific DRM server 320 is related (step 1003), and a rights template 900 is constructed. It is worth noting that to complete the permission template used by restricted users, etc., the permission template 900 must be made official. In other words, the permission template 900 must be identifiable as a permission template that can be used by a restricted user and so on. Therefore, in one embodiment of the present invention, a rights template constructed by a manager or the like is submitted to the DRM server 320 for signing by it, where such signing makes the rights template official (step 1005).

Note that if such information actually exists in the rights template 900, the signed DRM server 320 is the DRM server 320 whose information is in the rights template 900. Also note that the DRM server 320 may only sign the rights template 900 when performing any necessary checks, or may sign the rights template 900 without any checks at all. Finally, note that the template signature S(PR-DRM-T) from the DRM server 320 (at this time -T means the signature for the ORT (official rights template) 900), it should be based on at least the predefined in the rights template 900 The permission data can also be based on other information without departing from the spirit and scope of the present invention. As described below, the signature S (PR-DRM-T) is incorporated into the rights tag, and this signature is verified in conjunction with the rights tag, and therefore no matter what the signature is based on, it should be incorporated into the rights tag in an unaltered form.

When the DRM server 320 signs the rights template 900 and returns it to the manager, etc., the manager receives the signed and now official rights template 900 with S(PR-DRM-T) (step 1007), and The formal rights template (ORT) 900 is transmitted to one or more users who use it (step 1009). Therefore, for a user who distributes content based on ORT900, the user retrieves ORT900 (step 1011) and provides any required information, such as information about the content; appropriate key information; encrypted by (DES1) to generate (DES1 (Authority data)) The authority data from ORT900; and any other information from ORT900, the authority label is constructed based on ORT900 (step 1013). Notably, the user also includes the signature S (PR-DRM-T) from ORT900 with the authorization tag.

Thereafter, and as before, the user submits the authorization label to the DRM server 320 for signing (step 1015). Here, however, the DRM server 320 will not sign the submitted authority tag unless confirmed by the S(PR-DRM-T) in it. That is to say, the DRM server 320 refuses to sign the submitted permission label, unless the submitted permission label includes the signature S (PR-DRM-T), and the implementing user must base the submitted permission label on ORT900. Specifically, the DRM server 320 retrieves the S (PR-DRM-T) and whatever information the signature is based on from the submitted authority tag, and then verifies such a signature based on the (PU-DRM). Note that the rights data in the submitted rights label is encrypted according to (DES1) (ie (DES1 (right data)). Therefore, the DRM server 320 must first obtain (DES1) and use it to decrypt (DES1 (right data)), As described in conjunction with FIG. 7, it is necessary to be able to verify the signature based on the authorization data in the submitted authorization tag.

Once verified, the DRM server 320 signs the submitted rights label with S(PR-DRM-L) to generate SRL308, as before (here -L means that the signature is for SRL308). Here, S(PR-DRM-L) may replace S(PR-DRM-T), or may be added to S(PR-DRM-T). If attached, S(PR-DRM-L) may be based in part on S(PR-DRM-T). Note that (PR-DRM) can be used to generate both S(PR-DRM-T) and S(PR-DRM-L), or a different (PR-DRM) can be used for S(PR-DRM-T) And each of S(PR-DRM-L). When the DRM server 320 signs the authority label and returns the SRL308 to the user, the user receives the SRL308 with S (PR-DRM-L) (step 1017) and proceeds to concentrate the former on the content being issued, as before.

If the signature S (PR-DRM-T) of ORT900 is based at least in part on the permission data predefined in ORT900, then such permission data cannot be modified when it appears in SRL308 (in DES1 (permission data)) Or change. Otherwise, S(PR-DRM-T) will not be able to verify. However, in one embodiment of the present invention, the authority data in the ORT 900 can be changed within the prescribed rules also included in the ORT 900. For example, these rules may specify one of the two permission data sets to be included in SRL 308, or may allow selection from a set of selection objects. As can be appreciated, these rules can be any specific rules set forth in any suitable grammar without departing from the spirit and scope of the present invention. Here, when creating a permission label, a suitable rule interpreter will interpret the rules for the user. Although the rights data can vary, the rules are not the same, and therefore the template signature S (PR-DRM-T) used for ORT900 is based at least in part on the rules and not on the rights data itself. As a result, rules included with ORT900 must also be included with SRL308.

In an embodiment of the present invention, the authority data predefined in the ORT 900 is partly fixed and unchanging, and partly variable and rule-driven, as described above. Here, the template signature S (PR-DRM-T) for ORT 900 is based at least in part on the fixed part of the rule and the rule based on the variable part of the rights data.

As can be appreciated, the ORT900 as owned by the user may become obsolete or invalid. In other words, ORT900 can reflect policies that have become obsolete, irrelevant, or simply no longer applicable through the permission data in it. For example, one or more users or user classes specified in the permission data of ORT900 may no longer exist in the policy environment, or a specific user or user class specified in the permission data of ORT900 may no longer exist in the policy environment Have the same permissions. In this case, it may be that the administrator has released a modified ORT900, but the user is still using the previous, invalid version of ORT900.

In this case, and in an embodiment of the present invention, then, the DRM server 320 retains a copy of the ORT 900 when signing the submitted permission template 900 to create an ORT 900, and each ORT 900 has a unique identification mark based on An ORT900 including such an identification mark of the ORT900 constructs each authority label. Therefore, when receiving the submitted authority tag, such as in conjunction with FIG. 10, the DRM server 320 finds the identification mark of the ORT900 in the authority tag, and retrieves the latest copy of such ORT900 based on the found identification mark, from the submitted authority The permission data is deleted from the label, and then the permission label is signed based at least in part on the inserted permission data. Of course, the DRM server also performs any necessary encryption and decryption steps that are necessary and obligatory in the process as described, including decryption or re-encryption (DES1 (Entitlement Data)). Note that if the DRM server adaptively replaces the rights data in the submitted rights tags, such rights tags and the ORT 900 from which such rights tags are constructed need not include the rights data. Instead, the rights data only needs to reside on the DRM server 320. However, the ORT 900 with the authority tag and the authority tag constructed from it includes authority data, which may be useful to the user, and therefore useful in some cases.

When issuing a license for protected content via directory licensing, the license issuing entity (hereinafter "licensor") consults the sent SRL308 from the content to determine which user/group (group) to be. The /cluster/division/platform/etc. (hereinafter'entity') provides permissions and checks the sent certificate to identify the license requester. Based on the above, the license issuer determines which of the rights listed in SRL308 are to be issued to the requester. Conceptually, the licensor checks the entities listed in SRL308 and compares such entities with the requestor. Thus, if SRL308 specifies a specific group to receive a license and the requester is a member of such a group, then the requester is granted a license with the rights as described for this group in SRL308. Similarly, if SRL308 specifies that a particular user is to receive a license and the requestor is such a user, then the requestor is granted a license with the rights described in SRL308 for such a user. As can be appreciated, a particular SRL 308 can list several entities and permissions for it, and a particular requestor can be granted a license based on being a member of one or more entities.

In an embodiment of the present invention, and as seen in FIG. 12, the requester is identified in the sent certificate 1202 via an identifier 1204, where the identifier 1204 can be, for example, an alias. The requestor is identified in the organization's directory 1206. Therefore, SRL308 lists each authorized entity according to such an identifier 1204 therein. In this way, and as part of processing the request for the license 1208, the license issuer 1210 obtains the requestor's identifier 1204 from the certificate 1202, and combines the obtained identifier 1204 with all the identifiers as listed in the sent SRL308 The identifier 1204 is compared. If a match is found, the license issuer 1210 issues a license with the rights specified in the SRL 308 for such a requester's identifier 1204 to the requester.

Moreover, in the case that the catalog 1206 is valid, the licensor 1210 can also determine whether the requestor is any other entity listed in SRL308, assuming that the catalog 1206 contains appropriate cross-reference information, which can be reflected in each such The membership status of the requester in the other entities. Generally, the directory 1206 not only lists the identifier 1204 for each requester, but also lists the identifier 1208 of each group/group/department/platform/other entity/etc of the requester and its members. Note that the directory 1206 may include identifiers 1208, such as email addresses, alternative email addresses, IDs (identifiers), alternative IDs, group memberships, historical identifiers, and/or the like.

With the certificate 1202 received from the requester with its identifier 1204 in it, and with the authority data from the SRL308 received from the requester, then, and now referring to Figure 13, the license issuer 1210 is in the following manner The requester issues a license 1208. Initially, the license issuer 1210 obtains the identifier 1204 from the received certificate 1202 (step 1301), and finds the obtained identifier 1204 in the directory 1206 (step 1303). After that, the license issuer 1210 finds the identifier 1204 of each member of which the requester 1204 is a member in the directory 1206 based on the found identifier 1204 (step 1305). Thus, for each requester identifier 1204 found and all entity identifiers 1204 found, the license issuer 1210 compares such identifier 1204 with all identifiers 1204 as listed in the sent SRL308 (Step 1307). Once again, if a match is found, the license issuer 1210 issues a license with the rights specified in the SRL 308 for the matched identifier 1204 for the requester (step 1309a).

Note that due to the comparison of multiple identifiers 1204 with SRL308, it is possible that multiple matching identifiers 1204 are found in SRL308. If so, the license issuer 1210 selects a suitable matching identifier 1204 in the SRL308, and issues a license with the authority specified in the SRL308 for the selected matching identifier 1204 to the requester (step 1309b) . For example, the license issuer may choose to transmit the matching identifier 1204 with the most permissions to the requester (step 1309b-1). Note that the license issuer may be able to determine which matching identifier 1204 delivers the most rights, or may have to rely on some type of priority marking in SRL308. In the latter case, each matching identifier (user) 1204 in the SRL 308 has a corresponding priority mark 1212, and the higher mark 1212, for example, indicates a larger range of granted rights. Thus, if the license issuer 1210 finds multiple matching identifiers 1204 in the SRL 308, such license issuer 1210 selects the matching identifier 1204 with the highest priority mark 1212 (step 1309b-2).

Note that when referring to the directory 1206 to generate additional identifiers 1204 related to the requester, the license issuer 1210 will increase the likelihood of finding a match, even in such cases, for example, the requesters email address or ID is changed from It has changed since the creation of SRL308. Generally speaking, the directory 1206 provides a mapping from the identifier 1204 of one requester to the identifiers 1204 of other possible requesters, so that all the identifiers 1204 can be used to try to find a match with the identifier 1204 in the SRL308 .

Permission to the group In one embodiment of the present invention, the certificate 1202 sent, as submitted by the requester, may represent a group or a group or some other collection of individuals (hereinafter "group"), here Such groups are appropriately represented in the directory 1206. Such groups may include mail-activated groups such as a distribution list or mail alias, or a security group such as can be defined in conjunction with a network operating system or the like. Therefore, when the license issuer 1210 receives the sent "group" certificate 1202, it actually proceeds as before. Note, however, because the certificate 1202 sent represents a specific group, it can be, specifically, the license 1208 issued from the license issuer 1210 is for the group identified in the certificate 1202 and not the requester . Alternatively, the license issuer 1210 may determine from the directory 1206 that the requester is part of the group identified in the certificate 1202, and if so, the issued 1210 is for the requester.

In the former case, the issued license 1208 may include the content key encrypted according to the public key of the group, and the requester therefore needs to obtain the private key of the corresponding group. Therefore, the requester may have a group membership certificate with such a private key, which may be encrypted according to the requester's public key and decryptable according to the requester's private key.

In the latter case, the content key encrypted in accordance with the public key of the requester is to be included in the issued license 1208, and the license issuer 1210 may additionally receive the public key with such a public key from the requester. Certificate. Alternatively, the license issuer 1210 may have such a certificate on the file (see steps 608-612 in Figures 6A and 6B), and determine from the directory 1206 that the requester is identified in the sent group certificate 1202 When part of the group, use the public key in the certificate.

It is worth noting that the designated permissions in SRL 308 and the issuance of licenses according to groups 1208 complete data permissions management in the enterprise or organizational environment. For example, documents or emails can be protected by DRM, so all members of a given department have the right to read the documents or emails. Assuming that a group with such a department (such as an email alias) exists in the organization's directory 1206, this is the most common case, and the author of a document or email will grant permissions based on the group rather than the individual. As can be appreciated, the benefits of such group-level permission grants include ease of use for authors when designating classes of individuals with permissions. In addition, by assigning permissions in accordance with the group, the assigned permissions will not become "invalidated" when new individuals join the group and old individuals leave the group. Instead, all current members of the group can exercise these rights, as long as the membership of such a group is maintained in the organization's directory 1206 until now.

Inserting a policy during the licensing period. In one embodiment of the present invention, and as mentioned above indirectly in conjunction with the ORT900 of FIG. 9, when a license 1208 is issued based on such SRL308, the DRM server/license issuer 1210 can adaptively Modify or replace the permission data from the submitted SRL308. Specifically, several situations will occur when the permission data in the submitted SRL308 is explicitly ignored, and when the license 1208 is created based on such SRL308, the license issuer 1210 replaces or'injects' it instead. 'An alternative policy. Note that although several licensors 1210 disclosed herein insert policies into specific circumstances of the license 1208, the licensors 1210 can also insert policies without departing from the spirit and scope of the present invention. Licensor 1208 in any other type of situation.

In the first case, and referring now to FIG. 14, the license issuer 1208 maintains a list of special entities (users, groups, etc.) that are granted special permissions (FIG. 12). For example, special entities may include certain high-level individuals in the organization, certain managed individuals, certain individuals who should be able to reproduce all content, and the aforementioned groups of individuals. Such a list 1214 is actually included in the organization's catalog 1206 as identifying information listed for each special entity in the catalog, or more simply by creating a group of one or more such special entities. In this way, such special entities can reproduce content, even if the SRL308 for them will prevent such reproduction on the contrary.

When an entity submits SRL308 as part of a request for license 1208, then, referring now to FIG. 14, the license issuer 1210 uses the directory 1206 to check in an appropriate manner to determine whether the submitted entity is identified as a special entity (Step 1401), and if yes, the license issuer 1210 creates a license 1208 with a special authority different from the authority data provided in the submitted SRL 308 for this special entity (Step 1403). Note that the special rights may be any rights without departing from the spirit and scope of the present invention. For example, a special permission may be that all special entities from a certain group can fully access and reproduce the content, and a certain special entity receives enhanced permissions such as a higher number of plays or a longer time before the license 1208 expires. Note that if special permissions are specific to an individual or group, such permissions can be specified in the directory entry for this individual or group in the directory 1206, and such directory entry can have a suitable reference to a location, the location Place a special permission, the license issuer 1210 can find the special permission in the database based on the identifier 1204 of the individual or group, and so on.

In the second case, now turning to FIG. 15, the license issuer 1208 maintains a list 1216 of restricted entities (users, groups, etc.) for which permissions are to be restricted or denied (FIG. 12). For example, restricted entities may include individuals who have left the organization, individuals who should not normally have any rights to any content in the organization, such as maintenance and construction personnel, and individuals who have only a limited status in the organization, such as operators. And temporary workers, as well as groups of the aforementioned individuals. Like the "special list 1214 described above, the restricted list 1216 can also be included in the organizations directory 1206 as identifying information for each restricted entity listed in the directory, or more simply by creating an or Multiple such restricted groups. In this way, such restricted entities are restricted from reproducing content, even though the SRL308 for them will allow such reproduction instead.

An entity submits SRL308 as part of a request for a license 1208, and then, still referring to Figure 14, the license issuer 1210 uses the directory 1206 to check in an appropriate manner to determine whether the submitted entity is identified as a restricted entity (Step 1405), and if so, the license issuer 1210 creates a license 1208 for the restricted entity with restricted rights that are different from the rights provided in the submitted SRL 308 (Step 1407). Note that the restricted rights may be any rights without departing from the spirit and scope of the present invention. For example, restricted rights may be that all restricted entities cannot access and reproduce the corresponding content in any way, all restricted entities from a specific group can only reproduce content in a short-lived form, and a specific restricted entity Only a single copy of one piece of content can be printed, and so on. In addition, restricted authority may be an entity that does not grant restricted authority regardless of authority. As with regard to special permissions, if the restricted permissions are specific to an individual or group, then such permissions can be assigned to a directory entry for this individual or group in the directory 1206, and such directory entry can have an appropriate location for a location. For reference, the restricted rights are placed in this location, and the license issuer 1210 can find the restricted rights in the database based on the identifier 1204 of this individual or group, and so on.

In the third case, the licensor 1208 can insert a policy into the license 1208 to specify the minimum system requirements that are necessary to reproduce the corresponding content on the computing device 14 (FIG. 11) (step 1409). Such minimum system requirements generally relate to the reliability and safety of the computing device 14, although such requirements may relate to anything else without departing from the spirit and scope of the present invention.

The basic example that will be relevant to the authenticity and security of the licensor 1210 is whether the trusted component 18 of the computing device 14 or its secure portion is current. As can be appreciated, such currentness can be represented by version number, establishment date, etc., and reflect the time of use of the trusted component 18 or part thereof. As can also be appreciated, with the use time of such a trusted component 18 or part thereof, the trusted component 18 or part thereof is more susceptible to security attacks by illegal entities. Therefore, the license issuer 1210 can decide that the trusted component 18 or part of it beyond a certain time of use should be untrusted, and can insert a policy into the license 1208 issued by it, requiring that the corresponding content be reproduced before being allowed , First update such untrusted trusted components 18 or parts thereof.

Another example related to the authenticity and security of the license issuer 1210 is that the application to reproduce the content should in fact be trusted. As can be appreciated, it can be the case that one application can be trusted to reproduce the content within the limits of the license issuer 1208 by not allowing the content to be stored in an unprotected form, while another application The program cannot be equally trustworthy. Therefore, the license issuer 1210 can determine that only a certain application can be used to reproduce the corresponding content, and can insert a policy into the license 1208 issued by it, requiring that only such application be used to reproduce such content.

Of course, there are plenty of other policy insertions. Generally speaking, it is possible to perform policy insertion to add additional permissions to the permission data of SRL308, or to delete permissions from the permission data of SRL308, possibly based on the requester (step 1411); and also add conditions to such permission data Once again, or delete the condition from such permission data, it may be based on the requester (step 1413).

Conclusion The programming required to complete the process performed in conjunction with the present invention is relatively straightforward and obvious to the relevant programmers. Therefore, no such programming is attached here. Therefore, any specific programming can be used to complete the present invention without departing from the spirit and scope of the present invention.

It should be appreciated that the described embodiments can be modified without departing from the concept of the invention. It is worth noting that although the present invention is described in terms of a prescribed field such as an organization, the present invention can also be used in a prescribed field that is a subset of an organization or includes multiple organizations, all without departing from the spirit and scope of the present invention. under. Therefore, it should be understood that this invention is not limited to the specific embodiments disclosed, but is intended to cover modifications within the spirit and scope of the invention as defined by the appended claims.

Appendix 1 Sample Rights Data<? xml version="1.0"? >

<XrML version="1.2">

<BODY type="Rights Template">

<DESCRIPTOR>

<OBJECT>

<ID type="GUID">c43...</ID>

<NAME>$$411$411name$411desc</NAME>

</OBJECT>

</DESCRIPTOR>

<WORK>

<OBJECT>

<ID/>

</OBJECT>

<RIGHTSGROUP name="MAIN RIGHTS">

<RIGHTSLIST>

<VIEW>

<CONDITIONLIST>

<ACCESS>

<PRINCIPAL>

<OBJECT>

<ID/>

<NAME>test@company.com</NAME>

</OBJECT>

</PRINCIPAL>

</ACCESS>

</CONDITIONLIST>

</VIEW>

<RIGHT name="generic">

<CONDITIONLIST>

<ACCESS>

<PRINCIPAL>

<OBJECT>

<ID/>

<NAME>test@company.com</NAME>

</OBJECT>

</PRINCIPAL>

</ACCESS>

</CONDITIONLIST>

</RIGHT>

</RIGHTSLIST>

</RIGHTSGROUP>

</WORK>

</BODY>

<SIGNATURE>

<ALGORITHM>RSA PKCS#1-V1.5</ALGORITHM>

<DIGEST>

<ALGORITHM>SHA1</ALGORITHM>

<PARAMETER name="codingtype">

<VALUE encoding="string">surface-coding</VALUE>

</PARAMETER>

<VALUE encoding="base64"size="160">Mwl...=</VALUE>

</DIGEST>

<VALUE encoding="base64"size="1024">Msi...=</VALUE>

</SIGNATURE>

</XrML>

Appendix 2 Sample Signed Rights Label (SRL) 308 Sample Signed Rights Label (SRL) 308<? xml version="1.0"? >

<XrML version="1.2">

<BODY type="Rights Label"version="3.0">

<ISSUEDTIME>2002-01-01_12:00:00</ISSUEDTIME>

<DESCRIPTOR>

<OBJECT>

<ID/>

<NAME>$$409$...</NAME>

</OBJECT>

</DESCRIPTOR>

<ISSUER>

<OBJECT type="DRM-Server">

<ID type="GUID">{d81 ...}</ID>

<NAME>Test DRM Server</NAME>

<ADDRESS type="URL">http://licensing.dev.com</ADDRESS>

</OBJECT>

<PUBLICKEY>

<ALGORITHM>RSA</ALGORITHM>

<PARAMETER name="public-exponent">

<VALUE encoding="integer32">65537</VALUE>

</PARAMETER>

<PARAMETER name="modulus">

<VALUE encoding="base64" size="1024">NcO...=</VALUE>

</PARAMETER>

</PUBLICKEY>

<ENABLINGBITS type="sealed-key">

<VALUE encoding="base64" size="1024">tFg...=</VALUE>

</ENABLINGBITS>

<SECURITYLEVEL name="Server-Version"value="2.0"/>

<SECURITYLEVEL name="Server-SKU" value="22222-3333"/>

</ISSUER>

<DISTRIBUTIONPOINT>

<OBJECT type="LICENSE ACQUISITION URL">

<ID type="GUID">{OF4..,}</ID>

<NAME>DRM Server Cluster</NAME>

<ADDRESS type="URL">http://Iocalhost/Licensing</ADDRESS>

</OBJECT>

</DISTRIBUTIONPOINT>

<WORK>

<OBJECT type="TEST-FORMAT">

<ID type="MYID">FDB-1</ID>

</OBJECT>

<METADATA>

<SKU type="PIDTYPE">PID</SKU>

</METADATA>

<PRECONDITIONLIST>

<TIME/>

</PRECONDITIONLIST>

</WORK>

<AUTHDATA name="Encrypted Rights data">PAB...</AUTHDATA>

</BODY>

<SIGNATURE>

<ALGORITHM>RSA PKCS#1-V1.5</ALGORITHM>

<DIGEST>

<ALGORITHM>SHA1</ALGORITHM>

<PARAMETER name="codingtype">

<VALUE encoding="string">surface-coding</VALUE>

</PARAMETER>

<VALUE encoding="base64"size="160">Prc...=</VALUE>

</DIGEST>

<VALUE encoding="base64"size="1024">EHd...=</VALUE>

</SIGNATURE>

</XrML>