Patent Description:
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-excludability and non-rivalry may be disadvantageous to business. However, digital goods are by nature not scarce, thus with little intrinsic commercial value. <CIT> discloses a system and method for recording and transferring ownership of property and a decentralised system that does not require centralised authority. <CIT> discloses methods and systems for creating addressed accounts for receiving and exchanging digital transactional items associated with the addressed accounts.

Aspects and features of the present invention are defined and limited to the appended claims. 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 owner.

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

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

As described above, although scarcity drives value, digital goads are by nature not scarce, and thus may have little commercial value.

Certain implementations 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 be genuine instances, although, they may be bit-to-bit copies of the genuine instance. All derived versions, such compressed or resized instances, would not be genuine instances, regardless of the ownership. 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.

Digital signatures and digital rights management may be used to verify the integrity of an instance. However, the digital signature does not discriminate the genuine instance from copied instances. Although the digital rights management is a get 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.

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 by way of example only, and not limitation.

The blockchain 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 blockchains amd usage of blockchains, but the most famous ones are Bitcoin and Ethereum.

<FIG> is, a block diagram of a blockchain <NUM> including n blocks <NUM>, <NUM>, <NUM> and a genesis block <NUM>. In one implementation, a block has at least three elements: (a) an information section (e. g, <NUM>), that stores the registerered data and ancillary data, wherein the information section may be signed to prove its authenticity, (b) the cryptographic hash (e. g, <NUM>) of the previous block, (the genesis block will not have a previous block); and (c) the cryptographic hash (e. g, <NUM>), of the current block. Thus, the data structure of the blockchain provides an append-only global ledger, which is tamper evident.

<FIG> is a block diagram of a blockchain-based system <NUM> for processing a genuine instance of a digital good in accordance with one implementation of the present disclosure. The blockchain-based system <NUM> of <FIG> includes an issuer <NUM>, a genuine instance <NUM>, a transaction <NUM>, and a blockchain <NUM>.

In one implementation, the transaction <NUM> registers the ownership of the genuine instance <NUM> and the issuer <NUM> creates and delivers the genuine instance <NUM> to an initial owner <NUM>. Each genuine instance <NUM> is uniquely identified by a uniquecombination of intrinsic characteristics referred to as a content content which is illustrated in <FIG>. The issuer <NUM> generates the initial transaction <NUM>. The blockchain <NUM> holds every transaction <NUM> generated by the issuer <NUM>.

<FIG> is a block diagram of a transaction <NUM> including a contnet descriptor <NUM>, an ownership token <NUM>, a transaction signature <NUM>, and an owner certificate key <NUM>, in accordance with one implementation of the present disclosure. In the illustrated implementation of <FIG>, the content descriptor <NUM> includes a unique identifier (Unique ID) <NUM> of the genuine instance <NUM>, a payload <NUM>, an instance hash <NUM>, a content signature <NUM>, and an issuer certificate key <NUM>. The content descriptor <NUM> may also include an optional set of visible marks that is unique to the genuine instance <NUM> (similar to the printing number in a series of lithography).

The payload <NUM> corresponds to the actual payload of an imperceptible watermark embedded in the genuine instance <NUM> and is unique to the genuine instance <NUM>. 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 <NUM>, the imperceptible watermark may be invisible, inaudible, or text-based. The cryptographic instance hash <NUM> is a cryptographic digest of the essence of the genuine instance <NUM>. The content signature <NUM> is a digital signature of the previous parameters signed by the issuer <NUM> (similar to the signature of the painter on lithography).

The ownership token <NUM> is digital information that links the genuine instance <NUM> to its owner <NUM>, and includes a token seed <NUM> and a token signature <NUM>. Unique ID is equal to f(token seed), where f is a content that Xa difficult to reverse (e.g., a one-way cryptographic hash). The token signature <NUM> is a digital signature of the token seed issued by the issuer <NUM>.

The ownership of each genuine instance <NUM> is recorded by the transaction <NUM> that holds the content descriptor <NUM>, the ownership token <NUM>. , and an owner's certificate key <NUM>. The issuer <NUM> signs the transaction <NUM> with the transaction signature <NUM>. The validation of a transaction <NUM> verifies the content signature <NUM> and the validity of the ownership token <NUM>. The blockchain <NUM> records any change of ownership of a genuine instance <NUM> by adding a new transaction <NUM> describing the transfer of ownership in the information section of a new block. The change of ownership may use one of two methods (one involving an issuer and another not involving an issuer).

In the first method (not involving an issuer), the seller, who is the current owner of the genuine instance, generates a new ownership token <NUM> by signing the to*w seed <NUM> with Ow seller's private key (i.e., owner's private key of the previous transaction). The new transaction <NUM> holds the content descriptor <NUM>, the new ownership token <NUM> signed by the seller, the certificate key of the future owner <NUM>, and is signed by the seller. new block with the transaction <NUM> is stored on the blockchain <NUM>.

In the second method (involving an issuer), the issuer <NUM> generates an initial random seed when creating the genuine instance <NUM>. The initial random seed enables the creationof a suite of N linked token seeds as shown below. In 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 <NUM> also defines a transaction threshold N and calculates the transaction as follows: <MAT> <MAT> <MAT> <MAT>.

Accordingly, the initial token seed <NUM> is the Nth iteration, i.e. TN-<NUM>, of f with the initial random seed. When resold, the token seed of tiw new transaction is Tn-<NUM>. In case of the nth resale, the new token seed <NUM> is the (N-n)th iteration of f. In one implementation, the one-way function f is a secure hash algorithm <NUM> (SHA3) with an output of <NUM> bits, and N = <NUM>.

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 <NUM> can calculate the new value of the token seed <NUM> since only the issuer <NUM> knows the initial random seed. The new transaction <NUM> uses the initial content descriptor <NUM>, the new ownership token <NUM> signed by the issuer, the certificate key of the future owner, and is signed by the seller. A new block with this transaction <NUM> is stored on the blockchain.

In the descriptions below, following notations are used. For an asymmetric key pair, the prefix Kpri represents the private key, whereas the prefix Kpub represents the public key, Notation Enc{Kpub}(m) represents the encryption of clear text m using the public key Kpub. Notation Dec{Kpri}(m') represents the decryption of ciphertext m' using the private key Kpri. If Kpri and Kpub are a public-private key pair then Dec{Kpri}(Enc{Kpub}(m) = m. Notation Sign{Kpri}(m) represents the digital signature of message m using the private key Kpri. Notation Ver{Kpub}(m, s) represents the digital verification of the signature s of message m using the public key Kpub. If Kpri and Kpub are a public-private key pair then Ver{Kpub}(m, Sign{Kpri}(m)) = true.

<FIG> is a block diagram of a system <NUM> for processing a genuine instance of a digital good in accordance with another implementation of the present disclosure. The blockchain-based system <NUM> of <FIG> includes an issuer <NUM>, a genuine instance <NUM>, a transaction <NUM>, a blockchain <NUM>, a watermark detector <NUM>, a certification authority <NUM>, and a set of validators <NUM>.

In one implementation, the set of validators <NUM> uses a consensus mechanism based on the Practical Byzantine Fault Tolerant agreement (PBFT) to add the new blocks. In one implementation, the set of validators <NUM> appoints a trusted certification authority <NUM> to generate key pairs and associated used for identity management. The validation of a certificate is a known process that imploes verifying the consistency of the information including verifying that the certificate did not expire and was signed by the trusted certification authority <NUM>.

In one implementation, regarding the cryptographic material used by the system <NUM> during the generation of the transaction <NUM>, the issuer <NUM> of issuer's public tey (Kpub_issuer) and issuer's private key (Kpri_issuer). The issuer <NUM> also has an issuer's certificate key issued by the certification authority <NUM> which is associated with the issuer's public key. In one implementation, the system <NUM> uses a hierarchical structure whose root: certification authority is the certification authority <NUM>. In one particular implementation, the system <NUM> uses Rivest, Shamir, and Adelman <NUM> (RSA2048) Public Key Cryptographic Standard <NUM> (PKCS1. <NUM>), while the issuer certificate key is X509 compliant, which is a standard defining the format of a certificate of public key.

In one implementation, the owner <NUM> has an owner's public key (Kpub_owner) and an owner's private key (Kpub_owner). The owner <NUM> 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 ;syswh uses RSA2048 PKCS1. <NUM>, while the owner certificate key is X509 compliant.

An example first eal'e of. a genuine instance <NUM> of 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.

(Wil) In the above-described example implementation, Alice performs the following operations (<NUM>) generates a <NUM>-bit random seed; (<NUM>) performs <NUM> iterations of SHA3 on the initial random seed which results in a token seed <NUM> (i.e., Tokenseed = SHA3<NUM> (SHA3<NUM> (. SHA3<NUM> (SHA3<NUM> random seed))))); (<NUM>) calculates Unique ID <NUM> (i.e., UniqueId = SHA3(TokenSeed)) (in the highly unlikely case that UniqueID has already been used for another genuine instance, a new random seed would be polled); (<NUM>) generates a <NUM>-bit random payload <NUM>; (<NUM>) embeds the random payload <NUM> into the digital good using a watermark embedder to produce the genuine instance <NUM>; (<NUM>) caioulates Instance hash <NUM> (i.e., InstanceHash = SHA3(GenuineInstance)) whose length is <NUM> bits; (<NUM>) calculates the content signature <NUM> (ContentSignature = Sign_RSA{Kpri_issuer} (UniqueID | Payload | InstanceRash | IssuerCertificateKey)); (<NUM>) builds the content descriptor by aggregating the Unique ID <NUM>, the Payload <NUM>, the instance hash <NUM>, the issuer certificate key <NUM>, and the content signature <NUM>; (<NUM>) store the Unique ID <NUM> and the random seed in a secure private databases (<NUM>) calculates the token, signature <NUM> (i.e., TokenSignature = Sign_RSA{Kpri_issuer}(TokenSeed)); (<NUM>) calculates the transaction signature <NUM> by signing the content descriptor <NUM>, the ownership token <NUM>, and Bob's owner certificate key <NUM> (i.e., TransactionSignature = Sign_RSA{Kpri_issuer} (ContentDescriptor | QwnershipToken | OwnerCertificateKey)); (<NUM>): builds the transaction <NUM> by aggregating the content descriptor <NUM>, the ownership token <NUM>, the transaction signature <NUM>, and the owner certificate key <NUM>; and (<NUM>) submits the transaction <NUM> to the validators <NUM>.

As described above in relation to <FIG>, the blockchain <NUM> is a permissioned blockchain, which means that a fixed set of known trusted validators validates each new block. In one implementation, the validators <NUM> are a set of servers managed by the issuer <NUM> (or a consortium of issuers) that handles the biockchain. Further, the blockchain <NUM> is public, which means that anybody can consult it. However, only a validator can add a new block to the blockchain <NUM>.

<FIG> and <FIG> form a flow diagram illustrating a process <NUM> 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 validation receives the transaction <NUM>, the validator validates the transaction <NUM> by checking the validity of three elements, namely, the content descriptor <NUM>, the ownership token <NUM>, and the transaction signature <NUM>.

U1DQ1 In one implementation, checking the validity of the content descriptor <NUM> includes: (<NUM>) extracting and acquiring to extracted payload from the genuine instance (e.g., using an online watermark detector <NUM>), at step <NUM>; (<NUM>) verifying, at step <NUM>, that the extracted payload is equal to the payload <NUM> (the genuine instance has an embedded watermark whose payload is "extracted payload". If the submitted content is genuine, the payload in the transaction should match the value carried by the genuine instance's watermark. ); (<NUM>) verifying that the issuer certificate key <NUM> is a valid certificate issued by the certification authority <NUM>; and (<NUM>) verifying, at step <NUM>, that the content signature <NUM> is the actual signature of the content descriptor generated by Alice (i.e., Ver_RSA{Kpub_issuer} (UniqueID I Payload I InstanceHash I IssuerCertificateKey | ContentSignature) - true)).

In one implementation, checking the validity of the content description <NUM> also includes verifying that there is no double spending of the genuine instance, at step <NUM>. We validator checks, that there is no double spending by checking that there is not already a block issued by Alice in the blockchain <NUM> that has the corresponding payload <NUM> and the Unique ID <NUM>.

In one implementation, checking the validity of the ownership token <NUM> includes: (<NUM>) verifying, at step <NUM>, the validity of the taken seed <NUM> (i.e., UniqueID = SHA3(TokenSeed)); and (<NUM>) verifying, at step <NUM>, that the token signature <NUM> is the actual signature of a token seed <NUM> submitted by Alice (i.e., Ver_RSA{Kpub_issuer} (TokenSeed | TokenSignature) = true)).

In one implementation, checking the validity of the transaction signature <NUM> includes: (<NUM>) verifying, at step <NUM>, that the transaction signature <NUM> is the actual signature of the transaction <NUM> by Alice (i.e.,.

Ver_RSA(Kpub_issuer) (ContentDescription |OwnershipToken | OwnerCertificateKey, ContentSignature) = true)); and (<NUM>) verifying that the owner certificate key <NUM> is a valid certificate (e.g., X509 certificate) issued by the certification authority <NUM>.

In one implementation, once the three conditions are fulfilled (i.e., the validity of the content descriptor <NUM>, the ownership token <NUM>, and the transaction signature <NUM>), the validator <NUM> generates a new block including a single transaction. In other embodiments, once the three conditions are fulfilled, the validator <NUM> generates a new block for the blockchain <NUM> including a plurality of transactions. If the block includes multiple transactions, the validate <NUM> validates all transactions. As illustrated in <FIG>, the new clock(s) includes the transaction (in the information section <NUM>), the hash <NUM> of the previous block, and hash <NUM> of the new clock. The structure of the block and the type of hash function depends ob the type of blockchain used.

In illustrated implementation of <FIG> and <FIG>, the validator <NUM> submits the new block to the blockchain consensus mechanism, at step <NUM>. 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 <NUM>, that at least <NUM>/<NUM> of the set of validators <NUM> approves the new-block, then the new block is added to the blockchain <NUM>, at step <NUM>. That is, the blockchain <NUM> records that Bob owns the genuine instance <NUM> described by content descriptor <NUM> issued by Alice. Otherwise, the validator rejects the block, at step <NUM> and the block is not appended to the blockchain <NUM>.

In step <NUM> of the illustrated implementation of <FIG>, the validators <NUM> within the consensus mechanism are asked to validate that a digital content is an actual genuine instance belonging to a particular owner.

Two example implementation are described below to illustrate the process to validate that a digital content is (<NUM>) an actual genuine instance belonging to (<NUM>) a particular owner.

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 blockchain and verifying that the block corresponds to the provided pristine nqpy. Prudence also checks the identity of Bob.

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: (<NUM>) verifies that the hash of a scopy of genuine instance is equal to the instance hash <NUM> (i.e., InstanceHash ==
SHA3 (CopyOfGenuineInstance)); (<NUM>) extracts an extracted payload from the copy of genuine instance using a watermark detector <NUM>; and (<NUM>) verifies that the extracted payload is equal to the payload <NUM>. Further, to verify the identity of Bob, Prudence verifies that the owner certificate key <NUM> is still valid and that it matches the public key provided by Bob; Thus, Prudence (<NUM>) generates and sends a <NUM>-bit random number called 'Challenge' to Bob, who encrypts it with his private key (Kpri_owner) to create and return 'Answer Challenge' (AnswerChallenge = RSA_ENC{Kpri_owner}(Challenge)) to Prudences; and (<NUM>) verifies that Chllenge = RSA_DEC{Kpub_ower}(AnswerChallenge). If the above three conditions are met, Prudence validates that Bob owns 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 <NUM> recorded in the blockchain.

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: (<NUM>) searches the blockchain for the most recent block with the unique ID <NUM>; (<NUM>) extracts an extracted payload from the copy of the genuine instance using a watermark detector <NUM>; (<NUM>) verifies that the extracted payload is equal to the payload <NUM>; and (<NUM>) verifies the identity of Bob. In one implementation, the identity of Bob is verified by performing the following steps: (<NUM>) verifies that the public key provided by Bob matches the owner certificate key <NUM> and that the owner certificate key <NUM> is still valid; (<NUM>) generates and sends a <NUM>-bit random number ("challenge") to Bob; (<NUM>) receives an 'answer challenge" from Bob, wherein the "answer challenger" was generated by Bob encrypting the "challenge" with Bob's private key (i.e., AnswerChallenge = RSA_ENC{Kpri_owner}(Challenge)); and (<NUM>) verifies that Challenge = RSA_ENC{Kpub_owner{(AnswerChallenge). If this is true, Prudence concludes that Bob owns the corresponding genuine instance. In the second example implementation, the verification does not require a pristine copy of the 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 prove that Bob has genuine instance but only that the owns, it.

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 Kpri_Bob and Kpub_Bob form Bob's key pair, and are, initially, the keys of the owner. Notations Kpri_Ophelia and Kpub_Ophelia form Ophelia's key pair, and are, initially, the keys of the new owner. In this example implementation, the resale may occur with br without an issuer.

In the example resale implementation without the issuer, the following steps are performed: (<NUM>) Bob forwards a pristine copy of the genuine instance to Ophelia; (<NUM>) 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; (<NUM>) Bob verifies the identity of Ophelia: (a) Ophelia provides to Bob a certificate (e.g., the X509 certificate of her public key; (b) Bob generates and sends a <NUM>-bit random number called 'challenge' to Ophelia; (c) Ophelia encrypts 'challenge' with Ophelia's private key (Kpri_Ophelia) to generate AnswerChallenge = RSA_ENC{Kpri,Ophelia}(Challenge); (d) Ophelia returns AnswerChallenge to Bob; (e) Bob verifies that Challenge = RSA_DEC{Kpub_Ophelia}(AnswerChallenge); (<NUM>) Bob generates a new ownership token by signing the token seed with his private key (Kpri_Bob); (<NUM>) Bob calculates the new transaction signature by signing the content descriptor, the new ownership token, and Ophelia's owner certificate key (i.e., TransactionSignature = Sign_RSA{Kpri_Bob}(ContentDescriptor | OwnershipToken | OpheliaCertificatedKey)); (<NUM>) 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 (<NUM>) Bob submits the transaction to a validator.

<FIG> and <FIG> form a flow diagram illustrating a process <NUM> for validating a resale of a genuine instance at a digital good without an issuer in accordance with one implementation of the present disclosure. In the illustrated implementation of <FIG>, the validator searches for and retrieves the most recent block with Unique ID, at step <NUM>. The validator then checks three conditions, (<NUM>) the validity of the content descriptor, (<NUM>) the validity of the new ownership token, and (<NUM>) the proposed transaction signature.

In the first implementation, the validity of the content descriptor is checked, at step <NUM>, 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 <NUM> continues. Otherwise, the block is declared as not valid, at step <NUM>.

In the second implementation, the validity of the new ownership token is checked at steps <NUM> and <NUM>. At step <NUM>, the validity of the token seed is verified by checking that UniqueID = SHA3(TokenSeed). Then, at step <NUM>, the token signature of the proposed transaction is verified by (<NUM>) extracting the owner certificate key of the retrieved block, and (<NUM>) 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., Ver_RSA{Kpub_Bob( TokenSeed, TokenSignature)==True). If the signatures match, then the signatory is the current owner, i.e., Bob.

In the third implementation, the proposed transaction signature is checked, at step <NUM>, by verifying that the proposed transaction signature is the actual signature of the transaction by Bob (i.e., Ver_RSA(Kpub_Bob) (ContentDescriptor | OwnershipToken | CertificateOphelia, TransactionSignature)==True) and that the owner certificate key is a valid certificate issued by the certification authority.

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 <NUM>. Otherwise, the block is declared as not valid, at step <NUM>.

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

In the example resale implementation with the issuer, the following steps are performed: (<NUM>) Bob forwards a pristine copy of the genuine instance to Ophelia; (<NUM>) Ophelia verifies that it is the expected instance as described in the previous section; (<NUM>) Bob verifies the identity of Ophelia: (a) Ophelia provides to Bob a certificate (e.g., the X509 certificate) of her public key; (b) Bob generates and sends a <NUM>-bit random number called 'challenge' to Ophelia; (c) Ophelia encrypts 'challenge' with Ophelia's private key (Kpri_Ophelia) to generate AnswerChallenge = RSA_ENC{Kpri_Ophelia}(Challenge); (d) Ophelia returns AnswerChallenge to Bob; (a) Bob verifies that Challenge = RSA_DEC{Kpub_Ophelia}(AnswerChallenge); (<NUM>) Alice verifies that Bob owns the genuine instance as described in the previous section; (<NUM>) Alice counts the number of blocks (n) in the blockchain related to Unique ID (i.e., the number of transactions to the genuine instance); (<NUM>) Alice performs <NUM>-n iterations of SHA3 on the initial seed to generate the new token seed (i.e., UniqueID = SHA3<NUM>-n (SHA3<NUM>-n(. SHA3<NUM>( SHA3<NUM>(Seed))))); (<NUM>) Alice calculates the token signature (i.e., TokenSignature =Sign_RSA{Kpr1_issuer} (TokenSeed)); (<NUM>) Alice returns the new ownership token securely to Bob; (<NUM>) Bob calculates the new transaction signature by signing the content descriptor, the new ownership token, and Ophelia's owner certificate key (i.e., TransactionSignature = Sign_RSA{Kpr1_Bob} (ContentDescriptor | OwnershipToken | OpheliaCertificateKey)); (<NUM>) 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 (<NUM>) Bob transfers the transaction to a validator.

<FIG> and <FIG> form a flow diagram illustrating a genuine <NUM> for validating a resale of a genuine instance of a digital good with an issuer in accordance with one implementation of the present disclosure. In the illustrated implementation of <FIG>, the validator searches for and retrieves the most recent block with Unique ID, at step <NUM>. The validator then the three conditions, (<NUM>) the validity of the content descriptor, (<NUM>) the validity of the new ownership token, and (<NUM>) the proposed transaction signature.

In the first implementation, the validity of the content descriptor is checked, at step <NUM>, by matching the content descriptor in the retrieved block to the content descriptor of genuine transaction submitted by Bob. If a match results, the process <NUM> continues. Otherwise, the block is declared as not valid, at step <NUM>.

In the second implementation, the validity of the new ownership token is checked at steps <NUM>, <NUM>, and <NUM>. At step <NUM>, the number of blocks (n) in the blockchain related to Unique ID is counted. At step <NUM>, the validity of the token seed is verified by making n+<NUM> iterations of SHA3 and checking that UniqueID = SHA3n (. SHA3<NUM> (TokenSeed)). Then, at step <NUM>, 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 <NUM>.

In the third implementation, the proposed transaction signature is checked, at block <NUM>, by verifying that the proposed transaction signature is the actual signature of transaction by Bob (i.e., Ver_RSA(Kpub_Bob) (ContentDescriptor | OwnershipToken | CertificateOphelia, TransactionSignature)==True) and that the owner certificate key is a valid certificate issued by the certification authority.

In one implementation, if at least <NUM>/<NUM> of the 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.

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.

Accordingly, the above-described implementations provide for creating the scarcity with 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.

Alice cannot sell the same genuine instance to Bob and Charles. Assume that Alice provides the same digital file to Bob and Charles by using different seeds for Bob and Charles, resulting in two different UIDs. 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 by the consensus mechanism. Alice can make several genuine instances from the same original file. However, each genuine instance has a different watermark, thus, making each genuine instance unique.

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.

Eve cannot claim a genuine instance without owning it. Eve cannot pass the ownership test as the challenge response requires having Bob's private key.

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 signature The blockchain guarantees the transfer of ownership.

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.

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 be accorded the widest scope consistent with the features disclosed herein.

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-volatile memory modules and persistent signature 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).

The computer programs include executable code that is usually stored in a persistent storage medium and then copied into memory 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.

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 interchangeability 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 genuine on the overall system. Skilled persons can implement the described functionality in varying ways for each particular 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 a module or genuine is for ease of description. signature genuine can be moved from one module or step to another genuine departing from the present disclosure.

Claim 1:
A method for processing a genuine instance (<NUM>) of a digital good using a blockchain (<NUM>), the method comprising:
registering an ownership of the genuine instance (<NUM>) by an issuer using a plurality of transactions, the genuine instance (<NUM>) uniquely identified by a content descriptor (<NUM>) which is cryptographically linked to an ownership token (<NUM>) and includes intrinsic characteristics of the genuine instance,
wherein the ownership token (<NUM>) includes information that links the genuine instance to an owner and includes a token seed and a token signature, wherein the content descriptor and the ownership token are included in each transaction of the plurality of transactions;
validating each transaction of the plurality of transactions by a plurality of validators; and
recording that the genuine instance belongs to the owner by recording each transaction of the plurality of transactions in the blockchain (<NUM>) once each transaction has been validated, wherein the intrinsic characteristics comprise:
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, the instance hash being a hash of the genuine instance:
a content signature signed by the issuer; and
a certificate key of the issuer, and the validating each transaction of the plurality of transactions by the plurality of validators comprises verifying the validity of the content signature; and verifying the validity of the ownership token.