DETAILED ACTION
Acknowledgements
This Final Office Action is in reply to Applicant’s response filed September 11, 2025.
Claims 1–20 are currently pending.
Claims 1, 7-9, 12, 18-20 are currently amended.
Claims 1–20 have been examined.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim 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.
Claims 9 and 20 are rejected under 35 U.S.C. 112(a) 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 at the time the application was filed had possession of the claimed invention.
Regarding claims 9 and 20
Claim 9 recites, in relevant part:
The integrated circuit of claim 1, wherein the forwarder circuit is configured to suppress forwarding of a transaction in response to a validation result indicating that the transaction is invalid.
The specification is silent with respect to suppressing forwarding of a transaction. The closest disclosure appears to be the discussion at paragraph [00113] about a bypass path which is used when a transaction is not verified. However, the bypass path is between the scheduler 1110 and the transaction MVCC write block 625 and does not involve the forwarder circuit.
Claim 20 is substantially similar to claim 9 and is rejected for the same reason.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 4, 5, 7-12, 15, 16, 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Javaid et al. “Optimizing Validation Phase of Hyperledger Fabric” in view of Ren et al. (cited on August 28, 2024 892 form), in view of Cheng et al. (US 20220405623 A1), further in view of Wikipedia “Load balancing (computing)”, and in view of Burroughs et al. (US 20180365053 A1).
Regarding claim 1
Javaid teaches:
An integrated circuit (IC) for accelerating blockchain validation, the IC comprising: {III. A. “Each peer is run on a virtual machine which is allocated 16 Intel Xeon 4416 @ 2.1GHz vCPUs with 32GB RAM, 50GB hard disk, and configured with Ubuntu 16.04 LTS. All the machines were connected through a 1Gbps network.”}
Javaid teaches a validation process being executed on computing hardware, which at least implies an integrated circuit designed to carry out the process.
a scheduler circuit configured to receive a plurality of transactions to be committed to the blockchain; {II(A) “A block is created from the ordered transactions, and then broadcast to the peers” and “A non-endorsing peer only validates/commits blocks to the ledger.”}
The non-endorsing peers receive the block (plurality of transactions) to be committed to the ledger (blockchain).
a block processor to perform the blockchain validation, {figure 1 boxes 1-2}
PNG
media_image1.png
410
552
media_image1.png
Greyscale
wherein the block processor includes block verify circuitry {Figure 1 box 1}
[…] and block validate circuitry, {Figure 1 box 2}
a plurality of endorsement verification engine circuits configured to verify endorsements in the plurality of transactions, […] {Figure 1 “vscc”; I. “For the validation phase, recent optimizations [15], [23] include validation of transactions in parallel”; II. B. “Then, vscc (validation system chaincode) is run on each transaction where the endorsements are validated”}
Javaid teaches “vscc” verifying the transaction endorsements in parallel. Implemented on an integrated circuit this reads on a plurality of endorsement verification engine circuits.
a collector circuit configured to receive validation results of the plurality of transactions from the plurality of endorsement verification engine circuits {Figure 1, box labeled “2”}
Javaid does not teach the block verify circuitry performing signature matching of blocks, however Ren teaches:
for signature matching of blocks {page 3, fourth paragraph “In this stage, the committer actively receives the block broadcasted by the orderer and verifies the format and signature of the block.”}
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the block signature verification of Ren with the block processing of Javaid to avoid committing blocks with invalid signatures.
Javaid in view of Ren does not teach, however Cheng teaches:
A protocol processor to reformat data relating to one or more of the plurality of transactions and forward reformatted data related to the blockchain validation directly to {[0088] “The model data can be encoded or decoded by the shard explanation engine 330 and/or the shard driver engine [protocol processor] 310 as needed to change model data [reformat] to a format suitable for processing”}
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the data reformatting of Cheng with the transaction validation of Javaid in view of Ren so that the input data to the validation will be formatted correctly.
Javaid in view of Ren and further in view of Cheng does not teach, however Wikipedia “Load balancing (computing)” teaches:
wherein the scheduler circuit is configured to assign the plurality of endorsement verification engine circuits to the plurality of transactions based on a number of endorsements in each of the plurality of transactions; and
{Introduction “In computing, load balancing refers to the process of distributing a set of tasks over a set of resources (computing units)”; Problem Overview “Nature of tasks The efficiency of load balancing algorithms critically depends on the nature of the tasks. Therefore, the more information about the tasks is available at the time of decision making, the greater the potential for optimization. Size of tasks A perfect knowledge of the execution time of each of the tasks allows to reach an optimal load distribution […] One technique is to add some metadata to each task.”}
Javaid teaches using a set of resources (the parallel “vscc” of figure 1) to verify endorsements in transactions (tasks). Wikipedia teaches distributing tasks over resources based on the size of the task, using metadata. Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to apply the load balancing techniques of Wikipedia, which teaches distributing tasks over resources based on the size of the tasks (number of endorsements), to the validation process of Javaid. One would have been motivated to do so in order to maximize the efficiency of Javaid’s process (see Wikipedia, e.g., “with the aim of making their overall processing more efficient”).
Javaid in view of Ren in view of Cheng in view of Wikipedia does not teach, however Burroughs teaches:
a temporary storage coupled to an output of the collector circuit, the temporary storage configured to store a validation result associated with each transaction, {Fig. 1, 114; [0027] “Reordered queues [temporary storage] are used when there are one or more producers of work queuing up to communicate to multiple consumers with a requirement that the work (e.g., an ordered set of tasks) be dynamically balanced across the consumers and the results return from the consumers be restored to the original order.”; [0027] “Aspects of the invention are directed to offloading these software-processing tasks to a hardware manager.”} wherein the validation result is stored at a memory location indexed based on a transaction identifier associated with that transaction; and {[0040] “As for the task ID [transaction identifier] field, it is used to track a task's position or order relative to other tasks in the same workflow. According to an embodiment, the task ID stored in a task ID field is a numerical value that is sequentially assigned by the HQM. The sequence of task IDs may be unique to each workflow or may be shared between different workloads, so long as the assigned task IDs can be used to determine the ordering of tasks in the same workload.”}
PNG
media_image2.png
708
361
media_image2.png
Greyscale
a forwarder circuit coupled to the temporary storage, the forwarder circuit configured to output transactions and their associated validation results to a downstream commit path, wherein the forwarder circuit retrieves validation results from memory locations in the temporary storage using the transaction identifiers. {Fig. 1, [0027] “The reordered results 114 are then sent to the destination consumer(s) 116, which may perform further processing.”}
Javaid in view of Ren in view of Cheng in view of Wikipedia, as discussed above, teaches a transaction validation process using load balancing techniques to distribute tasks (transactions to validate) over a set of computing resources. Javaid teaches the transactions being ordered prior to validation (Javaid page 1 “The transaction flow in Fabric follows the execute-order-validate model, where a transaction is executed first, then ordered into a block, which is finally validated and committed to the ledger.”). Burroughs teaches using a reorder queue to restore the original order of task results after tasks have been distributed over a set of resources.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the reorder queue of Burroughs with the transaction validation of Javaid in view of Ren in view of Cheng in view of Wikipedia to restore the original ordering of transactions for downstream processes after distribution over a set of resources.
Regarding claim 4
Javaid teaches:
The integrated circuit of claim 1, further comprising:
a plurality of endorsement policy evaluator circuits configured to confirm the plurality of transactions have received the appropriate endorsements based on outputs of the plurality of endorsement verification engine circuits, wherein the plurality of endorsement policy evaluator circuits provide the validation results to the collector circuit. {Figure 1, “vscc”. See also page 2 column 2 first paragraph “Then, vscc (validation system chaincode) is run on each transaction where the endorsements are validated and the endorsement policy of the associated chaincode is evaluated.” and page 3-4 “Only the vscc operation benefits from multiple CPUs”}
The vscc contains the logic for verifying endorsement policies are satisfied (reads on have received the appropriate endorsements based on outputs of the plurality of endorsement verification engine circuits), and Javaid teaches doing it in parallel (reads on plurality of circuits).
Regarding claim 5
Javaid teaches:
The integrated circuit of claim 4, wherein a number of the plurality of endorsement policy evaluator circuits sets a maximum number of transactions that can be validated by the plurality of endorsement verification engine circuits in parallel.
The above limitation is implied by Javaid. As discussed above with respect to claim 1, Javaid teaches “vscc” (endorsement policy evaluator circuits) in parallel. A physical processor for carrying out the method, as taught by Javaid, would necessarily be limited to some finite number of transactions whose endorsements could be validated in parallel based on the number of “vscc” processors.
Regarding claim 7
The integrated circuit of claim 1, wherein the temporary storage is configured to receive validation results from the plurality of endorsement verification engine circuits in a manner that supports out-of-order storage of the validation results corresponding to different transactions.
This limitation is merely claiming an intended result of how the validation results are received. It specifies that the validation results are received in a way that achieves the result that they can be stored out-of-order. It does not specify a structural limitation on the temporary storage and therefore it is not given patentable weight.
Regarding claim 8
Javaid teaches:
The integrated circuit of claim 1, wherein the validation result stored in the temporary storage comprises a bit indicating whether the transaction was determined to be valid or invalid. {III E “If a transaction is ill-formed, then its flag is set to invalid.”; II B “In the final step 3, the block is committed. First, the entire block is written to the ledger with its transactions’ valid/invalid flags.”}
Javaid describes the validation result as a “flag”, which implies one bit per processed transaction.
Regarding claim 9
Javaid teaches:
The integrated circuit of claim 1, wherein the forwarder circuit is configured to suppress forwarding of a transaction in response to a validation result indicating that the transaction is invalid. {page 4 “This is addressed in step 3, where the mvcc checks are only applied to transactions that have been validated by the vscc operation, discarding all other invalid transactions.”}
Regarding claim 10
The above combination of Javaid in view of Ren in view of Cheng in view of Wikipedia does not teach the limitations of claim 10. However Wikipedia further teaches:
The integrated circuit of claim 1, wherein the scheduler circuit is configured to adjust, at runtime, its scheduling algorithm in response to a history of the validation results stored in the integrated circuit, wherein the scheduling algorithm is used to assign the plurality of endorsement verification engine circuits to the plurality of transactions. {Problem Overview “For this reason, there are several techniques to get an idea of the different execution times. First of all, in the fortunate scenario of having tasks of relatively homogeneous size, it is possible to consider that each of them will require approximately the average execution time. If, on the other hand, the execution time is very irregular, more sophisticated techniques must be used. One technique is to add some metadata to each task. Depending on the previous execution time for similar metadata [history of the validation results], it is possible to make inferences [adjust its scheduling algorithm] for a future task based on statistics.”}
Wikipedia teaches load balancing (assigning the engines) using the results of previous task executions. Wikipedia does not explicitly teach making the adjustments based on execution results at runtime. However, making the adjustment at runtime and making the adjustment offline are the only two possibilities, and it would have been obvious to try both techniques. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to further modify the circuit of Javaid in view of Ren in view of Cheng in view of Wikipedia with the inferences based on statistics of previous execution times in order to optimize the load balancing.
Regarding claim 11
Javaid teaches:
The integrated circuit of claim 1, wherein the integrated circuit comprises at least one of a system on a chip (SoC), a field programmable gate array (FPGA), or an application specific integrated circuit (ASIC).
A processor designed for an application such as a validation process, as discussed above with respect to claim 1, implies an application specific integrated circuit, since an application specific integrated circuit is simply an integrated circuit designed for a specific application and processor/computing unit implies an integrated circuit.
Regarding claims 12, 15, 16, 18-20
Claims 12, 15, 16, 18-20 are substantially similar to claims 1, 4, 5, 7-9 respectively, and are treated the same with respect to prior art rejections.
Claims 2 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Javaid in view of Ren in view of Cheng in view of Wikipedia in view of Burroughs as applied to claims 1 and 12 above, and further in view of Stack Overflow “How to sign a Hyperledger Fabric transaction at web application client side?”.
Regarding claim 2
Javaid teaches:
performs version check and {II. B. “In step 2, mvcc (multi-version concurrency control) check is applied.”}
commits write keys to a state database. {II. B. paragraph 1 “The read set is the keys accessed and their version numbers, while the write set is the keys to be updated with their new values.”; last paragraph “Then, the write sets of the valid transactions are committed to the state database.”}
The combination of Javaid in view of Ren in view of Cheng in view of Wikipedia in view of Burroughs does not teach, however Stack Overflow “How to sign a Hyperledger Fabric transaction at web application client side?” teaches:
The integrated circuit of claim 1, wherein the block validate circuitry verifies signatures of each of the plurality of transactions and {“How to sign a Hyperledger Fabric transaction at web application client side?” “5. Individual user's key/certificate should be used to sign the transaction going to Blockchain.”}
Since Stack Overflow teaches a Hyperledger Fabric transaction containing a signature, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to verify the signature during the transaction validation of Javaid in view of Ren in view of Cheng in view of Wikipedia in view of Burroughs to avoid committing transactions with invalid signatures.
Regarding claim 13
Claim 13 is substantially similar to claim 2 and is treated the same with respect to prior art rejections.
Claims 3 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Javaid in view of Ren in view of Cheng in view of Wikipedia in view of Burroughs in view of Stack Overflow as applied to claims 2 and 13 above, and further in view of Stack Overflow “Data validation: fail fast, fail early vs. complete validation”.
Regarding claim 3
Javaid in view of Ren in view of Cheng in view of Wikipedia in view of Burroughs in view of Stack Overflow “How to sign a Hyperledger Fabric transaction at web application client side?” does not teach, however Stack Overflow “Data validation: fail fast, fail early vs. complete validation” teaches:
The integrated circuit of claim 2, further comprising:
a bypass path coupled to the scheduler circuit that bypasses the plurality of endorsement verification engine circuits, wherein the scheduler circuit is configured to use the bypass path when one of a plurality of transaction verify block circuits indicates a transaction is invalid, wherein the bypass path indicates to a downstream circuit to discard data corresponding to the transaction that is invalid. {Data validation: fail fast, fail early vs. complete validation “Regarding data validation, I've heard that the options are to ‘fail fast, fail early’ or ‘complete validation’. The first approach fails on the very first validation error, whereas the second one builds up a list of failures and presents it.”}
As discussed above with respect to claim 2, Javaid in view of Ren in view of Cheng in view of Wikipedia “Load balancing (computing)” in view of Burroughs in view of Stack Overflow “How to sign a Hyperledger Fabric transaction at web application client side?” teaches “tx validation” for verifying transactions (transaction verify block circuits), followed by a load balancer, followed by “vscc” (endorsement verification engine circuits). It does not teach bypassing the load balancer and “vscc” when “tx validation” fails.
However, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the ‘fail fast, fail early’ validation of Stack Overflow with the validation process above, and therefore skip the load balancer and endorsement verification (“vscc”) when the signature validation (“tx validation”) fails, because Stack Overflow teaches a general validation technique which reduces computation.
“Wherein the bypass path indicates…” is not given patentable weight because it is an intended result of the claimed structure.
Regarding claims 14
Claim 14 is substantially similar to claim 3 and is treated the same with respect to prior art rejections.
Claims 6 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Javaid in view of Ren in view of Cheng in view of Wikipedia in view of Burroughs as applied to claims 1 and 12 above, and further in view of Wikipedia “Instruction cycle”.
Regarding claim 6
Javaid in view of Ren in view of Cheng in view of Wikipedia “Load balancing (computing)” in view of Burroughs teaches the limitations of claims 1 and 12 above but does not teach the limitations of claims 6 and 17
Nonetheless, Wikipedia “Instruction cycle” teaches:
The integrated circuit of claim 1, wherein the scheduler circuit is configured to:
determine that during a first cycle not all of the endorsements for a first transaction of the plurality of transactions were validated by the plurality of endorsement verification engine circuits; and
assign a number of the plurality of endorsement verification engine circuits during a second, subsequent cycle to validate the remaining endorsements of the first transaction. {Introduction “In simpler CPUs, the instruction cycle is executed sequentially, each instruction being processed before the next one is started.”}
“Instruction cycle” teaches a processor operates in cycles and accomplishes a finite amount of computation each cycle and proceeds with remaining computation in subsequent cycles. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the integrated circuit of Javaid in view of Ren in view of Cheng in view of Wikipedia “Load balancing (computing)” in view of Burroughs with the teachings of “Instruction cycle” to construct the integrated circuit such that it validates in cycles and proceeds with any remaining validations in subsequent cycles.
Regarding claim 17
Claim 17 is substantially similar to claim 6 and is treated the same with respect to prior art rejections.
Response to Arguments
35 USC § 103
Applicant argues Burroughs does not teach or suggest a temporary storage because it does not teach a persistent memory structure indexed by a transaction ID. However, Burroughs states [0027] “The generated results are then reordered by a reordering logic 112 to restore the order of the original work requests” which suggests the generated results are stored at least temporarily or else it wouldn’t make sense to describe them as having been “reordered”. Figure 1 further suggests this by showing the tasks in order at 114 (where the numbers appear to represent task IDs). The task ID of Burroughs has been mapped to the claimed transaction ID which, as claimed, is used for nothing more than putting the transactions in order in the temporary storage and is exactly the same role served by the task ID of Burroughs ([0040] “As for the task ID field, it is used to track a task's position or order relative to other tasks”).
Applicant argues Burroughs fails to disclose forwarder circuitry as claimed because Burroughs merely discusses programmable routing within a datapath for sending transactions through validation engines and has no relation to validation-result pairing and retrieval logic implemented as a dedicated block that retrieves those results using transaction IDs. However, with respect to “forwarder circuity” and “a dedicated block,” the claim recitations of a “forwarder circuit,” “collector circuit.” etc., are interpreted as referring to mere labels for logical divisions of processing hardware. Burroughs discusses implementing such features using processing hardware ([0027] “Aspects of the invention are directed to offloading these software-processing tasks to a hardware manager.”). Therefore, the art merely needs to teach the relevant functionality in order to teach the claim. Burroughs (fig. 1, 116) teaches forwarding the data downstream, and memory is generally accessed by locations (the index / transaction ID of the claim). Additionally, it is noted that this argument goes beyond the claim language because the claim does not mention validation-result pairing.
Applicant argues “the claimed commit path and validation result retrieval logic reflect the requirements of permissioned blockchain protocols where explicit transaction approval data is retained and processed in a controlled sequence. Burroughs provides no such disclosure of validation result management.” It is unclear what claim language this argument refers to or if it intended as a separate argument from the prior argument. The claim does not reference validation result management and the claimed commit path is merely some downstream processing which the results of the claimed process are output to.
Applicant argues “dependent claim 7 recites that the temporary storage is configured to support out-of-order storage of validation results corresponding to different transactions. […] Burroughs does not teach or suggest that individual validation results may arrive and be stored out-of-order.” However, this is merely claiming a capability of the temporary storage without claiming a function performed by the temporary storage or any other structural limitation. It is interpreted as an intended result not given patentable weight.
Applicant argues “dependent claim 8 adds that the validation result stored in temporary storage comprises a bit indicating whether the transaction was valid or invalid. This reflects a low-overhead result encoding […]. Burroughs does not specify the form or structure of the validation result.” However, this limitation is similar to previous claim 8 and is also taught by Javaid, which refers to the validation result as a “flag”.
Applicant argues “dependent claim 9 recites that the forwarder circuit is configured to suppress forwarding of a transaction in response to a validation result indicating invalidity. […] Burroughs does not teach or suggest such conditional forwarding logic.” However, this limitation is taught by Javaid which discusses discarding transactions marked as invalid (page 4 “mvcc checks are only applied to transactions that have been validated by the vscc operation, discarding all other invalid transactions.”).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SCOTT MICHAEL DIROMA whose telephone number is (571)272-6430. The examiner can normally be reached Monday - Friday 12:30 pm - 8:30 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Patrick McAtee can be reached on (571) 272-7575. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/S.M.D./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698
Prosecution Insights