DPRL Manual
`
`The Digital Property Rights Language
`Manual and Tutorial - XML Edition
`
`Version 2.00 — November 13, 1998
`
`Copyright © 1998-1999 Xerox Corporation. All Rights Reserved.
`
`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 *
`
`http://xml.coverpages.org/DPRLmanual-XML2.html
`
`10/8/2014
`
`Petitioner Apple Inc. - Exhibit 1029, p. 1
`
`

`
`DPRL Manual
`
`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 *
`
`http://xml.coverpages.org/DPRLmanual-XML2.html
`
`10/8/2014
`
`Petitioner Apple Inc. - Exhibit 1029, p. 2
`
`

`
`DPRL Manual
`
`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
`
`http://xml.coverpages.org/DPRLmanual-XML2.html
`
`10/8/2014
`
`Petitioner Apple Inc. - Exhibit 1029, p. 3
`
`

`
`DPRL Manual
`
`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.
`
`http://xml.coverpages.org/DPRLmanual-XML2.html
`
`10/8/2014
`
`Petitioner Apple Inc. - Exhibit 1029, p. 4
`
`

`
`DPRL Manual
`
`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.
`
`http://xml.coverpages.org/DPRLmanual-XML2.html
`
`10/8/2014
`
`Petitioner Apple Inc. - Exhibit 1029, p. 5
`
`

`
`DPRL Manual
`
`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
`
`http://xml.coverpages.org/DPRLmanual-XML2.html
`
`10/8/2014
`
`Petitioner Apple Inc. - Exhibit 1029, p. 6
`
`

`
`DPRL Manual
`
`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)+>
`
`http://xml.coverpages.org/DPRLmanual-XML2.html
`
`10/8/2014
`
`Petitioner Apple Inc. - Exhibit 1029, p. 7
`
`

`
`DPRL Manual
`
`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:
`
`<a d="something"/> or <a d="something"></a>
`
`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 "<!--" and ends 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
`
`http://xml.coverpages.org/DPRLmanual-XML2.html
`
`10/8/2014
`
`Petitioner Apple Inc. - Exhibit 1029, p. 8
`
`

`
`DPRL Manual
`
`<b>
`
`<a d="data">
`
`<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+)>
`
`http://xml.coverpages.org/DPRLmanual-XML2.html
`
`10/8/2014
`
`Petitioner Apple Inc. - Exhibit 1029, p. 9
`
`

`
`DPRL Manual
`
`<!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.
`
`http://xml.coverpages.org/DPRLmanual-XML2.html
`
`10/8/2014
`
`Petitioner Apple Inc. - Exhibit 1029, p. 10
`
`

`
`DPRL Manual
`
`<?XML version="1.0" encoding="UTF-8"?>
`
`<!DOCTYPE Work SYSTEM "work.dtd">
`
`<Work>
`
`<RightsVersion version-id="2.00"></RightsVersion>
`
`<WorkId work-id="ISDN-1-55860-166-X; AAP-2348957tut"></WorkId>
`
`<Description>"Title: 'Zuke-Zack, the Moby Dog Story' Author:'John Beagle' Copyright 1994 Jones Publishing"
`</Description>
`
`<Owner>
`
`<Certificate>
`
`<Authority authority-id="Library of Congress"></Authority>
`
`<PropertyPair name="ID" value="Murphy Publishers"/>
`
`</Certificate>
`
`</Owner>
`
`<Parts>
`
`<WorkId work-id="Photon-Celebshots-Dogs-23487gfj"></WorkId>
`
`<WorkId work-id="Dog-Breeds-Chart-AKC"></WorkId>
`
`</Parts>
`
`<Contents from="1" to="16636"/>
`
`<Comment>"Rights edited by Pete Jones, June 1996."</Comment>
`
`<RightsGroup group-name="Regular">
`
`<Comment>"This set of rights is used for standard retail editions."</Comment>
`
`<Bundle>
`
`<Time><Until yyyy="1998" mm="01" dd="01" sec="1"/></Time>
`
`<Access>
`
`<Security name="Protocol" value="5"/><Security name="Physical" value="6"/>
`
`</Access>
`
`<BundleFee><BundleMonetary><Account>
`
`<AccountTo account-id="123456789"/>
`
`http://xml.coverpages.org/DPRLmanual-XML2.html
`
`10/8/2014
`
`Petitioner Apple Inc. - Exhibit 1029, p. 11
`
`

`
`DPRL Manual
`
`<House clearing-house-id="Visa"/>
`
`</Account></BundleMonetary></BundleFee>
`
`</Bundle>
`
`<RightsList>
`
`<Play>
`
`<Fee><Monetary><MeteredFee>
`
`<Rate value=".05"/><Per hours="1"/><By seconds="1"/>
`
`</MeteredFee></Monetary></Fee>
`
`</Play>
`
`<Print>
`
`<Printer>
`
`<Certificate>
`
`<Authority authority-id="DPT"></Authority>
`
`<PropertyPair name="Type" value="TrustedPrinter-6"/>
`
`</Certificate>
`
`</Printer>
`
`<Watermark>
`
`<Watermark-Str string="Title: 'Zeke Zack the Moby Dog' Copyright 1994 by Zeck Jones. All
`Rights Reserved."/>
`
`<Watermark-Tokens all-rights="false" render-rights="true"/>
`
`<Watermark-Str string="Title: 'Zeke Zack the Moby Dog' Copyright 1994 by Zeck Jones. All
`Rights Reserved."/>
`
`</Watermark>
`
`<Fee><Monetary><PerUse value="10"/></Monetary></Fee>
`
`</Print>
`
`<Transfer></Transfer>
`
`<Copy>
`
`<Fee><Monetary><PerUse value="10"/></Monetary></Fee>
`
`</Copy>
`
`http://xml.coverpages.org/DPRLmanual-XML2.html
`
`10/8/2014
`
`Petitioner Apple Inc. - Exhibit 1029, p. 12
`
`

`
`DPRL Manual
`
`<Copy>
`
`<Access>
`
`<User>
`
`<Certificate>
`
`<Authority authority-id="Murphy Publishers"></Authority>
`
`<PropertyPa