DETAILED ACTION
This Office Action is in response to the request for continued examination and associated fee payment filed on June 5th, 2026, as well as the amendments filed on May 5th, 2025 for Application No. 17/874,605, in which claims 1-9, 11-15, and 17-20 are presented for examination.
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 05/05/2026 has been entered.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claim 12 is rejected under 35 U.S.C. 112(d) as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends.
Regarding Claim 12, each element of the claim is positively recited in Claim 1, which Claim 12 is dependent upon. As a result, Claim 12 fails to further limit the subject matter of a claim upon which it depends. See below for an element-by-element comparison.
Claim 12
Claim 1
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,
determining, by the one or more computing devices, a 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: 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.
determining . . . a selected execution node . . . to execute the quantum service based at least in part on a comparison between a performance profile of the quantum service and an operating state associated with the selected execution node
Applicant may cancel the claim, amend the claim to place the claim in proper dependent form, rewrite the claim in independent form, or present a sufficient showing that the dependent claim complies with the statutory requirements.
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”) and Kozlowski et al. (hereinafter Kozlowski) (“Towards Large-Scale Quantum Networks”).
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”);
receiving, by the one or more computing devices, a request to execute a quantum service (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 Para. [0069], “FIG. 9 shows an example computing device to implement the various techniques described herein, according to some embodiments”); 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 a comparison between a performance profile of the quantum service . . . 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”; see also 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; 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”):
analyzing, by the one or more computing devices, a quantum service definition file associated with the quantum service to determine the performance profile of the quantum service (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)”; 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”, are associated with the quantum service and within the broadest reasonable interpretation of a quantum service definition file, which are analyzed by the computing device to determine and form a performance profile for the request, which must be determined by the device to allow for selection to be based on it, see 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”),
the performance profile comprising information indicative of operating characteristics for execution of the quantum service (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)”; 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”, are information indicative of operating characteristics for execution of the quantum service); and
determining, by the one or more computing devices based on the performance profile, whether to route the quantum service to 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”, where, as discussed above, the request details, such as “dependencies”, “system . . . settings”, and “type of quantum computing unit”, form a performance profile for the request, which is used by the device to determine execution of the quantum service, which requires routing to the “classical” or “quantum” resources, “the algorithm execution management system may determine whether the quantum computing resources are available to execute the algorithm . . . identify or select appropriate quantum computing resources . . . [and] cause the classical computing resources to be provisioned on-demand”, see 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” and 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”)
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 physical quantum computing device joining . . . for the physical quantum computing device . . . operating states of the physical quantum computing device . . . physical . . . and an operating state associated with . . . physical . . . .
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 based on a comparison between a performance profile of the quantum service 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 in comparison with quantum service operating profiles, 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”).
Additionally, Kozlowski teaches . . . [a quantum computing network comprising a] . . . physical [quantum computing device] . . . (Pg. 1, Fig. 1, “Quantum networks will be embedded within clas sical networks and use existing infrastructure to send and receive control messages. This can be achieved by adding a quantum data plane to existing networks. Note that the quantum and classical links do not have to coincide” and Pg. 3, Col. 2, Para. 6, “However, they may also be processing nodes with an optical interface which are capable of storing qubits, as well as performing universal quantum computation. Examples include NV centres in diamond [4, 28, 58], ion traps [40], and neutral atoms [49]. Such systems can also be used to run application protocols in the quantum memory network stage and eventually above”; redundant recitations of physical omitted).
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 wherein operations are performed with regard to a quantum computing network comprising a plurality of quantum simulator nodes for a quantum computing device of Krneta in view of Coopmans with the a quantum computing network comprising a physical quantum computing device of Kozlowski in order to incorporate physical quantum computing devices into the quantum computing network method, which will allow for execution of quantum services that are incompatible with classical simulations (see Kozlowski, Pg. 1, Col. 1, Para. 2, “Quantum networks will be used to execute protocols that have no classical counterpart or are more efficient than what is possible classically. The range of possible quantum applications will depend on the development stage of the underlying hardware [67]. This new networking paradigm has already opened up a range of new applications, which are provably impossible to realise using classical communication over the inter net that we have today”; see also Kozlowski, Pg. 3, Col. 1, Para. 1, “We remark that this means that since there are 2n possible strings x ∈ {0,1}n, we need an exponential number of parameters αx ∈ C in order to describe the definite state |Ψ⟩. This is in sharp contrast to classical computing, where only n parameters are needed”), thereby increasing network efficiency and security in a feasible manner (Kozlowski, Pg. 2, Col. 1, Para. 4-6, “At present, no large-scale quantum networks exist. At short distances (~100 km in telecom fibre), devices that perform QKD are commercially available . . . Long-range quantum communication, as well as the realisations of networks with functionalities more advanced than QKD, are presently still in their infancy. Entanglement between distant sites (~1200 km) has been produced using a satellite”; see also Kozlowski, Pg. 1, Col. 1, Para. 2, “Quantum networks will be used to execute protocols that have no classical counterpart or are more efficient than what is possible classically” and Kozlowski, Pg. 5, Col. 2, Para. 4, “one of the most important features quan tum networking brings with it is enhanced security”).
Regarding Claim 2, Krneta in view of Coopmans and Kozlowski 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 physical 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, which in view of Kozlowski, are for the physical quantum computing device, see Kozlowski, Pg. 1, Fig. 1 and Kozlowski, Pg. 3, Col. 2, Para. 6, “However, they may also be processing nodes with an optical interface which are capable of storing qubits, as well as performing universal quantum computation. Examples include NV centres in diamond [4, 28, 58], ion traps [40], and neutral atoms [49]. Such systems can also be used to run application protocols in the quantum memory network stage and eventually above”).
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 and Kozlowski 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 and Kozlowski 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 and Kozlowski 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 and Kozlowski 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”):
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 and Kozlowski 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 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 and Kozlowski 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 physical quantum computing device and a plurality of quantum simulator nodes (Krneta, Fig. 4, where the plurality of quantum computing devices, “422” through “428”, which in view of Kozlowski, comprise a physical quantum computing device, see Kozlowski, Pg. 1, Fig. 1 and Kozlowski, Pg. 3, Col. 2, Para. 6, “However, they may also be processing nodes with an optical interface which are capable of storing qubits, as well as performing universal quantum computation. Examples include NV centres in diamond [4, 28, 58], ion traps [40], and neutral atoms [49]. Such systems can also be used to run application protocols in the quantum memory network stage and eventually above”, 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 of the physical 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, which in view of Kozlowski, are for the physical quantum computing device, see Kozlowski, Pg. 1, Fig. 1 and Kozlowski, Pg. 3, Col. 2, Para. 6, “However, they may also be processing nodes with an optical interface which are capable of storing qubits, as well as performing universal quantum computation. Examples include NV centres in diamond [4, 28, 58], ion traps [40], and neutral atoms [49]. Such systems can also be used to run application protocols in the quantum memory network stage and eventually above”),
wherein the physical quantum computing device 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”, which in view of Kozlowski, comprise the physical quantum computing device, see Kozlowski, Pg. 1, Fig. 1 and Kozlowski, Pg. 3, Col. 2, Para. 6, “However, they may also be processing nodes with an optical interface which are capable of storing qubits, as well as performing universal quantum computation. Examples include NV centres in diamond [4, 28, 58], ion traps [40], and neutral atoms [49]. Such systems can also be used to run application protocols in the quantum memory network stage and eventually above”; 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 a comparison between a performance profile for the quantum service and 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” 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 selected based at least in part on the operating state associated with it, and therefore, the above comparison of the “appropriate . . . resource” for the service “request” from the user 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 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”):
analyze a quantum service definition file associated with the quantum service to determine the performance profile of 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”, are associated with the quantum service and within the broadest reasonable interpretation of a quantum service definition file, which are analyzed by the computing device to determine and 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”),
the performance profile comprising information indicative of operating characteristics for execution of 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”, are information indicative of operating characteristics for execution of the quantum service); and
determine, based on the performance profile, whether to route the quantum service to the physical quantum computing device or one of the plurality of quantum simulator nodes; route the quantum service to the selected execution node for execution (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”, where, as discussed above, the request details, such as “dependencies”, “system . . . settings”, and “type of quantum computing unit”, form a performance profile for the request, which is used by the device to determine execution of the quantum service, which requires routing to the selected execution node for execution, the “classical” or “quantum” resources, “the algorithm execution management system may determine whether the quantum computing resources are available to execute the algorithm . . . identify or select appropriate quantum computing resources . . . [and] cause the classical computing resources to be provisioned on-demand”, see 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” and 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
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, Kozlowski, and Dasgupta et al. (hereinafter Dasgupta) (“Stability of Noisy Quantum Computing Devices”).
Regarding Claim 4, Krneta in view of Coopmans and Kozlowski teach the method of claim 1, wherein generating, by the one or more computing devices, a plurality of quantum simulator nodes for the physical 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”; which in view of Kozlowski, the quantum computing device is physical, see Kozlowski, Pg. 1, Fig. 1 and Kozlowski, Pg. 3, Col. 2, Para. 6, “However, they may also be processing nodes with an optical interface which are capable of storing qubits, as well as performing universal quantum computation. Examples include NV centres in diamond [4, 28, 58], ion traps [40], and neutral atoms [49]. Such systems can also be used to run application protocols in the quantum memory network stage and eventually above”):
. . . 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 physical quantum computing device (Kozlowski, Pg. 1, Fig. 1 and Kozlowski, Pg. 3, Col. 2, Para. 6, “However, they may also be processing nodes with an optical interface which are capable of storing qubits, as well as performing universal quantum computation. Examples include NV centres in diamond [4, 28, 58], ion traps [40], and neutral atoms [49]. Such systems can also be used to run application protocols in the quantum memory network stage and eventually above”) . . .
generating, by the one or more computing devices, a first simulator node associated with the first operating state for the physical 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”; where in view of Kozlowski, the quantum computing device is physical, see Kozlowski, Pg. 1, Fig. 1 and Kozlowski, Pg. 3, Col. 2, Para. 6, “However, they may also be processing nodes with an optical interface which are capable of storing qubits, as well as performing universal quantum computation. Examples include NV centres in diamond [4, 28, 58], ion traps [40], and neutral atoms [49]. Such systems can also be used to run application protocols in the quantum memory network stage and eventually above”);
. . . 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 physical quantum computing device (Kozlowski, Pg. 1, Fig. 1 and Kozlowski, Pg. 3, Col. 2, Para. 6, “However, they may also be processing nodes with an optical interface which are capable of storing qubits, as well as performing universal quantum computation. Examples include NV centres in diamond [4, 28, 58], ion traps [40], and neutral atoms [49]. Such systems can also be used to run application protocols in the quantum memory network stage and eventually above”) . . .
and generating, by the one or more computing devices, a second simulator node associated with the second operating state for the physical 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”; where in view of Kozlowski, the quantum computing device is physical, see Kozlowski, Pg. 1, Fig. 1 and Kozlowski, Pg. 3, Col. 2, Para. 6, “However, they may also be processing nodes with an optical interface which are capable of storing qubits, as well as performing universal quantum computation. Examples include NV centres in diamond [4, 28, 58], ion traps [40], and neutral atoms [49]. Such systems can also be used to run application protocols in the quantum memory network stage and eventually above”).
The reasons of obviousness are discussed above in regard to the rejection of Claim 1 and remain applicable here.
Krneta in view of Coopmans and Kozlowski do not explicitly teach . . . monitoring . . . a first operating state for . . . for a first monitoring period . . . monitoring . . . a second operating state . . . 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 physical 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 and Kozlowski 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, Kozlowski, 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, Kozlowski, and Dasgupta teach the method of claim 5, wherein the threshold condition is based at least in part on time, performance of the physical quantum computing device, or resources of the physical 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, Kozlowski, and IEEE Communications Society contributors (hereinafter IEEE) (“IEEE P1913 Software-Defined Quantum Communication Working Group”).
Regarding Claim 7, Krneta in view of Coopmans and Kozlowski 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 physical 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”, where in view of Kozlowski, the quantum computing device is physical, see Kozlowski, Pg. 1, Fig. 1 and Kozlowski, Pg. 3, Col. 2, Para. 6, “However, they may also be processing nodes with an optical interface which are capable of storing qubits, as well as performing universal quantum computation. Examples include NV centres in diamond [4, 28, 58], ion traps [40], and neutral atoms [49]. Such systems can also be used to run application protocols in the quantum memory network stage and eventually above”);
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 and Kozlowski do not explicitly teach . . . an operating profile of . . . the operating profile of the physical quantum computing device . . . .
However, IEEE teaches . . . [determining] . . . an operating profile of [a physical 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 physical 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 physical 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 and Kozlowski with the determining and communication of an operating profile for a physical 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, Kozlowski, and Froehlich (“6 types of enterprise networking topologies”).
Regarding Claim 17, Krneta in view of Coopmans and Kozlowski teach the computing device of claim 13, wherein the physical quantum computing device 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”, which in view of Kozlowski, comprise the physical quantum computing device, see Kozlowski, Pg. 1, Fig. 1 and Kozlowski, Pg. 3, Col. 2, Para. 6, “However, they may also be processing nodes with an optical interface which are capable of storing qubits, as well as performing universal quantum computation. Examples include NV centres in diamond [4, 28, 58], ion traps [40], and neutral atoms [49]. Such systems can also be used to run application protocols in the quantum memory network stage and eventually above”, 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”).
The reasons of obviousness are discussed above in regard to the rejection of Claim 1 and remain applicable here.
Krneta in view of Coopmans and Kozlowski 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 physical quantum computing device and the plurality of quantum simulator nodes connected in a network of Krneta in view of Coopmans and Kozlowski 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 May 5th, 2026 have been fully considered. Each argument is addressed in detail below.
Applicant argues the rejections of the claims, under 35 USC § 103, should be withdrawn (Applicant’s Remarks, 05/05/2026, Pg. 9-14, Sections “Rejections Under 35 U.S.C. § 103” and “Dependent Claims”).
In response to Applicant’s amendments, the previously communicated rejections under 35 U.S.C. § 103, have been withdrawn. However, Applicants arguments are not persuasive in light of the new grounds for rejection, under 35 U.S.C. § 103, discussed in detail above. The new grounds of rejection rely on new prior art of record to teach the new combination of elements in the amended independent claims, which were not presented in any of the previously presented claims. As a result, Applicant arguments against the previously communicated rejections under 35 U.S.C. § 103 are rendered moot.
However, for clarity of the record and to expedite prosecution, arguments that remain relevant to the new grounds of rejection are discussed below.
1) First, Applicant argues Krneta in view of Coopmans fail to disclose “receiving, by the one or more computing devices, a request to execute a quantum service” (Claim 1). Specifically, Applicant asserts the March 5th, 2026 Office Action relies on the same disclosures of Krneta to teach both the “receiving, by the one or more computing devices, a request to execute a quantum service” (Claim 1) and “receiving, by one or more computing devices, data indicative of a quantum computing device joining a quantum computing network” (Claim 1). Based on this assertion, Applicant argues Krneta cannot disclose “receiving, by the one or more computing devices, a request to execute a quantum service” (Claim 1) because the “data” and “request” cannot logically be the same entity. In support of this position, Applicant references MPEP § 2143.03, which is reproduced below, and Becton, Dickinson, and Co. v. Tyco Healthcare, Gr., LP, 616 F.3d 1249, 1254 (Fed. Cir. 2010), which purportedly stands for the positions that "Where a claim lists elements separately, the clear implication of the claim language is that those elements are distinct components of the claimed invention” and “where a claim provides two separate elements, those two elements logically cannot be one and the same" (Remarks, Pg. 11-12, Para. 6-1) (internal quotation marks and Applicant-identifications of adjustments omitted).
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)).
Additionally, according to MPEP § 2143.03, “Examiners must consider all claim limitations when determining patentability of an invention over the prior art”.
Here, as discussed in detail in the March 5th, 2026 Office Action, the limitation “receiving, by the one or more computing devices, a request to execute a quantum service” (Claim 1) is fully taught by Krneta. Whereas a person of ordinary skill in the art would be motivated to modify Krneta in view of Coopmans to arrive at the limitation “receiving, by one or more computing devices, data indicative of a quantum computing device joining a quantum computing network” (Claim 1) by modifying Krneta’s data receiving functionality to further comprise data indicating of device joining. The motivation for this modification is discussed at length in the March 5th, 2026 Office Action and in this Office Action. As a result, Krneta in view of Coopmans fully teach the Applicant-cited limitations of the amended claims (see MPEP § 2143.03) by disclosing distinct elements that are within the broadest reasonable interpretation (see MPEP 2111) of both the “request” (Claim 1) and the “joining” data (Claim 1). Therefore, even if it were assumed that a reference could not anticipate or render obvious multiple limitations of a claim using the same disclosed entity, which is fundamental to Applicant’s argument, the argument would still be insufficient because the March 5th, 2026 Office Action and this Office Action do not rely on one entity to teach both the request and joining data.
As a result, the argument is not persuasive.
2) Second, Applicant argues that “Krneta discloses a system where a pool of classical computing resources and a pool of quantum computing resources may be provisioned for a particular algorithm” and, as a result, “Krneta does not disclose determining whether to execute the quantum service using the quantum computing device or a classical computing device comprising a respective quantum simulator node” and “Krneta does not disclose routing an algorithm to a particular device or node, but rather discloses dynamically provisioning computing resources in order to execute the algorithm” (Remarks, Pg. 12-13, Para. 2-3).
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)).
Additionally, 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)).
Here, as discussed in detail above, Krneta discloses elements that are within the broadest reasonable interpretation of the Applicant-cited elements of the independent claims (see MPEP 2111).
Additionally, even if Applicant’s characterizations of Krneta were assumed to be true, the amended claims, as currently formulated, would not preclude disclosure of the Applicant-cited elements of the independent claims. Specifically, a system where a pool of classical computing resources and a pool of quantum computing resources may be provisioned for a particular algorithm can reasonably teach determining whether to execute the quantum service using the quantum computing device or a classical computing device comprising a respective quantum simulator node and routing an algorithm to a particular device or node; and any limitations recited in the specification that could conflict with this interpretation are not read into the claims (see MPEP 2145 (VI)). As evidence of this point, it is worth pointing out that the recitation of “quantum computing device or a classical computing device” can reasonably be understood as inclusive, such that determining and routing can occur for both computing device categories (see MPEP 2111).
As a result, the argument is not persuasive.
3) Third, Applicant argues the previous prior art of record fail to teach or suggest “analyzing, by the one or more computing devices, a quantum service definition file associated with the quantum service to determine the performance profile of the quantum service, the performance profile comprising information indicative of operating characteristics for execution of the quantum service”, as recited in the amended claims (Remarks, Pg. 13-14, Para. 4-3).
According to 37 C.F.R. 1.111(b), “In order to be entitled to reconsideration or further examination, . . . The reply by the applicant or patent owner must . . . specifically points out the supposed errors in the examiner’s action . . . A general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references does not comply with the requirements of this section”.
Here, this argument amounts to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references.
As a result, the argument is not persuasive.
Conclusion
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
Prosecution Insights