EP 0 715 245 A1
`
`invention. Referring to Figure 1, a creator creates a digital work, step 101. The creator will then detennine 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 Re-
`pository 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 As-
`suming 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 or to 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 107. Once the digital work has been transmitted to repository 2, repository 1 and 2 each generate billing infor-
`mation 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.
`Figure 2 illustrates the basic interactions between repositorytypes 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 re-
`pository transaction protocol 205.
`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 work that 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.
`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.
`Communication with a master repository 205 occurs in connection with obtaining an identification certificate. lden-
`tification certificates are the means by which a repository is identified as 'trustworthy'. The use of identification certif-
`icates is described below with respect to the registration transaction.
`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
`clearinghouse transactions 304. The clearinghouse transactions 304 enable a secure and encrypted transmission of
`information to the billing clearinghouse 303.
`
`RENDERING SYSTEMS
`
`A rendering system is generally defined as a system comprising a repository and a rendering device which can
`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.
`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
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`Petitioner Apple Inc. — Exhibit 1006, p. 3001
`
`Petitioner Apple Inc. - Exhibit 1006, p. 3001
`
`

`
`EP 0 715 245 A1
`
`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.
`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.
`Figure 4b is an example of a computer system as a rendering system. A computer system may constitute a ‘multi-
`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 repos-
`itory 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 funher coupled to a credit sewer 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
`
`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 of the 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'
`file and a ‘description free‘ 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.
`Figure 5 illustrates the layout of a contents file. Referring to Figure 5, a digital work is comprised of story A 510,
`advertisement 511, 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 funher 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).
`From Figures 5 and 6 it is readily observed that a digital work can be represented by its component pans 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 for the work in the repository, a staning 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 pans. 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 infomtation associated with a right is maintained. The information required by the respective usage rights is
`described 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.
`'
`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.
`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 511), d-block 823 (representing
`story B 512) and and d-block 824 (representing story C 513).
`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.
`
`20
`
`25
`
`30
`
`35
`
`40
`
`Petitioner Apple Inc. — Exhibit 1006, p. 3002
`
`Petitioner Apple Inc. - Exhibit 1006, p. 3002
`
`

`
`EP 0 715 245 A1
`
`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.
`
`
`
`
`
`Property
`
`Value
`
`Copies-in-Use
`
`15
`
`Loan-Period
`
`Time-Units
`
`, TABLE 1
`DIGITAL WORK STATE INFORMATION
`
`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.
`Indicator of the maximum number of time-units that a document can be loaned
`OUI
`
`
`
`
`
`20
`
`25
`
`30
`
`35
`
`40
`
`50
`
`55
`
`Loaner-Copy
`
`Boolean
`
`Indicator that the current work is a loaned out copy of an authorized digital work.
`
`Remaining-Time
`
`Time-Units
`
`Indicator of the remaining time of use on a metered document right.
`
`Document-Descr
`
`Flevenue~Owner
`
`FlO-Descr
`
`Publication-Date
`
`History-list
`
`Date-Descr
`
`History-Flec
`
`
`
`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, lSBN number, and so on.
`
`A handle identifying a revenue ownerfor a digital work. This is used for reporting
`usage lees.
`
`The date that the digital work was published.
`
`A list of events recording the repostories and dates for operations that copy,
`transfer, backup, or restore a digital work.
`
`The approach for representing digtal works by separating description data from content assumes that parts of a
`file are contiguous but takes no position on the actual representation of content. In panicular, 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 ovemead, e.g. the interpretation of the objects.
`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 how the 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.
`
`ATTACHING 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 digital
`work is distributed, the scope of the granted usage rights will remain the same or may be narrowed. For example, when
`a digital work is transferred from a document server to 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.
`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.
`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.
`
`Petitioner Apple Inc. — Exhibit 1006, p. 3003
`
`Petitioner Apple Inc. - Exhibit 1006, p. 3003
`
`

`
`Resolving conflicting Rights
`
`EP 0 715 245 A1
`
`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 pans must have the right, and (2) any conditions for exercising the right are satisfied.
`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.
`
`An example of applying both the strict rule and lenient is illustrated with reference to Figure 11. Referring to Figure
`11, a root d-block 1101 has child d-blocks 1102-1105. In this case, root d—block represents a magazine, and each of
`the child d-blocks 1102-1105 represent articles in the magazine. Suppose that a request is made to PRINT the digital
`work represented by root d-block 1101 wherein the strict rule is followed. The rights for the root d-block 1101 and child
`d-blocks 1102-1105 are then examined. Root d-block 1101 and child d-blocks 1102 and 1105 have been granted PRINT
`rights. Child d-block 1103 has not been granted PRINT rights and child d-block 1104 has PRINT rights conditioned on
`payment of a usage fee.
`Under the strict rule the PRINT right cannot be exercised because the child d-block does not have the PRINT right.
`Under the lenient rule, the result would be different. The digital works represented by child d-blocks 1102 and 1105
`could be printed and the digital work represented by d-block 1104 could be printed so long as the usage fee is paid.
`Only the digital work represented by d-block 1103 could not be printed. This same result would be accomplished under
`the strict rule if the requests were directed to each of the individual digital works.
`The present invention supports various combinations of allowing and disallowing access. Moreover, as will be
`described below, the usage rights grammar permits the owner of a digital work to specify if constraints may be imposed
`on the work by a container part. The manner in which digital works may be sanctioned because of usage rights conflicts
`would be implementation specific and would depend on the nature of the digital works.
`
`REPOSITORIES
`
`In the description of Figure 2, it was indicated that repositories come in various forms. All repositories provide a
`core set of services for the transmission of digital works. The manner in which digital works are exchanged is the basis
`for all transaction between repositories. The various repository types differ in the ultimate functions that they perform.
`Repositories may be devices themselves, or they may be incorporated into other systems. An example is the rendering
`repository 203 of Figure 2.
`A repository will have associated with it a repository identifier. Typically, the repository identifier would be a unique
`number assigned to the repository at the time of manufacture. Each repository will also be classified as being in a
`particular security class. Certain communications and transactions may be conditioned on a repository being in a
`particular security class. The various security classes are described in greater detail below.
`As a prerequisite to operation, a repository will require possession of an identification certificate. Identification
`certificates are encrypted to prevent forgery and are issued by a Master repository. A master repository plays the role
`of an authorization agent to enable repositories to receive digital works. Identification certificates must be updated on
`a periodic basis. Identification certificates are described in greater detail below with respect to the registration trans-
`action.
`
`A repository has both a hardware and functional embodiment. The functional embodiment is typically software
`executing on the hardware embodiment. Alternatively. the functional embodiment may be embedded in the hardware
`embodiment such as an Application Specific Integrated Circuit (ASIC) chip.
`The hardware embodiment of a repository will be enclosed in a secure housing which if compromised, may cause
`the repository to be disabled. The basic components of the hardware embodiment of a repository are described with
`reference to Figure 12. Referring to Figure 12, a repository is comprised of a processing means 1200, storage system
`1207, clock 1205 and external interface 1206. The processing means 1200 is comprised of a processor element 1201
`and processor memory 1202. The processing means 1201 provides controller, repository transaction and usage rights
`transaction functions for the repository. Various functions in the operation of the repository such as decryption and/or
`decompression of digital works and transaction messages are also performed by the processing means 1200. The
`processor element 1201 may be a microprocessor or other suitable computing component. The processor memory
`1202 would typically be further comprised of Read Only Memories (ROM) and Random Access Memories (RAM). Such
`memories would contain the software instructions utilized by the processor element 1201 in performing the functions
`of the repository.
`
`20
`
`25
`
`30
`
`40
`
`50
`
`Petitioner Apple Inc. — Exhibit 1006, p. 3004
`
`Petitioner Apple Inc. - Exhibit 1006, p. 3004
`
`

`
`EP 0 715 245 A1
`
`The storage system 1207 is further comprised of descriptor storage 1203 and content storage 1204. The description
`tree storage 1203 will store the description tree for the digital work and the content storage will store the associated
`content. The description tree storage 1203 and content storage 1204 need not be of the same type of storage medium,
`nor are they necessarily on the same physical device. So for example, the descriptor storage 1203 may be stored on
`a solid state storage (for rapid retrieval of the description tree information), while the content storage 1204 may be on
`a high capacity storage such as an optical disk.
`The clock 1205 is used to time-stamp various time based conditions for usage rights or for metering usage fees
`which may be associated with the digital works. The clock 1205 will have an uninterruptable power supply, eg. a
`battery, in order to maintain the integrity of the time-stamps. The external interface means 1206 provides for the signal
`connection to other repositories and to a credit server. The external interface means 1206 provides for the exchange
`of signals via such standard interfaces such as RS-232 or Personal Computer Manufacturers Card Industry Association
`(PCMCIA) standards, or FDDl. The external interface means 1206 may also provide network connectivity.
`The functional embodiment of a repository is described with reference to Figure 13. Referring to Figure 13, the
`functional embodiment is comprised of an operating system 1301, core repository services 1302, usage transaction
`handlers 1303, repository specific functions, 1304 and a user interface 1305. The operating system 1301 is specific
`to the repository and would typically depend on the type of processor being used. The operating system 1301 would
`also provide the basic services for controlling and interfacing between the basic components of the repository.
`The core repository services 1302 comprise a set of functions required by each and every repository. The core
`repository services 1302 include the session initiation transactions which are defined in greater detail below. This set
`of services also includes a generic ticket agent which is used to "punch' a digital ticket and a generic authorization
`server for processing authorization specifications. Digital tickets and authorizations are specific mechanisms for con-
`trolling the distribution and use of digital works and are described in more detail below. Note that coupled to the core
`repository services are a plurality of identification certificates 1306. The identification certificates 1306 are required to
`enable the use of the repository.
`The usage transactions handlers 1303 comprise functionality for processing access requests to digital works and
`for billing fees based on access. The usage transactions supported will be different for each repository type. For ex-
`ample, it may not be necessary for some repositories to handle access requests for digital works.
`The repository specific functionality 1304 comprises functionality that is unique to a repository. For example, the
`master repository has special functionality for issuing digital certificates and maintaining encryption keys. The repository
`specific functionality 1304 would include the user interface implementation for the repository.
`
`Repository Security Classes
`
`For some digital works the losses caused by any individual instance of unauthorized copying is insignificant and
`the chief economic concern lies in assuring the convenience of access and low-overhead billing. in such cases, simple
`and inexpensive handheld repositories and network-based workstations may be suitable repositories, even though the
`measures and guarantees of security are modest.
`At the other extreme, some digital works such as a digital copy of a first run movie or a bearer bond or stock
`certificate would be of very high value so that it is prudent to employ caution and fairly elaborate security measures to
`ensure that they are not copied or forged. A repository suitable for holding such a digital work could have elaborate
`measures for ensuring physical integrity and for verifying authorization before use.
`By arranging a universal protocol, all kinds of repositories can communicate with each other in principle. However,
`creators of some works will want to specify that their works will only be transferred to repositories whose level of security
`is high enough. For this reason, document repositories have a ranking system for classes and levels of security. The
`security classes in the currently preferred embodiment are described in Table 2.
`
`TABLE 2
`
`REPOSITORY SECURITY LEVELS
`
`Description of Security
`
`on removable storage.
`
`Open system. Document transmission is unencrypted. No digital certificate is required for identification.
`The security of the system depends mostly on user honesty, since only modest knowledge may be needed
`to circumvent the security measures. The repository has no provisions for preventing unauthorized
`programs from running and accessing or copying files. The system does not prevent the use of removable
`storage and does not encrypt stored files.
`
`Minimal security. Like the previous class except that stored files are minimally encrypted, including ones
`
`10
`
`20
`
`25
`
`30
`
`35
`
`40
`
`50
`
`55
`
`Petitioner Apple Inc. — Exhibit 1006, p. 3005
`
`Petitioner Apple Inc. - Exhibit 1006, p. 3005
`
`

`
`
`
`EP 0 715 245 A1
`
`TABLE 2 (continued)
`REPOSITORY SECURITY LEVELS
`
`Description of Security
`
`Level
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Basic security. Like the previous class except that special tools and knowledge are required to
`compromise the programming, the contents of the repository, or the state of the clock. All digital
`
`communications are encrypted. A digital certificate is provided as identification. Medium level encryption
`
`is used. Repository identification number is unforgeable.
`
`General security. Like the previous class plus the requirement of special tools are needed to compromise
`
`the physical integrity of the repository and that modest encryption is used on all transmissions. Password
`protection is required to use the local user interface. The digital clock system cannot be reset without
`authorization. No works would be stored on removable storage. When executing works as programs, it
`runs them in their own address space and does not give them direct access to any file storage or other
`memory containing system code or works. They can access works only through the transmission
`-transaction protocol.
`
` Like the previous class except that high level encryption is used on all communications. Sensors are
`
`
`
`used to record attempts at physical and electronic tampering. _After such tampering, the repository will
`not perform other transactions until it has reported such tampering to a designated server.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Like the previous class except that if the physical or digital attempts at tampering exceed some preset
`thresholds that threaten the physical integrity of the repository orthe integrity of digital and cryptographic
`barriers, then the repository will save only documentdescription records of history but will erase or destroy
`any digital identifiers that could be misused if released to an unscrupulous party. It also modifies any
`certificates of authenticity to indicate that the physical system has been compromised. It also erases the
`contents of designated documents.
`
`
`
`Like the previous class except that the repository will attempt wireless communication to report tampering
`and will employ noisy alarms.
`
`This would correspond to a very high level of security. This server would maintain constant
`communications to remote security systems reporting transactions, sensor readings, and attempts to
`circumvent security.
`
`
`
`
`
`The characterization of security levels described in Table 2 is not intended to be fixed. More important is the idea
`of having different security levels for different repositories. It is anticipated that new security classes and requirements
`will evolve according to social situations and changes in technology.
`
`Repository User Interface
`
`A user interface is broadly defined as the mechanism by which a user interacts with a repository in order to invoke
`transactions to gain access to a digital work, or exercise usage rights. As described above, a repository may be em-
`bodied in various fomis. The user interface for a repository will differ depending on the particular embodiment. The
`user interface may be a graphical user interface having icons representing the digital works and the various transactions
`that may be perfonned. The user interface may be a generated dialog in which a user is prompted for information.
`The user interface itself need not be part of the repository. As a repository may be embedded in some other device,
`the user interface may merely be a part of the device in which the repository is embedded. For example, the repository
`could be embedded in a 'card' that is inserted into an available slot in a computer system. The user interface may be
`a combination of a display, keyboard, cursor control device and software executing on the computer system.
`At a minimum, the user interface must pemiit a user to input information such as access requests and alpha
`numeric data and provide feedback as to transaction status. The user interface will then cause the repository to initiate
`the suitable transactions to service the request. Other facets of a particular user interface will depend on the functionality
`that a repository will provide.
`
`CREDIT SEFIVEFIS
`
`In the present invention, fees may be associated with the exercise of a right. The requirement for payment of fees
`is described with each version of a usage right in the usage rights language. The recording and reporting of such fees
`is performed by the credit server. One of the capabilities enabled by associating