DETAILED ACTION
This Office Action is in response to communications filed on December 17, 2025 for Application No. 17/874,605, in which claims 1-9, 11-15, and 17-20 are presented for examination. The amendments filed on December 17, 2025 have been entered, where claims 1, 4, 9, 11-13, and 17-20 are amended and claims 10 and 16 are canceled.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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-3, 8-9, 11-15, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Krneta et al. (hereinafter Krneta) (Pat. Pub. No. US 2023/0153155 A1) in view of Coopmans et al. (hereinafter Coopmans) (“NetSquid, a NETwork Simulator for QUantum Information using Discrete events”).
Regarding Claim 1, Krneta teaches a method, comprising (Para. [0076], “The various systems and methods as illustrated in the figures and described herein represent example embodiments of methods”):
receiving, by one or more computing devices, data (Fig. 7; Para. [0058], “FIG. 7 is a flowchart illustrating an example method . . . a request may be received, e.g., from a user, at an algorithm execution management system via a user interface (e.g., at algorithm execution management system 106 via user interface 108) . . . as indicated in block 702”, where the “request” is data and the “algorithm execution management system” is “implemented by a computer device”, see Fig. 9; Para. [0069], “the algorithm execution management system described above may be implemented by a computer device, for instance, a computer device as in FIG. 9”)
. . . a quantum computing network (Para. [0001], “A provider network may allow user to access services, via network connections, that are implemented using resources at locations remote from the users”; see also Para. [0005], “FIG. 4 is a block diagram showing an example quantum computing service of a provider network, according to some embodiments”; Fig. 4, where the “Provider Network 102” is a quantum computing network because it provides “Quantum Computing Service[s] 104”);
in response to receiving the data (Para. [0014], “the algorithm execution management system may receive a request from a user for execution of an algorithm . . . the container may provide a compute environment within which the algorithm may be executed at the classical computing resources”),
generating, by the one or more computing devices, a plurality of quantum simulator nodes . . . , each of the plurality of quantum simulator nodes (Fig. 4; Para. [0041], “In some embodiments, quantum compute simulator using classical hardware 418 of quantum computing service 104 may be used to simulate an algorithm using classical hardware . . . quantum compute simulator using classical hardware 418 may include one or more “warm” simulators that are pre-configured simulators”, where the “quantum compute simulator” is a simulator node, which can be implemented as a plurality of “simulators”, see also Para. [0041], “one or more virtual machines of a virtual computing service may be instantiated to process an algorithm simulation job . . . the simulation may involve multiple classical computing resources”; where “instantiat[ion]”, “pre-configurat[ion]”, and “using” both are and require generating; and where the functionality is implemented by a “computing device”, see generally Fig. 9; Para. [0069], “FIG. 9 shows an example computing device to implement the various techniques described herein, according to some embodiments”)
implemented on one or more classical computing devices of a plurality of classical computing devices (Para. [0041], "In some embodiments, quantum compute simulator using classical hardware 418 of quantum computing service 104 may be used to simulate an algorithm using classical hardware . . . In some embodiments, quantum compute simulator using classical hardware 418 may fully manage compute instances that perform the simulation”, where, as discussed above, each of the plurality of “quantum compute simulator . . . 418”, see Para. [0041], “one or more virtual machines of a virtual computing service may be instantiated to process an algorithm simulation job . . . the simulation may involve multiple classical computing resources . . . quantum compute simulator using classical hardware 418 may include one or more “warm” simulators”, are quantum simulator nodes, which are implemented by one or more classical computing devices of a plurality of classical computing devices, “classical computing devices”; see also Para. [0013], “The scope of the present disclosure includes any feature or combination of features disclosed herein”)
and operable to simulate one of a plurality of different [simulations] . . . (Para. [0041], “one or more virtual machines of a virtual computing service may be instantiated to process an algorithm simulation job . . . the simulation may involve multiple classical computing resources . . . quantum compute simulator using classical hardware 418 may include one or more “warm” simulators that are pre-configured simulators such that they are ready to perform a simulation job”, where the “simulators” may be “pre-configured” to “perform a simulation job”, which will be different from other simulations based on the specific “pre-configur[ations]”; see also Para. [0024], “In some embodiments, the container may also include one or more environment variables, and user 116 may specify their values to further customize the compute environment”, where the simulations can differ based on “user” “customiz[ation]” of “the compute environment”);
storing, by the one or more computing devices, each of the plurality of quantum simulator nodes as an execution node of the quantum computing network to execute a quantum service (Para. [0021]- [0023], “user 116 may provide algorithm execution management system 106, e.g., via user interface 108, request 118 for executing an algorithm using different types of computing resources, including classical computing resources 110 and quantum computing resources 112. In some embodiments, request 118 may indicate a container for the algorithm, for example, container 120 . . . In some embodiments, user 116 may further store the created container at container repositories 118 of provider network 102”, where the “classical” and “quantum” resources, which as discussed above includes each of the quantum compute simulator, are execution nodes because they are “store[d]” as part of “network” and used for “executing”; see also Para. [0041], “quantum compute simulator using classical hardware 418 may include one or more “warm” simulators that are pre-configured simulators”, where the “simulators” must be stored to be “pre-configured” for use as “warm simulators”),
wherein the quantum computing device and each of the plurality of quantum simulator nodes (Fig. 4, where the “Quantum Hardware”, such as “422” through “428”, are the plurality of quantum computing devices and the “Quantum Compute Simulator . . . 418” is a quantum simulator node, which can be implemented as a plurality, see Para. [0041], “one or more virtual machines of a virtual computing service may be instantiated to process an algorithm simulation job . . . the simulation may involve multiple classical computing resources . . . quantum compute simulator using classical hardware 418 may include one or more “warm” simulators”)
are a respective execution node of a plurality of execution nodes (Para. [0042], “user 116 may specify quantum computing resources 112 to be used for executing the user’s algorithm” and Para. [0046], “executing the algorithm at classical computing resources 110”, where both the “quantum” resources and “classical” resources, which implement the simulator, are a respective execution node of a plurality of execution nodes because they are resources of the network used for “executing”; see also Para. [0038]-[0041], “FIG. 4 shows an example quantum computing service of a provider network, according to some embodiments. In FIG. 4, provider network 102 may include quantum computing service 104, which may provide user 116 access to various quantum computing resources offered by quantum hardware providers 422, 424, 426, and 428 . . . In some embodiments, quantum compute simulator using classical hardware 418 of quantum computing service 104 may be used to simulate an algorithm using classical hardware”)
operable to execute the quantum service (Abstract, “An algorithm execution management system of a provider network . . . to be executed at the quantum computing resources ”; see generally Para. [0001], “A provider network may allow user to access services, via network connections, that are implemented using resources at locations remote from the users. Such services may be said to reside “in the cloud.” A cloud-based quantum computing service may provide users access to quantum computers (also called quantum processing units) of various quantum hardware providers”); and
determining, by the one or more computing devices, a selected execution node of the plurality of execution nodes to execute the quantum service based at least in part on . . . the selected execution node, wherein determining the selected execution node comprises (Para. [0015], “in some embodiments, based on the algorithm provided by the user, the algorithm execution management system may identify or select appropriate quantum computing resources (e.g., from a pool of quantum computing resources) for the user”; Para. [0016], “The algorithm execution management system may identify the classical computing resources (e.g., from a pool of classical computing resources) if the classical computing resources have not yet been identified, and perform configurations to provision the classical computing resources as a co-processor”, which is implemented by a “computing device”, see Para. [0069], “FIG. 9 shows an example computing device to implement the various techniques described herein, according to some embodiments”):
determining, by the one or more computing devices based on the quantum service, whether to execute the quantum service using the quantum computing device or a classical computing device (Para. [0015] – [0016], “In some embodiments, responsive to receiving the request from the user, the algorithm execution management system may determine whether the quantum computing resources are available to execute the algorithm . . . in some embodiments, based on the algorithm provided by the user, the algorithm execution management system may identify or select appropriate quantum computing resources . . . In some embodiments, the algorithm execution management system may cause the classical computing resources to be provisioned on-demand . . . The algorithm execution management system may instruct at least one portion of the algorithm to be executed at the classical computing resources using the container provided in the request, and at least another portion of the algorithm to be executed at the quantum computing resources”)
comprising a respective quantum simulator node of the plurality of quantum simulator nodes (Para. [0041], "In some embodiments, quantum compute simulator using classical hardware 418 of quantum computing service 104 may be used to simulate an algorithm using classical hardware . . . In some embodiments, quantum compute simulator using classical hardware 418 may fully manage compute instances that perform the simulation”, where, as discussed above, each of the plurality of “quantum compute simulator . . . 418”, see Para. [0041], “one or more virtual machines of a virtual computing service may be instantiated to process an algorithm simulation job . . . the simulation may involve multiple classical computing resources . . . quantum compute simulator using classical hardware 418 may include one or more “warm” simulators”, are quantum simulator nodes, which are implemented by one or more classical computing devices of a plurality of classical computing devices, “classical computing devices”; see also Para. [0013], “The scope of the present disclosure includes any feature or combination of features disclosed herein”).
Krneta does not explicitly teach . . . indicative of a quantum computing device joining . . . for the quantum computing device . . . operating states of the quantum computing device . . . an operating state associated with . . . .
However, Coopmans teaches . . . [data] indicative of a quantum computing device joining [a quantum computing network] (Pg. 10, Col. 2, Para. 3, “NetSquid is entirely modular, allowing users to set up large scale simulations of complicated networks and to explore variations in the network design . . . exchanging classical and quantum communication with other nodes as dictated by the protocol”, where the “quantum communication” is received by the “quantum network” to “connect distant quantum devices”, see Pg. 2, Col. 1, Para. 1, “Quantum communication can be used to connect distant quantum devices into a quantum network”)
. . . [simulating] for the quantum computing device . . . [a plurality of different] operating states of the quantum computing device (Pg. 11, Col. 1, Para. 6, “All physical devices in a quantum network are modelled by a ‘component’ object, and are thereby also all simulation entities”; Pg. 10, Col. 2, Para. 3, “NetSquid allows the modelling of any physical device in the network that can be mapped to qubits. To demonstrate this we studied two use cases involving nitrogen-vacancy centres in diamond as well as atomic-ensemble based memories”, where the “modeling of any physical device” includes “simulation” with “nitrogen-vacancy centres” “use cases”; Pg. 4, Col. 1, Para. 2, “The performance metrics of a simulation are determined statistically from many runs. Due to the independence of each run, simulations can be massively parallelised and thereby efficiently executed on computing clusters”, where “independen[t]” “simulation” “run[s]” creates a plurality of simulated operating states; see also Pg. 7, Fig. 6, “The NV hardware model consists of ~15 parameters and from those we focus on four parameters in this figure: (A) two-qubit gate fidelity, (B) detection probability, (C) induced storage qubit noise and (D) visibility . . . We start by improving all ~15 parameters . . . Then, for each of the four parameters only, we individually decrease their improvement”, where variations in operating states based on changes to the “~15 parameters” are simulated)
. . . [selection based on] an operating state associated with [a simulation] . . . (Pg. 11, Col. 1, Para. 6, “All physical devices in a quantum network are modelled by a ‘component’ object, and are thereby also all simulation entities”; Pg. 10, Col. 2, Para. 3, “NetSquid allows the modelling of any physical device in the network that can be mapped to qubits. To demonstrate this we studied two use cases involving nitrogen-vacancy centres in diamond as well as atomic-ensemble based memories”, where the “modeling of any physical device” includes “simulation” with “nitrogen-vacancy centres” “use cases”; Pg. 4, Col. 1, Para. 2, “The performance metrics of a simulation are determined statistically from many runs. Due to the independence of each run, simulations can be massively parallelised and thereby efficiently executed on computing clusters”, where “independen[t]” “simulation” “run[s]” creates a plurality of simulated operating states; see also Pg. 7, Fig. 6, “The NV hardware model consists of ~15 parameters and from those we focus on four parameters in this figure: (A) two-qubit gate fidelity, (B) detection probability, (C) induced storage qubit noise and (D) visibility . . . We start by improving all ~15 parameters . . . Then, for each of the four parameters only, we individually decrease their improvement”, where variations in operating states based on changes to the “~15 parameters” are simulated).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to combine the method comprising receiving data by a quantum computing network device, generating a plurality of simulator nodes to simulate a plurality of different simulations, storing the simulator nodes as execution nodes to execute a quantum service, and selecting of an execution node of Krneta with the data indicative of a quantum device joining a quantum network, the simulating of a plurality of operating states for the quantum device, and the selecting based on an operating state associated with a simulation of Coopmans in order to add distant quantum devices to the network, which would increase the scalability of the simulations (Coopmans, Pg. 2, Col. 1, Para. 1, “Quantum communication can be used to connect distant quantum devices into a quantum network. At short distances, networking quantum devices provides a path towards a scalable distributed quantum computer”; Krneta, Para. [0001], “A cloud-based quantum computing service may provide users access to quantum computers (also called quantum processing units) of various quantum hardware providers”), and to analyze the effectiveness of different operating states, which will allow users to select the best operating state for the quantum service (Coopmans, Pg. 10, Col. 2, Para. 3, “NetSquid allows the modelling of any physical device in the network that can be mapped to qubits”; Coopmans, Pg. 7, Para. 1, “These observations indicate that detection probability is the most important parameter for realising remote-entanglement generation with the SWAP-ASAP scheme, followed by two-qubit gate noise and induced storage qubit noise”; Krneta, Para. [0042], “algorithm execution management system 106 may use quantum hardware recommendation/selection module 420 to make a recommendation to user 116 as to which type of quantum computer or which quantum hardware provider to use to execute a quantum program submitted by the user”).
Regarding Claim 2, Krneta in view of Coopmans teach the method of claim 1, wherein each of the plurality of different operating states (Coopmans, Pg. 11, Col. 1, Para. 6, “All physical devices in a quantum network are modelled by a ‘component’ object, and are thereby also all simulation entities”; Coopmans, Pg. 10, Col. 2, Para. 3, “NetSquid allows the modelling of any physical device in the network that can be mapped to qubits. To demonstrate this we studied two use cases involving nitrogen-vacancy centres in diamond as well as atomic-ensemble based memories”, where the “modeling of any physical device” includes “simulation” with “nitrogen-vacancy centres” “use cases”; Coopmans, Pg. 4, Col. 1, Para. 2, “The performance metrics of a simulation are determined statistically from many runs. Due to the independence of each run, simulations can be massively parallelised and thereby efficiently executed on computing clusters”, where “independen[t]” “simulation” “run[s]” creates a plurality of simulated operating states)
is associated with a parameter set for the quantum computing device (Coopmans, Pg. 7, Fig. 6, “The NV hardware model consists of ~15 parameters and from those we focus on four parameters in this figure: (A) two-qubit gate fidelity, (B) detection probability, (C) induced storage qubit noise and (D) visibility . . . We start by improving all ~15 parameters . . . Then, for each of the four parameters only, we individually decrease their improvement”, where variations in operating states based on changes to the “~15 parameters” are simulated).
The reasons of obviousness are discussed above in regard to the rejection of Claim 1 and remain applicable here.
Regarding Claim 3, Krneta in view of Coopmans teach the method of claim 2, wherein the parameter set comprises data indicative of one or more of a number of qubits, qubit type, quantum error correction scheme, qubit load, or qubit noise profile (Coopmans, Pg. 7, Fig. 6, “The NV hardware model consists of ~15 parameters and from those we focus on four parameters in this figure: (A) two-qubit gate fidelity, (B) detection probability, (C) induced storage qubit noise and (D) visibility . . . We start by improving all ~15 parameters . . . Then, for each of the four parameters only, we individually decrease their improvement”, where “(C) induced storage qubit noise” comprises data indicative of qubit noise profile).
The reasons of obviousness are discussed above in regard to the rejection of Claim 1 and remain applicable here.
Regarding Claim 8, Krneta in view of Coopmans teach the method of claim 1, wherein the quantum computing network comprises a plurality of quantum computing devices (Krneta, Fig. 4; Krneta, Para. [0038], “FIG. 4 shows an example quantum computing service of a provider network . . . [the] provider network 102 may include quantum computing service 104, which may provide user 116 access to various quantum computing resources offered by quantum hardware providers 422, 424, 426, and 428. As indicated in FIG. 4, quantum hardware providers 422, 424, 426, and 428 may provide various different types of quantum computing resources”, where the quantum computing network, “provider network 102”, comprises “quantum hardware providers 422, 424, 426, and 428”, which are a plurality of quantum computing devices).
Regarding Claim 9, Krneta in view of Coopmans teach the method of claim 8, wherein each of the plurality of quantum computing devices (Krneta, Fig. 4, where the “Quantum Hardware”, such as “422” through “428”, are the plurality of quantum computing devices)
are a respective execution node (Krneta, Para. [0042], “user 116 may specify quantum computing resources 112 to be used for executing the user’s algorithm” and Krneta, Para. [0046], “executing the algorithm at classical computing resources 110”, where the “quantum” resources are execution nodes because they are resources of the network used for “executing”; see also Krneta, Para. [0038]-[0041], “FIG. 4 shows an example quantum computing service of a provider network, according to some embodiments. In FIG. 4, provider network 102 may include quantum computing service 104, which may provide user 116 access to various quantum computing resources offered by quantum hardware providers 422, 424, 426, and 428 . . . In some embodiments, quantum compute simulator using classical hardware 418 of quantum computing service 104 may be used to simulate an algorithm using classical hardware”)
of the quantum computing network to execute the quantum service (Krneta, Abstract, “An algorithm execution management system of a provider network . . . to be executed at the quantum computing resources ”; see generally Krneta, Para. [0001], “A provider network may allow user to access services, via network connections, that are implemented using resources at locations remote from the users. Such services may be said to reside “in the cloud.” A cloud-based quantum computing service may provide users access to quantum computers (also called quantum processing units) of various quantum hardware providers”).
Regarding Claim 11, Krneta in view of Coopmans teach the method of claim 1, wherein the method further comprises (Krneta, Para. [0076], “The various systems and methods as illustrated in the figures and described herein represent example embodiments of methods”):
receiving, by the one or more computing devices, a request to execute a quantum service (Krneta, Abstract, “An algorithm execution management system of a provider network may receive a request from a user for executing an algorithm using different types of computing resources, including classical computing resources and quantum computing resources”, which is implemented by a “computing device”, see Krneta, Para. [0069], “FIG. 9 shows an example computing device to implement the various techniques described herein, according to some embodiments”);
accessing, by the one or more computing devices, the quantum computing network to execute the quantum service (Krneta, Para. [0001], “A provider network may allow user to access services, via network connections, that are implemented using resources at locations remote from the users”; see also Krneta, Para. [0005], “FIG. 4 is a block diagram showing an example quantum computing service of a provider network, according to some embodiments”; Krneta, Fig. 4, where the “Provider Network 102” is a quantum computing network because it provides “Quantum Computing Service[s] 104”, which is implemented by a “computing device”, see Krneta, Para. [0069], “FIG. 9 shows an example computing device to implement the various techniques described herein, according to some embodiments”); and
obtaining, by the one or more computing devices, a result for the quantum service executed at the selected execution node (Krneta, para. [0017], “In some embodiments, the algorithm execution management system may receive a result of the execution of the algorithm from the classical computing resources and/or the quantum computing resources”, which is implemented by a “computing device”, see Krneta, Para. [0069], “FIG. 9 shows an example computing device to implement the various techniques described herein, according to some embodiments”).
The reasons of obviousness are discussed above in regard to the rejection of Claim 1 and remain applicable here.
Regarding Claim 12, Krneta in view of Coopmans teach the method of claim 1, wherein determining, by the one or more computing devices, the selected execution node to execute the quantum service based at least in part on an operating state associated with the selected execution node, further comprises (Krneta, Para. [0015], “in some embodiments, based on the algorithm provided by the user, the algorithm execution management system may identify or select appropriate quantum computing resources (e.g., from a pool of quantum computing resources) for the user”; Krneta, para. [0016], “The algorithm execution management system may identify the classical computing resources (e.g., from a pool of classical computing resources) if the classical computing resources have not yet been identified, and perform configurations to provision the classical computing resources as a co-processor”, where, in view of Coopmans, the “quantum” and “classical” resource execution nodes are selected based at least in part on the operating state associated with it, see Coopmans, Pg. 11, Col. 1, Para. 6, “All physical devices in a quantum network are modelled by a ‘component’ object, and are thereby also all simulation entities”; Coopmans, Pg. 10, Col. 2, Para. 3, “NetSquid allows the modelling of any physical device in the network that can be mapped to qubits. To demonstrate this we studied two use cases involving nitrogen-vacancy centres in diamond as well as atomic-ensemble based memories”, where the “modeling of any physical device” includes “simulation” with “nitrogen-vacancy centres” “use cases”; Coopmans, Pg. 4, Col. 1, Para. 2, “The performance metrics of a simulation are determined statistically from many runs. Due to the independence of each run, simulations can be massively parallelised and thereby efficiently executed on computing clusters”, where “independen[t]” “simulation” “run[s]” creates a plurality of simulated operating states; see also Coopmans, Pg. 7, Fig. 6, “The NV hardware model consists of ~15 parameters and from those we focus on four parameters in this figure: (A) two-qubit gate fidelity, (B) detection probability, (C) induced storage qubit noise and (D) visibility . . . We start by improving all ~15 parameters . . . Then, for each of the four parameters only, we individually decrease their improvement”, where variations in operating states based on changes to the “~15 parameters” are simulated; and which is implemented by a “computing device”, see Krneta, Para. [0069], “FIG. 9 shows an example computing device to implement the various techniques described herein, according to some embodiments”):
determining, by the one or more computing devices (Krneta, Para. [0069], “FIG. 9 shows an example computing device to implement the various techniques described herein, according to some embodiments”),
a performance profile for the quantum service (Krneta, Para. [0021], “request 118 may indicate a container for the algorithm . . . The container may be a package of software that includes the algorithm code and its dependencies so that the algorithm code may be portable and executable from one classical computing resource to another. For example, in some embodiments, the container may include the code of the algorithm (which may be included in one or more script files), one or more associated libraries for executing the algorithm, runtime (e.g., software or instructions that are executed while the algorithm is executed), and/or one or more system tools and settings (e.g., environment variables)”; Krneta, Para. [0026], “user 116 may embed an identifier (or ID) of a type of a quantum computing unit (QPU) into a value of an environment variable of the container”, where the request details, such as “dependencies”, “system . . . settings”, and “type of quantum computing unit”, form a performance profile for the request, which must be determined by the device to allow for selection to be based on it, see Krneta, Para. [0015], “based on the algorithm provided by the user, the algorithm execution management system may identify or select appropriate quantum computing resources (e.g., from a pool of quantum computing resources) for the user”); and
determining the selected execution node to execute the quantum service based at least in part by a comparison of the performance profile for the quantum service and the operating state associated with the selected execution node (Krneta, Para. [0015], “ responsive to receiving the request from the user . . . the algorithm execution management system may identify or select appropriate quantum computing resources (e.g., from a pool of quantum computing resources) for the user”, where, as discussed above, the ”request” includes a performance profile, and the “select[ion]” of the “resource” is based on a comparison of the “appropriate . . . resource” for the service “request” from the user; Krneta, para. [0016], “The algorithm execution management system may identify the classical computing resources (e.g., from a pool of classical computing resources) if the classical computing resources have not yet been identified, and perform configurations to provision the classical computing resources as a co-processor”, where, in view of Coopmans, the “quantum” and “classical” resource execution nodes are associated with an operating state, and therefore, the above comparison is based on the operating states, see Coopmans, Pg. 11, Col. 1, Para. 6, “All physical devices in a quantum network are modelled by a ‘component’ object, and are thereby also all simulation entities”; Coopmans, Pg. 10, Col. 2, Para. 3, “NetSquid allows the modelling of any physical device in the network that can be mapped to qubits. To demonstrate this we studied two use cases involving nitrogen-vacancy centres in diamond as well as atomic-ensemble based memories”, where the “modeling of any physical device” includes “simulation” with “nitrogen-vacancy centres” “use cases”; Coopmans, Pg. 4, Col. 1, Para. 2, “The performance metrics of a simulation are determined statistically from many runs. Due to the independence of each run, simulations can be massively parallelised and thereby efficiently executed on computing clusters”, where “independen[t]” “simulation” “run[s]” creates a plurality of simulated operating states; see also Coopmans, Pg. 7, Fig. 6, “The NV hardware model consists of ~15 parameters and from those we focus on four parameters in this figure: (A) two-qubit gate fidelity, (B) detection probability, (C) induced storage qubit noise and (D) visibility . . . We start by improving all ~15 parameters . . . Then, for each of the four parameters only, we individually decrease their improvement”, where variations in operating states based on changes to the “~15 parameters” are simulated; and which is implemented by a “computing device”).
The reasons of obviousness are discussed above in regard to the rejection of Claim 1 and remain applicable here.
Regarding Claim 13, Krneta in view of Coopmans teach a computing device comprising: a memory; and a processor device coupled to the memory to (Krneta, Para. [0069], “FIG. 9 shows an example computing device to implement the various techniques described herein, according to some embodiments”; Krneta, Fig. 9, where the “Computing Device 900” comprises “System Memory 920” and “Processor[s]” “910a” to “910n”, which as indicated by figure arrows, are coupled to the “System Memory 920”):
receive a request to execute a quantum service (Krneta, Abstract, “An algorithm execution management system of a provider network may receive a request from a user for executing an algorithm using different types of computing resources, including classical computing resources and quantum computing resources”);
access a quantum computing network to execute the quantum service (Krneta, Para. [0001], “A provider network may allow user to access services, via network connections, that are implemented using resources at locations remote from the users”; see also Krneta, Para. [0005], “FIG. 4 is a block diagram showing an example quantum computing service of a provider network, according to some embodiments”; Krneta, Fig. 4, where the “Provider Network 102” is a quantum computing network because it provides “Quantum Computing Service[s] 104”),
the quantum computing network comprising a plurality of quantum computing devices and a plurality of quantum simulator nodes (Krneta, Fig. 4, where the plurality of quantum computing devices, “422” through “428”, and the “Quantum Compute Simulator[s] . . . 418”, which are also a plurality, see Krneta, Para. [0041], “one or more virtual machines of a virtual computing service may be instantiated to process an algorithm simulation job . . . the simulation may involve multiple classical computing resources . . . quantum compute simulator using classical hardware 418 may include one or more “warm” simulators”, are part of a “Provider Network”; see also Krneta, Para. [0038], “FIG. 4 shows an example quantum computing service of a provider network . . . [the] provider network 102 may include quantum computing service 104, which may provide user 116 access to various quantum computing resources offered by quantum hardware providers 422, 424, 426, and 428. As indicated in FIG. 4, quantum hardware providers 422, 424, 426, and 428 may provide various different types of quantum computing resources”),
implemented on one or more classical computing devices of a plurality of classical computing devices (Krneta, Para. [0041], "In some embodiments, quantum compute simulator using classical hardware 418 of quantum computing service 104 may be used to simulate an algorithm using classical hardware . . . In some embodiments, quantum compute simulator using classical hardware 418 may fully manage compute instances that perform the simulation”, where, as discussed above, each of the plurality of “quantum compute simulator . . . 418”, see Krneta, Para. [0041], “one or more virtual machines of a virtual computing service may be instantiated to process an algorithm simulation job . . . the simulation may involve multiple classical computing resources . . . quantum compute simulator using classical hardware 418 may include one or more “warm” simulators”, are quantum simulator nodes, which are implemented by one or more classical computing devices of a plurality of classical computing devices, “classical computing devices”; see also Krneta, Para. [0013], “The scope of the present disclosure includes any feature or combination of features disclosed herein”),
each quantum simulator node operable to simulate a different operating state for one of the plurality of quantum computing devices (Krneta, Para. [0041], “one or more virtual machines of a virtual computing service may be instantiated to process an algorithm simulation job . . . the simulation may involve multiple classical computing resources . . . quantum compute simulator using classical hardware 418 may include one or more “warm” simulators that are pre-configured simulators such that they are ready to perform a simulation job”, where the “simulators” may be “pre-configured” to “perform a simulation job”, which will be different from other simulations based on the specific “pre-configur[ations]”; see also Krneta, Para. [0024], “In some embodiments, the container may also include one or more environment variables, and user 116 may specify their values to further customize the compute environment”, where the simulations can differ based on “user” “customiz[ation]” of “the compute environment”; and where in view of Coopmans, the simulations are differ based on operating states for one of a plurality of devices, “All physical devices”, see Coopmans, Pg. 11, Col. 1, Para. 6, “All physical devices in a quantum network are modelled by a ‘component’ object, and are thereby also all simulation entities”; Coopmans, Pg. 10, Col. 2, Para. 3, “NetSquid allows the modelling of any physical device in the network that can be mapped to qubits. To demonstrate this we studied two use cases involving nitrogen-vacancy centres in diamond as well as atomic-ensemble based memories”, where the “modeling of any physical device” includes “simulation” with “nitrogen-vacancy centres” “use cases”; Coopmans, Pg. 4, Col. 1, Para. 2, “The performance metrics of a simulation are determined statistically from many runs. Due to the independence of each run, simulations can be massively parallelised and thereby efficiently executed on computing clusters”, where “independen[t]” “simulation” “run[s]” creates a plurality of simulated operating states; see also Coopmans, Pg. 7, Fig. 6, “The NV hardware model consists of ~15 parameters and from those we focus on four parameters in this figure: (A) two-qubit gate fidelity, (B) detection probability, (C) induced storage qubit noise and (D) visibility . . . We start by improving all ~15 parameters . . . Then, for each of the four parameters only, we individually decrease their improvement”, where variations in operating states based on changes to the “~15 parameters” are simulated),
the plurality of quantum computing devices and the plurality of quantum simulator nodes are each an execution node (Krneta, Para. [0042], “user 116 may specify quantum computing resources 112 to be used for executing the user’s algorithm” and Krneta, Para. [0046], “executing the algorithm at classical computing resources 110”, where both the “quantum” resources and “classical” resources, which implement the simulator, are execution nodes because they are resources of the network used for “executing”; see also Krneta, Para. [0038]-[0041], “FIG. 4 shows an example quantum computing service of a provider network, according to some embodiments. In FIG. 4, provider network 102 may include quantum computing service 104, which may provide user 116 access to various quantum computing resources offered by quantum hardware providers 422, 424, 426, and 428 . . . In some embodiments, quantum compute simulator using classical hardware 418 of quantum computing service 104 may be used to simulate an algorithm using classical hardware”)
of a plurality of execution nodes (Krneta, Para. [0042], “user 116 may specify quantum computing resources 112 to be used for executing the user’s algorithm” and Krneta, Para. [0046], “executing the algorithm at classical computing resources 110”, where both the “quantum” resources and “classical” resources, which implement the simulator, are a respective execution node of a plurality of execution nodes because they are resources of the network used for “executing”; see also Krneta, Para. [0038]-[0041], “FIG. 4 shows an example quantum computing service of a provider network, according to some embodiments. In FIG. 4, provider network 102 may include quantum computing service 104, which may provide user 116 access to various quantum computing resources offered by quantum hardware providers 422, 424, 426, and 428 . . . In some embodiments, quantum compute simulator using classical hardware 418 of quantum computing service 104 may be used to simulate an algorithm using classical hardware”)
of the quantum computing network (Krneta, Abstract, “An algorithm execution management system of a provider network . . . to be executed at the quantum computing resources ”; see generally Krneta, Para. [0001], “A provider network may allow user to access services, via network connections, that are implemented using resources at locations remote from the users. Such services may be said to reside “in the cloud.” A cloud-based quantum computing service may provide users access to quantum computers (also called quantum processing units) of various quantum hardware providers”);
determine a selected execution node to execute the quantum service based at least in part on an operating state associated with the selected execution node, wherein to determine the selected execution node (Krneta, Para. [0015], “in some embodiments, based on the algorithm provided by the user, the algorithm execution management system may identify or select appropriate quantum computing resources (e.g., from a pool of quantum computing resources) for the user”; Krneta, para. [0016], “The algorithm execution management system may identify the classical computing resources (e.g., from a pool of classical computing resources) if the classical computing resources have not yet been identified, and perform configurations to provision the classical computing resources as a co-processor”, where, in view of Coopmans, the “quantum” and “classical” resource execution nodes are selected based at least in part on the operating state associated with it, see Coopmans, Pg. 11, Col. 1, Para. 6, “All physical devices in a quantum network are modelled by a ‘component’ object, and are thereby also all simulation entities”; Coopmans, Pg. 10, Col. 2, Para. 3, “NetSquid allows the modelling of any physical device in the network that can be mapped to qubits. To demonstrate this we studied two use cases involving nitrogen-vacancy centres in diamond as well as atomic-ensemble based memories”, where the “modeling of any physical device” includes “simulation” with “nitrogen-vacancy centres” “use cases”; Coopmans, Pg. 4, Col. 1, Para. 2, “The performance metrics of a simulation are determined statistically from many runs. Due to the independence of each run, simulations can be massively parallelised and thereby efficiently executed on computing clusters”, where “independen[t]” “simulation” “run[s]” creates a plurality of simulated operating states; see also Coopmans, Pg. 7, Fig. 6, “The NV hardware model consists of ~15 parameters and from those we focus on four parameters in this figure: (A) two-qubit gate fidelity, (B) detection probability, (C) induced storage qubit noise and (D) visibility . . . We start by improving all ~15 parameters . . . Then, for each of the four parameters only, we individually decrease their improvement”, where variations in operating states based on changes to the “~15 parameters” are simulated),
the processor device is further to (Krneta, Para. [0069], “FIG. 9 shows an example computing device to implement the various techniques described herein, according to some embodiments”; Krneta, Fig. 9, where the “Computing Device 900” comprises “System Memory 920” and “Processor[s]” “910a” to “910n”, which as indicated by figure arrows, are coupled to the “System Memory 920”):
determine whether to execute the quantum service using one of the plurality of quantum computing devices or one of the plurality of quantum simulator nodes (Krneta, Para. [0015] – [0016], “In some embodiments, responsive to receiving the request from the user, the algorithm execution management system may determine whether the quantum computing resources are available to execute the algorithm . . . in some embodiments, based on the algorithm provided by the user, the algorithm execution management system may identify or select appropriate quantum computing resources . . . In some embodiments, the algorithm execution management system may cause the classical computing resources to be provisioned on-demand . . . The algorithm execution management system may instruct at least one portion of the algorithm to be executed at the classical computing resources using the container provided in the request, and at least another portion of the algorithm to be executed at the quantum computing resources”); and
obtain a result for the quantum service executed at the selected execution node (Krneta, para. [0017], “In some embodiments, the algorithm execution management system may receive a result of the execution of the algorithm from the classical computing resources and/or the quantum computing resources”).
The reasons of obviousness are discussed above in regard to the rejection of Claim 1 and remain applicable here.
Regarding Claim 14, the additional elements of the dependent claim are substantially the same as limitations of Claim 2, therefore it is rejected under the same rationale.
Regarding Claim 15, the additional elements of the dependent claim are substantially the same as limitations of Claim 3, therefore it is rejected under the same rationale.
Regarding Claim 18, Krneta teaches a non-transitory computer-readable storage medium having stored thereon computer-executable instructions that, when executed, cause one or more processor devices to . . . (Krneta, Fig. 9; Krneta, Para. [0069], “FIG. 9 shows an example computing device to implement the various techniques described herein, according to some embodiments. For example, in one embodiment, the algorithm execution management system described above may be implemented by a computer device, for instance, a computer device as in FIG. 9 that includes one or more processors executing program instructions stored on a computer-readable storage medium coupled to the processors”).
The remaining limitations are substantially the same as limitations of Claim 1, therefore it is rejected under the same rationale.
Claims 4-6 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Krneta in view of Coopmans and Dasgupta et al. (hereinafter Dasgupta) (“Stability of Noisy Quantum Computing Devices”).
Regarding Claim 4, Krneta in view of Coopmans teach the method of claim 1, wherein generating, by the one or more computing devices, a plurality of quantum simulator nodes for the quantum computing device comprises (Krneta, Fig. 4; Krneta, Para. [0041], “In some embodiments, quantum compute simulator using classical hardware 418 of quantum computing service 104 may be used to simulate an algorithm using classical hardware . . . quantum compute simulator using classical hardware 418 may include one or more “warm” simulators that are pre-configured simulators”, where the “quantum compute simulator” is a simulator node, which can be implemented as a plurality of “simulators”, see also Krneta, Para. [0041], “one or more virtual machines of a virtual computing service may be instantiated to process an algorithm simulation job . . . the simulation may involve multiple classical computing resources”; where “instantiat[ion]”, “pre-configurat[ion]”, and “using” both are and require generating; and where the functionality is implemented by a “computing device”, see generally Krneta, Fig. 9; Krneta, Para. [0069], “FIG. 9 shows an example computing device to implement the various techniques described herein, according to some embodiments”; and where in view of Coopmans, the plurality of simulator nodes are for the quantum computing device, see Coopmans, Pg. 10, Col. 2, Para. 3, “NetSquid allows the modelling of any physical device in the network that can be mapped to qubits. To demonstrate this we studied two use cases involving nitrogen-vacancy centres in diamond as well as atomic-ensemble based memories”, where the “modeling of any physical device” includes “simulation” with “nitrogen-vacancy centres” “use cases”; Coopmans, Pg. 4, Col. 1, Para. 2, “The performance metrics of a simulation are determined statistically from many runs. Due to the independence of each run, simulations can be massively parallelised and thereby efficiently executed on computing clusters”):
. . . by the one or more computing devices . . . (Krneta, Para. [0069], “FIG. 9 shows an example computing device to implement the various techniques described herein, according to some embodiments”)
generating, by the one or more computing devices, a first simulator node associated with the first operating state for the quantum computing device (Krneta, Para. [0041], “one or more virtual machines of a virtual computing service may be instantiated to process an algorithm simulation job . . . the simulation may involve multiple classical computing resources . . . quantum compute simulator using classical hardware 418 may include one or more “warm” simulators that are pre-configured simulators such that they are ready to perform a simulation job”, where the “simulators” may be “pre-configured” to “perform a simulation job”, which will be different from other simulations based on the specific “pre-configur[ations]”; see also Krneta, Para. [0024], “In some embodiments, the container may also include one or more environment variables, and user 116 may specify their values to further customize the compute environment”, where the simulations can differ based on “user” “customiz[ation]” of “the compute environment”; and where in view of Coopmans, the simulations are differ based on operating states for one of a plurality of devices, “All physical devices”, see Coopmans, Pg. 11, Col. 1, Para. 6, “All physical devices in a quantum network are modelled by a ‘component’ object, and are thereby also all simulation entities”; Coopmans, Pg. 10, Col. 2, Para. 3, “NetSquid allows the modelling of any physical device in the network that can be mapped to qubits. To demonstrate this we studied two use cases involving nitrogen-vacancy centres in diamond as well as atomic-ensemble based memories”, where the “modeling of any physical device” includes “simulation” with “nitrogen-vacancy centres” “use cases”; Coopmans, Pg. 4, Col. 1, Para. 2, “The performance metrics of a simulation are determined statistically from many runs. Due to the independence of each run, simulations can be massively parallelised and thereby efficiently executed on computing clusters”, where “independen[t]” “simulation” “run[s]” creates a plurality of simulated operating states; see also Coopmans, Pg. 7, Fig. 6, “The NV hardware model consists of ~15 parameters and from those we focus on four parameters in this figure: (A) two-qubit gate fidelity, (B) detection probability, (C) induced storage qubit noise and (D) visibility . . . We start by improving all ~15 parameters . . . Then, for each of the four parameters only, we individually decrease their improvement”, where variations in operating states based on changes to the “~15 parameters” are simulated; Krneta, Para. [0069], “FIG. 9 shows an example computing device to implement the various techniques described herein, according to some embodiments”);
. . . by the one or more computing devices . . . (Krneta, Para. [0069], “FIG. 9 shows an example computing device to implement the various techniques described herein, according to some embodiments”)
and generating, by the one or more computing devices, a second simulator node associated with the second operating state for the quantum computing device (as discussed in detail above, Krneta in view of Coopmans teach a plurality of simulators to each simulate a plurality of operating states of the quantum computing device, where a plurality necessitates a second simulator node associated with a second operating state, see Krneta, Para. [0041], “In some embodiments, quantum compute simulator using classical hardware 418 of quantum computing service 104 may be used to simulate an algorithm using classical hardware . . . quantum compute simulator using classical hardware 418 may include one or more “warm” simulators that are pre-configured simulators” and Coopmans, Pg. 4, Col. 1, Para. 2, “The performance metrics of a simulation are determined statistically from many runs. Due to the independence of each run, simulations can be massively parallelised and thereby efficiently executed on computing clusters”, where “independen[t]” “simulation” “run[s]” creates a plurality of simulated operating states; see also Coopmans, Pg. 7, Fig. 6, “The NV hardware model consists of ~15 parameters and from those we focus on four parameters in this figure: (A) two-qubit gate fidelity, (B) detection probability, (C) induced storage qubit noise and (D) visibility . . . We start by improving all ~15 parameters . . . Then, for each of the four parameters only, we individually decrease their improvement”).
The reasons of obviousness are discussed above in regard to the rejection of Claim 1 and remain applicable here.
Krneta in view of Coopmans do not explicitly teach . . . monitoring . . . a first operating state for the quantum computing device for a first monitoring period . . . monitoring . . . a second operating state for the quantum computing device for a second monitoring period . . . .
However, Dasgupta teaches [a quantum computing method, comprising] (Pg. 1, Abstract, “Noisy, intermediate-scale quantum (NISQ) computing devices offer opportunities to test the principles of quantum computing but are prone to errors arising from various sources of noise. Fluctuations in the noise itself lead to unstable devices that undermine the reproducibility of NISQ results. Here we characterize the reliability of NISQ devices by quantifying the stability of essential performance metrics”):
[a quantum computing device] (Pg. 2, Col. 2, Para. 4, “We characterize in detail the stability of two superconducting transmon devices produced by IBM called yorktown and toronto. With the layouts shown in Fig. 1, these NISQ devices”);
. . . monitoring . . . a first operating state for the quantum computing device for a first monitoring period . . . monitoring . . . a second operating state for the quantum computing device for a second monitoring period . . . . (Pg. 3, Col. 1, Para. 1, “We collected daily calibration metrics of yorktown from 1 March 2019 to 30 December 2020”, where monitoring of the quantum device “yorktown” occurred from “1 March 2019 to 30 December 2020”, which is split into at least two “period[s]”, a first period “the period June 2019 to December 2019” and a second period “the next 12 months”, see Pg. 3, Col. 2, Para. 1, “The stability of the fidelity is referenced to the initial distribution for FI collected in March 2019, and the metric diverged sharply during the period June 2019 to December 2019. However, the metric FG for register pair (0,1) fluctuated much less during the next 12 months”; and where the “period[s]” correspond with a first and second operating state of the device because they had different states of operating “stability”, for additional details see also Pg. 4, Fig. 3; Pg. 3, Col. 2, Para. 2, “The spatial stability of FG for the yorktown device is also shown in Fig. 3b. The heatmap measures the distance between the fidelities describing pairs of CNOT operations. It corresponds to the metric distribution for the entire data” and see generally Pg. 1, Col. 1-2, Para. 3-1, “Even when temporal drift and spatial variability are mitigated efficiently on short scales, e.g., the duration of a single program execution [24]–[28], unstable noise undermines efforts to track progress in device performance and reproduce experimental milestones”, where instability changes operating states).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to combine the use of a device to generate a plurality of quantum simulator nodes for a quantum device, a first and second quantum simulator node of the plurality respectively associated with a first and second operating state of the quantum device of Krneta in view of Coopmans with the first and second monitoring period of a quantum device, where the first and second periods are respectively associated with a first and second operating state of the quantum device of Dasgupta in order to generate simulator nodes with specific operating states, which may be tied to specific performance and time-based monitoring periods (Dasgupta, Pg. 3, Col. 2, Para. 1, “The stability of the fidelity is referenced to the initial distribution for FI collected in March 2019, and the metric diverged sharply during the period June 2019 to December 2019. However, the metric FG for register pair (0,1) fluctuated much less during the next 12 months”, where the “stability”-based operating states varied between “period[s]”) and may be a significant factor when deciding which execution node to execute a quantum service (Krneta, Para. [0026], “based on the algorithm provided by user 116, algorithm execution management system 106 may recommend and identify appropriate quantum computing resources 112 (e.g., from a pool of quantum computing resources) for user 116”, where, depending on the service, “reproduce[ibility]” may be a dispositive selection consideration, see Dasgupta, Pg. 1, Col. 1-2, Para. 3-1, “Even when temporal drift and spatial variability are mitigated efficiently on short scales, e.g., the duration of a single program execution [24]–[28], unstable noise undermines efforts to track progress in device performance and reproduce experimental milestones”).
Regarding Claim 5, Krneta in view of Coopmans, and Dasgupta teach the method of claim 4, wherein the method comprises determining, by the one or more computing devices (Krneta, Para. [0069], “FIG. 9 shows an example computing device to implement the various techniques described herein, according to some embodiments”), a
transition between the first monitoring period and the second monitoring period based at least in part on an occurrence of a threshold condition (Dasgupta, Pg. 3, Col. 2, Para. 1, “The stability of the fidelity is referenced to the initial distribution for FI collected in March 2019, and the metric diverged sharply during the period June 2019 to December 2019. However, the metric FG for register pair (0,1) fluctuated much less during the next 12 months”, where the first monitoring period “June 2019 to December 2019” and the second monitoring period “the next 12 months” are transitioned between based in part on the beginning and ending of entire month units as well as the “fluctuation” levels during these periods, both of which are within the broadest reasonable interpretation of a threshold condition).
The reasons of obviousness are discussed above in regard to the rejection of Claim 4 and remain applicable here.
Regarding Claim 6, Krneta in view of Coopmans, and Dasgupta teach the method of claim 5, wherein the threshold condition is based at least in part on time, performance of the quantum computing device, or resources of the quantum computing device (Dasgupta, Pg. 3, Col. 2, Para. 1, “The stability of the fidelity is referenced to the initial distribution for FI collected in March 2019, and the metric diverged sharply during the period June 2019 to December 2019. However, the metric FG for register pair (0,1) fluctuated much less during the next 12 months”, where, as discussed above, the beginning and ending of entire month units as well as the “fluctuation” levels are threshold conditions; and where the beginning and ending of entire month is based in part on time whereas “fluctuation” is based on part on performance).
The reasons of obviousness are discussed above in regard to the rejection of Claim 4 and remain applicable here.
Regarding Claim 19, the additional elements of the dependent claim are substantially the same as limitations of Claim 5, which includes the limitations of Claim 4, therefore it is rejected under the same rationale.
Claims 7 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Krneta in view of Coopmans and IEEE Communications Society contributors (hereinafter IEEE) (“IEEE P1913 Software-Defined Quantum Communication Working Group”).
Regarding Claim 7, Krneta in view of Coopmans teach the method of claim 1, wherein the method further comprises: determining, by the one or more computing devices (Krneta, Para. [0069], “FIG. 9 shows an example computing device to implement the various techniques described herein, according to some embodiments”),
. . . the quantum computing device joining the quantum computing network (Coopmans, Pg. 10, Col. 2, Para. 3, “NetSquid is entirely modular, allowing users to set up large scale simulations of complicated networks and to explore variations in the network design . . . exchanging classical and quantum communication with other nodes as dictated by the protocol”, where the “quantum communication” is received by the “quantum network” to “connect distant quantum devices”, see Coopmans, Pg. 2, Col. 1, Para. 1, “Quantum communication can be used to connect distant quantum devices into a quantum network”);
and communicating, by the one or more computing devices, . . . to each of a plurality of nodes of the quantum computing network (Coopmans, Pg. 10, Col. 2, Para. 3, “NetSquid is entirely modular . . . exchanging classical and quantum communication with other nodes as dictated by the protocol”, where the plural “nodes” indicates the communicating is to each of a plurality of nodes in the quantum computing network; and where it is “implement[ed]” using a computing device, see Krneta, Para. [0069], “FIG. 9 shows an example computing device to implement the various techniques described herein, according to some embodiments”).
The reasons of obviousness are discussed above in regard to the rejection of Claim 4 and remain applicable here.
Krneta in view of Coopmans do not explicitly teach . . . an operating profile of . . . the operating profile of the quantum computing device . . . .
However, IEEE teaches . . . [determining] . . . an operating profile of [a quantum computing device] (Pg. 2, Para. 2-3, “The model is organized as a series of modules, complementing each other, to provide a comprehensive, flexible, and extensible solution. Note that the model currently assumes that the quantum services offered by a device can be expressed in terms of quantum circuits composed as a series of connected quantum gates . . . The model is currently organized as follows: - The overarching IEEE 1913 module brings together common devices characteristic and operational parameters with other module-relevant components, to describe in a comprehensive way a networked quantum device’s capability and configuration parameters or operational states . . . ”, where “the model” of the “capability and configuration parameters or operational states” of “a device” is within the broadest reasonable interpretation of a profile)
. . . [communicating] the operating profile of the quantum computing device [over a network] . . . (Pg. 3, Fig. 2; Pg. 3, Para. 2, “An example of operation is shown in Figure 2. A remote “user” (a) interacts with the IEEE 1913 common YANG data model of a quantum device (b). This can take place over a classical network (c) while the quantum devices implement or utilize a quantum network (d)”).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to combine the device to determine a quantum device joining a quantum computing network and communicating to each of a plurality of quantum devices on the quantum network of Krneta in view of Coopmans with the determining and communication of an operating profile for a quantum device in a quantum network of IEEE in order to determine and communicate a profile of a joining device to other devices on the quantum network, which will increase the interoperability of devices on the quantum network (IEEE, Pg. 4, Para. 2, “quantum networks are comprised of interoperable devices that benefit from common interfaces”; IEEE, Pg. 1, Para. 2, “Developing such common and generic model for quantum devices and systems brings about interoperability and plug-and-play capabilities with other devices”) by providing operating information (IEEE, Pg. 2, Para. 3, “The model is currently organized as follows: - The overarching IEEE 1913 module brings together common devices characteristic and operational parameters with other module-relevant components, to describe in a comprehensive way a networked quantum device’s capability and configuration parameters or operational states . . . ”) that will be useful for scalable quantum solutions that cannot be solved using classical network communication (Coopmans, Pg. 2, Para. 1, “At larger distances, interconnected quantum networks allow for communication tasks between distant users on a quantum internet. Both types of quantum networks have the potential for large societal impact. First, analogous to classical computers, it is likely that any approach for scaling up a quantum computer so that it can solve real world problems impractical to treat on a classical computer, will require the interconnection of different modules. Furthermore, quantum communication networks enable a host of tasks that are impossible using classical communication”).
Regarding Claim 20, the additional elements of the dependent claim are substantially the same as limitations of Claim 7, therefore it is rejected under the same rationale.
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Krneta in view of Coopmans and Froehlich (“6 types of enterprise networking topologies”).
Regarding Claim 17, Krneta in view of Coopmans teach the computing device of claim 13, wherein the plurality of quantum computing devices and the plurality of quantum simulator nodes are connected in [a network] . . . (Krneta, Fig. 4, where the plurality of quantum computing devices, “422” through “428”, and the “Quantum Compute Simulator[s] . . . 418”, which are also a plurality, see Krneta, Para. [0041], “one or more virtual machines of a virtual computing service may be instantiated to process an algorithm simulation job . . . the simulation may involve multiple classical computing resources . . . quantum compute simulator using classical hardware 418 may include one or more “warm” simulators”, are part of a “Provider Network”; see also Krneta, Para. [0038], “FIG. 4 shows an example quantum computing service of a provider network . . . [the] provider network 102 may include quantum computing service 104, which may provide user 116 access to various quantum computing resources offered by quantum hardware providers 422, 424, 426, and 428. As indicated in FIG. 4, quantum hardware providers 422, 424, 426, and 428 may provide various different types of quantum computing resources”).
Krneta in view of Coopmans teach do not explicitly teach . . . a mesh topology.
However, Froehlich teaches [the use of] . . . a mesh topology [for a network] (Pg. 3, Sec. “3. Mesh network topology”, “A mesh topology is another nonhierarchical structure where each network node directly connects to all others”).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to combine the plurality of quantum computing devices and quantum simulator nodes connected in a network of Krneta in view of Coopmans with the use of a mesh topology as the network topology of Froehlich in order to connect all network components together, which will ensure network resiliency (Froehlich, Pg. 3, Sec. “3. Mesh network topology”, “A mesh topology is another nonhierarchical structure where each network node directly connects to all others. Mesh topologies ensure tremendous network resiliency”) and better facilitate iterative information exchange and co-processing (Krneta, Para, [0030], “during execution of the algorithm, classical computing resources 110 and quantum computing resources 112 may iteratively exchange data”; Krneta, Para. [0041], “the simulation may involve multiple classical computing resources, where some may be used to simulate quantum computing and the others may be used as a co-processor to process the classical computing”).
Response to Arguments
Applicant's arguments filed on December 17, 2025 have been fully considered. Each argument is addressed in detail below.
I. Applicant argues the objections to the drawings should be withdrawn (Applicant’s Remarks, 12/17/2025, Pg. 9, Section “Drawing Objections”).
Applicant’s amendments have overcome each and every objection to the drawings previously set forth in the September 17th, 2025 Office Action. As a result, these objections to the drawings have been withdrawn.
II. Applicant argues the rejections of the claims, under 35 USC § 101, should be withdrawn (Applicant’s Remarks, 12/17/2025, Pg. 9-10, Section “Rejection Under 35 U.S.C. § 101”).
Applicant’s amendments have overcome each and every rejection to the claims, under 35 USC § 101, previously set forth in the September 17th, 2025 Office Action. As a result, these rejections to the claims have been withdrawn.
III. Applicant argues the rejections of the claims, under 35 USC § 103, should be withdrawn (Applicant’s Remarks, 12/17/2025, Pg. 10-15, Section “Rejection Under 35 U.S.C. § 103”).
1. First, Applicant argues Krneta in view of Coopmans fail to disclose “determining . . . a selected execution node to execute the quantum service based in part on an operating state associated with the selected node”, as recited by the amended independent claims (Claim 1, ln. 14-16; see also Claim 13, ln. 13-14; Claim 18, ln. 15-17).
According to MPEP 2145 (IV), “[o]ne cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references” (see also In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986)).
Here, Applicant argues against the asserted disclosure of “determining . . . a selected execution node to execute the quantum service based in part on an operating state associated with the selected node” by arguing each of Krneta (Pg. 12, Para. 2) and Coopmans (Pg. 13, Pg. 14, Para. 1), individually, fail to disclose this limitation. However, Krneta and Coopmans are collectively relied upon to teach this limitation, with Krneta being relied upon to teach the selection of execution nodes to execute a quantum service and Coopmans being relied upon to teach selection based on an operating state. Therefore, arguments alleging Krneta fails to disclose operating states or Coopmans fails to disclose selection of execution nodes are not sufficient to show nonobviousness.
As a result, the argument is not persuasive
Given that Applicant did not argue against the combination of Krneta in view of Coopmans, the only remaining points of contention are whether Krneta teaches selection of execution nodes to execute a quantum service and whether Coopmans teaches selection based on an operating state.
Relevantly, Applicant begins their arguments by reproducing excerpts from the text of Krneta to highlight particular teachings of the disclosure which Applicant indicates are relevant to the claimed subject matter (Pg. 11-12, Para. 3-1). Subsequently, Applicant asserts that these excerpts show that “Krneta discloses using quantum computing resources to execute algorithms, and utilizing classical computing resources to act as a co-processor for a portion of the algorithm being executed by the quantum computing resources. Both the quantum computing resources and the classical computing resources are selected from respective pools of available resources” (Pg. 12, Para. 2).
Similarly, Applicant reproduces excerpts from the text of Coopmans to highlight particular teachings of the disclosure which Applicant indicates are relevant to the claimed subject matter (Pg. 13). Subsequently, Applicant asserts that these excerpts show that “Coopmans discloses simulation software that allows for alteration of hardware parameters to determine the output fidelity based on various parameters . . . Coopmans merely discloses testing a variety of hardware parameters to determine how hardware parameters can affect output fidelity” (Pg. 14).
According to MPEP 2145 (VI), “Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims” (see also In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993)).
Additionally, according to MPEP 2111, “During patent examination, the pending claims must be given their broadest reasonable interpretation consistent with the specification” (internal quotation marks omitted) (see also Phillips v. AWH Corp., 415 F.3d 1303, 1316, 75 USPQ2d 1321, 1329 (Fed. Cir. 2005)).
Here, the amended independent claims, as currently formulated, do not recite any limitations that would conflict with Applicant’s interpretation of Krneta. Additionally, even if the specification recited limitations that would conflict with Applicant’s interpretation of Krneta, these limitations would not be read into the claims. As a result, even if Applicant’s interpretations of Krneta and Coopmans were assumed to be true, it would not serve as evidence against the asserted teachings of Krneta in view of Coopmans, as relied upon in the September 17th, 2025 Office Action and this Office Action.
Specifically, Applicant argues “[t]he Patent Office misconstrues the quantum computing resources and classical computing resources as execution nodes” because “[a] mere pool of available computing resources as disclosed in Krneta is not the same as an execution node”. However, the claims do not positively recite a prohibition that prevents the execution nodes from occurring in a pool of available resources. Additionally, the use of classical and quantum computing resources is consistent with the specification (Applicant’s Spec. Para. [0024], “An execution node may be a quantum simulator node or may be a physical quantum computing device capable of executing a quantum service”). Furthermore, as discussed in detail above, these resources are within the broadest reasonable interpretation of execution nodes because they are stored as part of network and used for executing.
Additionally, the alleged disclosure of Coopmans of simulation software that allows for alteration of hardware parameters to determine the output fidelity based on various parameters for testing and selection is within the broadest reasonable interpretation, consistent with the specification, of selection based on an operating state (see Applicant’s Spec. Para. [0023], “The simulator node may simulate an operating state of the quantum computing device . . . Each operating state may be associated with a parameter set. The parameter set may include data indicative of one or more of a number of qubits, qubit type, quantum error correction scheme, qubit load, qubit noise profile, or other parameter(s) associated with operation of the quantum computing device”, where the operating states are simulated based on their association with hardware parameters).
As a result, the argument is not persuasive.
2. Second, Applicant asserts that the additional references cited in the September 17th, 2025 Office Action and this Office Action fail to overcome the above-alleged deficiencies in the teaches of Krneta in view of Coopmans (Pg. 14, Para. 2). However, as discussed above, the arguments in favor of the alleged deficiencies in the teaches of Krneta in view of Coopmans are not persuasive.
As a result, the argument is not persuasive.
3. Third, Applicant asserts that amended limitations of Claim 1 recite new features not taught by the prior art of record (Pg. 14, Para. 3-5). However, as discussed in detail in regard to the rejection of Claim 1, under 35 USC § 103, Krneta in view of Coopmans teach every element of amended claim 1.
As a result, the argument is not persuasive.
4. Lastly, Applicant argues the dependent claims are patentably distinct from the prior art of record because they dependent upon one of independent claim 1, 13, or 18, all of which applicant asserts are patentable (Pg. 14-15, Para. 6-1). However, as discussed in detail above, the arguments in support of the asserted patentability of claims 1, 13, and 18 are not persuasive.
As a result, the argument is not persuasive.
Conclusion
THIS ACTION IS MADE FINAL. 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 MATTHEW BRYCE GOLAN whose telephone number is (571)272-5159. The examiner can normally be reached Monday through Friday, 8:00 AM to 5:00 PM ET.
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, Alexey Shmatov can be reached at (571) 270-3428. 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.
/MATTHEW BRYCE GOLAN/Examiner, Art Unit 2123
/ALEXEY SHMATOV/Supervisory Patent Examiner, Art Unit 2123