Enforcement architecture and method for digital rights management
11 claims: 4 independent, 7 dependent
- 1コンピュータ装置上でデジタル権利管理(DRM)システムを動作させるコンピュータ実行可能な命令を格納するコンピュータ読取可能媒体であって、 前記コンピュータ装置は暗号解読及び暗号化手段を有し、前記暗号解読及び暗号化手段は公開/秘密鍵対を含み、 前記命令は、実行されると、コンピュータ装置に、 ライセンス格納部に1つ以上のデジタル・ライセンスを格納するステップ であって、前記デジタル・ライセンスは前記コンピュータ装置からのライセンス要求に応答してライセンス・サーバにより発行され、前記ライセンス・サーバは前記デジタル・ライセンスの発行に先立って前記暗号解読及び暗号化手段の認証を行う、ステップ と、 前記ライセンス格納部内の前記1つ以上のデジタル・ライセンスの各々に 関して行われたレンダリングの状態に関する状態 情報を状態格納部に保持するステップであって、前記1つ以上のデジタル・ライセンスのうち少なくとも1つに対応するレンダリング の状態に関する状態情報 を保持するステップを含む、ステップと、 保護されるデジタル・コンテンツを前記コンピュータ装置上で特定の態様でレンダリングする要求をユーザから受信するステップと、 前記ライセンス格納部に格納されている前記1つ以上のデジタル・ライセンスのうち少なくとも1つが前記保護されるデジタル・コンテンツに対応するか否かを決定するステップであって、前記ライセンス格納部に格納されている前記1つ以上のデジタル・ライセンスのいずれもが前記保護されるデジタル・コンテンツに対応しない場合には、対応するデジタル・ライセンスを取得するステップと、 前記ライセンス格納部に格納されている前記1つ以上のデジタル・ライセンスのうち少なくとも1つが前記保護されるデジタル・コンテンツに対応する場合には、暗号解読機能を実行することにより少なくとも部分的に前記対応するデジタル・ライセンスを評価するステップとを実行させ、前記対応するデジタル・ライセンスの評価は、前記コンピュータ装置が、 前記対応するデジタル・ライセンスが有効か否かを決定するステップと、 前記対応するデジタル・ライセンスにおけるライセンス規則を 確認する ステップであって、前記ライセンス規則は前記対応するデジタル・ライセンスにより許可されるレンダリングの種類を指定する、ステップと、 前記ライセンス規則により許可されるレンダリングの種類及び前記状態格納部に保持される前記 状態 情報に おいて示される レンダリング の状態 に基づいて、要求を行っているユーザが要求される特定の態様で前記保護されるデジタル・コンテンツをレンダリングすることを許可されるか否かを決定するステップであって、前記状態格納部に保持される前記 状態 情報はデジタル・ライセンスの各評価により更新される、ステップと を実行することを含み 、 前記命令はさらに、前記コンピュータ装置に、 前記要求を行っているユーザが前記要求される特定の態様で前記保護されるデジタル・コンテンツのレンダリングを許可される場合、前記対応するデジタル・ライセンスから解読鍵を取得し、前記解読鍵を使用して前記保護されるデジタル・コンテンツを暗号解読するステッ プ を 実行 させる ことを含む、コンピュータ読取可能媒体。
- 2前記ライセンス格納部は、前記1つ以上のデジタル・ライセンスに対するアクセスを提供し、前記保護されるデジタル・コンテンツに対するアクセスを提供しない請求項1に記載のコンピュータ読取可能媒体。
- 3コンピュータ装置上でデジタル権利管理(DRM)システムを動作させる方法であって、 前記コンピュータ装置は暗号解読及び暗号化手段を有し、前記暗号解読及び暗号化手段は公開/秘密鍵対を含み、 前記コンピュータ装置内のライセンス格納部が1つ以上のデジタル・ライセンスを格納するステップ であって、前記デジタル・ライセンスは前記コンピュータ装置からのライセンス要求に応答してライセンス・サーバにより発行され、前記ライセンス・サーバは前記デジタル・ライセンスの発行に先立って前記暗号解読及び暗号化手段の認証を行う、ステップ と、 前記ライセンス格納部内の前記1つ以上のデジタル・ライセンスの各々に 関して行われたレンダリングの状態に関する状態 情報を前記コンピュータ装置内の状態格納部が保持するステップであって、前記1つ以上のデジタル・ライセンスのうち少なくとも1つに対応するレンダリング の状態に関する状態情報 を保持するステップを含む、ステップと、 保護されるデジタル・コンテンツを前記コンピュータ装置上で特定の態様でレンダリングする要求を、前記コンピュータ装置がユーザから受信するステップと、 前記ライセンス格納部に格納されている前記1つ以上のデジタル・ライセンスのうち少なくとも1つが前記保護されるデジタル・コンテンツに対応するか否かを前記コンピュータ装置が決定するステップであって、前記ライセンス格納部に格納されている前記1つ以上のデジタル・ライセンスのいずれもが前記保護されるデジタル・コンテンツに対応しない場合には、前記コンピュータ装置が対応するデジタル・ライセンスを取得するステップと、 前記ライセンス格納部に格納されている前記1つ以上のデジタル・ライセンスのうち少なくとも1つが前記保護されるデジタル・コンテンツに対応する場合には、前記コンピュータ装置が、暗号解読機能を実行することにより少なくとも部分的に前記対応するデジタル・ライセンスを評価するステップとを含み、前記対応するデジタル・ライセンスの評価は、前記コンピュータ装置が、 前記対応するデジタル・ライセンスが有効か否かを決定するステップと、 前記対応するデジタル・ライセンスにおけるライセンス規則を 確認する ステップであって、前記ライセンス規則は前記対応するデジタル・ライセンスにより許可されるレンダリングの種類を指定する、ステップと、 前記ライセンス規則により許可されるレンダリングの種類及び前記状態格納部に保持される前記 状態 情報に おいて示される レンダリング の状態 に基づいて、要求を行っているユーザが要求される特定の態様で前記保護されるデジタル・コンテンツをレンダリングすることを許可されるか否かを決定するステップであって、前記状態格納部に保持される前記 状態 情報はデジタル・ライセンスの各評価により更新される、ステップと を実行することを含み 、 前記方法はさらに、前記コンピュータ装置が、 前記要求を行っているユーザが前記要求される特定の態様で前記保護されるデジタル・コンテンツをレンダリングすることを許可される場合、前記対応するデジタル・ライセンスから解読鍵を取得し、前記解読鍵を使用して前記保護されるデジタル・コンテンツを暗号解読するステッ プ を 含む方法。
- 4前記ライセンス格納部は、前記1つ以上のデジタル・ライセンスに対するアクセスを提供し、前記保護されるデジタル・コンテンツに対するアクセスを提供しない請求項3に記載の方法。
- 5対応するデジタル・ライセンスを取得する前記ステップは、前記コンピュータ装置が、前記保護されるデジタル・コンテンツからライセンス取得情報を取得するステップをさらに含む請求項3に記載の方法。
- 6前記ライセンス取得情報はライセンス・サーバ位置を含み、対応するデジタル・ライセンスを取得する前記ステップは、前記ライセンス・サーバ位置におけるライセンス・サーバから前記コンピュータ装置が前記対応するデジタル・ライセンスを取得するステップを更に含む請求項5に記載の方法。
- 7公開/秘密鍵対を含む暗号解読及び暗号化手段を有する、 デジタル権利管理(DRM)システム を動作させるコンピュータ装置 であって、 1つ以上のデジタル・ライセンスを格納するライセンス格納部 であって、前記デジタル・ライセンスは前記コンピュータ装置からのライセンス要求に応答してライセンス・サーバにより発行され、前記ライセンス・サーバは前記デジタル・ライセンスの発行に先立って前記暗号解読及び暗号化手段の認証を行う、ライセンス格納部 と、 前記1つ以上のデジタル・ライセンスのうち少なくとも1つに対応するレンダリングの 状態に関する状態情報の 保持を含む、前記ライセンス格納部内の前記1つ以上のデジタル・ライセンスの各々に 関して行われたレンダリングの状態に関する状態 情報を保持する状態格納部と、 保護されるデジタル・コンテンツをコンピュータ装置上で特定の態様でレンダリングする要求をユーザから受信する手段と、 前記ライセンス格納部に格納されている前記1つ以上のデジタル・ライセンスのうち少なくとも1つが前記保護されるデジタル・コンテンツに対応するか否かを決定する手段であって、対応する場合に、対応するデジタル・ライセンスを出力し、前記ライセンス格納部に格納されている前記1つ以上のデジタル・ライセンスのいずれもが前記保護されるデジタル・コンテンツに対応しない場合には、対応するデジタル・ライセンスを取得する手段と、 暗号解読機能を実行することにより少なくとも部分的に前記対応するデジタル・ライセンスを評価する手段とを含み、前記評価する手段は、 前記対応するデジタル・ライセンスが有効か否かを決定する手段と、 前記対応するデジタル・ライセンスにおけるライセンス規則を 確認する 手段であって、前記ライセンス規則は前記対応するデジタル・ライセンスにより許可されるレンダリングの種類を指定する、手段と、 前記ライセンス規則により許可されるレンダリングの種類及び前記状態格納部に保持される前記 状態 情報に おいて示される レンダリング の状態 に基づいて、要求を行っているユーザが要求される特定の態様で前記保護されるデジタル・コンテンツをレンダリングすることを許可されるか否かを決定する手段であって、許可される場合に、前記対応するデジタル・ライセンスから解読鍵を出力し、前記状態格納部に保持される前記 状態 情報はデジタル・ライセンスの各評価により更新される、手段と を含み 、 前記DRMシステムはさらに、 前記解読鍵を使用して前記保護されるデジタル・コンテンツを暗号解読する手 段 を 含む、 コンピュータ装置 。
- 8前記ライセンス格納部は、前記1つ以上のデジタル・ライセンスに対するアクセスを提供し、前記保護されるデジタル・コンテンツに対するアクセスを提供しない請求項7に記載の コンピュータ装置 。
- 9前記対応するデジタル・ライセンスはデジタル署名を含み、前記対応するデジタル・ライセンスが有効か否かを決定する前記手段は、前記デジタル署名を評価する手段をさらに含む請求項7に記載の コンピュータ装置 。
- 10前記デジタル署名は前記保護されるデジタル・コンテンツに基づいている請求項9に記載の コンピュータ装置 。
- 11前記解読鍵を使用して前記保護されるデジタル・コンテンツを暗号解読する前記手段は、レンダリング・アプリケーションから前記保護されるデジタル・コンテンツを受信し、前記解読鍵を使用して前記保護されるデジタル・コンテンツを暗号解読し、前記暗号解読された保護されるデジタル・コンテンツを前記レンダリング・アプリケーションに返す手段をさらに含む請求項10に記載の コンピュータ装置 。
Independent claims11
1 paragraph, as filed
[0001] (Citation for related application) This application is entitled "ENFORCEMENT ARCHITECHTURE AND METHOD FOR DIGITAL RIGHTS MANAGEMENT" and is filed under Patent Attorney Reference Number MSFT-0063 on March 27, 1999. Claim the priority of No. 126,614. [0002] (Field of invention) The present invention relates to a rights enforcement architecture in digital content. More specifically, the present invention relates to an implementation architecture that allows access to encrypted digital content only according to parameters specified by a license right acquired by the user of the digital content. [0003] (Background of invention) The management and enforcement of digital rights refers to the distribution of such digital content to users with respect to digital content such as digital audio, digital video, digital text, digital data, digital multimedia, etc. Very desirable. Typical distribution methods include tangible devices such as magnetic (floppy) disks, magnetic tapes, optical (compact) disks (CDs), and intangible media such as electronic bulletin boards, electronic networks, the Internet, and the like. Upon receipt by the user, the user renders or "plays" the digital content with the help of a suitable rendering device such as a media player or personal computer. [0004] Typically, content owners, such as authors, publishers, broadcasters, etc. (Content Owners), exchange such digital content for license fees or some other consideration. Want to sell to users or recipients. Such content owners will often want to limit what users can do with the digital content sold in this way, if the choice is granted. For example, a content owner may allow a user to copy or redistribute such content to a second user, at least such that the second user denies the content owner a license fee. Now you want to constrain it. [0005] In addition, content owners may want to give users the flexibility to purchase different types of licenses for different license fees, while at the same time letting users maintain that requirement no matter what type of license they actually purchase. is there. For example, content owners may play digital content sold only a limited number of times, for a total amount of time, on certain machines, only on certain media players, and only for certain users. You may want to allow it. [0006] However, after making a sale, there are very few such content owners, even if they manage digital content. This is especially because practically any new product or modern personal computer makes an exact digital copy of such digital content, as well as magnetic or writable such an exact digital copy. This is a problem given the fact that it contains the software and hardware needed to download it to an optical disc or send such an exact copy to any destination over a network such as the Internet. [0007] Of course, as part of the legal action if a license fee is obtained, the content owner can require the user of the digital content to promise not to redistribute such digital content. However, such promises are easily made and easily broken. Content owners can also attempt to prevent such redistribution by any of several known security devices, often with encryption and decryption. However, if it cannot be prohibited to decrypt encrypted digital content, store such digital content in unencrypted form, and then redistribute it to mildly determined users. There are many. [0008] Therefore, there is a need to provide implementation architectures and methods that allow controllable rendering or playback of any form of digital content. In this case, management is flexible and can be defined by the content owner of such digital content. There is also a need to manage the rendering environment on a computer such as a personal computer. In this case, the rendering environment includes at least a portion of such an implementation architecture. This management of the rendering environment allows digital content to be rendered on a computer that is not under the control of the content owner, but only as specified by the content owner. .. [0009] In addition, trusted components on the computer If you run component) and a user of such a calculator attempts to access such digital content in a way that the content owner does not allow , the trusted component will give the content owner the rights to this piece of digital content. It is also required to be carried out on such a computer. As a mere example, such trusted software components prevent computer users from making copies of such digital content except as permitted by the content owner. (Outline of the invention) The aforementioned needs are met, at least in part, by digital rights management implementation architectures and methods. This architecture and method enforces rights in protected (guaranteed) digital content available on the Internet, optical discs, etc. To make the content available, the architecture includes a content server from which the digital content can be accessed in encrypted form, such as through the Internet. The content server can supply the encrypted digital content and record it on an optical disc or the like, and the encrypted digital content can be distributed on the optical disc itself. The content server encrypts the digital content with an encryption key and uses public / private key technology to tie the digital content to the digital license on the user's computer or client machine. [0010] When a user attempts to render digital content on a computer, the rendering application calls a digital rights management (DRM) system on such a user's computer. If the user is trying to render digital content first, the DRM system directs the user to a license server to obtain a license to render such digital content in the required manner, or on the user side. Now you can transparently obtain such a license from such a license server without any action. The license includes: [0011] -Decryption key (KD) to decrypt encrypted digital content -A description of the rights (playback, copy, etc.) granted by the license and related conditions (start date, end date, number of views, etc.). Such a description is in a digitally readable form. [0012] -Digital signature to ensure license integrity The user cannot decrypt or render the encrypted digital content without obtaining such a license from the license server. The acquired license is stored in the license store on the user's calculator. [0013] The important thing is that the license server only issues licenses to a "trusted" (ie, self-authenticateable) DRM system. To build "trust", DRM systems are equipped with a "black box", which performs decryption and encryption functions for such DRM systems. The black box contains a public / private key pair, version number, and unique signature, all supplied by an approved certification authority. The public key is made available to the license server for the purpose of encrypting a portion of the issued license, thereby binding such a license to such a black box. The private key can only be used in the black box for the purpose of decrypting the information encrypted with the corresponding public key, not the user or anyone else. First, the DRM system is supplied with a black box with a public / private key pair, and the user is asked to download the updated warranty black box from the black box server when the user first requests a license. To urge. The black box server supplies an updated black box with a unique public / private key pair. Such an update black box is written in unique executable code that runs only on the user's calculator and is updated regularly. When a user requests a license, the client machine sends a black box public key, version number, and signature to the license server, which, if the version number is current and the signature is valid. Issue a license. The license request also includes a key ID that identifies the digital content requesting the license and the decryption key associated with the requested digital content. The license server uses the black box public key to encrypt the decryption key, the decryption key to encrypt the license terms, and then the encrypted decryption key and the encrypted license terms to license. [0014] Once the downloaded license is stored in the DRM system's license store, the user can render the digital content according to the rights granted by the license and specified in the license terms. When a request is made to render digital content, a black box is made to decrypt the decryption key and license terms, and the license evaluation department of the DRM system evaluates these license terms. The black box only decrypts the encrypted digital content if the license evaluation determines that the requester is allowed to play such content. The decrypted content is fed to the rendering application for rendering. (A brief description of the drawing) The above overview and the following more detailed description of the embodiments of the present invention will be further understood by reading in connection with the accompanying drawings. For the purposes of exemplifying the present invention, currently preferred embodiments are shown in the drawings. However, as will be understood, the present invention is not limited to the configurations and means themselves shown. (Detailed description of the invention) With reference to the drawings in detail, similar numbers are used to indicate similar elements throughout. FIG. 1 shows an implementation architecture 10 according to an embodiment of the present invention. In general, implementation architecture 10 allows the owner of digital content 12 to specify a license rule and, if this license rule is not met, allows the user's computer 14 to render such digital content 12. Not done. Such licensing rules are embodied in Digital License 16, where the user / user calculator 14 (hereinafter, such terms are interchangeable unless circumstances permit) is the content owner. Or must be obtained from its agent. The digital content 12 is distributed in an encrypted form and can be freely and widely distributed. Preferably, a decryption key (KD) for decrypting the digital content 12 is included with the license 16.<u style="single">Computer environment</u>FIG. 12 and the following discussion are intended to provide a brief general description of a computer environment suitable for realizing the present invention. Although not necessarily, the description of the invention relates, at least in part, to common computer executable instructions executed by a computer such as a client workstation or server, such as a program module. Do it. In general, program modules include routine programs, objects, components, data structures, etc., perform specific tasks, or implement specific abstract data types. Further, the present invention and a part thereof include another computer including a handheld device, a multiprocessor system, a microprocessor electronic device or a programmable consumer electronic device, a network PC, a minicomputer, a mainframe computer, and the like. -Also admit that it can be implemented even with a system configuration. The present invention can also be implemented in a distributed computer environment, in which the task is executed by a remote processing device linked through a communication network. In a distributed computer environment, program modules can be located in both local and remote memory storage. [0015] As shown in FIG. 12, an example of a general-purpose computer system that realizes the present invention includes a conventional personal computer 120 and the like. The personal computer 120 includes an arithmetic unit 121, a system memory 122, and a system bus 123 that connects various system components including the system memory to the arithmetic unit 121. The system bus 123 may be of any of several bus structures, including a memory bus or memory controller, a peripheral bus, and a local bus using any of the various bus structures. System memory includes read-only memory (ROM) 124 and random access memory (RAM) 125. The basic input / output system 126 (BIOS) contains a basic routine that assists in data transfer between elements in the personal computer 120, such as during boot, and is stored in ROM 124. [0016] In addition, the personal computer 120 may include a hard disk drive 127 that reads and writes hard disks (not shown), a magnetic disk drive 128 that reads and writes removable magnetic disks 129, and removable devices such as CD-ROMs or other optical media. It also includes various peripheral hardware devices such as optical drive 130 that reads and writes optical disk 131. The hard disk drive 127, the magnetic disk drive 128, and the optical disk drive 130 are systemized via the hard disk drive interface 132, the magnetic disk drive interface 133, and the optical drive interface 134, respectively. -Connected to bus 123. The drive and its associated computer-readable media provide non-volatile storage of computer-readable instructions, data structures, program modules and other data of the personal computer 20. [0017] An example of the environment described herein employs hard disks, removable magnetic disks 129 and removable optical disks 131, but other types of computer-readable media capable of storing computer-accessible data are also available. It will be acknowledged by those skilled in the art that it can be used in the operating environment example. Such other types of media include magnetic cassettes, flash memory cards, digital video discs, Bernoulli cartridges, random access memory (RAM), read-only memory (ROM), and the like. [0018] A large number of program modules can be stored on a hard disk, magnetic disk 129, optical disk 131, ROM 124 or RAM 125, operating system 135, one or more application programs 136, other program modules 137, And contains program data 138. The user can enter commands and information into the personal computer 20 through input devices such as the keyboard 140 and the pointing device 142. Other input devices (not shown) can include microphones, joysticks, gamepads, satellite dishes, scanners and the like. These and other input devices are often connected to arithmetic unit 121 via a serial port interface 146 that connects to the system bus, but a parallel port, game port, or universal serial bus. It is also possible to connect with other interfaces such as (USB). A monitor 147 or other type of display device is also connected to system bus 123 via a peripheral hardware interface device such as the video adapter 148. In addition to monitor 147, personal computers typically include other peripheral output devices (not shown), such as speakers and printers. The example system in FIG. 12 also includes a host adapter 155, a small computer system interface (SCSI) bus 156, and an external storage device 162 connected to the SCSI bus 156. [0019] The personal computer 120 can also operate in a network environment using a logical connection to one or more remote computers, such as the remote computer 149. The remote computer 149 can be another personal computer, server, router, network PC, peer device, or other common network node, typically the elements mentioned above for the personal computer 120. Although many or all of them are included, only the memory storage device 150 is illustrated in FIG. The logical connections shown in Figure 12 include a local area network (LAN) 151 and a wide area network (WAN) 152. Such network environments are common in company-wide computer networks, intranets, and the Internet. [0020] When used in a LAN network environment, the personal computer 120 connects to the local network 151 via a network interface or adapter 153. When used in a WAN network environment, the personal computer 120 typically includes other means of establishing communication through a modem 154, or a wide area network 52 such as the Internet. Modem 154 may be internal or external and connects to system bus 123 via serial port interface 146. In a network environment, the program modules illustrated for personal computer 120 or parts thereof can also be stored in local or remote memory storage. It should be noted that the network connection shown is an example, and it can be acknowledged that another means of establishing a communication link between computers can be used.<u style="single">architecture</u>Referring again to FIG. 1, in one embodiment of the invention, the architecture 10 is not only the user's computer 14 described above, but also the authoring tool 18, the content key database 20, the content server 22, the license server 24, and Includes Black Box Server 25.<u style="single">Architecture-Authoring Tool 18</u>The authoring tool 18 is used by the content owner to package a piece of digital content 12 into a form that can be used with the architecture 10 of the present invention. That is, the content owner gives the authoring tool 18 instructions and / or rules regarding the digital content 12 and the instructions and / or rules associated with the digital content 12, and instructions and / or how to package the digital content 12. Or supply rules. The authoring tool 18 then generates digital content 12 encrypted according to the encryption / decryption key, and digital content package 12p with instructions and / or rules associated with the digital content 12. [0021] [0021] In one embodiment of the invention, the authoring tool 18 is instructed to continuously generate packages 12p of several different digital contents 12, each encrypted according to a different encryption / decryption key. Have the same digital content. As you will understand, having several different packages 12p where the digital content 12 is the same simply means "digital content 12" such as package 12p / content 12 (hereafter, unless special circumstances require it). ) May be useful in tracking distributions. Such distribution tracking is usually not required, but can be used by research agencies if Digital Content 12 is illegally sold or broadcast. [0022] In one embodiment of the invention, the encryption / decryption key that encrypts the digital content 12 is a symmetric key, and the encryption key is also the decryption key (KD). As discussed in more detail below, such decryption keys (KD) are delivered in hidden form to the user's computer 14 as part of license 16 of such digital content 12. Preferably, each piece of digital content has a content ID (or each package 12p has a package ID), and each decryption key (KD) has a key ID and is authored. Tool 18 stores the decryption key (kD), key ID, and content ID (or package ID) in the key content database 20 for each 12 pieces of digital content (or for each package 12p). In addition, the 16 types of licenses issued for Digital Content 12 and the terms and conditions for each type of 16 licenses. License data for conditions) can also be stored in the content key database 20, or any other database (not shown). Preferably, the license data can later be modified by the content owner as required by circumstances and market conditions. [0023] In use, the authoring tool 18 is provided with information, among other things, including: -Digital content to package 12 -Use watermark and / or fingerprint format and parameters, if required, -If necessary, the format and parameters of the data compression used, -Cryptography format and parameters used, -If necessary, the serialization format and parameters used, and -Orders and / or rules associated with Digital Content 12. [0024] As is known, a watermark is a hidden computer readable signal that is added to digital content 12 as an identifier. A fingerprint is a watermark that is different for each instance. As you will understand, an instance is a unique version of digital content 12. Any instance can make many copies of it, and each copy has a particular instance. If a particular instance of Digital Content 12 is illegally sold or broadcast, the investigative agency may identify the suspect by following the watermark / fingerprint attached to such Digital Content 12. [0025] Data compression can be performed according to any suitable compression algorithm without departing from the spirit and scope of the present invention. For example, .mp3 or .wav compression algorithms can be used. Of course, the digital content 12 may already be in a compressed state, in which case no additional compression is required. [0026] The instructions / and rules to accompany Digital Content 12 may include virtually any instruction, rule, or other information as appropriate, without departing from the spirit and scope of the invention. As discussed below, such ancillary instructions / rules / information are used primarily by the user and the user's calculator 14 to obtain license 16 and render the digital content 12. Therefore, such ancillary instructions / rules / information can include a properly formatted license acquisition script or the like. This will be described in more detail below. In addition, or instead, such ancillary instructions / rules / information may also include "preview" information designed to give the user a preview of the digital content 12. [0027] The authoring tool 18 then uses the information provided to generate one or more packages 12p for the digital content 12. Each package 12p is then stored on content server 2 and distributed worldwide. [0028] In one embodiment of the invention, with reference to FIG. 2 here, authoring tool 18 is a dynamic authoring tool 18 that receives input parameters. These can be specified and operated on the authoring tool 18. Therefore, such an authoring tool 18 can quickly generate a large number of variants of the package 12p for a large number of pieces of digital content 12. Preferably, the input parameters are embodied in the form of dictionary 28, as illustrated. Here, the dictionary 28 includes the following parameters. [0029] -Name of input file 29a with digital content 12, -The format of the encoding done, -Encryption / decryption key (KD) used, -Ancillary instructions / rules / information ("header information"), packaged with digital content 12 in package 12p, -The form of multiplexing that takes place, and -The name of the output file 29b that writes the package 12p based on digital content 12. [0030] As will be understood, such a dictionary 28 can be easily and quickly modified by the authoring tool 18 operator (human or machine), and thus also the form of authoring performed by the authoring tool 18. It can be changed easily, quickly and dynamically. In one embodiment of the invention, the authoring tool 18 includes an operator interface (not shown) that can be viewed by a human operator on a computer screen. Therefore, such an operator can modify the dictionary 28 through the interface, and can also appropriately assist or regulate the modification of the dictionary 28 by the interface. [0031] In the authoring tool 18, as seen in FIG. 2, the source file 18a searches the dictionary 28 for the name of the input file 29a with the digital content 12 and puts the digital content 12 into the RAM-like memory 29c. Put. The encoding filter 18b then encodes the digital content 12 in memory 29c, and from the input format, the output format (ie, .wav to .asp) according to the encoding format specified in the dictionary 28. , .Mp3 to .asp. Etc.) and put the encoded digital content 12 in memory 29c. As shown, the digital content 12 to be packaged (eg music) is received in a compressed format such as .wav or .mp3 format and converted to a format such as .asp (Active Streaming Protocol) format. Will be done. Of course, other input and output formats can also be adopted and do not deviate from the spirit and scope of the invention. [0032] After that, the encryption filter 18c encrypts the encoded digital content 12 in the memory 29c according to the encryption / decryption key (KD) specified in the dictionary 28, and the encrypted digital content 12 is stored in the memory 29c. Put in. Next, the header filter 18d adds the header information specified in the dictionary 28 to the encrypted digital content 12 in the memory 29c. [0033] As you will understand, in some circumstances, package 12p may contain multiple streams of time-aligned digital content 12 (one stream is shown in Figure 2). Many such streams are multiplexed (ie, "muxed"). Therefore, the multiplexing filter 18e multiplexes the header information and the encrypted digital content 12 in the memory 29c according to the multiplexing format specified in the dictionary 28, and puts the result in the memory 29c. The file write filter 18f then retrieves this result from memory 29c and writes such result to the output file 29b specified in dictionary 28 as package 12p. [0034] It should be noted that in some situations, the format of the encoding performed is usually unchanged. Since the multiplexing format is typically based on the encoding format, the multiplexing format is usually unchanged as well. In fact, in such cases, the dictionary 28 need not include parameters for encoding and multiplexing formats. Instead, you simply "hardwire" the encoding format to the encoding filter, or "hardwire" the multiplexing format to the multiplexing filter. Of course, if the situation requires, the authoring tool 18 may not include all of the above filters, or may include other filters, which may be hardwired or in dictionary 28. The function may be performed according to the specified parameters without departing from the spirit and scope of the present invention. [0035] Preferably, the authoring tool 18 is implemented by the appropriate software on the appropriate computer, processor, or other calculator. The structure and operation of such calculators and such software should be apparent on the basis of the disclosures herein, and therefore no further discussion is needed in this disclosure.<u style="single">Architecture-Content Server 22</u>Referring again to FIG. 1, in one embodiment of the invention, the content server 22 distributes the package generated by the authoring tool 18 or otherwise makes it searchable. Such a package 12p can be distributed at the request of Content Server 22 through any of the appropriate distribution channels and does not deviate from the spirit and scope of the invention. For example, such distribution channels can be the Internet or other networks, electronic bulletin boards, e-mail, and the like. In addition, the content server 22 can be used to copy the package 12p to a magnetic or optical disk or other storage device, and such a storage device may be distributed. [0036] Note that Content Server 22 will be allowed to distribute packages regardless of any trust or security issue. As discussed below, such issues are dealt with in relation to the license server 24 and the relationship between such license server 24 and the user's calculator 14. In one embodiment of the invention, the content server 22 is free to release and distribute the package 12p with the digital content 12 to any distribution destination that requires it. However, Content Server 22 can also constrain the release and distribution of such packages 12p and does not deviate from the spirit and scope of the invention. For example, the content server 22 may first request payment of a predetermined distribution fee prior to distribution, or may require the distribution destination to identify itself, or to identify the distribution destination. It is also possible to actually decide whether or not to distribute based on this. [0037] In addition, the content server 22 can be used to manage inventory by controlling the authoring tool 18 to generate a number of different packages 12p in advance to meet projected demand. For example, the server can generate 100 packages 12p based on the same digital content 12 and deliver each package 12p 10 times. If the supply of package 12p is reduced to, for example, 20, content server 22 can also instruct authoring tool 18, for example, to regenerate 80 additional packages 12p. [0038] Preferably, the content server 22 in architecture 10 has a unique public / private key pair (PU-CS, PR-CS) that evaluates license 16 and decrypts the corresponding digital content 12. Adopted as part of the process of obtaining the decryption key (KD) for. This will be described in more detail below. As is known, a public / private key pair is an asymmetric key, and what is encrypted on one side of a key pair cannot be decrypted without using the other side of the key on the key pair. In a public / private key-to-encryption system, the public key can be made known to the world, but the private key must always be kept secret by the owner of such a private key. Therefore, if the content server 22 encrypts data with its private key (PR-CS), it can send the encrypted data to the world along with its public key (PU-CS) for decryption purposes. .. Correspondingly, if an external device wants to send data to the content server 22 and only such a content server 22 wants to decrypt such data, then such an external device is the first on the content server 22. You must obtain a public key (PU-CS) and then encrypt the data with such a public key. Therefore, the content server 22 (and only the content server 22) can use its private key (PR-CS) to decrypt such encrypted data. [0039] As with the authoring tool 18, the content server 22 is implemented by the appropriate software on the appropriate computer, processor, or other computer. The structure and operation of such machines and such software should be apparent on the basis of the disclosures herein, and no detailed description is needed in this disclosure. Further, in one embodiment of the invention, the authoring tool 18 and the content server 22 may reside in separate workspaces on a single computer, processor, or other computer. Furthermore, it will be acknowledged that the content server 22 may, in some circumstances, include the authoring tool 18 and, as discussed above, perform the functions of the authoring tool 18.<u style="single">Structure of digital content package 12p</u>Next, referring to FIG. 3, in one embodiment of the invention, the digital content package 12p distributed by the content server 22 includes: [0040] -Digital content encrypted using an encryption / decryption key (KD) as discussed earlier (ie, (KD (CONTENT))), -Content ID (or Package ID) of such Digital Content 12 (or Package 12p), -Key ID of decryption key (KD), -Preferably unencrypted license acquisition information, and -The key KD (ie, (KD (PU-CS) S (PR-)) that encrypts the public key (PU-CS) of the content server 22 signed by the private key (PR-CS) of the content server 22. CS))). [0041] With respect to (KD (PU-CS) S (PR-CS)), it will be understood that such items are used in connection with the validation of Digital Content 12 and / or Package 12p. This will be described below. Unlike authentication with a digital signature (see below), a key (PU-CS) is not required to obtain (KD (PU-CS)). Instead, the key (PU-CS) is obtained by simply applying the decryption key (KD). Once obtained in this way, such a key (PU-CS) can be used to check the validity of the signature (S (PR-CS)). [0042] Also, for the package 12p constructed by the authoring tool 18 in this way, such an authoring tool 18 already has the license acquisition information and (KD (PU-CS)) as the header information supplied from the dictionary 28. ) S (PR-CS)) must be in possession. In addition, the authoring tool 18 and content server 22 must probably interact to build (KD (PU-CS) S (PR-CS)). Such interactions include, for example, the following steps. [0043] -Content server 22 sends (PU-CS) to authoring tool 18. -Authoring tool 18 uses (KD) to encrypt (PU-CS) and generate (KD (PU-CS)). [0044] -Authoring tool 18 sends (KD (PU-CS)) to content server 22. -Content server 22 signs (KD (PU-CS)) with (PR-CS) and generates (KD (PU-CS) S (PR-CS)). [0045] -Content server 22 sends (KD (PU-CS) S (PR-CS)) to authoring tool 18.<u style="single">Architecture-License Server 24</u>Referring again to FIG. 1, in one embodiment of the invention, the license server 24 receives a request for license 16 from the user's computer 14 with respect to a piece of digital content 12, and the user's computer 14 issues it. Determine if you can trust the granting of a license 16 to do, negotiate such a license 16, create such a license 16, and perform the function of sending such a license 16 to your computer 14. .. Preferably, the license 16 thus transmitted includes a decryption key (KD) for decrypting the digital content 12. Such license servers 24 and such features will be described in more detail below. Preferably, and like the content server 22, the license server 24 in architecture 10 has a unique public / private key pair (PU-LS, PR-LS) and is part of the process of evaluating license 16. To obtain the decryption key (KD) for decrypting the corresponding digital content 12. This will be described in more detail below. [0046] Like the authoring tool 18 and the content server 22, the license server 24 is implemented by the appropriate software on the appropriate computer, processor, or other computer. The structure and operation of such machines and such software should be apparent on the basis of the disclosure herein, and no detailed discussion is required in this disclosure. Further, in one embodiment of the invention, the authoring tool 18 and / or the content server 22 may reside in separate workspaces on a single computer, processor, or other computer. [0047] In one embodiment of the present invention, prior to the issuance of the license 16, the license server 24 and the content server 22 make a proxy contract or the like, and the license server 24 actually distributes the digital content server 22. Licensing for at least part of Content 12 I agree to be authority). As you will understand, one content server 22 can have proxy contracts with several license servers 24, or one license server 24 has proxy contracts with several content servers 22. None of this deviates from the spirit and scope of the invention. [0048] Preferably, the license server 24 can show the world that it actually has the agency right to issue license 16 of the digital content 12 distributed by the content server 22. By doing so, the license server 24 sends the license server 24's public key (PU-LS) to the content server 22, and the content server 22 sends the license server 24 the secret of the content server 22. It is preferable to send digital authentication including PU-LS as the content signed by the key (CERT (PU-LS) S (PR-CS)). As will be understood, the content (PU-LS) in such authentication cannot be accessed without using the public key (PR-CS) of the content server 22. As will be understood, in general, the digital signature of the underlying data is an encrypted form of such data, if such data has been forged or otherwise modified. It does not match such data when decrypted. [0049] As license agency rights associated with a piece of Digital Content 12, and as part of the licensing function, the License Server 24 must have access to the decryption key (KD) for such Digital Content 12. It doesn't become. Therefore, it is preferred that the license server 24 have access to the content key database 20 having the decryption key (KD), key ID, and content ID (or package ID) for such digital content 12 (or package 12p).<u style="single">Architecture-Black Box Server 26</u>Further referring to FIG. 1, in one embodiment of the invention, the black box server 26 performs a function of installing and updating a new black box 30 on the user's computer 14. As described in more detail below, the black box 30 performs encryption and decryption functions for the user's calculator 14. Also, as described in more detail below, the Black Box 30 is intended to be safe and protected from attack. Such security and protection is provided, at least in part, by upgrading the black box 30 to a new version with the black box server 26 as needed. This will be described in more detail below. [0050] As with the authoring tool 18, content server 22, and license server 24, the black box server 26 is implemented by the appropriate software on the appropriate computer, processor, or other computer. The structure and operation of such machines and such software should be apparent on the basis of the disclosures herein, and therefore no detailed discussion is required in this disclosure. Further, in one embodiment of the invention, the license server 24, authoring tool 18, and / or content server 22 are in separate workspaces on a single computer, processor, or other computer. It can also be resident. However, note that for security purposes it is wise to have the black box server 26 on a separate machine.<u style="single">Architecture-User's Calculator 14</u>Next, referring to FIG. 4, in one embodiment of the present invention, the user's computer 14 is a personal computer or the like, and is a keyboard, mouse, screen, processor, RAM, ROM, hard drive, floppy drive, CD. It has an element such as a player. However, the user's calculator 14 may be, among other things, a dedicated viewing device such as a television or monitor, a dedicated audio device such as a stereo or other music player, a dedicated printer, etc., which deviates from the spirit and scope of the present invention. There is no such thing. [0051] The content owner of a piece of digital content 12 is licensed by the user to allow the user's computer 14 to adhere to the rules specified by the content owner, i.e., render in the required manner. If you don't get it, you have to trust that you won't render digital content 12. Preferably, the user's computer 14 renders the digital content 12 unless such a computer 14 complies with the license rules embodied in the license 16 acquired by the user in connection with the digital content 12. Must have a trusted component or mechanism 32 that can fulfill what it does not to the content owner. [0052] Here, the trust mechanism 32 is a digital rights management (DRM) system 32, which is enabled when the user requests to render a piece of digital content 12, and the user digitally in the required manner. Determine if you have license 16 to render content 12, and if necessary, obtain such license 16 and whether the user has the right to play digital content 12 in accordance with license 16. If the user actually has such a right according to such license 16, the digital content 12 is decrypted for the purpose of rendering. The contents and functions of the DRM system 32 on the user's computer 14 and the relationship with the architecture 10 will be described below.<u style="single">DRM system 32</u>The DRM system 32 performs four main functions together with the architecture 10 disclosed herein. These are (1) content acquisition, (2) license acquisition, (3) content rendering, and (4) black box 30 installation / update. Preferably, any of these functions can be performed at any time, but it will be appreciated that some of these functions require that the digital content 12 has already been acquired.<u style="single">DRM System 32-Content Acquisition</u>Acquisition of digital content 12 by the user and / or the user's computer 14 is typically relatively simple, generally placing a file with encrypted digital content 12 on the user's computer 14. It consists of things. Of course, in order to work with the architecture 10 and DRM system 32 disclosed herein, the encrypted digital content 12 is a suitable form for such architecture 10 and DRM system 32, such as the digital package 12p. It is necessary. This will be described below. [0053] As will be appreciated, the digital content 12 can be obtained either directly or indirectly from the content server 22 and does not deviate from the spirit and scope of the invention. For example, such digital content 12 can be downloaded from a network such as the Internet, distributed on an acquired optical or magnetic disk, received as a part of an e-mail message, or an electronic bulletin board system. You can download it from. [0054] Once acquired, such digital content 12 is stored so that the acquired digital content 12 can be accessed by the rendering application 34 (described below) running on the computer 14 and the DRM system 32. It is preferable to do so. For example, the digital content 12 can be placed as a file on the user's computer 14's hard drive (not shown) or on a network server (not shown) accessible to the computer 14. If the digital content 12 is acquired on an optical or magnetic disk or the like, such a disk need only be loaded into a suitable drive (not shown) coupled to the user's calculator 14. [0055] The present invention assumes that no special tools are required to obtain the digital content 12, either from the content server 22 as a direct distribution source or from some intermediary as an indirect distribution source. There is. That is, it is preferred that the digital content 12 be as easily acquired as any other data file. However, the DRM system 32 and / or the rendering application 34 can also include an interface (not shown) designed to help the user acquire the digital content 12. For example, the interface can include a web browser specially designed to explore digital content 12 and link to a default internet website or the like that is known to be the source of digital content 12. To do.<u style="single">DRM System 32-Content Rendering, Part 1</u>Referring to FIG. 5A, in one embodiment of the invention, it is assumed that the encrypted digital content 12 is distributed, received by the user, and placed on the computer 14 by the user in the form of a stored file. Attempts to render digital content 12 by performing a variation on the render command (step 501). For example, such a rendering command can embody the digital content 12 as a "play" or "open" request. Depending on the computer environment, for example, "MICROSOFT" sold by MICROSOFT Corporation in Redmond, Washington. Like the WINDOWS "operating system, such a play or open command can be as easy as" clicking "on the icon representing digital content 12. Of course, other embodiments of such rendering commands can also be employed and do not deviate from the spirit and scope of the invention. In general, such rendering commands can be considered to be executed whenever the user commands a file with digital content 12 to be opened, run, executed, and so on. [0056] Importantly, and additionally, such rendering commands can be embodied as a request to copy the digital content 12 into another form, such as print form, visual form, auditory form, and so on. As you will understand, the same digital content 12 can also be rendered in one form, such as on a computer screen, and then in another form, such as a printed document. In the present invention, each rendering format is performed only if the user has the right to do so. This will be described below. [0057] In one embodiment of the invention, the digital content 12 is in the form of a digital file having a filename ending in an extension, and the computer 14 is based on such an extension as a particular type of rendering application. 34 can be decided to run. For example, if the filename extension indicates that the digital content 12 is a text file, then the rendering application 34 is "MICROSOFT" sold by Microsoft Corporation in Redmond, Washington. It will be some form of word processor like "WORD". Similarly, if the file name extension indicates that the digital content 12 is an audio, video, and / or multimedia file, then the rendering application 34 Will also be some form of multimedia player, such as the "MICROSOFT MEDIA PLAYER" sold by MICROSOFT Corporation in Redmond, Washington. [0058] [0058] Of course, other methods of determining the rendering application can also be adopted and do not deviate from the spirit and scope of the invention. As an example only, the digital content 12 can also include unencrypted metadata (header information described above), in which case the metadata renders such digital content 12. Contains information about the format of the rendering application 34 required for. [0059] Preferably, such a rendering application 34 tests the digital content 12 associated with the filename to determine if such digital content 12 is encrypted in a rights protection form (steps 503,505). ). If unprotected, digital content 12 can be rendered without any further hassle (step 507). If protected, the rendering application 34 determines from the encrypted digital content 12 whether a DRM system 32 is required to reproduce such digital content 12. In response, such a rendering application 34 instructs the user's calculator 14 to run the DRM system 32 on it (step 509). Such a rendering application 34 then calls such an RDM system 32 to decrypt the digital content 12 (step 511). As discussed in more detail below, the DRM system 32 actually entitles the user to play digital content 12 in accordance with the valid license 16 for such digital content 12 and the license rules in the valid license 16. Decrypt digital content 12 only if you have it. Preferably, once the DRM system 32 is called by the rendering application 34, such a DRM system 32 is at least intended to determine if the user has the right to play such digital content 12. Take control from rendering application 34 (step 513).<u style="single">DRM system 32 components</u>The license evaluation unit 36 identifies one or more licenses 16 corresponding to the requested digital content 12, determines whether such licenses 16 are valid, and licenses in such valid licenses 16. The rules are reviewed and based on the revised license rules, it is determined whether the requesting user has the right to render the requested digital content 12, in particular, in the requested manner. As you will understand, the license evaluation unit 36 is a trusted component in the DRM system 32. In this disclosure, "trust" means that the trust element fulfills the wishes of the owner of Digital Content 12 in accordance with the description of rights in License 16 with License Server 24 (or any other trusting element). It means convincing (trusting element) and that the user cannot easily change such a trusting element for any evil or other purpose. [0060] To ensure that License Evaluation Unit 36 actually evaluates License 16 properly, and in order to bypass the actual evaluation of License 16, such License Evaluation Department 36 is forged or otherwise modified by the user. Such a license evaluation unit 36 must be trusted to ensure that it is not. Therefore, the license evaluation unit 36 runs in a protected or concealed environment so that the user's access to such a license evaluation unit 36 is denied. Of course, other protective measures can also be adopted for the License Evaluation Unit 36 and do not deviate from the spirit and scope of the invention.<u style="single">DRM System 32 Components-Black Box 30</u>Primarily, and as discussed earlier, the black box 30 performs encryption and decryption functions in the DRM system 32. That is, the black box 30 works with the license evaluation unit 36 to decrypt and encrypt certain information as part of the license evaluation function. In addition, once the license evaluation unit 36 determines that the user actually has the right to render the requested digital content 12 in the required manner, the black box 30 will contain such digital content 12. Therefore, a decryption key (KD) is given, and based on such a decryption key (KD), the function of decrypting such digital contents 12 is executed. [0061] The black box 30 is also a trusted component in the DRM system 32. That is, the license server 24 must trust that the black box 30 performs the decryption function only in accordance with the license rules in license 16 and also has the evil purpose of bypassing the actual evaluation of license 16. You must also trust that such a black box 30 will not work if it is forged or otherwise modified by the user in. Therefore, the black box 30 also runs in a protected or concealed environment, and the user is denied access to such a black box 30. Again, other protective measures may be adopted for the black box 30 without departing from the spirit and scope of the invention. Preferably, and like the content server 22 and the license server 24, the black box 30 in the DR system 32 has a unique public / private key pair (PU-BB, PR-BB) and is licensed 16. Is used as part of the process of evaluating and obtaining a decryption key (KD) for decrypting digital content 12. This will be described in more detail below.<u style="single">DRM System 32 Components-License Store 38</u>The license store 38 stores the license 16 received for the digital content 12 supported by the DRM system 32. The license store 38 itself does not need to be trusted. This is because the license store 38 merely stores license 16, each of which is already built in as a trusted component. This will be described below. In one embodiment of the invention, the license store 38 is simply a subdirectory of a drive, such as a hard disk drive or network drive. However, the license store 38 embodies in all other forms without departing from the spirit and scope of the invention, as long as it performs the function of storing the license 16 in a relatively convenient location in the DRM system 32. It is also possible.<u style="single">DRM System 32 Components-State Store 40</u>The state store 40 performs the function of maintaining the state information corresponding to the license 38 that was in the current or previous license store 38. Such state information is created by the DRM system 32 and stored in the state store 40 as needed. For example, if a particular license 16 only allows a given number of times to render a piece of digital content 12 that corresponds to it, the state store 40 will have state information about how many times such license 16 was actually rendered. To maintain. The state store 40 continues to maintain state information about license 16 that is no longer in license store 38, and in an attempt to remove the corresponding state store information from state store 40, removes license 16 from license store 38, and then removes license 16 from license store 38. Avoid situations where it would be advantageous to obtain the same license 16. [0062] The state store 40 must also be trusted to ensure that the information stored internally is not reset to a more favorable state for the user. Therefore, the state store 40 also runs in a protected or concealed environment so that the user's access to such a state store 40 is denied. Again, other protective measures can, of course, be adopted for the state store 40 and do not deviate from the spirit and scope of the invention. For example, the state store 40 may be stored on the computer 14 in encrypted form by the DRM system 32.<u style="single">DRM System 32-Content Rendering, Part 2</u>With reference to FIG. 5A again, content rendering in one embodiment of the present invention will be discussed again. Once the DRM system 32 takes control from the calling rendering application 34, whether such a DRM system 32 has the right to render the requested digital content 12 in the manner requested by the user. Start the process of determining whether or not. That is, the DRM system 32 attempts to locate a valid authorization license 16 in the license store (steps 515,517) or obtain a valid entitlement license 16 from the license server 24 (ie, discussed below). Perform the license acquisition function shown in Figure 7). [0063] As a first step, and here with reference to Figure 6, the license evaluation unit 36 of such a DRM system 32 checks license 38 and receives one or more licenses 16 corresponding to digital content 12. Check if it is done (step 601). Typically, License 16 is in the form of a digital file, as discussed below, but it will be appreciated that License 16 may be in other forms without departing from the spirit and scope of the invention. Typically, a user receives digital content 12 without such license 16, but receives digital content 12 with the corresponding license 16 without departing from the spirit and scope of the invention. It will be acknowledged that it may be done as well. [0064] As discussed earlier in relation to FIG. 3, each piece of digital content 12 is in package 12p, and the content ID (or package ID) identifies such digital content 12 (or package 12p). , The key ID identifies the decryption key (KD) that decrypts the encrypted digital content 12. Preferably, the content ID (or package ID) and key ID are in unencrypted form. Therefore, and specifically, based on the content ID of the digital content 12, the license evaluation unit 36 looks for any license 16 in the license store 8 that houses the identification of the applicability of such content ID. .. It should be noted that such a license, especially if the owner of the digital content 12 has several different licenses 16 for such digital content 12 and the user has obtained a large number of such licenses 16. Note that many 16 may be found. In fact, if the license evaluation unit 36 cannot find any license 16 corresponding to the requested digital content 12 in the license store 38, the DRM system 32 performs the license acquisition function described below (Fig. 5). Step 519). [0065] Now suppose the DRM system 32 is required to render a piece of digital content 12 and one or more corresponding licenses 16 are in the license store 38. In one embodiment of the invention, the license evaluation unit 36 of the DRM system 32 subsequently determines, for each of these licenses 16, whether or not such licenses 16 themselves are valid (step of FIG. 6). 603 and 605). Preferably, and specifically, each license 116 includes a digital signature 26 based on the content 28 of that license 16. As you will understand, the digital signature 26 does not match the license 16 if the content 28 is forged or otherwise modified. Therefore, the license evaluation unit 36 can determine whether or not the content 28 is in the form received from the license server 24 (that is, is valid) based on the digital signature 26. If no valid license 16 is found in the license store 38, the DRM system 32 can perform the license acquisition function described below to obtain such a valid license 16. [0066] Assuming that one or more valid licenses 16 are found, for each valid license 16, the license evaluation unit 36 of the DRM system 32 then finds such a valid license 16 corresponding digitally in the desired manner. It is determined whether or not to give the user the right to render the content 12 (that is, to authorize it). That is, the license evaluation unit 36 further determines whether or not the requesting user has the right to play the requested digital content 12 and what the user does with the digital content 12 based on the description of the right in each license 16. Make a judgment based on whether you are trying. For example, such a statement of rights allows the user to render the digital content 12 into sound, but not to decipher it and render it into a digital copy. [0067] As will be understood, the description of rights in each license 16 specifies whether or not the user has the right to play the digital content 12 based on any of several factors. Factors include who the user is, where the user is, what kind of calculator 114 the user is using, which rendering application 34 is calling the DRM system 32, date, time, etc. Is done. In addition, the description of the right may limit the license 16 to, for example, a predetermined number of playbacks and a predetermined playback time. In such cases, the DRM system 32 must refer to all state information about license 16 (ie, how many times digital content 12 has been rendered, the total amount of time digital content 12 has been rendered, etc.). Such state information is stored in the state store 40 of the DRM system 32 of the user's calculator 14. [0068] Therefore, the license evaluation unit 36 of the DRM system 32 examines the description of the rights of each valid license 16 and determines whether or not such a valid license 16 grants the rights requested to the user. In doing so, the license evaluation unit 36 may have to refer to other data inside the user's calculator 14 to determine whether or not he / she has the rights requested by the user. As can be seen in FIG. 4, such data includes the identification 42 of the user's computer (machine) 14 and its specific aspects, the identification of the user 44 and its specific aspects, the identification of the rendering application 34 and its specific aspects. Specific embodiments, such as a system clock 46, can be included. If no valid license 16 is found that gives the user the right to render the digital content 12 in the manner requested, the DRM system 32 then performs the licensing function described below and actually does such: If license 16 can be obtained, obtain such license 16. [0069] Of course, in some cases, the user may not have the right to render the digital content 12 in the requested manner. This is because the content owners of such digital content 12 have ordered that users not be granted a license 16 that allows them to print text documents or copy multimedia representations in unencrypted form. This is because there are cases. In one embodiment of the invention, the digital content 12 includes data on what rights are available at the time of purchase of license 16 and the types of license 16 available. However, at any given time, the content owner of a piece of digital content 12 may now switch to such digital content 12 by changing the license 16 obtained for such digital content 12. It will be acknowledged that the available rights may change.<u style="single">DRM System 32-License</u>As shown in FIG. 7, if the license evaluation unit 36 cannot actually find any valid authorization license 16 corresponding to the requested digital content 12 in the license store 38, the DRM system 32 obtains the license. Perform the function. As shown in FIG. 3, each piece of digital content 12 is unencrypted information about how to obtain a license 16 for rendering such digital content 12 (ie, license acquisition). It is packaged with information). [0070] In one embodiment of the invention, such license acquisition information can be used for 16 types of licenses available and one or more Internet websites that can access one or more suitable license servers 24. Or it can contain other site information (especially). Here, each license server 24 can actually issue the license 16 corresponding to the digital content 12. Of course, the license can also be obtained in other ways and does not deviate from the spirit and scope of the invention. For example, license 16 can be obtained from the license server 24 on an electronic bulletin board system, or can be obtained by yourself or by regular mail in the form of a file such as a magnetic or optical disk. [0071] Assuming that the location for obtaining license 16 is actually the license server 24 on the network, the license evaluation unit 36 will use such license server 24 based on website or other site information. A network connection is established for it, and then a request for license 16 is sent from the license server 24 thus connected (steps 701, 703). That is, once the DRM system 32 contacts the license server 24, such a DRM system 32 sends appropriate license request information 37 to such a license server 24. In one embodiment of the invention, such license 16 requirement information 36 can include, among other things: [0072] -Public key (PU-BB) of black box 30 of DRM system 32, -DRM system 32 black box 30 version number, A certificate containing a digital signature from the certification authority that certified the black box 30 (the certificate can actually include the public key and version number of the black box 30 mentioned above), -Content ID (or Package ID) that identifies Digital Content 12 (or Package 12p), -Key ID that identifies the decryption key (KD) for decrypting digital content 12, -16 types of licenses requested (if many types are actually available), -Types of rendering applications 34 that required rendering of digital content 12. [0073] Of course, a larger or smaller amount of request information 36 of the license 16 can also be transmitted by the DRM system 32 to the license server 24 without departing from the spirit and scope of the present invention. For example, information about the type of rendering application 34 may not be needed, while additional information about the user and / or the user's calculator 14 may be needed. [0074] Once the license server 24 receives the request information 36 for license 16 from the DRM system 32, the license server 24 may perform some checks for trust / authentication and other purposes. In one embodiment of the invention, such a license server 24 checks the certificate, including the digital signature of the certification authority, to determine if it has been counterfeited or otherwise modified (step 705, step 705). 707). If so, the license server 24 refuses to grant any license 16 based on request information 36. The license server 24 can also hold a list of known "bad" users and / or the calculator 14 of the user, and also from the calculator 14 of such bad users and / or bad users on the list. It is also possible to refuse to grant any license 16 on request. Such a "bad guy" list can be compiled in any suitable manner and does not deviate from the spirit and scope of the invention. [0075] Based on the request received and the information that accompanies it, especially based on the content ID (or package ID) in the license request information, the license server 24 queries the content key database 20 (Figure 1) and is the basis for the request. -Locate the record corresponding to content 12 (or package 12p). As discussed earlier, such records include a decryption key (KD), key ID, and content ID for such digital content 12. In addition, such records can contain license data for the 16 types of licenses issued to the digital content 12 as well as the terms and conditions of each type of license 16. Alternatively, such a record may include a pointer, link, or reference to a location that has such additional information. [0076] As mentioned above, many types of licenses 16 can be obtained. For example, with a relatively small license fee, you can get a license 16 that allows a limited number of renderings. With a relatively large license fee, you can get a license 16 that allows unlimited rendering until the maturity date. For even higher license fees, you can get a license that allows unlimited rendering with no maturity date. In fact, any type of license 16 with all types of license terms can also be devised and issued by the license server 24 and does not deviate from the spirit and scope of the invention. [0077] In one embodiment of the invention, the request for license 16 is made with the help of a web page or the like as it is transmitted from the license server 24 to the user's computer 14. Preferably, such a web page contains information about any kind of license 16 obtained from the license server 24 for the digital content 12 that is the basis of the license 16 request. [0078] In one embodiment of the invention, prior to issuing license 16, the license server 24 checks the version number of the black box 30 to determine if such a black box 30 is relatively new. (Steps 709, 711). As you will understand, the black box 30 is a user who is safe and has an evil purpose (ie, improperly renders digital content 12 without license 16 or is out of the terms of the corresponding license 16). The purpose is to protect against attacks from. However, it can be acknowledged that in reality there is no system or software that is completely secure from such attacks. [0079] Obviously, if the black box 30 is relatively new, i.e., acquired or updated relatively recently, such a black box 30 can be successfully attacked by such an evil user. There is little sex. Preferably, and as a trust issue, if the license server 24 receives a license request with request information that includes a version number of a relatively non-new black box 30, such a license server 24 will have a corresponding black. Refuse to issue the requested license 16 until Box 30 is upgraded to the current version. This will be described below. Simply put, the license server 24 does not trust such a black box 30 unless it is relatively new. [0080] [0080] In connection with the Black Box 30 of the present invention, the terms "new" or "relatively new" are consistent with the ability to trust the Black Box 30 based on its age and usage. It can have an appropriate meaning and does not deviate from the spirit and scope of the present invention. For example, "new" can be defined according to the number of years (ie, less than a month). As another example, "new" can also be defined based on the number of times the black box 30 has decrypted digital content (ie, less than 200 decryptions). In addition, "new" can be based on the principles set by each license server 24, in which case one license server 24 may have a different definition for "new" than another license server. In addition, the license server 24 can also define "new" separately, among other things, depending on the digital content 12 for which license 16 is required, or depending on the type of license 16 requested. [0081] Assuming that the license server 24 is convinced that the version number of the black box 30 or other indicators of such a black box 30 are new, the license server 24 then negotiates the terms of license 16 with the user. To do. Alternatively, the license server 24 negotiates license 16 with the user and is itself convinced of the version number of the black box 30 indicating that such a black box 30 is new (step 713, then 711). ). Of course, the amount of negotiation depends on the type of 16 licenses issued and other factors. For example, if the license server 24 simply issues a one-time unlimited use license 16, there is little need to negotiate. On the other hand, if License 16 is based on items such as variable value, slides, break points, and other details, such items and details may be issued between License Server 24 and the user. In some cases, it must be devised before it becomes. [0082] As will be understood, in some circumstances, license negotiation may require the user to further provide information to the license server 24 (eg, information about the user, the user's computer 14, etc.). Importantly, license negotiations are, among other things, payment methods (credit accounts, debit accounts, checks by mail, etc.) and / or payment methods (immediate lump sum payments, etc.) that are mutually acceptable by the user and the license server 24. It is necessary to decide (division of time period). [0083] Once all terms and conditions of license 16 have been negotiated and both license server 24 and the user agree (step 715), license server 224 generates digital license 16 (step 719). The license 16 generated in this way is, at least in part, the decryption key for the license request, the public key (PU-BB) of the black box 30, and the digital content 12 that is the basis of the request obtained from the content key database 20. Based on (KD). In one embodiment of the invention, and as seen in FIG. 8, the generated license 16 includes: [0084] -Content ID of Digital Content 12 to which License 16 applies, -Probably encrypted with a decryption key (KD) (ie, KD (DRL)), Digital Rights License (DRL) 48 (ie, a license written in a prescribed format that License Evaluation Department 36 can inquire 16 Description of rights, i.e. actual conditions), -The decryption key (KD) (ie (PU-BB (KD)) for the digital content 12 encrypted with the public key (PU-BB) of the black box 30 received in the license request. [0085] -From the license server 24, encrypted with the private key of the license server 24 (ie, (S (PR-LS))) based on (KD (DRL)) and (PU-BB (KD)) Digital signature (without certificate attached), and -Certificate previously obtained by License Server 24 from Content Server 22. Such a certificate indicates that the license server 24 has the authority to issue license 16 from the content server 22 (ie, (CERT (PU-LS) S (PR-CS))). [0086] As will be understood, the aforementioned elements and perhaps other elements are also packaged in digital files or some other suitable form. Similarly, of course, if (PU-BB (KD)) in DRL48 or License 16 is counterfeited or otherwise modified, the digital signature (S (PR-LS)) in License 16 will not match. Therefore, such license 16 is not valid. For this reason, the DRL does not necessarily have to be in the above-mentioned encryption form (ie, (KD (DRL)), but in some cases such an encryption form is desirable, and therefore the present invention. May be adopted without departing from the spirit and scope of. [0087] Once the digital license 16 is ready, the next requester is such a license 16 (ie, DRM system 32 on the user's calculator 14) (step 719 in Figure 7). Preferably, license 16 may be transmitted through the same route as the request was made (ie, the Internet or other network), but other routes may be used and deviate from the spirit and scope of the invention. There is no such thing. Upon receipt, the requesting DRM32 preferably places the automatically received digital license 16 in the license store 38 (step 721). [0088] In some cases, the user's calculator 14 may malfunction, and the license 16 stored in the license store 38 of the DRM system 32 on the user's calculator 14 may become unsearchable and may be lost. It will be understood that it is possible. Therefore, the license server 24 retains the database 50 of the issued license 16 (Fig. 1), and if the user actually has the right to be reissued, the license issued by such a license server 25 to the user. It is preferable to give 16 copies or reissue (hereinafter "reissue"). In the above-mentioned case where license 16 becomes unsearchable and lost, it is stored in the state store 40, and the state information corresponding to such license 16 may also be lost. Such lost state information must be taken into account when reissuing License 16. For example, it is possible to legally reissue a fixed number of rendering licenses 16 in proportion to a certain percentage after a relatively short time period and not at all after a relatively long time period.<u style="single">DRM System 32-Install / Update Black Box 30</u>As discussed earlier, as part of the ability to obtain license 16, the license server 24 has a black box 30, that is, a relatively old version number, in which the DRM system 32 of the user's computer 14 is not relatively new. If you have a black box 30 with, you can deny the request for license 16 from the user. In such cases, it is preferable to update the black box 30 of such a DRM system 32 so that the licensing function can proceed. Of course, the black box 30 can be updated at other times and does not deviate from the spirit and scope of the invention. [0089] Preferably, a non-unique "lite" version of the black box 30 is provided as part of the process of installing the DRM system 32 on the user's calculator 14. Such a "light" black box 30 upgrades to a unique legitimate version before rendering a piece of digital content 12. Obviously, if each black box 30 in each DRM system 32 is unique, a security breach to one black box 30 can easily be repeated for any other black box 30. Can't. [0090] Next, referring to FIG. 9, the DRM system 32 obtains a unique black box 30 by requesting from a black box server or the like (as discussed earlier and shown in FIG. 1) (step). 901). Typically, the Internet is used to make such requests, but other means of access may be employed and do not deviate from the spirit and scope of the invention. For example, the connection to the black box server 26 can be direct, either local or remote. An upgrade from one unique non-light black box 30 to another unique non-light black box 30 at any given time, for example, the license server 24 sees the black box 30 as not new. It can be requested by the DRM system 32, as it did. This is as discussed earlier. [0091] The black box server 26 then generates a new unique black box 30 (step 903). As can be seen in Figure 3, each of the new black boxes 30 is equipped with a version number and a certificate with a digital signature from the certification authority. As discussed earlier in the context of the licensing feature, the version number of the black box 30 indicates its relative age and / or usage. Similarly, the certificate with a digital signature from the certification authority, which was discussed earlier in relation to the license acquisition function, is an offer or evidence mechanism from the certification authority that the license server 24 trusts the black box 30. .. Of course, the license server 24 trusts that the certification authority actually issues such a certificate to a trusted black box 30. In practice, it is possible that the license server 24 does not trust a particular certification authority and refuses to accept any certificate issued by such a certification authority. For example, if it is discovered that a particular certification authority is involved in a pattern of fraudulent issuance of certificates, trust cannot be gained. [0092] Preferably, and as discussed earlier, the black box server 26 provides a new unique public / private key pair (PU-BB, PR-BB) with a newly generated unique black box 30. Including. Preferably, the private key (PU-BB) of the black box 30 is accessible only from such a black box 30, and the computer 14 having the DRM system 32 including such a black box 30 and its users. It is hidden from the rest of the world, including, and is inaccessible. [0093] Most of the concealment methods can be used as long as such concealment methods actually perform the function of hiding the private key (PU-BB) from the world, and do not deviate from the spirit and scope of the present invention. .. As an example only, the private key (PU-BB) may be divided into several subcomponents, each subcomponent may be uniquely encrypted and stored in a different location. In such situations, it is preferable to fully assemble such a subassembly to never generate a complete private key (PU-BB). [0094] In one embodiment of the present invention, in order to encrypt such a private key (PU-BB), an encryption technique using a code is followed. That is, in such an embodiment, the actual software code (or other software code) of the black box 30 is used as the encryption key (plurality of encryption keys). So, for example, if the code in the black box 30 (or other software code) is forged or otherwise modified by the user for an evil purpose, such a private key (PU-BB) Cannot be deciphered. [0095] Each of the new black boxes 30 will be delivered with new public / private key pairs (PU-BB, PR-BB), but such new black boxes 30 will be on the user's computer 14. It is also preferable to give the DRM system 32 access to the old public / private key pair from the old black box 30 previously delivered (step 905). Therefore, the upgraded black box 30 can also use the old key pair to access the old digital content 12 and the corresponding old license 16 generated according to such an old key pair. This will be discussed in more detail below. [0096] Preferably, the upgraded black box 30 delivered by the black box server 26 is closely coupled or associated with the user's calculator 14. Therefore, the upgraded black box 30 cannot be operably transferred between a large number of computers for evil purposes and others. In one embodiment of the invention, as part of the black box 30 requirement (step 901), the DRM system 32 is hardware that is unique to such a DRM system 32 and / or to the user's computer 14. Information is provided to the black box server 26, which partially generates a black box 30 in the DRM system 32 based on such provided hardware information. The upgrade black box 30 thus generated is then delivered to the user's calculator 14 and installed on the DRM system 32 (steps 907, 909). Recognizing that if the upgraded black box 30 is somehow transferred to another calculator 14, the transferred black box 30 is not intended for such another calculator 14, and thus Do not allow all other requests to proceed with rendering on the computer 14. [0097] Once the new black box 30 is installed on the DRM system 32, such a DRM system 32 can perform licensing or any other function.<u style="single">DRM System 32-Content Rendering, Part 3</u>Next, referring to FIG. 5B, where the license evaluation unit 36 discovers at least one valid license 16, and at least one of such valid licenses 16 provides the corresponding digital content 12 in the required manner. Assuming that the user is found to have the necessary rights (ie, authorization) to render, the license evaluation unit 36 selects one of these licenses 16 for further use (step 519). That is, in order to render the requested digital content 12, the license evaluation unit 36 and the black box 30 together obtain a decryption key (KD) from such a license 16, and the black box 30 is The digital content 12 is decrypted using such a decryption key (KD). In one embodiment of the invention, and as discussed above, the decryption key (KD) obtained from License 16 is encrypted with the public key (PU-BB (KD)) of Black Box 30. The black box 30 uses its private key (PU-BB) to decrypt the decryption key thus encrypted and generate the decryption key (KD) (steps 521, 523). However, other methods of obtaining the decryption key (KD) of the digital content 12 may be used and do not deviate from the spirit and scope of the present invention. [0098] Once Black Box 30 has the decryption key (KD) for Digital Content 12 and has permission from License Evaluation Unit 36 to render Digital Content 12, control can be returned to Rendering Application 34 ( Steps 525, 527). In one embodiment of the invention, the rendering application 34 then calls the DRM system 32 / black box 30 to send at least a portion of the encrypted digital content 12 to the black box 30 for a decryption key (KD). ) According to (step 529). The black box 30 decrypts the digital content 12 based on the decryption key (KD) of the digital content 12, and then the black box 30 renders the decrypted digital content 12 in order to actually render it. Return to application 34 (steps 533, 535). The rendering application 34 sends a portion of the encrypted digital content 12 or the entire digital content 12 to the black box 30 to decipher such digital content 12 without departing from the spirit and scope of the present invention. It can be decrypted based on the key (KD). [0099] Preferably, if the rendering application 34 sends the digital content 12 to the black box 30 for decryption, the black box 30 and / or the DRM system 32 authenticates such a rendering application 34, which is actually the DRM. Make sure it is the same rendering application that you first requested System 32 to run (step 531). Alternatively, it is possible that the rendering approval was obtained fraudulently by actually rendering with another type of rendering application 34, based on a rendering request for one type of rendering application 34. Assuming successful authentication and the digital content 12 being decrypted by the black box 30, the rendering application 34 can render the decrypted digital content 12 (steps 533, 535).<u style="single">Key transaction sequence</u>Next, referring to FIG. 10, in one embodiment of the invention, a key transaction sequence is performed to obtain a decryption key (KD) for a requested piece of digital content 12 and evaluate license 16. (That is, perform steps 515-523 of FIGS. 5A and 5B). In this sequence, primarily the DRM system 32 obtains the decryption key (KD) from license 16 and uses the information obtained from license 16 and digital content 12 to authenticate or verify the validity of both, and then license 16. Determines whether or not grants the right to render the digital content 12 in the manner actually sought. If given, digital content 12 can be rendered. [0100] Keeping in mind that each license 16 of Digital Content 12 includes: -Content ID of Digital Content 12 to which License 16 applies, -Probably a Digital Rights License (DRL) 48 (ie, KD (DRK)) encrypted with a decryption key (KD). [0101] -The decryption key (KD) of the digital content 12 encrypted with the public key (PU-BB) of the black box 30 (ie, (PU-BB (KD)), -A digital signature from the license server 24 (ie, (S (PR)) based on (KD (DRK)) and (PU-BB (KD)) and encrypted with the license server 24's private key. -LS))), and -Certificate that License Server 24 previously obtained from Content Server 22 (ie, (CERT (PU-LS) S (PR-CS))), In addition, keeping in mind that package 12p with digital content 12 includes: -Content ID of such digital content 12, Digital Content 12 encrypted by KD (ie, (KD (CONTENT)), -Unencrypted license acquisition scripts and -Key KD, which encrypts the public key (PU-CS) of the content server 22 signed by the private key (PR-CS) of the content server 22 In one embodiment of the invention, a particular sequence of key transactions is performed for a particular one of license 16 of digital content 12. This sequence is as follows. [0102] 1. Based on (PU-BB (KD)) from license 16, the black box 30 of the DRM system 32 on the user's computer 14 applies its private key (PR-BB) and obtains (KD). (Step 1001). (PR-BB (PU-BB (PU-BB (KD)) = (KD)). It is important to note that the black box 30 uses KD to create digital content 12 without any further hassle. Note that it is also possible to attempt to decrypt. Such trust is a certification from a certification authority that such a license server 24 guarantees the authenticity of such a black box 30. Based on the document, it was established when license 16 was issued. Therefore, even if the black box 30 obtains the decryption key (KD) as the first step rather than the final step, the DRM system 32 will: Continue to perform all License 16 validation and evaluation functions as described. [0103] 2. Based on (KD (PU-CS) S (PR-CS)) from Digital Content 12, Black Box 30 applies the newly acquired decryption key (KD) to (PU-CS). Get (step 1003). (KD (KD (PU-CS) = (PU-CS)). In addition, the black box 30 applies (PU-CS) to the signature (S (PR-CS)), such as Convince the signature and such Digital Content 12 / Package 12p to be valid (step 1005). If not, interrupt the process and deny access to Digital Content 12. [0104] 3. Based on (CERT (PU-LS) S (PR-CS)) from license 16, the black box 30 applies the newly acquired public key (PU-CS) of the content server 22 and applies it. Convince that the certificate is valid (step 1007). This means that the license server 24 that issued the license 16 lets the authority from the content server 22 do so, and then inspects the contents of the certificate to obtain (PU-LS) (step). 1009). If not valid, abort the process and deny access to Digital Content 12 under License 16. [0105] 4. Based on (S (PR-LS)) from License 16, Black Box 30 applies the newly acquired Public Key (PR-LS) of License Server 24 and License 16 is valid. Convince that there is (step 1011). If not valid, abort the process and deny access to Digital Content 12 under License 16. [0106] 5. Assuming that all validation steps are successful and the DRL48 in License 16 is actually encrypted with the decryption key (KD), the license evaluation unit 36 has already obtained the decryption key (KD). ) Is applied to (KD (DRL)) obtained from license 16 to obtain license terms from license 16 (ie DRL 48) (step 1013). Of course, if the DRL 48 in License 16 is not actually encrypted with the decryption key (KD), step 1013 may be omitted. Next, the license evaluation unit 36 evaluates the DRL48, makes an inquiry, and does the user's computer 14 have the right to render the corresponding digital content 12 in the requested manner based on the DRL48 in the license 16. Whether or not (that is, whether or not DRL48 has authorized) is determined (step 1015). If the license evaluation unit 36 determines that such a right does not exist, it aborts the process and denies access to the digital content 12 under license 16. [0107] 6. Finally, as a result of the evaluation of License 16, it was positively determined that the user's computer 14 has the right to render the corresponding digital content 12 in the required manner, based on the conditions of the DRL 48. Assuming, the license evaluation unit 36 notifies such a black box 30 that the black box 30 can render the corresponding digital content 12 according to the decryption key (KD). The black box 30 then applies the decryption key (KD) to decrypt the digital content 12 from the package 12p (ie, (KD (KD (CONTENT)) = (CONTENT)) (step 1017). [0108] It is important to note that the series of steps embodied above represents an alternating or "ping-pong operation" between license 16 and digital content 12. Such a ping-pong operation ensures that the digital content 12 is tightly tied to license 16 and is validated and validated only if both digital content 12 and license 16 are properly issued and in valid form. Guarantee that the evaluation process can be performed. In addition, to obtain the public key (PU-CS) of the content server 22 from license 16 and the digital content 12 from package 12p in decrypted form (and perhaps the license terms from license 16 in decrypted form). Since the same decryption key (KD) is required (to obtain (DRL48)), such items are also closely linked. Sign validation also ensures that the digital content 12 and license 16 are in the same form issued by content server 22 and license server 24, respectively. Therefore, it is difficult, if not impossible, to decipher the digital content 12 by bypassing the license server 24, nor is it possible to modify and decipher the digital content 12 or license 16. It's difficult, if not difficult. [0109] In one embodiment of the invention, signature validation, in particular license 16 signature validation, is performed instead as follows. As shown in Figure 8, instead of encrypting the signature with the license server 16 private key (PR-LS), each license 16 signature is with the private root key (PR-R) (not shown). Encrypt. In this case, the black box 30 of each DRM system 32 contains a public root key (PU-P) (also not shown) corresponding to the secret root key (PR-R). The secret root key (PR-R) is known only to the root entity, and if the license server 24 adjusts such license server 24 to issue license 16 using the root entity. Only license 16 can be issued. [0110] That is, in such an embodiment, 1. The license server 24 supplies its public key (PR-LS) to the root entity. [0111] 2. The root entity returns the license server public key (PU-LS) encrypted with the private root key (PR-R) to such a license server 24 (ie, (CERT (PU-LS)). S (PR-R)))). [0112] 3. The license server 24 then issues license 16 with a signature encrypted with the license server's public key (S (PR-LS)) and further licenses a certificate from the root entity. Attached to (CERT (PU-LS) S (PR-R)). [0113] In order for the DRM system 18 to validate the license 17 thus issued, the DRM system 18 1. Apply the public root key (PU-R) to the attached certificate (CERT (PU-LS) S (PR-R)) to obtain the license server public key (PU-LS). 2. Apply the obtained license server public key (PU-LS) to the signature of license 16 (PR-LS). [0114] Importantly, permission for the root entity to issue license 16 to such a license server 24 by supplying a certificate (CERT (PU-LS) S (PR-R)) to the license server 24. Such a license server 24 also supplies a certificate to the second license server 24 (ie, (CERT (PU-LS2) S (PR-LS1)), just as it gives. It should also be acknowledged that this also allows the second license server to issue license 16. Now, as is clear, license 16 issued by the second license server is the first certificate. Includes (CERT (PU-LS1) S (PR-R)) and second certificate (CERT (PU-LS2) S (PR-LS1)). Similarly, such license 16 is the first and first. 2 Validity is acknowledged by following the chain of certificates. Of course, additional links may be added within the chain to allow them to pass through. [0115] One of the advantages of the signature validation process described above is that the root entity periodically changes the secret root key (RP-R), which also periodically adds new certificates to each license server 24. (CERT (PU-LS) S (PR-R)) can be acquired. Importantly, each license server must upgrade itself as a requirement to obtain such a new certificate. As with the black box 30, if the license server 24 is relatively new, that is, if it has been upgraded relatively recently, it is less likely to attack the license server 24 and succeed. Therefore, as a matter of trust, it is preferable that each license server 24 must be upgraded on a regular basis through an appropriate upgrade promotion mechanism such as a signature validation process. Of course, other upgrade mechanisms can be adopted and do not deviate from the spirit and scope of the invention. [0116] Of course, when changing the private root key (PR-R), the public root key (PU-R) in each DRM system 18 must also be changed. Such changes may be made, for example, during a normal black box 30 upgrade, or may actually require a black box 30 upgrade. The modified public root key (PU-R) could potentially interfere with signature validation for the old license 16 issued under the old private root key (PR-R). Interference can be minimized by requiring the upgraded black box 30 to remember all of the old public root keys (PU-R). Alternatively, to minimize such interference, the signature on License 16 may be verified only once. For example, the license evaluation unit 36 of the DRM system 18 first evaluates such a license 16. In such cases, the state information regarding whether or not the signature has been verified should be compiled and stored in the state store 40 of the DRM system 18.<u style="single">Digital rights license 48</u>In the present invention, the license evaluation unit 36 evaluates the digital rights license (DRL) 48 as a right description or condition of the license 16, and such a DRL 48 is the corresponding piece of the digital content 12 in the required manner. Determine whether to allow rendering. In one embodiment of the invention, any DRL language allows the licensor (ie, the content owner) to write the DRL 48. [0117] As you can see, there are many ways to specify DRL48. Therefore, high flexibility must be tolerated in any DRL language. However, it is impractical to specify all aspects of DRL48 in a particular licensed language, allowing authors of such languages to see all possible aspects of licensing desired by individual digital licensors. That is very unlikely. In addition, very sophisticated licensed languages may not be needed and may be an obstacle for licensors who give a relatively simple DRL48. However, the licensor should not be unnecessarily constrained in how to specify DRL48. At the same time, the License Evaluation Department 36 must always be able to obtain answers from DRL48 for a number of specific licensing issues. [0118] With reference to FIG. 11, in the present invention, the DRL 48 can be specified in any licensed language, but includes a language identifier or tag 54. The license evaluation unit 36 evaluates the license 16 and then performs an interim step of examining the language tag 54 to identify such a language, then selects the appropriate license language engine 52 and of the language thus identified. Access license 16. As will be understood, such a license language engine 52 must be present and accessible to the license evaluation unit 36. If not present, the language tag 54 and / or DRL48 preferably includes a place 56 (typically a website) to obtain such a language engine 52. [0119] Typically, the language engine 52 takes the form of an executable file or a set of files that resides in the memory of the user's computer 14, such as a hard drive. The language engine 52 assists when the license evaluation unit 36 makes a direct inquiry to the DRL 48, and the license evaluation unit 36 indirectly makes an inquiry to the DRL 48 via the language engine 48 or the like acting as an intermediary. When the language engine 52 runs, it runs in the memory workspace of the user's calculator 14, such as RAM. However, the language engine 52 can be used in any other form and does not deviate from the spirit and scope of the invention. [0120] Preferably, both language engines 52 and any DRL language ensure that the license evaluation unit 36 responds to at least a certain number of specific license questions that DRL48 expects to be answered. Therefore, the license evaluation unit 36 is not tied to any particular DRL language. The DRL48 can be written in any suitable DRL language, and the DRL48 specified in the new license language is such a license by having the existing License Evaluation Department 36 acquire the corresponding new language engine 52. It can be adopted by the evaluation unit 36.<u style="single">DRL language</u>Two examples of the DRL language are shown below when they are embodied in each DRL48. The first "simple" DLR48 is written in the DRL language that specifies the license attributes, while the second "script" DRL48 is the DRL language that can perform functions according to the script specified in the DRL48. Written in. When written in the DRL language, the meaning of each line of code should be clear based on its rules of language (linguistics) and / or the attribute description chart that follows. Simple DRL48 [0121] [table 1]<img file="JP4559639B2_D0001.tif" /><img file="JP4559639B2_D0002.tif" /><img file="JP4559639B2_D0003.tif" />[0122] [Table 2]<img file="JP4559639B2_D0004.tif" /><img file="JP4559639B2_D0005.tif" />In the two DRLs specified above, the posted attributes have the following description and data type: [0123] [Table 3]<img file="JP4559639B2_D0006.tif" /><img file="JP4559639B2_D0007.tif" /><u style="single">Method</u>As discussed earlier, the language engine 52 and any DRL language preferably respond to at least a certain number of specific license questions that the Digital License Evaluation Department 36 expects the DRL48 to answer. Recognizing such corresponding questions can include any question without departing from the spirit and scope of the invention and is consistent with the terms used in the two DRL48 examples given above. In one embodiment of the invention, such a corresponding question or "method" includes an "access method", a "DRL method", and a "permission method", such as: Access method The access method is used to query DRL48 for the top-level attribute VARIANT Quary Attribute (BSTR key) Each valid key returns a BSTR variant, License.Name, License.Id, Content.Name, Content.Id, Content.Type, Ower.Name, Owner.Id, Owner.PublicKye, Licensee.Name, Licensee.Id, Licensee.PublicKey, Description, And Terms, as well as Validity.Start and Validity.End, which return Date variants, respectively. DRL method The implementation of the following DRL methods is different for each DRL48. Many DRL methods include a variant parameter called'data', which is intended to communicate more advanced information with DRL48. This is mainly for future extensibility. Boolean Is Activated (variant data) This method returns a Boolean variable that indicates whether DRL48 / License 16 is activated. An example of activated license 16 is limited operation license 16 which is active for 48 hours on first replay. Activate (variant data) This method is used to activate license 16. Once license 16 is activated, it cannot be deactivated. Variant Query DRL This method is used to communicate with the more advanced DRL48. This is mainly related to the future extensibility of the DRL48 feature set. Variant GetExpires (BSTR action, variant data) This method returns the maturity date of license 16 for the submitted action. If the return value is NULL, the license does not yet have a maturity date, for example because it is considered indefinite or has not yet been activated. Variant GetCount (BSTR action, variant data) This method returns the number of remaining actions of the submitted action. If NULL is returned, the operation can be performed an infinite number of times. Boolean IsEnabled (BSTR action, variant data) This method indicates whether license 16 corresponds to the currently required action. Boolean IsSunk (BSTR action, variant data) This method indicates whether or not license 16 has been paid. License 16 that has been paid in advance returns TRUE, while license 16 that has not been paid in advance, such as license 16 that collects fees when used, returns FALSE. [0124] Use permission method These methods are used to grant license 16 used to decrypt the content. Boolean Validate (BSTR key) This method is used to check the validity of license 16. The terminated key is a black box 30 encrypted by the corresponding digital content 12 decryption key (KD) (ie, (KD (PU-BB))) used to validate the signature of license 16. Public key (PU-BB). If the return value is TRUE, it indicates that license 16 is valid. Indicates invalid if the return value is FALSE. int OpenLicense 16 (BSTR action, BSTR key, variant data) This method is used in preparation for accessing the decrypted authorization bits. The finished key is (KD (PU-BB)) as described above. If the return value is 0, it indicates success. Other return values can be defined. BSTR GetDecryptedEnablingBits (BSTR action, variant data) Variant GetDecryptedEnablingBitsAsBinary (BSTR action, variant data) These methods are used to access the decrypted form of the authorization bit. If this is unsuccessful for any of a number of reasons, a null string or null variant is returned. void CloseLicense 16 (BSTR action, variant data) This method is used to de-access the allow bits to perform the finished action. If this is unsuccessful for any of a number of reasons, a null string is returned.<u style="single">Discovery method</u>As discussed earlier, if there are multiple licenses 16 for the same piece of digital content 12, then one of the licenses 16 must be selected and used. Using the methods described above, the following discovery methods can be implemented to make such selections. That is, in order to perform an action (eg, "playback") on a piece of digital content 12, the following steps can be performed. [0125] 1. Obtain all 16 licenses that apply to a specific piece of digital content 12. 2. Remove each license 16 that does not enable the action by calling the IsEnabled function for such license 16. [0126] 3. Remove each inactive license 16 by calling IsActivated for such license 16. 4. Delete each license that has not been paid in advance by calling IsSunk for such license 16. [0127] 5. If any license 16 remains, use it. Before using the unlimited number of views license 16, use the unlimited number of views license, especially if the unlimited number of views license 16 has a maturity date. At any given time, the user is naturally allowed to select a particular license 16 that has already been obtained, even if the selection is not price efficient. Therefore, the user can select license 16 based on criteria that are probably not clear to the DRM system 32. [0128] 6. If there is a license 16 left unattended, return the status indicating it. Then, to the user, If available, use license 16 that has not been paid in advance, Activate License 16 and / or if availablePerform license acquisition from license server 24 , Is given the option.<u style="single">Conclusion</u>The programming required to accomplish the process performed in connection with the present invention should be relatively simple and obvious to those in the relevant programming discipline. Therefore, such programming is not attached here. That is, in order to achieve the present invention, it does not deviate from the spirit and scope of the present invention and can be used in any particular programming. [0129] In the above description, the present invention consists of a novel and useful implementation architecture 10 that allows control of digital content 12 to be rendered or played in any form, such control being flexible. It can be seen that it can be defined by the content owner of such digital content 12. Also, the present invention is novel in that the digital content 12 renders the digital content 12 only as specified by the content owner, even if it renders on a computer 14 that is not under the control of the content owner. Consists of useful rendering environment controls. Moreover, the present invention relates to such digital content 12 even in an attempt by a user of such calculator 14 to access a piece of digital content 12 in a manner not permitted by the content owner. Consists of a trust component that enforces the rights of the content owner on such a calculator 14. [0130] It will be acknowledged that the above embodiments can be modified without departing from the concept of the present invention. Therefore, it is understood that the present invention is not limited to the specific embodiments disclosed, but is intended to include modifications within the spirit and scope of the invention as defined by the appended claims. Yeah. [Simple explanation of drawings] FIG. 1 is a block diagram showing an implementation architecture according to an embodiment of the present invention. FIG. 2 is a block diagram of an authoring tool for the architecture of FIG. 1 according to an embodiment of the present invention. FIG. 3 is a block diagram of a digital content package with digital content for use with the architecture of FIG. 1 according to an embodiment of the invention. FIG. 4 is a block diagram of the user's calculator according to an embodiment of the present invention. FIG. 5A is a flow diagram showing steps performed with the digital rights management (DRM) system of the calculator of FIG. 4 for rendering content according to an embodiment of the invention. FIG. 5B is a flow diagram showing steps performed with the digital rights management (DRM) system of the computer of FIG. 4 for rendering content according to an embodiment of the invention. FIG. 6 is a flow diagram showing steps performed with the DRM system of FIG. 4 to determine if there is any valid authorization license according to an embodiment of the invention. FIG. 7 is a flow diagram showing steps performed with the DRM system of FIG. 4 to obtain a license according to an embodiment of the invention. FIG. 8 is a block diagram of a digital license used with the architecture of FIG. 1 according to an embodiment of the invention. FIG. 9 is a flow diagram showing steps performed with the DRM system of FIG. 4 to obtain a new black box according to an embodiment of the invention. FIG. 10 is a flow diagram illustrating a key transaction step performed with the DRM system of FIG. 4 to validate a license and a piece of digital content according to an embodiment of the invention and render the content. Is. [Fig. 11] It is a block diagram which shows the license evaluation part of FIG. 4, together with the digital rights license (DRL) of the license by one Embodiment of this invention, and the language engine which interprets DRM. FIG. 12 is a block diagram showing a general purpose computer system in which aspects of the present invention and / or a part thereof can be incorporated.
20 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12 Sheet 13 Sheet 14 Sheet 15 Sheet 16 Sheet 17 Sheet 18 Sheet 19 Sheet 20
Every citation, both ways
| Document | Relation | Office |
|---|---|---|
| JP10215242A | Cites | Japan |
| JP10161937A | Cites | Japan |
| JP10063364A | Cites | Japan |
| JP08185444A | Cites | Japan |
| JP09138827A | Cites | Japan |
95 members in 7 offices
Priority claims5
| Document | Office | Kind | Date |
|---|---|---|---|
| 60126614 | United States of America | – | |
| 12661499 | United States of America | P | |
| 09290363 | United States of America | – | |
| 29036399 | United States of America | A | |
| 0004947 | United States of America | W |
Members95
| Document | Office | Kind | |
|---|---|---|---|
| WO0057684A2 | World Intellectual Property Organization (WIPO) | A2 | |
| WO0058810A2 | World Intellectual Property Organization (WIPO) | A2 | |
| WO0058811A2 | World Intellectual Property Organization (WIPO) | A2 | |
| WO0058859A2 | World Intellectual Property Organization (WIPO) | A2 | |
| WO0059150A2 | World Intellectual Property Organization (WIPO) | A2 | |
| WO0059151A2 | World Intellectual Property Organization (WIPO) | A2 | |
| WO0059152A2 | World Intellectual Property Organization (WIPO) | A2 | |
| AU3007800A | Australia | A | |
| AU3380900A | Australia | A | |
| AU3381000A | Australia | A | |
| AU3503900A | Australia | A | |
| AU3608100A | Australia | A | |
| AU3708700A | Australia | A | |
| AU3710100A | Australia | A | |
| WO0152018A1 | World Intellectual Property Organization (WIPO) | A1 | |
| WO0152019A1 | World Intellectual Property Organization (WIPO) | A1 | |
| WO0152020A1 | World Intellectual Property Organization (WIPO) | A1 | |
| WO0152021A1 | World Intellectual Property Organization (WIPO) | A1 | |
| WO0152471A1 | World Intellectual Property Organization (WIPO) | A1 | |
| AU6923200A | Australia | A | |
| AU6927800A | Australia | A | |
| AU6927900A | Australia | A | |
| AU6928000A | Australia | A | |
| AU6928100A | Australia | A | |
| US2002007456A1 | United States of America | A1 | |
| US2002012432A1 | United States of America | A1 | |
| US2002013772A1 | United States of America | A1 | |
| US2002019814A1 | United States of America | A1 | |
| WO0057684A3 | World Intellectual Property Organization (WIPO) | A3 | |
| WO0058811A3 | World Intellectual Property Organization (WIPO) | A3 | |
| WO0058859A3 | World Intellectual Property Organization (WIPO) | A3 | |
| WO0059151A3 | World Intellectual Property Organization (WIPO) | A3 | |
| EP1259863A2 | European Patent Office (EPO) | A2 | |
| EP1271279A2 | European Patent Office (EPO) | A2 | |
| EP1271280A2 | European Patent Office (EPO) | A2 | |
| WO0059150A8 | World Intellectual Property Organization (WIPO) | A8 | |
| CN1393783A | China | A | |
| WO0058810A8 | World Intellectual Property Organization (WIPO) | A8 | |
| WO0059152A3 | World Intellectual Property Organization (WIPO) | A3 | |
| EP1287636A2 | European Patent Office (EPO) | A2 | |
| JP2003101526A | Japan | A | |
| US2003078853A1 | United States of America | A1 | |
| JP2003122636A | Japan | A | |
| JP2003522989A | Japan | A | |
| JP2003536119A | Japan | A | |
| US6772340B1 | United States of America | B1 | |
| US6775655B1 | United States of America | B1 | |
| US6816596B1 | United States of America | B1 | |
| US6829708B1 | United States of America | B1 | |
| US2005066187A1 | United States of America | A1 | |
| US2005086478A1 | United States of America | A1 | |
| US2005091169A1 | United States of America | A1 | |
| US2005091541A1 | United States of America | A1 | |
| US2005097368A1 | United States of America | A1 | |
| US2005192907A1 | United States of America | A1 | |
| EP1271280A3 | European Patent Office (EPO) | A3 | |
| US2005216743A1 | United States of America | A1 | |
| TWI242704B | Taiwan Province of China | B | |
| US6973444B1 | United States of America | B1 | |
| US7016498B2 | United States of America | B2 | |
| US7024393B1 | United States of America | B1 | |
| US7051005B1 | United States of America | B1 | |
| US7073063B2 | United States of America | B2 | |
| US2006167814A1 | United States of America | A1 | |
| US2006167815A1 | United States of America | A1 | |
| US7103574B1 | United States of America | B1 | |
| US2006212363A1 | United States of America | A1 | |
| US7136838B1 | United States of America | B1 | |
| US2006259770A1 | United States of America | A1 | |
| CN1294499C | China | C | |
| US7225333B2 | United States of America | B2 | |
| US2007226492A1 | United States of America | A1 | |
| US7319759B1 | United States of America | B1 | |
| US2008021839A1 | United States of America | A1 | |
| US7353209B1 | United States of America | B1 | |
| US7383205B1 | United States of America | B1 | |
| US7386891B2 | United States of America | B2 | |
| US7412061B2 | United States of America | B2 | |
| US2008195871A1 | United States of America | A1 | |
| US2008244751A1 | United States of America | A1 | |
| JP4226849B2 | Japan | B2 | |
| US7529927B2 | United States of America | B2 | |
| US7624451B2 | United States of America | B2 | |
| JP4406190B2 | Japan | B2 | |
| US2010024044A1 | United States of America | A1 | |
| US7680744B2 | United States of America | B2 | |
| US7716745B2 | United States of America | B2 | |
| EP1271279A3 | European Patent Office (EPO) | A3 | |
| US7757077B2 | United States of America | B2 | |
| JP4559639B2This record | Japan | B2 | |
| JP4668425B2 | Japan | B2 | |
| US8005757B2 | United States of America | B2 | |
| US8065521B2 | United States of America | B2 | |
| US8744969B2 | United States of America | B2 | |
| US9246916B2 | United States of America | B2 |
23 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Cancellation because of no payment of annual feesLAPS | LAPS | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Written notification of registration of transferJAPANESE INTERMEDIATE CODE: R350R350 | R350 | |
| Request for change of ownership or part of ownershipJAPANESE INTERMEDIATE CODE: R313113S111 | S111 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| First payment of annual fees (during grant procedure)JAPANESE INTERMEDIATE CODE: A61A61 | A61 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Decision of grant or rejection writtenTRDD | TRDD | |
| Transfer to examiner for re-examination before appeal (zenchi)AppealJAPANESE INTERMEDIATE CODE: A911A911 | A911 | |
| Written amendmentJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Written amendmentJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Decision of refusalJAPANESE INTERMEDIATE CODE: A02A02 | A02 | |
| Written amendmentJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Written request for application examinationJAPANESE INTERMEDIATE CODE: A621A621 | A621 | |
| Written request for application examinationJAPANESE INTERMEDIATE CODE: A621A621 | A621 | |
| Written amendmentJAPANESE INTERMEDIATE CODE: A523A521 | A521 |
Numbers
- Publication
- 4559639
- Application
- 608539
Titles2
- Japanese
- デジタルデジタル権利管理の実施アーキテクチャおよび方法
- English
- Digital Digital Rights Management Implementation Architecture and Methods
Classification
- CPC, 14
- H04L63/0442
- G06F21/71
- G06F21/84
- G06F2211/007
- G06F2221/2105
- G06F2221/2137
- G06Q30/06
- G06Q30/0601
- H04L63/068
- H04L63/0823
- H04L63/12
- H04L2463/101
- G07F9/002
- G06F21/109
- IPC, 9
- G06Q30 00
- G06F21 00
- G06F1 00
- G06F12 14
- G06F21 24
- G06Q30 06
- H04L9 08
- H04L9 32
- H04L29 06
