Channels ▼
RSS

Database

Digital Content & Intellectual Property Rights

Source Code Accompanies This Article. Download It Now.


Dec98: Digital Content & Intellectual Property Rights

The authors are researchers at Xerox Palo Alto Research Center in California. They can be contacted at arunr@cp10.es.xerox.com and prasad@cp10.es.xerox.com, respectively.


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 the work without having authorization or providing compensation. Content owners are concerned about unauthorized use and uncontrolled distribution of their digital content. The threat of potential loss in compensation has resulted in nonavailability of high-valued documents to Internet users.

Users lack convenient mechanisms to compensate intellectual property owners for the use of their content; they lack widespread access to high-valued digital content and are wary about compromises to their privacy while interacting with online distributors of digital goods and services. The issues of protecting the intellectual property rights of content owners and ensuring the privacy of users while providing them with convenient access to documents is the subject of intellectual property rights management (IPRM).

The inadequacy of current business models and legal infrastructure to enforce intellectual property rights during the distribution and use of intellectual assets has prompted the development of technologies to assist in dealing with this problem.

Several solutions exist to combat intellectual property rights violations. These solutions range from automated systems that enable tracking, to secure container technologies that enforce content owners' rights during delivery, and subsequent to delivery, manage the property rights. At Xerox Palo Alto Research Center, we've been working on projects that have resulted in a set of technologies that protect content owners' rights by facilitating as well as enforcing compliance with terms and conditions associated with the usage of the document. These technologies provide end-to-end solutions for document distribution and use, and enable a wide variety of rights-managed consumer applications that involve the distribution and use of digital documents.

Three distinct capabilities are necessary to support different requirements for IPRM:

  • Publishers should be able to specify and associate rights using uniform syntax across different contracts and file formats. Consumers should be able to access the rights labels, understand the terms, conditions, and fees associated with the different uses of a document.
  • Rights associated with the documents and the specific permissions granted to individual users of the document need to be tracked and enforced. This capability facilitates the compliance of rights and permissions through the notification of events that are triggered by the violation of rights, and enables enforcement of the permissions purchased by the user by restricting operations to those for which permissions have been granted.
  • During viewing or printing of a document, it is possible for the content owners' rights to be compromised by revealing a useful form of the document during the various transitions (of content) in the rendering process. Trusted Rendering should ensure protection of content owners' rights during rendering while honoring the permissions granted to the users.

In this article, we'll address how rights can be specified and enforced on digital documents. To illustrate, we'll use the Xerox Digital Property Rights Language (DPRL), a specification language designed to support electronic commerce in digital works -- that is, publishing and selling electronic books, digital movies, interactive games, computer software, and the like. DPRL 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. DPRL rights enforcement is achieved using Xerox Self-Protecting Documents (SPD) and related rights technologies. The DPRL specification (Version 1.08) and details on SPD are available from the authors.

Digital Property Rights Language

The Xerox Digital Property Rights Language is a language that can be used to specify rights for digital works. It provides a mechanism in which different terms and conditions related to access, fee, and time can be specified and enforced for the different operations on digital documents, such as view, print, and copy. Rights specifications are represented as statements in DPRL.

Different rights can be specified for different parts of a digital work using a work specification. Within a work specification, different sets of rights applicable to this work are specified. Rights can be grouped into named-groups called "rights groups." Each right within a rights group is associated with a set of conditions. Conditions can be of different types: 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. 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.
  • Configuration rights refer to the installation of software in repositories.

Listing One (listings are located at the end of this article) illustrates a work specification in DPRL having one rights group called "Regular," which specifies rights for standard retail editions of a book titled "Zuke-Zack, the Moby Dog Story." The work specification expresses conditions for several rights: play, print, transfer, copy, delete, backup, and restore. The work in the listing includes two other parts -- a photograph and a chart of breeds incorporated from other sources. A bundle specification bundles a set of common conditions that apply to all rights in the group. This specification states that all rights in the group are valid until January 1, 1998 and that the fee should be paid to account "Jones-PBLSH-18546789." The clearing-house for this transaction should be Visa. The following contract applies:

  • The work can be played by paying U.S.$1.00 every hour, where fee is accumulated by the second.
  • The work can be printed on TrustedPrinter-6, which is certified by DPT for a fee of U.S.$10.00 per print. The printed copy should have a watermark string (as depicted) and a list of tokens signifying fingerprint information known at the time it is printed.
  • This work can be copied either by paying U.S.$10.00 or by acquiring a distributor certificate from Murphy publishing.
  • Unrestricted transfer, deletion, or backing up of this work. Restoration costs U.S.$5.00.

Enforcing Rights and Conditions

Enforcement of the rights specified in DPRL during distribution and use of documents on a consumer's machine is a complex problem. The problem is hard because of open systems and networks, lack of common document formats, and rendering devices that have no protection capabilities. Xerox's SPD technology addresses the content-protection problem. SPD is an active document object that preserves the confidentiality and integrity of the document while at the same time enforcing publishers' rights as specified in DPRL. An SPD contains the encrypted content, rights label, watermarks, and active controls (referred to as "SPD Controls") that control document usage. SPD utilizes infrastructure services such as authorization (to verify access conditions associated with rights) and tracking (to track usage of rights). A rights label is the DPRL rights specification and metadata describing the document, publisher, and other related information.

Different levels of protection can be provided within SPD depending on the publisher's requirements. SPD achieves this protection by decrypting content at the time of rendering, such that capturing any intermediate state of the document does not result in compromising intellectual property.

Publishers specify rights and watermarks, and convert the original documents to SPDs. Consumers purchase a subset of permissions associated with the SPD. Publishers have all rights over the document, while consumers acquire permissions to use the document according to the specified terms and conditions.

Figure 1 depicts the structure of an SPD, which contains:

  • The rights label, which includes the DPRL rights and metadata.
  • The watermark specification, which includes the watermark contents and details on how the mark is to be merged with content during rendering.
  • Policy information, which dictates the kind of authentication, security, tracking, and notification mechanisms employed by this SPD, and the behavior of the SPD to user events.
  • SPD controls, which perform rights verification and enforcement, and interact with the SPD secure rendering engine to render content securely.
  • An SPD secure viewer, which is a Java applet that securely transforms the encrypted content to presentation data.

SPD Lifecycle

During its lifecycle, a document undergoes four stages of transformation:

1. SPD Preparation, in which the original document is converted to an intermediate format. This format is such that the transformation of the document from one encrypted form to another can be performed efficiently.

2. SPD Creation, in which a generic SPD is created using the intermediate form of the document, and the rights, watermark, and policy specification.

3. SPD Customization, in which the generic SPD is transformed to a customized SPD using the end-user credentials and the set of permissions acquired for this document.

4. SPD Usage, in which the SPD is securely rendered on screen or printer. Additional transformations of the document can happen at this stage depending on the level of security chosen for the SPD.

Generic SPD creation (see Figure 2) is typically under the control of the publisher. The customized SPD (see Figure 3) is specific to a particular consumer and the permissions purchased by him. During SPD creation, rights specified in the label are parsed, and the SPD is generated such that only those operations specified in DPRL are applicable to this SPD. During customization, the conditions associated with rights are extracted, verified if necessary, and placed in the customized SPD. A proxy-encryption mechanism transforms the SPD from one encrypted form to another (for more information, see "Public and Non-commutative Proxy-Encryption Schemes," Xerox Corp., 1998; available from the authors). This ensures confidentially during the transfer of SPDs between different parties -- publisher to distributor to retailer to consumer -- with rights protection at each stage.

SPD Usage

On the consumer's machine, the customized SPD can be rendered either in the browser or in a secure window. Figure 4 illustrates the SPD usage process. Suppose the consumer performs a view operation on the SPD. User authentication is performed with the user name and password. The underlying authentication scheme could be password based or public-key based. The rights-enforcement module of SPD verifies the conditions associated with the view. Conditions could be fee, time, access, watermark, or other conditions. Access condition is specified in the form of a list of certificates that the consumer should possess. Certificate verification can be done locally or online with a Rights Authorization Server. In Listing One, copies of the SPD can be made only by a valid distributor, which is proven if the SPD can successfully verify a Distributor digital-certificate issued by the certificate authority called "Murphy Publishers."

Depending on the level of security, the authorization server returns the verification status, or a key that is used during rendering for successful decryption of content. After satisfactory verification of conditions, a preaudit is performed where the SPD logs verification status to a tracking service (online or offline). The content is securely rendered on to the screen (details on secure rendering are provided in the next section). After rendering, a postaudit is performed in which the status of usage is updated with the tracking service.

Rights labels can be stored within the SPD or they can be stored on a label server. In the latter case, the SPD has a pointer to the label (instead of the label itself). DPRL, SPD, and supporting services such as rights labeling, authorization, and tracking, provide a mechanism for specifying and enforcing rights associated with digital documents.

SPD Rendering

SPD employs a trusted rendering mechanism in which the encrypted content is transformed to presentation data in different stages, such that capturing the stream at any intermediate stage does not provide a useful form of the document. Trusted rendering involves three steps:

1. Polarization, which transforms the encrypted content in the SPD into another state-dependent encrypted or encoded form. The state refers to a random value determined at the time of rendering and is specific to the device on which rendering occurs.

2. Rendering, which renders the polarized content into polarized presentation data. This data can be presented to a display device, but the contents are encrypted and polarized.

3. Depolarization, which transforms the polarized presentation data produced by the rendering engine into the final viewable form of the document. The depolarization step uses the same state that was used during polarization.

Polarization ties the polarized SPD to the current session and the device on which it is being rendered. Capturing the SPD at this stage does not yield a useful form of the document for redistribution. Higher levels of security can be achieved by performing additional proxy-transformations of the encrypted content during polarization and depolarization. Furthermore, the depolarization engine can be tightly coupled with the device-level rendering engine to provide better security.

Supporting Services

SPD utilizes supporting services to enable label management, authorization, and tracking SPD usage. Supporting services include the Rights Labeling Service, Rights Authorization Service, and Rights Tracking Service. The SPD control engine interacts with these services to verify and enforce rights specified in DPRL. Access conditions specified in DPRL are enforced by SPD Control using the Rights Authorization Service. SPD tracks usage of permissions, payment, and expiry conditions (as specified in DPRL) using the Rights Tracking Service. Rights labels associated with an SPD are either embedded within the SPD or acquired from the Rights Labeling Service.

Rights Labeling. The Rights Labeling Service includes systems that help in associating rights specified in DPRL with digital content and managing rights labels in a distributed environment such as the Internet. The Rights Labeling Service offers: creating a rights label, hosting labels in an online repository, allowing browsing/querying/retrieval of labels by Internet-based software agents and users, updating labels, renewing labels, revoking labels, and verifying label integrity. SPDs contain either the rights label or a pointer to the rights labels on the labeling server. Publishers can use this service to specify, publish, and update rights labels.

Rights Authorization. The Rights Authorization Service provides capabilities to enable access controls specified in DPRL. DPRL lets publishers specify a set of certificates in the "access" condition associated with a right. The access specification includes a list of certificates that the SPD control engine should verify during usage. The certificates are verified through the rights authorization service. The Rights Authorization Service provides: creation and issue of different types of certificates (identity, membership certificates, and so on), certificate retrieval, certificate verification, group and membership creation, membership cancellation and certificate revocation, and key-based authorization for SPDs. Publishers can use the rights authorization server to establish groups and associate membership conditions with the groups. Distributors, retailers, or end-consumers can become members of these groups by satisfying the membership condition -- a payment for a specified time period. A membership certificate (X.509v3), which can be used during authorization verification in the SPD, is issued to member. These certificates can also be hosted on the authorization server.

Rights Tracking. The Rights Tracking Service allows an SPD or other publisher/consumer applications to track usage of permissions, time-validity, payment, and authorization information specified in DPRL. Permissions usage refers to the number of permissions used by the consumer. Tracking time-validity involves ensuring that the given permission is exercised only in the time-window allowed for it. Tracking payment information involves ensuring that payment for a particular permission has been credited to the publisher's account. The tracking server may also have to interact with other services, such as a network time service or payment service.

Rights-Management Platform

Rights management involves specifying and associating rights with a document, placing controls on the document to enforce rights, enabling access checks, and tracking permissions usage and payment. In particular, the following capabilities are required:

  • Rights specification and rights label management.
  • Content protection, rights enforcement, and trusted rendering.
  • Rights authorization.
  • Rights tracking.
  • Security and commerce infrastructure.

A variety of technologies and software (or hardware) systems are required to provide full-fledged IPRM capabilities. Different transactions occur between entities during document creation, distribution, and use. Managing rights in all of these transactions is necessary. Document creation involves rights specification, labeling, and protection. Document distribution involves rights authorization, tracking, and label management. Rights enforcement and secure rendering happen during document usage.

The Xerox Rights Management Platform, which we have defined, includes a set of products and services that support rights-enabled transactions. The platform elements help manage rights associated with documents in these transactions. The products and services defined in the platform include:

  • A rights editor, watermark editor, and SPD generator for rights specification, watermarking, and SPD creation.
  • A rights-labeling server, rights-tracking server, and rights-authorization server. These servers provide online support for rights label management, tracking, and authorization.
  • A Rights Management Kit (RMK), which consists of a set of toolkits. The toolkits help incorporate IPRM capabilities into various applications.

Listings Two and Three illustrate the use of these toolkits to create a protected document, in this case a Microsoft Word document using the Rights Management Toolkits. This example demonstrates the creation of a rights specification and a generic SPD using the rights parser, SPD preparation, and SPD creation toolkits. The example is broken into a two-step process: rights creation and SPD creation.

The native document used here is a Microsoft Word document and the system on which the SPD is being created is assumed to have a Java virtual machine and the Microsoft Word rendering application. The rights and conditions to be specified are:

  • Unlimited view for a flat-rate of U.S.$10.00.
  • Pay U.S.$5.00 per print in the year of 1999.

Listing Two illustrates rights creation using Parser Toolkit (Java). Listing Three shows SPD creation using the SPD Preparation (C++) and SPD Creation Toolkits (C++). (The customized SPDs can be delivered in the form of an executable or a JAR file.) The toolkits provide a base on which various end-user applications can be built; an online digital document store for vending SPDs, for example. Different applications have different rights-management requirements and may selectively incorporate the necessary capabilities.

Conclusion

Copyright documents account for 6 percent of GDP -- third only to agriculture and aerospace. Digital content is projected to be the largest component of electronic commerce. The number of users relying on the Internet for their information needs is growing exponentially. Technologies such as secure communication, digital property rights management, and electronic payment are in place to complement business models and legal infrastructure to make electronic document commerce a reality.

Rights management involves both rights specification and enforcement. Xerox has developed a rights-management platform that defines a set of products and services for the IPRM of digital documents. DPRL, SPD controls, and other supporting services such as rights labeling, authorization, and tracking help in managing rights associated with digital works by enabling rights specification and enforcement. The platform provides a base on which to build applications that allow protected distribution and use of digital content. Integrating the rights-management technologies with various applications is performed through the Xerox rights management platform.

DDJ

Listing One

 (Work:    (Rights-Language-Version: 1.02)
    (Work-ID: "ISDN-1-55860-166-X; AAP-2348957tut")
    (Description: "Title: 'Zuke-Zack, the Moby Dog Story'  
        Author: 'John Beagle'  
        Copyright 1994 Jones Publishing")
    (Owner:  (Certificate:
            (Authority: "Library of Congress")
            (ID: "Murphy Publishers")))
    (Parts: "Photo-Celebshots-Dogs-23487gfj"  "Dog-Breeds-Chart-AKC")
    (Comment: "Rights edited by Pete Jones, June 1996.")
    (Contents: (From: 1) (To: 16636))  


</p>
    (Rights-Group: "Regular"
    (Comment: "This set of rights is used for standard retail editions.")
    (Bundle: 
    (Time: (Until: 1998/01/01 0:01))
        (Fee: (To: "Jones-PBLSH-18546789")(House: "Visa")))


</p>
   (Play:
        (Fee: (Metered: (Rate: 1.00 USD) (Per: 1:0:0) (By: 0:0:1)) ))
    (Print:  
        (Fee: (Per-Use: 10.00 USD))
        (Printer:  
            (Certificate: 
                (Authority: "DPT"
                (Type: "TrustedPrinter-6"))) 
        (Watermark: 
            (Watermark-Str: "Title: 'Zeke Zack - the Moby Dog' 
                        Copyright 1994  
                                by Zeke Jones.  
                                All Rights Reserved.")
            (Watermark-Tokens: user-id institution-location 
                           render-name render-time)  )))
    (Transfer: )
    (Copy:  (Fee:   (Per-Use: 10.00 USD) ))
    (Copy: (Access: 
            (User:  (Certificate:
                    (Authority: "Murphy Publishers")
                    (Type: "Distributor")))))
    (Delete:) 
    (Backup:) 
    (Restore:   (Fee:   (Per-Use: 5.00 USD))) ))

Back to Article

Listing Two

1. The rights specification engine is instantiated. A default work with a rights group is established.

</p>
UsageRights rgtEngine = UsageRights.getInstance();
Work work = rgtEngine.createWork("Work-ID-001235");
IRightsGroup rgtGroup = work.createRightsGroup("My Group");

2. The View right is added to the rights group and a $10.00 US flat-rate fee conditions is specified for the right. This amount is to be credit to the publisher's account "PUB-BA-00234".

IRight viewRgt = rgtGroup.addRight(IRight.VIEW);
IFeeSpec feeSpec = viewRgt.createFeeSpec();
feeSpec.setFlatFee(10.00, Currency.USD);
feeSpec.setAccount("PUB-BA-00234");

3. The Print right is added to the rights group. A $5.00 US pay-per-use fee condition and a fixed interval time-condition are specified for the right.

IRight printRgt = rgtGroup.addRight(IRight.PRINT);
IFeeSpec feeSpec2 = printRgt.createFeeSpec();
feeSpec2.setFee(5.00, Currency.USD);
feeSpec2.setAccount("PUB-BA-00234");

4. The rights specification is saved in an output file.

rgtEngine.save("c:\\docs\\mydoc\\example.rgt");

Back to Article

Listing Three

1. Instantiate the SPD preparation engine, which is part of the SPD preparation toolkit. Make a preparation request. The preparation engine uses the SPD Device Driver and generates a set of RPF pages from the native document. The RPF pages are placed in the target directory (say, c:\docs\mydoc). The native document name is "example.doc".

SPDPrepKit prepEngine = new SPDPrepKit();
PrepEngine->preparationRequest("c:\\docs\\mydoc\\example.doc",
                              "c:\\docs\\mydoc\\");

2. Instantiate the SPD creation engine, which is part of the SPD creation toolkit. Set the engine properties such as the source directory (c:\docs\mydoc) that contains the set of RPF files, and the destination directory (say, c:\doc\myspd) where the generic SPD will be created.

SPDCreateKit createEngine = new SPDCreateKit();
CreateEngine->setProperty(SPD_TEMPLATE_DIRECTORY, "c:\\docs\\mydoc\\");
createEngine->setProperty(SPD_TARGET_DIRECTORY, "c:\\docs\\myspd\\");

3. Make an SPD creation request using the rights file created above. Note that if watermark and policies are not specified, the SPD will be created with default policies and no watermark. The default policies include password authentication, no tracking, simple text-based notification of permission information, and no tracking. Note that the RPF files in the source (or template) directory are identified using the original document's name.

CreateEngine->create("example",
              "c:\\docs\\mydoc\\example.rgt", POLICY_DEFAULTS);

4. The generic SPD (a binary file) is created in c:\docs\myspd.

Back to Article


Copyright © 1998, Dr. Dobb's Journal

Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video