U.S. patent application number 13/162826 was filed with the patent office on 2011-10-06 for system and method for rights offering and granting using shared state variables.
This patent application is currently assigned to CONTENTGUARD HOLDINGS, INC.. Invention is credited to Eddie J. CHEN, Mai NGUYEN, Bijan TADAYON, Xin WANG.
Application Number | 20110247077 13/162826 |
Document ID | / |
Family ID | 25350385 |
Filed Date | 2011-10-06 |
United States Patent
Application |
20110247077 |
Kind Code |
A1 |
NGUYEN; Mai ; et
al. |
October 6, 2011 |
System and Method for Rights Offering and Granting Using Shared
State Variables
Abstract
A method, system and device for sharing rights adapted to be
associated with items, the method and system including generating
at least one of usage rights and meta-rights for the items;
defining, via the usage rights, a manner of use for the items; and
defining, via the meta-rights, a manner of rights transfer for the
items. The device including receiving at least one of usage rights
and meta-rights for the items; interpreting, via the usage rights,
a manner of use for the items; and interpreting, via the
meta-rights, a manner of rights transfer for the items. The usage
rights or the meta-rights include at least one state variable that
is shared by one or more rights.
Inventors: |
NGUYEN; Mai; (Buena Park,
CA) ; WANG; Xin; (Torrance, CA) ; CHEN; Eddie
J.; (Rancho Palos Verdes, CA) ; TADAYON; Bijan;
(Potomac, MD) |
Assignee: |
CONTENTGUARD HOLDINGS, INC.
Wilmington
DE
|
Family ID: |
25350385 |
Appl. No.: |
13/162826 |
Filed: |
June 17, 2011 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10956070 |
Oct 4, 2004 |
8001053 |
|
|
13162826 |
|
|
|
|
10162212 |
Jun 5, 2002 |
7774279 |
|
|
10956070 |
|
|
|
|
09867745 |
May 31, 2001 |
6754642 |
|
|
10162212 |
|
|
|
|
Current U.S.
Class: |
726/26 |
Current CPC
Class: |
G07F 17/16 20130101;
G06Q 50/184 20130101; G06Q 20/1235 20130101; G06Q 20/123
20130101 |
Class at
Publication: |
726/26 |
International
Class: |
H04L 9/00 20060101
H04L009/00 |
Claims
1. A method for sharing rights associated with an item between a
plurality of devices, the method comprising: associating a first
meta-right with the item, wherein the first meta-right is
enforceable by a computing device, and wherein the first meta-right
permits a first device of the plurality of devices to generate at
least one of a second meta-right and a usage right for the item;
associating a state variable with the first meta-right, wherein the
state variable is assigned an identification unique to the first
device, and wherein the state variable is managed by a license
server; storing the first meta-right and the item on the first
device; receiving, by the first device, a request to transfer the
item to a second device of the plurality of devices; generating, by
the first device, a derived right that is at least one of a second
meta-right and a usage right, wherein the derived right is
generated in accordance with the first meta-right; informing, by
the first device, the license server that governing of the state
variable is transferred to the second device; and managing, by the
license server, the state variable to associate the derived right
with the second device.
2. The method of claim 1, wherein the state variable indicates
which device is permitted to generate the derived right.
3. The method of claim 1, wherein the state variable indicates how
many devices are permitted to share rights.
4. The method of claim 1, wherein the license server is configured
to map the identification to a database of multiple variables,
where each variable represents a distinct state.
5. The method of claim 1, wherein the first meta-right is derived
from an offer, the offer is used to derive a plurality of
meta-rights, wherein each of the plurality of meta-rights is
associated with a distinct state variable.
6. The method of claim 5, wherein the offer does not explicitly
include meta-rights and the distinct state variable is created
based on interpretation of the offer.
7. The method of claim 1, wherein the state variable is shared
among multiple exercisable rights.
8. The method of claim 7, wherein the state variable represents a
plurality of states, wherein at least one of the states is managed
by one of the devices and at least one of the states is managed by
the license server.
9. The method of claim 1, wherein the state variable represents a
plurality of states, wherein at least one of the states is managed
by one of the devices and at least one of the states is managed by
the license server.
10. The method of claim 1, further comprising transferring, by the
first device, the item to the second device.
11. The method of claim 1, further comprising transferring, by the
first device, the derived right to the second device.
12. A system for sharing rights associated with an item between a
plurality of devices, the system comprising: a computing device
configured to associate a first meta-right with the item, wherein
the first meta-right is enforceable by a computing device, and
wherein the first meta-right permits a first device of the
plurality of devices to generate at least one of a second
meta-right and a usage right for the item; a computing device
configured to associate a state variable with the first meta-right,
wherein the state variable is assigned an identification unique to
the first device, and wherein the state variable is managed by a
license server; a first device comprising: a computing device
configured to store the first meta-right and the item on the first
device; a computing device configured to receive a request to
transfer the item to a second device of the plurality of devices; a
computing device configured to generate a derived right that is at
least one of a second meta-right and a usage right, wherein the
derived right is generated in accordance with the first meta-right;
and a computing device configured to inform the license server that
governing of the state variable is transferred to the second
device; and a license server configured to manage the state
variable to associate the derived right with the second device.
13. The system of claim 12, wherein the state variable indicates
which device is permitted to generate the derived right.
14. The system of claim 12, wherein the state variable indicates
how many devices are permitted to share rights.
15. The system of claim 12, wherein the license server is
configured to map the identification to a database of multiple
variables, where each variable represents a distinct state.
16. The system of claim 12, wherein the first meta-right is derived
from an offer, the offer is used to derive a plurality of
meta-rights, wherein each of the plurality of meta-rights is
associated with a distinct state variable.
17. The system of claim 16, wherein the offer does not explicitly
include meta-rights and the distinct state variable is created
based on interpretation of the offer.
18. The system of claim 12, wherein the state variable is shared
among multiple exercisable rights.
19. The system of claim 18, wherein the state variable represents a
plurality of states, wherein at least one of the states is managed
by one of the devices and at least one of the states is managed by
the license server.
20. The system of claim 12, wherein the state variable represents a
plurality of states, wherein at least one of the states is managed
by one of the devices and at least one of the states is managed by
the license server.
21. The system of claim 12, wherein the first device further
comprises a computing device configured to transfer the item to the
second device.
22. The system of claim 12, wherein the first device further
comprises a computing device configured to transfer the derived
right to the second device.
23. A method for sharing rights associated with an item between a
plurality of devices, the method comprising: receiving, at a first
device of the plurality of devices, the item and a first meta-right
associated with the item, wherein the first meta-right is
enforceable by a computing device, wherein the first meta-right is
associated with a state variable, the state variable being assigned
an identification unique to the first device and being managed by a
license server, and wherein the first meta-right permits the first
device to generate at least one of a second meta-right and a usage
right for the item; storing the first meta-right and the item on
the first device; receiving, by the first device, a request to
transfer the item to a second device of the plurality of devices;
generating, by the first device, a derived right that is at least
one of a second meta-right and a usage right, wherein the derived
right is generated in accordance with the first meta-right; and
informing, by the first device, the license server that governing
of the state variable is transferred to the second device to
thereby notify the license server that the state variable should be
managed to associate the derived right with the second device.
24. The method of claim 23, wherein the state variable indicates
which device is permitted to generate the derived right.
25. The method of claim 23, wherein the state variable indicates
how many devices are permitted to share rights.
26. The method of claim 23, wherein the license server is
configured to map the identification to a database of multiple
variables, where each variable represents a distinct state.
27. The method of claim 23, wherein the first meta-right is derived
from an offer, the offer is used to derive a plurality of
meta-rights, wherein each of the plurality of meta-rights is
associated with a distinct state variable.
28. The method of claim 27, wherein the offer does not explicitly
include meta-rights and the distinct state variable is created
based on interpretation of the offer.
29. The method of claim 23, wherein the state variable is shared
among multiple exercisable rights.
30. The method of claim 29, wherein the state variable represents a
plurality of states, wherein at least one of the states is managed
by one of the devices and at least one of the states is managed by
the license server.
31. The method of claim 23, wherein the state variable represents a
plurality of states, wherein at least one of the states is managed
by one of the devices and at least one of the states is managed by
the license server.
32. The method of claim 23, further comprising transferring, by the
first device, the item to the second device.
33. The method of claim 23, further comprising transferring, by the
first device, the derived right to the second device.
34. A device for sharing rights associated with an item between a
plurality of devices, the device being a first device of the
plurality of devices, the device comprising: a component configured
to receive the item and a first meta-right associated with the
item, wherein the first meta-right is enforceable by a computing
device, wherein the first meta-right is associated with a state
variable, the state variable being assigned an identification
unique to the first device and being managed by a license server,
and wherein the first meta-right permits the first device to
generate at least one of a second meta-right and a usage right for
the item; a component configured to store the first meta-right and
the item; a component configured to receive a request to transfer
the item to a second device of the plurality of devices; a
processor configured to generate a derived right that is at least
one of a second meta-right and a usage right, wherein the derived
right is generated in accordance with the first meta-right; and a
processor configured to inform the license server that governing of
the state variable is transferred to the second device to thereby
notify the license server that the state variable should be managed
to associate the derived right with the second device.
35. The device of claim 34, wherein the state variable indicates
which device is permitted to generate the derived right.
36. The device of claim 34, wherein the state variable indicates
how many devices are permitted to share rights.
37. The device of claim 34, wherein the license server is
configured to map the identification to a database of multiple
variables, where each variable represents a distinct state.
38. The device of claim 34, wherein the first meta-right is derived
from an offer, the offer is used to derive a plurality of
meta-rights, wherein each of the plurality of meta-rights is
associated with a distinct state variable.
39. The device of claim 38, wherein the offer does not explicitly
include meta-rights and the distinct state variable is created
based on interpretation of the offer.
40. The device of claim 34, wherein the state variable is shared
among multiple exercisable rights.
41. The device of claim 40, wherein the state variable represents a
plurality of states, wherein at least one of the states is managed
by one of the devices and at least one of the states is managed by
the license server.
42. The device of claim 34, wherein the state variable represents a
plurality of states, wherein at least one of the states is managed
by one of the devices and at least one of the states is managed by
the license server.
43. The device of claim 34, further comprising a processor
configured to transfer the item to the second device.
44. The device of claim 34, further comprising a processor
configured to transfer the derived right to the second device.
Description
RELATED APPLICATION DATA
[0001] This application is a continuation of U.S. patent
application Ser. No. 10/956,070, filed Oct. 4, 2004, now allowed,
which is a continuation-in-part of U.S. patent application Ser. No.
10/162,212, filed Jun. 5, 2002, now U.S. Pat. No. 7,774,279, issued
Aug. 10, 2010, which is a continuation-in-part of U.S. patent
application Ser. No. 09/867,745, filed May 31, 2001, now U.S. Pat.
No. 6,754,642, issued Jun. 22, 2004, and which claims benefit from
U.S. Provisional Patent Application No. 60/296,113, filed Jun. 7,
2001, U.S. Provisional Patent Application No. 60/331,625, filed
Nov. 20, 2001, and U.S. Provisional Patent Application No.
60/331,624, filed Nov. 20, 2001, the entire disclosures of all of
which are hereby incorporated by reference herein.
FIELD OF THE INVENTION
[0002] The present invention generally relates to offering and
granting of rights and more particularly to a method, system and
device for offering and granting of rights using shared state
variables.
BACKGROUND OF THE INVENTION
[0003] The digital age has greatly increased concerns about
ownership, access, and control of copyrighted information,
restricted services and valuable resources. Rapid evolution and
wide deployment has occurred for computers, and other electronic
devices such as cellular phones, pagers, PDAs, and e-book readers,
and these devices are interconnected through communication links
including the Internet, intranets and other networks. These
interconnected devices are especially conducive to publication of
content, offering of services and availability of resources
electronically.
[0004] One of the most important issues impeding the widespread
distribution of digital works (i.e. documents or other content in
forms readable by computers), via electronic means, and the
Internet in particular, is the current lack of ability to enforce
the intellectual property rights of content owners during the
distribution and use of digital works. Efforts to resolve this
problem have been termed "Intellectual Property Rights Management"
("IPRM"), "Digital Property Rights Management" ("DPRM"),
"Intellectual Property Management" ("IPM"), "Rights Management"
("RM"), and "Electronic Copyright Management" ("ECM"), collectively
referred to as "Digital Rights Management (DRM)" herein. There are
a number of issues to be considered in effecting a DRM System. For
example, authentication, authorization, accounting, payment and
financial clearing, rights specification, rights verification,
rights enforcement, and document protection issues should be
addressed. U.S. Pat. Nos. 5,530,235, 5,634,012, 5,715,403,
5,638,443, and 5,629,980, the disclosures of which are incorporated
herein by reference, disclose DRM systems addressing these
issues.
[0005] Two basic DRM schemes have been employed, secure containers
and trusted systems. A "secure container" (or simply an encrypted
document) offers a way to keep document contents encrypted until a
set of authorization conditions are met and some copyright terms
are honored (e.g., payment for use). After the various conditions
and terms are verified with the document provider, the document is
released to the user in clear form. Commercial products such as
Cryptolopes and Digiboxes fall into this category. Clearly, the
secure container approach provides a solution to protecting the
document during delivery over insecure channels, but does not
provide any mechanism to prevent legitimate users from obtaining
the clear document and then using and redistributing it in
violation of content owners' intellectual property.
[0006] In the "trusted system" approach, the entire system is
responsible for preventing unauthorized use and distribution of the
document. Building a trusted system usually entails introducing new
hardware such as a secure processor, secure storage and secure
rendering devices. This also requires that all software
applications that run on trusted systems be certified to be
trusted. While building tamper-proof trusted systems is a real
challenge to existing technologies, current market trends suggest
that open and untrusted systems, such as PC's and workstations
using browsers to access the Web, will be the dominant systems used
to access digital works. In this sense, existing computing
environments such as PC's and workstations equipped with popular
operating systems (e.g., Windows, Linux, and UNIX) and rendering
applications, such as browsers, are not trusted systems and cannot
be made trusted without significantly altering their architectures.
Of course, alteration of the architecture defeats a primary purpose
of the Web, i.e. flexibility and compatibility.
[0007] Some DRM systems allow content owners to specify usage
rights and conditions, and associate them with content. These usage
rights control how the recipient thereof can use the content.
Usually after a content distributor or consumer has completed
selecting and ordering specific content, the content is delivered
either electronically from some content repository or via a
conventional distribution channel to the recipient, such as
tangible media sent via a common carrier. Corresponding DRM systems
used by the recipient, for example the distributor or consumer,
will then interpret the rights and conditions associated with the
content, and use them to control how the content is distributed
and/or used. Examples of usage rights include view, print and
extract the content, and distribute, repackage and loan content.
Associated conditions may include any term upon which the rights
may be contingent such as payment, identification, time period, or
the like.
[0008] U.S. Pat. No. 5,634,012, discloses a system for controlling
the distribution of digital documents. Each rendering device has a
repository associated therewith. A predetermined set of usage
transaction steps define a protocol used by the repositories for
enforcing usage rights associated with a document. Usage rights
persist with the document content. The usage rights can permit
various manners of use such as, viewing only, use once,
distribution, and the like. Usage rights can be contingent on
payment or other conditions.
[0009] However, there are limitations associated with the
above-mentioned paradigms wherein only usage rights and conditions
associated with content are specified by content owners or other
grantors of rights. Once purchased by an end user, a consumer, or a
distributor, of content along with its associated usage rights and
conditions has no means to be legally passed on to a next recipient
in a distribution chain. Further the associated usage rights have
no provision for specifying rights to derive other rights, i.e.
rights to modify, transfer, offer, grant, obtain, transfer,
delegate, track, surrender, exchange, transport, exercise, revoke,
or the like. Common content distribution models often include a
multi-tier distribution and usage chain. Known DRM systems do not
facilitate the ability to prescribe rights and conditions for all
participants along a content distribution and usage chain.
Therefore, it is difficult for a content owner to commercially
exploit content unless the owner has a relationship with each party
in the distribution chain.
SUMMARY OF THE INVENTION
[0010] Exemplary aspects of the present invention include a method,
system and device for sharing rights adapted to be associated with
items, the method and system including generating at least one of
usage rights and meta-rights for the items; defining, via the usage
rights, a manner of use for the items; and defining, via the
meta-rights, a manner of rights transfer for the items. The device
including receiving at least one of usage rights and meta-rights
for the items; interpreting, via the usage rights, a manner of use
for the items; and interpreting, via the meta-rights, a manner of
rights transfer for the items. The usage rights or the meta-rights
include at least one state variable that is shared by one or more
rights.
[0011] Still other aspects, features, and advantages of the present
invention are readily apparent from the following detailed
description, simply by illustrating a number of exemplary
embodiments and implementations, including the best mode
contemplated for carrying out the present invention. The present
invention is also capable of other and different embodiments, and
its several details can be modified in various respects, all
without departing from the spirit and scope of the present
invention. Accordingly, the drawings and descriptions are to be
regarded as illustrative in nature, and not as restrictive.
BRIEF DESCRIPTION OF THE DRAWINGS
[0012] Exemplary embodiments of this invention will be described in
detail, with reference to the attached drawings in which:
[0013] FIG. 1 is a schematic diagram of a three-tier model for
content distribution;
[0014] FIG. 2 is a schematic diagram illustrating rights offering
and granting processes in the model of FIG. 1;
[0015] FIG. 3(a) is a schematic diagram of a simple
supplier-consumer push model for rights generating, issuing and
exercising;
[0016] FIG. 3(b) is a schematic diagram of a simple
supplier-consumer pull model for rights generating, issuing and
exercising;
[0017] FIG. 4 is a block diagram of a rights offering-granting
architecture in accordance with the preferred embodiment;
[0018] FIGS. 5a and 5b are workflow diagrams for examples of
offering and granting rights between a rights supplier and a rights
consumer with a push and pull model respectively;
[0019] FIG. 6 is a flow chart of a rights offer generation process
in accordance with the preferred embodiment;
[0020] FIG. 7 is a flow chart of a rights offer consideration
process in accordance with the preferred embodiment;
[0021] FIG. 8 is a flow chart of a rights offer customization
process in accordance with the preferred embodiment;
[0022] FIG. 9 is block diagram of a DRM system that may be utilized
in connection with the preferred embodiment;
[0023] FIG. 10 is a block diagram of an exemplary structure of a
license containing usage rights and meta-rights of the preferred
embodiment;
[0024] FIG. 11 is a schematic illustration of a rights label of the
preferred embodiment;
[0025] FIG. 12 illustrates an exemplary system including a
state-of-rights server;
[0026] FIG. 13 illustrates employing of a state variable in
deriving exclusive usage rights;
[0027] FIG. 14 illustrates employing of a state variable in
deriving inherited usage rights;
[0028] FIG. 15 illustrates employing of a state variable in
deriving rights that are shared among a known set of rights
recipients;
[0029] FIG. 16 illustrates employing of a state variable in
deriving rights that are shared among a dynamic set of rights
recipients;
[0030] FIG. 17 illustrates employing of a state variable in
maintaining a state shared by multiple rights;
[0031] FIG. 18 illustrates employing of multiple state variables to
represent one state of rights;
[0032] FIG. 19 illustrates a case where not all rights are
associated with states;
[0033] FIG. 20 illustrates a case where not all rights which are
associated with states are shared or inherited; and
[0034] FIG. 21 illustrates a case of rights sharing based on an
offer which does not explicitly include meta-rights.
DETAILED DESCRIPTION
[0035] Prior to providing detailed description of the apparatus and
method for offering and granting rights, a description of a DRM
system that can be utilized to specify and enforce usage rights and
meta-rights for specific content, services, or other items is first
described below.
[0036] FIG. 9 illustrates DRM System 10 that includes a user
activation component, in the form of activation server 20, that
issues public and private key pairs, or other identification
mechanisms, to content users in a protected fashion, as is well
known. Typically, when a user uses DRM system 10 for the first
time, the user installs software that works with, or includes, a
rendering application for a particular content format. The software
is installed in client environment 30, a computer associated with
the content recipient, for example. The software is part of DRM 10
system and is used to enforce usage rights for protected content.
During the activation process, some information is exchanged
between activation server 20 and client environment 30. Client
component 60 preferably is tamper resistant and contains the set of
public and private keys issued by activation server 20 as well as
other components, such as rendering components for example.
[0037] Rights label 40 is associated with content 42 and specifies
usage rights and meta-rights that are available to a recipient,
i.e. a consumer of rights, when corresponding conditions are
satisfied. License Server 50 manages the encryption keys and issues
licenses 52 for protected content 42. Licenses 52 embody the actual
granting of rights, including usage rights and meta-rights, to an
end user. For example, rights offer 40 may permit a user to view
content for a fee of five dollars and print content for a fee of
ten dollars, or it may permit a user to offer rights to another
user, for example, by utilizing the concept of meta-rights
described below. License 52 can be issued for the view right when
the five dollar fee has been paid. Client component 60 interprets
and enforces the rights, including usage rights and meta-rights,
that have been specified in the license. Rights label 40 and
license 52 are described in detail below.
[0038] FIG. 11 illustrates rights label 40 in accordance with the
preferred embodiment. Rights label 40 includes plural rights
options 44. Each rights option 44 includes usage rights 44a,
conditions 44b, and content specification 44c. Content
specification 44c can include any mechanism for referencing,
calling, locating, or otherwise specifying content 42 associated
with rights offer 44.
[0039] As shown in FIG. 10, license 52 includes license 52a, grant
52b, and digital signature 52c. Grant 52b includes granted usage
rights and/or meta-rights selected from label. The structure of the
grant also includes one or more principals, to whom the specified
usage rights and/or meta-rights are granted, a list of conditions,
and state variables required to enforce the license. Like usage
rights, access and exercise of the granted meta-rights are
controlled by the condition list and state variables as described
below.
[0040] Clear (unprotected) content can be prepared with document
preparation application 72 installed on computer 70 associated with
a content publisher, a content distributor, a content service
provider, or any other party. Preparation of content consists of
specifying the usage rights, meta-rights, and conditions under
which content 42 can be used and distributed, associating rights
label 40 with content 42 and protecting content 42 with some crypto
algorithm. A rights language such as XrML can be used to specify
the rights and conditions. However, the usage rights and
meta-rights can be specified in any manner. Also, the rights can be
in the form of a pre-defined specification or template that is
merely associated with the content. Accordingly, the process of
specifying rights refers to any process for associating rights with
content. Rights label 40 associated with content 42 and the
encryption key used to encrypt the content can be transmitted to
license server 50.
[0041] Rights can specify transfer rights, such as distribution
rights, and can permit granting of rights to others or the
derivation of rights. Such rights are referred to as "meta-rights".
Meta-rights are the rights that one has to manipulate, modify, or
otherwise derive other meta-rights or usage rights. Meta-rights can
be thought of as usage rights to usage rights. Meta-rights can
include rights to offer, grant, obtain, transfer, delegate, track,
surrender, exchange, and revoke usage rights to/from others.
Meta-rights can include the rights to modify any of the conditions
associated with other rights. For example, a meta-right may be the
right to extend or reduce the scope of a particular right. A
meta-right may also be the right to extend or reduce the validation
period of a right.
[0042] Often, conditions must be satisfied in order to exercise the
manner of use in a specified right. For, example a condition may be
the payment of a fee, submission of personal data, or any other
requirement desired before permitting exercise of a manner of use.
Conditions can also be "access conditions" for example, access
conditions can apply to a particular group of users, say students
in a university, or members of a book club. In other words, the
condition is that the user is a particular person or member of a
particular group. Rights and conditions can exist as separate
entities or can be combined.
[0043] State variables track potentially dynamic states conditions.
State variables are variables having values that represent status
of an item, usage rights, license or other dynamic conditions.
State variables can be tracked, by clearinghouse 90 license or
server 30 another device, based on identification mechanisms in
license 52. Further, the value of state variables can be used in a
condition. For example, a usage right can be the right to print
content 42 three times. Each time the usage right is exercised, the
value of the state variable "number of prints" is incremented. In
this example, when the value of the state variable is three, the
condition is not longer satisfied and content 42 cannot be printed.
Another example of a state variable is time. A condition of license
52 may require that content 42 is printed within thirty days. A
state variable can be used to track the expiration of thirty days.
Further, the state of a right can be tracked as a collection of
state variables. The collection of the change is the state of a
usage right represents the usage history of that right.
[0044] A typical workflow for DRM system 10 is described below. A
recipient, such as a user, operating within client environment 30
is activated for receiving content by activation server 20. This
results in a public-private key pair (and some user/machine
specific information) being downloaded to client environment 30 in
the form of client software component 60 in a known manner. This
activation process can be accomplished at any time prior to the
issuing of a license.
[0045] When a user wishes to use protected content 42, the user
makes a request for the content 42. For example, a user might
browse a Web site running on Web server 80 associated with a
grantor of rights such as a content distributor, using a browser
installed in client environment 30, and attempt to download
protected content 42. During this process, the user may go through
a series of steps possibly including a fee transaction (as in the
sale of content) or other transactions (such as collection of
information). When the appropriate conditions and other
prerequisites, such as the collection of a fee and verification
that the user has been activated, are satisfied, Web server 80
contacts license server 50 through a secure communications channel,
such as a channel using a Secure Sockets Layer (SSL). License
server 50 then generates license 52 for the content and Web server
80 causes both protected content 42 and license 52 to be
downloaded. License 52 can be downloaded from license server 50 or
an associated device. Content 42 can be downloaded from computer 70
associated with a publisher, distributor, or other party.
[0046] Client component 60 in client environment 30 will then
proceed to interpret license 52 and allow use of content 42 based
on the rights and conditions specified in license 52. The
interpretation and enforcement of usage rights are well known
generally. The steps above may take place sequentially or
approximately simultaneously or in various order.
[0047] DRM system 10 addresses security aspects of protecting
content 42. In particular, DRM system 10 may authenticate license
52 that has been issued by license server 50. One way to accomplish
such authentication is for application 60 to determine if the
licenses can be trusted. In other words, application 60 has the
capability to verify and validate the cryptographic signature of
digital signature 52c, or other identifying characteristic of the
license. During the activation step described above, both client
environment 30 and license server 50 receive a set of keys in a
tamper-resistant software "package" that also includes other
components, such as the necessary components for activated client
environment 30 to verify signature 52 of license 52 in a known
manner. Of course, the example above is merely one way to effect a
DRM system. For example, the license and content can be distributed
from different entities. Also, rights offer 40 can be associated
with content by a party other than the party preparing the content.
Also, clearinghouse 90 can be used to process payment transactions
and verify payment prior to issuing a license.
[0048] For any set of rights, there are two kinds of entities
involved, the "supplier" and the "consumer". The function of the
supplier is to offer, and possibly grant, the rights, and the
function of the consumer is to select, and possibly exercise the
rights. Both the supplier and consumer may actually represent two
or more entities. In general, multiple entities may collectively
make an offer and grant rights to multiple entities. The supplier
and consumer represent any two entities in the content value chain
that have a direct relationship with each other regarding the
granting of rights. At the beginning of the value chain, the
supplier and consumer may be author and publisher. Going down along
the value chain, the supplier and consumer may be a publisher and
another publisher (for content aggregation), a publisher and
distributor (for content distribution), a distributor and another
distributor (for multi-tier content distribution), a distributor
and a retailer (for content retailing), a retailer and a consumer
(for content consumption), and a consumer and another consumer (for
content supper-distribution or personal lending).
[0049] An "offer of rights" or "rights offer" expresses how a
consumer (e.g. a content distributor or user) can acquire a
particular instance of content together with its associated usage
rights and/or meta-rights. An offer may or may not contain
financial terms. An offer is an expression of mere willingness to
commerce negotiation and also an expression of willingness to grant
on terms stated. An offer may be expressed in the form of a rights
label. A "consideration of rights" is a process as part of the
rights granting in which the rights consumer has examined the
rights being offered and possibly bargained them and associated
terms and conditions. A "choice of rights" is a selection of rights
and their associated terms and conditions from a rights offer. It
indicates the intent of the consumer to accept these rights and the
corresponding terms and conditions. For example, selection can
comprise selecting one option 44 from label 40. "Customization of
rights" is a process as part of the rights granting in which the
rights supplier assembles rights and terms and conditions based on
a choice of the rights consumer. The output of this process can be
a draft license to be accepted by the rights consumer. A "license
of rights" is an expression of rights and possibly conditions
accepted and agreed upon by the rights supplier and consumer. It is
the output of the rights offering and granting process. A license
is a grant to exercise the rights that govern the usage (possibly
including further distribution) of content or other items.
[0050] As described above, a rights label, such as rights label 40,
may contain a number of options 44 allowing the consumer to make a
selection and conduct negotiation (if permitted), while license 52
contains rights the consumer has selected and accepted. Note that
the accepted rights may include a right to present offers to others
or make selections of offers.
[0051] An example of a distribution chain model is illustrated in
FIG. 1. The distribution chain includes a content provider 100,
distributor 110, and end user 120. Of course content may be
prepared in the manner described above. It is assumed that the
content has already been prepared in the model of FIG. 1. FIG. 1 is
directed to the transfer of content and shows that, in this
example, provider 100 may publish content to distributor 110 or
receive content for reuse from distributor 110. Distributor 110 may
in turn distribute content to user 120 or receive returned content
form user 120. User 100 can use content. To further illustrate the
potential complexities of multi-tier distribution chains provider
100 can aggregate content from others, distributor 110, can receive
content from other distributors for redistribution, and user 120
can share content with the other users. It is clear that there are
plural stages in the content life cycle and plural relationships
between the various parties. A precise and consistent specification
of rights at the different stages of the life cycle and
relationships is important and crucial to persistent protection of
content in multi-tier distribution and usage.
[0052] FIG. 2 illustrates the flow of rights in the same model,
including rights generating, aggregating, issuing, relinquishing,
driving, granting, surrendering, delegating and exercising. The
model of FIG. 2 includes the same entities, provider 100,
distributor 110, and user 120. It can be seen that, with respect to
the flow of rights, each party can grant and accept rights. User
120 can grant and accept rights from other users, a process called
"delegation", in this example.
[0053] The model of FIG. 2 covers many specific content publishing,
distribution and use relationships. Other models can be derived
from on this model by a different consolidation or segregation of
the parties. For example, every provider can be a distributor. This
is "direct publishing", which allows individual authors to
distribute/sell their content without any intermediate publisher.
Further, every consumer can be a potential distributor. This allows
consumers to pass content to each other. This includes
supper-distribution, gifting, and personal lending. In a "Web
community" and everyone is able to publish, distribute and consume
content. "Content aggregation" allows publishers to compose content
from other publishers into composite works. Site license and
enterprise use allows sharing content among consumers.
[0054] In general, all the rights relationships shown in FIG. 2 can
be captured by two generic supplier-consumer models, as shown in
FIGS. 3(a) and 3(b). FIG. 3(a) shows a "push" model and FIG. 3(b)
shows a "pull" model. In the push model shown in FIG. 3(a), rights
supplier 200 initiates the rights offering and granting process by
generating an offer and granting the rights to the rights consumer
210. In the pull model shown in FIG. 3(b), rights consumer 210
initiates the process by requesting an offer and accepting the
rights from the rights supplier 200.
[0055] An architecture of the preferred embodiment for rights
offering and granting is shown in FIG. 4. Architecture 400 can be
implemented as a combination of computer hardware and software and
includes rights supplier component 402, rights consumer component
438 and communication channel 422 linking these two components. For
example, communication channel 42 can be Internet, a direct
computer to computer connection, a LAN, a wireless connection or
the like. Supplier component 402 is associated with the supplier,
i.e. the entity making rights available to a consumer who is the
entity going to exercise, i.e., consume the rights. The supplier
could be the content owner or provider, or could be a distributor
or any "middle-man," such as a retailer or operator of a web site.
Consumer component 438 is associated with the consumer who could be
the ultimate user (i.e., content consumer) or a "middle-man," such
as a retailer, whole-seller, or reseller. Keep in mind that the
consumer consumes rights and does not necessarily use (i.e.
consume) the content. Both supplier component 402 and consumer
component 438 can embody any type of hardware devices, and or
software modules, such as a personal computer, a handheld computer,
a mobile phone a server, a network, or any combination of the same.
Supplier component 402 generates rights label 40 as offers,
presents draft licenses and grants license 52 to the consumer.
Consumer component 438 issues requests, select choices of options
44 from rights labels 40, generates counter offers, and accepts
licenses 52. Supplier component 402 and consumer component 438 can
be embodied in the same device(s) and communication channel 422 can
be an internal channel.
[0056] Supplier component 402 contains user interface module 404,
communication interface module 420 identity module 406 repository
412 for supplier's rights (e.g., in the form of issued licenses)
and database 414 for management related information. User interface
404 accomplishes presentation to the user of the component
functions and acceptance of user interactions in a known manner.
Communication interface 422 provides the proper formatting and
protocols for messages between supplier component 402 and consumer
component 438. Identity module 406 ensures that the identity of
supplier component 402 can be authenticated by consumer component
438 and may contain authentication information like a password,
cryptographic keys or biometric information of the user of supplier
component 402. Rights repository 412 stores rights granted to the
user of supplier component 402 and may include functions for
indexing, searching and updating the rights stored within.
Management database 414 is used to archive information generated
during the rights offering and granting processes. Such information
includes information related to initial offers, consumer choices,
possible counter-offers, agreements and final licenses.
[0057] Consumer component 438 includes user interface module 428,
communication interface module 424, identity module 426, repository
434 for consumer's rights (e.g., in the form of issued licenses),
and database 436 for management related information. User interface
424 deals handles presentation to the user of the component and
acceptance of user interactions. Communication interface 422
provides the proper formatting and protocols for rights offering
and granting messages between supplier component 402 and consumer
component 438. Identity module 426 ensures that the identity of the
consumer component 438 can be authenticated by supplier component
402 and may contain authentication information like a password,
cryptographic keys or biometric information of the user. Rights
repository 434 stores rights granted to the user of consumer
component 438 and may include functions for indexing, searching and
updating the rights stored within. Management database 436 is used
to archive information generated during the rights offering and
granting process. The information includes that related to offers
44, consumer choices, possible counter-offers, agreements and
licenses 52. Note that database 436 can store information that is
the same as or different from database 414 because the parties may
interact with other parties and thus have different archived
information.
[0058] Supplier component 402 also includes offer generator module
408 for generating offers, rights composer module 410 for composing
licenses, offer templates module 418 for providing templates for
generating offers based on previous transactions and common
formality of offers, and consumer profiles module 416 for
customizing and granting rights based on past consumer
characteristics and relationships.
[0059] Consumer component 438 also includes offer analyzer module
430 for understanding rights and their terms and conditions
presented within offers, a choice maker module 432 for selecting
favorable options specified in offers, a supplier preference module
438 for describing any preferred suppliers based on past and
existing supplier characteristics and relationships, and choice
patterns module 440 for providing patterns and interests in
selection options in offers. For example, the choice pattern module
440 may include a list of preferred suppliers or a list of lowest
prices for the item of interest to the consumer. Offer analyzer
module 430 and choice maker module 432, respectively, may be
combined into one module.
[0060] The process of offering and granting rights within
architecture 400 is based on protocols followed by supplier
component 402 and consumer component 438. These protocols generally
consist of an offer and acceptance of that offer. Specifically, the
protocols include an offering of rights by one party to another and
acceptance of that offer by the person to whom it is made. An
offer, once made, may be styled so that it may revoked before
acceptance or the offeror could styled it so that it cannot be
revoked at all or only under certain circumstances definable by the
offeror. An offer can also expire in various way, for example if a
deadline for acceptance passes. If there is no specified deadline,
then the offer could expire in a predetermined reasonable time,
depending on the subject matter of the offer. For periodically
available content such as magazines, journals, and even newspapers,
a reasonable time could be accord to the period of the content
publication, for example. For dynamically generated or provided
content such as streaming content, a reasonable time could be any
time before the availability of the content. The rights supplier
can dictate other terms of the acceptance, to which the rights
consumer is bound. For example, the offer may require acceptance in
sending back in a certain form via an email or through a certain
web page interface.
[0061] FIG. 5(a) illustrates the workflow of protocol 500 of a push
model for rights granting. Supplier component 402 generates an
offer of rights in the form of rights label 40 for example, with
possibly many options 44, and sends it to consumer component 438
(510). Consumer component 438 considers the offer and its possible
options, and responds to supplier component 402 with a choice of
any of the optional rights offer 44 (512). Supplier component 402
customizes rights according to the consumer's response, and issues
the rights the user of consumer component 432 (514) in the form of
a draft license.
[0062] Consumer component 438 then accepts the draft license if it
corresponds to the choice made and is otherwise acceptable (516).
Upon acceptance, supplier component 402 generates license 52 and
transmits license 52 to consumer component (518). Keep in mind that
grant 52b of license 52 can include usage rights and/or
meta-rights. Therefore license 52 can permit the user of consumer
component 438 to grant rights to others in a similar fashion.
However, the derivable rights are controlled by upstream parties
through the use of meta-rights. Additionally, the protocol can
include steps where supplier component 402 requests to make payment
through a credit card of the user of consumer component 438, and
the user component 402 provides the information and authorizes the
charge. Both supplier component 402 and consumer component 438 can
generate status reports on success or failure of the process.
Further, parties can authenticate each other during the process and
maintain authentication through the process.
[0063] FIG. 5(b) shows a protocol of pull model for rights
granting. First, consumer component 438 sends a request to supplier
component 402 to indicate an interest in obtaining certain rights
in content (520). Supplier component 402 then responds with an
offer, in the form of label 40 having plural offer options 44,
covering the rights requested by consumer component 438, and sends
the offer to consumer component 438 (522).
[0064] Consumer component 438 then considers the offer and its
options, and responds to supplier component 402 with a choice of
one of the offer options (524). Supplier component 402 customizes
rights according to the response, and grant the rights to the
consumer in the form of a draft license (526). Consumer component
438 then accepts the draft license (528) and supplier component 402
issues license 52 granting rights to consumer component 438 (530).
Once again the rights can include meta-rights.
[0065] FIG. 6 illustrates the offer generation process 600
performed by offer generator module 408 in supplier component 402.
In offer generation process 600, available rights are first
collected in block 602. Rights may be available from a previous
supplier by being derived from meta-rights granted to the supplier
or may be originally created rights. In step 604 it is determined
whether supplier has a right to make an offer to the consumer. For
example, if the consumer is known to be a minor and the content is
restricted to an adult consumer or if the consumer is on a list of
those prohibited from receiving content, the supplier may not make
an offer. In such case, the offer generation process terminates in
step 606. If the supplier has the right to make an offer, the
process then determines all the rights that can be offered to the
consumer in step 608 by parsing the rights collected in step 602.
Next, in step 610, the process determines whether the consumer has
requested any specific rights. If a request has been received, the
process further filters the determined rights that can be offered,
taking the received consumer requested rights into consideration
and comparing them to the available rights. Then, the process
determines whether an offer template needs to be applied in steps
614.
[0066] For example, the consumer might be offered standard rights
included in the template, such as printing right, archiving right,
etc. of the content. If an offer template is available and needed,
the offer template is then applied in steps 616. In steps 618,
human intervention may be provided to further make adjustments to
the offer template or to any of the rights that are available for
offering thus far in the process. Next, restrictions can be
applied, through conditions and/or state variables. For example, a
time restriction may be place on certain rights in step 620.
Finally, a digital signature or other authentication is provided
with the collection of rights to be offered in step 622 and an
authenticated offer, in the form of rights label 40 is made in step
624 and presented to consumer component 438 in step 624.
[0067] FIG. 8 illustrates rights customization process 800 which is
performed by rights composer module 410 in supplier component 402.
Initially, consumer's choices are received in step 802. Choices are
rights and conditions of an option 44 selected label 40 of step 624
(FIG. 6). The process then determines if supplier component 402 has
the right to grant rights to consumer component 438 in step 804.
For example, if the consumer fails to meet a certain requirement,
such as minimum age or proof of residence in a locale where content
may be licensed, for example, granting a license may not be proper,
and the rights customization process 800 terminates in step 806.
Otherwise, consumer selected choices are analyzed in step 808 to
ascertain if they are an discernible by supplier component 402. For
example, the choices can be parsed to see if they are
understandable.
[0068] Next, the process determines if consumer information is
available in step 810. For example, consumer profiles may be stored
in database 414 (FIG. 4). If available, the consumer information is
taken into consideration in step 812 for further analysis of
consumer choices. In step 812, dynamic information can also
considered as described below. For example, the profile may include
a trust rating or address of the consumer that renders it desirable
of undesirable to provide certain rights. The process then
determines if the choices are reasonable in step 814. This
determination may be carried out, for example, computationally or
with human intervention. If the customer's choices are deemed
unreasonable, re-negotiation of the customer's choices is then
performed in block 816. In this re-negotiation process, the
customer is presented with a new proposed offer based on the
previously analyzed choices, the customer is given an opportunity
to submit new choices offered, and the right customization process
800 begins again in step 802. Otherwise, a license including the
selected rights is created in step 818.
[0069] After a license is created, if consumer acceptance is
necessary (step 820), it is presented to the consumer for review in
step 822. If the consumer does not agree with the terms in the
license in step 824, re-negotiation is then initiated in step 816,
which re-starts the rights customization process 800 again in step
802. In step 820, if a review by the consumer is not required, then
the license is authenticated in step 826 to create a completed
license 52 in step 828 which is to be issued and associated with
content 42.
[0070] FIG. 7 illustrates offer consideration process 700 which is
performed by offer analyzer module 430 and choice maker module 432
of consumer component 438. Available offers are first collected in
step 702. In step 704, process 700 determines whether it has a
right to accept offers from the supplier. For example, if the
consumer certain restrictions on the purchase of content, such as
an age restriction or a restriction against accepting content from
outside an enterprise, the consumer may not accept an offer. In
such a case, the offer consideration process terminates in step
706. If the consumer has the right to accept offers from the
supplier, the offers are then analyzed in step 708 to ascertain if
they are discernible. If it is determined that supplier preferences
are available in step 710, the offers are filtered in step 712
based on the preferences. For example, the consumer may trust a
specific supplier, or otherwise prefer transactions with that
supplier, more that other suppliers. Next, step 714 determines if
consumer preferences are available and, if so, they are applied in
step 716 to the offers. Once all the offers are analyzed, by
applying the logic of steps 708-714 and any other desired logic,
the consumer then selects options in block 718 and specifies
contingencies in block 720. The selection of options can be done
automatically. If human intervention is desired, the customer can
intervene and further specify additional choices or conditions
desired. Any preferences, rules, or other logic can be used to
analyze offers.
[0071] Overall, as can be seen in the description of FIGS. 6, 7,
and 8 above, the consumer sends a request, and then a license is
constructed. Either the supplier or the consumer could draft the
content of the license, but in the example above the supplier does
so. The request is a subset of an offer and the offer has one or
more options. The supplier makes the offer available to the
consumer sending the request (and to other consumers if that is the
desire), and the consumer (including other consumers, if
applicable) makes choices. Then, the supplier analyzes the choices,
and constructs the license (i.e. a grant of rights). Note that the
request can also be rejected, or a counter proposal could be made
and the same process could then repeat for the counter
proposal.
[0072] Also, when the supplier analyzes the request, the analysis
may be done automatically, or with human intervention. When the
consumer considers the offer, the choice or acceptance may be done
automatically, or with human intervention. Either the offer or a
license, or both, may be generated based on the dynamic
information, the consumer's information, and the consumer's
request, such as described above.
[0073] The dynamic information may include many kinds of
information including information related to pricing, status of the
network, the traffic of a web site at each moment of time,
discounts given, coupons given, the habits of the consumer, how
many times the content has been used, for how long the content was
used, where it was used, or the like. The dynamic information can
be tracked as state variables and the values of the state variables
can be checked and updated as necessary.
[0074] Dynamic information is information capable of being
(although, it need not actually be) changed or created by or by
reference to a non-static element. For example, the dynamic
information can be obtained based on a formula, database, curve,
predetermined table, percentage of a value, a function, reference
to other data, such as the prime rate of interest or the change in
a stock market index, and/or by a human intervention of the user or
distributor, and/or consumer's input.
[0075] The consumer's information may include information such as
the age of the consumer, the credit history of the consumer, the
credit limit of the consumer, income of the consumer, what kind of
rights or licenses obtained, the password of the consumer, the key
assigned to the consumer, club membership for access or discount,
the class of the consumer based on a predetermined criteria, or any
other data, identification characteristics and information. The
supplier's information may include some or all of the subjects of
information as the consumer's information, and may also include,
for example, available options or variations, suppliers, shipping
information, and other information.
[0076] The system and processes disclosed in this invention support
multi-tier and super distributions of content. The following is a
use case that shows how this can be modeled and supported. It
illustrates the process of offering and granting rights by showing
the process of transforming offered rights to a rights supplier
(the content distributor in this case) to granted rights to a
rights consumer (the end user in this case). It specifically shows
how an offer is generated from an existing license, how this offer
is considered with a choice, and how a final license is issued.
Meta-rights provide a mechanism for permitting the transfer of
rights from one party to the next party in a content distribution
chain.
[0077] Suppose that a content provider P of some content C wants to
specify that a distributor D may sell, to any end user within the
region of the United States (US), the "play" right at a flat rate
of $1 and the "print" right at a cost of $4 per copy (both are paid
by D to P). The provider also allows the content distributor to add
its own conditions to the "play" and "print" rights it issues to
end users.
[0078] A license from the content provider to the distributor may
resemble the following using the XrML rights language.
TABLE-US-00001 <license> <grant> <forAll
varName="user"/> <forAll
varName="distributorConditionForPlay"/> <principal
id="distributor"/> <issue/> <grant> <principal
varRef="user"/> <play/> <digitalResource
licensePartId="book"/> <allCondition> <region
regionCode="US"/> <condition
varRef="distributorConditionForPlay"/> </allCondition>
</grant> <fee> <flat
currencycode="USD">1</flat> <to
licensePartid="provider"/> </fee> </grant>
<grant> <forAll varName="user"/> <forAll
varName="distributorConditionForPrint"/> <principal
id="distributor"/> <issue/> <grant> <principal
varRef="user"/> <play/> <digitalResource
licensePartId="book"/> <allCondition> <region
regionCode="US"/> <condition
varRef="distributorConditionForPrint"/> </allCondition>
</grant> <fee> <perUse
regionCode="USD">5</perUse> <to
licensePartId="provider"/> </fee> </grant>
<issuer id="provider"/> </license>
[0079] The distributor may make an offer to the end user based on
the rights it has as expressed in the license above. Note that
usage rights and conditions of each option are set forth as XML
elements between <grant> tags. In the following offer, note
that the distributor adds a fee condition for getting the "play"
right, charging the end user $2 ($1 more than it pays to the
provider), and another fee condition for the "print" right,
charging the end user $6 per print copy ($1 more than it pays to
the provider). The distributor also limits the offer to an
acceptance time period (up to Dec. 31, 2002). Meta rights granted
to the distributor permit the distributor to modify the grant in
the license, as described above, and make the offer.
TABLE-US-00002 <offer> <grant> <forAll
varName="user"/> <principal varRef="user"/>
<obtain/> <grant> <principal varRef="user"/>
<play/> <digitalResource licensePartId="book"/>
<region regionCode="US"/> </grant> <fee> <flat
currencyCode="USD">2</flat> <to
licensePartId="distributor"/> </fee> </grant>
<grant> <forAll varName="user"/> <principal
varRef="user"/> <obtain/> <grant> <principal
varRef="user"/> <print/> <digitalResource
licensePartId="book"/> <allCondition> <region
regionCode="US"/> <fee> <perUse
currencyCode="USD">6</perUse> <to
licensePartId="distributor"/> </fee> </allCondition>
</grant> </grant> <issuer id="distributor">
<validityInterval> <until>2002:12:31</until>
</validityInterval> </issuer> </offer>
[0080] When the offer is presented to an end user, the end user may
choose to get only the right to "play" for the flat fee of $2 and
responds to the distributor with a choice set forth as an XML
element between <choice> tags as follows.
TABLE-US-00003 <choice> <grant> <principal
id="anEndUser"/> <obtain/> <grant> <principal
id="anEndUser"/> <play/> <digitalResource
licensePartId="book"/> <region regionCode="US"/>
</grant> <fee> <flat
currencyCode="USD">2</flat> <to
licensePartId="distributor"/> </fee> </grant>
<issuer id="anEndUser"/> <validityInterval>
<until>2002:12:31</until> </validityInterval>
</issuer> </choice>
[0081] Note that the request can also be rejected. Note also that a
response can also be constructed as a counter offer for rights not
originally offered by the distributor. When the distributor
receives the choice from the end user, it then issues a license to
the user as shown below.
TABLE-US-00004 <license> <grant> <principal
id="anEndUser"/> <obtain/> <grant> <principal
id="anEndUser"/> <play/> <digitalResource
licensePartId="book"/> <region regionCode="US"/>
</grant> <fee> <flat
currencyCode="USD">2</flat> <to
licensePartId="distributor"/> </fee> </grant>
<issuer id="distributor"> <issuedTime> 2002:05:06
</issuedTime> </issuer> </license>
[0082] Note that in all the XML documents above, the issuers may
choose to digitally sign the documents using some digital signature
algorithms. The recipients of these documents have options to
verify the validity of these documents by checking the validity of
the attached digital signatures. Access to the various documents,
and elements thereof, can be controlled using known techniques.
[0083] In some situations offering and granting result in a license
with a fresh state for content usage. As one starts to exercise the
rights, derived rights, obtained as a result of meta-rights, may
inherit and/or share the state variable values associated with the
rights. For example, when one is granted with the right to print 5
times and make 4 copies of some document, all new copies may have
the same set of rights but share the state (or remaining rights)
with the original. After the original has been printed 2 times and
a new copy was then made, the copy and original can all together
print 3 times and make 2 more new copies.
[0084] Thus, the exemplary embodiments include a method for
transferring usage rights adapted to be associated with items. The
method includes generating, by a supplier, at least one first offer
containing usage rights and meta-rights for the item, the usage
rights defining a manner of use for the items, the meta-rights
specifying rights to derive usage rights or other meta-rights,
presenting the offer to a first consumer, receiving a selection
from the first consumer indicating desired usage rights and
meta-rights, and generating a first license granting the desired
usage rights and meta-rights to the first consumer. The exemplary
embodiments further include a system for transferring usage rights
adapted to be associated with an item to be licensed in multi-tier
channels of distribution with downstream rights and conditions
assigned at least one level. The system includes a supplier
component, comprising a supplier user interface module, an offer
generator module for generating an offer containing at least usage
rights and of meta-rights, a rights composer module for composing a
draft license, and a repository for supplier's rights, a supplier
management database. The system further includes a consumer
component comprising a consumer user interface module, an
offer-consideration module configured to analyze the offers
generated by the supplier component and select offers based on the
analysis, and a repository for consumer's rights, a consumer
management database. The exemplary embodiments still further
include a method for generating a license to digital content to be
used within a system for at least one of managing use and
distribution of the digital content. The method includes presenting
a consumer with an offer including meta-rights, receiving a
selection by the consumer of at least one meta-right in the offer,
generating a license based on the selection, wherein the license
permits the consumer to exercise the at least one meta-right and
permits the consumer to offer at least one derived right derived
from the at least one meta-right and generate a license including
the at least one derived right.
[0085] FIG. 12 illustrates an exemplary system including a common
state-of-rights server, according to the present invention. In FIG.
12, the exemplary system can include a common state-of-rights
server of the system 1201, including a state-of-rights manager
1209, and one or more state-of-rights repositories 1214, and one or
more license servers 1200, including a meta-rights manager 1210, a
usage rights manager 1212, an authorization component 1208, a
condition validator 1206, a state-of-rights manager 1204, one or
more state-of-rights repositories 1216, a license manager 1203, a
license interpreter 1202, and one or more license repositories
1218.
[0086] The common state-of-rights server 1201 can be configured as
a remote server connected with one or more of the license servers
1200. The common state-of-rights server 1201 provides comparable
services as the state-of-rights manager 1204 in the license servers
1200 via the state-of-rights manager 1209. The services provided by
the state-of-rights server 1201 are accessible and states that the
server 1201 manages can be shared by one or more rights suppliers
and rights consumers (not shown).
[0087] The state-of-rights server 1201 can be configured as a
remote server connected with one or more of the license servers
1200 via one or more communication links 1220, and the like. The
services provided by the state-of-rights server 1201 also can be
integrated within one or more of the license server 1200 and such
services can be accessible by other rights suppliers, rights
consumers, and the like.
[0088] The license manager 1203 derives new rights based on an
offer, which can include any suitable machine-readable expression,
and optionally including meta-rights. While deriving rights, the
license manager 1203 can create new state variables to be
associated with derived rights. The creation of state variables and
their scopes can be prescribed in the offer or by some other
function in the system. The state variables can be created in one
or more instances, for example, prior to rights derivation, during
rights derivation, upon fulfillment of conditions, during a first
exercise of rights associated with the state variables, and the
like. The state variables can be designated exclusively for a
specific rights consumer, can be shared among rights consumers, and
can be shared among rights consumers and other entities, such as
rights suppliers, and the like. The license manager 1203 can
interact with the state-of-rights manager 1204 to associate new
state variables with physical addresses in one or more of the
state-of-rights repositories 1216. The state-of-rights manager 1204
can access the one or more state-of-rights repositories 1216 and
can interact with the state-of-rights server 1201 to access shared
state variables from one or more of the state-of-rights
repositories 1214.
[0089] Designated state variables can be used to support a license
that grants a recipient of the license a right to print content 5
times, shared state variables can be used to support a site license
that grants a group of authorized users a right to print content an
aggregated total of 100 times, and the like. A designated state
variable can be updated when the corresponding right is exercised,
whereas a shared state variable can be updated when an authorized
user exercises the corresponding right. In other words, a shared
state variable can include a data variable that is updated in
response to actions by a plurality of users and which is globally
applied to each of the users.
[0090] There are multiple ways to specify the scope of state
variables, each of which can affect whether the derivative state
variables can be shared, how the derivative state variables can be
shared, and the like. For example, a state variable can be local,
and solely confined to a recipient or can be global, and shared by
a predetermined group of recipients. A global state variable can be
shared by a group of recipients not determined when derived rights
are issued, but to be specified later, perhaps based on certain
rules defined in the license or based on other means. A global
state variable can be shared between one or more rights suppliers,
predetermined recipients, un-specified recipients, and the like.
Advantageously, depending on the sharing employed with a given a
business model and the rights granted in the meta-rights, state
variables can be created at different stages of the value
chain.
[0091] A set of non-exhaustive exemplary usages of state variables
will now be described. For example, a state variable can be
unspecified in meta-rights, which means the identifier and value of
the state variable are yet to be determined by the meta-rights
manager module 1210 and included in the derived right. If a
distinct state variable is assigned to each derived right, the
scope of the state variable in the derived right is typically
exclusive to the recipient.
[0092] FIG. 13 is used to illustrate employing of a state variable
in deriving exclusive usage rights, according to the present
invention. In FIG. 13, rights 1302 and 1303 derived from an offer
1301 are exclusive to each respective consumer. The offer 1301 is a
type of meta-right of which the recipients have the rights to
obtain specific derivative rights when the conditions for obtaining
such rights are satisfied. Accordingly, the exemplary offer 1301
has an unspecified state variable 1304. However, specific state
variable 1305 and 1306, each with uniquely assigned identifications
(IDs) are included in the derived rights 1302 and 1303. The derived
state variables 1305 and 1306 are bound to their associated derived
rights, e.g., "AlicePlayEbook" (i.e., Alice has the right to play
Ebook) is bound to derived right 1302, and "BobPlayEbook" (i.e.,
Bob has the right to play Ebook) is bound to derived right 1303 The
"AlicePlayEbook" variable can be updated when Alice exercises her
play right, whereas the "BobPlayEbook" variable can be updated when
Bob exercises his play right.
[0093] Other than deriving rights from an offer, a right can
transfer from an entity to a recipient. When a right is
transferred, the governing of the associated state variable is also
transferred to the recipient. After a right is transferred, the
source principal typically can no longer exercise the right,
whereas the recipient can exercise the right. The license server
governing the exercising of a right of a recipient assumes the
responsibility for state management. If, however, the state
variables are managed by the common state of right server 1201, the
state of right server 1201 needs to be informed of the transfer of
right. Specifically, the state variable can be managed in the
context of the recipient after the transfer of right.
[0094] When a right is to be shared between the source principal
and the recipient, the associated state variable is referenced in
the derived right. If the same right is shared with multiple
recipients, then typically all of the recipients share the same
state variables with the source principal. In this case, a shared
state can be managed by an entity that is accessible by all sharing
principals.
[0095] FIG. 14 is used to illustrate employing of a state variable
in deriving inherited usage rights, according to the present
invention. In FIG. 14, a derived right can inherit a state variable
from meta-rights. For example, a personal computer (PC) of a user,
Alice, can be configured to play an e-book according to a license
1403. A personal data assistant (PDA) of Alice also can obtain a
right to play the e-book according to offer 1401, if the PC and PDA
share the same state variables 1404 and 1405, e.g.,
"AlicePlayEbook." A derived right 1402 allows Alice also to play
the e-book on her PDA as long as the PDA and the PC share a same
count limit 1406 of 5 times.
[0096] When a usage right is to be shared among a predetermined set
of recipients, a state variable for tracking a corresponding usage
right can be specified in a meta-right using a same state variable
identification for all recipients. During a process of exercising
the meta-right, the same state variable identification is included
in every derived right.
[0097] FIG. 15 illustrates the use of state variable in deriving
rights that are shared among a known set of rights recipients,
according to the present invention. In FIG. 15, a site license 1501
is issued to FooU university. For example, via the site license
1501, a librarian is granted a right to issue rights that allow
FooU students to play, view, and the like, corresponding content,
such as e-books and the like, as long as such usage is tracked by a
state variable 1504, e.g., "www.foou.edu." Accordingly, rights 1502
and 1503 derived from the site license 1501 include state variables
1505 and 1506, "www.foou.edu," which can be updated when
corresponding students, Alice and Bob, play the e-book.
[0098] When a usage right is to be shared among a dynamic set of
recipients, the state variable can stay unspecified in the usage
right. When exercising a meta-right and a set of recipients is
known, a state variable can be specified using some identification
unique to the known recipients and can be included within a derived
right.
[0099] FIG. 16 is used to illustrate employing of a state variable
in deriving rights that are shared among a dynamic set of rights
recipients, according to the present invention. In FIG. 16, an
offer 1601 specifies that a distributor can issue site licenses to
affiliated clubs, allowing 5 members of each club to concurrently
view, play, and the like, content, such as an e-book. A
corresponding state variable 1607 associated with such a right can
be unspecified in the offer 1601. When corresponding rights 1602
and 1603 are issued to affiliated clubs, the corresponding club
identities are used to specify state variables 1608 and 1609 in the
issued rights. The offers 1602 and 1603 are meta-rights derived
from the offer 1601, with offer being assigned the distinct state
variables 1608 and 1609. Further rights 1604-1606 can be derived
from the offers 1602 and 1603 to be shared among members of each
respective club. The licenses 1604 and 1605 are examples of rights
derived from the offer 1602, and which inherit the state variable
1608, e.g., "urn:acme:club," whereas the license 1606 inherits the
state variable 1609, e.g., "urn:foo:club."
[0100] Not only can state variables be shared among principals,
such as rights suppliers, consumers, and the like, a state variable
can be shared among multiple exercisable rights. FIG. 17 is used to
illustrate employing of a state variable for maintaining a state
shared by multiple rights, according to the present invention. In
FIG. 17, a same state variable 1703 is associated to both a right
to print 1702 and the right to play 1701, so that the total number
of playing, printing, and the like, can be tracked together.
[0101] The state of rights can depend on more than one state
variable. FIG. 18 is used to illustrate employing of multiple state
variables to represent one state of rights, according to the
present invention. The example described with respect to FIG. 18
builds upon the example described with respect to FIG. 16. In FIG.
18, a usage right can be tracked by employing multiple state
variables 1807 and 1808 in an offer 1801. The state variable 1808,
for example, representing a priority level, can stay unspecified in
the corresponding offers 1802 and 1803 (e.g., site licenses). The
corresponding state variables 1809-1811, for example, used for
setting a priority, can be assigned to each member in the
corresponding licenses 1804, 1805 and 1806. The corresponding right
to view, play, and the like, can now be dependent on two state
variables, effectively restricting 5 simultaneous views, plays, and
the like, per priority level.
[0102] One state variable can represent a collection of states. For
example, a unique identification can be used to represent a state
variable, and an appropriate mechanism can be employed to map such
unique id to a database of multiple variables, where each variable
represents a distinct state.
[0103] The scope of state variables can be used to determine
entities by which the state variables can be managed. For example,
for a local state variable, usage tracking of associated rights
thereof can be managed solely by a trusted agent embedded within a
rights consumption environment, such as a media player, and the
like. In addition, such usage tracking can be conducted by a
trusted remote service, such as the common state-of-rights server
1201. Further, shared global state variables can be made accessible
by multiple trusted agents. To avoid privacy issues, security
issues, trust issues, rights issues, and the like, associated with
accessing content, such as data, and the like, included within a
peer rights consumption environment, managing of such shared global
state variables can be performed by a remote service, such as the
state-of-rights server 1201.
[0104] A counter is a common form of state variable usage. For
example, such state sharing can include counter sharing where a
state represents a number of times a right has been exercised, an
event has occurred, and the like. Such counter sharing can be
manifested in various forms and occur in many contexts, such as:
tracking a number of simultaneous uses, tracking a number of
sequential uses, sequencing (e.g., a commercial must be viewed
before free content can be accessed), a one-time use constraint, a
transaction count, a delegation control level, a super-distribution
level, dependency on at least one or more services or devices, and
the like.
[0105] In addition, state variables can be incarnated in a wide
variety of forms. For example, a state variable can be used to
track specific time slots within a period of time, such as used by
a movie studio to transfer syndication rights to a specific TV
station, to transfer syndication rights shared by a group of
stations, to transfer syndication rights assigned through a bidding
process, and the like.
[0106] State variables also can be employed, for example, with
regional selling or distribution rights, in a statement from a
financial clearing house to acknowledge that an appropriate fee has
been paid, as a status of whether a commercial has been watched
before free content can be accessed, and the like.
[0107] Not all rights need be associated with states. FIG. 19 is
used to illustrate a case where not all rights are associated with
states, according to the present invention. In FIG. 19, an offer
1901 allows a user, Alice, to grant an unlimited play right, view
right, and the like, to her PDA. Such a play right need not be
associated with any state. Accordingly, derived right 1902 also has
an unlimited play right to the content, as well as the right 1903
for her PC.
[0108] Not all rights which are associated with states are shared
or inherited. For example, some rights are meant for off-line
usage, can be transferred in whole to another device, and hence are
not shared with other devices. FIG. 20 is used to illustrate a case
where not all rights which are associated with states are shared or
inherited, according to the present invention. In FIG. 20, even
though a play right 2003 of a user, Alice, a play right 2002 of a
PDA of Alice, and a play right 2003 of a PC of Alice specify a same
state variable identification 2004, a same state need not be shared
since each device can track a state thereof locally.
Advantageously, such an implementation would allow the PC and the
PDA to each play the corresponding content up to 5 times.
[0109] FIG. 21 illustrates a form of an offer which does not
explicitly include meta-rights. In FIG. 21, an offer 2101 is
configured as a site license written in English. Licenses 2102 and
2103 are instances derived from the offer 2101. In an exemplary
embodiment, variables 2104 and 2105 can be created based on
interpretation of the offer 2101, for example, by the system of
FIG. 12.
[0110] The preferred embodiment can utilize various devices, such
as a personal computers, servers, workstations, PDA's, thin
clients, and the like. For example, the client environment can be a
handheld device such as a mobile phone or a PDA. Various channels
for communication can be used. Further, the various functions can
be integrated in one device. For example, the license server
function can be accomplished by software within the client
environment. Further, the function of the license server or other
modules for making offers, selecting rights and granting licenses
can be accomplished in the same device. The disclosed functional
modules are segregated by function for clarity. However, the
various functions can be combined or segregated as hardware and/or
software modules in any manner. The various functions can be useful
separately or in combination.
[0111] The various elements and portions thereof can be stored on
the same device or on different devices. For example, a license can
be stored together with, or separate from, content. Further, the
various elements of a license can be stored on separate devices.
For example the values of state variables can be stored in a state
variable repository of a system that tracks the current value of
state variables. Various links, references, specifications, and the
like can be used to associate the elements.
[0112] The invention has been described through exemplary
embodiments and examples. However, various modifications can be
made without departing from the scope of the invention as defined
by the appended claims and legal equivalents.
* * * * *