Detailed Action
Claims 21-40 are pending and are examined.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
Claims 21-40 are newly added.
Claims 1-20 are cancelled.
Response to Remarks
35 U.S.C. § 112(a), § 112(b), and § 112(f)
Applicant’s amendments to the claims have overcome the previous rejections. Accordingly, the previous rejections are withdrawn. However, new grounds of rejection have been made.
35 U.S.C. § 102 and § 103
Remark 1: Applicant argues “Deshpande teaches heuristics for selecting transactions into blocks based on mining costs and results [para 0027: "selecting the transactions for the next blockchain block based on a highest result value and a lowest mining cost"]. It also teaches estimating costs for entities using lead transactions [para 0028: "the lead or first transaction for a particular entity may be the approach used to estimate costs and results for all transactions from that entity"] and iterative selection based on accounts and costs [para 0030: "different accounts and their transaction costs"], focusing on pre-block simulation for higher results [para 0022: "if the miners knew the true costs of executing a transaction, the blocks which are subsequently formed could be populated with higher resulting transactions"]. Deshpande fails to teach prioritizing smaller transactions to address inequities, as its heuristics explicitly favor higher value/low cost regardless of size, disadvantaging smaller transactions without equity mechanisms [para 0029 and claim 11 favor "highest result value and lowest mining cost"]. It lacks ML for dynamic block sizing based on historical data, relying on static heuristics without learning [claim 5: "the one or more heuristic procedures comprise determining the mining costs and nonce values"; no ML or historical evaluation]. Deshpande does not teach aggregating smaller transactions with an exhaustive meta hash, handling them individually without encapsulation [para 0028]. It fails to teach iterative space freeing during block formation, with selection based on costs but no reclamation [para 0030]. Finally, it omits TPS rewards, focusing on pre-block mining results [para 0022]. Combining Deshpande with others is not obvious, as its cost-maximization teaches away from equity for smaller transactions, and its static heuristics are incompatible with ML historical adaptation; no motivation to modify for exhaustive aggregation or TPS rewards, as Deshpande optimizes for miner profit, not network equity or throughput incentives.” (Applicant Arguments, 2025-11-19).
Response to Remark 1: Examiner respectfully disagrees, as the cited references (e.g. Deshpande, Safary, Madisetti, and White) still teach the current independent claims, as shown at least in paragraphs 47, 44, and 36 of Deshpande, and as further outlined in paragraphs 24-36 of this action. Indeed, Deshpande expressly teaches selecting blockchain transaction by simulating mining costs, determining cost per unit size, and applying one or more heuristics to maximize the result of the next block, which directly undercuts the assertion that it merely uses a rigid, non-adaptive profit rule. It also accounts for transaction size, leftover block size, iterative reselection, and dynamic programming/optimization, so the claim that Deshpande fails to address smaller transactions or iterative space management is unfounded. Moreover, Deshpande does not criticize or discourage alternative heuristics, aggregation strategies, or adaptive enhancements, rather it invites them by teaching multiple heuristics, dynamic selection, and optimization under transaction-size and cost constraints. Accordingly, this contention is unpersuasive.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 21-40 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention.
New Matter Added to Claims
Claims 21 and 31 recite “an active metadata processor”, “a reinforcement learning processor”, “a block creator processor”, “a merging processor”, “a command processor”, “a validation processor”, and “a segregation processor”. The specification (See Pre-Grant Publication 0086) disclosing microprocessors in the context of a general-purpose computer. However, the specification is silent with respect to each of the amended claimed terms of “an active metadata processor”, “a reinforcement learning processor”, “a block creator processor”, “a merging processor”, “a command processor”, “a validation processor”, and “a segregation processor” as being a processor. Therefore, new matter is added to the claims. New or amended claims which introduce elements or limitations that are not supported by the as-filed disclosure violate the written description requirement, and are thus rejected on the ground of a lack of written description under 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, first paragraph. See MPEP 2163.01 and 2163.06.
Claims 22-30 and 32-40 are also rejected per dependency upon a rejected claim.
Claim Rejections - 35 USC § 103
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.
Claims 21-40 are rejected under 35 U.S.C. 103 as being unpatentable over Deshpande et al. (US20190378069A1) (hereinafter “Deshpande”) in view of Safary et al. (US20220318270A1) (hereinafter “Safary”) and Madisetti et al. (US20180300382A1) (hereinafter “Madisetti”) in further view of White et al. (US20220207023A1) (hereinafter “White”)
As per Claim 21 and 31, Deshpande teaches:
A blockchain transaction processing system for improving transactions per second comprising: a transaction queue, the transaction queue configured to receive cryptocurrency transactions from users, to store the cryptocurrency transactions, and to prioritize the cryptocurrency transactions, each cryptocurrency transaction distinctly represented as an unspent transaction output with comprehensive sender information, comprehensive receiver information, and a transaction value; (“the system configuration 400 includes a memory pool or transaction pool 410 which is basically a queue of transactions 412.” (Para. 0047); “The processing platform used by the miner service to create blocks 420 may sort the transactions multiple times according to heuristics applied to the transactions for optimization determination prior to block creation. The transactions may be forwarded 414 and sorted by nonce 416, and a simulation 418 may be used to determine the entities associated with the transactions, the size of the transactions, the results linked to the transactions for performing the mining effort, etc.” (Para. 0047); “the method 500 may include receiving a plurality of blockchain transactions 512, sorting an order of the plurality of blockchain transactions 514.” (Para. 0065))
an active metadata processor operatively connected to the transaction queue, the active metadata processor configured to analyze details of each cryptocurrency transaction, to process the details of each cryptocurrency transaction, to calculate a precise real value of each cryptocurrency transaction, to calculate a size of each cryptocurrency transaction, and to continuously assess an available block size within a blockchain network for optimal transaction accommodation by iteratively querying block capacity in real-time and comparing against aggregated transaction sizes, with prioritization for smaller cryptocurrency transactions to address processing inequities; (See Fig 1A, “Simulate Execution of Transactions and Determine Exact Cost Per Unit Size for Each Transaction.”; “the configuration 100 provides a memory pool 110 of transactions 102-112 which are currently available for mining/finalization and preparation for blockchain block creation and committance to the blockchain. The transactions in the memory pool are not ordered in any particular scheme. Once the transactions are identified and received 114 from the transaction pool via a computing device, the transactions may be sorted according to their nonce values, which may be tied to certain accounts or entities as members of the blockchain. The transactions can then be simulated for cost and result analysis. The cost analysis may be based on cost per unit size for each transaction 116.” (Para. 0031); “The cost per unit size of the transactions may be determined to identify the time and processing requirements, CPU, memory, storage, etc., required to mine the transactions 422.” (Para. 0047))
a block creator processor operatively connected to the reinforcement learning processor, the block creator processor configured to receive a stream of optimized cryptocurrency transactions for inclusion in blockchain blocks and to provide real-time block size information to the reinforcement learning processor for ongoing transaction optimization; (“. . . certain transactions are identified for miner operations and ultimately committance to the blockchain 226. Once the transactions are identified and the expected cost and result values are confirmed, the block creation operations may be executed to create a next block 228 based on the optimization heuristics applied to the transaction data.” (Para. 0038), see also Fig. 2A; “The ordering node 284 does not need to inspect the entire content of a transaction in order to perform its operation, instead the ordering node 284 may simply receive transactions from all channels in the network, order them chronologically by channel, and create blocks of transactions per channel.” (Para. 0043); “The blocks of the transaction are delivered from the ordering node 284 to all peer nodes 281-283 on the channel. The transactions 294 within the block are validated to ensure any endorsement policy is fulfilled and to ensure that there have been no changes to ledger state for read set variables since the read set was generated by the transaction execution. Transactions in the block are tagged as being valid or invalid.” (Para. 0044))
a validation processor, the validation processor configured to perform validation of a complete blockchain block containing the singular larger transaction package and to employ a consensus mechanism within the blockchain network to ensure legitimacy of the cryptocurrency transactions, accuracy of the cryptocurrency transactions, and integrity of the cryptocurrency transactions; and (“The client 260 assembles the endorsements into a transaction payload 293 and broadcasts it to an ordering service node 284. The ordering service node 284 then delivers ordered transactions as blocks to all peers 281-283 on a channel. Before committal to the blockchain, each peer 281-283 may validate the transaction. For example, the peers may check the endorsement policy to ensure that the correct allotment of the specified peers have signed the results and authenticated the signatures against the transaction payload 293.” (Para. 0039); “Transactions in the block are tagged as being valid or invalid. Furthermore, in step 295 each peer node 281-283 appends the block to the channel's chain, and for each valid transaction the write sets are committed to current state database. An event is emitted, to notify the client application that the transaction (invocation) has been immutably appended to the chain, as well as to notify whether the transaction was validated or invalidated.” (Para. 0044); “A transaction is an execution of the smart contract code which can be performed in response to conditions associated with the smart contract being satisfied. The executing of the smart contract may trigger a trusted modification(s) to a state of a digital blockchain ledger. The modification(s) to the blockchain ledger caused by the smart contract execution may be automatically replicated throughout the distributed network of blockchain peers through one or more consensus protocols.” (Para. 0036))
Deshpande does not disclose: “a reinforcement learning processor communicatively linked to the active metadata processor, the reinforcement learning processor configured to receive detailed transaction data, to receive block size information, and to apply machine learning algorithms for dynamic adjustment of block sizes based on an aggregated size of cryptocurrency transactions awaiting processing by evaluating historical performance data, transaction load, and patterns in smaller transaction delays to prioritize equity, thereby enhancing processing efficiency”.
However, as per Claim 1, Safary in the analogous art of blockchain transaction management between parties, teaches: “a reinforcement learning processor communicatively linked to the active metadata processor, the reinforcement learning processor configured to receive detailed transaction data, to receive block size information, and to apply machine learning algorithms for dynamic adjustment of block sizes based on an aggregated size of cryptocurrency transactions awaiting processing by evaluating historical performance data, transaction load, and patterns in smaller transaction delays to prioritize equity, thereby enhancing processing efficiency;”. (See “. . . monitoring, by an AI engine, an input and output (I/O) load of the data store, and a network bandwidth corresponding to the data store. The AI engine may compare a size of the plurality of worklist items to a threshold size..” (Para. 0016); “The threshold size may be increased when the I/O load is high and the network bandwidth is high. The threshold size may be decreased when the I/O load is low and the network bandwidth is low. The method may further comprise determining that the size meets the threshold size and, in response to the determining that the size meets the threshold size, generating a hash value corresponding to the plurality of worklist items in the data store.” (Para. 0016); “If the size of the transaction pool reaches the threshold size, the AI-based performance monitoring module 720 may send an indication to the block service 722 for creation of a new block. Based on receiving the indication the block service may create a new block including the transactions stored in the transaction pool. The block service 722, for creating the new block, may query the ordering service server 716 for a latest hash value of the blockchain and the transactions stored in the transaction pool.” (Para. 0134))
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Deshpande with the technique of Safary to include an AI/ML controller to monitor transactions and issue block-related commands. Therefore, the incentives of ensuring secure, automated settlement of approved transactions using distributed ledger technology provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 1, Safary in the analogous art of multi-factor authentication, teaches: “and to apply advanced machine learning algorithms for dynamic adjustment of block sizes based on an aggregated size of transactions awaiting processing, thereby enhancing processing efficiency”. (See “An AI-based performance monitoring module 720 may monitor a size of the transaction pool (e.g., a quantity of transactions in the transaction pool), a network bandwidth, an input/output (I/O) load of the transaction pool, etc. Based on these monitored parameters, the AI-based performance monitoring module 720 may adjust a threshold size of the transaction pool. Further details associated with the AI-based monitoring platform are described with reference to FIGS. 9 and 11. If the size of the transaction pool reaches the threshold size, the AI-based performance monitoring module 720 may send an indication to the block service 722 for creation of a new block.” (para. 0133-0134); “The AI-based performance monitoring service 904 may use one or more machine learning algorithms to determine, based on the I/O load parameters and/or network bandwidth parameters, whether to initiate generation of a new block and/or adjust a block size.” (Para. 0162); “Based on determination of increased network bandwidth and/or I/O load, the AI-based performance monitoring service 904 may increase the block size such that a larger number of transactions are included in a block and a blockchain bandwidth is increased.” (Para. 0156))
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Deshpande with the technique of Safary to include an ML module that dynamically tunes block size using aggregated queued transactions. Therefore, the incentives of providing increased data security for the user provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
However, as per Claim 1, Safary in the analogous art of secured payments between parties, teaches: “a sophisticated command issuance system within the Reinforcement Learning module, configured to precisely instruct the Block Creator to integrate the merged transaction into a designated blockchain block, . . .”. (See “An AI-based performance monitoring module 720 may monitor a size of the transaction pool (e.g., a quantity of transactions in the transaction pool), a network bandwidth, an input/output (I/O) load of the transaction pool, etc. Based on these monitored parameters, the AI-based performance monitoring module 720 may adjust a threshold size of the transaction pool. Further details associated with the AI-based monitoring platform are described with reference to FIGS. 9 and 11.” (Para. 0133); “If the size of the transaction pool reaches the threshold size, the AI-based performance monitoring module 720 may send an indication to the block service 722 for creation of a new block. Based on receiving the indication the block service may create a new block including the transactions stored in the transaction pool. The block service 722, for creating the new block, may query the ordering service server 716 for a latest hash value of the blockchain and the transactions stored in the transaction pool.” (Para. 0134); “The threshold size may be decreased when the I/O load is low and the network bandwidth is low. The method may further comprise determining that the size meets the threshold size and, in response to the determining that the size meets the threshold size, generating a hash value corresponding to the plurality of worklist items in the data store. The method may further comprise creating a new block using the generated hash value and an immediately preceding block hash in the blockchain; and adding the new block to the blockchain.” (Para. 0016))
17. It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Deshpande with the technique of Safary to include dynamic block space management system. Therefore, the incentives of ensuring efficient use of network resources on the blockchain provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
Deshpande does not disclose “a segregation processor activated post-validation by the validation processor, the segregation processor configured to segregate the individual cryptocurrency transactions from the singular larger transaction package, thereby ensuring each cryptocurrency transaction represented by a respective unspent transaction output is assigned to an intended counterpart's wallet, thereby completing a transaction cycle and awarding TPS rewards to incentivize efficient processing”.
However, as per Claim 1, Madisetti in the analogous arts of blockchain transaction management between parties, teaches: “a segregation processor activated post-validation by the validation processor, the segregation processor configured to segregate the individual cryptocurrency transactions from the singular larger transaction package, thereby ensuring each cryptocurrency transaction represented by a respective unspent transaction output is assigned to an intended counterpart's wallet, thereby completing a transaction cycle and awarding TPS rewards to incentivize efficient processing.”. (See “The method of synchronizing transactions also includes generating a first merged block including the first private block and the second private block.” (Para. 0036, Madisetti); “The method of synchronizing transactions also includes recording the first merged block to a single block on a public blockchain network.” (Para. 0038, Madisetti); “the first merged block comprises a combined transaction comprising a net token value equaling the net of transfers of tokens between the two users in the plurality of transactions between the two users.” (Claim 3, Madisetti).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Deshpande with the technique of Madisetti to include meta-hashing for merged transactions. Therefore, the incentives of increasing transaction throughput and secured settlement of approved transactions using distributed ledger technology provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
Deshpande, Wright, Safary, and Madisetti do not disclose:
“a command processor within the reinforcement learning processor, the command processor configured to instruct a block creator to integrate the singular larger transaction package into a designated blockchain block and to manage a block space by freeing up superfluous space through iterative space assessment and reallocation, thereby facilitating inclusion of additional cryptocurrency transactions;” (claim 1)
As per Claim 1, White in the analogous art of blockchain transactions, teaches: “a command processor within the reinforcement learning processor, the command processor configured to instruct a block creator to integrate the singular larger transaction package into a designated blockchain block and to manage a block space by freeing up superfluous space through iterative space assessment and reallocation, thereby facilitating inclusion of additional cryptocurrency transactions;”. (See “Referring to FIG. 9, at 902, based at least in part on an amount of remaining storage available in the device being relative to a particular level, the device trims a portion of the blockchain from the device including by making storage allocated to the portion of the blockchain available.” (Para. 0103); “The target device 302 may, at 902, trim at least a portion of a blockchain from the target device 302. The target device 302 may, at 904, recalculate the blockchain without the portion of the blockchain that has been trimmed from the target device 302.” (Para. 0108); “at 902, the device may trim a portion of the blockchain 1000 by making storage allocated to a portion of the blockchain 1000 available. For example, the device 902 may determine to remove two blocks of the blockchain 1000.” (Para. 0112))
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Deshpande with the technique of White to include an adaptive processor that manages blocks by freeing up unused space. Therefore, the incentives of ensuring efficient memory usage provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 22, Deshpande teaches:
The blockchain transaction processing system of claim 21, wherein the transaction queue further includes a prioritization algorithm configured to prioritize the cryptocurrency transactions based on predefined criteria, such as a respective transaction value, urgency, or user status, further comprising sorting the cryptocurrency transactions by unspent transaction output details including sender and receiver identities to bundle transactions from common senders or receivers, preserving traceability and addressing delays for low-value users. (“The heuristics selected by the miner may be applied to finalize the sorted order of transactions 424 and to collect the optimal order 426 for block creation based on the selected transactions which will be used to include in next made block(s) 428. The blocks are then forwarded 432 to the blockchain 430 for committance.” (Para. 0047); “A first heuristic applied to sorting and selecting the transactions for a block may be to determine cost per unit size, identify nonce values and order the transactions based on nonce, cost values and results. The computing entities may measure costs based on operational codes (OPCODES). The OPCODES are linked to a number of compute cycles. So, if a particular OPCODE requires four compute cycles and another OPCODE requires 14 compute cycles then the cost may be four times a current market value of blockchain transaction value required to run a compute cycle. If the current market value is 0.1 then the cost of performing the first OPCODE operation is 4×0.1 and the cost of the second OPCODE is 14×0.1.” (Para. 0048); “Next, while leftover blocksize>0 and un-picked transactions size<leftover blocksize: for each account i, pick cost_i_max=argmax n (cost_unit_i[n]). The option is selected with a maximum cost s*, and the feasibility of adding to the block is checked and s* is added to S* and the leftover block_size is updated.” (Para. 0049))
As per Claim 23, Deshpande teaches:
The blockchain transaction processing system of claim 22, wherein the active metadata processor is further configured to dynamically update processing of the active metadata processor based on real-time changes in the blockchain network, such as fluctuations in the available block size or network congestion. (“Next, while leftover blocksize>0 and un-picked transactions size<leftover blocksize: for each account i, pick cost_i_max=argmax n (cost_unit_i[n]). The option is selected with a maximum cost s*, and the feasibility of adding to the block is checked and s* is added to S* and the leftover block_size is updated.” (Para. 0049); “The transactions can then be simulated for cost and result analysis. The cost analysis may be based on cost per unit size for each transaction 116. The transaction simulation 120 may include reordering the transactions 122-130 for a most optimal block creation for a next block in the blockchain. The heuristic approaches 132, 134 and 136 may be applied to assist with cost and result determinations prior to selecting the transactions for a next block. The solutions/results are processed and the next block can then be formed according to the optimal solution provided 138.” (Para. 0031); “The processing platform used by the miner service to create blocks 420 may sort the transactions multiple times according to heuristics applied to the transactions for optimization determination prior to block creation. The transactions may be forwarded 414 and sorted by nonce 416, and a simulation 418 may be used to determine the entities associated with the transactions, the size of the transactions, the results linked to the transactions for performing the mining effort, etc. The cost per unit size of the transactions may be determined to identify the time and processing requirements, CPU, memory, storage, etc., required to mine the transactions 422.” (Para. 0047))
As per Claim 4, Deshpande teaches:
• . . .
15. Deshpande does not disclose:
• “The blockchain transaction processing system of claim 23, wherein the reinforcement learning processor incorporates adaptive learning algorithms capable of evolving strategies for block size adjustment and transaction optimization based on historical blockchain network performance data through iterative learning cycles that incorporate feedback from past TPS outcomes and network congestion patterns.” (claim 24).
16. However, as per Claim 24, Safary in the analogous art of blockchain transaction management between parties, teaches: “The blockchain transaction processing system of claim 23, wherein the reinforcement learning processor incorporates adaptive learning algorithms capable of evolving strategies for block size adjustment and transaction optimization based on historical blockchain network performance data through iterative learning cycles that incorporate feedback from past TPS outcomes and network congestion patterns.”. (“a method for artificial intelligence (AI)-assisted creation of new blocks in a blockchain may comprise adding a first worklist item to a data store communicatively coupled with a plurality of computing devices. The data store may comprise a plurality of worklist items including the first worklist item. The method may further comprise, monitoring, by an AI engine, an input and output (I/O) load of the data store, and a network bandwidth corresponding to the data store. The AI engine may compare a size of the plurality of worklist items to a threshold size. The threshold size may be increased when the I/O load is high and the network bandwidth is high. The threshold size may be decreased when the I/O load is low and the network bandwidth is low.” (Para. 0016); “In some arrangements, the threshold size may be dynamic based on: monitoring an input and output (I/O) load of the data store; monitoring a network bandwidth corresponding to the data store; and increasing the threshold size when the I/O load is high and the network bandwidth is high. A high network bandwidth may comprise values in an upper quartile of a range of network bandwidths over a historical time period. A high I/O load may comprise values in a higher quartile of a range of I/O loads over a historical time period.” (Para. 0007).
17. It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Deshpande with the technique of Safary to include a forwarded new transaction request from a service provider processor to a blockchain network for execution of a smart contract. Therefore, the incentives of ensuring secure, automated settlement of approved transactions using distributed ledger technology provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 25, Deshpande teaches:
. . .
Deshpande does not disclose:
• “The blockchain transaction processing system of claim 24, wherein the block creator processor includes a feedback mechanism to the reinforcement learning processor, the feedback mechanism providing continuous updates on block creation efficiency and transaction inclusion success rates.” (claim 25).
However, as per Claim 25, Safary in the analogous art of blockchain transaction management between parties, teaches: “The blockchain transaction processing system of claim 24, wherein the block creator processor includes a feedback mechanism to the reinforcement learning processor, the feedback mechanism providing continuous updates on block creation efficiency and transaction inclusion success rates.”. (See “The computer processor may be configured to: create a new block using the generated hash value and an immediately preceding block hash in a blockchain; and transmit the new block for addition to the blockchain. The workflow engine may be configured to: receive, from the ordering service server, the first worklist item; validate the first worklist item; and update, based on the new block, worklists associated with the plurality of user computing devices.” (Para. 0015); “The method may further comprise, in response to the determining that the size meets the threshold size, generating a hash value corresponding to the plurality of worklist items in the data store; creating a new block using the generated hash value and an immediately preceding block hash in the blockchain; and transmitting the new block for addition to the blockchain. The method may further comprise updating the workflow engine with the blockchain, wherein the workflow engine comprises activity names and identifiers corresponding to the plurality of worklist items.” (Para. 0006); “In some arrangements, the monitoring the I/O load of the data store may comprise monitoring at least one of: an average size of the data store; an arrival rate of worklist items to the data store; an average wait time for a worklist item in the data store; and combinations thereof.” (Para. 0008); “In some arrangements, the decreasing the threshold size when the I/O load is low may comprise decreasing the threshold size when an average wait time for a worklist item in the data store is greater than a threshold wait time. In some arrangements, the decreasing the threshold size when the I/O load is low may comprise decreasing the threshold size when an arrival rate of worklist items to the data store is lower than a threshold rate.” (Para. 0021))
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Deshpande with the technique of Safary to include a feedback path from the block service to the learning module. Therefore, the incentives of reduced latency under variable loads and higher fee yields provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 26, Deshpande teaches:
. . .
Deshpande does not disclose:
• “The blockchain transaction processing system of claim 25, wherein the merging processor is configured to selectively merge the cryptocurrency transactions based on criteria like transaction size, cost, and processing urgency, to create an optimized meta hash, wherein the selective merging further includes bundling transactions from a common sender or receiver to preserve traceability of individual unspent transaction outputs within the exhaustive information encapsulated by the meta hash, including sender identities, receiver identities, transaction amounts, and timestamps for auditability.” (claim 26).
However, as per Claim 26, Safary in the analogous art of blockchain transaction management between parties, teaches: “The blockchain transaction processing system of claim 25, wherein the merging processor is configured to selectively merge the cryptocurrency transactions based on criteria like transaction size, cost, and processing urgency, to create an optimized meta hash, wherein the selective merging further includes bundling transactions from a common sender or receiver to preserve traceability of individual unspent transaction outputs within the exhaustive information encapsulated by the meta hash, including sender identities, receiver identities, transaction amounts, and timestamps for auditability.”. (See “The AI engine may be configured to: monitor an input and output (I/O) load of the data store; monitor a network bandwidth corresponding to the data store; and compare a size of the plurality of worklist items to a threshold size. The threshold size may be increased when the I/O load is high and the network bandwidth is high, and decreased when the I/O load is low and the network bandwidth is low. The computer processor may be configured to: determine that the size meets the threshold size; in response to the determining that the size meets the threshold size, generate a hash value corresponding to the plurality of worklist items in the data store; create a new block using the generated hash value and an immediately preceding block hash in a blockchain; and send the new block for addition to the blockchain.”, disclosing a hash as a package identifier (Para. 0025); “In some arrangements, the decreasing the threshold size when the I/O load is low may comprise decreasing the threshold size when an average wait time for a worklist item in the data store is greater than a threshold wait time. In some arrangements, the decreasing the threshold size when the I/O load is low may comprise decreasing the threshold size when an arrival rate of worklist items to the data store is lower than a threshold rate.” (Para. 0021); “In some arrangements, the monitoring the I/O load of the data store may comprise monitoring at least one of: an average size of the data store; an arrival rate of worklist items to the data store; an average wait time for a worklist item in the data store; and combinations thereof.” (Para. 0018))
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Deshpande with the technique of Safary to include a selective transaction merging mechanism which emits a metahash identifying the aggregated set. Therefore, the incentives of maximizing block fill and reducing confirmation latency provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 27, Deshpande teaches:
. . .
Deshpande does not disclose:
• “The blockchain transaction processing system of claim 26, wherein the command processor within the reinforcement learning processor includes an automated decision- making process for block space management, the automated decision-making process considering factors like current network load and anticipated transaction volume, further comprising reallocating freed space to accommodate pending smaller transactions prioritized for equity via iterative space assessment cycles that query block capacity multiple times during block formation.” (claim 27).
16. However, as per Claim 27, Safary in the analogous art of blockchain transaction management between parties, teaches: “The blockchain transaction processing system of claim 26, wherein the command processor within the reinforcement learning processor includes an automated decision- making process for block space management, the automated decision-making process considering factors like current network load and anticipated transaction volume, further comprising reallocating freed space to accommodate pending smaller transactions prioritized for equity via iterative space assessment cycles that query block capacity multiple times during block formation.”. (See “wherein the threshold size is dynamic by: monitoring an input and output (I/O) load of the data store; monitoring a network bandwidth corresponding to the data store; and increasing the threshold size when the I/O load is high and the network bandwidth is high.” (Claim 2); “In some arrangements, the increasing the threshold size when the I/O load is high may comprise increasing the threshold size when the I/O load is within a higher quartile of a range of I/O loads over a historical time period. In some arrangements, the increasing the threshold size when the I/O load is high may comprise increasing the threshold size when an arrival rate of worklist items to the data store is greater than a threshold rate. In some arrangements, the decreasing the threshold size when the I/O load is low may comprise decreasing the threshold size when an average wait time for a worklist item in the data store is greater than a threshold wait time. In some arrangements, the decreasing the threshold size when the I/O load is low may comprise decreasing the threshold size when an arrival rate of worklist items to the data store is lower than a threshold rate.” (Para. 0020-0021); “In some arrangements, the monitoring the I/O load of the data store may comprise monitoring at least one of: an average size of the data store; an arrival rate of worklist items to the data store; an average wait time for a worklist item in the data store; and combinations thereof.” (Para. 0008))
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Deshpande with the technique of Safary to include an RL module issuing automated block space allocation decisions based on metrics. Therefore, the incentives of higher throughput and stable latency provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 28, Deshpande teaches:
The blockchain transaction processing system of claim 27, wherein the validation processor includes an enhanced security protocol to detect fraudulent cryptocurrency transactions during a validation process and to prevent the fraudulent cryptocurrency transactions during the validation process, and wherein the segregation processor is further enhanced to perform real-time audit checks to ensure accuracy in a distribution of unspent transaction outputs to respective counterparts' wallets, further comprising verifying the exhaustive information in the meta hash against original unspent transaction outputs post-segregation to prevent loss of transaction integrity. (“the endorsing peer node 281 may verify (a) that the transaction proposal is well formed, (b) the transaction has not been submitted already in the past (replay-attack protection), (c) the signature is valid, and (d) that the submitter (client 260, in the example) is properly authorized to perform the proposed operation on that channel. The endorsing peer node 281 may take the transaction proposal inputs as arguments to the invoked chaincode function.” (Para. 0041); “The transactions 294 within the block are validated to ensure any endorsement policy is fulfilled and to ensure that there have been no changes to ledger state for read set variables since the read set was generated by the transaction execution. Transactions in the block are tagged as being valid or invalid. Furthermore, in step 295 each peer node 281-283 appends the block to the channel's chain, and for each valid transaction the write sets are committed to current state database.” (Para. 0044).
As per Claim 29 and 40, Deshpande teaches:
. . .
15. Deshpande does not disclose:
• “The system of claim 29, wherein the system is configured to operate in various blockchain environments, including both Proof of Work and Proof of Stake systems, demonstrating flexibility and adaptability in different blockchain network architectures” (claim 1).
16. However, as per Claim 1, Madisetti in the analogous art of secured payments between parties, teaches: “The blockchain transaction processing system of claim 28, wherein the blockchain transaction processing system is configured to operate in various blockchain environments, including both Proof of Work and Proof of Stake systems, demonstrating flexibility and adaptability in different blockchain network architectures.”. (See “Block Difficulty (difficulty) 168: This field specifies a difficulty value for mining. A block is valid only if it contains a valid proof-of-work (PoW) of a given difficulty.” (Para. 0084); “With a DSS model for a blockchain network, it is possible to quantify the effects of various consensus mechanisms, blockchain designs or parameters on the decentralization, scalability and security of the blockchain network. For example, with a DSS model, we can compare the effects of switching the consensus mechanism on a blockchain network from Proof-of-Work to Proof-of-Stake. Similarly, we can compare the effects of changing the block-size and block-interval parameters for a blockchain network.” (Para. 0128); “Private blockchain network 1000 may adopt a different consensus algorithm (such as Proof of Authority or Delegated Proof of Stake) from the public blockchain network 1002.” (Para. 0157))
17. It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Deshpande, Safary, and Wright with the technique of Madisetti to include multiple consensus regimes for transacting across blockchains. Therefore, the incentives of ensuring network interoperability and deployment flexibility provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 30, Deshpande teaches:
The blockchain transaction processing system of claim 29, wherein the TPS rewards are awarded based on metrics including the number of smaller transactions processed equitably and overall network efficiency improvements, as determined by post-validation analysis. (“In this example, the transaction can be a deploy, invoke or query, and may be issued through a client-side application leveraging an SDK, directly through a REST API, or the like. Trusted business networks may provide access to regulator systems 314, such as auditors (the Securities and Exchange Commission in a U.S. equities market, for example). Meanwhile, a blockchain network operator system of nodes 308 manage member permissions, such as enrolling the regulator system 310 as an “auditor” and the blockchain user 302 as a “client.” An auditor could be restricted only to querying the ledger whereas a client could be authorized to deploy, invoke, and query certain types of chaincode.” (Para. 0045); “An event is emitted, to notify the client application that the transaction (invocation) has been immutably appended to the chain, as well as to notify whether the transaction was validated or invalidated.” (Para. 0044); “The blocks of the transaction are delivered from the ordering node 284 to all peer nodes 281-283 on the channel. The transactions 294 within the block are validated to ensure any endorsement policy is fulfilled and to ensure that there have been no changes to ledger state for read set variables since the read set was generated by the transaction execution.” (Para. 0044)).
As per Claim 32, Deshpande teaches:
The blockchain transaction processing method of claim 31, wherein the step of receiving and storing transactions includes prioritizing the transactions in the transaction queue based on predefined criteria, including but not limited to transaction value, urgency, or user status. (“The heuristics selected by the miner may be applied to finalize the sorted order of transactions 424 and to collect the optimal order 426 for block creation based on the selected transactions which will be used to include in next made block(s) 428. The blocks are then forwarded 432 to the blockchain 430 for committance.” (Para. 0047); “A first heuristic applied to sorting and selecting the transactions for a block may be to determine cost per unit size, identify nonce values and order the transactions based on nonce, cost values and results. The computing entities may measure costs based on operational codes (OPCODES). The OPCODES are linked to a number of compute cycles. So, if a particular OPCODE requires four compute cycles and another OPCODE requires 14 compute cycles then the cost may be four times a current market value of blockchain transaction value required to run a compute cycle. If the current market value is 0.1 then the cost of performing the first OPCODE operation is 4×0.1 and the cost of the second OPCODE is 14×0.1.” (Para. 0048); “Next, while leftover blocksize>0 and un-picked transactions size<leftover blocksize: for each account i, pick cost_i_max=argmax n (cost_unit_i[n]). The option is selected with a maximum cost s*, and the feasibility of adding to the block is checked and s* is added to S* and the leftover block_size is updated.” (Para. 0049))
As per Claim 33, Deshpande teaches:
The blockchain transaction processing method of claim 32, further comprising dynamically updating the transaction processing strategy in the active metadata processor in response to fluctuations in blockchain network conditions, such as block size availability or network congestion. (“Next, while leftover blocksize>0 and un-picked transactions size<leftover blocksize: for each account i, pick cost_i_max=argmax n (cost_unit_i[n]). The option is selected with a maximum cost s*, and the feasibility of adding to the block is checked and s* is added to S* and the leftover block_size is updated.” (Para. 0049); “The transactions can then be simulated for cost and result analysis. The cost analysis may be based on cost per unit size for each transaction 116. The transaction simulation 120 may include reordering the transactions 122-130 for a most optimal block creation for a next block in the blockchain. The heuristic approaches 132, 134 and 136 may be applied to assist with cost and result determinations prior to selecting the transactions for a next block. The solutions/results are processed and the next block can then be formed according to the optimal solution provided 138.” (Para. 0031); “The processing platform used by the miner service to create blocks 420 may sort the transactions multiple times according to heuristics applied to the transactions for optimization determination prior to block creation. The transactions may be forwarded 414 and sorted by nonce 416, and a simulation 418 may be used to determine the entities associated with the transactions, the size of the transactions, the results linked to the transactions for performing the mining effort, etc. The cost per unit size of the transactions may be determined to identify the time and processing requirements, CPU, memory, storage, etc., required to mine the transactions 422.” (Para. 0047))
As per Claim 34, Deshpande teaches:
. . .
Deshpande does not disclose:
• “The blockchain transaction processing method of claim 33, wherein the reinforcement learning processor adapts its block size adjustment strategies based on historical data and performance metrics of the blockchain network.” (claim 34).
16. However, as per Claim 34, Safary in the analogous art of blockchain transaction management between parties, teaches: “The blockchain transaction processing method of claim 33, wherein the reinforcement learning processor adapts its block size adjustment strategies based on historical data and performance metrics of the blockchain network.”. (See “The computer processor may be configured to: create a new block using the generated hash value and an immediately preceding block hash in a blockchain; and transmit the new block for addition to the blockchain. The workflow engine may be configured to: receive, from the ordering service server, the first worklist item; validate the first worklist item; and update, based on the new block, worklists associated with the plurality of user computing devices.” (Para. 0015); “The method may further comprise, in response to the determining that the size meets the threshold size, generating a hash value corresponding to the plurality of worklist items in the data store; creating a new block using the generated hash value and an immediately preceding block hash in the blockchain; and transmitting the new block for addition to the blockchain. The method may further comprise updating the workflow engine with the blockchain, wherein the workflow engine comprises activity names and identifiers corresponding to the plurality of worklist items.” (Para. 0006); “In some arrangements, the monitoring the I/O load of the data store may comprise monitoring at least one of: an average size of the data store; an arrival rate of worklist items to the data store; an average wait time for a worklist item in the data store; and combinations thereof.” (Para. 0008); “In some arrangements, the decreasing the threshold size when the I/O load is low may comprise decreasing the threshold size when an average wait time for a worklist item in the data store is greater than a threshold wait time. In some arrangements, the decreasing the threshold size when the I/O load is low may comprise decreasing the threshold size when an arrival rate of worklist items to the data store is lower than a threshold rate.” (Para. 0021))
17. It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Deshpande with the technique of Safary to include an RL module adapting block and transaction sizes using historical metrics. Therefore, the incentives of reduced latency under variable loads and higher fee yields provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 35, Deshpande teaches:
. . .
Deshpande does not disclose:
• “The blockchain transaction processing method of claim 34, further including a feedback mechanism from the block creator processor to the reinforcement learning processor, providing insights into efficiency and success rates of block creation and transaction inclusion.” (claim 15).
However, as per Claim 35, Safary in the analogous art of blockchain transaction management between parties, teaches: “The blockchain transaction processing method of claim 34, further including a feedback mechanism from the block creator processor to the reinforcement learning processor, providing insights into efficiency and success rates of block creation and transaction inclusion.”. (See “The computer processor may be configured to: create a new block using the generated hash value and an immediately preceding block hash in a blockchain; and transmit the new block for addition to the blockchain. The workflow engine may be configured to: receive, from the ordering service server, the first worklist item; validate the first worklist item; and update, based on the new block, worklists associated with the plurality of user computing devices.” (Para. 0015); “The method may further comprise, in response to the determining that the size meets the threshold size, generating a hash value corresponding to the plurality of worklist items in the data store; creating a new block using the generated hash value and an immediately preceding block hash in the blockchain; and transmitting the new block for addition to the blockchain. The method may further comprise updating the workflow engine with the blockchain, wherein the workflow engine comprises activity names and identifiers corresponding to the plurality of worklist items.” (Para. 0006); “In some arrangements, the monitoring the I/O load of the data store may comprise monitoring at least one of: an average size of the data store; an arrival rate of worklist items to the data store; an average wait time for a worklist item in the data store; and combinations thereof.” (Para. 0008); “In some arrangements, the decreasing the threshold size when the I/O load is low may comprise decreasing the threshold size when an average wait time for a worklist item in the data store is greater than a threshold wait time. In some arrangements, the decreasing the threshold size when the I/O load is low may comprise decreasing the threshold size when an arrival rate of worklist items to the data store is lower than a threshold rate.” (Para. 0021))
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Deshpande with the technique of Safary to include a feedback path from the block service to the learning module. Therefore, the incentives of reduced latency under variable loads and higher fee yields provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 36, Deshpande teaches:
. . .
Deshpande does not disclose:
• “The blockchain transaction processing method of claim 35, wherein the step of merging transactions into a larger package includes selectively combining transactions based on specific characteristics, such as transaction size, associated costs, and processing priority.” (claim 16).
However, as per Claim 36, Safary in the analogous art of blockchain transaction management between parties, teaches: “The blockchain transaction processing method of claim 35, wherein the step of merging transactions into a larger package includes selectively combining transactions based on specific characteristics, such as transaction size, associated costs, and processing priority.”. (See “The AI engine may be configured to: monitor an input and output (I/O) load of the data store; monitor a network bandwidth corresponding to the data store; and compare a size of the plurality of worklist items to a threshold size. The threshold size may be increased when the I/O load is high and the network bandwidth is high, and decreased when the I/O load is low and the network bandwidth is low. The computer processor may be configured to: determine that the size meets the threshold size; in response to the determining that the size meets the threshold size, generate a hash value corresponding to the plurality of worklist items in the data store; create a new block using the generated hash value and an immediately preceding block hash in a blockchain; and send the new block for addition to the blockchain.”, disclosing a hash as a package identifier (Para. 0025); “In some arrangements, the decreasing the threshold size when the I/O load is low may comprise decreasing the threshold size when an average wait time for a worklist item in the data store is greater than a threshold wait time. In some arrangements, the decreasing the threshold size when the I/O load is low may comprise decreasing the threshold size when an arrival rate of worklist items to the data store is lower than a threshold rate.” (Para. 0021); “In some arrangements, the monitoring the I/O load of the data store may comprise monitoring at least one of: an average size of the data store; an arrival rate of worklist items to the data store; an average wait time for a worklist item in the data store; and combinations thereof.” (Para. 0018))
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Deshpande with the technique of Safary to include a selective transaction merging mechanism which emits a metahash identifying the aggregated set. Therefore, the incentives of maximizing block fill and reducing confirmation latency provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 37, Deshpande teaches:
. . .
Deshpande does not disclose:
• “The blockchain transaction processing method of claim 36, further comprising an automated decision-making process within the reinforcement learning processor for optimally managing block space based on current network load and anticipated future transaction volumes.” (claim 37).
16. However, as per Claim 37, Safary in the analogous art of blockchain transaction management between parties, teaches: “The blockchain transaction processing method of claim 36, further comprising an automated decision-making process within the reinforcement learning processor for optimally managing block space based on current network load and anticipated future transaction volumes.”. (See “wherein the threshold size is dynamic by: monitoring an input and output (I/O) load of the data store; monitoring a network bandwidth corresponding to the data store; and increasing the threshold size when the I/O load is high and the network bandwidth is high.” (Claim 2); “In some arrangements, the increasing the threshold size when the I/O load is high may comprise increasing the threshold size when the I/O load is within a higher quartile of a range of I/O loads over a historical time period. In some arrangements, the increasing the threshold size when the I/O load is high may comprise increasing the threshold size when an arrival rate of worklist items to the data store is greater than a threshold rate. In some arrangements, the decreasing the threshold size when the I/O load is low may comprise decreasing the threshold size when an average wait time for a worklist item in the data store is greater than a threshold wait time. In some arrangements, the decreasing the threshold size when the I/O load is low may comprise decreasing the threshold size when an arrival rate of worklist items to the data store is lower than a threshold rate.” (Para. 0020-0021); “In some arrangements, the monitoring the I/O load of the data store may comprise monitoring at least one of: an average size of the data store; an arrival rate of worklist items to the data store; an average wait time for a worklist item in the data store; and combinations thereof.” (Para. 0008))
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Deshpande with the technique of Safary to include an RL module issuing automated block space allocation decisions based on metrics. Therefore, the incentives of higher throughput and stable latency provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 38, Deshpande teaches:
The blockchain transaction processing method of claim 37, including an enhanced security protocol within the validation processor for detecting and mitigating fraudulent transactions during a validation phase. (“the endorsing peer node 281 may verify (a) that the transaction proposal is well formed, (b) the transaction has not been submitted already in the past (replay-attack protection), (c) the signature is valid, and (d) that the submitter (client 260, in the example) is properly authorized to perform the proposed operation on that channel. The endorsing peer node 281 may take the transaction proposal inputs as arguments to the invoked chaincode function.” (Para. 0041); “The transactions 294 within the block are validated to ensure any endorsement policy is fulfilled and to ensure that there have been no changes to ledger state for read set variables since the read set was generated by the transaction execution. Transactions in the block are tagged as being valid or invalid. Furthermore, in step 295 each peer node 281-283 appends the block to the channel's chain, and for each valid transaction the write sets are committed to current state database.” (Para. 0044).
As per Claim 39, Deshpande teaches:
The blockchain transaction processing method of claim 38, wherein the step of segregating and completing transactions includes performing real-time audit checks to ensure accuracy in the distribution of unspent transaction outputs to the intended recipients' wallets. (“In this example, the transaction can be a deploy, invoke or query, and may be issued through a client-side application leveraging an SDK, directly through a REST API, or the like. Trusted business networks may provide access to regulator systems 314, such as auditors (the Securities and Exchange Commission in a U.S. equities market, for example). Meanwhile, a blockchain network operator system of nodes 308 manage member permissions, such as enrolling the regulator system 310 as an “auditor” and the blockchain user 302 as a “client.” An auditor could be restricted only to querying the ledger whereas a client could be authorized to deploy, invoke, and query certain types of chaincode.” (Para. 0045); “An event is emitted, to notify the client application that the transaction (invocation) has been immutably appended to the chain, as well as to notify whether the transaction was validated or invalidated.” (Para. 0044); “The blocks of the transaction are delivered from the ordering node 284 to all peer nodes 281-283 on the channel. The transactions 294 within the block are validated to ensure any endorsement policy is fulfilled and to ensure that there have been no changes to ledger state for read set variables since the read set was generated by the transaction execution.” (Para. 0044)).
Conclusion
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 nonprovisional extension fee (37 CFR 1.17(a)) 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.
The following prior art made of record and not relied upon is considered pertinent to applicant's disclosure: US20220222656A1 (Adham), discussing “generating a transaction comprising transaction details for each digital wallet, and wherein the transaction further comprises a plurality of outputs associated with additional digital wallets; sending a request to each digital wallet in the transaction to verify the transaction details for that digital wallet; receiving a signature from each digital wallet based on the request to verify the transaction details for that digital wallet; and upon receiving signatures from each of the digital wallets, broadcasting the transaction at a blockchain network. (Claim 20).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Justin A. Jimenez whose telephone number is (571) 270-3080. The examiner can normally be reached on 8:30 AM - 5:00 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, John W. Hayes can be reached on 571-272-6708. 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.
/Justin Jimenez/
Patent Examiner, Art Unit 3697
/ARI SHAHABI/Primary Examiner, Art Unit 3697
Prosecution Insights