DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
2. This action is in response to the following communication: Non-provisional
Application No. 17/222,207 filed on 05/29/2026.
3. Claims 1-4, 6-12, 14-16 are pending.
Claims 1 and 9 are independent claims.
Response to Arguments
4. Applicant’s arguments with respect to newly amended independent claims 1 and 9 and claims 2-4, 6-8, 10-12, 14-16 on page 6 of the response have been fully considered but they are not persuasive are moot in view of the ground(s) of rejection- see Kikinis (Art of record) as applied below, as they further teach such use.
Claim Rejections - 35 USC § 103
5. 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 of this title, 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.
6. Claims 1-4, 6-12 and 15-16 are rejected under 35 U.S.C. 103 as being unpatentable over Kikinis, U.S. Patent No. 10,552,556 in view of Qi, WO 2020182134 A1 in view of Smith et al., U.S. 2019/0132350 (hereinafter Smith).
In regards to claim 1, Kikinis teaches:
A method for autonomous determination of performance metrics in a blockchain network through randomly generated transactions, comprising: (column 2, lines 38-40, see a system for performance testing of scalability implementations and testing of stability in blockchain database implementations) and (column 17, lines 65-67, see pre-generated and re-usable datasets could comprise 10,000 accounts (wallets), where each wallet holds a random number of tokens between 10 and 1000).
receiving, by a receiver in a blockchain node in a blockchain network that manages a blockchain, a testing instruction, where the testing instruction includes at least one testing criteria (column 2, lines 41-47, see the testing system comprises a cluster of private blockchain nodes instantiated on a server, likely a cloud-based system, and a control console that allows the user to set the number of nodes in the network and the number of clients for testing of a particular blockchain implementation).
a number of the plurality of blockchain transactions is based on the at least one testing criteria (column 2, lines 42-47, see the testing system comprises a cluster of private blockchain nodes instantiated on a server, likely a cloud-based system, and a control console that allows the user to set the number of nodes in the network and the number of clients for testing of a particular blockchain implementation. Performance would be measured in terms of transactions/ second with testing of time to system stability) and (column 17, lines 34-42, see in early stage testing, the number of nodes might be restricted to fewer than 10, whereas in later stages, the number can be increased to test the blockchain implantation for larger system configurations. Each client 1520a-c adds a certain demand on the network, resulting in a system total transaction throughput that may be measured by at least one performance metric, which is displayed in a performance metrics 1603 display).
submitting, by a transmitter of the blockchain node, the generated plurality of new blockchain transactions into a pending transaction queue in the blockchain network (column 18, lines 13-27, see then datasets are pre-generated in a database, such as, for example, Mongo database. Programs to generate accounts and wallets with tokens in Ethereum and to pre-load transactions in Ethereum queues without executing them are created. Transactions in out-of-box Ethereum are executed, and performance is measured… Then the test run and measurements are repeated using a 15-node Ethereum network. In phase two 1802, the system would decrease the Ethereum block time to six seconds, run transactions, and measure performance. Testing would be repeated, decreasing the Ethereum block time further, running transactions, and measuring performance, until we the minimum viable block time is established).
monitoring, by the processor of the blockchain node, a plurality of performance values for one or more nodes in the blockchain network and a plurality of performance values for the blockchain network (column 18, lines 24-27, see testing would be repeated, decreasing the Ethereum block time further, running transactions, and measuring performance, until we the minimum viable block time is established) and (column 26, lines 42-55, see instantiating a plurality of blockchain nodes on at least one computer system in the computer network; assigning one of the nodes to be the lead node for processing of blocks; generating or import simulated accounts, wallets, tokens, and transactions; loading an implementation of at least one shard of a divided blockchain for testing; running a simulation of activity on the at least one shard of the divided blockchain using the instantiated nodes and the simulated accounts, wallets, tokens, and transactions; testing the performance of the simulation using at least one performance metric).
identifying, by the processor of the blockchain node, one or more performance metrics based on the at least one testing criteria and at least one of: the plurality of performance values for the one or more nodes and the plurality of performance values for the blockchain network (column 2, lines 41-47, see the testing system comprises a cluster of private blockchain nodes instantiated on a server, likely a cloud-based system, and a control console that allows the user to set the number of nodes in the network and the number of clients for testing of a particular blockchain implementation. Performance would be measured in terms of transactions/second with testing of time to system stability) and (column 26, lines 42-55, see instantiating a plurality of blockchain nodes on at least one computer system in the computer network; assigning one of the nodes to be the lead node for processing of blocks; generating or import simulated accounts, wallets, tokens, and transactions; loading an implementation of at least one shard of a divided blockchain for testing; running a simulation of activity on the at least one shard of the divided blockchain using the instantiated nodes and the simulated accounts, wallets, tokens, and transactions; testing the performance of the simulation using at least one performance metric).
transmitting, by the transmitter of the blockchain node, the identified one or more performance metrics in response to the received testing instruction (column 17, lines 38-44, see each client 1520 a-c adds a certain demand on the network, resulting in a system total transaction throughput that may be measured by at least one performance metric, which is displayed in a performance metrics 1603 display. Optionally, a performance gauge 1604 may be added to provide a graphical display of system performance for a single metric or any combination of performance metrics).
the generated plurality of new blockchain transactions are submitted into the pending transaction queue over a predetermined period of time (column 18, lines 13-27, see then datasets are pre-generated in a database, such as, for example, Mongo database. Programs to generate accounts and wallets with tokens in Ethereum and to pre-load transactions in Ethereum queues without executing them are created. Transactions in out-of-box Ethereum are executed, and performance is measured… Then the test run and measurements are repeated using a 15-node Ethereum network. In phase two 1802, the system would decrease the Ethereum block time to six seconds, run transactions, and measure performance. Testing would be repeated, decreasing the Ethereum block time further, running transactions, and measuring performance, until we the minimum viable block time is established).
Kikinis doesn’t explicitly teach:
generating, by a processor of the blockchain node, a plurality of new blockchain transactions using random generation.
However, Qi teaches such use: (p. 7, 7th para., see add a random element to ensure that only one device can be authorized to broadcast information within a period of time. This random element is for the device to calculate a random hash value. Specifically, the block device calculates a string of 64-bit random numbers and letters according to the obtained input data, but only the hash value that meets the requirements can be accepted by the blockchain network as a proof of work. The block device obtains the accounting right corresponding to the task (transaction) of the consensus request, creates a new block and broadcasts the new block in the blockchain network, and other nodes verify and verify the new block. Add to their respective saved blockchains. In addition, the hash algorithm of the workload proof also realizes the serialization of historical information by using the information in each new block as the input value of the next hash algorithm, forming a traceable chain (blockchain)).
Kikinis and Qi are analogous art because they are from the same field of endeavor, monitoring program execution.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Kikinis and Qi before him or her, to modify the system of Kikinis to include the teachings of Qi, as a system for blockchain coordination, and accordingly it would enhance the system of Kikinis, which is focused on performance testing, because that would provide Kikinis with the ability to generate blockchain transactions, as suggested by Qi (p. 7, 7th para., p. 17, 7th para.).
Kikinis and Qi, in particular Kikinis doesn’t explicitly teach:
the blockchain network operates in a live environment.
However, Smith teaches such use: (Abstract, see the risk framework can then take those specified risks and convert them in to a plurality of tests that can be used to validate the organization's blockchain system. In one or more examples, the risk framework can provide a graphical user interface to user that allows them specify the risks they wish to manage within the blockchain computing system, and based on the user's inputs, can determine one or more continuous real-time validation tests to be performed on the blockchain computing system so as to characterize the risk specified by user using the risk framework) and (p. 5, [0064], see once a user has engaged the risk framework at step 304 to identify the risks they want analyzed during an audit, the process can move to step 306 wherein the user-preferences supplied to the risk framework can be converted in to one or more testing procedures to be performed during the real-time compliance testing of the customer's blockchain. As will be described in further detail below, the testing procedures can then be used by the validation/auditing software to in real-time audit the blockchain).
Kikinis, Qi and Smith are analogous art because they are from the same field of endeavor, monitoring program execution.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Kikinis, Qi and Smith before him or her, to modify the system of Kikinis and Qi, in particular Kikinis to include the teachings of Smith, as a system for the validation of a distributed system, and accordingly it would enhance the system of Kikinis, which is focused on performance testing, because that would provide Kikinis with the ability to test in an active environment as suggested by Smith (p. 5, [0064], p. 91, [0174]).
In regards to claim 2, Kikinis teaches:
identifying, by the processor of the blockchain node, a plurality of baseline values for the one or more nodes in the blockchain network and a plurality of baseline values for the blockchain network prior to submitting the plurality of new blockchain transactions, wherein the one or more performance metrics are further based on at least one of: the plurality of baseline values for the one or more nodes and the plurality of baseline values for the blockchain network (column 17, lines 60- column 18, line 17, see further, system 1700 is based on pre-generated datasets 1702 in the form of simulated clients 1520, 1520 a-c, simulated wallets 1530 a-f, and simulated transactions 1540. In this example, six nodes 1511 a-f have been instantiated in a private Ethereum-based network in the AWS cloud. Pre-generated and re-usable datasets could comprise 10,000 accounts (wallets), where each wallet holds a random number of tokens between 10 and 1000… FIG. 18 shows exemplary testing phases 1800 (stages) for testing of a divided blockchain database. In the implementation phases, the goal for each phase is to measure performance. Performance may be defined as N transactions/seconds (TPS), with the TPS stable after M seconds. In phase one 1801 of building such a system, a minimum five-node Ethereum network is established on AWS. Then datasets are pre-generated in a database, such as, for example, Mongo database. Programs to generate accounts and wallets with tokens in Ethereum and to pre-load transactions in Ethereum queues) (emphasis added).
In regards to claim 3, Kikinis doesn’t explicitly teach:
each of the plurality of new blockchain transactions is a random or pseudo-random 64-digit value.
However, Qi teaches such use: (p. 7, 7th para., see add a random element to ensure that only one device can be authorized to broadcast information within a period of time. This random element is for the device to calculate a random hash value. Specifically, the block device calculates a string of 64-bit random numbers and letters according to the obtained input data, but only the hash value that meets the requirements can be accepted by the blockchain network as a proof of work. The block device obtains the accounting right corresponding to the task (transaction) of the consensus request, creates a new block and broadcasts the new block in the blockchain network, and other nodes verify and verify the new block. Add to their respective saved blockchains. In addition, the hash algorithm of the workload proof also realizes the serialization of historical information by using the information in each new block as the input value of the next hash algorithm, forming a traceable chain (blockchain)).
Kikinis and Qi are analogous art because they are from the same field of endeavor, monitoring program execution.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Kikinis and Qi before him or her, to modify the system of Kikinis to include the teachings of Qi, as a system for blockchain coordination, and accordingly it would enhance the system of Kikinis, which is focused on performance testing, because that would provide Kikinis with the ability to generate blockchain transactions, as suggested by Qi (p. 7, 7th para., p. 17, 7th para.).
In regards to claim 4, Kikinis teaches:
the testing instruction is submitted to the blockchain node by an application program executed by the processor in the blockchain node (column 16, lines 63-67, see the system the runs a simulation using the simulated peer-to-peer distributed network 1510 using the simulated clients 1520, 1520 a-c, wallets 1530 a-f, and transactions 1540. The performance monitor 1550 and records various system performance metrics such as transactions per second (TPS), lag time between transactions, number of lost connections with nodes, failed transactions, failed block creation, system hangs, and other performance characteristics) and (column 26, lines 20-33, see instantiate a plurality of blockchain nodes on at least one computer system in the computer network; assign one of the nodes to be the lead node for processing of blocks; generate or import simulated accounts, wallets, tokens, and transactions; load an implementation of at least one shard of a divided blockchain for testing; run a simulation of activity on the at least one shard of the divided blockchain using the instantiated nodes and the simulated accounts, wallets, tokens, and transactions; test the performance of the simulation using at least one performance metric).
In regards to claim 6, Kikinis teaches:
the at least one testing criteria includes the predetermined period of time (column 16, lines 66-67, see the performance monitor 1550 and records various system performance metrics such as transactions per second (TPS), lag time between transactions, number of lost connections with nodes, failed transactions, failed block creation, system hangs, and other performance characteristics) and (column 2, lines 45-54, see performance would be measured in terms of transactions/second with testing of time to system stability. The test system allows for staged testing using generated databases, wallets, and accounts starting with simple 5-node networks, expanding to larger networks, then testing with decreased block validation times, continuing to testing using alternative, faster trust schemes, then testing implementation on divided blockchains, and finally testing on shared blockchains) (emphasis added).
In regards to claim 7, Kikinis teaches:
the at least one testing criteria includes at least one of: transactions per second, base transactions per second, maximum transactions per second, increase rate of transactions per second, time limit, transaction limit, and hash size (column 16, lines 66-67, see the performance monitor 1550 and records various system performance metrics such as transactions per second (TPS), lag time between transactions, number of lost connections with nodes, failed transactions, failed block creation, system hangs, and other performance characteristics) (emphasis added).
In regards to claim 8, Kikinis teaches:
the plurality of performance values for one or more nodes includes at least one of: processor usage, memory usage, confirmation time, level of synchronization, size of pending transaction queue, and number of transmitted messages (column 16, lines 66-67, see the performance monitor 1550 and records various system performance metrics such as transactions per second (TPS), lag time between transactions, number of lost connections with nodes, failed transactions, failed block creation, system hangs, and other performance characteristics) and (column 2, lines 45-54, see performance would be measured in terms of transactions/second with testing of time to system stability. The test system allows for staged testing using generated databases, wallets, and accounts starting with simple 5-node networks, expanding to larger networks, then testing with decreased block validation times, continuing to testing using alternative, faster trust schemes, then testing implementation on divided blockchains, and finally testing on shared blockchains) (emphasis added).
In regards to claim 9, Kikinis teaches:
A system for autonomous determination of performance metrics in a blockchain network through randomly generated transactions, comprising: (column 2, lines 38-40, see a system for performance testing of scalability implementations and testing of stability in blockchain database implementations) and (column 17, lines 65-67, see pre-generated and re-usable datasets could comprise 10,000 accounts (wallets), where each wallet holds a random number of tokens between 10 and 1000).
a blockchain network that manages a blockchain; and one or more nodes included in the blockchain network, where the one or more nodes includes a blockchain node and additional nodes, and the blockchain node includes (column 2, lines 41-47, see the testing system comprises a cluster of private blockchain nodes instantiated on a server, likely a cloud-based system, and a control console that allows the user to set the number of nodes in the network and the number of clients for testing of a particular blockchain implementation. Performance would be measured in terms of transactions/second with testing of time to system stability).
a receiver receiving a testing instruction, where the testing instruction includes at least one testing criteria (column 2, lines 41-47, see the testing system comprises a cluster of private blockchain nodes instantiated on a server, likely a cloud-based system, and a control console that allows the user to set the number of nodes in the network and the number of clients for testing of a particular blockchain implementation).
where a number of the plurality of blockchain transactions is based on the at least one testing criteria (column 2, lines 42-47, see the testing system comprises a cluster of private blockchain nodes instantiated on a server, likely a cloud-based system, and a control console that allows the user to set the number of nodes in the network and the number of clients for testing of a particular blockchain implementation. Performance would be measured in terms of transactions/second with testing of time to system stability) and (column 17, lines 34-42, see in early stage testing, the number of nodes might be restricted to fewer than 10, whereas in later stages, the number can be increased to test the blockchain implantation for larger system configurations. Each client 1520a-c adds a certain demand on the network, resulting in a system total transaction throughput that may be measured by at least one performance metric, which is displayed in a performance metrics 1603 display).
a transmitter submitting the generated plurality of new blockchain transactions into a pending transaction queue in the blockchain network (column 18, lines 13-27, see then datasets are pre-generated in a database, such as, for example, Mongo database. Programs to generate accounts and wallets with tokens in Ethereum and to pre-load transactions in Ethereum queues without executing them are created. Transactions in out-of-box Ethereum are executed, and performance is measured… Then the test run and measurements are repeated using a 15-node Ethereum network. In phase two 1802, the system would decrease the Ethereum block time to six seconds, run transactions, and measure performance. Testing would be repeated, decreasing the Ethereum block time further, running transactions, and measuring performance, until we the minimum viable block time is established).
the processor of the blockchain node monitors a plurality of performance values for one or more nodes in the blockchain network and a plurality of performance values for the blockchain network (column 18, lines 24-27, see testing would be repeated, decreasing the Ethereum block time further, running transactions, and measuring performance, until we the minimum viable block time is established) and (column 26, lines 42-55, see instantiating a plurality of blockchain nodes on at least one computer system in the computer network; assigning one of the nodes to be the lead node for processing of blocks; generating or import simulated accounts, wallets, tokens, and transactions; loading an implementation of at least one shard of a divided blockchain for testing; running a simulation of activity on the at least one shard of the divided blockchain using the instantiated nodes and the simulated accounts, wallets, tokens, and transactions; testing the performance of the simulation using at least one performance metric).
identifies one or more performance metrics based on the at least one testing criteria and at least one of: the plurality of performance values for the one or more nodes and the plurality of performance values for the blockchain network (column 2, lines 41-47, see the testing system comprises a cluster of private blockchain nodes instantiated on a server, likely a cloud-based system, and a control console that allows the user to set the number of nodes in the network and the number of clients for testing of a particular blockchain implementation. Performance would be measured in terms of transactions/second with testing of time to system stability) and (column 26, lines 42-55, see instantiating a plurality of blockchain nodes on at least one computer system in the computer network; assigning one of the nodes to be the lead node for processing of blocks; generating or import simulated accounts, wallets, tokens, and transactions; loading an implementation of at least one shard of a divided blockchain for testing; running a simulation of activity on the at least one shard of the divided blockchain using the instantiated nodes and the simulated accounts, wallets, tokens, and transactions; testing the performance of the simulation using at least one performance metric).
the transmitter of the blockchain node transmits the identified one or more performance metrics in response to the received testing instruction (column 17, lines 38-44, see each client 1520 a-c adds a certain demand on the network, resulting in a system total transaction throughput that may be measured by at least one performance metric, which is displayed in a performance metrics 1603 display. Optionally, a performance gauge 1604 may be added to provide a graphical display of system performance for a single metric or any combination of performance metrics).
the generated plurality of new blockchain transactions are submitted into the pending transaction queue over a predetermined period of time (column 18, lines 13-27, see then datasets are pre-generated in a database, such as, for example, Mongo database. Programs to generate accounts and wallets with tokens in Ethereum and to pre-load transactions in Ethereum queues without executing them are created. Transactions in out-of-box Ethereum are executed, and performance is measured… Then the test run and measurements are repeated using a 15-node Ethereum network. In phase two 1802, the system would decrease the Ethereum block time to six seconds, run transactions, and measure performance. Testing would be repeated, decreasing the Ethereum block time further, running transactions, and measuring performance, until we the minimum viable block time is established).
Kikinis doesn’t explicitly teach:
a processor generating a plurality of new blockchain transactions using random generation.
However, Qi teaches such use: (p. 7, 7th para., see add a random element to ensure that only one device can be authorized to broadcast information within a period of time. This random element is for the device to calculate a random hash value. Specifically, the block device calculates a string of 64-bit random numbers and letters according to the obtained input data, but only the hash value that meets the requirements can be accepted by the blockchain network as a proof of work. The block device obtains the accounting right corresponding to the task (transaction) of the consensus request, creates a new block and broadcasts the new block in the blockchain network, and other nodes verify and verify the new block. Add to their respective saved blockchains. In addition, the hash algorithm of the workload proof also realizes the serialization of historical information by using the information in each new block as the input value of the next hash algorithm, forming a traceable chain (blockchain)).
Kikinis and Qi are analogous art because they are from the same field of endeavor, monitoring program execution.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Kikinis and Qi before him or her, to modify the system of Kikinis to include the teachings of Qi, as a system for blockchain coordination, and accordingly it would enhance the system of Kikinis, which is focused on performance testing, because that would provide Kikinis with the ability to generate blockchain transactions, as suggested by Qi (p. 7, 7th para., p. 17, 7th para.).
Kikinis and Qi, in particular Kikinis doesn’t explicitly teach:
the blockchain network operates in a live environment.
However, Smith teaches such use: (Abstract, see the risk framework can then take those specified risks and convert them in to a plurality of tests that can be used to validate the organization's blockchain system. In one or more examples, the risk framework can provide a graphical user interface to user that allows them specify the risks they wish to manage within the blockchain computing system, and based on the user's inputs, can determine one or more continuous real-time validation tests to be performed on the blockchain computing system so as to characterize the risk specified by user using the risk framework) and (p. 5, [0064], see once a user has engaged the risk framework at step 304 to identify the risks they want analyzed during an audit, the process can move to step 306 wherein the user-preferences supplied to the risk framework can be converted in to one or more testing procedures to be performed during the real-time compliance testing of the customer's blockchain. As will be described in further detail below, the testing procedures can then be used by the validation/auditing software to in real-time audit the blockchain).
Kikinis, Qi and Smith are analogous art because they are from the same field of endeavor, monitoring program execution.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Kikinis, Qi and Smith before him or her, to modify the system of Kikinis and Qi, in particular Kikinis to include the teachings of Smith, as a system for the validation of a distributed system, and accordingly it would enhance the system of Kikinis, which is focused on performance testing, because that would provide Kikinis with the ability to test in an active environment as suggested by Smith (p. 5, [0064], p. 91, [0174]).
In regards to claim 10, Kikinis teaches:
identifies a plurality of baseline values for the one or more nodes in the blockchain network and a plurality of baseline values for the blockchain network prior to submitting the plurality of new blockchain transactions, and the one or more performance metrics are further based on at least one of: the plurality of baseline values for the one or more nodes and the plurality of baseline values for the blockchain network (column 17, lines 60- column 18, line 17, see further, system 1700 is based on pre-generated datasets 1702 in the form of simulated clients 1520, 1520 a-c, simulated wallets 1530 a-f, and simulated transactions 1540. In this example, six nodes 1511 a-f have been instantiated in a private Ethereum-based network in the AWS cloud. Pre-generated and re-usable datasets could comprise 10,000 accounts (wallets), where each wallet holds a random number of tokens between 10 and 1000… FIG. 18 shows exemplary testing phases 1800 (stages) for testing of a divided blockchain database. In the implementation phases, the goal for each phase is to measure performance. Performance may be defined as N transactions/seconds (TPS), with the TPS stable after M seconds. In phase one 1801 of building such a system, a minimum five-node Ethereum network is established on AWS. Then datasets are pre-generated in a database, such as, for example, Mongo database. Programs to generate accounts and wallets with tokens in Ethereum and to pre-load transactions in Ethereum queues) (emphasis added).
In regards to claim 11, Kikinis doesn’t explicitly teach:
each of the plurality of new blockchain transactions is a random or pseudo-random 64-digit value.
However, Qi teaches such use: (p. 7, 7th para., see add a random element to ensure that only one device can be authorized to broadcast information within a period of time. This random element is for the device to calculate a random hash value. Specifically, the block device calculates a string of 64-bit random numbers and letters according to the obtained input data, but only the hash value that meets the requirements can be accepted by the blockchain network as a proof of work. The block device obtains the accounting right corresponding to the task (transaction) of the consensus request, creates a new block and broadcasts the new block in the blockchain network, and other nodes verify and verify the new block. Add to their respective saved blockchains. In addition, the hash algorithm of the workload proof also realizes the serialization of historical information by using the information in each new block as the input value of the next hash algorithm, forming a traceable chain (blockchain)).
Kikinis and Qi are analogous art because they are from the same field of endeavor, monitoring program execution.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having the teaching of Kikinis and Qi before him or her, to modify the system of Kikinis to include the teachings of Qi, as a system for blockchain coordination, and accordingly it would enhance the system of Kikinis, which is focused on performance testing, because that would provide Kikinis with the ability to generate blockchain transactions, as suggested by Qi (p. 7, 7th para., p. 17, 7th para.).
In regards to claim 12, Kikinis teaches:
testing instruction is submitted to the blockchain node by an application program executed by the processor in the blockchain node (column 16, lines 63-67, see the system the runs a simulation using the simulated peer-to-peer distributed network 1510 using the simulated clients 1520, 1520 a-c, wallets 1530 a-f, and transactions 1540. The performance monitor 1550 and records various system performance metrics such as transactions per second (TPS), lag time between transactions, number of lost connections with nodes, failed transactions, failed block creation, system hangs, and other performance characteristics) and (column 26, lines 20-33, see instantiate a plurality of blockchain nodes on at least one computer system in the computer network; assign one of the nodes to be the lead node for processing of blocks; generate or import simulated accounts, wallets, tokens, and transactions; load an implementation of at least one shard of a divided blockchain for testing; run a simulation of activity on the at least one shard of the divided blockchain using the instantiated nodes and the simulated accounts, wallets, tokens, and transactions; test the performance of the simulation using at least one performance metric).
In regards to claim 13, Kikinis teaches:
the generated plurality of new blockchain transactions are submitted into the pending transaction queue over a predetermined period of time (column 18, lines 13-27, see then datasets are pre-generated in a database, such as, for example, Mongo database. Programs to generate accounts and wallets with tokens in Ethereum and to pre-load transactions in Ethereum queues without executing them are created. Transactions in out-of-box Ethereum are executed, and performance is measured… Then the test run and measurements are repeated using a 15-node Ethereum network. In phase two 1802, the system would decrease the Ethereum block time to six seconds, run transactions, and measure performance. Testing would be repeated, decreasing the Ethereum block time further, running transactions, and measuring performance, until we the minimum viable block time is established).
In regards to claim 14, Kikinis teaches:
the at least one testing criteria includes the predetermined period of time (column 16, lines 66-67, see the performance monitor 1550 and records various system performance metrics such as transactions per second (TPS), lag time between transactions, number of lost connections with nodes, failed transactions, failed block creation, system hangs, and other performance characteristics) and (column 2, lines 45-54, see performance would be measured in terms of transactions/second with testing of time to system stability. The test system allows for staged testing using generated databases, wallets, and accounts starting with simple 5-node networks, expanding to larger networks, then testing with decreased block validation times, continuing to testing using alternative, faster trust schemes, then testing implementation on divided blockchains, and finally testing on shared blockchains) (emphasis added).
In regards to claim 15, Kikinis teaches:
the at least one testing criteria includes at least one of: transactions per second, base transactions per second, maximum transactions per second, increase rate of transactions per second, time limit, transaction limit, and hash size (column 16, lines 66-67, see the performance monitor 1550 and records various system performance metrics such as transactions per second (TPS), lag time between transactions, number of lost connections with nodes, failed transactions, failed block creation, system hangs, and other performance characteristics) (emphasis added).
In regards to claim 16, Kikinis teaches:
the plurality of performance values for one or more nodes includes at least one of: processor usage, memory usage, confirmation time, level of synchronization, size of pending transaction queue, and number of transmitted messages (column 16, lines 66-67, see the performance monitor 1550 and records various system performance metrics such as transactions per second (TPS), lag time between transactions, number of lost connections with nodes, failed transactions, failed block creation, system hangs, and other performance characteristics) and (column 2, lines 45-54, see performance would be measured in terms of transactions/second with testing of time to system stability. The test system allows for staged testing using generated databases, wallets, and accounts starting with simple 5-node networks, expanding to larger networks, then testing with decreased block validation times, continuing to testing using alternative, faster trust schemes, then testing implementation on divided blockchains, and finally testing on shared blockchains) (emphasis added).
Conclusion
7. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US Patent Application Publications
Kikinis 20190140935 teaches a system for performance testing of scalability implementations and testing of stability in blockchain database implementations. The testing system comprises a cluster of private blockchain nodes instantiated on a network and a control console that allows the user to set the number of nodes in the network and the number of clients for testing of a particular blockchain implementation. Performance metrics are established and tested.
Liu 12135640 teaches a general blockchain performance evaluation method based on a dynamic proxy and a smart contract, and the method includes following steps: obtaining an automation configuration item script, configuring a chain system to be tested based on the automation configuration item script, and designing a proxy server network interface of the chain system to be tested; obtaining a general hierarchical test workload, and obtaining an environmental test result of the chain system to be tested based on the proxy server network interface and the general hierarchical test workload; obtaining a workload test execution result based on the proxy server network interface and the environmental test result; and carrying out a multi-dimensional evaluation on the workload test execution result to complete a blockchain performance evaluation.
8. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Evral Bodden whose telephone number is 571-272-3455. The examiner can normally be reached on Monday to Friday from 9am to 5pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Cha Do, can be reached at telephone number 571-272-3721. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
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) Form at https://www.uspto.gov/patents/uspto-automatedinterview-request-air-form.
If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/EVRAL E BODDEN/Primary Examiner, Art Unit 2193
Prosecution Insights