WO2019070563A1

WO2019070563A1 - Genuine instance of digital goods

Info

Publication number: WO2019070563A1
Application number: PCT/US2018/053705
Authority: WO
Inventors: Eric Diehl
Original assignee: Sony Corp; Sony Pictures Entertainment Inc
Current assignee: Sony Corp; Sony Pictures Entertainment Inc
Priority date: 2017-10-03
Filing date: 2018-10-01
Publication date: 2019-04-11
Anticipated expiration: 2020-04-03
Also published as: US11481786B2; EP3659091A1; CN111095322A; EP3659091A4; EP3659091B1; US20190102782A1; CN111095322B

Abstract

Processing a genuine instance of a digital good using a blockchain including: registering an ownership of the genuine instance using a plurality of transactions, the genuine instance uniquely identified by a content descriptor which is cryptographically linked to an ownership token and includes intrinsic characteristics of the genuine instance, wherein the ownership token includes a token seed and a token signature; validating each transaction of the plurality of transactions by a plurality of validators; and recording that the genuine instance belongs to an owner by recording each transaction of the plurality of transactions in the blockchain once each transaction has been validated.

Description

GENUINE INSTANCE OF DIGITAL GOODS

GROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of priority under 35 U.S.C. §119 (e) of co-pending U.S. Provisional Patent Application No, 62/567, 698, filed October 3, 2017, entitled "Genuine Instance of Digital Good," The disclosure of th above-referenced application is incorporated herein by reference.

BACKGROUND

Field

[0002] The present disclosure relates to genuine instance of digital goads,- a:nd more, specifically, to validating the genuine instance .

Background

[0003] A good is rival if once consumed it is not anymore available, A good is excludable- if it is possible to restrict its usage to an individual or a group of

individuals. Digital goods are by nature non-excludable and non-rival. In some cases, these intrinsic characteristics may be a business issue. As scarcity is driving value, non- exeiudability and non-rivalry may be disadvantageous to business. However, digital goods are by nature not scarce, thus with little intrinsic commercial value.

SUMMARY

[0004] The present disclosure provides for creating the scarcity with one unique instance of a digital good that will be the genuine instance and for linking that genuine instance to an owne .

[0005] In one implementation, a method for processing a genuine instance of a digital good using a hlbckchain is disclosed. The method includes : registering an ownership of the genuine instance using a plurality of transactions^ the genuine instance uniquely identified by a content descriptor which is cryptographicaliy linked to an

ownership token atnd includes intrinsic characteristics of the genuine instance, wherein the ownership token includes a token seed and a token signature; validating each

transaction of the plurality of transactions by a plurality of validators; and recording that the genuine instance belongs to an owner by recording each transaction of the plurality of transactions in the biockchain once each transaction has been validated.

[0fl06] In one implementation, the intrinsic characte istics include a unique identifie of the genuine instance which is calculated as a one-way cryptographic hash of the token seed; a payload of an imperceptible watermark embedded in the genuine instance; an instance hash of the plurality of transactions; and a content signature signed by the owner of a previous transaction. In one implementation, the ownership token includes information that links the genuine instance to the owner. In one implementation, registering an ownership of the genuine instance is performed by an issuer. In one implementation, intrinsic characteristics include: a unique identifier of the genuine instance which is calculated as a one-way cryptographic hash of the token seed; a payload of an imperceptible watermark embedded in the genuine instance; an instance hash of the plurality of transactions; a content signature signed by the issuer and a certificat key of the issuer. In one implementation, validating each transaction includes: verifying the

validity of the content signature; and verifying the validity of the ownership token . In one implementation, ^"verifying the validit of the ownership token in a resale includes: verifying the validity of the token seed; and verifying that the token signature is a actual signature of the token seed submitted by the owner in a previous transaction. In one implementation_r each transaction i nc i udes : a transaction signature signed fey the issuer and a certificate key of the owner. In one implementation, the method further includes generating, by the issuer, an initial random seed, wherein the initial random seed enables the creation of a finite series of successive token seeds, each token seed being a one-way cryptographic hash of the token seed generated in a previous transaction. In. on implementation, the method furthe includes generating the unique identifier of the genuine instance with a single iteration of a one-wa hash function of a last element of the finite series for an initial sale of the genuine instance. In one implementation, the method further includes: appointing a certification authority by the plurality of validators; and generating key pairs and associated certificates used for identity management by the certification authority. In one impleme t tion, generating key pairs and associated, certificates includes: verifying that the associated certificates did not expire; and verifying that the associated certificates were signed by the certification authority. In one implementation, the content descriptor also includes a set of visible marks that is unique to the genuine instance. In one

implementation, the ownership token also includes a token signature of the token seed. In one implementation. registering an ownershi of the genuine instance is

performed by the owne in a previous transaction. In one implementation, the method fur her includes: generating, by the owner in the previous transaction, a new ownership token by signing the token seed with a private key of the owne in the previous transaction and generating a suite of linked token seeds ,

[0007] In another implementation, a non-transitory

computer-readable storage medium storing a computer program to process a genuine instance of a digital good using a biockchain is disclosed. The computer program includes ^■executable ins actions that cause a computer to: registe an ownership of the genuine instance using a plurality of transactions, the genuine instance uniquely identified by a content descriptor which is cryptographical ly linked to an ownership token and includes intrinsic characteristics of the genuine instance, wherein the ownership token includes a. token seed and a token signature; validate each

transaction of the plurality of transactions by a plurality of validators; and recording that the genuine instance belongs to an owner by recording each transaction of the plurality of transactions in the biockchain once each transaction has been validated. [0008^:] In yet another implamentat ion, a system for

processing a genuine instance of a digital good using a foiockohain is disclosed. The system includes: an issuer confiqured to register an ownership of the genuine instance using a piuraiity of transactions, the genuine instance uniquely identified by a content descriptor which is

cryptographicaily linked to an ownershi token and includes intrinsic characteristics of the genuine instance,- wherein the ownership token includes a token seed and a token

signature; and a plurality of validators configured to validate each of the piuraiity of transactions, wherein the genuine instance is recorded as belonging to an owner by recording each transaction of the plurality of transactions in the foiockchain once each transaction has been validated fa the pluralit of validators,

£00X19] In one implementation, the intrinsic characteristics include; a unique identifier of the genuine instance which is calculated as a one-way cryptographic hash of the token seed; a. payload of an. imperceptible watermark embedded in the genuine instance; an instance hash of the pluralit of transactions; and a content signature signed by the owner in a previous transaction. In on implementation, the system further includes a watermark detector configured to detect and extract the payload of the imperceptible watermark embedded in the genuine instance. In one

implementation, the ownership token includes information that links the genuine instance to the owner. In one

implementation, the system further includes a certification authority configured to generate key pairs and associated certificates used for identity management .

[0010] Other features and advantages should be apparent from the present description which illustrates, by way of example, aspects of the disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The details of the present disclosure, both as to its structure and operation, may be gleaned in part by study of the appended drawings, in which like reference numerals refer to like parts, and in which:

[0012] FIG♦ 1 is a block diagram of a biockchain including n blocks and a genesis block;

[0013] FIG. 2 is a block diagram of a blockchain-based system for processing a genuine instance of a digital good in accordance with one implementation of the present

disclosure;

[0014] FIG » 3 is a block diagram of a transaction including a content descriptor, an ownership token, a transaction. signature/ and an owne certificate key, in accordance with one implementation of the present disclosure;

[0015] FIG . 4 is a block diagram of a blockchain-based system for processing a genuine instance of a digital good in accordance with another implementation of the present disclosure;

[0016] FIGS. 5A and SB form a flow diagram illustrating a process for validating a first sale of a genuine instance of a digital good in accordance with another implementation of the present disclosure;

[0017] FIGS. 6A and 6B form a flow diagram illustrating a process for validating a resale of a genuine instance of a digital good without an issuer in accordance with one implementation of the present disclosure; and

[0018] FI S , ΊΑ and 7B form a flow diagram illustrating process for validatin a resale of a genuine instance of a digital good with an issuer in accordance with one

implementation of the present disclosure.

DETAILED DESCRIPTION

[0019] As described above, although scarcity drives value, digital goods are by nature not scarce, and thus may have little commercial value. [002:0] Certain im lementations of the present disclosure provide for creating the scarcity with one unique instance of a digital good that will be the genuine instance and for linking that genuine instance to an owner. All copies of the genuine instance handled by an entity other than the proprietor would not foe genuine instances, although they may be bit-to-bit copies of the genuine instance. All derived versions, such as compressed or resized Instances, would not be genuine instances, regardless of the

ownershi . Thus, in the present disclosure, a genuine instance is a digital file with one unique owner. The present disclosure aims to link a digital file to an owner, and to trace and verify this ownership. In one

implementation, this link and ownership is implemented using a blockchain concept.

[0021] Digital signatures and digital, rights management m y be used to verify the integrity of an instance. However, the digital signature does not discriminate the genuine instance froia copied instances. Although the digital rights management is a set of technologies that create artificial scarcity for digital goods, they do not fulfill the

expected features. That is, although the digital rights management controls access to the digital goods, it does not handle its uniqueness and ownership. [0022] After reading these descriptions_/ it will become apparent how to implement the disclosure in various

implementations and applications. Although various

implementations of the present disclosure will be described herein, it is understood that these implementations are presented toy way of example only, and not limitation. As such this detailed description of various implementations shoul not be construed to limit the scope or breadth of the present disclosure.

[0023 j The bioeJchain data structure is an ordered list of blocks. Each block points back to its predecessor until the first block, which is sometimes referred to as the genesis block. The blocks and their sequencing are protected in integrity by backward-linking of cryptographic hashes.

There are many biockchains and usage of biockchains, but the most famous ones are Bitcoi and Ethereurr .

[0024] FIG. 1 is a block diagram of a block-chain 100 including n blocks 110, 120, 130 and a genesis block 140. in one implementation, a block has at least three elements: (a) an information section {e.g., 112) that stores the registered data and ancillary data, wherein the information section may be signed to prove its authenticity; (b) the cryptographic hash (e.g., 114} of the previous block (the genesis block will not have a previous block) ; and (c) the cryptographic hash (e.g. , 116} of the current block. Thus, the data structure of the blockchain provides an append- only global ledger, which is tamper evident.

0G2S] FIG. 2 is a block diagram of a blockchain-based system 200 for processing a genuine instance of a digital good in accordance with one implementation of the present disclosure. The blockchain-based system 200 f FIG. 2 includes an issuer 210, a genuine instance 220, a

transaction 230, and a blockchain 240.

[0026J in one implementation, the transaction 230 registers the ownership of the genuine instance 220 and the issuer 210 creates and delivers the genuine instance 220 to an initial owner 250. Each genuine instance 220 is uniquely identified, by a unique combination of intrinsic

characteristics referred to as a content descriptor which is illustrated in FIG, 3. The issuer 210 generates the initial transaction 230. The blockchain 240 holds every transaction 230 generated by the issuer 210.

[0027] FIG. 3 is a block diagram of a transaction 300 including a content descriptor 310, an ownership toke 320, a transaction signature 330, and an owner certificate key 340, in accordance with one im leme ta o of the present disclosure. In the illustrated implementation of FIG. 3 _r the content descriptor 310 Includes a unique identifier (Unique ID) 312 of th genuine instance 220, a payload 314, an instance hash 316, a content signature 318,. and an issuer certificate key 319. The content descriptor 310 may also include an optional set of visible arks that is unique to the genuine instance 220 {similar to the printing number in a series of lithography) .

[0028] In one implementation, the payload 314 corresponds to the actual payload of an imperceptible watermark

embedded in the genuine instance 220 and is unique to the genuine instance 220. The watermark is a unforgeable method to make the genuine instance unique for a given digital good. Depending on the type of media of the genuine

instance 220, the imperceptible watermark may foe invisible, inaudible, or text-based. In one implementation, the cryptographic instance hash 316 is a cryptographic digestof the essence of the genuine instance 220, In one

implementation, the content signature 318 is a digital signature of the previous parameters signed by the issuer 210 {similar to the signature of the painter on

lithography.) .

[0029] In one implementation, the ownership token 320 is digital information that links the genuine instance 220 to its owner 250, and includes a token seed 32.2 and a token signature 324, Unique ID is equal to f (token $-eeci), where £ is a function that is computationally difficult to reverse (e.g., a one-way cryptographic hash). The token signature 324 is a digital signature of the token seed issued by the issuer 210.

[0030] In one implementation, the ownership of each genuine instance 220 is recorded by the transaction 300 that holds the content descriptor 310, the ownership token 320, and an owner's certificate key 340, h issuer 210 signs the transaction 300 with the transaction signature 330, The validation of a transaction 300 verifies the content signature 318 and the validity of the ownership token 320. The biockchain 240 records any change of ownership of a genuine instance 220 by adding a new transaction 300 describing the transfer of ownership in the information section of a new block. The change of ownership ma use one :of two methods (one involving an issuer and another not involving an issuer) .

[0031] In the first method (not involving an issuer), the seller, who is the current owner of the genuine instance, generates a ne ownership token 320 by signing the coken seed 322 with the seller' s private key (i.e., owner's private key of. the previous transaction) . The new

transaction 300 holds the content descriptor 310, the new ownership token 320 signed by the seller, the certificate key of the future -owner 340, and is signed by the seller. A new block with the transaction 300 is stored on the

folockchain 240.

[0032] In the second method {involving an issuer) , the issuer 210 generates an initial random seed when creating the genuine instance 220. The initial random seed enables the creation of a suite of N linked token seeds as shown below. I :one implementation, the initial random seed enables the creation of a finite series of successive token seeds, each token seed being a one-way cryptographic hash of the token seed generated in a previous transaction. The issuer keeps this initial random seed confidentially. The issuer 210 also defines a transaction threshold N and calculates the transactions as follows:

Q ~ f (Initial Random Seed)

T_t ~ To)— f ( (Initial Random Seed) )

Unique 11)— f(T -t)

[0033] Accordingly, the initial token seed 322 is the ii- iteration, i.e. of £ with the initial random seed.

When resold, the token seed of the new transaction is T_?i_g, In case of the rr^h resale, the new token seed 322 is th (N- n) ^t¾ iteration of f. In one implementation, the one-way function f is a secure hash algorithm 3 (SHA3) with an .output of 256 bits, and N - 100:.

[0034] For the initial sale, UniqueID ^ f(token seed), while for the first resale, UniqueID - f { f (token seed}}, and so on. However, only the issuer 210 can calculate the new value of the token seed 322 since only the issuer 210 knows the initial random seed. The n w transaction 300 uses the initial content descriptor 310, the new ownership token 32:0 signed by the issuer, the certificate key of the future owner, and is signed by the seller. A new block with this transaction 300 is stored on the blockehain.

[0035 J In the descriptions below, following notations are used. For an asymmetric key pair, the prefix represents the private key, whereas the prefix Κ_ρ:^ represents the public key . Rotation Enc^^im) represents the encryption of clear text m using the public key Notation

Decji_f j(m') represents the decryption of ciphertext m^f using the private key K_p£i . If E_pZi and f_paf> are a public-private key pair then Deo _Hp^ (^ ^c{/e_pMl,}(^m)— « dotation Sign^.^irn

represents the digital signature of message m using the private key Κ_Ρί1 , Notation Ver^_Kt)^(tn_r s) represents the digital verification of the signature a of message m using the public key K_pi,_b , If K_;,_r; and K_ptih are a public-private key pair then Veri_Kpub m_s

[0036] FIG, is a block diagram of a blockcliain-based system 400 for processing a genuine instance of a digital good in accordance with another implementation of the present disclosure. The folockc ain-based system 400 of FIG. 4 includes an issuer 410, a genuine instance 420, a

transaction 430_/ a biockchain 440, a watermark detector 460, a certification authority 470, and a set o validators 480.

[0037] in one implementation, the set of validators 480 uses a consensus mechanism based on the Practical Byzantine Fault Tolerant agreement (PBFT) to add the new biocks. In one implementation, the set of validators 480 appoints a trusted certification authority 470 to generate key pairs and associated certificates used for identity management♦ The validation of a certificate is a known process that implies verifying the consistency of the. information

including verifying that the certificate did not expire and was signed by the trusted certification authority 470.

[0038] I . one implementation, regarding the cryptographic material used by the system 400 during the generation of the transaction 430, the issuer 410 has issuer's public key ij-s_f, a>>) and issuer's private key iKp_ri i_0mtir) _* he issuer 410 also has an issuer's certificate key issued, by the certification authority 470 which is associated with the issuer's public key. In one implementation, the system 400 uses a hierarchical structure whose root certification authority is the certification authority 470, In one particular implementation, the system 400 uses Rivest,

Shamir, and Adelman 2048 {RSA2048} Public Key Cryptographic Standard 1.5 (PRCSl.S}, while the issuer certificate key is X50 compliant, which is a standard defining the format of a certificate of public key,

[0039] In one implementation, the owner 450 has an owne ' s public ke _0ii),_ei} and an owner's private hey {Κ_{ρίΛ w(!X}) .

The owner 450 also has an owner's certificate key issued by the certification authority and is associated with the issuer's public key, In one particular implementation, the system uses RSA2048 PKCSI.S, while the owner certificate key is X509 compliant.

[0040] An example first sale of a genuine instance 4^'20 ol a. digital good is described below. Alice sells a genuine instance of a digital picture to Bob. Thus, in this

example, Alice is the issuer and Bob is the future owner.

[0041] In the: above-described example implementation, Alice performs the following operations: fl) generates a 256-bit random seed; {2} performs 100 iterations of SHA3 on the initial random seed which results in a token seed 322

{i.e., okenSeed - SHA3u_ii¾ {SBA3_¾S <..·, .SBA3«_: {SHA3, {random seed)}))}; (3) calculates Unique ID 312 (i.e. , OnxquelD ^~ SHA3 (TokenSeed) ) {in the highly unlikely case that UniquelD has already been used for: another genuine instance, a new random seed would be polled); (4) generates a 32-bit random payload 314; {5) embeds the random payload 314 into the digital good using a watermark erabedder to produce the genuine instance 420; (6) calculates instance hash 316 (i.e., InstanceHash - SBA3 (Genuinelnstance } whose length is 256 bits; {?) calculates the content signature 318

{Contentsignature -

(UniquelD I Payload I InstanceHash I IssuerCerti icateKey) ) ; (8) builds the content descriptor by aggregating the Unique ID 312, the Payload 314, the instance hash 316, the issuer certificate key 319, and the content signature 318; (9) stores the Unique ID 312 and the random seed in a secure private database; U-Q) calculates the token signature 324 ( .e., Token-Signature ^:::

} (11) calculates the transaction signature 330 by signing the content descriptor 310, the ownership token 320, and Bob's owner certificate key 340 (i.e., TransactionSignature «

(Content-Descriptor i OwnershipToken j G nerCerti icateKey) ; (12) builds the t an act ion 430 by aggregating the content descriptor 310, the ownershi toke 320,- the transaction signature 330, and the owner certificate key 340; and {13} submits the transaction 430 to the validators 480.

[0042] As described above in relation to FIG, 2, the

blockchain 440 is a permissioned blockchain, which means that a fixed set of known trusted validators validates each new block. I one Implementation, the validators 480 are a set of servers managed, by the issuer 410 (or a consortium of issuers) that handles the blockchain. Further, the blockchain 440 is public, which means that anybody can consul it. However, only a validator can add a new block to the blockchain 440,

[0043] FIGS. 5A and SB form a flow diagram illustrating a process 500 for validating a first sale of a genuine instance of a digital good in accordance with one

implementation of the present disclosure. In one

implementation, once the validator receives the transaction 300., the validator validates the transaction 300 by

checking the validity of three elements _r namely, the content descriptor 310, the ownership token 320, and the I r saction &ignature 330.

[0044] In one implementation, checking the validity of the content descriptor 310 includes: (!) extracting and

acquiring an extracted payload from the genuine instance (e.g., using an online watermark detector 460), at ste 510; (2) verifying, at step 512, that the extracted payload is equal to the payload 314 (the genuine instance has an embedded wateriaark whose payload is "extracted payload". If the submitted content is genuine, the payload in the transaction should match the vaiue carried by the genuine instance's watermark.}; (3) verifying that the issuer certificate key 319 is a valid certificate issued by the certification authority 470; and {4} verifying, at step

514, that the content signature 318 is the actual signature of the content descriptor generated by Alice (i.e.,

Ver R$A_K;.:_X.. , -_{;; :Λ}._{:Ϊ ;} {UniqueID I Payload j Instance-Hash I

IssuerCertificateKey I ConteritSignature) ===== true) } .

[0045] In one implementation, checking the validity of the content descriptor 310 also includes verifying that there is no double spending of the genuine instance, at step 516, The validator checks that there is no double spending by checking that there is not already a block issued by Alice in the blockchain 440 that has the corresponding payload 314 and th Unique ID 312.

[0046] In one: implementation, checking th validity of th ownership token 320 includes* (1) verifying, at step 518, the validity of the token se d 422 {i.e., Uniqu lb - SHA3 (TokenSeed) } and {2} verifying, at step 520, that the token signature 324 is the actual signature of token seed 322 submitted by Alic {i.e., Ver_RSAi._KxMif x ^xi {TofcenSeed I TokenSignature} ~~ true) ) .

[0047] In one implementation, checking the validity of the transaction signature 330 includes: (1) verifying, at step 522, that the transaction signature 330 is the actual signature of the transaction 300 by Alice (i.e.,

Ver_^RSAi ^ i«s««r} (ContentDescription ! OwnershipToken j

OwnerCertAficateEay, ContantSignature) true}} and (2) verifying that the owner certificate key 330 is a valid certificate (e.g., X509 certificate) issued by the

certification authority 470.

[0048] In one implementation, once the three conditions are fulfilled (i.e., the validity of the content descriptor 310, the ownership token 320, and the transaction signature 330) _t the validator 480 generates a new block including a single transaction. In other embodime s, once the three conditions are fulfilled, the validator 480 generates a new block for the blockchain 440 including a plurality of transactions. If the block includes multiple transactions, the validator 480 validates all transactions, As

illustrated in FIG. I, the new block. (.s) includes the transaction (in the information, section 112} , the hash 114 of the previous block, and the hash 116 of the new block. The structure of the block and the type of hash functio depends OB the type at blockchain used.

[0049} In illustrated implementation of FIGS. 5A and SB, the validator 480 submits the new block to the blockchain consensus mechanism, at step 530, The consensus mechanism depends on the technology used for the blockchain. In one embodiment, the consensus mechanism is the^■ PBFT. Thus, if it is determined, at step 532, that at least 2/3 of the set of validators 480 approves the new block, then the new block is added to the blockchain 440, at step 540. That is, the blockchain 440 records that Bob owns the genuine instance 420 described by content descriptor 310 issued by Alice. Otherwise, the validator rejects the block, at step 542 and the block is not appended to the blockchain 440.

[0050] In step 532 of the illustrated implementation of FIG. SB, the validators 480 within the consensus mechanism are asked to validate that a digital content i an actual, genuine instance belonging to a particular owner.

[0051] wo exam le irtiple entations are described below to illustrate the process to validate that a digital content- is (1) an actual /genuine instance belonging to- (2}_: a particular owner.

[0052] In the first example implementation,. Prudence wants to validate that a digital content is an actual genuine instance belonging to Bob. Thus, Bob provides to Prudence a pristine copy of genuine instance, his public key, and the Unique ID of the genuine instance. In one implementation, Prudence validates that the digital content is the actual genuine instance belonging to Bob by checking the most recent block (with the provided Unique ID) of the

blockehain and verifying that the block corresponds to the provided pristine copy. Prudenc also checks th identity of Bob.

[0053] To verify that the digital content is a ^pristine copy" { "pristine copy" means bit-to-bit copy of the genuine instance}, Prudence performs the following: (1) verifies that the hash of a copy of genuine instance is equal to the instance hash 31 (i.e., insta^'n eHash ■^»«

SHA3 ( opyOfGen .ineInstance) ) ; (2) extracts an extracted payload from the copy of genuine instance using a watermark detector 460; and (3) verifies that, the extracted payload is equal, to the payload 314, Further, to verify the

identity of Bob, Prudence verifies that the owner

certificate key 340 is still valid and that it matches the public ke provided by Bob; Thus, Prudence {!) generates and sends a 1024-bit random nuxaber called *Challenge' to Bob, who encrypts it with his private key ( K_{pri WB r}^ to create and return Answer Challenge'

RSAJNC^ _w>ter (Ckallmge)) to Prudence; and (2) verifies that Challenge -

. If the above three conditions are met, Prudence validates that Boh ow s the corresponding genuine instance. In this case, it is

important that Bob provides a pristine copy of the genuine instance to Prudence. Otherwise, the calculated hash would not match the instance hash 316 recorded in the locfcchain.

[0054] In the second example implementation, Prudence validates that. Bob owns the genuine instance. For this validation, Bob provides to Prudence a copy of the genuine instance, Bob's public key, and the Unique ID. Prudence performs the following: (1) searches the blockchain for the most recent block with the unique ID 312; (2) extracts an extracted payload from the copy of the genuine instance using a watermark detector 460; { 3 } verifies that the extracted payload is equal to the payload 314; and {4} verifies the identity of Bob. in one implementation, the identity of Bob is verified by performing the following steps: {1} verifies that the public key provided by Bob matches the owner certificate key 340 and that the owner certificate key 340 is still valid; (2) generates and sends a 102 -bit random number { ^>vchallenge^""} to Bob; {3} receives an ^vanswer challenge" from Bob, wherein the "answer

challenge'' was generated by Bob encrypting the ^challenge" with Bob's private key (i.e., AnswerCkallmge «

RSAJSNC ^jiChallmge)} ; and (4) verifies that Challenge =

RSAJ)EC{_K ^^(AnswerChallenge). If this is true, Prudence

concludes that Bob owns the corresponding genuine instance. In the second example impl eroen t t ion, the verification does not require a pristine copy of th genuine instance. Thus, the copy of the genuine instance may be of a lower quality than the genuine instance, as long as the watermark

extraction is successful. It shall be noted that Prudence does not rove that Bob has genuine instance but only that he owns it,

[:005s J In another example implementation,,- Bob wants to resell his genuine instance to Ophelia. Bob is the seller and Ophelia is the future owner. In this implementation, notations K_{pri Soh} and K _{lih ob} form Bob's key pair, and are, initially, the keys of the owner. Notations K_p^- e^ * an.d form Ophelia's key pair, and are, initially, the keys of th new owner. In this exam le implementation, th resale ma occur with or without an issuer.

[0056] In the example resale implementation without the issuer, the following steps are performed: {1} Bob forwards a pristine copy of th genuine instance to Ophelia; (2) Ophelia verifies that it is the expected instance (i.e., that it is the pristine copy of the genuine instance) as described in the previous section; ( 3 ) Bob verifies the identity of Ophelia: (a) Ophelia provides to Bob a

certificate (e.g., the X509 certificate) of her public key; (b) Bab generates and sends a 1024-bit random number called 'challenge' to Ophelia; (c) Ophelia encrypts 'challenge" with Ophelia' s private key optwi ) to generate

AnswerChaUenge - RSA ..ENC _Kprt ^(Challenge) ; (d) Ophelia returns

AnswerChallenge to Bob; (e) Bob verifies that Challenge ^

R$AJ)EC{_{S b l} ](AnswerChallenge) } (4) Bob generates a new ownership token by signing the token seed with his private key

( ¾._ϊν :S¾_M) ; (5) Bob calculates the new transaction signature by signing the content descriptor, the new ownership token, and Ophelia's owner certificate key (i.e., TransactionSign t re - Sign K&Sj _Kpji s*¾_> (ContentDesc r iptcr \ Ottn-ers Toksn j

OpheliaCertifIcate ey) ) (6) Bob builds the new transaction by aggregating the content descriptor, the new ownership token, Ophelia's owner certificate key, and the new

transaction signature; and {?} Bob submits the transaction to a validator.

[0057] FIGS . 6A and 6B form a flow diagram illustrating a process 600 for validating a resale of a genuine instance of a digital good without an issuer in accordance with one implementation of the present disclosure. In the

illustrated implementation of FIG. 6Ά, the validator searches for and retrieves the most recent block with

Unique ID, at step 610. The validator then checks three conditions,, (1) the validity of the content descriptor, (2) the validity of the new ownership token, and (3) the proposed transaction signature .

[0058] In the first implementation, the validity of the content descriptor is checked, at step €12, by matching the content descriptor in the extracted block to the content descriptor of the transaction submitted by Bob. If a match results, the process 600 continues. Otherwise, the block is declared as not valid, at step 650.

[0059] In the second implementation, the validity of the new ownership token is checked at steps 614 and 616. At step 614 , the validity of the token seed is verified by checking that UniqueID ^:= SHA3 (lokenSeed} . Then, at step 616, the token signature of the proposed transaction is verified by {1} extracting the owner certificate key of the retrieved block, and {2} verifying that the token signature of the proposed transaction is the actual signature of token seed by the owner of the owner certificate key of the retrieved block (i.e., { Tok nSsns _t

TokexSignature)∞*¥rtte) . If the signatures match, then the signatory is the current owner, i.e., Sob.

[0060] In the third implementation, the proposed

transaction signature is checked, at step 618, by verifying that the proposed transaction signature is the actual signature of the transaction by Bob (i.e.,

V&r F.S^'AiK_a!Sb :_;s}bi (ContentDsscriptor \ OvnsrshipToken \ CertificataOphel is. _r ransactioRSignaturs} ^ rue) and that the owner certificate key is a valid certificate issued by the certification

authority. f D061] If the above three implementations are checked and fulfilled, then the validator generates and submits the new block to the ^'validators of the blockchain consensus

mechanism, at step 630, Otherwise, the block is declared as not valid, at step 650.

[0062 J In one implementation, if at least 2/3 of the set of validators approves the new black, then the new block is added to the blockchain. That is, the blockchain records that the genuine instance described by content descriptor issued by Alice (and previously owned by Bob) is now owned by Ophelia.

[0063] In the example resale implementation with the issuer, the following steps are performed: (1) Bob forwards a pristine copy of the genuine instance to Ophelia; (2) Ophelia verifies that it is the expected instance as described in the previous section; ( 3 ) Bob verifies the identity of Ophelia: {a} Ophelia provides to Bob a

certificate {e.g., the X509 certificate) of her public key; ih) Bob generates and sends a 1024~b.it ra dom number called *challenge'^' to Ophelia; (c) Ophelia encrypts 'challenge' with Ophelia's private key {K^ op ^i ) to generate

AnswerChallenge - RSA HNC{_K . _0r!kS!Ha \ (Challenge); (d) Ophelia returns

AnswerChallenge to Bob; (e) Bob verifies that Challenge =

R$AJ)EC{_K→ ^^(An werChallenge ; (4) Alice verifies that Bob owns the genuine instance as described in the previous section; (5) Alice counts the number of blocks (n) in the blockchain related to Unique ID {i.e., the number of transactions related to the genuine instance); (11) Alice performs 100~n iterations of SEA3 on the initial seed to generate the new token seed {i.e., UniqueΪΟ - SHA3_K^-« {SHA3.»$>.._r! (... SHA3,>{ SHA3i (Seed) } ) } ) ; (12) Alice calculates the token signature {i.e., TokenSignature ~Sign_RSAi_Kp3:i ι««««π {"fokenSeed) ) ; (13) Alice retu ns: the new ownership token securel to Bob; {14} Bob calculates the new transaction signature by signing the content descriptor, the new ownership token, and: Ophelia's owner certificate key {.i.e., ?ransactionSigrsature =

Sign RSA{xpxi. s¾b} {Content-Descriptor \ OvmershipToken j OphellaCertifieateKey) ) ; {15} Bob builds the new transaction by aggregating the content descriptor, the new ownership token, Ophelia's owner certificate key, and the new transaction signature; and {17} Bob transfers the transaction to a validator.

[0064] FIGS, 7A and 7B form a flo diagram illustrating a process 700 for validating a resale of a genuine instance of a digital good with an issuer in accordance with one i plementation of the present disclosure. In the

illustrated implementation of FIG, 7A, the validator searches for and retrieves the most recent block with

Unique ID, at step 710. The validator then checks three conditions, (1) the validit of the content descriptor, (2) the validity of the new ownership token, and {3} the proposed transaction signat/ure .

[0065] In the first implementation, the validity of the content descriptor is checked, at step 712, by matching the content descriptor in the retrieved block to the content descriptor of the transaction submitted by Bob. If a match results, the process 700 continues. Otherwise,- the block is declared as not valid, at step 750.

[0066] In the second implementation, the validity of the new ownership token is checked at steps 720, 722, and 724. At step 720, the number of blocks (.:<} in the folocfcehaln related to Unique ID is counted. At step 722, the validity of the token seed is verified by making n+1 iterations of SHA3 and checking that UniqueID = SHA3_;s (.„ SHA3₀ (TokenSeed) } . Then, at step 724, the token signature of the proposed transaction is verified by verifying that the token

signature of the proposed transaction is the actual

signature :of token seed by the public key held in the issuer certificate key of the retrieved block. If the signature does not match, then the block is declared as not valid, at step 750.

[0067] In the third implementation, the- proposed

transaction signature is checked, at block 726, by

ver ying tha the proposed transaction signature is the actual signature of transaction .by Bob (i.e.,

fContentDesexiptor Ϊ OwnershipToken I Cerzixicst&Ophelia, ransact! onS nature) * *True) and that the owner certificate key is a valid certificate issued by the certification

authority.

[0068] If the: above three implementations are checked and fulfilled/ then the validator generates and submits the new block to the validators of the blocfcchain consensus

mechan sm, at step 730. Otherwise, the block is declared as not valid, at step 750. [^"0069] In one implementation, if at least 2/3 of th set of validators approves the new block, then the new block is added to the blockchain. That is, the blockchain records that the genuine instance described by content descriptor issued by Alice {and previously owned by Bob) is now owned by Ophelia.

[0070] The difference between the two implementations

(without issuer and with issuer) is that when the issuer is involved, the issuer acts as an additional trust referee. Only the issuer can generate a valid ownership token,

[0071] Accordingly,- the above-described implementations provid for creating the scarcity wi r h one unique instance of a digital good that will be the genuine instance and link that genuine instance to an owner. Any copies or derivatives are not genuine instances. Following examples verify that the concept works,

[0072] Alice cannot sell the same genuine instance to Bob and Charles, Assum that Alice provides the sa digital file to Bob and Charles: by using different seeds for Bob and Charles, resulting in two different U.IDs. However, in this case, the validator would detect the two transactions with the same payload but different Unique. IDs. This would be a violation detected b the consensus mechanism, Alice can make several genuine instances fro¾ the same, original file. However, each genuine instance has a different

watermark, thus, making each genuine instance unique.

[0073] Bob cannot resell the same genuine instance to

Ophelia and Charles. In this case, the blockchain detects the double spending. Since the validators can only record one ownership, the second sale would be a violation, thus, not validated.

[0074] Eve cannot claim a genuine instance without, owning it. Eve cannot pass the ownershi test as the challenge response requires having Bob's private key.

[0075] Bob cannot keep a genuine instance once he sells it. Bob may keep a pristine copy of the sold genuine instance. However, Bob will not pass the ownership test as this test requires the private key of the current owner registered in the blockchain. The blockchain guarantees the transfer of ownership.

[0076] The description herein of the disclosed

implementations is provided to enable any person skilled in the art to make or use the present disclosure. Numerous modifications to these implementations would be readily apparent to those skilled in the art, and the principals defined herein can be applied to other implementations without departing from the spirit or scop of th present disclosure . For example, although the specification describes the validation application performing hashing functions using the SHA3 program, other hashing functions can be used in place. Thus, the present disclosure is not intended to be limited to the implementations shown herein but is to toe accorded the widest scope consistent with the principal and novel features disclosed herei ,

[0077] Various implementations of the present disclosure are realized in electronic hardware, computer software, or combinations of these technologies. Some implementations include one or more computer programs executed by one or more computing devices. In general, the computing device includes one or .more processors, one or more data-storage components (e.g., volatile or non-voiatiie memory modules and persistent optical and magnetic storage devices, such as hard and floppy disk drives, CD-ROM drives, and magnetic tape drives), one or more input devices (e.g., game

controllers, mice and keyboards) , and one or more output devices {e.g., display devices).

[0078] The computer programs include executable cod that is usually stored in a persistent storage medium and then copied into memo y at run-time. At least one processor executes the code by retrieving program instructions from memory in a prescribed order. When executing the program code, the computer receives data from the input and/or storage devices, performs operations on the data, and then delivers the resulting data to the output and/or storage devices .

[0079] Those of skill in the art will appreciate that the various illustrative modules and method steps described herein can be implemented as electronic hardware, software, firmware or combinations of the foregoing. To clearly illustrate this interehangeability of hardware and

software, various illustrative modules and method steps have been described herein generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular

application and design constraints imposed on the overall system. Skilled persons can implement the described

functionality in varying ways fo each particula

application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure. In addition, the grouping of functions within module or step is for ease of description.

Specific functions can be moved from one module or step to another without departix'sg from the present disclosure.

[0080] All features of each above-discussed example are not necessarily required in a particular implementation of the resent disclosure, Further, it is to be understood that the description and drawings presented herein are

representative of the subject matter which is broadly contemplated by the present disclosure. It is further understood that the scope of the present disclosure fully encompasses other implementations that may become obvious to those skilled in the art and that the scope of the present disclosure is accordingly limited by nothing other than the appended claims.

Claims

1. Ά method, for processing a genuine instance of a digital good using a blockchain, the method comprising: registering an ownership of the genuine instance using a plurality of transactions, the genuine instance uniquely identified by a content descriptor which is

cryptograph!cally linked to an ownership token and includes intrinsic characteristics of the genuine instance,

wherein the ownership token includes a token seed and a token signature;

validating each transaction of the plurality of transactions by a plurality of validators; and

recording that th genuine instance belongs to an owner by recording each transaction of the pl.u al.ity of transactions in the blockchain once each transaction has been validated.

2, The method of claim 1, wherein the intrinsic characteristics comprise:

a unique identifier of the genuine instance which is calculated as a one-way cryptographic hash ox the token seed;

a ayload of an imperceptible waterrsark embedded in the genuine instance;

an instance hash of the plurality of transactions; and, a content signature signed by the owner of a previous transaction ,

3, The method of claim I, wherein the ownership token includes information that links the genuine instance to the own r ,

4, The method of claim 1, wherein registering an ownership of the genuine instance is performed by an

ssuer ,

5, The method of claim 4, wherein the intrinsic ch racteristics comprxse :

a unigue identifie of the genuine instance which is calculated as a one-way cryptographic hash of the token seed;

a payload of an imperceptible watermark embedded in the genuine instance;

an instance hash of th pluralit of transactions;

a content signature signed by the issuer; and

a certificate key of the issuer.

The method of c^'laixa S, wherein validating each transaction comprises:

verifying the validity of the content signature; and verifying the validity of the ownership token,

7. The method of claim 6, wherein verifying the validity of the ownership token in a resale comprises: verifying the validity of the token seed; and verifying that the token signature is an actual signature of the token seed submitted by the owner in a previous transaction.

8. The method of claim 4, wherein each transaction comprises ;

a transaction signature signed by the issuer; and a certificate key of the owner.

9. The method of claim 4, furthe comprising

generating, by the issuer, an initial random seed, wherein the initial randoxa seed enables the creation of a finite series of successive token seeds, each token seed being a one-way cryptographic hash of the token seed generated in a previous transaction.

10. The method of claim 9, further comprising

generating the unique identifier of the genuine instance with a single iteration of a one-way hash function of a last element of the finite series for an initial sale of the genuine instance.

11. The method Of claim 1, further comprising:

appointing a certification authority by the plurality of validators; and

generating key pairs and associated certificates used for identity management by the certification authority.

12. The method of claim 11, wherein generating key pairs and associated certificates comprises;

verifying that the associated certificates did not expire; and

verifying that the associated certificates were signed by the certification authority.

13. The method of claim 1, wherein the content

descriptor also comprises

a set of visible marks that is unique to th genuin instance,

14. The method of claim 1, wherein the ownership token also comprises a token signature of the token seed,

15. The method of claim 1, wherein registering an ownership o the genuine instance is performed by the owner in previous transaction,

16. The method of claim 15, further comprising:

generating, by the owner in the previous transaction, a new ownership token by signing the token seed with a private key of the owner in the previous transaction; and generating a suite of. linked token, seeds.

17. A non-transitory computer-readable storage medium storing a computer program to process a genuine instance of a digital good using a folockehain, the computer program comprising executable instructions that cause a computer to:

register an ownership of the genuine instance using a plurality of transactions, the genuine instance uniquel identified by a content descriptor which is cryptographically linked to an ovfnership token and includes intrinsic characteristics of the genuine instance,

wherein the ownership token includes a token seed and a token signature;

validate each transaction of the plurality of

transactions by a plurality of validators; and

record that the genuine instance belongs to an owner y recording each transaction of the plurality of

transactions in the folockchain once each transaction has been validated ,

18. A system for processing a genuine instance of a digital good using a biockchain, the system comprising: an issuer configured to register an ownership of the genuine instance using a plurality of transactions,: the genuine instance uniquely identified by a content

descriptor which is cryptographically linked to an

ownership token and includes intrinsic characteristics of the genuine instance,

wherein the ownership token includes a token seed and a token, signature; and

a plurality of validators configured to validate each of the plurality of transactions, wherein the genuine instance is recorded as belong to an owner by recording each transaction of the piuraiity of transactions in the biockchain once each transaction has been validated by the piuraiity of validators.

19. The system of claim IB, wherein the intrinsic characteristics compris :

a -unique identifier of the genuine instance whic is calcuiated as a one-way cryptographic hash of the token seed;

a payload of an imperceptible watermark embedded in the gen ine instance;

an instance hash of the plurality of transactions; and a content signature signed by the owner in a previous transaction .

20. The system of claim 19, further comprising

a watermark detector configured to detect and extract the payload of the imperceptible watermark embedded in the genuine instance .

21. The syste of claim 18, wherein the ownership token inGiudes information that links the genuine instance to the owne .

22. The systern of claim 18, further comprising a certification authority configured to generate pairs and associated certificates used for identity management .