throbber
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>
`

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket