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

Abstract

PURPOSE: Digital content publishing for limiting content rendering/use within a defined group such as an universe based on a DRM(Digital Right Management) system is provided to allow/facilitate controlled rendering within an office or the universe sharing a document with individuals of the defined universe or a class. CONSTITUTION: Digital contents are encrypted by a content key(CK)(402). A right description associated with the digital contents is generated(406). To generate the (PU-DRM(CK)), the content key is encrypted by a public key for a DRM server(PU-DRM)(414). Digital signature is generated based on a private key matched with the (PU-DRM) through combination of the right description and the (PU-DRM(CK))(420).

Description

PUBLISHING DIGITAL CONTENT WITHIN A DEFINED UNIVERSE SUCH AS AN ORGANIZATION IN ACCORDANCE WITH A DIGITAL RIGHTS MANAGEMENT (DRM) SYSTEM}

<Reference to the associated application>

The following U.S. patent applications disclose the subject matter related to this application and are incorporated herein by reference:

Filed on the same page as this application under US patent application Ser. No. _________, Representative Dock No. MSFT-1569, entitled "Publishing Digital Content Within a Defined Group, such as an Organization, in accordance with a Digital Rights Management (DRM) System" Is;

Filed June 28, 2002, under U.S. Patent Application No. 10 / 185,527, Representative Docker No. MSFT-1330, entitled "SRL Acquisition of Signed Rights Label for Digital Content and SRL of Digital Rights Management System" Obtain a digital license corresponding to the content ";

Filed June 28, 2002, under US Patent Application No. 10 / 185,278, Representative Docker No. MSFT-1333, entitled "Signed Rights Label (SRL) for Digital Content in Digital Rights Management Systems Using Rights Templates" Acquisition ";

Filed June 28, 2002, under US Patent Application No. 10 / 185,511, Representative Docker No. MSFT-1343, entitled "Use License Issuance System and Method for Digital Content and Services."

<Technology field>

The present invention relates to a digital rights management (DRM) system. More specifically, the present invention defines a defined population as described above such that the rendering and use of content within a defined universe such as an organization, office, company, etc. may be limited in accordance with the corresponding use or license term. It relates to using a DRM system to publish digital content within.

Digital rights management and enforcement is highly desirable with respect to digital content, such as digital audio, digital video, digital text, digital data, digital multimedia, and the like, which can be distributed to one or more users. Digital content may be static, for example, as a text document, or streamed, such as streamed audio / video of live events. Typical distribution modes include tangible devices such as magnetic (floppy) disks, magnetic tapes, optical (compact) disks (CDs), and the like, and intangible media such as bulletin boards, electronic networks, the Internet, and the like. While being received by the user, the user renders or 'plays' the digital content with the help of a suitable rendering device, such as a media player on a personal computer.

In one scenario, content owners or rights owners, such as authors, publishers, broadcasters, etc., wish to distribute such digital content to each of many users or recipients in exchange for a license fee or some other cost. do. In such a scenario, the content may be a song, a song album, a movie, etc., and the distribution purpose is to generate a license fee. Such content owners, if given the choice, will want to limit what a user can do with such distributed digital content. For example, a content owner would like to restrict a user from copying and redistributing such content to a second user in a manner that does not give the content user a license fee from at least the second user.

In addition, the content owner may wish to provide the user with the flexibility to purchase different types of use licenses at different license fees while at the same time keeping the user of the duration of all kinds of licenses actually purchased. For example, a content owner might want to ensure that the distributed digital content can only be played for a limited number of times, for a predetermined total time, only on certain types of machines, on certain types of media players, only by certain types of users, and the like. Can be.

In another scenario, a content developer, such as an employee or member of an organization, wishes to distribute such digital content to one or more other employees or members of the organization, or to other individuals outside the organization, but others We do not want to render the content. Here, the distribution of content is to an organization-based content that is shared in a secret or limited manner, in contrast to broad-based distribution, in exchange for a license fee or some other cost. Closer.

In such a scenario, the content can be a document presentation, a spreadsheet, a database, an email, etc., which can be replaced within an office setting, and the content developer can maintain the content within an organization or office setting, eg For example, you may want to make it impossible to render to unauthorized individuals such as competitors or enemies. Again, such content developers would like to limit what recipients can do with such distributed digital content. For example, a content owner would like to restrict a user from copying and redistributing such content to a second user, in a manner that exposes content that is at least outside the range of individuals that should be allowed to render the content.

In addition, content developers may wish to provide different levels of rendering rights to various recipients. For example, a content developer may want to make protected digital content viewable but not printable for one class of individuals, and printable while viewable for other classes of individuals.

In either scenario, however, after distribution has occurred, such content owner / developer has little control over the digital content. This is required for virtually every personal computer to make an accurate digital copy of this digital content, download the exact digital copy to a writable magnetic or optical disk, or send the exact digital copy to a given destination via a network such as the Internet. The fact that it includes software and hardware is particularly problematic.

Of course, as part of the transaction in which the content is distributed, the content owner / developer may require the user / recipient of the digital content to promise not to redistribute such digital content in an unwelcome manner. However, these promises are easily made and easily destroyed. Content owners / developers may attempt to prevent such redistribution through some known security device that generally involves encryption and decryption. However, it is almost impossible to allow a lightly determined user to decrypt encrypted digital content, keep such digital content in an unencrypted form, and then redistribute it.

Therefore, there is a need to provide a digital rights management (DRM) and enforcement architecture and method that allows for controlled rendering or playing of any form of digital content, the control being flexible to be provided by the content owner / developer of the digital content. Flexible and definable More specifically, there is a need for an architecture that allows and facilitates controlled rendering, especially in an office or organization where documents are shared among individuals of a defined group or individuals of a class.

1 is a block diagram illustrating an exemplary non-limiting computing environment in which the present invention may be implemented.

2 is a block diagram illustrating an exemplary network environment having various computing devices in which the present invention may be implemented.

3 is a functional block diagram of one embodiment of a system and method in accordance with the present invention for publishing digital content.

4 is a flowchart of one embodiment of a method in accordance with the present invention for publishing rights-managed digital content.

4A is a block diagram illustrating the structure of a signed rights label as generated by the method of FIG.

5 is a block diagram of one embodiment of a system and method in accordance with the present invention for licensing rights managed digital content.

6A and 6B are flowcharts of one embodiment of a method in accordance with the present invention for licensing rights managed digital content.

FIG. 7 is a flowchart showing the critical steps performed upon re-publishing of an authority label in accordance with an embodiment of the present invention. FIG.

8 is a block diagram illustrating a certificate issued to a user by a DRM server to enable a user to use offline publishing in accordance with one embodiment of the present invention.

FIG. 9 is a block diagram illustrating rights template designation information to be incorporated into a rights label in accordance with an embodiment of the present invention. FIG.

FIG. 10 is a flowchart illustrating the critical steps performed when generating the rights template of FIG. 9 and generating the signed rights label of FIG. 4A based on the rights template, in accordance with an embodiment of the present invention. FIG.

11 is a block diagram illustrating an enforcement architecture of one example of a trust based system.

12 is a block diagram illustrating that a licensor processes a request for a license in accordance with one embodiment of the present invention.

FIG. 13 is a flow diagram illustrating the steps performed by the licensor of FIG. 12 in relation to a directory when issuing a license.

FIG. 14 is a flow diagram illustrating the steps performed by the licensor of FIG. 12 when introducing a policy into a license to be issued.

<Explanation of symbols for the main parts of the drawings>

100: computing system environment

120: processing unit

130: system memory

121: system bus

302: content preparation application

304: encrypted digital content

306: DRM Client API

308: Signed Authority Label

310: Rights managed digital content

320: DRM server

330: communication network

The above mentioned needs are at least partly met by the present invention in which the licensor issues a digital license to the requester so that the requester can render the corresponding digital content. In the present invention, the licensor accesses a directory containing a list for the requestor, the list including an identifier of the requester and an identifier of each group of which the requestor is a member.

The licensor receives a request from the requester, the request comprising an identifier identifying the requester, and authorization data associated with the content, the authorization data listing at least one identifier and the authorization associated with it. The licensor then locates the requestor's identifier in the directory and, from the requestor identifier located in the directory, locates in the directory the identifier of each group of which the requester is a member thereof. Each located requestor identifier and each located group identifier is compared with each identifier listed in the authorization data to find a match, and a license is issued to the requestor having the rights associated with the match identifier.

The foregoing description, and the following detailed description of embodiments of the invention, may be better understood with reference to the accompanying drawings. For the purpose of illustrating the invention, a preferred embodiment is shown. However, the present invention is not limited to the precise configuration and means shown.

Computer environment

1 and the following description are intended to provide a brief description of suitable computing environments in which the present invention may be implemented. However, it should be understood that handheld, portable, and all sorts of other computing devices may be considered for use in connection with the present invention. Although a general purpose computer is described below, it is just one example, and the present invention only needs a thin client with network server interoperability and interaction. Therefore, the present invention can be realized in an environment of networked hosted services involving little or no client resources, i.e., in a network environment where the client device only acts as a browser or interface to the World Wide Web.

Although not required, the invention may be realized through an application programming interface (API) for use by a developer, and / or executed by one or more computers, such as client workstations, servers, or other devices. It can be included in network browsing software that can be described in the general context of computer-executable instructions, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or execute particular abstract data types. Typically, the functionality of the program modules may be combined or distributed as required in various embodiments. In addition, those skilled in the art will appreciate that the present invention may be practiced with other computer system configurations. Other well-known computing systems, environments and / or configurations that may be suitable for use with the present invention include personal computers (PCs), automated teller machines (ATMs), server computers, hand-held or laptop devices, multi Processor systems, microprocessor-based systems, programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network or other data transmission medium. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

Therefore, Figure 1 illustrates an example of a suitable computing environment 100 in which the present invention may be implemented, and as will be apparent from the above, the computing system environment 100 is only one example of a suitable computing environment and uses of the present invention. It is not intended to suggest any limitation as to scope or functionality. Computing environment 100 should not be construed as having any dependencies or requirements with respect to any one or combination of components shown in exemplary operating environment 100.

Referring to FIG. 1, an exemplary system for realizing the present invention includes a general purpose computing device in the form of a computer 100. Components of the computer 100 may include a system bus 121 that connects various system components, including the processing unit 120, system memory 130, and system memory, to the processing unit 120, It is not limited to this. System bus 121 may be any of several types of bus structures, including a memory bus or a memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. For example, these architectures include Industry Standard Architecture (ISA) buses, Micro Channel Architecture (MCA) buses, Enhanced ISA (EISA) buses, Video Electronics Standards Association (VESA) local buses, and Peripheral Component Interconnect (PCI) buses (Mezzanine). Also known as a bus).

Computer 110 typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by computer 110 and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, computer readable media may include, but are not limited to, computer storage media and communication media. Computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media may include RAM, ROM, EEPROM, flash memory or other memory technology, CDROM, Digital Versatile Disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other Magnetic storage device, or any other medium that can be used to store desired information and can be accessed by computer 110, but is not limited to such. Computer media typically implements computer readable instructions, data structures, program modules, or other data in modulated digital signals, such as carrier waves or other transmission mechanisms, and includes any information delivery media. The term "modulated data signal" means a signal that has one or more of its own set of characteristics or changed in such a manner as to encode information in the signal. For example, communication media includes, but is not limited to, wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared, and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.

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. Basic input / output system 133 (BIOS), which includes a basic routine that assists in transferring information between elements in computer 110, for example during start-up, is typically stored in ROM 131. . RAM 132 typically includes data and / or programs that are readily accessible to processing unit 120 and / or currently being operated by processing unit 120. For example, FIG. 1 illustrates an operating system 134, an application 135, other program modules 136, and program data 137, but is not limited to such.

Computer 110 may also include other removable / removable, volatile / nonvolatile computer storage media. By way of example only, FIG. 1 illustrates a hard disk drive 141 that reads or writes from a removable nonvolatile magnetic medium, a magnetic disk drive 151 that reads or writes from a removable nonvolatile magnetic disk 152, and a CD. Shows an optical disk drive 155 that reads from or writes to a removable nonvolatile optical disk 156, such as a ROM or other optical medium. Other removable / removable, which may be used in an exemplary operating environment, Volatile / nonvolatile computer storage media include, but are not limited to, magnetic tape cassettes, flash memory cards, DVDs, digital video tapes, solid state RAMs, solid state ROMs, and the like. Hard disk drive 141 is typically connected to system bus 121 via a non-removable memory interface, such as interface 140, and magnetic disk drive 151 and optical disk drive 155 typically have an interface ( Is connected to the system bus 121 by a removable memory interface such as 150.

The drive and associated computer storage media described above and shown in FIG. 1 provide storage of computer readable instructions, data structures, program modules, and other data for the computer 110. In FIG. 1, for example, hard disk drive 141 is shown to store operating system 144, application 145, other program modules 146, and program data 147. Note that these components may be the same as or different from operating system 134, application 135, other program modules 136, and program data 137. Operating system 144, application 145, other program module 146, and program data 147 are given different numbers here, at least to indicate that they are different copies. A user may enter commands and information into the computer 110 through input devices such as a keyboard 162 and pointing device 161, commonly referred to as a mouse, trackball or touchpad. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are frequently connected to the processing unit 120 via a user input interface 160 connected to the system bus 121, but other interfaces such as parallel ports, game ports or universal serial bus (USB). And by a bus structure.

The monitor 191 or other type of display device is also connected to the system bus 121 via an interface such as the video interface 190. Graphical interface 182, such as Northbridge, may also be connected to system bus 121. Northbridge is a chipset that communicates with the CPU or host processing unit 120 and is responsible for Accelerated Graphics Port (AGP) communication. One or more graphics processing units (GPUs) 184 may be in communication with the graphical interface 182. In this regard, GPU 184 generally includes on-chip memory storage, such as register storage, and GPU 184 is in communication with video memory 186. However, since the GPU 184 is only one example of a coprocessor, various coprocessing devices may be included in the computer 110. The monitor 191 or other type of display device is also connected to the system bus 121 via an interface, such as video interface 190, which can alternately communicate with video memory 186. In addition to the monitor 191, the computer may likewise include other peripheral output devices such as a speaker 197 and a printer 196 that may be connected via an output peripheral interface 195.

Computer 110 may operate in a network environment using logical connections to one or more remote computers, such as remote computer 180. Remote computer 180 may be a personal computer, server, router, network PC, peer device, or other conventional network node, although only memory storage 181 is shown in FIG. Multiple or all of the elements described above with respect to 110. The logical connection shown in FIG. 1 includes a local area network (LAN) 171 and a wide area network (WAN) 173, but may include other networks. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.

When used in a LAN networking environment, the computer 110 is connected to the LAN 171 via a network interface or adapter 170. When used in a WAN networking environment, the computer 110 typically includes a modem 172 and other means for establishing communications over the WAN 173, such as the Internet. The modem 172, which may be internal or external, may be connected to the system bus 121 via the user input interface 160 or other suitable mechanism. In a networked environment, program modules depicted in connection with the computer 110, or portions thereof, may be stored in the remote memory storage device. For example, FIG. 1 illustrates a remote application 185 residing in the memory device 181, but is not limited thereto. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers can be used.

Those skilled in the art will appreciate that computer 110 or other client device may be deployed as part of a computer network. In this regard, the present invention belongs to any computer system having any number of memory or storage units and having any number of applications and processes that occur across any number of storage units or volumes. The present invention is applicable to an environment with server computers and client computers deployed in a network environment with remote or local storage. The invention is also applicable to standalone computer devices having programming language capabilities, translation and execution capabilities.

Distributed computing facilitates sharing of computer resources and services by direct exchange between computing devices and systems. These resources and services include information exchange, cache storage, and disk storage for files. Distributed computing takes advantage of network connectivity, allowing clients to exercise their collective ability to benefit the entire enterprise. In this regard, various devices may have applications, objects, or resources that can interact to relate the authentication techniques of the present invention to trusted graphics pipeline (s).

2 provides a schematic diagram of an example network or distributed computing environment. Distributed computing environments include computing objects 10a, 10b, and the like, and computing objects or devices 110a, 110b, 110c, and the like. These objects can include programs, methods, data storage, programmable logic, and the like. The objects may include some of the same or different devices, such as a PDA, television, MP3 player, personal computer, and the like. Each object may communicate with other objects by the communication network 14. The network may include other computing objects and computing devices that provide services to the system of FIG. 2. In accordance with aspects of the present invention, each object 10 or 110 may include an application that may request the authentication technique of the present invention for trusted graphics pipeline (s).

It will also be appreciated that object 110c may be hosted on other computing device 10 or 110. Thus, although the depicted physical environment may depict a connected device, such as a computer, such illustration is illustrative only, and the physical environment may alternatively be various digital devices such as PDAs, TVs, MP3 players, etc. It may be depicted or described as including the same software object.

There are several systems, components, and network configurations that support distributed network environments. For example, computing systems may be connected together by wired or wireless systems, by local networks or widely distributed networks. Currently, many networks provide an infrastructure for widely distributed computing and are connected to the Internet covering many different networks.

In a home networking environment, there are at least four separate network transmission media that can each support unique protocols such as power lines, data (wireless and wired), voice (eg, telephone), and entertainment media. Most home control devices, such as light switches and appliances, can use power lines for connection. Data services can enter your home as a broadband (eg DSL or cable modem) and provide wireless (eg HomeRF or 802.11b) or wired (eg Home PNA, Cat5, or even power line) connections. To access within the home. Voice traffic can enter the home wired (eg, Cat3) or wireless (eg, cell phones) and can be distributed within the home using Cat3 wired. Entertainment media can enter the home via satellite or cable and are typically distributed within the home using coaxial cable. IEEE 1394 and DVI are also emerging as digital interconnects for clusters of media devices. All these network environments, and others that can emerge as protocol standards, can be interconnected to form an intranet that can be connected to the outside world by the Internet. In short, several separate sources exist for the storage and transmission of data, and thus, further, computing devices will require a method of protecting content in all parts of the data processing pipeline.

The 'Internet' generally refers to a collection of networks and gateways using TCP / IP suites of protocols well known in the field of computer networking. TCP / IP stands for "Transport Control Protocol / Interface Program." The Internet can be described as a system of geographically dispersed remote computer networks interconnected by computers running networking protocols that allow users to interact over the network and share information. Because of this extensive sharing of information, remote networks, such as the Internet, have evolved significantly into open systems that allow developers to design software applications to execute specialized operations or services without any restrictions.

Therefore, the network infrastructure allows for the hosting of network topologies such as client / server, peer-to-peer, or hybrid architectures. A "client" is a member of a class or group that uses a service of another class or group that is not relevant. Therefore, in computing, one client is one process, that is, generally a set of instructions or tasks that request a service provided by another program. The client process uses the requested service without having to "know" certain task details about another program or the service itself. In a client / server architecture, particularly network systems, a client is usually a computer that accesses shared network resources provided by other computers, for example servers. In the example of FIG. 2, the computer 110a, 110b, etc. may be considered a client, the computer 10a, 10b, etc. may be considered a server, and the server 10a, 10b, etc. may then be considered a client computer 110a. , 110b, etc.).

Servers are typically remote computer systems accessible through a remote network such as the Internet. The client process may be operated within the first computer system, the server process may be operated within the second computer system, and may communicate with each other via a communication medium to provide distributed functionality, and multiple clients may provide information about the server. -Make the collection ability available.

The client and server communicate with each other using the functionality provided by the protocol layer. For example, Hypertext-Transfer Protocol (HTTP) is a common protocol used with the World Wide Web (WWW). Typically, computer network addresses, such as Universal Resource Locator (URL) or Internet Protocol (IP) addresses, are used to identify servers or client computers from each other. The network address may be referred to as a URL address. For example, communication may be provided via a communication medium. In particular, the client and server may be connected to each other via a TCP / IP connection for high capacity communication.

Therefore, FIG. 2 illustrates an exemplary network or distributed environment with servers in communication with client computers over a network / bus in which the present invention may be used. More specifically, multiple servers (10a, 10b, etc.) are portable computers, handheld computers, thin clients, via a communication network / bus 14, which may be a LAN, WAN, intranet, Internet, etc., in accordance with the present invention. , Interconnected with a number of client or remote computing devices 110a, 110b, 110c, 110d, 110e, etc., such as networked electrical appliances, or other devices such as VCRs, TVs, ovens, lights, heaters, and the like. Therefore, the present invention can be applied to any computing device associated with desirably processing, storing or rendering secure content from a trusted source.

In a network environment where the communication network / bus 14 is the Internet, for example, server 10 may communicate with clients 110a, 110b, 110c, 110d, 110e, etc. via any of a number of known protocols such as HTTP. It can be a web server. Server 10 may also act as client 110, as may be characteristic of a distributed computing environment. The communication can be wired or wireless as appropriate. The client device 110 may or may not communicate over the communication network / bus 14, or may have independent communication associated with it. For example, in the case of a TV or VCR, it may or may not be a networked aspect to its control. Each client computer 110 and server computer 10 may be equipped with a variety of application program modules or objects 135, and various types of files may be stored or portion (s) of the files may be downloaded or moved. The connection or access to the storage element or object of the can be made. Thus, the present invention is directed to a client computer (110a, 110b, etc.) capable of accessing and interacting with a computer network / bus 14, a server computer (10a, 10b, etc.) capable of interacting with a client computer (110a, 110b, etc.), And other device 111 and database 20 may be utilized in a computer network environment.

Digital Rights Management (DRM) Overview

Referring now to FIG. 11, as is known, digital rights management (DRM) and enforcement are highly desirable with respect to digital content 12, such as digital audio, digital video, digital text, digital data, digital multimedia, and the like. Digital content 12 may be distributed to users. While being received by the user, this user renders or 'plays' the digital content with the help of a suitable rendering device, such as a media player on the personal computer 14.

Typically, a content owner or developer (hereinafter 'owner') who distributes such digital content wants to limit what a user can do with such digital content 12. For example, a content owner may wish to restrict a user from copying and redistributing such content 12 to a second user, or for a certain total amount of time, only a certain number of times the distributed digital content 12 is limited, It may be possible to play only on a machine of a certain type, and only on a certain kind of media player, by a certain kind of user or the like.

However, after distribution has occurred, such content owners have little control over the digital content. The DRM system 10 then allows for controlled rendering or playing of any type of digital content 12, which control is flexible and definable by the content owner of the digital content. Typically, content 12 is distributed to the user in the form of package 13 by any suitable distribution channel. The distributed digital content package 13 is digital content encrypted with a symmetric encryption / decryption key (KD) (ie, (KD (CONTENT))), as well as other information identifying the content, how to license such content, and the like. And (12).

The trust-based DRM system 10 allows the owner of the digital content 12 to specify license rules that must be met before such digital content 12 is allowed to be rendered on the user's computing device 14. Such licensing rules may include the temporary requirements described above, which the user / user's computing device 14 (hereafter these terms are replaceable unless the situation requires otherwise) must be obtained from the content owner or agent. It may be embodied in a digital license or use document (hereinafter referred to as "license"). This license 16 also includes a decryption key KD for decrypting the encrypted digital content, if possible, in accordance with the key decipherable by the user's computing device.

The content owner for the digital content 12 indicates that the user's computing device 14 will comply with the rules and requirements specified by this content owner in the license 16, ie the rules and requirements in the license 16. If this is not satisfied, it must be trusted that digital content 12 will not be rendered. Then, preferably, the user's computing device 14 may render the digital content 12 except for following the license rules associated with the digital content 12 and implemented in the license 16 obtained by the user. A trusted component or mechanism 18 is provided that is not present.

The trusted component 18 typically determines whether the license 16 is valid, reviews the license rules and requirements within this valid license 16, and requests the user to request based on the reviewed license rules and requirements. Among others, it has a license evaluator 20 that determines whether it has the right to render the requested digital content 12 in a searched manner. As can be appreciated, the license evaluator 20 is trusted within the DRM system 10 to implement the wishes of the owner of the digital content 12 in accordance with the rules and requirements of the license 16, and the user It should not be possible to easily change this trust component for any purpose, conspiracy or vice versa.

As can be appreciated, the rules and requirements in the license 16 include who the user is, where the user is located, what kind of computing device the user is using, what rendering application is calling the DRM system, It may be specified whether the user has the right to render the digital content 12 based on some predetermined factors, including date, time, and the like. In addition, the rules and requirements of license 16 may limit license 16 to, for example, a predetermined number of plays or a predetermined play time.

Rules and requirements may be specified in license 16 in accordance with any suitable language and syntax. For example, the language simply specifies the attributes and values that must be satisfied (for example, DATE must be later than X), or the specified script (for example, IF DATE greater than X, THEN DO ... It may require performance of the function according to,).

If the license evaluator 20 determines that the license 16 is valid and the user satisfies the rules and requirements therein, the digital content 12 may be rendered. In particular, in order to render the content 12, the decryption key KD is obtained from the license 12 and is applied to the (KD (CONTENT)) from the content package 13 to generate the actual content 12, The actual content 12 is then actually rendered.

Digital Content Publishing

3 is a functional block diagram of one embodiment of a system and method in accordance with the present invention for publishing digital content. The term "publishing" as used herein refers to who can be issued a set of rights and conditions, as well as a set of rights and conditions that this entity can publish for its content as a trusted entity. Refers to the process followed by an application or service. According to the present invention, the publishing process includes encrypting digital content and associating a list of continuous enforceable rights prepared by the creator of the content for all possible users of the content. This process can be executed in a secure manner that prohibits access to any rights or access to content unless intended by the author of the content.

In one embodiment of the invention, in particular three entities may be used for publishing secure digital content: a content preparation application 302 which also prepares content for execution and publishing on the client 300, and also the client device. A digital rights management (DRM) application program interface (API) 306 residing at 300, a DRM server 320 communicatively coupled to the client 300 via a communications network 330. In one embodiment of the invention, it can be appreciated that the communication network 330 may be any local area network or wide area network, such as a proprietary intranet, for example, but the communication network 330 includes the Internet.

The content preparation application 302 can be any application that generates digital content. For example, the application 302 may be another publisher or word processor that generates digital text files, digital music, video or other content. The content may also include streamed content such as, for example, streamed audio / video of a live or taped event. According to the present invention, a content preparation application allows its user to encrypt content using a key provided by that user. Application 302 uses a key to encrypt digital content, thus forming encrypted digital content file 304. The client application also allows the user to provide authorization data for the digital content file 304. The authorization data includes a respective identity for each entity having the authority of the digital content.

Such an entity may be, for example, a person, a class of individuals, or a device. For each such entity, the authorization data also includes a list of privileges that entity has in the content, and any condition that may be imposed on any or all of these privileges. Such rights may include the right to read, edit, copy, print, etc. digital content. Incidentally, authority may be inclusive or exclusive. Inclusion rights indicate that a particular user has certain rights in the content (eg, the user can edit the digital content). Exclusive rights indicate that a particular user has all rights in the content except those specified (eg, a user can do everything except copy it to digital content).

According to one embodiment of the invention, the client API 306 may send the encrypted digital content and authorization data to the DRM server 320. Using the process described below, the DRM server 320 determines whether the user can enforce the rights granted to it, and if so, the DRM server 320 authorizes to form a signed rights label (SRL) 308. Sign the data. In general, however, any trusted entity may preferably sign authorization data using a key trusted by the DRM server 320. For example, the client can sign the authorization data using the key provided to the client by the DRM server 320.

The entitlement label 308 can include an entitlement description, an encrypted content key, and data indicative of the entitlement description and the digital signature via the encrypted content key. If the DRM server is signing an authorization label, the DRM server sends the signed authorization label 308 back to the client via the client API 306 which stores the signed authorization 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, SRL 308 may be associated with encrypted digital content to form rights managed content file 310.

In general, however, authorization data need not be combined with digital content. For example, the authorization data can be stored in a known location, and a reference to the stored authorization data can be combined with encrypted digital content. A reference identifies an identifier that indicates where authorization data is stored (eg, a data store containing authorization data), and corresponds to that particular authorization data at that particular storage location (eg, specific authorization data of interest). An identifier identifying the containing file). The rights management content 310 can then be delivered to anyone in any place, and only those entities with the right to consume the content can consume the content only in accordance with the rights they have been assigned.

4 is a flowchart of an exemplary method 400 in accordance with the present invention for publishing rights management digital content, wherein a rights label is signed by a DRM server. However, it will be appreciated that this embodiment is merely exemplary and that an authorization label may generally be signed by any trusted entity. In general, the method according to the invention for publishing digital content comprises the steps of: encrypting the digital content using a content key (CK), generating a rights description associated with the digital content, (PU-DRM (CK)) Encrypting the content key (CK) according to the public key for the DRM server (PU-DRM) in order to produce a digital signature, and corresponding to the (PU-DRM) through a combination of an authorization description and (PU-DRM (CK)) Generating a digital signature based on the private key.

In step 402, application 302 generates a content key CK that is used to encrypt digital content. In general, although any key can be used to encrypt digital content, the content key CK is preferably a symmetric key. Symmetric key algorithms, sometimes referred to as "secret key" algorithms, use the same key to decrypt a message as they do to encrypt the message. For that reason, it is desirable that (CK) be kept secret. Sharing (CK) between the sender and receiver should be done very carefully to avoid intercepting this (CK) without permission. Since (CK) is shared between the encryptor and the decryptor, (CK) is preferably communicated before any encrypted message is sent.

Several symmetric key generation algorithms are well known in the art. It can be appreciated that any symmetric algorithm can be used, but in one embodiment a data encryption standard (DES) is employed. Examples of such symmetric key algorithms include, but are not limited to, AES, Triple-DES, International Data Encryption Algorithm (IDEA), Cast, Cast-128, RC4, RC5, and SkipJack.

In step 404, application 302 encrypts the digital content with a symmetric content key (CK) to form encrypted digital content 304 that can be written using a notation (CK). Authors using the application 302 may also generate authorization data associated with the digital content. The entitlement data includes a list of entities that may be entitled to consume the content, and certain entitlements that each entity possesses with respect to the content, along with any conditions that may be imposed on a particular entitlement. Such rights may include, for example, viewing of content, printing of content, and the like. Application 302 provides authorization data to API 306. One example of authorization data in XML / XrML format is attached herein as Attachment 1.

In step 406, the API 306 generates a second encryption key DES1 used to encrypt the content key CK. Preferably, (DES1) is also a symmetric key. In step 408, API 306 encrypts (CK) with (DES1) to result in (DES1 (CK)). In step 410, the API 306 discards (CK), with the result that CK can now only be obtained by decrypting (DES1 (CK)). API 306 to ensure that (CK (content)) can be protected for the central DRM server 320 and that all "license requests" for content can be made centrally in accordance with the authorization data. In step 412, it contacts the provided DRM server 320 to retrieve its public key (PU-DRM). In step 414, the API 306 encrypts (DES1) with (PU-DRM), resulting in (PU-DRM (DES1)). Therefore, as required to decrypt (CK (content)), to ensure that the DRM server 320 is the only entity capable of access to (CK), (CK) is (PU-DRM) Can be protected against. In step 416, the API 306 encrypts the authorization data (i.e., the list of authorized entities, and the respective permissions and conditions associated with each authorized entity within that list) with (DES1) and (DES1 ( rightsdata)).

In alternative embodiments, (CK) may be used to directly encrypt authorization data, resulting in (CK (rightsdata)), and (PU-DRM) may be used to directly encrypt (CK) to (PU-DRM ( CK)), which completely suspends the use of (DES1). However, using (DES1) to encrypt authorization data and (CK) allows that (DES1) to follow any specific algorithm that can follow the DRM server, while (CK) is associated with the DRM server. May be specified by an independent entity and may not follow it.

In step 418, the content protection application 302 may submit (PU-DRM (DES1)) and (DES1 (rightsdata)) to the DRM server 320 as an authorization label for signature. Alternatively, the client itself can sign the authorization data. If the authorization data is being submitted to the server for signature, at step 420, the DRM server 320 verifies that it can access the authorization data and enforce the rights and conditions of the submitted authorization label. To verify that the authorization data can be enforced, the DRM server 320 applies (PR-DRM) to (PU-DRM (DES1)) to generate (DES1), then (DES1) to (DES1). (rightsdata)) to generate rights data in the empty place. Server 320 may then make any policy checks to verify that the users, rights, and conditions specified in the authorization data are within any policy enforced by server 320. The server 320 signs the originally submitted rights label that includes (PU-DRM (DES1)) and (DES1 (rightsdata)), resulting in a signed rights label (SRL) 308 (here: Returns the SRL 308 back to the API 306, and then provides the returned SRL 308 to the client application 302, which is based on the private key (PR-DRM) of the DRM server 320). .

SRL 308 is a digitally signed document that is protected from modification. Incidentally, the SRL 308 maintains a strong 1-1 relationship to the content it is protecting, regardless of the actual key type and algorithm used to encrypt the content. Referring now to FIG. 4A, in one embodiment of the present invention, SRL 308 is inter alia; Information on the content underlying the SRL 308, possibly including the ID of the content; Information on the DRM server signing the SRL 308, including (PU-DRM (DES1)), and referral information such as URL for placing the DRM server on the network and coping information in case of a URL failure; Information describing the SRL 308 itself; (DES1 (rightsdata)) :( DES1 (CK)); And S (PR-DRM). Sample SRL 308 of XML / XrML is attached herein as Attachment 2.

To ensure that the trusted entity signs the authorization data to produce a signed authorization label 308, the DRM server is subject to a period of time announced by the issuer as described in the authorization data of the authorization label 308. It is announcing that it will issue a license for the content. As can be seen, the user is required to obtain a license in order to render the content, especially since the license includes a content key CK. When a user wants to obtain a license for encrypted content, he or she will present a license request that includes an SRL for content (308), and a certificate that verifies the user's credentials to the DRM server 320 or other license issuing entity. Can be. The license issuing entity then decrypts (PU-DRM (DES1)) and (DES1 (rightsdata)) to generate entitlement data, and lists all entitlements granted by the author (if any) to the license requesting entity, You can only configure licenses with these designated rights.

Preferably, when application 302 receives SRL 308, such application 302 associates the signed rights label 308 with a corresponding (CK) content to manage digital content. To form. Alternatively, the authorization data may be stored at a known location with a reference to a known location where encrypted digital content is provided. Therefore, the DRM-enabled rendering application may find the signed authorization label 308 through the portion of the content that the rendering application is attempting to render. This discovery triggers the rendering application to initiate a license request for the DRM licensing server 320. For example, the publishing application 302 may store the URL for the DRM licensing server 320 or the DRM licensing server 320 may include its URL as part of the metadata into the authorization label prior to the digital signature. As such, the DRM client API 306 called by the rendering application may identify the correct DRM licensing server 320. For example, a unique identifier, such as a globally unique identifier (GUID), is preferably inserted into the rights label before it is signed.

In one embodiment of the present invention, a simple object access protocol (SOAP) may be used for communication between the content protection application 302 or rendering application and the DRM server 320. In addition, an API library such as API 306 may be provided so that an application such as application 302 is not required to implement the client side of the DRM protocol, but can only make local API calls. While it will be appreciated that any suitable format may be used for the rights description and other data, it is desirable to use the XrML, XML language to describe rights descriptions, licenses and rights labels for digital content.

Obtain a license for published content

5 is a functional block diagram of one embodiment of a system and method in accordance with the present invention for licensing rights management digital content. The term "licensinh" refers herein to a process followed by an application or service to request and receive a license that may enable an entity named in a license to consume content in accordance with conditions specified in the license. Input to the licensing process may include a signed rights label (SRL) associated with the content for which a license is being requested, and the public key certificate (s) of the entity (s) for which the license is being requested. Note that the entity requesting a license does not have to be the entity for which the license is being requested. Typically, the license includes an authorization statement from SRL 308, an encrypted key capable of decrypting the encrypted content, and a digital signature via the authorization statement and the encrypted key.

One way in which the application 302 consumes rights management content 310 is that the client API 306 sends the signed rights label 308 of the rights management content 310 via the communication network 330 to the DRM server 320. Will be sent to. The location of the DRM server 320 may be found, for example, in reference information within the SRL 308. In such an embodiment, the process described below allows the DRM licensing server 320 to determine whether to issue a license using the rights description in the rights label, and if so, to derive the rights description for inclusion in the license. .

As described above, the authority label 308 includes a content key CK encrypted according to the public key (ie PU-DRM (CK)) of the DRM server 320 (PU-DRM). In the process of issuing a license, the DRM server 320 reliably decrypts this value to obtain (CK). Then, it uses the public key (PU-ENTITY) in the public key certificate that was overlooked at the license request to re-encrypt (CK) (i.e. (PU-ENTITY (CK)). ENTITY (CK)) is placed in the license by the server 320. Therefore, since only the owner of the associated private key (PR-ENTITY) can recover (CK) from (PU-ENTITY (CK)), The license can be returned to the caller without the risk of exposing the CK The client API 306 then decrypts the encrypted content using the CK to form the decrypted digital content 312. The client application 302 can then use the decrypted digital content 312 according to the rights provided in the license.

Alternatively, for example, a client, such as a publishing client, can issue its own license to consume the content. In such an embodiment, a secure process may be executed on the client computer providing the client with the key (s) needed to decrypt the digital content under appropriate circumstances.

6A and 6B provide a flowchart of one embodiment of a method 600 in accordance with the present invention for licensing rights management digital content. In accordance with the present invention, the requesting entity may submit a license request on behalf of one or more potential licensees. The requesting entity may or may not be one of the potential licensees. A potential license may be a person, group, device, or some other entity that can consume content in any way. Although the method 600 will now be described with respect to one embodiment where the DRM server processes a license request, it should be understood that license request processing may also be executed on the client and issued by the client directly.

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

In step 604, the requesting entity (ie, the entity generating the license request) is authenticated. According to one embodiment of the invention, the license issuing entity may be configured to determine the identity of the requesting entity using protocol (eg, challenge-response) authentication, or not to require authentication of the requesting entity (ie , Also known as "Allow anonymous authentication". If authentication is required, some form of authentication scheme may be used (e.g., a challenge-response scheme described above, a user ID and password scheme such as MICROSOFT.NET, PASSPORT, WINDOWS authentication, x509, etc.). Preferably, it not only supports certain protocol authentication schemes supported by the integrated information system. Anonymous authentication is allowed. The result of the authentication step may be, for example, an identity such as an "anonymous" identity (when anonymous authentication), or a personal account identity. If the license request cannot be authenticated for any reason, an error is returned and no license is granted.

In step 606, the authenticated entity is authorized-that is, in step 608 it is determined whether the authenticated entity has been granted a license request (on its own or on behalf of another entity). Preferably, the license issuing entity stores a list of entities for which the license request is authorized (or not authorized). In one embodiment, the identity in this identity list may be both, but rather the identity of the entity making the request, rather than the identity of the entity for which the license is being requested. For example, a personal account identity may be prohibited from making a license request directly, but a trusted server process may make a license request on behalf of such an entity.

According to the present invention, the license request may include a public key certificate or an identity for each potential licensee. If a license is requested for only one licensee, only one certificate or identity is named. If a license is requested for multiple licenses, a certificate or identity can be named for each potential licensee.

Preferably, the license issuing entity may have a public key certificate for each valid licensee. However, while application 302 wants to generate a license for a given user, application 302 may not be able to access the public key certificate for that user. In such a situation, the application 302 can specify a user identity at the time of the license request, so that the license issuing entity can perform a survey in the directory service to return the appropriate user's public key certificate. Module can be called

In step 608, if the issuing entity determines that the public key certificate is not included in the license request, the issuing entity uses the specified identity to determine the identity specified to conduct a survey in the directory service or database for the appropriate public key certificate. use. In step 610, if the issuing entity determines that the certificate is in the directory, 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 by the directory access protocol. If a certificate is not found for a given potential license, then within the request or directory, the license server does not generate a license for that potential license, and at step 614, an error is returned to the requesting entity.

If the license issuing entity has a public key certificate for at least one potential licensee, then in step 616 the issuing entity verifies the credit of the license certificate. Preferably, the issuing entity consists of a set of trusted certificate issuer certificates and determines whether the issuer of the license certificate is in the list of trusted issuers. In step 616, if the issuing entity determines that the issuer of the license certificate is not in the list of trusted issuers, the request fails for that license, and an error is generated in step 614. Therefore, any potential licensee whose certificate has not been issued by a trusted issuer cannot receive a license.

Incidentally, the issuing entity preferably performs digital signature verification for every entity in the certificate chain that proceeds from the trusted issuer certificate to the private licensee 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 potential license is not verified or the certificate in the chain is not verified, the license is not issued to that potential licensee because the potential licensee is not trusted. Otherwise, at step 618, a license may be issued. This process is repeated at step 620 until all entities for which a license is requested have been processed.

As shown in FIG. 6B, the license issuing entity proceeds to verify the signed rights label 308 received upon license request. In one embodiment, the issuing entity uses a rights label plug-in, and a back-up database, to store a master copy of all rights labels signed by the issuing entity on the server. The rights label is identified by the GUID placed within this label at the time of publication. At the time of license (at step 622), the issuing entity parses the rights label entered in the license request and retrieves its GUID. This GUID is then sent to the authority label plug-in to issue a query to the database to retrieve a copy of the master authority label. The master authorization label may be more recent than a copy of the authorization label sent at the time of the license request and may be the authorization label used at the time of the request in the following steps. If no authority label is found in the database based on the GUID, then the issuing entity checks its policy to determine if the issuance of the license is still authorized based on the authority label upon request in step 624. If this policy did not permit this, then the license request fails at step 626 and an error may be returned to API 306 at step 628.

At step 630, the license issuing entity checks the authorization label 308. If the digital signature on the authority label is verified, and the license issuing entity is not the issuer (signing entity) of the authority label, then the license issuing entity is a trusted entity (for example, the license issuing entity is not a key material). Entity to be shared). If the authorization label is not verified or is not issued by the trusted entity, then the license request fails in step 626 and an error may be returned to the API 306 in step 628.

After all confirmation has occurred, the license issuing entity converts the entitlement label 308 into a license for each approved licensee. In step 632, the license issuing entity generates respective rights descriptions for the licenses to be issued to each licensee. For each license, the issuing entity verifies the identity named in the license's public key certificate against the identity named in the authorization description in the authorization label. Right descriptions are assigned to every right or set of rights and to an identity set that can execute that right or set of rights within a license. For every privilege or set of privileges to which the license's identity is associated, that privilege or set of privileges is copied into a new data structure of the license. The data structure thus obtained is a description of the rights in the license for a particular licensee. As part of this process, the license issuing entity reviews certain prerequisites that may be associated with a given permission or set of rights within the rights description of the rights label. For example, an authorization may have a time prerequisite associated with an authorization restricting a license issuing entity from issuance of a license after a specified time. If the issuing entity needs to check the current time, if the time specified in the precondition has elapsed, the issuing entity is not able to issue that authority to the licensee, even if the licensee's identity is associated with that authority.

In step 636, the issuing entity obtains (PU-DRM (DES1)) and (DES1 (CK)) from the authority label 308 and applies (PR-DRM) to obtain (CK). The issuing entity then encrypts (CK) again using the licensee's public key certificate (PU-ENTITY), resulting in (PU-ENTITY (CK)). In step 638, the issuing entity associates the created authorization description with (PU-ENTITY (CK)) and digitally signs the final data structure using (PR-DRM). This signed data structure is the license for this particular licensee.

In step 640, if the issuing entity determines that there are no more licenses to generate for a particular request, the issuing entity may have zero or more licenses generated. The generated licenses are returned to the requesting entity in step 642 with the certificate chain associated with these licenses (eg, the server's own public key certificate as well as the certificate that issued its certificate).

In one embodiment of the system according to the invention, multiple licensor keys can be used. In such an embodiment, the encrypted content key CK entering into the license via the rights label 308 may actually be any data. One variant that is particularly useful is the use of a number of separate and encrypted content keys (CK), each associated with a different right or different person in the right description. For example, the digital versions of the songs of the album can all be encrypted with different keys (CK). These keys CK may be included in the same rights label, but one person may have the right to play a song (eg he may only have the right to obtain one key in his license), The second person may have the right to play all the songs (for example, she may have the right to get all the keys in her license).

Preferably, the system according to the present invention allows a publishing application / user to name a group or class of licenses in an authorization label 308. In this embodiment, the license issuing entity examines any group / class named in the entitlement label to determine if the current license identity is a member of that group / class. If a member is found within a named group / class, the issuing entity can add the permission or set of permissions associated with the group / class to the permission description data structure used in the license.

In one embodiment of the invention, the publishing and licensing protocol interface in the DRM server supports authentication and authorization of the calling application or user, and the management console for the DRM server allows an administrator to create access control lists for licensing and publishing interfaces. To be able. This allows the customer of the server to apply a policy that allows the user / application to publish, license, or both.

Change or republishing signed authority label 308

In one embodiment of the invention, SRL 308 may be "trial" if the user of the content has been given sufficient promise to do so. That is, if authorized, the user can change authorization data in SRL 308. In particular, permission to change authorization data should be granted infrequently and wisely, as a user who has been granted permission to change authorization data can basically grant himself broad rights in relation to the associated content. In my opinion, such a user may even authorize to expose content and send it to the world.

Here, the permission for change is indicated by including an indication in the authorization data in SRL 308 that a particular user or class of user can actually change or 'trial' the authorization data and authorization label 308. When the DRM server 320 receives an SRL 308 with this appointment in connection with a license request, the DRM server 320 encrypts the symmetric key DES1 encrypted according to the user's public key (ie, PU-ENTITY). In the user's requested license results in (PU-ENTITY (DES1)).

Therefore, to edit the authorization data in the SRL 308, referring now 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), (DES1 (rightsdata)) is retrieved from SRL 308 (step 705), and (DES1) is applied thereto to generate rights data (step 707). The user then changes the authorization data as desired (step 709) and submits the changed authorization data to the DRM server 320 in the manner described in connection with FIG. 4 to obtain a signed authorization label 308 (step 711). Of course, here, the signed rights label 308 is actually a trialed SRL 308, so that once the SRL 308 is received (step 713), the user detaches the original SRL 308 that is associated with the associated content. (Step 715), and then link the trialed SRL 308 to this content (step 717).

Thus, as can be seen, judging the SRL 308 allows the user to update the rights data in the SRL 308 that contains the rights, conditions, and users without having to change the associated content. In particular, the trial does not need to re-encrypt the associated content with a new (CK). In addition, the trial does not require the creation of a new SRL, especially because the original SRL 308 has many items that can be copied to the new SRL 308.

Self-publishing of signed rights label 308

In one embodiment of the invention, SRL 308 may be signed by the requesting user himself. Thus, the user does not need to contact the DRM server 320 to obtain an SRL 308 for the associated portion of the content. As a result, self-publishing is also referred to as off-line publishing. In such an embodiment, a user may be required to contact the DRM server 320 to request a license based on this self-published SRL 308. It is also to be understood that the publishing entity may be able to issue its own license.

In particular, referring now to FIG. 8, in this embodiment, the user is encrypted with the user's public key PU-CERT in order to generate (PU-ENTITY (PR-CERT)). And a DRM certificate 810 including a corresponding private key (PR-CERT) from the DRM server 320, which is first prepared to self-publish. This certificate must be signed by the private key (PR-DRM) of the DRM server 320 for verification by the DRM server 320, as described in more detail below. As can be seen, the DRM certificate 810 authorizes the user to self-publish. As can be seen, the key pairs (PU-CERT, PR-CERT) are separated from (PU-ENTITY, PR-ENTITY) and specifically used for self-publishing. The key pair (PU-CERT, PR-CERT) is the private key of the DRM server 320 so that the DRM certificate 810 contains only the user's public key (PU-ENTITY) and the DRM server 320 can verify it. It may not be used if signed by (PR-DRM).

Self-publishing differs from the publication shown in FIG. 4 in that the user basically takes the place of the DRM server 320 with respect to the steps performed. Importantly, the user submits a file containing (PU-DRM (DES1)) and (DES1 (rightsdata)) along with (PR-CERT) obtained from the DRM certificate 810 (i.e., S (PR-CERT)). Sign the authority label, resulting in (PU-ENTITY (PR-CERT)). As can be seen, the user obtains (PU-ENTITY (PR-CERT)) from this DRM certificate 810 and (PR-CERT) from DRM certificate 810 by applying (PR-ENTITY) to it. . However, especially because the user does not have a (PR-DRM) to apply to (PU-DRM (DES1)), the user cannot verify that the DRM server 320 can execute the rights in the submitted rights label. Please know that. Thus, the DRM server 320 itself must execute verification when a license is requested based on the self-published SRL 308.

Once the user self-publishes the SRL 308, the user associates the self-published SRL 308 with the DRM certificate 810 used to create it to the content, and the SRL 308 and the DRM certificate 810 This content with) is distributed to other users. The other user then requests and obtains a license for that content from the DRM server 320 in substantially the same manner as shown in FIGS. 6A and 6B. However, here, the license-requesting user submits both the self-published SRL 308 and the DRM certificate 810 to the DRM server 320 as connected to the content. 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 with the same as before. However, it should be noted that since the user cannot verify that the DRM server 320 can enforce the rights in the SRL 308, the DRM server 320 itself must perform verification at this time, as described above.

Permission template

As described above, a user generates most of any kind of authorization data in an authorization label by defining a user or class of users, defining permissions for each given user or user class, and then setting any conditions of use. Freedom to do it However, repeatedly specifying authorization data for multiple rights labels can be quite burdensome and repetitive, especially when the same user or user class, rights and conditions are set for different portions of the content repeatedly. This situation can occur, for example, in a corporate or office environment, where a user repeatedly publishes different pieces of content to be shared with a specially defined user team. In such a situation, in one embodiment of the present invention, a rights template is created that a user can repeatedly use in connection with the creation of a rights label, the rights template already having a predetermined user or user class, each predetermined user or Selected privileges for the user class, and certain conditions of use.

In one embodiment of the present invention, now referring to FIG. 9, the rights template 900 has substantially the same rights data as in the rights label. However, since (DES1) is not known until the content is published, the authorization data cannot be encrypted according to this (DES1) as in the authorization label. In one embodiment of the invention, a rights template 900 with unencrypted rights data is then submitted in the process of encrypting the rights data with (DES1) in step 416 of FIG. 4 to generate (DES1 (rightsdata)). . Of course, the authorization data is retrieved from the submitted authorization template 900 before it is so encrypted.

The DRM server 320 and its public key (PU-DRM) may or may not be known when the rights template is configured. Moreover, even if known, there may or may not be a case where there are two or more DRM servers 320 each having its own (PU-DRM). Nevertheless, when the DRM server 320 and its public key (PU-DRM) are known when the authorization template is configured, and only one DRM server 320 is used, or one DRM server 320 If only the rights template 900 is to be used, this rights template also includes information on the DRM server for signing the rights label due to the rights template 900 including its public key (PU-DRM). can do. This (PU-DRM) appears in the SRL 308 when encrypting (DES1) resulting in (PU-DRM (DES1)), but since (DES1) is unknown until the content is published, the rights template 900 It will be seen again that the (PU-DRM) within cannot encrypt this (DES1) as in the authorization label. Then, in one embodiment of the present invention, the rights template 900 with unencrypted (PU-DRM) is submitted in the process of encrypting (DES1) with (PU-DRM) in step 414 of FIG. Generate DRM (DES1). Of course, (PU-DRM) is retrieved from the rights template 900 submitted prior to use.

In addition, in the case described above, other information on the DRM server that may be included in the authorization template may include reference information such as a URL for locating the DRM server on the network, and handling information in case of URL failure. In some cases, the rights template may also contain information that describes, among other things, the rights template 900 itself. The rights template 900 may also be published, such as information that appears in a rights label related to the content and / or encryption key (CK) and (DES1), although it would not be necessary if the description of the rights template was not actually converted to a rights label. A space for information related to the content may be provided.

Although the rights template 900 disclosed so far is primarily for the convenience of the user, in some cases, the user may not have unlimited freedom to define the rights data in the rights label, and the rights template 900 may be created. It will also be appreciated that it can be used to limit the scope or form of the substance. For example, in a corporate or office environment, for example, it may be chosen as a policy that a particular user always publishes content only to a particular user class, or that a user cannot publish content to a particular user class at all. In some cases, in one embodiment of the present invention, such a policy is implemented as rights data selected within one or more rights templates 900, and the user is advised to use such rights templates to generate rights labels at the time of content publishing. May be limited. In particular, one rights template 900 or a group of rights templates 900 made available to a user to specify a publishing policy for a user may be in any particular form of publishing policy without departing from the spirit and scope of the present invention. Can be specified.

In order to designate a rights template 900 for a limited user or the like, referring now to FIG. 10, an administrator or the like actually defines the selected rights data (step 1001), such as information related to a particular DRM server 320, Authorization template 900 is constructed by defining any other data that is necessary and appropriate (step 1003). Importantly, in order to execute a rights template for a user by a limited user or the like, the rights template 900 must be official. That is, the rights template 900 should be recognized as a right template that can be used by a limited user. Thus, in one embodiment of the present invention, an authorization template configured by an administrator or the like is submitted to the DRM server 320 for signature, which signature makes the authorization template official (step 1005).

In fact, if the information exists in the authorization template 900, the signing DRM server 320 should know that the information is a DRM server 320 in the authorization template. In addition, it should be appreciated that the DRM server 320 may sign the rights template 900 only when making any necessary checks, or without checking at all. Finally, the template signature S (PR-DRM-T) from the DRM server 320, where -T indicates that the signature is for the ORT 900, is at least in the selected authorization data in the authorization template 900. It should be understood, but it is understood that other information may be based without departing from the spirit and scope of the invention. As will be discussed below, the signature S (PR-DRM-T) can be included in the authority label and can be verified in this regard, so that whatever the signature is based on can be included in a modified form of authority table.

When the DRM server 320 signs the authority template 900 and returns it to an administrator or the like, the administrator is signed with S (PR-DRM-T) and now receives an official authority template 900 (step 1007). A formal rights template (ORT) 900 is sent to one or more users (1009). Thus, for the user to publish the content based on the ORT 900, the user retrieves the ORT 900 (step 1011) and generates information on the content, appropriate key information, (DES1 (rightsdata)) ( An authority label is constructed based on the ORT 900 by providing any necessary information, such as authority data from the ORT 900 encrypted by DES1, and any other information from the ORT 900 (step 1013). ). Importantly, the user also includes the signature S (PR-DRM-T) from the ORT 900 along with the rights label.

Then, as before, the user submits the authorization label to the DRM server 320 for signature (step 1015). However, here, the DRM server 320 will not sign the submitted authority label unless the internal S (PR-DRM-T) verifies. That is, the DRM server 320 refuses to sign the submitted authority label if the submitted authority label does not include the signature S (PR-DRM-T) from the ORT 900 so that the user has submitted the submission on the ORT 900. Do this based on the permission label. In particular, the DRM server 320 retrieves this S (PR-DRM-T), retrieves all the information on which this signature is based from the authority label submitted, and then based on this (PU-DRM) Verify Note that the authorization data in the submitted authorization label is encrypted according to (DES1) (ie (DES1 (rightsdata)). Thus, the DRM server 320 may verify the signature based on the authorization data in the submitted authorization label. To be able to do this, as described in connection with Fig. 7, firstly, (DES1) is obtained, and with this, (DES1 (rightsdata)) is decrypted.

Once verified, the DRM server 320 signs the submitted authorization label with an S (PR-DRM-L), creating the SRL 308 as before (where -L is the signature for the SRL 308). ). Here, S (PR-DRM-L) may replace S (PR-DRM-T) or may be added to S (PR-DRM-T). In addition, S (PR-DRM-L) may be based in part on S (PR-DRM-T). (PR-DRM) is used to generate S (PR-SRM-T) and S (PR-DRM-L), or different (PR-DRM) is used for S (PR-DRM-T) and S (PR Note that it can be used for each of -DRM-L). When the DRM server 320 signs the authorization label and returns the SRL 308 to the user, the user receives the SRL 308 with S (PR-DRM-L) (step 1017) and publishes it as before. Proceed to link to the content.

If the signature S (PR-DRM-T) of the ORT 900 is based, at least in part, on the selected authorization data in the ORT 900, the authorization data represented in the SRL 308 (in DES1 (rightsdata)) is modified or changed. Can't be. Otherwise, S (PR-DRM-T) will not be verified. Nevertheless, in one embodiment of the present invention, the authorization data within the ORT 900 may also vary within the predetermined rules contained within the ORT 900. For example, there may be rules that specify one of two sets of authorization data to be included in SRL 308, or allow selection from an alternative set. As can be appreciated, these rules may be any specific rule described in any suitable context within the spirit and scope of the invention. Here, these rules can be interpreted by the appropriate rule interpreter for the user when the rights label is created. Although the authorization data may change, the rules do not change together, so the template signature S (PR-DRM-T) for the ORT 900 is based at least in part on the rule and not the authorization data itself. As a result, rules included with the ORT 900 must also be included with the SRL 308.

In one embodiment of the present invention, as described above, the predetermined authorization data in the ORT 900 is not fixedly changed in part, but partially changed to derive a rule. Here, the template signature S (PR-DRM-T) of the ORT 900 is based at least in part on the rules of the fixed part and the rules of the authority data of the changing part.

As can be seen, the ORT 900 owned by the user may be outdated or outdated. That is, the ORT 900 through internal authorization data may reflect a policy that is old, inappropriate, or no longer simply applicable. For example, one or more users or user classes specified in the authorization data of the ORT 900 may no longer exist in the policy environment, or a particular user or user class specified in the authorization data of the ORT 900 may be no longer present in the policy environment. You can't have the same permissions anymore. In such a case, the administrator may issue a revised ORT 900, but the user may still be using the previous validated version of the ORT 900.

Then, in this situation, in one embodiment of the invention, the DRM server 320 signing the rights template 900 submitted to generate the ORT 900 holds a copy of the ORT 900, Each ORT 900 has a unique identification mark, and each authority label constructed based on the ORT 900 includes an identification indication of the ORT 900 therein. Thus, upon receiving the submitted authority label as in connection with FIG. 10, the DRM server 320 finds an identification mark of the ORT 900 within the authority label and based on the found identification mark. Retrieve the most recent copy, remove authorization data from the submitted authorization label, insert authorization data from the retrieved ORT 900, and sign the authorization label based at least in part on the authorization data inserted. Of course, the DRM server also performs any necessary encryption and decryption necessary for the process described above and mandatory for the process, including decryption and re-encryption of (DES1 (rightsdata)). If the DRM server is applied to replace authorization data in a submitted authorization label, this authorization label, and the ORT 900 from which the authorization label is configured, do not necessarily include the authorization data therein. Instead, the authorization data need not only reside on the DRM server 320. However, including authorization data along with the authorization label and the ORT 900 from which the authorization label is constructed may be useful to the user, and may be useful in some cases.

Licensing through the Directory

When issuing a license of protected content, the license issuing entity (hereinafter referred to as the 'licensor') refers to the SRL 308 sent from the content, which user / group / cluster / block / platform / etc. ), And whether the certificate sent to identify the license requester will be provided. Based on this, the licensor determines which rights of those listed in the SRL 308 will be issued to the requester. Conceptually, the licensor examines the entities listed in the SRL 308 and compares these entities with the requestor. Therefore, if the SRL 308 enumerates that a particular group receives a license and the requester is a member of such a group, the requester is granted a license with the rights described for the group in the SRL 308. Similarly, if SRL 308 enumerates that a particular user has received a license and that the requester is such a user, then the requester is granted a license with the rights described for the user in SRL 308. As can be seen, a particular SRL 308 can list several entities and their rights, and a particular requestor can be licensed based on the membership of one or more entities that exist.

In one embodiment of the present invention, as can be seen in FIG. 12, the requestor is identified within a certificate 1202 sent via identifier 1204, which identifier 1204 is for example the requestor organization directory 1206. It may be an alternative name identified within. Correspondingly, SRL 308 lists each authorization entity according to this identifier 1204. Therefore, as part of the request processing for license 1208, licensor 1210 obtains the requester's identifier 1204 from certificate 1202, so that all identifiers 1204 listed in SRL 308 sent the obtained identifiers are obtained. Compare. If a match is found, the licensor 1210 issues a license 1208 to the requester having the authority specified in the SRL 308 for this requestor's identifier 1204.

Further, with the use of the directory, the licensor 1210 may also determine whether the requestor is a member of any other entity listed in the SRL 308 so that the directory 1206 may reflect the member status of the requestor in each other entity. It is assumed that it contains appropriate cross-reference information. Typically, directory 1206 lists, for each requester, not only its identifier 1204, but also an identifier 1208 such as each group / cluster / partition / platform / other entity / etc. That the requester is a member of. Note that directory 1206 may include an identifier 1208 such as a mail address, replacement mail address, ID, replacement ID, group member, history identifier, and the like.

Once the certificate 1202 is received from the requester with the identifier 1204 and the authorization data from the SRL 308 is received from the requester, referring now to FIG. 13, the licensor 1210 is licensed 1208 in the following manner. ) To the requestor. Temporarily, licensor 1210 obtains the requester's identifier 1204 from received certificate 1202 (step 1301) and places the obtained identifier 1204 in directory 1206 (step 1303). The licensor 1210 then locates the identifier 1204 of each entity of which the requestor identifier 1204 is a member based on the identifier 1204 located in the directory 1206 (step 1305). Therefore, for each located requestor identifier 1204 and all located entity identifiers 1204, the licensor 1210 compares this identifier 1204 with all identifiers 1204 listed in the sent SRL 308. (Step 1307). If a match is found again, the licensor 1210 issues a license 1208 to the requestor with the rights specified in the SRL 308 for the match identifier 1204.

Note that since multiple identifiers 1204 are compared to SRL 308, there may be cases where multiple match identifiers 1204 are found within SRL 308. If so, the license 1210 may select the appropriate one of the match identifiers 1204 in the SRL 308 to issue the license 1208 to the requestor with the rights specified in the SRL 308 for the selected match identifier 1204. . For example, the licensor may select a match identifier 1204 that conveys most of the authority to the requestor (step 1309b-1). Note that the licensor may determine whether the match identifier 1204 should convey most of the authority or rely on the same kind of priority indication 1212 in the SRL 308. In the latter case, each matching identifier (user) 1204 in the SRL 308 has a corresponding priority indication 1212, and the higher rank indication 1212, for example, has a wider range of granted privileges. Indicates. Therefore, if licensor 1210 finds multiple match identifiers 1204 in SRL 308, this licensor 1210 selects match identifiers 1204 with indication 1212 of the highest rank (step 1309b). -2).

Referring to directory 1206 to generate an additional identifier 1204 related to the requestor, licensor 1210 may find a match, for example, in a situation where the requestor's mail address or ID has changed since the SRL 308 was created. Be aware that it increases the chances of being In general, directory 1206 provides a mapping from one identifier 1204 of the requester to another possible identifier 1204 of the requester, so that all identifiers 1204 find a match for identifier 1204 in SRL 308. Can be used when trying to.

Licensing into Groups

In one embodiment of the present invention, the sent certificate 1202 submitted by the requestor represents a group, cluster, or any other group of individuals (hereinafter 'groups') in which the group is properly represented within the directory 1206. Can be. Such groups may include mail-enabled groups such as distribution lists or mail alternate names, security groups that may be defined in connection with the network operating system, and the like. Thus, the licensor 1210 receiving the sent 'group' certificate 1202 proceeds substantially as before. However, as the certificate 1202 sent represents a particular group, it is to be understood that the license 1208 issued from the licensor 1210 is for the group identified in the certificate 1202, and not specifically for the requestor. Alternatively, licensor 1210 may determine from directory 1206 that the requestor is part of a group identified in certificate 91202, and if so, issued license 1210 is for the requestor.

In the former case, the issued license 1208 may include a content key encrypted according to the group's public key, so the requestor needs to obtain the group's corresponding private key. Thus, the requestor may have a group member certificate with such a private key that is encrypted according to the requester's public key and decryptable according to the requester's corresponding private key.

In the latter case, the licensor 1210 may further receive a certificate from the requester with this public key to include the content key encrypted according to the requestor's public key in the issued license 1208. Alternatively, licensor 1210 may have such a certificate on a file (see, for example, steps 608-612 of FIGS. 6A and 6B) and that the requestor is part of a group identified within the group certificate 1202 to which it was sent. The public key can be used in the same manner as in the case of determining from the directory 1206.

In particular, assigning rights within the SRL 308 and issuing licenses 1208 according to groups allows for digital rights management to be performed at enterprise or organization settings. For example, a document or email may be DRM-protected such that all members of a given department have the right to read the document or email. Given that a group (eg, email alternative name) for such a department exists in the directory 1206 of the organization, which is the most common case, the author of a document or email may authorize on a group basis rather than an individual. As can be seen, the benefits of such grouped authorization include ease of use when the author specifies the class of the authorized individual. In addition, by assigning rights according to a group, the specified rights are not 'effective' as new individuals joining the group and existing individuals leaving the group. Instead, all current members of the group can exercise their rights as long as the members of this group are kept up to date in the organization directory 1206.

Introduction of policies during licensing

In one embodiment of the present invention, as described above in connection with the ORT 900 of FIG. 9, the DRM server / licensor 1210 is based on the SRL 308 and the SRL filed when issuing a license 1208. 308 may be altered or replaced with authorization data. In particular, if the entitlement data in the submitted SRL 308 is explicitly ignored, and the licensor 1210 instead replaces or 'introduces' an alternative policy at the time of license 1218 creation based on the SRL 308. There are a few things that happen. While some specific situations are disclosed herein where the licensor 1210 introduces a policy into the license 1208, the licensor 1210 may be licensed in any other form of context without departing from the spirit and scope of the present invention. Policy can be introduced into

In the first case, now referring to FIG. 14, the licensor 1208 manages a list 1214 (FIG. 12) of special entities (users, groups, etc.) to which special privileges have been granted. For example, a special entity may include, among other things, any higher level person in the organization, any manager, any person capable of rendering all content, and the group of individuals described above. This list 1214 may actually be included in the organization directory 1206 by identifying the information in the directory listing for each special entity, or simply creating one or more groups of such special entities. Thus, such a special entity may render content even if its SRL 308 otherwise prohibits such rendering.

When an entity submits an SRL 308 as part of a request for a license 1208, and now referring to FIG. 14, the licensor 1210 checks with the directory 1206 in an appropriate manner so that the submitting entity is characterized as a special entity. It is then determined whether it is possible (step 1401), and if so, the licensor 1210 generates a license 1208 for the special entity having special privileges different from the authorization data present in the submitted SRL 308 (step 1403). It is to be understood that the special rights may be any rights without departing from the spirit and scope of the invention. For example, a special right may be that all special entities have full access to and render the corresponding content, all special entities from a particular group have full access to and render the content, and the license 1208 expires. Enhanced rights, such as a previous higher play count or longer duration, may be received by a particular special entity, and so forth. If special rights are specified for an individual or group, these rights may be specified in a directory entry for the person or group in directory 1206, and such directory entries will have appropriate references to where the special rights are located. It is understood that the licensor 1210 may discover special privileges within the database based on the identifier 1204 of the individual or group.

In the second case, now referring to FIG. 15, the licensor 1208 maintains a list 1216 (FIG. 12) of restricted entities (users, groups, etc.) whose rights are to be restricted or revoked. For example, restricted entities are restricted within an organization, especially individuals, contractors, and temporary employees within an organization who typically do not have any rights to any content, such as individuals leaving the organization, maintenance, and building staff. Individuals with only, and groups of individuals described above. Like the 'special' list 1214 described above, the restricted list 1216 may also identify information in the directory listing for each restricted entity, or by simply creating one or more groups of such restricted entities, 1216). Therefore, this restricted entity is restricted from content rendering even though its SRL 308 allows such rendering differently.

If an entity submits an SRL 308 as part of a request for a license 1208, and now referring to FIG. 14, the licensor 1210 checks with the directory 1206 in an appropriate manner so that the submitting entity may be characterized as a special entity. It is then determined whether it is possible (step 1405), and if so, the licensor 1210 generates a license 1208 for the restricted entity with limited rights that differs from the authorization data present in the submitted SRL 308 (step 1407). It is to be understood that the limited rights may be any rights without departing from the spirit and scope of the invention. For example, restricted rights may mean that all restricted entities cannot access and render the corresponding content in any way, that all restricted entities from a particular group can access and render short-lived content, and Restricted entity may be able to print only one copy of a portion of the content, and so on. Restricted authority may also be that a restricted entity is not granted any license at all. If restricted rights, such as special rights, are specific to an individual or group, those rights may be specified within a directory entry for an individual or group in directory 1206, and this directory entry may be for the location where the special rights are located. Having an appropriate reference, licensor 1210 may discover special privileges within the database based on the identifier 1204 of the individual or group.

In a third case, the licensor 1208 may introduce a policy into the license 1208 to specify the minimum system requirements needed on the computing device 14 (FIG. 11) for rendering the corresponding content (step 208). 1409). These minimum policy requirements may relate to any other matter without departing from the spirit and scope of the present invention, but typically relate to the reliability and security of computing device 14.

A major example of the reliability and security that may be associated with the licensor 1210 is whether the trusted component 18 of the computing device 14 or its security portion is in use. As will be appreciated, this currency may be indicated by version number, date of manufacture, and the like, and reflects the age of trusted component 18 or a portion thereof. As can also be seen, trusted components 18 or portions thereof are more vulnerable to security attacks by bad entities such as the dating of these trusted components 18 or portions thereof. Thus, licensor 1210 determines that a trusted component 18 or portion thereof over some age should not be trusted, and such unreliable component 18 or portion thereof before the corresponding content is rendered. Policy may be introduced into the issued license 1208.

Another example of the reliability and security that will be associated with the licensor 1210 is whether an application for rendering content can actually be trusted. As can be seen, one application may be trusted to render content within the scope of license 1208, for example by not allowing the content to be kept in unprotected form, while other applications may not be trusted as well. There can be. Accordingly, the licensor 1210 may determine that only any application can be used to render the corresponding content, and introduce a policy into the issued license 1208 that requires only such application to be used to render this content. have.

Of course, other policy adoption situations are also abundant. In general, the policy introduction may be performed to add or remove authority from the authority data in the SRL 308, perhaps based on the requestor (step 1411), and also subject to this authority data based on the requestor. May be similarly performed to add or remove a condition from the authorization data (step 1413).

conclusion

The programming required to execute the processes executed in connection with the present invention is relatively simple and can be clarified in the related related art published. Thus, such programming is not attached hereto. And any particular programming may be used to practice the invention without departing from the spirit and scope of the invention.

It will be appreciated that changes may be made to the above described embodiments without departing from the spirit of the invention. In particular, while the present invention has been described with reference to a defined population, such as an organization, the invention may also be used within a defined population that encompasses a subset or organization of tissues without departing from the spirit and scope of the invention. Therefore, it will be appreciated that the invention is not limited to the specific embodiments disclosed, but only by the appended claims.

Claims (38)

A method in which a licensor issues a digital license to the requestor so that the requester can render corresponding digital content, the licensor in a directory containing a listing for the requestor. Accessible, the list includes an identifier of the requester and an identifier of each group of which the requester is a member thereof, Receiving a request from the requester, the request including an identifier identifying the requestor, and authorization data associated with the content, the authorization data listing at least one identifier and the authorization associated with it; Placing the identifier of the requestor in the directory; Positioning, in the directory, the identifier of each group of which the requester is a member, from the identifier of the requester located in the directory; Comparing each of the located requestor identifiers and each located group identifier with each identifier listed in the authorization data to find a match; And Issuing the license to the requestor with the authority associated with the match identifier. How to include. The method of claim 1, Receiving a request from the requester including a digital certificate having the identifier identifying the requestor. The method of claim 1, Receiving a request from the requester including the authorization data having a digital signature based on the authorization data. The method of claim 3, Verifying the digital signature. The method of claim 1, For each of the located requestor identifiers and each located group identifier, Comparing this identifier with each identifier listed in the authorization data; And Indicating whether the compared identifier is a matching identifier Including, To generate at least two matching identifiers, Selecting one of the match identifiers; And Issuing the license to the requestor having authority associated with the selected match identifier. How to include. The method of claim 5, Selecting the match identifier that conveys the highest amount of authority to the requestor. The method of claim 5, Each identifier in the authorization data has a corresponding priority indication, and the method includes selecting the match identifier having the most priority indication. A computer readable medium having stored thereon computer executable instructions for executing a method for a licensor to issue a digital license to the requestor so that the requester can render corresponding digital content, the licensor storing a list for the requestor. Access a directory, the list including an identifier of the requester and an identifier of each group of which the requester is a member thereof; The method, Receiving a request from the requester, the request including an identifier identifying the requestor, and authorization data associated with the content, the authorization data listing at least one identifier and the authorization associated with it; Placing the identifier of the requestor in the directory; Positioning, in the directory, the identifier of each group of which the requester is a member, from the identifier of the located requestor in the directory; Comparing each of the located requestor identifiers and each located group identifier with each identifier listed in the authorization data to find a match; And Issuing the license to the requestor having an authority associated with a match identifier. Computer-readable media comprising a. The method of claim 8, And the method comprises receiving a request from the requester comprising a digital certificate having the identifier identifying the requestor. The method of claim 8, And the method comprises receiving a request from the requester comprising the authorization data having a digital signature based on the authorization data. The method of claim 10, And the method further comprises verifying the digital signature. The method of claim 8, The method, For each of the located requestor identifiers and each located group identifier, Comparing this identifier with each identifier listed in the authorization data; And Indicating whether the compared identifier is a matching identifier Including, To generate at least two matching identifiers, Selecting one of the match identifiers; And Issuing the license to the requestor having authority associated with the selected match identifier. Computer-readable media comprising a. The method of claim 12, The method includes selecting the match identifier that conveys the highest amount of authority to the requestor. The method of claim 12, Wherein each identifier in the rights data has a corresponding priority indication, and the method includes selecting the matching identifier having the most priority indication. A method for a licensor to issue a digital license to a requestor so that a requestor who is a member of a group can render corresponding digital content. Receiving a request from the requester, the request including an identifier identifying the group, and authorization data associated with the content, the authorization data listing at least one identifier and the authorization associated with it; Comparing the group identifier from the request with each identifier listed in the authorization data to find a match; And Issuing the license to the requestor having the authority associated with the matching group identifier, wherein the issued license includes a content key corresponding to the content encrypted according to the group's public key, thereby providing the requester with the disclosure. Obtain the content key with the private key of the group corresponding to the key − How to include. The method of claim 15, Receiving a request from the requester including a digital certificate having the identifier identifying the group. The method of claim 15, Receiving a request from the requester including the authorization data having a digital signature based on the authorization data. The method of claim 17, Verifying the digital signature. The method of claim 15, The licensor can access a directory containing a list for a group, the list including an identifier of the group, and an identifier of each member of the group including the requestor, The method, Receiving the identifier from the requester; Placing the list for the group in the directory based on the identifier of the group; And Verifying that the located list for the group in the directory includes the identifier of the requester How to include more. A computer readable medium having stored thereon computer executable instructions for executing a method for a licensor to issue a digital license to the requestor so that a requestor who is a member of the group can render the corresponding digital content. The method, Receiving a request from the requester, the request including an identifier identifying the group, and authorization data associated with the content, the authorization data listing at least one identifier and the authorization associated with it; Comparing the group identifier from the request with each identifier listed in the authorization data to find a match; And Issuing the license to the requestor having an authority associated with the matching group identifier, wherein the issued license includes a content key corresponding to the content encrypted according to the group's public key, so that the requester has the public key. Obtain the content key with the private key of the group corresponding to Computer-readable media comprising a. The method of claim 20, And the method comprises receiving a request from the requestor comprising a digital certificate having the identifier identifying the group. The method of claim 20, And the method comprises receiving a request from the requester comprising the authorization data having a digital signature based on the authorization data. The method of claim 22, And the method further comprises verifying the digital signature. The method of claim 20, The licensor can access a directory containing a list for the group, the list including an identifier of the group and an identifier of each member of the group including the requestor, The method, Receiving the identifier from the requester; Placing the list for the group in the directory based on the identifier of the group; And Verifying that the located list for the group in the directory includes the identifier of the requestor The computer readable medium further comprising. A method in which a licensor issues a digital license to a requestor so that a requestor who is a member of a group can render a corresponding digital content, wherein the licensor can access a directory containing a list for the group, the list being Includes an identifier of each member of the group containing the requestor-, Receiving a request from the requester, the request comprising an identifier identifying the group, an identifier identifying the requester, and authorization data associated with the content, wherein the authorization data includes at least one identifier and an authorization associated with it To list-; Comparing the group identifier from the request with each identifier listed in the authorization data to find a match; Placing the list for the group in the directory based on the identifier of the group; Verifying from the located list that the requestor identifier is included therein; And Issuing the license to the requestor having an authority associated with the matching group identifier, wherein the issued license includes a content key corresponding to the content encrypted according to the requester's public key; Obtain the content key with the requester's private key corresponding to How to include. The method of claim 25, Receiving a request from the requester including a digital certificate having the identifier identifying the group. The method of claim 25, Receiving a request from the requester including a digital certificate having the identifier identifying the requestor. The method of claim 27, Obtaining the public key of the requester from the digital certificate. The method of claim 25, Receiving a request from the requester including the authorization data having a digital signature based on the authorization data. The method of claim 29, Verifying the digital signature. The method of claim 25, Obtaining the public key of the requester from a digital certificate on a file, wherein the digital certificate includes the identifier of the requestor. A computer readable medium having stored thereon computer executable instructions for executing a method for a licensor to issue a digital license to the requestor so that a requestor who is a member of the group can render the corresponding digital content. Access a directory containing a list for the list, wherein the list includes an identifier of each member of the group containing the requestor; The method, Receiving a request from the requester, the request comprising an identifier identifying the group, an identifier identifying the requester, and authorization data associated with the content, wherein the authorization data includes at least one identifier and an authorization associated with it To list-; Comparing the group identifier from the request with each identifier listed in the authorization data to find a match; Placing the list for the group in the directory based on the identifier of the group; Verifying from the located list that the requestor identifier is included therein; And Issuing the license to the requestor having the right associated with the matching group identifier, wherein the issued license includes a content key corresponding to the content encrypted according to the requester's public key Obtain the content key with the requester's private key corresponding to the key Computer-readable media comprising a. 33. The method of claim 32, And the method comprises receiving a request from the requester comprising a digital certificate having the identifier identifying the group. 33. The method of claim 32, And the method comprises receiving a request from the requester comprising a digital certificate having the identifier identifying the requestor. The method of claim 34, wherein The method further comprising obtaining the public key of the requester from the digital certificate. 33. The method of claim 32, And the method comprises receiving a request from the requester comprising the authorization data having a digital signature based on the authorization data. The method of claim 36, And the method further comprises verifying the digital signature. 33. The method of claim 32, And the method further comprises obtaining the public key of the requester from a digital certificate on a file, the digital certificate comprising the identifier of the requestor. <Attachment 1> <Attachment 2>