Quick Table of Contents

1  Introduction

2  Simple Example Use Cases

3  Overview Example Use Case

4  Special Topics Example Use Cases

5  Third-party Examples

Full Table of Contents

1  Introduction

2  Simple Example Use Cases

    2.1 Simple License

    2.2 Simple License with Temporal Restriction

    2.3 Simple License for a Particular End-User

    2.4 Simple Certificate

3  Overview Example Use Cases

    3.1 Alice Can Play "When the Thistle Blooms"

    3.2 Leavy Library Specifies Its Policy for PDQ Records

    3.3 PDQ Records Specifies Its Policy for University Distribution

    3.4 USC's Members

    3.5 Universities May Issue PDQ Records' Group Ids

    3.6 USC is a University

    3.7 I Am PDQ Records

4  Special Topics Example Use Cases

    4.1  Unlimited Usage

    4.2  Limited Usage

    4.3  Preview or Promotional Model

    4.4  Tiered Pricing Model

    4.5  Pay Per View or Use

    4.6  Subscription

    4.7  Territory Restriction

    4.8  Temporal Ordering of Exercising Rights

    4.9  Component Based Model

    4.10  User Type Based Model

    4.11 Site Licenses

    4.12 Payment to Multiple Rights Holders

    4.13 Personal Lending

    4.14 Giving

    4.15 Superdistribution

    4.16 Distributor Copies

    4.17 Personal Copies

    4.18 Nested Revenue Model

    4.19 Accessing Web Service

    4.20 Software Execution

    4.21 Confidentiality of Rights

    4.22 Watermark and Content Fragments

    4.23 Secure Device

    4.24 Third-party Metadata

5  Third-party Examples

    5.1  Distance Learning

    5.2  Screen Saver Preview and Superdistribution

1 Introduction

This document provides examples of using the eXtensible rights Markup Language (XrML) to address various use cases and business models in the realm of digital rights management. It does not fully illustrate every aspect and feature of the language. For such fine details, you should consult the eXtensible rights Markup Language (XrML) 2.0 Specification.

The example use cases are divided into 4 sections.  The Simple Example Use Cases section shows some simple expressions to get you familiar with the XrML syntax and grammar.  The Overview Example Use Case section illustrates how to restrict the use of content to authorized use, and how to manage this use during the content life cycle.  The Overview Example Use Case is meant to be a walkthrough to help readers understand an entire life cycle of content and the XrML expressions associated with each step in that life cycle.  The Special Topics Example Use Cases section illustrates XrML's support for the flexible expression of different business models, which may change over time, markets, and geography. Some business models are envisaged to involve “super distribution”, in which content and rights to interact with it are passed along from one user to another.  Also included in this section are examples for web services and software business models.  Finally, the Third-party Examples section shows some XrML representations of example scenarios designed by third parties.

2 Simple Example Use Cases

This section starts with a very simple XrML license, and then augments it with additional constraints. Finally, it shows how XrML is used to specify a simple certificate.

2.1 Simple License

The following example shows how to create a simple license that specifies a right on a digital content.

2.2 Simple License with Temporal Restriction

The following example augments the previous example by restricting the exercise of the granted right to some time period.

2.3 Simple License for a Particular End-User

The following example augments the simple license in Section 2.1 by specifying a principal it is issued to.

2.4 Simple Certificate

The following example shows how to create a simple certificate signed by an issuer.

3 Overview Example Use Case

This section presents an example use case for the purpose of giving an overview of the complete set of XrML licenses that are required to make a system work.  However, since it would be quite difficult to digest this entire set at once, it will be built up in small parts starting with the end user license and working backward to see how this end user license came to be.  However, before we embark on this mission, let us take a look at the scenario we will eventually model in XrML.

PDQ Records has become a leading producer of digital songs.  Apart from its commercial sale of these songs, it also desires to make them available to university libraries.  In order to do so, it defines the terms university, library, student, faculty, and device and establishes a certification process whereby it allows for entities to be certified as a member of one of these groups.  PDQ Records then decides on the policy by which its songs may be used at the libraries: 1) libraries may allow any students or faculty to play one of the songs by PDQ Records and 2) libraries may allow anyone to play the songs by PDQ Records on its university devices.  A particular library decides to allow students to virtually "check out" songs for 3 weeks each, but no more than 5 times per semester.  Faculty, on the other hand, may "check out" songs for 6 months each, with no limit on the number per semester.  The same library also allows the songs to be played on its university devices.  A student decides to "check out" "When the Thistle Blooms" for 3 weeks.

3.1 Alice can Play "When the Thistle Blooms"

Lets start out with the simple license at the end of this PDQ Records scenario: the one that allows the student, Alice, to play "When the Thistle Blooms" for 3 weeks.  In the license below, Alice is represented by the key she holds (if you expand the inventory you will see the definition of that key).  The right given to Alice is the play right, and "When the Thistle Blooms" is a digitalWork defined by its metadata expressed in XML as an MPEG-21 DIDL.  A validityInterval condition constrains the time during which Alice can play the song to three weeks starting at the time when this license was issued to her.  The signature on the license is that of USC's Leavey Library.

3.2 Leavey Library Specifies Its Policy for PDQ Records

Leavey Library's policy for PDQ Records' songs is threefold:

1. Students may "check out" songs for 3 weeks each, but no more than 5 times per semester,
2. Faculty may "check out" songs for 6 months each, with no limit on the number per semester, and
3. Anyone can play the songs on university devices.

Each of these bullets is modeled in XrML as one grant.  Let us take a look at the first grant first.

In order to express the concepts of "any student", "any song", and "any 3 weeks starting from check out", the library needs to take advantage of XrML's rich pattern matching functionality.  This functionality is embodied in the four forAll elements at the top of the grant.  For now, don't be too concerned with the contents of the first two forAll elements: they will be explained in more detail in Section 3.4.  Instead, just know that the first forAll says "this grant applies to all universities" and the second forAll says "this grant applies to all students from those universities".

The third forAll element says that this grant applies to all songs published by PDQ Records.  This is accomplished by using an XPath expression that evaluates to true when evaluated in the context of a resource representing a song published by PDQ Records.

The fourth forAll element says that this grant applies to any three-week period that starts from the time the obtain right is exercised.  This is accomplished by using a special pattern that evaluates to true when evaluated in the context of a validityInterval condition whose duration is 21 days and whose start time is the current time.

After these four forAll elements, the statement the grant is making can be read.  In English, it reads "A student can obtain a grant (to play a song for three weeks) subject to an exerciseLimit per student."  The exercises remaining per semester is stored on the identified service.

The second grant is to faculty and looks very much like the grant to students.  The only differences are that the faculty have no exerciseLimit and have six months instead of three weeks.

The third grant allows anyone to play any song subject to the condition that the cpu on which it is run is a USC device.  In this grant you will notice two new forAlls: one called anyone and one called device.  If you expand the anyone forAll, you will notice that it is empty; this means that there are no restrictions on who can be anyone.  The device forAll functions in much the same way as student and faculty did; don't worry about the details at this time.

Also notable in this example is the fact that the obtain right is missing.  This is because the library has already granted anyone the right to play the song on any device: there is no "check out" process involved (as there was in the case of the student Alice, who got her own customized license).  Anyone can simply walk into the library, sit down at one of its devices, and listen to the song inside the library.

You may notice an empty allConditions element near the end of the grant.  This is simply an artifact resulting from the fact that the library had a choice to add additional conditions as children of this element but chose not to.

The three grants just described can be bundled together into one license that represents Leavey Library's policy for PDQ Records' songs.

3.3 PDQ Records Specifies Its Policy for University Distribution

PDQ Record's policy for university distribution is twofold:

1. Libraries may "check out" songs to any member of a PDQ group under any terms the library chooses, and
2. Libraries may prescribe the terms under which the songs may be played on any of its university's devices or it may chose not to give permission for them to be played on those devices.

Each of these bullets is modeled in XrML as one grant.  Let us take a look at the first grant first.

The English reading of the grant below is: "Any library (from university1) can issue to any member (with any identification from university2) the right to play (under any condition of the library's choosing) any song published by PDQ Records."

At this point, it might be instructive to go back up to Section 3.2 and take a look at the two grants the library issued to the students and faculty giving them the right to obtain the right to play any song.  Notice that the grants the students and faculty have the right to obtain make up a subset of the grants the library has the right to issue.  Further, looking back up at Section 3.1, you can see that the grant Alice received is actually authorized by this grant from PDQ Records to the library.  This grant says

"Any library can issue any member the right to play any song under any condition"

and Alice's grant says

"Alice can play 'When the Thistle Blooms' for three weeks."

"Alice" is "any member."  play is play.  "When the Thistle Blooms" is "any song."  "For three weeks" is "any condition."  Therefore, the library has correctly issued Alice's grant.

Now let us take a look at the second grant in PDQ Record's policy.  This grant allows the library to grant everyone the right to play any song by PDQ Records on any device from the same university.  How do we know that the device has to be from the same university?  Well, expand the node with varName library and the node with varName device.  You will notice that each of these nodes contains a reference to the same university variable.  This means that the library and device must both belong to the same university.

Now collapse those two forAll nodes again.  This time look at the two sets of forAll nodes: one set for the top-level grant, one set for the grant that the library is allowed to issue.  The reason these are split up is to differentiate which of them the library gets to pick and which the end user gets to pick.  The library "picks" itself, the university, and the condition.  The end user "picks" itself, the device, and the song.  Now recall the end of Section 3.2 where we saw an empty allConditions element; here you can see where that empty element came from: the library chose to add no conditions.  If you expand the device node again here and then expand the one at the end of Section 3.2, you will also see that what was the variable university here has become an actual keyHolder (USC) when issued by USC's Leavey Library.

3.4 USC's Members

In this section, we get to discover how certificates work.  Recall the following construct from an earlier section:

This is an example of the use of the everyone pattern.  It has two children: a resource and a trustedIssuer.  In both cases here the resource is an identification.  In the first case the trustedIssuer is PDQ Records (as identified by the key it holds).  In the second case the trustedIssuer is a university (identified by reference to the variable defining it).  The idea here is that at some point PDQ Records issued a certificate to each university designating it as a university.  The universities then issue certificates to the students in that university designating them as students.  The first everyone pattern matches a particular keyHolder (say USC's keyHolder identity).  The second everyone pattern also matches a particular keyHolder (say Alice's keyHolder identity).  The implication, then, is that Alice's keyHolder identity can be used wherever there is a varRef called student.

The next license shows what these certificates look like.  In particular, this license issued by USC designates Alice (identified by her key) as a student (until 11 May 2002), Bob (identified by his key) as a faculty (until 11 May 2002), Leavey (identified by its key) as a library (no time restriction), and a CPU (identified by the http://www.intel.example/pentium4 identification scheme) as a university device (for one year (until 5 Nov 2002)).

Notice that the last of these grants shows an identification of 7439201232 in the http://www.intel.example/pentium4 scheme.  Since an identification itself is not secure, to use this identification as a principal we must couple it with an authentication scheme (which in this case happens to be the same as the identification scheme).  An identification scheme only defines the valid values for the ids and any uniqueness constraints, for instance.  An authentication scheme defines the means by which one can authenticate the presence and participation of an identified entity.

3.5 Universities May Issue PDQ Records' Group Ids

While Leavey Library doesn't require proof that USC has the right to issue PDQ Records' group ids (because the license Leavey Library has identifies USC as trustedIssuer), USC might require proof that it is allowed to issue these group ids from PDQ Records' id scheme (http://www.pdqrecords.example/group).  PDQ Records grants universities the right to issue ids in the same manner that PDQ Records grants libraries the right to issue play rights.

Notice that the university picks the anyone, the group identification, and the condition.

3.6 USC is a University

In the same way that universities designate their members (students, faculty, libraries, and devices), PDQ Records designates who is a university.

3.7 I am PDQ Records

So far we have seen certificates using the identification element.  Certificates work in general with any resource that is a property.  The following license shows PDQ Records issuing a self-signed certificate whereby it claims to have the common name "PDQ Records" from the X.509 world.

4 Special Topics Example Use Cases

The examples shown is this section illustrate how XrML supports different business models.

4.1 Unlimited Usage (Pay an Upfront Fee)

This business model illustrates how to offer a price for unlimited usage of some content, both in terms of conditions and obligations, and in terms of a predetermined set of rights such as copy and print.

In this model, the consumer pays an upfront fee of $25.99 to obtain the rights to play, print, copy, and extract from an eBook with no further conditions.  The grantGroup specification ties together all the rights that can be obtained for $25.99. The fee payment is recorded at some Web service. 

4.2 Limited Usage

This business model illustrates how to establish a price for limited usage, both in terms of time, and in terms of other rights such as copy and print. The price can be extended to include other conditions.

This example uses web services to keep track of the stateful conditions.  One service records the time interval for the play right.  Another monitors the counter for the print right.  paymentFlat specifies a one-time fee. It is assumed that the initial time interval and counter are set properly at their respective Web services. 

4.3 Preview or Promotional Model

This business model illustrates how to provide a free preview of some portion of the content. The content may still be controlled with DRM systems (for their integrity), but be available at no cost to consumers. This business model may be used in combination with other business models for promotional content to build incentive based models.

In this example, the first grant allows anyone to play the first chapter for free.  The second grant specifies that anyone can play the entire book for a fee of $25.00 per use.  paymentPerUse specifies how much to charge each time the book is played.

4.4 Tiered Pricing Model

This business model illustrates how to provide different pricing levels based on the quantity of a work requested, the length of time to use a work, or the quality of different versions of a same work offered.

This example offers the following tiered pricing structures:

·         Pay $10 for each copy up to 10 copies, and $8 for each copy over 10 copies.

·         Pay a rate of $1 per day for playing a DVD movie for less than 5 days, and a rate of $.75 per day for more than 5 days.

·         Pay $2 for an image of low resolution, and $5 for the same image of high resolution.

The first pricing structure is depicted in the following example.  It can be modified properly to model the last two structures. The second is to be with the trackReport condition, requiring that the exercise of the print right be reported to a designated tracking service, and the third is to be with the trackQuery condition, which is satisfied only if the reported state is within the range specified in the trackQuery condition.

4.5 Pay Per View or Use

This business model illustrates how to specify a simple fee charged every time that a right is exercised; that is, the fee is charged on the per use basis.

Note in the following two examples, paymentPerUse specifies how much to charge each time a printed copy is made or the movie is played.

4.6 Subscription

This use case of XrML illustrates how to specify subscription-based business models for content consumption. This use case addresses the issues of how to offer different subscription options via granting the right to obtain rights for consuming content (in different grants), and how to issue subscription licenses that can be used with individual content licenses for content consumption.

In the following example, an online eBook distributor (ebook.com) offers two subscription options to anyone for viewing any eBook it distributes. In order to become a subscriber, one has to pay a rate of $100.00 per year or a rate of $10.00 per month. Once becoming a subscriber, one will receive a subscription license. An eBook can be viewed by any subscriber who possesses a valid subscription license. 

There are four types of licenses used in this example. 

First, the distributor makes the following subscription offer that contains the two pricing options.  Anybody who pays for one of the offers becomes a subscriber and will get a subscription license.

Alice payed the $100.00 fee for a year subscription and gets the following subscription license.  The license grants her the right to play any ebooks from ebook.com for a year starting from 01/01/2001.

When an ebook is available, the following generic license is associated with it. This license allows anyone with a valid subscription license to play the ebook or download for offline reading.  

After Alice downloaded a copy of an eBook, the following license is generated for her so that she can play the eBook offline with no obligations. This license will stay valid even after Alice's subscription expires.

4.7 Territory Restriction

This business model illustrates how to specify territory information to enable regional pricing, and to offer publishers control over where content can be purchased.

In the following example, the first grant specifies the $5.00 fee for use in the U.S.  It takes precedence over the second grant, which specifies a fee of $7.00 for use elsewhere.  paymentFlat specifies a one time fee in both grants.

4.8 Temporal Ordering of Exercising Rights

This example shows temporal ordering of rights.   Alice may listen to a piece of music as many times as she pleases provided she has listened to some commercial.  The grant related to the commercial has a trackReport condition. When Alice attempts to listen to the piece of music, the trackQuery condition herein allows exercise of the right only when the state value tracked by the trackReport condition has a value greater than zero.

4.9 Component Based Model

This business model illustrates how to specify different rights, conditions, and obligations to individual components of a composite work, as well as to the entire composite work.

Note in this example, paymentFlat specifies a one-time fee in both grants.

4.10 User Type Based Model

This business model illustrates how to specify user-based pricing levels for different individual users or for different groups of users.

The first license in this example shows a simple way to identify membership of a club. The second license shows how to use this membership for different kinds of pricing. 

Clearly, the membership can be replaced by other types of characterizing users, such as user roles, to specify other user type based models. 

Note: it is also possible to express this equivalently using an everyone pattern instead of a prerequisiteRight condition.

4.11 Site Licenses

This business model illustrates how to specify a site license. Having specified a site license, other grants can be made to everyone having a site license.  Site licensing may also be combined with other business models such as the tiered pricing model.

Two licenses are required to fulfill this model.  

The first license grants that anyone in the www.contentguard.com domain is eligible to use the second license, under the following terms and conditions:

• Validity time condition: validityInterval specifies the period of time during which the content can be used.  
• Territory condition: territory indicates the content can be used in the contentguard domain.  
• Lack of revocation condition: revocationFreshness specifies that lack of revocation of this license has been verified within the last day.  If and when this license is revoked, notice thereof will be posted to the web service specified by revocationMechamism.
• Online approval condition: seekApproval specifies that approval by a designated service is required prior to each use.

The second license contains the terms and conditions for use of content.  The prerequisiteRight construct in the first grant limits the free usage to users with the site license.  The second grant requires anyone else a one-time fee of $2.00 to play any content.

4.12 Payment to Multiple Rights Holders

This business model illustrates how to specify payment to more than one individual rights holder. As content is distributed down the distribution value chain, more individual rights holders may require payment for its use.

In this example, paymentPerUse specifies the amount charged for each use and to specifies the account to receive the payment.  allConditions makes sure that both payments are made for each use.

4.13 Personal Lending

This business model illustrates how to specify the transfer of content and the rights, conditions, and obligations associated with it from one party to another, either temporarily or permanently. In this model, once a work is lent to someone else, the original user does not have access to the work until it is returned. 

In this example, the first grantGroup allows a consumer, represented as a keyHolder, to play a DVD movie and loan it to a friend.  The second grantGroup allows the same consumer to issue new licenses for the loan right.  Note the issue construct in the second grant, which indicates that this consumer can issue new licenses for the loaner copies. The lending state is properly tracked by a Web service. 

4.14 Giving

This business model illustrates how to specify the gift of content to someone else. Giving is similar to personal lending, except that there is no expectation that the content will be returned. In other words, it can be modeled as permanent personal lending.

In this example, the first grant allows a consumer, represented as a keyHolder, to play a DVD movie for free, upon prior approval from an online service.  The second grantGroup grants this consumer to right to transfer the movie to anyone as long as he pays a one-time fee of $10.00.  The issue construct indicates that this consumer can issue a new license for the same movie.  The trackReport construct specifies the service to be reported to when a new license is issued.

4.15 Superdistribution

This business model illustrates how to specify superdistribution of content in terms of associating the same or different sets of rights, conditions, and obligations for the superdistributed contents. In this model, the original consumer retains the rights granted to him/her, and new consumers are required to acquire the rights granted to them.

In this model, information on where rights are offered can be used to refer new users of content to acquire rights for themselves. To issue a different sets of rights, this model uses different business models for new consumers.

In the following example, the first two grants are made to a keyHolder named Alice for the right to play and print an eBook.  The third grant allows anyone coming across this license to issue (super distribute) this eBook to everyone.  

New consumers are to acquire the following terms and conditions: play for an up-front fee of $2.00, print for $3.00 per copy, and extract from the book for an up-front fee of $8.00.  The paymentFlat construct is used to specify a one-time up-front fee; the paymentPerUse construct specify a payment each time a right is exercised.

4.16 Distributor Copies

This business model illustrates how to specify a maximum number of copies that a distributor can make of a work for further transmission or sale. This avoids making unnecessary, duplicated copies for distributors.

In this example, the first license certifies that a particular keyHolder is a distributor.  The second license allows the same distributor the right to sell a content.  Note that the right to sell is represented by the right to issue new licenses, in this context.  The number of copies that can be sold is limited by an online service specified in the exerciseLimit condition.

4.17 Personal Copies

This business model illustrates how to specify the maximum number copies that a consumer can make of a work for personal use.

This example describes the right to copy a book.  The lack of the right to issue implies that the new copies are for personal use only.  The total number of copies is limited by an online service specified in the exerciseLimit condition.  

4.18 Nested Revenue Model

This business model illustrates how to specify payments for content usage in terms of percentages of previous transactions. This is useful when the recipient of the surcharge has no prior knowledge of the details of pricing in subsequent transactions.

Note in this example, the nested fee specification.  The paymentPerUse construct specifies the charge amount each time a book is played.  The markup construct specifies the royalty amount calculated based on each charge amount.

4.19 Accessing Web Service

This model illustrates how to transmit purchase orders to an identified web service.  An identified party is authorized to transmit only purchase orders to an identified web service, subject to some interesting and useful restrictions related to license revocation.  License revocation occurs when a license is known to have been compromised.  

The following license specifies that lack of revocation must have been verified within the last day for each purchase order whose total is more than $25.00.  If and when this license is revoked, notice thereof will be posted to the web service specified by revocationMechamism.

4.20 Software Execution

In the software business, it is typical to tie an application to a particular identity and device.

The following example requires that a keyHolder named Alice execute a software called "pico" on the foo.com mainframe.  The source condition restricts the device from which the software can be executed.

4.21 Confidentiality of Rights

In all business models, it may be necessary sometimes to keep the confidentiality of a license or some terms and conditions.

Following is an example of an encrypted license, when total confidentiality is required.

In the following is a license, the first grant allows anyone to play a movie for a one-time fee of $10.00.  The second grant is encrypted to keep the content of the grant secret.

4.22 Watermark and Content Fragments

In some business models where encrypted content must be decrypted before being rendered, watermark can be inserted in the content itself to make pirated copies identifiable.

The following example grants the right to print the first 10 pages of a book and it is requested that watermark information is placed in the printed output.  Note in this example, the content condition is used to reference a fragment of the book.

4.23 Secure Device

In cases where tamper resistant hardware is not available, security level is one way to restrict access to only authorized devices.

The following example allows only projectors with certain security level to play a movie.

The first license certifies projectors with certain characteristics and assigns them a security level of 5.  The forAll construct defines the characteristics required of a projector.  The first grant certifies such projector and the second grant assigns it a security level of 5.

In the following license, the renderer condition restricts the rendering of a movie to a certified projector.

4.24 Third-party Metadata

This example shows how to incorporate third-party metadata into an XrML license.  Note how mpeg:DIDL is used as metadata to describe a given digitalWork.

5 Third-party Examples

5.1 Distance Learning (http://www.vide.net/resources/conferences/mdvc2001/DRMbreakout.ppt)

Institutional lending enables library and corporate business models.  In this example, a digital video lecture at Georgia Tech is limited to registrants of the course, each of whom was issued a digital certificate identifying them as registrants. Non-registrants may view the course for a metered fee of $10 per hour during the course period. Non-registrants will receive a lower-resolution video file than registrants. Geoffrey Smith, the course Graduate Teaching Assistant, has many rights for the duration of the course.

Two registration licenses are used in this example.  One is a student registration; the other is a teaching assistant registration.

The following license shows grants to registrants, non-registrants, and Geoffrey Smith.

5.2 Screen Saver Preview and Superdistribution (ftp://dvbftp:dvb2000@ftp.dvb.org/dvb-cpt/CfP%20Responses/DVB-CPT-711r1_0.pdf)

This scenario is simple and is based on the initial purchase of a screen saver by User A.  User A is so happy with his purchase that he forwards a preview copy to his friend User B.  User B agrees with his friend's opinion and decides he wants to buy a full version of the screen saver.