DETAILED ACTION
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant’s submission filed on June 11, 2025 has been entered.
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 .
Acknowledgements
This Office Action is in response to Applicant’s submission filed on June 11, 2025 which included, inter alia, claim amendments (“June 2025 Claims”) and “REMARKS” (“June 2025 Remarks”).
Claims 1-20 are currently pending and have been examined.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-4, 6-12, 14-18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over “Mastering Bitcoin – Unlocking Digital Crypto-Currencies” by Antonopoulos (“Antonopoulous”) in view of Sheng et al. (US 2017/0228731 A1)(“Sheng”).
As to Claim 1, Antonopoulous discloses a computer-implemented method, comprising:
determining an unlocking transaction constraint (e.g.: “the unlocking script is called scriptSig, because it usually contained a digital signature. In this book we refer to it as an ‘unlocking script’” page 123, “An unlocking script is a script that ‘solves’, or satisfies, the conditions placed on an output by a locking script and allows the output to be spent.” page 123, “A locking script, also known as an ‘encumbrance’ that ‘locks’ this amount by specifying the conditions that must be met to spend the output” page 116; as such the condition(s) of the locking script, amount to unlocking transaction constraint(s)) that constrains an unlocking script (“An unlocking script is a script that ‘solves’, or satisfies, the conditions placed on an output by a locking script and allows the output to be spent.” page 123) of an input (“UTXO,” “The fundamental building block of a bitcoin transaction is an unspent transaction output or UTXO” Page 114, “The UTXO consumed by a transaction are called transaction inputs, while the UTXO created by a transaction are called transaction outputs” Page 115) of an unlocking transaction to include a serialized set of transaction fields of the unlocking transaction (e.g.: “<sig><PubK>” see unlocking script in Figure 5-1 on page 124, where <sig><PubK> is a serialized set of transaction fields, “In most cases the locking script will lock the output to a specific bitcoin address, thereby transferring ownership of that amount to the new owner. When Alice paid Bob’s Cafe for a cup of coffee, her transaction created a 0.0 l5 bitcoin output encumbered or locked to the Cafe's bitcoin address. That 0.015 bitcoin output was recorded on the blockchain and became part of the Unspent Transaction Output set, meaning it showed in Bob's wallet as part of the available balance. When Bob chooses to spend that amount, his transaction will release the encumbrance, unlocking the output by providing an unlocking script containing a signature from Bob’s private key.” page 117), the set of transaction fields comprising at least part of the input of the unlocking transaction (“For each input in the transaction, the validation software will first retrieve the UTXO referenced by the input. That UTXO contains a locking script defining the conditions required to spend it.” Page 124), the constraint including (1) a first reference (<PubK>) of the input of the unlocking transaction (e.g.: “<sig><PubK>” see unlocking script in Figure 5-1 on page 124) or (2) parts of a previous transaction pointed to by the first reference;
creating a redeemable transaction (“Once a transaction has been created, it is signed by the owner (or owners) of the source funds. If it was properly formed and signed, the signed transaction is now valid and contains all the information needed to execute the transfer of funds.” page 112, “A transaction is a data structure that encodes a transfer of value from a source of funds, called an input, to a destination, called an output.” page 113) that includes:
a transaction output that includes a redeemable amount (“Transaction outputs consists of two parts: An amount…,” page 116); and
a transaction locking script (“Transaction outputs consists of two parts:… A locking script…,” page 116) that includes the unlocking transaction constraint (“Transaction outputs associate a specific amount (in satoshis) to a specific encumbrance or locking-script that defines the condition that must be met to spend that amount. In most cases the locking script will lock the output to a specific bitcoin address, thereby transferring ownership of that amount to the new owner,” page 117, “transaction will release the encumbrance, unlocking the output by providing an unlocking script containing a signature from Bob's private key.” page 117), wherein unlocking the redeemable amount is contingent upon execution of at least one unlocking script (“If the result of executing the locking script with the stack data copied from the unlocking script is ‘TRUE’, the unlocking script has succeeded in resolving the conditions imposed by the locking script and therefore the input is a valid authorization to spend the UTXO” “Only a valid transaction that correctly satisfies the conditions of the UTXO results in the UTXO being marked as ‘spent’ and removed from the set of available (unspent) UTXO.” page 124) of the unlocking transaction, the unlocking script leaving the serialized set of transaction fields of the unlocking transaction left on a stack (“First, the unlocking script is executed, using the stack execution engine. If the unlocking script executed ·without errors (e.g it has no “dangling” operators leftover), the main stack (not the alternate stack) is copied and the locking script is executed. If the result of executing the locking script with the stack data copied from the unlocking script is “TRUE”, the unlocking script has succeeded in resolving the conditions imposed by the locking script and therefore the input is a valid authorization to spend the UTXO.” Page 124, “Bitcoin’s scripting language is called a stack-based language because it uses a data structure called a stack. A stack is a very simple data structure, which can be visualized as a stack of cards. A stack allows two operations: push and pop. Push adds an item on top of the stack. Pop removes the top item from the stack.” “The scripting language executes the script by processing each item from left to right. Numbers (data constants) are pushed onto the stack. Operators push or pop one or more parameters from the stack, act on them, and may push a result onto the stack” page 125, for example, see Fig 5-3, Page 130 and Fig.5-4, Page 131), satisfying the unlocking transaction constraint (“Once the UTXO is selected, the wallet then produces unlocking scripts containing signatures for each of the UTXO, thereby making them spendable by satisfying their locking script conditions. The wallet adds these UTXO references and unlocking scripts as inputs to the transaction.” page 119, “An unlocking script is a script that ‘solves’, or satisfies, the conditions placed on an output by a locking script and allows the output to be spent. Unlocking scripts are part of every transaction input and most of the time they contain a digital signature produced by the user's wallet from their private key.” page 123), wherein the execution includes:
from the input included in the serialized set of transaction fields of the unlocking transaction left on the stack, a second reference (“public key hash,” Page 124), to a previous transaction’s output (once input on the stack, “public key hash,” is calculated and extracted and transferred to the locking script: “the scripts are executed separately with the stack transferred between the two executions,” Page 124, these two executions are referring to the unlocking script and the locking script, “Lock Script…is found in a transaction output” page 124, Fig. 5-1, which includes PubKHash); and
based on the locking script of the redeemable transaction’s output, causing a determination of the constraint (“Any combination of locking and unlocking scripts that results in a TRUE value is valid.” Page 127, “Transaction outputs associate a specific amount (in satoshis) to a specific encumbrance or locking-script that defines the condition that must be met to spend that amount.” Page 117); and
causing the redeemable transaction to be validated at a node of a blockchain network (“Once a bitcoin transaction is sent to any node connected to the bitcoin network, the transaction will be validated by that node.” page 113).
Antonopoulous does not directly disclose extracting, from the input included in the serialized set of transaction fields of the unlocking transaction left on the stack, a second reference to a previous transaction’s output.
Sheng teaches extracting, from the input (OP_RETURN opcode) included in the serialized set of transaction fields (“Through the scripting system, the sender can create very complex conditions that people have to meet in order to claim the output’s value. For example, it’s possible to create an output that can be claimed by anyone without any authorization. It's also possible to require that an input be signed by ten different keys, or be redeemable with a password instead of a key.” [0119], “…using OP Return codes or the like. Such field can place bits of information into the transaction’s scriptSig value so that the irreversibility of the blockchain can be used to make that information verifiable at later times. OP RETURN is a valid opcode to be used in a bitcoin transaction, which allows 80 arbitrary bytes to be used in an unspendable transaction.” [0148], “An exemplary transaction which has an OP RETURN in its scriptSig, the hash of which may be for example, a text string…” [0149]) of the unlocking transaction left on the stack (“The input's scriptSig and the referenced output's scriptPubKey are evaluated in that order, with scriptPubKey using the values left on the stack by scriptSig.” [0119]), a second reference to a previous transaction’s output (“An exemplary transaction which has an OP RETURN in its scriptSig, the hash of which may be for example, a text string…” [0149], “The OP_RETURN code above is represented by the hex value 0x6a. This first byte is followed by a byte that represents the length of the rest of the bytes in the script PubKey. In this case, the hex value is 0x13, which means there are 19 more bytes. These bytes comprise the arbitrary less-than-80 bytes one may be allowed to send in a transaction marked by the OP RETURN opcode.” [0152]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Antonopoulous by the feature of Sheng and in particular to include in Antonopoulous’s input of the ScriptSig fields of the unlocking transaction, the OP_RETURN opcode of Sheng, “so that the irreversibility of the blockchain can be used to make that information verifiable at later times. OP RETURN is a valid opcode to be used in a bitcoin transaction, which allows 80 arbitrary bytes to be used in an unspendable transaction.” (Sheng, [0148]), and to include in Antonopoulous, the feature of extracting, from the input included in the serialized set of transaction fields of the unlocking transaction left on the stack, a second reference to a previous transaction’s output, as taught by Sheng, because it would increase the security of the transaction by making verification more complex.
As to Claim 2, Antonopoulous further discloses wherein the unlocking transaction constraint further constrains the input of the unlocking transaction to include a particular hash value (“These contain a locking script that encumbers the output with a public key hash, more commonly known as a bitcoin address. Transactions that pay a bitcoin address contain P2PKH scripts. An output locked by a P2PKH script can be unlocked (spent) by presenting a public key and a digital signature created by the corresponding private key.” page 128, “When executed, this combined script, will evaluate to TRUE if, and only if, the unlocking script matches the conditions set by the locking script. In other words, the result will be TRUE if the unlocking script has a valid signature from the Cafe’s private key which corresponds to the public key hash set as an encumbrance.” page 129).
As to Claim 3, Antonopoulous further discloses wherein the particular hash value encodes an identifier that references the previous transaction output (“Transactions consume UTXO unlocking it with the signature of the current owner and create UTXO locking it to the bitcoin address of the new owner.” page 115, “These contain a locking script that encumbers the output with a public key hash, more commonly known as a bitcoin address.” page 129).
As to Claim 4, Antonopoulous further discloses wherein the unlocking transaction constraint further constrains the input of the unlocking transaction to include a locking script that includes a set of script elements duplicated from the transaction locking script (“That transaction output would have a locking script of the form:” Page 128, “OP _ DUP OP_ HASH160 <Cafe Public Key Hash> OP_EQUAL OP_CHECKSIG” Page 129, “When executed, this combined script, will evaluate to TRUE if, and only if, the unlocking script matches the conditions set by the locking script. In other words, the result will be TRUE if the unlocking script has a valid signature from the Cafe’s private key which corresponds to the public key hash set as an encumbrance.” page 129, “OP_Dup…Duplicate the top item in the stack” Page 256).
As to Claim 6, Antonopoulous further discloses comprising determining a redeemable value for an output of the unlocking transaction (Table 5-2, “structure of a transaction output…Bitcoin value in Satoshies,” page 116, “Transaction outputs associate a specific amount (in satoshis) to a specific encumbrance or locking-script that defines the condition that must be met to spend that amount. In most cases the locking script will lock the output to a specific bitcoin address, thereby transferring ownership of that amount to the new owner,” page 117).
As to Claim 7, Antonopoulous further discloses wherein: the unlocking transaction constraint includes a particular locking script element from the previous transaction output (“Every bitcoin transaction creates outputs, which are recorded on the bitcoin ledger. Almost all of these outputs, with one exception…create spendable chunks of bitcoin called unspent transaction outputs or UTXO, which are then recognized by the whole network and available for the owner to spend in a future transaction. Sending someone bitcoin is creating an unspent transaction output (UTXO) registered to their address and available for them to spend.” page 115, “UTXO are tracked by every full node bitcoin client in a database held in memory, called the UJXO set or UTXO pool. New transactions consume (spend) one or more of these outputs from the UTXO set” page 116); and as a result of the input of the unlocking transaction including the particular locking script element, the execution of the at least one unlocking script satisfies the unlocking transaction constraint (“These contain a locking script that encumbers the output with a public key hash, more commonly known as a bitcoin address. Transactions that pay a bitcoin address contain P2PKH scripts. An output locked by a P2PKH script can be unlocked (spent) by presenting a public key and a digital signature created by the corresponding private key.” page 128, “When executed, this combined script, will evaluate to TRUE if, and only if, the unlocking script matches the conditions set by the locking script. In other words, the result will be TRUE if the unlocking script has a valid signature from the Cafe’s private key which corresponds to the public key hash set as an encumbrance.” page 129).
As to Claim 8, Antonopoulous further discloses wherein the particular locking script element encodes a cryptographic key of a particular entity (“valid signature from the Cafe’s private key,” page 129; it is known that a digital signature encrypts the information it signs).
As to Claim 9, Antonopoulous further discloses wherein: the unlocking transaction constraint is a first unlocking transaction constraint (“The unlocking script is usually a signature proving ownership of the bitcoin address that is in the locking script.” page 117); and the method further comprises: determining a second unlocking transaction constraint to further constrain the unlocking transaction (“UTXO are tracked by every full node bitcoin client in a database held in memory, called the UTXO set or UTXO pool. New transactions consume (spend) one or more of these outputs from the UTXO set” page 116; “The unlocking script is usually a signature proving ownership of the bitcoin address that is in the locking script.” page 117; note: a second new transaction depending on the bitcoin address of the first redeemable transaction would have a corresponding unlocking and locking script); and creating a second redeemable transaction that includes: a second amount (“Transaction outputs consists of two parts:… amount…,” page 116); and a second locking script (“Transaction outputs consists of two parts:… A locking script…,” page 116) that includes the second unlocking transaction constraint, wherein unlocking the second amount is further contingent upon execution of the at least one unlocking script satisfying the second unlocking transaction constraint (“UTXO are tracked by every full node bitcoin client in a database held in memory, called the UTXO set or UTXO pool. New transactions consume (spend) one or more of these outputs from the UTXO set” page 116; “The unlocking script is usually a signature proving ownership of the bitcoin address that is in the locking script.” page 117; note: a second new transaction using the bitcoin address of the first redeemable transaction would satisfy the corresponding unlocking and locking of the second new transaction).
As to Claim 10, Antonopoulous further discloses wherein: the locking script is a first locking script (“Transaction outputs consists of two parts:… A locking script…,” page 116); the at least one unlocking script includes a first unlocking script and a second unlocking script (“Once the UTXO is selected, the wallet then produces unlocking scripts containing signatures for each of the UTXO, thereby making them spendable by satisfying their locking script conditions. The wallet adds these UTXO references and unlocking scripts as inputs to the transaction.” page 119; note: as such each signature for each UTXO constitutes a separate script); the first unlocking transaction constraint constrains the first unlocking script to include at least a portion of the first locking script (“Unlocking-Script A script that fulfills the conditions of the UTXO locking-script” Table 5-3, page 119, “The unlocking script is usually a signature proving ownership of the bitcoin address that is in the locking script.” page 117); and the second unlocking transaction constraint constrains the second unlocking script to include at least a portion of the second locking script (“Unlocking-Script A script that fulfills the conditions of the UTXO locking-script” Table 5-3, page 119, “The unlocking script is usually a signature proving ownership of the bitcoin address that is in the locking script.” page 117).
As to Claim 11, Antonopoulous further discloses: the at least a portion of the first locking script includes a cryptographic key associated with a first entity (“valid signature from the Cafe’s private key,” page 129; “An unlocking script is a script that ‘solves’, or satisfies, the conditions placed on an output by a locking script and allows the output to be spent. Unlocking scripts are part of every transaction input and most of the time they contain a digital signature produced by the user's wallet from their private key.” page 123); and and the at least a portion of the second locking script includes a cryptographic key associated with a second entity different from the first entity (“Bitcoin addresses that begin with the number "3" are pay-to-script-hash (P2SH) addresses, sometimes erroneously called multi-signature or multi-sig addresses. They designate the beneficiary of a bitcoin transaction as the hash of a script, instead of the owner of a public key.” page 99, “When a transaction attempting to spend the UTXO is presented later, it must contain the script that matches the hash, in addition to the unlocking script” page 135).
As to Claim 12, Antonopoulous further discloses wherein the unlocking transaction constraint further constrains the input of the unlocking transaction to constrain an output of the unlocking transaction (“An unlocking script is a script that ‘solves’, or satisfies, the conditions placed on an output by a locking script and allows the output to be spent. Unlocking scripts are part of every transaction input and most of the time they contain a digital signature produced by the user's wallet from their private key.” page 123).
As to Claim 14, Antonopoulous further discloses a system, comprising: a processor; and memory including executable instructions that, as a result of execution by the processor, causes the system to perform the computer-implemented method according to claim 1 (“Bitcoin is structured as a peer-to-peer network architecture on top of the Internet. The term peer-to-peer or P2P means that the computers that participate in the network are peers to each other” page 139; note: processor and memory are necessarily resident in the computers of the Bitcoin network that execute the method).
As to Claim 15, Antonopoulous further discloses a non-transitory computer-readable storage medium having stored thereon executable instructions that, as a result of being executed by a processor of a computer system, cause the computer system to at least perform the computer-implemented method of claim 1 (“Bitcoin is structured as a peer-to-peer network architecture on top of the Internet. The term peer-to-peer or P2P means that the computers that participate in the network are peers to each other” page 139; note: processor and memory are necessarily resident in the computers of the Bitcoin network that execute the method).
As to Claim 16, Antonopoulous further discloses a system, comprising: a processor; and memory including executable instructions that, as a result of execution by the processor, causes the system to perform the computer-implemented method according to claim 2 (“Bitcoin is structured as a peer-to-peer network architecture on top of the Internet. The term peer-to-peer or P2P means that the computers that participate in the network are peers to each other” page 139; note: processor and memory are necessarily resident in the computers of the Bitcoin network that execute the method).
As to Claim 17, Antonopoulous further discloses a system, comprising: a processor; and memory including executable instructions that, as a result of execution by the processor, causes the system to perform the computer-implemented method according to claim 3 (“Bitcoin is structured as a peer-to-peer network architecture on top of the Internet. The term peer-to-peer or P2P means that the computers that participate in the network are peers to each other” page 139; note: processor and memory are necessarily resident in the computers of the Bitcoin network that execute the method).
As to Claim 18, Antonopoulous further discloses a system, comprising: a processor; and memory including executable instructions that, as a result of execution by the processor, causes the system to perform the computer-implemented method according to claim 4 (“Bitcoin is structured as a peer-to-peer network architecture on top of the Internet. The term peer-to-peer or P2P means that the computers that participate in the network are peers to each other” page 139; note: processor and memory are necessarily resident in the computers of the Bitcoin network that execute the method).
As to Claim 20, Antonopoulous further discloses a system, comprising: a processor; and memory including executable instructions that, as a result of execution by the processor, causes the system to perform the computer-implemented method according to claim 6 (“Bitcoin is structured as a peer-to-peer network architecture on top of the Internet. The term peer-to-peer or P2P means that the computers that participate in the network are peers to each other” page 139; note: processor and memory are necessarily resident in the computers of the Bitcoin network that execute the method).
Claims 5 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Antonopoulous in view of Sheng, and further in view of Antonopoulous in a second embodiment.
As to Claim 5, the Antonopoulous/Sheng combination discloses as discussed above.
Antonopoulous further discloses wherein the redeemable transaction encodes a contract having a plurality of states (“Ethereum's blockchain records contracts, which are expressed in a low-level, byte-code like, Turing-complete language. Essentially, a contract is a program that runs on every node in the Ethereum system. Ethereum contracts can store data, send and receive ether payments, store ether and execute an infinite range (hence Turing-complete) of computable actions, acting as de-centralized autonomous software agents.” page 233; “Alt-chains are alternative implementations of the blockchain design pattern, which are not primarily used as currency. Many include a currency, but the currency is used as a token for allocating something else, such as a resource or a contract” page 230; note: contracts have different functionalities which amount to different states).
However, Antonopoulous does not directly disclose that the contract is encoded in Bitcoin.
It is noted that as discussed in Antonopoulous, “Alt-chains use the same basic building blocks and sometimes also use a currency or token as a payment mechanism, but their primary purpose is not currency. We will look at Namecoin, Ethereum, and NXT as examples of altchains.” Page 220.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bitcoin as in Antonopoulous in the Antonopoulous/Sheng combination by the features of Ethereum in Antonopoulous, and in particular to include a contract as used in Ethereum as taught in Antonopoulous, in the transaction code of the Bitcoin of Claim 1, as taught in Antonopoulous.
A person having ordinary skill in the art would have been motivated to combine these features because it would confer additional usages such as conditions on the spending desired by the consumers.
As to Claim 19, Antonopoulous discloses as discussed above and further discloses a system, comprising: a processor; and memory including executable instructions that, as a result of execution by the processor, causes the system to perform the computer-implemented method according to claim 5 (“Bitcoin is structured as a peer-to-peer network architecture on top of the Internet. The term peer-to-peer or P2P means that the computers that participate in the network are peers to each other” page 139; note: processor and memory are necessarily resident in the computers of the Bitcoin network that execute the method).
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Antonopoulous in view of Sheng, in view of Antonopoulous in a second embodiment, and further in view of Hunn et al. (US 2017/0287090 A1)(“Hunn”).
As to Claim 13, the Antonopoulous/Sheng/Antonopoulous in a second embodiment combination discloses as discussed above.
Antonopoulous does not directly disclose wherein: the unlocking transaction constraints encodes another contract distinct from the contract; and unlocking the redeemable amount is contingent upon the other contract being implemented in the output of the unlocking transaction.
Hunn teaches unlocking transaction constraints encodes another contract distinct from the contract (“contracting parties may cryptographically sign updates through contract state updates. A contract state update can act as messages sent to programmable clauses and that act as function calls to perform actions” [0109], “These update the corresponding versioned contract data stored on the State Transitioning System as described herein. This may be used for transactions between contracts…The contracting parties (or any other third party permitted to do so) then submit the state back to the BDL, which unlocks the state again (usually in a different configuration than it started with)” [0109], wherein an updated contract is a distinct contract from the original and is the “other contract”); and unlocking the redeemable amount is contingent upon the other contract being implemented in the output of the unlocking transaction (“For example, a complex event processing system may run through contract rules, select the rules for which an external event condition is true, and then evaluate and undertake the corresponding contract actions or operations, such as payment or release of liability” [0061]; wherein payment necessitates an amount).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the Antonopoulous/Sheng/Antonopoulous in a second embodiment combination by the features of Hunn and in particular to include in the Antonopoulous/Sheng/Antonopoulous in a second embodiment combination, the features of unlocking transaction constraints encodes another contract distinct from the contract; and unlocking the redeemable amount is contingent upon the other contract being implemented in the output of the unlocking transaction, as taught by Hunn.
A person having ordinary skill in the art would have been motivated to combine these features because “This may lead to privacy benefits, reduced complexity, improved scaling, and other related benefits. A further potential benefit is that dynamic aspects of data-driven contracts when using/interfacing with "smart contract scripts" on BDLs may also mitigate issues of immutability that may lead to rigidity (i.e., once a BDL script is executed on a BDL it is typically difficult or burdensome to amend.” (Hunn, [0050]).
Response to Arguments
The arguments filed in the June 2025 Remarks have been fully considered and addressed below.
On pages 7-8 of the June 2025 Remarks, Applicant argues that Antonopoulos does not teach leaving a serialized set of transaction fields on the stack. The Examiner respectfully disagrees. Antonopoulos teaches the unlocking script leaving serialized set of transaction fields of the unlocking transaction left on a stack (“First, the unlocking script is executed, using the stack execution engine. If the unlocking script executed without errors (e.g it has no “dangling” operators leftover), the main stack (not the alternate stack) is copied and the locking script is executed. If the result of executing the locking script with the stack data copied from the unlocking script is “TRUE”, the unlocking script has succeeded in resolving the conditions imposed by the locking script and therefore the input is a valid authorization to spend the UTXO.” Page 124, “Bitcoin’s scripting language is called a stack-based language because it uses a data structure called a stack. A stack is a very simple data structure, which can be visualized as a stack of cards. A stack allows two operations: push and pop. Push adds an item on top of the stack. Pop removes the top item from the stack.” “The scripting language executes the script by processing each item from left to right. Numbers (data constants) are pushed onto the stack. Operators push or pop one or more parameters from the stack, act on them, and may push a result onto the stack” page 125, for example, see Fig 5-3, Page 130 and Fig.5-4, Page 131).
Next, Applicant argues the “extracting” limitation of the claim. However, the argument is now moot since Sheng is relied upon to teach that feature.
The remainder of the arguments rest and fall on the previous arguments. As such, the Examiner finds these arguments unpersuasive for the same reasons given above.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MONICA A MANDEL whose telephone number is (571)270-7046. The examiner can normally be reached Monday and Thursday 10:00 AM-6:00 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, Ilana Spar can be reached at (571) 270-7537. 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.
/M.A.M/Examiner, Art Unit 3622
/ILANA L SPAR/Supervisory Patent Examiner, Art Unit 3622
Prosecution Insights