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

[0001] Cross reference to related applications

[0002] 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:

[0003] U.S. Patent Application No. ____, filed under the attorney docket number (attorney docketnumber) MSFT-1569 at the same time as the present invention, and titled ^uPublishing Digital Content Withina Defined Universe Such As an Organization in Accordance with a DigitalRights Management(DRM)System;

[0004] US Patent Application No. 10/185, 527, filed on June 28, 2002 under the Attorney's Abstract No. MSFT-1330, and the title is ^uObtaining 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;

[0005] US Patent Application No. 10/185, 278, filed on June 28, 2002 under the Attorney's 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

[0006] US Patent Application No. 10/185, 511, filed on June 28, 2002 under the Attorney's Abstract No. MSFT-1343, and the title is Systems And Methods For Issuing Usage Licenses For Digital Content And Services.

Technical field

[0007] The present 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

[0008] In terms of digital content such as digital audio, digital video, digital text, digital data, digital multimedia, etc., where 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.

[0009] 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 cost. 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 here

CN 1521980 Β

Such a second user takes time to deny permission to the content owner.

[0010] 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.

[0011] In another scenario, such as employees in an organization or members of the 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 others from reproducing 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.

[0012] In such a scenario, the content may be document reports, spreadsheets, databases, emails, etc., such as those that can be communicated in an office environment, and content developers may want to ensure that the content remains in an organization or office environment Within and not be reproduced by unauthorized individuals such as, for example, competitors or opponents. 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 the scope of the individual who is allowed to reproduce the content.

[0013] 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 individual, and be viewable and printable with respect to another type of individual.

[0014] 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.

[0015] 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.

[0016] Therefore, there is a demand 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 can be controlled by such digital content. The content is defined by the content owner/developer. More specifically, there is a need for a structure that allows and promotes 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.

[0017] Overview

[0018] The above-mentioned needs are met at least in part by the present invention. In the present invention, the license issuer issues a digital license that allows the requester to reproduce the corresponding digital content to the requester. 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.

CN 1521980 Β

[0019] 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 requester's identifier 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

[0020] When you read in conjunction with the accompanying 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 attached picture:

[0021] FIG. 1 is a block diagram showing a typical non-limiting computing environment in which the present invention can be implemented; [0022] FIG. 2 is a block diagram showing a typical network environment with various computing devices, in which The present invention can be realized in;

[0023] FIG. 3 is a functional block diagram of an embodiment of the system and method according to the present invention for distributing digital content;

[0024] FIG. 4 is a flow chart of an embodiment of the method according to the present invention for the distribution of digital content for rights management;

[0025] FIG. 4A is a block diagram showing the structure of a signed authority tag as generated by the method of FIG. 4;

[0026] FIG. 5 is a block diagram of an embodiment of the system and method according to the present invention for digital content for licensing rights management;

[0027] FIGS. 6A and 6B are flowcharts of an embodiment of the method according to the present invention, used for digital content for licensing rights management;

[0028] FIG. 7 is a flowchart showing the key steps performed when a rights label is reissued according to an embodiment of the present invention;

[0029] FIG. 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;

[0030] FIG. 9 is a block diagram showing a permission template according to an embodiment of the present invention, specifying information to be incorporated into a permission tag;

[0031] FIG. 10 is a flowchart showing the key steps performed when creating the permission template of FIG. 9 and creating the signed permission label of FIG. 4A based on the permission template according to an embodiment of the present invention;

[0032] FIG. 11 is a block diagram showing the implementation structure of an example of a trust-based system;

[0033] FIG. 12 is a block diagram showing a license issuer processing a request for a license according to an embodiment of the present invention;

[0034] FIG. 13 is a flowchart showing steps related to a directory performed by the license issuer of FIG. 12 when issuing a license; and

[0035] FIG. 14 is a flowchart showing the steps performed by the license issuer of FIG. 12 when inserting a policy into a license to be issued.

[0036] Detailed description

CN 1521980 Β

[0037] FIG. 1 and the following discussion are intended to provide a brief overview 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.

[0038] 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, which will be in the general context of computer-executable instructions such as program modules. Describes web browsing software, which is 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 to 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.

[0039] FIG. 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, and It is not intended to imply any limitation on the scope of use or functions 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.

[0040] 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 a memory controller using various bus structures, an external device bus, and a local bus. As an example, but not limiting, 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).

[0041] The computer 110 generally includes a wide 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, 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 one or

CN 1521980 Β

Multiple characteristic signals. 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.

[0042] 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.

[0043] 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 for reading and writing non-removable, non-volatile magnetic media, a disk drive 151 for reading and writing a removable, non-volatile magnetic disk 152, and a removable, non-volatile disk drive 151 for reading and writing. 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.

[0044] 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 a 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).

[0045] 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, can 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.

[0046] 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 node, and generally includes many or all of the components described above with respect to the computer 110, although

Only the memory device 181 is shown in FIG. 1. 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.

[0047] When used in a LAN network environment, the computer 110 is connected to the LAN 17L through a network interface or adapter 170. When used in a WAN network environment, the computer 110 generally includes a modem 172 or is used to set up on the WAN 173 such as the Internet. Other tools for communication. The modem 172, which can be built-in or external, can be connected to the system bus 121 through the user input interface 160 or other appropriate mechanisms. In a networked environment, the program module 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.

[0048] A person skilled 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.

[0049] 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.

[0050] FIG. 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.

[0051] It can also be appreciated that an object such as 110c may 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.

[0052] 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.

[0053] In a home network environment, there are at least four disparate network transmission media, each of which can support a unique protocol, such as power line, data (both wireless or wired), voice (for example, telephone) And entertainment media (entertainmen t 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), 5

CN 1521980 Β

The data service is accessible through the connection of the category line (Cat 5) or even the power line. Voice services can be used as either wired (for example, Category 3 line (Cat 3)) or wireless (for example, cellular phones) into the home, and category 3 wiring can be used to distribute voice services 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.

[0054] "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 computer that executes network protocols that allow users to interact and share information over the network A system of interconnected remote computer networks. Because of such extensive information sharing, remote networks such as the Internet have generally been involved in open systems. Developers of this system can design for use with basically no restrictions. Software applications that perform special operations or services.

[0055] 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 regarded as clients, and the computers 10a, 10b, etc. can be regarded as servers, where the servers 10a, 10b, etc. are maintained and then copied to the client computers 110a, 110b, etc. The data.

[0056] A 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.

[0057] The client and server communicate with each other using 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.

[0058] In this way, FIG. 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 (television), microwave ovens, electric lights, heaters, 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.

[0059] 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. service

CN 1521980 Β

The device 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 in client computers 110a, 110b, etc. that can be accessed and interacted with the computer network/bus 14, and server computers 10a, 10b, etc. that can interact with client computers 110a, 110b, etc. and other devices 111 and databases 20 .

[0060] Overview of Data Rights Management (DRM)

[0061] As known, and referring now to FIG. 11, in terms of digital content 12, such as digital audio, digital video, digital text, digital data, digital multimedia, etc., when such digital content is to be distributed to users, the 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.

[0062] 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.

[0063] However, after the distribution has taken place, such content owners have very little control even if they have control over the digital content 12. 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.

[0064] 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.

[0065] 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 such content owner that the digital content 12 will not be reproduced unless Meet the rules and requirements in License 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.

[0066] The trusted component 18 generally has a license evaluator (license evaluator) 20, which determines whether the license 16 is valid, checks the licensing rules and requirements in such a valid license 16, and based on all Check the permission rules and requirements to determine 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 follow the rules in the license 16

CN 1521980 Β

And the desire of the owner who requires the completion of the digital content 12, and the user should not be able to easily change such a trusted unit for any illegal or other purposes.

[0067] 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 the user uses What type of computing device is it, 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.

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

[0069] 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.

[0070] Distribution of digital content

[0071] 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.

[0072] In an embodiment of the present invention, specifically, three entities can be used to issue secure digital content: a content preparation application (content preparation application) 302, which is executed on the client 300 and used to prepare for distribution Contents, a data rights management (DRM) application programming interface (API) 306, also resides in the client device 300±, and a DRM server 320, which 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.

[0073] 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.

[0074] 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 included permissions indicate that a specified user has the permissions specified in the content (for example, the user can edit digital content). Excluded permissions means that a specified user has all permissions in the content, except for those

CN 1521980 Β

Fixed (for example, users can do anything with digital content, except copy it).

[0075] According to an embodiment of the present invention, the client API 306 can transfer 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.

[0076] 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 right label, it will pass the signed right label 308 back to the client through the client API 306, and the API 306 will store the signed right label 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.

[0077] However, generally speaking, the 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.

[0078] 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 authority description and (PU-DRM(CK)) based on a private key (PR-DRM) corresponding to (PU-DRM).

[0079] In step 402, the application 302 generates a content key (CK) that is used to encrypt 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. Sharing (CK) between sender and 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.

[0080] 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, CastT28, RC4, RC5, and Skipjacko

[0081] In step 404, the application 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 permissions can be included, for example

CN 1521980 Β

Π/27 page includes viewing content, printing content, etc. The application program 302 provides permission data for the API 306. An example of permission data in XML/XrML format is attached here as Appendix 1.

[0082] 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, API306 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 "license 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, API306 encrypts (DES1) with (PU-DRM) to generate (PU-DRM(DES1)). In this way, (CK) can be protected by (PU-DRM) to ensure that the 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, the authorized entity list and the corresponding permissions and conditions associated with each authorized entity in this list) with (DES1) to generate (DES1 (Permission Data)).

[0083] 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)), so the use of (DES1) mentioned above is completed. 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 .

[0084] In step 418, the content preparation application 302 may submit (PU-DRM (DES 1)) and (DES1 (rights data)) to the DRM server 320 as rights labels 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 permission data, the DRM server 320 applies (PR-DRM) to (PU-DRM (DES 1)) to generate (DES1), and then applies (DES1) to (DESK permission 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 SRL308 to API306, API306 then provides the returned SRL308 to client application 302.

[0085] SRL308 is a digitally signed document to make it tamper-proof. In addition, SRL308 is independent of the actual key type and algorithm used to encrypt 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 (DES 1)) 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.

[0086] By ensuring that a trusted entity signs the rights data to create a signed rights label 308, in accordance with the terms described by the issuer in the rights data in the rights label 308, the DRM server claims that it will issue a license for the content . 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 including a signed rights label for the content 308

CN 1521980 Β

And a certificate that verifies the users credentials. 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 to the license requesting entity (if any Words), and construct a license with only those specific permissions.

[0087] Preferably, when the application program 302 receives the SRL 308, such an application program 302 centralizes the signed rights label 308 and the corresponding (CK (content)) 304 to form rights managed digital content. 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 reproduce 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 in 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.

[0088] In one embodiment of the present invention, a simple object access protocol (SOAP) may 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 DRM protocol clients, but can only make local API calls. 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.

[0089] Obtaining a license for distributed content

[0090] 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 (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 comply with the requirements 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 request The entity of the license does not need to be the entity for which the license is being requested. Generally, the license includes the permission description from SRL308, the encryption key that can decrypt the encrypted content, and the permission description and encryption key The digital signature on the ο The digital signature asserts that the specified entity and authority are legal.

[0091] A method for the application program 302 to restore the rights management content 310 is that the client API 306 transmits the rights tag 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.

[0092] As described above, the rights tag 308 contains the content key (CK) (ie (PU-DRM(CK))) encrypted according to 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 exposure (CK), because only the holder associated with the private key (PR-ENTITY) can

CN 1521980 Β

(PU-ENTITY (CK)) Recovery (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.

[0093] Alternatively, for example, a client such as an issuing client can issue its own license to restore 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.

[0094] FIGS. 6A and 6B provide a flow chart of an embodiment of a method 600 according to the present invention for digital content for licensing 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 directly issue the license.

[0095] 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. [0096] In step 604, the requesting entity (ie, the entity that generates the license request) is authenticated. According to an embodiment of the present invention, the license issuing entity may be configured to use protocol (such as 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 (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) password) schemes such as MICROSOFT. NET, PASSPORT, WINDOWS authorization, x509, etc.). 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.

[0097] In step 606, the entity authorized to authenticate, namely, 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.

[0098] 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.

[0099] 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.

[0100] 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 a suitable public key certificate in the directory service or database. If in step 610,

CN 1521980 Β

The issuing entity determines that the certificate is in the directory, and 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, either in the request or in the directory, the certificate cannot be found 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.

[0101] 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 credibility 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 list of trusted issuers. If in step 616, issue The entity determines that the issuer of the license holder's certificate is not in the list of trusted issuers, 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.

[0102] In addition, the issuing entity preferably performs digital signature verification on all digital signatures in the certificate chain, from a trusted issuer certificate to a personal license holder public key certificate. 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.

[0103] 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 that are put into them at the time of release. At the permission time (at step 622), the issuing entity parses the permission label input in the license request and retrieves its GUID_OIt 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.

[0104] 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.

[0105] 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 rights 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 used for specific license holders

CN 1521980 Β

The description of the permissions in the license. As part of this process, the license issuing entity identifies any prerequisites, which may be associated with any permission or permission group in the permission description of the permission label. 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 right to the licensee, even if the licensee The identity of is associated with that permission.

[0106] 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 re-encrypts (CK) using the (PU-ENTITY(CK)) license holder's public key certificate 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.

[0107] 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.).

[0108] 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) encrypted and transmitted 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, the 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 the keys in her license).

[0109] 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 specified group/class, the issuing entity can add the authority or authority group associated with the group/class to the authority description data structure for the license holder.

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

[0111] Modify or reissue the signed authority label 308

[0112] In one embodiment of the present invention, SRL308 can be republished, if the user who has granted the content has sufficient permission to do so. That is, if allowed, the user can change the permissions in SRL308 Data. Note that permission to change permission data should be granted with caution and thoughtful thinking, especially because a user with permission to change permission data can basically grant himself a wide range of permissions related to the associated content. Imagine , Such a user can even grant itself the right to expose content and deliver the same content to the world.

[0113] Here, the permission to change is represented 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

When the DRM server 320 receives the SRL 308 with such a license related to the request for the license, the DRM server 320 includes a symmetric key encrypted according to the user's public key (ie PU-ENTITY) in the license requested by the user. (DES1) to generate (PU-ENTITY(DESl)).

[0114] In this way, to edit the authority data in SRL308, and now turn to FIG. 7, the user retrieves (PU-ENTITY (DES1)) from the license (step 701), and applies (PR-ENTITY) to it to generate ( DES1) (step 703), retrieve (DESK permission data) from SRL308 (step 705), and apply (DES1) to it to generate permission 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).

[0115] In this way, and as can be appreciated, reissuing 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-encrypting 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 SRL308o

[0116] Self-issued signed authority label 308

[0117] In an embodiment of the present invention, the SRL 308 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-publishing can also refer to offline issuance. 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.

[0118] Specifically, and referring now to FIG. 8, in the embodiment, the user is first provided with a self-issued by receiving a DRM certificate from the DRM server 320, the DRM certificate includes a public key (PU-CERT) and the users The corresponding private key encrypted by the public key (PU-ENTITY) 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 It can be verified that they are exactly the same, 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 used exclusively for self-issue. 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.

[0119] The self-publishing is different from the issuance 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 (DES 1)). Therefore, when requesting a license based on the self-issued SRL 308, the DRM server 320 itself should perform verification.

[0120] 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

CN 1521980 Β

Users. 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 requests the user to submit 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.

[0121] Permission Template

[0122] As mentioned above, by defining users or user classes, define the permissions for each defined user or user class, and then define any conditions of use, and provide users with the ability to create most of any kind of permissions in the permissions tab Freedom of data. 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.

[0123] 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 label. In an embodiment of the present invention, then, during step 416 of FIG. 4 during the encryption of the authority data with (DES1), the authority template 900 with unencrypted authority data is submitted to generate (DESK authority data)). Of course, before such encryption, the permission data is retrieved from the submitted permission template 900.

[0124] 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)), realize again that (DES1) is not known , Until the content is released, and therefore (PU-DRM) in the rights template 900 cannot be encrypted (DES1), as is the case in the rights 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).

[0125] 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 a 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

In, such space is unnecessary.

[0126] Although the permission template 900 as disclosed so far is mainly for the convenience of users, it should be realized that in some environments, users should not have unlimited freedom to define permission data in permission tags, and can use The permission template 900 limits 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.

[0127] 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 the definition may be necessary and appropriate. Other data, such as information related to a specific DRM server 320 (step 1003), constructs a rights template 900. 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).

[0128] 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 authority template 900 when performing any necessary checks, or may sign the authority template 900 without any checking 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 authority label, and this signature is verified in conjunction with the authority label, and therefore no matter what the signature is based on, it should be incorporated into the authority label in an unaltered form.

[0129] 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 transmit the formal authorization template (ORT) 900 to one or more users who use it (step 1009). Therefore, for a user who distributes content based on the ORT900, the user retrieves the ORT900 (step 1011) and provides Any required information, such as information about content; appropriate key information; rights data from ORT900 encrypted by (DES1) to generate (DES1 (rights data)); and any other information from 0RT900, based on 0RT900 Permission label (step 1013). Notably, the user also includes the signature S (PR-DRM-T) from the ORT900 with the authorization tag.

[0130] 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 label unless confirmed by the S (PR-DRM-T) in it. In other words, 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 0RT900. Specifically,

The DRM server 320 retrieves the S (PR-DRM-T) and whatever information the signature is based on from the submitted authority label, and then verifies such a signature based on the (PU-DRM). Note that the authorization data in the submitted authorization label is encrypted according to (DES1) (ie (DES1 (authority data)). Therefore, the DRM server 320 must first obtain (DES1) and use

CN 1521980 Β

It decrypts (DESK authority data)), as described in conjunction with Figure 7, to be able to verify the signature based on the authority data in the submitted authority tag.

[0131] Once verified, the DRM server 320 signs the submitted rights label with S(PR-DRM-L) to generate SRL308, as before (where an L indicates 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) can be partly based on S (PR-DRM-T). Note that (PR-DRM) can be used to generate S (PR-DRM-T) and S (PR-DRM- L) Both, or different (PR-DRM) can be used for each of S (PR-DRM-T) and 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.

[0132] If ORT900's signature S (PR-DRM-T) is based at least in part on the rights data predefined in ORT900, then such rights data would appear in SRL308 (in DES1 (right data)) Cannot be modified or changed. Otherwise, S(PR-DRM-T) will not be able to verify. However, in one embodiment of the present invention, the authority data in the ORT900 can be changed within the prescribed rules also included in the ORT900. For example, these rules may specify one of 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 permission labels, 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) 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.

[0133] In an embodiment of the present invention, the permission data predefined in ORT900 is partially fixed and unchanging, and partially variable and rule-driven, as described above. Here, the template signature S (PR-DRM-T) for ORT900 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.

[0134] 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 0RT900, but the user is still using the previous, invalid version of 0RT900o

[0135] In this case, and in an embodiment of the present invention, then, the DRM server 320 reserves a copy of the ORT900 when signing the submitted permission template 900 to create an ORT900, and each ORT900 has a unique identification mark , And construct each authority label based on an ORT900 that includes such an ORT900 identification mark in it. 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 identification mark found, 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 (DESK permission data). Note that if the DRM server adaptively replaces the rights data in the submitted rights tags, such rights tags and ORT900 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, use permission tags and build by it like this

CN 1521980 Β

The ORT900 of the permission tag includes permission data, which may be useful to the user, and therefore useful in certain situations.

[0136] Licensed via catalog

[0137] When issuing a license for protected content, the license issuing entity (hereinafter "licensor") consults the sent SRL 308 from the content to determine which user/group (group) to be. /Cluster/division/platform/ etc. ("entity" in the following) provide permissions and check 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.

[0138] In an embodiment of the present invention, and as seen in FIG. 12, the requester is identified via the identifier 1204 in the transmitted certificate 1202, where the identifier 1204 may be, for example, an alias. The alias identifies the requester in an organization's directory 1206. Therefore, SRL308 lists each authorized entity in accordance with such an identifier 1204. Thus, 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 of 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 the identifier 1204 of such requester to the requester.

[0139] Moreover, in the case that the catalog 1206 is valid, the license issuer 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 The membership status of the requestor in each of these 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.

[0140] With the certificate 1202 received from the requester with its identifier 1204 in it, and the authority data from the SRL308 received from the requester, then, and now referring to FIG. 13, the license issuer is below 1210 The column method is for the requestor to issue 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). In this way, for each found requestor identifier 1204 and all found entity identifiers 1204, 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 for the requester with the rights specified in the SRL 308 for the matched identifier 1204 (step 1309a).

[0141] 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 licensor 1210 selects a suitable matching identifier 1204 in the SRL308, and issues to the requestor with the rights specified in the SRL308 for the selected matching identifier 1204.

CN 1521980 Β

Limited license (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. In this way, if the license issuer 1210 finds multiple matching identifiers 1204 in the SRL 308, such a license issuer 1210 selects the matching identifier 1204 with the highest priority mark 1212 (step 1309b-2).

[0142] 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 the ID has changed since the creation of SRL308. Generally speaking, the directory 1206 provides a mapping from the identifier 1204 of a 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 .

[0143] Permission to Group

[0144] In an embodiment of the present invention, the sent certificate 1202, as submitted by the requester, may represent a group or a group or some other collection of individuals (hereinafter "group"), in this case The group of is appropriately represented in the directory 1206. Such groups can 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, and 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.

[0145] In the former case, the issued license 1208 may include the content key encrypted in accordance with 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.

[0146] 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 from the requester with such a Public key 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.

[0147] It is worth noting that the designated permissions in the SRL 308 and the issuance of licenses according to the group 1208 complete data permission management in an 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.

[0148] Insert policy during permission

CN 1521980 Β

[0149] In an embodiment of the present invention, and as mentioned above indirectly in conjunction with 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. '-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 in any other type of situation 1208ο

[0150] In the first case, and referring now to FIG. 14, the licensor 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.

[0151] When an entity submits SRL308 as part of a request for a 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 authenticated as A special entity (step 1401), and if it is, the license issuer 1210 creates a license 1208 with special permissions different from the permission data provided in the submitted SRL 308 for this special entity (step 1403). Note that the special permission may be any permission without departing from the spirit and scope of the present invention. For example, a special permission can be that all special entities from a specific group can fully access and reproduce the content, and a specific special entity receives enhanced permissions such as a higher number of plays or a longer time before the license 1208 expires. Note that if a special permission is specific to an individual or group, such permission 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 Put 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.

[0152] In the second case, now turning to FIG. 15, the licensor 1208 saves a list 1216 of restricted entities (users, groups, etc.) for which rights 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 listed for each restricted entity 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.

[0153] An entity submits SRL308 as part of a request for a license 1208, and then, still referring to FIG. 14, the license issuer 1210 uses the directory 1206 to check in an appropriate manner to determine whether the submitted entity is authenticated as a subject Restricted entity (step 1405), and if so, the license issuer 1210 creates a license 1208 for the restricted entity with restricted permissions that are different from those provided in the submitted SRL308 (step 1407) . Note that the restricted rights can 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 about special rights

CN 1521980 Β

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 a suitable reference to a location. 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.

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

[0155] A basic example that will be relevant to the authenticity and security of the license issuer 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 use time 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 licensor 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 an untrustworthy trusted component 18 or part thereof.

[0156] 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.

[0157] Of course, there are a large number of other policy insertions. Generally speaking, it is possible to execute 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, it is possible to delete conditions from such permission data based on the requester (step 1413).

[0158] Conclusion

[0159] The programming required to complete the process performed in conjunction with the present invention is relatively straightforward and obvious to the relevant programmer. 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.

[0160] 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 specified fields such as organizations, the present invention can also be used in specified fields that are a subset of organizations or include 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.

[0161] Appendix 1

[0162] Sampling Rights Data

[0163] Sample Rights Data

[0164] <? Xml version = ^!f 1.0 ? >

[0165] <XrML version = ^!f 1.2 >

CN 1521980 Β

<td>[0166]</td><td>&lt;B0DY type = Rights Template&gt;</td>

<td>[0167]</td><td>&lt;DESCRIPT0R&gt;</td>

<td>[0168]</td><td>&lt;0BJECT&gt;</td>

<td>[0169]</td><td>&lt;ID type = GUID &gt;c43... &lt;/ID&gt;</td>

<td>[0170]</td><td>&lt;NAME&gt;$$411$411name$411desc&lt;/NAME&gt;</td>

<td>[0171]</td><td>&lt;/0BJECT&gt;</td>

<td>[0172]</td><td>&lt;/DESCRIPT0R&gt;</td>

<td>[0173]</td><td>&lt;W0RK&gt;</td>

<td>[0174]</td><td>&lt;0BJECT&gt;</td>

<td>[0175]</td><td>&lt;ID/&gt;</td>

<td>[0176]</td><td>&lt;/0BJECT&gt;</td>

<td>[0177]</td><td>&lt;RIGHTSGR0UP name = MAIN RIGHTS&gt;</td>

<td>[0178]</td><td>&lt;RIGHTSLIST&gt;</td>

<td>[0179]</td><td>&lt;VIEW&gt;</td>

<td>[0180]</td><td>&lt;C0NDITI0NLIST&gt;</td>

<td>[0181]</td><td>&lt;ACCESS&gt;</td>

<td>[0182]</td><td>&lt;PRINCIPAL&gt;</td>

<td>[0183]</td><td>&lt;0BJECT&gt;</td>

<td>[0184]</td><td>&lt;ID/&gt;</td>

<td>[0185]</td><td>NAMEtest@company. com&lt;/NAME&gt;</td>

<td>[0186]</td><td>&lt;/0BJECT&gt;</td>

<td>[0187]</td><td>&lt;/PRINCIPAL&gt;</td>

<td>[0188]</td><td>&lt;/ACCESS&gt;</td>

<td>[0189]</td><td>&lt;/C0NDITI0NLIST&gt;</td>

<td>[0190]</td><td>&lt;/VIEW&gt;</td>

<td>[0191]</td><td>&lt;RIGHT name = generic&gt;</td>

<td>[0192]</td><td>&lt;C0NDITI0NLIST&gt;</td>

<td>[0193]</td><td>&lt;ACCESS&gt;</td>

<td>[0194]</td><td>&lt;PRINCIPAL&gt;</td>

<td>[0195]</td><td>&lt;0BJECT&gt;</td>

<td>[0196]</td><td>&lt;ID/&gt;</td>

<td>[0197]</td><td>NAMEtest@company. com&lt;/NAME&gt;</td>

<td>[0198]</td><td>&lt;/0BJECT&gt;</td>

<td>[0199]</td><td>&lt;/PRINCIPAL&gt;</td>

<td>[0200]</td><td>&lt;/ACCESS&gt;</td>

<td>[0201]</td><td>&lt;/C0NDITI0NLIST&gt;</td>

<td>[0202]</td><td>&lt;/RIGHT&gt;</td>

<td>[0203]</td><td>&lt;/RIGHTSLIST&gt;</td>

<td>[0204]</td><td>&lt;/RIGHTSGR0UP&gt;</td>

CN 1521980 Β

[0205]

[0206]

[0207]

[0208]

[0209]

[0210]

[0211]

[0212]

[0213]

[0214] &lt;/VALUE&gt;

[0215]

[0216] &lt;/VALUE&gt;

[0217]

[0218]

[0219]

[0220]

[0221]

[0222]

[0223]

[0224]

[0225]

[0226]

[0227]

[0228]

[0229]

[0230]

[0231]

[0232]

[0233]

[0234]

[0235]

[0236]

[0237]

[0238]

[0239]

[0240]

[0241] &lt;/W0RK&gt;

&lt;/B0DY&gt;

&lt;SIGNATURE&gt;

&lt;ALGORITHM&gt;RSA PKCS#1-V1. 5&lt;/ALG0RITHM&gt;

&lt;DIGEST&gt;

&lt;ALGORITHM&gt;SHA1&lt;/ALGORITHM&gt;

&lt;PARAMETER name = codingtype&gt;

&lt;VALUE encoding = string&gt;surface-coding&lt;/VALUE&gt; &lt;/PARAMETER&gt;

&lt;VALUE encoding = base64 size = 160 &gt;MwI...= &lt;/DIGEST&gt;

&lt;VALUE encoding = base64 size = 1024 &gt;Msi...

&lt;/SIGNATURE&gt;

&lt;/XrML&gt;

Appendix 2 Signed Sampling Rights Label (SRL) 308

Sample Signed Rights Label(SRL)308 &lt;? Xml version = 1.0?&gt; &lt;XrML version = 1.2&gt;

&lt;BODY type = Rights Label version = 3. 0&gt; &lt;ISSUEDTIME&gt;2002-01-01_12:00L00&lt;/ISSUEDTIME&gt; &lt;DESCRIPTOR&gt;

&lt;OBJECT&gt;

&lt;ID/&gt; NAME$$409$... &lt;/NAME&gt;

&lt;/OBJECT&gt; &lt;/DESCRIPTOR&gt;

&lt;ISSUER&gt;

&lt;OBJECT type = DRM-Server&gt;

&lt;ID type = GUID &gt;{d81... }&lt;/ID&gt; &lt;NAME&gt;Test DRM Server&lt;/NAME&gt;

&lt;ADDRESS type = URL &gt;http://licensing. dev. com&lt;/ADDRESS&gt; &lt;/OBJECT&gt;

&lt;PUBLICKEY&gt;

&lt;ALG0RITHM&gt;RSA&lt;/ALGORITHM&gt;

&lt;PARAMETER name = public-exponent&gt; &lt;VALUE encoding = integer32 &gt;65537&lt;/VALUE&gt;

CN 1521980 Β

<td>[0242][0243]</td><td>&lt;/PARAMETER&gt;&lt;PARAMETER name = modulus^/z &gt;</td>

<td>[0244]&lt;/VALUE&gt;[0245][0246][0247][0248]&lt;/VALUE&gt;[0249][0250]</td><td>&lt;VALUE encoding = ^!f base64^/z size = ^!f 1024 &gt;NcO...=&lt;/PARAMETER&gt;&lt;/PUBLICKEY&gt;&lt;ENABLINGBITS type = ^!f sealed-key &gt;&lt;VALUE encoding = ^!f base64^/z size = ^!f 1024 &gt;tFg...=&lt;/ENABLINGBITS&gt;&lt;SECURITYLEVEL name = ^!f Server-Version^/z value = ^!f 2.0 /&gt;</td>

[0251] &lt;SECURITYLEVEL name = Server-SKU value /&gt;

22222-3333〃

<td>[0252][0253][0254][0255][0256][0257]ADDRESS&gt;</td><td>&lt;/ISSUER&gt;&lt;DISTRIBUTIONPOINT&gt;&lt;OBJECT type = LICENSE ACQUISITION URL&gt; &lt;ID type = QUID&gt; {0F4... }&lt;/ID&gt;&lt;NAME&gt;DRM Server Cluster&lt;/NAME&gt;&lt;ADDRESS type = URL http: //localhost/Licensing/</td>

[0258]

[0259]

[0260]

[0261]

[0262]

[0263]

[0264]

[0265]

[0266]

[0267]

[0268]

[0269]

[0270]

[0271]

AUTHDATA&gt;

&lt;/0BJECT&gt;

&lt;/DISTRIBUTI0NP0INT&gt;

&lt;W0RK&gt;

&lt;0BJECT type = TEST-FORMAT&gt; &lt;ID type = MYID &gt;FDB-1&lt;/ID&gt;

&lt;/OBJECT&gt;

&lt;METADATA&gt;

&lt;SKU type = PIDTYPE &gt;PID&lt;/SKU&gt;

&lt;/METADATA&gt;

&lt;PRECONDITIONLIST&gt;

&lt;TIME/&gt;

&lt;/PRECONDITIONLIST&gt;

&lt;/WORK&gt;

&lt;AUTHDATA name = Encrypted Rights data &gt;PAB... &lt;/

<td>[0272][0273][0274][0275]</td><td>&lt;/BODY&gt;&lt;SIGNATURE&gt;&lt;ALGORITHM&gt;RSA PKCS#1-V1. 5&lt;/ALG0RITHM&gt;&lt;DIGEST&gt;</td>

CN 1521980 Β

[0276]

[0277]

[0278]

[0279]

[0280] &lt;/VALUE&gt;

[0281]

[0282] &lt;/VALUE&gt;

[0283]

[0284] &lt;ALG0RITHM&gt;SHA1&lt;/ALG0RITHM&gt;

&lt;PARAMETER name = codingtype&gt;

&lt;VALUE encoding = string&gt;surface-coding&lt;/VALUE&gt; &lt;/PARAMETER&gt;

&lt;VALUE encoding = base64 size = 160 &gt;Prc...= &lt;/DIGEST&gt;

&lt;VALUE encoding = base64 size = 1024 &gt;EHd...= &lt;/SIGNATURE&gt;

&lt;/XrMl&gt;