U.S. patent application number 10/482918 was filed with the patent office on 2004-12-09 for digital rights management in a mobile communications environment.
Invention is credited to Alve, Jukka, Asokan, Nadarajah, Durand, Julian, Ekberg, Jan-Erik, Gustafsson, Patrik, Honglang, Zhang, Hurst, Leon, Kontio, Markku, Kumar, Ashwini, Lahteenmaki, Mika, Sipponen, Juha-Pekka, Stenman, Jorma, Teinila, Jaakku, Ylitalo, Tapio.
Application Number | 20040249768 10/482918 |
Document ID | / |
Family ID | 26789646 |
Filed Date | 2004-12-09 |
United States Patent
Application |
20040249768 |
Kind Code |
A1 |
Kontio, Markku ; et
al. |
December 9, 2004 |
Digital rights management in a mobile communications
environment
Abstract
The invention provides a method, system, and computer program
product to control the access, copying, and/or transfer of a
digital asset by mobile, wireless devices using a digital voucher.
The digital voucher references a primary content that contains all
of the expression for that particular asset and a secondary content
that contains information that can be distilled out as a preview.
The information in the primary content can be limited to a
specified duration or a specific number of viewings. The author,
owner, or possessor of the digital asset specifies the terms and
conditions for distribution of the digital asset. The digital
voucher authorizes the mobile, wireless device to access a
specified primary or secondary content that may be located
elsewhere in the network. The mobile, wireless device can download
a copy of portions or all of the content depending on the terms
specified in the voucher.
Inventors: |
Kontio, Markku; (Palojoki,
FI) ; Honglang, Zhang; (Andover, MA) ;
Gustafsson, Patrik; (Espoo, FI) ; Durand, Julian;
(San Diego, CA) ; Asokan, Nadarajah; (Espoo,
FI) ; Ekberg, Jan-Erik; (Helsinki, FI) ;
Stenman, Jorma; (Helsinki, FI) ; Teinila, Jaakku;
(Espoo, FI) ; Lahteenmaki, Mika; (Tampere, FI)
; Alve, Jukka; (Helsinki, FI) ; Kumar,
Ashwini; (Woburn, MA) ; Hurst, Leon;
(Helsinki, FI) ; Sipponen, Juha-Pekka; (Espoo,
FI) ; Ylitalo, Tapio; (Espoo, FI) |
Correspondence
Address: |
MORGAN & FINNEGAN, L.L.P.
3 WORLD FINANCIAL CENTER
NEW YORK
NY
10281-2101
US
|
Family ID: |
26789646 |
Appl. No.: |
10/482918 |
Filed: |
July 25, 2004 |
PCT Filed: |
July 3, 2002 |
PCT NO: |
PCT/IB02/02591 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60303157 |
Jul 6, 2001 |
|
|
|
Current U.S.
Class: |
705/65 |
Current CPC
Class: |
H04W 12/03 20210101;
H04L 63/12 20130101; G06F 2221/0742 20130101; H04L 2463/101
20130101; H04L 63/0823 20130101; G06F 2221/2137 20130101; G06Q
20/367 20130101; H04L 2209/603 20130101; G06F 21/10 20130101; H04L
9/0894 20130101; H04L 2209/80 20130101; G06F 2221/2135 20130101;
H04L 2209/56 20130101; G06F 2221/0766 20130101; H04L 63/0428
20130101; H04L 9/0838 20130101; H04L 2463/102 20130101; G06Q
20/3674 20130101 |
Class at
Publication: |
705/065 |
International
Class: |
G06F 017/60 |
Foreign Application Data
Date |
Code |
Application Number |
Mar 12, 2002 |
US |
10095062 |
Claims
1-73. (Canceled)
74. A method for distribution of a content item by sharing access
to the content item comprising: encrypting the content item with a
first encryption key; encrypting the first encryption key with at
least one second encryption key to create at least one encrypted
first encryption key; creating a voucher for expressing usage
rights associated with the content item; storing said at least one
encrypted first encryption key in the voucher; associating the
voucher with the content item, wherein the content item can be
accessed by a device having at least one decryption key for
decrypting at least one of said at least one encrypted first
encryption key.
75. The method of claim 74, wherein the first encryption key is
randomly chosen.
76. The method of claim 74, wherein said at least one second
encryption key is related to a device identifier of the device.
77. The method of claim 74, wherein said at least one second
encryption key is related to a user identifier associated with the
device.
78. The method of claim 74, wherein said at least one second
encryption key is related to a media identifier carrying the
content.
79. The method of claim 74, wherein said at least one second
encryption key is a public key of the device.
80. The method of claim 74, wherein said at least one second
encryption key is a public key related to a user of the device.
81. The method of claim 74, wherein said at least one second
encryption key is a public key associated with the media carrying
the content.
82. The method of claim 74, wherein the content item is stored on a
data carrying media.
83. The method of claim 74, wherein the device is a rendering
device.
84. The method of claim 74, wherein the device is a storing
device.
85. A device for rendering a content item comprising: means for
encrypting the content item with a first encryption key; means for
encrypting the first encrypting key with at least one second
encryption key to create at least one encrypted first encryption
key; means for associating said at least one encrypted first
encryption key with the content item; means for receiving the
content item and said at least one encrypted first encryption key;
means for storing the content item; means for storing said at least
one encrypted first encryption key; means for storing at least one
decryption key for decrypting said at least one encrypted first
encryption key; means for decrypting said at least one encrypted
first encryption key with said at least one decryption key; means
for decrypting the content item with the decrypted first encryption
key; means for rendering the decrypted content item.
86. The device of claim 85, further comprising: means for selecting
one of the stored decryption keys.
87. The device of claim 85, wherein at least one of said at least
one second encryption key is a public key of the rendering device,
and wherein the stored decryption key is a corresponding private
key of the rendering device.
88. The device of claim 85, wherein said at least one second
encryption key is related to a device identifier of the rendering
device.
89. The device of claim 85, wherein said at least one second
encryption key is related to a user identifier associated with the
rendering device.
90. The device of claim 85, wherein said at least one second
encryption key is related to a media identifier carrying the
encrypted content.
91. The device of claim 85, wherein said at least one encrypted
first encryption key is stored in a voucher associated with the
content item.
92. A device for rendering an encrypted content item comprising:
means for receiving the encrypted content item and an encryption
key associated with the encrypted content item; means for storing
the encrypted content item; means for storing the encryption key
associated with the encrypted content item; means for storing at
least one decryption key for decrypting the encryption key
associated with the encrypted content item; means for decrypting
the encryption key associated with the encrypted content item with
said at least one decryption key; means for decrypting the content
item with said decrypted content encryption key; means for
rendering the decrypted content.
93. The device of claim 92, further comprising: means for selecting
said at least one decryption key.
94. The device of claim 92, wherein said at least one decryption
key includes a decryption key relating to a device identifier, a
decryption key relating to a user identifier associated with the
device, a decryption key relating to a media identifier carrying
the content item, a private key associated with the device, a
private key associated with the user of the device, or a private
key associated with the media carrying the encrypted content.
95. The device of claim 94, wherein said at least one decryption
key are tried in sequence for decrypting the encrypted content
encryption key.
96-142. (Canceled)
Description
CROSS-REFERENCE TO A RELATED APPLICATION
[0001] This application for letters patent claims priority to and
incorporates by reference the provisional application for letters
patent Ser. No. 60/303,157 titled "A Method, System, and Computer
Program Product for Controlling the Distribution of a Digital Asset
in a Mobile Environment" and filed in the United States Patent and
Trademark Office on Jul. 6, 2001. This application for letters
patent is a continuation of and incorporates by reference utility
application for letters patent Ser. No. 10/095,062 titled "Digital
Rights Management in a Mobile Communications Environment" and filed
in the United States Patent and Trademark Office on Mar. 12, 2002.
This application for letters patent is related to and incorporates
by reference provisional application for letters patent Ser. No.
60/303,686 titled "Smart Content Object" and filed in the United
States Patent and Trademark Office on Jul. 6, 2001.
FIELD OF THE INVENTION
[0002] A method, system, and computer program product are disclosed
for controlling the distribution of digital assets in
communications networks. In particular, the method, system, and
computer program product manages the lifecycle of a digital asset
and the property rights held by the creator and owner of the
digital asset in a mobile, wireless environment.
BACKGROUND OF THE INVENTION
[0003] Digital technology dramatically impacts the creation,
distribution, sale, marketing, and consumption of copyrighted
digital content. Recent developments indicate that producers of
digital content are under pressure and have a desire to profit from
these new developments and reduce their vulnerability to the risk.
The risks are more obvious to content producers than the potential
benefits of the new technologies.
[0004] Copyright protection systems of the pre-digital age
consisted of legal mechanisms to prosecute individuals and groups
that ran large-scale illegal reproduction facilities for profit.
Since intellectual property pirates in the predigital age needed
physical assets to reproduce the physical media of the books,
music, or video, they were subject to traditional law enforcement
techniques. The added complications imposed by distribution of
these contraband copies made these pirates even more vulnerable to
detection. From the consumer's perspective, the illegal copies
produced by these pirates were less interesting because quality
suffered and the copies were not always promptly available as
legitimate copies.
[0005] The digital age introduced new risks because flawless copies
are now infinitely reproducible and may be transmitted instantly
anywhere in the world. There has been a shift from a paradigm where
a large number of individuals made a few copies to one where
relatively few individuals can make many copies.
[0006] When cassette tapes were first introduced, record companies
had similar concerns as demonstrated by the record jackets printed
in the early 1980s including the slogan "Some Taping Is Killing
Music". Eventually this lead to cassette tape manufacturers paying
mandatory licensing fees to the holder of the property rights to
the work.
[0007] Content producers are rightfully concerned with this new
capacity to cheat them of a fair return on their intellectual
property and, therefore, have been reluctant to take advantage of
digital commerce opportunities. Yet digital commerce offers the
potential to increase earnings while cutting the high overhead
costs of production, distribution, warehousing their goods while
presenting new business opportunities. It is believed that if
content producers were sufficiently confident in their ability to
protect their assets in digital form, they would gladly take part
in such a system.
[0008] Legal and regulatory means exist to protect digital content,
however a deterrent is necessary to make the illegal copying and
distribution of copyrighted content difficult and traceable. For
this reason, the deployment of a trusted end-to-end solution for
the management of digital rights is a necessary precursor to
digital production, dissemination and consumption of copyrighted
content.
[0009] Digital Rights Management (DRM) involves the description,
layering, analysis, valuation, trading, and monitoring of an
owner's property rights to an asset. DRM covers the management of
the digital rights to the physical manifestation of a work (e.g., a
textbook) or the digital manifestation of a work (e.g., a Web
page). DRM also covers the management of an asset whether the asset
has a tangible or an intangible value. Current DRM technologies
include languages for describing the terms and conditions for an
asset, tracking asset usage by enforcing controlled environments or
encoded asset manifestations, and closed architectures for the
overall management of the digital rights.
[0010] The Open Digital Rights Language (ODRL) provides the
semantics for implementing a DRM architecture in an open or trusted
computing environment. ODRL defines a standard vocabulary for
expressing the terms and conditions over an asset. ODRL covers a
core set of semantics for these purposes including the
identification of the property rights to the work and the
expression of permissible uses for manifestations of a protected
asset. Rights can be specified for a specific asset manifestation
or format or could be applied to a range of manifestations of the
asset. ODRL does not enforce or mandate any policy for DRM, but
provides the mechanisms to express such a policy. ODRL does not,
however, assume the existence of mechanisms to achieve a secure
architecture. ODRL complements existing rights management standards
by providing digital equivalents and supports an expandable range
of new services that can be afforded by the digital nature of the
assets in the Web environment. In the physical environment, ODRL
can be used to enable machine-based processing for DRM. The web
site "http://odrl.net" contains electronic ODRL resources including
the ODRL Specification Format version 1.0, ODRL Expression Language
version 1.0, and ODRL Data Dictionary version 1.0.
[0011] The Extensible Markup Language (XML) is a standard for
exchanging data and metadata electronically. Metadata is data that
describes data. For example, the term "author" is metadata that
describes the data "William Shakespeare". XML is an outgrowth of
the Standard Generalized Markup Language (SGML) that allows the
author of an XML document to separate the logical content of the
document from the presentation of the content. An author of an XML
document adds metadata to a document as hypertext transfer protocol
(HTTP) tags in the document. A document type definitions (DTD) file
is the mechanism that adds shared content to the XML document. The
web site "http://www.w3.org/XML/1999/XML-in-10-points" provides an
overview of XML.
[0012] Extensible Rights Markup Language (XrML) is an XML
conforming language definition that specifies rights, fees, and
conditions for using digital content. XrML also describes message
integrity and entity authentication rules. XrML supports commerce
in digital content such as publishing and selling electronic books,
digital movies, digital music, interactive games, and computer
software. In addition, XrML supports the specification of access
and use controls for secure digital documents in cases where
financial exchange is not part of the terms of use. The web site
"http://www.xrml.org/faq.asp" provides an overview of XrML.
[0013] Digital communications networks can be categorized in terms
of their geographic coverage, their transmission media, their
protocols, their transmission speeds, the types of equipment that
they interconnect, and other criteria. An example of geographic
coverage categories includes wide area networks (WANs),
metropolitan area networks (MANs), local area networks (LANs), and
personal area networks (PANs). An example of transmission media
categories includes fixed station wireline networks, mobile
wireless networks, and hybrid combinations of fixed station
wireline networks communicating through wireless access points with
wireless networks. There are many digital wireless, wide area
network architectures. Most of them are connected to the public
switched telephone network (PSTN) to provide access to wireline
telephones and digital computers. A short list includes Global
System for Mobile Communication (GSM), IS-136 TDMA-based Digital
Advanced Mobile Phone Service (DAMPS), Personal Digital Cellular
(PDC), IS-95 CDMA-based cdmaOne System, General Packet Radio
Service (GPRS) and broadband wireless systems such as W-CDMA, and
Broadband GPRS. For more information on these digital wireless,
wide area network architectures, see the book by Yi-Bing Lin, et
al. entitled Wireless and Mobile Network Architectures, John Wiley
& Sons, 2001.
[0014] Wide area networks can include communications satellite
links that interconnect nation-wide digital networks located on
different continents. Nation-wide digital networks typically
include backbone networks, regional distribution hubs, and routers,
which interconnect access subnetworks serving local routers,
servers, and service providers. The Internet is a familiar example
of a wide area network. For more information on the Internet as a
wide area network, see the book by Daniel Minoli et al. entitled
Internet Architectures, John Wiley & Sons, 1999.
[0015] At the other end of the range for geographic coverage are
short-range wireless systems. Short-range wireless systems have a
typical range of one hundred meters or less. They often combine
with systems wired to the Internet to provide communication over
long distances. The category of short-range wireless systems
include both a wireless personal area network (PAN) and a wireless
local area network (LAN). Both of these networks have the common
feature of operating in unlicensed portions of the radio spectrum,
usually either in the 2.4 GHz Industrial, Scientific, and Medical
(ISM) band or the 5 GHz Unlicensed-National Information
Infrastructure (U-NII) band. Wireless personal area networks use
low cost, low power wireless devices that have a typical range of
ten meters. The best-known example of wireless personal area
network technology is the Bluetooth Standard, which operates in the
2.4 GHz ISM band. It provides a peak air link speed of one Mbps and
a power consumption low enough for use in personal, portable
electronics such as PDAs and mobile phones. Wireless local area
networks generally operate at higher peak speeds of from 10 to 100
Mbps and have a longer range, which requires greater power
consumption. Wireless local area networks are typically used as
wireless links from portable laptop computers to a wired LAN, via
an access point (AP). Examples of wireless local area network
technology include the IEEE 802.11 Wireless LAN Standard and the
HIPERLAN Standard, which operates in the 5 GHz U-NII band. For more
information on wireless LANs, see the book by Jim Geier entitled
Wireless LANs, Macmillan Technical Publishing, 1999.
[0016] An ad hoc network is a short range wireless system composed
primarily of mobile wireless devices, which associate together for
a relatively short time to carry out a common purpose. A temporary
network such as this is called a "piconet" in the Bluetooth
Standard, an "independent basic service set" (IBSS) in the IEEE
802.11 Wireless LAN Standard, a "subnet" in the HIPERLAN Standard,
and generally a radio cell or a "micro-cell" in other wireless LAN
technologies. Ad hoc networks have the common property of being an
arbitrary collection of wireless devices, which are physically
close enough to be able to communicate and which are exchanging
information on a regular basis. The networks can be constructed
quickly and without much planning. Members of the ad hoc network
join and leave as they move into and out of the range of each
other. Most ad hoc networks operate over unlicensed radio
frequencies at speeds of from one to fifty-four Mbps using carrier
sense protocols to share the radio spectrum. The distance over
which they can communicate ranges from ten meters for Bluetooth
piconets to over one hundred meters for wireless LAN micro-cells in
an open environment. Ad hoc networks consist primarily of mobile
wireless devices, but can also include one or more access points,
which are stationary wireless devices operating as a stand-alone
server or connected as gateways to other networks.
[0017] Bluetooth is a short-range radio network, originally
intended as a cable replacement. It can be used to create ad hoc
networks of up to eight devices operating together. The Bluetooth
Special Interest Group, "Specification Of The Bluetooth System",
Version 1.0B, Volumes 1 and 2, December 1999, describes the
principles of Bluetooth device operation and communication
protocols. The devices operate in the 2.4 GHz radio band reserved
for general use by Industrial, Scientific, and Medical (ISM)
applications. Bluetooth devices are designed to find other
Bluetooth devices within their ten-meter radio communications range
and to discover what services they offer, using a service discovery
protocol (SDP). The SDP searching function relies on links being
established between the requesting Bluetooth device in a client
role and the responding Bluetooth device in a server role. Once a
link has been established, it can be used to find out about
services in the responding Bluetooth device and how to connect to
them.
[0018] A connection between two Bluetooth devices is initiated by
an inquiring device sending out an inquiry message searching for
other devices in its vicinity. Any other Bluetooth device that is
listening by means of conducting an inquiry scan, will recognize
the inquiry message and respond. The inquiry response is a message
packet containing the responding device's Bluetooth Device Address
(BD_ADDR). A Bluetooth device address is a unique, 48-bit IEEE
address that is electronically engraved into each Bluetooth
device.
[0019] The inquiring device uses the information provided in the
inquiry response packet, to prepare and send a paging message to
the responding device. To establish a connection, the inquiring
device must enter the page state. In the page state, the inquiring
device will transmit initial paging messages to the responding
device using the access code and timing information acquired from
the inquiry response packet. The responding device must be in the
page scan state to allow the inquiring device to connect with it.
Once in the page scan state, the responding device will acknowledge
the initial paging messages and the inquiring device will send a
paging packet that provides the clock timing and access code of the
inquiring device to the responding device. The responding device
responds with a page acknowledgment packet. This enables the two
devices to form a connection and both devices transition into the
connection state. The inquiring device that has initiated the
connection assumes the role of a master device and the responding
device assumes the role of a slave device in a new ad hoc network
piconet.
[0020] Each piconet has one master device and up to seven slave
devices. All communication is directed between the master device
and each respective slave device. The master initiates an exchange
of data and the slave responds to the master. When two slave
devices are to communicate with each other, they must do so through
the master device. The master device maintains the piconet's
network clock and controls when each slave device can communicate
with the master device. Members of the ad hoc network piconet join
and leave as they move into and out of the range of the master
device. A piconet supports distributed activities, such as
collaborative work projects, collaborative games, multi-user
gateways to the Internet, and the like. A user's device that joins
a particular piconet does so to enable its user to participate in
the currently running collaborative activity.
[0021] A Bluetooth-enabled laptop computer can send information to
a Bluetooth-enabled printer in the next room. A Bluetooth-enabled
microwave oven can send a message to a Bluetooth-enabled mobile
phone announcing that the meal is ready. Bluetooth will become the
standard in mobile phones, PCs, laptops and other electronic
devices, enabling users to share information, synchronize data,
access the Internet, integrate with LANs or actuate
electromechanical devices, such as unlocking a car. A passenger can
use a laptop or handheld computer to compose an electronic mail
message while flying in an airplane and then, after landing, the
messages can be automatically forwarded to the Internet by
Bluetooth devices that are ubiquitously located around the airport
terminal. In another example, while waiting in an airport lounge,
the passenger can receive interesting duty-free offers directly on
the laptop or handheld computer or play multi-player games with
friends.
[0022] The IEEE 802.11 Wireless LAN Standard defines at least two
different physical (PHY) specifications and one common medium
access control (MAC) specification. The IEEE 802.11(a) Standard is
designed for either the 2.4 GHz ISM band or the 5 GHz U-NI1 band,
and uses orthogonal frequency division multiplexing (OFDM) to
deliver up to 54 Mbps data rates. The IEEE 802.11 (b) Standard is
designed for the 2.4 GHz ISM band and uses direct sequence spread
spectrum (DSSS) to deliver up to 11 Mbps data rates. The IEEE
802.11 Wireless LAN Standard describes two major components, the
mobile station and the fixed access point (AP). IEEE 802.11 ad hoc
networks have an independent configuration where the mobile
stations communicate directly with one another, without support
from a fixed access point. The IEEE 802.11 standard provides
wireless devices with service inquiry features similar to the
Bluetooth inquiry and scanning features. IEEE 802.11 ad hoc
networks support distributed activities similar those of a
Bluetooth piconet, except that they have ten times the
communications range.
[0023] In order for an IEEE 802.11 mobile station to communicate
with other mobile stations in an ad hoc network, it must first find
the stations. The process of finding another station is by
inquiring. Active inquiry requires the inquiring station to
transmit queries and invoke responses from other wireless stations
in an ad hoc network. In an active inquiry, the mobile station will
transmit a probe request frame. If there is an ad hoc network on
the same channel that matches the service set identity (SSID) in
the probe request frame, a station in that ad hoc network will
respond by sending a probe response frame to the inquiring station.
The probe response includes the information necessary for the
inquiring station to access a description of the ad hoc network.
The inquiring station will also process any other received probe
response and Beacon frames. Once the inquiring station has
processed any responses, or has decided there will be no responses,
it may change to another channel and repeat the process. At the
conclusion of the inquiry, the station has accumulated information
about the ad hoc networks in its vicinity. Once a station has
performed an inquiry that results in one or more ad hoc network
descriptions, the station may choose to join one of the ad hoc
networks. The IEEE 802.11 Wireless LAN Standard is published in
three parts as "IEEE 802.11-1999", "IEEE 802.11a-1999", and "IEEE
802.11b-1999". All three of these publications are available from
the IEEE, Inc. web site at
http://grouper.ieee.org/groups/802/11.
[0024] The HIPERLAN standard provides a wireless LAN with a high
data rate of up to 54 Mbps and a medium-range of 50 meters.
HIPERLAN wireless LANs provide multimedia distribution with video
quality of service (QoS), reserved spectrum, and good in-building
propagation. There are two HIPERLAN standards. HIPERLAN Type 1 is a
dynamic, priority driven channel access protocol similar to
wireless Ethernet. HIPERLAN Type 2 is a reserved channel access
protocol similar to a wireless version of asynchronous transfer
mode (ATM). Both HIPERLAN Type 1 and HIPERLAN Type 2 use dedicated
spectrum at 5 GHz. HIPERLAN Type 1 uses an advanced channel
equalizer to deal with intersymbol interference and signal
multipath. HIPERLAN Type 2 avoids these interference problems by
using orthogonal frequency division multiplex (OFDM) and a
frequency transform function. The HIPERLAN Type 2 specification
offers options for bit rates of 6, 16, 36, and 54 Mbps. The
physical layer adopts an OFDM multiple carrier scheme using 48
carrier frequencies per OFDM symbol. Each carrier may then be
modulated using binary phase shift keying (BPSK), quadrature phase
shift keying (QPSK), or quadrature amplitude modulation (QAM)
formats of 16-QAM or 64-QAM to provide different data rates. The
modulation schemes chosen for the higher bit rates achieve
throughput in the range 30-50 Mbps.
[0025] The HIPERLAN Type 1 is a dynamic, priority driven channel
access protocol that can form ad hoc networks of wireless devices.
HIPERLAN Type 1 ad hoc networks support distributed activities
similar those of the Bluetooth piconets and IEEE 802.11 independent
basic service sets (IBSS). The HIPERLAN Type 1 standard provides
wireless devices with service inquiry features similar to those of
the Bluetooth inquiry and scanning features and the IEEE 802.11
probe request and response features. An overview of the HIPERLAN
Type 1 principles of operation is provided in the publication
"HIPERLAN Type 1 Standard", ETSI ETS 300 652, WA2 December
1997.
[0026] HIPERLAN Type 2 is a reserved channel access protocol that
forms ad hoc networks. HIPERLAN Type 2 ad hoc networks support
distributed activities similar to those of the HIPERLAN Type 1 ad
hoc networks, Bluetooth piconets and IEEE 802.11 independent basic
service sets (IBSS). HIPERLAN Type 2 provides high speed radio
communication with typical data rates from 6 MHz to 54 Mbps. It
connects portable devices with broadband networks that are based on
IP, ATM and other technologies. Centralized mode is used to operate
HIPERLAN Type 2 as an access network via a fixed access point. In
addition a capability for direct link communication is provided.
This mode is used to operate HIPERLAN Type 2 as an ad hoc network
without relying on a cellular network infrastructure. In this case
a central controller (CC), which is dynamically selected among the
portable devices, provides the same level of QoS support as the
fixed access point. Restricted user mobility is supported within
the local service area. Wide area roaming mobility can also be
supported. An overview of the HIPERLAN Type 2 principles of
operation is provided in the Broadband Radio Access Networks
(BRAN), "HIPERLAN Type 2; System Overview", ETSI TR 101 683 VI.I.1
(2000-02) and a more detailed specification of its ad hoc network
architecture is described in "HIPERLAN Type 2, Data Link Control
(DLC) Layer; Part 4. Extension for Home Environment", ETSI TS 101
761-4 V1.2.1 (2000-12).
[0027] Other wireless standards support ad hoc networks. Examples
include the IEEE 802.15 Wireless Personal Area Network (WPAN)
standard, the Infrared Data Association (IRDA) standard, the
Digital Enhanced Cordless Telecommunications (DECT) standard, the
Shared Wireless Access Protocol (SWAP) standard, the Japanese 3rd
Generation (3G) wireless standard, and the Multimedia Mobile Access
Communication (MMAC) Systems standard of the Japanese Association
of Radio Industries and Businesses.
[0028] Thus, there is a need for a method, system, and computer
program product for integrating digital rights management into a
mobile computing environment. The mobile computing environment can
include any wireless wide area network such as a cellular network
or short range wireless system such as a wireless LAN or a wireless
personal area network. The method, system, and computer program
product disclosed herein would provide a light-weight and efficient
DRM architecture that can promote the growth of electronic commerce
in the mobile computing environment.
SUMMARY OF THE INVENTION
[0029] The memory size of mobile, wireless devices is small when
compared to that of fixed station computers and servers. To
accommodate the limited memory capacity in mobile devices, the
invention provides light-weight digital vouchers to represent
larger sized digital assets. The invention provides a method to
control the access, copying and/or transfer of a digital asset by
mobile, wireless devices using the digital vouchers. In this
manner, only content that is currently required in a mobile device
needs to be located there.
[0030] The totality of information constituting a digital asset is
its primary content, which contains all of the expression of its
author for that particular asset. The expression may be in the form
of text, graphics, sound, video, or other multimedia forms.
Portions of the information in the primary content can be distilled
out as a preview, such as a text abstract, a thumbnail view, a
sound bite, a video clip, executable code fragment, or the like,
which are generically referred to as secondary content. The
presentation of the information in the primary content can be
limited to a specified duration or a specific number of
viewings.
[0031] The author, owner, or possessor of the digital asset can
specify the terms and conditions for distribution of the primary
content and the secondary content. The principal methods of
distribution are by sharing access to the content, by duplicating a
copy of the content and transferring possession of the copy, and by
giving or transferring possession of the content, itself.
[0032] In accordance with the invention, distribution by sharing
access to the content is accomplished by a digital voucher that is
stored in the mobile, wireless device. The digital voucher
authorizes the mobile, wireless device to access to a specified
primary or secondary content that may be located elsewhere in the
network. The mobile, wireless device can download a copy of
portions or all of the content to be viewed, played, or executed,
depending on the terms specified in the voucher. The principles of
the invention apply even where the voucher and the content are
located in any other nodes in the network.
[0033] Further in accordance with the invention, distribution by
copying the whole content is accomplished by a digital voucher that
is stored in the mobile, wireless device. The digital voucher
authorizes the mobile, wireless device to cause the duplication of
the entire portion of a specified primary or secondary content
which may be located elsewhere in the network. The mobile, wireless
device can then download the duplicated copy of the content, based
on the terms specified in the voucher. The principles of the
invention apply even where the voucher and the content are located
in any other nodes in the network.
[0034] Still further in accordance with the invention, distribution
by giving or transferring possession of the content is accomplished
by a digital voucher that is stored in the mobile, wireless device.
The digital voucher authorizes the mobile, wireless device to cause
the transfer of possession of a specified primary or secondary
content, from a currently specified distributing computer to
receiving terminal. The digital voucher is sent from the mobile,
wireless device to a voucher server in the network, which
transforms the identity of the custodian specified in the voucher
from the distributing computer to the receiving terminal. The
receiving terminal can then download the content from the
distributing terminal, based on the terms specified in the voucher.
The principles of the invention apply even where the voucher and
the content are located in any other nodes in the network.
[0035] In one aspect of the invention, the method begins by storing
the primary content in a distributing computer. To control the
disposition of the content, the mobile, wireless device stores a
primary voucher and a secondary, preview voucher. The primary
voucher allows the user of the mobile, wireless device to control
the primary content in accordance with the terms and conditions
specified in the primary voucher. The primary voucher includes a
first pointer to the primary content and a reference to the
secondary voucher. The secondary voucher allows the user of the
mobile, wireless device to control the secondary content in
accordance with the terms and conditions specified in the secondary
voucher. The secondary voucher includes a second pointer to the
primary content. The secondary voucher can further include a second
reference to itself, allowing the secondary voucher to create a
duplicate of itself.
[0036] In accordance with the invention, when the user invokes an
access sharing operation in the mobile, wireless device, a primary
voucher that contains the access sharing authorization, uses the
first pointer therein to signal the distributing computer to allow
the mobile, wireless device to access the primary content therein,
based on the terms specified in the primary voucher. The method
uses the first reference in the primary voucher to access the
secondary voucher to use the second pointer therein to signal the
distributing computer to allow the mobile, wireless device to
access a secondary, preview content therein, based on the terms
specified in the secondary voucher.
[0037] Further in accordance with the invention, when the user
invokes a third party access sharing operation in the mobile,
wireless device, a primary voucher that contains the third party
access sharing authorization, uses the first pointer therein to
signal the distributing computer to issue a digital voucher to the
third party receiving device, based on the terms specified in the
primary voucher. The issued voucher authorizes the third party
device to access the primary content or the secondary content in
the distributing computer, based on the terms specified in the
secondary voucher.
[0038] Still further in accordance with the invention, when the
user invokes a copy operation in the mobile, wireless device, a
method controls the distribution of a copy of a primary content and
a secondary, preview content. The method begins by storing a
primary content and a secondary content in a distributing computer.
To control the disposition of the content, the mobile, wireless
device stores a primary voucher and a secondary voucher. The
primary voucher allows the user of the mobile, wireless device to
render the content multiple times, but does not allow the
duplication of the content. The primary voucher further includes a
first pointer to the primary content and a second pointer to the
secondary content, and further includes a first reference to the
secondary voucher. The secondary voucher in the mobile, wireless
device allows a preview of the content to be distributed to another
user. The secondary voucher includes a third pointer to the primary
content and a fourth pointer to the secondary content. The
secondary voucher can also include a second reference to itself,
allowing the secondary voucher to create a duplicate of itself.
[0039] In accordance with the invention, the user invokes a copy
operation in the mobile, wireless device, to access the primary
voucher and use the first pointer therein to signal the
distributing computer to duplicate the primary content as a primary
content copy and to transmit it to a receiving terminal. The method
uses the first reference in the primary voucher to access the
secondary voucher to use the third pointer therein to signal the
distributing computer to duplicate the secondary content as a
secondary content copy and to duplicate the secondary voucher as a
duplicate voucher and to transmit them to the receiving terminal.
Since the primary voucher does not allow the duplication of the
content, the invocation step causes the primary voucher to be reset
to a no-rights state in the mobile, wireless device. In this
manner, the copy operation results in the primary content copy, the
secondary content copy, and the duplicate voucher being resident in
the receiving terminal. The duplicate voucher includes pointers to
the primary content copy, the secondary content copy, and a
reference to itself, to allowing the duplicate voucher to create a
duplicate of itself.
[0040] In another aspect of the invention, a method controls the
giving of a preview copy of a digital asset to another in a mobile
environment. The method begins by storing a primary content in a
distributing computer. To control the disposition of the content,
the mobile, wireless device stores a primary voucher and a
secondary voucher. The primary voucher allows the user of the
mobile, wireless device to render the content multiple times, but
does not allow the duplication of the content. The primary voucher
includes a first pointer to the primary content, and further
includes a first reference, in a narrow element, to the secondary
voucher. The secondary voucher in the mobile, wireless device
allows a preview of the content to be distributed to another user.
The secondary voucher includes a second pointer to the primary
content. The secondary voucher further includes a second reference,
in a narrow element, to the secondary voucher allowing the
secondary voucher to create a duplicate of itself.
[0041] In accordance with the invention, the user invokes a give
operation in the mobile, wireless device, to send a copy of the
secondary voucher to a voucher server. The voucher server
recognizes the give operation and responds with a reference voucher
that includes an indication of no rights to the primary content.
The mobile, wireless device receives the reference voucher from the
voucher server. The mobile, wireless device then sends the
reference voucher to a receiving terminal. The receiving terminal
then sends a request to the voucher server, requesting a new
secondary voucher. The new secondary voucher confers the same
preview rights onto the receiving terminal are available to the
mobile, wireless device. Since the primary voucher does not allow
the duplication of the content, the invocation step causes the
primary voucher to be reset to a no-rights state in the mobile,
wireless device. Still further in accordance with the invention,
the receiving terminal can purchase a primary voucher from the
voucher server, to obtain the same rights to the primary content as
are possessed by the mobile, wireless device.
[0042] In another aspect of the invention, a method controls the
giving of a primary content digital asset to another in a mobile
environment. The method begins by storing a primary content in a
distributing computer. Since the memory of the mobile, wireless
device is much smaller than that of the distributing computer, only
that content that is currently required in the mobile, wireless
device is located there. To control the disposition of the content,
the mobile, wireless device stores a primary voucher and a
secondary voucher. The primary voucher allows the user of the
mobile, wireless device to render the content multiple times, but
does not allow the duplication of the content. The primary voucher
includes a first pointer to the primary content, and further
includes a first reference, in a narrow element, to the secondary
voucher. The secondary voucher in the mobile, wireless device
allows a preview of the content to be distributed to another user.
The secondary voucher includes a second pointer to the primary
content. The secondary voucher further includes a second reference,
in a narrow element, to the secondary voucher allowing the
secondary voucher to create a duplicate of itself.
[0043] In accordance with the invention, the user invokes a give
operation in the mobile, wireless device, to send a copy of the
primary voucher to a voucher server. This operation resets the
primary voucher to a no-rights state in the mobile, wireless
device. The voucher server recognizes the give operation and
responds with a reference voucher that includes an indication of no
rights to the primary content. The mobile, wireless device receives
the reference voucher from the voucher server. The mobile, wireless
device then sends the reference voucher to a receiving terminal.
The receiving terminal then sends a request to the voucher server,
requesting a new primary voucher. The new primary voucher confers
the same full rights onto the receiving terminal were previously
available to the mobile, wireless device.
[0044] Further in accordance with the invention, a method is
disclosed for controlling the transfer of dormant rights to digital
asset in a mobile environment. The method begins by storing a
digital asset content in a distributing computer in a network.
Then, in accordance with the invention, the method stores a voucher
in a first device in the network, the voucher including a pointer
to the content, use information specifying the type of use intended
for the content, restriction information limiting usage of the
content, and identity information identifying a second device in
the network. The restriction and identity information in the
voucher prevents the first device from using the content. However,
the first device can super-distribute the content by transferring
the voucher to the second device. There, the voucher permits the
second device to use the content, in response to the restriction
and identity information in the voucher. The voucher can also
include clearing house information which requires the second device
to report is use of the content to a clearinghouse computer in the
network. The clearinghouse information can include a name of the
clearinghouse, its public signature verification key, and a network
address where the use of the content can be reported.
[0045] Further in accordance with the invention, a method is
disclosed for deferring payment for a digital asset in a mobile
environment. The method begins by storing a digital asset content
in a distributing computer in a network. Then, in accordance with
the invention, the method registers a buyer device in the network,
with a clearinghouse computer in the network. The clearinghouse
sends to the buyer device a certificate including a signing key for
the buyer device and a charge authorization ticket that is valid
for a specified total purchase amount. The buyer device then sends
to a seller device in the network, a copy of the certificate and an
offer indication to pay a price to the seller device for the
content. The seller device verifies the validity of the certificate
as the offer of payment by the buyer device. The seller device then
sends to the buyer device a voucher including a pointer to the
content, use information specifying the type of use intended for
the content, and restriction information limiting usage of the
content. The restriction and use information in the voucher allows
the buyer device to use the content. The seller device then sends
to the clearinghouse, the offer indication by the buyer device, to
obtain compensation for the price of the content. In one
embodiment, the clearinghouse sends a bill to the buyer device to
collect the price. In another embodiment, the clearinghouse deducts
the price from a prepaid amount previously paid by the buyer
device. In still another embodiment, the clearinghouse adds the
price to a debt amount to be paid by the buyer device. In yet
another embodiment, the clearinghouse provides a bonus to the
seller device as the compensation.
[0046] Further in accordance with the invention, a method is
disclosed for controlling the transfer of dormant rights to digital
asset in a mobile environment. The method begins by storing a
digital asset content in a distributing computer in a network.
Then, in accordance with the invention, the method stores a voucher
in a first device in the network, the voucher including a pointer
to the content, use information specifying the type of use intended
for the content, restriction information limiting usage of the
content, identity information identifying a second device in the
network, and clearing house information specifying a first
clearinghouse. The first device is registered with second,
different clearinghouse. The clearinghouse information in the
voucher prevents the first device from using the content, because
the second clearinghouse does not match with the specification of
the first clearing house in the voucher. However, the first device
can super-distribute the content by transferring the voucher to the
second device. There, the voucher permits the second device to use
the content, in response to the clearing house information, because
the first clearinghouse matches with the specification of the first
clearing house in the voucher. The clearing house information in
the voucher can requiring the second device to report is use of the
content to the first clearinghouse computer in the network.
[0047] Further in accordance with the invention, a method is
disclosed for conducting transactions up to a limit, for
transferring rights to a digital asset in a mobile environment. The
method begins by storing a digital asset content in a distributing
computer in a network. Then, in accordance with the invention, the
method stores a content of a digital asset in a distributing
computer in a network. Then the method registers a seller device in
the network, with a clearinghouse computer in the network. The
clearinghouse then sends the seller device a seller's voucher from,
including a pointer to the content, use information specifying the
type of use intended for the content, restriction information
limiting usage of the content; and transaction information allowing
transactions up to a limit, for transferring rights to the content.
Thereafter, a buyer device in the network is registered with the
clearinghouse computer. The clearinghouse then sends the buyer
device a certificate including a signing key for the buyer device
and a charge authorization ticket that is valid for a specified
total purchase amount. Thereafter, the buyer device sends to the
seller device, a copy of the certificate and an offer indication to
pay a price to the seller device for the content. The seller device
verifies the validity of the certificate as the offer of payment by
the buyer device. After the verification, the seller sends the
buyer device a buyer's voucher including a pointer to the content,
use information specifying the type of use intended for the
content, and restriction information limiting usage of the content.
The restriction and use information in the buyer's voucher allows
the buyer device to use the content, in response to. The seller
device then sends to the clearinghouse, the offer indication by the
buyer device, to obtain compensation to the seller device for the
price of the content. The transaction information of the seller's
voucher prohibits the seller device from conducting further
transactions beyond the limit.
[0048] Further in accordance with the invention, a method is
disclosed for transferring rights to a digital asset that includes
preview copies that convey with the asset in a mobile environment.
The method begins by storing a primary content and a secondary
content of a digital asset in a distributing computer in a network.
Then the method registers a seller device in the network, with a
clearinghouse computer in the network. The clearinghouse then sends
the seller device a seller's primary voucher, including a pointer
to the primary content, use information specifying the type of use
intended for the primary content, restriction information limiting
usage of the primary content; transaction information allowing
transactions up to a primary limit, for transferring lights to the
primary content, and a reference to a seller's secondary voucher.
In addition, the clearinghouse then sends the seller device the
seller's secondary voucher from the clearinghouse, the secondary
voucher including a pointer to the secondary content, use
information specifying the type of use intended for the secondary
content, restriction information allowing a preview copy of the
content to be distributed to another user; and transaction
information allowing transactions up to a secondary limit, for
transferring a preview copy. Thereafter, a buyer device in the
network is registered with the clearinghouse computer. The
clearinghouse then sends the buyer device a certificate including a
signing key for the buyer device and a charge authorization ticket
that is valid for a specified total purchase amount. Thereafter,
the buyer device sends to the seller device, a copy of the
certificate and an offer indication to pay a price to the seller
device for the content. The seller device verifies the validity of
the certificate as the offer of payment by the buyer device. After
the verification, the seller sends the buyer device, a buyer's
primary voucher including a pointer to the primary content, use
information specifying the type of use intended for the primary
content, restriction information limiting usage of the primary
content, and a reference to a buyer's secondary voucher. In
addition, the seller sends the buyer device the buyer's secondary
voucher from the clearinghouse, the buyer's secondary voucher
including a pointer to the secondary content, use information
specifying the type of use intended for the secondary content,
restriction information allowing a preview copy of the content to
be distributed to another user, and transaction information
allowing transactions up to a secondary limit, for transferring a
preview copy. The restriction and use information in the buyer's
primary and secondary vouchers allow the buyer device to use the
content. The seller device then sends to the clearinghouse, the
offer indication by the buyer device, to obtain compensation to the
seller device for the price of the content. The transaction
information of the seller's vouchers enables the buyer device to
distribute preview copies of the content up to the secondary
limit.
[0049] Further in accordance with the invention, a method is
disclosed to control the downloading of digital asset content from
a server to protect against resource exhaustion in a mobile
environment. The method begins by storing a digital asset content
in a distributing computer in a network. Then, in accordance with
the invention, the method stores a voucher in a device in the
network, the voucher including a pointer to the content, use
information specifying the type of use intended for the content,
restriction information limiting usage of the content, and
protection information specifying an ID for the content and an
encryption key for the content. The method continues by forming a
download token in the device, using the ID for the content and the
encryption key for the content. Then the method sends the download
token from the device to the distributing computer with a request
to download the content after validating the download token. Then
the device receives the content at the device, in response to the
validation of the download token at the distributing computer. As a
result, only authorized devices in the network can successfully
download the content. The download token can further include a
digital signature of the device and a certificate issued by a
certifying authority that certifies the authenticity of the digital
signature of the device. Still further, a payment authorization can
accompany the download token sent to the distributing computer.
[0050] In another aspect of the invention, a system is disclosed to
enable a wireless device in a mobile communication environment, to
obtain a right to give to another device, protected content of a
digital asset stored in any one of a plurality of content servers.
The system includes a plurality of content servers in a network,
each storing a content of a digital asset. The system further
includes a voucher server in the network, for registering the
digital content in the plurality of content servers. In addition,
the system includes a DRM agent or payment server in the network,
for obtaining information about the content from the voucher
server. The operation of the system begins with a wireless device
in a mobile communication environment, sending to the DRM agent a
request for a right to give to a terminal device, content of a
digital asset. The DRM agent responds by sending an offer of
consideration to the wireless device, including consideration
information obtained from the voucher server. The user of the
wireless device then sends an acceptance of the consideration to
the DRM agent. The DRM agent then obtains a give voucher for the
content from the voucher server and forwards it to the wireless
device. In accordance with the invention, the give voucher has
metadata including a plurality of pointers to the content in any
one of the plurality of content servers, use information specifying
the type of use intended for the content, restriction information
limiting usage of the content, and transaction information about
the right to give the content, an identity for the wireless device,
and an identity for the terminal device. The wireless device then
sends the give voucher to the terminal device to enable the
terminal device to select one of the plurality of content servers
and access the content from a selected content server, in response
to the metadata.
[0051] Still further in accordance with the invention, the terminal
device sends the give voucher to the DRM agent to exchange it for a
second, normal voucher. The second voucher has metadata including a
plurality of pointers to the content in any one of the plurality of
content servers, use information specifying the type of use
intended for the content, restriction information limiting usage of
the content, and the identity for the terminal device. The terminal
device is now able to select one of the plurality of content
servers, and access the content from a selected content server, in
response to the metadata.
[0052] In an alternate embodiment of the invention, the terminal
device sends the give voucher to a second DRM agent in the network,
different from the first DRM agent. The second DRM agent transforms
the give voucher into the second voucher. The terminal device is
now able to select one of the plurality of content servers and
access the content from a selected content server, in response to
the metadata.
[0053] In another aspect of the invention, a method is disclosed to
enable a wireless device to decrypt the protected content with a
content key. An author or publisher will originally submit the
content to the voucher server in the network, to register the
content in the plurality of content servers. The voucher server
encrypts the content with a content key and either retains the key
or appends the protected key to the encrypted content before
storing it in the content servers. Several techniques are disclosed
to protect the content and the content key. In one embodiment, the
wireless device is enabled to recover the content key to decrypt
the encrypted content. At the time that the wireless device
requests the content, it provides its unique device ID and/or user
ID. The voucher server joins the content key with the unique device
ID to form a key token that is either appended to the content or is
included in the voucher. The wireless device is able to recover the
content key from the key token by matching its device ID and/or
user ID with that in the key token. By using combinations of such
unique IDs, the danger of loosing one of the IDs and thus failing
to recover the key, is minimized. A randomized version of the user
ID can be used to provide privacy, if desired.
[0054] In one embodiment, the content key is joined with a
reference device ID by performing an exclusive OR operation between
the content key and the reference device ID, forming a first key
token. A similar operation is performed on a reference user ID to
form a second key token. These key tokens can either be appended to
the content or included in the voucher. When the wireless device
gains possession of the voucher it will have any of the key tokens
included therein. Using the metadata in the voucher, the wireless
device gains possession of the encrypted content and will have any
of the remaining key tokens included therein. Then, the wireless
device can recover the content key either if the device ID matches
the reference device ID in the first key token or if the user ID
matches the reference user ID in the second key token. Then, the
wireless device can decrypt the encrypted content with the
recovered content key.
[0055] Further in accordance with the invention, the content also
has a media ID. The voucher server can form the voucher's
transaction information to include a third key token containing the
content key joined with a reference media ID for the content. In
one embodiment, the content key is joined with the reference media
ID by performing an exclusive OR operation between the content key
and the reference media ID, forming the third key token. When the
wireless device receives the voucher, the metadata enables the
wireless device to access one of the plurality of content servers,
to obtain the encrypted content. Then, the wireless device can
recover the content key if the media ID of the encrypted content
matches the reference media ID in the third key token. The recovery
of the content key is by performing an exclusive OR operation
between the media ID and the third key token. The recovered content
key can then be used by the wireless device to decrypt the
encrypted content.
[0056] In another embodiment of the invention, the wireless device
can use its private key from a public key/private key pair, to
recover the content key. At the time that the wireless device
requests the content, it provides its public key. The voucher
server encrypts the content key with the wireless device's public
key to form a key token that is either appended to the content or
is included in the voucher. The wireless device is able to recover
the content key from the key token by decrypting the key token with
its private key. The recovered content key can then be used by the
wireless device to decrypt the encrypted content.
[0057] In another embodiment of the invention, the wireless device
can use its shared symmetric key, to recover the content key. At
the time that the wireless device requests the content, the voucher
server encrypts the content key with the shared symmetric key to
form a key token that is either appended to the content or is
included in the voucher. The wireless device is able to recover the
content key from the key token by decrypting the key token with the
shared symmetric key. The recovered content key can then be used by
the wireless device to decrypt the encrypted content
[0058] In another embodiment of the invention, the encrypted
content can be transferred on a tangible medium such as a CD ROM or
a floppy disk. The tangible medium has a media ID. The voucher
server can form the voucher's transaction information to include a
key token containing the content key joined with a reference media
ID for the content. In one embodiment, the content key is joined
with the reference media ID by performing an exclusive OR operation
between the content key and the reference media ID, forming the key
token. When the wireless device receives the voucher, it can
recover the content key if the media ID of the encrypted content
matches the reference media ID in the key token. The recovery of
the content key is by performing an exclusive OR operation between
the media ID and the key token. The recovered content key can then
be used by the wireless device to decrypt the encrypted
content.
[0059] The invention is applicable to virtually all digital
communications networks, including wide area networks (WANs),
metropolitan area networks (MANs), local area networks (LANs), and
personal area networks (PANs). The invention is applicable to fixed
station wireline networks, mobile wireless networks, and hybrid
combinations of fixed station wireline networks communicating
through wireless access points with mobile wireless networks. In
particular, the invention is applicable to any mobile computing
environment, including any wireless wide area network such as a
cellular telephone network or any short range wireless system such
as a wireless local area network or a wireless personal area
network. Examples of wireless, wide area network architectures to
which the invention applies include Global System for Mobile
Communication (GSM), IS-136 TDMA-based Digital Advanced Mobile
Phone Service (DAMPS), Personal Digital Cellular (PDC), IS-95
CDMA-based cdmaOne System, General Packet Radio Service (GPRS) and
broadband wireless systems such as W-CDMA, and Broadband GPRS.
Examples of short-range wireless systems to which the invention
applies include the Bluetooth Standard, the IEEE 802.11 Wireless
LAN Standard the HIPERLAN Standard, the IEEE 802.15 Wireless
Personal Area Network (WPAN) standard, the Infrared Data
Association (IRDA) standard, the Digital Enhanced Cordless
Telecommunications (DECT) standard, the Shared Wireless Access
Protocol (SWAP) standard, the Japanese 3rd Generation (3G) wireless
standard, and the Multimedia Mobile Access Communication (MMAC)
Systems standard of the Japanese Association of Radio Industries
and Businesses.
BRIEF DESCRIPTION OF THE DRAWINGS
[0060] The accompanying figures best illustrate the details of the
method, system, and apparatus for controlling the distribution of a
digital asset in a mobile communication environment, both as to its
structure and operation. Like reference numbers and designations in
these figures refer to like elements.
[0061] FIG. 1 is a network diagram that depicts the delivery of a
Mobile Rights Voucher content package to a receiving terminal from
either a distributing terminal or a network service.
[0062] FIG. 2 is a network diagram that expands the system shown in
FIG. 1 by illustrating an exemplary communication between the
receiving terminal and the network service.
[0063] FIG. 3A is an abstract representation of an embodiment of a
Mobile Rights Voucher.
[0064] FIG. 3B is an illustration of an XML embodiment of the
Mobile Rights Voucher shown in FIG. 3A.
[0065] FIGS. 4A through 4V illustrate the DTD declarations for the
XML embodiment of the Mobile Rights Voucher shown in FIG. 3A.
[0066] FIGS. 5A through 5D illustrate, respectively, an exemplary
DTD for subset A, subset B, subset C, and a baseline DTD for the
XML embodiment of the Mobile Rights Voucher shown in FIG. 3A.
[0067] FIG. 6 is a functional block diagram that illustrates the
interaction of a distribution terminal and a receiving terminal in
the distribution of a primary and a secondary content in the Mobile
Rights Voucher copy intent process.
[0068] FIG. 7 is a functional block diagram that illustrates the
interaction of a distribution terminal and a receiving terminal in
the non-personalized Mobile Rights Voucher copy intent process for
sending a preview copy of protected digital content.
[0069] FIG. 8 is a functional block diagram that illustrates the
interaction of a distribution terminal, a receiving terminal, and a
voucher server in the personalized Mobile Rights Voucher give
intent process for sending a preview copy of protected digital
content.
[0070] FIG. 9 is a functional block diagram that depicts a network
environment for distributing a Mobile Rights Voucher by
illustrating a use case scenario in which a sending terminal
accesses a content service and a voucher service via a cellular
network to purchase two screen savers.
[0071] FIG. 10 is a network process diagram illustrating the basic
controlled download protocol between a receiving DRM device, the
receiver protocol engine, the sender protocol engine, and the
sending DRM device.
[0072] FIG. 11 is a functional block diagram illustrating the
interaction of a mobile device, a rights gateway, a retail content
service, and a clearinghouse in the process of the mobile device
purchasing rights from the retail content service.
[0073] FIG. 12 is a functional block diagram illustrating the
interaction of the architectural elements of the Mobile DRM
system.
[0074] FIG. 13 is a functional block diagram that expands upon the
architecture shown in FIG. 12 to illustrate the interaction of a
more complex Mobile DRM system to illustrate the relationships
between the participating entities.
[0075] FIG. 14 is a functional block diagram that expands upon the
architecture shown in FIG. 12 to illustrate the interaction of a
more complex Mobile DRM system to illustrate the relationships
between the participating entities.
[0076] FIG. 15 is a flow diagram that demonstrates the message
flows among the elements shown in FIG. 12.
DETAILED DESCRIPTION OF THE INVENTION
[0077] Mobile Rights Voucher
[0078] The Mobile Rights Voucher disclosed herein manages the
lifecycle of a piece of content and the associated property rights
held by the creator or agent of the digital content. In addition,
the Mobile Rights Voucher can facilitate flexible payment for
content and can deliver the content separate from the voucher. The
Mobile Rights Voucher is a message that can be sent by electronic
mail, a Multimedia Messaging Service (MMS), or a Short Messaging
Service (SMS). Alternatively, the Mobile Rights Voucher can be
downloaded using a Wireless Application Protocol (WAP) or a
Hypertext Transfer Protocol (HTTP).
[0079] Smart Content Object is a content encapsulation architecture
that includes smart routing capabilities for content and can be
useful for application routing. The Mobile Rights Voucher can use
the Smart Content Object for expressing rights information. The
Smart Content Object and Mobile Rights Voucher are both implemented
on memory-limited devices such as a mobile phone or a personal
digital assistant. The Mobile Rights Voucher is not bound in any
way to the Smart Content Object and can be used in other transport
architectures such as MMS and Hypertext Transfer
Protocol/Multipurpose Internet Mail Extensions (HTTP/MIME).
[0080] The Mobile Rights Voucher is a "light-weight" DRM that can
benefit a mobile environment. Additionally, the Mobile Rights
Voucher can express usage rights for "low value" content such as
cellular telephone ringing tones, operator logos, and additional
levels for cellular telephone games.
[0081] In one embodiment, the Mobile Rights Voucher is sent over
the air and can allow devices that implement this specification to
interoperate. Due to constraints of implementation and
industry-wide adoption, this specification does not attempt to
deliver on all of the promise of DRM in a single step. Thus, the
Mobile Rights Voucher full baseline specification is split three
subsets. Subset A of the baseline specification supports no rights
for a piece of content. Subset A relies upon another entity such as
a service provider who supplies the mobile device to implement the
Mobile Rights Voucher as a "stub" and take care of the
implementation of specific DRM tasks. Subset B of the baseline
specification supports the preview of digital content and allows
for the specification of transaction and administrative
information. Subset C of the baseline specification supports many
intents and constraints with full distribution capabilities.
Subsets B and C provide increased functional DRM capabilities for a
mobile device such as a cellular telephone. The full baseline
specification will provide a completely functional light-weight DRM
architecture.
[0082] Compatibility with a publicly specified voucher system such
as ODRL or XrML can improve the integration of the Mobile Rights
Voucher with existing systems. Unfortunately, XrML is disqualified
due of unclear licensing terms. Thus, the Mobile Rights Voucher is
based upon a non-valid version of ODRL and is extended slightly in
appropriate places to allow for the envisioned use cases.
[0083] FIG. 1 is a network diagram that depicts the delivery of
content package 135 from either distributing terminal 100 or retail
content service 110 to receiving terminal 140. Distributing
terminal 100 is coupled to either personal area network 120 or
cellular network 130. Personal area network 120 is a short-range
network that implements an architecture specification such as
Infrared data association IrDA), Bluetooth, or object exchange
architecture. Cellular network 130 is a communication network such
as an analog signal, global system for mobile (GSM) communications,
general packet radio service (GPRS), time-division multiple access
(TDMA), or code-division multiple access (CDMA). In addition,
cellular network 130 can accommodate Enhanced Data Rates for GSM
Evolution (EDGE), an evolution of GSM and TDMA systems that
increases network capacity and data rates up to 473 K-bits per
second to enable Mobile Multimedia services, and Digital Video
Broadcasting (DVB) technology. The delivery of content package 135
can use a single technology to receive the rights and the content
or can mix technologies. A user may choose to receive the rights
and the content using Bluetooth on personal area network 120 or,
instead, receive the rights using Bluetooth on personal area
network 120 and receive the content using DVB on cellular network
130. In one embodiment, distributing terminal 100, retail content
service 110, and receiving terminal 140 are Bluetooth devices that
use a radio frequency signal that includes data adhering to the
Bluetooth protocol and specification to communicate data among the
devices. However, the architecture disclosed herein and shown in
FIG. 1 will apply to any appropriate wireless environment.
[0084] The first content delivery scenario shown in FIG. 1 involves
personal area network 120 coupling distributing terminal 100 and
receiving terminal 140. A user (not shown) coupled to distributing
terminal 100 selects to transmit content package 135 to receiving
terminal 140 using personal area network 120. Content package 135
includes content object 136 and voucher object 137.
[0085] The second content delivery scenario shown in FIG. 1
involves cellular network 130 coupling distributing terminal 100
and receiving terminal 140. A user (not shown) coupled to
distributing terminal 100 selects to transmit content package 135
to receiving terminal 140 using cellular network 130. Content
package 135 is the same as in the first delivery scenario and
includes content object 136 and voucher object 137.
[0086] The third content delivery scenario shown in FIG. 1 involves
personal area network 120 coupling retail content service 110 and
receiving terminal 140. An owner (not shown) coupled to retail
content service 110 selects to transmit content package 135 to
receiving terminal 140 using personal area network 120. Content
package 135 is the same as in the first delivery scenario and
includes content object 136 and voucher object 137.
[0087] The fourth content delivery scenario shown in FIG. 1
involves cellular network 130 coupling retail content service 110
and receiving terminal 140. An owner (not shown) coupled to retail
content service 110 selects to transmit content package 135 to
receiving terminal 140 using cellular network 130. Content package
135 is the same as in the first delivery scenario and includes
content object 136 and voucher object 137.
[0088] FIG. 2 is a network diagram that expands the system shown in
FIG. 1 by illustrating the communication between retail content
service 110 and receiving terminal 140. A user (not shown) is
coupled to receiving terminal 140. Receiving device 140
communicates with retail content service 110 that includes content
catalog 210, payment system 220, voucher system 230, and content
hosting 240.
[0089] When the user carries receiving terminal 140 into the
communication range of retail content service 110, the user can
browse the content of retail content service 110 by sending catalog
request 211 to content catalog 210 and receiving catalog response
212 from content catalog 210. In one embodiment, the format of
catalog request 211 and catalog response 212 complies with either
wireless access protocol (WAP) or hypertext transfer protocol
(HTTP).
[0090] If the user decides to purchase content from retail content
service 110, the user sends payment request 221 to payment system
220 and receives payment response 222 from payment system 220. The
payment mechanism includes subscription-based, micro, and pre-paid
payment systems. The payment is realized by sending an SMS message
to a predetermined number maintained by an operator. The receipt of
the message generates a charge to the bill the user gets from the
service operator and the user can pay the fee using a typical
telephone bill payment method. In one embodiment, the format of
payment request 221 and payment response 222 complies with either
WAP or HTTP.
[0091] The user receives either a Mobile Rights Voucher or a
reference to the Mobile Rights Voucher from retail content service
110 as part of payment response 222. If the user receives the
reference to the Mobile Rights Voucher, receiving terminal 140
retrieves the Mobile Rights Voucher by sending voucher request 231
to voucher system 230 and receiving voucher response 232 from
voucher system 230. In one embodiment, the format of voucher
request 231 and voucher response 232 complies with either a short
messaging system (SMS), a multimedia messaging system (MMS), or an
object download architecture. In addition, the Mobile Rights
Voucher can contain a pictorial cover of a multimedia message
related to the content that the user wants to retrieve.
[0092] The user either receives the content bundled with the Mobile
Rights Voucher or downloads the content as an additional step. The
user can download the content from retail content service 110 by
sending content request 241 to content hosting 240 and receiving
content response 242 from content hosting 240. In one embodiment,
the format of content request 241 and content response 242 complies
with either an SMS, an MMS, or an object download architecture.
[0093] There are many ways to model and implement a digital rights
management (DRM) system to control the lifecycle of a piece of
digital content. The voucher-based model of the system disclosed
herein is flexible and provides a migration path to a more
sophisticated system for managing digital commerce applications and
private information. One embodiment of the system disclosed herein
captures the usage rules, rights, and business rules in a Mobile
Rights Voucher and stores the digital content (i.e., asset) and
Mobile Rights Voucher as distinct objects in a content package.
Since the content and the Mobile Rights Voucher are distinct
objects, the consuming device can receive each piece
separately.
[0094] FIG. 3A illustrates an abstract representation of a Mobile
Rights Voucher based on the ODRL specification. A voucher is a
representation of the usage rights for an item of digital content.
The voucher identifies an asset, lists the usage and associated
constraints for the asset, includes meta-information to identify a
voucher service, the asset, and a payment transaction method, and
provides a mechanism to unlock the asset if protection is used.
[0095] As shown in FIG. 3A, Nokia Rights Voucher 300 is a Mobile
Rights Voucher that includes meta-information 310 and usage
information 320. Meta-information 310 further comprises version
segment 312, administrative segment 314, and transaction segment
316. Usage information 320 further comprises a list of asset 322
and protection 324 pairs, intent rules 330, and default constraints
340. Intent rules 330 include print directive 331, play directive
332, execute directive 333, display directive 334, give directive
335, and copy directive 336.
[0096] Nokia Rights Voucher 300 is a representation of the usage
rights for a piece of digital content. The purpose of Nokia Rights
Voucher 300 is to identify the assets that require protection,
define possible usage constraints for each asset, define
meta-information for the voucher service, the assets, and the
transaction, and provide a mechanism to unlock the content if
protection is used. A device that processes a voucher and it's
content are inherently trusted to respect the rights and usage
constraints for the voucher and to disallow access to the content
if the rights or usage constraints are ignored.
[0097] FIG. 3B is an embodiment of Nokia Rights Voucher 300, the
abstract Mobile Rights Voucher shown in FIG. 3A, which adheres to
the XML specification. Line 1 defines the version and encoding
scheme for the XML shown in FIG. 3B. Line 2 specifies the location
of the document type definition (DTD) file that defines the
interpretation of the XML markup tags shown in FIG. 3B. Lines 3
through 41 define the entire structure of Nokia Rights Voucher 300.
Lines 4 through 8 define the entire structure of meta-information
310 and lines 9 through 40 define the entire structure of usage
information 320. Line 4 illustrates version segment 312 of
meta-information 310 as an XML tag that specifies Nokia Rights
Voucher 300 version 1.0.3. Lines 5 through 7 illustrate
administrative segment 314 of meta-information 310 as an XML tag
that specifies the user identification (ID) as the URL
"http://www.media-sampo.com/ScreenSaverSer- vice". Line 8
illustrates transaction segment 316 of meta-information 310 as an
XML tag that specifies the transaction identifier (TID)
"3457345987-6789-9". Lines 10 through 23 illustrate a list that
includes two pairs of asset 322 and protection 324 for usage
information 320, respectively, lines 10 through 16 and lines 17
through 23. Each pair specifies a UID for the asset and the
protection associated with the UID. Lines 24 through 32 illustrate
intent rules 330 of usage information 320. Line 24 illustrates
display directive 334 of intent rules 330 that specifies that the
recipient of Nokia Rights Voucher 300 has the right to display the
content. Lines 25 through 32 illustrate the copy directive 336 of
intent rules 330 that specifies that the recipient of Nokia Rights
Voucher 300 has the right to copy
"previewvoucher.343453344@digitalshop.c- om" until Aug. 30, 2001.
Lines 33 through 36 illustrate default constraints 340 of usage
information 320. Default constraints 340 specifies the individual
UID "IMEI:123456789123459" as the constraint Lines 38 through 40
illustrate the integrity protection constraints for Nokia Rights
Voucher 300.
[0098] The XML embodiment of Nokia Rights Voucher 300 requires a
document type definitions (DTD) file, such as the file
"C:.backslash.MRV1.0-subset- C.dtd" specified on line 2 in FIG. 3B,
to specify the allowable order, structure, and attributes of XML
markup tags for Nokia Rights Voucher 300. FIGS. 4A through 4V
specify the DTD declarations and attributes for each element of the
XML embodiment of the Mobile Rights Voucher shown in FIG. 3B. In
addition, FIGS. 4A through 4V describe a purpose and a description
for each element, as well as an example that uses the element in a
DTD file, and an interoperability description that maps the XML
embodiment of Nokia Rights Voucher 300 to a pure ODRL
specification.
[0099] A Mobile Rights Voucher includes a unique identifier that
does not change for any instance of the voucher. The Mobile Rights
Voucher is a universal resource identifier (URI) such as a uniform
resource locator (URL) and should include an absolute address path.
In addition, the Mobile Rights Voucher should support at least the
hypertext transfer protocol (HTTP), the international mobile
equipment identity (IMEI) standard, the international subscriber
identity (IMSI) standard, and the URL content identifier (CID) and
message identifier (MID) schemes.
[0100] A Mobile Rights Voucher that results from a copy request by
a user (i.e., using the "copy" intent rule associated with the
voucher) will receive a new unique identifier. In addition, any
self-referential links in the duplicated voucher (i.e., links
defined in a "narrow" DTD element) will receive a new unique
identifier.
[0101] The XML embodiment of the Mobile Rights Voucher supports a
phased release of a digital rights management (DRM) system for a
mobile environment. Thus, the fill baseline Mobile Rights Voucher
based on XML will result from a three-phased release of the Mobile
Rights Voucher DTD specification.
[0102] Subset A of the Mobile Rights Voucher DTD specification is
capable of expressing "no-rights" for a specific piece of digital
content, that is, the user cannot use the digital content on the
device. Subset A is intended for use with Smart Content Object and
DRM packaging formats to express that the enclosed digital content
is delivered without any rights and that a Mobile Rights Voucher is
needed to access the content. The capabilities for Mobile Rights
Voucher Subset A include:
1 Download control Not Available Peer-to-peer control Not Available
Usage controls Not Available Encapsulation MIME multi-part/Smart
Content Object Application routing MIME multi-part/Smart Content
Object Transport Browsing (e.g., HTTP, WAP). Voucher technology
Mobile Rights Voucher, Release 1, Subset A (ODRL-based) Protection
Not Available IMPACT None
[0103] Subset B of the Mobile Rights Voucher DTD specification
supports the first phase of the Light DRM implementation. The
capabilities for Mobile Rights Voucher Subset B include:
2 Download control Voucher server authorizing content download
Peer-to-peer control Simple distribution Usage controls Preview
(count and time) Encapsulation MIME multi-part/Smart Content Object
Application routing MIME multi-part/Smart Content Object Transport
Browsing (HTTP, WAP). Voucher and content can be transported
independently. Voucher technology Mobile Rights Voucher, Release 1,
Subset A (ODRL-based) Protection Not Available IMPACT Minimal
impact on phone client. Legacy phones will be able to use content
download. Need for voucher server (and related payment). Prepares
for Phase Two service model.
[0104] Subset C of the Mobile Rights Voucher DTD specification
supports the second phase of the Light DRM implementation. The
capabilities for Mobile Rights Voucher Subset B include:
3 Download control Voucher server authorizing content usage
Peer-to-Peer Control Super distribution (person-to-person) possible
Usage Controls Preview, Play, (not Give), Copy, Display, Print, and
Execute Encapsulation MIME multi-part/Smart Content Object
Application Routing MIME multi-part/Smart Content Object Transport
Browsing (HTTP, WAP), MMS, and OBEX. Voucher and content can be
transported independent of Smart Content Object. Voucher Technology
Mobile Rights Voucher Release 1 (ODRL-based) Protection Content and
voucher encryption and integrity protection IMPACT Medium impact on
phone design (framework for usage rights and content storage).
Opens up new super distribution-based business models.
[0105] Backward compatibility is supported in every phase of the
Mobile Rights Voucher DTD specification development. Thus, a
voucher conforming to Mobile Rights Voucher subset A will be fully
understood on a terminal that implements Mobile Rights Voucher
subset A, B, or C. Similarly, a voucher conforming to Mobile Rights
Voucher subset B will be fully understood in a terminal that
implements Mobile Rights Voucher subset B or C.
[0106] Forward compatibility, on the other hand, is not guaranteed
because some new elements may not be understood. This is a
potentially dangerous situation regarding the protection of the
expressed rights. If a device receives a piece of content that
contains a constraint type (e.g., count, datetime, or individual
elements) that the DTD cannot interpret, the entire constrain
element is deemed to have failed. This ensures that no rights are
lost. Thus, a voucher that conforms to Mobile Rights Voucher subset
C cannot be guaranteed to be understood on a terminal that
implements Mobile Rights Voucher subset B. The voucher may be used,
however, if all constrain type in relevant constrain elements are
understood by the subset B conforming device.
[0107] FIG. 5A illustrates an exemplary DTD for subset A of the
Mobile Rights Voucher. The DTD defines the minimum and optional
requirements for representing a container for multimedia digital
assets that can expresses "no-right" or "full-right" for each
asset. The quality "no-right" means that the associated asset is
not to be used on the device at all, whereas the quality
"full-right" means that the associated asset can be used on any
device. Line 1 defines the version and encoding scheme for the DTD
shown in FIG. 5A. Lines 2 through 5 are a comment. The DTD requires
the presence of the "rights" element on lines 6 through 9 because
the "rights" element is the root element for the Mobile Rights
Voucher object. The "rights" includes zero or one "admin" elements
and exactly one "usage" element. The DTD also requires the presence
of the "admin" element on line 10 because the "admin" element
describes the entity for identifying resource of vouchers. The
"admin" element includes exactly one "uid" element. The DTD
requires the presence of the "usage" element on line 11 because the
"usage" element defines the usage rights for an asset. The "usage"
element includes exactly one "asset" element. The "no-rights" usage
is assigned to restrict access to the asset and the "full-rights"
usage is assigned to use the asset. The absence of an asset
declaration means that the voucher is associated with the enclosing
content package. The DTD requires the presence of the "asset"
element on line 12 because the "asset" element creates a reference
to each asset associated with this voucher. The "asset" element
includes zero or one "uid" element. The DTD requires the presence
of the "uid" element on line 13 because the "uid" element
represents a URI string. The "uid" element includes parsed
character data.
[0108] FIG. 5B illustrates an exemplary DTD for subset B of the
Mobile Rights Voucher. The DTD is intended to deliver a small and
concise rights expression voucher by supporting content preview by
count for multiple content types (i.e., multiple intents) and
transaction and administrative (i.e., retail server URL)
information. Line 1 defines the version and encoding scheme for the
DTD shown in FIG. 5B. Lines 2 through 5 are a comment. The DTD
requires the presence of the "rights" element on lines 6 through 9
because the "rights" element is the root element for the Mobile
Rights Voucher object. The "rights" element includes zero or one
"version" element, zero or one "admin" element, zero or one
"transaction" element, and one or more "usage" elements. The
"version" element on line 10 is an optional requirement that is set
to the version number for the DTD (e.g., "1.0). The "version"
element includes parsed character data. The DTD requires the
presence of the "admin" element on line 11 because the "admin"
element describes the entity for identifying resource of vouchers.
The "admin" element includes exactly one "uid" element. The DTD
requires the presence of the "uid" element on line 12 because the
"uid" element represents a URI string. The "uid" element includes
parsed character data The DTD requires the presence of the
"transaction" element on line 13 because the "transaction" element
specifies payment-related information in a format that is defined
by the type of payment chosen. The "transaction" element includes
parsed character data. The DTD requires the presence of the "usage"
element on line 14 because the "usage" element defines the usage
rights for an asset. The "usage" element includes exactly one
"asset" element, zero or one "display" element, zero or one "play"
element, zero or one "execute" element, and zero or one "copy"
element. Subset B provides support for preview related rights such
as "display", "play", "execute", and "copy" that are only used
once, but does not support any super-distribution rights such as
"copy" or "give". The DTD requires the "asset" element on line 15
because the "asset" element creates a reference to each asset
associated with this voucher. The "asset" element includes zero or
more "uid" elements. The DTD requires the "display" element on line
16 because the "display" element defines the rights to visually
render an asset on a display device. The "display" element includes
zero or one "constrain" elements. For subset B, "display" is a
preview element and only allows rendering of an asset one time. The
DTD requires the presence of the "play" element on line 17 because
the "play" element defines the rights to render an asset into audio
or video form. A visual asset that does not change over time can be
regarded as a "still video" and rendered using the "play" element
as opposed to the "display" element. The "play" element includes
zero or one "constrain" elements. For subset B, "play" is a preview
element and only allows rendering of an asset one time. The DTD
requires the presence of the "execute" element on line 18 because
the "execute" element defines the rights to render an asset into
machine-readable form. The "execute" element includes zero or one
"constrain" elements. For subset B, "execute" is a preview element
and only allows rendering of an asset one time. The DTD requires
the presence of the "copy" element on line 19 because the "copy"
element defines the rights to forward a copy of an asset to another
user's terminal. The "copy" element includes zero or one
"constrain" elements. For subset B, "copy" is a preview element and
only allows forwarding a preview copy of an asset. The DTD requires
the presence of the "constrain" element on line 20 because the
"constrain" element is used to ensure there is only one usage of
the intent. The "constrain" element includes zero or one "count"
elements and zero or one "datetime" elements. The DTD requires the
presence of the "count" element on line 21 because the "count"
element holds the one usage restriction. The "count" element
includes parsed character data The DTD requires the presence of the
"datetime" element on line 22 because the "datetime" element
restricts usage based on time. The "datetime" element includes zero
or one "start" element and zero or one "end" element. The DTD
requires the presence of the "start" element on line 23 because the
"start" element sets a starting count or a starting date. The
"start" element includes parsed character data. The DTD requires
the presence of the "end" element on line 24 because the "end"
element sets an ending count or an ending date. The "end" element
includes parsed character data.
[0109] FIG. 5C illustrates an exemplary DTD for subset C of the
Mobile Rights Voucher. The DTD is intended to deliver additional
rights to the subset B voucher by supporting content usage
controlled by the voucher system, super-distribution business
models, possible binding to device IMEI, and possible protection.
Line 1 defines the version and encoding scheme for the DTD shown in
FIG. 5C. Lines 2 through 5 are a comment. The DTD requires the
presence of the "rights" element on lines 6 through 10 because the
"rights" element is the root element for the Mobile Rights Voucher
object. The "rights" element includes zero or one "version"
element, zero or one "admin" element, zero or one "transaction"
element, one or more "usage" elements, and zero or one "protection"
elements. The "version" element on line 11 is an optional
requirement that is set to the version number for the DTD (e.g.,
"1.0). The "version" element includes parsed character data The DTD
requires the presence of the "admin" element on line 12 because the
"admin" element describes the entity for identifying resource of
vouchers. The "admin" element includes one or more "uid" elements.
The DTD requires the presence of the "uid" element on line 13
because the "uid" element represents a URI string. The "uid"
element includes parsed character data. The DTD requires the
presence of the "transaction" element on line 14 because the
"transaction" element specifies payment-related information in a
format that is defined by the type of payment chosen. The
"transaction" element includes parsed character data The
"protection" element on line 15 is an optional requirement that
stores protection information for the content package. The
"protection" element includes parsed character data. The DTD
requires the presence of the "usage" element on lines 16 and 17
because the "usage" element defines the usage rights for an asset.
Subset C provides full support including super-distribution rights
for intents such as "print", "display", "play", "execute", and
"copy", but does not support the super-distribution rights for the
give" intent. The "usage" element includes one or more "asset"
elements, zero or more "print" elements, zero or more "display"
elements, zero or more "play" elements, zero or more "execute"
elements, zero or more "copy" elements, and zero or one "constrain"
elements. The DTD requires the presence of the "asset" element on
line 18 because the "asset" element creates a reference to each
asset, the rights-holder, and any protection associated with this
voucher. The "asset" element includes zero or more "uid" elements,
zero or more "rightsholder" elements, and zero or one "protection"
element. The DTD requires the presence of the "rightsholder"
element on line 19 because the "rightsholder" element enables the
association of a rights-holder with a specified asset. The
"rightsholder" element includes exactly one "uid" element. The DTD
requires the presence of the "print" element on line 20 because the
"print" element defines the rights to visually render an asset on a
display device. The "print" element includes zero or one
"constrain" element. For subset C, "print" is a preview element and
only allows rendering of an asset one time. The DTD requires the
presence of the "display" element on line 21 because the "display"
element defines the rights to visually render an asset on a display
device. The "display" element includes zero or one "constrain"
element. For subset C, "display" is a preview element and only
allows rendering of an asset one time. The DTD requires the
presence of the "play" element on line 22 because the "play"
element defines the rights to render an asset into audio or video
form. A visual asset that does not change over time can be regarded
as a "still video" and rendered using the "play" element as opposed
to the "display" element. The "play" element includes zero or one
"constrain" element For subset C, "play" is a preview element and
only allows rendering of an asset one time. The DTD requires the
presence of the "execute" element on line 23 because the "execute"
element defines the rights to render an asset into machine-readable
form. The "execute" element includes zero or one "constrain"
element. For subset C, "execute" is a preview element and only
allows rendering of an asset one time. The DTD requires the
presence of the "copy" element on line 24 because the "copy"
element provides support for super-distribution of assets and the
ability to duplicate narrowed vouchers. The "copy" element includes
zero or one "constrain" element and one or more "narrow" elements.
The DTD requires the presence of the "narrow" element on line 25
because the "narrow" element provides a list of vouchers that will
be duplicated with the content. The "narrow" element includes zero
or more "uid" elements. The DTD requires the presence of the
"constrain" element on line 26 because the "constrain" element is
used to ensure there is only one usage of the intent. The
"constrain" element includes zero or one "datetime" element, zero
or one "count" element, and zero or more "individual" elements. The
DTD requires the presence of the "datetime" element on line 27
because the "datetime" element restricts usage based on time. The
"datetime" element includes zero or one "start" element and zero or
one "end" element. The DTD requires the presence of the "start"
element on line 28 because the "start" element sets a starting
count or a starting date. The "start" element includes parsed
character data. The DTD requires the presence of the "end" element
on line 29 because the "end" element sets an ending count or an
ending date. The "end" element includes parsed character data. The
DTD requires the presence of the "count" element on line 30 because
the "count" element holds the one usage restriction. The "count"
element includes parsed character data. The "individual" element on
line 31 is an optional requirement that provides the capability to
associate the defined rights with a specified device or user. The
"individual" element includes one or more "uid" elements.
[0110] FIG. 5D illustrates an exemplary baseline DTD for the Mobile
Rights Voucher. The baseline DTD provides capabilities in addition
to the capabilities provided in subset C. Line 1 defines the
version and encoding scheme for the DTD shown in FIG. 5D. Lines 2
through 6 are a comment. The DTD requires the presence of the
"rights" element on lines 7 through 11 because the "rights" element
is the root element for the Mobile Rights Voucher object. The
"rights" element includes zero or one "version" element, zero or
one "admin" element, zero or one "transaction" element, one or more
"usage" elements, and zero or one "protection" elements. The
"version" element on line 12 is a should requirement that is set to
the version number for the DTD (e.g., "1.0). The "version" element
includes parsed character data. The DTD requires the presence of
the "admin" element on line 13 because the "admin" element
describes the entity for identifying resource of vouchers. The
"admin" element includes one or more "uid" elements. The DTD
requires the presence of the "uid" element on line 14 because the
"uid" element represents a URI string. The "uid" element includes
parsed character data. The DTD requires the presence of the
"transaction" element on line 15 because the "transaction" element
specifies payment-related information in a format that is defined
by the type of payment chosen. The "transaction" element includes
parsed character data The "protection" element on line 16 is a
should requirement that stores protection information for the
content package. The "protection" element includes parsed character
data. The DTD requires the presence of the "usage" element on lines
17 and 18 because the "usage" element defines the usage rights for
an asset. The baseline DTD provides full support including
super-distribution rights for intents such as "print", "display",
"play", "execute", "copy", and "give". The "usage" element includes
one or more "asset" elements, zero or more "print" elements, zero
or more "display" elements, zero or more "play" elements, zero or
more "execute" elements, zero or more "copy" elements, zero or more
"give" elements, and zero or one "constrain" elements. The DTD
requires the presence of the "asset" element on line 19 because the
"asset" element creates a reference to each asset, the
rights-holder, and any protection associated with this voucher. The
"asset" element includes zero or more "uid" elements, zero or more
"rightsholder" elements, and zero or one "protection" element. The
DTD requires the presence of the "rightsholder" element on line 20
because the "rightsholder" element enables the association of a
rights-holder with a specified asset. The "rightsholder" element
includes exactly one "uid" element. The DTD requires the presence
of the "print" element on line 21 because the "print" element
defines the rights to visually render an asset on a display device.
The "print" element includes zero or more "constrain" elements. The
DTD requires the presence of the "display" element on line 22
because the "display" element defines the rights to visually render
an asset on a display device. The "display" element includes zero
or more "constrain" elements. The DTD requires the presence of the
"play" element on line 23 because the "play" element defines the
rights to render an asset into audio or video form. A visual asset
that does not change over time can be regarded as a "still video"
and rendered using the "play" element as opposed to the "display"
element. The "play" element includes zero or more "constrain"
elements. The DTD requires the presence of the "execute" element on
line 24 because the "execute" element defines the rights to render
an asset into machine-readable form. The "execute" element includes
zero or more "constrain" elements. The DTD requires the presence of
the "copy" element on line 25 because the "copy" element provides
support for super-distribution of assets and the ability to
duplicate narrowed vouchers. The "copy" element includes zero or
more "constrain" elements and one or more "narrow" elements. The
DTD requires the presence of the "give" element on line 26 because
the "give" element provides support for transfer of an asset to
another terminal or user. The "give" element includes zero or more
"constrain" elements and one or more "narrow" elements. The DTD
requires the presence of the "narrow" element on line 27 because
the "narrow" element provides a list of vouchers that will be
duplicated with the content. The "narrow" element includes zero or
more "uid" elements. The DTD requires the presence of the
"constrain" element on line 28 because the "constrain" element is
used to ensure there is only one usage of the intent. The
"constrain" element includes zero or more "datetime" elements, zero
or more "count" elements, and zero or more "individual" elements.
The DTD requires the presence of the "datetime" element on line 29
because the "datetime" element restricts usage based on time. The
"datetime" element includes zero or one "start" element and zero or
one "end" element. The DTD requires the presence of the "start"
element on line 30 because the "start" element sets a starting
count or a starting date. The "start" element includes parsed
character data. The DTD requires the presence of the "end" element
on line 31 because the "end" element sets an ending count or an
ending date. The "end" element includes parsed character data. The
DTD requires the presence of the "count" element on line 32 because
the "count" element holds the one usage restriction. The "count"
element includes parsed character data. The "individual" element on
line 33 is an optional requirement that provides the capability to
associate the defined rights with a specified device or user. The
"individual" element includes one or more "uid" elements.
[0111] The XML embodiment of the Mobile Rights Voucher requires
strict conformance with the implementation requirements described
below. The requirements disclosed herein apply to every subset of
Mobile Rights Voucher unless otherwise stated.
[0112] A voucher is an atomic unit and cannot be specified in part
or divided into parts. When a voucher is delivered to a terminal it
is associated with an identifier. The identifier is a valid URI, is
delivered with the voucher in the delivery package, and is stored
with the voucher on the terminal. Examples of the delivery
packaging include multipurpose Internet mail extensions (MIME),
multimedia messaging system (MMS) and NSC. Valid URI schemes
include URL and MSG-ID. This supports voucher identification which
is necessary for distribution.
[0113] An asset (i.e., an item of digital content) is associated
with an identifier. The identifier is a valid URI. The identifier
is delivered with the asset in the delivery package and is stored
with the asset on the terminal. Examples of the delivery packaging
include MIME, MMS and NSC. Valid URI schemes include URL and
MSG-ID. This supports asset identification and is critical for the
expression of rights in the voucher.
[0114] A piece of digital content delivered as part of the Light
DRM system has an associated rights voucher that contains the usage
rights controlling access to the content. All access is governed
through the voucher and the rights expressed within the
voucher.
[0115] A system that implements the Mobile Rights Voucher
architecture disclosed herein must respect the rights expressed in
the voucher. If a device receives a piece of content that includes
a constrain element that contains a constraint type (e.g., count,
datetime, or individual) that it cannot interpret, the entire
constrain element is deemed to have failed and the device returns
boolean "false". This ensures that no rights are lost. Thus, a
voucher conforming to Mobile Rights Voucher Subset C which cannot
be guaranteed to be understood on a terminal implementing Mobile
Rights Voucher Subset B may be used if all constrain types in
relevant constrain elements are understood by the Subset B
conformant device.
[0116] In addition, the implementation is able to associate each
digital asset (i.e., piece of content) with the associated Mobile
Rights Voucher. This is accomplished by linking the identifier
references under the asset tag declaration in the Mobile Rights
Voucher and the identifier reference delivered with each digital
asset or piece of content. This supports the independent delivery
of the voucher and the associated content.
[0117] The intent elements specified in the XML DTD support current
content types. The implementing applications should use the most
appropriate intent elements for their content. If an intent element
is not declared then that intent element must not be invoked on the
specified asset(s). An intent may contain several constrain
elements that evaluate to a boolean value. For example: 1
intent_result = evaluation if an intent can be invoked or not = (
true AND intent_constrain _result AND usage_constrain _result )
[0118] When the result of the evaluation is "false" the intent has
failed and the intent must not be invoked. For example: 2
intent_constrain _result = evaluation of ALL constrain elements
expressed under an intent = ( true AND constrain_element _ 1 AND
constrain_element _ 2 AND AND constrain_element _N )
[0119] When the result of the evaluation is "false" the intent
constrain has failed and the result is used as part of the greater
expression evaluation. The English description of the boolean
expression is that both the constrain elements attached to an
intent AND the usage (default) constrain element must all be
satisfied (i.e., evaluate to "true) before the intent can be
invoked.
[0120] A constraint element can be associated with either a usage
element or an intent element. A constraint can have several types
of constraints. The implementation is pessimistic. Thus, if any
constraint for an intent element fails then that intent must not be
invoked on the content. This supports combinations of individual
and time expiry of content. This is a boolean expression evaluating
to either true or false. For example: 3 constrain_element =
evaluation of all constrain - types under a constrain element . = (
true AND constrain_type _ 1 AND constrain_type _ 2 AND AND
constrain_type _N )
[0121] When the result is boolean "false" the constrain element has
failed and this result is used as part of the greater expression
evaluation.
[0122] The constrain element that can be declared at the usage
element level is a default constraint that is applied to all intent
elements under that usage element. 4 usage_constrain _result = (
true AND constrain_type _ 1 AND constrain _type _ 2 AND AND
constrain_type _N )
[0123] When the result is boolean false the usage constrain has
failed and this result is used as part of the greater expression
evaluation.
[0124] If an intent element contains no constrain elements then the
asset can be used without restriction for that intent.
[0125] If there are no intent elements declared, then the asset
must not be used for any reason. This is a special case that is
used to express "no-rights" to the specified assets.
[0126] The count constraint indicates the number of times an intent
element can be invoked on an asset. The count element is a
non-negative integer number and can include zero. The implementing
system must maintain outside the voucher the current count for that
voucher-usage-intent constrain element. Each count has its own
variable and is updated separately. When the running total is equal
to the count value in the voucher, the count is considered
expended. Thus, the content must not be used for that intent after
the count is expended. This is referred to a "remaining rights".
Invocation of an intent element that has multiple count constraints
will cause each associated variable to be incremented upon the
invocation of the intent element.
[0127] The datetime constraint indicates a period of time when an
intent element can be invoked on an asset. The datetime element may
include an end element indicating the expiration date beyond which
the content must not be used. If there is a start element then the
asset must not be used before that point. If the start element is
missing then the start time is the current time. The format for the
value type is expressed as the complete representation, basic
format for a calendar date. The textual format specifies a
four-digit year, two-digit month, and two-digit day of the month.
There are no textual separator characters between the year, month,
and day of the month. The implementing system must ensure that
vouchers are created consistently such that the start time is less
than the end time. For release 1 (subsets A, B, and C) of the
Mobile Rights Voucher the datetime element only support calendar
dates. In addition, there are not remaining rights with the
datetime element. Release 2 of the Mobile Rights Voucher will
provide support for relative datetime periods and will include the
time of day in addition to the calendar date. For release 2 of the
Mobile Rights Voucher, the universal time constant (UTC) format
will be used for the time of day.
[0128] The individual constraint requires that the consuming
terminal be able to match a locally stored unique identifier to the
unique identifier included in the voucher. It is recommended that
the unique identity is securely associated with to the terminal
using either as an International Mobile Equipment Identity (IMEI)
number or an identifier from a Wireless Identity Module (WIM). If
this identity is not present in the terminal then the intent must
not be used. The identity in the voucher is expressed as a URI.
[0129] Distribution by copying the content is accomplished by a
digital voucher stored at a user's node in the network. The user's
node is the distributing terminal and can include the user's mobile
or wireless device. The digital voucher authorizes the distributing
terminal to cause the duplication of the specified primary or
secondary content that may be located in the distributing terminal
or elsewhere in the network. The receiving terminal can then
download the duplicated copy of the content, based on the terms
specified in the voucher.
[0130] As shown in FIG. 6, the Mobile Rights Voucher includes
support for the distribution of content using a "copy" intent and a
"give" intent These are only two of the building blocks used in the
creation of a content super distribution business.
[0131] The "copy" intent has the semantics to make a faithful
duplicate of the content resulting in a new instance with the same
specified rights (the "duplicate" here refers to the new instance).
The copier does not lose any rights to the content. The copied
assets may have to be regenerated if the voucher is "personalized"
(this will be discussed later). If a voucher does not contain a
"copy" intent element then the specified assets and vouchers cannot
be copied (or given). The copy operation is achieved using the
Mobile Rights Voucher format, the user agent behavior, and some
protocol elements. An understanding of copy will require reading
each of these sections.
[0132] The "copy" intent element specifies that the asset(s)
defined in the enclosing usage are to be duplicated in preparation
for forwarding. The forwarding is a feature supported by the
application; Associated with a "copy" intent element are the usual
constraints that have been discussed above and the "copy" intent
must only be invoked if there is no satisfied constraint.
[0133] Also included with the "copy" intent is the narrow element.
In the narrow element one must either specify the references for
the vouchers that are to be duplicated in addition to the assets
and then associated with those assets for forwarding, or if no
voucher is specified the enclosing voucher is assumed to be
implicitly specified. This perpetuated the requirement for voucher
identifiers. The additional vouchers are external to the original
voucher and could even be located on a separate system although
this would greatly affect implementation.
[0134] FIG. 6 illustrates the distribution of content in a mobile
environment using the Mobile Rights Voucher copy intent. In FIG. 6,
a user (not shown) coupled to distributing terminal 200 purchases
some digital content and is copying or forwarding the digital
content to receiving terminal 240. Resident in the memory of
distributing terminal 200 is content store 600 and voucher store
610. Content store 600 includes two pieces of digital content,
primary content 602 and secondary content 604. Voucher store 610
includes two vouchers, primary voucher 612 and secondary voucher
614. Primary voucher 612 is a "full rights" voucher that allows the
user to render the content as many times as necessary, but
eliminates the fear of leaking rights by not allowing the
duplication of the content. Primary voucher 612 includes pointers
to primary content 602 and secondary content 604. Secondary voucher
614 is a "preview" voucher that distributes a preview or one-time
copy of the content to another user. Secondary voucher 614 includes
pointers to primary content 602 and secondary content 604. Primary
voucher 612 includes a reference, in the narrow element, to
secondary voucher 614. Secondary voucher 614 includes a reference,
in the narrow element, to secondary voucher 614 to itself that
allows secondary voucher 614 to create a duplicate of itself.
[0135] If an application supports the Mobile Rights Voucher copy or
forwarding feature, the user can invoke a forwarding operation to
copy the content to another user coupled to receiving terminal 240.
The "copy" intent associated with primary voucher 612 duplicates
primary content 602 as primary content 622, and signals secondary
voucher 614 to duplicate secondary content 604 as secondary content
624 and duplicate secondary voucher 614 as duplicate voucher 632.
When the forwarding operation is complete, primary content 622,
secondary content 624, and duplicate voucher 632 are resident in
the memory of receiving terminal 240. Furthermore, duplicate
voucher 632 includes pointers to primary content 622, secondary
content 624, and a reference, in the narrow element, to itself that
allows duplicate voucher 632 to create a duplicate of itself.
[0136] A "personalized" voucher is a voucher that contains
information that is specific to the terminal to which it is being
sent. The "personalized" voucher includes individual and protection
elements and sometimes includes admin and transaction elements. For
any of these elements, but especially individual and protection, it
will be necessary to regenerate the copied voucher before it can be
forwarded to another user. This is performed either on the terminal
itself or on the network. Terminals must not modify vouchers for
Mobile Rights Voucher release 1 except for identifier regeneration
during copy. There are significant side affects that make
sufficient implementation very difficult. Any regeneration of a
voucher must take place at a Voucher server on the network. There
is a protocol for this that is explained later.
[0137] The "give" intent has the semantics that one gives away
rights to another party. Thus, after invoking the "give" intent,
the giver may be left with no rights to the given content. The give
operation is very similar to the copy operation described above
with the following key differences.
[0138] The content is duplicated similar to the copy operation,
however, the given usage rights are removed from the givers
voucher. In fact, the vouchers are queued for delivery to the
target terminal. The giver creates a "no-rights" voucher in the
place of the given voucher. This is achieved by duplicating the
original voucher and then removing the intents from the usage
block. It is useful for giver to maintain the admin and transaction
information from the original voucher.
[0139] Again there is an issue of "personalized" vouchers such that
the give would have to involve a regeneration process of the given
voucher. The issues are the same as with copy. Thus, give is
performed with the aid of an intermediary voucher server rather
than performing the give from one terminal to another.
[0140] The remaining rights differ from the "copy" intent. When a
voucher is given to another party only the remaining rights from
that voucher can be given. In this scenario, the giver uses an
intermediary voucher server rather than performing the give from
one terminal to another.
[0141] Usage rights may be defined as unlimited or limited. In the
case of unlimited rights, remaining rights are always equal to
original rights.
[0142] Limited rights fall into one of two categories, rights that
are unaffected by actual usage, and rights that are reduced by
usage.
[0143] Limited rights that are unaffected by usage include "the
right to use an asset until a specified datetime". The remaining
rights of the asset is "until that date and time".
[0144] Limited rights that are affected by usage include "use the
asset COUNT number of times" and "use the asset for INTERVAL number
of seconds" (not in Mobile Rights Voucher, Release 1). The
remaining rights of the asset are the COUNT or INTERVAL currently
unused. Use is defined as either PLAY/DISPLAY/etc. or GIVE.
[0145] Copy must not take account of remaining rights. When copy is
invoked on a voucher it must make an exact duplicate of the
expressed rights.
[0146] End-to-end solutions are required to protect content and the
vouchers that authorize use of that content. There are three areas
in which content may be attacked by hackers within a
closed-distribution mobile environment If a closed environment is
undesirable or is too expensive to achieve, the only alternative is
to ensure that the content is protected. This will require that
parts of the voucher also be protected.
[0147] First, content is subject to attack by hackers in a
closed-distribution mobile environment on the Service Provider
server. Protection on the server is achieved by implementing proper
secure environments and premises combined with appropriate
mechanisms to guarantee that only paying customers have access to
the content Since the compromise of a server will result in theft
of all content, similarly strong security is assumed for server for
all categories of time value of content.
[0148] Second, content is subject to attack by hackers in a
closed-distribution mobile environment while in transit from the
Service Provider to the device. Technologies for securing content
in transit include secure socket layer (SSL) or wireless transport
layer security (WTLS) for session-based protection and encrypted
content and vouchers that do not depend upon encrypted
communication lines.
[0149] Third, content is subject to attack by hackers in a
closed-distribution mobile environment while stored on the device.
It is important to note that even if content is protected while in
transit, once it is stored in the device it is vulnerable to
attack. Solutions include hardware and tamper resistance
techniques, persistently protecting the content using encryption
techniques such as RSA or Diffie-Hellman encryption, and a
combination of tamper resistance and encryption. The protection
strategy depends on features of the device and the time-sensitive
nature of the content.
[0150] The Mobile Rights Voucher can be used in solutions where the
content is of a very low value but is distributed in a very large
volume. In this environment, distribution costs are very low. In
addition, the need for protection is balanced with the content
value, cost of protection (terminal and network infrastructure) and
the consumer usability issues.
[0151] If the Mobile Rights Voucher protects the operating
environment, it is not possible for content with associated Mobile
Rights Voucher vouchers to be distributed outside the operating
environment. This is termed a "closed system" approach. The major
cost in this solution is to engineer terminals that will respect
this restriction for content with vouchers and to ensure that
inter-operating terminals (developed by other vendors) will also
respect the closed system requirement On the other hand, if the
Mobile Rights Voucher protects the content, even if content is
leaked it is unusable due to the protection. Encryption is the
typical mechanism used to achieve this. The major cost in this
solution is the creation of a terminal key for each terminal and
protecting those keys and the associated key infrastructure
required for managing the system.
[0152] Mobile Rights Voucher will support basic protection
facilities. It is possible that the assets referenced in the
voucher are protected (e.g. using encryption). If the assets are
protected, a protection instrument (e.g. decryption key) would be
necessary to open the asset. This protection instrument could
arrive to the consuming device prior to the purchase, with the
purchase, or as part of a separate transaction. If the protection
instrument arrives prior to the purchase, an instrument can be
manufactured into the device or provisioned to the device. If the
protection instrument arrives with the purchase, the instrument can
be delivered to the device in a voucher as part of the asset
purchase transaction. If the protection instrument arrives as part
of a separate transaction, the instrument can be delivered to the
device by means other than a voucher as part of the asset purchase
transaction.
[0153] The Mobile Rights Voucher accounts for the protection
instrument arriving with the purchase. The Mobile Rights Voucher
supports this with a protection element that can carry the
protection instrument (e.g. a decryption key) that can open the
protected asset(s). Since protecting assets without protecting the
protection instrument that can open the asset provides little
additional security, it is reasonable to expect that the protection
instrument will itself be protected (e.g. by encryption). If the
protection instrument is secured in some way there is a system
external to the voucher system which enable access to the secured
protection instrument. This part of the protection scenario is
outside the scope of Mobile Rights Voucher.
[0154] The Mobile Rights Voucher protection element is a container
for meta-information for protection related information that might
be transmitted with the voucher. Since ODRL does not support any
protection features, the Mobile Rights Voucher is adding these
protection features to the ODRL specification.
[0155] The XML embodiment of the Mobile Rights Voucher defines the
following headers for use with either an HTTP header or a MIME
header. These headers have been defined for the purpose of
exchanging vouchers between entities. For different transport
systems the following are replicated. These are needed to support
content distribution where the voucher requires regeneration from a
Voucher Server.
4 x-mrv- Used to indicate to a voucher server that the
giveVoucherSend associated voucher is to be handed to another
entity. The final receiving entity will identify itself using the
x-mrv-drv-voucherIndex header. The element can take the parameters
"req" and "resp". x-mrv-voucherIndex Used to indicate to the
receiver that the attached voucher should be used to automatically
retrieve a new voucher from the location defined by the ADMIN
element definition. It is possible that the Voucher Server would
attempt to authenticate the receiver at this point. Accept-content
Takes a list of accepted media types as parameters. If the device
indicates that it supports the Mobile Rights Voucher media type it
also must adhere to the roles of at least the MIN profile.
x-mrv-mode Indicates to the receiver which versions of Mobile
Rights Voucher are supported by the client.
[0156] The source terminal of the copy operation can send the
voucher to be copied, as well as the asset, to the destination or
target terminal of the copy operation. The voucher may be defined
using a narrow attribute.
[0157] FIG. 7 illustrates the Mobile Rights Voucher
non-personalized copy process for sending a preview copy of
protected digital content. In FIG. 7, a user (not shown) coupled to
distributing terminal 200 purchases some digital content and wants
to send an unedited preview copy of the digital content to
receiving terminal 240. Primary content 702, primary voucher 712,
and secondary voucher 714 are resident in the memory of
distributing terminal 200. Primary voucher 712 is a "full rights"
voucher that allows the user to render the content as many times as
necessary, but eliminates the fear of leaking rights by not
allowing the duplication of the content Primary voucher 712
includes pointers to primary content 702 and a reference, in the
narrow element, to secondary voucher 714. Secondary voucher 714 is
a "preview" voucher that distributes a preview or one-time copy of
the content to another user. Secondary voucher 714 includes
pointers to primary content 702, and a reference, in the narrow
element, to itself that allows secondary vouchcr 714 to create a
duplicate of itself.
[0158] If an application supports the Mobile Rights Voucher
non-personalized copy feature, the user can invoke a forwarding
operation to copy the content to another user coupled to receiving
terminal 240. When the user selects to send a preview voucher to
receiving terminal 240, the distributing terminal 200 retains the
rights to primary content 702 and continues to maintain primary
voucher 712 and secondary voucher 714. The "copy" intent associated
with secondary voucher 714 duplicates secondary voucher 714 as
duplicate voucher 732 and duplicates primary content 702 as primary
content 722. Distributing terminal 200 may transfer primary content
722 and duplicate voucher 732 to receiving terminal 240 separately
or as a single unit. When the non-personalized copy is complete,
primary content 722 and duplicate voucher 732 are resident in the
memory of receiving terminal 240. Furthermore, duplicate voucher
732 includes a pointer to primary content 722, and a reference, in
the narrow element, to itself that allows duplicate voucher 732 to
create a duplicate of itself.
[0159] The protocol for a personalized give covers the case when a
regeneration of a voucher is necessary such as changing the
protection, removing personal information in an admin or
transaction, and updating individual constraints. A "give" intent
require attention to the remaining rights because the receiver must
not receive more rights than there are remaining on the giver's
terminal.
[0160] The client knows when a voucher regeneration is required if
it is to give a voucher to a target and his own voucher is
personalized, or if the usage rights defined by the narrow
attribute indicate that the voucher is personalized for himself
rather than the intended receiver.
[0161] The client sends a copy of his voucher to the voucher server
using an HTTP POST operation. The voucher server recognizes the
give intent semantics by the header "x-mrv-giveVoucherSend" with
the parameter "req". The voucher server responds with a "given
voucher reference" when the giving entity receives this reference
he has logically performed the give operation, and lost usage
rights. The given voucher reference is a voucher that includes the
administrative information, that includes the reference index, and
no rights to the asset. The response message includes the header
"x-mrv-giveVoucherS end" with the parameter "resp".
[0162] The reference index is formatted as a parameter to the
administrative URI. The format of this parameter is up to the
voucher server. The mechanism to transport the "given voucher
reference" can be done by any peer-to-peer transport mechanism that
both entities are known to support and should be identified in the
header with a "x-mrv-voucherIndex" element.
[0163] The target client receives the reference voucher,
potentially in combination with the asset, and contacts the voucher
server defined by the administrative element, and the parameters
that identify the particular voucher. The voucher server recognizes
the give semantics by the unique administrative URI that is used by
the client. The voucher server responds with a new personalized or
protected voucher.
[0164] The giving entity does not at any point know the identity of
the receiving device. This makes the "give" process light-weight,
and even anonymous between the two parties of the transaction, with
only reasonable compromise to security. The giving entity does only
need to know the "messaging address" of the intended give
receiver.
[0165] The "give" mechanism and the transactions between clients
and voucher server are fully automatic. User interactions should
not be inserted in the client-server interaction. The mechanism
above can be described as "I want to give this content to someone
to whom I will give the index created by the voucher server".
[0166] Distribution by giving the content is accomplished by a
digital voucher stored at a user's node in the network. The user's
node is the distributing terminal and can include the user's mobile
or wireless device. For example, the digital voucher can authorize
the distributing terminal to cause the giving of a preview copy of
a digital asset to a receiving terminal. The digital asset may be
located in the distributing terminal or elsewhere in the network.
The user invokes a give operation in the distributing terminal, to
send a copy of a secondary voucher specifying the preview rights,
to a voucher server. The voucher server recognizes the give
operation and responds with a reference voucher that includes an
indication of no rights to the primary content. The distributing
terminal receives the reference voucher from the voucher server.
The distributing terminal then sends the reference voucher to the
receiving terminal. The receiving-terminal can then send a request
to the voucher server, requesting a new secondary voucher. The new
secondary voucher confers the same preview rights onto the
receiving terminal as are available to the distributing terminal.
Later, the receiving terminal can purchase a primary voucher from
the voucher server, to obtain the same rights to the primary
content as are possessed by the distributing terminal.
[0167] FIG. 8 illustrates the protocol for the Mobile Rights
Voucher personalized give process for sending a preview copy of
protected digital content. In FIG. 8, a user coupled to
distributing terminal 200 purchases some digital content and wants
to send an unedited preview copy of the digital content to
receiving terminal 240. Primary content 802, primary voucher 812,
and secondary voucher 814 are resident in the memory of
distributing terminal 200. Primary voucher 812 is a "full rights"
voucher that allows the user to render the content as many times as
necessary, but eliminates the fear of leaking rights by not
allowing the duplication of the content. Primary voucher 812
includes pointers to primary content 802 and a reference, in the
narrow element, to secondary voucher 814. Secondary voucher 814 is
a "preview" voucher that distributes a preview or one-time copy of
the content to another user. Secondary voucher 814 includes
pointers to primary content 802, and a reference, in the narrow
element, to itself that allows secondary voucher 814 to create a
duplicate of itself.
[0168] If an application supports the Mobile Rights Voucher
personalized give feature, the user can invoke a forwarding
operation to copy the content to another user coupled to receiving
terminal 240. When the user selects to send a preview voucher to
receiving terminal 240, a copy of secondary voucher 814 is sent to
voucher service 840 using the "x-mrv-giveVoucherSend" HTTP POST
header. Voucher server 840 responds to distributing terminal 200
with a "given voucher reference". Distributing terminal 200
forwards the "given voucher reference" to receiving terminal 240,
the target of the give operation. The asset may also be sent during
this transmission with a "no-rights" voucher. At this point,
distributing terminal 200 deletes primary voucher 812, leaving only
secondary voucher 814, a "no rights" voucher. Receiving terminal
240 sends a message to voucher service 840 requesting the
regenerated voucher on presentation of the "given voucher
reference". Voucher service 840 responds to receiving terminal 240
with the regenerated voucher such that it only contains the
remaining rights and the personalized information is changed for
the new target.
[0169] If digital content is meant to have rights associated with
it, and those rights will be delivered independent of the content
and possibly after content distribution to the terminal, there is a
need to express concisely that the user `currently` has no rights
to the content. Thus, the main requirement for Mobile Rights
Voucher Subset A is the expression of "no-rights".
[0170] The following is an exemplary voucher that demonstrates the
minimal "no-rights" voucher with an assumed asset:
5 <rights> <usage> <asset></asset>
</usage> </rights>
[0171] The above example is the minimum because the usage contains
no asset declaration. This implies that this voucher is associated
with the content in the same package whether a MIME multi-part or
an MMS package.
[0172] The following is an exemplary voucher that demonstrates the
minimal "no-rights" voucher with a declared asset:
6 <rights> <usage> <asset>
<uid>mid:batmanlogo345684567@city.fi</u- id>
</asset> </usage> </rights>
[0173] The above example declares the asset to allow for
independent delivery of the asset and content. This voucher
supports automatic content delivery and user initiate content
request.
[0174] The following is an exemplary voucher that demonstrates a
"no-rights" voucher with a declared asset and an administrative
identifier:
7 <rights> <admin>
<uid>http://www.media-sampo.com/</uid> </admin>
<usage> <asset>
<uid>mid:batmanlogo345684567@city.fi</uid>
</asset> </usage> </rights>
[0175] The above example declares the asset to allow for
independent delivery of the asset and content. This voucher
supports automatic content delivery and user initiate content
request The addition of the "admin" tag enables the user to contact
the voucher service or a retail service to buy a voucher with
rights for the specified content.
[0176] The Mobile Rights Voucher Subset B requirements are to
support content preview, content save, and simple forwarding
enabled or disabled. The content types that Mobile Rights Voucher
Subset B supports include ringing tones, operator logos and command
line interface (CLI) graphics, screen savers, and Java
applications.
[0177] The following is an exemplary voucher that demonstrates the
independent content preview capability with forwarding disabled
(i.e., no copy intent):
8 <rights> <usage> <asset></asset>
<display> <constrain> <count>1</count>
</constrain> </display> </usage>
</rights>
[0178] Since the usage tag in the above example does not contain an
asset declaration, it has an implicit reference relationship with
the content object. The asset is visual because the intent is to
display. The intent is further constrained to display the content
only one time. This means it is a preview and one may not want it
saved on the device, but note that even if the content is saved the
count will be used up after one. When the usage count decreases to
zero, it is safe to leave the content in the device because the
preview voucher will indicate that no usage rights exist for the
preview voucher. Finally, as there is no copy clause in the voucher
the asset is forwarding disabled. This happened by default when
copy elements are not present.
[0179] The following is an exemplary voucher that demonstrates the
independent content preview capability with forwarding enabled
(i.e., a copy intent):
9 <rights> <usage> <asset></asset>
<display>
<constrain><count>1</count></constrain>
</display> <copy></copy> <!- this will enable
forwarding --> </usage> </rights>
[0180] The above example is similar to the previous example with
the addition that the implicit reference to the asset and the
implicit voucher itself can be copied for distribution (i.e.,
forwarding is enabled).
[0181] The following is an exemplary voucher that demonstrates the
independent content save or full rendering rights capability and
including forwarding disabled (i.e., no copy intent):
10 <rights> <usage> <asset></asset>
<display></display> </usage> </rights>
[0182] Since the usage tag in the above example does not contain an
asset declaration, the voucher is associated with the content in
the same package whether a MIME multi-part, a MMS or a generic XML
package. The asset is visual because the intent is to display.
Since the intent is not constrained, the content can be saved to
the terminal as there are remaining rights and the content is
likely to be used repeatedly.
[0183] The following is an exemplary voucher that demonstrates the
voucher when it is embedded into a generic XML package:
11 <Generic XML Container> <Version>1.0</Version>
<Content> <Meta> <rights> <usage
xmlns="MRVsubsetb1.0"> <asset></asset>
<display></display> </usage> </rights>
</Meta> <Type>vnd.nok.screensaver</Type>
<Format>b64</Format> <Data> <!--Base64 encoded
content information-- .sup. --Base64 encoded content information--
.sup. --Base64 encoded content information-- .sup. --Base64 encoded
content information-- .sup. --Base64 encoded content information--
.sup. --Base64 encoded content information--> </Data>
</Content> </Generic XML Container>
[0184] In the above example, the fill display rights are embedded
into a Smart Content Object package and associated with the content
element of the parent of the Smart Content Object. The voucher is
very small.
[0185] The following is an exemplary voucher that demonstrates the
voucher when it is embedded into a MIME multi-part package:
12 MIME-Version: 1.0 Content-type: multipart/mixed;
boundary="simple boundary" --simple boundary Content-type:
text/MRV; <rights> <usage>
<asset>mid:1@a.b</asset> <display></displa-
y> </usage> </rights> --simple boundary
Content-type: vnd.nok.screensaver; Content-transfer-encoding:
base64 Message-ID: <1@a.b> --base64 encoded content
information --base64 encoded content information --base64 encoded
content information --base64 encoded content information --base64
encoded content information --simple boundary--
[0186] In the above example, the fall display rights are embedded
into a MIME multi-part package and associated with the content
element of the parent voucher. Thus, the voucher is very small.
[0187] FIG. 9 depicts a network environment for distributing a
Mobile Rights Voucher that presents voucher related issues and
example vouchers. In the use case scenario shown in FIG. 9, a
sending user (not shown) coupled to sending terminal 900 accesses
content service 930 and voucher service 940 via cellular network
130 to purchase two screen savers. Since the sending user is happy
with the purchase, sending terminal 900 forwards a preview copy of
the screen savers to receiving terminal 910 via personal area
network 120. A receiving user (not shown) views the preview copy of
the screen savers to evaluate the screen savers. If the receiving
user is happy with the screen savers, receiving terminal 910 can
purchase a full-right version of the screen savers from content
service 930 and voucher service 940 via cellular network 130.
[0188] In the first step in the use case scenario, when sending
terminal 900 purchases two screen savers, his terminal receives an
MMS message that contains two assets, one for each screen saver.
The MMS message also contains a full rights voucher and a preview
voucher. The full-right voucher is personalized for sending
terminal 900 and supports forwarding a preview copy to another user
for a limited period of time. The preview voucher allows a one-time
preview of the assets and supports forwarding of the preview
voucher to another user for a limited period of time and contains a
reference to a service where another user can purchase a full
voucher.
[0189] An exemplary full voucher for sending terminal 900 may
appear as follows:
13 <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE rights
SYSTEM "C:.backslash.MRV1.0-subsetC.dtd"> <rights
xmlns:xlink="MRV1.0.3" xmlns="MRV1.0.3">
<version>1.0.3</version> <admin>
<uid>http://www.media-sampo.com/ScreenSaverService</uid>
`2</admin> <transaction>TID:3457345987-6789-9<-
/transaction> <usage> <asset>
<uid>mid:tropicalsunset.345658347@digitalshop.com</uid>
<!--<protection>content protection would go
here</protection>--> </asset> <asset>
<uid>mid:underwaterdivert.345658347@digital-
shop.com</uid> <!--<protection>content protection
would go here</protection>--> </asset>
<display></display> <copy> <constrain>
<datetime> <end>20010830</end> </datetime>
</constrain> <narrow>
<uid>mid:previewvoucher.343453344@digitalshop.com</uid>
</narrow> </copy> <constrain>
<individual><uid>IMEI:123456789123459</uid></i-
ndividual> </constrain> </usage>
<!--<protection>The integrity would go
here</protection>--- > </rights>
[0190] In the exemplary full voucher shown above, the "admin"
element points to the service where the voucher was purchased. Some
personal transaction information is delivered for sending terminal
900. Assets are declared. There is a full rights voucher for
display of the screen savers. There is a time limited copy intent
that can copy the content and only the preview voucher. Finally,
the individual constraint at the usage level locks this voucher to
the sending terminal 900 terminal for all intents, therefore, it is
not necessary to declare it multiple times.
[0191] The preview voucher for sending terminal 900 would appear as
follows:
14 <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE rights
SYSTEM "C:.backslash.MRV1.0-subsetC.dtd"> <rights
xmlns:xlink="MRV1.0.3" xmlns="MRV1.0.3">
<version>1.0.3</version> <admin><uid>htt-
p://www.media-
sampo.com/ScreenSaverService</uid></admin&g- t;
<usage> <asset>
<uid>mid:tropicalsunset.345658347@digitalshop.com</uid>
<!--<protection>content protection would go
here</protection>--> </asset> <asset>
<uid>mid:underwaterdivert.345658347@digital-
shop.com</uid> <!--<protection>content protection
would go here</protection>--> </asset>
<display> <constrain> <count>1</count>
</constrain> </display> <copy> <constrain>
<datetime> <end>20010830</end> </datetime>
</constrain> <narrow>
<uid>mid:previewvoucher.343453344@digital-
shop.com</uid> </narrow> </copy> </usage>
<!--<protection>The integrity would go
here</protection>--> </rights>
[0192] Note that the above preview voucher does not contain any
transaction information, the preview is not locked to any terminal
by use of individual, the preview is limited to a single viewing,
and the voucher allows itself to be forwarded for a limited period
of time.
[0193] In the second step in the use case scenario, when sending
terminal 900 forwards a preview voucher to receiving terminal 910,
receiving terminal 910 receives an MMS message that contains two
assets, one for each screen saver. The MMS message also contains a
preview voucher that allows a one-time preview of the assets and
supports forwarding of the preview voucher to another user for a
limited period of time and contains a reference to a service where
another user can purchase a full voucher.
[0194] The preview voucher for receiving terminal 910 is the same
as the preview voucher for sending terminal 900. Receiving terminal
910 can preview the screen savers with the preview voucher.
Receiving terminal 910 will preview the screen savers and decide if
he wants to purchase his own full rights copy of the screen savers.
If he decides to purchase the screen savers he would select this
option on his terminal. The preview contains a reference in the
"admin" tag to a Voucher Service that retains a fill right voucher
that receiving terminal 910 can purchase. As a response to the
request to purchase a full rights voucher, receiving terminal 910
will receive the following voucher that will give him the same
rights as sending terminal 900.
15 <!xml version="1.0" encoding="UTF-8"?> <!DOCTYPE rights
SYSTEM "C:.backslash.MRV1.0-subsetC.dtd"> <rights
xmlns:xlink="MRV1.0.3" xmlns="MRV1.0.3">
<version>1.0.3</version> <admin>
<uid>http://www.media-sampo.com/ScreenSaverService</uid>
</admin> <transaction>TID:3647589987-5677-9</-
transaction> <usage> <asset>
<uid>mid:tropicalsunset.345658347@digitalshop.com</uid>
<!--<protection>constant protection would go
here</protection>--> </asset> <asset>
<uid>mid:underwaterdivert.345658347@digita-
lshop.com</uid> <!--<protection>content protection
would go here</protection>--> </asset>
<display></display> <copy> <constrain>
<datetime> <end>20010830</end> </datetime>
</constrain> <narrow>
<uid>mid:previewvoucher.343453344@digitalshop.com</uid>
</narrow> </copy> <constrain> <individual>
<uid>IMEI:343586722223454- </uid> </individual>
</constrain> </usage> <!--<protection>The
integrity would go here</protection>-->
</rights>
[0195] In the third and final step in the use case scenario, when
receiving terminal 910 decides to purchase a full-rights version of
the screen savers, receiving terminal 910 receives an MMS message
that contains two assets, one for each screen saver. The MMS
message also contains a preview voucher that allows a one-time
preview of the assets and supports forwarding of the preview
voucher to another user for a limited period of time and contains a
reference to a service where another user can purchase a full
voucher.
[0196] Another embodiment of the Mobile Rights Voucher maps the
Mobile Rights Voucher DTD into a single Wireless Application
Protocol (WAP) Binary XML (WBXML) code space. WBXML is a binary
representation of XML that is designed to reduce the transmission
size of XML documents and allows more effective use of XML data on
narrowband communication channels. The Mobile Rights Voucher DTD is
assigned the WBXML document public identifier associated with the
Formal Public Identifier (FPI) such as "-//NOKIA//DTD Mobile Rights
Voucher 1.0//EN". The Mobile Rights Voucher format DTD is mapped
into tokens from a single code page, "00", associated with the FPI
"-//NOKIA//DTD Mobile Rights Voucher 1.0//EN". The following WBXML
token codes represent elements (i.e., tags) from the code page x00
(zero) of the Mobile Rights Voucher DTD. The WBXML encoding of the
XML elements is shown in Table 1.
16 TABLE 1 WBXML Tag Token XML Type Name (Hexadecimal Value) Rights
05 Version 06 Admin 07 Uid 08 Transaction 09 Protection 0A Usage 0B
Asset 0C Rightsholder 0D Print 0E Display 0F Play 10 Execute 11
Copy 12 Give 13 Narrow 14 Constrain 15 Count 16 Start 17 End 18
Datetime 19 Individual 1A
[0197] Using Independent Clearinghouses for Monitoring Digital
Rights Transfer Transactions
[0198] An important aspect of digital rights management is the
design of mechanisms that can enable various types of revenue
sharing among the players involved (e.g., publishers, resellers,
etc.). This invention proposes a flexible and scalable
mechanism.
[0199] New copies of digital content can be created effortlessly.
This enables large-scale distribution and super-distribution of the
content. To share revenue effectively, the creation of new copies
needs to be accurately monitored. Typically, a clearinghouse
monitors the copies and may be tightly integrated with the DRM
system (e.g., a single global clearinghouse, or a single network of
clearinghouses).
[0200] The described scheme for reporting new copies is extremely
flexible. In the most general case, this scheme allows anyone to
run a clearinghouse. The device manufacturer may also choose to
limit the clearinghouse functionality only to clearinghouses
certified (directly or indirectly) by the manufacturer. Our scheme
also specifies the clearinghouse on a per-content basis (rather
than assuming a single global clearinghouse, or a single
clearinghouse network). This allows several independent
clearinghouse networks to exist in parallel. Further, the method
provides for dormant rights.
[0201] We assume that the rights for a copy of some content are
encoded in a voucher in such a way that only the intended compliant
device will be able to use that copy. This does not prevent the
device from giving away its rights to another device, by creating a
new voucher and deleting its own. A voucher contains information
about the clearinghouse responsible for that content and may
include the name of the clearinghouse, its public signature
verification key, and a network address (e.g., URL) where the
creation of new copies of this content can be reported. The voucher
also specifies whether the device importing the voucher needs to
report the existence of the copy to the clearinghouse.
[0202] When a voucher is imported to a compliant device, the device
will perform the following checks:
[0203] 1. Whether this copy should be reported?
[0204] 2. If the copy should be reported, does the device have a
way of reporting to the clearinghouse specified by the voucher? If
not, mark the voucher as disabled in this device.
[0205] 3. If the copy does not need to be report, import the
voucher and mark it as enabled in this device, subject to any other
restrictions.
[0206] 4. After the copy is reported, the voucher will be marked as
reported, so that it need not be reported again.
[0207] When a compliant device makes a new copy for another device
(e.g., during super-distribution), it may either report the copy to
the clearinghouse by itself, or set a flag in the new voucher so
that the receiving device will report it. Note that if the
receiving device cannot report the copy, the voucher will be marked
as disabled in that device. But the receiving device may still
either give the right away, or make new copies for other devices.
Effectively, this allows devices to act as a vector that carries a
dormant right. Super-distribution of receiver-reported copies is
even allowed when the super-distributor does not have the right to
use the content. Dormant rights will become active if and when the
rights arrive at a device that can report them to the
clearinghouse. This may increase the scope and speed of
super-distribution, just as biological vectors increase the scope
and speed of infection.
[0208] Independent mechanisms may be used to control how the
reporting is to be done (e.g., on-line or off-line, whether
reporting may be delayed until network connectivity is obtained,
how to limit use while report is pending etc.). These independent
mechanisms require the registration of devices with one or more
clearinghouses. But the devices could still import and use vouchers
referring to other clearinghouses if the device can find a suitable
trust chain (starting from the clearinghouses mentioned in the
voucher and ending in a clearinghouse with which the device is
registered). If not, step 2 above will fail.
[0209] A manufacturer may configure its devices so that it will
only agree to report to clearinghouses that are certified by the
manufacturer. In this case, when a voucher is imported, the device
will check whether a manufacturer (directly or indirectly)
certifies the specified clearinghouse. If not, step 2 above will
fail. Certifying clearinghouses may allow the manufacturer to
charge the certified clearinghouses. But technically, such a
certificate is not necessary. A compliant device may enforce
vouchers for any clearinghouse. This may enable widespread
grass-roots level publishing of content.
[0210] Charging-Independent Method for Containing Off-Line
Super-Distribution of Material with a Monetary Value in a DRM
Environment
[0211] One of the bigger hindrances of off-line (ad-hoc)
super-distribution is the collection of rights and other charges.
This invention formulates a method for partially guaranteeing that
all players in a DRM transaction eventually get their dues. The
solution has been developed with a mobile music player in mind, but
applies as well to any kind of digital content in a DRM scheme.
[0212] DRM infrastructures generally enforce protected distribution
and presentation of digital content so that digital rights can be
protected and necessary charges collected for the rights owners.
Payment or charging solutions, with the exception of some
electronic payment solutions, normally require network interaction
with a charging server of some sort. In an ideal DRM model, users
should be able to spread or move content between themselves in
various manners defined by the rights associated with the content.
One model allows content distribution to be charged for between
users outside of network coverage (only peer-to-peer connection
between users). This model usually either assumes the existence of
a payment scheme that is integrated with the DRM or that the
selling user has purchased additional rights in the first place
that he then can sell forward in the off-line case. Related
problems usually involve currency conversions, taxation
requirements and distribution of monetary value to all involved
partners in the distribution chain.
[0213] Previously, this problem was solved by:
[0214] 1. Enforcing a network connection through a ubiquitous
network connection (e.g. distribute content over infrared);
[0215] 2. Including a payment scheme in the DRM infrastructure;
and
[0216] 3. Requiring the purchasing user to purchase "additional"
rights in advance, in the form of a "season ticket" or
equivalent.
[0217] This solution is:
[0218] 1. Independent of the payment or charging mechanism; and
[0219] 2. Makes ad-hoc or "spur of the moment" distribution of
content available while still restricting the monetary risk for the
involved rights owners.
[0220] Thus, the problem involves how to support off-line
super-distribution, that is, if you give me a copy, so that the
recipient can use the content right away without having to contact
some voucher server. One solution is to rely on taniper-resistance
and delayed reporting. Another solution is to use "season tickets".
Each user registers with a clearinghouse and receives a certificate
of his signing key. This certificate is the "season ticket" (it may
be valid for a short time, and will have limits on the number of
transactions it can perform). For user A to super-distribute a copy
of the season ticket to user B, user B gives user A a signed
statement for the amount. User A can verify this signature against
the certificate or season ticket issued to user B by the
clearinghouse. When user B receives the voucher, he can use the
content immediately. All of these steps happen off-line. The next
time user A is on-line, user A can submit the signed statement to
the clearinghouse. The clearinghouse can then either bill user B or
deduct the amount from a pre-paid account. The clearinghouse can
also give user A credit for the sale (e.g., a payback, bonus, or
loyalty points) as an incentive to report the signature. The
"season ticket" scenario does not require tamper-resistance for
payments and will work is only one party is honest. The risk of
dishonesty or collusion by both parties is slight and can be
mitigated by integrating tamper-resistance as a second-line of
defense.
[0221] Most users behave more or less rationally. In this scheme we
let the users or devices acquire a certain amount of debt
(unrelated to any charging/payment mechanism) off-line, and tie
this debt to the DRM device. The debt is tied based on the rule
that the total value of the debt that can be run up by a device is
limited by the number of debt-increasing transactions so that the
total amount of debt will always be significantly less than the
perceived value of the device. So the user of the device is
motivated to clear the debt of the device the next time when he is
connected to the network by the fact that he again has the "whole
spending limit" to use in upcoming off-line situations.
[0222] Off-line transactions that can increase the debt of device
come in two forms. First, user A sells content to user B and
collects money immediately. In this case the debt will be tied to
the device associated with user A. No debt is tied to the buying
user. Second, user A "sells or distributes" content to user B and
the buyer "promises" to pay later (when he comes into network
coverage again). In this case the debt will be tied to the device
associated with user B. No debt is tied to the selling user.
[0223] Since we want, at least in one case, to keep the system
unrelated to monetary complications like currency conversions, the
debt is limited to the number of debt-increasing trasactions rather
than the actual monetary value involved. This can be included as a
separate "counter" with the additional overhead of handling
currencies.
[0224] This system should be suitable for all involved partners.
System users will get the additional freedom of (to a certain
degree) distributing content among themselves, and the rights
owners will (eventually) get additional revenue streams from the
super-distribution.
[0225] The described system combines the generation of sample
playback copies and the purchase status of a certain content copy.
This means that when a copy of the content is purchased, a certain
number of distributable preview copies are "included in the price".
These may be given out or super-distributed to friends, who in this
scheme can receive a copy from the owner of the content and
playback the content one time. If a content is resold (B1 or B2
scheme), the newly generated copy will have the full number of
preview copies included whereas the copy count of the original may
or may not be upgraded to the full amount after a resell.
[0226] This invention describes and strives to protect a method for
limited super-distribution that can benefit a system that
incorporates the method. A more detailed description of the
protocols and security features involved (which are not relevant to
the idea itself) can be found in the TranSec protocol
descriptions.
[0227] Controlling the Downloading of Content in Digital Rights
Management Systems
[0228] Most of the Digital Rights Management (DRM) work so far has
focused on PCs or other special-purpose devices as the client
terminals. DRM for a portable device is of particular interest to
the mobile computing environment. An inherent limitation of a
portable device is lack of storage or memory.
[0229] Due to the lack of storage on portable devices, a user
cannot keep copies of all the content for which he bought rights.
He should be able to pay for the content once, use it, delete it to
use the storage space for some other purpose, but later download
the same content without having to pay again.
[0230] One approach is to assume that all copies of a given piece
of content are encrypted with the same key and that the encrypted
content is freely available for downloading from public sources
(e.g., public web-sites). This approach is implied (although not
explicitly stated), e.g., by the EBX E-book specifications.
[0231] Content files may be large. If anyone is allowed to freely
download the content files from public servers, an attacker may be
able to overwhelm the server by issuing bogus requests. This will
prevent legitimate users from downloading content.
[0232] This bandwidth exhaustion problem is especially severe in
public access wireless networks (e.g., a kiosk serving content via
Wireless LAN in a public hotspot).
[0233] This invention introduces methods to control access to
encrypted content files so that such a denial-of-service attack is
difficult to mount. In one embodiment, the invention also allows
the possibility of metering downloads.
[0234] Allowing anyone to download encrypted content may be
undesirable, for example, during peak hours. This requires a way to
perform controlled content transfers. One solution is to charge for
content downloads. Another solution is to require that the
receiving device prove its knowledge of the content encryption key
by constructing a download token in the form of a Message
Authentication Code (MAC). A third solution is to issue a download
certificate that certifies the receiving device at the time of
rights transfer and is useful to construct a download ticket
later.
[0235] Regardless of how the download token is constructed, the
basic controlled download protocol is as shown in FIG. 10.
Sender_challenge is a random challenge sent by the sender (e.g.,
content server). If a MAC is used, the Download_Token is derived by
the function:
"MAC(K, sender_challenge.vertline.CID)"
[0236] where MAC is a suitable MAC function (e.g., HMAC_SHA1), CID
is a unique identifier for the content and K is the universal
encryption key used for CID. The function createDownloadToken( )
takes CID as input and produces the Download_Token as output. A
device will be able to do this only if K is known, that is, it has
the rights for CID. The function verifyDownloadToken( ) takes CID
and the Download_token and computes the MAC and compares it with
the Download_token.
[0237] If Signatures are used, a Download_Certificate is issued to
the device at the time the right for CID is acquired for the
device. This certificate is issued by the entity that grants the
rights. For example, a public kiosk K could issue the
Download_Certificate of the form:
Sig(SK, V.sub.D.vertline.CID.vertline. . . . other info . . .
[0238] where S.sub.K is the signature key of the kiosk (with
corresponding verification key V.sub.K), V.sub.D is the signature
verification key of the device (with corresponding signing key
S.sub.D). "Other info" may include limitations like an expiry date.
The certificate asserts that the owner of V.sub.D has purchased the
rights for CID and is eligible for downloading the actual content.
The Download_Ticket is of the form:
Sig(S.sub.D, sender_challenge, CID), Download_Certificate
[0239] Any download server that knows the public key V.sub.K can
verify the Download_Certificate, and then the signature, and hence
limit download requests.
[0240] The features of the MAC-based approach are:
[0241] 1. It is simple; and
[0242] 2. Since the content key is universal, a requestor will be
able to produce a Download_Token that can be verified by any server
for that encrypted content. However, a server may want to
distribute the content to someone who got the rights from a
different server (or a server in a different domain). This could be
achieved by server-specific (or domain-specific) content keys
rather than global content keys.
[0243] The advantages of the Signature based scheme are:
[0244] 1. It is flexible in that additional constraints (such as an
expiry date for free downloads) may be encoded in the
Download_Certificate; and
[0245] 2. Since signatures cannot be forged, the download tokens
can serve as a way to accurately measure the number of downloads
for a given content. For example, advertisers are interested in
obtaining metering information that is not forged.
[0246] Methods to generate and evaluate message authentication
codes to insure the integrity of data are described in the book by
Stephen Thomas entitled SSL and TLS, published by John Wiley and
Sons, 2000. The RSA Message Digest (MD5) and the Secure Hash
Algorithm (SHA) are two example algorithms for message
authentication that are described in the book by Stephen Thomas.
Another reference that goes into greater detail in its discussion
of data integrity methods is the book by Bruce Schneier entitled
Applied Cryptography--2nd Edition published by John Wiley and Sons,
1996. Methods to generate and evaluate digital signatures to insure
the source of the digital program are described in the book by
Richard E. Smith entitled Internet Cryptography, published by
Addison Wesley, 1997. To insure that the source of the data cannot
be repudiated, a digital signature can be appended to the data, as
described in the book by Richard E. Smith.
[0247] Lending Rights to DRM Protected Content
[0248] The content is transferred from one consumer to another by
means of portable media such as compact disk or floppy disk. Prior
to transferring the content, the sender opens a transaction with a
clearinghouse and informs it about the transfer of rights. The
sender opens the existing license and then encrypts it with the
receiver's public key. The receiver can then use the loaned content
based on the business rules in the license. The content is returned
to the original sender in the same way as it was sent in the first
place.
[0249] Another way to transfer content is to send a reference to
the receiving consumer, which indicates where to get the new
license for the content. The receiving consumer then contacts the
clearinghouse and receives the new license via this connection.
This way the receiving consumer does not need to send it's public
key to the sender.
[0250] When the content is DRM protected, it cannot be lent to
another persons use in a traditional way because the license is
tied to one device at a time.
[0251] Many different implementations are possible and feasible.
The inventor suggests that the best implementation for GSM mobile
terminals could be SMS communication between the terminal and the
clearinghouse.
[0252] Flexible Content Binding Scheme
[0253] To prevent the widespread infringement of the copyright of
digital content such as movies, music, or electronic books,
different content protection and digital rights management systems
have emerged. There is a common requirement for all those systems;
they need to bind the content to something. There have been many
arguments over whether the right thing to do is to bind the content
to a piece of equipment (such as a certain PC, for instance), the
media on which the content is stored (memory card or hard disk, for
instance) or to the user. This invention makes this no longer an
"either-or" situation by allowing content to be bound to a
multitude of identities. The presence of even one of those
identities will enable the usage of the content.
[0254] When a file containing a piece of content is originally
purchased (e.g. downloaded from the Web), it is encrypted with a
randomly chosen Content Key. The Content Key is then encrypted with
a multitude of different IDs such as Device ID, Media ID and User
ID. All those encrypted versions of the Content Key are then
attached to the content. The content can then be freely moved
around in the encrypted format. When it is time to use the content,
the player software then tries the Device ID, the Media ID and the
User ID as keys for decrypting the Encrypted Content Key. As long
as even one of those identities matches, the correct Content Key is
recovered and the content can be decrypted.
[0255] Alternatively, in an environment where it is not possible to
keep the Device ID, Media ID or User ID secret, for instance
because the binding is done in a remote server, the Content Key may
be encrypted with a public key associated with or derived from such
IDs instead of the ID itself When the content is to be decrypted,
the private keys corresponding to the Device ID, Media ID or User
ID can be tried in sequence, whether they correctly decrypt the
Content Key. This invention also contemplates the use of various
combinations of IDs or related pairs of public keys and private
keys. This is just a matter of which IDs can be used without
exposing them.
[0256] The invention solves the "what to bind content to" issue by
allowing content to be bound to a number of different identities.
The problems with the existing binding methods that are related
only to a single identity are numerous. Binding to equipment can be
a problem in case the equipment breaks down or is lost for some
reason, or, for instance, replaced with a later model. Binding with
media does not permit backup copies, so if the media is destroyed,
the content is lost. Binding with a user might be most convenient,
but it often causes privacy concerns. It also prevents lending or
giving the content to a friend even if it is on the original
media.
[0257] In the past, there have been suggestions to use a database
to group different identities together to indicate that they are
all authorized to use the content. The invention disclosed herein
provides a simpler solution because there is no need for a special
database, and therefore no administrative overhead.
[0258] Implementation is pretty straightforward as part of a
content protection or DRM solution. They usually have already
solved the issue of binding content to a single ID. This invention
simply takes that idea a step further by allowing binding to a
multitude of different IDs.
[0259] Media IDs already exist for some memory cards and hard
disks. Device IDs are typically also an existing requirement for
devices that are used for DRM. They can be implemented using unique
serial numbers or pseudo-unique random numbers on the system chip
or related FLASH memory etc. On PCs existing IDs such as Ethernet
MAC addresses can also be considered The User ID is probably the
most challenging ID to assign, as the privacy concerns remain an
issue. One possibility would be to assign a non-unique (but
statistically close enough to unique) random number to each user at
the time for signing up for a service, for instance. This would
probably alleviate those concerns because it would be impossible to
positively identify the user (several users may get the same
ID).
[0260] Distributed Rights Gateway System in a Mobile
Environment
[0261] This invention relates to distributed rights management in
the context of mobility. This invention also utilizes a distributed
payment mechanism. Scenarios of right updating and
super-distribution are considered. Storage of rights remotely is
considered for device portability.
[0262] This invention is a model of highly distributed systems
suitable for mobile environments. Rights of ownership and usage of
a content for a mobile user is achieved through mutable and mobile
metadata associated with content. Distributed payment nodes control
the mutation of metadata. This metadata is solely responsible for
decision to let the user use content. This metadata is replicated
to a server near the user. If the device moves to a location closer
to another server, the user's rights in the form of Metadata is
transferred to this new server.
[0263] The invention aims to solve the problem of network latency
in acquiring rights to use content in a mobile device. This
invention also backs up rights in a server that is more reliable
than a mobile device and solves the problem of super-distribution
through rights portability.
[0264] Earlier solutions required generation or updating of rights
for a content from a remote retail site. Since there is only one
place where rights can be obtained, it is not the best solution for
mobile environments keeping network latency and fault tolerance in
mind.
[0265] By storing the rights in a decentralized fashion and also
updating them in a decentralized fashion through appropriate
payment nodes, this invention will minimize the network latency to
update rights for any content. The decentralization of rights
storage will help in their backup that is an important use case for
mobile devices. This invention emphasizes that only the payment
nodes are sufficient to update the rights. Earlier solutions do not
take payments into account when updating rights.
[0266] FIG. 11 depicts the architecture of the system and the
interrelationship between the different entities within the system.
A user (not shown) coupled to mobile device 1110 can purchase
rights from retail content service 110 using mobile device 1110.
The user would download content from the retail content service 110
through a secure channel. The content and Metadata will be
downloaded to mobile device 1110. A copy of this metadata is kept
in rights database 1124 associated with rights gateway 1120. When
the user wants to update his rights for content, be contacts rights
gateway 1120 through an agent on mobile device 1110. Rights gateway
1120 will use payment node 1122 to update the metadata associated
with the digital content The metadata is available in an encrypted
form and can only be updated by rights gateway 1120 after approval
by payment node 1122. The user will then download this metadata
with updated rights. The user is then free to continue using the
digital content. If the user wants to use the content in another
device, he can transfer the content to the other device. The device
that plays the digital content will look at the metadata to
identify if the user has adequate rights to use the content. If the
user wants to distribute the content to another user (recipient),
he will transfer the metadata associated with the content to the
recipient's rights gateway, rights gateway 1150. This gateway will
change the fields within the metadata such that it belongs to the
recipient and also contacts payment node 1152 to purchase the
rights. Once the rights are purchased, the recipient is free to
download content and its associated rights to his device for
usage.
[0267] A rights gateway such as rights gateway 1120 can perform the
following operations on the metadata:
[0268] 1. Mutate the metadata to reflect changes to rights and
rules associated with content and user,
[0269] 2. Obtain payment authorization to change the rights portion
of metadata;
[0270] 3. Send the payment data capture information to
clearinghouse 1140;
[0271] 4. Send the authorization reversal request message to the
backend payment system and change the rights associated with the
metadata accordingly;
[0272] 5. Handle an error returned by backend payment system;
[0273] 6. Handle super-distribution by exposing a method that
accepts a metadata and recipient ID, then changes the relevant
field of the metadata; and
[0274] 7. Interface with a terminal WIM card to authenticate a user
and change the metadata to establish ownership of the content.
[0275] This invention can be best implemented using a DRM
technology that provides a trusted environment for the various
components of the system. It is important that all the software
entities like payment nodes, rights gateway, and players are
trusted. The Nokia mPlatform standard, a comprehensive answer to
the challenge of setting up portals throughout national and
international networks, can be used as an interoperability standard
for payment nodes and rights gateway.
[0276] Voucher-Based Mobile DRM Architecture
[0277] Digital Rights Management is a technology providing
mechanisms for controlling consumption of digital content. DRM is
already being used to some extent in the wireline Internet domain,
but there is currently no wide-spread DRM system that is used in
the mobile domain. Today copy protection is done in the mobile
domain with so called forward-lock method in which the terminal
disables the ability to forward the piece of content (e.g.
ringing-tone) to another terminal.
[0278] One of the attractive features of DRM is super-distribution,
that is, the ability to forward content from peer-to-peer and still
enabling that the content owner gets paid for each copy. The
forward-lock method effectively kills super-distribution and thus
we need to discover other DRM mechanisms. The problem with
super-distribution is that once it is enabled, it is really
difficult to control the bits that are distributed from
peer-to-peer. That is a natural law of the digital world, bits are
inherently easy to copy and modify. Cryptography is the only
practical technology that can be used to control the content
consumption if super-distribution is used. That means that the
content is encrypted and the decryption key is delivered to those
terminals that have paid to consume the content.
[0279] In other words, DRM enables the paid content model, that is,
the content is paid for when it is consumed. Thus, payment is an
important function in any DRM system, although it can be considered
as separate to DRM.
[0280] The invention is the architectural model of the voucher
server based Mobile DRM system that enables one to utilize
cost-efficient mobile operator payment systems.
[0281] The novelty value of this invention comes from the
utilization of the mobile payment service provisioning also to
manage digital rights-related payment collection. In effect, this
means mobile optimizing the DRM system. The most obvious benefits
of this approach are the ability to utilize mobile network operator
payment systems, related agreements, and user interaction, and
minimization of the over-the-air information exchange between
mobile terminal and network.
[0282] The Internet-optimized DRM systems assume that payment is
done with some mechanism in the retail site but do not describe
how. That may be due to the lack of effective micro-payment and
mini-payment methods on the Internet (as compared with operator
billing in the mobile Internet). Thus, the common approach is to
separate the payment to be handled as, for example, Internet credit
card transaction.
[0283] We made the same error in our earlier thinking. Our original
architecture was similar to the others, but after reviewing that
with our mobile payment people we ended up turning the architecture
upside-down. We believe that this new model has novelty value and
is a practical way to implement Mobile DRM.
[0284] The following assumptions are made:
[0285] 1. Voucher-based DRM model is used, where a voucher enables
a terminal to access a specific piece of content;
[0286] 2. Super-distribution is enabled;
[0287] 3. Content can be separate from the voucher;
[0288] 4. Content can be unambiguously identified (Content ID);
[0289] 5. Voucher contains the content decryption key that is
encrypted for each terminal separately;
[0290] 6. Each terminal has a secret/private key that is specific
for that device;
[0291] 7. Each terminal has a DRM ID that can be used to discover
the terminal's public (if asymmetric algorithms are used) or secret
key (if symmetric algorithms are used);
[0292] 8. Payment Service Provider model is used for handling
payments;
[0293] 9. The end user has configured at least one Payment Service
Provider into his mobile terminal; and
[0294] 10. Payment server handles the user interface during voucher
acquisition.
[0295] The invention is one way to solve the generic problem that
all DRM solutions try to solve, that is, to enable the paid content
model where content owners get paid each and every time someone
consumes their content. The voucher model with content encryption
solves the copy protection part of the DRM, that is, it protects
the content owner from losing revenue due to end users illegally
copying and consuming the content.
[0296] The difficult problem in such a DRM system is to implement a
cost-efficient payment mechanism. Digital content for the mobile
domain is cheap (a few euros or less). In addition, it is likely
that the end user will buy vouchers from multiple Voucher Servers
(voucher retailers)--this is by design of the general voucher
model. And further on, super-distribution of digital content from
user to user via messaging implies that the content flows easily
over, for example, operator domains implying that an end user needs
to access Voucher Servers that are not located in his own
operator's domain. This is in line with our intention to reward the
top quality content creators with a possibility that their content
can populate the whole mobile domain. Further, the content
originators can use a relatively limited number of mobile payment
service providers (e.g., deals with all leading operators in a
given market) to conveniently to reach almost the whole market.
[0297] This all sums up to the fact that each end user will have to
pay a small amount of money to a large number of retailers
throughout the world. It is not cost-efficient for those retailers
to send invoices for small payments. It is also inconvenient for
the end user as well.
[0298] Our invention introduces the Payment Service Provider (PSP)
model into DRM. The Payment Server is run by an entity that has a
close relationship with the end user such as the mobile operator.
The PSP information (access point etc.) is configured into the
terminal by the end user. In most likely cases the PSP will be the
end user's own mobile operator--but this is not mandated in our
architecture. The PSP could be any party that has a flexible
billing mechanism based on a user friendly authentication
mechanism.
[0299] Mobile operators have access to the operator billing system
that is the most convenient payment mechanism for small payments.
And that can be based on user-friendly MSISDN authentication (i.e.,
authentication that employs the mobile identity number of the
mobile device), which can be done securely in the domain of a
single mobile operator (MSISDN authentication is not very secure
across operator domains). Further, the ease of authentication as a
part of phone signaling clearly is superior to usernames/passwords
that Internet-based systems have to rely on. Even though prior art
DRM systems exist, a wide-spread and "light-weight" mobile DRM is
novel.
[0300] Our invention enables one to use operator billing for all
DRM related payments by introducing the Mobile Payment Service
Provider model into DRM. The Mobile Rights Voucher architecture has
mobile optimizations and makes the Payment Service Provider the
"user interaction agent" instead of the retail site.
[0301] The disadvantage of this solution is the fact that Mobile
Payment Service Provider (mPSP) controls the user interaction with
the consumer. This principle is quite mobile-usage centric and not
as flexible as the Web model. However, the advantage of ease
authentication and consistent user experience by the mPSP
overweight this in mobile use.
[0302] FIG. 12 is an illustration that shows the interaction of the
architectural elements of the Mobile DRM system. The architectural
elements that comprise the Mobile DRM system include content server
1260, voucher server 1250, payment server or DRM Agent 1220, and
terminal 1210. Content server 1260 is a web server that is used to
distribute content to end users and content pieces with a Voucher
Server. Voucher server 1250 handles content registration requests
from Content Servers (price, optionally content encryption key
generation, optionally content ID generation) and handles also
voucher generation requests from Payment Servers (receives content
ID and terminal's DRM ID and generates in return a voucher for that
specific terminal and piece of content). Payment server or DRM
Agent 1220 handles user interface during voucher acquisition,
communicates with a back-end payment mechanism (e.g. operator
billing, credit card system) and requests vouchers from the Voucher
Servers for end users. Terminal 1210 downloads content from Content
Servers, acquires via Payment Server vouchers that enable the
terminal to access content. Content may be distributed from
terminal to terminal (super-distribution).
[0303] FIG. 15 is a flow diagram that demonstrates the message
flows among the elements shown in FIG. 12. During message flow "1.
CONTENT DOWNLOAD", terminal 1210 downloads a protected content
package from Content Server 1260. The content package comprises a
content ID, encrypted digital content, and an address (e.g. an URL)
of Voucher Server 1250 which is associated with the content. During
message flow "2. VOUCHER OFFER REQUEST", terminal 1210 requests a
voucher for the downloaded content through DRM Agent 1220 by giving
the content ID and address (URL) of Voucher Server 1250 and a
terminal DRM ID. DRM Agent 1220 forwards the request to Voucher
Server 1250. Terminal ID can be wireless device ID, user ID, or
other ID. During message flow "3. OFFER", Voucher Server 1250 sends
an offer to Terminal 1210 through the DRM Agent 1220. During
message flow "4. ACCEPTANCE", Terminal 1210 sends a message
accepting the received offer. During message flow "4a. PAYMENT",
DRM Agent 1220 handles the payment transaction with the Payment
Server 1500. During message flow "5. VOUCHER REQUEST", DRM Agent
1220 requests Voucher Server 1250 to generate the voucher. During
message flow "6. VOUCHER DELIVERY", Voucher Server 1250 delivers
the voucher to Terminal 1210 via DRM Agent 1220. The voucher
comprises Content ID, Content Encryption Key, transaction ID, usage
rules, and usage limitations for the content.
[0304] The following discussion of content server 1260, terminal
1210, DRM agent 1220, payment server 1500, and voucher server 1250
shown in FIG. 12 and FIG. 15, as well as the relationships CS-VS,
DA-VS, T-DA, CS-T, and T-T shown in FIG. 12 demonstrate the message
flows shown in FIG. 15.
[0305] Content Server-Voucher Server Interface CS-VS--The Content
Server (CS) registers content with the Voucher Server (VS) and
passes registration information including Digital content, Price
for the content, and Potentially a template for the DRM usage rules
for that content (different rules may have different prices). VS
prepares the digital content (generates potentially a content ID)
and encapsulates it into protected DRM format (content encryption)
and returns the protected content to the CS for distribution to end
users. After registration process the VS is able to handle voucher
requests (for that specific content) from Payment Servers.
[0306] DRM Agent-Voucher Server Interface DA-VS--The DRM Agent (DA)
requests information from VS about a piece of content (identified
with a content ID) that the terminal is about to purchase a voucher
for. That is used to generate an offer for the end user. If the
offer is accepted, DA requests VS to generate a voucher for that
specific content (content ID) and for that specific terminal
(terminal DRM ID).
[0307] Terminal-DRM Agent Interface T-DA--A terminal initiates a
voucher acquisition transaction with the DA if the end user wants
to consume unpaid content. Terminal passes information about the
content (content ID, Voucher Server URL (carried with the content)
to its own Payment Service Provider (PSP) that operates the DA. DA
sends an offer to the Terminal and the terminal accepts or rejects
it. If the offer is accepted, DA handles the payment transaction
(e.g. operator billing) and requests a voucher from the VS through
DA-VS interface and delivers that voucher to the terminal.
[0308] Terminal-Content Server Interface CS-T--The terminal
downloads protected content from the CS.
[0309] Terminal-Terminal Interface T-T--The terminal
super-distributes content to another terminal.
[0310] DRM is a technology that provides us with a promise that we
are able to control the consumption of digital content. This can be
accomplished with two steps:
[0311] 1. Associate usage rules with digital content; and
[0312] 2. Enforce that the rules are followed
[0313] The tricky part is the rule enforcement. How to make sure
that each and every entity that consumes the bits also follows the
attached usage rules? How to make sure that the rules are not
detached from the content? Once the bits get lost they're gone for
good.
[0314] Bits are very easy to copy. And further on, every copy is
perfect, as good as the original one--this is a natural law in
cyberspace. If we want to make copying bits difficult, we must use
technology to contradict that natural law. DRM systems include such
technology.
[0315] On the other hand, the ability to control the bits and
prevent them from being illegally copied is not enough. Actually
the content owner wants quite the opposite, he wants to make sure
that his bits get copied as much as possible--as long as he gets
paid for each copy (this is called the paid content model).
[0316] This results in three major requirements for the DRM
system:
[0317] a) The DRM system must be able to control the consumption of
content (i.e. copy protection);
[0318] b) The DRM system must enforce the paid content model (i.e.
a convenient and cost-efficient payment mechanism must be
supported); and
[0319] c) The DRM system must enable multiple easy content
distribution mechanisms (i.e. peer-to-peer super-distribution,
content distribution via browsing or downloading, service
originated messaging).
[0320] Even though requirements (a) and (c) seem to conflict, they
can be fulfilled if the protection mechanisms and content
distribution mechanisms are orthogonal, that is, the DRM system is
content transport agnostic. This implies that piggybacking
transport layer security mechanisms for content protection purposes
may result in a system that severely restricts the content
distribution possibilities.
[0321] Super-distribution is a great opportunity for content
owners. Each piece of content has a possibility to get distributed
from peer-to-peer to a large population. Whether that happens for a
particular piece of content or not depends on end user's subjective
perception of the quality and price of the content. People vote
with their forward-buttons. We want to encourage these kind of
dynamics that reward content owners with great content.
[0322] The main operative functions of the DRM system are:
[0323] 1. Content registration to the DRM system;
[0324] 2. Content distribution to end users (from network to
terminal and terminal to terminal);
[0325] 3. Voucher acquisition process that enables the end user to
consume the content. This includes the payment process; and
[0326] 4. Money settlement process during which each value chain
participant gets his share of the money collected from the end
user.
[0327] FIGS. 13 and 14 expand upon the architecture shown in FIG.
12 to illustrate the interaction of a more complex Mobile DRM
system to illustrate the relationships between the participating
entities.
[0328] Content registration is done between a Content Server and a
Voucher Server.
[0329] Content needs to be registered into the DRM system before it
can be distributed to end users. During this registration the
content is packaged into a DRM capsule that forces terminals to
acquire a voucher before they are able to consume the content.
Usually this includes content encryption. Only after registration
the content (DRM packaged version of it) may be distributed to end
users.
[0330] After content registration has taken place, the following
shall apply (note: some things may already apply before
registration). The piece of content has a unique ID (Content ID,
CID). The Content ID needs to be associated with the content In
addition of being a unique identifier it is anticipated that in
most cases the Content ID also points to the actual content object
in the Content Server (URL). There is a specific Voucher Server
that assumes responsibility for issuing vouchers for that specific
piece of content. The URI pointing to the Voucher Server is
associated with the content and travels with the content to
terminals. Mechanisms for this are specified in (XHTML
<object> element parameter "accessRights) and (<admin>
element in the voucher meta data). The specific Voucher Server has
sufficient information for issuing vouchers. This includes Content
ID, Content Encryption Key, voucher templates with business rules,
pricing information related to each voucher template. The Content
Server has sufficient information to distribute the content. This
includes the DRM protected version of the content.
[0331] Content registration happens in most cases only once per a
piece of content. Re-registration may include Content Encryption
Key refreshing (implies repackaging), pricing modifications, adding
new voucher templates etc.
[0332] There are two models to register content, Voucher Server
centric and Content Server centric. Both models are functionally
equal but differ in the task division between the two entities.
[0333] In this registration model the Voucher Server is responsible
for almost all of the DRM related issues. For example, Content
Encryption Key generation and storage and packaging the content
into the DRM capsule.
[0334] Content Server does not need to bother about DRM details, it
only decides the prices for voucher templates and sends the plain
content to the Voucher Server.
[0335] From security point of view this model has the advantage
that the Content Encryption Key leaves the Voucher Server only
inside a protected voucher. The Content Server does not need to
know the Content Encryption Key.
[0336] Registering the same piece of content with two Voucher
Servers results in two different DRM packaged versions of the same
content. This may not be desirable.
[0337] In this model the Content Server handles the DRM specific
details and packages the content into the DRM capsule. Content
Server informs the Voucher Server only about the absolutely
necessary details it needs to know in order to issue vouchers.
[0338] This model supports scenarios where the same piece of
content is registered with multiple Voucher Servers and still there
is only one DRM packaged version, however, this also depends on the
security model.
[0339] Content is distributed in the DRM system from the Content
Server to Terminal and from Terminal to Terminal
(super-distribution). Only registered (i.e. DRM packaged) content
should be distributed. The assumption that packaged content is
useless without a voucher makes content distribution requirements
pretty loose. We can use whatever transport mechanisms we desire,
if the following requirements are fulfilled the content is in
protected DRM packaged format and the information that is required
by the voucher acquisition process is carried with the content
(including Content ID, Voucher Server URL).
[0340] The most feasible transport mechanisms for Content Server to
Terminal distribution are downlading in a standard browsing session
(http) or server originated messaging with MMS. In Terminal to
Terminal super-distribution MMS is an important mechanism. In
addition, local link via OBEX over BT or cable may be used.
[0341] Voucher acquisition is the most important function of the
DRM system. During that process a voucher is generated and
distributed to the terminal and a monetary transaction takes place.
The entities related to the voucher acquisition are Terminal, DRM
Agent and Voucher Server.
[0342] The Terminal initiates voucher acquisition when the end user
wants to consume content for which the terminal does not have a
voucher. In the basic scenario the terminal contacts the end user's
DRM Agent and requests an offer for a voucher. DRM Agent contacts
the specific Voucher Server that registered the content and
requests information about the vouchers (e.g. price). DRM Agent
makes an offer for the end user. If end user accepts the offer DRM
Agent deducts the appropriate amount of money from the end users
account (e.g. operator billing) and requests the Voucher Server to
generate one voucher for that terminal. The voucher is then sent to
the terminal and after that the terminal is able to consume the
content.
[0343] Money is collected from the end user during voucher
acquisition. At the end of the day (or week or month) the
settlement process must take place. In that process, each
participant in the value chain gets a separate share of the
money.
[0344] DRM Agent is entitled to its share because it takes care of
the payment transaction with the end user. DRM Agent keeps track of
all issued vouchers.
[0345] Voucher Server is the middleman between Content Servers and
DRM Agents and is entitled for its share because it handles the
content registration and voucher generation related issues. Voucher
Server also keeps track of issued vouchers.
[0346] Content Server is close to the Content Owner (in many cases
the same entity) and thus should get its large share because the
actual value that the end user paid for is in the content itself.
However, super-distribution based voucher acquisitions are
invisible for the Content Server making it impossible for it to
keep track of content consumption. Content Server must rely on the
information received from the Voucher Server.
[0347] The settlement process is external to the DRM system and can
be implemented by interfacing with existing invoicing systems.
[0348] The digital content is created (or aggregated) by the
Content Server. This implies that the Content Server is in close
relationship with the Content Owner.
[0349] The main functions of Content Server is to register digital
content with a Voucher Server and distribute registered content to
an end user. In most cases the Content Server is just a normal
http-server with a content registration interface integrated to
it.
[0350] The main functions of the Voucher Server are to receive
content registration requests from Content Servers and to issue
vouchers that enable terminals to consume registered content.
[0351] The voucher generation decision is an important control
point from security point of view.
[0352] Voucher Server is in close relationship with the Content
Server and must also have an agreement with a set of DRM Agents in
order to make ensure that a large population of end users can
consume the content. This is a win-win situation for both the
Voucher Servers and DRM Agents.
[0353] Voucher Server maintains a database of registered content
and keeps tracks of the generated vouchers.
[0354] DRM Agent is the middleman between the terminals that want
to consume content and the Voucher Servers that generate the
vouchers (i.e., DRM Agent plays a central role in the voucher
acquisition process) especially in the payment transaction. The
rationale for introducing a middleman is related to the difficulty
of doing cost-efficient and convenient invoicing between multiple
Voucher Servers and the end user.
[0355] The most important role of the DRM Agent is to handle the
payment collection from the end user before the voucher is issued
by the Voucher Server. This implies that there is a close
relationship between the end user and the DRM Agent. In addition,
the DRM Agent must also have an agreement with a set of Voucher
Servers.
[0356] DRM Agent maintains a user database and keeps track of the
generated vouchers.
[0357] The terminal is DRM system compliant and thus implements the
communication protocols and functionality related to interfaces
with Content Server, DRM Agent and other Terminals. The DRM system
also assumes that some kind of local voucher and content repository
is implemented.
[0358] Information about the chosen DRM Agents is configured to the
terminal by the end user or the mobile operator (i.e., the terminal
always initiates the voucher acquisition dialog with one of the end
user's own DRM Agents).
[0359] The External Payment System may be, for example, operator
billing system or credit card payment system.
[0360] All of the terminal management issues are separated to a DRM
Terminal Infrastructure (DRMI). These include mechanisms for
terminal initialization, personalization, key renovation and
terminal revocation.
[0361] Referring again to FIG. 12 and FIG. 15, the Content
Server-Voucher Server CS-VS interface is used to register digital
content into the DRM system. Registration requests and responses
add, modify, or delete a piece of content and the related
information from Voucher Server. Mutual authentication is required
between CS and VS. In addition, confidentiality and integrity of
the communications must be protected. SOAP requests and responses
over http with a SSL connection. VS acts as an http-server, CS as
an http-client. Content registration may be quite infrequent in
some cases. This implies that the interface can also be implemented
with, for example, secure electronic-mail messaging between CS and
VS operators.
[0362] Referring again to FIG. 12 and FIG. 15, the Content
Server-Terminal CS-T interface is used to distribute the DRM
protected content from the Content Server to the Terminals. Content
object downloading network originated MMS messaging. There are no
major security requirements for this interface. However, it is
useful but not mandatory for the end user to authenticate the
Content Server. The same goes for the other way around, although
that is just normal behaviour of a Content Server and thus out of
the scope of the DRM system. Spamming control needs to be
implemented at some stage. Content downloading in a standard
http/WAP-browsing session. The content may be wrapped inside a MIME
or WAP multi-part message. Content may also be distributed with MMS
messaging. Since MMS messages are based on RFC 822 the wrapping is
similar to the browsing/downloading scenario. The actual transport
mechanism should not be affected by DRM, only the processing of the
received object is DRM specific.
[0363] Referring again to FIG. 12 and FIG. 15, the
Terminal-Terminal T-T interface is used to super-distribute content
and possibly vouchers from terminal to terminal. Content object
sending to another terminal. This may include sending a preview or
no-rights voucher with the content. There are no major security
requirements for this interface. It is useful for the end user to
authenticate the origin of the message. Spamming control needs to
be implemented at some stage. The actual transport mechanism should
not be affected by DRM, only the processing of the received object
is DRM specific.
[0364] Referring again to FIG. 12 and FIG. 15, the Terminal-DRM
Agent T-DA interface is used to acquire a voucher. Payment
transaction is done via this interface. For voucher acquisition,
the terminal initiates the acquisition process (T=>DA: CID,
Transaction ID, Voucher Server URL, Terminal's DRM ID), DRM Agent
responds and sends optionally an offer for the voucher, end user
accepts or rejects the offer and performs payment related
authentication, DRM Agent sends the voucher to the terminal. For
GIVE voucher acquisition, the terminal initiates GIVE voucher
acquisition process (T=>DA: CID, Transaction ID, Voucher Server
URL, Terminal's DRM ID), DRM Agent responds and sends an offer for
the GIVE voucher, end user accepts or rejects the offer and
performs payment related authentication, DMR Agent sends the GIVE
voucher to the terminal, terminal sends the GIVE voucher to another
terminal (interface T-T). For GIVE voucher consumption, the
terminal receives GIVE voucher (interface T-T), the Terminal sends
GIVE voucher to the DRM Agent (T=>DA: GIVE voucher information,
Transaction ID, Voucher Server URL, Terminal's DRM ID), DRM Agent
sends a "normal" voucher back to the terminal, the terminal may
download the content if it did not already have it (interface
CS-T).
[0365] DRM Agent must authenticate the end user (actually DRM Agent
is interested in authorization. However, authorization is usually
based on authentication). The end user should be able to
authenticate the DRM Agent, at least in those cases where it sends
confidential information to the DRM Agent (e.g. username password).
The integrity of the communications should be protected.
Confidentiality requirements are not that major, expect possibly
for GIVE vouchers (depends on the GIVE voucher implementation).
[0366] Referring again to FIG. 12 and FIG. 15, the DRM
Agent-Voucher Server DA-VS interface is used to request information
and vouchers from the Voucher Server. For voucher information
requests and responses, DA=>VS Content ID, terminal DRM ID,
transaction ID and VS=>DS Voucher descriptions and prices. For
voucher requests and responses, DA=>VS Content ID, terminal DRM
ID, transaction ID and VS=>DS Voucher. Mutual authentication is
required between DA and VS. In addition, integrity of the
communications must be protected. SOAP requests and responses over
http with a SSL connection. VS acts as an http/server, DA as an
http-client.
[0367] Referring again to FIG. 12 and FIG. 15, the DRM
Agent-External Payment System DA-EPS interface is used to collect
real money from the end user. The implementation of this interface
is a feature of a specific DRM agent product.
[0368] Referring back to FIG. 12, the Voucher Server-DRMI Terminal
Infrastructure VS-DRMI interface is used by the Voucher Server to
request information about the DRM terminals. The function of this
interface is to get terminal cryptographic information of a
specific terminal (e.g., symmetric key, public key or certificate)
and to check revocation status of a specific terminal. One
implementation is to use a full-blown terminal PKI with a directory
service containing terminal certificates and revocation lists. This
interface will most likely be specific to a terminal vendor and
thus a Voucher Server product will need to implement a plug-in
architecture for multiple terminal vendor DRMI implementations.
[0369] Referring again to FIG. 12 and FIG. 15, the Terminal-DRM
Terminal Infrastructure T-DRMI interface is used for terminal
management operations. The function of this interface is to perform
terminal initialization (e.g., key generation), terminal renovation
(e.g., key refresh, DRM client binary update), and terminal
revocation. Anomaly detection mechanisms must be used to detect
cracked terminals. This interface will most likely be terminal
vendor specific and is used in some implementations only during
manufacturing phase of the terminal.
[0370] The interfaces described above do not include all
information exchange between the entities of the architecture.
Certain contractual arrangements need to be done beforehand and
monetary settlement after the fact (e.g. weekly or once in a
month). In addition, mutual authentication is required in most
cases between communicating parties implying that some kind of
authentication information (e.g. usernames and passwords) may need
to be exchanged beforehand.
[0371] These kind of arrangements are done between Content Server
and Voucher Server, End user (terminal) and DRM Agent, DRM Agent
and Voucher Server, DRM Agent and External Payment System, and
Voucher Server and DRM Terminal Infrastructure.
[0372] As for security considerations, the DRM problem can be
solved in a simple way if we do not allow super-distribution. This
is called the "forward-lock" method that disables the end-user from
forwarding the content to another terminal. Thus, everyone must get
their ringing tone or whatever from the retail site and pay for
it.
[0373] If we enable super-distribution the rules of the game are
radically different. It gets very hard to keep the content within a
closed system of trusted terminals, especially without dramatically
restricting the super-distribution mechanisms.
[0374] Super-distribution changes the dynamics of security breaks
when compared to the forward-lock solution. In the forward-lock
solution it is difficult to distribute the cracked piece of content
in large scale because ordinary terminals can not be trivially used
for re-distribution. However, if super-distribution is enabled the
cracked version will get distributed with the same mechanism as the
original content. And paradoxically, the cracked version will get
accerelated super-distribution because of its outstanding
price/quality ratio when compared to the original piece. Thus, the
competition between the cracked and original versions is quite
unfair and may lead to a situation where the cracked version
spreads like a virus and outnumbers the original version by far.
This is difficult to estimate because we do not have much
experience on suberdistribution.
[0375] The scenario above shows that it is very dangerous to
compare the security requirements of forward-lock and
super-distribution systems (e.g., "It is already possible to crack
ringing tones in the forward-lock system but that has not been a
problem--why should it be a problem in the super-distribution
case?).
[0376] At the end of the day, cryptography is the only technology
that provides us with mechanisms to protect the content once it
gets distributed to an untrusted terminal (e.g. PC). In practice
this means that the content is encrypted and the decryption key is
only available for those terminals that have paid to consume the
content.
[0377] Table 2 below describes some possible solutions to the DRM
problem.
17TABLE 2 Solution name Description Comments Forward- Terminal UI
prevents the end user This is already used in Nokia mobile lock to
forward the content to another phones with e.g. ringing tones.
terminal. Payment is done before Forward-lock kills
super-distribution. downloading the content. Link This is content
forward-lock, but Content is always downloaded from the forwarding
allows the end user to forward the URL into the terminal and
payment is content URL. done before content downloading. This is an
attempt to provide the functionality and user experience of
super-distribution without a need for DRM key management
infrastructure. This solution does not utilize the possibility to
use an effective local link for super-distribution of the content.
Plain This is a DRM solution that Messaging based
super-distribution (e.g. transport piggybacks transport layer
security MMS) is difficult to handle with this security protocols.
approach because it allows that the content can be sent to e.g. PC.
That is difficult to prevent. Content Content is statically
encrypted but This is an attempt to provide content encrypted, the
voucher (and the content encryption but avoid storing
secret/private voucher in decryption key within) is in plain keys
inside the terminal because of the plain text text. Transport layer
security costs of such DRM key management protocols are piggybacked
to infrastructures. How to prevent that the protect the voucher
while it is in voucher does not in a trivial way end up transit.
The vouchers that contain into an untrusted terminal (e.g. PC) and
the decryption key are not compromise the content? Client
forwarded. authentication would solve this, but that would require
a secret inside the terminal... This solution is transport agnostic
for the content delivery but not for the voucher delivery. Content
This is the basic voucher based Securitywise, this solution is
totally encrypted, DRM model. transport agnostic. Voucher needs to
be voucher personalized (if we assume that each encrypted terminal
has personal keys).
[0378] Method and System for Issuing Rights for Copyright Protected
Content
[0379] Method for issuing rights for (copyright) protected content
in a mobile communication environment with a wireless terminal by
means of vouchers, which are issued by a voucher server having a
connection to the mobile network of the terminal and having a
connection to at least one content server. The vouchers issued by
the voucher server contain usage rules, rights, and business rules
relating to a content item and to the user. The voucher is
connected to the content but is separate from the content. The
voucher is deliverable separately from the content as specified by
the terminal or the user to a terminal and/or to a server within
the communication network for further processing and/or for
acquiring the issued rights.
[0380] Method and System for Acquiring Rights for Copyright
Protected Content
[0381] Method for acquiring rights for (copyright) protected
content in a mobile communication environment with a wireless
terminal by means of vouchers, which are issued by a voucher server
having a connection to the mobile network of the terminal and
having a connection to at least one content server. The method
comprises steps of creating a connection with the content server
(and the payment server), selecting at least one content item from
a plurality of content items on a content server, specifying the
scope of rights to the chosen content item(s), making payment(s)
for the selected content item(s), receiving the voucher(s) for the
selected and purchased content item(s), and storing the received
voucher(s) at the terminal and/or at a server having a connection
to the terminal and/or on a /physical carrier having a connection
to the terminal for storing the received voucher(s). According to
the method the rights issued by the voucher can also be modified
according to the usage and/or business rules of the voucher and/or
the voucher issuing system.
[0382] A registered terminal can acquire additional vouchers and/or
modifications for existing vouchers with a one-click procedure (the
terminal/user and the acquired vouchers are identified, expiry
warnings)
[0383] Method and System for Accessing Copyright Protected
Content
[0384] Method for accessing (copyright) protected content in a
mobile communication environment by means of a wireless terminal
using vouchers, which are issued by a voucher server having a
connection to the mobile network of the terminal and having a
connection to at least one content server and which vouchers
specify at least a part of the scope of rights acquired
unambiguously. According to the method a voucher specifying the
scope of the rights to a content item is stored at the terminal or
at a server having connection to the terminal and accessible to the
user of the terminal for controlling the use of the specified
content item, e.g., for consuming and/or other (further)
processing, e.g., downloading, storing, super-distributing etc. as
specified in the voucher. The specified content is delivered to the
specified location after the validity and/or authenticity of the
voucher is verified. In super-distribution the super-distributed
content is made available according to the usage rules for that
content item.
[0385] Method and System for Transferring Access Rights to
Copyright Protected Content
[0386] Method for transferring access rights to (copyright)
protected content in a mobile communication environment by means of
a wireless terminals using vouchers, which are issued by a voucher
server having a connection to the mobile network of the terminal
and having a connection to at least one content server. According
to the method at least one acquired voucher specifying the scope of
the rights to a content item is accessible to the user of the
terminal for controlling the use of the specified content item,
e.g., for consuming and/or other (further) processing, e.g.
downloading, storing, super-distributing etc. as specified in the
voucher. The voucher can be stored at the fist terminal and/or at a
server having connection to the first terminal and/or at a
(physical) carrier, which can be accessed by the first terminal.
All or a part of the rights specified in the acquired voucher can
be transferred to at least another terminal.
[0387] The transfer, which can be lending or super-distribution
starts either with an offer from the first terminal (sender) to the
second terminal (receiver) or with a request from the second
terminal to the first terminal preferably by using a IR or RF link
between the terminals. The first (sender) terminal transmits a
message to the voucher server expressing the intent
(lend/super-distribute) to transfer the rights. The message may
contain in addition to the information concerning the voucher, also
such information on the receiving terminal that the transaction can
be fulfilled (identification of the second terminal and payment
server of the second terminal). The voucher of the first terminal
is modified according to the transfer intent.
[0388] The resulting invention is applicable to virtually all
digital communications networks, including wide area networks
(WANs), metropolitan area networks (MANs), local area networks
(LANs), and personal area networks (PANs). The resulting invention
is applicable to fixed station wireline networks, mobile wireless
networks, and hybrid combinations of fixed station wireline
networks communicating through wireless access points with mobile
wireless networks. In particular, the resulting invention is
applicable to any mobile computing environment, including any
wireless wide area network such as a cellular telephone network or
any short range wireless system such as a wireless local area
network or a wireless personal area network. Examples of wireless,
wide area network architectures to which the invention applies
include Global System for Mobile Communication (GSM), IS-136
TDMA-based Digital Advanced Mobile Phone Service (DAMPS), Personal
Digital Cellular (PDC), IS-95 CDMA-based cdmaOne System, General
Packet Radio Service (GPRS) and broadband wireless systems such as
W-CDMA, and Broadband GPRS. Examples of short-range wireless
systems to which the invention applies include the Bluetooth
Standard, the IEEE 802.11 Wireless LAN Standard the HIPERLAN
Standard, the IEEE 802.15 Wireless Personal Area Network (WPAN)
standard, the Infrared Data Association (IRDA) standard, the
Digital Enhanced Cordless Telecommunications (DECT) standard, the
Shared Wireless Access Protocol (SWAP) standard, the Japanese 3rd
Generation (3G) wireless standard, and the Multimedia Mobile Access
Communication (MMAC) Systems standard of the Japanese Association
of Radio Industries and Businesses.
[0389] Although the embodiments disclosed herein describe a fully
functioning method, system, and computer program product for
controlling the distribution of a digital asset in a mobile
environment, the reader should understand that other equivalent
embodiments exist. Since numerous modifications and variations will
occur to those who review this disclosure, the method, system, and
computer program product for controlling the distribution of a
digital asset in a mobile environment is not limited to the exact
construction and operation illustrated and disclosed herein.
Accordingly, this disclosure intends all suitable modifications and
equivalents to fall within the scope of the claims.
* * * * *
References