ContentGuard Technology

[This local archive copy is from the official and canonical URL, http://www.contentguard.com/Techmenu.htm; please refer to the canonical source document if possible.]

Technology ContentGuard incorporates several key technologies to facilitate e-commerce of digital content and preserve adherence to copyrights. These technologies can be grouped in 3 areas: rights specification, rights protection and rights tracking.

Rights specification is accomplished by utilizing The Digital Property Rights Language (DPRL). DPRL is a computer-interpretable language, developed at the Xerox Palo Alto Research Center. 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.

Rights protection is accomplished through Self Protecting Documents (SPD). A Self-Protecting Document (SPD) is an active document that preserves its confidentiality and integrity, and enforces rights associated with the document through the Rights Management Process. Any document can be converted to an SPD.

Document tracking is accomplished through server-side components and services interacting with SPDs for usage tracking or permission renewal. These services, including rights specification and document protection, form the Xerox Rights Management Framework. This framework provides an integrated core from which developers can implement rights management applications. It also insulates developers from the evolving rights management technologies and the consequent implementation changes that result from it.

The Digital Property Rights Language (DPRL) is a computer-interpretable language, developed at the Xerox Palo Alto Research Center under the leadership of Mark Stefik. 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.

One of the goals of DPRL in digital property rights is to develop an approach and language that can be used throughout the publishing industries and other industries as well. 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.

DPRL 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. 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.

DPRL is used to specify fees, terms and conditions governing the use of digital content. DPRL is extremely flexible and supports multiple business models and rights protection policies, giving publishers the flexibility they need for their current and future businesses. DPRL supports multiple pricing models: subscription-based, outright purchase, purchase of individual rights (view, print, copy, edit, etc.), metered usage, time-based usage, and membership pricing.

DPRL defines syntax for specifying rights for a digital document. Rights such as "play," "print," "copy," "edit," etc. can be grouped into named "rights groups."

Each right within a rights group is associated with a set of conditions. Conditions can be of different types such as: fee to be paid, time of use, type of access, type of watermark, type of device on which the operation can be performed, and so on. Different groups of rights can be applied to various parts of a document using a "work" specification. Within a work specification, different sets of rights applicable to this work are specified.

DPRL allows different categories of rights:

Transfer 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 making and restoring backup copies.
Finally, configuration rights refer to the installation of software in repositories.

DPRL is the mechanism by which rights associated with digital property are expressed and specified. However, DPRL is not a document protection technology. Protection of content integrity and the persistent control of digital property rights is accomplished through the use of The Xerox Self Protecting Document (SPD) [Link].

DPRL is described in more technical detail in the December 1998 issue of Dr. Dobb's Journal.

D o w n l o a d D P R L M a n u a l

For specific uses of DPRL, the Digital Property Rights Manual is available. It 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.

A Self-Protecting Document (SPD) is an active document that preserves its confidentiality and integrity, and enforces rights associated with the document. Any document can be converted to an SPD.

SPD contains the encrypted content, rights associated with it, watermarks, usage policies and a set of controls that travel along with the document in the form of Java applets. Proven cryptographic algorithms ensure complete protection during rendering by converting a document to the rendered form in various stages; thus, intercepting the document at any stage will not yield a usable form of the document.

To strengthen the encryption mechanism, the SPD is customized according to the user’s credentials, the rights purchased for a given document, and the environment in which the document is rendered. Further, only those rights purchased by the user may be exercised by the SPD. Before rendering, the SPD ensures proper usage of rights by interacting with the Rights Tracking Server and allowing only those rights that are valid. Any unauthorized or invalid operations attempted by the user are denied.

The SPD may interact with a rendering application to securely render the encrypted document, thereby enforcing the publisher’s rights throughout its usage. While the SPD has the ability to render itself both to a screen and to a printer, its design allows integration with existing rendering applications to incorporate rights management technologies in them. Rendering applications such as Microsoft Office, Adobe Acrobat, Lotus Notes and others can be enhanced with SPD and trusted rendering capabilities.

The controls (also referred to as SPD Controls) help enforce rights, generate the appropriate keys to decrypt the content, interact with online supporting services for authorization, tracking, etc., and interact with trusted rendering applications to render the content, whether to screen or to printer.

An SPD that is created by the publisher is referred to as the generic SPD. Before making it available to an end user, the SPD is customized for a specific user using his credentials and the permissions acquired by him for this document. This is referred to as a customized SPD.

In its lifecycle, a document undergoes the following transformations:

SPD Preparation – in which an original document is converted to an intermediate format called the Rights Protected Format (RPF).

SPD Creation – in which a generic SPD is created from RPF (or original content, depending on the packaging policy), rights, watermarks and policy data.
SPD Customization – in which a customized SPD is created. In this case, the generic SPD is customized with the user’s credentials and permissions acquired by the user for this document.
SPD Usage – in which the customized SPD is polarized and used on an end-user’s machine.

R i g h t s M a n a g e m e n t P r o c e s s i n S P D

The diagram below illustrates the rights management process through a collaboration diagram that depicts interactions among the various SPD control components. The following model depicts the path followed during the execution of a requested operation. In this case, we see a request from the rendering application for the view operation. The SPD Controls routes the request to the SPD Permissions Object by calling on its authorize method, which in turn drives the authorization process. What is returned is an update Data Authorization Table (DAT) object. At this point, the spdAuditor’s authorize method is invoked with the DAT and subsequently the ASN.1 form of the DAT is sent across to the Rights Services Gateway. Once the Rights Services Gateway has validated the conditions of the requested permission, it returns to the SPD an Authorization Token containing the needed information to commence the operation. Using that token, the SPD Enforcer decrypts the SPD’s contents and generates a SPD Usage Object returning it to the SPD Control that returns it to the Rendering Application.