U.S. patent application number 10/880504 was filed with the patent office on 2006-01-05 for encrypted contents recording medium and apparatus and method for reproducing encrypted contents.
Invention is credited to Tokuda Katsumi, Masayuki Kozuka, Miyazaki Masaya, Okamoto Ryuichi, Nakahara Tohru, Masaya Yamamoto.
Application Number | 20060005257 10/880504 |
Document ID | / |
Family ID | 35515567 |
Filed Date | 2006-01-05 |
United States Patent
Application |
20060005257 |
Kind Code |
A1 |
Tohru; Nakahara ; et
al. |
January 5, 2006 |
Encrypted contents recording medium and apparatus and method for
reproducing encrypted contents
Abstract
The present invention aims to provide an encrypted contents
playback apparatus and an encrypted contents playback method that
are suitable for playing back contents from a medium storing
therein both contents to which conventional copy protection is
applied and contents to which DRM is applied, as well as to provide
a recording medium in which data used by such playback apparatus or
method is recorded. The medium of the present invention stores
therein information that indicates whether the contents have
conventional copy protection applied thereto or DRM applied
thereto. The terminal device determines which key should be used
for decrypting the contents based on the information.
Inventors: |
Tohru; Nakahara; (Osaka,
JP) ; Ryuichi; Okamoto; (Kadoma, JP) ;
Yamamoto; Masaya; (Hirakata, JP) ; Katsumi;
Tokuda; (Ikeda, JP) ; Masaya; Miyazaki;
(Ikeda, JP) ; Kozuka; Masayuki; (Neyagawa,
JP) |
Correspondence
Address: |
WENDEROTH, LIND & PONACK, L.L.P.
2033 K STREET N. W.
SUITE 800
WASHINGTON
DC
20006-1021
US
|
Family ID: |
35515567 |
Appl. No.: |
10/880504 |
Filed: |
July 1, 2004 |
Current U.S.
Class: |
726/27 ;
G9B/20.002; G9B/27.019; G9B/27.05 |
Current CPC
Class: |
G11B 20/00086 20130101;
G06F 21/10 20130101; G11B 20/0021 20130101; G11B 20/00797 20130101;
G11B 27/105 20130101; G11B 20/00492 20130101; G11B 20/00862
20130101; G11B 20/0084 20130101; G11B 20/00731 20130101; G11B
2220/2541 20130101; G06Q 20/3829 20130101; G11B 20/00195 20130101;
G11B 20/00847 20130101; G11B 20/00253 20130101; G11B 20/00181
20130101; G11B 27/329 20130101 |
Class at
Publication: |
726/027 |
International
Class: |
G06F 17/30 20060101
G06F017/30 |
Claims
1. A terminal device that plays back a medium on which an encrypted
content is recorded, comprising: a content key acquiring unit
operable to acquire a content key from outside the medium; an
acquisition source specifying unit operable to specify an
acquisition source from which the content key is acquired; a
communication establishing unit operable to establish communication
with the acquisition source; and a decrypting unit operable to
decrypt the encrypted content, using the content key.
2. The terminal device of claim 1, wherein the medium further
stores therein a media key that is unique to the medium, and the
decrypting unit decrypts the encrypted content, using the media key
and the content key.
3. A terminal device that plays back a medium on which an encrypted
content and acquisition source specification information are
recorded, comprising: a content key acquiring unit operable to
acquire a content key from outside the medium; an acquisition
source specifying unit operable to specify an acquisition source
from which the content key is acquired, based on the acquisition
source specification information; a communication establishing unit
operable to establish communication with the specified acquisition
source; and a decrypting unit operable to decrypt the encrypted
content using the content key.
4. The terminal device of claim 3, wherein the medium further
stores therein a media key that is unique to the medium, and the
decrypting unit decrypts the encrypted content, using the media key
and the content key.
5. A terminal device that plays back a medium on which an encrypted
content, acquisition source specification information, and
connection destination specification information are recorded, the
terminal device comprising: a connection destination specifying
unit operable to specify a connection destination based on the
connection destination specification information; a communication
establishing unit operable to establish communication with the
specified connection destination; a content key acquiring unit
operable to transmit the acquisition source specification
information to the specified connection destination and acquire a
content key; a decrypting unit operable to decrypt the encrypted
content, using the content key.
6. The terminal device of claim 5, wherein the medium further
stores therein a media key that is unique to the medium, and the
decrypting unit decrypts the encrypted content, using the media key
and the content key.
7. A client device that acquires and transmits a content key based
on acquisition source specification information received from an
external device, the client device comprising: an acquisition
source judging unit operable to judge whether an acquisition source
from which the content key is acquired is the client device itself
or an external source, according to the acquisition source
specification information; an acquisition source specifying unit
operable to specify the acquisition source based on the acquisition
source specification information; a communication establishing unit
operable to establish communication with the specified acquisition
source; a content key acquiring unit operable to acquire the
content key from the acquisition source; and a content key
transmitting unit operable to transmit the content key to the
external device.
8. A method of playing back a medium on which an encrypted content
is recorded, comprising: a content key acquiring step of acquiring
a content key from outside the medium; an acquisition source
specifying step of specifying an acquisition source from which the
content key is acquired; a communication establishing step of
establishing communication with the acquisition source; and a
decrypting step of decrypting the encrypted content, using the
content key.
9. A method of playing back a medium on which an encrypted content
and acquisition source specification information are recorded, the
method comprising: a content key acquiring step of acquiring a
content key from outside the medium; an acquisition source
specifying step of specifying an acquisition source from which the
content key is acquired, based on the acquisition source
specification information; a communication establishing step of
establishing communication with the specified acquisition source;
and a decrypting step of decrypting the encrypted content, using
the content key.
10. A method of playing back a medium on which an encrypted
content, acquisition source specification information, and
connection destination specification information are recorded, the
method comprising: a connection destination specifying step of
specifying a connection destination based on the connection
destination specification information; a communication establishing
step of establishing communication with the specified connection
destination; a content key acquiring step of transmitting the
acquisition source specification information to the specified
connection destination and acquiring a content key; and a
decrypting step of decrypting the encrypted content, using the
content key.
11. A medium in which an encrypted content is stored, wherein the
medium further stores therein acquisition source specification
information for specifying an acquisition source from which a
content key is acquired.
12. The medium of claim 11, further storing therein a certificate
that is unique to the acquisition source and is to be used for
verifying a signature for a piece of data provided by the
acquisition source.
13. The medium of claim 11, further storing therein identification
information for specifying a certificate that is unique to and
provided by the acquisition source.
14. A medium that stores therein an encrypted content, wherein the
medium further stores therein acquisition source specification
information for specifying an acquisition source from which a
content key is acquired; and connection destination specification
information for specifying a connection destination with which
connection is to be made in order to acquire the content key.
15. The medium of claim 14, further storing therein a media key
that is unique to the medium.
16. The medium of claim 15, further storing therein a certificate
that is unique to the acquisition source and is to be used for
verifying a piece of data provided by the acquisition source.
17. The medium of claim 15, further storing therein identification
information for specifying a certificate that is unique to and
provided by the acquisition source.
18. The medium of claim 14, further storing therein a certificate
that is unique to the acquisition source and is to be used for
verifying a signature for a piece of data provided by the
acquisition source.
19. The medium of claim 14, further storing therein identification
information for specifying a certificate that is unique to and
provided by the acquisition source.
Description
BACKGROUND OF THE INVENTION
[0001] 1. Field of the Invention
[0002] The present invention relates to apparatuses and methods for
playing back contents of which the copyrights are protected and
recording media for storing data used by the apparatuses and in the
methods.
[0003] 2. Description of the Related Art
[0004] For DVDs (Digital Versatile Discs), CSS (Contents Scrambling
System) has been introduced to prevent unauthorized copying of
contents. In CSS, a piece of information unique to a DVD medium is
recorded, and a title key is generated from this piece of
information and another piece of information stored in the playback
apparatus. Encrypted contents recorded on the DVD medium are
decrypted using the title key and played back. (See, for example,
the Japanese Unexamined Patent Application Publication No.
2003-37589).
[0005] On the other hand, it has become popular lately to use the
DRM (digital Rights Management) System in contents distribution
systems. In the DRM system, a license is distributed separately
from encrypted contents. The license has a license key and the
conditions of use recorded. The contents are decrypted with the
license key according to the conditions of use and played back.
[0006] In the DRM system, contents and licenses are distributed via
a network. Further, in recent years, attempts have been made to
distribute contents by a storing-type broadcast system called the
server-type broadcast.
[0007] Recently, BDs (Blu-ray Discs) have been proposed as media to
replace conventional DVDs. A BD has a capacity five times as large
as a DVD and is capable of having not only images with SD quality
but also images with HD quality recorded thereon.
[0008] Like CSS for a conventional DVD, BDs have a mechanism by
which a piece of information unique to a medium is recorded and a
media key is generated from this piece of information and another
piece of information stored in the playback apparatus. Further,
contents are encrypted using the media key, and the encrypted
contents are recorded on the medium. This method prevents
unauthorized copying of the contents like in the case of DVDs.
[0009] Furthermore, it has been considered to apply DRM to BDs.
When DRM is applied to a package medium, contents encrypted with a
license key are stored into a medium, and a license is distributed
separately via a network. In order to play back the contents, the
encrypted contents recorded on the medium are decrypted with the
license key and then played back.
[0010] Applying DRM brings out a problem, however, when a medium
stores therein both contents to which conventional copy protection
is applied and contents to which DRM is applied. That is to say, a
playback apparatus is not able to tell if each of the contents has
conventional copy protection applied thereto or DRM applied
thereto. Even if an attempt is made to decrypt, with a media key,
contents to which DRM is applied, it is not possible to decrypt the
contents. Conversely, even if an attempt is made to search for a
license that corresponds to contents 1-0 to which conventional copy
protection is applied, since no corresponding license exists, it is
not possible to play back the contents.
SUMMARY OF THE INVENTION
[0011] The object of the present invention is to provide a data
structure suitable for, in a case where a medium stores therein
contents to which conventional copy protection is applied and
contents to which DRM is applied, playing back both kinds of
contents properly, as well as a recording medium that stores
therein data having such a data structure, and a playback apparatus
and a playback method for playing back such data.
[0012] In order to achieve the object, the present invention
provides a terminal device that plays back a medium on which an
encrypted content is recorded, comprising: a content key acquiring
unit operable to acquire a content key from outside the medium; an
acquisition source specifying unit operable to specify an
acquisition source from which the content key is acquired; a
communication establishing unit operable to establish communication
with the acquisition source; and a decrypting unit operable to
decrypt the encrypted content, using the content key.
BRIEF DESCRIPTION OF THE DRAWINGS
[0013] These and other objects, advantages and features of the
invention will become apparent from the following description
thereof taken in conjunction with the accompanying drawings which
illustrate a specific embodiment of the invention.
[0014] In the drawings:
[0015] FIG. 1 shows the overall structure of the contents playback
system of the first embodiment of the present invention;
[0016] FIG. 2 shows the internal structure of the terminal device
101 and information recorded on the medium 102 according to the
first embodiment of the present invention;
[0017] FIG. 3 shows the internal structures of the license server
104 and the license management client 230 according to the first
embodiment of the present invention;
[0018] FIG. 4 shows the data structure of the playback control
information 211 according to the first embodiment of the present
invention;
[0019] FIG. 5 shows the data structure of the key control
information 213 according to the first embodiment of the present
invention;
[0020] FIG. 6 shows the data structure of the media unique
information 214 according to the first embodiment of the present
invention;
[0021] FIG. 7 shows the table configuration of the rights storing
unit 315 according to the first embodiment of the present
invention;
[0022] FIG. 8 shows the table configuration of the key storing unit
305 according to the first embodiment of the present invention;
[0023] FIG. 9 shows the table configuration of the use condition
storing unit 306 according to the first embodiment of the present
invention;
[0024] FIG. 10 shows the configuration of communication message
according to the first embodiment of the present invention;
[0025] FIG. 11 shows the configuration of rights according to the
first embodiment of the present invention;
[0026] FIG. 12 shows the configuration of contents playback
information according to the first embodiment of the present
invention;
[0027] FIG. 13 is a flow chart that shows the processing procedure
to play back the contents and complete the playback, according to
the first embodiment of the present invention;
[0028] FIG. 14 is a flow chart that shows the processing procedure
in the content key acquisition process 1 according to the first
embodiment of the present invention;
[0029] FIG. 15 is a flow chart that shows the processing procedure
in the rights key acquisition process 1 according to the first
embodiment of the present invention;
[0030] FIG. 16 is a flow chart that shows the processing procedure
in the rights key transmission process 1 according to the first
embodiment of the present invention;
[0031] FIG. 17 is a flow chart that shows the processing procedure
in the media key acquisition process 1 according to the first
embodiment of the present invention;
[0032] FIG. 18 is a flow chart that shows the processing procedure
in the contents playback process 1 according to the first
embodiment of the present invention;
[0033] FIG. 19 is a flow chart that shows the processing procedure
in the use condition update process 1 according to the first
embodiment of the present invention;
[0034] FIG. 20 is a flow chart that shows the processing procedure
in the next playback content specification process 1 according to
the first embodiment of the present invention;
[0035] FIG. 21 shows the internal structure of the terminal device
101 and information recorded on the medium 102 according to the
second embodiment of the present invention;
[0036] FIG. 22 shows the internal structures of the license server
104 and the license management client 230 of the second embodiment
of the present invention;
[0037] FIG. 23 shows the data structure of the playback control
information 211 of the second embodiment of the present
invention;
[0038] FIG. 24 shows the data structure of the key control
information 213 of the second embodiment of the present
invention;
[0039] FIG. 25 is a flowchart that shows the processing procedure
to play back the contents and complete the playback, according to
the second embodiment of the present invention;
[0040] FIG. 26 is a flowchart that shows the processing procedure
in the content key acquisition storing process 2 according to the
second embodiment of the present invention;
[0041] FIG. 27 is a flow chart that shows the processing procedure
in the rights key acquisition process 2 according to the second
embodiment of the present invention;
[0042] FIG. 28 is a flowchart that shows the processing procedure
in the rights key transmission process 2 according to the second
embodiment of the present invention;
[0043] FIG. 29 is a flow chart that shows the processing procedure
in the contents playback process 2 according to the second
embodiment of the present invention; and
[0044] FIG. 30 is a flow chart that shows the processing procedure
in the use condition update process 2 according to the second
embodiment of the present invention.
DESCRIPTION OF THE PREFERRED EMBODIMENTS
First Embodiment
Overall Structure of the Contents Playback System
[0045] The following describes in detail the first embodiment of
the present invention, with reference to the drawings.
[0046] FIG. 1 is a schematic drawing of the overall structure of
the contents playback system according to the first embodiment of
the present invention.
[0047] The contents playback system comprises: a terminal device
101 operable to play back contents; a medium 102 that stores
therein encrypted contents and other data; a display device 103
operable to display contents played back by the terminal device
101; a license server 104 operable to generate and distribute a
license; and a transmission line 105 that connects the terminal
device 101 with the license server 104.
[0048] FIG. 2 shows the internal structure of the terminal device
101 and information recorded on the medium 102.
[0049] Firstly, the internal structure of the terminal device 101
is to be described.
[0050] The terminal device 101 comprises: a contents playback unit
200 that plays back contents; an operation unit 221 operable to
receive user operations; a display unit 222 operable to transmit
display data to the display device 103; a key acquisition
intermediary unit 223 operable to intermediate the acquisition of
rights key performed by the contents playback unit 200; a license
management client A 230 operable to transmit a rights key based on
a request form the contents playback unit 200; and a license
management client B 240 that has a different security level from
the license management client A 230. In the following description,
it is assumed that the security level of the license management
client A 230 is higher than that of the license management client B
240.
[0051] The contents playback unit 200 comprises: a reading unit 201
operable to read data from the medium 102; a playback control unit
202 operable to control playback of contents; a decrypting unit 203
operable to decrypt encrypted contents; a key acquisition control
unit 204 operable to control acquisition processing of a content
key; and a media key generating unit 205 operable to generate a
media key according to an instruction from the key acquisition
control unit 204.
[0052] An example of implementing the terminal device 101 is a
client computer including a CPU, a work memory, a flash memory, a
BD drive, a remote controller, a video adaptor, a network adaptor,
and so on. More specifically, the reading unit 201 is a BD drive,
the operation unit 221 is a remote controller, and the display unit
222 is a video adaptor. A model may be presumed in which the
contents playback unit 200 is arranged to be tamper-resistant
hardware-wise or software-wise, the license management client A 230
is arranged to be tamper-resistant hardware-wise, and the license
management client B 240 is arranged to be tamper-resistant
software-wise. For example, the contents playback unit 200 may
comprise a secure LSI arranged to be tamper-resistant
hardware-wise, the license management client A 230 may be a program
that operates on an IC card arranged to be tamper-resistant
hardware-wise, and the license management client B 240 may be a
program operating in a secure program execution environment of the
terminal device 101. These specific examples are mere examples, and
the configuration of the terminal device 101 is not limited to
these examples.
[0053] Secondly, information recorded on the medium 102 is
described.
[0054] The medium 102 stores therein playback control information
211 which is information for controlling playback order, encrypted
contents 212 being contents data having been encrypted, key control
information 213 being information on control of the key acquisition
processing, and media unique information 214 being information
unique to the medium 102.
[0055] Here, description is provided for a case where the medium
102 is specifically a BD medium.
[0056] A BD medium has a file system such as UDF; consequently, a
method is normally used in which the playback control information
211, the encrypted contents 212, the key control information 213,
and the media unique information 214 are recorded as one or more
files on a file system. The present invention, however, is not
limited to this method. For example, there are other methods in
which the media unique information 214 is recorded in a special
area within a lead-in area of a BD medium, or recorded using a BCA
(Burst Cutting Area), or recorded after an error is intentionally
made for an error detecting code.
[0057] FIG. 3 shows the internal structures of the license server
104, the license management client A 230, and the license
management client B 240. It should be noted that, in FIG. 3, the
internal structure of the license management client A 230 is shown
as a representative, since the license management client A 230 and
the license management client B 240 have the same structure.
[0058] The following describes the internal structure of the
license server 104.
[0059] The license server 104 comprises: a rights transmitting unit
301 operable to transmit a right to the terminal device 101; a
transmission control unit 302 operable to control data transmission
to the terminal device 101; a rights generating unit 303 operable
to generate a right from a rights key and conditions of use; a key
transmitting unit 304 operable to transmit a rights key to the
terminal device 101; a usability judging unit 307 operable to judge
whether or not it is acceptable to transmit a key based on the
conditions of use; a key storing unit 305 operable to store there
in a rights key; and a use condition storing unit 306 operable to
store therein the conditions of use. An example of implementing the
license server 104 is a server computer including a CPU, a work
memory, an HDD, and a network adaptor. More specifically, the
rights transmitting unit 301 is a network adaptor, and the
transmission control unit 302 and the rights generating unit 303
are software that operates using a CPU and a work memory. These
specific examples are mere examples, and the configuration of the
license server 104 is not limited to these examples.
[0060] The following describes the internal structure of the
license management client A 230.
[0061] The license management client A 230 comprises: a rights
acquiring unit 311 operable to acquire a right from the outside; a
key extracting unit 312 operable to extract a rights key from a
right; a usability judging unit 313 operable to judge whether or
not it is acceptable to transmit a key based on the conditions of
use; a key transmitting unit 314 operable to transmit a rights key
to the outside; a rights storing unit 315 operable to store therein
a right; and a use condition updating unit 316 operable to update
the conditions of use.
[0062] Each of the license server 104, the terminal device 101, the
license management client A 230, and the license management client
B 240 comprises a data storing unit and various processing units.
Each data storing unit is realized with a recording medium such as
an HDD, a flash memory, or the like. Each processing unit is
realized with hardware such as an LSI, and a program executed with
the use of a CPU, a RAM, or a ROM.
[0063] This completes the detailed description of the structures of
the terminal device 101, the license server 104, and the license
management client A 230.
[0064] The following describes data and data structure to be dealt
within the first embodiment. Firstly, the data structure of the
data to be stored in the medium 102 will be described. Secondly,
the data structure of data to be stored in each storing unit is
described, starting with the license management client A 230, and
then the license server 104. Lastly, explanation will be provided
on the rights distributed from the license server 104 and the data
structure of the contents playback information acquired by the
contents playback unit 200 from the outside when the contents are
to be played back, according to the present embodiment.
[0065] To start with, the data structure of the data stored in the
medium 102 is described with reference to FIGS. 4, 5, and 6.
The Data Structure of the Playback Control Information 211
[0066] FIG. 4 shows an example of data structure of the playback
control information 211. The playback control information 211
includes four kinds of information as below:
[0067] "Playback Number"
[0068] This is an index number that uniquely identifies each of the
pieces of information arranged in lines and registered in the
playback control information 211, respectively. The number starts
with one and increments by one for each line.
[0069] "Content Name"
[0070] It is information that identifies each of contents arranged
in the lines. Each content is stored into a BD medium as a file,
and a file name of a corresponding content is recorded as the
content name.
[0071] "Next-Playback Number"
[0072] It is the line number of a content to be played back next,
when the playback of the content in this line is completed. For
example, for the first line, the Next-playback Number is "2". It
therefore means that when the playback of Opening.mpg is completed,
playback of Trailer.mpg will start.
[0073] "Alternative Playback Number"
[0074] It is the line number of a content to be played back
alternatively, when the playback of the content indicated with the
Next-playback Number is found to be impossible. For example, for
the second line, the Next-playback Number is "3", and the
"Alternative Playback Number" is "4". It therefore means that when
the playback of Trailer.mpg is completed and the playback of
Movie.mpg is found to be impossible, Warning.mpg will be played
back. It should be noted that when there is no Alternative Playback
Number is specified, regardless of whether or not the playback of
the content indicated with a Next-playback Number is possible, the
playback of the content indicated with the Next-playback Number
will be forced to conduct.
The Data Structure of the Encrypted Contents 212
[0075] The encrypted contents 212 are data obtained by encrypting a
transport stream into which an MPEG (Moving Picture Experts Group)
2 video elementary stream and an MPEG 2 audio elementary stream are
multiplexed according to a multiplex method defined by MPEG 2. AES
(Advanced Encryption Standard) is used for the encryption, and the
payloads of the packets in the transport stream except for the
adaptation field are encrypted.
[0076] In the case of a menu content, a transport stream may store
therein data for displaying buttons, in addition to a video
elementary stream and an audio elementary stream. The data for
displaying buttons is normally recorded as a private stream;
however, the present invention is not limited to this. It should be
noted that explanation has been provided here for the encrypted
contents 212 of which the contents format is the MPEG 2 transport
stream, and of which the encryption method is AES; however, the
present invention is not limited to these examples.
The Data Structure of the Key Control Information 213
[0077] FIG. 5 shows an example of data structure of the key control
information 213. The key control information 213 includes nine
kinds of information as below:
[0078] "Content Name"
[0079] It is information that identifies each of contents arranged
in lines. Like each of the content names recorded in the playback
control information 211, a file name of a corresponding content is
recorded as a content name. It should be noted that, unlike the
playback control information 211, each content does not appear more
than once in the key control information 213.
[0080] "Content Unique Information"
[0081] It is unique information that is designated for each content
and is used for generating a key for the content.
[0082] "Key Generation Information"
[0083] It is information to specify a generation method to be used
when a key for the content is generated. One of a media key, a
rights key, and a composite key is specified.
[0084] "Playback Possibility Information"
[0085] It is information that indicates whether or not the playback
of each content is possible or not. It is specified as either
"playback possible" or "playback impossible". It should be noted
that in this example it is specified as either playback possible or
playback impossible; however, the present invention is not limited
to this example. The Playback Possibility Information may include
quality of playback, for example.
[0086] "Copiability Information"
[0087] It is information that indicates whether or not each content
is copiable. It is specified as Once, Free, or Never. Once means
that only one generation is copiable. Free means that the content
is copiable without restriction. Never means that the content is
not copiable. It should be noted that, in this example, it is
specified as Once, Free, or Never; however, the present invention
is not limited to this example. For example, the Copiability
Information may include other information such as one that
identifies quality of a copy or one that identifies a copy
destination medium.
[0088] "Corresponding Rights Format Information"
[0089] It is information that identifies a format of the
corresponding rights information for a line in which the key
generation information is specified as a rights key or a composite
key. For example, for the third line, since "Format D1" is
specified, rights processing for the content in this line is
permitted only by a right that has been generated in Format D1.
[0090] "Connection Destination Type"
[0091] This information is paired with "Corresponding Rights Format
Information" and is for specifying a connection destination when a
rights key is to be acquired, for a line in which the key
generation information is specified as a rights key or a composite
key. For example, for the third line, since "Client A" is
specified, the contents playback unit 200 is connected to, in order
to acquire a rights key for the content in this line, the license
management client A 230 in Format D1.
[0092] "Public Key Certificate"
[0093] It is information for verifying the signature of a message
received from a connection destination module specified by
"Corresponding Rights Format Information" and "Connection
Destination Type", for a line in which the key generation
information is specified as a rights key or a composite key. To be
more specific, the public key certificate of the connection
destination module is set. For example, for the third line, a
public key certificate of the license management client A 230 in
Format D1 is set.
[0094] It should be noted that, in this example, a public key
certificate of a connection destination module is set; however, it
is acceptable to have an arrangement wherein a piece of
identification information that uniquely identifies a public key
certificate of the connection destination module is set, and the
contents playback unit 200 acquires the public key certificate of
the connection destination module according to the piece of
identification information. Alternatively, it is acceptable to set
the public key of the connection destination module in each
line.
[0095] Further, the piece of identification information that
uniquely identifies a public key certificate of the connection
destination module may be, for example, a piece of information in
which a piece of Corresponding Rights Format Information and the
Connection Destination Type are expressed as a code such as
"001-00A".
[0096] In addition, it is acceptable to have an arrangement wherein
no such information is set in each line and a public key
certificate of the connection destination module is acquired based
on "Rights Format Information" and "Connection Destination
Type".
[0097] "Priority Order"
[0098] It is information that indicates the priority order among
connection destinations, in a case where there is more than one
connection destination, denoting the order in which connection
processing is performed, for a line in which the key generation
information is specified as a rights key or a composite key.
[0099] In the present embodiment, it is possible to have more than
one connection destination for a line in which the key generation
information is specified as a rights key or a composite key. For
example, for the sixth line, "1" is specified as the priority order
for Client A in Format D1, and "2" is specified as the priority
order for Client B in Format D1. In such a case, in order to
acquire a rights key, the contents playback unit 200 makes an
acquisition request for a rights key, first to the license
management client A 230 in Format D1, and if the acquisition of a
rights key is impossible for the reason that the client does not
exist or such, then to the license management client B 240 in
Format D1.
The Data Structure of Media Unique Information 214
[0100] FIG. 6 shows an example of data structure of the media
unique information 214. The media unique information 214 includes
two kinds of information as below:
[0101] "Device Unique Information"
[0102] It is device unique information that is uniquely assigned to
each playback device.
[0103] "Encrypted Media Key"
[0104] It is data obtained by encrypting a media key with a device
unique key.
[0105] In the present embodiment, an encrypted media key is
recorded as media unique information 214 for each playback device.
In the event that a playback device becomes unauthentic as having
been hacked, or for some other reasons, it is possible to prevent
the unauthentic playback device to perform playback by not
recording the device unique information of the unauthentic playback
device and the corresponding encrypted media key. It should be
noted that, in the present embodiment, it is necessary to provide
as many pieces of device unique information and as many encrypted
media keys as the number of playback devices. With this method,
data amount of the media unique information 214 becomes
unnecessarily large; therefore, it is acceptable to compress the
data amount with a method using a binary tree.
[0106] This completes the description of the data structure of the
data stored in the medium 102.
[0107] The following describes the data structure of data stored in
the storing unit of the license management client A 230, with
reference to FIG. 7.
[0108] FIG. 7 shows an example of data structure of rights
information stored in the rights storing unit 315. The rights
information includes five kinds of information as below. It should
be noted that what is included in the rights information is not
limited to these five kinds of information. Particularly, various
kinds of information may be included in the information related to
the conditions of use of rights, such as the playback number of
times and the playback expiration.
[0109] "Package Identifier"
[0110] It is information that uniquely identifies the substance of
the contents included in the medium 102. One package identifier is
set for one medium, the medium 102. It is information that uniquely
identifies, for example, "Top 50 Hits of 2003 for domestic music"
or "Movie Collection directed by xx".
[0111] "Content Name"
[0112] It is information that identifies a content corresponding to
the right specified in each line. Like each of the content names
recorded in the playback control information 211, a file name of a
corresponding content is recorded as a content name.
[0113] "Rights Key"
[0114] It is a rights key that corresponds to a right specified in
each line.
[0115] "Playback Number of Times"
[0116] It is the number of times the content is authorized to be
played back by the right specified in each line. When no number is
specified in particular, it means that it is possible to play back
the content any number of times.
[0117] "Playback Expiration"
[0118] It is the expiration until which the content is authorized
to be played back by the right specified in each line. When no
expiration is specified in particular, it means that it is possible
to play back the content without any expiration.
[0119] The following describes the data structure of the data
stored in the storing unit of the license server 104, with
reference to FIGS. 8 and 9.
[0120] FIG. 8 shows an example of data structure of the key
information stored in the key storing unit 305. The key information
includes three kinds of information as below:
[0121] "Package Identifier"
[0122] It is information that uniquely identifies the substance of
the contents included in the medium 102.
[0123] "Content Name"
[0124] It is information that identifies a content corresponding to
the right specified in each line. Like each of the content names
recorded as the playback control information 211, a file name of a
corresponding content is recorded as a content name.
[0125] "Rights Key"
[0126] It is a rights key that corresponds to a right specified in
each line.
[0127] FIG. 9 shows an example of data structure of the use
condition information stored in the use condition storing unit 306.
The use condition information includes four kinds of information as
below. It should be noted that what is included in the use
condition information is not limited to these examples, as noted
for the rights information.
[0128] "Package Identifier"
[0129] It is information that uniquely identifies the substance of
the contents included in the medium 102. One package identifier is
set for one medium, the medium 102.
[0130] "Content Name"
[0131] It is information that identifies a content corresponding to
the right specified in each line. Like each of the content names
recorded in the playback control information 211, a file name of a
corresponding content is recorded as a content name.
[0132] "Playback Number of Times"
[0133] It is the number of times the content is authorized to be
played back by the right specified in each line. When no number is
specified in particular, it means that it is possible to play back
the content any number of times.
[0134] "Playback Expiration"
[0135] It is the expiration until which the content is authorized
to be played back by the right specified in each line. When no
expiration is specified in particular, it means that it is possible
to play back the content without any expiration.
[0136] This completes the description of the data structure of the
data stored in the storing units.
[0137] Lastly, explanation is provided on the data structures of
the rights distributed from the license server 104 and the contents
playback information acquired by the contents playback unit 200
from the outside when a content is to be played back, according to
the present embodiment.
[0138] Here, prior to explanation on the data structures,
communication messages to be dealt with in the present embodiment
will be described. FIG. 10 shows the substance of the message
format of a communication message transmitted and received through
communication between the license server 104 and the terminal
device 101. The communication message shown in FIG. 10 is made up
of a message header and a message body.
[0139] Here, the message header includes, at least, a piece of
information that identifies a transmission destination and a piece
of information that identifies a transmission source. The piece of
information that identifies a transmission destination is referred
to as a destination of the message. The piece of information that
identifies a transmission source is referred to as a destination to
which a reply message is to be transmitted in response to the
message. An IP address is a typical example of a piece of
information that identifies a transmission source or a transmission
destination. It is acceptable to have an arrangement wherein a
message header includes information required for authentication
processing, in a case where authentication processing is performed
between a server and a machine that transmit and receive the
communication message. A message body includes information that is
unique to the message. This type of information that is unique to
each message body will be described later for each of the
messages.
[0140] FIG. 11 shows an example of a right that is acquired by the
license management client A 230 or the license management client B
240 from the license server 104. The rights information includes
two kinds of information as below and specified in the message body
shown in FIG. 10.
[0141] "Conditions of Use"
[0142] It is information used for judgment of whether or not the
contents are usable and for control being exercised when the
contents are used. "Playback Number of Times" and "Playback
Expiration" are examples of the former. Image quality and sound
quality of the playback at the time of using the contents are
examples of the latter.
[0143] "Rights Key"
[0144] It is a rights key that corresponds to a right to be
distributed.
[0145] This completes the description of the data structure of the
rights information.
[0146] FIG. 12 shows an example of contents playback information
acquired by the contents playback unit 200 from the license server
104, the license management client A 230, or the license management
client B 240, when the contents are used. The contents playback
information includes four kinds of information as below:
[0147] "Use Condition Type"
[0148] It indicates whether the conditions of use for a content
corresponding to a key acquisition request made by the contents
playback unit 200 are stateless or stateful. Being stateless means
that the conditions of use do not require an update. Being stateful
means that the conditions of use require an update. To be more
specific, a condition of use in which only expiration is specified
is an example of the former. A condition of use denoting that the
playback number of times is "five" is an example of the latter.
[0149] "Contents Playback Control Conditions"
[0150] It is information used for control being exercised when the
contents are used. Image quality and sound quality of the playback
at the times of using contents are specific examples.
[0151] "Rights Key"
[0152] It is a rights key that corresponds to a key acquisition
request made by the contents playback unit 200.
[0153] "Signature Data"
[0154] It is data obtained by signing data that contains at least
"Playback Control Conditions" "Use Condition Type" and "Rights Key"
using the secret key of the signing subject.
[0155] This completes the explanation on the data structure of the
contents playback information.
[0156] In the sections above, the data structure of the data dealt
with in the present embodiment has been described.
[0157] Next, the following describes the processing performed by
the terminal device 101, to play back the contents stored in the
medium 102 and complete the playback, with reference to FIGS. 13
through 20.
[0158] With reference to the flow chart in FIG. 13, description is
provided for the operation performed by the terminal device 101 to
playback the contents stored in the medium 102 and complete the
playback.
[0159] Immediately after the power of the terminal device 101 is
turned on or immediately after the medium 102 is inserted, upon an
instruction from the user to start the playback via the operation
unit 221, the terminal device 101 starts the playback processing of
the contents stored in the medium 102.
[0160] The playback control unit 202 controls the reading unit 201
so that the playback control information 211 is read from the
medium 102, acquires the content name that corresponds to the
Playback Number 1, and specifies the content to be played back. The
playback control unit 202 transmits the content name and a package
identifier of the medium 102 to the key acquisition control unit
204, and instructs the key acquisition control unit 204 to acquire
the content key of the content that corresponds to the content name
(FIG. 13: Step S1301).
[0161] The key acquisition control unit 204 performs the content
key acquisition process 1 to be described later with reference to
the flow chart in FIG. 14, and transmits the acquired content key,
the content name, and a playback instruction to the decrypting unit
203. When it is not possible to acquire the content key, the key
acquisition control unit 204 transmits an error message to the
decrypting unit 203 (FIG. 13: Step S1302).
[0162] When having received the content key from the key
acquisition control unit 204, the decrypting unit 203 performs the
subsequent processing. In a case where a content key has not been
acquired even after the processing by the key acquisition control
unit 204 is completed, the playback processing of the contents is
completed. It is acceptable to have an arrangement wherein, in a
case where it is not possible to acquire the content key, the user
is notified, by the display on the display device 103 via the
display unit 222, that it is not possible to play back the contents
and of the reason why the content key cannot be acquired (FIG. 13:
Step S1303).
[0163] The decrypting unit 203 performs the contents playback
process 1 to be described later with reference to the flow chart in
FIG. 18 (FIG. 13: Step S1304).
[0164] When the playback of the contents being the playback target
in Step S1304 is completed, the decrypting unit 203 notifies the
playback control unit 202 that the playback is completed.
[0165] The playback control unit 202 judges whether or not there is
a playback continuation instruction from the user (FIG. 13: Step
S1305). When there is no playback continuation instruction, the
playback control unit 202 completes the playback processing. When
there is a playback continuation instruction, the playback control
unit 202 performs the next playback content specification process
1, to be described later with reference to the flow chart in FIG.
20, and the procedure returns to the processing in Step S1302 (FIG.
13: Step S1306).
[0166] This completes the description of the operation performed by
the terminal device 101 to play back the contents stored in the
medium 102 and complete the playback.
[0167] The following describes the content key acquisition process
1 in Step S1302 in FIG. 13, with reference to the flow chart in
FIG. 14.
[0168] The key acquisition control unit 204 controls the reading
unit 201 so that key control information 213 is acquired from the
medium 102 (FIG. 14: Step S1401).
[0169] The key acquisition control unit 204 specifies a piece of
key generation information that corresponds to the content being
the playback target from the key control information 213, based on
the content name acquired from the playback control unit 202.
[0170] The key acquisition control unit 204 judges whether or not a
rights key is required, based on the piece of key generation
information (FIG. 14: Step S1402). More specifically, when the
piece of key generation information is a rights key or a composite
key, the key acquisition control unit 204 judges that a rights key
is required. When the piece of key generation information is a
media key, the key acquisition control unit 204 judges that a
rights key is not required.
[0171] When having judged that a rights key is required, the key
acquisition control unit 204 performs the rights key acquisition
process 1 (FIG. 14: S1403), to be described later with reference to
the flow chart in FIG. 15. When having judged that a rights key is
not required, the key acquisition control unit 204 instructs the
media key generating unit 205 to generate a media key and performs
the media key acquisition process 1 (FIG. 14: Step S1411), to be
described later with reference to the flow chart in FIG. 17.
[0172] When having judged that a rights key is required, the key
acquisition control unit 204 checks whether or not a rights key has
been acquired (FIG. 14: Step S1404).
[0173] For example, when it is not possible to establish the
connection with the connection destination, or when the connection
destination does not own a rights key, it will be a case where it
is not possible to acquire a rights key.
[0174] When it is not possible to acquire a rights key, the key
acquisition control unit 204 returns to the rights key acquisition
process 1, to be described later with reference to the flow chart
in FIG. 15.
[0175] When having acquired a rights key, the key acquisition
control unit 204 performs the subsequent processing.
[0176] The key acquisition control unit 204 judges whether or not a
media key is required, based on the piece of key generation
information (FIG. 14: Step S1405). More specifically, when the
piece of key generation information is a composite key, the key
acquisition control unit 204 judges that a media key is required.
When the piece of key generation information is a rights key, the
key acquisition control unit 204 judges that a media key is not
required.
[0177] When having judged that a media key is not required, the key
acquisition control unit 204 takes the acquired rights key as a
content key. The method of generating a content key is not limited
to just taking a rights key as a content key. It is acceptable to
generate a content key from a rights key and content unique
information, using a one-way function. The method of generating a
content key may be specified in advance at the key acquisition
control unit 204. Alternatively, information that identifies a
generating method may be included in key generation information.
Further, it is acceptable to determine a method for generating a
content key depending on the type of contents to be played
back.
[0178] When having judged that a media key is required, the key
acquisition control unit 204 instructs the media key generating
unit 205 to generate a media key, and performs the media key
acquisition process 1 (FIG. 14: Step S1406), to be descried later
with reference to the flow chart in FIG. 17.
[0179] The key acquisition control unit 204 generates a content key
from the acquired rights key and media key, using a one-way
function (FIG. 14: Step S1407). The method of generating a content
key is not limited to the one using a one-way function. There are
various ways to generate a content key, for example, by decrypting
content unique information with a media key, or by simply combining
the content unique information with a media key and taking a hash
thereof. The method of generating a content key may be specified in
advance at the key acquisition control unit 204. Alternatively,
information that identifies a generating method may be included in
key generation information. Further, it is acceptable to determine
a method for generating a content key depending on the type of
contents to be played back.
[0180] This completes the description of the operation performed by
the key acquisition control unit 204 to acquire a content key.
[0181] The following describes the rights key acquisition process 1
in Step S1403 in FIG. 14, with reference to the flow chart in FIG.
15.
[0182] Based on the priority order indicated in the key control
information 213, the key acquisition control unit 204 specifies a
connection destination module (FIG. 15: Step S1501). To be more
specific, description is provided for a case where a rights key is
to be acquired for a content name with which two or more
corresponding rights formats and connection destination types are
specified. In such a case, the key acquisition control unit 204
determines, as the connection destination module, starting from a
corresponding rights format and a connection destination type that
has a smallest value of the priority order indicated in the key
control information 213. For example, if the key acquisition
control unit 204 is aware in advance that it is not possible to
acquire a rights key from a connection destination module having
the first priority order because, for example, connection cannot be
established, then the key acquisition control unit 204 specifies a
connection destination module having the second priority order as a
connection destination. The key acquisition control unit 204 is
able to find out about connection destination modules from which a
rights key cannot be acquired by, for example, keeping a record of
connection destination modules to which an error message has been
sent during a predetermined length of time in the past, with regard
to a rights key acquisition processing, or polling connection
destination modules regularly to keep a record of the
connectability and holding table information showing modules from
which a rights key cannot be acquired.
[0183] The key acquisition control unit 204 transmits five kinds of
information including the information of the connection destination
specified in Step S1501 to the key acquisition intermediary unit
223 (FIG. 15: Step S1502). The transmitted information contains: a
package identifier, a content name, corresponding rights format
information, connection destination type, a public key certificate
of the contents playback unit 200.
[0184] The key acquisition intermediary unit 223 receives the
information transmitted by the key acquisition control unit 204 in
Step S1502 (FIG. 15: Step S1511).
[0185] The key acquisition intermediary unit 223 extracts the
corresponding rights format information and the connection
destination type from the information received in Step S1511, and
establishes communication with the connection destination module
specified by these two kinds of information (FIG. 15: Step S1512).
More specifically, when the corresponding rights format information
indicates Format D1, and the connection destination type indicates
a license management client A, connection with a license management
client A that corresponds to Format D1 is established. There are
various ways for the key acquisition intermediary unit 223 to
specify a license management client A that corresponds to Format
D1. For example, it is acceptable to use methods such as holding a
table showing the correspondence between MAC addresses or IP
addresses and clients, or making inquiries to all connection
destinations modules that are connectable and specifying a client
according to the responses.
[0186] The key acquisition intermediary unit 223 extracts the
package identifier, the content name, and the public key
certificate of the contents playback unit 200 from the information
received in Step S1511, and transmits the extracted information to
the connection destination module (FIG. 15: Step S1513).
[0187] The connection destination module, which is one of the
license management client A 230, the license management client B
240, and the license server 104, performs the rights key
transmission process 1 (FIG. 15: Step S1521), to be described later
with reference to the flow chart in FIG. 16.
[0188] The key acquisition intermediary unit 223 receives a message
with a signature from the connection destination module (FIG. 15:
Step S1514).
[0189] The message with a signature is a message obtained by
signing a piece of data that contains at least the rights key
encrypted with the public key of the contents playback unit 200,
the playback control conditions, and the use condition type with
the secret key of the connection destination module.
[0190] The key acquisition intermediary unit 223 transmits the
message with the signature to the key acquisition control unit 204
(FIG. 15: Step S1515).
[0191] The key acquisition control unit 204 receives the message
with the signature from the key acquisition intermediary unit 223
(FIG. 15: Step S1503).
[0192] The key acquisition control unit 204 acquires the public key
certificate from the key control information 213 and verifies the
message with the signature (FIG. 15: Step S1504). When the
signature verification result is no good, the key acquisition
control unit 204 completes the content key acquisition processing.
It should be noted that description is provided here for the case
where the public key certificate is set in the medium 102; however,
it is acceptable to acquire the public key certificate from the
outside and perform verification. Explanation will be omitted as to
the method of acquiring the public key certificate and the specific
procedure of the signature verification.
[0193] When the signature verification result is OK, the key
acquisition control unit 204 decrypts the encrypted rights key
contained in the message with the signature, using the secret key
of the contents playback unit 200, and acquires the rights key
(FIG. 15: Step S1505).
[0194] This completes the description of the operation performed by
the key acquisition control unit 204 to acquire a rights key.
[0195] The following describes the rights key transmission process
1 in Step S1521 in FIG. 15, with reference to the flow chart in
FIG. 16.
[0196] The rights key transmission process 1 varies depending on
which connection destination module is the subject of the
operation; therefore, explanation is provided on each case.
[0197] First, explanation is provided for a case where the
connection destination module is either the license management
client A 230 or the license management client B 240, taking the
license management client A 230 as a representative example.
[0198] The usability judging unit 313 receives the information
transmitted by the key acquisition intermediary unit 223 in Step
S1513 (FIG. 16: Step S1601).
[0199] The usability judging unit 313 extracts the package
identifier and the content name from the received information and
specifies and acquires a right that corresponds to the content
being the playback target from the rights storing unit 315, based
on these two kinds of information (FIG. 16: Step S1602).
[0200] The usability judging unit 313 acquires the conditions of
use contained in the right and judges whether or not the contents
are usable based on the conditions of use (FIG. 16: Step S1603).
More specifically, the conditions of use include a playback number
of times, and a playback expiration as described with reference to
FIG. 7. As for the playback number of times, when the playback
number of times is one or more, it is judged that the contents are
usable, whereas when the playback number of times is zero, it is
judged that the contents are unusable. As for the playback
expiration, the usability judging unit 313 acquires a reliable
current time and when the current time is before the playback
expiration, it is judged that the contents are usable, whereas when
the current time is after the playback expiration, it is judged
that the contents are unusable. It should be noted that information
included in the conditions of use are not limited to these
examples.
[0201] When having judged that the contents are unusable, the
usability judging unit 313 signs the error judgment result with the
secret key of the license management client A 230 and generates a
message with a signature to be transmitted (FIG. 16: Step S1607) It
should be noted that it is also acceptable that the error judgment
result contains the cause of the error, for example, "Playback
Expiration is up"or "Playback Number of Times is zero".
[0202] When having judged that the contents are usable, the us
ability judging unit 313 sets a use condition type and transmits
the use condition type along with the right to the key extracting
unit 312. To be more specific, the use condition type is set as
either stateless or stateful depending on the substance of the
conditions of use.
[0203] Being stateless means that the conditions of use do not
require an update after the contents are used. For instance,
conditions of use which indicates that the playback number of times
is unlimited and in which only a playback expiration is set are
stateless. Being stateful means that the conditions of use require
an update after the contents are used. For instance, conditions of
use which indicate that the playback number of times is five are
stateful.
[0204] The key extracting unit 312 extracts a rights key from the
right and generates, if necessary, playback control conditions
(FIG. 16: S1604). More specifically, image quality and sound
quality of the playback are set as the playback control conditions.
These conditions may be set in advance at the license management
client A 230, may be set in the conditions of use, or may be
determined depending on the type of contents to be played back. The
information included in the playback control conditions is not
limited to these examples. It is also acceptable to have no
playback control conditions.
[0205] The key extracting unit 312 transmits the extracted rights
key, the generated playback control conditions, and the use
condition type to the key transmitting unit 314.
[0206] Having received the rights key, the playback control
conditions, and the use condition type, the key transmitting unit
314 acquires the public key of the contents playback unit 200 from
the public key certificate received in Step S1601, and encrypts the
rights key so as to generate an encrypted rights key (FIG. 16: Step
S1605). Here, explanation is provided for the case where the rights
key is encrypted with the public key of the contents playback unit
200; however, it is acceptable to encrypt a rights key with a media
key, or to encrypt a rights key dually with the public key of the
contents playback unit 200 and a media key. In order to acquire a
media key, it is acceptable to make an inquiry to a server that
manages media keys every time when necessary, or to store media
keys within each client. Explanation on the specific procedure will
be omitted.
[0207] It is further acceptable to have an arrangement wherein
either the key acquisition control unit 204 or the key acquisition
intermediary unit 223 generates a random number every time a rights
key acquisition request is made, and stores the random number
within itself as well as transmits the rights key acquisition
request containing the random number, and the key transmitting unit
314 encrypts the rights key and the playback control conditions,
using the random number. To be more specific, the key transmitting
unit 314 encrypts the playback control conditions with an
encryption key generated from the random number and the public key
of the contents playback unit 200 and signs the encrypted rights
key and the encrypted playback control conditions. This method
makes it possible to return a reply message that is different for
every rights key request asking for one same right. Thus, security
level is expected to be improved. Further, the key transmitting
unit 314 signs a piece of data that contains at least the encrypted
rights key, the playback control conditions, and the use condition
type, with a secret key of the license management client A 230 so
as to generate a message with a signature to be transmitted (FIG.
16: S1606).
[0208] Alternatively, it is acceptable to have an arrangement
wherein the key transmitting unit 314 signs a piece of data that
contains the random number in addition to the encrypted rights key,
the playback control conditions, and the use condition type, with a
secret key of the license management client A 230.
[0209] The key transmitting unit 314 transmits the message with the
signature to the key acquisition intermediary unit 223 (FIG. 16:
Step S1608).
[0210] The following describes a case where the connection
destination module is the license server 104.
[0211] The usability judging unit 307 receives the information
transmitted by the key acquisition intermediary unit 223 in Step
S1513 (FIG. 16: Step S1601).
[0212] The usability judging unit 307 extracts the package
identifier and the content name form the received information and
specifies and acquires conditions of use that correspond to the
contents to be played back from the use condition storing unit 306,
based on these two kinds of information (FIG. 16: Step S1602).
[0213] Having acquired the conditions of use, the usability judging
unit 307 judges whether or not he contents are usable based on the
conditions of use (FIG. 16: Step S1603).
[0214] When having judged that the contents are unusable, the
usability judging unit 307 signs the error judgment result with the
secret key of the license server 104 and generates a message with a
signature to be transmitted (FIG. 16: Step S1607).
[0215] When having judged that the contents are usable, the
usability judging unit 307 sets a use condition type, and transmits
the use condition type and the conditions of use, along with the
package identifier and the content name with which the conditions
of use have been specified, to the key extracting unit 312.
[0216] The key extracting unit 312 extracts a rights key from the
key storing unit 305 based on the package identifier and the
content name, and generates, if necessary, playback control
conditions (FIG. 16: Step S1604).
[0217] The key extracting unit 312 transmits the extracted rights
key, the generated playback control conditions and the use
condition type to the key transmitting unit 304.
[0218] Having acquired the rights key and the playback control
conditions, the key transmitting unit 304 acquires the public key
of the contents playback unit 200 from the public key certificate
received in Step S1601 and encrypts the rights key so as to
generate an encrypted rights key (FIG. 16: Step S1605).
[0219] The key transmitting unit 304 signs the piece of data that
contains at least the encrypted rights key, the playback control
conditions, and the use condition type with the secret key of the
license server 104 and generates a message with a signature to be
transmitted (FIG. 16: Step S1606).
[0220] The key transmitting unit 304 transmits the message with the
signature to the key acquisition intermediary unit 223 (FIG. 16:
Step S1608).
[0221] This completes the description of the operation performed by
a connection destination module to transmit a rights key, in the
cases of the license management client A 230 and the license server
104, in the stated order.
[0222] The following describes the media key acquisition process 1
in Steps 1411 and 1405 in FIG. 14, with reference to the flow chart
in FIG. 17.
[0223] The media key generating unit 205 controls the reading unit
201 so that media unique information 214 is acquired from the
medium 102 (FIG. 17: Step S1701).
[0224] The media key generating unit 205 stores therein device
unique information that is unique to the device and judges whether
the device unique information of its own is set in the media unique
information 214 based on the device unique information (FIG. 17:
Step S1702). Here, when the device unique information of its own is
not set, the media key generating unit 205 completes the media key
acquisition processing and also completes the contents playback
processing. For instance, in FIG. 7, the device unique information
"0003" is not registered in the media unique information 214.
Consequently, the terminal device 101 having "0003" as the device
unique information halts without starting the playback of the
medium 102.
[0225] When the device unique information of its own is set in the
media unique information 214, the media key generating unit 205
acquires an encrypted media key that corresponds to the device of
its own (FIG. 17: Step S1703).
[0226] The media key generating unit 205 decrypts the acquired
encrypted media key with the device unique key so as to acquire the
media key (FIG. 17: Step S1704).
[0227] This completes the description of the operation performed by
the media key generating unit 205 to generate a media key.
[0228] The following describes the contents playback process 1 in
Step S1304 in FIG. 13, with reference to the flow chart in FIG.
18.
[0229] The decrypting unit 203 acquires a content key, playback
control conditions, a use condition type, and a content name from
the key acquisition control unit 204. The decrypting unit 203
acquires an encrypted content 212 from the medium 102 based on the
content name (FIG. 18: Step S1801).
[0230] The decrypting unit 203 checks whether or not playback
control conditions are set (FIG. 18: Step S1802).
[0231] When playback control conditions are set, the decrypting
unit 203 plays back the contents while controlling the image
quality and sound quality of the contents according to the playback
control conditions (FIG. 18: Step S1803).
[0232] When playback control conditions are not set, the decrypting
unit 203 plays back the contents without any restriction (FIG. 18:
Step S1804).
[0233] When having received a user instruction to stop the playback
or having completed the playback of the contents being playback
target, the decrypting unit 203 completes the playback of the
contents (FIG. 18: Step S1805).
[0234] The decrypting unit 203 judges whether the conditions of use
that correspond to the contents played back are stateless or
stateful, based on the use condition type acquired from the key
acquisition control unit 204 (FIG. 18: Step S1806).
[0235] When the conditions of use are stateless, the decrypting
unit 203 judges that the conditions of use do not need to be
updated, and completes the playback processing of the contents.
[0236] When the conditions of use are stateful, the decrypting unit
203 generates a playback history for the purpose of updating the
conditions of use (FIG. 18: Step S1807). More specifically, a
playback history is generated to indicate that, for example, "the
playback number of times is one" or "the playback period is two
hours".
[0237] The decrypting unit 203 transmits the playback history and a
history transmission instruction to the key acquisition control
unit 204.
[0238] Having received the playback history and the history
transmission instruction from the decrypting unit 203, the key
acquisition control 204 transmits, to the key acquisition
intermediary unit 223, (i) transmission data containing six kinds
of information including at least information of the connection
destination specified in Steps S1501 and (ii) a message with a
signature obtained by signing, with the secret key of the contents
playback unit 200, the transmission data from which corresponding
rights format information and connection destination type are
excluded (FIG. 18: Step S1808). The transmission data contains a
package identifier, a content name, corresponding rights format
information, a connection destination type, a public key
certificate of the contents playback unit 200, and a playback
history.
[0239] The key acquisition intermediary unit 223 receives the
message with the signature transmitted by the key acquisition
control unit 204 in Step S1808 (FIG. 18: Step S1811).
[0240] The key acquisition intermediary unit 223 extracts the
corresponding rights format information and the connection
destination type from the message with the signature received in
Step S1808 and establishes communication with the connection
destination module specified by these two kinds of information
(FIG. 18: Step S1812).
[0241] The key acquisition intermediary unit 223 extracts the
package identifier, the content name, the public key certificate of
the contents playback unit 200, the playback history, and the
signature data from the message with the signature received in Step
S1808, and transmits these kinds of information to the use
condition updating unit 316 of the connection destination module
(FIG. 18: Step S1813). It should be noted that it is acceptable to
have an arrangement wherein all the kinds of information in the
transmission data are signed in Step S1808, and the message with
the signature received in Step S1808 is transmitted to the
connection destination module as the way it is in Step S1813.
[0242] The connection destination module, which is one of the
license management client A 230, the license management client B
240, and the license server 104, performs the use condition update
process 1 (FIG. 18: Step S1821), to be described later with
reference to the flow chart in FIG. 19.
[0243] The key acquisition intermediary unit 223 receives, from the
connection destination module, a message with a signature obtained
by signing a piece of data that contains at least a result of the
use condition processing with the secret key of the connection
destination module (FIG. 18: Step S1814).
[0244] The key acquisition intermediary unit 223 transmits the
message with the signature to the key acquisition control unit 204
(FIG. 18: Step S1815).
[0245] The key acquisition control unit 204 receives the message
with the signature from the key acquisition intermediary unit 223
(FIG. 18: Step S1809).
[0246] The key acquisition control unit 204 acquires a public key
certificate from the key control information 213 and verifies the
message with the signature (FIG. 18: step S180A). When the
signature verification result is no good, the key acquisition
control unit 204 performs a predetermined processing to be
conducted in the event of a signature verification error (FIG. 18:
Step S180B). For example, the key acquisition control unit 204
judges that the connection destination module is unreliable and
registers it as an unconnectable connection destination module.
[0247] When the signature verification result is OK, the key
acquisition control unit 204 performs a predetermined processing
according to the results of the use condition update processing
(FIG. 18: Step S180C). For example, when the result of the
processing indicates a use condition update error, the key
acquisition control unit 204 performs the use condition update
process 1 again, or prohibits the terminal device 101 from playing
back contents thereafter. Conversely, when the result of the
processing indicates a normal termination, the result as such may
be displayed on the screen to notify the user. The processing to be
conducted in the event of a signature verification error and the
processing to be conducted according to the use condition update
processing result may be performed according to information having
been set in the medium 102 or may be performed after making an
inquiry to the outside.
[0248] This completes the description of the operation performed by
the decrypting unit 203 to start the playback of contents and
complete the playback of the contents.
[0249] The following describes the use condition update process 1
in Step S1821 in FIG. 18, with reference to the flow chart in FIG.
19.
[0250] The use condition update process 1 varies depending on which
connection destination module is the subject of the operation;
therefore, explanation is provided on each case.
[0251] First, explanation is provided for a case where the
connection destination module is either the license management
client A 230 or the license management client B 240, taking the
license management client A 230 as a representative example.
[0252] The use condition updating unit 316 receives the information
transmitted by the key acquisition intermediary unit 223 in Step
S1813 (FIG. 19: Step S1901).
[0253] The use condition updating unit 316 extracts the public key
certificate of the contents playback unit 200 from the received
information and acquires the public key of the contents playback
unit 200.
[0254] The use condition updating unit 316 verifies the signature
of the information received in Step S1901, based on the public key
(FIG. 19: Step S1902). When the signature verification result is no
good, the use condition updating unit 316 does not update the
conditions of use, and performs the processing in and after Step
S1905.
[0255] When the signature verification result is OK, the use
condition updating unit 316 specifies and acquires a right that
includes the conditions of use of the update target from the rights
storing unit 315, based on the package identifier and the content
name contained in the information received in Step S1901 (FIG. 19:
Step S1903).
[0256] The use condition updating unit 316 updates the conditions
of use, based on the conditions of use contained in the right and
the playback history contained in the information received in Step
S1901 and stores the right containing the updated conditions of use
into the rights storing unit 315 (FIG. 19: Step S1904). More
specifically, when the conditions of use indicates the playback
number of times is "five", and the playback history indicates "two
times" of playback, the conditions of use is updated to indicate
that the playback number of times is "three".
[0257] The use condition updating unit 316 signs a piece of data
that contains at least a processing result, with the secret key of
the license management client A 230 and generates a message with a
signature to be transmitted (FIG. 19: Step S1905). More
specifically, a signature error, a normal termination, or use
condition update error may be set as a processing result.
[0258] The use condition updating unit 316 transmits the message
with the signature to the key acquisition intermediary unit 223
(FIG. 19: Step S1906).
[0259] The following explains the case where the connection
destination module is the license server 104.
[0260] The use condition updating unit 308 receives the information
transmitted by the key acquisition intermediary unit 223 in Step
S1813 (FIG. 19: Step S1901).
[0261] The use condition updating unit 308 extracts the public key
certificate of the contents playback unit 200 from the received
information and acquires the public key of the contents playback
unit 200.
[0262] The use condition updating unit 308 verifies the signature
of the information received in Step S1901, based on the public key
(FIG. 19: Step S1902). When the signature verification result is no
good, the use condition updating unit 308 does not update the
conditions of use, and performs the processing in and after Step
S1905.
[0263] When the signature verification result is OK, the use
condition updating unit 308 acquires the conditions of use of the
update target from the use condition storing unit 306, based on the
package identifier and the content name contained in the
information received in Step S1901 (FIG. 19: Step S1903).
[0264] The use condition updating unit 308 updates the conditions
of use, from the conditions of use and the playback history
contained in the information received in Step S1901 and stores the
updated conditions of use into the use condition storing unit 306
(FIG. 19: Step 1904).
[0265] The use condition updating unit 308 signs a piece of data
that contains at least the processing result with the secret key of
the license server 104 and generates a message with a signature to
be transmitted (FIG. 19: Step S1905).
[0266] The use condition updating unit 316 transmits the message
with the signature to the key acquisition intermediary unit 223
(FIG. 19: Step S1906).
[0267] This completes the description of the operation performed by
a connection destination module to update conditions of use, in the
cases of the license management client A 230 and the license server
104, in the stated order.
[0268] The following describes the next playback content
specification process 1 in Step S1306 in FIG. 13, with reference to
the flow chart in FIG. 20.
[0269] The playback control unit 202 controls the reading unit 201
so that playback control information 211 is acquired from the
medium 102 (FIG. 20: Step S2001).
[0270] The playback control unit 202 searches in the playback
control information 211, based on a content name of the content of
which the playback has just completed, to specify the Next-playback
Number that corresponds to the content name (FIG. 20: Step
S2002).
[0271] The playback control unit 202 specifies a content name of
the content to be played back next based on the Next-playback
Number (FIG. 20: Step S2003).
[0272] Finally, the processing performed by either the license
management client A 230 or the license management client B 240, to
acquire a right from the license server 104, taking the license
management client A 230 as a representative example.
[0273] When the user operates the operation unit 221 and instructs
acquisition of a right as well as inputs the package identifier and
the content name of the right to be acquired, the following
processing starts:
[0274] The rights acquiring unit 311 of the license management
client A 230 transmits the package identifier and the content name
to the license server 104.
[0275] The transmission control unit 302 of the license server 104
performs user authentication and other processing and judges
whether or not it is acceptable to transmit a right. When the
judgment result is OK to transmit a right, the transmission control
unit 302 instructs the right generating unit 303 to generate a
right. When the judgment result is no good to transmit a right, the
transmission control unit 302 replies to the license management
client A 230 with a reason why the transmission of a right is no
good.
[0276] The right generating unit 303 acquires conditions of use
that corresponds to the package identifier and the content name
from the use condition storing unit 306 and acquires a
corresponding right key from the key storing unit 305, so as to
generate a right.
[0277] The right generating unit 303 transmits the right to the
right transmitting unit 301. The rights transmitting unit 301
transmits the right to the right acquiring unit 311 of the license
management client A 230.
[0278] The right acquiring unit 311 stores the right received from
the rights transmitting unit 301 into the rights storing unit 315.
Here, it should be noted that the right acquisition processing
starts as a result of the user explicitly operates the operation
unit 221; however, it is acceptable to have an arrangement wherein
a right is automatically acquired when purchase of contents is
completed, or a right is automatically acquired as a result of
prediction of the contents to be played back next based on a
playback history of contents.
[0279] This completes the description of the first embodiment of
the present invention.
Second Embodiment
[0280] The following describes the contents playback system of the
second embodiment of the present invention. The contents playback
system of the second embodiment has almost the same configuration
and operates almost in the same manner as the contents playback
system of the first embodiment except that there are partial
differences; therefore, only the differences from the first
embodiment will be described. Also, the same reference signs are
used in the drawings to describe the components in common.
[0281] The first embodiment describes a case where, when the
contents playback unit 200 is to acquire a rights key, the
connection destination module is the same as the module
transmitting the rights key.
[0282] The second embodiment describes a case where, when the
contents playback unit 200 is to acquire a rights key, the
connection destination module is not necessarily the same as the
module transmitting the rights key.
[0283] FIG. 21 shows the internal structure of the terminal device
101 and information recorded on the medium 102.
[0284] Firstly, explanation is provided on the internal structure
of the terminal device 101.
[0285] The terminal device 101 comprises: a contents playback unit
200; an operation unit 221; a display unit 222; a key acquisition
intermediary unit 223; a license management client A 230; and a
license management client B 240.
[0286] The contents playback unit 200 comprises: a reading unit
201; a playback control unit 202; a decrypting unit 203; a key
acquisition control unit 204; a media key generating unit 205; and
a key storing unit 206 operable to store therein a rights key.
[0287] Description of information recorded on the medium 102 will
be omitted, as it is the same as that in the first embodiment.
[0288] FIG. 22 shows the internal structure of the license server
104, the license management client A 230, and the license
management client B 240.
[0289] It should be noted that, in FIG. 3, the internal structure
of the license management client A 230 is shown as a
representative, since the license management client A 230 and the
license management client B 240 have the same structure.
[0290] Description of the internal structure of the license server
104 will be omitted since it is the same as that of the first
embodiment.
[0291] The following describes the internal structure of the
license management client A 230.
[0292] The license management client A 230 comprises: a rights
acquiring unit 311; a key extracting unit 312; a usability judging
unit 313; a key transmitting unit 314 operable to transmit a rights
key to the outside; a rights storing unit 315; and a use condition
updating unit 316; and an acquisition source judging unit 317
operable to judge an acquisition source from which a rights key is
acquired.
[0293] This completes the detailed description of the structures of
the terminal device 101, the license server 104, and the license
management client A 230.
[0294] The following describes data and data structure to be dealt
with in the second embodiment. Playback control information 211 and
key control information 213 stored in the medium 102 will be
described with reference to FIGS. 23 ad 24. The data structures of
other kinds of data will be omitted since they are the same as
those in the first embodiment.
The Data Structure of the Playback Control Information 211
[0295] FIG. 23 shows an example of data structure of the playback
control information 211. The playback control information 211
includes eight kinds of information as below:
[0296] "Playback Number"
[0297] This is an index number that uniquely identifies each of the
pieces of information arranged in lines and registered in the
playback control information 211, respectively.
[0298] "Content Name"
[0299] It is information that identifies each of contents arranged
in the lines.
[0300] "Next-Playback Number"
[0301] It is the line number of a content to be played back next,
when the playback of the content in this line is completed.
[0302] "Alternative Playback Number"
[0303] It is the line number of a content to be played back
alternatively, when the playback of the content indicated with the
Next-playback Number is found to be impossible.
[0304] "Corresponding Rights Format Information"
[0305] It is information that identifies a format of the
corresponding rights information for a line in which the key
generation information is specified as a rights key or a composite
key.
[0306] "Connection Destination Type"
[0307] This information is paired with "Corresponding Rights Format
Information" and is for specifying a connection destination when a
rights key is to be acquired, for a line in which the key
generation information is specified as a rights key or a composite
key.
[0308] "Acquisition Source Type"
[0309] This information is paired with "Corresponding Rights Format
Information" and is for specifying an acquisition source from which
a rights key is acquired for a line in which the key generation
information is specified as a rights key or a composite key. For
example, for the third line, "Client A" is specified as the
connection destination, and "Server" is specified as the
acquisition source; consequently, when acquiring a rights key for
the content, the contents playback unit 200 connects to the license
management client A 230 in Format D1, and acquires a rights key
from the license server 104 via the license management client A
230. In the present embodiment, as an example in which the
connection destination is different from the acquisition source, it
is assumed that the connection destination is a license management
client contents, and the acquisition source is the license server
104. In other words, such an example is not assumed in which the
connection destination is the license server 104, and the
acquisition source is the license management client contents.
[0310] "Priority Order"
[0311] It is information that indicates the priority order among
connection destinations, in a case where there is more than one
connection destination, denoting the order in which connection
processing is performed, for a line in which the key generation
information is specified as a rights key or a composite key.
The Data Structure of the Key Control Information 213
[0312] FIG. 24 shows an example of data structure of the key
control information 213. The key control information 213 includes
six kinds of information as below:
[0313] "Content Name"
[0314] It is information that identifies each of contents arranged
in the lines.
[0315] "Content Unique Information"
[0316] It is unique information that is designated for each content
and is used for generating a key for the content.
[0317] "Key Generation Information"
[0318] It is information to specify a generation method to be used
when a key for the content is generated.
[0319] "Playback Possibility Information"
[0320] It is information that indicates whether or not the playback
of each content is possible or not.
[0321] "Copiability Information"
[0322] It is information that indicates whether or not each content
is copiable.
[0323] "Public Key Certificate"
[0324] It is information for verifying the signature of a message
received from a connection destination module specified by
"Corresponding Rights Format Information" and "Connection
Destination Type" that correspond to the same content name in the
playback control information 211, for a line in which the key
generation information is specified as a rights key or a composite
key. To be more specific, a public key certificate of the
connection destination module is set. It should be noted that, in
this example, a public key certificate of the connection
destination module is set; however, it is acceptable to have an
arrangement wherein a piece of identification information that
uniquely identifies a public key certificate of the acquisition
source module is set, and the contents playback unit 200 acquires
the public key certificate of the acquisition source module
according to the piece of identification information.
Alternatively, it is acceptable to set the public key of the
acquisition source module in each line.
[0325] Further, the piece of identification information that
uniquely identifies a public key certificate of the acquisition
source module may be, for example, Corresponding Rights Format
Information and Acquisition Source Type.
[0326] This completes the description of the data structure of the
data dealt with in the second embodiment.
[0327] The following describes the processing performed by the
terminal device 101 to playback the contents stored in the medium
102 and complete the playback, with reference to FIGS. 25 through
30.
[0328] With reference to the flow chart in FIG. 25, description is
provided for the operation performed by the terminal device 101 to
playback the contents stored in the medium 102 and complete the
playback.
[0329] When the key acquisition trigger detecting unit (not shown
in the drawing) in the terminal device 101 has detected an event
upon which a content key should be acquired, the key acquisition
trigger detection unit instructs the playback control unit 202 to
acquire a content key (FIG. 25: Step S2501). Examples of such an
event include: turning the power of the terminal device 101 on;
inserting the medium 102 into the terminal device 101; a key
acquisition instruction from the user; and presenting a menu with a
list of contents of which the playback is possible to the user
based on the playback control information 211.
[0330] The playback control unit 202 controls the reading unit 201
so that the playback control information 211 is read from the
medium 102, acquires the content name that corresponds to the
Playback Number 1, and specifies the content to be played back.
[0331] The playback control unit 202 performs, with the use of the
playback control information 211 and the content name, the content
key acquisition storing process 2 to be described later with
reference to the flowchart in FIG. 26, and stores the acquired
content key into the key storing unit 206 (FIG. 25: Step
S2502).
[0332] It should be noted that in order to present a menu with a
list of contents of which the playback is possible to the user, the
processing in Step S2502 is repeated for each of the content names,
and the user will be notified that contents whose content keys have
been acquired are the contents of which the playback is possible,
and that contents whose contents key have not been acquired are the
contents of which the playback is not possible. For example, in a
list of contents, those contents of which the playback is not
possible may be indicated with gray shades.
[0333] The user selects a content to be played back from the list
of contents via the operation unit 221. The operation unit 221
inputs the content name that corresponds to the content to the
playback control unit 202.
[0334] The playback control unit 202 specifies a content being a
playback target based on the content name (FIG. 25: Step S2503) The
playback control unit 202 extracts the package identifier from the
playback control information 211 and transmits the extracted
package identifier along with the content name to the key
acquisition control unit 204.
[0335] The key acquisition control unit 204 acquires a content key,
playback control conditions, and a use condition type that
correspond to the content being the playback target, from the key
storing unit 206, based on the package identifier and the content
name.
[0336] The key acquisition control unit 204 transmits the content
name, the content key, the playback control conditions, and the use
condition type to the decrypting unit 203 and instructs the
decrypting unit 203 to play back the contents.
[0337] The decrypting unit 203 performs the contents playback
process 2 (FIG. 25: Step S2504), to be described later with
reference to the flow chart in FIG. 29.
[0338] When the playback of the contents being the playback target
in Step S2504 is completed, the decrypting unit 203 notifies the
playback control unit 202 that the playback is completed.
[0339] The playback control unit 202 judges whether or not there is
a playback continuation instruction from the user (FIG. 25: Step
S2505). When there is no playback continuation instruction, the
playback control unit 202 completes the playback processing.
[0340] When there is a playback continuation instruction, the
playback control unit 202 performs the next playback content
specification process 1 which has been described earlier with
reference to the flow chart in FIG. 20, and the procedure returns
to the processing in Step S2504 (FIG. 25: Step S2506).
[0341] This completes the description of the operation performed by
the terminal device 101 to play back the contents stored in the
medium 102 and complete the playback.
[0342] The following describes the content key acquisition storing
process 2 in Step S2502 in FIG. 25, with reference to the flow
chart in FIG. 26.
[0343] The playback control unit 202 specifies a piece of
corresponding rights format information that corresponds to the
content being the playback target from the playback control
information 211, based on the content name (FIG. 26: Step
S2601).
[0344] The playback control unit 202 judges whether or not a rights
key is required, according to the corresponding rights format
information (FIG. 26: Step S2602). More specifically, when
corresponding rights format information is set, the playback
control unit 202 judges that a rights key is required. When no
information is set as corresponding rights format information, the
playback control unit 202 judges that a rights key is not
required.
[0345] When having judged that a rights key is required, the
playback control unit 202 performs the rights key acquisition
process 2 (FIG. 26: S2603), to be described later with reference to
the flow chart in FIG. 27.
[0346] After performing the rights key acquisition process 2, the
playback control unit 202 checks whether or not a rights key has
been acquired (FIG. 26: Step S2604).
[0347] When a rights key has not been acquired, the playback
control unit 202 performs the rights key acquisition process 2
again.
[0348] When having confirmed that a rights key has been acquired,
the playback control unit 202 extracts a package identifier from
the playback control information 211, and transmits the acquired
rights key, playback control conditions, a use condition type, the
extracted package identifier, and the content name to the key
acquisition control unit 204, as well as instructs the key
acquisition control unit 204 to generate a content key and store
various data.
[0349] The key acquisition control unit 204 controls the reading
unit 201 so that so that key control information 213 is acquired
from the medium 102.
[0350] The key acquisition control unit 204 specifies a piece of
key generation information that corresponds to the content being
the playback target from the key control information 213, based on
the content name.
[0351] The key acquisition control unit 204 judges whether or not a
media key is required, based on the piece of key generation
information (FIG. 26: Step S2605). More specifically, when the
piece of key generation information indicates a rights key or a
composite key, the key acquisition control unit 204 judges that a
media key is required. When the piece of key generation information
indicates a rights key, the key acquisition control unit 204 judges
that a media key is not required.
[0352] When having judged that a media key required, the key
acquisition control unit 204 transmits the content name to the
media key generating unit 205 and instructs the media key
generating unit 205 to generate a media key.
[0353] The media key generating unit 205 performs the media key
acquisition process 1 (FIG. 26: Step S2606), which has been
described earlier with reference to the flow chart in FIG. 17.
[0354] The media key generating unit 205 transmits the media key
generated in the media key acquisition process 1 to the key
acquisition control unit 204.
[0355] The key acquisition control unit 204 generates a content key
from the rights key and the media key and stores the generated
content key along with the playback control conditions and the use
condition type into the key storing unit 206 (FIG. 26: Step S2607).
The method of generating a content key from a rights key and a
media key is the same as the one described in the first
embodiment.
[0356] When the content key, the playback control conditions, the
use condition type have been stored, the key acquisition control
unit 204 notifies the playback control unit 202 that storing of the
content key has been, completed.
[0357] When having judged that a rights key is not required in Step
S2602, the playback control unit 202 extracts a package identifier
from the playback control information 211 and transmits the package
identifier and the content name to the key acquisition control unit
204 and instructs the key acquisition control unit 204 to generate
and store a content key.
[0358] Having received the instruction, the key acquisition control
unit 204 transmits the content name to the media key generating
unit 205 and instructs the media key generating unit 205 to
generate a media key.
[0359] The media key generating unit 205 performs the media key
acquisition process 1 (FIG. 26: Step S2611), which has been
described earlier with reference to the flow chart in FIG. 17.
[0360] The media key generating unit 205 transmits the media key
generated in the media key acquisition process 1 to the key
acquisition control unit 204.
[0361] The key acquisition control unit 204 stores the received
media key being a content key along with the playback control
conditions and the use condition type into the key storing unit
206, in such a manner that the stored information is in
correspondence with the package identifier and the content
name.
[0362] When storing of the content key, the playback control
conditions, and the use condition type has been completed, the key
acquisition control unit 204 notifies the playback control unit 202
that storing of the content key is completed.
[0363] This completes the description of the operation performed by
the playback control unit 202 to acquire and store a content
key.
[0364] The following describes the rights key acquisition process 2
in Step S2603 in FIG. 26, with reference to the flow chart in FIG.
27.
[0365] The playback control unit 202 specifies a connection
destination module, according to the priority level indicated in
the playback control information 211 (FIG. 27: Step S2701).
[0366] The playback control unit 202 transmits five kinds of
information including a piece of information that identifies the
connection destination module specified in Step S2701 to the key
acquisition intermediary unit 223 (FIG. 27: Step S2702). The
transmitted information includes a package identifier, a content
name, corresponding rights format information, a connection
destination type, an acquisition source type, and a public key
certificate of the contents playback unit 200.
[0367] The key acquisition intermediary unit 223 receives the
information transmitted by the playback control unit 202 in Step
S2702 (FIG. 27: Step S2711).
[0368] The key acquisition intermediary unit 223 extracts the
corresponding rights format information and the connection
destination type from the information received in Step S2711, and
establishes communication with the connection destination module
specified from these two kinds of information (FIG. 27: Step
S2712).
[0369] The key acquisition intermediary unit 223 extracts the
package identifier, the content name, the acquisition source type,
and the public key certificate of the contents playback unit 200
from the information received in Step S2711, and transmits the
extracted information to the connection destination module (FIG.
27: Step S2713).
[0370] The connection destination module, which is one of the
license management client A 230, the license management client B
240, and the license server 104, performs the rights key
transmission process 2 (FIG. 27: Step S2721), to be described later
with reference to the flow chart in FIG. 28.
[0371] The key acquisition intermediary unit 223 receives a message
with a signature from the connection destination module (FIG. 27:
Step S2714). The message with the signature is obtained by signing
a data that contains at least a right key encrypted with the public
key of the contents playback unit 200, playback control conditions,
and a use condition type, with the secret key of the acquisition
source module.
[0372] The key acquisition intermediary unit 223 transmits the
message with the signature to the playback control unit 202 (FIG.
27: Step S2715).
[0373] The playback control unit 202 receives the message with the
signature from the key acquisition intermediary unit 223 (FIG. 27:
Step S2703).
[0374] The playback control unit 202 transmits the content name and
the message with the signature to the key acquisition control unit
204 and instructs the key acquisition control unit 204 to verify
the signature.
[0375] The key acquisition control unit 204 controls the reading
unit 201 so that key control information 213 is acquired from the
medium 102.
[0376] The key acquisition control unit 204 acquires a public key
certificate that corresponds to the content being the playback
target from the key control information 213, based on the content
name.
[0377] The key acquisition control unit 204 verifies the message
with the signature, using the public key certificate (FIG. 27: Step
S2704).
[0378] When the signature verification result is no good, the key
acquisition control unit 204 completes the content key acquisition
processing and transmits an error message to the playback control
unit 202.
[0379] When the signature verification result is OK, the key
acquisition control unit 204 decrypts the encrypted rights key
contained in the message with the signature, using the secret key
of the contents playback unit 200 and acquires the rights key (FIG.
27: Step S2705).
[0380] The key acquisition control unit 204 transmits the rights
key, the playback control conditions, the use condition type to the
playback control unit 202 and notifies that acquisition of the
rights key is completed.
[0381] This completes the description of the operation performed by
the playback control unit 202 to acquire the rights key.
[0382] The following describes the rights key transmission process
2 in Step S2721 in FIG. 27, with reference to the flow chart in
FIG. 28.
[0383] The rights key transmission process 2 varies depending on
which connection destination module is the subject of the
operation; therefore, explanation is provided on each case.
[0384] First, explanation is provided for a case where the
connection destination module is either the license management
client A 230 or the license management client B 240, taking the
license management client A 230 as a representative example.
[0385] The acquisition source judging unit 317 receives the
information transmitted by the key acquisition intermediary unit
223 in Step S2713 (FIG. 28: Step S2801).
[0386] The acquisition source judging unit 317 extracts the
corresponding rights format information and the acquisition source
type from the received information.
[0387] The acquisition source judging unit 317 judges whether or
not the acquisition source module from which the rights key is
acquired is an outside module, based on the acquisition source type
(FIG. 28: Step S2831). More specifically, the acquisition source
judging unit 317 judges whether the value being set as the
acquisition source type matches the type information of its own.
When the value does not match its own type information, the
acquisition source judging unit 317 judges that the acquisition
source is an outside module. When the value matches its own type
information, the acquisition source judging unit 317 judges that
the acquisition source is itself.
[0388] When the acquisition source module is an outside module, the
acquisition source judging unit 317 establishes connection with the
outside module specified by the corresponding rights format
information and the acquisition source type. More specifically,
when Format D1 is specified as the corresponding right format
information, and a server is specified as the acquisition source
type, the acquisition source judging unit 317 establishes
communication with the license server 104 that corresponds to
Format D1.
[0389] The acquisition source judging unit 317 extracts the package
identifier, the content name, and the public key certificate of the
contents playback unit 200 from the received information, and
transmits the extracted information to the outside module (FIG. 28:
Step S2811).
[0390] When having received the information transmitted by the
acquisition source judging unit 317 in Step S2811, the outside
module performs the rights key transmission process 1, which has
been described earlier with reference to the flow chart in FIG. 16,
and transmits a message with a signature to the license management
client A 230.
[0391] The license management client A 230 receives the message
with the signature (FIG. 28: Step S2812).
[0392] The license management client A 230 transmits the message
with the signature to the key acquisition intermediary unit 223
(FIG. 28: Step S2813).
[0393] When the acquisition source module is judged to be itself in
Step S2831, the acquisition source judging unit 317 transmits the
received information to the usability judging unit 313 and
instructs the usability judging unit 313 to perform usability
judging processing based on the conditions of use.
[0394] The processing in Steps from S2802 to S2808 is the same as
the processing in Steps from S1602 to S1608 described in the first
embodiment; therefore, explanation will be omitted.
[0395] The following describes a case where the connection
destination module is the license server 104.
[0396] As mentioned in the description of the data structure of the
playback control information 211, in the present embodiment, when
the connection destination is the license server 104, it is assumed
that the rights key acquisition source is also the license server
104.
[0397] The processing performed when the connection destination and
the acquisition source are both the license server 104 is the same
as the rights key transmission process 1 in the first embodiment;
therefore, explanation will be omitted.
[0398] This completes the description of the operation performed by
a connection destination module to transmit a rights key, in the
cases of the license management client A 230 and the license server
104, in the stated order.
[0399] The following describes the contents playback process 2 in
Step S2504 in FIG. 25, with reference to the flow chart in FIG.
29.
[0400] The decrypting unit 203 acquires a content key, playback
control conditions, a use condition type, and a content name from
the key acquisition control unit 204.
[0401] The processing in Steps from S2901 to S2907 is the same as
the processing in Steps from S1801 to Step 1807 described in the
first embodiment; therefore, explanation will be omitted.
[0402] The decrypting unit 203 transmits the playback history and a
history transmission instruction to the key acquisition control
unit 204.
[0403] The key acquisition control unit 204 transmits the playback
history received from the decrypting unit 203 to the playback
control unit 202 and instructs the playback control unit 202 to
transmit the playback history.
[0404] The playback control unit 202 transmits, to the key
acquisition intermediary unit 223, (i) transmission data containing
six kinds of information including at least information of a
connection destination module and an acquisition source module,
(ii) a message with a signature obtained by signing, with the
secret key of the contents playback unit 200, the transmission data
from which corresponding rights format information and connection
destination type are excluded (FIG. 29: Step S2908). The
transmission data contains a package identifier, a content name,
corresponding rights format information, a connection destination
type, an acquisition source type, a public key certificate of the
contents playback unit 200, and a playback history.
[0405] The key acquisition intermediary unit 223 receives the
message with the signature transmitted by the key acquisition
control unit 204 in Step S2908 (FIG. 29: Step S2911).
[0406] The key acquisition intermediary unit 223 extracts the
corresponding rights format information and the connection
destination type from the message with the signature received in
Step S2908 and establishes communication with the connection
destination module specified by these two kinds of information
(FIG. 29: Step S2912).
[0407] The key acquisition intermediary unit 223 extracts the
package identifier, the content name, the acquisition source type,
the public key certificate of the contents playback unit 200, the
playback history, and the signature data from the message with the
signature received in Step S2908, and transmits the extracted
information to the use condition updating unit 316 of the
connection destination module (FIG. 29: Step S2913).
[0408] The connection destination module, which is one of the
license management client A 230, the license management client B
240, and the license server 104, performs the use condition update
process 2 (FIG. 29: Step S2921), to be described later with
reference to the flow chart in FIG. 30.
[0409] The key acquisition intermediary unit 223 receives, from the
connection destination module, a message with a signature obtained
by signing a piece of data that contains at least a result of the
use condition processing with the secret key of the acquisition
source module (FIG. 29: Step S2914).
[0410] The key acquisition intermediary unit 223 transmits the
message with the signature to the key acquisition control unit 204
(FIG. 29: Step S2915).
[0411] The processing in Steps from S2909 to S2907B is the same as
the processing in Steps from S1809 to S180B described in the first
embodiment; therefore, explanation will be omitted.
[0412] This completes the description of the operation performed by
the decrypting unit 203 to start the playback of the contents and
complete the playback.
[0413] The following describes the use condition update process 2
in Step S2921 in FIG. 29, with reference to the flow chart in FIG.
30.
[0414] The use condition update process 2 varies depending on which
connection destination module is the subject of the operation;
therefore, explanation is provided on each case.
[0415] First, explanation is provided for a case where the
connection destination module is either the license management
client A 230 or the license management client B 240, taking the
license management client A 230 as a representative example.
[0416] The acquisition source judging unit 317 receives the
information transmitted by the key acquisition intermediary unit
223 in Step S2913 (FIG. 30: Step S3001).
[0417] The acquisition source judging unit 317 extracts the
corresponding rights format information and an acquisition source
type from the received information.
[0418] The acquisition source judging unit 317 judges whether or
not the module that updates the conditions of use is an outside
module, based on the acquisition source type (FIG. 30: Step S3002).
More specifically, the acquisition source judging unit 317 judges
whether the value being set as the acquisition source type matches
the type information of its own. When the value does not match its
own type information, the acquisition source judging unit 317
judges that the module that updates the conditions of use is an
outside module. When the value matches its own type information,
the acquisition source judging unit 317 judges that the module that
updates the conditions of use is itself.
[0419] When the module that updates the conditions of use is an
outside module, the acquisition source judging unit 317 establishes
connection with the outside module specified by the corresponding
rights format information and the acquisition source type.
[0420] The acquisition source judging unit 317 extracts the package
identifier, the content name, and the public key certificate of the
contents playback unit 200, the playback history, and the signature
data from the received information, and transmits the extracted
information to the outside module (FIG. 30: Step S3011).
[0421] When having received the information transmitted by the
acquisition source judging unit 317 in Step S3011, the outside
module performs the use condition update process 1, which has been
described earlier with reference to the flow chart in FIG. 19, and
transmits a message with a signature to the license management
client A 230.
[0422] The license management client A 230 receives the message
with the signature (FIG. 30: Step S3012).
[0423] The license management client A 230 transmits the message
with the signature to the key acquisition intermediary unit 223
(FIG. 30: Step S3013).
[0424] When the acquisition source module is judged to be itself in
Step S3002, the acquisition source judging unit 317 transmits the
received information to the usability judging unit 313 and
instructs the usability judging unit 313 to perform the use
condition update process.
[0425] The processing in Steps from S3003 to Step S3007 is the same
as the processing in Steps from S1902 to S1906 described in the
first embodiment; therefore, explanation will be omitted.
[0426] The following describes the case in which the connection
destination module is the license server 104.
[0427] As mentioned in the description of the data structure of the
playback control information 211, in the present embodiment, when
the connection destination is the license server 104, it is assumed
that the rights key acquisition source is also the license server
104.
[0428] The processing performed when the connection destination and
the acquisition source are both the license server 104 is the same
as the rights key transmission process 1 in the first embodiment;
therefore, explanation will be omitted.
[0429] This completes the description of the operation performed by
a connection destination module to transmit a rights key, in the
cases of the license management client A 230 and the license server
104, in the stated order.
[0430] The following describes the processing to be performed in a
case where the contents playback unit 200 does not include the key
storing unit 206.
[0431] When having detected an event upon which a menu with a list
of contents should be displayed, the playback control unit 202 has
a menu with a list of contents displayed on the display device 103.
Examples of such an event include: turning the power of the
terminal device 101 on; inserting the medium 102 into the terminal
device 101; a key acquisition instruction from the user; and
presenting a menu with a list of contents of which the playback is
possible to the user based on the playback control information
211.
[0432] The user specifies a desired content from the menu with a
list of contents and notifies the content name to the playback
control unit 202 via the operation unit 221.
[0433] The playback control unit 202 performs the processing before
the storing of the content key, the playback control conditions,
and the use condition type performed by the key acquisition control
unit 204 in the content key acquisition storing process 2, which
has been described earlier with reference to the flow chart in FIG.
26.
[0434] The key acquisition control unit 204 transmits the content
name, the content key, the playback control conditions, and the use
condition type to the decrypting unit 203 and instructs the
decrypting unit 203 to play back the content.
[0435] The decrypting unit 203 performs the contents playback
process 2, which has been described earlier with reference to the
flow chart in FIG. 29.
[0436] In the case where the key generation information in the key
control information 213 indicates a media key or a composite key,
and a media key is required for playback of a content, description
has been provided in the second embodiment that a media key is
acquired in the content key acquisition storing process 2 so as to
generate a content key.
[0437] It is acceptable, however, to acquire and store only a
rights key in the content key acquisition storing process 2, and to
acquire a media key and generate a content key in the contents
playback process 2. To be more specific, it is acceptable that
Steps from S2605 through S2607 and Step S2611 shown in FIG. 26 are
not performed in the content key acquisition storing process 2.
[0438] In such a case, it would be appropriate to perform Steps
from S2605 to S2607 shown in FIG. 26 before Step S2901 shown in
FIG. 29, in the contents playback process 2.
[0439] Description has been provided in the second embodiment for
the case where when the contents playback unit 200 transmits a
playback history to a rights key acquisition source module, the
playback history is transmitted via the connection destination
module; however, it is acceptable that the contents playback unit
200 transmits the playback history to the rights key acquisition
source module.
[0440] Description has been provided in the second embodiment for
the case where when the contents playback unit 200 transmits a
playback history to a rights key acquisition source module, it is
transmitted via the connection destination module; however, it is
acceptable that the contents playback unit 200 transmits the
playback history to the rights key acquisition source module.
[0441] This completes the description of the second embodiment.
[0442] It should be noted that in the first and the second
embodiments, it has been described that when the contents playback
unit 200 acquires a rights key, the signature of the transmission
source module is used in order to check whether the transmission
source module of the rights key is a predetermined module.
[0443] It is acceptable, however, to have an arrangement wherein
after the contents playback unit 200 establishes a secure
authenticated channel (hereafter, it will be referred to as an
"SAC") with a connection destination module, data is transmitted
and received. In order to establish an SAC, SSL (Secure Socket
Layer) or TLS (Transport Layer Security) may be used, for example.
When an SAC is used, the signature by the transmission source
module is unnecessary.
[0444] It is also acceptable to have an arrangement wherein the
medium 102 stores therein a program of the license management
client operating on the terminal device 101, a playback control
program operating on the contents playback unit 200, a content
decryption program, a key acquisition control program, and a media
key generation program.
[0445] In such a case, the programs stored in the medium 102 are
read at a trigger of, for example, turning the power of the
terminal device 101 on, inserting the medium 102, or a user
operation.
[0446] In the first and the second embodiments, when a rights key
is to be acquired, a connection destination is specified based on
the corresponding rights format information and the connection
destination type contained in the playback control information 211
or the key control information 213 stored in the medium 102.
[0447] It is acceptable, however, that no corresponding rights
format information and no connection destination type is stored in
the medium 102, and that the contents playback unit 200
sequentially connects to connectable modules one by one and
performs signature verification of a reply message in each
processing. More specifically, it is acceptable to have an
arrangement wherein the contents playback unit 200 sequentially
connects to connectable modules one by one and verifies a signature
of each message. In a case where the signature verification result
is not good, the contents playback unit 200 connects to another
module, and in a case where the signature verification result is
OK, the contents playback unit 200 continues the contents playback
processing.
[0448] It should be noted that the first and second embodiments
describe that, in a case where there are two or more connection
destinations with respect to a content name at the time of
acquiring a rights key, the connection destination module is
determined based on the priority order recorded in the key control
information 213 or the playback control information 211 stored in
the medium 102; however, it is acceptable to have an arrangement
wherein the contents playback unit 200 stores therein a priority
order, and the connection destination module is determined
according to the priority order stored in the contents playback
unit 200. More specifically, when Format D1 is used, the priority
order may be set as "the license management client A 230 is
prioritized over the license server 104" or "the license management
client A 230 in Format D2 is prioritized over the license
management client A 230 in Format D1"
[0449] The priority order stored in the contents playback unit 200
may be set when the contents playback unit 200 is manufactured.
Alternatively, the priority order may be obtained from another
device via the transmission line 105, or may be obtained from the
medium 102. Further, when a priority order is set in both the
medium 102 and the contents playback unit 200, it is acceptable
that medium 102 records thereon information that indicates which
one of those two priority orders is prioritized. Furthermore, it is
acceptable to have an arrangement wherein the contents playback
unit 200 stores therein the corresponding rights format
information, the connection destination type, and the acquisition
source type, as well as the priority order.
[0450] The first and second embodiments describe that it is judged
whether or not a playback history is transmitted to an acquisition
source module based on the use condition type after the contents
are played back; however, it is acceptable to have an arrangement
wherein the contents playback information contains no use condition
type, and a playback history is always transmitted or a playback
history is never transmitted.
[0451] In addition, it is acceptable to delete the content key or
the rights key stored in the key storing unit 206 when a
predetermined condition is satisfied. To be more specific, it is
acceptable to delete the key when a predetermined length of time
has elapsed after the key is stored in the key storing unit 206, or
to delete the key when the medium 102 having the corresponding
contents stored is taken out of the terminal device 101.
[0452] It is also acceptable to have an arrangement wherein after a
rights key is transmitted, the license server 104, the license
management client A 230, and the license management client B 240
each lock the corresponding conditions of use so that they are not
usable, and a request from a different terminal device for a rights
key is rejected.
INDUSTRIAL APPLICABILITY
[0453] The apparatus and the method for playing back encrypted
contents and the recording medium storing therein data to be used
by the apparatus and the method according to the present invention
is suitable for playback of contents from a medium that stores
therein both contents to which conventional copy protection is
applied and contents to which DRM is applied and is useful in the
field of package media and contents distribution.
[0454] Although the present invention has been fully described by
way of examples with reference to the accompanying drawings, it is
to be noted that various changes and modifications will be apparent
to those skilled in the art. Therefore, unless such changes and
modifications depart from the scope of the present invention, they
should be construed as being included therein.
* * * * *