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 .
DETAILED ACTION
1. This action is responsive to: an original application filed on 26 March 2026.
2. Claims 1-28 are currently pending and rejected.
Responses to the Argument
3. The applicant’s arguments filed on 26 March 2026 are moot in view of new ground of rejection rendered.
Claim Rejections - 35 USC § 103
4. 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 1-28 are rejected under 35 U.S.C §103 as being unpatentable over Bake et al. (US Publication No. 20200092085), hereinafter Bake and in view of Xiao et al. (CN Publication No. 109344630), hereinafter Xiao.
Regarding claim 1:
creating a candidate block of transaction data (Bake, ¶26-27), wherein producer nodes having a block generation status at a predetermined time for each round; determining whether the second node receives a candidate block before being promoted within the N-th round; if a candidate block is not received by the second node before being promoted, generating a candidate block including voting information within the last block of the blockchain to which a new block is to be connected; voting for accepting a generated candidate block as an approved block; and transmitting the candidate block and voting information to other nodes. According to a still further different aspect, the method may further comprise receiving, by the second node promoted in the N-th round, a candidate block generated by 7other node.
Bake does not explicitly suggest, determining a set of verifier nodes by identifying nodes of the blockchain network that have each created a respective block that has been included in the blockchain within a predetermined period prior to the creating of the candidate block; however, in a same field of endeavor Xiao discloses this limitation (Xiao, page 8, para.7, page 9, para 1, page 6, para.5),
and sending the candidate block to each of the verifier nodes for verification (Bake, ¶19), wherein determining whether a received candidate block is a valid candidate block may include determining whether to promote a node that has generated the received candidate block; and if the received candidate block is the block that a promoted node has generated, accepting the received candidate block as a valid candidate block.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to include the method of block verification of Bake with block generation based on time disclosed in Xiao because to improve service performance, stated by Xiao at para.14.
Regarding claim 2:
comprising using positions of blocks in the blockchain, or timestamps within blocks of the blockchain, to identify nodes of the blockchain network that have each created a respective block that has been included in the blockchain within the predetermined period (Bake, ¶79-80).
Regarding claim 3:
comprising receiving the candidate block of transaction data at each of the set of verifier nodes (Bake, ¶70).
Regarding claim 4:
comprising each of the verifier nodes verifying the candidate block by determining whether the candidate block meets one or more verification criteria (Bake, ¶32).
Regarding claim 5:
comprising, in response to determining that at least one of the set of verifier nodes has determined that the candidate block does not meet the verification criteria, rejecting the candidate block (Bake, ¶16).
Regarding claim 6:
comprising each of the verifier nodes outputting verification data indicating whether each of the verifier nodes has determined that the candidate block meets the verification criteria (Bake, ¶12).
Regarding claim 7:
wherein the verification data is readable by each of the verifier nodes (Bake, ¶20).
Regarding claim 8:
comprising each of the verifier nodes outputting verification data to a data server (Bake, ¶156).
Regarding claim 9:
wherein the data server is readable by one or more further nodes of the network in addition to the verifier nodes (Bake, ¶154).
Regarding claim 10:
wherein the one or more verification criteria comprise: one or more primary verification criteria, corresponding to one or more requirements that the candidate block must meet in order for the candidate block to be included in the blockchain (Bake, ¶31); and one or more secondary criteria, corresponding to one or more non-essential requirements that it is desirable, but not essential, for the candidate block to meet (Bake, ¶32).
Regarding claim 11:
comprising each of the verifier nodes categorising the candidate block into one of three categories: a first category, indicating that the candidate block meets all of the primary verification criteria and all of the secondary verification criteria; a second category, indicating that the candidate block meets all of the primary verification criteria but does not meet all of the secondary verification criteria (Bake, ¶104); or a third category, indicating that the candidate block does not meet all of the primary verification criteria (Bake, ¶16).
Regarding claim 12:
comprising, in response to a majority of the verifier nodes determining that the candidate block meets all of the primary verification criteria, and none of the verifier nodes determining that the candidate block does not meet all of the primary verification criteria, allowing the candidate block to be added to the blockchain (Bake, ¶146-147).
Regarding claim 13:
comprising, in response to a majority of the verifier nodes determining that the candidate block does not meet one or more of the primary verification criteria, rejecting the candidate block from inclusion in the blockchain (Bake, ¶149, ¶154).
Regarding claim 14:
comprising, in response to determining that i) a majority of the verifier nodes have determined that the candidate block meets all of the primary verification criteria, and ii) at least one of the verifier nodes has determined that the candidate block does not meet one or more of the primary verification criteria, one or each of the verifier nodes sending the candidate block to one or more further nodes of the plurality of nodes for further verification (Bake, ¶26, ¶31, 113).
Regarding claim 15:
wherein the one or more further nodes are selected at random from the plurality of nodes (Bake, ¶155).
Regarding claim 16:
comprising: identifying one or more dissenting verifier nodes that have made a different determination regarding whether the candidate block meets the verification criteria than a majority of the verifier nodes; and in response to identifying a dissenting verifier node, some or all of the other verifier nodes using evidence data output by the dissenting verifier node to determine whether the candidate block meets the verification data (Bake, ¶154, ¶104).
Regarding claim 17:
wherein the evidence data output by the dissenting verifier node indicates a reason for the determination made by the dissenting verifier node as to whether the candidate block meets the verification criteria (Bake, ¶92-93).
Regarding claim 18:
comprising the one or more verifier nodes sending the candidate block to one or more further nodes of the plurality of nodes for further verification after attempting to determine, using the evidence data output by the dissenting verifier node, whether the candidate block meets the verification criteria (Bake, ¶12).
Regarding claim 19:
wherein the predetermined period extends back in time from a time at which the candidate block was created, or from an end of a predetermined confirmation period that extends back in time from a time at which the candidate block was created (Bake, ¶15).
Regarding claim 20:
wherein the predetermined period corresponds to a constant number of block creations (Bake, ¶95).
Regarding claim 21:
comprising each of the set of verifier nodes receiving the candidate block of transaction data, and at least one of the set of verifier nodes subsequently ceasing to receive one or more subsequent candidate blocks of transaction data for verification (Bake, ¶15, ¶20).
Regarding claim 22:
comprising: the network rejecting candidate blocks of transaction data from a block-creating node of the plurality of nodes at least until the block-creating node has paid a creator deposit; the block-creating node paying a creator deposit; and the block-creating node creating a candidate block of transaction data (Bake, ¶88, ¶79).
Regarding claim 23:
comprising withholding some or all of the creator deposit from the block-creating node in response to determining that the candidate block created by the block-creating node has been rejected from inclusion in the blockchain (Bake, ¶79, ¶88).
Regarding claim 24:
comprising: the network preventing a block creating-node of the plurality of nodes from becoming a verifier node at least until the block-creating node has paid a behaviour deposit; the block-creating node paying a behaviour deposit; and the block-creating node creating a candidate block of transaction data (Bake, ¶95).
Regarding claim 25:
comprising: a node paying a behaviour deposit; the node determining that a candidate block meets the verification criteria; the network determining that the candidate block has been rejected; and the network withholding some or all of the behaviour deposit from the node (Bake, ¶147, ¶95).
Regarding claim 26:
A processing system for a node of a blockchain network, wherein the processing system is configured to (Bake, Abstract): create a candidate block of transaction data for inclusion in a blockchain hosted by the blockchain network (Bake, ¶26-27), wherein producer nodes having a block generation status at a predetermined time for each round; determining whether the second node receives a candidate block before being promoted within the N-th round; if a candidate block is not received by the second node before being promoted, generating a candidate block including voting information within the last block of the blockchain to which a new block is to be connected; voting for accepting a generated candidate block as an approved block; and transmitting the candidate block and voting information to other nodes. According to a still further different aspect, the method may further comprise receiving, by the second node promoted in the N-th round, a candidate block generated by other node.
Bake does not explicitly suggest, determine a set of verifier nodes by identifying nodes of the blockchain network that have each created a respective block that has been included in the blockchain within a predetermined period prior to the creating of the candidate block; however, in a same field of endeavor Xiao discloses this limitation (Xiao, page 8, para.7, page 9, para 1, page 6, para.5),
and send the candidate block to each of the verifier nodes for verification (Bake, ¶19), wherein determining whether a received candidate block is a valid candidate block may include determining whether to promote a node that has generated the received candidate block; and if the received candidate block is the block that a promoted node has generated, accepting the received candidate block as a valid candidate block.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to include the method of block verification of Bake with block generation based on time disclosed in Xiao because to improve service performance, stated by Xiao at para.14.
Regarding claim 27:
wherein the processing system is configured to determine the set of verifier nodes by inspecting a copy of the blockchain stored by the node in order to determine which nodes have created blocks that have been included in the blockchain within the predetermined period (Bake, ¶26-27).
Regarding claim 28:
A blockchain network comprising a plurality of nodes, wherein the blockchain network hosts a blockchain and is configured to perform the method of claim (Bake, abstract).
Conclusion
5. The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Monjour Rahim whose telephone number is (571)270-3890.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Shewaye Gelagay can be reached on 571-272-4219. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (in USA or CANANDA) or 571-272-1000.
/Monjur Rahim/
Patent Examiner
United States Patent and Trademark Office
Art Unit: 2436; Phone: 571.270.3890
E-mail: monjur.rahim@uspto.gov
Fax: 571.270.4890
Prosecution Insights