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 .
The Office Action is in response to claims filed 06/03/2026.
Claims 1-20 are pending.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 9-19 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 9 recites the limitation "the scheduling rules" in the limitation starting with “deploying.” There is insufficient antecedent basis for this limitation in the claim. Claims 10-19 are also rejected by virtue of their dependency on claim 9.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4 are rejected is/are rejected under 35 U.S.C. 103 as being unpatentable over Novotny et al. Pat. No. US 20210240673 A1 (hereafter Novotny) in view of Li Pat. No. US 20180240114 A1 (hereafter Li) and further in view of Niederle Pat. No. US 20250299788 A1 (hereafter Niederle), Carey et al. Pat. No. US 20230305870 A1 (hereafter Carey), Chen et al. Pat. No. US 20090168092 A1 (hereafter Chen), Morehead Pat. No. US 20220067562 A1 (hereafter Morehead), and Abdelrahman et al. Pat. No. US 20240330927 A1 (hereafter Abdelrahman).
With regard to claim 1, Novotny teaches a computer-implemented method for job scheduling in a distributed ledger environment, comprising (¶ [0028] states “the following detailed description of the embodiments of at least one of a method, apparatus, non-transitory computer readable medium and system.” ¶ [0044] states “FIG. 1 illustrates a blockchain network 100 which implements load balancing according to example embodiments.” Examiner’s Note: blockchains are a type of distributed ledger):
receiving, at a data reception module, a range of transactional and operational data from a plurality of nodes within a distributed ledger network, wherein the transactional and operational data includes details of transaction types, sizes, and priorities (¶ [0055] states “simulation responses are provided from the endorser peer nodes 281-283 to the client node 260. In 293, the client 260 identifies metrics (latency data) based on the simulation responses.” ¶ [0070] states “the probing transaction is a special transaction which invokes simulation/execution of a chaincode that is installed on the blockchain peer.” ¶ [0110] states “a new data block 730 (also referred to as a data block) that is stored on the blockchain 722 of the distributed ledger 720 may include multiple data segments such as a block header 740, block data 750 (block data section), and block metadata 760.” FIG. 7B shows “type.” Examiner’s Note: the data received is transactional because it is the result of a special transaction. The data received is operational because it includes latency data. The block data in FIG. 7B includes a type which is the transaction type. Block data 750 also includes N transactions which is a size);
filtering, by the data reception module, the received transactional data based on predefined criteria including at least one of transaction type, transaction size, transaction priority, transaction urgency, or resource intensity (¶ [0113] states “Metadata fields may include signature on block creation, a reference to a last configuration block, a transaction filter identifying valid and invalid transactions within the block” and “The transaction filter may include a byte array of a size equal to the number of transactions that are included in the block data 750 and a validation code identifying whether a transaction was valid/invalid.” FIG. 7B shows “type.” Examiner’s Note: transactions are filtered based on whether they are valid or not. The filtering is based on the number of transactions in the block data, or resource intensity);
analyzing, by a job analysis module, the filtered data to ascertain job execution parameters, wherein the analysis involves evaluating against real-time network conditions and an array of business rules applicable to transaction processing within the distributed ledger network (¶ [0053] states “receive respective response from the endorser peers 281, 282, and 283, in 292. Based on the responses, the client 260 may identify latency metrics and select one or more peers for endorsement, in 293. Here, the endorsement policy requires only one endorser peer to be selected.” ¶ [0085] states “the client 420 selects the “N” best performing peers (e.g., based on their up-to-date tx processing latencies stored in the latency list 430).” Examiner’s Note: the node or nodes that are selected to perform endorsement are the job execution parameters. Selecting the best performing peers based on latency is analyzing based on “real-time network conditions.” The endorsement policy, or number of endorsements required, is the “array of business rules applicable to transaction processing”);
processing, by a photonic quantum computing system, the job execution parameters to optimize job scheduling strategies over a plurality of optimization parameters including transaction throughput, latency, network bandwidth, block confirmation time, block size, validation time, and storage resource, the processing including quantum annealing and simulations to resolve scheduling scenarios that include merging a plurality of jobs having identical inputs and outputs and splitting a job into a plurality of subordinate jobs, and to generate a dynamic job schedule configuration that maps the plurality of optimization parameters on a temporal axis and that is regenerated at regular intervals (¶ [0085] states “the client 420 selects the “N” best performing peers (e.g., based on their up-to-date tx processing latencies stored in the latency list 430).” Examiner’s Note: the selected nodes are processed to form optimized job scheduling strategies);
deploying, by a job orchestration engine, the dynamic smart contracts to one or more target distributed ledgers within a blockchain network (¶ [0055] states “The client node 260 initiates the transaction 294 by constructing and sending a request to the peer node 281, which is an endorser.” ¶ [0050] states “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.” See FIG. 2B. Examiner’s Note: after the client selects the peer nodes to perform the endorsement operation, the client sends a transaction to the peer node. According to ¶ [0050], transactions are “the execution of the smart contract code,” so it is interpreted that the client is deploying a smart contract to the endorser peer node);
executing, by the job orchestration engine, jobs on nodes hosting the target distributed ledger in accordance with the encoded conditional execution logic, and wherein the execution includes a sequence of operations determined based on the optimized job scheduling strategies (¶ [0033] states “Blockchain transactions associated with this application can be “endorsed” before being committed to the blockchain while transactions, which are not endorsed, are disregarded” and “When a client sends the transaction to the peers specified in the endorsement policy, the transaction is executed to validate the transaction.” ¶ [0070] states “In response to receiving the probing transaction 422, the blockchain peer 411 may simulate the chaincode identified by the chaincode ID 423 using the simulation data, and generate a response 424 which includes simulated results, timestamps 425, and the like.” Examiner’s Note: the transaction performed at the peer node during the endorsement process is the job. The endorsement operations are performed because of the optimized job scheduling strategy selecting the best performing peer nodes);
monitoring, by a system monitoring module, the execution of jobs on the distributed ledger and gathering comprehensive performance data including system load and transaction confirmation times (¶ [0080] states “The client 420 may separately probe each chaincode on a periodic basis and monitor/track latency values in a client records the each peer's transaction processing latency.” ¶ [0075] states “T.sub.2: The time before (or when) the blockchain peer 411 begins to simulate the transaction. T.sub.3: The time after (or when) the blockchain peer 411 finishes simulating the transaction.” ¶ [0070] states “the probing transaction is a special transaction which invokes simulation/execution of a chaincode that is installed on the blockchain peer 411.” FIG. 2B and 4A shows the client receiving data from the peer. Examiner’s Note: T.sub.3 is the transaction confirmation time. Monitoring the latency of the simulated transaction is monitoring the execution of jobs on the distributed ledger because latency is affected by resource utilization. The more jobs that are executing, the more latency there may be. Latency is a type of system load);
providing, by the system monitoring module, feedback to the job analysis module based on the monitoring, wherein the feedback includes data indicative of network performance deviations from an optimal state (¶ [0079] states “The client 420 receives responses from each of the blockchain peers 411-415, determines round-trip latency values 432 and chaincode simulation latency values 433 and 434, and stores the round-trip latency values 432 and the chaincode simulation latency values 433 and 434 within a latency list 430. Here, the latency values are also stored with an identifier 431 of the respective peers.” ¶ [0083] states “the latency list 430 managed by the client 420 may indicate that a latency value(s) of a blockchain peer is unstable.” Examiner’s Note: the client storing the latency information in the latency list, is the providing of feedback. When the latency values of a blockchain peer is unstable, that is the “feedback [including] data indicative of network performance deviations from an optimal state”);
adjusting, in real-time by the job analysis module, the job execution parameters in response to the feedback to improve job execution efficiency and network performance (¶ [0085] states “For each group of peers mandated by the consensus/endorsement policy, the client 420 selects the “N” best performing peers (e.g., based on their up-to-date tx processing latencies stored in the latency list 430). The client 430 selects peers 412, 414, and 415, and waits for endorsement results from the selected peers.” ¶ [0082] states “the client 420 determines that peers 412, 414, and 415 have the most efficient total processing latency value (combination of round-trip latency 432 and chaincode simulation latency 433) and sends endorsement requests to these peers accordingly.” ¶ [0080] states “The client 420 may separately probe each chaincode on a periodic basis and monitor/track latency values in a client records the each peer's transaction processing latency.” Examiner’s Note: the nodes that are chosen for endorsement are the job execution parameters. Therefore, selecting nodes to perform the endorsement based on inquired latency information is adjusting the job execution parameters. The nodes chosen are based on latency metrics, or feedback, to select the best performing nodes for endorsement. Since the monitoring is done on a periodic basis, the system is continually adjusting which nodes will perform the endorsement operation);
and dynamically updating, by the job orchestration engine, the job scheduling on the distributed ledger in response to the adjusted job execution parameters to maintain or enhance optimal network operation (¶ [0089] states “the blockchain network enables load balancing among the peers so that peer resources can be utilized effectively to avoid hotspots as well as under used peers.” ¶ [0082] states “the client 420 determines that peers 412, 414, and 415 have the most efficient total processing latency value (combination of round-trip latency 432 and chaincode simulation latency 433) and sends endorsement requests to these peers accordingly.” Examiner’s Note: sending endorsement requests to newly selected peers is updating the job scheduling because it is selecting new nodes to perform endorsement).
Novotny does not explicitly teach transaction priorities.
However, in an analogous art, Li teaches receiving, at a data reception module, a range of transactional and operational data from a plurality of nodes within a distributed ledger network, wherein the transactional and operational data includes details of transaction types, sizes, and priorities (¶ [0036] states “the selection of the transaction requests can be based, for example, on priority. For example, highest-priority transaction requests can be chosen for inclusion into the pre-processed block.” ¶ [0056] states “the first block chain node 206 can obtain transaction requests with a transaction type higher than a set priority from the memory.”).
filtering, by the data reception module, the received transactional data based on predefined criteria including at least one of transaction type, transaction size, transaction priority, transaction urgency, or resource intensity (¶ [0056] states “For example, by using a transaction type as a constraint or a filter, the first block chain node 206 can obtain transaction requests of transaction types having priorities higher than the transaction type from the memory.”).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine receiving transaction types and priority and then filtering based on transaction type and priority of Li with the blockchain environment of Novotny. A person having ordinary skill in the art would have been motivated to make this combination for the purpose of being able to broadcast high priority data (¶ [0036] – [0037] states “For example, highest-priority transaction requests can be chosen for inclusion into the pre-processed block. From 108, method 100 proceeds to 110. At 110, the pre-processed block is broadcast to the second block chain nodes.” By prioritizing, the most important transactions can be processed first. Further, Li ¶ [0005] teaches that “First, adverse effects on consensus verification of transaction requests that are caused by a network failure can be reduced. Second, transaction processing accuracy of the block chain network can be improved.”).
Novotny and Li do not explicitly teach processing by a photonic quantum computing system.
However, in an analogous art, Niederle teaches processing, by a photonic quantum computing system, the job execution parameters to optimize job scheduling strategies over a plurality of optimization parameters including transaction throughput, latency, network bandwidth, block confirmation time, block size, validation time, and storage resource, the processing including quantum annealing and simulations to resolve scheduling scenarios that include merging a plurality of jobs having identical inputs and outputs and splitting a job into a plurality of subordinate jobs, and to generate a dynamic job schedule configuration that maps the plurality of optimization parameters on a temporal axis and that is regenerated at regular intervals (¶ [0004] states “a probe list including probe data for a plurality of probes, wherein the probe data for a probe comprises a probe identification and a task associated with the probe identification, wherein a task is indicative of one or more operations to be performed with a predetermined timing by a laboratory equipment on the probe.” ¶ [0075] states “In particular, the job scheduler is configured to formulate a schedule problem, for instance, based on a probe list, to provide at least a part of the schedule problem to the quantum computer for calculation. The schedule solution, in particular, the results of the quantum computer calculation indicative for the schedule solution, are then again provided to the job scheduler such that the job scheduler can determine based on the results of the quantum computer calculation a job schedule and provide respective schedule control signals to a laboratory equipment to be controlled.” ¶ [0054] states “Quantum computing devices are based on quantum elements adhering to the physics of quantum mechanics, such as superconductors, ions, atoms, quantum dots, photons, particle spins, bosons or the like.” ¶ [0023] states “the scheduling problem preparation unit is adapted to prepare the scheduling problem to be solvable on a quantum computer that refers to a quantum annealer.” ¶ [0021] states “the preparation of the at least a part of the scheduling problem can refer to any kind of preparation and/or transformation of the scheduling problem such that the scheduling problem is performable utilizing a quantum computation.”).
generating, by a generative artificial intelligence (AI) engine interfaced with the photonic quantum computing system, dynamic smart contracts that encapsulate the optimized job scheduling strategies, wherein the generative artificial intelligence engine receives the optimized job scheduling strategies from the photonic quantum computing system and encodes the received optimized job scheduling strategies into conditional execution logic of the dynamic smart contracts based on real-time network bandwidth availability (¶ [0079] states “The quantum computer interface unit 803 is configured to provide an interface for interfacing with the quantum computer 810 for utilizing the quantum computer for calculating the scheduling problem. Moreover, the quantum computer interface unit 803 can also be configured to receive the result of the quantum computation of the scheduling problem from the quantum computer 810, wherein the result is indicative of the optimized scheduling problem.” ¶ [0081] states “The schedule determination unit 804 is then adapted to determine a schedule for the probe list based on the received result of the quantum computation.” ¶ [0076] states “the apparatus 800 can comprise one or more processors that are configured to provide the functions defined by the units of the apparatus 800.” Examiner’s Note: a schedule is generated by the apparatus 800 that encapsulates the optimal job scheduling strategies);
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the photonic quantum computing system to optimize a schedule of Niederle with the endorsement node selection and transaction distribution in a blockchain environment of Novotny and the transaction priorities of Li. A person having ordinary skill in the art would have been motivated to make this combination because quantum computers “perform certain computations more efficiently than classical digital computers” (¶ [0014]). Additionally, ¶ [0003] states “It is an object of the present invention to provide an apparatus, a method and a computing program product that allow for a less time consuming, less computational resource intensive and more objective optimization of a laboratory scheduling in an automatic laboratory environment. Moreover, the apparatus, method and computing program product allow for a more efficient usage of available laboratory equipment and for an increase in the level of laboratory automation.”
Novotny, Li, and Niederle do not explicitly teach optimization parameters including at least a block confirmation time.
However, in an analogous art, Carey teaches processing, by a photonic quantum computing system, the job execution parameters to optimize job scheduling strategies over a plurality of optimization parameters including transaction throughput, latency, network bandwidth, block confirmation time, block size, validation time, and storage resource, the processing including quantum annealing and simulations to resolve scheduling scenarios that include merging a plurality of jobs having identical inputs and outputs and splitting a job into a plurality of subordinate jobs, and to generate a dynamic job schedule configuration that maps the plurality of optimization parameters on a temporal axis and that is regenerated at regular intervals (¶ [0076] states “In a first variation, S300 includes querying one or more managed nodes for the blockchain data.” ¶ [0072] states “Determining blockchain data indicative of a blockchain event S300 (e.g., introspecting the blockchain) functions to determine that a blockchain event is about to happen, determine when a blockchain event will happen, determine that a blockchain event is happening, and/or determine that a blockchain event has occurred … In a first variant, this information is used to detect the blockchain event.” ¶ [0075] states “The blockchain data can include: whether the blockchain event is happening; when the next blockchain event will occur (… block validation, block confirmation, and/or other blockchain event, etc.); … blockchain parameters (e.g., block height, transactions per second, block time or confirmation time, etc.); and/or any other suitable data.” ¶ [0092] states “S700 preferably allocates computing resources in real- or near-real time, such that the nodes are allocated the resources immediately or after a short delay. Additionally or alternatively, S700 can schedule future computing resource allocation for one or more nodes.” See FIG. 3. ¶ [0074] states “S300 can be performed: periodically (e.g., at the block generation rate or a fraction thereof); at a varying frequency (e.g., more frequently with temporal, block position, or transaction position proximity to the next blockchain event); constantly; randomly; and/or at any other time.” See FIG. 4. Examiner’s Note: step S700 follows S300 and is related to optimizing and scheduling. Therefore, the scheduling is based off the optimization parameters determined in S300 and the schedule maps the optimization parameters to a temporal axis. S300 can be performed periodically, so step S700 is also performed periodically. See FIG. 4 to see the loop starting at S300).
generating, by a generative artificial intelligence (AI) engine interfaced with the photonic quantum computing system, dynamic smart contracts that encapsulate the optimized job scheduling strategies, wherein the generative artificial intelligence engine receives the optimized job scheduling strategies from the photonic quantum computing system and encodes the received optimized job scheduling strategies into conditional execution logic of the dynamic smart contracts based on real-time network bandwidth availability (¶ [0075] states “The blockchain data can include: whether the blockchain event is happening; when the next blockchain event will occur (… block validation, block confirmation, and/or other blockchain event, etc.); … blockchain parameters (e.g., block height, transactions per second, block time or confirmation time, etc.); and/or any other suitable data.” ¶ [0092] states “S700 preferably allocates computing resources in real- or near-real time, such that the nodes are allocated the resources immediately or after a short delay. Additionally or alternatively, S700 can schedule future computing resource allocation for one or more nodes.” ¶ [0037] states “Examples of computing resources (e.g., management system resources) that can be provided can include: … memory (e.g., addresses, blocks, memory locations, cache space, contiguous free space, management system memory, etc.) … network throughput (e.g., within the machine itself, Internet bandwidth, etc.)”).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine scheduling of allocation of resources based on optimization parameters of Carey with the blockchain environment of Novotny, transaction priority of Li, and the quantum computing system of Niederle. A person having ordinary skill in the art would have been motivated to make this combination for the purpose of “dynamically allocating computing resources to the node based on current and/or anticipated node participation in the blockchain event (e.g., by setting the process priority for the node)” which “allows for the same number of nodes to be hosted by less machines, which leads to lower overall resource, energy, and cost consumption” (¶ [0016]).
Novotny, Li, Niederle, and Carey do not explicitly teach merging a plurality of jobs having identical inputs and outputs.
However, in an analogous art, Chen teaches processing, by a photonic quantum computing system, the job execution parameters to optimize job scheduling strategies over a plurality of optimization parameters including transaction throughput, latency, network bandwidth, block confirmation time, block size, validation time, and storage resource, the processing including quantum annealing and simulations to resolve scheduling scenarios that include merging a plurality of jobs having identical inputs and outputs and splitting a job into a plurality of subordinate jobs, and to generate a dynamic job schedule configuration that maps the plurality of optimization parameters on a temporal axis and that is regenerated at regular intervals (¶ [0018] states “when the job queue executes job entities with identical parameter settings, it would adjust the execution time for job entities, update parameter settings or combine identical job entities according to the parameter settings, privilege value, or data dependency of job entities.” Examiner’s Note: identical jobs have identical inputs and outputs)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the combining of identical job entities of Chen with the blockchain environment of Novotny, transaction priority of Li, the quantum computing system of Niederle, and the optimization parameters of Carey. A person having ordinary skill in the art would have been motivated to make this combination because “the storage space of job queue will not be occupied by identical job entities, thereby allowing the storage of job entities corresponding to other job requests and preventing overflow, which tends to cause operating error of the network system.” (¶ [0018]).
Novotny, Li, Niederle, Carey, and Chen do not explicitly teach splitting a job and a generative artificial intelligence engine interfaced with the photonic quantum computing system.
However, in an analogous art, Morehead teaches processing, by a photonic quantum computing system, the job execution parameters to optimize job scheduling strategies over a plurality of optimization parameters including transaction throughput, latency, network bandwidth, block confirmation time, block size, validation time, and storage resource, the processing including quantum annealing and simulations to resolve scheduling scenarios that include merging a plurality of jobs having identical inputs and outputs and splitting a job into a plurality of subordinate jobs, and to generate a dynamic job schedule configuration that maps the plurality of optimization parameters on a temporal axis and that is regenerated at regular intervals (¶ [0007] states “The present general inventive concept also provides an AI system that is designed and/or configured to decompose a larger problem into a plurality of smaller problems to be solved. Each node of the AI system formed as a network will become a solver of a smaller problem of the decomposed larger problem.”)
generating, by a generative artificial intelligence (AI) engine interfaced with the photonic quantum computing system, dynamic smart contracts that encapsulate the optimized job scheduling strategies, wherein the generative artificial intelligence engine receives the optimized job scheduling strategies from the photonic quantum computing system and encodes the received optimized job scheduling strategies into conditional execution logic of the dynamic smart contracts based on real-time network bandwidth availability (¶ [0103] states “The cycle begins with the classical computer 106 reading any received signals, whether they come from the input or the output channels 102, 104. The classical computer 106 processes this data and may use the data to configure the node's quantum computer 108. Next, the quantum computer 108 executes a full quantum computation, which includes the application of a set of quantum gates to its qubits, and then a measure operation. The output of the measure operation provides a set of classical bits which the classical computer 106 may process and/or send via either the input or the output channels 102, 104.”)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the AI system that decomposes larger problems into smaller problems that are then processed on nodes having classical and quantum computers of Morehead with the blockchain environment of Novotny, transaction priority of Li, the quantum computing system of Niederle, the optimization parameters of Carey, and the identical job merging of Chen. A person having ordinary skill in the art would have been motivated to make this combination because “The quantum computer may be configured to process computations determined difficult for the classical computer” (¶ [0013]). Additionally, the Morehead teaches that the artificial intelligence system can perform processing to achieve “a goal including minimizing a number of duplicate computations, maximizing signal robustness, and maximizing coding efficiency” (¶ [0028]).
Novotny, Li, Niederle, Carey, Chen, and Morehead do not explicitly teach generating smart contracts to encapsulate optimized job scheduling strategies.
However, in an analogous art, Abdelrahman teaches generating, by a generative artificial intelligence (AI) engine interfaced with the photonic quantum computing system, dynamic smart contracts that encapsulate the optimized job scheduling strategies, wherein the generative artificial intelligence engine receives the optimized job scheduling strategies from the photonic quantum computing system and encodes the received optimized job scheduling strategies into conditional execution logic of the dynamic smart contracts based on real-time network bandwidth availability (¶ [0007] states “processing the smart contract logic description with a generative artificial intelligence model to generate smart contract code.” ¶ [0062] states “The smart contract logic description represents a conversion of the input logic described in the text 53 into smart code logic, e.g., such illustrating example logic paths as would be executed on the blockchain in response to different conditions.” Examiner’s Notes: “logic paths … executed … in response to different conditions” is interpreted as conditional execution logic);
executing, by the job orchestration engine, jobs on nodes hosting the target distributed ledger in accordance with the encoded conditional execution logic, and wherein the execution includes a sequence of operations determined based on the optimized job scheduling strategies (¶ [0041] states “The AI system uses generative AI configured to receive smart contract text-based documents as input and provide more optimized and secure smart contract computer code as output. In an example, the output is configured to be executed on a distributed ledger network.” [0062] states “The smart contract logic description represents a conversion of the input logic described in the text 53 into smart code logic, e.g., such illustrating example logic paths as would be executed on the blockchain in response to different conditions.” Examiner’s Note: when the smart contract is executed, it is executed according to the encoded execution logic because the smart contracted included the conditional logic).
As a result of the combination of Novotny, Niederle, Carey, and Morehead, an optimized job schedule for a task in a blockchain environment is determined. This job schedule is based on network bandwidth. It would have been obvious for the generative AI system of Abdelrahman to receive as input the optimized job schedule determined by Novotny, Niederle, Carey, and Morehead. The generative AI system of Abdelrahman then processes the input to output a smart contract. Therefore, the generated smart contract encodes the optimized job scheduling strategies that are based on network bandwidth availability. Further, the smart contract would be executed according to the teachings of Novotny and Abdelrahman.
A person having ordinary skill in the art would have been motivated to make this combination for the purpose of having “improved security for the smart contract, thereby making the smart contract less vulnerable to hacking attacks. Additional advantages of systems and methods disclosed herein include improving logic and code design, resulting in more efficient smart contracts being executed on the distributed ledger” (¶ [0040]). Further, Abdelrahman teaches that the optimized smart contract code optimizes resource usage (¶ [0110] states “the generative AI model is trained or fine tuned using a large set of training examples of well optimized and highly secured smart contract code from bridge examples. Optimization includes optimization for computational complexity (e.g., efficiency), memory usage, processor usage, etc.”).
With regard to claim 2, Novotny, Li, Niederle, Carey, Chen, Morehead, and Abdelrahman teach the method of claim 1. Li additionally teaches further comprising prioritizing the transactional data based on the urgency associated with each transaction type during the filtering step (¶ [0056] states “For example, by using a transaction type as a constraint or a filter, the first block chain node 206 can obtain transaction requests of transaction types having priorities higher than the transaction type from the memory.”).
With regard to claim 3, Novotny, Li, Niederle, Carey, Chen, Morehead, and Abdelrahman, teach the method of claim 2. Novotny additionally teaches wherein analyzing the filtered data further includes adapting the job execution parameters based on real-time changes to predefined business rules and priorities established (¶ [0105] states “The method of endorsing a transaction depends on an endorsement policy which may be specified within chaincode. An example of an endorsement policy is “the majority of endorsing peers must endorse the transaction”. Different channels may have different endorsement policies.” ¶ [0038] states “An endorsement policy of the blockchain may require a client to submit a transaction to all blockchain peers of the blockchain network. As another example, the endorsement policy may allow the client to choose a fixed number of blockchain peers to perform the endorsement. In this example, a client (submitter of the transaction) may choose a subset of blockchain peers (e.g., an amount of peers required by the endorsement policy) from a larger set of blockchain peers available in the network.” Examiner’s Note: the number of endorsing peer nodes selected from nodes in the network is based on the endorsement policy. The selected peer nodes are the job execution parameters. The policy changes depending on the channel. The endorsement policies also represent an established priority because a policy that requires only one endorsement prioritizes speed while a policy that requires all nodes to endorse prioritizes collaboration).
With regard to claim 4, Novotny, Li, Niederle, Carey, Chen, Morehead, and Abdelrahman teach the method of claim 3. Li additionally teaches wherein the quantum annealing and simulations are specifically configured to prioritize job scheduling strategies that correspond to the highest-priority transaction types as identified in the prioritization step (¶ [0056] states “For example, by using a transaction type as a constraint or a filter, the first block chain node 206 can obtain transaction requests of transaction types having priorities higher than the transaction type from the memory.”)
Niederle additionally teaches wherein the quantum annealing and simulations are specifically configured to prioritize job scheduling strategies that correspond to the highest-priority transaction types as identified in the prioritization step (¶ [0079] states “Moreover, the quantum computer interface unit 803 can also be configured to receive the result of the quantum computation of the scheduling problem from the quantum computer 810, wherein the result is indicative of the optimized scheduling problem.” ¶ [0023] states “the scheduling problem preparation unit is adapted to prepare the scheduling problem to be solvable on a quantum computer that refers to a quantum annealer.”).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine Li’s prioritization of transaction types with Niederle’s quantum annealer to optimize a scheduling strategy and the combination of Novotny, Carey, Chen, Morehead, and Abdelrahman. A person having ordinary skill in the art would have been motivated to make this combination to “allow for a less time consuming, less computational resource intensive and more objective optimization of a laboratory scheduling in an automatic laboratory environment. Moreover, the apparatus, method and computing program product allow for a more efficient usage of available laboratory equipment and for an increase in the level of laboratory automation” (¶ [0003]).
Claims 5-8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Novotny, Li, Niederle, Carey, Chen, Morehead, Abdelrahman, and further in view of Nikkhah et al. Pat. No. US 20180137412 A1 (hereafter Nikkhah).
With regard to claim 5, Novotny, Li, Niederle, Carey, Chen, Morehead, and Abdelrahman teach the method of claim 4. Abdelrahman additionally teaches wherein the generative Al engine utilizes a reinforcement learning algorithm to iteratively improve the conditional execution logic within the dynamic smart contracts based on historical network performance data (¶ [0175] states “The AI system 910 may include one or more generative AI systems” and “the models may be trained using historical or synthetic data (e.g., transaction).” ¶ [0176] states “the AI system 910 may be applied may involve traditional AI/ML models for classification, regression, clustering, pattern detection, anomaly detection, or also more advanced reinforcement learning settings for online network optimization.” [0062] states “The smart contract logic description represents a conversion of the input logic described in the text 53 into smart code logic, e.g., such illustrating example logic paths as would be executed on the blockchain in response to different conditions.” Examiner’s Note: the advanced reinforcement learning settings improves the generative AI system, which includes conditional execution logic).
Novotny, Li, Niederle, Carey, Chen, Morehead, and Abdelrahman do not explicitly teach using historical network performance data.
However, in an analogous art, Nikkhah teaches wherein the generative Al engine utilizes a reinforcement learning algorithm to iteratively improve the conditional execution logic within the dynamic smart contracts based on historical network performance data (¶ [0011] states “a server to predict a bandwidth value for a computer network element using past traffic data using an LSTM neural network.” ¶ [0033] states “In step 620, the server trains an LSTM neural network using at least a portion of the received time series. In one example, a training set of data and a validation set of data is determined from the time series of bandwidth values and used to train the LSTM neural network”).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the training of an LSTM neural network using previous network bandwidth values of Nikkhah and the AI system to generate smart contracts with conditional execution and reinforcement learning settings of Abdelrahman and combination of Novotny, Li, Niederle, Carey, Chen, and Morehead. As a result, the AI system uses reinforcement learning based on previous network data to improve smart contract generation. A person having ordinary skill in the art would have been motivated to make this combination because “one advantage of LSTM to ordinary neural networks is its ability to infer long-term dependencies between data points, and learning to forget those data points that are not important. The ability to forget allows the LSTM neural network to adapt to changes in the computer network configuration without having to reconfigured the neural network” (¶ [0054]). Additionally, by using “An accurate prediction of future bandwidth requirements generated by looking at past bandwidth usage, utilization or other network traffic data allows network administrators to provide adequate provisioning for users, while avoiding the costs of overprovisioning network resources that are not necessary during a particular time period” (¶ [0002]).
With regard to claim 6, Novotny, Li, Niederle, Carey, Chen, Morehead, Abdelrahman, and Nikkhah teach the method of claim 5. Novotny additionally teaches wherein the deployment of dynamic smart contracts includes a verification process to ensure smart contracts' conditional logic is compliant with a current operational state of the target distributed ledgers (¶ [0065] states “Depending on the blockchain's 352 network parameters the nodes verify 360 the transaction based on rules (which may be pre-defined or dynamically allocated) established by the permissionless blockchain 352 creators. For example, this may include verifying identities of the parties involved, etc. The transaction may be verified immediately or it may be placed in a queue with other transactions and the nodes 354 determine if the transactions are valid based on a set of network rules.” ¶ [0050] states “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.” Examiner’s Note: verifying the transaction is verifying the smart contracts. Verifying if a transaction is valid is based on network rules is ensuring that the smart contracts’ conditional logic is compliant with the operational state of the target distributed ledgers).
With regard to claim 7, Novotny, Li, Niederle, Carey, Chen, Morehead, Abdelrahman, and Nikkhah teach the method of claim 6. Novotny additionally teaches wherein the job orchestration engine is configured to execute a real-time comparison between scheduled job execution and actual job performance to identify discrepancies (¶ [0086] states “In some embodiments, before sending the transaction to the selected peers 412, 414, and 415, the client 420 may compare it with the probing transaction to calculate the expected transaction simulation time. If the client still misses n out of N endorsement results after time t, then the client selects the next n peers from the ordered peer list and sends transaction proposals to them.” Examiner’s Note: the expected transaction simulation time is the scheduled job execution. The response received at the client is the actual job performance. Discrepancies are identified when the response results exceed the expected transaction simulation time).
With regard to claim 8, Novotny, Li, Niederle, Carey, Chen, Morehead, Abdelrahman, and Nikkhah teach the method of claim 7. Nikkhah additionally teaches wherein the feedback provided includes predictive analysis based on trend data to preemptively adjust job execution parameters in anticipation of network load changes (¶ [0033] states “In step 620, the server trains an LSTM neural network using at least a portion of the received time series.” ¶ [0034] states “In step 630, the server uses the trained LSTM neural network to predict the next bandwidth value in the time series” and “In step 640, the server adjusts the bandwidth provisioned to the network element based on the predicted bandwidth value.” See FIG. 6. Examiner’s Note: the training data is the trend data. The predicted network bandwidth value is used to adjust provisioned bandwidth in advance of network changes).
Claims 9 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Novotny, Niederle, Carey, Morehead, and Abdelrahman.
With regard to claim 9 Novotny teaches a distributed ledger job scheduling system comprising one or more processors and one or more non-transitory computer-readable storage media storing instructions that, when executed by the one or more processors, cause the system to perform operations comprising (¶ [0044] states “FIG. 1 illustrates a blockchain network 100 which implements load balancing according to example embodiments.” ¶ [0006] states “A further example embodiment provides a non-transitory computer readable medium comprising instructions, that when read by a processor, cause the processor to perform one or more of transmitting an inquiry to a blockchain peer.” Examiner’s Note: blockchains are a type of distributed ledger):
autonomously receiving and interpreting, via a data reception module executed by the one or more processors, transactional and operational data from multiple nodes within a distributed ledger network (¶ [0055] states “simulation responses are provided from the endorser peer nodes 281-283 to the client node 260. In 293, the client 260 identifies metrics (latency data) based on the simulation responses.” ¶ [0070] states “the probing transaction is a special transaction which invokes simulation/execution of a chaincode that is installed on the blockchain peer.” ¶ [0159] states “FIG. 9 illustrates an example system 900 that supports one or more of the example embodiments described and/or depicted herein.” Examiner’s Note: the data received is transactional because it is the result of a special transaction. The data received is operational because it includes latency data);
processing, via an analysis module executed by the one or more processors and linked to the data reception module, the received data to ascertain job execution parameters based on current network conditions and predefined business rules (¶ [0053] states “receive respective response from the endorser peers 281, 282, and 283, in 292. Based on the responses, the client 260 may identify latency metrics and select one or more peers for endorsement, in 293. Here, the endorsement policy requires only one endorser peer to be selected.” ¶ [0085] states “the client 420 selects the “N” best performing peers (e.g., based on their up-to-date tx processing latencies stored in the latency list 430).” Examiner’s Note: the node or nodes that are selected to perform endorsement are the job execution parameters. Selecting the best performing peers based on latency is analyzing based on “current network conditions.” The endorsement policy, or number of endorsements required, is a predefined business rule);
performing, via a quantum computing module executed by the one or more processors and comprising a photonic processor operatively coupled to the analysis module, quantum computations to optimize job scheduling strategies based on the job execution parameters over a plurality of optimization parameters including transaction throughput, latency, network bandwidth, block confirmation time, block size, validation time, and storage resource, thereby producing optimized job scheduling strategies, and to generate a dynamic job schedule configuration that maps the plurality of optimization parameters on a temporal axis and that is regenerated at regular intervals (¶ [0085] states “the client 420 selects the “N” best performing peers (e.g., based on their up-to-date tx processing latencies stored in the latency list 430).” Examiner’s Note: the selected nodes are processed to form optimized job scheduling strategies);
receiving, via a generative artificial intelligence (AI) module executed by the one or more processors, the optimized job scheduling strategies from the quantum computing module and generating dynamic smart contracts that encode the received optimized job scheduling strategies as conditional execution logic tailored to optimize transaction throughput, reduce latency, and efficiently allocate network bandwidth and storage resources (¶ [0043] states “Some of the benefits of the example embodiments include reduced latency of transaction processing, improvement in the overall transaction throughput of the blockchain network, optimization of peer resource utilization to avoid skewed load distribution”);
deploying, via an orchestration module executed by the one or more processors and communicatively connected to the AI module, the generated smart contracts to the distributed ledger and initiating job execution in accordance with the scheduling rules (¶ [0055] states “The client node 260 initiates the transaction 294 by constructing and sending a request to the peer node 281, which is an endorser.” ¶ [0050] states “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.” See FIG. 2B. Examiner’s Note: after the client selects the peer nodes to perform the endorsement operation, the client sends a transaction to the peer node. According to ¶ [0050], transactions are “the execution of the smart contract code,” so it is interpreted that the client is deploying a smart contract to the endorser peer node and executing the smart contract);
and continuously evaluating, via a monitoring module executed by the one or more processors, the execution of jobs on the distributed ledger, providing feedback to the analysis module, and adjusting the job execution parameters in real time, wherein the orchestration module dynamically updates the job scheduling in response to the feedback to maintain optimal network operation (¶ [0080] states “The client 420 may separately probe each chaincode on a periodic basis and monitor/track latency values in a client records the each peer's transaction processing latency.” ¶ [0079] states “The client 420 receives responses from each of the blockchain peers 411-415, determines round-trip latency values 432 and chaincode simulation latency values 433 and 434, and stores the round-trip latency values 432 and the chaincode simulation latency values 433 and 434 within a latency list 430. Here, the latency values are also stored with an identifier 431 of the respective peers.” ¶ [0085] states “the client 420 selects the “N” best performing peers (e.g., based on their up-to-date tx processing latencies stored in the latency list 430).” ¶ [0089] states “the blockchain network enables load balancing among the peers so that peer resources can be utilized effectively to avoid hotspots as well as under used peers.” Examiner’s Note: monitoring the latency of the peer nodes is evaluating the execution of jobs. The client storing the latency information in the latency list, is the providing of feedback. Selecting the N best performing nodes is the adjusting the job execution parameters and dynamically updating the job schedule).
Novotny does not explicitly teach a photonic computing system.
However, in an analogous art, Niederle teaches performing, via a quantum computing module executed by the one or more processors and comprising a photonic processor operatively coupled to the analysis module, quantum computations to optimize job scheduling strategies based on the job execution parameters over a plurality of optimization parameters including transaction throughput, latency, network bandwidth, block confirmation time, block size, validation time, and storage resource, thereby producing optimized job scheduling strategies, and to generate a dynamic job schedule configuration that maps the plurality of optimization parameters on a temporal axis and that is regenerated at regular intervals (¶ [0004] states “a probe list including probe data for a plurality of probes, wherein the probe data for a probe comprises a probe identification and a task associated with the probe identification, wherein a task is indicative of one or more operations to be performed with a predetermined timing by a laboratory equipment on the probe.” ¶ [0075] states “In particular, the job scheduler is configured to formulate a schedule problem, for instance, based on a probe list, to provide at least a part of the schedule problem to the quantum computer for calculation. The schedule solution, in particular, the results of the quantum computer calculation indicative for the schedule solution, are then again provided to the job scheduler such that the job scheduler can determine based on the results of the quantum computer calculation a job schedule and provide respective schedule control signals to a laboratory equipment to be controlled.” ¶ [0054] states “Quantum computing devices are based on quantum elements adhering to the physics of quantum mechanics, such as superconductors, ions, atoms, quantum dots, photons, particle spins, bosons or the like.” ¶ [0023] states “the scheduling problem preparation unit is adapted to prepare the scheduling problem to be solvable on a quantum computer that refers to a quantum annealer.” ¶ [0021] states “the preparation of the at least a part of the scheduling problem can refer to any kind of preparation and/or transformation of the scheduling problem such that the scheduling problem is performable utilizing a quantum computation.” Examiner’s Note: the probe list is the optimization parameter).
receiving, via a generative artificial intelligence (AI) module executed by the one or more processors, the optimized job scheduling strategies from the quantum computing module and generating dynamic smart contracts that encode the received optimized job scheduling strategies as conditional execution logic tailored to optimize transaction throughput, reduce latency, and efficiently allocate network bandwidth and storage resources (¶ [0079] states “The quantum computer interface unit 803 is configured to provide an interface for interfacing with the quantum computer 810 for utilizing the quantum computer for calculating the scheduling problem. Moreover, the quantum computer interface unit 803 can also be configured to receive the result of the quantum computation of the scheduling problem from the quantum computer 810, wherein the result is indicative of the optimized scheduling problem.” ¶ [0081] states “The schedule determination unit 804 is then adapted to determine a schedule for the probe list based on the received result of the quantum computation.” ¶ [0076] states “the apparatus 800 can comprise one or more processors that are configured to provide the functions defined by the units of the apparatus 800.” Examiner’s Note: a schedule is generated by the apparatus 800 that encapsulates the optimal job scheduling strategies);
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the photonic quantum computing system to optimize a schedule of Niederle with the endorsement node selection and transaction distribution in a blockchain environment of Novotny. A person having ordinary skill in the art would have been motivated to make this combination because quantum computers “perform certain computations more efficiently than classical digital computers” (¶ [0014]). Additionally, ¶ [0003] states “It is an object of the present invention to provide an apparatus, a method and a computing program product that allow for a less time consuming, less computational resource intensive and more objective optimization of a laboratory scheduling in an automatic laboratory environment. Moreover, the apparatus, method and computing program product allow for a more efficient usage of available laboratory equipment and for an increase in the level of laboratory automation.”
Novotny and Niederle do not explicitly teach optimization parameters including at least a block confirmation time.
However, in an analogous art, Carey teaches performing, via a quantum computing module executed by the one or more processors and comprising a photonic processor operatively coupled to the analysis module, quantum computations to optimize job scheduling strategies based on the job execution parameters over a plurality of optimization parameters including transaction throughput, latency, network bandwidth, block confirmation time, block size, validation time, and storage resource, thereby producing optimized job scheduling strategies, and to generate a dynamic job schedule configuration that maps the plurality of optimization parameters on a temporal axis and that is regenerated at regular intervals (¶ [0076] states “In a first variation, S300 includes querying one or more managed nodes for the blockchain data.” ¶ [0072] states “Determining blockchain data indicative of a blockchain event S300 (e.g., introspecting the blockchain) functions to determine that a blockchain event is about to happen, determine when a blockchain event will happen, determine that a blockchain event is happening, and/or determine that a blockchain event has occurred … In a first variant, this information is used to detect the blockchain event.” ¶ [0075] states “The blockchain data can include: whether the blockchain event is happening; when the next blockchain event will occur (… block validation, block confirmation, and/or other blockchain event, etc.); … blockchain parameters (e.g., block height, transactions per second, block time or confirmation time, etc.); and/or any other suitable data.” ¶ [0092] states “S700 preferably allocates computing resources in real- or near-real time, such that the nodes are allocated the resources immediately or after a short delay. Additionally or alternatively, S700 can schedule future computing resource allocation for one or more nodes.” See FIG. 3. ¶ [0074] states “S300 can be performed: periodically (e.g., at the block generation rate or a fraction thereof); at a varying frequency (e.g., more frequently with temporal, block position, or transaction position proximity to the next blockchain event); constantly; randomly; and/or at any other time.” See FIG. 4. Examiner’s Note: step S700 follows S300 and is related to optimizing and scheduling. Therefore, the scheduling is based off the optimization parameters determined in S300 and the schedule maps the optimization parameters to a temporal axis. S300 can be performed periodically, so step S700 is also performed periodically. See FIG. 4 to see the loop starting at S300);
receiving, via a generative artificial intelligence (AI) module executed by the one or more processors, the optimized job scheduling strategies from the quantum computing module and generating dynamic smart contracts that encode the received optimized job scheduling strategies as conditional execution logic tailored to optimize transaction throughput, reduce latency, and efficiently allocate network bandwidth and storage resources (¶ [0092] states “S700 preferably allocates computing resources in real- or near-real time, such that the nodes are allocated the resources immediately or after a short delay. Additionally or alternatively, S700 can schedule future computing resource allocation for one or more nodes.” ¶ [0037] states “Examples of computing resources (e.g., management system resources) that can be provided can include: … memory (e.g., addresses, blocks, memory locations, cache space, contiguous free space, management system memory, etc.) … network throughput (e.g., within the machine itself, Internet bandwidth, etc.)”).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine scheduling of allocation of resources based on optimization parameters of Carey with the blockchain environment of Novotny and the quantum computing system of Niederle. A person having ordinary skill in the art would have been motivated to make this combination for the purpose of “dynamically allocating computing resources to the node based on current and/or anticipated node participation in the blockchain event (e.g., by setting the process priority for the node)” which “allows for the same number of nodes to be hosted by less machines, which leads to lower overall resource, energy, and cost consumption” (¶ [0016]).
Novotny, Niederle, and Carey do not explicitly teach a generative artificial intelligence engine interfaced with the photonic quantum computing system.
However, in an analogous art, Morehead teaches receiving, via a generative artificial intelligence (AI) module executed by the one or more processors, the optimized job scheduling strategies from the quantum computing module and generating dynamic smart contracts that encode the received optimized job scheduling strategies as conditional execution logic tailored to optimize transaction throughput, reduce latency, and efficiently allocate network bandwidth and storage resources (¶ [0103] states “The cycle begins with the classical computer 106 reading any received signals, whether they come from the input or the output channels 102, 104. The classical computer 106 processes this data and may use the data to configure the node's quantum computer 108. Next, the quantum computer 108 executes a full quantum computation, which includes the application of a set of quantum gates to its qubits, and then a measure operation. The output of the measure operation provides a set of classical bits which the classical computer 106 may process and/or send via either the input or the output channels 102, 104.”)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the AI system that decomposes larger problems into smaller problems that are then processed on nodes having classical and quantum computers of Morehead with the blockchain environment of Novotny, the quantum computing system of Niederle, and the optimization parameters of Carey. A person having ordinary skill in the art would have been motivated to make this combination because “The quantum computer may be configured to process computations determined difficult for the classical computer” (¶ [0013]). Additionally, the Morehead teaches that the artificial intelligence system can perform processing to achieve “a goal including minimizing a number of duplicate computations, maximizing signal robustness, and maximizing coding efficiency” (¶ [0028]).
Novotny, Niederle, Carey, and Morehead do not explicitly teach generating smart contracts.
However, in an analogous art, Abdelrahman teaches receiving, via a generative artificial intelligence (AI) module executed by the one or more processors, the optimized job scheduling strategies from the quantum computing module and generating dynamic smart contracts that encode the received optimized job scheduling strategies as conditional execution logic tailored to optimize transaction throughput, reduce latency, and efficiently allocate network bandwidth and storage resources (¶ [0007] states “processing the smart contract logic description with a generative artificial intelligence model to generate smart contract code.” ¶ [0062] states “The smart contract logic description represents a conversion of the input logic described in the text 53 into smart code logic, e.g., such illustrating example logic paths as would be executed on the blockchain in response to different conditions.” Examiner’s Notes: “logic paths … executed … in response to different conditions” is interpreted as conditional execution logic).
deploying, via an orchestration module executed by the one or more processors and communicatively connected to the AI module, the generated smart contracts to the distributed ledger and initiating job execution in accordance with the scheduling rules (¶ [0046] states “the smart contract generation and validation system 20, which generates, validates, and deploys a smart contract based on a desired functionality of the requesting user.” ¶ [0062] states “The smart contract logic description represents a conversion of the input logic described in the text 53 into smart code logic, e.g., such illustrating example logic paths as would be executed on the blockchain in response to different conditions.” Examiner’s Note: in light of the 112(b) rejection related to “the scheduling rules,” examiner interprets the scheduling rules to be the logic within the smart contract. Therefore, when the smart contract executes, it will execute according to the logic that responds to different conditions).
As a result of the combination of Novotny, Niederle, Carey, and Morehead, an optimized job schedule for a task in a blockchain environment is determined. This job schedule is based tailored to optimize transaction throughput, reduce latency, and efficiently allocate network bandwidth and storage resources. It would have been obvious for the generative AI system of Abdelrahman to receive as input the optimized job schedule determined by Novotny, Niederle, Carey, and Morehead. The generative AI system of Abdelrahman then processes the input to output a smart contract. Therefore, the generated smart contract encodes the optimized job scheduling strategies that are tailored to optimize transaction throughput, reduce latency, and efficiently allocate network bandwidth and storage resources.. Further, the smart contract would be executed according to the teachings of Novotny and Abdelrahman.
A person having ordinary skill in the art would have been motivated to make this combination for the purpose of having “improved security for the smart contract, thereby making the smart contract less vulnerable to hacking attacks. Additional advantages of systems and methods disclosed herein include improving logic and code design, resulting in more efficient smart contracts being executed on the distributed ledger” (¶ [0040]). Further, Abdelrahman teaches that the optimized smart contract code optimizes resource usage (¶ [0110] states “the generative AI model is trained or fine tuned using a large set of training examples of well optimized and highly secured smart contract code from bridge examples. Optimization includes optimization for computational complexity (e.g., efficiency), memory usage, processor usage, etc.”).
With regard to claim 20, Novotny additionally teaches an autonomous job scheduling system for managing tasks within a distributed ledger network, the system comprising one or more processors and one or more non-transitory computer-readable storage media storing instructions that, when executed by the one or more processors, cause the system to perform operations comprising (¶ [0044] states “FIG. 1 illustrates a blockchain network 100 which implements load balancing according to example embodiments.” ¶ [0040] states “enable a blockchain client to smartly send transaction proposals to blockchain peers for endorsement thereby improving transaction throughput and network performance of the blockchain network.” ¶ [0006] states “A further example embodiment provides a non-transitory computer readable medium comprising instructions, that when read by a processor, cause the processor to perform one or more of transmitting an inquiry to a blockchain peer.” Examiner’s Note: blockchains are a type of distributed ledger. The blockchain client does not require manual intervention to perform the load balancing of transactions, so it is autonomous):
collecting, via a job analysis module executed by the one or more processors, operational data from the distributed ledger, including transaction context, business rules, and network performance metrics (¶ [0055] states “simulation responses are provided from the endorser peer nodes 281-283 to the client node 260. In 293, the client 260 identifies metrics (latency data) based on the simulation responses.” ¶ [0105] states “Different channels may have different endorsement policies.” ¶ [0056] states “the endorsing peer node 281 may verify … (d) that the submitter (client 260, in the example) is properly authorized to perform the proposed operation on that channel.” ¶ [0064] states “to join a permissionless blockchain a user may create a personal address and begin interacting with the network, by submitting transactions.” ¶ [0159] states “FIG. 9 illustrates an example system 900 that supports one or more of the example embodiments described and/or depicted herein.” ¶ [0161] states “The components of computer system/server 902 may include, but are not limited to, one or more processors or processing units 904, a system memory 906, and a bus that couples various system components including system memory 906 to processor 904.” Examiner’s Note: it is interpreted that when a client joins the permissionless blockchain and submits a transaction, the client has received the endorsement policy, or business rule. Based on the 112(f) claim interpretation, the modules and engines are implemented on generic computing components such as processors and memory);
receiving, via a photonic quantum computing system executed by the one or more processors and communicatively coupled with the job analysis module, the operational data and executing quantum computations to derive optimized job scheduling strategies over a plurality of optimization parameters including transaction throughput, latency, network bandwidth, block confirmation time, block size, validation time, and storage resource, and to generate a dynamic job schedule configuration that maps the plurality of optimization parameters on a temporal axis and that is regenerated at regular intervals (¶ [0085] states “the client 420 selects the “N” best performing peers (e.g., based on their up-to-date tx processing latencies stored in the latency list 430).” Examiner’s Note: the selected nodes are processed to form optimized job scheduling strategies);
and deploying and executing, via a job orchestration engine executed by the one or more processors and operatively connected to the generative AI engine, the dynamic smart contracts on the distributed ledger, thereby scheduling jobs in accordance with the optimized strategies (¶ [0033] states “Blockchain transactions associated with this application can be “endorsed” before being committed to the blockchain while transactions, which are not endorsed, are disregarded.” ¶ [0070] states “In response to receiving the probing transaction 422, the blockchain peer 411 may simulate the chaincode identified by the chaincode ID 423 using the simulation data, and generate a response 424 which includes simulated results, timestamps 425, and the like.” Examiner’s Note: the tasks performed at the peer node during the endorsement process are the jobs. The endorsement operations are performed because of the optimized job scheduling strategy selecting the best performing peer nodes).
Novotny does not explicitly teach using a quantum computer.
However, in an analogous art, Niederle teaches receiving, via a photonic quantum computing system executed by the one or more processors and communicatively coupled with the job analysis module, the operational data and executing quantum computations to derive optimized job scheduling strategies over a plurality of optimization parameters including transaction throughput, latency, network bandwidth, block confirmation time, block size, validation time, and storage resource, and to generate a dynamic job schedule configuration that maps the plurality of optimization parameters on a temporal axis and that is regenerated at regular intervals (¶ [0004] states “a probe list including probe data for a plurality of probes, wherein the probe data for a probe comprises a probe identification and a task associated with the probe identification, wherein a task is indicative of one or more operations to be performed with a predetermined timing by a laboratory equipment on the probe.” ¶ [0075] states “In particular, the job scheduler is configured to formulate a schedule problem, for instance, based on a probe list, to provide at least a part of the schedule problem to the quantum computer for calculation. The schedule solution, in particular, the results of the quantum computer calculation indicative for the schedule solution, are then again provided to the job scheduler such that the job scheduler can determine based on the results of the quantum computer calculation a job schedule and provide respective schedule control signals to a laboratory equipment to be controlled.” ¶ [0054] states “Quantum computing devices are based on quantum elements adhering to the physics of quantum mechanics, such as superconductors, ions, atoms, quantum dots, photons, particle spins, bosons or the like.” ¶ [0023] states “the scheduling problem preparation unit is adapted to prepare the scheduling problem to be solvable on a quantum computer that refers to a quantum annealer.” ¶ [0021] states “the preparation of the at least a part of the scheduling problem can refer to any kind of preparation and/or transformation of the scheduling problem such that the scheduling problem is performable utilizing a quantum computation.”).
formulating, via a generative AI engine executed by the one or more processors and interfaced with the quantum computing system, dynamic smart contracts incorporating the optimized job scheduling strategies, wherein the generative AI engine receives the optimized job scheduling strategies from the photonic quantum computing system and encodes the received optimized job scheduling strategies as conditional execution logic of the dynamic smart contracts (¶ [0079] states “The quantum computer interface unit 803 is configured to provide an interface for interfacing with the quantum computer 810 for utilizing the quantum computer for calculating the scheduling problem. Moreover, the quantum computer interface unit 803 can also be configured to receive the result of the quantum computation of the scheduling problem from the quantum computer 810, wherein the result is indicative of the optimized scheduling problem.” ¶ [0081] states “The schedule determination unit 804 is then adapted to determine a schedule for the probe list based on the received result of the quantum computation.” ¶ [0076] states “the apparatus 800 can comprise one or more processors that are configured to provide the functions defined by the units of the apparatus 800.” Examiner’s Note: a schedule is generated by the apparatus 800 that encapsulates the optimal job scheduling strategies);
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the photonic quantum computing system to optimize a schedule of Niederle with the endorsement node selection and transaction distribution in a blockchain environment of Novotny and the transaction priorities of Li. A person having ordinary skill in the art would have been motivated to make this combination because quantum computers “perform certain computations more efficiently than classical digital computers” (¶ [0014]). Additionally, ¶ [0003] states “It is an object of the present invention to provide an apparatus, a method and a computing program product that allow for a less time consuming, less computational resource intensive and more objective optimization of a laboratory scheduling in an automatic laboratory environment. Moreover, the apparatus, method and computing program product allow for a more efficient usage of available laboratory equipment and for an increase in the level of laboratory automation.”
Novotny and Niederle do not explicitly teach optimization parameters including at least a block confirmation time.
However, in an analogous art, Carey teaches receiving, via a photonic quantum computing system executed by the one or more processors and communicatively coupled with the job analysis module, the operational data and executing quantum computations to derive optimized job scheduling strategies over a plurality of optimization parameters including transaction throughput, latency, network bandwidth, block confirmation time, block size, validation time, and storage resource, and to generate a dynamic job schedule configuration that maps the plurality of optimization parameters on a temporal axis and that is regenerated at regular intervals (¶ [0076] states “In a first variation, S300 includes querying one or more managed nodes for the blockchain data.” ¶ [0072] states “Determining blockchain data indicative of a blockchain event S300 (e.g., introspecting the blockchain) functions to determine that a blockchain event is about to happen, determine when a blockchain event will happen, determine that a blockchain event is happening, and/or determine that a blockchain event has occurred … In a first variant, this information is used to detect the blockchain event.” ¶ [0075] states “The blockchain data can include: whether the blockchain event is happening; when the next blockchain event will occur (… block validation, block confirmation, and/or other blockchain event, etc.); … blockchain parameters (e.g., block height, transactions per second, block time or confirmation time, etc.); and/or any other suitable data.” ¶ [0092] states “S700 preferably allocates computing resources in real- or near-real time, such that the nodes are allocated the resources immediately or after a short delay. Additionally or alternatively, S700 can schedule future computing resource allocation for one or more nodes.” See FIG. 3. ¶ [0074] states “S300 can be performed: periodically (e.g., at the block generation rate or a fraction thereof); at a varying frequency (e.g., more frequently with temporal, block position, or transaction position proximity to the next blockchain event); constantly; randomly; and/or at any other time.” See FIG. 4. Examiner’s Note: step S700 follows S300 and is related to optimizing and scheduling. Therefore, the scheduling is based off the optimization parameters determined in S300 and the schedule maps the optimization parameters to a temporal axis. S300 can be performed periodically, so step S700 is also performed periodically. See FIG. 4 to see the loop starting at S300).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine scheduling of allocation of resources based on optimization parameters of Carey with the blockchain environment of Novotny and the quantum computing system of Niederle. A person having ordinary skill in the art would have been motivated to make this combination for the purpose of “dynamically allocating computing resources to the node based on current and/or anticipated node participation in the blockchain event (e.g., by setting the process priority for the node)” which “allows for the same number of nodes to be hosted by less machines, which leads to lower overall resource, energy, and cost consumption” (¶ [0016]).
Novotny, Niederle, and Carey do not explicitly teach a generative AI engine interfaced with the quantum computing system.
However, in an analogous art, Morehead teaches formulating, via a generative AI engine executed by the one or more processors and interfaced with the quantum computing system, dynamic smart contracts incorporating the optimized job scheduling strategies, wherein the generative AI engine receives the optimized job scheduling strategies from the photonic quantum computing system and encodes the received optimized job scheduling strategies as conditional execution logic of the dynamic smart contracts (¶ [0103] states “The cycle begins with the classical computer 106 reading any received signals, whether they come from the input or the output channels 102, 104. The classical computer 106 processes this data and may use the data to configure the node's quantum computer 108. Next, the quantum computer 108 executes a full quantum computation, which includes the application of a set of quantum gates to its qubits, and then a measure operation. The output of the measure operation provides a set of classical bits which the classical computer 106 may process and/or send via either the input or the output channels 102, 104.”).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the AI system that decomposes larger problems into smaller problems that are then processed on nodes having classical and quantum computers of Morehead with the blockchain environment of Novotny, the quantum computing system of Niederle, and the optimization parameters of Carey. A person having ordinary skill in the art would have been motivated to make this combination because “The quantum computer may be configured to process computations determined difficult for the classical computer” (¶ [0013]). Additionally, the Morehead teaches that the artificial intelligence system can perform processing to achieve “a goal including minimizing a number of duplicate computations, maximizing signal robustness, and maximizing coding efficiency” (¶ [0028]).
Novotny, Niederle, Carey, and Morehead do not explicitly teach formulating smart contracts to encapsulate optimized job scheduling strategies.
However, in an analogous art, Abdelrahman teaches formulating, via a generative AI engine executed by the one or more processors and interfaced with the quantum computing system, dynamic smart contracts incorporating the optimized job scheduling strategies, wherein the generative AI engine receives the optimized job scheduling strategies from the photonic quantum computing system and encodes the received optimized job scheduling strategies as conditional execution logic of the dynamic smart contracts (¶ [0007] states “processing the smart contract logic description with a generative artificial intelligence model to generate smart contract code.” ¶ [0062] states “The smart contract logic description represents a conversion of the input logic described in the text 53 into smart code logic, e.g., such illustrating example logic paths as would be executed on the blockchain in response to different conditions.” Examiner’s Notes: “logic paths … executed … in response to different conditions” is interpreted as conditional execution logic).
and deploying and executing, via a job orchestration engine executed by the one or more processors and operatively connected to the generative AI engine, the dynamic smart contracts on the distributed ledger, thereby scheduling jobs in accordance with the optimized strategies (¶ [0041] states “The AI system uses generative AI configured to receive smart contract text-based documents as input and provide more optimized and secure smart contract computer code as output. In an example, the output is configured to be executed on a distributed ledger network.” [0062] states “The smart contract logic description represents a conversion of the input logic described in the text 53 into smart code logic, e.g., such illustrating example logic paths as would be executed on the blockchain in response to different conditions.” ¶ [0246] states “FIG. 22 illustrates an example computing environment 1600, in accordance with some embodiments of the present disclosure.” ¶ [0251] states “Many example computers 1610 include one or more processors 1612, memory 1614, and one or more interfaces 1618.” Examiner’s Note: when the smart contract is executed, it is executed according to the encoded execution logic because the smart contracted included the conditional logic).
As a result of the combination of Novotny, Niederle, Carey, and Morehead, an optimized job schedule for a task in a blockchain environment is determined. This job schedule is based on network bandwidth. It would have been obvious for the generative AI system of Abdelrahman to receive as input the optimized job schedule determined by Novotny, Niederle, Carey, and Morehead. The generative AI system of Abdelrahman then processes the input to output a smart contract. Therefore, the generated smart contract encodes the optimized job scheduling strategies that are based on network bandwidth availability. Further, the smart contract would be executed according to the teachings of Novotny and Abdelrahman.
A person having ordinary skill in the art would have been motivated to make this combination for the purpose of having “improved security for the smart contract, thereby making the smart contract less vulnerable to hacking attacks. Additional advantages of systems and methods disclosed herein include improving logic and code design, resulting in more efficient smart contracts being executed on the distributed ledger” (¶ [0040]). Further, Abdelrahman teaches that the optimized smart contract code optimizes resource usage (¶ [0110] states “the generative AI model is trained or fine tuned using a large set of training examples of well optimized and highly secured smart contract code from bridge examples. Optimization includes optimization for computational complexity (e.g., efficiency), memory usage, processor usage, etc.”).
Claims 10-12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Novotny, Niederle, Carey, Morehead, Abdelrahman, and Li.
With regard to claim 10, Novotny, Niederle, Carey, Morehead, and Abdelrahman teach the system of claim 9. Novotny additionally teaches wherein the data reception module is further configured to filter transactional data based on transaction type, size, or priority status (¶ [0113] states “Metadata fields may include signature on block creation, a reference to a last configuration block, a transaction filter identifying valid and invalid transactions within the block” and “The transaction filter may include a byte array of a size equal to the number of transactions that are included in the block data 750 and a validation code identifying whether a transaction was valid/invalid.” ¶ [0110] states “a new data block 730 (also referred to as a data block) that is stored on the blockchain 722 of the distributed ledger 720 may include multiple data segments such as a block header 740, block data 750 (block data section), and block metadata 760.” FIG. 7B shows “type.” Examiner’s Note: transactions are filtered based on whether they are valid or not. The block data in FIG. 7B includes a type which is the transaction type. Block data 750 also includes N transactions which is a size. The filtering is based on the number of transactions in the block data).
Novotny, Niederle, Carey, Morehead, and Abdelrahman do not explicitly teach filtering based on transaction priority.
However, in an analogous art, Li teaches wherein the data reception module is further configured to filter transactional data based on transaction type, size, or priority status (¶ [0056] states “For example, by using a transaction type as a constraint or a filter, the first block chain node 206 can obtain transaction requests of transaction types having priorities higher than the transaction type from the memory.”).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine receiving transaction types and priority and then filtering based on transaction type and priority of Li with the combination of Novotny, Niederle, Carey, Morehead, and Abdelrahman. A person having ordinary skill in the art would have been motivated to make this combination for the purpose of being able to broadcast high priority data (¶ [0036] – [0037] states “For example, highest-priority transaction requests can be chosen for inclusion into the pre-processed block. From 108, method 100 proceeds to 110. At 110, the pre-processed block is broadcast to the second block chain nodes.” By prioritizing, the most important transactions can be processed first. Further, Li ¶ [0005] teaches that “First, adverse effects on consensus verification of transaction requests that are caused by a network failure can be reduced. Second, transaction processing accuracy of the block chain network can be improved.”
With regard to claim 11, Novotny, Niederle, Carey, Morehead, Abdelrahman, and Li teach the system of claim 10. Novotny additionally teaches wherein the analysis module includes a business logic interpreter capable of adapting the job execution parameters in real time based on changes in the predefined business rules and the filtered transactional data (¶ [0034] states “A “node” may perform a logical function in the sense that multiple nodes of different types can run on the same physical server.” ¶ [0080] states “The client 420 may separately probe each chaincode on a periodic basis and monitor/track latency values in a client records the each peer's transaction processing latency.” ¶ [0085] states “the client 420 selects the “N” best performing peers (e.g., based on their up-to-date tx processing latencies stored in the latency list 430).” ¶ [0105] states “The method of endorsing a transaction depends on an endorsement policy which may be specified within chaincode. An example of an endorsement policy is “the majority of endorsing peers must endorse the transaction.” Different channels may have different endorsement policies.” Examiner’s Note: the client node executes on a server. A server is a computer device that can interpret business logic. The endorsement policy that specifies the number of endorsements required is a predefined business rule. The endorsement policy changes depending on the channel. The client continuously changes the selected nodes to perform endorsement based on the probing transactions).
With regard to claim 12, Novotny, Niederle, Carey, Morehead, Abdelrahman, and Li teach the system of claim 11. Niederle additionally teaches wherein the quantum computing module comprises a photonic quantum processor configured to perform quantum annealing to solve optimization problems related to job scheduling derived from the adapted job execution parameters (¶ [0004] states “a probe list including probe data for a plurality of probes, wherein the probe data for a probe comprises a probe identification and a task associated with the probe identification, wherein a task is indicative of one or more operations to be performed with a predetermined timing by a laboratory equipment on the probe.” ¶ [0075] states “In particular, the job scheduler is configured to formulate a schedule problem, for instance, based on a probe list, to provide at least a part of the schedule problem to the quantum computer for calculation. The schedule solution, in particular, the results of the quantum computer calculation indicative for the schedule solution, are then again provided to the job scheduler such that the job scheduler can determine based on the results of the quantum computer calculation a job schedule and provide respective schedule control signals to a laboratory equipment to be controlled.” ¶ [0023] states “the scheduling problem preparation unit is adapted to prepare the scheduling problem to be solvable on a quantum computer that refers to a quantum annealer.”)
Claims 13-17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Novotny, Niederle, Carey, Morehead, Abdelrahman, Li, and Nikkhah.
With regard to claim 13, Novotny, Niederle, Carey, Morehead, Abdelrahman, and Li teach the system of claim 12. Novotny, Niederle, Carey, Morehead, Abdelrahman, and Li do not explicitly teach using a neural network to predict future network conditions.
However, in an analogous art, Nikkhah teaches wherein the Al module includes a neural network trained to predict future network conditions based on historical data patterns and the received optimized strategies from the photonic quantum processor (¶ [0011] states “a server to predict a bandwidth value for a computer network element using past traffic data using an LSTM neural network”).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the LSTM neural network for predicting a bandwidth value of Nikkhah with the combination of Novotny, Niederle, Carey, Morehead, Abdelrahman, and Li. As a result, the LSTM neural network is inputted with historical traffic data and optimized strategies from the photonic quantum processor. A person having ordinary skill in the art would have been motivated to make this combination because “one advantage of LSTM to ordinary neural networks is its ability to infer long-term dependencies between data points, and learning to forget those data points that are not important. The ability to forget allows the LSTM neural network to adapt to changes in the computer network configuration without having to reconfigured the neural network” (¶ [0054]). Additionally, by using “An accurate prediction of future bandwidth requirements generated by looking at past bandwidth usage, utilization or other network traffic data allows network administrators to provide adequate provisioning for users, while avoiding the costs of overprovisioning network resources that are not necessary during a particular time period” (¶ [0002]).
With regard to claim 14, Novotny, Niederle, Carey, Morehead, Abdelrahman, Li, and Nikkhah teach the system of claim 13. Novotny additionally teaches wherein the orchestration module is further configured to sequence job execution across multiple distributed ledgers to balance the network load, based on predictions made by the neural network (¶ [0082] states “the client 420 determines that peers 412, 414, and 415 have the most efficient total processing latency value (combination of round-trip latency 432 and chaincode simulation latency 433) and sends endorsement requests to these peers accordingly.” ¶ [0089] states “the blockchain network enables load balancing among the peers so that peer resources can be utilized effectively to avoid hotspots as well as under used peers.” Examiner’s Note: the job of endorsing is distributed among multiple nodes that each have a ledger of the distributed ledger system).
Nikkhah additionally teaches wherein the orchestration module is further configured to sequence job execution across multiple distributed ledgers to balance the network load, based on predictions made by the neural network (¶ [0034] states “In step 630, the server uses the trained LSTM neural network to predict the next bandwidth value in the time series” and “In step 640, the server adjusts the bandwidth provisioned to the network element based on the predicted bandwidth value”).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the LSTM predicting future bandwidth use and a server adjusting bandwidth with the load balancing between nodes of Nikkhah with the combination of Novotny, Niederle, Carey, Morehead, Abdelrahman, and Li. As a result, the future bandwidth of nodes is used to determine which node to select for endorsement. A person having ordinary skill in the art would have been motivated to make this combination because “one advantage of LSTM to ordinary neural networks is its ability to infer long-term dependencies between data points, and learning to forget those data points that are not important. The ability to forget allows the LSTM neural network to adapt to changes in the computer network configuration without having to reconfigured the neural network” (¶ [0054]). Additionally, by using “An accurate prediction of future bandwidth requirements generated by looking at past bandwidth usage, utilization or other network traffic data allows network administrators to provide adequate provisioning for users, while avoiding the costs of overprovisioning network resources that are not necessary during a particular time period” (¶ [0002]).
With regard to claim 15, Novotny, Niederle, Carey, Morehead, Abdelrahman, Li, and Nikkhah teach the system of claim 14. Carey additionally teaches wherein the dynamic smart contracts generated by the Al module include provisions for conditional execution based on real-time network bandwidth availability, as sequenced by the orchestration module (¶ [0075] states “The blockchain data can include: whether the blockchain event is happening; when the next blockchain event will occur (… block validation, block confirmation, and/or other blockchain event, etc.); … blockchain parameters (e.g., block height, transactions per second, block time or confirmation time, etc.); and/or any other suitable data.” ¶ [0092] states “S700 preferably allocates computing resources in real- or near-real time, such that the nodes are allocated the resources immediately or after a short delay. Additionally or alternatively, S700 can schedule future computing resource allocation for one or more nodes.” ¶ [0037] states “Examples of computing resources (e.g., management system resources) that can be provided can include: … memory (e.g., addresses, blocks, memory locations, cache space, contiguous free space, management system memory, etc.) … network throughput (e.g., within the machine itself, Internet bandwidth, etc.)”),
Abdelrahman additionally teaches wherein the dynamic smart contracts generated by the Al module include provisions for conditional execution based on real-time network bandwidth availability, as sequenced by the orchestration module (¶ [0007] states “processing the smart contract logic description with a generative artificial intelligence model to generate smart contract code.” ¶ [0062] states “The smart contract logic description represents a conversion of the input logic described in the text 53 into smart code logic, e.g., such illustrating example logic paths as would be executed on the blockchain in response to different conditions”).
With regard to claim 16, Novotny, Niederle, Carey, Morehead, Abdelrahman, Li, and Nikkhah teach the system of claim 15. Novotny additionally teaches wherein the monitoring module utilizes distributed sensors across network nodes to gather comprehensive performance data for a feedback mechanism, influencing the conditional execution provisions in the dynamic smart contracts (¶ [0070] states “In response to receiving the probing transaction 422, the blockchain peer 411 may simulate the chaincode identified by the chaincode ID 423 using the simulation data, and generate a response 424 which includes simulated results, timestamps 425, and the like. For example, the timestamps may include a start time and a stop time at which execution of the chaincode started and stopped on the blockchain peer 411.” ¶ [0080] states “The client 420 may separately probe each chaincode on a periodic basis and monitor/track latency values in a client records the each peer's transaction processing latency.” ¶ [0085] states “the client 420 selects the “N” best performing peers (e.g., based on their up-to-date tx processing latencies stored in the latency list 430).” Examiner’s Note: each peer can perform the chaincode and measure the start and stop time. The generic computing component recording the timestamps and creating the response is the sensor. The response data of Novotny influences the conditional execution provisions in the dynamic smart contracts because in the combination of Novotny, Niederle, Carey, and Morehead at least the selected nodes are inputted into the quantum computer. Then, in combination with Abdelrahman, the output of the quantum computer is used to generate the smart contracts with conditional execution. Smart contracts are then executed. Therefore, the data collected from nodes in Novotny influences the conditional execution of smart contracts).
With regard to claim 17, Novotny, Niederle, Carey, Morehead, Abdelrahman, Li, and Nikkhah teach the system of claim 16. Novotny additionally teaches wherein the Al module is further configured to update the dynamic smart contracts autonomously in response to feedback indicating a deviation from optimal network performance, as determined by the monitoring module (¶ [0083] states “If the new total processing latency value is significantly different than the previous total processing latency value of the same peer (i.e., greater than the adjustable threshold), the client 420 may determine that the peer is unstable and request an additional probing transaction. Here, the client 420 may repeatedly/continuously probe the unstable peer until the latency values stabilize (are within the adjustable threshold).” Examiner’s Note: when the peer node is unstable, it is a deviation from optimal network performance).
Abdelrahman additionally teaches wherein the Al module is further configured to update the dynamic smart contracts autonomously in response to feedback indicating a deviation from optimal network performance, as determined by the monitoring module (¶ [0076] states “if the smart contract fails the validation step, the smart contract is destroyed and feedback is provided to the smart contract generator 24. In such an example, the overall flow can return to operation 54 or 56 for the creation of an updated contract”).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the creation of an update smart contract in response to a smart contract failing verification of Abdelrahman with the probing transaction revealing feedback that a blockchain is unstable of Novotny and the combination of Niederle, Carey, Morehead, Li, and Nikkhah. As a result, a smart contract may fail verification and need to be updated if the probing transaction reveals that the peer node has become unstable. A person having ordinary skill in the art would have been motivated to make this combination for the purpose of “improving logic and code design, resulting in more efficient smart contracts being executed on the distributed ledger” (Abdelrahman ¶ [0040]). Additionally, one of ordinary skill in the art would recognize that by regenerating smart contracts in response to feedback can help further improve the advantages discussed by Novotny (¶ [0043] states “reduced latency of transaction processing, improvement in the overall transaction throughput of the blockchain network, optimization of peer resource utilization to avoid skewed load distribution, identification of malfunctioning/poor performing peers in the blockchain network”).
Claims 18-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Novotny, Niederle, Carey, Morehead, Abdelrahman, Li, Nikkhah, and further in view of Gokhale Pat. No. US 20080155526 A1 (hereafter Gokhale).
With regard to claim 18, Novotny, Niederle, Carey, Morehead, Abdelrahman, Li, and Nikkhah teach the system of claim 17. Novotny additionally teaches wherein the orchestration module includes a rollback feature to revert job schedules to a previous state in event of network failure or performance degradation, as indicated by updates from the Al module (¶ [0083] states “the latency list 430 managed by the client 420 may indicate that a latency value(s) of a blockchain peer is unstable” and “If the new total processing latency value is significantly different than the previous total processing latency value of the same peer (i.e., greater than the adjustable threshold), the client 420 may determine that the peer is unstable and request an additional probing transaction. Here, the client 420 may repeatedly/continuously probe the unstable peer until the latency values stabilize (are within the adjustable threshold).” ¶ [0085] states “the client 420 selects the “N” best performing peers (e.g., based on their up-to-date tx processing latencies stored in the latency list 430).” Examiner’s Note: the selected nodes for endorsement are part of the job schedule).
Novotny, Niederle, Carey, Morehead, Abdelrahman, Li, and Nikkhah do not explicitly teach a rollback feature.
However, in an analogous art, Gokhale teaches wherein the orchestration module includes a rollback feature to revert job schedules to a previous state in event of network failure or performance degradation, as indicated by updates from the Al module (¶ [0012] states “receiving a rollback request to roll the data storage system back to a pre-update state; and automatically rolling back the updated components of the storage system to the pre-update state by using copies of the components”).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the rollback request to rollback a data storage system of Gokhale the combination of Novotny, Niederle, Carey, Morehead, Abdelrahman, Li and Nikkhah. As a result, it is the job schedules that are reverted to a previous state when there is an unstable node detected. A person having ordinary skill in the art would have been motivated to make this combination to “diminish the risks of installing software upgrades within the computer network and data migration system 102, reducing the cost of maintaining both” and “In this manner, the human labor needed to perform rollback and un-installation operations is reduced” (¶ [0023]).
With regard to claim 19, Novotny, Niederle, Carey, Morehead, Abdelrahman, Li, Nikkhah, and Gokhale teach the system of claim 18. Gokhale additionally teaches further comprising a user interface module to allow administrators to manually override the autonomous scheduling decisions made by the system, including rollback actions of the orchestration module (¶ [0054] states “In the event that the rollback manager 100 detects an error in the rollback process, the user or administrator may be prompted with an error message 214,” “The error message may further comprise action prompts,” and “the action prompt may allow the user or administrator to cancel the process and the method 200 returns to the monitoring operation of step 202.” ¶ [0058] state “FIG. 4 illustrates one schematic embodiment of a graphical user interface 400 of the rollback manager which allows an administrator or user of the data migration system or computer network to rollback or un-install various software installed within the data migration system or computer network”).
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date to combine the user interface that allows an administrator to cancel a rollback of Gokhale with the combination of Novotny, Niederle, Carey, Morehead, Abdelrahman, Li, and Nikkhah. A person having ordinary skill in the art would have been motivated to make this combination because “this interface 400 enhances the ease with which the administrator and users may monitor and customize the rollback operations” (¶ [0059]). Additionally, one of ordinary skill in the art would recognize the benefits of providing different error recovery options to an administrator, such as increased flexibility.
Response to Arguments
The previous 35 U.S.C. 112(a) and 35 U.S.C. 112(b) rejections have been withdrawn.
With regard to the 35 U.S.C. 103 rejection of claims 1-20, applicant argues that Abdelrahman does not teach generating smart contracts that “encapsulate the optimized job scheduling strategies.” Examiner respectfully disagrees. As explained in the 35 U.S.C. 103 rejection of claims 1-20, the combination of Novotny, Niederle, Carey, and Morehead teach an optimized job schedule for a task in a blockchain environment. This optimized job schedule would be inputted into the generative AI of Abdelrahman to generate the smart contracts. Therefore, the generated smart contracts encapsulated the optimized job scheduling strategies.
Regarding additional arguments under 35 U.S.C. 103, applicant’s arguments with respect to claim(s) 1-20 have been considered but are moot because the new ground of rejection does not rely on the combination of references applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20200221299 A1
teaches
AUTHENTICATING RADIO ACCESS NETWORK COMPONENTS USING DISTRIBUTED LEDGER TECHNOLOGY
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
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 nonprovisional extension fee (37 CFR 1.17(a)) 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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PETER L YUAN whose telephone number is (571)272-5737. The examiner can normally be reached Mon-Fri 7:30am-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, Bradley Teets can be reached at 571-272-3338. 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.
/PETER LI YUAN/Examiner, Art Unit 2197
/BRADLEY A TEETS/Supervisory Patent Examiner, Art Unit 2197
Prosecution Insights