System for safe distribution and control of digital work andits control method

Description: TECHNICAL FIELD [Detailed description of the invention]

【0001】

[Technical field to which the invention belongs]

The present invention relates to the fields of distribution of digitally coded works (works, copyrighted works) and enforcement of usage rights.

【0002】

[Problems to be solved by conventional techniques and inventions]

The fundamental problem facing the publishing and information industry, which is considered electronic publishing, is how to prevent unauthorized, uncharged distribution or use of electronically published material (data). .. Electronically published materials are generally distributed in digital form and are recreated in computer-based systems that have the ability to recreate these materials. Audio and video recordings, software, books, and multimedia work are all electronically published. Companies in these industries receive royalties for being responsible for the delivery of materials such as the sale of audio CDs in retail stores. Unpaid distribution of works (generally referred to as works, works, books) results in unpaid royalties (eg copying audio recording CDs to other digital media).

【0003】

The main issue is the simplicity with which electronically published work can be "fully" reproduced and distributed. Transferring digital work across networks is now common sense. One network that is widely used in this way is the Internet. The Internet is a broad network facility where computer users in many universities, businesses, and government agencies communicate and exchange ideas and information. Computer bulletin boards on the Internet and commercial networks, such as CompuServe and Prodigy, allow posting and retrieval of digital information. Dialog and LEXIS / NEXIS Information services such as provide a database of current information for a wide range of topics. Another factor that makes the situation worse is the development and expansion of NII (National Information Infrastructure Development Policy in the United States). As NII grows, it is expected that the transfer of digital work across the network will increase over and over again. Therefore, it is desirable to use NII for the distribution of digital work without the risk of widespread unauthorized copying.

【0004】

The easiest way to curb unpaid rations is to prevent unauthorized copying and transfer. Various safeguards are used for existing materials distributed in digital form. In the case of software, a copy protection method (scheme) has been used that limits the number of copies that can be created or that deteriorates the output when a copy (copy) is detected. The other method disables the software after a predetermined period of time. The technology used for workstation-based software requires that special hardware devices must be present on the workstation in order for the software to run. In this regard, see, for example, US Pat. No. 4,932,054 entitled "Method and MFP for Protecting Computer Software Utilizing Coded Filter Network in conjuntion with an Active Coded Hardware Device". Such devices are generally equipped with software called "dongles".

【0005】

Yet another method is to distribute software that requires a "key" to make the software operational. It is used in distribution schemes where the software "demos" (meaning demonstration) is provided on the medium along with the entire product. Demos are free to use, but keys must be purchased in order to use the actual product. If you buy the key first, these methods do not interfere with the copy of the software.

【0006】

[Means for solving problems]

Systems for controlling the use and distribution of digital work are disclosed. Digital work is any write, audio, graphical, or video-based work, including computer programs that have been converted or created in digital form, and this digital work can be recreated using appropriate rendering means such as software programs. Can be created. The present invention allows the owner of a digital work to attach a usage right to the work. The right to use a digital work defines how the digital work is used and distributed. Digital works and their right to use are stored in a secure repository. Digital work can only be accessed by other secure repositories.

【0007】

Usage rights for digital work are incorporated in a flexible and extensible usage rights grammar. Conceptually, a right in a usage right grammar is a label attached to a given action and condition for exercising the right.

【0008】

The repository includes a storage means for storing the digital work and its attached usage rights, an external interface for receiving and transferring data, a processor, and a clock. The repository has two main modes of operation, server mode and requester mode. When operating in server mode, the repository is responding to requests to access digital work. When operating in requester mode, the repository is requesting access to digital work. In general, the repository processes each request to access a digital work by considering the right to use the work.

【0009】

The repository communicates using a set of repository transactions. A repository transaction incorporates a set of protocols to establish a secure session connection between repositories and to handle access requests to the digital work.

【0010】

The digital work is recreated on the rendering system. The rendering system includes at least one rendering repository and a rendering device (eg, a printer, display or audio system). The rendering system is internally secure.

【0011】

One aspect of the present invention is a system for the secure distribution and control of digital work between repositories, which comprises means of creating usage rights, and each instance of usage rights is how the digital work is used. It indicates a specific instance to be distributed or distributed, has a means to attach the created set of usage rights to digital work, and has a communication medium that connects repositories to enable exchange of repository transaction messages. A storage that stores digital works and has a plurality of general-purpose repositories for safely exchanging the digital work with attached usage rights, and each of the general-purpose repositories stores digital works and their attached usage rights. It has means, an identification certificate to show that the corresponding general-purpose repository is secure, an external interface that detachably binds to the communication medium, and a secure and reliable session with other repositories. It has a session-initiated transaction processing means to be established, and the session-initiating transaction processing means uses an identification certificate and generates a repository transaction message used to request access to digital work stored in another general-purpose repository. A use transaction processing means having a requester operation mode for the use, the use repository transaction message specifies a use right, and the use transaction processing means grants a request for access to a digital work stored in the storage means. The server operation mode for determining whether or not to be performed is further provided, and the request is granted only when the usage right specified in the request is attached to the digital work, and the usage transaction processing means. A system for the secure distribution and control of digital work between repositories, which is coupled to and provides input means for generating used repository transaction messages by user-created signals to request access to the digital work. Is.

【0012】

Another aspect of the invention is a method for controlling the distribution and use of a digital work, comprising: a) attaching a set of usage rights to the digital work, each of which is how the digital work is. Defines a specific instance to be used or distributed, and the usage right is satisfied so that the usage right is exercised and the next set of usage rights is attached to the distributed digital work. It comprises the steps of specifying one or more conditions to be, b) storing the digital work and its attached usage rights in the first repository, c) the second repository in the first repository. It comprises a step of initiating a request to access the digital work, the request identifying a usage right indicating how the second repository wants to use the digital work, d) said first. The repository comprises a step of receiving the request from the second repository, e) the first repository comprises a step of determining whether or not the identified usage right is attached to the digital work, f. ) If the identified usage right is not attached to the digital work, the first repository comprises a step of denying access to the digital work, g) the identified usage right is attached to the digital work. If so, the first repository comprises a step of determining whether or not the conditions specified by the usage rights are met, h) if the conditions are not met, the first repository is said. It comprises a step of denying access to the digital work, i) if the conditions are met, the first repository attaches the next set of usage rights to the digital work, and the next set of usage rights. Provides a step of specifying how the second repository uses and distributes the digital work, j) the first repository provides the next set of the digital work and the attached usage rights. Digital with steps to transfer to said second repositoryDistribution of LeworkAnd a method for controlling usage.

【0013】

BEST MODE FOR CARRYING OUT THE INVENTION

Systems for controlling the use and distribution of digital work are disclosed. The present invention relates to supporting commercial transactions involving digital work.

【0014】

In the present specification, the terms "digital work", "work" and "content" refer to any work (work, work, book, etc.) reduced to digital representation. This includes any audio, video, text or multimedia work, and any accompanying interpreters (eg, software) that may be needed to recreate the work. The term "composite work" refers to a digital work consisting of a set of other digital works. The term "right to use" or "right" is a term that refers to the right granted as a distribution destination of digital work. In general, these rights define how a digital work can be used and whether the digital work can be further distributed. Each use right has one or more designated conditions that must be met before the right can be exercised.

【0015】

FIG. 1 is a high-level flowchart showing the basic operation of the present invention, although various details are omitted. With respect to FIG. 1, in step 101, the creator creates a digital work. In step 102, the creator determines the appropriate usage rights and fees, attaches them to the digital work, and then stores them in Repository 1. The determination of appropriate usage rights and fees depends on various economic factors. The digital work remains secure in Repository 1 until an access request is received. Access requests begin with the start of a session by another repository. At this time, in step 103, the repository 2 starts a session with the repository 1. As described in more detail below, this session initiation includes steps to help ensure that each repository is trusted. Assuming a session can be set up, in step 104, Repository 2 is Digital for the alleged purpose. You can request access to Work (digital work). The purpose may be, for example, to print a digital work or obtain a copy of the digital work. This purpose corresponds to a specific usage right. In any case, in step 105, Repository 1 checks the usage rights corresponding to the digital work to determine if access to the digital work has been granted. The usage right check is essentially a determination of whether the right corresponding to the access request is attached to the digital work and whether all the conditions corresponding to this right are met. Includes. If access is denied, in step 106, Repository 1 terminates the session with an error message. If access is granted, in step 107, Repository 1 transfers the digital work to Repository 2. When the digital work is transferred to the repository 2, in step 108, the repositories 1 and 2 generate billing information for each access, and the billing information is transferred to the credit server. Such double billing reports are made to protect against attempts to fraudulently deceive billing.

【0016】

FIG. 2 shows the basic dialogue between repository types in the present invention. As is clear from Figure 2, different repository types provide different functionality. Basically, the repository shares a core set of functions that enable secure and reliable communication. With respect to Figure 2, repository 201 shows a typical instance of the repository. The repository 201 has two operation modes, a server mode and a requester mode. When in server mode, the repository receives and processes access requests to digital work. When in requester mode, the repository initiates a request to access the digital work. Repository 201 is common in that its main purpose is as an exchange medium for digital work. In the process of operation, the repository 201 may communicate with a plurality of other repositories, namely the authorization repository 202, the rendering repository 203 and the master repository 204. Communication between repositories is performed using the repository transaction protocol 205.

【0017】

Communication with the authorization repository 202 takes place when the digital work being accessed has conditions that require authorization. Conceptually, authorization is a digital certificate, and possession of this certificate is required to gain access to digital work. Authorization is the digital work itself that can be moved between repositories and is subject to fees and usage rights. Authorization may be required by both repositories involved in accessing digital work.

【0018】

Communication with the rendering repository 203 is for rendering digital work. As described in detail below, the rendering repository is linked to a rendering device that has a rendering system (eg, a printer device).

【0019】

Communication with the master repository 205 is made with respect to obtaining an identification certificate. Identification certificates are a means by which a repository is identified as "trusted." The use of identity certificates is described below for registration transactions.

【0020】

FIG. 3 shows repository 201 linked to credit server 301. The credit server 301 is a device that accumulates billing information for the repository 201. The credit server 301 communicates with the repository 201 via the billing transaction 302 to record the billing transaction. Billing transactions are periodically reported by the credit server to the billing clearinghouse (intelligence agency) 303. The credit server 301 communicates with the billing clearinghouse 303 via clearinghouse transaction 304. Clearinghouse transaction 304 allows secure transfer of information to billing clearinghouse 303, i.e. encrypted transfer.

【0021】

A rendering system is generally defined as a system with a repository and a rendering device capable of rendering digital work in the desired format. Examples of rendering systems may be computer systems, digital audio systems, or printers. The rendering system has the same security characteristics as the repository. The connection of the rendering repository with the rendering device may be performed in a manner suitable for the type of rendering device.

【0022】

FIG. 4 (a) shows a printer as an example of a rendering system. With respect to FIG. 4, the printer system 401 includes the printer repository 402 and the printer device 403. The dash line that defines the printer system 401 defines the security system boundary. Communication with the perimeter is assumed to be secure. Depending on the security level, the perimeter also indicates a barrier intended to provide physical integrity. The printer repository 402 is an instantiation of the rendering repository 205 of FIG. The printer repository 402 also contains, in some instances, a single-cut copy of the digital work that remains until printed out by the printer engine 403. In other instances, the printer repository 402 contains digital work such as fonts that can remain or be billed based on usage. This design ensures that the entire line of communication between the printer and the printer is encrypted if it is not within a physically secure boundary. This form of design eliminates potential "fault" points that could result in fraudulent digital work. Printer device 403 indicates a printer component used to produce a printed output.

【0023】

Repository 404 is also shown in (a) of Figure 4. The repository 404 is linked to the printer repository 402. The repository 404 indicates an external repository containing digital work.

【0024】

FIG. 4B is an example of a computer system as a rendering system. Computer systems execute digital work (eg, software programs) ) And display digital work (eg, digitized photographs), so it may be equipped with a "multi-function" device. Logically, each rendering device appears to have its own repository, even though it requires only one physical repository. With respect to (b) of FIG. 4, the computer system 410 includes a display / execution repository 411. The display / execution repository 411 is linked to the display device 412 and the execution device 413. The dash line box surrounding the computer system 410 indicates a security boundary on which communication is assumed to be secure. The display / execution repository 411 is further linked to a credit server 414 to notify the charges charged for access to the digital work and a repository 415 to access the stored digital work. ..

【0025】

The right of use is directly attached to the digital work. Therefore, it is important to understand the structure of digital work. In a special composite digital work, the structure of the digital work is naturally organized so as to be a non-circular structure such as a hierarchy. Magazines, for example, carry a variety of articles and photographs that may have been created and owned by different people. Each of these articles and photos can show nodes in a hierarchical structure. As a result, control, or usage rights, may be placed on each node by the creator. By allowing control and billing to be associated with each node, the creator of the work can ensure that rights and fees are not fraudulently deceived.

【0026】

In the embodiment of the present invention, the file information for the digital work is divided into two files, a "contents" file and a "description tree" file. Seen from the repository, a "contents" file is a stream of addressable bytes whose format depends entirely on the interpreter used to play, display, or print the digital work. The "description tree" file makes it possible to consider the rights and fees for the work regardless of the contents of the digital work. The term "description tree" as used herein refers to any type of non-circular structure used to indicate the relationships between the various components of a digital work.

【0027】

Figure 5 shows the layout of the content file. With respect to FIG. 5, the digital work 509 comprises story A: 510, advertisement 511, story B: 512, and story C: 513. Digital work is assumed to be stored starting at relative address 0. Each part of the digital work is stored linearly, so that story A: 510 is stored roughly at addresses 0 to 30,000, advertisement 511 is stored at addresses 30,001 to 40,000, story B :. 512 is stored at addresses 40,001 to 60,000, and story C: 513 is stored at addresses 60,001 to 90,000. Details of Story A: 510 are shown in Figure 6. As for Figure 6, Story A510 is further subdivided into roughly text 614 stored at addresses 0-1500, brick-like photo 615 stored at addresses 1501-10,000, It shows the graphics 616 stored at addresses 10,000 to 25,000 and the sidebar 617 stored at addresses 25,001 to 30,000. The data in the content file may be compressed (for storage) or encrypted (for security).

【0028】

It is easily observed that digital work can be represented by its component parts as a hierarchy. The description tree for digital work contains a set of associated descriptor blocks (d-blocks). The contents of each d-block are described with respect to FIG. With respect to FIG. 7, the d-block 700 contains the identifier 701, which is the only identifier for the work in the repository, the start address 702, which provides the start address of the first byte of the work, and the number of bytes in the work. The length to be granted 703, the licensed usage right and the right part 704 that holds their state data, the parent pointer 705 that points to the parent d-block, and the child pointer 706 that points to the child d-block. Includes. In a preferred embodiment, the identifier 701 has two parts. The first part is the only number assigned to the repository at manufacturing time. The second part is the only number assigned to the work at creation time. The rights portion 704 includes a look-up table-like data structure that holds various information corresponding to the rights. The information required by each license is described in more detail below. d-blocks form a strict hierarchy. The d-block at the top of the work has no parent, and all other d-blocks have one parent. The relationship of usage rights between parent and child d-blocks and how to resolve conflicts are explained below.

【0029】

A special type of d-block is a "shell" d-block. Shell d-blocks do not add new content other than that part of the content. Shell d-blocks are commonly used by digital work distributors to add rights and fee information.

【0030】

FIG. 8 shows a description tree for the digital work of FIG. With respect to Figure 8, the top d-block 820 for digital work directs the various stories and advertisements contained within. At this point, the top d-block 820 is d-block 821 (representing story A: 510), d-block 822 (representing ad 511), d-block 823 (representing story B: 512), and Point to d-block 824 (representing story C: 513).

【0031】

Figure 9 shows the part of the description tree for story A: 510. d-block 925 represents text 614, d-block 926 represents photo 615, d-block 927 represents graphics 616, and d-block 928 represents sidebar 617.

【0032】

The rights portion 704 of the descriptor block is further shown in FIG. FIG. 10 shows a structure that is repeated in rights portion 704 for each right. With respect to FIG. 10, each right has a right code field 1050 and a status information field 1052. The rights code field 1050 has the only code assigned to the rights. The state information field 1052 contains information about the state of rights and digital work. Such information is shown in Table 1 below. The rights stored within the rights portion 704 may generally be in the order of numbers based on the rights code.

【0033】

[table 1]

<img file="JPH08263441A_D0001.tif" />【0034】

The approach of showing digital work by separating descriptive data from the content assumes that each part of the file is within the same boundaries but is not involved in the actual display of the content. In particular, it is neutral to the question of whether content display takes an object-oriented approach. It is natural to show the content as an object. In principle, it is convenient to have a content object containing the claim structure and the rights information shown within the d-block. Such variations are possible and alternative in the design of the display, but may also introduce processing overhead, such as decoding objects.

【0035】

Digital work is stored in the repository as part of a hierarchical file system. Folders (also called directories and subdirectories) contain other folders along with digital work. The digital works and folders in the folder are arranged in alphabetical order. These digital works are typed to reflect how these files are used. Usage rights can be attached to the folder so that the folder itself is treated as digital work. Access to folders is handled in the same way as any other digital work. The contents of the folders are subject to their own rights, as described in more detail below. It also defines how file management rights can be attached to a folder and the contents of the folder can be managed.

【0036】

It is fundamental to the present invention that the right of use is treated as part of the digital work. When digital work is distributed, the scope of licensed licenses remains unchanged or narrowed. For example, when digital work is transferred from a document server to a repository, usage rights include the right to lend a copy for a period of time (called the original right). When the repository lends a copy of digital work, the lender's right to use the copy (called the following set of rights) can be set to prohibit any additional rights to lend the copy. .. The basic idea is that you cannot grant more rights than they have.

【0037】

Attachment of usage rights to digital work can be done in a variety of ways. If the usage rights are the same for the entire digital work, then when the digital work is processed for a deposit on the digital work server, the usage rights are attached (to the digital work). For digital works that have different usage rights for different components, (attaching usage rights) can be performed during the creation of the digital work. A writing tool or digital work assembly tool that provides an automated process for entitlement attachment may be used.

【0038】

The "next set of rights" may be specified when the digital work is copied, transferred or rented, as described below. This "next set of rights" is attached to the digital work when it is transmitted.

【0039】

Since each part of the digital work may have its own right to use, there are instances where the right to the "contained part" is different from its parent or container part. This requires conflicting rules to be set to specify when and how rights are exercised. The hierarchical structure of digital work facilitates the implementation of such rules. The "strict" rules are as follows: Digital if and only if permitted for that part, the d-block of the ancestor containing that part, and the d-block of all offspring. Rights to that part of the work are granted. The license indicates that (1) each part must have a right and (2) all conditions for exercising that right are met.

【0040】

It is also possible to carry out the present invention with more generous rules. In a more generous rule, access to that part is allowed to work for the part of the offspring who has the right, but is denied to the offspring who do not have the right.

【0041】

Examples of the use of strict and generous rules are shown with respect to Figure 11. With respect to FIG. 11, root d-block 1101 has child d-blocks 1102 to 1105. In this case, the root d-block indicates a magazine, and each of the child d-blocks 1102 to 1105 indicates an article in the magazine. Suppose a request is made to PRINT the digital work indicated by root d-block 1101 according to strict rules. Next, the rights to this root d-block 1101 and child d-blocks 1102 to 1105 are examined. PRINT rights to root d-block 1101 and child d-blocks 1102 and 1105 are granted. The PRINT right of the child d-block 1103 is not granted, but the child d-block 1104 gets the PRINT right on condition that the usage fee is paid.

【0042】

Under strict rules, the PRINT right cannot be exercised because the child d-block does not have the PRINT right (single). Under generous rules, the results will be different. The digital work shown by the child d-blocks 1102 and 1105 can be printed, and the digital work shown by d-block 1104 can be printed if the royalties are paid. Only the digital work indicated by d-block 1103 cannot be printed. If the request is specified for each of the individual digital works, the same result will be achieved under strict rules.

【0043】

The present invention supports various combinations of permissible and non-permissible access. In addition, the usage rights grammar allows the owner of the digital work to specify whether constraints are imposed on the work by the container portion, as described below. The method by which a digital work can be licensed due to usage rights conflicts is a property of practice, and this method depends on the nature of the digital work.

【0044】

The description in Figure 2 shows that repositories take various forms. All repositories provide a core set of services for digital work transfer. The way digital work is exchanged is fundamental to all transactions between repositories. Different repository types differ in the final function they perform. Repositories may themselves be devices or may be embedded in other systems. The rendering repository 203 in FIG. 2 is an example.

【0045】

The repository associates itself with the repository identifier. Generally, the repository identifier is the only number assigned to the repository at the time of manufacture. Each repository is also categorized as being in a special security class. Some communications and transactions are conditional on repositories that are in a special security class. The various security classes are described in detail below.

【0046】

As an integral part of its operation, the repository requires possession of an identity certificate. The identification certificate is encrypted to prevent forgery and is issued by the Master repository. The master repository acts as an authorization agent that allows the repository to receive digital work. The identification certificate must be renewed on a regular basis. The identity certificate is described in more detail below with respect to the registration transaction.

【0047】

The repository has both hardware and functional representation. Functional representation is generally software that is executed in the materialized part of the hardware. Alternatively, the functional representation may be embedded in a hardware embodiment such as an Application Specific Integrated Circuit (ASIC) chip.

【0048】

The hardware embodiment of the repository is surrounded by a security housing that, if agreed, renders the repository inoperable. The basic components of the hardware implementation of the repository are described with reference to Figure 12. With respect to FIG. 12, the repository consists of processing means 1200, storage system 1207, clock 1205 and external interface 1206. The processing means 1200 includes a processor element 1201 and a processor memory 1202. The processing means 1200 provides a controller, a repository transaction, and a license transaction function for this repository. Various operational functions of the repository, such as decryption and / or decompression of digital work and transaction messages, are also performed by the processing means 1200. Processor element 1201 may be a microprocessor or other suitable arithmetic component. The processor memory 1202 generally further includes a ROM (read-only memory) and a RAM (random access memory). Such memory contains software instructions used by processor element 1201 when performing the functions of the repository.

【0049】

The storage system 1207 further includes a descriptor storage device 1203 and a content storage device 1204. The descriptor storage device 1203 stores a description tree for digital work, and the content storage device 1204 stores the corresponding contents. The descriptor storage device 1203 and the content storage device 1204 do not have to be the same type of storage medium, and do not necessarily have to be placed on the same physical device. Here, for example, the descriptor storage device 1203 may be stored on a solid-state storage device (for rapid retrieval of descriptive tree information), while the content storage device 1204 is stored on a high-capacity storage device such as an optical disk. May be placed in.

【0050】

Clock 1205 is used to time stamp various time-based conditions for usage rights or for charging royalties that may be compatible with digital work. The clock 1205 has an uninterrupted power source, such as a battery, to maintain the integrity of the time stamps. External interface means 1206 provides signal connections to other repositories and credit servers. External interface means 1206 provides signal exchange via RS-232 or Personal Computer Manufacturers Card Industry (PCMCIA) standards, or standard interfaces such as FDDI. External interface means 1206 may provide network connectivity.

【0051】

The functional embodiment of the repository is shown in Figure 13. With respect to FIG. 13, functional embodiment includes operating system 1301, core repository service 1302, transaction handler 1303 used, repository identification function 1304, and user interface 1305. Operating system 1301 is specific to the repository and depends on the type of processor commonly used. Operating system 1301 also provides basic services for controlling and interfacing between the basic components of the repository.

【0052】

Core repository service 1302 includes the set of features required by each repository and all repositories. This core repository service 1302 contains a session start transaction as defined in detail below. This set of services includes a generic ticket agent used to "punch" digital tickets and a generic authorization server to process authorization specifications. Digital tickets and authorizations are specific mechanisms for controlling the distribution and use of digital work and are described in more detail below. Note that multiple identification certificates 1306 are linked to the core repository service. Identification certificate 1306 is required to enable the use of the repository.

【0053】

Use Transaction Handler 1303 has the ability to process access requests to digital work and charge based on access. The supported transactions used depend on the repository type. For example, some repositories do not need to handle access requests for digital work.

【0054】

Repository identification function 1304 has the only function for the repository. For example, the master repository has a special function for issuing digital certificates and holding encryption keys. This repository identification function 1304 includes executing a user interface to the repository.

【0055】

For some digital work, the loss caused by every individual instance of an unauthorized copy is not significant, and the main financial concern is to ensure convenience of access and low overhead billing. It is in. In such cases, simple and inexpensive handheld repositories and network-based workstations may be suitable repositories, even if security measures and guarantees are inadequate.

【0056】

Other extreme cases of some digital work, such as just-released movies, securities, or stock securities, are so valuable that they are not copied or counterfeited. It is advisable to take vigilance and fairly careful security measures to ensure that. Repositories suitable for holding such digital work can have elaborate measures to ensure physical integrity and to verify authorization before use.

【0057】

By arranging generic protocols, all kinds of repositories can communicate with each other in principle. However, creators of some works want to specify transfer only to repositories where their work is sufficiently secure. For this reason, document repositories have a ranking system for security classes and levels. The security classes in the preferred embodiments of the present invention are described in Table 2.

【0058】

<img file="JPH08263441A_D0002.tif" /><img file="JPH08263441A_D0003.tif" />【0059】

The security level characteristic display described in Table 2 is not fixed. More important is the idea of having different levels of security for different repositories. It is hoped that new security classes and requirements will evolve in response to changes in social conditions and technology.

【0060】

Repository user interface A user interface is widely defined as a mechanism by which a user interacts with a repository to call or exercise usage rights in a transaction to gain access to digital work. As mentioned above, repositories are incorporated in various formats. The user interface to the repository will vary depending on the particular embodiment. The user interface may be a graphical user interface (GUI) with icons representing digital work and various transactions that can be performed. The user interface may be a generation dialog in which information is prompted by the user.

【0061】

The user interface itself does not have to be part of the repository. If the repository may be embedded within another device, the user interface is only part of the device in which the repository is embedded. For example, a repository can be embedded in a "card" that is inserted into an available slot in a computer system. A user interface is a combination of displays, keyboards, cursor control devices and software running on a computer system.

【0062】

At a minimum, the user interface must allow the user to enter information such as access requests and alphanumeric data and provide feedback on transactional state. The user interface then initiates the appropriate transaction to the repository to maintain the request. Other facets of the special user interface depend on the functionality provided by the repository.

【0063】

In the present invention, the fee is associated with the exercise of the right. The payment requirements are described with each version of the license in the license language. Recording and notification of such charges is done by the credit server. One of the few possibilities made possible by associating fees with rights is the possibility of supporting a wide range of billing models. The simplest model used by traditional software was set at a single price at the time of purchase, after which the purchaser gained unlimited rights to use the work as many times as he or she wanted. It is. Other models include chargeable usage and variable charges. Single workpieces can have different charges for different uses. For example, viewing a photo on a display has a separate charge than making a hard copy or incorporating the hard copy into a newly created work piece. The key to these other billing models is to have a low overhead means of setting charges and calculating charges for these transactions.

【0064】

A credit server is a computing system that reliably authorizes and records these transactions so that they are charged and paid. The credit server notifies the billing clearinghouse of the charges. The billing clearinghouse manages financial transactions as they occur. As a result, an invoice is generated and the fee is settled. Preferably, the credit server stores the toll transaction and periodically communicates with the billing clearinghouse over the network for clearing. In such an embodiment, the communication with the billing clearinghouse is encrypted for integrity and security reasons. In another embodiment, the credit server acts as a "debit card" where transactions occur "in real time" on the user's account.

【0065】

A credit server consists of memory, processing means, clocks, and interface means (eg, a modem) for coupling with repositories and financial institutions. Credit servers also need to have security and authentication capabilities. These elements are essentially the same elements as the elements in the repository. Therefore, assuming that a single device has the appropriate processing elements to perform the corresponding functions and protocols, it can be both a repository and a credit server. Generally, however, credit servers are combined into repositories and interact through financial transactions as described below. Dialogue with the financial institution may be conducted via a protocol set by the financial institution itself. [0066]

In an embodiment of the invention, the credit server, which supports both the server and the repository, notifies the billing clearinghouse (the central authority of information) of the financial transaction. For example, when digital work is copied from one repository to another for its charges, the credit servers associated with each of the repositories notify the billing clearinghouse of this transaction. This is desirable from the perspective of ensuring that transaction charges are calculated even if communication between the credit server and the billing clearinghouse is interrupted. However, in some embodiments, only a single credit server may be incorporated that notifies the transaction to minimize the processing of the transaction when there is a risk of losing some transaction.

【0067】

The present invention uses high-level "use right language" statements to define the rights corresponding to digital work and its parts. The license statement is decrypted by the repository and used to determine which transactions can be successfully performed for a digital work and to determine the parameters for those transactions. For example, a sentence in a language determines whether a given digital work can be copied, when and how it can be used, and how much (if any) it should be charged for its use. To do. When license statements occur, they are coded in the proper format for access during the processing of the transaction.

【0068】

By defining usage rights in a language in combination with a hierarchical representation of digital work, it is possible to support a wide range of distribution and pricing methods (of digital work). One example is the possibility of attaching multiple versions of a right to a work. So creators can attach a PRINT right to make 5 copies for $ 10 and an unlimited PRINT right to make an unlimited number of copies for $ 100. The buyer can then choose which option best suits his needs. Another example is the addition of rights and fees. Here, in the case of a composite work, each right and charge of the component work is used when determining the right and charge for the work as a whole.

【0069】

The basic content of the right is shown in Figure 14. With respect to FIG. 14, rights 1450 has transitional component 1451 and specification component 1452. Right 1450 has a label (eg, COPY or PRINT) indicating the privilege of use or distribution incorporated by the right. The transactional component 1451 corresponds to a special way in which digital work is used or distributed. The transactional component 1451 is generally incorporated within a software instruction in the repository that exercises the privilege of use or distribution of rights. Specification component 1452 is used to specify the conditions that must be met before the right can be exercised or to specify the parameters associated with various transactions. In a preferred embodiment of the invention, these specifications include copy count 1453, fee and reward 1454, time 1455, access and security 1456, and control 1457. Each of these specifications is described in detail below with respect to linguistic grammatical elements.

【0070】

The licensed language is based on the grammar described below. Grammar is a convenient way to define a valid sequence of symbols for a language. When explaining the grammar, the notation [a | b | c] is used to indicate a clear choice from alternatives. In this example, the sentence can have either "a", "b", or "c". The sentence must include exactly one of them. Brace {} is used to indicate a choice. Brackets [], bars and braces are used to describe the language of the usage right sentence, but they do not appear in the actual sentence of the language.

【0071】

In contrast, parentheses () are part of the licensed language. Parentheses are used to group the listed items. Notation (x^*) Is used to indicate a variable length list, that is, a list containing one or more items of type x. Notation (x)^*Is used to indicate a variable list containing x.

【0072】

Keywords in grammar are words with a colon added. Keywords are common in languages and are a very special case. These are sometimes used to indicate a single value, commonly an identifier. In many cases, keywords and parameters are generally optional. Given a keyword, it takes a single identifier as its value. In some cases, the keyword takes a list of identifiers.

【0073】

In licensed languages, time is specified by the hours: minutes: seconds (or hh: mm: ss) representation. A time zone indicator, such as PDT (Pacific Daylight Time), can also be specified. The date is shown as year / month / day (or YYYY / MMM / DD). These time and date representations can specify time, a unit of time. The unit of money is specified by converting it into dollars.

【0074】

In the right-of-use language, various "things" need to interact with each other. For example, an instance of a usage right specifies a bank transaction, a digital ticket, or the like. Such objects need to be identified and are designated using the suffix "-ID" in the present invention.

【0075】

The entire usage right grammar is listed in Figure 15 and is described in detail below.

【0076】

Grammar element 1501 "Digital Work Rights =" (Rights^*) "Defines a digital work right as a set of rights. A set of rights attached to a digital work defines how the digital work is transferred, used, executed or reproduced. The set is attached to the overall digital work, and in the case of composite digital work, to each of the components of the digital work. The rights to use the digital components are different.

【0077】

Grammar element 1502 "Right: = (Right-Code {Copy-Count} {Control-Spec} {Time-Spec} {Access-Spec} {Fee-Spec})" enumerates the content of the right. Each usage right must specify a right code. Each use right can also selectively specify the conditions that must be met before the right can be exercised. These conditions are copy count, control, time, access, and fee conditions. In a preferred embodiment of the invention, the following defaults apply for optional elements. That is, a copy count of 1, no time limit on the use of the right, no access test or security level required to use the right, and no charge. Each of these conditions is described in more detail below.

【0078】

It is important to note that digital work may have multiple rights versions, each with the same rights code. Multiple versions offer alternative terms and fees for accessing digital work.

【0079】

Grammar element 1503 "Right-Code: = Render-Code | Transport-Code | File-Management-Code | Derivative-Works-Code Configuration-Code" is a specific right (although each right is identified by a different right code). Distinguish each of these into special rights types. In this way, the grammar provides a catalog of rights that may correspond to parts of the digital work. In the following, rights are categorized for convenience of describing them.

【0080】

Grammar element 1504 "Render-Code: = Play: {Player: Player-ID} | Print: {Printer: Printer-ID}" makes a temporary, short-lived, or non-digital copy of all digital work. A list of rights categories that include. These copies are erased after use. Play-The process of rendering or executing digital work on several processors. This includes playing digital movies, playing digital music, playing video games, running computer programs, or playing documents on a display. Print-Rendering work to media that is no longer protected by usage rights, such as printing on paper.

【0081】

Grammar element 1505 "Transport-Code: = Copy | Transfer | Loan {Remaining-Rights: Next-Set-of-Rights} {(Next-Copy-Rights: Next-Set of Rights)}" is persistent and A list of rights categories, including making copies of digital work available on other repositories. The optional Next-Copy-Rights determine the rights to the work after it has been transmitted. If this is not specified, the rights of the transmitted copy are the same as the rights of the original. The optional Remaining-Rights specify the rights that remain with the digital work when the copy is lent. If this right is not specified, the default is that the right is not exercised when the copy is rented. -Copy-Make a new copy of the work. -Transfer-Transfer work from one repository to another. -Loan-Lending a copy to another repository for a specified period of time.

【0082】

Syntax element 1506 "File-Management-Code: = Backup {Back-Up-Copy-Rights: Next-Set-of Rights} | Restore | Delete | Folder | Directory {Name: Hide-Local | Hide-Remote} {Parts: Hide-Local | Hide-Remote} "is a list of rights categories that include actions for file management such as backup copies to protect copy owners from catastrophic equipment failure.

【0083】

Numerous software license and copyright laws give copy owners the right to make backup copies to protect them from catastrophic equipment failure. However, making an uncontrolled backup copy is essentially not an ability to control its use, as an uncontrolled backup copy can be saved and restored even after the authorized copy has been sold.

【0084】

File-Management rights allow the creation and restoration of backup copies in a manner that respects usage rights and respects the requirements of both copy owners and rights grantors and income owners. A backup copy of the work description (including usage and fee data) may be sent to another document repository with a high degree of security under appropriate protocol and usage rights control. Further rights allow the organization of digital work into folders. These folders are treated as digital work in their own right, and their contents may be "hidden" from the party trying to determine the contents of the repository. -Backup-Making a backup copy of your digital work as protection against media failures. Restore-Restoring a backup copy of your digital work. -Delete-To delete or delete a copy of a digital work. -Folder-Creating and naming folders and moving files and folders between folders. -Directory-Hiding a folder or its contents.

【0085】

Grammar element 1507 "Derivative-Works-Code: = Extract | Embed | Edit {Process: Process-ID} {Next-Copy-Rights: Next-Set-of-Rights}" is a digital work for creating a new work. A list of rights categories, including the use of. -Extract-Remove the work part for the purpose of creating a new work. -Embed-Incorporating a work into an existing work. Edit-Modifying a digital work by copying, selecting, and modifying parts of an existing digital work.

【0086】

Grammar element 1508 "Configuration-Code: = Install | Uninstall" is a list of categories of rights to install and not install software on a repository (generally a rendering repository). This typically happens for the installation of new types of playback means within the rendering repository. · Install-Installing new software on the repository. · Uninstall-Remove existing software from the repository.

【0087】

Grammar Element 1509 "Next-Set-Of-Rights: = {Add: Set-Of-Rights)} {(Delete: Set-Of-Rights)} {(Replace: Set-Of-Rights} {(Keep: Set-) Of-Rights)} "defines how the right to a copy of a digital work is advanced. If Next-Copy-Rights is not specified, the right to the next copy is the same as the right to the current copy. Otherwise, a set of rights for the next copy may be specified. The version of the rights after Add is added to the current set of rights. The rights after Delete are deleted from the current set of rights. If only rights codes are listed after Delete, all versions of the rights that have these codes will be deleted. The rights version after Replace will be all versions of the same type of rights in the current set of rights. Include.

【0088】

If Remaining-Rights is not specified, there is no right to the original after all loan copies have been lent out. If Remaining-Rights is specified, Keep: tokens can be used to simplify the representation of which rights should be kept behind the scenes. The list of rights codes that follows the keep means means that all of the listed rights versions are retained in the remaining copy. This specification can be overridden by the subsequent Delete: or Replace: specifications.

【0089】

For various transactions, it is desirable to impose some restrictions on the number of "copies" of work that can be exercised simultaneously against the right. For example, it is desirable to limit the number of copies of digital work that can be rented out at one time and viewed at one time.

【0090】

Grammar element 1510 "Copy-Count: =" (Copies: positive-integer | 0 | unlimited) "provides a condition that defines the number of" copies "of a work subject to entitlement. The copy count is zero, fixed, or unlimited. In contrast to the existence of a single copy count for digital work, the copy count corresponds to each right. The Copy-Count for the right is decremented each time the right is exercised. If the Copy-Count for the right is equal to zero, then this right is no longer exercised. If Copy-Count is not specified, the default value is 1.

【0091】

Rights and fees generally depend on the rights granted by the creator and also on the further restrictions imposed by the new distributor. The control specification handles the dialogue between the creators and their distributors who control the imposition of additional restrictions and fees. For example, digital work distributors do not want the ultimate consumer of digital work to use the purchased digital work commercially to raise fees or otherwise profit.

【0092】

Grammar element 1511 "Control-Spec: =" (Control: {Restrictable | Unrestrictable} {Unchargeable | Chargeable}) "provides conditions for specifying the effect of parental usage rights and fees on the exercise of rights. Digital work can be restricted if higher levels of d-blocks can impose additional restrictions on rights (time and access specifications). It cannot be restricted unless further restrictions are imposed. The default settings can be restricted. If no further charges can be levied on the use of the right, the right cannot be claimed. A right can be claimed if a further fee can be levied on the use of the right. This default is billable.

【0093】

It is often desirable to assign a start date or specify a period for when the right is exercised. The grammar element 1512 "Time-Spec: =" ({Fixed-Interval | Sliding-Interval | Meter-Time} Until: Expiration-Date) "provides specifying a time condition for exercising a right. Rights may be granted for a specified period of time. Different types of time specifications are appropriate for different types of rights. Some rights may be exercised for a set period of time. Some rights may be exercised only during the interval starting from the time the rights are called by a transaction. Some rights may be exercised or charged according to certain types of billing time, which billing time may be divided into separate intervals. For example, the right to view a painting for one hour may be divided into six 10-minute views, four 15-minute views, and three 20-minute views.

【0094】

The terms "time" and "date" are used as synonyms to represent time. There are several types of time specifications. Each specification indicates a limit on the amount of time the usage right applies. Expiration-Date specifies the time when the usage right ends. For example, if Expiration-Date is "January 1, 1995", the right ends at the first time of 1995. Expiration-Date^*forever ^*If specified, the right is deciphered as continuing without termination. If only a maturity date is given, that right can be exercised as desired by that maturity date.

【0095】

The grammar element 1513 "Fixed-Interval: = From: Start-Time" is used to define a given interval that runs from start time to maturity date.

【0096】

The grammar element 1514 "Sliding-Interval: = Interval: Use-Duration" is used to define an indefinite (or "open") start time. The element sets a limit on the duration of time that the content is accessible. This period starts at the time of the first access and ends after this period has elapsed or after the maturity date has been reached, whichever comes first. For example, if the right grants 10 hours of continuous access, the period of use begins when the first access is made and ends after 10 hours.

【0097】

The grammar element 1515 "Meter-Time: = Time-Remaining: Remaining-Use" is used to define the "billing time", that is, the measurement of the time the right was actually exercised. This differs from the Sliding-Interval specification in that the time (duration) during use of the digital work does not have to be continuous. For example, if the right guarantees access for three days, these days can be distributed over a month or more. By this specification, these rights are exercised until the billing time is exhausted or the maturity date is reached, whichever comes first.

【0098】

Remaining-Use: = Time-Unit Start-Time: = Time-Unit Use-Duration: = Time-Unit All of the time specifications include time unit specifications in their final instantiation.

【0099】

The present invention provides various security mechanisms introduced into distribution or use schemes. Grammar element 1516 "Access-Spec: = ({SC: Security-Class} {Authorization: Authorization-ID"^*} {Other-Authorization: Authorization-ID^*} {Ticket: Ticket-ID}) provides a means of limiting access and forwarding. The access specification can specify the required security class for the repository or the required authorization test that must be met in order to exercise the right.

【0100】

The keyword "SC:" is used to specify the minimum security level for the repository contained in the access. If "SC:" is not specified, the lowest security level is acceptable.

【0101】

The optional "Authorization" keyword is used to specify the required authorization in the same repository as the work. The optional "Other-Authorization" keyword is used to specify the required authorization for other repositories in a transaction.

【0102】

The optional "Ticket:" keyword specifies the identification of the ticket requested for the transaction. Transactions involving digital tickets must search for a suitable digital ticket agent that can "punch" or validate this ticket before the transaction can proceed. Tickets are described in more detail below.

【0103】

In a transaction involving a repository and a document server, some entitlements require that the repository have a particular authorization, that the server has some authorizations, or that both repositories have (possibly different) authorizations. be able to. The authorization itself is a digital work (hereinafter referred to as an authorization object) that can be moved between repositories like any other digital work. These copies and transfers are subject to the same authorization and fees as any other digital work. A repository is said to have an authorization if this authorization object is contained within this repository.

【0104】

In some cases, authorization may be requested from sources other than the document server and repository. The authorization object referenced by the Authorization-ID can contain digital address information used to set up a communication link between the repository and the authorization source. These are similar to phone numbers. Communication must be set up for such access tests and authorization must be obtained before the rights can be exercised.

【0105】

A variant of this scheme for one-time use rights is to have a digital ticket. The ticket is provided to the digital ticket agent and the type is specified on the ticket. In the simplest case, a guaranteed generic ticket agent available for all repositories is available to "punch" this ticket. In other cases, the ticket may include address information for searching for "special" ticket agents. Once a ticket is punched, it cannot be reused for the same type of transaction (unless it is unpunched, or refreshed, as described below). Punching involves marking a ticket with a time stamp of the date and time the ticket will be used. Tickets are digital works and may be copied or transferred between repositories according to the right to use these digital works.

【0106】

In a preferred embodiment of the invention, a "punched" ticket is "unpunched" or "refreshed" when it is copied or extracted. Copy and Extract operations store the date and time as a characteristic of their digital ticket. When a ticket agent is granted a ticket, the digital agent can simply check if it was copied after the last time it was punched. The digital ticket must, of course, have a copy of it or extract the usage rights attached to that copy.

【0107】

The ability to not punch tickets is important in the following cases: -Digital work is distributed at low cost, limited to one-time use. -Digital work is distributed with a single-use ticket to give a discount on the purchase of other work. -Digital work is distributed by tickets that can be used for future upgrades (included in the purchase price and probably embedded within the work).

【0108】

In each of these cases, if the purchased copy consists of digital work (including tickets), the new owner will be fresh (punched) whether the seller of the copy uses the work or not. Expect to get a ticket (not done). On the other hand, lending work or simply transferring work to another repository is not reusing tickets.

【0109】

Claims for the use of digital work are fundamental to commercial distribution systems. Grammar element 1517 "Fee-Spec: = {Scheduled-Discount} Regular-Fee-Spec | Scheduled-Fee-Spec | Markup-Spec" provides a range of billing options for the use of digital work.

【0110】

A key feature of this method is the development of low overhead billing for potentially small transactions. This makes it easy to collect only a few cents for each of the thousands of transactions.

【0111】

The grammar distinguishes between uses that are billed for each use and those that are charged by the time unit. Transactions can support not only the fees paid by the user to use the digital work, but also the fees paid by the licensor to the user to guide the user to use or distribute the digital work.

【0112】

The optional scheduled discount corresponds to the rest of the pricing specification and discounts the pricing for a given percentage of the time. If not specified, there are no scheduled discounts. The specified rate specifications are constant per hour. The scheduled rate specification gives a schedule for the date on which the rate specification changes. The markup specification is used within the d-block to add a fee to the charges already charged.

【0113】

Grammar element 1518 "Scheduled-Discount: = (Scheduled-Discount: (Time-Spec Percentage)) ^*) ". Scheduled-Discount is essentially a scheduled modifier of other pricing specifications for that version of a digital work right. (This does not correspond to a child or parent digital work or other rights version. ). This is a pair list of hours and percentages. The latest time in the list that has not yet elapsed at the time of the transaction is the time it will be executed. This percentage gives a discounted percentage. For example, the number 10 is 10. Shows a% discount.

【0114】

Syntax element 1519 "Regular-Fee-Spec: = ({Fee: | Incentive:} Per-Use-Spec | Metered-Rate-Spec | Best-Price-Spec | Call-For-Price-Spec {Min: Money-Unit Per: Time-Spec} {Max: Money-Unit Per: Time-Spec} To: Account-ID) "offers several pricing specifications.

【0115】

If Fee: is specified, the fee will be paid by the copy owner / user to the total revenue owner. If Incentive: is specified, the reward will be paid to the user by the income owner. Min: Once a specification is granted, it will indicate the minimum charge charged per time specification for its use. Then, given the Max: specification, the maximum charge per time specification for its use is shown. If Fee: is specified, the Account-ID identifies the account on which the fee will be paid. If Incentive: is specified, the Account-ID identifies the account on which the fee will be paid.

【0116】

Grammar element 1520 "Per-Use-Spec: = Per-Use: Money-Unit" defines a simple fee paid each time a right is exercised, regardless of how long the transaction takes.

【0117】

Grammar element 1521 "Metered-Rate-Spec: = Metered: Money-Unit Per: Time-Spec" defines a billing rate that is paid according to the time the rights are exercised. In this way, the time taken to complete the transaction determines this charge.

【0118】

The grammar element 1522 "Best-Price-Spec: = Best-Price: Money-unit Max: Money-unit" is used to specify the optimal price that will be determined when the invoice is set. This specification includes special deals, rebates, and pricing that rely on information that is not available in the repository. All pricing specifications can be combined with a ticket or authorization that can indicate that the consumer is a wholesaler or a preferred customer, or that the seller is somehow authorized, and so on. Max: The amount in the field is the maximum amount of expense to use. This is the amount tentatively charged to the credit server. However, any excess amount will be returned to the consumer in another transaction when the transaction is finally closed.

【0119】

The grammar element 1523 "Call-For-Price-Spec: = Call-For-Price" is similar to "Best-Price-Spec" in that it is intended to include cases where prices fluctuate. Call-For-Price-Spec requires an exchange of information with the dealer to determine the price. If the repository cannot communicate with the dealer when the right is exercised, this option cannot be exercised. This is based on a secure transaction in which the dealer places a price to exercise the right and passes the proof of transaction, which is referenced or incorporated in the billing process.

【0120】

Grammar element 1524 "Scheduled-Fee-Spec: = (Schedule: (Time-Spec Regular-Fee-Spec)" ^*) Is used to provide a schedule for dates with changing pricing specifications. This rate specification with the latest past date is the rate specification to be implemented. This is more common as it provides a means to change the rate agreement on a period-by-period basis.

【0121】

Grammar element 1525 "Markup-Spec: = Markup: percentage To: Account-ID" is provided to add a fee to the charges already charged. For example, a 5% markup indicates that 5% of the cumulative charges so far will be allocated to the distributor. Markup specifications can be applied to all other types of pricing specifications. The markup specification is commonly used within the shell provided by the distributor. This applies to the charges corresponding to the d-block, which is currently part of the d-block. This is a useful specification for use in taxes or distributor overhead.

【0122】

When a user requests access to digital work, the repository initiates various transactions. The combination of transactions called depends on the specifications assigned to the usage right. There are three basic types of transactions: session start transactions, financial transactions and use transactions. In general, a session start transaction is started first to establish a valid session. When a valid session is set, transactions corresponding to various usage rights are called. Finally, a request specific transactions is executed.

【0123】

Transactions occur between two repositories (one acting as a server), between repositories and document playback platforms (eg for execution and viewing), between repositories and credit servers, or between repositories and authorization servers. .. When a transaction occurs between one or more repositories, it is assumed that there is a trusted communication channel between these repositories. The communication channel may be, for example, a TCP / IP channel or other commercially available channel that has built-in capabilities for detecting and correcting transfer errors. However, it is not assumed that the communication channel is secure. Providing security and privacy is part of the requirements for specifying and executing a repository, which constitutes a need for various transactions.

【0124】

Transactions require that there be some communication between repositories. Communication between repositories occurs in a unit called a message. Since the communication line is assumed to be insecure, communication with all repositories above the lowest security class is encrypted using public key cryptography. Public key encryption is a well-known technique in encryption technology. The term "key" is used in conjunction with encryption and decryption algorithms. The keys appear in pairs, where the "write key" is used to encrypt the data and the "checking key" is used to decrypt the data. Both the write and check keys may be public or private. Public keys are other keys that are distributed. The private key is kept confidential.

【0125】

Key management and security are useful in the success of public key cryptosystems. In a preferred embodiment of the invention, one or more master repositories retain these keys and create an identification certificate used by the repositories.

【0126】

When the shipping repository transfers a message to the receiving repository, the shipping repository encrypts all of its data using the public write key of the receiving repository. The shipping repository contains its own name, the name of the receiving repository, a session identifier such as a nonce (described below), and a message counter for each message.

【0127】

Thus, the communication can only be read (with high probability) by the receiving repository, which holds a checking key private to decryption. Auxiliary data is used to protect security from various replay attacks. If the message arrives with an incorrect counter or old nonceword, the repository can assume that someone has interrupted the communication and the transaction has ended.

【0128】

Each public key for the repository used for encryption is obtained in the registration transaction described below.

【0129】

Use transactions are executed in sessions between repositories. A registration transaction is performed for a use transaction that contains one or more repositories, or for a financial transaction between a repository and a bridge server. A second transaction, called a login transaction, may be required to start a session. Communication channels between repositories are assumed to be reliable but insecure, so there is a risk that non-repositories may mimic protocols to gain illegal access to repositories.

【0130】

The registration transaction between the two repositories is described with respect to Figures 16 and 17. The steps described are from the perspective of "repository-1", which registers the identification in "repository-2". Registration must be symmetric so that the same set of steps is repeated for Repository-2, which has registered its identification in Repository-1. With respect to FIG. 16, in step 1601, Repository-1 first generates an encrypted registration identifier and in step 1602 it generates a registration message. The registration message consists of a master repository identifier, an identification certificate for repository-1, and an encrypted random registration identifier. The identification certificate is encrypted by the master repository with its private key, proving that the repository (here, repository-1) is a real repository. The identity certificate also includes the repository, the repository security level, and the public key for the time stamp (indicating that the certificate is no longer valid after that time). The registration identifier is a number generated by the repository for this registration. The registration identifier is unique to the session and is encrypted with the repository-1's private key. The registration identifier is used to improve the security of authentication by detecting several types of communication-based attacks. Then, in step 1603, Repository-1 forwards the registration message to Repository-2.

【0131】

Upon receiving the registration message, in step 1604, Repository-2 determines whether the message has the required public key in the master repository. At step 1618, the registration transaction ends with an error if Repository-2 does not have the public key required to decrypt the identity certificate.

【0132】

Assuming that Repository-2 has a suitable public key, the identity certificate is decrypted in step 1605. At step 1606, Repository-2 stores the encrypted registration identifier and at step 1607 it extracts the repository identifier. In step 1608, the extracted repository identifier is checked against the "hot list" of the adopted document repository. In a preferred embodiment of the invention, each repository comprises a "hot list" of adopted repositories. If the repository is on the "hot list", at step 1618, the registration transaction ends with an error. Repositories can be removed from the hotlist when their certificates expire, which prevents the list from growing endlessly. In addition, the repository maintains a short list of previously received hotlist certificates, which allows the repository to avoid the task of actually reviewing this list. These lists are encrypted by the master repository. A minor variant for an approach to improving efficiency has a repository that first exchanges a list of hotlist certificate names, resulting in only exchanges of lists that have never been received before. .. The "hot list" is maintained and distributed by the master repository.

【0133】

Note that instead of the transaction ending with an error, the transaction can require other registration messages to be sent based on the identity certificate created by the other master repository. This is repeated until a satisfactory identification certificate is found or until it is determined that trust will not be established.

【0134】

Assuming the repository is not on the hotlist, the repository identification must be verified. In other words, Repository-2 needs to verify that the repository at the other end (of the link) is actually Repository-1. This is called a performance test and is done to prevent invalid access to the repository through a fake repository that plays the record of the previous session start between repository-1 and repository-2. The performance test is initiated by Repository-2, which raises a performance message in step 1609. Performance messages consist of nonce words, the name and time of each repository, and the registration identifier received from repository-1. A nonce is a message generated based on some arbitrary variable information (eg, time or temperature). This nonce allows the repository-1 to actually deploy accurate encryption of the message with a private key that the repository-1 is required to have never seen on the message. Used to check if not. Performance messages are encrypted using the public key specified in the repository-1 registration message. This performance message is transferred to Repository-1 in step 1610 and decrypted by Repository-1 using its private key in step 1611. Repository-1 then checks to see if the names of the two repositories are correct in step 1612, the time is correct in step 1613, and the registration identifier corresponds to the identifier sent by repository-1 in step 1614. Check for. If any of these tests fail, the transaction ends at step 1616. If these tests pass, in step 1615, Repository-1 transfers the nonce to Repository-2 unencrypted. Repository-2 then goes to step 161 In 7, compare the received nonce with the original nonce. If they do not match, at step 1618, the registration transaction ends with an error. If they are the same, the registration transaction ends successfully.

【0135】

At this time, assuming that this transaction did not end, these repositories exchange messages containing the session key used in all communications between sessions and synchronize the clocks. Figure 17 shows the session information exchange and clock synchronization steps (again, from the perspective of Repository-1). For Figure 17, in step 1701, Repository-1 creates a session key pair. The first key is kept private and used by Repository-1 to encrypt the message. The second key is the public key used by Repository-2, which decrypts the message. This second key is encrypted with the repository-2's public key in step 1702 and sent to repository-2 in step 1703. Upon receipt, in step 1704, Repository-2 decrypts the second key. The second key is used to decrypt the message in subsequent communications. When each repository completes this step, both of these repositories confirm that the other repository is genuine and that these repositories are communicating with the original repository. Each repository assigns a key to the other repository that will be used to decrypt further communications during the session. Since this key is itself transferred with the public key of the receiving repository only, it is possible to decrypt the key used to decrypt subsequent messages.

【0136】

After the session information is exchanged, the repository must synchronize these clocks. Clock synchronization is used by the repositories to set up an agreed timebase for the financial records of each other's transactions in these repositories. Returning to FIG. 17, in step 1705, Repository-2 initiates clock synchronization by generating a time stamp exchange message, and in step 1706 forward this message to Repository-1. Upon receipt, Repository-1 generates its own timestamp message in step 1707 and forwards that message back to Repository-2 in step 1708. In step 1709, Repository-2 notes the current time, and in step 1710, it remembers the time received from Repository-1. In step 1711, the current time is compared to the time received from Repository-1. In step 1712, this difference is checked to see if it exceeds a predetermined tolerance (eg, 1 minute). If so, at step 1713, the repository-2 terminates the transaction because the repository-2 may indicate a forgery of the repository. If not exceeded, in step 1714, Repository-2 calculates the adjusted time delta. The adjusted time delta is the difference between the clock time in Repository-2 and the average time from Repository-1 and Repository-2.

【0137】

To achieve higher accuracy, Repository-2 reclaims time up to a certain number of times (eg, 5 times), iterates over the clock synchronization steps, and averages the results.

【0138】

The second session start transaction is the Login transaction. Login transaction is used to check the authenticity of the user requesting the transaction. Login transactions are particularly careful about the authorization of financial transactions charged to credit servers. The Login transaction involves the interaction between the user and the credit server corresponding to the repository in the user interface. The information exchanged here is a login string provided by the repository / credit server to identify itself to the user and a personal identification number (Personal Identification Number) provided by the user to identify itself to the credit server. PIN) (Personal Identification Number). If the user is accessing the credit server in a repository different from the one in which the user interface resides, the exchange of information is encrypted using the public and private keys of each repository.

【0139】

Billing Transaction is about a financial transaction with a credit server. The billing transaction is executed when all other conditions are met and a royalties are required to grant this request. In most cases, billing transactions are well understood in the art. These transactions are between the repository and the credit server, or between the credit server and the billing clearinghouse. That is, the required transaction includes: -Registration and LOGIN transactions for repositories and users to set their authenticity on credit servers. If the repository and credit server run as a single system, these transactions are completely internal transactions. -Registration and LOGIN transactions where the credit server sets the real thing in the billing clearinghouse. -Assign-fee transaction for allocating charges. The information in this transaction includes the transaction identifier, the identity of the repository in the transaction, and a list of claims from that part of the digital work. This information is also included if any anomalies occur in the transaction, such as jamming. -Begin-charge transaction for assigning bills. This transaction is a toll allocation transaction (Assign-fee) except that it is used for billing use. transaction) is almost the same. Note that this transaction includes usage fee information together with the fee allocation transaction. The credit server then serves to run the clock. -End-charge transaction that ends billing for billing use. (In a variant of this approach, the repository exchanges periodic billing information every block of time.) · Report-charges transaction between personal credit server and billing clearinghouse. This transaction is called at least once during the billing period. It is used to pass information about billing. On the balance card, this transaction is used to update balance information and credit limits as needed.

【0140】

All billing transactions are given a transaction ID and are notified to the credit server by both the server and the client. This reduces the possibility of loss of billing information and checks for counterfeiting of the system if one of the parties to the transaction loses the bank card.

【0141】

The request for use may be processed after the session start transaction ends. To simplify the description of the steps taken when processing a usage request, the term "requester" is used to refer to the requester mode repository that initiates the request. The term "server" is used to refer to a repository in server mode and also includes the desired digital work. In many cases, such as a request to print or view work, the requester and server may be on the same device, or the transaction described below may be a completely internal transaction. .. In such instances, some transaction steps, such as registration transactions, need not be performed.

【0142】

There are some common steps that are part of all the semantics of a usage right transaction. These steps are called common transaction steps. There are two steps, an "opening" step and a "closing" step. For simplicity, they are listed in the present invention rather than repeating them in every description of the license transaction.

【0143】

A transaction can point to a digital work that includes part of a digital work, a complete digital work, or another digital work. Although not described in detail herein, a transaction can even direct a folder of multiple digital works. The term "work" is used to indicate any part or set of digital work being accessed.

【0144】

Many of the steps involve determining whether certain conditions are met. Recall that each use right may have one or more conditions that must be met before the right can be exercised. Digital work has parts, and parts have parts. Different parts can have different rights and fees. Therefore, it is necessary to verify that the necessary conditions are satisfied for all the parts included in the transaction. In short, when instructed to check whether a right exists and the conditions for exercising it are met, all such checks are intended to occur for each of the relevant parts of the work. There is.

【0145】

Figure 18 shows the first common opening and closing steps for a transaction. At this point, it is assumed that registration has occurred and the "trusted" session is in place. A general-purpose test is a test for usage rights corresponding to a folder containing work or several folders including a folder at a higher level in the file system hierarchy. These tests address the requirements placed on the work as a result of the work being on a particular repository, as opposed to the work being attached to the work itself. With respect to FIG. 18, in step 1801, before initiating a use transaction, the requester performs any required generic test before the rights corresponding to that transaction are exercised. For example, install, uninstall and delete rights (of the software) may be exercised to require the requester to have an authorization certificate before the rights are exercised. Another example is the requirement that a digital ticket be presented and punched before the digital work is copied to the requester. If any of the generic tests fail, then at step 1802, no transaction is started. Assuming that a usage request is received and the test thus requested is passed, at step 1803 the server generates a transaction identifier used to record or notify the transaction. The server then checks in step 1804 whether the rights corresponding to the requested transaction have been granted to the digital work. If the right to comply with the request is not granted to the digital work, the transaction ends in step 1805. If the requested right is granted to the digital work, the server determines whether various conditions for exercising the right have been met. Time-based conditions are considered in step 1806 Is done. These conditions are checked by reviewing the time specification for the version of the right. If neither condition is met, the transaction ends in step 1805.

【0146】

If the time-based conditions are met, the server checks security and access conditions in step 1807. Such security and access conditions are met in the following cases: 1) The requester is in the specified security class or a higher security class. 2) The server has passed all specified authorization tests. 3) The requester has passed all designated authorization tests and has all required digital tickets. If neither condition is met, the transaction ends in step 1805.

【0147】

Assuming all security and access conditions are met, in step 1808 the server checks the copy count condition. If the copy count is equal to zero, the transaction cannot be completed and the transaction ends in step 1805.

【0148】

Assuming that the copy count is not equal to zero, in step 1809, the server uses the copy for the requested right to equal or equal to the copy count for the requested right (or related part). Check if it is more than that. If the copy in use is greater than or equal to the copy count, this indicates that the usage rights for the version of the transaction have been exhausted. Therefore, in step 1805, the server terminates the transaction. If the copy count is less than the copy used in the transaction, the transaction continues and in step 1810 the copy used is incremented by the number of digital works requested in the transaction.

【0149】

The server then checks in step 1811 if the digital work has "Loan" access rights. The "Loan" access right is a special case because the right may remain even if all copies are lent out. If the digital work has "Loan" access, in step 1812 it is checked to see if all copies have been rented. The number of copies lent is the sum of Copy-Counts for all versions of digital work lending rights. For composite work, the relevant number is a minimum number, such as the sum of each component of the composite work. If all copies have been lent out, the remaining rights are determined in step 1813. The remaining rights are determined from the remaining rights specification from the "Loan" rights version. If there is only one "Loan" right, the decision is simple. The remaining rights are the rights specified in the version of Loan's rights, or Remaining-Rights: None if is not specified. If there are multiple versions of Loan's rights, and if all copies of all versions are lent out, the remaining rights are the minimum set of rights remaining across all versions of Loan's rights (intersection). Taken as. At step 1814, the server determines if the requested set is within the remaining set of rights. If the requested set is not in the remaining set of rights, at step 1805, the server terminates the transaction.

【0150】

If Loan is not a right to use Digital Work, or if not all copies are lent out, or the requested right is within the remaining set of rights, then in step 1815 the terms of the fee for that right are checked. It initiates various financial transactions between the repository and its corresponding credit server. In addition, all charges for the use of digital work will begin. If any financial transaction fails, the transaction ends in step 1805.

【0151】

Note that the order in which the conditions are checked does not have to follow the order in steps 1806-1815.

【0152】

At this point, the rights identification step is now performed and is represented as step 1816. This entitlement step is described in more detail below.

【0153】

A common closing transaction step is performed. Each closing transaction step is executed by the server after the transaction has been successfully completed. Returning to FIG. 18, in step 1817, the copy value used for the requested right is decremented by the number of copies contained in the transaction. Then, if the right has a metered usage fee specification, in step 1818 the server subtracts the elapsed time from the Remaining-Use-Time corresponding to the right to all parts contained in the transaction. Finally, if there is a charge specification corresponding to the right, at step 1819, the server initiates an End-Charge financial transaction to confirm the bill.

【0154】

An important part to consider is the transfer of digital work from the server to the requester. The transfer protocols described herein relate to events that occur after a valid session has been created. The transfer protocol must handle cases of communication interruptions between repositories. Interferences such as noise injection into the communication channel can be detected by integrity checks (eg, parity, checksum, etc.). The integrity check is incorporated into the transmission protocol but is not described in detail herein.

【0155】

The underlying goal of the transfer protocol is to prevent some failure modes such as intentional or accidental disruption of the communication channel. For example, suppose a user draws a card with a credit server at a particular time near the end of a transaction. There should be no unprotected time that would fail to accurately count the copy number of the work for which the repository was created by "drawing a card". In short, after using digital work, there should be no time for the party to break the connection as a means of avoiding payments.

【0156】

If a transaction is disrupted (and failed), both repositories recover the digital work, the accounting for the state of the digital work before the failure, and the module record of the failure itself.

【0157】

FIG. 19 is a state block showing the steps in the process of transferring information during a transaction. Each box shows the state of the repository in either server mode (above the central dotted line 1901) or requester mode (below the dotted line 1901). Solid arrows represent transitions between states. Arrows on the dash line represent message communication between repositories. A dash-line message arrow pointing to a solid transition arrow is interpreted to mean that a transition occurs when the message is received. Unlabeled transition arrows occur unconditionally. Other labels on the state transition arrow describe the conditions that trigger the transition.

【0158】

As for Figure 19, the server is in the 1902 state where a new transaction is first started via start message 1903. This message contains transaction information, including a transaction identifier and a count of blocks of data being transferred. Initially, the requester in the standby state in 1904 executes the data standby state 1905.

【0159】

The server performs data transfer state 1906, transfers data block 1907, and then waits for knowledge state 1908. When the data is received, the requester executes the data receiving state 1909, and when the data block is completely received, it executes the knowledge state 1910 and forwards the Acknowledgement message 1911 to the server.

【0160】

If you send more blocks, the server waits for an Acknowledgement message from the requester. When the Acknowledgement message is received, the server sends the next block to the requester and waits for the acknowledge again. This requester also repeats the same state cycle.

【0161】

If the server detects a communication failure before sending the final block, the server enters a canceled state 1912 where the transaction is cancelled. Similarly, if the requester detects a communication failure before receiving the final block, the requester enters the canceled state 1913.

【0162】

When there are no more blocks to send, the server commits to the transaction and waits for the final Acknowledgement in state 1914. If there is a communication failure before the server receives the final Acknowledgement message, the server still commits to the transaction, but contains a notification about what happened to its credit server in state 1915. This notice serves two purposes. This notice helps to legalize the user's allegations that they have been charged for receiving digital work that has not been fully received. In addition, this helps identify repositories and communication lines with suspicious usage patterns and jamming. The server then executes its completion state 1916.

【0163】

On the requester side, where there are no more blocks to receive, the requester commits to this transaction in state 1917. If the requester detects a communication failure in this state, the requester notifies the credit server of the failure in state 1918, but still commits to the transaction. When a requester commits, it sends an acknowledge message to the server. The server then enters its completion state 1919.

【0164】

The key characteristic is that both the server and the requester cancel the transaction if the transaction is interrupted before all the data blocks are delivered, and commit to the transaction if all the data blocks are delivered. is there.

【0165】

The server may have sent (and committed) all the data blocks, but the requester may not have received them all or may cancel the transaction. In this case, both repositories will probably detect a communication failure and notify the credit server of this repository. This case is probably rare because it depends on the very exact timing of the communication failure. The only result is that users in the requester repository want a refund from the credit service, and the case for this refund is substantiated by notifications from both repositories.

【0166】

To prevent data loss, the server must not delete any transferred digital work until it receives the final acknowledge from the requester. However, you must not use a server or file. A well-known method of dealing with this condition is called "two-phase commit" or two-phase commit.

【0167】

"Two-phase commit" works as follows. The first phase works similarly to the method shown above. The server sends all the data to the requester. Both repositories are marked as uncommitted to the transaction (and the appropriate files). The server sends a ready-to-commit message to the requester. The requester returns the knowledge. The server then commits and sends a commit message to the requester. When the requester receives a commit message, the requester commits to the file.

【0168】

In the event of a communication failure or other crash, the requester must check back with the server to determine the status of the transaction. The server has a final word for this. The requester may have received all the data, but if the requester did not get the final message, the requester has not committed. Once the server commits, it knows that the file has been completely transferred before starting the 2PC cycle, so the server can proceed and delete the file (except for transaction records).

【0169】

There are technically known variants that can be used to achieve the same effect. For example, an additional encryption level can be used when the server transfers work to the client. This client sends the key only after the client has sent the receipt information for the message acknowledge. The client then agrees to pay for the digital work. The point of this transformation is to provide a clear accounting history of the client receiving the work. However, for credible systems, this variant does not bring real gains in accounting capacity due to the addition of cryptographic levels.

【0170】

Transactions for specific usage rights are described below. A Copy Transaction is a request for making one or more independent copies of work with equal or slightly less usage rights. Copying differs from the extraction rights described below in that it points to the entire digital work or the entire folder containing the digital work. The copy operation cannot be used to remove some part of the digital work. -The requester sends a message to the server to start a copy transaction. This message includes the work to be copied, the copyright version used for the transaction, the destination address (location in the folder) information for placing the work, the file data (including size) for the work, and the number of copies requested. Is shown. -The repository performs a common opening transaction step. -The server transfers the requested contents and data to the client according to the transfer protocol. If Next-Set-Of-Rights are provided for a version of the rights, these rights will be transferred as rights to the work. Otherwise, the original rights will be transferred. In all cases, the Copy-Count field for the copy of the digital work being sent is set to the requested number of copies. -The requester records the content, data, and usage rights of the work and memorizes this work. The requester records the date and time the copy was made in the attributes of the digital work. · The repository performs a common closing transaction step.

【0171】

A Transfer transaction is a request to move a copy of a work that has equal or slightly less usage rights to another repository. In contrast to CopyTransaction, this will remove the work copy from the server. -The requester sends a message to the server to start the Transfer transaction. This message indicates the work to be transferred, the version of the transfer right used in the transaction, the destination address information for arranging the work, the file data for this work, and the copy number included. -The repository executes a common opening transaction step. -The server transfers the requested content and data to the requester according to the transfer protocol. If Next-Set-Of-Rights are provided for a version of the rights, these rights will be transferred as rights to the work. Otherwise, the original rights will be transferred. In both cases, the Copy-Count field for the transferred rights is set to the requested number of copies. -The requester records the contents, data, and usage rights of the work and memorizes this work. -The server decrements the copy count by the number of copies included in the transaction. -The repository performs a common closing transaction step. -If the number of copies remaining in the server is currently zero, the digital work will be erased from memory.

【0172】

A Loan transaction is a mechanism for lending a copy of digital work. The maximum duration of this loan is determined by the internal parameters of the digital work. The work will be automatically returned after a specified period. -The requester sends a message to the server to start a Loan transaction. This message indicates the work to be rented, the version of the lending right used in the transaction, the destination address information for arranging the work, the number of copies included, the file data for the work, and the period of lending. The server checks the validity of the requested lending period and terminates with an error if this period is not valid. The loan for the loaned copy cannot exceed the original loan period to the server. -The repository executes a common opening transaction step. -The server transfers the requested content and data to the requester. If Next-Set-Of-Rights are provided, these rights will be transferred as rights to the work. Otherwise, the original rights are renewed to reflect the lending period before being transferred. -The requester records the contents, data, usage rights, and lending period of the work, and memorizes this work. -The server updates the usage right information in digital work to reflect the rented copy number. · The repository performs a common closing transaction step. -The server updates the usage right data for digital work. This excludes the use of this work until it is returned. Users on the requester platform can use the transferred copy of the digital work here. Users accessing the original repository will not be able to use the digital work unless a copy remains. What happens next depends on the order of events in time. Case 1: The loan period time has not been used up yet and the requester returns to the repository. When sending a message (return message) -The return message includes the requester identification and transaction ID. -The server decrements the used copy for the number of returned copies. (If the number of returned digital works is greater than the number actually lent out, it will be treated as an error.) This step can now enable the works on the server for other users. The requester invalidates the copy and removes its contents from memory. The requester terminates all current use and erases the digital work copy from memory. In any case, the work is automatically returned, but it is expected that the requester will return the work earlier than the lending period. One of the reasons for the early return is the existence of a weighing fee that determines the rental cost. Early return can reduce this charge. Case 2: If the loan period time is exhausted and the requester has not yet sent a Return message -The server decrements the copy fields in use by the number of rented digital works. -The requester automatically disables copying of digital work. The requester terminates all current use and erases the digital work copy from memory. Although the work is automatically returned anyway, it is expected that the requester will return the work earlier than the lending period. One of the reasons for early return is the existence of a weighing fee that determines the rental cost. Early return can reduce this charge.

【0173】

A Play Transaction is a request to use the contents of a work. In general, "playing" a work is sending it to a digital work via some kind of transducer, such as a speaker or display device. This requirement suggests that these contents are not intended to be digitally communicated to other systems. For example, these contents are sent to a printer, recorded on digital media, retained after a transaction, or sent to another repository.

【0174】

The term "Play" is natural for examples such as playing music, playing a movie, or playing a video game. A common form of reproduction means that a "player" is used to use digital work. However, the term "reproduction" covers all recording media and recording types. Thus, when a person "plays" a digital work, it means rendering it to read it, or "playing" a computer program means executing it. For digital tickets, the player can also be a digital ticket agent. -The requester sends a message to the server to start a Play Transaction. This message indicates the work to be played, the version of the play right used in the transaction, the identification of the player being used, and the file data for the work. -The server checks the validity of the player identification and the compatibility of this player identification with the player specifications in terms of rights. If these are not met, it ends with an error. The requester performs a common opening transaction step. -The server and requester read and write blocks of data as requested by the player according to the transfer protocol. The requester uses the player to reproduce the contents of the work. When the player is finished, the player and the request Star is to remove the contents from their memory. -The repository performs a common closing transaction step.

【0175】

A Print transaction is a request to obtain the contents of a work in order to render (draw) the contents of the work on a "printer". We use the term "printer" to include the common case of writing on paper with ink. However, the main aspect of "printing" in our use of this term is to make a copy of the digital work outside of the protection of the right of use. Like all rights, this may require a special authorization certificate.

【0176】

Once the digital work is printed, publishers and users are limited by what copyright law is in effect. However, printing moves their contents out of the control of the repository. For example, in the absence of other implementation mechanisms, once a digital work is printed on paper, the digital work can be copied on a regular copier without being disturbed by a repository that collects usage fees. If a printer to a digital desk is allowed, this digital copy is out of the control of the right of use. Creators absolutely do not implicitly agree to such copyright-violating copies, but both creators and users are aware of this. -The requester sends a message to the server to start a print transaction. This message indicates the work to be played, the printer used, the file data for the work, and the required copy number. -The server checks the validity of the printer identification and the compatibility between the printer identification and the printer specifications in terms of rights. If these conditions are not met, it ends with an error. -The repository executes a common opening transaction step. -The server transfers blocks of data according to the transfer protocol. -The requester prints the work contents using a printer. When the printer is shut down, the printer and requester remove these contents from their memory. -The repository performs a common closing transaction step.

【0177】

A Backup transaction is a requirement to make a backup copy of a digital work as protection against media failure. In terms of the contents of the repository, the security backup copy differs from other copies in the following three points. (1) These security backup copies are created under the control of the Backup transaction, not the Copy transaction. (2) These are not counted as legitimate copies. (3) These are not available as legitimate copies. In general, backup copies are encrypted.

【0178】

Backup copies are transferred or copied depending on the rights assigned to them, but the only way to make backup copies useful for their reproduction, printing or embedding is to restore them. That is.

【0179】

The output of the Backup operation is both an encrypted data file that contains the contents and description of the work and a restore file that has an encryption key that restores the encrypted contents. In many cases, encrypted data files have the right to "print" this output to a disk outside the protection system, relying solely on security encryption. Such files can be stored in a physically safe and convenient location. The restored files are kept in the repository. This file is needed to restore the backup copy. This file may have rights for transfer between repositories. -The requester sends a message to the server to start a Backup transaction. This message indicates the work to be backed up, the version of the backup right used in the transaction, the destination address information for placing the backup copy, and the file data for the work. -The repository executes a common opening transaction step. -The server transfers the requested content and data to the requester. If Next-Set-Of-Rights are provided, these rights will be transferred as rights to the work. Otherwise, the server sets a default set of rights for the original backup file. -The requester records the contents, data, and usage rights of the work. It then creates a one-time-use key and encrypts the contents file. It saves the key information in the restore file. -The repository performs a common closing transaction step.

【0180】

In some cases, it is convenient to be able to archive a large number of encrypted content files to protect a magneto-optical storage system or an offline storage device such as magnetic tape. Creating a non-repository archive file is as secure as the encryption process. Such non-repository archive storage is considered a form of "printing" and is controlled by print rights with a particular "archive printer". The archive printer device is programmed to store the encrypted content file (but not the descriptive file) offline so that it can be retrieved.

【0181】

A Restore transaction is a request to convert an encrypted backup copy of a digital work into a usable copy. The restore operation is intended to be used to compensate for media failure due to a disaster. Like all usage rights, restoration rights can include fees including authorization checks and access tests. -The requester sends a message to the server to start the Restore transaction. This message indicates the work to be restored, the version of the restore right used in the transaction, the destination address information for arranging the work, and the file data for the work. The server verifies that the contents file is available (ie, the digital work corresponding to this request is backed up). If the contents file is not available, the transaction ends with an error. -The repository executes a common opening transaction step. -The server searches the restore file for the key. The server decrypts the work content, data, and usage rights. -The server transfers the requested content and data to the requester according to the transfer protocol. If Next-Set-Of-Rights are provided, these rights will be transferred as rights to the work. Otherwise, the server transfers the default set of rights to the original backup file. -The requester memorizes the digital work. -The repository performs a common closing transaction step.

【0182】

A Delete transaction deletes a large number of copies of a digital work or digital work from a repository. In practice, all digital work has the right to delete. The requester sends a message to the server to start the Delete transaction. This message indicates the work to be deleted and the version of the delete right for the transaction. -The repository executes a common opening transaction step. The server deletes the file and erases it from the file system. -The repository performs a common closing transaction step.

【0183】

A Directory transaction is a request for information about folders, digital work, and parts of them. This is almost the same idea as the protection code in a traditional file system like TENEX, except that it is generalized to the access specification of a full-power licensed language.

【0184】

Directory transactions have an important role in passing a description of rights and charges for digital work. When a user wants to exercise a right, the user interface of the user's repository implicitly creates a directory request to determine the version of the right available. Generally, for example, they have different claim choices for exercising their rights and these are provided to the user. As such, many Directory transactions are invisible to the user and are exercised as part of the normal process of exercising all rights. The requester sends a message to the server to start a Directory transaction. This message indicates the file or folder from which the directory request originated and the version of the directory right used for the transaction. -The server verifies that the information to the requester is accessible. Especially in these directory specifications, HIDE-NAME It does not return the name of any file that has the (name hiding) state, nor does it return the part of any folder or file that has HIDE-PARTS (part hiding) in these specifications. If the information is not accessible, the server terminates this transaction with an error. -The repository executes a common opening transaction step. -The server sends the requested data to the requester according to the transfer protocol. The requester stores the data. -The repository performs a common closing transaction step.

【0185】

A Folder transaction is a request to create and rename a folder, or move work between folders. Along with Directory rights, Folder rights control the extent to which a repository's configuration can be accessed or modified by other repositories. -The requester sends a message to the server to start a Folder transaction. This message indicates the folder that is the source of the folder request and the version, behavior, and data of the folder right for the transaction. The action may be one of file creation, renaming, and moving. This data is a required specification for operations such as folder or digital work and name specifications. -The repository executes a common opening transaction step. -The server performs the requested action. For example, create a folder, rename a folder, or move work between folders. · The repository performs a common closing transaction step.

【0186】

An Extract transaction is a request to copy a part of a digital work and create a new work containing it. Extract transactions differ from copies in that some of the digital work can be used to separate it from a d-block or shell in which additional restrictions or fees are placed. The extraction operation differs from the editing operation in that it only embeds the work in the d-block and does not change the contents of the work. Extraction creates a new digital work. -The requester sends a message to the server to start the Extract transaction. This message contains the part of the work to be extracted, the version of the extraction right used in the transaction, the destination address information to place that part as a new work, the file data for the work, and the copy number included. Shown. -The repository executes a common opening transaction step. -The server transfers the requested content and data to the requester according to the transfer protocol. If Next-Set-Of-Rights are provided, these rights will be transferred as rights to the new work. Otherwise, the original rights will be transferred. The Copy-Count field for this right is set to the required number of copies. The requester records the content, data, and usage rights and memorizes this work. The requester records the date and time when a new work was created in the work attributes. -The repository performs a common closing transaction step.

【0187】

An embed transaction is a request to make a digital work part of another digital work or to add a shell or d-block to allow additional charges by the work distributor. The requester sends a message to the server to start an embed transaction. This message indicates the work to be embedded, the version of the embedding right used for the transaction, the destination address information for arranging the part as the work, the file data for the work, and the number of copies included. -The server checks the control specifications for all rights in the part and the destination. If they are incompatible, the server terminates the transaction with an error. -The repository performs a common opening transaction step. -The server transfers the requested content and data to the requester according to the transfer protocol. If Next-Set-Of-Rights are provided, these rights will be transferred as rights to the work. Otherwise, the original rights will be transferred. The Copy-Count field for this right is set to the required number of copies. -The requester records the content, data, and usage rights, and incorporates the work into the destination file. -The repository performs a common closing transaction step.

【0188】

An Edit transaction is a requirement to create a new digital work by copying, selecting, and modifying parts of an existing digital work. This operation can actually change the contents of the digital work. The type of change allowed depends on the process being used. Similar to the extraction operation, the editing operates on parts of the digital work. In contrast to the extraction operation, editing does not affect the rights or position of the work. The type of change allowed is determined by the processor type specification specified in these rights. In a preferred embodiment of the invention, the Edit transaction modifies the work itself and does not create a new work. However, it is a reasonable change to make a new copy of the work. -The requester sends a message to the server to start the Edit transaction. This message indicates the work to be edited, the version of the edit right used for the transaction, the file data for the work (including size), the process-ID for the process, and the number of copies included. The server checks for compatibility with any process-ID specification in the process-ID rights used by the requester. If incompatible, terminate this transaction with an error. -The repository executes a common opening transaction step. The requester uses the process to modify the content of the digital work as desired. (For example, a requester can select a part of a digital work, copy it, concatenate it with other information, or calculate a function based on the information, which is ultimately text, music, or. Equivalent to editing an image (picture) or optionally using other steps useful in creating a derivative (series) work.) -The repository performs a common closing transaction step.

【0189】

Edit transaction is used to cover a wide variety of work. The process of taking any part of a digital work as an input and then modifying this input in some way is the category of the transaction. For example, with respect to text, the process for editing this text requires edit rights. The process of "summarizing" or counting words in a text is also considered an edit. For music files, processing can include pitch or tempo changes, or the addition of echoes, or any other audio effect. For digital video, those who change the image require editing rights. Examples include coloring, scaling, still photo extraction, selecting and combining frames to create a storyboard, image sharpening with signal processing, and more.

【0190】

Some creators may want to protect the certification of their work by limiting the types of processes that are performed (on the work). Without editing rights, no processing is allowed. A processor identifier can be included to specify what kind of process is allowed. If no processor identifier is specified, any processor can be used. For an example of a particular process, the photographer may try to authorize the use of his photographs, but may be reluctant to be colored. The musician may try to authorize the extraction of parts of his work, but may be reluctant to change the tonal characteristics.

【0191】

There are many ways in which an authorization transaction can be defined. In the following, one preferred method is to simply define them for the other transactions we already need for the repository. Thus, while it is often easy to describe "authorization transactions," these transactions actually consist of other transactions that the repository already has.

【0192】

The usage right can specify an authorization-ID that identifies the authorization object (digital work in a standard format file), which must be owned by the repository and processed by that repository. The authorization is granted to the generic authorization (or ticket) server of the repository that initiates the decryption of the authorization.

【0193】

As mentioned earlier, the authorization includes a server identifier, which may be a generic authorization server or other server. When a remote authorization server is requested, the server can include a digital address. The server may further include a digital certificate.

【0194】

When a remote authorization server is required, the authorization process first performs the following steps: -The generic authorization server tries to set up the communication channel. (Authorization fails with an error if the channel is not set up.) -If the channel is set up, the remote repository will perform the registration process. (If registration fails, authorization will fail with an error.) -When registration is completed, the generic authorization server calls a "replay" transaction by the remote repository and supplies the authorization document as a digital work to be reproduced and the remote authorization server (program) as a "player". (If the player is not found or the player has some other error, the authorization ends with an error.) The authorization server then "plays" the authorization. This involves decrypting it using either the public key of the master repository that issued the certificate or the session key from the repository that transferred it. The authorization server runs various tests. These tests vary by authorization server. These include steps such as checking the issuance and validity of authorizations and checking the hotlist of known invalid authorizations. The authorization server can also check the directory on the repository, find someone to send the password, or request that it perform any other transaction, such as playing some other digital work. .. The authorization server may also call some special processes to check for information about location or recent events. A "script" for these steps is contained within the authorization server. If all required steps are completed successfully, the authorization server completes the transaction successfully, signaling that this authorization has been granted.

【0195】

An Install transaction is a request to install digital work as runnable software on a repository. In the general case, the requester repository is a rendering repository and this software is a new kind or new version of the player. In a more general case, the software is copied to the requester repository's file system before the requester repository is installed. -The requester sends an Install message to the server. This message indicates the work to be installed, the version of the installation right to be called, and the file data (including its size) for that work. -The repository executes a common opening transaction step. The requester extracts a copy of the digital certificate for the software. If this certificate is not found, or if the requester is not informed of the master repository for this certificate, the transaction ends with an error. -The requester decrypts the digital work certificate using the public key of the master repository, and records the identification of the supplier and creator, the key for decrypting the software, compatibility information, and the counterfeit check code. (This step authenticates the software.) -The requester decrypts the software using the key from the certificate and calculates the check code on the requester using the unidirectional hash function. If the check code does not code with the forged check code from the certificate, the installation transaction ends with an error. (This step ensures that the contents of the software, including the various scripts, have not been forged.) The requester searches for instructions in the compatibility check script and follows them. If the software is incompatible with the repository, the installation transaction ends with an error. (This step checks platform compatibility.) The requester searches for instructions in the installation script and follows them. If there is an error in this process (eg, insufficient resources), the transaction ends with an error. The installation process is the placement of executable software in a repository that is no longer accessible as work to exercise any usage rights other than running the software as part of the repository behavior when performing other transactions. Please pay attention to. -The repository performs a common closing transaction step.

【0196】

An Uninstall transaction is a request to exclude software from the repository. This step is controlled because uncontrolled or inaccurate exclusion of software from the repository can compromise its behavioral integrity. -The requester sends an Uninstall message to the server. This message indicates the work that will not be installed, the version of the Uninstall right that will be called, and the file data (including its size) for this work. -The repository executes a common opening transaction step. -Extract a copy of the digital certificate for the software. If this certificate is not found, or the requester is not informed of the master repository for this certificate, the transaction ends with an error. -The requester checks if the software has been installed. If the software is not installed, the transaction ends with an error. The requester uses the master requester's public key to decrypt the digital certificate and records the identity of the supplier and creator, the key to decrypt the software, compatibility information, and a counterfeit check code. (This step authenticates the software's certificate, including the script to exclude the software.) -The requester decrypts the software using the key from the certificate and calculates the check code on the requester using the unidirectional hash function. If the check code does not code with the forged check code from the certificate, the installation transaction ends with an error. (This step ensures that the contents of the software, including the various scripts, have not been forged.) -The requester searches for instructions in the uninstallation (exclusion setting) script and follows these instructions. If this process encounters an error (eg, insufficient resources), the transaction ends with an error. -The repository performs a common closing transaction step.

【0197】

[Effect of the invention]

Provided is a system for controlling the use and distribution of digital work that includes computer programs that are converted or created in digital form and that can be recreated using appropriate rendering means.

[Simple explanation of drawings]

[Figure 1]

It is a flowchart which shows the simple instance generation of the operation of the preferred embodiment of this invention.

[Figure 2]

In a preferred embodiment of the invention, it is a block diagram showing various repository types and showing a repository transaction flow between repositories.

[Fig. 3]

FIG. 5 is a block diagram of a repository linked to a credit server in a preferred embodiment of the present invention.

[Fig. 4]

FIG. 4A is a diagram showing an example of a rendering system that can be used in the embodiment of the present invention. FIG. 4B is a diagram showing an example of a rendering system that can be used in the embodiment of the present invention.

[Fig. 5]

It is a figure which shows the content file layout for the digital work which can be used in a preferable embodiment of this invention.

[Fig. 6]

It is a figure which shows the content file layout for each digital work of the digital work of FIG. 5 which can be used in a preferable embodiment of this invention.

[Fig. 7]

It is a figure which shows the component of the description block of the preferable embodiment of this invention.

[Fig. 8]

It is a figure which shows the description tree for the contents file layout of the digital work shown in FIG.

[Fig. 9]

It is a figure which shows the part of the description tree corresponding to each digital work shown in FIG.

[Fig. 10]

It is a figure which shows the layout with respect to the right part of the description block used in embodiment of this invention.

[Fig. 11]

Some d-blocks are descriptive trees with PRINT usage rights, which are used to show "strict" and "generous" rules for resolving usage rights conflicts.

[Fig. 12]

It is a block diagram of the hardware component of the repository used in the preferred embodiment of the present invention.

[Fig. 13]

It is a block diagram of the functional (logical) component of the repository used in the preferred embodiment of the present invention.

[Fig. 14]

It is a block diagram which shows the basic component of the right of use in a preferable embodiment of this invention.

[Fig. 15]

This is a program display example of the usage right grammar of the preferred embodiment of the present invention.

[Fig. 16]

FIG. 5 is a flow chart showing steps of certificate delivery, hotlist checking and performance testing performed in a registration transaction, as performed in a preferred embodiment of the invention.

[Fig. 17]

It is a flowchart which shows the step of session information exchange and clock synchronization which is executed in the preferable embodiment of this invention after each repository in a registration transaction has successfully completed the step shown in FIG.

[Fig. 18]

It is a flowchart which shows the basic flow for the use transaction which includes the common opening and closing steps as executed in the preferred embodiment of this invention.

[Fig. 19]

It is a block diagram of the state of a server and a client repository according to a transmission protocol that is followed when moving a digital work from a server to a client repository, as performed in a preferred embodiment of the invention.

[Explanation of symbols]

201 repository 301 credit server 401 print system 402 Printer repository 403 print device 410 Multi-function system