DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
2. Claims 1-20 are pending. Claims 1 and 11 are in independent forms. Claim 1 has been amended. Claims 2-20 are new.
Information Disclosure Statement
3. The information disclosure statements (IDS's) submitted on 06/27/2025 is in compliance with provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Drawings
4. The drawings filed on 03/04/2025 are accepted by the examiner.
Double Patenting
5. The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the claims at issue are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP §§ 706.02(l)(1) - 706.02(l)(3) for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/forms/. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
6. Claims 1 - 20 are provisionally rejected on the ground of non-statutory obviousness-type double patenting as being unpatentable over claims1, 3-11 and 13-20 of patent No. 12,244,731 in view of Zamani et al. (US 2020/0162264 A1), further in view of Matican et al. (US 2019/0342383 A1). Although the conflicting claims are not identical, they are not patentably distinct from each other because the instant application merely attempts to broaden the scope of the invention by omitting “wherein if the first RSIP clans do not affirm said transaction, the leader clan signature, and the oracle clan signature, then the oracle clan sends said transaction, the leader clan signature, and the oracle clan signature to a second plurality of randomly selected clans ("second RSIP clans") to affirm said transaction, wherein the second RSIP clans comprise a larger number of nodes than the first RSIP clans”. Since it has been held that omission of an element and its function in a combination where the remaining elements perform the same functions as before involves only routine skill in the art. In re Karison, 136 USPQ 184, Application 19/069509 is an obvious variant of patent No. 12,244,731.
respectively (see table below).
Instant Application 19/069509
Patent No. 12,244,731
Claim 1: An apparatus comprising a computing terminal accessing a decentralized computer network for conducting a transaction, said network comprising:
a plurality of clans comprising a plurality of nodes;
a plurality of tribes comprising the plurality of clans; an oracle clan, wherein the oracle clan is one of the plurality of clans; and
a leader clan;
wherein said leader clan is configured to receive said transaction and upon receipt of said transaction, determine whether to affirm said transaction;
if said transaction is affirmed by the leader clan, then the leader clan is configured to send said transaction and a leader clan signature to the oracle clan for affirmation;
if said transaction and the leader clan signature are affirmed by the oracle clan, then the oracle clan is configured to send (i) said transaction, (ii) the leader clan signature, (iii) and an oracle clan signature to a first plurality of randomly selected clans ("first RSIP clans");
wherein if said transaction, the leader clan signature, and the oracle clan signature are affirmed by the first RSIP clans, then the first RSIP clans are configured to send first RSIP signatures to the oracle clan;
wherein the oracle clan is configured to receive the first RSIP signature from the first RSIP clans and determine whether to affirm the first RSIP signatures;
wherein if the oracle clan affirms the first RSIP signatures, then the oracle clan is configured to send said transaction, the oracle clan signature, and the first RSIP signatures to the leader clan;
wherein the leader clan is configured to receive said transaction, the oracle clan signature, and the first RSIP signatures from the oracle clan and determine whether to affirm said transaction, the oracle clan signature, and the first RSIP signatures,
wherein if the leader clan affirms said transaction, the oracle clan signature, and the first RSIP signatures, then the leader clan broadcasts said transaction to the plurality of nodes, and
wherein the network is accessed by said computing terminal.
Claim 2: The decentralized computer network of claim 1, wherein if the first RSIP clans do not affirm said transaction, the leader clan signature, and the oracle clan signature, then the oracle clan sends said transaction, the leader clan signature, and the oracle clan signature to a second plurality of randomly selected clans ("second RSIP clans") to affirm said transaction, and the second RSIP clans comprise a larger number of nodes than the first RSIP clans.
Claim 3: The decentralized computer network of claim 2, wherein if said transaction, the leader clan signature, and the oracle clan signature are affirmed by the second RSIP clans, then the second RSIP clans are configured to send second RSIP signatures to the oracle clan, and the oracle clan is configured to receive the second RSIP signature from the second RSIP clans and determine whether to affirm the second RSIP signatures.
Claim 4: The decentralized computer network of claim 3, wherein if the oracle clan affirms the second RSIP signatures, then the oracle clan is configured to send said transaction, the oracle clan signature, and the second RSIP signatures to the leader clan; the leader clan is configured to receive said transaction, the oracle clan signature, and the second RSIP signatures from the oracle clan and determine whether to affirm said transaction, the oracle clan signature, and the second RSIP signatures, and if the leader clan affirms said transaction, the oracle clan signature, and the second RSIP signatures, then the leader clan broadcasts said transaction to the plurality of nodes.
Claim 5: The decentralized computer network of claim 1, wherein the leader clan determines whether to affirm said transaction based on blockchain data.
Claim 6: The decentralized computer network of claim 1, wherein the leader clan affirms said transaction when a threshold number of the plurality of nodes comprising the leader clan affirm the transaction, and the plurality of nodes comprising the leader clan is a protocol determined clan.
Claim 7: The decentralized computer network of claim 1, wherein the plurality of nodes store or reference said transaction in block data after the leader clan broadcasts said transaction.
Claim 8: The decentralized computer network of claim 1, wherein the first RSIP clans are configured to perform a sentiment analysis by affirming or not.
Claim 9: The decentralized computer network of claim 1, wherein each of the first RSIP clans comprise a same number of nodes.
Claim 10: The decentralized computer network of claim 1, wherein if the first RSIP clans do not affirm said transaction, the leader clan signature, and the oracle clan signature, then the oracle clan sends said transaction, the leader clan signature, and the oracle clan signature to the clans in the tribe or tribes of the clans in the first RSIP clans which are in the minority vote to affirm the transaction.
Claim 11: A process comprising:
Using a computer terminal to access a decentralized computer network to confirm a transaction by the decentralized computer network performing a method, said method comprising:
receiving, by a leader clan, a transaction confirmation request comprising said transaction;
determining, by the leader clan, whether to affirm said transaction;
sending, by the leader clan, said transaction and a leader clan signature to an oracle clan for affirmation based on said transaction being affirmed by the leader clan, wherein the oracle clan is one of a plurality of clans;
sending, by the oracle clan, (i) said transaction, (ii) the leader clan signature, and (iii) an oracle clan signature to a first plurality of randomly selected clans ("first RSIP clans") based on said transaction and the leader clan signature being affirmed by the oracle clan;
sending, by the first RSIP clans, first RSIP signatures to the oracle clan, based on said transaction, the leader clan signature, and the oracle clan signature are affirmed by the first RSIP clans;
receiving, by the oracle clan, the first RSIP signatures from the first RSIP clans;
determining, by the oracle clan, whether to affirm the first RSIP signatures;
sending, by the oracle clan, said transaction, the oracle clan signature, and the first RSIP signature to the leader clan, based on the oracle clan affirming the first RSIP signatures; receiving, by the leader clan, said transaction, the oracle clan signature, and the first RSIP signatures from the oracle clan;
determining, by the leader clan, whether to affirm said transaction, the oracle clan signature, and the first RSIP signatures; and
broadcasting, by the leader clan, said transaction to the plurality of nodes, based on the leader clan affirming said transaction, the oracle clan signature, and the first RSIP signatures.
Claim 12: The process of claim 11, wherein if the first RSIP clans do not affirm said transaction, the leader clan signature, and the oracle clan signature, then the oracle clan sends said transaction, the leader clan signature, and the oracle clan signature to a second plurality of randomly selected clans ("second RSIP clans") to affirm said transaction, and the second RSIP clans comprise a larger number of nodes than the first RSIP clans.
Claim 13: The process of claim 12, wherein based on said transaction, the leader clan signature, and the oracle clan signature being affirmed by the second RSIP clans, then the second RSIP clans send second RSIP signatures to the oracle clan, and the oracle clan receives the second RSIP signature from the second RSIP clans and determines whether to affirm the second RSIP signatures.
Claim 14: The process of claim 13, wherein based on the oracle clan affirming the second RSIP signatures, then the oracle clan sends said transaction, the oracle clan signature, and the second RSIP signatures to the leader clan; the leader clan receives said transaction, the oracle clan signature, and the second RSIP signatures from the oracle clan and determines whether to affirm said transaction, the oracle clan signature, and the second RSIP signatures, and based on the leader clan affirming said transaction, the oracle clan signature, and the second RSIP signatures, then the leader clan broadcasts said transaction to the plurality of nodes.
Claim 15: The process of claim 11, wherein the leader clan determines whether to affirm said transaction based on blockchain data.
Claim 16: The process of claim 11, wherein the leader clan affirms said transaction when a threshold number of the plurality of nodes comprising the leader clan affirm the transaction, and the plurality of nodes comprising the leader clan is a protocol determined clan.
Claim 17: The process of claim 11, wherein the plurality of nodes store said transaction in block data after the leader clan broadcasts said transaction.
Claim 18: The process of claim 11, wherein the first RSIP clans perform a sentiment analysis.
Claim 19: The process of claim 11, wherein each of the first RSIP clans comprise a same number of nodes.
Claim 20: The process of claim 11, wherein based on the first RSIP clans not affirming said transaction, the leader clan signature, and the oracle clan signature, the oracle clan sends said transaction, the leader clan signature, and the oracle clan signature to the clans in the tribe or tribes of the clans in the first RSIP clans which are in the minority vote to affirm the transaction.
Claim 1: An apparatus comprising a computing terminal accessing a decentralized computer network for conducting a transaction, said network comprising:
a plurality of clans comprising a plurality of nodes;
a plurality of tribes comprising the plurality of clans; an oracle clan, wherein the oracle clan is one of the plurality of clans; and
a leader clan;
wherein said leader clan is configured to receive said transaction and upon receipt of said transaction, determine whether to affirm said transaction;
if said transaction is affirmed by the leader clan, then the leader clan is configured to send said transaction and a leader clan signature to the oracle clan for affirmation;
if said transaction and the leader clan signature are affirmed by the oracle clan, then the oracle clan is configured to send (i) said transaction, (ii) the leader clan signature, (iii) and an oracle clan signature to a first plurality of randomly selected clans ("first RSIP clans");
wherein if said transaction, the leader clan signature, and the oracle clan signature are affirmed by the first RSIP clans, then the first RSIP clans are configured to send first RSIP signatures to the oracle clan;
wherein the oracle clan is configured to receive the first RSIP signature from the first RSIP clans and determine whether to affirm the first RSIP signatures;
wherein if the oracle clan affirms the first RSIP signatures, then the oracle clan is configured to send said transaction, the oracle clan signature, and the first RSIP signatures to the leader clan;
wherein the leader clan is configured to receive said transaction, the oracle clan signature, and the first RSIP signatures from the oracle clan and determine whether to affirm said transaction, the oracle clan signature, and the first RSIP signatures,
wherein if the leader clan affirms said transaction, the oracle clan signature, and the first RSIP signatures, then the leader clan broadcasts said transaction to the plurality of nodes,
wherein if the first RSIP clans do not affirm said transaction, the leader clan signature, and the oracle clan signature, then the oracle clan sends said transaction, the leader clan signature, and the oracle clan signature to a second plurality of randomly selected clans ("second RSIP clans") to affirm said transaction,
wherein the second RSIP clans comprise a larger number of nodes than the first RSIP clans, and
wherein the network is accessed by said computing terminal.
Claim 2: (Cancelled)
Claim 3: The decentralized computer network of claim 1, wherein if said transaction, the leader clan signature, and the oracle clan signature are affirmed by the second RSIP clans, then the second RSIP clans are configured to send second RSIP signatures to the oracle clan, and the oracle clan is configured to receive the second RSIP signature from the second RSIP clans and determine whether to affirm the second RSIP signatures.
Claim 4: The decentralized computer network of claim 3, wherein if the oracle clan affirms the second RSIP signatures, then the oracle clan is configured to send said transaction, the oracle clan signature, and the second RSIP signatures to the leader clan; the leader clan is configured to receive said transaction, the oracle clan signature, and the second RSIP signatures from the oracle clan and determine whether to affirm said transaction, the oracle clan signature, and the second RSIP signatures, and if the leader clan affirms said transaction, the oracle clan signature, and the second RSIP signatures, then the leader clan broadcasts said transaction to the plurality of nodes.
Claim 5: The decentralized computer network of claim 1, wherein the leader clan determines whether to affirm said transaction based on blockchain data.
Claim 6: The decentralized computer network of claim 1, wherein the leader clan affirms said transaction when a threshold number of the plurality of nodes comprising the leader clan affirm the transaction, and the plurality of nodes comprising the leader clan is a protocol determined clan.
Claim 7: The decentralized computer network of claim 1, wherein the plurality of nodes store or reference said transaction in block data after the leader clan broadcasts said transaction.
Claim 8: The decentralized computer network of claim 1, wherein the first RSIP clans are configured to perform a sentiment analysis by affirming or not.
Claim 9: The decentralized computer network of claim 1, wherein each of the first RSIP clans comprise a same number of nodes.
Claim 10: The decentralized computer network of claim 1, wherein if the first RSIP clans do not affirm said transaction, the leader clan signature, and the oracle clan signature, then the oracle clan sends said transaction, the leader clan signature, and the oracle clan signature to the clans in the tribe or tribes of the clans in the first RSIP clans which are in the minority vote to affirm the transaction.
Claim 11: A process, comprising:
using a computer terminal to access a decentralized computer network to confirm a transaction by the decentralized computer network performing a method, said method comprising:
receiving, by a leader clan, a transaction confirmation request comprising said transaction;
determining, by the leader clan, whether to affirm said transaction;
sending, by the leader clan, said transaction and a leader clan signature to an oracle clan for affirmation based on said transaction being affirmed by the leader clan, wherein the oracle clan is one of a plurality of clans;
sending, by the oracle clan, (i) said transaction, (ii) the leader clan signature, and (iii) an oracle clan signature to a first plurality of randomly selected clans ("first RSIP clans") based on said transaction and the leader clan signature being affirmed by the oracle clan;
sending, by the first RSIP clans, first RSIP signatures to the oracle clan, based on said transaction, the leader clan signature, and the oracle clan signature being affirmed by the first RSIP clans;
receiving, by the oracle clan, the first RSIP signatures from the first RSIP clans;
determining, by the oracle clan, whether to affirm the first RSIP signatures;
sending, by the oracle clan, said transaction, the oracle clan signature, and the first RSIP signature to the leader clan, based on the oracle clan affirming the first RSIP signatures;
receiving, by the leader clan, said transaction, the oracle clan signature, and the first RSIP signatures from the oracle clan;
determining, by the leader clan, whether to affirm said transaction, the oracle clan signature, and the first RSIP signatures; and
broadcasting, by the leader clan, said transaction to the plurality of nodes, based on the leader clan affirming said transaction, the oracle clan signature, and the first RSIP signatures,
wherein based on the first RSIP clans not affirming said transaction, the leader clan signature, and the oracle clan signature, the oracle clan sends said transaction, the leader clan signature, and the oracle clan signature to a second plurality of randomly selected clans ("second RSIP clans") to affirm said transaction, and the second RSIP clans comprise a larger number of nodes than the first RSIP clans.
Claim 12: (Cancelled)
Claim 13: The process of claim 11, wherein based on said transaction, the leader clan signature, and the oracle clan signature being affirmed by the second RSIP clans, then the second RSIP clans send second RSIP signatures to the oracle clan, and the oracle clan receives the second RSIP signature from the second RSIP clans and determines whether to affirm the second RSIP signatures.
Claim 14: The process of claim 13, wherein based on the oracle clan affirming the second RSIP signatures, then the oracle clan sends said transaction, the oracle clan signature, and the second RSIP signatures to the leader clan; the leader clan receives said transaction, the oracle clan signature, and the second RSIP signatures from the oracle clan and determines whether to affirm said transaction, the oracle clan signature, and the second RSIP signatures, and based on the leader clan affirming said transaction, the oracle clan signature, and the second RSIP signatures, then the leader clan broadcasts said transaction to the plurality of nodes.
Claim 15: The process of claim 11, wherein the leader clan determines whether to affirm said transaction based on blockchain data.
Claim 16: The process of claim 11, wherein the leader clan affirms said transaction when a threshold number of the plurality of nodes comprising the leader clan affirm the transaction, and the plurality of nodes comprising the leader clan is a protocol determined clan.
Claim 17: The process of claim 11, wherein the plurality of nodes store said transaction in block data after the leader clan broadcasts said transaction.
Claim 18: The process of claim 11, wherein the first RSIP clans perform a sentiment analysis.
Claim 19: The process of claim 11, wherein each of the first RSIP clans comprise a same number of nodes.
Claim 20: The process of claim 11, wherein based on the first RSIP clans not affirming said transaction, the leader clan signature, and the oracle clan signature, the oracle clan sends said transaction, the leader clan signature, and the oracle clan signature to the clans in the tribe or tribes of the clans in the first RSIP clans which are in the minority vote to affirm the transaction.
Claim Rejections - 35 USC § 103
6. 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.
7. Claims 1, 5-11, and 15-20 are rejected under 35 U.S.C. 103 as being unpatentable over Zamani et al. US Patent Application Publication No. 2020/0162264 (hereinafter Zamani) in view of Matican et al. US Patent Application Publication No. 2019/0342383 (hereinafter Matican). Regarding claim 1, Zamani discloses a decentralized computer network for conducting a transaction (Fig. 1), said network comprising:
“a plurality of clans comprising a plurality of nodes” (see Zamani par. 0011, a method performed by a node in a computer network including a plurality of nodes, each node having a node identifier, the method comprising: a) receiving, by the node, node identifiers from other nodes of the plurality of nodes in the computer network; b) determining, by the node, a plurality of node committees (clans) in a sampler graph comprising a plurality of nodes, wherein the node is present in a node committee in the plurality of node committees);
“a plurality of tribes comprising the plurality of clans” (see Zamani par. 0012, determining a plurality of node committees in a sampler graph comprising a plurality of nodes, wherein the node is present in a node committee in the plurality of node committees (tribes));
“an oracle clan, wherein the oracle clan is one of the plurality of clans” (see Zamani pars. 0113, In every consensus epoch, each participant solves a proof of work based on an epoch randomness obtained from the last state of the blockchain. The PoW's least-significant bits are used to determine the committees which coordinate (oracle clan) with each other to process transactions); and
“a leader clan” (see Zamani par. 0053, A committee may be capable of communicating with other committees. In some embodiments, a committee may include a node that can be a committee leader); wherein
“if said transaction is affirmed by the leader clan, then the leader clan is configured to send said transaction and a leader clan signature to the oracle clan for affirmation” (see Zamani par. 0139, when committee 1 C.sub.1 sends a message to committee 2 C.sub.2, a leader node of committee 1 C.sub.1 can receive a message including a digital signature from each of the plurality of nodes in committee 1 C.sub.1 and can aggregate the messages and can then transmit an aggregated message to a leader of committee 2 C.sub.2. The leader of committee 2 C.sub.2 can transmit the aggregated message to every node in committee 2 C.sub.2, wherein every node in committee 2 C.sub.2 can verify the digital signatures created by the plurality of nodes in committee 1 C.sub.1.);
“if said transaction and the leader clan signature are affirmed by the oracle clan, then the oracle clan is configured to send (i) said transaction, (ii) the leader clan signature, (iii) and an oracle clan signature to a first plurality of randomly selected clans ("first RSIP clans")” (see Zamani pars. 0165-0167, all nodes can sign the data (ID, s) of the e elected nodes that have the smallest h and then gossip the signatures in the group as a proof of election for the elected node. The signed data (ID, s) can be proof that the e elected nodes are actually elected nodes. Any given node can verify the signed data (ID, s) to determine if a node is an elected node. In some embodiments, after each subcommittee election, the nodes can perform subcommittee peer discovery. Every node can learn the identities of the elected nodes from each committee);
“wherein if said transaction, the leader clan signature, and the oracle clan signature are affirmed by the first RSIP clans, then the first RSIP clans are configured to send first RSIP signatures to the oracle clan” (see Zamani par. 0139, The leader of committee 2 C.sub.2 can transmit the aggregated message to every node in committee 2 C.sub.2, wherein every node in committee 2 C.sub.2 can verify the digital signatures created by the plurality of nodes in committee 1 C.sub.1.);
“wherein the oracle clan is configured to receive the first RSIP signature from the first RSIP clans and determine whether to affirm the first RSIP signatures” (see Zamani pars. 0193-0196, (a) The nodes of C run GenRand to choose a random string s. (b) All nodes of C sign s and propagate their signature in C. (c) For each node of C with public key PK, if H(s∥PK)≤2.sup.κ-e, then the node broadcasts a message to all members of C announcing itself as an elected member, where e determines the number of parties to elect. The leader can also propagate a proof (s that can be signed by f+1 of the members of C). (d) All members of C verify the announcements. The leaders in C can learn about all other leaders from other committees. If a committee announces more than e leaders, ignore the announcements and flag that committee as dishonest and set its leaders as empty).
“wherein if the oracle clan affirms the first RSIP signatures, then the oracle clan is configured to send said transaction, the oracle clan signature, and the first RSIP signatures to the leader clan” (see Zamani par. 0215, Each echo “echo<propose<H, r>>” message for the same proposed value in current round from a single node can be considered as one vote towards the validity of the header H. The node can then accept the value H and gossips the “accept<propose<H, r>>, proof” and removes it from the nodes pending blocks list. The proof can be a data item that indicates that the header H is proved to be valid. In some embodiments, the proof can be an aggregate of node signatures. For example, a node can sign the proposed message if it is valid and then send the signed proposed message to the leader node L.sub.r.);
“wherein the leader clan is configured to receive said transaction, the oracle clan signature, and the first RSIP signatures from the oracle clan and determine whether to affirm said transaction, the oracle clan signature, and the first RSIP signatures” (see Zamani par. 0013, receiving, by first node of the first committee, a solution to the proof of work process from the second node, wherein a plurality of nodes in the first committee verifies the solution; generating, by the first node of the first committee a random string, which is used by the first node to determine a second committee for the second node; introducing, by the first node to second committee, the second node, wherein the second committee displaces a node to allow the second node to join the second committee; and communicating, by the first node, information regarding the second node being in the second committee to other nodes in the computer network); and
“wherein if the leader clan affirms said transaction, the oracle clan signature, and the first RSIP signatures, then the leader clan broadcasts said transaction to the plurality of nodes” (see Zamani pars. 0144-0145, The setup phase can start by running a setup protocol where each node can join the system by solving a proof of work process to establish an identity. Then, the nodes can run a committee election protocol where they can determine a good committee, which can be referred to as a leader committee. The leader committee can then generate and distribute a sequence of random bits that can be used to establish k good committees {C.sub.1, . . . , C.sub.k}. In some embodiments, the setup phase can establish the computer network for the reconfiguration phase and the consensus phase).
Zamani does not explicitly discloses said leader clan is configured to receive said transaction and upon receipt of said transaction, determine whether to affirm said transaction.
However, in analogues art, Matican discloses said leader clan is configured to receive said transaction and upon receipt of said transaction, determine whether to affirm said transaction (see Matican pars. 0068-0069, The (elected) leader node of TServer Raft groups such as G1 is responsible for executing the requests received from user applications/systems. The requests are first received by Query Layer (shown in each of nodes 310A-310C) which in turn examines the request to identify the specific tablet/shard (assumed to be “tablet 1” having Raft group G1) where the read/write is to be performed. Query Layer then forwards the request to the leader node (assumed to be 332) for that specific tablet).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to Incorporate the teachings of Matican into the system of Zamani for a leader node decides the order in which the data item is to be committed, with the other nodes in the cluster using the same order to commit the write of the received data item (see Matican par. 0041).
Regarding claims 5 and 15, Zamani in view of Matican discloses the decentralized computer network of claim 1, the method of claim 11,
Zamani further discloses wherein the leader clan determines whether to affirm said transaction based on blockchain data (see Zamani par. 0010, Embodiments can enable an election of a leader committee in a computer network. The leader committee may be capable of partitioning a plurality of nodes in the computer network into sharding committees. Embodiments may allow new nodes to join the computer network. The sharding committees can receive interaction data which can be verified and stored in a shard of a blockchain).
Regarding claims 6 and 16, Zamani in view of Matican discloses the decentralized computer network of claim 1, the method of claim 11,
Zamani further discloses wherein the leader clan affirms said transaction when a threshold number of the plurality of nodes comprising the leader clan affirm the transaction, and the plurality of nodes comprising the leader clan is a protocol determined clan (see Zamani par. 0095, Once the leader committee is formed (i.e., after the setup phase 302), each node of the leader committee can establish a P2P network with the other nodes of the leader committee and can participate in a distributed random generation protocol, described below, to agree on the first epoch randomness, r.sub.0, which can be distributed by the nodes of the leader committee to all nodes in the computer network).
Regarding claims 7 and 17, Zamani in view of Matican discloses the decentralized computer network of claim 1, the method of claim 11,
Matican further discloses wherein the plurality of nodes store or reference said transaction in block data after the leader clan broadcasts said transaction (see Matican par. 0041, Upon receiving a write request for storing a data item, the leader node decides the order in which the data item is to be committed, with the other nodes in the cluster using the same order to commit the write of the received data item. As such, write requests are required to always be routed through the leader node. For read requests for retrieving data items, the leader node provides the latest values for the requested data items as is needed for a strong consistent data service, while the other nodes in the cluster provide potentially older, though timeline consistent, values).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to Incorporate the teachings of Matican into the system of Zamani for a leader node decides the order in which the data item is to be committed, with the other nodes in the cluster using the same order to commit the write of the received data item (see Matican par. 0041).
Regarding claims 8 and 18, Zamani in view of Matican discloses the decentralized computer network of claim 1, the method of claim 11,
Zamani further discloses wherein the first RSIP clans are configured to perform a sentiment analysis by affirming or not (see Zamani par. 0016, receiving, by a first node in a committee, an interaction request, the interaction request including interaction data from a client computer; incorporating, by the first node, the interaction data along with other interaction data associated with other client computers into a block comprising interaction data, wherein the block includes block parts; broadcasting, by the first node, the block to other nodes in the committee, wherein the other nodes in the committee verify the block; and incorporating the block into a blockchain managed by the committee).
Regarding claims 9 and 19, Zamani in view of Matican discloses the decentralized computer network of claim 1, the method of claim 11,
Zamani further discloses wherein each of the first RSIP clans comprise a same number of nodes (see Zamani par. 0160, After determining the plurality of node committees in the sampler graph comprising a plurality of nodes, the nodes of each committee can run the GenRand protocol or possibly any other suitable random value generation algorithm. Each node can generate a random string s. The nodes within a committee can generate the same random string s. For example, a first plurality of nodes in a first committee can generate a first random string, whereas a second plurality of nodes in a second committee can generate a second random string. In some embodiments, the random string s may be any suitable length).
Regarding claims 10 and 20, Zamani in view of Matican discloses the decentralized computer network of claim 1, the method of claim 11,
Zamani further discloses wherein if the first RSIP clans do not affirm said transaction, the leader clan signature, and the oracle clan signature, then the oracle clan sends said transaction, the leader clan signature, and the oracle clan signature to the clans in the tribe or tribes of the clans in the first RSIP clans which are in the minority vote to affirm the transaction (see Zamani pars. 0219-0223, a) Leader can gossip a “propose<H, r>” for a safe value of H for round r with a “proof” message that shows the value is safe, i.e., the proof contains f+1 votes for <H, r>. (b) The node that receives a valid “propose<H, r>” can gossip the “echo<propose<H, r>>” message. (c) If the node receives more than one valid “propose<H, r>” or “echo<propose<H, r>>” for different values H but same round number r from the leader, the node can consider the leader as dishonest and gossip “pending<H, r>”. (d) Else, if the node receives f+1 valid votes for <H, r> (In addition to votes the party receives before from the accept messages, each “echo<propose<H, r>>” messages for the same proposed value is in current round is considered as one vote), the node accepts the value H and gossips the “accept<propose<H, r>>,proof” and removes it from the nodes pending blocks list. (e) If a node receives a valid “accept<propose<H, r>>,proof” message from another party, the node changes the other nodes vote to <H, r>).
Regarding claim 11, Zamani discloses a method of confirming a transaction with a decentralized computer network, said method comprising:
“sending, by the leader clan, said transaction and a leader clan signature to an oracle clan for affirmation if said transaction is affirmed by the leader clan, wherein the oracle clan is one of a plurality of clans” (see Zamani par. 0139, when committee 1 C.sub.1 sends a message to committee 2 C.sub.2, a leader node of committee 1 C.sub.1 can receive a message including a digital signature from each of the plurality of nodes in committee 1 C.sub.1 and can aggregate the messages and can then transmit an aggregated message to a leader of committee 2 C.sub.2. The leader of committee 2 C.sub.2 can transmit the aggregated message to every node in committee 2 C.sub.2, wherein every node in committee 2 C.sub.2 can verify the digital signatures created by the plurality of nodes in committee 1 C.sub.1.);
“sending, by the oracle clan, (i) said transaction, (ii) the leader clan signature, and (iii) an oracle clan signature to a first plurality of randomly selected clans ("first RSIP clans") if said transaction and the leader clan signature are affirmed by the oracle clan” (see Zamani pars. 0165-0167, all nodes can sign the data (ID, s) of the e elected nodes that have the smallest h and then gossip the signatures in the group as a proof of election for the elected node. The signed data (ID, s) can be proof that the e elected nodes are actually elected nodes. Any given node can verify the signed data (ID, s) to determine if a node is an elected node. In some embodiments, after each subcommittee election, the nodes can perform subcommittee peer discovery. Every node can learn the identities of the elected nodes from each committee);
“sending, by the first RSIP clans, first RSIP signatures to the oracle clan, if said transaction, the leader clan signature, and the oracle clan signature are affirmed by the first RSIP clans” (see Zamani par. 0139, The leader of committee 2 C.sub.2 can transmit the aggregated message to every node in committee 2 C.sub.2, wherein every node in committee 2 C.sub.2 can verify the digital signatures created by the plurality of nodes in committee 1 C.sub.1.);
“receiving, by the oracle clan, the first RSIP signatures from the first RSIP clans; determining, by the oracle clan, whether to affirm the first RSIP signatures” (see Zamani par. 0013, receiving, by first node of the first committee, a solution to the proof of work process from the second node, wherein a plurality of nodes in the first committee verifies the solution; generating, by the first node of the first committee a random string, which is used by the first node to determine a second committee for the second node; introducing, by the first node to second committee, the second node, wherein the second committee displaces a node to allow the second node to join the second committee; and communicating, by the first node, information regarding the second node being in the second committee to other nodes in the computer network);
“sending, by the oracle clan, said transaction, the oracle clan signature, and the first RSIP signature to the leader clan, if the oracle clan affirms the first RSIP signatures” (see Zamani par. 0215, Each echo “echo<propose<H, r>>” message for the same proposed value in current round from a single node can be considered as one vote towards the validity of the header H. The node can then accept the value H and gossips the “accept<propose<H, r>>, proof” and removes it from the nodes pending blocks list. The proof can be a data item that indicates that the header H is proved to be valid. In some embodiments, the proof can be an aggregate of node signatures. For example, a node can sign the proposed message if it is valid and then send the signed proposed message to the leader node L.sub.r.);
“receiving, by the leader clan, said transaction, the oracle clan signature, and the first RSIP signatures from the oracle clan; determining, by the leader clan, whether to affirm said transaction, the oracle clan signature, and the first RSIP signatures” (see Zamani par. 0013, receiving, by first node of the first committee, a solution to the proof of work process from the second node, wherein a plurality of nodes in the first committee verifies the solution; generating, by the first node of the first committee a random string, which is used by the first node to determine a second committee for the second node; introducing, by the first node to second committee, the second node, wherein the second committee displaces a node to allow the second node to join the second committee; and communicating, by the first node, information regarding the second node being in the second committee to other nodes in the computer network); and
“broadcasting, by the leader clan, said transaction to the plurality of nodes, if the leader clan affirms said transaction, the oracle clan signature, and the first RSIP signatures” (see Zamani pars. 0144-0145, The setup phase can start by running a setup protocol where each node can join the system by solving a proof of work process to establish an identity. Then, the nodes can run a committee election protocol where they can determine a good committee, which can be referred to as a leader committee. The leader committee can then generate and distribute a sequence of random bits that can be used to establish k good committees {C.sub.1, . . . , C.sub.k}. In some embodiments, the setup phase can establish the computer network for the reconfiguration phase and the consensus phase).
Zamani does not explicitly discloses receiving, by a leader clan, a transaction confirmation request comprising said transaction; determining, by the leader clan, whether to affirm said transaction.
However, in analogues art, Matican discloses receiving, by a leader clan, a transaction confirmation request comprising said transaction; determining, by the leader clan, whether to affirm said transaction (see Matican pars. 0068-0069, The (elected) leader node of TServer Raft groups such as G1 is responsible for executing the requests received from user applications/systems. The requests are first received by Query Layer (shown in each of nodes 310A-310C) which in turn examines the request to identify the specific tablet/shard (assumed to be “tablet 1” having Raft group G1) where the read/write is to be performed. Query Layer then forwards the request to the leader node (assumed to be 332) for that specific tablet).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to Incorporate the teachings of Matican into the system of Zamani for a leader node decides the order in which the data item is to be committed, with the other nodes in the cluster using the same order to commit the write of the received data item (see Matican par. 0041).
Allowable Subject Matter
8. Claims 2-4 and 12-14 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
9. Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAMUEL AMBAYE whose telephone number is (571)270-7635. The examiner can normally be reached M-F 9:00 AM - 6:00 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, Jeffrey Pwu can be reached at (571) 272-6798. 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.
/SAMUEL AMBAYE/Examiner, Art Unit 2433
/JEFFREY C PWU/Supervisory Patent Examiner, Art Unit 2433
Prosecution Insights