DETAILED ACTION
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 .
Response to Arguments
2. Applicant's arguments filed 05/14/2025 with respect to the rejection(s) of claim(s) 1-20 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made.
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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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-8, and 12-20 are rejected under 35 U.S.C. 103 as being unpatentable over Viale et al. (US 20200387395 A1), in view of Bhagavatha et al. (US 20210326867A1), and further and in view of Kawahara et al. (US 20200220770 A1).
5. Regarding claims 1, 15 and 20, Viale discloses a block chain-based block consensus method (A block chain-based block consensus apparatus, the apparatus comprising: processing circuitry configured to, A non-transitory computer-readable storage medium, storing instructions which when executed by a processor cause the processor to perform), (Para. 0088-0089; and Para. 0040-0041, This application can utilize a ledger that is a sequenced, tamper-resistant record of all state transitions of a blockchain. State transitions may result from chaincode invocations (i.e., transactions) submitted by participating parties (e.g., client nodes, ordering nodes, endorser nodes, peer nodes, etc.). Each participating party (such as a peer node) can maintain a copy of the ledger. A transaction may result in a set of asset key-value pairs being committed to the ledger as one or more operands, such as creates, updates, deletes, and the like. The ledger includes a blockchain (also referred to as a chain) which is used to store an immutable, sequenced record in blocks. The ledger also includes a state database which maintains a current state of the blockchain. This application can utilize a chain that is a transaction log which is structured as hash-linked blocks, and each block contains a sequence of N transactions where N is equal to or greater than one. The block header includes a hash of the block's transactions, as well as a hash of the prior block's header. In this way, all transactions on the ledger may be sequenced and cryptographically linked together. Accordingly, it is not possible to tamper with the ledger data without breaking the hash links. A hash of a most recently added blockchain block represents every transaction on the chain that has come before it, making it possible to ensure that all peer nodes are in a consistent and trusted state. The chain may be stored on a peer node file system (i.e., local, attached storage, cloud, etc.), efficiently supporting the append-only nature of the blockchain workload).
comprising: acquiring a proposal block generated in an Nth round with a block height of M, and performing validity verification on the proposal block, M and N both being positive integers; (Para. 0098-0099, FIG. 2B illustrates an example of a blockchain transactional flow 250 between nodes of the blockchain in accordance with an example embodiment. Referring to FIG. 2B, the transaction flow may include a transaction proposal 291 sent by an application client node 260 to an endorsing peer node 281. The endorsing peer 281 may verify the client signature and execute a chaincode function to initiate the transaction. The output may include the chaincode results, a set of key/value versions that were read in the chaincode (read set), and the set of keys/values that were written in chaincode (write set). The proposal response 292 is sent back to the client 260 along with an endorsement signature, if approved. The client 260 assembles the endorsements into a transaction payload 293 and broadcasts it to an ordering service node 284. The ordering service node 284 then delivers ordered transactions as blocks to all peers 281-283 on a channel. Before committal to the blockchain, each peer 281-283 may validate the transaction. For example, the peers may check the endorsement policy to ensure that the correct allotment of the specified peers have signed the results and authenticated the signatures against the transaction payload 293. Referring again to FIG. 2B, the client node 260 initiates the transaction 291 by constructing and sending a request to the peer node 281, which is an endorser. The client 260 may include an application leveraging a supported software development kit (SDK), which utilizes an available API to generate a transaction proposal. The proposal is a request to invoke a chaincode function so that data can be read and/or written to the ledger (i.e., write new key value pairs for the assets). The SDK may serve as a shim to package the transaction proposal into a properly architected format (e.g., protocol buffer over a remote procedure call (RPC)) and take the client's cryptographic credentials to produce a unique signature for the transaction proposal.
and based on the first consensus result being a consensus pass result, acquiring the target execution result mapped by the block hash of the proposal block in the memory, and storing the proposal block and the target execution result to a block chain, (Para. 0037-0038, In one embodiment the application utilizes a decentralized database (such as a blockchain) that is a distributed storage system, which includes multiple nodes that communicate with each other. The decentralized database includes an append-only immutable data structure resembling a distributed ledger capable of maintaining records between mutually untrusted parties. The untrusted parties are referred to herein as peers or peer nodes. Each peer maintains a copy of the database records and no single peer can modify the database records without a consensus being reached among the distributed peers. For example, the peers may execute a consensus protocol to validate blockchain storage transactions, group the storage transactions into blocks, and build a hash chain over the blocks. This process forms the ledger by ordering the storage transactions, as is necessary, for consistency. This application can utilize a blockchain that operates arbitrary, programmable logic, tailored to a decentralized storage scheme and referred to as “smart contracts” or “chaincodes.” In some cases, specialized chaincodes may exist for management functions and parameters which are referred to as system chaincode. The application can further utilize smart contracts that are trusted distributed applications which leverage tamper-proof properties of the blockchain database and an underlying agreement between nodes, which is referred to as an endorsement or endorsement policy. Blockchain transactions associated with this application can be “endorsed” before being committed to the blockchain while transactions, which are not endorsed, are disregarded. An endorsement policy allows chaincode to specify endorsers for a transaction in the form of a set of peer nodes that are necessary for endorsement. When a client sends the transaction to the peers specified in the endorsement policy, the transaction is executed to validate the transaction. After validation, the transactions enter an ordering phase in which a consensus protocol is used to produce an ordered sequence of endorsed transactions grouped into blocks).
executing an application based on transaction data in the proposal block to obtain a target execution result, and storing a block hash of the proposal block and the target execution result in a memory, the memory including N execution results with the block height of M, the N execution results including the target execution result, (Para. 0041-0042, This application can utilize a chain that is a transaction log which is structured as hash-linked blocks, and each block contains a sequence of N transactions where N is equal to or greater than one. The block header includes a hash of the block's transactions, as well as a hash of the prior block's header. In this way, all transactions on the ledger may be sequenced and cryptographically linked together. Accordingly, it is not possible to tamper with the ledger data without breaking the hash links. A hash of a most recently added blockchain block represents every transaction on the chain that has come before it, making it possible to ensure that all peer nodes are in a consistent and trusted state. The chain may be stored on a peer node file system (i.e., local, attached storage, cloud, etc.), efficiently supporting the append-only nature of the blockchain workload. The current state of the immutable ledger represents the latest values for all keys that are included in the chain transaction log. Since the current state represents the latest key values known to a channel, it is sometimes referred to as a world state. Chaincode invocations execute transactions against the current state data of the ledger. To make these chaincode interactions efficient, the latest values of the keys may be stored in a state database. The state database may be simply an indexed view into the chain's transaction log, it can therefore be regenerated from the chain at any time. The state database may automatically be recovered (or generated if needed) upon peer node startup, and before transactions are accepted.; and Para. 0103, The blocks of the transaction are delivered from the ordering node 284 to all peer nodes 281-283 on the channel. The transactions 294 within the block are validated to ensure any endorsement policy is fulfilled and to ensure that there have been no changes to ledger state for read set variables since the read set was generated by the transaction execution. Transactions in the block are tagged as being valid or invalid. Furthermore, in step 295 each peer node 281-283 appends the block to the channel's chain, and for each valid transaction the write sets are committed to current state database. An event is emitted, to notify the client application that the transaction (invocation) has been immutably appended to the chain, as well as to notify whether the transaction was validated or invalidated.)
Viale does not explicitly disclose performing two consecutive rounds of consensus voting processing on the proposal block to obtain a first consensus result, a second round of the two consecutive rounds of consensus voting processing being performed on the proposal block based on a voting result of a first round of the two consecutive rounds of consensus voting processing on the proposal block being larger than a pre-defined threshold value.
However, Bhagavatha teaches performing two consecutive rounds of consensus voting processing on the proposal block to obtain a first consensus result, a second round of the two consecutive rounds of consensus voting processing being performed on the proposal block based on a voting result of a first round of the two consecutive rounds of consensus voting processing on the proposal block being larger than a pre-defined threshold value, (Para. 0082-0084, FIG. 9 illustrates an example method 900 for committing a block to the blockchain, according to one embodiment. In the example embodiment shown in FIG. 9, the method 900 begins by identifying 910 a block that is ready to be counted. A block can be identified 910 as ready to be counted by having accumulated at least pre-commit threshold number of pre-commit signatures (e.g., signatures from more than two-thirds of the total number of Validators 210). The Validators 210 may periodically check uncommitted blocks to determine whether they have accumulated the required number of signatures. The Validators 210 may do this independently and similarly proceed with the commitment phase independently. As described previously, the Validators 210 need not communicate directly to reach consensus. The Validator 210 validates 920 each pre-commit signature using the corresponding verification key (the public key of the Validator that provided the pre-commit signature in question). Assuming sufficient pre-commit signatures are successfully validated 920 (e.g., more than two-thirds of the total number of Validators 210), the Validator determines 930 whether the pre-commit signature is conditional. If the pre-commit signature is conditional, the Validator 210 signs 940 the block conditionally. Otherwise, the Validator 945 signs the block unconditionally. If the number of commit signatures for the block exceeds a commit threshold, the block is committed 950 to the blockchain. In other words, if a sufficient number of Validators 210 have signed the block, it is hardened. In one embodiment, where Byzantine fault tolerance is used, the commit threshold is two-thirds of the total number of Validators 210. At this stage, the block is ready for sealing, as described previously with reference to FIG. 5.; and Para. 0064, After a block has been pre-committed 520, the block is ready for counting. This process is also referred to as commitment 530. Since each Validator 210 signs the block asynchronously, no assumptions can be made on when the block is ready for counting. Therefore, the Validators 210 scan for blocks for commit readiness, indicated by the number of pre-commit signatures for a block exceeding a pre-commit threshold. In embodiments using Byzantine fault tolerance, if the number of pre-commit signatures for a block is at least (⅔+1) of the number of Validators 210, the block is determined to be ready for the commit process 530. In other embodiments, other validation thresholds may be used.; and Para. 0022, In a further embodiment, a Validator retrieves transactions corresponding to reduced representations (e.g., transaction hashes) included in a distributed ledger (e.g., in a block of a blockchain) and performs validation tests on at least some (e.g., all) of the transactions. Based on the validation tests, the Validator applies a pre-commit signature to the block in conjunction with an indication of whether the pre-commit signature is conditional or unconditional.)
One of ordinary skill in the art would have recognized that applying the known technique of Bhagavatha to the known invention of Viale would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate consensus voting features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to performing two consecutive rounds of consensus voting processing on the proposal block to obtain a first consensus result, a second round of the two consecutive rounds of consensus voting processing being performed on the proposal block based on a voting result of a first round of the two consecutive rounds of consensus voting processing on the proposal block being larger than a pre-defined threshold value results in an improved invention because applying said technique will ensure that transactions are executed concurrently with consensus voting, thus improving the overall performance of the invention.
Viale as modified does not explicitly disclose the execution of the application based on the transaction data in the proposal block being performed concurrently with at least a portion of the two consecutive rounds of consensus voting processing.
However, Kawahara teaches the execution of the application based on the transaction data in the proposal block being performed concurrently with at least a portion of the two consecutive rounds of consensus voting processing, (Para. 0032-0033, A blockchain operates arbitrary, programmable logic tailored to a decentralized storage scheme and referred to as “smart contracts” or “chaincodes.” In some cases, specialized chaincodes may exist for management functions and parameters which are referred to as system chaincode. Smart contracts are trusted distributed applications which leverage tamper-proof properties of the blockchain database and an underlying agreement between nodes which is referred to as an endorsement policy. In general, blockchain transactions typically must be “endorsed” before being committed to the blockchain while transactions which are not endorsed are disregarded. A typical endorsement policy allows chaincode to specify endorsers for a transaction in the form of a set of peer nodes that are necessary for endorsement. When a client sends the transaction to the peers specified in the endorsement policy, the transaction is executed to validate the transaction. After validation, the transactions enter an ordering phase in which a consensus protocol is used to produce an ordered sequence of endorsed transactions grouped into blocks. Examples of the endorsement polices are shown here. In one example, T(2, p1, p2, p3). In the above example, the function denoted as “T( . . . )” is called a threshold function. The first argument of the threshold function is a threshold, which defines the criteria of a consensus. The rest of the arguments consists a list of peer nodes. The endorsements from the peer nodes in the list are examined. If the number of the endorsements which contains the same execution result as a value exceeds the threshold, then the threshold function returns the endorsement. In total, this endorsement policy means that a consensus is made when there are two or more endorsements from the list of peers, p1, p2 and p3 and those endorsements are the same. The threshold function works like a voting; the threshold parameter corresponds to a quorum and the list of the peer nodes consist a set of voters. An endorsement policy can be further complicated by combining multiple threshold functions. For example, T(2, T(1, p1, p2), T(1, p3, p4)). In this case, a consensus is made when there are one or more endorsements from a group of peer nodes p1 and p2, and one or more endorsements from another group of peer nodes p3 and p4, and two endorsements from the threshold functions T(1, p1, p2) and T(1, p3, p4) and both endorsements are the same.; and Para. 0098, When the ordering service 710 initializes a new block 730, the new block 730 may be broadcast to committing peers (e.g., blockchain nodes 711, 712, and 713). In response, each committing peer validates the transaction within the new block 730 by checking to make sure that the read set and the write set still match the current world state in the state database 724. Specifically, the committing peer can determine whether the read data that existed when the endorsers simulated the transaction is identical to the current world state in the state database 724. When the committing peer validates the transaction, the transaction is written to the blockchain 722 on the distributed ledger 720, and the state database 724 is updated with the write data from the read-write set. If a transaction fails, that is, if the committing peer finds that the read-write set does not match the current world state in the state database 724, the transaction ordered into a block will still be included in that block, but it will be marked as invalid, and the state database 724 will not be updated.)
One of ordinary skill in the art would have recognized that applying the known technique of Kawahara to the known invention of Viale as modified would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate consensus voting features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include the execution of the application based on the transaction data in the proposal block being performed concurrently with at least a portion of the two consecutive rounds of consensus voting processing result of a first round of the two consecutive rounds of consensus voting processing on the proposal block being larger than a pre-defined threshold value results in an improved invention because applying said technique will ensure that transactions are executed concurrently with consensus voting, thus improving the overall performance of the invention.
6. Regarding claims 2 and 16, Viale discloses wherein the executing the application based on the transaction data comprises: based on a validity verification result of the validity verification performed on the proposal block being a valid result, executing the application based on the transaction data in the proposal block to obtain the target execution result, (Para. 0098-0100, FIG. 2B illustrates an example of a blockchain transactional flow 250 between nodes of the blockchain in accordance with an example embodiment. Referring to FIG. 2B, the transaction flow may include a transaction proposal 291 sent by an application client node 260 to an endorsing peer node 281. The endorsing peer 281 may verify the client signature and execute a chaincode function to initiate the transaction. The output may include the chaincode results, a set of key/value versions that were read in the chaincode (read set), and the set of keys/values that were written in chaincode (write set). The proposal response 292 is sent back to the client 260 along with an endorsement signature, if approved. The client 260 assembles the endorsements into a transaction payload 293 and broadcasts it to an ordering service node 284. The ordering service node 284 then delivers ordered transactions as blocks to all peers 281-283 on a channel. Before committal to the blockchain, each peer 281-283 may validate the transaction. For example, the peers may check the endorsement policy to ensure that the correct allotment of the specified peers have signed the results and authenticated the signatures against the transaction payload 293. Referring again to FIG. 2B, the client node 260 initiates the transaction 291 by constructing and sending a request to the peer node 281, which is an endorser. The client 260 may include an application leveraging a supported software development kit (SDK), which utilizes an available API to generate a transaction proposal. The proposal is a request to invoke a chaincode function so that data can be read and/or written to the ledger (i.e., write new key value pairs for the assets). The SDK may serve as a shim to package the transaction proposal into a properly architected format (e.g., protocol buffer over a remote procedure call (RPC)) and take the client's cryptographic credentials to produce a unique signature for the transaction proposal. In response, the endorsing peer node 281 may verify (a) that the transaction proposal is well formed, (b) the transaction has not been submitted already in the past (replay-attack protection), (c) the signature is valid, and (d) that the submitter (client 260, in the example) is properly authorized to perform the proposed operation on that channel. The endorsing peer node 281 may take the transaction proposal inputs as arguments to the invoked chaincode function. The chaincode is then executed against a current state database to produce transaction results including a response value, read set, and write set. However, no updates are made to the ledger at this point. In 292, the set of values, along with the endorsing peer node's 281 signature is passed back as a proposal response 292 to the SDK of the client 260 which parses the payload for the application to consume).
7. Regarding claims 3 and 17, Viale discloses wherein the storing the block hash of the proposal block and the target execution result comprises: storing the block hash of the proposal block and the target execution result as a key-value pair, the block hash of the proposal block being a key in the key-value pair and the target execution result being a value in the key-value pair, ( Para. 0040-0042, This application can utilize a ledger that is a sequenced, tamper-resistant record of all state transitions of a blockchain. State transitions may result from chaincode invocations (i.e., transactions) submitted by participating parties (e.g., client nodes, ordering nodes, endorser nodes, peer nodes, etc.). Each participating party (such as a peer node) can maintain a copy of the ledger. A transaction may result in a set of asset key-value pairs being committed to the ledger as one or more operands, such as creates, updates, deletes, and the like. The ledger includes a blockchain (also referred to as a chain) which is used to store an immutable, sequenced record in blocks. The ledger also includes a state database which maintains a current state of the blockchain. This application can utilize a chain that is a transaction log which is structured as hash-linked blocks, and each block contains a sequence of N transactions where N is equal to or greater than one. The block header includes a hash of the block's transactions, as well as a hash of the prior block's header. In this way, all transactions on the ledger may be sequenced and cryptographically linked together. Accordingly, it is not possible to tamper with the ledger data without breaking the hash links. A hash of a most recently added blockchain block represents every transaction on the chain that has come before it, making it possible to ensure that all peer nodes are in a consistent and trusted state. The chain may be stored on a peer node file system (i.e., local, attached storage, cloud, etc.), efficiently supporting the append-only nature of the blockchain workload. The current state of the immutable ledger represents the latest values for all keys that are included in the chain transaction log. Since the current state represents the latest key values known to a channel, it is sometimes referred to as a world state. Chaincode invocations execute transactions against the current state data of the ledger. To make these chaincode interactions efficient, the latest values of the keys may be stored in a state database. The state database may be simply an indexed view into the chain's transaction log, it can therefore be regenerated from the chain at any time. The state database may automatically be recovered (or generated if needed) upon peer node startup, and before transactions are accepted).
8. Regarding claims 4 and 18, Viale discloses wherein the performing the validity verification comprises: acquiring the transaction data in the proposal block, and performing a hash operation on the transaction data to obtain a to-be-verified hash value; performing a hash operation on the to-be-verified hash value according to a Merkle tree path in the proposal block to obtain a to-be-verified tree root hash value; acquiring a Merkle tree root hash value from a header of the proposal block; based on the to-be-verified tree root hash value being identical with the Merkle tree root hash value, determining that a validity verification result of the validity verification performed on the proposal block is a valid result; and based on the to-be-verified tree root hash value not being identical with the Merkle tree root hash value, determining that the validity verification result of the proposal block is an invalid result, (Para. 0133] The block data 650 may store transactional information of each transaction that is recorded within the new data block 630. For example, the transaction data may include one or more of a type of the transaction, a version, a timestamp, a channel ID of the distributed ledger 620, a transaction ID, an epoch, a payload visibility, a chaincode path (deploy tx), a chaincode name, a chaincode version, input (chaincode and functions), a client (creator) identify such as a public key and certificate, a signature of the client, identities of endorsers, endorser signatures, a proposal hash, chaincode events, response status, namespace, a read set (list of key and version read by the transaction, etc.), a write set (list of key and value, etc.), a start key, an end key, a list of keys, a Merkel tree query summary, and the like. The transaction data may be stored for each of the N transactions.; and Para. 0139-0142, In the example embodiment of FIG. 6C, the blockchain 670 includes a number of blocks 678.sub.1, 678.sub.2, . . . 678.sub.N cryptographically linked in an ordered sequence, where N≥1. The encryption used to link the blocks 678.sub.1, 678.sub.2, . . . 678.sub.N may be any of a number of keyed or un-keyed Hash functions. In one embodiment, the blocks 678.sub.1, 678.sub.2, . . . 678.sub.N are subject to a hash function which produces n-bit alphanumeric outputs (where n is 256 or another number) from inputs that are based on information in the blocks. Examples of such a hash function include, but are not limited to, a SHA-type (SHA stands for Secured Hash Algorithm) algorithm, Merkle-Damgard algorithm, HAIFA algorithm, Merkle-tree algorithm, nonce-based algorithm, and a non-collision-resistant PRF algorithm. In another embodiment, the blocks 678.sub.1, 678.sub.2, . . . , 678.sub.N may be cryptographically linked by a function that is different from a hash function. For purposes of illustration, the following description is made with reference to a hash function, e.g., SHA-2. Each of the blocks 678.sub.1, 678.sub.2, . . . , 678.sub.N in the blockchain includes a header, a version of the file, and a value. The header and the value are different for each block as a result of hashing in the blockchain. In one embodiment, the value may be included in the header. As described in greater detail below, the version of the file may be the original file or a different version of the original file. The first block 678.sub.1 in the blockchain is referred to as the genesis block and includes the header 672.sub.1, original file 674.sub.1, and an initial value 676.sub.1. The hashing scheme used for the genesis block, and indeed in all subsequent blocks, may vary. For example, all the information in the first block 678.sub.1 may be hashed together and at one time, or each or a portion of the information in the first block 678.sub.1 may be separately hashed and then a hash of the separately hashed portions may be performed. The header 672.sub.1 may include one or more initial parameters, which, for example, may include a version number, timestamp, nonce, root information, difficulty level, consensus protocol, duration, media format, source, descriptive keywords, and/or other information associated with original file 674.sub.1 and/or the blockchain. The header 672.sub.1 may be generated automatically (e.g., by blockchain network managing software) or manually by a blockchain participant. Unlike the header in other blocks 678.sub.2 to 678.sub.N in the blockchain, the header 672.sub.1 in the genesis block does not reference a previous block, simply because there is no previous block).
9. Regarding claims 5 and 19, Viale discloses wherein the performing the validity verification comprises: acquiring the transaction data in the proposal block; calling a transaction verification function to verify the transaction data to obtain a transaction verification result; based on the transaction verification result being a valid result, determining that a validity verification result of the validity verification performed on the proposal block is a valid result; and based on the transaction verification result being an invalid result, determining that the validity verification result of the proposal block is an invalid result, (Para. 0101-0103, In response, the application of the client 260 inspects/verifies the endorsing peers signatures and compares the proposal responses to determine if the proposal response is the same. If the chaincode only queried the ledger, the application would inspect the query response and would typically not submit the transaction to the ordering node service 284. If the client application intends to submit the transaction to the ordering node service 284 to update the ledger, the application determines if the specified endorsement policy has been fulfilled before submitting (i.e., did all peer nodes necessary for the transaction endorse the transaction). Here, the client may include only one of multiple parties to the transaction. In this case, each client may have their own endorsing node, and each endorsing node will need to endorse the transaction. The architecture is such that even if an application selects not to inspect responses or otherwise forwards an unendorsed transaction, the endorsement policy will still be enforced by peers and upheld at the commit validation phase. After successful inspection, in step 293 the client 260 assembles endorsements into a transaction and broadcasts the transaction proposal and response within a transaction message to the ordering node 284. The transaction may contain the read/write sets, the endorsing peers signatures and a channel ID. The ordering node 284 does not need to inspect the entire content of a transaction in order to perform its operation, instead the ordering node 284 may simply receive transactions from all channels in the network, order them chronologically by channel, and create blocks of transactions per channel. The blocks of the transaction are delivered from the ordering node 284 to all peer nodes 281-283 on the channel. The transactions 294 within the block are validated to ensure any endorsement policy is fulfilled and to ensure that there have been no changes to ledger state for read set variables since the read set was generated by the transaction execution. Transactions in the block are tagged as being valid or invalid. Furthermore, in step 295 each peer node 281-283 appends the block to the channel's chain, and for each valid transaction the write sets are committed to current state database. An event is emitted, to notify the client application that the transaction (invocation) has been immutably appended to the chain, as well as to notify whether the transaction was validated or invalidated).
10. Regarding claim 6, Viale discloses wherein the performing the validity verification comprises: acquiring a block hash of a parent block of the proposal block in the block chain as a target parent block hash; acquiring a parent block hash from a header of the proposal block as a to-be-verified parent block hash; based on the to-be-verified parent block hash being identical with the target parent block hash, determining that a validity verification result of the validity verification performed on the proposal block is a valid result; and based on the to-be-verified parent block hash not being identical with the target parent block hash, determining that the validity verification result of the proposal block is an invalid result, (Para. 0131-0132, When the ordering service 610 initializes a new data block 630, the new data block 630 may be broadcast to committing peers (e.g., blockchain nodes 611, 612, and 613). In response, each committing peer validates the transaction within the new data block 630 by checking to make sure that the read set and the write set still match the current world state in the state database 624. Specifically, the committing peer can determine whether the read data that existed when the endorsers simulated the transaction is identical to the current world state in the state database 624. When the committing peer validates the transaction, the transaction is written to the blockchain 622 on the distributed ledger 620, and the state database 624 is updated with the write data from the read-write set. If a transaction fails, that is, if the committing peer finds that the read-write set does not match the current world state in the state database 624, the transaction ordered into a block will still be included in that block, but it will be marked as invalid, and the state database 624 will not be updated. Referring to FIG. 6B, a new data block 630 (also referred to as a data block) that is stored on the blockchain 622 of the distributed ledger 620 may include multiple data segments such as a block header 640, block data 650, and block metadata 660. It should be appreciated that the various depicted blocks and their contents, such as new data block 630 and its contents. Shown in FIG. 6B are merely examples and are not meant to limit the scope of the example embodiments. The new data block 630 may store transactional information of N transaction(s) (e.g., 1, 10, 100, 500, 1000, 2000, 3000, etc.) within the block data 650. The new data block 630 may also include a link to a previous block (e.g., on the blockchain 622 in FIG. 6A) within the block header 640. In particular, the block header 640 may include a hash of a previous block's header. The block header 640 may also include a unique block number, a hash of the block data 650 of the new data block 630, and the like. The block number of the new data block 630 may be unique and assigned in various orders, such as an incremental/sequential order starting from zero.; and Para. 0110-0111, In structure 362, valid transactions are formed into a block and sealed with a lock (hash). This process may be performed by mining nodes among the nodes 354. Mining nodes may utilize additional software specifically for mining and creating blocks for the permissionless blockchain 352. Each block may be identified by a hash (e.g., 256 bit number, etc.) created using an algorithm agreed upon by the network. Each block may include a header, a pointer or reference to a hash of a previous block's header in the chain, and a group of valid transactions. The reference to the previous block's hash is associated with the creation of the secure independent chain of blocks. Before blocks can be added to the blockchain, the blocks must be validated. Validation for the permissionless blockchain 352 may include a proof-of-work (PoW) which is a solution to a puzzle derived from the block's header. Although not shown in the example of FIG. 3C, another process for validating a block is proof-of-stake. Unlike the proof-of-work, where the algorithm rewards miners who solve mathematical problems, with the proof of stake, a creator of a new block is chosen in a deterministic way, depending on its wealth, also defined as “stake.” Then, a similar proof is performed by the selected/chosen node). Examiner interprets the term parent block hash is analogous for the term previous block's hash in the cited prior art.
11. Regarding claim 7, Viale discloses wherein the performing the validity verification comprises: acquiring signature data associated with the proposal block; acquiring a public key of a proposer node, and verifying the signature data through the public key to obtain a signature verification result; (Para. 0133, The block data 650 may store transactional information of each transaction that is recorded within the new data block 630. For example, the transaction data may include one or more of a type of the transaction, a version, a timestamp, a channel ID of the distributed ledger 620, a transaction ID, an epoch, a payload visibility, a chaincode path (deploy tx), a chaincode name, a chaincode version, input (chaincode and functions), a client (creator) identify such as a public key and certificate, a signature of the client, identities of endorsers, endorser signatures, a proposal hash, chaincode events, response status, namespace, a read set (list of key and version read by the transaction, etc.), a write set (list of key and value, etc.), a start key, an end key, a list of keys, a Merkel tree query summary, and the like. The transaction data may be stored for each of the N transactions).
based on the signature verification result indicating successful signature verification, determining that a validity verification result of the validity verification performed on the proposal block is a valid result; the signature data with the successful signature verification being obtained by signing, by the proposer node, the proposal block through a possessed private key, and the proposal block associated with the signature data with the successful signature verification being generated by the proposer node; and based on the signature verification result indicating failed signature verification, determining that the validity verification result of the proposal block is an invalid result. (Para. 0098-0102, FIG. 2B illustrates an example of a blockchain transactional flow 250 between nodes of the blockchain in accordance with an example embodiment. Referring to FIG. 2B, the transaction flow may include a transaction proposal 291 sent by an application client node 260 to an endorsing peer node 281. The endorsing peer 281 may verify the client signature and execute a chaincode function to initiate the transaction. The output may include the chaincode results, a set of key/value versions that were read in the chaincode (read set), and the set of keys/values that were written in chaincode (write set). The proposal response 292 is sent back to the client 260 along with an endorsement signature, if approved. The client 260 assembles the endorsements into a transaction payload 293 and broadcasts it to an ordering service node 284. The ordering service node 284 then delivers ordered transactions as blocks to all peers 281-283 on a channel. Before committal to the blockchain, each peer 281-283 may validate the transaction. For example, the peers may check the endorsement policy to ensure that the correct allotment of the specified peers have signed the results and authenticated the signatures against the transaction payload 293. Referring again to FIG. 2B, the client node 260 initiates the transaction 291 by constructing and sending a request to the peer node 281, which is an endorser. The client 260 may include an application leveraging a supported software development kit (SDK), which utilizes an available API to generate a transaction proposal. The proposal is a request to invoke a chaincode function so that data can be read and/or written to the ledger (i.e., write new key value pairs for the assets). The SDK may serve as a shim to package the transaction proposal into a properly architected format (e.g., protocol buffer over a remote procedure call (RPC)) and take the client's cryptographic credentials to produce a unique signature for the transaction proposal. In response, the endorsing peer node 281 may verify (a) that the transaction proposal is well formed, (b) the transaction has not been submitted already in the past (replay-attack protection), (c) the signature is valid, and (d) that the submitter (client 260, in the example) is properly authorized to perform the proposed operation on that channel. The endorsing peer node 281 may take the transaction proposal inputs as arguments to the invoked chaincode function. The chaincode is then executed against a current state database to produce transaction results including a response value, read set, and write set. However, no updates are made to the ledger at this point. In 292, the set of values, along with the endorsing peer node's 281 signature is passed back as a proposal response 292 to the SDK of the client 260 which parses the payload for the application to consume. In response, the application of the client 260 inspects/verifies the endorsing peers signatures and compares the proposal responses to determine if the proposal response is the same. If the chaincode only queried the ledger, the application would inspect the query response and would typically not submit the transaction to the ordering node service 284. If the client application intends to submit the transaction to the ordering node service 284 to update the ledger, the application determines if the specified endorsement policy has been fulfilled before submitting (i.e., did all peer nodes necessary for the transaction endorse the transaction). Here, the client may include only one of multiple parties to the transaction. In this case, each client may have their own endorsing node, and each endorsing node will need to endorse the transaction. The architecture is such that even if an application selects not to inspect responses or otherwise forwards an unendorsed transaction, the endorsement policy will still be enforced by peers and upheld at the commit validation phase. After successful inspection, in step 293 the client 260 assembles endorsements into a transaction and broadcasts the transaction proposal and response within a transaction message to the ordering node 284. The transaction may contain the read/write sets, the endorsing peers signatures and a channel ID.)
12. Regarding claim 8, Viale discloses wherein the executing the application based on the transaction data comprises: acquiring the transaction data in the proposal block, and calling a transaction execution function configured to execute the transaction data in the application, acquiring read data of the transaction data according to the transaction execution function, and executing the transaction execution function according to the read data and the transaction data to obtain the target execution result of the transaction data; and the storing the block hash of the proposal block and the target execution result includes storing the block hash of the proposal block and the target execution result in the memory in an associated manner. (Para. 0094-0098, The blockchain architecture configuration of FIG. 2A may process and execute program/application code 220 via one or more interfaces exposed, and services provided, by blockchain platform 212. The code 220 may control blockchain assets. For example, the code 220 can store and transfer data, and may be executed by nodes 204-210 in the form of a smart contract and associated chaincode with conditions or other code elements subject to its execution. As a non-limiting example, smart contracts may be created to execute reminders, updates, and/or other notifications subject to the changes, updates, etc. The smart contracts can themselves be used to identify rules associated with authorization and access requirements and usage of the ledger. For example, the conditional consensus information 226 may be processed by one or more processing entities (e.g., virtual machines) included in the blockchain layer 216. The result 228 may include committed coordinated transactions. The physical infrastructure 214 may be utilized to retrieve any of the data or information described herein.A smart contract may be created via a high-level application and programming language, and then written to a block in the blockchain. The smart contract may include executable code which is registered, stored, and/or replicated with a blockchain (e.g., distributed network of blockchain peers). A transaction is an execution of the smart contract code which can be performed in response to conditions associated with the smart contract being satisfied. The executing of the smart contract may trigger a trusted modification(s) to a state of a digital blockchain ledger. The modification(s) to the blockchain ledger caused by the smart contract execution may be automatically replicated throughout the distributed network of blockchain peers through one or more consensus protocols. The smart contract may write data to the blockchain in the format of key-value pairs. Furthermore, the smart contract code can read the values stored in a blockchain and use them in application operations. The smart contract code can write the output of various logic operations into the blockchain. The code may be used to create a temporary data structure in a virtual machine or other computing platform. Data written to the blockchain can be public and/or can be encrypted and maintained as private. The temporary data that is used/generated by the smart contract is held in memory by the supplied execution environment, then deleted once the data needed for the blockchain is identified. A chaincode may include the code interpretation of a smart contract, with additional features. As described herein, the chaincode may be program code deployed on a computing network, where it is executed and validated by chain validators together during a consensus process. The chaincode receives a hash and retrieves from the blockchain a hash associated with the data template created by use of a previously stored feature extractor. If the hashes of the hash identifier and the hash created from the stored identifier template data match, then the chaincode sends an authorization key to the requested service. The chaincode may write to the blockchain data associated with the cryptographic details. FIG. 2B illustrates an example of a blockchain transactional flow 250 between nodes of the blockchain in accordance with an example embodiment. Referring to FIG. 2B, the transaction flow may include a transaction proposal 291 sent by an application client node 260 to an endorsing peer node 281. The endorsing peer 281 may verify the client signature and execute a chaincode function to initiate the transaction. The output may include the chaincode results, a set of key/value versions that were read in the chaincode (read set), and the set of keys/values that were written in chaincode (write set). The proposal response 292 is sent back to the client 260 along with an endorsement signature, if approved. The client 260 assembles the endorsements into a transaction payload 293 and broadcasts it to an ordering service node 284. The ordering service node 284 then delivers ordered transactions as blocks to all peers 281-283 on a channel. Before committal to the blockchain, each peer 281-283 may validate the transaction. For example, the peers may check the endorsement policy to ensure that the correct allotment of the specified peers have signed the results and authenticated the signatures against the transaction payload 293.)
13. Regarding claim 12, Viale discloses further comprising: based on a validity verification result of the validity verification performed on the proposal block being an invalid result, performing two consecutive rounds of consensus voting processing on the proposal block to obtain a second consensus result; and based on the second consensus result being the consensus pass result, synchronizing the proposal block, with the block height of M, that has been stored to the block chain from a target validator node and the target execution result corresponding to the proposal block, the target validator node successfully storing the proposal block and the target execution result to the block chain. (Para. 0179-0181, The operation of the blockchain 752 is based on two procedures (i) creation of transactions, and (ii) construction of blocks that aggregate the new transactions. New transactions may be created similar to a traditional blockchain network. Each transaction may contain information about a sender, a receiver, a time of creation, an amount (or value) to be transferred, a list of reference transactions that justifies the sender has funds for the operation, and the like. This transaction record is then sent to all other nodes where it is entered into a pool of unconfirmed transactions. Here, two parties (i.e., a pair of users from among 754-760) authenticate the transaction by providing their shared secret key 762 (QKD). This quantum signature can be attached to every transaction making it exceedingly difficult to tamper with. Each node checks their entries with respect to a local copy of the blockchain 752 to verify that each transaction has sufficient funds. However, the transactions are not yet confirmed. Rather than perform a traditional mining process on the blocks, the blocks may be created in a decentralized manner using a broadcast protocol. At a predetermined period of time (e.g., seconds, minutes, hours, etc.) the network may apply the broadcast protocol to any unconfirmed transaction thereby to achieve a Byzantine agreement (consensus) regarding a correct version of the transaction. For example, each node may possess a private value (transaction data of that particular node). In a first round, nodes transmit their private values to each other. In subsequent rounds, nodes communicate the information they received in the previous round from other nodes. Here, honest nodes are able to create a complete set of transactions within a new block. This new block can be added to the blockchain 752. In one embodiment the features and/or the actions described and/or depicted herein can occur on or with respect to the blockchain 752. FIG. 8 illustrates an example system 800 that supports one or more of the example embodiments described and/or depicted herein.)
14. Regarding claim 13, Viale discloses wherein the performing the validity verification comprises: in response to acquiring the proposal block generated in the Nth round with the block height of M within a verification time threshold, performing the validity verification on the proposal block; the method further comprising: in response to not acquiring the proposal block generated in the Nth round with the block height of M within the verification time threshold, constructing a temporary empty block; (Para. 0096, The smart contract may write data to the blockchain in the format of key-value pairs. Furthermore, the smart contract code can read the values stored in a blockchain and use them in application operations. The smart contract code can write the output of various logic operations into the blockchain. The code may be used to create a temporary data structure in a virtual machine or other computing platform. Data written to the blockchain can be public and/or can be encrypted and maintained as private. The temporary data that is used/generated by the smart contract is held in memory by the supplied execution environment, then deleted once the data needed for the blockchain is identified.; and Para. 0130-0131, Transactions are written to the distributed ledger 620 in a consistent order. The order of transactions is established to ensure that the updates to the state database 624 are valid when they are committed to the network. Unlike a cryptocurrency blockchain system (e.g., Bitcoin, etc.) where ordering occurs through the solving of a cryptographic puzzle, or mining, in this example the parties of the distributed ledger 620 may choose the ordering mechanism that best suits that network. When the ordering service 610 initializes a new data block 630, the new data block 630 may be broadcast to committing peers (e.g., blockchain nodes 611, 612, and 613). In response, each committing peer validates the transaction within the new data block 630 by checking to make sure that the read set and the write set still match the current world state in the state database 624. Specifically, the committing peer can determine whether the read data that existed when the endorsers simulated the transaction is identical to the current world state in the state database 624. When the committing peer validates the transaction, the transaction is written to the blockchain 622 on the distributed ledger 620, and the state database 624 is updated with the write data from the read-write set. If a transaction fails, that is, if the committing peer finds that the read-write set does not match the current world state in the state database 624, the transaction ordered into a block will still be included in that block, but it will be marked as invalid, and the state database 624 will not be updated.)
Performing the two consecutive rounds of consensus voting processing on the temporary empty block to obtain a third consensus result; and based on the third consensus result being the consensus pass result, synchronizing the proposal block, with the block height of M, that has been stored to the block chain from a target validator node and the target execution result corresponding to the proposal block, the target validator node successfully storing the proposal block and the target execution result to the block chain, (Para. 0172-0174, The collected data may be stored in the blockchain 710 based on a consensus mechanism. The consensus mechanism pulls in (permissioned nodes) to ensure that the data being recorded is verified and accurate. The data recorded is time-stamped, cryptographically signed, and immutable. It is therefore auditable, transparent, and secure. Adding IoT devices which write directly to the blockchain can, in certain cases (i.e. supply chain, healthcare, logistics, etc.), increase both the frequency and accuracy of the data being recorded. Furthermore, training of the machine learning model on the collected data may take rounds of refinement and testing by the host platform 720. Each round may be based on additional data or data that was not previously considered to help expand the knowledge of the machine learning model. In 702, the different training and testing steps (and the data associated therewith) may be stored on the blockchain 710 by the host platform 720. Each refinement of the machine learning model (e.g., changes in variables, weights, etc.) may be stored on the blockchain 710. This provides verifiable proof of how the model was trained and what data was used to train the model. Furthermore, when the host platform 720 has achieved a finally trained model, the resulting model may be stored on the blockchain 710. After the model has been trained, it may be deployed to a live environment where it can make predictions/decisions based on the execution of the final trained machine learning model. For example, in 704, the machine learning model may be used for condition-based maintenance (CBM) for an asset such as an aircraft, a wind turbine, a healthcare machine, and the like. In this example, data fed back from the asset 730 may be input the machine learning model and used to make event predictions such as failure events, error codes, and the like. Determinations made by the execution of the machine learning model at the host platform 720 may be stored on the blockchain 710 to provide auditable/verifiable proof. As one non-limiting example, the machine learning model may predict a future breakdown/failure to a part of the asset 730 and create alert or a notification to replace the part. The data behind this decision may be stored by the host platform 720 on the blockchain 710. In one embodiment the features and/or the actions described and/or depicted herein can occur on or with respect to the blockchain 710.)
15. Regarding claim 14, Viale discloses wherein after the storing the proposal block and the target execution result to the block chain, the method further comprises: deleting the N execution results with the block height of M in the memory; or acquiring a total quantity of all the execution results in the memory, and based on the total quantity being greater than or equal to a stored quantity threshold, deleting all the execution results in the memory; all the execution results corresponding to one or more block heights, (Para. 0078-0082 , In addition to new types of transaction and consensus, and new types of qualifiers for world state data elements, new functions may be required for orchestrating the blockchain support of coordinated processes. The functions may be: 1. Context Manager. The Context Manager function is invoked each time a transaction of type coordinated reaches a consensus of type conditional. The function is responsible for: Collecting, structuring, and storing all context data that pertains to each coordinated process; Updating the context data for a given coordinated process as interim transactions occur within said process; and Deleting the context data that pertains to a given coordinated process once its final transaction has received consensus.; and Para. 0095-0096, A smart contract may be created via a high-level application and programming language, and then written to a block in the blockchain. The smart contract may include executable code which is registered, stored, and/or replicated with a blockchain (e.g., distributed network of blockchain peers). A transaction is an execution of the smart contract code which can be performed in response to conditions associated with the smart contract being satisfied. The executing of the smart contract may trigger a trusted modification(s) to a state of a digital blockchain ledger. The modification(s) to the blockchain ledger caused by the smart contract execution may be automatically replicated throughout the distributed network of blockchain peers through one or more consensus protocols. The smart contract may write data to the blockchain in the format of key-value pairs. Furthermore, the smart contract code can read the values stored in a blockchain and use them in application operations. The smart contract code can write the output of various logic operations into the blockchain. The code may be used to create a temporary data structure in a virtual machine or other computing platform. Data written to the blockchain can be public and/or can be encrypted and maintained as private. The temporary data that is used/generated by the smart contract is held in memory by the supplied execution environment, then deleted once the data needed for the blockchain is identified).
Claims 9-11 are rejected under 35 U.S.C. 103 as being unpatentable over Viale et al. (US 20200387395 A1), in view of Bhagavatha et al. (US 20210326867A1), in view of Kawahara et al. (US 20200220770 A1), further in view of Cao et al (CN 110943838 A).
17. Regarding claim 9, Viale as modified does not explicitly disclose wherein the performing the two consecutive rounds of consensus voting processing comprises: in the first round of the two consecutive rounds of consensus voting processing, performing prevote processing on the proposal block according to a validity verification result of the validity verification performed on the proposal block to obtain a prevote result; and in the second round of the two consecutive rounds of consensus voting processing, performing precommit processing on the proposal block according to the prevote result to obtain the first consensus result.
However, Cao teaches wherein the performing the two consecutive rounds of consensus voting processing comprises: in the first round of the two consecutive rounds of consensus voting processing, performing prevote processing on the proposal block according to a validity verification result of the validity verification performed on the proposal block to obtain a prevote result; and in the second round of the two consecutive rounds of consensus voting processing, performing precommit processing on the proposal block according to the prevote result to obtain the first consensus result,( Abstract Section, Embodiments of the present disclosure relate to a method of blockchain formation consensus, an apparatus for a node of a blockchain, a computer readable storage medium and a computer program product. The method comprises the following steps: the method comprises the following steps: at a master node of the blockchain, sending a suggested block to a plurality of other nodes, the suggested block being associated with a transaction to be processed; in response to determining that the number of received acknowledgement messages is greater than a first predetermined value, determining primary node signature messages associated with the proposed blocks, each acknowledgement message sent by one of the plurality of other nodes in response to determining that the proposed block is verified; and Detailed Description Section, In addition, instead of each node broadcasting a prefix message to other nodes, each node sends a confirmation message to the master node confirming that the currently proposed block passes the verification, and again, instead of each node broadcasting a prefix message to other nodes, each node sends a master node signature message generated based on the received confirmation message, so that the number of network communications is compressed to at least the order of N (N is the number of network nodes) from the order of N2 required by the conventional consensus method.; and Detailed Description Section, Each node 305 in the network 300 may vote for only one block at each altitude and each round of consensus determination to allow consensus to be achieved as quickly as possible. In some embodiments, each node may record a block if more than a predetermined threshold number of backup nodes vote for the block during consensus determination for the block. The master node may determine whether more than a predetermined threshold number of backup nodes cast in favor of a vote based on the received votes. The backup node may perform the above determination based on the aggregated signature broadcast by the primary node. If consensus on the blocks is not achieved, the nodes may make a new round of consensus determination based on the recorded blocks. For example, in a new round of consensus determination, the master node broadcasts the recorded chunks. The backup node may compare the received blocks with the recorded blocks after receiving the blocks broadcast by the primary node. If the two are the same, the backup node approves the ticket. This ensures that more than a predetermined threshold number (e.g., more than two thirds) of the voting rights are locked to the same block, thereby preventing divergence and achieving consensus as early as possible.; and Detailed Description Section, A new round of consensus determination may also include two phases, pre-voting and pre-validation. In the pre-vote phase, if a node has recorded or bound a block, the node still votes for this block even though it currently receives a new block. If the node has not previously recorded or locked any blocks, it is verified whether the currently received block is valid. If valid, the node approves the ticket, otherwise it approves the ticket (e.g., the empty string nil) to indicate that the node wishes to enter the next round of consensus determination. In the pre-validation phase, if the node determines that more than a predetermined threshold number (e.g., more than two-thirds) of positive tickets have not been received in the pre-voting phase, the node votes against the tickets (e.g., the empty string nil or empty tickets). In the event that more than a predetermined threshold number of positive tickets are received, the node may also vote negatively (e.g., an empty ticket) to indicate a desire to enter the next round of consensus determination. At which point unlocking (or binding) is required. If more than a predetermined threshold number of votes are received and the node has bound to the received tile, the node directly honors the votes. If a predetermined threshold number of positive tickets are received but the blocks for which positive tickets are directed are not the same as the recorded or bound blocks, then it is verified whether the blocks for which positive tickets are directed are valid. If valid, the ticket is voted for and this new chunk is recorded or bound. If more than a predetermined threshold number of votes are received, the node does not vote for the corresponding block. The node may request this block from other nodes and cast a null ticket.)
One of ordinary skill in the art would have recognized that applying the known technique of Cao to the known invention of Viale as modified would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate consensus voting features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include wherein the performing the two rounds of the consensus voting processing comprises: in a first round of the consensus voting, performing prevote processing on the proposal block according to a validity verification result of the validity verification performed on the proposal block to obtain a prevote result; and in a second round of the consensus voting, performing precommit processing on the proposal block according to the prevote result to obtain the first consensus result, results in an improved invention because applying said technique will ensure that proposal blocks that only pass the initial verification proceed, thus improving the overall performance of the invention.
18. Regarding claim 10, Viale as modified does not explicitly disclose wherein the performing the prevote processing comprises: in the first round of the two consecutive rounds of consensus voting processing, determining a first prevote result as a first affirmative result for the proposal block according to the valid result; broadcasting the first prevote result to a plurality of target validator nodes; receiving second prevote results respectively from the plurality of target validator nodes, the plurality of second prevote results including at least one of the first affirmative result for the proposal block or a first negative result for the proposal block; determining a quantity of first affirmative votes and a quantity of first negative votes for the proposal block according to the first prevote result and the plurality of second prevote results; based on the quantity of first affirmative votes exceeding a first prevote threshold, determining that the prevote result is a successful prevote result; and based on the quantity of first negative votes exceeding a second prevote threshold, determining that the prevote result is a failed prevote result.
However, Cao teaches wherein the performing the prevote processing comprises: in the first round of the two consecutive rounds of consensus voting processing, determining a first prevote result as a first affirmative result for the proposal block according to the valid result; broadcasting the first prevote result to a plurality of target validator nodes; receiving second prevote results respectively from the plurality of target validator nodes, the plurality of second prevote results including at least one of the first affirmative result for the proposal block or a first negative result for the proposal block; determining a quantity of first affirmative votes and a quantity of first negative votes for the proposal block according to the first prevote result and the plurality of second prevote results; based on the quantity of first affirmative votes exceeding a first prevote threshold, determining that the prevote result is a successful prevote result; and based on the quantity of first negative votes exceeding a second prevote threshold, determining that the prevote result is a failed prevote result,( Abstract Section, Embodiments of the present disclosure relate to a method of blockchain formation consensus, an apparatus for a node of a blockchain, a computer readable storage medium and a computer program product. The method comprises the following steps: the method comprises the following steps: at a master node of the blockchain, sending a suggested block to a plurality of other nodes, the suggested block being associated with a transaction to be processed; in response to determining that the number of received acknowledgement messages is greater than a first predetermined value, determining primary node signature messages associated with the proposed blocks, each acknowledgement message sent by one of the plurality of other nodes in response to determining that the proposed block is verified; and Detailed Description Section, In addition, instead of each node broadcasting a prefix message to other nodes, each node sends a confirmation message to the master node confirming that the currently proposed block passes the verification, and again, instead of each node broadcasting a prefix message to other nodes, each node sends a master node signature message generated based on the received confirmation message, so that the number of network communications is compressed to at least the order of N (N is the number of network nodes) from the order of N2 required by the conventional consensus method.; and Detailed Description Section, If the block is very large, it takes a long time for the master node to broadcast the block and for the backup node to receive the block. It also takes a long time for the master node to collect the votes of the backup nodes. This will greatly reduce the number of Transactions Per Second (TPS) in a blockchain network. In some embodiments, the master node may divide the data of the block into a plurality of data sub-blocks while generating summary information for the block. By way of example, the summary information may include an identification of the block, a height of the block, a number of rounds at which consensus was determined, and a number of data sub-blocks, among others. The summary information may also include verification information for the data sub-blocks, such as a hash value for each data sub-block or a hash tree value for the entire block (e.g., a Merkle tree hash value).; and Detailed Description Section, The master node may broadcast summary information for the blocks and a plurality of data sub-blocks separately. For example, the host node may broadcast the summary information first, and then broadcast the data sub-blocks. Alternatively, the master node may also broadcast the summary information and the data sub-blocks in parallel... Fig. 5 illustrates an example process 500 for a backup node to vote and receive data sub-blocks in parallel, in accordance with certain embodiments of the present disclosure. As shown in fig. 5, at 505, the backup node is in an idle state. At 510, the backup node receives summary information for the blocks broadcast by the primary node. At 515, in response to receiving the summary information, the backup node determines whether to approve or disapprove the block and performs a pre-vote. At 520, the backup node preacknowledges the block. The operations and features described above with respect to pre-voting and pre-validation are also applicable here.; and Detailed Description Section, After two rounds of pre-voting and pre-validation, the backup node validates the block at 535 after verifying the block even if the backup node determines that more than a predetermined threshold number of nodes voted for the block. If no node exceeding the predetermined threshold number votes for approval or the block fails verification, the block is discarded and the next round of consensus confirmation is entered (i.e., the height H is not changed, the number of rounds R is incremented by one; and Detailed Description Section, If the client 130 receives correct response messages from nodes greater than or equal to f +1, e.g., the signature is correct, the timestamp t is the same, and the execution result r is the same, the client 130 determines that consensus is achieved. In the example shown in FIG. 1, the backup node 140-N is a failed node. Thus, in both the prepare phase 115 and the confirm phase 120, no broadcast message is received by each node from the backup node 140-N. In the reply phase 125, the client 130 also does not receive a reply message from the backup node 140-N. However, since the client 130 receives the correct reply messages from more than f +1 nodes, consensus is achieved.; and Detailed Description Section, During the pre-vote phase 210, each node (including the primary node 235 and the backup node 240) validates the proposed block 245 and broadcasts a PREVOTE message, i.e., makes a preliminary vote (250). The pre-voting on the block is used to prepare the network to confirm the vote of the block. A pre-vote containing an empty message (e.g., an empty string nil) is a vote indicating that the network is expected to prepare for the next round of consensus determination. After the node receives a PREVOTE message from more than two-thirds of the nodes in the consensus group, the node enters the pre-acknowledgement phase 215).
One of ordinary skill in the art would have recognized that applying the known technique of Cao to the known invention of Viale as modified would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate consensus voting features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include wherein the performing the prevote processing comprises: in the first round of the consensus voting, determining a first prevote result as a first affirmative result for the proposal block according to the valid result; broadcasting the first prevote result to a plurality of target validator nodes; receiving second prevote results respectively from the plurality of target validator nodes, the plurality of second prevote results including at least one of the first affirmative result for the proposal block or a first negative result for the proposal block; determining a quantity of first affirmative votes and a quantity of first negative votes for the proposal block according to the first prevote result and the plurality of second prevote results; based on the quantity of first affirmative votes exceeding a first prevote threshold, determining that the prevote result is a successful prevote result; and based on the quantity of first negative votes exceeding a second prevote threshold, determining that the prevote result is a failed prevote result, results in an improved invention because applying said technique will ensure that multiple validators agree on the validity of the block, thus improving the overall performance of the invention.
19. Regarding claim 11, Viale as modified does not explicitly disclose wherein the performing the precommit processing comprises:based on the prevote result being the successful prevote result, determining a first precommit result as a second affirmative result for the proposal block; based on the prevote result being the failed prevote result, determining the first precommit result as a second negative result for the proposal block; broadcasting the first precommit result to the plurality of target validator nodes; receiving second precommit results respectively from the plurality of target validator nodes, the plurality of second precommit results including at least one of the second affirmative result for the proposal block or the second negative result for the proposal block; determining a quantity of second affirmative votes and a quantity of second negative votes for the proposal block according to the first precommit result and the plurality of second precommit results; based on the quantity of second affirmative votes exceeding a first precommit threshold, determining that the first consensus result is the consensus pass result; and based on the quantity of second negative votes exceeding a second precommit threshold, determining that the first consensus result is a consensus fail result.
However, Cao teaches wherein the performing the precommit processing comprises:based on the prevote result being the successful prevote result, determining a first precommit result as a second affirmative result for the proposal block; based on the prevote result being the failed prevote result, determining the first precommit result as a second negative result for the proposal block; broadcasting the first precommit result to the plurality of target validator nodes; receiving second precommit results respectively from the plurality of target validator nodes, the plurality of second precommit results including at least one of the second affirmative result for the proposal block or the second negative result for the proposal block; determining a quantity of second affirmative votes and a quantity of second negative votes for the proposal block according to the first precommit result and the plurality of second precommit results; based on the quantity of second affirmative votes exceeding a first precommit threshold, determining that the first consensus result is the consensus pass result; and based on the quantity of second negative votes exceeding a second precommit threshold, determining that the first consensus result is a consensus fail result, (Detailed Description Section, In the pre-validation phase, if the node determines that more than a predetermined threshold number (e.g., more than two-thirds) of positive tickets have not been received in the pre-voting phase, the node votes against the tickets (e.g., the empty string nil or empty tickets). In the event that more than a predetermined threshold number of positive tickets are received, the node may also vote negatively (e.g., an empty ticket) to indicate a desire to enter the next round of consensus determination. At which point unlocking (or binding) is required. If more than a predetermined threshold number of votes are received and the node has bound to the received tile, the node directly honors the votes. If a predetermined threshold number of positive tickets are received but the blocks for which positive tickets are directed are not the same as the recorded or bound blocks, then it is verified whether the blocks for which positive tickets are directed are valid. If valid, the ticket is voted for and this new chunk is recorded or bound. If more than a predetermined threshold number of votes are received, the node does not vote for the corresponding block. The node may request this block from other nodes and cast a null ticket.
In the validation phase, if more than a predetermined threshold number of positive tickets are received for a block, the block is validated before the next height (i.e., block height H plus 1) is entered. If more than a predetermined threshold number (e.g., more than two-thirds) of empty tickets are received, the next round of consensus determination is entered (i.e., the number of rounds R plus 1) and the current tile height remains unchanged.; and Detailed Description Section, The master node generates an aggregated signature based on signatures in votes from the plurality of backup nodes that is the same size as the nodes in the votes. For example, the primary node may multiply the signatures of multiple backup nodes to generate an aggregate signature. In some embodiments, the master node may multiply the signatures in the positive tickets for the blocks, such that the generated aggregated signature contains the signature of the backup node that voted positive. The aggregated signature may be generated if the master node determines that more than a predetermined threshold number of nodes (e.g., more than two-thirds of the nodes) in the network 300 vote in favor of the block. In this way, in the case where a node sends a conflicting or wrong vote because it is attacked, since the impact is limited to this single node, the consensus is still valid if more than two-thirds of the nodes are secure.
The aggregated signature is broadcast by the master node in the network 300. Meanwhile, the main node also broadcasts a bitmap of a backup node participating in voting, and the signature in the voting participates in the generation of the aggregated signature. After receiving the aggregated signature and the bitmap, the backup nodes may determine from the bitmap which backup nodes' public keys to use to verify the aggregated signature and verify it using the associated public keys. For example, the backup node may multiply the public keys of other backup nodes that sent votes to the primary node and the signatures in the votes participated in aggregate signature generation to generate an aggregate public key, which is then used to verify the aggregate signature. Therefore, each backup node can determine the voting result of the pre-voting stage and can determine whether the main node is a malicious node. For a backup node participating in the voting, the signature of the backup node may not participate in the generation of the aggregated signature. Accordingly, the bitmap may also have no information for the node. This is because, as described above, the master node may generate an aggregate signature upon determining that more than a predetermined threshold number (e.g., more than two-thirds) of nodes cast positive or negative votes (or null votes, e.g., null strings nil) to the block, without having to wait for the signatures of all backup nodes to be collected.; and Detailed Description Section, After two rounds of pre-voting and pre-validation, the backup node validates the block at 535 after verifying the block even if the backup node determines that more than a predetermined threshold number of nodes voted for the block. If no node exceeding the predetermined threshold number votes for approval or the block fails verification, the block is discarded and the next round of consensus confirmation is entered (i.e., the height H is not changed, the number of rounds R is incremented by one).
One of ordinary skill in the art would have recognized that applying the known technique of Cao to the known invention of Viale as modified would have been recognized that the application of the technique would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate consensus voting features into a similar invention. Further, it would have been recognized by those of ordinary skill in the art that modifying the method to include wherein the wherein the performing the precommit processing comprises:based on the prevote result being the successful prevote result, determining a first precommit result as a second affirmative result for the proposal block; based on the prevote result being the failed prevote result, determining the first precommit result as a second negative result for the proposal block; broadcasting the first precommit result to the plurality of target validator nodes; receiving second precommit results respectively from the plurality of target validator nodes, the plurality of second precommit results including at least one of the second affirmative result for the proposal block or the second negative result for the proposal block; determining a quantity of second affirmative votes and a quantity of second negative votes for the proposal block according to the first precommit result and the plurality of second precommit results; based on the quantity of second affirmative votes exceeding a first precommit threshold, determining that the first consensus result is the consensus pass result; and based on the quantity of second negative votes exceeding a second precommit threshold, determining that the first consensus result is a consensus fail result, results in an improved invention because applying said technique ensures that only the blocks that have passed the two rounds of voting are added to the blockchain , thus improving the overall performance of the invention.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Voting-Based Consensus Method (WO 2019232789 A1) teaches a voting-based consensus method, comprising: S1, selecting an on-duty housekeeper, and the on-duty housekeeper determining whether an upcoming block is a special block; S2, the on-duty housekeeper sending a generated pre-block to all member nodes and waiting for signatures of the members, and determining whether the number of member node verification signatures received by the on-duty housekeeper is greater than half of the number of members; S3, determining whether a valid block has timed out; and S4, determining whether the valid block is a special block. In terms of compliance regulation, alliance nodes are permitted to fully control the generation and confirmation of transaction data. Compared with a public chain algorithm, control over the system is reflected in the need for only half of members to agree to maintain data on a chain and provide an auditor with required data.
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 extension fee 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.
In addition to the foregoing, other aspects are described in the claims, drawings, and text. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Davida L. King whose telephone number is (571) 272-4724. The examiner can normally be reached M-F 8am-5pm.
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, Neha Patel can be reached on (571) 270-1492. 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.
/D.L.K./Examiner, Art Unit 3699