DETAILED ACTION
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 .
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 05/19/2026 has been entered.
The following is a non-final office action in response to the request for continued examination of 05/19/2026.
Status of Claims
Claims 1-15, as originally filed 04/20/2026, are pending and have been examined on the merits (claims 1, 14, and 15 being independent). Claims 1, 8, and 14-15 have been amended.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 04/17/2026 and 08/12/2026 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Response to Arguments
Applicant’s arguments and amendments filed 04/20/2026 have been fully considered but they are not persuasive.
With regard to the rejections of the claims under 35 USC 103, Applicant’s arguments and amendments have been considered but are moot as a new ground of rejection has been added and Examiner respectfully disagrees. Examiner notes that Applicant is arguing newly amended claim language. Further as noted in the citation above the prior art and the amendments are addressed by the rejections cited under 35 USC 103.
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 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.
In the rejections below, where claims are currently amended, this is indicated by underlining.
Claims 1-7 and 13-15 are rejected under 35 U.S.C. 103 as being unpatentable over Carver et al. (hereinafter Carver), US Publication Number 2019/0199516 A1 in view of Davies et al (hereinafter Davies), US Publication Number 2023/0115569 A1 in further view of Wright et al. (hereinafter Wright), WO 2020/165676 A1 (International Publication Date: 08/20/2020).
Regarding claim 1:
Carver discloses the following:
A computer-implemented method for distributing validation of a blockchain block comprising a plurality of blockchain transactions and a root of a Merkle tree for the block across a plurality of computing resources that are operative to perform blockchain related validation tasks, the method comprising the steps: (Carver: See paragraphs [0035] discloses “A blockchain is a continuously growing list of records, called blocks, that are linked and secured using cryptography. Each block in a blockchain typically contains a cryptographic hash linking to the previous block, and transaction data. For use as a distributed ledger, a blockchain is typically managed by a peer-to-peer network collectively adhering to a protocol for inter-node communication and validating new blocks.”; and [0051] discloses “Once a mined segment is finished, message 504 is sent from the element responsible for that segment to the element responsible for the block header. The message includes, among other things, the Merkle root of the generated segment. Once all messages 504 are sent and received, the element responsible for the block header creates the top of the block Merkle tree and saves the Merkle root in the header.”)
segmenting, by a controller, the plurality of blockchain transactions into a plurality of subsets of blockchain transactions, wherein each respective subset of blockchain transactions is represented by a respective inner portion of the Merkle tree for the blockchain block, and wherein: (Carver: See paragraphs [0041] discloses “Referring to FIG. 2, a block 200 is segmented by transaction id (Tx,) into some number of segments 202a-n, where n=l000, and a header 204. The segments 202 and header 204 represent a block of the blockchain although they may be (and often are) processed, transmitted and stored separately. The number of segments 202, shown in FIG. 2 as 1000, may be more or fewer in number and may change over time or dynamically.”; and [0076] discloses “Each segment handler, in turn, persists its set of segments associated with the block, and it instructs its associated transaction handlers to finalize the block. In so doing, the segment handlers generate and provide to the transaction handlers the portion of the block's overall Merkle tree each transaction handler needs for its set of segments.”)
all transactions in the respective subset of blockchain transactions share the same respective inner node; (Carver: See paragraph [0042] discloses “block segmentation typically is an externally visible attribute shared by all nodes of the network. As will be seen, organizing the block data by segment significantly improves the performance and efficiency of nodes exchanging block information.”)
iii) allocating, by the controller, a respective subset of blockchain transactions to the respective computing resource for validation of the respective subset of blockchain transactions to verify that they conform to a blockchain protocol; and (Carver: See paragraph [0061] discloses “a transaction handler that receives a raw transaction determines (from querying the UTXO handler) whether inputs to the transaction exists and, if so, what are their values and locking scripts (containing public keys sometimes referred to as addresses or wallet addresses). It checks each input's unlocking script (digital signature), and if all signatures are valid, the transaction handler commits (saves) the raw transaction to its associated memory pool. In this manner, validated raw transactions accumulate in each handler's mem pool. Thus, in each transaction handler's mem pool there are a collection of transactions in effect "waiting" to be mined (i.e., assigned) to a block segment (and thus a block) in the blockchain.”, and see also [0058])
Carver does not explicitly disclose the following, however Davies further teaches:
the respective inner portion of the Merkle tree for the blockchain block is represented by a respective inner node of the Merkle Tree for the blockchain block; (Davies: See paragraph [0090] discloses “a hash tree is a tree-like data structure comprising "internal" nodes and "leaf' nodes connected by a set of directional edges. Each leaf node represents the cryptographic hash of a portion of data (data block) that is to be "stored" in the tree, and each node is generated by hashing the concatenation of its "children" (child nodes).”)
the respective inner node is a node in the Merkle tree for the blockchain block that is neither the root node of the Merkle tree for the blockchain block nor a leaf node; and (Davies: See paragraph [0090] discloses “a hash tree is a tree-like data structure comprising "internal" nodes and "leaf' nodes connected by a set of directional edges. Each leaf node represents the cryptographic hash of a portion of data (data block) that is to be "stored" in the tree, and each node is generated by hashing the concatenation of its "children" (child nodes). A child node of a "parent" node is any node directly connected to the parent node by a directional edge. The root node of the hash tree can be used to represent a large set of data compactly, and it can be used to prove that any one of the portions of data corresponding to a leaf node is indeed part of the set. The root node is a single node to which all other nodes are connected either directly or indirectly.”)
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the transaction handler commits (saves) the raw transaction to its associated memory pool with validated raw transactions that accumulate in each handler's mem pool (e.g., in each transaction handler's mem pool there are a collection of transactions in effect "waiting" to be mined (i.e., assigned) to a block segment (and thus a block) in the blockchain.) of Carver to include the internal nodes and leaf nodes connected by a set of directional edges. Each leaf node represents the cryptographic hash of a portion of data (data block) that is to be stored in the tree, and each node is generated by hashing the concatenation of its "children" (child nodes). A child node of a parent node is any node directly connected to the parent node by a directional edge (i.e. a tree data structure), as taught by Davies, in order to verify the set of transactions. (See Davies, [0003-0010])
Carver and Davies do not explicitly disclose the following, however Wright further teaches:
ii) generating, storing and/or maintaining, by a respective computing resource of the plurality of computing resources, a respective output repository for recording, searching and/or processing a respective plurality of unspent transaction outputs, each unspent transaction output associated with a transaction (Tx) in a respective subset of blockchain transactions; (Wright: See page 2, lines 10-19: discloses “In order for a transaction to be written to the blockchain, it must be "validated". Network nodes (miners) perform work to ensure that each transaction is valid, with invalid transactions rejected from the network. Software clients installed on the nodes perform this validation work on an unspent transaction (UTXO) by executing its locking and unlocking scripts. If execution of the locking and unlocking scripts evaluate to TRUE, the transaction is valid and the transaction is written to the blockchain. Thus, in order for a transaction to be written to the blockchain, it must be i) validated by the first node that receives the transaction - if the transaction is validated, the node relays it to the other nodes in the network; and ii) added to a new block built by a miner; and iii) mined, i.e. added to the public ledger of past transactions.”, and notes: for examination purposes, “and/or” will be interpreted as “or”.)
iv) recording, in the respective output repository by the respective computing resource, each unspent transaction output that is associated with a transaction (Tx) in the respective subset of blockchain transactions. (Wright: See page 2, lines 10-19: discloses “In order for a transaction to be written to the blockchain, it must be "validated". Network nodes (miners) perform work to ensure that each transaction is valid, with invalid transactions rejected from the network. Software clients installed on the nodes perform this validation work on an unspent transaction (UTXO) by executing its locking and unlocking scripts. If execution of the locking and unlocking scripts evaluate to TRUE, the transaction is valid and the transaction is written to the blockchain. Thus, in order for a transaction to be written to the blockchain, it must be i) validated by the first node that receives the transaction - if the transaction is validated, the node relays it to the other nodes in the network; and ii) added to a new block built by a miner; and iii) mined, i.e. added to the public ledger of past transactions.” )
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the transaction handler commits (saves) the raw transaction to its associated memory pool with validated raw transactions that accumulate in each handler's mem pool (e.g., in each transaction handler's mem pool there are a collection of transactions in effect "waiting" to be mined (i.e., assigned) to a block segment (and thus a block) in the blockchain.) of Carver to include the Merkle tree with that root to check (i.e. verify) whether a particular transaction was included in a particular block on the blockchain, without having to download the entire blockchain, as taught by Wright, in order to provide an efficient search for a certain transaction. (See Wright, page 3)
Regarding claim 2:
Carver and Davies do not explicitly disclose the following, however Wright further teaches:
The method according to claim 1, and comprising:
generating, storing and/or maintaining at least one further output repository. (Wright: See page 2, lines 23-26: discloses “Once stored in the blockchain as a UTXO, a user can transfer control of the associated cryptocurrency to another address associated with an input in another transaction. This is often done using a digital wallet which stores the public and private key pairs associated with the user's cryptocurrency.” and notes: for examination purposes, “and/or” will be interpreted as “or”.)
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the transaction handler commits (saves) the raw transaction to its associated memory pool with validated raw transactions that accumulate in each handler's mem pool (e.g., in each transaction handler's mem pool there are a collection of transactions in effect "waiting" to be mined (i.e., assigned) to a block segment (and thus a block) in the blockchain.) of Carver to include the Merkle tree with that root to check (i.e. verify) whether a particular transaction was included in a particular block on the blockchain, without having to download the entire blockchain, as taught by Wright, in order to provide an efficient search for a certain transaction. (See Wright, page 3)
Regarding claim 3:
Carver teaches the following:
The method according to claim 1, and further comprising:
creating and/or maintaining a database log that comprises a history of actions, changes and events relating to the output repository. (Carver: See paragraph [0088] discloses “Preferably, UTXOs are identified by an identifier (txid), which is a hash or digest of the originating transaction, and the index of the output in the originating transaction. A UTXO also has two other pieces of information (not used in its identification), namely, a value, and a "locking script." Generally, the locking script is a set of instructions or simply a public key associated with the output. Sometimes the public key is called an address or wallet address. The locking script (e.g., the public key) is conveyed in the output of a transaction along with the value, and typically it is stored in a UTXO database along with the UTXO identifying information and its value. Thus, a query to the UTXO handler during initial transaction validation returns both the value and the locking script (public key). To spend a UTXO as an input to a new transaction, the new transaction (essentially its outputs), must be signed by the private key cryptographically matching the public key of the UTXO to be spent.”, and see also [0089], notes: for examination purposes, “and/or” will be interpreted as “or”.)
Regarding claim 4:
Carver teaches the following:
The method according to claim 1, wherein: the first output repository and/or at least one further output repository comprises at least one record associated with:
i) an unspent transaction output; and/or (Carver: See paragraph [0088] discloses “Preferably, UTXOs are identified by an identifier (txid), which is a hash or digest of the originating transaction, and the index of the output in the originating transaction.”)
ii) an identifier that is associated with a) an unspent transaction output and/or b) a transaction (Tx) in the plurality of blockchain transactions. (Carver: See paragraph [0088] discloses “Preferably, UTXOs are identified by an identifier (txid), which is a hash or digest of the
Regarding claim 5:
Carver and Davies do not explicitly disclose the following, however Wright further teaches:
The method according to claim 4, wherein: the at least one record comprises a record identifier having:
a block identifier (block ID) associated with a blockchain block; and/or (Wright: See page 3, lines 1-7: discloses “The block header uniquely identifies the block so it can be located on the blockchain. It comprises fields of data that provide a unique summary or fingerprint of the entire block's contents. The block header includes the Merkle Root, which is a hash of all of the transactions in that block. A user is then able to search the Merkle tree with that root to check (i.e. verify) whether a particular transaction was included in a particular block on the blockchain, without having to download the entire blockchain.”, and notes: for examination purposes, “and/or” will be interpreted as “or”.)
ii) a transaction identifier (TxID) associated with a transaction (Tx) in the plurality of blockchain transactions. (Wright: See page 15, lines 3-7: discloses “Alice also communicates the transaction ID TxID3 of the payment transaction Tx3 to Bob”)
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the transaction handler commits (saves) the raw transaction to its associated memory pool with validated raw transactions that accumulate in each handler's mem pool (e.g., in each transaction handler's mem pool there are a collection of transactions in effect "waiting" to be mined (i.e., assigned) to a block segment (and thus a block) in the blockchain.) of Carver to include the Merkle tree with that root to check (i.e. verify) whether a particular transaction was included in a particular block on the blockchain, without having to download the entire blockchain, as taught by Wright, in order to provide an efficient search for a certain transaction. (See Wright, page 3)
Regarding claim 6:
Carver teaches the following:
The method according to claim 5, wherein:
the record identifier comprises a function of the block identifier (block ID) and the transaction identifier (TxID); and/or
ii) the record identifier comprises a concatenation of the block identifier (block ID) and the transaction identifier (TxID); and/or
iii) the transaction of the plurality of blockchain transactions is associated with an unspent transaction output. (Carver: See paragraph [0089] discloses “the transaction handler interacts with a set of UTXO handlers 614 with messages (via 615 and 620) to create, query, spend, and assign Unspent Transaction Outputs (UTXOs) associated with each transaction.”, and notes: for examination purposes, “and/or” will be interpreted as “or”.)
Regarding claim 7:
Carver teaches the following:
The method according to claims 5, further comprising the step: using the record identifier to search for, identify, access or insert the at least one record in the output repository. (Carver: See paragraph [0035] discloses “A blockchain is a continuously growing list of records, called blocks, that are linked and secured using cryptography. Each block in a blockchain typically contains a cryptographic hash linking to the previous block, and transaction data. For use as a distributed ledger, a blockchain is typically managed by a peer-to-peer network collectively adhering to a protocol for inter-node communication and validating new blocks.”, and notes: for examination purposes, “and/or” will be interpreted as “or”.)
Regarding claim 13:
Carver teaches the following:
The method according to claim 1, wherein:
the portion of the Merkle tree is a sub-portion or segment of the Merkle tree for the blockchain block; and/or (Carver: See paragraph [0076] discloses “the node coordinator provides the overall block Merkle tree to each segment handler. Each segment handler, in turn, persists its set of segments associated with the block, and it instructs its associated transaction handlers to finalize the block. In so doing, the segment handlers generate and provide to the transaction handlers the portion of the block's overall Merkle tree each transaction handler needs for its set of segments.”, and notes: for examination purposes, “and/or” will be interpreted as “or”.)
ii) the plurality of blockchain transactions is represented by an inner node of the Merkle tree.
Regarding claim 14:
Carver discloses the following:
A blockchain validating system operative to validate at least a portion of a blockchain block that comprises a plurality of blockchain transactions and a root of a Merkle tree for the block; (Carver: See paragraph [0051] discloses “In performing validation, and upon receiving messages 503 for a segment, the receiving node element handling the segment validates the received transactions, computes the segment's Merkle tree, and upon completion sends message 506 to the element in the node handling the header. That element reconstructs the block header from the messages 506 for all segments and compares it to the header received from the mining node in message 505. If the headers match, the block is accepted and added to the set of pre-finalized blocks in that node.”)
wherein the system comprises a plurality of validating resources, each comprising: a processor; and memory including executable instructions that, as a result of execution by the processor, causes a respective validating resource of the system to perform a computer-implemented method comprising the steps: (Carver: See paragraph [0152] discloses “A machine implementing the techniques herein comprises a processor, computer memory holding instructions that are executed by the processor to perform the above described methods.”, and see also [0121-0123])
segmenting, by a controller, the plurality of blockchain transactions into a plurality of subsets of blockchain transactions, wherein each respective subset of blockchain transactions is represented by a respective inner portion of the Merkle tree for the blockchain block, and wherein: (Carver: See paragraphs [0041] discloses “Referring to FIG. 2, a block 200 is segmented by transaction id (Tx,) into some number of segments 202a-n, where n=l000, and a header 204. The segments 202 and header 204 represent a block of the blockchain although they may be (and often are) processed, transmitted and stored separately. The number of segments 202, shown in FIG. 2 as 1000, may be more or fewer in number and may change over time or dynamically.”; and [0076] discloses “Each segment handler, in turn, persists its set of segments associated with the block, and it instructs its associated transaction handlers to finalize the block. In so doing, the segment handlers generate and provide to the transaction handlers the portion of the block's overall Merkle tree each transaction handler needs for its set of segments.”)
all transactions in the respective subset of blockchain transactions share the same respective inner node; (Carver: See paragraph [0042] discloses “block segmentation typically is an externally visible attribute shared by all nodes of the network. As will be seen, organizing the block data by segment significantly improves the performance and efficiency of nodes exchanging block information.”)
iii) allocating, by the controller, a subset of blockchain transactions to the respective computing resource for validation of the respective subset of blockchain transactions to verify that they conform to a blockchain protocol; and (Carver: See paragraph [0061] discloses “a transaction handler that receives a raw transaction determines (from querying the UTXO handler) whether inputs to the transaction exists and, if so, what are their values and locking scripts (containing public keys sometimes referred to as addresses or wallet addresses). It checks each input's unlocking script (digital signature), and if all signatures are valid, the transaction handler commits (saves) the raw transaction to its associated memory pool. In this manner, validated raw transactions accumulate in each handler's mem pool. Thus, in each transaction handler's mem pool there are a collection of transactions in effect "waiting" to be mined (i.e., assigned) to a block segment (and thus a block) in the blockchain.”, and see also [0058])
Carver does not explicitly disclose the following, however Davies further teaches:
the respective inner portion of the Merkle tree for the blockchain block is represented by a respective inner node of the Merkle Tree for the blockchain block; (Davies: See paragraph [0090] discloses “a hash tree is a tree-like data structure comprising "internal" nodes and "leaf' nodes connected by a set of directional edges. Each leaf node represents the cryptographic hash of a portion of data (data block) that is to be "stored" in the tree, and each node is generated by hashing the concatenation of its "children" (child nodes).”)
the respective inner node is a node in the Merkle tree for the blockchain block that is neither the root node of the Merkle tree for the blockchain block nor a leaf node; and (Davies: See paragraph [0090] discloses “a hash tree is a tree-like data structure comprising "internal" nodes and "leaf' nodes connected by a set of directional edges. Each leaf node represents the cryptographic hash of a portion of data (data block) that is to be "stored" in the tree, and each node is generated by hashing the concatenation of its "children" (child nodes). A child node of a "parent" node is any node directly connected to the parent node by a directional edge. The root node of the hash tree can be used to represent a large set of data compactly, and it can be used to prove that any one of the portions of data corresponding to a leaf node is indeed part of the set. The root node is a single node to which all other nodes are connected either directly or indirectly.”)
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the transaction handler commits (saves) the raw transaction to its associated memory pool with validated raw transactions that accumulate in each handler's mem pool (e.g., in each transaction handler's mem pool there are a collection of transactions in effect "waiting" to be mined (i.e., assigned) to a block segment (and thus a block) in the blockchain.) of Carver to include the internal nodes and leaf nodes connected by a set of directional edges. Each leaf node represents the cryptographic hash of a portion of data (data block) that is to be stored in the tree, and each node is generated by hashing the concatenation of its "children" (child nodes). A child node of a parent node is any node directly connected to the parent node by a directional edge, as taught by Davies, in order to verify the set of transactions. (See Davies, [0003-0010])
Carver and Davies do not explicitly disclose the following, however Wright further teaches:
ii) generating, storing and/or maintaining, by the respective validating resource of the plurality of computing resources, a respective output repository for recording, searching and/or processing a plurality of unspent transaction outputs, each unspent transaction output associated with a transaction (Tx) in a respective subset of blockchain transactions (TXs) of the blockchain block; (Wright: See page 2, lines 10-19: discloses “In order for a transaction to be written to the blockchain, it must be "validated". Network nodes (miners) perform work to ensure that each transaction is valid, with invalid transactions rejected from the network. Software clients installed on the nodes perform this validation work on an unspent transaction (UTXO) by executing its locking and unlocking scripts. If execution of the locking and unlocking scripts evaluate to TRUE, the transaction is valid and the transaction is written to the blockchain. Thus, in order for a transaction to be written to the blockchain, it must be i) validated by the first node that receives the transaction - if the transaction is validated, the node relays it to the other nodes in the network; and ii) added to a new block built by a miner; and iii) mined, i.e. added to the public ledger of past transactions.”, and notes: for examination purposes, “and/or” will be interpreted as “or”.)
iv) recording, in the respective output repository by the respective computing resource, each unspent transaction output that is associated with a transaction (Tx) in the respective subset of blockchain transactions. (Wright: See page 2, lines 10-19: discloses “In order for a transaction to be written to the blockchain, it must be "validated". Network nodes (miners) perform work to ensure that each transaction is valid, with invalid transactions rejected from the network. Software clients installed on the nodes perform this validation work on an unspent transaction (UTXO) by executing its locking and unlocking scripts. If execution of the locking and unlocking scripts evaluate to TRUE, the transaction is valid and the transaction is written to the blockchain. Thus, in order for a transaction to be written to the blockchain, it must be i) validated by the first node that receives the transaction - if the transaction is validated, the node relays it to the other nodes in the network; and ii) added to a new block built by a miner; and iii) mined, i.e. added to the public ledger of past transactions.” )
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the transaction handler commits (saves) the raw transaction to its associated memory pool with validated raw transactions that accumulate in each handler's mem pool (e.g., in each transaction handler's mem pool there are a collection of transactions in effect "waiting" to be mined (i.e., assigned) to a block segment (and thus a block) in the blockchain.) of Carver to include the Merkle tree with that root to check (i.e. verify) whether a particular transaction was included in a particular block on the blockchain, without having to download the entire blockchain, as taught by Wright, in order to provide an efficient search for a certain transaction. (See Wright, page 3)
Regarding claim 15: it is similar scope to claim 14, and thus it is rejected under similar rationale.
Claims 8-12 are rejected under 35 U.S.C. 103 as being unpatentable over Carver in view of Davies in view of Wright in further view of Xiao, US Publication Number 2021/0209595 A1.
Regarding claim 8:
Carver, Davies, and Wright do not explicitly disclose the following, however Xiao further teaches:
The method according to preceding claim 1, wherein: at least one unspent transaction output in the plurality of unspent transaction outputs is associated with a locking flag which:
indicates whether the unspent transaction output is available or unavailable for spending; and/or (Xiao: See paragraph [0105] discloses “The so-called 'lock' may be adding a flag bit in the UTXO to mark that the UTXO cannot perform a transfer”, and notes: for examination purposes, “and/or” will be interpreted as “or”.)
ii) is configurable between a first state indicative that spending of the unspent transaction output is allowed and a second state indicative that spending of the unspent transaction output is prohibited.
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the transaction handler commits (saves) the raw transaction to its associated memory pool with validated raw transactions that accumulate in each handler's mem pool (e.g., in each transaction handler's mem pool there are a collection of transactions in effect "waiting" to be mined (i.e., assigned) to a block segment (and thus a block) in the blockchain.) of Carver to include the ability to flag transactions, as taught by Xiao, in order to prohibit the UTXO form participating in the account transfers. (See Xiao, paragraph [0105])
Regarding claim 9:
Carver, Davies, and Wright do not explicitly disclose the following, however Xiao further teaches:
The method according to claim 8, the method comprising the step:
associating the unspent transaction output with the locking flag; and/or; (Xiao: See paragraph [0105] discloses “The so-called 'lock' may be adding a flag bit in the UTXO to mark that the UTXO cannot perform a transfer”, and notes: for examination purposes, “and/or” will be interpreted as “or”.)
ii) changing a state of the locking flag from the first state to the second state, or second state to the first state.
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the transaction handler commits (saves) the raw transaction to its associated memory pool with validated raw transactions that accumulate in each handler's mem pool (e.g., in each transaction handler's mem pool there are a collection of transactions in effect "waiting" to be mined (i.e., assigned) to a block segment (and thus a block) in the blockchain.) of Carver to include the ability to flag transactions, as taught by Xiao, in order to prohibit the UTXO form participating in the account transfers. (See Xiao, paragraph [0105])
Regarding claim 10:
Carver, Davies, and Wright do not explicitly disclose the following, however Xiao further teaches:
The method according to claims 8, comprising the step:
sending a communication from a first processing resource to at least one further processing resource to cause the at least one further processing resource to change the state of the locking flag associated with the unspent transaction output from the first state to the second state, or second state to the first state. (Xiao: See paragraph [0129] discloses “the transfer agreement identifier acquisition module 520 further includes a to-be-transferred currency resource unlocking submodule configured to set the locking flag bit of the to-be-transferred UTXO as an unlocking state value”.)
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the transaction handler commits (saves) the raw transaction to its associated memory pool with validated raw transactions that accumulate in each handler's mem pool (e.g., in each transaction handler's mem pool there are a collection of transactions in effect "waiting" to be mined (i.e., assigned) to a block segment (and thus a block) in the blockchain.) of Carver to include the ability to flag transactions, as taught by Xiao, in order to prohibit the UTXO form participating in the account transfers. (See Xiao, paragraph [0105])
Regarding claim 11:
Carver and Davies do not explicitly disclose the following, however Wright further teaches:
The method according to claim 10, wherein the communication comprises:
a transaction (TX), a transaction identifier (TxID) and/or a hash of a transaction (Tx); and (Wright: See page 15, lines 3-7: discloses “Alice also communicates the transaction ID TxID3 of the payment transaction Tx3 to Bob”, and notes: for examination purposes, “and/or” will be interpreted as “or”.)
ii) a list of one or more unspent transaction outputs. (Wright: See page 22, lines 12-15: discloses “the ability to broadcast a new signed transaction to the blockchain network and to query for the existence of specific UTXOs in the current UTXO set.”)
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the transaction handler commits (saves) the raw transaction to its associated memory pool with validated raw transactions that accumulate in each handler's mem pool (e.g., in each transaction handler's mem pool there are a collection of transactions in effect "waiting" to be mined (i.e., assigned) to a block segment (and thus a block) in the blockchain.) of Carver to include the Merkle tree with that root to check (i.e. verify) whether a particular transaction was included in a particular block on the blockchain, without having to download the entire blockchain, as taught by Wright, in order to provide an efficient search for a certain transaction. (See Wright, page 3)
Regarding claim 12:
Carver, Davies, and Wright do not explicitly disclose the following, however Xiao further teaches:
The method according to claims 10, and comprising the steps:
receiving the communication at the at least one further processing resource; changing the state of the locking flag from the first state to the second state, or second state to the first state. (Xiao: See paragraph [0129] discloses “the transfer agreement identifier acquisition module 520 further includes a to-be-transferred currency resource unlocking submodule configured to set the locking flag bit of the to-be-transferred UTXO as an unlocking state value”.)
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the transaction handler commits (saves) the raw transaction to its associated memory pool with validated raw transactions that accumulate in each handler's mem pool (e.g., in each transaction handler's mem pool there are a collection of transactions in effect "waiting" to be mined (i.e., assigned) to a block segment (and thus a block) in the blockchain.) of Carver to include the ability to flag transactions, as taught by Xiao, in order to prohibit the UTXO form participating in the account transfers. (See Xiao, paragraph [0105])
Conclusion
The prior art made of record but not relied upon herein but pertinent to Applicant’s disclosure is listed in the enclosed PTO-892.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to YONG S PARK whose telephone number is (571)272-8349. The examiner can normally be reached M-F 9:00-5:00 PM, EST.
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, Bennett M. Sigmond can be reached on (303)297-4411. 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.
/YONGSIK PARK/Examiner, Art Unit 3694
August 26, 2026
/BENNETT M SIGMOND/Supervisory Patent Examiner, Art Unit 3694
Prosecution Insights