content guard huawei - US China Trade War Blog

content guard huawei - US China Trade War Blog
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 1 of 65 PageID #: 1
IN THE UNITED STATES DISTRICT COURT
FOR THE EASTERN DISTRICT OF TEXAS
MARSHALL DIVISION
ContentGuard Holdings, Inc.,
Plaintiff,
-against-
Civil Action No. 2:13-cv-1112
Amazon.com, Inc.; Apple Inc.; BlackBerry
Corporation (fka Research In Motion
Corporation); Huawei Device USA, Inc.; and
Motorola Mobility LLC.
JURY TRIAL DEMANDED
Defendants.
COMPLAINT FOR PATENT INFRINGEMENT
ContentGuard Holdings, Inc. (“ContentGuard”), by and through its undersigned
attorneys, based upon personal knowledge with respect to its own actions and on information and
belief as to other matters, for its complaint avers as follows:
THE PARTIES
A.
ContentGuard
1.
ContentGuard is a leading innovator, developer, and licensor of digital rights
management (“DRM”) and related digital content distribution products and technologies.
ContentGuard is a corporation organized under the laws of the state of Texas with its principal
place of business at 6900 N. Dallas Parkway, Suite 850, Plano, Texas, 75024.
2.
ContentGuard’s long history of innovation in the DRM space began in the 1990s
at Xerox Corporation’s legendary Palo Alto Research Center (“Xerox PARC”), where brilliant
scientists envisioned a future in which people would rely on the Internet to supply the broadest
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 2 of 65 PageID #: 2
array of digital content the world had ever seen. At that time, however, no one had yet invented
an effective means to prevent piracy of digital content, which could be readily copied and
distributed by personal computers. Many believed that the problem was essentially unsolvable—
and that, as a consequence, the distribution of movies, videos, music, books, “apps,” and other
digital content over the Internet would be blocked by copyright owners and others with a vested
interest in protecting such content.
3.
A well-known commentator—John Perry Barlow—summarized the “digitized
property” challenge as follows: “If our property can be infinitely reproduced and instantaneously
distributed all over the planet without cost, without our knowledge, without its even leaving our
possession, how can we protect it? How are we going to get paid for the work we do with our
minds? And, if we can’t get paid, what will assure the continued creation and distribution of
such work? Since we don’t have a solution to what is a profoundly new kind of challenge, and
are apparently unable to delay the galloping digitization of everything not obstinately physical,
we are sailing into the future on a sinking ship.”
4.
While they fully understood the “profoundly new kind of challenge” posed by the
arrival of the Internet, Xerox PARC’s scientists had a different vision of the future, firmly
believing that a solution to what Barlow called the “immense, unsolved conundrum . . . of
digitized property” could in fact be found. Xerox PARC’s scientists thus began to explore DRM
solutions that would not only prevent piracy, but would also enable musicians, authors,
photographers, publishers, and producers to share, track, and control their content. Through a
series of revolutionary inventions in the 1990s, Xerox PARC’s scientists laid the technological
foundation for what would ultimately become the prevailing paradigm for distributing digital
content over the Internet.
-2-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 3 of 65 PageID #: 3
5.
In 2000, Xerox Corporation partnered with Microsoft Corporation to form a new
company, ContentGuard, to pursue the DRM business. Xerox contributed key personnel, as well
as all of its then-existing and future DRM-related inventions and technologies to ContentGuard.
In the press release announcing the formation of ContentGuard, Steve Ballmer, Microsoft’s
President and Chief Executive Officer, hailed ContentGuard’s innovations in the DRM space,
noting that “the secure and safe delivery of digital media is of primary importance to not only
everyone in the business of content distribution, but consumers of this information as well.” The
joint Xerox and Microsoft press release announcing the formation of ContentGuard, and an
advertisement produced at the time, are attached hereto as Exhibits A and B.
6.
Staffed by a team of scientists and technology veterans from Xerox and
Microsoft, ContentGuard continued its path of innovation, developing both hardware and
software solutions to solve the vexing problem of digital piracy. ContentGuard has invested
more than $100 million to develop these DRM solutions and bring them to market.
7.
ContentGuard expanded its commitment to research and innovation by
developing end-to-end DRM systems and products embodying ContentGuard’s inventions, an
effort that continues today. ContentGuard also provided DRM research expertise to various
industry players that wished to have the freedom to custom-build and operate their own DRM
systems. In addition to its extensive collaboration with Microsoft, ContentGuard also partnered
with companies such as Hewlett-Packard, Adobe, TimeWarner, and Accenture to assist them in
developing DRM solutions.
8.
To further accelerate the evolution of the marketplace for digital content,
ContentGuard also led the way in enabling industry groups to better understand DRM system
requirements and to develop appropriate DRM specifications and industry standards that would
-3-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 4 of 65 PageID #: 4
allow for DRM interoperability between content providers, distributors, and device
manufacturers.
Among other things, recognizing the need for standardized mechanisms to
facilitate trusted interoperability between DRM systems, ContentGuard engineers developed a
standards-based rights description language called eXtensible Rights Markup Language
(“XrML”). XrML, which is deployed in Microsoft DRM products, advanced the state of the art
of rights expression languages by introducing features such as improved identification
capabilities of the digital resource, user, and issuer.
9.
ContentGuard’s important contributions to the DRM field have been widely
recognized. The New York Times hailed ContentGuard as a “pioneer in th[e] field of digitalrights management.”
The Los Angeles Times similarly noted that ContentGuard held “the
technological building blocks necessary to make the digital delivery of music, movies and other
files secure.” Another market commentator remarked that ContentGuard “has almost singlehandedly driven DRM interoperability.”
10.
To this day, ContentGuard continues to innovate and invest in researching new
and innovative DRM technologies and products that enable the distribution of rich multimedia
content on smartphones, tablets, e-readers, laptop computers, smart televisions, set top boxes,
and other electronic devices manufactured and sold worldwide.
Among other things,
ContentGuard recently released an “app” under its own name that allows users to share
documents, PDFs, and photos securely and privately. To determine the areas of research and
development investment, ContentGuard leverages the expertise of its engineers and product
development team.
11.
ContentGuard’s DRM innovations remain immensely relevant—and immensely
valuable—today. The availability of rich multimedia content is a key driver of the enormous
-4-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 5 of 65 PageID #: 5
success experienced by manufacturers of devices such as smartphones, tablets, and e-readers—
including Defendants—whose commercial value is largely driven by the capability of such
devices to download, play, and display digital content. Without effective DRM protection, many
owners of digital content would not allow their content to be available on those devices. As the
president of the World Wide Web Consortium remarked in pointed language “Reject DRM and
you risk walling off parts of the web.”
12.
Virtually every smartphone, tablet, and e-reader produced and sold around the
world relies on ContentGuard’s DRM technology. ContentGuard’s new content-sharing “app”
and other products that are currently under development similarly rely on ContentGuard’s
foundational DRM technology. Without that technology, many companies that invest billions of
dollars to produce movies, videos, books, music, and “apps” would be unwilling to distribute
such digital content over the Internet.
B.
The Defendants
13.
Defendant Amazon.com Inc. (“Amazon”) is a corporation organized under the
laws of the State of Delaware and registered to do business in the State of Texas, with a principal
place of business at 410 Terry Ave, North Seattle, WA 98109. Amazon is doing business and
infringing ContentGuard’s DRM patents in the Eastern District of Texas and elsewhere in the
United States.
14.
Defendant Apple, Inc. (“Apple”) is a corporation organized under the laws of
California and registered to do business in the State of Texas, with a principal place of business
is 1 Infinite Loop, Cupertino, CA 95014. Apple is doing business and infringing ContentGuard’s
DRM patents in the Eastern District of Texas and elsewhere in the United States.
15.
BlackBerry Corporation (“BlackBerry,” fka Research In Motion Corporation) is a
corporation organized and existing under the laws of the State of Delaware and registered to do
-5-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 6 of 65 PageID #: 6
business in the State of Texas, with a principal place of business at 5000 Riverside Drive, Irving,
Texas 75039. BlackBerry is doing business and infringing ContentGuard’s DRM patents in the
Eastern District of Texas and elsewhere in the United States.
16.
Huawei Device USA, Inc. (“Huawei”) is a corporation organized and existing
under the laws of Texas and registered to do business in the State of Texas, with a principal place
of business at 5700 Tennyson Parkway Suite 500, Plano, TX 75024. Huawei is doing business
and infringing ContentGuard’s DRM patents in the Eastern District of Texas and elsewhere in
the United States.
17.
Defendant Motorola Mobility LLC (“Motorola”) is a corporation organized and
existing under the laws of Delaware and registered to do business in the State of Texas, with a
principal place of business at 1303 East Algonquin Road, Schaumberg, Illinois. Motorola is
doing business and infringing ContentGuard’s DRM patents in the Eastern District of Texas and
elsewhere in the United States.
JURISDICTION AND VENUE
18.
This is a civil action arising in part under laws of the United States relating to
patents (35 U.S.C. §§ 271, 281, 283, 284, and 285). This court has federal jurisdiction of such
federal question claims pursuant to 28 U.S.C. §§ 1331 and 1338(a).
19.
Personal jurisdiction is proper in the State of Texas and in this judicial district.
Among other things, Defendants conduct business, sell infringing products, and are engaged in
activities that lead to infringement of ContentGuard’s DRM patents in the State of Texas and in
this judicial district.
20.
Venue is proper under 28 U.S.C. §§ 1391(b) and 1400(b).
-6-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 7 of 65 PageID #: 7
THE PATENTS IN SUIT
21.
On November 8, 2005, the USPTO duly and legally issued United States Patent
No. 6,963,859 (“the ’859 Patent”) entitled “Content rendering repository.” ContentGuard holds
all right, title and interest to the ’859 Patent. A true and correct copy of the ’859 Patent is
attached as Exhibit C.
22.
On April 21, 2009, the USPTO duly and legally issued United States Patent No.
7,523,072 (“the ’072 Patent”) entitled “System for controlling the distribution and use of digital
works.” ContentGuard holds all right, title and interest to the ’072 Patent. A true and correct
copy of the ’072 Patent is attached as Exhibit D.
23.
On August 10, 2010, the USPTO duly and legally issued United States Patent No.
7,774,280 (“the ’280 Patent”) entitled “System and method for managing transfer of rights using
shared state variables.” ContentGuard holds all right, title and interest to the ’280 Patent. A true
and correct copy of the ’280 Patent is attached as Exhibit E.
24.
On August 16, 2011, the USPTO duly and legally issued United States Patent No.
8,001,053 (“the ’053 Patent”) entitled “System and method for rights offering and granting using
shared state variables.” ContentGuard holds all right, title and interest to the ’053 Patent. A true
and correct copy of the ’053 Patent is attached as Exhibit F.
25.
On September 11, 2007, the USPTO duly and legally issued United States Patent
No. 7,269,576 (“the ’576 Patent”) entitled “Content rendering apparatus.” ContentGuard holds
all right, title and interest to the ’576 Patent. A true and correct copy of the ’576 Patent is
attached as Exhibit G.
26.
On February 5, 2013, the USPTO duly and legally issued United States Patent No.
8,370,956 (“the ’956 Patent”) entitled “System and method for rendering digital content in
-7-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 8 of 65 PageID #: 8
accordance with usage rights information.” ContentGuard holds all right, title and interest to the
’956 Patent. A true and correct copy of the ’956 Patent is attached as Exhibit H.
27.
On March 5, 2013, the USPTO duly and legally issued United States Patent No.
8,393,007 (“the ’007 Patent”) entitled “System and method for distributing digital content in
accordance with usage rights information.” ContentGuard holds all right, title and interest to the
’007 Patent. A true and correct copy of the ’007 Patent is attached as Exhibit I.
28.
On May 29, 2007, the USPTO duly and legally issued United States Patent No.
7,225,160 (“the ’160 Patent”) entitled “Digital works having usage rights and method for
creating the same.” ContentGuard holds all right, title and interest to the ’160 Patent. A true and
correct copy of the ’160 Patent is attached as Exhibit J.
29.
On November 12, 2013, the USPTO duly and legally issued United States Patent
No. 8,583,556 (“the ’556 Patent”) entitled “Method for providing a digital asset for distribution.”
ContentGuard holds all right, title and interest to the ’556 Patent. A true and correct copy of the
’556 Patent is attached as Exhibit K.
CONTENTGUARD’S EFFORTS TO LICENSE DEFENDANTS’ USE OF ITS DRM
TECHNOLOGIES
30.
Throughout its history, ContentGuard has prided itself in being an innovator and
leader in the DRM field. ContentGuard’s revolutionary DRM technologies are embodied in its
extensive portfolio of DRM patents and patent applications, which was developed during the past
two decades and now comprises over 300 issued patents and 160 pending applications.
31.
Following its early partnerships with companies such as Hewlett-Packard, Adobe,
Microsoft, Technicolor and TimeWarner, ContentGuard successfully licensed its DRM
technologies for use in smartphones and tablets to companies around the world, including Casio,
Fujitsu, Hitachi, LG Electronics, NEC, Nokia, Panasonic, Pantech, Sanyo, Sharp, Sony, Toshiba,
-8-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 9 of 65 PageID #: 9
and others.
These companies embraced ContentGuard’s DRM technologies and agreed to
license use of those technologies for substantial royalties.
32.
ContentGuard’s numerous patent license agreements were executed without
ContentGuard having to take legal action, or even threaten litigation, to protect its intellectual
property rights.
33.
Defendants have refused to take a license, instead choosing to infringe
ContentGuard’s DRM patents and free-ride, notwithstanding ContentGuard’s willingness to
accept the fair and reasonable terms agreed to by Defendants’ competitors.
34.
ContentGuard has made numerous attempts to negotiate a license agreement with
Amazon. Despite ContentGuard’s good-faith efforts, Amazon has refused to pay for its use of
ContentGuard’s DRM technologies.
35.
ContentGuard has made numerous attempts to negotiate a license agreement with
Apple. Despite ContentGuard’s good-faith efforts, Apple has refused to pay for its use of
ContentGuard’s DRM technologies.
36.
ContentGuard has made numerous attempts to negotiate a license agreement with
BlackBerry. Despite ContentGuard’s good-faith efforts, BlackBerry has refused to pay for its
use of ContentGuard’s DRM technologies.
37.
ContentGuard has made numerous attempts to negotiate a license agreement with
Huawei. Despite ContentGuard’s good-faith efforts, Huawei has refused to pay for its use of
ContentGuard’s DRM technologies.
38.
ContentGuard has made numerous attempts to negotiate a license agreement with
Motorola. Despite ContentGuard’s good-faith efforts, Motorola has refused to pay for its use of
ContentGuard’s DRM technologies.
-9-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 10 of 65 PageID #: 10
39.
Defendants’ refusal to agree to pay for their use of ContentGuard’s DRM
technologies on the fair and reasonable terms and conditions agreed to by competitors has left
ContentGuard no choice but to commence this litigation.
DEFENDANTS’ COMMON ACTS OF INFRINGEMENT
40.
Defendants are properly joined in this action because (a) ContentGuard’s claims
herein are based on the same transaction(s), occurrence(s) or series of transactions or occurrences
relating to Defendants’ making, using, offering for sale, and selling of the accused products and
processes; and (b) questions of fact common to all Defendants will arise in the action.
41.
For example, all Defendants (a) provide access to the Amazon Kindle “app,”
either preloaded or via their online stores, on one or more of their devices, (b) provide hardware
and software components required by the claims of the ContentGuard DRM patents to enable the
Kindle DRM solution to operate on their devices, and/or (c) test the Amazon Kindle “app” to
ensure it will work reliably for users of their devices. These devices include, merely by way of
example, the Apple iPad, the Amazon Kindle Fire, the BlackBerry Z10, the Huawei Ascend, and
the Motorola Moto X. In each of these devices and many other devices supplied by Defendants,
the Amazon Kindle “app” is and has been used to practice ContentGuard’s DRM patents.
42.
In addition, there is a logical relationship and many actual links between the
infringement claims against the Defendants arising out of their common use of the Amazon
Kindle “app.” Amazon supplies the Kindle “app” that is used by all Defendants and/or their
customers to practice the claimed inventions, and the Kindle “app” operates the same way
relative to the patents in providing the claimed DRM functionality on Defendants’ products.
Moreover, on information and belief, there are licensing and/or technology agreements between
Amazon and the other Defendants in connection with the Kindle “app,” and, on information and
belief, Amazon and the other Defendants collaborate in developing, testing, supporting, and/or
-10-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 11 of 65 PageID #: 11
optimizing the Kindle “app” for the different accused products. These are just a few of the many
actual links between the infringement claims against Amazon and the other Defendants
indicating that all the Defendants have been properly joined in this action.
43.
Similarly, on information and belief, each of the Defendants have accused
products and methods that use one or more of the Google Play “apps” (Google Play Books,
Google Play Movies, and Google Play Music) to practice the claimed inventions. For example,
Google Play Books and Google Play Music are available and have been used in accused devices
made by each of the Defendants, including, merely by way of example, the Apple iPad, the
Amazon Kindle Fire, the BlackBerry Z10, the Huawei Ascend, and the Motorola Moto X. In
each of these devices and many other devices supplied by Defendants, Google Play Books and
Google Play Music are and have been used to practice ContentGuard’s DRM patents. In
addition, Google Play Movies is and has been used to practice ContentGuard’s DRM patents on
accused devices.
44.
In addition, there is a logical relationship and many actual links between the
infringement claims against the Defendants arising out of their common use of the Google Play
“apps”. Google supplies the Google Play “apps” that are used by all Defendants to practice the
claimed inventions, and the Google Play “apps” operate the same way relative to the patents in
providing the claimed DRM functionality on Defendants’ products. These are just a few of the
many actual links between the infringement claims against the Defendants in relation to the
Google Play “apps” indicating that all the Defendants have been properly joined in this action.
45.
Similarly, on information and belief, each of the Defendants have accused
products and methods that implement one or more versions of a standard known as Unique
Identifier Technology Solution or “UITS.” UITS is a specification that describes a way to
-11-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 12 of 65 PageID #: 12
embed metadata into unprotected media files so that it is possible to detect when the metadata is
modified. The UITS specification requires metadata about the content and distributor, and
identifiers that distinguish between different purchase events. The metadata is arranged in a
standard way and is cryptographically signed so that tampering can be detected. UITS can be
used for a number of different purposes, such as communicating the copyright or parental
advisory status of a file, verifying retailer sales, transporting redemption codes, and more.
Products practicing the UITS specification infringe at least the ’556 patent. Accused devices
made by each of the Defendants, including, merely by way of example, the Apple iPad, the
Amazon Kindle Fire, the BlackBerry Z10, the Huawei Ascend, and the Motorola Moto X,
practice the UITS specification.
46.
For these reasons, infringement issues in this case will include for all defendants
common questions of fact concerning the Kindle application, the Google Play “apps,” and the
UITS specification, resulting in substantial evidentiary overlap with respect to the design and
operation of the accused devices, as applied to the claims of the asserted patents.
COUNT 1: INFRINGEMENT OF THE ’859 PATENT
(AGAINST ALL DEFENDANTS)
47.
Paragraphs 1 through 46 are incorporated by reference as if fully stated herein.
48.
Amazon has been and is now directly infringing and/or indirectly infringing the
’859 Patent by way of inducement and/or contributory infringement, literally and/or under the
doctrine of equivalents, in this District, and elsewhere, in violation of 35 U.S.C. § 271, including
by making, using, selling, and/or offering for sale in the United States or importing into the
United States products covered by at least one claim of the ’859 Patent. Amazon has notice of
the ’859 Patent. Amazon actively induces content providers and/or end users of Amazon
-12-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 13 of 65 PageID #: 13
products to infringe the ’859 Patent by, among other things, (a) providing access to certain
“apps” (such as the iTunes client, the Amazon Kindle, Amazon Instant Video, and/or Google
Play “apps”) that use the ContentGuard DRM solution claimed in the ’859 Patent, (b) providing
instructions for using such “apps”; (c) providing advertisings for using such “apps”; and (d)
providing hardware and software components required by the claims of the ’859 Patent.1
Amazon engages in the foregoing activities because it specifically intends end users of Amazon
products to use “apps” that deploy, and content providers to distribute content that is protected
by, the ContentGuard DRM solutions claimed in the ’859 Patent. Amazon thereby specifically
intends end users and content providers to infringe the ’859 Patent. Amazon derives revenue
from both its own and the third-party infringers’ infringing activities. Indeed, Amazon’s ability
to sell the accused products is wholly dependent upon the availability of these “apps” and the
digital content they make available to users. Amazon also contributorily infringes the ’859
Patent because there is no substantial non-infringing use of these “apps” on the accused Amazon
products. These “apps” cannot be used with accused Amazon products without infringing the
’859 Patent.
49.
Apple has been and is now directly infringing and/or indirectly infringing the ’859
Patent by way of inducement and/or contributory infringement, literally and/or under the
doctrine of equivalents, in this District, and elsewhere, in violation of 35 U.S.C. § 271, including
by making, using, selling, and/or offering for sale in the United States or importing into the
1
See, e.g., http://www.amazon.com/kindle-fire-hd-best-family-kids-tablet/dp/B00CU0NSCU;
http://www.amazon.com/gp/help/customer/display.html?nodeId=201240840;
http://www.amazon.com/gp/feature.html/ref=kcp_iph_ln_ar?docId=1000301301;
http://www.amazon.com/gp/help/customer/display.html?nodeId=200729450;
http://www.amazon.com/gp/help/customer/display.html?nodeId=201009460;
http://www.amazon.com/kindle-fire-hd-best-family-kids-tablet/dp/B00CU0NSCU;
https://developer.amazon.com/sdk/fire/specifications.html.
-13-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 14 of 65 PageID #: 14
United States products covered by at least one claim of the ’859 Patent. Apple has notice of the
’859 Patent. Apple actively induces content providers and/or end users of Apple products to
infringe the ’859 Patent by, among other things, (a) providing access to certain “apps” (such as
the iTunes client, the Amazon Kindle, Amazon Instant Video, and/or Google Play “apps”) that
use the ContentGuard DRM solution claimed in the ’859 Patent, (b) providing instructions for
using such “apps”; (c) providing advertisings for using such “apps”; and (d) providing hardware
and software components required by the claims of the ’859 Patent.2 Apple engages in the
foregoing activities because it specifically intends end users of Apple products to use “apps” that
deploy, and content providers to distribute content that is protected by, the ContentGuard DRM
solutions claimed in the ’859 Patent. Apple thereby specifically intends end users and content
providers to infringe the ’859 Patent. Apple derives revenue from both its own and the thirdparty infringers’ infringing activities. Indeed, Apple’s ability to sell the accused products is
wholly dependent upon the availability of these “apps” and the digital content they make
available to users. Apple also contributorily infringes the ’859 Patent because there is no
substantial non-infringing use of these “apps” on the accused Apple products. These “apps”
cannot be used with accused Apple products without infringing the ’859 Patent.
50.
BlackBerry has been and is now directly infringing and/or indirectly infringing
the ’859 Patent by way of inducement and/or contributory infringement, literally and/or under
2
See, e.g., http://www.apple.com/itunes/features/#store;
http://www.apple.com/itunes/;
https://itunes.apple.com/in/app/kindle/id302584613;
https://itunes.apple.com/us/app/google-play-books/id400989007;
https://itunes.apple.com/us/app/app-for-google-music-free/id485638799;
https://itunes.apple.com/us/app/google-tv-remote/id422137859?l=es&mt=8;
http://www.apple.com/in/iphone-5s/specs/;
http://www.apple.com/in/ipad/specs/;
http://www.apple.com/in/ipod-touch/specs.html.
-14-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 15 of 65 PageID #: 15
the doctrine of equivalents, in this District, and elsewhere, in violation of 35 U.S.C. § 271,
including by making, using, selling, and/or offering for sale in the United States or importing
into the United States products covered by at least one claim of the ’859 Patent. BlackBerry has
notice of the ’859 Patent. BlackBerry actively induces content providers and/or end users of
BlackBerry products to infringe the ’859 Patent by, among other things, (a) providing access to
certain “apps” (such as the iTunes client, the Amazon Kindle, Amazon Instant Video, and/or
Google Play “apps”) that use the ContentGuard DRM solution claimed in the ’859 Patent, (b)
providing instructions for using such “apps”; (c) providing advertisings for using such “apps”;
and (d) providing hardware and software components required by the claims of the ’859 Patent.3
BlackBerry engages in the foregoing activities because it specifically intends end users of
BlackBerry products to use “apps” that deploy, and content providers to distribute content that is
protected by, the ContentGuard DRM solutions claimed in the ’859 Patent. BlackBerry thereby
specifically intends end users and content providers to infringe the ’859 Patent. BlackBerry
derives revenue from both its own and the third-party infringers’ infringing activities. Indeed,
BlackBerry’s ability to sell the accused products is wholly dependent upon the availability of
these “apps” and the digital content they make available to users. BlackBerry also contributorily
infringes the ’859 Patent because there is no substantial non-infringing use of these “apps” on the
accused BlackBerry products. These “apps” cannot be used with accused BlackBerry products
without infringing the ’859 Patent.
3
See, e.g., http://in.blackberry.com/apps/blackberry-world.html#tab-1;
http://appworld.blackberry.com/webstore/content/25058915/?countrycode=IN&lang=en;
http://appworld.blackberry.com/webstore/content/65525/?countrycode=US&lang=en;
http://in.blackberry.com/apps/blackberry-world.html#tab-1;
http://appworld.blackberry.com/webstore/content/25058915/?countrycode=IN&lang=en;
http://in.blackberry.com/smartphones/blackberry-z30/specifications.html.
-15-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 16 of 65 PageID #: 16
51.
Huawei has been and is now directly infringing and/or indirectly infringing the
’859 Patent by way of inducement and/or contributory infringement, literally and/or under the
doctrine of equivalents, in this District, and elsewhere, in violation of 35 U.S.C. § 271, including
by making, using, selling, and/or offering for sale in the United States or importing into the
United States products covered by at least one claim of the ’859 Patent. Huawei has notice of
the ’859 Patent.
Huawei actively induces content providers and/or end users
of Huawei
products to infringe the ’859 Patent by, among other things, (a) providing access to certain
“apps” (such as the iTunes client, the Amazon Kindle, Amazon Instant Video, and/or Google
Play “apps”) that use the ContentGuard DRM solution claimed in the ’859 Patent, (b) providing
instructions for using such “apps”; (c) providing advertisings for using such “apps”; and (d)
providing hardware and software components required by the claims of the ’859 Patent.4
Huawei engages in the foregoing activities because it specifically intends end users of Huawei
products to use “apps” that deploy, and content providers to distribute content that is protected
by, the ContentGuard DRM solutions claimed in the ’859 Patent. Huawei thereby specifically
intends end users and content providers to infringe the ’859 Patent. Huawei derives revenue
from both its own and the third-party infringers’ infringing activities. Indeed, Huawei’s ability
to sell the accused products is wholly dependent upon the availability of these “apps” and the
digital content they make available to users. Huawei also contributorily infringes the ’859 Patent
4
See, e.g., http://huaweimobile.com;
http://www.huaweidevice.com/worldwide/productMobile.do?method=index&directoryId=6001
&treeId=3745;
http://www.huaweidevice.com/worldwide/productFeatures.do?pinfoId=3298&directoryId=6001
&treeId=3745&tab=0;
http://www.huaweidevice.com/worldwide/technicaIndex.do?method=gotoProductSupport&prod
uctId=3942&tb=0%29;
http://www.huaweidevice.com/worldwide/downloadCenter.do?method=toDownloadFile&flay=d
ocument&softid=NDcxOTM=;
http://www.uscellular.com/uscellular/pdf/huawei-ascend-y-google-play.pdf.
-16-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 17 of 65 PageID #: 17
because there is no substantial non-infringing use of these “apps” on the accused Huawei
products. These “apps” cannot be used with accused Huawei products without infringing the
’859 Patent.
52.
Motorola has been and is now directly infringing and/or indirectly infringing the
’859 Patent by way of inducement and/or contributory infringement, literally and/or under the
doctrine of equivalents, in this District, and elsewhere, in violation of 35 U.S.C. § 271, including
by making, using, selling, and/or offering for sale in the United States or importing into the
United States products covered by at least one claim of the ’859 Patent. Motorola has notice of
the ’859 Patent. Motorola actively induces content providers and/or end users of Motorola
products to infringe the ’859 Patent by, among other things, (a) providing access to certain
“apps” (such as the iTunes client, the Amazon Kindle, Amazon Instant Video, and/or Google
Play “apps”) that use the ContentGuard DRM solution claimed in the ’859 Patent, (b) providing
instructions for using such “apps”; (c) providing advertisings for using such “apps”; and (d)
providing hardware and software components required by the claims of the ’859 Patent.5
Motorola engages in the foregoing activities because it specifically intends end users of Motorola
products to use “apps” that deploy, and content providers to distribute content that is protected
by, the ContentGuard DRM solutions claimed in the ’859 Patent. Motorola thereby specifically
intends end users and content providers to infringe the ’859 Patent. Motorola derives revenue
from both its own and the third-party infringers’ infringing activities. Indeed, Motorola’s ability
5
See, e.g., http://www.motorola.com/us/FLEXR1-1/Moto-X/FLEXR1.html;
https://motorola-globalportal.custhelp.com/app/product_page/faqs/p/30,6720,8882/session/L3RpbWUvMTM4Mzc3MT
A0MS9zaWQvblhuRklIRWw%3D#/how_do_i;
http://www.motorola.com/us/ANDROID/m-Android-Overview.html;
http://www.mobileworldlive.com/verizon-preloads-amazon-kindle-app-on-android-devices;
https://motorola-global-portal.custhelp.com/app/answers/detail/a_id/70762/action/auth.
-17-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 18 of 65 PageID #: 18
to sell the accused products is wholly dependent upon the availability of these “apps” and the
digital content they make available to users. Motorola also contributorily infringes the ’859
Patent because there is no substantial non-infringing use of these “apps” on the accused Motorola
products. These “apps” cannot be used with accused Motorola products without infringing the
’859 Patent.
COUNT 2: INFRINGEMENT OF THE ’072 PATENT
(AGAINST ALL DEFENDANTS)
53.
Paragraphs 1 through 46 are incorporated by reference as if fully stated herein.
54.
Amazon has been and is now directly infringing and/or indirectly infringing the
’072 Patent by way of inducement and/or contributory infringement, literally and/or under the
doctrine of equivalents, in this District, and elsewhere, in violation of 35 U.S.C. § 271, including
by making, using, selling, and/or offering for sale in the United States or importing into the
United States products covered by at least one claim of the ’072 Patent. Amazon has notice of
the ’072 Patent. Amazon actively induces content providers and/or end users of Amazon
products to infringe the ’072 Patent by, among other things, (a) providing access to certain
“apps” (such as the iTunes client, the Amazon Kindle, Amazon Instant Video, and/or Google
Play “apps”) that use the ContentGuard DRM solution claimed in the ’072 Patent, (b) providing
instructions for using such “apps”; (c) providing advertisings for using such “apps”; and (d)
providing hardware and software components required by the claims of the ’072 Patent.6
6
See, e.g., http://www.amazon.com/kindle-fire-hd-best-family-kids-tablet/dp/B00CU0NSCU;
http://www.amazon.com/gp/help/customer/display.html?nodeId=201240840;
http://www.amazon.com/gp/feature.html/ref=kcp_iph_ln_ar?docId=1000301301;
http://www.amazon.com/gp/help/customer/display.html?nodeId=200729450;
http://www.amazon.com/gp/help/customer/display.html?nodeId=201009460;
http://www.amazon.com/kindle-fire-hd-best-family-kids-tablet/dp/B00CU0NSCU;
https://developer.amazon.com/sdk/fire/specifications.html.
-18-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 19 of 65 PageID #: 19
Amazon engages in the foregoing activities because it specifically intends end users of Amazon
products to use “apps” that deploy, and content providers to distribute content that is protected
by, the ContentGuard DRM solutions claimed in the ’072 Patent. Amazon thereby specifically
intends end users and content providers to infringe the ’072 Patent. Amazon derives revenue
from both its own and the third-party infringers’ infringing activities. Indeed, Amazon’s ability
to sell the accused products is wholly dependent upon the availability of these “apps” and the
digital content they make available to users. Amazon also contributorily infringes the ’072
Patent because there is no substantial non-infringing use of these “apps” on the accused Amazon
products. These “apps” cannot be used with accused Amazon products without infringing the
’072 Patent.
55.
Apple has been and is now directly infringing and/or indirectly infringing the ’072
Patent by way of inducement and/or contributory infringement, literally and/or under the
doctrine of equivalents, in this District, and elsewhere, in violation of 35 U.S.C. § 271, including
by making, using, selling, and/or offering for sale in the United States or importing into the
United States products covered by at least one claim of the ’072 Patent. Apple has notice of the
’072 Patent. Apple actively induces content providers and/or end users of Apple products to
infringe the ’072 Patent by, among other things, (a) providing access to certain “apps” (such as
the iTunes client, the Amazon Kindle, Amazon Instant Video, and/or Google Play “apps”) that
use the ContentGuard DRM solution claimed in the ’072 Patent, (b) providing instructions for
using such “apps”; (c) providing advertisings for using such “apps”; and (d) providing hardware
and software components required by the claims of the ’072 Patent.7 Apple engages in the
7
See, e.g., http://www.apple.com/itunes/features/#store;
http://www.apple.com/itunes/;
https://itunes.apple.com/in/app/kindle/id302584613;
-19-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 20 of 65 PageID #: 20
foregoing activities because it specifically intends end users of Apple products to use “apps” that
deploy, and content providers to distribute content that is protected by, the ContentGuard DRM
solutions claimed in the ’072 Patent. Apple thereby specifically intends end users and content
providers to infringe the ’072 Patent. Apple derives revenue from both its own and the thirdparty infringers’ infringing activities. Indeed, Apple’s ability to sell the accused products is
wholly dependent upon the availability of these “apps” and the digital content they make
available to users. Apple also contributorily infringes the ’072 Patent because there is no
substantial non-infringing use of these “apps” on the accused Apple products. These “apps”
cannot be used with accused Apple products without infringing the ’072 Patent.
56.
BlackBerry has been and is now directly infringing and/or indirectly infringing
the ’072 Patent by way of inducement and/or contributory infringement, literally and/or under
the doctrine of equivalents, in this District, and elsewhere, in violation of 35 U.S.C. § 271,
including by making, using, selling, and/or offering for sale in the United States or importing
into the United States products covered by at least one claim of the ’072 Patent. BlackBerry has
notice of the ’072 Patent. BlackBerry actively induces content providers and/or end users of
BlackBerry products to infringe the ’072 Patent by, among other things, (a) providing access to
certain “apps” (such as the iTunes client, the Amazon Kindle, Amazon Instant Video, and/or
Google Play “apps”) that use the ContentGuard DRM solution claimed in the ’072 Patent, (b)
providing instructions for using such “apps”; (c) providing advertisings for using such “apps”;
https://itunes.apple.com/us/app/google-play-books/id400989007;
https://itunes.apple.com/us/app/app-for-google-music-free/id485638799;
https://itunes.apple.com/us/app/google-tv-remote/id422137859?l=es&mt=8;
http://www.apple.com/in/iphone-5s/specs/;
http://www.apple.com/in/ipad/specs/;
http://www.apple.com/in/ipod-touch/specs.html.
-20-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 21 of 65 PageID #: 21
and (d) providing hardware and software components required by the claims of the ’072 Patent.8
BlackBerry engages in the foregoing activities because it specifically intends end users of
BlackBerry products to use “apps” that deploy, and content providers to distribute content that is
protected by, the ContentGuard DRM solutions claimed in the ’072 Patent. BlackBerry thereby
specifically intends end users and content providers to infringe the ’072 Patent. BlackBerry
derives revenue from both its own and the third-party infringers’ infringing activities. Indeed,
BlackBerry’s ability to sell the accused products is wholly dependent upon the availability of
these “apps” and the digital content they make available to users. BlackBerry also contributorily
infringes the ’072 Patent because there is no substantial non-infringing use of these “apps” on the
accused BlackBerry products. These “apps” cannot be used with accused BlackBerry products
without infringing the ’072 Patent.
57.
Huawei has been and is now directly infringing and/or indirectly infringing the
’072 Patent by way of inducement and/or contributory infringement, literally and/or under the
doctrine of equivalents, in this District, and elsewhere, in violation of 35 U.S.C. § 271, including
by making, using, selling, and/or offering for sale in the United States or importing into the
United States products covered by at least one claim of the ’072 Patent. Huawei has notice of
the ’072 Patent.
Huawei actively induces content providers and/or end users
of Huawei
products to infringe the ’072 Patent by, among other things, (a) providing access to certain
“apps” (such as the iTunes client, the Amazon Kindle, Amazon Instant Video, and/or Google
Play “apps”) that use the ContentGuard DRM solution claimed in the ’072 Patent, (b) providing
8
See, e.g., http://in.blackberry.com/apps/blackberry-world.html#tab-1;
http://appworld.blackberry.com/webstore/content/25058915/?countrycode=IN&lang=en;
http://appworld.blackberry.com/webstore/content/65525/?countrycode=US&lang=en;
http://in.blackberry.com/apps/blackberry-world.html#tab-1;
http://appworld.blackberry.com/webstore/content/25058915/?countrycode=IN&lang=en;
http://in.blackberry.com/smartphones/blackberry-z30/specifications.html.
-21-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 22 of 65 PageID #: 22
instructions for using such “apps”; (c) providing advertisings for using such “apps”; and (d)
providing hardware and software components required by the claims of the ’072 Patent.9
Huawei engages in the foregoing activities because it specifically intends end users of Huawei
products to use “apps” that deploy, and content providers to distribute content that is protected
by, the ContentGuard DRM solutions claimed in the ’072 Patent. Huawei thereby specifically
intends end users and content providers to infringe the ’072 Patent. Huawei derives revenue
from both its own and the third-party infringers’ infringing activities. Indeed, Huawei’s ability
to sell the accused products is wholly dependent upon the availability of these “apps” and the
digital content they make available to users. Huawei also contributorily infringes the ’072 Patent
because there is no substantial non-infringing use of these “apps” on the accused Huawei
products. These “apps” cannot be used with accused Huawei products without infringing the
’072 Patent.
58.
Motorola has been and is now directly infringing and/or indirectly infringing the
’072 Patent by way of inducement and/or contributory infringement, literally and/or under the
doctrine of equivalents, in this District, and elsewhere, in violation of 35 U.S.C. § 271, including
by making, using, selling, and/or offering for sale in the United States or importing into the
United States products covered by at least one claim of the ’072 Patent. Motorola has notice of
the ’072 Patent. Motorola actively induces content providers and/or end users of Motorola
9
See, e.g., http://huaweimobile.com;
http://www.huaweidevice.com/worldwide/productMobile.do?method=index&directoryId=6001
&treeId=3745;
http://www.huaweidevice.com/worldwide/productFeatures.do?pinfoId=3298&directoryId=6001
&treeId=3745&tab=0;
http://www.huaweidevice.com/worldwide/technicaIndex.do?method=gotoProductSupport&prod
uctId=3942&tb=0%29;
http://www.huaweidevice.com/worldwide/downloadCenter.do?method=toDownloadFile&flay=d
ocument&softid=NDcxOTM=;
http://www.uscellular.com/uscellular/pdf/huawei-ascend-y-google-play.pdf.
-22-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 23 of 65 PageID #: 23
products to infringe the ’072 Patent by, among other things, (a) providing access to certain
“apps” (such as the iTunes client, the Amazon Kindle, Amazon Instant Video, and/or Google
Play “apps”) that use the ContentGuard DRM solution claimed in the ’072 Patent, (b) providing
instructions for using such “apps”; (c) providing advertisings for using such “apps”; and (d)
providing hardware and software components required by the claims of the ’072 Patent.10
Motorola engages in the foregoing activities because it specifically intends end users of Motorola
products to use “apps” that deploy, and content providers to distribute content that is protected
by, the ContentGuard DRM solutions claimed in the ’072 Patent. Motorola thereby specifically
intends end users and content providers to infringe the ’072 Patent. Motorola derives revenue
from both its own and the third-party infringers’ infringing activities. Indeed, Motorola’s ability
to sell the accused products is wholly dependent upon the availability of these “apps” and the
digital content they make available to users. Motorola also contributorily infringes the ’072
Patent because there is no substantial non-infringing use of these “apps” on the accused Motorola
products. These “apps” cannot be used with accused Motorola products without infringing the
’072 Patent.
COUNT 3: INFRINGEMENT OF THE ’280 PATENT
(AGAINST APPLE, BLACKBERRY, HUAWEI, AND MOTOROLA)
59.
Paragraphs 1 through 46 are incorporated by reference as if fully stated herein.
10
See, e.g., http://www.motorola.com/us/FLEXR1-1/Moto-X/FLEXR1.html;
https://motorola-globalportal.custhelp.com/app/product_page/faqs/p/30,6720,8882/session/L3RpbWUvMTM4Mzc3MT
A0MS9zaWQvblhuRklIRWw%3D#/how_do_i;
http://www.motorola.com/us/ANDROID/m-Android-Overview.html;
http://www.mobileworldlive.com/verizon-preloads-amazon-kindle-app-on-android-devices;
https://motorola-global-portal.custhelp.com/app/answers/detail/a_id/70762/action/auth.
-23-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 24 of 65 PageID #: 24
60.
Apple has been and is now directly infringing and/or indirectly infringing the ’280
Patent by way of inducement and/or contributory infringement, literally and/or under the
doctrine of equivalents, in this District, and elsewhere, in violation of 35 U.S.C. § 271, including
by making, using, selling, and/or offering for sale in the United States or importing into the
United States products covered by at least one claim of the ’280 Patent. Apple has notice of the
’280 Patent. Apple actively induces content providers and/or end users of Apple products to
infringe the ’280 Patent by, among other things, (a) providing access to certain “apps” (such as
the iTunes client, the Amazon Kindle, Amazon Instant Video, and/or Google Play “apps”) that
use the ContentGuard DRM solution claimed in the ’280 Patent, (b) providing instructions for
using such “apps”; (c) providing advertisings for using such “apps”; and (d) providing hardware
and software components required by the claims of the ’280 Patent.11 Apple engages in the
foregoing activities because it specifically intends end users of Apple products to use “apps” that
deploy, and content providers to distribute content that is protected by, the ContentGuard DRM
solutions claimed in the ’280 Patent. Apple thereby specifically intends end users and content
providers to infringe the ’280 Patent. Apple derives revenue from both its own and the thirdparty infringers’ infringing activities. Indeed, Apple’s ability to sell the accused products is
wholly dependent upon the availability of these “apps” and the digital content they make
available to users. Apple also contributorily infringes the ’280 Patent because there is no
11
See, e.g., http://www.apple.com/itunes/features/#store;
http://www.apple.com/itunes/;
https://itunes.apple.com/in/app/kindle/id302584613;
https://itunes.apple.com/us/app/google-play-books/id400989007;
https://itunes.apple.com/us/app/app-for-google-music-free/id485638799;
https://itunes.apple.com/us/app/google-tv-remote/id422137859?l=es&mt=8;
http://www.apple.com/in/iphone-5s/specs/;
http://www.apple.com/in/ipad/specs/;
http://www.apple.com/in/ipod-touch/specs.html.
-24-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 25 of 65 PageID #: 25
substantial non-infringing use of these “apps” on the accused Apple products. These “apps”
cannot be used with accused Apple products without infringing the ’280 Patent.
61.
BlackBerry has been and is now directly infringing and/or indirectly infringing
the ’280 Patent by way of inducement and/or contributory infringement, literally and/or under
the doctrine of equivalents, in this District, and elsewhere, in violation of 35 U.S.C. § 271,
including by making, using, selling, and/or offering for sale in the United States or importing
into the United States products covered by at least one claim of the ’280 Patent. BlackBerry has
notice of the ’280 Patent. BlackBerry actively induces content providers and/or end users of
BlackBerry products to infringe the ’280 Patent by, among other things, (a) providing access to
certain “apps” (such as the iTunes client, the Amazon Kindle, Amazon Instant Video, and/or
Google Play “apps”) that use the ContentGuard DRM solution claimed in the ’280 Patent, (b)
providing instructions for using such “apps”; (c) providing advertisings for using such “apps”;
and (d) providing hardware and software components required by the claims of the ’280 Patent.12
BlackBerry engages in the foregoing activities because it specifically intends end users of
BlackBerry products to use “apps” that deploy, and content providers to distribute content that is
protected by, the ContentGuard DRM solutions claimed in the ’280 Patent. BlackBerry thereby
specifically intends end users and content providers to infringe the ’280 Patent. BlackBerry
derives revenue from both its own and the third-party infringers’ infringing activities. Indeed,
BlackBerry’s ability to sell the accused products is wholly dependent upon the availability of
these “apps” and the digital content they make available to users. BlackBerry also contributorily
12
See, e.g., http://in.blackberry.com/apps/blackberry-world.html#tab-1;
http://appworld.blackberry.com/webstore/content/25058915/?countrycode=IN&lang=en;
http://appworld.blackberry.com/webstore/content/65525/?countrycode=US&lang=en;
http://in.blackberry.com/apps/blackberry-world.html#tab-1;
http://appworld.blackberry.com/webstore/content/25058915/?countrycode=IN&lang=en;
http://in.blackberry.com/smartphones/blackberry-z30/specifications.html.
-25-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 26 of 65 PageID #: 26
infringes the ’280 Patent because there is no substantial non-infringing use of these “apps” on the
accused BlackBerry products. These “apps” cannot be used with accused BlackBerry products
without infringing the ’280 Patent.
62.
Huawei has been and is now directly infringing and/or indirectly infringing the
’280 Patent by way of inducement and/or contributory infringement, literally and/or under the
doctrine of equivalents, in this District, and elsewhere, in violation of 35 U.S.C. § 271, including
by making, using, selling, and/or offering for sale in the United States or importing into the
United States products covered by at least one claim of the ’280 Patent. Huawei has notice of
the ’280 Patent.
Huawei actively induces content providers and/or end users
of Huawei
products to infringe the ’280 Patent by, among other things, (a) providing access to certain
“apps” (such as the iTunes client, the Amazon Kindle, Amazon Instant Video, and/or Google
Play “apps”) that use the ContentGuard DRM solution claimed in the ’280 Patent, (b) providing
instructions for using such “apps”; (c) providing advertisings for using such “apps”; and (d)
providing hardware and software components required by the claims of the ’280 Patent.13
Huawei engages in the foregoing activities because it specifically intends end users of Huawei
products to use “apps” that deploy, and content providers to distribute content that is protected
by, the ContentGuard DRM solutions claimed in the ’280 Patent. Huawei thereby specifically
intends end users and content providers to infringe the ’280 Patent. Huawei derives revenue
13
See, e.g., http://huaweimobile.com;
http://www.huaweidevice.com/worldwide/productMobile.do?method=index&directoryId=6001
&treeId=3745;
http://www.huaweidevice.com/worldwide/productFeatures.do?pinfoId=3298&directoryId=6001
&treeId=3745&tab=0;
http://www.huaweidevice.com/worldwide/technicaIndex.do?method=gotoProductSupport&prod
uctId=3942&tb=0%29;
http://www.huaweidevice.com/worldwide/downloadCenter.do?method=toDownloadFile&flay=d
ocument&softid=NDcxOTM=;
http://www.uscellular.com/uscellular/pdf/huawei-ascend-y-google-play.pdf.
-26-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 27 of 65 PageID #: 27
from both its own and the third-party infringers’ infringing activities. Indeed, Huawei’s ability
to sell the accused products is wholly dependent upon the availability of these “apps” and the
digital content they make available to users. Huawei also contributorily infringes the ’280 Patent
because there is no substantial non-infringing use of these “apps” on the accused Huawei
products. These “apps” cannot be used with accused Huawei products without infringing the
’280 Patent.
63.
Motorola has been and is now directly infringing and/or indirectly infringing the
’280 Patent by way of inducement and/or contributory infringement, literally and/or under the
doctrine of equivalents, in this District, and elsewhere, in violation of 35 U.S.C. § 271, including
by making, using, selling, and/or offering for sale in the United States or importing into the
United States products covered by at least one claim of the ’280 Patent. Motorola has notice of
the ’280 Patent. Motorola actively induces content providers and/or end users of Motorola
products to infringe the ’280 Patent by, among other things, (a) providing access to certain
“apps” (such as the iTunes client, the Amazon Kindle, Amazon Instant Video, and/or Google
Play “apps”) that use the ContentGuard DRM solution claimed in the ’280 Patent, (b) providing
instructions for using such “apps”; (c) providing advertisings for using such “apps”; and (d)
providing hardware and software components required by the claims of the ’280 Patent.14
Motorola engages in the foregoing activities because it specifically intends end users of Motorola
products to use “apps” that deploy, and content providers to distribute content that is protected
14
See, e.g., http://www.motorola.com/us/FLEXR1-1/Moto-X/FLEXR1.html;
https://motorola-globalportal.custhelp.com/app/product_page/faqs/p/30,6720,8882/session/L3RpbWUvMTM4Mzc3MT
A0MS9zaWQvblhuRklIRWw%3D#/how_do_i;
http://www.motorola.com/us/ANDROID/m-Android-Overview.html;
http://www.mobileworldlive.com/verizon-preloads-amazon-kindle-app-on-android-devices;
https://motorola-global-portal.custhelp.com/app/answers/detail/a_id/70762/action/auth.
-27-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 28 of 65 PageID #: 28
by, the ContentGuard DRM solutions claimed in the ’280 Patent. Motorola thereby specifically
intends end users and content providers to infringe the ’280 Patent. Motorola derives revenue
from both its own and the third-party infringers’ infringing activities. Indeed, Motorola’s ability
to sell the accused products is wholly dependent upon the availability of these “apps” and the
digital content they make available to users. Motorola also contributorily infringes the ’280
Patent because there is no substantial non-infringing use of these “apps” on the accused Motorola
products. These “apps” cannot be used with accused Motorola products without infringing the
’280 Patent.
COUNT 4: INFRINGEMENT OF THE ’053 PATENT
(AGAINST APPLE, BLACKBERRY, HUAWEI AND MOTOROLA))
64.
Paragraphs 1 through 46 are incorporated by reference as if fully stated herein.
65.
Apple has been and is now directly infringing and/or indirectly infringing the ’053
Patent by way of inducement and/or contributory infringement, literally and/or under the
doctrine of equivalents, in this District, and elsewhere, in violation of 35 U.S.C. § 271, including
by making, using, selling, and/or offering for sale in the United States or importing into the
United States products covered by at least one claim of the ’053 Patent. Apple has notice of the
’053 Patent. Apple actively induces content providers and/or end users of Apple products to
infringe the ’053 Patent by, among other things, (a) providing access to certain “apps” (such as
the iTunes client, the Amazon Kindle, Amazon Instant Video, and/or Google Play “apps”) that
use the ContentGuard DRM solution claimed in the ’053 Patent, (b) providing instructions for
using such “apps”; (c) providing advertisings for using such “apps”; and (d) providing hardware
-28-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 29 of 65 PageID #: 29
and software components required by the claims of the ’053 Patent.15 Apple engages in the
foregoing activities because it specifically intends end users of Apple products to use “apps” that
deploy, and content providers to distribute content that is protected by, the ContentGuard DRM
solutions claimed in the ’053 Patent. Apple thereby specifically intends end users and content
providers to infringe the ’053 Patent. Apple derives revenue from both its own and the thirdparty infringers’ infringing activities. Indeed, Apple’s ability to sell the accused products is
wholly dependent upon the availability of these “apps” and the digital content they make
available to users. Apple also contributorily infringes the ’053 Patent because there is no
substantial non-infringing use of these “apps” on the accused Apple products. These “apps”
cannot be used with accused Apple products without infringing the ’053 Patent.
66.
BlackBerry has been and is now directly infringing and/or indirectly infringing
the ’053 Patent by way of inducement and/or contributory infringement, literally and/or under
the doctrine of equivalents, in this District, and elsewhere, in violation of 35 U.S.C. § 271,
including by making, using, selling, and/or offering for sale in the United States or importing
into the United States products covered by at least one claim of the ’053 Patent. BlackBerry has
notice of the ’053 Patent. BlackBerry actively induces content providers and/or end users of
BlackBerry products to infringe the ’053 Patent by, among other things, (a) providing access to
certain “apps” (such as the iTunes client, the Amazon Kindle, Amazon Instant Video, and/or
15
See, e.g., http://www.apple.com/itunes/features/#store;
http://www.apple.com/itunes/;
https://itunes.apple.com/in/app/kindle/id302584613;
https://itunes.apple.com/us/app/google-play-books/id400989007;
https://itunes.apple.com/us/app/app-for-google-music-free/id485638799;
https://itunes.apple.com/us/app/google-tv-remote/id422137859?l=es&mt=8;
http://www.apple.com/in/iphone-5s/specs/;
http://www.apple.com/in/ipad/specs/;
http://www.apple.com/in/ipod-touch/specs.html.
-29-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 30 of 65 PageID #: 30
Google Play “apps”) that use the ContentGuard DRM solution claimed in the ’053 Patent, (b)
providing instructions for using such “apps”; (c) providing advertisings for using such “apps”;
and (d) providing hardware and software components required by the claims of the ’053 Patent.16
BlackBerry engages in the foregoing activities because it specifically intends end users of
BlackBerry products to use “apps” that deploy, and content providers to distribute content that is
protected by, the ContentGuard DRM solutions claimed in the ’053 Patent. BlackBerry thereby
specifically intends end users and content providers to infringe the ’053 Patent. BlackBerry
derives revenue from both its own and the third-party infringers’ infringing activities. Indeed,
BlackBerry’s ability to sell the accused products is wholly dependent upon the availability of
these “apps” and the digital content they make available to users. BlackBerry also contributorily
infringes the ’053 Patent because there is no substantial non-infringing use of these “apps” on the
accused BlackBerry products. These “apps” cannot be used with accused BlackBerry products
without infringing the ’053 Patent.
67.
Huawei has been and is now directly infringing and/or indirectly infringing the
’053 Patent by way of inducement and/or contributory infringement, literally and/or under the
doctrine of equivalents, in this District, and elsewhere, in violation of 35 U.S.C. § 271, including
by making, using, selling, and/or offering for sale in the United States or importing into the
United States products covered by at least one claim of the ’053 Patent. Huawei has notice of
the ’053 Patent.
Huawei actively induces content providers and/or end users
of Huawei
products to infringe the ’053 Patent by, among other things, (a) providing access to certain
16
See, e.g., http://in.blackberry.com/apps/blackberry-world.html#tab-1;
http://appworld.blackberry.com/webstore/content/25058915/?countrycode=IN&lang=en;
http://appworld.blackberry.com/webstore/content/65525/?countrycode=US&lang=en;
http://in.blackberry.com/apps/blackberry-world.html#tab-1;
http://appworld.blackberry.com/webstore/content/25058915/?countrycode=IN&lang=en;
http://in.blackberry.com/smartphones/blackberry-z30/specifications.html.
-30-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 31 of 65 PageID #: 31
“apps” (such as the iTunes client, the Amazon Kindle, Amazon Instant Video, and/or Google
Play “apps”) that use the ContentGuard DRM solution claimed in the ’053 Patent, (b) providing
instructions for using such “apps”; (c) providing advertisings for using such “apps”; and (d)
providing hardware and software components required by the claims of the ’053 Patent.17
Huawei engages in the foregoing activities because it specifically intends end users of Huawei
products to use “apps” that deploy, and content providers to distribute content that is protected
by, the ContentGuard DRM solutions claimed in the ’053 Patent. Huawei thereby specifically
intends end users and content providers to infringe the ’053 Patent. Huawei derives revenue
from both its own and the third-party infringers’ infringing activities. Indeed, Huawei’s ability
to sell the accused products is wholly dependent upon the availability of these “apps” and the
digital content they make available to users. Huawei also contributorily infringes the ’053 Patent
because there is no substantial non-infringing use of these “apps” on the accused Huawei
products. These “apps” cannot be used with accused Huawei products without infringing the
’053 Patent.
68.
Motorola has been and is now directly infringing and/or indirectly infringing the
’053 Patent by way of inducement and/or contributory infringement, literally and/or under the
doctrine of equivalents, in this District, and elsewhere, in violation of 35 U.S.C. § 271, including
by making, using, selling, and/or offering for sale in the United States or importing into the
17
See, e.g., http://huaweimobile.com;
http://www.huaweidevice.com/worldwide/productMobile.do?method=index&directoryId=6001
&treeId=3745;
http://www.huaweidevice.com/worldwide/productFeatures.do?pinfoId=3298&directoryId=6001
&treeId=3745&tab=0;
http://www.huaweidevice.com/worldwide/technicaIndex.do?method=gotoProductSupport&prod
uctId=3942&tb=0%29;
http://www.huaweidevice.com/worldwide/downloadCenter.do?method=toDownloadFile&flay=d
ocument&softid=NDcxOTM=;
http://www.uscellular.com/uscellular/pdf/huawei-ascend-y-google-play.pdf.
-31-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 32 of 65 PageID #: 32
United States products covered by at least one claim of the ’053 Patent. Motorola has notice of
the ’053 Patent. Motorola actively induces content providers and/or end users of Motorola
products to infringe the ’053 Patent by, among other things, (a) providing access to certain
“apps” (such as the iTunes client, the Amazon Kindle, Amazon Instant Video, and/or Google
Play “apps”) that use the ContentGuard DRM solution claimed in the ’053 Patent, (b) providing
instructions for using such “apps”; (c) providing advertisings for using such “apps”; and (d)
providing hardware and software components required by the claims of the ’053 Patent.18
Motorola engages in the foregoing activities because it specifically intends end users of Motorola
products to use “apps” that deploy, and content providers to distribute content that is protected
by, the ContentGuard DRM solutions claimed in the ’053 Patent. Motorola thereby specifically
intends end users and content providers to infringe the ’053 Patent. Motorola derives revenue
from both its own and the third-party infringers’ infringing activities. Indeed, Motorola’s ability
to sell the accused products is wholly dependent upon the availability of these “apps” and the
digital content they make available to users. Motorola also contributorily infringes the ’053
Patent because there is no substantial non-infringing use of these “apps” on the accused Motorola
products. These “apps” cannot be used with accused Motorola products without infringing the
’053 Patent.
18
See, e.g., http://www.motorola.com/us/FLEXR1-1/Moto-X/FLEXR1.html;
https://motorola-globalportal.custhelp.com/app/product_page/faqs/p/30,6720,8882/session/L3RpbWUvMTM4Mzc3MT
A0MS9zaWQvblhuRklIRWw%3D#/how_do_i;
http://www.motorola.com/us/ANDROID/m-Android-Overview.html;
http://www.mobileworldlive.com/verizon-preloads-amazon-kindle-app-on-android-devices;
https://motorola-global-portal.custhelp.com/app/answers/detail/a_id/70762/action/auth.
-32-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 33 of 65 PageID #: 33
COUNT 5: INFRINGEMENT OF THE ’576 PATENT
(AGAINST ALL DEFENDANTS)
69.
Paragraphs 1 through 46 are incorporated by reference as if fully stated herein.
70.
Amazon has been and is now directly infringing and/or indirectly infringing the
’576 Patent by way of inducement and/or contributory infringement, literally and/or under the
doctrine of equivalents, in this District, and elsewhere, in violation of 35 U.S.C. § 271, including
by making, using, selling, and/or offering for sale in the United States or importing into the
United States products covered by at least one claim of the ’576 Patent. Amazon has notice of
the ’576 Patent. Amazon actively induces content providers and/or end users of Amazon
products to infringe the ’576 Patent by, among other things, (a) providing access to certain
“apps” (such as the iTunes client, the Amazon Kindle, Amazon Instant Video, and/or Google
Play “apps”) that use the ContentGuard DRM solution claimed in the ’576 Patent, (b) providing
instructions for using such “apps”; (c) providing advertisings for using such “apps”; and (d)
providing hardware and software components required by the claims of the ’576 Patent.19
Amazon engages in the foregoing activities because it specifically intends end users of Amazon
products to use “apps” that deploy, and content providers to distribute content that is protected
by, the ContentGuard DRM solutions claimed in the ’576 Patent. Amazon thereby specifically
intends end users and content providers to infringe the ’576 Patent. Amazon derives revenue
from both its own and the third-party infringers’ infringing activities. Indeed, Amazon’s ability
19
See, e.g., http://www.amazon.com/kindle-fire-hd-best-family-kids-tablet/dp/B00CU0NSCU;
http://www.amazon.com/gp/help/customer/display.html?nodeId=201240840;
http://www.amazon.com/gp/feature.html/ref=kcp_iph_ln_ar?docId=1000301301;
http://www.amazon.com/gp/help/customer/display.html?nodeId=200729450;
http://www.amazon.com/gp/help/customer/display.html?nodeId=201009460;
http://www.amazon.com/kindle-fire-hd-best-family-kids-tablet/dp/B00CU0NSCU;
https://developer.amazon.com/sdk/fire/specifications.html.
-33-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 34 of 65 PageID #: 34
to sell the accused products is wholly dependent upon the availability of these “apps” and the
digital content they make available to users. Amazon also contributorily infringes the ’576
Patent because there is no substantial non-infringing use of these “apps” on the accused Amazon
products. These “apps” cannot be used with accused Amazon products without infringing the
’576 Patent.
71.
Apple has been and is now directly infringing and/or indirectly infringing the ’576
Patent by way of inducement and/or contributory infringement, literally and/or under the
doctrine of equivalents, in this District, and elsewhere, in violation of 35 U.S.C. § 271, including
by making, using, selling, and/or offering for sale in the United States or importing into the
United States products covered by at least one claim of the ’576 Patent. Apple has notice of the
’576 Patent. Apple actively induces content providers and/or end users of Apple products to
infringe the ’576 Patent by, among other things, (a) providing access to certain “apps” (such as
the iTunes client, the Amazon Kindle, Amazon Instant Video, and/or Google Play “apps”) that
use the ContentGuard DRM solution claimed in the ’576 Patent, (b) providing instructions for
using such “apps”; (c) providing advertisings for using such “apps”; and (d) providing hardware
and software components required by the claims of the ’576 Patent.20 Apple engages in the
foregoing activities because it specifically intends end users of Apple products to use “apps” that
deploy, and content providers to distribute content that is protected by, the ContentGuard DRM
20
See, e.g., http://www.apple.com/itunes/features/#store;
http://www.apple.com/itunes/;
https://itunes.apple.com/in/app/kindle/id302584613;
https://itunes.apple.com/us/app/google-play-books/id400989007;
https://itunes.apple.com/us/app/app-for-google-music-free/id485638799;
https://itunes.apple.com/us/app/google-tv-remote/id422137859?l=es&mt=8;
http://www.apple.com/in/iphone-5s/specs/;
http://www.apple.com/in/ipad/specs/;
http://www.apple.com/in/ipod-touch/specs.html.
-34-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 35 of 65 PageID #: 35
solutions claimed in the ’576 Patent. Apple thereby specifically intends end users and content
providers to infringe the ’576 Patent. Apple derives revenue from both its own and the thirdparty infringers’ infringing activities. Indeed, Apple’s ability to sell the accused products is
wholly dependent upon the availability of these “apps” and the digital content they make
available to users. Apple also contributorily infringes the ’576 Patent because there is no
substantial non-infringing use of these “apps” on the accused Apple products. These “apps”
cannot be used with accused Apple products without infringing the ’576 Patent.
72.
BlackBerry has been and is now directly infringing and/or indirectly infringing
the ’576 Patent by way of inducement and/or contributory infringement, literally and/or under
the doctrine of equivalents, in this District, and elsewhere, in violation of 35 U.S.C. § 271,
including by making, using, selling, and/or offering for sale in the United States or importing
into the United States products covered by at least one claim of the ’576 Patent. BlackBerry has
notice of the ’576 Patent. BlackBerry actively induces content providers and/or end users of
BlackBerry products to infringe the ’576 Patent by, among other things, (a) providing access to
certain “apps” (such as the iTunes client, the Amazon Kindle, Amazon Instant Video, and/or
Google Play “apps”) that use the ContentGuard DRM solution claimed in the ’576 Patent, (b)
providing instructions for using such “apps”; (c) providing advertisings for using such “apps”;
and (d) providing hardware and software components required by the claims of the ’576 Patent.21
BlackBerry engages in the foregoing activities because it specifically intends end users of
BlackBerry products to use “apps” that deploy, and content providers to distribute content that is
21
See, e.g., http://in.blackberry.com/apps/blackberry-world.html#tab-1;
http://appworld.blackberry.com/webstore/content/25058915/?countrycode=IN&lang=en;
http://appworld.blackberry.com/webstore/content/65525/?countrycode=US&lang=en;
http://in.blackberry.com/apps/blackberry-world.html#tab-1;
http://appworld.blackberry.com/webstore/content/25058915/?countrycode=IN&lang=en;
http://in.blackberry.com/smartphones/blackberry-z30/specifications.html.
-35-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 36 of 65 PageID #: 36
protected by, the ContentGuard DRM solutions claimed in the ’576 Patent. BlackBerry thereby
specifically intends end users and content providers to infringe the ’576 Patent. BlackBerry
derives revenue from both its own and the third-party infringers’ infringing activities. Indeed,
BlackBerry’s ability to sell the accused products is wholly dependent upon the availability of
these “apps” and the digital content they make available to users. BlackBerry also contributorily
infringes the ’576 Patent because there is no substantial non-infringing use of these “apps” on the
accused BlackBerry products. These “apps” cannot be used with accused BlackBerry products
without infringing the ’576 Patent.
73.
Huawei has been and is now directly infringing and/or indirectly infringing the
’576 Patent by way of inducement and/or contributory infringement, literally and/or under the
doctrine of equivalents, in this District, and elsewhere, in violation of 35 U.S.C. § 271, including
by making, using, selling, and/or offering for sale in the United States or importing into the
United States products covered by at least one claim of the ’576 Patent. Huawei has notice of
the ’576 Patent.
Huawei actively induces content providers and/or end users
of Huawei
products to infringe the ’576 Patent by, among other things, (a) providing access to certain
“apps” (such as the iTunes client, the Amazon Kindle, Amazon Instant Video, and/or Google
Play “apps”) that use the ContentGuard DRM solution claimed in the ’576 Patent, (b) providing
instructions for using such “apps”; (c) providing advertisings for using such “apps”; and (d)
providing hardware and software components required by the claims of the ’576 Patent.22
22
See, e.g., http://huaweimobile.com;
http://www.huaweidevice.com/worldwide/productMobile.do?method=index&directoryId=6001
&treeId=3745;
http://www.huaweidevice.com/worldwide/productFeatures.do?pinfoId=3298&directoryId=6001
&treeId=3745&tab=0;
http://www.huaweidevice.com/worldwide/technicaIndex.do?method=gotoProductSupport&prod
uctId=3942&tb=0%29;
-36-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 37 of 65 PageID #: 37
Huawei engages in the foregoing activities because it specifically intends end users of Huawei
products to use “apps” that deploy, and content providers to distribute content that is protected
by, the ContentGuard DRM solutions claimed in the ’576 Patent. Huawei thereby specifically
intends end users and content providers to infringe the ’576 Patent. Huawei derives revenue
from both its own and the third-party infringers’ infringing activities. Indeed, Huawei’s ability
to sell the accused products is wholly dependent upon the availability of these “apps” and the
digital content they make available to users. Huawei also contributorily infringes the ’576 Patent
because there is no substantial non-infringing use of these “apps” on the accused Huawei
products. These “apps” cannot be used with accused Huawei products without infringing the
’576 Patent.
74.
Motorola has been and is now directly infringing and/or indirectly infringing the
’576 Patent by way of inducement and/or contributory infringement, literally and/or under the
doctrine of equivalents, in this District, and elsewhere, in violation of 35 U.S.C. § 271, including
by making, using, selling, and/or offering for sale in the United States or importing into the
United States products covered by at least one claim of the ’576 Patent. Motorola has notice of
the ’576 Patent. Motorola actively induces content providers and/or end users of Motorola
products to infringe the ’576 Patent by, among other things, (a) providing access to certain
“apps” (such as the iTunes client, the Amazon Kindle, Amazon Instant Video, and/or Google
Play “apps”) that use the ContentGuard DRM solution claimed in the ’576 Patent, (b) providing
instructions for using such “apps”; (c) providing advertisings for using such “apps”; and (d)
http://www.huaweidevice.com/worldwide/downloadCenter.do?method=toDownloadFile&flay=d
ocument&softid=NDcxOTM=;
http://www.uscellular.com/uscellular/pdf/huawei-ascend-y-google-play.pdf.
-37-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 38 of 65 PageID #: 38
providing hardware and software components required by the claims of the ’576 Patent.23
Motorola engages in the foregoing activities because it specifically intends end users of Motorola
products to use “apps” that deploy, and content providers to distribute content that is protected
by, the ContentGuard DRM solutions claimed in the ’576 Patent. Motorola thereby specifically
intends end users and content providers to infringe the ’576 Patent. Motorola derives revenue
from both its own and the third-party infringers’ infringing activities. Indeed, Motorola’s ability
to sell the accused products is wholly dependent upon the availability of these “apps” and the
digital content they make available to users. Motorola also contributorily infringes the ’576
Patent because there is no substantial non-infringing use of these “apps” on the accused Motorola
products. These “apps” cannot be used with accused Motorola products without infringing the
’576 Patent.
COUNT 6: INFRINGEMENT OF THE ’956 PATENT
(AGAINST ALL DEFENDANTS)
75.
Paragraphs 1 through 46 are incorporated by reference as if fully stated herein.
76.
Amazon has been and is now directly infringing and/or indirectly infringing the
’956 Patent by way of inducement and/or contributory infringement, literally and/or under the
doctrine of equivalents, in this District, and elsewhere, in violation of 35 U.S.C. § 271, including
by making, using, selling, and/or offering for sale in the United States or importing into the
United States products covered by at least one claim of the ’956 Patent. Amazon has notice of
23
See, e.g., http://www.motorola.com/us/FLEXR1-1/Moto-X/FLEXR1.html;
https://motorola-globalportal.custhelp.com/app/product_page/faqs/p/30,6720,8882/session/L3RpbWUvMTM4Mzc3MT
A0MS9zaWQvblhuRklIRWw%3D#/how_do_i;
http://www.motorola.com/us/ANDROID/m-Android-Overview.html;
http://www.mobileworldlive.com/verizon-preloads-amazon-kindle-app-on-android-devices;
https://motorola-global-portal.custhelp.com/app/answers/detail/a_id/70762/action/auth.
-38-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 39 of 65 PageID #: 39
the ’956 Patent. Amazon actively induces content providers and/or end users of Amazon
products to infringe the ’956 Patent by, among other things, (a) providing access to certain
“apps” (such as the iTunes client, the Amazon Kindle, Amazon Instant Video, and/or Google
Play “apps”) that use the ContentGuard DRM solution claimed in the ’956 Patent, (b) providing
instructions for using such “apps”; (c) providing advertisings for using such “apps”; and (d)
providing hardware and software components required by the claims of the ’956 Patent.24
Amazon engages in the foregoing activities because it specifically intends end users of Amazon
products to use “apps” that deploy, and content providers to distribute content that is protected
by, the ContentGuard DRM solutions claimed in the ’956 Patent. Amazon thereby specifically
intends end users and content providers to infringe the ’956 Patent. Amazon derives revenue
from both its own and the third-party infringers’ infringing activities. Indeed, Amazon’s ability
to sell the accused products is wholly dependent upon the availability of these “apps” and the
digital content they make available to users. Amazon also contributorily infringes the ’956
Patent because there is no substantial non-infringing use of these “apps” on the accused Amazon
products. These “apps” cannot be used with accused Amazon products without infringing the
’956 Patent.
77.
Apple has been and is now directly infringing and/or indirectly infringing the ’956
Patent by way of inducement and/or contributory infringement, literally and/or under the
doctrine of equivalents, in this District, and elsewhere, in violation of 35 U.S.C. § 271, including
24
See, e.g., http://www.amazon.com/kindle-fire-hd-best-family-kids-tablet/dp/B00CU0NSCU;
http://www.amazon.com/gp/help/customer/display.html?nodeId=201240840;
http://www.amazon.com/gp/feature.html/ref=kcp_iph_ln_ar?docId=1000301301;
http://www.amazon.com/gp/help/customer/display.html?nodeId=200729450;
http://www.amazon.com/gp/help/customer/display.html?nodeId=201009460;
http://www.amazon.com/kindle-fire-hd-best-family-kids-tablet/dp/B00CU0NSCU;
https://developer.amazon.com/sdk/fire/specifications.html.
-39-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 40 of 65 PageID #: 40
by making, using, selling, and/or offering for sale in the United States or importing into the
United States products covered by at least one claim of the ’956 Patent. Apple has notice of the
’956 Patent. Apple actively induces content providers and/or end users of Apple products to
infringe the ’956 Patent by, among other things, (a) providing access to certain “apps” (such as
the iTunes client, the Amazon Kindle, Amazon Instant Video, and/or Google Play “apps”) that
use the ContentGuard DRM solution claimed in the ’956 Patent, (b) providing instructions for
using such “apps”; (c) providing advertisings for using such “apps”; and (d) providing hardware
and software components required by the claims of the ’956 Patent.25 Apple engages in the
foregoing activities because it specifically intends end users of Apple products to use “apps” that
deploy, and content providers to distribute content that is protected by, the ContentGuard DRM
solutions claimed in the ’956 Patent. Apple thereby specifically intends end users and content
providers to infringe the ’956 Patent. Apple derives revenue from both its own and the thirdparty infringers’ infringing activities. Indeed, Apple’s ability to sell the accused products is
wholly dependent upon the availability of these “apps” and the digital content they make
available to users. Apple also contributorily infringes the ’956 Patent because there is no
substantial non-infringing use of these “apps” on the accused Apple products. These “apps”
cannot be used with accused Apple products without infringing the ’956 Patent.
25
See, e.g., http://www.apple.com/itunes/features/#store;
http://www.apple.com/itunes/;
https://itunes.apple.com/in/app/kindle/id302584613;
https://itunes.apple.com/us/app/google-play-books/id400989007;
https://itunes.apple.com/us/app/app-for-google-music-free/id485638799;
https://itunes.apple.com/us/app/google-tv-remote/id422137859?l=es&mt=8;
http://www.apple.com/in/iphone-5s/specs/;
http://www.apple.com/in/ipad/specs/;
http://www.apple.com/in/ipod-touch/specs.html.
-40-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 41 of 65 PageID #: 41
78.
BlackBerry has been and is now directly infringing and/or indirectly infringing
the ’956 Patent by way of inducement and/or contributory infringement, literally and/or under
the doctrine of equivalents, in this District, and elsewhere, in violation of 35 U.S.C. § 271,
including by making, using, selling, and/or offering for sale in the United States or importing
into the United States products covered by at least one claim of the ’956 Patent. BlackBerry has
notice of the ’956 Patent. BlackBerry actively induces content providers and/or end users of
BlackBerry products to infringe the ’956 Patent by, among other things, (a) providing access to
certain “apps” (such as the iTunes client, the Amazon Kindle, Amazon Instant Video, and/or
Google Play “apps”) that use the ContentGuard DRM solution claimed in the ’956 Patent, (b)
providing instructions for using such “apps”; (c) providing advertisings for using such “apps”;
and (d) providing hardware and software components required by the claims of the ’956 Patent.26
BlackBerry engages in the foregoing activities because it specifically intends end users of
BlackBerry products to use “apps” that deploy, and content providers to distribute content that is
protected by, the ContentGuard DRM solutions claimed in the ’956 Patent. BlackBerry thereby
specifically intends end users and content providers to infringe the ’956 Patent. BlackBerry
derives revenue from both its own and the third-party infringers’ infringing activities. Indeed,
BlackBerry’s ability to sell the accused products is wholly dependent upon the availability of
these “apps” and the digital content they make available to users. BlackBerry also contributorily
infringes the ’956 Patent because there is no substantial non-infringing use of these “apps” on the
26
See, e.g., http://in.blackberry.com/apps/blackberry-world.html#tab-1;
http://appworld.blackberry.com/webstore/content/25058915/?countrycode=IN&lang=en;
http://appworld.blackberry.com/webstore/content/65525/?countrycode=US&lang=en;
http://in.blackberry.com/apps/blackberry-world.html#tab-1;
http://appworld.blackberry.com/webstore/content/25058915/?countrycode=IN&lang=en;
http://in.blackberry.com/smartphones/blackberry-z30/specifications.html.
-41-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 42 of 65 PageID #: 42
accused BlackBerry products. These “apps” cannot be used with accused BlackBerry products
without infringing the ’956 Patent.
79.
Huawei has been and is now directly infringing and/or indirectly infringing the
’956 Patent by way of inducement and/or contributory infringement, literally and/or under the
doctrine of equivalents, in this District, and elsewhere, in violation of 35 U.S.C. § 271, including
by making, using, selling, and/or offering for sale in the United States or importing into the
United States products covered by at least one claim of the ’956 Patent. Huawei has notice of
the ’956 Patent.
Huawei actively induces content providers and/or end users
of Huawei
products to infringe the ’956 Patent by, among other things, (a) providing access to certain
“apps” (such as the iTunes client, the Amazon Kindle, Amazon Instant Video, and/or Google
Play “apps”) that use the ContentGuard DRM solution claimed in the ’956 Patent, (b) providing
instructions for using such “apps”; (c) providing advertisings for using such “apps”; and (d)
providing hardware and software components required by the claims of the ’956 Patent.27
Huawei engages in the foregoing activities because it specifically intends end users of Huawei
products to use “apps” that deploy, and content providers to distribute content that is protected
by, the ContentGuard DRM solutions claimed in the ’956 Patent. Huawei thereby specifically
intends end users and content providers to infringe the ’956 Patent. Huawei derives revenue
from both its own and the third-party infringers’ infringing activities. Indeed, Huawei’s ability
27
See, e.g., http://huaweimobile.com;
http://www.huaweidevice.com/worldwide/productMobile.do?method=index&directoryId=6001
&treeId=3745;
http://www.huaweidevice.com/worldwide/productFeatures.do?pinfoId=3298&directoryId=6001
&treeId=3745&tab=0;
http://www.huaweidevice.com/worldwide/technicaIndex.do?method=gotoProductSupport&prod
uctId=3942&tb=0%29;
http://www.huaweidevice.com/worldwide/downloadCenter.do?method=toDownloadFile&flay=d
ocument&softid=NDcxOTM=;
http://www.uscellular.com/uscellular/pdf/huawei-ascend-y-google-play.pdf.
-42-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 43 of 65 PageID #: 43
to sell the accused products is wholly dependent upon the availability of these “apps” and the
digital content they make available to users. Huawei also contributorily infringes the ’956 Patent
because there is no substantial non-infringing use of these “apps” on the accused Huawei
products. These “apps” cannot be used with accused Huawei products without infringing the
’956 Patent.
80.
Motorola has been and is now directly infringing and/or indirectly infringing the
’956 Patent by way of inducement and/or contributory infringement, literally and/or under the
doctrine of equivalents, in this District, and elsewhere, in violation of 35 U.S.C. § 271, including
by making, using, selling, and/or offering for sale in the United States or importing into the
United States products covered by at least one claim of the ’956 Patent. Motorola has notice of
the ’956 Patent. Motorola actively induces content providers and/or end users of Motorola
products to infringe the ’956 Patent by, among other things, (a) providing access to certain
“apps” (such as the iTunes client, the Amazon Kindle, Amazon Instant Video, and/or Google
Play “apps”) that use the ContentGuard DRM solution claimed in the ’956 Patent, (b) providing
instructions for using such “apps”; (c) providing advertisings for using such “apps”; and (d)
providing hardware and software components required by the claims of the ’956 Patent.28
Motorola engages in the foregoing activities because it specifically intends end users of Motorola
products to use “apps” that deploy, and content providers to distribute content that is protected
by, the ContentGuard DRM solutions claimed in the ’956 Patent. Motorola thereby specifically
28
See, e.g., http://www.motorola.com/us/FLEXR1-1/Moto-X/FLEXR1.html;
https://motorola-globalportal.custhelp.com/app/product_page/faqs/p/30,6720,8882/session/L3RpbWUvMTM4Mzc3MT
A0MS9zaWQvblhuRklIRWw%3D#/how_do_i;
http://www.motorola.com/us/ANDROID/m-Android-Overview.html;
http://www.mobileworldlive.com/verizon-preloads-amazon-kindle-app-on-android-devices;
https://motorola-global-portal.custhelp.com/app/answers/detail/a_id/70762/action/auth.
-43-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 44 of 65 PageID #: 44
intends end users and content providers to infringe the ’956 Patent. Motorola derives revenue
from both its own and the third-party infringers’ infringing activities. Indeed, Motorola’s ability
to sell the accused products is wholly dependent upon the availability of these “apps” and the
digital content they make available to users. Motorola also contributorily infringes the ’956
Patent because there is no substantial non-infringing use of these “apps” on the accused Motorola
products. These “apps” cannot be used with accused Motorola products without infringing the
’956 Patent.
COUNT 7: INFRINGEMENT OF THE ’007 PATENT
(AGAINST ALL DEFENDANTS)
81.
Paragraphs 1 through 46 are incorporated by reference as if fully stated herein.
82.
Amazon has been and is now directly infringing and/or indirectly infringing the
’007 Patent by way of inducement and/or contributory infringement, literally and/or under the
doctrine of equivalents, in this District, and elsewhere, in violation of 35 U.S.C. § 271, including
by making, using, selling, and/or offering for sale in the United States or importing into the
United States products covered by at least one claim of the ’007 Patent. Amazon has notice of
the ’007 Patent. Amazon actively induces content providers and/or end users of Amazon
products to infringe the ’007 Patent by, among other things, (a) providing access to certain
“apps” (such as the iTunes client, the Amazon Kindle, Amazon Instant Video, and/or Google
Play “apps”) that use the ContentGuard DRM solution claimed in the ’007 Patent, (b) providing
instructions for using such “apps”; (c) providing advertisings for using such “apps”; and (d)
providing hardware and software components required by the claims of the ’007 Patent.29
29
See, e.g., http://www.amazon.com/kindle-fire-hd-best-family-kids-tablet/dp/B00CU0NSCU;
http://www.amazon.com/gp/help/customer/display.html?nodeId=201240840;
http://www.amazon.com/gp/feature.html/ref=kcp_iph_ln_ar?docId=1000301301;
-44-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 45 of 65 PageID #: 45
Amazon engages in the foregoing activities because it specifically intends end users of Amazon
products to use “apps” that deploy, and content providers to distribute content that is protected
by, the ContentGuard DRM solutions claimed in the ’007 Patent. Amazon thereby specifically
intends end users and content providers to infringe the ’007 Patent. Amazon derives revenue
from both its own and the third-party infringers’ infringing activities. Indeed, Amazon’s ability
to sell the accused products is wholly dependent upon the availability of these “apps” and the
digital content they make available to users. Amazon also contributorily infringes the ’007
Patent because there is no substantial non-infringing use of these “apps” on the accused Amazon
products. These “apps” cannot be used with accused Amazon products without infringing the
’007 Patent.
83.
Apple has been and is now directly infringing and/or indirectly infringing the ’007
Patent by way of inducement and/or contributory infringement, literally and/or under the
doctrine of equivalents, in this District, and elsewhere, in violation of 35 U.S.C. § 271, including
by making, using, selling, and/or offering for sale in the United States or importing into the
United States products covered by at least one claim of the ’007 Patent. Apple has notice of the
’007 Patent. Apple actively induces content providers and/or end users of Apple products to
infringe the ’007 Patent by, among other things, (a) providing access to certain “apps” (such as
the iTunes client, the Amazon Kindle, Amazon Instant Video, and/or Google Play “apps”) that
use the ContentGuard DRM solution claimed in the ’007 Patent, (b) providing instructions for
using such “apps”; (c) providing advertisings for using such “apps”; and (d) providing hardware
http://www.amazon.com/gp/help/customer/display.html?nodeId=200729450;
http://www.amazon.com/gp/help/customer/display.html?nodeId=201009460;
http://www.amazon.com/kindle-fire-hd-best-family-kids-tablet/dp/B00CU0NSCU;
https://developer.amazon.com/sdk/fire/specifications.html.
-45-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 46 of 65 PageID #: 46
and software components required by the claims of the ’007 Patent.30 Apple engages in the
foregoing activities because it specifically intends end users of Apple products to use “apps” that
deploy, and content providers to distribute content that is protected by, the ContentGuard DRM
solutions claimed in the ’007 Patent. Apple thereby specifically intends end users and content
providers to infringe the ’007 Patent. Apple derives revenue from both its own and the thirdparty infringers’ infringing activities. Indeed, Apple’s ability to sell the accused products is
wholly dependent upon the availability of these “apps” and the digital content they make
available to users. Apple also contributorily infringes the ’007 Patent because there is no
substantial non-infringing use of these “apps” on the accused Apple products. These “apps”
cannot be used with accused Apple products without infringing the ’007 Patent.
84.
BlackBerry has been and is now directly infringing and/or indirectly infringing
the ’007 Patent by way of inducement and/or contributory infringement, literally and/or under
the doctrine of equivalents, in this District, and elsewhere, in violation of 35 U.S.C. § 271,
including by making, using, selling, and/or offering for sale in the United States or importing
into the United States products covered by at least one claim of the ’007 Patent. BlackBerry has
notice of the ’007 Patent. BlackBerry actively induces content providers and/or end users of
BlackBerry products to infringe the ’007 Patent by, among other things, (a) providing access to
certain “apps” (such as the iTunes client, the Amazon Kindle, Amazon Instant Video, and/or
30
See, e.g., http://www.apple.com/itunes/features/#store;
http://www.apple.com/itunes/;
https://itunes.apple.com/in/app/kindle/id302584613;
https://itunes.apple.com/us/app/google-play-books/id400989007;
https://itunes.apple.com/us/app/app-for-google-music-free/id485638799;
https://itunes.apple.com/us/app/google-tv-remote/id422137859?l=es&mt=8;
http://www.apple.com/in/iphone-5s/specs/;
http://www.apple.com/in/ipad/specs/;
http://www.apple.com/in/ipod-touch/specs.html.
-46-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 47 of 65 PageID #: 47
Google Play “apps”) that use the ContentGuard DRM solution claimed in the ’007 Patent, (b)
providing instructions for using such “apps”; (c) providing advertisings for using such “apps”;
and (d) providing hardware and software components required by the claims of the ’007 Patent.31
BlackBerry engages in the foregoing activities because it specifically intends end users of
BlackBerry products to use “apps” that deploy, and content providers to distribute content that is
protected by, the ContentGuard DRM solutions claimed in the ’007 Patent. BlackBerry thereby
specifically intends end users and content providers to infringe the ’007 Patent. BlackBerry
derives revenue from both its own and the third-party infringers’ infringing activities. Indeed,
BlackBerry’s ability to sell the accused products is wholly dependent upon the availability of
these “apps” and the digital content they make available to users. BlackBerry also contributorily
infringes the ’007 Patent because there is no substantial non-infringing use of these “apps” on the
accused BlackBerry products. These “apps” cannot be used with accused BlackBerry products
without infringing the ’007 Patent.
85.
Huawei has been and is now directly infringing and/or indirectly infringing the
’007 Patent by way of inducement and/or contributory infringement, literally and/or under the
doctrine of equivalents, in this District, and elsewhere, in violation of 35 U.S.C. § 271, including
by making, using, selling, and/or offering for sale in the United States or importing into the
United States products covered by at least one claim of the ’007 Patent. Huawei has notice of
the ’007 Patent.
Huawei actively induces content providers and/or end users
of Huawei
products to infringe the ’007 Patent by, among other things, (a) providing access to certain
31
See, e.g., http://in.blackberry.com/apps/blackberry-world.html#tab-1;
http://appworld.blackberry.com/webstore/content/25058915/?countrycode=IN&lang=en;
http://appworld.blackberry.com/webstore/content/65525/?countrycode=US&lang=en;
http://in.blackberry.com/apps/blackberry-world.html#tab-1;
http://appworld.blackberry.com/webstore/content/25058915/?countrycode=IN&lang=en;
http://in.blackberry.com/smartphones/blackberry-z30/specifications.html.
-47-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 48 of 65 PageID #: 48
“apps” (such as the iTunes client, the Amazon Kindle, Amazon Instant Video, and/or Google
Play “apps”) that use the ContentGuard DRM solution claimed in the ’007 Patent, (b) providing
instructions for using such “apps”; (c) providing advertisings for using such “apps”; and (d)
providing hardware and software components required by the claims of the ’007 Patent.32
Huawei engages in the foregoing activities because it specifically intends end users of Huawei
products to use “apps” that deploy, and content providers to distribute content that is protected
by, the ContentGuard DRM solutions claimed in the ’007 Patent. Huawei thereby specifically
intends end users and content providers to infringe the ’007 Patent. Huawei derives revenue
from both its own and the third-party infringers’ infringing activities. Indeed, Huawei’s ability
to sell the accused products is wholly dependent upon the availability of these “apps” and the
digital content they make available to users. Huawei also contributorily infringes the ’007 Patent
because there is no substantial non-infringing use of these “apps” on the accused Huawei
products. These “apps” cannot be used with accused Huawei products without infringing the
’007 Patent.
86.
Motorola has been and is now directly infringing and/or indirectly infringing the
’007 Patent by way of inducement and/or contributory infringement, literally and/or under the
doctrine of equivalents, in this District, and elsewhere, in violation of 35 U.S.C. § 271, including
by making, using, selling, and/or offering for sale in the United States or importing into the
32
See, e.g., http://huaweimobile.com;
http://www.huaweidevice.com/worldwide/productMobile.do?method=index&directoryId=6001
&treeId=3745;
http://www.huaweidevice.com/worldwide/productFeatures.do?pinfoId=3298&directoryId=6001
&treeId=3745&tab=0;
http://www.huaweidevice.com/worldwide/technicaIndex.do?method=gotoProductSupport&prod
uctId=3942&tb=0%29;
http://www.huaweidevice.com/worldwide/downloadCenter.do?method=toDownloadFile&flay=d
ocument&softid=NDcxOTM=;
http://www.uscellular.com/uscellular/pdf/huawei-ascend-y-google-play.pdf.
-48-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 49 of 65 PageID #: 49
United States products covered by at least one claim of the ’007 Patent. Motorola has notice of
the ’007 Patent. Motorola actively induces content providers and/or end users of Motorola
products to infringe the ’007 Patent by, among other things, (a) providing access to certain
“apps” (such as the iTunes client, the Amazon Kindle, Amazon Instant Video, and/or Google
Play “apps”) that use the ContentGuard DRM solution claimed in the ’007 Patent, (b) providing
instructions for using such “apps”; (c) providing advertisings for using such “apps”; and (d)
providing hardware and software components required by the claims of the ’007 Patent.33
Motorola engages in the foregoing activities because it specifically intends end users of Motorola
products to use “apps” that deploy, and content providers to distribute content that is protected
by, the ContentGuard DRM solutions claimed in the ’007 Patent. Motorola thereby specifically
intends end users and content providers to infringe the ’007 Patent. Motorola derives revenue
from both its own and the third-party infringers’ infringing activities. Indeed, Motorola’s ability
to sell the accused products is wholly dependent upon the availability of these “apps” and the
digital content they make available to users. Motorola also contributorily infringes the ’007
Patent because there is no substantial non-infringing use of these “apps” on the accused Motorola
products. These “apps” cannot be used with accused Motorola products without infringing the
’007 Patent.
33
See, e.g., http://www.motorola.com/us/FLEXR1-1/Moto-X/FLEXR1.html;
https://motorola-globalportal.custhelp.com/app/product_page/faqs/p/30,6720,8882/session/L3RpbWUvMTM4Mzc3MT
A0MS9zaWQvblhuRklIRWw%3D#/how_do_i;
http://www.motorola.com/us/ANDROID/m-Android-Overview.html;
http://www.mobileworldlive.com/verizon-preloads-amazon-kindle-app-on-android-devices;
https://motorola-global-portal.custhelp.com/app/answers/detail/a_id/70762/action/auth.
-49-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 50 of 65 PageID #: 50
COUNT 8: INFRINGEMENT OF THE ’160 PATENT
(AGAINST ALL DEFENDANTS)
87.
Paragraphs 1 through 46 are incorporated by reference as if fully stated herein.
88.
Amazon has been and is now directly infringing and/or indirectly infringing the
’160 Patent by way of inducement and/or contributory infringement, literally and/or under the
doctrine of equivalents, in this District, and elsewhere, in violation of 35 U.S.C. § 271, including
by making, using, selling, and/or offering for sale in the United States or importing into the
United States products covered by at least one claim of the ’160 Patent. Amazon has notice of
the ’160 Patent. Amazon actively induces content providers and/or end users of Amazon
products to infringe the ’160 Patent by, among other things, (a) providing access to certain
“apps” (such as the iTunes client, the Amazon Kindle, Amazon Instant Video, and/or Google
Play “apps”) that use the ContentGuard DRM solution claimed in the ’160 Patent, (b) providing
instructions for using such “apps”; (c) providing advertisings for using such “apps”; and (d)
providing hardware and software components required by the claims of the ’160 Patent.34
Amazon engages in the foregoing activities because it specifically intends end users of Amazon
products to use “apps” that deploy, and content providers to distribute content that is protected
by, the ContentGuard DRM solutions claimed in the ’160 Patent. Amazon thereby specifically
intends end users and content providers to infringe the ’160 Patent. Amazon derives revenue
from both its own and the third-party infringers’ infringing activities. Indeed, Amazon’s ability
34
See, e.g., http://www.amazon.com/kindle-fire-hd-best-family-kids-tablet/dp/B00CU0NSCU;
http://www.amazon.com/gp/help/customer/display.html?nodeId=201240840;
http://www.amazon.com/gp/feature.html/ref=kcp_iph_ln_ar?docId=1000301301;
http://www.amazon.com/gp/help/customer/display.html?nodeId=200729450;
http://www.amazon.com/gp/help/customer/display.html?nodeId=201009460;
http://www.amazon.com/kindle-fire-hd-best-family-kids-tablet/dp/B00CU0NSCU;
https://developer.amazon.com/sdk/fire/specifications.html.
-50-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 51 of 65 PageID #: 51
to sell the accused products is wholly dependent upon the availability of these “apps” and the
digital content they make available to users. Amazon also contributorily infringes the ’160
Patent because there is no substantial non-infringing use of these “apps” on the accused Amazon
products. These “apps” cannot be used with accused Amazon products without infringing the
’160 Patent.
89.
Apple has been and is now directly infringing and/or indirectly infringing the ’160
Patent by way of inducement and/or contributory infringement, literally and/or under the
doctrine of equivalents, in this District, and elsewhere, in violation of 35 U.S.C. § 271, including
by making, using, selling, and/or offering for sale in the United States or importing into the
United States products covered by at least one claim of the ’160 Patent. Apple has notice of the
’160 Patent. Apple actively induces content providers and/or end users of Apple products to
infringe the ’160 Patent by, among other things, (a) providing access to certain “apps” (such as
the iTunes client, the Amazon Kindle, Amazon Instant Video, and/or Google Play “apps”) that
use the ContentGuard DRM solution claimed in the ’160 Patent, (b) providing instructions for
using such “apps”; (c) providing advertisings for using such “apps”; and (d) providing hardware
and software components required by the claims of the ’160 Patent.35 Apple engages in the
foregoing activities because it specifically intends end users of Apple products to use “apps” that
deploy, and content providers to distribute content that is protected by, the ContentGuard DRM
35
See, e.g., http://www.apple.com/itunes/features/#store;
http://www.apple.com/itunes/;
https://itunes.apple.com/in/app/kindle/id302584613;
https://itunes.apple.com/us/app/google-play-books/id400989007;
https://itunes.apple.com/us/app/app-for-google-music-free/id485638799;
https://itunes.apple.com/us/app/google-tv-remote/id422137859?l=es&mt=8;
http://www.apple.com/in/iphone-5s/specs/;
http://www.apple.com/in/ipad/specs/;
http://www.apple.com/in/ipod-touch/specs.html.
-51-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 52 of 65 PageID #: 52
solutions claimed in the ’160 Patent. Apple thereby specifically intends end users and content
providers to infringe the ’160 Patent. Apple derives revenue from both its own and the thirdparty infringers’ infringing activities. Indeed, Apple’s ability to sell the accused products is
wholly dependent upon the availability of these “apps” and the digital content they make
available to users. Apple also contributorily infringes the ’160 Patent because there is no
substantial non-infringing use of these “apps” on the accused Apple products. These “apps”
cannot be used with accused Apple products without infringing the ’160 Patent.
90.
BlackBerry has been and is now directly infringing and/or indirectly infringing
the ’160 Patent by way of inducement and/or contributory infringement, literally and/or under
the doctrine of equivalents, in this District, and elsewhere, in violation of 35 U.S.C. § 271,
including by making, using, selling, and/or offering for sale in the United States or importing
into the United States products covered by at least one claim of the ’160 Patent. BlackBerry has
notice of the ’160 Patent. BlackBerry actively induces content providers and/or end users of
BlackBerry products to infringe the ’160 Patent by, among other things, (a) providing access to
certain “apps” (such as the iTunes client, the Amazon Kindle, Amazon Instant Video, and/or
Google Play “apps”) that use the ContentGuard DRM solution claimed in the ’160 Patent, (b)
providing instructions for using such “apps”; (c) providing advertisings for using such “apps”;
and (d) providing hardware and software components required by the claims of the ’160 Patent.36
BlackBerry engages in the foregoing activities because it specifically intends end users of
BlackBerry products to use “apps” that deploy, and content providers to distribute content that is
36
See, e.g., http://in.blackberry.com/apps/blackberry-world.html#tab-1;
http://appworld.blackberry.com/webstore/content/25058915/?countrycode=IN&lang=en;
http://appworld.blackberry.com/webstore/content/65525/?countrycode=US&lang=en;
http://in.blackberry.com/apps/blackberry-world.html#tab-1;
http://appworld.blackberry.com/webstore/content/25058915/?countrycode=IN&lang=en;
http://in.blackberry.com/smartphones/blackberry-z30/specifications.html.
-52-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 53 of 65 PageID #: 53
protected by, the ContentGuard DRM solutions claimed in the ’160 Patent. BlackBerry thereby
specifically intends end users and content providers to infringe the ’160 Patent. BlackBerry
derives revenue from both its own and the third-party infringers’ infringing activities. Indeed,
BlackBerry’s ability to sell the accused products is wholly dependent upon the availability of
these “apps” and the digital content they make available to users. BlackBerry also contributorily
infringes the ’160 Patent because there is no substantial non-infringing use of these “apps” on the
accused BlackBerry products. These “apps” cannot be used with accused BlackBerry products
without infringing the ’160 Patent.
91.
Huawei has been and is now directly infringing and/or indirectly infringing the
’160 Patent by way of inducement and/or contributory infringement, literally and/or under the
doctrine of equivalents, in this District, and elsewhere, in violation of 35 U.S.C. § 271, including
by making, using, selling, and/or offering for sale in the United States or importing into the
United States products covered by at least one claim of the ’160 Patent. Huawei has notice of
the ’160 Patent.
Huawei actively induces content providers and/or end users
of Huawei
products to infringe the ’160 Patent by, among other things, (a) providing access to certain
“apps” (such as the iTunes client, the Amazon Kindle, Amazon Instant Video, and/or Google
Play “apps”) that use the ContentGuard DRM solution claimed in the ’160 Patent, (b) providing
instructions for using such “apps”; (c) providing advertisings for using such “apps”; and (d)
providing hardware and software components required by the claims of the ’160 Patent.37
37
See, e.g., http://huaweimobile.com;
http://www.huaweidevice.com/worldwide/productMobile.do?method=index&directoryId=6001
&treeId=3745;
http://www.huaweidevice.com/worldwide/productFeatures.do?pinfoId=3298&directoryId=6001
&treeId=3745&tab=0;
http://www.huaweidevice.com/worldwide/technicaIndex.do?method=gotoProductSupport&prod
uctId=3942&tb=0%29;
-53-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 54 of 65 PageID #: 54
Huawei engages in the foregoing activities because it specifically intends end users of Huawei
products to use “apps” that deploy, and content providers to distribute content that is protected
by, the ContentGuard DRM solutions claimed in the ’160 Patent. Huawei thereby specifically
intends end users and content providers to infringe the ’160 Patent. Huawei derives revenue
from both its own and the third-party infringers’ infringing activities. Indeed, Huawei’s ability
to sell the accused products is wholly dependent upon the availability of these “apps” and the
digital content they make available to users. Huawei also contributorily infringes the ’160 Patent
because there is no substantial non-infringing use of these “apps” on the accused Huawei
products. These “apps” cannot be used with accused Huawei products without infringing the
’160 Patent.
92.
Motorola has been and is now directly infringing and/or indirectly infringing the
’160 Patent by way of inducement and/or contributory infringement, literally and/or under the
doctrine of equivalents, in this District, and elsewhere, in violation of 35 U.S.C. § 271, including
by making, using, selling, and/or offering for sale in the United States or importing into the
United States products covered by at least one claim of the ’160 Patent. Motorola has notice of
the ’160 Patent. Motorola actively induces content providers and/or end users of Motorola
products to infringe the ’160 Patent by, among other things, (a) providing access to certain
“apps” (such as the iTunes client, the Amazon Kindle, Amazon Instant Video, and/or Google
Play “apps”) that use the ContentGuard DRM solution claimed in the ’160 Patent, (b) providing
instructions for using such “apps”; (c) providing advertisings for using such “apps”; and (d)
http://www.huaweidevice.com/worldwide/downloadCenter.do?method=toDownloadFile&flay=d
ocument&softid=NDcxOTM=;
http://www.uscellular.com/uscellular/pdf/huawei-ascend-y-google-play.pdf.
-54-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 55 of 65 PageID #: 55
providing hardware and software components required by the claims of the ’160 Patent.38
Motorola engages in the foregoing activities because it specifically intends end users of Motorola
products to use “apps” that deploy, and content providers to distribute content that is protected
by, the ContentGuard DRM solutions claimed in the ’160 Patent. Motorola thereby specifically
intends end users and content providers to infringe the ’160 Patent. Motorola derives revenue
from both its own and the third-party infringers’ infringing activities. Indeed, Motorola’s ability
to sell the accused products is wholly dependent upon the availability of these “apps” and the
digital content they make available to users. Motorola also contributorily infringes the ’160
Patent because there is no substantial non-infringing use of these “apps” on the accused Motorola
products. These “apps” cannot be used with accused Motorola products without infringing the
’160 Patent.
COUNT 9: INFRINGEMENT OF THE ’556 PATENT
(AGAINST ALL DEFENDANTS)
93.
Paragraphs 1 through 46 are incorporated by reference as if fully stated herein.
94.
Amazon has been and is now directly infringing and/or indirectly infringing the
’556 Patent by way of inducement and/or contributory infringement, literally and/or under the
doctrine of equivalents, in this District, and elsewhere, in violation of 35 U.S.C. § 271, including
by making, using, selling, and/or offering for sale in the United States or importing into the
United States products covered by at least one claim of the ’556 Patent. Amazon has notice of
38
See, e.g., http://www.motorola.com/us/FLEXR1-1/Moto-X/FLEXR1.html;
https://motorola-globalportal.custhelp.com/app/product_page/faqs/p/30,6720,8882/session/L3RpbWUvMTM4Mzc3MT
A0MS9zaWQvblhuRklIRWw%3D#/how_do_i;
http://www.motorola.com/us/ANDROID/m-Android-Overview.html;
http://www.mobileworldlive.com/verizon-preloads-amazon-kindle-app-on-android-devices;
https://motorola-global-portal.custhelp.com/app/answers/detail/a_id/70762/action/auth.
-55-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 56 of 65 PageID #: 56
the ’556 Patent. Amazon actively induces content providers and/or end users of Amazon
products to infringe the ’556 Patent by, among other things, (a) providing access to certain
“apps” (such as the iTunes client, the Amazon Kindle, Amazon Instant Video, and/or Google
Play “apps”) that use the ContentGuard DRM solution claimed in the ’556 Patent, (b) providing
instructions for using such “apps”; (c) providing advertisings for using such “apps”; and (d)
providing hardware and software components required by the claims of the ’556 Patent.39
Amazon engages in the foregoing activities because it specifically intends end users of Amazon
products to use “apps” that deploy, and content providers to distribute content that is protected
by, the ContentGuard DRM solutions claimed in the ’556 Patent. Amazon thereby specifically
intends end users and content providers to infringe the ’556 Patent. Amazon derives revenue
from both its own and the third-party infringers’ infringing activities. Indeed, Amazon’s ability
to sell the accused products is wholly dependent upon the availability of these “apps” and the
digital content they make available to users. Amazon also contributorily infringes the ’556
Patent because there is no substantial non-infringing use of these “apps” on the accused Amazon
products. These “apps” cannot be used with accused Amazon products without infringing the
’556 Patent.
95.
Apple has been and is now directly infringing and/or indirectly infringing the ’556
Patent by way of inducement and/or contributory infringement, literally and/or under the
doctrine of equivalents, in this District, and elsewhere, in violation of 35 U.S.C. § 271, including
39
See, e.g., http://www.amazon.com/kindle-fire-hd-best-family-kids-tablet/dp/B00CU0NSCU;
http://www.amazon.com/gp/help/customer/display.html?nodeId=201240840;
http://www.amazon.com/gp/feature.html/ref=kcp_iph_ln_ar?docId=1000301301;
http://www.amazon.com/gp/help/customer/display.html?nodeId=200729450;
http://www.amazon.com/gp/help/customer/display.html?nodeId=201009460;
http://www.amazon.com/kindle-fire-hd-best-family-kids-tablet/dp/B00CU0NSCU;
https://developer.amazon.com/sdk/fire/specifications.html.
-56-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 57 of 65 PageID #: 57
by making, using, selling, and/or offering for sale in the United States or importing into the
United States products covered by at least one claim of the ’556 Patent. Apple has notice of the
’556 Patent. Apple actively induces content providers and/or end users of Apple products to
infringe the ’556 Patent by, among other things, (a) providing access to certain “apps” (such as
the iTunes client, the Amazon Kindle, Amazon Instant Video, and/or Google Play “apps”) that
use the ContentGuard DRM solution claimed in the ’556 Patent, (b) providing instructions for
using such “apps”; (c) providing advertisings for using such “apps”; and (d) providing hardware
and software components required by the claims of the ’556 Patent.40 Apple engages in the
foregoing activities because it specifically intends end users of Apple products to use “apps” that
deploy, and content providers to distribute content that is protected by, the ContentGuard DRM
solutions claimed in the ’556 Patent. Apple thereby specifically intends end users and content
providers to infringe the ’556 Patent. Apple derives revenue from both its own and the thirdparty infringers’ infringing activities. Indeed, Apple’s ability to sell the accused products is
wholly dependent upon the availability of these “apps” and the digital content they make
available to users. Apple also contributorily infringes the ’556 Patent because there is no
substantial non-infringing use of these “apps” on the accused Apple products. These “apps”
cannot be used with accused Apple products without infringing the ’556 Patent.
40
See, e.g., http://www.apple.com/itunes/features/#store;
http://www.apple.com/itunes/;
https://itunes.apple.com/in/app/kindle/id302584613;
https://itunes.apple.com/us/app/google-play-books/id400989007;
https://itunes.apple.com/us/app/app-for-google-music-free/id485638799;
https://itunes.apple.com/us/app/google-tv-remote/id422137859?l=es&mt=8;
http://www.apple.com/in/iphone-5s/specs/;
http://www.apple.com/in/ipad/specs/;
http://www.apple.com/in/ipod-touch/specs.html.
-57-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 58 of 65 PageID #: 58
96.
BlackBerry has been and is now directly infringing and/or indirectly infringing
the ’556 Patent by way of inducement and/or contributory infringement, literally and/or under
the doctrine of equivalents, in this District, and elsewhere, in violation of 35 U.S.C. § 271,
including by making, using, selling, and/or offering for sale in the United States or importing
into the United States products covered by at least one claim of the ’556 Patent. BlackBerry has
notice of the ’556 Patent. BlackBerry actively induces content providers and/or end users of
BlackBerry products to infringe the ’556 Patent by, among other things, (a) providing access to
certain “apps” (such as the iTunes client, the Amazon Kindle, Amazon Instant Video, and/or
Google Play “apps”) that use the ContentGuard DRM solution claimed in the ’556 Patent, (b)
providing instructions for using such “apps”; (c) providing advertisings for using such “apps”;
and (d) providing hardware and software components required by the claims of the ’556 Patent.41
BlackBerry engages in the foregoing activities because it specifically intends end users of
BlackBerry products to use “apps” that deploy, and content providers to distribute content that is
protected by, the ContentGuard DRM solutions claimed in the ’556 Patent. BlackBerry thereby
specifically intends end users and content providers to infringe the ’556 Patent. BlackBerry
derives revenue from both its own and the third-party infringers’ infringing activities. Indeed,
BlackBerry’s ability to sell the accused products is wholly dependent upon the availability of
these “apps” and the digital content they make available to users. BlackBerry also contributorily
infringes the ’556 Patent because there is no substantial non-infringing use of these “apps” on the
41
See, e.g., http://in.blackberry.com/apps/blackberry-world.html#tab-1;
http://appworld.blackberry.com/webstore/content/25058915/?countrycode=IN&lang=en;
http://appworld.blackberry.com/webstore/content/65525/?countrycode=US&lang=en;
http://in.blackberry.com/apps/blackberry-world.html#tab-1;
http://appworld.blackberry.com/webstore/content/25058915/?countrycode=IN&lang=en;
http://in.blackberry.com/smartphones/blackberry-z30/specifications.html.
-58-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 59 of 65 PageID #: 59
accused BlackBerry products. These “apps” cannot be used with accused BlackBerry products
without infringing the ’556 Patent.
97.
Huawei has been and is now directly infringing and/or indirectly infringing the
’556 Patent by way of inducement and/or contributory infringement, literally and/or under the
doctrine of equivalents, in this District, and elsewhere, in violation of 35 U.S.C. § 271, including
by making, using, selling, and/or offering for sale in the United States or importing into the
United States products covered by at least one claim of the ’556 Patent. Huawei has notice of
the ’556 Patent.
Huawei actively induces content providers and/or end users
of Huawei
products to infringe the ’556 Patent by, among other things, (a) providing access to certain
“apps” (such as the iTunes client, the Amazon Kindle, Amazon Instant Video, and/or Google
Play “apps”) that use the ContentGuard DRM solution claimed in the ’556 Patent, (b) providing
instructions for using such “apps”; (c) providing advertisings for using such “apps”; and (d)
providing hardware and software components required by the claims of the ’556 Patent.42
Huawei engages in the foregoing activities because it specifically intends end users of Huawei
products to use “apps” that deploy, and content providers to distribute content that is protected
by, the ContentGuard DRM solutions claimed in the ’556 Patent. Huawei thereby specifically
intends end users and content providers to infringe the ’556 Patent. Huawei derives revenue
from both its own and the third-party infringers’ infringing activities. Indeed, Huawei’s ability
42
See, e.g., http://huaweimobile.com;
http://www.huaweidevice.com/worldwide/productMobile.do?method=index&directoryId=6001
&treeId=3745;
http://www.huaweidevice.com/worldwide/productFeatures.do?pinfoId=3298&directoryId=6001
&treeId=3745&tab=0;
http://www.huaweidevice.com/worldwide/technicaIndex.do?method=gotoProductSupport&prod
uctId=3942&tb=0%29;
http://www.huaweidevice.com/worldwide/downloadCenter.do?method=toDownloadFile&flay=d
ocument&softid=NDcxOTM=;
http://www.uscellular.com/uscellular/pdf/huawei-ascend-y-google-play.pdf.
-59-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 60 of 65 PageID #: 60
to sell the accused products is wholly dependent upon the availability of these “apps” and the
digital content they make available to users. Huawei also contributorily infringes the ’556 Patent
because there is no substantial non-infringing use of these “apps” on the accused Huawei
products. These “apps” cannot be used with accused Huawei products without infringing the
’556 Patent.
98.
Motorola has been and is now directly infringing and/or indirectly infringing the
’556 Patent by way of inducement and/or contributory infringement, literally and/or under the
doctrine of equivalents, in this District, and elsewhere, in violation of 35 U.S.C. § 271, including
by making, using, selling, and/or offering for sale in the United States or importing into the
United States products covered by at least one claim of the ’556 Patent. Motorola has notice of
the ’556 Patent. Motorola actively induces content providers and/or end users of Motorola
products to infringe the ’556 Patent by, among other things, (a) providing access to certain
“apps” (such as the iTunes client, the Amazon Kindle, Amazon Instant Video, and/or Google
Play “apps”) that use the ContentGuard DRM solution claimed in the ’556 Patent, (b) providing
instructions for using such “apps”; (c) providing advertisings for using such “apps”; and (d)
providing hardware and software components required by the claims of the ’556 Patent.43
Motorola engages in the foregoing activities because it specifically intends end users of Motorola
products to use “apps” that deploy, and content providers to distribute content that is protected
by, the ContentGuard DRM solutions claimed in the ’556 Patent. Motorola thereby specifically
43
See, e.g., http://www.motorola.com/us/FLEXR1-1/Moto-X/FLEXR1.html;
https://motorola-globalportal.custhelp.com/app/product_page/faqs/p/30,6720,8882/session/L3RpbWUvMTM4Mzc3MT
A0MS9zaWQvblhuRklIRWw%3D#/how_do_i;
http://www.motorola.com/us/ANDROID/m-Android-Overview.html;
http://www.mobileworldlive.com/verizon-preloads-amazon-kindle-app-on-android-devices;
https://motorola-global-portal.custhelp.com/app/answers/detail/a_id/70762/action/auth.
-60-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 61 of 65 PageID #: 61
intends end users and content providers to infringe the ’556 Patent. Motorola derives revenue
from both its own and the third-party infringers’ infringing activities. Indeed, Motorola’s ability
to sell the accused products is wholly dependent upon the availability of these “apps” and the
digital content they make available to users. Motorola also contributorily infringes the ’556
Patent because there is no substantial non-infringing use of these “apps” on the accused Motorola
products. These “apps” cannot be used with accused Motorola products without infringing the
’556 Patent.
WILLFUL INFRINGEMENT
99.
Defendants’ infringement occurred with knowledge of and/or objective
recklessness and thus has been and continues to be willful and deliberate. Defendants’ willful
and deliberate infringement entitles ContentGuard to enhanced damages under 35 U.S.C. § 285.
IRREPARABLE HARM TO CONTENTGUARD
100.
ContentGuard has been irreparably harmed by the Defendants’ acts of
infringement, and will continue to be harmed unless and until Defendants’ acts of infringement
are enjoined by this Court. ContentGuard has no adequate remedy at law to redress Defendants’
continuing acts of infringement. The hardships that would be imposed upon Defendants by an
injunction are less than those faced by ContentGuard should an injunction not issue.
Furthermore, the public interest would be served by issuance of an injunction. As a result of
Defendants’ acts of infringement, ContentGuard has suffered and will continue to suffer
damages in an amount to be proved at trial.
-61-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 62 of 65 PageID #: 62
PRAYER FOR RELIEF
WHEREFORE, ContentGuard prays for the following relief:
101.
A judgment that Amazon directly and/or indirectly infringes the ’859, ’072, ’576,
’956, ’007, ’160, and ’556 patents;
102.
A judgment that Apple directly and/or indirectly infringes the ’859, ’072, ’280,
’053, ’576, ’956, ’007, ’160, and ’556 patents;
103.
A judgment that BlackBerry directly and/or indirectly infringes the ’859, ’072,
’280, ’053, ’576, ’956, ’007, ’160, and ’556 patents;
104.
A judgment that Huawei directly and/or indirectly infringes the ’859, ’072, ’280,
’053, ’576, ’956, ’007, ’160, and ’556 patents;
105.
A judgment that Motorola directly and/or indirectly infringes the ’859, ’072, ’280,
’053, ’576, ’956, ’007, ’160, and ’556 patents;
106.
A permanent injunction preventing Amazon and its respective officers, directors,
agents, servants, employees, attorneys, licensees, successors, and assigns, and those in active
concert or participation with any of them, from engaging in infringing activities with respect to
the ’859, ’072, ’576, ’956, ’007, ’160, and ’556 patents;
107.
A permanent injunction preventing Apple and its respective officers, directors,
agents, servants, employees, attorneys, licensees, successors, and assigns, and those in active
concert or participation with any of them, from engaging in infringing activities with respect to
the ’859, ’072, ’280, ’053, ’576, ’956, ’007, ’160, and ’556 patents;
108.
A permanent injunction preventing Blackberry and its respective officers,
directors, agents, servants, employees, attorneys, licensees, successors, and assigns, and those in
-62-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 63 of 65 PageID #: 63
active concert or participation with any of them, from engaging in infringing activities with
respect to the ’859, ’072, ’280, ’053, ’576, ’956, ’007, ’160, and ’556 patents;
109.
A permanent injunction preventing Huawei and its respective officers, directors,
agents, servants, employees, attorneys, licensees, successors, and assigns, and those in active
concert or participation with any of them, from engaging in infringing activities with respect to
the ’859, ’072, ’280, ’053, ’576, ’956, ’007, ’160, and ’556 patents;
110.
A permanent injunction preventing Motorola and its respective officers, directors,
agents, servants, employees, attorneys, licensees, successors, and assigns, and those in active
concert or participation with any of them, from engaging in infringing activities with respect to
the ’859, ’072, ’280, ’053, ’576, ’956, ’007, ’160, and ’556 patents;
111.
A judgment that Amazon’s infringement has been willful;
112.
A judgment that Apple’s infringement has been willful;
113.
A judgment that BlackBerry’s infringement has been willful;
114.
A judgment that Huawei’s infringement has been willful;
115.
A judgment that Motorola’s infringement has been willful;
116.
A ruling that this case is exceptional under 35 U.S.C. § 285 as to each Defendant;
117.
A judgment and order requiring each Defendant to pay ContentGuard damages
under 35 U.S.C. § 284, including supplemental damages for any continuing post-verdict
infringement up until entry of judgment, with an accounting, as needed, as well as treble
damages for willful infringement under 35 U.S.C. § 285;
118.
A judgment and order requiring each Defendant to pay ContentGuard’s costs of
this action (including all disbursements);
-63-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 64 of 65 PageID #: 64
119.
A judgment and order requiring each Defendant to pay pre-judgment and post-
judgment interest on damages awarded;
120.
A judgment and order requiring that in the event a permanent injunction
preventing future infringement is not granted, that Defendants pay ContentGuard a compulsory
ongoing licensing fees; and
121.
Such other and further relief as the Court may deem just and proper.
-64-
Case 2:13-cv-01112 Document 1 Filed 12/18/13 Page 65 of 65 PageID #: 65
Dated: December 18, 2013
Respectfully submitted,
/s/ Sam Baxter
Samuel F. Baxter
Texas State Bar No. 01938000
[email protected]
MCKOOL SMITH, P.C.
104 East Houston, Suite 300
Marshall, Texas 75670
Telephone: (903) 923-9000
Facsimile: (903) 923-9099
Holly E. Engelmann
[email protected]
Seth R. Hasenour
[email protected]
MCKOOL SMITH P.C.
300 Crescent Court, Suite 1500
Dallas, Texas 75201
Telephone: (214) 978-4000
Facsimile: (214) 978-4004
Robert A. Cote
[email protected]
Radu A. Lelutiu
[email protected]
Shahar Harel
[email protected]
David R. Dehoney
[email protected]
MCKOOL SMITH P.C.
One Bryant Park, 47th Floor
New York, New York 10036
Telephone: (212) 402-9400
Facsimile: (212) 402-9444
ATTORNEYS FOR CONTENTGUARD
HOLDINGS, INC.
-65-
Case 2:13-cv-01112 Document 1-1 Filed 12/18/13 Page 1 of 4 PageID #: 66
Exhibit A
Microsoft Collaborates with Xerox and ContentGuard to Facilitate Secure Distribution of Electronic Content
Case 2:13-cv-01112 Document 1-1 Filed 12/18/13 Page 2 of 4 PageID #: 67
Sign in
News Center
Mobile
Our Company
Our Products
TopStories
Blogs & Communities
Microsoft takes measures to shield
customer data from govt. snooping
2013-12-04
April 27, 2000
ContentGuard, Inc., a Xerox spin-off company augmented by Microsoft investments, will offer an
easy way to protect digital material distributed over the Internet and expand consumer choice.
Tweet
0
0
Share
PALO ALTO, Calif., April 27, 2000 — When Stephen King's novella, "Riding the Bullet," was released
over the Internet last month, the publishing world heralded it as a glimpse into the future of electronic
book distribution. Its release proved two major points about eBooks. First, it proved there was real
demand for premium digital content -- there were 500,000 downloads of the book in its first 48
hours of availability, and some servers shut down trying to keep up with the demand. It also proved
that digital content is subject to piracy. Hackers managed to break the book's encryption code, and
pirated copies were distributed illegally to a number of Web sites and chat groups.
The distribution of books and other digital media over the Internet has opened up enormous
possibilities for consumers in how they can sample, experience and purchase electronic materials. At
the same time, suppliers are working to create a distribution system known as "digital rights
management (DRM) technology" that ensures protection for copyrighted material while making it easy
for consumers to buy and enjoy these forms of digital entertainment.
"People love getting content delivered to them wherever and whenever they chose, and we want to
ensure that they continue to have many opportunities to do so," said Microsoft President and CEO
Steve Ballmer as he announced today's launch of ContentGuard, Inc., a spin-off of the Xerox Corp.
The new Internet company, created with the help of an investment from Microsoft, will offer a
comprehensive software system to protect and manage books, documents, music, software and other
valuable content that is distributed over the Web. "The secure and safe delivery of digital media is of
primary importance to not only everyone in the business of content distribution, but consumers of this
information as well," Ballmer said.
ContentGuard's DRM technology, originally developed at the Xerox Palo Alto Research Center and
augmented with contributions from Microsoft , provides products such as software and consulting
services as well as Internet-based solutions to help content distributors disseminate digital content
over the Internet in a way that is protected but still easily accessible to consumers.
Microsoft and ContentGuard will also collaborate on future development of DRM technology.
Microsoft will support ContentGuard's licensing and rights labeling format in its own DRM solutions.
Microsoft Reader, a new software product for displaying books on screen, will be the first product to
incorporate the new ContentGuard technology when it debuts this summer. The technology will also
be extended to support future versions of Windows Media Player and Windows Digital Rights
Manager.
"ContentGuard will offer a safe and secure e-commerce environment for publishing and distributing
any high-value or copyrighted material," said Xerox President and CEO Rick Thoman.
ContentGuard's Internet content protection software is designed to "lock" digital content, preventing
unauthorized users from forwarding it or copying it unless they have paid or registered with the
content owner.
http://www.microsoft.com/en-us/news/features/2000/04-27contentguard.aspx[12/10/2013 2:09:09 PM]
Follow
Nifty gifts are close at hand with these Bing Maps preview app on Windows
tech tips and tools
8.1 delivers the world in 3D
2013-12-05
2013-12-05
Microsoft Collaborates with Xerox and ContentGuard to
Facilitate Secure Distribution of Electronic Content
Like
Subscribe
Press Tools
Press Contacts
Rapid Response Team
Waggener Edstrom Worldwide
(503) 443-7070
Related Links
Press Release:
Microsoft Takes Stake in Xerox E-Commerce
Spinoff to Deliver Total Publishing and Rights
Management Solution for eBooks, Digital Content
on the Web - Apr. 27, 2000
Microsoft Resource:
Microsoft Reader
External Resources:
ContentGuard
Xerox
Microsoft Collaborates with Xerox and ContentGuard to Facilitate Secure Distribution of Electronic Content
Case 2:13-cv-01112 Document 1-1 Filed 12/18/13 Page 3 of 4 PageID #: 68
Once content owners such as publishers or authors establish specifications for how customers will
access their publications, ContentGuard will incorporate those specifications into the content and use
encryption technology to "lock" the content. Anyone who wants access to the material must obtain a
digitally signed "license" to unlock the content. When users attempt to access a ContentGuardenabled document, they are sent to a digital rights management Web site where they make a
payment as they would in any standard e-commerce transaction. The user can then download the
digital content and see or hear it by employing a standard viewer or player.
While users can redistribute the content, new recipients will have to acquire their own "license" before
gaining access to the content. In other words, if someone enjoyed reading, "Riding the Bullet," and
wanted to send it to a friend, he or she could do so, but the recipient would have to pay for the right
to read it.
While DRM technology has been available from many sources, the benefit of the ContentGuard
approach is that it is flexible enough so that publishers can use marketing initiatives such as single
chapter preview programs or one-time usage scenarios to promote their products. Such promotions
will let consumers sample content before actually having to pay for it.
"Content wants to be free, but content creators want to get paid," said Dick Brass, vice president for
technology development at Microsoft. "ContentGuard's ease of use for publishers and for consumers
certainly ensures it an immediate presence in the eBook industry." Brass and Xerox Internet Business
Group president, Michael Miron, will be co-chairmen of ContentGuard's board of directors.
Microsoft and ContentGuard will also collaborate on the development of a common digital rights
management standard for the many emerging digital content categories. This will assure that content
developers such as publishers and authors receive payment and retain control over how their
materials are used.
ContentGuard will work to establish one of its core technologies, XrML (eXtensible rights Markup
Language) as a standard for digital rights management on the Internet. It has agreed to provide the
XrML code to the industry royalty-free to stimulate its use among software developers and content
providers. By freely licensing XrML, ContentGuard is promoting the use of digital rights specifications
among authors, artists, publishers, distributors and retailers who may use software products from
different vendors.
"The creation of common standards among these varied groups will be critical to making the most of
the Internet as a way of distributing published materials," Miron said.
Although ContentGuard's current focus is on the publishing and eBook markets, creating a standard
way for applications to support digital rights management opens doors for many markets. It will allow
developers to create a new generation of common products such as word processing applications,
spread sheets, email, media players and eBook readers, with built-in digital rights management
features. The ContentGuard technology will be integrated into commonly used technology so as to
create minimal intrusion for the consumer.
"Digital rights management will become a ubiquitous element of all content exchange eventually,
whether for secure ecommerce or for ensuring the persistent protection of high-value sensitive
material," Brass said. "ContentGuard's mission is to drive this evolution."
Currently, the ContentGuard software suite can protect the distribution of digital content such as
market research, business reports, books, periodicals, sheet music, patent applications and academic
course packs. Plans are under way to enable ContentGuard for audio and video material.
"Ultimately, as ContentGuard and other digital rights management software is widely adopted,
consumers will be able to access a far greater range of digital content over the Internet than ever
before-whether it's music, software or eBooks," Brass said. "Since they won't need to download special
software, this process will be simple and fast."
Mobile
Other Microsoft sites
Windows
Follow
Downloads
Security
Popular resources
Download Center
Security home
Windows Phone devices
Windows downloads
Microsoft Security Essentials
Windows Phone apps and games
Office
Office downloads
Surface
Support
http://www.microsoft.com/en-us/news/features/2000/04-27contentguard.aspx[12/10/2013 2:09:09 PM]
Subscribe
About
Microsoft
Laptops and desktop computers
Microsoft computer security
Microsoft Collaborates with Xerox and ContentGuard to Facilitate Secure Distribution of Electronic Content
Malware 4
removal
toolPageID #: 69
Case 2:13-cv-01112 Document 1-1 Filed 12/18/13 Page
of 4
Windows Phone
Xbox
Skype
Support home
Careers
Knowledge base
Company News
Free antivirus software
Cloud computing solutions
Investor relations
Microsoft Dynamics CRM Online
Site map
Bing
Microsoft Store
United States
Contact Us
http://www.microsoft.com/en-us/news/features/2000/04-27contentguard.aspx[12/10/2013 2:09:09 PM]
Terms of Use
Trademarks
Privacy & Cookies
©2013 Microsoft
Case 2:13-cv-01112
Document 1-2
Filed 12/18/13
Exhibit B
Page
1 of 2
PageID
70
Case 2:13-cv-01112
Document 1-2
Filed 12/18/13
Page
2 of 2
PagelD#:
w
>6
2
Cr
c
2
4.,
CC
illt:
uj
mem.
0
c4,,,,
r'.33
-0
c
0
.2
I'S
cll
Iowa, farm
9:',
t'
1::3
Ei
ie-•
tfl
e-
r...J
O
in
U)
LAU
Z
2
0
u
3
2
al
0
CX
imam'
lama
Uni
Um
Itr.
0
-F.,
.r..-
‘jdgiewa
Wia
-0
-a"
-0
.1:
a
MUM
C-3
a).
C
cz
LD
6..
•5
A
an)
2, 0
M-•
r-
E
(t7
s
co
Co
6-
-6
CO
CD
:1.--•
L.
1.`3141
gi)
c
r'3
ai
t'l:
--2
ki
'FA
6
m
W
E
c
a,
4'
E
_c
c
w
c,
c
LI
Uinr._.
0 a:
re_
2
14J
zt
ets)
X
oz
.z-.
E
'c
r
t
0.)
nu E
lkd
Wm;
tuft
X
c
c.,1
--i,
01
0C g
ti
F
z
z.)
o
z
i.l.
4-•
aj
-3,•13,
in."
0
4
0
LLI
E
0
a)
'otto.
w
X
0
cc
c.
al
.6.
LI)
2
EPhi
1-•-%
CD
I..
:t^
taLl
Iwoj,
0
0: -0
0
v,
75'
C)
0-
*mar
..c
1:1"
7;;
e:
1.^
L3
CD
1).
11Si!Mi
r3
t
^'S
0
c
'5
c:
.7.3
0
9-
1
71
Case 2:13-cv-01112 Document 1-3 Filed 12/18/13 Page 1 of 45 PageID #: 72
Exhibit C
Case 2:13-cv-01112 Document 1-3 Filed 12/18/13 Page 2 of 45 PageID #: 73
111111
1111111111111111111111111111111111111111111111111111111111111
US006963859B2
(12)
United States Patent
(10)
Stefik et al.
(45)
(54)
CONTENT RENDERING REPOSITORY
(75)
Inventors: Mark J. Stefik, Portola Valley, CA
(US); Peter L. Pirolli, San Francisco,
CA(US)
(73)
Assignee: ContentGuard Holdings, Inc.,
Wilmington, DE (US)
( *)
Notice:
(21)
Appl. No.: 10/345,390
(22)
Filed:
Subject to any disclaimer, the term of this
patent is extended or adjusted under 35
U.S.C. 154(b) by 78 days.
Prior Publication Data
US 2003/0225699 A1 Dec. 4, 2003
Related U.S. Application Data
( 63)
(51)
(52)
(58)
3,790,700
3,798,605
4,159,468
4,220,991
Continuation of application No. 09/778,006, filed on Feb. 7,
2001, now Pat. No. 6,714,921, which is a division of
application No. 08/967,084, filed on Nov. 10, 1997, now Pat.
No. 6,236,971, which is a continuation of application No.
08/344,760, filed on Nov. 23, 1994, now abandoned.
Int. Cl? ................................................ G06F 17/60
U.S. Cl. ............................. 705/51; 705/52; 705/53;
705/54; 705!55; 705!56; 705/57; 705/58;
705!59; 705!50; 380/201; 707/9; 707/104.1;
713/182; 713/183; 713/184; 713/185; 713/186
Field of Search ...................... 705!50--59; 380/201,
380/30; 707/9, 104.1; 713/182-186, 156;
235/449; 379/93
References Cited
(56)
U.S. PATENT DOCUMENTS
3,263,158 A
3,609,697 A
7/1966 Bargen et a!.
9/1971 Blevins et a!.
A
A
A
A
2/1974
3/1974
6/1979
9/1980
US 6,963,859 B2
Nov. 8, 2005
Callais et a!.
Feistel
Barnes et a!.
Hamano et a!.
(Continued)
FOREIGN PATENT DOCUMENTS
EP
EP
EP
EP
EP
0
0
0
0
0
084
180
332
651
668
441
460
707
554
695
7/1983
5/1986
9/1989
5/1995
8/1995
(Continued)
OTHER PUBLICATIONS
Jan. 16, 2003
(65)
Patent No.:
Date of Patent:
Weber, Robert. Digital Rights Management Technologies.
Oct. 1995. Retrieved from IDS.*
"National Semiconductor and EPR Partner for Information
Metering/Data Security Cards" Mar. 4, 1994, Press Release
from Electronic Publishing Resources, Inc.
(Continued)
Primary Examiner-James A Reagan
(74) Attorney, Agent, or Firm-Marc S. Kaufman; Nixon
Peabody, LLP
(57)
ABSTRACT
A rendering system adapted for use in a system for managing
use of content and operative to rendering content in accordance with usage rights associated with the content. The
system includes a rendering device configured to render the
content and a repository coupled to the rendering device and
operative to enforce usage rights associated with the content
and permit the rendering device to render the content in
accordance with a manner of use specified by the usage
rights.
84 Claims, 13 Drawing Sheets
Case 2:13-cv-01112 Document 1-3 Filed 12/18/13 Page 3 of 45 PageID #: 74
US 6,963,859 B2
Page 2
U.S. PATENT DOCUMENTS
4,278,837
4,323,921
4,442,486
4,529,870
4,558,176
4,593,376
4,614,861
4,644,493
4,658,093
4,713,753
4,796,220
4,817,140
4,827,508
4,868,376
4,891,838
4,924,378
4,932,054
4,937,863
4,949,187
4,953,209
4,961,142
4,975,647
4,977,594
4,999,806
5,010,571
5,014,234
5,023,907
5,047,928
5,050,213
5,052,040
5,058,164
5,103,476
5,113,519
5,136,643
5,138,712
5,146,499
5,148,481
5,159,182
5,183,404
5,191,193
5,204,897
5,222,134
5,235,642
5,247,575
5,255,106
5,260,999
5,263,157
5,263,158
5,276,444
5,276,735
5,291,596
5,295,266
5,301,231
5,311,591
5,319,705
5,335,346
5,337,357
5,339,091
5,339,392
5,341,429
5,347,579
5,381,526
5,394,469
5,410,598
5,412,717
5,428,606
5,432,849
5,438,508
5,444,779
5,453,601
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
*
*
*
*
*
7/1981
4/1982
4/1984
7/1985
12/1985
6/1986
9/1986
2/1987
4/1987
12/1987
1!1989
3/1989
5/1989
9/1989
1!1990
5/1990
6/1990
6/1990
8/1990
8/1990
10/1990
12/1990
12/1990
3/1991
4/1991
5/1991
6/1991
9/1991
9/1991
9/1991
10/1991
4/1992
5/1992
8/1992
8/1992
9/1992
9/1992
10/1992
2/1993
3/1993
4/1993
6/1993
8/1993
9/1993
10/1993
11/1993
11/1993
11/1993
1!1994
1!1994
3/1994
3/1994
4/1994
5/1994
6/1994
8/1994
8/1994
8/1994
8/1994
8/1994
9/1994
1!1995
2/1995
4/1995
5/1995
6/1995
7/1995
8/1995
8/1995
9/1995
Best
Guillou
Mayer
Chaum
Arnold eta!.
Yolk
Pavlov eta!.
Chandra et a!.
Hellman
Beobert et a!.
Wolfe
Chandra et a!.
Shear
Lessin eta!.
Faber
Hershey et a!.
Chou eta!.
Robert eta!.
Cohen
Ryder, Sr. et a!.
Elliott et a!.
Downer eta!.
Shear
Chernow et a!.
Katznelson
Edwards, Jr.
Johnson et a!.
Wiedemer
Shear
Preston et a!.
Elmer eta!.
Waite eta!.
Johnson et a!.
Fischer
Corbin ....................... 713/200
Geffrotin
Abraham et a!.
Eisele
Aldous eta!.
LeRoux
Wyman
Waite eta!.
Wobber eta!.
Sprague et a!.
Castro
Wyman ....................... 705!59
Janis
Janis
McNair
Boebert et a!.
Mita
Hinsley et a!. ............. 718/101
Abraham et a!.
Fischer
Halter eta!.
Fabbio ....................... 711!163
Chou eta!.
Yamazaki eta!.
Risberg et a!. ............. 345/762
Stringer et a!.
Blandford
Elison
Nagel eta!.
Shear
Fischer
Moskowitz
Johnson et a!.
Wyman
Daniele
Rosen
5,455,953
5,457,746
5,473,687
5,473,692
5,499,298
5,502,766
5,504,814
5,504,818
5,504,837
5,509,070
5,530,235
5,532,920
5,534,975
5,539,735
5,563,946
5,568,552
5,621,797
5,629,980
5,633,932
5,634,012
5,638,443
5,649,013
5,655,077
5,708,717
5,734,823
5,734,891
5,737,413
5,737,416
5,745,569
5,748,783
5,757,907
5,761,686
5,765,152
5,768,426
5,825,892
5,892,900
5,910,987
5,915,019
5,917,912
5,920,861
5,940,504
5,943,422
5,949,876
5,982,891
5,999,949
6,047,067
6,112,181
6,115,471
6,138,119
6,157,721
6,185,683
6,226,618
6,233,684
6,237,786
6,240,185
6,253,193
6,266,618
6,292,569
6,301,660
6,327,652
6,330,670
6,345,256
6,363,488
6,389,402
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
10/1995
10/1995
12/1995
12/1995
3/1996
3/1996
4/1996
4/1996
4/1996
4/1996
6/1996
7/1996
7/1996
7/1996
10/1996
10/1996
4/1997
5/1997
5/1997
5/1997
6/1997
7/1997
8/1997
1!1998
3/1998
3/1998
4/1998
4/1998
4/1998
5/1998
5/1998
6/1998
6/1998
6/1998
10/1998
4/1999
6/1999
6/1999
6/1999
7/1999
8/1999
8/1999
9/1999
11/1999
12/1999
4/2000
8/2000
9/2000
10/2000
12/2000
2/2001
5/2001
5/2001
5/2001
5/2001
6/2001
7/2001
9/2001
10/2001
12/2001
12/2001
2/2002
3/2002
5!2002
Russell
Dolphin
Lipscomb et a!.
Davis
Narasimhalu et a!.
Boebert et a!.
Miyahara
Okano
Griffeth et a!.
Schull
Stefik eta!.
Hartrick et a!.
Stefik eta!.
Moskowitz
Cooper eta!.
Davis
Rosen
Stefik eta!.
Davis eta!.
Stefik eta!.
Stefik eta!.
Stuckey et a!.
Jones eta!.
Alasia
Saigh eta!.
Saigh
Akiyama et a!.
Cooper eta!.
Moskowitz et a!.
Rhoads
Cooper eta!.
Bloomberg
Erickson
Rhoads
Braudaway et a!.
Ginter eta!.
Ginter eta!.
Ginter eta!.
Ginter eta!.
Hallet a!.
Griswold
VanWie eta!.
Ginter eta!.
Ginter eta!.
Crandall
Rosen
Shear eta!.
Oki eta!.
Hallet a!.
Shear eta!.
Ginter eta!.
Downs eta!.
Stefik eta!.
Ginter eta!.
VanWie eta!.
Ginter eta!.
Ye eta!.
Shear eta!.
Benson
England et a!.
England et a!.
Milsted et a!.
Ginter eta!.
Ginter eta!.
FOREIGN PATENT DOCUMENTS
EP
GB
GB
JP
JP
0 725 376
2 136 175
2 236 604
62-241061
64-068835
8/1996
9/1984
4/1991
10/1987
3/1989
Case 2:13-cv-01112 Document 1-3 Filed 12/18/13 Page 4 of 45 PageID #: 75
US 6,963,859 B2
Page 3
JP
JP
JP
JP
JP
JP
JP
JP
JP
wo
wo
wo
wo
wo
wo
wo
wo
wo
H03-282733
04-369068
05-268415
06-175794
06-215010
07-084852
07-200317
07-244639
0 715 241
wo 92/20022
wo 93/01550
wo 94/01821
wo 96/24092
wo 97/48203
wo 98/11690
wo 98/42098
wo 99/49615
wo 01/63528
* 12/1991
............. G06F/9/06
12/1992
10/1993
6/1994
8/1994
3/1995
8/1995
9/1995
6/1996
11/1992
1!1993
1!1994
8/1996
12/1997
3/1998
9/1998
9/1999
8/2001
01HER PUBLICATIONS
Weber, R., "Digital Rights Management Technology" Oct.
1995.
Flasche, U. et al., "Decentralized Processing of Documents", pp. 119-131, 1986, Comput. & Graphics, vol. 10,
No.2.
Mori, R. et al., "Superdistribution: The Concept and the
Architecture", pp. 1133-1146, 1990. The Transactions of the
IEICE, Vo. E 73, No. 7, Tokyo, JP.
Weber, R., "Metering Technologies for Digital Intellectual
Property", pp. 1-29, Oct. 1994, A Report to the International
Federation of Reproduction Rights Organizations.
Clark, P.C. et al., "Bits: A Smartcard protected Operating
System", pp. 66-70 and 94, Nov. 1994, Communications of
the ACM, vol. 37, No. 11.
Ross, P.E., "Data Guard", pp. 101, Jun. 6, 1994, Forbes.
Saigh, W.K., "Knowledge is Sacred", 1992, Video Pocket/
Page Reader Systems, Ltd.
Kahn, R.E., "Deposit, Registration and Recordation in an
Electronic Copyright Management System", pp. 1-19, Aug.
1992, Corporation for National Research Initiatives, Virginia.
Hilts, P. et al., "Books While U Wait", pp. 48-50, Jan. 3,
1994, Publishers Weekly.
Strattner, A, "Cash Register on a Chip may Revolutionaize
Software Pricing and Distribution; Wave Systems Corp.",
pp. 1-3,Apr. 1994, Computer Shopper, vol. 14, No.4, ISSN
0886-0556.
O'Conner, M., "New Distribution Option for Electronic
Publishers; iOpener Data Encryption and Metering System
for CD-ROM use; Column", pp. 1-6, Mar. 1994, CD-ROM
Professional, vol. 7, No. 2, ISSN: 1409-0833.
Willett, S., "Metered PCs: Is Your System Watching You?
Wave System beta tests new technology", pp. 84, May 2,
1994, InfoWorld.
Linn, R., "Copyright and Information Services in the Context of the National Research and Education Network", pp.
9-20, Jan. 1994, IMAintellectual Property Project Proceedings, vol. 1, Issue 1.
Perrit, Jr., H., "Permission Headers and Contract Law", pp.
27-48, Jan. 1994, IMA Intellectual Property Project Proceedings, vol. 1, Issue 1.
Upthegrove, L., "Intellectual Property Header Descriptors:
A Dynamic Approach", pp. 63-66, Jan. 1994, IMA Intellectual Property Proceedings, vol. 1, Issue 1.
Sirbu, M., "Internet Billing Service Design and prototype
Implementation", pp. 67-80, Jan. 1994, IMA Intellectual
Property Project Proceedings, vol. 1, Issue 1.
Simmell, S. et al., "Metering and Licensing of Resources:
Kala's General Purpose Approach", pp. 81-110, Jan. 1994,
IMA Intellectual Property Project Proceedings, vol. 1, Issue
1.
Kahn, R., "Deposit Registration and Recordation in an
Electronic Copyright Management System", pp. 111-120,
Jan. 1994, IMA Intellectual Property Project Proceedings,
vol. 1, Issue 1.
Tygar, J. et al., "Dyad: A System for Using Physically Secure
Coprocessors", pp. 121-152, Jan. 1994, IMA Intellectual
Property Project Proceedings, vol. 1, Issue 1.
Griswold, G., "A Method for Protecting Copyright on Networks", pp. 169-178, Jan. 1994, IMA Intellectual Property
Project Proceedings, vol. 1 Issue 1.
Nelson, T., "A Publishing and Royalty Model for Networked
Documents", pp. 257-259, Jan. 1994, IMA Intellectual
Property Project Proceedings, vol. 1, Issue 1.
Robinson, E., "Redefining Mobile Computing", pp.
238-240, 247-248 and 252, Jul. 1993, PC Computing.
Abadi, M. et al., "Authentication and Delegation with
Smart-cards", pp. 1-24, 1990, Research Report DEC Systems Research Center.
Mark Stefik, "Letting Loose the Light: Igniting Commerce
in Electronic Publication", pp. 219-253, 1996, Internet
Dreams: Archetypes, Myths, and Metaphors, IDSN
0-262-19373-6.
Mark Stefik, "Letting Loose the Light: Igniting Commerce
in Electronic Publication", pp. 2-35, Feb. 8, 1995, Internet
Dreams: Archetypes, Myths and Metaphors.
Henry H. Perritt, Jr., "Technological Strategies for Protecting Intellectual Property in the Networked Multimedia Environment", Apr. 2-3, 1993, Knowbots, Permissions
Headers & Contract Law.
* cited by examiner
Case 2:13-cv-01112 Document 1-3 Filed 12/18/13 Page 5 of 45 PageID #: 76
U.S. Patent
Nov. 8, 2005
Sheet 1 of 13
US 6,963,859 B2
Figure 1
101
Creator Creates A
Digital Work
~~
102
Usage Rights Attached To
Oi~ital Work and
Deposited In Repository 1
,,
103
Repository 2 Initiates A
Sess1on With Repository 1
,.
104
Repository 2 Requests
Access To Digital Work for
A Stated Purpose
~·
105
1 Checks Usage
Rights of Digital Work To
Determined if Access May Be
Granted
Reposito~
Access Denied
,,
106
Repostiory 1
Terminates Session
With Error
Access Granted
107
Repository 1 Transmits
Digital Work To
Repository 2
108
Repository 1and 2 Each
Generate Billing
Information and Transmit
To Credit Server
Case 2:13-cv-01112 Document 1-3 Filed 12/18/13 Page 6 of 45 PageID #: 77
U.S. Patent
Nov. 8, 2005
Sheet 2 of 13
US 6,963,859 B2
Figure 2
•...........•
: Master :
·: Repository :
•
Repository
Transactions
•I •
2\..
••••••••••••••••
.
•
• • •
Repository
Transactions
205
• • 1 I
. .
•
•
202
::4-!..--...'~-....
...: ...........
.. •.• •.•
•.•
• •
•
.
.•.•..• .......
..... .
_.·~.....H
:Authorization ..
: __..·_
: Repository • •
204
Repository
201
••••••••••••
•
•
1-~-~-+::
Rendering :
:
. : Repository
•
.._.._....,..--...e:
203
:
.
.
....•
••
•
••••••••••••
Agure 3
.••• ••
.
•
•
Repository
201
.....
.....
.• .••
•
Billin11
/
...
.
•
I
•
•
Transactions
302
......
Credit
Server
301
4~
.••/
...
.. .. ... .•
....
• • • • • .. ••
:
Billing
:
•
' •••••
,~
•
: Clearinghouse:
:
303
:
••••••••••••••••
Clearinghouse
Protocol
304
Case 2:13-cv-01112 Document 1-3 Filed 12/18/13 Page 7 of 45 PageID #: 78
U.S. Patent
Nov. 8, 2005
US 6,963,859 B2
Sheet 3 of 13
Printer System
401
Figure 4a
r---------------------~
I
I
I
Printer
Repository
......
402
I
I
I
I
I
Print Device
403
I
I
--- ·------------4 ~
L--
Repository
404
Figure 4b
Multi-Function System
410
I
r------------------------------~I
Credit
Server
414
...
-""
......
Display/
Execution
Repository
411
A~
L-
r+
-
Display
Engine
412
I
I
...
I
Execution
Engine
413
-----------·, ,------------Repository
415
I
I
I
I
I
I
I
I
I
____ .J
Case 2:13-cv-01112 Document 1-3 Filed 12/18/13 Page 8 of 45 PageID #: 79
U.S. Patent
Nov. 8, 2005
40.000
20,000
0
10.000
30.000
Ad
511
80,000
60,000
so.ooo
70,000
I
I
I
Story A
510
US 6,963,859 B2
Sheet 4 of 13
90,000
StoryC
513
Story&
512
Figure 5
0
10.000
30.000
1.500
Text
614
25,000
Photo
Graphics
615
616
Figure 6
Sidebar
617
Case 2:13-cv-01112 Document 1-3 Filed 12/18/13 Page 9 of 45 PageID #: 80
U.S. Patent
US 6,963,859 B2
Sheet 5 of 13
Nov. 8, 2005
Identifier 701
Figure 7
Starting Address 702
Descriptor
Block
(d-block)
700
length 703
Rights Portion 704
Parent Pointer 705
..•
..••
I
Child Pointer 706
Child Pointer 706
Top
d-block
Figure 8
d-block
821
(Story A)
Figure 9
I
820
d-block
822
(Ad)
d-block.
823
(Story B)
d-block
824
(Story C)
d-block
821
(Story A)
d-block
d-block
d-block
925
927
(Graphics)
(Sidebar)
(Text)
928
Case 2:13-cv-01112 Document 1-3 Filed 12/18/13 Page 10 of 45 PageID #: 81
U.S. Patent
Nov. 8, 2005
Sheet 6 of 13
Figure 10
Right
COde
1050
Status
Information
1052
Figure 14
Right
1450
Transactional
Component
1451
Specification
Component
1452
Fees/Incentives
1454
US 6,963,859 B2
Case 2:13-cv-01112 Document 1-3 Filed 12/18/13 Page 11 of 45 PageID #: 82
U.S. Patent
Nov. 8, 2005
Sheet 7 of 13
US 6,963,859 B2
Identifier (Magazine)
Starting Address (0)
Figure 11
Length (100,000)
root
d-block
1101
Rights Portion
(PRINT,VIEW)
Parent Pointer
Child Pointers
Identifier (Article 2)
"Starting Address
(25,001)
Starting Address (0)
Length (25,000)
Length (25,000)
Rights Portion
(PRINT,VIEW)
Parent Pointer
Rights Portion
(PRINT,VIEW)
Parent Pointer
Child Pointers
Child Pointers
d-block
1102
Identifier (Article 3) ·
Starting Address
(50,001)
Starting Address
(75,001)
Length (25,000)
Length (25,000)
Rights Portion
(VIEW)
Rights Portion
(PRINT (Fee))
Parent Potnter
Parent Pointer
Child Pointers
Child Pointers
d-b lock
1103
d-b lock
1104
Case 2:13-cv-01112 Document 1-3 Filed 12/18/13 Page 12 of 45 PageID #: 83
U.S. Patent
US 6,963,859 B2
Sheet 8 of 13
Nov. 8, 2005
Figure 12
Processing
Means
.................................L ..
Clock
1205
•
--+:
..
...
Processing ,
Element
Processor
Memory
......
...
""'-
·······r···r·········· ····
1202
1201
P'
: •••••••.••••••••.•••••..••••••••••• : /
.:
:
:
Descriptor
Storage
co·ntent
Storage
.
1204
... 1203
....•· .................................•
Figure 13
User
Interface
1305
Repository Spedic
SoftWare
Function/Services
1304
Usage Transaction
Handlers
1303
Core Repository
Serv1ces/
Transaction
Handling
1302
Operating
System
1301
Identification
Certificates
1306
1200
.
External
Interface
1206
~~~~
1207
Case 2:13-cv-01112 Document 1-3 Filed 12/18/13 Page 13 of 45 PageID #: 84
U.S. Patent
Nov. 8, 2005
Sheet 9 of 13
US 6,963,859 B2
1501 -Digital Work Rights:= (Rights*)
1502-- Right : = (Right-Code {Copy-Count} {Control-Spec} {Time-Spec}
{Access-Spec} {Fee-Spec})
1503 .._Right-Code:= Render-Code I Transport-Code I File-ManagementCode( Derivative-Works- Code I Configuration-Code
1504-Render-Code : = [Play: {Player: Player-ID} IPrint: {Printer: Printer-ID}]
1505 -Tran&port-Code: = [Copy ITransfer I Loan {Remaining-Rights:
Next-Set-of-Rights}]{(Next-Copy-Rights: Next-Set-of-Rights)}
1506 ._File-Management-Code : = Backup {Back-Up-Copy-Rights:
Next-Set-of-Rights} I Restore IDelete I Folder
I Directory {Name: Hide-Local\ Hide-Remote}
{Parts: Hide-Local I Hide-Remote}
1507--Derivative-Works-Code:= [Extract I Embed I Edit{Process:
Process-ID}] {Next-Copy-Rights:
Next-Set-of Rights}
1508-...Confiruration-Code: = Install! Unin.stall
1509-...Next-Set-of-Rights :={(Add: Set-Of-Rights)}{(Delete:
Set-Of-Rights)} {(Replace: Set-Of-Rights )}{(Keep: Set-Of-Rights)}
1510..._.Copy-Count := (Copies:positive-integer I 0 I Unlimited)
1511-Control-Spec: = (Control: {Restrictable I Unrestrictable}
{Unchargeable I Chargeable})
'1512-Time-Spec:= ({Fixed-Interval (Sliding-Interval! Meter-Time}
Until: Expiration-Date)
1513 .._Fixed-Interval:= From: Start-Time
1514-Sliding-Interval :=Interval: Use-Duration
1515-Me&er-Time: =Time-Remaining: Remaining-Use
1516 ....__Access-Spec : = ({SC: Security-Class} {Authorization: Authorization-ID*}
{Other-Authorization: Authorization-In*} {Ticket: Tick.et-ID})
1511-- Fee-Spec:= {Scheduled-Discount} Regular-F~pec IScheduled-Fee-Spec I
Markup-Spec
1518--Scheduled-Discount: = Scheduled-Discount: (Scheduled-Discount:
(Time-Spec Percentage)*)
1519--.R.egular-Fee-Spec := ({Fee: I Incentive:} [Per-Use-Spec I Metered-RateSpec I Best-Price-Spec I Call-For-Price-Spec]
{Min: Money-Unit Per: Time-Spec}{Max:
Money-Unit Per: Time-Spec} To: Account-!D)
1520-Per-Use-Spec: Per-Use: Money-unit
1521- Metered-Rate-Spec : = Metered: Money-Unit Per: Time-Spec
1522- Best-Price-Spec : Best-Price: Money-unit Max: Money-unit
=
=
1523--Call-For-Price-Spec :=Call-For -Price
1524- Scheduled-Fee-Spec:= (Schedule: (Time-Sp c Regular-Fee-Spec) )
1525-- Markup-Spec:= Markup: perc ntage To: Account-ID
Fig.15
Case 2:13-cv-01112 Document 1-3 Filed 12/18/13 Page 14 of 45 PageID #: 85
U.S. Patent
Sheet 10 of 13
Nov. 8, 2005
REPOSITORY-1
US 6,963,859 B2
REPOSITORY·2
1601
Generate R~istration
ldenti ier
1602
1605
1603
Transmit Registration
Message
1606
1611
Decrypt Performance
Message
1607
Extract Repository-1
Identifier
Transmit Performance
Message
Transmit Nonce
Yes
1616
Repository-1
Terminate Transaction
Rep sitory- 2
Terminate Transaction
Fig.16
Case 2:13-cv-01112 Document 1-3 Filed 12/18/13 Page 15 of 45 PageID #: 86
U.S. Patent
Sheet 11 of 13
Nov. 8, 2005
US 6,963,859 B2
REPOSITORY-1
REPOSITORY-2
Encrypt Second Key Using
Generate Timestamp
Pubhc Key of Repository-2
Exchange Message
1703
1706
Transmit Encrypted Second
Key To Repository-2
Transmit Timestamp
Exchange Message
To Repository,;.1
Generate Timestamp
Message
1708
Transmit Timestamp
Message To Repository-2
Compare Current Time With
. Time From Repository-1
Compute Adjusted
Time Delta
Fig.17
Case 2:13-cv-01112 Document 1-3 Filed 12/18/13 Page 16 of 45 PageID #: 87
U.S. Patent
Nov. 8, 2005
US 6,963,859 B2
Sheet 12 of 13
Figure 18
SERVER
REQUESTER
t803
Server Generates Transaction
Identifier
Deuement Copy
Count For Right
1813
Determine Set
Of Remaining
Rights
1805
1817
Decrement Copies In Use For
Right By Number In Request
1818
For Metered Use, Subtract
Elapsed nme From Remaining
Use Time For Right
1819
Initiate End-Charge Financial
Transaction to Confirm Billing
Case 2:13-cv-01112 Document 1-3 Filed 12/18/13 Page 17 of 45 PageID #: 88
U.S. Patent
US 6,963,859 B2
Sheet 13 of 13
Nov. 8, 2005
Figure 19
SERVER
(C.nceCJ
Fail
1912
Wait For Ad:
1908
New
Send
Transaction .,___ _~ Next Data
1902
19CMi
I
Commit Repart To
Credit Server
1914
I
'II
'
'II
'
I
t
''
\
~
Date
''
\
1907
Start\
1903 \I
\
\
\I
''
''t
I
Act
''
''
'~
'\
.
•..•........ ,' .•••••...•••.••••••.•.•
'
CUENT
I
I
'
'II
I
I
''
~.
W1itFor
Datil
1905
..•..•...•.....•
I
I
'
I
Walt for
Transaction
1904
i·············~········
I
I
Line
1.901
I
I
I
I
Act
I
I
I
I
I
'•
•
I
t
O.bl
Received
No More
om
Commit Report To
Credit Server
1-
19115
1909
More
O.ta
Acknowledge
1910
(C..C•OV
Fall
1913
Report Error
To Credit Server
1918
I
I
Done
1919
~
Case 2:13-cv-01112 Document 1-3 Filed 12/18/13 Page 18 of 45 PageID #: 89
US 6,963,859 B2
1
2
provided on a medium along with the entire product. The
demos can be freely used, but in order to use the actual
product, the key must be purchased. These scheme do not
Continuation of prior application Ser. No.: 09/778,006
hinder copying of the software once the key is initially
filed Feb. 7, 2001, now U.S. Pat. No. 6,714,921; which is a
Division of U.S. Ser. No.: 08/967,084 filed Nov. 10, 1997, 5 purchased.
now U.S. Pat. No. 6,236,971 and which is a Continuation of
A system for ensuring that licenses are in place for using
U.S. Ser. No.: 08/344,760 filed Nov. 23, 1994, now abanlicensed products is described in PCT Publication WO
doned.
93/01550 to Griswold entitled "License Management System and Method." The licensed product may be any elecFIELD OF THE INVENTION
10 tronically published work but is most effective for use with
works that are used for extended periods of time such as
The present invention relates to the field of distribution
software programs. Griswold requires that the licensed prodand usage rights enforcement for digitally encoded works.
uct contain software to invoke a license check monitor at
BACKGROUND OF THE INVENTION
predetermined time intervals. The license check monitor
A fundamental issue facing the publishing and informa- 15 generates request datagrams which identify the licensee. The
request datagrams are sent to a license control system over
tion industries as they consider electronic publishing is how
an appropriate communication facility. The license control
to prevent the unauthorized and unaccounted distribution or
system then checks the datagram to determine if the datausage of electronically published materials. Electronically
gram is from a valid licensee. The license control system
published materials are typically distributed in a digital form
and recreated on a computer based system having the 20 then sends a reply datagram to the license check monitor
indicating denial or approval of usage. The license control
capability to recreate the materials. Audio and video
system will deny usage in the event that request datagrams
recordings, software, books and multimedia works are all
go unanswered after a predetermined period of time (which
being electronically published. Companies in these indusmay indicate an unauthorized attempt to use the licensed
tries receive royalties for each accounted for delivery of the
materials, e.g. the sale of an audio CD at a retail outlet. Any 25 product). In this system, usage is managed at a central
location by the response datagrams. So for example if
unaccounted distribution of a work results in an unpaid
license fees have not been paid, access to the licensed
royalty (e.g. copying the audio recording CD to another
product is terminated.
digital medium.)
It is argued by Griswold that the described system is
The ease in which electronically published works can be 30
advantageous because it can be implemented entirely in
"perfectly" reproduced and distributed is a major concern.
software. However, the system described by Griswold has
The transmission of digital works over networks is comlimitations. An important limitation is that during the use of
monplace. One such widely used network is the Internet.
the licensed product, the user must always be coupled to an
The Internet is a widespread network facility by which
computer users in many universities, corporations and gov- 35 appropriate communication facility in order to send and
receive datagrams. This creates a dependency on the comernment entities communicate and trade ideas and informamunication facility. So if the communication facility is not
tion. Computer bulletin boards found on the Internet and
available, the licensed product cannot be used. Moreover,
commercial networks such as CompuServ and Prodigy
some party must absorb the cost of communicating with the
allow for the posting and retrieving of digital information.
Information services such as Dialog and LEXIS/NEXIS 40 license server.
A system for controlling the distribution of digitally
provide databases of current, information on a wide variety
encoded books is embodied in a system available from VPR
of topics. Another factor which will exacerbate the situation
Systems, LTD. of St. Louis, Mo. The VPR system is
is the development and expansion of the National Informaself-contained and is comprised of: (1) point of sale kiosks
tion Infrastructure (the Nil). It is anticipated that, as the Nil
grows, the transmission of digital works over networks will 45 for storing and downloading of books, (2) personal storage
mediums (cartridges) to which the books are downloaded,
increase many times over. It would be desirable to utilize the
and (3) readers for viewing the book. In a purchase
Nil for distribution of digital works without the fear of
transaction, a purchaser will purchase a voucher card repwidespread unauthorized copying.
resenting the desired book. The voucher will contain suffiThe most straightforward way to curb unaccounted distribution is to prevent unauthorized copying and transmis- 50 cient information to identify the book purchased and perhaps
some demographic information relating to the sales transsian. For existing materials that are distributed in digital
action. To download the book, the voucher and the cartridge
form, various safeguards are used. In the case of software,
are inserted into the kiosk.
copy protection schemes which limit the number of copies
The VPR system may also be used as a library. In such an
that can be made or which corrupt the output when copying
is detected have been employed. Another scheme causes 55 embodiment, the kiosk manages the number of "copies" that
may be checked out at one time. Further, the copy of the
software to become disabled after a predetermined period of
book is erased from the users cartridge after a certain
time has lapsed. A technique used for workstation based
check-out time has expired. However, individuals cannot
software is to require that a special hardware device must be
loan books because the cartridges may only be used with the
present on the workstation in order for the software to run,
e.g., see U.S. Pat. No. 4,932,054 entitled "Method and 60 owners reader.
Apparatus for Protecting Computer Software Utilizing
The foregoing distribution and protection schemes operCoded Filter Network in Conjunction with an Active Coded
ate in part by preventing subsequent distribution of the work.
Hardware Device." Such devices are provided with the
While this certainly prevents unauthorized distributions, it
software and are commonly referred to as dongles.
does so by sacrificing the potential for subsequent revenue
Yet another scheme is to distribute software, but which 65 bearing uses. For example, it may be desirable to allow the
requires a "key" to enable it's use. This is employed in
lending of a purchased work to permit exposure of the work
distribution schemes where "demos" of the software are
to potential buyers. Another example would be to permit the
CONTENT RENDERING REPOSITORY
Case 2:13-cv-01112 Document 1-3 Filed 12/18/13 Page 19 of 45 PageID #: 90
US 6,963,859 B2
3
4
creation of a derivative work for a fee. Yet another example
FIG. 2 is a block diagram illustrating the various reposiwould be to permit copying the work for a fee (essentially
tory types and the repository transaction flow between them
purchasing it). Thus, it would be desirable to provide flexin the currently preferred embodiment of the present invenibility in how the owner of a digital work may allow it to be
tion.
distributed.
5
FIG. 3 is a block diagram of a repository coupled with a
While flexibility in distribution is a concern, the owners
credit
server in the currently preferred embodiment of the
of a work want to make sure they are paid for such
present invention.
distributions. In U.S. Pat. No. 4,977,594 to Shear, entitled
"Database Usage Metering and Protection System and
FIGS. 4a and 4b are examples of rendering systems as
Method," a system for metering and billing for usage of 10 may be utilized in the currently preferred embodiment of the
information distributed on a CD-ROM is described. The
present invention.
system requires the addition of a billing module to the
FIG. 5 illustrates a contents file layout for a digital work
computer system. The billing module may operate in a
as may be utilized in the currently preferred embodiment of
number of different ways. First, it may periodically comthe present invention.
municate billing data to a central billing facility, whereupon
the user may be billed. Second, billing may occur by 15
FIG. 6 illustrates a contents file layout for an individual
disconnecting the billing module and the user sending it to
digital work of the digital work of FIG. 5 as may be utilized
a central billing facility where the data is read and a user bill
in the currently preferred embodiment of the present invengenerated.
tion.
U.S. Pat. No. 5,247,575, Sprague et al., entitled "Information Distribution System", describes an information dis- 20
FIG. 7 illustrates the components of a description block of
tribution system which provides and charges only for user
the currently preferred embodiment of the present invention.
selected information. A plurality of encrypted information
FIG. 8 illustrates a description tree for the contents file
packages (IPs) are provided at the user site, via high and/or
of the digital work illustrated in FIG. 5.
layout
low density storage media and/or by broadcast transmission.
Some of the IPs may be of no interest to the user. The IPs 25
FIG. 9 illustrates a portion of a description tree correof interest are selected by the user and are decrypted and
sponding to the individual digital work illustrated in FIG. 6.
stored locally. The IPs may be printed, displayed or even
FIG. 10 illustrates a layout for the rights portion of a
copied to other storage medias. The charges for the selected
description block as may be utilized in the currently preIP's are accumulated within a user apparatus and periodically reported by telephone to a central accounting facility. 30 ferred embodiment of the present invention.
The central accounting facility also issues keys to decrypt
FIG. 11 is a description tree wherein certain d-blocks have
the IPs. The keys are changed periodically. If the central
PRINT usage rights and is used to illustrate "strict" and
accounting facility has not issued a new key for a particular
"lenient" rules for resolving usage rights conflicts.
user station, the station is unable to retrieve information
from the system when the key is changed.
FIG. 12 is a block diagram of the hardware components
35
A system available from Wave Systems Corp. of
of a repository as are utilized in the currently preferred
Princeton, N.Y., provides for metering of software usage on
embodiment of the present invention.
a personal computer. The system is installed onto a computer
FIG. 13 is a block diagram of the functional (logical)
and collects information on what software is in use, encrypts
components
of a repository as are utilized in the currently
it and then transmits the information to a transaction center.
From the transaction center, a bill is generated and sent to 40 preferred embodiment of the present invention.
the user. The transaction center also maintains customer
FIG. 14 is diagram illustrating the basic components of a
accounts so that licensing fees may be forwarded directly to
usage right in the currently preferred embodiment of the
the software providers. Software operating under this system
present invention.
must be modified so that usage can be accounted.
FIG. 15 lists the usage rights grammar of the currently
Known techniques for billing do not provide for billing of 45
preferred embodiment of the present invention.
copies made of the work. For example, if data is copied from
the CD-ROM described in Shear, any subsequent use of the
FIG. 16 is a flowchart illustrating the steps of certificate
copy of the information cannot be metered or billed. In other
delivery,
hotlist checking and performance testing as perwords, the means for billing runs with the media rather than
the underlying work. It would be desirable to have a 50 formed in a registration transaction as may be performed in
the currently preferred embodiment of the present invention.
distribution system where the means for billing is always
transported with the work.
FIG. 17 is a flowchart illustrating the steps of session
information exchange and clock synchronization as may be
SUMMARY OF THE INVENTION
performed in the currently preferred embodiment of the
An aspect of the invention is a rendering system adapted
55 present invention, after each repository in the registration
for use in a system for managing use of content and
transaction has successfully completed the steps described in
operative to rendering content in accordance with usage
FIG. 16.
rights associated with the content. The system includes a
rendering device configured to render the content and a
FIG. 18 is a flowchart illustrating the basic flow for a
repository coupled to the rendering device and operative to
usage transaction, including the common opening and closenforce usage rights associated with the content and permit 60 ing step, as may be performed in the currently preferred
the rendering device to render the content in accordance
embodiment of the present invention.
with a manner of use specified by the usage rights.
FIG. 19 is a state diagram of server and client repositories
BRIEF DESCRIPTION OF THE DRAWINGS
in accordance with a transport protocol followed when
FIG. 1 is a flowchart illustrating a simple instantiation of 65 moving a digital work from the server to the client
the operation of the currently preferred embodiment of the
repositories, as may be performed in the currently preferred
present invention.
embodiment of the present invention.
Case 2:13-cv-01112 Document 1-3 Filed 12/18/13 Page 20 of 45 PageID #: 91
US 6,963,859 B2
5
DETAILED DESCRIPTION OF 1HE
PREFERRED EMBODIMENT
6
software) that may be required for recreating the work. The
term composite work refers to a digital work comprised of
a collection of other digital works. The term "usage rights"
"rights" is a term which refers to rights granted to a
or
TABLE OF CONTENTS
5 recipient of a digital work. Generally, these rights define
OVERVIEW
how a digital work can be used and if it can be further
RENDERING SYSTEMS
distributed. Each usage right may have one or more specified
ATTACHING USAGE RIGHTS TO A DIGITAL WORK
conditions which must be satisfied before the right may be
exercised. Appendix 1 provides a Glossary of the terms used
Resolving Conflicting Rights
10 herein.
REPOSITORIES
A key feature of the present invention is that usage rights
Repository Security Classes
are permanently "attached" to the digital work. Copies made
Repository User Interface
of a digital work will also have usage rights attached. Thus,
CREDIT SERVICES
the usage rights and any associated fees assigned by a
USAGE RIGHTS LANGUAGE
15 creator and subsequent distributor will always remain with
Copy Count Specification
a digital work.
Control Specification
The enforcement elements of the present invention are
embodied in repositories. Among other things, repositories
Time Specification
are used to store digital works, control access to digital
Security Class and Authorization Specification
20 works, bill for access to digital works and maintain the
Usage Fees and Incentives Specification
security and integrity of the system.
Examples of Sets of Usage Rights
The combination of attached usage rights and repositories
REPOSITORY TRANSACTIONS
enable distinct advantages over prior systems. As noted in
Message Transmission
the prior art, payment of fees are primarily for the initial
Session Initiation Transactions
25 access. In such approaches, once a work has been read,
Billing Transactions
computational control over that copy is gone.
Transmission Protocol
Metaphorically, "the content genie is out of the bottle and no
more fees can be billed." In contrast, the present invention
The Copy Transaction
never separates the fee descriptions from the work. Thus, the
The Transfer Transaction
30 digital work genie only moves from one trusted bottle
The Loan Transaction
(repository) to another, and all uses of copies are potentially
The Play Transaction
The Print Transaction
controlled and billable.
The Backup Transaction
FIG. 1 is a high level flowchart omitting various details
but which demonstrates the basic operation of the present
The Restore Transaction
The Delete Transaction
35 invention. Referring to FIG. 1, a creator creates a digital
The Directory Transaction
work, step 101. The creator will then determine appropriate
The Folder Transaction
usage rights and fees, attach them to the digital work, and
The Extract Transaction
store them in Repository 1, step 102. The determination of
The Embed Transaction
appropriate usage rights and fees will depend on various
The Edit Transaction
40 economic factors. The digital work remains securely in
The Authorization Transaction
Repository 1 until a request for access is received. The
request for access begins with a session initiation by another
The Install Transaction
repository. Here a Repository 2 initiates a session with
The Uninstall Transaction
DISTRIBUTION AND USE SCENARIOS
Repository 1, step 103. As will be described in greater detail
APPENDIX A GLOSSARY
45 below, this session initiation includes steps which helps to
Overview
insure that the respective repositories are trustworthy.
A system for controlling use and distribution of digital
Assuming that a session can be established, Repository 2
may then request access to the Digital Work for a stated
works is disclosed. The present invention is directed to
purpose, step 104. The purpose may be, for example, to print
supporting commercial transactions involving digital works.
The transition to digital works profoundly and fundamen- 50 the digital work or to obtain a copy of the digital work. The
purpose will correspond to a specific usage right. In any
tally changes how creativity and commerce can work. It
changes the cost of transporting or storing works because
event, Repository 1 checks the usage rights associated with
digital property is almost "massless." Digital property can
the digital work to determine if the access to the digital work
be transported at electronic speeds and requires almost no
may be granted, step 105. The check of the usage rights
warehousing. Keeping an unlimited supply of virtual copies 55 essentially involves a determination of whether a right
on hand requires essentially no more space than keeping one
associated with the access request has been attached to the
copy on hand. The digital medium also lowers the costs of
digital work and if all conditions associated with the right
alteration, reuse and billing.
are satisfied. If the access is denied, repository 1 terminates
There is a market for digital works because creators are
the session with an error message, step 106. If access is
strongly motivated to reuse portions of digital works from 60 granted, repository 1 transmits the digital work to repository
2, step 107. Once the digital work has been transmitted to
others rather than creating their own completely. This is
repository 2, repository 1 and 2 each generate billing inforbecause it is usually so much easier to use an existing stock
mation for the access which is transmitted to a credit server,
photo or music clip than to create a new one from scratch.
Herein the terms "digital work", "work" and "content"
step 108. Such double billing reporting is done to insure
refer to any work that has been reduced to a digital repre- 65 against attempts to circumvent the billing process.
sentation. This would include any audio, video, text, or
FIG. 2 illustrates the basic interactions between repository
types in the present invention. As will become apparent from
multimedia work and any accompanying interpreter (e.g.
Case 2:13-cv-01112 Document 1-3 Filed 12/18/13 Page 21 of 45 PageID #: 92
US 6,963,859 B2
7
8
FIG. 2, the various repository types will serve different
some instances contain an ephemeral copy of a digital work
functions. It is fundamental that repositories will share a
which remains until it is printed out by the print engine 403.
core set of functionality which will enable secure and trusted
In other instances, the printer repository 402 may contain
communications. Referring to FIG. 2, a repository 201
digital works such as fonts, which will remain and can be
represents the general instance of a repository. The reposi- 5 billed based on use. This design assures that all communitory 201 has two modes of operation; a server mode and a
cation lines between printers and printing devices are
encrypted, unless they are within a physically secure boundrequester mode. When in the server mode, the repository
ary. This design feature eliminates a potential "fault" point
will be receiving and processing access requests to digital
works. When in the requester mode, the repository will be
through which the digital work could be improperly
initiating requests to access digital works. Repository 201 is 10 obtained. The printer device 403 represents the printer
general in the sense that it's primary purpose is as an
components used to create the printed output.
exchange medium for digital works. During the course of
Also illustrated in FIG. 4a is the repository 404. The
operation, the repository 201 may communicate with a
repository 404 is coupled to the printer repository 402. The
plurality of other repositories, namely authorization reposirepository 404 represents an external repository which contory 202, rendering repository 203 and master repository 15 tains digital works.
FIG. 4b is an example of a computer system as a rendering
204. Communication between repositories occurs utilizing a
repository transaction protocol 205.
system. A computer system may constitute a "multiCommunication with an authorization repository 202 may
function" device since it may execute digital works (e.g.
occur when a digital work being accessed has a condition
software programs) and display digital works (e.g. a digirequiring an authorization. Conceptually, an authorization is 20 tized photograph). Logically, each rendering device can be
a digital certificate such that possession of the certificate is
viewed as having it's own repository, although only one
required to gain access to the digital work. An authorization
physical repository is needed. Referring to FIG. 4b, a
is itself a digital work that can be moved between reposicomputer system 410 has contained therein a display/
tories and subjected to fees and usage rights conditions. An
execution repository 411. The display/execution repository
authorization may be required by both repositories involved 25 411 is coupled to display device, 412 and execution device
in an access to a digital work.
413. The dashed box surrounding the computer system 410
Communication with a rendering repository 203 occurs in
represents a security boundary within which communicaconnection with the rendering of a digital work. As will be
tions are assumed to be secure. The display/execution
described in greater detail below, a rendering repository is
repository 411 is further coupled to a credit server 414 to
coupled with a rendering device (e.g. a printer device) to 30 report any fees to be billed for access to a digital work and
a repository 415 for accessing digital works stored therein.
comprise a rendering system.
Structure of Digital Works
Communication with a master repository 205 occurs in
connection with obtaining an identification certificate. IdenUsage rights are attached directly to digital works. Thus,
tification certificates are the means by which a repository is
it is important to understand the structure of a digital work.
identified as "trustworthy". The use of identification certifi- 35 The structure of a digital work, in particular composite
digital works, may be naturally organized into an acyclic
cates is described below with respect to the registration
structure such as a hierarchy. For example, a magazine has
transaction.
various articles and photographs which may have been
FIG. 3 illustrates the repository 201 coupled to a credit
server 301. The credit server 301 is a device which accucreated and are owned by different persons. Each of the
mulates billing information for the repository 201. The 40 articles and photographs may represent a node in a hierarcredit server 301 communicates with repository 201 via
chical structure. Consequently, controls, i.e. usage rights,
billing transactions 302 to record billing transactions. Billmay be placed on each node by the creator. By enabling
ing transactions are reported to a billing clearinghouse 303
control and fee billing to be associated with each node, a
by the credit server 301 on a periodic basis. The credit server
creator of a work can be assured that the rights and fees are
301 communicates to the billing clearinghouse 303 via 45 not circumvented.
clearinghouse transactions 304. The clearinghouse transacIn the currently preferred embodiment, the file information for a digital work is divided into two files: a "contents"
tions 304 enable a secure and encrypted transmission of
information to the billing clearinghouse 303.
file and a "description tree" file. From the perspective of a
repository, the "contents" file is a stream of addressable
Rendering Systems
A rendering system is generally defined as a system 50 bytes whose format depends completely on the interpreter
comprising a repository and a rendering device which can
used to play, display or print the digital work. The descriprender a digital work into its desired form. Examples of a
tion tree file makes it possible to examine the rights and fees
for a work without reference to the content of the digital
rendering system may be a computer system, a digital audio
system, or a printer. A rendering system has the same
work. It should be noted that the term description tree as
security features as a repository. The coupling of a rendering 55 used herein refers to any type of acyclic structure used to
repository with the rendering device may occur in a manner
represent the relationship between the various components
suitable for the type of rendering device.
of a digital work.
FIG. 4a illustrates a printer as an example of a rendering
FIG. 5 illustrates the layout of a contents file. Referring to
system. Referring to FIG. 4, printer system 401 has conFIG. 5, a digital work 509 is comprised of story A 510,
tained therein a printer repository 402 and a print device 60 advertisement 511, story B 512 and story C 513. It is
assumed that the digital work is stored starting at a relative
403. It should be noted that the the dashed line defining
address of 0. Each of the parts of the digital work are stored
printer system 401 defines a secure system boundary. Communications within the boundary is assumed to be secure.
linearly so that story A 510 is stored at approximately
addresses 0-30,000, advertisement 511 at addresses
Depending on the security level, the boundary also represents a barrier intended to provide physical integrity. The 65 30,001-40,000, story B 512 at addresses 40,001-60,000 and
printer repository 402 is an instantiation of the rendering
story C 513 at addresses 60,001-SSK. The detail of story A
repository 205 of FIG. 2. The printer repository 402 will in
510 is illustrated in FIG. 6. Referring to FIG. 6, the story A
Case 2:13-cv-01112 Document 1-3 Filed 12/18/13 Page 22 of 45 PageID #: 93
US 6,963,859 B2
9
10
510 is further broken down to show text 614 stored at
address 0-1500, soldier photo 615 at addresses 1501-10,
TABLE 1
000, graphics 616 stored at addresses 10,001-25,000 and
DIGITAL WORK STATE INFORMATION
sidebar 617 stored address 25,001-30,000. Note that the
data in the contents file may be compressed (for saving 5 Property
Value
Use
storage) or encrypted (for security).
Copies -inNumber
A counter of the number of copies of a
From FIGS. 5 and 6 it is readily observed that a digital
Use
work that are in use. Incremented when
work can be represented by its component parts as a hieranother copy is used; decremented when
archy. The description tree for a digital work is comprised of
use is completed.
Indicator of the maximum number of
a set of related descriptor blocks ( d-blocks). The contents of 10 Loan-Period Time-Units
time-units that a document can be
each d-block is described with respect to FIG. 7. Referring
loaned out
to FIG. 7, ad-block 700 includes an identifier 701 which is
Indicator that the current work is a
Loaner-Copy Boolean
a unique identifier for the work in the repository, a starting
loaned out copy of an authorized digital
work.
address 702 providing the start address of the first byte of the
Indicator of the remaining time of use
work, a length 703 giving the number of bytes in the work, 15 Remaining- Time-Units
Time
on a metered document right.
a rights portion 704 wherein the granted usage rights and
DocumentString
A string containing various identifying
their status data are maintained, a parent pointer 705 for
information about a document. The
Descr
exact format of this is not specified, but
pointing to a parent d-block and child pointers 706 for
it can include information such as a
pointing to the child d-blocks In the currently preferred
publisher name, author name, ISBN
embodiment, the identifier 701 has two parts. The first part 20
number, and so on.
is a unique number assigned to the repository upon manuRevenueRO-Descr
A handle identifying a revenue owner
for a digital work. This is used for
Owner
facture. The second part is a unique number assigned to the
reporting usage fees.
work upon creation. The rights portion 704 will contain a
Publication- Date-Descr
The date that the digital work was
data structure, such as a look-up table, wherein the various
Date
published.
information associated with a right is maintained. The 25 History-list History-Rec
A list of events recording the repostories
and dates for operations that copy,
information required by the respective usage rights is
transfer, backup, or restore a digital
described in more detail below. D-blocks form a strict
work.
hierarchy. The top d-block of a work has no parent; all other
d-blocks have one parent. The relationship of usage rights
between parent and child d-blocks and how conflicts are 30 viable alternatives but may introduce processing overhead,
resolved is described below.
e.g. the interpretation of the objects.
A special type of d-block is a "shell" d-block. A shell
Digital works are stored in a repository as part of a
d-block adds no new content beyond the content of its parts.
hierarchical file system. Folders (also termed directories and
A shell d-block is used to add rights and fee information,
sub-directories) contain the digital works as well as other
35 folders. Digital works and folders in a folder are ordered in
typically by distributors of digital works.
FIG. 8 illustrates a description tree for the digital work of
alphabetical order. The digital works are typed to reflect how
the files are used. Usage rights can be attached to folders so
FIG. 5. Referring to FIG. 8, a top d-block 820 for the digital
that the folder itself is treated as a digital work. Access to the
work points to the various stories and advertisements confolder would then be handled in the same fashion as any
tained therein. Here, the top d-block 820 points to d-block
821 (representing story A 510), d-block 822 (representing 40 other digital work As will be described in more detail below,
the advertisement 511), d-block 823 (representing story B
the contents of the folder are subject to their own rights.
512) and and d-block 824 (representing story C 513).
Moreover, file management rights may be attached to the
folder which define how folder contents can be managed.
The portion of the description tree for Story A 510 is
illustrated in FIG. 9. D-block 925 represents text 614,
Attaching Usage Rights to a Digital Work
d-block 926 represents photo 615, d-block 927 represents 45
It is fundamental to the present invention that the usage
graphics 616 by and d-block 928 represents sidebar 617.
rights are treated as part of the digital work. As the digital
The rights portion 704 of a descriptor block is further
work is distributed, the scope of the granted usage rights will
illustrated in FIG. 10. FIG. 10 illustrates a structure which
remain the same or may be narrowed. For example, when a
is repeated in the rights portion 704 for each right. Referring
digital work is transferred from a document server to a
to FIG. 10, each right will have a right code field 1001 and 50 repository, the usage rights may include the right to loan a
status information field 1002. The right code field 1001 will
copy for a predetermined period of time (called the original
contain a unique code assigned to a right. The status
rights). When the repository loans out a copy of the digital
information field 1002 will contain information relating to
work, the usage rights in the loaner copy (called the next set
the state of a right and the digital work. Such information is
of rights) could be set to prohibit any further rights to loan
indicated below in Table 1. The rights as stored in the rights 55 out the copy. The basic idea is that one cannot grant more
portion 304 may typically be in numerical order based on the
rights than they have.
The attachment of usage rights into a digital work may
right code.
The approach for representing digital works by separating
occur in a variety of ways. If the usage rights will be the
description data from content assumes that parts of a file are
same for an entire digital work, they could be attached when
contiguous but takes no position on the actual representation 60 the digital work is processed for deposit in the digital work
of content. In particular, it is neutral to the question of
server. In the case of a digital work having different usage
whether content representation may take an object oriented
rights for the various components, this can be done as the
approach. It would be natural to represent content as objects.
digital work is being created. An authoring tool or digital
In principle, it may be convenient to have content objects
work assembling tool could be utilized which provides for
that include the billing structure and rights information that 65 an automated process of attaching the usage rights.
is represented in the d-blocks. Such variations in the design
As will be described below, when a digital work is copied,
transferred or loaned, a "next set of rights" can be specified.
of the representation are possible and are
Case 2:13-cv-01112 Document 1-3 Filed 12/18/13 Page 23 of 45 PageID #: 94
US 6,963,859 B2
11
12
The "next set of rights" will be attached to the digital work
as it is transported.
Resolving Conflicting Rights
Because each part of a digital work may have its own
usage rights, there will be instances where the rights of a
"contained part" are different from its parent or container
part. As a result, conflict rules must be established to dictate
when and how a right may be exercised. The hierarchical
structure of a digital work facilitates the enforcement of such
rules. A "strict" rule would be as follows: a right for a part
in a digital work is sanctioned if and only if it is sanctioned
for the part, for ancestor d-blocks containing the part and for
all descendent d-blocks. By sanctioned, it is meant that (1)
each of the respective parts must have the right, and (2) any
conditions for exercising the right are satisfied.
It also possible to implement the present invention using
a more lenient rule. In the more lenient rule, access to the
part may be enabled to the descendent parts which have the
right, but access is denied to the descendents which do not.
Example of applying both the strict rule and lenient is
illustrated with reference to FIG. 11. Referring to FIG. 11, a
root d-block 1101 has child d-blocks 1102-1105. In this
case, root d-block represents a magazine, and each of the
child d-blocks 1102-1105 represent articles in the magazine.
Suppose that a request is made to PRINT the digital work
represented by root d-block 1101 wherein the strict rule is
followed. The rights for the root d-block 1101 and child
d-blocks 1102-1105 are then examined. Root d-block 1101
and child d-blocks 1102 and 1105 have been granted PRINT
rights. Child d-block 1103 has not been granted PRINT
rights and child d-block 1104 has PRINT rights conditioned
on payment of a usage fee.
Under the strict rule the PRINT right cannot be exercised
because the child d-block does not have the PRINT right.
Under the lenient rule, the result would be different. The
digital works represented by child d-blocks 1102 and 1105
could be printed and the digital work represented by d-block
1104 could be printed so long as the usage fee is paid. Only
the digital work represented by d-block 1103 could not be
printed. This same result would be accomplished under the
strict rule if the requests were directed to each of the
individual digital works.
The present invention supports various combinations of
allowing and disallowing access. Moreover, as will be
described below, the usage rights grammar permits the
owner of a digital work to specify if constraints may be
imposed on the work by a container part. The manner in
which digital works may be sanctioned because of usage
rights conflicts would be implementation specific and would
depend on the nature of the digital works.
Repositories
Many of the powerful functions of repositories-such as
their ability to "loan" digital works or automatically handle
the commercial reuse of digital works-are possible because
they are trusted systems. The systems are trusted because
they are able to take responsibility for fairly and reliably
carrying out the commercial transactions. That the systems
can be responsible ("able to respond") is fundamentally an
issue of integrity. The integrity of repositories has three
parts: physical integrity, communications integrity, and
behavioral integrity.
Physical integrity refers to the integrity of the physical
devices themselves. Physical integrity applies both to the
repositories and to the protected digital works. Thus, the
higher security classes of repositories themselves may have
sensors that detect when tampering is attempted on their
secure cases. In addition to protection of the repository
itself, the repository design protects access to the content of
digital works. In contrast with the design of conventional
magnetic and optical devices-such as floppy disks,
CD-ROMs, and videotapes-repositories never allow nontrusted systems to access the works directly. A maker of
generic computer systems cannot guarantee that their platform will not be used to make unauthorized copies. The
manufacturer provides generic capabilities for reading and
writing information, and the general nature of the functionality of the general computing device depends on it. Thus, a
copy program can copy arbitrary data. This copying issue is
not limited to general purpose computers. It also arises for
the unauthorized duplication of entertainment "software"
such as video and audio recordings by magnetic recorders.
Again, the functionality of the recorders depends on their
ability to copy and they have no means to check whether a
copy is authorized. In contrast, repositories prevent access to
the raw data by general devices and can test explicit rights
and conditions before copying or otherwise granting access.
Information is only accessed by protocol between trusted
repositories.
Communications integrity refers to the integrity of the
communications channels between repositories. Roughly
speaking, communications integrity means that repositories
cannot be easily fooled by "telling them lies." Integrity in
this case refers to the property that repositories will only
communicate with other devices that are able to present
proof that they are certified repositories, and furthermore,
that the repositories monitor the communications to detect
"impostors" and malicious or accidental interference. Thus
the security measures involving encryption, exchange of
digital certificates, and nonces described below are all
security measures aimed at reliable communication in a
world known to contain active adversaries.
Behavioral integrity refers to the integrity in what repositories do. What repositories do is determined by the software
that they execute. The integrity of the software is generally
assured only by knowledge of its source. Restated, a user
will trust software purchased at a reputable computer store
but not trust software obtained off a random (insecure)
server on a network. Behavioral integrity is maintained by
requiring that repository software be certified and be distributed with proof of such certification, i.e. a digital certificate. The purpose of the certificate is to authenticate that
the software has been tested by an authorized organization,
which attests that the software does what it is supposed to do
and that it does not compromise the behavioral integrity of
a repository. If the digital certificate cannot be found in the
digital work or the master repository which generated the
certificate is not known to the repository receiving the
software, then the software cannot be installed.
In the description of FIG. 2, it was indicated that repositories come in various forms. All repositories provide a core
set of services for the transmission of digital works. The
manner in which digital works are exchanged is the basis for
all transaction between repositories. The various repository
types differ in the ultimate functions that they perform.
Repositories may be devices themselves, or they may be
incorporated into other systems. An example is the rendering
repository 205 of FIG. 2.
A repository will have associated with it a repository
identifier. Typically, the repository identifier would be a
unique number assigned to the repository at the time of
manufacture. Each repository will also be classified as being
in a particular security class. Certain communications and
transactions may be conditioned on a repository being in a
particular security class. The various security classes are
described in greater detail below.
s
10
15
20
25
30
35
40
45
so
ss
60
65
Case 2:13-cv-01112 Document 1-3 Filed 12/18/13 Page 24 of 45 PageID #: 95
US 6,963,859 B2
13
14
As a prerequisite to operation, a repository will require
possession of an identification certificate. Identification certificates are encrypted to prevent forgery and are issued by
a Master repository. A master repository plays the role of an
authorization agent to enable repositories to receive digital
works. Identification certificates must be updated on a
periodic basis. Identification certificates are described in
greater detail below with respect to the registration transaction.
A repository has both a hardware and functional embodiment. The functional embodiment is typically software
executing on the hardware embodiment. Alternatively, the
functional embodiment may be embedded in the hardware
embodiment such as an Application Specific Integrated
Circuit (ASIC) chip.
The hardware embodiment of a repository will be
enclosed in a secure housing which if compromised, may
cause the repository to be disabled. The basic components of
the hardware embodiment of a repository are described with
reference to FIG. 12. Referring to FIG. 12, a repository is
comprised of a processing means 1200, storage system
1207, clock 1205 and external interface 1206. The processing means 1200 is comprised of a processor element 1201
and processor memory 1202. The processing means 1201,
provides controller, repository transaction, and usage rights
transaction functions for the repository. Various functions in
the operation of the repository such as decryption and/or
decompression of digital works and transaction messages
are also performed by the processing means 1200. The
processor element 1201 may be a microprocessor or other
suitable computing component. The processor memory 1202
would typically be further comprised of Read Only Memories (ROM) and Random Access Memories (RAM). Such
memories would contain the software instructions utilized
by the processor element 1201 in performing the functions
of the repository.
The storage system 1207 is further comprised of descriptor storage 1203 and content storage 1204. The description
tree storage 1203 will store the description tree for the digital
work and the content storage will store the associated
content. The description tree storage 1203 and content
storage 1204 need not be of the same type of storage
medium, nor are they necessarily on the same physical
device. So for example, the descriptor storage 1203 may be
stored on a solid state storage (for rapid retrieval of the
description tree information), while the content storage 1204
may be on a high capacity storage such as an optical disk.
The clock 1205 is used to time-stamp various time based
conditions for usage rights or for metering usage fees which
may be associated with the digital works. The clock 1205
will have an uninterruptable power supply, e.g. a battery, in
order to maintain the integrity of the time-stamps. The
external interface means 1206 provides for the signal connection to other repositories and to a credit server. The
external interface means 1206 provides for the exchange of
signals via such standard interfaces such as RS-232 or
Personal Computer Manufacturers Card Industry Association (PCMCIA) standards, or FDDI. The external interface
means 1206 may also provide network connectivity.
The functional embodiment of a repository is described
with reference to FIG. 13. Referring to FIG. 13, the functional embodiment is comprised of an operating system
1301, core repository services 1302, usage transaction handlers 1303, repository specific functions, 1304 and a user
interface 1305. The operating system 1301 is specific to the
repository and would typically depend on the type of processor being used. The operating system 1301 would also
provide the basic services for controlling and interfacing
between the basic components of the repository.
The core repository services 1302 comprise a set of
functions required by each and every repository. The core
repository services 1302 include the session initiation transactions which are defined in greater detail below. This set of
services also includes a generic ticket agent which is used to
"punch" a digital ticket and a generic authorization server
for processing authorization specifications. Digital tickets
and authorizations are specific mechanisms for controlling
the distribution and use of digital works and are described
and more detail below. Note that coupled to the core
repository services are a plurality of identification certificates 1306. The identification certificates 1306 are required
to enable the use of the repository.
The usage transactions handler 1303 comprise functionality for processing access requests to digital works and for
billing fees based on access. The usage transactions supported will be different for each repository type. For
example, it may not be necessary for some repositories to
handle access requests for digital works.
The repository specific functionality 1304 comprises
functionality that is unique to a repository. For example, the
master repository has special functionality for issuing digital
certificates and maintaining encryption keys. The repository
specific functionality 1304 would include the user interface
implementation for the repository.
Repository Security Classes
For some digital works the losses caused by any individual instance of unauthorized copying is insignificant and
the chief economic concern lies in assuring the convenience
of access and low-overhead billing. In such cases, simple
and inexpensive handheld repositories and network-based
workstations may be suitable repositories, even though the
measures and guarantees of security are modest.
At the other extreme, some digital works such as a digital
copy of a first run movie or a bearer bond or stock certificate
would be of very high value so that it is prudent to employ
caution and fairly elaborate security measures to ensure that
they are not copied or forged. A repository suitable for
holding such a digital work could have elaborate measures
for ensuring physical integrity and for verifying authorization before use.
By arranging a universal protocol, all kinds of repositories
can communicate with each other in principle. However,
creators of some works will want to specify that their works
will only be transferred to repositories whose level of
security is high enough. For this reason, document repositories have a ranking system for classes and levels of
security. The security classes in the currently preferred
embodiment are described in Table 2.
5
10
15
20
25
30
35
40
45
50
TABLE 2
55
REPOSITORY SECURITY LEVELS
Level Description of Security
0
60
65
Open system. Document transmission is unencrypted. No digital
certificate is required for identification. The security of the system
depends mostly on user honesty, since only modest knowledge may
be needed to circumvent the security measures. The repository
has no provisions for preventing unauthorized programs from
running and accessing or copying files. The system does not
prevent the use of removable storage and does not encrypt stored
files.
Minimal security. Like the previous class except that stored files
are minimally encrypted, including ones on removable storage.
Case 2:13-cv-01112 Document 1-3 Filed 12/18/13 Page 25 of 45 PageID #: 96
US 6,963,859 B2
15
16
lar user interface will depend on the functionality that a
repository will provide.
TABLE 2-continued
Credit Servers
REPOSITORY SECURITY LEVELS
In the present invention, fees may be associated with the
5 exercise of a right. The requirement for payment of fees is
Level Description of Security
described with each version of a usage right in the usage
2 Basic security. Like the previous class except that special tools
rights language. The recording and reporting of such fees is
and knowledge are required to compromise the programming, the
performed
by the credit server. One of the capabilities
contents of the repository, or the state of the clock. All digital
enabled by associating fees with rights is the possibility of
communications are encrypted. A digital certificate is provided as
identification. Medium level encryption is used. Repository
10 supporting a wide range of charging models. The simplest
identification number is unforgeable.
model, used by conventional software, is that there is a
3 General security. Like the previous class plus the requirement of
single
fee at the time of purchase, after which the purchaser
special tools are needed to compromise the physical integrity of the
obtains unlimited rights to use the work as often and for as
repository and that modest encryption is used on all transmissions.
Password protection is required to use the local user interface. The
long as he or she wants. Alternative models, include metered
digital clock system cannot be reset without authorization. No
15 use and variable fees. A single work can have different fees
works would be stored on removable storage. When executing
for different uses. For example, viewing a photograph on a
works as programs, it runs them in their own address space and
display could have different fees than making a hardcopy or
does not give them direct access to any file storage or other
memory containing system code or works. They can access works
including it in a newly created work. A key to these
only through the transmission transaction protocol.
alternative charging models is to have a low overhead means
4 Like the previous class except that high level encryption is used on
20 of establishing fees and accounting for credit on these
all communications. Sensors are used to record attempts at
transactions.
physical and electronic tampering. After such tampering, the
repository will not perform other transactions until it has reported
A credit server is a computational system that reliably
such tampering to a designated server.
authorizes and records these transactions so that fees are
5 Like the previous class except that if the physical or digital
billed and paid. The credit server reports fees to a billing
attempts at tampering exceed some preset thresholds that
25 clearinghouse. The billing clearinghouse manages the finanthreaten the physical integrity of the repository or the integrity of
digital and cryptographic barriers, then the repository will save
cial transactions as they occur. As a result, bills may be
only document description records of history but will erase or
generated and accounts reconciled. Preferably, the credit
destroy any digital identifiers that could be misused if released to
server would store the fee transactions and periodically
an unscrupulous party. It also modifies any certificates of
communicate via a network with billing clearinghouse for
authenticity to indicate that the physical system has been
compromised. It also erases the contents of designated documents.
30 reconciliation. In such an embodiment, communications
Like the previous class except that the repository will attempt
with the billing clearinghouse would be encrypted for integwireless communication to report tampering and will employ noisy
rity and security reasons. In another embodiment, the credit
alarms.
server acts as a "debit card" where transactions occur in
10 This would correspond to a very high level of security. This server
would maintain constant communications to remote security
"real-time" against a user account.
systems reporting transactions, sensor readings, and attempts to
35
A credit server is comprised of memory, a processing
circumvent security.
means, a clock, and interface means for coupling to a
repository and a financial institution (e.g. a modem). The
credit server will also need to have security and authentiThe characterization of security levels described in Table
cation functionality. These elements are essentially the same
2 is not intended to be fixed. More important is the idea of
having different security levels for different repositories. It is 40 elements as those of a repository. Thus, a single device can
anticipated that new security classes and requirements will
be both a repository and a credit server, provided that it has
evolve according to social situations and changes in techthe appropriate processing elements for carrying out the
nology.
corresponding functions and protocols. Typically, however,
Repository User Interface
a credit server would be a card-sized system in the possesA user interface is broadly defined as the mechanism by 45 sian of the owner of the credit. The credit server is coupled
which a user interacts with a repository in order to invoke
to a repository and would interact via financial transactions
transactions to gain access to a digital work, or exercise
as described below. Interactions with a financial institution
usage rights. As described above, a repository may be
may occur via protocols established by the financial instiembodied in various forms. The user interface for a repositutions themselves.
In the currently preferred embodiment credit servers
tory will differ depending on the particular embodiment. The 50
associated with both the server and the repository report the
user interface may be a graphical user interface having icons
financial transaction to the billing clearinghouse. For
representing the digital works and the various transactions
example, when a digital work is copied by one repository to
that may be performed. The user interface may be a generated dialog in which a user is prompted for information.
another for a fee, credit servers coupled to each of the
The user interface itself need not be part of the repository. 55 repositories will report the transaction to the billing clearinghouse. This is desirable in that it insures that a transaction
As a repository may be embedded in some other device, the
will be accounted for in the event of some break in the
user interface may merely be a part of the device in which
the repository is embedded. For example, the repository
communication between a credit server and the billing
could be embedded in a "card" that is inserted into an
clearinghouse. However, some implementations may
available slot in a computer system. The user interface may 60 embody only a single credit server reporting the transaction
to minimize transaction processing at the risk of losing some
be combination of a display, keyboard, cursor control device
transactions.
and software executing on the computer system.
Usage Rights Language
At a minimum, the user interface must permit a user to
The present invention uses statements m a high level
input information such as access requests and alpha numeric
data and provide feedback as to transaction status. The user 65 "usage rights language" to define rights associated with
digital works and their parts. Usage rights statements are
interface will then cause the repository to initiate the suitable
interpreted by repositories and are used to determine what
transactions to service the request. Other facets of a particu-
Case 2:13-cv-01112 Document 1-3 Filed 12/18/13 Page 26 of 45 PageID #: 97
US 6,963,859 B2
17
18
transactions can be successfully carried out for a digital
(or YYYY/MMM/DD). Note that these time and date representations may specify moments in time or units of time
work and also to determine parameters for those transacMoney units are specified in terms of dollars.
tions. For example, sentences in the language determine
Finally, in the usage rights language, various "things" will
whether a given digital work can be copied, when and how
it can be used, and what fees (if any) are to be charged for 5 need to interact with each other. For example, an instance of
a usage right may specify a bank account, a digital ticket,
that use. Once the usage rights statements are generated,
etc. Such things need to be identified and are specified herein
they are encoded in a suitable form for accessing during the
using the suffix "-ID."
processing of transactions.
The Usage Rights Grammar is listed in it's entirety in
Defining usage rights in terms of a language in combination with the hierarchical representation of a digital work 10 FIG. 15 and is described below.
Grammar element 1501 "Digital Work Rights:=
enables the support of a wide variety of distribution and fee
(Rights*)" define the digital work rights as a set of rights.
schemes. An example is the ability to attach multiple verThe set of rights attached to a digital work define how that
sions of a right to a work. So a creator may attach a PRINT
digital work may be transferred, used, performed or played.
right to make 5 copies for $10.00 and a PRINT right to make
unlimited copies for $100.00. A purchaser may then choose 15 A set of rights will attach to the entire digital work and in the
case of compound digital works, each of the components of
which option best fits his needs. Another example is that
the digital work. The usage rights of components of a digital
rights and fees are additive. So in the case of a composite
may be different.
work, the rights and fees of each of the components works
Grammar element 1502 "Right:=(Right-Code{ Copyis used in determining the rights and fees for the work as a
whole. Other features and benefits of the usage rights 20 Count} {Control-Spec} {Time-Spec} {Access-Spec} {FeeSpec})" enumerates the content of a right. Each usage right
language will become apparent in the description of distrimust specify a right code. Each right may also optionally
bution and use scenarios provided below.
specify conditions which must be satisfied before the right
The basic contents of a right are illustrated in FIG. 14.
can be exercised. These conditions are copy count, control,
Referring to FIG. 14, a right 1450 has a transactional
component 1451 and a specifications component 1452. A 25 time, access and fee conditions. In the currently preferred
embodiment, for the optional elements, the following
right 1450 has a label (e.g. COPY or PRINT) which indicate
defaults apply: copy count equals 1, no time limit on the use
the use or distribution privileges that are embodied by the
of the right, no access tests or a security level required to use
right. The transactional component 1451 corresponds to a
the right and no fee is required. These conditions will each
particular way in which a digital work may be used or
distributed. The transactional component 1451 is typically 30 be described in greater detail below.
It is important to note that a digital work may have
embodied in software instructions in a repository which
multiple versions of a right, each having the same right code.
implement the use or distribution privileges for the right.
The multiple version would provide alternative conditions
The specifications components 1452 are used to specify
and fees for accessing the digital work.
conditions which must be satisfied prior to the right being
Grammar element 1503 "Right-Code: =Renderexercised or to designate various transaction related param- 35
CodeiTransport-CodeiFile-Management-CodeiDerivativeeters. In the currently preferred embodiment, these specifiWorks-Code Configuration-Code" distinguishes each of the
cations include copy count 1453, Fees and Incentives 1454,
specific rights into a particular right type (although each
Time 1455, Access and Security 1456 and Control 1457.
right is identified by distinct right codes). In this way, the
Each of these specifications will be described in greater
detail below with respect to the language grammar elements. 40 grammar provides a catalog of possible rights that can be
associated with parts of digital works. In the following,
The usage rights language is based on the grammar
rights are divided into categories for convenience in describdescribed below. A grammar is a convenient means for
ing them.
defining valid sequence of symbols for a language. In
Grammar element 1504 "Render-Code:=[Play:{Player:
describing the grammar the notation "[albic]" is used to
indicate distinct choices among alternatives. In this example, 45 Player-ID }IPrint:{Printer:Printer-ID} ]" lists a category of
rights all involving the making of ephemeral, transitory, or
a sentence can have either an "a", "b" or "c". It must include
non-digital copies of the digital work. After use the copies
exactly one of them. The braces { } are used to indicate
are erased.
optional items. Note that brackets, bars and braces are used
Play A process of rendering or performing a digital work
to describe the language of usage rights sentences but do not
on some processor. This includes such things as playing
appear in actual sentences in the language.
50
digital movies, playing digital music, playing a video
In contrast, parentheses are part of the usage rights
game, running a computer program, or displaying a
language. Parentheses are used to group items together in
document on a display.
lists. The notation (x*) is used to indicate a variable length
list, that is, a list containing one or more items of type x. The
Print To render the work in a medium that is not further
notation (x)* is used to indicate a variable number of lists 55
protected by usage rights, such as printing on paper.
containing x.
Grammar element 1505 "Transport-Code:=
Keywords in the grammar are words followed by colons.
[(CopyiTransferiLoan{Remaining-Rights: Next-Set-ofRights}]{ (Next-Copy-Rights:Next-Set of Rights)}" lists a
Keywords are a common and very special case in the
category of rights involving the making of persistent, usable
language. They are often used to indicate a single value,
typically an identifier. In many cases, the keyword and the 60 copies of the digital work on other repositories. The optional
parameter are entirely optional. When a keyword is given, it
Next-Copy-Rights determine the rights on the work after it
often takes a single identifier as its value. In some cases, the
is transported. If this is not specified, then the rights on the
transported copy are the same as on the original. The
keyword takes a list of identifiers.
optional Remaining-Rights specify the rights that remain
In the usage rights language, time is specified in an
hours:minutes:seconds (or hh:mm:ss) representation. Time 65 with a digital work when it is loaned out. If this is not
zone indicators, e.g. PDT for Pacific Daylight Time, may
specified, then the default is that no rights can be exercised
also be specified. Dates are represented as year/month/day
when it is loaned out.
Case 2:13-cv-01112 Document 1-3 Filed 12/18/13 Page 27 of 45 PageID #: 98
US 6,963,859 B2
19
20
Copy Make a new copy of a work
If Remaining-Rights is not specified, then there are no
rights for the original after all Loan copies are loaned out. If
Transfer Moving a work from one repository to another.
Remaining-Rights is specified, then the Keep: token can be
Loan Temporarily loaning a copy to another repository for
to simplify the expression of what rights to keep
used
a specified period of time.
Grammar element 1506 "File-Management-Code:= 5 behind. A list of right codes following keep means that all of
the versions of those listed rights are kept in the remaining
Backup{Back-Up-Copy-Rights:Next-Set of
copy. This specification can be overridden by subsequent
Rights} IRestoreiDeleteiFolderiDirectory {N arne :HideDelete: or Replace: specifications.
LocaliHide-Remote }{Parts:Hide-LocaliHide-Remote }"lists
Copy Count Specification
a category of rights involving operations for file
For various transactions, it may be desirable to provide
10
management, such as the making of backup copies to protect
some limit as to the number of "copies" of the work which
the copy owner against catastrophic equipment failure.
may be exercised simultaneously for the right. For example,
Many software licenses and also copyright law give a
it may be desirable to limit the number of copies of a digital
copy owner the right to make backup copies to protect
work that may be loaned out at a time or viewed at a time.
against catastrophic failure of equipment. However, the
Grammar element 1510 "Copy-Count:=(Copies:positivemaking of uncontrolled backup copies is inherently at odds 15
integeriOunlimited)"
provides a condition which defines the
with the ability to control usage, since an uncontrolled
number of "copies" of a work subject to the right. A copy
backup copy can be kept and then restored even after the
count can be 0, a fixed number, or unlimited. The copy-count
authorized copy was sold.
is associated with each right, as opposed to there being just
The File management rights enable the making and restoring of backup copies in a way that respects usage rights, 20 a single copy-count for the digital work. The Copy-Count
for a right is decremented each time that a right is exercised.
honoring the requirements of both the copy owner and the
When
the Copy-Count equals zero, the right can no longer
rights grantor and revenue owner. Backup copies of work
be exercised. If the Copy-Count is not specified, the default
descriptions (including usage rights and fee data) can be sent
1s one.
under appropriate protocol and usage rights control to other
document repositories of sufficiently high security. Further 25 Control Specification
Rights and fees depend in general on rights granted by the
rights permit organization of digital works into folders
creator as well as further restrictions imposed by later
which themselves are treated as digital works and whose
distributors. Control specifications deal with interactions
contents may be "hidden" from a party seeking to determine
between the creators and their distributors governing the
the contents of a repository.
30 imposition of further restrictions and fees. For example, a
Backup To make a backup copy of a digital work as
distributor of a digital work may not want an end consumer
protection against media failure.
of a digital work to add fees or otherwise profit by comRestore To restore a backup copy of a digital work.
mercially exploiting the purchased digital work.
Delete To delete or erase a copy of a digital work.
Grammar element 1511 "Control-Spec:=
Folder To create and name folders, and to move files and 35 (Control: {RestrictableiU nrestrictable} {U nchargeablel
Chargeable})" provides a condition to specify the effect of
folders between folders.
usage
rights and fees of parents on the exercise of the right.
Directory To hide a folder or it's contents.
A digital work is restrictable if higher level d-blocks can
Grammar element 1507 "Derivative-Works-Code:
impose further restrictions (time specifications and access
[ExtractiEmbediEdit {Process:Process-ID} ]{Next-CopyRights:Next-Set-ofRights }"lists a category of rights involv- 40 specifications) on the right. It is unrestrictable if no further
restrictions can be imposed. The default setting is restricting the use of a digital work to create new works.
able. A right is unchargeable if no more fees can be imposed
Extract To remove a portion of a work, for the purposes
on
the use of the right. It is chargeable if more fees can be
of creating a new work.
imposed. The default is chargeable.
Embed To include a work in an existing work.
45 Time Specification
Edit To alter a digital work by copying, selecting and
It is often desirable to assign a start date or specify some
modifying portions of an existing digital work.
duration as to when a right may be exercised. Grammar
Grammar element 1508 "Configuration-Code:=
element 1512 "Time-Spec:=( {Fixed-IntervaliSlidingInstalliUninstall" lists a category of rights for installing and
IntervaliMeter-Time} Until:Expiration-Date )" provides for
uninstalling software on a repository (typically a rendering 50 specification of time conditions on the exercise of a right.
repository.) This would typically occur for the installation of
Rights may be granted for a specified time. Different kinds
a new type of player within the rendering repository.
of time specifications are appropriate for different kinds of
Install: To install new software on a repository.
rights. Some rights may be exercised during a fixed and
predetermined duration. Some rights may be exercised for
Uninstall: To remove existing software from a repository.
Grammar element 1509 "Next-Set-of-Rights:={ (Add:Set- 55 an interval that starts the first time that the right is invoked
Of-Rights)} {(Delete:Set-Of-Rights)} {(Replace: Set-Ofby some transaction. Some rights may be exercised or are
Rights)}{(Keep:Set-Of-Rights)}" defines how rights are
charged according to some kind of metered time, which may
carried forward for a copy of a digital work. If the Nextbe split into separate intervals. For example, a right to view
Copy-Rights is not specified, the rights for the next copy are
a picture for an hour might be split into six ten minute
the same as those of the current copy. Otherwise, the set of 60 viewings or four fifteen minute viewings or twenty three
rights for the next copy can be specified. Versions of rights
minute viewings.
The terms "time" and "date" are used synonymously to
after Add: are added to the current set of rights. Rights after
Delete: are deleted from the current set of rights. If only right
refer to a moment in time. There are several kinds of time
codes are listed after Delete:, then all versions of rights with
specifications. Each specification represents some limitation
those codes are deleted. Versions of rights after Replace: 65 on the times over which the usage right applies. The
subsume all versions of rights of the same type in the current
Expiration-Date specifies the moment at which the usage
set of rights.
right ends. For example, if the Expiration-Date is "Jan. 1,
Case 2:13-cv-01112 Document 1-3 Filed 12/18/13 Page 28 of 45 PageID #: 99
US 6,963,859 B2
21
22
1995," then the right ends at the first moment of 1995. If the
In some cases, an authorization may be required from a
source other than the document server and repository. An
Expiration-Date is specified as *forever*, then the rights are
authorization object referenced by an Authorization-ID can
interpreted as continuing without end. If only an expiration
contain digital address information to be used to set up a
date is given, then the right can be exercised as often as
5 communications link between a repository and the authoridesired until the expiration date.
zation source. These are analogous to phone numbers. For
Grammar element 1513 "Fixed-Interval:=From:Startsuch access tests, the communication would need to be
Time" is used to define a predetermined interval that runs
established and authorization obtained before the right could
from the start time to the expiration date.
be exercised.
Grammar element 1514 "Sliding-Interval:=Interval:UseFor one-time usage rights, a variant on this scheme is to
Duration" is used to define an indeterminate (or "open") 10
have a digital ticket. A ticket is presented to a digital ticket
start time. It sets limits on a continuous period of time over
agent, whose type is specified on the ticket. In the simplest
which the contents are accessible. The period starts on the
case, a certified generic ticket agent, available on all
first access and ends after the duration has passed or the
repositories, is available to "punch" the ticket. In other
expiration date is reached, whichever comes first. For
cases, the ticket may contain addressing information for
example, if the right gives 10 hours of continuous access, the 15 locating a "special-" ticket agent. Once a ticket has been
use-duration would begin when the first access was made
punched, it cannot be used again for the same kind of
and end 10 hours later.
transaction (unless it is unpunched or refreshed in the
Grammar element 1515 "Meter-Time: Timemanner described below.) Punching includes marking the
Remaining:Remaining-Use" is used to define a "meter
ticket with a timestamp of the date and time it was used.
time," that is, a measure of the time that the right is actually 20 Tickets are digital works and can be copied or transferred
between repositories according to their usage rights.
exercised. It differs from the Sliding-Interval specification in
In the currently preferred embodiment, a "punched" ticket
that the time that the digital work is in use need not be
becomes "unpunched" or "refreshed" when it is copied or
continuous. For example, if the rights guarantee three days
extracted. The Copy and Extract operations save the date
of access, those days could be spread out over a month. With
this specification, the rights can be exercised until the meter 25 and time as a proper of the digital ticket. When a ticket agent
is given a ticket, it can simply check whether the digital copy
time is exhausted or the expiration date is reached, whichwas made after the last time that it was punched. Of course,
ever comes first.
the digital ticket must have the copy or extract usage rights
Remaining-Use:= Time-Unit
attached thereto.
Start-Time:= Time-Unit
The capability to unpunch a ticket is important in the
30
Use-Duration:= Time-Unit
following cases:
All of the time specifications include time-unit specifications
A digital work is circulated at low cost with a limitation
in their ultimate instantiation.
that it can be used only once.
Security Class and Authorization Specification
A digital work is circulated with a ticket that can be used
The present invention provides for various security
once to give discounts on purchases of other works.
mechanisms to be introduced into a distribution or use 35
A digital work is circulated with a ticket (included in the
scheme. Grammar element 1516 "Access-Spec:=
purchase price and possibly embedded in the work) that
( { SC:Security-Class} { Authorization:Authorizationcan be used for a future upgrade.
ID*} { Other-Authorization:AuthorizationIn each of these cases, if a paid copy is made of the digital
ID*}{Ticket:Ticket-ID})" provides a means for restricting
work (including the ticket) the new owner would expect to
access and transmission. Access specifications can specify a 40 get a fresh (unpunched) ticket, whether the copy seller has
required security class for a repository to exercise a right or
used the work or not. In contrast, loaning a work or simply
a required authorization test that must be satisfied.
transferring it to another repository should not revitalize the
The keyword "SC:" is used to specify a minimum security
ticket.
level for the repositories involved in the access. If "SC:" is
Usage Fees and Incentives Specification
45
The billing for use of a digital work is fundamental to a
not specified, the lowest security level is acceptable.
commercial distribution system. Grammar Element 1517
The optional "Authorization:" keyword is used to specify
"Fee -Spec:= {Scheduled-Discount} Regular-Feerequired authorizations on the same repository as the work.
The optional "Other-Authorization:" keyword is used to
SpeciScheduled-Fee-SpeciMarkup-Spec" provides a range
of options for billing for the use of digital works.
specify required authorizations on the other repository in the
A key feature of this approach is the development of
50
transaction.
low-overhead billing for transactions in potentially small
The optional "Ticket:" keyword specifies the identity of a
ticket required for the transaction. A transaction involving
amounts. Thus, it becomes feasible to collect fees of only a
few cents each for thousands of transactions.
digital tickets must locate an appropriate digital ticket agent
who can "punch" or otherwise validate the ticket before the
The grammar differentiates between uses where the
transaction can proceed. Tickets are described in greater 55 charge is per use from those where it is metered by the time
detail below.
unit. Transactions can support fees that the user pays for
In a transaction involving a repository and a document
using a digital work as well as incentives paid by the right
server, some usage rights may require that the repository
grantor to users to induce them to use or distribute the digital
have a particular authorization, that the server have some
work.
authorization, or that both repositories have (possibly 60
The optional scheduled discount refers to the rest of the
different) authorizations. Authorizations themselves are
fee specification--discounting it by a percentage over time.
If it is not specified, then there is no scheduled discount.
digital works (hereinafter referred to as an authorization
object) that can be moved between repositories in the same
Regular fee specifications are constant over time. Scheduled
manner as other digital works. Their copying and transferfee specifications give a schedule of dates over which the fee
ring is subject to the same rights and fees as other digital 65 specifications change. Markup specifications are used in
works. A repository is said to have an authorization if that
d-blocks for adding a percentage to the fees already being
authorization object is contained within the repository.
charged.
Case 2:13-cv-01112 Document 1-3 Filed 12/18/13 Page 29 of 45 PageID #: 100
US 6,963,859 B2
23
24
Grammar Element 1518 "Scheduled-Discount:=
Grammar element 1525 "Markup-Spec:=
(Scheduled-Discount:(Time-Spec Percentage)*)" A
Markup:percentage To:Account-ID" is provided for adding
Scheduled-Discount is a essentially a scheduled modifier of
a percentage to the fees already being charged. For example,
any other fee specification for this version of the right of the
a 5% markup means that a fee of 5% of cumulative fee so
digital work. (It does not refer to children or parent digital 5 far will be allocated to the distributor. A markup specificaworks or to other versions of rights.). It is a list of pairs of
tion can be applied to all of the other kinds of fee specifications. It is typically used in a shell provided by a distributimes and percentages. The most recent time in the list that
has not yet passed at the time of the transaction is the one in
tor. It refers to fees associated with d-blocks that are parts of
the current d-block. This might be a convenient specification
effect. The percentage gives the discount percentage. For
10 for use in taxes, or in distributor overhead.
example, the number 10 refers to a 10% discount.
Grammar Element 1519 "Regular-Fee-Spec:=
Examples of Sets of Usage Rights
( {Fee:IIncentive: }[Per-Use-SpeciMetered-Rate-SpeciBest((Play) (Transfer (SC: 3)) (Delete)
Price -Specl Call- For- Price -Spec] {Min: Maney- Unit
This work can be played without requirements for fee or
Per: Time-Spec} {Max: Money- Unit Per: Timeauthorization on any rendering system. It can be transferred
Spec} To:Account-ID)" provides for several kinds of fee 15 to any other repository of security level 3 or greater. It can
specifications.
be deleted.
Fees are paid by the copy-owner/user to the revenue((Play) (Transfer (SC: 3)) (Delete) (Backup) (Restore
owner if Fee: is specified. Incentives are paid by the
(Fee: Per-Use: $5 To: Account-ID-678)))
revenue-owner to the user if Incentive: is specified. If the
Same as the previous example plus rights for backup and
Min: specification is given, then there is a minimum fee to 20 restore. The work can be backed up without fee. It can be
be charged per time-spec unit for its use. If the Max:
restored for a $5 fee payable to the account described by
specification is given, then there is a maximum fee to be
Account-ID-678.
charged per time-spec for its use. When Fee: is specified,
((Play) (Transfer (SC: 3))
Account-ID identifies the account to which the fee is to be
(Copy (SC:3)(Fee: Per-Use: $5 To: Account-ID-678))
paid. When Incentive: is specified, Account-ID identifies the 25
(Delete (Incentive: Per-Use: $2.50 To: Account-IDaccount from which the fee is to be paid.
678)))
Grammar element 1520 "Per-Use-Spec:=Per-Use:MoneyThis work can be played, transferred, copied, or deleted.
unit" defines a simple fee to be paid every time the right is
Copy or transfer operations can take place only with reposiexercised, regardless of how much time the transaction
tories of security level three or greater. The fee to make a
30
takes.
copy is $5 payable to Account-ID-678. If a copy is deleted,
Grammar element 1521 "Metered-Rate-Spec:=
then an incentive of $2.50 is paid to the former copy owner.
Metered:Money-Unit Per:Time-Spec" defines a metered((Play) (Transfer (SC: 3))
rate fee paid according to how long right is exercised. Thus,
Copy (SC: 3) (Fee: Per-Use: $10 To: Account-ID-678))
the time it takes to complete the transaction determines the
Delete)
(Backup) (Restore (SC: 3) (Fee: Per-Use: $5
fee.
35
To: Account-ID-678)))
Grammar element 1522 "Best-Price-Spec:=BestSame as the previous example plus fees for copying. The
Price:Money-unit Max:Money-unit" is used to specify a
work can be copied digitally for a fee of $10 payable to
best-price that is determined when the account is settled.
Account-ID-678. The repository on which the work is
This specification is to accommodate special deals, rebates,
and pricing that depends on information that is not available 40 copied or restored must be at security level 3 or greater.
((Play) (Transfer (SC: 3))
to the repository. All fee specifications can be combined with
(Copy Authorization: License-123-ID (SC: 3)))
tickets or authorizations that could indicate that the conThe digital work can be played, transferred, or copied.
sumer is a wholesaler or that he is a preferred customer, or
Copies or transfers must be on repositories of security level
that the seller be authorized in some way. The amount of
money in the Max: field is the maximum amount that the use 45 3 or greater. Copying requires the license License-123-ID
issued to the copying repository. None of the rights require
will cost. This is the amount that is tentatively debited from
fees.
the credit server. However, when the transaction is ulti((Play) (Print Printer: Printer-567-ID (Fee: Per-Use: $1
mately reconciled, any excess amount will be returned to the
To: Account-ID-678)))
consumer in a separate transaction.
This work can be played for free. It can be printed on any
Grammar element 1523 "Call-For-Price-Spec:=Call-For- 50
printer with the identifier Printer-567-ID for a fee of $1
Price" is similar to a "Best-Price-Spec" in that it is intended
payable to the account described by Account-ID-678.
to accommodate cases where prices are dynamic. A Call((Play Player: Player-876-ID) (From: 94/02/14 Until:
For-Price Spec requires a communication with a dealer to
95/02/15) (Fee: Metered: $0.01 Per: 0:1:0 Min: $0.25
determine the price. This option cannot be exercised if the
Per: 0!1/0 To: Account-ID-567))
repository cannot communicate with a dealer at the time that 55
This work can be played on any player holding the ID
the right is exercised. It is based on a secure transaction
Player-876-ID. The time of this right is from Feb. 14, 1994
whereby the dealer names a price to exercise the right and
until Feb. 15, 1995. The fee for use is one cent per minute
passes along a deal certificate which is referenced or
with a minimum of 25 cents in any day that it is used,
included in the billing process.
Grammar element 1524 "Scheduled-Fee-Spec:= 60 payable to the account described by Account-ID-567.
(Schedule:(Time-Spec Regular-Fee-Spec)*)" is used to pro((Play) (Transfer) (Delete)(Loan 2 (Delete: Transfer
vide a schedule of dates over which the fee specifications
Loan)))
change. The fee specification with the most recent date not
This work can be played, transferred, deleted, or loaned.
Up to two copies can be loaned out at a time. The loaned
in the future is the one that is in effect. This is similar to but
more general than the scheduled discount. It is more general, 65 copy has the same rights except that it cannot be transferred.
because it provides a means to vary the fee agreement for
When both copies are loaned out, no rights can be exercised
each time period.
on the original on the repository.
Case 2:13-cv-01112 Document 1-3 Filed 12/18/13 Page 30 of 45 PageID #: 101
US 6,963,859 B2
25
26
((Play) (Transfer) (Delete) (Backup) (Restore (SC:3))
encrypted utilizing a public key encryption technique. Pub(Loan 2 Remaining-Copy-Rights: (Delete: Play
lic key encryption is a well known technique in the encrypTransfer)
tion arts. The term key refers to a numeric code that is used
Next-Set-of-Rights: (Delete: Transfer Loan)))
with encryption and decryption algorithms. Keys come in
Similar to previous example. Rights to Backup and 5 pairs, where "writing keys" are used to encrypt data and
"checking keys" are used to decrypt data. Both writing and
Restore the work are added, where restoration requires a
checking keys may be public or private. Public keys are
repository of at least security level three. When all copies of
those that are distributed to others. Private keys are mainthe work are loaned out, the remaining copy cannot be
tained in confidence.
played or transferred.
Key management and security is instrumental in the
((Play) (Transfer) (Copy) (Print) (Backup) (Restore 10
success
of a public key encryption system. In the currently
(SC:3))
preferred embodiment, one or more master repositories
(Loan 1 Remaining-Copy-Rights: (Add: Play Print
maintain the keys and create the identification certificates
Backup)
used by the repositories.
Next-Set-of-Rights: (Delete: Transfer Loan)
When a sending repository transmits a message to a
(Fee: Metered: $10 Per: 1:0:0 To: Account-ID-567)) 15 receiving repository, the sending repository encrypts all of
(Loan 1 Remaining-Copy-Rights:
its data using the public writing key of the receiving reposiAdd: ((Play Player: Player-876-ID) 2 (From: 94/02/14
tory. The sending repository includes its name, the name of
Until: 95/02/15)
the receiving repository, a session identifier such as a nonce
(Fee: Metered: $0.01 Per: 0:1:0 Min: $0.25 Per: 0!1/0
(described below), and a message counter in each message.
To: Account-ID-567))))
In this way, the communication can only be read (to a high
20
The original work has rights to Play, Transfer, Copy, Print,
probability) by the receiving repository, which holds the
Backup, Restore, and Loan. There are two versions of the
private checking key for decryption. The auxiliary data is
Loan right. The first version of the loan right costs $10 per
used to guard against various replay attacks to security. If
day but allows the original copy owner to exercise free use
messages ever arrive with the wrong counter or an old
of the Play, Print and Backup rights. The second version of 25 nonce, the repositories can assume that someone is interferthe Loan right is free. None of the original rights are
ing with communication and the transaction terminated.
applicable. However a right to Play the work at the specified
The respective public keys for the repositories to be used
metered rate is added.
for encryption are obtained in the registration transaction
((Play Player: Player-Small-Screen-123-ID)
described below.
30 Session Initiation Transactions
(Embed (Fee: Per-Use $0.01 To: Account-678-ID))
(Copy (Fee: Per-Use $1.00 To: Account-678-ID)))
A usage transaction is carried out in a session between
The digital work can be played on any player with the
repositories. For usage transactions involving more than one
identifier Player-Small-Screen-123-ID. It can be embedded
repository, or for financial transactions between a repository
in a larger work. The embedding requires a modest one cent
and a credit server, a registration transaction is performed. A
registration fee to Account-678-ID. Digital copies can be 35 second transaction termed a login transaction, may also be
made for $1.00.
needed to initiate the session. The goal of the registration
transaction is to establish a secure channel between two
Repository Transactions
repositories who know each others identities. As it is
When a user requests access to a digital work, the
repository will initiate various transactions. The comb inaassumed that the communication channel between the
tion of transactions invoked will depend on the specifica- 40 repositories is reliable but not secure, there is a risk that a
non-repository may mimic the protocol in order to gain
tions assigned for a usage right. There are three basic types
illegitimate access to a repository.
of transactions, Session Initiation Transactions, Financial
Transactions and Usage Transactions. Generally, session
The registration transaction between two repositories is
initiation transactions are initiated first to establish a valid
described with respect to FIGS. 16 and 17. The steps
session. When a valid session is established, transactions 45 described are from the perspective of a "repository-!".
corresponding to the various usage rights are invoked.
registering its identity with a "repository-2". The registraFinally, request specific transactions are performed.
tion must be symmetrical so the same set of steps will be
repeated for repository-2 registering its identity with
Transactions occur between two repositories (one acting
repository-!. Referring to FIG. 16, repository-! first generas a server), between a repository and a document playback
platform (e.g. for executing or viewing), between a reposi- 50 ates an encrypted registration identifier, step 1601 and then
tory and a credit server or between a repository and an
generates a registration message, step 1602. A registration
message is comprised of an identifier of a master repository,
authorization server. When transactions occur between more
than one repository, it is assumed that there is a reliable
the identification certificate for the repository-! and an
encrypted random registration identifier. The identification
communication channel between the repositories. For
example, this could be a TCP!IP channel or any other 55 certificate is encrypted by the master repository in its private
commercially available channel that has built-in capabilities
key and attests to the fact that the repository (here
for detecting and correcting transmission errors. However, it
repository-!) is a bona fide repository. The identification
is not assumed that the communication channel is secure.
certificate also contains a public key for the repository, the
Provisions for security and privacy are part of the requirerepository security level and a timestamp (indicating a time
ments for specifying and implementing repositories and thus 60 after which the certificate is no longer valid.) The registraform the need for various transactions.
tion identifier is a number generated by the repository for
this registration. The registration identifier is unique to the
Message Transmission
session and is encrypted in repository-l's private key. The
Transactions require that there be some communication
between repositories. Communication between repositories
registration identifier is used to improve security of authenoccurs in units termed as messages. Because the communi- 65 tication by detecting certain kinds of communications based
cation line is assumed to be unsecure, all communications
attacks. Repository-! then transmit the registration message
with repositories that are above the lowest security class are
to repository-2, step 1603.
Case 2:13-cv-01112 Document 1-3 Filed 12/18/13 Page 31 of 45 PageID #: 102
US 6,963,859 B2
27
28
Upon rece1vmg the registration message, repository-2
session information exchange and clock synchronization
steps (again from the perspective of repository-!.) Referring
determines if it has the needed public key for the master
to FIG. 17, repository-! creates a session key pair, step 1701.
repository, step 1604. If repository-2 does not have the
A first key is kept private and is used by repository-! to
needed public key to decrypt the identification certificate,
the registration transaction terminates in an error, step 1618. 5 encrypt messages. The second key is a public key used by
repository-2 to decrypt messages. The second key is
Assuming that repository-2 has the proper public key the
encrypted using the public key of repository-2, step 1702
identification certificate is decrypted, step 1605.
and is sent to repository-2, step 1703. Upon receipt,
Repository-2 saves the encrypted registration identifier, step
repository-2 decrypts the second key, step 1704. The second
1606, and extracts the repository identifier, step 1607. The
key is used to decrypt messages in subsequent communicaextracted repository identifier is checked against a "hotlist" 10
tions. When each repository has completed this step, they are
of compromised document repositories, step 1608. In the
both convinced that the other repository is bona fide and that
currently preferred embodiment, each repository will conthey are communicating with the original. Each repository
tain "hotlists" of compromised repositories. If the repository
has given the other a key to be used in decrypting further
is on the "hotlist", the registration transaction terminates in
communications during the session. Since that key is itself
an error per step 1618. Repositories can be removed from 15 transmitted in the public key of the receiving repository only
the hotlist when their certificates expire, so that the list does
it will be able to decrypt the key which is used to decrypt
not need to grow without bound. Also, by keeping a short list
subsequent messages.
of hotlist certificates that it has previously received, a
After the session information is exchanged, the repositorepository can avoid the work of actually going through the
ries must synchronize their clocks. Clock synchronization is
list. These lists would be encrypted by a master repository. 20 used by the repositories to establish an agreed upon time
base for the financial records of their mutual transactions.
A minor variation on the approach to improve efficiency
Referring back to FIG. 17, repository-2 initiates clock
would have the repositories first exchange lists of names of
synchronization by generating a time stamp exchange
hotlist certificates, ultimately exchanging only those lists
message, step 1705, and transmits it to repository-!, step
that they had not previously received. The "hotlists" are
25 1706. Upon receipt, repository-! generates its own time
maintained and distributed by Master repositories.
stamp message, step 1707 and transmits it back to
Note that rather than terminating in error, the transaction
repository-2, step 1708. Repository-2 notes the current time,
could request that another registration message be sent based
step 1709 and stores the time received from repository-!,
on an identification certificate created by another master
step 1710. The current time is compared to the time received
repository. This may be repeated until a satisfactory identification certificate is found, or it is determined that trust 30 from repository-!, step 1711. The difference is then checked
to see if it exceeds a predetermined tolerance (e.g. one
cannot be established.
minute), step 1712. If it does, repository-2 terminates the
Assuming that the repository is not on the hotlist, the
transaction as this may indicate tampering with the
repository identification needs to be verified. In other words,
repository, step 1713. If not repository-2 computes an
repository-2 needs to validate that the repository on the other
end is really repository-!. This is termed performance test- 35 adjusted time delta, step 1714. The adjusted time delta is the
difference between the clock time of repository-2 and the
ing and is performed in order to avoid invalid access to the
average of the times from repository-! and repository-2.
repository via a counterfeit repository replaying a recording
To achieve greater accuracy, repository-2 can request the
of a prior session initiation between repository-! and
time again up to a fixed number of times (e.g. five times),
repository-2. Performance testing is initiated by repository-2
generating a performance message, step 1609. The perfor- 40 repeat the clock synchronization steps, and average the
results.
mance message consists of a nonce, the names of the
A second session initiation transaction is a Login transrespective repositories, the time and the registration identiaction. The Login transaction is used to check the authenfier received from repository-!. A nonce is a generated
ticity of a user requesting a transaction. A Login transaction
message based on some random and variable information
(e.g. the time or the temperature.) The nonce is used to check 45 is particularly prudent for the authorization of financial
transactions that will be charged to a credit server. The Login
whether repository-! can actually exhibit correct encrypting
transaction involves an interaction between the user at a user
of a message using the private keys it claims to have, on a
interface and the credit server associated with a repository.
message that it has never seen before. The performance
The information exchanged here is a login string supplied by
message is encrypted using the public key specified in the
registration message of repository-!. The performance mes- 50 the repository/credit server to identify itself to the user, and
a Personal Identification Number (PIN) provided by the user
sage is transmitted to repository-!, step 1610, where it is
to identify himself to the credit server. In the event that the
decrypted by repository-! using its private key, step 1611.
user is accessing a credit server on a repository different
Repository-! then checks to make sure that the names of the
from the one on which the user interface resides, exchange
two repositories are correct, step 1612, that the time is
accurate, step 1613 and that the registration identifier cor- 55 of the information would be encrypted using the public and
private keys of the respective repositories.
responds to the one it sent, step 1614. If any of these tests
Billing Transactions
fails, the transaction is terminated per step 1616. Assuming
Billing Transactions are concerned with monetary transthat the tests are passed, repository-! transmits the nonce to
action with a credit server. Billing Transaction are carried
repository-2 in the clear, step 1615. Repository-2 then
compares the received nonce to the original nonce, step 60 out when all other conditions are satisfied and a usage fee is
required for granting the request. For the most part, billing
1617. If they are not identical, the registration transaction
transactions are well understood in the state of the art. These
terminates in an error per step 1618. If they are the same, the
transactions are between a repository and a credit server, or
registration transaction has successfully completed.
between a credit server and a billing clearinghouse. Briefly,
At this point, assuming that the transaction has not
terminated, the repositories exchange messages containing 65 the required transactions include the following:
session keys to be used in all communications during the
Registration and LOGIN transactions by which the
session and synchronize their clocks. FIG. 17 illustrates the
repository and user establish their bona-fides to a credit
Case 2:13-cv-01112 Document 1-3 Filed 12/18/13 Page 32 of 45 PageID #: 103
US 6,963,859 B2
29
30
server. These transactions would be entirely internal in
brevity, when reference is made to checking whether the
cases where the repository and credit server are implerights exist and conditions for exercising are satisfied, it is
mented as a single system.
meant that all such checking takes place for each of the
relevant parts of the work.
Registration and LOGIN transactions, by which a credit
FIG. 18 illustrates the initial common opening and closing
server establishes its bona fides to a billing clearing- 5
steps for a transaction. At this point it is assumed that
house.
registration has occurred and that a "trusted" session is in
An Assign-fee transaction to assign a charge. The inforplace.
General tests are tests on usage rights associated with
mation in this transaction would include a transaction
the folder containing the work or some containing folder
identifier, the identities of the repositories in the
transaction, and a list of charges from the parts of the 10 higher in the file system hierarchy. These tests correspond to
requirements imposed on the work as a consequence of its
digital work. If there has been any unusual event in the
being
on the particular repository, as opposed to being
transaction such as an interruption of communications,
attached to the work itself. Referring to FIG. 18, prior to
that information is included as well.
initiating a usage transaction, the requester performs any
An Begin-charges transaction to assign a charge. This 15 general tests that are required before the right associated
transaction is much the same as an assign fee transacwith the transaction can be exercised, step, 1801. For
tion except that it is used for metered use. It includes
example, install, uninstall and delete rights may be implethe same information as the assign-fee transaction as
mented to require that a requester have an authorization
well as the usage fee information. The credit-server is
certificate before the right can be exercised. Another
then responsible for running a clock.
20 example is the requirement that a digital ticket be present
An End-charges transaction to end a charge for metered
and punched before a digital work may be copied to a
use. (In a variation on this approach, the repositories
requester. If any of the general tests fail, the transaction is
would exchange periodic charge information for each
not initiated, step, 1802. Assuming that such required tests
block of time.)
are passed, upon receiving the usage request, the server
A report-charges transaction between a personal credit 25 generates a transaction identifier that is used in records or
reports of the transaction, step 1803. The server then checks
server and a billing clearinghouse. This transaction is
whether the digital work has been granted the right correinvoked at least once per billing period. It is used to
pass along information about charges. On debit and
sponding to the requested transaction, step 1804. If the
credit cards, this transaction would also be used to
digital work has not been granted the right corresponding to
update balance information and credit limits as needed. 30 the request, the transaction terminates, step 1805. If the
digital work has been granted the requested right, the server
All billing transactions are given a transaction ID and are
then determines if the various conditions for exercising the
reported to the credit severs by both the server and the client.
This reduces possible loss of billing information if one of the
right are satisfied. Time based conditions are examined, step
1806. These conditions are checked by examining the time
parties to a transaction loses a banking card and provides a
check against tampering with the system.
35 specification for the the version of the right. If any of the
Usage Transactions
conditions are not satisfied, the transaction terminates per
After the session initiation transactions have been
step 1805.
completed, the usage request may then be processed. To
Assuming that the time based conditions are satisfied, the
server checks security and access conditions, step 1807.
simplify the description of the steps carried out in processing
a usage request, the term requester is used to refer to a 40 Such security and access conditions are satisfied if: 1) the
requester is at the specified security class, or a higher
repository in the requester mode which is initiating a
security class, 2) the server satisfies any specified authorirequest, and the term server is used to refer to a repository
in the server mode and which contains the desired digital
zation test and 3) the requester satisfies any specified authowork. In many cases such as requests to print or view a work,
rization tests and has any required digital tickets. If any of
the requester and server may be the same device and the 45 the conditions are not satisfied, the transaction terminates
per step 1805.
transactions described in the following would be entirely
Assuming that the security and access conditions are all
internal. In such instances, certain transaction steps, such as
satisfied, the server checks the copy count condition, step
the registration transaction, need not be performed.
1808. If the copy count equals zero, then the transaction
There are some common steps that are part of the semantics of all of the usage rights transactions. These steps are 50 cannot be completed and the transaction terminates per step
1805.
referred to as the common transaction steps. There are two
sets-the "opening" steps and the "closing" steps. For
Assuming that the copy count does not equal zero, the
server checks if the copies in use for the requested right is
simplicity, these are listed here rather than repeating them in
the descriptions of all of the usage rights transactions.
greater than or equal to any copy count for the requested
Transactions can refer to a part of a digital work, a 55 right (or relevant parts), step 1809. If the copies in use is
complete digital work, or a Digital work containing other
greater than or equal to the copy count, this indicates that
digital works. Although not described in detail herein, a
usage rights for the version of the transaction have been
exhausted. Accordingly, the server terminates the
transaction may even refer to a folder comprised of a
transaction, step 1805. If the copy count is less than the
plurality of digital works. The term "work" is used to refer
to what ever portion or set of digital works is being accessed. 60 copies in use for the transaction the transaction can continue,
Many of the steps here involve determining if certain
and the copies in use would be incremented by the number
of digital works requested in the transaction, step 1810.
conditions are satisfied. Recall that each usage right may
The server then checks if the digital work has a "Loan"
have one or more conditions which must be satisfied before
the right can be exercised. Digital works have parts and parts
access right, step 1811. The "Loan" access right is a special
have parts. Different parts can have different rights and fees. 65 case since remaining rights may be present even though all
copies are loaned out. If the digital work has the "Loan"
Thus, it is necessary to verify that the requirements are met
access right, a check is made to see if all copies have been
for ALL of the parts that are involved in a transaction For
Case 2:13-cv-01112 Document 1-3 Filed 12/18/13 Page 33 of 45 PageID #: 104
US 6,963,859 B2
31
32
loaned out, step 1812. The number of copies that could be
FIG. 19 is a state diagram showing steps in the process of
loaned is the sum of the Copy-Counts for all of the versions
transmitting information during a transaction. Each box
of the loan right of the digital work. For a composite work,
represents a state of a repository in either the server mode
the relevant figure is the minimal such sum of each of the
(above the central dotted line 1901) or in the requester mode
components of the composite work. If all copies have been 5 (below the dotted line 1901). Solid arrows stand for transiloaned out, the remaining rights are determined, step 1813.
tions between states. Dashed arrows stand for message
The remaining-rights is determined from the remaining
communications between the repositories. A dashed mesrights specifications from the versions of the Loan right. If
sage arrow pointing to a solid transition arrow is interpreted
there is only one version of the Loan right, then the
as meaning that the transition takes place when the message
determination is simple. The remaining rights are the ones
10 is received. Unlabeled transition arrows take place unconspecified in that version of the Loan right, or none if
ditionally. Other labels on state transition arrows describe
Remaining-Rights: is not specified. If there are multiple
conditions that trigger the transition.
versions of the Loan right and all copies of all of the versions
Referring now to FIG. 19, the server is initially in a state
are loaned out, then the remaining rights is taken as the
1902 where a new transaction is initiated via start message
minimum set (intersection) of remaining rights across all of
the versions of the loan right. The server then determines if 15 1903. This message includes transaction information including a transaction identifier and a count of the blocks of data
the requested right is in the set of remaining rights, step
to be transferred. The requester, initially in a wait state 1904
1814. If the requested right is not in the set of remaining
then enters a data wait state 1905.
rights, the server terminates the transaction, step 1805.
The server enters a data transmit state 1906 and transmits
If Loan is not a usage right for the digital work or if all
copies have not been loaned out or the requested right is in 20 a block of data 1907 and then enters a wait for acknowlthe set of remaining rights, fee conditions for the right are
edgement state 1908. As the data is received, the requesters
then checked, step 1815. This will initiate various financial
enters a data receive state 1909 and when the data blocks is
transactions between the repository and associated credit
completely received it enters an acknowledgement state
server. Further, any metering of usage of a digital work will
1910 and transmits an Acknowledgement message 1911 to
commence. If any financial transaction fails, the transaction 25 the server.
terminates per step 1805.
If there are more blocks to send, the server waits until
It should be noted that the order in which the conditions
receiving an Acknowledgement message from the requester.
are checked need not follow the order of steps 1806-1815.
When an Acknowledgement message is received it sends the
At this point, right specific steps are now performed and
next block to the requester and again waits for acknowlare represented here as step 1816. The right specific steps are
30 edgement. The requester also repeats the same cycle of
described in greater detail below.
states.
The common closing transaction steps are now perIf the server detects a communications failure before
formed. Each of the closing transaction steps are performed
sending the last block, it enters a cancellation state 1912
by the server after a successful completion of a transaction.
wherein the transaction is cancelled. Similarly, if the
Referring back to FIG. 18, the copies in use value for the
requested right is decremented by the number of copies 35 requester detects a communications failure before receiving
the last block it enters a cancellation state 1913.
involved in the transaction, step 1817. Next, if the right had
If there are no more blocks to send, the server commits to
a metered usage fee specification, the server subtracts the
the transaction and waits for the final Acknowledgement in
elapsed time from the Remaining-Use-Time associated with
state 1914. If there is a communications failure before the
the right for every part involved in the transaction, step
1818. Finally, if there are fee specifications associated with 40 server receives the final Acknowledgement message, it still
commits to the transaction but includes a report about the
the right, the server initiates End-Charge financial transaction to confirm billing, step 1819.
event to its credit server in state 1915. This report serves two
purposes. It will help legitimize any claims by a user of
Transmission Protocol
An important area to consider is the transmission of the
having been billed for receiving digital works that were not
digital work from the server to the requester. The transmis- 45 completely received. Also it helps to identify repositories
sion protocol described herein refers to events occurring
and communications lines that have suspicious patterns of
after a valid session has been created. The transmission
use and interruption. The server then enters its completion
protocol must handle the case of disruption in the commustate 1916
nications between the repositories. It is assumed that interOn the requester side, when there are no more blocks to
ference such as injecting noise on the communication chan- 50 receive, the requester commits to the transaction in state
nel can be detected by the integrity checks (e.g., parity,
1917. If the requester detects a communications failure at
checksum, etc.) that are built into the transport protocol and
this state, it reports the failure to its credit server in state
are not discussed in detail herein.
1918, but still commits to the transaction. When it has
The underlying goal in the transmission protocol is to
committed, it sends an acknowledgement message to the
preclude certain failure modes, such as malicious or acci- 55 server. The server then enters its completion state 1919
dental interference on the communications channel.
The key property is that both the server and the requester
Suppose, for example, that a user pulls a card with the credit
cancel a transaction if it is interrupted before all of the data
server at a specific time near the end of a transaction. There
blocks are delivered, and commits to it if all of the data
should not be a vulnerable time at which "pulling the card"
blocks have been delivered.
There is a possibility that the server will have sent all of
causes the repositories to fail to correctly account for the 60
number of copies of the work that have been created.
the data blocks (and committed) but the requester will not
Restated, there should be no time at which a party can break
have received all of them and will cancel the transaction. In
a connection as a means to avoid payment after using a
this case, both repositories will presumably detect a comdigital work.
munications failure and report it to their credit server. This
If a transaction is interrupted (and fails), both repositories 65 case will probably be rare since it depends on very precise
timing of the communications failure. The only consequence
restore the digital works and accounts to their state prior to
the failure, modulo records of the failure itself.
will be that the user at the requester repository may want to
Case 2:13-cv-01112 Document 1-3 Filed 12/18/13 Page 34 of 45 PageID #: 105
US 6,963,859 B2
33
34
request a refund from the credit services-and the case for
The Transfer Transaction
A Transfer transaction is a request to move copies of the
that refund will be documented by reports by both repositories.
work with the same or lesser usage rights to another reposiTo prevent loss of data, the server should not delete any
tory. In contrast with a copy transaction, this results in
transferred digital work until receiving the final acknowl- 5 removing the work copies from the server.
edgement from the requester. But it also should not use the
The requester sends the server a message to initiate the
file. A well known way to deal with this situation is called
Transfer Transaction. This message indicates the work
"two-phase commit" or 2PC.
to be transferred, the version of the transfer right to be
Two-phase commit works as follows. The first phase
used in the transaction, the destination address inforworks the same as the method described above. The server 10
mation for placing the work, the file data for the work,
sends all of the data to the requester. Both repositories mark
and the number of copies involved.
the transaction (and appropriate files) as uncommitted. The
The repositories perform the common opening transaction
server sends a ready-to-commit message to the requester.
steps.
The requester sends back an acknowledgement. The server
The server transmits the requested contents and data to the
then commits and sends the requester a commit message. 15
requester according to the transmission protocol. If a
When the requester receives the commit message, it comNext-Set-Of-Rights has been provided, those rights are
mits the file.
transmitted as the rights for the work. Otherwise, the
If there is a communication failure or other crash, the
rights of the original are transmitted. In either case, the
requester must check back with the server to determine the
Copy-Count field for the transmitted rights are set to
status of the transaction. The server has the last word on this. 20
the number-of-copies requested.
The requester may have received all of the data, but if it did
The requester records the work contents, data, and usage
not get the final message, it has not committed. The server
rights and stores the work.
can go ahead and delete files (except for transaction records)
The
server decrements its copy count by the number of
once it commits, since the files are known to have been fully
copies involved in the transaction.
25
transmitted before starting the 2PC cycle.
The repositories perform the common closing transaction
There are variations known in the art which can be used
steps.
to achieve the same effect. For example, the server could use
an additional level of encryption when transmitting a work
If the number of copies remaining in the server is now
to a client. Only after the client sends a message acknowlzero, it erases the digital work from its memory.
edging receipt does it send the key. The client then agrees to 30 The Loan Transaction
pay for the digital work. The point of this variation is that it
A loan transaction is a mechanism for loaning copies of a
provides a clear audit trail that the client received the work.
digital work. The maximum duration of the loan is deterFor trusted systems, however, this variation adds a level of
mined by an internal parameter of the digital work. Works
encryption for no real gain in accountability.
are automatically returned after a predetermined time
The transaction for specific usage rights are now dis- 35 period.
cussed.
The requester sends the server a message to initiate the
The Copy Transaction
Transfer Transaction. This message indicates the work
A Copy transaction is a request to make one or more
to be loaned, the version of the loan right to be used in
independent copies of the work with the same or lesser usage
the transaction, the destination address information for
rights. Copy differs from the extraction right discussed later 40
placing the work, the number of copies involved, the
in that it refers to entire digital works or entire folders
file data for the work, and the period of the loan.
containing digital works. A copy operation cannot be used to
The server checks the validity of the requested loan
remove a portion of a digital work.
period, and ends with an error if the period is not valid.
The requester sends the server a message to initiate the
Loans for a loaned copy cannot extend beyond the
Copy Transaction. This message indicates the work to 45
period of the original loan to the server.
be copied, the version of the copy right to be used for
The repositories perform the common opening transaction
the transaction, the destination address information
steps.
(location in a folder) for placing the work, the file data
The server transmits the requested contents and data to the
for the work (including its size), and the number of
requester. If a Next-Set-Of-Rights has been provided,
50
copies requested.
those rights are transmitted as the rights for the work.
The repositories perform the common opening transaction
Otherwise, the rights of the original are transmitted, as
steps.
modified to reflect the loan period.
The server transmits the requested contents and data to the
The requester records the digital work contents, data,
client according to the transmission protocol. If a 55
usage rights, and loan period and stores the work.
Next-Set-Of-Rights has been provided in the version of
The server updates the usage rights information in the
the right, those rights are transmitted as the rights for
digital work to reflect the number of copies loaned out.
the work. Otherwise, the rights of the original are
The repositories perform the common closing transaction
transmitted. In any event, the Copy-Count field for the
steps.
copy of the digital work being sent right is set to the 60
The server updates the usage rights data for the digital
number-of-copies requested.
work. This may preclude use of the work until it is
The requester records the work contents, data, and usage
returned from the loan. The user on the requester
rights and stores the work. It records the date and time
platform can now use the transferred copies of the
that the copy was made in the properties of the digital
digital work. A user accessing the original repository
work.
65
cannot use the digital work, unless there are copies
The repositories perform the common closing transaction
remaining. What happens next depends on the order of
steps.
events in time.
Case 2:13-cv-01112 Document 1-3 Filed 12/18/13 Page 35 of 45 PageID #: 106
US 6,963,859 B2
35
36
Case 1. If the time of the loan period is not yet
with ink on paper. However, the key aspect of "printing" in
exhausted and the requester sends the repository a
our use of the term is that it makes a copy of the digital work
Return message.
in a place outside of the protection of usage rights. As with
The return message includes the requester
all rights, this may require particular authorization certifiidentification, and the transaction ID.
5 cates.
The server decrements the copies-in-use field by the
Once a digital work is printed, the publisher and user are
number of copies that were returned. (If the numbound by whatever copyright laws are in effect. However,
printing moves the contents outside the control of repositober of digital works returned is greater than the
ries. For example, absent any other enforcement
number actually borrowed, this is treated as an
error.) This step may now make the work available 10 mechanisms, once a digital work is printed on paper, it can
be copied on ordinary photocopying machines without interat the server for other users.
vention by a repository to collect usage fees. If the printer to
The requester deactivates its copies and removes the
a digital disk is permitted, then that digital copy is outside
contents from its memory.
of the control of usage rights. Both the creator and the user
Case 2. If the time of the loan period is exhausted and
the requester has not yet sent a Return message.
15 know this, although the creator does not necessarily give
The server decrements the copies-in-use field by the
tacit consent to such copying, which may violate copyright
laws.
number digital works that were borrowed.
The requester automatically deactivates its copies of
The requester sends the server a message to initiate a Print
the digital work. It terminates all current uses and
transaction. This message indicates the work to be
erases the digital work copies from memory. One 20
played, the identity of the printer being used, the file
question is why a requester would ever return a
data for the work, and the number of copies in the
work earlier than the period of the loan, since it
request.
would be returned automatically anyway. One
The server checks the validity of the printer identification
reason for early return is that there may be a
and the compatibility of the printer identification with
metered fee which determines the cost of the loan. 25
the printer specification in the right. It ends with an
Returning early may reduce that fee.
error if these are not satisfactory.
The Play Transaction
The repositories perform the common opening transaction
A play transaction is a request to use the contents of a
steps.
work. Typically, to "play" a work is to send the digital work
The server transmits blocks of data according to the
through some kind of transducer, such as a speaker or a 30
transmission protocol.
display device. The request implies the intention that the
The
requester prints the work contents, using the printer.
contents will not be communicated digitally to any other
When
the printer is finished, the printer and the requester
system. For example, they will not be sent to a printer,
remove
the contents from their memory.
recorded on any digital medium, retained after the transacThe repositories perform the common closing transaction
35
tion or sent to another repository.
steps.
This term "play" is natural for examples like playing
The Backup Transaction
music, playing a movie, or playing a video game. The
A Backup transaction is a request to make a backup copy
general form of play means that a "player" is used to use the
of a digital work, as a protection against media failure. In the
digital work. However, the term play covers all media and
kinds of recordings. Thus one would "play" a digital work, 40 context of repositories, secure backup copies differ from
other copies in three ways: (1) they are made under the
meaning, to render it for reading, or play a computer
control of a Backup transaction rather than a Copy
program, meaning to execute it. For a digital ticket the
transaction, (2) they do not count as regular copies, and (3)
player would be a digital ticket agent.
they are not usable as regular copies. Generally, backup
The requester sends the server a message to initiate the
play transaction. This message indicates the work to be 45 copies are encrypted.
Although backup copies may be transferred or copied,
played, the version of the play right to be used in the
depending on their assigned rights, the only way to make
transaction, the identity of the player being used, and
them useful for playing, printing or embedding is to restore
the file data for the work.
them.
The server checks the validity of the player identification
The output of a Backup operation is both an encrypted
50
and the compatibility of the player identification with
data file that contains the contents and description of a work,
the player specification in the right. It ends with an
and a restoration file with an encryption key for restoring the
error if these are not satisfactory.
encrypted contents. In many cases, the encrypted data file
The repositories perform the common opening transaction
would have rights for "printing" it to a disk outside of the
steps.
55 protection system, relying just on its encryption for security.
The server and requester read and write the blocks of data
Such files could be stored anywhere that was physically safe
as requested by the player according to the transmission
and convenient. The restoration file would be held in the
protocol. The requester plays the work contents, using
repository. This file is necessary for the restoration of a
the player.
backup copy. It may have rights for transfer between reposiWhen the player is finished, the player and the requester 60 tories.
remove the contents from their memory.
The requester sends the server a message to initiate a
backup transaction. This message indicates the work to
The repositories perform the common closing transaction
be backed up, the version of the backup right to be used
steps.
in the transaction, the destination address information
The Print Transaction
for placing the backup copy, the file data for the work.
A Print transaction is a request to obtain the contents of a 65
The repositories perform the common opening transaction
work for the purpose of rendering them on a "printer." We
use the term "printer" to include the common case of writing
steps.
Case 2:13-cv-01112 Document 1-3 Filed 12/18/13 Page 36 of 45 PageID #: 107
US 6,963,859 B2
37
38
The server transmits the requested contents and data to the
roughly the same idea as protection codes in a conventional
requester. If a Next-Set-Of-Rights has been provided,
file system like TENEX, except that it is generalized to the
those rights are transmitted as the rights for the work.
full power of the access specifications of the usage rights
Otherwise, a set of default rights for backup files of the
language.
original are transmitted by the server.
5
The Directory transaction has the important role of passThe requester records the work contents, data, and usage
ing along descriptions of the rights and fees associated with
rights. It then creates a one-time key and encrypts the
a digital work. When a user wants to exercise a right, the
contents file. It saves the key information in a restorauser interface of his repository implicitly makes a directory
tion file.
request to determine the versions of the right that are
The repositories perform the common closing transaction 10 available. Typically these are presented to the user such as
steps.
with different choices of billing for exercising a right. Thus,
In some cases, it is convenient to be able to archive the
many directory transactions are invisible to the user and are
large, encrypted contents file to secure offline storage, such
exercised as part of the normal process of exercising all
as a magneto-optical storage system or magnetic tape. This
rights.
creation of a non-repository archive file is as secure as the 15
The requester sends the server a message to initiate a
encryption process. Such non-repository archive storage is
Directory transaction. This message indicates the file or
considered a form of "printing" and is controlled by a print
folder that is the root of the directory request and the
right with a specified "archive-printer." An archive-printer
version of the directory right used for the transaction.
device is programmed to save the encrypted contents file
The server verifies that the information is accessible to the
(but not the description file) offline in such a way that it can 20
requester.
be retrieved.
In particular, it does not return the names of any files that
The Restore Transaction
have a HIDE-NAME status in their directory specifications,
A Restore transaction is a request to convert an encrypted
and it does not return the parts of any folders or files that
backup copy of a digital work into a usable copy. A restore
have HIDE-PARTS in their specification. If the information
operation is intended to be used to compensate for cata- 25
is not accessible, the server ends the transaction with an
strophic media failure. Like all usage rights, restoration
error.
rights can include fees and access tests including authoriThe repositories perform the common opening transaction
zation checks.
steps.
The requester sends the server a message to initiate a
The server sends the requested data to the requester
Restore transaction. This message indicates the work to 30
according to the transmission protocol.
be restored, the version of the restore right for the
The requester records the data.
transaction, the destination address information for
placing the work, and the file data for the work.
The repositories perform the common closing transaction
The server verifies that the contents file is available (i.e.
steps.
a digital work corresponding to the request has been 35 The Folder Transaction
backed-up.) If it is not, it ends the transaction with an
A Folder transaction is a request to create or rename a
error.
folder, or to move a work between folders. Together with
The repositories perform the common opening transaction
Directory rights, Folder rights control the degree to which
steps.
organization of a repository can be accessed or modified
The server retrieves the key from the restoration file. It 40 from another repository.
decrypts the work contents, data, and usage rights.
The requester sends the server a message to 1mt1ate a
Folder transaction. This message indicates the folder
The server transmits the requested contents and data to the
that is the root of the folder request, the version of the
requester according to the transmission protocol. If a
Next-Set-Of-Rights has been provided, those rights are
folder right for the transaction, an operation, and data.
transmitted as the rights for the work. Otherwise, a set 45
The operation can be one of create, rename, and move
of default rights for backup files of the original are
file. The data are the specifications required for the
transmitted by the server.
operation, such as a specification of a folder or digital
work and a name.
The requester stores the digital work.
The repositories perform the common opening transaction
The repositories perform the common closing transaction 50
steps.
steps.
The Delete Transaction
The server performs the requested operation--creating a
A Delete transaction deletes a digital work or a number of
folder, renaming a folder, or moving a work between
copies of a digital work from a repository. Practically all
folders.
digital works would have delete rights.
The repositories perform the common closing transaction
55
The requester sends the server a message to initiate a
steps.
delete transaction. This message indicates the work to
The Extract Transaction
be deleted, the version of the delete right for the
A extract transaction is a request to copy a part of a digital
transaction.
work and to create a new work containing it. The extraction
The repositories perform the common opening transaction 60 operation differs from copying in that it can be used to
steps.
separate a part of a digital work from d-blocks or shells that
place additional restrictions or fees on it. The extraction
The server deletes the file, erasing it from the file system.
operation differs from the edit operation in that it does not
The repositories perform the common closing transaction
change the contents of a work, only its embedding in
steps.
The Directory Transaction
65 d-blocks. Extraction creates a new digital work.
The requester sends the server a message to initiate an
A Directory transaction is a request for information about
Extract transaction. This message indicates the part of
folders, digital works, and their parts. This amounts to
Case 2:13-cv-01112 Document 1-3 Filed 12/18/13 Page 37 of 45 PageID #: 108
US 6,963,859 B2
39
40
the work to be extracted, the version of the extract right
size), the process-ID for the process, and the number of
copies involved.
to be used in the transaction, the destination address
information for placing the part as a new work, the file
The server checks the compatibility of the process-ID to
be used by the requester against any process-ID specidata for the work, and the number of copies involved.
fication in the right. If they are incompatible, it ends the
The repositories perform the common opening transaction 5
transaction with an error.
steps.
The repositories perform the common opening transaction
The server transmits the requested contents and data to the
steps.
requester according to the transmission protocol. If a
The requester uses the process to change the contents of
Next-Set-Of-Rights has been provided, those rights are
the digital work as desired. (For example, it can select
transmitted as the rights for the new work. Otherwise, 10
and duplicate parts of it; combine it with other inforthe rights of the original are transmitted. The Copymation; or compute functions based on the information.
Count field for this right is set to the number-of-copies
This can amount to editing text, music, or pictures or
requested.
taking whatever other steps are useful in creating a
The requester records the contents, data, and usage rights 15
derivative work.)
and stores the work. It records the date and time that
The repositories perform the common closing transaction
new work was made in the properties of the work.
steps.
The edit transaction is used to cover a wide range of kinds
The repositories perform the common closing transaction
of works. The category describes a process that takes as its
steps.
The Embed Transaction
20 input any portion of a digital work and then modifies the
An embed transaction is a request to make a digital work
input in some way. For example, for text, a process for
editing the text would require edit rights. A process for
become a part of another digital work or to add a shell
"summarizing" or counting words in the text would also be
d-block to enable the adding of fees by a distributor of the
considered editing. For a music file, processing could
work.
The requester sends the server a message to initiate an 25 involve changing the pitch or tempo, or adding
reverberations, or any other audio effect. For digital video
Embed transaction. This message indicates the work to
works, anything which alters the image would require edit
be embedded, the version of the embed right to be used
rights. Examples would be colorizing, scaling, extracting
in the transaction, the destination address information
still photos, selecting and combining frames into story
for placing the part as a a work, the file data for the
30 boards, sharpening with signal processing, and so on.
work, and the number of copies involved.
Some creators may want to protect the authenticity of
The server checks the control specifications for all of the
their works by limiting the kinds of processes that can be
rights in the part and the destination. If they are
performed on them. If there are no edit rights, then no
incompatible, the server ends the transaction with an
processing is allowed at all. A processor identifier can be
error.
included to specify what kind of process is allowed. If no
The repositories perform the common opening transaction 35 process identifier is specified, then arbitrary processors can
steps.
be used. For an example of a specific process, a photograThe server transmits the requested contents and data to the
pher may want to allow use of his photograph but may not
requester according to the transmission protocol. If a
want it to be colorized. A musician may want to allow
Next-Set-Of-Rights has been provided, those rights are
40 extraction of portions of his work but not changing of the
transmitted as the rights for the new work. Otherwise,
tonality.
the rights of the original are transmitted. The CopyAuthorization Transactions
Count field for this right is set to the number-of-copies
There are many ways that authorization transactions can
requested.
be defined. In the following, our preferred way is to simply
The requester records the contents, data, and usage rights 45 define them in terms of other transactions that we already
and embeds the work in the destination file.
need for repositories. Thus, it is convenient sometimes to
speak of "authorization transactions," but they are actually
The repositories perform the common closing transaction
made up of other transactions that repositories already have.
steps.
A usage right can specify an authorization-ID, which
The Edit Transaction
An Edit transaction is a request to make a new digital 50 identifies an authorization object (a digital work in a file of
a standard format) that the repository must have and which
work by copying, selecting and modifying portions of an
it must process. The authorization is given to the generic
existing digital work. This operation can actually change the
authorization (or ticket) server of the repository which
contents of a digital work. The kinds of changes that are
begins to interpret the authorization.
permitted depend on the process being used. Like the
As described earlier, the authorization contains a server
extraction operation, edit operates on portions of a digital 55
identifier, which may just be the generic authorization server
work. In contrast with the extract operation, edit does not
or it may be another server. When a remote authorization
effect the rights or location of the work. It only changes the
server is required, it must contain a digital address. It may
contents. The kinds of changes permitted are determined by
also contain a digital certificate.
the type specification of the processor specified in the rights.
If a remote authorization server is required, then the
In the currently preferred embodiment, an edit transaction 60
authorization process first performs the following steps:
changes the work itself and does not make a new work.
However, it would be a reasonable variation to cause a new
The generic authorization server attempts to set up the
copy of the work to be made.
communications channel. (If the channel cannot be set
up, then authorization fails with an error.)
The requester sends the server a message to initiate an
Edit transaction. This message indicates the work to be 65
When the channel is set up, it performs a registration
process with the remote repository. (If registration fails,
edited, the version of the edit right to be used in the
transaction, the file data for the work (including its
then the authorization fails with an error.)
Case 2:13-cv-01112 Document 1-3 Filed 12/18/13 Page 38 of 45 PageID #: 109
US 6,963,859 B2
41
42
When registration is complete, the generic authorization
repository where it is no longer accessible as a work for
exercising any usage rights other than the execution of
server invokes a "Play" transaction with the remote
the software as part of repository operations in carrying
repository, supplying the authorization document as the
out other transactions.
digital work to be played, and the remote authorization
The repositories perform the common closing transaction
server (a program) as the "player." (If the player cannot 5
steps.
be found or has some other error, then the authorization
The Uninstall Transaction
fails with an error.)
An Uninstall transaction is a request to remove software
The authorization server then "plays" the authorization.
from a repository. Since uncontrolled or incorrect removal of
This involves decrypting it using either the public key
software
from a repository could compromise its behavioral
of the master repository that issued the certificate or the 10
integrity, this step is controlled.
session key from the repository that transmitted it. The
The requester sends the server an Uninstall message. This
authorization server then performs various tests. These
message indicates the work to be uninstalled, the vertests vary according to the authorization server. They
sion of the Uninstall right being invoked, and the file
include such steps as checking issue and validity dates
data for the work (including its size).
of the authorization and checking any hot-lists of 15
The repositories perform the common opening transaction
known invalid authorizations. The authorization server
steps.
may require carrying out any other transactions on the
The requester extracts a copy of the digital certificate for
repository as well, such as checking directories, getting
the software. If the certificate cannot be found or the
some person to supply a password, or playing some
master repository for the certificate is not known to the
other digital work. It may also invoke some special 20
requester, the transaction ends with an error.
process for checking information about locations or
The requester checks whether the software is installed. If
recent events. The "script" for such steps is contained
the software is not installed, the transaction ends with
within the authorization server.
an error.
If all of the required steps are completed satisfactorily, the
The requester decrypts the digital certificate using the
25
authorization server completes the transaction
public key of the master repository, recording the
normally, signaling that authorization is granted.
identity of the supplier and creator, a key for decrypting
The Install Transaction
the software, the compatibility information, and a
An Install transaction is a request to install a digital work
tamper-checking code. (This step authenticates the ceras runnable software on a repository. In a typical case, the
tification of the software, including the script for unin30
requester repository is a rendering repository and the softstalling it.)
ware would be a new kind or new version of a player. Also
The requester decrypts the software using the key from
in a typical case, the software would be copied to file system
the certificate and computes a check code on it using a
of the requester repository before it is installed.
1-way hash function. If the check-code does not match
The requester sends the server an Install message. This
the tamper-checking code from the certificate, the
35
message indicates the work to be installed, the version
installation transaction ends with an error. (This step
of the Install right being invoked, and the file data for
assures that the contents of the software, including the
the work (including its size).
various scripts, have not been tampered with.)
The repositories perform the common opening transaction
The requester retrieves the instructions in the uninstallasteps.
tion script and follows them. If there is an error in this
40
The requester extracts a copy of the digital certificate for
process (such as insufficient resources), then the transthe software. If the certificate cannot be found or the
action ends with an error.
master repository for the certificate is not known to the
The repositories perform the common closing transaction
requester, the transaction ends with an error.
steps.
The requester decrypts the digital certificate using the 45 Distribution and Use Scenarios
public key of the master repository, recording the
To appreciate the robustness and flexibility of the present
identity of the supplier and creator, a key for decrypting
invention, various distribution and use scenarios for digital
the software, the compatibility information, and a
works are illustrated below. These scenarios are meant to be
tamper-checking code. (This step certifies the
exemplary rather than exhaustive.
software.)
50 Consumers as Unpaid Distributors
The requester decrypts the software using the key from
In this scenario, a creator distributes copies of his works
the certificate and computes a check code on it using a
to various consumers. Each consumer is a potential distribu1-way hash function. If the check-code does not match
tor of the work. If the consumer copies the digital work
the tamper-checking code from the certificate, the
(usually for a third party), a fee is collected and automatiinstallation transaction ends with an error. (This step 55 cally paid to the creator.
assures that the contents of the software, including the
This scenario is a new twist for digital works. It depends
various scripts, have not been tampered with.)
on the idea that "manufacturing" is just copying and is
The requester retrieves the instructions in the
essentially free. It also assumes that the consumers as
compatibility-checking script and follows them. If the
distributors do not require a fee for their time and effort in
software is not compatible with the repository, the 60 distributing the work.
installation transaction ends with an error. (This step
This scenario is performed as follows:
checks platform compatibility.)
A creator creates a digital work. He grants a Copy right
The requester retrieves the instructions in the installation
with fees paid back to himself. If he does not grant an Embed
script and follows them. If there is an error in this
right, then consumers cannot use the mechanism to act as
process (such as insufficient resources), then the trans- 65 distributors to cause fees to be paid to themselves on future
action ends with an error. Note that the installation
copies. Of course, they could negotiate side deals or trades
to transfer money on their own, outside of the system.
process puts the runnable software in a place in the
Case 2:13-cv-01112 Document 1-3 Filed 12/18/13 Page 39 of 45 PageID #: 110
US 6,963,859 B2
43
44
Paid Distributors
Super Distributors
In another scenario, every time a copy of a digital work
This is a variation on the previous scenarios. A distributor
is sold a fee is paid to the creator and also to the immediate
can sell to anyone and anyone can sell additional copies,
distributor.
resulting in fees being paid back to the creator. However,
This scenario does not give special status to any particular 5 only licensed distributors can add fees to be paid to themdistributor. Anyone who sells a document has the right to
selves.
add a fee to the sale price. The fee for sale could be
This scenario gives distributors the right to add fees to
established by the consumer. It could also be a fixed nominal
cover their own advertising and promotional costs, without
amount that is contributed to the account of some charity.
making them be the sole suppliers. Their customers can also
This scenario is performed as follows:
10 make copies, thus broadening the channel without diminA creator creates a digital work. He grants a Copy right
ishing their revenues. This is because distributors collect
with fees to be paid back to himself. He grants an Embed
fees from copies of any copies that they originally sold. Only
right, so that anyone can add shells to have fees paid to
distributors can add fees.
themselves.
This scenario is performed similarly to the previous ones.
A distributor embeds the work in a shell, with fees 15 There are two key differences. (1) The creator only grants
specified to be paid back to himself. If the distributor is
Embed rights for people who have a Distribution license.
content to receive fees only for copies that he sells himself,
This is done by putting a requirement for a distributor's
he grants an Extract right on the shell.
license on the Embed right. Consequently, non-distributors
When a consumer buys a copy from the distributor, fees
cannot add their own fees. (2) The Distributor does not grant
are paid both to the distributor and to the creator. If he 20 Extract rights, so that consumers cannot avoid paying fees to
chooses, the consumer can extract the work from the disthe Distributor if they make subsequent copies.
tributor's shell. He cannot extract it from the creator's shell.
Consequently, all subsequent copies result in fees paid to the
He can add his own shell with fees to be paid to himself.
Distributor and the Creator.
Licensed Distribution
1-Level Distribution Fees
In this scenario, a creator wants to protect the reputation 25
In this scenario, a distributor gets a fee for any copy he
and value of his work by making certain requirements
sells directly. However, if one of his customers sells further
on its distributors. He issues licenses to distributors that
copies, he gets no further fee for those copies.
satisfy the requirements, and in turn, promises to
This scenario pays a distributor only for use of copies that
reward their efforts by assuring that the work will not
he actually sold.
be distributed over competing channels. The distribu- 30
This scenario is performed similarly to the previous ones.
tors incur expenses for selecting the digital work,
The key feature is that the distributor creates a shell which
explaining it to buyers, promoting its sale, and possibly
specifies fees to be paid to him. He puts Extract rights on the
for the license itself The distributor obtains the right to
shell. When a consumer buys the work, he can extract away
enclose the digital work in a shell, whose function is to
the distributor's shell. Copies made after that will not require
permit the attachment of usage fees to be paid to the 35 fees to be paid to the distributor.
distributor in addition to the fees to be paid to the
Distribution Trees
creator.
In another scenario, distributors sell to other distributors
This differs from the previous scenario in that it precludes
and fees are collected at each level. Every copy sold by any
the typical copy owner from functioning as a distributor,
distributor--even several d-blocks down in the chainsince the consumer lacks a license to copy the document. 40
results in a fee being paid back to all of the previous
Thus, a consumer cannot make copies, even for free. All
distributors.
copies must come initially from authorized distributors. This
This scenario is like a chain letter or value chain. Every
version makes it possible to hold distributors accountable in
contributor or distributor along the way obtains fees, and is
some way for the sales and support of the work, by conthereby encouraged to promote the sale of copies of the
trolling the distribution of certificates that enable distributors 45
digital work.
to legitimately charge fees and copy owners to make copies.
This scenario is performed similarly to the previous ones.
Since licenses are themselves digital works, the same
The key feature is that the distributor creates a shell which
mechanisms give the creators control over distributors by
specifies fees to be paid to him. He does not grant Extract
charging for licenses and putting time limits on their validrights on the shell. Consequently, all future copies that are
ity.
50
made will result in fees paid to him.
This scenario is performed as follows:
Weighted Distribution Trees
A creator purchases a digital distribution license that he
In this scenario, distributors make money according to a
will hand out to his distributors. He puts access requirements
distribution tree. The fee that they make depends on various
(such as a personal license) on the Copy and Transfer rights
on the distribution license so that only he can copy or 55 parameters, such as time since their sale or the number of
subsequent distributors.
transfer it.
This is a generalized version of the Distribution Tree
The creator also creates a digital work. He grants an
scenario, in that it tries to vary the fee to account for the
Embed right and a Copy right, both of which require the
significance of the role of the distributor.
distribution license to be exercised. He grants a Play right so
that the work can be played by anyone. He may optionally 60
This scenario is similar to the previous one. The difference is that the fee specification on the distributor's shell has
add a Transfer or Loan right, so that end consumers can do
provisions for changes in prices. For example, there could be
some non-commercial exchange of the work among friends.
a fee schedule so that copies made after the passage of time
A distributor obtains the distribution license and a number
will require lower fees to be paid to the distributor.
of copies of the work. He makes copies for his customers,
65 Alternatively, the distributor could employ a "best-price"
using his distribution license.
billing option, using any algorithm he chooses to determine
A customer buys and uses the work. He cannot make new
the fee up to the maximum specified in the shell.
copies because he lacks a distribution license.
Case 2:13-cv-01112 Document 1-3 Filed 12/18/13 Page 40 of 45 PageID #: 111
US 6,963,859 B2
45
46
Fees for Reuse
Upgrading a Digital Work with a Vendor
In this scenario, a first creator creates a work. It is
A consumer buys a digital work together with an agreement that he can upgrade to a new version at a later date for
distributed by a first distributor and purchased by a second
a modest fee, much less than the usual purchase price. When
creator. The second creator extracts a portion of the work
and embeds in it a new work distributed by a second 5 the new version becomes available, he goes to a qualified
distributor. A consumer buys the new work from the second
vendor to make the transaction.
This scenario deals with a common situation in computer
distributor. The first creator receives fees from every transsoftware. It shows how a purchase may include future
action; the first distributor receives fees only for his sale; the
"rights." Two important features of the scenario are that the
second creator and second distributor receive fees for the
final sale.
transaction must take place at a qualified vendor, and that the
10
This scenario shows how that flexible automatic arrangetransaction can be done only once per copy of the digital
ments can be set up to create automatic charging systems
work purchased.
that mirror current practice. This scenario is analogous to
This scenario is performed as follows:
when an author pays a fee to reuse a figure in some paper.
The creator creates a digital work, an upgrade ticket, and
In the most common case, a fee is paid to the creator or
a distribution license. The upgrade ticket uses the a generic
15 ticket agent that comes with repositories. As usual, the
publisher, but not to the bookstore that sold the book.
The mechanisms for derived works are the same as those
distribution license does not have Copy or Transfer rights.
for distribution.
He distributes a bundled copies of the work and the ticket to
Limited Reuse
his distributors as well as distribution licenses.
In this scenario, several first creators create works. A
The distributor sells the old bundled work and ticket to
second creator makes a selection of these, publishing a 20 customers.
collection made up of the parts together with some new
The customer extracts the work and the ticket. He uses the
work according to the agreements until the new version
interstitial material. (For example, the digital work could be
becomes available.
a selection of music or a selection of readings.) The second
When the new work is ready, the creator gives it to
creator wants to continue to allow some of the selected
works to be extractable, but not the interstitial material.
25 distributors. The new work has a free right to copy from a
This scenario deals with fine grained control of the rights
distributor if a ticket is available.
and fees for reuse.
The consumer goes to distributors and arranges to copy
the work. The transaction offers the ticket. The distributor's
This scenario is performed as follows:
The first creators create their original works. If they grant
repository punches the ticket and copies the new version to
extraction and embedding rights, then the second creator can 30 the consumers repository.
include them in a larger collected work. The second creator
The consumer can now use the new version of the work.
creates the interstitial material. He does grant an Extract
Distributed Upgrading of Digital Works
A consumer buys a digital work together with an agreeright on the interstitial material. He grants Extract rights on
a subset of the reused material. A consumer of the collection
ment that he can upgrade to a new version at a later date for
can only extract portions that have that right. Fees are 35 a modest fee, much less than the usual purchase price. When
the new version becomes available, he goes to anyone who
automatically collected for all parts of the collection.
has the upgraded version and makes the transaction.
Commercial Libraries
This scenario is like the previous one in that the transacCommercial libraries buy works with the right to loan.
tion can only be done once per copy of the digital work
They limit the loan period and charge their own fees for use.
This scenario deals with fees for loaning rather than fees for 40 purchased, but the transaction can be accomplished without
making copies. The fees are collected by the same automatic
the need to connect to a licensed vendor.
mechanisms.
This scenario is similar to the previous one except that the
Copy right on the new work does not require a distribution
The mechanisms are the same as previous scenarios
except that the fees are associated with the Loan usage right
license. The consumer can upgrade from any repository
rather than the Copy usage right.
45 having the new version. He cannot upgrade more than once
Demo Versions
because the ticket cannot work after it has been punched. If
desired, the repository can record the upgrade transaction by
A creator believes that if people try his work that they will
want to buy it or use it. Consumers of his work can copy the
posting a zero cost bill to alert the creator that the upgrade
work for free, and play (or execute) a limited version of the
has taken place.
work for free, and can play or use the full featured version 50 Limited Printing
A consumer buys a digital work and wants to make a few
for a fee.
ephemeral copies. For example, he may want to print out a
This scenario deals with fees for loaning rather than fees
paper copy of part of a digital newspaper, or he may want to
for making copies. The fees are collected by the same
automatic mechanisms.
make a (first generation) analog cassette tape for playing in
This scenario is performed as follows:
55 his car. He buys the digital work together with a ticket
The creator creates a digital work and grants various rights
required for printing rights.
and fees. The creator grants Copy and Embed rights without
This scenario is like the common practice of people
a fee, in order to ensure widespread distribution of the work.
making cassette tapes to play in their car. If a publisher
Another of the rights is a limited play right with little or no
permits the making of cassette tapes, there is nothing to
fee attached. For example, this right may be for playing only 60 prevent a consumer from further copying the tapes.
a portion of the work. The play right can have various
However, since the tapes are "analog copies," there is a
restrictions on its use. It could have a ticket that limits the
noticeable quality loss with subsequent generations. The
number of times it is used. It could have internal restrictions
new contribution of the present invention is the use of tickets
that limit its functionality. It could have time restrictions that
in the access controls for the making of the analog copies.
invalidate the right after a period of time or a period of use. 65
This scenario is performed as follows:
The creator sells a work together with limited printing
Different fees could be associated with other versions of the
rights. The printing rights specify the kind of printer (e.g., a
Play right.
Case 2:13-cv-01112 Document 1-3 Filed 12/18/13 Page 41 of 45 PageID #: 112
US 6,963,859 B2
47
48
kind of cassette recorder or a kind of desktop paper printer)
Rational Database Usage Charges
and also the kind of ticket required. The creator either
Online information retrieval services typically charge for
bundles a limited number of tickets or sells them separately.
access in a way that most clients find unpredictable and
If the tickets use the generic ticket agent, the consumer with
uncorrelated to value or information use. The fee depends on
the tickets can exercise the right at his convenience.
5 which databases are open, dial-up connect time, how long
the searches require, and which articles are printed out.
Demand Publishing
There are no provisions for extracting articles or
Professors in a business school want to put together
photographs, no method for paying to reuse information in
course books of readings selected from scenario studies
new works, no distinction between having the terminal sit
from various sources. The bookstore wants to be able to print
the books from digital masters, without negotiating for and 10 idly versus actively searching for data, no distinction
between reading articles on the screen and doing nothing,
waiting for approval of printing of each of the scenarios. The
and higher rates per search when the centralized facility is
copyright holders of the scenarios want to be sure that they
busy and slow servicing other clients. Articles can not be
are paid for every copy of their work that is printed.
ofiloaded to the client's machine for off-site search and
On many college campuses, the hassle of obtaining copy
clearances in a timely way has greatly reduced the viability 15 printing. To offer such billing or the expanded services, the
service company would need a secure way to account for
of preparing course books. Print shops have become much
and bill for how information is used.
more cautious about copying works in the absence of
This scenario is performed as follows:
documented permission.
The information service bundles its database as files in a
Demand Publishing is performed as follows: the creator
20 repository. The information services company assigns difsells a work together with printing rights for a fee. There can
ferent fees for different rights on the information files. For
be rights to copy (distribute) the work between bookstore
example, there could be a fee for copying a search database
repositories, with or without fee. The printing rights specify
or a source file and a different fee for printing. These fees
the kind of printer. Whenever a bookstore prints one of the
would
be in addition to fees assigned by the original creator
works (either standalone or embedded in a collection), the
fee is credited to the creator automatically. To discourage 25 for the services. The fees for using information would be
different for using them on the information service compaunauthorized copying of the print outs, it would be possible
ny's computers or the client's computers. This billing disfor the printer to print tracer messages discretely on the
tinction
would be controlled by having different versions of
pages identifying the printing transaction, the copy number,
the rights, where the version for use on the service compaand any other identifying information. The tracer information could be secretly embedded in the text itself (encoded 30 ny's computer requires a digital certificate held locally. Fees
for copying or printing files would be handled in the usual
in the grey scale) or hidden in some other way.
way, by assigning fees to exercising those rights. The
Metered Use and Multiple Price Packages
distinction between searching and viewing information
A consumer does not know what music to purchase until
would be made by having different "players" for the differhe decides whether he likes it. He would like to be able to 35 ent functions. This distinction would be maintained on the
take it home and listen to it, and then decide whether to
client's computers as well as the service computers. Articles
purchase. Furthermore, he would like the flexibility of
could be extracted for reuse under the control of Extract and
paying less if he listens to it very infrequently.
Embed rights. Thus, if a client extracts part of an article or
This scenario just uses the capability of the approach to
photograph, and then sells copies of a new digital work
have multiple versions of a right on a digital work. Each 40 incorporating it, fees could automatically be collected both
version of the right has its own billing scheme. In this
by the information service and earlier creators and distribuscenario, the creator of the work can offer the Copy right
tors of the digital work. In this way, the information retrieval
without fee, and defer billing to the exercise of the Play
service could both offer a wider selection of services and
right. One version of the play right would allow a limited
billing that more accurately reflects the client's use of the
performance without fee-a right to "demo". Another ver- 45 information.
sian of the right could have a metered rate, of say $0.25 per
Print Spooling with Rights
hour of play. Another version could have a fee of $15.00 for
In the simplest scenario, when a user wants to print a
the first play, but no fee for further playing. When the
digital document he issues a print command to the user
consumer exercises a play right, he specifies which version
interface. If the document has the appropriate rights and the
of the right is being selected and is billed accordingly.
50 conditions are satisfied, the user agrees to the fee and the
Fees for Font Usage
document is printed. In other cases, the printer may be on a
A designer of type fonts invests several months in the
remote repository and it is convenient to spool the printing
design of special fonts. The most common way of obtaining
to a later time. This leads to several issues. The user
revenue for this work is to sell copies of the fonts to
requesting the printing wants to be sure that he is not billed
publishers for unlimited use over unlimited periods of time. 55 for the printing until the document is actually printed.
A font designer would like to charge a rate that reflects the
Restated, if he is billed at the time the print job is spooled
amount that the font is used.
but the job is canceled before printing is done, he does not
This scenario is performed as follows: the font designer
want to pay. Another issue is that when spooling is
creates a font as a digital work. He creates versions of the
permitted, there are now two times at which rights, condiPlay right that bill either for metered use or "per-use". Each 60 tions and fees could be checked: the time at which a print job
is spooled and the time at which a print is made. As with all
version of the play right would require that the player (a
print layout program) be of an approved category. The font
usage rights, it is possible to have rights that expire and to
designer assigns appropriate fees to exercise the Copy right.
have rights whose fee depends on various conditions. What
When a publisher client wants to use a font, he includes it
is needed is a means to check rights and conditions at the
as input to a layout program, and is billed automatically for 65 time that printing is actually done.
This scenario is performed as follows: A printing reposiits use. In this way, a publisher who makes little use of a font
tory is a repository with the usual repository characteristics
pays less than one who uses it a lot.
Case 2:13-cv-01112 Document 1-3 Filed 12/18/13 Page 42 of 45 PageID #: 113
US 6,963,859 B2
49
50
plus the hardware and software to enable printing. Suppose
Description Tree:
that a user logs into a home repository and wants to spool
A structure which describes the location of content and
print jobs for a digital work at a remote printing repository.
the usage rights and usage fees for a digital work. A
The user interface for this could treat this as a request to
description tree is comprised of description blocks. Each
"spool" prints. Underneath this "spooling" request, 5 description block corresponds to a digital work or to an
interest (typically a revenue bearing interest) in a digital
however, are standard rights and requests. To support such
work.
requests, the creator of the work provides a Copy right,
Digital Work (Work):
which can be used to copy the work to a printing repository.
Any encapsulated digital information. Such digital inforIn the default case, this Copy right would have no fees
associated for making the copy. However, the Next-Set-Of- 10 mation may represent music, a magazine or book, or a
Rights for the copy would only include the Print rights, with
multimedia composition. Usage rights and fees are attached
to the digital work.
the usual fees for each variation of printing. This version of
the Copy right could be called the "print spooling" version
Distributor:
of the Copy right. The user's "spool request" is implemented
A term which refers to a party who legitimately obtains a
as a Copy transaction to put a copy of the work on the 15 copy of a digital work and offers it for sale.
Identification (Digital) Certificate:
printing repository, followed by Print transactions to create
A signed digital message that attests to the identity of the
the prints of the work. In this way, the user is only billed for
printing that is actually done. Furthermore, the rights, conpossessor. Typically, digital certificates are encrypted in the
ditions and fees for printing the work are determined when
private key of a well-known master repository.
the work is about to be printed.
20 Master Repository:
Thus, a system for enforcing the usage rights of digital
A special type of repository which issues identification
works is disclosed. While the embodiments disclosed herein
certificates and distributes lists of repositories whose integare preferred, it will be appreciate from this teaching that
rity have been compromised and which should be denied
various alternative, modifications, variations or improveaccess to digital works (referred to as repository "hotlists".)
ments therein may be made by those skilled in the art, which 25 Public Key Encryption:
are intended to be encompassed by the following claims.
A encryption technique used for secure transmission of
messages on a communication channel. Key pairs are used
Appendix A
for the encryption and decryption of messages. Typically
one key is referred to as the public key and the other is the
Glossary
30 private key. The keys are inverses of each other from the
Authorization Repository:
perspective of encryption. Restated, a digital work that is
A special type of repository which provides authorization
encryption by one key in the pair can be decrypted only by
service. An authorization may be specified by a usage right.
the other.
The authorization must be obtained before the right may be
Registration Transactions:
exercised.
35
The protocol used between repositories to established a
Billing Clearinghouse:
trusted session.
A financial institution or the like whose purpose is to
Rendering Repository:
reconcile billing information received from credit servers.
A special type of repository which is typically coupled to
The billing clearinghouse may generate bills to users or
a
rendering
system. The rendering repository will be typialternatively, credit and debit accounts involved in the
40 cally be embodied within the secure boundaries of a rencommercial transactions.
dering system.
Billing Transactions:
Rendering System:
The protocal used by which a repository reports billing
The combination of a rendering repository and a renderinformation to a credit server.
45 ing device. Examples of rendering systems include printing
Clearinghouse Transactions:
systems, displaying systems, general purpose computer
The protocal used between a credit server and a clearingsystems, video systems or audio systems.
house.
Repository:
Composite Digital Work:
Conceptually a set of functional specifications defining
A digital work comprised of distinguishable parts. Each of
the distinguishable parts is itself a digital work which have 50 core functionality in the support of usage rights. A repository
is a trusted system in that it maintains physical, communiusage rights attached.
cations and behavioral integrity.
Content:
Requester Mode:
The digital information (i.e. raw bits) representing a
A mode of repository where it is requesting access to a
digital work.
Copy Owner:
55 digital work.
Revenue Owners:
A term which refers to the party who owns a digital work
stored in a repository. In the typical case, this party has
A term which refers to the parties that maintain an interest
purchased various rights to the document for printing,
in collecting fees for document use or who stand to lose
revenue if illegitimate copies of the digital work are made.
viewing, transferring, or specific uses.
Creator:
60 Server Mode:
A term which refers to a party who produces a digital
A mode of a repository where it is processing an incoming
work.
request to access a digital work.
Credit Server:
Shell Description Block:
A special type of description block designating an interest
A device which collects and reports billing information
for a repository. In many implementations, this could be 65 in a digital work, but which does not add content. This will
typically be added by a distributor of a digital work to add
built as part of a repository. It requires a means for periodically communicating with a billing clearinghouse.
their fees.
Case 2:13-cv-01112 Document 1-3 Filed 12/18/13 Page 43 of 45 PageID #: 114
US 6,963,859 B2
51
52
Transactions:
15. A rendering system as recited in claim 1 wherein said
A term used to refer to the protocols by which repositories
rendering device comprises a computer system and said
communicate.
repository comprises software executed on the computer
Usage Fees:
system.
16. A rendering system as recited in claim 1, further
A fee charged to a requester for access to a digital work. 5
comprising an execution device coupled to said repository,
Usage fees are specified within the usage rights language.
Usage Rights:
said repository being further operative to permit said execution device to execute a computer program only in a manner
A language for defining the manner in which a digital
work may be used or distributed, as well as any conditions
specified by the usage rights.
10
17. A rendering system as recited in claim 1, wherein the
on which use or distribution is premised.
content is a computer program and the manner of use is a
Usage Transactions:
manner of executing the computer program.
A set of protocols by which repositories communicate in
18. A rendering system as recited in claim 1, wherein the
the exercise of a usage rights. Each usage right has it's own
transaction steps.
manner of use is a manner of printing.
15
19. A rendering system as recited in claim 1, wherein the
What is claimed is:
manner of use is a manner of displaying.
1. A rendering system adapted for use in a distributed
system for managing use of content, said rendering system
20. A rendering system as recited in claim 1, wherein the
being operative to rendering content in accordance with
manner of use is a manner of playing.
usage rights associated with the content, said rendering
21. A rendering system as recited in claim 1, wherein the
system comprising:
20 rendering device and the repository are integrated into a
secure system having a secure boundary.
a rendering device configured to render the content; and
22. A rendering system as recited in claim 1, wherein the
a distributed repository coupled to said rendering device
rendering device and the repository are separate devices.
and including a requester mode of operation and server
23. A rendering system as recited in claim 1, wherein the
mode of operation,
25 usage rights include at least one condition that must be
wherein the server mode of operation is operative to
satisfied to exercise the manner of use, and wherein the
enforce usage rights associated with the content and
system further comprises means for communicating with an
permit the rendering device to render the content in
authorization repository for authorizing a condition.
accordance with a manner of use specified by the usage
24. A rendering system as recited in claim 1, further
rights,
30 comprising means for communicating with a master reposithe requester mode of operation is operative to request
tory for obtaining an identification certificate for the reposiaccess to content from another distributed repository,
tory.
and
25. A rendering system as recited in claim 1, further
comprising a boundary containing said repository and said
said distributed repository is operative to receive a request
to render the content and permit the content to be 35 rendering device in a secure environment.
rendered only if a manner of use specified in the request
26. A rendering system as recited in claim 23, wherein the
corresponds to a manner of use specified in the usage
condition is possession of a digital ticket.
rights.
27. A rendering as recited in claim 1, wherein the content
has plural components having usage lights associated there2. A rendering system as recited in claim 1, wherein said
rendering device is configured to render content into a 40 with and wherein said repository enforces the usage rights
for each component.
desired form.
3. A rendering system as recited in claim 1, wherein said
28. A rendering system as recited in claim 1, wherein said
repository comprises means for storing the content.
system is implemented using one or more hardware and/or
4. A rendering system as recited in claim 3 wherein said
software devices.
29. A rendering method adapted for use in a distributed
means for storing is means for storing ephemeral copies of 45
the content.
system for managing use of content, and operative to render
5. A rendering system as recited in claim 3 wherein said
content in accordance with usage rights associated with the
means for storing comprises means for storing content after
content, said method comprising:
rendering.
configuring a rendering device to render the content;
6. A rendering system as recited in claim 5 wherein the 50
configuring a distributed repository coupled to said rencontent comprises fonts.
dering device to include a requester mode of operation
7. A rendering system as recited in claim 5 wherein the
and server mode of operation;
content comprises music.
enforcing
usage rights associated with the content and
8. A rendering system as recited in claim 5 wherein the
permitting
the rendering device to render the content in
55
content comprises video.
accordance with a manner of use specified by the usage
9. A rendering system as recited in claim 3, wherein said
rights, when in the server mode of operation;
repository comprises removable media.
requesting access to content from another distributed
10. A rendering system as recited in claim 1, further
repository, when in the requester mode of operation;
comprising means for storing the content.
and
11. A rendering system as recited in claim 10, wherein 60
said means for storing comprises removable media.
receiving by said distributed repository a request to render
12. A rendering system as recited in claim 1 wherein said
the content and permitting the content to be rendered
rendering device comprises a printer.
only if a manner of use specified in the request corresponds to a manner of use specified in the usage rights.
13. A rendering system as recited in claim 1, wherein said
65
30. A rendering method as recited in claim 29, wherein
rendering device comprises a video system.
14. A rendering system as recited in claim 1, wherein said
said rendering device is configured to render content into a
rendering device comprises an audio system.
desired form.
Case 2:13-cv-01112 Document 1-3 Filed 12/18/13 Page 44 of 45 PageID #: 115
US 6,963,859 B2
53
31. A rendering method as recited in claim 29, wherein
54
57. A rendering method as recited in claim 29, wherein
said repository comprises means for storing the content.
said method is implemented using a computer readable
32. A rendering method as recited in claim 31, further
medium including one or more computer readable instruccomprising storing ephemeral copies of the content.
tions embedded therein and configured to cause one or more
33. A rendering method as recited in claim 31, wherein 5 computer processors to perform said method.
said means for storing comprises means for storing content
58. A computer readable medium including one or more
after rendering.
computer readable instructions embedded therein for use in
34. A rendering method as recited in claim 33, wherein the
a distributed system for managing use of content, and
content comprises fonts.
operative to render content in accordance with usage rights
35. A rendering method as recited in claim 33, wherein the
10 associated with the content, said computer readable instruccontent comprises music.
tions configured to cause one or more computer processors
36. A rendering method as recited in claim 33, wherein the
to perform the steps of:
content comprises video.
configuring a rendering device to render the content;
37. A rendering method as recited in claim 29, further
comprising storing the content.
configuring a distributed repository coupled to said ren38. A rendering method as recited in claim 37, wherein 15
dering device to include a requester mode of operation
said means for storing comprises removable media.
and server mode of operation;
39. A rendering method as recited in claim 29, wherein
enforcing usage rights associated with the content and
said rendering device comprises a printer.
permitting the rendering device to render the content in
40. A rendering method as recited in claim 29, wherein
accordance with a manner of use specified by the usage
20
said rendering device comprises a video system.
rights, when in the server mode of operation;
41. A rendering method as recited in claim 29, wherein
requesting access to content from another distributed
said rendering device comprises an audio system.
repository, when in the requester mode of operation;
42. A rendering method as recited in claim 29, wherein
said rendering device comprises a computer system and said
and
repository comprises software executed on the computer 25
receiving by said distributed repository a request to render
system.
the content and permitting the content to be rendered
43. A rendering method as recited in claim 29, further
only if a manner of use specified in the request correcomprising:
sponds to a manner of use specified in the usage rights.
coupling an execution device to said repository; and
59. A computer readable medium as recited in claim 58,
permitting by said repository said execution device to 30 wherein said rendering device is configured to render conexecute a computer program only in a manner specified
tent into a desired form.
by the usage rights.
60. A computer readable medium as recited in claim 58,
44. A rendering method as recited in claim 29, wherein the
wherein said repository comprises means for storing the
content is a computer program and the manner of use is a
content.
manner of executing the computer program.
35
61. A computer readable medium as recited in claim 60,
45. A rendering method as recited in claim 29, wherein the
wherein said computer readable instructions are configured
manner of use is a manner of printing.
to cause the one or more computer processors to perform the
46. A rendering method as recited in claim 29, wherein the
step of storing ephemeral copies of the content.
manner of use is a manner of displaying.
62. A computer readable medium as recited in claim 60,
47. A rendering method as recited in claim 29, wherein the
40 wherein said means for storing comprises means for storing
manner of use is a manner of playing.
content after rendering.
48. A rendering method as recited in claim 29, wherein the
63. A computer readable medium as recited in claim 62,
rendering device and the repository are integrated into a
wherein the content comprises fonts.
secure system having a secure boundary.
49. A rendering method as recited in claim 29, wherein the
64. A computer readable medium as recited in claim 62,
45 wherein the content comprises music.
rendering device and the repository are separate devices.
50. A rendering method as recited in claim 29, wherein the
65. A computer readable medium as recited in claim 62,
wherein the content comprises video.
usage rights include at least one condition that must be
66. A computer readable medium as recited in claim 60,
satisfied to exercise the manner of use, and the method
wherein said repository comprises removable media.
further comprises communicating with an authorization
50
67. A computer readable medium as recited in claim 58,
repository for authorizing a condition.
51. A rendering method as recited in claim 29, further
wherein said computer readable instructions are configured
to cause the one or more computer processors to perform the
comprising communicating with a master repository for
step of storing the content.
obtaining an identification certificate for the repository.
52. A rendering method as recited in claim 29, further
68. A computer readable medium as recited in claim 58,
comprising configuring a boundary containing said reposi- 55 wherein said rendering device comprises a printer.
tory and said rendering device in a secure environment.
69. A computer readable medium as recited in claim 58,
53. A rendering method as recited in claim 50, wherein the
wherein said rendering device comprises a video system.
70. A computer readable medium as recited in claim 58,
condition is possession of a digital ticket.
54. A rendering method as recited in claim 29, wherein the
wherein said rendering device comprises an audio system.
71. A computer readable medium as recited in claim 58,
content has plural components having usage rights associ- 60
ated therewith and the method further comprises enforcing
wherein said rendering device comprises a computer system
by said repository the usage rights for each component.
and said repository comprises software executed on the
computer system.
55. A rendering method as recited in claim 31, wherein
72. A computer readable medium as recited in claim 58,
said repository comprises removable media.
56. A rendering method as recited in claim 29, wherein 65 wherein said computer readable instructions are configured
said method is implemented using one or more hardware
to cause the one or more computer processors to perform the
and/or software devices.
steps of:
Case 2:13-cv-01112 Document 1-3 Filed 12/18/13 Page 45 of 45 PageID #: 116
US 6,963,859 B2
55
56
coupling an execution device coupled to said repository;
communicating with an authorization repository for authoand
rizing a condition.
80. A computer readable medium as recited in claim 79,
permitting by said repository said execution device to
execute a computer program only in a manner specified
wherein the condition is possession of a digital ticket.
5
by the usage rights.
81. A computer readable medium as recited in claim 58,
73. A computer readable medium as recited in claim 58,
wherein said computer readable instructions are configured
wherein the content is a computer program and the manner
to cause the one or more computer processors to perform the
of use is a manner of executing the computer program.
step of communicating with a master repository for obtain74. A computer readable medium as recited in claim 58, 10 ing an identification certificate for the repository.
wherein the manner of use is a manner of printing.
82. A computer readable medium as recited in claim 58,
75. A computer readable medium as recited in claim 58,
wherein said computer readable instructions are configured
wherein the manner of use is a manner of displaying.
to cause the one or more computer processors to perform the
76. A computer readable medium as recited in claim 58,
step of configuring a boundary containing said repository
wherein the manner of use is a manner of playing.
and said rendering device in a secure environment.
77. A computer readable medium as recited in claim 58, 15
83. A computer readable medium as recited in claim 58,
wherein the rendering device and the repository are intewherein
the content has plural components having usage
grated into a secure system having a secure boundary.
rights associated therewith and said computer readable
78. A computer readable medium as recited in claim 58,
instructions are configured to cause the one or more comwherein the rendering device and the repository are separate
20 puter processors to perform the step of enforcing by said
devices.
repository the usage rights for each component.
79. A computer readable medium as recited in claim 58,
84. A computer readable medium as recited in claim 67,
wherein the usage rights include at least one condition that
wherein said means for storing comprises removable media.
must be satisfied to exercise the manner of use, and said
computer readable instructions are configured to cause the
one or more computer processors to perform the step of
* * * * *
Case 2:13-cv-01112 Document 1-4 Filed 12/18/13 Page 1 of 47 PageID #: 117
Exhibit D
Case 2:13-cv-01112 Document 1-4 Filed 12/18/13 Page 2 of 47 PageID #: 118
111111
1111111111111111111111111111111111111111111111111111111111111
US007523072B2
c12)
(54)
(75)
(73)
( *)
United States Patent
(10)
Stefik et al.
(45)
SYSTEM FOR CONTROLLING THE
DISTRIBUTION AND USE OF DIGITAL
WORKS
Notice:
(21)
Appl. No.: 11/304,794
(22)
Filed:
Prior Publication Data
Jul. 6, 2006
Related U.S. Application Data
(60)
Continuation of application No. 11/198,216, filed on
Aug. 8, 2005, which is a continuation of application
No. 10/176,608, filed on Jun. 24, 2002, now Pat. No.
6,934,693, which is a continuation of application No.
09/777,845, filed on Feb. 7, 2001, which is a division
of application No. 08/967,084, filed on Nov. 10, 1997,
now Pat. No. 6,236,971, which is a continuation of
application No. 08/344,760, filed on Nov. 23, 1994,
now abandoned.
(51)
Int. Cl.
H04K 1100
(2006.01)
H04L 9100
(2006.01)
U.S. Cl. ............................... 705/59; 705/1; 705/50;
705/51; 726/26; 726/27
Field of Classification Search ................... 705/51,
705/1, 50, 59; 726/26, 27
See application file for complete search history.
(52)
(58)
*Apr. 21, 2009
References Cited
3,263,158 A
7/1966 Bargen eta!.
(Continued)
FOREIGN PATENT DOCUMENTS
BR
9810967 A
10/2001
(Continued)
OTHER PUBLICATIONS
Henry H. Perritt, Jr, Knowbots, Permissions Headers and Contract
Law, Apr. 30, 1993, Villanova Law School, pp. 1-24, http://www.ifla.
org/documents/infopol/copyrightlperh2.txt. *
(Continued)
Dec.16, 2005
US 2006/0149680Al
US 7,523,072 B2
U.S. PATENT DOCUMENTS
Subject to any disclaimer, the term of this
patent is extended or adjusted under 35
U.S.C. 154(b) by 0 days.
This patent is subject to a terminal disclaimer.
(65)
(56)
Inventors: Mark J. Stefik, Portola Valley, CA (US);
Peter L. T. Pirolli, San Francisco, CA
(US)
Assignee: Contentguard Holdings, Inc.,
Wilmington, DE (US)
Patent No.:
Date of Patent:
Primary Examiner-Andrew J. Fischer
Assistant Examiner-Joshua Murdaugh
(74) Attorney, Agent, or Firm-Marc S. Kaufman; Stephen
M. Hertzler; Nixon Peabody, LLP
(57)
ABSTRACT
A method, system and software for securely rendering digital
documents, including storing a digital document in a document platform; and storing a usage right associated with the
digital document. The usage right specifies a manner of use
indicating the manner in which the digital document can be
rendered by the document platform. The digital document
comprises plural parts of digital content. The usage right
includes plural usage rights respectively associated with each
of the plural parts of digital content. Whether one of the parts
of the digital document may be rendered by the document
platform is determined based a respective usage right. If the
respective usage right allows the digital document to be rendered on the document platform, the corresponding part of the
digital document is rendered by the document platform.
25 Claims, 13 Drawing Sheets
Case 2:13-cv-01112 Document 1-4 Filed 12/18/13 Page 3 of 47 PageID #: 119
US 7,523,072 B2
Page 2
U.S. PATENT DOCUMENTS
3,609,697
3,790,700
3,798,605
4,159,468
4,200,700
4,220,991
4,278,837
4,323,921
4,361,851
4,423,287
4,429,385
4,442,486
4,529,870
4,558,176
4,593,376
4,614,861
4,621,321
4,644,493
4,658,093
4,713,753
4,736,422
4,740,890
4,796,220
4,816,655
4,817,140
4,827,508
4,868,376
4,882,752
4,888,638
4,891,838
4,924,378
4,932,054
4,937,863
4,949,187
4,953,209
4,961,142
4,975,647
4,977,594
4,999,806
5,010,571
5,014,234
5,023,907
5,047,928
5,050,213
5,052,040
5,058,164
5,103,476
5,113,519
5,129,083
5,136,643
5,138,712
5,146,499
5,148,481
5,159,182
5,174,641
5,183,404
5,191,193
5,204,897
5,222,134
5,224,163
5,235,642
5,247,575
5,255,106
5,260,999
5,263,157
5,263,158
5,276,444
5,276,735
5,287,408
5,291,596
5,293,422
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
9/1971
2/1974
3/1974
6/1979
4/1980
9/1980
7/1981
4/1982
1111982
12/1983
111984
4/1984
7/1985
12/1985
6/1986
9/1986
1111986
2/1987
4/1987
12/1987
4/1988
4/1988
111989
3/1989
3/1989
5/1989
9/1989
1111989
12/1989
111990
5/1990
6/1990
6/1990
8/1990
8/1990
10/1990
12/1990
12/1990
3/1991
4/1991
5/1991
6/1991
9/1991
9/1991
9/1991
10/1991
4/1992
5/1992
7/1992
8/1992
8/1992
9/1992
9/1992
10/1992
12/1992
2/1993
3/1993
4/1993
6/1993
6/1993
8/1993
9/1993
10/1993
1111993
1111993
1111993
111994
111994
2/1994
3/1994
3/1994
Blevins et al.
Callais eta!.
Feistel
Barnes eta!.
Mader
Hamano eta!.
Best
Guillou
Asip et al.
Zeidler
Cichelli eta!.
Mayer
Chaurn
Arnold eta!.
Yolk
Pavlov eta!.
Boebert et a!.
Chandra et a!.
Hellman
Beo bert et a!.
Mason
William
Wolfe
Musycket a!.
Chandra et a!.
Shear
Lessin et al.
Lindman et a!.
Bohn
Faber
Hershey et a!.
Chou eta!.
Robert eta!.
Cohen
Ryder, Sr. eta!.
Elliott et a!.
Downer eta!.
Shear
Chernow et a!.
Katznelson
Edwards, Jr.
Johnson et a!.
Wiedemer
Shear
Preston et al.
Elmer eta!.
Waite et al.
Johnson et a!.
Cutler eta!.
Fischer
Corbin
Geffrotin
Abraham et al.
Eisele
Lim
Aldous eta!.
LeRoux
Wyman
Waite et al.
Gasser eta!.
Wobber eta!.
Sprague et a!.
Castro
Wyman
Janis
Janis
McNair
Boebert et a!.
Samson
Mita
Loiacono
5,299,263
5,301,231
5,311,591
5,319,705
5,335,275
5,337,357
5,339,091
5,341,429
5,347,579
5,381,526
5,386,369
5,390,297
5,394,469
5,410,598
5,412,717
5,414,852
5,428,606
5,432,849
5,438,508
5,444,779
5,453,601
5,455,953
5,457,746
5,473,687
5,473,692
5,485,577
5,499,298
5,502,766
5,504,814
5,504,816
5,504,818
5,504,837
5,509,070
5,530,235
5,532,920
5,534,975
5,535,276
5,539,735
5,553,143
5,557,678
5,563,946
5,564,038
5,568,552
5,619,570
5,621,797
5,625,690
5,629,980
5,633,932
5,634,012
5,636,346
5,638,443
5,638,494
5,638,513
5,649,013
5,655,077
5,708,709
5,708,717
5,715,403
5,724,425
5,734,823
5,734,891
5,737,413
5,737,416
5,745,569
5,745,879
5,748,783
5,757,907
5,761,686
5,764,807
5,765,152
5,768,426
5,787,172
5,790,677
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
3/1994
4/1994
5/1994
6/1994
8/1994
8/1994
8/1994
8/1994
9/1994
111995
111995
2/1995
2/1995
4/1995
5/1995
5/1995
6/1995
7/1995
8/1995
8/1995
9/1995
10/1995
10/1995
12/1995
12/1995
111996
3/1996
3/1996
4/1996
4/1996
4/1996
4/1996
4/1996
6/1996
7/1996
7/1996
7/1996
7/1996
9/1996
9/1996
10/1996
10/1996
10/1996
4/1997
4/1997
4/1997
5/1997
5/1997
5/1997
6/1997
6/1997
6/1997
6/1997
7/1997
8/1997
111998
111998
2/1998
3/1998
3/1998
3/1998
4/1998
4/1998
4/1998
4/1998
5/1998
5/1998
6/1998
6/1998
6/1998
6/1998
7/1998
8/1998
Beller eta!.
Abraham et a!.
Fischer
Halter et al.
Millar eta!.
Chou et al.
Yamazaki et a!.
Stringer et a!.
Blandford
Elison
Christiano
Barber eta!.
Nagel eta!.
Shear
Fischer
Kramer eta!.
Moskowitz
Johnson et al.
Wyman
Daniele
Rosen
Russell
Dolphin
Lipscomb et al.
Davis
Eyer eta!.
Narasirnhalu et al.
Boebert et a!.
Miyahara
Hamilton et a!.
Okano
Griffeth et a!.
Schull
Stefik eta!.
Hartrick et a!.
Stefik eta!.
Ganesan
Moskowitz
Ross eta!.
Ganesan
Cooper et al.
Grantz eta!.
Davis
Tsutsui
Rosen
Michel eta!.
Stefik eta!.
Davis et al.
Stefik eta!.
Saxe
Stefik eta!.
Pinard eta!.
Ananda
Stuckey et a!.
Jones eta!.
Rose
Alasia
Stefik
Chang eta!.
Saigh eta!.
Saigh
Akiyama et al.
Cooper et al.
Moskowitz et a!.
Wyman
Rhoads
Cooper et al.
Bloomberg
Pearlman et a!.
Erickson
Rhoads
Arnold
Fox eta!.
Case 2:13-cv-01112 Document 1-4 Filed 12/18/13 Page 4 of 47 PageID #: 120
US 7,523,072 B2
Page 3
5,812,664
5,825,876
5,825,879
5,825,892
5,838,792
5,848,154
5,848,378
5,850,443
5,892,900
5,910,987
5,915,019
5,917,912
5,920,861
5,933,498
5,940,504
5,943,422
5,949,876
5,982,891
5,987,134
5,999,624
5,999,949
6,006,332
6,020,882
6,047,067
6,073,234
6,091,777
6,112,181
6,112,239
6,115,471
6,135,646
6,138,119
6,141,754
6,157,719
6,157,721
6,169,976
6,185,683
6,189,037
6,189,146
6,209,092
6,216,112
6,219,652
6,226,618
6,233,684
6,236,971
6,237,786
6,240,185
6,253,193
6,266,618
6,292,569
6,301,660
6,307,939
6,327,652
6,330,670
6,345,256
6,353,888
6,363,488
6,389,402
6,397,333
6,401,211
6,405,369
6,424,717
6,424,947
6,487,659
6,516,052
6,516,413
6,523,745
6,796,555
7,130,087
200110009026
200110011276
200110014206
200110037467
200110039659
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A *
A
A
A
A
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B2
B1
B1
B1
B2 *
A1
A1
A1
A1
A1
9/1998
10/1998
10/1998
10/1998
1111998
12/1998
12/1998
12/1998
4/1999
6/1999
6/1999
6/1999
7/1999
8/1999
8/1999
8/1999
9/1999
1111999
1111999
12/1999
12/1999
12/1999
212000
4/2000
6/2000
7/2000
8/2000
8/2000
9/2000
10/2000
10/2000
10/2000
12/2000
12/2000
112001
2/2001
2/2001
2/2001
3/2001
4/2001
4/2001
5/2001
5/2001
5/2001
5/2001
5/2001
6/2001
7/2001
9/2001
10/2001
10/2001
12/2001
12/2001
212002
3/2002
3/2002
5/2002
5/2002
6/2002
6/2002
7/2002
7/2002
1112002
2/2003
2/2003
2/2003
9/2004
10/2006
7/2001
8/2001
8/2001
1112001
1112001
Bernobich et a!.
Peterson
Davis
Braudaway et a!.
Ganesan
Nishio eta!.
Shelton et a!.
Van Oorschot et al.
Ginter et al.
Ginter et al.
Ginter et al.
Ginter et al.
Hallet a!.
Schneck et a!.
Griswold
VanWie eta!.
Ginter et al.
Ginter et al.
Shin eta!.
Hopkins
Crandall
Rabne et al.
Kinghorn et a!.
Rosen
Kigo eta!.
Guetz eta!.
Shear eta!.
Kenner eta!.
Oki et al.
Kahnet a!. ................. 709/217
Hallet a!.
Choy
Wasilewski eta!.
Shear eta!.
Colosso
Ginter et al.
Adams eta!.
Misra eta!.
Linnartz
Fuller eta!.
Carteret a!.
Downs eta!.
Stefik eta!.
Stefik eta!.
Ginter et al.
VanWie eta!.
Ginter et al.
Ye eta!.
Shear eta!.
Benson
Vigarie
England et al.
England et al.
Milsted eta!.
Kakehi eta!.
Ginter et al.
Ginter et al.
Sohne eta!.
Brezak, Jr. eta!.
Tsuria
Pinder et al.
T suria et al.
Kigo eta!.
Voudouris
Aratani et a!.
Tamori
Blahut
Rhoads ...................... 358/3.28
Terao eta!.
Durst Jr. et a!.
Arti galas et al.
O'Toole, Jr. eta!.
Simmons eta!.
2002/0001387
2002/0035618
2002/0044658
2002/0056118
2002/0069282
2002/0099948
2002/0127423
2003/0097 567
2004/0052370
2004/0064692
2004/0172552
A1
A1
A1
A1
A1
A1
A1
A1
A1
A1
A1
1/2002
3/2002
4/2002
5/2002
6/2002
7/2002
9/2002
5/2003
3/2004
4/2004
9/2004
Dillon
Mendez et al.
Wasilewski eta!.
Hunter eta!.
Reisman
Kocher eta!.
Kayanakis
Terao eta!.
Katznelson
Kalm et al.
Boyles et al.
FOREIGN PATENT DOCUMENTS
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
GB
GB
GB
GB
GB
GB
GB
GB
JP
JP
JP
JP
JP
JP
JP
JP
JP
JP
JP
JP
JP
JP
JP
JP
JP
JP
JP
JP
JP
0 067 556
0084441
0 180 460
0 257 585
0 262 025
0 332 304
0 332 707
0 393 806
0 450 841
0 529 261
0 538 216
0 613 073
0 651 554
0 668 695
0 678 836
0 679 977
0 715 243
0 715 244
0 715 245
0 725 376
0731404
0 763 936
0 818 748
0 840 194
0 892 521
0 934 765
0 946 022
0 964 572
1 103 922
1483282
2022969
2 136 175
2 236 604
2236604
2309364
2316503
2354102
62-241061
64-068835
03-014109
3063717
04-369068
5100939
5168039
5-268415
05-298174
06-103286
6131371
6-175794
06-214862
6-215010
06-230847
06-318167
07-084852
07-200317
07-244639
0 715 241
11031130
B1
A2
A2
A2
A2
A2
A2
A1
A1
A1
A1
A1
A1
A1
A1
A2
A2
A2
A2
A1
A2
A1
A2
A
A
A
A
A
A
A2
A
A2
12/1982
7/1983
5/1986
3/1988
3/1988
9/1989
9/1989
10/1990
10/1991
3/1993
4/1993
8/1994
5/1995
8/1995
10/1995
1111995
6/1996
6/1996
6/1996
8/1996
9/1996
3/1997
111998
5/1998
111999
8/1999
9/1999
12/1999
5/2001
8/1977
12/1979
9/1984
4/1991
4/1991
7/1997
2/1998
3/2001
10/1987
3/1989
111991
3/1991
12/1992
4/1993
7/1993
10/1993
1111993
4/1994
5/1994
6/1994
8/1994
8/1994
8/1994
1111994
3/1995
8/1995
9/1995
6/1996
2/1999
Case 2:13-cv-01112 Document 1-4 Filed 12/18/13 Page 5 of 47 PageID #: 121
US 7,523,072 B2
Page 4
JP
JP
JP
JP
JP
JP
JP
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
11032037
11205306
11215121
2000215165
2005218143
2005253109
20060180562
WO 83/04461
wo 92/20022
WO 92/20022
wo 93/01550
WO 93/01550
WO 93/11480
wo 94/01821
WO 94/03003
WO 96/13814
wo 96/24092
WO 96/24092
WO 96/27155
WO 97/25800
WO 97/37492
WO 97/41661
WO 97/43761
wo 97/48203
WO 98/09209
WO 98/10561
wo 98/11690
WO 98/11690
WO 98/19431
wo 98/42098
WO 98/43426
WO 98/45768
WO 99/24928
WO 99/34553
WO 99/35782
WO 99/48296
wo 99/49615
WO 99/60461
WO 99/60750
WO 00/04727
WO 00/05898
WO 00/46994
WO 00/59152
WO 00/62260
W000/72118
WO 00/73922
WO 01103044
WO 01137209
wo 01163528
WO 2004/034223
wo 2004/103843
A2
A2
A2
A2
A2
A2
A2
A1
A1
A1
A1
A1
A1
A2
A2
A1
A1
A2
A2
A1
A1
A1
A1
A1
A1
A2
A1
A1
A1
A1
A2
A2
A2
A1
A2
A1
A1
A2
A1
A1
A2
2/1999
7/1999
8/1999
8/2000
8/2005
9/2005
7/2006
12/1983
1111992
1111992
111993
111993
6/1993
111994
2/1994
5/1996
8/1996
8/1996
9/1996
7/1997
10/1997
1111997
1111997
12/1997
3/1998
3/1998
3/1998
3/1998
5/1998
9/1998
10/1998
10/1998
5/1999
7/1999
7/1999
9/1999
9/1999
1111999
1111999
1/2000
212000
8/2000
10/2000
10/2000
1112000
12/2000
1/2001
5/2001
8/2001
4/2004
12/2004
OTHER PUBLICATIONS
Henry M. Levy, "Capability-Based Computer Systems",
Digital Press, 1984, P1-18 USA.
Kawahara Masaharu, "Consideration of a Method of Charging for Electronic Objects in Superdistribution", Technical
Report of the Institute of Electronics, Information and Communication Engineers, EIC Institute of Electronics, InformationandCommunicationEngineers, Sep. 21, 1994, Shingaku
Giho vol. 94 No. 240, p. 17-24 Japan-English Translation.
Ryoichi Mori et a!., "The Inevitable Way Toward
Superdistribution", Information Symposium Papers, Information Processing Society of Japan, Feb. 17, 1994, vol. 94,
No. 1, p. 67-76 Japan.
Shinichi Ueki et a!., "The Accounting Process in Software
Usage Monitor for Superdistribution", Information Processing Society of Japan Technical Report, 90-Is-27, Jan. 16,
1990, vol. 90, No. 1, p. 1-10 Japan English Translation.
Naoya Torii et a!., "System Architecture of Superdistribu-
tion", Technical Report of the Institute of Electronics, Information and Communication Engineers, EIC Institute ofElectronics, Information and Communication Engineers, Sep. 21,
1994, Shingaku Giho vol. 94 No. 240, p. 59-66 Japan.
Yasushi Kuho eta!., "Information Technology System Security for Open Distributed Computing Environment", The
Hitachi Hyoron, Nov. 1994, vol. 76, p. 49-52 Japan.
Hiroyoshi Takeda, "Function and Use of Workstation" The
Office Management, Nikkan Kogyo Shinbun, Aug. 1, 1989,
vol. 28, No. 8, p. 8-17 Japan.
Atsushi Iizawa, "Document Image Database System", Information Processing Society, May 15, 1992, vol. 33, No.5, p.
497-504 Japan.
"National Semiconductor and EPR Partner for Information
Metering/Data Security Cards" Mar. 4, 1994, Press Release
from Electronic Publishing Resources, Inc.
Weber, R., "Digital Rights Management Technology" Oct.
1995.
Flasche, U. eta!., "Decentralized Processing of Documents",
pp. 119-131, 1986, Comput. & Graphics, vol. 10, No.2.
Mori, R. et a!., "Superdistribution: The Concept and the
Architecture", pp. 1133-1146, 1990. The Transactions of the
IEICE, Vo. E 73, No. 7, Tokyo, JP.
Weber, R., "Metering Technologies for Digital Intellectual
Property", pp. 1-29, Oct. 1994, A Report to the International
Federation of Reproduction Rights Organizations.
Clark, P.C. et a!., "Bits: A Smartcard protected Operating
System", pp. 66-70 and 94, Nov. 1994, Communications of
theACM, vol. 37, No. 11.
Ross, P.E., "Data Guard", pp. 101, Jun. 6, 1994, Forbes.
Saigh, W.K., "Knowledge is Sacred", 1992, Video Pocket/
Page Reader Systems, Ltd.
Kahn, R.E., "Deposit, Registration and Recordation in an
Electronic Copyright Management System", pp. 1-19, Aug.
1992, Corporation for National Research Initiatives, Virginia.
Hilts, P. eta!., "Books While U Wait", pp. 48-50, Jan. 3, 1994,
Publishers Weekly.
Strattner, A, "Cash Register on a Chip may Revolutionaize
Software Pricing and Distribution; Wave Systems Corp.", pp.
1-3, Apr. 1994, Computer Shopper, vol. 14, No. 4, ISSN
0886-0556.
O'Conner, M., "New Distribution Option for Electronic Publishers; iOpener Data Encryption and Metering System for
CD-ROM use; Colunm", pp. 1-6, Mar. 1994, CD-ROM Professional, vol. 7, No.2, ISSN: 1409-0833.
Willett, S., "Metered PCs: Is Your System Watching You?
Wave System beta tests new technology", pp. 84, May 2,
1994, Info World.
Linn, R., "Copyright and Information Services in the Context
of the National Research and Education Network", pp. 9-20,
Jan. 1994, IMA Intellectual Property Project Proceedings,
vol. 1, Issue 1.
Perrit, Jr., H., "Permission Headers and Contract Law", pp.
27-48, Jan. 1994, IMA Intellectual Property Project Proceedings, vol. 1, Issue 1.
Upthegrove, L., "Intellectual Property Header Descriptors: A
Dynamic Approach", pp. 63-66, Jan. 1994, IMA Intellectual
Property Proceedings, vol. 1, Issue 1.
Sirbu, M., "Internet Billing Service Design and prototype
Implementation", pp. 67-80, Jan. 1994, IMA Intellectual
Property Project Proceedings, vol. 1, Issue 1.
Simmell, S. et a!., "Metering and Licensing of Resources:
Kala's General Purpose Approach", pp. 81-110, Jan. 1994,
IMA Intellectual Property Project Proceedings, vol. 1, Issue
1.
Case 2:13-cv-01112 Document 1-4 Filed 12/18/13 Page 6 of 47 PageID #: 122
US 7,523,072 B2
Page 5
Kahn, R., "Deposit, Registration and Recordation in an Electronic Copyright Management System", pp. 111-120, Jan.
1994, IMA Intellectual Property Project Proceedings, vol. 1,
Issue 1.
Tygar, J. eta!., "Dyad: A System for Using Physically Secure
Coprocessors", pp. 121-152, Jan. 1994, IMA Intellectual
Property Project Proceedings, vol. 1, Issue 1.
Griswold, G., "A Method for Protecting Copyright on Networks", pp. 169-178, Jan. 1994, IMA Intellectual Property
Project Proceedings, vol. 1, Issue 1.
Nelson, T., "A Publishing and Royalty Model for Networked
Documents", pp. 257-259, Jan. 1994, IMA Intellectual Property Project Proceedings, vol. 1, Issue 1.
Robinson, E., "Redefining Mobile Computing", pp. 238-240,
247-248 and 252, Jul. 1993, PC Computing.
Abadi, M. eta!., "Authentication and Delegation with Smartcards", pp. 1-24, 1990, Research Report DEC Systems
Research Center.
Mark Stefik, "Letting Loose the Light: Igniting Commerce in
Electronic Publication", pp. 219-253, 1996, Internet Dreams:
Archetypes, Myths, and Metaphors, IDSN 0-262-19373-6.
Mark Stefik, "Letting Loose the Light: Igniting Commerce in
Electronic Publication", pp. 2-35, Feb. 8, 1995, Internet
Dreams: Archetypes, Myths and Metaphors.
Henry H. Perritt, Jr., "Technological Strategies for Protecting
Intellectual Property in the Networked Multimedia Environment", Apr. 2-3, 1993, Knowbots, Permissions Headers &
Contact Law.
Perritt, Henry H.; Knowbots, Permissions Headers and Contract Law paper for conference on Technological Strategies
for Protecting Intellectual Property in the Networked Multimedia Environment, Apr. 2-3 1993, pp. 1-22.
European Search Report dated Sep. 8, 2004 in corresponding
European Application No. EP 03 015 128.6.
European Search Report dated Sep. 13, 2004 in corresponding European Application No. EP 03 015 127.8.
European Search Report for Corresponding European Application 95308422.5.
Blaze eta!, "Divertible Protocols and Atomic Proxy Cryptography" 1998 Advances in Cryptography-Euro Crypt International Conference on the Theory and Application ofCrypto
Techniques, Springer Verlag, DE.
Blaze et a!, "Atomic Proxy Cryptography" Draft (Online)
(Nov. 2, 1997) XP002239619 Retrieved from the Internet.
Cox, "Superdistribution" Wired Magazine (Sep. 1994),
XP002233405 URL:http:/ /www.wired.com/wiredlarchive/
2.09/ superdis_pr.html&gt.
Dunlop eta!, Telecommunications Engineering, pp. 346-352
(1984).
Elgamal, "A Public Key Cryptosystem and a Signature
Scheme Based on Discrete Logarithms," IEEE Transactions
on Information Theory IT-31 (4 ):469-4 72 (Jul. 1985).
Iannella, ed., Open Digital Rights Language (ODRL), pp.
1-31 (Nov. 21, 2000).
Kahle, wais.concepts.txt, Wide Area Information Server
Concepts, Thinking Machines Version 4, Draft, pp. 1-18
(Nov. 3, 1989).
Kahn, "Deposit, Registration and Recordation in an Electronic Copyright Management System" Technical Report,
Corporation for National Research Initiatives, Reston, Virginia (Aug. 1992) URL:http:/ I www.cni.org/docs/ima.ipworkshop/kahn.html.
Kahn eta!, "The Digital Library Project, vol. 1: The World of
Knowbots (Draft), An OpenArchitecture for a Digital Library
System and a Plan for its Development," Corporation for
National Research Initiatives, pp. 1-48 (Mar. 1988).
Kohl eta!, Network Working Group Request for Comments:
1510, pp. 1-112 (Sep. 1993).
Lee et a!, CDMA Systems Engineering Handbook (1998)
[excerpts but not all pages numbered].
Mambo et a!, "Protection of Data and Delegated Keys in
Digital Distribution," Information Security and Privacy. Second Australian Conference, ACISP '97 Proceedings, pp. 271282 (Sydney, NSW, Australia, Jul. 7-9, 1997, 1997 Berlin,
Germany, Springer-Verlag, Germany), XP008016393 ISBN:
3-540-63232-8.
Mambo et a!, "Proxy Cryptosystems: Delegation of the
Power to Decrypt Ciphertexts,", IEICE Trans. Fundamentals
vol. E80-A, No. 1:54-63 (Jan. 1997) XP00742245 ISSN:
0916-8508.
Microsoft Word, Users Guide, Version 6.0, pp. 487-489, 549555, 560-564, 572-575, 599-613, 616-631 (1993).
Ojanperii and Prasad, eds., Wideband CDMA for Third Generation Mobile Communications (1998) [excerpts but not all
pages numbered].
Perritt, "Knowbots, Permissions Headers and Contract Law,"
Paper for the Conference on Technological Strategies for
Protecting Intellectual Property in the Networked Multimedia Environment, pp. 1-22 (Apr. 2-3, 1993 with revisions of
Apr. 30, 1993).
Raggett, (Hewlett Packard), "HTML+(Hypertext markup
language)," pp. 1-31 (Jul. 12, 1993) URL:http:/ /citeseer.ist.
psu.edu/correct/340709.
Samuelson et a!, "Intellectual Property Rights for Digital
Library and Hypertext Publishing Systems: An Analysis of
Xanadu," Hypertext '91 Proceedings, pp. 39-50 (Dec. 1991).
No Author, "Softlock Services Introduces ... Softlock Services" Press Release (Jan. 28, 1994).
Ius Mentis, "The E!Gamal Public Key System," pp. 1-2 (Oct.
1, 2005) online at http:/ /www.iusmentis.com/technology/
encyrption/ elgamal/.
Microsoft Word User's Guide, pp. 773-774, 315-316, 487489, 561-564, 744, 624-633 (1993).
No Author, "What is the E!Gamal Cryptosystem," p. 1 (Nov.
27, 2006) online at http:/ /www.x5.net/faqs/crypto/q29.html.
Johnson eta!., "A Secure Distributed Capability Based System," ACM, pp. 392-402 (1985).
Wikipedia, "El Gamal Encryption," pp. 1-3 (last modified
Nov. 2, 2006) online at http:/ /en.wikipdeia.org/wiki/
E!Gamal_encryption.
Blaze, "Atomic Proxy Cryptography," p. 1 Abstract (Oct. 20,
1998).
Blaze, "Matt Blaze's Technical Papers," pp. 1-6 (last updated
Aug. 6, 2006).
Online Search Results for "inverted file", "inverted index"
from www.techweb.com, www.cryer.co.uk, computing-dictionary.thefreedictionary.com, www.nist.gov, en.wikipedia.
org, www.cni.org, www.tiscali.co.uk (Jul. 15-16, 2006).
Corporation for National Research Initiatives, "Digital
Object Architecture Project", http:/ /www.nnri.reston.va.us/
doa.html (updated Nov. 28, 2006).
Stefik, Summary and Analysis of A13 (Kahn, Robert E and
Vinton G Cerf, "The Digital Library Project, vol. 1: The
World ofKnowbots (Draft), An Open Architecture for a Digital Library System and a Plan for its Development," Corporation for National Research Initiatives (Mar. 1988)), pp. 1-25
(May 30, 2007).
Johnson eta!., "A Secure Distributed Capability Based System," Proceedings of the 1985 ACM Annual Conference on
Case 2:13-cv-01112 Document 1-4 Filed 12/18/13 Page 7 of 47 PageID #: 123
US 7,523,072 B2
Page 6
the Range of Computing: MID-SO's Perspective: MID-SO's
Perspective Association for Computing Machinery pp. 392402 (19S5).
Perritt, "Technologies Strategies for Protecting IP in the
Networked Multimedia Environment", Apr. 2-3, 1993,
Knowbot Permissions.
Delaigle, "Digital Watermarking", Spie Conference in Optical Security and Counterfeit Deterrence Techniques, San
Jose, CA Feb. 1996, vol. 2659 pp. 99-110.
Delaigle, "Digital Watermarking," Spie Conference in Optical Security and Counterfeit Detterence Techniques, San
Jose, CA (Feb. 1996).
Perritt, "Technologies Strategies for Protecting Intellectual
Property in the Networked Multimedia Environment,"
Knowbots, Permissions Headers and Contract Law (Apr. 2-3,
1993).
* cited by examiner
Case 2:13-cv-01112 Document 1-4 Filed 12/18/13 Page 8 of 47 PageID #: 124
U.S. Patent
Apr. 21, 2009
US 7,523,072 B2
Sheet 1 of 13
FIG. 1
Creator Creates A
Digital Work
~101
Usage Rights Attached To
Digital Work and
Deposited In Repository 1
~ 102
Repository 2 Initiates A
Session With Repository 1
Repository 2 Requests
Access To Digital Work For
A Stated Purpose
_.,-1 03
_.,-1 04
Repository 1 Checks Usage
Rights of Digital Work for
_.,-1 05
Determined If Access May
Be Granted
I
Access Denied
Repository 1
Terminates Session
with Error
~106
Access Granted
Repository 1 Transmits
Digital Work To
Repository 2
Repository 1 and 2 Each
Generate Billing
Information And Transmit
To Credit Server
Case 2:13-cv-01112 Document 1-4 Filed 12/18/13 Page 9 of 47 PageID #: 125
U.S. Patent
Apr. 21, 2009
US 7,523,072 B2
Sheet 2 of 13
FIG. 2
r---------------,
I
I
I
I
:
Master
: Repository
:
:
I
I
I
I
I
_..-~
204---' L-----
--, .... ---( _
'
--....
205'
I
I
I
I
Authorization
Repository
,
--- -----
---
l
J
----' ,-205
}-"'
--_..,205
I
I
.... /
I
I
I
..l...
I
' \I
I
I
I
I
I
I
I
I
I
I
\
,_ ....I
I
, -'-
' \I
I
Rendering
Repository
I
I
I
I
I
\
l 202
I
I
I
I
Repository
I
I
,_ ....I
I
I
l 203
l 201
FIG. 3
302'
I
I
I
I
I
Repository
I
\
..\....
' \I
I
I
I
' ,_ ....
I
I
___,..-- 301
Credit
Server
I
I
I
I
I
I
201
/
I
,.... .... --' ... .... ___
---
r
-
....
I
I
r--....
---
~-------
I
' \I /I
/
----- --- ----- ,
I
! Billing
_..,! Clearinghouse
303 --' :
'----------------
....
-304
Case 2:13-cv-01112 Document 1-4 Filed 12/18/13 Page 10 of 47 PageID #: 126
U.S. Patent
Apr. 21, 2009
US 7,523,072 B2
Sheet 3 of 13
FIG. 4A
r------------------------1
I
I
I
I
I
I
Printer
Repository
1
I
1
1
p~~~re
I
1
I
I
:
L402
L_____
L403 :
------------~-----~
\
'-- 401
Repository
._..,-- 404
FIG. 48
/
---410
,------------------------J-----------,
414
411
)
)
Credit
Server
412 "-Display
Engine
Display/
Execution Repository
_r-413
Execution
Engine
L-----------------
------------------~
Repository /
415
Case 2:13-cv-01112 Document 1-4 Filed 12/18/13 Page 11 of 47 PageID #: 127
U.S. Patent
Apr. 21, 2009
US 7,523,072 B2
Sheet 4 of 13
FIG. 5
40,000
20,000
0
10,000
30,000
80,000
60,000
50,000
70,000
I
I
I
90,000
Story A
Ad
Story B
Story C
)
510
)
511
)
512
~
513
FIG. 6
10,000
0
30,000
25,000
1,500
Text
Photo
Graphics
Sidebar
)
614
)
615
)
616
~
617
Case 2:13-cv-01112 Document 1-4 Filed 12/18/13 Page 12 of 47 PageID #: 128
U.S. Patent
Apr. 21, 2009
FIG. 7
v
Identifier
__./""
Length
700
~
701
v- 702
Starting Address
703
Rights Portion
v- 704
Parent Pointer
v
~
Child Pointer
<-----------''r- _
FIG. 8
US 7,523,072 B2
Sheet 5 of 13
Child Pointer
705
706
706
Top
d-block
821
d-block
(Story A)
d-block
(Ad)
d-block
(Story B)
d-block
(Story C)
822
823
824
d-block
(Graphics)
d-block
(Sidebar)
FIG. 9
925
d-block
(Text)
d-block
(Photo)
926
928
Case 2:13-cv-01112 Document 1-4 Filed 12/18/13 Page 13 of 47 PageID #: 129
U.S. Patent
Apr. 21, 2009
Sheet 6 of 13
US 7,523,072 B2
FIG. 10
Right
Code
Status
lnfonnation
f
1050
1052
f
FIG. 14
Right
Transactional
Component
Specification
Component
Copy Count
1453
1454
Fees /Incentives
Time
Control
1455
1457
Access
1456
Case 2:13-cv-01112 Document 1-4 Filed 12/18/13 Page 14 of 47 PageID #: 130
U.S. Patent
Apr. 21, 2009
US 7,523,072 B2
Sheet 7 of 13
FIG. 11
Identifier {Magazine)
Starting Address {0)
Length {100,000)
Rights Portion
(PRINT, VIEW)
root
d-block
1101
....,/
Parent Pointer
Child Pointers
t
l
t
l
Identifier {Article 1)
Identifier (Article 2)
Starting Address {0)
Starting Address {25,001)
Length (25,000)
Length (25,000)
Rights Portion
(PRINT, VIEW)
Rights Portion
{PRINT, VIEW)
Parent Pointer
Parent Pointer
Child Pointers
Child Pointers
t_ d-block
1102
!
!
d-block_)
1105
Identifier (Artide 3)
Identifier (Article 4)
Starting Address (50,001)
Starting Address (75,001)
Length (25,000)
Length (25,000)
Rights Portion
{VIEW)
Rights Portion
{PRINT (Fee))
Parent Pointer
Parent Pointer
Child Pointers
Child Pointers
d-block_)
1103
d-block _)
1104
Case 2:13-cv-01112 Document 1-4 Filed 12/18/13 Page 15 of 47 PageID #: 131
U.S. Patent
Apr. 21, 2009
US 7,523,072 B2
Sheet 8 of 13
FIG. 12
_...-1200
r-----------------~l
~I--~
I
I
Clock
I
~~I
I
I
I
I
~~~
I
L_
~
1205
~~--~
I
_J
T [ 1202 ___ 12o1
1 _______ 1___ -----~l
1201
I
:
1203
I
External
Interface
\
12o6
I
Descriptor
Storage
Content
Storage
I
L ___________________ j
:
1204
I
I
FIG. 13
User
Interface
Repository Specific
Software
Function I Services
Usage Transaction
Handlers
Core Repository
Services I Transaction
Handling
~1305
~1304
~1303
""
1302
Operating
System
~1301
Identification
Certificates
v-
~306
Case 2:13-cv-01112 Document 1-4 Filed 12/18/13 Page 16 of 47 PageID #: 132
U.S. Patent
Apr. 21, 2009
Sheet 9 of 13
US 7,523,072 B2
FIG. 15
1501 - - Digital Work Rights: = (Rights*)
1502 - - Right: = (Right-Code {Copy-Count} {Control-spec} {Time-Spec}
{Access-Spec} (Fee-Spec})
1503-- Right-Code: = Render-Code 1 Transport-Code 1 File-ManagementCode Derivative-Works-Code I Configuration-Code
1504 - - Render-Code: = [Play: {Player: Player-ID} 1 Print: {Printer: Printer-ID}]
1505-- Transport-Code:= [Copy 1 Transfer I loan {Remaining-Rights:
Next-set-of-Rights}] {(Next-Copy-Rights: Next-Set-of-Rights)}
1506 - - File-Management-Code: = Backup {Back-Up-Copy-Rights:
Next-set-of-Rights} 1 Restore 1 Delete 1 Folder
1 Directory {Name: Hide-local I Hide-Remote}
{Parts: Hide-Local I Hide-Remote}
1507-- Derivative-Works-Code: = [Extract 1 Embed 1 Edit {Process:
Process-ID}] {Next-Copy-Rights:
Next-Set-of Rights}
1508 --Configuration-Code: = Install IUninstall
1509 - - Next-Set-of-Rights: = {(Add: Set-of-Rights)} {(Delete:
Set-of-Rights)} {(Replace: Set-of-Rights)} {(Keep: Set-of-Rights)}
151 0 --Copy-Count: = (Copies:positive-integer 1 0 1 Unlimited)
1511 --Control-Spec:= (Control: {Restrictable 1 Unrestrictable}
{Unchargeable Chargeable})
1512-- Time-Spec:= ({Fixed-Interval ISliding-Interval IMeter-Time}
Until: Expiration-Date)
1513 --Fixed-Interval:= From: Start-Time
1514 - - Sliding-Interval: = Interval : Use-Duration
1515 - - Meter-Time: = Time-Remaining: Remaining-Use
1516 --Access-Spec:= ({SC: Security-Class} {Authorization: Authorization-101
{Other-Authorization: Authorization-ID1 {Ticket: Ticket-ID})
1517 - - Fee-spec: = {Scheduled-Discount} Regular-Fee-Spec IScheduled-Fee-Spec I
Markup-Spec
1518 --Scheduled-Discount:= Scheduled-Discount: (Scheduled-Discount:
(Time-5pec Percentage)*)
1519 --Regular-Fee-Spec: =({Fee: I Incentive:} [Per-Use-Spec IMetered-RateSpec I Best-Price-Spec 1 Call-For-Price-Spec]
{Min: Money-Unit Per: Time-Spec} {Max:
Money-Unit Per: Time-5pec} To: Account-ID)
1520 - - Per-Use-Spec: = Per-Use: Money-Unit
1521 - - Metered-Rate-spec: = Metered: Money-Unit Per: Time-Spec
1522 - - Best-Price-Spec: = Best-Price: Money-unit Max: Money-Unit
1523 - - Call-For-Price-Spec:= Call-For-Price
1524 --Scheduled-Fee-Spec: = (Schedule: (Time-Spec Regular-Fee-Spec)*)
1525 - - Markup-Spec: = Mar1<up: percentage To: Account-10
1
Case 2:13-cv-01112 Document 1-4 Filed 12/18/13 Page 17 of 47 PageID #: 133
U.S. Patent
Apr. 21, 2009
Sheet 10 of 13
US 7,523,072 B2
Yes
Transmit Nonce
Repository-1
Terminate Transaction
1616
Repository-2
Terminate Transaction
Case 2:13-cv-01112 Document 1-4 Filed 12/18/13 Page 18 of 47 PageID #: 134
U.S. Patent
Apr. 21, 2009
Sheet 11 of 13
US 7,523,072 B2
FIG. 17
REPOSITORY-1
REPOSITORY-2
1701
1704
Decrypt Second Key
Create a Session Key Pair
1702
Encrypt Second Key Using
Public Key of Repository-2
1705
Generate Timestamp
Exchange Message
1706
1703
Transmit Encrypted Second
Key To Repository-2
Transmit Timestamp
Exchange Message
To Repository-1
Generate Timestamp
Message
1709
Transmit Timestamp
Message To Repository-2
Note Current Time
1711
Compare Current Time With
Time From Repository-1
No
1713
Terminate Transaction
1714
Compute Adjusted
Time Delta
Case 2:13-cv-01112 Document 1-4 Filed 12/18/13 Page 19 of 47 PageID #: 135
U.S. Patent
Apr. 21, 2009
US 7,523,072 B2
Sheet 12 of 13
FIG. 18
REQUESTER
SERVER
1801
Server Generates
Transaction Identifier
Tests Passed
1804
No
Tests Failed
r::---:-:-~~.
Do Not Initiate
Transaction
1809
1810
Decrement Copy
Count For Right
Yes
t-----<...
1813
No
1815
1817
1816
1819
Perform Usage
Transaction Steps
Decrement Copies In Use For
Right By Number In Request
For Metered Use, Subtract
Initiate End-Charge Financial .,___ _--1 Elapsed Time From Remaining
Transaction to Confirm Billing
Use Time For Right
1818
Case 2:13-cv-01112 Document 1-4 Filed 12/18/13 Page 20 of 47 PageID #: 136
U.S. Patent
Apr. 21, 2009
US 7,523,072 B2
Sheet 13 of 13
FIG. 19
SERVER
1912~
l J 1908
More
Data
New
Transaction
19d2
I
I
I
I
I
I
I
Send
Next Data
;
No
More
Data
)
1906
Start
Wait For Ack
I
I
I
I
I
)1914
Commit Report
To Credit Server
,---_J
1903
I
I
I
I
I
I
I
I
I
L----~
I
I
I
I
I
I
I
Data
1907
I
I
:
(Cancel)
Fail
~
Report Error
To Credit Server
~
Ack
"---'
+rI
I
I
I
:
I
I
I
I
Wait For
Transaction
Ll
I
I
I
I
I
I
I
•
1964
1905 J
l
.(
19
(Cancel)
Fail
I
Wait For
Data
f
•
:
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
)
1916
-+
I
I
1
I
I
I
I
:
1915
I
I
----------------------------r-----~---------------------------------1
CLIENT
Done
Ack
Line
1901
____________ _
:
I
I
I
Ll
1909
~
Data
Received
~More
Data
1
Acknowledge _./ 1910
No
More
Data
: 1916
: )
Commit Report
To Credit Server
l
1--
;1918
Report Error
To Credit Server
'
Done
/1919
Case 2:13-cv-01112 Document 1-4 Filed 12/18/13 Page 21 of 47 PageID #: 137
US 7,523,072 B2
1
2
SYSTEM FOR CONTROLLING THE
DISTRIBUTION AND USE OF DIGITAL
WORKS
protection schemes which limit the number of copies that can
be made or which corrupt the output when copying is detected
have been employed. Another scheme causes software to
become disabled after a predetermined period of time has
lapsed. A technique used for workstation based software is to
require that a special hardware device must be present on the
workstation in order for the software to run, e.g., see U.S. Pat.
No. 4,932,054 entitled "Method and Apparatus for Protecting
Computer Software Utilizing Coded Filter Network in Conjunction with an Active Coded Hardware Device." Such
devices are provided with the software and are commonly
referred to as dongles.
Yet another scheme is to distribute software, but which
requires a "key" to enable its use. This is employed in distribution schemes where "demos" of the software are provided
on a medium along with the entire product. The demos can be
freely used, but in order to use the actual product, the key must
be purchased. These schemes do not hinder copying of the
software once the key is initially purchased.
A system for ensuring that licenses are in place for using
licensed products is described in PCT Publication WO
93/01550 to Griswold entitled "License Management System
and Method." The licensed product may be any electronically
published work but is most effective for use with works that
are used for extended periods of time such as software programs. Griswold requires that the licensed product contain
software to invoke a license check monitor at predetermined
time intervals. The license check monitor generates request
datagrams which identify the licensee. The request data grams
are sent to a license control system over an appropriate communication facility. The license control system then checks
the datagram to determine if the datagram is from a valid
licensee. The license control system then sends a reply datagram to the license check monitor indicating denial or
approval of usage. The license control system will deny usage
in the event that request datagrams go unanswered after a
predetermined period of time (which may indicate an unauthorized attempt to use the licensed product). In this system,
usage is managed at a central location by the response datagrams. So for example if license fees have not been paid,
access to the licensed product is terminated.
It is argued by Griswold that the described system is advantageous because it can be implemented entirely in software.
However, the system described by Griswold has limitations.
An important limitation is that during the use of the licensed
product, the user must always be coupled to an appropriate
communication facility in order to send and receive datagrams. This creates a dependency on the communication
facility. So if the communication facility is not available, the
licensed product cam10t be used. Moreover, some party must
absorb the cost of communicating with the license server.
A system for controlling the distribution of digitally
encoded books is embodied in a system available from VPR
Systems, LTD. of St. Louis, Miss. The VPR system is selfcontained and is comprised of: (1) point of sale kiosks for
storing and downloading ofbooks, (2) personal storage mediurns (cartridges) to which the books are downloaded, and (3)
readers for viewing the book. In a purchase transaction, a
purchaser will purchase a voucher card representing the
desired book. The voucher will contain sufficient information
to identify the book purchased and perhaps some demographic information relating to the sales transaction. To
download the book, the voucher and the cartridge are inserted
into the kiosk.
The VPR system may also be used as a library. In such an
embodiment, the kiosk manages the number of"copies" that
may be checked out at one time. Further, the copy of the book
CROSS REFERENCE TO RELATED
APPLICATIONS
This application is a continuation of U.S. patent application Ser. No. 11/198,216 of STEFIK, eta!., filed on Aug. 8,
2005, entitled "SYSTEM FOR CONTROLLING THE DISTRIBUTION AND USE OF DIGITAL WORKS," now pending, which is a continuation of U.S. patent application Ser.
No. 10/176,608 of STEFIK, eta!., filed on Jun. 24, 2002,
entitled "SYSTEM FOR CONTROLLING THE DISTRIBUTION AND USE OF DIGITAL WORKS," now U.S. Pat.
No. 6,934,693, which is a continuation of U.S. patent application Ser. No. 09/777,845, filed on Feb. 7, 2001, now pending, which is a divisional ofU.S. patent application Ser. No.
08/967,084, filed on Nov. 10, 1997, now U.S. Pat. No. 6,236,
971, which is a continuation of U.S. patent application Ser.
No. 08/344,760, filed on Nov. 23, 1994, now abandoned, the
disclosures of all of which are hereby incorporated by reference herein.
FIELD OF THE INVENTION
5
10
15
20
25
The present invention relates to the field of distribution and
usage rights enforcement for digitally encoded works.
BACKGROUND OF THE INVENTION
A fundamental issue facing the publishing and information
industries as they consider electronic publishing is how to
prevent the unauthorized and unaccounted distribution or
usage of electronically published materials. Electronically
published materials are typically distributed in a digital form
and recreated on a computer based system having the capability to recreate the materials. Audio and video recordings,
software, books and multimedia works are all being electronically published. Companies in these industries receive royalties for each accounted for delivery of the materials, e.g. the
sale of an audio CD at a retail outlet. Any unaccounted distribution of a work results in an unpaid royalty (e.g. copying
the audio recording CD to another digital medium.)
The ease in which electronically published works can be
"perfectly" reproduced and distributed is a major concern.
The transmission of digital works over networks is commonplace. One such widely used network is the Internet. The
Internet is a widespread network facility by which computer
users in many universities, corporations and government entities communicate and trade ideas and information. Computer
bulletin boards found on the Internet and commercial networks such as CompuServ and Prodigy allow for the posting
and retrieving of digital information. Information services
such as Dialog and LEXIS/NEXIS provide databases of current information on a wide variety of topics. Another factor
which will exacerbate the situation is the development and
expansion of the National Information Infrastructure (the
Nil). It is anticipated that, as the Nil grows, the transmission
of digital works over networks will increase many times over.
It would be desirable to utilize the Nil for distribution of
digital works without the fear of widespread unauthorized
copying.
The most straightforward way to curb unaccounted distribution is to prevent unauthorized copying and transmission.
For existing materials that are distributed in digital form,
various safeguards are used. In the case of software, copy
30
35
40
45
50
55
60
65
Case 2:13-cv-01112 Document 1-4 Filed 12/18/13 Page 22 of 47 PageID #: 138
US 7,523,072 B2
3
4
is erased from the user's cartridge after a certain check-out
time has expired. However, individuals cannot loan books
because the cartridges may only be used with the owner's
reader.
the underlying work. It would be desirable to have a distribution system where the means for billing is always transported
with the work.
The foregoing distribution and protection schemes operate
in part by preventing subsequent distribution of the work.
While this certainly prevents unauthorized distributions, it
does so by sacrificing the potential for subsequent revenue
bearing uses. For example, it may be desirable to allow the
lending of a purchased work to permit exposure of the work to
potential buyers. Another example would be to permit the
creation of a derivative work for a fee. Yet another example
would be to permit copying the work for a fee (essentially
purchasing it). Thus, it would be desirable to provide flexibility in how the owner of a digital work may allow it to be
distributed.
While flexibility in distribution is a concern, the owners of
a work want to make sure they are paid for such distributions.
In U.S. Pat. No. 4,977,594 to Shear, entitled "Database Usage
Metering and Protection System and Method," a system for
metering and billing for usage of information distributed on a
CD-ROM is described. The system requires the addition of a
billing module to the computer system. The billing module
may operate in a number of different ways. First, it may
periodically communicate billing data to a central billing
facility, whereupon the user may be billed. Second, billing
may occur by disconnecting the billing module and the user
sending it to a central billing facility where the data is read and
a user bill generated.
U.S. Pat. No. 5,247,575, Sprague eta!., entitled "Information Distribution System", describes an information distribution system which provides and charges only for user selected
information. A plurality of encrypted information packages
(IPs) are provided at the user site, via high and/or low density
storage media and/or by broadcast transmission. Some of the
IPs may be of no interest to the user. The IPs of interest are
selected by the user and are decrypted and stored locally. The
IPs may be printed, displayed or even copied to other storage
media. The charges for the selected IP's are accumulated
within a user apparatus and periodically reported by telephone to a central accounting facility. The central accounting
facility also issues keys to decrypt the IPs. The keys are
changed periodically. Ifthe central accounting facility has not
issued a new key for a particular user station, the station is
unable to retrieve information from the system when the key
is changed.
A system available from Wave Systems Corp. of Princeton,
N.Y., provides for metering of software usage on a personal
computer. The system is installed onto a computer and collects information on what software is in use, encrypts it and
then transmits the information to a transaction center. From
the transaction center, a bill is generated and sent to the user.
The transaction center also maintains customer accounts so
that licensing fees may be forwarded directly to the software
providers. Software operating under this system must be
modified so that usage can be accounted.
Known techniques for billing do not provide for billing of
copies made of the work. For example, if data is copied from
the CD-ROM described in Shear, any subsequent use of the
copy of the information carmot be metered or billed. In other
words, the means for billing runs with the media rather than
SUMMARY OF THE INVENTION
10
15
20
25
30
35
40
45
50
55
60
65
A system for controlling the distribution and use of digital
works using digital tickets is disclosed. A ticket is an indicator
that the ticket holder has already paid for or is otherwise
entitled to some specified right, product or service. In the
present invention, a "digital ticket" is used to enable the ticket
holder to exercise usage rights specifYing the requirement of
the digital ticket. Usage rights are used to define how a digital
work may be used or distributed. Specific instances of usage
rights are used to indicate a particular marmer of use or
distribution. A usage right may specify a digital ticket which
must be present before the right may be exercised. For
example, a digital ticket may be specified in a Copy right of a
digital work, so that exercise of the Copy right requires the
party that desires a copy of the digital work be in possession
of the necessary digital ticket. After a copy of the digital work
is successfully sent to the requesting party, the digital ticket is
"punched" to indicate that a copy of the digital work has been
made. When the ticket is "punched" a predetermined number
of times, it may no longer be used.
Digital works are stored in repositories. Repositories
enforce the usage rights for digital works. Each repository has
a "generic ticket agent" which punches tickets. In some
instances only the generic ticket agent is necessary. In other
instances, punching by a "special ticket agent" residing on
another repository may be desired. Punching by a "special
ticket agent" enables greater security and control of the digital
work. For example, it can help prevent digital ticket forgery.
Special ticket agents are also useful in situations where an
external database needs to be updated or checked.
A digital ticket is merely an instance of a digital work.
Thus, a digital ticket may be distributed among repositories in
the same fashion as other digital works.
A digital ticket may be used in many commercial scenarios
such as in the purchase of software and prepaid upgrades. A
digital ticket may also be used to limit the number of times
that a right may be exercised. For example, a user may purchase a copy of a digital work, along with the right to make up
to 5 Copies. In this case, the Copy right would have associated
therewith a digital ticket that can be punched up to 5 times.
Other such commercial scenarios will become apparent from
the detailed description.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a flowchart illustrating a simple instantiation of
the operation of the currently preferred embodiment of the
present invention.
FIG. 2 is a block diagram illustrating the various repository
types and the repository transaction flow between them in the
currently preferred embodiment of the present invention.
FIG. 3 is a block diagram of a repository coupled with a
credit server in the currently preferred embodiment of the
present invention.
FIGS. 4a and 4b are examples of rendering systems as may
be utilized in the currently preferred embodiment of the
present invention.
FIG. 5 illustrates a contents file layout for a digital work as
may be utilized in the currently preferred embodiment of the
present invention.
Case 2:13-cv-01112 Document 1-4 Filed 12/18/13 Page 23 of 47 PageID #: 139
US 7,523,072 B2
5
6
FIG. 6 illustrates a contents file layout for an individual
digital work of the digital work of FIG. 5 as may be utilized in
the currently preferred embodiment of the present invention.
FIG. 7 illustrates the components of a description block of
the currently preferred embodiment of the present invention.
FIG. 8 illustrates a description tree for the contents file
layout of the digital work illustrated in FIG. 5.
FIG. 9 illustrates a portion of a description tree corresponding to the individual digital work illustrated in FIG. 6.
FIG. 10 illustrates a layout for the rights portion of a
description block as may be utilized in the currently preferred
embodiment of the present invention.
FIG. 11 is a description tree wherein certain d-blocks have
PRINT usage rights and is used to illustrate "strict" and
"lenient" rules for resolving usage rights conflicts.
FIG. 12 is a block diagram of the hardware components of
a repository as are utilized in the currently preferred embodiment of the present invention.
FIG. 13 is a block diagram of the functional (logical)
components of a repository as are utilized in the currently
preferred embodiment of the present invention.
FIG. 14 is diagram illustrating the basic components of a
usage right in the currently preferred embodiment of the
present invention.
FIG. 15 lists the usage rights grammar of the currently
preferred embodiment of the present invention.
FIG. 16 is a flowchart illustrating the steps of certificate
delivery, hotlist checking and performance testing as performed in a registration transaction as may be performed in
the currently preferred embodiment of the present invention.
FIG. 17 is a flowchart illustrating the steps of session
information exchange and clock synchronization as may be
performed in the currently preferred embodiment of the
present invention, after each repository in the registration
transaction has successfully completed the steps described in
FIG. 16.
FIG. 18 is a flowchart illustrating the basic flow for a usage
transaction, including the common opening and closing step,
as may be performed in the currently preferred embodiment
of the present invention.
FIG. 19 is a state diagram of server and client repositories
in accordance with a transport protocol followed when moving a digital work from the server to the client repositories, as
may be performed in the currently preferred embodiment of
the present invention.
because it is usually so much easier to use an existing stock
photo or music clip than to create a new one from scratch.
Herein the terms "digital work", "work" and "content"
refer to any work that has been reduced to a digital representation. This would include any audio, video, text, or multimedia work and any accompanying interpreter (e.g. software)
that may be required for recreating the work. The term composite work refers to a digital work comprised of a collection
of other digital works. The term "usage rights" or "rights" is
a term which refers to rights granted to a recipient of a digital
work. Generally, these rights define how a digital work can be
used and if it can be further distributed. Each usage right may
have one or more specified conditions which must be satisfied
before the right may be exercised. Appendix 1 provides a
Glossary of the terms used herein.
A key feature of the present invention is that usage rights
are permanently "attached" to the digital work. Copies made
of a digital work will also have usage rights attached. Thus,
the usage rights and any associated fees assigned by a creator
and subsequent distributor will always remain with a digital
work.
The enforcement elements of the present invention are
embodied in repositories. Among other things, repositories
are used to store digital works, control access to digital works,
bill for access to digital works and maintain the security and
integrity of the system.
The combination of attached usage rights and repositories
enable distinct advantages over prior systems. As noted in the
prior art, payment of fees are primarily for the initial access.
In such approaches, once a work has been read, computational control over that copy is gone. Metaphorically, "the
content genie is out of the bottle and no more fees can be
billed." In contrast, the present invention never separates the
fee descriptions from the work. Thus, the digital work genie
only moves from one trusted bottle (repository) to another,
and all uses of copies are potentially controlled and billable.
FIG. 1 is a high level flowchart omitting various details but
which demonstrates the basic operation of the present invention. Referring to FIG. 1, a creator creates a digital work, step
101. The creator will then determine appropriate usage rights
and fees, attach them to the digital work, and store them in
Repository 1, step 102. The determination of appropriate
usage rights and fees will depend on various economic factors. The digital work remains securely in Repository 1 until
a request for access is received. The request for access begins
with a session initiation by another repository. Here a Repository 2 initiates a session with Repository 1, step 103. As will
be described in greater detail below, this session initiation
includes steps which help to insure that the respective repositories are trustworthy. Assuming that a session can be established, Repository 2 may then request access to the Digital
Work for a stated purpose, step 104. The purpose may be, for
example, to print the digital work or to obtain a copy of the
digital work. The purpose will correspond to a specific usage
right. In any event, Repository 1 checks the usage rights
associated with the digital work to determine if the access to
the digital work may be granted, step 105. The check of the
usage rights essentially involves a determination of whether a
right associated with the access request has been attached to
the digital work and if all conditions associated with the right
are satisfied. If the access is denied, repository 1 terminates
the session with an error message, step 106. If access is
granted, repository 1 transmits the digital work to repository
2, step 107. Once the digital work has been transmitted to
repository 2, repository 1 and 2 each generate billing information for the access which is transmitted to a credit server,
10
15
20
25
30
35
40
45
DETAILED DESCRIPTION OF THE PREFERRED
EMBODIMENT
50
Overview
A system for controlling use and distribution of digital
works is disclosed. The present invention is directed to supporting commercial transactions involving digital works. The
transition to digital works profoundly and fundamentally
changes how creativity and commerce can work. It changes
the cost of transporting or storing works because digital property is almost "massless." Digital property can be transported
at electronic speeds and requires almost no warehousing.
Keeping an unlimited supply of virtual copies on hand
requires essentially no more space than keeping one copy on
hand. The digital medium also lowers the costs of alteration,
reuse and billing.
There is a market for digital works because creators are
strongly motivated to reuse portions of digital works from
others rather than creating their own completely. This is
55
60
65
Case 2:13-cv-01112 Document 1-4 Filed 12/18/13 Page 24 of 47 PageID #: 140
US 7,523,072 B2
7
8
step 108. Such double billing reporting is done to insure
against attempts to circumvent the billing process.
FIG. 2 illustrates the basic interactions between repository
types in the present invention. As will become apparent from
FIG. 2, the various repository types will serve different functions. It is fundamental that repositories will share a core set
of functionality which will enable secure and trusted communications. Referring to FIG. 2, a repository 201 represents the
general instance of a repository. The repository 201 has two
modes of operation; a server mode and a requester mode.
When in the server mode, the repository will be receiving and
processing access requests to digital works. When in the
requester mode, the repository will be initiating requests to
access digital works. Repository 201 is general in the sense
that its primary purpose is as an exchange medium for digital
works. During the course of operation, the repository 201
may communicate with a plurality of other repositories,
namely authorization repository 202, rendering repository
203 and master repository 204. Communication between
repositories occurs utilizing a repository transaction protocol
205.
Communication with an authorization repository 202 may
occur when a digital work being accessed has a condition
requiring an authorization. Conceptually, an authorization is
a digital certificate such that possession of the certificate is
required to gain access to the digital work. An authorization is
itself a digital work that can be moved between repositories
and subjected to fees and usage rights conditions. An authorization may be required by both repositories involved in an
access to a digital work.
Communication with a rendering repository 203 occurs in
connection with the rendering of a digital work. As will be
described in greater detail below, a rendering repository is
coupled with a rendering device (e.g. a printer device) to
comprise a rendering system.
Communication with a master repository 205 occurs in
connection with obtaining an identification certificate. Identification certificates are the means by which a repository is
identified as "trustworthy". The use of identification certificates is described below with respect to the registration transaction.
FIG. 3 illustrates the repository 201 coupled to a credit
server 301. The credit server 301 is a device which accumulates billing information for the repository 201. The credit
server 301 communicates with repository 201 via billing
transactions 302 to record billing transactions. Billing transactions are reported to a billing clearinghouse 303 by the
credit server 301 on a periodic basis. The credit server 301
communicates to the billing clearinghouse 303 via clearinghouse transactions 304. The clearinghouse transactions 304
enable a secure and encrypted transmission of information to
the billing clearinghouse 303.
401 defines a secure system boundary. Communications
within the boundary is assumed to be secure. Depending on
the security level, the boundary also represents a barrier
intended to provide physical integrity. The printer repository
402 is an instantiation of the rendering repository 205 of FIG.
2. The printer repository 402 will in some instances contain an
ephemeral copy of a digital work which remains until it is
printed out by the print engine 403. In other instances, the
printer repository 402 may contain digital works such as
fonts, which will remain and can be billed based on use. This
design assures that all communication lines between printers
and printing devices are encrypted, unless they are within a
physically secure boundary. This design feature eliminates a
potential "fault" point through which the digital work could
be improperly obtained. The printer device 403 represents the
printer components used to create the printed output.
Also illustrated in FIG. 4a is the repository 404. The
repository 404 is coupled to the printer repository 402. The
repository 404 represents an external repository which contains digital works.
FIG. 4b is an example of a computer system as a rendering
system. A computer system may constitute a "multi-function" device since it may execute digital works (e.g. software
programs) and display digital works (e.g. a digitized photograph). Logically, each rendering device can be viewed as
having its own repository, although only one physical repository is needed. Referring to FIG. 4b, a computer system 410
has contained therein a display/execution repository 411. The
display/executionrepository 411 is coupled to display device,
412 and execution device 413. The dashed box surrounding
the computer system 410 represents a security boundary
within which communications are assumed to be secure. The
display/executionrepository 411 is further coupled to a credit
server 414 to report any fees to be billed for access to a digital
work and a repository 415 for accessing digital works stored
therein.
10
15
20
25
30
35
Structure of Digital Works
40
45
50
Rendering Systems
55
A rendering system is generally defined as a system comprising a repository and a rendering device which can render
a digital work into its desired form. Examples of a rendering
system may be a computer system, a digital audio system, or
a printer. A rendering system has the same security features as
a repository. The coupling of a rendering repository with the
rendering device may occur in a manner suitable for the type
of rendering device.
FIG. 4a illustrates a printer as an example of a rendering
system. Referring to FIG. 4, printer system 401 has contained
therein a printer repository 402 and a print device 403. It
should be noted that the dashed line defining printer system
60
65
Usage rights are attached directly to digital works. Thus, it
is important to understand the structure of a digital work. The
structure of a digital work, in particular composite digital
works, may be naturally organized into an acyclic structure
such as a hierarchy. For example, a magazine has various
articles and photographs which may have been created and
are owned by different persons. Each of the articles and
photographs may represent a node in a hierarchical structure.
Consequently, controls, i.e. usage rights, may be placed on
each node by the creator. By enabling control and fee billing
to be associated with each node, a creator of a work can be
assured that the rights and fees are not circumvented.
In the currently preferred embodiment, the file information
for a digital work is divided into two files: a "contents" file
and a "description tree" file. From the perspective of a repository, the "contents" file is a stream of addressable bytes whose
format depends completely on the interpreter used to play,
display or print the digital work. The description tree file
makes it possible to examine the rights and fees for a work
without reference to the content of the digital work. It should
be noted that the term description tree as used herein refers to
any type of acyclic structure used to represent the relationship
between the various components of a digital work.
FIG. 5 illustrates the layout of a contents file. Referring to
FIG. 5, a digital work 509 is comprised of story A 510,
advertisement 511, story B 512 and story C 513. It is assumed
that the digital work is stored starting at a relative address of
0. Each of the parts of the digital work are stored linearly so
Case 2:13-cv-01112 Document 1-4 Filed 12/18/13 Page 25 of 47 PageID #: 141
US 7,523,072 B2
9
10
that story A 510 is stored at approximately addresses 0-30,
represented in the d-blocks. Such variations in the design of
000, advertisement 511 at addresses 30,001-40,000, story B
the representation are possible and are viable alternatives but
512 at addresses 40,001-60,000 and story C 513 at addresses
may introduce processing overhead, e.g. the interpretation of
60,001-85K. The detail of story A 510 is illustrated in FIG. 6.
the objects.
Referring to FIG. 6, the story A 510 is further broken down to
show text 614 stored at address 0-1500, soldier photo 615 at
TABLE 1
addresses 1501-10,000, graphics 616 stored at addresses
DIGITAL WORK STATE INFORMATION
10,001-25,000 and sidebar 617 stored address 25,001-30,
000. Note that the data in the contents file may be compressed
Property
Value
Use
10
(for saving storage) or encrypted (for security).
Copies-inNumber
A counter of the number of copies of a
From FIGS. 5 and 6 it is readily observed that a digital work
Use
work that are in use. Incremented when
can be represented by its component parts as a hierarchy. The
another copy is used; decremented when
description tree for a digital work is comprised of a set of
use is completed.
Loan-Period
Time-Units
Indicator of the maximwn nwnber of
related descriptor blocks (d-blocks). The contents of each
time-nnits that a docwnent can be
d-block are described with respect to FIG. 7. Referring to 15
loaned out
FIG. 7, a d-block 700 includes an identifier 701 which is a
Loaner-Copy
Boolean
Indicator that the current work is a
unique identifier for the work in the repository, a starting
loaned out copy of an authorized digital
work.
address 702 providing the start address of the first byte of the
RemainingTime-Units
Indicator of the remaining time of use
work, a length 703 giving the number of bytes in the work, a
Time
on a metered docwnent right.
rights portion 704 wherein the granted usage rights and their 20 DocumentA string containing various identifYing
String
status data are maintained, a parent pointer 705 for pointing to
Descr
information about a document. The
exact format of this is not specified, but
a parent d-block and child pointers 706 for pointing to the
it can include information such as a
child d-blocks. In the currently preferred embodiment, the
publisher name, author name, ISBN
identifier 701 has two parts. The first part is a unique number
nwnber, and so on.
assigned to the repository upon manufacture. The second part 25 RevenueRO-Descr
A handle identifYing a revenue owner
Owner
for a digital work. This is used for
is a unique number assigned to the work upon creation. The
reporting usage fees.
rights portion 704 will contain a data structure, such as a
PublicationDate-Descr
The date tbat the digital work was
look-up table, wherein the various information associated
Date
published.
with a right is maintained. The information required by the
History-list
History-Rec A list of events recording the repostories
and dates for operations that copy,
respective usage rights is described in more detail below. 30
transfer, backup, or restore a digital
D-blocks form a strict hierarchy. The top d-block of a work
work.
has no parent; all other d-blocks have one parent. The relationship of usage rights between parent and child d-blocks
and how conflicts are resolved is described below.
Digital works are stored in a repository as part of a hierarA special type of d-block is a "shell" d-block. A shell 35 chical file system. Folders (also termed directories and subdirectories) contain the digital works as well as other folders.
d-block adds no new content beyond the content of its parts.
Digital works and folders in a folder are ordered in alphabetiA shell d-block is used to add rights and fee information,
cal order. The digital works are typed to reflect how the files
typically by distributors of digital works.
are used. Usage rights can be attached to folders so that the
FIG. 8 illustrates a description tree for the digital work of
FIG. 5. Referring to FIG. 8, a top d-block 820 for the digital 40 folder itself is treated as a digital work. Access to the folder
would then be handled in the same fashion as any other digital
work points to the various stories and advertisements contained therein. Here, the top d-block 820 points to d-block821
work As will be described in more detail below, the contents
(representing story A 510), d-block 822 (representing the
of the folder are subject to their own rights. Moreover, file
advertisement 511), d-block 823 (representing story B 512)
management rights may be attached to the folder which
and d-block 824 (representing story C 513).
45 defines how folder contents can be managed.
The portion of the description tree for Story A 510 is
Attaching Usage Rights to a Digital Work
illustrated in FIG. 9. D-block 925 represents text 614, d -block
926 represents photo 615, d-block 927 represents graphics
It is fundamental to the present invention that the usage
616 by and d-block 928 represents sidebar 617.
The rights portion 704 of a descriptor block is further 50 rights are treated as part of the digital work. As the digital
work is distributed, the scope of the granted usage rights will
illustrated in FIG. 10. FIG. 10 illustrates a structure which is
remain the same or may be narrowed. For example, when a
repeated in the rights portion 704 for each right. Referring to
digital work is transferred from a document server to a reposiFIG.10, each right will have aright code field 1001 and status
tory, the usage rights may include the right to loan a copy for
information field 1002. The right code field 1001 will contain
a unique code assigned to a right. The status information field 55 a predetermined period of time (called the original rights).
When the repository loans out a copy of the digital work, the
1002 will contain information relating to the state of a right
usage rights in the loaner copy (called the next set of rights)
and the digital work. Such information is indicated below in
could be set to prohibit any further rights to loan out the copy.
Table 1. The rights as stored in the rights portion 304 may
The basic idea is that one cannot grant more rights than they
typically be in numerical order based on the right code.
The approach for representing digital works by separating 60 have.
description data from content assumes that parts of a file are
The attachment of usage rights into a digital work may
contiguous but takes no position on the actual representation
occur in a variety of ways. If the usage rights will be the same
for an entire digital work, they could be attached when the
of content. In particular, it is neutral to the question of whether
content representation may take an object oriented approach.
digital work is processed for deposit in the digital work server.
It would be natural to represent content as objects. In prin- 65 In the case of a digital work having different usage rights for
ciple, it may be convenient to have content objects that
the various components, this can be done as the digital work
include the billing structure and rights information that is
is being created. An authoring tool or digital work assembling
Case 2:13-cv-01112 Document 1-4 Filed 12/18/13 Page 26 of 47 PageID #: 142
US 7,523,072 B2
11
12
tool could be utilized which provides for an automated process of attaching the usage rights.
As will be described below, when a digital work is copied,
transferred or loaned, a "next set of rights" can be specified.
The "next set of rights" will be attached to the digital work as
it is transported.
Physical integrity refers to the integrity of the physical
devices themselves. Physical integrity applies both to the
repositories and to the protected digital works. Thus, the
higher security classes of repositories themselves may have
sensors that detect when tampering is attempted on their
secure cases. In addition to protection of the repository itself,
the repository design protects access to the content of digital
works. In contrast with the design of conventional magnetic
and optical devices-such as floppy disks, CD-ROMs, and
videotapes-repositories never allow non-trusted systems to
access the works directly. A maker of generic computer systems cannot guarantee that their platform will not be used to
make unauthorized copies. The manufacturer provides
generic capabilities for reading and writing information, and
the general nature of the functionality of the general computing device depends on it. Thus, a copy program can copy
arbitrary data. This copying issue is not limited to general
purpose computers. It also arises for the unauthorized duplication of entertainment "software" such as video and audio
recordings by magnetic recorders. Again, the functionality of
the recorders depends on their ability to copy and they have no
means to check whether a copy is authorized. In contrast,
repositories prevent access to the raw data by general devices
and can test explicit rights and conditions before copying or
otherwise granting access. Information is only accessed by
protocol between trusted repositories.
Communications integrity refers to the integrity of the
communications channels between repositories. Roughly
speaking, communications integrity means that repositories
carmot be easily fooled by "telling them lies." Integrity in this
case refers to the property that repositories will only communicate with other devices that are able to present proof that
they are certified repositories, and furthermore, that the
repositories monitor the communications to detect "impostors" and malicious or accidental interference. Thus the security measures involving encryption, exchange of digital certificates, and nonces described below are all security
measures aimed at reliable communication in a world known
to contain active adversaries.
Behavioral integrity refers to the integrity in what repositories do. What repositories do is determined by the software
that they execute. The integrity of the software is generally
assured only by knowledge of its source. Restated, a user will
trust software purchased at a reputable computer store but not
trust software obtained off a random (insecure) server on a
network. Behavioral integrity is maintained by requiring that
repository software be certified and be distributed with proof
of such certification, i.e. a digital certificate. The purpose of
the certificate is to authenticate that the software has been
tested by an authorized organization, which attests that the
software does what it is supposed to do and that it does not
compromise the behavioral integrity of a repository. If the
digital certificate cannot be found in the digital work or the
master repository which generated the certificate is not
known to the repository receiving the software, then the software cannot be installed.
In the description of FIG. 2, it was indicated that repositories come in various forms. All repositories provide a core set
of services for the transmission of digital works. The manner
in which digital works are exchanged is the basis for all
transaction between repositories. The various repository
types differ in the ultimate functions that they perform.
Repositories may be devices themselves, or they may be
incorporated into other systems. An example is the rendering
repository 205 of FIG. 2.
A repository will have associated with it a repository identifier. Typically, the repository identifier would be a unique
Resolving Conflicting Rights
Because each part of a digital work may have its own usage
rights, there will be instances where the rights of a "contained
part" are different from its parent or container part. As a
result, conflict rules must be established to dictate when and
how a right may be exercised. The hierarchical structure of a
digital work facilitates the enforcement of such rules. A
"strict" rule would be as follows: a right for a part in a digital
work is sanctioned if and only if it is sanctioned for the part,
for ancestor d-blocks containing the part and for all descendent d-blocks. By sanctioned, it is meant that (1) each of the
respective parts must have the right, and (2) any conditions for
exercising the right are satisfied.
It also possible to implement the present invention using a
more lenient rule. In the more lenient rule, access to the part
may be enabled to the descendent parts which have the right,
but access is denied to the descendents which do not.
Example of applying both the strict rule and lenient is
illustrated with reference to FIG. 11. Referring to FIG. 11, a
root d-block 1101 has child d-blocks 1102-1105. In this case,
root d-block represents a magazine, and each of the child
d-blocks 1102-1105 represent articles in the magazine. Suppose that a request is made to PRINT the digital work represented by root d-block 1101 wherein the strict rule is followed. The rights for the root d-block 1101 and childd-blocks
1102-1105 are then examined. Root d-block 1101 and child
d-blocks 1102 and 1105 have been granted PRINT rights.
Child d-block 1103 has not been granted PRINT rights and
child d-block 1104 has PRINT rights conditioned on payment
of a usage fee.
Under the strict rule the PRINT right cannot be exercised
because the child d-block does not have the PRINT right.
Under the lenient rule, the result would be different. The
digital works represented by child d-blocks 1102 and 1105
could be printed and the digital work represented by d-block
1104 could be printed so long as the usage fee is paid. Only
the digital work represented by d-block 1103 could not be
printed. This same result would be accomplished under the
strict rule if the requests were directed to each of the individual digital works.
The present invention supports various combinations of
allowing and disallowing access. Moreover, as will be
described below, the usage rights grammar permits the owner
of a digital work to specifY if constraints may be imposed on
the work by a container part. The manner in which digital
works may be sanctioned because of usage rights conflicts
would be implementation specific and would depend on the
nature of the digital works.
10
15
20
25
30
35
40
45
50
55
Repositories
Many of the powerful functions of repositories-such as
their ability to "loan" digital works or automatically handle
the commercial reuse of digital works-are possible because
they are trusted systems. The systems are trusted because they
are able to take responsibility for fairly and reliably carrying
out the commercial transactions. That the systems can be
responsible ("able to respond") is fundamentally an issue of
integrity. The integrity of repositories has three parts: physical integrity, commnnications integrity, and behavioral integrity.
60
65
Case 2:13-cv-01112 Document 1-4 Filed 12/18/13 Page 27 of 47 PageID #: 143
US 7,523,072 B2
13
14
number assigned to the repository at the time of manufacture.
Each repository will also be classified as being in a particular
security class. Certain communications and transactions may
be conditioned on a repository being in a particular security
class. The various security classes are described in greater
detail below.
As a prerequisite to operation, a repository will require
possession of an identification certificate. Identification certificates are encrypted to prevent forgery and are issued by a
Master repository. A master repository plays the role of an
authorization agent to enable repositories to receive digital
works. Identification certificates must be updated on a periodic basis. Identification certificates are described in greater
detail below with respect to the registration transaction.
A repository has both a hardware and functional embodiment. The functional embodiment is typically software
executing on the hardware embodiment. Alternatively, the
functional embodiment may be embedded in the hardware
embodiment such as an Application Specific Integrated Circuit (ASIC) chip.
The hardware embodiment of a repository will be enclosed
in a secure housing which if compromised, may cause the
repository to be disabled. The basic components of the hardware embodiment of a repository are described with reference to FIG. 12. Referring to FIG. 12, a repository is comprised of a processing means 1200, storage system 1207,
clock 1205 and external interface 1206. The processing
means 1200 is comprised of a processor element 1201 and
processor memory 1202. The processing means 1201 provides controller, repository transaction and usage rights transaction functions for the repository. Various functions in the
operation of the repository such as decryption and/or decompression of digital works and transaction messages are also
performed by the processing means 1200. The processor element 1201 may be a microprocessor or other suitable computing component. The processor memory 1202 would typically be further comprised of Read Only Memories (ROM)
and Random Access Memories (RAM). Such memories
would contain the software instructions utilized by the processor element 1201 in performing the functions of the
repository.
The storage system 1207 is further comprised of descriptor
storage 1203 and content storage 1204. The description tree
storage 1203 will store the description tree for the digital
work and the content storage will store the associated content.
The description tree storage 1203 and content storage 1204
need not be of the same type of storage medium, nor are they
necessarily on the same physical device. So for example, the
descriptor storage 1203 may be stored on a solid state storage
(for rapid retrieval of the description tree information), while
the content storage 1204 may be on a high capacity storage
such as an optical disk.
The clock 1205 is used to time-stamp various time based
conditions for usage rights or for metering usage fees which
may be associated with the digital works. The clock 1205 will
have an uninterruptible power supply, e.g. a battery, in order
to maintain the integrity of the time-stamps. The external
interface means 1206 provides for the signal connection to
other repositories and to a credit server. The external interface
means 1206 provides for the exchange of signals via such
standard interfaces such as RS-232 or Personal Computer
Manufacturers Card Industry Association (PCMCIA) standards, or FDDI. The external interface means 1206 may also
provide network connectivity.
The functional embodiment of a repository is described
with reference to FIG. 13. Referring to FIG. 13, the functional
embodiment is comprised of an operating system 1301, core
repository services 1302, usage transaction handlers 1303,
repository specific functions, 1304 and a user interface 1305.
The operating system 1301 is specific to the repository and
would typically depend on the type of processor being used.
The operating system 1301 would also provide the basic
services for controlling and interfacing between the basic
components of the repository.
The core repository services 1302 comprise a set of functions required by each and every repository. The core repository services 1302 include the session initiation transactions
which are defined in greater detail below. This set of services
also includes a generic ticket agent which is used to "punch"
a digital ticket and a generic authorization server for processing authorization specifications. Digital tickets and authorizations are specific mechanisms for controlling the distribution and use of digital works and are described and more
detail below. Note that coupled to the core repository services
are a plurality of identification certificates 1306. The identification certificates 1306 are required to enable the use of the
repository.
The usage transactions handler 1303 comprise functionality for processing access requests to digital works and for
billing fees based on access. The usage transactions supported will be different for each repository type. For example,
it may not be necessary for some repositories to handle access
requests for digital works.
The repository specific functionality 1304 comprises functionality that is unique to a repository. For example, the master repository has special functionality for issuing digital
certificates and maintaining encryption keys. The repository
specific functionality 1304 would include the user interface
implementation for the repository.
10
15
20
25
30
35
40
45
50
55
Repository Security Classes
For some digital works the losses caused by any individual
instance of unauthorized copying is insignificant and the
chief economic concern lies in assuring the convenience of
access and low-overhead billing. In such cases, simple and
inexpensive handheld repositories and network-based workstations may be suitable repositories, even though the measures and guarantees of security are modest.
At the other extreme, some digital works such as a digital
copy of a first run movie or a bearer bond or stock certificate
would be of very high value so that it is prudent to employ
caution and fairly elaborate security measures to ensure that
they are not copied or forged. A repository suitable for holding such a digital work could have elaborate measures for
ensuring physical integrity and for verifying authorization
before use.
By arranging a universal protocol, all kinds of repositories
can communicate with each other in principle. However, creators of some works will want to specifY that their works will
only be transferred to repositories whose level of security is
high enough. For this reason, document repositories have a
ranking system for classes and levels of security. The security
classes in the currently preferred embodiment are described
in Table 2.
TABLE2
60
REPOSITORY SECURITY LEVELS
Level
0
65
Description of Security
Open system. Document transmission
is unencrypted. No digital
certificate is required for identification. The security of the system
Case 2:13-cv-01112 Document 1-4 Filed 12/18/13 Page 28 of 47 PageID #: 144
US 7,523,072 B2
Level
2
4
15
16
TABLE 2-continued
TABLE 2-continued
REPOSITORY SECURITY LEVELS
REPOSITORY SECURITY LEVELS
Description of Security
depends mostly on user honesty,
since only modest knowledge may
be needed to circumvent the
security measures. The repository
has no provisions for preventing
unauthorized programs from
nmning and accessing or copying
files. The system does not
prevent the use of removable
storage and does not encrypt stored
files.
Minimal secmity. Like the previous
class except that stored files
are minimally encrypted, including
ones on removable storage.
Basic security. Like the previous
class except that special tools
and knowledge are required to
compromise the programming, the
contents of the repository, or
the state of the clock. All digital
commnnications are encrypted. A
digital certificate is provided as
identification. Medium level
encryption is used. Repository
identification nwnber is nnforgeable.
General secmity. Like the previous
class plus the requirement of
special tools are needed to compromise
the physical integrity of the
repository and that modest encryption is used on all transmissions.
Password protection is required to
use the local user interface. The
digital clock system cannot be
reset without authorization. No
works would be stored on removable
storage. When executing
works as programs, it runs them
in their own address space and
does not give them direct access
to any file storage or other
memory containing system code or
works. They can access works
only through the transmission
transaction protocol.
Like the previous class except that
high level encryption is used on
all communications. Sensors are
used to record attempts at
physical and electronic tampering.
After such tampering, the
repository will not perform other
transactions until it has reported
such tampering to a designated server.
Like the previous class except
that if the physical or digital
attempts at tampering exceed some
preset thresholds that
threaten the physical integrity
of the repository or the integrity of
digital and cryptographic barriers,
then the repository will save
only document description records
of history but will erase or
destroy any digital identifiers
that could be misused if released to
an unscrupulous party. It also
modifies any certificates of
authenticity to indicate that
the physical system has been
compromised. It also erases the
contents of designated docwnents.
Like the previous class except
that the repository will attempt
Level
10
10
Description of Security
wireless communication to report
tampering and will employ noisy
alarms.
This would correspond to a very
high level of security. This server
would maintain constant commnnications to remote security
systems reporting transactions,
sensor readings, and attempts to
circwnvent security.
15
20
25
30
35
40
45
The characterization of security levels described in Table 2
is not intended to be fixed. More important is the idea of
having different security levels for different repositories. It is
anticipated that new security classes and requirements will
evolve according to social situations and changes in technology.
Repository User Interface
A user interface is broadly defined as the mechanism by
which a user interacts with a repository in order to invoke
transactions to gain access to a digital work, or exercise usage
rights. As described above, a repository may be embodied in
various forms. The user interface for a repository will differ
depending on the particular embodiment. The user interface
may be a graphical user interface having icons representing
the digital works and the various transactions that may be
performed. The user interface may be a generated dialog in
which a user is prompted for information.
The user interface itself need not be part of the repository.
As a repository may be embedded in some other device, the
user interface may merely be a part of the device in which the
repository is embedded. For example, the repository could be
embedded in a "card" that is inserted into an available slot in
a computer system. The user interface may be combination of
a display, keyboard, cursor control device and software
executing on the computer system.
At a minimum, the user interface must permit a user to
input information such as access requests and alpha numeric
data and provide feedback as to transaction status. The user
interface will then cause the repository to initiate the suitable
transactions to service the request. Other facets of a particular
user interface will depend on the functionality that a repository will provide.
50
Credit Servers
55
60
65
In the present invention, fees may be associated with the
exercise of a right. The requirement for payment of fees is
described with each version of a usage right in the usage
rights language. The recording and reporting of such fees is
performed by the credit server. One of the capabilities
enabled by associating fees with rights is the possibility of
supporting a wide range of charging models. The simplest
model, used by conventional software, is that there is a single
fee at the time of purchase, after which the purchaser obtains
unlimited rights to use the work as often and for as long as he
or she wants. Alternative models, include metered use and
variable fees. A single work can have different fees for different uses. For example, viewing a photograph on a display
could have different fees than making a hardcopy or including
it in a newly created work. A key to these alternative charging
Case 2:13-cv-01112 Document 1-4 Filed 12/18/13 Page 29 of 47 PageID #: 145
US 7,523,072 B2
17
18
models is to have a low overhead means of establishing fees
and accounting for credit on these transactions.
A credit server is a computational system that reliably
authorizes and records these transactions so that fees are
billed and paid. The credit server reports fees to a billing
clearinghouse. The billing clearinghouse manages the financial transactions as they occur. As a result, bills may be
generated and accounts reconciled. Preferably, the credit
server would store the fee transactions and periodically communicate via a network with billing clearinghouse for reconciliation. In such an embodiment, communications with the
billing clearinghouse would be encrypted for integrity and
security reasons. In another embodiment, the credit server
acts as a "debit card" where transactions occur in "real-time"
against a user account.
A credit server is comprised of memory, a processing
means, a clock, and interface means for coupling to a repository and a financial institution (e.g. a modem). The credit
server will also need to have security and authentication functionality. These elements are essentially the same elements as
those of a repository. Thus, a single device can be both a
repository and a credit server, provided that it has the appropriate processing elements for carrying out the corresponding
functions and protocols. Typically, however, a credit server
would be a card-sized system in the possession of the owner
of the credit. The credit server is coupled to a repository and
would interact via financial transactions as described below.
Interactions with a financial institution may occur via protocols established by the financial institutions themselves.
In the currently preferred embodiment credit servers associated with both the server and the repository report the financial transaction to the billing clearinghouse. For example,
when a digital work is copied by one repository to another for
a fee, credit servers coupled to each of the repositories will
report the transaction to the billing clearinghouse. This is
desirable in that it insures that a transaction will be accounted
for in the event of some break in the communication between
a credit server and the billing clearinghouse. However, some
implementations may embody only a single credit server
reporting the transaction to minimize transaction processing
at the risk of losing some transactions.
features and benefits of the usage rights language will become
apparent in the description of distribution and use scenarios
provided below.
The basic contents of a right are illustrated in FIG. 14.
Referring to FIG. 14, a right 1450 has a transactional component 1451 and a specifications component 1452. A right
1450 has a label (e.g. COPY or PRINT) which indicate the
use or distribution privileges that are embodied by the right.
The transactional component 1451 corresponds to a particular way in which a digital work may be used or distributed.
The transactional component 1451 is typically embodied in
software instructions in a repository which implement the use
or distribution privileges for the right. The specifications
components 1452 are used to specify conditions which must
be satisfied prior to the right being exercised or to designate
various transaction related parameters. In the currently preferred embodiment, these specifications include copy count
1453, Fees and Incentives 1454, Time 1455, Access and Security 1456 and Control1457. Each of these specifications will
be described in greater detail below with respect to the language grammar elements.
The usage rights language is based on the grammar
described below. A grammar is a convenient means for defining valid sequence of symbols for a language. In describing
the grammar the notation"[ albic]" is used to indicate distinct
choices among alternatives. In this example, a sentence can
have either an "a", "b" or "c". It must include exactly one of
them. The braces { } are used to indicate optional items. Note
that brackets, bars and braces are used to describe the language of usage rights sentences but do not appear in actual
sentences in the language.
In contrast, parentheses are part of the usage rights language. Parentheses are used to group items together in lists.
The notation (x*) is used to indicate a variable length list, that
is, a list containing one or more items of type x. The notation
(x)* is used to indicate a variable numberoflists containing x.
Keywords in the grammar are words followed by colons.
Keywords are a common and very special case in the language. They are often used to indicate a single value, typically
an identifier. In many cases, the keyword and the parameter
are entirely optional. When a keyword is given, it often takes
a single identifier as its value. In some cases, the keyword
takes a list of identifiers.
In the usage rights language, time is specified in an hours:
minutes:seconds (or hh:mm:ss) representation. Time zone
indicators, e.g. PDT for Pacific Daylight Time, may also be
specified. Dates are represented as year/month/day (or
YYYY/MMM/DD). Note that these time and date representations may specify moments in time or units of time Money
units are specified in terms of dollars.
Finally, in the usage rights language, various "things" will
need to interact with each other. For example, an instance of
a usage right may specify a bank account, a digital ticket, etc.
Such things need to be identified and are specified herein
using the suffix "-ID."
The Usage Rights Grammar is listed in it's entirety in FIG.
15 and is described below.
Grammar element 1501 "Digital Work Rights:=(Rights*)"
define the digital work rights as a set of rights. The-set of
rights attached to a digital work define how that digital work
may be transferred, used, performed or played. A set of rights
will attach to the entire digital work and in the case of compound digital works, each of the components of the digital
work. The usage rights of components of a digital may be
different.
Grammar element 1502 "Right:=(Right-Code {CopyCount} {Control-Spec} {Time-Spec} {Access-Spec} {Fee-
10
15
20
25
30
35
40
Usage Rights Language
The present invention uses statements in a high level
"usage rights language" to define rights associated with digital works and their parts. Usage rights statements are interpreted by repositories and are used to determine what transactions can be successfully carried out for a digital work and
also to determine parameters for those transactions. For
example, sentences in the language determine whether a
given digital work can be copied, when and how it can be
used, and what fees (if any) are to be charged for that use.
Once the usage rights statements are generated, they are
encoded in a suitable form for accessing during the processing of transactions.
Defining usage rights in terms of a language in combination with the hierarchical representation of a digital work
enables the support of a wide variety of distribution and fee
schemes. An example is the ability to attach multiple versions
of a right to a work. So a creator may attach a PRINT right to
make 5 copies for $10.00 and a PRINT right to make unlimited copies for $100.00. A purchaser may then choose which
option best fits his needs. Another example is that rights and
fees are additive. So in the case of a composite work, the
rights and fees of each of the components works is used in
determining the rights and fees for the work as a whole. Other
45
50
55
60
65
Case 2:13-cv-01112 Document 1-4 Filed 12/18/13 Page 30 of 47 PageID #: 146
US 7,523,072 B2
19
20
Spec})" enumerates the content of a right. Each usage right
must specifY a right code. Each right may also optionally
specifY conditions which must be satisfied before the right
can be exercised. These conditions are copy count, control,
time, access and fee conditions. In the currently preferred
embodiment, for the optional elements, the following
defaults apply: copy count equals 1, no time limit on the use
of the right, no access tests or a security level required to use
the right and no fee is required. These conditions will each be
described in greater detail below.
It is important to note that a digital work may have multiple
versions of a right, each having the same right code. The
multiple versions would provide alternative conditions and
fees for accessing the digital work.
A Grammar element 1503 "Right-Code:=RenderCode ITransport--Code IF ile-Management -Code IDerivativeWorks-Code Configuration-Code" distinguishes each of the
specific rights into a particular right type (although each right
is identified by distinct right codes). In this way, the grammar
provides a catalog of possible rights that can be associated
with parts of digital works. In the following, rights are divided
into categories for convenience in describing them.
Grammar element 1504 "Render-Code:=[Play: {Player:
Player-ID} !Print: {Printer: Printer-ID}]" lists a category of
rights all involving the making of ephemeral, transitory, or
non-digital copies of the digital work. After use the copies are
erased.
Play: A process of rendering or performing a digital work
on some processor. This includes such things as playing
digital movies, playing digital music, playing a video
game, =ing a computer program, or displaying a
document on a display.
Print: To render the work in a medium that is not further
protected by usage rights, such as printing on paper.
1505
"Transport-Code:=
Grammar
element
[Copy ITransfer! Loan {Remaining-Rights: Next -Set -ofRights} l{ (Next-Copy-Rights: Next-Set of Rights)}" lists a
category of rights involving the making of persistent, usable
copies of the digital work on other repositories. The optional
Next-Copy-Rights determine the rights on the work after it is
transported. If this is not specified, then the rights on the
transported copy are the same as on the original. The optional
Remaining-Rights specify the rights that remain with a digital
work when it is loaned out. If this is not specified, then the
default is that no rights can be exercised when it is loaned out.
Copy: Make a new copy of a work
Transfer: Moving a work from one repository to another.
Loan: Temporarily loaning a copy to another repository for
a specified period of time.
Grammar element 1506 "File-Management-Code:=
Backup {Back-Up-Copy-Rights: Next-Set-of Rights}
IRestoreiDeleteiFolderiDirectory {Name:Hide-LocaliHideRemote} {Parts:Hide-LocaliHide-Remote}" lists a category
of rights involving operations for file management, such as
the making of backup copies to protect the copy owner
against catastrophic equipment failure.
Many software licenses and also copyright law give a copy
owner the right to make backup copies to protect against
catastrophic failure of equipment. However, the making of
uncontrolled backup copies is inherently at odds with the
ability to control usage, since an uncontrolled backup copy
can be kept and then restored even after the authorized copy
was sold.
The File management rights enable the making and restoring of backup copies in a way that respects usage rights,
honoring the requirements of both the copy owner and the
rights grantor and revenue owner. Backup copies of work
descriptions (including usage rights and fee data) can be sent
under appropriate protocol and usage rights control to other
document repositories of sufficiently high security. Further
rights permit organization of digital works into folders which
themselves are treated as digital works and whose contents
may be "hidden" from a party seeking to determine the contents of a repository.
Backup: To make a backup copy of a digital work as protection against media failure.
Restore: To restore a backup copy of a digital work.
Delete: To delete or erase a copy of a digital work.
Folder: To create and name folders, and to move files and
folders between folders.
Directory: To hide a folder or it's contents.
Grammar element 1507 "Derivative-Works-Code:
[ExtractiEmbediEdit {Process: Process-ID}] {Next-CopyRights: Next-Set-ofRights }"lists a category of rights involving the use of a digital work to create new works.
Extract: To remove a portion of a work, for the purposes of
creating a new work.
Embed: To include a work in an existing work.
Edit: To alter a digital work by copying, selecting and
modifYing portions of an existing digital work.
1508
"Configuration-Code:=
Grammar
element
InstalliUninstall" lists a category of rights for installing and
uninstalling software on a repository (typically a rendering
repository.) This would typically occur for the installation of
a new type of player within the rendering repository.
Install: To install new software on a repository.
Uninstall: To remove existing software from a repository.
Grammar element 1509 "Next-Set-of-Rights:={ (Add: SetOf-Rights)} {(Delete: Set-Of-Rights)} {(Replace: Set-OfRights)} {(Keep: Set-Of-Rights)}" defines how rights are
carried forward for a copy of a digital work. If the Next-CopyRights is not specified, the rights for the next copy are the
same as those of the current copy. Otherwise, the set of rights
for the next copy can be specified. Versions of rights after
Add: are added to the current set of rights. Rights after Delete:
are deleted from the current set of rights. If only right codes
are listed after Delete: then all versions of rights with those
codes are deleted. Versions of rights after Replace: subsume
all versions of rights of the same type in the current set of
rights.
If Remaining-Rights is not specified, then there are no
rights for the original after all Loan copies are loaned out. If
Remaining-Rights is specified, then the Keep: token can be
used to simplify the expression of what rights to keep behind.
A list of right codes following keep means that all of the
versions of those listed rights are kept in the remaining copy.
This specification can be overridden by subsequent Delete: or
Replace: specifications.
5
10
15
20
25
30
35
40
45
50
55
60
65
Copy Count Specification
For various transactions, it may be desirable to provide
some limit as to the number of "copies" of the work which
may be exercised simultaneously for the right. For example, it
may be desirable to limit the number of copies of a digital
work that may be loaned out at a time or viewed at a time.
Grammar element 1510 "Copy-Count:=(Copies: positiveinteger 101 unlimited)" provides a condition which defines the
number of "copies" of a work subject to the right. A copy
count can be 0, a fixed number, or unlimited. The copy-count
is associated with each right, as opposed to there being just a
single copy-count for the digital work. The Copy-Count for a
right is decremented each time that a right is exercised. When
the Copy-Count equals zero, the right can no longer be exercised. If the Copy-Count is not specified, the default is one.
Case 2:13-cv-01112 Document 1-4 Filed 12/18/13 Page 31 of 47 PageID #: 147
US 7,523,072 B2
21
22
Control Specification
Rights and fees depend in general on rights granted by the
creator as well as further restrictions imposed by later distributors. Control specifications deal with interactions
between the creators and their distributors governing the
imposition of further restrictions and fees. For example, a
distributor of a digital work may not want an end consumer of
a digital work to add fees or otherwise profit by commercially
exploiting the purchased digital work.
Grammar element 1511 "Control-Spec:=(Control:
{RestrictableiUnrestrictable}
{UnchargeableiChargeable}-)" provides a condition to
specifY the effect of usage rights and fees of parents on the
exercise of the right. A digital work is restrictable if higher
level d-blocks can impose further restrictions (time specifications and access specifications) on the right. It is unrestrictable if no further restrictions can be imposed. The default
setting is restrictable. A right is unchargeable if no more fees
can be imposed on the use of the right. It is chargeable if more
fees can be imposed. The default is chargeable.
days could be spread out over a month. With this specification, the rights can be exercised until the meter time is
exhausted or the expiration date is reached, whichever comes
first.
Remaining-U se:=Time-Unit
Start-Time:=Time-Unit
Use-Duration:=Time-Unit
All of the time specifications include time-unit specifications in their ultimate instantiation.
Time Specification
It is often desirable to assign a start date or specifY some
duration as to when a right may be exercised. Grmar ele1512
"Time-Spec:=( {Fixed-Interval ISlidingment
Interval! Meter-Tim-e} Until: Expiration-Date)" provides for
specification of time conditions on the exercise of a right.
Rights may be granted for a specified time. Different kinds of
time specifications are appropriate for different kinds of
rights. Some rights may be exercised during a fixed and
predetermined duration. Some rights may be exercised for an
interval that starts the first time that the right is invoked by
some transaction. Some rights may be exercised or are
charged according to some kind of metered time, which may
be split into separate intervals. For example, a right to view a
picture for an hour might be split into six ten minute viewings
or four fifteen minute viewings or twenty three minute viewings.
The terms "time" and "date" are used synonymously to
refer to a moment in time. There are several kinds of time
specifications. Each specification represents some limitation
on the times over which the usage right applies. The Expiration-Date specifies the moment at which the usage right ends.
For example, if the Expiration-Date is "Jan. 1, 1995," then the
right ends at the first moment of1995. If the Expiration-Date
is specified as *forever*, then the rights are interpreted as
continuing without end. If only an expiration date is given,
then the right can be exercised as often as desired until the
expiration date.
Grammar element 1513 "Fixed-Interval:=From: StartTime" is used to define a predetermined interval that runs
from the start time to the expiration date.
Grammar element 1514 "Sliding-Interval:=Interval: UseDuration" is used to define an indeterminate (or "open") start
time. It sets limits on a continuous period of time over which
the contents are accessible. The period starts on the first
access and ends after the duration has passed or the expiration
date is reached, whichever comes first. For example, if the
right gives 10 hours of continuous access, the use-duration
would begin when the first access was made and end 10 hours
later.
Grammar element 1515 "Meter-Time:=Time-Remaining:
Remaining-Use" is used to define a "meter time," that is, a
measure of the time that the right is actually exercised. It
differs from the Sliding-Interval specification in that the time
that the digital work is in use need not be continuous. For
example, if the rights guarantee three days of access, those
10
15
20
25
30
35
40
45
50
55
60
65
Security Class and Authorization Specification
The present invention provides for various security mechanisms to be introduced into a distribution or use scheme.
Grammar element 1516 "Access-Spec:=( {SC: SecurityClass} {Authorization: Authorization-ID*} {Other-Authorization: Authorization-ID*} {Ticket: Ticket-ID} )"provides a
means for restricting access and transmission. Access specifications can specify a required security class for a repository
to exercise a right or a required authorization test that must be
satisfied.
The keyword "SC:" is used to specify a minimum security
level for the repositories involved in the access. If"SC:" is not
specified, the lowest security level is acceptable.
The optional "Authorization:" keyword is used to specifY
required authorizations on the same repository as the work.
The optional "Other-Authorization:" keyword is used to
specifY required authorizations on the other repository in the
transaction.
The optional "Ticket:" keyword specifies the identity of a
ticket required for the transaction. A transaction involving
digital tickets must locate an appropriate digital ticket agent
who can "punch" or otherwise validate the ticket before the
transaction can proceed. Tickets are described in greater
detail below.
In a transaction involving a repository and a document
server, some usage rights may require that the repository have
a particular authorization, that the server have some authorization, or that both repositories have (possibly different)
authorizations. Authorizations themselves are digital works
(hereinafter referred to as an authorization object) that can be
moved between repositories in the same manner as other
digital works. Their copying and transferring is subject to the
same rights and fees as other digital works. A repository is
said to have an authorization if that authorization object is
contained within the repository.
In some cases, an authorization may be required from a
source other than the document server and repository. An
authorization object referenced by an Authorization-ID can
contain digital address information to be used to set up a
communications link between a repository and the authorization source. These are analogous to phone numbers. For
such access tests, the communication would need to be established and authorization obtained before the right could be
exercised.
For one-time usage rights, a variant on this scheme is to
have a digital ticket. A ticket is presented to a digital ticket
agent, whose type is specified on the ticket. In the simplest
case, a certified generic ticket agent, available on all repositories, is available to "punch" the ticket. In other cases, the
ticket may contain addressing information for locating a
"special" ticket agent. Once a ticket has been punched, it
cannot be used again for the same kind of transaction (unless
it is unpunched or refreshed in the manner described below.)
Punching includes marking the ticket with a timestamp of the
date and time it was used. Tickets are digital works and can be
copied or transferred between repositories according to their
usage rights.
Case 2:13-cv-01112 Document 1-4 Filed 12/18/13 Page 32 of 47 PageID #: 148
US 7,523,072 B2
23
24
In the currently preferred embodiment, a "punched" ticket
becomes "unpunched" or "refreshed" when it is copied or
extracted. The Copy and Extract operations save the date and
time as a property of the digital ticket. When a ticket agent is
given a ticket, it can simply check whether the digital copy
was made after the last time that it was punched. Of course,
the digital ticket must have the copy or extract usage rights
attached thereto.
The capability to unpunch a ticket is important in the following cases:
A digital work is circulated at low cost with a limitation that
it can be used only once.
A digital work is circulated with a ticket that can be used
once to give discounts on purchases of other works.
A digital work is circulated with a ticket (included in the
purchase price and possibly embedded in the work) that
can be used for a future upgrade.
In each of these cases, if a paid copy is made of the digital
work (including the ticket) the new owner would expect to get
a fresh (unpunched) ticket, whether the copy seller has used
the work or not. In contrast, loaning a work or simply transferring it to another repository should not revitalize the ticket.
account to which the fee is to be paid. When Incentive: is
specified, Account-ID identifies the account from which the
fee is to be paid.
Grammar element 1520 "Per-Use-Spec:=Per-Use: Moneyunit" defines a simple fee to be paid every time the right is
exercised, regardless ofhow much time the transaction takes.
Grammar element 1521 "Metered-Rate-Spec:=Metered:
Money-Unit Per: Time-Spec" defines a metered-rate fee paid
according to how long the right is exercised. Thus, the time it
takes to complete the transaction determines the fee.
Grammar, element 1522 "Best-Price-Spec:=Best-Price:
Money-unit Max: Money-unit" is used to specifY a best-price
that is determined when the account is settled. This specification is to accommodate special deals, rebates, and pricing
that depends on information that is not available to the repository. All fee specifications can be combined with tickets or
authorizations that could indicate that the consumer is a
wholesaler or that he is a preferred customer, or that the seller
be authorized in some way. The amount of money in the Max:
field is the maximum amount that the use will cost. This is the
amount that is tentatively debited from the credit server. However, when the transaction is ultimately reconciled, any
excess amount will be returned to the consumer in a separate
transaction.
Grammar element 1523 "Call-For-Price-Spec:=Call-ForPrice" is similar to a "Best-Price-Spec" in that it is intended to
accommodate cases where prices are dynamic. A Call-ForPrice Spec requires a communication with a dealer to determine the price. This option caunot be exercised if the repository caunot communicate with a dealer at the time that the
right is exercised. It is based on a secure transaction whereby
the dealer names a price to exercise the right and passes along
a deal certificate which is referenced or included in the billing
process.
Grammar element 1524 "Scheduled-Fee-Spec:=(Schedule: (Time-Spec Regular-Fee-Spec)*)" is used to provide a
schedule of dates over which the fee specifications change.
The fee specification with the most recent date not in the
future is the one that is in effect. This is similar to but more
general than the scheduled discount. It is more general,
because it provides a means to vary the fee agreement for each
time period.
Grammar element 1525 "Markup-Spec:=Markup: percentage To: Account-ID" is provided for adding a percentage
to the fees already being charged. For example, a 5% markup
means that a fee of 5% of cumulative fee so far will be
allocated to the distributor. A markup specification can be
applied to all of the other kinds of fee specifications. It is
typically used in a shell provided by a distributor. It refers to
fees associated with d-blocks that are parts of the current
d-block. This might be a convenient specification for use in
taxes, or in distributor overhead.
Usage Fees and Incentives Specification
The billing for use of a digital work is fundamental to a
commercial distribution system. Grammar Element 1517
"Fee-Spec:={ Scheduled-Discount}
Regular-FeeSpeciScheduled-Fee-SpeciMarkup-Spec" provides a range
of options for billing for the use of digital works.
A key feature of this approach is the development oflowoverhead billing for transactions in potentially small
amounts. Thus, it becomes feasible to collect fees of only a
few cents each for thousands of transactions.
The grammar differentiates between uses where the charge
is per use from those where it is metered by the time unit.
Transactions can support fees that the user pays for using a
digital work as well as incentives paid by the right grantor to
users to induce them to use or distribute the digital work.
The optional scheduled discount refers to the rest of the fee
specification-discounting it by a percentage over time. If it
is not specified, then there is no scheduled discount. Regular
fee specifications are constant overtime. Scheduled fee specifications give a schedule of dates over which the fee specifications change. Markup specifications are used in d-blocks
for adding a percentage to the fees already being charged.
Grammar Element 1518 "Scheduled-Discount:=(Scheduled-Discount: (Time-Spec Percentage)*)" A ScheduledDiscount is essentially a scheduled modifier of any other fee
specification for this version of the right of the digital work.
(It does not refer to children or parent digital works or to other
versions of rights.). It is a list of pairs of times and percentages. The most recent time in the list that has not yet passed at
the time of the transaction is the one in effect. The percentage
gives the discount percentage. For example, the number 10
refers to a 10% discount.
Grammar Element 1519 "Regular-Fee-Spec:=({Fee:
IIncentive:} [Per-Use-Specl Metered-Rate-Spec IBest-PriceSpeciCall-For-Price-Spec] {Min: Money-Unit Per: TimeSpec} {Max: Money-Unit Per: Time-Spec} To: AccountID)" provides for several kinds of fee specifications.
Fees are paid by the copy-owner/userto the revenue-owner
if Fee: is specified. Incentives are paid by the revenue-owner
to the user iflncentive: is specified. If the Min: specification
is given, then there is a minimum fee to be charged per
time-spec unit for its use. If the Max: specification is given,
then there is a maximum fee to be charged per time-spec for
its use. When Fee: is specified, Account-ID identifies the
10
15
20
25
30
35
40
45
50
55
60
65
Examples of Sets of Usage Rights
((Play) (Transfer (SC: 3)) (Delete)
This work can be played without requirements for fee or
authorization on any rendering system. It can be transferred to
any other repository of security level 3 or greater. It can be
deleted.
((Play) (Transfer (SC: 3)) (Delete) (Backup) (Restore (Fee:
Per-Use: $5 To: Account-ID-678)))
Same as the previous example plus rights for backup and
restore. The work can be backed up without fee. It can be
restored for a $5 fee payable to the account described by
Account-ID-678.
Case 2:13-cv-01112 Document 1-4 Filed 12/18/13 Page 33 of 47 PageID #: 149
US 7,523,072 B2
25
26
((Play) (Transfer (SC: 3))
(Copy (SC:3)(Fee: Per-Use: $5 To: Account-ID-678))
(Delete (Incentive: Per-Use: $2.50 To: Account-ID-678)))
This work can be played, transferred, copied, or deleted.
Copy or transfer operations can take place only with repositories of security level three or greater. The fee to make a copy
is $5 payable to Account-ID-678. If a copy is deleted, then an
incentive of $2.50 is paid to the former copy owner.
((Play) (Transfer (SC: 3))
Copy (SC: 3) (Fee: Per-Use: $10 To: Account-ID-678))
Delete) (Backup) (Restore (SC: 3) (Fee: Per-Use: $5 To:
Account-ID-678)))
Same as the previous example plus fees for copying. The
work can be copied digitally for a fee of $10 payable to
Account-ID-678. The repository on which the work is copied
or restored must be at security level 3 or greater.
((Play) (Transfer (SC: 3))
(Copy Authorization: License-123-ID (SC: 3)))
The digital work can be played, transferred, or copied.
Copies or transfers must be on repositories of security level 3
or greater. Copying requires the license License-123-ID
issued to the copying repository. None of the rights require
fees.
((Play) (Print Printer: Printer-567-ID (Fee: Per-Use: $1 To:
Account-ID-678)))
This work can be played for free. It can be printed on any
printer with the identifier Printer-567-ID for a fee of $1 payable to the account described by Account-ID-678.
((Play Player: Player-876-ID) (From: Feb. 2, 1994 Until:
Feb. 15, 1995) (Fee: Metered: $0.01 Per: 0:1:0 Min:
$0.25 Per: 0/1/0 To: Account-ID-567))
This work can be played on any player holding the ID
Player-876-ID. The time of this right is from Feb. 14, 1994
until Feb. 15, 1995. The fee for use is one centperminutewith
a minimum of25 cents in any day that it is used, payable to the
account described by Account-ID-567.
((Play) (Transfer) (Delete)(Loan 2 (Delete: Transfer
Loan)))
This work can be played, transferred, deleted, or loaned.
Up to two copies can be loaned out at a time. The loaned copy
has the same rights except that it cannot be transferred. When
both copies are loaned out, no rights can be exercised on the
original on the repository.
((Play) (Transfer) (Delete) (Backup) (Restore (SC:3))
(Loan 2 Remaining-Copy-Rights: (Delete: Play Transfer)
Next-Set-of-Rights: (Delete: Transfer Loan)))
Similar to previous example. Rights to Backup and Restore
the work are added, where restoration requires a repository of
at least security level three. When all copies of the work are
loaned out, the remaining copy cannot be played or transferred.
((Play) (Transfer) (Copy) (Print) (Backup) (Restore (SC:
3))
(Loan 1 Remaining-Copy-Rights: (Add: Play Print
Backup)
Next-Set-of-Rights: (Delete: Transfer Loan)
(Fee: Metered: $10 Per: 1:0:0 To: Account-ID-567))
(Loan 1 Remaining-Copy-Rights:
Add: ((Play Player: Player-876-ID) 2 (From: Feb. 14, 1994
Until: Feb. 15, 1995)
(Fee: Metered: $0.01 Per: 0:1:0 Min: $0.25 Per: 0/1/0
To: Account-ID-567))))
The original work has rights to Play, Transfer, Copy, Print,
Backup, Restore, and Loan. There are two versions of the
Loan right. Thefirstversionofthe loan right costs $10perday
but allows the original copy owner to exercise free use of the
Play, Print and Backup rights. The second version of the Loan
right is free. None of the original rights are applicable. However a right to Play the work at the specified metered rate is
added.
((Play Player: Player-Small-Screen-123-ID)
(Embed (Fee: Per-Use $0.01 To: Account-678-ID))
(Copy (Fee: Per-Use $1.00 To: Account-678-ID)))
The digital work can be played on any player with the
identifier Player-Small-Screen-123-ID. It can be embedded
in a larger work. The embedding requires a modest one cent
registration fee to Account-678-ID. Digital copies can be
made for $1.00.
5
10
Repository Transactions
15
20
25
30
35
40
45
50
55
60
65
When a user requests access to a digital work, the repository will initiate various transactions. The combination of
transactions invoked will depend on the specifications
assigned for a usage right. There are three basic types of
transactions, Session Initiation Transactions, Financial
Transactions and Usage Transactions. Generally, session initiation transactions are initiated first to establish a valid session. When a valid session is established, transactions corresponding to the various usage rights are invoked. Finally,
request specific transactions are performed.
Transactions occur between two repositories (one acting as
a server), between a repository and a document playback
platform (e.g. for executing or viewing), between a repository
and a credit server or between a repository and an authorization server. When transactions occur between more than one
repository, it is assumed that there is a reliable communication channel between the repositories. For example, this could
be a TCP/IP channel or any other commercially available
channel that has built-in capabilities for detecting and correcting transmission errors. However, it is not assumed that
the communication channel is secure. Provisions for security
and privacy are part of the requirements for specifying and
implementing repositories and thus form the need for various
transactions.
Message Transmission
Transactions require that there be some communication
between repositories. Communication between repositories
occurs in units termed as messages. Because the communication line is assumed to be unsecure, all communications
with repositories that are above the lowest security class are
encrypted utilizing a public key encryption technique. Public
key encryption is a well kuown technique in the encryption
arts. The term key refers to a numeric code that is used with
encryption and decryption algorithms. Keys come in pairs,
where "writing keys" are used to encrypt data and "checking
keys" are used to decrypt data. Both writing and checking
keys may be public or private. Public keys are those that are
distributed to others. Private keys are maintained in confidence.
Key management and security is instrun1ental in the success of a public key encryption system. In the currently preferred embodiment, one or more master repositories maintain
the keys and create the identification certificates used by the
repositories.
When a sending repository transmits a message to a receiving repository, the sending repository encrypts all of its data
using the public writing key of the receiving repository. The
sending repository includes its name, the name of the receiving repository, a session identifier such as a nonce (described
below), and a message counter in each message.
In this way, the communication can only be read (to a high
probability) by the receiving repository, which holds the pri-
Case 2:13-cv-01112 Document 1-4 Filed 12/18/13 Page 34 of 47 PageID #: 150
US 7,523,072 B2
27
28
vate checking key for decryption. The auxiliary data is used to
guard against various replay attacks to security. If messages
ever arrive with the wrong counter or an old nonce, the repositories can assume that someone is interfering with communication and the transaction terminated.
The respective public keys for the repositories to be used
for encryption are obtained in the registration transaction
described below.
first exchange lists of names ofhotlist certificates, ultimately
exchanging only those lists that they had not previously
received. The "hotlists" are maintained and distributed by
Master repositories.
Note that rather than terminating in error, the transaction
could request that another registration message be sent based
on an identification certificate created by another master
repository. This may be repeated until a satisfactory identification certificate is found, or it is determined that trust cannot
be established.
Assuming that the repository is not on the hotlist, the
repository identification needs to be verified. In other words,
repository-2 needs to validate that the repository on the other
end is really repository-!. This is termed performance testing
and is performed in order to avoid invalid access to the repository via a counterfeit repository replaying a recording of a
prior session initiation between repository-! and repository2. Performance testing is initiated by repository-2 generating
a performance message, step 1609. The performance message consists of a nonce, the names of the respective repositories, the time and the registration identifier received from
repository-!. A nonce is a generated message based on some
random and variable information (e.g. the time or the temperature.) The nonce is used to check whether repository-!
can actually exhibit correct encrypting of a message using the
private keys it claims to have, on a message that it has never
seen before. The performance message is encrypted using the
public key specified in the registration message of repository!. The performance message is transmitted to repository-!,
step 1610, where it is decrypted by repository-! using its
private key, step 1611. Repository-! then checks to make sure
that the names of the two repositories are correct, step 1612,
that the time is accurate, step 1613 and that the registration
identifier corresponds to the one it sent, step 1614. If any of
these tests fails, the transaction is terminated per step 1616.
Assuming that the tests are passed, repository-! transmits the
nonce to repository-2 in the clear, step 1615. Repository-2
then compares the received nonce to the original nonce, step
1617. If they are not identical, the registration transaction
terminates in an error per step 1618. If they are the same, the
registration transaction has successfully completed.
At this point, assuming that the transaction has not terminated, the repositories exchange messages containing session
keys to be used in all communications during the session and
synchronize their clocks. FIG. 17 illustrates the session information exchange and clock synchronization steps (again
from the perspective of repository-!.) Referring to FIG. 17,
repository-! creates a session key pair, step 1701. A first key
is kept private and is used by repository-! to encrypt messages. The second key is a public key used by repository-2 to
decrypt messages. The second key is encrypted using the
public key of repository-2, step 1702 and is sent to repository2, step 1703. Upon receipt, repository-2 decrypts the second
key, step 1704. The second key is used to decrypt messages in
subsequent communications. When each repository has completed this step, they are both convinced that the other repository is bona fide and that they are communicating with the
original. Each repository has given the other a key to be used
in decrypting further communications during the session.
Since that key is itself transmitted in the public key of the
receiving repository only it will be able to decrypt the key
which is used to decrypt subsequent messages.
After the session information is exchanged, the repositories must synchronize their clocks. Clock synchronization is
used by the repositories to establish an agreed upon time base
for the financial records of their mutual transactions. Referring back to FIG. 17, repository- 2 initiates clock synchroni-
Session Initiation Transactions
A usage transaction is carried out in a session between
repositories. For usage transactions involving more than one
repository, or for financial transactions between a repository
and a credit server, a registration transaction is performed. A
second transaction termed a login transaction, may also be
needed to initiate the session. The goal of the registration
transaction is to establish a secure charmel between two
repositories who know each others identities. As it is assumed
that the communication channel between the repositories is
reliable but not secure, there is a risk that a non-repository
may mimic the protocol in order to gain illegitimate access to
a repository.
The registration transaction between two repositories is
described with respect to FIGS. 16 and 17. The steps
described are from the perspective of a "repository-!" registering its identity with a "repository-2". The registration must
be symmetrical so the same set of steps will be repeated for
repository-2 registering its identity with repository-!. Referring to FIG. 16, repository-! first generates an encrypted
registration identifier, step 1601 and then generates a registration message, step 1602. A registration message is comprised of an identifier of a master repository, the identification
certificate for the repository-! and an encrypted random registration identifier. The identification certificate is encrypted
by the master repository in its private key and attests to the
fact that the repository (here repository-!) is a bona fide
repository. The identification certificate also contains a public
key for the repository, the repository security level and a
timestamp (indicating a time after which the certificate is no
longer valid.) The registration identifier is a number generated by the repository for this registration. The registration
identifier is unique to the session and is encrypted in repository-!' s private key. The registration identifier is used to
improve security of authentication by detecting certain kinds
of communications based attacks. Repository-! then transmits the registration message to repository-2, step 1603.
Upon receiving the registration message, repository-2
determines if it has the needed public key for the master
repository, step 1604. If repository-2 does not have the
needed public key to decrypt the identification certificate, the
registration transaction terminates in an error, step 1618.
Assuming that repository-2 has the proper public key the
identification certificate is decrypted, step 1605. Repository-2 saves the encrypted registration identifier, step 1606,
and extracts the repository identifier, step 1607. The extracted
repository identifier is checked against a "hotlist" of compromised document repositories, step 1608. In the currently preferred embodiment, each repository will contain "hotlists" of
compromised repositories. If the repository is on the "hatlist", the registration transaction terminates in an error per
step 1618. Repositories can be removed from the hotlist when
their certificates expire, so that the list does not need to grow
without bound. Also, by keeping a short list ofhotlist certificates that it has previously received, a repository can avoid the
work of actually going through the list. These lists would be
encrypted by a master repository. A minor variation on the
approach to improve efficiency would have the repositories
10
15
20
25
30
35
40
45
50
55
60
65
Case 2:13-cv-01112 Document 1-4 Filed 12/18/13 Page 35 of 47 PageID #: 151
US 7,523,072 B2
29
30
zation by generating a time stamp exchange message, step
1705, and transmits it to repository-!, step 1706. Upon
receipt, repository-! generates its own time stamp message,
step 1707 and transmits it back to repository-2, step 1708.
Repository-2 notes the current time, step 1709 and stores the
time received from repository-!, step 1710. The current time
is compared to the time received from repository-!, step
1711. The difference is then checked to see if it exceeds a
predetermined tolerance (e.g. one minute), step 1712. If it
does, repository-2 terminates the transaction as this may indicate tampering with the repository, step 1713. If not repository-2 computes an adjusted time delta, step 1714. The
adjusted time delta is the difference between the clock time of
repository-2 and the average of the times from repository-!
and repository-2.
To achieve greater accuracy, repository-2 can request the
time again up to a fixed number of times (e.g. five times),
repeat the clock synchronization steps, and average the
results.
A second session initiation transaction is a Login transaction. The Login transaction is used to check the authenticity of
a user requesting a transaction. A Login transaction is particularly prudent for the authorization of financial transactions that will be charged to a credit server. The Login transaction involves an interaction between the user at a user
interface and the credit server associated with a repository.
The information exchanged here is a login string supplied by
the repository/credit server to identifY itself to the user, and a
Personal Identification Number (PIN) provided by the user to
identify himself to the credit server. In the event that the user
is accessing a credit server on a repository different from the
one on which the user interface resides, exchange of the
information would be encrypted using the public and private
keys of the respective repositories.
An End-charges transaction to end a charge for metered
use. (In a variation on this approach, the repositories
would exchange periodic charge information for each
block of time.)
A report-charges transaction between a personal credit
server and a billing clearinghouse. This transaction is
invoked at least once per billing period. It is used to pass
along information about charges. On debit and credit
cards, this transaction would also be used to update
balance information and credit limits as needed.
All billing transactions are given a transaction ID and are
reported to the credit severs by both the server and the client.
This reduces possible loss of billing information if one of the
parties to a transaction loses a banking card and provides a
check against tampering with the system.
Billing Transactions
Billing Transactions are concerned with monetary transaction with a credit server. Billing Transactions are carried out
when all other conditions are satisfied and a usage fee is
required for granting the request. For the most part, billing
transactions are well understood in the state of the art. These
transactions are between a repository and a credit server, or
between a credit server and a billing clearinghouse. Briefly,
the required transactions include the following:
Registration and LOGIN transactions, by which the repository and user establish their bona fides to a credit server.
These transactions would be entirely internal in cases
where the repository and credit server are implemented
as a single system.
Registration and LOGIN transactions, by which a credit
server establishes its bona fides to a billing clearinghouse.
AnAssign-fee transaction to assign a charge. The information in this transaction would include a transaction identifier, the identities of the repositories in the transaction,
and a list of charges from the parts of the digital work. If
there has been any unusual event in the transaction such
as an interruption of communications, that information
is included as well.
A Begin-charges transaction to assign a charge. This transaction is much the same as an assign-fee transaction except
that it is used for metered use. It includes the same information as the assign-fee 4, ii transaction as well as the usage fee
information. The credit-server is then responsible for running
a clock.
10
15
20
25
30
35
40
45
50
55
60
65
Usage Transactions
After the session initiation transactions have been completed, the usage request may then be processed. To simplifY
the description of the steps carried out in processing a usage
request, the term requester is used to refer to a repository in
the requester mode which is initiating a request, and the term
server is used to refer to a repository in the server mode and
which contains the desired digital work. In many cases such
as requests to print or view a work, the requester and server
may be the same device and the transactions described in the
following would be entirely internal. In such instances, certain transaction steps, such as the registration transaction,
need not be performed.
There are some common steps that are part of the semantics
of all of the usage rights transactions. These steps are referred
to as the common transaction steps. There are two sets-the
"opening" steps and the "closing" steps. For simplicity, these
are listed here rather than repeating them in the descriptions
of all of the usage rights transactions.
Transactions can refer to a part of a digital work, a complete digital work, or a Digital work containing other digital
works. Although not described in detail herein, a transaction
may even refer to a folder comprised of a plurality of digital
works. The term "work" is used to refer to what ever portion
or set of digital works is being accessed.
Many of the steps here involve determining if certain conditions are satisfied. Recall that each usage right may have
one or more conditions which must be satisfied before the
right can be exercised. Digital works have parts and parts have
parts. Different parts can have different rights and fees. Thus,
it is necessary to verify that the requirements are met for ALL
of the parts that are involved in a transaction For brevity, when
reference is made to checking whether the rights exist and
conditions for exercising are satisfied, it is meant that all such
checking takes place for each of the relevant parts of the work.
FIG. 18 illustrates the initial common opening and closing
steps for a transaction. At this point it is assumed that registration has occurred and that a "trusted" session is in place.
General tests are tests on usage rights associated with the
folder containing the work or some containing folder higher
in the file system hierarchy. These tests correspond to requirements imposed on the work as a consequence of its being on
the particular repository, as opposed to being attached to the
work itself. Referring to FIG. 18, prior to initiating a usage
transaction, the requester performs any general tests that are
required before the right associated with the transaction can
be exercised, step, 1801. For example, install, uninstall and
delete rights may be implemented to require that a requester
have an authorization certificate before the right can be exercised. Another example is the requirement that a digital ticket
be present and punched before a digital work may be copied
Case 2:13-cv-01112 Document 1-4 Filed 12/18/13 Page 36 of 47 PageID #: 152
US 7,523,072 B2
31
32
to a requester. If any of the general tests fail, the transaction is
actions between the repository and associated credit server.
not initiated, step, 1802. Assuming that such required tests are
Further, any metering of usage of a digital work will compassed, upon receiving the usage request, the server generates
mence. If any financial transaction fails, the transaction terminates per step 1805.
a transaction identifier that is used in records or reports of the
transaction, step 1803. The server then checks whether the
It should be noted that the order in which the conditions are
digital work has been granted the right corresponding to the
checked need not follow the order of steps 1806-1815.
requested transaction, step 1804. If the digital work has not
At this point, right specific steps are now performed and are
been granted the right corresponding to the request, the transrepresented here as step 1816. The right specific steps are
action terminates, step 1805. If the digital work has been
described in greater detail below.
granted the requested right, the server then determines if the 1o
The common closing transaction steps are now performed.
various conditions for exercising the right are satisfied. Time
Each of the closing transaction steps are performed by the
based conditions are examined, step 1806. These conditions
server after a successful completion of a transaction. Referare checked by examining the time specification for the verring back to FIG. 18, the copies in use value for the requested
sion of the right. If any of the conditions are not satisfied, the
right is decremented by the number of copies involved in the
transaction terminates per step 1805.
15 transaction, step 1817. Next, if the right had a metered usage
Assuming that the time based conditions are satisfied, the
fee specification, the server subtracts the elapsed time from
server checks security and access conditions, step 1807. Such
the Remaining-Use-Time associated with the right for every
security and access conditions are satisfied if: 1) the requester
part involved in the transaction, step 1818. Finally, ifthere are
is at the specified security class, or a higher security class, 2)
fee specifications associated with the right, the server initiates
the server satisfies any specified authorization test and 3) the 20 End-Charge financial transaction to confirm billing, step
requester satisfies any specified authorization tests and has
1819.
any required digital tickets. If any of the conditions are not
Transmission Protocol
satisfied, the transaction terminates per step 1805.
An important area to consider is the transmission of the
Assuming that the security and access conditions are all
satisfied, the server checks the copy count condition, step 25 digital work from the server to the requester. The transmission
protocol described herein refers to events occurring after a
1808. If the copy count equals zero, then the transaction
valid session has been created. The transmission protocol
carmot be completed and the transaction terminates per step
must handle the case of disruption in the communications
1805.
between the repositories. It is assumed that interference such
Assuming that the copy count does not equal zero, the
server checks if the copies in use for the requested right is 30 as injecting noise on the communication channel can be
detected by the integrity checks (e.g., parity, checksum, etc.)
greater than or equal to any copy count for the requested right
that
are built into the transport protocol and are not discussed
(or relevant parts), step 1809. If the copies in use are greater
in detail herein.
than or equal to the copy count, this indicates that usage rights
The underlying goal in the transmission protocol is to
for the version of the transaction have been exhausted.
Accordingly, the server terminates the transaction, step 1805. 35 preclude certain failure modes, such as malicious or accidental interference on the communications charmel. Suppose, for
If the copy count is less than the copies in use for the transexample, that a user pulls a card with the credit server at a
action the transaction can continue, and the copies in use
specific time near the end of a transaction. There should not be
would be incremented by the number of digital works
a vulnerable time at which "pulling the card" causes the
requested in the transaction, step 1810.
The server then checks if the digital work has a "Loan" 40 repositories to fail to correctly account for the number of
copies of the work that have been created. Restated, there
access right, step 1811. The "Loan" access right is a special
should be no time at which a party can break a connection as
case since remaining rights may be present even though all
a means to avoid payment after using a digital work.
copies are loaned out. If the digital work has the "Loan"
If a transaction is interrupted (and fails), both repositories
access right, a check is made to see if all copies have been
loaned out, step 1812. The number of copies that could be 45 restore the digital works and accounts to their state prior to the
failure, modulo records of the failure itself.
loaned is the sum of the Copy-Counts for all of the versions of
FIG. 19 is a state diagram showing steps in the process of
the loan right of the digital work. For a composite work, the
transmitting information during a transaction. Each box reprelevant figure is the minimal such sum of each of the comresents a state of a repository in either the server mode (above
ponents of the composite work. If all copies have been loaned
out, the remaining rights are determined, step 1813. The 50 the central dotted line 1901) or in the requester mode (below
the dotted line 1901). Solid arrows stand for transitions
remaining-rights are determined from the remaining rights
between states. Dashed arrows stand for message communispecifications from the versions of the Loan right. If there is
cations between the repositories. A dashed message arrow
only one version of the Loan right, then the determination is
pointing to a solid transition arrow is interpreted as meaning
simple. The remaining rights are the ones specified in that
version of the Loan right, or none if Remaining-Rights: is not 55 that the transition takes place when the message is received.
Unlabeled transition arrows take place unconditionally. Other
specified. If there are multiple versions of the Loan right and
labels on state transition arrows describe conditions that trigall copies of all of the versions are loaned out, then the
ger the transition.
remaining rights is taken as the minimum set (intersection) of
Referring now to FIG. 19, the server is initially in a state
remaining rights across all of the versions of the loan right.
The server then determines if the requested right is in the set 60 1902 where a new transaction is initiated via start message
1903. This message includes transaction information includof remaining rights, step 1814. If the requested right is not in
ing a transaction identifier and a count of the blocks of data to
the set of remaining rights, the server terminates the transacbe transferred. The requester, initially in a wait state 1904
tion, step 1805.
then enters a data wait state 1905.
If Loan is not a usage right for the digital work or if all
The server enters a data transmit state 1906 and transmits a
copies have not been loaned out or the requested right is in the 65
set of remaining rights, fee conditions for the right are then
block of data 1907 and then enters a wait for acknowledgechecked, step 1815. This will initiate various financial transment state 1908. As the data is received, the requesters enters
Case 2:13-cv-01112 Document 1-4 Filed 12/18/13 Page 37 of 47 PageID #: 153
US 7,523,072 B2
33
34
a data receive state 1909 and when the data blocks is completely received it enters an acknowledgement state 1910 and
transmits an Acknowledgement message 1911 to the server.
If there are more blocks to send, the server waits until
receiving an Acknowledgement message from the requester.
When an Acknowledgement message is received it sends the
next block to the requester and again waits for acknowledgement. The requester also repeats the same cycle of states.
If the server detects a communications failure before sending the last block, it enters a cancellation state 1912 wherein
the transaction is cancelled. Similarly, if the requester detects
a communications failure before receiving the last block it
enters a cancellation state 1913.
If there are no more blocks to send, the server commits to
the transaction and waits for the final Acknowledgement in
state 1914. If there is a communications failure before the
server receives the final Acknowledgement message, it still
commits to the transaction but includes a report about the
event to its credit server in state 1915. This report serves two
purposes. It will help legitimize any claims by a user of
having been billed for receiving digital works that were not
completely received. Also it helps to identifY repositories and
communications lines that have suspicious patterns of use and
interruption. The server then enters its completion state
On the requester side, when there are no more blocks to
receive, the requester commits to the transaction in state
1917. If the requester detects a communications failure at this
state, it reports the failure to its credit server in state 1918, but
still commits to the transaction. When it has committed, it
sends an acknowledgement message to the server. The server
then enters its completion state 1919.
The key property is that both the server and the requester
cancel a transaction if it is interrupted before all of the data
blocks are delivered, and commits to it if all of the data blocks
have been delivered.
There is a possibility that the server will have sent all of the
data blocks (and committed) but the requester will not have
received all of them and will cancel the transaction. In this
case, both repositories will presumably detect a communications failure and report it to their credit server. This case will
probably be rare since it depends on very precise timing of the
communications failure. The only consequence will be that
the user at the requester repository may want to request a
refund from the credit services-and the case for that refund
will be documented by reports by both repositories.
To prevent loss of data, the server should not delete any
transferred digital work until receiving the final acknowledgement from the requester. But it also should not use the
file. A well known way to deal with this situation is called
"two-phase commit" or 2PC.
Two-phase commit works as follows. The first phase works
the same as the method described above. The server sends all
of the data to the requester. Both repositories mark the transaction (and appropriate files) as uncommitted. The server
sends a ready-to-commit message to the requester. The
requester sends back an acknowledgement. The server then
commits and sends the requester a commit message. When
the requester receives the commit message, it commits the
file.
If there is a communication failure or other crash, the
requester must check back with the server to determine the
status of the transaction. The server has the last word on this.
The requester may have received all of the data, but if it did
not get the final message, it has not committed. The server can
go ahead and delete files (except for transaction records) once
it commits, since the files are known to have been fully
transmitted before starting the 2PC cycle.
There are variations known in the art which can be used to
achieve the same effect. For example, the server could use an
additional level of encryption when transmitting a work to a
client. Only after the client sends a message acknowledging
receipt does it send the key. The client then agrees to pay for
the digital work. The point of this variation is that it provides
a clear audit trail that the client received the work. For trusted
systems, however, this variation adds a level of encryption for
no real gain in accountability.
The transactions for specific usage rights are now discussed.
10
15
20
25
30
35
40
45
50
55
60
65
The Copy Transaction
A Copy transaction is a request to make one or more
independent copies of the work with the same or lesser usage
rights. Copy differs from the extraction right discussed later
in that it refers to entire digital works or entire folders containing digital works. A copy operation cannot be used to
remove a portion of a digital work.
The requester sends the server a message to initiate the
Copy Transaction. This message indicates the work to be
copied, the version of the copy right to be used for the
transaction, the destination address information (location in a folder) for placing the work, the file data for the
work (including its size), and the number of copies
requested.
The repositories perform the common opening transaction
steps.
The server transmits the requested contents and data to the
client according to the transmission protocol. If a NextSet-Of-Rights has been provided in the version of the
right, those rights are transmitted as the rights for the
work. Otherwise, the rights of the original are transmitted. In any event, the Copy-Count field for the copy of
the digital work being sent right is set to the number-ofcopies requested.
The requester records the work contents, data, and usage
rights and stores the work. It records the date and time
that the copy was made in the properties of the digital
work.
The repositories perform the common closing transaction
steps.
The Transfer Transaction
A Transfer transaction is a request to move copies of the
work with the same or lesser usage rights to another repository. In contrast with a copy transaction, this results in removing the work copies from the server.
The requester sends the server a message to initiate the
Transfer Transaction. This message indicates the work
to be transferred, the version of the transfer right to be
used in the transaction, the destination address information for placing the work, the file data for the work, and
the number of copies involved.
The repositories perform the common opening transaction
steps.
The server transmits the requested contents and data to the
requester according to the transmission protocol. If a
Next-Set-Of-Rights has been provided, those rights are
transmitted as the rights for the work. Otherwise, the
rights of the original are transmitted. In either case, the
Copy-Count field for the transmitted rights is set to the
number-of-copies requested.
The requester records the work contents, data, and usage
rights and stores the work.
The server decrements its copy count by the number of
copies involved in the transaction.
Case 2:13-cv-01112 Document 1-4 Filed 12/18/13 Page 38 of 47 PageID #: 154
US 7,523,072 B2
35
The repositories perform the common closing transaction
steps.
If the number of copies remaining in the server is now zero,
it erases the digital work from its memory.
36
The Play Transaction
A play transaction is a request to use the contents of a work.
Typically, to "play" a work is to send the digital work through
some kind of transducer, such as a speaker or a display device.
The request implies the intention that the contents will not be
The Loan Transaction
communicated digitally to any other system. For example,
A loan transaction is a mechanism for loaning copies of a
they will not be sent to a printer, recorded on any digital
digital work. The maximum duration of the loan is determedium, retained after the transaction or sent to another
mined by an internal parameter of the digital work. Works are
repository.
automatically returned after a predetermined time period.
10
This term "play" is natural for examples like playing
The requester sends the server a message to initiate the
music, playing a movie, or playing a video game. The general
Transfer Transaction. This message indicates the work
form of play means that a "player" is used to use the digital
to be loaned, the version of the loan right to be used in the
work. However, the term play covers all media and kinds of
transaction, the destination address information for
recordings. Thus one would "play" a digital work, meaning,
placing the work, the number of copies involved, the file 15 to render it for reading, or play a computer program, meaning
data for the work, and the period of the loan.
to execute it. For a digital ticket the player would be a digital
The server checks the validity of the requested loan period,
ticket agent.
and ends with an error if the period is not valid. Loans for
The requester sends the server a message to initiate the play
a loaned copy cannot extend beyond the period of the
transaction. This message indicates the work to be
original loan to the server.
20
played, the version of the play right to be used in the
The repositories perform the common opening transaction
transaction, the identity of the player being used, and the
steps.
file data for the work.
The server transmits the requested contents and data to the
The server checks the validity of the player identification
requester.
and the compatibility of the player identification with
If a Next-Set-Of-Rights has been provided, those rights are 25
the player specification in the right. It ends with an error
transmitted as the rights for the work. Otherwise, the
if these are not satisfactory.
rights of the original are transmitted, as modified to
The repositories perform the common opening transaction
reflect the loan period.
steps.
The requester records the digital work contents, data, usage
The server and requester read and write the blocks of data
30
rights, and loan period and stores the work.
as requested by the player according to the transmission
protocol. The requester plays the work contents, using
The server updates the usage rights information in the
the player.
digital work to reflect the number of copies loaned out.
When the player is finished, the player and the requester
The repositories perform the common closing transaction
remove the contents from their memory.
steps.
35
The repositories perform the common closing transaction
The server updates the usage rights data for the digital
steps.
work. This may preclude use of the work until it is
returned from the loan. The user on the requester platThe Print Transaction
form can now use the transferred copies of the digital
A Print transaction is a request to obtain the contents of a
work. A user accessing the original repository cannot 40
work for the purpose of rendering them on a "printer." We use
use the digital work, unless there are copies remaining.
the term "printer" to include the common case of writing with
What happens next depends on the order of events in
ink on paper. However, the key aspect of "printing" in our use
time.
of the term is that it makes a copy of the digital work in a place
Case 1. If the time of the loan period is not yet exhausted
outside of the protection of usage rights. As with all rights,
45
and the requester sends the repository a Return message.
this may require particular authorization certificates.
The return message includes the requester identification,
Once a digital work is printed, the publisher and user are
and the transaction ID.
bound by whatever copyright laws are in effect. However,
The server decrements the copies-in-use field by the numprinting moves the contents outside the control of repositober of copies that were returned. (If the number of digital 50 ries. For example, absent any other enforcement mechanisms,
works returned is greater than the number actually boronce a digital work is printed on paper, it can be copied on
rowed, this is treated as an error.) This step may now
ordinary photocopying machines without intervention by a
make the work available at the server for other users.
repository to collect usage fees. If the printer to a digital disk
The requester deactivates its copies and removes the conis permitted, then that digital copy is outside of the control of
tents from its memory.
usage
rights. Both the creator and the user know this, although
55
the creator does not necessarily give tacit consent to such
Case 2. If the time of the loan period is exhausted and the
copying, which may violate copyright laws.
requester has not yet sent a Return message.
The requester sends the server a message to initiate a Print
The server decrements the copies-in-use field by the numtransaction. This message indicates the work to be
ber digital works that were borrowed.
played, the identity of the printer being used, the file data
The requester automatically deactivates its copies of the 60
for the work, and the number of copies in the request.
digital work. It terminates all current uses and erases the
The server checks the validity of the printer identification
digital work copies from memory. One question is why
and the compatibility of the printer identification with
a requester would ever return a work earlier than the
the printer specification in the right. It ends with an error
period of the loan, since it would be returned automatiif these are not satisfactory.
cally anyway. One reason for early return is that there 65
The repositories perform the common opening transaction
may be a metered fee which determines the cost of the
steps.
loan. Returning early may reduce that fee.
Case 2:13-cv-01112 Document 1-4 Filed 12/18/13 Page 39 of 47 PageID #: 155
US 7,523,072 B2
37
The server transmits blocks of data according to the transmission protocol.
The requester prints the work contents, using the printer.
When the printer is finished, the printer and the requester
remove the contents from their memory.
The repositories perform the common closing transaction
steps.
38
The requester sends the server a message to 1mtlate a
Restore transaction. This message indicates the work to
be restored, the version of the restore right for the transaction, the destination address information for placing
the work, and the file data for the work.
The server verifies that the contents file is available (i.e. a
digital work corresponding to the request has been
backed-up.) If it is not, it ends the transaction with an
error.
The repositories perform the common opening transaction
steps.
The server retrieves the key from the restoration file. It
decrypts the work contents, data, and usage rights.
The server transmits the requested contents and data to the
requester according to the transmission protocol. If a
Next-Set-Of-Rights has been provided, those rights are
transmitted as the rights for the work. Otherwise, a set of
default rights for backup files of the original are transmitted by the server.
The requester stores the digital work.
The repositories perform the common closing transaction
steps.
The Backup Transaction
A Backup transaction is a request to make a backup copy of 10
a digital work, as a protection against media failure. In the
context of repositories, secure backup copies differ from
other copies in three ways: ( 1) they are made under the control
of a Backup transaction rather than a Copy transaction, (2)
they do not count as regular copies, and (3) they are not usable 15
as regular copies. Generally, backup copies are encrypted.
Although backup copies may be transferred or copied,
depending on their assigned rights, the only way to make
them useful for playing, printing or embedding is to restore
them.
20
The output of a Backup operation is both an encrypted data
file that contains the contents and description of a work, and
a restoration file with an encryption key for restoring the
The Delete Transaction
encrypted contents. In many cases, the encrypted data file
would have rights for "printing" it to a disk outside of the 25
A Delete transaction deletes a digital work or a number of
protection system, relying just on its encryption for security.
copies of a digital work from a repository. Practically all
Such files could be stored anywhere that was physically safe
digital works would have delete rights.
and convenient. The restoration file would be held in the
The requester sends the server a message to initiate a delete
repository. This file is necessary for the restoration of a
transaction. This message indicates the work to be
backup copy. It may have rights for transfer between reposi- 30
deleted, the version of the delete right for the transaction.
tories.
The repositories perform the common opening transaction
The requester sends the server a message to initiate a
steps.
backup transaction. This message indicates the work to
The server deletes the file, erasing it from the file system.
be backed up, the version of the backup right to be used
The repositories perform the common closing transaction
in the transaction, the destination address information 35
steps.
for placing the backup copy, the file data for the work.
The Directory Transaction
The repositories perform the common opening transaction
A Directory transaction is a request for information about
steps.
folders, digital works, and their parts. This amounts to
The server transmits the requested contents and data to the
requester. If a Next-Set-Of-Rights has been provided, 40 roughly the same idea as protection codes in a conventional
file system like TENEX, except that it is generalized to the
those rights are transmitted as the rights for the work.
full power of the access specifications of the usage rights
Otherwise, a set of default rights for backup files of the
language.
original are transmitted by the server.
The Directory transaction has the important role of passing
The requester records the work contents, data, and usage
rights. It then creates a one-time key and encrypts the 45 along descriptions of the rights and fees associated with a
digital work. When a user wants to exercise a right, the user
contents file. It saves the key information in a restoration
interface of his repository implicitly makes a directory
file.
request to determine the versions of the right that are availThe repositories perform the common closing transaction
able. Typically these are presented to the user-such as with
steps.
different choices of billing for exercising a right. Thus, many
50
In some cases, it is convenient to be able to archive the
directory transactions are invisible to the user and are exerlarge, encrypted contents file to secure offline storage, such as
cised as part of the normal process of exercising all rights.
a magneto-optical storage system or magnetic tape. This creThe requester sends the server a message to initiate a Direcation of a non-repository archive file is as secure as the
tory transaction. This message indicates the file or folder
encryption process. Such non-repository archive storage is
that is the root of the directory request and the version of
55
considered a form of "printing" and is controlled by a print
the directory right used for the transaction.
right with a specified "archive-printer." An archive-printer
The server verifies that the information is accessible to the
device is programmed to save the encrypted contents file (but
requester. In particular, it does not return the names of
not the description file) offline in such a way that it can be
any files that have a HIDE-NAME status in their direcretrieved.
tory specifications, and it does not return the parts of any
60
folders or files that have HIDE-PARTS in their specifiThe Restore Transaction
cation. If the information is not accessible, the server
A Restore transaction is a request to convert an encrypted
ends the transaction with an error.
backup copy of a digital work into a usable copy. A restore
The repositories perform the common opening transaction
operation is intended to be used to compensate for catasteps.
strophic media failure. Like all usage rights, restoration rights 65
The server sends the requested data to the requester accordcan include fees and access tests including authorization
ing to the transmission protocol.
checks.
Case 2:13-cv-01112 Document 1-4 Filed 12/18/13 Page 40 of 47 PageID #: 156
US 7,523,072 B2
40
39
The requester records the data.
The repositories perform the common closing transaction
steps.
The Folder Transaction
A Folder transaction is a request to create or rename a
folder, or to move a work between folders. Together with
Directory rights, Folder rights control the degree to which
organization of a repository can be accessed or modified from
another repository.
The requester sends the server a message to initiate a
Folder transaction. This message indicates the folder
that is the root of the folder request, the version of the
folder right for the transaction, an operation, and data.
The operation can be one of create, rename, and move
file. The data are the specifications required for the
operation, such as a specification of a folder or digital
work and a name.
The repositories perform the common opening transaction
steps.
The server performs the requested operation--creating a
folder, renaming a folder, or moving a work between
folders.
The repositories perform the common closing transaction
steps.
The Extract Transaction
A extract transaction is a request to copy a part of a digital
work and to create a new work containing it. The extraction
operation differs from copying in that it can be used to separate a part of a digital work from d-blocks or shells that place
additional restrictions or fees on it. The extraction operation
differs from the edit operation in that it does not change the
contents of a work, only its embedding in d-blocks. Extraction creates a new digital work.
The requester sends the server a message to initiate an
Extract transaction. This message indicates the part of
the work to be extracted, the version of the extract right
to be used in the transaction, the destination address
information for placing the part as a new work, the file
data for the work, and the number of copies involved.
The repositories perform the common opening transaction
steps.
The server transmits the requested contents and data to the
requester according to the transmission protocol. If a
Next-Set-Of-Rights has been provided, those rights are
transmitted as the rights for the new work. Otherwise,
the rights of the original are transmitted. The CopyCount field for this right is set to the number-of-copies
requested.
The requester records the contents, data, and usage rights
and stores the work. It records the date and time that new
work was made in the properties of the work.
The repositories perform the common closing transaction
steps.
The Embed Transaction
An embed transaction is a request to make a digital work
become a part of another digital work or to add a shell d-block
to enable the adding offees by a distributor of the work.
The requester sends the server a message to initiate an
Embed transaction. This message indicates the work to
be embedded, the version of the embed right to be used
in the transaction, the destination address information
for placing the part as a work, the file data for the work,
and the number of copies involved.
10
15
20
25
30
35
40
45
50
55
60
65
The server checks the control specifications for all of the
rights in the part and the destination. If they are incompatible, the server ends the transaction with an error.
The repositories perform the common opening transaction
steps.
The server transmits the requested contents and data to the
requester according to the transmission protocol. If a
Next-Set-Of-Rights has been provided, those rights are
transmitted as the rights for the new work. Otherwise,
the rights of the original are transmitted. The CopyCount field for this right is set to the number-of-copies
requested.
The requester records the contents, data, and usage rights
and embeds the work in the destination file.
The repositories perform the common closing transaction
steps.
The Edit Transaction
An Edit transaction is a request to make a new digital work
by copying, selecting and modifying portions of an existing
digital work. This operation can actually change the contents
of a digital work. The kinds of changes that are permitted
depend on the process being used. Like the extraction operation, edit operates on portions of a digital work. In contrast
with the extract operation, edit does not effect the rights or
location of the work. It only changes the contents. The kinds
of changes permitted are determined by the type specification
of the processor specified in the rights. In the currently preferred embodiment, an edit transaction changes the work
itself and does not make a new work. However, it would be a
reasonable variation to cause a new copy of the work to be
made.
The requester sends the server a message to initiate an Edit
transaction. This message indicates the work to be
edited, the version of the edit right to be used in the
transaction, the file data for the work (including its size),
the process-ID for the process, and the number of copies
involved.
The server checks the compatibility of the process-ID to be
used by the requester against any process-ID specification in the right. If they are incompatible, it ends the
transaction with an error.
The repositories perform the common opening transaction
steps.
The requester uses the process to change the contents of the
digital work as desired. (For example, it can select and
duplicate parts of it; combine it with other information;
or compute functions based on the information. This can
amount to editing text, music, or pictures or taking whatever other steps are useful in creating a derivative work.)
The repositories perform the common closing transaction
steps.
The edit transaction is used to cover a wide range of kinds
of works. The category describes a process that takes as its
input any portion of a digital work and then modifies the input
in some way. For example, for text, a process for editing the
text would require edit rights. A process for "summarizing" or
counting words in the text would also be considered editing.
For a music file, processing could involve changing the pitch
or tempo, or adding reverberations, or any other audio effect.
For digital video works, anything which alters the image
would require edit rights. Examples would be colorizing,
scaling, extracting still photos, selecting and combining
frames into story boards, sharpening with signal processing,
and so on.
Some creators may want to protect the authenticity of their
works by limiting the kinds of processes that can be per-
Case 2:13-cv-01112 Document 1-4 Filed 12/18/13 Page 41 of 47 PageID #: 157
US 7,523,072 B2
41
42
formed on them. If there are no edit rights, then no processing
is allowed at all. A processor identifier can be included to
specifY what kind of process is allowed. If no process identifier is specified, then arbitrary processors can be used. For an
example of a specific process, a photographer may want to
allow use of his photograph but may not want it to be colorized. A musician may want to allow extraction of portions
of his work but not changing of the tonality.
a typical case, the software would be copied to file system of
the requester repository before it is installed.
The requester sends the server an Install message. This
message indicates the work to be installed, the version of
the Install right being invoked, and the file data for the
work (including its size).
The repositories perform the common opening transaction
steps.
The requester extracts a copy of the digital certificate for
the software. If the certificate cannot be found or the
master repository for the certificate is not known to the
requester, the transaction ends with an error.
The requester decrypts the digital certificate using the public key of the master repository, recording the identity of
the supplier and creator, a key for decrypting the software, the compatibility information, and a tamperchecking code. (This step certifies the software.)
The requester decrypts the software using the key from the
certificate and computes a check code on it using a
1-way hash function. If the check-code does not match
the tamper-checking code from the certificate, the installation transaction ends with an error. (This step assures
that the contents of the software, including the various
scripts, have not been tampered with.)
The requester retrieves the instructions in the compatibility-checking script and follows them. If the software is
not compatible with the repository, the installation transaction ends with an error. (This step checks platform
compatibility.)
The requester retrieves the instructions in the installation
script and follows them. Ifthere is an error in this process
(such as insufficient resources), then the transaction
ends with an error. Note that the installation process puts
the runnable software in a place in the repository where
it is no longer accessible as a work for exercising any
usage rights other than the execution of the software as
part of repository operations in carrying out other transactions.
The repositories perform the common closing transaction
steps.
Authorization Transactions
There are many ways that authorization transactions can be
defined. In the following, our preferred way is to simply
define them in terms of other transactions that we already
need for repositories. Thus, it is convenient sometimes to
speak of "authorization transactions," but they are actually
made up of other transactions that repositories already have.
A usage right can specifY an authorization-ID, which identifies an authorization object (a digital work in a file of a
standard format) that the repository must have and which it
must process. The authorization is given to the generic authorization (or ticket) server of the repository which begins to
interpret the authorization.
As described earlier, the authorization contains a server
identifier, which may just be the generic authorization server
or it may be another server. When a remote authorization
server is required, it must contain a digital address. It may also
contain a digital certificate.
If a remote authorization server is required, then the authorization process first performs the following steps:
The generic authorization server attempts to set up the
communications channel. (If the charmel cannot be set
up, then authorization fails with an error.)
When the channel is set up, it performs a registration process with the remote repository. (If registration fails,
then the authorization fails with an error.)
When registration is complete, the generic authorization
server invokes a "Play" transaction with the remote
repository, supplying the authorization document as the
digital work to be played, and the remote authorization
server (a program) as the "player." (If the player cannot
be found or has some other error, then the authorization
fails with an error.)
The authorization server then "plays" the authorization.
This involves decrypting it using either the public key of
the master repository that issued the certificate or the
session key from the repository that transmitted it. The
authorization server then performs various tests. These
tests vary according to the authorization server. They
include such steps as checking issue and validity dates of
the authorization and checking any hot-lists of known
invalid authorizations. The authorization server may
require carrying out any other transactions on the repository as well, such as checking directories, getting some
person to supply a password, or playing some other
digital work. It may also invoke some special process for
checking information about locations or recent events.
The "script" for such steps is contained within the authorization server.
If all of the required steps are completed satisfactorily, the
authorization server completes the transaction normally,
signaling that authorization is granted.
The Install Transaction
An Install transaction is a request to install a digital work as
rurmable software on a repository. In a typical case, the
requester repository is a rendering repository and the software would be a new kind or new version of a player. Also in
10
15
20
25
30
35
40
45
50
55
60
65
The Uninstall Transaction
An Uninstall transaction is a request to remove software
from a repository. Since uncontrolled or incorrect removal of
software from a repository could compromise its behavioral
integrity, this step is controlled.
The requester sends the server an Uninstall message. This
message indicates the work to be uninstalled, the version
of the Uninstall right being invoked, and the file data for
the work (including its size).
The repositories perform the common opening transaction
steps.
The requester extracts a copy of the digital certificate for
the software. If the certificate cannot be found or the
master repository for the certificate is not known to the
requester, the transaction ends with an error.
The requester checks whether the software is installed. If
the software is not installed, the transaction ends with an
error.
The requester decrypts the digital certificate using the public key of the master repository, recording the identity of
the supplier and creator, a key for decrypting the software, the compatibility information, and a tamperchecking code. (This step authenticates the certification
of the software, including the script for uninstalling it.)
The requester decrypts the software using the key from the
certificate and computes a check code on it using a
Case 2:13-cv-01112 Document 1-4 Filed 12/18/13 Page 42 of 47 PageID #: 158
US 7,523,072 B2
44
43
1-way hash function. If the check-code does not match
the tamper-checking code from the certificate, the installation transaction ends with an error. (This step assures
that the contents of the software, including the various
scripts, have not been tampered with.)
The requester retrieves the instructions in the uninstallation
script and follows them. Ifthere is an error in this process
(such as insufficient resources), then the transaction
ends with an error.
The repositories perform the common closing transaction
steps.
10
Distribution and Use Scenarios
To appreciate the robustness and flexibility of the present
invention, various distribution and use scenarios for digital
works are illustrated below. These scenarios are meant to be
exemplary rather than exhaustive.
Consumers as Unpaid Distributors
In this scenario, a creator distributes copies of his works to
various consumers. Each consumer is a potential distributor
of the work. If the consumer copies the digital work (usually
for a third party), a fee is collected and automatically paid to
the creator.
This scenario is a new twist for digital works. It depends on
the idea that "manufacturing" is just copying and is essentially free. It also assumes that the consumers as distributors
do not require a fee for their time and effort in distributing the
work.
This scenario is performed as follows:
A creator creates a digital work. He grants a Copy right
with fees paid back to himself. If he does not grant an Embed
right, then consumers cam10t use the mechanism to act as
distributors to cause fees to be paid to themselves on future
copies. Of course, they could negotiate side deals or trades to
transfer money on their own, outside of the system.
Paid Distributors
In another scenario, every time a copy of a digital work is
sold a fee is paid to the creator and also to the immediate
distributor.
This scenario does not give special status to any particular
distributor. Anyone who sells a document has the right to add
a fee to the sale price. The fee for sale could be established by
the consumer. It could also be a fixed nominal amount that is
contributed to the account of some charity.
This scenario is performed as follows:
A creator creates a digital work. He grants a Copy right
with fees to be paid back to himself. He grants an Embed
right, so that anyone can add shells to have fees paid to
themselves.
A distributor embeds the work in a shell, with fees specified
to be paid back to himself. If the distributor is content to
receive fees only for copies that he sells himself, he grants an
Extract right on the shell.
When a consumer buys a copy from the distributor, fees are
paid both to the distributor and to the creator. If he chooses,
the consumer can extract the work from the distributor's shell.
He cannot extract it from the creator's shell. He can add his
own shell with fees to be paid to himself.
Licensed Distribution
In this scenario, a creator wants to protect the reputation
and value of his work by making certain requirements on its
distributors. He issues licenses to distributors that satisfY the
requirements, and in tum, promises to reward their efforts by
assuring that the work will not be distributed over competing
15
20
25
30
35
40
45
50
55
60
65
channels. The distributors incur expenses for selecting the
digital work, explaining it to buyers, promoting its sale, and
possibly for the license itself. The distributor obtains the right
to enclose the digital work in a shell, whose function is to
permit the attachment of usage fees to be paid to the distributor in addition to the fees to be paid to the creator.
This differs from the previous scenario in that it precludes
the typical copy owner from functioning as a distributor, since
the consumer lacks a license to copy the document. Thus, a
consumer cannot make copies, even for free. All copies must
come initially from authorized distributors. This version
makes it possible to hold distributors accountable in some
way for the sales and support of the work, by controlling the
distribution of certificates that enable distributors to legitimately charge fees and copy owners to make copies. Since
licenses are themselves digital works, the same mechanisms
give the creators control over distributors by charging for
licenses and putting time limits on their validity.
This scenario is performed as follows:
A creator purchases a digital distribution license that he
will hand out to his distributors. He puts access requirements
(such as a personal license) on the Copy and Transfer rights
on the distribution license so that only he can copy or transfer
it.
The creator also creates a digital work. He grants an Embed
right and a Copy right, both of which require the distribution
license to be exercised. He grants a Play right so that the work
can be played by anyone. He may optionally add a Transfer or
Loan right, so that end consumers can do some non-commercia! exchange of the work among friends.
A distributor obtains the distribution license and a number
of copies of the work. He makes copies for his customers,
using his distribution license.
A customer buys and uses the work. He cannot make new
copies because he lacks a distribution license.
Super Distributors
This is a variation on the previous scenarios. A distributor
can sell to anyone and anyone can sell additional copies,
resulting in fees being paid back to the creator. However, only
licensed distributors can add fees to be paid to themselves.
This scenario gives distributors the right to add fees to
cover their own advertising and promotional costs, without
making them be the sole suppliers. Their customers can also
make copies, thus broadening the channel without diminishing their revenues. This is because distributors collect fees
from copies of any copies that they originally sold. Only
distributors can add fees.
This scenario is performed similarly to the previous ones.
There are two key differences. (1) The creator only grants
Embed rights for people who have a Distribution license. This
is done by putting a requirement for a distributor's license on
the Embed right. Consequently, non-distributors cannot add
their own fees. (2) The Distributor does not grant Extract
rights, so that consumers cannot avoid paying fees to the
Distributor if they make subsequent copies. Consequently, all
subsequent copies result in fees paid to the Distributor and the
Creator.
!-Level Distribution Fees
In this scenario, a distributor gets a fee for any copy he sells
directly. However, if one ofhis customers sells further copies,
he gets no further fee for those copies.
This scenario pays a distributor only for use of copies that
he actually sold.
This scenario is performed similarly to the previous ones.
The key feature is that the distributor creates a shell which
specifies fees to be paid to him. He puts Extract rights on the
Case 2:13-cv-01112 Document 1-4 Filed 12/18/13 Page 43 of 47 PageID #: 159
US 7,523,072 B2
45
46
shell. When a consumer buys the work, he can extract away
the distributor's shell. Copies made after that will not require
fees to be paid to the distributor.
on the interstitial material. He grants Extract rights on a
subset of the reused material. A consumer of the collection
can only extract portions that have that right. Fees are automatically collected for all parts of the collection.
Distribution Trees
In another scenario, distributors sell to other distributors
and fees are collected at each level. Every copy sold by any
distributor-even several d-blocks down in the chain-results in a fee being paid back to all of the previous distributors.
This scenario is like a chain letter or value chain. Every
contributor or distributor along the way obtains fees, and is
thereby encouraged to promote the sale of copies of the digital
work.
This scenario is performed similarly to the previous ones.
The key feature is that the distributor creates a shell which
specifies fees to be paid to him. He does not grant Extract
rights on the shell. Consequently, all future copies that are
made will result in fees paid to him.
Weighted Distribution Trees
In this scenario, distributors make money according to a
distribution tree. The fee that they make depends on various
parameters, such as time since their sale or the number of
subsequent distributors.
This is a generalized version of the Distribution Tree scenario, in that it tries to vary the fee to account for the significance of the role of the distributor.
This scenario is similar to the previous one. The difference
is that the fee specification on the distributor's shell has
provisions for changes in prices. For example, there could be
a fee schedule so that copies made after the passage of time
will require lower fees to be paid to the distributor. Alternatively, the distributor could employ a "best-price" billing
option, using any algorithm he chooses to determine the fee
up to the maximum specified in the shell.
Fees for Reuse
In this scenario, a first creator creates a work. It is distributed by a first distributor and purchased by a second creator.
The second creator extracts a portion of the work and embeds
in it a new work distributed by a second distributor. A consumer buys the new work from the second distributor. The
first creator receives fees from every transaction; the first
distributor receives fees only for his sale; the second creator
and second distributor receive fees for the final sale.
This scenario shows how that flexible automatic arrangements can be set up to create automatic charging systems that
mirror current practice. This scenario is analogous to when an
author pays a fee to reuse a figure in some paper. In the most
common case, a fee is paid to the creator or publisher, but not
to the bookstore that sold the book.
The mechanisms for derived works are the same as those
for distribution.
Limited Reuse
In this scenario, several first creators create works. A second creator makes a selection of these, publishing a collection
made up of the parts together with some new interstitial
material. (For example, the digital work could be a selection
of music or a selection of readings.) The second creator wants
to continue to allow some of the selected works to be extractable, but not the interstitial material.
This scenario deals with fine grained control of the rights
and fees for reuse.
This scenario is performed as follows:
The first creators create their original works. If they grant
extraction and embedding rights, then the second creator can
include them in a larger collected work. The second creator
creates the interstitial material. He does grant an Extract right
10
15
20
25
30
35
40
45
50
55
60
65
Commercial Libraries
Commercial libraries buy works with the right to loan.
They limit the loan period and charge their own fees for use.
This scenario deals with fees for loaning rather than fees for
making copies. The fees are collected by the same automatic
mechanisms.
The mechanisms are the same as previous scenarios except
that the fees are associated with the Loan usage right rather
than the Copy usage right.
Demo Versions
A creator believes that if people try his work that they will
want to buy it or use it. Consumers of his work can copy the
work for free, and play (or execute) a limited version of the
work for free, and can play or use the full featured version for
a fee. This scenario deals with fees for loaning rather than fees
for making copies. The fees are collected by the same automatic mechanisms.
This scenario is performed as follows:
The creator creates a digital work and grants various rights
and fees. The creator grants Copy and Embed rights without
a fee, in order to ensure widespread distribution of the work.
Another of the rights is a limited play right with little or no fee
attached. For example, this right may be for playing only a
portion of the work. The play right can have various restrictions on its use. It could have a ticket that limits the number of
times it is used. It could have internal restrictions that limit its
functionality. It could have time restrictions that invalidate the
right after a period of time or a period of use. Different fees
could be associated with other versions of the Play right.
Upgrading a Digital Work with a Vendor
A consumer buys a digital work together with an agreement that he can upgrade to a new version at a later date for a
modest fee, much less than the usual purchase price. When
the new version becomes available, he goes to a qualified
vendor to make the transaction.
This scenario deals with a common situation in computer
software. It shows how a purchase may include future
"rights." Two important features of the scenario are that the
transaction must take place at a qualified vendor, and that the
transaction can be done only once per copy of the digital work
purchased.
This scenario is performed as follows:
The creator creates a digital work, an upgrade ticket, and a
distribution license. The upgrade ticket uses the a generic
ticket agent that comes with repositories. As usual, the distribution license does not have Copy or Transfer rights. He
distributes a bundled copies of the work and the ticket to his
distributors as well as distribution licenses.
The distributor sells the old bundled work and ticket to
customers.
The customer extracts the work and the ticket. He uses the
work according to the agreements until the new version
becomes available.
When the new work is ready, the creator gives it to distributors. The new work has a free right to copy from a distributor
if a ticket is available.
The consumer goes to distributors and arranges to copy the
work. The transaction offers the ticket. The distributor's
repository punches the ticket and copies the new version to
the consumer's repository.
The consumer can now use the new version of the work.
Case 2:13-cv-01112 Document 1-4 Filed 12/18/13 Page 44 of 47 PageID #: 160
US 7,523,072 B2
47
48
Distributed Upgrading of Digital Works
A consumer buys a digital work together with an agreement that he can upgrade to a new version at a later date for a
modest fee, much less than the usual purchase price. When
the new version becomes available, he goes to anyone who
has the upgraded version and makes the transaction.
This scenario is like the previous one in that the transaction
can only be done once per copy of the digital work purchased,
but the transaction can be accomplished without the need to
connect to a licensed vendor.
This scenario is similar to the previous one except that the
Copy right on the new work does not require a distribution
license. The consumer can upgrade from any repository having the new version. He cannot upgrade more than once
because the ticket cannot work after it has been punched. If
desired, the repository can record the upgrade transaction by
posting a zero cost bill to alert the creator that the upgrade has
taken place.
be secretly embedded in the text itself (encoded in the grey
scale) or hidden in some other way.
Limited Printing
A consumer buys a digital work and wants to make a few
ephemeral copies. For example, he may want to print out a
paper copy of part of a digital newspaper, or he may want to
make a (first generation) analog cassette tape for playing in
his car. He buys the digital work together with a ticket
required for printing rights.
This scenario is like the common practice of people making
cassette tapes to play in their car. If a publisher permits the
making of cassette tapes, there is nothing to prevent a consumer from further copying the tapes. However, since the
tapes are "analog copies," there is a noticeable quality loss
with subsequent generations. The new contribution of the
present invention is the use of tickets in the access controls for
the making of the analog copies.
This scenario is performed as follows:
The creator sells a work together with limited printing
rights. The printing rights specify the kind of printer (e.g., a
kind of cassette recorder or a kind of desktop paper printer)
and also the kind of ticket required. The creator either bundles
a limited number of tickets or sells them separately. If the
tickets use the generic ticket agent, the consumer with the
tickets can exercise the right at his convenience.
Demand Publishing
Professors in a business school want to put together course
books of readings selected from scenario studies from various
sources. The bookstore wants to be able to print the books
from digital masters, without negotiating for and waiting for
approval of printing of each of the scenarios. The copyright
holders of the scenarios want to be sure that they are paid for
every copy of their work that is printed.
On many college campuses, the hassle of obtaining copy
clearances in a timely way has greatly reduced the viability of
preparing course books. Print shops have become much more
cautious about copying works in the absence of documented
permission.
Demand Publishing is performed as follows: the creator
sells a work together with printing rights for a fee. There can
be rights to copy (distribute) the work between bookstore
repositories, with or without fee. The printing rights specify
the kind of printer. Whenever a bookstore prints one of the
works (either standalone or embedded in a collection), the fee
is credited to the creator automatically. To discourage unauthorized copying of the print outs, it would be possible for the
printer to print tracer messages discretely on the pages identifYing the printing transaction, the copy number, and any
other identifYing information. The tracer information could
10
15
20
25
30
35
40
45
50
55
60
65
Metered Use and Multiple Price Packages
A consumer does not know what music to purchase until he
decides whether he likes it. He would like to be able to take it
home and listen to it, and then decide whether to purchase.
Furthermore, he would like the flexibility of paying less if he
listens to it very infrequently.
This scenario just uses the capability of the approach to
have multiple versions of a right on a digital work. Each
version of the right has its own billing scheme. In this scenario, the creator of the work can offer the Copy right without
fee, and defer billing to the exercise of the Play right. One
version of the play right would allow a limited performance
without fee-a right to "demo". Another version of the right
could have a metered rate, of say $0.25 per hour of play.
Another version could have a fee of $15.00 for the first play,
but no fee for further playing. When the consumer exercises a
play right, he specifies which version of the right is being
selected and is billed accordingly.
Fees for Font Usage
A designer of type fonts invests several months in the
design of special fonts. The most common way of obtaining
revenue for this work is to sell copies of the fonts to publishers
for unlimited use over unlimited periods of time. A font
designer would like to charge a rate that reflects the amount
that the font is used.
This scenario is performed as follows: the font designer
creates a font as a digital work. He creates versions of the Play
right that bill either for metered use or "per-use". Each version of the play right would require that the player (a print
layout program) be of an approved category. The font
designer assigns appropriate fees to exercise the Copy right.
When a publisher client wants to use a font, he includes it as
input to a layout program, and is billed automatically for its
use. In this way, a publisher who makes little use of a font pays
less than one who uses it a lot.
Rational Database Usage Charges
Online information retrieval services typically charge for
access in a way that most clients find unpredictable and
uncorrelated to value or information use. The fee depends on
which databases are open, dial-up connect time, how long the
searches require, and which articles are printed out. There are
no provisions for extracting articles or photographs, no
method for paying to reuse information in new works, no
distinction between having the terminal sit idly versus
actively searching for data, no distinction between reading
articles on the screen and doing nothing, and higher rates per
search when the centralized facility is busy and slow servicing other clients. Articles can not be offioaded to the client's
machine for off-site search and printing. To offer such billing
or the expanded services, the service company would need a
secure way to account for and bill for how information is
used.
This scenario is performed as follows:
The information service bundles its database as files in a
repository. The information services company assigns different fees for different rights on the information files. For
example, there could be a fee for copying a search database or
a source file and a different fee for printing. These fees would
be in addition to fees assigned by the original creator for the
services. The fees for using information would be different
for using them on the information service company's computers or the client's computers. This billing distinction
would be controlled by having different versions of the rights,
Case 2:13-cv-01112 Document 1-4 Filed 12/18/13 Page 45 of 47 PageID #: 161
US 7,523,072 B2
49
50
where the version for use on the service company's computer
requires a digital certificate held locally. Fees for copying or
printing files would be handled in the usual way, by assigning
fees to exercising those rights. The distinction between
searching and viewing information would be made by having
different "players" for the different functions. This distinction would be maintained on the client's computers as well as
the service computers. Articles could be extracted for reuse
under the control of Extract and Embed rights. Thus, if a
client extracts part of an article or photograph, and then sells
copies of a new digital work incorporating it, fees could
automatically be collected both by the information service
and earlier creators and distributors of the digital work. In this
way, the information retrieval service could both offer a wider
selection of services and billing that more accurately reflects
the client's use of the information.
ments therein may be made by those skilled in the art, which
are intended to be encompassed by the following claims.
APPENDIX A
Glossary
10
15
Print Spooling with Rights
20
Authorization Repository:
A special type of repository which provides an authorization service. An authorization may be specified by a usage
right. The authorization must be obtained before the right
may be exercised.
Billing Clearinghouse:
A financial institution or the like whose purpose is to reconcile billing information received from credit servers. The
billing clearinghouse may generate bills to users or alternatively, credit and debit accounts involved in the commercial
transactions.
In the simplest scenario, when a user wants to print a digital
Billing Transactions:
document he issues a print command to the user interface. If
The protocol used by which a repository reports billing
the document has the appropriate rights and the conditions are
information to a credit server.
satisfied, the user agrees to the fee and the document is
printed. In other cases, the printer may be on a remote reposi- 25 Clearinghouse Transactions:
The protocol used between a credit server and a clearingtory and it is convenient to spool the printing to a later time.
house.
This leads to several issues. The user requesting the printing
wants to be sure that he is not billed for the printing until the
Composite Digital Work:
document is actually printed. Restated, if he is billed at the
A digital work comprised of distinguishable parts. Each of
30
time the print job is spooled but the job is canceled before
the distinguishable parts is itself a digital work which has
printing is done, he does not want to pay. Another issue is that
usage rights attached.
when spooling is permitted, there are now two times at which
Content:
rights, conditions and fees could be checked: the time at
The digital information (i.e. raw bits) representing a digital
which a print job is spooled and the time at which a print is 35
work.
made. As with all usage rights, it is possible to have rights that
expire and to have rights whose fee depends on various conCopy Owner:
ditions. What is needed is a means to check rights and conA term which refers to the party who owns a digital work
ditions at the time that printing is actually done.
stored in a repository. In the typical case, this party has pur40
chased various rights to the document for printing, viewing,
This scenario is performed as follows: A printing repositransferring, or other specific uses.
tory is a repository with the usual repository characteristics
plus the hardware and software to enable printing. Suppose
Creator:
that a user logs into a home repository and wants to spool print
A term which refers to a party who produces a digital work.
jobs for a digital work at a remote printing repository. The 45
user interface for this could treat this as a request to "spool"
Credit Server:
prints. Underneath this "spooling" request, however, are stanA device which collects and reports billing information for
dardrights and requests. To support such requests, the creator
a repository. In many implementations, this could be built as
part of a repository. It requires a means for periodically comof the work provides a Copy right, which can be used to copy
50 municating with a billing clearinghouse.
the work to a printing repository. In the default case, this Copy
right would have no fees associated for making the copy.
Description Tree:
However, the Next-Set-Of-Rights for the copy would only
A structure which describes the location of content and the
include the Print rights, with the usual fees for each variation
usage rights and usage fees for a digital work. A description
of printing. This version of the Copy right could be called the 55 tree is comprised of description blocks. Each description
"print spooling" version of the Copy right. The user's "spool
block corresponds to a digital work or to an interest (typically
request" is implemented as a Copy transaction to put a copy of
a revenue bearing interest) in a digital work.
the work on the printing repository, followed by Print transDigital Work (Work):
actions to create the prints of the work. In this way, the user is
Any encapsulated digital information. Such digital inforonly billed for printing that is actually done. Furthermore, the 60
mation may represent music, a magazine or book, or a mulrights, conditions and fees for printing the work are detertimedia composition. Usage rights and fees are attached to the
mined when the work is about to be printed.
digital work.
Thus, a system for enforcing the usage rights of digital
works is disclosed. While the embodiments disclosed herein 65 Distributor:
are preferred, it will be appreciate from this teaching that
A term which refers to a party who legitimately obtains a
various alternative, modifications, variations or improvecopy of a digital work and offers it for sale.
Case 2:13-cv-01112 Document 1-4 Filed 12/18/13 Page 46 of 47 PageID #: 162
US 7,523,072 B2
51
52
Identification (Digital) Certificate:
A signed digital message that attests to the identity of the
possessor. Typically, digital certificates are encrypted in the
private key of a well-known master repository.
Usage Transactions:
A set of protocols by which repositories communicate in
the exercise of a usage rights. Each usage right has it's own
transaction steps.
Master Repository:
A special type of repository which issues identification
certificates and distributes lists of repositories whose integrity have been compromised and which should be denied
access to digital works (referred to as repository "hotlists".)
What is claimed:
1. A method for securely rendering digital documents,
comprising:
retrieving, by a document platform, a digital document and
10
at least one usage right associated with the digital docuPublic Key Encryption:
ment from a document repository, the at least one usage
An encryption technique used for secure transmission of
right specifying a manner of use indicating the manner
messages on a communication channel. Key pairs are used for
in which the digital document can be rendered;
the encryption and decryption of messages. Typically one key
storing
the digital document and the at least one usage right
is referred to as the public key and the other is the private key. 15
in separate files in the document platform;
The keys are inverses of each other from the perspective of
determining, by the document platform, whether the digital
encryption. Restated, a digital work that is encrypted by one
document may be rendered based on the at least one
key in the pair can be decrypted only by the other.
usage right; and
Registration Transactions:
20
if the at least one usage right allows the digital document to
The protocol used between repositories to establish a
be rendered on the document platform, rendering the
trusted session.
digital document by the document platform.
2. The method as recited in claim 1, wherein the manner of
Rendering Repository:
use includes the number of times the digital document can be
A special type of repository which is typically coupled to a
25 rendered.
rendering system. The rendering repository will typically be
3. The method as recited in claim 1, wherein at least a
embodied within the secure boundaries of a rendering system.
portion of the digital document is a software program.
Rendering System:
4. The method as recited in claim 1, wherein the at least one
The combination of a rendering repository and a rendering
usage right comprises a revenue identifier for identifying a
device. Examples of a rendering systems include printing 30
revenue owner of the digital document.
systems, display systems, general purpose computer systems,
5. The method as recited in claim 1, wherein the at least one
video systems or audio systems.
usage right also specifies one or more conditions which must
Repository:
be satisfied before the manner of rendering may be exercised.
Conceptually a set of functional specifications defining 35
6. The method as recited in claim 5, wherein at least one
core functionality in the support of usage rights. A repository
condition includes determining the presence of a digital
is a trusted system in that it maintains physical, communicaticket.
tions and behavioral integrity.
7. The method as recited in claim 1, wherein the at least one
usage right or a part of the digital document is stored on a
Requester Mode:
A mode of a repository where it is requesting access to a 40 removable storage device.
8. The method as recited in claim 1, wherein at least one
digital work.
part of the digital document and the at least one usage right are
Revenue Owners:
stored on a same device.
A term which refers to the parties that maintain an interest
9. The method as recited in claim 1, wherein at least one
in collecting fees for document use or who stand to lose 45 part of the digital document and the at least one usage right are
revenue if illegitimate copies of the digital work are made.
stored on different devices.
Server Mode:
10. A method for securely rendering digital documents,
comprising:
A mode of a repository where it is processing an incoming
request to access a digital work.
storing a digital document and at least one usage right in
50
separate files in a document repository, wherein the at
Shell Description Block:
least one usage right is associated with the digital docuA special type of description block designating an interest
ment;
in a digital work, but which does not add content. This will
receiving a request from a document platform for access to
typically be added by a distributor of a digital work to add
the digital document;
55
their fees.
determining, by the document platform, whether the
Transactions:
request may be granted based on the at least one usage
A term used to refer to the protocols by which repositories
right, the determining step including authenticating the
communicate.
document platform and determining whether the at least
one usage right includes a manner of use that allows
Usage Fees:
60
transfer of the digital document to the document platA fee charged to a requester for access to a digital work.
form;
Usage fees are specified within the usage rights language.
if the at least one usage right allows the transfer of the
Usage Rights:
digital document to the document platform, transferring
the digital document and the at least one usage right
A language for defining the manner in which a digital work 65
may be used or distributed, as well as any conditions on which
associated with the digital document to the document
use or distribution is premised.
platform;
Case 2:13-cv-01112 Document 1-4 Filed 12/18/13 Page 47 of 47 PageID #: 163
US 7,523,072 B2
53
54
storing the digital document and the at least one usage right
in the document platform, wherein the at least one usage
right is stored in a separate file from the digital document; and
rendering the digital document by the document platform.
11. The method as recited in claim 10, wherein at least a
portion of the digital document is a software program.
12. The method as recited in claim 10, wherein the at least
one usage right comprises a revenue identifier for identifying
a revenue owner of the digital document.
13. The method as recited in claim 10, wherein the at least
one usage right also specifies one or more conditions which
must be satisfied before the manner of rendering may be
exercised.
14. The method as recited in claim 13, wherein at least one
condition includes determining the presence of a digital
ticket.
15. The method as recited in claim 10, wherein the at least
one usage right or a part of the digital document is stored on
a removable storage device.
16. The method as recited in claim 10, wherein at least one
part of the digital document and the at least one usage right are
stored on a same device.
17. The method as recited in claim 10, wherein at least one
part of the digital document and the at least one usage right are
stored on different devices.
18. A method for securely rendering digital documents,
comprising:
receiving a request from a document platform to transfer a
digital document from a document repository to the
document platform, the digital document having at least
one usage right associated therewith;
authenticating the document platform by accessing at least
one identifier associated with the document platform or
with a user of the document platform and determining
whether the identifier is associated with at least one of
the document platform and a user authorized to use the
digital document;
if the authenticating step is successful, determining
whether the digital document may be transferred and
stored on the document platform based on a manner of
use included in the at least one usage right;
if the at least one usage right allows the digital document to
be transferred to the document platform, transferring the
digital document and the at least one usage right associated with the digital document to the document platform;
storing the digital document and the at least one usage right
in the document platform, wherein the at least one usage
right is stored in a separate file from the digital document; determining, by the document platform, whether
the digital document may be rendered based on the at
least one usage right; and
if the at least one usage right allows the digital document to
be rendered on the document platform, rendering the
digital document by the document platform.
19. The method as recited in claim 18, wherein at least a
portion of the digital document is a software program.
20. The method as recited in claim 18, wherein the at least
one usage right comprises a revenue identifier for identifying
a revenue owner of the digital content.
21. The method as recited in claim 18, wherein the at least
one usage right also specifies one or more conditions which
must be satisfied before the manner of rendering may be
exercised.
22. The method as recited in claim 21, wherein at least one
condition includes determining the presence of a digital
ticket.
23. The method as recited in claim 18, wherein the at least
one usage right or a part of the digital document is stored on
a removable storage device.
24. The method as recited in claim 18, wherein at least one
part of the digital document and at least one usage right are
stored on a same device.
25. The method as recited in claim 18, wherein at least one
part of the digital document and the at least one usage right are
stored on different devices.
10
15
20
25
30
35
* * * * *
Case 2:13-cv-01112 Document 1-5 Filed 12/18/13 Page 1 of 29 PageID #: 164
Exhibit E
Case 2:13-cv-01112 Document 1-5 Filed 12/18/13 Page 2 of 29 PageID #: 165
111111
1111111111111111111111111111111111111111111111111111111111111
US007774280B2
c12)
(54)
United States Patent
(10)
Nguyen et al.
(45)
Patent No.:
Date of Patent:
(56)
SYSTEM AND METHOD FOR MANAGING
TRANSFER OF RIGHTS USING SHARED
STATE VARIABLES
U.S. PATENT DOCUMENTS
Inventors: Mai Nguyen, Buena Park, CA (US); Xin
Wang, Torrance, CA (US); Thanh Ta,
Huntington Beach, CA (US); Guillermo
Lao, Torrance, CA (US); Eddie J. Chen,
Rancho Palos Verdes, CA (US)
(73)
Assignee: ContentGuard Holdings, Inc.,
Wilmington, DE (US)
( *)
Notice:
Appl. No.: 10/956,121
(22)
Filed:
(65)
FOREIGN PATENT DOCUMENTS
BR
10/2001
OTHER PUBLICATIONS
Workshop on Digital Rights Management for the Web, World Wide
Web Consortium, Minutes from the Architecture/Infrastructure Session, Jan. 2001. *
(Continued)
Prior Publication Data
Primary Examiner-Andrew J. Fischer
Assistant Examiner-Thomas West
(7 4 )Attorney, Agent, or Firm-Nixon Peabody, LLP; Marc S.
Kaufman; Stephen M. Hertzler
Mar. 17, 2005
Related U.S. Application Data
(63)
Continuation-in-part of application No. 10/162,701,
filed on Jun. 6, 2002.
(60)
Provisional application No. 60/331,624, filed on Nov.
20, 2001, provisional application No. 60/331,623,
filed on Nov. 20, 2001, provisional application No.
60/331,621, filed on Nov. 20, 2001, provisional application No. 60/296,113, filed on Jun. 7, 2001, provisional application No. 60/296,117, filed on Jun. 7,
2001, provisional application No. 60/296,118, filed on
Jun. 7, 2001.
(52)
(58)
9810967 A
(Continued)
Oct. 4, 2004
US 2005/0060571 Al
(51)
7/1966 Bargen eta!.
(Continued)
Subject to any disclaimer, the term of this
patent is extended or adjusted under 35
U.S.C. 154(b) by 1529 days.
(21)
Aug. 10, 2010
References Cited
3,263,158 A
(75)
US 7,774,280 B2
(57)
ABSTRACT
A method, system and device for transferring rights adapted
to be associated with items from a rights supplier to a rights
consumer, including obtaining a set of rights associated with
an item, the set of rights including meta-rights specifying
derivable rights that can be derived from the meta-; determining whether the rights consumer is entitled to the derivable
rights specified by the meta-rights; and deriving at least one
right from the derivable rights, if the rights consumer is
entitled to the derivable rights specified by the meta-rights,
wherein the derived right includes at least one state variable
based on the set of rights and used for determining a state of
the derived right.
Int. Cl.
G06F 7104
(2006.01)
G06F 7130
(2006.01)
H04N 7116
(2006.01)
U.S. Cl. ........................................... 705/59; 726/27
Field of Classification Search .............. 705/50-79
See application file for complete search history.
36 Claims, 14 Drawing Sheets
10
70
I
40
-
!0
Activation
60
Clearinghouse
2Q
Case 2:13-cv-01112 Document 1-5 Filed 12/18/13 Page 3 of 29 PageID #: 166
US 7,774,280 B2
Page 2
U.S. PATENT DOCUMENTS
3,609,697
3,790,700
3,798,605
4,159,468
4,200,700
4,220,991
4,278,837
4,323,921
4,361,851
4,423,287
4,429,385
4,442,486
4,529,870
4,558,176
4,593,376
4,614,861
4,621,321
4,644,493
4,658,093
4,713,753
4,736,422
4,740,890
4,796,220
4,816,655
4,817,140
4,827,508
4,868,376
4,888,638
4,891,838
4,924,378
4,932,054
4,937,863
4,949,187
4,953,209
4,961,142
4,975,647
4,977,594
4,999,806
5,010,571
5,014,234
5,023,907
5,047,928
5,050,213
5,052,040
5,058,164
5,103,476
5,113,519
5,129,083
5,136,643
5,138,712
5,146,499
5,148,481
5,159,182
5,174,641
5,183,404
5,191,193
5,204,897
5,222,134
5,235,642
5,247,575
5,255,106
5,260,999
5,263,157
5,263,158
5,276,444
5,276,735
5,287,408
5,291,596
5,293,422
5,301,231
5,311,591
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
9/1971
2/1974
3/1974
6/1979
4/1980
9/1980
7/1981
4/1982
1111982
12/1983
111984
4/1984
7/1985
12/1985
6/1986
9/1986
1111986
2/1987
4/1987
12/1987
4/1988
4/1988
111989
3/1989
3/1989
5/1989
9/1989
12/1989
111990
5/1990
6/1990
6/1990
8/1990
8/1990
10/1990
12/1990
12/1990
3/1991
4/1991
5/1991
6/1991
9/1991
9/1991
9/1991
10/1991
4/1992
5/1992
7/1992
8/1992
8/1992
9/1992
9/1992
10/1992
12/1992
2/1993
3/1993
4/1993
6/1993
8/1993
9/1993
10/1993
1111993
1111993
1111993
111994
111994
2/1994
3/1994
3/1994
4/1994
5/1994
Blevins et al.
Callais eta!.
Feistel
Barnes eta!.
Mader
Hamano et a!.
Best
Guillou
Asip et al.
Zeidler
Cichelli eta!.
Mayer
Chaurn
Arnold eta!.
Yolk
Pavlov eta!.
Boebert et a!.
Chandra et a!.
Hellman
Boebert et a!.
Mason
William
Wolfe
Musycket a!.
Chandra et a!.
Shear
Lessin et al.
Bohn
Faber
Hershey et a!.
Chou eta!.
Robert eta!.
Cohen
Ryder, Sr. eta!.
Elliott et a!.
Downer eta!.
Shear
Chernow et a!.
Katznelson
Edwards, Jr.
Johnson et a!.
Wiedemer
Shear
Preston et al.
Elmer eta!.
Waite et al.
Johnson et a!.
Cutler eta!.
Fischer
Corbin
Geffrotin
Abraham et al.
Eisele
Lim
Aldous eta!.
LeRoux
Wyman
Waite et al.
Wobber eta!.
Sprague et a!.
Castro
Wyman
Janis
Janis
McNair
Boebert et a!.
Samson
Mita
Loiacono
Abraham et al.
Fischer
5,319,705
5,335,275
5,337,357
5,339,091
5,341,429
5,347,579
5,381,526
5,386,369
5,390,297
5,394,469
5,410,598
5,412,717
5,414,852
5,428,606
5,432,849
5,438,508
5,444,779
5,453,601
5,455,953
5,457,746
5,473,687
5,473,692
5,485,577
5,499,298
5,502,766
5,504,814
5,504,816
5,504,818
5,504,837
5,509,070
5,530,235
5,532,920
5,534,975
5,535,276
5,539,735
5,553,143
5,557,678
5,563,946
5,564,038
5,568,552
5,619,570
5,621,797
5,625,690
5,629,980
5,633,932
5,634,012
5,636,346
5,638,443
5,638,513
5,649,013
5,655,077
5,708,709
5,708,717
5,715,403
5,734,823
5,734,891
5,737,413
5,737,416
5,745,569
5,745,879
5,748,783
5,757,907
5,761,686
5,764,807
5,765,152
5,768,426
5,787,172
5,790,677
5,812,664
5,825,876
5,825,879
5,825,892
5,838,792
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
6/1994
8/1994
8/1994
8/1994
8/1994
9/1994
111995
111995
2/1995
2/1995
4/1995
5/1995
5/1995
6/1995
7/1995
8/1995
8/1995
9/1995
10/1995
10/1995
12/1995
12/1995
111996
3/1996
3/1996
4/1996
4/1996
4/1996
4/1996
4/1996
6/1996
7/1996
7/1996
7/1996
7/1996
9/1996
9/1996
10/1996
10/1996
10/1996
4/1997
4/1997
4/1997
5/1997
5/1997
5/1997
6/1997
6/1997
6/1997
7/1997
8/1997
111998
111998
2/1998
3/1998
3/1998
4/1998
4/1998
4/1998
4/1998
5/1998
5/1998
6/1998
6/1998
6/1998
6/1998
7/1998
8/1998
9/1998
10/1998
10/1998
10/1998
1111998
Halter et al.
Millar eta!.
Chou et al.
Yamazaki et a!.
Stringer et a!.
Blandford
Elison
Christiano
Barber eta!.
Nagel eta!.
Shear
Fischer
Kramer et a!.
Moskowitz
Johnson et al.
Wyman
Daniele
Rosen
Russell
Dolphin
Lipscomb et al.
Davis
Eyer eta!.
Narasirnhalu et al.
Boebert et a!.
Miyahara
Hamilton et a!.
Okano
Griffeth et a!.
Schull
Stefik eta!.
Hartrick et a!.
Stefik eta!.
Ganesan
Moskowitz
Ross eta!.
Ganesan
Cooper et al.
Grantz eta!.
Davis
Tsutsui
Rosen
Michel eta!.
Stefik eta!.
Davis et al.
Stefik eta!.
Saxe
Stefik eta!.
Ananda
Stuckey et a!.
Jones eta!.
Rose
Alasia
Stefik
Saigh eta!.
Saigh
Akiyama et al.
Cooper et al.
Moskowitz et a!.
Wyman
Rhoads
Cooper et al.
Bloomberg
Pearlman et a!.
Erickson
Rhoads
Arnold
Fox eta!.
Bernobich et a!.
Peterson
Davis
Braudaway et a!.
Ganesan
Case 2:13-cv-01112 Document 1-5 Filed 12/18/13 Page 4 of 29 PageID #: 167
US 7,774,280 B2
Page 3
5,848,154
5,848,378
5,850,443
5,892,900
5,910,987
5,915,019
5,917,912
5,920,861
5,933,498
5,940,504
5,943,422
5,949,876
5,982,891
5,987,134
5,999,624
5,999,949
6,006,332
6,020,882
6,044,466
6,047,067
6,073,234
6,091,777
6,112,181
6,112,239
6,115,471
6,135,646
6,138,119
6,141,754
6,157,719
6,157,721
6,169,976
6,185,683
6,189,037
6,189,146
6,209,092
6,216,112
6,219,652
6,226,618
6,233,684
6,236,971
6,237,786
6,240,185
6,253,193
6,266,618
6,292,569
6,301,660
6,307,939
6,327,652
6,330,670
6,345,256
6,353,888
6,363,488
6,389,402
6,397,333
6,397,355
6,401,211
6,405,369
6,424,717
6,424,947
6,487,659
6,516,052
6,516,413
6,523,745
6,796,555
200110009026
200110011276
200110014206
200110037467
200110039659
2002/0001387
2002/0035618
2002/0044658
2002/0056118
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A *
A
A
A
A
A
A
A
A
A
A
A
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1 *
B1
B1
B1
B1
B1
B2
B1
B1
B1
A1
A1
A1
A1
A1
A1
A1
A1
A1
12/1998
12/1998
12/1998
4/1999
6/1999
6/1999
6/1999
7/1999
8/1999
8/1999
8/1999
9/1999
1111999
1111999
12/1999
12/1999
12/1999
212000
3/2000
4/2000
6/2000
7/2000
8/2000
8/2000
9/2000
10/2000
10/2000
10/2000
12/2000
12/2000
112001
2/2001
2/2001
2/2001
3/2001
4/2001
4/2001
5/2001
5/2001
5/2001
5/2001
5/2001
6/2001
7/2001
9/2001
10/2001
10/2001
12/2001
12/2001
212002
3/2002
3/2002
5/2002
5/2002
5/2002
6/2002
6/2002
7/2002
7/2002
1112002
2/2003
2/2003
2/2003
9/2004
7/2001
8/2001
8/2001
1112001
1112001
112002
3/2002
4/2002
5/2002
Nishio eta!.
Shelton et a!.
Van Oorschot et al.
Ginter et al.
Ginter et al.
Ginter et al.
Ginter et al.
Hallet a!.
Schneck et a!.
Griswold
VanWie eta!.
Ginter et al.
Ginter et al.
Shin eta!.
Hopkins
Crandall
Rabne et al.
Kinghorn et a!.
Anand eta!. ................... 726/1
Rosen
Kigo eta!.
Guetz eta!.
Shear eta!.
Kenner eta!.
Oki et al.
Kahnet a!.
Hallet a!.
Choy
Wasilewski eta!.
Shear eta!.
Colosso
Ginter et al.
Adams eta!.
Misra eta!.
Linnartz
Fuller eta!.
Carteret a!.
Downs eta!.
Stefik eta!.
Stefik eta!.
Ginter et al.
VanWie eta!.
Ginter et al.
Ye eta!.
Shear eta!.
Benson
Vigarie
England et al.
England et al.
Milsted eta!.
Kakehi eta!.
Ginter et al.
Ginter et al.
Sohne eta!.
Curtis eta!. .................. 714/38
Brezak, Jr. eta!.
Tsuria
Pinder et al.
T suria et al.
Kigo eta!.
Voudouris
Aratani et a!.
Tarnori
Blahut
Terao eta!.
Durst, Jr. et a!.
Arti galas et al.
O'Toole, Jr. eta!.
Simmons eta!.
Dillon
Mendez eta!.
Wasilewski eta!.
Hunter eta!.
2002/0069282
2002/0099948
2002/0127423
2003/0097 567
2004/0052370
2004/0172552
A1
A1
A1
A1
A1
A1
6/2002
7/2002
9/2002
5/2003
3/2004
9/2004
Reisman
Kocher eta!.
Kayanakis
Terao eta!.
Katznelson
Boyles et al.
FOREIGN PATENT DOCUMENTS
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
GB
GB
GB
GB
GB
GB
GB
GB
JP
JP
JP
JP
JP
JP
JP
JP
JP
JP
JP
JP
JP
JP
JP
JP
JP
JP
JP
JP
JP
JP
JP
wo
wo
wo
wo
wo
0 067 556
0084441
0 180 460
0 257 585
0 262 025
0 332 304
0 332 707
0 393 806
0 450 841
0 529 261
0 613 073
0 651 554
0 668 695
0 678 836
0 679 977
0 715 243
0 715 244
0 715 245
0 725 376
0731404
0 763 936
0 818 748
0 840 194
0 892 521
0 934 765
0 946 022
0 964 572
1 103 922
1483282
2022969
2 136 175
2 236 604
2236604
2309364
2316503
2354102
62-241061
64-068835
3-063717
04-369068
5-100939
5168039
05-268415
6-131371
06-175794
06-215010
7-36768
07-084852
07-200317
07-244639
0 715 241
11031130
11032037
11205306
11215121
2000215165
2005218143
2005253109
2006180562
WO 83/04461
wo 92/20022
WO 92/20022
wo 93/01550
WO 93/01550
B1
A2
A2
A2
A2
A2
A2
A1
A1
A1
A1
A1
A1
A1
A2
A2
A2
A2
A1
A2
A1
A
A
A
A
A
A
A2
A
A2
A2
A2
A2
A2
A2
A2
A1
A1
A1
12/1982
7/1983
5/1986
3/1988
3/1988
9/1989
9/1989
10/1990
10/1991
3/1993
8/1994
5/1995
8/1995
10/1995
1111995
6/1996
6/1996
6/1996
8/1996
9/1996
3/1997
111998
5/1998
111999
8/1999
9/1999
12/1999
5/2001
8/1977
12/1979
9/1984
4/1991
4/1991
7/1997
2/1998
3/2001
10/1987
3/1989
3/1991
12/1992
4/1993
7/1993
10/1993
5/1994
6/1994
8/1994
2/1995
3/1995
8/1995
9/1995
6/1996
2/1999
2/1999
7/1999
8/1999
8/2000
8/2005
9/2005
7/2006
12/1983
1111992
1111992
111993
111993
Case 2:13-cv-01112 Document 1-5 Filed 12/18/13 Page 5 of 29 PageID #: 168
US 7,774,280 B2
Page 4
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
WO 93/11480
wo 94/01821
WO 94/03003
WO 96/13814
wo 96/24092
WO 96/24092
WO 96/27155
WO 97/25800
WO 97/37492
WO 97/41661
WO 97/43761
wo 97/48203
WO 98/09209
WO 98/10561
wo 98/11690
WO 98/11690
WO 98/19431
wo 98/42098
WO 98/43426
WO 98/45768
WO 99/24928
WO 99/34553
WO 99/35782
WO 99/48296
wo 99/49615
WO 99/60461
WO 99/60750
WO 00/04727
WO 00/05898
wo 00/20950
WO 00/46994
WO 00/59152
WO 00/62260
W000/72118
WO 00/73922
WO 01103044
WO 01137209
wo 01163528
WO 2004/34223
wo 2004/103843
A1
A1
A1
A2
A2
A1
A1
A2
A2
A1
A1
A1
A1
A1
A1
A2
A1
A1
A1
A1
A2
A2
A2
A1
A2
A1
A1
A2
A1
A1
A2
6/1993
111994
2/1994
5/1996
8/1996
8/1996
9/1996
7/1997
10/1997
1111997
1111997
12/1997
3/1998
3/1998
3/1998
3/1998
5/1998
9/1998
10/1998
10/1998
5/1999
7/1999
7/1999
9/1999
9/1999
1111999
1111999
1/2000
212000
4/2000
8/2000
10/2000
10/2000
1112000
12/2000
1/2001
5/2001
8/2001
4/2004
12/2004
OTHER PUBLICATIONS
"National Semiconductor and EPR Partner for Information Metering/Data Security Cards" Mar. 4, 1994, Press Release from Electronic Publishing Resources, Inc.
Weber, R., "Digital Rights Management Technology" Oct. 1995.
Flasche, U. et a!., "Decentralized Processing of Documents", pp.
119-131, 1986, Comput. & Graphics, vol. 10, No.2.
Mori, R. et al., "Superdistribution: The Concept and the Architecture", pp. 1133-1146, 1990. The Transactions of the IEICE, Vo. E 73,
No.7, Tokyo, JP.
Weber, R., "Metering Technologies for Digital Intellectual Property",
pp. 1-29, Oct. 1994, A Report to the International Federation of
Reproduction Rights Organizations.
Clark, P.C. et al., "Bits: A Smartcard protected Operating System",
pp. 66-70 and 94, Nov. 1994, Communications of the ACM, vol. 37,
No. 11.
Ross, P.E., "Data Guard", pp. 101, Jun. 6, 1994, Forbes.
Saigh, W.K., "Knowledge is Sacred", 1992, Video Pocket/Page
Reader Systems, Ltd.
Kahn, R.E., "Deposit, Registration and Recordation in an Electronic
Copyright Management System", pp. 1-19, Aug. 1992, Corporation
for National Research Initiatives, Virginia.
Hilts, P. et al., "Books While U Wait", pp. 48-50, Jan. 3, 1994,
Publishers Weekly.
Strattner, A, "Cash Register on a Chip may Revolutionaize Software
Pricing and Distribution; Wave Systems Corp.", pp. 1-3, Apr. 1994,
Computer Shopper, vol. 14, No.4, ISSN 0886-0556.
O'Conner, M., "New Distribution Option for Electronic Publishers;
iOpener Data Encryption and Metering System for CD-ROM use;
Column", pp. 1-6, Mar. 1994, CD-ROM Professional, vol. 7, No.2,
ISSN: 1409-0833.
Willett, S., "Metered PCs: Is Your System Watching You? Wave
System beta tests new technology", pp. 84, May 2, 1994, InfoWorld.
Linn, R., "Copyright and Information Services in the Context of the
National Research and Education Network", pp. 9-20, Jan. 1994,
IMA Intellectual Property Project Proceedings, vol. 1, Issue 1.
Perrit, Jr., H., "Permission Headers and Contract Law", pp. 27-48,
Jan. 1994, IMA Intellectual Property Project Proceedings, vol. 1,
Issue 1.
Upthegrove, L., "Intellectual Property Header Descriptors: A
Dynamic Approach", pp. 63-66, Jan. 1994, IMAintellectual Property
Proceedings, vol. 1, Issue 1.
Sirbu, M., "Internet Billing Service Design and prototype Implementation", pp. 67-80, Jan. 1994, IMA Intellectual Property Project Proceedings, vol. 1, Issue 1.
Simmell, S. et a!., "Metering and Licensing of Resources: Kala's
General Purpose Approach", pp. 81-110, Jan. 1994, IMAintellectual
Property Project Proceedings, vol. 1, Issue 1.
Kalm, R., "Deposit, Registration and Recordation in an Electronic
Copyright Management System", pp. 111-120, Jan. 1994, IMAintellectual Property Project Proceedings, vol. 1, Issue 1.
Tygar, J. et a!., "Dyad: A System for Using Physically Secure
Coprocessors", pp. 121-152, Jan. 1994, IMA Intellectual Property
Project Proceedings, vol. 1, Issue 1.
Griswold, G., "A Method for Protecting Copyright on Networks", pp.
169-178, Jan. 1994, IMA Intellectual Property Project Proceedings,
vol. 1, Issue 1.
Nelson, T., "A Publishing and Royalty Model for Networked Documents", pp. 257-259, Jan. 1994, IMA Intellectual Property Project
Proceedings, vol. 1, Issue 1.
Robinson, E., "Redefining Mobile Computing", pp. 238-240, 247248 and 252, Jul. 1993, PC Computing.
Abadi, M. eta!., "Authentication and Delegation with Smart-cards",
pp. 1-24, 1990, Research Report DEC Systems Research Center.
Mark Stefik, "Letting Loose the Light: Igniting Commerce in Electronic Publication", pp. 219-253, 1996, Internet Dreams: Archetypes,
Myths, and Metaphors, IDSN 0-262-19373-6.
Mark Stefik, "Letting Loose the Light: Igniting Commerce in Electronic Publication", pp. 2-35, Feb. 8, 1995, Internet Dreams: Archetypes, Myths and Metaphors.
Henry H. Perritt, Jr., "Technological Strategies for Protecting Intellectual Property in the Networked Multimedia Enviromnent", Apr.
2-3, 1993, Knowbots, Permissions Headers & Contract Law.
Blaze et al, "Divertible Protocols and Atomic Proxy Cryptography"
1998 Advances in Cryptography-Euro Crypt International Conference on the Theory and Application ofCrypto Techniques, Springer
Verlag, DE.
Blaze eta!, "Atomic Proxy Cryptography" Draft (Online) (Nov. 2,
1997) XP002239619 Retrieved from the Internet.
No Author, "Capability- and Object-Based Systems Concepts,"
Capability-Based Computer Systems, pp. 1-19 (no. date).
Cox, "Superdistribution" Wired Magazine (Sep.
1994)
XP002233405
URL:http://www.wired.com/wired!archive/2.09/
superdis_pr.htrnl&gt.
Dunlop eta!, Telecommunications Engineering, pp. 346-352 (1984).
Elgamal, "A Public Key Cryptosystem and a Signature Scheme
Based on Discrete Logarithms," IEEE Transactions on Information
Theory IT-31(4):469-472 (Jul. 1985).
Gheorghiu eta!., "Authorization for Metacomputing Applications"
(no date).
Iannella, ed., Open Digital Rights Language (ODRL), pp. 1-31 (Nov.
21, 2000).
Kahle, wais.concepts.txt, Wide Area Information Server Concepts,
Thinking Machines Version 4, Draft, pp. 1-18 (Nov. 3, 1989).
Kalm, "Deposit, Registration and Recordation in an Electronic Copyright Management System," Technical Report, Corporation for
National Research Initiatives, Reston, Virginia (Aug. 1992)
URL:http://www.cni.org/docs/ima.ip-workshop/kahn.html.
Kalm et a!, "The Digital Library Project, vol. 1: The World of
Knowbots (DRAFT), An Open Architecture for a Digital Library
System and a Plan for its Development," Corporation for National
Research Initiatives, pp. 1-48 (Mar. 1988).
Kohl et al, Network Working Group Request for Comments: 1510,
pp. 1-112 (Sep. 1993).
Case 2:13-cv-01112 Document 1-5 Filed 12/18/13 Page 6 of 29 PageID #: 169
US 7,774,280 B2
Page 5
Lee eta!, CDMA Systems Engineering Handbook (1998) [excerpts
but not all pages numbered].
Mambo et a!, "Protection of Data and Delegated Keys in Digital
Distribution," Information Security and Privacy. Second Australian
Conference, ACISP '97 Proceedings, pp. 271-282 (Sydney, NSW,
Australia, Jul. 7-9, 1997, 1997 Berlin, Germany, Springer-Verlag,
Germany), XP008016393 ISBN: 3-540-63232-8.
Mambo et a!, "Proxy Cryptosystems: Delegation of the Power to
Decrypt Ciphertexts,", IEICE Trans. Fundamentals vol. E80-A, No.
1:54-63 (Jan. 1997)) XP00742245 ISSN: 0916-8508.
Microsoft Word, Users Guide, Version 6.0, pp. 487-489, 549-555,
560-564, 572-575, 599-613, 616-631 (1993).
Ojanperii and Prasad, eds., Wideband CDMA for Third Generation
Mobile Communications (1998) [excerpts but not all pages numbered].
Perritt, "Knowbots, Permissions Headers and Contract Law," Paper
for the Conference on Technological Strategies for Protecting Intellectual Property in the Networked Multimedia Environment, pp. 1-22
(Apr. 2-3, 1993 with revisions of Apr. 30, 1993).
Raggett, (Hewlett Packard), "HTML+(Hypertext markup language),"pp.1-31 (Jul.12, 1993)URL:http://citeseer.ist.psu.edu/correct/340709.
Samuelson eta!, "Intellectual Property Rights for Digital Library and
Hypertext Publishing Systems: An Analysis ofXanadu," Hypertext
'91 Proceedings, pp. 39-50 (Dec. 1991).
No Author, "Softlock Services Introduces . . Softlock Services"
Press Release (Jan. 28, 1994).
No Author, "Appendix III-Compatibility with HTML," No Title,
pp. 30-31 (no date).
No Editor, No Title, Dictionary pages, pp. 469-472, 593-594 (no
date).
Benoit, Digital Television MPEG-1, MPEG-2 and Principles of the
DVB System, pp. 75-80, 116-121 (no date).
Benoit, Digital Television MPEG-1, MPEG-2 and Principles of the
DVB System, 2"d edition, pp. 74-80 (no date).
AH Digital Audio and Video Series, "DTV Receivers and Measurements," Understanding Digital Terrestrial Broadcasting, pp. 159-164
(no date).
O'Driscoll, The Essential Guide to Digital Set-Top Boxes and Interactive TV, pp. 6-24 (no date).
Ius Mentis, "The EIGarnal Public Key System," pp. 1-2 (Oct. 1, 2005)
online
at
http://www.iusmentis.com/technology/encyrption/
elgamal.
Schneier, "Crypto Bibliography," Index of Crypto Papers Available
Online, pp. 1-2 (online) (no date).
No Author, No Title, pp. 344-355 (no date).
No Author, "Part Four Networks," No Title, pp. 639-714 (no date).
Microsoft Word User's Guide, pp. 773-774,315-316,487-489, 561564, 744, 624-633 (1993).
No Author, "What is the EIGamal Cryptosystem," p. 1 (Nov. 27,
2006) online at http://www.x5.net/faqs/crypto/q29.htrnl.
Johnson et al., "A Secure Distributed Capability Based System,"
ACM, pp. 392-402 (1985).
Wikipedia, "E1 Garnal Encyption," pp. 1-3 (last modified Nov. 2,
2006) online at http://en.wikipedia.org/wiki/E1Gamal_encryption.
Blaze, "Atomic Proxy Cryptography," p. 1 Abstract (Oct. 20, 1998).
Blaze, "Matt Blaze's Technical Papers," pp. 1-6 (last updated Aug. 6,
2006)].
Online Search Results for "inverted file", "inverted index" from
www.techweb.com,
www.cryer.co.uk,
computing-dictionary.
thefreedictionary.com, www.nist.gov, en.wikipedia.org, www.cni.
org, www.tiscali.co.uk (Jul. 15-16, 2006).
Corporation for National Research Initiatives, "Digital Object Architecture Project", http://www.nnri.reston.va.us/doa.htrnl (updated
Nov. 28, 2006).
Stefik, Summary and Analysis ofA13 (Kahn, Robert E and Vinton G
Cerf, "The Digital Library Project, vol. 1: The World of Knowbots
(DRAFT), An Open Architecture for a Digital Library System and a
Plan for its Development," Corporation for National Research Initiatives (Mar. 1988)), pp. 1-25 (May 30, 2007).
Bill Rosenblatt, et al., ContentGuard White Pages; "Integrating Content Management with Digital Rights Management-Imperatives
and Opportunities for Digital Content Lifecycles" GiantSteps Media
Technology Strategies; May 15, 2005; pp. 1-20; www.contentguard.
corn/whitepapers/CM-DRMwhitepaper.pdf.
M. Kamat; Texas A&M University; "Security Requirements for Digital Rights Management"; In The Proceedings ofiSECON 2002, v 19
(San Antonio): §353b. ISSN: 1542-7382; pp. 1-4; http://isedj.org/
isecon/2002/353b/ISECON.2002.kamat.ppt.
International Search Report; mailed Mar. 2, 2005 (International
Application No. PCT/US04/32588).
Johnson et al., "A Secure Distributed Capability Based System,"
Proceedings of the 1985 ACM Annual Conference on the Range of
Computing: Mid-80's Perspective: MID-80's Perspective Association for Computing Machinery pp. 392-402 (1985).
Delaigle, "Digital Watermarking," Spie Conference in Optical Security and Counterfeit Deterrence Techniques, San Jose, CA (Feb.
1996).
Perritt, "Technologies Strategies for Protecting Intellectual Property
in theNetworked Multimedia Environment," Knowbots, Permissions
Headers and Contract Law (Apr. 2-3, 1993).
* cited by examiner
Case 2:13-cv-01112 Document 1-5 Filed 12/18/13 Page 7 of 29 PageID #: 170
~
10
70
r---------------
:
~
I
40
: Rights Label
00
•
~
~
~
=
~
~
42
~
, ____ 1'::,?/??.J?:f" ___ _
....
"""4r:otecte'8~
1')'
'/J'A'#?.#
0
~0
80
.r"/#'//f~
Gontent"'·
N
0
....
Activation
0
52
rFJ
=....
.........
('D
('D
.....
1
Licen'se
:
0
z;">7J:"' ___ "' ... -~
~
""'1?r.otP
.:.t .# .<r"'~e~~~
d'.!l !\\1l'
[;£ <•
,i . :;y·.···~:•:··'··.vw·• l!ifl
IGont{'f/..;
· ··'\J
7
.j;o.
.1' f / f , /.... ~
72
Clearinghouse
90
60
d
rJl
-....l
~
-....l
~
'N
Fig. 1
00
=
=
N
Case 2:13-cv-01112 Document 1-5 Filed 12/18/13 Page 8 of 29 PageID #: 171
U.S. Patent
Aug. 10, 2010
Sheet 2 of 14
US 7, 77 4,280 B2
...
..!!!
ca
c
CDM
·-
O::N
.
0')
LL
...0
-
::::s
.c
...CD
.c
-~
:Co
::::s._
O..N
Case 2:13-cv-01112 Document 1-5 Filed 12/18/13 Page 9 of 29 PageID #: 172
U.S. Patent
Aug. 10, 2010
Sheet 3 of 14
US 7, 77 4,280 B2
Case 2:13-cv-01112 Document 1-5 Filed 12/18/13 Page 10 of 29 PageID #: 173
52
\
<license>
~
<grant>
<forAII varName="user''/>
<forAII varName="distributorConditionForPiay"/>
<principal id="distributor"/>
<issue/>
<grant>
<principal varRef=lluser"/>
<play/>
<digitaiResource licensePartld= book"/>
<aiiCond ition>
<region regionCode="US"/>
<condition varRef= distributorConditionForPiay"/>
</aiiCondition>
</grant>
<fee>
<flat currencyCode=nUSD">1 </flat>
<to licensePartld= provider"/>
</fee>
</grant>
<issuer id="providern/>
</license>
~
00
•
~
~
~
~
=
~
~
~
....
~0
N
0
....
0
11
11
rFJ
=-
('D
('D
.....
.j;o.
0
.........
.j;o.
11
d
rJl
-....l
~
-....l
~
'N
Fig. 4
00
=
=
N
Case 2:13-cv-01112 Document 1-5 Filed 12/18/13 Page 11 of 29 PageID #: 174
U.S. Patent
Aug. 10, 2010
Sheet 5 of 14
US 7, 77 4,280 B2
.
C)
LL
---
~---- ~---------------------
00
0
tr)
0
......
tr)
------------------------------------
Case 2:13-cv-01112 Document 1-5 Filed 12/18/13 Page 12 of 29 PageID #: 175
U.S. Patent
Aug. 10, 2010
Sheet 6 of 14
Label40
Offer44
Rights
44a
""""I
....
.
..........
""
Conditions
44b
Content
Specification
44c
......
Conditions
44b
Content
Specification
44c
Conditions
44b
Content
Specification
44c
Offer44
Rights
44a
Offer44
Rights
44a
.
......... ""
Fig. 6
US 7, 77 4,280 B2
Case 2:13-cv-01112 Document 1-5 Filed 12/18/13 Page 13 of 29 PageID #: 176
~
00
•
~
~
702
~
708
~
=
~
~
~
....
~0
704
Access
Denied
A
710
Access
Granted
Access
Denied
'\.
A
N
0
....
Access
Granted
712
0
rFJ
=-
If
('D
('D
.....
-....l
0
.........
.j;o.
No more
New Rights
714
~
..
';
If
More New
Rights
~
d
rJl
"'--...1
-.....1
-.....1
~
'N
00
Fig. 7
=
=
N
Case 2:13-cv-01112 Document 1-5 Filed 12/18/13 Page 14 of 29 PageID #: 177
U.S. Patent
US 7, 77 4,280 B2
Sheet 8 of 14
Aug. 10, 2010
800
812
803
808
Authorization
~-------------1~
804
Condition
Validator
License
Interpreter
806
802
816
~820
809
State-ofRights
Manager
801
814
Fig. 8
Case 2:13-cv-01112 Document 1-5 Filed 12/18/13 Page 15 of 29 PageID #: 178
~
I~ ~u1
Offer
Anyone
play
ebook
5 times
state variable id =
<unspecified>
/
II
_s-
Alice
play
I ebook
5 times
state variable id =
AlicePiayEbook
I
902
~
~
_s-
=
905
~
903
ebook
5 times
state variable id =
BobPiayEbook
~
~
~Bob
play
904
00
•
>
=
~
....
~0
_s-
N
0
....
906
Fig. 9
0
rFJ
=-
Offer
Alice's PDA
play
ebook
5 times
state variable id =
AlicePiayEbook
Alice's PC
play
ebook
5 times
state variable id =
AlicePiayEbook
('D
('D
_s- 1001
Alice's PDA
play
1006
ebook
5 times
state variable id =
AlicePiayEbook
_s-
_s- 1004
.....
\0
0
.........
1002
.j;o.
d
s
rJl
-....l
1003
~
-....l
_s- 1005
~
Fig. 10
'N
00
=
=
N
Case 2:13-cv-01112 Document 1-5 Filed 12/18/13 Page 16 of 29 PageID #: 179
~
Alice
play
ebook
track usage
state variable id
www.foou.edu
Offer
any FooU student
play
ebook
track usage
state variable id =
www.foou.edu
_:s;-
11 04
00
•
1102
~
~
~
~
=
=_:s;- 11 05
Bob
play
ebook
track usage
state variable id =
www.foou.edu
~
~
~
1103
....
~0
N
0
....
0
_:s;- 11 06
Fig. 11
rFJ
=....
('D
('D
.....
Alice
play
ebook
_:s;- 1303
track usage
state variable id = 40
Alice
print
ebook
_:s;- 1303
track usage
state variable id = 40
0
0
l>
1301
l>
1302
.........
.j;o.
d
rJl
-....l
~
-....l
~
'N
Fig. 13
00
=
=
N
Case 2:13-cv-01112 Document 1-5 Filed 12/18/13 Page 17 of 29 PageID #: 180
~
Offer
00
•
~1201
~
any affiliated club
issue
its club member
play
ebook
simultaneous use = 5
state variable id =
<unspecified>
~
~
~
=
~
_s- 1207
~
~
....
~0
~202~
~
Offer
=5
1208
rFJ
=........
.........
('D
('D
......
0
=
~~~
:s-
1203
any Foo club member
play
ebook
simultaneous use = 5
state variable id
~ 1209
um:foo:club
~
=_s-
Alice
play
ebook
simultaneous use
state variable id
um:acme:club
>
....
0
Offer
any Acme club member
play
ebook
simultaneous use = 5
state variable id
1208
um:acme:club
1204~
N
0
£20~
Bob
play
ebook
simultaneous use 5
state variable id ~ 1208
um:acme:club ~
=
=
1
.j;o.
51206
I
Cathy
play
ebook
simultaneous use
state variable id
um:foo:club
=5
= 1209
_s-
d
rJl
-....l
~
Fig. 12
-....l
~
'N
00
=
=
N
Case 2:13-cv-01112 Document 1-5 Filed 12/18/13 Page 18 of 29 PageID #: 181
U.S. Patent
Aug. 10, 2010
US 7,77 4,280 B2
Sheet 12 of 14
l_s- 1401
Offer
any affiliated club
issue
its club member
play
ebook
simultaneous use = 5
state variable id
1407
<unspecified>
state variable id = ~ 1408
<unspecified> ~
=__s:-
1402
----
\f\
Offer
any Acme club member
play
ebook
simultaneous use =5
state variable id
um:acme:club
1408
state variable id
<unspecified>
=
/
Offer
any Foo club member
play
ebook
simultaneous use =5
state variable id um:foo:club
state variable id
1408
<unspecified>
=
=__s:-
=__s:-
1404 \A
; : 1403
~
------
<; 1405
~----~==~~~----~
Alice
play
ebook
simultaneous use = 5
state variable id =
1409
um:acme:club
state variable id priority_2
__s:=
Fig. 14
Bob
play
ebook
simultaneous use 5
state variable id =
141 0
um:acme:club
state variable id = priority_1
=
__s:-
~ 1406
Cathy
play
ebook
simultaneous use = 5
state variable id =
1411
um:foo:club
state variable id priority_1
__s:=
Case 2:13-cv-01112 Document 1-5 Filed 12/18/13 Page 19 of 29 PageID #: 182
~
1501
00
•
Offer
~
1502
Alice's PDA
play
ebook
Alice's PDA
play
ebook
~
~
=
~
~
l> 1503
Alice's PC
play
ebook
~
~
....
~0
Fig. 15
N
0
....
0
1601
rFJ
=....
('D
('D
.....
Offer
Alice's PDA
play
ebook
5 times
state variable id
Alice's PC
play
ebook
5 times
state variable id
Alice's PDA
play
ebook
5 times
state variable id
_s- 1604
=0001
l5
_s-1604
=0001
(.H
1602
0
.........
.j;o.
_s;-1604
=0001
d
rJl
-....l
1603
~
Fig. 16
-....l
~
'N
00
=
=
N
Case 2:13-cv-01112 Document 1-5 Filed 12/18/13 Page 20 of 29 PageID #: 183
~
00
•
~
~
~
~
=
~
Offer
any FooU student can play
ebook as long as their uses
are tracked.
Alice
play
ebook
track usage
_s- 1704
state variable id = www.foou.edu
1702
~
~
....
~0
N
0
....
0
rFJ
Bob
play
ebook
track usage
state variable id
=....
('D
('D
.....
1703
5
1705
=www.foou.edu
,j;o,.
0
.........
,j;o,.
Fig. 17
d
rJl
-....l
~
-....l
~
'N
00
=
=
N
Case 2:13-cv-01112 Document 1-5 Filed 12/18/13 Page 21 of 29 PageID #: 184
US 7,774,280 B2
1
2
SYSTEM AND METHOD FOR MANAGING
TRANSFER OF RIGHTS USING SHARED
STATE VARIABLES
be the dominant systems used to access digital works. In this
sense, existing computing envirouments 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.
As an example, U.S. Pat. No. 5,634,012, the disclosure of
which is incorporated herein by reference, 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. Usage
rights define one or more manners of use of the associated
document content and 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. Further, a party
may grant usage rights to others that are a subset of usage
rights possessed by the party.
DRM systems have facilitated distribution of digital content by permitting the content owner to control use of the
content. However, known business models for creating, distributing, and using digital content and other items involve a
plurality of parties. For example, a content creator may sell
content to a publisher who then authorizes a distributor to
distribute content to an on-line storefront who then sells content to end-users. Further, the end users may desire to share or
further distribute the content. In such a business model, usage
rights can be given to each party in accordance with their role
in the distribution chain. However, the parties do not have
control over downstream parties unless they are privy to any
transaction with the downstream parties in some way. For
example, once the publisher noted above provides content to
the distributor, the publisher cannot readily control rights
granted to downstream parties, such as the first or subsequent
users unless the publisher remains a party to the downstream
transaction. This loss of control combined with the ever
increasing complexity of distribution chains results in a situation, which hinders the distribution of digital content and
other items. Further, the publisher may want to prohibit the
distributor and/or the storefront from viewing or printing
content while allowing an end user receiving a license from
the storefront to view and print. Accordingly, the concept of
simply granting rights to others that are a subset of possessed
rights is not adequate for multi-party, i.e. multi-tier, distribution models.
RELATED APPLICATION DATA
This application is a continuation-in-part application of
co-pending application Ser. No. 10/162,701 filed on Jun. 6,
2002, which claims benefit from U.S. provisional applications Ser. Nos. 60/331,624, 60/331,623, and 60/331,621 filed
on Nov. 20, 2001, and U.S. provisional applications Ser. Nos.
60/296,113, 60/296,117, and 60/296,118 filed on Jun. 7,
2001, the entire disclosures of all of which are hereby incorporated by reference herein.
10
15
FIELD OF THE INVENTION
The present invention generally relates to rights transfer
and more particularly to a method, system and device for
managing transfer of rights using shared state variables.
20
BACKGROUND OF THE INVENTION
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.
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.
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 rnn 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
25
30
35
40
45
50
55
60
65
SUMMARY OF THE INVENTION
The exemplary embodiments of the present invention are
directed to a method, system and device for transferring rights
adapted to be associated with items from a rights supplier to
a rights consumer, including obtaining a set of rights associated with an item, the set of rights including meta-rights
specifYing derivable rights that can be derived from the meta-;
determining whether the rights consumer is entitled to the
derivable rights specified by the meta-rights; and deriving at
least one right from the derivable rights, if the rights consumer is entitled to the derivable rights specified by the metarights, wherein the derived right includes at least one state
variable based on the set of rights and used for determining a
state of the derived right.
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
Case 2:13-cv-01112 Document 1-5 Filed 12/18/13 Page 22 of 29 PageID #: 185
US 7,774,280 B2
3
4
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.
server 20 as well as other components, such as any component
necessary for rendering content 42.
Rights label 40 is associated with content 42 and specifies
usage rights and possibly corresponding conditions that can
be selected by a content recipient. License Server 50 manages
the encryption keys and issues licenses for protected content.
These licenses embody the actual granting of usage rights to
an end user. For example, rights label 40 may include usage
rights permitting a recipient to view content for a fee of five
dollars and view and print content for a fee of ten dollars.
License 52 can be issued for the view right when the five
dollar fee has been paid, for example. Client component 60
interprets and enforces the rights that have been specified in
license 52.
FIG. 6 illustrates rights label 40 in accordance with the
preferred embodiment. Rights label 40 includes plural rights
offers 44 each including usage rights 44a, conditions 44b, and
content specification 44c. Content specification 44c can
include any mechanism for calling, referencing, locating,
linking or otherwise specifYing content 42 associated with
offer 44. 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 rights and conditions under
which content 42 can be used, associating rights label40 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 rights can be specified
in any marmer. Also, the rights can be in the form of a predefined 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 label40 associated with content 42 and the encryption
key used to encrypt the content can be transmitted to license
server 50. As discussed in detail below, rights 44a can include
usage rights, which specify a marmer of use, and meta-rights,
which permit other rights to be derived.
In some case, license 52 includes conditions that must be
satisfied in order to exercise 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.
Labels, offers, usage rights, and conditions can be stored
together with content 42 or otherwise associated with content
42 through content specification 44c or any other mechanism.
A rights language such as XrML can be used to specifY the
rights and conditions. However, the rights can be specified in
any manner. Also, the rights can be in the form of a predefined specification or template that is merely associated
with content 42.
A typical workflow for DRM system 10 is described below.
A recipient operating within client environment 30 is activated for receiving content 42 by activation server 20. This
results in a public-private key pair (and possibly some user/
machine specific information) being downloaded to client
environment 30 in the form of client software component 60
in a known marmer. This activation process can be accomplished at any time prior to the issuing of a license.
When a recipient wishes to obtain specific content 42, the
recipient makes a request for content 42. For example, a user,
BRIEF DESCRIPTION OF THE DRAWINGS
Exemplary embodiments of this invention will be
described in detail, with reference to the attached drawings in
which:
FIG. 1 is a schematic illustration of a rights management
system in accordance with the preferred embodiment;
FIG. 2 is a block diagram of an example distribution chain
showing the derivation of rights from meta-rights;
FIG. 3 is a schematic illustration of a license in accordance
with the preferred embodiment;
FIG. 4 is an example of a license expressed with an XML
based rights language in accordance with the preferred
embodiment;
FIG. 5 is a block diagram of the license serverofthe system
ofFIG. 1;
FIG. 6 is a block diagram of a rights label in accordance
with the preferred embodiment;
FIG. 7 is a flow chart of the procedure for transferring and
deriving rights in accordance with the preferred embodiment;
FIG. 8 illustrates an exemplary system including a stateof-rights server;
FIG. 9 illustrates employing of a state variable in deriving
exclusive usage rights;
FIG. 10 illustrates employing of a state variable in deriving
inherited usage rights;
FIG. 11 illustrates employing of a state variable in deriving
rights that are shared among a known set of rights recipients;
FIG. 12 illustrates employing of a state variable in deriving
rights that are shared among a dynamic set of rights recipients;
FIG. 13 illustrates employing of a state variable in maintaining a state shared by multiple rights;
FIG. 14 illustrates employing of multiple state variables to
represent one state of rights;
FIG. 15 illustrates a case where not all rights are associated
with states;
FIG. 16 illustrates a case where not all rights which are
associated with states are shared or inherited; and
FIG. 17 illustrates a case of rights sharing based on an offer
which does not explicitly include meta-rights.
10
15
20
25
30
35
40
45
50
DETAILED DESCRIPTION
AD RM system can be utilized to specifY and enforce usage
rights for specific content, services, or other items. FIG. 1
illustrates DRM System 10 that can be used in connection
with the preferred embodiment. DRM System 10 includes a
user activation component, in the form of activation server 20,
that issues public and private key pairs to content users in a
protected fashion, as is well known. During an activation
process, some information is exchanged between activation
server 20 and client environment 30, a computer or other
device associated with a content recipient, and client component 60 is downloaded and installed in client environment 30.
Client component 60 preferably is tamper resistant and contains the set of public and private keys issued by activation
55
60
65
Case 2:13-cv-01112 Document 1-5 Filed 12/18/13 Page 23 of 29 PageID #: 186
US 7,774,280 B2
5
6
as a recipient, might browse a Web site running on Web server
80, using a browser installed in client environment 30, and
request 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
content 42 and Web server 80 causes both the content and
license 52 to be downloaded. License 52 includes the appropriate rights, such as usage rights and/or meta-rights, and can
be downloaded from license server 50 or an associated
device. Content 42 can be downloaded from computer 70
associated with a vendor, distributor, or other party.
Client component 60 in client environment 30 will then
proceed to interpret license 52 and allow use of content 42
based on the usage rights and conditions specified in license
52. The interpretation and enforcement of usage rights are
well known generally and described in the patents referenced
above, for example. The steps described above may take place
sequentially or approximately simultaneously or in various
orders.
DRM system 10 addresses security aspects of 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
license 52 can be trusted. In other words, application 60 has
the capability to verifY and validate the cryptographic signature, or other identifYing characteristic of license 52. Of
course, the example above is merely one way to effect a DRM
system. For example, license 52 and content 42 can be distributed from different entities. Clearinghouse 90 can be used
to process payment transactions and verify payment prior to
issuing a license.
As noted above, typical business models for distributing
digital content include plural parties, such as owners, publishers, distributors, and users. Each of these parties can act as
a supplier granting rights to a consumer downstream in the
distribution channel. The preferred embodiment extends the
known concepts of usage rights, such as the usage rights and
related systems disclosed in U.S. Pat. Nos. 5,629,980, 5,634,
012, 5,638,443, 5,715,403 and 5,630,235, to incorporate the
concept of"meta-rights." Meta-rights are the rights that one
has to generate, manipulate, modifY, dispose of or otherwise
derive other rights. Meta-rights can be thought of as usage
rights to usage rights (or other meta-rights). This concept will
become clear based on the description below.
Meta-rights can include derivable rights to offer rights,
grant rights, negotiate rights, obtain rights, transfer rights,
delegate rights, expose rights, archive rights, compile rights,
track rights, surrender rights, exchange rights, and revoke
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. Metarights can be hierarchical and can be structured as objects
within objects. For example, a distributor may have a metaright permitting the distributor to grant a meta-right to a
retailer which permits the retailer to grant users rights to view
content. Just as rights can have conditions, meta-rights can
also have conditions. Meta-rights can also be associated with
other meta-rights.
The concept of meta-rights can be particularly useful
because distribution models may include entities that are not
creators or owners of digital content, but are in the business of
manipulating the rights associated with the content. For
example, as noted above, in a multi-tier content distribution
model, intermediate entities (e.g., distributors) typically will
not create or use the content but will be given the right to issue
rights for the content they distribute. In other words, the
distributor or reseller will need to obtain rights (meta-rights)
to issue rights. For the sake of clarity, the party granting usage
rights or meta-rights is referred to as "supplier" and the party
receiving and/or exercising such rights is referred to as "consumer" herein. It will become clear that any party can be a
supplier or a consumer depending on their relationship with
the adjacent party in the distribution chain. Note that a consumer "consumes", i.e. exercises, rights and does not necessarily consume, i.e. use, the associated content.
FIG. 2 schematically illustrates an example of a multi-tier
distribution model 200. Publisher 210 publishes content for
distribution, by distributor 220 for example. Distributor 220
distributes content to retailers, such as retailer 230 and retailer
230 sells content to users, such as user 240. In model 200,
publisher 210 could negotiate business relationships with
distributor 220 and distributor 220 could negotiate business
relationships with retailer 230. Also, retailer 230 may desire
usage rights that are beyond usage rights granted to distributor 220. However, keep in mind that, in a distribution chain
that utilizes a DRM system to control use and distribution of
content or other items, content can travel from publisher 210
to user 240 through any digital communication charmel, such
a network or transfer of physical media. When user 240
wishes to use content, a license is obtained, in the manner
described above for example. Accordingly, the negotiated
relationships can become difficult, if not impossible, to manage.
In model 200 of FIG. 2, retailer 230 will only grant rights
to user 240 that have been predetermined and authorized by
the distributor 220, publisher 210 and potentially other parties
upstream of the transaction, such as the content creator or
owner. The rights are predetermined through, and derived
from, meta-rights granted to retailer 230 by distributor 220.
Of course, there can be any number of parties in the distribution chain. For example, distributor 220 may sell directly to
the public in which case retailer 230 is not necessary. Also,
there may be additional parties. For example user 240 can
distribute to other users.
In model 200 publisher grants to distributor 220 usage
rights 212 permitting distribution of content, and meta-rights
214. Meta-rights 214 permit distributor 220 to grant to retailer
230 the usage right 214' (derived from meta-rights 214) to
distribute or possibly sell content and meta-rights 216 which
permit retailer 230 to grant user 240 the right to use content.
For example, publisher 210 may specify, through meta-rights
214, that meta-right 216 granted to retailer 230 permits
retailer 230 to grant only 500 licenses and usage rights 216'
that retailer 230 can grant to a user can only be "view" and
"print-once". In other words, distributor 220 has granted
meta-rights to retailer 230. Similarly, publisher 210 issues
meta-rights 214 to the distributor that will govern what type,
and how many, rights distributor 220 can grant to retailer 23 0.
Note that these entities could be divisions, units or persons
that are part of a larger enterprise, which also has other roles.
For example, an enterprise might create, distribute, and sell
content and carry out those activities using different personnel or different business units within the enterprise. The principles of meta-rights can be applied to an enterprise to determine content usage within that enterprise. Also, retailer 230
10
15
20
25
30
35
40
45
50
55
60
65
Case 2:13-cv-01112 Document 1-5 Filed 12/18/13 Page 24 of 29 PageID #: 187
US 7,774,280 B2
7
8
could grant meta-rights 218 to user 240 permitting user 240 to
share rights or grant usage rights to achieve a super-distribution model. It can be seen that meta-rights of a party are
derived from meta-rights granted by an upstream party in the
distribution chain.
For example, a person's medical records can be in digital
form managed by a first hospital as publisher 230. In this
scenario, the person, as supplier, grants usage rights to the
hospital, as consumer, to access and update the medical
records. Should that person require treatment at a second
hospital and desires to transfer their records to the second
hospital, the person can grant to the first hospital the right to
transfer the access rights to the new hospital through metarights. In other words, the person has specified meta-rights
and granted the meta-rights to the first hospital. The metarights permit the first hospital to grant rights, as a supplier, to
the second hospital, as a consumer. In another example, a
person's last will and testament can be in digital form and
managed by a law firm as publisher 210. If the person wishes
to allow a third party to review the will. The person can grant
meta-rights to the law firm permitting the law firm to grant
access rights to this third party.
At a high level the process of enforcing and exercising
meta-rights are the same as for usage rights. However, the
difference between usage rights and meta-rights are the result
from exercising the rights. When exercising usage rights,
actions to content result. For example usage rights can be for
viewing, printing, or copying digital content. When metarights are exercised, new rights are created from the metarights or existing rights are disposed as the result of exercising
the meta-rights. The recipient of the new rights may be the
same principal (same person, entity, or machine, etc), who
exercises the meta -rights. Alternatively, the recipient of metarights can be a new principal. The principals who receive the
derived rights may be authenticated and authorized before
receiving/storing the derived rights. Thus, the mechanism for
exercising and enforcing a meta-right can be the same as that
for a usage right. For example, the mechanism disclosed in
U.S. Pat. No. 5,634,012 can be used.
Meta-rights can be expressed by use of a grammar or rights
language including data structures, symbols, elements, or sets
of rules. For example, the XrML™ rights language can be
used. As illustrated in FIG. 3, the structure of license 52 can
consist of one or more grants 300 and one or more digital
signatures 310. Each grant 300 includes specific granted
meta-rights 302 such as rights to offer usage rights, grant
usage rights, obtain usage rights, transfer usage rights,
exchange usage rights, transport usage rights, surrender
usage rights, revoke usage rights, reuse usage rights, or management meta-rights such as the rights to backup rights,
restore rights, recover rights, reissue rights, or escrow the
rights for management of meta-rights and the like.
Grant 300 can also specifY one or more principals 304 to
whom the specified meta-rights are granted. Also grants 300
can include conditions 306 and state variables 308. Like
usage rights, access and exercise of the granted meta-rights
are controlled by any related conditions 306 and state variables 308. The integrity oflicense 52 is ensured by the use of
digital signature 310, or another identification mechanism.
Signature 310 can include a crypto-algorithm, a key, or
another mechanism for providing access to content 42 in a
known manner. The structure of digital signature 310
includes the signature itself, the method of how the code is
computed, the key information needed to verifY the code and
issuer identification.
State variables track potentially dynamic states conditions.
State variables are variables having values that represent sta-
tus of rights, or other dynamic conditions. State variables can
be tracked, by clearinghouse 90 or 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 for and a
condition can be that the usage right can be exercised three
times. Each time the usage right is exercised, the value of the
state variable is incremented. In this example, when the value
of the state variable is three, the condition is no 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.
FIG. 4 is an example of license 52 encoded in XrML™.
The provider grants the distributor a meta right to issue a
usage right (i.e., play) to the content (i.e., a book) to any end
user. With this meta right, the distributor may issue the right
to play the book within the U.S. region and subject to some
additional conditions that the distributor may impose upon
the user, as long as the distributor pays $1 to the provider each
time the distributor issues a license for an end user. The
XrML™ specification is published and thus well known.
FIG. 5 illustrates the primary modules oflicense server 50
in accordance with the preferred embodiment. License interpreter module 502 validates and interprets license 52 and also
provides the functions to query any or all fields in the license
such as meta-rights 302, conditions 306, state variables 308,
principle 304, and/or digital signature 310. License manager
module 503 manages all license repositories for storing
licenses 52, and also provides functions to create licenses 52
for derived rights, verifY licenses, store licenses, retrieve
licenses and transfer licenses. State of rights module 504
manages the state and history of rights and meta-rights. The
current value and history of the state variables together with
the conditions controls the permission to exercise given metarights for a given authenticated principal. Condition validator
506 verifies conditions associated with the meta-rights.
Together with the state variables, conditions associated with
meta-rights define variables whose values may change over
the lifetime of the meta-rights. Values of state variables used
in conditions can affect the meta-rights at the time and during
the time the rights are exercised.
Authorization module 508 authorizes the request to exercise meta-rights and to store the newly created rights or
derived rights as the result of exercising the meta-rights.
Authorization module 508 accesses both state of rights manager module 504 and condition validator module 506. Authorization module 508 interacts with license manager module
503 and the list of state variables and conditions and then
passes the state variables to state of rights manager module
504 and condition list to condition validator module 506 for
authorization.
A request for exercising a meta-right is passed to metarights manager module 510. Assuming that the requesting
device has been authenticated, meta-rights manager module
510 requests the license manager module 504 to verify the
license for exercising the requested meta-rights. License
manager module 504 verifies the digital signature of the
license and the key of the signer. If the key of the signer is
trusted and the digital signature is verified then license manager module 504 returns "verified" to the meta-rights manager module 510. Otherwise "not verified" is returned.
Authorization module 508 instructs license manager 503 to
fetch state variable 308 and conditions 306 of license 52.
10
15
20
25
30
35
40
45
50
55
60
65
Case 2:13-cv-01112 Document 1-5 Filed 12/18/13 Page 25 of 29 PageID #: 188
US 7,774,280 B2
9
10
Authorization manager 508 then determines which state variabies are required to enforce to enforce license 52. State of
rights manager 504 then supplies the current value of each
required state variable to authorization module 508. Authorization module 508 then passes conditions 306 and the
required state variables to condition validator 506. If all conditions 306 are satisfied, authorization module 508 returns
"authorized" to meta-rights manager module 510.
Meta-rights manager module 510 verifies license 52 and
meta-rights 302 therein, to authorize the request to exercise
meta-rights 302, to derive new rights from meta-rights 302,
and to update the state of rights and the current value of the
conditions. Rights manager module 512, on the other hand,
manages the new rights created or the derived rights as the
result of exercising the meta-rights. Rights manager module
512 uses authorization module 508 to verifY that recipient of
the newly created rights or derived rights is intended principal
304. If the recipient are authorized then the rights manager
module 512 directs license manager 504 to store the newly
created rights in a repository associated with the consumer.
This is discussed in greater detail below with reference to
FIG. 7.
The authorization process is not limited to the sequence or
steps described above. For example, a system could be programmed to allow authorization module 508 to request the
state conditions from license manager 504 prior to verification of the digital signature. In such a case it would be possible
to proceed subject to a verified license. Further, the various
modules need not reside in the license server or related
devices. The modules can be effected through hardware and/
or software in any part of the system and can be combined or
segregated in any manner.
Once a request to exercise a meta-rights has been authorized, the meta-right can be exercised. Meta-rights manager
module 510 informs state of rights module 504 that it has
started exercising the requested meta-rights. State of rights
module 504 then records the usage history and changes its
current value of the state variables. Meta-rights manager
module 510 exercises the requested meta-rights in a manner
similar to known procedures for usage rights. Ifnew rights are
derived, then meta-rights manager module 510 invokes
license manager module 504 to create new rights as the result
of exercising the target meta-rights. Each new right is then
sent to the corresponding rights manager module 512 of the
consumer and stored in a repository associated with the consumer. Rights manager module 512 of the consumer will
authenticate and authorize the consumer before receiving and
storing the newly created right. New rights can be derived
from meta-rights in accordance with a set of rules or other
logic. For example, one rule can dictate that a consumed right
to offer a license for use will result in the consumer having the
right to offer a usage right and grant a license to that usage
right to another consumer.
FIG. 7 illustrates the workflow for transferring meta-rights
and deriving new rights from the meta-rights in accordance
with the preferred embodiment. All steps on the left side of
FIG. 7 relate to the supplier of rights and all steps on the right
side of FIG. 7 relate to the consumer of rights. In step 702,
principal 304 oflicense 52 is authenticated in a known manner. In other words, it is determined if the party exercising
meta-right 302 has the appropriate license to do so. If the
principal is not authorized, the procedure terminates in step
704. If the principal is authorized, the procedures advances to
step 706 in which meta right 302 is exercised and transmitted
to the consumer in the form of license 52 having derived
rights in the manner set forth above. In step 708 the principal
of this new license is authenticated. In other words, it is
determined if the party exercising the derived rights has the
appropriate license to do so. If the principal is not authorized,
the procedure terminates in step 710. If the principal is authorized, the procedures advances to step 712 in which the
derived right is stored. The procedure then returns to step 708
for each additional right in the license and terminates in step
714 when all rights have been processed.
Thus, the exemplary embodiments include a method for
transferring rights adapted to be associated with items from a
rights supplier to a rights consumer, including obtaining a set
of rights associated with an item, the set of rights including
meta-rights specifYing derivable rights that can be derived
therefrom by the rights consumer, determining whether the
rights consumer is entitled to derive the derivable rights specified by the meta-rights, and at least one of deriving the derivable rights, and generating a license including the derived
rights with the rights consumer designated as a principal if the
rights consumer is entitled to derive the derivable rights specified by the meta-rights. The exemplary embodiments further
include a license associated with an item and adapted to be
used within a system for managing the transfer of rights to the
item from a rights supplier to a rights consumer. The license
includes a set of rights including meta-rights specifying
derivable rights that can be derived therefrom by the rights
consumer, a principal designating at least one rights consumer who is authorized to derive the derivable rights, and a
mechanism for providing access to the item in accordance
with the set of rights. The exemplary embodiments still further include a method for deriving rights adapted to be associated with items from meta-rights, including obtaining a set
of rights associated with an item, the set of rights including
meta-rights specifYing derivable rights that can be derived
therefrom by the rights consumer, and generating a license
associated with the item and including the derived rights.
FIG. 8 illustrates an exemplary system including a common state-of-rights server, according to the present invention.
In FIG. 8, the exemplary system can include a common stateof-rights server of the system 801, including a state-of-rights
manager 809, and one or more state-of-rights repositories
814, and one or more license servers 800, including a metarights manager 810, a usage rights manager 812, an authorization component 808, a condition validator 806, a state-ofrights manager 804, one or more state-of-rights repositories
816, a license manager 803, a license interpreter 802, and one
or more license repositories 818.
The common state-of-rights server 801 can be configured
as a remote server connected with one or more of the license
servers 800. The common state-of-rights server 801 provides
comparable services as the state-of-rights manager 804 in the
license servers 800 via the state-of-rights manager 809. The
services provided by the state-of-rights server 801 are accessible and states that the server 801 manages can be shared by
one or more rights suppliers and rights consumers (not
shown).
The state-of-rights server 801 can be configured as a
remote server connected with one or more of the license
servers 800 via one or more communication links 820, and the
like. The services provided by the state-of-rights server 801
also can be integrated within one or more of the license server
800 and such services can be accessible by other rights suppliers, rights consumers, and the like.
The license manager 803 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 803 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
10
15
20
25
30
35
40
45
50
55
60
65
Case 2:13-cv-01112 Document 1-5 Filed 12/18/13 Page 26 of 29 PageID #: 189
US 7,774,280 B2
11
12
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 803 can interact with the state-ofrights manager 804 to associate new state variables with
physical addresses in one or more of the state-of-rights
repositories 816. The state-of-rights manager 804 can access
the one or more state-of-rights repositories 816 and can interact with the state-of-rights server 801 to access shared state
variables from one or more of the state-of-rights repositories
814.
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.
There are multiple ways to specify the scope of state variabies, 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, unspecified 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.
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 810 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.
FIG. 9 is used to illustrate employing of a state variable in
deriving exclusive usage rights, according to the present
invention. In FIG. 9, rights 902 and 903 derived from an offer
901 are exclusive to each respective consumer. The offer 901
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 901 has an unspecified state variable 904. However, specific state variable 905 and 906, each with uniquely
assigned identifications (IDs) are included in the derived
rights 902 and 903. The derived state variables 905 and 906
are bound to their associated derived rights, e.g., "AlicePlayEbook" (i.e., Alice has the right to play Ebook) is bound
to derived right 902, and "BobP!ayEbook" (i.e., Bob has the
right to play Ebook) is bound to derived right 903 The "AliceP!ayEbook" variable can be updated when Alice exercises
her play right, whereas the "BobP!ayEbook" variable can be
updated when Bob exercises his play right.
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 801, the state of
right server 801 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.
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.
FIG.10 is used to illustrate employing of a state variable in
deriving inherited usage rights, according to the present
invention. In FIG. 10, 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 1003. A personal data assistant (PDA)
ofAlice also can obtain a right to play thee-book according to
offer 1001, if the PC and PDA share the same state variables
1004 and 1005, e.g., "AliceP!ayEbook." A derived right 1002
allows Alice also to play the e-bookonher PDA as long as the
PDA and the PC share a same count limit 1006 of 5 times.
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.
FIG. 11 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. 11, a site license
1101 is issued to FooU university. For example, via the site
license 1101, 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 1104, e.g., "www.foou.edu."
Accordingly, rights 1102 and 1103 derived from the site
license 1101 include state variables 1105 and 1106, "www.foou.edu," which can be updated when corresponding students, Alice and Bob, play thee-book.
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.
FIG. 12 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. 12, an
offer 1201 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 1207 associated with such a right
can be unspecified in the offer 1201. When corresponding
rights 1202 and 1203 are issued to affiliated clubs, the corresponding club identities are used to specifY state variables
1208 and 1209 in the issued rights. The offers 1202 and 1203
10
15
20
25
30
35
40
45
50
55
60
65
Case 2:13-cv-01112 Document 1-5 Filed 12/18/13 Page 27 of 29 PageID #: 190
US 7,774,280 B2
13
14
are meta-rights derived from the offer 1201, with offer being
assigned the distinct state variables 1208 and 1209. Further
rights 1204-1206 can be derived from the offers 1202 and
1203 to be shared among members of each respective club.
The licenses 1204 and 1205 are examples of rights derived
from the offer 1202, and which inherit the state variable 1208,
e.g., "um:acme:club," whereas the license 1206 inherits the
state variable 1209, e.g., "um:foo:club."
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. 13 is used to illustrate employing of a state variable for
maintaining a state shared by multiple rights, according to the
present invention. In FIG. 13, a same state variable 1303 is
associated to both a right to print 1302 and the right to play
1301, so that the total number of playing, printing, and the
like, can be tracked together.
The state of rights can depend on more than one state
variable. FIG. 14 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. 14 builds upon the example described with respect to
FIG. 12. In FIG. 14, a usage right can be tracked by employing
multiple state variables 1407 and 1408 in an offer 1401. The
state variable 1408, for example, representing a priority level,
can stay unspecified in the corresponding offers 1402 and
1403 (e.g., site licenses). The corresponding state variables
1409-1411, for example, used for setting a priority, can be
assigned to each member in the corresponding licenses 1404,
1405 and 1406. 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.
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.
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 801. 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 801.
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.
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.
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.
Not all rights need be associated with states. FIG.15 is used
to illustrate a case where not all rights are associated with
states, according to the present invention. In FIG. 15, an offer
1501 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 1502
also has an unlimited play right to the content, as well as the
right 1503 for her PC.
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. 16 is used to
illustrate a case where not all rights which are associated with
states are shared or inherited, according to the present invention. InFIG.16, even though a play right1603 of a user, Alice,
a play right 1602 of a PDA of Alice, and a play right 1603 of
a PC of Alice specifY a same state variable identification
1604, 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.
FIG.17 illustrates a form of an offer which does not explicitly include meta-rights. In FIG. 17, an offer 1701 is configured as a site license written in English. Licenses 1702 and
1703 are instances derived from the offer 1701. In an exemplary embodiment, variables 1704 and 1705 can be created
based on interpretation of the offer 1701, for example, by the
system of FIG. 8.
The preferred embodiments are not limited to situations
where resellers, distributors or other "middlemen" are used.
For example, the preferred embodiment can be applied within
enterprises or other organizations, which create and/or distribute digital content or other items to control use of the
content within the enterprise or other organization. Metarights can also be issued to end-users, when the grant of a right
relates to another right. For example, the right to buy or sell
securities as it is in the case of trading options and futures.
Meta-rights can be assigned or associated with goods services, resources, or other items.
The invention can be implemented through any type of
devices, such as computers and computer systems. The preferred embodiment is implemented in a client server environment. However, the invention can be implemented on a single
computer or other device. Over a network using dumb terminals, thin clients, or the like, or through any configuration of
devices. The various modules of the preferred embodiment
have been segregated and described by function for clarity.
However, the various functions can be accomplished in any
mauner through hardware and/or software. The various modules and components of the preferred embodiment have separate utility and can exist as distinct entities. Various communication channels can be used with the invention. For
example, the Internet or other network can be used. Also, data
can be transferred by moving media, such as a CD, DVD,
memory stick or the like, between devices. Devices can
include, personal computers, workstations, thin clients,
PDA's and the like.
10
15
20
25
30
35
40
45
50
55
60
65
Case 2:13-cv-01112 Document 1-5 Filed 12/18/13 Page 28 of 29 PageID #: 191
US 7,774,280 B2
15
16
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.
13. The system of claim 12, wherein the state variable
inherits a state thereof for content usage or rights transfer
from the set of rights.
14. The system of claim 12, wherein the state variable
shares a state thereof for content usage or rights transfer with
the set of rights.
15. The system of claim 12, wherein the state variable
inherits a remaining state for content usage or rights transfer
from the set of rights.
16. The system of claim 12, wherein the state variable is
updated upon exercise of a right associated with the state
variable.
17. The system of claim 12, wherein exercising the metaright results creates a plurality of rights, wherein the state
variable is shared by the created rights.
18. The system of claim 12, wherein the state variable
represents a collection of states.
19. The system of claim 12, including a plurality of state
variables that determine the state of the created right.
20. The system of claim 12, wherein the at least one state
variable is unspecified in the created right, is created during a
rights transfer, and is assigned to the created right.
21. The system of claim 12, wherein the state variable is
transferred from the right specified by the meta-right to the
created right.
22. The system of claim 12, further comprising means for
generating a license including the created right, if the rights
consumer is entitled to the right specified by the meta-right.
23. The system of claim 12, wherein the means for obtaining, the means for determining, and the means for exercising
comprise at least one of computer-executable instructions,
and devices of a computer system.
24. A device for transferring rights adapted to be associated
with items from a rights supplier to a rights consumer, the
device comprising:
means for obtaining a set of rights associated with an item,
the set of rights including a meta-right specifYing a right
that can be created when the meta-right is exercised,
wherein the meta-right is provided in digital form and is
enforceable by a repository;
means for determining whether the rights consumer is
entitled to the derivable right specified by the meta-right;
and
means for exercising the meta-right to create the right
specified by the meta-right if the rights consumer is
entitled to the right specified by the meta-right, wherein
the created right includes at least one state variable based
on the set of rights and used for determining a state of the
created right.
25. The device of claim 24, wherein the state variable
inherits a state thereof for content usage or rights transfer
from the set of rights.
26. The device of claim 24, wherein the state variable
shares a state thereof for content usage or rights transfer with
the set of rights.
27. The device of claim 24, wherein the state variable
inherits a remaining state for content usage or rights transfer
from the set of rights.
28. The device of claim 24, wherein the state variable is
updated upon exercise of a right associated with the state
variable.
29. The device of claim 24, wherein exercising the metaright results creates a plurality of rights, wherein the state
variable is shared by the created rights.
30. The device of claim 24, wherein the state variable
represents a collection of states.
What is claimed is:
1. A computer-implemented method for transferring rights
adapted to be associated with items from a rights supplier to
a rights consumer, the method comprising:
obtaining a set of rights associated with an item, the set of
rights including a meta-right specifying a right that can
be created when the meta-right is exercised, wherein the
meta-right is provided in digital form and is enforceable
by a repository;
determining, by a repository, whether the rights consumer
is entitled to the right specified by the meta-right; and
exercising the meta-right to create the right specified by the
meta-right if the rights consumer is entitled to the right
specified by the meta-right, wherein the created right
includes at least one state variable based on the set of
rights and used for determining a state of the created
right.
2. The method of claim 1, wherein the state variable inherits a state thereof for content usage or rights transfer from the
set of rights.
3. The method of claim 1, wherein the state variable shares
a state thereof for content usage or rights transfer with the set
of rights.
4. The method of claim 1, wherein the state variable inherits a remaining state for content usage or rights transfer from
the set of rights.
5. The method of claim 1, wherein the state variable is
updated upon exercise of a right associated with the state
variable.
6. The method of claim 1, wherein exercising the metaright creates a plurality of rights, wherein the state variable is
shared by the created rights.
7. The method of claim 1, wherein the state variable represents a collection of states.
8. The method of claim 1, further comprising a plurality of
state variables that determine the state of the created right.
9. The method of claim 1, wherein the at least one state
variable is unspecified in the created right, is created during a
rights transfer, and is assigned to the created right.
10. The method of claim 1, wherein the state variable is
transferred from the right specified by the meta-right to the
created right.
11. The method of claim 1, further comprising generating
a license including the created right, if the rights consumer is
entitled to the right specified by the meta-right.
12. A system for transferring rights adapted to be associated with items from a rights supplier to a rights consumer, the
system comprising:
means for obtaining a set of rights associated with an item,
the set of rights including a meta-right specifying a right
that can be created when the meta-right is exercised,
wherein the meta-right is provided in digital form and is
enforceable by a repository;
means for determining whether the rights consumer is
entitled to the right specified by the meta-right; and
means for exercising the meta-right to create the right
specified by the meta-right if the rights consumer is
entitled to the right specified by the meta-right, wherein
the created right includes at least one state variable based
on the set of rights and used for determining a state of the
created right.
10
15
20
25
30
35
40
45
50
55
60
65
Case 2:13-cv-01112 Document 1-5 Filed 12/18/13 Page 29 of 29 PageID #: 192
US 7,774,280 B2
17
18
31. The device of claim 24, including a plurality of state
35. The device of claim 24, wherein the means for obtain-
variables that determine the state of the created right.
32. The device of claim 24, wherein the at least one state
variable is unspecified in the created right, is created during a
rights transfer, and is assigned to the created right.
33. The device of claim 24, wherein the state variable is
transferred from the right specified by the meta-right to the
created right.
34. The device of claim 24, further comprising means for
generating a license including the created right, if the rights
consumer is entitled to the right specified by the meta-right.
ing, the means for determining, and the means for exercising
comprise at least one of computer-executable instructions,
and devices of a computer system.
36. The device of claim 24, wherein one or more of the
means for obtaining, the means for determining, and the
means for exercising are specified in a license.
10
* * * * *
Case 2:13-cv-01112 Document 1-6 Filed 12/18/13 Page 1 of 35 PageID #: 193
Exhibit F
Case 2:13-cv-01112 Document 1-6 Filed 12/18/13 Page 2 of 35 PageID #: 194
111111
1111111111111111111111111111111111111111111111111111111111111
US00800 1053B2
c12)
United States Patent
(10)
Nguyen et al.
(45)
(54)
SYSTEM AND METHOD FOR RIGHTS
OFFERING AND GRANTING USING SHARED
STATE VARIABLES
(58)
(75)
Inventors: Mai Nguyen, Buena Park, CA (US); Xin
Wang, Torrance, CA (US); Eddie J.
Chen, Rancho Palos Verdes, CA (US);
Bijan Tadayon, Germantown, MD (US)
(56)
Patent No.:
Date of Patent:
US 8,001,053 B2
*Aug. 16, 2011
Field of Classification Search ................ 705/1, 54,
705/57
See application file for complete search history.
References Cited
U.S. PATENT DOCUMENTS
3,263,158 A
7/1966 Janis
(Continued)
(73)
Assignee: ContentGuard Holdings, Inc.,
Wilmington, DE (US)
FOREIGN PATENT DOCUMENTS
BR
( *)
Notice:
Subject to any disclaimer, the term of this
patent is extended or adjusted under 35
U.S.C. 154(b) by 278 days.
This patent is subject to a terminal disclaimer.
(21)
Appl. No.: 10/956,070
(22)
Filed:
9810967 A
10/2001
(Continued)
OTHER PUBLICATIONS
Delaigle, "Digital Watermarking," Spie Conference in Optical Security and Counterfeit Deterrence Techniques, San Jose, CA (Feb.
1996).
(Continued)
Oct. 4, 2004
(65)
Prior Publication Data
US 2005/0137984 Al
Jun.23,2005
Related U.S. Application Data
(63)
Continuation-in-part of application No. 10/162,212,
filed on Jun. 5, 2002, which is a continuation-in-part of
application No. 09/867,745, filed on May 31, 2001,
now Pat. No. 6,754,642.
(60)
Provisional application No. 60/296,113, filed on Jun.
7, 2001, provisional application No. 60/331,625, filed
on Nov. 20, 2001, provisional application No.
60/331,624, filed on Nov. 20, 2001.
(51)
Int. Cl.
H04L 9100
(2006.01)
U.S. Cl. ................. 705/57; 705/51; 705/53; 705/59
(52)
Primary Examiner- Evens J Augustin
(74) Attorney, Agent, or Firm- Reed Smith LLP; Marc S.
Kaufman; Stephen M. Hertzler
(57)
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 mauner 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.
35 Claims, 17 Drawing Sheets
400
402
416
!
Consumer Component
38
40
36
Case 2:13-cv-01112 Document 1-6 Filed 12/18/13 Page 3 of 35 PageID #: 195
US 8,001,053 B2
Page 2
U.S. PATENT DOCUMENTS
3,609,697
3,790,700
3,798,605
4,159,468
4,200,700
4,220,991
4,278,837
4,323,921
4,361,851
4,423,287
4,429,385
4,442,486
4,529,870
4,558,176
4,593,376
4,614,861
4,621,321
4,644,493
4,658,093
4,713,753
4,736,422
4,740,890
4,796,220
4,816,655
4,817,140
4,827,508
4,868,376
4,888,638
4,891,838
4,924,378
4,932,054
4,937,863
4,949,187
4,953,209
4,961,142
4,975,647
4,977,594
4,999,806
5,010,571
5,014,234
5,023,907
5,047,928
5,050,213
5,052,040
5,058,164
5,103,476
5,113,519
5,129,083
5,136,643
5,138,712
5,146,499
5,148,481
5,159,182
5,174,641
5,183,404
5,191,193
5,204,897
5,222,134
5,235,642
5,247,575
5,255,106
5,260,999
5,263,157
5,263,158
5,276,444
5,276,735
5,287,408
5,291,596
5,293,422
5,301,231
5,311,591
5,319,705
5,335,275
5,337,357
5,339,091
5,341,429
5,347,579
5,381,526
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
9/1971
2/1974
3/1974
6/1979
4/1980
9/1980
7/1981
4/1982
1111982
12/1983
111984
4/1984
7/1985
12/1985
6/1986
9/1986
1111986
2/1987
4/1987
12/1987
4/1988
4/1988
111989
3/1989
3/1989
5/1989
9/1989
12/1989
111990
5/1990
6/1990
6/1990
8/1990
8/1990
10/1990
12/1990
12/1990
3/1991
4/1991
5/1991
6/1991
9/1991
9/1991
9/1991
10/1991
4/1992
5/1992
7/1992
8/1992
8/1992
9/1992
9/1992
10/1992
12/1992
2/1993
3/1993
4/1993
6/1993
8/1993
9/1993
10/1993
1111993
1111993
1111993
111994
111994
2/1994
3/1994
3/1994
4/1994
5/1994
6/1994
8/1994
8/1994
8/1994
8/1994
9/1994
111995
Blevins et al.
Callais eta!.
Feistel
Barnes eta!.
Mader
Hamano et a!.
Best
Guillou
Asip et al.
Zeidler
Cichelli eta!.
Mayer
Chaum
Arnold eta!.
Yolk
Pavlov eta!.
Boebert et a!.
Chandra et a!.
Hellman
Boebert et a!.
Mason
William
Wolfe
Musycket a!.
Chandra et a!.
Shear
Lessin et al.
Bohn
Faber
Hershey et a!.
Chou eta!.
Robert eta!.
Cohen
Ryder eta!.
Elliott et a!.
Downer eta!.
Shear
Chernow et a!.
Katznelson
Edwards
Johnson et a!.
Wiedemer
Shear
Preston et al.
Elmer eta!.
Waite et al.
Johnson et a!.
Cutler eta!.
Fischer
Corbin
Geffrotin
Abraham et al.
Eisele
Lim
Aldous eta!.
LeRoux
Wyman
Waite et al.
Wobber eta!.
Sprague et a!.
Castro
Wyman
Janis
Janis
McNair
Boebert et a!.
Samson
Mita
Loiacono
Abraham et al.
Fischer
Halter eta!.
Millar eta!.
Chou eta!.
Yarnazaki et a!.
Stringer et a!.
Blandford
Elison
5,386,369
5,390,297
5,394,469
5,410,598
5,412,717
5,414,852
5,428,606
5,432,849
5,438,508
5,444,779
5,453,601
5,455,953
5,457,746
5,473,687
5,473,692
5,485,577
5,499,298
5,502,766
5,504,814
5,504,816
5,504,818
5,504,837
5,509,070
5,530,235
5,532,920
5,534,975
5,535,276
5,539,735
5,553,143
5,557,678
5,563,946
5,564,038
5,568,552
5,619,570
5,621,797
5,625,690
5,629,980
5,633,932
5,634,012
5,636,346
5,638,443
5,638,513
5,649,013
5,655,077
5,671,412
5,708,709
5,708,717
5,715,403
5,734,823
5,734,891
5,737,413
5,737,416
5,745,569
5,745,879
5,748,783
5,757,907
5,758,069
5,761,686
5,764,807
5,765,152
5,768,426
5,787,172
5,790,664
5,790,677
5,794,207
5,812,664
5,825,876
5,825,879
5,825,892
5,838,792
5,848,154
5,848,378
5,850,443
5,892,900
5,910,987
5,915,019
5,917,912
5,920,861
5,925,127
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
*
111995
2/1995
2/1995
4/1995
5/1995
5/1995
6/1995
7/1995
8/1995
8/1995
9/1995
10/1995
10/1995
12/1995
12/1995
111996
3/1996
3/1996
4/1996
4/1996
4/1996
4/1996
4/1996
6/1996
7/1996
7/1996
7/1996
7/1996
9/1996
9/1996
10/1996
10/1996
10/1996
4/1997
4/1997
4/1997
5/1997
5/1997
5/1997
6/1997
6/1997
6/1997
7/1997
8/1997
9/1997
111998
111998
2/1998
3/1998
3/1998
4/1998
4/1998
4/1998
4/1998
5/1998
5/1998
5/1998
6/1998
6/1998
6/1998
6/1998
7/1998
8/1998
8/1998
8/1998
9/1998
10/1998
10/1998
10/1998
1111998
12/1998
12/1998
12/1998
4/1999
6/1999
6/1999
6/1999
7/1999
7/1999
Christiano
Barber eta!.
Nagel eta!.
Shear
Fischer
Kramer et a!.
Moskowitz
Johnson et al.
Wyman
Daniele
Rosen
Russell
Dolphin
Lipscomb et al.
Davis
Eyer eta!.
Narasirnhalu et al.
Boebert et a!.
Miyahara
Hamilton et a!.
Okano
Griffeth et a!.
Schull
Stefik eta!.
Hartrick et a!.
Stefik eta!.
Ganesan
Moskowitz
Ross eta!.
Ganesan
Cooper et al.
Grantz eta!.
Davis
Tsutsui
Rosen
Michel eta!.
Stefik eta!. ..................... 705/54
Davis et al.
Stefik eta!.
Saxe
Stefik eta!.
Ananda
Stuckey et a!.
Jones eta!.
Christiano
Rose
Alasia
Stefik
Saigh eta!.
Saigh
Akiyama et al.
Cooper et al.
Moskowitz et a!.
Wyman
Rhoads
Cooper et al.
Olsen
Bloomberg
Pearlman et a!.
Erickson
Rhoads
Arnold
Coley et al.
Fox eta!.
Walker eta!.
Bernobich et a!.
Peterson
Davis
Braudaway et a!.
Ganesan
Nishio eta!.
Shelton et a!.
Van Oorschot et al.
Ginter et al.
Ginter et al.
Ginter et al.
Ginter et al.
Hallet a!.
Ahmad
Case 2:13-cv-01112 Document 1-6 Filed 12/18/13 Page 4 of 35 PageID #: 196
US 8,001,053 B2
Page 3
5,933,498
5,940,504
5,943,422
5,949,876
5,982,891
5,987,134
5,991,306
5,999,624
5,999,949
6,006,332
6,009,401
6,020,882
6,047,067
6,056,786
6,073,234
6,091,777
6,112,181
6,112,239
6,115,471
6,135,646
6,138,119
6,141,754
6,157,719
6,157,721
6,169,976
6,185,683
6,189,037
6,189,146
6,209,092
6,216,112
6,219,652
6,226,618
6,233,684
6,236,971
6,237,786
6,240,185
6,253,193
6,292,569
6,301,660
6,307,939
6,327,652
6,330,670
6,345,256
6,353,888
6,363,488
6,389,402
6,397,333
6,401,211
6,405,369
6,424,717
6,424,947
6,442,517
6,487,659
6,516,052
6,516,413
6,523,745
6,636,966
6,697,944
6,772,340
6,775,655
6,796,555
6,816,596
6,829,708
6,850,252
6,885,748
6,947,571
6,947,910
6,973,444
6,985,588
6,993,131
7,010,808
7,024,393
7,039,615
7,051,005
7,065,507
7,068,787
7,103,574
7,120,254
7,134,144
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
B1
B1
B1
B1
B1
B1
B1
B1 *
B1 *
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1 *
B1
B2
B1
B1
B1 *
B1 *
B1 *
B1 *
B1
B1 *
B1 *
B1 *
B1 *
B1 *
B2 *
B1 *
B1 *
B1 *
B1 *
B1 *
B1 *
B1 *
B2 *
B1 *
B1 *
B2 *
B2 *
8/1999
8/1999
8/1999
9/1999
1111999
1111999
1111999
12/1999
12/1999
12/1999
12/1999
212000
4/2000
5/2000
6/2000
7/2000
8/2000
8/2000
9/2000
10/2000
10/2000
10/2000
12/2000
12/2000
112001
2/2001
2/2001
2/2001
3/2001
4/2001
4/2001
5/2001
5/2001
5/2001
5/2001
5/2001
6/2001
9/2001
10/2001
10/2001
12/2001
12/2001
212002
3/2002
3/2002
5/2002
5/2002
6/2002
6/2002
7/2002
7/2002
8/2002
1112002
2/2003
2/2003
2/2003
10/2003
2/2004
8/2004
8/2004
9/2004
1112004
12/2004
2/2005
4/2005
9/2005
9/2005
12/2005
112006
112006
3/2006
4/2006
5/2006
5/2006
6/2006
6/2006
9/2006
10/2006
1112006
Schneck et a!.
Griswold
VanWie eta!.
Ginter et al.
Ginter et al.
Shin eta!.
Burns eta!.
Hopkins
Crandall
Rabne et al.
Horstmann
Kinghorn et a!.
Rosen
Rivera eta!.
Kigo eta!.
Guetz eta!.
Shear eta!.
Kenner eta!.
Oki et al.
Kahnet a!.
Hallet a!.
Choy
Wasilewski eta!.
Shear eta!.
Colosso
Ginter et al.
Adams eta!.
Misra eta!.
Linnartz
Fuller eta!.
Carteret a!.
Downs eta!. ................... 705/51
Stefik eta!. ................... 713/176
Stefik eta!.
Ginter et al.
VanWie eta!.
Ginter et al.
Shear eta!.
Benson
Vigarie
England et al.
England et al.
Milsted eta!.
Kakehi eta!.
Ginter et al.
Ginter et al.
Sohne eta!.
Brezak, Jr. eta!.
Tsuria
Pinder et al.
T suria et al.
Miller eta!. .................. 704/201
Kigo eta!.
Voudouris
Aratani et a!.
Tarnori
Lee et al . ...................... 713/165
Jones et al. ................... 713/168
Peinado et a!. ............... 713/168
Peinado et a!. ................. 705/59
Blahut
Peinado et a!. ............... 380/277
Peinado et a!. ............... 713/156
Hofiberg ...................... 7151716
Wang ............................ 380/201
Rhoads et al. ................ 382/100
Hsu eta!. ........................ 705/57
Blinn et al. ..................... 705/51
Glick et al. ................... 380/258
Meyers ......................... 380/201
Leung et al. .................... 726/26
Peinado et a!. ................. 705/59
Gajjala et a!. ................... 705/59
Peinado et a!. ................. 705/57
Mohannned et a!. ........... 705/59
Ta eta!. ........................ 380/240
Peinado et a!. ................. 705/51
Glick et al. ................... 380/258
McKune ......................... 726/26
7,136,838
7,149,722
7,181,438
7,233,948
7,319,759
200110009026
200110011276
200110014206
200110032312
200110037467
200110039659
200110051996
2002/0001387
2002/0019814
2002/0035618
2002/0044658
2002/0051540
2002/0056118
2002/0069282
2002/0099948
2002/0127423
2002/0141584
2002/0169974
2003/0028488
2003/0066884
2003/0097 567
2004/0052370
2004/0172552
B1
B1
B1
B1
B1
A1
A1
A1
A1
A1
A1
A1
A1
A1
A1
A1
A1
A1
A1
A1
A1
A1
A1
A1
A1
A1
A1
A1
*
*
*
*
*
*
*
*
*
*
*
*
*
1112006
12/2006
2/2007
6/2007
1/2008
7/2001
8/2001
8/2001
10/2001
1112001
1112001
12/2001
1/2002
212002
3/2002
4/2002
5/2002
5/2002
6/2002
7/2002
9/2002
10/2002
1112002
2/2003
4/2003
5/2003
3/2004
9/2004
Peinado et a!. ................. 705/59
Abburi ............................ 705/59
Szabo
111
Sharnoon et a!.
111
Peinado et a!. ............... 380/277
Terao eta!.
Durst, Jr. et al.
Arti galas et a!.
Runje eta!. ................... 713/172
O'Toole, Jr. eta!.
Simmons et a!.
Cooper et al . ................ 709/217
Dillon
Ganesan ......................... 705/59
Mendez et al.
Wasilewski eta!.
Glick eta!. ................... 380/258
Hunter eta!.
Reisman
Kocher eta!.
Kayanakis
Razdan eta!. ................ 380/203
McKune ....................... 713/200
Mohannned et a!. ........... 705/59
Reddy eta!. ............... 235/382.5
Terao eta!.
Katznelson
Boyles et al.
FOREIGN PATENT DOCUMENTS
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
EP
GB
GB
GB
GB
GB
GB
GB
GB
JP
JP
JP
JP
JP
JP
JP
JP
0 067 556
0084441
0 180 460
0 257 585
0 262 025
0 332 304
0 332 304
0 332 707
0 393 806
0 450 841
0 529 261
0 613 073
0 651 554
0 668 695
0 678 836
0 679 977
0 715 243
0 715 243
0 715 244
0 715 244
0 715 245
0 715 246
0 725 376
0731404
0 763 936
0 818 748
0 840 194
0 892 521
0 934 765
0 946 022
0 964 572
1 041 823
1 103 922
1483282
2022969
2 136 175
2 236 604
2236604
2309364
2316503
2354102
62-241061
64-068835
3-063717
04-369068
5-100939
5168039
05-268415
6-131371
B1
A2
A2
A2
A3
A2
A2
A2
A1
A1
A1
A
A1
A
A1
A1
A
A1
A2
A2
A2
A2
A1
A2
A1
A2
A2
A
A
A
A
A
A
A2
A
12/1982
7/1983
5/1986
3/1988
3/1988
9/1989
9/1989
9/1989
10/1990
10/1991
3/1993
8/1994
5/1995
8/1995
10/1995
1111995
6/1996
6/1996
6/1996
6/1996
6/1996
6/1996
8/1996
9/1996
3/1997
111998
5/1998
111999
8/1999
9/1999
12/1999
10/2000
5/2001
8/1977
12/1979
9/1984
4/1991
4/1991
7/1997
2/1998
3/2001
10/1987
3/1989
3/1991
12/1992
4/1993
7/1993
10/1993
5/1994
Case 2:13-cv-01112 Document 1-6 Filed 12/18/13 Page 5 of 35 PageID #: 197
US 8,001,053 B2
Page 4
JP
JP
JP
JP
JP
JP
JP
JP
JP
JP
JP
JP
JP
JP
JP
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
wo
06-175794
06-215010
7-36768
07-084852
07-200317
07-244639
0 715 241
11031130
11032037
11205306
11215121
2000215165
2005218143
2005253109
2006180562
WO 83/04461
wo 92/20022
WO 92/20022
wo 93/01550
WO 93/01550
WO 93/11480
wo 94/01821
WO 94/03003
WO 96/13814
wo 96/24092
WO 96/24092
WO 96/27155
WO 97/25800
WO 97/37492
WO 97/41661
WO 97/43761
wo 97/48203
WO 98/09209
WO 98/10561
wo 98/11690
WO 98/11690
WO 98/19431
wo 98/42098
WO 98/43426
WO 98/45768
WO 99/24928
WO 99/34553
WO 99/35782
WO 99/48296
wo 99/49615
WO 99/60461
WO 99/60750
WO 00/04727
WO 00/05898
WO 00/08909
WO 00/46994
wo 00/59152
WO 00/59152
WO 00/62260
W000/72118
WO 00/73922
WO 01103044
WO 01 13198
WO 01124530
WO 01137209
wo 01163528
WO 2004/034223
wo 2004/103843
A2
A2
A2
A2
A2
A2
A2
A2
A1
A1
A1
A1
A1
A1
A2
A2
A1
A1
A2
A2
A1
A1
A1
A1
A1
A1
A2
A1
A1
A1
A1
A2
A2
A2
A
A1
A2
A1
A1
A2
A1
A
A2
A1
A2
6/1994
8/1994
2/1995
3/1995
8/1995
9/1995
6/1996
2/1999
2/1999
7/1999
8/1999
8/2000
8/2005
9/2005
7/2006
12/1983
1111992
1111992
111993
111993
6/1993
111994
2/1994
5/1996
8/1996
8/1996
9/1996
7/1997
10/1997
1111997
1111997
12/1997
3/1998
3/1998
3/1998
3/1998
5/1998
9/1998
10/1998
10/1998
5/1999
7/1999
7/1999
9/1999
9/1999
1111999
1111999
1/2000
212000
212000
8/2000
10/2000
10/2000
10/2000
1112000
12/2000
1/2001
1/2001
4/2001
5/2001
8/2001
4/2004
12/2004
OTHER PUBLICATIONS
Perritt, "Technologies Strategies for Protecting Intellectual Property
in theNetworked Multimedia Environment," Knowbots, Permissions
Headers and Contract Law (Apr. 2-3, 1993).
Blaze et al, "Divertible Protocols and Atomic Proxy Cryptography"
1998 Advances in Cryptography-Euro Crypt International Conference on the Theory and Application ofCrypto Techniques, Springer
Verlag, DE.
Blaze eta!, "Atomic Proxy Cryptography" DRAFT (Online) (Nov. 2,
1997) XP002239619 Retrieved from the Internet.
No Author, "Capability- and Object-Based Systems Concepts,"
Capability-Based Computer Systems, pp. 1-19 (no date).
1994)
Cox, "Superdistribution" Wired Magazine (Sep.
XP002233405
URL:http://www.wired.com/wired!archive/2.09/
superdis_pr.htrnl&gt.
Dunlop eta!, Telecommunications Engineering, pp. 346-352 (1984).
Elgamal, "A Public Key Cryptosystem and a Signature Scheme
Based on Discrete Logarithms," IEEE Transactions on Information
Theory IT-31(4):469-472 (Jul. 1985).
Gheorghiu eta!., "Authorization for Metacomputing Applications"
(no date).
Iannella, ed., Open Digital Rights Language (ODRL), pp. 1-31 (Nov.
21, 2000).
Kahle, wais.concepts.txt, Wide Area Information Server Concepts,
Thinking Machines Version 4, Draft, pp. 1-18 (Nov. 3, 1989).
Kahn, "Deposit, Registration and Recordation in an Electronic Copyright Management System," Technical Report, Corporation for
National Research Initiatives, Reston, Virginia (Aug. 1992)
URL:http://www.cni.org/docs/ima.ip-workshop/kahn.html.
Kahn et a!, "The Digital Library Project, vol. 1: The World of
Knowbots (DRAFT), An Open Architecture for a Digital Library
System and a Plan for its Development," Corporation for National
Research Initiatives, pp. 1-48 (Mar. 1988).
Kohl et al, Network Working Group Request for Comments: 1510,
pp. 1-112 (Sep. 1993).
Lee eta!, CDMA Systems Engineering Handbook (1998) [excerpts
but not all pages numbered].
Mambo et a!, "Protection of Data and Delegated Keys in Digital
Distribution," Information Security and Privacy. Second Australian
Conference, ACISP '97 Proceedings, pp. 271-282 (Sydney, NSW,
Australia, Jul. 7-9, 1997, 1997 Berlin, Germany, Springer-Verlag,
Germany), XP008016393 ISBN: 3-540-63232-8.
Mambo et al, "Proxy Cryptosystems: Delegation of the Power to
Decrypt Ciphertexts,", IEICE Trans. Fundamentals vol. E80-A, No.
1:54-63 (Jan. 1997) XP00742245 ISSN: 0916-8508.
Microsoft Word, Users Guide, Version 6.0, pp. 487-489, 549-555,
560-564, 572-575, 599-613,616-631 (1993).
Ojanperii and Prasad, eds., Wideband CDMA for Third Generation
Mobile Communications (1998) [excerpts but not all pages numbered].
Perritt, "Knowbots, Permissions Headers and Contract Law," Paper
for the Conference on Technological Strategies for Protecting Intellectual Property in theNetworked Multimedia Environment, pp. 1-22
(Apr. 2-3, 1993 with revisions of Apr. 30, 1993).
Raggett, (Hewlett Packard), "HTML+(Hypertext markup language)," pp. 1-31 (Jul. 12, 1993) URL:hrtp://citeseer.ist.psu.edu/correct/340709.
Samuelson eta!, "Intellectual Property Rights for Digital Library and
Hypertext Publishing Systems: An Analysis ofXanadu," Hypertext
'91 Proceedings, pp. 39-50 (Dec. 1991).
No Author, "Softlock Services Introduces ... Softlock Services"
Press Release (Jan. 28, 1994).
No Author, "Appendix III-Compatibility with HTML," No Title,
pp. 30-31 (no date).
No Editor, No Title, Dictionary pages, pp. 469-472, 593-594 (no
date).
Benoit, Digital Television MPEG-1, MPEG-2 and Principles of the
DVB System, pp. 75-80, 116-121 (no date).
Benoit, Digital Television MPEG-1, MPEG-2 and Principles of the
DVB System, 2"d edition, pp. 74-80 (no date).
AH Digital Audio and Video Series, "DTV Receivers and Measurements," Understanding Digital Terrestrial Broadcasting, pp. 159-164
(no date).
O'Driscoll, The Essential Guide to Digital Set-Top Boxes and
Interactive TV, pp. 6-24 (no date).
Ius Mentis, "The E!Gamal Public Key System," pp. 1-2 (Oct. 1, 2005)
online
at
http://www.iusmentis.com/technology/encyrption/
elgamal/.
Schneier, "Crypto Bibliography," Index of Crypto Papers Available
Online, pp. 1-2 (online) (no date).
No Author, No Title, pp. 344-355 (no date).
No Author, "Part Four Networks," No Title, pp. 639-714 (no date).
Microsoft Word User's Guide, pp. 773-774,315-316,487-489, 561564, 744, 624-633 (1993).
Case 2:13-cv-01112 Document 1-6 Filed 12/18/13 Page 6 of 35 PageID #: 198
US 8,001,053 B2
Page 5
No Author, "What is the ElGarnal Cryptosystem," p. 1 (Nov. 27,
2006) online at http://www.x5.net/faqs/crypto/q29.html.
Johnson et al., "A Secure Distributed Capability Based System,"
ACM, pp. 392-402 (1985).
Wikipedia, "El Garnal Encyption," pp. 1-3 (last modified Nov. 2,
2006) online at http://en.wikipedia.org/wiki/ElGarnal_encryption.
Blaze, "Atomic Proxy Cryptography," p. 1 Abstract (Oct. 20, 1998).
Blaze, "Matt Blaze's Technical Papers," pp. 1-6 (last updated Aug. 6,
2006)].
Online Search Results for "inverted file", "inverted index" from
www.techweb.com,
www.cryer.co.uk,
computing-dictionary.
thefreedictionary.com, www.nist.gov, en.wikipedia.org, www.cni.
org, www.tiscali.co.uk (Jul. 15-16, 2006).
Corporation for National Research Initiatives, "Digital Object Architecture Project", http://www.nnri.reston.va.us/doa.htrnl (updated
Nov. 28, 2006).
Stefik, Summary and Analysis ofA13 (Kahn, Robert E and Vinton G
Cerf, "The Digital Library Project, vol. 1: The World ofKnowbots
(DRAFT), An Open Architecture for a Digital Library System and a
Plan for its Development," Corporation for National Research Initiatives (Mar. 1988)), pp. 1-25 (May 30, 2007).
Johnson et al., "A Secure Distributed Capability Based System,"
Proceedings of the 1985 ACM Annual Conference on the Range of
Computing: MID-80's Perspective: MID-80's Perspective Association for Computing Machinery pp. 392-402 (1985).
"National Semiconductor and EPR Partner for Information Metering/Data Security Cards" Mar. 4, 1994, Press Release from Electronic Publishing Resources, Inc.
Weber, R., "Digital Rights Management Technology" Oct. 1995.
Flasche, U. et a!., "Decentralized Processing of Documents", pp.
119-131, 1986, Comput. & Graphics, vol. 10, No.2.
Mori, R. et al., "Superdistribution: The Concept and the Architecture", pp. 1133-1146, 1990. The Transactions of the IEICE, Vo. E 73,
No.7, Tokyo, JP.
Weber, R., "Metering Technologies for Digital Intellectual Property",
pp. 1-29, Oct. 1994, A Report to the International Federation of
Reproduction Rights Organizations.
Clark, P.C. et al., "Bits: A Smartcard protected Operating System",
pp. 66-70 and 94, Nov. 1994, Communications of the ACM, vol. 37,
No. 11.
Ross, P.E., "Data Guard", pp. 101, Jun. 6, 1994, Forbes.
Saigh, W.K., "Knowledge is Sacred", 1992, Video Pocket/Page
Reader Systems, Ltd.
Kahn, R.E., "Deposit, Registration and Recordation in an Electronic
Copyright Management System", pp. 1-19, Aug. 1992, Corporation
for National Research Initiatives, Virginia.
Hilts, P. et al., "Books While U Wait", pp. 48-50, Jan. 3, 1994,
Publishers Weekly.
Strattner, A, "Cash Register on a Chip may Revolutionaize Software
Pricing and Distribution; Wave Systems Corp.", pp. 1-3, Apr. 1994,
Computer Shopper, vol. 14, No.4, ISSN 0886-0556.
O'Conner, M., "New Distribution Option for Electronic Publishers;
iOpener Data Encryption and Metering System for CD-ROM use;
Column", pp. 1-6, Mar. 1994, CD-ROM Professional, vol. 7, No.2,
ISSN: 1409-0833.
Willett, S., "Metered PCs: Is Your System Watching You? Wave
System beta tests new technology", pp. 84, May 2, 1994, InfoWorld.
Linn, R., "Copyright and Information Services in the Context of the
National Research and Education Network", pp. 9-20, Jan. 1994,
IMA Intellectual Property Project Proceedings, vol. 1, Issue 1.
Perrit, Jr., H., "Permission Headers and Contract Law", pp. 27-48,
Jan. 1994, IMA Intellectual Property Project Proceedings, vol. 1,
Issue 1.
Upthegrove, L., "Intellectual Property Header Descriptors: A
Dynamic Approach", pp. 63-66, Jan. 1994, IMAintellectual Property
Proceedings, vol. 1, Issue 1.
Sirbu, M., "Internet Billing Service Design and prototype Implementation", pp. 67-80, Jan. 1994, IMA Intellectual Property Project Proceedings, vol. 1, Issue 1.
Simmell, S. et a!., "Metering and Licensing of Resources: Kala's
General Purpose Approach", pp. 81-110, Jan. 1994, IMAintellectual
Property Project Proceedings, vol. 1, Issue 1.
Kalm, R., "Deposit, Registration and Recordation in an Electronic
Copyright Management System", pp. 111-120, Jan. 1994, IMAintellectual Property Project Proceedings, vol. 1, Issue 1.
Tygar, J. et a!., "Dyad: A System for Using Physically Secure
Coprocessors", pp. 121-152, Jan. 1994, IMA Intellectual Property
Project Proceedings, vol. 1, Issue 1.
Griswold, G., "A Method for Protecting Copyright on Networks", pp.
169-178, Jan. 1994, IMA Intellectual Property Project Proceedings,
vol. 1, Issue 1.
Nelson, T., "A Publishing and Royalty Model for Networked Documents", pp. 257-259, Jan. 1994, IMA Intellectual Property Project
Proceedings, vol. 1, Issue 1.
Robinson, E., "Redefining Mobile Computing", pp. 238-240, 247248 and 252, Jul. 1993, PC Computing.
Abadi, M. eta!., "Authentication and Delegation with Smart-cards",
pp. 1-24, 1990, Research Report DEC Systems Research Center.
Mark Stefik, "Letting Loose the Light: Igniting Commerce in Electronic Publication", pp. 219-253, 1996, Internet Dreams: Archetypes,
Myths, and Metaphors, IDSN 0-262-19373-6.
Mark Stefik, "Letting Loose the Light: Igniting Commerce in Electronic Publication", pp. 2-35, Feb. 8, 1995, Internet Dreams: Archetypes, Myths and Metaphors.
Henry H. Perritt, Jr., "Technological Strategies for Protecting Intellectual Property in the Networked Multimedia Envirornnent", Apr.
2-3, 1993, Knowbots, Permissions Headers & Contract Law.
Perritt, "Technologies Strategies for Protecting IP in the Networked
Multimedia Envirornnent", Apr. 2-3, 1993, Knowbot Permissions.
Delaigle, "Digital Watermarking", Spie Conference in Optical Security and Counterfeit Deterrence Techniques, San Jose, CA Feb. 1996,
vol. 2659 pp. 99-110.
"The C++ Programming Language-Second Edition", Bjarne
Stroustrup, Addison-Wesley, ISBN 0-201-53992-6, 1991.
* cited by examiner
Case 2:13-cv-01112 Document 1-6 Filed 12/18/13 Page 7 of 35 PageID #: 199
U.S. Patent
Aug. 16, 2011
US 8,001,053 B2
Sheet 1 of 17
110
100
120
I
I
I
Sharing
Redistributing
Aggregating
Fig. 1
100
Provider (P)
()
]
/\
Grai)V
~
~
CY
t
I
~
~y
~=>Accept
Grant
'
/
/'J'\.
'-
.;;:_/
"'"
/
1
(
J
Aggregating
/'.Accept
"'-~
Surrendering
\
(
(- - - - \
J(\
120
Distributor (D)
Contracting
.,.~
/A,
1
I
110
A
Surrendenng
r,
~-.-~~
'
~~
Issuing
\
(')
"--
~
~(_~
A
/
G
/
~
Deriving
Fig. 2
Exe<elslng
\
ra r;rt
A\cept
I
)
1
)
I
User (U)
0
Delegating
Case 2:13-cv-01112 Document 1-6 Filed 12/18/13 Page 8 of 35 PageID #: 200
U.S. Patent
Aug. 16, 2011
US 8,001,053 B2
Sheet 2 of 17
210
200
Supplier (S)
I
()
Gs?i4~--r--~
Consumer (C)
s?
I
0
i-<=)
;\
Exercising
Fig. 3(a)
210
200
I
I
Supplier (S)
Consumer (C)
e>-J · .__._ ~ .__. ~--<~
Generating
\
Obtaining
Fig. 3(b)
Exercising
Case 2:13-cv-01112 Document 1-6 Filed 12/18/13 Page 9 of 35 PageID #: 201
~
00
•
400
~
~
Supplier Component
~
~
Consumer Component
~
~
=
~
~
~
....
Offer
Analyser
Offer
Generator
~Cl\
N
0
........
416
Consumer
Profiles
Respository for
Supplier's
Rights
414
~
Rights
Composer
{g
(])
_.
\
402
Choice
Maker
c::
rFJ
=-
('D
('D
.....
(.H
0
Repository for
Consumer's
Rights
....-....l.....
d
rJl
00
Fig. 4
=
=
=
""""'
u.
w
=
N
Case 2:13-cv-01112 Document 1-6 Filed 12/18/13 Page 10 of 35 PageID #: 202
~
00
•
Supplier
510
512
r
1
514
~
~
=
I
I
I
I
(
I
~I
:
_.;4
~
1
Generation
I
I
I
I
I
~
Consumer
I
I
I
1
1
Communication
Channel
Offer
~
~
:
Consideration
~
~
....
~Cl\
I__;J
N
0
........
Choice
I
Customization
~
Draft License
rFJ
=-
~
('D
('D
Confirmation
516
I ~ Acceptance
518
License
y
.j;o.
0
.........
-....l
IC U
d
y
Fig. 5(a)
.....
rJl
00
=
=
=
""""'
u.
w
=
N
Case 2:13-cv-01112 Document 1-6 Filed 12/18/13 Page 11 of 35 PageID #: 203
Supplier
1
:
...
~
I'~ ru
00
•
1
~
I
I
I
I
:±:I
520
~
Consumer
Communication
Channel
Request
~
~
~
=
~
Generation
522
I
Offer
I
-
524
.
~
Consideration
~
.....
0\
~
.
N
0
Choice
.....
.....
Customization
Draft License
526
I
.
rFJ
.
('D
('D
=-
......
Ul
0
......
I
528
Authentication
:
530
:
I
~~
y
1
:
fE1
~
.....
-....l
Acceptance
:
I
I
a· ::
License :.......·
::::::::
I
I
I
Fig. 5(b)
.•.
:
y:
d
rJl
00
=
=
=
""""'
u.
w
=
N
Case 2:13-cv-01112 Document 1-6 Filed 12/18/13 Page 12 of 35 PageID #: 204
~
00
•
~
~
~
~
602
608
=
~
614
618
~keOffer
ermine Rights
that can be
Offered
Collect Rights
Available
610
604
Yes
I
~
~
....
~Cl\
620
616
Yes
I
Restrict Terms for
Every Option
N
0
........
rFJ
=-
('D
('D
.....
Cl\
606
612
c _ _ __ _
0
622
.........
-....l
624
No Offer
Generated
Filter Rights
Based on Request
Offer
Authenticate
Offer
d
Fig. 6
rJl
00
=
=
=
""""'
u.
w
=
N
Case 2:13-cv-01112 Document 1-6 Filed 12/18/13 Page 13 of 35 PageID #: 205
~
00
•
~
~
~
~
702
=
~
708
714
718
'J
Collect Offers
Avaible
fcAnalyze Offers
I
~
Consumer
Preference?
I
SSiect Option
~
....
~Cl\
N
0
704
'\l"\..
706
/
-
710
'"
~
Yes
~
No
No Offer
Considered
/
1
716
~11nnli~r ~
No I
l<:
712
)
l
"Eitllt::l Vllt::l;:)
I
Based on
Preference
........
720
I
I
~~" r.nnc:11m~r
I
I
Specify
Contengency
....-....l.....
722
724
::::::::.::::::
Choice
=-
.....
-....l
0
I
f-J
rFJ
('D
('D
Authenticate
Choice
d
Fig. 7
rJl
00
=
=
=
""""'
u.
w
=
N
Case 2:13-cv-01112 Document 1-6 Filed 12/18/13 Page 14 of 35 PageID #: 206
802
~
808
00
•
814
Receive
Consumer
Choices
~
~
~
Understand
Choices
810
=
reate License
~
820
816
804
Re-negotiation
806
~
818
812
~
'
~
....
~Cl\
N
0
........
rFJ
=-
Consider Choice
Based on Profile
('D
('D
.....
QO
0
/
No
....-....l.....
'
~------~
eptance?
Authenticate
License
24
d
rJl
00
Fig. 8
=
=
=
""""'
u.
w
=
N
Case 2:13-cv-01112 Document 1-6 Filed 12/18/13 Page 15 of 35 PageID #: 207
~
00
•
10
70
., , 'j
:'Ciear-\c~
..
Content
L Appli~~~i~~~
,
,;,;
I
40
·-- %PJ'///."'"/./
...
,; : Rights Label
,
I!f;::. Document
~,~ , ---- ------ ~ ::.----- •
• "*'''' .' . .,~.
-.r·:.·Prepa.ration.··.,!. ___. . Prot~Gt.e9,;
~
~
/")~P.~S~9-:fl
=
~
~
42
'fdf#/•4'#/.i
~
~
~
....
.. ~S~iva~ion
·Server
80
>
~Cl\
·~~~~~~••on-
N
0
........
Activation
11---~-=~~~-_130
!f~t~~~~e~t
-------~
---~~:-,lt(co~mer)
· ·'. ·11·,e:.•z~£!~.c1
· · ·1'.
52
72
....___ _ _ ___,'
L"1c:ense
:
·----~~~~
' /J.I
t.r""Vjl
72
;10'40,11
••."""'.
·t
i
_,,
M"'*'':.
I
~
rFJ
=-
('D
('D
.....
\0
0
....-....l.....
60
d
Clearinghouse
Fig. 9
90
rJl
00
=
=
=
""""'
u.
w
=
N
Case 2:13-cv-01112 Document 1-6 Filed 12/18/13 Page 16 of 35 PageID #: 208
~
52
\
52a
00
•
I Label40
. I
I I I
~
~
~
Offer44
License
License id
~
1-
I Digital signature
52b
I
1- I
H
I I
Conditions
44b
1-
I
Grant [I..n]
Rights
Principal
Conditions
State variables
Ticket Specification
Rights
44a
I~ont~nt
.
SpecificatiOn
1 44c
I
I I
=
I
~
....
~Cl\
N
0
1 Rights
44a
H
Conditions
44b
II
........
I
Offer44
Cont~nt .
rFJ
=....
Specification
44c
('D
('D
.....
0
0
.........
I
Offer44
Rights
44a
Fig. 11
I
~
>
=
I
Fig. 10
~
Conditions
44b
II
Cont~nt .
Specification
44c
I I I
I
-....l
d
rJl
00
=
=
=
""""
u.
w
=
N
Case 2:13-cv-01112 Document 1-6 Filed 12/18/13 Page 17 of 35 PageID #: 209
U.S. Patent
Aug. 16, 2011
US 8,001,053 B2
Sheet 11 of 17
1200
1208
Authorization
~-----------1~
License
Manager
1203
1204
License
Interpreter
1206
1202
1216
~1220
1209
State-ofRights
Manager
1201
1214
Fig. 12
Case 2:13-cv-01112 Document 1-6 Filed 12/18/13 Page 18 of 35 PageID #: 210
~
I __.- 1301
Offer
Anyone
play
ebook
5 times
state variable id
<unspecified>
II
= _s- 1304
/
Alice
play
I ebook
5 times
state variable id =_s- 1305
AlicePiayEbook
1302
~
~
=
~
1303
. ebook
5 times
state variable id
BobPiayEbook
~
~
I
~Bob
play
00
•
>
=
~
....
~Cl\
N
0
=_s- 1306
Fig. 13
........
rFJ
Offer
Alice's PDA
play
ebook
5 times
state variable id
AlicePiayEbook
Alice's PC
play
ebook
5 times
state variable id
AlicePiayEbook
--------
L-s- 1401
=....
('D
('D
Alice's PDA
play
1406
ebook
5 times
state variable id
AlicePiayEbook
_s--
.....
N
0
1402
.........
-....l
=
= _s- 1404
d
rJl
00
_s-1403
= _s- 1405
Fig. 14
=
=
=
""""'
u.
w
=
N
Case 2:13-cv-01112 Document 1-6 Filed 12/18/13 Page 19 of 35 PageID #: 211
~
00
•
~
~
Alice
play
ebook
track usage
state variable id
www.foou.edu
Offer
any FooU student
play
ebook
track usage
state variable id
www.foou.edu
~
~
1502
=_s:- 1505
=
~
~
~
....
= _s:- 1504
Bob
play
ebook
track usage
state variable id
www.foou.edu
~Cl\
1503
=_s:- 1506
Fig. 15
N
0
........
rFJ
=....
('D
('D
.....
(.H
0
Alice
play
ebook
track usage
state variable id
l>
.........
-....l
1701
_s:- 1703
=40
d
Alice
print
ebook
track usage
1703
state variable id = 40
_s:-
I/
I/>
rJl
00
1702
Fig. 17
=
=
=
""""'
u.
w
=
N
Case 2:13-cv-01112 Document 1-6 Filed 12/18/13 Page 20 of 35 PageID #: 212
~
00
•
~
~
~
Offer
~
=
any affiliated club
issue
its club member
play
ebook
simultaneous use
state variable id
<unspecified>
~
~
=5
= _s- 1607
~
....
~Cl\
N
0
........
rFJ
=....
('D
('D
.....
.j;o.
0
.........
-....l
160
6
d
rJl
00
Fig. 16
=
=
=
'""""
u.
w
=
N
Case 2:13-cv-01112 Document 1-6 Filed 12/18/13 Page 21 of 35 PageID #: 213
U.S. Patent
Aug. 16, 2011
Sheet 15 of 17
US 8,001,053 B2
~O#
__
er____________________~ Ls-1801
any affiliated club
issue
its club member
play
ebook
simultaneous use 5
state variable id =_s- 1807
<unspecified>
state variable id =_s- 1808
<unspecified>
=
---- ----
1802~
/
any Foo club member
play
ebook
simultaneous use =5
state variable id =um:foo:club
state variable id =_s- 1808
<unspecified>
- - - - - - _..
Alice
play
ebook
simultaneous use =5
state variable id =
um:acme:club _s- 1809
state variable id =priority_2
Fig. 18
1803
Offer
Offer
any Acme club member
play
ebook
simultaneous use = 5
state variable id =
um:acme:club
state variable id =_s- 1808
<unspecified>
1804 \1\
>
> 1805
Bob
play
ebook
simultaneous use =5
state variable id =
1810
um:acme:club S
state variable id = priority_1
~ 1806
Cathy
play
ebook
simultaneous use =5
state variable id =
um:foo:club
_s- 1811
state variable id =priority_1
Case 2:13-cv-01112 Document 1-6 Filed 12/18/13 Page 22 of 35 PageID #: 214
~
1901
00
•
Offer
~
Alice's PDA
-.,. play
ebook
Alice's PDA
play
ebook
1902
~
~
=
~
L> 1903
Alice's PC
play
ebook
~
~
~
....
Fig. 19
~Cl\
N
0
........
2001
rFJ
./
=....
Offer
('D
('D
Alice's PDA
play
ebook
5 times
state variable id
Alice's PC
play
ebook
5 times
state variable id
Alice's PDA
play
ebook
5 times
state variable id
_s- 2004
=0001
l>
_s- 2004
=0001
.....
Cl\
2002
_s- 2004
0
.........
-....l
=0001
d
2003
rJl
00
Fig. 20
=
=
=
""""'
u.
w
=
N
Case 2:13-cv-01112 Document 1-6 Filed 12/18/13 Page 23 of 35 PageID #: 215
~
00
•
~
~
~
~
=
~
Offer
Alice
play
ebook
21 04
track usage
state variable id = www.foou.edu
~
2102
....
~Cl\
N
0
_s-
any FooU student can play
ebook as long as their uses
are tracked.
~
........
rFJ
Bob
play
ebook
2105
track usage
state variable id = www.foou.edu
=....
('D
('D
.....
2103
_s-
-....l
0
.........
-....l
Fig. 21
d
rJl
00
=
=
=
""""
u.
w
=
N
Case 2:13-cv-01112 Document 1-6 Filed 12/18/13 Page 24 of 35 PageID #: 216
US 8,001,053 B2
1
2
SYSTEM AND METHOD FOR RIGHTS
OFFERING AND GRANTING USING SHARED
STATE VARIABLES
mechanism to prevent legitimate users from obtaining the
clear document and then using and redistributing it in violation of content owners' intellectual property.
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 envirouments 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.
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.
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.
However, there are limitations associated with the abovementioned 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.
RELATED APPLICATION DATA
This application is a continuation-in-part application of
co-pending application Ser. No. 10/162,212 filed on Jun. 5,
2002, which is a continuation-in-part application of application Ser. No. 09/867,745 filed on May 31, 2001, and which
claims benefit from U.S. provisional application Ser. No.
60/296,113, filed in Jun. 7, 2001, U.S. provisional application, Ser. No. 60/331,625 filed in Nov. 20, 2001, and U.S.
provisional application Ser. No. 60/331,624 filed on Nov. 20,
2001, the entire disclosures of all of which are hereby incorporated by reference herein.
10
15
FIELD OF THE INVENTION
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.
20
BACKGROUND OF THE INVENTION
25
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.
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.
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
30
35
40
45
50
55
60
SUMMARY OF THE INVENTION
65
Exemplary aspects of the present invention include a
method, system and device for sharing rights adapted to be
Case 2:13-cv-01112 Document 1-6 Filed 12/18/13 Page 25 of 35 PageID #: 217
US 8,001,053 B2
3
4
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.
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.
FIG. 17 illustrates employing of a state variable in maintaining a state shared by multiple rights;
FIG. 18 illustrates employing of multiple state variables to
represent one state of rights;
FIG. 19 illustrates a case where not all rights are associated
with states;
FIG. 20 illustrates a case where not all rights which are
associated with states are shared or inherited; and
FIG. 21 illustrates a case of rights sharing based on an offer
which does not explicitly include meta-rights.
10
DETAILED DESCRIPTION
15
20
BRIEF DESCRIPTION OF THE DRAWINGS
25
Exemplary embodiments of this invention will be
described in detail, with reference to the attached drawings in
which:
FIG. 1 is a schematic diagram of a three-tier model for
content distribution;
FIG. 2 is a schematic diagram illustrating rights offering
and granting processes in the model of FIG. 1;
FIG. 3(a) is a schematic diagram of a simple supplierconsumer push model for rights generating, issuing and exercising;
FIG. 3(b) is a schematic diagram of a simple supplierconsumer pull model for rights generating, issuing and exercising;
FIG. 4 is a block diagram of a rights offering-granting
architecture in accordance with the preferred embodiment;
FIGS. Sa and Sb 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;
FIG. 6 is a flow chart of a rights offer generation process in
accordance with the preferred embodiment;
FIG. 7 is a flow chart of a rights offer consideration process
in accordance with the preferred embodiment;
FIG. 8 is a flow chart of a rights offercustomization process
in accordance with the preferred embodiment;
FIG. 9 is block diagram of a DRM system that may be
utilized in connection with the preferred embodiment;
FIG. 10 is a block diagram of an exemplary structure of a
license containing usage rights and meta-rights of the preferred embodiment;
FIG. 11 is a schematic illustration of a rights label of the
preferred embodiment;
FIG. 12 illustrates an exemplary system including a stateof-rights server;
FIG. 13 illustrates employing of a state variable in deriving
exclusive usage rights;
FIG. 14 illustrates employing of a state variable in deriving
inherited usage rights;
FIG. 15 illustrates employing of a state variable in deriving
rights that are shared among a known set of rights recipients;
FIG. 16 illustrates employing of a state variable in deriving
rights that are shared among a dynamic set of rights recipients;
30
35
40
45
50
55
60
65
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.
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 ofDRM 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.
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 often 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 label40 and license 52 are described
in detail below.
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.
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.
Case 2:13-cv-01112 Document 1-6 Filed 12/18/13 Page 26 of 35 PageID #: 218
US 8,001,053 B2
5
6
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 label40 associated with content 42 and the encryption
key used to encrypt the content can be transmitted to license
server 50.
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 "metarights". 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.
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.
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.
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.
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.
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.
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.
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 multitier 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).
An "offer of rights" or "rights offer" expresses how a
consumer (e.g. a content distributor or user) can acquire a
10
15
20
25
30
35
40
45
50
55
60
65
Case 2:13-cv-01112 Document 1-6 Filed 12/18/13 Page 27 of 35 PageID #: 219
US 8,001,053 B2
7
8
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 label40. "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.
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.
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.
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.
The model ofFIG. 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.
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.
An architecture of the preferred embodiment for rights
offering and granting is shown in FIG. 4.Architecture400 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.
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.
Consumer component 438 includes user interface module
428, communication interface module 424, identity module
10
15
20
25
30
35
40
45
50
55
60
65
Case 2:13-cv-01112 Document 1-6 Filed 12/18/13 Page 28 of 35 PageID #: 220
US 8,001,053 B2
9
10
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.
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.
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.
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.
FIG. 5(a) illustrates the workflow of protocol500 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.
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 oflicense 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.
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).
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.
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.
10
15
20
25
30
35
40
45
50
55
60
65
Case 2:13-cv-01112 Document 1-6 Filed 12/18/13 Page 29 of 35 PageID #: 221
US 8,001,053 B2
11
12
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.
FIG. 8 illustrates rights customization process 800 which is
performed by rights composer module 410 in supplier component 402. Initially, consumers 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.
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.
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.
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.
Overall, as can be seen in the description ofFIGS. 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.
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.
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.
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.
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.
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
10
15
20
25
30
35
40
45
50
55
60
65
Case 2:13-cv-01112 Document 1-6 Filed 12/18/13 Page 30 of 35 PageID #: 222
US 8,001,053 B2
14
13
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.
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.
A license from the content provider to the distributor may
resemble the following using the XrML rights language.
10
15
20
<license>
<grant>
<forAll varName~"user"/>
<forAll varName~"distributorConditionForPlay"/>
<principal id~"distributor"/>
<issue/>
<grant>
<principal varRef~"user"/>
<play/>
<digitalResource licensePartld~"book"/>
<all Condition>
<region regionCode~"US"/>
<condition varRef~''distributorConditionForPlay''/>
</all Condition>
</grant>
<fee>
<flat currencycode~"USD"> 1</flat>
<to licensePartld~"provider"/>
</fee>
</grant>
<grant>
<forAll varName~"user"/>
<forAll varName~''distributorConditionForPrint''/>
<principal id~"distributor"/>
<issue/>
<grant>
<principal varRef~"user"/>
<play/>
<digitalResource licensePartld~"book"/>
<all Condition>
<region regionCode~"US"/>
<condition varRef~''distributorConditionForPrint''/>
</all Condition>
</grant>
<fee>
<perUse regionCode~"USD">5</perUse>
<to licensePartld~"provider"/>
</fee>
</grant>
<issuer id="provider"/>
</license>
25
30
35
40
45
50
55
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.
60
65
<offer>
<grant>
<forAll varName~"user"/>
<principal varRef="user"/>
<obtain/>
<grant>
<principal varRef~"user"/>
<play/>
<digitalResource licensePartld~"book"/>
<region regionCode~"US"/>
</grant>
<fee>
<flat currencyCode~"USD">2</flat>
<to licensePartld~"distributor"/>
</fee>
</grant>
<grant>
<forAll varName~"user"/>
<principal varRef="user"/>
<obtain/>
<grant>
<principal varRef~"user"/>
<print/>
<digitalResource licensePartld~"book"/>
<all Condition>
<region regionCode~"US"/>
<fee>
<perUse currencyCode~''USD''>6</perUse>
<to licensePartld~"distributor"/>
</fee>
</all Condition>
</grant>
</grant>
<issuer id="distributor">
<validityInterval>
<until>2002:12:31 </until>
</validityInterval>
</issuer>
</offer>
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.
<choice>
<grant>
<principal id~"anEndUser"/>
<obtain/>
<grant>
<principal id~"anEndUser"/>
<play/>
<digitalResource licensePartld~"book"/>
<region regionCode~"US"/>
</grant>
<fee>
<flat currencyCode~"USD">2</flat>
<to licensePartld~"distributor"/>
</fee>
</grant>
<issuer id="anEndUser">
<validityInterval>
<until>2002:12:31 </until>
</validityInterval>
</issuer>
</choice>
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.
Case 2:13-cv-01112 Document 1-6 Filed 12/18/13 Page 31 of 35 PageID #: 223
US 8,001,053 B2
15
<license>
<grant>
<principal id~"anEndUser"/>
<obtain/>
<grant>
<principal id~"anEndUser"/>
<play/>
<digitalResource licensePartld~"book"/>
<region regionCode~"US"/>
</grant>
<fee>
<flat currencyCode~"USD">2</flat>
<to licensePartld~"distributor"/>
</fee>
</grant>
<issuer id="distributor">
<issued Time>
2002:05:06
<!issuedTime>
<!issuer>
</license>
16
10
15
20
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.
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.
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.
25
30
35
40
45
50
55
60
65
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.
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 stateof-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.
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).
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 commnnication 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.
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-ofrights 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.
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
Case 2:13-cv-01112 Document 1-6 Filed 12/18/13 Page 32 of 35 PageID #: 224
US 8,001,053 B2
17
18
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.
There are multiple ways to specify the scope of state variabies, 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, unspecified 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.
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.
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., "AliceP!ayEbook" (i.e., Alice has the right to play
Ebook) is bound to derived right 1302, and "BobP!ayEbook"
(i.e., Bob has the right to play Ebook) is bound to derived right
1303. The "AliceP!ayEbook" variable can be updated when
Alice exercises her play right, whereas the "BobP!ayEbook"
variable can be updated when Bob exercises his play right.
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.
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.
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)
ofAlice also can obtain a right to play thee-book according to
offer 1401, if the PC and PDA share the same state variables
1404 and 1405, e.g., "AliceP!ayEbook." A derived right 1402
allows Alice also to play the e-bookonher PDA as long as the
PDA and the PC share a same count limit 1406 of 5 times.
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.
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 thee-book.
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.
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."
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.
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,
10
15
20
25
30
35
40
45
50
55
60
65
Case 2:13-cv-01112 Document 1-6 Filed 12/18/13 Page 33 of 35 PageID #: 225
US 8,001,053 B2
19
20
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.
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.
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.
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.
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.
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.
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.
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 right2003 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.
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.
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 charmels 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 marmer. The various functions can be
useful separately or in combination.
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.
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.
10
15
20
25
30
35
40
45
50
55
60
65
What is claimed is:
1. A method for sharing rights adapted to be associated
with an item, the method comprising:
specifying, in a first license, using a processor, at least one
usage right and at least one meta-right for the item,
wherein the usage right and the meta-right include at
least one right that is shared among one or more users or
devices;
defining, via the at least one usage right, using a processor,
a marmer of use selected from a plurality of permitted
manners of use for the item;
defining, via the at least one meta-right, using a processor,
a mauner of rights creation for the item, wherein said at
least one meta-right is enforceable by a repository and
allows said one or more users or devices to create new
rights;
associating, using a processor, at least one state variable
with the at least one right in the first license, wherein the
at least one state variable identifies a location where a
state of rights is tracked;
generating, in a second license, using a processor, one or
more rights based on the meta-right in the first license,
wherein the one or more rights in the second license
includes at least one right that is shared among one or
more users or devices; and
Case 2:13-cv-01112 Document 1-6 Filed 12/18/13 Page 34 of 35 PageID #: 226
US 8,001,053 B2
21
22
associating at least one state variable with the at least one
right that is shared in the second license, wherein the at
least one state variable that is associated with the second
license is based on the at least one state variable that is
associated with the first license.
2. The method of claim 1, wherein the state variable in the
first or second license inherits a state thereof for content usage
or rights derivation from other generated usage rights and
meta-rights.
3. The method of claim 1, wherein the state variable in the
first or second license shares a state thereof for content usage
or rights derivation with other generated usage rights and
meta-rights.
4. The method of claim 1, wherein the state variable in the
first or second license inherits a remaining state for content
usage or rights derivation from other generated usage rights
and meta-rights.
5. The method of claim 1, wherein the state variable in the
first or second license is updated upon exercise of a right
associated with the state variable.
6. The method of claim 1, wherein the state variable in the
first or second license represents a collection of states.
7. The method of claim 1, further comprising:
generating in a third license, using a processor, one or more
rights from at least one of the usage right and the metaright in the second license,
wherein the one or more rights in the third license includes
at least one right that is shared among one or more users
or devices;
associating, using a processor, at least one state variable
with the at least one right that is shared in the third
license,
wherein the at least one state variable that is associated
with the third license is based on the at least one state
variable that is associated with the second license.
8. The method of claim 1, further comprising a plurality of
state variables that determine the state of the at least one right
that is shared in the first or the second license.
9. The method of claim 1, wherein the state variable in the
second license is transferred from the at least one right in the
first license and is associated with the right that is shared in
the second license.
10. The method of claim 1, wherein the plurality of permitted manners of use for the item include copy, transfer,
loan, play, print, delete, extract, embed, edit, authorize,
install, and nn-install the item.
11. The method of claim 1, further comprising:
generating in a further license, using a processor, one or
more rights based on the meta-right in the second
license, wherein the one or more rights in the further
license includes at least one right that is shared among
one or more users or devices; and
associating, using a processor, at least one state variable
with the at least one right that is shared in the further
license, wherein the at least one state variable that is
associated with the further license is based on the at least
one state variable that is associated with the second
license.
12. The method of claim 1, wherein the at least one state
variable that is associated with the second license is the same
as the at least one state variable that is associated with the first
license, if the at least one state variable that is associated with
the first license does not identify an unspecified location.
13. The method of claim 1, wherein the at least one state
variable that is associated with the second license is assigned
a new location identification, if the at least one state variable
that is associated with the first license identifies an unspecified location.
14. The method of claim 1, wherein two or more of the
specifYing, defining, associating, and generating steps may
be carried out using a single processor.
15. A system for sharing rights adapted to be associated
with an item, the system comprising:
a processor for specifYing in a first license at least one
usage right and at least one meta-right for the item,
wherein the usage right and the meta-right include at
least one right that is shared among one or more users or
devices;
a processor for defining, via the at least one usage right, a
manner of use selected from a plurality of permitted
manners of use for the item;
a processor for defining, via the at least one meta-right, a
manner of rights creation for the item, wherein said at
least one meta-right is enforceable by a repository and
allows said one or more users or devices to create new
rights;
a processor for associating at least one state variable with
the at least one right in the first license, wherein the at
least one state variable identifies a location where a state
of rights is tracked;
a processor for generating in a second license one or more
rights based on the meta-right in the first license,
wherein the one or more rights in the second license
includes at least one right that is shared among one or
more users or devices; and
a processor for associating at least one state variable with
the at least one right that is shared in the second license,
wherein the at least one state variable that is associated
with the second license is based on the at least one state
variable that is associated with the first license.
16. The system of claim 15, wherein the state variable in the
first or second license inherits a state thereof for content usage
or rights derivation from other generated usage rights and
meta-rights.
17. The system of claim 15, wherein the state variable in the
first or second license shares a state thereof for content usage
or rights derivation with other generated usage rights and
meta-rights.
18. The system of claim 15, wherein the state variable in the
first or second license inherits a remaining state for content
usage or rights derivation from other generated usage rights
and meta-rights.
19. The system of claim 15, wherein the state variable in the
first or second license is updated upon exercise of a right
associated with the state variable.
20. The system of claim 15, wherein the state variable in the
first or second license represents a collection of states.
21. The system of claim 15, further comprising:
a processor for generating in a third license one or more
rights from at least one of the usage right and the metaright in the second license,
wherein the one or more rights in the third license includes
at least one right that is shared among one or more users
or devices;
a processor for associating at least one state variable with
the at least one right that is shared in the third license,
wherein the at least one state variable that is associated
with the third license is based on the at least one state
variable that is associated with the second license.
22. The system of claim 15, including a plurality of state
variables that determine the state of the at least one right that
is shared in the first or the second license.
10
15
20
25
30
35
40
45
50
55
60
65
Case 2:13-cv-01112 Document 1-6 Filed 12/18/13 Page 35 of 35 PageID #: 227
US 8,001,053 B2
24
23
23. The system of claim 15, wherein the state variable in the
28. The device of claim 26, wherein the state variable in the
second license is transferred from the at least one right in the
first license and is associated with the right that is shared in
the second license.
24. The system of claim 15, wherein the plurality of permitted manners of use for the item include copy, transfer,
loan, play, print, delete, extract, embed, edit, authorize,
install, and nn-install the item.
25. The system of claim 15, wherein a single processor may
be used to carry out two or more of the specifYing, defining,
associating, and generating steps.
26. A device for sharing rights adapted to be associated
with an item, the device comprising:
a repository for receiving a first license specifYing at least
one usage right and at least one meta-right for the item,
wherein the usage right and the meta-right include at
least one right that is shared among one or more users or
devices, the least one usage right defines a marmer of use
selected from a plurality of permitted marmers of use for
the item, the at least one meta-right defines a marmer of
rights creation for the item, said at least one meta-right is
enforceable by a repository and allows said one or more
users or devices to create new rights, at least one state
variable is associated with the at least one right in the
first license and identifies a location where a state of
rights is tracked; and
a processor for generating in a second license one or more
rights based on the meta-right in the first license,
wherein the one or more rights in the second license
includes at least one right that is shared among one or
more users or devices, at least one state variable is as sociated with the at least one right that is shared in the
second license, and the at least one state variable that is
associated with the second license is based on the at least
one state variable that is associated with the first license.
27. The device of claim 26, wherein the state variable in the
first or second license inherits a state thereof for content usage
or rights derivation from other generated usage rights and
meta-rights.
first or second license shares a state thereof for content usage
or rights derivation with other generated usage rights and
meta-rights.
29. The device of claim 26, wherein the state variable in the
first or second license inherits a remaining state for content
usage or rights derivation from other generated usage rights
and meta-rights.
30. The device of claim 26, wherein the state variable in the
first or second license is updated upon exercise of a right
associated with the state variable.
31. The device of claim 26, wherein the state variable in the
first or second license represents a collection of states.
32. The device of claim 26, wherein a third license includes
one or more rights from at least one of the usage right and the
meta-right in the second license,
the one or more rights in the third license includes at least
one right that is shared among one or more users or
devices,
at least one state variable is associated with the at least one
right that is shared in the third license, and
the at least one state variable that is associated with the
third license is based on the at least one state variable
that is associated with the second license.
33. The device of claim 26, including a plurality of state
variables that determine the state of the at least one right that
is shared in the first or the second license.
34. The device of claim 26, wherein the state variable in the
second license is transferred from the at least one right in the
first license and is associated with the right that is shared in
the second license.
35. The device of claim 26, wherein the plurality of permitted marmers of use for the item include copy, transfer,
loan, play, print, delete, extract, embed, edit, authorize,
install, and nn-install the item.
10
15
20
25
30
35
* * * * *
Case 2:13-cv-01112 Document 1-7 Filed 12/18/13 Page 1 of 45 PageID #: 228
Exhibit G
Case 2:13-cv-01112 Document 1-7 Filed 12/18/13 Page 2 of 45 PageID #: 229
111111
1111111111111111111111111111111111111111111111111111111111111
US007269576B2
c12)
United States Patent
(10)
Stefik et al.
(45)
(54)
CONTENT RENDERING APPARATUS
(75)
Inventors: Mark J. Stefik, San Francisco, CA
(US); Peter L. T. Pirolli, San
Francisco, CA (US); Ralph C. Merkle,
Sunnyvale, CA (US)
(73)
( *)
(56)
Subject to any disclaimer, the term of this
patent is extended or adjusted under 35
U.S.C. 154(b) by 239 days.
3,263,158 A
Appl. No.: 10/773,306
(22)
Filed:
(65)
FOREIGN PATENT DOCUMENTS
EP
(51)
(52)
(58)
7/1983
OTHER PUBLICATIONS
Perritt, Henry H. "Knowbots, Permissions Headers and Contract
Law" (Apr. 30, 1993).*
(Continued)
Prior Publication Data
Dec. 2, 2004
Related U.S. Application Data
(60)
0 084 441
(Continued)
Feb. 9, 2004
US 2004/0243834 Al
7/1966 Bargen et al.
(Continued)
This patent is subject to a terminal disclaimer.
(21)
References Cited
U.S. PATENT DOCUMENTS
Assignee: ContentGuard Holdings, Inc.,
Wilmington, DE (US)
Notice:
Patent No.:
US 7,269,576 B2
Date of Patent:
*Sep.11,2007
Continuation of application No. 09/777,966, filed on
Feb. 7, 2001, now Pat. No. 6,944,600, which is a
division of application No. 08/967,084, filed on Nov.
10, 1997, now Pat. No. 6,236,971, which is a continuation of application No. 08/344,760, filed on Nov.
23, 1994, now abandoned.
Int. Cl.
G06Q 99100
(2006.01)
H04K 1100
(2006.01)
H04L 9100
(2006.01)
G06F 7100
(2006.01)
G06F 15116
(2006.01)
U.S. Cl. .............................. 705/50; 705/59; 707/9;
709/229; 713/182
Field of Classification Search .................. 705/50,
705/51,57, 59; 707/9, 104.1; 709/229;
713/182
See application file for complete search history.
Primary Examiner-Andrew J. Fischer
Assistant Examiner--Charlie C. L. Agwumezie
(74) Attorney, Agent, or Firm-Marc S. Kaufman; Carlos
Villamar; Nixon Peabody LLP
(57)
ABSTRACT
A system for controlling the distribution and use of digital
works using digital tickets. In the present invention, a
"digital ticket" is used to entitle the ticket holder to exercise
some usage right with respect to a digital work. Usage rights
are used to define how a digital work may be used or
distributed. Each usage right may specifY a digital ticket
which must be present before the right may be exercised.
Digital works are stored in repositories which enforce a
digital works usage rights. Each repository has a "generic
ticket agent" which punches tickets. In some instances only
the generic ticket agent is necessary. In other instances,
punching by a "special ticket agent" residing on another
repository may be needed.
36 Claims, 13 Drawing Sheets
Case 2:13-cv-01112 Document 1-7 Filed 12/18/13 Page 3 of 45 PageID #: 230
US 7,269,576 B2
Page 2
U.S. PATENT DOCUMENTS
3,609,697
3,790,700
3,798,605
4,159,468
4,220,991
4,278,837
4,323,921
4,442,486
4,529,870
4,558,176
4,593,376
4,614,861
4,644,493
4,658,093
4,713,753
4,796,220
4,817,140
4,827,508
4,868,376
4,882,752
4,891,838
4,924,378
4,932,054
4,937,863
4,949,187
4,953,209
4,961,142
4,975,647
4,977,594
4,999,806
5,010,571
5,014,234
5,023,907
5,047,928
5,050,213
5,052,040
5,058,164
5,103,476
5,113,519
5,136,643
5,138,712
5,146,499
5,148,481
5,159,182
5,183,404
5,191,193
5,204,897
5,222,134
5,224,163
5,235,642
5,247,575
5,255,106
5,260,999
5,263,157
5,263,158
5,276,444
5,276,735
5,291,596
5,299,263
5,301,231
5,311,591
5,319,705
5,337,357
5,339,091
5,341,429
5,347,579
5,381,526
5,394,469
5,410,598
5,412,717
5,428,606
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
*
9/1971
2/1974
3/1974
6/1979
9/1980
7/1981
4/1982
4/1984
7/1985
12/1985
6/1986
9/1986
2/1987
4/1987
12/1987
111989
3/1989
5/1989
9/1989
1111989
111990
5/1990
6/1990
6/1990
8/1990
8/1990
10/1990
12/1990
12/1990
3/1991
4/1991
5/1991
6/1991
9/1991
9/1991
9/1991
10/1991
4/1992
5/1992
8/1992
8/1992
9/1992
9/1992
10/1992
2/1993
3/1993
4/1993
6/1993
6/1993
8/1993
9/1993
10/1993
1111993
1111993
1111993
111994
111994
3/1994
3/1994
4/1994
5/1994
6/1994
8/1994
8/1994
8/1994
9/1994
111995
2/1995
4/1995
5/1995
6/1995
Blevins et a!.
Callais et al.
Feistel
Barnes et al.
Hamano eta!.
Best
Guillou
Mayer
Chaum
Arnold eta!.
Yolk
Pavlov et al.
Chandra et a!.
Hellman
Beo bert et al.
Wolfe
Chandra et a!.
Shear
Lessin eta!.
Lindman et a!.
Faber ............................ 726/5
Hershey et a!.
Chou eta!.
Robert eta!.
Cohen
Ryder, Sr. et a!.
Elliott et a!.
Downer eta!.
Shear
Chernow et a!.
Katznelson
Edwards, Jr.
Johnson et a!.
Wiedemer
Shear
Preston et a!.
Elmer et al.
Waite eta!.
Johnson et a!.
Fischer
Corbin
Geffrotin
Abraham et a!.
Eisele
Aldous eta!.
LeRoux
Wyman
Waite eta!.
Gasser eta!.
Wobber et al.
Sprague et a!.
Castro
Wyman
Janis
Janis
McNair
Boebert et al.
Mita
Beller et al.
Abraham et a!.
Fischer
Halter eta!.
Chou eta!.
Yamazaki et a!.
Stringer et a!.
Blandford
Elison
Nagel et al.
Shear
Fischer
Moskowitz
5,432,849
5,438,508
5,444,779
5,453,601
5,455,953
5,457,746
5,473,687
5,473,692
5,499,298
5,502,766
5,504,814
5,504,818
5,504,837
5,509,070
5,530,235
5,532,920
5,534,975
5,539,735
5,563,946
5,568,552
5,621,797
5,629,980
5,633,932
5,634,012
5,638,443
5,649,013
5,655,077
5,708,717
5,734,823
5,734,891
5,737,413
5,737,416
5,745,569
5,748,783
5,757,907
5,761,686
5,765,152
5,768,426
5,825,892
5,892,900
5,910,987
5,915,019
5,917,912
5,920,861
5,940,504
5,943,422
5,949,876
5,982,891
5,999,949
6,047,067
6,112,181
6,115,471
6,135,646
6,138,119
6,157,721
6,185,683
6,226,618
6,233,684
6,237,786
6,240,185
6,253,193
6,292,569
6,301,660
6,327,652
6,330,670
6,345,256
6,363,488
6,389,402
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
B1
*
*
7/1995
8/1995
8/1995
9/1995
10/1995
10/1995
12/1995
12/1995
3/1996
3/1996
4/1996
4/1996
4/1996
4/1996
6/1996
7/1996
7/1996
7/1996
10/1996
10/1996
4/1997
5/1997
5/1997
5/1997
6/1997
7/1997
8/1997
111998
3/1998
3/1998
4/1998
4/1998
4/1998
5/1998
5/1998
6/1998
6/1998
6/1998
10/1998
4/1999
6/1999
6/1999
6/1999
7/1999
8/1999
8/1999
9/1999
1111999
12/1999
4/2000
8/2000
9/2000
10/2000
10/2000
12/2000
2/2001
5/2001
5/2001
5/2001
5/2001
6/2001
9/2001
10/2001
12/2001
12/2001
212002
3/2002
5/2002
Johnson et a!.
Wyman
Daniele
Rosen
Russell
Dolphin
Lipscomb et a!. ............ 705/51
Davis
Narasimhalu eta!.
Boebert et a!.
Miyahara
Okano
Griffeth et a!.
Schull
Stefik et al.
Hartrick et a!.
Stefik et al.
Moskowitz
Cooper eta!.
Davis
Rosen
Stefik et al.
Davis et al.
Stefik et al.
Stefik et al.
Stuckey et a!.
Jones eta!.
Alasia
Saigh eta!.
Saigh
Akiyama et a!.
Cooper eta!.
Moskowitz et a!.
Rhoads
Cooper eta!.
Bloomberg
Erickson
Rhoads
Braudaway et al.
Ginter eta!.
Ginter eta!.
Ginter eta!.
Ginter eta!. ............... 713/187
Hallet a!.
Griswold
VanWie eta!.
Ginter eta!.
Ginter eta!.
Crandall
Rosen
Shear eta!.
Oki eta!.
Kalm eta!.
Hallet a!.
Shear eta!.
Ginter eta!.
Downs eta!.
Stefik et al.
Ginter eta!.
VanWie eta!.
Ginter eta!.
Shear eta!.
Benson
England et a!.
England et a!.
Milsted eta!.
Ginter eta!.
Ginter eta!.
FOREIGN PATENT DOCUMENTS
EP
EP
0 180 460
0 332 707
5/1986
9/1989
Case 2:13-cv-01112 Document 1-7 Filed 12/18/13 Page 4 of 45 PageID #: 231
US 7,269,576 B2
Page 3
EP
EP
EP
EP
GB
GB
JP
JP
JP
JP
JP
JP
JP
JP
JP
JP
wo
wo
wo
wo
wo
wo
wo
wo
wo
0 538 216 A1
0 651 554
0 668 695
0 725 376
2 136 175
2 236 604
62-241061
64-068835
04-369068
05-268415
06-175794
06-215010
07-084852
07-200317
07-244639
0 715 241
W092/20022
W093/01550
W094/01821
W096/24092
W097/48203
W098/11690
W098/42098
W099/49615
wo 01163528
4/1993
5/1995
8/1995
8/1996
9/1984
4/1991
10/1987
3/1989
12/1992
10/1993
6/1994
8/1994
3/1995
8/1995
9/1995
6/1996
1111992
111993
111994
8/1996
12/1997
3/1998
9/1998
9/1999
8/2001
OTHER PUBLICATIONS
Perritt, Henry H. 'Knowbots, Permissions Headers and Contract
Law' (Apr. 30, 1993).*
"National Semiconductor and EPR Partner for Information Metering/Data Security Cards" Mar. 4, 1994, Press Release from Electronic Publishing Resources, Inc.
Weber, R., "Digital Rights Management Technology" Oct. 1995.
Flasche, U. et a!., "Decentralized Processing of Documents", pp.
119-131, 1986, Comput. & Graphics, vol. 10, No.2.
Mori, R. et al., "Superdistribution: The Concept and the Architecture", pp. 1133-1146, 1990. The Transactions of the IEICE, Vo. E
73, No. 7, Tokyo, JP.
Weber, R., "Metering Technologies for Digital Intellectual Property", pp. 1-29, Oct. 1994, A Report to the International Federation
of Reproduction Rights Organizations.
Clark, P.C. eta!., "Bits: A Smartcard protected Operating System",
pp. 66-70 and 94, Nov. 1994, Communications of the ACM, vol. 37,
No. 11.
Ross, P.E., "Data Guard", pp. 101, Jun. 6, 1994, Forbes.
Saigh, W.K., "Knowledge is Sacred", 1992, Video Pocket/Page
Reader Systems, Ltd.
Kahn, R.E., "Deposit, Registration and Recordation in an Electronic
Copyright Management System", pp. 1-19, Aug. 1992, Corporation
for National Research Initiatives, Virginia.
Hilts, P. et a!., "Books While U Wait", pp. 48-50, Jan. 3, 1994,
Publishers Weekly.
Strattner, A, "Cash Register on a Chip may Revolutionaize Software
Pricing and Distribution; Wave Systems Corp.", pp. 1-3, Apr. 1994,
Computer Shopper, vol. 14, No. 4, ISSN 0886-0556.
O'Conner, M., "New Distribution Option for Electronic Publishers;
iOpener Data Encryption and Metering System for CD-ROM use;
Column", pp. 1-6, Mar. 1994, CD-ROM Professional, Vol. 7, No.2,
ISSN: 1409-0833.
Willett, S., "Metered PCs: Is Your System Watching You? Wave
System beta tests new technology", pp. 84, May 2, 1994, InfoWorld.
Linn, R., "Copyright and Information Services in the Context of the
National Research and Education Network", pp. 9-20, Jan. 1994,
IMA Intellectual Property Project Proceedings, vol. 1, Issue 1.
Perrit, Jr., H., "Permission Headers and Contract Law", pp. 27-48,
Jan. 1994, IMA Intellectual Property Project Proceedings, vol. 1,
Issue 1.
Upthegrove, L., "Intellectual Property Header Descriptors: A
Dynamic Approach", pp. 63-66, Jan. 1994, IMA Intellectual Property Proceedings, vol. 1, Issue 1.
Sirbu, M., "Internet Billing Service Design and prototype Implementation", pp. 67-80, Jan. 1994, IMAintellectual Property Project
Proceedings, vol. 1, Issue 1.
Simmell, S. et a!., "Metering and Licensing of Resources: Kala's
General Purpose Approach", pp. 81-110, Jan. 1994, IMA Intellectual Property Project Proceedings, vol. 1, Issue 1.
Kalm, R., "Deposit, Registration and Recordation in an Electronic
Copyright Management System", pp. 111-120, Jan. 1994, IMA
Intellectual Property Project Proceedings, vol. 1, Issue 1.
Tygar, J. et a!., "Dyad: A System for Using Physically Secure
Coprocessors", pp. 121-152, Jan 1994, IMA Intellectual Property
Project Proceedings, vol. 1, Issue 1.
Griswold, G., "A Method for Protecting Copyright on Networks",
pp. 169-178, Jan. 1994, IMA Intellectual Property Project Proceedings, vol. 1, Issue 1.
Nelson, T., "A Publishing and Royalty Model for Networked
Documents", pp. 257-259, Jan. 1994, IMA Intellectual Property
Project Proceedings, vol. 1, Issue 1.
Robinson, E., "Redefining Mobile Computing", pp. 238-240, 247248 and 252, Jul. 1993, PC Computing.
Abadi, M. et al., "Authentication and Delegation with Smart-cards",
pp. 1-24, 1990, Research Report DEC Systems Research Center.
Mark Stefik, "Letting Loose the Light: Igniting Commerce in
Electronic Publication", pp. 219-253, 1996, Internet Dreams:
Archetypes, Myths, and Metaphors, IDSN 0-262-19373-6.
Mark Stefik, "Letting Loose the Light: Igniting Commerce in
Electronic Publication", pp. 2-35, Feb. 8, 1995, Internet Dreams:
Archetypes, Myths and Metaphors.
Henry H. Perritt, Jr., "Technological Strategies for Protecting Intellectual Property in the Networked Multimedia Environment", Apr.
2-3, 1993, Knowbots, Permissions Headers & Contract Law.
* cited by examiner
Case 2:13-cv-01112 Document 1-7 Filed 12/18/13 Page 5 of 45 PageID #: 232
U.S. Patent
Sep.11,2007
US 7,269,576 B2
Sheet 1 of 13
Figure 1
101
Creator Creates A
Digital Work
~,
102
Usage Rights Attached To
Di~ital Work and
Depostted In Repository 1
~,
103
Repository 2 Initiates A
Sesseon With Repository 1
,,
104
Repository 2 Requests
Access To Otgital Work for
A Stated Purpose
105
RepositorY 1 Checks Usage
Rights of Digital Work To
Determined if Access May Be
Granted
~,
Access Denied
106
Repostiory 1
Terminates Session
With Error
Access Granted
~,
107
Repository 1 Transmits
Digital Work To
Repository 2
108
Repository land 2 Each
Generate Billing
lnformati nand Transmit
T Credit Server
Case 2:13-cv-01112 Document 1-7 Filed 12/18/13 Page 6 of 45 PageID #: 233
U.S. Patent
Sep.l1,2007
US 7,269,576 B2
Sheet 2 of 13
Figure 2
•••••••••••••
: Master :
: Repository :
Repository
Transactions
205
~
••••••••••••••••
:
••
204
I • • •
• • •
.•• ..••
• • • ••••
• • • I
•
• • • • ••
•••
• •••••••••••
1-~-~-.: Rendering :
•
•
: Authorization;.:_..·-~·--1~
: Repository • •
:
202
:,........,......_
•
• •
...
.
••••••••••••••••
Repository
Transactions
205
:
••
: Repository:
.........- . . -...•
203
:
:
...- - - t
.
•
•••• •
•
I
I
I
I
I
I
I
I
.
I I.
Figure 3
..
.
Repository
201
~
.....
Billin9
302
Transacttons
•••
• •
.• •
•
•
•
•
•
•
•
• •
• •
...
Credit
Server
301
Clearinghouse
Protocol
~ ~
/
.
••••• •
•• •
••
•
••• ••••• •
/
, r
•• • • •••••• ••• •
:
Billing
:
: Clearingtlouse:
:
303
:
••••••••••••••••
304
Case 2:13-cv-01112 Document 1-7 Filed 12/18/13 Page 7 of 45 PageID #: 234
U.S. Patent
US 7,269,576 B2
Sheet 3 of 13
Sep.11,2007
Print r System
Figure 4a
401
:---------------------~
I
I
I
I
I
.
Printer
Repository
402
L--
I
I
I
I
I
Print Device
403
•tt
--- ~--------------
--J
Repository
404
Figure 4b
Multi-Fu.nction System
410
.------------------------------,I
I
I
I
I
I
I
I
I
I
I
I
I
I
L-
Credit
Server
414
....
...
Display/
Execution
Repository
r+
Display
Engine
412
~
411
...
4
Execution
Engine
413
-----------·,,------------Repository
415
____
,..~
Case 2:13-cv-01112 Document 1-7 Filed 12/18/13 Page 8 of 45 PageID #: 235
U.S. Patent
Sep.11,2007
40,000
20,000
0
10,000
30,000
60,000
Ad
511
80,000
50,000
70,000
I
I
I
Story A
510
US 7,269,57 6 B2
Sheet 4 of 13
Story B
512
90,000
Stogc
51
Figure 5
0
10,000
30,000
1,500
Text
614
25,000
Photo
Graphia
615
616
Figure 6
Sidebar
617
Case 2:13-cv-01112 Document 1-7 Filed 12/18/13 Page 9 of 45 PageID #: 236
U.S. Patent
US 7,269,576 B2
Sheet 5 of 13
Sep.11,2007
Identifier 701
Figure 7
Starting Address 702
Descriptor
Block
Length 703
(d-b lock)
700
Rights Portion 704
Parent Pointer 705
Child Pointer 706
•
•
••
••
•
I
•
•
•
•
•
•
•
Child Pointer 706
I
Top
d-block
Figure 8
820
d-block
d-block
(Story A)
(Ad)
821
d-block
822
823
(Story B)
d-block
824
(Story C)
d-block
Figure 9
821
(Story A)
d-block
925
(Text)
d-block
926
(Photo)
d-block
d-block
(Graphics)
(Sidebar)
927
928
Case 2:13-cv-01112 Document 1-7 Filed 12/18/13 Page 10 of 45 PageID #: 237
U.S. Patent
Sep.11,2007
Sheet 6 of 13
US 7,269,576 B2
Figure 10
Right
Code
1050
Status
Information
1052
Figure 14
Right
1450
Transactional
Component
1451
Specification
Component
1452
Fees/Incentives
1454
Access
1456
Case 2:13-cv-01112 Document 1-7 Filed 12/18/13 Page 11 of 45 PageID #: 238
U.S. Patent
Sep.11,2007
US 7,269,576 B2
Sheet 7 of 13
Identifier (Magazine)
Starting Address (0)
Figure 11
Length (100,000)
rcot
d-block
1101
Rights Portion
(PRINT,VIEW)
Parent Pointer:
Child Pointers
Identifier (Article 2)
'Starting Address
(25,001)
Starting Address (0)
Length (25,000)
Length (25,000)
Rights Portion
(PRINT, VIEW)
Rights Portion
(PRINT,VIEW)
Parent Pointer
Parent Pointer
Child Pointers
Child Pointers
d-block
1102
d-block
1105
Identifier (Article 3)
Identifier (Article 4)
Starting Address
(50.001)
Starting Address
(75,001)
Length (25,000)
Length (25,000)
Rights Portion
(VIEW)
Rights Portion
(PRINT (Fee))
Parent Pointer
Parent Pointer
Child Pointers
Child Pointers
d-block
1103
d-bl ck
1104
Case 2:13-cv-01112 Document 1-7 Filed 12/18/13 Page 12 of 45 PageID #: 239
U.S. Patent
Sep.11,2007
US 7,269,576 B2
Sheet 8 of 13
Rgure 12
Processing
Means
~
....
Processor
•"
•
Memory
.
•
.... 1202
.•
••••••••••••••••••••••••••••••••
1200
0
Clock
1205
. .·
Yo
.._
Processing "
Element
1201
•
.:•
...
Descriptor
Storage
• e e e e •
e e
I
I
I
•
•
•
I
I
I
e e
I
I
I. I
I
I
I
I
I
•
User
Interface
1305
Repository Spedic
SoftWare
Function/Services
1304
Usage Transaction
Handlers
1303
1302
Operating
System
1301
:
:
1204
Figure 13
Core Repository
Serv1ces/
Transaction
Handling
•
Content
Storage
1203
I
~~~:~
···············:~
:····················
•
1206
.~-H-r~~~
··············I·····r····· · ·· ····
•
..
External
Interface
Identification
Certificates
1306
...
.
°
I
•
I
I
•
I.
1207
Case 2:13-cv-01112 Document 1-7 Filed 12/18/13 Page 13 of 45 PageID #: 240
U.S. Patent
Sep.11,2007
Sheet 9 of 13
US 7,269,57 6 B2
FIGURE 15
1:SOl -
Digital W rk Rights:= (Rights*)
l$a.a.-
Rigbt : = (Right-Code {Copy-Count} {Control-Spec} {Time.Spec } {Acc:ess-Spec} {FeeSpec})
''5o!- Right-Code : = Render-Code I Transport-Code I FUe-Ma.nagement-Codel Derivative-
Works· Code I Configuration-Code
\50'4-
Render-Code:= [Play: {Player: Player-ID} I Print: (Printer: Printer-ID}]
:= [Copy I Transfer I Loan {Remaining-Rights: Next-Set-of·
Rights}]{(Next-Copy-Rights: Next-Set-of-Rights)}
1e01- Transport-Code
!Solo ..
File-Management-Code := Backup {Back-Up-Copy-Rights: Next-Set-ofRights} I Restore I Delete I Folder I Directory
{Name: Hide-.Loc:all Hide-Remote} {Parts: HideLocal! Hide-Remote}
1scn- Derivative-Works-Code:=
{Extract I Embed I Edit{Process: Process-IDH
{Next-Copy-Rights: Next-Set-of Rights}
••••- Cooliguration-Code : = Install I Uninstall
IS~ ... Nezt-Set-of-Rigbts : = {(Add: Set-Of-Rights)} {(Delete: Set-Of-Rights)}
{(Replace: Set-Of-Rights >H<Keep: Set-Of-Rights >}
•••o- Copy-Count:= (Copies:positive-integer I 0 I Unlimited)
• 511-
Control-Spec:= (Control: {Restrictable I Unrestrictable} {Unchargeable I Chargeable}J
1CO:t. ...
Time-Spec:= ({Fixed-Intervall Sliding-Interval I Meter-Time} Until: Expiration-Date!
Fixed-Interval:= From: Start-Time
1515-
IS\-t-
SUding-Interval:
=Interval: Use-Duration
t6r,-Meter-Time: =Time-Remaining: Remaining-Use
'''"-Acc:ess-8pec :=
•Sn- Fee-Spec:=
({SC: Security-Class~ {Authorization: Authorization-ID*} (OtherAuthorization: Autborization-ID*} {Ticket: Tic:ket-ID}>
{Scheduled-Discount} Regular-Fee-Spec I Scheduled-Fee-Spec: I Markup·
Spec
161t-
Scheduled-Discount:= Scheduled-Discount: (Scheduled-Discount: (Time-Spec
Percentage)*)
<{Fee: I Incentive:} (Per-Use-Spec I Metered-Rate-Spec I BestPrice-Spec I Call-For-Price-Spec) {Min: Money-Unit Per: Time-Spec}{Mu: Money·
Unit Per: Time-Spec) To: Acc:ount-IDI
1S1'\- Regular-Fee-Spec:=
1e~o-
Per-Use-Spec:= Per-Use: Money-unit
•r.l\ ..... Metered-Rate-Spec:= Metered: Money-Unit Per: Time-Spec
IS~
-Best-Price-Spec:= Best-Price: Money-unit Mu: Money-unit
sf'.a- CaD-For-Price-Spec : = Call-For -Price
1s.l.'t-
Scheduled·F -Spec:= (Schedule: (Time-Spec Regular-Fee-Spec:) )
1 54 -Markup-Spec:=
Markup: percentage To: Account-ID
Case 2:13-cv-01112 Document 1-7 Filed 12/18/13 Page 14 of 45 PageID #: 241
U.S. Patent
Sep.l1,2007
Sheet 10 of 13
US 7,269,576 B2
Figure 16
REPOSITORY-1
1601
Generate Registration Identifier
N
1605
Generate Registration Message
1603
Transmit Registration Message
Decrypt Registration Message
1606
1------'
1611
Decrypt Performance Message
Save Enaypted Repository-1
Registration Identifier
Extract Repository-1 Identifier
Generate Performance Message
~----------~----------~1610
Transmit Performance Message
No
Yes
1615
Transmit Nonce
1618
1616
Repository- I Terminate
Transaction
Repository- 2 Terminate
Transaction
Case 2:13-cv-01112 Document 1-7 Filed 12/18/13 Page 15 of 45 PageID #: 242
U.S. Patent
Sep. 11,2007
Sheet 11 of 13
US 7,269,576 B2
Figure 17
REPOSITORY·1
REPOSITORY·2
1701
1704
Create a Session Key Pair
~!
I
Decrypt Second Key
1702
Encrypt Second Key Using Public
Key of Repository-2
1705
Generate Timestamp
Exchange Message
1703
1706
Transmit Encrypted Second Key
To Repository-2
Transmit Timestamp
Exchange Message To
Repository-1
1707
Generate Timestamp
Message
1709
~
Note Current Time
I
1708
lr
Transmit Timestamp
Message To Repository-2
1710
Save Time From Repository-1
1711
Compare Current Time With
Time From Repository·1
1712
Time
Difference Exceed
Tolerance?
No
Yes
1713
Terminate Transaction
1714
Compute Adjusted Time
Delta
'
End
~
Case 2:13-cv-01112 Document 1-7 Filed 12/18/13 Page 16 of 45 PageID #: 243
U.S. Patent
Sep.l1,2007
Sheet 12 of 13
US 7,269,576 B2
Figure 18
SERVER
REQUESTER
1803
Server Generates Transacti n
Identifier
1807
Decrement Copy
Count For Right
Yes
1813
Determine Set
Of Remaining
Rights
1805
_...,..Terminate Transaction
,817
Decrement Copies In Use For
Right By Number In Request
1818
For Metered Use, Subtract
Elapsed Time From Remaining
Use Time For Right
Perform Usag
Transaction Steps
1819
Initiate End-Charge Financial
Transaction t C nfirm Billing
Case 2:13-cv-01112 Document 1-7 Filed 12/18/13 Page 17 of 45 PageID #: 244
U.S. Patent
Sep.l1,2007
Sheet 13 of 13
US 7,269,576 B2
Figure 19
SERVER
(Cancel)
Fail
1912
WaitForAck
1908
ro;;;-1
New
Send
Transaction .__ _ _trof Next Data
1902
\
\
\
\
''
''
\
Data
''
''
\
\
1907
\
\
1903 \
\
''
''
''
''
•••••••••••• \
CUENT
Wait For
Transaction
Commit Report To
Credit Server
NoMore
Data
Start \
1904
~
1906
1914
''
'
Ack
''
Ack
''
'
• • • • • • • • • • • • • • • • • • ~ •••• J • • • • • • • • • • • • • • • • • • • • • •
''
Line
1901
...............
.
''
''
''
'
''
''
•
'
Wait For
Data
1905
''
''
'
•
I
'
"
~
Data
Received
No More
Commit Report To
Data
Credit Server
1909
1916
More
Data
Ackn wledg
1910
, . ,.,)V
Rep rt Err r
T Credit Server
1918
,
Fail
1913
0 ne
r
1919
...-
-
Case 2:13-cv-01112 Document 1-7 Filed 12/18/13 Page 18 of 45 PageID #: 245
US 7,269,576 B2
1
2
CONTENT RENDERING APPARATUS
A system for ensuring that licenses are in place for using
licensed products is described in PCT Publication WO
93/01550 to Griswold entitled "License Management System and Method." The licensed product may be any electronically published work but is most effective for use with
works that are used for extended periods of time such as
software programs. Griswold requires that the licensed product contain software to invoke a license check monitor at
predetermined time intervals. The license check monitor
generates request data grams which identifY the licensee. The
request datagrams are sent to a license control system over
an appropriate communication facility. The license control
system then checks the datagram to determine if the datagram is from a valid licensee. The license control system
then sends a reply datagram to the license check monitor
indicating denial or approval of usage. The license control
system will deny usage in the event that request datagrams
go unanswered after a predetermined period of time (which
may indicate an unauthorized attempt to use the licensed
product). In this system, usage is managed at a central
location by the response datagrams. So for example if
license fees have not been paid, access to the licensed
product is terminated.
It is argued by Griswold that the described system is
advantageous because it can be implemented entirely in
software. However, the system described by Griswold has
limitations. An important limitation is that during the use of
the licensed product, the user must always be coupled to an
appropriate communication facility in order to send and
receive datagrams. This creates a dependency on the communication facility. So if the communication facility is not
available, the licensed product cannot be used. Moreover,
some party must absorb the cost of communicating with the
license server.
A system for controlling the distribution of digitally
encoded books is embodied in a system available from VPR
Systems, LTD. of St. Louis, Mo. The VPR system is
self-contained and is comprised of: (1) point of sale kiosks
for storing and downloading of books, (2) personal storage
mediums (cartridges) to which the books are downloaded,
and (3) readers for viewing the book. In a purchase transaction, a purchaser will purchase a voucher card representing the desired book. The voucher will contain sufficient
information to identify the book purchased and perhaps
some demographic information relating to the sales transaction. To download the book, the voucher and the cartridge
are inserted into the kiosk.
The VPR system may also be used as a library. In such an
embodiment, the kiosk manages the number of"copies" that
may be checked out at one time. Further, the copy of the
book is erased from the users cartridge after a certain
check-out time has expired. However, individuals cannot
loan books because the cartridges may only be used with the
owners reader.
The foregoing distribution and protection schemes operate in part by preventing subsequent distribution of the work.
While this certainly prevents unauthorized distributions, it
does so by sacrificing the potential for subsequent revenue
bearing uses. For example, it may be desirable to allow the
lending of a purchased work to permit exposure of the work
to potential buyers. Another example would be to permit the
creation of a derivative work for a fee. Yet another example
would be to permit copying the work for a fee (essentially
purchasing it). Thus, it would be desirable to provide flexibility in how the owner of a digital work may allow it to be
distributed.
FIELD OF THE INVENTION
The present invention relates to the field of distribution
and usage rights enforcement for digitally encoded works.
BACKGROUND OF THE INVENTION
A fundamental issue facing the publishing and information industries as they consider electronic publishing is how
to prevent the unauthorized and unaccounted distribution or
usage of electronically published materials. Electronically
published materials are typically distributed in a digital form
and recreated on a computer based system having the
capability to recreate the materials. Audio and video recordings, software, books and multimedia works are all being
electronically published. Companies in these industries
receive royalties for each accounted for delivery of the
materials, e.g. the sale of an audio CD at a retail outlet. Any
unaccounted distribution of a work results in an unpaid
royalty (e.g. copying the audio recording CD to another
digital medium.)
The ease in which electronically published works can be
"perfectly" reproduced and distributed is a major concern.
The transmission of digital works over networks is commonplace. One such widely used network is the Internet.
The Internet is a widespread network facility by which
computer users in many universities, corporations and government entities communicate and trade ideas and information. Computer bulletin boards found on the Internet and
commercial networks such as CompuServ and Prodigy
allow for the posting and retrieving of digital information.
Information services such as Dialog and LEXIS/NEXIS
provide databases of current information on a wide variety
of topics. Another factor which will exacerbate the situation
is the development and expansion of the National Information Infrastructure (the Nil). It is anticipated that, as the Nil
grows, the transmission of digital works over networks will
increase many times over. It would be desirable to utilize the
Nil for distribution of digital works without the fear of
widespread unauthorized copying.
The most straightforward way to curb unaccounted distribution is to prevent unauthorized copying and transmission. For existing materials that are distributed in digital
form, various safeguards are used. In the case of software,
copy protection schemes which limit the number of copies
that can be made or which corrupt the output when copying
is detected have been employed. Another scheme causes
software to become disabled after a predetermined period of
time has lapsed. A technique used for workstation based
software is to require that a special hardware device must be
present on the workstation in order for the software to run,
e.g., see U.S. Pat. No. 4,932,054 entitled "Method and
Apparatus for Protecting Computer Software Utilizing
Coded Filter Network in Conjunction with an Active Coded
Hardware Device." Such devices are provided with the
software and are commonly referred to as dongles.
Yet another scheme is to distribute software, but which
requires a "key" to enable it's use. This is employed in
distribution schemes where "demos" of the software are
provided on a medium along with the entire product. The
demos can be freely used, but in order to use the actual
product, the key must be purchased. These scheme do not
hinder copying of the software once the key is initially
purchased.
10
15
20
25
30
35
40
45
50
55
60
65
Case 2:13-cv-01112 Document 1-7 Filed 12/18/13 Page 19 of 45 PageID #: 246
US 7,269,576 B2
3
4
While flexibility in distribution is a concern, the owners
of a work want to make sure they are paid for such
distributions. In U.S. Pat. No. 4,977,594 to Shear, entitled
"Database-Usage Metering and Protection System and
Method," a system for metering and billing for usage of
information distributed on a CD-ROM is described. The
system requires the addition of a billing module to the
computer system. The billing module may operate in a
number of different ways. First, it may periodically communicate billing data to a central billing facility, whereupon
the user may be billed. Second, billing may occur by
disconnecting the billing module and the user sending it to
a central billing facility where the data is read and a user bill
generated.
U.S. Pat. No. 5,247,575, Sprague et a!., entitled "Information Distribution System", describes an information distribution system which provides and charges only for user
selected information. A plurality of encrypted information
packages (IPs) are provided at the user site, via high and/or
low density storage media and/or by broadcast transmission.
Some of the IPs may be of no interest to the user. The IPs
of interest are selected by the user and are decrypted and
stored locally. The IPs may be printed, displayed or even
copied to other storage medias. The charges for the selected
IP's are accumulated within a user apparatus and periodically reported by telephone to a central accounting facility.
The central accounting facility also issues keys to decrypt
the IPs. The keys are changed periodically. If the central
accounting facility has not issued a new key for a particular
user station, the station is unable to retrieve information
from the system when the key is changed.
A system available from Wave Systems Corp. of Princeton, N.Y., provides for metering of software usage on a
personal computer. The system is installed onto a computer
and collects information on what software is in use, encrypts
it and then transmits the information to a transaction center.
From the transaction center, a bill is generated and sent to
the user. The transaction center also maintains customer
accounts so that licensing fees may be forwarded directly to
the software providers. Software operating under this system
must be modified so that usage can be accounted.
Known techniques for billing do not provide for billing of
copies made of the work. For example, if data is copied from
the CD-ROM described in Shear, any subsequent use of the
copy of the information cannot be metered or billed. In other
words, the means for billing runs with the media rather than
the underlying work. It would be desirable to have a
distribution system where the means for billing is always
transported with the work.
After a copy of the digital work is successfully sent to the
requesting party, the digital ticket is "punched" to indicate
that a copy of the digital work has been made. When the
ticket is "punched" a predetermined number of times, it may
no longer be used.
Digital works are stored in repositories. Repositories
enforce the usage rights for digital works. Each repository
has a "generic ticket agent" which punches tickets. In some
instances only the generic ticket agent is necessary. In other
instances, punching by a "special ticket agent" residing on
another repository may be desired. Punching by a "special
ticket agent" enables greater security and control of the
digital work. For example, it can help prevent digital ticket
forgery. Special ticket agents are also useful in situations
where an external database needs to be updated or checked.
A digital ticket is merely an instance of a digital work.
Thus, a digital ticket may be distributed among repositories
in the same fashion as other digital works.
A digital ticket may be used in many commercial scenarios such as in the purchase of software and prepaid
upgrades. A digital ticket may also be used to limit the
number of times that a right may be exercised. For example,
a user may purchase a copy of a digital work, along with the
right to make up to 5 Copies. In this case, the Copy right
would have associated therewith a digital ticket that can be
punched up to 5 times. Other such commercial scenarios will
become apparent from the detailed description.
10
15
20
25
BRIEF DESCRIPTION OF THE DRAWINGS
30
35
40
45
50
SUMMARY OF THE INVENTION
A system for controlling the distribution and use of digital
works using digital tickets is disclosed. A ticket is an
indicator that the ticket holder has already paid for or is
otherwise entitled to some specified right, product or service. In the present invention, a "digital ticket" is used to
enable the ticket holder to exercise usage rights specifying
the requirement of the digital ticket. Usage rights are used to
define how a digital work may be used or distributed.
Specific instances of usage rights are used to indicate a
particular manner of use or distribution. A usage right may
specifY a digital ticket which must be present before the right
may be exercised. For example, a digital ticket may be
specified in a Copy right of a digital work, so that exercise
of the Copy right requires the party that desires a copy of the
digital work be in possession of the necessary digital ticket.
55
60
65
FIG. 1 is a flowchart illustrating a simple instantiation of
the operation of the currently preferred embodiment of the
present invention.
FIG. 2 is a block diagram illustrating the various repository types and the repository transaction flow between them
in the currently preferred embodiment of the present invention.
FIG. 3 is a block diagram of a repository coupled with a
credit server in the currently preferred embodiment of the
present invention.
FIGS. 4a and 4b are examples of rendering systems as
may be utilized in the currently preferred embodiment of the
present invention.
FIG. 5 illustrates a contents file layout for a digital work
as may be utilized in the currently preferred embodiment of
the present invention.
FIG. 6 illustrates a contents file layout for an individual
digital work of the digital work of FIG. 5 as may be utilized
in the currently preferred embodiment of the present invention.
FIG. 7 illustrates the components of a description block of
the currently preferred embodiment of the present invention.
FIG. 8 illustrates a description tree for the contents file
layout of the digital work illustrated in FIG. 5.
FIG. 9 illustrates a portion of a description tree corresponding to the individual digital work illustrated in FIG. 6.
FIG. 10 illustrates a layout for the rights portion of a
description block as may be utilized in the currently preferred embodiment of the present invention.
FIG. 11 is a description tree wherein certain d-blocks have
PRINT usage rights and is used to illustrate "strict" and
"lenient" rules for resolving usage rights conflicts.
FIG. 12 is a block diagram of the hardware components
of a repository as are utilized in the currently preferred
embodiment of the present invention.
Case 2:13-cv-01112 Document 1-7 Filed 12/18/13 Page 20 of 45 PageID #: 247
US 7,269,576 B2
5
6
FIG. 13 is a block diagram of the functional (logical)
components of a repository as are utilized in the currently
-continued
preferred embodiment of the present invention.
TABLE OF CONTENTS
FIG. 14 is diagram illustrating the basic components of a
usage right in the currently preferred embodiment of the
Page No.
present invention.
The Install Transaction
99
FIG. 15 lists the usage rights grammar of the currently
The Uninstall Transaction
101
preferred embodiment of the present invention.
DISTRIBUTION AND USE SCENARIOS
103
FIG. 16 is a flowchart illustrating the steps of certificate
APPENDIX A GLOSSARY
120
delivery, hotlist checking and performance testing as per- 10
formed in a registration transaction as may be performed in
Overview
the currently preferred embodiment of the present invention.
A system for controlling use and distribution of digital
FIG. 17 is a flowchart illustrating the steps of session
works is disclosed. The present invention is directed to
information exchange and clock synchronization as may be
performed in the currently preferred embodiment of the 15 supporting commercial transactions involving digital works.
The transition to digital works profoundly and fundamenpresent invention, after each repository in the registration
tally changes how creativity and commerce can work. It
transaction has successfully completed the steps described in
changes the cost of transporting or storing works because
FIG. 16.
digital property is almost "massless." Digital property can
FIG. 18 is a flowchart illustrating the basic flow for a
usage transaction, including the common opening and clos- 20 be transported at electronic speeds and requires almost no
warehousing. Keeping an unlimited supply of virtual copies
ing step, as may be performed in the currently preferred
on hand requires essentially no more space than keeping one
embodiment of the present invention.
copy on hand. The digital medium also lowers the costs of
FIG. 19 is a state diagram of server and client repositories
alteration, reuse and billing.
in accordance with a transport protocol followed when
There is a market for digital works because creators are
moving a digital work from the server to the client reposi- 25
strongly motivated to reuse portions of digital works from
tories, as may be performed in the currently preferred
others rather than creating their own completely. This is
embodiment of the present invention.
because it is usually so much easier to use an existing stock
photo or music clip than to create a new one from scratch.
DETAILED DESCRIPTION OF THE
Herein the terms "digital work", "work" and "content"
30
PREFERRED EMBODIMENT
refer to any work that has been reduced to a digital representation. This would include any audio, video, text, or
multimedia work and any accompanying interpreter (e.g.
software) that may be required for recreating the work. The
TABLE OF CONTENTS
35 term composite work refers to a digital work comprised of
a collection of other digital works. The term "usage rights"
Page No.
or "rights" is a term which refers to rights granted to a
15
OVERVIEW
recipient of a digital work. Generally, these rights define
RENDERING SYSTEMS
19
how a digital work can be used and if it can be further
STRUCTURE OF DIGITAL WORKS
21
40 distributed. Each usage right may have one or more specified
ATTACHING USAGE RIGHTS TO A DIGITAL WORK
26
conditions which must be satisfied before the right may be
Resolving Conflicting Rights
27
28
REPOSITORIES
exercised. Appendix 1 provides a Glossary of the terms used
Repository Security Classes
35
herein.
Repository User Interface
37
A key feature of the present invention is that usage rights
38
CREDIT SERVERS
45 are permanently "attached" to the digital work. Copies made
USAGE RIGHTS LANGUAGE
40
Copy Count Specification
48
of a digital work will also have usage rights attached. Thus,
Control Specification
48
the usage rights and any associated fees assigned by a
49
Time Specification
creator and subsequent distributor will always remain with
Security Class and Authorization Specification
51
a digital work.
Usage Fees and Incentives Specification
54
Examples of Sets of Usage Rights
58
The enforcement elements of the present invention are
50
REPOSITORY TRANSACTIONS
61
embodied in repositories. Among other things, repositories
Message Transmission
62
are used to store digital works, control access to digital
Session Initiation Transactions
63
works, bill for access to digital works and maintain the
Billing Transactions
69
Usage Transactions
71
security and integrity of the system.
Transmission Prot col
76
55
The combination of attached usage rights and repositories
The Copy Transaction
80
enable distinct advantages over prior systems. As noted in
The Transfer Transaction
81
the prior art, payment of fees are primarily for the initial
The Loan Transaction
82
The Play Transaction
85
access. In such approaches, once a work has been read,
86
The Print Transaction
computational control over that copy is gone. Metaphori88
The Backup Transaction
60 cally, "the content genie is out of the bottle and no more fees
89
The Restore Transaction
can be billed." In contrast, the present invention never
The Delete Transaction
91
91
The Directory Transaction
separates the fee descriptions from the work. Thus, the
The Folder Transaction
92
digital work genie only moves from one trusted bottle
The Extract Transaction
93
(repository) to another, and all uses of copies are potentially
The Embed Transaction
94
65 controlled and billable.
The Edit Transaction
95
97
The Authorization Transaction
FIG. 1 is a high level flowchart omitting various details
but which demonstrates the basic operation of the present
Case 2:13-cv-01112 Document 1-7 Filed 12/18/13 Page 21 of 45 PageID #: 248
US 7,269,576 B2
7
8
invention. Referring to FIG. 1, a creator creates a digital
work, step 101. The creator will then determine appropriate
usage rights and fees, attach them to the digital work, and
store them in Repository 1, step 102. The determination of
appropriate usage rights and fees will depend on various
economic factors. The digital work remains securely in
Repository 1 until a request for access is received. The
request for access begins with a session initiation by another
repository. Here a Repository 2 initiates a session with
Repository 1, step 103. As will be described in greater detail
below, this session initiation includes steps which helps to
insure that the respective repositories are trustworthy.
Assuming that a session can be established, Repository 2
may then request access to the Digital Work for a stated
purpose, step 104. The purpose may be, for example, to print
the digital work or to obtain a copy of the digital work. The
purpose will correspond to a specific usage right. In any
event, Repository 1 checks the usage rights associated with
the digital work to determine if the access to the digital work
may be granted, step 105. The check of the usage rights
essentially involves a determination of whether a right
associated with the access request has been attached to the
digital work and if all conditions associated with the right
are satisfied. If the access is denied, repository 1 terminates
the session with an error message, step 106. If access is
granted, repository 1 transmits the digital work to repository
2, step 107. Once the digital work has been transmitted to
repository 2, repository 1 and 2 each generate billing information for the access which is transmitted to a credit server,
step 108. Such double billing reporting is done to insure
against attempts to circumvent the billing process.
FIG. 2 illustrates the basic interactions between repository
types in the present invention. As will become apparent from
FIG. 2, the various repository types will serve different
functions. It is fundamental that repositories will share a
core set of functionality which will enable secure and trusted
communications. Referring to FIG. 2, a repository 201
represents the general instance of a repository. The repository 201 has two modes of operation; a server mode and a
requester mode. When in the server mode, the repository
will be receiving and processing access requests to digital
works. When in the requester mode, the repository will be
initiating requests to access digital works. Repository 201 is
general in the sense that it's primary purpose is as an
exchange medium for digital works. During the course of
operation, the repository 201 may communicate with a
plurality of other repositories, namely authorization repository 202, rendering repository 203 and master repository
204. Communication between repositories occurs utilizing a
repository transaction protocol 205.
Communication with an authorization repository 202 may
occur when a digital work being accessed has a condition
requiring an authorization. Conceptually, an authorization is
a digital certificate such that possession of the certificate is
required to gain access to the digital work. An authorization
is itself a digital work that can be moved between repositories and subjected to fees and usage rights conditions. An
authorization may be required by both repositories involved
in an access to a digital work.
Communication with a rendering repository 203 occurs in
connection with the rendering of a digital work. As will be
described in greater detail below, a rendering repository is
coupled with a rendering device (e.g. a printer device) to
comprise a rendering system.
Communication with a master repository 205 occurs in
connection with obtaining an identification certificate. Identification certificates are the means by which a repository is
identified as "trustworthy". The use of identification certificates is described below with respect to the registration
transaction.
FIG. 3 illustrates the repository 201 coupled to a credit
server 301. The credit server 301 is a device which accumulates billing information for the repository 201. The
credit server 301 communicates with repository 201 via
billing transactions 302 to record billing transactions. Billing transactions are reported to a billing clearinghouse 303
by the credit server 301 on a periodic basis. The credit server
301 communicates to the billing clearinghouse 303 via
clearinghouse transactions 304. The clearinghouse transactions 304 enable a secure and encrypted transmission of
information to the billing clearinghouse 303.
10
15
20
25
30
35
40
45
50
55
60
65
Rendering Systems
A rendering system is generally defined as a system
comprising a repository and a rendering device which can
render a digital work into its desired form. Examples of a
rendering system may be a computer system, a digital audio
system, or a printer. A rendering system has the same
security features as a repository. The coupling of a rendering
repository with the rendering device may occur in a manner
suitable for the type of rendering device.
FIG. 4a illustrates a printer as an example of a rendering
system. Referring to FIG. 4, printer system 401 has contained therein a printer repository 402 and a print device
403. It should be noted that the the dashed line defining
printer system 401 defines a secure system boundary. Communications within the boundary is assumed to be secure.
Depending on the security level, the boundary also represents a barrier intended to provide physical integrity. The
printer repository 402 is an instantiation of the rendering
repository 205 of FIG. 2. The printer repository 402 will in
some instances contain an ephemeral copy of a digital work
which remains until it is printed out by the print engine 403.
In other instances, the printer repository 402 may contain
digital works such as fonts, which will remain and can be
billed based on use. This design assures that all communication lines between printers and printing devices are
encrypted, unless they are within a physically secure boundary. This design feature eliminates a potential "fault" point
through which the digital work could be improperly
obtained. The printer device 403 represents the printer
components used to create the printed output.
Also illustrated in FIG. 4a is the repository 404. The
repository 404 is coupled to the printer repository 402. The
repository 404 represents an external repository which contains digital works.
FIG. 4b is an example of a computer system as a rendering
system. A computer system may constitute a "multi-function" device since it may execute digital works (e.g. software programs) and display digital works (e.g. a digitized
photograph). Logically, each rendering device can be
viewed as having it's own repository, although only one
physical repository is needed. Referring to FIG. 4b, a
computer system 410 has contained therein a display/execution repository 411. The display/execution repository 411 is
coupled to display device, 412 and execution device 413.
The dashed box surrounding the computer system 410
represents a security boundary within which communications are assumed to be secure. The display/execution
repository 411 is further coupled to a credit server 414 to
report any fees to be billed for access to a digital work and
a repository 415 for accessing digital works stored therein.
Case 2:13-cv-01112 Document 1-7 Filed 12/18/13 Page 22 of 45 PageID #: 249
US 7,269,576 B2
9
10
Structure of Digital Works
Usage rights are attached directly to digital works. Thus,
it is important to understand the structure of a digital work.
The structure of a digital work, in particular composite
digital works, may be naturally organized into an acyclic
structure such as a hierarchy. For example, a magazine has
various articles and photographs which may have been
created and are owned by different persons. Each of the
articles and photographs may represent a node in a hierarchical structure. Consequently, controls, i.e. usage rights,
may be placed on each node by the creator. By enabling
control and fee billing to be associated with each node, a
creator of a work can be assured that the rights and fees are
not circumvented.
In the currently preferred embodiment, the file information for a digital work is divided into two files: a "contents"
file and a "description tree" file. From the perspective of a
repository, the "contents" file is a stream of addressable
bytes whose format depends completely on the interpreter
used to play, display or print the digital work. The description tree file makes it possible to examine the rights and fees
for a work without reference to the content of the digital
work. It should be noted that the term description tree as
used herein refers to any type of acyclic structure used to
represent the relationship between the various components
of a digital work.
FIG. 5 illustrates the layout of a contents file. Referring to
FIG. 5, a digital work 509 is comprised of story A 510,
advertisement 511, story B 512 and story C 513. It is
assumed that the digital work is stored starting at a relative
address ofO. Each of the parts of the digital work are stored
linearly so that story A 510 is stored at approximately
addresses 0-30,000, advertisement 511 at addresses 30,00140,000, story B 512 at addresses 40,001-60,000 and story C
513 at addresses 60,001-85K. The detail of story A 510 is
illustrated in FIG. 6. Referring to FIG. 6, the story A 510 is
further broken down to show text 614 stored at address
0-1500, soldier photo 615 at addresses 1501-10,000, graphics 616 stored at addresses 10,001-25,000 and sidebar 617
stored address 25,001-30,000. Note that the data in the
contents file may be compressed (for saving storage) or
encrypted (for security).
From FIGS. 5 and 6 it is readily observed that a digital
work can be represented by its component parts as a hierarchy. The description tree for a digital work is comprised of
a set of related descriptor blocks (d-blocks). The contents of
each d-block is described with respect to FIG. 7. Referring
to FIG. 7, a d-block 700 includes an identifier 701 which is
a unique identifier for the work in the repository, a starting
address 702 providing the start address of the first byte of the
work, a length 703 giving the number of bytes in the work,
a rights portion 704 wherein the granted usage rights and
their status data are maintained, a parent pointer 705 for
pointing to a parent d-block and child pointers 706 for
pointing to the child d-blocks In the currently preferred
embodiment, the identifier 701 has two parts. The first part
is a unique number assigned to the repository upon manufacture. The second part is a unique number assigned to the
work upon creation. The rights portion 704 will contain a
data structure, such as a look-up table, wherein the various
information associated with a right is maintained. The
information required by the respective usage rights is
described in more detail below. D-blocks form a strict
hierarchy. The top d-block of a work has no parent; all other
d-blocks have one parent. The relationship of usage rights
between parent and child d-blocks and how conflicts are
resolved is described below.
A special type of d-block is a "shell" d-block. A shell
d-block adds no new content beyond the content of its parts.
A shell d-block is used to add rights and fee information,
typically by distributors of digital works.
FIG. 8 illustrates a description tree for the digital work of
FIG. 5. Referring to FIG. 8, a top d-block 820 for the digital
work points to the various stories and advertisements contained therein. Here, the top d-block 820 points to d-block
821 (representing story A 510), d-block 822 (representing
the advertisement 511), d-block 823 (representing story B
512) and and d-block 824 (representing story C 513).
The portion of the description tree for Story A 510 is
illustrated in FIG. 9. D-block 925 represents text 614,
d-block 926 represents photo 615, d-block 927 represents
graphics 616 by and d-block 928 represents sidebar 617.
The rights portion 704 of a descriptor block is further
illustrated in FIG. 10. FIG. 10 illustrates a structure which
is repeated in the rights portion 704 for each right. Referring
to FIG. 10, each right will have a right code field 1001 and
status information field 1002. The right code field 1001 will
contain a unique code assigned to a right. The status
information field 1002 will contain information relating to
the state of a right and the digital work. Such information is
indicated below in Table 1. The rights as stored in the rights
portion 304 may typically be in numerical order based on the
right code.
The approach for representing digital works by separating
description data from content assumes that parts of a file are
contiguous but takes no position on the actual representation
of content. In particular, it is neutral to the question of
whether content representation may take an object oriented
approach. It would be natural to represent content as objects.
In principle, it may be convenient to have content objects
that include the billing structure and rights information that
is represented in the d-blocks. Such variations in the design
of the representation are possible and are
10
15
20
25
30
35
TABLE 1
40
DIGITAL WORK STATE INFORMATION
Property
Copies-in45 Use
Loan-Period
Value
Use
Number
A cmmter of the number of copies of a
work that are in use. Incremented when
another copy is used; decremented when
use is completed.
Indicator of the maximum number of
time-nnits that a document can be
loaned out
Indicator that the current work is a
loaned out copy of an authorized digital
work.
Indicator of the remaining time of use
on a metered document right.
A string containing various identifYing
information about a document. The
exact format of this is not specified, but
it can include information such as a
publisher name, author name, ISBN
nwnber, and so on.
A handle identifying a revenue owner
for a digital work. This is used for
reporting usage fees.
The date tbat tbe digital work was
published.
A list of events recording the repostories
and dates for operations that copy,
transfer, backup, or restore a digital
work.
Time-Units
50 Loaner-Copy Boolean
RemainingTime
Document55 Descr
60
65
Time-Units
String
RevenueOwner
RO-Descr
PublicationDate
History-list
Date-Descr
History-Rec
Case 2:13-cv-01112 Document 1-7 Filed 12/18/13 Page 23 of 45 PageID #: 250
US 7,269,576 B2
11
12
viable alternatives but may introduce processing overhead,
e.g. the interpretation of the objects.
Digital works are stored in a repository as part of a
hierarchical file system. Folders (also termed directories and
sub-directories) contain the digital works as well as other
folders. Digital works and folders in a folder are ordered in
alphabetical order. The digital works are typed to reflect how
the files are used. Usage rights can be attached to folders so
that the folder itself is treated as a digital work. Access to the
folder would then be handled in the same fashion as any
other digital work As will be described in more detail below,
the contents of the folder are subject to their own rights.
Moreover, file management rights may be attached to the
folder which define how folder contents can be managed.
and child d-blocks 1102 and 1105 have been granted PRINT
rights. Child d-block 1103 has not been granted PRINT
rights and child d-block 1104 has PRINT rights conditioned
on payment of a usage fee.
Under the strict rule the PRINT right cannot be exercised
because the child d-block does not have the PRINT right.
Under the lenient rule, the result would be different. The
digital works represented by child d-blocks 1102 and 1105
could be printed and the digital work represented by d-block
1104 could be printed so long as the usage fee is paid. Only
the digital work represented by d-block 1103 could not be
printed. This same result would be accomplished nnder the
strict rule if the requests were directed to each of the
individual digital works.
The present invention supports various combinations of
allowing and disallowing access. Moreover, as will be
described below, the usage rights grammar permits the
owner of a digital work to specify if constraints may be
imposed on the work by a container part. The manner in
which digital works may be sanctioned because of usage
rights conflicts would be implementation specific and would
depend on the nature of the digital works.
Attaching Usage Rights to a Digital Work
It is fundamental to the present invention that the usage
rights are treated as part of the digital work. As the digital
work is distributed, the scope of the granted usage rights will
remain the same or may be narrowed. For example, when a
digital work is transferred from a document server to a
repository, the usage rights may include the right to loan a
copy for a predetermined period of time (called the original
rights). When the repository loans out a copy of the digital
work, the usage rights in the loaner copy (called the next set
of rights) could be set to prohibit any further rights to loan
out the copy. The basic idea is that one cannot grant more
rights than they have.
The attachment of usage rights into a digital work may
occur in a variety of ways. If the usage rights will be the
same for an entire digital work, they could be attached when
the digital work is processed for deposit in the digital work
server. In the case of a digital work having different usage
rights for the various components, this can be done as the
digital work is being created. An authoring tool or digital
work assembling tool could be utilized which provides for
an automated process of attaching the usage rights.
As will be described below, when a digital work is copied,
transferred or loaned, a "next set of rights" can be specified.
The "next set of rights" will be attached to the digital work
as it is transported.
Resolving Conflicting Rights
Because each part of a digital work may have its own
usage rights, there will be instances where the rights of a
"contained part" are different from its parent or container
part. As a result, conflict rules must be established to dictate
when and how a right may be exercised. The hierarchical
structure of a digital work facilitates the enforcement of such
rules. A "strict" rule would be as follows: a right for a part
in a digital work is sanctioned if and only if it is sanctioned
for the part, for ancestor d-blocks containing the part and for
all descendent d-blocks. By sanctioned, it is meant that (1)
each of the respective parts must have the right, and (2) any
conditions for exercising the right are satisfied.
It also possible to implement the present invention using
a more lenient rule. In the more lenient rule, access to the
part may be enabled to the descendent parts which have the
right, but access is denied to the descendents which do not.
Example of applying both the strict rule and lenient is
illustrated with reference to FIG. 11. Referring to FIG. 11, a
root d-block 1101 has child d-blocks 1102-1105. In this case,
root d-block represents a magazine, and each of the child
d-blocks 1102-1105 represent articles in the magazine. Suppose that a request is made to PRINT the digital work
represented by root d-block 1101 wherein the strict rule is
followed. The rights for the root d-block 1101 and child
d-blocks 1102-1105 are then examined. Root d-block 1101
10
15
20
25
30
35
40
45
50
55
60
65
Repositories
Many of the powerful functions of repositories-such as
their ability to "loan" digital works or automatically handle
the commercial reuse of digital works-are possible because
they are trusted systems. The systems are trusted because
they are able to take responsibility for fairly and reliably
carrying out the commercial transactions. That the systems
can be responsible ("able to respond") is fundamentally an
issue of integrity. The integrity of repositories has three
parts: physical integrity, communications integrity, and
behavioral integrity.
Physical integrity refers to the integrity of the physical
devices themselves. Physical integrity applies both to the
repositories and to the protected digital works. Thus, the
higher security classes of repositories themselves may have
sensors that detect when tampering is attempted on their
secure cases. In addition to protection of the repository
itself, the repository design protects access to the content of
digital works. In contrast with the design of conventional
magnetic and optical devices-such as floppy disks, CDROMs, and videotapes-repositories never allow nontrusted systems to access the works directly. A maker of
generic computer systems cannot guarantee that their platform will not be used to make unauthorized copies. The
manufacturer provides generic capabilities for reading and
writing information, and the general nature of the functionality of the general computing device depends on it. Thus, a
copy program can copy arbitrary data. This copying issue is
not limited to general purpose computers. It also arises for
the unauthorized duplication of entertainment "software"
such as video and audio recordings by magnetic recorders.
Again, the functionality of the recorders depends on their
ability to copy and they have no means to check whether a
copy is authorized. In contrast, repositories prevent access to
the raw data by general devices and can test explicit rights
and conditions before copying or otherwise granting access.
Information is only accessed by protocol between trusted
repositories.
Communications integrity refers to the integrity of the
communications channels between repositories. Roughly
speaking, communications integrity means that repositories
cannot be easily fooled by "telling them lies." Integrity in
this case refers to the property that repositories will only
communicate with other devices that are able to present
Case 2:13-cv-01112 Document 1-7 Filed 12/18/13 Page 24 of 45 PageID #: 251
US 7,269,576 B2
13
14
proof that they are certified repositories, and furthermore,
that the repositories monitor the communications to detect
"impostors" and malicious or accidental interference. Thus
the security measures involving encryption, exchange of
digital certificates, and nonces described below are all
security measures aimed at reliable communication in a
world known to contain active adversaries.
Behavioral integrity refers to the integrity in what repositories do. What repositories do is determined by the software
that they execute. The integrity of the software is generally
assured only by knowledge of its source. Restated, a user
will trust software purchased at a reputable computer store
but not trust software obtained off a random (insecure)
server on a network. Behavioral integrity is maintained by
requiring that repository software be certified and be distributed with proof of such certification, i.e. a digital certificate. The purpose of the certificate is to authenticate that
the software has been tested by an authorized organization,
which attests that the software does what it is supposed to do
and that it does not compromise the behavioral integrity of
a repository. If the digital certificate cannot be found in the
digital work or the master repository which generated the
certificate is not known to the repository receiving the
software, then the software cannot be installed.
In the description of FIG. 2, it was indicated that repositories come in various forms. All repositories provide a core
set of services for the transmission of digital works. The
manner in which digital works are exchanged is the basis for
all transaction between repositories. The various repository
types differ in the ultimate functions that they perform.
Repositories may be devices themselves, or they may be
incorporated into other systems. An example is the rendering
repository 205 of FIG. 2.
A repository will have associated with it a repository
identifier. Typically, the repository identifier would be a
unique number assigned to the repository at the time of
manufacture. Each repository will also be classified as being
in a particular security class. Certain communications and
transactions may be conditioned on a repository being in a
particular security class. The various security classes are
described in greater detail below.
As a prerequisite to operation, a repository will require
possession of an identification certificate. Identification certificates are encrypted to prevent forgery and are issued by
a Master repository. A master repository plays the role of an
authorization agent to enable repositories to receive digital
works. Identification certificates must be updated on a
periodic basis. Identification certificates are described in
greater detail below with respect to the registration transaction.
A repository has both a hardware and functional embodiment. The functional embodiment is typically software
executing on the hardware embodiment. Alternatively, the
functional embodiment may be embedded in the hardware
embodiment such as an Application Specific Integrated
Circuit (ASIC) chip.
The hardware embodiment of a repository will be
enclosed in a secure housing which if compromised, may
cause the repository to be disabled. The basic components of
the hardware embodiment of a repository are described with
reference to FIG. 12. Referring to FIG. 12, a repository is
comprised of a processing means 1200, storage system
1207, clock 1205 and external interface 1206. The processing means 1200 is comprised of a processor element 1201
and processor memory 1202. The processing means 1201
provides controller, repository transaction and usage rights
transaction functions for the repository. Various functions in
the operation of the repository such as decryption and/or
decompression of digital works and transaction messages
are also performed by the processing means 1200. The
processor element 1201 may be a microprocessor or other
suitable computing component. The processor memory 1202
would typically be further comprised of Read Only Memories (ROM) and Random Access Memories (RAM). Such
memories would contain the software instructions utilized
by the processor element 1201 in performing the functions
of the repository.
The storage system 1207 is further comprised of descriptor storage 1203 and content storage 1204. The description
tree storage 1203 will store the description tree for the digital
work and the content storage will store the associated
content. The description tree storage 1203 and content
storage 1204 need not be of the same type of storage
medium, nor are they necessarily on the same physical
device. So for example, the descriptor storage 1203 may be
stored on a solid state storage (for rapid retrieval of the
description tree information), while the content storage 1204
may be on a high capacity storage such as an optical disk.
The clock 1205 is used to time-stamp various time based
conditions for usage rights or for metering usage fees which
may be associated with the digital works. The clock 1205
will have an uninterruptable power supply, e.g. a battery, in
order to maintain the integrity of the time-stamps. The
external interface means 1206 provides for the signal connection to other repositories and to a credit server. The
external interface means 1206 provides for the exchange of
signals via such standard interfaces such as RS-232 or
Personal Computer Manufacturers Card Industry Association (PCMCIA) standards, or FDDI. The external interface
means 1206 may also provide network connectivity.
The functional embodiment of a repository is described
with reference to FIG. 13. Referring to FIG. 13, the functional embodiment is comprised of an operating system
1301, core repository services 1302, usage transaction handlers 1303, repository specific functions, 1304 and a user
interface 1305. The operating system 1301 is specific to the
repository and would typically depend on the type of processor being used. The operating system 1301 would also
provide the basic services for controlling and interfacing
between the basic components of the repository.
The core repository services 1302 comprise a set of
functions required by each and every repository. The core
repository services 1302 include the session initiation transactions which are defined in greater detail below. This set of
services also includes a generic ticket agent which is used to
"punch" a digital ticket and a generic authorization server
for processing authorization specifications. Digital tickets
and authorizations are specific mechanisms for controlling
the distribution and use of digital works and are described
and more detail below. Note that coupled to the core
repository services are a plurality of identification certificates 1306. The identification certificates 1306 are required
to enable the use of the repository.
The usage transactions handler 1303 comprise functionality for processing access requests to digital works and for
billing fees based on access. The usage transactions supported will be different for each repository type. For
example, it may not be necessary for some repositories to
handle access requests for digital works.
The repository specific functionality 1304 comprises
functionality that is unique to a repository. For example, the
master repository has special functionality for issuing digital
certificates and maintaining encryption keys. The repository
10
15
20
25
30
35
40
45
50
55
60
65
Case 2:13-cv-01112 Document 1-7 Filed 12/18/13 Page 25 of 45 PageID #: 252
US 7,269,576 B2
15
16
specific functionality 1304 would include the user interface
implementation for the repository.
TABLE 2-continued
REPOSITORY SECURITY LEVELS
Repository Security Classes
For some digital works the losses caused by any indiLevel Description of Security
vidual instance of unauthorized copying is insignificant and
Like the previous class except that the repository will attempt
the chief economic concern lies in assuring the convenience
wireless communication to report tampering and will employ noisy
of access and low-overhead billing. In such cases, simple
alarms.
10 This would correspond to a very high level of security. This server
and inexpensive handheld repositories and network-based
would maintain constant commnnications to remote security
workstations may be suitable repositories, even though the 10
systems reporting transactions, sensor readings, and attempts to
measures and guarantees of security are modest.
circwnvent security.
At the other extreme, some digital works such as a digital
copy of a first run movie or a bearer bond or stock certificate
The characterization of security levels described in Table
would be of very high value so that it is prudent to employ 15 2 is not intended to be fixed. More important is the idea of
caution and fairly elaborate security measures to ensure that
having different security levels for different repositories. It is
they are not copied or forged. A repository suitable for
anticipated that new security classes and requirements will
holding such a digital work could have elaborate measures
evolve according to social situations and changes in techfor ensuring physical integrity and for verifying authorizanology.
tion before use.
20
Repository User Interface
By arranging a universal protocol, all kinds of repositories
A user interface is broadly defined as the mechanism by
can communicate with each other in principle. However,
which a user interacts with a repository in order to invoke
creators of some works will want to specifY that their works
transactions to gain access to a digital work, or exercise
will only be transferred to repositories whose level of
usage rights. As described above, a repository may be
security is high enough. For this reason, document reposi- 25
embodied in various forms. The user interface for a repositories have a ranking system for classes and levels of
tory will differ depending on the particular embodiment. The
security. The security classes in the currently preferred
user interface may be a graphical user interface having icons
embodiment are described in Table 2.
representing the digital works and the various transactions
that may be performed. The user interface may be a gener30
TABLE 2
ated dialog in which a user is prompted for information.
The user interface itself need not be part of the repository.
REPOSITORY SECURITY LEVELS
As a repository may be embedded in some other device, the
Level Description of Security
user interface may merely be a part of the device in which
the repository is embedded. For example, the repository
0 Open system. Document transmission is nnencrypted. No digital
35
could be embedded in a "card" that is inserted into an
certificate is required for identification. The security of the system
depends mostly on user honesty, since only modest knowledge may
available slot in a computer system. The user interface may
be needed to circwnvent the security measures. The repository
be combination of a display, keyboard, cursor control device
has no provisions for preventing unauthorized programs from
and software executing on the computer system.
running and accessing or copying files. The system does not
At a minimum, the user interface must permit a user to
prevent the use of removable storage and does not encrypt stored
40
files.
input information such as access requests and alpha numeric
Minimal security. Like the previous class except that stored files
data and provide feedback as to transaction status. The user
are minimally encrypted, including ones on removable storage.
interface will then cause the repository to initiate the suitable
2 Basic secmity. Like the previous class except that special tools
transactions to service the request. Other facets of a particuand knowledge are required to compromise the programming, the
contents of the repository, or the state of the clock. All digital
45 lar user interface will depend on the functionality that a
communications are encrypted. A digital certificate is provided as
repository will provide.
4
identification. Medium level encryption is used. Repository
identification number is unforgeable.
General security. Like the previous class plus the requirement of
special tools are needed to compromise the physical integrity of the
repository and that modest encryption is used on all transmissions.
Password protection is required to use the local user interface. The
digital clock system cannot be reset without authorization. No
works would be stored on removable storage. When executing
works as programs, it nms them in their own address space and
does not give them direct access to any file storage or other
memory containing system code or works. They can access works
only through the transmission transaction protocol.
Like the previous class except that high level encryption is used on
all commnnications. Sensors are used to record attempts at
physical and electronic tampering. After such tampering, the
repository will not perform other transactions nntil it has reported
such tampering to a designated server.
Like the previous class except that if the physical or digital
attempts at tampering exceed some preset thresholds that
threaten the physical integrity of the repository or the integrity of
digital and cryptographic barriers, then the repository will save
only docwnent description records of history but will erase or
destroy any digital identifiers that could be misused if released to
an unscrupulous party. It also modifies any certificates of
authenticity to indicate that the physical system has been
compromised. It also erases the contents of designated docwnents.
50
55
60
65
Credit Servers
In the present invention, fees may be associated with the
exercise of a right. The requirement for payment of fees is
described with each version of a usage right in the usage
rights language. The recording and reporting of such fees is
performed by the credit server. One of the capabilities
enabled by associating fees with rights is the possibility of
supporting a wide range of charging models. The simplest
model, used by conventional software, is that there is a
single fee at the time of purchase, after which the purchaser
obtains unlimited rights to use the work as often and for as
long as he or she wants. Alternative models, include metered
use and variable fees. A single work can have different fees
for different uses. For example, viewing a photograph on a
display could have different fees than making a hardcopy or
including it in a newly created work. A key to these
alternative charging models is to have a low overhead means
of establishing fees and accounting for credit on these
transactions.
A credit server is a computational system that reliably
authorizes and records these transactions so that fees are
Case 2:13-cv-01112 Document 1-7 Filed 12/18/13 Page 26 of 45 PageID #: 253
US 7,269,576 B2
17
18
billed and paid. The credit server reports fees to a billing
clearinghouse. The billing clearinghouse manages the financial transactions as they occur. As a result, bills may be
generated and accounts reconciled. Preferably, the credit
server would store the fee transactions and periodically
communicate via a network with billing clearinghouse for
reconciliation. In such an embodiment, communications
with the billing clearinghouse would be encrypted for integrity and security reasons. In another embodiment, the credit
server acts as a "debit card" where transactions occur in
"real-time" against a user account.
A credit server is comprised of memory, a processing
means, a clock, and interface means for coupling to a
repository and a financial institution (e.g. a modem). The
credit server will also need to have security and authentication functionality. These elements are essentially the same
elements as those of a repository. Thus, a single device can
be both a repository and a credit server, provided that it has
the appropriate processing elements for carrying out the
corresponding functions and protocols. Typically, however,
a credit server would be a card-sized system in the possession of the owner of the credit. The credit server is coupled
to a repository and would interact via financial transactions
as described below. Interactions with a financial institution
may occur via protocols established by the financial institutions themselves.
In the currently preferred embodiment credit servers
associated with both the server and the repository report the
financial transaction to the billing clearinghouse. For
example, when a digital work is copied by one repository to
another for a fee, credit servers coupled to each of the
repositories will report the transaction to the billing clearinghouse. This is desirable in that it insures that a transaction
will be accounted for in the event of some break in the
communication between a credit server and the billing
clearinghouse. However, some implementations may
embody only a single credit server reporting the transaction
to minimize transaction processing at the risk of losing some
transactions.
The basic contents of a right are illustrated in FIG. 14.
Referring to FIG. 14, a right 145 has a transactional component 1451 and a specifications component 1452. A right
1450 has a label (e.g. COPY or PRINT) which indicate the
use or distribution privileges that are embodied by the right.
The transactional component 1451 corresponds to a particular way in which a digital work may be used or distributed.
The transactional component 1451 is typically embodied in
software instructions in a repository which implement the
use or distribution privileges for the right. The specifications
components 1452 are used to specify conditions which must
be satisfied prior to the right being exercised or to designate
various transaction related parameters. In the currently preferred embodiment, these specifications include copy count
1453, Fees and Incentives 1454, Time 1455, Access and
Security 1456 and Control 1457. Each of these specifications will be described in greater detail below with respect
to the language grammar elements.
The usage rights language is based on the grammar
described below. A grammar is a convenient means for
defining valid sequence of symbols for a language. In
describing the grammar the notation "[albic]" is used to
indicate distinct choices among alternatives. In this example,
a sentence can have either an "a", "b" or "C". It must include
exactly one of them. The braces { } are used to indicate
optional items. Note that brackets, bars and braces are used
to describe the language of usage rights sentences but do not
appear in actual sentences in the language.
In contrast, parentheses are part of the usage rights
language. Parentheses are used to group items together in
lists. The notation (x*) is used to indicate a variable length
list, that is, a list containing one or more items of type x. The
notation (x)* is used to indicate a variable number of lists
containing x.
Keywords in the grammar are words followed by colons.
Keywords are a common and very special case in the
language. They are often used to indicate a single value,
typically an identifier. In many cases, the keyword and the
parameter are entirely optional. When a keyword is given, it
often takes a single identifier as its value. In some cases, the
keyword takes a list of identifiers.
In the usage rights language, time is specified in an
hours:minutes:seconds (or hh:mm:ss) representation. Time
zone indicators, e.g. PDT for Pacific Daylight Time, may
also be specified. Dates are represented as year/month/day
(or YYYY/MMM/DD). Note that these time and date representations may specifY moments in time or units of time
Money units are specified in terms of dollars.
Finally, in the usage rights language, various "things" will
need to interact with each other. For example, an instance of
a usage right may specify a bank account, a digital ticket,
etc. Such things need to be identified and are specified herein
using the suffix "-ID."
The Usage Rights Grammar is listed in it's entirety in
FIG. 15 and is described below.
Grammar element 1501 "Digital Work Rights:=
(Rights*)" define the digital work rights as a set of rights.
The set of rights attached to a digital work define how that
digital work may be transferred, used, performed or played.
A set of rights will attach to the entire digital work and in the
case of compound digital works, each of the components of
the digital work. The usage rights of components of a digital
may be different.
Grammar element 1502 "Right:=(Right-Code {CopyCount}{ Control-Spec }{Time-Spec}{ Access-Spec }{FeeSpec})" enumerates the content of a right. Each usage right
must specifY a right code. Each right may also optionally
10
15
20
25
30
35
40
Usage Rights Language
The present invention uses statements in a high level
"usage rights language" to define rights associated with
digital works and their parts. Usage rights statements are
interpreted by repositories and are used to determine what
transactions can be successfully carried out for a digital
work and also to determine parameters for those transactions. For example, sentences in the language determine
whether a given digital work can be copied, when and how
it can be used, and what fees (if any) are to be charged for
that use. Once the usage rights statements are generated,
they are encoded in a suitable form for accessing during the
processing of transactions.
Defining usage rights in terms of a language in combination with the hierarchical representation of a digital work
enables the support of a wide variety of distribution and fee
schemes. An example is the ability to attach multiple versions of a right to a work. So a creator may attach a PRINT
right to make 5 copies for $10.00 and a PRINT right to make
unlimited copies for $100.00. A purchaser may then choose
which option best fits his needs. Another example is that
rights and fees are additive. So in the case of a composite
work, the rights and fees of each of the components works
is used in determining the rights and fees for the work as a
whole. Other features and benefits of the usage rights
language will become apparent in the description of distribution and use scenarios provided below.
45
50
55
60
65
Case 2:13-cv-01112 Document 1-7 Filed 12/18/13 Page 27 of 45 PageID #: 254
US 7,269,576 B2
19
20
specifY conditions which must be satisfied before the right
can be exercised. These conditions are copy count, control,
time, access and fee conditions. In the currently preferred
embodiment, for the optional elements, the following
defaults apply: copy count equals 1, no time limit on the use
of the right, no access tests or a security level required to use
the right and no fee is required. These conditions will each
be described in greater detail below.
It is important to note that a digital work may have
multiple versions of a right, each having the same right code.
The multiple version would provide alternative conditions
and fees for accessing the digital work.
Grammar
element
1503
"Right-Code:=RenderCodeiTransport-CodeiFile-Management-CodeiDerivativeWorks-Code Configuration-Code" distinguishes each of the
specific rights into a particular right type (although each
right is identified by distinct right codes). In this way, the
grammar provides a catalog of possible rights that can be
associated with parts of digital works. In the following,
rights are divided into categories for convenience in describing them.
Grammar element 1504 "Render-Code:=[Play: {Player:
Player-ID}IPrint: {Printer: Printer-ID}]" lists a category of
rights all involving the making of ephemeral, transitory, or
non-digital copies of the digital work. After use the copies
are erased.
Play A process of rendering or performing a digital work
on some processor. This includes such things as playing
digital movies, playing digital music, playing a video
game, running a computer program, or displaying a
document on a display.
Print To render the work in a medium that is not further
protected by usage rights, such as printing on paper.
1505
"Transport-Code:=
Grammar
element
[CopyiTransferiLoan {Remaining-Rights: Next -Set -ofRights} l{ (Next-Copy-Rights: Next-Set of Rights)}" lists a
category of rights involving the making of persistent, usable
copies of the digital work on other repositories. The optional
Next-Copy-Rights determine the rights on the work after it
is transported. If this is not specified, then the rights on the
transported copy are the same as on the original. The
optional Remaining-Rights specify the rights that remain
with a digital work when it is loaned out. If this is not
specified, then the default is that no rights can be exercised
when it is loaned out.
Copy Make a new copy of a work
Transfer Moving a work from one repository to another.
Loan Temporarily loaning a copy to another repository for
a specified period of time.
Grammar element 1506 "File-Management-Code:
=Backup
{Back-Up-Copy-Rights:
Next-Set-of
Rights }IRestoreiDeleteiFolderiDirectory
{Name:HideLocaliHide-Remote} {Parts:Hide-LocaliHide-Remote}" lists
a category of rights involving operations for file management, such as the making of backup copies to protect the
copy owner against catastrophic equipment failure.
Many software licenses and also copyright law give a
copy owner the right to make backup copies to protect
against catastrophic failure of equipment. However, the
making of uncontrolled backup copies is inherently at odds
with the ability to control usage, since an uncontrolled
backup copy can be kept and then restored even after the
authorized copy was sold.
The File management rights enable the making and restoring of backup copies in a way that respects usage rights,
honoring the requirements of both the copy owner and the
rights grantor and revenue owner. Backup copies of work
descriptions (including usage rights and fee data) can be sent
under appropriate protocol and usage rights control to other
document repositories of sufficiently high security. Further
rights permit organization of digital works into folders
which themselves are treated as digital works and whose
contents may be "hidden" from a party seeking to determine
the contents of a repository.
Backup To make a backup copy of a digital work as
protection against media failure.
Restore To restore a backup copy of a digital work.
Delete To delete or erase a copy of a digital work.
Folder To create and name folders, and to move files and
folders between folders.
Directory To hide a folder or it's contents.
Grammar element 1507 "Derivative-Works-Code:
[ExtractiEmbediEdit {Process: Pr cess-ID}] {Next-CopyRights: Next-Set-of Rights}" lists a category of rights
involving the use of a digital work to create new works.
Extract To remove a portion of a work, for the purposes
of creating a new work.
Embed To include a work in an existing work.
Edit To alter a digital work by copying, selecting and
modifYing portions of an existing digital work.
1508
"Configuration-Code:
Grammar
element
=InstalliUninstall" lists a category of rights for installing and
uninstalling software on a repository (typically a rendering
repository.) This would typically occur for the installation of
a new type of player within the rendering repository.
Install: To install new software on a repository.
Uninstall: To remove existing software from a repository.
Grammar element 1509 "Next-Set-of-Rights:={ (Add:
Set-Of-Rights)}{ (Delete: Set-Of-Rights)}{ (Replace: SetOf-Rights)}{ (Keep: Set-Of-Rights)}" defines how rights are
carried forward for a copy of a digital work. If the NextCopy-Rights is not specified, the rights for the next copy are
the same as those of the current copy. Otherwise, the set of
rights for the next copy can be specified. Versions of rights
after Add: are added to the current set of rights. Rights after
Delete: are deleted from the current set of rights. If only right
codes are listed after Delete:, then all versions of rights with
those codes are deleted. Versions of rights after Replace:
subsume all versions of rights of the same type in the current
set of rights.
If Remaining-Rights is not specified, then there are no
rights for the original after all Loan copies are loaned out. If
Remaining-Rights is specified, then the Keep: token can be
used to simplify the expression of what rights to keep
behind. A list of right codes following keep means that all of
the versions of those listed rights are kept in the remaining
copy. This specification can be overridden by subsequent
Delete: or Replace: specifications.
5
10
15
20
25
30
35
40
45
50
55
60
65
Copy Count Specification
For various transactions, it may be desirable to provide
some limit as to the number of "copies" of the work which
may be exercised simultaneously for the right. For example,
it may be desirable to limit the number of copies of a digital
work that may be loaned out at a time or viewed at a time.
Grammar element 1510 "Copy-Count:=(Copies: positiveintegeriOiunlimited)" provides a condition which defines the
number of "copies" of a work subject to the right. A copy
count can be 0, a fixed number, or unlimited. The copy-count
is associated with each right, as opposed to there being just
a single copy-count for the digital work. The Copy-Count
for a right is decremented each time that a right is exercised.
Case 2:13-cv-01112 Document 1-7 Filed 12/18/13 Page 28 of 45 PageID #: 255
US 7,269,576 B2
21
22
When the Copy-Count equals zero, the right can no longer
be exercised. If the Copy-Count is not specified, the default
1s one.
differs from the Sliding-Interval specification in that the time
that the digital work is in use need not be continuous. For
example, if the rights guarantee three days of access, those
days could be spread out over a month. With this specification, the rights can be exercised until the meter time is
exhausted or the expiration date is reached, whichever
comes first.
Remaining-Use:=Time-Unit
Start-Time:=Time-Unit
Use-Duration:=Time-Unit
Control Specification
Rights and fees depend in general on rights granted by the
creator as well as further restrictions imposed by later
distributors. Control specifications deal with interactions
between the creators and their distributors governing the
imposition of further restrictions and fees. For example, a
distributor of a digital work may not want an end consumer
of a digital work to add fees or otherwise profit by commercially exploiting the purchased digital work.
Grammar element 1511 "Control-Spec:=(Control:
{RestrictableiUnrestrictable} {UnchargeableiChargeable} )"
provides a condition to specifY the effect of usage rights and
fees of parents on the exercise of the right. A digital work is
restrictable if higher level d-blocks can impose further
restrictions (time specifications and access specifications) on
the right. It is unrestrictable if no further restrictions can be
imposed. The default setting is restrictable. A right is
unchargeable if no more fees can be imposed on the use of
the right. It is chargeable if more fees can be imposed. The
default is chargeable.
Time Specification
It is often desirable to assign a start date or specifY some
duration as to when a right may be exercised. Grammar
1512
"Time-Spec:=({Fixed-IntervaliSlidingelement
IntervaliMeter-Time} Until: Expiration-Date)" provides for
specification of time conditions on the exercise of a right.
Rights may be granted for a specified time. Different kinds
of time specifications are appropriate for different kinds of
rights. Some rights may be exercised during a fixed and
predetermined duration. Some rights may be exercised for
an interval that starts the first time that the right is invoked
by some transaction. Some rights may be exercised or are
charged according to some kind of metered time, which may
be split into separate intervals. For example, a right to view
a picture for an hour might be split into six ten minute
viewings or four fifteen minute viewings or twenty three
minute viewings.
The terms "time" and "date" are used synonymously to
refer to a moment in time. There are several kinds of time
specifications. Each specification represents some limitation
on the times over which the usage right applies. The
Expiration-Date specifies the moment at which the usage
right ends. For example, if the Expiration-Date is "Jan. 1,
1995," then the right ends at the first moment of 1995. If the
Expiration-Date is specified as *forever*, then the rights are
interpreted as continuing without end. If only an expiration
date is given, then the right can be exercised as often as
desired until the expiration date.
Grammar element 1513 "Fixed-Interval:=From: StartTime" is used to define a predetermined interval that runs
from the start time to the expiration date.
Grammar element 1514 "Sliding-Interval:=Interval: UseDuration" is used to define an indeterminate (or "open")
start time. It sets limits on a continuous period of time over
which the contents are accessible. The period starts on the
first access and ends after the duration has passed or the
expiration date is reached, whichever comes first. For
example, if the right gives 10 hours of continuous access, the
use-duration would begin when the first access was made
and end 10 hours later.
Grammar element 1515 "Meter-Time:=Time-Remaining:
Remaining-Use" is used to define a "meter time," that is, a
measure of the time that the right is actually exercised. It
10
All of the time specifications include time-unit specifications
in their ultimate instantiation.
15
20
25
30
35
40
45
50
55
60
65
Security Class and Authorization Specification
The present invention provides for various security
mechanisms to be introduced into a distribution or use
scheme. Grmar element 1516 "Access-Spec:=({SC:
Security-Class}{ Authorization: Authorization-ID }{OtherAuthorization: Authorization-ID* }{Tick t: Ticket-ID} )"
provides a means for restricting access and transmission.
Access specifications can specifY a required security class
for a repository to exercise a right or a required authorization
test that must be satisfied.
The keyword "SC:" is used to specifY a minimum security
level for the repositories involved in the access. If "SC:" is
not specified, the lowest security level is acceptable.
The optional "Authorization:" keyword is used to specifY
required authorizations on the same repository as the work.
The optional "Other-Authorization:" keyword is used to
specifY required authorizations on the other repository in the
transaction.
The optional "Ticket:" keyword specifies the identity of a
ticket required for the transaction. A transaction involving
digital tickets must locate an appropriate digital ticket agent
who can "punch" or otherwise validate the ticket before the
transaction can proceed. Tickets are described in greater
detail below.
In a transaction involving a repository and a document
server, some usage rights may require that the repository
have a particular authorization, that the server have some
authorization, or that both repositories have (possibly different) authorizations. Authorizations themselves are digital
works (hereinafter referred to as an authorization object) that
can be moved between repositories in the same manner as
other digital works. Their copying and transferring is subject
to the same rights and fees as other digital works. A
repository is said to have an authorization if that authorization object is contained within the repository.
In some cases, an authorization may be required from a
source other than the document server and repository. An
authorization object referenced by an Authorization-ID can
contain digital address information to be used to set up a
communications link between a repository and the authorization source. These are analogous to phone numbers. For
such access tests, the communication would need to be
established and authorization obtained before the right could
be exercised.
For one-time usage rights, a variant on this scheme is to
have a digital ticket. A ticket is presented to a digital ticket
agent, whose type is specified on the ticket. In the simplest
case, a certified generic ticket agent, available on all repositories, is available to "punch" the ticket. In other cases, the
ticket may contain addressing information for locating a
"special" ticket agent. Once a ticket has been punched, it
cannot be used again for the same kind of transaction (unless
it is unpunched or refreshed in the manner described below.)
Punching includes marking the ticket with a timestamp of
Case 2:13-cv-01112 Document 1-7 Filed 12/18/13 Page 29 of 45 PageID #: 256
US 7,269,576 B2
23
24
the date and time it was used. Tickets are digital works and
can be copied or transferred between repositories according
to their usage rights.
In the currently preferred embodiment, a "punched" ticket
becomes "unpunched" or "refreshed" when it is copied or
extracted. The Copy and Extract operations save the date
and time as a property of the digital ticket. When a ticket
agent is given a ticket, it can simply check whether the
digital copy was made after the last time that it was punched.
Of course, the digital ticket must have the copy or extract
usage rights attached thereto.
The capability to unpunch a ticket is inportant in the
following cases:
A digital work is circulated at low cost with a limitation
that it can be used only once.
A digital work is circulated with a ticket that can be used
once to give discounts on purchases of other works.
A digital work is circulated with a ticket (included in the
purchase price and possibly embedded in the work) that
can be used for a future upgrade.
In each of these cases, if a paid copy is made of the digital
work (including the ticket) the new owner would expect to
get a fresh (unpunched) ticket, whether the copy seller has
used the work or not. In contrast, loaning a work or simply
transferring it to another repository should not revitalize the
ticket.
Fees are paid by the copy-owner/user to the revenueowner if Fee: is specified. Incentives are paid by the revenue-owner to the user iflncentive: is specified. If the Min:
specification is given, then there is a minimum fee to be
charged per time-spec unit for its use. If the Max: specification is given, then there is a maximum fee to be charged
per time-spec for its use. When Fee: is specified, Account-ID
identifies the account to which the fee is to be paid. When
Incentive: is specified, Account-ID identifies the account
from which the fee is to be paid.
Grammar element 1520 "Per-Use-Spec:=Per-Use:
Money-unit" defines a simple fee to be paid every time the
right is exercised, regardless of how much time the transaction takes.
Grammar element 1521 "Metered-Rate-Spec:=Metered:
Money-Unit Per: Time-Spec" defines a metered-rate fee paid
according to how long the right is exercised. Thus, the time
it takes to complete the transaction determines the fee.
Grammar element 1522 "Best-Price-Spec:=Best-Price:
Money-unit Max: Money-unit" is used to specify a bestprice that is determined when the account is settled. This
specification is to accommodate special deals, rebates, and
pricing that depends on information that is not available to
the repository. All fee specifications can be combined with
tickets or authorizations that could indicate that the consumer is a wholesaler or that he is a preferred customer, or
that the seller be authorized in some way. The amount of
money in the Max: field is the maximum amount that the us
will cost. This is the amount that is tentatively debited from
the credit server. However, when the transaction is ultimately reconciled, any excess amount will be returned to the
consumer in a separate transaction.
Grammar element 1523 "Call-For-Price-Spec:=Call-ForPrice" is similar to a "Best-Price-Spec" in that it is intended
to accommodate cases where prices are dynamic. A CallFor-Price Spec requires a communication with a dealer to
determine the price. This option caunot be exercised if the
repository carmot communicate with a dealer at the time that
the right is exercised. It is based on a secure transaction
whereby the dealer names a price to exercise the right and
passes along a deal certificate which is referenced or
included in the billing process.
Grammar element 1524 "Scheduled-Fee-Spec:=(Schedule: (Time-Spec Regular-Fee-Spec)*)" is used to provide a
schedule of dates over which the fee specifications change.
The fee specification with the most recent date not in the
future is the one that is in effect. This is similar to but more
general than the scheduled discount. It is more general,
because it provides a means to vary the fee agreement for
each time period.
Grammar element 1525 "Markup-Spec:=Markup: percentage To: Account-ID" is provided for adding a percentage
to the fees already being charged. For example, a 5%
markup means that a fee of 5% of cumulative fee so far will
be allocated to the distributor. A markup specification can be
applied to all of the other kinds of fee specifications. It is
typically used in a shell provided by a distributor. It refers
to fees associated with d-blocks that are parts of the current
d-block. This might be a convenient specification for use in
taxes, or in distributor overhead.
Usage Fees and Incentives Specification
The billing for use of a digital work is fundamental to a
commercial distribution system. Grammar Element 1517
"Fee-Spec:={ Scheduled-Discount}
Regular-FeeSpeciScheduled-Fee-SpeciMarkup-Spec" provides a range
of options for billing for the use of digital works.
A key feature of this approach is the development of
low-overhead billing for transactions in potentially small
amounts. Thus, it becomes feasible to collect fees of only a
few cents each for thousands of transactions.
The grammar differentiates between uses where the
charge is per use from those where it is metered by the time
unit. Transactions can support fees that the user pays for
using a digital work as well as incentives paid by the right
grantor to users to induce them to use or distribute the digital
work.
The optional scheduled discount refers to the rest of the
fee specification-discounting it by a percentage over time.
If it is not specified, then there is no scheduled discount.
Regular fee specifications are constant over time. Scheduled
fee specifications give a schedule of dates over which the fee
specifications change. Markup specifications are used in
d-blocks for adding a percentage to the fees already being
charged.
Grammar Element 1518 "Scheduled-Discount:=(Scheduled-Discount: (Time-Spec Percentage)*)" A ScheduledDiscount is a essentially a scheduled modifier of any other
fee specification for this version of the right of the digital
work. (It does not refer to children or parent digital works or
to other versions of rights.). It is a list of pairs of times and
percentages. The most recent time in the list that has not yet
passed at the time of the transaction is the one in effect. The
percentage gives the discount percentage. For example, the
number 10 refers to a 10% discount.
Grammar Element 1519 "Regular-Fee-Spec:=( {Fee:IIncentive:} [Per-Use-SpeciMetered-Rate-SpeciBest-PriceSpeciCall-For-Price-Specl{Min: Money-Unit Per: TimeSpec }{Max: Mon y-Unit Per: Tim-Spec} To: Account-ID)''
provides for several kinds of fee specifications.
10
15
20
25
30
35
40
45
50
55
60
65
Examples of Sets of Usage Rights
((Play) (Transfer (SC: 3)) (Delete)
This work can be played without requirements for fee or
authorization on any rendering system. It can be transferred
to any other repository of security level 3 or greater. It can
be deleted.
Case 2:13-cv-01112 Document 1-7 Filed 12/18/13 Page 30 of 45 PageID #: 257
US 7,269,576 B2
25
26
((Play) (Transfer (SC: 3)) (Delete) (Backup) (Restore
(Fee:Per-Use: $5 To: Account-ID-678)))
Same as the previous example plus rights for backup and
restore. The work can be backed up without fee. It can be
restored for a $5 fee payable to the account described by
Account-ID-678.
((Play) (Transfer (SC: 3))
(Copy (SC:3)(Fee: Per-Use: $5 To: Account-ID-678))
(Delete (Incentive: Per-Use: $2.50 To: Acconnt-ID-678)))
This work can be played, transferred, copied, or deleted.
Copy or transfer operations can take place only with repositories of security level three or greater. The fee to make a
copy is $5 payable to Acconnt-ID-678. If a copy is deleted,
then an incentive of $2.50 is paid to the former copy owner.
((Play) (Transfer (SC: 3))
Copy (SC: 3) (Fee: Per-Use: $10 To: Account-ID-678))
Delete) (Backup) (Restore (SC: 3) (Fee: Per-Use: $5 To:
Account-ID-678)))
Same as the previous example plus fees for copying. The
work can be copied digitally for a fee of $10 payable to
Account-ID-678. The repository on which the work is
copied or restored must be at security level 3 or greater.
((Play) (Transfer (SC: 3))
(Copy Authorization: License-123-ID (SC: 3)))
The digital work can be played, transferred, or copied.
Copies or transfers must be on repositories of security level
3 or greater. Copying requires the license License-123-ID
issued to the copying repository. None of the rights require
fees.
((Play) (Print Printer: Printer-567-ID (Fee: Per-Use: $1
To: Acconnt-ID-678)))
This work can be played for free. It can be printed on any
printer with the identifier Printer-567-ID for a fee of $1
payable to the account described by Account-ID-678.
((Play Player: Player-876-ID) (From: 94/02/14 Until:
95/02/15) (Fee: Metered: $0.01 Per: 0:1:0 Min: $0.25
Per: 0/1/0 To: Account-ID-567))
(Fee: Metered: $0.01 Per: 0:1:0 Min: $0.25 Per: 0/1/0
To: Account-ID-567))))
The original work has rights to Play, Transfer, Copy, Print,
Backup, Restore, and Loan. There are two versions of the
Loan right. The first version of the loan right costs $10 per
day but allows the original copy owner to exercise free use
of the Play, Print and Backup rights. The second version of
the Loan right is free. None of the original rights are
applicable. However a right to Play the work at the specified
metered rate is added.
((Play Player: Player-Small-Screen-123-ID)
(Embed (Fee: Per-Use. $0.01 To: Account-678-ID))
(Copy (Fee: Per-Use $1.00 To: Acconnt-678-ID)))
The digital work can be played on any player with the
identifier Player-Small-Screen-123-ID. It can be embedded
in a larger work. The embedding requires a modest one cent
registration fee to Account-678-ID. Digital copies can be
made for $1.00.
This work can be played on any player holding the ID
Player-876-ID. The time of this right is from Feb. 14, 1994
until Feb. 15, 1995. The fee for use is one cent per minute
with a minimum of 25 cents in any day that it is used,
payable to the account described by Account-ID-567.
((Play) (Transfer) (Delete)(Loan 2 (Delete: Transfer
Loan)))
This work can be played, transferred, deleted, or loaned.
Up to two copies can be loaned out at a time. The loaned
copy has the same rights except that it cannot be transferred.
When both copies are loaned out, no rights can be exercised
on the original on the repository.
((Play) (Transfer) (Delete) (Backup) (Restore (SC:3))
(Loan 2 Remaining-Copy-Rights: (Delete: Play Transfer)
Next-Set-of-Rights: (Delete: Transfer Loan)))
Similar to previous example. Rights to Backup and
Restore the work are added, where restoration requires a
repository of at least security level three. When all copies of
the work are loaned out, the remaining copy cannot be
played or transferred.
((Play) (Transfer) (Copy) (Print) (Backup) (Restore (SC:
3))
(Loan 1 Remaining-Copy-Rights: (Add: Play Print
Backup)
Next-Set-of-Rights: (Delete: Transfer Loan)
(Fee: Metered: $10 Per: 1:0:0 To: Account-ID-567))
(Loan 1 Remaining-Copy-Rights:
Add: ((Play Player: Player-876-ID) 2 (From: 94/02/14
Until: 95/02/15)
5
10
15
20
25
30
35
40
45
50
55
60
65
Repository Transactions
When a user requests access to a digital work, the
repository will initiate various transactions. The combination of transactions invoked will depend on the specifications assigned for a usage right. There are three basic types
of transactions, Session Initiation Transactions, Financial
Transactions and Usage Transactions. Generally, session
initiation transactions are initiated first to establish a valid
session. When a valid session is established, transactions
corresponding to the various usage rights are invoked.
Finally, request specific transactions are performed.
Transactions occur between two repositories (one acting
as a server), between a repository and a document playback
platform (e.g. for executing or viewing), between a repository and a credit server or between a repository and an
authorization server. When transactions occur between more
than one repository, it is assumed that there is a reliable
communication charmel between the repositories. For
example, this could be a TCP/IP charmel or any other
commercially available channel that has built-in capabilities
for detecting and correcting transmission errors. However, it
is not assumed that the communication channel is secure.
Provisions for security and privacy are part of the requirements for specifYing and implementing repositories and thus
form the need for various transactions.
Message Transmission
Transactions require that there be some communication
between repositories. Communication between repositories
occurs in units termed as messages. Because the communication line is assumed to be nnsecure, all communications
with repositories that are above the lowest security class are
encrypted utilizing a public key encryption technique. Public key encryption is a well kuown technique in the encryption arts. The term key refers to a numeric code that is used
with encryption and decryption algorithms. Keys come in
pairs, where "writing keys" are used to encrypt data and
"checking keys" are used to decrypt data. Both writing and
checking keys may be public or private. Public keys are
those that are distributed to others. Private keys are maintained in confidence.
Key management and security is instrumental in the
success of a public key encryption system. In the currently
preferred embodiment, one or more master repositories
maintain the keys and create the identification certificates
used by the repositories.
When a sending reposition transmits a message to a
receiving repository, the sending repository encrypts all of
its data using the public writing key of the receiving reposi-
Case 2:13-cv-01112 Document 1-7 Filed 12/18/13 Page 31 of 45 PageID #: 258
US 7,269,576 B2
27
28
tory. The sending repository includes its name, the name of
the receiving repository, a session identifier such as a nonce
(described below), and a message counter in each message.
In this way, the communication can only be read (to a high
probability) by the receiving repository, which holds the
private checking key for decryption. The auxiliary data is
used to guard against various replay attacks to security. If
messages ever arrive with the wrong counter or an old
nonce, the repositories can assume that someone is interfering with communication and the transaction terminated.
The respective public keys for the repositories to be used
for encryption are obtained in the registration transaction
described below.
the hotlist when their certificates expire, so that the list does
not need to grow without bound. Also, by keeping a short list
of hotlist certificates that it has previously received, a
repository can avoid the work of actually going through the
list. These lists would be encrypted by a master repository.
A minor variation on the approach to improve efficiency
would have the repositories first exchange lists of names of
hotlist certificates, ultimately exchanging only those lists
that they had not previously received. The "hotlists" are
maintained and distributed by Master repositories.
Note that rather than terminating in error, the transaction
could request that another registration message be sent based
on an identification certificate created by another master
repository. This may be repeated until a satisfactory identification certificate is found, or it is determined that trust
cannot be established.
Assuming that the repository is not on the hotlist, the
repository identification needs to be verified. In other words,
repository-2 needs to validate that the repository on the other
end is really repository-!. This is termed performance testing and is performed in order to avoid invalid access to the
repository via a counterfeit repository replaying a recording
of a prior session initiation between repository-! and repository-2. Performance testing is initiated by repository-2 generating a performance message, step 1609. The performance
message consists of a nonce, the names of the respective
repositories, the time and the registration identifier received
from repository-!. A nonce is a generated message based on
some random and variable information (e.g. the time or the
temperature.) The nonce is used to check whether repository-! can actually exhibit correct encrypting of a message
using the private keys it claims to have, on a message that
it has never seen before. The performance message is
encrypted using the public key specified in the registration
message ofrepository-1. The performance message is transmitted to repository-!, step 1610, where it is decrypted by
repository-! using its private key, step 1611. Repository-!
then checks to make sure that the names of the two repositories are correct, step 1612, that the time is accurate, step
1613 and that the registration identifier corresponds to the
one it sent, step 1614. If any of these tests fails, the
transaction is terminated per step 1616. Assuming that the
tests are passed, repository-! transmits the nonce to repository-2 in the clear, step 1615. Repository-2 then compares
the received nonce to the original nonce, step 1617. If they
are not identical, the registration transaction terminates in an
error per step 1618. If they are the same, the registration
transaction has successfully completed.
At this point, assuming that the transaction has not
terminated, the repositories exchange messages containing
session keys to be used in all communications during the
session and synchronize their clocks. FIG. 17 illustrates the
session information exchange and clock synchronization
steps (again from the perspective ofrepository-1.) Referring
to FIG. 17, repository-! creates a session key pair, step 1701.
A first key is kept private and is used by repository-! to
encrypt messages. The second key is a public key used by
repository-2 to decrypt messages. The second key is
encrypted using the public key of repository-2, step 1702
and is sent to repository-2, step 1703. Upon receipt, repository-2 decrypts the second key, step 1704. The second key
is used to decrypt messages in subsequent communications.
When each repository has completed this step, they are both
convinced that the other repository is bona fide and that they
are communicating with the original. Each repository has
given the other a key to be used in decrypting further
communications during the session. Since that key is itself
Session Initiation Transactions
A usage transaction is carried out in a session between
repositories. For usage transactions involving more than one
repository, or for financial transactions between a repository
and a credit server, a registration transaction is performed. A
second transaction termed a login transaction, may also be
needed to initiate the session. The goal of the registration
transaction is to establish a secure channel between two
repositories who know each others identities. As it is
assumed that the communication channel between the
repositories is reliable but not secure, there is a risk that a
non-repository may mimic the protocol in order to gain
illegitimate access to a repository.
The registration transaction between two repositories is
described with respect to FIGS. 16 and 17. The steps
described are from the perspective of a "repository-!"
registering its identity with a "repository-2". The registration must be symmetrical so the same set of steps will be
repeated for repository-2 registering its identity with repository-!. Referring to FIG. 16, repository-! first generates an
encrypted registration identifier, step 1601 and then generates a registration message, step 1602. A registration message is comprised of an identifier of a master repository, the
identification certificate for the repository-! and an
encrypted random registration identifier. The identification
certificate is encrypted by the master repository in its private
key and attests to the fact that the repository (here repository-!) is a bona fide repository. The identification certificate
also contains a public key for the repository, the repository
security level and a timestamp (indicating a time after which
the certificate is no longer valid.) The registration identifier
is a number generated by the repository for this registration.
The registration identifier is unique to the session and is
encrypted in repository-l's private key. The registration
identifier is used to improve security of authentication by
detecting certain kinds of communications based attacks.
Repository-! then transmit the registration message to
repository-2, step 1603.
Upon receiving the registration message, repository-2
determines if it has the needed public key for the master
repository, step 1604. If repository-2 does not have the
needed public key to decrypt the identification certificate,
the registration transaction terminates in an error, step 1618.
Assuming that repository-2 has the proper public key the
identification certificate is decrypted, step 1605. Repository-2 saves the encrypted registration identifier, step 1606,
and extracts the repository identifier, step 1607. The
extracted repository identifier is checked against a "hotlist"
of compromised document repositories, step 1608. In the
currently preferred embodiment, each repository will contain "hotlists" of compromised repositories. If the repository
is on the "hotlist", the registration transaction terminates in
an error per step 1618. Repositories can be removed from
10
15
20
25
30
35
40
45
50
55
60
65
Case 2:13-cv-01112 Document 1-7 Filed 12/18/13 Page 32 of 45 PageID #: 259
US 7,269,576 B2
29
30
transmitted in the public key of the receiving repository only
it will be able to decrypt the key which is used to decrypt
subsequent messages.
After the session information is exchanged, the repositories must synchronize their clocks. Clock synchronization is
used by the repositories to establish an agreed upon time
base for the financial records of their mutual transactions.
Referring back to FIG. 17, repository-2 initiates clock
synchronization by generating a time stamp exchange message, step 1705, and transmits it to repository-!, step 1706.
Upon receipt, repository-! generates its own time stamp
message, step 1707 and transmits it back to repository-2,
step 1708. Repository-2 notes the current time, step 1709
and stores the time received from repository-!, step 1710.
The current time is compared to the time received from
repository-!, step 1711. The difference is then checked to see
if it exceeds a predetermined tolerance (e.g. one minute),
step 1712. If it does, repository-2 terminates the transaction
as this may indicate tampering with the repository, step
1713. If not repository-2 computes an adjusted time delta,
step 1714. The adjusted time delta is the difference between
the clock time of repository-2 and the average of the times
from repository-! and repository-2.
To achieve greater accuracy, repositry-2 can request the
time again up to a fixed number of times (e.g. five times),
repeat the clock synchronization steps, and average the
results.
A second session initiation transaction is a Login transaction. The Login transaction is used to check the authenticity of a user requesting a transaction. A Login transaction
is particularly prudent for the authorization of financial
transactions that will be charged to a credit server. The Login
transaction involves an interaction between the user at a user
interface and the credit server associated with a repository.
The information exchanged here is a login string supplied by
the repository/credit server to identifY itself to the user, and
a Personal Identification Number (PIN) provided by the user
to identifY himself to the credit server. In the event that the
user is accessing a credit server on a repository different
from the one on which the user interface resides, exchange
of the information would be encrypted using the public and
private keys of the respective repositories.
An Begin-charges transaction to assign a charge. This
transaction is much the same as an assign fee transaction except that it is used for metered use. It includes
the same information as the assign-fee transaction as
well as the usage fee information. The credit-server is
then responsible for running a clock.
An End-charges transaction to end a charge for metered
use. (In a variation on this approach, the repositories
would exchange periodic charge information for each
block of time.)
A report-charges transaction between a personal credit
server and a billing clearinghouse. This transaction is
invoked at least once per billing period. It is used to
pass along information about charges. On debit and
credit cards, this transaction would also be used to
update balance information and credit limits as needed.
All billing transactions are given a transaction ID and are
reported to the credit severs by both the server and the client.
This reduces possible loss of billing information if one of the
parties to a transaction loses a banking card and provides a
check against tampering with the system.
Billing Transactions
Billing Transactions are concerned with monetary transaction with a credit server. Billing Transaction are carried
out when all other conditions are satisfied and a usage fee is
required for granting the request. For the most part, billing
transactions are well understood in the state of the art. These
transactions are between a repository and a credit server, or
between a credit server and a billing clearinghouse. Briefly,
the required transactions include the following:
Registration and LOGIN transactions by which the
repository and user establish their bona fides to a credit
server. These transactions would be entirely internal in
cases where the repository and credit server are implemented as a single system.
Registration and LOGIN transactions, by which a credit
server establishes its bona fides to a billing clearinghouse.
An Assign-fee transaction to assign a charge. The information in this transaction would include a transaction
identifier, the identities of the repositories in the transaction, and a list of charges from the parts of the digital
work. If there has been any unusual event in the
transaction such as an interruption of communications,
that information is included as well.
10
15
20
25
30
35
40
45
50
55
60
65
Usage Transactions
After the session initiation transactions have been completed, the usage request may then be processed. To simplifY
the description of the steps carried out in processing a usage
request, the term requester is used to refer to a repository in
the requester mode which is initiating a request, and the term
server is used to refer to a repository in the server mode and
which contains the desired digital work. In many cases such
as requests to print or view a work, the requester and server
may be the same device and the transactions described in the
following would be entirely internal. In such instances,
certain transaction steps, such as the registration transaction,
need not be performed.
There are some common steps that are part of the semantics of all of the usage rights transactions. These steps are
referred to as the common transaction steps. There are two
sets-the "opening" steps and the "closing" steps. For
simplicity, these are listed here rather than repeating them in
the descriptions of all of the usage rights transactions.
Transactions can refer to a part of a digital work, a
complete digital work, or a Digital work containing other
digital works. Although not described in detail herein, a
transaction may even refer to a folder comprised of a
plurality of digital works. The term "work" is used to refer
to what ever portion or set of digital works is being accessed.
Many of the steps here involve determining if certain
conditions are satisfied. Recall that each usage right may
have one or more conditions which must be satisfied before
the right can be exercised. Digital works have parts and parts
have parts. Different parts can have different rights and fees.
Thus, it is necessary to verify that the requirements are met
for ALL of the parts that are involved in a transaction For
brevity, when reference is made to checking whether the
rights exist and conditions for exercising are satisfied, it is
meant that all such checking takes place for each of the
relevant parts of the work.
FIG. 18 illustrates the initial common opening and closing
steps for a transaction. At this point it is assumed that
registration has occurred and that a "trusted" session is in
place. General tests are tests on usage rights associated with
the folder containing the work or some containing folder
higher in the file system hierarchy. These tests correspond to
requirements imposed on the work as a consequence of its
being on the particular repository, as opposed to being
attached to the work itself. Referring to FIG. 18, prior to
Case 2:13-cv-01112 Document 1-7 Filed 12/18/13 Page 33 of 45 PageID #: 260
US 7,269,576 B2
31
32
initiating a usage transaction, the requester performs any
general tests that are required before the right associated
with the transaction can be exercised, step, 1801. For
example, install, uninstall and delete rights may be implemented to require that a requester have an authorization
certificate before the right can be exercised. Another
example is the requirement that a digital ticket be present
and punched before a digital work may be copied to a
requester. If any of the general tests fail, the transaction is
not initiated, step, 1802. Assuming that such required tests
are passed, upon receiving the usage request, the server
generates a transaction identifier that is used in records or
reports of the transaction, step 1803. The server then checks
whether the digital work has been granted the right corresponding to the requested transaction, step 1804. If the
digital work has not been granted the right corresponding to
the request, the transaction terminates, step 1805. If the
digital work has been granted the requested right, the server
then determines if the various conditions for exercising the
right are satisfied. Time based conditions are examined, step
1806. These conditions are checked by examining the time
specification for the the version of the right. If any of the
conditions are not satisfied, the transaction terminates per
step 1805.
Assuming that the time based conditions are satisfied, the
server checks security and access conditions, step 1807.
Such security and access conditions are satisfied if: 1) the
requester is at the specified security class, or a higher
security class, 2) the server satisfies any specified authorization test and 3) the requester satisfies any specified authorization tests and has any required digital tickets. If any of
the conditions are not satisfied, the transaction terminates
per step 1805.
Assuming that the security and access conditions are all
satisfied, the server checks the copy count condition, step
1808. If the copy count equals zero, then the transaction
carmot be completed and the transaction terminates per step
1805.
Assuming that the copy count does not equal zero, the
server checks if the copies in use for the requested right is
greater than or equal to any copy count for the requested
right (or relevant parts), step 1809. If the copies in use is
greater than or equal to the copy count, this indicates that
usage rights for the version of the transaction have been
exhausted. Accordingly, the server terminates the transaction, step 1805. If the copy count is less than the copies in
use for the transaction the transaction can continue, and the
copies in use would be incremented by the number of digital
works requested in the transaction, step 1810.
The server then checks if the digital work has a "Loan"
access right, step 1811. The "Loan" access right is a special
case since remaining rights may be present even though all
copies are loaned out. If the digital work has the "Loan"
access right, a check is made to see if all copies have been
loaned out, step 1812. The number of copies that could be
loaned is the sum of the Copy-Counts for all of the versions
of the loan right of the digital work. For a composite work,
the relevant figure is the minimal such sum of each of the
components of the composite work. If all copies have been
loaned out, the remaining rights are determined, step 1813.
The remaining-rights is determined from the remaining
rights specifications from the versions of the Loan right. If
there is only one version of the Loan right, then the
determination is simple. The remaining rights are the ones
specified in that version of the Loan right, or none if
Remaining-Rights: is not specified. If there are multiple
versions of the Loan right and all copies of all of the versions
are loaned out, then the remaining rights is taken as the
minimum set (intersection) of remaining rights across all of
the versions of the loan right. The server then determines if
the requested right is in the set of remaining rights, step
1814. If the requested right is not in the set of remaining
rights, the server terminates the transaction, step 1805.
If Loan is not a usage right for the digital work or if all
copies have not been loaned out or the requested right is in
the set of remaining rights, fee conditions for the right are
then checked, step 1815. This will initiate various financial
transactions between the repository and associated credit
server. Further, any metering of usage of a digital work will
commence. If any financial transaction fails, the transaction
terminates per step 1805.
It should be noted that the order in which the conditions
are checked need not follow the order of steps 1806-1815.
At this point, right specific steps are now performed and
are represented here as step 1816. The right specific steps are
described in greater detail below.
The common closing transaction steps are now performed. Each of the closing transaction steps are performed
by the server after a successful completion of a transaction.
Referring back to FIG. 18, the copies in use value for the
requested right is decremented by the number of copies
involved in the transaction, step 1817. Next, if the right had
a metered usage fee specification, the server subtracts the
elapsed time from the Remaining-Use-Time associated with
the right for every part involved in the transaction, step
1818. Finally, if there are fee specifications associated with
the right, the server initiates End-Charge financial transaction to confirm billing, step 1819.
10
15
20
25
30
35
40
45
50
55
60
65
Transmission Protocol
An important area to consider is the transmission of the
digital work from the server to the requester. The transmission protocol described herein refers to events occurring
after a valid session has been created. The transmission
protocol must handle the case of disruption in the communications between the repositories. It is assumed that interference such as injecting noise on the communication channel can be detected by the integrity checks (e.g., parity,
checksum, etc.) that are built into the transport protocol and
are not discussed in detail herein.
The underlying goal in the transmission protocol is to
preclude certain failure modes, such as malicious or accidental interference on the communications channel. Suppose, for example, that a user pulls a card with the credit
server at a specific time near the end of a transaction. There
should not be a vulnerable time at which "pulling the card"
causes the repositories to fail to correctly account for the
number of copies of the work that have been created.
Restated, there should be no time at which a party can break
a connection as a means to avoid payment after using a
digital work.
If a transaction is interrupted (and fails), both repositories
restore the digital works and accounts to their state prior to
the failure, modulo records of the failure itself.
FIG. 19 is a state diagram showing steps in the process of
transmitting information during a transaction. Each box
represents a state of a repository in either the server mode
(above the central dotted line 1901) or in the requester mode
(below the dotted line 1901). Solid arrows stand for transitions between states. Dashed arrows stand for message
communications between the repositories. A dashed message arrow pointing to a solid transition arrow is interpreted
as meaning that the transition takes place when the message
is received. Unlabeled transition arrows take place uncon-
Case 2:13-cv-01112 Document 1-7 Filed 12/18/13 Page 34 of 45 PageID #: 261
US 7,269,576 B2
33
34
ditionally. Other labels on state transition arrows describe
conditions that trigger the transition.
Referring now to FIG. 19, the server is initially in a state
1902 where a new transaction is initiated via start message
1903. This message includes transaction information including a transaction identifier and a count of the blocks of data
to be transferred. The requester, initially in a wait state 1904
then enters a data wait state 1905.
The server enters a data transmit state 1906 and transmits
a block of data 1907 and then enters a wait for acknowledgement state 1908. As the data is received, the requesters
enters a data receive state 1909 and when the data blocks is
completely received it enters an acknowledgement state
1910 and transmits an Acknowledgement message 1911 to
the server.
If there are more blocks to send, the server waits until
receiving an Acknowledgement message from the requester.
When an Acknowledgement message is received it sends the
next block to the requester and again waits for acknowledgement. The requester also repeats the same cycle of
states.
If the server detects a communications failure before
sending the last block, it enters a cancellation state 1912
wherein the transaction is cancelled. Similarly, if the
requester detects a communications failure before receiving
the last block it enters a cancellation state 1913. If there are
no more blocks to send, the server commits to the transaction and waits for the final Acknowledgement in state 1914.
If there is a communications failure before the server
receives the final Acknowledgement message, it still commits to the transaction but includes a report about the event
to its credit server in state 1915. This report serves two
purposes. It will help legitimize any claims by a user of
having been billed for receiving digital works that were not
completely received. Also it helps to identify repositories
and communications lines that have suspicious patterns of
use and interruption. The server then enters its completion
state
On the requester side, when there are no more blocks to
receive, the requester commits to the transaction in state
1917. If the requester detects a communications failure at
this state, it reports the failure to its credit server in state
1918, but still commits to the transaction. When it has
committed, it sends an acknowledgement message to the
server. The server then enters its completion state 1919
The key property is that both the server and the requester
cancel a transaction if it is interrupted before all of the data
blocks are delivered, and commits to it if all of the data
blocks have been delivered.
There is a possibility that the server will have sent all of
the data blocks (and committed) but the requester will not
have received all of them and will cancel the transaction. In
this case, both repositories will presumably detect a communications failure and report it to their credit server. This
case will probably be rare since it depends on very precise
timing of the communications failure. The only consequence
will be that the user at the requester repository may want to
request a refund from the credit services-and the case for
that refund will be documented by reports by both repositories.
To prevent loss of data, the server should not delete any
transferred digital work until receiving the final acknowledgement from the requester. But it also should not use the
file. A well known way to deal with this situation is called
"two-phase commit" or 2PC.
Two-phase commit works as follows. The first phase
works the same as the method described above. The server
sends all of the data to the requester. Both repositories mark
the transaction (and appropriate files) as uncommitted. The
server sends a ready-to-commit message to the requester.
The requester sends back an acknowledgement. The server
then commits and sends the requester a commit message.
When the requester receives the commit message, it commits the file.
If there is a communication failure or other crash, the
requester must check back with the server to determine the
status of the transaction. The server has the last word on this.
The requester may have received all of the data, but if it did
not get the final message, it has not committed. The server
can go ahead and delete files (except for transaction records)
once it commits, since the files are known to have been fully
transmitted before starting the 2PC cycle.
There are variations known in the art which can be used
to achieve the same effect. For example, the server could use
an additional level of encryption when transmitting a work
to a client. Only after the client sends a message acknowledging receipt does it send the key. The client then agrees to
pay for the digital work. The point of this variation is that it
provides a clear audit trail that the client received the work.
For trusted systems, however, this variation adds a level of
encryption for no real gain in accountability.
The transaction for specific usage rights are now discussed.
10
15
20
25
30
35
40
45
50
55
60
65
The Copy Transaction
A Copy transaction is a request to make one or more
independent copies of the work with the same or lesser usage
rights. Copy differs from the extraction right discussed later
in that it refers to entire digital works or entire folders
containing digital works. A copy operation cannot be used to
remove a portion of a digital work.
The requester sends the server a message to initiate the
Copy Transaction. This message indicates the work to
be copied, the version of the copy right to be used for
the transaction, the destination address information
(location in a folder) for placing the work, the file data
for the work (including its size), and the number of
copies requested.
The repositories perform the common opening transaction
steps.
The server transmits the requested contents and data to the
client according to the transmission protocol. If a
Next-Set-Of-Rights has been provided in the version of
the right, those rights are transmitted as the rights for
the work. Otherwise, the rights of the original are
transmitted. In any event, the Copy-Count field for the
copy of the digital work being sent right is set to the
number-of-copies requested.
The requester records the work contents, data, and usage
rights and stores the work. It records the date and time
that the copy was made in the properties of the digital
work.
The repositories perform the common closing transaction
steps.
The Transfer Transaction
A Transfer transaction is a request to move copies of the
work with the same or lesser usage rights to another repository. In contrast with a copy transaction, this results in
removing the work copies from the server.
The requester sends the server a message to initiate the
Transfer Transaction. This message indicates the work
to be transferred, the version of the transfer right to be
used in the transaction, the destination address infor-
Case 2:13-cv-01112 Document 1-7 Filed 12/18/13 Page 35 of 45 PageID #: 262
US 7,269,576 B2
36
35
mation for placing the work, the file data for the work,
and the number of copies involved.
The repositories perform the common opening transaction
steps.
The server transmits the requested contents and data to the
requester according to the transmission protocol. If a
Next-Set-Of-Rights has been provided, those rights are
transmitted as the rights for the work. Otherwise, the
rights of the original are transmitted. In either case, the
Copy-Count field for the transmitted rights are set to
the number-of-copies requested.
The requester records the work contents, data, and usage
rights and stores the work.
The server decrements its copy count by the number of
copies involved in the transaction.
The repositories perform the common closing transaction
steps.
If the number of copies remaining in the server is now
zero, it erases the digital work from its memory.
10
15
20
The L an Transaction
A loan transaction is a mechanism for loaning copies of a
digital work. The maximum duration of the loan is determined by an internal parameter of the digital work. Works
are automatically returned after a predetermined time
period.
The requester sends the server a message to initiate the
Transfer Transaction. This message indicates the work
to be loaned, the version of the loan right to be used in
the transaction, the destination address information for
placing the work, the number of copies involved, the
file data for the work, and the period of the loan.
The server checks the validity of the requested loan
period, and ends with an error if the period is not valid.
Loans for a loaned copy cannot extend beyond the
period of the original loan to the server.
The repositories perform the common opening transaction
steps.
The server transmits the requested contents and data to the
requester. If a Next-Set-Of-Rights has been provided,
those rights are transmitted as the rights for the work.
Otherwise, the rights of the original are transmitted, as
modified to reflect the loan period.
The requester records the digital work contents, data,
usage rights, and loan period and stores the work.
The server updates the usage rights information in the
digital work to reflect the number of copies loaned out.
The repositories perform the common closing transaction
steps.
The server updates the usage rights data for the digital
work. This may preclude use of the work until it is
returned from the loan. The user on the requester
platform can now use the transferred copies of the
digital work. A user accessing the original repository
cannot use the digital work, unless there are copies
remaining. What happens next depends on the order of
events in time.
Case 1. If the time of the loan period is not yet
exhausted and the requester sends the repository a
Return message.
The return message includes the requester identification, and the transaction ID.
The server decrements the copies-in-use field by the
number of copies that were returned. (If the number of digital works returned is greater than the
number actually borrowed, this is treated as an
25
30
35
40
45
50
55
60
65
error.) This step may now make the work available
at the server for other users.
The requester deactivates its copies and removes the
contents from its memory.
Case 2. If the time of the loan period is exhausted and
the requester has not yet sent a Return message.
The server decrements the copies-in-use field by the
number digital works that were borrowed.
The requester automatically deactivates its copies of
the digital work. It terminates all current uses and
erases the digital work copies from memory. One
question is why a requester would ever return a
work earlier than the period of the loan, since it
would be returned automatically anyway. One
reason for early return is that there may be a
metered fee which determines the cost of the loan.
Returning early may reduce that fee.
The Play Transaction
A play transaction is a request to use the contents of a
work. Typically, to "play" a work is to send the digital work
through some kind of transducer, such as a speaker or a
display device. The request implies the intention that the
contents will not be communicated digitally to any other
system. For example, they will not be sent to a printer,
recorded on any digital medium, retained after the transaction or sent to another repository.
This term "play" is natural for examples like playing
music, playing a movie, or playing a video game. The
general form of play means that a "player" is used to use the
digital work. However, the term play covers all media and
kinds of recordings. Thus one would "play" a digital work,
meaning, to render it for reading, or play a computer
program, meaning to execute it. For a digital ticket the
player would be a digital ticket agent.
The requester sends the server a message to initiate the
play transaction. This message indicates the work to be
played, the version of the play right to be used in the
transaction, the identity of the player being used, and
the file data for the work.
The server checks the validity of the player identification
and the compatibility of the player identification with
the player specification in the right. It ends with an
error if these are not satisfactory.
The repositories perform the common opening transaction
steps.
The server and requester read and write the blocks of data
as requested by the player according to the transmission
protocol. The requester plays the work contents, using
the player.
When the player is finished, the player and the requester
remove the contents from their memory.
The repositories perform the common closing transaction
steps.
The Print Transaction
A Print transaction is a request to obtain the contents of a
work for the purpose of rendering them on a "printer." We
use the term "printer" to include the common case of writing
with ink on paper. However, the key aspect of "printing" in
our use of the term is that it makes a copy of the digital work
in a place outside of the protection of usage rights. As with
all rights, this may require particular authorization certificates.
Once a digital work is printed, the publisher and user are
bound by whatever copyright laws are in effect. However,
printing moves the contents outside the control of repositories. For example, absent any other enforcement mecha-
Case 2:13-cv-01112 Document 1-7 Filed 12/18/13 Page 36 of 45 PageID #: 263
US 7,269,576 B2
37
38
nisms, once a digital work is printed on paper, it can be
copied on ordinary photocopying machines without intervention by a repository to collect usage fees. If the printer to
a digital disk is permitted, then that digital copy is outside
of the control of usage rights. Both the creator and the user
know this, although the creator does not necessarily give
tacit consent to such copying, which may violate copyright
laws.
The requester sends the server a message to initiate a Print
transaction. This message indicates the work to be
played, the identity of the printer being used, the file
data for the work, and the number of copies in the
request.
The server checks the validity of the printer identification
and the compatibility of the printer identification with
the printer specification in the right. It ends with an
error if these are not satisfactory.
The repositories perform the common opening transaction
steps.
The server transmits blocks of data according to the
transmission protocol.
The requester prints the work contents, using the printer.
When the printer is finished, the printer and the requester
remove the contents from their memory.
The repositories perform the common closing transaction
steps.
The repositories perform the common closing transaction
steps.
In some cases, it is convenient to be able to archive the
large, encrypted contents file to secure offline storage, such
as a magneto-optical storage system or magnetic tape. This
creation of a non-repository archive file is as secure as the
encryption process. Such non-repository archive storage is
considered a form of "printing" and is controlled by a print
right with a specified "archive-printer." An archive-printer
device is programmed to save the encrypted contents file
(but not the description file) offline in such a way that it can
be retrieved.
The Backup Transaction
A Backup transaction is a request to make a backup copy
of a digital work, as a protection against media failure. In the
context of repositories, secure backup copies differ from
other copies in three ways: (1) they are made under the
control of a Backup transaction rather than a Copy transaction, (2) they do not count as regular copies, and (3) they are
not usable as regular copies. Generally, backup copies are
encrypted.
Although backup copies may be transferred or copied,
depending on their assigned rights, the only way to make
them useful for playing, printing or embedding is to restore
them.
The output of a Backup operation is both an encrypted
data file that contains the contents and description of a work,
and a restoration file with an encryption key for restoring the
encrypted contents. In many cases, the encrypted data file
would have rights for "printing" it to a disk outside of the
protection system, relying just on its encryption for security.
Such files could be stored anywhere that was physically safe
and convenient. The restoration file would be held in the
repository. This file is necessary for the restoration of a
backup copy. It may have rights for transfer between repositories.
The requester sends the server a message to initiate a
backup transaction. This message indicates the work to
be backed up, the version of the backup right to be used
in the transaction, the destination address information
for placing the backup copy, the file data for the work.
The repositories perform the common opening transaction
steps.
The server transmits the requested contents and data to the
requester. If a Next-Set-Of-Rights has been provided,
those rights are transmitted as the rights for the work.
Otherwise, a set of default rights for backup files of the
original are transmitted by the server.
The requester records the work contents, data, and usage
rights. It then creates a one-time key and encrypts the
contents file. It saves the key information in a restoration file.
10
15
20
25
30
35
40
45
50
55
60
65
The Restore Transaction
A Restore transaction is a request to convert an encrypted
backup copy of a digital work into a usable copy. A restore
operation is intended to be used to compensate for catastrophic media failure. Like all usage rights, restoration
rights can include fees and access tests including authorization checks.
The requester sends the server a message to initiate a
Restore transaction. This message indicates the work to
be restored, the version of the restore right for the
transaction, the destination address information for
placing the work, and the file data for the work.
The server verifies that the contents file is available (i.e.
a digital work corresponding to the request has been
backed-up.) If it is not, it ends the transaction with an
error.
The repositories perform the common opening transaction
steps.
The server retrieves the key from the restoration file. It
decrypts the work contents, data, and usage rights.
The server transmits the requested contents and data to the
requester according to the transmission protocol. If a
Next-Set-Of-Rights has been provided, those rights are
transmitted as the rights for the work. Otherwise, a set
of default rights for backup files of the original are
transmitted by the server.
The requester stores the digital work.
The repositories perform the common closing transaction
steps.
The Delete Transaction
A Delete transaction deletes a digital work or a number of
copies of a digital work from a repository. Practically all
digital works would have delete rights.
The requester sends the server a message to initiate a
delete transaction. This message indicates the work to
be deleted, the version of the delete right for the
transaction.
The repositories perform the common opening transaction
steps.
The server deletes the file, erasing it from the file system.
The repositories perform the common closing transaction
steps.
The Directory Transaction
A Directory transaction is a request for information about
folders, digital works, and their parts. This amounts to
roughly the same idea as protection codes in a conventional
file system like TENEX, except that it is generalized to the
full power of the access specifications of the usage rights
language.
The Directory transaction has the important role of passing along descriptions of the rights and fees associated with
a digital work. When a user wants to exercise a right, the
user interface of his repository implicitly makes a directory
Case 2:13-cv-01112 Document 1-7 Filed 12/18/13 Page 37 of 45 PageID #: 264
US 7,269,576 B2
40
39
request to determine the versions of the right that are
available. Typically these are presented to the user-such as
with different choices of billing for exercising a right. Thus,
many directory transactions are invisible to the user and are
exercised as part of the normal process of exercising all
rights.
The requester sends the server a message to initiate a
Directory transaction. This message indicates the file or
folder that is the root of the directory request and the
version of the directory right used for the transaction.
The server verifies that the information is accessible to the
requester. In particular, it does not return the names of
any files that have a HIDE-NAME status in their
directory specifications, and it does not return the parts
of any folders or files that have HIDE-PARTS in their
specification. If the information is not accessible, the
server ends the transaction with an error.
The repositories perform the common opening transaction
steps.
The server sends the requested data to the requester
according to the transmission protocol.
The requester records the data.
The repositories perform the common closing transaction
steps.
The Folder Transaction
A Folder transaction is a request to create or rename a
folder, or to move a work between folders. Together with
Directory rights, Folder rights control the degree to which
organization of a repository can be accessed or modified
from another repository.
The requester sends the server a message to initiate a
Folder transaction. This message indicates the folder
that is the root of the folder request, the version of the
folder right for the transaction, an operation, and data.
The operation can be one of create, rename, and move
file. The data are the specifications required for the
operation, such as a specification of a folder or digital
work and a name.
The repositories perform the common opening transaction
steps.
The server performs the requested operation--creating a
folder, renaming a folder, or moving a work between
folders.
The repositories perform the common closing transaction
steps.
The Extract Transaction
A extract transaction is a request to copy a part of a digital
work and to create a new work containing it. The extraction
operation differs from copying in that it can be used to
separate a part of a digital work from d-blocks or shells that
place additional restrictions or fees on it. The extraction
operation differs from the edit operation in that it does not
change the contents of a work, only its embedding in
d-blocks. Extraction creates a new digital work.
The requester sends the server a message to initiate an
Extract transaction. This message indicates the part of
the work to be extracted, the version of the extract right
to be used in the transaction, the destination address
information for placing the part as a new work, the file
data for the work, and the number of copies involved.
The repositories perform the common opening transaction
steps.
The server transmits the requested contents and data to the
requester according to the transmission protocol. If a
Next-Set-Of-Rights has been provided, those rights are
transmitted as the rights for the new work. Otherwise,
the rights of the original are transmitted. The CopyCount field for this right is set to the number-of-copies
requested.
The requester records the contents, data, and usage rights
and stores the work. It records the date and time that
new work was made in the properties of the work.
The repositories perform the common closing transaction
steps.
10
15
20
25
30
35
40
45
50
55
60
65
The Embed Transaction
An embed transaction is a request to make a digital work
become a part of another digital work or to add a shell
d-block to enable the adding of fees by a distributor of the
work.
The requester sends the server a message to initiate an
Embed transaction. This message indicates the work to
be embedded, the version of the embed right to be used
in the transaction, the destination address information
for placing the part as a a work, the file data for the
work, and the number of copies involved.
The server checks the control specifications for all of the
rights in the part and the destination. If they are
incompatible, the server ends the transaction with an
error.
The repositories perform the common opening transaction
steps.
The server transmits the requested contents and data to the
requester according to the transmission protocol. If a
Next-Set-Of-Rights has been provided, those rights are
transmitted as the rights for the new work. Otherwise,
the rights of the original are transmitted. The CopyCount field for this right is set to the number-of-copies
requested.
The requester records the contents, data, and usage rights
and embeds the work in the destination file.
The repositories perform the common closing transaction
steps.
The Edit Transaction
An Edit transaction is a request to make a new digital
work by copying, selecting and modifying portions of an
existing digital work. This operation can actually change the
contents of a digital work. The kinds of changes that are
permitted depend on the process being used. Like the
extraction operation, edit operates on portions of a digital
work. In contrast with the extract operation, edit does not
effect the rights or location of the work. It only changes the
contents. The kinds of changes permitted are determined by
the type specification of the processor specified in the rights.
In the currently preferred embodiment, an edit transaction
changes the work itself and does not make a new work.
However, it would be a reasonable variation to cause a new
copy of the work to be made.
The requester sends the server a message to initiate an
Edit transaction. This message indicates the work to be
edited, the version of the edit right to be used in the
transaction, the file data for the work (including its
size), the process-ID for the process, and the number of
copies involved.
The server checks the compatibility of the process-ID to
be used by the requester against any process-ID specification in the right. If they are incompatible, it ends the
transaction with an error.
The repositories perform the common opening transaction
steps.
The requester uses the process to change the contents of
the digital work as desired. (For example, it can select
and duplicate parts of it; combine it with other infor-
Case 2:13-cv-01112 Document 1-7 Filed 12/18/13 Page 38 of 45 PageID #: 265
US 7,269,576 B2
41
mation; or compute functions based on the information.
This can amount to editing text, music, or pictures or
taking whatever other steps are useful in creating a
derivative work.)
The repositories perform the common closing transaction
steps.
The edit transaction is used to cover a wide range of kinds
of works. The category describes a process that takes as its
input any portion of a digital work and then modifies the
input in some way. For example, for text, a process for
editing the text would require edit rights. A process for
"summarizing" or counting words in the text would also be
considered editing. For a music file, processing could
involve changing the pitch or tempo, or adding reverberations, or any other audio effect. For digital video works,
anything which alters the image would require edit rights.
Examples would be colorizing, scaling, extracting still photos, selecting and combining frames into story boards,
sharpening with signal processing, and so on.
Some creators may want to protect the authenticity of
their works by limiting the kinds of processes that can be
performed on them. If there are no edit rights, then no
processing is allowed at all. A processor identifier can be
included to specifY what kind of process is allowed. If no
process identifier is specified, then arbitrary processors can
be used. For an example of a specific process, a photographer may want to allow use of his photograph but may not
want it to be colorized. A musician may want to allow
extraction of portions of his work but not changing of the
tonality.
Authorization Transactions
There are many ways that authorization transactions can
be defined. In the following, our preferred way is to simply
define them in terms of other transactions that we already
need for repositories. Thus, it is convenient sometimes to
speak of "authorization transactions," but they are actually
made up of other transactions that repositories already have.
A usage right can specifY an authorization-ID, which
identifies an authorization object (a digital work in a file of
a standard format) that the repository must have and which
it must process. The authorization is given to the generic
authorization (or ticket) server of the repository which
begins to interpret the authorization.
As described earlier, the authorization contains a server
identifier, which may just be the generic authorization server
or it may be another server. When a remote authorization
server is required, it must contain a digital address. It may
also contain a digital certificate.
If a remote authorization server is required, then the
authorization process first performs the following steps:
The generic authorization server attempts to set up the
communications channel. (If the channel cannot be set
up, then authorization fails with an error.)
When the channel is set up, it performs a registration
process with the remote repository. (If registration fails,
then the authorization fails with an error.)
When registration is complete, the generic authorization
server invokes a "Play" transaction with the remote
repository, supplying the authorization document as the
digital work to be played, and the remote authorization
server (a program) as the "player." (If the player cannot
be found or has some other error, then the authorization
fails with an error.)
The authorization server then "plays" the authorization.
This involves decrypting it using either the public key
of the master repository that issued the certificate or the
42
10
15
20
25
30
35
40
45
50
55
60
65
session key from the repository that transmitted it. The
authorization server then performs various tests. These
tests vary according to the authorization server. They
include such steps as checking issue and validity dates
of the authorization and checking any hot-lists of
known invalid authorizations. The authorization server
may require carrying out any other transactions on the
repository as well, such as checking directories, getting
some person to supply a password, or playing some
other digital work. It may also invoke some special
process for checking information about locations or
recent events. The "script" for such steps is contained
within the authorization server.
If all of the required steps are completed satisfactorily, the
authorization server completes the transaction normally, signaling that authorization is granted.
The Install Transaction
An Install transaction is a request to install a digital work
as runnable software on a repository. In a typical case, the
requester repository is a rendering repository and the software would be a new kind or new version of a player. Also
in a typical case, the software would be copied to file system
of the requester repository before it is installed.
The requester sends the server an Install message. This
message indicates the work to be installed, the version
of the Install right being invoked, and the file data for
the work (including its size).
The repositories perform the common opening transaction
steps.
The requester extracts a copy of the digital certificate for
the software. If the certificate cannot be found or the
master repository for the certificate is not known to the
requester, the transaction ends with an error.
The requester decrypts the digital certificate using the
public key of the master repository, recording the
identity of the supplier and creator, a key for decrypting
the software, the compatibility information, and a
tamper-checking code. (This step certifies the software.)
The requester decrypts the software using the key from
the certificate and computes a check code on it using a
1-way hash function. If the check-code does not match
the tamper-checking code from the certificate, the
installation transaction ends with an error. (This step
assures that the contents of the software, including the
various scripts, have not been tampered with.)
The requester retrieves the instructions in the compatibility-checking script and follows them. If the software is
not compatible with the repository, the installation
transaction ends with an error. (This step checks platform compatibility.)
The requester retrieves the instructions in the installation
script and follows them. If there is an error in this
process (such as insufficient resources), then the transaction ends with an error. Note that the installation
process puts the runnable software in a place in the
repository where it is no longer accessible as a work for
exercising any usage rights other than the execution of
the software as part of repository operations in carrying
out other transactions.
The repositories perform the common closing transaction
steps.
The Uninstall Transaction
An Uninstall transaction is a request to remove software
from a repository. Since uncontrolled or incorrect removal of
Case 2:13-cv-01112 Document 1-7 Filed 12/18/13 Page 39 of 45 PageID #: 266
US 7,269,576 B2
43
44
software from a repository could compromise its behavioral
integrity, this step is controlled.
The requester sends the server an Uninstall message. This
message indicates the work to be uninstalled, the version of the Uninstall right being invoked, and the file
data for the work (including its size).
The repositories perform the common opening transaction
steps.
The requester extracts a copy of the digital certificate for
the software. If the certificate cannot be found or the
master repository for the certificate is not known to the
requester, the transaction ends with an error.
The requester checks whether the software is installed. If
the software is not installed, the transaction ends with
an error.
The requester decrypts the digital certificate using the
public key of the master repository, recording the
identity of the supplier and creator, a key for decrypting
the software, the compatibility information, and a
tamper-checking code. (This step authenticates the certification of the software, including the script for uninstalling it.)
The requester decrypts the software using the key from
the certificate and computes a check code on it using a
1-way hash function. If the check-code does not match
the tamper-checking code from the certificate, the
installation transaction ends with an error. (This step
assures that the contents of the software, including the
various scripts, have not been tampered with.)
The requester retrieves the instructions in the uninstallation script and follows them. If there is an error in this
process (such as insufficient resources), then the transaction ends with an error.
The repositories perform the common closing transaction
steps.
established by the consumer. It could also be a fixed nominal
amount that is contributed to the account of some charity.
Distribution and Use Scenarios
To appreciate the robustness and flexibility of the present
invention, various distribution and use scenarios for digital
works are illustrated below. These scenarios are meant to be
exemplary rather than exhaustive.
Consumers as Unpaid Distributors
In this scenario, a creator distributes copies of his works
to various consumers. Each consumer is a potential distributor of the work. If the consumer copies the digital work
(usually for a third party), a fee is collected and automatically paid to the creator.
This scenario is a new twist for digital works. It depends
on the idea that "manufacturing" is just copying and is
essentially free. It also assumes that the consumers as
distributors do not require a fee for their time and effort in
distributing the work.
This scenario is performed as follows:
A creator creates a digital work. He grants a Copy right
with fees paid back to himself. If he does not grant an Embed
right, then consumers carmot use the mechanism to act as
distributors to cause fees to be paid to themselves on future
copies. Of course, they could negotiate side deals or trades
to transfer money on their own, outside of the system.
10
15
20
25
30
35
40
45
50
55
60
Paid Distributors
In another scenario, every time a copy of a digital work
is sold a fee is paid to the creator and also to the immediate
distributor.
This scenario does not give special status to any particular
distributor. Anyone who sells a document has the right to
add a fee to the sale price. The fee for sale could be
65
This scenario is performed as follows:
A creator creates a digital work. He grants a Copy right
with fees to be paid back to himself. He grants an Embed
right, so that anyone can add shells to have fees paid to
themselves.
A distributor embeds the work in a shell, with fees
specified to be paid back to himself. If the distributor is
content to receive fees only for copies that he sells himself,
he grants an Extract right on the shell.
When a consumer buys a copy from the distributor, fees
are paid both to the distributor and to the creator. If he
chooses, the consumer can extract the work from the distributor's shell. He cannot extract it from the creator's shell.
He can add his own shell with fees to be paid to himself.
Licensed Distribution
In this scenario, a creator wants to protect the reputation
and value of his work by making certain requirements on its
distributors. He issues licenses to distributors that satisfY the
requirements, and in tum, promises to reward their efforts by
assuring that the work will not be distributed over competing
channels. The distributors incur expenses for selecting the
digital work, explaining it to buyers, promoting its sale, and
possibly for the license itself. The distributor obtains the
right to enclose the digital work in a shell, whose function
is to permit the attachment of usage fees to be paid to the
distributor in addition to the fees to be paid to the creator.
This differs from the previous scenario in that it precludes
the typical copy owner from functioning as a distributor,
since the consumer lacks a license to copy the document.
Thus, a consumer cannot make copies, even for free. All
copies must come initially from authorized distributors. This
version makes it possible to hold distributors accountable in
some way for the sales and support of the work, by controlling the distribution of certificates that enable distributors
to legitimately charge fees and copy owners to make copies.
Since licenses are themselves digital works, the same
mechanisms give the creators control over distributors by
charging for licenses and putting time limits on their validity.
This scenario is performed as follows:
A creator purchases a digital distribution license that he
will hand out to his distributors. He puts access requirements
(such as a personal license) on the Copy and Transfer rights
on the distribution license so that only he can copy or
transfer it.
The creator also creates a digital work. He grants an
Embed right and a Copy right, both of which require the
distribution license to be exercised. He grants a Play right so
that the work can be played by anyone. He may optionally
add a Transfer or Loan right, so that end consumers can do
some non-commercial exchange of the work among friends.
A distributor obtains the distribution license and a number
of copies of the work. He makes copies for his customers,
using his distribution license.
A customer buys and uses the work. He cannot make new
copies because he lacks a distribution license.
Super Distributors
This is a variation on the previous scenarios. A distributor
can sell to anyone and anyone can sell additional copies,
resulting in fees being paid back to the creator. However,
only licensed distributors can add fees to be paid to themselves.
Case 2:13-cv-01112 Document 1-7 Filed 12/18/13 Page 40 of 45 PageID #: 267
US 7,269,576 B2
45
46
This scenario gives distributors the right to add fees to
cover their own advertising and promotional costs, without
making them be the sole suppliers. Their customers can also
make copies, thus broadening the channel without diminishing their revenues. This is because distributors collect
fees from copies of any copies that they originally sold. Only
distributors can add fees.
This scenario is performed similarly to the previous ones.
There are two key differences. (1) The creator only grants
Embed rights for people who have a Distribution license.
This is done by putting a requirement for a distributor's
license on the Embed right. Consequently, non-distributors
cannot add their own fees. (2) The Distributor does not grant
Extract rights, so that consumers cannot avoid paying fees to
the Distributor if they make subsequent copies. Consequently, all subsequent copies result in fees paid to the
Distributor and the Creator.
distributor. A consumer buys the new work from the second
distributor. The first creator receives fees from every transaction; the first distributor receives fees only for his sale; the
second creator and second distributor receive fees for the
final sale.
This scenario shows how that flexible automatic arrangements can be set up to create automatic charging systems
that mirror current practice. This scenario is analogous to
when an author pays a fee to reuse a figure in some paper.
In the most common case, a fee is paid to the creator or
publisher, but not to the bookstore that sold the book.
The mechanisms for derived works are the same as those
for distribution.
!-Level Distribution Fees
In this scenario, a distributor gets a fee for any copy he
sells directly. However, if one of his customers sells further
copies, he gets no further fee for those copies.
This scenario pays a distributor only for use of copies that
he actually sold.
This scenario is performed similarly to the previous ones.
The key feature is that the distributor creates a shell which
specifies fees to be paid to him. He puts Extract rights on the
shell. When a consumer buys the work, he can extract away
the distributor's shell. Copies made after that will not require
fees to be paid to the distributor.
Distribution Trees
In another scenario, distributors sell to other distributors
and fees are collected at each level. Every copy sold by any
distributor-even several d-blocks down in the chainresults in a fee being paid back to all of the previous
distributors.
This scenario is like a chain letter or value chain. Every
contributor or distributor along the way obtains fees, and is
thereby encouraged to promote the sale of copies of the
digital work.
This scenario is performed similarly to the previous ones.
The key feature is that the distributor creates a shell which
specifies fees to be paid to him. He does not grant Extract
rights on the shell. Consequently, all future copies that are
made will result in fees paid to him.
Weighted Distribution Trees
In this scenario, distributors make money according to a
distribution tree. The fee that they make depends on various
parameters, such as time since their sale or the number of
subsequent distributors.
This is a generalized version of the Distribution Tree
scenario, in that it tries to vary the fee to account for the
significance of the role of the distributor.
This scenario is similar to the previous one. The difference is that the fee specification on the distributor's shell has
provisions for changes in prices. For example, there could be
a fee schedule so that copies made after the passage of time
will require lower fees to be paid to the distributor. Alternatively, the distributor could employ a "best-price" billing
option, using any algorithm he chooses to determine the fee
up to the maximum specified in the shell.
Fees for Reuse
In this scenario, a first creator creates a work. It is
distributed by a first distributor and purchased by a second
creator. The second creator extracts a portion of the work
and embeds in it a new work distributed by a second
10
15
20
25
30
35
40
45
50
55
60
65
Limited Reuse
In this scenario, several first creators create works. A
second creator makes a selection of these, publishing a
collection made up of the parts together with some new
interstitial material. (For example, the digital work could be
a selection of music or a selection of readings.) The second
creator wants to continue to allow some of the selected
works to be extractable, but not the interstitial material.
This scenario deals with fine grained control of the rights
and fees for reuse.
This scenario is performed as follows:
The first creators create their original works. If they grant
extraction and embedding rights, then the second creator can
include them in a larger collected work. The second creator
creates the interstitial material. He does grant an Extract
right on the interstitial material. He grants Extract rights on
a subset of the reused material. A consumer of the collection
can only extract portions that have that right. Fees are
automatically collected for all parts of the collection.
Commercial Libraries
Commercial libraries buy works with the right to loan.
They limit the loan period and charge their own fees for use.
This scenario deals with fees for loaning rather than fees for
making copies. The fees are collected by the same automatic
mechanisms.
The mechanisms are the same as previous scenarios
except that the fees are associated with the Loan usage right
rather than the Copy usage right.
Demo Versions
A creator believes that if people try his work that they will
want to buy it or use it. Consumers of his work can copy the
work for free, and play (or execute) a limited version of the
work for free, and can play or use the full featured version
for a fee.
This scenario deals with fees for loaning rather than fees
for making copies. The fees are collected by the same
automatic mechanisms.
This scenario is performed as follows:
The creator creates a digital work and grants various rights
and fees. The creator grants Copy and Embed rights without
a fee, in order to ensure widespread distribution of the work.
Another of the rights is a limited play right with little or no
fee attached. For example, this right may be for playing only
a portion of the work. The play right can have various
restrictions on its use. It could have a ticket that limits the
number of times it is used. It could have internal restrictions
that limit its functionality. It could have time restrictions that
invalidate the right after a period of time or a period of use.
Different fees could be associated with other versions of the
Play right.
Case 2:13-cv-01112 Document 1-7 Filed 12/18/13 Page 41 of 45 PageID #: 268
US 7,269,576 B2
47
48
Upgrading a Digital Work with a Vendor
A consumer buys a digital work together with an agreement that he can upgrade to a new version at a later date for
a modest fee, much less than the usual purchase price. When
the new version becomes available, he goes to a qualified
vendor to make the transaction.
This scenario deals with a common situation in computer
software. It shows how a purchase may include future
"rights." Two important features of the scenario are that the
transaction must take place at a qualified vendor, and that the
transaction can be done only once per copy of the digital
work purchased.
This scenario is performed as follows:
The creator creates a digital work, an upgrade ticket, and
a distribution license. The upgrade ticket uses the a generic
ticket agent that comes with repositories. As usual, the
distribution license does not have Copy or Transfer rights.
He distributes a bundled copies of the work and the ticket to
his distributors as well as distribution licenses.
The distributor sells the old bundled work and ticket to
customers.
The customer extracts the work and the ticket. He uses the
work according to the agreements until the new version
becomes available.
When the new work is ready, the creator gives it to
distributors. The new work has a free right to copy from a
distributor if a ticket is available.
The consumer goes to distributors and arranges to copy
the work. The transaction offers the ticket. The distributor's
repository punches the ticket and copies the new version to
the consumers repository.
The consumer can now use the new version of the work.
This scenario is performed as follows:
The creator sells a work together with limited printing
rights. The printing rights specify the kind of printer (e.g., a
kind of cassette recorder or a kind of desktop paper printer)
and also the kind of ticket required. The creator either
bundles a limited number of tickets or sells them separately.
If the tickets use the generic ticket agent, the consumer with
the tickets can exercise the right at his convenience.
Distributed Upgrading of Digital Works
A consumer buys a digital work together with an agreement that he can upgrade to a new version at a later date for
a modest fee, much less than the usual purchase price. When
the new version becomes available, he goes to anyone who
has the upgraded version and makes the transaction.
This scenario is like the previous one in that the transaction can only be done once per copy of the digital work
purchased, but the transaction can be accomplished without
the need to connect to a licensed vendor.
This scenario is similar to the previous one except that the
Copy right on the new work does not require a distribution
license. The consumer can upgrade from any repository
having the new version. He cannot upgrade more than once
because the ticket cannot work after it has been punched. If
desired, the repository can record the upgrade transaction by
posting a zero cost bill to alert the creator that the upgrade
has taken place.
Limited Printing
A consumer buys a digital work and wants to make a few
ephemeral copies. For example, he may want to print out a
paper copy of part of a digital newspaper, or he may want to
make a (first generation) analog cassette tape for playing in
his car. He buys the digital work together with a ticket
required for printing rights.
This scenario is like the common practice of people
making cassette tapes to play in their car. If a publisher
permits the making of cassette tapes, there is nothing to
prevent a consumer from further copying the tapes. However, since the tapes are "analog copies," there is a noticeable quality loss with subsequent generations. The new
contribution of the present invention is the use of tickets in
the access controls for the making of the analog copies.
10
15
20
25
30
35
40
45
50
55
60
65
Demand Publishing
Professors in a business school want to put together
course books of readings selected from scenario studies
from various sources. The bookstore wants to be able to print
the books from digital masters, without negotiating for and
waiting for approval of printing of each of the scenarios. The
copyright holders of the scenarios want to be sure that they
are paid for every copy of their work that is printed.
On many college campuses, the hassle of obtaining copy
clearances in a timely way has greatly reduced the viability
of preparing course books. Print shops have become much
more cautious about copying works in the absence of
documented permission.
Demand Publishing is performed as follows: the creator
sells a work together with printing rights for a fee. There can
be rights to copy (distribute) the work between bookstore
repositories, with or without fee. The printing rights specify
the kind of printer. Whenever a bookstore prints one of the
works (either standalone or embedded in a collection), the
fee is credited to the creator automatically. To discourage
unauthorized copying of the print outs, it would be possible
for the printer to print tracer messages discretely on the
pages identifying the printing transaction, the copy number,
and any other identifying information. The tracer information could be secretly embedded in the text itself (encoded
in the grey scale) or hidden in some other way.
Metered Use and Multiple Price Packages
A consumer does not know what music to purchase until
he decides whether he likes it. He would like to be able to
take it home and listen to it, and then decide whether to
purchase. Furthermore, he would like the flexibility of
paying less if he listens to it very infrequently.
This scenario just uses the capability of the approach to
have multiple versions of a right on a digital work. Each
version of the right has its own billing scheme. In this
scenario, the creator of the work can offer the Copy right
without fee, and defer billing to the exercise of the Play
right. One version of the play right would allow a limited
performance without fee-a right to "demo". Another version of the right could have a metered rate, of say $0.25 per
hour of play. Another version could have a fee of $15.00 for
the first play, but no fee for further playing. When the
consumer exercises a play right, he specifies which version
of the right is being selected and is billed accordingly.
Fees for Font Usage
A designer of type fonts invests several months in the
design of special fonts. The most common way of obtaining
revenue for this work is to sell copies of the fonts to
publishers for unlimited use over unlimited periods of time.
A font designer would like to charge a rate that reflects the
amount that the font is used.
This scenario is performed as follows: the font designer
creates a font as a digital work. He creates versions of the
Play right that bill either for metered use or "per-use". Each
version of the play right would require that the player (a
print layout program) be of an approved category. The font
designer assigns appropriate fees to exercise the Copy right.
Case 2:13-cv-01112 Document 1-7 Filed 12/18/13 Page 42 of 45 PageID #: 269
US 7,269,576 B2
49
50
When a publisher client wants to use a font, he includes it
as input to a layout program, and is billed automatically for
its use. In this way, a publisher who makes little use of a font
pays less than one who uses it a lot.
usage rights, it is possible to have rights that expire and to
have rights whose fee depends on various conditions. What
is needed is a means to check rights and conditions at the
time that printing is actually done.
This scenario is performed as follows: A printing repository is a repository with the usual repository characteristics
plus the hardware and software to enable printing. Suppose
that a user logs into a home repository and wants to spool
print jobs for a digital work at a remote printing repository.
The user interface for this could treat this as a request to
"spool" prints. Underneath this "spooling" request, however, are standard rights and requests. To support such
requests, the creator of the work provides a Copy right,
which can be used to copy the work to a printing repository.
In the default case, this Copy right would have no fees
associated for making the copy. However, the Next-Set-OfRights for the copy would only include the Print rights, with
the usual fees for each variation of printing. This version of
the Copy right could be called the "print spooling" version
of the Copy right. The user's "spool request" is implemented
as a Copy transaction to put a copy of the work on the
printing repository, followed by Print transactions to create
the prints of the work. In this way, the user is only billed for
printing that is actually done. Furthermore, the rights, conditions and fees for printing the work are determined when
the work is about to be printed.
Thus, a system for enforcing the usage rights of digital
works is disclosed. While the embodiments disclosed herein
are preferred, it will be appreciate from this teaching that
various alternative, modifications, variations or improvements therein may be made by those skilled in the art, which
are intended to be encompassed by the following claims.
Rational Database Usage Charges
Online information retrieval services typically charge for
access in a way that most clients find unpredictable and
uncorrelated to value or information use. The fee depends on
which databases are open, dial-up connect time, how long
the searches require, and which articles are printed out.
There are no provisions for extracting articles or photographs, no method for paying to reuse information in new
works, no distinction between having the terminal sit idly
versus actively searching for data, no distinction between
reading articles on the screen and doing nothing, and higher
rates per search when the centralized facility is busy and
slow servicing other clients. Articles can not be offloaded to
the client's machine for off-site search and printing. To offer
such billing or the expanded services, the service company
would need a secure way to account for and bill for how
information is used.
This scenario is performed as follows:
The information service bundles its database as files in a
repository. The information services company assigns different fees for different rights on the information files. For
example, there could be a fee for copying a search database
or a source file and a different fee for printing. These fees
would be in addition to fees assigned by the original creator
for the services. The fees for using information would be
different for using them on the information service company's computers or the client's computers. This billing distinction would be controlled by having different versions of
the rights, where the version for use on the service company's computer requires a digital certificate held locally. Fees
for copying or printing files would be handled in the usual
way, by assigning fees to exercising those rights. The
distinction between searching and viewing information
would be made by having different "players" for the different functions. This distinction would be maintained on the
client's computers as well as the service computers. Articles
could be extracted for reuse under the control of Extract and
Embed rights. Thus, if a client extracts part of an article or
photograph, and then sells copies of a new digital work
incorporating it, fees could automatically be collected both
by the information service and earlier creators and distributors of the digital work. In this way, the information retrieval
service could both offer a wider selection of services and
billing that more accurately reflects the client's use of the
information.
Print Spooling with Rights
In the simplest scenario, when a user wants to print a
digital document he issues a print command to the user
interface. If the document has the appropriate rights and the
conditions are satisfied, the user agrees to the fee and the
document is printed. In other cases, the printer may be on a
remote repository and it is convenient to spool the printing
to a later time. This leads to several issues. The user
requesting the printing wants to be sure that he is not billed
for the printing until the document is actually printed.
Restated, if he is billed at the time the print job is spooled
but the job is canceled before printing is done, he does not
want to pay. Another issue is that when spooling is permitted, there are now two times at which rights, conditions and
fees could be checked: the time at which a print job is
spooled and the time at which a print is made. As with all
10
15
20
25
30
APPENDIX A
35
Glossary
Authorization Repository:
40
45
50
A special type of repository which provides an authorization
service. An authorization may be specified by a usage right.
The authorization must be obtained before the right may be
exercised.
Billing Clearinghouse:
A financial institution or the like whose purpose is to
reconcile billing information received from credit servers.
The billing clearinghouse may generate bills to users or
alternatively, credit and debit accounts involved in the
commercial transactions.
Billing Transactions:
The protocol used by which a repository reports billing
information to a credit server.
55
Clearinghouse Transactions:
The protocol used between a credit server and a clearinghouse.
60
Composite Digital Work:
A digital work comprised of distinguishable parts. Each of
the distinguishable parts is itself a digital work which have
have usage rights attached.
65
Content:
The digital information (i.e. raw bits) representing a digital
work.
Case 2:13-cv-01112 Document 1-7 Filed 12/18/13 Page 43 of 45 PageID #: 270
US 7,269,576 B2
51
52
Copy Owner:
Repository:
A term which refers to the party who owns a digital work
stored in a repository. In the typical case, this party has
purchased various rights to the document for printing, viewing, transferring, or other specific uses.
Conceptually a set of functional specifications defining core
functionality in the support of usage rights. A repository is
a trusted system in that it maintains physical, communications and behavioral integrity.
Creator:
Requester Mode:
A term which refers to a party who produces a digital work.
A mode of a repository where it is requesting access to a
digital work.
Credit Server:
A device which collects and reports billing information for
a repository. In many implementations, this could be built as
part of a repository. It requires a means for periodically
communicating with a billing clearinghouse.
10
Revenue Owners:
15
A term which refers to the parties that maintain an interest
in collecting fees for document use or who stand to lose
revenue if illegitimate copies of the digital work are made.
Description Tree:
Server Mode:
A structure which describes the location of content and the
usage rights and usage fees for a digital work. A description
tree is comprised of description blocks. Each description
block corresponds to a digital work or to an interest (typically a revenue bearing interest) in a digital work.
A mode of a repository where it is processing an incoming
request to access a digital work.
20
Digital Work (Work):
Any encapsulated digital information. Such digital information may represent music, a magazine or book, or a multimedia composition. Usage rights and fees are attached to the
digital work.
Distributor:
A term which refers to a party who legitimately obtains a
copy of a digital work and offers it for sale.
Identification (Digital) Certificate:
A signed digital message that attests to the identity of the
possessor. Typically, digital certificates are encrypted in the
private key of a well-known master repository.
Master Repository:
A special type of repository which issues identification
certificates and distributes lists of repositories whose integrity have been compromised and which should be denied
access to digital works (referred to as repository "hotlists".)
25
Transactions:
A term used to refer to the protocols by which repositories
communicate.
30
Usage Rights:
35
45
50
55
Rendering Repository:
A special type of repository which is typically coupled to a
rendering system. The rendering repository will typically be
embodied within the secure boundaries of a rendering systern.
60
Rendering System:
The combination of a rendering repository and a rendering
device. Examples of a rendering systems include printing
systems, display systems, general purpose computer systems, video systems or audio systems.
A language for defining the manner in which a digital work
may be used or distributed, as well as any conditions on
which use or distribution is premised.
Usage Transactions:
40
Registration Transactions:
The protocol used between repositories to establish a trusted
sesswn.
Usage Fees:
A fee charged to a requester for access to a digital work.
Usage fees are specified within the usage rights language.
Public Key Encryption:
An encryption technique used for secure transmission of
messages on a communication channel. Key pairs are used
for the encryption and decryption of messages. Typically
one key is referred to as the public key and the other is the
private key. The keys are inverses of each other from the
perspective of encryption. Restated, a digital work that is
encrypted by one key in the pair can be decrypted only by
the other.
Shell Description Block:
A special type of description block designating an interest in
a digital work, but which does not add content. This will
typically be added by a distributor of a digital work to add
their fees.
65
A set of protocols by which repositories communicate in the
exercise of a usage rights. Each usage right has it's own
transaction steps.
What is claimed is:
1. An apparatus for rendering digital content in accordance with rights that are enforced by the apparatus, said
apparatus comprising:
a rendering engine configured to render digital content;
a storage for storing the digital content;
means for requesting use of the digital content stored in
the storage; and
a repository coupled to the rendering eng