Encrypted contents recording medium and apparatus and method for reproducing encrypted contents

BACKGROUND OF THE INVENTION

1. Field of the Invention

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.

2. Description of the Related Art

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).

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.

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.

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.

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.

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.

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

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.

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

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.

In the drawings:

FIG. 1 shows the overall structure of the contents playback system of the first embodiment of the present invention;

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;

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;

FIG. 4 shows the data structure of the playback control information 211 according to the first embodiment of the present invention;

FIG. 5 shows the data structure of the key control information 213 according to the first embodiment of the present invention;

FIG. 6 shows the data structure of the media unique information 214 according to the first embodiment of the present invention;

FIG. 7 shows the table configuration of the rights storing unit 315 according to the first embodiment of the present invention;

FIG. 8 shows the table configuration of the key storing unit 305 according to the first embodiment of the present invention;

FIG. 9 shows the table configuration of the use condition storing unit 306 according to the first embodiment of the present invention;

FIG. 10 shows the configuration of communication message according to the first embodiment of the present invention;

FIG. 11 shows the configuration of rights according to the first embodiment of the present invention;

FIG. 12 shows the configuration of contents playback information according to the first embodiment of the present invention;

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;

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;

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;

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;

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;

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;

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;

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;

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;

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;

FIG. 23 shows the data structure of the playback control information 211 of the second embodiment of the present invention;

FIG. 24 shows the data structure of the key control information 213 of the second embodiment of the present invention;

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;

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;

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;

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;

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

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

The following describes in detail the first embodiment of the present invention, with reference to the drawings.

FIG. 1 is a schematic drawing of the overall structure of the contents playback system according to the first embodiment of the present invention.

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.

FIG. 2 shows the internal structure of the terminal device 101 and information recorded on the medium 102.

Firstly, the internal structure of the terminal device 101 is to be described.

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.

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.

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.

Secondly, information recorded on the medium 102 is described.

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.

Here, description is provided for a case where the medium 102 is specifically a BD medium.

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.

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.

The following describes the internal structure of the license server 104.

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.

The following describes the internal structure of the license management client A 230.

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.

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.

This completes the detailed description of the structures of the terminal device 101, the license server 104, and the license management client A 230.

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.

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

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:

“Playback Number”

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.

“Content Name”

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.

“Next-Playback Number”

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.

“Alternative Playback Number”

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

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.

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

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:

“Content Name”

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.

“Content Unique Information”

It is unique information that is designated for each content and is used for generating a key for the content.

“Key Generation Information”

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.

“Playback Possibility Information”

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.

“Copiability Information”

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.

“Corresponding Rights Format Information”

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.

“Connection Destination Type”

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.

“Public Key Certificate”

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.

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.

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”.

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”.

“Priority Order”

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.

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

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:

“Device Unique Information”

It is device unique information that is uniquely assigned to each playback device.

“Encrypted Media Key”

It is data obtained by encrypting a media key with a device unique key.

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.

This completes the description of the data structure of the data stored in the medium 102.

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.

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.

“Package Identifier”

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”.

“Content Name”

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.

“Rights Key”

It is a rights key that corresponds to a right specified in each line.

“Playback Number of Times”

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.

“Playback Expiration”

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.

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.

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:

“Package Identifier”

It is information that uniquely identifies the substance of the contents included in the medium 102.

“Content Name”

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.

“Rights Key”

It is a rights key that corresponds to a right specified in each line.

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.

“Package Identifier”

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.

“Content Name”

“Playback Number of Times”

“Playback Expiration”

This completes the description of the data structure of the data stored in the storing units.

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.

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.

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.

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.

“Conditions of Use”

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.

“Rights Key”

It is a rights key that corresponds to a right to be distributed.

This completes the description of the data structure of the rights information.

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:

“Use Condition Type”

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.

“Contents Playback Control Conditions”

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.

“Rights Key”

It is a rights key that corresponds to a key acquisition request made by the contents playback unit 200.

“Signature Data”

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.

This completes the explanation on the data structure of the contents playback information.

In the sections above, the data structure of the data dealt with in the present embodiment has been described.

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.

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.

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.

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).

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).

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).

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).

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.

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).

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.

The following describes the content key acquisition process 1 in Step S1302 in FIG. 13, with reference to the flow chart in FIG. 14.

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).

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.

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.

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.

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).

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.

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.

When having acquired a rights key, the key acquisition control unit 204 performs the subsequent processing.

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.

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.

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.

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.

This completes the description of the operation performed by the key acquisition control unit 204 to acquire a content key.

The following describes the rights key acquisition process 1 in Step S1403 in FIG. 14, with reference to the flow chart in FIG. 15.

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.

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.

The key acquisition intermediary unit 223 receives the information transmitted by the key acquisition control unit 204 in Step S1502 (FIG. 15: Step S1511).

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.

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).

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.

The key acquisition intermediary unit 223 receives a message with a signature from the connection destination module (FIG. 15: Step S1514).

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.

The key acquisition intermediary unit 223 transmits the message with the signature to the key acquisition control unit 204 (FIG. 15: Step S1515).

The key acquisition control unit 204 receives the message with the signature from the key acquisition intermediary unit 223 (FIG. 15: Step S1503).

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.

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).

This completes the description of the operation performed by the key acquisition control unit 204 to acquire a rights key.

The following describes the rights key transmission process 1 in Step S1521 in FIG. 15, with reference to the flow chart in FIG. 16.

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.

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.

The usability judging unit 313 receives the information transmitted by the key acquisition intermediary unit 223 in Step S1513 (FIG. 16: Step S1601).

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).

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.

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”.

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.

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.

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.

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.

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.

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).

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.

The key transmitting unit 314 transmits the message with the signature to the key acquisition intermediary unit 223 (FIG. 16: Step S1608).

The following describes a case where the connection destination module is the license server 104.

The usability judging unit 307 receives the information transmitted by the key acquisition intermediary unit 223 in Step S1513 (FIG. 16: Step S1601).

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).

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).

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).

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.

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).

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.

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).

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).

The key transmitting unit 304 transmits the message with the signature to the key acquisition intermediary unit 223 (FIG. 16: Step S1608).

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.

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.

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).

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.

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).

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).

This completes the description of the operation performed by the media key generating unit 205 to generate a media key.

The following describes the contents playback process 1 in Step S1304 in FIG. 13, with reference to the flow chart in FIG. 18.

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).

The decrypting unit 203 checks whether or not playback control conditions are set (FIG. 18: Step S1802).

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).

When playback control conditions are not set, the decrypting unit 203 plays back the contents without any restriction (FIG. 18: Step S1804).

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).

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).

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.

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”.

The decrypting unit 203 transmits the playback history and a history transmission instruction to the key acquisition control unit 204.

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.

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).

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).

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.

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.

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).

The key acquisition intermediary unit 223 transmits the message with the signature to the key acquisition control unit 204 (FIG. 18: Step S1815).

The key acquisition control unit 204 receives the message with the signature from the key acquisition intermediary unit 223 (FIG. 18: Step S1809).

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.

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.

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.

The following describes the use condition update process 1 in Step S1821 in FIG. 18, with reference to the flow chart in FIG. 19.

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.

The use condition updating unit 316 receives the information transmitted by the key acquisition intermediary unit 223 in Step S1813 (FIG. 19: Step S1901).

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.

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.

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).

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”.

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.

The use condition updating unit 316 transmits the message with the signature to the key acquisition intermediary unit 223 (FIG. 19: Step S1906).

The following explains the case where the connection destination module is the license server 104.

The use condition updating unit 308 receives the information transmitted by the key acquisition intermediary unit 223 in Step S1813 (FIG. 19: Step S1901).

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.

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.

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).

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).

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).

The use condition updating unit 316 transmits the message with the signature to the key acquisition intermediary unit 223 (FIG. 19: Step S1906).

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.

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.

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).

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).

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).

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.

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:

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.

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.

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.

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.

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.

This completes the description of the first embodiment of the present invention.

Second Embodiment

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.

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.

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.

FIG. 21 shows the internal structure of the terminal device 101 and information recorded on the medium 102.

Firstly, explanation is provided on the internal structure of the terminal device 101.

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.

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.

Description of information recorded on the medium 102 will be omitted, as it is the same as that in the first embodiment.

FIG. 22 shows the internal structure 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.

Description of the internal structure of the license server 104 will be omitted since it is the same as that of the first embodiment.

The following describes the internal structure of the license management client A 230.

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.

This completes the detailed description of the structures of the terminal device 101, the license server 104, and the license management client A 230.

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

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:

“Playback Number”

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.

“Content Name”

It is information that identifies each of contents arranged in the lines.

“Next-Playback Number”

It is the line number of a content to be played back next, when the playback of the content in this line is completed.

“Alternative Playback Number”

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.

“Corresponding Rights Format Information”

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.

“Connection Destination Type”

“Acquisition Source Type”

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.

“Priority Order”

The Data Structure of the Key Control Information 213

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:

“Content Name”

It is information that identifies each of contents arranged in the lines.

“Content Unique Information”

It is unique information that is designated for each content and is used for generating a key for the content.

“Key Generation Information”

It is information to specify a generation method to be used when a key for the content is generated.

“Playback Possibility Information”

It is information that indicates whether or not the playback of each content is possible or not.

“Copiability Information”

It is information that indicates whether or not each content is copiable.

“Public Key Certificate”

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.

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.

This completes the description of the data structure of the data dealt with in the second embodiment.

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.

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.

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.

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).

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.

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.

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.

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.

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.

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.

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.

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.

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).

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.

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.

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).

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.

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.

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).

When a rights key has not been acquired, the playback control unit 202 performs the rights key acquisition process 2 again.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

This completes the description of the operation performed by the playback control unit 202 to acquire and store a content key.

The following describes the rights key acquisition process 2 in Step S2603 in FIG. 26, with reference to the flow chart in FIG. 27.

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).

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.

The key acquisition intermediary unit 223 receives the information transmitted by the playback control unit 202 in Step S2702 (FIG. 27: Step S2711).

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).

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.

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.

The key acquisition intermediary unit 223 transmits the message with the signature to the playback control unit 202 (FIG. 27: Step S2715).

The playback control unit 202 receives the message with the signature from the key acquisition intermediary unit 223 (FIG. 27: Step S2703).

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.

The key acquisition control unit 204 controls the reading unit 201 so that key control information 213 is acquired from the medium 102.

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.

The key acquisition control unit 204 verifies the message with the signature, using the public key certificate (FIG. 27: Step S2704).

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.

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).

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.

This completes the description of the operation performed by the playback control unit 202 to acquire the rights key.

The following describes the rights key transmission process 2 in Step S2721 in FIG. 27, with reference to the flow chart in FIG. 28.

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.

The acquisition source judging unit 317 receives the information transmitted by the key acquisition intermediary unit 223 in Step S2713 (FIG. 28: Step S2801).

The acquisition source judging unit 317 extracts the corresponding rights format information and the acquisition source type from the received information.

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.

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.

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).

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.

The license management client A 230 receives the message with the signature (FIG. 28: Step S2812).

The license management client A 230 transmits the message with the signature to the key acquisition intermediary unit 223 (FIG. 28: Step S2813).

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.

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.

The following describes a case where the connection destination module is the license server 104.

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.

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.

The following describes the contents playback process 2 in Step S2504 in FIG. 25, with reference to the flow chart in FIG. 29.

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 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.

The decrypting unit 203 transmits the playback history and a history transmission instruction to the key acquisition control unit 204.

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.

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.

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).

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).

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).

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.

The key acquisition intermediary unit 223 transmits the message with the signature to the key acquisition control unit 204 (FIG. 29: Step S2915).

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.

This completes the description of the operation performed by the decrypting unit 203 to start the playback of the contents and complete the playback.

The following describes the use condition update process 2 in Step S2921 in FIG. 29, with reference to the flow chart in FIG. 30.

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.

The acquisition source judging unit 317 receives the information transmitted by the key acquisition intermediary unit 223 in Step S2913 (FIG. 30: Step S3001).

The acquisition source judging unit 317 extracts the corresponding rights format information and an acquisition source type from the received information.

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.

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.

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).

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.

The license management client A 230 receives the message with the signature (FIG. 30: Step S3012).

The license management client A 230 transmits the message with the signature to the key acquisition intermediary unit 223 (FIG. 30: Step S3013).

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.

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.

The following describes the case in which the connection destination module is the license server 104.

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.

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.

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.

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.

The decrypting unit 203 performs the contents playback process 2, which has been described earlier with reference to the flow chart in FIG. 29.

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.

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.

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.

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.

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.

This completes the description of the second embodiment.

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.

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.

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.

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.

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.

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.

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”

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.

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.

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.

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

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.

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.

Encrypted contents recording medium and apparatus and method for reproducing encrypted contents

Information

Publication Number

Date Filed

Date Published

Inventors

CPC

US Classifications

International Classifications

Abstract

Description

Claims