DETAILED ACTION
Status of Claims
This action is in reply to the communication filed on 03/09/2026.
Claim 1 has been amended.
Claims 1-15 are currently pending and have been examined.
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 03/09/2026 has been entered.
Response to Arguments
Applicant's arguments filed 03/09/2026 regarding the rejections under 35 U.S.C. § 102 have been fully considered but they are moot in view of the new grounds of rejection and/or not persuasive as described below.
On pg. 7-8 Applicant provides an annotated quotation from McCaskey (truncated, emphasis original) and essentially argues:
Mccaskey discloses a XACC framework that describes a layered architecture with typed extension points (Compiler, Accelerator, IRTransformation, etc.). XACC is silent with respect to any component being connectable to any other component based on format matching. In contrast, McCaskey's description of XACC provides that the XACC workflow proceeds through defined layers and interfaces.
Specifically, Section 3.8 (on pages 11 - 12) of McCaskey provides as follows:
"To enable this, XACC requires a robust factory pattern that promotes this sort of interface-based programming. ( ... ) These services are loaded and registered with a core framework instance, thus enabling clients to request an instance of an interface implementation given by a specified string name. … This framework enables run-time registration of interface implementations against their interface type and unique string identifiers. ... At runtime, XACC loads the plugins (shared libraries) into the core CppMicroServices framework and all available interface implementations are registered. Clients can then request specific services by providing the interface type and the name of the service. The code in Fig. 15 demonstrates this process. First, a CppMicroServices framework is created and initialized, then all plugin libraries are loaded and all bundles are started (thus registering all service implementations). Later, clients can request a service (here Compiler) of a specified unique name (openqasm). To handle all of this, XACC leverages a class called the ServiceRegistry, which exposes templated methods to retrieve implementations corresponding to a certain interface type and the unique string name" (emphasis added).
Therefore, XACC defines a set of interfaces (e.g., Accelerator, Compiler, IRTransformation, etc.), and implementations of these interfaces are registered as services with the framework. A provided in McCaskey, a client retrieves an implementation by requesting a service implementing a particular interface type ( often with an identifier/name).”
Therefore, notwithstanding the lack of disclosure in Mccaskey of the claimed upstream and downstream interfaces, McCaskey appears to be silent with respect to such interfaces being common "in that the upstream interface of any of the processing modules can be connected to the downstream interface of any other processing module of the processing modules based on said upstream and downstream interfaces supporting a same data format for the description of the quantum program included in the job to be executed" as required by amended claim 1”
As it relates to the cited amended limitation, the argument is essentially moot in view of the new grounds of rejection. For clarity of record, Examiner notes that the highlighted portions of McCaskey describe the programming interfaces of the framework employed by users to retrieve modules from the registry and compose hybrid programs, not the functional interfaces by which modules exchange data during execution of a hybrid program, and its relevance beyond the description of the registry mapped to the database is uncertain. That is, AppSpec describes (¶0040-0041):
“The hardware resources and the software resources of the computing system 10 may be accessed, for instance remotely, by a client device 20 used by a user willing to develop and execute a hybrid program.
The software resources, e.g. stored in the database 13 in the example of FIG. 1, comprise a plurality of processing modules 32, 33 that may be used for building hybrid programs. “
While there is assumedly an interface provided that allows the user to access the database and specify the modules to be connected to build a hybrid program, AppSpec does not describe how users interact with the system, so McCaskey’s description such subject matter appears to be outside the scope of the discussion.
On pg. 8-9 Applicant essentially argues (emphasis original):
“In addition, claim 1 has been amended to recite, in part, "said plurality of processing modules comprises: at least one quantum processing module for each quantum computer, wherein each quantum processing module comprises an upstream interface for receiving a job to be executed by said quantum computer and does not comprise a downstream interface" (emphasis added).
In this regard, the Examiner cites pages 2 - 3, pages 11 - 12 (paragraph 3.8), and page 10, paragraphs 1 -2 of McCaskey. Further, in page 3 of the Office Action, the Examiner considers an alleged correspondence between the claimed "quantum processing module" and the "accelerator" of McCaskey, and refers to page 3, Section 3, and to page 9, Section 3.5 of McCaskey.
However, Mccaskey is silent with respect to the "accelerator" not comprising "a downstream interface," as required by amended claim 1. Specifically, XACC does not frame the accelerator as having "upstream only" and "no downstream."
Examiner respectfully disagrees McCaskey fails to teach the limitation. McCaskey provides an Accelerator/backend module for each type of quantum computing HW configured to run compiled programs on the corresponding quantum HW, functionally indistinguishable from the “quantum processing modules” described in AppSpec. The Accelerator does not transmit a job to be executed to any other program module, and thus does not comprise a downstream interface, because it is the element that carries out the execution.
From AppSpec
“A quantum processing module 32 is the software resource which actually communicates with a quantum computer 11 for executing a job received on its upstream interface 30 and for receiving the corresponding result which it returns on its upstream interface 30. Such a quantum processing module 32 is executed at least in part by a quantum computer 11, but it can also be partly executed by a classical computer 12 which implements the upstream interface 30 and communicates with a remote or local target quantum computer” (AppSpec ¶0047)
From McCaskey
“The back-end layer exposes an abstract quantum computer interface that accepts instances of the IR and executes them on a targeted hardware device (see section 3.5) (pg. 3, sect. 3)…The primary interface put forward by the XACC back-end layer is the Accelerator. This concept is intended to be implemented for physical and virtual quantum computing back-ends that can be local or remote. Accelerators expose an execute() method that takes as input an AcceleratorBuffer instance and the CompositeInstruction containing the compiled representation of the quantum program. Accelerators are free to implement this as necessary for executing the program on their representative hardware or simulator, but must persist all measurement results to the provided buffer instance (pg. 9, sect. 3.5)…XACC defines Accelerator implementations for IBM, Rigetti, D-Wave, IonQ, and a number of backend simulators (TNQVM[25], C++ local IBM noise-aware simulator, etc). Each of these physical QPU implementations actually subclass a RemoteAccelerator class, which further subclass Accelerator…We note that these Accelerators…make direct calls to the exposed REST API provided by the vendors. (pg. 16)
Applicant’s remaining arguments are moot in view of the new grounds of rejection.
Claim Interpretations
The following is a quotation of 35 U.S.C. 112(f):
(f) ELEMENT IN CLAIM FOR A COMBINATION.—An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims include one or more elements which are being interpreted as invoking 35 U.S.C. 112(f).
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element is limited by the description in the specification when 35 U.S.C. 112(f), is invoked. As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f):
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as "configured to" or "so that"; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f). The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f), is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f). The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f), is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function. Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f), except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f), except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitations are:
Claims 5 and 6: “iterative processing plugin module” (¶0036-0040, 0070-0074; FIG. 5); claims 7-9: “converting processing plugin module” (¶0036-0040, 0055-0069, FIG. 4); claims 10-11: “digital to analog converting, DAC, plugin module” (¶0036-0040, 0195-0100; FIG. 7); claims 12-13: “analog to digital converting, ADC, plugin module” (¶0036-0040, 0101-0102).
Because these claim limitations are being interpreted under 35 U.S.C. 112(f) they are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have the limitation(s) above interpreted under 35 U.S.C. 112(f), applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-7, 14, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over “XACC: a system-level software infrastructure for heterogeneous quantum–classical computing”, 2020 (hereafter McCaskey) in view of “myQLM documentation”, 07/2021 (hereafter “myQLM”).
Claim 1:
McCaskey discloses the limitations as shown in the following rejections:
A computing system (XACC framework and hardware environment) for executing hybrid programs, said computing system comprising: hardware resources comprising quantum computing resources (e.g. quantum processing units (QPUs)) and classical computing resources, said quantum computing resources comprising one or more quantum computers; and software resources (services) to be executed on the hardware resources, wherein the software resources are stored in a database (service registry); wherein the software resources comprise a plurality of processing modules usable for building hybrid programs (see at least pg. 1, Abstract; pg. 2, § 2; pg. 3, Fig. 2; pg. 11-12, § 3.8); Exemplary quotation:
“The purpose of the XACC framework is to provide a holistic, low-level software infrastructure that enables cross-platform programming, compilation, and execution of hybrid quantum–classical scientific applications.” (pg. 2, § 2, para. 1)…The XACC framework supports a service-oriented, or plugin, architecture that enables modular and extensible functionality. Such a service-oriented software architecture is useful in integrating hardware back-ends, high-level programming approaches, intermediate-level quantum compilation, and error mitigation strategies. A plugin architecture directly enables researchers and programmers to efficiently swap out key aspects of the overall programming, compilation, and execution workflow with problem-specific implementations” (pg. 2, last para.)
the plurality of processing modules comprising interfaces of two types respectively referred to as upstream interface and downstream interface, wherein said upstream interface is configured for receiving a job (program/”composite instruction”) to be executed and for transmitting a result of the execution of the received job, said downstream interface is configured for transmitting a job to be executed and for receiving a result (via AcceleratorBuffer) of the execution of the transmitted job, wherein said plurality of processing modules comprises: at least one quantum processing module ((Accelerator/backend) for each quantum computer, wherein each quantum processing module comprises an upstream interface for receiving a job to be executed by said quantum computer and does not comprise a downstream interface (see at least pg. 2, last para.; pg. 3, § 3; pg. 9-10, § 3.5; pg. 16, second to last para.) disclosing XACC provides a modular service-oriented architecture for building hybrid quantum-classical programs. The services including Accelerators/backends (quantum processing module) which communicates with quantum computing HW to execute a quantum program (description of a quantum program included in the job to be executed) input to its execution interface; the Accelerator does not output/transmit a job to be executed to and/or receive a result from any other module (because it carries out the execution and is the source of the result) and thus does not comprise a downstream interface.
wherein said plurality of processing modules comprises…a plurality of plugin modules (e.g. Compiler, Decorator, Algorithm) wherein each plugin module comprises a respective upstream interface and a downstream interface; wherein a hybrid program is built by connecting at least one plugin module and one quantum processing module (see at least pg. 3, § 3; pg. 11-12, § 3.8; pg. 9-10) disclosing XACC’s extensible, modular plugin architecture allows developers to connect modules providing services (e.g. error mitigation, VQE) with Accelerator backends chained together to form hybrid quantum–classical programs. Decorators particularly can be connected to form “a chain of decorators, with the final decorator delegating to a concrete Accelerator“, where each decorator performs pre-processing on an input job to be executed (downstream direction) and post-processing of subsequent results (upstream). Exemplary quotation:
XACC defines a decorator pattern on the Accelerator interface that promotes extensible pre- and post-processing of Accelerator execution input and results. The AcceleratorDecorator interface is an Accelerator sub-type but also delegates... to insert pre-processing of execution input, execution on the delegated Accelerator, and post-processing of measurement results and metadata. This design is particularly useful in near-term quantum computation as it enables an extension point for general error mitigation strategies…It is useful to note that this pattern enables a chain of decorators, with the final decorator delegating to a concrete Accelerator, thereby enabling a composition of different pre- and post-processing strategies (multiple error mitigation strategies)” (pg. 9-10, § 3.5, para. 3).
Regarding the limitation wherein the interfaces of the processing modules of the plurality of processing modules are common in that the upstream interface of any of the processing modules can be connected to the downstream interface of any other processing module of the processing modules based on said upstream and downstream interfaces supporting a same data format for the description of the quantum program included in the job to be executed, McCaskey at least teaches toward the subject matter disclosing (pg. 6) XACC employs a common intermediate representation data format for the jobs/programs being passed amongst the services and processed through the pre/post processing Decorator sequence, but some services have constraints on how they connect (e.g. VQE-Algorithm can on be at front of such a chain), and McCaskey does not elaborate on the functional implementation of the Decorators, and McCaskey accordingly does not clearly anticipate the limitation.
myQLM, however, discloses (pg. 1-2) an analogous system for programming and executing hybrid quantum-classical programs using software modules including “Quantum Processing Units” (QPUs) (quantum processing module) and “Plugins”. myQLM further discloses (pg. 16-17; pg. 27-30) the Plugins can be connected in a sequence concluding at a QPU to “process a flow of quantum circuits (or jobs) on their way to a QPU, and/or process a flow of information (samples or values) on their way back from a QPU” and teaches the limitation the plurality of processing modules comprising interfaces of two types respectively referred to as upstream interface and downstream interface, wherein said upstream interface (“compile” method input, “post_process” output) is configured for receiving a job (“Batch” object) to be executed and for transmitting a result (“BatchResult” object) of the execution of the received job, said downstream interface (compile method output) is configured for transmitting a job to be executed and for receiving a result of the execution of the transmitted job…quantum processing module (QPU) comprises an upstream interface for receiving a job to be executed by said quantum computer and does not comprise a downstream interface; wherein each plugin module comprises a respective upstream interface and a respective downstream interface. From pg. 17 for convenience.
PNG
media_image1.png
280
703
media_image1.png
Greyscale
Furthermore, as disclosed in at least pg. 16, (“compile for the way in…will take a Batch together with some HardwareSpecs and return a new Batch..when a fresh batch or job is submitted, the batch will run through the compile of plugin1, the resulting batch will run through the compile of plugin2, etc.) the output of each Plugin in each direction is in the same data format (“Batch”, “BatchResult”) as the received input, accordingly, the interfaces of the processing modules of the plurality of processing modules are common in that the upstream interface of any of the processing modules can be connected to the downstream interface of any other processing module of the processing modules based on said upstream and downstream interfaces supporting a same data format (“Batch”) for the description of the quantum program included in the job to be executed.
It would have been obvious to one of ordinary skill in the art prior to the filing date of the invention to modify McCaskey to support the quantum Plugin implementation disclosed by myQLM because it provides easy, user friendly programming semantics that simplify the design of programs while still facilitating customization and extension (myQLM pg. 1; pg. 16-17).
Claim 2:
The combination of McCaskey/myQLM discloses the limitations as shown in the rejections above. McCaskey further discloses wherein a hybrid program is built at least by connecting a plurality of plugin modules altogether, by connecting the downstream interface of a plugin module with the upstream interface of another plugin module, and by connecting at least one quantum processing module to the plurality of connected plugin modules, by connecting the downstream interface of a plugin module to the upstream interface of the at least one quantum processing module (see at least pg. 2.; pg. 3, § 3; pg. 11-12, § 3.8; pg. 9-10, § 3.5).
Claims 3 and 4:
The combination of McCaskey/myQLM discloses the limitations as shown in the rejections above. McCaskey further discloses wherein the quantum computing resources comprise at least two different quantum computers (e.g. IBM, Rigetti, D-Wave, IonQ) and the plurality of processing modules comprise: at least two quantum computer-specific quantum processing modules, one for each different quantum computer; at least two quantum computer-specific plugin modules, one for each different quantum computer…wherein said at least two quantum computer-specific plugin modules comprise at least two quantum computer-specific quantum compilers (pg. 18-19, § 5.2; pg. 16; pg. 2, § 2; pg. 22, § 6) .
“XACC defines Accelerator implementations for IBM, Rigetti, D-Wave, IonQ, and a number of backend simulators (TNQVM[25], C++ local IBM noise-aware simulator, etc). Each of these physical QPU implementations actually subclass a RemoteAccelerator class (pg. 16)…Programmers compose the quantum kernel code as a string (or string literal) and compile it with the correct Compiler instance, which creates and returns an instance of the IR, ready to be used in backend execution. This compilation step can optionally take the Accelerator as input, thereby exposing connectivity, noise, or other back-end-specific properties at compile time.”
Claims 5 and 6:
The combination of McCaskey/myQLM discloses the limitations as shown in the rejections above. McCaskey further discloses one or more iterative processing plugin modules (Algorithms, Optimizers), wherein each iterative processing plugin module is configured to iteratively process a result received on the downstream interface to produce an updated job that is output on the downstream interface, until a stop criterion is satisfied (convergence), and wherein the result that is output on the upstream interface (AcceleratorBuffer) is determined based on the results received on the downstream interface…wherein at least one iterative processing plugin module is configured to perform a variational quantum eigensolver (VQE) (pg. 10-11, § 3.6 - 3.7; pg. 19-21, § 5.3). See also myQLM pg. 27-30.
Claim 7:
The combination of McCaskey/myQLM discloses the limitations as shown in the rejections above. McCaskey further discloses one or more converting plugin modules (preprocessor Decorator and/or observable transform), wherein each converting processing plugin module is configured to convert (transform/preprocess) an input job received on the upstream interface into an output job to be output at the downstream interface, and to convert or forward an input result received on the downstream interface into an output result to be output at the upstream interface (see at least pg. 8, § 3.4; pg. 9-10, § 3.5, para. 3). See also myQLM pg. 1, 17, and 28.
Claims 14 and 15:
The combination of McCaskey/myQLM discloses the limitations as shown in the rejections above. McCaskey further discloses wherein all or part of the hardware resources are cloud (e.g. IBM Valencia) computing resources…wherein all or part of the hardware resources are high performance computing, HPC, resources (pg. 18, last para.; pg. 16, para. 3; pg. 1-2, § 1, para. 2).
Claims 8 and 9 are rejected under 35 U.S.C. 103 as being unpatentable over McCaskey in view of myQLM in further view of (“Hybrid Programming for Near-term Quantum Computing Systems”, 2018), hereafter McCaskey2018.
Claims 8 and 9:
The combination of McCaskey/myQLM discloses the limitations as shown in the rejections above. McCaskey does not specifically disclose at least one converting plugin module configured to convert an input job received on the upstream interface into a plurality of output jobs to be output at the downstream interface and to convert input results received on the downstream interface into an output result to be output at the upstream interface.
McCaskey2018, however, discloses (pg. 8, § VI-B) at least one converting plugin module (error mitigation pre-processor) configured to convert an input job received on the upstream interface into a plurality of output jobs (kernels) to be output at the downstream interface and to convert input results received on the downstream interface into an output result to be output at the upstream interface…[claim 9] wherein at least one converting plugin module is configured to perform error mitigation.:
“The IRPreprocessor interface takes an IR instance as input, pre-processes or otherwise modifies it, and then outputs a functional instance of some post-processing step that is stored by the XACC framework and executed after QPU execution. This is an ideal setup for mitigating the QPU qubit readout errors…To this end, XACC provides a pre-processor implementation that prepends the IR instance with additional quantum kernels preparing classical bit strings in order to characterize the bit flip error rates. Those results are stored and used by a post-processor functional instance, which is applied to the qubit measurement results after execution.”
It would have been obvious to one of ordinary skill in the art prior to the filing date of the invention to modify McCaskey/myQLM with the error mitigation technique disclosed by McCaskey2018 as it represents the use of known technique to improve similar systems in the same way.
Claims 10-13 are rejected under 35 U.S.C. 103 as being unpatentable over McCaskey in view of myQLM in further view of Linvill et al. (US 2020/0027029 A1).
Claims 10-13:
The combination of McCaskey/myQLM discloses the limitations as shown in the rejections above. Regarding claims 10-13, McCaskey further discloses (pg. 3, para. 1; pg. 17, para. 2; pg. 22, § 6; pg. 16, para. 4) that XACC’s “back-end infrastructure supports both gate model and annealing quantum computing technologies” via corresponding Accelerator/backend modules and accordingly discloses [claim 10, 13] wherein the quantum computing resources comprise at least one analog (annealing-based) quantum computer (e.g. D-Wave) configured to execute quantum programs expressed as temporal schedules (Hamiltonian) and analog quantum processing module (e.g. D-Wave Accelerator) comprising an upstream interface configured to receive a job (kernel/instructions) including a temporal schedule [and] [claim 11, 12] at least one digital (gate-based) quantum computer (e.g. IBM) configured to execute quantum programs expressed as quantum circuits and the plurality of processing modules comprises: a digital quantum processing module (e.g. IBM Accelerator) comprising an upstream interface configured to receive a job including a quantum circuit.
McCaskey also briefly discloses “XACC provides an extensible quantum code transpilation or compilation interface that may be tailored to parse many different languages” (pg. 3), but does not specifically describe the embodiment of translating between quantum gate and annealing program formats and does not explicitly disclose [claim 10] a digital to analog converting, DAC, plugin module comprising an upstream interface configured to receive an input job including a quantum circuit and to convert the input job into an output job including a corresponding temporal schedule, to be output at the downstream interface and/or [claim 12] an analog to digital converting, ADC, plugin module comprising an upstream interface configured to receive an input job including a temporal schedule and to convert the input job into an output job including a corresponding quantum circuit, to be output at the downstream interface.
Linvill, however, discloses (¶0051-0053) an analogous environment including both at least one analog quantum computer (annealer/adiabatic quantum computer) configured to execute quantum programs expressed as temporal schedules (Hamiltonian) and at least one digital quantum computer (quantum gate processors) configured to execute quantum programs expressed as quantum circuits. Linvill further discloses (¶0070-0076 FIG. 2, 4) a quantum formulation converter (DAC/ADC module) configured to receive data representing a computational task to be performed by an identified type of quantum computing resource (e.g. annealer or gate processor) and, when it is formatted for the incorrect type, translate to an acceptable type; and accordingly teaches DAC/ADC module comprising an upstream interface configured to receive an input job including a quantum circuit/temporal schedule and to convert the input job into an output job (correctly formulated task) including a corresponding temporal schedule/ quantum circuit, to be output at the downstream interface.
It would have been obvious to one of ordinary skill in the art prior to the filing date of the invention to augment McCaskey/myQLM’s transpiler plugins with the quantum formulation converter of Linvill to enhance scheduling flexibility and efficiency by increasing the amount of viable job-resource assignments and prevent errors from incorrectly formatted tasks (Linvill ¶0025-0026. 0033-0034).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure:
US 11494681 B1 is directed to a system for compiling and managing hybrid classical/quantum algorithms.
“Extending XACC for Quantum Optimal Control” is directed to analog-digital circuit transpilation in the context of XACC.
Composable Programming of Hybrid Workflows for Quantum Simulation is directed to a workflow system for composing and running hybrid jobs.
The following are directed to design time and/or runtime type checking or type matching: 20090288065 A1, US 20090288067 A1, US 10949171 B1.
Any inquiry of a general nature or relating to the status of this application or concerning this communication or earlier communications from the Examiner should be directed to Paul Mills whose telephone number is 571-270-5482. The Examiner can normally be reached on Monday-Friday 11:00am-8:00pm. If attempts to reach the examiner by telephone are unsuccessful, the Examiner’s supervisor, April Blair can be reached at 571-270-1014.
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.
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.
/P. M./
Paul Mills
06/17/2026
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196
Prosecution Insights