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 .
Status of Claims
This action is in reply to the amendment filed 11/28/2025.
Claims 1, 4, and 14-15 have been amended. Claims 1-15 are pending and have been examined on the merits (claims 1, 14, and 15 being independent).
The amendment filed 11/28/2025 to the claims has been entered.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 11/24/2025 is 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 11/28/2025 have been fully considered.
Regarding to the claim objection, Applicant’s amendment has properly addressed based on the claim objection. Therefore, the claim objection has been withdrawn.
Regrading to the rejections under 35 U.S.C. 101, Applicant’s argument and amendments have been considered and are persuasive. Therefore, the rejections under 35 U.S.C. 101 have been withdrawn in view of the Applicant’s arguments and amendments (see Applicant’s remarks, pages 6-8)
With regard to the rejections of claims 1-15 under 35 U.S.C. 102/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. As noted in the citation above the prior art and it is addressed by the rejections 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 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 across a plurality of computing resources that are operative to perform blockchain related validation tasks, the method comprising the steps: (Carver: See paragraph [0035] “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 see also [0049])
ii) the plurality of blockchain transactions has been allocated to the respective computing resource by a controller resource for validation of the plurality of blockchain transactions to verify that they conform to a blockchain protocol. (Carver: See paragraph [0061] “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 [0049] and [0058])
Carver does not explicitly disclose the following, however Wright further teaches:
generating, storing and/or maintaining, by a respective computing resource of the plurality of computing resources, a respective first output repository for recording, searching and/or processing a respective plurality of unspent transaction outputs, each unspent transaction associated with a transaction (Tx) in a plurality of blockchain transactions (TXs) of the blockchain block; (Wright: See page 2, lines 10-19: “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”.)
wherein:
i) the plurality of blockchain transactions provides and/or is represented by a portion of a Merkle tree for the blockchain block; and (Wright: See page 3, lines 1-7: “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”)
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 does 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: “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] “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] “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] “Preferably, UTXOs are identified by an identifier (txid), which is a hash or digest of the
Regarding claim 5:
Carver does 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: “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: “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] “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] “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] “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:
Wright 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; (Wright: See page 3, lines 1-7: “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.”)
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: (Wright: See page 8, lines 19-21: “The system may comprise: a processor; and memory including executable instructions that, as a result of execution by the processor, causes the system to perform any embodiment of the disclosure described or claimed herein.”)
generating, storing and/or maintaining, by the respective validating resource of the plurality of computing resources, a respective first 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 plurality of blockchain transactions (TXs) of the a blockchain block; (Wright: See page 2, lines 10-19: “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”.)
wherein:
i) the respective plurality of blockchain transactions provides and/or is represented by a portion of the Merkle tree for the blockchain block; and (Wright: See page 3, lines 1-7: “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”.)
Wright does not explicitly disclose the following, however Carver further teaches:
ii) the respective plurality of blockchain transactions has been allocated to the respective computing resource by a controller resource for validation of the plurality of blockchain transactions to verify that they conform to a blockchain protocol. (Carver: See paragraph [0061] “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 [0049] and [0058])
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 providing improved verification solutions for blockchain implemented transfers of Wright to include to 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.), as taught by Carver, in order to provide create and assign unspent transaction outputs (UTXOs) associated with each transaction. (See Carver, paragraph [0088-0089])
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 Wright in further view of Xiao, US Publication Number 2021/0209595 A1.
Regarding claim 8:
Carver 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] “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 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] “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 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] “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 does 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: “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: “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 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] “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.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
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 on 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 February 13, 2026
/BENNETT M SIGMOND/Supervisory Patent Examiner, Art Unit 3694