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 .
This action is in response to the claims filed 6/28/2024. Claims 1-20 are pending with claims 1 (a method), 5 (a method), and 14 (a machine) are independent.
Double Patenting
A rejection based on double patenting of the “same invention” type finds its support in the language of 35 U.S.C. 101 which states that “whoever invents or discovers any new and useful process... may obtain a patent therefor...” (Emphasis added). Thus, the term “same invention,” in this context, means an invention drawn to identical subject matter. See Miller v. Eagle Mfg. Co., 151 U.S. 186 (1894); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Ockert, 245 F.2d 467, 114 USPQ 330 (CCPA 1957).
A statutory type (35 U.S.C. 101) double patenting rejection can be overcome by canceling or amending the claims that are directed to the same invention so they are no longer coextensive in scope. The filing of a terminal disclaimer cannot overcome a double patenting rejection based upon 35 U.S.C. 101.
Claims 5-20 is/are rejected under 35 U.S.C. 101 as claiming the same invention as that of claims 1-16 (in the same order) of prior U.S. Patent No. 11,611,439. This is a statutory double patenting rejection.
The claims are identical.
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 1-4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Long et al., “Scalable BFT Consensus Mechanism Through Aggregated Signature Gossip” (Presented at conference 2019-05), in view of Rizvi et al., US 10,848,549 (filed 2018-11), and Chander et al., “A Fault Resilient Consensus Protocol for Large Permissioned Blockchain Networks” (Presented at conference 2019-05).
As to claim 1, Long discloses a method comprising:
(“the newly elected validator committee will start proposing and settling new blocks from the latest guardian-finalized block” Long § III.A)
…
sending, by the validator computing device, the signature to a third validator computing device (“the guardian first sends out its current aggregated signature σi and signer vector c^i to all its neighbors….” Long § III.E) …
receiving, by the validator computing device, a second signature from the third validator computing device; (“… Then, if it has not considered the checkpoint as finalized, it waits for the signatures and signer vectors from all its neighbors” Long § III.E)
determining, by the validator computing device, whether the signature and the second signature agree on whether the candidate block is valid or not valid; (“Upon receiving all the signature and signer vectors, it checks the validity of (σj,c^j) received from neighboring node j using the BLS aggregated signature verification algorithm…. To guard against byzantine nodes, all the invalid signatures and their associated signer vectors are discarded for the next aggregation step.” Long § III.E) and
combining, by the validator computing device, the signature and the second signature to generate a combined signature if the signature and the second signature agree (“The aggregation step aggregates the BLS signature σj, and updates the signer vector c^j from the neighbors.” Long § III.E) or sending the signature to the block producer if the signature and the second signature do not agree. (alternative not required)
Long does not explicitly disclose:
receiving, at a validator computing device of a distributed network, a candidate block from a block producer, wherein the block producer is a second validator computing device of the distributed network;
determining, by the validator computing device, whether the candidate block is valid or not valid;
signing, by the validator computing device, an indication of whether the candidate block is valid or not valid to generate a signature;
… that is a sibling node to the validator computing device in a tree structure;
Rizvi discloses:
receiving, at a validator computing device of a distributed network, a candidate block from a block producer (See Rizvi Fig. 6A write requests for a new block), wherein the block producer is a second validator computing device of the distributed network;
(node d is a block producer, node a is a validator: “node 102 a, which has been designated as a representative of the first group 104 a, contacts 204 node 102 d, which has been designated as an emulator of the second group 104 b. Node 102 a retrieves an ordered grouping of node-level proposals for the second group of nodes 104b that was previously aggregated and ordered at virtual node 106b during round one of the consensus cycle.” Rizvi col. 10, ln. 40. See also the further steps Rizvi Figures 6-8 and associated description.)
… that is a sibling node to the validator computing device (“The representative may then broadcast that ordered grouping of group level proposals to other nodes 102 b-c in the first group of nodes 104 a. By doing this, all of the nodes in the first group of nodes 104 a have the same order for how write requests received at both the first group of nodes 104 a and the second group of nodes 104 b are to be processed to the shared data structure.” Rizvi col. 10, ln. 60. See also the further steps of Rizvi Figures 6-8 and associated description.) in a tree structure; (see Rizvi figures 2 and 3.)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Long with Rizvi by grouping the nodes in a tree according to physical proximity and performing the consensus, signature, operations intra-group before processing inter-group consensus. 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 Long with Rizvi in order to efficiently arrive at consensus with a large number of nodes, Rizvi col. 2, ln. 13.
Long in view of Rizvi does not explicitly disclose:
determining, by the validator computing device, whether the candidate block is valid or not valid;
signing, by the validator computing device, an indication of whether the candidate block is valid or not valid to generate a signature;
Chander discloses:
determining, by the validator computing device, whether the candidate block is valid or not valid; (“a newly proposed block from the leader is propagated to all the nodes in the blockchain network …. Once an intermediate node receives a propose message, the block is validated and the message is forwarded to all its children if (i) all the transactions inside the block are valid and follow the predefined serialization constraints” Chander § III.A) signing, by the validator computing device, (“this is done from the leaves of the tree upward to the root, with each non-leaf node aggregating signatures from its children along with its own signature and sending the short signature upwards.” Chander § III.A) an indication of whether the candidate block is valid or not valid to generate a signature; (“if (i) all the transactions inside the block are valid and follow the predefined serialization constraints” Chander § III.A)
A person of ordinary skill in the art before the effective filing date of the claimed invention would have combined Long in view of Rizvi with Chander by validating the blocks prior to signing the blocks. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to perform validation at the nodes of Long termed validators in order to ensure that the proposed blocks to be added to the blockchain are legitimate and will not compromise the data stored on the ledger.
As to claim 2, Long in view of Rizvi and Chander discloses the method of claim 1 and further discloses:
if the signature and the second signature agree: (“Upon receiving all the signature and signer vectors, it checks the validity of (σj,c^j) received from neighboring node j using the BLS aggregated signature verification algorithm…. To guard against byzantine nodes, all the invalid signatures and their associated signer vectors are discarded for the next aggregation step.” Long § III.E)
determining that the validator computing device is operating a virtual node (“previously aggregated and ordered at virtual node 106b during round one of the consensus cycle.” Rizvi col. 10, ln. 40.) at a top level of the tree structure; and (note Applicant’s specification ¶ 82 describing a “top level” as the level below the root of the tree)
(“this is done from the leaves of the tree upward to the root, with each non-leaf node aggregating signatures from its children along with its own signature and sending the short signature upwards.” Chander § III.A)
in response to determining that the validator computing device is operating a virtual node at a top level of the tree structure, sending the combined signatures (“this is done from the leaves of the tree upward to the root, with each non-leaf node aggregating signatures from its children along with its own signature and sending the short signature upwards.” Chander § III.A) to the block producer. (“a newly proposed block from the leader is propagated to all the nodes in the blockchain network ….” Chander § III.A)
As to claim 3, Long in view of Rizvi and Chander discloses the method of claim 1 and further discloses:
if the signature and the second signature agree: (“Upon receiving all the signature and signer vectors, it checks the validity of (σj,c^j) received from neighboring node j using the BLS aggregated signature verification algorithm…. To guard against byzantine nodes, all the invalid signatures and their associated signer vectors are discarded for the next aggregation step.” Long § III.E)
determining that the validator computing device is operating a virtual node (“previously aggregated and ordered at virtual node 106b during round one of the consensus cycle.” Rizvi col. 10, ln. 40.) at a level of the tree structure that is not a top level of the tree structure; and (“this is done from the leaves of the tree upward to the root, with each non-leaf node aggregating signatures from its children along with its own signature and sending the short signature upwards.” Chander § III.A)
in response to determining that the validator computing device is operating a virtual node (“previously aggregated and ordered at virtual node 106b during round one of the consensus cycle.” Rizvi col. 10, ln. 40.) that is not at the top level of the tree structure, (“this is done from the leaves of the tree upward to the root, with each non-leaf node aggregating signatures from its children along with its own signature and sending the short signature upwards.” Chander § III.A)
sending the combined signatures to a fourth validator computing device (“After the initialization, the guardian enters a loop. In each iteration, the guardian first sends out its current aggregated signature 𝜎𝑖 and signer vector 𝑐𝑖 to all its neighbors.” Long § III.E)operating a second virtual node that is a sibling node of the virtual node in the tree structure, (“The representative may then broadcast that ordered grouping of group level proposals to other nodes 102 b-c in the first group of nodes 104 a. By doing this, all of the nodes in the first group of nodes 104 a have the same order for how write requests received at both the first group of nodes 104 a and the second group of nodes 104 b are to be processed to the shared data structure.” Rizvi col. 10, ln. 60. See also the further steps of Rizvi Figures 6-8 and associated description.) and receiving a second combined signatures from the fourth validator computing device. (“it waits for the signatures and signer vectors from all its neighbors,” Long § III.E)
As to claim 4, Long in view of Rizvi and Chander discloses the method of claim 1 and further discloses:
receiving, from the block producer, a list of signatures; (“The protocol also uses function InitSignerVector() to initialize the signer vector 𝑐𝑖 , which is an n dimensional integer vector whose uth entry represents how many times the uth guardian has signed the aggregated signature.” Long § III.E) determining that the signature is not in the list of signatures; (“Here ciu is the uth entry of vector 𝑐𝑖 . Function 𝐼: true, false → {1,0} maps a true condition to 1, and false to 0. Condition 𝑐𝑖𝑢 > 0 indicates that node u has signed the aggregated signature that node i currently possesses at least once.” Long § III.E. node updates signing vector after signature is performed.) and sending the signature to the block producer. (“The aggregation step aggregates the BLS signature 𝜎𝑗, and updates the signer vector 𝑐𝑗 from the neighbors.” Long § III.E)
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See PTO-892, particularly:
Li et al., US 2019/0097790, discloses scalable byzantine fault-tolerant protocol with a tree broadcast.
Zhang et al., US 2019/0394175, discloses a permissioned blockchain with a broadcast tree for fine grained access control.
Rohrer et al., “Kadcast: A structured Approach to Broadcast in Blockchain Networks” disclosing broadcasting updates in subtrees.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL W CHAO whose telephone number is (571)272-5165. The examiner can normally be reached M, W-F 8-5.
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, Rupal Dharia can be reached at (571) 272-3880. 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.
/MICHAEL W CHAO/ Primary Examiner, Art Unit 2492