(19)
`
`(12)
`
`sigma
`
`
`
`European
`Patent Office
`
`lllllllllllllllllllllllll|||||||||||l|||||l||l||||||||||||||l|l|||l|l|||||l
`
`(11)
`
`EP 1 349 045 B1
`
`EUROPEAN PATENT SPECIFICATION
`
`(45) Date of publication and mention
`of the grant of the patent:
`21.05.2008 Bulletin 2008/21
`
`(21) Application number: 03015128.6
`
`(22) Date of filing: 23.11.1995
`
`(51) Int Cl.:
`GOb‘F21/00‘2m-W)
`
`(54) System for controlling the distribution and use of digital works
`
`System zur Steuerung der Verteilung und Benutzung von Digitalwerken
`
`Syst‘eme pour commander la distribution et I’utilisation d’oeuvres numériques
`
`(84) Designated Contracting States:
`DE FR GB
`
`(30) Priority: 23.11.1994 US 344760
`
`(43) Date of publication of application:
`01.10.2003 Bulletin 2003/40
`
`(62) Document number(s) of the earlier application(s) in
`accordance with Art. 76 EPC:
`02028101.0 /1 293 860
`953084225 / 0 715 247
`
`(73) Proprietor: ContentGuard Holdings, Inc.
`Wilmington, DE 19803 (US)
`
`(72) Inventors:
`0 Stefik, Mark, J.
`Woodside,
`California 94062 (US)
`
`0 Pirolli, Peter, L.
`El Cerrito,
`California 94530 (US)
`
`(74) Representative: Griinecker, Kinkeldey,
`Stockmair & Schwanhéusser
`Anwaltssozietét
`
`Leopoldstrasse 4
`80802 Miinchen (DE)
`
`(56) References cited:
`EP-A- 0 538 216
`US-A- 5 260 999
`
`US-A- 4 882 752
`
`0 PERRI'I'I' H H: "Knowbots, Permissions Headers
`and Contract Law" PROCEEDINGS
`TECHNOLOGICAL STRATEGIES FOR
`PROTECTING INTELLECTUAL PROPERTY IN
`THE NETWORKED MULTIMEDIA
`
`ENVIRONMENT, XX, XX, 2 April 1993 (1 993-04-02),
`pages 39-50, XP002233403
`
`
`
`Note: Within nine months of the publication of the mention of the grant of the European patent in the European Patent
`Bulletin, any person may give notice to the European Patent Office of opposition to that patent, in accordance with the
`Implementing Regulations. Notice of opposition shall not be deemed to have been filed until the opposition fee has been
`paid. (Art. 99(1) European Patent Convention).
`
`Printed by Jouve, 75001 PARIS (FR)
`
`ContentGuard Exhibit 2005
`
`ZTE v. ContentGuard
`
`IPR2013-00133
`
`EP1349045B1
`
`

`

`Description
`
`EP 1 349 045 B1
`
`[0001] The present invention relates to the field of distribution and usage rights enforcementfordigitally encoded works.
`[0002] A fundamental issue facing the publishing and information industries as they consider electronic publishing is
`how to prevent the unauthorized and unaccounted distribution or usage of electronically published materials. Electron-
`ically published materials are typically distributed in a digital form and recreated on a computer based system having
`the capability to recreate the materials. Audio and video recordings, software, books and multimedia works are all being
`electronically published. Companies in these industries receive royalties for each accounted for delivery of the materials,
`e.g. the sale of an audio CD at a retail outlet. Any unaccounted distribution of a work results in an unpaid royalty (e.g.
`copying the audio recording CD to another digital medium.)
`[0003] The ease in which electronically published works can be "perfectly" reproduced and distributed is a major
`concern. The transmission of digital works over networks is commonplace. One such widely used network is the Internet.
`The Internet is a widespread networkfacility by which computer users in many universities, corporations and government
`entities communicate and trade ideas and information. Computer bulletin boards found on the Internet and commercial
`networks such as CompuServ and Prodigy allow forthe posting and retrieving of digital information. Information services
`such as Dialog and LEXIS/NEXIS provide databases of current information on a wide variety of topics. Another factor
`which will exacerbate the situation is the development and expansion ofthe National Information Infrastructure (the NH).
`It is anticipated that, as the NII grows, the transmission of digital works over networks will increase many times over. It
`would be desirable to utilize the NII for distribution of digital works without the fear of widespread unauthorized copying.
`[0004] The most straightforward way to curb unaccounted distribution is to prevent unauthorized copying and trans-
`mission. For existing materials that are distributed in digital form, various safeguards are used. In the case of software,
`copy protection schemes which limit the number of copies that can be made orwhich corrupt the output when copying
`is detected have been employed. Another scheme causes software to become disabled after a predetermined period
`of time has lapsed. A technique used for workstation based software is to require that a special hardware device must
`be present on the workstation in order forthe software to run, e.g., see USA-4,932,054 entitled "Method and Apparatus
`for Protecting Computer Software Utilizing Coded Filter Networkin Conjunction with an Active Coded Hardware Device."
`Such devices are provided with the software and are commonly referred to as dongles.
`[0005] Yet another scheme is to distribute software, but which requires a "key" to enable its use. This is employed in
`distribution schemes where "demos" of the software are provided on a medium along with the entire product. The demos
`can be freely used, but in order to use the actual product, the key must be purchased. These schemes do not hinder
`copying of the software once the key is initially purchased.
`[0006] US 5,260,999 discloses a license management system for software products in a computer system. A license
`server administers licenses for licensed products. Programs executing on the user CPUs are applications programs
`which have added to them a unit 19 that functions as a client stub. A call to a license server, which stores licenses for
`licensed products, is made through this stub and returns are received by this stub and passed on to the program. When
`execution of a program begins, a unit 18 is invoked to check on the availability of a license forthis particular node. The
`unit 18 sends a request to the license management program. A return is sent to the user node granting permission to
`continue.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`PERRI'I'I' H H: "Knowbots, Permission Headers and Contract Law" PROCEEDINGS TECHNOLOGICAL
`[0007]
`STRATEGIES FOR PROTECTING INTELLECTUAL PROPERTY IN THE NETWORKED MULTIMEDIA ENVIRON-
`
`45
`
`50
`
`55
`
`MENT, [Online] 30 April 1993, pages 39 to 50, Retrieved from the Internet on 2003-03-04
`<URL:http://www.ifla.org/documents/infopoI/copyright/perh2.txt>, describes a digital library concept of information ob-
`jects distributed throughout an electronic network. The objects reside on servers and can be retrieved remotely by users
`using clientworkstations. The digital library concept envisions retrieval of complete information resources and not merely
`bibliographic information. The digital library concept contemplates three basic architectural elements, a query (also called
`a knowbot), a permissions header attached to each information object, and a procedure for matching the query with the
`permissions header.
`[0008]
`It is therefore the object of the present invention to provide an improved repository for storing and controlling
`the use of digital works.
`[0009] This object is solved by the subject matter of the independent claim 1.
`[0010]
`Preferred embodiments are defined by the dependent claims.
`[0011] A system for controlling the distribution and use of digital works using digital tickets is disclosed. A ticket is an
`indicator that the ticket holder has already paid for or is othenNise entitled to some specified right, product or service. In
`the presentinvention, a "digital ticket" is used to enable the ticket holderto exercise usage rights specifying the requirement
`of the digital ticket. Usage rights are used to define how a digital work may be used or distributed. Specific instances of
`usage rights are used to indicate a particular manner of use or distribution. A usage right may specify a digital ticket
`which must be present before the right may be exercised. For example, a digital ticket may be specified in a Copy right
`of a digital work, so that exercise of the Copy right requires the party that desires a copy of the digital work be in possession
`
`

`

`EP 1 349 045 B1
`
`ofthe necessary digital ticket. After a copy ofthe digital work is successfully sent to the requesting party, the digital ticket
`is "punched" to indicate that a copy of the digital work has been made. When the ticket is "punched" a predetermined
`number of times, it may no longer be used.
`[0012] Digital works are stored in repositories. Repositories enforce the usage rights for digital works. Each repository
`has a "generic ticket agent’ which punches tickets. In some instances only the generic ticket agent is necessary. In other
`instances, punching by a "special ticket agent" residing on another repository may be desired. Punching by a "special
`ticket agent’ enables greater security and control of the digital work. For example, it can help prevent digital ticket forgery.
`Special ticket agents are also useful in situations where an external database needs to be updated or checked.
`[0013]
`A digital ticket is merely an instance of a digital work. Thus, a digital ticket may be distributed among repositories
`in the same fashion as other digital works.
`[0014] A digital ticket may be used in many commercial scenarios such as in the purchase of software and prepaid
`upgrades. A digital ticket may also be used to limit the number of times that a right may be exercised. For example, a
`user may purchase a copy of a digital work, along with the right to make up to 5 Copies. In this case, the Copy right
`would have associated therewith a digital ticket that can be punched up to 5 times. Other such commercial scenarios
`will become apparent from the detailed description.
`[0015] A system and method in accordance with the invention will now be described, by way of example, with reference
`to the accompanying drawings, in which:-
`
`is a flowchart illustrating a simple instantiation of the operation of the currently preferred embodiment of
`Figure 1
`the present invention.
`Figure 2 is a block diagram illustrating the various repository types and the repository transaction flow between them
`in the currently preferred embodiment of the present invention.
`Figure 3 is a block diagram of a repository coupled with a credit server in the currently preferred embodiment of the
`present invention.
`Figures 4a and 4b are examples of rendering systems as may be utilized in the currently preferred embodiment of
`the present invention.
`Figure 5 illustrates a contents file layout for a digital work as may be utilized in the currently preferred embodiment
`of the present invention.
`Figure 6 illustrates a contents file layout for an individual digital work of the digital work of Figure 5 as may be utilized
`in the currently preferred embodiment of the present invention.
`Figure 7 illustrates the components of a description block of the currently preferred embodiment of the present
`invention.
`
`Figure 8 illustrates a description tree for the contents file layout of the digital work illustrated in Figure 5.
`Figure 9 illustrates a portion of a description tree corresponding to the individual digital work illustrated in Figure 6.
`Figure 10 illustrates a layoutforthe rights portion of a description block as may be utilized in the currently preferred
`embodiment of the present invention.
`Figure 11 is a description tree wherein certain d-blocks have PRINT usage rights and is used to illustrate "strict"
`and "lenient" rules for resolving usage rights conflicts.
`Figure 12 is a block diagram of the hardware components of a repository as are utilized in the currently preferred
`embodiment of the present invention.
`Figure 13 is a block diagram of the functional (logical) components of a repository as are utilized in the currently
`preferred embodiment of the present invention.
`Figure 14 is diagram illustrating the basic components of a usage right in the currently preferred embodiment of the
`present invention.
`Figure 15 lists the usage rights grammar of the currently preferred embodiment of the present invention.
`Figure 16 is a flowchart illustrating the steps of certificate delivery, hotlist checking and performance testing as
`performed in a registration transaction as may be performed in the currently preferred embodiment of the present
`invention.
`
`Figure 17 is a flowchart illustrating the steps of session information exchange and clock synchronization as may be
`performed in the currently preferred embodiment of the present invention, after each repository in the registration
`transaction has successfully completed the steps described in Figure 16.
`Figure 18 is a flowchart illustrating the basic flow for a usage transaction, including the common opening and closing
`step, as may be performed in the currently preferred embodiment of the present invention.
`Figure 19 is a state diagram of server and client repositories in accordance with a transport protocol followed when
`moving a digital work from the server to the client repositories, as may be performed in the currently preferred
`embodiment of the present invention.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`

`

`OVERVIEW
`
`EP 1 349 045 B1
`
`[0016] A system for controlling use and distribution of digital works is disclosed. The present invention is directed to
`supporting commercial transactions involving digital works.
`[0017] Herein the terms "digital work", "work" and "content" refer to any work that has been reduced to a digital
`representation. This would include any audio, video, text, or multimedia work and any accompanying interpreter (e.g.
`software) that may be required for recreating the work. The term composite work refers to a digital work comprised of
`a collection of other digital works. The term "usage rights" or "rights" is a term which refers to rights granted to a recipient
`of a digital work. Generally, these rights define how a digital work can be used and if it can be further distributed. Each
`usage right may have one or more specified conditions which must be satisfied before the right may be exercised.
`[0018]
`Figure 1
`is a high level flowchart omitting various details but which demonstrates the basic operation of the
`present invention. Referring to Figure 1, a creator creates a digital work, step 101. The creator will then determine
`appropriate usage rights and fees, attach them to the digital work, and store them in Repository 1, step 102. The
`determination of appropriate usage rights and fees will depend on various economic factors. The digital work remains
`securely in Repository 1 until a request for access is received. The request for access begins with a session initiation
`by another repository. Here a Repository 2 initiates a session with Repository 1, step 103. As will be described in greater
`detail below, this session initiation includes steps which helps to insure that the respective repositories are trustworthy.
`Assuming that a session can be established, Repository 2 may then request access to the Digital Work for a stated
`purpose, step 104. The purpose may be, for example, to print the digital work orto obtain a copy of the digital work. The
`purpose will correspond to a specific usage right.
`in any event, Repository 1 checks the usage rights associated with
`the digital work to determine if the access to the digital work may be granted, step 105. The check of the usage rights
`essentially involves a determination of whether a right associated with the access request has been attached to the
`digital work and if all conditions associated with the right are satisfied. if the access is denied, repository 1 terminates
`the session with an error message, step 106. If access is granted, repository 1 transmits the digital work to repository
`2, step 1 07. Oncethe digital work has been transmittedto repository 2, repository 1 and 2 each generate billing information
`for the access which is transmitted to a credit server, step 108. Such double billing reporting is done to insure against
`attempts to circumvent the billing process.
`[0019]
`Figure 2 illustrates the basic interactions between repository types in the present invention. As will become
`apparent from Figure 2, the various repository types will serve different functions. It is fundamental that repositories will
`share a core set of functionality which will enable secure and trusted communications. Referring to Figure 2, a repository
`201 represents the general instance of a repository. The repository 201 has two modes of operation; a server mode and
`a requester mode. When in the server mode, the repository will be receiving and processing access requests to digital
`works. When in the requester mode, the repository will be initiating requests to access digital works. Repository 201 is
`general in the sense that its primary purpose is as an exchange medium for digital works. During the course of operation,
`the repository 201 may communicate with a plurality of other repositories, namely authorization repository 202, rendering
`repository 203 and master repository 204. Communication between repositories occurs utilizing a repository transaction
`protocol 205.
`[0020] Communication with an authorization repository 202 may occur when a digital work being accessed has a
`condition requiring an authorization. Conceptually, an authorization is a digital certificate such that possession of the
`certificate is required to gain access to the digital work. An authorization is itself a digital workthat can be moved between
`repositories and subjected to fees and usage rights conditions. An authorization may be required by both repositories
`involved in an access to a digital work.
`[0021] Communication with a rendering repository 203 occurs in connection with the rendering of a digital work. As
`will be described in greater detail below, a rendering repository is coupled with a rendering device (e.g. a printer device)
`to comprise a rendering system.
`[0022] Communication with a master repository 205 occurs in connection with obtaining an identification certificate.
`Identification certificates are the means by which a repository is identified as "trustworthy". The use of identification
`certificates is described below with respect to the registration transaction.
`[0023]
`Figure 3 illustrates the repository 201 coupled to a credit server 301. The credit server 301 is a device which
`accumulates billing information for the repository 201 . The credit server 301 communicates with repository 201 via billing
`transactions 302 to record billing transactions. Billing transactions are reported to a billing clearinghouse 303 by the
`credit server 301 on a periodic basis. The credit server 301 communicates to the billing clearinghouse 303 via clearing-
`house transactions 304. The clearinghouse transactions 304 enable a secure and encrypted transmission of information
`to the billing clearinghouse 303.
`
`RENDERING SYSTEMS
`
`[0024] A rendering system is generally defined as a system comprising a repository and a rendering device which can
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`

`

`EP 1 349 045 B1
`
`render a digital work into its desired form. Examples of a rendering system may be a computer system, a digital audio
`system, or a printer. A rendering system has the same security features as a repository. The coupling of a rendering
`repository with the rendering device may occur in a manner suitable for the type of rendering device.
`[0025]
`Figure 4a illustrates a printer as an example of a rendering system. Referring to Figure 4, printer system 401
`has contained therein a printer repository 402 and a print device 403. It should be noted that the the dashed line defining
`printer system 401 defines a secure system boundary. Communications within the boundary are assumed to be secure.
`Depending on the security level, the boundary also represents a barrier intended to provide physical integrity. The printer
`repository 402 is an instantiation of the rendering repository 205 of Figure 2. The printer repository 402 will in some
`instances contain an ephemeral copy of a digital work which remains until it is printed out by the print engine 403.
`In
`other instances, the printer repository 402 may contain digital works such as fonts, which will remain and can be billed
`based on use. This design assures that all communication lines between printers and printing devices are encrypted,
`unless they are within a physically secure boundary. This design feature eliminates a potential "fault" point through which
`the digital work could be improperly obtained. The printer device 403 represents the printer components used to create
`the printed output.
`[0026] Also illustrated in Figure 4a is the repository 404. The repository 404 is coupled to the printer repository 402.
`The repository 404 represents an external repository which contains digital works.
`[0027]
`Figure 4b is an example of a computer system as a rendering system. A computer system may constitute a
`"mufti-function" device since it may execute digital works (e.g. software programs) and display digital works (e.g. a
`digitized photograph). Logically, each rendering device can be viewed as having its own repository, although only one
`physical repository is needed. Referring to Figure 4b, a computer system 410 has contained therein a display/execution
`repository 411. The display/execution repository 411 is coupled to display device, 412 and execution device 413. The
`dashed box surrounding the computer system 410 represents a security boundary within which communications are
`assumed to be secure. The display/execution repository 411 is further coupled to a credit server 414 to report any fees
`to be billed for access to a digital work and a repository 415 for accessing digital works stored therein.
`
`STRUCTURE OF DIGITAL WORKS
`
`[0028] Usage rights are attached directly to digital works. Thus, it is important to understand the structure of a digital
`work. The structure of a digital work, in particular composite digital works, may be naturally organized into an acyclic
`structure such as a hierarchy. For example, a magazine has various articles and photographs which may have been
`created and are owned by different persons. Each ofthe articles and photographs may represent a node in a hierarchical
`structure. Consequently, controls, i.e. usage rights, may be placed on each node by the creator. By enabling control
`and fee billing to be associated with each node, a creator of a work can be assured that the rights and fees are not
`circumvented.
`
`In the currently preferred embodiment, the file information for a digital work is divided into two files: a "contents"
`[0029]
`file and a "description tree’ file. From the perspective of a repository, the "contents" file is a stream of addressable bytes
`whose format depends completely on the interpreter used to play, display or print the digital work. The description tree
`file makes it possible to examine the rights and fees for a work without reference to the content of the digital work.
`It
`should be noted that the term description tree as used herein refers to any type of acyclic structure used to represent
`the relationship between the various components of a digital work.
`[0030]
`Figure 5 illustrates the layout of a contents file. Referring to Figure 5, a digital work is comprised of story A 510,
`advertisement 51 1 , story B 512 and story C 513. It is assumed that the digital work is stored starting at a relative address
`of 0. Each of the parts of the digital work are stored linearly so that story A 510 is stored at approximately addresses
`0-30,000, advertisement 511 at addresses 30,001 -40,000, story B 512 at addresses 40,001 -60,000 and story C 513 at
`addresses 60,001 -85K. The detail of story A 510 is illustrated in Figure 6. Referring to Figure 6, the story A 510 is further
`broken down to show text 614 stored at address 0-1500, soldier photo 615 at addresses 1501-10,000, graphics 616
`stored at addresses 10,001-25,000 and sidebar 617 stored address 25,001-30,000. Note that the data in the contents
`file may be compressed (for saving storage) or encrypted (for security).
`[0031]
`From Figures 5 and 6 it is readily observed that a digital work can be represented by its component parts as
`a hierarchy. The description tree for a digital work is comprised of a set of related descriptor blocks (d-blocks). The
`contents of each d-block is described with respect to Figure 7. Referring to Figure 7, a d-block 700 includes an identifier
`701 which is a unique identifier forthe work in the repository, a starting address 702 providing the start address of the
`first byte of the work, a length 703 giving the number of bytes in the work, a rights portion 704 wherein the granted usage
`rights and their status data are maintained, a parent pointer 705 for pointing to a parent d—block and child pointers 706
`for pointing to the child d-blocks. In the currently preferred embodiment, the identifier 701 has two parts. The first part
`is a unique number assigned to the repository upon manufacture. The second part is a unique number assigned to the
`work upon creation. The rights portion 704 will contain a data structure, such as a look-up table, wherein the various
`information associated with a right is maintained. The information required by the respective usage rights is described
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`

`

`EP 1 349 045 B1
`
`in more detail below. D-blocks form a strict hierarchy. The top d-block of a work has no parent; all other d-blocks have
`one parent. The relationship of usage rights between parent and child d-blocks and how conflicts are resolved is described
`below.
`
`[0032] A special type of d-block is a "shell" d-block. A shell d-block adds no new content beyond the content of its
`parts. A shell d-block is used to add rights and fee information, typically by distributors of digital works.
`[0033]
`Figure 8 illustrates a description tree for the digital work of Figure 5. Referring to Figure 8, a top d-block 820
`for the digital work points to the various stories and advertisements contained therein. Here, the top d-block 820 points
`to d-block 821 (representing story A 510), d-block 822 (representing the advertisement 51 1), d-block 823 (representing
`story B 512) and and d-block 824 (representing story C 513).
`[0034] The portion of the description tree for Story A 510 is illustrated in Figure 9. D-block 925 represents text 614,
`d-block 926 represents photo 615, d-block 927 represents graphics 616 by and d-block 928 represents sidebar 617.
`[0035] The rights portion 704 of a descriptor block is further illustrated in Figure 10. Figure 10 illustrates a structure
`which is repeated in the rights portion 704 for each right. Referring to Figure 10, each right will have a right code field
`1050 and status information field 1052. The right code field 1050 will contain a unique code assigned to a right. The
`status information field 1052 will contain information relating to the state of a right and the digital work. Such information
`is indicated below in Table 1. The rights as stored in the rights portion 704 may typically be in numerical order based
`on the right code.
`
`TABLE 1
`
`Property
`
`Value
`
`Copies -in-Use
`
`Number
`
`Use
`
`A counter of the number of copies of a work that are in use. lncremented when
`another copy is used; decremented when use is completed.
`lndicatorofthe maximum numberoftime-unitsthata document can be loaned out
`
`Loaner-Copy
`
`lndicatorthatthe current work is a loaned out copy of an authorized digital work.
`
`
`
`Document-Descr
`
`String
`
`Indicator of the remaining time of use on a metered document right.
`
`A string containing various identifying information about a document. The exact
`format of this is not specified, but it can include information such as a publisher
`name, author name, ISBN number, and so on.
`
`A handle identifying a revenue ownerfora digital work. This is used for reporting
`usage fees.
`
`Publication-Date
`
`The date that the digital work was published.
`
`History-list
`
`History-Rec
`
`A list of events recording the repostories and dates for operations that copy,
`transfer, backup, or restore a digital work.
`
`DIGITAL WORK STATE INFORMATION
`
`[0036] The approach for representing digtal works by separating description data from content assumes that parts of
`afile are contiguous buttakes no position on the actual representation of content. In particular, it is neutral to the question
`of whether content representation may take an object oriented approach. It would be natural to represent content as
`objects. In principle, it may be convenient to have content objects that include the billing structure and rights information
`that is represented in the d-blocks. Such variations in the design of the representation are possible and are viable
`alternatives but may introduce processing overhead, e.g. the interpretation of the objects.
`[0037] Digital works are stored in a repository as part of a hierarchical file system. Folders (also termed directories
`and sub-directories) contain the digital works as well as other folders. Digital works and folders in a folder are ordered
`in alphabetical order. The digital works are typed to reflect howthe files are used. Usage rights can be attached to folders
`so that the folder itself is treated as a digital work. Access to the folder would then be handled in the same fashion as
`any other digital work As will be described in more detail below, the contents of the folder are subject to their own rights.
`Moreover, file management rights may be attached to the folder which define how folder contents can be managed.
`
`A'ITACHING USAGE RIGHTS TO A DIGITAL WORK
`
`It is fundamental to the present invention that the usage rights are treated as part of the digital work. As the
`[0038]
`digital work is distributed, the scope of the granted usage rights will remain the same or may be narrowed. For example,
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`

`

`EP 1 349 045 B1
`
`when a digital work is transferred from a document serverto a repository, the usage rights may include the right to loan
`a copy for a predetermined period of time (called the original rights). When the repository loans out a copy of the digital
`work, the usage rights in the loaner copy (called the next set of rights) could be set to prohibit any further rights to loan
`out the copy. The basic idea is that one cannot grant more rights than they have.
`[0039] The attachment of usage rights into a digital work may occur in a variety of ways. If the usage rights will be the
`same for an entire digital work, they could be attached when the digital work is processed for deposit in the digital work
`server. In the case of a digital work having different usage rights for the various components, this can be done as the
`digital work is being created. An authoring tool or digital work assembling tool could be utilized which provides for an
`automated process of attaching the usage rights.
`[0040] As will be described below, when a digital work is copied, transferred or loaned, a "next set of rights" can be
`specified. The "next set of rights" will be attached to the digital work as it is transported.
`
`Resolving Conflicting Rights
`
`[0041] Because each part of a digital work may have its own usage rights, there will be instances where the rights of
`a "contained part" are different from its parent or container part. As a result, conflict rules must be established to dictate
`when and how a right may be exercised. The hierarchical structure of a digital work facilitates the enforcement of such
`rules. A "strict" rule would be as follows: a right for a part in a digital work is sanctioned if and only if it is sanctioned for
`the part, for ancestor d-blocks containing the part and for all descendent d-blocks. By sanctioned, it is meant that (1)
`each of the respective parts must have the right, and (2) any conditions for exercising the right are satisfied.
`[0042]
`It also possible to implement the present invention using a more lenient rule. In the more lenient rule, access
`to the part may be enabled to the descendent parts which have the right, but access is denied to the descendents which
`do not.
`
`[0043] An example of applying both the strict rule and lenient is illustrated with reference to Figure 11. Referring to
`Figure 11, arootd-block1101 has child d-blocks1102-1105. In this case, root d-block represents a magazine, and each
`of the child d-blocks1102-1105 represent articles in the magazine. Suppose that a request is made to PRINT the digital
`work represented by rootd-block 1101 wherein the strict rule is followed. The rights for the root d-block 1101 and child
`d-blocks1102-1105 are then examined. Rootd-block 1101 and child d-blocks 1102 and 1 105 have been granted PRINT
`