WO2003088114A1 - Dispositif et procede de traitement d'informations, support de programme et programme - Google Patents

Dispositif et procede de traitement d'informations, support de programme et programme Download PDF

Info

Publication number
WO2003088114A1
WO2003088114A1 PCT/JP2003/004544 JP0304544W WO03088114A1 WO 2003088114 A1 WO2003088114 A1 WO 2003088114A1 JP 0304544 W JP0304544 W JP 0304544W WO 03088114 A1 WO03088114 A1 WO 03088114A1
Authority
WO
WIPO (PCT)
Prior art keywords
content
usage
key
client
cpu
Prior art date
Application number
PCT/JP2003/004544
Other languages
English (en)
French (fr)
Inventor
Ryuji Ishiguro
Yoji Kawamoto
Yuichi Ezura
Motohiko Nagano
Original Assignee
Sony Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Corporation filed Critical Sony Corporation
Priority to US10/480,315 priority Critical patent/US20050119967A1/en
Priority to KR1020037016281A priority patent/KR100957899B1/ko
Priority to EP03717551A priority patent/EP1496459A4/en
Publication of WO2003088114A1 publication Critical patent/WO2003088114A1/ja

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/03—Credit; Loans; Processing thereof
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2135—Metering
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2137—Time limited access, e.g. to a computer or data

Definitions

  • the present invention relates to an information processing apparatus and method, a program storage medium, and a program, and in particular, it is possible to provide a user with a right to use more finely divided content without putting a burden on the user.
  • FIELD The present invention relates to an information processing apparatus and method, a program storage medium, and a program. Background art
  • networks typified by the Internet have become widespread, and contents such as audio and video have come to be distributed via various networks.
  • the user accesses the server via the network and downloads the content.
  • the content and the right to use the content independent.
  • the user needs to acquire the usage right separately in addition to the content.
  • the content is encrypted and provided to the user, and the key to decrypt the encryption is usually included in the usage right.
  • the content may include a decryption key, and the content may be decrypted using tamper-resistant software or the like without the algorithm being known.
  • the right to use may change depending on the payment status. For example, if you pay 200 yen at the time of registration, you can use up to 10 songs for 1 month, If you pay an additional ⁇ 50 for each additional song, you can own the song (no time limit) and if you pay an additional ⁇ 100, you will be able to checkout the song on your portable device There is a case that can be done. If the content of the usage right is complicated in this way, the client who has obtained the usage right needs to manage by itself the status of the usage right, that is, the current status of the usage right.
  • the present invention has been made in view of such circumstances, the information processing apparatus without imposing a burden on the client, c present invention is to be able to safely manage the usage right,
  • the information processing apparatus may further comprise generation means for generating the usage right from the partial usage condition.
  • the usage conditions received by the receiving means are defined for each usage mode of the corresponding content, and the extraction means generates partial usage conditions including usage conditions for at least one or more usage modes. can do.
  • the first information received by the receiving means may include charging information corresponding to the usage condition.
  • a part using condition is extracted from a receiving step of receiving information including the using condition, and a using condition received by the process of the receiving step.
  • the method comprises the steps of: generating the extraction step; and distributing the partial use conditions generated by the processing of the extraction step to the user.
  • the program of the program storage medium of the present invention comprises: a receiving step of receiving information including use conditions; an extraction step of extracting a part of the use conditions received by the processing of the receiving step; and generating a partial use condition; And Distributing the partial use conditions generated by the processing of the steps to the user.
  • a program according to the present invention includes a receiving step of receiving information including a use condition, an extraction step of extracting a part from the use condition received by the process of the receiving step, and generating a partial use condition, and a processing of the extraction step. And a distribution step of distributing the partial use condition generated by the method to the user.
  • a part of the usage conditions included in the received information is extracted, a partial usage condition is generated, and the generated partial usage condition is distributed to the user.
  • FIG. 1 is a diagram showing the configuration of a content providing system to which the present invention is applied.
  • FIG. 2 is a block diagram showing the configuration of the license server of FIG.
  • FIG. 3 is a flow chart explaining the content download process of the client shown in FIG.
  • FIG. 4 is a flow chart for explaining the content provision processing of the content server of FIG.
  • FIG. 5 is a diagram showing an example of the format in step S 26 in FIG.
  • FIG. 6 is a flowchart for explaining the content reproduction process of the client shown in FIG.
  • FIG. 7 is a flowchart explaining the details of the usage right acquisition process of step S 4 3 of FIG.
  • FIG. 8 shows the structure of the usage right.
  • Fig. 9 is a flow chart explaining the processing for providing the license for the license server shown in Fig. 1.
  • FIG. 10 is a diagram for explaining the configuration of the key.
  • FIG. 11 is a diagram for explaining category nodes.
  • FIG. 12 is a diagram showing a specific example of correspondence between nodes and devices.
  • FIG. 13 is a diagram for explaining the configuration of the enabling key block.
  • FIG. 14 is a diagram for explaining the configuration of the enabling key block.
  • FIG. 15 is a diagram for explaining the use of the enabling key block.
  • FIG. 16 is a diagram showing an example of the format of the enabling key block.
  • Fig.17 is a diagram for explaining the configuration of the tag of activation keep lock.
  • FIG. 18 is a diagram for explaining decryption processing of content using DNK.
  • FIG. 19 is a diagram showing an example of the enabling key block.
  • FIG. 20 is a diagram for explaining assignment of a plurality of contents to one device.
  • FIG. 21 is a flow chart for explaining the usage right provision processing of the content holder server of FIG.
  • FIG. 22 is a flow chart explaining the process of acquiring the right of use of the license server of FIG.
  • FIG. 23 is a diagram showing an example of usage rights provided by the content holder server of FIG.
  • FIG. 24 is a diagram showing an example in which the usage right of FIG. 23 is divided.
  • FIG. 25 is a flowchart showing an example of the usage right division process of step S 3 0 3 of FIG.
  • FIG. 26 is a diagram showing an example of the usage right registered in step S 302 of FIG.
  • FIG. 27 shows an example of the usage right divided from the usage right of FIG.
  • FIG. 28 is a flowchart showing another example of the right-of-use division process of step S 3 0 3 of FIG.
  • FIG. 29 is a diagram showing an example of the usage right registered in the process of step S 3 51 of FIG. 28.
  • FIG. 30 is a diagram for explaining division of usage rights.
  • FIG. 31 is a diagram showing an example of usage rights provided from the content holder server of FIG. 1 to the license server.
  • Figure 32 is a flowchart that illustrates the process of purchasing and upgrading usage rights.
  • FIG. 33 is a diagram showing a display example in the usage right division process.
  • FIG. 34 is a diagram for explaining the management of the use state in the license server of FIG. .
  • FIG. 35 is a diagram for explaining a plurality of protocols.
  • FIG. 36 is a flow chart for explaining the process of acquiring the usage right of the client shown in FIG.
  • FIG. 37 is a flow chart explaining the process of distributing the right of use of the license server shown in FIG.
  • Fig. 38 is a flowchart describing the usage right usage process of the client in Fig. 1.
  • FIG. 39 is a flowchart explaining the usage status update process of the license server of FIG.
  • FIG. 40 is a diagram for explaining the basic description method of Usage Usage.
  • FIG. 41 is a diagram showing an example of a usage rule description format.
  • Figure 42 shows an example of the operator.
  • FIG. 43 shows an example of usage conditions described in the rule description language.
  • BEST MODE FOR CARRYING OUT THE INVENTION FIG. 1 shows the configuration of a content providing system to which the present invention is applied.
  • Clients 1 and 1-2 (hereinafter, these clients are simply referred to as client 1 when it is not necessary to distinguish them individually) are connected to the Internet 2. Although only two clients are shown in this example, Internet 2 is connected with an arbitrary number of clients.
  • a content server 3 for providing content to the client 1 a license server 4 for granting the client 1 the usage right necessary for using the content provided by the content server 3,
  • the charging server 5 for charging the client 1 is connected.
  • the content server 3 and the license server 4 are further connected with a content owner server 6 power S.
  • the content holder server 6 provides the content to the content server 3 and also provides the license server 4 with product information related to the content.
  • An arbitrary number of content servers 3, license servers 4, charging servers 5, and content holders 6 are also provided, and are connected to the Internet 2 as necessary.
  • FIG. 2 shows the configuration of the license server 4.
  • FIG. 2 Here, CPU (Central Processing Unit) 2 1 ⁇ , ROM (Read Only Memory) 2 2 The program stored in 2 or Memory unit 2 8 to RAM
  • (Random Access Memory) 2 Perform various processing according to the program loaded in 3 (Random Access Memory).
  • the timer 20 performs clock operation and supplies time information to the CPU 21.
  • the RAM 23 also stores data necessary for the CPU 21 to execute various processes.
  • the encryption / decryption unit 24 encrypts the content data and decodes the already encrypted content data.
  • the codec unit 25 may use, for example, an ATRAC (Adaptive Transform Acoustic Coding) 3 system.
  • the data is encoded and supplied to the semiconductor memory 44 connected to the drive 30 via the I / O interface 32 and recorded.
  • the codec unit 25 decodes encoded data read from the semiconductor memory 44 via the drive 30.
  • the semiconductor memory 44 is configured of, for example, Memory Stick (trademark).
  • the CPU 2 1, ROM 2 2, RAM 2 3, encryption / decryption unit 2 4, and codec unit 2 5 are mutually connected via a bus 31.
  • An input / output interface 32 is also connected to the bus 31.
  • the input / output interface 32 includes an input unit 26 comprising a keyboard, mouse etc., a display comprising a CRT, LCD etc., an output unit 27 comprising a speaker etc., a storage unit 28 comprising a hard disk etc., a modem, A communication unit 29 comprising a terminal adapter etc. is connected.
  • the communication unit 29 performs communication processing via the Internet 2.
  • the communication unit 29 also performs communication processing of an analog signal or a digital signal with another client.
  • a drive 30 is also connected to the input / output interface 32 as necessary, and a magnetic disk 41, an optical disk 42, a magneto-optical disk 43, a semiconductor memory 44, etc. are appropriately mounted, and read from them.
  • the installed computer program is installed in the storage unit 28 as necessary.
  • the client 1, the content server 3, and the charging server 5 are also configured by the same configuration as the license server 4 shown in FIG. Therefore, in the following description, the configuration of FIG. 2 is also referred to as the configuration of the client 1, the content server 3, the charging server 5, and the like.
  • a PD Portable Device
  • a computer having basically the same configuration as the license server 4 shown in FIG.
  • the process in which the client 1 receives the provision of content from the content server 3 will be described.
  • the CPU 21 controls the communication unit 29 in step S 1, and sends the content server 3 to the content server 3 via the Internet 2.
  • step S2 when the user operates the input unit 26 and designates the content to be provided.
  • the CPU 21 receives this designation information, and from the communication unit 29 via the Internet 2.
  • the content server 3 is notified of the content ID of the designated content, As will be described later with reference to the flowchart of FIG. 4, the content server 3 receiving this notification transmits the content including the encrypted content data. Since the CPU 21 receives the content data via the communication unit 29 in step S3, the encrypted content data is stored in the storage unit 28 in step S4. Supply and store to the hard disk to be configured.
  • the configuration of the license server 4 in FIG. 2 is also referred to as the configuration of the content server 3.
  • step S21 the CPU 21 of the content server 3 waits for access from the Internet 2 via the communication unit 29 from the client 1, and when it is determined that access has been received, the process proceeds to step S22.
  • step S23 the CPU 21 of the content server 3 selects the content data specified by the content ID fetched in the process of step S22 from the content stored in the storage unit 28. read out.
  • step S 24 the CPU 21 supplies the content data read from the storage unit 28 to the encryption / decryption unit 24 and encrypts the content data using the content key Kc. Since the content data stored in the storage unit 28 is already encoded by the codec unit 25 according to the ATRAC 3 system, the encoded content data is to be encrypted. Become.
  • the content data can be stored in the storage unit 28 in a pre-encrypted state.
  • the process of step S24 can be omitted.
  • step S 25 the CPU 21 of the content server 3 uses key information necessary for decrypting the encrypted content in the header constituting the format for transmitting the encrypted content data (see FIG. Add EKB and K EKBC (Kc)) described later with reference to 5. Then, in step S 26, the CPU 21 of the content server 3 formats the content encrypted in the process of step S 24 and the header to which the key information is added in the process of step S 25.
  • the transmitted data is sent from the communication unit 2 9 to the accessing client 1 via internet 1.
  • FIG. 5 shows the format configuration when content is supplied from the content server 3 to the client 1 in this way.
  • this format consists of a header (Header) and data (Data).
  • the header contains content information (Content information), URL (Uniform)
  • Content information includes information such as a content ID (CID) as identification information for identifying content data formatted as data, and a format of a codec of the content.
  • the URL is address information to be accessed when acquiring the usage right necessary to use the content, and in the case of the system of FIG. 1, specifically, the license server required to receive the usage right. It is an address of 4.
  • Content attributes are information related to content, and content attributes include content), record company IDs as identification information for identifying content providers, and identification information for identifying artists. Artist ID etc. are included.
  • the attribute is used to specify the content to which the usage right is targeted.
  • the signature is a digital signature corresponding to the content attribute.
  • Each encryption block consists of an initial vector (IV (Initial Vector)), a seed (Seed), and data obtained by encrypting the content data with the key K 'c.
  • the key K ′ c is constituted by a content key Kc and a value calculated by applying a Seed set by a random number to a hash function, as shown by the following equation.
  • K 'c Hash (Kc, Seed)
  • the initial vector IV and the seed Seed are set to different values for each encryption block.
  • This encryption is performed every 8 bytes by dividing the content data into 8 byte units.
  • the latter 8-byte encryption is performed in CBC (Cipher Block Chaining) mode, which is performed using the results of the former 8-byte encryption.
  • the encryption method is not limited to this.
  • the client 1 can freely acquire content from the content server 3 for free. Therefore, the content itself can be distributed in large quantities.
  • each client 1 when using each acquired content, each client 1 needs to have a usage right that indicates that the usage of that content is permitted. Therefore, with reference to FIG. 6, the process in the case where the client 1 reproduces the content will be described.
  • step S41 the CPU 21 of the client 1 acquires the identification information (CID) of the instructed content by operating the input unit 2 6 by the user.
  • This identification information is made up of, for example, the title of the content, and a number assigned to each stored content.
  • the CPU 21 reads the attributes of the content. These Attributes are described in the header of the content, as shown in Figure 5.
  • step S42 the CPU 21 uses the right to use the client 1 so that the attributes read in step S41 satisfy the contents included in each right. It is determined whether or not it has already been acquired and stored in the storage unit 28. If the usage right has not been acquired yet, the process proceeds to step S43, and the CPU 21 executes the usage right acquisition process. The details of the usage right acquisition process will be described later with reference to the flowchart of FIG.
  • step S42 determines whether the usage right has already been acquired, or if the usage right is acquired as a result of execution of the usage right acquisition processing in step S43.
  • step Proceeding to S 44 the CPU 21 determines whether the acquired usage right is within the validity period. Whether the usage right is within the expiration date or not is determined by comparing the time limit specified as the content of the usage right (see FIG. 8 described later) with the current date and time counted by the timer 20. Be done. Valid use right If it is determined that the time limit has already expired, the CPU 21 proceeds to step S45 and executes the usage right update process.
  • step S44 If it is determined in step S44 that the usage right is still within the expiration date, or if the usage right is updated in step S45, the processing proceeds to step S46, and the CPU 21 stores the storage unit. Read out the usage conditions and usage status (described later) included in the usage right stored in 8 and determine whether the playback conditions are satisfied.
  • step S46 If it is determined in step S46 that the reproduction is permitted based on the usage conditions and usage state included in the usage right, the process proceeds to step S47, and the CPU 21 is encrypted.
  • the content data is read from the storage unit 28 and stored in the RAM 23.
  • step S 48 the CPU 21 supplies the encrypted content data stored in the RAM 23 to the encryption / decryption unit 24 in units of encryption blocks arranged in the data of FIG. 5. Decrypt using the content key Kc.
  • the device node key (DNK) is used to obtain the key K EKBC contained in the EKB (FIG. 5).
  • the content key Kc can be obtained from the data K EKBC (Kc) (Fig. 5) using the key K EKBC .
  • the CPU 21 further supplies the content data decrypted by the encryption / decryption unit 24 to the codec unit 25 for decoding in step S 4 9. Then, the CPU 21 supplies the data decoded by the codec unit 25 to the output unit 27 from the input / output interface 32, performs D / A conversion, and outputs it from the speaker. If it is determined in step S 46 that the reproduction is not permitted based on the conditions of use and the state of use included in the right of use, the process ends without outputting the content.
  • Client 1 registers the leaf ID, DNK (Device Node Key), client 1's private key, public key pair, license server's public key, and certificates of each public key by registering with the license server in advance.
  • the leaf ID indicates the identification information assigned to each client, and DNK decrypts the Content-Kc encrypted by the EKB (Enabling Key Block) contained in the content.
  • EKB Enabling Key Block
  • step S61 the CPU 21 obtains the URL described in the header of the content.
  • this URL is an address to be accessed when acquiring the usage right necessary to use the content. Therefore, in step S62, the CPU 21 accesses the URL acquired in step S61.
  • the communication unit 29 accesses the license server 4 via the Internet 2.
  • the license server 4 transmits a list of usage rights to the client 1, and usage right specification information for specifying usage rights to purchase (use rights required to use the content), and the user. You will be prompted to enter your ID and password (step S 10 2 in Figure 9 below).
  • the CPU 2'1 displays this request on the display unit of the output unit 27. Based on this display, the user operates the input unit 26 to input usage right designation information, a user ID, and a password.
  • the user ID and the password are obtained in advance by the user of the client 1 accessing the license server 4 via the Internet 2.
  • the CPU 21 captures the usage right designation information input from the input unit 26 and captures the user ID and password.
  • the CPU 21 controls the communication unit 29 in step S65, and the input user ID and password are included in usage right designation information and service data (described later).
  • Make the license server 4 send a usage right request including the ID via the Internet 2.
  • the license server 4 transmits the usage right based on the user ID, the password, and the usage right designation information (step S 10 9) or the condition If the above is not satisfied, the usage right is not sent (Step S 1 1 2).
  • step S 66 the CPU 21 determines whether or not the usage right has been transmitted from the license server 4. If the usage right has been transmitted, the process proceeds to step S 6 7 and the usage right is determined. Supply to storage unit 28 and store it.
  • step S 66 If it is determined in step S 66 that the usage right is not sent, the CPU 2
  • step S68 execute error processing. Specifically, since the CPU 21 can not obtain the right to use the content, the content reproduction processing is prohibited.
  • each client 1 can acquire the usage right necessary to use the content and can use the content for the first time.
  • usage right acquisition processing of FIG. 7 can be performed in advance before each user acquires content.
  • the usage right provided to client 1 includes, for example, terms of use, leaf ID and electronic signature, as shown in FIG.
  • the version is information that describes the version of the usage right, with the major version and my "" one version separated by a dot.
  • a profile is described from an integer value in base 10, and is information that specifies restrictions on the method of describing usage rights.
  • the right of use ID is identification information for identifying the right of use described in a hexadecimal constant.
  • the creation date shows 0 o'clock when the usage right was created.
  • Expiration date indicates the expiration date of the usage right. 9 9 9 9 2 3 5 9 9 5 9 seconds
  • the expiration date indicates that there is no limit on the expiration date.
  • the usage conditions include the usage period for which the content can be used based on the usage right, the playback deadline for which the content can be played back based on the usage right, the maximum number of times of playback of the content, and the usage Based on the rights, the number of times the content can be copied (the number of copies allowed), the maximum number of checkouts, and whether or not the content can be recorded on a CD-R '. It includes information indicating the number of times it can be copied to a PD (Portable Device), whether or not the usage right can be transferred, and whether or not it is obligated to take usage logs.
  • PD Portable Device
  • the electronic signature of the use condition is a digital signature corresponding to the use condition.
  • a constant is a constant referred to in the use condition or the use condition.
  • Leaf ID is identification information for identifying the client.
  • Electronic signatures are electronic signatures that correspond to the entire usage right.
  • a certificate is a certificate that contains the license server's public key.
  • the storage unit 28 of the client 1 stores a usage status, which is information indicating the status of the usage right, along with the usage condition of the usage right.
  • the usage status includes the number of times the content has been played based on the corresponding usage rights, the number of times the content has been copied, the number of times the content has been checked out, the date and time of the first playback of the content, the number of times the content has been recorded on CD-R, and other content Alternatively, it contains information indicating historical information etc. regarding usage rights.
  • step S46 in FIG. 6 The determination of the reproduction condition in step S46 in FIG. 6 is performed based on the use condition included in the use right and the use state stored in the storage unit 28 together with the use right. For example, if the number of times the content stored in the use state has been reproduced is less than the maximum number of content reproductions included in the use condition, it is determined that the reproduction condition is satisfied.
  • the usage right provision processing of the license server 4 executed corresponding to the usage right acquisition processing of the client 1 of FIG. 7 will be described.
  • step S101 the CPU 21 of the license server 4 waits until it receives access from the client 1, and when access is received, the process proceeds to step S102 and each client 1 that has made access is It sends a list of usage rights including information on usage rights, and requests transmission of user ID and password, and usage rights specification information.
  • the user ID, password, leaf ID, and usage right designation information (which may be usage right ID) are transmitted from the client 1 in the process of step S 65 in FIG.
  • the CPU 2 1 of the license server 4 receives this via the communication unit 2 9 and executes the process of capturing it, and the CPU 2 1 of the license server 4 executes the communication unit 2 9 in step S 103.
  • the charge server 5 receives a request for credit processing from the license server 4 via the Internet 2, the charge server 5 investigates the past payment history of the user corresponding to the user ID and password, and the user uses the right of use right in the past. Investigate whether there is a record of nonpayment on the value, etc. If there is no such record, send a credit result that permits the granting of the usage right, and if there is a record on nonpayment, etc. Send the result of the disapproval of the license.
  • step S104 the CPU 21 of the license server 4 determines whether the credit result from the charging server 5 is a credit result that permits the grant of the usage right, and grants the usage right. If the user is permitted, the process proceeds to step S 105, and the usage right corresponding to the usage right designation information fetched in the process of step S 102 is stored in the storage unit 28. Take it out of the usage right.
  • the usage right stored in the storage unit 28 has information such as usage right ID, version, creation date, expiration date, etc. described in advance.
  • step S106 the CPU 21 adds the received leaf ID to the usage right. Furthermore, in step S 1 0 7, CPU 2 1 4544
  • Step 17 Select the usage conditions associated with the usage rights selected in step S105.
  • the use condition is added to the use condition prepared in advance, as necessary. Adds the selected terms of use to the right of use.
  • the conditions of use may be pre-added to the right of use.
  • step S108 the CPU 21 signs the usage right with the license server's private key, and attaches a certificate including the license server's public key to the usage right, as shown in FIG. Usage rights for the configuration are generated.
  • step S1009 the CPU 21 of the license server 4 transmits the usage right (having the configuration shown in FIG. 8) from the communication unit 29 to the client 1 via the Internet 2. .
  • step S 110 the CPU 21 of the license server 4 fetches the usage right (including the terms of use and the leaf ID) just transmitted in the process of step S 100 in the process of step S 100. It is stored in the storage unit 2 8 according to the user ID and password. Furthermore, in step S11 1, the CPU 21 executes charging processing. Specifically, the CPU 21 requests the communication server 29 to the charging server 5 to charge the user corresponding to the user ID and password. The charging server 5 executes a charging process for the user based on the request for charging. As described above, when the user does not pay for this charging process, the user can not receive the usage right even if the user subsequently requests the grant of the usage right. It will be.
  • the credit server 5 sends a credit result that disallows the grant of the usage right from the charge server 5, so the process proceeds from step S104 to step S112, and the CPU 21 processes the error.
  • the CPU 21 of the license server 4 transmits a message to the effect that the usage right can not be granted to the client 1 that has accessed by controlling the communication unit 29 and ends the process. .
  • the client 1 since the client 1 can not receive the right of use, it can not use the content (decryption and reproduction of the encrypted content data).
  • devices and keys are managed based on the principle of Broadcast Encryption.
  • the keys are arranged in a hierarchical tree structure, with the lowest leaf corresponding to each device-specific key.
  • the hierarchical structure key management used in the system of the present invention is described in patent publication 2001-352321.
  • keys corresponding to 16 devices from number 0 to number 1 5 are generated.
  • Each key is defined corresponding to each node of the tree structure shown by a circle in the figure. Be done.
  • the root key KR corresponds to the topmost root node
  • the keys K0 and K 1 correspond to the second stage node
  • the keys K0 0 to K 1 correspond to the third stage node.
  • 1 corresponds to the node at the fourth stage
  • keys K0 0 0 to K 1 1 1 correspond to each other.
  • the keys K00 0 0 to K 1 1 1 1 correspond to the leaf (device node) as the lowermost node.
  • the upper key of key K0 0 1 0 and key 00 1 1 is K 0 0 1 and the upper key of key K 000 and key K 00 1 is K 0 0 .
  • the upper keys of the keys K0 0 and K0 1 are K0, and the upper keys of the keys K 0 and K 1 are KR.
  • Keys that use content are managed by keys corresponding to each node of one path from the lowermost device node (leaf) to the uppermost root node. For example, in the device corresponding to the leaf of number 3, the keys for using the content are managed by the keys of the path including keys K 0 0 1 1, K 00 1, K 0 0, K 0, and KR.
  • a key system configured based on the principle of FIG. 10 is used to manage device keys and content keys.
  • the 8 + 24 + 3 two-tier nodes are in a tree structure and A category is corresponded to each node from the lower node to the lower eight stages.
  • a category here means a category such as a category of a device using a semiconductor memory such as a memory stick, a category of a device receiving a digital broadcast, and managing a license to one of the category nodes.
  • This system (called T system) corresponds as a system.
  • the service provider or the service provided by the service provider is corresponded by the key corresponding to the 24 stages of nodes in the hierarchy lower than the node of this T system.
  • this makes it possible to define a 2 24 (approximately 1 6 mega) because mono bis providers or services.
  • the lowermost 32 levels can define 2 32 (about 4 giga) users (or clients 1).
  • the key corresponding to each node on the path from the bottom 32 nodes to the node of T system constitutes the DNK (Device Node Key), and the ID corresponding to the bottom leaf is the leaf ID .
  • the content key that encrypts the content is encrypted by the updated root key KR ', and the update node key of the upper hierarchy is encrypted using the update node key of the nearest lower hierarchy, and the EKB (Fig. 1 3 and FIG. 14 will be described later).
  • the update node key one row higher from the end in E K B is encrypted by the node key or leaf key at the end of E K B and placed in E K B.
  • Client 1 updates the latest upper hierarchy described in the EKB (Fig.13 and Fig.14) distributed with the content data using one of the DNK keys described in the service data.
  • the node key is decrypted, and the key obtained by decryption is used to decrypt the update node key of the further upper hierarchy described in the EKB.
  • the client 1 can obtain the update root key KR ′.
  • Figure 12 shows a concrete example of category classification of hierarchical tree structure.
  • the root key KR 2 3 0 1 is set at the top of the hierarchical tree structure
  • the node key 2 3 0 2 is set at the following middle stage
  • the leaf key 2 3 0 is at the bottom.
  • 3 is It is set.
  • Each device has its own leaf key, a series of node keys from leaf key to root key, and a device node key (DNK) consisting of root key.
  • DNK device node key
  • the category [Memory Stick (trademark)] is set in one node 2 3 0 5 in the M-th stage in Fig. 12 and the nodes connected to this node and the leaf are the various devices using memory status.
  • stages lower than M stages can be set as subcategory nodes 2 3 0 6.
  • the node 2 3 0 7 of the music playback function phone included in the category of playback-only device is set to the node 2 3 0 6 or less of the playback-only device which is a subcategory node, and further, music playback function is added below it.
  • the [PHS] node 2 3 0 8 included in the phone category and the [mobile phone] node 2 3 0 9 are set.
  • categories and subcategories are not only device types, but arbitrary units such as nodes managed by certain manufacturers, content providers, payment institutions, etc., ie processing units, jurisdiction units, or provided service units. These can be generically called “entities” below).
  • entities ie processing units, jurisdiction units, or provided service units.
  • EKB Enable Keep Lock
  • one vertex of a category stage or a subcategory stage is configured by setting one node as a vertex and setting the following nodes as a category defined in the vertex node or a related node of a subcategory. It becomes possible for a maker managing a node, a content provider, etc. to independently create an enabled keep lock (EKB) whose apex is the node, and distribute it to devices belonging to the apex node and below, and does not belong to the apex node. It is possible to perform key update without affecting devices belonging to other categories of nodes.
  • EKB enabled keep lock
  • K (t) a a a indicates that it is an updated key of the generation t of the key K a a a.
  • the key update can be performed, for example, by storing a table composed of block data called an enabling key block (EKB) shown in FIG. 13 via a network or in a recording medium. , 1, 2 is performed by supplying.
  • the enabling key block (EKB) distributes the newly updated key to the devices corresponding to each leaf (lowermost node) configuring the tree structure as shown in FIG. Configured with the encryption key.
  • An Activation Key Block (EKB) is sometimes called a Key Renewal Block (KRB).
  • the enabling key block (EKB) shown in Fig. 13 is configured as block data with a data configuration that can be updated only by devices that need to update node keys.
  • the example of FIG. 13 is block data formed for the purpose of distributing the update node key of generation t in the devices 0, 1 and 2 in the single structure shown in FIG.
  • device 0, device 1 require K (t) 00, K (t) 0, K (t) R as the update node key, and device 2 has K as the update node key.
  • (t) 00 1 K (t) 00, K (t) 0, K (t) R is required.
  • EKB contains multiple encryption keys.
  • the encryption key at the bottom of FIG. 13 is E n c (K 0 0 1 0, K (t) 0 0 1).
  • This is the update node key K (t) 0 0 1 encrypted by the leaf key K 0 0 1 0 possessed by the device 2, and the device 2 decrypts this encryption key by the leaf key K 00 1 0 possessed by itself.
  • the update node key K (t) 0 0 1 can be obtained.
  • the encryption key E nc ((t) 0 0 1, K (t) 00) can be decrypted at the second level from the bottom of FIG.
  • the updated node key K (t) 00 can be obtained.
  • the updated node key K (t) 0 is obtained by sequentially decrypting the encryption key E nc (K (t) 0 0, K (t) 0) in the second row from the top of FIG.
  • the updated root key K (t) R can be obtained by decrypting the encryption key E nc (K (t) 0, K (t) R) in the first row from the top of Fig. 13 using .
  • the node key K0 0 0 is not included in the update target, and nodes 0 and 1 are required as the update node key as K (t) 0 0, K (t) 0, K (t) R Ru.
  • the nodes 0 and 1 use the device keys K0 0 0 0 and K 0 0 0 1 to decrypt the third encryption key E nc (0 0 0, K (t) 0 0) from the top of FIG.
  • the updated node key K (t) 0 0 is obtained by doing the By decrypting the encryption key E nc (K (t) 0 0, K (t) 0), the update node key K (t) 0 is obtained, and the encryption key E nc (the first row from the top of FIG. K (t) 0, K
  • the index in Fig. 13 indicates the absolute address of the leaf key and the node key used as the decryption key for decrypting the encryption key on the right side of the figure.
  • the update node key K (t) 0 0 can be distributed to devices 0, 1 and 2 by using the standardization keep lock (EKB).
  • the EKB shown in Figure 14 can be used, for example, to distribute a new context key shared by a specific group.
  • a new context key K (t) con is required.
  • data E nc (K) obtained by encrypting a new common updated content key K (t) con using K (t) 00 which updated the common node key K 0 0 of the devices 0, 1, 2 and 3 (t) 0 0, K (t) con) Force Distributed with the EKB shown in Figure 14.
  • This distribution enables distribution as data that devices in other groups, such as Device 4, can not decode.
  • Device 0 is processed by the same EKB process as described above, using the EKB at generation t stored in the recording medium and the node key K 00 stored in advance. Generate the node key K (t) 00. In addition, device 0 decrypts the updated content key K (t) con using the decrypted update node key K (t) 0 0, and later only with its own leaf key K 00 0 0 to use it. Encrypt and store.
  • FIG 16 shows an example of the format of the enabling key block (EKB).
  • Version 601 is an identifier that indicates the version of the enabling key block (EKB).
  • the version has a function to identify the latest EKB and a function to show the correspondence with the content.
  • the depth indicates the number of hierarchical levels for the device to which the activated keeplock (EKB) is distributed.
  • the data border 6 0 3 is a pointer indicating the position of the data portion 6 0 6 in the validation keep-open (EKB)
  • the tag pointer 6 04 is the position of the tag portion 6 0 7
  • the signature pointer 6 0 5 Is a pointer indicating the position of the signature 6008.
  • the data unit 606 stores, for example, data obtained by encrypting a node key to be updated.
  • the data unit stores encryption keys and the like related to the updated node key as shown in FIG.
  • the tag unit 600 is a tag indicating the positional relationship between the encrypted node key and leaf key stored in the data unit 606. This tag assignment rule is explained using Fig.18.
  • FIG 17 shows an example of sending the enabling key block (EK B) described above in Figure 13 as data.
  • the data at this time is as shown in the table indicated by B in FIG.
  • the address of the top node included in the encryption key at this time be the top node address.
  • the top node address is KR.
  • data E nc (K (t) 0, K (t) R) on the top row corresponds to the position P 0 shown in the hierarchical tree shown by A in FIG.
  • the data of the next stage is E nc (K (t) 0 0, K (t) 0), which corresponds to the lower left position P 0 0 of the previous data on the tree.
  • tags are set as ⁇ left (L) tag, right (R) tag ⁇ .
  • tags are set for all data, and the data string and tag string shown in C of Figure 17 are configured.
  • the tag is set to indicate where in the corresponding data E n c (Kx X X, Ky y y) tree structure.
  • the key data E nc (Kx XX, Ky yy) ⁇ ⁇ ⁇ stored in the data section 600 is only a list of simply encrypted keys, but the ciphers stored as data by the above-mentioned tag It is possible to determine the position of the conversion key on the tree. For example, using the node / index corresponding to the encrypted data as in the configuration described above with reference to FIG. 15 without using the tag described above.
  • index data indicating a key position the key position can be determined with a small amount of data.
  • the digital signature is executed by, for example, the key management center (license server 4), content provider (content server 3), settlement organization (charging server 5), etc. who issued the enabling key block (EKB). is there. Device that received EKB The chairperson verifies that it is the validating key block (EKB) issued by the valid validating keeplock (EKB) issuer by the signature verification.
  • processing for using the content supplied from the content server 3 is summarized on the basis of the usage right supplied from the license server 4 as shown in FIG.
  • the content is provided from the content server 3 to the client 1, and the license is provided from the license server 4 to the client 1.
  • a combination of service data supplied when the client 1 is registered with the license server 4 and a usage right which is information for permitting the use of a specific content is called a license.
  • the content is encrypted by the content key Kc (Enc (Kc, Content)), and the content key Kc is the key obtained from the update root key KR '(EKB, corresponding to the key K EKBC in FIG. Encrypted)
  • Enc (KR ,, Kc) and EKB are added to the encrypted content and provided to Client 1.
  • the EKB in the example of FIG. 18 includes, for example, an update root key KR that can be decrypted with DNK as shown in FIG. 21 (Enc (DNK, KR,)). Therefore, the client 1 can obtain the updated root key KR, from the EKB by using the DNK included in the service data. Furthermore, it is possible to decrypt the content key Kc from Enc (KR ,: Kc) using the update root key KR 'and to decrypt the content from. Enc (Kc, Content) using the content key Kc D
  • assigning DNK to each device to client 1 makes it possible to revoke individual client 1 according to the principle described with reference to FIG. 10 and FIG.
  • the client 1 associates the service data with the usage right, which makes it possible to prevent unauthorized copying of the usage right.
  • Figure 22 shows an example of this relationship. That is, device D 1 is assigned DNK 1 based on the T system, and can play content 1 including E K B. Similarly, for example, DNK 2 is assigned to this device D 1, and the content 2 ribbed from a CD can be recorded on a memory stick.
  • the device D1 can simultaneously handle the contents distributed by different systems (the T system and the device management system), such as the contents 1 and 2. When assigning a new DNK, you can not do this if you allow the device to correspond to only one DNK, for example by deleting the DM already assigned.
  • independent key management can be performed for each category.
  • the system allows users to purchase keys by downloading DNK to each device or medium when the license server 4 performs registration processing instead of embedding it in the device or medium beforehand. Can be realized.
  • content is used for all purposes regardless of how it is used, regardless of how it is used. It is desirable to be possible. For example, it is desirable that the same content can be used even if different content delivery services or applications are different.
  • each user receives a secret key from the license server 4 as a certificate authority, and The corresponding public key certificates (certificates) are distributed.
  • Each user can use the private key to create a signature and add it to the content to ensure the integrity of the content and to prevent tampering with the content.
  • the client 1 must access the license server 4 and acquire the usage right before using the content.
  • the license server 4 receives access from the client 1, the license server 4 provides usage rights, but it is necessary to obtain product information on the content from the content holder server 6 before that.
  • step S201 the CPU 21 of the content holder server 6 creates product information of the content.
  • step S 202 the CPU 21 transmits the product information created in step S 201 to the license server 4 through the communication unit 29.
  • the license server 4 executes the processing shown in the flowchart of FIG.
  • step S301 the CPU 21 of the license server 4 receives the product information transmitted from the content holder server 6 (sent in the process of step S202 in FIG. 21). To receive.
  • step S302 the CPU 21 supplies the product information received in the process of step S301 to the storage unit 28 for storage. Thereafter, in step S303, the CPU 21 executes processing for dividing the product information (usage conditions) registered in the processing of step S302.
  • the product information transmitted from the content holder server 6 has the content as shown in FIG.
  • the user pays for ⁇ 350 it becomes possible to reproduce the corresponding content without limitation of the number and period.
  • the number of times is not limited. The power period is only one month, and the user is permitted to play the content during that time.
  • the checkout is permitted only three times. If a further consideration of ⁇ 50 is paid, copying is permitted only once, for 10 days. In this case, reproduction at the copy destination does not require payment of compensation (even though the compensation is 0 yen), but the number of times is limited to 10 times, and the period is limited to one day.
  • the license server 4 When the license server 4 receives the product information as shown in FIG. 23 from the content holder server 6, the license server 4 divides this product information as shown in FIG. 24, for example.
  • the product information is divided into three.
  • the first product information is for the case where the user paid for ⁇ 350, and the content of the product information is that the number of times of reproduction and the reproduction period are infinite.
  • the second product information is for the case in which the user paid a fee of ⁇ 150 and the number of replays is infinite, but the replay period is up to YY ⁇ ⁇ DD ⁇ , and the checkout The number of times is up to three times.
  • the consideration is 0 yen, the contents of which prescribes the usage conditions of the copy destination, the number of replays is 10 times, and the regeneration period is 1 day.
  • this third product information is 0 yen, it is distributed along with the second product information.
  • the license server 4 divides the use condition into a plurality of use conditions within the range of the use conditions described in the product information accepted from the content holder server 6, and includes the divided use conditions. As the right of use,
  • the processing shown in FIG. 25 is provided from the content holder server 6, and the usage conditions included in the product information stored in the storage unit 28 of the license server 4 are, for example, the contents as shown in FIG. In this case, from this condition of use, an example of the process of dividing as a condition of use which permits only reproduction is shown.
  • the number of replays is three and the number of checkouts is three. And, The reproduction start date is assumed to be February 1, 1 February 1, and the end date is assumed to be February 28, 2008.
  • step S321 the CPU 21 receives XML from the content holder server 6 and stores the XML of the product information stored in the storage unit 8 (Extensible Markup)
  • step S3222 the CPU 21 determines whether "playback” exists. If “playback” exists, the process proceeds to step S323, and the CPU 21 extracts a period from the time limit option (timespan_id). In the example of Fig. 26, the period from 1st February 1st to 2nd February 2008 is extracted.
  • step S324 the CPU 21 starts playing back date_start (start date) and date_ e nd (end date) of the period extracted in the process of step S323. Assign to the variable resp representing the day and reep representing the renewable end date.
  • the CPU 21 creates divided usage conditions based on the data generated based on the process at step S324. This creates, for example, the conditions of use as shown in Figure 27.
  • the content is made available for a period of 1 st February 1st to 2 st Feb 2008.
  • step S326 the CPU 21 combines the use condition created in the process of step S325, the content condition included in the product information, the use right ID, etc. Create a usage right with a version, an expiration date, etc., and register the generated usage right in storage unit 28.
  • step S 32 2 If it is determined in step S 32 2 that the text “playback” does not exist, the processing of step S 3 2 3 to step S 3 2 6 is skipped.
  • step S 3 2 3 to step S 3 2 6 Next, another example of the condition division processing of step S 3 0 3 of FIG. 22 will be described with reference to the flowchart of FIG.
  • steps S 34 1 to S 3 45 processing similar to that in steps S 3 21 to S 32 5 of FIG. 25 is performed. As a result, as described above, usage rights including usage conditions for regeneration are divided and generated.
  • step S 34 2 If it is determined in step S 34 2 that the element “PLAYBACK” is not found, the processing in steps S 34 3 to S 34 5 is skipped, and the processing is performed in step S 34 6. Go to
  • step S346 the CPU 21 searches for an element of "checkout” from the Rule section (Fig. 26) described in XML.
  • step S 347 the CPU 21 determines whether “checkout” exists or not. If it exists, the process proceeds to step S 3 4 8 and reads the number of times from the Rule part of XML. In the case of the example in Fig. 26, three times are read as the number of times.
  • step S349 the CPU 21 substitutes the number read out in step S348 into a variable recc indicating the maximum number of checkouts. Then, in step S350, the CPU 21 creates divided usage conditions based on the data generated in the process of step S349. In step S351, the CPU 21 generates a usage right including the use conditions created in step S345 or step S350, and executes a process of registering it in the storage unit 28. If it is determined in step S347 that "checkout" does not exist, the processing in steps S348 to S350 is skipped.
  • usage rights including usage conditions for reproduction as shown in FIG. 29 and usage rights including usage conditions for which the number of checks has been made three times are generated.
  • the client 1 is not burdened with handling the large usage conditions. It becomes possible to manage the right of use easily.
  • one usage right is defined which specifies reproduction, checkout and purchase of the content, and this is used as the license server 4 To provide.
  • the license server 4 divides this one usage right into two usage rights: one that can be played back only, and the other that is played back and checked out.
  • the client 1 can obtain the right of reproduction only by paying 10 yen. Then, after that, the client 1 can obtain the usage right to which not only the reproduction but also the checkout right is added by paying an additional 30 yen. That is, Client 1 can upgrade the usage right from playback-only usage rights to usage rights including playback and checkout.
  • FIG. 31 shows an outline of the usage conditions of the product information provided by the license server 4 from the content holder server 6.
  • the Usage Rule ID is 1 and a payment of 10 yen is made
  • a rule that allows playback and a payment of 20 yen will allow playback and checkout.
  • Rules are described.
  • the license server 4 divides one usage condition shown in FIG. 3 1 into a usage condition for reproduction only and a usage condition for permitting reproduction and checkout, and the usage corresponding to each of them. Suppose you have generated a right.
  • step S372 if Client 1 paid 10 yen to license server 4 in step S371, (the detailed description will be omitted, but the specific The charging process is performed by the charging server 5.
  • step S372 the license server 4 gives the client 1 a usage right of reproduction.
  • the process in this case is the same as the purchase process.
  • step S373 the client 1 transmits to the license server 4 information for further permitting payment of ⁇ 20, and in step S344 the leaf ID of the client 1 and the step
  • the license server 4 gives the client 1 the usage right including the contents of playback and checkout. To distribute.
  • This process is an upgrade process.
  • this usage right ID corresponds to the usage right ID provided by the content holder server 6 by the license server 4 shown in FIG.
  • the two usage rights are derived from the usage conditions included in the same product information.
  • FIG. 33 shows a display example when the client 1 acquires the usage right from the license server 4.
  • client 1 receives The ID is sent to the license server 4, and when the usage right has already been acquired, the ID is sent to the license server 4.
  • the license server 4 sends the client 1 a document in which the list of available rights and the corresponding price are described.
  • the CPU 21 of the client 1 When receiving this via the communication unit 29, the CPU 21 of the client 1 outputs it to the monitor of the output unit 27 for display.
  • the usage right held by client 1 changes depending on the value paid by client 1.
  • the client 1 that has accessed license server 4 has acquired the usage right in any state.
  • the license server 4 manages this. Therefore, based on the leaf ID of the client 1 and the ID of the usage right held by the client 1, the CPU 21 of the license server 4 has a menu corresponding to the client 1 who has accessed (content of purchasable rights) Can be displayed.
  • the message "Sato, welcome” is also displayed at the same time. Since the user name is registered when the user 1 who has accessed the client 1 is registered when the user registration process is performed, the user's full name corresponding to the leaf ID is retrieved from the database. It becomes possible to display.
  • cookies it is also possible to use cookies to display names.
  • step S329 when the client 1 performs the purchase procedure of the right of use according to the menu display and processes the payment for the right of use, step S393 is performed.
  • the license server 4 distributes usage right to the client 1 from the license server 4.
  • the content holder server 6 supplies one product information to the license server 4.
  • This product information can be obtained by using Usage Rules 1 that can be obtained for a fee of 200 yen, Usage Rules 2 that can be obtained by paying an additional 100 yen, and pays an additional 50 yen. It consists of Usage Rules 3 that can be acquired by using this method, and Usage Rules 4 that can be acquired by a user who has Usage Rul es 2 by paying an additional 30 yen.
  • the license server 4 Upon acquiring this product information from the content holder server 6, the license server 4 divides Usage Rules 1 to Usage Rules 4. Then, the license server 4 generates and manages a record of the usage right purchase status corresponding to the Usage Rules 1 to the Usage Rules 4 as the status table for each Leaf ID and usage right.
  • states having Usage Rules 1 to Usage Rules 4 are State 1 to State 4, and a state not having any of these is State 0.
  • the client 1 need only purchase any one of Usage Resources 1 to Usage Rules 4 as appropriate.
  • the user of Client 1 can obtain usage rights including Usage Rules 1 by paying ⁇ 200, and by additionally paying ⁇ 100, Usage including Usage Rules 2 You can get the right.
  • the client 1 there are two types of protocols for distributing the usage right from the license server 4 to the client 1: simple purchase protocol and right updating protocol.
  • the simple purchase protocol is a protocol that does not require special authentication
  • the rights update protocol is a protocol that requires special authentication. That is, the rights renewal protocol is a more secure communication environment than the simple purchase protocol.
  • the usage right is simply downloaded from the license server 4 to the client 1.
  • an authentication process is performed in order for the license server 4 to execute a process of updating the usage right of the client 1.
  • step S 4 61 the CPU 21 of the client 1 accesses the license server 4.
  • step S 42 2 the CPU 21 transmits information on the usage right desired by the user to the license server 4 via the communication unit 29 based on a command from the user.
  • step S 44 reads out the leaf ID stored in the storage unit 28, and transmits it to the license server 4 via the communication unit 29.
  • the license server 4 adds the digital signature corresponding to the usage right desired by the client 1 and sends it to the client 1 (step S 4 4 7 in FIG. 3 7). Therefore, in step S 45, the CPU 21 of the client 1 receives the usage right and the digital signature transmitted from the client server 4.
  • step S 4 16 the CPU 2 1 decrypts the digital signature received in step S 4 1 5 with the public key SP of the license server 4. This public key SP of the license server is obtained together with the leaf ID in the registration process and stored in the storage unit 28 (step S 53 in FIG. 6).
  • step S 417 the CPU 21 determines whether the usage right received in the process of step S 4 15 matches the usage right obtained by decrypting the digital signature in the process of step S 4 16. Determine if If the two match, the CPU 21 stores the usage right in the storage unit 28 in step S 4 18 because it is the proper (not tampered with) usage right.
  • step S426 the CPU 21 executes error processing.
  • step S 43 if it is determined in step S 43 that the AKE process has been requested, the process proceeds to step S 4 19, and the CPU 21 executes the AKE process with the license server 4. That is, by this, processing for securing a more secure communication path is executed, and the session key is shared.
  • step S420 the CPU 21 determines whether or not an SAC (Secure Authentication Channel) can be formed (whether a secure communication path can be secured) by AKE processing. If it is determined that the SAC has been formed, the CPU 21 encrypts the leaf ID stored in the storage unit 28 with the session key secured by the AKE processing in step S 41. Communication unit 29 Transmits to license server 4 via Internet 2. In this case, the license key and the digital signature encrypted with the session key are sent from the license server 4 to the client 1 (step S 45 4 in FIG. 37 described later). Therefore, in step S 42 2, the CPU 21 of the client 1 receives the usage right and digital signature encrypted with the session key, and in step S 4 2 3, the encrypted usage right is In step S 4 19, decryption is performed using the session key acquired in the AKE process.
  • SAC Secure Authentication Channel
  • step S 44 2 the CPU 21 decrypts the digital signature received in the process of step S 42 2 with the public key SP of the license server 4.
  • step S425 the CPU 21 agrees that the use right obtained by the process of step S423 and the use right obtained by the process of step S424. Determine if it is or not. If the two match, it is confirmed that the right to use is the right, so the process proceeds to step S 4 18 and the CPU 21 stores the obtained right of use in the storage unit 28. If it is determined in the process of step S 4 25 that the two usage rights do not match, the obtained usage rights may not be correct (for example, they may have been tampered with). As in the case where it is determined that the SAC can not be formed in S420, the process proceeds to step S426 and error processing is performed.
  • the usage right distribution processing of the license server 4 executed corresponding to the usage right acquisition processing of the client 1 will be described with reference to the flowchart in FIG.
  • the CPU 21 of the license server 4 receives an access from the client 1.
  • the CPU 21 receives information on the usage right from the client 1. The information on the usage right has been transmitted from the client 1 by the process of step 3412 in FIG.
  • step S 44 3 the CPU 21 of the license server 4 acquires, from the storage unit 28, information on the usage right corresponding to the service desired by the client 1.
  • step S 44 4 the CPU 21 determines whether the usage right desired by the client 1 is that of the subscription service usage right. Advantage There is no need to communicate in a secure environment, especially if the license is not the subscription service license (if it is for purchasing or listening). At this time, a leaf ID is sent from the client 1 (step S 4 1 4 in FIG. 36). Therefore, in step S 45, the CPU 21 of the license server 4 receives the leaf ID transmitted from the client 1, and inserts the leaf ID into the usage right desired by the client 1.
  • step S 46 the CPU 21 uses the private key of the license server 4 to create a digital signature of the usage right including the leaf ID in step S 45.
  • step S 4 47 the CPU 21 uses the right to purchase the reef ID in the process of step S 4 45 and the digital signature created in the process of step S 4 46. Send to client 1
  • step S 44 determines whether the right of use desired by the client 1 is the use right of the subscription service (not for buying or listening). a more secure environment can be achieved. You need to communicate. Therefore, the processing proceeds to step S448.
  • the CPU 21 requests the client 1 to perform AKE processing, and executes AKE processing.
  • step S 4 49 when the CPU 2 1 can form a c SAC to determine whether or not the SAC can be formed, the process proceeds to step S 4 51, and the CPU 2 1 requests the client 1 to request. Add Usage Status to the right to use.
  • step S 42 2 the CPU 21 inserts the leaf ID into the usage right desired by the client 1 and encrypts it with the session key obtained in the AKE process in step S 4 48.
  • step S 45 3 CPU 21 uses its own private key to import the leaf ID in the process of step S 45 2 and digitally sign the usage right encrypted with the session key.
  • step S 45 4 the CPU 21 controls the use right encrypted with the session key in the process of step S 45 2 and the digital signature created in the process of step S 45 3 as a client. Send to 1.
  • step S449 If it is determined in step S449 that the SAC can not be formed, the secure communication path can not be secured. Therefore, the process proceeds to step S450 to execute error processing.
  • the usage right is not distributed to the client 1.
  • Users who do not want to distribute the usage rights in a more secure state do not need to have the function to do so, and it is possible to distribute usage rights without overburdening the users.
  • users who wish to acquire usage rights in a secure environment can be distributed more securely. As a result, it is prevented that the right of use is stolen by a third party.
  • the client 1 that has acquired the content and the usage right executes processing to use (for example, reproduce) the content based on the usage right.
  • Step S 41 1 In the step S 4 1, the CPU 21 of the client 1 accesses the license server 4. At step S 4 72, the CPU 21 executes AKE processing with the license server 4.
  • step S 4 7 3 the CPU 21 determines whether or not the SAC can be formed. If the SAC can be formed, the license server 4 requests transmission of the usage status, leaf ID, and content information. It will come (Step S 4 9 5 in Figure 3 9 described later).
  • the CPU 21 of the client 1 receives this request from the license server 4 in step S 4 75.
  • This request is AKE in step S472. It is encrypted with the session key obtained in the process. Therefore, the CPU 21 decrypts this request using the session key obtained by the AKE process in step S 42 2.
  • the updated usage status is transmitted from the license server 4 with the session key encrypted (step S 4 9 8 in FIG. 39).
  • step S 47 7 the CPU 21 of the client 1 receives the updated usage status transmitted from the license server 4, decrypts it with the session key, and stores it in the storage unit 28. For example, if the usage right includes the usage count condition, Client 1 will play back the content, so the usage count will be updated to the value incremented once. Then, in step S 4 7 8, the CPU 21 executes a process of reproducing the content.
  • the license server 4 can appropriately prohibit the use of the content or provide a flexible service to a predetermined user by appropriately rewriting the use state as necessary.
  • the license server 4 can control the usage status of the usage right held by the client 1, so that the license server 4 can appropriately increase or decrease the number of times of usage permission, invalidate each content, stop the service itself, etc. It will be possible to do. If it is determined in step S 4 73 that an SAC can not be formed, the process proceeds to step S 4 7 4 and error processing is performed.
  • step S 49 the CPU 21 of the license server 4 receives an access from the client 1.
  • step S 4 92 the CPU 2 1 executes AKE processing with the client 1.
  • step S 43 3 the CPU 2 1 determines whether or not an SAC has been formed as a result of the AKE processing.
  • step S 495 the process proceeds to step S 495, and the CPU 21 requests the client 1 to transmit the usage status, leaf ID, and content information.
  • This request is sent to the client 1 encrypted with the session key obtained in the AKE process of step S 42 2.
  • this request is received by the client 1 in the process of step S 4 75, and the process corresponding to the request is transmitted from the client 1 in the process of step S 4 7 6.
  • step S 496 the CPU 21 of the license server 4 receives the use status, leaf data D and content information transmitted from the client 1. Since these pieces of information are encrypted with the session key, the CPU 21 decrypts these pieces of information using the session key obtained by the AKE process of step S 42 2.
  • the CPU 21 updates the usage status sent from the client 1 based on the content information. For example, if the content is to be used from now on, change the usage count to a value that has been incremented only once. Alternatively, if the content is to be disabled thereafter, the CPU 21 changes the usage count to the number of times that it can no longer be used.
  • step S 4 9 8 the CPU 21 encrypts the use state updated in the process of step S 4 9 7 with the session key, and transmits the encrypted state to the client 1.
  • This usage status is received at the client 1 at step S 4 7 7 as described above.
  • step S 493 If it is determined in the process of step S 493 that no SAC can be formed, the process proceeds to step S 4 9 4 and error processing is performed.
  • error processing When describing usage conditions, if describing only using flags and values, it is necessary for client 1 to know all the meanings of the values. This makes it difficult for the license server 4 to add condition items.
  • the usage conditions of the content are related to the relational expression and By describing a conditional expression consisting only of a logical expression, it is not necessary to prescribe the format of each item in the client 1 in advance, and it is possible to cope with the description of various usage conditions. Therefore, it becomes possible to describe the conditions of use regardless of the implementation in the client 1.
  • Usage Rules specify the conditions of use of content and, as mentioned above, are included in the Usage Right purchased by the user (Client 1). Among the things that can be specified in Usage Rules are the following.
  • One Usage Rule is described in a format as shown in FIG.
  • One Usage Rule is a domain_id described at the top, which specifies the domain to which it applies.
  • the following rules are defined in ' ⁇ ' ⁇ ⁇ ⁇ ' ⁇ ', among which are the three sections of the Noble section, the invariables section, and the overhead part.
  • the Nore section can describe multiple domain-rules at the beginning of ' ⁇ ' ⁇ ⁇ ⁇ , ⁇ '.
  • the invariables section is the part that follows the rules section and begins with a single word, invariables :.
  • Overhead part is the invariables section. 'over one head-part:' match by here, domain-id is a name indicating a domain, which is one of the following strings: .
  • the renderer domain is a category of usage types such as content playback and display
  • the ripper domain is a category of usage type of reading of CD contents
  • the burner domain is a category of usage type of recording of contents onto CD-R
  • the drm domain is all The categories of usage forms are respectively represented.
  • a rule number can be specified in the following format before each rule.
  • the conditional expression is Chars Code to refer to the state variable or constant of each domain.
  • the comparison operation is applied to (C C).
  • the description example is as follows, for example.
  • the invariables section describes various constants, and defines values in the Chars Code in the following format.
  • the overhead part is a part that describes the rules unique to each domain.
  • Char Code may be defined in usage rights, contents, usage status etc. in addition to being defined in the invariables section of Usage Rules.
  • FIG. 1 An example described in the above rule description language is shown in FIG. 1
  • any two or more of the content server 3, the license server 4, the charging server 5, and the content holder server 6 described above can be substantially integrated into one server as needed.
  • the key information for decrypting the encrypted content is included in the content
  • the usage right includes the key information, or the key information included in the content and the usage right is included. It may be made decipherable by combining with the key information to be obtained.
  • the client to which the present invention is applied can be a PDA (Personal Digital Assistant), a cellular phone, a game terminal, etc. in addition to a so-called personal computer.
  • PDA Personal Digital Assistant
  • This recording medium is a magnetic disk 41 (including a flexible disk) on which a program is recorded, which is distributed to provide the program to the user separately from the main body of the device.
  • Optical disc 4 2 Compact Disc-Read Only Memory (CD-ROM), including DVD (Digital Versatile Disc), Magneto-optical disc 4 3 (including MD (Mini-Di sk (trademark)), or semiconductor)
  • CD-ROM Compact Disc-Read Only Memory
  • DVD Digital Versatile Disc
  • Magneto-optical disc 4 3 including MD (Mini-Di sk (trademark)), or semiconductor
  • the program is stored in R0M 22 and storage unit 28. It is configured with the included hard disk etc.
  • the steps for describing the program to be recorded on the recording medium are not limited to processing that is performed chronologically in the order described, but not necessarily parallel processing. It also includes processes that are executed intentionally or individually.
  • programs that execute security-related processes be encrypted in order to prevent their analysis.
  • the program can be configured as a tamper-resistant module.
  • the content condition of the attribute of the content and the usage right is used to specify the usage right necessary to use the content, but the present invention is not limited to this.
  • the content may include the usage right ID of the usage right necessary to use the content, and in this case, if the content is specified, the usage right necessary to use it is uniquely determined. Therefore, there is no need to perform processing to determine the matching between the two.
  • usage rights can be distributed to users.
  • it is possible to distribute to users the usage rights divided in detail.
  • it is possible to distribute usage rights without putting heavy burden on users.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Technology Law (AREA)
  • Strategic Management (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Software Systems (AREA)
  • Multimedia (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Storage Device Security (AREA)

Description

明細書
情報処理装置および方法、 プログラム格納媒体、 並びにプログラム 技術分野
本発明は、 情報処理装置および方法、 プログラム格納媒体、 並びにプログラム に関し、 特に、 ユーザに負担をかけることなく、 より細かく分割された内容の使 用権をユーザに提供することができるようにした、 情報処理装置および方法、 プ 口グラム格納媒体、 並びにプログラムに関する。 背景技術
最近、 インターネットに代表されるネットワークが普及し 各種のネットヮー クを介して、 オーディオ、 あるいはビデオなどのコンテンツが配布されるように なってきた。 ユーザ （クライアント） は、 ネット ークを介してサーバにァクセ スし、 コンテンッをダウンロードする。
また、 コンテンツとそのコンテンツを利用する利用権を独立のものとすること が提案されている。 このような場合、 ユーザは、 コンテンツ以外に、 その利用権 を別途取得する必要がある。 そして、 通常、 コンテンツは暗号化されて、 ユーザ に提供され、 その暗号を解く鍵は、 通常、 その利用権に含まれている。 あるいは コンテンッに復号鍵が含まれていて、 コンテンッの復号処理がタンパ一レジスタ ントソフトウエア等でそのアルゴリズムを知られることなく行われる構成とする ものもある。
このようにすることで、 コンテンツをより容易に配布することが可能となる。 ところで、 利用権は、 支払い状況に応じて、 内容が変化するような場合がある, 例えば、 登録時、 2 0 0円を支払うと、 1 0曲まで 1ヶ月間利用することができ るが、 追加で 1曲毎に 5 0円を支払うと、 その曲を所有することができ （期間の 制限がなくなり） 、 さらに追加で 1 0 0円を支払うと、 ポータブル機器にその曲 をチェックァゥトすることができるといった内容の場合がある。 利用権の内容がこのように複雑である場合、 利用権を取得したクライアントは、 その利用権の状態がいずれの状態にあるのかを、 自分自身で管理する必要がある すなわち、 その利用権の現在の状態が 2 0 0円を支払っただけの状態であるのか、 その後、 さらに 5 0円を 1曲毎に支払ったのであるのか、 支払ったのであるとす ると、 どの曲に対して支払ったのであるのか、 さらには、 その後、 追加で 1 0 0 円を支払い、 ポータブル機器にチェックァゥトすることができる状態にあるのか といったことを、 クライアント自身が管理している必要がある。 クライアントに このような管理を行なわせることは、 クライアントにとって大きな負荷となる。 また、 クライアントにこのような管理を行わせると、 悪意のユーザが利用権を 改竄する恐れがあり、 安全性の面からも好ましくない。 発明の開示
本発明は、 このような状況に鑑みてなされたものであり、 クライアントに負担 をかけることなく、 利用権を安全に管理することができるようにするものである c 本発明の情報処理装置は、 使用条件を含む情報を受信する受信手段と、 受信手 段により受信された使用条件から一部を抽出し、 部分使用条件を生成する抽出手 段と、 抽出手段により生成された部分使用条件をユーザに配布する配布手段とを 備えることを特徴とする。
前記部分使用条件から前記利用権を生成する生成手段をさらに備えることがで さる。
前記受信手段が受信する前記使用条件は、 対応するコンテンツの利用形態毎に 定義されており、 前記抽出手段は少なくとも 1つ以上の前記利用形態に関する使 用条件を含む部分使用条件を生成するようにすることができる。
前記受信手段によって受信される前記第 1の情報は、 前記使用条件に対応する 課金情報を含むようにすることができる。 ·
本発明の情報処理方法は、 使用条件を含む情報を受信する受信ステップと、 受 信ステップの処理により受信された使用条件から一部を抽出し、 部分使用条件を 生成する抽出ステップと、 抽出ステップの処理により生成された部分使用条件を ユーザに配布する配布ステップとを含むことを特徴とする。
本発明のプログラム格納媒体のプログラムは、 使用条件を含む情報を受信する 受信ステップと、 受信ステップの処理により受信された使用条件から一部を抽出 し、 部分使用条件を生成する抽出ステップと、 抽出ステップの処理により生成さ れた部分使用条件をユーザに配布する配布ステップとを含むことを特徴とする。 本発明のプログラムは、 使用条件を含む情報を受信する受信ステップと、 受信 ステップの処理により受信された使用条件から一部を抽出し、 部分使用条件を生 成する抽出ステップと、 抽出ステップの処理により生成された部分使用条件をュ 一ザに配布する配布ステップとをコンピュータに実行させることを特徴とする。 本発明においては、 受信された情報に含まれる使用条件から一部が抽出され、 部分使用条件が生成され、 生成された部分使用条件がユーザに配布される。 図面の簡単な説明
図 1は、 本発明を適用したコンテンツ提供システムの構成を示す図である。 図 2は、 図 1のライセンスサーバの構成を示すブロック図である。
図 3は、 図 1のクライアントのコンテンツのダウンロード処理を説明するフロ 一チヤ一トである。
図 4は、 図 1のコンテンツサーバのコンテンツ提供処理を説明するフローチヤ ートである。
図 5は、 図 4のステップ S 2 6におけるフォーマツトの例を示す図である。 図 6は、 図 1のクライアントのコンテンツ再生処理を説明するフローチヤ一ト である。
図 7は、 図 6のステップ S 4 3の利用権取得処理の詳細を説明するフローチヤ ートである。
図 8は、 利用権の構成を示す図である。 JP03/04544
4 図 9は、 図 1のライセンスサーバの利用権提供の処理を説明するフローチヤ一 トである。
図 1 0は、 キーの構成を説明する図である。
図 1 1は、 カテゴリノードを説明する図である。
図 1 2は、 ノードとデバイスの対応の具体例を示す図である。
図 1 3は、 有効化キーブロックの構成を説明する図である。
図 1 4は、 有効化キーブロックの構成を説明する図である。
図 1 5は、 有効化キーブロックの利用を説明する図である。
図 1 6は、 有効化キーブロックのフォーマットの例を示す図である。
図 1 7は、 有効化キープロックのタグの構成を説明する図である。
図 1 8は、 DNKを用いたコンテンツの復号処理を説明する図である。
図 1 9は、 有効化キーブロックの例を示す図である。
図 2 0は、 複数のコンテンツの 1つのデバイスに対する割り当てを説明する図 である。
ライセンスのカテゴリを説明する図である。
図 2 1は、 図 1のコンテンツホルダサーバの利用権提供処理を説明するフロー チヤ一トである。
図 2 2は、 図 1のライセンスサーバの利用権取得処理を説明するフローチヤ一 トである。
図 2 3は、 図 1のコンテンツホルダサーバが提供する利用権の例を示す図であ る。
図 2 4は、 図 2 3の利用権を分割した例を示す図である。
図 2 5は、 図 2 2のステップ S 3 0 3の利用権分割処理の例を示すフローチヤ 一トである。
図 2 6は、 図 2 2のステップ S 3 0 2において登録される利用権の例を示す図 、、ある。
図 2 7は、 図 2 6の利用権から分割された利用権の例を示す図である。 図 2 8は、 図 2 2のステップ S 3 0 3の利用権分割処理の他の例を示すフロー チヤ一トである。
図 2 9は、 図 2 8のステップ S 3 5 1の処理で登録される利用権の例を示す図 である。
図 3 0は、 利用権の分割を説明する図である。
図 3 1は、 図 1のコンテンッホルダサーバからライセンスサーバに提供される 利用権の例を示す図である。
図 3 2は、 利用権の購入とアップグレードの処理を説明するフローチャートで ある。
図 3 3は、 利用権分割の処理における表示例を示す図である。
図 3 4は、 図 1のライセンスサーバにおける使用状態の管理を説明する図であ る。 .
図 3 5は、 複数のプロトコルを説明する図である。
図 3 6は、 図 1のクライアントの利用権取得処理を説明するフローチャートで ある。
図 3 7は、 図 1のライセンスサーバの利用権配布処理を説明するフローチヤ一 トである。
図 3 8は、 図 1のクライアントの利用権使用処理を説明するフローチャートで める。
図 3 9は、 図 1のライセンスサーバの使用状態更新処理を説明するフローチヤ ートである。
図 4 0は、 Usage Rul esの基本的な記述方法を説明する図である。
図 4 1は、 UsageRuleの記述形式の例を示す図である。
図 4 2は、 演算子の例を示す図である。
図 4 3は、 ルール記述言語で記載された使用条件の例を示す図である。 発明を実施するための最良の形態 図 1は、 本発明を適用したコンテンツ提供システムの構成を示している。 イン ターネット 2には、 クライアント 1一 1， 1 - 2 (以下、 これらのクライアント を個々に区別する必要がない場合、 単にクライアント 1と称する） が接続されて いる。 この例においては、 クライアントが 2台のみ示されているが、 インターネ ット 2には、 任意の台数のクライアントが接続される。
また、 インターネット 2には、 クライアント 1に対してコンテンツを提供する コンテンツサーバ 3、 コンテンツサーバ 3が提供するコンテンツを利用するのに 必要な利用権をクライアント 1に対して付与するライセンスサーバ 4、 およぴク ライアント 1が利用権を受け取った場合に、 そのクライアント 1に対して課金処 理を行う課金サーバ 5が接続されている。
コンテンツサーバ 3とライセンスサーバ 4には、 コンテンツホノレダサーパ 6力 S さらに接続されている。 コンテンツホルダサーバ 6は、 コンテンツサーバ 3に対- してコンテンツを提供するとともに、 ライセンスサーバ 4に対してコンテンツに 関するプロダクト情報を提供する。
これらのコンテンツサーバ 3、 ライセンスサーバ 4、 課金サーバ 5、 およぴコ ンテンッホルダ 6も、 任意の台数設けられ、 必要に応じてインターネット 2に接 続される。
図 2はライセンスサーバ 4の構成を表している。
図 2 こぉレヽて、 CPU (Central Processing Unit) 2 1 ίま、 ROM (Read Only Memory) 2 2に記憶されているプログラム、 または記憶部 2 8から RAM
(Random Access Memory) 2 3にロードされたプログラムに従って各種の処理 を実行する。 タイマ 2 0は、 計時動作を行い、 時刻情報を CPU 2 1に供給する。 RAM 2 3にはまた、 CPU 2 1が各種の処理を実行する上において必要なデータな ども適宜記憶される。
暗号化復号部 2 4は、 コンテンツデータを暗号化するとともに、 既に暗号化さ れているコンテンツデータを復号する処理を行う。 コーデック部 2 5は、 例えば、 ATRAC (Adapt ive Transform Acoustic Coding) 3方式などでコ タをェンコードし、 入出力インタフェース 3 2を介してドライブ 3 0に接続され ている半導体メモリ 4 4に供給し、 記録させる。 あるいはまた、 コーデック部 2 5は、 ドライブ 3 0を介して半導体メモリ 4 4より読み出した、 エンコードされ ているデータをデコードする。 ·
半導体メモリ 4 4は、 例えば、 メモリースティック （商標） などにより構成さ れる。
CPU 2 1、 ROM 2 2 , RAM 2 3、 暗号化復号部 2 4、 およびコーデック部 2 5は、 バス 3 1を介して相互に接続されている。 このバス 3 1にはまた、 入出力インタ フェース 3 2も接続されている。
入出力インタフェース 3 2には、 キーボード、 マウスなどよりなる入力部 2 6、 CRT, LCD などよりなるディスプレイ、 並びにスピーカなどよりなる出力部 2 7、 ハードディスクなどより構成される記憶部 2 8、 モデム、 ターミナルアダプタな どより構成される通信部 2 9が接続されている。 通信部 2 9は、 インターネット 2を介しての通信処理を行う。 通信部 2 9はまた、 他のクライアントとの間で、 アナ口グ信号またはデジタル信号の通信処理を行う。
入出力インタフェース 3 2にはまた、 必要に応じてドライブ 3 0が接続され、 磁気ディスク 4 1、 光ディスク 4 2、 光磁気ディスク 4 3、 或いは半導体メモリ 4 4などが適宜装着され、 それらから読み出されたコンピュータプログラムが、 必要に応じて記憶部 2 8にインス トールされる。
なお、 図示は省略するが、 クライアント 1、 コンテンツサーバ 3、 課金サーバ 5も、 図 2に示したライセンスサーバ 4と基本的に同様の構成を有するコンビュ ータにより構成される。 そこで、 以下の説明においては、 図 2の構成は、 クライ アント 1、 コンテンツサーバ 3、 課金サーバ 5などの構成としても引用される。 なお、 図示は省略するが、 PD (Portable Device) も、 図 2に示したライセン スサーバ 4と基本的に同様の構成を有するコンピュータにより構成される。
次に、 図 3のフローチャートを参照して、 クライアント 1がコンテンツサーバ 3からコンテンツの提供を受ける処理について説明する。 ユーザが、 力部 2 6を操作することでコンテンツサーバ 3に対するアクセス を指令すると、 CPU 2 1は、 ステップ S 1において、 通信部 2 9を制御し、 イン ターネット 2を介してコンテンツサーバ 3にアクセスさせる。 ステップ S 2にお いて、 ユーザが、 入力部 2 6を操作して、 提供を受けるコンテンツを指定すると. CPU 2 1は、 この指定情報を受け取り、 通信部 2 9から、 インターネット 2を介 してコンテンツサーバ 3に、 指定されたコンテンツのコンテンツ ID を通知する, 図 4のフローチャートを参照して後述するように、 この通知を受けたコンテンツ サーバ 3は、 暗号化されたコンテンツデータを含むコンテンツを送信してくるの で、 ステップ S 3において、 CPU 2 1は、 通信部 2 9を介して、 このコンテンツ データを受信すると、 ステップ S 4において、 その暗号化されているコンテンツ データを記憶部 2 8を構成するハードディスクに供給し、 記憶させる。
次に、 図 4のフローチャートを参照して、 クライアント 1の以上の処理に対応 するコンテンツサーバ 3のコンテンツ提供処理について説明する。 なお、 以下の 説明において、 図 2のライセンスサーバ 4の構成は、 コンテンツサーバ 3の構成 としても引用される。
ステップ S 2 1において、 コンテンツサーバ 3の CPU 2 1は、 インターネット 2から通信部 2 9を介してクライアント 1よりアクセスを受けるまで待機し、 ァ クセスを受けたと判定したとき、 ステップ S 2 2に進み、 クライアント 1から送 信されてきたコンテンツ IDを取り込む。 このコンテンツ IDは、 クライアント 1力 図 3のステップ S 2において通知してきた情報である。
ステップ S 2 3において、 コンテンツサーバ 3の CPU 2 1は、 記憶部 2 8に記 憶されているコンテンツの中から、 ステップ S 2 2の処理で取り込まれたコンテ ンッ IDで指定されたコンテンツデータを読み出す。 CPU 2 1は、 ステップ S 2 4において、 記憶部 2 8から読み出されたコンテンツデータを、 暗号化復号部 2 4に供給し、 コンテンツキー Kcを用いて暗号化させる。 記憶部 2 8に記億されているコンテンツデータは、 コーデック部 2 5により、 既に ATRAC 3方式によりェンコ一ドされているので、 このェンコ一ドされている コンテンッデータが暗号化されることになる。
なお、 もちろん、 記憶部 2 8に予め暗号化した状態でコンテンツデータを記憶 させることができる。 この場合には、 ステップ S 2 4の処理は省略することが可 能である。
次に、 ステップ S 2 5において、 コンテンツサーバ 3の CPU 2 1は、 暗号化し たコンテンツデータを伝送するフォーマツトを構成するヘッダに、 暗号化されて いるコンテンツを復号するのに必要なキー情報 （図 5を参照して後述する EKB と KEKBC (Kc) ) を付加する。 そして、 ステップ S 2 6において、 コンテンツサ ーパ 3の CPU 2 1は、 ステップ S 2 4の処理で暗号化したコンテンツと、 ステツ プ S 2 5の処理でキー情報を付加したヘッダとをフォーマツト化したデータを、 通信部 2 9から、 ィンタ一ネット 2を介して、 アクセスしてきたクライアント 1 に送信する。
図 5は、 このようにして、 コンテンツサーバ 3からクライアント 1にコンテン ッが供給される場合のフォーマツトの構成を表している。 同図に示されるように このフォーマットは、 ヘッダ （Header) とデータ （Data) とにより構成される, ヘッダには、 コンテンツ情報 (Content informat ion) 、 URL (Uniform
Resource Locator) , イネ一プリングキープロック （有効化キーブロック）
(EKB (Enabl ing Key Block) ) 、 EKBから生成されたキー KEKBCを用いて暗号化 されたコンテンツキー Kc としてのデータ KEKBC (Kc) 、 コンテンツの属性
(Attributes) 、 および署名 （Signatures) が配置されている。 なお、 EKBに ついては、 図 1 3および図 1 4を参照して後述する。
コンテンツ情報には、 データとしてフォーマツト化されているコンテンツデー タを識別するための識別情報としてのコンテンツ ID (CID) 、 そのコンテンツの コーデックの方式などの情報が含まれている。 URLは、 そのコンテンツを利用するために必要な利用権を取得するときァクセ スするアドレス情報であり、 図 1のシステムの場合、 具体的には、 利用権を受け るために必要なラィセンスサーバ 4のアドレスである。
コンテンツの属性は、 コンテンツの関する情報であり、 コンテンツの属性には、 コンテンツお)、 コンテンツの提供者を識別するための識別情報としてのレコー ドカンパニー ID、 アーティストを識別するための識別情報としてのアーティス ト IDなどが含まれる。 本実施の形態では、 属性は利用権の対象となるコンテン ッを特定するために用いられる。
署名は、 コンテンツの属性に対応する電子署名である。
データは、 任意の数の暗号化ブロック （Encryption Block) により構成され る。 各暗号化プロックは、 イニシャルべクトル （IV (Initial Vector) ) 、 シ ード （Seed) 、 およびコンテンツデータをキー K' cで暗号化したデータ
E o (data)により構成されている。
キー K' cは、 次式により示されるように、 コンテンツキー Kcと、 乱数で設定 される値 Seedをハッシュ関数に適用して演算された値により構成される。
K' c = Hash (Kc, Seed)
イニシャルべクトル IVとシード Seedは、 各暗号化プロック毎に異なる値に 設定される。
この暗号化は、 コンテンツのデータを 8バイト単位で区分して、 8バイ ト毎に 行われる。 後段の 8バイトの暗号化は、 前段の 8バイトの暗号化の結果を利用し て行われる CBC (Cipher Block Chaining) モードで行われる。
CBCモードの場合、 最初の 8バイトのコンテンツデータを暗号化するとき、 そ の前段の 8バイ トの暗号化結果が存在しないため、 最初の 8バイトのコンテンツ データを暗号化するときは、 イニシャルべク トル IVを初期値として暗号化が行 われる。
この CBCモードによる暗号化を行うことで、 1つの暗号化プロックが解読さ れたとしても、 その影響が、 他の暗号化ブロックにおよぶことが抑制される。 また、 暗号方式についてはこれに限らない。
以上のようにして、 クライアント 1は、 コンテンツサーバ 3からコンテンツを 無料で、 自由に取得することができる。 従って、 コンテンツそのものは、 大量に 配布することが可能となる。
しかしながら、 各クライアント 1は、 取得したコンテンツを利用するとき、 そ のコンテンツの利用が許可されていることを示す利用権を保持している必要があ る。 そこで、 図 6を参照して、 クライアント 1がコンテンツを再生する場合の処 理について説明する。
ステップ S 4 1において、 クライアント 1の CPU 2 1は、 ユーザが入力部 2 6 を操作することで指示したコンテンツの識別情報 （CID) を取得する。 この識別 情報は、 例えば、 コンテンツのタイ トルや、 記憶されている各コンテンツ毎に付 与されている番号などにより構成される。
そして、 CPU 2 1は、 コンテンツが指示されると、 そのコンテンツの属性 (Attributes) を読み取る。 この属性 (Attributes) は、 図 5に示されるよう に、 コンテンツのヘッダに記述されているものである。
次に、 ステップ S 4 2に進み、 CPU 2 1は、 ステップ S 4 1で読み取られた属 性 （Attributes) が各利用権に含まれているコンテンツ条件を満たすような利 用権が、 クライアント 1により既に取得され、 記憶部 2 8に記憶されているか否 かを判定する。 まだ、 利用権が取得されていない場合には、 ステップ S 4 3に進 み、 CPU 2 1は、 利用権取得処理を実行する。 この利用権取得処理の詳細は、 図 7のフローチャートを参照して後述する。
ステップ S 4 2において、 利用権が既に取得されていると判定された場合、 ま たは、 ステップ S 4 3において、 利用権取得処理が実行された結果、 利用権が取 得された場合、 ステップ S 4 4に進み、 CPU 2 1は、 取得されている利用権は有 効期限内のものであるか否かを判定する。 利用権が有効期限内のものであるか否 かは、 利用権の内容として規定されている期限 （後述する図 8参照） と、 タイマ 2 0により計時されている現在日時と比較することで判断される。 利用権の有効 期限が既に満了していると判定された場合、 CPU 2 1は、 ステップ S 4 5に進み、 利用権更新処理を実行する。
ステップ S 4 4において、 利用権はまだ有効期限内であると判定された場合、 または、 ステップ S 4 5において、 利用権が更新された場合、 ステップ S 4 6に 進み、 CPU 2 1は記憶部 2 8に記憶されている、 利用権に含まれる使用条件及び 使用状態 （後述する） を読み出し、 再生の条件を満たしているかどうかを判定す る。
ステップ S 4 6において、 利用権に含まれる使用条件、 及び使用状態に基づき、 再生が許可されると判断された場合には、 ステップ S 4 7に進み、 CPU 2 1は、 暗号化されているコンテンツデータを記憶部 2 8から読み出し、 RAM 2 3に格納 させる。 そして、 ステップ S 4 8において、 CPU 2 1は、 RAM 2 3に記憶された 暗号化コンテンツデータを、 図 5のデータに配置されている暗号化プロック単位 で、 暗号化復号部 2 4に供給し、 コンテンツキー Kcを用いて復号させる。
コンテンツキー Kcを得る方法の具体例は、 図 1 3および図 1 4を参照して後 述するが、 デバイスノードキー （DNK) を用いて、 EKB (図 5 ) に含まれるキー KEKBCを得ることができ、 そのキー KEKBCを用いて、 データ KEKBC (Kc) (図 5 ) から、 コンテンツキー Kcを得ることができる。
CPU 2 1は、 さらに、 ステップ S 4 9において、 暗号化復号部 2 4により復号 されたコンテンツデータをコーデック部 2 5に供給し、 デコードさせる。 そして. コーデック部 2 5によりデコードされたデ一タを、 CPU 2 1は、 入出力ィンタフ エース 3 2から出力部 2 7に供給し、 D/A変換させ、 スピーカから出力させる。 ステップ S 4 6において、 利用権に含まれる使用条件、 及び使用状態に基づき. 再生が許可されないと判断された場合、 コンテンツを出力しないで、 処理は終了 する。
次に、 図 7のフローチャートを参照して、 図 6のステップ S 4 3で行われる利 用権取得処理の詳細について説明する。 4
13 クライアント 1は、 事前にライセンスサーバに登録することにより、 リーフ ID, DNK (Device Node Key)、 クライアント 1の秘密鍵 .公開鍵のペア、 ライセ ンスサーバの公開鍵、 及び各公開鍵の証明書を含むサービスデータを取得してお リーフ IDは、 クライアント毎に割り当てられた識別情報を表し、 DNKは、 コ ンテンッに含まれる EKB (有効化キーブロック） によって暗号化されているコン テンツキ一 Kcを復号するのに必要なデバイスノードキーである （図 1 0を参照 して後述する） 。
最初にステップ S 6 1において、 CPU 2 1は、 コンテンツのヘッダに記述され ている URLを取得する。 上述したように、 この URLは、 そのコンテンツを利用 するために必要な利用権を取得するときアクセスすべきァドレスである。 そこで、 ステップ S 6 2において、 CPU 2 1は、 ステップ S 6 1で取得した URLにァクセ スする。 具体的には、 通信部 2 9によりインターネット 2を介してライセンスサ —バ 4にアクセスが行われる。 このとき、 ライセンスサーバ 4は、 クライアント 1に対して、 利用権のリス トを送信するとともに、 購入する利用権 （コンテンツ を使用するのに必要な利用権） を指定する利用権指定情報、 並びにユーザ IDと パスワードの入力を要求してくる （後述する図 9のステップ S 1 0 2 ) 。 CPU 2 ' 1は、 この要求を出力部 2 7の表示部に表示させる。 ユーザは、 この表示に基づ いて、 入力部 2 6を操作して、 利用権指定情報、 ユーザ ID、 およびパスワード を入力する。 なお、 このユーザ ID とパスワードは、 クライアント 1のユーザが- ィンターネット 2を介してライセンスサーバ 4にアクセスし、 事前に取得してお いたものである。
CPU 2 1は、 ステップ S 6 3， S 6 4において、 入力部 2 6から入力された利 用権指定情報を取り込むとともに、 ユーザ IDとパスワードを取り込む。 CPU 2 1は、 ステップ S 6 5において、 通信部 2 9を制御し、 入力されたユーザ IDと パスワードを、 利用権指定情報及びサービスデータ （後述する） に含まれるリー フ IDを含む利用権要求をインターネット 2を介してライセンスサーバ 4に送信 させる。
ライセンスサーバ 4は、 図 9を参照して後述するように、 ユーザ IDとパスヮ ード、 並びに利用権指定情報に基づいて利用権を送信してくる (ステップ S 1 0 9 ) か、 または、 条件が満たされない場合には、 利用権を送信してこない （ステ ップ S 1 1 2 ) 。
ステップ S 6 6において、 CPU 2 1は、 ライセンスサーバ 4から利用権が送信 されてきたか否かを判定し、 利用権が送信されてきた場合には、 ステップ S 6 7 に進み、 その利用権を記憶部 2 8に供給し、 記憶させる。
ステップ S 6 6において、 利用権が送信されて来ないと判定した場合、 CPU 2
1は、 ステップ S 6 8に進み、 エラー処理を実行する。 具体的には、 CPU 2 1は、 コンテンツを利用するための利用権が得られないので、 コンテンッの再生処理を 禁止する。
以上のようにして、 各クライアント 1は、 コンテンツを利用するために必要な 利用権を取得して、 初めて、 そのコンテンツを使用することが可能となる。
なお、 図 7の利用権取得処理は、 各ユーザがコンテンツを取得する前に、 予め 行っておくようにすることも可能である。
クライアント 1に提供される利用権は、 例えば、 図 8に示されるように、 使用 条件、 リーフ IDおよび電子署名などを含んでいる。
バージョンは、 メジャーバージョンおよびマイ ""一バージョンをドットで区切 つて、 利用権のバージョンを記述する情報である。
プロファイルは、 1 0進の整数値から記述され、 利用権の記述方法に対する制 限を規定する情報である。
利用権 IDは、 1 6進定数で記述される、 利用権を識別するための識別情報で ある。
作成日時は、 利用権が作成された 0時を示す。 有効期限は、 利用権の有効期限を示す。 9 9 9 9年 2 3時 5 9分 5 9秒である 有効期限は、 有効期限に制限がないことを示す。
使用条件には、 その利用権に基づいて、 コンテンツを使用することが可能な使 用期限、 その利用権に基づいて、 コンテンツを再生することが可能な再生期限、 コンテンツの最大再生回数、 その利用権に基づいて、 コンテンツをコピーするこ とが可能な回数 （許されるコピー回数） 、 最大チェックアウト回数、 その利用権 に基づいて、 コンテンツを CD- R'に記録することができるか否か、 PD (Portable Device) にコピーすることが可能な回数、 利用権の移動の可否、 使用ログをと る義務の有無等を示す情報が含まれる。
使用条件の電子署名は、 使用条件に対応する、 電子署名である。
定数は、 使用条件または使用状態で参照される定数である。
リーフ IDは、 クライアントを識別するための識別情報である。
電子署名は、 利用権全体に対応する、 電子署名である。
証明書は、 ライセンスサーバの公開鍵を含む証明書である。
また、 クライアント 1の記憶部 2 8には、 利用権の使用条件とあわせて、 コン テンッゃ利用権の状態を表す情報である使用状態が記憶される。 使用状態には、 対応する利用権に基づいてコンテンツを再生した回数、 コンテンツをコピーした 回数、 コンテンツをチェックアウトした回数、 コンテンツを初めて再生した日時、 コンテンツを CD - Rに記録した回数、 その他コンテンツあるいは利用権に関する 履歴情報等を示す情報が含まれる。
図 6のステップ S 4 6の再生の条件の判定は、 利用権に含まれる使用条件と、 記憶部 2 8に利用権と共に記憶されている使用状態とを基に行われる。 例えば、 使用状態に記憶されているコンテンツを再生した回数が、 使用条件に含まれるコ ンテンッ最大再生回数より少ない場合には、 再生の条件が満たされていると判定 される。 次に、 図 9のフローチャートを参照して、 図 7のクライアント 1の利用権取得 処理に対応して実行されるライセンスサーバ 4の利用権提供処理について説明す る。
ステップ S 1 0 1において、 ライセンスサーバ 4の CPU 2 1は、 クライアント 1よりアクセスを受けるまで待機し、 アクセスを受けたとき、 ステップ S 1 0 2 に進み、 アクセスしてきたクライアント 1に対して、 各利用権に関する情報を含 む利用権のリストを送信するとともに、 ユーザ IDとパスワード、 並びに、 利用 権指定情報の送信を要求する。 上述したようにして、 クライアント 1から、 図 7 のステップ S 6 5の処理で、 ユーザ IDとパスワード、 リーフ ID並びに利用権 指定情報 （利用権 IDであってもよい） が送信されてきたとき、 ライセンスサー ノ 4の CPU 2 1は、 通信部 2 9を介してこれを受信し、 取り込む処理を実行する, そして、 ライセンスサーバ 4の CPU 2 1は、 ステップ S 1 0 3において、 通信 部 2 9から課金サーバ 5にアクセスし、 ユーザ IDとパスヮードに対応するユー ザの与信処理を要求する。 課金サーバ 5は、 インターネット 2を介してライセン スサーバ 4から与信処理の要求を受けると、 そのユーザ IDとパスワードに対応 するユーザの過去の支払い履歴などを調査し、 そのユーザが、 過去に利用権の対 価の不払いの実績があるか否かなどを調べ、 そのような実績がない場合には、 利 用権の付与を許容する与信結果を送信し、 不払いの実績などがある場合には、 利 用権付与の不許可の与信結果を送信する。
ステップ S 1 0 4において、 ライセンスサーバ 4の CPU 2 1は、 課金サーバ 5 からの与信結果が、 利用権を付与することを許容する与信結果であるか否かを判 定し、 利用権の付与が許容されている場合には、 ステップ S 1 0 5に進み、 ステ ップ S 1 0 2の処理で取り込まれた利用権指定情報に対応する利用権を、 記憶部 2 8に記憶されている利用権の中から取り出す。 記憶部 2 8に記憶されている利 用権は、 あらかじめ利用権 ID、 バージョン、 作成日時、 有効期限等の情報が記 述されている。 ステップ S 1 0 6において、 CPU 2 1は、 その利用権に受信した リーフ IDを付加する。 さらに、 ステップ S 1 0 7において、 CPU 2 1は、 ステ 4544
17 ップ S 1 0 5で選択された利用権に対応づけられている使用条件を選択する。 あ るいはまた、 ステップ S 1 0 2の処理で、 ユーザから使用条件が指定された場合 には、 その使用条件が必要に応じて、 予め用意されている使用条件に付加される, CPU 2 1は、 選択された使用条件を利用権に付加する。 使用条件は利用権にあら かじめ付加されていてもよい。
ステップ S 1 0 8において、 C P U 2 1はライセンスサーバの秘密鍵により利 用権に署名し、 ライセンスサーバの公開鍵を含む証明書を利用権に添付し、 これ により、 図 8に示されるような構成の利用権が生成される。
次に、 ステップ S 1 0 9に進み、 ライセンスサーバ 4の CPU 2 1は、 その利用 権 （図 8に示される構成を有する） を、 通信部 2 9からインターネット 2を介し てクライアント 1に送信させる。
ステップ S 1 1 0においてライセンスサーバ 4の CPU 2 1は、 ステップ S 1 0 9の処理で、 いま送信した利用権 （使用条件、 リーフ IDを含む） を、 ステップ S 1 0 2の処理で取り込まれたユーザ IDとパスヮードに対応して、 記憶部 2 8 に記憶させる。 さらに、 ステップ S 1 1 1において、 CPU 2 1は、 課金処理を実 行する。 具体的には、 CPU 2 1は、 通信部 2 9から課金サーバ 5に、 そのユーザ IDとパスワードに対応するユーザに対する課金処理を要求する。 課金サーバ 5 は、 この課金の要求に基づいて、 そのユーザに対する課金処理を実行する。 上述 したように、 この課金処理に対して、 そのユーザが支払いを行わなかったような 場合には、 以後、 そのユーザは、 利用権の付与を要求したとしても、 利用権を受 けることができないことになる。
すなわち、 この場合には、 課金サーバ 5から利用権の付与を不許可とする与信 結果が送信されてくるので、 ステップ S 1 0 4からステップ S 1 1 2に進み、 CPU 2 1は、 エラー処理を実行する。 具体的には、 ライセンスサーバ 4の CPU 2 1は、 通信部 2 9を制御してアクセスしてきたクライアント 1に対して、 利用権 を付与することができない旨のメッセージを送信し、 処理を終了させる。 この場合、 上述したように、 そのクライアント 1は利用権を受けることができ ないので、 そのコンテンツを利用すること （暗号化されたコンテンツデータを復 号し、 再生すること） ができないことになる。
本発明においては、 図 1 0に示されるように、 ブロードキャス トインクリプシ ヨン （Broadcast Encryption) 方式の原理に基づいて、 デバイスとキーが管理 される。 キーは、 階層ツリー構造とされ、 最下段のリーフ （leaf) が個々のデ バイス固有のキーに対応する。 本発明のシステムに用いられる階層ッリ一構造鍵 管理については特許公開 2001-352321号公報に記載されている。 図 1 0の例の 場合、 番号 0から番号 1 5までの 1 6個のデバイスに対応するキーが生成される, 各キーは、 図中丸印で示されるツリー構造の各ノードに対応して規定される。 この例では、 最上段のルートノードに対応してルートキー KRが、 2段目のノー ドに対応してキー K0, K 1が、 3段目のノードに対応してキー K0 0乃至 K 1 1が、 第 4段目のノードに対応してキー K0 0 0乃至キー K 1 1 1が、 それぞれ 対応されている。 そして、 最下段のノードとしてのリーフ （デバイスノード） に キー K00 0 0乃至 K 1 1 1 1力 それぞれ対応されている。
階層構造とされているため、 例えば、 キー K0 0 1 0とキー 00 1 1の上位の キーは、 K0 0 1とされ、 キー K000とキー K00 1の上位のキーは、 K0 0 とされている。 以下同様に、 キー K0 0とキー K0 1の上位のキーは、 K0とさ れ、 キー K 0とキー K 1の上位のキーは、 KRとされている。
コンテンツを利用するキーは、 最下段のデバイスノード （リーフ） から、 最上 段のルートノードまでの 1つのパスの各ノードに対応するキーで管理される。 例 えば、 番号 3のリーフに対応するデバイスにおいて、 コンテンツを利用するため のキーは、 キー K 0 0 1 1 , K00 1 , K 0 0 , K0， KRを含むパスの各キー で管理される。
本発明のシステムにおいては、 図 1 1に示されるように、 図 1 0の原理に基づ いて構成されるキーシステムで、 デバイスのキーとコンテンツのキーの管理が行 われる。 図 1 1の例では、 8 + 24+ 3 2段のノードがツリー構造とされ、 ルー トノードから下位の 8段までの各ノードにカテゴリが対応される。 ここにおける カテゴリとは、 例えばメモリースティックなどの半導体メモリを使用する機器の カテゴリ、 デジタル放送を受信する機器のカテゴリといったカテゴリを意味する, そして、 このカテゴリノードのうちの 1つのノードに、 ライセンスを管理するシ ステムとして本システム ( Tシステムと称する) が対応する。
すなわち、 この Tシステムのノードよりさらに下の階層の 2 4段のノードに対 応するキーにより、 サービスプロバイダ、 あるいはサービスプロバイダが提供す るサービスが対応される。 この例の場合、 これにより、 2 24 (約 1 6メガ) めサ 一ビスプロバイダあるいはサービスを規定することができる。 さらに、 最も下側 の 3 2段の階層により、 2 32 (約 4ギガ） のユーザ （あるいはクライアント 1 ) を規定することができる。 最下段の 3 2段のノードから Tシステムのノードまで のパス上の各ノードに対応するキーが、 DNK (Device Node Key) を構成し、 最 下段のリーフに対応する IDがリーフ IDとされる。
コンテンツを暗号化したコンテンツキーは更新されたルートキ一 KR'によって 喑号化され、 上位の階層の更新ノードキーは、 その直近の下位の階層の更新ノー ドキーを用いて暗号化され、 E K B (図 1 3および図 1 4を参照して後述する） 内に配置される。 E K Bにおける末端から 1つ上の段の更新ノードキーは E K B の末端のノードキーあるいはリーフキーによって暗号化され、 E K B内に配置さ れる。 クライアント 1は、 サービスデータに記述されている D N Kのいずれかの キーを用いて、 コンテンツデータとともに配布される E K B (図 1 3および図 1 4 ) 内に記述されている直近の上位の階層の更新ノードキーを復号し、 復号して 得たキーを用いて、 E K B内に記述されているさらにその上の階層の更新ノード キーを復号する。 以上の処理を順次行うことで、 クライアント 1は、 更新ルート キー KR'を得ることができる。
図 1 2に階層ツリー構造のカテゴリの分類の具体的な例を示す。 図 1 2におい て、 階層ツリー構造の最上段には、 ルートキー KR 2 3 0 1が設定され、 以下の 中間段にはノードキー 2 3 0 2が設定され、 最下段には、 リーフキー 2 3 0 3が 設定される。 各デバイスは個々のリーフキーと、 リーフキーからルートキーに至 る一連のノードキー、 ルートキーからなるデバイスノードキー （D N K) を保有 する。
最上段から第 M段目 （図 1 1の例では、 M= 8 ) の所定のノードがカテゴリノ ード 2 3 0 4として設定される。 すなわち第 M段目のノードの各々が特定カテゴ リのデバイス設定ノードとされる。 第 M段の 1つのノードを頂点として M + 1段 以下のノード、 リーフは、 そのカテゴリに含まれるデバイスに関するノードおよ びリーフとされる。
例えば図 1 2の第 M段目の 1つのノード 2 3 0 5にはカテゴリ [メモリーステ イツク （商標） ] が設定され、 このノード以下に連なるノード、 リーフはメモリ ステツイクを使用した様々なデバイスを含むカテゴリ専用のノードまたはリーフ として設定される。 すなわち、 ノード 2 3 0 5以下が、 メモリースティックの力 テゴリに定義されるデバイスの関連ノード、 およびリーフの集合として定義され る。
さらに、 M段から数段分下位の段をサブカテゴリノード 2 3 0 6として設定す ることができる。 図 1 2の例では、 カテゴリ [メモリースティック] ノード 2 3 0 5の 2段下のノードに、 メモリースティックを使用したデバイスのカテゴリに 含まれるサブカテゴリノードとして、 [再生専用器] のノード 2 3 0 6が設定さ れている。 さらに、 サブカテゴリノードである再生専用器のノード 2 3 0 6以下 に、 再生専用器のカテゴリに含まれる音楽再生機能付き電話のノード 2 3 0 7が 設定され、 さらにその下位に、 音楽再生機能付き電話のカテゴリに含まれる [ P H S ] ノード 2 3 0 8と、 [携帯電話] ノード 2 3 0 9が設定されている。 さらに、 カテゴリ、 サブカテゴリは、 デバイスの種類のみならず、 例えばある メーカー、 コンテンツプロバイダ、 決済機関等が独自に管理するノード、 すなわ ち処理単位、 管轄単位、 あるいは提供サービス単位等、 任意の単位 （これらを総 称して以下、 エンティティと呼ぶ） で設定することが可能である。 例えば 1つの カテゴリノードをゲーム機器メーカーの販売するゲーム機器 X Y Z専用の頂点ノ ードとして設定すれば、 メーカーの販売するゲーム機器 XYZに、 その頂点ノー ド以下の下段のノードキー、 リーフキーを格納して販売することが可能となり、 その後、 暗号化コンテンツの配信、 あるいは各種キーの配信、 更新処理を、 その 頂点ノードキー以下のノードキー、 リーフキーによって構成される有効化キープ ロック （EKB) を生成して配信し、 頂点ノード以下のデバイスに対してのみ利 用可能なデータが配信可能となる。
このように、 1つのノードを頂点として、 以下のノードをその頂点ノードに定 義されたカテゴリ、 あるいはサブカテゴリの関連ノードとして設定する構成とす ることにより、 カテゴリ段、 あるいはサブカテゴリ段の 1つの頂点ノードを管理 するメーカー、 コンテンツプロバイダ等がそのノードを頂点とする有効化キープ ロック （EKB) を独自に生成して、 頂点ノード以下に属するデバイスに配信す る構成が可能となり、 頂点ノードに属さない他のカテゴリのノードに属するデバ ィスには全く影響を及ぼさずにキー更新を実行することができる。
また、 ある時点 tにおいて、 デバイス 3の所有する鍵 KO 0 1 1， K0 0 1， KO 0， KO，KRが攻撃者 （ハッカー） により解析されて露呈したことが発覚し た場合、 それ以降、 システム （デバイス 0， 1， 2, 3のグループ） で送受信さ れるデータを守るために、 デバイス 3をシステムから切り離す必要がある。 その ためには、 ノードキー K0 0 1， K0 0， KO，KRを、 それぞれ新たな鍵 K ( t ) 0 0 1, K ( t ) 00，K ( t) 0，K ( t ) Rに更新し、 デバイス 0, 1 , 2に その更新キーを伝える必要がある。 ここで、 K ( t) a a aは、 鍵 K a a aの世 代 (Generation) tの更新キーであることを示す。
更新キーの配布処理ついて説明する。 キーの更新は、 例えば、 図 1 3に示す有 効化キーブロック （EKB： Enabling Key Block) と呼ばれるブロックデータ によって構成されるテーブルを、 ネットワークを介して、 あるいは記録媒体に格 納してデバイス 0， 1， 2に供給することによって実行される。 なお、 有効化キ 一ブロック （EKB) は、 図 1 0に示されるようなツリー構造を構成する各リー フ （最下段のノード） に対応するデバイスに、 新たに更新されたキーを配布する ための暗号化キーによって構成される。 有効化キーブロック （EKB) は、 キー 更新ブロック （KRB： Key Renewal Block) と呼ばれることもある。
図 1 3に示す有効化キーブロック （EKB) は、 ノードキーの更新の必要なデ バイスのみが更新可能なデータ構成を持つブロックデータとして構成される。 図 1 3の例は、 図 1 0に示すッリ一構造中のデバィス 0 , 1 , 2において、 世代 t の更新ノードキーを配布することを目的として形成されたプロックデータである。 図 1 0から明らかなように、 デバイス 0, デバイス 1は、 更新ノードキーとして K ( t) 00、 K ( t) 0、 K ( t) Rが必要であり、 デバイス 2は、 更新ノー ドキーとして K ( t) 00 1、 K ( t ) 00、 K ( t) 0、 K ( t) Rが必要で ある。
図 1 3の EKBに示されるように、 E KBには複数の暗号化キーが含まれる。 図 1 3の最下段の暗号化キーは、 E n c (K0 0 1 0 , K ( t ) 0 0 1 ) である。 これはデバイス 2の持つリーフキー K 0 0 1 0によって暗号化された更新ノード キー K ( t) 0 0 1であり、 デパイス 2は、 自身の持つリーフキー K 00 1 0に よってこの暗号化キーを復号し、 更新ノードキー K ( t) 0 0 1を得ることがで きる。 また、 復号により得た更新ノードキー K ( t) 00 1を用いて、 図 1 3の 下から 2段目の暗号化キー E n c ( ( t) 0 0 1， K ( t) 00) が復号可能 となり、 更新ノードキー K ( t) 00を得ることができる。
以下順次、 図 1 3の上から 2段目の暗号化キー E n c (K ( t) 0 0， K ( t ) 0) を復号することで、 更新ノードキー K ( t ) 0が得られ、 これを用い て、 図 1 3の上から 1段目の暗号化キー E n c (K ( t) 0， K ( t ) R) を復 号することで、 更新ルートキー K ( t) Rが得られる。
—方、 ノードキー K0 0 0は更新する対象に含まれておらず、 ノード 0, 1が、 更新ノードキーとして必要なのは、 K ( t) 0 0、 K ( t) 0、 K ( t) Rであ る。 ノード 0， 1は、 デバイスキー K0 0 0 0, K0 0 0 1を用いて、 図 1 3の 上から 3段目の暗号化キー E n c ( 0 0 0, K ( t) 0 0) を復号することで 更新ノードキー K ( t) 0 0を取得し、 以下順次、 図 1 3の上から 2段目の暗号 化キー E n c (K ( t) 0 0, K ( t) 0) を復号することで、 更新ノードキー K ( t) 0を得、 図 1 3の上から 1段目の暗号化キー E n c (K ( t) 0, K
( t) R) を復号することで、 更新ルートキー K ( t) Rを得る。 このようにし て、 デバイス 0， 1 , 2は更新したキー K ( t) Rを得ることができる。
なお、 図 1 3のインデックスは、 図の右側の暗号化キーを復号するための復号 キーとして使用するノードキー、 リーフキーの絶対番地を示す。
図 1 0に示すツリー構造の上位段のノードキー K ( t) 0，K ( t ) Rの更新 が不要であり、 ノードキー K0 0のみの更新処理が必要である場合には、 図 1 4 の有効化キープロック （EKB) を用いることで、 更新ノードキー K ( t) 0 0 をデバイス 0, 1， 2に配布することができる。
図 1 4に示す EKBは、 例えば特定のグループにおいて共有する新たなコンテ ンッキーを配布する場合に利用可能である。 具体例として、 図 1 0に点線で示す グループ内のデバイス 0, 1， 2， 3がある記録媒体を用いており、 新たな共通 のコンテンツキー K ( t) c o nが必要であるとする。 このとき、 デバイス 0, 1， 2, 3の共通のノードキー K0 0を更新した K ( t) 00を用いて新たな共 通の更新コンテンツキー K ( t) c o nを暗号化したデータ E n c (K ( t) 0 0， K ( t) c o n) 力 図 1 4に示される EKBとともに配布される。 この配 布により、 デバイス 4など、 その他のグループの機器が復号することができない データとしての配布が可能となる。
すなわち、 デバイス 0, 1 , 2は EKBを処理して得たキー K ( t) 0 0を用 いて暗号文を復号すれば、 t時点でのコンテンツキー K ( t) c o nを得ること が可能になる。
図 1 5に、 t時点でのコンテンツキー K ( t) c o nを得る処理例として、 K ( t) 00を用いて新たな共通のコンテンツキー K ( t) c o nを暗号化したデ ータ E n c (K ( t ) 0 0， K ( t ) c o n) と、 図 1 4に示す E K Bとを記録 媒体を介して受領したデバイス 0の処理を示す。 すなわちこの例は、 EKBによ る暗号化メッセージデータをコンテンツキー K ( t ) c o nとした例である。 4544
24 . 図 1 5に示すように、 デバイス 0は、 記録媒体に格納されている世代 t時点 の EKBと、 自分があらかじめ格納しているノードキー K0 00を用いて、 上述 したと同様の EKB処理により、 ノードキー K ( t) 00を生成する。 さらに、 デバイス 0は、 復号した更新ノードキー K ( t) 0 0を用いて、 更新コンテンツ キー K ( t ) c o nを復号して、 後にそれを使用するために自分だけが持つリー フキー K00 0 0で暗号化して格納する。
図 1 6に有効化キーブロック （EKB) のフォーマット例を示す。 バージョン 6 0 1は、 有効化キーブロック （EKB) のバージョンを示す識別子である。 な お、 バージョンは、 最新の E KBを識別する機能と、 コンテンツとの対応関係を 示す機能を持つ。 デプスは、 有効化キープロック （EKB) の配布先のデバイス に対する階層ッリ一の階層数を示す。 データボインタ 6 0 3は、 有効化キープ口 ック （EKB) 中のデータ部 6 0 6の位置を示すポインタであり、 タグポインタ 6 04はタグ部 6 0 7の位置、 署名ポインタ 6 0 5は署名 6 0 8の位置を示すポ ィンタである。
データ部 6 0 6は、 例えば更新するノードキーを暗号化したデータを格納する, 例えば図 1 5に示すような更新されたノードキーに関する各暗号化キー等を格納 する。
タグ部 6 0 7は、 データ部 6 06に格納された暗号化されたノードキー、 リー フキーの位置関係を示すタグである。 このタグの付与ルールを図 1 8を用いて説 明する。
図 1 7では、 データとして先に図 1 3で説明した有効化キーブロック （EK B) を送付する例を示している。 この時のデータは、 図 1 7の Bで示す表に示す ようになる。 このときの暗号化キーに含まれるトップノードのァドレスをトップ ノードアドレスとする。 この例の場合は、 ルートキーの更新キー K ( t) Rが含 まれているので、 トップノードアドレスは KRとなる。 このとき、 例えば最上段 のデータ E n c (K ( t) 0， K ( t) R) は、 図 1 7の Aで示す階層ツリーに 示す位置 P 0に対応する。 次の段のデータは、 E n c (K ( t) 0 0, K ( t) 0) であり、 ツリー上では前のデータの左下の位置 P 0 0に対応する。 ツリー構 造の所定の位置から見て、 その下に、 データがある場合は、 タグが 0、 ない場合 はタグが 1に設定される。 タグは {左 （L) タグ， 右 （R) タグ } として設定さ れる。 表 Bの最上段のデータ E n c (K ( t) 0， K ( t) R) に対応する位置 P0の左下の位置 POOにはデータがあるので、 Lタグ = 0、 右にはデータがない ので、 Rタグ = 1となる。 以下、 すべてのデータにタグが設定され、 図 1 7の C で示すデータ列、 およぴタグ列が構成される。
タグは、 対応するデータ E n c (Kx X X , Ky y y) ツリー構造のどこ に位置しているのかを示すために設定されるものである。 データ部 6 0 6に格納 されるキーデータ E n c (Kx X X , Ky y y) · · ·は、 単純に暗号化された キーの羅列データに過ぎないが、 上述したタグによってデータとして格納された 暗号化キーのツリー上の位置が判別可能となる。 上述したタグを用いずに、 先の 図 1 5で説明した構成のように、 暗号化データに対応させたノード ·インデック スを用いて、 例えば、
0 ： E n c (K ( t ) 0, K ( t ) R)
00 : E n c (K ( t ) 0 0， K ( t ) 0)
00 0 ： E n c (K ( ( t ) 0 00， K ( t ) 0 0)
- ■ 'のようなデータ構成とすることも可能であるが、 このようなインデック スを用いた構成とすると、 冗長なデータとなりデータ量が増大し、 ネットワーク を介する配信等においては好ましくない。 これに対し、 上述したタグをキー位置 を示す索引データとして用いることにより、 少ないデータ量でキー位置の判別が 可能となる。
図 1 6に戻って、 EKBフォーマットについてさらに説明する。 署名
(Signature) 6 0 8は、 有効化キーブロック （EKB) を発行した例えば鍵管 理センタ （ライセンスサーバ 4) 、 コンテンツロバイダ (コンテンツサーバ 3 ) 決済機関 （課金サーバ 5) 等が実行する電子署名である。 EKBを受領したデバ イスは、 署名検証によって正当な有効化キープロック （E K B ) 発行者が発行し た有効化キーブロック （E K B ) であることを確認する。
以上のようにして、 ライセンスサーバ 4から供給された利用権に基づいて、 コ ンテンッサーバ 3から供給されたコンテンツを利用する処理をまとめると、 図 1 8に示されるようになる。
すなわち、 コンテンツサーバ 3からクライアント 1に対してコンテンツが提供 されるとともに、 ライセンスサーバ 4からクライアント 1にライセンスが与えら れる。 クライアント 1をライセンスサーバ 4に登録した際に供給されるサービス データと、 特定のコンテンッの利用を許可する情報である利用権との組み合わせ をライセンスと呼ぶ。 コンテンツは、 コンテンツキー Kcにより、 暗号化されて おり （Enc (Kc , Content) ) 、 コンテンツキー Kcは、 更新ルートキー KR' (EKB から得られるキーであって、 図 5におけるキー KEKBCに対応する）で暗号化され
(Enc (KR，， Kc) ) 、 EKB とともに、 暗号化されたコンテンツに付加されてク ライアント 1に提供される。
図 1 8の例における EKBには、 例えば、 図 2 1に示されるように、 DNKで復号 可能な更新ルートキー KR，が含まれている （Enc (DNK, KR，） ） 。 従って、 クラ イアント 1は、 サービスデータに含まれる DNKを利用して、 EKBから更新ルート キー KR，を得ることができる。 さらに、 更新ルートキー KR'を用いて、 Enc (KR，： Kc) からコンテンツキー Kc を復号することができ、 コンテンツキー Kc を用いて. Enc (Kc, Content) からコンテンツを復号することができる D
このように、 クライアント 1に DNKを各デバイスに割り当てることにより、 図 1 0と図 1 5を参照して説明した原理に従って、 個々のクライアント 1のリボ ーク （revoke) が可能になる。
また、 ライセンスリーフ IDを付加して配布することにより、 クライアント 1 において、 サービスデータと利用権の対応付けが行われることになり、 利用権の 不正コピーを防止することが可能になる。 4
27 また、 クライアント用の証明書と秘密鍵をサービスデータとして配信するよう にすることで、 エンドユーザも、 これらを用いて不正コピーを防止可能なコンテ ンッを作成することが可能になる。
本発明においては、 図 1 1を参照して説明したように、 カテゴリノードにライ センスを管理する Tシステムと、 各種のコンテンツを利用するデバイスのカテゴ リが対応づけられるので、 複数の DNKを同一のデバイスに持たせることができ る。 その結果、 異なるカテゴリのコンテンツを 1つのデバイスで管理することが 可能となる。
図 2 2は、 この関係の一例を表している。 すなわち、 デバイス D 1には、 Tシ ステムに基づいて、 DNK 1が割り当てられており、 E K Bを含むコンテンツ 1を 再生することができる。 同様に、 このデバイス D 1には、 例えば、 DNK 2が割り 当てられており、 メモリースティックに CDからリッビングしたコンテンツ 2を 記録することができる。 この場合、 デバイス D 1は、 コンテンツ 1とコンテンツ 2という、 異なるシステム （Tシステムとデバイス管理システム） により配信さ れたコンテンツを同時に扱うことが可能となる。 新たな DNK を割り当てるとき、 既に割り当てられている DMを削除するなどして、 デバイスに 1個の DNKだけ を対応させるようにした場合、 このようなことはできなレ、。
このように、 本発明においては、 カテゴリ毎に独立したキー管理が可能になる。 また、 DNKを、 機器やメディアに予め埋め込むのではなく、 ライセンスサーバ 4により、 登録処理を行う際に、 各機器やメディアにダウンロードするようにす ることで、 ユーザによるキーの購入が可能なシステムを実現することができる。 コンテンツとその利用権を別々に配布するシステムにおいては、 コンテンツは、 それが作成された後、 どのような使われ方をされようとも、 その使われ方に関わ りなく、 全ての用途において、 使用可能であるのが望ましい。 例えば、 異なるコ ンテンッ配信サービス、 あるいは用途が異なる場合においても、 同一のコンテン ッが使えることが望ましい。 本発明においては、 このため、 上述したように、 各 ユーザ （クライアント 1 ) に、 認証局としてのライセンスサーバ 4から秘密鍵と、 それに対応する公開鍵の証明書 （certi ficates) が配布される。 各ユーザは、 その秘密鍵を用いて、 署名 （signature) を作成し、 コンテンツに付加して、 コ ンテンッの真正さ（integrity)を保証し、 かつコンテンッの改竄防止を図ること ができる。
クライアント 1は、 コンテンツを利用する前に、 ライセンスサーバ 4にァクセ スし、 利用権を取得する必要がある。 ライセンスサーバ 4は、 クライアント 1か らアクセスを受けたとき、 利用権を提供するのであるが、 その前にコンテンツホ ルダサーバ 6からコンテンツに関するプロダクト情報を取得する必要がある。 次 に、 図 2 1と図 2 2のフローチャートを参照して、 この場合の処理について説明 する。
コンテンツホルダサーバ 6の CPU 2 1は、 ステップ S 2 0 1において、 コンテ ンッのプロダクト情報を作成する。 ステップ S 2 0 2において、 CPU 2 1は、 ス テツプ S 2 0 1で作成したプロダクト情報を、 通信部 2 9を介してライセンスサ ーバ 4に送信する。
以上のコンテンツホルダサーバ 6の処理に対応して、 ライセンスサーバ 4は、 図 2 2のフローチヤ一トに示される処理を実行する。
すなわち、 ステップ S 3 0 1において、 ライセンスサーバ 4の CPU 2 1は、 コ ンテンッホルダサーバ 6から送信されてきた （図 2 1のステップ S 2 0 2の処理 で送信されてきた） プロダクト情報を受信する。 ステップ S 3 0 2において、 CPU 2 1は、 ステップ S 3 0 1の処理で受信したプロダクト情報を記憶部 2 8に 供給し、 記憶させる。 その後、 ステップ S 3 0 3において、 CPU 2 1·は、 ステツ プ S 3 0 2の処理で登録したプロダクト情報 （使用条件） を分割する処理を実行 する。
例えば、 コンテンッホルダサーバ 6から送信されてきたプロダクト情報が図 2 3に示されるような内容であったとする。 図 2 3の例においては、 ユーザが 3 5 0円の対価を支払った場合には、 対応するコンテンツを、 回数と期間の制限なく 再生することが可能となる。 これに対して、 ユーザが 1 0 0円の対価を支払った場合には、 回数は制限ない 力 期間は 1ヶ月のみとされ、 その間、 ユーザはコンテンツを再生することが許 容される。
ユーザは、 さらに 5 0円を追加的に支払った場合には、 3回だけチェックァゥ トが許容される。 さらに 5 0円の対価が支払われた場合には、 1回だけ、 1 0日 間の間、 コピーをすることが許容される。 この場合におけるコピー先での再生は、 対価の支払いは必要ないが （対価は 0円であるが） 、 回数は 1 0回に限られ、 期 間は 1日に限られている。
ライセンスサーバ 4は、 図 2 3に示されるようなプロダク ト情報をコンテンツ ホルダサーバ 6から受け取ったとき、 このプロダクト情報を、 例えば、 図 2 4に 示されるように分割する。
図 2 4の例においては、 プロダク ト情報は 3つに分割されている。 第 1のプロ ダクト情報は、 ユーザが 3 5 0円の対価を支払った場合のものであり、 その内容 は、 再生回数と再生期間が無限とされている。
第 2のプロダクト情報は、 ユーザが 1 5 0円の対価を支払った場合のものであ り、 再生回数は無限であるが、 再生期間は、 YY年丽月 DD曰までとされ、 チェ ックァゥトの回数は 3回まで許容される内容となっている。
第 3番目のプロダクト情報は、 対価は 0円とされ、 その内容はコピー先の使用 条件を規定するものであり、 再生回数は 1 0回とされ、 再生期間は 1日とされて いる。
この第 3番目のプロダクト情報は 0円であるので、 第 2番目のプロダクト情報 に付随して配布される。
このように、 ライセンスサーバ 4は、 コンテンツホルダサーバ 6から許容され たプロダクト情報に記載されている使用条件の範囲内において、 その使用条件を 複数の使用条件に分割し、 分割された使用条件を含む利用権として、
ト 1に対して提供することができる。 次に、 図 2 5のフローチャートを参照して、 図 2 2のステップ S 3 0 3のプロ ダクト情報 （使用条件） 分割処理の具体的な例について説明する。
なお、 図 2 5の処理は、 コンテンツホルダサーバ 6から提供され、 ライセンス サーバ 4の記憶部 2 8に記憶されているプロダクト情報に含まれる使用条件が、 例えば、 図 2 6に示されるような内容である場合において、 この使用条件から、 再生だけを許容する使用条件として分割する処理の例を表している。
図 2 6の例においては、 再生回数は 3回とされ、 チェックアウト回数も 3回と されている。 そして、 再生開始日は 2 0 0 1年 1 2月 1日とされ、 終了日は 2 0 0 2年 2月 2 8日とされている。
ステップ S 3 2 1において、 CPU 2 1は、 コンテンツホルダサーバ 6から受信 し、 記憶部 2 8に記憶したプロダクト情報の XML (Extensible Markup
Language) で記述されている Rule部から、 「playback」 の要素を検索する。 次に、 ステップ S 3 2 2において、 CPU 2 1は、 「playback」 が存在したか否 かを判定する。 「playback」 が存在した場合には、 ステップ S 3 2 3に進み、 CPU 2 1は、 期間制限オプション（timespan_id)から期間を抽出する。 図 2 6の 例においては、 2 0 0 1年 1 2月 1日から 2 0 0 2年 2月 2 8日までの期間が抽 出される。
次に、 ステップ S 3 2 4において、 CPU 2 1は、 ステップ S 3 2 3の処理で抽 出された期間の date—start (開始日） と date_end (終了日） を、 それぞれ再生 可能開始日を表す変数 resp及び再生可能終了日を表す reepに代入する。
ステップ S 3 2 5において、 CPU 2 1は、 ステップ S 3 2 4の処理に基づいて 生成されたデータに基づいて、 分割された使用条件を作成する。 これにより、 例 えば、 図 2 7に示されるような使用条件が作成される。
図 2 7の例においては、 2 0 0 1年 1 2月 1日力 ら 2 0 0 2年 2月 2 8日まで の期間、 コンテンツが使用可能とされている。
ステップ S 3 2 6において、 CPU 2 1は、 ステップ S 3 2 5の処理で作成した 使用条件と、 プロダク ト情報に含まれるコンテンツ条件、 利用権 ID等を組み合 わせ、 バージョン、 有効期限等を追加した利用権を生成し、 生成された利用権を 記憶部 2 8に登録する。
ステップ S 3 2 2において、 「playback」 のテキストが存在しないと判定さ れた場合には、 ステップ S 3 2 3乃至ステップ S 3 2 6の処理はスキップされる。 次に、 図 2 8のフローチャートを参照して、 図 2 2のステップ S 3 0 3の使用 条件分割処理の他の例について説明する。
この例は、 図 2 6に示されるような使用条件がコンテンツホルダサーバ 6から ライセンスサーバ 4に提供された場合において、 再生の使用条件と、 チェックァ ゥトの使用条件の、 合計 2つの使用条件を分割、 生成する場合の処理例を表して いる。
ステップ S 3 4 1乃至 S 3 4 5において、 図 2 5のステップ S 3 2 1乃至ステ ップ S 3 2 5における場合と同様の処理が実行される。 これにより、 上述したよ うに、 再生の使用条件を含む利用権が分割、 生成される。
なお、 ステップ S 3 4 2において、 「PLAYBACK」 の要素が検索されなかった と判定された場合、 ステップ S 3 4 3乃至ステップ S 3 4 5の処理はスキップさ れ、 処理はステップ S 3 4 6に進む。
次に、 ステップ S 3 4 6において、 CPU 2 1は、 XMLで記述された Rule部 （図 2 6 ) 力 ら 「checkout」 の要素を検索する。 ステップ S 3 4 7において、 CPU 2 1は、 「checkout」 が存在したか否かを判定し、 存在した場合には、 ステップ S 3 4 8に進み、 XMLの Rule部から回数を読み出す。 図 2 6の例の場合、 回数 として 3回が読み出される。
ステップ S 3 4 9において、 CPU 2 1は、 ステップ S 3 4 8で読み出された回 数を、 最大チェックアウト回数を表す変数 reccに代入する。 そして、 ステップ S 3 5 0において、 CPU 2 1は、 ステップ S 3 4 9の処理で生成されたデータを 元に、 分割された使用条件を作成する。 ステップ S 3 5 1において、 CPU 2 1は, ステップ S 3 4 5またはステップ S 3 5 0で作成された使用条件を含む利用権を 生成し、 記憶部 2 8に登録する処理を実行する。 ステップ S 3 4 7において、 「checkout」 が存在しないと判定された場合、 ステップ S 3 4 8乃至ステップ S 3 5 0の処理はスキップされる。
このようにして、 図 2 9に示されるような再生の使用条件を含む利用権とチェ ックァゥト回数が 3回である使用条件を含む利用権が生成される。
以上のようにして、 ライセンスサーバ 4がコンテンツホルダサーバ 6から提供 を受けた使用条件を、 分割、 管理するようにすることで、 クライアント 1は、 大 きな使用条件を取り扱う負担を強いられることなく、 利用権を容易に管理するこ とが可能となる。
また、 利用権に含まれている使用条件をアップグレードさせることができる。 この場合の処理について、 図 3 0を参照して説明する。
すなわち、 図 3 0の例においては、 コンテンツホルダサーバ 6が生成したコン テンッに対する利用権として、 そのコンテンツの再生、 チェックアウト、 および 購入を規定する 1つの利用権を生成し、 これをライセンスサーバ 4に提供する。 ライセンスサーバ 4は、 この 1つの利用権を、 再生だけができる利用権、 並ぴ に再生とチェックアウトができる利用権の 2つの利用権に分割する。
クライアント 1は、 例えば、 1 0円を支払うことにより、 再生だけの利用権を 取得することができる。 そして、 その後、 クライアント 1は、 さらに 3 0円を支 払うことにより、 再生だけでなく、 さらにチェックアウトの権利が付加された利 用権を取得することができる。 すなわち、 再生だけの利用権から、 再生とチエツ クアウトを含む利用権に、 クライアント 1は利用権をアップグレードすることが できる。
この場合において、 クライアント 1は、 利用権の状態が、 1 0円を支払った状 態と、 さらに 3 0円を支払った状態とがあるということを管理している必要はな い。 クライアント 1は、 ただ単に、 新たな利用権を購入するだけでよい。 換言す れば、 クライアント 1から見れば、 再生の利用権と、 再生とチェックアウトの利 用権とは、 全く独立した別の利用権として取り扱えばよいことになる。 この場合の処理を、 さらに図 3 1と図 3 2を参照して説明する。 図 3 1は、 ラ ィセンスサーバ 4がコンテンツホルダサーバ 6から提供を受けたプロダクト情報 の使用条件の概要を表している。 この例では、 Usage Rule IDが 1とされ、 1 0円の支払いが行われた場合、 再生が許容されるルールと、 2 0円の支払いがな された場合には、 再生とチェックアウトが許容されるルールが記述されている。 このような場合において、 ライセンスサーバ 4が図 3 1に示される 1つの使用 条件を、 再生だけの使用条件と、 再生とチェックアウトを許容する使用条件の 2 つに分割し、 それぞれに対応する利用権を生成したとする。
この場合、 図 3 2に示されるように、 クライアント 1がステップ S 3 7 1で、 ライセンスサーバ 4に対して 1 0円を支払った場合、 (なお、 詳細な説明は省略 するが、 具体的な課金処理は、 課金サーバ 5により行われる。 以下同様） ステツ プ S 3 7 2において、 ライセンスサーバ 4は、 クライアント 1に対して再生の利 用権 （Usage Right) を付与する。 この場合の処理は、 購入処理と同様となる。 その後、 ステップ S 3 7 3において、 クライアント 1がライセンスサーバ 4に 対して、 さらに 2 0円の支払いを許諾する情報を送信し、 ステップ S 3 7 4にお いて、 クライアント 1のリーフ ID と、 ステップ S 3 7 2で取得した利用権の ID を、 ライセンスサーバ 4に対して送信すると、 ステップ S 3 7 5において、 ライ センスサーバ 4は、 再生とチェックアウトの内容を含む利用権を、 クライアント 1に配布する。 この処理は、 アップグレード処理である。
なお、 ステップ S 3 7 2でクライアント 1に付与される利用権 IDと、 ステツ プ S 3 7 5の処理でクライアント 1に付与される利用権 IDは、 同一である。 す なわち、 この利用権 IDは、 図 3 1に示されるライセンスサーバ 4がコンテンツ ホルダサーバ 6から提供を受けた利用権の IDと対応している。
換言すれば、 分割されてはいるが、 2つの利用権は同一のプロダク ト情報に含 まれる使用条件から派生したものである。
図 3 3は、 クライアント 1がライセンスサーバ 4から利用権を取得する場合に おける表示例を表している。 ステップ S 3 9 1において、 クライアント 1がリー フ IDをライセンスサーバ 4に送信するとともに、 既に利用権を取得している場 合には、 その IDをライセンスサーバ 4に送信する。
ライセンスサーバ 4は、 クライアント 1に対して、 購入可能な権利のリストと 対応する値段が記述されたドキュメントを、 クライアント 1に送信する。 クライ アント 1の CPU 2 1は、 これを通信部 2 9を介してこれを受信すると、 出力部 2 7のモニタに出力し、 表示させる。
図 3 3の例においては、 購入可能な権利として、 3回のチェックアウトを可能 にする 1 0 0円の利用権、 既に取得されているコンテンツを自分のものにする 1 5 0円の利用権、 並びに既に取得している利用権を他人にコピーしてあげる 1 0 円の利用権の、 3種類の利用権が表示されている。
クライアント 1が保持する利用権は、 クライアント 1が支払った対価に応じて. 変化するのであるが、 いま、 ライセンスサーバ 4にアクセスしてきたクライアン ト 1が、 いずれの状態の利用権を取得しているのかは、 ライセンスサーバ 4が管 理している。 従って、 クライアント 1のリーフ IDとクライアント 1が保持して いる利用権の IDに基づいて、 ライセンスサーバ 4の CPU 2 1は、 アクセスして きたクライアント 1に対応するメニュー （購入可能な権利の内容） を表示させる ことができる。
なお、 図 3 3の表示例においては、 「佐藤さん、 いらっしゃいませ。 」 のメッ セージも同時に表示されている。 アクセスしてきたクライアント 1のユーザが誰 であるのかは、 ユーザを登録する処理を行った場合に、 ユーザ名を登録している ので、 リーフ IDに対応するユーザの氏名をデータベースから検索することで、 表示することが可能となる。
あるいは、 また、 cookieを利用して氏名を表示させるようにすることも可能 である。
ステップ S 3 9 2で、 クライアント 1が、 メニュー表示に従い利用権の購入手 続を行い、 利用権に対する対価の支払の処理を行うと、 ステップ S 3 9 3におい 4544
35 て、 ライセンスサーバ 4からクライアント 1に、 対価に対応する利用権 （Usage Right) が配布される。
次に、 図 3 4を参照して、 ライセンスサーバ 4において行われる購入履歴の管 理について説明する。
図 3 4の例においては、 コンテンツホルダサーバ 6が 1つのプロダク ト情報を ライセンスサーバ 4に供給する。 このプロダク ト情報は、 2 0 0円の対価によつ て取得することが可能な Usage Rules 1、 さらに 1 0 0円を支払って取得する ことが可能な Usage Rules 2、 さらに 5 0円を支払うことにより取得可能な Usage Rules 3、 並びに Usage Rul es 2を有するユーザがさらに 3 0円を支払う ことにより取得することが可能な Usage Rules 4、 により構成されている。
ライセンスサーバ 4は、 コンテンツホルダサーバ 6からこのプロダクト情報を 取得すると、 Usage Rules 1乃至 Usage Rul es 4を分割する。 そして、 ライセン スサーバ 4は、 状態テーブルとして、 Usage Rules 1乃至 Usage Rules 4に対応 した利用権購入状態のレコードを LeafID、 利用権ごとに生成、 管理する。
すなわち、 このテーブルでは、 Usage Rules 1乃至 Usage Rules 4をそれぞれ 有する状態が、 状態 1乃至状態 4とされ、 これらのいずれをも有していない状態 が状態 0とされる。
このように、 利用権所持の状態は、 ライセンスサーバ 4により管理されている ので、 クライアント 1が管理する必要はない。 従って、 クライアント 1の負荷が 軽減される。
すなわち、 クライアント 1は、 Usage Rul es 1乃至 Usage Rules 4のうちのい ずれか 1つを適宜購入するだけでよい。
例えば、 クライアント 1のユーザは、 2 0 0円を支払うことで、 Usage Rules 1を含む利用権を取得することができ、 さらに 1 0 0円を追加的に支払うことで、 Usage Rules 2を含む利用権を取得することができる。
クライアント 1がいずれの利用権を取得する場合においても、 同一のプロトコ ルを使用することが可能であるが、 利用権の内容に応じて、 使用するプロトコル を変更することも可能である。 次に、 この使用権に応じて、 プロトコルを変更す る例について説明する。
この実施の形態では、 図 3 5に示されるように、 ライセンスサーバ 4からクラ イアント 1に対して、 利用権を配布するプロトコルには、 簡易購入プロトコルと 権利更新プロトコルの 2種類が用意される。 簡易購入プロトコルは、 特殊な認証 が不要とされるプロトコルであり、 権利更新プロトコルは、 特殊な認証が必要と されるプロトコルである。 すなわち、 権利更新プロトコルは、 簡易購入プロトコ ルに比べて、 よりセキュアな環境化での通信が行われるものである。
簡易購入プロトコルにおいては、 利用権は、 ライセンスサーバ 4からクライァ ント 1に対して、 単にダウンロードされる。 これに対して、 権利更新プロトコル においては、 ライセンスサーバ 4がクライアント 1が有する利用権を更新する処 理を実行するため認証処理が行われる。
次に、 図 3 6のフローチヤ一トを参照して、 クライアント 1がライセンスサー バ 4から、 利用権の内容に応じて、 異なるプロ トコルで利用権を取得する処理に ついて説明する。
ステップ S 4 6 1において、 クライアント 1の CPU 2 1は、 ライセンスサーバ 4にアクセスする。 ステップ S 4 1 2において、 CPU 2 1は、 ユーザからの指令 に基づいて、 ユーザが希望する利用権に関する情報を通信部 2 9を介してライセ ンスサーバ 4に送信する。
図 3 7のフローチャートを参照して後述するように、 クライアント 1が希望す るのが、 サブスクリプシヨンサービスの利用権である場合には、 ライセンスサー ノ 4力 ら AKE (Authentication Key Exchange)処理カ要求されてくる （図 3 7 のステップ S 4 4 8 ) 。 これに対して、 取得する利用権がサブスクリプシヨンサ 一ビスの利用権ではない場合 （買い取り用、 または試聴用である場合） には、 AKE 処理が要求されてこない。 そこで、 ステップ S 4 1 3において、 CPU 2 1は、
-ーバ 4から AKE処理が要求されたか否かを判定し、 AKE処理が要求 されてこない場合には、 ステップ S 4 1 4に進み、 記憶部 2 8に記憶されている リーフ IDを読み出し、 通信部 2 9を介してライセンスサーバ 4に送信させる。 このとき、 ライセンスサーバ 4は、 クライアント 1が希望した利用権に、 それ に対応するデジタル署名を付加してクライアント 1に送信してくる （図 3 7のス テツプ S 4 4 7 ) 。 そこで、 ステップ S 4 1 5において、 クライアント 1の CPU 2 1は、 クライアントサーバ 4から送信されてきた利用権とデジタル署名を受信 する。 ステップ S 4 1 6において、 CPU 2 1は、 ステップ S 4 1 5で受信したデ ジタル署名をライセンスサーバ 4の公開鍵 SPで復号する。 このライセンスサー バの公開鍵 SPは、 リーフ IDとともに、 登録処理において、 取得され、 記憶部 2 8に記憶されているものである （図 6のステップ S 5 3 ) 。
ステップ S 4 1 7において、 CPU 2 1は、 ステップ S 4 1 5の処理で受信した 利用権は、 ステップ S 4 1 6の処理でデジタル署名を復号して得られた利用権と 一致するか否かを判定する。 両者が一致する場合には、 適正な （改竄されていな い） 利用権であるので、 CPU 2 1は、 ステップ S 4 1 8において、 その利用権を 記憶部 2 8に記憶させる。
それに対して、 2つの利用権が一致しない場合には、 正しい利用権ではないの で、 ステップ S 4 2 6に進み、 CPU 2 1は、 エラー処理を実行する。
一方、 ステップ S 4 1 3において、 AKE処理が要求されたと判定された場合、 ステップ S 4 1 9に進み、 CPU 2 1は、 ライセンスサーバ 4との間で AKE処理を 実行する。 すなわち、 これにより、 よりセキュアな通信路を確保する処理が実行 され、 セッション鍵が共有される。
ステップ S 4 2 0において、 CPU 2 1は、 AKE処理により、 SAC (Secure Authent ication Channel)が形成できたか否か (セキュアな通信路が確保でき たか否か） を判定する。 SACが形成できたと判定された場合には、 ステップ S 4 2 1において、 CPU 2 1は、 記憶部 2 8に記憶されているリーフ IDを、 AKE処理 により確保されたセッション鍵で暗号化して、 通信部 2 9からインターネット 2 を介して、 ライセンスサーバ 4に送信する。 この場合、 ライセンスサーバ 4からセッション鍵で暗号化された使用鍵とデジ タル署名が、 クライアント 1に送信されてくる （後述する図 3 7のステップ S 4 5 4 ) 。 そこで、 ステップ S 4 2 2において、 クライアント 1の CPU 2 1は、 セ ッシヨン鍵で暗号化されている利用権とデジタル署名を受信し、 ステップ S 4 2 3において、 暗号化された利用権を、 ステップ S 4 1 9の AKE処理で取得した セッション鍵で復号する。
ステップ S 4 2 4において、 CPU 2 1は、 ステップ S 4 2 2の処理で受信した デジタル署名を、 ライセンスサーバ 4の公開鍵 SPで復号する。 ステップ S 4 2 5において、 CPU 2 1は、 ステップ S 4 2 3の処理で復号して得られた利用権と ステップ S 4 2 4の処理で復号して得られた利用権とが、 一致するか否かを判定 する。 両者が一致する場合には、 正しい利用権であることが確認できたので、 ス テツプ S 4 1 8に進み、 CPU 2 1は、 得られた利用権を記憶部 2 8に記憶する。 ステップ S 4 2 5の処理において、 2つの利用権が一致しないと判定された場 合、 得られた利用権が正しいものではない （例えば、 改竄されたものである） 恐 れがあるので、 ステップ S 4 2 0において、 SACが形成できなかったと判定され た場合と同様に、 ステップ S 4 2 6に進み、 エラー処理が実行される。
以上のクライアント 1の利用権取得処理に対応して実行されるライセンスサー バ 4の利用権配布処理について、 図 3 7のフローチャートを参照して説明する。 ステップ S 4 4 1において、 ライセンスサーバ 4の CPU 2 1は、 クライアント 1からのアクセスを受け付ける。 ステップ S 4 4 2において、 CPU 2 1は、 クラ イアント 1からの利用権に関する情報を受信する。 この利用権に関する情報は、 図 3 6のステップ3 4 1 2の処理により、 クライアント 1から送信されてきたも のである。
ステップ S 4 3 4において、 ライセンスサーバ 4の CPU 2 1は、 クライアント 1が希望するサービスに対応する利用権の情報を記憶部 2 8から取得する。
ステップ S 4 4 4において、 CPU 2 1は、 クライアント 1が希望している利用 権は、 サブスクリプシヨンサービスの利用権のものであるか否かを判定する。 利 用権がサブスクリプシヨンサービスの利用権でない場合 （買い取り用または試聴 用のものである場合） には、 特に、 セキュアな環境化で通信を行う必要がない。 このとき、 クライアント 1からリーフ IDが送信されてくる （図 3 6のステップ S 4 1 4 ) 。 そこで、 ステップ S 4 4 5において、 ライセンスサーバ 4の CPU 2 1は、 クライアント 1から送信されてきたリーフ IDを受信し、 そのリーフ ID をクライアント 1が希望する利用権に挿入する。
ステップ S 4 4 6において、 CPU 2 1は、 ライセンスサーバ 4の秘密鍵を用い て、 ステップ S 4 4 5の処理でリーフ IDを揷入した利用権のデジタル署名を作 成する。
次に、 ステップ S 4 4 7において、 CPU 2 1は、 ステップ S 4 4 5の処理でリ ーフ IDを揷入した利用権と、 ステップ S 4 4 6の処理で作成したデジタル署名 とを、 クライアント 1に送信する。
このようにして、 送信した利用権とデジタル署名が、 図 3 6のステップ S 4 1 5において、 クライアント 1により受信されることになる。
一方、 ステップ S 4 4 4において、 クライアント 1が希望している利用権がサ ブスクリプシヨンサービスの利用権である （買い取り用または試聴用ではない） と判定された場合、 よりセキュアな環境化で通信を行う必要がある。 そこで、 ス テツプ S 4 4 8に進み、 CPU 2 1は、 クライアント 1に対して AKE 処理を要求し、 AKE処理を実行する。
ステップ S 4 4 9において、 CPU 2 1は、 SAC が形成できたか否かを判定する c SACが形成できた場合には、 ステップ S 4 5 1に進み、 CPU 2 1は、 クライアン ト 1が希望する利用権に使用状態 （Usage Status) を付加する。 ステップ S 4 5 2において、 CPU 2 1は、 クライアント 1が希望する利用権にリーフ IDを揷 入し、 ステップ S 4 4 8の AKE処理で得られたセッション鍵で暗号化する。
ステップ S 4 5 3において、 CPU 2 1は、 自分自身の秘密鍵を用いて、 ステツ プ S 4 5 2の処理でリーフ IDが揷入され、 セッション鍵で喑号化された利用権 のデジタル署名を作成する。 ステップ S 4 5 4において、 CPU 2 1は、 ステップ S 4 5 2の処理でセッショ ン鍵で暗号化された利用権と、 ステップ S 4 5 3の処理で作成されたデジタル署 名とを、 クライアント 1に送付する。
このようにして、 送付された利用権とデジタル署名は、 上述したように、 クラ イアント 1により、 ステップ S 4 2 2において受信される。
ステップ S 4 4 9において、 SACが形成できなかったと判定された場合には、 セキュアな通信路が碓保できなかったので、 ステップ S 4 5 0に進み、 エラー処 理が実行される。
すなわち、 この場合には、 利用権は、 クライアント 1に対して配布されないこ とになる。
よりセキュアな状態での利用権の配布を望まないユーザは、 そのための機能を 設ける必要がないので、 ユーザに必要以上の負担をかけることなく、 利用権を配 布することが可能となる。 また、 セキュアな環境下での利用権の取得を希望する ユーザに対しては、 より安全に利用権を配布することが可能となる。 その結果、 利用権が第 3者に盗用されるようなことが防止される。
以上のようにして、 コンテンツと利用権を得たクライアント 1は、 利用権に基 づいて、 コンテンツを使用する （例えば、 再生する） 処理を実行する。
次に、 この場合の処理について、 図 3 8のフローチャートを参照して説明する < ステップ S 4 7 1において、 クライアント 1の CPU 2 1は、 ライセンスサーバ 4にアクセスする。 ステップ S 4 7 2において、 CPU 2 1は、 ライセンスサーバ 4との間で AKE処理を実行する。
ステップ S 4 7 3において、 CPU 2 1は、 SAC が形成できたか否かを判定する, SACが形成できた場合には、 ライセンスサーバ 4から使用状態、 リーフ ID、 お よびコンテンツ情報の送信を要求してくる （後述する図 3 9のステップ S 4 9 5 ) 。
そこで、 ステップ S 4 7 5において、 クライアント 1の CPU 2 1は、 ライセン スサーバ 4からのこの要求を受信する。 この要求は、 ステップ S 4 7 2の AKE 処理で得られたセッション鍵で暗号化されている。 そこで、 CPU 2 1は、 ステツ プ S 4 7 2の AKE 処理で得られたセッション鍵を用いて、 この要求を復号する。 ステップ S 4 7 6において、 CPU 2 1は、 この要求に基づいて、 これから使用 する利用権に対応する使用状態、 リーフ ID、 およびコンテンツ情報を、 セッシ ヨン鍵で喑号化して、 ライセンスサーバ 4に送信する。
この送信に対応して、 ライセンスサーバ 4から更新した使用状態を、 セッショ ン鍵で暗号化して送信してくる （図 3 9のステップ S 4 9 8 ) 。
そこで、 ステップ S 4 7 7において、 クライアント 1の CPU 2 1は、 ライセン スサーバ 4から送信されてきた、 更新された使用状態を受信し、 セッション鍵で 復号し、 記憶部 2 8に記憶する。 例えば、 利用権に使用回数の条件が含まれてい るような場合、 クライアント 1がこれからコンテンツを再生するので、 使用回数 は 1回インクリメントされた値に更新されていることになる。 そして、 ステップ S 4 7 8において、 CPU 2 1は、 コンテンツを再生する処理を実行する。
このように、 使用状態がクライアント 1ではなく、 ライセンスサーバ 4により 管理されるので、 利用権がクライアント 1において改竄され、 コンテンツが不正 に利用されるようなことが防止される。
また、 ライセンスサーバ 4は、 必要に応じて、 使用状態を適宜書き換えること で、 所定のユーザに対して、 コンテンツの利用を適宜禁止させたり、 柔軟なサー ビスの提供を行うことが可能となる。
また、 ライセンスサーバ 4からクライアント 1が保持する利用権の使用状態を 制御することができるため、 使用を許可する回数の増減、 コンテンツ毎の無効化、 サービス自体の停止などを、 ライセンスサーバ 4が適宜行うことが可能となる。 ステップ S 4 7 3において、 SACが形成できなかったと判定された場合、 ステ ップ S 4 7 4に進み、 エラー処理が実行される。
以上のクライアント 1の利用権使用処理に対応して実行されるライセンスサー バ 4の処理について、 図 3 9のフローチヤ一トを参照して説明する。 ステップ S 4 9 1において、 ライセンスサーバ 4の CPU 2 1は、 クライアント 1からのアクセスを受け付ける。 ステップ S 4 9 2において、 CPU 2 1は、 クラ イアント 1との間で AKE処理を実行する。 ステップ S 4 9 3において、 CPU 2 1 は、 AKE処理の結果、 SACが形成できたか否かを判定する。
SACが形成できた場合には、 ステップ S 4 9 5に進み、 CPU 2 1は、 クライア ント 1に対して、 使用状態、 リーフ ID、 およびコンテンツ情報の送信を要求す る。 この要求は、 ステップ S 4 9 2の AKE処理で得られたセッション鍵で暗号 化して、 クライアント 1に送信される。 上述したように、 この要求は、 クライア ント 1において、 ステップ S 4 7 5の処理で受信され、 ステップ S 4 7 6の処理 でその要求に対応した情報がクライアント 1から送信されてくる。
そこで、 ステップ S 4 9 6において、 ライセンスサーバ 4の CPU 2 1は、 クラ イアント 1から送信されてきた使用状態、 リーフエ D、 およびコンテンツ情報を 受信する。 これらの情報は、 セッション鍵で暗号化されているので、 CPU 2 1は、 ステップ S 4 9 2の AKE処理で得られたセッション鍵を用いて、 これらの情報 を復号する。
ステップ S 4 9 7において、 CPU 2 1は、 クライアント 1から送信されてきた 使用状態をコンテンツ情報に基づいて更新する。 例えば、 これからコンテンツが 使用される場合には、 その使用回数を 1回だけィンクリメントした値に変更させ る。 あるいは、 そのコンテンツを以後使用禁止にする場合には、 CPU 2 1は、 使 用回数をもはや使用できない回数に変更する。
ステップ S 4 9 8において、 CPU 2 1は、 ステップ S 4 9 7の処理で更新した 使用状態をセッション鍵で暗号化して、 クライアント 1に送信する。
この使用状態が上述したように、 クライアント 1において、 ステップ S 4 7 7 において、 受信される。
ステップ S 4 9 3の処理で SACが形成できなかったと判定された場合には、 ステップ S 4 9 4に進み、 エラー処理が実行される。 使用条件を記述する場合、 フラグや値のみで記述すると、 その値の意味をクラ イアント 1が全て知っている必要がある。 このため、 条件項目をライセンスサー バ 4が追加することが困難になる。
また、 逆に、 使用条件をフレキシブルに記述することを許容すると、 クライア ント 1において、 ユーザに対して、 使用条件をどのように表現するか難しくなる, そこで、 コンテンツの使用条件を、 関係式と論理式のみからなる条件式で記述 することにより、 クライアント 1において、 各項目のフォーマットをあらかじめ 規定しておく必要がなく、 様々な使用条件の記述に対応することができるように することができる。 このため、 クライアント 1における実装によらずに、 使用条 件を記述することが可能となる。
また、 クライアント 1の処理能力等によって、 Usage Rulesの記述に制限を 設けるようにすることで、 クライアント 1において、 容易にルールの意味を解釈 できるようにすることができる。 以下、 この例について説明する。
Usage Rulesは、 コンテンツの使用条件を規定するものであり、 上述したよ うに、 ユーザ (クライアント 1 ) が購入する利用権（Usage Right)に含まれる。 Usage Rulesで規定できるものには、 以下のようなものがある。
コンテンツの再生回数
コンテンツの使用期限
コンテンツのチェックァゥト回数
その他
これらの条件は、 専用の記述言語で記述し、 バイトコードにコンパイルして、 Usage Rightに格納される。
基本的な記述方法は、 図 4 0に示されるような形式となる。 すなわち、 各ドメ イン、 つまりコンテンツの利用形態のカテゴリ、 に対して、 Usage Ruleが記述 される。
1つの Usage Ruleは、 図 4 1に示されるような形式で記述される。 1つの Usage Ruleは、 先頭に記述する domain_idで、 それを適用するドメイ ンを規定する。 さらに、 それに続く' {' ■ · ■ ' } '内に、 各種ルールが規定さ れる力 その中は、 ノレ一ルセクシヨン、 invariablesセクション、 および overhead partの 3つのセクションに分力、れる。
ノレ一ノレセクションは、 ' {' · ■ · , } 'の先頭で、 複数の domain— ruleを記述 することができる。 invariablesセクションは、 ルールセクションに続き、 キ 一ワード， invariables:，によって始まる部分である。 overhead partは、 invariables セクション【こ続く音分であり、 ' over一 head—part： ' こよって 合まる, domain— idは、 ドメインを示す名称であり、 以下の文字列のうちのいずれかで ある。
drm
Tenderer
ri per
burner
1cm— 1
lcra_2
lcm_3
renderer ドメインはコンテンツの再生、 表示等の利用形態のカテゴリ、 ripper ドメインは CDのコンテンツの読み出しの利用形態のカテゴリ、 burner ドメインはコンテンツの CD- Rへの記録の利用形態のカテゴリ、 drm ドメインは 全ての利用形態のカテゴリをそれぞれ表している。
domain— ruleは、
, {' <条件式〉 ' } ，
の形式で記述される。
各ルールの前には、 以下の形式でルール番号を指定することができる。
' [' <ルール番号〉，] ' {' <条件式 >' } ' ルール番号を指定する場合には、 次のように、 複数の番号を指定することが可 能である。
[ 1 ] ' {'く条件式 # 1〉' } ，
[ 2 ] ， {' <条件式# 2 > ' } '
条件式は、 各ドメィンの状態変数や定数などを参照するための Chars Code
( C C ) に対して、 比較演算を施したものである。 その記述例は、 例えば、 次の ようになる。
！ ee and ！ pp
！ ee and 、 cid pp )
利用できる演算子には、 図 4 2に示されるようなものあがる。
図 4 2における 2項演算子の演算優先順位は、 弱い順に、 or, and，その他の 演算子となる。 どの演算子も左結合である。
invariablesセクションは、 各種定数を記述する部分であり、 次の形式で Chars Codeに値を定義する。
< Chars Code > ' =' <値> ' ； '
複数の invariablesを定義する場合には、 次に示されるように、 ，， 'で区切 つて記述が行われる。
< Chars Code〉， =，く値〉'， ' < Chars Code〉， ='く値〉 , · ■ ' ； ' < Chars Code〉は、 その名称と意味があらかじめ規定されている。
overhead partは、 各ドメイン毎の独自のルールを記述する部分である。
Char Code は Usage Rules の invariables セクション内で定義される以外に 利用権、 コンテンツ、 使用状態等の中で定義されていても良い。
以上のルール記述言語で記載された例が図 4 3に示されている。
なお、 上述したコンテンツサーバ 3、 ライセンスサーバ 4、 課金サーバ 5、 並 びにコンテンツホルダサーバ 6のいずれか 2つ以上は、 必要に応じて実質的に 1 つのサーバに統合させることも可能である。 また、 本実施の形態では、 暗号化されたコンテンツを復号するための鍵情報は コンテンツに含まれているが、 利用権に鍵情報を含む、 あるいはコンテンツに含 まれる鍵情報と利用権に含まれる鍵情報とを組み合わせることで復号可能となる ようにしても良い。
本発明が適用されるクライアントは、 いわゆるパーソナルコンピュータ以外に PDA (Personal Digital Assi stants) 、 携帯電話機、 ゲーム端末機などとする ことができる。
—連の処理をソフトウェアにより実行させる場合には、 そのソフトウェアを構 成するプログラムが、 専用のハードウェアに組み込まれているコンピュータ、 ま たは、 各種のプログラムをインス トールすることで、 各種の機能を実行すること が可能な、 例えば汎用のパーソナルコンピュータなどに、 ネットワークや記録媒 体からィンストールされる。
この記録媒体は、 図 2に示されるように、 装置本体とは別に、 ユーザにプログ ラムを提供するために配布される、 プログラムが記録されている磁気ディスク 4 1 (フレキシブノレディスクを含む） 、 光ディスク 4 2 (CD-ROM (Compact Disk - Read Only Memory) , DVD (Digital Versati le Di sk)を含む） 、 光磁気ディスク 4 3 (MD (Mini - Di sk) (商標） を含む） 、 もしくは半導体メモリ 4 4などよ りなるパッケージメディアにより構成されるだけでなく、 装置本体に予め組み込 まれた状態でユーザに提供される、 プログラムが記録されている R0M 2 2や、 記 憶部 2 8に含まれるハードディスクなどで構成される。
なお、 本明細書において、 記録媒体に記録されるプログラムを記述するステツ プは、 記載された順序に沿って時系列的に行われる処理はもちろん、 必ずしも時 系列的【こ処理されなくとも、 並列的あるいは個別に実行される処理をも含むもの である。
また、 セキュリティに関連する処理を実行させるプログラムは、 その処理を解 析されるのを防ぐため、 そのプログラム自体が暗号化されているのが望ましい。 例えば、 暗号処理などを行う処理については、 そのプログラムをタンパ一レジス タントモジュールとして構成することができる。
また、 上記実施の形態では、 コンテンツを利用するために必要な利用権を特定 するためにコンテンッの属性と利用権のコンテンツ条件を用いたが、 これに限ら ない。 例えば、 コンテンツに、 該コンテンツを利用するために必要な利用権の利 用権 IDを含むようにしても良く、 この場合、 コンテンツを指定すればそれを利 用するために必要な利用権は一意に決まるため、 両者のマッチングを決定する処 理を行う必要はない。 産業上の利用可能性
以上の如く、 本発明によれば、 利用権をユーザに配布することができる。 特に その場合において、 内容を細かく分割した利用権をユーザに配布することができ る。 さらに、 ユーザに対して重い負荷をかけることなく、 利用権を配布すること が可能となる。

Claims

請求の範囲
1 . コンテンツの使用条件を規定する利用権を配布する情報処理装置において. 前記使用条件を含む情報を受信する受信手段と、
前記受信手段により受信された前記使用条件から一部を抽出し、 部分使用条件 を生成する抽出手段と、
前記抽出手段により生成された前記部分使用条件をユーザに配布する配布手段 と
を備えることを特徴とする情報処理装置。
2 . 前記部分使用条件から前記利用権を生成する生成手段を
さらに備えることを特徴とする請求の範囲第 1項に記載の情報処理装置。
3 . 前記受信手段が受信する前記使用条件は、 対応するコンテンツの利用形態 毎に定義されており、
前記抽出手段は少なくとも 1つ以上の前記利用形態に関する使用条件を含む部 分使用条件を生成する
ことを特徴とする請求の範囲第 1項に記載の情報処理装置。
4 . 前記受信手段によって受信される前記情報は、 前記使用条件に対応する課 金情報を含む
ことを特徴とする請求の範囲第 1項に記載の情報処理装置。
5 . コンテンツの使用条件を規定する利用権を配布する情報処理装置の情報処 理方法において、
前記使用条件を含む情報を受信する受信ステップと、
前記受信ステップの処理により受信された前記使用条件から一部を抽出し、 部 分使用条件を生成する抽出ステップと、 ' 前記抽出ステップの処理により生成された前記部分使用条件をユーザに配布す る配布ステップと
を含むことを特徴とする情報処理方法。
6 . コンテンッの使用条件を規定する利用権を配布する情報処理装置のプログ ラムであって、
前記使用条件を含む情報を受信する受信ステップと、
前記受信ステップの処理により受信された前記使用条件から一部を抽出し、 部 分使用条件を生成する抽出ステップと、
前記抽出ステップの処理により生成された前記部分使用条件をユーザに配布す る配布ステップと
を含むことを特徴とするコンピュータが読み取り可能なプログラムが格納され ているプログラム格納媒体。
7 . コンテンツの使用条件を規定する利用権を配布する情報処理装置を制御す るコンピュータに、
前記使用条件を含む情報を受信する受信ステップと、
前記受信ステップの処理により受信された前記使用条件から一部を抽出し、 部 分使用条件を生成する抽出ステップと、
前記抽出ステップの処理により生成された前記部分使用条件をユーザに配布す る配布ステップと
を実行させることを特徴とするプログラム。
PCT/JP2003/004544 2002-04-15 2003-04-10 Dispositif et procede de traitement d'informations, support de programme et programme WO2003088114A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US10/480,315 US20050119967A1 (en) 2002-04-15 2003-04-10 Information processing device and method, program storage medium and program
KR1020037016281A KR100957899B1 (ko) 2002-04-15 2003-04-10 정보 처리 장치 및 방법, 프로그램 저장 매체, 및 프로그램
EP03717551A EP1496459A4 (en) 2002-04-15 2003-04-10 INFORMATION PROCESSING DEVICE AND METHOD, PROGRAM SUPPORT, AND PROGRAM

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2002111927A JP4447821B2 (ja) 2002-04-15 2002-04-15 情報処理装置および方法
JP2002-111927 2002-04-15

Publications (1)

Publication Number Publication Date
WO2003088114A1 true WO2003088114A1 (fr) 2003-10-23

Family

ID=29243296

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2003/004544 WO2003088114A1 (fr) 2002-04-15 2003-04-10 Dispositif et procede de traitement d'informations, support de programme et programme

Country Status (6)

Country Link
US (1) US20050119967A1 (ja)
EP (1) EP1496459A4 (ja)
JP (1) JP4447821B2 (ja)
KR (1) KR100957899B1 (ja)
CN (1) CN1545676A (ja)
WO (1) WO2003088114A1 (ja)

Families Citing this family (50)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100499450C (zh) * 2003-04-22 2009-06-10 国际商业机器公司 数字资源的分层密钥生成方法及其设备
US7624284B2 (en) * 2003-05-06 2009-11-24 Infoprint Solutions Company Llc Secure print control and rights management system
US20050108333A1 (en) * 2003-10-31 2005-05-19 Martin Scholz Blocking input with delayed message
US8402283B1 (en) 2004-08-02 2013-03-19 Nvidia Corporation Secure content enabled drive system and method
US8359332B1 (en) 2004-08-02 2013-01-22 Nvidia Corporation Secure content enabled drive digital rights management system and method
US20060031873A1 (en) * 2004-08-09 2006-02-09 Comcast Cable Holdings, Llc System and method for reduced hierarchy key management
JP4748762B2 (ja) * 2004-08-24 2011-08-17 キヤノン株式会社 署名生成方法及び情報処理装置
JP2008520025A (ja) * 2004-11-11 2008-06-12 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ ディジタル・ライセンスを処理する方法及び装置
US8099369B2 (en) * 2004-12-08 2012-01-17 Ngna, Llc Method and system for securing content in media systems
US8788425B1 (en) 2004-12-15 2014-07-22 Nvidia Corporation Method and system for accessing content on demand
US8751825B1 (en) 2004-12-15 2014-06-10 Nvidia Corporation Content server and method of storing content
US8346807B1 (en) 2004-12-15 2013-01-01 Nvidia Corporation Method and system for registering and activating content
US8875309B1 (en) * 2004-12-15 2014-10-28 Nvidia Corporation Content server and method of providing content therefrom
US7383438B2 (en) * 2004-12-18 2008-06-03 Comcast Cable Holdings, Llc System and method for secure conditional access download and reconfiguration
US7933410B2 (en) * 2005-02-16 2011-04-26 Comcast Cable Holdings, Llc System and method for a variable key ladder
US20060200412A1 (en) * 2005-02-23 2006-09-07 Comcast Cable Holdings, Llc System and method for DRM regional and timezone key management
US8893299B1 (en) 2005-04-22 2014-11-18 Nvidia Corporation Content keys for authorizing access to content
CN101180850B (zh) * 2005-05-19 2011-10-05 爱利亚有限责任公司 经授权的域政策方法
KR100827227B1 (ko) 2005-06-24 2008-05-07 삼성전자주식회사 저성능 저장장치의 ｄｒｍ 권리 객체를 효율적으로관리하는 방법 및 장치
US20070027809A1 (en) * 2005-08-01 2007-02-01 Jukka Alve Method for signaling geographical constraints
CN101322344B (zh) 2005-10-21 2013-01-02 尼尔逊媒介研究股份有限公司 用于计量便携式媒体播放器的方法和装置
KR100813973B1 (ko) * 2006-01-03 2008-03-14 삼성전자주식회사 복수의 사용 제한 정보들을 포함하는 컨텐트를 임포트하는장치 및 방법
CA2947649C (en) 2006-03-27 2020-04-14 The Nielsen Company (Us), Llc Methods and systems to meter media content presented on a wireless communication device
HUE030535T2 (en) * 2006-06-27 2017-05-29 Waterfall Security Solutions Ltd One-way security connections from a security operating unit to a security operating unit
IL177756A (en) * 2006-08-29 2014-11-30 Lior Frenkel Encryption-based protection against attacks
KR100869945B1 (ko) * 2006-11-03 2008-11-24 삼성전자주식회사 Ｄｒｍ 권한 개선 방법과 ｄｒｍ 권한 개선 컨텐츠 및 이를이용하는 휴대 단말기
JPWO2008059559A1 (ja) * 2006-11-13 2010-02-25 パイオニア株式会社 コンテンツ配信装置、コンテンツ再生装置、コンテンツ記録装置、コンテンツ配信方法、コンテンツ再生方法、コンテンツ記録方法、コンテンツ配信プログラム、コンテンツ再生プログラム、コンテンツ記録プログラムおよびコンピュータに読み取り可能な記録媒体
IL180020A (en) * 2006-12-12 2013-03-24 Waterfall Security Solutions Ltd Encryption -and decryption-enabled interfaces
US8812579B2 (en) * 2006-12-21 2014-08-19 Verizon Patent And Licensing Inc. Apparatus for transferring data via a proxy server and an associated method and computer program product
KR101354759B1 (ko) * 2007-01-03 2014-01-22 엘지전자 주식회사 단말기의 디지털 저작권 관리방법
IL180748A (en) * 2007-01-16 2013-03-24 Waterfall Security Solutions Ltd Secure archive
KR20080084481A (ko) * 2007-03-16 2008-09-19 삼성전자주식회사 디바이스간의 콘텐츠 전송 방법 및 그 시스템
TWI357068B (en) * 2007-03-19 2012-01-21 Cyberlink Corp Method for activating audio/video data in an optic
US20080294453A1 (en) * 2007-05-24 2008-11-27 La La Media, Inc. Network Based Digital Rights Management System
US7907735B2 (en) 2007-06-15 2011-03-15 Koolspan, Inc. System and method of creating and sending broadcast and multicast data
KR20090011152A (ko) * 2007-07-25 2009-02-02 삼성전자주식회사 콘텐츠 제공 방법 및 시스템
US7934083B2 (en) * 2007-09-14 2011-04-26 Kevin Norman Taylor Configurable access kernel
US8223205B2 (en) 2007-10-24 2012-07-17 Waterfall Solutions Ltd. Secure implementation of network-based sensors
JP5087014B2 (ja) * 2009-01-06 2012-11-28 株式会社東芝 情報処理装置、および再生装置
US9679163B2 (en) * 2012-01-17 2017-06-13 Microsoft Technology Licensing, Llc Installation and management of client extensions
US9256445B2 (en) 2012-01-30 2016-02-09 Microsoft Technology Licensing, Llc Dynamic extension view with multiple levels of expansion
US9449112B2 (en) 2012-01-30 2016-09-20 Microsoft Technology Licensing, Llc Extension activation for related documents
US9635037B2 (en) 2012-09-06 2017-04-25 Waterfall Security Solutions Ltd. Remote control of secure installations
US9325381B2 (en) 2013-03-15 2016-04-26 The Nielsen Company (Us), Llc Methods, apparatus and articles of manufacture to monitor mobile devices
US9419975B2 (en) 2013-04-22 2016-08-16 Waterfall Security Solutions Ltd. Bi-directional communication over a one-way link
IL235175A (en) 2014-10-19 2017-08-31 Frenkel Lior Secure desktop remote control
CN105743885B (zh) * 2016-01-22 2019-09-27 山东大学（威海） 基于多级服务器客户端模式的数据文件收发方法和装置
IL250010B (en) 2016-02-14 2020-04-30 Waterfall Security Solutions Ltd Secure connection with protected facilities
US11055437B2 (en) * 2018-02-02 2021-07-06 Florida Atlantic University Board Of Trustees Systems and methods for ensuring privacy in online information sharing applications
CN110909382B (zh) * 2019-11-14 2022-11-04 北京字节跳动网络技术有限公司 数据安全控制方法、装置、电子设备及计算机可读介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0715247A1 (en) 1994-11-23 1996-06-05 Xerox Corporation System for controlling the distribution and use of digital works using digital tickets
JPH08272746A (ja) * 1994-11-23 1996-10-18 Xerox Corp 料金通知メカニズムを有するディジタルワークの配給及び使用を制御するためのシステムと料金通知方法
JP2000331087A (ja) * 1999-05-25 2000-11-30 Sony Corp ソフトウェア課金システム、ソフトウェア販売装置、ソフトウェア再生装置、ソフトウェア課金方法及び記録媒体
JP2001344437A (ja) * 2000-05-31 2001-12-14 Sony Corp データ配信方法とそのシステム、データ使用装置および配信用データが記録された記録媒体

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5629980A (en) * 1994-11-23 1997-05-13 Xerox Corporation System for controlling the distribution and use of digital works
US5715403A (en) * 1994-11-23 1998-02-03 Xerox Corporation System for controlling the distribution and use of digital works having attached usage rights where the usage rights are defined by a usage rights grammar
US5638443A (en) * 1994-11-23 1997-06-10 Xerox Corporation System for controlling the distribution and use of composite digital works
US6226618B1 (en) * 1998-08-13 2001-05-01 International Business Machines Corporation Electronic content delivery system
US20020107809A1 (en) * 2000-06-02 2002-08-08 Biddle John Denton System and method for licensing management
US7050586B1 (en) * 2000-06-19 2006-05-23 Intertrust Technologies Corporation Systems and methods for retrofitting electronic appliances to accept different content formats
US7203966B2 (en) * 2001-06-27 2007-04-10 Microsoft Corporation Enforcement architecture and method for digital rights management system for roaming a license to a plurality of user devices

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0715247A1 (en) 1994-11-23 1996-06-05 Xerox Corporation System for controlling the distribution and use of digital works using digital tickets
JPH08272746A (ja) * 1994-11-23 1996-10-18 Xerox Corp 料金通知メカニズムを有するディジタルワークの配給及び使用を制御するためのシステムと料金通知方法
JP2000331087A (ja) * 1999-05-25 2000-11-30 Sony Corp ソフトウェア課金システム、ソフトウェア販売装置、ソフトウェア再生装置、ソフトウェア課金方法及び記録媒体
JP2001344437A (ja) * 2000-05-31 2001-12-14 Sony Corp データ配信方法とそのシステム、データ使用装置および配信用データが記録された記録媒体

Also Published As

Publication number Publication date
JP2003308440A (ja) 2003-10-31
EP1496459A1 (en) 2005-01-12
KR20040103747A (ko) 2004-12-09
US20050119967A1 (en) 2005-06-02
CN1545676A (zh) 2004-11-10
KR100957899B1 (ko) 2010-05-13
EP1496459A4 (en) 2008-07-30
JP4447821B2 (ja) 2010-04-07

Similar Documents

Publication Publication Date Title
WO2003088114A1 (fr) Dispositif et procede de traitement d&#39;informations, support de programme et programme
JP4326186B2 (ja) 情報処理装置および方法
US7325139B2 (en) Information processing device, method, and program
US20050021783A1 (en) Information processing apparatus and method
US7336791B2 (en) Information processing apparatus
KR100983982B1 (ko) 정보 처리 장치 및 정보 처리 방법과 컴퓨터 판독 가능 기록 매체
US7426639B2 (en) Information processing apparatus and method for managing grouped devices in an encrypted environment
US20070044159A1 (en) Information processing apparatus
US20050015343A1 (en) License management device, license management method, and computer program
US20030185397A1 (en) Information processing apparatus
JP2003308252A (ja) 情報処理装置および方法、記録媒体、並びにプログラム
JP4391056B2 (ja) 情報管理装置および方法、記録媒体、並びにプログラム
JP2004227282A (ja) コンテンツ配信システム、情報処理装置又は情報処理方法、並びにコンピュータ・プログラム
KR20040103750A (ko) 정보 처리 장치 및 방법, 기록 매체, 및 프로그램
JP4640374B2 (ja) 情報処理装置および方法、プログラム格納媒体、並びにプログラム
JP4479698B2 (ja) コンテンツ提供システム
KR100608849B1 (ko) 디지털 컨텐츠의 보안 방법
KR20050116786A (ko) 디지털 컨텐츠의 보안 방법
KR20050109417A (ko) 디지털 컨텐츠의 재생 제어 방법
KR20060056294A (ko) 디지털 컨텐츠의 재생 제어 방법

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): CN KR US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT RO SE SI SK TR

WWE Wipo information: entry into national phase

Ref document number: 2003717551

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 10480315

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 1020037016281

Country of ref document: KR

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 20038008378

Country of ref document: CN

WWP Wipo information: published in national office

Ref document number: 2003717551

Country of ref document: EP