WO2020090118A1 - Digital content license management system using blockchain technology - Google Patents

Abstract

Provided are a series of automatic tools which improve the efficiency of the content publishing industry with respect to digital content license management. The digital content license management system 1 includes a transaction processing unit 40 and a license token storage unit 60, wherein, when a new license token is derived on the basis of a license token stored in the license token storage unit 60, the transaction processing unit 40 generates at least one piece of input information including identification information for specifying an original license token and information for specifying output information about the original license token, at least one piece of output information, and identification information about the license token, and stores the input information, the output information, and the identification information in the licensing token storage unit 60 as the new license token.

Description

Digital content license management system utilizing blockchain technology

The present invention relates to a digital content license management system that enables license management of digital content using blockchain technology.

Conventionally, an efficient data structure that can easily capture a typical license hierarchy as shown in FIG. 13 has been frequently used in the content publishing industry. However, while works of art are created by copyright holders around the world, there is no effective way to manage the distribution of usage rights and the creation of derivative works.

In this FIG. 13, a copyright holder 100 who owns an intellectual property 200 such as a movie content has a worldwide exclusive derivative license 210 based on the intellectual property 200 (with the intellectual property 200 as a parent). Is generated and transferred to a global publisher 110, who owns a worldwide exclusive derivative license 210. In addition, the global publisher 110 generates a country-specific derivative license 220 (based on the global exclusive derivative license 210 as a parent) based on the global exclusive derivative license 210, and publishes the regional publisher. Assigned to 120, publishers 120 in the region own derivative licenses 220 by country. Further, the regional publishing company 120 generates an individual derivative license 230 and transfers it to the individual 130 based on the country derivative license 220 (with the country derivative license as a parent). Owns a derivative license 230 of This individual derivative license 230 is used to control the use of an individual's 130 use (consumption) of a copy 240 of intellectual property 200.

A method of managing a license hierarchy as shown in FIG. 13 by applying a blockchain technology is disclosed (for example, refer to Patent Document 1).

U.S. Patent Application Publication No. 2018/0115416

For the license hierarchy as shown in Fig. 13, in most cases, the contract is captured as a document, so there are subtle differences even between the standard contract clauses. This makes it difficult for preparers, distributors and consumers to gain the transparency needed to create an efficient market. Market inefficiency will eventually be transmitted to consumers, and removal of this inefficiency will eventually reduce the burden on the entire distribution chain.

The present invention has been made in view of the above problems, and an object thereof is to provide a series of automatic tools for improving the efficiency of the content publishing industry regarding license management of digital content.

In order to solve the above problems, a digital content license management system according to the present invention includes a transaction processing unit that generates a license token and a license token storage unit that stores the license token, and the license token includes: The transaction processing unit has at least one output information and identification information for uniquely identifying the license token, and the transaction processing unit creates a new license token based on the license token stored in the license token storage unit. When deriving, at least one input information including identification information that identifies the original license token and information that identifies the output information of the original license token, at least one output information, and the license token. Identification information Generates, the input information is stored in the license token storing unit the output information and the identification information as the new license tokens.

Also, in the digital content license management system according to the present invention, the transaction processing unit adds the maximum value of the number of license tokens that can be derived from the original license token to the output information of the original license token. And a distribution unit equal to or smaller than the distribution unit set in the output information of the original license token specified by the input information is set in the input information of the new license token. Preferably.

Further, in the digital content license management system according to the present invention, the transaction processing unit sets the distribution unit in the output information of the new license token, and sets the output information included in the new license token. It is preferable that the total of the distribution units to be set is matched with the distribution unit set in the input information included in the new license token.

Further, in the digital content license management system according to the present invention, the transaction processing unit may associate the output information of the original license token with the input information of the new license token in a one-to-one correspondence. preferable.

Further, in the digital content license management system according to the present invention, the transaction processing unit uses the identification information as a signature generated from all the output information and the input information included in the license token identified by the identification information. It is preferably information.

Further, in the digital content license management system according to the present invention, a predetermined program can be set in the output information and the input information, and the transaction processing unit is configured to derive the new license token. Further, it is preferable that the program of the input information of the new license token and the program of the output information of the original license token specified by the input information can be executed.

Further, in the digital content license management system according to the present invention, the output information includes information for limiting the owner of the new license token when a new license token is derived from the license token including the output information. The transaction processing unit derives the new license token only when the owner of the new license token is the owner set in the output information of the original license token. Preferably.

Further, in the digital content license management system according to the present invention, the output information can be set with information regarding a period during which a new license token can be derived from a license token including the output information. It is preferable that the section derives the new license token only during the period set in the output information of the original license token.

Further, in the digital content license management system according to the present invention, the output information can be set with information on an area where a new license token can be derived from a license token including the output information. It is preferable that the section derives the new license token only when the area licensed by the new license token is the area set in the output information of the original license token.

Further, in the digital content license management system according to the present invention, the output information can be set with information on content licensed by a license token including the output information, and the transaction processing unit serves as the source. It is preferable to derive the new license token only when the content corresponding to the content information set in the output information of the license token is stored in a predetermined storage unit.

Further, in the digital content license management system according to the present invention, the transaction processing unit, when deriving the new license token, based on the program set in the input information included in the new license token, It is preferable to record information about the derivation of the new license token.

According to the present invention, it is possible to provide a series of automatic tools for improving the efficiency of the content publishing industry regarding license management of digital content.

It is a block diagram showing a configuration of a digital content license management system. It is explanatory drawing which shows the data structure of an origin license token. It is explanatory drawing which shows the data structure of a derivative license token. It is explanatory drawing which shows the connected license token. It is explanatory drawing which shows the data structure of a license token storage part. It is explanatory drawing which shows the production | generation process of an origin license token. It is explanatory drawing which shows the production | generation process of a derivative license token. FIG. 9 is an explanatory diagram of a table that defines permission / non-permission of license token generation according to the attributes of participants. It is explanatory drawing which shows the chain of the license token when it licenses with the combination of the music which changes for every area. It is the figure which represented the structure of FIG. 9 by the conventional license hierarchy. It is explanatory drawing which shows the chain of the license token in the case of on-demand streaming. It is an explanatory view showing a chain of license tokens in the case of batch sale of license tokens. It is explanatory drawing which shows a typical license hierarchy.

Hereinafter, preferred embodiments of the present invention will be described with reference to the drawings. This section describes an efficient data structure that uses rules (programming language) that can understand content license scenarios that are common in the publishing industry. Here we show how participants in the content publishing industry can use these data structures and explain how the individual parts of the architecture work together. This effectively finds ways to tokenize licenses and simplify management of complex content distribution chains.

First, the schematic configuration of the digital content license management system 1 will be described with reference to FIG. In FIG. 1, a rectangular element indicates a data storage unit, an elliptic element indicates a terminal of a participant who uses the digital content license management system 1, and an octagonal element indicates a data processing unit.

The participant uses the license management user interface (LMUI) 20 from the terminal 10 to generate a license (license token). In generating the license token, the participant's private key is retrieved from the key storage unit 30 and used. Further, the generated license token is transmitted to the transaction processing unit 40. In addition, in FIG. 2, as the terminal 10 of the participant, a distributor terminal 11, a publisher terminal 12, a content creator terminal 13, and a trustee terminal 14 are shown, but these participants are examples. It's just an example and more people can participate.

The transaction processing unit 40 uses the content evaluation unit 50 to confirm the content ID to ensure that the content referenced by the license token is registered. Further, the license token storage unit 60 is used to store the newly created license token, and the license token created by referring to the other license token conforms to the rule stipulated in the other referenced license token. Test for compliance.

Next, the license token will be described. The license token L created by the license management user interface 20 through the terminal 10 of the participant P is defined as a data structure including all necessary for describing the license. This license token consists of an input I _i , an output O _j , and a signature (signature digest) S _M.

Specifically, the input I _i (I ₁ , ..., I _n ) indicates the input of one or more license tokens. The output O _j (O ₁ , ..., O _n ) indicates the output of one or more license tokens. The subscript n shown in the input I and the output O is a natural number. Also, S _M represents the signature (signature digest) of all the previous information M signed by the participant P who generates the license token.

License tokens create and consume distribution units of content that may be consumed by individual consumers. In the following description, this distribution unit is indicated as U. For example, a music album can be limited to the creation of 100 distribution units (100U). In a digital music store, this means you can buy the album 100 times. Specifically, for the content whose content ID is C, the distribution unit is counted as U _C.

A single license token can include distribution units for several works of art, and the resulting license token is called a composite license token. That is, the generation and consumption of the above-mentioned distribution unit is obtained by the input I _i of the license token and the output O _i of the license token, and these inputs and outputs are composed of a single license token and a composite license token. be able to. This allows the license to include not only a single song, but the entire album.

The structure of the license token described above will be specifically described with reference to the drawings. First, as a license token, the origin license token (Genesis LicenseToken: GLT) and the derivative license token (DerivativeLicense Token: DLT) are specified.

The origin license token (GLT) is a license token generated for the content created by the content creator, and in the configuration of FIG. 1, for example, is generated and registered by the terminal 13 of the content creator. As shown in FIG. 2, this origin license token (GLT) has no input and stores the output O _j and the signature digest S _M. The “selective comment” shown in FIG. 2 is used to display information such as the purpose for which each license token was generated when the license token is described by the notation method of FIG. You have not configured a token.

The derivative license token (DLT) is a license token generated when the license is transferred. In the configuration of FIG. 1, for example, the terminals 11, 12, and 14 other than the content creator generate and register the license token. It As shown in FIG. 3, the derivative license token (DLT) stores the input I _i , the output O _j, and the signature digest S _M. The “selective comment” is treated in the same manner as the above-mentioned origin license token.

FIG. 4 shows a case where a derivative license token (DLT) is generated by using an origin license token (GLT) as a parent, and these license tokens form a chain of licenses that are chained via an input and an output. is doing. In the case where one output of the license token (distribution unit) is connected to the input of another license token, a label such as 100U indicating the distribution unit (upper limit) can be added to the arrow when illustrated. Also, the input distribution unit can be divided into a plurality of license tokens and output, and each can be used as the input of the next license token. In addition, FIG. 4 shows a case where a distribution unit defined as 100 U in the output 1 of the origin license token GLT is divided by setting 99 U in the output 1 of the derived license token DLT and 1 U in the output 2. There is. Here, the distribution unit of the input (input 1) of the child license token (DLT in FIG. 4) is set to the output (output 1) of the parent license token (GLT in FIG. 4) to which this input is connected. It is set not to exceed the distribution unit. Further, the total of distribution units (99U + 1U) assigned to outputs 1 and 2 of the child license token (DLT in FIG. 4) matches the distribution unit (100U) set in the input 1 of the child license token DLT. To do.

Moreover, the unused license token output (Unspent LicenseToken Output: ULTO) indicates the output that is not yet connected to the input of another license token among the outputs set in the license token (GLT, DLT). This unused license token output may be managed by the transaction processing unit 40 in order to improve the processing speed. However, even if the unused license token output is not managed, the information stored in the license token 60 can be used. You can search and extract unused output.

Each input I _i must be connected to one license output O _i . On the other hand, the output O _{i of the} license token can be connected to one license input I _i (there is also the state of the unused license token output as described above). The resulting connected license tokens can form a directed acyclic graph (DAG), which can lead to many interesting and useful mathematical properties, where these properties can be exploited further, but here Is omitted.

Here, the signature on the license token will be described. First, a unique cipher for a given message M calculated using an asymmetric cryptographic scheme such as elliptic curve cryptography (ECC) or RSA (Rivest-Shamir-Adleman) using the participant's unique secret key K _pr. A signature abbreviated as S _M is defined as a digest. The participant's public key K _pu can then be recovered using the recovery function rec (m, s) and the following equation (1) is true for all possible messages M.

rec (M, sign (M, K _pr )) = K _pu (1)

Also, to get the message M, given inputs I ₁ ,. ． ． , I _n and O ₁ ,. ． ． , O _n and the concatenated function cat that can be used for the following equation (2).

M: = cat (<I ₁ , ..., I _n >, <O ₁ , ..., O _n >) (2)

By using this concatenation function cat, the signature (signature digest) S _M can be calculated for the data structure of the license token L as shown in the following expression (3).

S _M : = sign (M, K _pr ) (3)

In most cases, for all combinations of the input I _n and the output O _n is unique, can also function signature S _M as a unique identifier for all license tokens L. Also, it is not necessary to store the identification information of the license token creator. This is because the unique public key can be recovered simply by looking at the contents of the license token and signature.

The license token input and license token output include rules (small programs) written in a formal language, although detailed description is omitted. The input or output program R is written as R (I _i ) or R (O _i ), respectively. Using a formal language, a license token can use other license token outputs as input and provide output that other license tokens can use as input.

Here, the purpose of the program R (O _i ) of the output O is
(1) Limit how many distribution units such as downloads are created using this license token. (2) How payment and revenue sharing should be configured when creating a derivative license token, for example, currency, amount of money. , Specify information such as payment conditions (3) Specify the identification information and public key of the user who is allowed to connect to the output of the license token (4) Limit the period during which derivative license tokens can be created ( 5) To define a number of rules that can be reliably coded and evaluated using computer programs.

Also, the purpose of the program R (I _i ) of the input I is to record how the rules of the output program were executed. Specifically, in response to the above output,
(1) The identifier of the output program used and the license token in which it is placed (2) Proof that the creator of the derived license token has permission to use the license token output (3) Bank note or Payment proofs such as wire transfer cryptographic transaction hashes or other legal proofs (or other forms of payment) (4) Many that can be reliably encoded and evaluated using computer programs The proofs of are recorded.

The license token can contain any number of I / O programs, but in most practical cases this number should be in the range of approximately 1-10 per license token.

It should be noted here that the input of the license token and the subsequent output of the license token are substantially destruction and generation of the distribution unit. For example, in an unused transaction output (UTXO) of virtual currency such as bitcoin, all transactions (excluding coin-based transactions) consume the virtual currency and create a new virtual currency as the output.

Similar to the configuration of such virtual currency, in the digital content license management system 1 according to the present embodiment, as shown in FIG. 4, a child license token (DLT) is generated based on a parent license token (GLT). When generated, the distribution unit set in the output 1 of the parent license token GLT is destroyed and generated as the outputs 1 and 2 of the child license token DLT. When the child license token DLT is generated, the distribution unit set in the output 1 of the parent license token GLT cannot be used. In this way, the digital content license management system 1 according to the present embodiment enables complete traceability of movement of distribution units.

Below, an example of the functions specified in the programming language for describing the input and output rules of the license token is explained. First, Table 1 shows functions that can be commonly used for output and input.

(Table 1) Common output / input functions
and (f, g, ...) Evaluates the arguments f, g, ... and is true if all are true
or (f, g, ...) Evaluates the arguments f, g, ... and is true if at least one is true
scale (f, n) sets the distribution unit of f with integer n
unit (i) Specify 1U for i (content ID) that is generated or consumed

Next, Table 2 shows the functions that can be used for output.

(Table 2) Output function
id (K _pu ) _Evaluate that the participant using the output has the public key K _pu
pay (rule) Specifies that payment will be made according to an arbitrary rule
term (f, t) Validate rule f until time t
region (f, r) validate rule f in geographic region r

Finally, Table 3 shows the functions that can be used for input.

<Input function>
use (l, o) use output o from license token l
The encrypted challenge response contained in id (K _pu , response) proves that the participant using the output has the public key K _pu.
Prove that the payment rules are met by proving the pay (rule, response, eg, a currency transaction, hash, etc.)

The creator of the parent license token (eg, GLT in FIG. 4) can limit the creator of the child license token (DLT in FIG. 4) with the public key. This can be realized by describing the above-mentioned function id (K _pu ) in the output program. That is, the public key _Kpu can lock the output to the owner of the correct key pair.

As mentioned above, only the owner of the private key K _pr can generate a signature corresponding to this private key, but anyone can tell if the signature was actually created by the private key owner. You can check without knowing the key itself.

With the encrypted challenge-response method, the challenge must be unique and cannot be reused a second time.

For the encrypted challenge given by the function id (K _pu ), the transaction processing unit 40 outputs the output of the derived license token DLT used as the challenge, as shown in the following equation (4). Select the signature S _M and the output number i.

challenge: = <S _M , i> (4)

Then, only the consumer who is the correct output of the derived license token DLT can generate a response by the following equation (5).

response; = sign (challenge, _Kpr ) (5)

Further, the license evaluation unit of the transaction processing unit 40 can evaluate by judging whether the relation of the following expression (6) is established. Here, rec is the recovery function described in equation (1).

rec (response, K _pu ) = K _pu (6)

From the above, the transaction processing unit 40 confirms that the correct participant has created the derivative license token DLT. You can now try to write some business rules using this language.

The following shows examples of input and output programs.

(List 1) Output program example
and (
scale (unit ("0xcd93 ..."), 100),
id ("0x4609 ..."),
pay ("Pay 1 BTC to 1Fwhj ..."),
)

The output program shown in Listing 1 uses the scale function and the id function to "allow a participant having a public key of 0x4609 to consume 100U of the content having the content ID of 0xcd03 as a distribution unit". It also represents the rule, and the pay function is used to represent the rule “pay virtual currency 1BTC to the address 1Fwhj”. By writing the output program in this way, specify the content to be licensed, limit the creators of license tokens that can connect to the output, and further specify the payment amount and payee for the license. You can

(List 2) Input program example
and (
use (L, 0),
scale (unit ("0xcd93 ..."), 100),
id ("0x4609 ...", "0xe11c ..."),
pay ("Pay 1 BTC to 1Fwhj ...", "The transaction hash is 0x512f ...").
)

The input program shown in Listing 2 uses the use function to specify “the parent license token L and the output of that license token (for example,“ 0 ”specifies the 0th output from the top). The rule that "a participant having a public key of 0x4609 consumes 100 U of content having a content ID of 0xcd93 as a distribution unit" using the scale function, the unit function, and the id function. And the pay function is used to express the rule that "the virtual currency 1BTC is paid to the address 1Fwhj and the hash value in the transaction is 0x512f". By writing the input program in this way, the parent license and the output of the parent license are specified, and the creator and distribution unit of the license token that can connect to the licensed content and output are limited. Further, information regarding payment such as the amount paid for the license and the payee can be specified.

Next, a more complicated example of the entry / exit program is shown.

(List 3) More complex output program example
and (
or (
and (
term (
scale (unit ("0x6d9a ..."), 100),
"2018-12-31",
),
pay ("EUR 100 to DE123123 ..."),
),
and (
scale (unit ("0x6d9a ..."), 50),
pay ("EUR 110 to DE123123"),
id ("0x76c3 ..."),
),
),
)

The output program shown in Listing 3 uses the term function, the scale function, and the pay function to "permit consumption of 100 U as the distribution unit for the content having the content ID of 0x6d9a, but the expiration date is December 2018. It is up to the 31st of the month and 100 euros will be paid to an account called DE123123 ". In addition, using the scale function, pay function and id function, "allowing the participant having the public key of 0x763c to consume 50U of the content having the content ID of 0x6d9a as a distribution unit, 110 euros" Is paid to an account called DE123123 ”. These two rules are written in the or function, so only one rule applies. Thus, by using the term function, you can determine the time limit for granting a license.

(List 4) Example of a more complicated input program
and (
#Where L is the above license token and O is the first specified #single output rule use (L, O),
scale (unit ("0x6d9a ..."), 100),
# Attach proof of payment pay ("EUR 100 to DE123123 ...", "0xc187 ..."),
)

The input program shown in Listing 4 corresponds to the first written program (the first listed function of the two and functions listed in the or function) of the output programs shown in Listing 3 Using a function, a rule "a parent license token L and the output of the license token to be connected (for example," 0 "designates the 0th output from the top)" , Scale function, unit function and id function, using the rule that "a participant having a public key of 0x4609 consumes 100 U of a content having a content ID of 0xcd93 as a distribution unit", and a pay function, It represents the rule that "100 euro is paid to the account DE123123 and the response is 0xe11c". Note that “#” in List 4 indicates that the description after that line is a comment.

By defining in the output rule R (O) a license token that contains one output having the rules shown in Listing 3 above, the participant uses the distribution rule listed in the output as the input shown in Listing 4 Can be generated. Then, when the transaction processing unit 40 verifies this input, it is given the right to create an output rule in the same license token that outputs the distribution unit for the content of the same content ID.

Note that the content ID in the above description is unique to a digital art work (eg, MP3 music file, WAVE file mastered in the studio, uncompressed video file, subtitle file in a specific machine-readable format, etc.). The identifier is abbreviated as C and is abbreviated as C in the following description. This content ID is calculated by applying a cryptographic hash function, such as SHA-3, to the digital form of the work, resulting in a properly formatted cryptographic hash. For example, the cryptographic hash is 0x. ． ． ． It is shown as any string of the form. Alternatively, the content ID is calculated using a unique content identifier, such as a digital object identifier (DOI) as found in the entertainment identifier registry (EIDR).

Participant P can also create and sign a license token as an authorized network participant. The transaction processing unit 40 recognizes the roles of different participants. This role, including those shown in Figure 2, artists, book publishers, consumers, distributors, game publishers, game studios, movie studios, music labels, trustees (in case of bankruptcy, etc. To participate in).

How the license token (single distribution unit) sold to the consumer is processed is not described in detail here, but for example, a DRM-based system can be used.

License token storage section 60, as shown in FIG. 5, information constituting a license token (signature S _M, inputs I _1, ..., I _n, the output O _1, ..., O _n) tabular Store with. Only a license token can be added to this license token storage unit 60. In other words, the license token cannot be deleted from the license token storage unit 60. Therefore, the license token storage unit 60 is an additional-only data storage.

The transaction processing unit 40 manages the life cycle of the license token and its distribution unit. This section describes how to create new origin license tokens and derivative license tokens.

First, the method of creating the origin license token (GLT) by the transaction processing unit 40 will be described with reference to FIG. The participant (for example, content creator) uses the terminal 10 (in the case of the content creator, the participant terminal 13 for the content creator) and the origin license token (GLT) using the license management user interface 20. Is generated (step S100). At this time, from the participant terminal 13 to the license management user interface 20, the content ID, which is information for identifying the content for which the license is to be generated, and the information on the usage condition of the content (the number of distribution units, etc.) Will be sent. Note that the content itself for which the license is generated is stored in advance in a content storage unit (not shown in FIG. 1), and the content ID is also calculated when the content is stored.

The license management user interface 20 determines the output O _i based on the content ID specified in the participant terminal 13 and the usage conditions of the content, acquires the secret key of the content creator from the key storage unit 30, and signs it. S _M is calculated to generate a signed license token (GLT) consisting of the output O _i and the signature S _M (step S110). The signed license token is transmitted to the transaction processing unit 40 (step S120). List 5 shows an example of the program of output 1 set in the origin license token GLT having the configuration shown in FIG. In the output 1 of the origin license token GLT in FIG. 4, 100U is set as a distribution unit. Further, the content ID designated by the unit function is not specifically described.

(List 5) Example of program 1 of output 1 of origin license token GLT shown in FIG.
scale (
unit ('Content ID "),
100,
)

The transaction processing unit 40 that has received the signed license token evaluates the syntax of the signed license token (step S130). Then, the transaction processing unit 40 transmits the content ID of the content corresponding to the signed license token to the content evaluation unit 50 based on the rule (program) described as the output O _i , and the content is registered. Is inquired (step S140). On the other hand, the content evaluation unit 50 transmits the evaluation result of the received content ID to the transaction processing unit 40 (step S150). When the transaction processing unit 40 evaluates the output program of the signed license token and determines that the content is registered (step S160), the transaction processing unit 40 stores the license token in the license storage unit 60. When an instruction is given (step S170) and a notification that the license token is stored is received from the license token storage unit 60 (step S180), a confirmation of generation of the license token is transmitted to the license management user interface 20 (step S190). The license management user interface 20 transmits a confirmation of generation of the license token to the participant terminal 13 (step S195), and ends the generation processing of the original license token.

Next, a method of creating a derivative license token (DLT) by the transaction processing unit 40 will be described with reference to FIG. The participant (for example, distributor) uses the terminal 10 (in the case of the distributor, the participant terminal 11 for the distributor) to generate the derivative license token (DLT) using the license management user interface 20. Instruct (step S200). At this time, the signature S _M , which is information for specifying the parent license token (eg, GLT in the example of FIG. 5) from the participant terminal 11 to the license management user interface 20, Of the output O _i included in the license token specified by this signature S _M , information that specifies which output is connected to the input of the license token to be generated, and the usage conditions of the content (the number of distribution units, etc.) Information is sent.

The license management user interface 20 determines the output O _i and the input I _i based on the signature S _M of the parent license token designated by the participant terminal 11, the output information to be connected, and the usage conditions of the content, The secret key of the content creator is obtained from the key storage unit 30, the signature S _M is calculated, and a signed license token (DLT) composed of the output O _i , the input I _i and the signature S _M is generated ( In step S210), the signed license token is transmitted to the transaction processing unit 40 (step S220). Lists 6 to 8 show examples of programs of input 1, output 1 and output 2 set in the derived license token DLT having the configuration shown in FIG. In the derivative license token DLT in FIG. 4, of the 100 U distribution unit received from the output 1 of the origin license token GLT1 at the input 1, 99 U is allocated to the output 1 and 1 U is allocated to the output 2.

(List 6) Example of program of input 1 of derivative license token DLT shown in FIG.
and (
use ('GLT License', 1),
scale (
unit ('Content ID'),
100,
)
)

(List 7) Example of program of output 1 of derivative license token DLT shown in FIG.
scale (
unit ('Content ID "),
99,
)

(List 8) Example of program of output 2 of derivative license token DLT shown in FIG.
scale (
unit ('Content ID "),
1,
)

The transaction processing unit 40 that has received the signed license token evaluates the syntax of the signed license token (step S230). Then, the transaction processing unit 40 requests the license token storage unit 60 to acquire the parent license token based on the rule (program) described as the input I _i (step S240), and the license token storage unit 60. The parent license token returned from is received (step S250), and the input program and output program of the license token are evaluated (step S260). In this processing, for example, processing such as payment of a copyright fee to the owner of the content to be licensed by the license token is executed (the payment method is not limited, but payment can be made in virtual currency, for example).

Then, the transaction processing unit 40 instructs the license storage unit 60 to store the license token (step S270), and when receiving the notification that the license token is stored from the license token storage unit 60 (step S280), the license is stored. The confirmation of generation of the license token is transmitted to the management user interface 20 (step S290), and further, the license management user interface 20 transmits confirmation of generation of the license token to the participant terminal 11 (step S295), and the derived license. The token generation process ends.

As described above, each time a license is derived, a derivative license token is generated, and an output of a parent license token (eg, GLT in FIG. 4) and a derived child license token (eg, in FIG. 4) are generated. Since the chain of license tokens is stored in the license token storage unit 60 by linking the input of the DLT) (in the above-described example, the use function is used to specify the output to be linked to the parent license token), License links can be managed accurately and efficiently.

The license management user interface 20 has a table shown in FIG. 8 and has attributes of the participant terminals 10 (for example, artists who are content creators, consumers, distributors, and music labels who are publishers). Etc.) based on each of the origin license token, the derivative license token, and the composite license token. In the process for generating the license token described above, although the composite license token is not described, the license token has a plurality of inputs, and each input is connected to the output of the parent license token of a different parent.

Next, specific examples will be described.

(Example 1: When licensed with a combination of different music for each area)
FIG. 9 shows a case in which an album having a combination of music different for each region is licensed. Here, the origin license token is an intellectual property, and the derivative license token is an exclusive license. Further, FIG. 10 shows a hierarchical structure of the license corresponding to FIG. The reference numerals shown in FIG. 10 are the same as those in FIG. 13 used in the description of the prior art, and as branch numbers, E is attached to an element corresponding to Europe and J is attached to an element corresponding to Japan. Is attached.

First, the content creator who is an artist creates three songs (track 1, track 2, and track 3 for the album) and generates GLT1, GLT2, and GLT3 as origin license tokens for each song. There is. Of these three songs, the first two songs (track 1 and track 2 licensed by GLT1 and GLT2) are songs recorded in the album regardless of region, and the third song (track licensed by GLT3). 3) is a song recorded on a bonus track limited to Japan.

First, the content creator licenses two songs consisting of GLT1 and GLT2 to a global label for the purpose of licensing to European distributors and Japanese distributors. As a result, derivative license tokens DLT1 and DLT2 are generated for the worldwide label. The derivative license token DLT1 described as division 1 is a license token for licensing a song licensed by GLT1 to Europe and Japan, and the derivative license token DLT2 described as division 2 is licensed at GLT2. It is a license token to license music to Europe and Japan.

Then, the world-wide label licenses the album consisting of the derivative license tokens DLT1 and DLT2 to the European distributor. As a result, the derivative license token DLT11 for the album for Europe is generated. This derivation license token DLT11 has an input 1 connected to the output 1 of DLT1 and an input 2 connected to the output 1 of DLT2, but since it is not licensed to the consumer yet, output 1 Is an unused license token output (ULTO). Listing 9 below shows an example of a program for output 1 of the European distributor's derivative license token DLT11.

(List 9) Example of DLT11 output 1 program
and (
scale (
and (
unit ("0xd1a3 ..."),
unit ("0x52fc ..."),
),
100,
),
id ("0x9e69 ..."), # <-European distributor's public key
)

The output program shown in Listing 9 has a configuration in which a participant having a public key of 0x9e69 (European distributor) licenses two songs with content IDs of 0xd1a3 and 0x52fc as a distribution unit and 100U. Output 1 of different license tokens (DLT1, DLT2) is connected to each of the input 1 and the input 2 of the DLT 11, but when the distribution units are different, the distribution unit of the output 1 is the input 1, The smallest distribution unit among the distribution units input in 2 is set. The same applies when there are three or more inputs. Further, when there are a plurality of outputs, the total of the distribution units set to those outputs matches the minimum value of the distribution units input to the plurality of inputs. Further, since the public key specified by the id function will be further divided by the European distributor in the future, the public key of this European distributor is described.

On the other hand, the Japanese distributor receives a license for two songs corresponding to DLT1 and DLT2 from a global label, and a license for a song corresponding to GLT3 for the bonus track from the content creator. As a result, the derivative license token DLT21 for the album for Japan is generated. This derived license token DLT21 has an input 1 connected to the output 2 of DLT1, an input 2 connected to the output 2 of DLT2, and an input 3 connected to the output 1 of GLT3. Furthermore, the derivative license token DLT211 described as division 3 is generated, and the output 1 of the derivative license token DLT21 is connected to the input 1 of the derivative license token DLT211. The derivative license token DLT211 allocates a part of the distribution unit to the output 2 for sale, and allocates the remaining distribution unit to the output 1. Output 1 and output 2 are both unused license token outputs (ULTO). List 10 below shows an example of the program of output 1 of the derivative license token DLT211 in the Japanese distributor, and list 11 shows an example of the program of output 2.

(List 10) Example of output 1 program of DLT211
and (
scale (
and (
unit ("0xd1a3 ..."),
unit ("0x52fc ..."),
unit ("0x5fcd ..."),
),
99,
),
id ("0x13c0 ..."), # <-Japanese distributor's public key
)

(List 11) Example of output 2 program of DLT211
and (
scale (
and (
unit ("0xd1a3 ..."),
unit ("0x52fc ..."),
unit ("0x5fcd ..."),
),
1,
),
id ("0x9e69 ..."), # <-consumer's public key
)

In output 1 and output 2 of the derived license token DLT211, 99U and 1U are set for the three songs with content IDs 0xd1a3, 0x52fc, and 0x5fcd, respectively. Here, since the public key specified by the id function in the program of output 1 will be further divided by the Japanese distributor in the future, the public key of this Japanese distributor is described. Also, the public key specified by the id function in the program of output 2 is the license provided to the consumer, so the public key of the consumer is described.

Here, the number of distribution units is defined in the output 1 of each of the origin license tokens GLT1, GLT2, and GLT3, so that even if a derivative license token is generated, the number of distribution units set in the origin license token. Is never exceeded. Each of the license tokens described above is signed with the private key of each participant.

As described above, the digital content license management system 1 according to the present embodiment effectively expresses a complicated license token hierarchy as shown in FIG. 1 by using a simple recursive data structure. You can Further, by limiting the initial number of distribution units of the origin license token, the content creator can prevent both the global label and the regional label from duplicating the license token excessively.

(Example 2: On-demand streaming)
In the case of on-demand streaming, the following information needs to be encoded in the license token chain (license token structure). First, the service provider's on-demand streaming site has the right to distribute movies filmed in a given language (eg English), and also the right to deliver subtitles in a language different from the given language (eg French). Have Also, users from various countries want to watch this movie and the appropriate subtitles. Further, a predetermined amount of distribution unit (for example, 100 U) is set for each license token that is initially owned (only the set distribution unit can be streamed).

As shown in FIG. 11, for a movie, a service provider performing on-demand streaming has a derivative license token DLT1 for a license for streaming the movie and a derivative license token DLT2 for a license for streaming subtitles of the movie. have. Note that, in FIG. 11, the parent derivation license token or the origin license token is connected to the input 1 of the derivation license tokens DLT1 and DLT2, respectively, but it is omitted here. Further, in FIG. 11, one license token for subtitles is displayed, but it may have a plurality of license tokens corresponding to a plurality of languages.

-English-speaking customers request to watch movies without subtitles. Therefore, the service provider generates a derivative license token DLT11 with the comment of division 1 and leaves 99U in output 2 out of 100U input in input 1 and 1U in output 1 for later use. To divide. Then, the service provider generates the derivative license token DLT112 with the comment of stream 1, and provides 1U input to the input 1 to the English-speaking customer as the output 1. Note that in FIG. 11, the output of the derived license token DLT 112 is an unused license token output (ULTO) because it has not been used yet.

-Non-English speaking customers request to watch movies with subtitles in their preferred language (eg French). Therefore, the service provider uses the derivative license token DLT111 with the comment of division 2 for the movie that the consumer watches (consumes) and the derivative license token DLT21 with the comment of division 3 for the subtitles. Split 1U for this customer by creating. Note that, in FIG. 11, the movie derivative license token DLT1 is already divided by the derivative license token DLT11 for the stream for English-speaking customers, and therefore is allocated to the output 2 of the derivative license token DLT11. 99U is input to the input 1 of the derivative license token DLT111, and 1U of the input is split as the output 2. The remaining 98U is assigned to output 1. This output 1 is an unused license token output (ULTO) at the present time.

On the other hand, since the subtitles have not been divided yet, 100U allocated to the output 1 of the derivative license token DLT2 is input to the input 1 of the derivative license token DLT21, 1U is divided as the output 1, and the remaining 99U Is assigned to output 2. This output 2 is an unused license token output (ULTO) at the present time.

Then, the service provider generates the derivative license token DLT3 with the comment of stream 2, inputs 1 U of the movie divided by the derivative license token DLT111 in input 1, and divides it by the derivative license token DLT21 in input 2. 1U of the subtitles is input, and these are provided as output 1 to the non-English-speaking customer (consumer). Note that in FIG. 11, the output of the derived license token DLT3 is an unused license token output (ULTO) because it has not been used yet. The following list 12 shows an example of a program of input 1 of the derived license token DLT3 which is stream 2, list 13 shows an example of a program of input 2, and list 14 shows an example of a program of output 1.

(List 12) Example of DLT3 input 1 program
and (
use ("0x07d4 ...", 2), # Use output 2 of split 2 unit ("0xd1a3 ..."), # Movie content ID
id ("...", "..."), # Service provider validation
)

(List 13) Example of DLT3 input 2 program
and (
use ("0x07d4 ...", 2), # Use output 1 of division 3 unit ("0x52fc ..."), # Content ID of subtitle
id ("...", "..."), # Validate service provider
)

(List 14) Example of DLT3 output 1 program
and (
unit ("0xd1a3 ..."), # Movie content ID
unit ("0x52fc ..."), # Subtitle content ID
id ("0x9e69 ..."), # <-consumer's public key
)

Note that, in FIG. 11, as a result of setting 1U streaming to an English-speaking customer and 1U streaming to a non-English-speaking customer, four unused license token outputs (ULTO) remain. Specifically, 98U ULTO for movie content, 99U ULTO for subtitles, ULTO consumed for streaming to English-speaking customers, and ULTO consumed for streaming to non-English-speaking customers. .. Here, "consuming" the delivery unit is an act of providing the user with basic contents.

As described above, according to the digital content license management system 1 according to the present embodiment, even in the on-demand streaming, the distribution set to the output 1 of the derivative license token DLT1 of the movie and the derivative license token DLT2 of the subtitle owned by the service provider. Content can be streamed with the maximum number of units. In other words, based on 100U set to the output 1 of the derivative license tokens DLT1 and DLT2, streaming can be performed simultaneously for a maximum of 100 users, but further streaming cannot be performed.

(Example 3: In case of batch sale of license tokens)
If the content distributor wants to sell the complete content catalog, this can also be implemented in the DLT transaction. FIG. 12 shows two licenses (a derivative license token DLT1 described as content 1 and a derivative license token DLT2 described as content 2) owned by a content distributor (referred to as “former owner”). The distribution unit is 100 U) and the content is sold to another content distributor (referred to as “new owner”).

In this case, the derivative license token DLT11 for the content 1 and the derivative license token DLT21 for the content 2 are generated for the new owner, and the parent license token DLT1 is input to each of the inputs 1 of the derivative license tokens DLT11, DLT21. , Output 1 of DLT2 are connected, and 100U is allocated to the output 1 of each of the child derivative license tokens DLT11 and DLT21. Output 1 of the child derivative license tokens DLT11 and DLT21 is an unused license token output because it has not been used yet.

As described above, according to the digital content license management system 1 according to the present embodiment, a license token whose output is unused can be easily transferred to another person.

1 Digital Content License Management System 10 Participant Terminal 20 License Management User Interface 30 Key Storage Section 40 Transaction Processing Section 50 Content Evaluation Section 60 License Token Storage Section

Claims (11)

A transaction processing unit that generates a license token,
A license token storage unit that stores the license token,
The license token is
At least one output information and identification information for uniquely identifying the license token,
The transaction processing unit, when deriving a new license token based on the license token stored in the license token storage unit,
At least one input information including identification information for specifying an original license token and information for specifying output information for the original license token;
At least one output information,
Generate the license token identification information,
A digital content license management system that stores the input information, the output information, and the identification information as the new license token in the license token storage unit. The transaction processing unit is
In the output information of the original license token, set a distribution unit that is the maximum value of the number of license tokens that can be derived from the original license token,
The digital content according to claim 1, wherein a distribution unit equal to or less than the distribution unit set in the output information of the original license token specified by the input information is set in the input information of the new license token. License management system. The transaction processing unit is
The distribution unit is set to the output information of the new license token,
The digital content according to claim 2, wherein the total of the distribution units set in the output information included in the new license token matches the distribution unit set in the input information included in the new license token. License management system. The transaction processing unit is
The digital content license management system according to any one of claims 1 to 3, wherein information for specifying the output information of one original license token is set in the input information of the new license token. The transaction processing unit is
The digital content license according to any one of claims 1 to 4, wherein the identification information is signature information generated from all the output information and the input information included in a license token identified by the identification information. Management system. The output information and the input information can be configured by a predetermined program,
The transaction processing unit is
When deriving the new license token,
The program of the input information of the new license token and the program of the output information of the original license token specified by the input information can be executed. Digital Content License Management System. In the output information, when deriving a new license token from the license token including the output information, it is possible to set information that limits the owner of the new license token,
The transaction processing unit is
7. The new license token is derived only when the owner of the new license token is the owner set in the output information of the original license token. The described digital content license management system. In the output information, it is possible to set information regarding a period during which a new license token can be derived from a license token including the output information,
The transaction processing unit is
The digital content license management system according to claim 1, wherein the new license token is derived only during a period set in the output information of the original license token. In the output information, it is possible to set information about a region where a new license token can be derived from a license token including the output information,
The transaction processing unit is
9. The new license token is derived only when the area licensed by the new license token is the area set in the output information of the original license token. The digital content license management system described in. In the output information, it is possible to set information on content licensed by a license token including the output information,
The transaction processing unit is
10. The new license token is derived only when the content corresponding to the content information set in the output information of the original license token is stored in a predetermined storage unit. The digital content license management system according to 1 above. The transaction processing unit is
11. When deriving the new license token, information regarding derivation of the new license token is recorded based on a program set in input information included in the new license token. The digital content license management system according to one item.

Images