JP2002140534A - System and method for contents distribution with log management constitution - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a contents distribution system having log management constitution which securely and efficiently performs contents distribution management. SOLUTION: Contents purchase log data are gathered as the open key certificate of user equipment which purchases contents is updated. It is made essential to use a user equipment open key certificate for mutual authentication with a shop server or signature verification processing for the user equipment which is carried out as the user equipment purchases contents, and a term of validity is set in the open key certificate. To purchase contents, the user equipment sends log data to a log gathering server to update the open key certificate and then needs to have the open key certificate having an effective term of validity, so the log data from the user equipment are securely gathered on the log gathering server and a contents sales state can be managed.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

The present invention relates to a content distribution system and a content distribution method having a log management configuration. More specifically, in the content transaction between the entity that provides the content providing service and the user device that receives the content, the content has a log management configuration that enables the exact content transaction entity to be grasped reliably and efficiently. The present invention relates to a distribution system and a content distribution method.

[0002]

2. Description of the Related Art Recently, game programs, audio data,
2. Description of the Related Art Various software data such as image data and document creation programs (hereinafter, referred to as content) have been actively distributed via networks such as the Internet. In addition, merchandise sales and settlement processing via networks such as online shopping, bank settlement, and ticket sales have become active.

In data communication via such a network, the data transmitting side and the data receiving side confirm that they are legitimate data transmission / reception objects, and then transfer necessary information, that is, consider security. It is common to adopt a data transfer configuration described above. Techniques for implementing a security configuration at the time of data transfer include encryption of transferred data, signature processing on data, and the like.

[0004] Encrypted data can be returned to usable decrypted data (plaintext) by a decryption process according to a predetermined procedure. Data encryption and decryption methods using an encryption key for such information encryption processing and a decryption key for decryption processing are well known in the art.

There are various types of data encryption / decryption methods using an encryption key and a decryption key. One example is a so-called public key encryption method. In the public key cryptosystem, the keys of a sender and a receiver are different, one key is used as a public key that can be used by an unspecified user, and the other key is used as a secret key for keeping secret.
For example, the data encryption key is a public key, and the decryption key is a secret key. Alternatively, it is used in a mode in which the authenticator generation key is a secret key and the authenticator verification key is a public key.

[0006] Unlike a so-called common key encryption method that uses a common key for encryption and decryption, in a public key encryption method, a private key that needs to be kept secret is only required to be held by a specific person. Is advantageous. However, the public key cryptosystem has a slower data processing speed than the common key cryptosystem, and is often used for objects with a small amount of data, such as private key distribution and digital signatures. A representative public key cryptosystem is RSA (Rivest-Shamir-Adleman) cryptosystem. This is two very large prime numbers (eg 150 digits)
Of two large prime numbers (for example, 1
It takes advantage of the difficulty of factoring the product of (50 digits).

In the public key cryptosystem, an unspecified number of public keys can be used, and a certificate for certifying whether or not the distributed public key is valid, that is, a public key certificate is used. Many methods are used. For example, the user A generates a pair of a public key and a secret key, sends the generated public key to a certificate authority, and obtains a public key certificate from the certificate authority. User A publishes the public key certificate to the public. An unspecified user obtains a public key through a predetermined procedure from a public key certificate, encrypts a document or the like, and sends it to the user A. The user A is a system for decrypting an encrypted document or the like using a secret key. In addition, the user A signs a document or the like using a private key, and an unspecified user obtains a public key from a public key certificate through a predetermined procedure and verifies the signature. .

[0008] A public key certificate is a certificate authority or an issuing authority (CA: Certificate Authority) in a public key cryptosystem.
Or a certificate issued by IA (Issuer Authority), and when the user submits his / her own ID and public key to the certificate authority, the certificate authority adds information such as the ID and expiration date of the certificate authority. This is a certificate created by adding a signature from a certificate authority.

The public key certificate includes a certificate version number, a serial number of the certificate assigned to the certificate subscriber by the issuing authority, an algorithm and parameters used for electronic signature, a name of the certificate authority, a validity period of the certificate, Includes the name (user ID) of the relying party, the public key of the relying party, and an electronic signature.

The digital signature includes a certificate version number, a serial number of the certificate assigned by the certificate authority to the certificate subscriber, an algorithm and parameters used for the digital signature,
A hash value is generated by applying a hash function to the name of the certification authority, the expiration date of the certificate, the name of the relying party, and the entire public key of the relying party, and a hash value is generated for the hash value. This is data generated using a key.

On the other hand, when using this public key certificate, the user verifies the digital signature of the public key certificate using the public key of the certificate authority held by the user, and succeeds in verifying the digital signature. After that, the public key is extracted from the public key certificate, and the public key is used. Therefore, all users who use the public key certificate need to hold a common certificate authority public key.

[0012]

In a data transmission system based on a public key cryptosystem using a public key certificate issued by a certificate authority as described above, for example, a content distribution shop that distributes contents uses a user's public key as a key. The content to be distributed is encrypted based on the content and transmitted to the user.
Upon receiving the encrypted data from the content distribution shop, the user device decrypts the encrypted content with its own private key corresponding to its own public key.

However, in an actual content transaction, a license holder having a right to distribute the content or a content creator having a copyright of the content is
It is often different from a content distribution shop that provides services to content users,
In many cases, the content distribution shop distributes the content without confirming whether or not the user to which the shop transmits the content has the right to use the content. That is, there is a case where the content is illegally used or sold by a user who does not have the right to use the content.

[0014] In the above-mentioned transaction form, a transaction involving a corresponding content usage fee is established between a content distribution shop as a content seller and a user device as a content user. However, a license holder who has a distribution right for a content or a content creator who has a copyright on the content is not guaranteed to obtain a license fee for a content transaction between a shop and a user. At present, it is a general form of transaction that the self-declaration of the content distribution shop confirms the sales volume of the content, and the license fee based on the self-declaration is provided from the shop to the license holder or the content creator. .

In such a content transaction form,
License holders who have the right to distribute content or content creators who have the copyright of the content cannot understand the substance of the content transaction and check whether the content is properly distributed under the correct usage right There was no way to do it.

SUMMARY OF THE INVENTION The present invention has been made in view of the above-described problems in the content transaction, and the content distribution entity between the content distribution shop that provides the content distribution service and the user has the right to distribute the content. A content distribution system and a content distribution system with a log management configuration that ensures that the license holder who owns the content or the content creator who has the copyright of the content can distribute the content under the management of the legitimate content usage right It provides a method.

More specifically, a log collection server periodically collects a purchase log generated in a user device in response to a content purchase, and implements a content distribution management configuration based on the purchase log.

[0018]

SUMMARY OF THE INVENTION A first aspect of the present invention is as follows.
A shop server that receives a content purchase request from a user device and transmits sales confirmation data to the user device, and transmits content purchase request data to the shop server, and a public key certificate of the user device whose expiration date has been set. A user device that executes a content purchase request process based on a procedure using a certificate, receives the sales confirmation data, and generates and stores a purchase log based on the received sales confirmation data; and A log collection server that receives a request for updating the public key certificate based on the receipt of the purchase log, and transmits the updated public key certificate of the user device issued by the public key certificate issuing authority to the user device. There is provided a content distribution system having a log management configuration.

Further, in one embodiment of the content distribution system according to the present invention, the procedure using the public key certificate whose expiration date has been set includes the step of using the public key certificate executed between the user device and the shop server. It is characterized by the mutual authentication process used.

Further, in one embodiment of the content distribution system of the present invention, the procedure using the public key certificate whose expiration date has been set is performed by the content purchase request data transmitted from the user device to the shop server. A signature verification process executed by the shop server for an electronic signature generated by the user device, wherein the signature verification process is a process using a public key stored in a public key certificate of the user device. Features.

[0021] Further, in one embodiment of the content distribution system of the present invention, at least a part of data transmitted and received between the user device and the shop server is a mutual authentication executed between the user device and the shop server. It is characterized in that it is transmitted with an alteration check value (ICV) based on the session key Kses generated at the time, and a data alteration check process based on the ICV is executed on the receiving side.

Further, in one embodiment of the content distribution system of the present invention, the user device is executed between the user device and the log collection server with respect to a purchase log transmitted to the log collection server. A log tampering value (ICV) based on the session key Kses generated at the time of mutual authentication is added and transmitted, and a data tampering check process based on the ICV is executed on the log collection server side.

Further, in one embodiment of the content distribution system of the present invention, the user device generates and adds an electronic signature of the user device to a purchase log transmitted to the log collection server, The log collection server is configured to execute a process of verifying a digital signature of a user device.

Further, in one embodiment of the content distribution system of the present invention, the log collection server manages fee distribution information for one or more fee receiving entities of the content fee based on a purchase log received from the user device. And a response processing based on the charge distribution information in response to a sales confirmation request from a charge receiving entity.

Further, in one embodiment of the content distribution system of the present invention, the shop server manages the sales data of the contents, and sends all the sales data within a predetermined period or the fee receiving entity to the log collection server. It is characterized by having a configuration for executing a process of transmitting sales data for each.

Further, in one embodiment of the content distribution system of the present invention, the content purchase request data generated by the user device and transmitted to the shop server includes a transaction ID as a content transaction identifier, a purchase request target The shop server is configured as data having a content ID as a content identifier and including an electronic signature of a user device,
A configuration for executing a process of checking the presence or absence of data tampering by executing a signature verification of the content purchase request data and generating the sales confirmation data based on the content purchase request data and transmitting the data to the user device. It is characterized by having.

Further, a second aspect of the present invention is a log collection server that executes sales management of contents traded between a shop server and user equipment, and the log collection server executes the sales management of the user according to the purchased contents of the user equipment. A log collection server that receives a public key certificate update request from the user device on condition that a purchase log generated by the device is received, and executes content sales management based on the received purchase log.

Further, according to a third aspect of the present invention, a content purchase request data is transmitted from a user device to a shop server, and the content purchase request data is transmitted based on a procedure using a public key certificate whose expiration date is set. Executing the processing, and, in the shop server, receiving the content purchase request from the user device, transmitting the sales confirmation data to the user device; and, in the user device, receiving and receiving the sales confirmation data. Generating and storing a purchase log based on the sales confirmation data; and, in the log collection server, receiving a request for updating the public key certificate of the user device based on the receipt of the purchase log, and issuing the public key certificate. Transmitting the updated public key certificate of the user equipment issued by the authority to the user equipment. In the content distribution method with the log management structure characterized by.

Further, in one embodiment of the content distribution method according to the present invention, the procedure using the public key certificate whose expiration date has been set includes the step of using the public key certificate executed between the user device and the shop server. It is characterized by the mutual authentication process used.

[0030] Further, in one embodiment of the content distribution method of the present invention, the procedure using the public key certificate whose expiration date is set is performed by the content purchase request data transmitted from the user device to the shop server. A signature verification process executed by the shop server for an electronic signature generated by the user device, wherein the signature verification process is a process using a public key stored in a public key certificate of the user device. Features.

Further, in one embodiment of the content distribution method according to the present invention, at least a part of data transmitted and received between the user device and the shop server includes a mutual authentication executed between the user device and the shop server. It is characterized by adding a falsification check value (ICV) based on the session key Kses generated at the time and transmitting the data, and executing a data falsification check process based on the ICV on the receiving side.

Further, in one embodiment of the content distribution method of the present invention, the user device is executed between the user device and the log collection server with respect to a purchase log transmitted to the log collection server. It is characterized in that a log falsification check value (ICV) based on the session key Kses generated at the time of mutual authentication is added and transmitted, and a data falsification check process based on the ICV is executed on the log collection server side.

Further, in one embodiment of the content distribution method of the present invention, the user device generates and adds an electronic signature of the user device to a purchase log transmitted to the log collection server, The log collection server executes a process of verifying a digital signature of a user device.

Further, in one embodiment of the content distribution method of the present invention, the log collection server manages fee distribution information for one or more fee receiving entities of the content fee based on a purchase log received from the user device. And performing a response process based on the fee distribution information in response to a sales confirmation request from a fee receiving entity.

Further, in one embodiment of the content distribution method of the present invention, the shop server manages the sales data of the contents, and sends all the sales data within a predetermined period or the fee receiving entity to the log collection server. It is characterized by executing a process of transmitting each sales data.

Further, in one embodiment of the content distribution method of the present invention, the content purchase request data generated by the user device and transmitted to the shop server includes a transaction ID as a content transaction identifier, The shop server is configured as data having a content ID as a content identifier and including a digital signature of a user device. The shop server checks the presence or absence of data tampering by executing signature verification of the content purchase request data, and A process of generating the sales confirmation data based on the request data and transmitting the generated data to the user device is performed.

Further, a fourth aspect of the present invention is a program providing medium for providing a computer program for causing a computer system to execute distribution management of content, wherein the computer program is purchased by a user device. Receiving the purchase log generated by the user device according to the content, executing the verification of the purchase log, and verifying the purchase log, on condition that the validity of the reception log is confirmed. Receiving a public key certificate update request from the user device,
Acquiring the updated public key certificate and transmitting the updated public key certificate to the user device.

The program providing medium according to the fourth aspect of the present invention is, for example, a medium for providing a computer program in a computer-readable format to a general-purpose computer system capable of executing various program codes. It is. The form of the medium is not particularly limited, such as a recording medium such as a CD, an FD, and an MO, and a transmission medium such as a network.

Such a program providing medium defines a structural or functional cooperative relationship between the computer program and the providing medium for realizing a predetermined computer program function on a computer system. Things. In other words, by installing the computer program into the computer system via the providing medium, a cooperative operation is exerted on the computer system, and the same operation and effect as the other aspects of the present invention can be obtained. You can do it.

Still other objects, features and advantages of the present invention are:
It will become apparent from the following more detailed description based on the embodiments of the present invention and the accompanying drawings.

[0041]

Embodiments of the present invention will be described below in detail with reference to the drawings. The description will be made according to the following items. 1. Content distribution management by rekeying encrypted content keys 1.1. System configuration: basic content distribution model 1 1.2. Modified example of basic content distribution model 1 1.3. Basic content distribution model 2 2. 2. Content distribution model using electronic tickets 3. Content distribution management by log collection server Public key certificate or attribute certificate usage configuration that records attribute data

[0042]

Embodiments [1. Content Distribution Management by Encrypted Content Key Rekeying Process] [1.1. System Configuration: Basic Content Distribution Model 1] FIG. 1 is a diagram illustrating an outline of an embodiment of a content distribution system and a content distribution method according to the present invention.
Note that the system is a logical set configuration of a plurality of devices, and the devices of each configuration are not limited to those in the same housing.

The content distribution system shown in FIG. 1 includes a shop server (SHOP) 100 that provides a content distribution service to user devices, and a user device (DEVIC) that receives content distribution from the shop server 100.
E) 200, and further, a user device authentication server (DAS: Device Authentication Server) 300 functioning as a management server that performs legitimate content transaction management. In the configuration of FIG. 1, the shop server 100, the user device 200, and the user device authentication server 3
00 are shown one by one, but in an actual content transaction configuration, there are a plurality of components shown in FIG. 1, and information is transmitted and received along various routes for each content transaction. FIG. 1 shows a data flow in one content transaction.

(Shop Server) FIG. 2 shows the configuration of the shop server 100 of the content distribution system shown in FIG.
The shop server 100 includes a content key Kc (Content), which is encrypted content data obtained by encrypting a content to be dealt with a content key, and a content key K.
c is a user device authentication server (DAS: Device Authentic
public key of the application server): a content database 110 storing an encrypted content key KpDAS (Kc) encrypted with KpDAS. As shown in the figure, Kc (Content), which is encrypted content data, has a content ID, which is a content identifier, and has a configuration that can be identified based on the content ID.

The shop server 100 further has a purchase management database 120 for managing content transaction management data, for example, the identifier of the user device of the content seller and the content identifier in association with each other. Further, processing for extracting distribution content from the content database 110, processing for generating transaction data to be registered in the purchase management database 120 accompanying the transaction, processing for communication with the user device 200 and the user device authentication server 300, and further, each communication process And a control unit 130 for executing data encryption processing and the like at the time.

FIG. 3 shows the data structure of the purchase management database 120. The purchase management database 120 stores a shop process N as an internally generated identification number when the shop server executes a process according to a content transaction.
o. A device ID that is an identifier of the user device that has issued the content purchase request, a transaction ID as a content transaction identifier generated and issued by the user device when executing a content transaction between the user device and the shop, and an identifier of the content to be traded And a status indicating the status of the content transaction processing in the shop server. As will be described in detail later, the status is updated in accordance with the progress of a plurality of processes accompanying the content transaction.

The control means 130 also has a function as an encryption processing means and a communication processing means as shown in FIG. 2, and the control means 130 is constituted by, for example, a computer storing an encryption processing program and a communication processing program. Key data and the like used in the encryption processing executed by the encryption processing means of the control means 130 are securely stored in storage means inside the control means. Shop server 10
The data for encryption processing such as an encryption key stored in 0 is a private key of the shop server: KsSHOP, a public key certificate Cert_SHOP of the shop server, and authentication as a public key certificate issuing authority which is a public key certificate issuing organization. Station (C
A: There is a public key KpCA of Certificate Authority.

FIG. 4 shows a configuration example of the control means 130. The configuration of the control means 130 will be described. The control unit 131 is a central processing unit (CP) that executes various processing programs.
U: Central Processing Unit).
Of each component of the control means is controlled. ROM (Re
ad only Memory) 132 is an IPL (Initial Program)
This is a memory that stores programs such as Loading. R
The AM (Random Access Memory) 133 includes a control unit 131
Are used as storage areas for execution programs, such as database management programs, encryption processing programs, communication programs, and the like, and as work areas in the processing of each of these programs.

The display unit 134 has display means such as a liquid crystal display device and a CRT, and displays data when executing various programs, for example, user data of a content distribution destination, under the control of the control unit 131. The input unit 135 includes a keyboard and a pointing device such as a mouse, for example, and outputs commands and data input from these input devices to the control unit 131. HDD (Hard Disk Driv
e) 136 stores programs such as a database management program, an encryption processing program, and a communication program, and various data.

The drive 137 is, for example, an HD (Hard Dis
k), magnetic disk such as FD (Floppy Disk), CD-
It has a function of controlling access to various recording media such as an optical disk such as a ROM (Compact Disk ROM), a magneto-optical disk such as a mini disk, and a semiconductor memory such as a ROM and a flash memory. Various recording media such as magnetic disks store programs, data, and the like. The network interface 138 functions as an interface for wired or wireless communication such as the Internet or a telephone line.

The shop server 100 uses the control means 130 having the above-described configuration, for example, to perform various encryption processing and authentication associated with the content transaction with the user device 200 or the user device authentication server 300 which is the target of the content transaction. Perform processing and the like.

(User Device Authentication Server) FIG. 5 shows the configuration of the user device authentication server (DAS) 300. The user device authentication server has a license management database 320. FIG. 6 shows the data configuration of the license management database 320. The license management database stores a user device authentication server process No. as a process identifier internally generated according to a process executed by the user device authentication server (DAS) at the time of content transaction. A device ID which is an identifier of a user device which has issued a content purchase request, a transaction ID which is a content transaction identifier generated and issued by the user device when executing a content transaction, a content ID which is an identifier of a transaction target content, and a content transaction. , The shop ID that is the identifier of the shop server that executes the shop, and the shop processing No. that is the processing identifier of the shop issued by the shop. And status information indicating the status of the content transaction processing in the user device authentication server (DAS). The status will be described in detail later, but is updated as a plurality of processes progress with the content transaction

User equipment authentication server (DAS) 300
Has a control unit 330 that executes communication processing with the user device 200 and the shop server 100, and further executes data encryption processing and the like in each communication processing. Control means 330
Has a function as an encryption processing unit and a communication processing unit, similarly to the control unit of the shop server described above. The configuration is similar to the configuration described with reference to FIG. Key data and the like used in the encryption processing executed by the encryption processing means of the control means 330 are securely stored in a storage means inside the control means. The encryption processing data such as an encryption key stored in the user equipment authentication server (DAS) 300 includes a secret key of the user equipment authentication server (DAS): KsDAS, a public key certificate Cert_DAS of the user equipment authentication server (DAS), and a public key. Certificate Authority (CA: Cert) as the public key certificate issuing authority that is the key certificate issuing organization
public authority KpCA.

(User Equipment) FIG. 7 shows the configuration of the user equipment 200. The user device is, for example, a content reproduction device that executes purchase of the content and uses the purchased content, that is, reproduces and executes the content, and has a purchase management database 220. FIG. 8 shows the data configuration of the purchase management database 220. When executing a content transaction, the purchase management database stores a transaction ID as a content transaction identifier generated and issued by the user device, a content ID as an identifier of the transaction target content, and a shop ID as an identifier of a shop server executing the content transaction. , Each piece of status information indicating the status of the content transaction processing in the user device, and a device ID that is a device identifier of the user device. As will be described in detail later, the status is updated in accordance with the progress of a plurality of processes accompanying the content transaction.

The user equipment 200 is connected to the shop server 10
0, a control unit 230 for performing communication processing with the user device authentication server 300 and performing data encryption processing and the like in each communication processing. The control means 230 includes an encryption processing means, like the control means of the shop server described above.
It also has a function as communication processing means. Its configuration is shown in FIG.
Is the same as that described with reference to FIG. Key data and the like used in the encryption processing executed by the encryption processing means of the control means 230 are securely stored in a storage means inside the control means. The encryption processing data such as an encryption key stored in the user device 200 includes a secret key of the user device: KsDEV, and a public key certificate Cert_ of the user device.
DEV, CA (Certificate Authority) as a public key certificate issuing authority that is a public key certificate issuing organization
And a storage key Ksto applied as an encryption key when the content is stored in a storage device such as a hard disk of the user equipment.

[Public key certificate] The shop server (S
HOP) 100, user equipment (DEVICE) 200,
User device authentication server (DAS: Device Authenticatio)
n Server) 300 about the public key certificate held in FIG. 9
This will be described with reference to FIG.

A public key certificate is a public key possessed by a valid user in a process of transmitting / receiving encrypted data using a public key or performing mutual authentication between two parties performing data transmission / reception. This is something that has been proved by a third party, that is, a Certificate Authority (CA). FIG. 9A shows an outline of the format of the public key certificate.
Shown in

The version indicates the version of the certificate format. The serial number of the certificate is a serial number (Serial Number), which is a serial number of a public key certificate set by a public key certificate issuing authority (CA). Signature algorithm identifier, algorithm parameter (Signature algorithm Identifier algor
Ithm parameter) is a field for recording the signature algorithm of the public key certificate and its parameters. In addition,
Signature algorithms include elliptic curve cryptography and RSA
In the case where the elliptic curve encryption is applied, the parameter and the key length are recorded. When the RSA is applied, the key length is recorded. The name of the issuing authority is a field in which the name of the issuer of the public key certificate, that is, the public key certificate issuing authority (CA) is recorded in a distinguishable format (Distinguished Name). In the validity period of a certificate, a start date and time and an end date and time, which are valid dates of the certificate, are recorded. As the user name (ID) of the public key certificate, the name of an authentication target person who is a user is recorded. Specifically, for example, it is the ID of the user device, the ID of the service provider, or the like. User public key (subject Public Key Info algorithm subj
ect Public key) is a field for storing a key algorithm as the user's public key information and the key information itself. The signature given by the issuing authority is the public key certificate issuing authority (C
A) is a digital signature executed on the data of the public key certificate using the private key of A), and the user of the public key certificate is verified using the public key of the public key certificate issuing authority (CA). To check whether the public key certificate has been tampered with.

A method of generating a digital signature using the public key cryptosystem will be described with reference to FIG. The processing shown in FIG. 10 is performed by EC-DSA ((Elliptic Curve Digital Signa
3 is a flow of a process for generating digital signature data using the tureAlgorithm) and IEEE P1363 / D3). Here, Elliptic Curve Cryptography is used as public key cryptography.
(Hereinafter, referred to as ECC) will be described. Note that, in the data processing device of the present invention, in addition to elliptic curve cryptography, for example, RS
A cipher ((Rivest, Shamir, Adleman) etc. (ANSI X9.3
1)) can also be used.

The steps in FIG. 10 will be described. In step S1, p is a characteristic, a and b are coefficients of an elliptic curve (elliptic curve: 4a ³ + 27b ² ≠ 0 (mod p), G is a base point on the elliptic curve, r is the order of G, and Ks is In step S2, the hash value of the message M is calculated, and f = Hash (M).

Here, a method of obtaining a hash value using a hash function will be described. The hash function is a function that receives a message, compresses the message into data having a predetermined bit length, and outputs the data as a hash value. With a hash function, it is difficult to predict the input from the hash value (output). When one bit of the data input to the hash function changes, many bits of the hash value change, and the same hash value It has a feature that it is difficult to find different input data. As the hash function, MD4, MD5, SHA-1, or the like may be used, or DES-CBC may be used. In this case, the final output value MAC (check value: IC
V) corresponds to a hash value.

Subsequently, in step S3, a random number u (0 <u
<R) is generated, and a coordinate V (Xv, Yv) obtained by multiplying the base point by u is calculated in step S4. The addition and doubling on the elliptic curve are defined as follows.

[0063]

## EQU1 ## P = (Xa, Ya), Q = (Xb, Yb), R = (Xc, Y
c) = P + Q, when P ≠ Q (addition), Xc = λ ² −Xa−Xb Yc = λ × (Xa−Xc) −Ya λ = (Yb−Ya) / (Xb−Xa) When P = Q (doubled), Xc = λ ² −2Xa Yc = λ × (Xa−Xc) −Ya λ = (3 (Xa) ² + a) / (2Ya)

Using these, the u-times of the point G is calculated (the operation is performed as follows, although the speed is slow, but is most easily understood. G, 2 × G, 4 × G... Are calculated, and u is calculated by 2 2 ⁱ × G (where G is i
(I is a bit position counted from the LSB of u)).

In step S5, c = Xvmod r is calculated. In step S6, it is determined whether or not this value becomes 0. If not, d = [(f + cKs) in step S7.
/ U] mod r is calculated, and it is determined whether or not d is 0 in step S8. If d is not 0, c and d are output as digital signature data in step S9. Suppose r
Is 160 bits long, the digital signature data is 320 bits long.

If c is 0 in step S6, the flow returns to step S3 to generate a new random number again. Similarly, if d is 0 in step S8, the process returns to step S3 to generate a random number again.

Next, a method of verifying an electronic signature using a public key cryptosystem will be described with reference to FIG. Step S11
Where M is the message, p is the characteristic, a and b are the coefficients of the elliptic curve (elliptic curve: y ² = x ³ + ax + b), G is the base point on the elliptic curve, r is the order of G, G and Ks Let × G be a public key (0 <Ks <r). In step S12, it is verified whether the digital signature data c and d satisfy 0 <c <r and 0 <d <r. If this is satisfied, step S13
Then, the hash value of the message M is calculated, and f = Hash
(M). Next, h = 1 / d mod r is calculated in step S14, and h1 = fh mod r, h is calculated in step S15.
2 = ch mod r is calculated.

In step S16, the value of h already calculated
Using 1 and h2, the point P = (Xp, Yp) = h1 × G
+ H2 · Ks × G is calculated. Since the digital signature verifier knows the public key G and Ks × G, it can calculate a scalar multiple of a point on the elliptic curve as in step S4 of FIG. Then, in step S17, it is determined whether or not the point P is an infinite point. If not, the process proceeds to step S18 (actually, the determination of the infinite point can be made in step S16. That is, P = (X , Y) and Q = (X, -Y), λ cannot be calculated and P + Q is known to be an infinite point.) In step S18, Xp mo
dr is calculated and compared with the digital signature data c. Finally, if the values match, the process proceeds to step S19, where it is determined that the electronic signature is correct.

When it is determined that the electronic signature is correct, it is understood that the data is not falsified and that the person holding the private key corresponding to the public key has generated the electronic signature.

If the digital signature data c or d does not satisfy 0 <c <r and 0 <d <r in step S12, the flow advances to step S20. Step S17
In step S2, when the point P is a point at infinity,
Go to 0. Furthermore, in step S18, Xp
The process also proceeds to step S20 when the value of mod r does not match the digital signature data c.

If it is determined in step S20 that the digital signature is not correct, the data is
It can be seen that the person holding the private key corresponding to the public key did not generate the electronic signature.

The public key certificate is signed by the issuing authority, and the public key user can verify the falsification of the certificate by verifying the signature. Returning to FIG. 9, the description will be continued. FIG. 9B shows a public key certificate: Cert_DEV of the user device stored in the user device, which stores the user device ID and the public key KpDEV of the user device. FIG. 9C shows the public key certificate of the shop server: Cert_SHOP stored in the shop server.
Shop ID and shop server's public key KpSHOP
Is stored. FIG. 9D shows the public key certificate of the user device authentication server stored in the user device authentication server: Ce
rt_DAS, which stores the user device authentication server ID and the public key KpDAS of the user device authentication server. As described above, the user device, the shop server, and the user device authentication server each have a public key certificate.

[Content Purchasing Process] Next, returning to FIG. 1, a process in which the user equipment purchases a content from the shop server and uses it will be described. Processing proceeds in the order of numbers (1) to (20) in FIG. Details of the processing will be described in the order of each number. In this embodiment, the mutual authentication processing ((1), (7),
Although (11)) is described, it may be omitted as necessary.

(1) Mutual Authentication The user device 200 that intends to purchase content from the shop server 100 performs a mutual authentication process with the shop server. The two means for executing data transmission / reception mutually confirm whether or not the other party is a correct data communicator, and thereafter perform necessary data transfer. The process of confirming whether the other party is the correct data communicator is the mutual authentication process. One preferable data transfer method is to generate a session key during the mutual authentication process, and to perform data transmission by performing an encryption process using the generated session key as a shared key.

A mutual authentication method using a common key cryptosystem is described as follows.
This will be described with reference to FIG. In FIG. 12, DES is used as a common key encryption method, but any common key encryption method may be used.

First, B generates a 64-bit random number Rb and transmits Rb and its own ID (b) to A. Upon receiving this, A newly generates a 64-bit random number R
a, and encrypts the data in the order of Ra, Rb, and ID (b) using the key Kab in the DES CBC mode,
Return to.

[0086] Upon receiving this, B transmits the received data to the key Ka.
b. In the method of decrypting the received data, first, the ciphertext E1 is decrypted with the key Kab to obtain a random number Ra. Next, the ciphertext E2 is decrypted with the key Kab, and the result and E1
Is exclusive-ORed to obtain Rb. Finally, the ciphertext E3 is decrypted with the key Kab, and the result is exclusively ORed with E2 to obtain ID (b). Ra, Rb, I thus obtained
It verifies that Rb and ID (b) of D (b) match those transmitted by B. If this verification passes, B becomes A
Is authenticated as valid.

Next, B generates a session key (Session Key (hereinafter referred to as Kses)) to be used after authentication (a random number is used as a generation method). And Rb, Ra,
In the order of Kses, the data is encrypted using the key Kab in the DES CBC mode, and is returned to A.

[0086] Upon receiving this, A sends the received data to the key Ka.
b. The method of decoding the received data is the same as the decoding process of B, and thus the details are omitted here. It verifies that Rb and Ra among the Rb, Ra, and Kses thus obtained match those transmitted by A. If the verification passes, A authenticates B as valid. After mutually authenticating each other, the session key Kse
s is used as a common key for secret communication after authentication.

In the case where an incorrect or inconsistent data is found during the verification of the received data, the process is interrupted assuming that the mutual authentication has failed.

Next, a mutual authentication method using a 160-bit elliptic curve cryptosystem which is a public key cryptosystem will be described with reference to FIG. In FIG. 13, ECC is used as the public key cryptosystem, but any public key cryptosystem may be used as described above. The key size is 160
It does not have to be a bit. In FIG. 13, first, B is 6
A 4-bit random number Rb is generated and transmitted to A. Upon receiving this, A newly receives a 64-bit random number Ra and characteristic p
Generate a smaller random number Ak. Then, a point Av = Ak × G obtained by multiplying the base point G by Ak is obtained, and Ra, R
b, electronic signature for Av (X coordinate and Y coordinate) Sig
Is generated and returned to B together with A's public key certificate. Here, Ra and Rb are each 64 bits, and X of Av
Since the coordinate and the Y coordinate are each 160 bits, an electronic signature for a total of 448 bits is generated.

When using the public key certificate, the user verifies the electronic signature of the public key certificate by using the public key of the public key certificate issuing authority (CA) 410 held by the user. After the signature has been successfully verified, the public key is extracted from the public key certificate, and the public key is used. Therefore, all users who use the public key certificate need to hold a common public key certificate authority (CA) public key. In addition,
The method of verifying the electronic signature has been described with reference to FIG.

A public key certificate, Ra, Rb, Av, digital signature B that has received Sig, R that A has transmitted
Verify that b matches the one generated by B. As a result, if they match, the digital signature in the public key certificate of A is verified with the public key of the certificate authority, and the public key of A is extracted. Then, using the public key of the extracted A, the digital signature A.
Verify Sig. After successfully verifying the electronic signature, B authenticates A as valid.

Next, B generates a random number Bk smaller than the characteristic p. And the point B obtained by multiplying the base point G by Bk
v = Bk × G, and a digital signature B.V. for Rb, Ra, Bv (X coordinate and Y coordinate). Generate Sig and send it back to A along with B's public key certificate.

B's public key certificate, Rb, Ra, Bv, digital signature A that has received Sig, R that B has transmitted
Verify that a matches the one generated by A. As a result, if they match, the electronic signature in B's public key certificate is verified with the public key of the certificate authority, and B's public key is extracted. Then, using the public key of B, the digital signature B.
Verify Sig. After successfully verifying the electronic signature, A authenticates B as valid.

If both are successfully authenticated, B becomes Bk
XAv (Bk is a random number, but Av is a point on an elliptic curve, so a scalar multiplication of a point on the elliptic curve is required), A calculates Ak × Bv, and calculates the X coordinate of these points The lower 64 bits are used as a session key for subsequent communication (when the common key encryption is a 64-bit key length common key encryption). Of course, the session key may be generated from the Y coordinate, and may not be the lower 64 bits. In the secret communication after the mutual authentication, the transmission data may not only be encrypted with the session key but also may be digitally signed.

In the case of verifying the digital signature or the verification of the received data, if an invalid or inconsistent is found, the processing is interrupted assuming that the mutual authentication has failed.

In such a mutual authentication process, transmission data is encrypted using the generated session key, and mutual data communication is performed.

(2) Transaction ID, purchase request data generation, and (3) purchase request data transmission When mutual authentication between the shop server 100 and the user device 200 is successful, the user device 200 transmits the content purchase request data. Generate. FIG. 14A shows the structure of the purchase request data. The purchase request data includes a shop ID that is an identifier of the shop server 100 to which the content purchase is requested, a transaction ID that is generated by the cryptographic processing unit of the user device 200 based on, for example, a random number as an identifier of the content transaction, Has data of a content ID as an identifier of the content desired to be purchased, and an electronic signature of the user device is added to these data. Further, the public key certificate of the user device is attached to the purchase request data and sent to the shop server 100. If the public key certificate has already been sent to the shop in the above-mentioned mutual authentication processing or the processing before that, it is not necessary to send it again.

(4) Verification of Received Data The purchase request data shown in FIG.
Receives the data from the shop server 100 and executes a verification process of the received data. The details of the verification process will be described with reference to FIG. First, the shop server 100 verifies the public key certificate Cert_DEV of the user device in the received data (S51). As described above, this is executed as a process for verifying the signature of the issuing authority (CA) included in the public key certificate (see FIG. 11), and the public key of the issuing authority: K
This is performed by applying pCA.

If the verification is OK, that is, if it is determined that the public key certificate has not been tampered with (Yes in S52), the process proceeds to S53. If the verification is not established (No in S52), it is determined in S57 that the public key certificate has been tampered with, and the process using the public key certificate is stopped. In S53, the public key of the user device: KpDEV is extracted from the public key certificate,
In step S54, verification processing of the user device signature of the purchase request data using the public key: KpDEV (see FIG. 11) is executed. If the verification is OK, that is, if it is determined that the purchase request data has not been tampered with (Yes in S55), the process proceeds to S56, where it is determined that the received data is valid content purchase request data. When verification is not established (No in S55)
In step S57, it is determined that the purchase request data has been tampered with, and the processing for the purchase request data is stopped.

(5) Transmission of Encrypted Content and Encrypted Content Key Data 1 (Shop) When the shop server 100 completes the verification of the purchase request data and determines that the request is a legitimate content purchase request without data tampering, The server 100 transmits the encrypted content and the encrypted content key data 1 (shop) to the user device. These are all data stored in the content database 110,
An encrypted content: Kc (content) obtained by encrypting the content with the content key, and encrypted content key data: KpDAS (Kc) obtained by encrypting the content key: Kc with the public key of the user device authentication server (DAS) 300. .

Encrypted content key data 1 (shop)
14 (b) is shown. The encrypted content key data 1 (shop) is a user device ID that is an identifier of the user device 200 that is the source of the content purchase request, and purchase request data (data excluding the user device public key certificate in FIG. 14A). , The shop process No. generated by the shop server 100 in accordance with the content transaction. , Encrypted content key data: KpDAS (Kc), and an electronic signature of the shop server 100 is added to these data. Further, the public key certificate of the shop server 100 is attached to the encrypted content key data 1 (shop) and sent to the user device 200. If the shop server public key certificate has already been sent to the user device side in the above-described mutual authentication processing or processing before that, it is not always necessary to send it again.

(6) Received Data Verification The encrypted content: Kc (co
The user device 200 that has received the encrypted content key data 1 (shop) shown in FIG. 14B executes the verification processing of the encrypted content key data 1 (shop). This verification processing is the same processing as the processing flow of FIG. 15 described above. First, the user device 200 verifies the public key certificate of the shop server received from the shop server 100 by publicizing the issuing authority (CA). The process is executed using the key KpCA, and then the shop signature of the encrypted content key data 1 (shop) shown in FIG. 14B is verified using the public key KpSHOP of the shop server extracted from the public key certificate. .

(7) Mutual Authentication The user device 200 receives the encrypted content: Kc (content) and the encrypted content key data 1 (shop) from the shop server 100, and verifies the encrypted content key data 1 (shop). Is completed, the user device 200
Accesses the user device authentication server 300, and executes a mutual authentication process between the user device 200 and the user device authentication server 300. This process is performed in the same procedure as the above-described mutual authentication process between the shop server 100 and the user device 200.

(8) Transmission of Encrypted Content Key Data (User Device) and Encrypted Content Key Change Request When mutual authentication between the user device 200 and the user device authentication server 300 is established, the user device 200 First, the shop server 1
00, the encrypted content key KpDAS (K
Encrypted content key data including c) (user equipment)
Sends the encrypted content key change request.

Encrypted content key data (user equipment)
14 (c) is shown. The encrypted content key data (user device) includes the user device authentication server ID which is the identifier of the user device authentication server 300 to which the request for the encrypted content key change request is made, and the shop server 100.
(See FIG. 14B)
, Except for the shop public key certificate), and an electronic signature of the user device 200 is added to these data. Further, the public key certificate of the shop server 100 and the public key certificate of the user device 200 are attached to the encrypted content key data (user device) and sent to the user device authentication server 300. When the user device authentication server 300 already has the user device public key certificate and the shop server public key certificate, it is not necessary to send the certificate again.

(9) Verification of Received Data Encrypted content key data (user device) and encrypted content key change request from user device 200 (FIG. 1)
4 (c)), the user device authentication server 300 receives
A verification process of the encrypted content key change request is executed. This verification processing is the same processing as the processing flow of FIG. 15 described above, and the user device authentication server 300
First, verification of the public key certificate of the user device received from the user device 200 is performed using the public key KpCA of the issuing authority (CA), and then using the public key KpDEV of the user device extracted from the public key certificate. Then, the electronic signature of the purchase request data shown in FIG. 14A and the encrypted content key data (user device) shown in FIG. 14C are verified.
Further, the public key certificate of the shop server is verified using the public key KpCA of the issuing authority (CA), and then the public key KpSH of the shop server extracted from the public key certificate.
Using the OP, (5) the shop signature of the encrypted content key data 1 included in the encrypted content key data (user device) shown in FIG. 14C is verified.

(10) Encrypted content key change process, user device authentication server 300
When the verification of the encrypted content key data (user device) received from 0 and the encrypted content key change request is completed and it is determined that the request is a valid key change request, the user device authentication server 300 transmits the encrypted content key. The encrypted content key included in the data (user device), that is, the content key: Kc is transmitted to the user device authentication server (DA).
S) Data encrypted with 300 public key KpDAS: K
The content key Kc is obtained by decrypting the pDAS (Kc) with the secret key KsDAS of the user device authentication server 300, and further, the content key Kc is converted to the public key of the user device: KpDE.
V encrypted content key: KpDEV (K
c). That is, KpDAS (Kc) → Kc
→ The key change process of KpDEV (Kc) is executed.

FIG. 16 shows a flow of the encrypted content key changing process executed in the user device authentication server 300. First, the user device authentication server 300 converts the encrypted content key data (user device) received from the user device 200 into a user device authentication server (DAS).
The content key data: KpDAS (Kc) encrypted with the 300 public key KpDAS is extracted (S61). Next, the content key Kc is obtained by decrypting with the secret key KsDAS of the user device authentication server 300 (S62). Next, the content key Kc obtained by decryption is re-encrypted with the public key of the user device: KpDEV to generate an encrypted content key: KpDEV (Kc) (S63). When these processes are completed, the status of the license management database (see FIG. 6) is set to "key change completed".

(11) Mutual Authentication In the user device authentication server 300, when the above-described re-keying process of the encrypted content key is completed, the user device authentication server 300 accesses the shop server 100 and communicates with the user device authentication server 300. Shop server 10
A mutual authentication process is executed between 0. This process is performed in the same procedure as the above-described mutual authentication process between the shop server 100 and the user device 200.

(12) Transmission of Encrypted Content Data When mutual authentication between the user device authentication server 300 and the shop server 100 is established, the user device authentication server 300
Transmits the encrypted content key data (DAS) to the shop server 100.

FIG. 17D shows the structure of the encrypted content key data (DAS). The encrypted content key data (DAS) includes a shop ID, which is an identifier of the shop server 100 to which the content purchase is requested, and encrypted content key data (user device) (the shop and user device public key certificate in FIG. 14C). And the encrypted content key data: Kp generated by the user device authentication server 300 by the key change process described above.
DEV (Kc), and an electronic signature of the user device authentication server 300 is added to these data. Furthermore, the user device authentication server 300 and the public key certificate of the user device 200 are attached to the encrypted content key data (DAS) and sent to the shop server 100. If the shop server already has these public key certificates, it is not necessary to send them again.

When the user device authentication server 300 is recognized as a trusted third party, the encrypted content key data (DAS) is
As shown in FIG. 18 (d), the data configuration does not include the encrypted content key data (user device) generated by the user device as it is as shown in FIG.
User device ID, transaction ID, content I
D, shop processing NO, and content key KpDEV (Kc) data encrypted with the public key of the user device,
The user device authentication server 300 may extract the information and add a signature to the extracted information to obtain encrypted content key data (DAS). In this case, (8) it is not necessary to verify the encrypted content key data (user device), so the attached public key certificate may be only the public key certificate of the user device authentication server 300.

(13) Verification of Received Data Upon receiving the encrypted content key data (DAS) (FIG. 17D) from the user device authentication server 300, the shop server 100 verifies the encrypted content key data (DAS). Execute. This verification processing is similar to the processing flow of FIG. 15 described above, and the shop server 100 first verifies the public key certificate of the user device authentication server received from the user device authentication server 300 by the issuing authority ( CA) using the public key KpCA, and then using the public key KpDAS of the user device authentication server 300 extracted from the public key certificate, to extract the encrypted content key data (DAS) shown in FIG. Perform signature verification. Further, verification of the public key certificate of the user device is performed using the public key KpCA of the issuing authority (CA), and then using the public key KpDEV of the user device extracted from the public key certificate, as shown in FIG. (8) Verify the user device signature of the encrypted content key data (user device) included in the encrypted content key data (DAS). Furthermore, the encrypted content data (user device) may be verified using its own public key KpSHOP.

If the shop server 100 receives the simplified encrypted content key data (DAS) shown in FIG.
Performs the verification of the public key certificate of the user device authentication server using the public key KpCA of the issuing authority (CA), and then uses the public key KpDAS of the user device authentication server 300 extracted from the public key certificate. The process is only to verify the digital signature of the encrypted content key data (DAS) shown in FIG.

(14) Mutual authentication, and (15) Transmission of encrypted content key request data Next, the user device 200 transmits the encrypted content key request data to the shop server 100. In addition,
At this time, if the request is executed in a session different from the previous request, the mutual authentication is executed again, and the encrypted content key request data is transmitted from the user device 200 to the shop server 100 on condition that the mutual authentication is established. Is done.

FIG. 17E shows the structure of the encrypted content key request data. The encrypted content key request data is
A shop ID, which is an identifier of the shop server 100 from which the content purchase is requested, a transaction ID, which is an identifier of a content transaction previously generated by the user device 200, and a content ID, which is an identifier of the content the user device wants to purchase Further, the shop process No. included in the data previously generated by the shop and transmitted to the user device 200 as the encrypted content key data 1 (shop) (see FIG. 14B). And an electronic signature of the user device is added to these data. Further, the public key certificate of the user device is attached to the encrypted content key request data and sent to the shop server 100. If the public key certificate has already been stored at the shop, it is not necessary to send it again.

(16) Verification Processing, and (17) Billing Processing Upon receiving the encrypted content key request data from the user equipment, the shop server 100 executes the verification processing of the encrypted content key request data. This is the same process as described with reference to FIG. When the data verification is completed, the shop server 100 executes a billing process regarding the transaction of the content. The billing process is a process of receiving a content fee from a user's transaction account. The received content fee is distributed to various parties, such as the copyright holder of the content, the shop, and the administrator of the user device authentication server.

Since the process of re-changing the encrypted content key by the user device authentication server 300 is indispensable before the charging process, the shop server 100 performs the charging process only between the user devices. Processing cannot be performed. Also, the user device 200 cannot decrypt the encrypted content key, so that the content cannot be used. The user device authentication server records the content transaction contents that have executed all of the key exchange processes in the user device authentication server / license management database described with reference to FIG. It becomes possible to grasp. Therefore, it is impossible for the shop to independently trade contents, and illegal contents sales are prevented.

(18) Transmission of Encrypted Content Key Data 2 (Shop) When the charging process in the shop server 100 is completed,
The shop server 100 stores the encrypted content key data 2
(Shop) to the user device 200.

Encrypted content key data 2 (shop)
(F) of FIG. The encrypted content key data 2 (shop) is a user device I that is an identifier of the user device 200 that is the request source of the encrypted content key request.
D, having encrypted content key data (DAS) received from the user device authentication server 300 (data excluding the user device and the user device authentication server public key certificate in FIG. 17D). An electronic signature of the shop server 100 is added. Further, the public key certificate of the shop server 100 and the user device authentication server 300 are included in the encrypted content key data 2 (shop).
Is attached and sent to the user device 200. When the user device 200 already has the user device authentication server public key certificate and the shop server public key certificate, the user device 200 does not necessarily need to send it again.

The user device authentication server 300 is recognized as a trusted third party, and the encrypted content key data (DAS) received by the shop server 100 from the user device authentication server 300 will be described first. In the case of the simplified encrypted content key data (DAS) shown in FIG.
Is the encrypted content key data 2 shown in FIG.
(Shop) to the user device. That is, FIG.
The public key certificate of the shop server 100 and the public key certificate of the user device authentication server 300 are added to the data obtained by adding the signature of the shop server to the simplified encrypted content key data (DAS) shown in FIG. It is attached and sent to the user device 200.

(19) Verification of Received Data Upon receiving the encrypted content key data 2 (shop) from the shop server 100, the user device 200 executes a process of verifying the encrypted content key data 2 (shop). This verification processing is the same processing as the processing flow of FIG. 15 described above. First, the user device 200 verifies the public key certificate of the shop server received from the shop server 100 by publicizing the issuing authority (CA). Execute using the key KpCA, and then verify the electronic signature of the encrypted content key data 2 (shop) shown in FIG. 17F using the public key KpSHOP of the shop server 100 extracted from the public key certificate. I do. Further, the user device authentication server 3
Of the public key certificate of the public key K of the issuing authority (CA).
This is executed using pCA, and then using the public key KpDAS of the user device authentication server 300 extracted from the public key certificate, the encrypted content key data 2 shown in FIG.
(12) The signature of the encrypted content key data (DAS) included in the (shop) is verified. Furthermore, the encrypted content data (user device) may be verified using its own public key KpDEV.

(20) Storage Process The user device 200 that has verified the encrypted content key data 2 (shop) received from the shop server 100
The encrypted content key: KpDEV (Kc) encrypted with its own public key KpDEV included in the encrypted content key data 2 (shop) is decrypted using its own secret key KsDEV, and further, the storage key of the user device Encrypted and encrypted content key using Ksto: Ksto (Kc)
Is generated and stored in the storage unit of the user device 200. When using the content, the encrypted content key:
Ksto (Kc) is decrypted using the storage key Ksto, the content key Kc is extracted, and the decrypted process of the encrypted content Kc (Content) is executed using the extracted content key Kc to reproduce the content (Content). ,Execute.

Content Key K in User Equipment 200
FIG. 19 shows the acquisition and storage processing flow of c. The user device 200 firstly encrypts the encrypted content key data 2 (shop) received from the shop server 100 with its own public key KpDEV using the encrypted content key: Kp
The DEV (Kc) is extracted (S71), and the extracted encrypted content key: KpDEV (Kc) is assigned to its own secret key K.
The content key Kc is extracted by decrypting using the sDEV (S72). Further, the content key Kc is encrypted by using the storage key Ksto of the user device to generate an encrypted content key: Ksto (Kc) and stored in the storage means (internal memory) of the user device 200. (S7
3) Yes.

By the above processing, the user device can obtain the encrypted content Kc (Content) and the content key Kc of the encrypted content, and can use the content. As is clear from the above description, the key device re-processing process of the encrypted content key in the user device authentication server 300 is indispensable before the user device 200 can use the content. Therefore, the shop server 100 cannot sell the content secretly to the user device authentication server 300 to the user device 200, and cannot make the content usable in the user device. The user device authentication server records in the user device authentication server / license management database described with reference to FIG. 6 the contents of the content transactions for which all the key change processes have been executed, and manages the transactions of all shops. Identify the content transactions that have been charged, and accurately distribute the content fees received in the shop billing process to various parties, such as the copyright owner of the content, the shop, and the administrator of the user device authentication server. Becomes

(Status Transition in Each Device) The shop server 100, the user device 200, and the user authentication server (DAS) 300 shown in FIG. Determine the next process. The status is
For example, the purchase management database of the shop server shown in FIG. 3, the license management database of the user device authentication server in FIG. 6, and the purchase management database of the user device in FIG. 8 are managed for each content transaction.

First, the status transition of the shop server 100 will be described with reference to FIG. The shop server starts the process by receiving the content purchase request data from the user device 200 (corresponding to the process (3) in FIG. 1). The shop server 100 is a user device 20
Verify the received data from 0 and if the verification is successful,
If the status is set to "purchase acceptance completed" and the data verification does not determine that the request is a valid purchase request, the processing is stopped or a similar processing, here, the purchase acceptance processing is executed. After repeating the process a predetermined number of times, the process is stopped, and the status is set to “purchase reception failed”. The process proceeds to the next step only when the status is “purchase accepted”.

When the status changes to “purchase acceptance completed”, the shop server 100
By transmitting the encrypted content key data 1 (shop) to the user (corresponding to the process (5) in FIG. 1) and receiving a reception response (response) from the user device, the status is changed to “key 1 distribution completed”. And If the transmission of the key data 1 is not successful, the processing is stopped, or the same processing, here, the transmission processing of the key data 1 is repeated a predetermined number of times, and then the processing is stopped and the status is changed to “key 1”. Delivery failure ". The process proceeds to the next step only when the status is “key 1 distribution completed”.

If the status changes to “key 1 distribution completed”, the shop server 100 then sends the encrypted content key data (DAS) from the user device authentication server 300.
(Corresponding to the process (12) in FIG. 1), and executes data verification. If the verification is successful, the status is set to “key reception completed”. If the data verification does not determine that the data is valid encrypted content key data (DAS), the process is stopped. Alternatively, after repeating the key receiving process a predetermined number of times, the process is stopped, and the status is set to “key reception failed”. The process proceeds to the next step only when the status is “key reception completed”.

When the status changes to “key reception completed”, the shop server 100
, Receives the encrypted content key transmission request data (corresponding to the process (15) in FIG. 1), and executes data verification. If the verification is successful, set the status to "encrypted content key transmission request reception completed". If the data verification does not determine that the data is valid key transmission request data, stop the process. Alternatively, here, after repeating the reception processing of the encrypted content key transmission request data a predetermined number of times, the processing is stopped, and the status is set to “encryption content key transmission request reception failure”. Only when the status is “encrypted content key transmission request reception completed”, the process proceeds to the next step.

When the status changes to “encrypted content key transmission request reception completed”, the shop server 1
00 executes a billing process (corresponding to the process (17) in FIG. 1). When the charging process is completed, the status is set to "charging completed", and if the charging process is not completed, for example, if the content fee cannot be debited from the designated account of the user device, the subsequent processes are executed. Without
After the processing is stopped or a similar processing, here, the charging processing is repeated a predetermined number of times, the processing is stopped, and the status is set to “charging failed”. Status is "Billing Complete"
Only when it is, proceed to the next step.

When the status changes to “charging completed”, the shop server 100 executes a process of transmitting the encrypted content key data 2 (shop) to the user device (corresponding to the process (18) in FIG. 1). . When the encrypted content key data 2 (shop) transmission process is completed and a reception response from the user device is received, the status is changed to “key 2”.
If the distribution is set to "delivery completed" and the key data 2 (shop) transmission processing is not completed, the status is set to "key 2 distribution failure". Only when the status is "key 2 distribution completed", the next step, here, the process ends, and when the status is "key 2 distribution failure", the subsequent processes are not executed, and the process is stopped, or A similar process, here, the key data 2 (shop) transmission process is repeated a predetermined number of times. The shop server 100 executes such a state transition for each content transaction.

Next, the status transition of the user device 200 will be described with reference to FIG. User equipment 200
First, the process is started by transmitting content purchase request data to the shop server 100 (corresponding to the process (3) in FIG. 1). Upon receiving the response to the shop server 100 that the content purchase request data has been received, the user device 200 sets the status to “purchase request transmission completed”. If the user device 200 cannot receive the reception completion response from the shop server 100, Or a similar process, here, the purchase request transmission process is repeated a predetermined number of times, and then the process is stopped, and the status is set to “purchase request transmission failed”. The process proceeds to the next step only when the status is “purchase request transmission completed”.

When the status changes to “purchase request transmission completed”, the user device 200
From 00, the encrypted content key data 1 (shop) is received (corresponding to the process (5) in FIG. 1), and the received data is verified. When the verification of the encrypted content key data from the shop server 100 is successful, the status is set to “key 1 reception completed”, and when the data verification does not determine that the data is valid encrypted content key data. For example, the process is stopped, or a similar process, here, the key 1 reception process is repeated a predetermined number of times, then the process is stopped, and the status is set to “key 1 reception failed”. The process proceeds to the next step only when the status is “key 1 reception completed”.

When the status changes to “key 1 reception completed”, the user device 200 transmits the encrypted content key data (user device) to the user device authentication server 300 (the process in FIG. 8)) and a data reception response is received. If a data reception response is received, the status is set to "key transmission completed". If no data reception response is received, the process is stopped or a similar process, here, the key transmission process is repeated a predetermined number of times. After that, the process is stopped, and the status is set to “key transmission failure”. The process proceeds to the next step only when the status is “key transmission completed”.

If the status changes to “key transmission completed”, the user device 200
Transmits an encrypted content key transmission request (corresponding to the process (15) in FIG. 1), and receives a data reception response. If a data reception response is received, the status is set to “encrypted content key transmission request transmission completed”. If no data reception response is received, the process is stopped or a similar process is performed. After repeating the content key transmission request transmission process a predetermined number of times,
The process is stopped, and the status is set to “encryption content key transmission request transmission failure”. The process proceeds to the next step only when the status is “encrypted content key transmission request transmission completed”.

If the status changes to “encrypted content key transmission request transmission completed”, then the user device 200
Receives the encrypted content key data 2 (shop) from the shop server 100 (corresponding to the process (18) in FIG. 1) and performs data verification. If the data verification is successful, the status is set to “key 2 reception completed”, and if the data verification is not successful, the processing is canceled or
Alternatively, after repeating a similar process, here, the key data 2 (shop) receiving process a predetermined number of times, the process is stopped,
The status is set to “key 2 reception failure”. If the status is “key 2 reception completed”, the process ends. The user device 200 executes such a state transition for each content transaction.

Next, the status transition of the user device authentication server 300 will be described with reference to FIG. The user device authentication server 300 starts processing by receiving the encrypted content key data (user device) from the user device 200 (corresponding to the process (8) in FIG. 1). The user device authentication server 300 verifies the data received from the user device 200. If the verification is successful, the user device authentication server 300 sets the status to “key reception completed”, and the data verification does not determine that the data is valid. In such a case, the process is stopped, or a similar process, here, the process of receiving the encrypted content key data (user device) is repeated a predetermined number of times, then the process is stopped, and the status is changed to “Key reception failure”. ". The process proceeds to the next step only when the status is “key reception completed”.

When the status changes to “key reception completed”, the user device authentication server 300 executes a content key change process (corresponding to the process (10) in FIG. 1), and the key change process is completed. In this case, the status is set to "key change completed". Since it is not assumed that the key change will fail, here, there is a status transition of only “key change complete”.

When the status changes to “key change completed”, the user device authentication server 300 sends the encrypted content key data (D
AS) (corresponding to the process (12) in FIG. 1), and receives a data reception response from the shop server 100. When a data reception response is received, the status is set to “key transmission completed”, and when the data reception response is not received, the processing is stopped, or similar processing is performed.
Here, after the transmission process of the encrypted content key data (DAS) is repeated a predetermined number of times, the process is stopped, and the status is set to “key transmission failure”. If the status is “key transmission completed”, the process ends. The user device authentication server 300 executes such a state transition for each content transaction.

(Content Purchase Processing Flow) Next, data transmission / reception processing executed between the shop server 100, the user equipment 200, and the user equipment authentication server 300 in response to a content purchase request from the user equipment to the shop server will be described according to the flow. . The processing flow will be described by dividing into A, B, C, and D below.

A. Process between shop server and user device (processes (1) to (6) shown in FIG. 1) Mutual authentication between user device 200 and shop server 100
Content purchase request from the user device 200 to the shop server 100 to transmission of the key 1 (shop) from the shop server 100 to the user device 200. B. Process between the user device authentication server and the user device (processes (7) to (9) shown in FIG. 1) Mutual authentication between the user device 200 and the user device authentication server 300-transmission of encrypted content key data-user device authentication server 300 Incoming data verification in. C. Processing between the user device authentication server and the shop server (processing of (11) to (13) shown in FIG. 1) Mutual authentication between the user device authentication server 300 and the shop server 100-transmission of encrypted content key data (DAS)-shop Validation of received data at the server. D. Processing between shop server and user device (Fig. 1
(Processes of (14) to (19) shown in (1)) Mutual authentication between user device 200 and shop server 100
Transmission of encrypted content key request data from user device 200 to shop server 100 to shop server 10
From 0, transmission of the key 2 (shop) to the user device 200 to verification of received data in the user device 200.

First, A.I. The process between the shop server and the user device (the processes (1) to (6) shown in FIG. 1) will be described with reference to FIGS.

23 and 24, the left side shows the processing of the shop server, and the right side shows the processing of the user device. In addition,
In all the flows, the processing step number of the shop server is S10xx, the processing step number of the user device is S20xx, and the processing step number of the user device authentication server is S10xx.
Is shown as S30xx.

First, as shown in FIG. 23, at the start of the processing, mutual authentication is performed between the shop server and the user device (S1001, S2001). The mutual authentication process is executed as the process described with reference to FIG. 12 or FIG. Using the session key generated in the mutual authentication process, the transmission data is encrypted as necessary to execute data communication. When the mutual authentication is established, the shop server adds a new shop process number to the purchase management database (see FIG. 3) as a new process entry (S100).
3) Yes.

On the other hand, when the mutual authentication is established, the user device generates a transaction ID to be applied in this content transaction based on, for example, a random number, and adds the new transaction ID to the purchase database (see FIG. 8) as a new entry. (S2003). Further, the user device transmits the content purchase request data to the shop server (S2004), that is, FIG.
The transmission of (3) purchase request data shown in 4 (a) is executed.

The shop server receives the content purchase request data from the user device (S1004) and verifies the received data (S1005). Data validation is
This is processing according to the processing flow of FIG. 11 described above.
If it is determined by the verification of the received data that the data is legitimate data without tampering, the user
A response of K is transmitted (S1008), and the status of the purchase management database is set to "purchase accepted" (S1).
010). If the received data is verified as falsified and invalid data by the verification of the received data, a response of the reception NG is transmitted to the user equipment (S1007).
Then, the status of the purchase management database is set to "purchase reception failed" (S1009).

The user device receives the response of the reception OK from the shop server (Y in S2005 and S2006).
es) Then, the status of the purchase management database is set to “purchase request transmission completed”, and when the reception NG response from the shop server is received (No in S2005 and S2006), the status of the purchase management database is “purchase request transmission failed”. Set to.

In the shop server, the status of the purchase management database is set to “purchase accepted” (S101).
0) After that, encrypted content key data 1 (shop) (see FIG. 14B) is generated (S1011), and encrypted content encrypted with the content key: Kc for the user device: Kc (Content) Is transmitted (S1012), and the encrypted content key data 1 shown in FIG.
(Shop) is transmitted (S1013).

The user device sets the status of the purchase management database to “purchase request transmission completed” (S2007).
Thereafter, an encrypted content: Kc (Content) encrypted with the content key: Kc is received from the shop server (S2).
009), and further receives the encrypted content key data 1 (shop) (FIG. 14B) from the shop server (S2010).

The user device determines in steps S2009 and S2
A verification process (see FIG. 11) of the data received in step 010 is executed (S2021). If the verification of the received data indicates that the data is legitimate data without tampering, a response of a reception OK to the shop server is received. (S2
023), and sets the status of the purchase management database to “key 1 reception completed” (S2025). If the received data is verified to be falsified and invalid data by the verification of the received data, a response of the reception NG is transmitted to the shop server (S2024), and the status of the purchase management database is set to “key 1 reception failure”. Setting (S2026)
After that, the connection with the shop server is disconnected (S202
7).

The shop server receives the response from the user device (S1021), and if the response is OK, changes the status of the purchase management database to “key 1”.
It is set to "delivery successful" (S1024). Response is N
In the case of G, the status of the purchase management database is set to "key 1 distribution failure" (S1023), and then the connection with the user device is disconnected (S1025).

In the case where the mutual authentication has failed in steps S1002 and S2002, in the case of the setting of “purchase acceptance failure” in the status of S1009 and in the case of the setting of “purchase request transmission failure” in the status of S2008, the processing is performed. The process is stopped, the connection is terminated, and the process is terminated.

Next, B. The process between the user device authentication server and the user device (the processes (7) to (9) shown in FIG. 1) will be described according to the flow of FIG.

First, mutual authentication is performed between the user device authentication server and the user device (S3001, S20).
31). The mutual authentication process is executed as the process described with reference to FIG. 12 or FIG. Using the session key generated in the mutual authentication process, the transmission data is encrypted as necessary to execute data communication. When the mutual authentication is established, the user device authentication server adds the new user device authentication server process NO to the license management database (see FIG. 6) as a new process entry (S3003).
I do.

On the other hand, when mutual authentication is established, the user device encrypts the encrypted content key data (user device) (FIG. 14).
(See (c)) (S2033), and transmits it to the user device authentication server (S2034).

The user device authentication server receives the encrypted content key data (user device) from the user device (S
3004) and verify the received data (S3005). The data verification is processing according to the processing flow of FIG. 11 described above. If the received data is verified as valid data without tampering, a response of reception OK is transmitted to the user device (S300).
8) Then, the status of the license management database is set to “key reception completed” (S3010). If the received data is verified to be falsified and invalid data by the verification of the received data, a response of a reception NG is transmitted to the user device (S3007), and the status of the license management database is set to “key reception failure”. (S300
9) After that, the connection with the user device is cut off (S3011).

The user device receives the response of the reception OK from the user device authentication server (S2035, S203)
If Yes at 6), the status of the purchase management database is set to "key transmission completed" (S2037), and a reception NG response from the user device authentication server is received (S20).
35, No in S2036), the status of the purchase management database is set to “key transmission failure” (S2038).
After that, the connection with the user device authentication server is disconnected (S20).
39).

If the mutual authentication has failed in steps S3002 and S2032, the processing is stopped, the processing for disconnecting the connection is performed, and the processing is terminated.

Next, C.I. Processing between the user device authentication server and the shop server ((11) to (1) shown in FIG. 1)
The process 3) will be described with reference to the flow of FIG.

First, mutual authentication is performed between the user device authentication server and the shop server (S3021, S302).
1031). The mutual authentication process is executed as the process described with reference to FIG. 12 or FIG. Using the session key generated in the mutual authentication process, the transmission data is encrypted as necessary to execute data communication. When mutual authentication is established, the user device authentication server generates encrypted content key data (DAS) (see FIG. 17D) (S
3023), and transmits it to the shop server (S3024).

On the other hand, after the mutual authentication is established, the shop server receives the encrypted content key data (DAS) (see FIG. 17D) from the user device authentication server (S103).
3) Then, the received data is verified (S1034).
The data verification is processing according to the processing flow of FIG. 11 described above. If the received data is verified as valid data without tampering, a response of reception OK is transmitted to the user device authentication server (S1).
036), and sets the status of the purchase management database to “key reception completed” (S1038). If the received data is verified to be falsified and invalid data by verification of the received data, a response of the reception NG is transmitted to the user device authentication server (S1037), and the status of the purchase management database is set to “key reception failure”. (S103
9) Then, the connection with the user device authentication server is disconnected (S10).
40).

The user device authentication server receives the response of reception OK from the shop server (S3025, S3
If "Yes" at 026), the status of the license management database is set to "key transmission completed" (S3028).
When the reception NG response from the shop server is received (No in S3025, S3026), the status of the license management database is set to “key transmission failure” (S3027), and then the connection with the user device authentication server is disconnected (S3029). ).

If the mutual authentication has failed in steps S3022 and S1032, the processing is stopped, the processing for disconnecting the connection is performed, and the processing is terminated.

Next, D. Processing between the shop server and the user device (processing (14) to (19) shown in FIG. 1)
Will be described with reference to FIGS. 27 and 28.

First, at the start of processing, mutual authentication is performed between the shop server and the user device (S105).
1, S2051). The mutual authentication process is performed as shown in FIG.
3 is performed. Using the session key generated in the mutual authentication process, the transmission data is encrypted as necessary to execute data communication. When the mutual authentication is established, the user device generates encrypted content key transmission request data (see FIG. 17E) (S205).
3) and transmit it to the shop server (S2054).

The shop server receives the encrypted content key transmission request data from the user device (S1054).
Then, the received data is verified (S1055). The data verification is processing according to the processing flow of FIG. 11 described above. If the received data is verified to be valid data without tampering, a reception OK response is transmitted to the user device (S1058), and the status of the purchase management database is changed to "encrypted content key transmission request". It is set to "acceptance completed" (S1060). If the received data is verified to be falsified and invalid data as a result of the verification of the received data, a response of a reception NG is transmitted to the user device (S1057), and the status of the purchase management database is changed to "encrypted content key transmission request". It is set to "reception failure" (S1059).

The user device receives the response of reception OK from the shop server (Y in S2055 and S2056).
es), the status of the purchase management database is set to “encrypted content key transmission request transmission completed” (S2
057), and when the reception NG response from the shop server is received (No in S2055, S2056), the status of the purchase management database is set to “encryption content key transmission request transmission failure” (S2058).

The shop server sets the status of the purchase management database to “encrypted content key transmission request accepted” (S1060), and then generates encrypted content key data 2 (shop) (see FIG. 17 (f)) (FIG. 17 (f)). S10
61) Then, the encrypted content key data 2 (shop) shown in FIG. 17F is transmitted to the user device (S10).
62).

After setting the status of the purchase management database to “encrypted content key transmission request transmission completed” (S2057), the user device transmits encrypted content key data 2 (shop) from the shop server (FIG. 17 (f)). Is received (S2059).

The user device executes a verification process (see FIG. 11) of the data received in step S2059 (S207).
1) If the received data is verified by the verification of the received data as valid data without tampering, a response of reception OK is transmitted to the shop server (S2073).
Change the status of the purchase management database to "Key 2 received"
(S2075). By verifying the received data,
If the data is found to be invalid data with tampering, a response of reception NG is transmitted to the shop server (S2074), and the status of the purchase management database is set to "key 2 reception failure" (S2076). Then, the connection with the shop server is disconnected (S2077).

The shop server receives the response from the user device (S1071), and if the response is OK, changes the status of the purchase management database to “key 2”.
It is set to "delivery successful" (S1074). Response is N
In the case of G, the status of the purchase management database is set to "key 2 distribution failure" (S1073), and then the connection with the user device is disconnected (S1075).

If the mutual authentication has failed in steps S1052 and S2052, the process is stopped, the process for disconnecting the connection is performed, and the process ends.

[Modification of Basic Content Distribution Model 1]
So far, the configuration and the processing procedure of the content purchase process have been described based on the configuration of the basic content distribution model 1 shown in FIG. 1. However, the configuration in which the user device authentication server basically executes the content key changeover process The configuration is not limited to the configuration shown in FIG. 1 as long as the configuration has the following policy. Hereinafter, various modifications will be described.

The configuration shown in FIG. 29 is a configuration in which the functions of the shop server are separated, and a shop server and a distribution server are provided. The shop server 100 receives the content purchase request from the user device 200,
The distribution server 400 executes the distribution of the contents for “0”. In this example, the mutual authentication processing is omitted between the entities. However, similar to the basic content distribution model 1, the mutual authentication processing may be performed.

The shop server 100 stores the user equipment 20
0 and receives the purchase request data and verifies the data (FIG. 2).
After performing the process (3) of No. 9 to confirm the validity of the request data, the content server transmits a content distribution request to the distribution server 400 (process (4) of FIG. 29). The distribution server 400 verifies the content distribution request data from the shop server 100, and when the validity of the data is confirmed, transmits the encrypted content and the encrypted content key data (distribution server) extracted from the content database 410 ( The processing (6) in FIG. 29 is performed. The encrypted content key data (distribution server) corresponds to the encrypted content key data 1 (shop) in the above-described embodiment, and is a content key Kc encrypted with the public key KpDAS of the user device authentication server, that is, KpDAS (Kc). It is data containing.

The processing after the user device 200 receives the encrypted content and the encrypted content key data (distribution server) from the distribution server 400 is the same as that in the embodiment based on the configuration shown in FIG.

In the present configuration, the shop server 100
Receives the content request from the user device, verifies its validity, receives the renewed encrypted content key from the user device authentication server, mainly executes distribution to the user device, and executes the content itself. Do not manage or distribute Accordingly, one shop server responds to a content request from a user device with respect to a plurality of distribution servers serving as various content management entities, such as a music content distribution server that manages music data, a game content distribution server that manages game content, and the like. This is a mode suitable for a configuration in which a shop server transmits a content distribution request to a distribution server that manages requested content in response to the request. In addition, with this configuration, for example, the user device and the shop server use two-way communication, so use the Internet, but use one-way communication from the distribution server to the user device, so that high-speed satellite communication can be used. There are benefits.

FIG. 30 shows a configuration in which the functions of the shop server are separated as in FIG. 29, and a shop server and a distribution server are provided.
Receives a content purchase request from the user device 2
The distribution server 400 executes the content distribution with respect to 00. The difference from the configuration of FIG.
0, the content distribution request is not transmitted to the distribution server 400, and the user device authentication server 300 transmits the content distribution request to the distribution server 400.

[0172] The shop server 100
0, the purchase request data is received, and the data is verified (FIG. 3).
0 (3), and confirms the validity of the request data, and then transmits a content distribution request to the user device authentication server 300 (process (4) in FIG. 30). After that, the user device authentication server 300 performs data verification (process (5) in FIG. 30) to confirm the validity of the requested data, and then transmits a content distribution request to the distribution server 400 ( The processing (6) in FIG. 30 is performed. The distribution server 400 is a user device authentication server 300
When the validity of the content distribution request data is verified and the validity is confirmed, the encrypted content and the encrypted content key data (distribution server) extracted from the content database 410 are transmitted to the user device 200 (see FIG. 30). Processing (8) is performed. The encrypted content key data (distribution server) corresponds to the encrypted content key data 1 (shop) of the above-described embodiment, and is encrypted with the public key KpDAS of the user device authentication server,
That is, the data includes KpDAS (Kc).

The processing after the user device 200 receives the encrypted content and the encrypted content key data (distribution server) from the distribution server 400 is the same as that of the embodiment based on the configuration shown in FIG.

In this configuration, the user device authentication server 300 transmits the content purchase request to the shop server 100 before the key change request from the user device 200. Information can be acquired and managed. Therefore, upon receipt of the key change request from the user device 200, it is possible to perform a collation process on whether or not the user device is a registered content purchase request user device.

[1.3. Basic content distribution model 2]
Next, a basic content distribution model 2 different from the basic content distribution model 1 will be described with reference to FIG. In the basic content distribution model 2, data is not transmitted and received between the user device 200 and the user device authentication server 300. Each process (1) to (19) shown in FIG. 31 will be described focusing on differences from the basic content distribution model 1. In the present embodiment, the mutual authentication processing ((1), (7), (13)) is described in the communication between the entities, but may be omitted as necessary.

(1) Mutual Authentication The user device 200 that intends to purchase content from the shop server 100 performs a mutual authentication process with the shop server 100. The mutual authentication process is the process described with reference to FIG. 12 or FIG. In the mutual authentication process, the transmission data is encrypted as necessary using the generated session key to execute data communication.

(2) Transaction ID, purchase request data generation, and (3) purchase request data transmission When mutual authentication between the shop server 100 and the user device 200 succeeds, the user device 200 generates content purchase request data. . FIG. 32 shows the structure of purchase request data.
(G). The purchase request data includes a shop ID, which is an identifier of the shop server 100 to which the content purchase is requested, a transaction ID, which is generated by the cryptographic processing means of the user device 200 based on a random number, as an identifier of the content transaction. Each data has a content ID as an identifier of the content desired to be purchased, and an electronic signature of the user device is added to these data. Further, a public key certificate of the user device is attached to the purchase request data, and the shop server 1
Sent to 00. If the public key certificate has already been sent to the shop in the above-mentioned mutual authentication processing or the processing before that, it is not necessary to send it again.

(4) Received Data Verification The purchase request data shown in FIG.
Receives the data from the shop server 100 and executes a verification process of the received data. Details of the verification process are as described above with reference to FIG.

(5) Transmission of Encrypted Content and Purchase Acceptance Data When the shop server 100 completes the verification of the purchase request data and determines that the request is a valid content purchase request without data tampering, the shop server 100 Send the content and the purchase acceptance data to the user device. These are the encrypted content: Kc (content) obtained by encrypting the content with the content key and the data indicating only that the purchase request has been received. The content key: Kc is set to the user device authentication server (DAS) 30.
Encrypted content key data encrypted with a public key of 0: K
This data does not include pDAS (Kc).

FIG. 32 (h) shows the structure of the purchase acceptance data. The purchase acceptance data includes a user device ID, which is an identifier of the user device 200 that is the requester of the content purchase, purchase request data (data excluding the user device public key certificate in FIG. 32 (g)), and a shop associated with the content transaction. The shop processing No. generated by the server 100 And an electronic signature of the shop server 100 is added to these data. Further, the public key certificate of the shop server 100 is attached to the purchase acceptance data and sent to the user device 200. If the shop server public key certificate has already been sent to the user device side in the above-described mutual authentication processing or processing before that, it is not always necessary to send it again.

(6) Received Data Verification The shop server 100 sends the encrypted content: Kc (co
ntent) and the user device 200 that has received the purchase reception data shown in FIG. 32 (h) executes the verification processing of the purchase reception data. This verification processing is the same processing as the processing flow of FIG. 15 described above. First, the user device 200 verifies the public key certificate of the shop server received from the shop server 100 by publicizing the issuing authority (CA). The process is executed using the key KpCA, and then the shop signature of the purchase reception data shown in FIG. 32H is verified using the public key KpSHOP of the shop server extracted from the public key certificate.

(7) Mutual Authentication (8) Transmission of Encrypted Content Key Data 1 (Shop) Next, the shop server 100
00, and performs a mutual authentication process between the shop server 100 and the user device authentication server 300. When the mutual authentication is established, the shop server 100
The encrypted content key data 1 (shop) is transmitted to the user device authentication server 300.

Encrypted content key data 1 (shop)
32 (i) is shown in FIG. The encrypted content key data 1 (shop) includes the user device authentication server ID which is the identifier of the user device authentication server 300 to which the request for the encrypted content key change request is made, and the purchase request data received from the user device 200 (FIG. 32). (G) data excluding the user device public key certificate); And an electronic signature of the shop server 100 is added to these data. Further, the public key certificate of the shop server 100 and the public key certificate of the user device 200 are attached to the encrypted content key data 1 (shop) and sent to the user device authentication server 300. When the user device authentication server 300 already has the user device public key certificate and the shop server public key certificate, it is not necessary to send the certificate again.

(9) Received Data Verification The encrypted content key data 1 from the shop server 100
The user device authentication server 300 that has received (shop) (FIG. 32 (i)) executes a process of verifying the received data.
This verification processing is similar to the processing flow of FIG. 15 described above, and the user device authentication server 300 first verifies the public key certificate of the shop server received from the shop server 100 by issuing authority (CA). Of the encrypted content key data 1 (shop) shown in FIG. 32 (i) using the public key KpSHOP of the shop server extracted from the public key certificate. Execute. Further, verification of the public key certificate of the user device is executed using the public key KpCA of the issuing authority (CA), and then using the public key KpDEV of the user device extracted from the public key certificate, FIG. (3) Verify the user device signature of the purchase request data included in the encrypted content key data 1 (shop) shown in FIG.

(10) Encrypted Content Key Changeover Process In the user device authentication server 300, when the verification of the encrypted content key data 1 (shop) received from the shop server 100 is completed and it is determined that the data is valid data, The user device authentication server 300 encrypts the encrypted content key contained in the encrypted content key data 1 (shop), that is, the content key: Kc with the public key KpDAS of the user device authentication server (DAS) 300: KpDAS (Kc) is the user device authentication server 3
The content key Kc is obtained by decrypting with the secret key KsDAS 00 and obtaining the content key Kc, and further encrypting the content key Kc with the public key of the user device: KpDEV.
DEV (Kc) is generated. That is, KpDAS (K
c) A key change process of Kc → KpDEV (Kc) is executed. This process is a process according to the flow shown in FIG. 16 described above.

(11) Transmission of Encrypted Content Data Next, the user device authentication server 300 transmits the encrypted content key data (DAS) to the shop server 100.

FIG. 33 (j) shows the structure of the encrypted content key data (DAS). The encrypted content key data (DAS) includes a shop ID which is an identifier of the shop server 100 to which the content purchase is requested, an encrypted content key data 1 (shop) (the shop and user device public key certification in FIG. 32 (i)). And the encrypted content key data: Kp generated by the user device authentication server 300 by the key change process described above.
DEV (Kc), and an electronic signature of the user device authentication server 300 is added to these data. Furthermore, the user device authentication server 300 and the public key certificate of the user device 200 are attached to the encrypted content key data (DAS) and sent to the shop server 100. If the shop server already has these public key certificates, it is not necessary to send them again.

When the user device authentication server 300 is recognized as a trusted third party, the encrypted content key data (DAS) is
(8) Encrypted content key data 1 as shown in (j)
(J), the shop ID, the user device ID, the transaction ID, the content ID,
The shop process NO, the user device authentication server 300 extracts each data of the content key KpDEV (Kc) encrypted with the public key of the user device, adds a signature to them, and generates them as encrypted content key data (DAS). Is also good. The attached public key certificate is the user device authentication server 3
00 public key certificate.

(12) Verification of Received Data Upon receiving the encrypted content key data (DAS) (FIG. 33 (j)) from the user device authentication server 300, the shop server 100 verifies the encrypted content key data (DAS). Execute. This verification processing is similar to the processing flow of FIG. 15 described above, and the shop server 100 first verifies the public key certificate of the user device authentication server received from the user device authentication server 300 by the issuing authority ( CA) using the public key KpCA of FIG. 33, and then using the public key KpDAS of the user device authentication server 300 extracted from the public key certificate to obtain the electronic content of the encrypted content key data (DAS) shown in FIG. Perform signature verification. The simplified encrypted content key data (DAS) shown in FIG.
The same verification is performed when 00 is received. further,
If necessary, the encrypted content key 1 (shop 1) in the encrypted content data (DAS) in FIG. 33 (j) may be verified.

(13) Mutual authentication, and (14) Transmission of encrypted content key request data Next, the user device 200 transmits the encrypted content key request data to the shop server. At this time, if the request is executed in a session different from the previous request, mutual authentication is executed again, and the encrypted content key request data is transmitted from the user device 200 to the shop server 100 on condition that the mutual authentication is established. Sent to.

(15) Verification processing and (16) Billing processing The shop server 100 that has received the encrypted content key request data from the user equipment executes the verification processing of the encrypted content key request data. This is the same process as described with reference to FIG. When the data verification is completed, the shop server 100 executes a billing process regarding the transaction of the content. The billing process is a process of receiving a content fee from a user's transaction account. The received content fee is distributed to various parties, such as the copyright holder of the content, the shop, and the administrator of the user device authentication server.

As in the case of the basic model 1 described above, the process of re-keying the encrypted content key by the user device authentication server 300 is essential before the charging process, so that the shop server 100 The billing process cannot be executed only by processing between devices. Also, the user device 200 cannot decrypt the encrypted content key, so that the content cannot be used. The user device authentication server records the content transaction contents that have executed all of the key exchange processes in the user device authentication server / license management database described with reference to FIG. It becomes possible to grasp. Therefore, it is impossible for the shop to independently trade contents, and illegal contents sales are prevented.

(17) Transmission of Encrypted Content Key Data 2 (Shop) When the charging process in the shop server 100 is completed,
The shop server 100 stores the encrypted content key data 2
(Shop) to the user device 200.

Encrypted content key data 2 (shop)
33 (k) is shown in FIG. The encrypted content key data 2 (shop) is a user device I that is an identifier of the user device 200 that is the request source of the encrypted content key request.
D, having encrypted content key data (DAS) received from the user device authentication server 300 (data excluding the user device authentication server public key certificate in FIG. 33 (j));
An electronic signature of the shop server 100 is added to these data. Further, the public key certificate of the shop server 100 and the public key certificate of the user device authentication server 300 are attached to the encrypted content key data 2 (shop) and sent to the user device 200. Note that the user device 200 is a user device authentication server public key certificate,
If you already have a shop server public key certificate, you do not need to send it again.

Note that the user device authentication server 300 is recognized as a trusted third party, and the encrypted content key data (DAS) received by the shop server 100 from the user device authentication server 300 will be described first. In the case of the simplified encrypted content key data (DAS) shown in FIG.
Is the encrypted content key data 2 shown in FIG.
(Shop) to the user device. That is, FIG.
The public key certificate of the shop server 100 and the public key certificate of the user device authentication server 300 are added to the data obtained by adding the signature of the shop server to the simplified encrypted content key data (DAS) shown in FIG. 4 (j ′). It is attached and sent to the user device 200.

(18) Verification of Received Data Upon receiving the encrypted content key data 2 (shop) from the shop server 100, the user device 200 executes a process of verifying the encrypted content key data 2 (shop). This verification processing is the same processing as the processing flow of FIG. 15 described above. First, the user device 200 verifies the public key certificate of the shop server received from the shop server 100 by publicizing the issuing authority (CA). The process is executed using the key KpCA, and then the digital signature of the encrypted content key data 2 (shop) shown in FIG. 33 (k) is executed using the public key KpSHOP of the shop server 100 extracted from the public key certificate. I do. Further, the user device authentication server 3
Of the public key certificate of the public key K of the issuing authority (CA).
The encrypted content key data 2 shown in FIG. 33 (j) is executed using the pCA and then using the public key KpDAS of the user device authentication server 300 extracted from the public key certificate.
(11) The signature of the encrypted content key data (DAS) included in (shop) is verified. Furthermore, if necessary, the encrypted content data (DA
The encrypted content key 1 (shop 1) in S) may be verified.

(19) Storage Process The user device 200 that has verified the encrypted content key data 2 (shop) received from the shop server 100,
The encrypted content key: KpDEV (Kc) encrypted with its own public key KpDEV included in the encrypted content key data 2 (shop) is decrypted using its own secret key KsDEV, and further, the storage key of the user device Encrypted and encrypted content key using Ksto: Ksto (Kc)
Is generated and stored in the storage unit of the user device 200. When using the content, the encrypted content key:
Ksto (Kc) is decrypted using the storage key Ksto, the content key Kc is extracted, and the decrypted process of the encrypted content Kc (Content) is executed using the extracted content key Kc to reproduce the content (Content). ,Execute.

As described above, in the basic distribution model 2, the user device 200 and the user device authentication server 300
No data transmission / reception is performed between
In the case of 00, it is only necessary to perform data transmission and reception with the shop server 100, and the processing load on the user equipment is reduced.

[1.2. Modification of Basic Content Distribution Model 2] Next, a modification of the configuration of basic content distribution model 2 shown in FIG. 31 will be described. The configuration shown in FIG. 35 is a configuration in which the function of the shop server is separated and a shop server and a distribution server are provided. Shop server 10
0 receives a content purchase request from the user device 200, but the distribution server 400 executes content distribution to the user device 200. In this configuration, mutual authentication is not performed between the entities that execute data transmission and reception,
Each entity performs only signature verification of the received data. However, similarly to the basic content distribution model 2, a configuration may be adopted in which mutual authentication processing is performed between entities.

[0200] The shop server 100 is
0, the purchase request data is received, and the data is verified (FIG. 3).
After performing the process (3) of No. 5 to confirm the validity of the request data, the content server transmits a content distribution request to the distribution server 400 (the process (4) of FIG. 35). The distribution server 400 verifies the content distribution request data from the shop server 100, and when the validity of the data is confirmed, transmits the encrypted content retrieved from the content database 410 (process (6) in FIG. 35).

The user device 200 receives the encrypted content from the distribution server 400, and after verifying the data, transmits the encrypted content reception data to the distribution server 400 (process (8) in FIG. 35). After verifying the received data, distribution server 400 transmits the encrypted content key data (distribution server) and the encrypted content key change request to user device authentication server 300 (processing (1 in FIG. 35).
0)).

The processing after the user device authentication server 300 receives the encrypted content key data (distribution server) and the encrypted content key change request from the distribution server 400, except that the mutual authentication processing is omitted. This is the same as the embodiment based on the configuration shown in FIG.

In this configuration, the user device transmits a content purchase request to the shop server without performing mutual authentication, and receives the encrypted content from the distribution server. The shop server 100 receives a content request from a user device and verifies its validity only based on signature verification. Further, it receives the renewed encrypted content key from the user device authentication server and executes its validity by signature verification. Distribution server 400
Executes the signature verification on the data received from the shop server, confirms the validity of the data, and distributes the content.

The shop server 100 does not manage and distribute the content itself. Accordingly, one shop server responds to a content request from a user device with respect to a plurality of distribution servers serving as various content management entities, such as a music content distribution server that manages music data, a game content distribution server that manages game content, and the like. This is a mode suitable for a configuration in which a shop server transmits a content distribution request to a distribution server that manages requested content in response to the request. In addition, with this configuration, for example, the user device and the shop server use two-way communication, so use the Internet, but use one-way communication from the distribution server to the user device, so that high-speed satellite communication can be used. There are benefits.

In the present embodiment, since the mutual authentication is omitted and the process of confirming the validity of the data is performed only by verifying the signature, the efficiency of the process is realized.

FIG. 36 is similar to FIG. 35 except that the functions of the shop server are separated, a shop server and a distribution server are provided, and mutual authentication is omitted.
Receives the content purchase request from the user device 200 and performs signature verification. The distribution server 400 executes the content distribution to the user device 200. 35 is different from the configuration in FIG. 35 in that the content distribution request is not transmitted from the shop server 100 to the distribution server 400, and the user device authentication server 300 transmits the content distribution request to the distribution server 400. It is.

The shop server 100 stores the user equipment 20
0, the purchase request data is received, and the data is verified (FIG. 3).
After confirming the validity of the request data by performing the process (3) of step 6, transmission of the encrypted content key data 1 (shop) to the user device authentication server 300 is executed (step (4) of FIG. 36). )). After that, the user device authentication server 300 performs data verification (process (5) in FIG. 36) to confirm the validity of the requested data, and then transmits a content distribution request to the distribution server 400 ( The processing (6) in FIG. 36 is performed. The distribution server 400 verifies the content distribution request data from the user device authentication server 300, and when the data is verified, the user device 200
Then, the encrypted content extracted from the content database 410 is transmitted (process (8) in FIG. 36). The subsequent processing is the same as the processing based on the configuration shown in FIG.

In this configuration, the user device authentication server 300 sends the content purchase request to the shop server 100 before the key renewal request from the distribution server 400, and the user device authentication Information can be acquired and managed. Therefore, upon receiving the key change request from the distribution server 400, it is possible to perform a collation process on whether or not the user device is a registered content purchase request user device. Further, if the DAS is regarded as a reliable organization, the distribution server does not need to verify the transmission data of the shop server, and the processing efficiency can be improved.

As described above, according to the content distribution configuration of the present invention, after the encrypted content Kc (Content) is obtained, the user device must wait for the user device authentication server before the content can be used. A process for re-keying the encrypted content key is essential. Therefore, the shop server sells the content to the user device without notifying the user device authentication server, and cannot make the content available in the user device. The user device authentication server records the contents of the content transactions for which all the key exchange processes have been executed in the user device authentication server / license management database (see FIG. 6), and can manage the transactions of all shops. Identify the content transactions that have been charged, and accurately distribute the content fees received in the shop billing process to various parties, such as the copyright owner of the content, the shop, and the administrator of the user device authentication server. As a result, a configuration for eliminating unauthorized use of the content is realized.

[2. Content Distribution Model Using Electronic Ticket] Next, based on the use (purchase) of the content by the user, profit distribution information to various stakeholders such as the copyright owner, creator, license holder, shop, etc. of the content is described. A configuration for issuing an electronic ticket and executing a profit distribution process based on the issued electronic ticket will be described.

FIG. 37 shows a system configuration for executing profit distribution based on an electronic ticket. The content distribution system in FIG. 37 receives a purchase request for content purchased by a user device, and issues an electronic ticket describing profit distribution information of a usage fee associated with the content purchase, and issues a ticket issue server (TIS: Ticket Issuer Server) 610; A user device (DEV) 620 that is a content purchaser, a user device authentication server (DAS) 630 that functions as a management server that performs a key change process for legitimate content transaction management, and a content that distributes content Provider (CP)
Distribution server (CP: Content Provider) 640, and a ticket exchange server (TES: Ticket Exc) that performs exchange processing such as transfer of usage fee based on the electronic ticket.
Hange Server) 650 is a main component.

(Ticket Issuing Server) Ticket Issuing Server (TIS) 610 of the content distribution system of FIG.
38 is shown in FIG. The ticket issuing server 610,
It receives a purchase request from the user device 620 and issues an electronic ticket describing profit distribution information corresponding to the content to be traded for which the purchase request was made.

[0213] The ticket issuing server (TIS) 610
Issue ticket management data for content transactions,
For example, it has a ticket issuance management database 612 that associates and manages identifiers of user devices of content sellers, content identifiers, content charges, and the like. further,
Control means for executing content purchase request verification from the user device 620, control of a ticket issuance management database, billing processing for the user device based on the ticket, communication processing with the user device, and data encryption processing in each communication process. 613.

FIG. 39 shows the data structure of the ticket issuance management database 612. The ticket issuance management database 612 stores a ticket issuance process number as an internally generated identification number when the ticket issuance server executes the ticket issuance process in response to the content transaction. Device I which is the identifier of the user device that issued the content purchase request
D, when executing a transaction between the user device and the ticket issuing server, a transaction ID generated and issued by the user device as a content transaction identifier, a content ID which is an identifier of the transaction target content, an electronic ticket issued by the ticket issuing server 610 An entity that obtains a fee based on, for example, a ticket use destination ID as an identifier of a copyright holder, a license holder, an administrator, a content sales stakeholder, etc., an amount as a content use charge distribution amount corresponding to each ticket use ID, Expiration date of cashing process based on ticket, ticket issuing server 61
0 has status information indicating the status of ticket issuance and management processing. As will be described in detail later, the status is updated in accordance with the progress of a plurality of processes accompanying the content transaction.

Control means 61 of ticket issuing server 610
38 also has a function as an encryption processing means and a communication processing means as shown in FIG. 38, and the control means 613 is constituted by a computer storing, for example, an encryption processing program and a communication processing program. Key data and the like used in the encryption processing executed by the encryption processing means of the control means 613 are securely stored in a storage means inside the control means. The data for encryption processing such as an encryption key stored in the ticket issuing server 610 includes the ticket issuing server 6.
10 secret keys: KsTIS, ticket issuing server 610
Public key certificate Cert_TIS, a certification authority (CA:
Certificate Authority) public key KpCA.

The configuration of the control means 613 is the same as the configuration of the control means described above with reference to FIG. 4, that is, a central processing unit (CPU),
OM (Read only Memory), RAM (Random Access Me)
mory), a display unit, an input unit, a storage unit, a communication interface, and the like.

(User equipment) User equipment (DEV) 62
0 is the user equipment in the configuration of FIG.
It has a configuration similar to the configuration described above. The encryption processing data such as an encryption key stored in the user device 620 includes a secret key of the user device: KsDEV, and a public key certificate Cer of the user device.
t_DEV, Certificate Authority (CA: Certificate Authority) as a public key certificate issuing authority that is a public key certificate issuing organization
There is a public key KpCA of y) and a storage key Ksto applied as an encryption key when the content is stored in a storage device such as a hard disk of the user equipment.

The purchase management database of the user device 620 in the system for executing the ticket management configuration of FIG. 37 has a data configuration having a ticket management function.
FIG. 40 shows the data configuration of the purchase management database. The purchase management database stores the transaction I generated and issued by the user device when executing the content transaction.
D, a content ID that is an identifier of the content to be dealt, a ticket issuer ID that is an identifier of a ticket issuer that issues a ticket in accordance with the content transaction, and a ticket issuing process N set by the ticket issuing server 610.
o. , A ticket transmission destination ID as an identifier of a transmission destination entity to which the ticket is transmitted, and status information indicating a status of a content transaction process in the user device. As will be described in detail later, the status is updated in accordance with the progress of a plurality of processes accompanying the content transaction.

(User Device Authentication Server) The user device authentication server (DAS) 630 has the same configuration as the user device authentication server in the configuration of FIG. 1, that is, the configuration of FIG. The encryption processing data such as an encryption key stored in the user device authentication server 630 includes a secret key of the user device authentication server (DAS): KsDAS, a public key certificate Cert_DAS of the user device authentication server (DAS), and a public key certificate. Public key KpC of a Certificate Authority (CA) as a public key certificate issuing authority
There is A.

The license management database of the user device authentication server 630 in the system for executing the ticket management configuration of FIG. 37 has a data configuration having a ticket management function. FIG. 41 shows the data configuration of the license management database. The license management database
User device authentication server (DA
S) The user device authentication server process No. as a process identifier generated internally according to the process executed by 630 , A device ID which is an identifier of a user device which has issued a content purchase request, a transaction ID which is generated and issued by the user device when executing a content transaction, a content ID which is an identifier of a content to be traded, and a ticket is issued in accordance with the content transaction. Issuer ID which is the identifier of the issuer to be issued, the ticket issue server 61
0 is set. Further, it has status information indicating the status of the content transaction processing in the user equipment authentication server (DAS). As will be described in detail later, the status is updated in accordance with the progress of a plurality of processes accompanying the content transaction.

(Distribution Server) FIG. 42 shows the configuration of the distribution server 640 of the content distribution system of FIG. The distribution server 640 is, for example, a content provider (CP)
Kc (C), which is encrypted content data obtained by encrypting the content to be dealt with a content key.
and a content database 644 storing an encrypted content key KpDAS (Kc) obtained by encrypting a content key Kc with a public key: KpDAS of a user device authentication server (DAS). As shown in the drawing, a content ID, which is a content identifier, is added to Kc (Content), which is encrypted content data.
It has a configuration that can be identified based on the content ID.

The distribution server 640 further includes a distribution management database 642 for managing content distribution management data.
Having. The distribution management database 642 has a data configuration having a ticket management function. FIG. 43 shows the data configuration of the purchase management database. Delivery management database 6
Reference numeral 42 denotes a delivery server process No. set by the delivery server 640 when executing the content delivery process. , A content ID that is an identifier of the content to be traded, a user device ID as an identifier of a content to be distributed, a ticket issuer ID that is an identifier of a ticket issuer that issues a ticket in accordance with the content transaction, and a ticket issuance set by the ticket issuer Processing No. Further, it has status information indicating the status of the content transaction processing in the distribution server. The status will be described in detail later, but is updated as a plurality of processes progress with the content transaction

Further, distribution server 640 performs processing for extracting distribution contents from content database 644,
It has a control unit 643 for executing a process of generating transaction data to be registered in the distribution management database 642 accompanying the transaction, a process of communicating with the user device 620, etc., and a data encryption process in each communication process. The control means 643 also has functions as an encryption processing means and a communication processing means as shown in FIG. 42, and the control means 643 is constituted by, for example, a computer storing an encryption processing program and a communication processing program. The key data and the like used in the encryption processing executed by the encryption processing means of the control means 643 are securely stored in the storage means inside the control means. The encryption processing data such as an encryption key stored in the distribution server 640 includes a secret key of the distribution server 640: KsCP, and a public key certificate Cer of the distribution server 640.
t_CP, Certificate Authority (CA: Certificate Authority) as a public key certificate issuing authority that is a public key certificate issuing organization
There is a public key KpCA of y).

The configuration of the control means 643 is the same as the configuration of the control means described above with reference to FIG. 4, that is, a central processing unit (CPU),
OM (Read only Memory), RAM (Random Access Me)
mory), a display unit, an input unit, a storage unit, a communication interface, and the like.

(Ticket Exchange Server) Ticket exchange server (TES) 650 of the content distribution system shown in FIG.
44 is shown in FIG. The ticket exchange server 650
An electronic ticket is received from various entities, and after verifying the received data, a cashing process based on the ticket, for example, an account transfer process, or a change process of the balance of electronic money is performed.
0 can be set as a server in the bank that manages the bank account of each entity.

[0226] The ticket exchange server 650 has a ticket exchange management database 652 that manages management data for exchange processing based on issued tickets accompanying content transactions. Further, it has a control unit 653 that executes verification of a received ticket from each entity, control of a ticket exchange management database, communication processing with each entity, and data encryption processing in each communication processing.

FIG. 45 shows the data structure of the ticket exchange management database 652. The ticket exchange management database 652 stores the ticket exchange server processing No. as an internally generated identification number when the ticket exchange server executes the ticket exchange processing according to the received ticket. , A redemption requester ID as a requesting entity identifier that has issued a redemption request based on a ticket, a ticket issuer ID that is an identifier of a ticket issuer that issues a ticket in accordance with a content transaction, and a ticket issuance set by the ticket issuing server 610 Processing No. , A monetary amount based on the ticket, a user device ID as an identifier of the user device that purchases the content, a transaction ID generated and issued by the user device when executing the content transaction, and a status of the cashing process in the ticket redemption server. Status information that indicates As will be described in detail later, the status is updated in accordance with the progress of a plurality of processes accompanying the content transaction.

Further, the ticket exchange server 650 executes data generation and update processing of the ticket exchange management database 652, verification processing of received tickets, communication processing with various entities, and data encryption processing in each communication processing. Control means 653 is provided. Control means 65
Reference numeral 3 also has a function as an encryption processing means and a communication processing means as shown in FIG. 44, and the control means 653 is constituted by, for example, a computer storing an encryption processing program and a communication processing program. Key data and the like used in the encryption processing executed by the encryption processing means of the control means 653 are securely stored in a storage means inside the control means. The data for encryption processing such as an encryption key stored in the ticket exchange server 650 includes the ticket exchange server 6.
50 secret keys: KsTES, ticket exchange server 650
Public key certificate Cert_TES, a certification authority (CA:
Certificate Authority) public key KpCA.

The configuration of the control means 653 is the same as the configuration of the control means described above with reference to FIG. 4, that is, a central processing unit (CPU),
OM (Read only Memory), RAM (Random Access Me)
mory), a display unit, an input unit, a storage unit, a communication interface, and the like.

[Content Purchasing Process] Next, returning to FIG. 37, the user device issues a content purchase request to the ticket issuing server and stores the content in a usable state in the user device. The processing until is distributed (cashed) will be described. The processing proceeds in the order of numbers (1) to (32) in FIG.
Details of the processing will be described in the order of each number.

(1) Mutual Authentication The user device 620 who intends to purchase contents performs a mutual authentication process with the ticket issuing server 610. The mutual authentication process is the process described with reference to FIG. 12 or FIG. In the mutual authentication process, the transmission data is encrypted as necessary using the generated session key to execute data communication.

(2) Transaction ID, purchase request data generation, and (3) purchase request data transmission If mutual authentication between the ticket issuing server 610 and the user device 620 succeeds, the user device 620 generates content purchase request data. I do. The structure of the purchase request data is shown in FIG. The purchase request data is a device I that is an identifier of the user device 620 that is the source of the content purchase request.
D, as transaction identifiers, a transaction ID generated by the cryptographic processing means of the user equipment 620 based on, for example, a random number, and a content ID as an identifier of the content that the user equipment wants to purchase. An electronic signature of the user device is added to the data. Further, a public key certificate of the user device is attached to the purchase request data as needed for signature verification.

(4) Verification of Received Data The purchase request data shown in FIG.
The ticket issuing server 610 received from the server executes verification processing of the received data. The details of the verification process are described earlier in FIG.
As described above.

(5) Charging Process (6) Electronic Ticket Issuance (7) Electronic Ticket Transmission The ticket issuing server 610 next executes a charging process and an electronic ticket issuance process relating to content transactions. These processes are executed, for example, as processes for issuing an electronic ticket within a user's transaction amount limit set based on a pre-registered user account or an electronic money account. The issued electronic ticket is transmitted to the user device 620.

FIG. 47 shows a configuration example of the electronic ticket. FIG. 47A shows a data configuration in the case where the charge distribution destination (charge reception entity) based on the electronic ticket is single, and the ticket issuer ID, the ticket issue processing No. , A ticket usage ID indicating a charge distribution destination (entity) based on an electronic ticket, an amount indicating a charge distributed based on the electronic ticket, and an expiration date of the electronic ticket, that is, a fee receiving entity based on the ticket (charge settlement). It includes a period during which the process can be executed, and purchase request data (see FIG. 46 (m)) transmitted from the user device to the ticket issuing server. Note that data such as a ticket issue date may be added. An electronic signature of the ticket issuing server 610 is added to these data. Furthermore, a public key certificate of the ticket issuing server is attached to the electronic ticket as needed for signature verification.

FIG. 47B shows a data structure in the case where there are a plurality of charge distribution destinations (entities) based on the electronic ticket. A plurality (1 to n) of ticket use destination IDs are stored, and the respective ticket use destinations are stored. For each ID, an amount indicating a fee allocated based on the electronic ticket is stored from 1 to n. An entity that receives a fee based on a ticket receives an amount corresponding to its own ID.

In the processing example of FIG. 37, the ticket issuing server 610 issues an electronic ticket for the content provider (CP) managing the distribution server and an electronic ticket for the user device authentication server (DAS). These ticket issuance destinations differ for each content, and may include the creator of the content. The ticket issuing server
It has a table in which the ticket issuer and the distribution amount are determined based on the content ID, and obtains the ticket issuer and the distribution amount data from the table based on the content ID included in the content purchase request from the user device, and obtains the ticket. Generate and issue

(8) Received Data Verification The user device 620 that has received the ticket from the ticket issuing server 610 executes a ticket verification process. This verification processing is the same as the processing flow of FIG. 15 described above, and the user device 620 first verifies the public key certificate of the ticket issuing server with the public key K of the issuing authority (CA).
This is executed using pCA, and then the signature verification of the ticket is executed using the public key KpTIS of the ticket issuing server extracted from the public key certificate.

(9) Mutual Authentication (10) Transmission of Electronic Ticket (for CP) Next, the user device 620 accesses the distribution server 640 and executes a mutual authentication process. When mutual authentication is established,
The user device 620 transmits an electronic ticket (for CP) for the distribution server to the distribution server 640.

(11) Received Data Verification (12) Transmission of Encrypted Content and Encrypted Content Key The distribution server 640 has completed verification of the electronic ticket (for CP) and determines that the electronic ticket is valid without data tampering. Then, the distribution server 640 transmits the encrypted content and the encrypted content key to the user device. These are an encrypted content: Kc (content) obtained by encrypting the content with the content key, and an encrypted content key data: KpD obtained by encrypting the content key: Kc with the public key of the user equipment authentication server (DAS) 630.
It is data including AS (Kc).

(13) Received Data Verification (14) Mutual Authentication (15) Transmission of Electronic Ticket (for DAS) and Key Change Request The user device 620 that has received the encrypted content and the encrypted content key from the distribution server 640, Execute the verification process. After data verification, the user device 620
Accesses the user device authentication server 630 and executes a mutual authentication process. When the mutual authentication is established, the user device 620 transmits an electronic ticket (DAS) for the user device authentication server and a key change request to the user device authentication server 630. The key change request is the content key Kc encrypted with the public key of the user device authentication server previously received from the distribution server 640. The encrypted content key KpDAS (Kc) is used as the public key Kp of the user device.
DEV-encrypted content key, ie KpDEV
(Kc), which is the same as the changeover process described with reference to FIG.

(16) Received Data Verification (17) Encrypted Content Key Replacement Process, User Device Authentication Server 630 that Receives Electronic Ticket (for DAS) and Encrypted Content Key KpDAS (Kc) Replacement Request from User Device 620 Performs verification processing of the electronic ticket (for DAS) and the encrypted content key change request. When the verification is completed and it is determined that the electronic ticket is a valid electronic ticket without falsification of data and is a valid key change request, the user device authentication server 630 sets the content key: Kc to the user device authentication server (DAS) 630.
Data encrypted with public key KpDAS: KpDAS
(Kc) is the secret key KsD of the user device authentication server 630.
The content key Kc is obtained by decrypting with the AS, and the content key Kc is encrypted with the public key of the user device: KpDEV to generate an encrypted content key: KpDEV (Kc). That is, KpDAS (Kc) → Kc → KpDE
The key change process of V (Kc) is executed. This process
This is the same as the processing described with reference to FIG.

(18) Transmit encrypted content key (19) Verify received data (20) Save processing The user device authentication server 630 transmits the encrypted content key KpDEV (Kc) generated by key change to the user device 620. . Upon receiving the encrypted content key KpDEV (Kc) from the user device authentication server 630, the user device 620 executes a received data verification process. After verification, the user device 620 sets the encrypted content key KpD
The EV (Kc) is decrypted using its own secret key KsDEV, and further encrypted using the storage key Ksto of the user device to generate an encrypted content key: Ksto (Kc). Store in storage means. When using the content, the encrypted content key: Ksto
(Kc) is decrypted using the storage key Ksto, the content key Kc is extracted, and the decrypted process of the encrypted content Kc (Content) is executed using the extracted content key Kc to reproduce the content (Content). Execute.

(21) Mutual Authentication (22) Transmission of Electronic Ticket (for CP) After distributing the encrypted content to the user device 620, the distribution server 640 accesses the ticket exchange server 650 and executes a mutual authentication process. When mutual authentication is established, distribution server 640 transmits an electronic ticket (for CP) for the distribution server to ticket exchange server 650.

(23) Received Data Verification and Cashing Process In the ticket cashing server 650, the electronic ticket (C
When the verification of the P (for P) is completed and the electronic ticket is determined to be a valid electronic ticket without data tampering, the ticket exchange server 650
Executes a cashing process based on the received electronic ticket (for CP). In the cashing process, the amount set in the electronic ticket (for the CP) is stored in a management account of a content provider (CP) that manages a distribution server registered in advance, or an electronic money account, for example. It is performed as a process of transferring from. Alternatively, it may be performed as a process of transferring the amount set in the ticket from the ticket issuing server management account, which has already been received by the ticket issuing server as a prepaid deposit from the user, to the content provider (CP) management account. Note that the ticket exchange server 650 verifies the expiration date stored in the ticket, and executes a fee settlement process based on the ticket on condition that it is confirmed that the expiration date has been reached.

(24) Report on Cashing Processing Report In the ticket cashing server 650, the electronic ticket (C
When the cashing based on (for P) ends, the ticket cashing server 650 transmits a report indicating that the cashing process has been completed to the distribution server 640.

FIG. 46 (n) shows an example of the structure of the cashing report.
Shown in The cashing process report includes a ticket cashing process ID which is an identifier of each ticket cashing process, a cashing requester ID as a requesting entity identifier which has issued a cashing request based on the ticket, a cashing amount based on the ticket, and a ticket in accordance with the content transaction. Ticket issuer ID, which is the identifier of the issued ticket issuer, ticket issuing server 61
0 is set. And the data such as the date on which the ticket redemption process has been completed in the ticket redemption server 650, and the electronic signature of the ticket redemption server 650 is added to these data. Further, a public key certificate of the ticket exchange server is attached to the exchange processing report as needed for signature verification.

(25) Received Data Verification The distribution server 640 that has received the cashing processing report from the ticket cashing server 650 executes the cashing processing report verification processing. If the report is found to be valid by the data verification, it is confirmed that the distribution of the fee for the content transaction to the content provider which is the managing entity of the distribution server is completed.

(26) Mutual Authentication (27) Transmission of Electronic Ticket (for DAS) (28) Received Data Verification and Cash Processing (29) Cash Processing Report Report (30) Received Data Verification User Device Authentication Server 630 and Ticket Exchange Server 65
Even between 0 and 0, processes similar to the processes (21) to (25) between the distribution server 640 and the ticket exchange server 650 are executed based on the electronic ticket (for DAS).

(31) Mutual Authentication (32) Cash Processing Report Report (33) Received Data Verification In addition, when the ticket cashing server 650 executes a cashing process based on a ticket received from each entity, the ticket issuing server 610 After the mutual authentication, the same cashing report as sent to each entity (FIG. 46)
(See (n)) to the ticket issuing server 610.
The ticket issuing server 610 is used for the ticket exchange server 65.
Verification of the realization processing report received from 0 is executed to confirm that the realization processing for the issued ticket has been completed.

(Status Transition in Each Device) FIG. 37
Each of the entities such as the ticket issuing server 610 shown in (1) determines the next process in a series of processes related to the content transaction according to the status indicating the process status. The status is managed for each content transaction in, for example, the ticket issuance management database shown in FIG. 39 and the purchase management database of the user device shown in FIG.

First, the status transition of the ticket issuing server 610 will be described with reference to FIG. The ticket issuing server 610 receives the content purchase request data from the user device 620 (corresponding to the process (3) in FIG. 37).
Then, the processing is started. Ticket issuing server 61
0 indicates that the received data from the user device 620 is verified, if the verification is successful, the status is set to “purchase acceptance completed”, and if the data verification does not determine that the request is a valid purchase request, etc. In this case, the process is stopped, or the same process, here, the purchase reception process is repeated a predetermined number of times, then the process is stopped, and the status is set to “purchase reception failed”. The process proceeds to the next step only when the status is “purchase accepted”.

When the status changes to “purchase acceptance completed”, the ticket issuing server
20 is transmitted to the electronic ticket 20 (process (7) in FIG. 37).
) And a response from the user device (response)
, The status is set to “ticket distribution completed”. If a reception response (response) is not received, the process is stopped, or the same process, in this case, after the electronic ticket transmission process is repeated a predetermined number of times, the process is stopped, and the status is changed to “Ticket distribution failure”. "
And The process proceeds to the next step only when the status is “ticket distribution completed”.

When the status changes to “ticket distribution completed”, the ticket issuing server 610 receives the cashing processing report from the ticket cashing server and verifies the report (processing (32), (33) in FIG. 37). Corresponding). If the verification is successful, the status is set to "completion of cash processing report reception" and the processing ends. If the report is not determined to be a valid report by report verification, etc., the processing is stopped, or the same processing, here, report reception and verification processing is repeated a predetermined number of times, and then the processing is stopped. , The status is “failure to receive cash report”. The ticket issuing server 610,
Such a state transition is executed for each content transaction.

Next, the status transition of the user device authentication server 630 will be described with reference to FIG. The user device authentication server 630 starts the process by receiving the encrypted content key KpDAS (Kc) from the user device 620 (corresponding to the process (15) in FIG. 37). The user device authentication server 630 verifies the received data including the electronic ticket (DAS) from the user device 620, and if the verification is successful, sets the status to “key reception completed” and verifies the data with valid data by data verification. If it is not determined that there is, for example, the processing is stopped, or the same processing, here, the reception processing of the encrypted content key data (user equipment) is repeated a predetermined number of times, and then the processing is stopped. , The status is “key reception failure”. The process proceeds to the next step only when the status is “key reception completed”.

When the status changes to “key reception completed”, the user device authentication server 630 executes a content key change process (corresponding to the process (17) in FIG. 37), and the key change process succeeds. In this case, the status is set to "key change completed". Since it is not assumed that the key change will fail, here, there is a status transition of only “key change complete”.

When the status changes to “key change completed”, the user device authentication server 630 then transmits the encrypted content key data (DA) to the user device 620.
S) (corresponding to the process (18) in FIG. 37), and receives a data reception response from the user device 620. If a data reception response is received, the status is "Key transmission completed"
If the data reception response is not received, the processing is stopped, or the same processing, here, the transmission processing of the encrypted content key data (DAS) is repeated a predetermined number of times, The processing is stopped, and the status is set to “key transmission failure”.

When the status changes to “key transmission completed”, the user device authentication server 630 transmits an electronic ticket (for DAS) to the ticket exchange server 650 (corresponding to the process (27) in FIG. 37). ), And receives a data reception response from the ticket exchange server 650. When a data reception response is received, the status is set to “ticket cashing request transmission completed”, and when the data reception response is not received, the processing is stopped, or a similar processing, here, After repeating the ticket exchange request transmission process a predetermined number of times, the process is stopped, and the status is set to "ticket exchange request failure".

When the status transits to “ticket redemption request transmission completed”, next, the user device authentication server 630
Receives the realization processing report from the ticket realization server 650, and executes the report verification processing (processing (2 in FIG. 37).
9) and (30)). If the verification is successful, the status is set to "completion of cash processing report reception" and the processing ends. If the report is not determined to be a valid report by report verification, etc., the processing is stopped, or the same processing, here, report reception and verification processing is repeated a predetermined number of times, and then the processing is stopped. , The status is “failure to receive cash report”. The user device authentication server 630 performs such a state transition for each content transaction.

Next, status transition of distribution server 640 will be described with reference to FIG. Distribution server 640
Is started by receiving an electronic ticket (for CP) from the user device 620 (corresponding to the process (10) in FIG. 37). The distribution server 640 verifies the data received from the user device 620. If the verification is successful, the distribution server 640 sets the status to “electronic ticket reception completed”, and the data verification does not determine that the data is valid. In such cases, stop the processing or perform the same processing,
Here, after the ticket receiving process is repeated a predetermined number of times, the process is stopped, and the status is set to “electronic ticket reception failed”. The process proceeds to the next step only when the status is “electronic ticket reception completed”.

When the status changes to “electronic ticket reception completed”, the distribution server 640 then sends the user device 6
The encrypted content and the encrypted content key data KpDAS (Kc) are transmitted to 20 (process (1) in FIG. 37).
2)), and receives a data reception response from the user equipment 620. If a data reception response is received, the status is set to “delivery completed”. If no data reception response is received, the processing is stopped, or the same processing, in this case, the encrypted content After repeating the transmission process of the encrypted content key data KpDAS (Kc) a predetermined number of times, the process is stopped, and the status is set to “distribution failure”.

When the status changes to “delivery completed”,
Next, the distribution server 640 sets the ticket exchange server 650
, An electronic ticket (for CP) is transmitted (corresponding to the process (22) in FIG. 37), and a data reception response from the ticket exchange server 650 is received. If a data reception response is received, the status is changed to "ticket cashing request transmission completed"
If the data reception response is not received, etc., the processing is stopped, or the same processing, here, the processing for transmitting the ticket redemption request is repeated a predetermined number of times, and then the processing is stopped. The status is set to “failure of ticket exchange request”.

When the status changes to “ticket cashing request transmission completed”, the distribution server 640 receives the cashing processing report from the ticket cashing server 650,
Report verification processing (processing (24) and (25) in FIG. 37)
(Corresponding to). If the verification is successful, the status is set to "completion of cash processing report reception" and the processing ends. If the report verification does not determine that the report is valid, stop the processing,
Alternatively, after repeating a similar process, here, the report receiving and verifying process a predetermined number of times, the process is stopped, and the status is set to “failure to receive a cash report”. Distribution server 640
Executes such a state transition for each content transaction.

Next, the status transition of the user device 620 will be described with reference to FIG. User equipment 620
First, the process is started by transmitting purchase request data to the ticket issuing server 610 (corresponding to the process (3) in FIG. 37). When the user device 620 receives the response of the purchase request data reception completion to the ticket issuing server 610, the user device 620 sets the status to “purchase request transmission completed”, and when the reception completion response from the ticket issuing server 610 cannot be received, After the process is stopped or a similar process, here, the purchase request transmission process is repeated a predetermined number of times, the process is stopped, and the status is set to “purchase request transmission failed”. The process proceeds to the next step only when the status is “purchase request transmission completed”.

When the status changes to “purchase request transmission completed”, the user device 620 receives the electronic ticket from the ticket issuing server 610 (corresponding to the processes (7) and (8) in FIG. 37), and Verify received data. If the ticket from the ticket issuing server 610 has been successfully verified, the status is set to “electronic ticket reception completed”, and if the data verification does not determine that the ticket is valid, the processing is stopped. Alternatively, after repeating the same process, here, the ticket receiving process a predetermined number of times, the process is stopped, and the status is set to “electronic ticket reception failed”. The process proceeds to the next step only when the status is “electronic ticket reception completed”.

When the status changes to “electronic ticket reception completed”, the user device 620 transmits an electronic ticket to the distribution server 640 (corresponding to the process (10) in FIG. 37) and receives data. Receive the response. If a data reception response is received, the status is set to “electronic ticket transmission completed”. If a data reception response is not received, the process is stopped or a similar process, here, the ticket transmission process is performed a predetermined number of times. After the repetition, the process is stopped, and the status is set to “electronic ticket transmission failure”. The process proceeds to the next step only when the status is “electronic ticket transmission completed”.

When the status transits to “electronic ticket transmission completed”, next, the user device 620
40, the encrypted content and the encrypted content key K
pDAS (Kc) is received, and data verification (corresponding to processes (12) and (13) in FIG. 37) is executed. If the data verification is successful, the status is set to “key 1 reception completed”, and if the data verification is not successful, the processing is stopped or the same processing is performed. After the process is repeated a predetermined number of times, the process is stopped and the status is set to "key 1 reception failure".

When the status changes to “key 1 reception completed”, the user device 620 transmits an electronic ticket (for DAS) and an encrypted content key KpDAS (Kc) to the user device authentication server 630 (FIG. 37 processes (1
5)) and a data reception response is received. If a data reception response is received, the status is set to “key change request transmission completed”, and if a data reception response is not received, the process is stopped or a similar process, in this case, an electronic ticket (DAS ) And the transmission process of the encrypted content key KpDAS (Kc) are repeated a predetermined number of times, and then the process is stopped, and the status is set to “key change request transmission failure”. The process proceeds to the next step only when the status is “key change request transmission completed”.

When the status is "transmission of key change request completed"
Then, the user device 620 sends the encrypted content key KpDEV from the user device authentication server 630.
(Kc) and receives data verification (processing (1) in FIG. 37).
8) and (19)). If the data verification is successful, set the status to “Key 2 reception completed”
The process ends. If the data verification is not successful, for example, the process is stopped, or a similar process, here, the key data receiving process is repeated a predetermined number of times, then the process is stopped, and the status is changed to “Key 2 reception failed. ".

Next, the status transition of the ticket exchange server 650 will be described with reference to FIG. The ticket redemption server 650 starts processing by receiving an electronic ticket from an entity having distribution right by electronic ticket (corresponding to the processing (22) and (27) in FIG. 37). The ticket redemption server 650 verifies the received ticket. If the verification is successful, the status is set to “electronic ticket reception completed”. If the data verification does not determine that the data is valid, for example, , The process is stopped, or a similar process, here, the ticket receiving process is repeated a predetermined number of times, then the process is stopped, and the status is set to “electronic ticket reception failed”. The process proceeds to the next step only when the status is “electronic ticket reception completed”.

When the status transits to “electronic ticket reception completed”, next, the ticket cashing server 650 executes a cashing process based on the electronic ticket. The cashing process is performed by storing an electronic ticket (CP) in a profit distribution entity registered in advance, for example, a management account of a content provider (CP) that manages a distribution server, or an electronic money account.
Process for transferring the amount set for the user device from the account of the management user of the user device, or from the content of the content provider (C) from the ticket issuing server management account already received by the ticket issuing server as a prepayment deposit from the user.
This is performed as a process of transferring the amount set in the ticket to the management account of P). When the cashing process is completed, the status is set to “completion of the cashing process”. When the cashing process cannot be executed, the process is stopped and the status is set to “failure of the cashing process”.

When the status changes to “completion of cash processing”, the ticket cash server 650 transmits a cash processing report to the entity that transmitted the ticket (processing (24), (29) in FIG. 37). ), And receives a data reception response from each entity. If a data reception response has been received, the status is set to “finalization report transmission completed”, and the process ends. In the case where the data reception response is not received, for example, the processing is stopped, or the same processing, here, the transmission processing of the cashing report is repeated a predetermined number of times, and then the processing is stopped, and the status is changed to "Cashing report". Transmission failure ". The ticket exchange server 650 executes such a state transition for each content transaction.

FIG. 53 shows a specific example of a structure for performing a content charge settlement process by distributing a ticket issued by a ticket issuer. User equipment 802
When there is a content purchase request to the ticket issuer 801, the ticket issuer executes a billing process and an electronic ticket issuance process regarding the transaction of the content. These processes include, for example, a user account registered in advance,
Alternatively, the process is executed as a process of issuing an electronic ticket within a transaction amount limit of a user set based on an electronic money account or the like. In the example shown in FIG. 53, the ticket issuer issues an electronic ticket for 1,000 yen as a content purchase price to the user device.

In the example of FIG. 53, the content fee is 1000
As shown in the upper part of the figure, the distribution of the yen is as follows. The shop as the ticket issuer is 300 yen as the shop profit as the sales commission, and the license holder (user device authentication server) 803 as the system operator of the content distribution is as the license fee. It is assumed that the setting is to receive 100 yen and the content creator (distribution server) receives 600 yen as the content fee.

The ticket issuer 801 that has received the purchase request from the user device obtains the setting information of the distribution ratio of the content fee from the content ID, and if there are a plurality of fee distribution destinations, issues each electronic ticket. FIG.
In the example, a license fee for the license holder 803 and an electronic ticket in which a distribution fee of 100 yen are set, and a content fee for the content creator and a ticket of 600 yen are distributed to the user device 802. A signature of the ticket issuer is generated for the electronic ticket to be distributed.

[0276] The user device 802 is the license holder 8
03, each electronic ticket is transmitted to each content creator 804. The license holder 803 and the content creator 804 verify the received electronic ticket, confirm that the ticket is valid, transmit the ticket to the bank (ticket redemption server) 805, and verify the signature in the realization server. Execute, confirm that it is a valid ticket, and redeem each allocation fee (ex. Transfer processing)
Perform The signature verification of the ticket executed in the bank (ticket cashing server) is verification of the signature of the ticket issuer generated for the electronic ticket. Also,
It also verifies the user device signature of the purchase request data included in the ticket.

Further, the content creator and the license holder, which are the transmitting entities of the ticket, generate signatures for the transmission data including the electronic ticket, and the bank (ticket redemption server) executes the signature verification for these signatures. It may be.

In the configuration of FIG. 53, the ticket issuer (shop) 801 itself also transmits its own electronic ticket for a part of the content fee of 300 yen to the bank (ticket cashing server) 80.
5, and the cash is sent to the cashier.

[0279] By performing the cashing process of each of the electronic tickets, the distribution of the content fee is surely executed. The content creator 804 sends the electronic ticket to the user device 802.
After receiving and verifying the encrypted content, the encrypted content encrypted with the content key Kc and the encrypted content key KpDAS (Kc) obtained by encrypting the content key Kc with the public key KpDAS of the license holder (user device authentication server) are obtained. Transmit to the user device 802.

[0280] The user device 802 is the content creator 8
04, the encrypted content key KpDAS (K
c) is transmitted to the license holder 803 together with the electronic ticket (DAS). After verifying the electronic ticket, the license holder issues an encrypted content key KpDAS (K
Execute the key change process of c) and obtain the public key K of the user device.
The content key is encrypted with pDEV, and KpDEV (K
c) is generated and transmitted to the user equipment 802. The user device 802 transmits the KpDEV (Kc) to its own secret key KsD.
The content key Kc can be obtained by decrypting with the EV.
When the content key is stored in the device, the content key is encrypted using its own storage key Ksto and stored.

As described above, the ticket issued by the ticket issuer is received, and the distribution server (ex. Content creator) transmits the encrypted content and the encrypted content key to the user device on condition that the ticket is valid. Send, while the license holder (user authentication device)
However, in the same manner, the electronic ticket is received, the encrypted content key is changed on condition that the ticket is valid, and the content is distributed to the user device. Is executed, and the content can be used in the user device.

[3. Content distribution management by log collection server] Next, the fact that the user device purchased the content is accumulated as a log in the user device, and the log collection is performed by the system operator, so that the distribution entity of the content can be accurately grasped. A description will be given of a content distribution system that is enabled.

FIG. 54 shows a system configuration of a content distribution mode having a log collection system. The content distribution system shown in FIG. 54 includes a shop server (SHOP) 901 for providing a content distribution service to user equipment,
A user device (DEVICE) 902 that receives the content distribution from the shop server 901 and a log collection server 903 that functions as a log management server for valid content transaction management are used as main components, and the content as a content provider is provided. A provider 905,
For the content provided by the content provider 905, various information such as content usage restriction information is generated as a header, and the authoring server 904 provides the information to the shop server. Further, a public key certificate (Cert_xxx) is provided for each entity. Issuing certificate authority (C
A: Certificate Authority).

In the configuration of FIG. 54, the content provider 905 and the authoring server 904 are an example of an entity configuration for providing the content to be distributed to the shop server 901, and are not limited to the configuration of FIG. Distribution contents are provided to the shop server in various modes. For example, the content may be provided directly from the content provider to the shop server, or the content may be provided to the shop server via a plurality of service providers from the author who is the holder of the content.

The configuration example shown in FIG. 54 shows a content provider 905 as a typical example of an entity having a right to acquire a part of content sales in order to facilitate understanding of the description of the present invention. . In the configuration example of FIG. 54, the content provider 905 can reliably acquire its own distribution profit by confirming the content sales data managed based on the logs collected by the log collection server 903. When there is an entity having another profit distribution right, the entity is added to the configuration of FIG. 54, and it is possible to confirm its own distribution profit based on the log collected by the log collection server 903.

In the configuration of FIG. 54, the shop server 9
Reference numeral 01 denotes a configuration similar to that described in the other configurations of FIG. 1 and includes a control unit capable of performing encryption processing and communication processing, executes status management associated with content transaction processing, and executes a transaction processing sequence in each device. Execute. In addition, the content provider 905 and the authoring server 904 also have a control unit capable of performing encryption processing and communication processing, execute status management associated with content transaction processing,
Execute a transaction processing sequence in each device.

(User Equipment) The user equipment 902 has the same configuration as that described with reference to FIG. 7, and has a control unit 230 (see FIG. 7) capable of performing encryption processing and communication processing. However, in the present embodiment, the control unit 230 generates log data for each content purchase process, and stores the generated log data in the purchase management database 220.

FIG. 55 shows a configuration example of log data generated and stored in the user device 902. In FIG. 55,
Two examples of log data are shown. (A) Configuration example 1
Content I, which is an identifier of the content acquired by the user device 902 through a transaction with the shop server 901
D, a user equipment ID (ID_
DEV), a shop ID (ID_SHOP), which is the identifier of the shop that performed the transaction, and date information indicating the date and time of the transaction, and a signature (Sig. DEV) of the user device for these data is generated. The log collection server performs a process of verifying the electronic signature of the purchase log received from the user device. (B) Configuration example 2 is a configuration in which a signature (Sig. DEV) of the user device is generated for the sales confirmation data and the date and time of receipt of the content. The shop server 901 stores the sales confirmation data in the user device 9.
02 is data indicating that the content generated based on the content purchase request from 02 has been sold. The sales confirmation data will be further described later.

At the time of content purchase processing, the user device 902 generates, for example, log data shown in FIG. 55 and stores it in the user device. The stored log data is transmitted to the log collection server 903. The user device transmits the log data accumulated during the process of updating its own public key certificate to the log collection server 903 during execution of the update process. These processing sequences will be described later in detail using a flow.

(Log collection server) Log collection server 903
Has the configuration shown in FIG. The log collection server has a collection log management database 9031. The collection log management database 9031 is a database that stores log data (see FIG. 55) received from various user devices.

The log collection server 903 is connected to the user device 90
2. It has control means 9032 for executing communication processing with the shop server 901 and the like, and data encryption processing in each communication processing. The control unit 9032 includes an encryption processing unit, like the control unit such as the shop server described above.
It also has a function as communication processing means. Its configuration is shown in FIG.
Is the same as that described with reference to FIG. Control means 9032
The key data and the like used in the encryption processing executed by the encryption processing means are securely stored in the storage means inside the control means. As the data for encryption processing such as an encryption key stored in the log collection server 903, the secret key of the log collection server 903: KsLOG, the log collection server 903
Public key certificate Cert_LOG, and a certificate authority (CA: CA:
Certificate Authority) public key KpCA.

The log collection server 903 is connected to the user device 90
In response to receipt of the log data from No. 2, a public key certificate issuance procedure is executed. Specifically, the user device 9
02, the public key for update is received, the received public key is transferred to the certificate authority 906, a request is issued for the public key certificate of the user device, and the public key certificate issued by the certificate authority 906 is received. And transmits it to the user device 902. This series of processing will be described later in detail using a flow.

(Content Purchasing Process) As shown in the upper part of FIG. Content purchase processing B. Log transmission, public key certificate update processing Content sales preparation processing D. Sales processing is classified into four processings. Hereinafter, each of these processes will be described using a flow.

(A. Content Purchase Process) The content purchase process will be described with reference to the flow charts of FIGS. 57 and 58, the user equipment is on the left side,
The right side shows the processing of the shop server. First, FIG.
As shown in FIG. 7, at the start of the process, mutual authentication is performed between the user device and the shop server (S1501, S1501).
S1601).

The mutual authentication process is executed as a process based on the public key system described with reference to FIG. This mutual authentication is performed using a public key certificate whose expiration date is issued by a certification authority (CA) 906. It is required as a condition to be satisfied. As will be described later, the update processing of the public key certificate is performed by the log collection server 9.
It is executed on condition that a log is transmitted to the server 03.

The session key (Kses) generated in the mutual authentication process may be used to encrypt data to be transmitted as necessary to execute data communication, or to generate an alteration check value (ICV: Integrity Check Value) using Kses. Used for processing. The generation of the ICV will be described later.

[0297] When the mutual authentication is established, the user equipment sets the transaction I to be applied in the content transaction.
D is generated based on, for example, a random number, and purchase request data is generated (S1502). FIG. 59A shows a format example of the purchase request data.

The purchase request data includes the above-mentioned transaction ID (TID_DEV), a content ID as a content identifier, and a user device I as an identifier of a user device.
D (ID_DEV), display price which is the content price,
Further, a signature (Sig. Dev) of the user device for the data including the purchase request date and time is generated.

Further, the user device generates a falsification check value (ICV1) of the purchase request data and transmits it to the shop server (S1503). Falsification check value (IC
V) is calculated by using a hash function for the data to be tampered with, and ICV = hash (Kicv, C
1, C2,...). Kicv is ICV
It is a generated key. C1 and C2 are information of the data to be tampered with and checked, and the message authentication code (MAC: Message authentication C) of the important information of the data to be tampered with is checked.
ode) is used.

FIG. 60 shows an example of MAC value generation using the DES encryption processing configuration. As shown in the configuration of FIG. 60, the target message is divided into 8-byte units (hereinafter, the divided messages are referred to as M1, M2,..., MN).
First, the initial value (Initial Value (hereinafter referred to as IV))
And M1 are XORed (the result is I1).
Next, I1 is entered into the DES encryption unit, and is encrypted using a key (hereinafter, referred to as K1) (output is referred to as E1). Subsequently, E1 and M2 are XORed, the output I2 is input to the DES encryption unit, and is encrypted using the key K1 (output E2). Hereinafter, this is repeated, and encryption processing is performed on all messages. The last EN that appears is the message authentication code (MAC).
e)). Note that partial data constituting data to be verified can be used as the message.

The falsification check value (ICV) of the check target data is configured as a MAC value generated using the ICV generation key Kicv. For example, comparing the ICV generated at the time of data generation by the data transmission side with the ICV generated at the data reception side based on the received data, and ensuring that the same ICV is obtained, it is determined that the data has not been tampered with. Guaranteed, if the ICV is different,
It is determined that there has been tampering.

Here, a session key: Kses generated at the time of mutual authentication is used as an ICV generation key. The user device applies the session key: Kses to the falsification check value (ICV) of the purchase request data (see FIG. 59A).
1) is generated, and the purchase request data + ICV1 is transmitted to the shop server.

The shop server verifies ICV1, that is, generates a falsification check value ICV1 ′ by applying a session key: Kses based on the received data, and determines whether or not the received ICV1 = ICV1 ′ is satisfied. I do.
If it is established, it is determined that there is no tampering. Further, the shop server verifies the signature of the purchase request data (S1603).
Perform The signature verification is performed using the public key of the user device. The public key is the public key certificate Cert_D of the user device.
It must be a public key certificate that is extracted from the EV and that has not expired. The expired public key certificate is not used for signature verification in the shop server and becomes a purchase request NG. If both the ICV check and the signature verification are OK, the shop server generates sales confirmation data (S1604).

The sales confirmation data is, for example, as shown in FIG.
It has the data configuration shown in The transaction ID (TID_SHOP) generated by the shop server, the shop ID (ID_SHOP) as the shop identifier, the sales date and time, the operator fee information for the content sales, and the operator are, for example, the management entity (SH) of the content sales system. : System holder). In FIG. 54, the entity manages the log collection server 903.

[0305] Furthermore, CP (content provider) sales distribution information, which is information indicating distribution of content providers to sales of content. Further, it includes purchase request data (see FIG. 59 (A)), and a shop signature (Sig.SHOP) is generated for these data.

The sales confirmation data format shown in FIG. 59 (B) records only the distribution information of the two entities of the sales of the content: the operator (SH: system holder) and the content provider (CP). But,
In addition, if there are distribution destination entities for the content sales, the distribution information of those entities is also stored.

Both ICV check and signature verification are OK
When the sales confirmation data is generated (S1604),
The shop server generates a falsification check value (ICV2) using the session key Kses, adds the falsification check value (ICV2) to the purchase OK data including the message consent to purchase, and transmits the data to the user device (S
1605). If either the ICV check or the signature verification is NG, the shop server generates a falsification check value (ICV2) using the session key Kses and adds the falsification check value (ICV2) to the purchase NG data including the message rejecting the purchase, and transmits the data to the user device ( S1606).

Further, when the shop server transmits the purchase OK data to the user device, the shop server transmits the sales confirmation data (see FIG. 59 (B)) and the header (various content-related information including content usage information and the like). The data and the content for which the tampering check value (ICV3) has been generated using the session key Kses are transmitted to the user equipment (S160
7) Yes.

The user equipment receives the content and the purchase request response data (OK or NG) + ICV2 (S
1504), the ICV2 is verified, and a purchase request response is confirmed (S1505). If the ICV2 determines that the data has not been tampered with and the purchase has been accepted (OK), the sales confirmation data (see FIG. 59B) and a header (various content-related information including content usage information) + ICV3 Is received (S1506), ICV3 is verified, and the signature of the sales confirmation data is verified.
If the content is OK,
V4 is generated and transmitted to the shop server.

[0310] If the determination in step S1507 is No, in step S1509, the content reception N
An ICV4 is generated in response to G and transmitted to the shop server.

The shop server receives the content reception OK or NG + ICV4 ((S1608), and
The verification of No. 4 is performed (S1611), and if the response from the user device is that the reception of the content is OK, the content is charged to the user (S1613). This billing process is a process of receiving a content fee from a user's transaction account or a credit card designated account, for example, as in the previous embodiment. When the charging process is completed, the ICV 5 is generated in the charging end message and transmitted to the user device (S1614). Step S161
If either 1 or the determination in S1612 is No, in step S1615, an ICV5 is generated as a charging incomplete message and transmitted to the user equipment.

Billing end (or not completed) message + IC
Upon receiving the V5, the user equipment performs verification of the ICV5, determines whether or not the charging has been completed successfully, and when confirming that the charging has been completed, generates a purchase log (see FIG. 55) and stores the purchased log in the memory of the own device. After saving the content, use the content. If the determination in step S1512 or S1513 is No, a process of deleting the header and the content received from the shop server in step S1514 is performed.

Next, a key update process and a log transmission process performed between the user device and the log collection server will be described with reference to FIGS. 61 and 62. 61 and 62 show the processing of the user device on the left side and the processing of the log collection server on the right side.
This process is executed when the user device purchasing the content from the shop server updates the public key certificate of the user device stored in the user device. An expiration date is set in the public key certificate of the user device, and it is necessary to execute the update process at regular intervals. The processing will be described from FIG. 61.

First, the user device and the log collection server execute mutual authentication (S1521, S1721) to generate a session key. The user equipment fetches the purchase log stored in the memory in the user equipment device on condition that the authentication is established, and sends the session log Kse to the purchase log.
s to generate a tampering check value (ICV1) and purchase log +
The ICV1 is transmitted to the log collection server (S1522).

The log collection server receives the purchase log + ICV1 (S1722) and executes verification of ICV1 (S17).
23) If the verification is OK, the log is stored in the database (S1724). The log collection server may further be configured to perform a process of verifying the electronic signature of the user device in the purchase log to further check whether data has been tampered with. The log collection server further checks whether the log is received.
Tampering check value (IC
V2), and transmits the log reception OK data + ICV2 to the user device (S1725). Step S1723
If the verification NG of the ICV1 is invalid, the falsification check value (ICV1) is added to the log reception NG data using the session key Kses.
2) is generated, and the log reception NG data + ICV2 is transmitted to the user device (S1726).

[0316] The user equipment receives the log reception data + ICV2.
(S1523), and if the verification is OK and the log reception is OK (S1524), a pair of a public key (KpDEV) and a secret key (KsDEV) for updating is generated (S1525), and the generated public key is generated. A falsification check value (ICV3) is generated and added to (KpDEV) and transmitted to the log collection server (S1526).

[0317] The log collection server uses the public key (KpDEV).
+ ICV3 is received from the user device (S1727)
And verification of ICV3 is executed (S1731), and verification OK
If it is, ICV for the public key reception OK message
4 is generated and transmitted to the user device (S1732). If verification of ICV3 is NG, public key reception NG
The ICV4 is generated and added to the message and transmitted to the user device (S1733).

Further, the log collection server checks the public key reception O
When the IC message 4 is generated and added to the K message and transmitted to the user equipment (S1732), the issuing authority (CA) is requested to issue a public key certificate together with the received public key, and the updated public information of the user equipment is issued. Key certificate (Cert_
DEV) (S1734), and further generates and adds a tampering check value ICV5 to the updated public key certificate (Cert_DEV) and transmits it to the user device (S1734).
35).

[0319] After receiving the public key reception result (OK or NG) + ICV4, the user device verifies the ICV4, the ICV4 verification is OK, and the public key reception OK (S1
532), the updated public key certificate + I
The CV5 is received (S1533), the ICV5 is verified, and the received public key certificate is verified (S1534). If both verifications are OK, the public key in the public key certificate is extracted and compared with the public key transmitted by itself (S1535). If they match, the secret key generated for updating, and The received public key certificate is stored in the memory of the user device (S1536), and the log (the log sent to the log collection server) is deleted (S1537).

Steps S1532, S1534, S15
If the determination of any of No. 35 is No, the process of updating the valid public key certificate is not executed, and the process ends.

Next, content sales confirmation processing executed between the content provider and the log collection server will be described with reference to the flow of FIG. The log collection server manages fee distribution information for one or more fee receiving entities of the content fee based on the purchase log received from the user device, and responds based on the fee distribution information in response to a sales confirmation request from the fee receiving entity. Execute the process. The log collection server can calculate the sales of the fee receiving entity based on the sales of the content from the content ID included in the purchase log and the content charge distribution information held by the log collection server in advance. In the case of receiving the log storing the sales confirmation data shown in FIG. 55B, the sales of the fee receiving entity can be calculated based on the distribution information included in the sales confirmation data.

First, mutual authentication is performed between the content provider and the log collection server (S1521, S1721).
Is executed, and the session key Kses is generated. The log collection server extracts the content provider identifier ID_CP from the public key certificate Cert_CP of the content provider (CP) on condition that the mutual authentication is established (S1722), and stores the sales data corresponding to the ID_CP into the log information stored in the database. Generated based on (S
1723). As described above, distribution information of content providers is stored in the collected log data, and the distribution fee of each content provider is obtained based on the log data. Further, the log collection server generates and adds a tampering check value ICV1 to the sales data, and transmits it to the content provider (CP) (S172).
4) Yes.

The content provider (CP) receives the sales data + ICV1 from the log collection server (S15).
22) Then, the ICV1 is verified to confirm that there is no data tampering (S1523), and the sales data is stored in the memory (S1524). If the ICV1 is verified and the data has been tampered with, the process is terminated without storing the data in the memory. In this case, the sales data request to the log collection server is made again.

Next, a shop server and a log collection server,
The sales report processing executed between the content providers will be described based on the processing flows of FIGS. The shop server manages the sales data of the content, and executes a process of transmitting all sales data within a predetermined period or sales data for each fee receiving entity to the log collection server. FIG. 64 shows a process of collectively transmitting the sales of the entire content sales process executed by the shop server to the log collection server.
The process 5 is a process of selecting the sales related to the content provided by the specific content provider during the content sales processing executed by the shop server and transmitting the selected sales to the content provider.

A description will be given of the sales collective reporting process shown in FIG. First, mutual authentication (S1631, S1731) is performed between the shop server and the log collection server.
A session key Kses is generated. The shop server extracts all the sales data for a predetermined period from the database on condition that the mutual authentication is established, generates a falsification check value ICV1 for all the sales data, and transmits it to the log collection server (S1632).

The log collection server receives all sales data + ICV1 from the shop server (S1732),
The CV1 is verified to confirm that there is no data tampering (S1733), and the sales data is stored in the memory (S1733).
1734). If the ICV1 is verified and the data is falsified, the data is not stored in the memory, and
The process ends. In this case, the sales data is again requested to the shop server.

The specific content provider sales report processing of FIG. 65 will be described. First, mutual authentication (S164) is performed between the shop server and the content provider.
1, S1741) is executed to generate the session key Kses. The shop server extracts ID_CP, which is the identifier of the content provider, from the public key certificate Cert_CP of the content provider obtained by the mutual authentication on condition that the mutual authentication is established (S1642). Based on the extracted ID_CP, the shop server extracts the sales data. A search is performed, and sales data of the content provided by the specific content provider is obtained (S1643). Further, a falsification check value ICV1 for the sales data is generated and added and transmitted to the log collection server (S1644).

The log collection server receives all sales data + ICV1 from the shop server (S1742),
The CV1 is verified to confirm that there is no data tampering (S1743), and the sales data is stored in the memory (S1743).
1744). If the ICV1 is verified and the data is falsified, the data is not stored in the memory, and
The process ends. In this case, the sales data is again requested to the shop server.

According to the configuration of this embodiment, it is possible to collect the content purchase log data in accordance with the update processing of the public key certificate of the user device, and the system operator (SH: System) that manages the log collection server. Holder) can reliably grasp the content sales situation. The public key certificate of the user device is required in the mutual authentication process with the shop server, and having a public key certificate with a valid expiration date is a condition for executing content purchase. In addition, the verification of the signature added to the purchase request data from the user device is also performed by the public key extracted from the public key certificate of the user device, and the public key certificate with a valid term is set. This is necessary for signature verification. Therefore, in order to purchase content, the user device needs to transmit log data to the log collection server, update the public key certificate, and have a public key certificate with a valid term. By setting the expiration date of the public key certificate to, for example, one month or three months, the system operator (SH: System Holder) managing the log collection server surely collects the accumulated logs for each setting organization. can do.

As described above, the log data collected from the user device is reliably collected by the log collection server managed by the system operator, and the content sales status can be managed. Further, based on the sales distribution information in the log data, the contents sales can be accurately distributed to the sales profit acquisition right holder such as a contents provider.

In this embodiment, a session key Kses generated at the time of mutual authentication is used for data communicated between the entities as a key for generating an alteration check value (ICV), and an ICV is added to transmission data for communication. With the configuration, the security of communication data is further enhanced.

In the above-described embodiment, a configuration has been described in which all of the mutual authentication processing, the signature generation, and the signature verification processing between the user device and the shop server are executed. Alternatively, as a configuration in which only the signature generation and signature verification processes are executed, the configuration may be such that the use of a public key certificate within the expiration date is required in any of the configurations.

[4. Configuration of Use of Public Key Certificate or Attribute Certificate Recording Attribute Data] Next, the configuration of use of a public key certificate or attribute certificate recording attribute data will be described. For example, in the content distribution configuration described above,
There is a possibility that a malicious shop operator may perform fictitious transaction of content by impersonating user equipment, or conduct fictitious content transaction between a content provider and a shop. Further, in a case where the user equipment which intends to execute a legitimate transaction starts communication by believing that the user equipment is a shop server, executes a content purchase request of the shop server partner, and executes, for example, a credit account number transmission process. In the case where the other party is a fraudulent server impersonating the shop server, there is a possibility that processing such as illegally acquiring a credit account number from the user device is executed. Furthermore, there is no denying the possibility that the user device pretends to be a shop and performs processing such as fictitious sale of content to other user devices. When such a situation occurs, it becomes difficult for the system operator to grasp the exact content distribution entity.

As a configuration for preventing such a fictitious transaction other than a legitimate content distribution route, a configuration using a public key certificate or attribute certificate in which attribute data is recorded will be described below.

[0335] Attribute data refers to user equipment (DEVIC).
E) Identify the types of entities that make up the content distribution system, such as shop (SHOP), content provider (CP), service operator (SH), registration authority that performs public key certificate and attribute certificate issuance examination. Data.

As a configuration example of the attribute data, FIG. 66 shows a table indicating the contents of the attribute data. As shown in FIG. 66, different codes are assigned to each entity.
For example, a request for issuing a public key certificate and an attribute certificate is received from a user device or a shop, etc., and “0000” is given to a registration authority for examination, and a system holder as a system holder that collects a license for content distributed on the content distribution system. “0001” is assigned to the service operator as an attribute code. In the example described above, the service operator is an entity that manages a user device authentication server that executes a key change process, or an entity that manages a log information collection server that collects log information.

[0337] Further, the content seller as a shop that sells the content to the user device is provided with "0
002 ”, and a content distributor who operates a distribution server that distributes content to a user in response to a request from a shop (content seller) is“ 000 ”.
3 ”and“ 0 ”for the user device that purchases and uses the content.
004 ”is assigned. In addition, different codes are assigned to entities related to content distribution according to their types. It should be noted that the present invention is not limited to a configuration in which one code is always assigned to a shop. If there are shops with different roles and functions, different codes may be assigned so that they can be distinguished from each other.
Further, a different attribute code may be assigned to a user device according to some category.

The attribute information described above has a configuration to be included in the public key certificate and a configuration to issue an attribute certificate different from the public key certificate and identify the attribute by the attribute certificate.
FIG. 67 shows a configuration example of a public key certificate having attribute information.

The public key certificate shown in FIG. 67 includes a certificate version number, a serial number of a certificate assigned by a public key certificate authority (CA) to a certificate subscriber, an algorithm and parameters used for an electronic signature, The name of the issuing authority, the expiration date of the certificate, the name of the certificate subscriber (ex. User device ID), the public key of the certificate subscriber, and the above [0000], [0001]... [Nnnn], etc. It contains attribute information and an electronic signature. The serial number of the certificate is, for example, a total of 16 bytes including the year of issue (4 bytes), month (2 bytes), day (2 bytes), and serial number (8 bytes). As the user name, an identifiable name defined by the registration authority, or a random number or a serial number may be used. Alternatively, the configuration may be such that the upper byte is a category and the lower byte is a serial number.

The electronic signature includes the version number of the certificate, the serial number of the certificate assigned by the public key certificate authority (CA) to the certificate subscriber, the algorithm and parameters used for the electronic signature, the name of the issuing authority, the certificate Expiration date of the document,
A hash value is generated by applying a hash function to the name of the relying party, the public key of the relying party, and the entire attribute data, and data generated using the secret key of the issuing authority for the hash value It is.

The public key certificate issuing authority (CA) issues the public key certificate shown in FIG. 67, updates the expired public key certificate, and rejects a user who has performed an illegal operation. Create, manage, and distribute a list of unauthorized persons (this is called Revocation).

On the other hand, when using this public key certificate, the user verifies the digital signature of the public key certificate by using the public key KpCA of the issuing authority held by the user, and verifies the digital signature. After success, the public key is extracted from the public key certificate and the public key is used. Therefore, all users who use the public key certificate need to have a common public key certificate authority public key.

Next, FIG. 68 shows a public key certificate having no attribute information and a data structure of the attribute certificate. (A) is a public key certificate having no attribute information, and has a data configuration obtained by removing attribute information from the public key certificate shown in FIG.
Issued by the public key certificate authority. (B) is an attribute certificate. An attribute certificate is issued by an attribute certificate authority (AA: Attrib).
ute Authority).

The attribute certificate shown in FIG. 68 is the version number of the certificate, the serial number of the public key certificate corresponding to the attribute certificate issued by the attribute certificate issuing authority (AA). It is the same as the serial number of the certificate, and has a function as link data that associates both certificates. An entity that wants to confirm the attribute of the communication partner by using an attribute certificate, sends an attribute certificate linked to the public key certificate,
Confirm based on the public key certificate and the public key certificate serial number that is commonly stored in the attribute certificate, and obtain attribute information from the attribute certificate that stores the same public key certificate serial number as the public key certificate Can be. The serial number is, for example, year (4 bytes), month (2 bytes), day (2 bytes),
The serial number (8 bytes) is 16 bytes in total. Furthermore, the algorithm and parameters used for the electronic signature, the name of the attribute certificate issuing authority, the expiration date of the certificate, the name of the certificate subscriber (ex. User device ID), which are used for the corresponding public key certificate The data structure is the same as the name of the person, and is an identifiable name defined by the registration authority, or a random number, a serial number, or a data structure in which the upper byte is a category and the lower byte is a serial number. In addition, [000
0], [0001]... [Nnnn], and the like, and the electronic signature of the attribute certificate issuing authority (AA).

The electronic signature includes the version number of the certificate, the serial number of the public key certificate, the algorithm and parameters used for the electronic signature, the name of the issuing authority, the expiration date of the certificate,
The hash value is generated by applying a hash function to the name of the certificate user and the entire attribute data, and the hash value is generated using the secret key of the attribute certificate issuing authority.

The attribute certificate issuing authority (AA) is shown in FIG.
In addition to issuing the attribute certificate shown in (B), renewing the expired attribute certificate, creating, managing, and distributing an unauthorized person list for rejecting a user who has made an illegal use Application: Revocation).

FIG. 69 is a view for explaining a procedure for newly issuing a public key certificate used by each of the user device and the shop server participating in the content transaction. Here, the shop server 1010 and the user device 102
0 has the same configuration as that described with reference to FIG. The service management body 1030 is a system holder (SH) that manages the entire content distribution, and performs the content key renewal processing or the method of collecting the log generated by the purchase of the content of the user device, and the like. Understand the distribution situation. Here, it also has a function as a registration authority (RA: Registration Authority) for receiving and issuing requests for issuance of public key certificates and attribute certificates of the shop server 1010 and the user devices 1020 and the like. In this example, the service management body 10
Reference numeral 30 denotes a configuration having a function as a system holder (SH) and a function as a registration authority (RA), but these may be configured as separate and independent entities.

In FIG. 69, new public key certificate issuing procedures in the user device 1020 are indicated by A1 to A8, and new public key certificate issuing procedures in the shop server 1010 are indicated by B1 to B7. First, the user equipment 1020
Will be described below.

(A1) Mutual Authentication First, the user device 1020 communicates with the service
Perform mutual authentication between and. However, at this point, since the user device 1020 does not have the public key certificate, the user device 1020 cannot execute the mutual authentication using the public key certificate, and the symmetric key encryption described with reference to FIG. A method, that is, a mutual authentication process using a shared secret key and an identifier (ID) is executed (for details, refer to the description related to FIG. 12).

(A2) Generation of a public key / private key pair (A3) Public key certificate issuance request (A4) Examination & public key certificate issuance request (A5) Public key certificate issuance request The encryption processing unit 1020 generates a pair of a public key and a private key to be newly registered in the encryption processing unit in its own device, and transmits the generated public key to the service operating unit 1030 together with a certificate issuance request. Upon receiving the public key certificate issuance request, the service operating unit 1030 examines the issuance request, and if the requirement as an entity that issues the public key certificate is satisfied, issues the public key certificate issuance to the public key certificate issuance. It transmits to the station (CA) 1040. If the public key certificate issued here is a public key certificate having the attribute information shown in FIG. 68 (A), the service operating body 1030 sets the attribute of the entity that transmitted the certificate issuance request to the ID Is determined based on

A user device participating in content distribution stores a user device identifier (ID) and a secret key as secret information in advance, and the user device ID and the secret key are managed by the service management body 1030. , The service operator 1030 searches the secret information storage database based on the ID transmitted from the user device,
After confirming that the user device ID has been registered in advance, the secret key is extracted, the user device is used for mutual authentication based on FIG. 12 using this key, and it is possible to participate in content distribution only when the mutual authentication is successful. Confirm that the user device is correct.

(A6) Issuing a public key certificate (A7) Sending a public key certificate (A8) Sending a public key certificate The public key certificate issuing authority 1040 that has received the public key certificate issuing request from the service operating body 1030 It stores the public key of the user device, issues a public key certificate (FIG. 67 or 68 (A)) having an electronic signature of the public key certificate issuing authority 1040, and transmits it to the service management body 1030. The service operating body 1030 transmits the public key certificate received from the public key certificate issuing authority 1040 to the user device 1020. The user device stores the received public key certificate and the secret key generated in (A2) above in its own device, and can use it for mutual authentication, data encryption, decryption processing and the like at the time of content transaction. Become.

On the other hand, the procedure for issuing a public key certificate of the shop server 1010 is basically the same as the procedure for issuing a certificate in the user device. However, the shop server sends the service management entity 1030 as an entity that sells contents. Procedures for approval are required. Therefore, the shop server 1010 needs to execute a license application (procedure in B2 in FIG. 69) together with its own public key. This is, for example, the service operator 1
This is executed as a process in which the shop server 1010 accepts the execution of content sales in accordance with the policy defined by 030. The service management body 1030
If the shop server 1010 can execute content sales in accordance with the policy defined by the service management body 1030 and accepts that the shop server 1010 complies with the policy, the procedure for issuing a public key certificate to the shop proceeds. The public key certificate issuance procedure is the same as that of the user device described above.

Next, the updating process of the public key certificate will be described with reference to FIG. Public key certificates are shown in FIGS.
The expiration date is set as shown in FIG. 7A, and the entity using the public key certificate cannot use the certificate whose expiration date has passed. Therefore, the renewal process is executed within the expiration date, and the new expiration date is set. It is necessary to perform a public key certificate issuance procedure in which is set.

In FIG. 70, the procedures for updating the public key certificate in the user device 1020 are indicated by A1 to A8, and the procedures for updating the public key certificate in the shop server 1010 are denoted by B.
1 to B7. First, a procedure for updating a public key certificate in the user device 1020 will be described.

(A1) Mutual Authentication First, the user device 1020 communicates with the service
Perform mutual authentication between and. At this point user equipment 1
Since 020 holds a currently valid public key certificate, it executes mutual authentication using the public key certificate. This is the mutual authentication process described above with reference to FIG. If the expiration date of the public key certificate already in hand has passed, the mutual authentication process using the shared secret key and the identifier (ID) described earlier with reference to FIG. You may do so.

(A2) New public key / private key pair generation (A3) Public key certificate renewal request (A4) Examination & public key certificate renewal request (A5) Public key certificate renewal request The device 1020 generates a pair of a new public key and a secret key for updating in the encryption processing unit in its own device, and transmits the generated public key to the service operating body 1030 together with a certificate update request. Service operating entity 1 that has received the public key certificate update request
030 examines the renewal request and, if the renewal requirement is satisfied, issues the certificate renewal request to a public key certificate authority (CA).
Send to 1040. If the public key certificate issued here is a public key certificate having the attribute information shown in FIG. 68 (A), the service operating body 1030 sets the attribute of the entity that transmitted the certificate issuance request to the ID Is determined based on

(A6) Update of public key certificate (A7) Transmission of public key certificate (A8) Transmission of public key certificate The public key certificate issuing authority 1040, which has received the public key certificate update request from the service operating body 1030, A public key certificate storing the new public key of the user device and having an electronic signature of the public key certificate issuing authority 1040 (FIG. 67 or FIG. 68).
(A)) and transmits it to the service management body 1030. The service operating body 1030 is the public key certificate issuing authority 1
The public key certificate received from the user device 1020
Send to The user device stores the received public key certificate and the secret key generated in (A2) above in its own device, and can use it for mutual authentication, data encryption, decryption processing and the like at the time of content transaction. Become.

On the other hand, the procedure for updating the public key certificate of the shop server 1010 is basically the same as the procedure for updating the certificate in the user device, but executes the above-described update of the license application (the procedure of B2 in FIG. 70). It is necessary to do. The service management body 1030 is the shop server 10
If the license of 10 is renewed, the procedure for updating the public key certificate for the shop is advanced. The procedure for updating the public key certificate is the same as that for the user device described above.

Next, a procedure for newly issuing an attribute certificate will be described with reference to FIG. The attribute certificate is shown in FIG.
The attribute certificate is issued after the issuance of the public key certificate shown in FIG. 68A. In FIG. 71, the new issuance procedure of the attribute certificate in the user device 1020 is indicated by A1 to A7, and the new issuance procedure of the public key certificate of the shop server 1010 is indicated by B1 to B7. First, a procedure for newly issuing a public key certificate in the user device 1020 will be described.

(A1) Mutual Authentication First, the user device 1020 is connected to the service
Perform mutual authentication between and. At this point user equipment 1
Since the public key certificate 020 already has a public key certificate issuing authority public key certificate, mutual authentication using the public key certificate is executed.

(A2) Attribute Certificate Issuance Request (A3) Examination & Attribute Certificate Issuance Request (A4) Attribute Certificate Issuance Request When mutual authentication is established, the user device 1020 sends the attribute certificate to the service Send a certificate issuance request. Service operator 1 that received the attribute certificate issuance request
030 examines the issuance request and transmits the certificate issuance request to the attribute certificate issuing authority (AA) 1050 when the requirement as an entity for issuing the attribute certificate is satisfied. Here, the service management entity 1030 sets the attribute of the entity that transmitted the certificate issuance request to the ID of the entity.
Is determined based on As described above, the user devices participating in the content distribution are provided with the user device identifier (I
D) is stored, and these user device IDs are managed by the service management unit 1030. The service management unit 1030 compares the ID transmitted from the user device with the user device ID registered in advance. With this, it is confirmed that the user device can participate in content distribution.

(A5) Issuing an attribute certificate (A6) Sending an attribute certificate (A7) Sending an attribute certificate The attribute certificate issuing authority 1050, which has received the attribute certificate issuance request from the service operating body 1030, sends the attribute of the user device. The information is stored, an attribute certificate (FIG. 68 (B)) having an electronic signature of the attribute certificate issuing authority 1050 is issued, and transmitted to the service management body 1030. The service management body 1030
The attribute certificate received from the attribute certificate issuing authority 1050 is transmitted to the user device 1020. The user device stores the received attribute certificate in its own device, and uses it for attribute confirmation processing at the time of content transaction.

On the other hand, the attribute certificate issuing procedure (B1 to B7) of the shop server 1010 is basically the same as the certificate issuing procedure in the user device. The procedure for updating the attribute certificate is the same as the procedure for new issuance.

Next, a content transaction involving an attribute confirmation process using an attribute certificate or an attribute confirmation process using attribute information stored in a public key certificate will be described.

FIG. 72 shows a processing configuration for executing the attribute confirmation processing at the time of mutual authentication. The configuration in FIG. 72 is the same as the system configuration in FIG. 1 described above. That is, the shop server 1010 that sells the content, the user device 1020 that executes the content purchase, and the user device authentication server 1030 are constituent elements. Here, the user device authentication server 1030 is under the management of the service operating entity described above. The processing proceeds in the order of numbers (1) to (20) in FIG. Details of the processing will be described in the order of each number.

(1) Mutual Authentication and Attribute Confirmation Process The user device 1020 that intends to purchase content from the shop server 1010 performs a mutual authentication process with the shop server. The two means for executing data transmission / reception mutually confirm whether or not the other party is a correct data communicator, and thereafter perform necessary data transfer. The process of confirming whether the other party is the correct data communicator is the mutual authentication process. One preferable data transfer method is to generate a session key during the mutual authentication process, and to perform data transmission by performing an encryption process using the generated session key as a shared key. The public key mutual authentication process is performed by extracting the partner's public key after verifying the signature of the issuing authority of the public key certificate. For details, refer to the description related to FIG.

Further, in this embodiment, an attribute confirmation process is executed. If attribute data is stored in the public key certificate of the communication partner, the shop server 1010 confirms that the attribute is data indicating that the attribute is a user device. If the attribute data is not stored in the public key certificate, the attribute is confirmed using the attribute certificate.
Since the attribute certificate is signed using the private key of the attribute certificate issuing authority, the public key of the attribute certificate issuing authority: K
The signature verification is performed using pAA to confirm that the certificate is valid, and the “serial number” and / or “user (ID)” of the attribute certificate is set to “serial number” and “serial number” in the public key certificate. After confirming whether or not it matches the "user (ID)", the attribute information in the certificate is confirmed.

On the other hand, if the attribute data is stored in the public key certificate of the communication partner, the user device 1020 confirms that the attribute is data indicating that it is a shop. When the attribute data is not stored in the public key certificate, the attribute certificate is subjected to signature verification using the public key of the attribute certificate issuing authority: KpAA to confirm that the certificate is valid. After confirming that the "serial number" and / or "user (ID)" of the attribute certificate matches the "serial number" and / or "user (ID)" in the public key certificate, Check the attribute information of.

[0370] The shop server 1010 confirms that the attribute of the public key certificate or attribute certificate of the content purchase requesting entity is a user device, and the user device 1020
After confirming that the attribute of the public key certificate or the attribute certificate of the content purchase request destination is shop, the process proceeds to subsequent processing.

FIG. 73 shows the flow of the attribute confirmation processing. FIG. 73A shows attribute confirmation processing using a public key certificate when attribute data is stored in the public key certificate.
(B) is an attribute confirmation process using an attribute certificate.

Description will be made from the flow of FIG. 73 (A). First, in step S2101, a mutual authentication process using a public key certificate is executed (see FIG. 13). On condition that the authentication is established (Yes in S2102), the attribute information is extracted from the public key certificate of the other party. Take out. When the attribute information is valid (Yes in S2104), it is determined that the mutual authentication and the attribute confirmation are successful (S2105),
Move to the subsequent processing. Note that the attribute is valid if, for example, the user device accesses the shop server to execute a content purchase request, the attribute is determined to be valid if the attribute is a shop, and other users other than the shop, for example, are authorized. If the attribute code indicates a device, it is determined that the attribute code is not valid. For example, when executing a content purchase request to the shop server, this determination process includes a step of executing an attribute code comparison process in a content purchase request processing sequence (ex. The assigned code [000
2] is compared with the attribute code acquired from the public key certificate or attribute certificate of the communication partner (entity), and if they match, it is determined to be valid; Alternatively, the public key certificate of the communication partner (entity) or the attribute code obtained from the attribute certificate is displayed on a display or the like, and the user compares the attribute code set for the entity assumed as the communication partner with the user himself / herself. May be determined. Step S21
02, when the determination is No in S2104, it is determined that the mutual authentication and the attribute confirmation have failed (S2106), and the subsequent processing is stopped.

As described above, in the processing execution program for the shop, the code [0002] assigned to the shop in advance and the public key certificate of the communication partner (entity) or the attribute certificate are determined. Steps are executed as a process for comparing with an attribute code acquired from a certificate. In a key exchange request process execution sequence (ex. Program) executed by the user device with respect to the user device authentication server, for example, user device authentication is performed in advance. The step is executed as a process of comparing the code [0001] assigned to the server with the public key certificate of the communication partner (entity) or the attribute code acquired from the attribute certificate. In addition, also in the communication processing between the shop and the user device authentication server, a processing sequence (e
x. In the program, a step is executed as a process of comparing an attribute code preset as a valid communication partner with a public key certificate of the communication partner (entity) or an attribute code acquired from the attribute certificate.

Next, a flow to which the attribute certificate shown in FIG. 73B is applied will be described. First, step S2201
, A mutual authentication process using the public key certificate is executed (see FIG. 13), and on condition that the authentication is established (Yes in S2202), the attribute certificate of the partner is verified by the attribute certificate issuing authority. Execute using public key (S220
3) Then, the verification is successful, and the attribute certificate linked to the public key certificate is confirmed based on the public key certificate and the public key certificate serial number commonly stored in the attribute certificate (S2).
The attribute information is extracted from the attribute certificate that stores the same public key certificate serial number as the public key certificate on condition that the determination in step 204 is Yes) (S2205). If the attribute information is valid (Yes in S2206), the mutual authentication
It is determined that the attribute confirmation has succeeded (S2207), and the process proceeds to subsequent processing. Step S2202, S220
4, If the determination is No in S2206, it is determined that mutual authentication and attribute confirmation have failed (S2208), and the subsequent processing is stopped.

(2) Transaction ID, purchase request data generation, and (3) purchase request data transmission When the mutual authentication and attribute confirmation between the shop server 1010 and the user device 1020 are successful, the user device 1
020 generates content purchase request data. The structure of the purchase request data is the structure shown in FIG. 14A described above. The shop ID which is the identifier of the shop server 1010 which is the request destination of the content purchase, and the encryption processing of the user device 1020 as the identifier of the transaction are performed. The means has a transaction ID generated based on a random number and data of a content ID as an identifier of a content that the user device desires to purchase, and a digital signature of the user device is added to these data.

(4) Verification of Received Data The purchase request data shown in FIG.
The shop server received from 0 performs a verification process of the received data. The verification process is performed by using the public key certificate Cert_DE of the user device as described above with reference to FIG.
After verification of V, the public key of the user device from the public key certificate:
The KpDEV is extracted and the public key of the user device: Kp_
The DEV is used to verify the user device signature of the purchase request data.

If the verification is successful, that is, if there is no falsification of the purchase request data, it is determined that the received data is valid content purchase request data. If the verification fails, it is determined that the purchase request data has been tampered with, and the processing for the purchase request data is stopped.

(5) Transmission of Encrypted Content and Encrypted Content Key Data 1 (Shop) When the shop server 1010 completes the verification of the purchase request data and determines that the request is a valid content purchase request without data tampering, the shop server The server 1010 transmits the encrypted content and the encrypted content key data 1 (shop) to the user device. These are all data stored in the content database, and the encrypted content: Kc (content) obtained by encrypting the content with the content key and the content key: Kc are public keys of the user equipment authentication server (DAS) 1030. Encrypted content key data: KpDAS (Kc).

[0379] Encrypted content key data 1 (shop)
Is the configuration shown in FIG. 14B described above. That is, the user device 102 from which the content purchase is requested
0, which is an identifier of the user device, purchase request data (data excluding the user device public key certificate in FIG. 14A), and the shop server 101 in accordance with the content transaction.
0 generated by the shop process No. , Encrypted content key data: KpDAS (Kc), and an electronic signature of the shop server 1010 is added to these data. Further, the public key certificate of the shop server 1010 is attached to the encrypted content key data 1 (shop) and sent to the user device 1020. If the shop server public key certificate has already been sent to the user device side in the above-described mutual authentication processing or processing before that, it is not always necessary to send it again.

(6) Received data verification Encrypted content: Kc from shop server 1010
(Content) and the user device 1020 that has received the encrypted content key data 1 (shop) shown in FIG.
Executes the verification process of the encrypted content key data 1 (shop). This verification processing is the same processing as the processing flow of FIG.
First executes verification of the public key certificate of the shop server received from the shop server 1010 using the public key KpCA of the issuing authority (CA), and then executes the public key KpSHOP of the shop server extracted from the public key certificate. Figure 1 using
Verification of the shop signature of the encrypted content key data 1 shown in FIG.

(7) Mutual Authentication and Attribute Confirmation Process The user device 1020 receives the encrypted content: Kc (content) and the encrypted content key data 1 (shop) from the shop server 1010, and receives the encrypted content key data 1 (shop). Shop), user equipment 1
020 accesses the user device authentication server 1030, and connects the user device 1020 with the user device authentication server 1030.
A mutual authentication process and an attribute confirmation process are executed between the 30 devices. This processing is executed by the same procedure as the above-described mutual authentication processing and attribute confirmation processing between the shop server 1010 and the user device 1020.

(8) Transmission of Encrypted Content Key Data (User Device) and Encrypted Content Key Change Request When mutual authentication and attribute confirmation between the user device 1020 and the user device authentication server 1030 are established, the user device 1020 The encrypted content key KpDAS (Kc) previously received from the shop server 1010 and the encrypted content key change request are transmitted to the user device authentication server 1030. The configuration of the encrypted content key data (user device) is the configuration shown in FIG. 14C described above. That is, the user device authentication server ID which is the identifier of the user device authentication server 1030 to which the request for the encrypted content key change request is made, the encrypted content key data received from the shop server 1010 (the shop public key in FIG. 14B) Data without certificate),
And a digital signature of the user device 1020 is added to these data. Further, the encrypted content key data (user device) includes a shop server 1010.
And the public key certificate of the user device 1020 are attached and sent to the user device authentication server 1030. When the user device authentication server 1030 already has the user device public key certificate and the shop server public key certificate, it is not necessary to send the certificate again.

(9) Received Data Verification The user device authentication server 1030 that has received the encrypted content key data (user device) and the encrypted content key change request (FIG. 14C) from the user device 1020
Executes the verification process of the encrypted content key change request. This verification processing is the same processing as the processing flow of FIG. 15 described above, and the user device authentication server 1030
First verifies the public key certificate of the user device received from the user device 1020 with the public key KpCA of the issuing authority (CA).
Then, the digital signature of the encrypted content key data (user device) shown in FIG. 14C is verified using the public key KpDEV of the user device extracted from the public key certificate. Further, verification of the public key certificate of the shop server is performed using the public key KpCA of the issuing authority (CA), and then using the public key KpSHOP of the shop server extracted from the public key certificate, FIG. (5) included in the encrypted content key data (user device)
The shop signature of the encrypted content key data 1 is verified. Also, the message transmitted by the user device is shown in FIG.
If the message is included in the format shown in (c), the verification of the message is executed as necessary.

(10) Encrypted content key change process In the user device authentication server 1030, the user device 1
When the verification of the encrypted content key data (user device) and the encrypted content key change request received from the terminal device 020 is completed and it is determined that the request is a valid key change request, the user device authentication server 1030 sets the encrypted content key The encrypted content key included in the data (user device), that is, data obtained by encrypting the content key: Kc with the public key KpDAS of the user device authentication server (DAS) 1030: KpDAS (Kc)
30, the content key Kc is obtained by decrypting the content key Kc with the public key KpDEV of the user device.
DEV (Kc) is generated. That is, KpDAS (K
c) A key change process of Kc → KpDEV (Kc) is executed.

[0385] As described above with reference to Fig. 16, this processing is performed from the encrypted content key data (user device).
Public key Kp of user equipment authentication server (DAS) 1030
Content key data encrypted by DAS: KpDAS
(Kc), and then the user device authentication server 10
The content key Kc is obtained by decryption with the 30 secret keys KsDAS, and then the content key Kc obtained by decryption is re-encrypted with the public key of the user device: KpDEV to generate an encrypted content key: KpDEV (Kc). This is the processing to be performed.

(11) Mutual Authentication and Attribute Confirmation Process In the user device authentication server 1030, when the above-described process of changing the encrypted content key is completed, the user device authentication server 1030 accesses the shop server 1010, A mutual authentication process and an attribute confirmation process are executed between the authentication server 1030 and the shop server 1010. This processing is performed in the shop server 10 described above.
It is executed in the same procedure as the mutual authentication process and the attribute confirmation process between the user device 10 and the user device 1020.

(12) Transmission of Encrypted Content Data User device authentication server 1030 and shop server 101
When the mutual authentication between 0 and the attribute confirmation process is established, the user device authentication server 1030 transmits the encrypted content key data (DAS) to the shop server 1010. The configuration of the encrypted content key data (DAS) is the configuration shown in FIG. 17D described above. Shop ID, which is the identifier of the shop server 1010 that is the content purchase request destination, and encrypted content key data (user equipment)
(Data excluding the shop and user device public key certificate in FIG. 14C), and further, the encrypted content key data: KpDEV (Kc) generated by the user device authentication server 1030 by the above-described key exchange process. The electronic signature of the user device authentication server 1030 is added to these data. Further, the encrypted content key data (DAS) includes the user device authentication server 1030.
Then, the public key certificate of the user device 1020 is attached and sent to the shop server 1010. If the shop server already has these public key certificates, it is not necessary to send them again.

When the user device authentication server 1030 is recognized as a trusted third party, the encrypted content key data (DAS) is
As shown in FIG. 18 (d), the data configuration does not include the encrypted content key data (user device) generated by the user device as it is as shown in FIG.
User device ID, transaction ID, content I
D, shop processing NO, and content key KpDEV (Kc) data encrypted with the public key of the user device,
The user device authentication server 1030 may extract the information and add a signature to the extracted information to obtain encrypted content key data (DAS). In this case, (8) it is not necessary to verify the encrypted content key data (user device), so the attached public key certificate may be only the public key certificate of the user device authentication server 1030.

(13) Received Data Verification The shop server 1010 that has received the encrypted content key data (DAS) (FIG. 17D) from the user device authentication server 1030 receives the encrypted content key data (DA
The verification processing of S) is executed. This verification processing is the same processing as the processing flow of FIG. 15 described above, and the shop server 1010 first checks the user device authentication server 1030
Verifying the public key certificate of the user device authentication server received from the public key KpCA of the issuing authority (CA),
Next, the electronic signature of the encrypted content key data (DAS) shown in FIG. 17D is verified using the public key KpDAS of the user device authentication server 1030 extracted from the public key certificate. Further, the public key certificate of the user device is verified using the public key KpCA of the issuing authority (CA),
Next, the public key K of the user device extracted from the public key certificate
The verification of the user device signature of the (8) encrypted content key data (user device) included in the encrypted content key data (DAS) shown in FIG. 17D is performed using the pDEV. Also, the message transmitted from the user device is as shown in FIG.
If the message is in the format shown in (1), the verification of the message is executed as necessary.

If the shop server 1010 receives the simplified encrypted content key data (DAS) shown in FIG.
10 executes verification of the public key certificate of the user device authentication server by using the public key KpCA of the issuing authority (CA), and then, the user device authentication server 10 extracted from the public key certificate.
The process only executes the verification of the electronic signature of the encrypted content key data (DAS) shown in FIG. 18D using the 30 public keys KpDAS.

(14) Mutual authentication and attribute confirmation (15) Transmission of encrypted content key request data Next, the user equipment 1020 transmits encrypted content key request data to the shop server. At this time, if the request is executed in a session different from the previous request, mutual authentication and attribute confirmation are executed again, and the encrypted content key request data is transmitted to the user on condition that the mutual authentication and attribute confirmation are established. The information is transmitted from the device 1020 to the shop server 1010. When the message transmitted by the user device is included in the format shown in FIG. 14C, the verification of the message is executed as necessary.

The structure of the encrypted content key request data is as shown in FIG. The encrypted content key request data includes a shop ID that is an identifier of the shop server 1010 to which the content purchase is requested, a transaction ID that is generated by the cryptographic processing unit of the user device 1020 based on a random number as an identifier of the transaction, A content ID serving as an identifier of a content that the device desires to purchase, and a user device 1 generated first by the shop and as encrypted content key data 1 (shop)
020 contained in the data (see FIG. 14B). And an electronic signature of the user device is added to these data. Further, the public key certificate of the user device is attached to the encrypted content key request data and sent to the shop server 1010. If the public key certificate has already been stored at the shop, it is not necessary to send it again.

(16) Verification Processing and (17) Billing Processing Upon receiving the encrypted content key request data from the user device, the shop server 1010 executes the verification processing of the encrypted content key request data. This is the same process as described with reference to FIG. When the data verification is completed, the shop server 1010 executes a billing process regarding the transaction of the content. The billing process is a process of receiving a content fee from a user's transaction account. The received content fee is distributed to various parties, such as the copyright holder of the content, the shop, and the administrator of the user device authentication server.

[0394] Before the accounting process, the process of re-keying the encrypted content key by the user device authentication server 1030 is indispensable. Therefore, the shop server 1010 performs accounting only for processing between user devices. Processing cannot be performed. Also, the user device 1020 cannot decrypt the encrypted content key, and thus cannot use the content. The user device authentication server records the content transaction contents that have executed all of the key exchange processes in the user device authentication server / license management database described with reference to FIG. It becomes possible to grasp. Therefore, it is impossible for the shop to independently trade contents, and illegal contents sales are prevented.

(18) Transmission of Encrypted Content Key Data 2 (Shop) When the charging process in the shop server 1010 is completed, the shop server 1010 transmits the encrypted content key data 2 (shop) to the user device 1020.

[0396] Encrypted content key data 2 (shop)
Is as shown in FIG. 17F described above. The user device ID which is the identifier of the user device 1020 which is the request source of the encrypted content key request, the encrypted content key data (DAS) received from the user device authentication server 1030 (the user device of FIG. Data excluding the server public key certificate), and an electronic signature of the shop server 1010 is added to these data. Further, the public key certificate of the shop server 1010 and the public key certificate of the user device authentication server 1030 are attached to the encrypted content key data 2 (shop) and sent to the user device 1020. If the user device 1020 already has the user device authentication server public key certificate and the shop server public key certificate, it is not necessary to send the certificate again.

The user device authentication server 1030 is recognized as a trusted third party, and the shop server 1010 is connected to the user device authentication server 1030.
If the encrypted content key data (DAS) received from the server 1 is the simplified encrypted content key data (DAS) shown in FIG.
Step 010 sends the encrypted content key data 2 (shop) shown in FIG. 18 (f ′) to the user device. That is, the public key certificate of the shop server 1010 is added to the data obtained by adding the signature of the shop server to the simplified encrypted content key data (DAS) shown in FIG.
The public key certificate of the user device authentication server 1030 is attached and sent to the user device 1020.

(19) Verification of Received Data Upon receiving the encrypted content key data 2 (shop) from the shop server 1010, the user device 1020 executes a process of verifying the encrypted content key data 2 (shop). This verification processing is the same processing as the processing flow of FIG. 15 described above, and the user equipment 1020 first verifies the public key certificate of the shop server received from the shop server 1010 by publicizing the issuing authority (CA). Key KpCA
1 using the public key KpSHOP of the shop server 1010 extracted from the public key certificate.
Verification of the electronic signature of the encrypted content key data 2 (shop) shown in FIG. Further, the verification of the public key certificate of the user device authentication server 1030 is performed by the issuing authority (C).
A) using the public key KpCA of A), and then using the public key KpDAS of the user device authentication server 1030 extracted from the public key certificate to the encrypted content key data 2 (shop) shown in FIG. The signature verification of the included (12) encrypted content key data (DAS) is executed.
If any transmission message is included in the format shown in FIG. 17F, the verification of the message is executed as necessary.

(20) Storage Processing The user device 1020 that has verified the encrypted content key data 2 (shop) received from the shop server 1010
Is the encrypted content key: KpDEV (Kc) encrypted with its own public key KpDEV included in the encrypted content key data 2 (shop).
And the storage key Ksto of the user device.
Content key: Ksto (K
c) is generated and stored in the storage means of the user equipment 1020. When the content is used, the encrypted content key: Ksto (Kc) is decrypted using the storage key Ksto, the content key Kc is extracted, and the encrypted content Kc (Conten) is extracted using the extracted content key Kc.
The decryption process of t) is executed to reproduce and execute the content (Content).

[0400] As described above, in each process associated with content distribution, each entity that executes communication includes:
By confirming the attribute of the other party, for example, after confirming that the device is a user device, the process is executed, so that an illegal content transaction, for example, a process in which a shop impersonates the user device and transacts the content,
Alternatively, the process of impersonating the shop server and illegally acquiring the credit account number from the user device is prevented.

For example, if the user equipment is confirmed by the attribute confirmation that the communication partner of the user equipment is a shop,
It is possible to safely execute the process associated with the purchase of content as a process for the shop, and in the attribute confirmation,
If it is confirmed that the communication partner is the user device authentication server, processing for the user device authentication server, for example, transmission of a key change request can be executed. According to this configuration, the attribute of the communication partner can be confirmed by performing the attribute confirmation, so that a legitimate process corresponding to each communication partner is executed. Furthermore, since confidential data is not erroneously transmitted to an unauthorized communication partner, data leakage can be prevented.

Next, a form in which only the signature verification of the received data is executed, the presence / absence of data falsification and the attribute confirmation are executed to execute the content transaction processing without executing the other party confirmation by the mutual authentication processing is shown in FIG. 74. This will be described with reference to FIG.

The processing shown in FIG. 74 is executed as a processing in which the mutual authentication processing is omitted from the processing shown in FIG. Processing proceeds in the order of numbers (1) to (16) in FIG. Details of the processing will be described in the order of each number.

(1) Transaction ID, purchase request data generation, and (2) purchase request data transmission First, the user device 1020 generates content purchase request data and transmits it to the shop server 1010. The structure of the purchase request data is the structure shown in FIG.

(3) Received Data Verification The purchase request data shown in FIG.
The shop server received from 0 performs a verification process of the received data. The verification processing in the present embodiment is to check the presence or absence of falsification of the purchase request data and also to check the attribute information.

FIG. 75 shows a received data verification processing flow when attribute information is stored in a public key certificate. First, the shop server 1010 that has received the message, the signature (purchase request data), and the public key certificate of the user device (S2301) uses the public key certificate of the public key certificate issuing authority as the public key certificate of the user device. Verification (S230
2) Do it. When the verification is established (Yes in S2303),
The public key of the user device: KpDEV is extracted from the public key certificate (S2304), and the public key of the user device: KpD
The user device signature of the purchase request data is verified using the EV (S2305). Further, the verification is successful (S23).
If “Yes” in step 06, attribute information is extracted from the public key certificate (S2307), and it is determined whether the attribute is a valid attribute (here, an attribute indicating a user device) (S2308).
If it is valid, the verification process is successful (S2309), and the process proceeds to the next process. Step S2303, S2
If the determination is No in 306 and S2308, the verification process fails (S2310) and the process is stopped.

Next, a received data verification process using a public key certificate and an attribute certificate will be described with reference to the flow of FIG. First, the message and signature (purchase request data)
And the public key certificate and the attribute certificate of the user device are received (S
2401) The shop server 1010 performs the public key certificate of the user device with the public key KpCA of the public key certificate issuing authority.
The verification is performed using (step S2402). Verification is established (S24
If the answer is Yes in 03, the public key of the user device: KpDEV is extracted from the public key certificate (S2404), and the user device signature of the purchase request data is verified using the public key of the user device: KpDEV (S2405). Further, when the verification is successful (Yes in S2406), the attribute certificate is verified using the public key KpAA of the attribute certificate issuing authority (S2407). Verification succeeded (Ye in S2408)
s), the attribute information is extracted from the attribute certificate (S2409), and it is determined whether the attribute is a valid attribute (here, an attribute indicating the user device) (S2410).
If it is valid, the verification process is successful (S2411), and the process proceeds to the next process. Step S2403, S2
If the determination is No in 406, S2408, and S2410, the process is stopped as the verification process has failed (S2412).

(4) Transmission of Encrypted Content and Encrypted Content Key Data 1 (Shop) In the shop server 1010, verification of the purchase request data is completed, and it is determined that the request is a legitimate content purchase request without data tampering, and the attribute is determined. Upon confirmation, the shop server 1010 transmits the encrypted content and the encrypted content key data 1 (shop) (see FIG. 14B) to the user device.

(5) Received Data Verification Encrypted content: Kc from shop server 1010
(Content) and the user device 1020 that has received the encrypted content key data 1 (shop) shown in FIG.
Executes the verification process and the attribute confirmation process of the encrypted content key data 1 (shop). This verification processing is the same processing as the processing flow of FIG. 75 or FIG. 76 described above. In this case, if the attribute of the public key certificate or the attribute certificate does not indicate the shop, the process is stopped.

(6) Encrypted Content Key Data (User Device) and Encrypted Content Key Change Request Transmission Next, the user device 1020 sends the user device authentication server 1
030, the encrypted content key KpDAS (Kc) previously received from the shop server 1010 and the encrypted content key change request (see FIG. 14C) are transmitted.

(7) Received Data Verification The user device authentication server 1030 that has received the encrypted content key data (user device) and the encrypted content key change request (FIG. 14C) from the user device 1020
Executes the verification process of the encrypted content key change request. This verification processing is the same processing as the processing flow of FIGS. 75 and 76 described above, and is a processing that also executes attribute confirmation. In this case, if the attribute of the public key certificate or the attribute certificate is not a user device, the process is stopped.

(8) Encrypted content key change process Next, the user device authentication server 1030
A key change process of AS (Kc) → Kc → KpDEV (Kc) is executed.

(9) Transmission of Encrypted Content Data Next, the user device authentication server 1030 transmits the encrypted content key data (DAS) to the shop server 1010. The configuration of the encrypted content key data (DAS) is the configuration shown in FIG. 17D described above.

(10) Verification of Received Data Upon receiving the encrypted content key data (DAS) (FIG. 17D) from the user device authentication server 1030, the shop server 1010 receives the encrypted content key data (DA).
The verification processing of S) is executed. This verification processing is similar to the processing flow of FIGS. 75 and 76 described above,
Attribute confirmation is also performed. In this case, if the attribute of the public key certificate or the attribute certificate is not the user device authentication server (service operating body), the process is stopped.

[0415] (11) Transmission of encrypted content key request data Next, the user device 1020 transmits encrypted content key request data to the shop server. The structure of the encrypted content key request data is as shown in FIG.

[0416] (12) Verification processing and (13) Charging processing The shop server 1010 that has received the encrypted content key request data from the user equipment executes the verification processing of the encrypted content key request data. This is the same processing as the processing flow of FIGS. 75 and 76 described above, and is a processing that also executes attribute confirmation. In this case, if the attribute of the public key certificate or attribute certificate is not a user device,
Processing is aborted. When the data verification is completed, the shop server 1010 executes a billing process regarding the transaction of the content.

(14) Transmission of Encrypted Content Key Data 2 (Shop) When the charging process in the shop server 1010 is completed, the shop server 1010 transmits the encrypted content key data 2 (shop) to the user device 1020.
The configuration of the encrypted content key data 2 (shop) is as shown in FIG.

(15) Verification of Received Data (16) Storage Process Upon receiving the encrypted content key data 2 (shop) from the shop server 1010, the user device 1020 executes the verification process of the encrypted content key data 2 (shop). I do. This verification processing is performed in accordance with FIGS. 75 and 76 described above.
Is a process similar to that of the process flow of FIG. In this case, if the attribute of the public key certificate or the attribute certificate is not a shop, the process is stopped. After the data verification, the user device 1020 stores the content, that is, the encrypted content key encrypted with its own public key KpDEV: KpDEV (Kc).
Is decrypted using its own secret key KsDEV, and further encrypted using the storage key Ksto of the user device to generate an encrypted content key: Ksto (Kc), which is stored in the storage unit of the user device 1020. Execute the processing to be performed.

As described above, in the processing shown in FIG. 74, instead of performing attribute confirmation at the time of mutual authentication, processing for confirming attributes is performed in signature verification of received data, so that processing is simplified. And the efficiency of processing accompanying the content transaction is achieved.

[0420] In the embodiment in which the attribute confirmation based on the attribute data is applied, the configuration in which the key change process is executed in the service operating body has been described. Confirmation processing can be applied. Between the entities that perform other general data transmission / reception, attributes are set based on the functions characteristic of each entity, the set attributes are stored in a public key certificate or an attribute certificate, and these certificates are stored. Executing the attribute confirmation process of the communication partner using the certificate can further enhance the security and security of data communication. Also,
Since the attribute confirmation process can be performed together with the conventional mutual authentication process and signature verification process, normal data communication performs only signature verification or only mutual authentication.
Selective signature verification processing, mutual authentication processing, etc., depending on the degree of security, such as performing attribute confirmation processing as necessary
It is possible to execute any one of the attribute confirmation processes or a combination thereof.

The present invention has been described in detail with reference to the specific embodiments. However, it is obvious that those skilled in the art can modify or substitute the embodiment without departing from the spirit of the present invention. That is, the present invention has been disclosed by way of example, and should not be construed as limiting. In order to determine the gist of the present invention, the claims described at the beginning should be considered.

[0422]

As described above, according to the content distribution system and the content distribution method having the log management configuration of the present invention, the content purchase log is updated in accordance with the process of updating the public key certificate of the user device that purchases the content. Data can be collected, and a system operator (SH: System Holder) managing the log collection server can reliably grasp the content sales situation.

According to the content distribution system and the content distribution method having the log management configuration of the present invention, the public key certificate of the user device is added to the mutual authentication processing with the shop server or the purchase request data from the user device. In order to purchase the content, the user device sends log data to the log collection server, updates the public key certificate, and updates the public key certificate in order to purchase the content. It is necessary to have a letter. Therefore, even if the user device has the expired public key certificate, the content cannot be purchased, and it is possible to prompt the user to update the public key certificate.

Further, according to the content distribution system and the content distribution method having the log management configuration of the present invention,
The log data collected from the user device is reliably collected by the log collection server managed by the system operator, and the content sales status can be managed. Further, based on the sales distribution information in the log data, the contents sales can be accurately distributed to the sales profit acquisition right holder such as a contents provider.

Further, according to the content distribution system and the content distribution method having the log management configuration of the present invention,
The data communicated between the entities such as the user device, the shop server, the log collection server, and the like are provided with a session key Kses generated at the time of mutual authentication by a falsification check value (IC
V) is used as a generation key and communication is performed by adding an ICV to transmission data, so that the security of communication data is further enhanced.

[Brief description of the drawings]

FIG. 1 is a diagram illustrating a system outline of a content distribution system of the present invention and a content distribution process.

FIG. 2 is a diagram showing a configuration of a shop server in the content distribution system of the present invention.

FIG. 3 is a diagram showing a configuration of a purchase management database of a shop server in the content distribution system of the present invention.

FIG. 4 is a diagram showing a configuration of control means of a shop server in the content distribution system of the present invention.

FIG. 5 is a diagram showing a configuration of a user device authentication server in the content distribution system of the present invention.

FIG. 6 is a diagram showing a configuration of a license management database of a user device authentication server in the content distribution system of the present invention.

FIG. 7 is a diagram showing a configuration of a user device in the content distribution system of the present invention.

FIG. 8 is a diagram showing a configuration of a purchase management database of user equipment in the content distribution system of the present invention.

FIG. 9 is a diagram showing a public key certificate distribution configuration in the content distribution system of the present invention.

FIG. 10 is a diagram illustrating a signature generation process applicable in the content distribution system of the present invention.

FIG. 11 is a diagram illustrating a signature verification process applicable in the content distribution system of the present invention.

FIG. 12 is a diagram illustrating a mutual authentication (symmetric key method) process applicable in the content distribution system of the present invention.

FIG. 13 is a diagram illustrating a mutual authentication (asymmetric key method) process applicable in the content distribution system of the present invention.

FIG. 14 is a diagram illustrating a data configuration communicated between entities in the content distribution system of the present invention.

FIG. 15 is a diagram illustrating data verification processing applicable in the content distribution system of the present invention.

FIG. 16 is a diagram for explaining a key change process executed in the content distribution system of the present invention.

FIG. 17 is a diagram illustrating a data configuration communicated between entities in the content distribution system of the present invention.

FIG. 18 is a diagram illustrating a data configuration communicated between entities in the content distribution system of the present invention.

FIG. 19 is a diagram illustrating content key storage processing executed in the content distribution system of the present invention.

FIG. 20 is a diagram illustrating a status transition of a shop server in the content distribution system of the present invention.

FIG. 21 is a diagram illustrating a status transition of a user device in the content distribution system of the present invention.

FIG. 22 is a diagram illustrating a status transition of the user device authentication server in the content distribution system of the present invention.

FIG. 23 is a diagram showing a processing flow (1) between the shop server and the user device in the content distribution system of the present invention.

FIG. 24 is a diagram showing a processing flow (2) between the shop server and the user device in the content distribution system of the present invention.

FIG. 25 is a diagram showing a processing flow between the user device authentication server and the user device in the content distribution system of the present invention.

FIG. 26 is a diagram showing a processing flow between a user device authentication server and a shop server in the content distribution system of the present invention.

FIG. 27 is a diagram showing a processing flow (1) between the shop server and the user device in the content distribution system of the present invention.

FIG. 28 is a diagram showing a processing flow (part 2) between the shop server and the user device in the content distribution system of the present invention.

FIG. 29 is a diagram illustrating a content distribution process using a distribution server as a modification of the content distribution system of the present invention.

FIG. 30 is a diagram illustrating content distribution processing using a distribution server as a modification of the content distribution system of the present invention.

FIG. 31 is a diagram illustrating content distribution processing of a modification of the content distribution system of the present invention.

FIG. 32 is a diagram illustrating a data configuration communicated between entities in the content distribution system of the present invention.

FIG. 33 is a diagram illustrating a data structure communicated between entities in the content distribution system of the present invention.

FIG. 34 is a diagram illustrating a data configuration communicated between entities in the content distribution system of the present invention.

FIG. 35 is a diagram illustrating content distribution processing without mutual authentication of the content distribution system of the present invention.

FIG. 36 is a diagram illustrating a modification of the content distribution processing without mutual authentication of the content distribution system of the present invention.

FIG. 37 is a diagram illustrating content distribution processing using an electronic ticket in the content distribution system of the present invention.

FIG. 38 is a diagram illustrating a configuration of a ticket issuing server of the content distribution system of the present invention.

FIG. 39 is a diagram illustrating the configuration of a ticket issuance management database of the ticket issuance server of the content distribution system of the present invention.

FIG. 40 is a diagram illustrating a purchase management database configuration of a user device of the content distribution system of the present invention.

FIG. 41 is a diagram illustrating a license management database configuration of a user device authentication server of the content distribution system of the present invention.

FIG. 42 is a diagram illustrating a configuration of a distribution server of the content distribution system of the present invention.

FIG. 43 is a diagram illustrating a configuration of a distribution management database of a distribution server of the content distribution system according to the present invention.

FIG. 44 is a diagram illustrating a configuration of a ticket exchange server of the content distribution system of the present invention.

FIG. 45 is a diagram illustrating the configuration of a ticket exchange management database of a ticket exchange server of the content distribution system of the present invention.

FIG. 46 is a diagram illustrating a data configuration communicated between entities in the content distribution system of the present invention.

FIG. 47 is a diagram illustrating a data configuration communicated between entities in the content distribution system of the present invention.

FIG. 48 is a diagram illustrating a status transition of the ticket issuing server in the content distribution system of the present invention.

FIG. 49 is a diagram illustrating a status transition of the user device authentication server in the content distribution system of the present invention.

FIG. 50 is a diagram illustrating a status transition of the distribution server in the content distribution system of the present invention.

FIG. 51 is a diagram illustrating a status transition of a user device in the content distribution system of the present invention.

FIG. 52 is a diagram illustrating a status transition of the ticket exchange server in the content distribution system of the present invention.

FIG. 53 is a diagram illustrating a specific example of content distribution processing using an electronic ticket in the content distribution system of the present invention.

FIG. 54 is a diagram illustrating content distribution processing to which a log collection server is applied in the content distribution system of the present invention.

FIG. 55 is a diagram illustrating a configuration example of a purchase log in the content distribution system of the present invention.

FIG. 56 is a diagram showing a configuration of a log collection server in the content distribution system of the present invention.

FIG. 57 is a flowchart (part 1) illustrating processing between a user device and a shop server in the content distribution system of the present invention.

FIG. 58 is a flowchart (part 2) illustrating a process between the user device and the shop server in the content distribution system of the present invention.

FIG. 59 is a diagram showing a format example of purchase request data and sales confirmation data in the content distribution system of the present invention.

FIG. 60 is a diagram showing a configuration of a falsification check value (ICV) generation process which can be performed in the content distribution system of the present invention.

FIG. 61 is a flowchart (part 1) illustrating processing between a user device and a log collection server in the content distribution system of the present invention.

FIG. 62 is a flowchart (part 2) showing a process between the user device and the log collection server in the content distribution system of the present invention.

FIG. 63 is a flowchart showing processing between a content provider and a log collection server in the content distribution system of the present invention.

FIG. 64 is a flowchart showing processing between a shop server and a log collection server in the content distribution system of the present invention.

FIG. 65 is a flowchart showing processing between a shop server and a log collection server in the content distribution system of the present invention.

FIG. 66 is a diagram illustrating attribute information applied in the content distribution system of the present invention.

FIG. 67 is a diagram showing a public key certificate configuration having attribute information applicable in the content distribution system of the present invention.

FIG. 68 is a diagram showing a public key certificate and an attribute certificate configuration applicable in the content distribution system of the present invention.

FIG. 69 is a diagram illustrating a process of newly issuing a public key certificate in the content distribution system of the present invention.

FIG. 70 is a diagram illustrating a process of updating a public key certificate in the content distribution system of the present invention.

FIG. 71 is a diagram illustrating a new attribute certificate issuing process in the content distribution system of the present invention.

FIG. 72 is a diagram illustrating content distribution processing with attribute checking in the content distribution system of the present invention.

FIG. 73 is a flowchart illustrating a mutual authentication process involving an attribute check in the content distribution system of the present invention.

FIG. 74 is a diagram illustrating content distribution processing with attribute checking in the content distribution system of the present invention.

FIG. 75 is a flowchart illustrating a data verification process involving an attribute check in the content distribution system of the present invention.

FIG. 76 is a flowchart illustrating a data verification process involving an attribute check in the content distribution system of the present invention.

[Explanation of symbols]

 100 Shop Server 110 Content Database 120 Purchasing Management Database 130 Control Unit 131 Control Unit 132 ROM 133 RAM 134 Display Unit 135 Input Unit 136 HDD 137 Drive 138 Network Interface 200 User Equipment 220 Purchase Management Database 230 Control Unit 300 User Equipment Authentication Server 320 License Management database 330 Control means 400 Distribution server 410 Content database 610 Ticket issuing server 612 Purchase management database 613 Control means 620 User equipment 630 User equipment authentication server 640 Distribution server 642 Distribution management database 643 Control means 644 Content database 650 Ticket exchange server 652 Ticket exchange Management database 653 control means 801 ticket issuer 802 user equipment 803 license holder 804 content creator 805 bank 901 shop server 902 user equipment 903 log collection server 904 authoring server 905 content provider 9031 log management database 9032 control means 1010 shop server 1020 user equipment 1030 service Management entity 1040 Public key certificate issuing authority 1050 Attribute certificate issuing authority

──────────────────────────────────────────────────続 き Continued on the front page (51) Int.Cl. ⁷ Identification symbol FI Theme coat ゛ (Reference) G06F 17/60 512 G06F 17/60 512 G09C 1/00 640 G09C 1/00 640B 640Z H04L 9/32 H04N 7 7/173 640A H04N 7/173 640 H04L 9/00 675B (72) Inventor Kenji Yoshino 6-7-35 Kita Shinagawa, Shinagawa-ku, Tokyo Inside Sony Corporation (72) Inventor Toru Akishita Kita, Shinagawa-ku, Tokyo 6-7-35 Shinagawa, Sony Corporation (72) Inventor Makoto Oka 6-7-35 Kita-Shinagawa, Shinagawa-ku, Tokyo F-term (reference) 5C064 BA01 BB01 BC01 BC18 BD02 BD16 5J104 AA07 AA08 AA09 AA16 EA05 EA06 EA19 KA02 KA05 LA03 LA06 NA02 NA03 NA12 NA16 PA11

Claims (20)

[Claims] 1. A shop server for receiving a content purchase request from a user device and transmitting sales confirmation data to the user device; and transmitting a content purchase request data to the shop server, the user having an expiration date set. A user device that executes content purchase request processing based on a procedure using a device public key certificate, receives the sales confirmation data, and generates and stores a purchase log based on the received sales confirmation data; Receiving a request to update the public key certificate of the user device based on the receipt of the purchase log, and collecting an updated public key certificate of the user device issued by the public key certificate issuing authority to the user device; A content distribution system having a log management configuration, comprising: a server; 2. The method according to claim 1, wherein the procedure using the public key certificate whose expiration date is set is a mutual authentication process using a public key certificate executed between the user device and the shop server. A content distribution system having the log management configuration according to claim 1. 3. The procedure using a public key certificate with an expiration date set includes the steps of: generating a digital signature generated by the user device with respect to content purchase request data sent from the user device to the shop server; The log management configuration according to claim 1, wherein the signature verification process is performed by the shop server, and the signature verification process is a process using a public key stored in a public key certificate of the user device. Content distribution system with. 4. At least a part of data transmitted / received between the user device and the shop server includes a falsification check value based on a session key Kses generated at the time of mutual authentication performed between the user device and the shop server. The content distribution system having a log management configuration according to claim 1, wherein the content distribution system is configured to transmit the data with an ICV) added thereto and execute a data tampering check process based on the ICV on the receiving side. 5. The user device checks a purchase log transmitted to the log collection server for tampering based on a session key Kses generated during mutual authentication performed between the user device and the log collection server. Value (I
CV) and send the log collection server.
The content distribution system having a log management configuration according to claim 1, wherein the content distribution system is configured to execute a data tampering check process based on CV. 6. The user device generates and adds an electronic signature of the user device to a purchase log transmitted to the log collection server, and the log collection server generates a digital signature of the user device. The content distribution system having a log management configuration according to claim 1, wherein the content distribution system is configured to execute a verification process. 7. The log collection server manages fee distribution information for one or more fee receiving entities of a content fee based on a purchase log received from the user device, and responds to a sales confirmation request from the fee receiving entity. The content distribution system having a log management configuration according to claim 1, further comprising a configuration for executing a response process based on the charge distribution information. 8. The shop server manages content sales data and executes a process of transmitting all sales data within a predetermined period or sales data for each fee receiving entity to the log collection server. The content distribution system having a log management configuration according to claim 1, wherein 9. The content purchase request data generated by the user device and transmitted to the shop server includes a transaction I as a content transaction identifier.
D, which is configured as data including a content ID as a content identifier of a purchase request target and including an electronic signature of a user device, wherein the shop server checks the presence or absence of data tampering by executing signature verification of the content purchase request data The content having a log management configuration according to claim 1, further comprising a process for generating the sales confirmation data based on the content purchase request data and transmitting the generated data to the user device. Delivery system. 10. A log collection server for managing sales of contents traded between a user device and a shop server, and receiving a purchase log generated by the user device according to the content purchased by the user device. A log collection server that receives a public key certificate update request from the user device as a condition and executes content sales management based on the received purchase log. 11. A step of transmitting content purchase request data from a user device to a shop server, and executing a content purchase request process based on a procedure using a public key certificate with an expiration date set; Receiving a content purchase request from the user device and transmitting sales confirmation data to the user device; and receiving the sales confirmation data at the user device;
Generating and storing a purchase log based on the received sales confirmation data; and, in a log collection server, receiving a request for updating the public key certificate of the user device based on the reception of the purchase log. Transmitting an updated public key certificate of the user device issued by the issuing authority to the user device. A content distribution method having a log management configuration, comprising: 12. The procedure using the public key certificate whose expiration date has been set is a mutual authentication process using a public key certificate executed between the user device and the shop server. A content distribution method having the log management configuration according to claim 11. 13. A procedure using a public key certificate with an expiration date set, the method comprising the steps of: applying a digital signature generated by the user device to content purchase request data sent from the user device to the shop server; The log management configuration according to claim 11, wherein the signature verification process is performed by the shop server, and the signature verification process is a process using a public key stored in a public key certificate of the user device. Content delivery method with. 14. At least a part of data transmitted / received between the user device and the shop server includes a falsification check value based on a session key Kses generated at the time of mutual authentication performed between the user device and the shop server. 12. The content distribution method having a log management configuration according to claim 11, wherein the content is transmitted with an ICV) added thereto, and a data tampering check process based on the ICV is executed on the receiving side. 15. A falsification check for a purchase log transmitted to the log collection server based on a session key Kses generated at the time of mutual authentication performed between the user device and the log collection server. The content distribution method having a log management configuration according to claim 11, wherein a value (ICV) is added and transmitted, and a data tampering check process based on the ICV is executed on the log collection server side. 16. The user device generates and adds an electronic signature of the user device to a purchase log transmitted to the log collection server, and the log collection server generates a digital signature of the user device. 12. The content distribution method having a log management configuration according to claim 11, wherein a verification process is performed. 17. The log collection server manages fee distribution information for one or more fee receiving entities of a content fee based on a purchase log received from the user device, and responds to a sales confirmation request from the fee receiving entity. The method according to claim 11, wherein a response process is performed based on the charge distribution information. 18. The shop server manages sales data of contents, and sends the data to the log collection server.
12. The content distribution method having a log management configuration according to claim 11, wherein a process of transmitting all sales data within a predetermined period or sales data for each fee receiving entity is executed. 19. The content purchase request data generated by the user device and transmitted to the shop server includes a transaction I as a content transaction identifier.
D, which is configured as data having a content ID as a content identifier of a purchase request target and including an electronic signature of a user device, wherein the shop server checks the presence or absence of data tampering by executing signature verification of the content purchase request data 12. The method according to claim 11, further comprising: executing a process of generating the sales confirmation data based on the content purchase request data and transmitting the generated data to the user device. 20. A computer / computer for managing distribution of contents.
A program providing medium for providing a computer program to be executed on a system, the computer program comprising: receiving a purchase log generated by a user device in accordance with content purchased by the user device; Executing a verification of the purchase log, accepting a public key certificate update request from the user device on condition that the validity of the reception log is confirmed, and Acquiring, and transmitting to the user equipment, a program providing medium.