DETAILED ACTION
Acknowledgements
This Non-Final Office Action is in reply to Applicant’s original application and preliminary amendment filed March 19, 2025.
Claims 1-19, 21 are currently pending.
Claims 1-19, 21 have been examined.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Objections
Claims 1, 3, 5, 6, 8, 9, 11, 16, 21 are objected to. The suggested corrections are shown using strikethrough and underlining.
Claim 1 recites, in relevant part:
generating a first blockchain transaction, wherein generating the first blockchain transaction comprises:
generating a first input of the first blockchain transaction that includes a reference referencing an output of the token issuance transaction or an output of a previous transaction that forms part of a chain of one or more previous transactions linking to the token issuance transaction, wherein the referenced output is locked to a first public key of the sending party,
sending the first blockchain transaction to a receiving party, wherein the receiving party is configured to verify that the first input references the output of the token issuance transaction or the output of the previous transaction that forms part of the chain of one or more previous transactions linking to the token issuance transaction, and verify that the first output is locked to the public key of the receiving party, and if so, generate a funded first transaction by including one or more respective inputs in the first blockchain transaction that reference one or more respective outputs of one or more respective funding transactions, the one or more respective outputs being locked to one or more respective public keys of the receiving party;
including the digital signature in the first input of the funded first transaction
Claim 21 is objected to for the same reasons.
Claims 3, 5, 6, 9 also contain references to the “first transaction” which should be changed to “first blockchain transaction” to ensure it is referred to consistently throughout the claims.
Claim 3 recites, in relevant part:
The method of claim 1, wherein the referenced output comprises an enforcement locking script […]
Claim 8 recites:
The method of claim 3, wherein the constraint sub-script comprises a non-interactive zero-knowledge verification algorithm configured to verify that the constraint proof has been generated for satisfying a particular program, and wherein the method comprises generating the constraint proof for satisfying the particular program.
Claim 8 appears to mistakenly refer to the “commitment sub-script” instead of the “constraint sub-script”. It is inconsistent with claim 3 and page 34 of the specification which both say that the constraint sub-script verifies the constraint proof. However, since these are merely labels for parts of the enforcement locking script, there is no effect on the claim’s interpretation.
Claim 11 recites:
The method of claim 3, wherein at least one of the one or more constraints is that the committed blockchain transaction comprises an input that references the token issuance transaction or that the committed blockchain transaction references a transaction that forms part of a chain of one or more transactions linking to the token issuance transaction.
Claim 16 recites, in relevant part:
A computer-implemented method of accepting a token transferred using a blockchain, wherein the blockchain comprises a token issuance transaction, wherein the token issuance transaction comprises token data and an output locked to a public key of an issuing party, and wherein the method is performed by a receiving party and comprises:
Additionally, claim 16 refers to a “funded first blockchain transaction”, while every other claim refers to a “funded first transaction”. Either claim 16 or its dependents should be amended to refer to this consistently.
Claim 16 further recites:
[…] the second output comprising token data;
However, claim 1 recites “encoding token data into the first output”. Because claims 1 and 16 appear to be corresponding methods, it is likely that claim 16 contains a drafting error and it is supposed to be the first output that comprises token data. Applicant should verify whether this is correct and make any amendments as appropriate. However, the claim interpretation is unaffected because the token data is nonfunctional data which is never again referenced in claim 16 or its dependent claims.
Specification
The disclosure is objected to. Pages 61-66 of the specification contain similar language to the claims and must be amended to fix the same issues noted above, where applicable.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 1, 6, 9, 14, 18, 21 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention.
Regarding claims 1, 21
Claim 1 recites, in relevant part:
generating a second output of the first blockchain transaction, including constructing a locking script configured to cryptographically lock the first output to a public key of the sending party;
Claim 1 appears to contain a drafting mistake. It recites a locking script included in the second output which locks the first output. The “first output” is likely intended to say “second output”. As written, the claim is ambiguous because it is internally inconsistent since the script is in one output but says it locks another output. For purposes of examination, this limitation is interpreted as referring only to the second output.
Claim 1 further recites, in relevant part:
verifying that the second output locked to the public key of the sending party locks a predetermined amount of digital asset, and if so, generating a signed first transaction by:
This language creates ambiguity as to whether the steps that follow are conditional steps or required steps, and whether the step of “verifying” requires a particular result. For purposes of examination, the steps that follow are interpreted as required. The step of “verifying” is interpreted as ensuring that the condition is true. Removing the phrase “if so” would resolve the ambiguity.
Claim 21 contains similar language and is treated the same.
Regarding claim 6
Claim 6 recites:
The method of claim 3, wherein the commitment sub-script is configured to supply the transaction commitment proof to the constraint sub-script, and wherein the constraint sub-script is configured to use the verification key, the public input and the transaction commitment to verify that the constraint proof provides proof that the first transaction or the funded first transaction satisfies the one or more constraints.
There is no antecedent basis for “the transaction commitment proof”. Claim 3 introduces a “transaction commitment” and a “constraint proof”. “Transaction commitment proof” likely refers to one of these, but it is not clear which. For purposes of examination it is interpreted as referring to the transaction commitment.
There is no antecedent basis for “the public input”. A “public input” is introduced in claim 4, but claim 6 does not depend from claim 4. The intended dependency chain is therefore unclear. It is suggested that claim 6 should depend from claim 4 or proper antecedent basis for the public input be provided in claim 6.
Regarding claim 9
Claim 9 recites:
The method of claim 3, wherein the transaction commitment comprises a digital signature, wherein the commitment key comprises a public key, and wherein the commitment sub-script is configured to verify that the digital signature signs a message based on the first transaction or the funded first transaction, and wherein the method comprises generating a digital signature based on the first transaction or the funded first transaction.
There is no antecedent basis for “the commitment key”. A “commitment key” is introduced in claim 5, but claim 9 does not depend from claim 5. The intended dependency chain is therefore unclear. It is suggested that claim 9 should depend from claim 5 or proper antecedent basis for the commitment key be provided in claim 9.
Regarding claim 14
Claim 14 recites:
The method of claim 3, comprising including the enforcement locking script in the second output of the first blockchain transaction.
Claim 14 appears to contain a drafting mistake by referring to “the second output” whereas it likely should say “the first output”. Page 6 of the specification provides the following description which corresponds to this claim:
In that way, one can ensure that the spending transaction enforces the same conditions on the next spending transaction. That is, the n-1th transaction includes a locking script that forces the nth transaction to include the same locking script, which therefore forces the n+1th transaction to include the same locking script. In this way, a chain of transactions is created whereby each transaction includes the same locking script. This may be used in the context of digital tokens that, for example, represent ownership of real world objects, or even objects in a virtual world. This is advantageous as it means that each transfer of the token is subject to the same rules.
Additionally, Fig. 10 appears to show the enforcement locking script (“validate transfer”) being copied from the first input to the first output. Since the first output is the one locked to the receiving party and contains token data, the claim would read logically if “second output” was replaced with “first output”. As written, the claim is unclear because an enforcement locking script enforces token transfer rules and it’s unclear how it can be contained in the non-token output (see specification page 35 “The first transaction may be a token mint transaction that enforces conditions of a token protocol, via the enforcement locking script”). For purposes of examination, claim 14 is interpreted as referring to the first output.
Regarding claim 18
Claim 16 recites, in relevant part:
receiving a first blockchain transaction from a sending party via an off-chain communication channel;
verifying that a first output of the first blockchain transaction is cryptographically locked to a public key of the receiving party;
generating a funded first blockchain transaction by including one or more respective inputs in the first blockchain transaction […]
Claim 18 recites:
The method of claim 16, wherein the first output locked to the public key of the receiving party is included in the funded first transaction by the receiving party.
Claim 16 requires verifying that the first blockchain transaction includes a first output, and then generating the funded first blockchain transaction by adding to the first blockchain transaction. Therefore, claim 18, by virtue of its dependency on claim 16, already requires that the first output be present from the sending party. The step of claim 18 therefore creates ambiguity as to who is including the first output and whether claim 18 is intended to remove the “verifying” step from claim 16.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 2, 16-19, 21 are rejected under 35 U.S.C. 103 as being unpatentable over Pedro Franco Understanding Bitcoin.
Regarding claim 1
Franco teaches:
A computer-implemented method of transferring a token using a blockchain, wherein the blockchain comprises a token issuance transaction, wherein the token issuance transaction comprises token data and an output locked to a public key of an issuing party, and wherein the method is performed by a sending party and comprises:
generating a first blockchain transaction, wherein generating the first transaction comprises: {Fig. 12.1, annotated below; Page 184 “Figure 12.1 presents a straightforward way in which digital assets could be created. An issuer publicly declares that the funds in a certain Bitcoin address represent ownership of an asset. The issuer could be a custodian in possession of the asset or it could be the issuer of a financial obligation directly, like a company issuing its own shares. The issuer must be trusted, otherwise the digital asset would not be recognized to have any value. The issuer [sending party] could sell the asset to several buyers, transferring ownership through regular Bitcoin transactions. As Figure 12.1 shows, the ownership is transferred using a transaction with two inputs and two outputs. The transaction must be signed by both buyer [receiving party] and seller [sending party] of the digital asset, so there is no risk that one of the two parties cheats: unless the transaction is correctly signed by both, it is invalid and no transfer would take place2.”}
PNG
media_image1.png
603
771
media_image1.png
Greyscale
generating a first input of the first blockchain transaction that include[s] a reference referencing an output of the token issuance transaction or an output of a previous transaction that forms part of a chain of one or more previous transactions linking to the token issuance transaction, {See Fig. 12.1 above, element marked “first input”}
wherein the referenced output is locked to a first public key of the sending party, {Page 82 “The most common transaction type is pay-to-address.”; Page 83 “In summary, the creator of the output transaction puts in the following condition to spend the output: the new transaction must be signed with the private key associated with the Bitcoin address <hashPubKeyHex>. The input that spends this [out]put must provide two elements: An EC public key <pubKey> that when hashed corresponds to the address <hashPubKeyHex>.A signature <sig> of the whole transaction with the correct private key. This signature proves ownership of the Bitcoin address.”}
generating a first output of the first blockchain transaction, {See Fig. 12.1 above, element marked “first output”}
including constructing a locking script configured to cryptographically lock the first output to a public key of a receiving party, and encoding token data into the first output, and {Page 82 “The most common transaction type is pay-to-address.”; Page 83 “In summary, the creator of the output transaction puts in the following condition to spend the output: the new transaction must be signed with the private key associated with the Bitcoin address <hashPubKeyHex>. The input that spends this [out]put must provide two elements: An EC public key <pubKey> that when hashed corresponds to the address <hashPubKeyHex>.A signature <sig> of the whole transaction with the correct private key. This signature proves ownership of the Bitcoin address.”}
generating a second output of the first blockchain transaction, {See Fig. 12.1 above, element marked “second output”}
including constructing a locking script configured to cryptographically lock the [[first]] second output to a public key of the sending party; {Page 82 “The most common transaction type is pay-to-address.”; Page 83 “In summary, the creator of the output transaction puts in the following condition to spend the output: the new transaction must be signed with the private key associated with the Bitcoin address <hashPubKeyHex>. The input that spends this [out]put must provide two elements: An EC public key <pubKey> that when hashed corresponds to the address <hashPubKeyHex>.A signature <sig> of the whole transaction with the correct private key. This signature proves ownership of the Bitcoin address.”}
sending the first blockchain transaction to a receiving party, {Page 184 “The transaction has to be signed by the two parties before it is published in the blockchain. Thus the two parties need a communication channel aside from the Bitcoin network to send back and forth the partially signed transaction.”}
wherein the receiving party is configured to verify that the first input references the output of the token issuance transaction or the output of the previous transaction that forms part of the chain of one or more previous transactions linking to the token issuance transaction, and verify that the first output is locked to the public key of the receiving party, and if so, generate a funded first transaction by including one or more respective inputs in the first transaction that reference one or more respective outputs of one or more respective funding transactions, the one or more respective outputs being locked to one or more respective public keys of the receiving party; {See Fig. 12.1 above, element marked “respective input”; Page 184 “The transaction has to be signed by the two parties before it is published in the blockchain. Thus the two parties need a communication channel aside from the Bitcoin network to send back and forth the partially signed transaction.”}
This limitation is not given patentable weight because it claims a configuration of a receiving party rather than a method step. However, even if the above functions of the receiving party were claimed as method steps, they would be taught by Franco. Franco teaches passing the transaction back and forth and creating all of the claimed inputs and outputs. Verifying the correctness of the transaction before signing is at least implied.
Franco does not explicitly teach which inputs/outputs are filled by the buyer and which are filled by the seller. However, Franco teaches the buyer and seller passing the transaction back and forth and then each signing the completed transaction. Different variations on which party fills out each piece of information in the transaction are merely obvious variants, as it has no effect on the overall method.
receiving the funded first blockchain transaction from the receiving party; {Page 184 “The transaction has to be signed by the two parties before it is published in the blockchain. Thus the two parties need a communication channel aside from the Bitcoin network to send back and forth the partially signed transaction.”}
verifying that the second output locked to the public key of the sending party locks a predetermined amount of digital asset, {Fig. 12.1; Page 184 “The transaction has to be signed by the two parties before it is published in the blockchain. Thus the two parties need a communication channel aside from the Bitcoin network to send back and forth the partially signed transaction.”}
Figure 12.1 shows, annotated above, shows the second output pays the price (predetermined amount) to the seller. Franco does not explicitly teach verifying this. However, Franco teaches sending the partial transaction back and forth and signing it by each party. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention that verifying the correctness of the transaction before signing is at least implied in order to ensure the transaction is not maliciously altered.
and if so, generating a signed first transaction by:
generating a digital signature using a private key corresponding to the first public key of the sending party, and {Page 184 “The transaction has to be signed by the two parties before it is published in the blockchain. Thus the two parties need a communication channel aside from the Bitcoin network to send back and forth the partially signed transaction.”}
including the digital signature in the first input of the funded first transaction {Page 184 “The transaction has to be signed by the two parties before it is published in the blockchain.”; Page 83 “The input that spends this [out]put must provide two elements: An EC public key <pubKey> that when hashed corresponds to the address <hashPubKeyHex>.A signature <sig> of the whole transaction with the correct private key. This signature proves ownership of the Bitcoin address.”}
sending the signed first blockchain transaction to one or more nodes of a blockchain network and/or to the receiving party. {Page 184 “The transaction has to be signed by the two parties before it is published [sending to one or more nodes] in the blockchain.”}
Regarding claim 2
Franco teaches:
The method of claim 1, comprising verifying that the one or more respective funding transactions are on the blockchain, wherein said generating of the signed first transaction is conditional on said verification. {Page 78 “To verify that a transaction is valid, a node follows these steps: It checks that the previous outputs referenced by the transaction exist”}
Regarding claim 16
Franco teaches:
A computer-implemented method of accepting a token transferred using a blockchain, wherein the blockchain comprises a token issuance transaction, wherein the token issuance transaction comprises token data and an output locked to a public key an issuing party, and wherein the method is performed by a receiving party and comprises: {Fig. 12.1, annotated above in relation to claim 1; Page 184 “Figure 12.1 presents a straightforward way in which digital assets could be created. An issuer publicly declares that the funds in a certain Bitcoin address represent ownership of an asset. The issuer could be a custodian in possession of the asset or it could be the issuer of a financial obligation directly, like a company issuing its own shares. The issuer must be trusted, otherwise the digital asset would not be recognized to have any value. The issuer [sending party] could sell the asset to several buyers, transferring ownership through regular Bitcoin transactions. As Figure 12.1 shows, the ownership is transferred using a transaction with two inputs and two outputs. The transaction must be signed by both buyer [receiving party] and seller [sending party] of the digital asset, so there is no risk that one of the two parties cheats: unless the transaction is correctly signed by both, it is invalid and no transfer would take place2.”}
receiving a first blockchain transaction from a sending party via an off-chain communication channel; {Page 184 “The transaction has to be signed by the two parties before it is published in the blockchain. Thus the two parties need a communication channel aside from the Bitcoin network to send back and forth the partially signed transaction.”}
verifying that the first blockchain transaction comprises a first input that references an output of the token issuance transaction or an output of a previous blockchain transaction that forms part of a chain of one or more previous blockchain transactions linking to the token issuance transaction, wherein the referenced output is locked to a first public key of the sending party; {Fig. 12.1; Page 78 “To verify that a transaction is valid, a node follows these steps: It checks that the previous outputs referenced by the transaction exist”}
verifying that a first output of the first blockchain transaction is cryptographically locked to a public key of the receiving party; {Fig. 12.1, annotated above; Page 184 “Figure 12.1 presents a straightforward way in which digital assets could be created. An issuer publicly declares that the funds in a certain Bitcoin address represent ownership of an asset. The issuer could be a custodian in possession of the asset or it could be the issuer of a financial obligation directly, like a company issuing its own shares. The issuer must be trusted, otherwise the digital asset would not be recognized to have any value. The issuer [sending party] could sell the asset to several buyers, transferring ownership through regular Bitcoin transactions. As Figure 12.1 shows, the ownership is transferred using a transaction with two inputs and two outputs. The transaction must be signed by both buyer [receiving party] and seller [sending party] of the digital asset, so there is no risk that one of the two parties cheats: unless the transaction is correctly signed by both, it is invalid and no transfer would take place2.”}
In Figure 12.1 above, the output annotated “first output” says “1Buyer1:Asset”. It is the output that sends the asset to the buyer.
generating a funded first blockchain transaction by including one or more respective inputs in the first blockchain transaction that reference one or more respective outputs of one or more respective funding transactions, the one or more respective outputs being cryptographically locked to one or more respective public keys of the receiving party, wherein the funded first blockchain transaction comprises a second output cryptographically locked to a public key of the receiving party, the second output comprising token data; {Fig. 12.1, annotated above;}
In Figure 12.1 above, the output annotated “respective input” says “1Buyer1:Price”. It is the input that unlocks the price (funds the purchase of the asset).
Franco does not explicitly teach which inputs/outputs are filled by the buyer and which are filled by the seller. However, Franco teaches the buyer and seller passing the transaction back and forth and then each signing the completed transaction. Different variations on which party fills out each piece of information in the transaction are merely obvious variants, as it has no effect on the overall method.
sending the funded first blockchain transaction to the sending party via an off-chain communication channel, {Page 184 “The transaction has to be signed by the two parties before it is published in the blockchain. Thus the two parties need a communication channel aside from the Bitcoin network to send back and forth the partially signed transaction.”}
wherein the sending party is configured to verify that the one or more respective funding transactions are on the blockchain and verify that a second output of the funded first transaction is locked to a public key of the sending party and locks a predetermined amount of digital asset, and if so, generate a signed first transaction by including a signature in the first input of the funded first transaction, wherein the signature corresponds to the first public key of the sending party, and send the signed first transaction to one or more nodes of a blockchain network and/or to the receiving party.
This language describes the configuration of the sending party. It does not describe any method steps, and is therefore not given patentable weight. However, claim 1, discussed above, appears to be directed towards the corresponding method performed by the sending party.
Regarding claim 17
Franco teaches:
The method of claim 16, comprising:
receiving the signed first transaction from the sending party; and {Page 184 “The transaction has to be signed by the two parties before it is published in the blockchain. Thus the two parties need a communication channel aside from the Bitcoin network to send [receiving] back and forth the partially signed transaction.”}
sending the signed first transaction to one or more nodes of the blockchain network. {Page 184 “The transaction has to be signed by the two parties before it is published [sending to one or more nodes] in the blockchain.”}
Regarding claim 18
Franco teaches:
The method of claim 16, wherein the first output locked to the public key of the receiving party is included in the funded first transaction by the receiving party. {Fig. 12.1, annotated above}
Franco does not explicitly teach which inputs/outputs are filled by the buyer and which are filled by the seller. However, Franco teaches the buyer and seller passing the transaction back and forth and then each signing the completed transaction. Different variations on which party fills out each piece of information in the transaction are merely obvious variants, as it has no effect on the overall method.
Regarding claim 19
Franco teaches:
The method of claim 16, wherein the referenced output comprises a enforcement locking script, wherein the enforcement locking script comprises a commitment sub-script, and a constraint sub-script comprising a verification key, and wherein when executed together with an unlocking script of a blockchain transaction, the unlocking script comprising a transaction commitment and a constraint proof, the enforcement locking script is configured such that the commitment sub-script is configured to verify that the transaction commitment corresponds to the blockchain transaction, and the constraint sub-script is configured to use the verification key to verify that the constraint proof provides proof that a committed blockchain transaction satisfies one or more constraints, and wherein the method comprises:
This language is directed towards data and functions of the commitment sub-script and the constraint sub-script. The commitment sub-script and the constraint sub-script are not created as part of the method, and their functions are not method steps. The commitment sub-script and the constraint sub-script are code which already exists on the blockchain when the method is being performed. This limitation is therefore merely describing an intended environment of use. It does not describe a method step or limit the performance of any method step and is not given patentable weight.
verifying that the verification key corresponds to a particular verification key, wherein said generating of the funded first transaction is conditional on the verification key corresponding to the particular verification key. {Page 83 “The input that spends this input must provide two elements: An EC public key [particular verification key] <pubKey> that when hashed corresponds to the address <hashPubKeyHex> [verification key].”}
Regarding claim 21
Claim 21 is similar in scope to claim 1 and is treated the same with respect to prior art rejections.
Claims 3-15 are rejected under 35 U.S.C. 103 as being unpatentable over Franco as applied to claim 1 above, and further in view of Trock (US 20240013213 A1).
Regarding claim 3
Franco teaches:
generating a transaction commitment based on the first transaction or the funded first transaction;
including the transaction commitment […] in an unlocking script of the first input of the first transaction or the funded first transaction. {Page 82 “The most common transaction type is pay-to-address.”; Page 83 “In summary, the creator of the output transaction puts in the following condition to spend the output: the new transaction must be signed with the private key associated with the Bitcoin address <hashPubKeyHex>. The input that spends this [out]put must provide two elements: An EC public key <pubKey> that when hashed corresponds to the address <hashPubKeyHex>.A signature <sig> [transaction commitment] of the whole transaction with the correct private key. This signature proves ownership of the Bitcoin address.”}
Franco does not teach, however Trock teaches:
The method of claim 1, wherein the referenced output comprises a enforcement locking script, wherein the enforcement locking script comprises a commitment sub-script, and a constraint sub-script comprising a verification key, and wherein when executed together with an unlocking script of a blockchain transaction, the unlocking script comprising a transaction commitment and a constraint proof, the enforcement locking script is configured such that the commitment sub-script is configured to verify that the transaction commitment corresponds to the blockchain transaction, and the constraint sub-script is configured to use the verification key to verify that the constraint proof provides proof that a committed blockchain transaction satisfies one or more constraints, and wherein the method comprises:
generating a constraint proof based on the first transaction or the funded first transaction, wherein the constraint proof provides proof that the first transaction or the funded first transaction satisfies the one or more constraints; and
including the […] the constraint proof in an unlocking script of the first input of the first transaction or the funded first transaction. {[0004] “the method comprising: identifying an input of a transaction; identifying a locking script associated with an output of a previous transaction that is referenced by the input, wherein the locking script comprises a persisting smart contract [constraint sub-script] that is arranged to persist through multiple transactions on the blockchain; and outputting a transmission to the second node in dependence on: the persisting smart contract being present in a locking script of an output of the transaction; and/or a redemption condition [constraints] of the persisting smart contract being satisfied; wherein the persisting smart contract comprises a token identifier; and wherein the token identifier is associated with a contract transaction, which contract transaction is associated with the persisting smart contract, wherein the contract transaction defines the redemption condition.”}
The constraint proof is the data in the first input which satisfies the locking script of the referenced output.
As discussed above, Franco teaches a transaction which is collaboratively created and signed by a buyer and seller in order to accomplish simultaneous transfer of a digital asset and its purchase price. Franco teaches the transaction inputs containing unlocking scripts which satisfy a referenced output’s locking script. Trock further teaches a locking script containing a “persisting smart contract” containing a “redemption condition” which follows the asset by requiring that it be present in the output of the spending transaction.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to add the persisting smart contract of Trock to the transaction method of Franco. Since both references are directed towards generic blockchain techniques, using both of them on the same blockchain would be straightforward. Combining them would have the advantage of allowing the issuer of the asset to place conditions on its transfer which stay in place as the asset is bought and sold.
Regarding claim 4
The method of claim 3, wherein the constraint sub-script and/or the unlocking script of the first input comprises a public input, and wherein the constraint sub-script is configured to use both the verification key and the public input to verify that the constraint proof provides proof that the committed blockchain transaction satisfies the one or more constraints.
This limitation is directed towards data and functions of the constraint sub-script. The constraint sub-script is not created as part of the method, and its functions are not method steps. The constraint sub-script is code which already exists on the blockchain when the method is being performed. This limitation is therefore merely describing an intended environment of use. It does not describe a method step or limit the performance of any method step and is not given patentable weight.
Regarding claim 5
The method of claim 3, wherein the commitment sub- script comprises a commitment key, and wherein the commitment sub-script is configured to use the commitment key to verify that the transaction commitment corresponds to the first transaction or the funded first transaction.
This limitation is directed towards data and functions of the commitment sub-script. The commitment sub-script is not created as part of the method, and its functions are not method steps. The commitment sub-script is code which already exists on the blockchain when the method is being performed. This limitation is therefore merely describing an intended environment of use. It does not describe a method step or limit the performance of any method step and is not given patentable weight.
Regarding claim 6
The method of claim 3, wherein the commitment sub-script is configured to supply the transaction commitment proof to the constraint sub-script, and wherein the constraint sub-script is configured to use the verification key, the public input and the transaction commitment to verify that the constraint proof provides proof that the first transaction or the funded first transaction satisfies the one or more constraints.
This limitation is directed towards data and functions of the commitment sub-script and the constraint sub-script. The commitment sub-script and the constraint sub-script are not created as part of the method, and their functions are not method steps. The commitment sub-script and the constraint sub-script are code which already exists on the blockchain when the method is being performed. This limitation is therefore merely describing an intended environment of use. It does not describe a method step or limit the performance of any method step and is not given patentable weight.
Regarding claim 7
Franco teaches:
The method of claim 3, wherein the constraint sub-script is configured to use the verification key to verify that the constraint proof has been generated using an evaluation key corresponding to the verification key, and
This limitation is directed towards data and functions of the constraint sub-script. The constraint sub-script is not created as part of the method, and its functions are not method steps. The constraint sub-script is code which already exists on the blockchain when the method is being performed. This limitation is therefore merely describing an intended environment of use. It does not describe a method step or limit the performance of any method step and is not given patentable weight.
wherein the method comprises generating the constraint proof based on the evaluation key. {Page 184 “The transaction has to be signed by the two parties before it is published in the blockchain.”}
Regarding claim 8
The method of claim 3, wherein the constraint sub-script comprises a non-interactive zero-knowledge verification algorithm configured to verify that the constraint proof has been generated for satisfying a particular program, and
This limitation is directed towards data and functions of the constraint sub-script. The constraint sub-script is not created as part of the method, and its functions are not method steps. The constraint sub-script is code which already exists on the blockchain when the method is being performed. This limitation is therefore merely describing an intended environment of use. It does not describe a method step or limit the performance of any method step and is not given patentable weight.
wherein the method comprises generating the constraint proof for satisfying the particular program.
“Particular program” is interpreted as a generic label for the constraints imposed by the constraint sub-script. This limitation therefore does not add any limitation beyond what is already in claim 3.
Regarding claim 9
Franco teaches:
The method of claim 3, wherein the transaction commitment comprises a digital signature,
and wherein the method comprises generating a digital signature based on the first transaction or the funded first transaction. {Page 184 “The transaction has to be signed by the two parties before it is published in the blockchain.”}
wherein the commitment key comprises a public key, and wherein the commitment sub-script is configured to verify that the digital signature signs a message based on the first transaction or the funded first transaction,
This limitation is directed towards data and functions of the commitment sub-script. The commitment sub-script is not created as part of the method, and its functions are not method steps. The commitment sub-script is code which already exists on the blockchain when the method is being performed. This limitation is therefore merely describing an intended environment of use. It does not describe a method step or limit the performance of any method step and is not given patentable weight.
Regarding claim 10
Franco teaches:
The method of claim 9, wherein the public key corresponds to a private key set equal to one. {Page 70 “It is crucial that the private key d is generated by a good random number generator.”}
Since Franco teaches a randomly generated private key, it teaches performing the method with any particular key value.
Regarding claim 11
The method of claim 3, wherein at least one of the one or more constraints is that the committed blockchain transaction comprises an input that references the token issuance transaction or that the committed blockchain transaction references a transaction that forms part of a chain of one or more transactions linking to the token issuance transaction.
This limitation is directed towards data and functions of the constraint sub-script. The constraint sub-script is not created as part of the method, and its functions are not method steps. The constraint sub-script is code which already exists on the blockchain when the method is being performed. This limitation is therefore merely describing an intended environment of use. It does not describe a method step or limit the performance of any method step and is not given patentable weight.
Regarding claim 12
The method of claim 3, wherein at least one of the one or more constraints is that a transaction referenced by an input of the committed blockchain transaction comprises a valid constraint proof linking the transaction to the token issuance transaction, or that the transaction is the token issuance transaction.
This limitation is directed towards data and functions of the constraint sub-script. The constraint sub-script is not created as part of the method, and its functions are not method steps. The constraint sub-script is code which already exists on the blockchain when the method is being performed. This limitation is therefore merely describing an intended environment of use. It does not describe a method step or limit the performance of any method step and is not given patentable weight.
Regarding claim 13
The method of claim 3, wherein the enforcement locking script comprises a transfer sub-script, wherein the transfer sub-script comprises a target public key or a hash thereof, wherein the transfer sub-script is configured to verify that the unlocking script of the first input comprises a signature corresponding to the first public key of the sending party.
This limitation is directed towards data and functions of the enforcement locking script. The enforcement locking script is not created as part of the method, and its functions are not method steps. The enforcement locking script is code which already exists on the blockchain when the method is being performed. This limitation is therefore merely describing an intended environment of use. It does not describe a method step or limit the performance of any method step and is not given patentable weight.
Regarding claim 14
Franco does not teach, however Trock teaches:
The method of claim 3, comprising including the enforcement locking script in the first output of the first blockchain transaction. {[0004] “the method comprising: identifying an input of a transaction; identifying a locking script associated with an output of a previous transaction that is referenced by the input, wherein the locking script comprises a persisting smart contract [constraint sub-script] that is arranged to persist through multiple transactions on the blockchain; and outputting a transmission to the second node in dependence on: the persisting smart contract being present in a locking script of an output [first output] of the transaction [first blockchain transaction]; and/or a redemption condition [constraints] of the persisting smart contract being satisfied; wherein the persisting smart contract comprises a token identifier; and wherein the token identifier is associated with a contract transaction, which contract transaction is associated with the persisting smart contract, wherein the contract transaction defines the redemption condition.”}
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to include the persisting smart contract of Trock in the asset transfer transaction of Franco for the reasons given above with respect to claim 3.
Regarding claim 15
Franco does not teach, however Trock teaches:
The method of claim 3, wherein at least one of the one or more constraints is that the committed blockchain transaction comprises some or all of the enforcement locking script. {[0004] “the method comprising: identifying an input of a transaction; identifying a locking script associated with an output of a previous transaction that is referenced by the input, wherein the locking script comprises a persisting smart contract [constraint sub-script] that is arranged to persist through multiple transactions on the blockchain; and outputting a transmission to the second node in dependence [constraint] on: the persisting smart contract being present in a locking script of an output of the transaction [committed blockchain transaction]; and/or a redemption condition of the persisting smart contract being satisfied; wherein the persisting smart contract comprises a token identifier; and wherein the token identifier is associated with a contract transaction, which contract transaction is associated with the persisting smart contract, wherein the contract transaction defines the redemption condition.”}
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to include the persisting smart contract of Trock in the asset transfer transaction of Franco for the reasons given above with respect to claim 3.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure and is listed in the enclosed PTO-892.
Brown (US 20200349532 A1) teaches an atomic swap:
[0107] “A Transaction may consume and produce multiple state objects of multiple types, as illustrated in FIG. 11, which shows an exchange, where two input states objects, 1105 and 1107, are consumed, and two output states objects, 1110 and 1112, are created, inside a single atomic transaction 1100. The business purpose of this transaction is to atomically pay an importer and endorse the associated bill of lading. States objects created as a result of one Transaction will ultimately be consumed in another, in an ongoing chain of transactions. So long as the input transaction is verified and validated, the parties to subsequent transactions need not perform any further diligence or trust activity to execute the transaction with a high degree of certainty and low risk.”
Guo (US 20210027289 A1) teaches an atomic swap:
[0115] “When recording the transaction information in a new block, the target node may record a transaction record corresponding to the transaction information shown in FIG. 9 in the new block, specifically, in the same transaction of the new block. The transaction includes the first transaction record and the second transaction record, and includes two inputs and two outputs. In a case that the user A exchanges 100 bitcoins for 50 ethers of the user B, the input source, the asset type, an asset quantity, and a proof of expense of the 100 bitcoins of the user A form the transaction input (the first input item) (the transaction input may alternatively not include the asset type and the asset quantity) of the first transaction record; and an outputted item number, an output account address, the asset type, the asset quantity, and an expense condition of the bitcoins of the user A form the transaction output (the first output item) of the first transaction record. Composition of the second transaction record is similar to that of the first transaction record. Therefore, details of the second transaction are not described herein again for the sake of brevity.”
Trock (US 20230291561 A1) teaches an atomic swap:
PNG
media_image2.png
213
417
media_image2.png
Greyscale
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SCOTT MICHAEL DIROMA whose telephone number is (571)272-6430. The examiner can normally be reached Monday - Friday 12:30 pm - 8:30 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Patrick McAtee can be reached on (571) 272-7575. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/S.M.D./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698
Prosecution Insights