DPRL Manual

The Digital Property Rights Language

Manual and Tutorial - XML Edition

Version 2.00 — November 13, 1998

LIMITED DISTRIBUTION - REVIEW PURPOSES ONLY

The material contained in this document is provided for review purposes only. Receipt of this document does not constitute a license, actual or implied, to any intellectual property contained herein. All material contained in this document is the intellectual property of the Xerox Corporation.

1. INTRODUCTION *

1.1 Enabling Commerce in Digital Property *

1.2 Scope of this Document *

1.3 Basics of Digital Property Rights *

1.4 Interfaces to Digital Property Rights Specifications *

1.4.1 Rights Editor Interfaces *

1.4.2 Trusted System Interfaces *

1.5 Design Goals for the Digital Property Rights Language *

2. LANGUAGE SPECIFICATIONS *

2.1 Specifying a Work *

2.2 Digital Property Rights *

2.2.1 Transport Rights *

2.2.2 Render Rights *

2.2.3 Derivative Work Rights *

2.2.4 File Management Rights *

2.2.5 Configuration Rights *

2.3 Specifying Times *

2.3.1 Specifying Moments in Time *

2.3.2 Specifying Units of Time *

2.3.3 Specifying When Rights Can Be Exercised *

2.4 Specifying Fees and Incentives *

2.4.1 Currencies and Accounts *

2.4.2 Digital Tickets *

2.4.3 Per Use and Metered Fees *

2.4.4 Best-Price Fees *

2.4.5 Markup Fees *

2.5. Specifying Access Controls *

2.5.1 Digital Licenses (Certificates) *

2.5.2 Security Classes *

2.6 Specifying Watermark Information *

2.6.1 Watermark Strings, Tokens, and Objects *

2.6.2 Examples of Watermark Specifications *

2.7 Bundle Secifications *

2.7.1 Specifying Time Limits Inside Bundles *

2.7.2 Specifying Fees Inside Bundles *

2.7.3 Specifying Access Inside Bundles *

2.7.4 Specifying Watermark Information Inside Bundles *

APPENDIX A. LEXICAL CONVENTIONS *

Keywords *

Constants *

Identifiers *

Currency Codes *

APPENDIX B. GRAMMAR FOR THE DIGITAL PROPERTY LANGUAGE *

APPENDIX C. QUESTIONS AND ANSWERS *

General Questions About Digital Property Rights *

Questions About Work Specifications *

Questions About Transport Rights *

Questions About Render Rights *

Questions About Derivative Work Rights *

Questions About File Management Rights *

Questions About Time Specifications *

Questions About Fee Specifications *

Questions About Security and Authorization *

INDEX *

1. INTRODUCTION

The Digital Property Rights Language Manual is a work in progress specifying a language for describing rights, conditions, and fees for using digital works. The Digital Property Rights Language (DPRL) is intended to support commerce in digital works, that is, publishing and selling electronic books, digital movies, digital music, interactive games, computer software and other creations distributed in digital form. It is also intended to support specification of access and use controls for secure digital documents in cases where financial exchange is not part of the terms of use.

This manual is being circulated for review among publishers, platform vendors, authors, librarians, and others interested in the issues involving rights and fees for digital works. Our purpose in circulating the manual is to solicit feedback and suggestions that can guide us in developing the language and establishing appropriate standards. The use of a standard language for usage rights on digital property ensures that trusted systems can exchange digital works and interoperate. The trusted systems are for authoring, playing, and selling digital works. They include personal systems, on-line storefront systems, library systems, and others.

The digital property rights language describes distinct categories of uses for digital works in terms of "rights," including rights to copy a digital work, or to print it out, or to loan it, or to use portions of it in derivative works. DPRL also describes conditions and fees (if any) relevant to such uses.

Before describing the language itself, this introduction first discusses the commercial context for DPRL. It discusses the intended audience for this manual and how usage rights would actually appear to creators, publishers, and consumers of digital works. Finally, it describes our design goals and assumptions for the language.

For variety in expression, we use the words digital property rights, digital rights, and usage rights synonymously. Similarly, we use the words digital property rights language, digital property language, digital rights language, and rights language synonymously. We also use the terms digital publications, digital documents, and digital works synonymously.

1.1 Enabling Commerce in Digital Property

Digital technology has shifted the balance of practice in the social contract between those who create and distribute works and those who use them. For many kinds of digital works, it is very easy to use and duplicate a work without having authorization or providing compensation. With electronic networks, it is easy to distribute unauthorized copies of a digital work to points around the world, without knowledge of the publisher or author.

For some publishers, the issue of unauthorized distribution represents too great a business risk and they do not publish in digital form. For others the revenue losses are affordable, but they lead to billing and distribution schemes that are cumbersome. For example, distributors of digital works typically bill all users the same amount regardless of the use to which the consumers will put the work. Some digital publishers rely on the honesty of users not to replicate a work or use it in unauthorized ways after an initial purchase. Ironically, some publishers figure that some "leakage" of works that need periodic upgrading (such as computer software) helps to increase their installed base. However, even for computer software, it is often reported that there are more unauthorized copies in use than authorized ones.

Consumers of digital works are also poorly served. It requires much more time, effort and money to be honest than to slip beyond the legal rights for use of a digital work. Consumers sometimes view the creators of a work as opponents, and try to "get away with" unpaid use because they have paid so much for other works. Given the lack of safeguards and reliable billing services, few publishers have been willing to distribute their works digitally over computer networks. Consequently, consumers miss out on the convenience of 24-hour software shopping and on-line delivery. Since there are no reliable and general means for determining how much software is used, users must usually pay the same for software regardless of how much use they make of it.

Various approaches have been proposed to create a commercially viable means of distribution. These approaches are based on concepts such as trusted systems, semi-trusted systems, digital envelopes, and secure containers. The most general approaches are based on two simple ideas: that digital works can be bought and sold among trusted systems and that works have attached usage rights that specify what can be done with them and what it costs to exercise the rights.

Different publishing and distribution systems require different kinds of subsystems and capabilities. The digital property language is primarily concerned with those systems that are directly involved in buying, selling, and using digital works. These systems would generally be implemented as trusted systems.

A trusted system is a system that can hold digital works and which can be trusted to honor the rights, conditions, and fees specified for a work. Trusted systems can take different forms, such as "trusted players" that play digital works, or "trusted readers" for reading digital works or "trusted servers" that may provide access to digital works on a network. Recognizing that different applications require different kinds of trusted systems and different levels of security, we use the terms trusted system and repository interchangeably to refer generically to systems relied on to keep documents secure and to honor usage rights.

Different implementations of trusted systems have different requirements for security and different approaches. In the most secure approaches, all of the hardware and software on the platform is certified to honor digital rights. Other approaches focus on the use of so-called secure envelopes or containers, emphasizing transmission and storage of information. All such approaches have some elements that are assumed to be trusted and which can be circumscribed by boundaries of trust. These boundaries may be the boundaries of program code assumed not to be altered, data files assumed not to be acessible, language interpreters (such as Java) assumed to follow certain rules, or physical hardware assumed not to be compromised. The security of a trusted system depends in large measure on its vulnerability across these boundaries. For the purposes of this document, we use the term "trusted system" in a generic sense to refer to all systems for security and commerce in digital works, regardless of the techniques used to create a basis for trust.

We use the term "semi-trusted system" to refer to a class of repositories that have two levels of storage - regular storage and trusted storage. Regular storage is file space accessible to untrusted programs. Generally, this is used to hold encrypted works. Trusted storage is special storage not readily accessible to untrusted programs. Trusted storage is for encryption keys, billing data, some non-transferable digital certificates, and digital tickets.

Beyond trusted systems are several other kinds of systems, made up of hardware, software, and communications elements. For example, trusted systems would confirm credit and exchange billing data with financial clearing houses. In contrast to "authoring systems," we use the term "digital publishing systems" to refer to systems that can import digital works in native formats, interact with a publisher or distributor to add usage right information, and export the digital works in encrypted forms or in digital containers. We use the term "network sales server" to refer to systems that offer documents for sale on-line, such as on the World Wide Web.

1.2 Scope of this Document

This document explains the basic concepts for managing digital works in trusted systems, describes the language syntax and semantics, and provides examples of typical specifications of usage rights. It does not provide specifications for security in trusted systems, propose specific applications, or describe the details of the accounting systems required.

One of the goals of our work in usage rights is to develop an approach and language that can be used throughout the publishing industries and in other industries as well. This paper does not address the agreements, coordination or institutional challenges involved in achieving that goal. See (Stefik, 1995) for a sketch of some of the institutional challenges.

1.3 Basics of Digital Property Rights

Digital property rights (or "usage rights" for short) are rights associated with digital works and their parts that describe how the works can be used. Here are some basic concepts:

• Rights are associated with parts of a digital work (and with folders).

• Every class of usage right has a corresponding transaction.

• The transaction defines what a repository does when the right is exercised.

• Rights are described in sentences of a machine-interpreted language having a grammar.

• The transactions for a given work are parameterized by the information in the usage rights sentences for the work.

• The rights on a work can be changed later, if the change is authorized by the rights owner.

1.4 Interfaces to Digital Property Rights Specifications

Specifications in the digital property language are established by creators of digital works and also by publishers and distributors. Specifications are used by consumers as they select and use digital works. However, creators, publishers, distributors, or consumers would seldom (if ever) look directly at specifications written in the language.

Thus, specifications in the usage rights language are intended to be readable by machines rather than directly readable by people. They are used by systems that store, play, transport, copy, and sell digital works. These repositories potentially include a range of devices with embedded computers, including personal computers, set top boxes, personal document readers, personal entertainment devices, on-line servers, and trusted printers.

In many cases, the rights associated changing rights with a digital work are established at the time that the work is published and remain the same over time. There are, however, several ways that rights may be changed over time, and these involve different interfaces.

• Republishing with new rights. In the simplest case, the publisher or rights holder may simply republish a work with new rights. At the time of publishing, the terms and conditions on new copies of the work are changed to be different from those on older copies of the work. One way to accomplish this is simply to reinvoke a rights editor on a copy of the work and then to begin distributing only the revised version. An important job of a rights editor is to check the credentials of the person seeking to change the rights, since only the rights owner is authorized to change the rights on a work.

• Embedding a work and adding new terms and fees. In this case, a work may be embedded in a larger work. Embedding is controlled by the Embed right discussed later in this document. Generally, embedding is done by a distributor, who adds value by repackaging the work. Embedding typically adds extra fees for exercising rights. Although this operation typically includes combining a work with additional content, it includes the case where the content itself is not changed.

• Upgrading rights. Some trusted systems will support the operation of changing the rights on a work already distributed. This process would be carried out on a trusted system which checks the authorization for the change during a transaction that changes the rights. The details of the transaction are beyond the scope of this document except to say that the operation is automatic and the transaction to change the keys must be digitally signed by the rights owner.

Programmers developing trusted applications that use the rights language would typically not work with the syntax directly. Instead, they would use the application programmer’s interface (API) to an object-oriented representation of the statements in the rights language. The application interface is described in other documents.

1.4.1 Rights Editor Interfaces

To specify rights a publisher of a digital work uses a graphical user interface (a "rights editor" program) in a digital authoring or publishing system. Such interfaces can take different forms. For example, one convenient form of a right editor interface is similar to a spreadsheet.

The interface enables a publisher to fill in information indicating what rights, fees, or licenses apply to the digital work at hand. For example, a publisher may simply select individual rights or a set of standard rights from a menu, modifying them slightly to indicate particular fees or distribution requirements. The publishing program then outputs a specification written in the digital property language and attaches that specification to the digital work.

1.4.2 Trusted System Interfaces

Trusted systems, such as trusted workstations, trusted music players, trusted video players, and other trusted devices need user interfaces appropriate to the device.

For example, to play a work of digital music or a video, a consumer would just press the play button of a trusted player in much the same way that one uses a play button on a conventional compact disk or video tape player. In many systems, pushing a button would automatically invoke all of the appropriate checking, authorization, and payment transactions that are required for playing the digital work. In some systems, a consumer could use a small display similar to a calculator display to select among different rights or billing options. Different devices would have different user interfaces, but interoperable devices would share a common digital property language — a lingua franca for systems dealing in permissions and fees.

In some cases, a digital work may be offered with hundreds of variations on the rights. For example, a publisher may offer variations on rights at different prices for different users. There may be regular consumer rates, corporate rates, special rates for academic institutions or libraries, special rates for members of the book of the month club, special rates for frequent fliers, special rates for recent purchasers of other works by the same publisher, and so on. There can be different rates for a permanent use, use over a ten year period, or use over a special two-day introductory period.

In many cases, an unmediated interface to so many variations will be overly complex for normal use. An alternative is for the system to present the set of credentials, memberships, and special offers available to the user via an interface agent that matches held certificates and tickets with the rights offers available on the digital work. Given a selection policy established by the user, the agent can filter the choices down to a small set or automatically select the lowest cost right meeting the user’s needs. For example, on a trusted music player, pressing the play button may be all that is required to select the least expensive alternative and play the work.

1.5 Design Goals for the Digital Property Rights Language

The design goals for DPRL are:

• To describe rights, fees, and conditions appropriate for the commerce models that are important to publishers and consumers in digital publishing.

• To provide standard terms for usage rights specifications that have useful, concise and easily understandable meanings.

• To provide operational definitions of specifications for vendors of trusted systems that distribute or render digital works, so that the compliance of systems can be tested and evaluated.

• To provide a basis of extensibility to new language features in a manner that does not unduly compromise the other goals.

Digital commerce in documents requires a wide range of specification abilities to handle the variety of publishing niches and payment schemes that will be desired. A digital property rights language should be expressive enough to handle a wide range of situations for commerce in documents. The rights specifications must be practical to interpret and enforce by computer systems. Furthermore, the meaning of rights expressed in the language must be clearly defined so that different systems will interpret the rights in the same way.

Broadly construed, DPRL is about "terms and conditions" of use. Terms and conditions ultimately refer to facts about the world and permissioned actions on digital works. Examples of facts are: the current date and time, whether the user is a member of the book of the month club, and the security class of the trusted system. DPRL requires well-defined and certified ways of determining such facts, such as trusted clocks and accessible, signed digital certificates attesting to various facts. Restated, the kinds of facts DPRL uses to determine whether a right can be exercised are always determinable in a reliable way by accessing digital certificates and controlled internal parameters of trusted systems.

Actions sanctioned by terms and conditions are always well-defined transactions corresponding to exercising specific digital rights. Thus, there are transactions defined for such actions as printing, copying, or making an encrypted backup copy. All of these actions are performed by trusted systems. There are no rights in DPRL for actions performed by people, such as "play for educational purposes," although this might alternatively be approximated as "play for a user possessing a specific, valid educator or student certificate."

Although the digital property rights language has already benefited from comments from publishers and other interested parties, the language is not frozen. Further changes will be made as we discover situations that we have not yet considered. Feedback and suggestions are solicited.

2. LANGUAGE SPECIFICATIONS

Usage rights specifications are represented using the element/attribute markup model of eXtensible MarkUp Language(XML) . Collectively, the markup tags indicate what rights are in effect on a digital work. Different parts of a work may have different rights specified. The rights specification is written in a Document Type Definition (DTD) file.

Terms in italics represent elements. An element may contain other elements, together with character data. Elements can also contain meta-data in the form of attribute list. A basic XML element declaration looks like this:

<!ELEMENT list (item)+>

This means that the element list contains one or more item elements. "+" denotes one or more. "*" denotes zero or more. A "?" indicates that a specification is optional. Vertical bars "|" are used to indicate alternative expressions. For example, the rule

<!ELEMENT b (a, (x| c)?)>

<!ELEMENT x (list))

<!ELEMENT a EMPTY>

<!ATTLIST a d CDATA #REQUIRED>

<!ELEMENT c (#PCDATA)>

means that a element b is expanded into an "a" followed by an optional "x" or "c". The element x is expanded to another element "list". The element a does not contain any data between its start and end tags but has a mandatory character data attribute "d" that has to be specified. The element c contains Parsed Character Data (PCDATA) . The "#"words are XML keywords and should be used as is (case senstive).

If an element (as in "a") is specified to be EMPTY, it means that there will not be anything between its start and end tags. The usage of such tags within a XML document can be in either of the following two ways:

An element can also be defined as ANY, in which case, between the start and end tags of that element any other tag or data can be specified in the XML document.

Just as elements represent the document’s logical structure, entites represent its physical structure. A reference to a declared entity can be done in the DTD. For example

<!ENTITY % inline "#PCDATA | emphasis | link" >

<!ELEMENT para (%inline;)

is equivalent to <!ELEMENT para (#PCDATA | emphasis | link)>

White space in the language follows the XML specification. White space, such as spaces, tabs and blank lines, is used to set apart the markup for greater readability. However, "significant" white space within character data is preserved. In XML, all markup tags are case sensitive and the XML documents using this DTD should use the tags as defined. Thus a "Work" tag is different from "work" tag or "wORk" tag. The rights specification DTD defines all the tags by capitalizing the first letter for better readability.

The comments in a XML document begins with "" characters.

Design goals for the specification written in XML include

• Simple parsing. The XML is compatible with SGML and is easy to write programs which process XML documents.

• Extensive defaulting. Many parameters are optional. The mandatory parameters are specified and optional parameters have well-defined defaults.

• Extensibility. In the rights specification DTD, it is easy to add new features unambiguously without substantially modifying the language or rewriting old specifications.

The rights specified in an XML document should meet all the well-formedness and validity constraints specified in the DTD. An example of well-formed, valid XML is

<b>

<c>"This element is a PCDATA"</c>

</a>

</b>

The order in which the elements are specifed within another element is position-sensitve. (i.e within the element "b", element "c" cannot be specified before "a".

2.1 Specifying a Work

The highest level grouping in the digital property language is a work specification.

The language design goal for a work specification is to provide a place for the information relevant to a digital work. A composite work would have a separate work specification for each part of the overall work.

<!ELEMENT Work (RightsVersion,

WorkId?,

Description?,

Owner?,

Parts?,

Contents?,

Copies?,

Comment?,

(RightsGroup | ReferencedRightsGroup)+

<!ELEMENT RightsVersion EMPTY>

<!ATTLIST RightsVersion version-id CDATA #REQUIRED>

<!ELEMENT WorkId EMPTY >

<!ATTLIST WorkId work-id CDATA #REQUIRED>

<!ELEMENT Description (#PCDATA)>

<!ELEMENT Owner (Certificate)>

<!ELEMENT Parts (WorkId+)>

<!ELEMENT Contents EMPTY>

<!ATTLIST Contents from CDATA #REQUIRED

to CDATA #REQUIRED>

<!ELEMENT Copies EMPTY>

<!ATTLIST Copies copy-count CDATA #IMPLIED>

<!ELEMENT Comment (#PCDATA)>

A work specification includes the RightsVersion which is the version of the rights language used for the specification. This is intended to facilitate backward compatibility to works whose rights were written in an old version of the language.

A work specification also includes optional work identification (WorkId). This identifies a digital certificate signed by a well known registration authority and assigning a unique identification number to the digital work. Assumptions and methods for identifying and rating works are discussed elsewhere in this document.

The work-id is an identification tag which can be used to identify this work. It includes information for detecting locally if the work has been changed or tampered with. It also includes address information for locating a reference copy of the work.

A work specification also includes an optional text description of the work, which is intended to hold ISBN numbers for books, ISSN numbers (for periodicals), author addresses, and a variety of other information for identifying a work, but whose format is not necessarily fixed. The format and scope of the information in the text description is not specified, so that different organizations can put different information here. In general, the information in the text description is intended for human use. It is not used in the automatic rights processing of a repository.

The ability to change the rights on a work is not the same issue as adding further fees or restrictions when a work is included in a composite work. Rather, it is the right to change the terms and conditions within the work specification. A work specification includes an optional owner specification, which indicates who is authorized to change any part of the work-specification, including adding or deleting rights, changing conditions, or raising or lowering fees. The owner specification indicates what digital license is required to make the changes. If no owner specification is specified, then anyone can make changes to the rights on a digital work. This is the first example of a specification of a digital certificate. Digital certificates and their representation are described in more detail later in this manual.

For composite works, the optional parts specification specifies a list of works which are included as parts of this work. The right specifications given in the higher level work specification are for the work as a whole. (They do not override the rights on individual included works. See the appendix on transaction semantics.)

The contents specification gives the starting and stopping addresses to which the rights in the work specification apply. If no contents specification is given, the work is interpreted as covering the entire attached digital work. When works are nested, the addresses are taken as relative to the beginning (origin) of the larger containing work. The form of an address depends on the medium on which the work is stored.

An optional copies specification gives the number of copies of the digital work. This field is referenced in the operation of various rights. If no copies specification is given, the number of copies of the digital work is taken to be one. If there are two or more copies, then it is possible to transfer or loan a copy of the work while exercising other rights on remaining copies.

A work specification includes an optional comment. Comments in DPRL are intended for documentation, typically used by people creating and updating rights specifications. Comments are not interpreted for meaning by trusted systems. However, persistence of comments is important in order for comments to serve their purpose. Comments have fixed and specific locations in the syntax ("structured comments"). There can be atmost one comment in a work specification. Comments can also be used in other places in a specification, such as in rights groups, as described later.

Finally, a work specification includes a list of named groups of rights.

<?XML version="1.0" encoding="UTF-8"?>

<!DOCTYPE Work SYSTEM "work.dtd">

<Work>

<Owner>

</Certificate>

</Owner>

<Parts>

</Parts>

<Comment>"Rights edited by Pete Jones, June 1996."</Comment>

<Comment>"This set of rights is used for standard retail editions."</Comment>

</Access>

</Account></BundleMonetary></BundleFee>

</Bundle>

<Play>

</MeteredFee></Monetary></Fee>

</Play>

<Print>

</Certificate>

</Printer>

<Watermark-Tokens all-rights="false" render-rights="true"/>

</Watermark>

</Print>

<Copy>

</Copy>

<Copy>

<User>

</Certificate>

</User>

</Access>

</Copy>

</Restore>

</RightsList>

</RightsGroup>

</Work>

This example of a work specification in the digital property language has one rights group. The work specification expresses conditions and fees for several rights: play, print, transfer, copy, delete, backup, and restore. The syntax, meaning and defaults of these various right specifications are explained later. The work includes two other parts, a photograph and a chart of breeds incorporated from other sources.

Usage rights specifications are organized in groups of rights. Various rights specify what usage rights are passed along when a work is copied, transferred, loaned, or used in derivative works. It is convenient to refer to groups of rights by name. Within a work specification, each rights group must have a unique name.

<!ELEMENT RightsGroup (Comment?, Bundle?, RightsList)>

<!ATTLIST RightsGroup group-name CDATA #REQUIRED>

<!ELEMENT ReferencedRightsGroup (Comment?, Bundle?, RightsList)>

<!ATTLIST ReferencedRightsGroup group-name CDATA #REQUIRED>

There are two kinds of rights groups: regular rights groups and reference rights groups. A regular rights group contains a group of rights applied to the current work. A reference rights group contains a group of rights that can be referred to by name in transport rights and applied to subsequent copies of the work.

A rights group can include an optional comment before the list of rights.

A rights group can include an optional bundle specification, which specifies time specifications, fee specifications, or access specifications that apply to all of the rights in the group. The precise meanings of time specifications, fee specifications, access specifications, and watermark specifications as they appear in bundle specifications are explained in later sections. A bundle specification can include an optional comment.

The rights for a digital work are explicitly listed. Any right not in the list is not granted. The name of the right identifies the kind of right. Kinds of rights fall into various classes as explained later.

There can be more than one instance of a particular kind of right for a given work. For example, there can be more than one instance of a Copy right, which grants permission to make new copies of a digital work. One instance of the Copy right may have a special rate for "book of the month club" members. Another instance of the Copy right may allow copies to made without charge if the consumer has an appropriate digital ticket.

<!ELEMENT RightsList ((Copy | Transfer | Loan |

Play | Print | Export |

Edit | Extract | Embed |

Install | Uninstall)+)>

Each right, identified by its name, has an optional comment, an optional time specification, an optional access specification, and an optional fee specification.

All the rights being granted for the work is specified in the list. The various kinds of rights covered by the usage rights system are described in the rest of this section. The time specification states the period of time over which the right is granted. The access specification states conditions on the exercise of a right, such as a requirement for various authorizations. The fee specification states fees associated with the exercise of a right. These specifications are described individually in the following sections of this manual.

The specifications for a given right are a combination of (1) the specifications explicitly within the right statement itself, and (2) specifications from an optional bundle specification in the rights group to which it belongs. If there is no time specification, then there is no time limit on the use of this right. If there is no access specification, then there is no access test (including security level) required. If there is no fee specification, then there is no fee required for use. A right specification can include an optional comment.

2.2 Digital Property Rights

Rights belong to one of several categories. The rights in DPRL describe uses that:

• Relate meaningfully to distinctions of use described in copyright law.

• Respect distinctions of use relevant to common licensing arrangements in commercial purposes of digital works.

• Are enforceable by practical trusted systems.

• Are exercised by carrying out a particular transaction on a repository.

Logically, rights can be categorized into Transport, Render, Deravative work, File management and rights for Configuration. Transport rights govern the movement of a work from one repository to another. Render rights govern the printing and display of a work, or more generally, the transmission of a work through a transducer to an external medium. (This includes the Export right, which can be used to make copies in the clear.) Derivative work rights govern the reuse of a work in creating new works. File management rights govern such things as making and restoring backup copies. Finally, configuration rights refer to the installation of software in repositories.

The next five sections pf this manual, describe each of the rights that fall under each catergory.

2.2.1 Transport Rights

Transport rights govern the creation and movement of persistent copies of a work under the control of trusted repositories. There are three distinct kinds of transport rights: copy, transfer, and loan. The interpretation of these rights are similar to familiar operations on physical works: copying an audio tape, transferring (or giving someone) a book, or loaning a compact disc.

The design goals of the transport rights are to provide for the following:

• To distinguish between rights for moving works among repositories and rights that increase the total number of copies of a digital work.

• To describe controlled loaning of works, both personal loans and also institutional or library loans.

• To support a range of distribution models, including both licensed distributor models and consumer-based distribution (also known as super distribution).

• To enable publishers to specify how the rights change on new copies of works.

• To control what rights move to the loaner copy when a copy of a work is loaned out and also what rights stay behind.

<!ELEMENT Copy (NextCopyRights?, Comment?, Time?, Access?, Fee?)>

<!ELEMENT Transfer (NextCopyRights?, Comment?, Time?, Access?, Fee?)>

<!ELEMENT Loan (RemainingRights?, NextCopyRights?, Comment?, Time?, Access?, Fee?)>

A Copy right is the right to make a new digital copy of a work. (Print rights, described later, govern the making of hard copies.) The Copy right is invoked whenever a new digital copy is made. Like all rights, the right to copy can be parameterized by time, access, fee, and control specifications. An optional next-copy-rights specification can be used to establish rights for the new copy that are distinct from the rights on the original.

A Transfer right is the right to transfer the digital work from one repository to another. A Transfer right does not increase the number of copies of a work because the transfer transaction between two trusted systems removes the digital work from the sending repository when the copy has been created and verified on the receiving repository.

A Loan right is the right to loan a copy of the work for a period of time. A Loan right creates a "loaner" copy of a work on a receiving repository. Typically, during the time that a work is loaned, the original copy of the work cannot be rendered. However, if there is more than one copy of the work on the original repository, then the original repository can still exercise all rights on copies that are not loaned out. As discussed below, exactly what rights are usable by either the loaning repository or at the loanee repository can be specified explicitly using the next-copy-rights and the remaining-rights specification.

Throughout the loan period, both repositories must keep track of the fact that the copy has been loaned and take this information into account in all relevant transactions. At the end of the loan period, the copy of the work on the receiving repository deactivates and the copy on the loaning repository reactivates.

<!ELEMENT NextCopyRights (RightsToAdd | RightsToDelete)>

<!ELEMENT RemainingRights EMPTY>

<!ATTLIST RemainingRights group-name CDATA #REQUIRED>

When a digital work is copied, transferred, or loaned, certain rights become available on the receiving repository. Exactly which rights are available is determined by an optional NextCopyRights specification. By default, the rights on the new repository are the same as the rights on the original repository. However, the list of rights can be modified by specifically adding or deleting groups of rights. The groups named can be either regular rights groups or reference rights groups.

The rights specification for the next copy can be described as a set of differences from the original specification. These differences may be rights to add to those of the original and rights to delete from those of the original. The set of rights provided in the RightsToAdd specification is added to those of the original work. The set of rights provided in the RightsToDelete specification is deleted from those of the original.

<!ELEMENT RightsToAdd EMPTY>

<!ATTLIST RightsToAdd group-name CDATA #REQUIRED>

<!ELEMENT RightsToDelete EMPTY>

<!ATTLIST RightsToDelete group-name CDATA #REQUIRED>

The optional remaining rights specification describes what rights to keep behind in the original loaned work. If this specification is not given, then no rights are retained when the last copy is loaned out.

Here is a simple example of a Loan usage right that specifies what rights to keep and which ones to give on the loaned copy. In this case, the loaner copy gets all of the rights except the book club rights, which are retained, by the original repository.

<Loan>

</Access>

</Loan>

Here is another example of a work specification. This work specification has two rights groups, one called "Distributor" and one called "Consumer."

<?XML version="1.0" encoding="UTF-8"?>

<!DOCTYPE Work SYSTEM "work.dtd">

<Work>

<Owner>

</Certificate>

</Owner>

<Comment>"These rights limited to our licensed distributors."</Comment>

</Certificate></User>

</Access>

</Bundle>

<Copy>

</Ticket></Fee>

</Copy>

</RightsList>

</RightsGroup>

<Comment>"These rights exercised by any owner of our works."</Comment>

</Access>

</Account></BundleMonetary>

</BundleFee>

</Bundle>

</Account></Monetary></Fee>

</Copy>

<Play>

</MeteredFee></Monetary></Fee>

</Play>

<Delete><Comment>"This right is without restrictions."</Comment></Delete>

<Loan>

</Loan>

</RightsList>

</RightsGroup>

</Work>

The distributor rights include the right to copy a work without fee except that a particular digital ticket must be punched. The distributor rights also include a right to play the work without fee. Each of the rights in the "Distributor" rights group requires a Murphy’s distributor digital license to exercise.

There is also a "Consumer" rights group. This group includes rights to copy, play, delete, transfer, and loan. The copy right has a set fee to make a copy and the play right has a metered charge of five cents per hour. A loaner copy does not carry the distributor rights.

2.2.2 Render Rights

Render rights govern the creation of representations of a digital work outside of the control of trusted systems.

According to the dictionary, to render something is to represent it in a verbal form or in a drawing or a painting. In the context of usage rights, we use the word "render" to refer to processes that transform a digital copy of a work into a form where it can be seen or used outside of the repository. For example, a digital book or digital photograph may be displayed on a screen, a piece of music may be played through a loud speaker, a movie may be shown on a screen, or a page of a book may be printed on a printer.

When a digital work is rendered, information moves outside of the control of a trusted system. This presentation of the work as image or sound makes it possible for someone to see or hear the work. Necessarily, it also makes the work accessible for analog copying. Anything you can see you can photograph; anything you can hear you can record. Rendering does not imply permission to make other recordings of the work, such as with a film camera, video camera, or tape recorder, even though such copies will typically have lower quality than the digital original. The right to make such copies is governed by copyright law. Many techniques for rendering from digital originals also allow the inclusion of information in watermarks and fingerprints, making it possible to identify the work and also the person who played it. Although recordings of rendered works cannot be prevented, such non-digital copying of a work is governed by applicable copyright laws.

The design goals of the render rights are:

• To distinguish between rights for making ephemeral copies such as display images and rights for making long-lasting copies such as printouts.

• To provide a means of distinguishing different kinds of players and printers for digital works such as ones that add distinguishing codes. For example, a publisher may want to limit printing of a digital work to certain kinds of printers that are capable of embedding specific kinds of watermarks.

• To provide a controlled means for creating unencumbered digital copies outside of a trusted system.

• To provide a means for specifying information to be embedded in watermarks for works displayed or printed. Watermark data can be pre-specified by a publisher or distributor. It includes data that is not known until the time that a work is printed or displayed.

<!ELEMENT Play (Player?, Watermark?, Comment?, Time?, Access?, Fee?)>

<!ELEMENT Print (Printer?, Watermark?, Comment?, Time?, Access?, Fee?)>

<!ELEMENT Export (Repository?, Comment?, Time?, Access?, Fee?)>

There are three kinds of render rights: play, print, and export.

Play rights refer to ways of making a transient or ephemeral copy of a work available for use. For example, a page of a book may be displayed on a screen or music may be played out a speaker. The image on the screen or the sound coming out of the speaker is a transient copy. The Play right is also used to refer to invocation of a computer program, such as when someone plays a video game. The renderings produced when a Play right is exercised are ephemeral. Another way to understand a "Play" right is that playing requires active participation by a trusted player to render the work during the entire time that the work is perceivable.

Print rights refer to making more permanent rendered copies of a work outside of the control of a repository. In contrast to the Play right, once a work is printed, the printed copy can be viewed without requiring that the "printer" be used the entire time. The typical case is printing something on paper at a printer. The Print right also refers to making rendered copies on other external media, such as bitmap images on removable disks or audio on magnetic tapes. For example, a repository may provide rights to "print" encrypted backup copies of a digital work. Unauthorized use of such copies is inhibited because such copies of the work are generally encrypted.

An Export right makes a digital source copy outside of trusted system control. Typically, this would be a file in a format suitable for unencumbered viewing, printing, or editing. Thus, this right can be used to make a digital copy that is not encrypted or otherwise protected. An Export right might be exercised, for example, to release an older work after it has passed out of copyright.

Render rights can optionally specify the use of particular kinds of hardware for playing and printing. These specifications are intended to qualify the use of a work. Players and printers are parts of repositories, and are sometimes called trusted players and trusted printers. They are identified by non-transferable digital certificates. A given repository, such as a trusted printer, may have several different digital certificates corresponding to different output devices or kinds of printing services. For example, a digital movie player may specify a kind of player suitable for home use rather than theater use. The certificate for a particular player may be used to differentiate between high and low resolution renderings with appropriately different fees.

A printer specification may indicate a printer which marks the pages with a particular kind of identifying watermark. Specifications for embedding data in watermarks on trusted printers and trusted players are discussed in a later section.

Here is an example of a work specification. This specification is for a digital home movie. The work has two groups of rights called "theater" and "home-viewer". The theater rights allow playing the movie on a kind of public viewer by authorized distributors for a fee of $100. The home-viewer rights allow playing the movie on a home player for a rate of $5 per hour.

<?XML version="1.0" encoding="UTF-8"?>

<!DOCTYPE Work SYSTEM "work.dtd">

<Work>

<Description>"Title: 'Zuke-Zack, the Moby Dog - The Movie' Script:'John Beagle'

Director: 'Peter Hound Jones' Producer: 'Martha Jones'

No Cruelty to Animals in this flick.

</Description>

<Owner>

</Certificate>

</Owner>

<Play>

</Certificate></Player>

</Certificate></User></Access>

<Fee>

</Account></Monetary></Fee>

</Play>

</RightsList>

</RightsGroup>

<Play>

</Certificate></Player>

<Fee>

</Monetary>

</Fee>

</Play>

</RightsList>

</RightsGroup>

</Work>

The following example is of a digital book. The exemplar digital book has no fee for playing, but does have a five dollar fee for making a digital copy. It also has two Print rights, both requiring a trusted printer. The first Print right can be exercised if the user has a particular prepaid ticket. The second print right has a flat fee of ten dollars. The example assumes that the digital book can transmitted to a user’s computer by exercising the Copy right, and that the user can play or print the work at his or her convenience using the Play and Print rights. Fees are logged from the user’s workstation whenever a right is exercised.

<?XML version="1.0" encoding="UTF-8"?>

<!DOCTYPE Work SYSTEM "work.dtd">

<Work>

</Certificate></Owner>

</Access>

</BundleMonetary></BundleFee>

</Bundle>

<Print>

</Certificate></Printer>

</Ticket></Fee>

</Print>

<Print>

</Certificate></Printer>

</Print>

</RightsList>

</RightsGroup>

</Work>

Here is a different version of rights for the "Moby Dog Story" digital book. In this version, the publisher does not want digital delivery to be made directly to a consumer workstation. A practical consideration supporting this choice may be that the publisher wants to minimize the risk of unauthorized copying and requires a higher level of security than is provided by trusted systems on available workstations. Instead, the publisher wants the book to be sent directly from an on-line bookstore to a trusted printer. Printing must be prepaid via digital tickets. To enable digital distribution to authorized distributors but not directly to consumers, the publisher requires that both parties in a Copy right be have an authorizing digital license. In this example, a consumer can not play the work at a workstation. Instead, the consumer must print the work.

<?XML version="1.0" encoding="UTF-8"?>

<!DOCTYPE Work SYSTEM "work.dtd">

<Work>

</Certificate></Owner>

</Access>

</BundleMonetary></BundleFee>

</Bundle>

<Copy>

</Certificate></Source>

</Certificate></Destination>

</Access>

</Copy>

<Print>

</Certificate></Printer>

</Ticket></Fee>

</Print>

</RightsList>

</RightsGroup>

</Work>

2.2.3 Derivative Work Rights

Derivative work rights govern the reuse of a digital work, in whole or part, to create a new composite work. The design goal for derivative work rights is not to cover all possible forms of reuse. Many kinds of reuse involve substantial negotiation about issues that are outside the scope of what a practical trusted system can mediate or check. Rather, the derivative use rights are intended to automate the simple case where the rights owner can pre-determine fees and repository-testable conditions on a work prior to distributing it digitally.

The design goals for the derivative work rights are:

• To make it possible for the rights owner to pre-arrange fees and conditions governing subsequent use of the material in derivative works.

• To make it possible for the rights owner to pre-determine whether communication for notification or authorization is required before a derivative work right can be exercised.

• To ensure that all information about authorship, identity, contents, and rights is controlled or preserved in the derivative work.

• To arrange that the collection of fees for use of derivative works is automatic and can depend on the number of copies of the derivative work that are actually made.

• To enable a rights owner to determine whether derivative works can incorporate selected portions of a work, or whether the original work must be incorporated in total.

• To provide a framework that can eventually enable a rights owner to determine what kinds of changes are permitted in the derivative work, if any.

<!ELEMENT Edit (Editor?, NextCopyRights?, Comment?, Time?, Access?, Fee?)>

<!ELEMENT Extract (Editor?, NextCopyRights?, Comment?, Time?, Access?, Fee?)>

<!ELEMENT Embed (Editor?, NextCopyRights?, Comment?, Time?, Access?, Fee?)>

<!ELEMENT Editor (Certificate+)>

There are three kinds of derivative work rights: extract, edit, and embed.

The Extract right allows removing a portion of a digital work, creating a new work. A rights owner can divide a total digital work up into different sub-works, each with its own work specification. In this way, the rights owner can decide whether a work can be reused as a whole or in parts, and also can associate different rights and conditions with different parts of a digital work. Extract differs from Edit in that it does not grant the right to modify a work, except by removing parts of it.

The editor specification is intended to be used to test whether different editing systems qualify. From the perspective of DPRL, an editor is expected to be a trusted system with signed certificates attesting to its properties. A publisher can name the properties that an editing system must have before it can be used to edit the work. If the optional editor specification is not given, then any editor program can be used for the extraction process. Otherwise, an editing system with the specified certificates can be used.

Edit grants the right to modify a work. Edit is like Extract in that it creates a new work. It differs from Extract in that it is used to make changes to a work. A rights owner can control what kinds of changes can be made to a digital work by specifying a kind of editor. For example, a particular digital audio music editor may allow someone to change the pitch or key of a piece of music, but not add notes. If the optional editor specification is not given, then any editing program can be used. Otherwise, only the specified editing system can be used.

Embed grants the right to include a work as part of a composite work. Embed puts a copy of a digital work inside a composite work. If the optional editor specification is not given, then any editing system can be used. Otherwise, only the specified editor can be used.

By default, if the optional next copy rights are not specified, the fees and conditions for a work when it is reused are the same as the fees and conditions for the original work. A publisher can override this default by adding or deleting rights in an optional next-copy-rights specification.

<?XML version="1.0" encoding="UTF-8"?>

<!DOCTYPE Work SYSTEM "work.dtd">

<Work>

</Certificate></Owner>

<Comment>"These rights apply to deravative works."</Comment>

<Copy>

</Access>

</Account>

</Monetary></Fee>

</Copy>

</RightsList>

</RightsGroup>

</Access></Bundle>

<Copy>

</Account>

</Monetary></Fee>

</Copy>

</Certificate>

</Editor>

</Extract>

<Embed>

</Certificate>

</Editor>

</NextCopyRights>

</Embed>

<Play>

<Fee>

</Account>

</Monetary>

</Fee>

</Play>

</RightsList>

</RightsGroup>

</Work>

Here is an example of how a work can be specified to provide for derivative use. In this example, the publisher has granted Extract and Embed rights requiring that a particular "editing" program be used. No changes can be made to the work. In addition to the original rights on the work, the embedded work has an additional copy right with a lower per use fee paid to a different account.

For some applications, it will be useful to have fairly elaborate controls on the changes that can be made to a derivative work. For example, a written work may require that certain sections always be extracted together. A musical work may allow changing the key and pitch but not the notes. The variety of possible kinds of controls is rich, not developed, and depends on the media and application. The digital property language is designed to allow application-specific kinds of restrictions as described in the following.

Each kind of editor can have its own terminology for kinds of change. For example, a digital music editor might have editing operations for pitch, key, instrumentation, and other things. Digital representations for works can be augmented to include annotations that point to regions of a work and specify in an application-specific way the kinds of changes that can be made. Such annotations would have no effect when a work is played, but would control editing operations when a derived work is edited.

In this way the rights specifications are divided between domain-independent considerations in the digital property language and the application-specific considerations in specific editors. The usage rights language allows a rights owner to specify general usage rights in the usual way, including the required use of a chosen editor (or family of editors) for editing the work. The rights owner then uses the specified editor to annotate the work to specify the kinds of changes that are allowed in domain specific terms. Later when a user wants to make a derived work by editing the work, he must use a compatible trusted editor which follows the domain-specific change annotations.

2.2.4 File Management Rights

File management rights govern access to directory and file information when two repositories are connected. File management rights control how directory information of one repository can be accessed from another. They also control the making and restoring of backup copies.

Some usage rights, such as Print or Copy, typically involve more than one repository. Other usage rights, such as Transfer and Loan, inherently involve more than one repository. To exercise rights that involve more than one repository, a user at one repository must be able to access digital works located on another.

The design goals for the file management rights are as follows:

• To provide a simple and consistent means to specify and control access to digital works across different repositories and different kinds of repositories.

• To provide a lightweight and convenient means for organizing collections of digital works on a repository.

• To integrate specifications for controlling how collections of works can be used with specifications about how individual works can be used.

• To provide facilities that manage the risk of system or media failure or distribution of rogue works.

<!ELEMENT Backup (BackupCopyRights, Comment?, Time?, Access?, Fee?)>

<!ELEMENT Restore (Comment?, Time?, Access?, Fee?)>

<!ELEMENT Verify (Verifier, Comment?, Time?, Access?, Fee?)>

<!ELEMENT Folder (Comment?, Time?, Access?, Fee?)>

<!ELEMENT Directory (Comment?, Time?, Access?, Fee?)>

<!ELEMENT Delete (Comment?, Time?, Access?, Fee?)>

<!ELEMENT BackupCopyRights EMPTY>

<!ATTLIST BackupCopyRights group-name CDATA #REQUIRED>

<!ELEMENT Verifier(Certificate+)>

There are six kinds of file management rights: Folder, Directory, Delete, Verify, Backup, and Restore.

When a repository has many digital works, it is often convenient to organize them into named hierarchical sets called folders. This approach is basic to many popular file systems, such as Windows™, MacOS™, and UNIX™. In repositories built on conventional computer file systems, these hierarchical sets generally correspond to file system folders and directories. For consistency across brands of repositories, the same digital property language that applies to digital works is also used for folders.

Folder rights govern the creation and naming of subfolders, and the right to reconfigure the folders by moving files and folders among folders. These rights are exercised by commands at a repository user interface. The right to exercise all of these operations is governed by the single "folder" right. (Restated, there are no separate rights for moving or renaming files and folders. All of these repository actions are governed under folder rights.) Directory rights govern the delivery of information about what works are contained within folders.

Here is an example of a rights group for a personal folder on a repository. The rights on a folder augment the rights of the works in a folder. For example, if a work is moved into a folder on which there are no print rights, no work in the folder can be printed. In this example, the rights group named "PersonalFolder" simply adds the requirement that a particular authorizing license ("Stefik’s license") be in force before any of a set of rights can be exercised. Moving a work into this "personal" folder would prevent anyone, who is logged into the repository but who does not have the license, from accessing or using any work in the folder.

</Certificate></User></Access>

</Bundle>

</RightsList>

</RightsGroup>

A directory listing may be requested of any folder in a repository, allowing either the local or a remote repository to get information about the works, their parts, and other folders contained in it. The ability to get information about a folder, a work, or its parts may be withheld in such directory listings by simply requiring a license to exercise the right.

Delete rights govern the operation of deleting a copy of a digital work. The generally expected practice is to grant any copy owner the right to delete the work. The right to delete needs to be controlled in applications where many people can log into a repository and where deleting a file could be done accidentally or in malicious mischief. To prevent the unwanted and unauthorized deletion of digital works that are accessed remotely, it is typical for a Delete right to include various conditions, such as the requirement of a digital license to exercise the right.

An opposite problem from unauthorized deletion is the creation of "Trojan Horse" works which are copied for free but which require fees to delete them. To defend against such tricks, many repositories will generate warning and confirmation messages before accepting copies of works that lack delete rights or which assess charges or conditions to exercise this right.

Verify rights are used to authorize checking of the authenticity of a work. There are several different kinds of checking that can be performed. The simplest checks verify that the work is properly encrypted. Other checks involve the use of 1-way hash functions and other keys that can detect tampering with a work. Other checks can consider hot-lists of rogue works maintained by the trusted system. Reference copies of a work may be available on the network. Local copies can be carefully compared with reference copies to verify their authenticity.

Since a verifying system has access to the contents of a digital work, publishers can require that the system be certified. To protect against "rogue verifiers" that copy works under the guise of checking them or that damage works, publishers may specify that particular kinds of verifiers be used, such as certified verifiers on well known on-line servers.

</Certificate></Verifier></Verify>

Backup grants the right to make copies of a work for the purpose of guarding against the loss of the original due to accident or catastrophic media or equipment failure. The backup operation creates an encrypted copy of a digital work, which is in a form where it cannot be rendered without first exercising a restore operation. The optional BackupCopyRights is used to specify the rights on the encrypted backup copy. Typically, Transfer and Restore rights would be given on a backup copy. If no backup copy rights are given, the default right is to restore the copy. Backup copy rights are not the same as the rights that will be available when the backup copy is restored. The rights on the restored copy are the same as the rights on the original before the backup was made.

A restore operation converts an encrypted backup copy into a usable copy in a controlled manner. Restore rights typically elaborate various fees and conditions that balance the interests of the copy owner with the interests of the publisher.

</Access></Transfer>

</Ticket></Fee>

</Restore>

</Monetary></Fee>

</Restore>

</Certificate></User>

</Access>

</Restore>

</RightsList>

</ReferencedRightsGroup>

</Access></Play>

</Access></Transfer>

</RightsList>

</RightsGroup>

Here is an example of Backup and Restore rights. The reference rights group named "Safety-Net" includes a transfer right and three restore rights with different fees and conditions. All of the restore rights require that the repository have security class 3. One of the restore rights requires no monetary fee but uses a particular digital ticket. This approach could be used by a publisher who grants a limited number of free restorations controlled by a set of digital tickets. The second restore right costs a flat fee of $15. The third restore right is free, but requires a particular distributor’s license.

The second rights group called "regular" elaborates rights for normal use, including play, delete, transfer, and backup. The backup copy rights are those in the "SafetyNet" rights group. The next example expresses the same rights groups somewhat more simply by using Bundle specifications.

</Bundle>

</Access></Transfer>

</Ticket></Fee>

</Restore>

</Monetary></Fee>

</Restore>

</Certificate></User></Access>

</Restore>

</RightsList>

</ReferencedRightsGroup>

</Access></Bundle>

</RightsList>

</RightsGroup>

2.2.5 Configuration Rights

Configuration rights govern the adding and removing of system software from highly secure repositories. These rights are not relevant on platforms where the loading of software is not controllable.

The design goals for configuration rights are as follows:

• To provide a means to load software that insures that it is certified, has not been tampered with, and is compatible with the repository.

• To arrange that a user installing and uninstalling repository software in the field has security on the same order as when software is installed in a secure facility.

Because general purpose computers have other means for loading and deleting software, configuration rights are most relevant to dedicated, high security repositories. Typically, the control offered by configuration rights on secure repositories is most useful when adding software for a new player or editor.

<!ELEMENT Install (Comment?, Time?, Access?, Fee?)>

<!ELEMENT Uninstall (Comment?, Time?, Access?, Fee?)>

There are two kinds of configuration rights: Install and Uninstall. As with all other rights, these rights also have an optional comment, time, access, fee specification. An Install operation makes software runnable on a repository. Just copying a program to a repository does not make it runnable. The installation operation checks that software is certified, that it has not been tampered with, and that it is compatible with the repository. If these conditions are satisfied, the install operation links the software into the secure software procedures of the repository.

The Uninstall operation removes software from the running system. Uninstall does not delete the file corresponding to the program. It merely disables it from running, restoring it to the state before it was installed.

2.3 Specifying Times

Usage rights are usually granted for a specified period of time. The time period over which a right is granted is indicated by a time specification. To honor time specifications, a trusted system must have accurate and tamper-proof clocks.

The language design goals of the time specifications are:

• To express time limits that govern when rights become available and when they cease to be available.

• To express the categories of time blocks that are useful for governing commercial use of digital works.

• To describe contiguous periods of time, periods of time that do not start until a work is first used, and accumulative amounts of time that need not be contiguous.

• To provide unambiguous specifications suitable for international commerce and commerce across time zones.

Time specifications use representations of moments in time and units of time. The next two sections describe representations for moments and time units. We then discuss time specifications for usage rights that use these representations to indicate when the rights are valid.